agentbelt 为 AI 编程助手统一工具权限

换一个 AI 编程助手，往往就要重新配置工具、权限和测试流程。agentbelt 想把这部分抽出来：Claude Code、Codex、Cursor 等应用负责调用模型，共用一套受策略约束、可审计的开发工具。

作者的核心主张是：操作边界应该由工具执行层负责，不能只靠提示词。它值得读的地方，是把分支隔离、人工批准、更新验证和客户端兼容性放进了同一套设计，但这些机制也有明确的保护范围。

共用一套工具，能解决什么问题

模型会运行命令，不代表不同应用会用同样的方式操作仓库。配置文件、权限提示、安全判断各不相同，切换应用时，已有工作流也容易跟着丢失。

agentbelt 通过 MCP（Model Context Protocol，模型上下文协议）把工具放到独立程序里。可以把它理解成一个公共工具服务：AI 应用提出调用请求，由它提供 Git、测试和工作流能力，不需要额外 API key，也没有第二个 LLM。

Git 操作集中在隔离的任务分支 agentbelt/<id>，允许提交，但不允许 push，也不执行 reset、rebase、clean 或 checkout。作者希望借此限制模型误操作的影响，避免出现 git reset --hard 或推错分支的问题。

测试工具负责发现并运行项目已有的检查，覆盖 npm、pnpm、yarn、Cargo、Go、Swift 和 pytest。repo-health、safe-commit 则是小型 JSON 工作流，可以串联检查与批准步骤。

它的价值首先是复用：换助手时，尽量保留同一套操作规则。

安全边界怎么落到执行层

agentbelt 把安全限制放进工具调用链，而不是只写进提示词。

所有动作都经过 broker，也就是统一接收和检查请求的中间层。插件不能直接运行命令或接触文件；broker 会核对插件声明的权限与核心策略，包括禁止 shell、只允许指定子命令，以及限制路径不能越出项目或触及 .git。

批准也有单独的边界。工作流中的批准步骤只能由用户在终端执行 agentbelt approve，没有对应工具供模型调用，因此模型不能批准自己的工作。

审计记录写入 .agentbelt/audit.jsonl，按作者描述会移除秘密信息。不过，原文没有交代脱敏规则及覆盖范围，不能据此认定日志绝不会泄露敏感内容。

另一处区分很关键：内置工具标记为 policy-only，有策略检查，但没有操作系统沙箱隔离。第三方插件则必须进入真实的操作系统沙箱，macOS 使用 sandbox-exec，Linux 使用 bubblewrap，禁止网络访问；缺少沙箱时拒绝运行。

这比笼统声称「工具安全」更有参考价值，因为两类工具的保护强度并不相同。

安装能验证，兼容也要有调用证据

安装入口只有一条命令：

npx agentbelt setup

注意这里的 setup：按作者描述，它安装固定版本、关闭安装脚本，并在切换前执行真实工具调用。更新时，agentbelt update 把新版本装在旧版本旁边，验证后切换；agentbelt rollback 可以立即切回旧版本。

原文没有给出具体版本号，也没有展开安装验证覆盖了哪些风险。

客户端兼容性采用了更具体的标准：必须在真实会话中成功调用工具，并在审计日志里留下记录。作者称，已验证 Claude Code、Codex、Cursor、VS Code 的 Copilot agent mode、DeepSeek Harness 和 LM Studio。

这套验证发现了三个实际问题：

• DeepSeek Harness 不告知工具服务当前项目，并从自身设置目录启动服务。agentbelt 因此拒绝把设置目录当作项目，并要求通过 --workspace 指定路径。
• Cursor 不替换全局配置中的 ${workspaceFolder}，但打开文件夹后会通过 MCP 提供项目位置，因此不再依赖这个占位符。
• LM Studio 需要在每次聊天中启用 MCP 插件，还需要选择其工具调用能够被解析的模型。

「能接上 MCP」和「能在正确目录里完成任务」，中间确实隔着不少细节。

我的判断

我认同把限制放到执行层，尤其是禁止模型自行批准，以及明确披露 policy-only。它们让用户能检查实际边界，而不只是相信助手会遵守约定。

但限制的覆盖面有前提。原文没有说明 AI 应用自带的终端、文件编辑和 Git 工具如何受控。如果模型仍能通过其他入口操作仓库，agentbelt 的策略就不能自动覆盖那些入口。

同样，执行项目测试也不天然等于安全：测试脚本本身可能写文件、启动进程或访问外部服务。原文没有说明内置测试工具对此有哪些额外限制。

和各助手原生工具相比，共享工具层有望减少重复配置，但也增加了一层服务需要维护。作者给出了兼容性实测案例，没有给出误操作率、性能或配置耗时的对照数据。效率收益目前应当视为经验判断，不能当成已被量化验证的结论。

能拿来做什么

• 如果经常在 Claude Code、Codex 和 Cursor 之间切换，可以先用同一个仓库验证检查结果与审计记录是否一致，再决定是否统一工具入口。
• 对前端或 Node 项目，可以让助手通过 agentbelt 运行现有 npm、pnpm 或 yarn 检查，并修复失败项；项目自身的检查质量仍然要由团队负责。
• 试用时应检查助手还保留哪些原生执行入口，并确认批准步骤必须经过终端，避免把局部工具限制误当成整个会话的权限边界。
• 更新后可以复跑一次常用检查流程，遇到问题再使用 agentbelt rollback，把版本切换是否可靠纳入验收。