做 Agent 相关项目这两年我见过太多团队在同一个地方栽跟头Agent 跑得不稳定第一反应就是上监控把调用链、token、时延全部可视化然后宣布自己已经具备 AgentOps 能力。但真实情况是监控只是 AgentOps 最表层的一层皮。AgentOps 不是在给工作流加监控而是给 Agent 配一套可运营的运行时。这套运行时要解决的不只是它挂了你怎么知道更是挂了怎么恢复、怎么召回、怎么演进、怎么控制成本、怎么保证安全。这篇文章我打算把我在实际项目中搭建 AgentOps 的完整思路和踩坑记录整理出来给正在从能跑走向能运营的团队做一份参考。1. 先搞明白Agent 不是加了循环的工作流1.1 工作流的本质是确定性编排工作流是工程师画出的一条固定赛道节点 A 执行完进入节点 BB 的结果不满足条件就走分支 C每个分支都事先定义好了。n8n、Coze、Dify 里搭出来的工作流本质上都在做这件事。确定性带来的收益是可控任何一个时间点你都知道 Agent 或者说这个流程走到哪了、下一步该干嘛、出了问题该回滚到哪个节点。传统监控系统按这个模型来设计完全没有问题因为系统预期是固定的只需盯住几个固定的指标响应时间、错误率、吞吐量。1.2 Agent 的本质是不确定性探索Agent 不是工作流的升级版它的内核是自主决策。模型根据自己的理解决定调用哪个工具、按照什么顺序调用、在什么条件下终止。同一段 Prompt同一个用户请求跑十次可能得到十条不同的工具调用路径。有一个实验数据我记得很清楚同一个 Agent 在 20 次调用中实际产生的工具调用序列有 8 种变体占比最高的路径也才 35%。这种不确定性才是 Agent 的威力所在因为复杂任务没法预先把所有路径画出来。但不确定性也意味着固定的工作流监控模型本身就不适用了。工作流出现异常你能对照流程图精确排查Agent 出现异常你连本次执行到底做了几轮工具调用这种基本信息不做额外埋点都拿不到。1.3 监控在 Agent 场景为什么会失灵监控系统的典型响应路径是指标异常 - 定位节点 - 回滚或修复。这个路径默认所有异常都能被预先定义。Agent 场景下真正致命的往往不是服务崩溃而是看起来正常实际结果错得离谱。比如 Agent 没有调用检索工具直接依靠幻觉回答了用户问题状态码 200耗时正常传统监控完全无感。所以在 Agent 场景监控失灵不是因为它流量不够、日志不全而是因为监控默认的确定性目标不存在了。你没办法设定第 3 步必须调用搜索工具这种普适规则因为不同请求的路径天然不同。我们需要换一套思路从盯指标转向盯行为、盯过程、盯结果。2. 可运营的运行时长什么样七个关键能力2.1 全链路可观测从一次会话到一次工具调用可观测这个词被用烂了但在 Agent 场景下它有一个明确的实现标准一次用户请求要能完整还原出模型决策链。包括模型收到的完整上下文、调用工具时的入参与返回值、工具报错后模型如何修正、每一轮 LLM 调用的 token 消耗、耗时分布。不是记录一张链路图而是把每一次 Agent 的试错过程都记录下来。我见过不少团队用 LangSmith 接上 trace 就以为完成了可观测实际上只记录到了 LLM 调用那一层工具参数、Agent 内部状态变更全部丢失排障时只能靠猜。2.2 状态与记忆管理让 Agent断电重启还能继续干活工作流是无状态的执行完就完了顶多存一下结果。Agent 不一样它有会话记忆、有子任务状态、有累积的上下文。训练一个 Agent 你来晚了它聊到一半崩溃了恢复之后用户继续对话Agent 却完全不记得刚才聊了什么这就是状态管理缺位的典型表现。一个可运营的运行时必须能把 Agent 的关键状态定期快照崩溃后自动恢复甚至在 Agent 被备份到新环境时也能把记忆迁移过去。2.3 评估与回归体系给 Agent 做性格测试监控可以告诉你坏了评估体系回答的是它够不够好。对 Agent 团队来说核心资产不是代码而是 Prompt、工具描述、评估集。没有评估体系你根本不敢改 Prompt——你无法判断这版改动是变好了还是变差了。业界现在的通用做法是建回归集收集一批有代表性的真实请求每个请求配上期望结果或关键断言指标每次改动后跑一遍全量回归集对比分数。这相当于给 Agent 做性格测试每次版本迭代都要验证性格有没有偏离预期。2.4 成本与配额控制Agent 的钱花在哪必须能算清传统服务的主成本是服务器Agent 的主成本是模型调用。一个 Agent 一次任务可能调用几十次 LLM逐轮累计。更麻烦的是Agent 可能因为工具调用失败而陷入重试循环一次任务烧掉平时十倍的成本。没有成本视角的运行时等于在开一架没有油表的飞机。我见过真实案例一个教程 Demo 忘加退出条件Agent 在死循环里连续调用了两百多次外部 API跑了一个多小时才熔断账单金额高得离谱。2.5 安全与合规边界指令注入不是新鲜事Agent 的能力边界越大安全压力越大。工作流的安全主要是接口鉴权Agent 的安全多了一层工具调用暴露面。用户通过 Prompt 注入操纵 Agent 调用危险工具、泄露内部上下文、越权读取其他用户数据这是 Agent 独有的攻击向量。可运营的运行时必须对工具调用做白名单控制、对敏感信息做脱敏、对异常调用模式做熔断并且每一次工具调用都要有审计日志。2.6 灰度与回滚Agent 版本如何发布传统服务发布失败回滚代码就行。Agent 发布失败问题更复杂。你回滚了系统代码Prompt 却已经改过了数据也已经跑过了用户看到的行为已经发生了变化。Agent 的版本不只是服务代码还是模型配置、Prompt、工具描述、知识库索引的组合体。可运营的运行时要把这些产物打包成统一版本号做好影子发布、灰度比例、一键回滚。回滚的对象不是一个镜像而是整组配置和逻辑。2.7 数据闭环生产数据不能只躺在日志里AgentOps 和别的运维体系最大的不同在于它不应该只是消耗资源的维护体系而应该是反哺效果的能力引擎。生产环境每一次成功或失败的用户交互都是改进 Agent 的样本。可运营的运行时要把失败样本自动抽取、归因、打标、回流到评估集形成线上运行-发现失败-积累样本-改进模型或 Prompt-回归验证-发布上线的飞轮。没有这个闭环AgentOps 就只是高级监控离可运营差着十万八千里。3. 从 0 到 1 搭建 AgentOps 的实操记录3.1 技术选型别一上来就上重家伙很多团队听到 AgentOps 就往 LangSmith、Langfuse 这类工具上靠这不坏但得先想清楚自己的体量和阶段。我根据自己用过和调研过的方案给你一张选型参考表方案类型适合场景上手成本说明LangSmith托管 SaaS深度使用 LangChain/LangGraph需要全功能中功能齐全但按量计费数据出境你要自己想清楚Langfuse开源自托管数据敏感、要自控、需要生产级中高开源组件齐全自带初步 eval 与 prompt 版本能力Arize Phoenix开源轻量本地研究、小流量、快速验证低适合已经用 OpenTelemetry 的团队Helicone代理网关层不想改代码只想先看指标低通过代理拦截快速见到效果但深度能力有限自研轻量方案代码内埋点定制化极强、研发团队有精力高推荐有 1 个专用人力时再做我的建议是如果团队还没到 10 万次调用量先用开源自托管方案把数据握在自己手里等规模上来再考虑商业化产品或自研整合。重点不是工具选得多炫而是跑通链路、凌晨三点有告警能定位问题。3.2 埋点与链路规范trace 要可读、可过滤、可检索工具定了接下来是最脏最累的活埋点。这里我强烈建议用统一规范而不是到处随意添加日志。实际项目中我们按这种结构来做埋点顶层 Span一次用户会话带 user_id、session_id、intent 标签中间 Span一次 Agent 决策循环记录状态快照、当前步骤子 Span每次 LLM 调用、每次工具调用记录 model、prompt、output、token 数、工具入参和出参关键一点tag 一定要规范。我们规定所有 Span 必须带 env环境、service服务名、session_id、agent_type 四个标签没有这些标签的 Span 直接视为无效数据。刚开始会觉得繁琐但一个月后你就明白这是救命的设计没有 tag 的 trace 是一个一个翻有 tag 的 trace 是一把一把筛。3.3 Eval 集与回归任务第一步先积累 100 条样本Eval 集是 AgentOps 里面最容易被跳过、但又最不能跳过的东西。很多团队觉得评估不是有 LLM-as-judge 嘛直接让大模型打分不就行了。实际用下来会发现Judge 模型本身就不可靠没有一把可靠的标尺你无法判断它是 Agent 的问题还是裁判的问题。我们当时的落地流程是这样的先人工积累 100 条真实生产样本每条标注好预期工具调用序列预期答案关键点禁止出现的错误类型。然后跑一个最小回归脚本每次改 Prompt 或调工具就把这 100 条样本跑一遍核对三类指标任务完成率最终输出是否达到预期目标工具调用合规率是否调用了不该调用的工具顺序是否合理每任务成本平均模型调用次数有没有突增这套回来之后再做 Agent 行为聚类通过线上 trace 把 Agent 的典型路径聚类成若干行为簇每个簇单独统计完成率和成本。这样能发现很多隐藏问题比如某种类型对话老是重试。3.4 成本画像按 session 拆分 token 与预算聊到成本不能只看总量。没有画像的成本数据毫无决策价值。我们把成本按四个维度做聚合维 度拆 分 方 式用 途按 Agent 类型不同类型 Agent 分开算发现哪个 Agent 是成本黑洞按 session 长度短会话 vs 长会话长会话成本随轮次爆炸式增长按失败类型成功 vs 失败任务很多失败任务比成功任务更烧钱按模型层主模型 vs 工具提取 vs judge评估模型的 token 成本占比是否过高我们在实际中加了一个简单的报警规则单次 session 成本超过历史中位数的 5 倍立刻告警。这个规则抓到过好几例因为工具报错导致的重试风暴。4. AgentOps 落地中的常见坑与排查记录4.1 trace 对不齐99% 是异步没闭环Agent 系统大量使用异步编排子任务并发执行。你经常会看到 trace 图里一个 Span 孤零零挂着没有任何父子关系。排查后发现代码里用了 async/await 但 trace context 没有正确传递子任务变成了孤儿 Span。解决办法统一用 OpenTelemetry 的 Context Propagation在发起异步任务时手动传递上下文对象不要依赖隐式传递。另外每个 Agent 循环都要在入口显式注入 trace_id否则 trace 会断在每一轮循环之间。4.2 告警噪音太大先学会计数而不是设阈值我见过团队在第一天配了十几条告警第一天晚上告警风暴就来了第二天他们默默把告警全关了。这是 AgentOps 最容易翻车的地方。Agent 的指标天然方差大一次性请求可能调用 2 次模型也可能调用 20 次固定阈值根本不适用。更靠谱的做法是看分布和趋势不要设绝对值阈值。我们后来用滑动窗口统计 P90/P95 成本与轮次只对窗口内持续恶化发告警。对成功率则使用环比下降比例而非绝对阈值。告警不在于多每条告警必须附带一条可见的 trace 跳转链接否则排查成本巨大。一条没有 trace 的告警资历再老的工程师也只能干瞪眼。4.3 回滚比发布难状态没办法跟着代码走Agent 上线后模型会在用户真实数据上产生新的记忆状态。代码回滚到上一版但状态回滚不了。用户已经看到的行为、已经产生的对话内容抹不掉。更麻烦的是Prompt 回滚和代码回滚节奏不一致代码在 v2.1、Prompt 在 v1.8排查问题都不知道先看哪一版。我们后来做的做法是版本号全局化模型名、Prompt 内容、工具描述、代码 commit全部打同一个 release tag。回滚必须整体回滚到同一个 tag不允许代码和 Prompt 错位。这个规范一开始会推得艰难但经历过一次代码新、Prompt 旧的混乱之后团队所有人都会主动遵守。4.4 常见问题速查表现象可能原因排查步骤trace 断链异步上下文丢失检查是否显式传递 Context检查是否用同一 exporter 实例成本突增工具连续失败造成重试循环按 session 聚合成本过滤失败任务查看循环轨迹Eval 分数忽高忽低Judge 模型换版本或温度过高固定 judge 模型和参数多次采样取均值回滚后行为仍旧异常提示词版本未随代码一起回滚核对 release tag 是否包含 Prompt 版本Agent 重复同一个错误工具工具返回错误格式Agent 不理解检查工具出错的错误信息是否足够结构化5. 最后说点我自己的体感我自己经历这个过程下来最大的感受是AgentOps 与其说是一套技术方案不如说是一套工程纪律。工具选得再好埋点规范不执行等于白搭评估集再完整发布流程不绑定版本号等于空转。Agent 最大的特点是不可控而 AgentOps 的价值并不是把它变成可控的——你不可能让 Agent 变得和传统程序一样确定你能做的是让每一个不可控的行为都有记录、有归因、有止损、有改进。如果你们团队的项目还处在给 Agent 加日志、加监控的阶段我建议下一步不要继续堆指标了停下来画一张能力地图把状态管理、灰度回滚、评估回归这三块先补上。这套运行时补齐之后Agent 才能真正放在生产环境里放心运营。最后再分享一个小经验搭建 AgentOps 不要追求一步到位先把每次会话全部可溯源这一个目标做到极致比急着上十三个系统都管用。