为你的项目找一份 HARNESS.md
按回车打开第一条结果。
3 个条目
- exploratory-prototype
A deliberately thin agent harness for an exploratory prototype, proof of concept, demo, spike, or research experiment: one person, a coding agent supervised turn by turn, code that is thrown away or redesigned within a quarter, and nothing a wrong change can damage. Keeps only what still matters when everything else is disposable: isolation from host credentials, a secret scan, one command that runs the thing, a smoke check, and checkpoint commits. States the triggers for moving to a heavier design.
- production-engineering
A full agent harness for a production codebase maintained by a team for years, where a wrong change can reach users, data, or money, and coding agents work task by task with review in between or partly unattended. Hosted on GitHub or GitLab. Covers all seven layers: an isolated environment with scoped credentials and a tool inventory, a short entrypoint with routed knowledge files, fast and full verification an agent can run itself, pre-commit and CI gates behind one summary check, a written permission policy with a protected default branch and squash merges, specification-driven completion with recorded approval, and drift control with a harness self-check.
- solo-open-source-library
A medium-weight agent harness for a public open-source library with one maintainer who accepts outside contributions: a long-lived package whose public API other projects depend on, hosted on GitHub or GitLab, where issues and pull requests bring in text and code anyone can write. Lets a contributor's coding agent succeed without the maintainer, protects against prompt injection from public content, gates the public API with a snapshot, semantic versioning, and a changelog, asks for a short proposal only when the API changes, and keeps ceremony low everywhere else.
没有匹配的条目。条目是用英文写的,换成英文关键词或者少用几个词试试。
HARNESS.md 是什么
HARNESS.md 记录一个项目的 Agent harness 设计:编码 Agent 在哪里运行,读什么,怎样检查自己的工作,什么会拦住一次错误的改动,哪些事它可以不问就做。入口文件、权限文件、Hook 和 CI 配置都照着它来建。
它有两种用法。当作模板:从 hub 里挑一份存到项目根目录,告诉编码 Agent 这个项目要做什么,让它先对照你的项目核对文件里的 Context 一节,再把 harness 建出来;建完可以把文件删掉。当作锚定文档:把它长期留在仓库里,作为项目的设计记录,很少改动,只在检查 harness 有没有漂移或者要改进它的时候才打开。
写 HARNESS.md 时可以对照规范,读懂它不靠规范。Agent 即使从没见过规范,也没装任何插件,照样能读懂这份文件并照着做。
接下来看什么
文件里有什么
开头是一段简短的 frontmatter,写明文件的名称和说明;后面是标题、一段导言和正文,正文用哪些标题由设计决定。规范推荐下面十三个标题和这个顺序,没有一个是必选的。
- Context影响设计的项目条件:出错的代价、团队、平台
- Invariants每个任务都要遵守的规则
- Style代码应该是什么样,Agent 才能在里面工作
- File Structure设计要求的目录和文件
- EnvironmentAgent 在哪里运行,能碰到什么
- KnowledgeAgent 读什么,什么时候读
- FeedbackAgent 怎样验证自己的工作
- Gates拦住缺陷的检查
- Authority哪些事 Agent 可以自己做,哪些需要人
- Completion怎样对齐目标,怎样算做完
- Entropyharness 怎样与代码保持一致
- Open Questions还没有决定的事
- References这份设计依据的资料