什么是org harness

回复 群友 2523： 这个概念是 Ian Johnson 今年 6 月那篇《The Org Harness》里提出来的（Towards AI），它不是某个工具或框架，而是一种给 Agent 工程分层的方式。Joye 那句「做 org harness 也算某种程度的 infra」，说的就是把这一层当基础设施来建。 先说它怎么分层的，用洋葱模型来理解： 最内层是 project harness，也就是仓库级的那圈——CLAUDE.md、rules、skills、hooks，管的是「这个任务在该代码库里怎么写」。 往外一层是 delivery harness，管的是「哪个任务该进来、以什么形态进来、做完谁来验收」：backlog 打分、任务契约（contract，写清 scope in/out 和可验证的验收标准）、状态流转、人工介入点、merge gate。文章里的四段式是 Discover → Define → Dispatch → Verify。内层看不到自己的工作是怎么被立项、怎么被验收的，因为那些问题都在外层。 而 org harness 是再往外的一层，它包住组织里多个 delivery harness。 举个大白话的例子。一家公司后端团队和移动端团队各自有一套 delivery harness 在派活、跑验收。org 这层管的是所有团队都要遵守、不该各写一遍的东西：公司统一的安全基线和合规门禁（比如「任何仓库没过安全扫描不许 merge」）、共享的规则库、设计系统的 MCP server、统一的埋点规范。每个团队的 delivery harness 按需从外面这层加载，但不能横向去伸手拿另一个团队的规则。 放规则的时候有个挺好用的判据，就是问一句「什么变化会让这条规则失效」：换技术栈还成立的（比如 backlog 打分方式、状态流转、merge gate）放 delivery 层；换流程还成立的（比如安全底线、合规要求）就再往外放，到 org 层甚至更外面的 personal 层。所谓 personal harness 就是你自己那套 ~/.claude/CLAUDE.md、快捷键、提示词，换工作能带走，org harness 带不走。 没有 org harness 会出什么问题，文章说得很具体：两个团队各维护一份安全规则，一个更新了另一个忘了；或者同一个任务被两个 agent 各做一遍没人认领；或者一个改动依赖了另一个还没合的分支，主线直接红了。这些都不是 project harness 的 bug，是外面那层缺失。 所以它为什么算 infra：它不写业务代码，但决定了「什么工作以什么形态流到 agent 面前、什么结果允许流出去、公共能力怎么统一供给」。本质上是把组织里原本靠口头和人脑维持的那套协作流程，变成显式、可继承、可替换适配器的工程层。这跟 infra 的定义挺贴的——不直接产出业务价值，但决定了上层能以多低成本、多稳的方式跑起来。 顺带提醒一句，这还是一个偏新的圈内说法，不是已经统一的行业标准，目前主要就是这篇文章和围绕它的讨论在用。