企业级 AI 架构 · 05 可观测与评测｜怎么知道 Agent 干得好不好

企业级 AI 架构 · 05 可观测与评测｜怎么知道 Agent 干得好不好

系列第 05 篇。安全管"别越界"，这一篇管更日常、也更难的一件事：怎么知道 Agent 干得对不对，以及拿什么证明。照旧三方对照。

呼应 00 总览的中央论点：评测把"干得好不好"落成可验证工作区，是把验收标准写在模型之外——这是控制平面的"验收机制"，而非交给模型自证清白。

一、WorkBuddy 的权威主张：反馈层 + 把"答案"换成"可验证的工作区"

Harness 五层里有一层叫反馈层（Feedback），解决的就是"执行后怎么知道错了"。它靠三类信号：

  • 工具结果里带可纠正信息（不只是报错码，而是告诉你错在哪、怎么改）；
  • 编辑前做时间戳校验（防止改到别人刚改过的文件）；
  • 外部验证信号回流（类型检查、单测、lint 的结果反哺给 Agent）。

这些反馈让 Agent 在"问题进入人工审查之前"先自我纠错。这背后的原则还是那句：计算型信号优先，能机器判定的问题，别让人肉看。

顺带把可观测性的"强弱"讲清：WorkBuddy 侧靠反馈层信号 + 审计 / 会话日志实现可追溯，属于审计日志级的可重建——能事后翻出每一步做了什么，但不是 DeepSeek Harness 那种"模型可见即已记录"式的运行时不变量（架构硬保证）。两者都能支撑取证，但力度不同：WB 是"记录可查"，DSH 是"不记录就跑不了"。把"运行时不变量"这个更强表述留给 DSH，WB 侧用"审计日志级"更准确。

05_反馈闭环

05b_评测双极对照
图：同一夹具，直调引擎 / DSH 插件入口两极互证「15 命中」（0 误报由 Pi/DSH 两侧 eval 分别断言）。

但要"评测一个 Agent 到底行不行"，靠单次反馈不够，得有一套基准。WorkBuddy 团队联合发了篇论文（arXiv:2607.20911），做了个 260 题的跨域基准，覆盖 Code / Web / Office / Security 四域。它有几个反直觉的发现：

  1. Harness 不是中性外壳，同一个模型，换一层 Harness，排名可能对调（Security 域跨 Harness 平均差 8.6 分）；
  2. 没有"全能王"模型；
  3. Token 多 ≠ 分高。

更重要的是它的评测对象变了：从"补丁 / 聊天答案"转向"最终可验证的工作区"，不再是看它"说了什么"，而是看它"交付的东西能不能用、能不能验证"。这个转向，和整个系列的立意是一致的。

再往上是 Loop 层的传感器（Sensors）/ 评测（Evals）/ 停止条件（Stop Conditions）/ 预算（Budget）——这些是"长期任务怎么自我监控、什么时候该停"的机制，会在后续的 Loop 相关篇目里反复出现。

（WorkBuddy 闭源，以上是公开方法论，只当"标准答案"。）

二、Pi 怎么做：可观测性藏在"纯文本事件流"里

Pi 的可观测性，靠一个朴素的载体：JSONL 会话文件。

它的 session 是追加式的事件流，每个 entry 一行、带类型，从用户消息、助手回复、工具调用到压缩摘要，全在一个文件里：

{"type":"user","id":"1","parentId":null,"text":"帮我修这个 bug"}
{"type":"assistant","id":"2","parentId":"1","text":"我先看下报错…"}
{"type":"tool","id":"3","parentId":"2","tool":"bash","result":"..."}
{"type":"compaction","id":"4","parentId":"3","summary":"goal: 修 bug; progress: 已定位; decisions: 改 A 处"}

示意片段，基于 Pi 官方文档；字段以官方为准。

这一行一行的 JSONL，就是 Pi 的"审计日志"和"评测素材"：可以回放、可以分叉（/tree /fork）、可以压缩（/compact）。出了问题，直接把 session 文件翻出来看，Agent 每一步想了什么、调了什么、结果如何，全都有据可查。

Pi 的"评测"没有内置成一套基准，但它把可观测性做成了默认，纯文本、可读、可迁移。这符合它一贯的极简哲学：不给你一套评测框架，但保证你手里有一份能拿去评测的完整记录。

三、DeepSeek Harness 怎么做：可观测性被做成了"不变量"

DSH 在可观测性上走得更极端，它把"完整记录"升格成了一条运行时不变量：

模型可见即已记录。

意思是：凡是送进模型请求的输入，都必须能从日志重建，并且由一项运行时断言来保证。系统提示、推理过程、工具调用与结果、子 Agent 调度、所有上下文注入，全部落进同一条 append-only session log，支持 resume / fork / search / replay。（DSH 架构文档原句 "Model-visible means logged"，由运行时断言保证；一手来源：github.com/deepseek-ai/deepseek-harness 的 docs/architecture.md）

它还能在 Web UI 里把一次运行的轨迹可视化、逐帧回看（视图形态与命名以你使用当日为准）。v0.1.2-rc.1 又往前推了一步：新增实验性的 Inspector 工具，把"往里看"这件事从界面功能做成了工具（标注 experimental，形态仍可能变）。对比 Pi 的"纯文本可读"，DSH 的差异在于：它把"可观测"做成了架构保证，而不是事后翻阅，你要新增一项模型能看到的输入，就必须新增一个会话事件，没有后门。

v0.1.3-alpha.1 还把会话日志换到了 Session 格式 v2：按不可变的相邻 generation 迁移，Assistant 流按 attempt 聚合并落进持久化的 settlement。对评测的意义很直接——"重放一次运行"的粒度变细了：一次回答里的多次尝试不再被压成一条，逐帧回看才真能定位到"是哪一次 attempt 跑偏"。

但真正要紧的是后面这一跳：v0.1.5-alpha.1 又把格式升到了 V3（系统提示词纳入消息历史，旧 PTC 事件与 code 预设引用自动迁移），而且官方写得很明确——升级后的会话不支持降级读取。也就是说，5 天之内会话格式换了两代，而且这是一道单向门：恢复受支持的历史会话时会生成新版日志（原文件保留），但新日志回不去上一代。

对评测的含义比"格式换了"重得多：你的历史评测集本身就是一批 session。一旦被新版本读过一次，它们就整体升到 V3，此后旧版本再也读不了——想拿老版本复现一次几个月前的评测结果，门已经关了。所以做评测基础设施时，别只备份原始输入，要把 session 目录按版本快照整份归档；也别指望"先升级看看，不行再退回去"。自定义日志读取器同样得跟着适配 V3。

补一条好消息：这道单向门现在配了说明书。 到 v0.1.5-rc.1（9-10），仓库里已经放了迁移文档 packages/session/session-format-v2-to-v3/README.zh.md（中文版），讲清 v2 到 v3 的跨版本迁移细节。这件事的意义不在技术细节，而在流程：单向门本身不可怕，可怕的是没有公告栏的单向门。对做评测基础设施的人来说，行动顺序就很清楚了——升级前先读那份迁移文档、先归档 session、再决定过不过门，而不是升级完了才发现回不去。

标注：DSH 目前是 developer preview（写作时 v0.1.7-alpha.2，非 GA），接口仍在迭代、会有破坏性变更，本系列只做架构对照，不承诺逐行跟跑。

两条 0.1.6 的变更直接影响评测基建怎么搭：其一，v0.1.6-alpha.1 弃用了 Session 的同步历史读取接口 snapshotEvents、eventAt 与 ownEvents——按这几个接口写过自定义日志读取器的得改；其二，Headless 支持从标准输入接收任务、用 --session-id 继续已有会话、用 --json 逐行输出 JSON 运行事件。第二条的意义比看上去大：以前"跑一批用例、把结果接进自己的报表"只能解析终端输出，现在它给了结构化事件流，评测第一次能作为流水线的一等公民被接进来。配合前面说的会话格式单向门，顺序不能反——先把历史 session 按版本整份快照归档，再决定过不过门。

再到 v0.1.7-alpha.1，单向门开了第二道。 发布说明：

Session 日志升级为 V4，新增面向开发者的批量迁移工具，并兼容部分 V3 会话缺少轮次结束记录的情况。

V3 → V4。 和上次 V2 → V3 比，这次多给了一样东西：批量迁移工具。前面说过一句话——单向门本身不可怕，可怕的是没有公告栏的单向门。这次上游不仅给了公告栏（发布说明里明写），还把搬运工具也备好了，所以企业侧的行动顺序可以更明确：升级前先把历史 session 按版本整份快照归档，再决定过不过门，因为过门之后旧版本读不回来（"兼容 V3 缺轮次结束记录"是读侧的兜底，不是回退通道）。评测集本身就是一批 session，这道门对做评测基建的人尤其要紧。

四、三方对照：可观测与评测，三种"取证方式"

维度 WorkBuddy（方法论之尺） Pi（极简派，可跟跑） DeepSeek Harness（极繁派，dev preview）
反馈信号 工具结果带可纠正信息 + 时间戳校验 工具结果进 session 文件 事件流（模型可见即已记录）
审计/回放 全链路审计（企业版） JSONL session 可回放/分叉 append-only log + 回放/检查视图（以当日 UI 为准）
评测基准 260 题四域 Bench（可验证工作区） 无内置基准，靠 session 记录 无内置基准，靠事件流
核心结论 Harness 非中性外壳 / Token≠分高 可观测性是"默认"而非"附加" 可观测性是"不变量"

速记一句话：可观测性的关键不是"事后能翻记录"，而是"记录从一开始就完整、可信"，WorkBuddy 用反馈层 + 基准去度量，Pi 用纯文本事件流留痕，DSH 用运行时断言保证"可见即已记录"。三者殊途同归：把"评测 Agent"这件原本说不清的事，落成可验证、可复现的工程动作。

相关阅读（系列互链）

本篇是【企业级 AI 架构】技术深轨，与公众号《AI思想的东方注脚》哲学引子、本体智能 / FDE 系列同源联动——同一观点不重复讲，按兴趣深潜：

  • 《番外：评测生产化（把"要测"变成"每天在测"）》（企业级 AI 架构·番外）——本篇立标准，番外讲怎么把它跑成日常
  • 《当 AI 能自己改库存：供应链里的"本体智能"实战》（本体智能·篇5）——评测指标最终要落到真实的业务动作上

下一篇：06 · 模型不可知与路由——评测发现"没有全能王"，那多模型到底怎么选、怎么切。

可观测性 #AI评测 #企业级AI #质量门禁

关注公众号「农夫三拳有点癫」，第一时间读到本系列更新。
账号二维码

posted @ 2026-10-09 17:02  老羅  阅读(22)  评论(0)    收藏  举报