给 Agent 接工具之前,先想清楚三个问题

给 agent 接工具,很多团队的默认动作是能连的服务都连上,工具越多看起来越强。Nikita Kothari 在 AI Engineer World’s Fair 主舞台上说,这个默认动作本身就是坑的来源。他是 Salesforce 做 Agentforce 相关工作的资深工程师,之前在 Amazon 和 LinkedIn 也做过工程,这场分享讲的是一件听起来很基础、却决定 agent 能不能上生产的事:工具接入层怎么设计。

原视频：https://www.youtube.com/watch?v=I2cbIws9j10（约 02:20:08 开始）

三种工具,三个比喻

Kothari 把团队过去一年踩过的坑归成三层,每层配一个日常比喻。

第一层是 CLI,他说这就像递给别人一把螺丝刀:工具就在那,直接用。agent 执行一条命令,拿到输出,继续往下走。他给了一条判断标准:一个工程师打开终端就能做的事,agent 大概率也该用同样的方式做。CLI 的好处很朴素:可读,任何人看一眼命令就知道发生了什么;可复现,凌晨两点线上出问题,把同一条命令复制到自己机器上跑一遍就能重现错误;可组合,多条命令能用管道串起来。CLI 已经用了五十年,不算新鲜,但经得住用。

第二层是 MCP(Model Context Protocol),他的比喻是 USB-C 转接头:以前每个设备都有自己专用的充电口,现在一个标准接口能接任何设备。一边是 Claude、GPT 这类编码工具,另一边是工单系统、代码搜索、错误追踪、监控这些服务。他举的例子是代码搜索:agent 调用一次 search 接口,传个查询就拿到结构化结果,背后是几百万个文件的索引,而且租户隔离在服务端就做好了。这也是 MCP 解决安全问题的方式:每次接一个外部服务,都要先走一遍授权。

第三层是 Skill,他说这是自己最喜欢的一层,现在工作里大部分重复动作都已经打包成了 skill。Skill 是一份包住 CLI 和 MCP 的结构化操作手册:满足什么条件、检查什么前置项、按顺序执行第一步第二步第三步、显式处理边界情况。这样做的好处是不用每次都靠 agent 现场猜,还能省内存、可标准化。一个 skill 只接真正用得到的两三个 MCP,不用把所有工具都摊在 agent 面前。

三个真实会出问题的地方

Kothari 用三个具体场景说明为什么这件事重要,而不是纸上谈兵。

第一个是上下文爆炸。他给了两组数字:把 50 个工具的 schema 塞进 agent 的上下文窗口,任务还没开始,60% 的思考空间已经用掉;同时挂 5 个 MCP server、55 个工具在线,任务还没跑,15000 到 20000 个 token 就已经烧掉了。行业默认的假设是工具接得越多越强,这两个数字说的是相反的事——工具描述本身在跟任务抢位置,agent 甚至会因为监控和部署这类工具的定义占满窗口,把前面聊过的内容忘掉。这个代价发生在任务真正开始之前,等于起跑线上就已经落后一截。

更麻烦的一种是隐形失败,问题不报错,却在没人盯着的地方悄悄发生。他举的例子是 agent 跑了七次工具调用去起草一个 PR,中间某一步出了错,PR 建到了错误的分支上,过程里没有任何人发现。团队损失的不只是重新做一遍的时间,更麻烦的是从此对这个 agent 处理同类任务的信心掉了一截——一次看不见的失败,代价往往比一次报错的失败更大。

第三个是安全暴露面。场景是凌晨两点排查客户 A 报的错,LLM 对查询和租户数据的访问权限比较宽,结果排查着排查着误读进了客户 B 的数据。这不是一个普通 bug,是多租户平台上的合规事故,足够让人从睡梦中惊醒。

怎么选,他给了一套具体标准

这是整场分享里最实用的部分。Kothari 给出三个问题,答完基本就知道该往哪层走。

第一个问题:这件事还有谁需要?只有当前这个 agent 用,CLI 就够;多个 agent 都要用同一个服务,上 MCP;多个工作流共享同一套流程,打包成 skill。

再往下想,你最担心哪种失败模式?在意透明和可复现,选 CLI,出错了能在自己机器上重放;需要验证租户隔离,选 MCP,服务端来保证隔离,不靠 agent 自觉;需要保证步骤顺序不能乱,选 skill。

第三个问题:上下文余量紧不紧?余量宽松,可以让 agent 自己探索所有 MCP 工具再决定用哪个;余量很紧,就必须上 skill 层,按需编排要用到的 MCP 工具,同时省钱、降延迟。

三个问题背后是同一条安全原则:隔离要建在基础设施里,不能建在 prompt 里。Prompt 挡不住注入攻击,基础设施挡得住。CLI 的风险半径是整个 shell 权限,靠沙箱和容器化兜底;MCP 的风险半径限定在显式暴露出来的工具范围内,服务端负责保证租户隔离。落到具体做法:不共享凭据给 agent,租户隔离必须在基础设施层强制,权限永远按最小够用给。

案例上也一一对应:修一个测试失败,不用打开所有 MCP 工具,看发布日志和 GitHub 就够,skill 里只接这两个;起草 PR 这类多步操作,第一步用轻量 CLI 命令弄清本地改了什么,不走重 API,第二步再用 git 命令在正确分支上开 PR。步骤能直接写下来,做成 skill 后还能持续改进;凌晨排查客户 bug,同样是查日志、搜错误模式、看最近发布,把这套流程用有限的 MCP 工具加 CLI 固定成 skill,比每次现场现想快得多。

这场分享在当天议程里的位置

这是 AI Engineer World’s Fair 官方日程标注的 Day 4(收尾日)主舞台的一场,排在 Agentic Engineering 赛道。当天主舞台上很多分享要么讲模型能力,要么讲某个具体产品案例,这一场少见地把”agent 怎么接工具”讲成一套完整的决策框架:把 CLI、MCP、Skill 摆在同一张坐标系里,给出什么时候用哪个的判断标准,比单纯罗列 MCP server 清单或者安利 skill 更接近工程实践。前面几场谈的多是模型能不能干成一件事,这一场补的是地基——agent 真正落地生产时最先绊倒人的,往往不是模型不够聪明,是工具这层没设计好。

我的延伸

我们之前在整理 MCP 相关笔记时留过一个判断:Skill 解决的是”教 agent 怎么做”,是行为能力;MCP 解决的是”让 agent 接入外部世界”,是访问能力。Kothari 这场分享把这个二分法往前推了一层——CLI 才是最底下那层”能不能直接执行”,MCP 和 Skill 都是在 CLI 之上做的封装,只是封装方式不同。三层拼起来,原来两分的框架才算完整。

还有两处印证也挺直接。我们拆过的 Skill 设计五层模型里专门有一层叫边界层,管的是”哪些行为不能擅自做”,这跟”隔离建在基础设施里,不建在 prompt 里”是同一件事的两种说法。另一条是”确定性判断交代码,不确定的推理才交模型”的分工原则,跟他那条 CLI 判断标准(工程师能在终端做的事,agent 也该用同样方式做)本质上是同一个判断:能写成明确步骤的事,不要交给模型现场猜。

我自己这几个月也在往这个方向走,把日常重复的诊断、巡检、发布类工作流一个个包成结构化的 skill,而不是每次现写 prompt。踩过的坑跟他说的很像:一开始图省事把能连的服务全接上,agent 反而在无关工具之间绕远路;后来收窄到每个 skill 只留真正要用的两三个工具,响应明显更稳,也更容易在出问题时定位到底是哪一步错了。如果你的 agent 项目正在纠结要不要再接一个新工具,不妨先问这三个问题:这事还有谁需要、你最怕哪种失败、上下文余量还剩多少。答案通常已经在问题里了。