为何在演示中表现出色的智能体在实际应用中会失败，以及应构建什么替代方案。
为何在演示中表现出色的AI智能体在实际应用中会失败：它们出问题的原因、单智能体与多智能体的权衡、重试与回退机制，以及真正的运行成本。
演示中从未展示的内容
一个优秀的智能体演示总是围绕“理想路径”来呈现的：工具调用会返回完全符合预期的结果，模型能正确理解任务，也不会出现超时情况。在这种条件下，使用工具并逐步推理任务的智能体看起来几乎已经完成任务。然而人们往往低估了这与实际服务之间存在的差距。
实际生产环境中的情况则完全属于“理想路径”之外的范畴：证书会过期，数据结构可能在不经通知的情况下发生变化，命令也可能被误读。响应可能会延迟、内容不完整甚至根本不会到达，而且智能体所调用的每一个外部API都有其独特的运行规律。这些都不是运气不好，而是因为在系统中存在非确定性组件，而外界环境仍在不断变化，所以才会出现这类情况。
演示版本往往也会跳过评估与监控环节。没有这些机制，幻觉内容或已超出容量的上下文窗口都不会引发警报。智能体会持续输出答案，而这些答案往往是错误的，直到出现用户投诉或数据损坏时才会显现问题。只有在密切监控下才表现良好的系统，还不具备无人值守运行的条件。
一个简单的例子就能体现这种差距。设想一个通过调用日历API来安排会议的智能体。在演示环境中，日历API会在200毫秒内返回结构规范的JSON数据。但在实际使用中，该API有时会突然更改字段名称，有时会返回空页面，有时还会卡住30秒。此时模型可能会编造一个看似合理的时段来填补空白。对于每种情况都需要有明确的处理方式：验证数据结构，将空值视为独立状态，限制等待时间，绝不能随意猜测。
智能体在执行任务时出现故障的环节
那些相同的故障点一再出现。
- 模型输出不可靠。模型给出的结论缺乏现实依据。当智能体连接到实时系统或被要求提供关键信息时，编造的细节会导致错误的操作。
- 工具故障。智能体依赖API和外部工具，而这些工具可能会功能变化、断开连接或拒绝处理异常输入。智能体需要为工具故障准备应对方案，比如重新尝试或转而使用更简单的方法。
- 无限循环。糟糕的状态跟踪或未处理的边界情况会让智能体陷入无进展的循环。清晰记录已完成的操作是避免重复工作的关键。
代理数量越多并不代表可靠性越高
人们通常认为将任务分配给多个代理可以提高性能和可靠性。但实际上，这往往只会带来更多麻烦，因为每个额外的代理都会增加沟通和协调的工作量。
单个代理有一个明显优势：只需调整一处参数，只需关注一项指标。当任务遵循简单的线性流程，比如步骤清晰、易于理解的常规查询时，单个代理通常更为合适。
对于那些可以拆分成独立部分并同时运行的复杂任务，使用多个代理是合理的做法。即便如此，仍然存在成本问题——必须有人确保这些代理不会朝不同方向行事或重复劳动。如果没有协调，它们就会基于过时或矛盾的信息开始工作。每增加一个代理，失败的风险就会增加一个点；每次任务交接都可能是上下文丢失或被扭曲的环节；而且各代理之间的依赖关系会导致一个故障蔓延到其他代理，因此监控措施也需要相应地更加严格。
当任务能够自然拆分时，协调机制就能发挥作用。在客户支持场景中，一个代理负责获取信息，另一个代理判断消息的情绪倾向，第三个代理负责起草回复，而协调机制则将这些部分整合成一份完整的答复。
以批量处理为例：有几百份几乎相同的支持工单，都需要相同的分类和标准处理流程。相比由多名客服人员协作处理，采用固定流程并在决策点仅进行一次模型调用的方式更易于测试、定价，也更容易向审计人员解释。
不过在许多情况下，简单的确定性工作流程仍优于团队协作。如果任务不需要并行处理，或者管理开销超过了可能带来的收益，那么由单个客服人员按照固定顺序处理一批相似请求会更高效，因为几乎无需应对各种变化。
决策应基于实际任务情况：任务的复杂程度、并行处理是否有帮助，以及协调和监控会带来多大的成本。诚实地权衡这些因素，才能让设计充分利用各种方法的优点，同时避免其缺点。
从一开始就为生产环境设计
为生产环境构建系统意味着放弃打造令人印象深刻的演示版本的目标，转而追求一种能够从必然会出现的故障中恢复的系统。有几项实践尤为重要。
结构化的输出。 强制使用统一的输出格式可以降低误解的可能性，同时简化调试工作。下游系统可以依赖这种可预测的格式。
带延迟的重试机制以及超时设置。 网络故障或服务短暂不可用等临时性问题可以通过重试来解决，且每次重试之间的等待时间应逐渐增加。超时功能则能防止程序无限期地等待永远不会到来的响应。
备用方案。备用流程应与其他代码路径一样被记录下来并经过测试，因为未经测试的备用方案往往会在最关键时刻失效。当主要路径出错时，替代工具或方法或许能得到类似结果，但准确度或覆盖范围会降低。这样服务仍可继续运行而不会停止。
人工介入。复杂或模糊的情况正是自动化系统难以处理的领域。将这类任务交由人工操作员处理，能让关键决策更具判断力，同时明确责任归属。
模型路由。不同的模型各有优势。将每项任务分配给最合适的模型，可以提高准确度和性能，但这取决于对各类模型能力范围的了解。
评估集。一个有效的评估集会将普通请求与异常请求混合在一起：格式错误的输入、相互矛盾的指令、会导致超时的工具。通过持续使用各种不同的测试场景，可以及早发现系统弱点，并判断在条件变化时该智能体是否仍能保持可靠性。
追踪与成本监控。追踪功能能够记录数据及决策在系统中的流转路径，有助于调试和优化。成本监控则可确保资源使用量处于约定范围内，并判断系统的投入是否物有所值。
有计划的性能降级。如果智能体无法访问其搜索工具，它仍可以基于缓存数据给出答案并明确说明，这比显示错误页面更好。在压力环境下，系统应有序地失去部分功能而非彻底崩溃。提前规划故障处理方式能够加快恢复速度，同时将對用户的影响降到最低。
运行代理的实际成本
代币费用是账单上显而易见的部分，但这仅仅是冰山一角。合理的成本核算还需考虑其他几项内容。
- 工具调用。每次对外部服务的调用都会耗费金钱与时间，还会增加可能出现故障的环节。代理通常离不开这些工具，但这种依赖性使得系统成本更高、更复杂。
- 基础设施。服务器、存储和网络设施的规模必须根据用户活跃度及任务难度变化而调整。要确保这些基础设施的高可用性，还需额外投入成本。
- 重试与错误处理。虽然这对系统可靠性至关重要，但每次重试都会消耗计算资源。在频繁出现短暂故障的系统中，这些成本会迅速累积。
要客观反映实际情况，应按每项完成任务的成本来计算，而非按每次模型调用的成本。一个需要三次重试、两次工具调用以及人工审查的任务，其实际成本远高于仅根据调用次数得出的数值，而正是这个数值才应在不同设计方案之间进行比较，并且需要每周跟踪其变化。
实际结论是，必须综合管理所有这些方面的成本。仅从代币成本来看似乎很低的系统，一旦计入重试次数、支持人员费用及服务器成本，实际上可能会变得非常昂贵。
“可靠”究竟意味着什么
代理型人工智能的未来并不取决于最自动化、最引人注目的演示效果，而更在于这些系统在实际应用中能否稳定运行、快速恢复，并实现成本回收。人们的关注点应从在受控环境中展示技术能力，转向应对部署过程中种种棘手的现实问题。
可靠性是首要考虑的。这意味着要平稳应对故障，在条件变化时及时调整，并在负载下保持稳定。支撑这一目标的架构注重结构化的输出、合理的错误处理以及全面的监控。通过预判可能出现的问题，并设置重试、超时和备用机制，团队能够构建出既能恢复又能持续稳定运行的系统。
成本则是第二位的考量。一个AI系统的实际成本包括基础设施、工具交互、延迟、人工投入以及模型令牌费用。要控制成本，就需要合理利用资源，并清晰了解每项架构选择所带来的代价。一个虽然价格更低但需要更多重试和人工审核的模型，其最终成本很可能高于那些一次就能正确运行的更强大的模型。
在任何项目启动之前，一份简短的检查清单就足够了。上述每种故障模式都能被明确命名吗？每种故障模式都有对应的负责人和应对措施吗？能否查看该智能体昨天的操作记录？是否存在支出上限和循环深度限制？是否有快速关闭智能体的方法？如果这些问题的答案都是“否”，那么该系统仍然只是演示版本。
最终，成功的标准将取决于这些智能体与人们现有工作流程的契合程度以及它们所能创造的实际价值。这要求人们转变思维方式，从关注单独使用的智能体，转向构建能够扩展人们能力的系统。只要始终以可靠性、合理的成本效益以及使用者的需求为出发点，智能体型人工智能就能成为解决复杂问题及日常工作的可靠伙伴。
相关阅读
- 实用指南：构建可用于生产环境的智能欺诈检测系统 — 该指南提供了可操作的步骤说明，包括合同、检查项以及供采用该模式的团队直接使用的代码片段。
- 实用指南：Claude Code Agent Teams：组建团队的实用指南 — 该指南同样提供了可操作的步骤说明，包括合同、检查项以及供采用该模式的团队直接使用的代码片段。