什么是 Repo Harness？

回复 群友 1459： Repo Harness 是 Joye 那篇《Agent Harness 的三层》里的第二层，夹在"单个产品"和"整个组织"之间。原文的整个主线是：通用的补丁会被下一代模型学走，但 Harness 本身没变小，它在往外长——从产品，长到仓库，再长到组织。Repo Harness 就是中间这一圈。 它是在 coding agent 好用到人手一个之后才冒出来的。设想一个 5 人团队，每人配一个 agent，单独看每个都没问题，放在一起问题就来了，而且这些问题换更强模型也解决不了。原文列了几种典型：A 的 agent 改了一个接口约定，B 的 agent 不知道，还按旧约定写了三处调用；两个 issue 单看都合理，改的却是同一块逻辑、前提还互相矛盾，两个 agent 分头做完，合并的时候才发现冲突；还有历史遗留的那些事，比如这段代码为什么写得这么绕、哪个模块看着能删其实不能动、哪张表其实有两个地方在写。另外每个 agent 进仓库都要重新熟悉一遍模块怎么分、入口在哪、哪些目录是生成的别读，这份成本每个会话付一次，再乘以 agent 的数量。规范也只在人脑子里：提交信息怎么写、哪些改动必须先跑 check、哪些文件不能动，人可以靠默契，agent 只能靠写下来的东西。 没有 AI 的时候这些是怎么解决的？问同事。看不懂的代码问一句旁边的人，两个需求可能冲突开会时总有人提出来。知识一直都在，只是存在人的脑子里和聊天记录里，从来不在仓库里。现在干活的是 agent，它没有可以随口一问的同事。所以要把这些东西变成 agent 能读到、能用上的形式，也就是让仓库变得 agent friendly。 最基础的是四样：一份 AGENTS.md（Claude Code 里是 CLAUDE.md）、CI/CD、文档，以及一份 repo index，也就是给 agent 看的仓库地图。但远不止这些，怎么记录"当初为什么这样决定"、怎么让一个 agent 知道另一个 agent 正在改什么、怎么处理 issue 之间的依赖和冲突，大家都还在探索。 原文举了三个具体例子。一个是 Joye 自己博客仓库的 CLAUDE.md，里面规定不要直接 push 到 main，先推分支等他看过预览再合并——这条是出过一次事故才加的：agent 写完文章直接推了 main，而 main 是自动部署的，那篇文在他看之前就上线了。Agent 没做错什么，是没告诉它。第二个是 Claude Code 团队的 Robert，他说自己开发 Claude Tag 时主要精力就放这层，最关心开发环境对 Claude 够不够友好：能不能自己把软件跑起来，能不能从头到尾自己完成验证。第三个是 Bun 从 Zig 重写成 Rust，Bun 团队的 Jarred 每逢新一代模型发布就把这任务交给它试一次，直到有一代做成；按 Boris 的说法，那是一个 prompt 加一个调度大量 Agent 的工作流，跑了 11 天。这事能成的关键不在提示词，而在于 Bun 和 Node.js 本来就有一大套现成测试，结果对不对随时能验证。所以原文那句话是：能不能验证比指令怎么写更重要，而能不能验证取决于仓库这一层。 再往前想一步，当一个人已经 AI native，接下来要解决的就是让所在组织也 AI native。让一个仓库对 agent 友好，和让一个组织对 agent 友好，本质是同一件事：把原来只在人和人之间流动的信息，变成 agent 也能拿到的信息，区别只是范围从一个仓库扩到整个组织。 最后回到主线：这一层里通用的部分也会被收走——读仓库、跑 review 这些会被 coding agent 内置——但团队的规范和历史得自己写，而且越往外，属于自己、学不走的那部分占比越高。原文在这里：https://www.joyehuang.me/blog/20260912---codexharnessevolution/post