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

比如让 Coding Agent 修一个“登录后白屏”的 bug： 只有仓库和提示词，它可能改完代码就说修好了。 配好 repo/workspace harness，它能自己启动应用、复现白屏、查看浏览器报错和服务日志、改代码、跑测试；验证失败，就带着错误继续修。 支撑这个闭环的文档、脚本、工具、环境和检查机制，就是这里说的 harness。不是单独一份 AGENTS.md，也不一定是某个框架。 repo 和 workspace 可以这样分着理解，不过这不是统一的标准分类。 repo 层：让 Agent 看得懂、改得对。 例如，AGENTS.md 提供导航，架构文档解释模块边界，统一命令负责构建和测试，lint 与结构测试强制检查依赖关系。 “不允许 UI 直接访问数据库”，写在文档里只是提醒；变成检查规则，违规后直接报错并给出修复提示，才形成可执行的约束。 workspace 层：让 Agent 跑得起来、观察得到、任务之间不互相干扰。 例如，每个任务有独立 worktree，自动准备依赖、端口和测试数据，可以启动应用、访问浏览器和日志，结束后清理进程与临时资源。 注意，worktree 只隔离代码工作目录，不等于安全沙箱；进程、凭据、网络权限需要另行控制。 值得看的博客： OpenAI：Harness engineering: leveraging Codex in an agent-first world 2026 年 2 月 11 日 https://openai.com/index/harness-engineering/ 这篇最贴你的问题，而且有具体团队实践。重点看三个地方： 把 AGENTS.md 当目录，而不是塞满所有规则的大手册；详细知识放进仓库内的版本化文档，按需读取。 用自定义 lint 和结构测试约束架构，把“请遵守”变成“违规会被检测出来”。 让每个 worktree 都能独立启动应用，接入浏览器操作，以及临时的日志、指标、追踪环境，让 Agent 自己复现和验证问题。 它的核心经验是：Agent 卡住时，别只改提示词催它努力，而要找缺失的工具、知识或反馈。但文中也明确说，这种自主能力依赖他们专门建设的环境，不能直接推广成“任何仓库都能做到”。 Addy Osmani：Agent Harness Engineering 2026 年 4 月 19 日 https://addyosmani.com/blog/agent-harness-engineering/ 适合补充整体认识：把 Agent 周围的支撑设施当作需要持续维护的工程产物，而不是一次性配置。读的时候可以关注一个问题：Agent 犯错以后，如何改进环境，让下一次不再依赖人工提醒。 简单区分：prompt 告诉 Agent 怎么做；repo/workspace harness 则提供它做事的条件，以及判断有没有做对的反馈。