MCP与CLI加Skill对比：Agent工具链的上下文成本与迁移判据

摘要：说MCP被抛弃的那批文章，引的是同一个数字，而且把它读错了。GitHub官方原话是合并Projects工具集省下约两万三千词元、降幅五成，并没有说整个服务从五万降到两万三；由此推出的两百五十倍差距，是二次加工的产物。Anthropic自己给的解法是让模型写代码去调协议，而不是弃用它，一个案例把十五万词元压到两千；微软则把Skill放上层、MCP压下层，还让MCP服务反过来对外公布Skill。本文梳理三笔成本账、四种误读和一套可执行的迁移判据。

先看一件常被跳过的小事。GitHub在2026年1月28日的更新日志里写了一句话：他们把Projects这一组工具合并成三个函数，因此减少了约两万三千词元的用量，降幅五成。

这句话被引用了成百上千次，传着传着就变了形，成了“GitHub官方MCP服务光是描述自己的工具就吃掉五万词元，后来砍到两万三”。再往下一步，有人拿这个五万去除以一份技能文件的两百词元，得出两百五十倍的差距，这个倍数至今还在中文技术圈里流传。

问题在于，那个五成的基数是Projects这一个工具组，并非整台服务器。官方那句话从头到尾没有给出全量工具定义的总词元数。整条推论链的第一块砖，是读者自己垫上去的。

纠正这个错误，并不是为了替MCP辩护。真实证据比编出来的数字更有说服力，指向的结论也更精确：MCP没有死，它被从“默认集成方式”这个位置上挪走了，挪走它的并不是CLI，而是Skill那一层。下面把账重新算一遍。

MCP词元数据被引错之后，是怎么滚成共识的？

这一节单独讲数字的传播，因为同样的滚雪球每个月都在发生，下一个雪球多半也拦不住，除非手上有一套拆解方法。

这颗雪球大致经过四步。第一步，官方发一句带百分比的话，句子里有个隐含的基数。第二步，二手报道留下百分比、丢掉基数，写成“整台服务从五万降到两万三”。第三步，有人拿这个凭空出现的五万，去除以另一个来源、另一种口径的两百，得出两百五十倍。第四步，这个倍数因为好记、好转发，反过来成了论证的前提。

四步走完，原始那句话里唯一可核实的数据，即降幅五成，反而没人提了。

用哪三个问题拆开这类倍数数据？

下次再看到某个惊人的倍数，按顺序问三个问题，基本能筛掉九成的水分。

第一，分子和分母是同一次测量吗？这里显然不是同一次：五万来自一台服务的工具定义，两百来自一份技能文件的元数据，两者来源不同，口径也不同。

第二，百分比的基数写清楚了没有？官方原文里那个五成，基数是Projects这一组工具，并非全部工具。基数一换，结论就跟着变。

第三，这个数字在你自己的环境里能测吗？这一问最管用。工具定义占多少词元，翻一次会话日志就知道，不需要引用任何人。凡是能在自己机器上十分钟测出来的东西，就别引二手数字，尤其别引带倍数的二手数字。

这套拆法不只适用于协议之争。AI领域每周都在产出“提升X倍”“节省Y成”的句子，自己动手测的人和只会转发的人，判断力的差距会越拉越大。

MCP的上下文成本到底贵在哪一部分？

2025年大半年，MCP被包装成Agent时代的通用接口：一个协议连接所有工具和所有模型。这个说法能被接受，是因为它解决的是2024年的真问题：那时模型不太会用工具，标准化的结构描述确实帮了大忙。

到2026年，问题反过来了。模型已经很会用工具，付不起的是描述工具的方式。这笔成本可以拆成三笔，而且互相叠加。

第一笔：工具定义的词元开销如何按会话预收？

MCP的设计是把工具目录预先灌进模型上下文。动态发现要求模型先知道有什么可用，这是设计本身，谈不上缺陷，但它同时就是一笔税。

麻烦出在收费方式上，绝对值倒在其次：进门先交，交完之后这次会话可能一个相关工具都不会调。按需加载的技能文件则是触发才读，不触发就一个词元都不花。

有一组被反复引用的社区实测：同时挂三台服务器，工具定义在二十万词元的窗口里占掉了十四万三，也就是七成多。这个数字来自个人配置而非官方基准，具体多少取决于你挂了什么，但量级上没人反驳过。GitHub自己也在文档里提供了按工具组开关的参数，理由写得很直白：只启用你需要的工具组，可以帮助模型做工具选择，同时减小上下文体积。厂商在文档里教用户少装，说明这笔开销确实存在。

更麻烦的是，这笔固定开销和实际用量脱钩。一台服务挂上去，它的定义在每一轮对话里都要重新过一遍模型；不管这次会话是在改一段CSS还是在查订单，它都照收不误。用得越少的服务，单位价值越低，而最容易被忘掉的恰恰是那些用得少的服务。

第二笔：工具列表过长为什么会降低模型表现？

上下文成本还有一层比账单更严重的二阶影响。每一千词元的工具描述，都会让模型少一千词元的注意力放在真正的问题上；工具列表越长，选错工具的概率越高。

这一点可以测量。同一个任务，把无关工具组关掉再跑一遍，会看到调用路径变短、绕路变少。注意力是Agent系统里最稀缺的资源，工具目录却把它花在了管道上。

有个容易被忽略的机制：选错工具的代价会延续下去。选错工具会返回一个不对路的结果，这个结果留在上下文里，成为下一轮推理的依据。一次糟糕的工具选择会污染后面所有轮次，没法靠简单重试消掉。所以把工具目录砍窄，往往比调提示词见效更快。

验证方法很简单，不用信任何人：把同一个任务在两种配置下各跑三遍，一种挂满，一种只留必需的那一组，对比总词元数、工具调用次数和最终是否一次做对。三组数据出来，该关哪些就清楚了。

第三笔：为什么模型用CLI比调用MCP工具更顺手？

这一笔说到底不是工程问题，是语言学问题。

大模型的训练语料里有几十亿行shell命令和它们的输出：问答站、代码仓库的问题区、持续集成日志、配置文件、教程。Agent敲一条命令行时，做的是一件见过几百万次的事，连报错长什么样、人类怎么排错都见过。

调一个MCP工具时，它照着三十秒前才第一次出现在上下文里的结构描述干活。前者像用母语交流，后者像趴在工作台上现翻说明书。让模型用命令行，用的是它已经掌握的技能，不需要现学。

命令行还自带一套工具。输出可以用管道预过滤，只让相关的几行进上下文；报错是模型见过无数次的纯文本；调试时把命令原样粘进自己的终端，就能亲眼看到它在哪一步出错。MCP出错时你在翻别人服务的日志，命令行出错时命令本身就是复现步骤。

管道这一点尤其被低估。一次接口调用可能返回几千行结构化数据，全量进上下文既贵又分散注意力；同样的活在命令行里是一次调用接两三个过滤器，回来五行。过滤发生在模型外面，和让模型读完再自己挑，是两种成本结构。

这也解释了一个现象：很多人第一次把某台服务换成命令行时，体感提升远大于省下来的词元数。省词元只是账面收益，模型不再需要在一大坨返回值里翻找、一次就答对，才是体感变化的来源。

Anthropic为什么用代码执行调用MCP，而不弃用协议？

如果协议有根本缺陷，最有资格下结论的是它的作者。而作者给的方案并不是让你卸载。

Anthropic在工程博客里承认了两件事：工具定义会撑爆上下文窗口，中间结果也要一路穿过模型再传给下一步。他们给的做法是把MCP服务当成代码接口而不是直接调用的工具：让Agent写一小段代码去调，用文件系统发现有哪些工具、只加载真正要用的那几个定义，再在执行环境里把大结果过滤完才回传。

官方给的对照案例数据很明确：一条把云端表格数据同步进客户系统的流程，原来要十五万词元，改成代码执行之后是两千，节省98.7%。

怎么理解这个方案，会影响后续决策。它的意思并非“协议不行”，而是协议不该直接贴着模型的上下文窗口用，中间需要垫一层代码。一旦接受要垫一层代码，这一层是用宿主语言写的脚本还是用现成的命令行工具，就只剩工程偏好的差别。命令行路线能站住，原因正在这里：它是这层代码最便宜的现成实现。

独立站运营任务卡在MCP协议层，会遇到哪些故障？

观点谁都能发表，三个具体的卡点更有参考价值。这三件事都是独立站运营里最常见的活，失败方式各不相同，结局却一样。

第一种：MCP服务如何把你和已有资源隔开？

任务是抓自家站点的搜索表现数据。浏览器里天天登着后台，看起来最顺手的方案是让Agent直接开浏览器点进去。

结果服务启动的是一个全新配置的浏览器实例：没有cookie，没有登录态。想着登录一次就好，自动化检测又把登录流程拦了。改成接管真实的浏览器，标签页定位又不稳定，点击落在了错误的页面上。

和这层抽象折腾了四十分钟之后，换成几十行脚本直连已登录浏览器的调试端口，一次跑通。问题不在于那台服务做得差，而在于它在你和一个你本来就拥有的资源之间，加了一道隔离层。

第二种：托管MCP服务停服后流程怎么办？

批量出图这条线原来走的是一个托管聚合服务，由它代理上游的生图接口。某天它停服了。没有变慢，也没有降级，服务直接下线，所有经过它的流程当场全部中断。

修复方案是一百行出头的脚本直连上游接口，先按高分辨率出图，再降采样成网页用的尺寸。速度比原来快，还支持了代理层从没暴露过的参数，依赖只剩环境里的一个密钥。

这段脚本现在的存活时间已经超过了它替代的那层“基础设施”。原因很简单：脚本的依赖清单是运行时加一个接口，托管服务的依赖清单里包含别人家公司的商业模式。

第三种：有官方接口时为什么不该驱动浏览器？

第一种卡点之后退一步想：为什么要驱动浏览器？搜索表现和流量数据都有官方接口，都支持服务账号认证。

最终方案是一个用服务账号认证的无界面脚本，定时运行，数据落成本地文件供Agent直接读取。没有浏览器，没有会过期的登录态，也没有中间层。这条经验可以推广：相当一部分服务包装的东西，往下挖一层本来就有可脚本化的接口。

三次失败指向同一个诊断：中间那一层要么是故障点，要么是会消失的依赖，而它下面那一层，即命令行、脚本、官方接口，始终可用。有个说法把这个性质讲得很准：服务断开时你从自动降级为手动，但流程知识还在。前提是流程知识写在你自己的文件里，没有编码在别人的工具描述里。

唱衰MCP的几种流行说法，原文究竟怎么讲？

2026年一季度这波退潮和普通的社交媒体唱衰不同，关键在于退出的是谁。也正因为这些话被反复转述，误差累积得特别快。逐条对照原文，结论会温和不少，也准确不少。

最典型的是那条被引用最多的原帖：抱怨吃上下文、抱怨要来回开关、抱怨认证，然后花三十分钟写了一个浏览器自动化的命令行包装器，结果团队告诉他别家早就做过一个了。这条帖子实际传达的是“现有集成方式的体验差到值得我自己动手”，并没有说“协议本身是错的”。

那位Sentry创始人的完整立场更值得参考：技能教你怎么做菜，协议提供做菜的器具。一个自己还在跑两台服务的人说“许多服务不需要存在”，重点在“许多”，不在“存在”。

这类话为什么容易被放大？因为“谁在退出”这个框架本身就便于传播。当初押注最重的人出来抱怨，比一百个旁观者点评更有戏剧性，转述者会下意识把语气往极端调：抱怨变成宣判，降低优先级变成弃用，“许多”变成“全部”。

读这类消息有个笨办法很管用：只看当事人自己现在还在用什么，不看他说了什么。说话代表立场，配置才是事实。上面这四条里，凡是能查到当事人现状的，现状都比言论温和得多。

替代MCP默认地位的，为什么是Skill层而非CLI？

多数对比文章漏掉了一点：单靠命令行并没有改变格局，改变格局的是命令行加一层知识文件。

技能文件写的是流程知识：跑哪些命令、按什么顺序、边界情况怎么处理、什么时候该停下来问人。它是写给模型看的作业指导书。技能文件该怎么组织、frontmatter有哪些字段可用是另一个话题，这里只谈它在架构里的位置。

位置很清楚：Skill接管了协议的编排价值，命令行接管了它的执行价值，两头分担之后，常规场景下协议就没剩多少事了。

MCP工具描述和Skill作业指导书，差别为什么在体裁？

同样是给模型看的文字，为什么一个要几万词元还讲不清，另一个几百词元就够？因为两者承载的内容根本不是同一类。

工具描述回答的是“这个函数接受什么参数、返回什么结构”。它适合表达接口，不适合表达顺序、条件和禁忌。一个参数说明里写不清“先查库存再改价格，改完必须回读确认，如果库存为零就停下来问人”。

作业指导书回答的是“遇到这类活该怎么办”。顺序、判断、边界、什么时候该停，都是它擅长表达的内容。2025年那批几万词元的工具定义，实际上是压缩得很差的作业指导书：体裁选错了，字数再多也说不明白。

换了体裁之后还有三个附带好处：改行为只需改一份文本、再提交一次版本管理，反馈周期以分钟计；团队里不写代码的人也能读、能审、能提意见；出问题时看到的是一份人话流程，而非一堆参数签名。

飞书CLI加Skill的形态说明了国内什么动向？

飞书在2026年3月底开源了官方命令行工具，形态是命令行，并没有再发一台MCP服务。它用Go写成，MIT许可，覆盖日历、消息、文档、表格、多维表格、任务、邮件、会议等18个业务域，两百多条精选命令，底层对接两千五百多个开放接口。

更能说明问题的是配套形态：它内置了26个可直接安装的Agent技能，一条命令就能装进主流编程Agent。一家头部协作平台选择用命令行加技能的形态对接Agent生态、而没有发布一台服务器，说明这已经从社区偏好变成了厂商用研发预算做出的选择。

顺便校准一个数字：早期报道普遍写的是11个业务域、19个技能，那是它刚开源时的规模；到2026年年中已经扩到18个域、26个技能，星标一万六千以上。引用开源项目的规格时，别把发布当天的快照当常量用。

Skill技能文件有哪些执行代价？

文字形式的作业指导书毕竟不是代码，做不到百分之百确定性执行。模型会漏读一步、跳过一条护栏、在你要求照章办事的地方自作主张。

可行的规则是：凡是必须精确的步骤，写成脚本让技能去调用；技能文件的文字只负责需要判断的部分。判断归技能，精确归脚本。如果一个流程零容忍偏差、又完全不需要判断，它就不该做成技能，应该做成定时任务。

微软的技能执行器如何组合Skill与MCP？

这套架构最终会是什么样，目前最可信的参考来自微软，而且它给出的答案比“Skill在上、MCP在下”这个流行说法更精细。

他们的技能执行器由四个部件拼成：技能加载器从目录里发现并解析技能文件，把前置元数据和正文分开；模型服务负责对话与函数调用；协议客户端连接一台或多台MCP服务，发现它们的工具并路由执行请求；执行器本身负责运行Agent主循环。

技能文件在这里被解析成一个对象，带名称、描述、标签，正文整段作为指令。前置元数据里有两个字段值得借鉴：一个声明这条技能在什么文件模式下被激活，一个声明它预期用到哪些工具。

MCP服务对外公布Skill，改变了什么？

如果只到“Skill在上、MCP在下”，那还只是分层。微软后来又让MCP服务反过来对外公布技能：技能不再只能放在本地磁盘，也可以放在一台MCP服务上，服务通过一份索引文档对外公布自己有哪些技能，框架再经由认证过的连接把技能正文取回来。

这一步改变了原来的叙事方向。协议从“工具的传输层”扩展成了“知识的分发通道”：它既是Skill下面的传输管道，也可以是存放Skill的地方。那些断言协议会被技能取代的文章，没有预料到两者能这样组合。

对做独立站和外贸的团队，这一层的现实影响是：未来要接入的第三方能力，很可能不再以“装一台服务、灌几十个工具定义”的形式交付，而以“订阅一份技能索引”的形式交付。选型时该问的，不是对方有没有MCP服务，而是对方的能力以什么粒度、在什么时机进入你的上下文。

为什么把能力传输与能力说明分开后这个设计才成立？

因为它把原本混在一起的两件事分开了：能力的传输，和能力的说明书。

过去这两件事绑在一起：连上一台服务，它就把工具描述一次性塞过来，说明书是传输的一部分，想用前者必须先接下后者。分开之后，服务只在真正执行的那一刻被调用，说明书按需取回，什么时候进上下文由你这边决定。

这一步对企业采购的意义比对个人开发者更大。供应商可以继续维护自己的服务和授权体系，客户的上下文开销则从“每次会话固定支出”变成“按需支出”，双方诉求第一次不再冲突。之前那种非此即彼的争论，很大程度上是因为没人把这两件事拆开讨论。

另外提醒一点：看到某个平台同时提供服务与技能两种接法时，别默认技能一定更省。要看它的技能文件是否真的按需加载、正文有多长、有没有把一整本手册塞进一个文件。体裁对了，不代表分量也合适。

哪些场景下MCP仍然比CLI加Skill更合适？

宣告某项技术已死的文章，大多从不列出对方的有利事实。这里把MCP的适用场景列出来，理由是结构性的，与怀旧无关。

• 没有shell，命令行方案就不成立。网页版助手、移动端Agent、锁死的企业沙箱，很多根本接触不到命令行。对它们来说，“直接跑一条命令就行”没有意义，而基于HTTP的协议传输恰好能进入这些环境。这个范畴并不小众，大部分面向消费者的AI产品都在其中。
• 工具池确实高频变化时，动态发现有真实价值。在开放生态里，用户会在运行时给Agent接入自己的第三方服务，这时带结构描述的协议就是比一个文件夹的文档强。2025年的错误在于把动态发现当成了静态工具集的默认方案，造出这个协议本身没有错。
• 托管授权和审计边界。脚本连上你已登录的浏览器时，继承的是你的完整会话，方便，但也正是安全团队最担心的全量授权。远程服务配托管授权，给企业的是细粒度令牌，可撤销，每次调用都留痕。

命令行路线的另一面也要说清楚：给Agent一个shell，等于给它执行任意命令的能力。威胁模型里一旦包含提示词注入，受限的协议面反而成了优点。这组矛盾怎么处理，和选服务时怎么辨认真实包名与授权范围属于同一类工程判断。

还有一条跨平台的现实问题：技能文件里的命令通常默认了某一种操作系统，搬到另一套环境要返工，而协议描述不依赖操作系统。团队里有人用Mac、有人用Windows时，这个问题比预想的更麻烦。

这些场景有一个共同点：全都是环境约束，包括没有shell、工具不稳定、凭证不能落地、跨系统。其中没有一条是“在命令行存在且可用的前提下，协议集成得更好”。所以准确的说法是MCP被降级了，并没有死。

为什么多数团队最后采用混合式分层架构？

把上面两组理由放在一起，得到的是分层方案，而非二选一：作业指导书在上层，命令行和脚本是默认执行层，协议是前两层覆盖不到时的兜底传输。

这种结构有个实际好处：替换成本被限制在单层内。上游服务停服，换一条执行路径即可，作业指导书基本不动；模型换代，换模型即可，作业指导书同样不动。知识和传输解耦之后，传输就变成了大宗商品，而大宗商品按成本竞争。

从MCP迁移到CLI加Skill，有哪些可执行的判据？

下面是可以直接照做的检查清单。逐条核对你正在运行的每一台服务：

1. 官方命令行或可脚本化接口已经存在。如果存在，这台服务只是在你的Agent和它本可直接访问的对象之间做翻译。
2. 你的Agent能访问shell。能访问的话，命令行方案完全适用。
3. 流程是可重复的。反复调用的就是那三五个工具、顺序也相似，却在为静态的例行操作支付动态发现的成本。
4. 词元开销远超使用率。服务加载了成千上万词元的定义，实际只用到其中五分之一的工具。翻一下会话日志，这一条可以测量。
5. 服务需要人工维护。认证反复重配、常驻进程要管理、动不动就得关掉重开试试。

命中三条以上，就写一份技能文件指向命令行，断开服务，然后对比迁移前后每个任务的词元数。技能文件通常只需要四段：用哪个工具、带真实输出的标准命令示例、失败模式和兜底、模型不许越过的硬边界。

Skill技能文件的四段各写什么、写多长？

这四段写成什么样，决定了这份文件是资产还是负担。下面是一份可以照着填的骨架。

第一段：用哪个工具、怎么确认它已安装。写清工具名、版本要求，以及一条自检命令。这一段让模型在开工前就确认环境是否正确，避免到第三步才因为找不到命令而乱猜。

第二段：带真实输出的标准命令示例。这是四段里最有价值的一段。不要只写命令，要把命令跑出来的真实输出粘一小段进去。模型见过输出的样子，解析和判断的准确率会明显不同；只给命令不给输出，模型只能凭猜测解析结果。

第三段：失败模式和兜底。列出已经踩过的坑：认证过期是什么表现、限流报什么错、哪个参数在某些情况下会静默失效。每条配一句处理办法。这一段会随时间越写越长，也是这份文件里唯一会持续增值的部分。

第四段：硬边界。明确写出模型不许做的事：不许改这几个目录、未经确认不许执行删除、不许把密钥打进日志。这一段只是提示，没有强制力，真正不能出错的边界还要靠权限配置保证，文字只负责让模型不去尝试。

总长度控制在一百行以内是个合理的目标。超过这个数，通常说明一份文件里塞了三件事，该拆分了。

各类MCP集成的迁移先后顺序怎么排？

一次性全部迁移最容易出问题。按下面这张表挑选，先动收益大、风险小的几台。

还有一类不该动：一个月只用一两次、而且每次用法都不同的服务。它的词元开销本来就摊得很薄，为它写一份技能文件，维护成本反而更高。迁移收益与使用频次成正比，与用法的固定程度成正比，也与你能否自己修复它成正比。

迁移前后的每任务词元数应该怎么测量？

迁移前后各测一遍，听起来简单，实际上很容易测出一个误导自己的数字。常见陷阱有三个。

第一，只测一次。同一个任务跑三遍，词元数波动两三成很常见，单次对比没有意义。至少各跑三遍取中位数，任务本身也要固定，不要一次查订单、一次改标题。

第二，只看总量不看构成。总量下降，可能只是这次少绕了一次弯，和改动无关。要分开看两部分：固定开销，即任务开始前上下文里已有多少词元；变动开销，即执行过程中新增了多少。迁移主要削减的是前者，如果前者没变，说明服务没有断开干净。

第三，漏算技能文件本身。技能文件被触发后也要进入上下文，并非零成本。正确的对比是“协议的固定开销”对“技能文件的触发开销加脚本调用的输出量”，不能拿几万词元去比一份文件的元数据。把这一项算进去，倍数会缩小，但结论通常仍然成立：从两百倍变成十几倍，而十几倍已经足以改变决策。

除了词元数，迁移后还应该测量哪些指标？

词元下降是最容易写出来的数字，但未必最重要。保哥自己迁移时，真正改变判断的是故障恢复时间：脚本坏了，把命令粘进终端就能看到报错；服务那条路坏了，只能去翻别人家的日志。可调试性的收益会持续累积，却从来不体现在账单上。

还有一个反直觉的观察：把工具目录砍窄之后，模型表现的提升往往比省下来的钱更有价值。算token账时这一点容易被漏掉：省下的两万词元是一次性的加法，选对工具带来的路径缩短则是每一轮都生效的乘法。同样的账在浏览器这个具体场景里也成立，四种让模型看页面的方式各自要花多少词元那篇里量过一遍，量级差异同样在两个数量级上。

MCP与CLI加Skill的选型结论能否写成一句话？

把立场写成一句可以被证伪的话：到2026年底，“怎么把Agent接到某个系统”的默认答案会变成“它有命令行吗”，只有这个问题的答案是“没有”时，协议才出场。

今天新起一个Agent项目，从技能加命令行开始；遇到前面那三种环境约束时，再加服务，不要提前加。三种扩展机制之间的边界怎么划，MCP、Skills与Hooks各管哪一段那篇写得更细，可以配套阅读。

常见问题解答

MCP是不是已经死了，还值得学吗？

值得学，但重点要换。MCP没有死，它从默认集成方式降级成了几种可选传输之一。真正过时的是“遇到集成需求先找现成服务”这个习惯。现在应该先问有没有命令行或可脚本化接口，没有再考虑协议。协议里的概念，包括工具发现、结构化描述、托管授权，在没有shell的环境里依然是唯一解。

那个流传很广的250倍差距到底靠不靠谱？

不靠谱，至少推导过程站不住。它把GitHub官方“合并Projects工具组省下约两万三千词元、降幅五成”读成了“整台服务从五万降到两万三”，再拿这个五万去除以技能文件的两百词元。官方从没公布过全量工具定义的总词元数。方向没错，按需加载确实比预先灌入省得多，但具体倍数请以你自己会话日志里的实测为准。

技能文件不能保证百分之百执行，那关键流程怎么办？

需要判断的部分交给技能文件，不能出错的部分写成脚本让技能调用。判断归技能，精确归脚本。如果一个流程既零容忍偏差又不需要任何判断，就不该交给Agent，应该做成定时任务。这样分工，也能防止技能文件越写越长。

给Agent开shell安全吗，会不会被提示词注入利用？

风险确实存在，开放shell等于开放任意命令执行能力。可行的控制分三层：用允许名单和拒绝名单限定可执行的命令和可读写的路径，把密钥放进环境变量而不让它读取凭证文件，在工具调用前挂一道钩子做硬拦截。这也说明了受限协议面在高危环境里的价值：不是所有场景都该用同一套接法。

已经装了七八台服务，要不要一次全迁走？

不要。按迁移判据逐台评估，命中三条以上的先迁，一次只迁一台，每台迁完记录每任务词元数和一次故障恢复的耗时。一次性全量替换，会同时失去多个可回退的参照，出了问题分不清是哪一处改动引起的。

公司里有人坚持“协议是标准，不能不用”，怎么沟通？

把讨论从立场转到成本上。请对方一起看两个可测量的数据：一是每个会话里工具定义占了多少词元、其中多少工具实际被调用过；二是这条集成最近三次出故障时，定位问题花了多长时间。这两个数字摆出来后，讨论通常会从“要不要遵循标准”转向“这条集成值不值这个成本”。

权威参考资料