#Agent 可靠性专题总览

Agent 的价值不是“让模型自己做更多事”，而是在路径不固定、信息不完整、需要多次观察和调整时，把模型变成一个能规划、执行、检查和恢复的执行者。

问题也从这里开始。普通 Chat 说错一句话，通常还能人工纠正；Agent 一旦能调用工具、改数据、跑任务，就可能出现 plan drift、tool misuse、infinite loop、恢复失败等问题。它不是一次模型调用，而是一段会变化的执行过程。

Agent 可靠性的目标不是让 Agent 永远不犯错，而是让它的目标、边界、步骤、工具、状态和失败都可控、可见、可恢复。

本专题可以按四篇文章连起来读：这篇总览回答 Agent 为什么会失控；《Agent 控制边界》回答目标、工具、权限和预算怎么收住；《Workflow、Tool Calling 和 Agent 的决策边界》专门判断什么时候用 Workflow，什么时候只需要 Tool Calling，什么时候才值得引入 Agent；《Agent 的恢复、回放、断点续跑和 Eval》讨论失败后如何恢复和持续评估。

#场景

先看一个企业内部运营 Agent。

运营同事每天要处理一批客户续费风险：读取 CRM 客户列表，查看最近工单和产品使用数据，判断风险原因，生成跟进建议，必要时创建任务给客户成功经理。

没有 AI 时，运营会手动筛选客户、打开多个后台、复制数据到表格、写备注、分配任务。流程耗时，但路径并不完全固定：不同客户可能需要查工单、看合同、对比用量、找最近沟通记录，甚至跳过某些步骤。

用户输入可能是：

帮我检查本周到期且过去 30 天活跃度下降的企业客户，找出最需要跟进的 20 个，并给每个客户生成一条 CS 跟进任务。

这个任务看起来适合 Agent，因为它需要动态决策。但失败样本也很具体：

• Agent 原计划只分析“本周到期客户”，执行中被某个异常客户吸引，开始扩展到所有低活跃客户，出现 plan drift。
• Agent 把 create_followup_task 当成查询工具使用，在未确认的情况下批量创建任务，属于 tool misuse。
• Agent 查询 CRM 后发现字段缺失，不断改写查询条件、重复检索同一批客户，进入 infinite loop。
• Agent 执行到第 14 个客户时工具超时，重新开始整批任务，导致前 13 个客户被重复创建任务，恢复失败。

这个场景的关键不是“模型能不能理解续费风险”，而是系统能否回答这些工程问题：

• Agent 当前目标是否仍然是用户授权的目标？
• 每一步工具调用是否在权限、成本和风险边界内？
• 失败后能否知道执行到哪里、哪些动作已经生效？
• 是否能从断点继续，而不是整段重跑？
• 哪些动作必须人工确认？

#问题类型

Agent 任务通常混合了规划、检索、判断和执行，不能只靠 prompt 描述“请谨慎”。

Agent 可靠性最容易出问题的四类故障是：

模型适合做动态判断，但不适合独自承担状态管理、权限、幂等、预算和恢复。Agent 工程的核心，就是把这些能力从 prompt 里拿出来，放到系统边界里。

#收益和成本判断

Agent 的收益主要来自长尾和动态任务：

• 减少人在多个系统之间切换。
• 处理路径不固定的多步骤任务。
• 根据工具结果调整下一步，而不是固定执行脚本。
• 覆盖规则和 workflow 难以穷举的异常样本。
• 将人工从信息搜集和重复判断中解放出来。

但成本也明显高于普通 Workflow：

• 需要计划状态、步骤日志、工具调用记录和 checkpoint。
• 需要更严格的工具权限、确认、幂等和回滚。
• 需要限制步数、时间、token、工具调用次数和费用。
• 需要为 plan drift、tool misuse、loop、恢复失败建立 eval。
• 需要运维监控、人工接管和事故复盘机制。

低风险、路径固定、步骤稳定的流程，不应该为了“智能”强行做 Agent。Agent 只有在流程真的需要动态选择步骤，并且收益能覆盖可靠性成本时，才值得引入。

#方案阶梯

Agent 可靠性也要从简单到复杂升级。

第一层不用 Agent。规则筛选、数据库查询、固定报表、表单流转能解决的问题，优先用确定性系统。

第二层是 prompt 或结构化输出。适合单步分类、抽取、摘要、草稿生成，输出可人工复核。

第三层是 Workflow。多步骤但路径稳定时，用状态机、任务队列和异常分支，比 Agent 更可靠。

第四层是 Workflow + 模型节点。流程由程序控制，模型只负责局部判断，例如判断客户风险原因或生成跟进建议。

第五层是受控 Agent。只有在下一步需要根据观察动态选择时，才开放有限工具，并加入预算、权限、计划校验、checkpoint 和人工确认。

第六层是多阶段 Agent。把 planner、executor、reviewer 分开，降低一个模型同时规划、执行和自我评价带来的风险。

第七层是 Agent Ops。上线后要能回放任务、评估失败类型、监控成本和循环、支持断点续跑与人工接管。

#什么时候简单 Workflow 足够

以下情况通常不需要 Agent：

• 步骤顺序固定，例如“筛选客户 -> 生成摘要 -> 人工确认 -> 创建任务”。
• 分支条件清楚，可以写成规则或状态机。
• 工具调用集合固定，不需要模型动态选择。
• 失败可以在明确节点重试。
• 输出会经过人工复核。
• 任务频率高，稳定性和可预测性比覆盖长尾更重要。

例如续费风险流程中，如果公司已经定义了明确规则：到期时间、活跃度阈值、工单数量、套餐等级和负责人分配规则，那么 Workflow + 局部模型节点通常已经足够。

#什么时候需要 Agent 工程

以下情况才值得进入 Agent 工程：

• 用户目标开放，需要系统自主拆解步骤。
• 信息来源不固定，Agent 需要决定查哪些系统。
• 工具结果会改变后续计划。
• 异常样本很多，固定分支会爆炸。
• 任务跨越较长时间，需要保存状态并恢复。
• Agent 会执行写入、通知、创建任务或修改数据。
• 团队需要知道每一步为什么发生，并能复盘失败。

此时不能只写一个“你是一个可靠 Agent”的系统提示词。需要把目标边界、工具边界、执行预算、状态持久化、确认机制、回放和 eval 一起设计。

#方案选型表

#反模式

第一种反模式：看到多步骤任务就直接做 Agent。

很多多步骤任务只是固定流程。用 Agent 会引入不必要的不确定性，让本来可以通过状态机解决的问题变成可靠性问题。

第二种反模式：把计划只放在自然语言里。

如果计划没有结构化步骤、状态、版本和完成条件，系统无法判断 Agent 是否偏离目标，也无法在失败后恢复。

第三种反模式：用 prompt 代替权限。

“不要调用高风险工具”不是边界。工具运行时必须控制哪些工具可用、哪些参数合法、哪些动作需要确认。

第四种反模式：没有循环预算。

Agent 可以不断观察、反思、再调用工具。如果没有最大步数、最大耗时、最大费用和重复调用检测，infinite loop 迟早会在线上出现。

第五种反模式：失败后整段重跑。

长任务中间可能已经创建任务、发送通知或写入备注。没有 checkpoint 和幂等，重跑会制造更多错误。

第六种反模式：只评估最终答案。

Agent 的最终答案可能看起来合理，但中间调用了错误工具、越权读取了数据或做了多余动作。Eval 必须覆盖计划、工具、状态和恢复过程。

#工程清单

• 场景边界：Agent 处理的用户、流程、输入、输出和失败代价是否明确。
• 目标控制：用户目标是否被结构化记录，是否允许 Agent 扩大范围。
• 计划状态：计划是否有步骤、状态、版本、完成条件和取消条件。
• 工具边界：工具是否按查询、写入、高风险分级，是否有 schema、权限和确认。
• 执行预算：是否限制步数、时间、token、工具次数和总费用。
• 循环检测：是否检测重复工具调用、重复观察和无进展状态。
• Checkpoint：每个关键步骤是否保存输入、输出、工具结果和副作用。
• 幂等回滚：写入动作是否有 idempotency key、撤销或补偿路径。
• 人工接管：不确定、高风险或多次失败时是否能转人工。
• 可观测性：是否记录计划、工具调用、模型版本、错误和成本。
• Eval：是否有 plan drift、tool misuse、loop 和恢复失败样本。
• 回放恢复：线上事故是否能复现，并从断点继续或安全终止。

#小结

Agent 可靠性不是一个模型能力问题，而是一个执行系统问题。

当流程固定、风险可控、分支可枚举时，Workflow 往往比 Agent 更合适。当路径动态、工具结果会改变下一步、异常样本很多时，Agent 才有价值。

一旦进入 Agent 工程，就必须把计划、工具、状态、预算、恢复和 eval 作为一套系统设计。否则 Agent 不是更聪明的自动化，而是更难复盘的不确定执行器。