Harness is the New Dataset：决定 Agent 上限的不是模型，而是系统
模型越来越强之后，很多人还在把主要精力放在「怎么写 prompt」上。
但真正的分水岭已经发生了：当模型能力过线，瓶颈会外移到系统层。决定一个 agent 能走多远的，不是模型 IQ，而是你围绕它搭的那套 harness。
一句话：Agent = LLM + Harness。
1）为什么 Harness 会变成关键变量
把模型想象成一匹野马：力量很强，但不稳定。
Prompt 只是在“告诉它往哪跑”；Context 是“给它看什么路况”。
而 Harness 更像马具 + 赛道 + 裁判系统：
- 让它能调用工具、拿到权限、读写记忆
- 让它在真实环境里执行
- 让它出错能回滚
- 让它产出可验证
- 让你能观测、能调试、能迭代
模型过线后，工程的胜负手就变成：系统能不能把不稳定的能力，稳定地转化为可交付结果。
2）Harness 不是一个组件，而是一套“运行系统”
把 Harness 拆开看，大致是六块（我用更工程化的说法复述）：
- 记忆与上下文管理：让 agent 在这一刻只看到最相关的信息，而不是被历史淹没。
- 工具与技能：把能力做成可调用的“外部动作”，并把工作法封装成可复用的 skill。
- 编排与协作：复杂任务怎么拆、怎么并行、怎么交接、怎么收口。
- 基础设施与护栏：权限、沙箱、失败恢复、安全边界。
- 评估与验证：有没有测试/检查闭环，能不能自己发现问题并修正。
- 追踪与可观测：日志、轨迹、成本、过程还原——系统必须可调试。
这六块可以再抽象成三层：
- 信息层：准备资源（让它看到该看的）
- 执行层：推进动作（让它按正确方式做）
- 反馈层：验证与复利（让它越用越好）
3）信息层：精准比求全更重要
长上下文不是免费午餐。上下文越长，注意力越容易被噪音稀释。
所以信息层的原则不是“尽量塞满”，而是“控制出场顺序”。
渐进式披露：把规则分层
最有效的做法往往是文件系统分层：
- 入口规则（少而硬）：最关键、最常用的元规则
- 按需加载的 skill：只在特定任务出现时加载
- 参考/脚本/日志：进入执行细节时再拿
这背后的本质是：让模型的注意力始终集中在当前最关键的那 1% 信息上。
工具少而精
反直觉但很现实：工具越多，不一定越强。
过度复杂的工具集，会让 agent 陷入决策瘫痪，也更容易产生幻觉式调用。
最好是几把“万能扳手”，而不是一整面墙的扳手。
用 subagent 做 context 隔离
当主线程上下文变重，把子任务丢给独立 subagent：
- 每个 subagent 在更干净的上下文里产出
- 主线程只负责调度与收口
这其实就是一种 context firewall。
4）执行层：把 research/plan/execute/verify 拆开
很多失败并不是模型不聪明，而是任务结构不对。
一个有效的工作流是强行拆成四段：
- research（查资料/方案空间）
- plan（确定路线与验收标准）
- execute（按计划执行）
- verify（验证，不通过就回到 plan）
关键点：执行阶段尽量背一个“干净上下文”。
更关键的是，人类最该介入的位置，不是事后 code review，而是事前 plan。
因为糟糕的计划会长出几百行糟糕的代码。
5）反馈层：复利来自“让同类错误永远不再发生”
我最认同的一句原则是：
只要发现 agent 犯了一个错，就花时间工程化解决，让它以后不要再犯同类错误。
这就是 harness 的复利：
- 把线上翻车沉淀成规则
- 把经验固化成校验与回归用例
- 把验证做成自动化闭环
最终你得到的不是一次性输出，而是一个持续变强的系统。
6）最重要的一句：Harness 本身就是数据集
真正高价值的新数据，不再只是静态语料，而是 真实任务中的执行轨迹：
- 它看到了什么信息
- 调用了哪些工具
- 做了哪些决策
- 哪一步容易错
- 什么反馈能把它校准回来
所以才会有那句判断：
The Harness is the Dataset.
竞争优势，不再只是“谁的模型更强”，而是“谁能持续捕获更高质量的轨迹，并把它们变成可训练、可迭代的闭环”。
结尾：别把工程焦点停在 Prompt
Prompt 工程当然还重要，但它已经不是主战场。
真正的差距会来自：
- 你是否把任务拆得足够工程化
- 你是否有验证与回滚
- 你是否可观测、可调试
- 你是否把每次失败都沉淀进系统
如果要把它落成两条“硬规则”，我建议就是：
- 任何 3+ 步任务默认先 plan；执行阶段用干净上下文。
- 每次失败必沉淀：写规则/加校验/加回归用例，让它以后不会再犯。