什么是 Harness 治理？为什么说 Agent 的能力一半在模型一半在 harness？
谁在问：头部 AI 公司与平台团队进阶题；用来判断你有没有把 Agent 工程当作可管理的资产
口语化问法
- Agent 的效果，多少来自模型、多少来自你们的工程？
- 同样的模型，为什么不同团队做出来的 Agent 差这么多？
- 新模型出来了，你们那套工程要怎么改？
考察意图
这题是第 3 章的收口题，问的是你怎么看待自己这份工作的价值。面试官在验四层：
- 能不能把 harness 说成一个有结构的东西，而不是"提示词加一堆代码"。
- 知不知道能力差异的机理——为什么换个 harness 成功率能差一个数量级，而不是只会复述这句话。
- 有没有治理意识：harness 是资产，就要有版本、有归属、有评测、有债务偿还，否则它会在下一次模型换代时变成负担。
- 会不会做减法。 2026 最重要的 harness 动作是删，不是加。这是第三个问法的落点。
参考答案
60 分答案（及格线）
Harness 指模型之外、决定 Agent 实际能力的那整套工程结构。 拆开大致八块：
- 工具集与它们的 schema、描述
- 上下文组装（系统提示、状态注入、压缩策略、工具结果裁剪）
- 循环控制（终止条件、步数与预算、重试、死循环兜底）
- 错误反馈的格式（决定模型能不能自愈）
- 权限与人工确认（分级自治）
- 记忆与状态管理
- 可观测与评测
- 运行环境（沙箱、可用命令、文件系统）
为什么说一半在 harness：模型每一步的决策质量，取决于它看到什么（上下文）、能做什么（工具）、失败后得到什么反馈（错误消息）、有几次机会（循环与预算）——这四样全在 harness 里。截至 2026-08 业内比较认可的表述是 LangChain 那句"If you're not the model, you're the harness"，同一个模型换一套 harness，任务成功率可以差一个数量级。
Harness 治理就是把这套东西当代码资产管理：版本化、走 review、改动必须跑评测回归。
90 分答案（有生产经验的回答）
补三层。
1. 把 harness 分成两类，这是治理的核心。
| 类别 | 内容 | 随模型变强会怎样 |
|---|---|---|
| 模型补丁 | 手写 CoT 引导、self-critique、格式修补、针对某模型脾气的提示词技巧、拆得很细的子步骤 | 会消失。模型内化后继续保留反而是负优化（占 token、和内部推理打架） |
| 系统约束 | 权限、预算、审计、可回滚、外部状态、人在环、可观测 | 永远不会消失。它们不属于模型，模型再强也接管不了 |
治理的第一原则是：这两类必须在代码里就分开、并且标注清楚。混在一起写的后果是模型换代时不敢删——分不清哪一行是为了绕开旧模型的缺陷、哪一行是业务底线，最后只能原样搬过去，于是新模型的收益被旧补丁吃掉一半。
2. 因此，2026 的常规动作是"harness 减法"（截至 2026-08）。 每次模型升级，我会做一次减法冲刺：先用同一套评测集在新模型上跑现有 harness 拿基线，然后逐类删补丁（一次只删一类，否则归因不了），看哪些删了不掉分甚至更好。经验上最先能删的是格式修补、显式思考引导、和为弥补旧模型工具调用不稳而写的重试与纠偏。系统约束那一栏一行都不动。
3. harness 债务要能被度量。 债务信号：只有原作者看得懂的 magic prompt；没有任何评测覆盖的分支；上次被验证是在两个模型版本之前；为某个已修复的模型 bug 写的绕行代码。可度量的指标：harness 里无评测覆盖的比例、每条补丁的最后验证时间、模型换代后未复查的补丁数。这三个数一摆，团队就知道该还多少债了。
4. 归属问题很现实。 最常见的病是提示词散落在几个服务里、工具定义各写各的、没人 own。治理上要做到：提示词与工具定义进代码仓库、走 review、有版本号，并且能关联到评测结果与线上指标（这版提示词对应哪次评测、上线后指标怎么变）。评测集是团队共享资产，不属于某个人。规模大一点的团队值得设一个 harness / 平台层的 owner。
5. 一句可以收口的判断：模型变强让 harness 变薄，但不会让它消失——薄的是补丁，留下的是约束。所以这份工作的长期价值不在于"帮模型想得更清楚"，而在于"给系统提供模型给不了的保证"。
追问链
同模型换 harness 差一个数量级，具体差在哪？
期望要给能量化的改动：① 错误消息可操作化：报错从异常堆栈改成「参数date需YYYY-MM-DD，你传的是『上周』」，直接影响自愈率；② 工具集从二十几个收到不到十个、补负向边界，选择准确率回升；③ 裁剪工具结果 + 目标约束搬进结构化状态，长任务后半程不再断崖。都没换模型信号举得出改动 + 观察到的指标方向（哪怕是几十条样本的粗糙对比）→ 真调过；只复述「harness 很重要」这句口号 → 是听来的新模型上来，harness 怎么处理？
期望顺序：① 先拿基线：同 harness 同评测集新旧各跑一遍，看成功率、成本、时延，成本反直觉，更强未必贵，必须实测；② 按标注的「模型补丁」逐类删，一次一类单独评测；③ 补丁会反噬：强制「先输出思考过程」和推理模型内部推理打架；④ 系统约束一行不动；⑤ 影子并行、按意图切信号给出「先基线、再逐类删、系统约束不动」这个顺序并提到补丁反噬 → 做过换代；答「换个模型名就行」→ 没经历过harness 债务怎么度量、怎么还？
期望度量看三个数：无评测覆盖的 harness 比例、每条补丁的最后验证时间、换代后未复查的补丁数；定性信号：有没有「没人敢动」的那段提示词。偿还的最佳时机是模型升级窗口，把减法冲刺固定成流程的一部分。防再生：新增补丁强制写清「解决什么问题、在什么模型上验证过、什么条件下可以删」信号提出「新增补丁必须写可删除条件」→ 是治理思维；只答「定期重构一下」→ 没有可操作抓手harness 归谁 own？团队里怎么协作？
期望让 harness 像代码一样被管理：提示词与工具定义进仓库、走review、有版本号，改动关联评测与线上指标。两种病：提示词散落多个服务各改各的（同一能力两处描述，行为不一致）；评测集是共享资产，被私藏就谁都能声称自己的改动更好。规模大了设平台层统管工具注册、trace 接入信号把评测集列为共享资产、指出「同一能力两处描述」这种真实病症 → 在多人团队做过；只答「大家一起维护」→ 没遇到过协作冲突团队很兴奋，说「新模型换上去我们现在的问题都能解决」，你怎么答？
期望不泼冷水但先量：一两天用现有评测集跑基线 → 先说清三个反直觉：① 能力涨了但行为变了，输出结构与调用时机都变，原补丁从帮忙变添乱 ② 成本方向不定，测单位任务成本别看单价 ③ 有些问题根本不是模型问题：工具描述不清、上下文缺信息 → 切换与减法分开做，同时干归因不了 → 影子并行、按意图灰度、留回滚 → 系统约束不动，顺手还 harness 债信号先要基线、把切换与减法分开、预判「有些问题不是模型问题」→ 主导过升级；跟着兴奋全量切换或一味说「先观望」→ 都缺决策方法
评分要点
- 能把 harness 说成有结构的八块，而不是笼统的"工程"
- 说得出能力差异的机理（模型看到什么、能做什么、失败后得到什么反馈、有几次机会）
- 区分模型补丁与系统约束，并知道两者随模型变强的不同命运
- 知道 2026 的常规动作是 harness 减法，且要逐类删以便归因
- 提示词与工具定义版本化、走 review、关联评测与线上指标
- 能给出 harness 债务的度量方式
- 加分：新增补丁必须写明可删除条件
- 加分：换代时切换与减法分开做，系统约束一行不动
- 加分：能指出"有些问题换模型解决不了"并说清是哪些