Claude Code、Codex 等工具已参与代码分析、任务拆分、实现和测试；完整的多 Agent 工作台仍属于持续建设的方法设计。
Harness 设计参考：工作台的六层结构
Agent = Model + Harness。模型能力是公共供给，规则、上下文、任务边界和验证设施才会沉淀成个人工程能力。本篇给出一套可逐步落地的参考结构；它不是“已经全部生产运行”的成果声明。
一、什么是 harness，为什么值得专门写
Harness 指包裹在模型外面的全部工程设施：规则、工具、记忆、流程约束、验证闸门。行业在 2025-2026 年密集地把它确立为独立学科——Anthropic 复盘长时程任务的 harness 设计（评估器与生成器分离、上下文焦虑等失效模式），OpenAI 则给出了更极端的实证：有团队公开了以 harness 工程支撑长周期 AI 研发的实践。两家的共同结论可以压成一句：
模型能力决定下限，harness 决定这个能力能否稳定地变成交付。
这和本站方法论是同一件事的两面：方法论是流程规范（人怎么组织 AI），harness 是这套规范的物理安装（规范怎么变成环境里的默认行为）。方法论写在纸上会被忘记，安装进 harness 才会被执行。
二、全景：六层结构
参考工作台可以围绕 Claude Code、Codex 等工具按职责分成六层。每层回答一个问题：
| 层 | 回答的问题 | 参考实现 |
|---|---|---|
| 规则层 | 什么约束永远生效？ | 分层 rules 文件：common（语言无关）+ 语言特定（TS/Python/Go/Swift） |
| 技能层 | 什么流程可以一键复用？ | Skills：需求体检、TDD、code-review、验证循环、多模型协作等 |
| 代理层 | 什么职责需要独立上下文？ | 按需角色：planner、architect、reviewer、test、build-fix、doc 等；不追求固定数量 |
| 拦截层 | 什么底线不能靠自觉？ | Hooks：PreToolUse（动作前校验）、PostToolUse（格式化/检查）、Stop（收尾验证） |
| 记忆层 | 什么经验要跨会话留存？ | 项目 memory 索引 + 经重复验证后再晋级的规则 |
| 工具层 | AI 需要什么感知能力？ | MCP 接入：代码图谱（调用链/影响面）、网页抓取、设计工具等 |
这六层与工具工作台的三梯队引入顺序一致：规则层是零安装的纯文本，最先建；拦截层和技能层其次；工具层最后。
三、每层的设计决策与落地风险
规则层：分层 + 覆盖优先级
规则文件如果从一个大文件开始，常见问题是不同语言的约束互相冲突，规则越堆越长又触发上下文稀释。可采用以下结构：
rules/
├── common/ # 语言无关：coding-style、testing、security、git-workflow…
├── typescript/ # 语言特定，同名文件覆盖 common 对应项
├── python/
├── golang/
└── swift/
优先级规则：特定覆盖通用（类似 CSS specificity / .gitignore 的层叠逻辑）。典型冲突的解法：common 层主张不可变数据，golang 层显式声明"指针接收者修改结构体是 Go 惯用法，本层覆盖通用规则"——冲突不是靠删掉一边解决，而是靠声明优先级解决。
一个需要提前防住的安装风险是：目录必须整体复制，不能打平合并。common 和语言目录里可能存在同名文件，打平会静默覆盖通用规则，相对引用也可能断裂。这类细节说明：harness 的可靠性需要安装校验和回归测试，不能只看架构图。
规则 vs 技能的分界
两者最初混在一起，后来立了一条分界：规则说 what（标准、红线、检查单），技能说 how（带步骤的操作流程）。"测试覆盖率 80%、禁止硬编码密钥"是规则；"怎么按 TDD 写一个 Go 的表驱动测试"是技能。规则常驻上下文（必须短），技能按需调用（可以长）——这个分界本质上是上下文分层里"常驻层"和"按需层"的落地。
代理层：按"是否需要独立上下文 + 专职工具集"拆分
如果扩展到多个专职 agent，拆分标准应只有两条：职责需要干净上下文（如 reviewer 只给只读工具，避免“审着审着顺手改了”）；职责有专属的最小工具集（如 planner/architect 只读不写，修复角色只做最小 diff）。角色数量按真实任务增加，不把“多”本身当成熟度。
Agent 的工具集声明就是它的边界规格：不给写权限，比叮嘱一百遍"不要改代码"可靠。
拦截层：只放"违反即事故"的规则
Hook 有三个时机（动作前 / 动作后 / 会话结束），取舍标准与工作台一致：违反后果是效率低的进技能，是事故的才进 Hook。同时保留一条元规则：不使用全局跳过权限的模式——自动化程度可以高，但破坏性动作的确认权不让渡。Harness 的自动化是“默认动作自动化”，不是“风险审批自动化”。
记忆层：从"记住结论"到"演化经验"
可以采用两级结构：项目 memory（索引 + 单事实单文件）负责“这个项目的事实”；经验候选池负责收集反复出现的纠偏，经过人工确认和重复命中后再升级为正式规则。经验按项目隔离，防止 A 项目的做法污染 B 项目——经验复用和上下文污染是同一枚硬币的两面。
工具层：感知能力优先于操作能力
MCP 工具里最高价值的是代码图谱（调用链、影响面查询）：它把"改这个 DTO 会影响谁"从 AI 猜变成 AI 查——验证闸门里影响面分析的物理支撑。经验是：给 AI 加"看得更准"的工具，回报普遍高于加"做得更多"的工具——多数失误源于看错，不是做不动。
四、这套 harness 与方法论的映射
| 方法论环节 | Harness 安装点 |
|---|---|
| 需求体检 | 体检清单技能 + planner agent |
| 规格与结构决策 | 规格模板 + architect agent（只读）+ ADR 进记忆层 |
| 工作单执行 | agent 工具集边界 + tdd-guide 强制先测 |
| 验证闭环 | code-reviewer / security-reviewer（独立上下文）+ PostToolUse 检查 + Stop 收尾验证 |
| 缺陷回流 | 经验候选池 + 人工确认 + 规则文件更新 |
| 运行与解答 | 代码图谱 + 项目 memory 作为轻量知识层 |
方法论的每个环节都有至少一个 harness 安装点——这张表就是"纪律不靠自觉"的完整对照表。
五、落地前必须承认的局限
按本站自己的证据标准，这套参考结构在真正宣称落地前必须补三类证据：
- 评估基线：规则或角色配置变化后，要有固定任务集衡量成功率、返工和人工接管；没有基线只能说明“搭了”，不能说明“有效”；
- 规则防腐：定期回答“删掉这条规则，最近哪些任务会退化”，清理失效和冲突内容；
- 经验晋级门槛：一次纠偏不能直接升级为长期规则，要经过重复命中和人工确认，防止把偶然偏好固化。
Harness 的可信度不来自结构图，而来自持续命中的失败模式、可复现的验证结果和真实减少的返工。当前页面先保留设计参考，后续再按证据采集结果升级为个人实录。
六、如果你想复刻
参考资料
- Anthropic, Effective Harness Design for Long-Running Agents——生成器/评估器分离、上下文焦虑、harness 随模型升级而简化的实证。
- OpenAI, Harness Engineering——以工程约束支撑长周期 AI 研发的公开实践。
- 本站工具工作台——harness 组件选型与引入顺序的方法论。