美团后端 AI 一面：工具恢复、中断与代码上下文
本场面试题
- 工具调用失败后，怎样决定重试、对账还是停止？
- 设计可中断的智能体系统时，要区分哪些状态和恢复边界？
- 大项目代码怎样与 Agent 交互，才能在有限 token 下保留必要上下文？
面经与参考答法
美团后端 AI 一面：工具恢复、中断与代码上下文
来源自述为美团暑期后端AI开发一面，面试日期与部门未披露。本文选录工具失败、中断设计和大项目代码上下文三组问题；答案与例子是编辑教学补充，不代表候选人现场方案或原项目实现。
（1）工具调用失败后，怎样决定重试、对账还是停止？
先按操作语义分类：瞬态网络或限流错误，只有在幂等、策略允许且剩余预算足够时才做有限退避重试；参数、权限和永久业务错误需要修正或停止。写操作超时可能已在远端提交，应按operation ID查询对账，已提交则复用结果，未知则保留未解决状态，不能盲目重发。部分副作用可能需要补偿，但补偿是新动作，也会失败；恢复后仍须验证结果。
教学例子（非原项目工具）：创建报告的请求超时，按同一operation ID查询已提交，就获取原结果；若只能确认状态未知，则继续对账或转人工，不能生成新ID再建一份并宣称恢复成功。
（2）设计可中断的智能体系统时，要区分哪些状态和恢复边界？
先明确中断指停止接收、暂停任务还是取消后续执行。把取消意图传到运行时和支持取消的工具，同时分别记录请求取消、确认停止、已提交与未知，不能把本地停止等待当成远端已撤销。持久化已确认事件、工具结果和必要任务状态，恢复时从可信确认点继续并重新核对权限；已发生的副作用要对账或补偿，不应重做。协议没有保证时，不能从任意token续接或宣称取消会回滚业务。
教学例子（非原项目）：用户点停止时通知可能已经发出。界面停止显示不等于通知被收回；服务端先记录该操作的确认状态，再决定是否继续、对账或补偿，恢复时不重复发送。
（3）大项目代码怎样与 Agent 交互，才能在有限 token 下保留必要上下文？
先绑定仓库快照与访问范围，按定义、引用、调用关系、关键词或语义检索找到相关代码，再围绕目标符号补齐必要类型、调用方、测试和配置。通过受限搜索与按需读取逐步扩展，保留文件、行号和commit，去掉重复与无关内容，并为工具结果和输出留出token预算。缺少关键证据时继续检索或说明缺口；不能靠静默截断整仓库，也不能把代码注释当成可覆盖用户指令的权限。
教学例子（非原项目仓库）：问谁调用createOrder，先查定义与引用，再读取相关入口、必要helper和测试，并标明commit；不把整个monorepo塞进提示词，发现跨文件依赖不足时再按需读取。