做业务智能体之前，我以为难点在「会不会调工具」。 真跑起来才发现：能调通一次不难，难的是它坏的时候你还控得住。
面试里如果只吹 Function Calling，却讲不清翻车点，很容易被当成只会演示。下面三个地方，是我自己和身边项目里最常见的坑。
翻车一：工具失败（超时、空结果、半成功）
Agent 一调外部 API、数据库、导出服务，就会遇到：
- 接口超时
- 返回空或字段缺失
- 调用成功了，但业务上等于没做成（比如查到 0 条还当完成）
ChatBot 挂了，最多回一句「我不知道」。 Agent 挂在工具上，若没有处理，整条链路会卡死，或者用幻觉把空结果编圆。
我现在的兜底习惯：
1. 工具调用一律设超时；超时记日志，不要无限等。
2. 区分「技术失败」和「业务空结果」：前者可重试或降级，后者要明确告诉用户「没查到」。
3. 关键工具失败就停，进入人工 / 友好提示，而不是假装任务已完成。
4. 日志里至少留下：哪一步、哪个工具、入参摘要、错误码或耗时。
面试加分句：我不怕工具失败，怕的是失败了还像成功。
翻车二：循环调用（空转烧钱）
模型觉得「再调一次就好」，于是同一工具反复打，或 A 调 B、B 又调 A。 表现是：日志刷屏、费用上涨、任务永远不结束。
根因通常不是模型「坏了」，而是你没给它终止条件。我现在的硬约束：1.步数上限：例如单次任务最多 N 步，到顶强制结束并汇报已完成部分。 2. 同工具连续失败次数上限：连续失败就熔断，不再盲重试。 3. 状态可见：每一步的目标、工具、结果回填写进上下文，避免模型「忘了已经查过」。 4. 禁止无意义重复：同一入参短时间内重复调用，直接拦截。
一句话：Agent 要有刹车，不能只有油门。
翻车三：提示词失控（目标漂移、格式乱、越权）
提示词一长，模型容易：
- 忘了原目标，开始闲聊或扩写无关内容
- 输出格式漂移，下游解析失败
- 在不该调工具时乱调，或越权去碰权限外的数据
这在演示里不一定爆，一接真实业务规则就爆。
我现在的约束方式：
1.目标写死：开头明确「本次只完成某某报告 / 某某检查，不做其他」。
2. 输出契约：关键节点要求 JSON / 固定字段，失败就重试或人工，不把散文硬塞进流水线。
3. 工具白名单：只能调允许的工具；权限在服务端校验，不信任模型自觉。
4. 人在回路：对外正式结果前加审核节点，尤其是诊断结论、对外文案。
提示词是说明书，不是宪法；真正的边界要落在代码和权限上。
三个坑，对应三句面试答法
可以这样答「Agent 你怎么保证稳定」：
> 我重点防三类：工具失败、循环空转、提示词失控。 > 做法是超时与降级、步数与熔断、输出契约加工具白名单，关键结果走人审。 > 演示能跑通只是起点，可追踪、可终止、可回滚才像工程。
和 ChatBot 对比，为什么这些坑更扎眼
ChatBot 主要拼「说得像不像」。 Agent 拼「做得成不成」。
一旦引入工具和多步，失败模式就从「一句胡话」变成「一整条流程失控」。所以我谈 Agent 项目时，会主动讲翻车和兜底——这比只讲「我接了某个模型」更像干过活。
会调工具，只说明 Agent 有手； 限步数、记日志、敢熔断、肯人审，才说明它有刹车。
先把三个翻车点堵上，再谈多智能体、更炫的编排。
热门跟贴