Harness Engineering 与多 Agent 协作效率

最近这段时间，在持续使用和观察 Agent 的过程中，我们越来越强烈地感受到：因为模型能力、Skill能力在持续进步，单个 Agent 的能力是在快速提升的。但新的问题出现了，很多复杂任务需要多Agent协作完成，过程经常很糟糕，执行很慢甚至会超时失败，所以真正的瓶颈转向“多个 Agent 能不能高效协作”。

过去 3 年，Agent 的工程重心一直在迁移

Prompt Engineering：关注提示词怎么写，怎么把一句话说对，怎么让模型更听懂。

Context Engineering：决定效果的已经不只是 prompt 本身，还包括 tools、memory、RAG、文件、system prompt 和任务上下文的组织方式。

Harness Engineering：Agent 驯化工程。真正重要的是使用者有没有建立起一套持续反馈、持续修正、持续协同的方法，让 Agent 越来越贴近自己的目标。

我最近越来越喜欢 Harness Engineering这个词，因为它比 Context Engineering 更目标导向，也更贴近真实使用场景。如果站在纯技术视角，Agent 效果不好时，我们很容易把问题定义成检索不准、工具不好用、记忆没接好、上下文没喂够。这样一来，优化责任就会不断收敛到技术系统本身，最后变成一句熟悉的话：再等等，等底层能力更强一点。

但 Harness Engineering 的视角不一样。它会把重点放在：Agent 的主人如何建立自己的使用方法、反馈机制、训练方式和协同习惯，让 Agent 越来越贴近自己的目标。Agent 能力强不强，它不再只是技术团队单方面的责任，它取决于“当Agent 卡住时，谁来补上下一步”，以及“它踩过的坑，能不能被其他 Agent 复用”。

Harness Engineering 不仅关乎人如何‘驯化’单个 Agent，更关乎系统如何‘驯化’一个由多个 Agent 组成的协作生态。

真正的瓶颈，从单点能力转向多Agent协作效率

当系统里只有 1 个 Agent 时，大家比的是单点能力；但当系统里同时运行 10 个、20 个 Agent 时，决定系统效率上限的变成了协作质量。

很多时候，"分工"并不是一个足够 agent-friendly 的描述。分工太接近人类的组织结构，强调固定职责和边界。但在复杂的 Agent网络中，更高效的模型是：谁当前拥有某种能力、资源、权限、环境、缓存或者经验，谁就临时补位，把卡住的那一步顶过去。这需要一层极其灵活的协作机制，来解决经验流动、资源共享和动态接力问题。

解法方法：论坛沉淀+协作网络

未来Agent 协作形态，应该同时具备两种能力：

“留下来”：把问题、过程、结论和修正记录下来，形成可以复用的知识资产。（论坛沉淀）

“连起来”：实时协作、动态补位、即时救火。（协作网络）

#论坛沉淀

当一个 Agent 遇到问题时，它首先应该能检索已有问题和相似 thread。找到现成解法，就直接复用；找到相似案例，就补充自己的环境和新线索；只有完全没有对应记录时，再创建新的问题。

通过论坛沉淀知识和过程互动，可以减少重复提问，减少重复踩坑，也减少经验只停留在个体记忆里的浪费。

#协作网络

系统需要持续生成一个“可求解问题池”，并把最近最值得处理的问题，推给最可能有能力解决它的 Agent。后者自己判断是否认领、是否补位、是否提供部分帮助，最后把有效解法沉淀成可复用的 resolution。

未来系统不再只依赖单个 Agent 的能力上限，而是开始依赖整个网络的补位效率、经验流动效率和知识复用效率。谁能更快地让问题被发现，谁能更准地把问题送到有能力解决它的 Agent 面前，谁能更稳定地把一次次补位经验沉淀下来，谁就更可能形成真正的系统优势。