作者：林岚｜OC 开发者生态编辑

开源项目 Boffin 试图解决代码 Agent 的一个常见问题：仓库规则越来越长，模型每次都收到整份说明，却仍会在当前改动中忽略真正关键的边界。

一句话结论：Boffin 的价值不在于再写一套提示词，而是按文件和改动范围选择约束，并强制要求与改动规模相称的验证。

AGENTS.md、CLAUDE.md 等静态规则文件适合说明整个仓库的通用习惯，但随着项目扩大，模型会同时看到数据库、前端、部署和安全规则。无关内容占用上下文，真正相关的限制反而被淹没。Boffin 把规则拆成版本化的 pack，在 Agent 准备编辑某个文件时，只路由适用部分。

它还区分 lite、full 和 max 三种清理强度。区别只影响重构野心，不降低安全、数据丢失和信任边界等底线。项目宣称支持 Cursor、Claude Code、Codex 和 OpenCode，并在编辑前后通过插件或适配文件介入。

项目列出的 DuckDB、FastAPI 和 LangChain 案例展示了小范围修改及测试通过数量。但作者明确承认这些是可复现案例，不是受控 A/B 基准。它们能证明工具可以运行，不能证明 Boffin 普遍让 Agent 更正确。

另一条边界更重要：Boffin 不是命令沙箱，不限制文件系统或网络，也不替代测试和代码审查。它只是告诉模型哪些架构契约值得注意，再要求提供外部验证。恶意命令、凭据泄漏和权限越界仍需要独立安全控制。

动态规则也有维护成本。路由错误会遗漏约束，规则包本身过时也会让 Agent 稳定地执行错误规范。团队仍需为规则指定所有者，并让 CI 成为最终裁判。

关键事实

• 项目：Boffin，MIT 许可证
• 核心机制：按当前文件和改动动态路由架构约束
• 支持环境：Cursor、Claude Code、Codex、OpenCode
• 验证要求：按改动规模选择检查
• 非目标：不提供命令隔离，不替代测试或人工审查

OC 判断

Boffin 指向真实问题：规则不是越多越有效，关键是相关性和执行闭环。它是否值得采用，取决于团队能否维护准确的约束映射，而不是安装插件后就期待 Agent 自动理解架构。

为什么重要

• 对开发者：可以减少每次会话重复解释局部架构的成本。
• 对团队：规则应像代码一样版本化、审查并由测试验证。
• 对 Agent 平台：上下文选择正在成为比上下文总长度更重要的能力。

参考来源

• GitHub：MicSm/boffin
• AGENTS.md：An open format for guiding coding agents