Agent 项目踩坑与恢复

【真实性边界】我不会把题库预设的客服 Agent 当作自己的经历。以下内容必须用我的真实项目填写；若讨论的是假设架构，我会明确标注“假设”。

【回答框架】项目面向【真实用户和流程】，基线是【】，目标指标与统计口径是【】，约束为【】。我的直接职责是【】，依赖团队提供【】。系统将确定性逻辑放在【规则或代码】，把需要语义判断的部分交给【模型】，并通过【工具、状态、记忆、权限、监控】形成完整链路。

【事实填空】实际遇到的质量问题是【】，稳定性问题是【】，成本或延迟问题是【】。我分别用【回放/trace/压测/人工抽检】定位，实施【真实改动】，结果为【真实数字与窗口】，副作用为【】。人工接管条件和回滚方式是【】。

【证据自检】我会确认有基线、版本、样本、对照和个人提交；多 Agent 如果没有相对单 Agent 的实验，就只描述设计取舍，不写成已经验证的提升。

【追问入口】请继续追问：哪些逻辑必须确定性执行，工具调用为什么失败，长链路如何超时与恢复，状态怎样同步，阈值如何校准，以及什么时候不该使用 Agent。

架构部分可以用“确定性外壳包住概率模型”来说明。认证、权限、金额计算、状态迁移和最终写操作由代码或规则控制；模型负责理解语言、提出候选步骤或生成解释；工具执行器负责 schema 与业务校验；观测系统负责把每次决策和副作用关联到同一 trace。这样即使模型输出不稳定，风险仍有明确边界。

三个挑战需要不同证据。质量问题用标注集、错误切片和人工复核；稳定性问题用错误码、超时、循环与恢复记录；成本问题用 token、模型路由、工具调用次数和缓存命中。单独调整 temperature 通常不能证明参数错误已解决，结构化解码和业务校验更关键。缓存虽然降低延迟，也会引入版本、权限和失效风险。

是否拆多 Agent 应看任务依赖和受控实验。若多个角色只是顺序执行固定步骤，拆分可能只增加上下文和同步成本；只有并行、独立专长或隔离权限带来可测收益时才值得。回答结尾应明确当前方案在哪些流量、权限和错误预算下成立，以及哪些约束变化会触发重新设计。

最后，口述时先给出一句与真实经历一致的结论，再沿“场景、职责、决策、证据、边界”展开。任何无法对应记录的公司、数字、职责或因果关系都删除；如果面试官追问到本人没有负责的部分，明确说明团队分工，再讲自己能够验证的接口与依赖。