Agent EngineeringAgent 架构落地9 min
工具调用不是插件列表
Agent 接入工具的关键不是数量，而是协议、权限、失败处理和可验证输出。
Tool UseMCPAgent System
很多 Agent 项目一开始会把重点放在“接了多少工具”上。
这很容易跑偏。工具不是展示能力的清单，而是 Agent 改变环境的接口。一个工具只要能写文件、发消息、改数据、执行命令，它就已经进入了风险区。
工具调用的本质
工具调用解决的是这件事：
让 Agent 从生成文本，变成执行动作。
但只要 Agent 能执行动作，系统设计就必须同时处理四个问题：
- 它能做什么？
- 它不能做什么？
- 失败了怎么办？
- 怎么证明它真的做对了？
如果这四件事没设计好，工具越多，系统越不可控。
Claude Code 的启发
Claude Code 的工具环境很值得研究：文件、终端、搜索、浏览器、git、子 Agent。
这些工具不是孤立的。它们组合成了一个工程闭环：
- 读文件理解现状
- 改文件执行方案
- 跑命令验证结果
- 看 git diff 确认变更范围
- 用浏览器检查 UI
- 最终给出交付说明
这说明工具调用的价值不在单个工具，而在工具之间能不能形成闭环。
好工具要有结构化边界
一个 Agent 工具至少应该定义清楚：
- 名称：它解决什么问题
- 输入：参数类型和必填字段
- 输出：返回结构和错误结构
- 权限：只读、写入、外部请求、生产操作
- 幂等性：重复执行是否安全
- 审计：谁调用、何时调用、输入输出是什么
如果一个工具只有一段自然语言说明，它很难长期稳定。
工具不要直接暴露真实世界
我不喜欢让 Agent 直接拿到过大的工具权限。
比如“执行任意 shell 命令”很强，但风险也很高。更稳的方式是把能力分层：
- 常用安全命令可以直接执行
- 写操作需要限定目录
- 生产环境操作必须确认
- 外部系统要有只读模式
- 高风险工具要有审计日志
工具层应该像操作系统权限，而不是一个自由输入框。
MCP 的位置
MCP 很适合作为工具协议层，但它不是安全答案本身。
接入 MCP Server 前，我会看：
- 维护者是谁
- 是否官方或可信
- 工具是否默认只读
- 是否需要生产凭据
- 返回数据是否结构化
- 是否能限制作用域
Agent 的工具生态越开放，权限设计越重要。
应用到自己的项目
设计 OpenClaw 的工具系统时，我会把工具分成几类：
- 信息工具：搜索、读取文档、查询数据库
- 创作工具：生成文档、图片、Prompt、报告
- 工程工具：读写文件、运行测试、调用 CLI
- 协作工具：飞书消息、文档、表格、任务
- 控制工具：浏览器操作、部署、任务调度
每类工具有不同默认权限。信息工具可以更开放，控制工具必须更谨慎。
判断一个工具是否值得接入
我会问三个问题：
- 它是否能明显减少人工步骤？
- 它的输出是否能被验证？
- 它失败时是否可恢复？
如果答案都是否定的，这个工具接入后只会增加系统复杂度。
工具调用不是越多越好。好的 Agent 工具层，应该让行动更可靠，而不是让系统看起来更热闹。