在 Better Harness 中，我们构建了一套分析体系，用于理解 Agent 的执行过程及其所处的工程环境。对应的开源版本，也已经支持从十余种 Coding Agent 中读取并分析不同层级的本地数据。但随着开发者开始并行使用多个 Agent、维护多个项目，并在不同设备间切换，核心问题不仅仅是：如何将分散的数据汇总？
真正的问题是：如何将分布在不同 Agent、项目和机器上的执行数据串联起来，形成一条从需求到验证的完整任务链路？又如何让这套能力不仅帮助个人更好地完成任务，也帮助团队把方法复用，并最终支撑组织规模化地交付？
这也是我们正在尝试探索的方向：让 Agent 不只是“会完成一次编码任务”，而是逐渐成为一种可验证、可复制、可治理、可运营的交付能力。
为什么：Agent 的挑战正在从“单点做成”走向“规模运营”
在使用一个新的 Agent 的时，通常我们只关心一个问题：它能不能把眼前的任务完成？然而一次成功，并不等于形成了稳定能力，所以在构建 Agent Harness，我们需要构建持续丰富的测试集来评测。
同样的任务交给另一位开发者、另一个 Agent、另一个项目，或者换到另一台机器上，结果可能完全不同。与此同时，上下文、工具、权限、项目规范、Skill、MCP、模型和验收方式中的任何差异，都可能改变最终结果。
因此，Agent 能力要真正进入团队和组织，需要经历三个阶段：
- 单点做成关注的是：这一次任务需要怎样的上下文、知识和工具能力等，才能产生可靠的结果产物。
- 团队复制关注的是：一次成功中的哪些做法，可以沉淀为 Skill、模板、MCP 服务和质量规则。
- 规模运营关注的是：这些能力如何通过 Skill 市场、 MCP 网关、评测体系和模型网关，被安全地提供给更多团队。
这条路径对应三个逐步升级的问题，一次任务能力能不能做好，同类任务能不能稳定复用，成熟能力能不能安全、经济地规模化运行。
要回答这些问题，仅仅统计 Session 数量、Token 消耗或者工具调用次数是不够的，还需要建立围绕任务结果的采集与反馈机制，把 Skill 与 MCP 的执行过程、验收结果和资源消耗连接起来，再据此优化 Harness 资产、改进团队实践、补齐个人能力，最终降低完成一次合格任务所需要的整体成本。
关注点驱动：不同层级，需要不同的 Harness
随着 Builder 从个人走向团队和企业，Harness 解决的问题也随之变化：个人首先需要把一次 Agent 协作做好；团队需要让有效的方法稳定复用；企业则需要让成熟能力在安全与成本可控的前提下规模化运行。因此，Harness 的能力重点也应当分层设计。
个人：把一次 Agent 协作做好
今天，人人都可以成为 Builder，每天指挥多个 Agent 工作。对于个人而言，最直接的问题是：怎样让 Agent 一次把活干好？所以，我们需要：
- 先把任务说清楚，再让 Agent 动手：明确问题、改动范围、不做什么、交付物、验收方式和风险点，即我们的 spec 文档上的内容；如果 Agent 还无法准确理解完成条件，就不进入执行/实现阶段。
- 按任务准备上下文和工具：提供当前任务真正需要的项目说明、架构知识、领域知识和技能，只开放必要的目录、命令、工具与网络权限。
- 围绕真实产物与 Agent 协作：直接在代码 diff、网页或文档上标注、修改和验收，同时要求 Agent 给出验证结果（截图、测试等 ）。
因此，个人视角关注的是能否还原一次任务从定义、执行到最终验收的完整过程。
团队：把个人经验变成稳定的工程实践
而对于来说团队，关注的层面就有所不同，更关注的是如何把个人经验变成稳定的工程实践？
- 让环境可以被 Agent 操作：搭建统一安装、启动、测试和调试方式，使 Agent 能快速进入验证阶段、复现问题，并在失败后恢复。诸如于通过 Npm、Gradle 之类的标准构建工具，定义好构建任务。
- 让规则可以被自动检查：为架构、安全、测试和视觉要求配置对应的检查机制与验收方式，让规则真正进入执行流程。诸如于，能通过 Playwright CLI、Agent Browser 访问环境，来进行视觉检查。
- 让任务经验可以被持续沉淀：关联需求、会话、文件变化、测试、提交和评审证据，将反复验证有效的做法沉淀为项目规范、Skill、脚本、Hook、任务模板或质量门禁。
团队视角关注的不是某一次任务偶然成功，而是能否通过统一环境、自动检查和 Harness 资产，把一类任务持续做稳。
组织：让 Agent 能力以可接受的成本规模化运行
当 Harness 进入多团队、多项目和多设备协作后，组织需要解决的，不再只是某个 Agent 是否完成任务，而是如何基于跨任务、跨团队的真实证据，持续治理和优化交付能力：
- 建立跨 Agent 的任务证据链：关联需求、任务定义、Agent 会话、上下文与工具使用、代码变更、验证结果、人工验收和后续缺陷，使一次交付能够被还原、追溯和复盘。
- 治理可复用的 Harness 能力：结合轨迹分析，将经验证有效的 Skill、MCP、Hook、规则和评测集版本化，并明确其适用任务、质量要求与维护责任，避免“能用一次”的经验被无边界扩散。
- 基于结果决定投入与推广：按任务类型持续比较不同 Harness 方案的验收通过率、人工介入、失败重试、返工、资源消耗和后续缺陷，判断哪些能力应推广、优化、收窄或停用。
组织视角关注的不是“Agent 看起来是否聪明”，也不只是单次调用成本，而是能否把分散的执行活动转化为可验证的交付证据，并据此以可控的质量、风险和成本持续扩大有效能力的覆盖范围。
Better Harness 的初步尝试：从执行数据走向任务反馈
前面讨论的个人协作、团队复用和企业运营，最终都依赖同一个前提：我们能否知道一次任务是如何完成的、最终产生了什么结果，以及其中哪些能力真正发挥了作用。一次完整任务并不只发生在 Agent 的对话窗口中，而是穿过四层相互连接的 Harness：
向下，组织和团队目标被转化为任务边界、验收条件、上下文、工具与规则，由 Agent 完成计划、执行、验证和恢复；向上，真实产物经过自动验证或人工验收后形成任务证据，并将反复验证有效的方法沉淀为 Skill、MCP、Hook、规则或任务模板，为团队复用和组织决策提供依据。
这也是 Better Harness Dashboard 想做的事情，尝试把分散的 Agent 执行记录转化为可观察的任务反馈，以降低人与 Agent 的摩擦，从而让组织减少 token/credits 的浪费，以放在更有价值的任务上。
目前，Dashboard 已能跨项目查看 Skill、MCP、模型、Token 和工具调用等活动，帮助个人和团队识别能力是否被使用、使用发生在哪些阶段，以及是否存在异常消耗或执行摩擦。
但“被调用”并不等于“有效”。下一步需要把这些活动与任务意图、验收条件、真实产物和人工验收连接起来，逐步回答：
- 任务是否真正通过验收？对应的 Edit 文件工具的调用，引发的提交是不是在对应的 release 版本中。
- Skill 和 MCP 是否用在了正确阶段？在 Skill、MCP 执行过程中有多少的调用失败、错误场景，应该要合理的统计进来，以便反馈给发布者进行改进，减少额外的 token 消耗。
- 哪些消耗没有转化为有效进展？是否存在消耗巨大的无效长程任务等。
- 哪些经验值得沉淀为团队 Harness 资产？诸如于在当前阶段 400k 的上下文能达到最好的成本和效果平衡等。
因此，Dashboard 不是最终目标，而是任务反馈的观察入口。现阶段最重要的，是先把执行活动与真实结果连接起来，为持续改进 Harness、降低合格任务的整体成本建立基础。后续，则可以结合这些经验和教训，将更多的最佳实践分享给更多的团队。
欢迎体验 Better Harness
Better Harness 当前仍在快速演进。你可以先在本地运行 Harness UI，看看它如何读取项目中的 Agent、Skill、MCP 和任务数据：
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 Issue。
- 通过版本化组件、评测集和受控实验，验证 Skill、MCP 与规则等改动是否有效。
- 完善成本与路由评估、长期任务基准，以及不同 Agent 和操作系统的真实验证。
欢迎提交 Issue、贡献 Adapter，或参与 Better Harness 的设计与验证。
