HOL Guard 的代码地图扩展

我维护着 where-are-we（github.com/ngavrish/where-are-we），这是一个 CLI 工具，可以构建代码仓库的地图（代码在哪里、谁调用了谁、哪些测试覆盖了哪些代码），让编程智能体直接查询地图，而不用靠 grep 到处搜索。智能体使用它时，几乎所有操作都是读取。但有几个参数会改动地图之外的东西：- --agent-file 会重写 CLAUDE.md / AGENTS.md 中的一个章节 - --install-hook claude 会编辑 ~/.claude/settings.json，让工具在每次会话开始时运行 - --specs / --spec-cmd 会从工单跟踪系统获取数据，而 --spec-cmd 会针对每张工单运行一次命令 项目展示 当智能体在任务中途触发其中某个操作时，你往往要等到后来才发现：智能体指令或钩子变了，你却不知道原因。我当时的选择，要么是手动批准每一次调用（包括数百次无害的读取），要么是一次都不批准。所以我为 HOL Guard（github.com/hashgraph-online/hol-guard）写了一个扩展。HOL Guard 是一个开源的本地防火墙，位于智能体与 shell 之间。这个扩展上周已经合并。它会做什么：- 只读调用（--ask、--callers、重建地图）无需提示即可通过 - 写入仓库和调用工单跟踪系统时，会暂停并等待你批准 - 安装钩子会被标记为高风险 - 遇到未知参数也会暂停，防止工具的新版本绕过检查 它无法拦截什么：- 通过环境变量（SPEC_ROOTS、SPEC_FETCH_CMD、RUNS_API_READ）而非参数配置的工单跟踪系统访问 - 任何不经过智能体 shell 的操作，例如它之前安装的 git 钩子 - 它默认关闭；你必须在 Guard 中启用它 如果你也在开发供智能体调用的 CLI 工具，我很好奇你是怎么处理这个问题的。你会自行区分读取和写入参数，还是交给智能体运行框架处理？利益关系披露：where-are-we 和这个扩展都是我写的。我与 HOL 没有关联。