repo/workspace的harness是什么？有这方面实践的blog吗？

可以把 repo/workspace 的 harness 理解为：围绕代码仓库和开发环境，给 Coding Agent 配的一套“工作设施、操作规则和验收反馈”，让它不只是能改代码，还能自己跑起来、发现错误、继续修复。 先举个例子。 你让 Agent 修“登录后页面白屏”。只有代码和聊天框时，它可能改完一个组件就说完成了。 配好 harness 后，它能找到登录模块的架构说明，在独立环境启动应用，用测试账号复现白屏，读浏览器报错和后端日志，修改代码，再跑端到端测试确认修复。如果测试失败，错误会回到执行循环里，而不是等你发现。 这里的文档、启动脚本、浏览器工具、测试、反馈机制和权限边界，共同构成 harness。不是单独一份 AGENTS.md，也不一定是某个框架。 repo 和 workspace 可以分两层理解，但这不是统一的标准分类。 repo 层：让 Agent 看得懂、改得对。 包括简短的 AGENTS.md 导航、架构和业务文档、统一的构建测试命令、可执行的依赖约束、CI 检查，以及可以跨会话接续的任务计划。 比如“不允许 UI 直接访问数据库”，只写进提示词属于指导；写成结构测试，违规就报错并说明修复方式，才有了可执行的约束。 workspace 层：让 Agent 跑得起来、观察得到、失败后能恢复。 包括每个任务的独立 worktree 或容器、依赖初始化、独立端口和测试数据、日志与浏览器访问、进程清理，以及中断后的状态恢复。 注意，worktree 只能隔离代码工作目录，不等于安全沙箱；进程、网络、凭据权限还需要单独控制。 有三篇值得读，前两篇最贴你的问题： OpenAI：Harness engineering: leveraging Codex in an agent-first world 2026 年 2 月 11 日 https://openai.com/index/harness-engineering/ 这是最直接的 repo 实践。重点不是“代码全由 AI 写”，而是他们怎么改造仓库： 把 AGENTS.md 当目录而不是百科全书；详细知识放进版本化文档；用自定义 lint 和结构测试约束架构；每个 worktree 能启动独立应用，还配临时的日志、指标和追踪环境，让 Agent 自己验证行为。 推荐看它如何把“人知道的规矩”变成“Agent 找得到、工具检查得了的规则”。 OpenAI：An open-source spec for Codex orchestration: Symphony 2026 年 4 月 27 日 https://openai.com/index/open-source-codex-orchestration-symphony/ 更贴 workspace 生命周期和多任务运行。它把 issue 映射到专属 workspace，由调度器负责启动 Agent、重试、状态对账和清理，把工作流提示与运行配置放进仓库里的 WORKFLOW.md。 推荐看：任务不再绑定某个聊天会话，Agent 挂了以后，系统如何围绕同一个任务继续工作。它属于 harness 外围的调度与运行管理，不只是仓库文档配置。 Addy Osmani：Agent Harness Engineering https://addyosmani.com/blog/agent-harness-engineering/ 社区作者的全景梳理，覆盖文件系统、Git、沙箱、hooks、上下文管理、长期任务和验证循环。 最值得借鉴的是它的迭代思路：Agent 某次犯错后，不只是再提醒一次，而是判断缺的是文档、工具还是强制检查，把改进沉淀进环境。但别把“好好配置就能解决所有模型问题”当成保证。 一句话区分：prompt 告诉 Agent 怎么做，repo/workspace harness 则把“做事所需的条件”和“判断做对没有的机制”真正搭起来。