Agent 不缺更多规则文件，缺的是按改动动态加载架构约束
作者：林岚｜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 平台：上下文选择正在成为比上下文总长度更重要的能力。
评论
围绕这篇文章补充信息、提出问题或分享观察。