工具、权限和 MCP：编码代理如何成为现实
人们仍然谈论编码代理，就好像模型就是整个故事一样。
那是倒退。
仅当模型获得对其周围世界采取行动的受控方式时，它才成为编码代理。
这意味着三件事必须结合在一起：
- 工具表面
- 权限系统
- 外部功能的集成层
Claw Code 是一个很好的案例研究，因为这三个因素都清楚地出现在公共平价回购协议中。
系列地图
本文是 AI 编码代理堆栈内部 的一部分：
- Claw Code揭示了AI编码代理架构的哪些内容
- 为什么AI编码代理同时使用Rust和Python
- 工具、权限和 MCP：编码代理如何成为现实
- AI 编码代理中的挂钩、插件和会话
- AI 代理团队的无尘室重写和奇偶校验
工具就是承诺
在编码代理中，工具不仅仅是函数调用。
这是一个承诺，该模型可以做一些具体且可重复的事情。
示例包括：
- 读取文件
- 写入或编辑文件
- glob 和 grep 搜索
- 外壳执行
- 网络获取和网络搜索
- 子代理委托
- 笔记本编辑
- 配置检查
一旦模型能够访问这些功能，产品就会发生变化。用户不再仅仅询问想法。用户要求结果。
这就是工具设计很重要的原因。
工具层定义了代理的真实操作界面。
为什么粗略的刀具设计会失败
一个常见的早期错误是将所有内容折叠成一个巨大的执行面：
- 一个 shell 工具解决一切问题
- 一款模糊文件工具
- 一个广泛的“集成”层
在用户需要控制之前，这看起来很简单。
那么所有的问题都会同时出现：
- 权限变得不可读
- 审计线索变得混乱
- 提示变得嘈杂
- 错误更难分类
- 用户对代理的实际操作失去信心
更好的模式是组合的：
- 读写分离
- 将工作区操作与网络操作分开
- 将本地工具与外部工具分开
- 将内置工具与扩展支持的工具分开
这是 Claw Code 的运行时和工具组织中可见的方向，也是我期望更多认真的编码代理遵循的方向。
权限不是事后的想法
第二个重要教训是权限系统是用户体验的一部分。
这听起来似乎是显而易见的，但许多人工智能产品仍然表现得好像安全性是你可以稍后再添加的东西。
你不能。
在编码代理中，权限设计决定了用户是否感觉系统是：
- 可预测的
- 可检查的
- 可逆的
- 足够安全值得信赖
公开的《爪法》材料使这一点变得具体。 Parity 存储库包括显式权限模式，例如只读、工作区写入和危险完全访问。命名很重要。它可以让用户快速推理系统。
良好的权限设计并不会消除权力。
它使权力变得清晰可见。
这是一个非常不同的目标。
好的权限设计是什么样的
编码代理的最佳权限系统往往具有以下几个特点：
1. 能力映射到权限级别
用户应该能够一眼看出为什么某个工具处于特定的风险范围内。
2.默认值是可以理解的
默认为令人惊讶的模式的系统甚至在第一个操作运行之前就会产生不信任。
3. 升级是显而易见的
如果任务需要的功率超过当前模式允许的功率，则升级路径应该是明确的。
4. 保留可审计性
用户需要知道哪些内容运行了、哪些内容被阻止以及哪些内容发生了变化。
这就是编码代理与通用聊天工具显着不同的地方。在聊天中，错误的答案很烦人。在代理中，错误的行为可能会付出高昂的代价。
MCP 改变了扩张故事
然后是MCP。
MCP 很重要，因为它为编码代理提供了一种更清晰的方式来扩展其内置工具。
代理可以连接到 MCP 服务器并获得对以下内容的访问权限，而不是将每个外部功能硬编码到产品中：
- 额外的工具
- 外部资源
- 远程服务
- 结构化数据源
这将架构从封闭的工具箱转变为功能总线。
如果您想要了解协议背景，请从我们的 MCP 指南 开始。较短的版本是这样的：
MCP 让代理构建者能够拓宽环境，而无需每次都重新发明集成模型。
这具有重要的战略意义，因为编码代理的长期价值不仅仅在于它如何在本地编辑文件。这是它将本地工作与团队系统的其他部分连接起来的程度。
为什么这三层必须设计在一起
这是人们经常忽略的部分。
工具、权限和 MCP 不是三个独立的功能。
它们是一个设计问题。
如果你在没有干净权限的情况下添加工具，系统会感觉很鲁莽。
如果在没有丰富的工具模型的情况下添加权限，系统会感觉很局促。
如果添加 MCP 而没有两者，系统将变成一个庞大的集成表面，且信任边界不清晰。
正确的心智模型看起来更像是这样的：
textTool surface -> defines what the agent can do Permission policy -> defines when and under what trust level it may do it MCP layer -> defines how the capability surface can expand over time
这个三元组将“带函数调用的法学硕士”转变为“可用的编码代理”。
建筑商应该借什么
如果我今天设计一个新的编码代理，我会从这个模式中吸取以下教训：
- 将工具视为产品原语，而不是隐藏的实现细节。
- 为权限模式提供人类可读的名称。
- 使本地和远程功能表面易于区分。
- 使用 MCP 来标准化扩展，而不是为架构的草率开脱。
- 使信任边界在界面中可见。
最后一点值得重复。
用户信任他们可以检查的系统。
如果感觉不透明，世界上最强大的特工仍然会失败。
为什么这对市场很重要
这种设计视角也有助于解释为什么人工智能编码工具存在差异。
某些产品针对编辑器内的低摩擦建议界面进行了优化。
其他人正在成为具有会话、工具、权限和可扩展性的完整操作环境。
两个类别都可以获胜。
但只有第二类真正在玩更深层次的“编码代理”游戏。
这是我认为市场讨论逐渐远离纯粹的基准讨论的原因之一。问题正在从“哪种模型最聪明？”转变为“哪种模型最聪明？”到“哪种环境可以让智能安全有效地发挥作用？”
这是一个更难的问题。
而且是一个更具防御性的。
最后拍摄
当人们说编码代理感觉“真实”时，他们通常的意思并不是散文变得更聪明。
它们意味着系统可以：
- 采取行动
- 尊重界限
- 连接到外部世界
- 在完成这三项工作时保持可理解性
那是一个工具问题。
权限问题。
还有 MCP 问题。
《爪码》值得关注，因为它让真相变得显而易见。
探索全系列
如需完整阅读路径，请访问 AI Coding Agent Stack 主题中心。它将本系列与 MCP、开发人员工具和生产型代理设计的相关报道结合在一起。