MCP还有必要装吗？CLI加Skill已经接管了Agent工具链的主干

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

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

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

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

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

一个被引错的数字，是怎么滚成共识的？

值得花一节讲这个，因为同样的滚雪球每个月都在发生，而且下一个雪球你多半也拦不住——除非手上有一套拆的办法。

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

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

三个问题就能把这类数字拆开

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

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

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

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

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

MCP到底贵在哪，贵的是哪一部分？

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

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

第一笔：词元房租，每个会话预收一次

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

扎心的不是绝对值，是收费方式：进门先交，交完这次会话可能一条相关工具都不会调。一份按需加载的技能文件则是触发才读，不触发就一个词元都不花。

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

更要命的是这笔房租的计价方式跟你的实际用量脱钩。一台服务挂上去，它的定义在每一轮对话里都要重新过一遍模型；你这次会话是在改一段CSS还是在查订单，它一视同仁地收。用得越少的服务，单位价值越差，而人最容易忘掉的恰恰是那些用得少的服务。

第二笔：模型实打实变笨

上下文成本有一层比账单更疼的二阶伤害。每一千词元的工具描述，就是模型少一千词元的注意力放在你真正的问题上；工具列表越长，选错工具的概率越高。

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

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

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

第三笔：逼模型说外语

这一笔最有意思，因为它不是工程问题，是语言学问题。

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

调一个MCP工具时，它在照着三十秒前才第一次出现在自己上下文里的结构描述干活。一边是母语，一边是趴在工作台上现翻说明书。让模型用命令行，不是在教它新技能，是在给它已有的技能让路。

母语还自带一套工具箱。输出可以用管道预过滤，只有相关的那几行进上下文；报错是它见过一百万次的纯文本；调试就是把命令原样粘进自己的终端，亲眼看它怎么挂。MCP出错时你在翻别人服务的日志，命令行出错时命令本身就是复现步骤。

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

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

为什么Anthropic自己给的解法不是弃用协议？

如果说协议有原罪，最有资格宣判的应该是它的作者。而作者给的方案，恰恰不是让你卸载。

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

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

这个方案该怎么读，决定了你会不会做错决策。它不是“协议不行”，而是协议不该直接贴着模型的上下文窗口用，中间需要垫一层代码。而一旦你接受要垫一层代码，那么这一层是用宿主语言写的脚本，还是用现成的命令行工具，就只剩下工程口味的差别了。这也是命令行路线能站住的真正原因——它就是那层代码最便宜的现成实现。

站内运营的活儿卡在协议层，是什么手感？

大人物的观点不值钱，讲三个具体的卡点更实在。这三件事全是独立站运营里最平常的活，失败模式各不相同，但结局一样。

第一种：它把你和你本来就有的东西隔开了

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

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

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

第二种：它是别人家的商业模式

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

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

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

第三种：往下挖一层，浏览器根本不该出场

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

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

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

离场的那批人，究竟说了什么？

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

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

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

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

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

真正替代MCP的不是命令行，是Skill这一层

多数对比文章漏掉一个关键：光有命令行并没有掀翻什么。掀翻它的是命令行加一层知识文件。

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

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

工具描述和作业指导书，差的不是格式是体裁

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

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

作业指导书回答的是“遇到这类活该怎么办”。顺序、判断、边界、什么时候该停，全都是它的母语。2025年那批几万词元的工具定义，本质上是被压缩得很烂的作业指导书——用错了体裁，再多字数也说不明白。

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

国内的动向和硅谷同频，而且跑得更实

飞书在2026年3月底开源了官方命令行工具——注意，是命令行，不是又一台MCP服务。它用Go写成，MIT许可，覆盖日历、消息、文档、表格、多维表格、任务、邮件、会议等18个业务域，两百多条精选命令，把两千五百多个开放接口收在下面。

更说明问题的是配套形态：它内置了26个可直接安装的Agent技能，一条命令装进主流编程Agent。当一家头部协作平台选择用命令行加技能的形态对接Agent生态，而不是发一台服务器，这就不再是社区偏好，是厂商拿研发预算投的票。

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

技能文件的代价也要摆出来

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

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

微软把这套东西落成了什么形状？

终局长什么样，目前最可信的预览来自微软，而且它给出的答案比“Skill在上、MCP在下”这个流行说法更精细。

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

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

真正的反转在这里

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

这一步把叙事整个掰了个方向。协议从“工具的传输层”变成了“知识的分发通道”——它不再只是Skill脚下的水管，也可以是Skill的货架。那些断言协议会被技能取代的文章，恰恰没料到两者能这么长。

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

为什么这个反转能成立，而不是又一次概念套壳

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

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

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

顺带说一句选型上的提醒：看到某个平台同时提供服务与技能两种接法时，别默认技能一定更省。要看它的技能文件是不是真的按需加载、正文有多长、有没有把一整本手册塞进一个文件里。体裁对了不等于分量对了。

什么情况下MCP仍然是更优解？

宣告某个技术已死的文章大多败在从不给对方摆事实。这里反过来说，而且理由是结构性的，不是怀旧。

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

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

还有一条跨平台的现实：技能文件里的命令通常默默假设了某一种操作系统，搬到另一套环境上要返工，而协议描述不挑系统。团队里有人用Mac有人用Windows的时候，这条比想象中更烦人。

注意这些赢面的共性：全都是环境约束——没shell、工具不稳定、凭证不能落地、跨系统。没有一条是“在命令行存在且能用的前提下，协议集成得更好”。这就是降级而非死亡的准确含义。

混合式才是大多数团队最后落到的形状

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

这个形状有个很实际的好处——它让替换成本降到了单层。上游服务停服，你换一条执行路径，作业指导书基本不动；模型换代，你换模型，作业指导书还是不动。把知识和传输解耦之后，传输就变成了大宗商品，而大宗商品是按成本竞争的。

这周就能跑一遍的迁移判据

理论说完，给可以直接抄的作业。逐条核对你在跑的每一台服务：

1. 官方命令行或可脚本化接口已经存在。存在，就说明这台服务只是在你的Agent和它本可直达的东西之间做翻译。
2. 你的Agent摸得到shell。摸得到，命令行论全额适用。
3. 流程是可重复的。你翻来覆去调的就是那三五个工具、相似的顺序，却在为静态例行公事支付动态发现的价格。
4. 词元开销远超使用率。服务加载了成千上万词元的定义，你只用其中五分之一的工具。翻一下会话日志，这条可测量。
5. 服务需要人伺候。认证反复重配、常驻进程要管、动不动关了再开试试。

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

四段各该写什么，写多长

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

第一段：用哪个工具、怎么确认它装好了。写清楚工具名、版本要求，以及一条用来自检的命令。这一段的作用是让模型在开工前就知道环境对不对，而不是在第三步才因为找不到命令而乱猜。

第二段：带真实输出的标准命令示例。这是四段里最值钱的一段。别只写命令，要把它跑出来的真实输出粘一小段进去。模型见过输出长什么样，解析和判断的准确率会明显不一样；只给命令不给输出，等于让人闭着眼睛接球。

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

第四段：硬边界。明确写出模型不许做的事——不许改这几个目录、不许在没确认前执行删除、不许把密钥打进日志。注意这一段是提示而不是强制，真正不能出错的边界还得靠权限配置兜底，文字只负责让它不去试。

总长度控制在一百行以内是个不错的目标。超过这个数，通常意味着你把三件事塞进了一份文件，该拆了。

按迁移收益排个先后

一次全迁是最容易翻车的做法。按下面这张表挑，先动收益大风险小的那几台。

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

每任务词元到底怎么量才算数

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

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

第二，只测总量不看构成。总量降了，可能只是这次它少绕了一次弯，跟你的改动无关。要分开看两块：固定开销，也就是任务开始前上下文里已经躺着多少；变动开销，也就是执行过程中新增了多少。迁移主要削的是前者，如果前者没动，说明服务其实没断干净。

第三，忘了算技能文件本身。技能文件被触发之后也要进上下文，它不是免费的。真正的对比是“协议的固定开销”对“技能文件的触发开销加脚本调用的输出量”，而不是拿几万词元去比一份文件的元数据。把这一项算进去，倍数会缩水，但结论通常还是成立——只是从两百倍变成十几倍，而十几倍已经足够改变决策了。

别省掉测量这一步，也别只测词元

词元下降是最好写的那个数字，但它未必是最重要的。保哥自己迁移时真正改变判断的，是故障恢复时间：脚本坏了，把命令一粘就看到报错；服务那条路坏的时候，人在翻别人家的日志。可调试性才是复利，而它从来不体现在账单上。

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

如果只能记一句

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

今天新起一个Agent项目，从技能加命令行开始；撞上前面那三种环境约束的那天，再加服务，别提前。至于三种扩展机制彼此的边界怎么划，MCP、Skills与Hooks各管哪一段那篇写得更细，可以当配套读。

常见问题解答

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

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

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

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

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

把需要判断的部分留给技能文件，把不能出错的部分写成脚本让它调用。判断归技能，精确归脚本。如果一个流程既零容忍偏差又不需要任何判断，那它根本不该交给Agent，该做成定时任务。这个分工也是技能文件不至于越写越长的关键。

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

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

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

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

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

把话题从立场换成成本。请对方一起看两个可测量的东西：一是每个会话里工具定义占了多少词元、其中多少工具实际被调用过；二是最近三次这条集成出故障时，定位问题花了多久。这两个数字摆出来之后，讨论通常会自动从要不要标准，变成这条集成到底值不值那个价。

权威参考资料