a05、a06 告诉你「评系统不评模型」，这一讲把「系统」拆成可操作的部件：harness 五部件、三治理面、「评测 harness 必须对齐生产」的铁律，最后给一个今晚就能跑的对照实验。是把系统观落到工程的关键一篇。
先修：a05（Agent Eval 概念五件套）。准备给 Agent 搭评测环境的团队，在写第一行评测代码前读。与 a05（概念）、a15（工程体系）连读：这篇是两者之间的结构层。
先合上原文在心里作答，再点开对照。全对 = 本篇真正通关。
Permission（能碰什么 → 安全评测：越权、注入）；Control（跑多远 → 循环健康度：死循环、步数与成本失控）；Observability（看得见吗 → 可观测性与 Tracing：能否定位到哪一步错了）。
评测 harness（完美工具、温室环境）与生产 harness 不是一套：超时重试、脏数据、异常恢复从没被考验过。你测的那个 Agent 和上线的那个 Agent，根本不是同一个系统。
控制变量：固定 harness 只换模型（反之亦然）；每个任务跑多次 trial 看通过比例而非单次；分维度对比（完成率 / 步数成本 / 失败聚集在轨迹哪一步）。
上方为本站原创导读，下方为原文完整收录，便于对照阅读。
上一讲结尾，我抛出了四个跃迁里最关键、也最被低估的一个：Agent 评测，评的不是模型，而是"模型 + harness"这个系统。这一讲，我们就把这件事彻底讲透。
为什么值得用一整讲？因为它是这门专栏的"地基中的地基"。这个认知没立稳，你后面做的每一件事——挑基准、设计评测集、读评测分数——都会在不知不觉中犯同一个错误：把系统的成绩，错算到模型头上。而这个错误的代价，往往就是"线下选了个高分模型，上线却跑不动"。
正好，最近工程圈有两个很火的概念——Harness Engineering 和 Loop Engineering——给我们提供了一套现成的、说人话的语言。这一讲我们先讲 harness，下一讲讲 loop。
我们先不谈定义，先看一个现象。
两个团队，都做编码 Agent，用的是同一个底层大模型——同一个版本、同样的权重，一个字都没差。结果呢？在同一套任务上，一个团队的任务完成率，能比另一个高出几十个百分点。
如果你还停留在"模型决定一切"的思维里，这个现象是无法解释的：模型一模一样，成绩怎么会差这么多？
但只要你接受"Agent = 模型 + harness"，一切就顺了。两个团队差的，不是模型，是包在模型外面的那层东西——工具怎么给的、提示怎么写的、上下文怎么管的、出错怎么处理的。这层东西，就是 harness。
这个现象不是个例，而是 Agent 工程的常态。它逼着我们承认一件事：
在 Agent 这个系统里，模型很重要，但模型之外的那层 harness，常常才是决定上限的地方。
先给一个能用的定义。
Harness，是包在模型外面的那层运行时基础设施，负责把模型"概率化的推理"，翻译成"可依赖的行动"。它管理上下文、调度工具执行、施加安全控制、维护会话记忆——是模型与真实世界之间的全部中间层。
一个好用的类比是操作系统。模型就像 CPU，是负责"算"的核心，但一颗 CPU 单独摆在那儿什么也干不了；是操作系统把内存管理、设备驱动、进程调度、权限控制这些事都包办了，CPU 的算力才变成你能用的软件。Harness 对模型，就是操作系统对 CPU。
这里有个看待模型的视角转变，很值得你接受：把底层大模型当成一颗"冻结的推理计算器"（frozen reasoning calculator）。意思是，在你的应用里，模型的能力基本是给定的、冻结的——你不太会去重新训练它。那么，安全、执行的准确性、多步任务的编排、跨轮的记忆，这些责任就不应该寄希望于模型自己长出来，而要由你设计的 harness 来兜住。
顺便交代一下来历，方便你查资料：harness engineering 这个提法，近期由 Mitchell Hashimoto 等人推热，很快成了圈内热词（OpenAI 的工程博客也用它来讲"用 Codex 造 Agent 时，改进 harness 比换模型更重要"）。它和你可能听过的另一个词 scaffold（脚手架）基本是同义的——本专栏统一用 harness，你在别处看到 scaffold，知道是一回事就行。
再补一个正在成形的视角：有人把它进一步拆成 model / harness / skill 三层——在模型和 harness 之外，"skill"指可组合、可按需加载的能力单元（如 Anthropic 的 Agent Skills）。你先不必纠结三分还是两分，记住本质即可：模型之外那几层，才是决定 Agent 上限、也是评测真正要盯的地方。
一个 Agent 系统 = 模型（核心）+ 包在它外面的 harness。先摆好中心：模型 / 推理核心是决策大脑，负责判断"现在该干嘛"（比如"这个订单该不该退"）——但在你的应用里它基本是给定的（"冻结的计算器"）。真正需要你去设计、也是这一讲要拆开看的，是包在模型外面、构成 harness 的这五个部件（还是用"退款 #1234 并发确认邮件"来对照）：
一是上下文与记忆。模型能看到什么信息、看不到什么信息，都由 harness 决定——当前对话、之前的工具返回、外部知识，进还是不进上下文窗口，怎么压缩、怎么取舍。在长任务里，这一块的设计直接决定模型会不会"记岔了"。
二是工具与接口。Agent 能调哪些工具（查订单、退款、发邮件）、每个工具的描述写得清不清楚、参数定义合不合理、调用协议（比如 MCP）怎么接。工具描述写错一个字，模型就可能选错工具。
三是权限。哪些工具能直接调、哪些必须先经人审批。比如"查订单"可以随便调，但"退款"这种动钱的操作，要不要设一道门槛？
四是控制回路。驱动 Agent 一轮轮往前走的循环逻辑，以及套在它身上的"缰绳"——最多走几步、最多花多少钱、多久超时。没有这层，Agent 可能在某个环节反复打转停不下来。
五是观测与反馈。把 Agent 每一步的行为记录下来（日志、轨迹、指标），以及行动之后的校验器（比如调完退款接口，自动跑个检查确认状态真的变了）。
你发现没有：模型之外这五个部件，恰恰就是上一讲说的那些"结果与轨迹"的生产者。所以评 Agent，本质上就是在评"模型 + 这五个 harness 部件"协同工作的质量。
六个部件还是有点散。业界有一个更凝练的归纳，把"harness 在运行时如何约束和管理 Agent"收敛成三个治理面。我特别推荐你记住这三个面，因为后面好几个评测主题，都能直接挂回到它们身上。
第一个面：Permission（权限）——它能碰什么。沙箱隔离、文件系统隔离、网络限制、工具的风险分级、哪些操作需要人在环路审批。它回答的是"边界在哪"。在我们的例子里，"退款"该不该被允许直接执行，就是权限面的事。这个面对应后面的安全评测：你的 Agent 会不会越权、会不会被提示注入诱导着做了不该做的事。
第二个面：Control（控制）——它能跑多远。递归与步数上限、成本天花板、超时设置。它回答的是"什么时候必须停"。这是防止 Agent 停不下来、防止一次任务烧爆预算的"缰绳"。这个面对应后面的循环健康度与非功能评测：死循环、步数失控、成本失控，测的就是这层缰绳有没有真的勒住。
第三个面：Observability（观测）——它在干什么你看得见吗。结构化日志、执行轨迹（trace）、聚合指标。它回答的是"出了问题，你能不能定位到是哪一步"。这个面对应后面的可观测性与 Tracing：没有观测，一个失败的分数对你就是个黑箱；有了观测，你能精确地指到"就是第三步那次工具调用错了"。
你看，harness 的三个设计面（怎么设计），几乎一一对应着评测的三类任务（怎么验证）。这不是巧合——这正是这门专栏的主线：设计与验证，一体两面。
到这里你可能会想：既然 Agent = 模型 + harness，那评测的时候，我能不能把模型的贡献和 harness 的贡献分开算？
很遗憾，基本掰不开。这是 Agent 评测最别扭、也最重要的一个性质，必须讲清楚。
原因在于，harness 控制着模型与任务之间的全部接口。模型看到什么、能用什么工具、工具长什么样、出错后有没有机会重来——全是 harness 喂给它的。所以当一个任务失败时，你面对的是一道无法干净拆分的归因题：
更反直觉的是，模型和 harness 之间还存在"适配"关系：一个能力偏弱的模型，配上一套贴合它习性的 harness（比如把任务拆得更碎、提示给得更具体），完全可能反超一个更强、但 harness 很粗糙的对手。也就是说，"哪个模型更好"这个问题，脱离 harness 根本没有答案。
这件事对评测有两个非常具体的后果，请你记牢：
后果一：评测分数永远是"联合成绩"。你报出的任何一个数字，都是"某个模型 + 某套 harness"一起跑出来的，不是模型的独奏。所以——评测报告里必须记清楚 harness 信息（模型版本、工具集、提示版本、环境）。一份只写了"成功率 78%"却没说 harness 的报告，是不可复现、不可比较的，约等于没有结论。
后果二：想做"干净"的对比，必须控制变量。你要么固定 harness 只换模型（回答"换个模型值不值"），要么固定模型只改 harness（回答"我这次 harness 优化有没有用"）。两个一起变，那分数变了你也不知道该归功于谁。这个方法，我们下一节就动手。
既然分数是模型和 harness 的联合成绩，那就引出一条贯穿整门专栏的工程铁律：
评测时用的 harness，要尽量和生产那套对齐——工具、环境、提示、控制策略，越一致，结论越可信。
这条铁律的反面，是一个特别常见、又特别坑的错误。我把它叫做"理想化评测"：
工程师在评测时，给 Agent 配了一组"完美"的工具——永远秒回、永远不报错、永远返回干净的数据；环境也是精心准备的、不会有意外的"温室"。在这套温室里，Agent 表现优异，成功率漂亮。于是上线。
可生产环境是什么样的？工具会超时、会限流、会返回半截脏数据；用户的输入千奇百怪；网络会抖。Agent 一进真实世界，那些在温室里从没被考验过的环节——超时重试、脏数据处理、异常恢复——全线崩溃。
线下高分，线上翻车，十有八九就是评测 harness 和生产 harness 不是一套。你测的那个 Agent，和上线的那个 Agent，根本就不是同一个系统。
所以，在你信任任何一个评测分数之前，先用这张清单核对一遍"评测 harness"和"生产 harness"对齐了没有：
光说道理不够，我给你设计一个最小的、你回去就能跑的对照实验，亲手感受一下 harness 的分量。
目标：在模型完全不变的前提下，验证"harness 的好坏，足以显著改变 Agent 的成绩"。
步骤：
你大概率会观察到：仅仅是把工具描述写清楚，B 套的完成率就明显高于 A 套，而且 A 套的失败会扎堆在"选错工具/传错参数"那一步。模型一个字没变，成绩却变了——这就是 harness 的力量，也是"为什么评测对象是系统"最直观的证据。
这个实验还顺手教了你一件事：这正是一次小型的受控评测。把变量控制好、跑足够多次、分维度看结果——评测的基本功，都在里面了。
这一讲，我们用 Harness Engineering 的视角，把上一讲的"评系统而非评模型"彻底落地了：
一句话总纲：你评的，从来不是模型，而是模型和它的 harness 协作出来的那个系统。