构建可在生产中运行的AI代理的最佳实践
内容提要
生产级AI代理的核心是确定性代码控制循环，仅在关键决策点调用模型。最佳实践包括：控制模型上下文、拥有提示词、精确定义工具；用确定性代码管理控制流并设置硬性停止条件；将状态存储在软件中而非模型内；保持代理范围狭窄且受监督。权衡方面，单一编排器配合短期子代理效果最佳，但需考虑成本与模型改进带来的冗余。
延伸解读
确定性代码与模型调用的平衡
生产级AI代理并非完全依赖模型，而是将大部分行为交给确定性代码，仅在关键决策点调用模型。这种设计能显著降低错误率，因为模型调用次数减少，复合错误的风险也随之降低。例如，20步操作中每步95%的准确率，整体成功率仅约三分之一，而通过减少模型调用，可以大幅提升可靠性。
上下文控制与提示词管理
控制模型上下文是提升可靠性的关键。开发者应像管理源代码一样管理提示词，进行版本控制和测试。同时，主动裁剪上下文，只保留当前步骤所需的信息，避免无关内容干扰模型判断。工具定义需精确，以减少模型选择错误工具的概率。这些做法能显著提升模型输出的准确性。
状态外部化与可扩展性
将状态存储在软件中而非模型内，使模型保持无状态，带来两大优势：一是系统可暂停和恢复，崩溃后能干净地恢复；二是便于水平扩展，因为任何实例都能处理任何请求。这种设计让模型成为纯函数，输入相同则输出相同，提高了系统的可测试性和可靠性。
单一编排器与短期子代理的权衡
关于多代理与单代理的争论，最终共识是：单一编排器持有完整上下文，生成短期子代理执行单一任务并返回摘要。子代理间直接通信易产生冲突，而编排器控制则能避免。但需注意成本，多代理设计消耗更多token，仅在任务价值高时才值得采用。
Q&A
生产级AI代理的核心设计原则是什么？
生产级AI代理的核心是确定性代码控制循环，仅在关键决策点调用模型。这意味着大部分行为由常规代码执行，模型只在少数需要判断的地方介入。
为什么AI代理在演示中表现良好但在生产环境中容易失败？
因为演示环境通常简单且可控，而生产环境面临真实流量，模型错误会累积，产生错误输出，循环可能失控，状态丢失等问题。
如何控制AI代理的上下文以提高可靠性？
控制上下文的三个习惯：拥有提示词（版本控制、审查、测试）、拥有上下文窗口（主动修剪不相关内容，保持相关性）、精确定义工具（清晰名称和输入模式）。
在AI代理中，控制流应该由什么决定？
控制流应由确定性代码决定，模型只在少数需要判断的点被调用。同时，必须设置硬性停止条件（如迭代上限、超时）确保循环终止。
AI代理的状态应该存储在哪里？为什么？
状态应存储在软件中（如数据库），而不是模型内。模型保持无状态，每次调用只读取上下文。这样支持暂停恢复、崩溃恢复，并便于水平扩展。
为什么推荐使用窄范围、受监督的AI代理？
窄范围代理失败面小，易于测试和调试。受监督意味着设计人工交接步骤，在敏感操作或低置信度时转交人类，提高安全性和可靠性。
单一代理和多代理设计各自的优缺点是什么？
单一代理简单但可能上下文过长；多代理并行可能产生冲突。最佳实践是单一编排器配合短期子代理，子代理独立完成任务并返回摘要，避免直接通信。
模型改进后，当前的AI代理最佳实践会过时吗？
部分会，但很多问题（如上下文窗口限制、状态一致性、安全暂停）不会因模型改进而消失。因此，应避免过度工程化，但核心实践仍有价值。
