AI Agent 上生产的最后一公里:可观测性、运行时审计与评估怎么做(2026)

把一个 AI agent 送进生产,难点已经不在"能不能跑通 demo",而在"能不能证明它可信"。要跨过这道坎,需要三道护栏:可观测性(运行时看得见发生了什么)、运行时审计(能向第三方证明发生了什么、且记录改不了)、评估(上线前后验证它做得对不对)。三者缺一,agent 就停在"演示能过、生产不敢上"的最后一公里。本文用哈希链审计、270 次工程契约全通过等实证,拆开这三道护栏各自解决什么、怎么落地,以及可观测性和评估平台该怎么选型。

这也是我们上一篇《为什么 AI agent 在生产环境会失败》的续篇——那篇讲"为什么会失败"(诊断),本篇讲"怎么观测、审计、评估让它在生产里活下来"(解法)。

AI agent 上生产前,到底要做哪些可观测性和评估?

一句话答案:至少要做三件事——给运行时装上可观测性(traces / logs / metrics)、给关键行为加上运行时审计(可验证、不可篡改的证据链)、给上线质量建立评估契约(用代码而非提示词兜住确定性)。

这三件套对应三个不同的问题。可观测性回答"它现在在干什么、慢在哪、错在哪";运行时审计回答"事后我能不能向客户、合规、安全团队证明它当时到底做了什么";评估回答"它这次改动之后,行为是变好了还是回退了"。

值得强调的是,评估并不等于"再测一遍模型输出"。arXiv 上一篇 2026 年 7 月的论文《From Prompts to Contracts: Harness Engineering for Auditable Enterprise LLM Agents》提出的思路是:把需要确定性的行为从提示词里"下沉"到代码、manifest、schema 和校验件中,围绕一个可替换的"组合边界(composition boundary)"来组织——也就是说,评估的对象是工程化的契约,而不只是一段自然语言指令的运气。而运行时审计这一层,已经有像 Halo 这样的开源运行时在做:把每一次工具调用、模型调用、数据访问都记成日志。下面几节逐一展开。企业为什么连"跑通"之后仍然上不了线,可以参照《为什么企业 AI 落地这么难》里的系统性阻力。

可观测性和评估到底有什么区别?

一句话答案:可观测性关注运行时"发生了什么"(traces / logs / metrics),评估关注上线前后"做得对不对"(质量 / 回归 / 红队),运行时审计则关注"能不能向第三方证明发生过什么"(不可篡改)——三者目标不同,不能相互替代。

很多团队把这三件事混为一谈,结果是:装了 tracing 却没有评估门禁,模型一改版就在生产里悄悄回退;或者做了离线评估却没有运行时证据,出事时拿不出可信记录。用三类主流工具的定位来对照,区别会更清楚:mlflow 提供 tracking 加 evaluation,promptfoo 侧重 evaluation 加红队对抗测试,comet-ml/opik 覆盖 debug / evaluate / monitor 的全链路。下表把四个维度拆开:

维度	可观测性(Observability)	评估(Evaluation)	运行时审计(Runtime Audit)
回答的问题	它现在在干什么、慢在哪、错在哪	它这次改动做得对不对、有没有回退	事后能不能证明它当时做了什么
触发时机	运行时持续	上线前 + 回归 + 定期红队	每次关键调用即时留痕
典型产出	每一步 tool call 的 trace、延迟与 token 指标	跑一批对抗 prompt 看通过率 / 泄漏率	每次工具/模型/数据访问的哈希链日志
面向对象	工程与 SRE	质量与产品	客户安全团队、合规、审计方
代表工具	opik、mlflow tracing	promptfoo、mlflow evaluation	Halo(哈希链、不可篡改)

一个实操判据:如果你只能向工程团队解释系统状态,却没法向客户的安全团队出示不可抵赖的证据,那你有可观测性,但没有运行时审计——而在企业场景里,后者往往才是签约的前提。

怎么向客户的安全团队证明 agent 没乱动他们的数据?

一句话答案:靠运行时审计留下一条"供应商在运行、但供应商自己也改不了"的证据链——把每次工具调用、模型调用、数据访问都写成哈希链式(hash-chained)的追加日志,任何持有 checkpoint 的一方都能验证记录未被篡改。

这正是开源项目 Halo(2026 年 7 月 7 日发布于 Show HN,37 分、23 条讨论)给出的答案,它把自己定义为"the audit trail the vendor runs but cannot edit"(供应商运行、却无法编辑的审计追踪)。它的几个设计点对企业交付很关键:

• 哈希链追加日志:每一次工具调用、模型调用、数据访问都追加成一条链式记录,任何一方只要持有某个 checkpoint,就能校验这条链是否被事后改动过——即"可验证不可篡改(tamper-evident)"。
• 隐私友好:原始入参不落库,只存哈希加脱敏摘要,因此审计证据本身不会成为新的数据泄漏面。
• 易嵌入:零运行时依赖、约 4,300 行 Python,已提供 OpenTelemetry、LangChain、MCP、OpenAI Agents SDK、Claude Code 等适配器,能直接挂进现有 agent 栈。

对 FDE(Forward Deployed Engineer,前向部署工程师——把 agent 真正落进客户生产环境的那个角色)来说,这类证据链的意义是把"相信我们没乱动数据"换成"这里是可验证的记录,你自己核"。这也是我们在企业 AI 操作系统里坚持"每个专属智能体各自可审计"的原因。

为什么只写 prompt 或规则不够,一定要工程化护栏?

一句话答案:因为提示词复现不了确定性保证——同一条规则,靠 prompt 写会时灵时不灵,靠代码/harness 兜才是承重的。

前面提到的那篇 arXiv 2607.08028给出了到目前为止最硬的一组对照数据。研究者在 5 家韩国企业集团、共 25 家上市公司的公开数据上做实验,跨 3 个托管模型,让确定性行为走"组合边界"的工程化契约:270 次 composition-boundary 运行契约全部通过。

更说明问题的是失败一侧的对照:仅靠 prompt 指令时,"推荐措辞"越界和"内部 trace 泄漏"这两类违规会直接抵达最终用户;而换成 harness(把校验下沉到代码与 schema)后,这些违规被完全拦截。 结论很直接——代码保证是承重墙,提示词只是装饰层,你没法让一句自然语言指令去承担"绝不泄漏内部 trace"这种硬约束。这一节的取舍,和《为什么 AI agent 在生产环境会失败》里反复出现的"demo 靠提示词、生产靠工程"是同一件事。

Agent 可观测性 / 评估平台有哪些,怎么选型?

一句话答案:主流的三个开源平台各有侧重——mlflow 偏工程平台与 tracking,promptfoo 偏评估与红队,opik 偏运行时监控;若还要向第三方证明"发生过什么",再补一层像 Halo 这样的不可篡改审计。

选型不必纠结"谁最好",而要看你当下缺的是哪道护栏。下表是 2026 年 7 月中旬的一个快照(Star 数与定位均取自各项目本周仍在更新的仓库):

工具	定位	强项	适合场景	Star(2026-07)
mlflow	agents/LLMs 的 AI engineering 平台	tracking + evaluation,实验与版本管理成熟	已有 ML 平台、想把 agent 纳入统一治理	26,970★
promptfoo	prompt / agent / RAG 测试	evaluation + red teaming,对抗与泄漏测试	上线前门禁、安全红队	23,133★
comet-ml/opik	agentic workflow 的可观测层	debug / evaluate / monitor 全链路	生产运行时监控与排障	20,528★
Halo(halo-record)	不可篡改运行时审计	哈希链、tamper-evident、只存哈希+脱敏摘要	需向客户/合规出示可验证证据	开源 · Show HN 37p

一个务实的组合:用 opik 或 mlflow 兜运行时可观测,用 promptfoo 做上线前评估与红队,用 Halo 补上向第三方举证的审计层——三者分别对应前面三道护栏。如果你想把这套护栏整合进一套统一的企业 AI 操作系统(其卖点正含"各自可审计的专属智能体"),而不是自己拼装,可以从这里切入。

主动式 agent 上线后,除了它自己还要监控什么?

一句话答案:还要监控它所观测的"企业状态"——主动式(proactive)agent 的价值在于持续盯着业务变化并及时浮现问题,所以可观测的对象不只是 agent 内部,还包括它对外部世界的感知质量。

arXiv 另一篇 2026 年 7 月的论文《Context Graphs for Proactive Enterprise Agents》给出了这一层的量化标尺:主动式 agent 在持续监控企业状态时,Precision@5 达到 0.83、误报率 0.11,而平均"浮现时间"从反应式基线的 47 分钟压缩到 30 秒以内(47min → 30s)。 这组数字说明,当 agent 从"等你问"变成"主动报",你要监控的指标就多了一层:它的判断准不准(precision)、吵不吵(误报率)、快不快(浮现时间)。缺了这层监控,主动式 agent 很容易变成"要么漏报、要么天天误报"的噪声源。

这些护栏值得投入吗?落地会不会导致裁员?

一句话答案:值得,而且数据不支持"AI 落地=裁员"这一焦虑——重投入 AI 的公司,采用后反而在扩招。

给 agent 上生产装三道护栏确实要花工程成本,但它换来的是能签约、能通过安全审查、能规模化复制的生产系统,而不是永远停在 demo。商业侧的实证也偏向乐观:Ramp Economics Lab 2026 年 6 月 30 日的研究《Companies hire more after AI adoption》基于超过 21,000 家美国公司的样本发现,重投入 AI 的公司在采用后两年内,总员工数增长约 10%、入门级岗位增长约 12%。换句话说,把 AI agent 真正落进生产、并用护栏让它可信,更像是在为团队创造杠杆,而不是替换团队。

如果你正卡在"demo 能跑、生产不敢上"的最后一公里,6AM TECH(晨启科技)的 FDE 咨询可以帮你把可观测性、运行时审计与评估这三道护栏落进客户的真实环境。更多常见问题见我们的 FAQ。