Agent 上线之后的日常运维要盯什么
数据截至 2026-07，各项目能力以官方文档当前版本为准。
Agent 上线之后最常见的事故形态，不是”它答错了”，而是”它跑通了，但跑歪了，而且没人发现”。所以日常运维真正要盯的，从来不是准确率这一个数字，而是六件更朴素的事：每一次运行有没有留下可回放的轨迹、工具调用的失败率有没有抬头、单次任务的花费有没有悄悄翻倍、循环有没有刹车、依赖的框架是不是还在积极维护、出事时人能不能立刻插进去。
先承认一个很普遍的误解：不少团队把 Agent 的运维当成传统 Web 服务的运维来做，盯 CPU、盯内存、盯 5xx 错误率。这几项当然要盯，但它们几乎抓不到 Agent 的典型故障。Agent 出问题时，HTTP 状态码通常是 200，进程也没崩，日志里满是”成功”——只是它把一个本该三步做完的任务绕了十七步，或者拿着一份过期的检索结果一本正经地写完了报告。这类故障在监控面板上是安静的，只有账单和用户投诉会替你报警，而那时候已经晚了。
一、没有完整轨迹，就谈不上运维
Agent 运维的第一块地基是可回放：拿到一个出问题的会话 ID，你能不能把它当时的每一步原样调出来——收到了什么输入、状态里存了什么、调用了哪个工具、工具返回了什么、模型基于这些又决定做什么。
这件事要在上线前就设计好，因为事后补不回来。具体要落地的做法：
- 给每次任务分配一个贯穿全链路的 run_id，模型调用、工具调用、检索请求、写库操作全部带上它。排查时只要有这一个 ID，就能把散在各处的日志串成一条线。
- 状态要落盘，不能只活在内存里。进程重启、机器换节点、任务跑到一半被打断，内存里的执行进度就全没了。
- 工具的入参和返回值都要存，而且要存原样的那份，不是模型转述过的那份。事后你会发现，大量”模型胡说”其实是工具返回了一坨畸形数据，模型只是照着编了下去。
- 只存摘要不存原文的做法要谨慎。省存储是真的，但等你需要复现一个偶发问题时，摘要基本没用。折中办法是原文短期保留、摘要长期保留。
从工具层面看，几家多智能体框架在这块的成熟度确实有差别。按 2026 年若干第三方实战对比的口径，LangGraph 在执行流控制上更精细，内置了 checkpointing、streaming 和 human-in-the-loop 这几类原语，支持可持久化的长时运行工作流，在”生产成熟度”这一项上被排在最前；CrewAI 在 2025 年补上了 Flows 这种事件驱动的 pipeline 模式，面向更可预测的生产型负载——不少较早的对比文章没覆盖这一条，所以”CrewAI 只适合做原型”这个旧结论现在不宜照搬。需要说明的是，上面这些是第三方对比的说法，各框架具体提供哪些能力、怎么配置，以各项目官方文档当前版本为准。
二、把工具调用的失败率单独拉出来看
模型这一层的健康度大家都会看，工具那一层反而经常被合并进”总体成功率”里稀释掉。但实际运行中，Agent 的绝大多数不稳定来自工具：第三方接口限流、内部服务改了字段名、数据库超时、爬取的页面改了结构。
建议单独建一张按工具维度拆开的表，每个工具至少盯三列：调用次数、失败次数、平均耗时。然后看两种变化：
一是某个工具的失败率单独抬头，其他工具没事。这基本就是那个上游出问题了，跟模型无关，去找对应的服务方。
二是调用次数异常增长而任务量没变。这是更值得警惕的信号，说明 Agent 开始反复重试同一个工具，或者陷入了”调工具—结果不满意—再调”的来回。它不报错，但成本和延迟都在涨。
阈值定多少？这里不给通用数字，因为它完全取决于你的业务。可行的做法是上线第一周先什么都不报警，只采集，把这一周的数值当基线，第二周再按基线的偏离幅度设阈值。任何从文章里抄来的绝对阈值，对你的系统都是瞎猜。
三、成本要按”每次任务”看，不是按天看
按天看账单是运维 Agent 最容易踩的坑：任务量本来就在涨，账单跟着涨看起来完全合理，等你发现异常时，单位成本可能已经翻了几倍。
正确的口径是单次任务的平均 token 消耗，并且拆成输入和输出两列分开看。这个数字应该是相对稳定的，一旦它开始漂移，多半对应下面几种情况：
- 上下文没有裁剪，历史越滚越长，每一轮都把前面所有内容重新发一遍；
- 工具返回的大段原始数据被原样塞回了模型；
- 提示词改版之后系统提示变长了，而它每一轮都要重发；
- 多智能体之间的对话回合数变多了。
最后一条尤其值得注意。多个 agent 互相交谈的架构，回合数是成本的乘数——同样一个任务，来回商量五轮和商量两轮，差的不是一点。第三方对比里给出的排序是 LangGraph 的 token 效率最好、AutoGen 的开销最大，这个结论来自某次实测对比，不同任务上的表现未必一致，但它至少提示一件事：架构选择本身就是成本决策，不只是开发体验决策。
关于成本的更细拆解，可以看 Agent 跑着跑着账单失控：几个常见原因。
四、循环必须有刹车，而且要有人替它踩
Agent 最贵的一类故障是停不下来：判断条件写得含糊，模型每次都觉得”还差一点”，于是一直转，直到额度耗尽或者有人手动杀掉。
三道刹车建议都装上，它们的失效模式不同，不能互相替代：
- 步数上限。硬性规定一次任务最多执行多少步，到了就中止并告警。这是最粗但最可靠的一道。
- 成本上限。单次任务累计消耗超过某个值就中止。步数少但每步都很贵的情况，只有这道拦得住。
- 无进展检测。连续若干步的状态没有实质变化（比如反复调用同一个工具、参数都一样），判定为原地打转直接中止。前两道都是等它撞墙，这一道能早一点发现。
带反馈环的循环任务在框架层面的支持差别也不小。第三方对比里的说法是这类场景 LangGraph 更占优，CrewAI 技术上支持循环但调试起来比较痛苦——调试成本在运维阶段会被放大，因为线上出问题时你没有慢慢试的时间。
延伸阅读：Agent 失败了怎么重试？ 和 长时运行的 Agent 怎么做断点续跑。
五、上游框架的维护状态，也是一项运维指标
这一条经常被漏掉：你依赖的框架本身在不在积极维护，是需要定期回看的运维项，而不是选型时看一眼就完事的事情。
一个当前很典型的例子是 AutoGen。微软已经把重心转到了范围更大的 Agent Framework，AutoGen 的主要新功能开发停止了，进入维护模式——仍然有 bug 修复和安全补丁，社区里也已经有人在找替代方案。有实践者的判断是 2026 年不宜再把它作为新项目的起点。这里要说清楚分寸：这不等于”它死了”，存量项目不必恐慌迁移，安全补丁还在。但如果你正在这上面持续加功能，那你需要知道往后新特性大概率要自己实现。
日常该怎么盯：给关键依赖排一个季度性的回看，看仓库最近的提交频率、issue 的响应情况、有没有官方发布过路线图或迁移说明。变更成本最低的时候是”还没出事但已经看到信号”的时候。
顺带说一句互操作性。协议层面的支持也在动：CrewAI 已经加入了 A2A 支持；OpenAgents 声称自己是唯一原生同时支持 MCP 与 A2A 的框架——“声称”这两个字要保留，这条未经独立核实。如果你的系统要跨框架协作，这类能力的变动同样值得纳入季度回看。
框架之间的横向差别可以看 主流 AI Agent 框架对比。
六、人工接管的开关，平时就要能按
自动化程度越高，出事时”插不进手”的代价越大。上线前应该准备好三个动作，并且确认它们在生产环境真的能执行：
- 暂停：让某个正在跑的任务停在当前步，不销毁状态，等人看完再决定继续还是终止。
- 改写后继续：人工修正状态里的某个字段，然后从当前步接着往下跑，而不是整个任务重来。
- 全局降级：一键把 Agent 切成”只给建议不执行动作”的模式。上游模型抽风、工具大面积失败的时候，这个开关比逐个排查值钱得多。
这些能力在框架层面有的提供了原语（前面提到 LangGraph 内置了 human-in-the-loop 相关原语），有的需要自己在应用层实现。无论走哪条路，关键是上线前演练一次——只在文档里存在的应急开关，出事时按不下去。
具体的介入点设计可以看 Agent 里的人工介入怎么设计。
七、说说局限：你可能根本不需要这么重的运维
前面六节默认了一个前提：你跑的是一套多 agent、多工具、带循环的系统。如果不是，这些东西大部分可以砍掉。
有一条反直觉但重要的提醒：单个 agent 只调一两个工具时，OpenAI Agents SDK 或 Anthropic Claude Agent SDK 往往是更快的路径，你可能根本不需要多智能体框架。相应地，运维负担也小很多——没有 agent 间对话就没有回合数爆炸，工具少就没必要建那张按工具拆分的表，链路短了轨迹回放也简单得多。
判断标准很朴素：如果你的系统里从来没有出现过”两个 agent 商量”的场景，也没有真正的分支和循环，那把它拆成多智能体架构，多出来的复杂度全部由你自己承担，收益却不明显。选型这一步可以看 Agent SDK 和多智能体框架怎么选。
还要诚实说一句本文的边界：文中关于各框架能力强弱的排序，来自 2026 年的若干第三方实战对比，不是一手官方文档的逐条核实，也没有可交叉验证的公开基准。它们适合用来提示”该往哪个方向做验证”，不适合直接当作选型结论。真正可靠的做法，是拿你自己的两三个典型任务各跑一遍，用自己的数字说话。
小结
Agent 运维的核心是把”看不见”变成”看得见”：先有贯穿全链路的执行轨迹，再有按工具拆开的失败率，再有按单次任务算的成本。循环必须装步数、成本、无进展这三道刹车，缺一道就可能烧到额度见底。依赖框架的维护状态要定期回看，AutoGen 转入维护模式就是提醒——选型不是一次性决定。人工接管的开关要在上线前演练过，不能只写在文档里。最后，如果你的场景只是单 agent 加一两个工具，别急着上重型架构，运维成本是要天天还的。