repo Harness和组织级的Harness有什么区别，跟以前的产品级的有什么区别？

回复 群友 716： 可以把它们理解成三个层次：Agent 自己怎么干活、进一个仓库怎么干活、进一家公司怎么协作。不是三代替代关系，而是可以叠加。先说明，这三个叫法并不是统一的行业标准。 产品级 Harness：给 Agent 配“工作装备”。 比如一个 Coding Agent 如何调用工具、管理上下文、执行循环、失败重试、请求用户批准。重点是：这个 Agent 产品本身能否稳定完成任务。 Repo 级 Harness：给某个仓库配“入职手册＋自动验收”。 告诉 Agent 代码在哪里、架构怎么分层、怎么启动测试、哪些依赖不能跨层引用。通常落在仓库文档、AGENTS.md、测试、检查脚本和 CI 中。 重点不是多写几份提示词，而是让规则能被找到、执行和验证。 组织级 Harness：给多个团队配“协作制度＋公共设施”。 例如跨仓库任务由谁负责、哪些数据允许读取、什么改动需要审批、如何统一评测，以及失败经验怎样沉淀并推广。 它不是把所有仓库的 AGENTS.md 拼起来，而是处理单个仓库无法决定的权限、责任和协作边界。 拿“让 Agent 修改支付接口”举例： 产品级负责：读代码、改文件、运行命令，出错后继续处理。 Repo 级负责：告诉它支付模块的约束，并用测试检查有没有改坏。 组织级负责：决定它能否访问支付数据、谁审批上线、其他依赖这个接口的团队如何协调。 所以跟以前产品级的主要区别，是视角从“把 Agent 工具做好”，扩展到了“把 Agent 工作的环境和组织流程也做好”。同一个产品级 Harness，进入不同仓库、不同组织，实际效果仍可能差很多。 相关参考，讲仓库如何承载上下文和可执行约束： https://github.com/lopopolo/harness-engineering 如果这些词来自某篇文章，把原文发来，我可以按作者的具体定义对齐。