一个知道何时不该出手的自主 GitHub 机器人
Cookbook 的 GitHub agent 配方基于 OpenCode 和 Muse Spark，把 issue 分诊、PR 审查和 bug 修复自动化接入 GitHub Actions。其中最值得迁移的经验，是那些护栏。
这个机器人做什么
这份配方构建了一个自主的 GitHub Actions 机器人，承担四项工作：issue 分诊、pull request 审查、AI 垃圾代码（AI-slop）检测，以及提交 bug 修复 PR——运行在 OpenCode 上，以 Muse Spark 作为模型，借助 Model API 对现有 agent CLI 的即插即用兼容性。一切都跑在你自己仓库的 Actions 里，而不是别人的基础设施上。
克制是一项设计要求
让这份配方区别于天真的“把 LLM 接上 webhook”项目的，是它有多大篇幅在讲不出手。审查 agent 带着一份明确的“NOT slop”清单——列出它绝不能标记的改动类型，避免对合理的模式狼来了。分诊永远不会关闭 issue，那始终是人类的决定。bug 修复 agent 如果无法先复现 bug，就不会开 PR。Meta 的表述很直白：过度触发被当作一种故障模式，而不是可有可无的细节。
还有一套引用纪律：问答功能只能基于仓库文件作答，为自己的论断附上文件与章节的引用，当答案不在仓库里时拒绝编造。对于一个在公开讨论串里以你项目的口吻发言的机器人来说，“有依据才说话，否则沉默”是唯一站得住脚的策略。
AGENTS.md：一个文件统领整支队伍
配方中的每个 agent 都会自动加载一份共享的 AGENTS.md，其中承载着仓库上下文——让 agent 不必去猜项目惯例——以及它们共同继承的安全规则。Meta 称它是最需要为你自己项目改写的一个文件：随附的版本是一个针对 Python/pytest/uv 技术栈的完整示例，本意就是让你为自己的栈重写，但 SECURITY 一节要原封不动地保留。
分阶段上线，写权限要靠挣
部署指南是一个四阶段的信任阶梯。第一阶段：PR 审查与分诊，只读——在真实流量上验证质量，爆炸半径为零。第二阶段：显式的 /oc 命令，由维护者主动调用 agent 工作。第三阶段：由 label 门控的自动 bug 修复。第四阶段：加固——分支保护、CODEOWNERS、CI 门禁。写权限是靠履历挣来的，绝不会在第一天就授予。这和 Muse Code 自己的可审计性故事是同一套哲学：自主性的扩张速度，只能与验证能力同步。
Meta 是怎么验证它的
有个细节值得照抄：这份配方的验证方式，是让真实的 agent 以无头（headless）方式跑过一批脚本化的 issue 和 PR 场景——通过在 PATH 上放一个伪造的 gh 来重建 Action 的提示词，从而完全不触碰任何真实仓库——然后阅读它们的产出。测试你的机器人，要像测试任何不可信的自动化一样：先关进罐子里，再让它接触生产环境。可直接运行的配方在 cookbook 的 use cases 部分。