在 agent 系统里，工具不是中性的。

agent 会根据工具名称、描述、schema、参数说明和历史结果来选择工具。也就是说，工具注册表不只是“有哪些函数可以调用”的清单，它会影响 agent 的行动路径。

这就是为什么 tool registry 本质上是控制面。

工具描述会改变行为

一个人看到工具列表时，会带着常识判断风险。agent 看到工具列表时，主要依赖描述、上下文和模型推断。

如果一个工具把能力写得过宽，agent 可能误用它。
如果一个工具没有说明副作用，agent 可能把危险动作当成查询动作。
如果一个 MCP server 暴露了文件、网络、凭证或外部账号能力，agent 可能在不恰当的时机触发它。
如果工具描述被污染，agent 甚至可能被引导到错误 workflow。

所以工具描述本身不是文档细节，而是执行边界的一部分。

供应链边界已经扩大

传统软件供应链关心包管理器、依赖、构建脚本、CI 访问凭据和部署权限。AI agent 把这个边界继续扩大了。

现在需要被纳入治理的对象包括：

  • MCP server；
  • plugin 和 connector；
  • 本地 shell 脚本；
  • 自动下载的二进制工具；
  • IDE extension；
  • package install 和 postinstall；
  • 模型 provider、访问配置和代理层；
  • agent skill、AGENTS.md、hook 和 daemon；
  • 工具 registry 中暴露给模型的描述文本。

这些东西共同决定 agent 能看到什么、能调用什么、会相信什么，以及能把动作推进到哪里。

一个最小 tool registry contract

成熟项目不一定需要很重的工具平台，但至少应该为 agent 可见工具建立 registry contract。

每个工具条目应该说明：

  • 它解决什么问题；
  • 谁是 owner；
  • 读取哪些路径、网络或服务；
  • 是否会写文件、发请求、发帖、部署、删除或修改外部状态；
  • 是否需要凭证；
  • 输出是否可以作为证据；
  • 失败后应该 retry、rollback、ask 还是 halt；
  • 使用它需要 allow、ask、block 还是只读模式；
  • 什么时候不应该用它。

最后一条很重要。agent 需要知道工具的能力，也需要知道工具的边界。

MCP 不是天然安全边界

MCP 的价值是让工具集成更标准化。但标准化接口不等于安全边界。

一个 MCP server 可能只是只读查询工具，也可能能操作文件系统、调用外部 API、修改项目状态或触发业务动作。对 agent 来说，它们都可能以“工具”的形式出现。

因此治理重点不是“用了 MCP 就安全”，而是：

  • 这个 MCP server 暴露了哪些能力？
  • 这些能力是否被正确描述？
  • 哪些参数会产生副作用？
  • 是否有 path、domain、method 或 credential 限制？
  • 调用结果是否进入 trace？
  • 高风险调用是否经过 autonomy gate？

同理，插件、hooks、CLI 工具和本地脚本都应进入同一套视图。

对开源 agent 工程的含义

如果要把 issue-driven、autorun 或 project-specific harness 做成可复用项目，tool governance 不能是后补功能。

最小版本可以只做三件事：

  • 把工具注册表写成机器可读 manifest；
  • 给每个工具标注 side effects、risk level 和 evidence value；
  • 让调度器或 worker 在执行前读取这些字段。

这比写一段“请谨慎使用工具”的 prompt 更稳定。

核心判断

agent 的工具面，就是 agent 的权力面。

当工具、MCP、插件、本地脚本和依赖都可以被模型调用或影响模型判断时，tool registry 就不再是开发便利设施。它是运行治理的一部分，也是 AI 软件供应链的一部分。