工具、权限与 MCP：编码代理如何变成真实系统
人们仍然常把编码代理说成“模型的故事”。
这其实倒置了重点。
模型只有获得一种受控方式去作用于周围世界，才会变成编码代理。这里有三件事必须合在一起：
- 工具表面
- 权限系统
- 外部能力集成层
Claw Code 是一个好的案例，因为这三者都能在公开 parity 仓库中看到。
系列地图
本文属于 Inside the AI Coding Agent Stack 系列：
- Claw Code 揭示的 AI 编码代理架构
- 为什么 AI 编码代理会同时使用 Rust 和 Python
- 工具、权限与 MCP：编码代理如何变成真实系统
- AI 编码代理中的 Hooks、插件与会话
- 面向 AI 代理团队的 Clean-Room 重写与 Parity Audit
工具是一种承诺
在编码代理中，工具不是普通函数调用，而是一个承诺：模型可以稳定、可重复地做某件具体事情。
常见能力包括读取文件、写入或编辑文件、glob 与 grep 搜索、shell 执行、网页获取、子代理委派、notebook 编辑和配置检查。
一旦模型拥有这些能力，产品性质就改变了。用户不再只是要想法，而是在要结果。工具层因此定义了代理真正的操作表面。
粗糙工具设计为什么会崩
早期系统经常把所有动作塞进一个巨大的执行表面：
- 一个 shell 工具做所有事
- 一个模糊的文件工具
- 一个宽泛的 integration 层
这看起来简单，直到用户需要控制。随后问题会一起出现：权限不可读、审计轨迹混乱、prompt 噪音变大、错误难以分类，用户也不再相信代理会做什么。
更好的模式是组合式工具设计：读和写分开，本地和网络分开，内置工具和扩展工具分开，高风险动作和低风险动作分开。
这正是 Claw Code 运行时和工具组织中能看到的方向，也是严肃编码代理会继续走的方向。
权限不是事后补丁
权限层决定用户能否放心让代理行动。
一个能读文件的代理很有用；一个能写文件的代理更有用；一个能执行 shell 的代理更强，也更危险。权限系统必须让这些差异可见，而不是把风险藏在 prompt 里。
好的权限模型应该回答：
- 这个动作会读取什么？
- 它会修改什么？
- 是否会访问网络？
- 是否会执行命令？
- 是否需要用户确认？
- 是否能被记录和回放？
权限不是安全团队最后加上的门锁，而是产品体验的一部分。用户越能理解边界，越愿意把更长的任务交给代理。
MCP 是能力总线
MCP 的意义在于，它把外部工具和上下文变成更标准的接口。
对编码代理来说，这很关键。代理不可能只靠内置工具完成所有团队工作。它需要访问文档、issue、数据库、监控、部署、设计系统和私有工具。没有标准化能力总线，每个集成都容易变成一次性 glue。
MCP 让代理可以用更统一的方式接入外部能力，也让权限和审计有机会围绕能力边界设计，而不是围绕临时脚本补丁设计。
工具、权限与 MCP 必须一起设计
这三者不能分开考虑。
如果只有工具，没有权限，代理会强但不可托付。只有权限，没有清晰工具，用户不知道自己在授权什么。只有 MCP，没有能力治理，扩展会很快变成混乱。
好的编码代理会把它们设计成同一套系统：
- 工具说明代理能做什么
- 权限说明代理在什么条件下能做
- MCP 说明能力如何被外部扩展
这也是模型从“会写代码的聊天机器人”变成“能参与工程流程的代理”的关键转折点。