Harness 决定 AI 协作上限
这两年，AI 协作讨论的重心已经变了。
以前大家更关心的是：
- 模型够不够强
- Agent 能不能自己调用工具
- 能不能一口气做完整任务
- 能不能替人多干一点活
但现在社区明显在往更深一层走。
大家讨论的不再只是“怎么让一个 Agent 动起来”，而是：
- harness
- SDD
- multi-agent
- 自动化工作流
- spec / plan / review
- compound engineering
这说明一件事：
问题已经不是 Agent 会不会干活，而是它怎么稳定地工作。
我自己这段时间越用越觉得，AI 协作真正的分水岭，不是你有几个 Agent，也不是你把链路堆得多自动化，而是你有没有一层 harness。
Agent 是能力单元。
harness 才是工作系统。
什么是 harness
我不想用概念词堆这个定义。
如果说得更实一点，harness 就是模型之外那一整层让 Agent 变得可工作的东西：
- 任务怎么进入系统
- 目标怎么定义
- 边界怎么约束
- 上下文怎么提供
- 工具怎么调用
- 过程怎么观察
- 结果怎么验证
- 经验怎么沉淀
也可以说得更直接一点：
harness 就是给 Agent 套上的工作壳。
没有这层壳，它会动；有了这层壳，它才开始能工作。
很多人会把注意力放在模型本身：哪个模型更强，哪个 Agent 更聪明。
但真实工作里，你很快会发现，模型能力只是底盘，能不能进入生产流，主要看外面那层壳。
为什么多 Agent 不是答案
“一个 Agent 不够，那我上多个 Agent。”
这条路很自然，所以社区现在会有越来越多 multi-agent 的东西。
问题是，多 Agent 不会自动变强，只会自动放大系统本身的优点和缺点。
如果这套系统里已经有这些问题：
- 目标没说清楚
- 边界没卡住
- 上下文不完整
- 验证标准模糊
- 结果没人兜底
- 经验不会沉淀
那你加一个 Agent，是一个 Agent 跑偏；
你加三个 Agent，就是三个 Agent 一起把偏差放大。
所以我现在越来越不相信一种很表层的理解：
“多 Agent = AI 团队 = 更强产出”
真实情况更像是：
没有 harness 的多 Agent，不是团队，是噪声放大器。
我为什么开始重视 harness
我不是因为看了几个前沿词，才开始讲 harness。
恰恰相反，是因为我在真实工作里不断撞墙，才越来越觉得这个东西重要。
我前面也接触过一些更重的工作流。
spec、plan、分步执行、review、自动化链路，这些我都不是没见过。
这些方法不是没价值。
问题是，真实工作里我越来越在意的不是“这个流程看起来有多完整”，而是下面这些更硬的问题：
- 它能不能减少返工？
- 它能不能降低跑偏概率？
- 它能不能让我中途插手？
- 它能不能让问题更早暴露？
- 它能不能把这次经验变成下次的起点？
因为真实工作里最贵的，从来不是多花几分钟讨论。
真正贵的是：
系统看起来已经跑起来了，但其实一路在偏。
spec 写得很完整，也可能从第 3 步开始偏。
plan 做得很漂亮，也不代表上下文真的对齐了。
多 Agent 并行跑起来很热闹，也不代表最终返工更少。
我后来越来越接受一个很朴素的判断：
AI 协作里最值钱的，不是“自动化得很满”，
而是“偏得更少，错得更早，收得回来”。
而这件事，本质上就是 harness 在解决。
Agent 只是能力，harness 才决定上限
单看 Agent，你获得的是一种能力：
- 能写
- 能查
- 能总结
- 能调用工具
- 能执行一段任务
但真实工作不是一串能力拼图。
真实工作是一个会被打断、会被修正、会因为上下文缺失而跑偏、还要持续推进的系统。
也就是说，能力本身不稀缺，协作结构才稀缺。
今天很多人对 AI 协作的关注点，还停留在：
- 怎么让 Agent 更聪明
- 怎么让它一次做更多
- 怎么让它更自动
但对我来说，真正决定一套系统上限的问题已经变成：
- 它是不是知道自己在解决什么问题？
- 它是不是知道哪些东西不能碰？
- 它有没有足够但不过载的上下文？
- 它做完之后，我能不能快速验证？
- 它踩过的坑，下一次会不会白踩？
这些问题都不是 Agent 本身回答的。
这些问题是 harness 回答的。
我现在怎么理解“够用的 harness”
我现在反而不太想把 harness 神秘化。
在我看来，一个 够用的 harness，至少要解决 5 件事：
1. 目标明确
这次任务到底要完成什么？
不是“优化一下”“改一改”这种模糊表述，
而是明确终点：什么算完成，什么不算完成。
2. 边界明确
什么要做，什么不要做，什么留给后面？
很多 AI 协作跑偏，不是因为模型能力不够，而是因为范围没有被说清楚。
边界不清，系统就会默认扩张。默认扩张，最后就一定返工。
3. 上下文受控
不是上下文越多越好，而是要刚好够。
给太少，它会瞎猜。
给太多，它会混乱。
好的 harness 不是把所有资料都塞进去，而是只给当前任务真正需要的那部分信息。
4. 验证闭环存在
它做完之后，怎么知道它做对了？
这是我越来越重视的一点。
很多自动化工作流只解决了“怎么生成”，没有真正解决“怎么验证”。
结果就是：看起来产出很多，实际上不敢放心接。
5. 结果能沉淀
这次踩的坑，下次还会不会再踩？
如果每次协作都只是一次性对话，那再高级也只是临时劳务。
真正有复利的系统，一定能把这次的判断、边界、约束、经验，变成下一次协作的起点。
为什么我不迷信更重的一层
说到这里，很多人会自然地往下推一步：
既然 harness 这么重要，是不是越重越好？
越完整越好？
越自动越好？
我的答案是：不一定。
我现在不再把 SDD 当主开发方法，不是因为这些方向没价值。
恰恰相反，我越来越承认它们背后的问题意识是对的：
AI 协作确实需要结构、需要约束、需要编排、需要复盘。
但在我当前的真实工作里，我更在意的是另一件事：
这套东西能不能稳定地降低返工，而不是只是看起来更高级。
如果一个更重的流程带来的是：
- 更高的 token 成本
- 更长的链路
- 更高的偏航概率
- 更复杂的修正成本
那它就未必比一个更轻但更可控的 harness 更好。
所以我现在越来越接受一种更现实的判断：
- 先讨论清楚，本身就是 harness
- 明确边界，本身就是 harness
- 控制上下文，本身就是 harness
- 建立验证，本身就是 harness
- 让经验沉淀下来，本身就是 harness
不一定非得上到一个特别重、特别全自动、特别“社区前沿”的形态，才叫 harness。
对真实工作来说，可控比炫酷更重要，连续性比完整口号更重要。
我的结论
社区往 harness、multi-agent、自动化工作流走，我觉得方向是对的。
因为大家终于开始面对一个更真实的问题：
AI 协作真正难的，不是让 Agent 动起来，
而是让 Agent 在一个可控的系统里稳定地产生价值。
所以如果今天再让我重新概括这件事，我会这样说：
- Agent 是能力单元，不是工作系统
- 多 Agent 不会自动变强，只会放大系统质量
- 真正决定 AI 协作上限的，是 harness
- harness 的核心不是更重，而是更可控
- 真实工作的关键，不是自动化有多满，而是返工有多少
我现在更关心的，不是再找一个更强的 Agent。
而是继续把这层工作系统设计得更好一点。
AI 协作真正的问题，从来不是“让 Agent 动起来”，
而是“让 Agent 在可控的系统里稳定地产生价值”。