The New Era of Harness

解构

几个月前一开始听到 Harness Engineer 的时候，我还是从提示词/上下文工程的角度进行思考。
无非是又一个新包装出来的概念，其本质似乎还是用一些 skills 来约束 AI Agent 的行为，最终使其从多次随机的、不确定简单的模型调用，转向一个能解决实际问题的稳定工作流。
自 OpenAI 提出这个概念以来，对 Harness 这件事本身，较为广义(或者说更通俗)的定义是从 Vibe Coding 转向真正可以工作的 Long Running Tasks 的过程。可以是 Agent 架构本身 —— Claude Code, Codex, OpenCode etc.，也可以是 Skills framework —— Superpowers, Tacit(by me)。
但随着这几个月，各种模型不断刷新能力上线，此前我认为扮演核心角色的——标准化的SOP，文档系统，甚至各类 skills 本身，逐渐被内化为模型的一部分。那之前所做的一系列工作是否还有效？

做减法

Thariq 大佬这篇文章一定程度上解释了这个现象，即在使用 SoTA 时，不再需要大量的 System prompt 去约束和控制模型的行为，claude code 通过简化提示词、删除过时的工具释放了模型的能力。正如 Harness 本身所指的，过多的鞍具反而会成为模型能力的束缚。
前几天开源的 Deepseek Harness 同样是用做减法的方式提供了一种 Agent 开发的新思路，通过真正意义上的可插拔/可回滚来简化 Agent Loop 本身，即只关注最核心和最需要的部分。这样的好处是，最大程度上可以避免架构腐化，或者说降低代码腐化的速度；不会因为一个简单的小众模型适配、channels 或者一些小彩蛋就直接动到核心代码，这种插件化的好处是，对于 AI Coding 极度友好，只需要知道契约，便可以开始开发，而不需要关注各种分支逻辑和厚重的历史包袱，最重要的，不容易改坏。

还能做些什么

通用 Agent 的路似乎已经走到尽头了 —— 不是说走不下去，而是已经看到了罗马，未来只是如何在这个基础上进行迭代和整合。
但深度结合领域特性和业务逻辑的 Agent 还处在发展阶段，如何把以前的软件开发经验和思路迁移到 Agent 开发，Agent as a Service(AaaS) 或许才是(或者已经是)下一个发展的方向。
其实写着写着发现已经偏题太多了，不过探索和思考就是这样，可能也需要一个 Harness 来约束 Vibe Thinking? ;)

参考

Harness Engineering
The new rules of context engineering for Claude 5 generation models
Deepseek Harness