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