AI Agent 开发常见反模式：业务逻辑不应委托给 LLM

深入 AI Agent 开发，我反复在个人原型项目和早期生产项目中看到同样的错误。这些反模式在本地测试时看起来无害，但一旦真实用户流量到来就会导致全面崩溃。

本文将逐一讨论我踩过的实际坑，不涉及高层理论。

反模式一：将 LLM 作为唯一事实来源

一个常见陷阱：把所有决策完全委托给大语言模型，所有逻辑、验证、条件判断都放在 Prompt 文本里。

Prompt 会漂移。模型输出在每次 API 调用间会有差异。Temperature 设置会改变行为。

更好的做法：将业务规则、验证逻辑和硬约束保留在应用代码中。用 LLM 做推理、规划和自然语言理解，而不是强制执行刚性规则。不要把关键逻辑变成 Prompt 注释。

反模式二：过度依赖无限工具访问

许多 Agent 演示让模型不受限制地访问所有可用工具。听起来很强大，但造成了巨大风险。

Agent 可能出于好奇调用无关工具，无限重试失败的端点，或者在用户不知情的情况下触发昂贵操作。

针对每个任务采用工具白名单 限制每个工具在单个工作流中的调用次数 将只读工具与破坏性写操作工具分离 对修改数据的操作要求明确确认

反模式三：忽略部分失败状态

当所有 API 调用都成功时一切都很美好。一旦某个工具返回错误，许多 Agent 实现就会崩溃。

它们不跟踪哪些步骤成功了、哪些失败了，也无法恢复工作。整个任务从头重启，浪费 Token 和用户时间。

你需要显式的状态跟踪：保存哪些子任务已完成、哪些待处理、哪些已失败。当错误发生时，在本地恢复而不是重置整个 Agent 会话。

反模式四：无限任务迭代

很容易忘记给 Agent 循环设置上限。面对模糊的问题，Agent 可能陷入死循环：计划、执行、观察、再计划、重复。

计算成本迅速飙升，用户无限期等待。

始终设置硬限制：

单个用户请求的最大子任务数 单个会话的最大 Token 预算 超时阈值。超过时停止执行并向用户返回状态报告

反模式五：观察与决策不做区分

Agent 读取工具输出，但许多开发者将原始、未过滤的工具响应直接塞回 Prompt。

嘈杂的日志、大型 JSON 转储、堆栈跟踪会迅速撑满上下文窗口。重要信号被无关文本淹没。

添加一个轻量级转换层：总结工具输出、剥离冗余字段、仅提取与当前子任务相关的字段，然后再喂给 LLM。

构建可靠的 AI Agent 与其说是巧妙的 Prompt 技巧，不如说是防御性工程，就像传统后端开发一样。

我们花大量时间阅读 Agent 能做什么，但同样重要的是研究什么会让它们崩溃。

你在自己的 Agent 项目中踩过这些反模式吗？或者发现了其他意想不到的坑？欢迎在评论区分享。