Agent 上线 Checklist 实战：评测门禁、可观测性埋点与 AgentOps 落地（附可运行代码）一个反直觉的

本周主题「AI Agent 从 Demo 到生产」Day 5 收官。前四天聊了范式、成本、工具基建、治理安全，今天解决最后一个问题：怎么判断 Agent 能不能上线，上线之后怎么持续盯着它。

一、为什么传统监控对 Agent 失效

一个反直觉的事实：你的 Agent 可以每一步都返回 HTTP 200，但答案依然是错的。腾讯云本周上线 Agent 可观测服务时给出的数据：仅凭状态码判断，将漏掉近半的真实异常。原因很简单——Agent 的失败发生在语义层，不在传输层。

传统 APM 的观测单位是"请求"，Agent 的观测单位必须是"任务全程"：一次用户请求背后是数十次模型调用、多次工具执行、多轮推理循环。缺了任何一环的 trace，故障复盘就是考古。

本周可观测赛道四连发（OpenObserve v1.0、AWS CloudWatch Omni、腾讯云、Snowflake），赛道判断一致：Agent 生产化的瓶颈已从模型能力转移到运行时治理。选型五项必备能力：

端到端 trace 拼接（LLM 调用 + 工具 + 检索 + 人工审批）
prompt 捕获 + PII 脱敏
漂移检测（行为偏离 golden path 超 2σ 告警）
token/工具级成本归因（死循环曾致云账单 12 倍暴涨）
评测集成（trace 回放进离线评测）

二、评测即门禁：让 CI 阻断错误的合并

本周最硬核的观点来自对 OpenAI 7 月评测环境事故复盘的分析：沙箱负责强制执行，评测负责验证行为。其中 4 项验证（网络出口、文件边界、工具权限、审批门禁）可直接复用沙箱已有事件，3 项（干净恢复、密钥不泄露、trace 可重建）需要专门写测试。

对业务团队，落到 CI 只有两条硬要求：

工具调用正确性要在 CI 里断言，失败即非零退出；
trace 查看器只能"看"不能"拦"——拦不住合并的观测体系等于没有。

可运行代码 1：DeepEval 工具调用正确性门禁

# test_agent_gate.py
# pip install deepeval pytest
from deepeval import assert_test
from deepeval.test_case import LLMTestCase
from deepeval.metrics import ToolCorrectnessMetric

# 期望轨迹：报销 Agent 处理一张超标发票应依次调用这些工具
expected_tools = ["read_invoice", "check_budget", "request_approval"]

test_case = LLMTestCase(
    input="帮我报销这张 5000 元的发票",
    actual_output="已提交审批，等待主管确认",
    # 从真实 trace 中提取的工具调用序列（生产回放或集成测试产出）
    tools_called=["read_invoice", "check_budget"],  # 缺了 request_approval！
    expected_tools=expected_tools,
)

# any_of=False：要求调用序列严格匹配期望列表
metric = ToolCorrectnessMetric(threshold=1.0, any_of=False, include_reason=True)
assert_test(test_case, [metric])  # 失败 -> pytest 非零退出 -> CI 阻断合并

对应 GitHub Actions：

# .github/workflows/agent-eval-gate.yml
name: agent-eval-gate
on: [pull_request]
jobs:
  eval:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with: { python-version: "3.12" }
      - run: pip install deepeval pytest
      - run: deepeval test run test_agent_gate.py   # 非零退出即阻断
        env:
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}

可运行代码 2：OpenTelemetry GenAI 语义约定的任务级埋点

# agent_tracing.py  —  任务级 correlation + 逐步骤埋点（OTel GenAI 约定示意）
# pip install opentelemetry-sdk opentelemetry-api
from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor, ConsoleSpanExporter
import time, uuid

trace.set_tracer_provider(TracerProvider())
tracer = trace.get_tracer("my-agent")
trace.get_tracer_provider().add_span_processor(BatchSpanProcessor(ConsoleSpanExporter()))

def run_task(user_input: str, model: str, prompt_template_version: str):
    # 任务级根 span：correlation ID 贯穿全部下游调用
    with tracer.start_as_current_span("agent.task") as task:
        task_id = str(uuid.uuid4())
        task.set_attributes({
            "gen_ai.system": model,
            "gen_ai.prompt.template.version": prompt_template_version,
            "agent.task_id": task_id,           # 关键：端到端关联键
            "agent.user_input_chars": len(user_input),
        })
        for step, (tool, args) in enumerate([("search_db", {"q": user_input})]):
            with tracer.start_as_current_span(f"agent.tool.{tool}") as span:
                span.set_attributes({
                    "agent.task_id": task_id,   # 每个子 span 都携带
                    "agent.step": step,
                    "gen_ai.request.model": model,
                    "tool.name": tool,
                    # 生产环境：另记 token 用量 / 成本 / 耗时，PII 先脱敏
                })
                time.sleep(0.1)                 # 实际工具执行

要点：agent.task_id 必须穿透模型调用、工具、下游系统和人工审批——没有它，trace 恰好会断在你最需要排查的那一环。

三、评测指标与红线

12 指标目录：任务成功率、无依据断言率、工具调用准确率、恢复率、人工接管率、p95 延迟、单任务成本、安全违规、权限失败、数据新鲜度、用户接受度、业务影响。

三条起步红线：关键任务完成率 ≥95%、权限执行率 100%、敏感数据泄露 0 容忍。三个反模式：拿排行榜当评测、只测干净 prompt、LLM 当唯一裁判（裁判要与专家标注报告一致率）。

更进一步是"监控你的监控"：事前/事后覆盖度分开统计、评审时延报 median+p95+最老未处理项、分母独立审计（防监控自己报自己 100%）。Anthropic 披露其 8 月产生了超 10 亿次监控决策——量级虽远，方法相通。

四、踩坑记录

采样丢数据：为省观测成本开启激进采样，事故现场恰好没数据。对策：span 存算分离（Langfuse 自托管 / OpenObserve 都走这个思路），全量留、按需查；
MCP 解析缺失：MCP 已成工具调用事实标准（Linux 基金会：同比增 340%），观测平台若不支持 MCP 原生解析，工具调用 trace 是不透明 JSON 块；
评测环境裸奔：带真实凭证的评测任务必须进沙箱（gVisor/Kata / K8s Agent Sandbox），隔离等级与生产对齐——"只是跑个测试"不是降级理由；
correlation ID 缺失：事后补 ID 的成本是设计时就加的 10 倍以上，第一天就写进架构。

五、落地节奏

第 1-2 周：OTel 埋点 + trace 看板（Langfuse 自托管 / OpenObserve，零许可费）；
第 3-4 周：golden dataset（每工作流 ≥100 例，含失败/边界/对抗样本）+ CI 门禁；
第 2-3 月：线上 LLM-as-judge + 漂移检测 + 告警联动回滚 + 生产失败自动入库。

小结

Agent 工程化的闭环是：评测定义约束 → 沙箱执行约束 → 可观测性验证约束 → AgentOps 持续运转。今天给出的两段代码分别对应"门禁"与"埋点"，抄走改改就能跑。系列完结，感谢追更 🔚

参考资料：OpenObserve v1.0 发布（VentureBeat）、AWS CloudWatch Omni（Techstrong.ai）、腾讯云 Agent 可观测（站长之家）、Agent 监控元指标（agentkit.ai）、评测门禁分析（clixlogix.com）、工具选型（toolradar.com）。