AI Agent 指能够自主规划步骤、调用工具并完成任务的智能体。AgentOps，英文全称 Agent Operations，中文通常译为智能体运营，是一套面向 AI Agent 全生命周期的运营方法，覆盖目标设定、开发测试、部署上线、运行监控、效果评估、反馈迭代和权限治理。AgentOps 管理的单位，是一项任务从接收需求、规划步骤、调用工具到交付结果的全过程，关注范围超过一次模型调用。
IBM 在 AgentOps 词条 中把它描述为一种仍在初步定义阶段的新兴实践，融合了 DevOps 与 MLOps 的原则，用来管理、监控和优化智能体开发管道。这个描述说明了两点。AgentOps 目前没有唯一规范定义，不同团队的工具和流程仍在快速变化。本文讨论作为工程实践与管理方法的 AgentOps，并在后文区分同名的 AgentOps 产品。
一个实用的判断是，当 Agent 开始接触真实数据、真实系统和真实用户，AgentOps 就值得被提上日程。它回答的核心问题是，Agent 这次任务为什么成功，为什么失败，下一次怎样更稳定、更可控、更划算。
AgentOps 是什么：定义、对象与边界
把 AgentOps 拆开看，它包含三层工作。第一层是运行证据，记录 Agent 每一步做了什么。第二层是质量判断，评估任务是否完成、过程是否合规。第三层是改进机制，把失败案例变成下一轮的修复动作。三层需要一起工作。只有监控看板而没有评估与改进，AgentOps 容易变成只有日志、没有改进的监控系统。
AgentOps 的管理对象是一项任务的完整执行链。以客服 Agent 为例，一次任务可能包括识别用户意图、检索知识库、查询订单、判断退款资格、生成回复，必要时转人工。只要其中一步查错订单或误读政策，最终回复可能仍然通顺，业务结果却已经错了。AgentOps 要保留的，是这条链路上的输入、输出、耗时、成本和错误，以及人工在哪个环节接管。
AgentOps 常与 MLOps、LLMOps 一起出现。MLOps 指机器学习运营，LLMOps 指大语言模型运营，AgentOps 则把管理对象扩展到任务链。
| 维度 | AgentOps 主要关注 | 仍需配合的体系 |
|---|---|---|
| 管理单元 | 一次任务或会话的完整执行链 | LLMOps 管理单次模型调用、提示词和模型参数 |
| 运行证据 | 模型调用、工具调用、检索、子 Agent 交接、耗时、Token、错误 | APM 与基础设施监控提供服务与资源指标 |
| 质量判断 | 任务完成率、过程合规、人工接管是否合理 | MLOps 管理训练数据、模型版本和漂移 |
| 变更控制 | Agent 图、工具版本、提示词和模型路由的联动变更 | CI/CD 负责构建、测试和发布流水线 |
这张表也说明了边界。AgentOps 不替代 DevOps 和 MLOps，它在它们之上补上任务链这一层。AgentOps 也不等于买一个平台。团队可以先用手工流程和开源工具建立习惯，再决定是否引入更完整的平台。
为什么 Agent 上线后，传统监控会失效
传统应用监控通常回答三个问题：服务是否可用、请求是否变慢、接口是否报错。Agent 的问题往往不在这三个问题里。CNCF 的一篇一线实践文章把 Agent 的典型故障描述为循环、幻觉、Token 消耗失控，以及看起来合理但实际错误的结果。它们不会像程序崩溃那样留下清晰的堆栈。
第一类变化来自非确定性。同一个问题，Agent 每次的推理路径和工具调用顺序都可能不同。昨天通过的测试，今天可能因为模型版本、提示词或工具描述的变化而失败。
第二类变化来自多步执行。Agent 会规划、调用工具、观察结果、再规划。错误会沿着步骤放大，前一步查错对象，后一步就会基于错误前提继续执行。
第三类变化来自副作用。查询类工具出错只影响答案，写入类工具出错可能创建错误工单、发出错误邮件，甚至改动业务数据。
第四类变化来自成本。Token 消耗会随上下文长度、推理轮数、工具数量和重试次数波动。一次死循环可能在很短时间内消耗大量预算，而账单往往滞后于故障。
这也是 AgentOps 的一条基础原则：先保留执行证据，再讨论优化。只看最终答案，团队很难判断问题出在意图理解、知识检索、工具调用还是模型生成。只有把任务链拆开，才能定位到第一个异常步骤。
AgentOps 具体管什么：从开发到治理的五个环节
IBM 把 AgentOps 的实践分为开发、测试、监控、反馈和治理五个阶段。这个划分适合作为落地检查表。
开发：先定目标和边界
在写代码之前，团队需要明确 Agent 要完成什么任务，什么算成功，哪些工具可以调用，哪些数据可以访问，哪些动作必须人工确认。目标越模糊，后面的评估越难做。权限边界也要在这一步收敛，尤其是退款、下单、发券、改配置这类有副作用的动作。
测试：用场景验证，不只做单元测试
Agent 的测试对象不只是函数，还包括任务场景。团队可以用历史失败案例、典型用户请求和边缘情况组成评测集，在发布前跑一轮回归。测试要覆盖正常路径、工具失败、知识缺失、权限不足和需要转人工的情况。通过率只是结果，失败样本更能说明问题。
监控：看任务链，不只看接口
上线后要持续采集 Trace，观察任务成功率、耗时、Token 成本、工具失败率和循环情况。监控要能下钻到单次会话，看到每一步的输入、输出和错误。对于面向用户的 Agent，还要把用户是否继续追问、是否放弃、是否转人工纳入观察。
反馈：把失败案例变成下一轮输入
用户反馈、人工标注和线上异常都应该进入同一个问题池。团队需要给失败分类，例如意图识别错误、知识过期、工具参数错误、权限拦截、模型输出不合规。每一类问题对应不同的修复动作，修复后再用同一套评测集复测，避免改好一个场景、弄坏另一个场景。
治理：权限、审计与合规
Agent 会代表企业执行动作，治理不能只靠提示词。最小权限、敏感操作审批、全量审计日志、个人数据脱敏、提示词注入防护，都需要在系统层实现。审计日志要能回答谁在什么时间让 Agent 做了什么，Agent 调用了哪些系统，结果是什么，人工是否介入。
看一条 Agent Trace，到底看什么
Trace 是一次任务的完整执行记录。一次用户请求通常对应一个 Trace，Trace 里面的每个模型调用、工具调用、检索和子 Agent 交接都是一个 Span。Session 则把同一用户或同一工作流中的多次 Trace 串起来。
一条可用的 Trace 至少应包含以下信息：
- 任务标识：Trace ID、Session ID、环境、版本、Agent 名称。
- 模型调用：模型名称、输入提示词、输出结果、Token 用量、耗时、错误。
- 工具调用：工具名称、入参、返回结果、耗时、是否成功。
- 检索与记忆：检索到的文档、命中片段、记忆读写。
- 交接与人工：子 Agent 交接、人工接管点、审批结果。
- 成本：单步成本和整条任务成本。
Trace 用来调试，指标用来告警。CNCF 的实践文章特别提醒，不要把两者混用。告警依赖聚合指标，例如任务成功率、P95 延迟、工具失败率、单次会话成本相对滚动均值的异常。调试则要回到单条 Trace，逐层查看哪一步最先偏离预期。
指标口径要结合任务定义。客服 Agent 看一次解决率和转人工率，运营 Agent 看任务完成率和人工修改率，数据分析 Agent 看结论可复算率和追问率。统一成一个总分，容易掩盖具体问题。
图 1：一次 Agent 任务的 Trace 结构。每个节点是一个 Span，整条链路构成 Trace。
AgentOps 与 MLOps、LLMOps 怎么分
三者经常被放在一起讨论，因为它们都在解决 AI 系统上线后的可靠性问题，但管理单元不同。
| 维度 | MLOps | LLMOps | AgentOps |
|---|---|---|---|
| 主要管理对象 | 模型权重与训练数据 | 提示词、模型调用与输出 | 任务链、工具调用与 Agent 行为 |
| 执行形态 | 确定性推理 | 单次或少量模型调用 | 多步推理与工具执行 |
| 主要风险 | 数据漂移、模型衰减 | 幻觉、拒答、格式错误 | 循环、工具错误、越权、成本失控 |
| 典型证据 | 模型指标、数据版本 | 提示词版本、Token、评测结果 | Trace、Span、任务成功率、每个成功任务成本 |
| 变更对象 | 模型版本 | 提示词与模型参数 | Agent 图、工具版本、路由与权限 |
这张表描述的是典型分工，实际项目里边界会更模糊。一个 Agent 内部仍然需要 LLMOps 管理提示词和模型调用，也需要 MLOps 管理微调模型和数据。AgentOps 补的是任务链这一层，关注 Agent 如何规划、调用工具、处理异常和交付结果。
如果应用只是单轮问答，没有工具调用和业务动作，LLMOps 的很多做法已经够用。当应用开始多步执行、访问外部系统、产生业务副作用，AgentOps 的价值就会明显上升。
哪些团队现在就需要 AgentOps
可以用六个信号判断：
- Agent 会写入业务系统，而不只是查询信息。
- 一项任务需要跨多个系统或多个工具完成。
- Agent 面向外部用户，错误会带来投诉、退款或合规风险。
- 模型、提示词、工具或 Agent 图经常变更。
- Token 成本波动大，团队无法解释钱花在哪里。
- 已经出现多 Agent 协作或人工接管，责任边界开始模糊。
如果还在原型阶段，不必急着采购完整平台。先把 Trace 和评测集做起来，成本更低，也更容易形成团队习惯。一个简单的判断标准是，出现一次失败任务后，团队能否快速还原 Agent 做了什么、为什么这样做、哪一步出了错。如果答案是否定的，就说明可观测基础还不够。
另一个信号是责任归属。Agent 出错时，如果产品、算法、工程和运营团队都在等别人排查，说明缺少统一的任务证据和交接机制。AgentOps 也是组织协作方式的一部分。
从零开始，先做对这四步
第一步：选一个真实任务，定义成功与失败
从一条有业务价值的任务开始，例如客服退款初审、运营活动配置、数据异常排查。把任务拆成可观察的步骤，明确什么算完成，什么算失败，哪些动作必须人工确认。
第二步：打通一条端到端 Trace
先覆盖一个生产任务，把用户请求、模型调用、工具调用、检索、人工接管和最终结果串起来。埋点尽量采用 OpenTelemetry 等通用标准，避免绑定单一厂商。Trace 上报不能阻塞主流程，后端暂时不可用时，业务仍然要能运行。
第三步：建立一个小型评测集
从真实任务中挑选有代表性的样本，覆盖常见路径、边缘情况和已知失败。每次修改提示词、模型、工具或 Agent 图，都跑同一套评测，比较通过率和失败类型。评测集不需要一开始很大，但要持续更新，避免只覆盖老问题。
第四步：建立周度复盘和变更验证
每周挑选失败任务做复盘，定位第一个异常步骤，形成修复动作，再用同一口径复测。把高频问题沉淀为评测样本和告警规则。变更发布时，先小流量验证，再逐步扩大。
建议从以下指标开始，不必一次上全。
| 指标 | 回答的问题 |
|---|---|
| 任务成功率 | Agent 是否完成了任务目标 |
| 每个成功任务成本 | 完成一项有效工作需要多少 Token 和调用费用 |
| P95 延迟 | 大多数用户需要等待多久 |
| 工具失败率 | 外部系统和工具是否稳定 |
| 循环或重复调用率 | Agent 是否在原地打转 |
| 人工接管率 | 哪些任务仍然需要人兜底 |
| 评测回归通过率 | 本次变更是否弄坏了已有能力 |
这些指标需要和任务定义绑定，不能直接跨团队比较。客服任务的成功率与数据分析任务的成功率，口径差异很大。指标用来发现变化，团队要结合任务定义解读。
工具怎么选：先分清方法论与同名产品
搜索 AgentOps，会看到一个同名平台 AgentOps。它的官方文档把自己描述为测试、调试和部署 AI Agent 与 LLM 应用的平台，提供自动埋点、Session、Span、成本和错误记录，支持多种模型提供商和 Agent 框架。这类产品是 AgentOps 的一种落地工具，覆盖不了方法论的全部内容。
选型时可以先看六个问题：
- 是否支持团队正在使用的模型、框架和协议，尤其是 OpenTelemetry。
- 能否记录完整的任务链，而不只是模型调用。
- 是否支持离线评测、线上抽样评估和回归对比。
- 成本能否按任务、会话、租户或功能拆分。
- 是否提供权限、审批、审计和敏感数据脱敏。
- 能否私有化部署或接入现有数据平台，避免形成新的数据孤岛。
如果企业已经有 APM 或数据平台，优先看能不能把 Agent Trace 接进去。再建一套独立看板，容易让运行数据和业务数据分离，排查时还是靠人拼接。
把 AgentOps 放进企业现有栈：ThinkingAI 的一个做法
AgentOps 落地时，数据连接往往比看板更难。Agent 的一次任务会产生运行数据，用户的一次点击、追问或转化会产生行为数据。两边分开看，团队只能看到结果变差，很难判断是用户需求变化，还是意图理解、工具调用或内容生成出了偏差。
ThinkingAI 的 Agentic SDK 支持鸿蒙智能体框架 HMAF 2.0，通过 Trace 采集调用关系、执行状态、耗时和 Token 使用等结构化数据，并把 Agent 的运行过程与用户操作关联到同一会话。Agent 观测平台 AI Monitor 承接这些数据，从失败、长耗时、异常 Trace 和 Token 波动等聚合信号中发现问题，再下钻到单次 Trace，核对 Conversation、Model、Tool 与 Skill 的关键执行证据。
智能诊断会给出问题说明、相关证据和改进建议，团队完成调整后可以用相同口径复核效果。用户行为与 Agent 行为进入同一个分析上下文后，团队还可以结合 A/B 实验比较不同模型、Tool、Skill 或交互策略带来的变化。ThinkingAI 的企业级 Agent 平台支持私有化部署，这类能力可以与既有数据基础一起落地。
ThinkingAI 已服务全球超 1500 家企业，接入产品超 8000 款。这些能力说明的是企业级 Agent 平台如何承接 AgentOps 中的可观测与诊断环节，不代表 AgentOps 只有这一种实现方式。团队仍需要根据自身任务、权限和合规要求设计流程。
常见问题
AgentOps 和 LLMOps 是一回事吗？
两者有交集，但管理单元不同。LLMOps 主要管理模型调用、提示词、Token 成本和输出质量。AgentOps 管理一项任务从规划到工具执行再到结果交付的完整链路。单轮问答场景下，两者边界会比较模糊；多步 Agent 场景下，AgentOps 还需要处理工具错误、越权、循环和人工接管。
AgentOps 是一个工具吗？
AgentOps 是一套实践和方法，工具是它的载体。团队可以用开源库、商业平台或自建系统实现，也可以先用手工流程和现有可观测设施起步。判断标准在于能否持续获得任务证据、评估质量和推动改进，买了某个产品并不等于完成 AgentOps。
小团队需要 AgentOps 吗？
看 Agent 是否进入真实业务。如果只是内部试用、单轮问答、没有写入动作，可以先从轻量 Trace 和失败记录开始。如果 Agent 已经面向用户、调用多个工具或产生业务副作用，即使团队很小，也需要基本的任务追踪、评测和权限控制。
AgentOps 最先该看哪些指标？
先看任务成功率、每个成功任务成本、工具失败率和人工接管率。这四个指标分别回答任务有没有完成、成本是否合理、外部依赖是否稳定、哪些环节还需要人兜底。等基础数据稳定后，再补充延迟、循环率和评测回归通过率。
AgentOps 和 APM 有什么区别？
APM 指应用性能监控，关注服务可用性、接口耗时和错误率，AgentOps 关注任务链上的决策与动作。APM 能告诉你接口返回了 200，AgentOps 还要告诉你这次调用是否必要、参数是否正确、结果是否被正确使用。两者可以共用 Trace 基础设施，但观测对象和分析口径不同。
没有生产流量，怎么做评估？
用历史工单、人工编写的典型任务和已知失败案例组成离线评测集。让 Agent 在模拟环境中执行，记录每一步的输入、输出和工具结果，再按任务完成、过程合规、成本和时间评分。上线后再用真实流量抽样补充评测集。
参考资料
- IBM，什么是 AgentOps？，检索于 2026 年 11 月 6 日。
- CNCF，You can't debug what you can't see — Observability for AI Agents，2026 年 8 月 4 日。
- AgentOps 官方文档，Introduction。
- AgentOps 官方文档，Core Concepts。
