很多团队已经把 AI agent 放进了生产环境。
问题往往不在于“它能不能跑起来”，而在于另一件更麻烦的事：出了结果之后，我们能不能说清楚它到底做了什么、为什么这样做、这样做是否合规、成本是多少，以及哪里正在悄悄变坏。
这正是 AgentOps 想解决的问题。它关心的不是 agent 的演示效果，而是 agent 一旦开始调用真实系统、处理真实数据、影响真实业务结果之后，团队如何建立可见性、判断力和控制力。
把风险摆在“聪明”之前
在许多演示（Demo）中，我们习惯于展示 Agent 如何“聪明”地解决问题。但在生产环境下，风险才是第一位的。
一个 AI agent 可能审批了一张处方，也可能拒掉了一张处方。但如果团队连它到底是基于什么证据做的决策都说不清，这就不是简单的产品体验问题，而是严重的合规与责任风险。
以医疗领域的 Prior Authorization（预授权） 为例：患者需要特殊药物，医生开了处方，但药房不能直接发药，必须等保险公司批准。传统流程极其漫长（3-5 个工作日），充斥着电话、传真和补件。这非常适合 Agent 自动化，但由于涉及敏感数据和关键决策，一旦 Agent 出现“幻觉”或流程失控，后果是无法承受的。
Agent 到底在做什么？从文本输出到工具调用
在典型的 Prior Authorization 场景中，通常是一个 双 Agent 工作流：
- Clinical Documentation Agent：连接 EHR（电子病历）系统，拉取诊断代码、化验结果和治疗记录。
- Payer Authorization Agent：负责提交材料到保险公司 Portal、轮询状态、处理补件请求并通知结果。
从功能上看，这已经超出了“单纯输出文本”的范畴。Agent 在调用 API、访问外部 record、跨步骤推进任务并在多 Agent 之间传递上下文。正如微软和 LangChain 关于生产级 Agent 的定义：Agent 不只是会回答问题，而是会 Open tickets、Update records、Make decisions。12
传统的代码报错（500 错误、超时）在 Agent 系统中只是冰山一角。更难搞的是“逻辑成功但行为偏离”：
- 幻觉出错误的诊断代码。
- 在多 Agent 协作中丢失关键上下文。
- 陷入无限重试循环导致 API 费用失控。
AgentOps 三层架构：顺序不可逆
AgentOps（Agent Operations）的核心思想是把 Agent 作为一个持续运行的系统来管理。这套框架通常由三层组成，且顺序至关重要：
Observability (看见) → Evaluation (衡量) → Optimization (改进) 你必须先看见发生了什么，才谈得上衡量好坏；有了衡量标准，优化才不会沦为“盲目调优”。
第一层：Observability（可观测性）
可观测性不只是多打日志，而是要能完整重建一次任务路径。
在 Agent 系统中，我们特别关注以下指标：
- End-to-End Trace Duration：用户发起请求到拿到结果的总时长。
- Agent-to-Agent Handoff Latency：多 Agent 协作中的交接延迟。很多时候，瓶颈不在模型调用，而在任务交接和上下文整理。
- Cost per Request：单次请求的 Token 消耗和工具调用成本。
传统监控会告诉你 API 返回了 200，但 AgentOps 需要告诉你：虽然返回了 200，但检索到的文档是否全是噪音？Agent 是否基于错误前提执行了后续步骤？
第二层：Evaluation（评估）
“看见”之后，我们需要判断 Agent 做得对不对。
- Task Completion Rate：有多少请求最终完成了，且不需要人工接管。
- Guardrail Violation Rate：Agent 尝试越界（如泄露隐私或给出非法建议）的频率。
- Factual Accuracy Rate：事实性内容（如诊断代码、药名）的正确率。
在医疗这类高风险领域，评估通常包含两个特定维度：
- Clinical Appropriateness：由专业药师人工审核 5% 的样本，确保结论符合临床逻辑。
- First Pass Approval Rate：第一次提交即获获批的比例。这直接衡量了 Agent 的动作是否真的有效减少了往返补件。3
第三层：Optimization（优化）
当有了明确的观测和评估基准，优化才变得有据可依。
- Prompt Token Efficiency：在保证质量的前提下，通过压缩 Prompt 降低成本。
- Retrieval Precision at K：优化 RAG，确保喂给模型的前几项文档是高度相关的。
- Handoff Success Rate：提升多 Agent 协作的稳定性。
避开“Demo 陷阱”：证据驱动的管理
很多团队在初期会过度关注 Prompt 怎么写得漂亮，但这往往想简单了。
生产级 Agent 的失败通常不是因为某一轮回答不够好，而是整个链路累积的偏差。一次 Hand-off 丢了字段、一次检索混进噪音、一次外部系统震荡导致重试失控——这些问题只有在建立了完整的 AgentOps 机制后才能被捕捉。
出了问题时，你能否回答：它做了什么？为什么这样做？是否应该这样做？花了多少钱？哪些失败会影响核心用户？
落地挑战与工程责任
虽然三层架构提供了方向，但在落地时仍有大量硬核细节需要填补：
- Guardrail 的实现：是靠策略模型拦阻，还是靠规则引擎？在医疗场景下，PHI（患者隐私数据）脱敏是 Trace 系统必须解决的前提。
- 长链路的幂等性：外部 Portal 超时时，Agent 的重试是否会制造冗余 record？
- 基准的可验证性：没有稳定的 Factual Baseline，准确率就只能是印象分。
结语：从“看起来能跑”到“证明它在工作”
AgentOps 并不是多加了一个仪表盘，而是多了一层 生产责任。
当 AI 已经开始影响真实业务结果时，团队需要的不只是一个能干活的 Agent，而是一套能解释行为、限制风险并在可见证据下持续进化的运行机制。
AgentOps 让我们从“它大概没问题”转变为“我们知道它为什么没问题，并且知道如果出问题了该去哪里修”。