Harness —— Context over control
Harness 往往从个人实践开始。
最初，它通常只是一个人在本地搭出来的一套 Agent 使用方式。
我们会在本地给 Agent 准备一些 skill，告诉它某类事情应该怎么做；
写一些 rules，约束它不要犯重复的错误；
再整理一些 Knowledge，让它能够理解仓库、业务和团队过去做过的决定。
随着一次次开发和迭代，一套符合个人习惯的开发流程也会逐渐形成。
需求理解、技术方案、实现、测试、代码审查、提交、合入、发布……这些步骤被串在一起，让 Agent 能够沿着一条相对稳定的路径，把一件事情从想法推进到交付。
这套方式通常工作得不错。
因为规则和流程都来自同一个人的经验，每一个选择都符合他的习惯：哪里应该停下来确认，哪里可以自动继续，都很清楚。
但它有一个很明显的问题：大部分时候，它只在一个人的电脑上运行。
从个人习惯到团队 Harness
不是每个人都愿意花时间研究 Harness，也不是每个人都想自己维护 skill、rules、Knowledge 和 Workflow。
于是一个很自然的想法是：既然个人 Harness 有价值，为什么不把它沉淀到仓库里，让整个团队都能直接使用？
团队开始建设仓库级的 Harness。
仓库里逐渐有了更完整的背景知识、开发规范和可复用能力。
新人第一次进入仓库时，Agent 不再一无所知；熟悉项目的人也不需要反复解释同样的事情。
Knowledge、rules 和 skills 的复用通常比较顺利。
它们更多是在告诉 Agent：
- 这个仓库是什么；
- 有哪些约束；
- 遇到某类问题可以使用什么能力；
- 过去有哪些值得复用的经验。
真正容易出现分歧的，往往是 Workflow。
一个人把自己最舒服的流程沉淀下来，再推给团队使用时，很快就会遇到各种问题。
团队越努力推广和 push，反对的声音有时反而越多。
表面上看，像是大家不愿意接受新工具；但更核心的原因往往很朴素：它不好用。
对于已经形成个人实践的人，团队 Harness 可能还不如本地的 Harness Workflow 顺手；
对于其他人，它也可能不如直接和 Agent 协作自由。
原本是为了提效，实际却增加了等待、确认和流程成本。
如果 Harness 没有让开发变得更轻松，反而要求每个人放弃自己的工作方式，去适应一套固定流程，那么推广得越用力，阻力就越大。
这不是推广力度的问题，而是 Harness 本身需要解决的问题：重点不该是让更多人服从 Workflow，而是减少不必要的 Control。
有人觉得方案阶段太重，有人希望实现前多做一次 Review；
有人习惯快速写一个 Demo 验证方向，有人希望一开始就把完整方案想清楚。
更重要的是，不是所有需求都适合同一套流程。
一个明确的小改动、一次线上问题排查、一个探索性需求和一次正式的大型交付，本来就不应该走完全相同的路径。
于是仓库里开始出现越来越多的 Workflow：
每增加一种场景，就再增加一条流程。
Harness 看起来越来越完整，使用起来却不一定越来越轻松。
为什么需要通用 Harness Agent
当一个仓库的 Harness 逐渐成熟后，下一个自然目标是把它复用到更多仓库。
但真正开始迁移时，经常会发现：能够直接复用的东西并没有想象中那么多。
不同仓库有不同的目录结构、构建方式、测试工具、发布平台、协作习惯和业务知识。
原来运行良好的 Workflow，换一个仓库后往往需要重新调整。
最后，每个仓库仍然要从头搭建一套 Harness。
于是又出现了一个新的目标：做一套通用的 Harness Agent。
这里的“通用”，不是再造一个替代 Codex 或 Claude 的 Agent，也不是让所有仓库使用同一套 Workflow。
它更像一层运行在不同 Agent 之上的开发基础设施：不耦合具体业务和仓库，通过配置加载各自的 Context 与能力，并统一提供资源隔离、状态恢复、依赖编排和交付保障。
每个仓库只需要沉淀自己的 skills、Knowledge、rules 和可执行能力，通用 Harness Agent 负责把它们交给当前 Agent 使用。
简单任务当然可以直接使用 Codex 或 Claude。
Harness 的价值不在于比 Agent 更会写代码，而在于让它进入不同仓库时拥有正确的 Context，并能跨会话、跨仓库持续、可靠地把事情做完。
这个方向听起来很合理。
但如果通用 Harness Agent 仍然内置了一套固定的开发流程，那么它只是把某个仓库的 Workflow，提升成了所有仓库都要接受的 Workflow。
它解耦了业务，却没有解耦工作方式。
Workflow 是经验，也是一种主张
走到这里，问题的根源逐渐清晰：
Knowledge、rules 和 skills 更多是在提供 Context，而 Workflow 往往是在表达某个人对“事情应该怎么做”的主张。
这并不意味着 Workflow 没有价值。
对于目标明确、交付路径稳定的任务，一条成熟的 Workflow 可以减少大量重复判断。
测试、提交、CI、部署、合入和发包，本来就有比较明确的依赖关系，也非常适合自动化。
问题在于，我们很容易把一条“经过验证的推荐路径”，逐渐变成“所有人必须经过的轨道”。
当 Workflow 成为 Harness 的中心后，Agent 不再根据当前问题选择下一步，而是在努力完成一套预先定义的流程。
用户也会逐渐失去主导权。
想快速问一个问题，要先进入需求分析；
想写个 Demo 验证一下，要先确认完整方案；
中间发现方向不对，明明只需要改一点，却不知道应该回退多少节点。
如果一次性顺利跑完，这套流程看起来没有问题。
但真实开发很少如此整齐。
需求会变化，方案会被推翻，测试会暴露新的理解偏差，某个节点可能失败，用户也可能在中途突然意识到：这件事情没有必要做得这么大。
开发不是一条只向前运行的流水线。
Context over control
最近公布的字节领导力原则中，有一条叫“Context over Control”。
它强调充分共享信息和上下文，让不同的人参与进来，并基于充分的信息做出决策。
这同样适用于 Harness。
一个通用 Harness 要服务的不只是不同仓库，还要服务不同用户。
仓库决定了有哪些能力和约束，用户有自己的习惯和偏好，而每一次任务又有不同的清晰度、风险和交付目标。
真正通用的，不应该是一条所有人共同执行的 Workflow，而应该是一套能够理解这些 Context 的运行环境。
对于已经知道要做什么的任务，Harness 可以直接使用一条成熟流程：
对于仍然模糊的任务，Agent 应该可以先和用户一起探索，快速修改、快速验证，甚至做一些带有 Vibe Coding 色彩的尝试。
当方向逐渐清晰，再自然地进入正式交付。
这两种状态不应该是两个割裂的产品，也不应该要求用户重新开始一个任务。
理想的体验应该是无感切换：
先聊聊。
先试一下。
这个方向可以，正式实现。
实现差不多了，帮我检查一下。
没问题，继续创建 MR 和跑 CI。
先不要发布，我还想再改一点。
Harness 应该理解这些变化，并调整接下来要做的事情，而不是要求用户适应它已经生成的流程。
Agent 负责创造，Harness 负责不漏和收尾
理想的 Harness，不应该控制 Agent 在开发中的每一步探索与创造。
实现过程中，Agent 应该保持足够自由。
它可以读代码、尝试方案、写 Demo、修改实现，也可以随时和用户讨论。
Harness 更像一个不打扰人的副驾驶。
它知道当前需求、仓库规则、用户目标和已有改动，在必要时提醒：
- 是否遗漏了一条异常路径；
- 是否意外扩大了改动范围；
- 是否缺少测试；
- 是否还有没有验证的假设；
- 当前实现是否仍然符合最初目标。
这些提醒不应该自动打断开发，也不应该把每一次思考都变成一个节点。
而当实现结束后，Harness 可以更主动地接管机械工作：
- 格式化和静态检查；
- 运行测试；
- 检查 Diff；
- 创建提交和 MR；
- 等待 CI；
- 部署和验收；
- 合入和发包。
如果中间发现问题，它应该准确指出哪些结论已经失效、哪些检查需要重跑，然后让 Agent 回去做一个局部修复。
不是动不动就推倒整条流程。
Workflow 应该是快捷方式，而不是轨道
这并不意味着未来应该完全没有 Workflow。
成熟的 Workflow 仍然是一种非常有价值的团队经验。
它可以让明确任务快速进入稳定路径，也可以承载那些必须确定执行的交付动作。
但 Workflow 更适合作为 Recipe：
这是一个经过验证的推荐做法，你可以直接使用，也可以根据当前 Context 调整。
它不应该成为 Harness 唯一能够理解的运行方式。
Harness 真正需要守住的，是少数重要边界：
- 用户当前授权 Agent 做到哪里；
- 哪些远程操作需要确认；
- 什么证据才能证明测试通过；
- 什么条件下可以合入或发布；
- 任务中断后如何恢复；
- 需求变化后哪些已有结果仍然有效。
边界之间，应该给 Agent 和用户留下足够大的自由空间。
最后
过去半年多，Harness 的建设一直在追求更多确定性。
但越来越多的实践也在说明，一个好的 Harness 不应该让人时时感受到它的存在。
它应该了解仓库，也了解用户；
能够支持一套成熟的交付流程，也允许一次漫无目的的探索。
Harness 真正应该追求的，不是“零人工干预”。
开发本身包含判断、反馈和变化，必要的人机协作不是成本。
真正应该被减少的，是那些没必要的人工干预：重复确认、机械执行、无意义等待，以及为了适应流程而产生的额外操作。
该由人做判断时，Harness 应该提供充分的 Context；
该由系统机械执行时，就不要再让人反复介入。
它不会替每个人规定应该怎样开发。
它提供足够的 Context，让 Agent 做出更好的判断；
只在真正重要的边界上，提供必要的 Control。
这或许就是：
Harness —— Context over control.