09-工具设计五类工具与MCP生态Agent的手脚与通用设计原则引子光有聪明脑子也拧不开瓶盖先讲个段子。GPT-4 刚火那阵有人问它你会写代码吗它说会。再问那你能帮我改一下服务器上的配置吗“它沉默了。为啥因为大语言模型天生是个键盘侠”——脑子里全是知识手上却啥都摸不着。它看不见你的数据库改不了你的 YAML发不了那封催货邮件。这就是李博杰在《深入理解AI Agent设计原理与工程实践》里反复强调的一个核心观点Agent 大脑 手脚。大模型是大脑负责推理、规划、决策而工具Tool就是 Agent 的手脚是它感知和改变外部世界的接口。没有工具Agent 只是会说话的百科全书有了工具它才能干活。今天这篇我们就把手脚这件事掰开揉碎了讲。一、为什么工具是 Agent 的生死线书里有一个很形象的比喻Agent 被困在一个信息密室里唯一的窗口就是 LLM 的输入输出。它对外部世界的了解完全取决于别人塞给它什么文本。这就带来两个致命缺陷感知盲区Agent 不知道现在几点、不知道设备是否在线、不知道摄像头拍到的画面里有没有人拿错货。行动无能就算 Agent 推理出应该补货它也无法真的让仓库机器人去补货。工具就是打通这两堵墙的锤子。感知类工具负责看执行类工具负责干缺一不可。这也是为什么现在评价一个 Agent 框架强不强先看它的工具生态——工具的数量和质量决定了 Agent 的能力边界。二、工具分类全景五类手脚各司其职书中把 Agent 工具梳理成了五类我们结合无人售货柜场景逐个看。1. 感知工具Perception ToolsAgent 的眼睛耳朵负责把外部世界的信息翻译成 Agent 能读的文本。核心是多模态感知视觉摄像头抓拍 → YOLO 检测柜内商品余量、识别补货人员身份语音识别柜机旁顾客说的我要可乐传感读取温度传感器制冷失效预警、门锁状态、震动传感器数字接口查数据库、调 REST API 拉订单流水。感知工具的价值在于把非结构化数据图片、视频、传感器信号转化为结构化文本让 LLM 的推理建立在事实之上而不是猜测之上。2. 执行工具Execution ToolsAgent 的手负责对世界做出改变比如调用补货 API、下发开门指令、给结算系统提交退款。执行工具通常要求幂等、可回滚——因为 Agent 的一次错误操作可能比不做更糟。3. 协作工具Collaboration ToolsAgent 之间的对讲机当多个 Agent 组成团队比如一个管库存、一个管客服时需要消息总线、任务队列这类协作工具来传递任务与结果。书中强调协作工具要明确消息的语义边界防止 Agent 之间互相甩锅。4. 事件触发工具Event Trigger ToolsAgent 的闹钟解决没人喊它它也能主动干活的问题。典型有定时器每天凌晨 2 点盘点库存、文件监听日志文件出现 ERROR 就触发、Webhook设备上报故障即触发。这是第 10 篇的主角先埋个伏笔。5. 用户沟通工具User Communication ToolsAgent 的嘴把结果送达人发企业微信通知、推手机短信、给顾客弹退款确认。注意用户沟通工具要支持双向——不只是 Agent 发消息还要能收集用户回复作为后续输入。三、工具设计的通用原则书里这部分干货极密我提炼成六条条条都踩过坑。原则一能力表达形式——专用工具 vs Skill通用执行器专用工具为特定任务写死如get_stock(sku)。优点精确、可控缺点每加一个能力就要写一个新工具工具数量爆炸。Skill 通用执行器给 Agent 一套技能说明书Skill和一个万能执行器比如可以执行任意 Python 代码、任意 SQL让 Agent 自己编排。优点扩展性强缺点失控风险高。书中给出的建议是分层混合底层用通用执行器兜底上层用专用工具约束关键路径。好比售货柜日常查询用专用接口但遇到特殊报表需求允许 Agent 在一个隔离的 Python 沙箱里自己写脚本算。原则二工具粒度——整合与分离的权衡粒度过细get_shelf_1_stock、get_shelf_2_stock……Agent 的上下文被垃圾调用塞满推理速度断崖。粒度过粗一个get_all_info()返回 200 个字段Agent 直接看花眼。书中给出的经验是按一个原子任务划分粒度。查询某个 SKU 的实时库存是一个原子任务查询所有 SKU 的库存是另一个。让工具描述与 Agent 的意图天然对齐。原则三工具通用性设计同样的能力别给不同系统各写一套。比如售货柜品牌 A 用 MySQL、品牌 B 用 Redis 缓存库存底层不通但工具语义要统一——对外都叫query_stock(sku)内部再适配。这样 Agent 不需要理解每种系统差异通用性直接决定 Agent 的可迁移性。原则四工具描述的艺术工具描述不是写给机器看是写给 LLM 看的使用说明书。书里点出三个要点说清楚什么时候用“当用户询问某商品库存时调用本工具”说清楚参数含义sku是 13 位 EAN 条码不是商品名说清楚副作用“本工具会创建一笔退款单不可撤销”描述写得好LLM 的工具选择准确率能上一个档次写得烂它会把退货接口当成查询接口用。原则五参数传递保真性这是工程上最容易被忽视的一条。工具调用时LLM 生成的参数本质是文本进系统时要经历文本 → 结构化的转换。保真性要求强类型校验count必须是正整数负数直接拒绝枚举约束status只能是pending | paid | refunded别让 Agent 传一个PAIDD进来边界检查单价不能是负数、数量不能超过库存。一个不经校验的参数可能让结算系统多退一笔钱。校验是工具的最后一道防线。原则六工具设计演进工具不是一次设计定稿的。观察 Agent 在实际使用中的报错率、调用失败率持续迭代描述太泛就写具体粒度太粗就拆开参数频繁错就加约束。工具的进化速度就是 Agent 能力的进化速度。四、MCP给工具定个普通话工具多了问题就来了每个 Agent 框架一套工具协议A 家的工具 B 家用不了每次集成都要写胶水代码。李博杰在书中特别介绍了MCPModel Context Protocol模型上下文协议这是 Anthropic 推出的工具互操作标准可以理解为USB-C 接口——统一了 Agent 与工具之间的通信协议。MCP 的核心设计Server/Client 架构工具能力由 MCP Server 暴露如售货柜网关 MCP ServerAgent 作为 Client 按标准协议发现和调用能力发现DiscoveryServer 声明我有哪些工具Agent 启动时自动拉取清单不用写死标准化调用工具名、参数 schema、返回结果都有统一格式LLM 看到的是标准 JSON 描述。有了 MCP第三方售货柜硬件厂商只要实现一个 MCP Server市面上所有支持 MCP 的 Agent 都能直接长出手脚。这对 SaaS 平台的生态建设是战略级的——你的工具集越标准能接入的 Agent 越多。五、工具生态与工具选择的挑战工具多了也有甜蜜的烦恼。书里坦承两个现实挑战选择爆炸一个 Agent 挂 50 个工具LLM 的注意力会被稀释选错工具的概率上升。对策是按场景动态挂载工具子集——售后场景只挂售后工具补货场景只挂补货工具。信任问题工具来自第三方怎么保证它不坑你只能靠沙盒隔离 权限最小化 调用审计三重保险这在第 11 篇讲 Coding Agent 安全时还会展开。六、实战给无人售货柜 Agent 设计一双手最后按书中原则给我们的售货柜运营 Agent 落地一套工具集类型工具说明感知query_stock(sku)查商品实时库存参数为 13 位条码感知query_orders(status, time_range)查订单流水status 枚举限定感知detect_shelf(device_id)调 YOLO 视觉服务返回柜内商品余量结构化结果执行restock(device_id, sku, count)生成补货任务校验 count 为正整数执行control_device(device_id, cmd)下发开门/锁定/重启指令只允许白名单命令事件触发schedule_job(cron, task)注册每日盘点、每周库存预警任务协作notify_ops_channel(msg)向运维群推送消息含定级P0/P1/P2用户沟通send_customer_msg(order_id, text)向下单顾客发取货提醒/退款通知这套设计用一句话总结就是感知工具管看执行工具管干事件触发管主动协作与沟通管连接MCP 管标准。工具的真相是它决定了 Agent 的能力上限。五类工具也好、六条原则也罢最终都指向同一个命题——怎么让 Agent 在世界里看得清、下得去手、发得出声。把这双手打磨好后面的异步架构、Coding 能力、Agent 自举才都有得聊。 
长河君 · 2026/8/27 18:45:02 · 阅读 1.2k agent 工具设计：五类工具与MCP生态，Agent的“手脚“与通用设计原则
09-工具设计五类工具与MCP生态Agent的手脚与通用设计原则引子光有聪明脑子也拧不开瓶盖先讲个段子。GPT-4 刚火那阵有人问它你会写代码吗它说会。再问那你能帮我改一下服务器上的配置吗“它沉默了。为啥因为大语言模型天生是个键盘侠”——脑子里全是知识手上却啥都摸不着。它看不见你的数据库改不了你的 YAML发不了那封催货邮件。这就是李博杰在《深入理解AI Agent设计原理与工程实践》里反复强调的一个核心观点Agent 大脑 手脚。大模型是大脑负责推理、规划、决策而工具Tool就是 Agent 的手脚是它感知和改变外部世界的接口。没有工具Agent 只是会说话的百科全书有了工具它才能干活。今天这篇我们就把手脚这件事掰开揉碎了讲。一、为什么工具是 Agent 的生死线书里有一个很形象的比喻Agent 被困在一个信息密室里唯一的窗口就是 LLM 的输入输出。它对外部世界的了解完全取决于别人塞给它什么文本。这就带来两个致命缺陷感知盲区Agent 不知道现在几点、不知道设备是否在线、不知道摄像头拍到的画面里有没有人拿错货。行动无能就算 Agent 推理出应该补货它也无法真的让仓库机器人去补货。工具就是打通这两堵墙的锤子。感知类工具负责看执行类工具负责干缺一不可。这也是为什么现在评价一个 Agent 框架强不强先看它的工具生态——工具的数量和质量决定了 Agent 的能力边界。二、工具分类全景五类手脚各司其职书中把 Agent 工具梳理成了五类我们结合无人售货柜场景逐个看。1. 感知工具Perception ToolsAgent 的眼睛耳朵负责把外部世界的信息翻译成 Agent 能读的文本。核心是多模态感知视觉摄像头抓拍 → YOLO 检测柜内商品余量、识别补货人员身份语音识别柜机旁顾客说的我要可乐传感读取温度传感器制冷失效预警、门锁状态、震动传感器数字接口查数据库、调 REST API 拉订单流水。感知工具的价值在于把非结构化数据图片、视频、传感器信号转化为结构化文本让 LLM 的推理建立在事实之上而不是猜测之上。2. 执行工具Execution ToolsAgent 的手负责对世界做出改变比如调用补货 API、下发开门指令、给结算系统提交退款。执行工具通常要求幂等、可回滚——因为 Agent 的一次错误操作可能比不做更糟。3. 协作工具Collaboration ToolsAgent 之间的对讲机当多个 Agent 组成团队比如一个管库存、一个管客服时需要消息总线、任务队列这类协作工具来传递任务与结果。书中强调协作工具要明确消息的语义边界防止 Agent 之间互相甩锅。4. 事件触发工具Event Trigger ToolsAgent 的闹钟解决没人喊它它也能主动干活的问题。典型有定时器每天凌晨 2 点盘点库存、文件监听日志文件出现 ERROR 就触发、Webhook设备上报故障即触发。这是第 10 篇的主角先埋个伏笔。5. 用户沟通工具User Communication ToolsAgent 的嘴把结果送达人发企业微信通知、推手机短信、给顾客弹退款确认。注意用户沟通工具要支持双向——不只是 Agent 发消息还要能收集用户回复作为后续输入。三、工具设计的通用原则书里这部分干货极密我提炼成六条条条都踩过坑。原则一能力表达形式——专用工具 vs Skill通用执行器专用工具为特定任务写死如get_stock(sku)。优点精确、可控缺点每加一个能力就要写一个新工具工具数量爆炸。Skill 通用执行器给 Agent 一套技能说明书Skill和一个万能执行器比如可以执行任意 Python 代码、任意 SQL让 Agent 自己编排。优点扩展性强缺点失控风险高。书中给出的建议是分层混合底层用通用执行器兜底上层用专用工具约束关键路径。好比售货柜日常查询用专用接口但遇到特殊报表需求允许 Agent 在一个隔离的 Python 沙箱里自己写脚本算。原则二工具粒度——整合与分离的权衡粒度过细get_shelf_1_stock、get_shelf_2_stock……Agent 的上下文被垃圾调用塞满推理速度断崖。粒度过粗一个get_all_info()返回 200 个字段Agent 直接看花眼。书中给出的经验是按一个原子任务划分粒度。查询某个 SKU 的实时库存是一个原子任务查询所有 SKU 的库存是另一个。让工具描述与 Agent 的意图天然对齐。原则三工具通用性设计同样的能力别给不同系统各写一套。比如售货柜品牌 A 用 MySQL、品牌 B 用 Redis 缓存库存底层不通但工具语义要统一——对外都叫query_stock(sku)内部再适配。这样 Agent 不需要理解每种系统差异通用性直接决定 Agent 的可迁移性。原则四工具描述的艺术工具描述不是写给机器看是写给 LLM 看的使用说明书。书里点出三个要点说清楚什么时候用“当用户询问某商品库存时调用本工具”说清楚参数含义sku是 13 位 EAN 条码不是商品名说清楚副作用“本工具会创建一笔退款单不可撤销”描述写得好LLM 的工具选择准确率能上一个档次写得烂它会把退货接口当成查询接口用。原则五参数传递保真性这是工程上最容易被忽视的一条。工具调用时LLM 生成的参数本质是文本进系统时要经历文本 → 结构化的转换。保真性要求强类型校验count必须是正整数负数直接拒绝枚举约束status只能是pending | paid | refunded别让 Agent 传一个PAIDD进来边界检查单价不能是负数、数量不能超过库存。一个不经校验的参数可能让结算系统多退一笔钱。校验是工具的最后一道防线。原则六工具设计演进工具不是一次设计定稿的。观察 Agent 在实际使用中的报错率、调用失败率持续迭代描述太泛就写具体粒度太粗就拆开参数频繁错就加约束。工具的进化速度就是 Agent 能力的进化速度。四、MCP给工具定个普通话工具多了问题就来了每个 Agent 框架一套工具协议A 家的工具 B 家用不了每次集成都要写胶水代码。李博杰在书中特别介绍了MCPModel Context Protocol模型上下文协议这是 Anthropic 推出的工具互操作标准可以理解为USB-C 接口——统一了 Agent 与工具之间的通信协议。MCP 的核心设计Server/Client 架构工具能力由 MCP Server 暴露如售货柜网关 MCP ServerAgent 作为 Client 按标准协议发现和调用能力发现DiscoveryServer 声明我有哪些工具Agent 启动时自动拉取清单不用写死标准化调用工具名、参数 schema、返回结果都有统一格式LLM 看到的是标准 JSON 描述。有了 MCP第三方售货柜硬件厂商只要实现一个 MCP Server市面上所有支持 MCP 的 Agent 都能直接长出手脚。这对 SaaS 平台的生态建设是战略级的——你的工具集越标准能接入的 Agent 越多。五、工具生态与工具选择的挑战工具多了也有甜蜜的烦恼。书里坦承两个现实挑战选择爆炸一个 Agent 挂 50 个工具LLM 的注意力会被稀释选错工具的概率上升。对策是按场景动态挂载工具子集——售后场景只挂售后工具补货场景只挂补货工具。信任问题工具来自第三方怎么保证它不坑你只能靠沙盒隔离 权限最小化 调用审计三重保险这在第 11 篇讲 Coding Agent 安全时还会展开。六、实战给无人售货柜 Agent 设计一双手最后按书中原则给我们的售货柜运营 Agent 落地一套工具集类型工具说明感知query_stock(sku)查商品实时库存参数为 13 位条码感知query_orders(status, time_range)查订单流水status 枚举限定感知detect_shelf(device_id)调 YOLO 视觉服务返回柜内商品余量结构化结果执行restock(device_id, sku, count)生成补货任务校验 count 为正整数执行control_device(device_id, cmd)下发开门/锁定/重启指令只允许白名单命令事件触发schedule_job(cron, task)注册每日盘点、每周库存预警任务协作notify_ops_channel(msg)向运维群推送消息含定级P0/P1/P2用户沟通send_customer_msg(order_id, text)向下单顾客发取货提醒/退款通知这套设计用一句话总结就是感知工具管看执行工具管干事件触发管主动协作与沟通管连接MCP 管标准。工具的真相是它决定了 Agent 的能力上限。五类工具也好、六条原则也罢最终都指向同一个命题——怎么让 Agent 在世界里看得清、下得去手、发得出声。把这双手打磨好后面的异步架构、Coding 能力、Agent 自举才都有得聊。