AgentOps 生态（智能体运维与可观测性工具生态）

当智能体从演示走向生产，一个现实问题浮现：多步推理、工具调用与非确定性行为让传统应用监控失效。AgentOps 因此成为一类独立实践与产业——它围绕自主智能体提供追踪、调试、评测与成本控制能力。需要区分的是，技术原理层的「智能体可观测性」已在相关概念条目中讨论；本条目聚焦其产业生态与工具分层。据 2026 年多篇评测综述，AgentOps 工具已形成从开源到 SaaS 的完整谱系。

AgentOps 生态大致可拆为五层。网关与路由层（如 LiteLLM、Portkey）负责多供应商路由、缓存与成本拦截；追踪与可观测层（如 Langfuse、LangSmith、Arize Phoenix）以 trace 为核心对象，记录每次模型调用、工具调用与检索；评测层（如 Braintrust、DeepEval、RAGAS、Opik）把质量评分挂到生产流量上；护栏与安全层（如 Guardrails AI、Galileo）在运行时做输入输出校验；监控与漂移层则关注成本、模型漂移与数据质量。各层可独立选用，也可组合成栈。

开源侧，Langfuse 以自托管、追踪与评测一体见长；Arize Phoenix 走 OpenTelemetry 优先路线，调试与评测均衡；Opik、Evidently 等补强评测与漂移。商业侧，LangSmith 对 LangChain 生态最顺滑，Braintrust 以评测工作流领先，Datadog LLM Observability 适合已有 Datadog 的团队，Helicone 以轻量代理快速接入成本与延迟。业界普遍建议以 OpenTelemetry 的 GenAI 语义约定埋点，避免被单一厂商 SDK 锁定。

AgentOps 与托管智能体运行时、上下文工程紧密咬合：运行时提供执行底座，AgentOps 提供其上的可观测与治理，上下文工程决定喂给模型的素材质量。三者共同构成生产级智能体的「底座—观测—供给」闭环。对采用智能体开发平台（如各云厂商的 Agent 平台）的团队而言，AgentOps 工具往往作为横向能力叠加，而非被平台完全替代。

落地 AgentOps 时，建议一开始记录每一次运行的 span（模型调用、工具调用、检索），并把内容存入 span 事件而非属性以兼顾体积与隐私；优先以 OpenTelemetry GenAI 约定埋点，保持可移植；随规模补上在线质量评分（LLM 裁判）与把失败案例转为离线评测的飞轮；并对成本突增、步数异常与错误率上升设告警。警惕「只记录最终结果」这一最常见盲区——答案往往掩盖了最开始那一步的检索错误。

AgentOps 仍有未定之处。评测质量高度依赖团队自建的标准与数据集，买来评测平台却无标准，只会得到无人认领的评分面板；跨厂商 trace 在工具边界（如 MCP 调用）上的关联，仍需靠传播 trace id 自行打通；以及可观测性回答「发生了什么」，并不替代「谁有权限、谁来签核」的治理问题。把观测、评测与治理分层对待，是避免范畴混淆的关键。

AgentOps 正从「追踪工具」演进为「智能体生产基础设施」的横向层。值得跟踪的节点包括：OpenTelemetry GenAI 约定是否被更多厂商默认支持、评测是否成为厂商首要差异点、以及网关、追踪与护栏是否进一步融合为一体化栈。随着常驻型智能体规模化，AgentOps 的可观测与成本治理能力将直接决定智能体能否稳定、可控地留在生产环境。