工具、Context 隔离与对抗性 Agent 分工
Harness Engineering 不是把 Agent 堆在一起干活。工具是对抗的武器，Context 隔离是分工的基础，对抗拆分是质量的保障，人的判断密度是最终的壁垒。
一、工具是对抗中的武器
Agent 面对同样的职责，有工具和没有工具，执行起来差别很大。
没有工具时，Agent 只能依靠阅读、推理和自我描述来判断问题；有工具时，很多判断会变成可执行、可重复、可验证的工程结果。
这种差异在对抗流程中最明显。Dev Agent、Code Reviewer Agent、QA Agent 都可以说自己做了检查，但如果没有工具，很多检查仍然停留在 Agent 的主观判断里。有了工具，检查就会变成更稳定的证据。
高效
lint、typecheck、test runner、coverage、build、Playwright 这些工具可以直接执行并给出结果，不需要 Agent 在 Context Window 里反复推理。它们节约的不只是时间，也节约 Agent 的注意力。
精准
不同工具服务于不同目标：
| 工具 | 检查内容 |
|---|---|
| lint | 规则检查 |
| SAST | 安全风险暴露 |
| Jacoco | 覆盖率 |
| SonarQube | 复杂度、重复、坏味道 |
| Playwright | 真实交互验证 |
| 自定义脚本 | 项目特定问题 |
工具不会把一个明确检查讲成一段泛泛而谈的建议。
无情
Agent 会解释，也会辩解；更重要的是，Agent 之间是会互相影响、互相说服的。Dev Agent 可能把一个没有意义的测试包装成"这里只是 smoke test""这里不重要""后续会补"。如果只是让另一个 Agent 看，它也可能被这些解释带过去。
但工具不会被说服。 一个没有意义的测试——比如 expect(true).toBe(true)，或者只检查对象 not null——在覆盖率、mutation testing、自定义检查脚本面前，没有意义就是没有意义，覆盖不到就是覆盖不到，规则不通过就是不通过。
这也是工具在对抗中最重要的价值：它把一部分质量要求变成不可协商的事实。 Agent 可以讨论原因，可以提出修复方案，但不能靠解释绕过工具暴露出来的问题。
工具是对抗的武器，不是对抗本身。工具能够暴露信号，但信号仍然需要 Agent 和人理解、判断、修复和沉淀。真正的对抗，仍然来自不同职责、不同标准和不同 Context 下的检查。
二、Context 隔离是 Agent 分工的基础
既然项目的长期记忆和知识不能全部放在 Context Window 里，接下来的问题就是：能不能在需要工作的时候，把相关的知识和记忆一次性都塞进去？
答案仍然是否定的。
企业级应用里的职责太多，对应的 context 也太多。业务规则、架构约束、接口文档、设计稿、测试策略、review 规则、发布流程、历史决策、当前状态——它们都可能是有用信息，但并不都应该在同一个时刻进入同一个 Agent 的 Context。
如果全部放在一起，不同职责需要的知识会互相干扰：
| Agent | 需要的内容 | 不需要的内容 |
|---|---|---|
| Dev Agent | 实现相关的代码、架构、接口和约束 | QA 验收路径、PM 进度信息 |
| QA Agent | 验收路径、测试数据、边界条件、验证工具 | 实现细节、代码审查规则 |
| Code Reviewer | 代码质量、架构边界、团队规范、风险模式 | 业务优先级、发布流程 |
| BA Agent / TL Agent | 业务规则、技术约束、分析材料 | 具体实现细节 |
| PM Agent | workflow、plan/story、status、协作信息 | 代码实现、测试策略 |
这些 Context 并不是谁多谁少的问题，而是谁和当前职责相关的问题。一个 Agent 如果拿到了大量和当前职责无关的信息，它并不会因此变得更可靠，反而更容易失去焦点——可能被其他职责的知识牵引，顺手做了不该做的事，也可能在本该专注的任务上遗漏关键细节。
Agent 分工本质上是 Context 分工
职责边界决定了 Agent 应该拥有哪些知识、工具和输入输出，也决定了哪些内容不应该进入它当前的 Context。
QA Agent 不应该顺手改代码，不只是因为职责上不该做，也因为它的 Context 并不是为了实现代码而组织的。
Dev Agent 不应该替人做业务取舍，也不是因为它"能力不够"，而是因为它的 Context 没有承载那些判断所需的完整业务、风险和责任信息。
Context 隔离不是为了制造墙，而是为了让每个 Agent 在自己的职责范围内保持专注。该看的内容进入当前 window，不该看的内容留在外面，必要时通过文档、report、status 和 human gate 进行交接。
三、为什么要拆分对抗
最直觉的做法，是让一个 Agent 把所有事情都做完：写代码、检查代码、运行测试、修复问题、总结报告。这样看起来最简单，也最符合"让 AI 自己完成任务"的想象。
但实践中很快会发现，这样不够可靠。
问题一：自己很容易说服自己
生成代码的 Agent 往往会沿着自己的假设解释自己的实现。它当然可以做自我检查，也应该做自我检查，但自我检查无法替代独立视角。实现者不应该独自决定自己的结果是否正确。
问题二：Context Window 很快被塞满
实现细节、审查问题、测试输出、修复历史、报告材料如果全部堆在同一个 Context 里，Agent 会逐渐失去当前职责的焦点。它既要记住怎么写代码，又要审查架构边界，又要验证用户行为，又要追踪测试结果。最后很容易变成什么都看过，却什么都抓不住重点。
问题三：发现和修复被混在一起
一个 Agent 如果在实现过程中发现问题，往往会顺手把它改掉。看起来这很高效，但问题、判断和修复过程会被压扁成一次代码变化。后来的人和 Agent 很难知道：到底发现了什么问题，为什么它是问题，修复依据是什么，是否和 Spec 有关，是否应该反向同步。
发现问题和修复问题本身是宝贵的项目经验。 如果它们没有被记录下来，代码的可追踪性就会被伤害。
对抗拆分的实践
在 Harness Engineering 的实践中，对抗需要被拆成不同角色：
Dev Agent → 实现 + 基本自检
Code Reviewer → 审查代码是否符合 Spec 和工程约束
QA Agent → 验证行为是否符合 Spec
这种拆分不是为了模仿人类团队的组织形式，而是为了保留软件工程中最重要的质量机制：实现不能自证正确，行为必须被独立验证。
不同 Agent 读取同一份 Spec，但带着不同职责和不同 Context 工作，既避免了自我说服，也避免了单个 Context 被过度填满。
对抗不是互相否定，而是互相校准。它的目标不是制造冲突，而是让代码在不同标准的反复检查中逐渐接近正确。
四、人的判断密度在升高
过去分散在团队里的判断，正在集中到一个人身上。
Harness Engineering 并没有降低对人的要求。恰恰相反，它提高了对人的要求。它降低的是执行负担和认知负担，但提高了人的判断密度。
在过去的软件团队中，这些能力通常分散在不同角色身上：
| 角色 | 关注点 |
|---|---|
| Product / PO | 价值、方向、最终确认 |
| BA | 业务规则、范围边界、需求澄清 |
| SA / TL | 架构、技术风险、代码质量 |
| QA | 质量、验证、异常路径 |
| PM | 流程、节奏、协调、进度 |
这些角色并不是在 Harness 中消失了，而是其中大量可执行、可整理、可验证、可报告的部分被 Agent 承接了。Agent 可以阅读材料、整理上下文、生成代码、运行测试、准备报告、追踪状态，也可以在不同阶段提供建议和检查。
正因为这些执行和信息处理负担被 Agent 接过去，一人团队才变得可能。但一人团队不是一个人亲手完成过去整个团队的所有工作，而是一个人通过 Harness 管理一组 Agent，让它们分别承担可工程化的职责。
意外收获
当很多执行工作被 Agent 承接之后，过去团队内部大量沟通、澄清和等待的成本也会被压缩。需求不需要在多个角色之间反复转述，判断不需要穿过很长的决策链路，反馈也更容易在同一个上下文中快速完成。
这会让需求落地变得更敏捷，也让人的判断价值被进一步放大。
代价
过去分散在团队里的判断能力，会越来越集中到 Human-in-the-Loop 的人身上。这个人需要判断方向、价值、范围、风险、质量、节奏和最终结果。Agent 降低了执行门槛，但提高了人的判断密度。
在 Harness Engineering 中，人的价值不是变低了，而是变得更高了。