构建AI代理？以下是应避免的反模式。

AI代理的失败往往是可以预测的，问题通常不在于模型本身，而在于架构、记忆设计、工具决策以及复杂性引入的方式。大多数失败的代理项目都有一系列结构性的错误，这些错误只有在后期才会显现，且修复成本高昂。

理解AI代理为何失败以及如何失败，有助于建立更清晰的心智模型，了解工作代理真正需要什么。有效的方法是从简单开始，为可观测性而构建，并且只在能衡量回报时才增加复杂性。而反模式则发生在团队反其道而行之时。

本文涵盖三个主要方面：代理失败为何比简单AI系统更严重；随系统增长而累积的架构错误；以及仅在生产环境中才出现的操作错误。

代理失败的影响更大，因为语言模型回答问题，而代理系统解决任务，它评估下一步行动、选择工具、根据结果行动，并在出错时调整。推理循环使代理强大，也使其以提示-响应系统绝不会有的方式失败。当聊天机器人给出错误答案时，对话结束；但当代理在任务中途出错时，它会继续执行，可能使用错误参数调用工具、产生下游步骤依赖的输出，或因无法识别卡住而无限循环。错误的决策在每一步中扩大影响范围。

自主代理还会跨步骤累积状态，这意味着错误会复合。第二步中的错误工具调用会影响第五步的上下文。过时的记忆条目会影响三步后的决策。到用户看到问题时，代理可能已经基于错误假设采取了多个错误行动。因此，代理失败在种类上不同，而不仅仅是程度。

最常见的架构错误是过早追求多代理架构。团队读到多代理系统、分层协调器和点对点协作，并尚未验证单一代理能否解决问题时就设计这些模式。多代理系统引入的协调开销会以难以预测的方式增加成本和调试难度。在采用多代理之前，应询问几个问题：单一代理加上良好设计的工具是否能解决问题？是否已测量单一代理实际失效的地方？业务价值是否抵消了令牌成本和增加的复杂性？通常，对于首次部署，单一代理就能胜任。

构建一个做所有事情的代理是另一个常见错误。一个配置了十五种工具、指令庞大且承担多种任务类型的代理会在所有任务上表现不佳。优化一种输入会损害其他输入的性能，因此将输入路由到专门代理往往比一个通用代理产生更好结果。解决方案不一定是增加更多代理，通常一个范围明确的专用代理表现优于臃肿的通用代理。先缩小职责范围，如果仍然不够，才有理由拆分。

工具列表的扩散也是一个问题。每增加一个工具到代理的上下文中，模型在决定下一步行动时就需要考虑更多。大的工具表面会增加模型错误选择的可能性，膨胀提示大小，并使调试更困难。保持工具集最小且目的明确，工具应该是离散的、可重用的模块，具有清晰且不重叠的职责。如果工具功能相似，应明确命名空间以便模型区分。如果为了处理边缘情况而添加工具，则表明任务范围需要缩小。

硬编码逻辑而非为变化而构建会带来风险。代理系统在生产环境中不断变化，今天有效的提示下周可能需要修订。如果逻辑硬编码在单体实现中，每次更改都可能破坏其他部分。模块化设计意味着提示放在配置中心，工具作为离散单元，代理由所需组件组装而成。

跳过专用记忆设计是另一个常见问题。许多团队像设计聊天机器人一样设计代理：传入对话，得到回复。但处理多步任务的代理需要知道两步前的动作、工具调用是否成功以及携带的中间结果。如果没有深思熟虑的记忆设计，上下文窗口溢出会成为生产事故。分层方法可以处理：短期会话记忆用于当前任务状态和最近工具输出，长期记忆用于跨会话上下文，结构化日志用于审计和调试。从一开始就构建记忆架构，因为事后改造非常痛苦。

在缺乏可观测性的情况下交付代理会导致诊断困难。AI代理通常是非确定性的，具有不透明的推理过程。当出现问题时，无法通过堆栈跟踪了解代理的决策原因。需要查看提示链、工具调用及其参数、模型推理路径以及上下文在步骤间的流动。没有可观测性的团队可能会花费数周调试那些通过适当仪表化几分钟就能诊断的问题。从第一行代码开始构建可观测性。

给予代理无管控的写访问权限非常危险。LLM可能产生幻觉、推理错误并以高置信度给出错误答案。具有直接写生产系统权限的代理需要在输出和操作之间设置防护。读写操作属于不同风险类别，应从一开始就区别对待。实践上意味着：在任何写操作执行前进行输出验证，限制代理能触及的范围，并对高风险或不可逆操作要求人机确认。

忽略长时间运行任务中的上下文漂移会导致问题。代理启动时准确的上下文会随着任务运行而退化，工具输出变得过时。上下文窗口应视为有限资源，具有递减的回报。缓解措施包括：自动清除过时的工具结果，仅从工具响应中提取需要的信息，并限制工具输出大小。不要等到代理开始产生幻觉才处理。

最后，在未充分评估前就部署是常见错误。在受控测试环境中工作的代理会在生产环境中暴露新的失败模式。有效的评估意味着在部署前用多样化、对抗性和边缘情况的输入运行代理，定义与业务成果相关的成功指标，并建立反馈循环使生产失败直接影响下一轮迭代。

总结而言，代理失败更多是架构性而非模型性，可避免的错误包括过度工程、代理过载、缺乏记忆、可观测性差和无管控工具访问。本文提供了反模式及其修复的详细表格，并推荐了值得阅读的资源。祝构建顺利！