组织级 Harness 工程：从任务证据到可规模化的 Agent 运营
Better Harness 可以检查多个 Coding Agent 宿主中的本地证据：Session、已配置资产、工具活动，以及它们所在的工程上下文。但当开发者开始在多个项目和设备上协同使用多个 Agent 时，核心问题已不只是如何汇总分散数据。
更难的问题是，如何将这些数据连接成一条从任务意图、执行到验证的交付链路；又如何让同一套能力既帮助个人完成任务，也帮助团队复用有效方法，并支撑组织规模化运营 Agent 驱动的交付。
我们正在探索的方向是：Agent 不应只完成一次编码任务，而应逐步成为一种可验证、可复制、可治理、可运营的交付能力。
从一次成功，到一种可运营的能力
采用一个新 Agent 时，最先关注的往往很简单：它能否完成眼前的任务？但一次成功并不等于形成了稳定能力。同一任务交给另一位开发者、另一个 Agent、另一个项目，或换到另一台机器上，结果都可能不同。上下文、工具、权限、项目规则、Skill、MCP 服务、模型和验收方法，都会影响最终产出。
因此，Agent 能力需要经历三个层级的成熟过程：
| 层级 | 核心问题 | 期望产出 |
|---|---|---|
| 单点做成 | 当前任务需要哪些上下文、知识与工具，才能可靠完成？ | 有明确边界且可验证的一次任务交付。 |
| 团队复制 | 一次成功中哪些部分可以稳定复用？ | 将一类任务做稳的 Skill、模板、MCP 服务与质量规则。 |
| 规模运营 | 如何将已经验证的能力安全、经济地提供给更多团队？ | 通过能力目录、网关、评测和模型路由进行受控分发。 |
这条路径对应三个逐步升级的问题：一次任务能不能完成、同类任务能不能稳定复用、成熟能力能不能以可接受的成本安全且可预测地运行。
仅仅统计 Session 数量、Token 消耗或工具调用次数，无法回答这些问题。Harness 需要建立围绕任务结果的反馈机制：将 Skill 与 MCP 服务的执行过程关联到验收证据和资源消耗。只有这样，团队才能优化 Harness 资产、改进工程实践、识别能力缺口，并降低完成一次合格交付的整体成本。
不同范围，需要不同的 Harness
随着 Builder 从个人走向团队和组织，问题也在变化。个人需要把一次 Agent 协作做好；团队需要稳定地复用有效方法；组织需要在风险和成本可控的前提下运营成熟能力。因此，Harness 的能力也应分层设计。
个人：让一次 Agent 协作形成完整交付
对于个人，最直接的问题是：怎样让 Agent 把这次任务做好？ 这需要：
- 先定义任务，再进入执行。 明确问题、改动边界、不做什么、交付物、验收方式和风险点。如果完成条件尚不清楚，任务就还不适合进入实现阶段。
- 按任务准备上下文和工具。 提供真正相关的项目、架构与领域知识，同时只开放任务实际需要的目录、命令、工具和网络权限。
- 围绕真实产物协作。 直接审阅和迭代代码 diff、页面或文档，并要求提供测试结果、截图等验证证据。
个人视角关注的是还原一次任务从定义、执行到验收的完整过程。
团队：把个人经验变成工程实践
团队需要的不只是让单次任务成功，而是回答：如何把有效的个人方法变成稳定的工程实践？
- 让环境可被 Agent 操作。 标准化安装、启动、测试、调试、问题复现与恢复方式，让 Agent 能快速进入验证循环。
- 让规则可被自动检查。 为架构、安全、测试和视觉要求提供可执行的检查与验收路径，而不是只将它们停留在文字规则中。
- 持续沉淀任务经验。 关联需求、Session、文件变更、测试、Commit 与评审证据，将反复验证有效的路径沉淀为项目规则、Skill、脚本、Hook、任务模板或质量门禁。
团队的目标不是偶然成功，而是用共享环境、自动检查和 Harness 资产，让一类任务持续保持可靠。
组织：以可接受的成本运营 Agent 能力
当范围扩大到多团队、多项目和多设备，问题变成如何根据跨任务的真实证据，持续治理和改进交付能力：
- 建立跨 Agent 的交付证据链。 关联任务意图、Agent Session、上下文与工具使用、代码变更、验证结果、人工验收和后续缺陷，使一次交付可以被还原和复盘。
- 治理可复用的 Harness 能力。 对已证明有效的 Skill、MCP 服务、Hook、规则和评测集进行版本化，并记录其适用任务、质量要求和维护责任。
- 以结果指导投入和推广。 按任务类型比较验收通过率、人工介入、失败重试、返工、资源消耗和后续缺陷，据此决定哪些能力应推广、优化、收窄或停用。
组织关注的并不是 Agent 看起来是否聪明，甚至不只是一次调用的成本；而是能否把分散的执行活动转化为交付证据，据此在质量、风险与成本可控的条件下扩大有效能力的覆盖范围。
任务反馈循环连接四层 Harness
个人协作、团队复用与组织运营，都依赖于一个共同前提：我们能否知道一次任务如何完成、最终产生什么结果，以及哪些能力真正发挥了作用。一次完整的任务会穿过四层相互连接的 Harness：
- 意图与验收。 组织和团队目标被转化为任务边界、验收条件、风险和责任归属。
- 执行环境。 上下文、工具、权限与规则决定 Agent 如何规划、执行、验证和恢复。
- 交付证据。 源码变更、测试结果、生成产物、评审结论和发布信息，说明了实际发生什么，以及什么被接受。
- Harness 资产与反馈。 反复有效的方法会沉淀为版本化的 Skill、MCP 服务、Hook、规则和任务模板；结果证据决定这些资产应扩大、调整还是停止使用。
这是一条反馈循环，而不是单向的数据看板：向下的路径让目标变得可执行，向上的路径将已验证的工作转化为证据和可复用能力。
Better Harness：从执行记录走向任务反馈
Better Harness 是这个方向的一次初步实践。它从让本地 Agent 活动和项目上下文可观察开始，而不是把一段对话记录当作全部交付。其本地 Harness UI 可以展示项目中的已配置资产与执行活动；当数据源提供相应证据时，也能观察到 Skill、MCP 服务、模型、Token 使用和工具调用等信息。
这种可见性是必要条件，但还不够。资产被调用，并不等于它产生了帮助。下一步是将活动与任务意图、验收条件、真实产物和人工评审连接起来，从而提出更有价值的问题：
- 任务是否通过了验收，相关变更是否进入了预期的发布版本？
- Skill 和 MCP 服务是否在正确阶段被使用，失败是否能被其维护者看见？
- 哪些资源消耗没有转化为有意义的进展？
- 哪些观察到的模式已获得足够证据，值得沉淀为可复用的 Harness 资产？
因此，Dashboard 是任务反馈的观察入口，而不是最终目标。真正的目标是建立一个让 Harness 改进和合格交付成本都可度量的任务反馈系统。
让推广决策可被证伪
组织级 Harness 需要的不只是可用能力的目录，更需要证据证明某项能力在明确条件下能让一类任务做得更好。对于给定任务类型，可以从以下信号比较不同方案：
- 验收与发布成功率；
- 验证和评审的完整性；
- 人工介入、重试与返工；
- 执行时间以及 Token 或 Credits 消耗；
- 后续缺陷或回滚信号；以及
- 每项参与的 Harness 资产的适用范围、版本和维护者。
这些度量并不会把工程判断简化成单一分数，但会让推广决策变得可检查：一项能力被扩大、收窄、改进或停用，都应有能够在交付证据中追溯的理由。
体验 Better Harness
Better Harness 仍在快速演进。可通过以下方式，在本地项目副本中启动 Harness UI：
git clone https://github.com/QoderAI/better-harness.git
cd better-harness
npm install
npm run harness-ui:dev
访问 http://127.0.0.1:3410 查看本地 Dashboard。接下来值得一起探索的方向包括：
- 连接 Session、任务历程、代码变更和交付结果，建立跨 Agent 的任务证据链；
- 从多个任务中识别可复用的工作模式，并沉淀为可追踪的 Harness 资产；
- 通过版本化组件、评测集和受控实验，验证 Skill、MCP 服务与规则的变更是否真的有效；以及
- 完善成本与路由评估、长期任务基准，以及不同 Agent 和操作系统上的真实验证。
欢迎提交 Issue、贡献 Adapter，或参与 Better Harness 的设计与验证。