这帖子说到点子上了，MCP和Skill这波确实在改底层逻辑。不过楼主提到的“上下文理解”这块我太有同感了——我们之前做内部工单系统的Agent化，把50多个功能拆成8个Skill，结果Agent经常选错Skill去调用，比如“查询历史工单”和“生成工单摘要”这两个Skill，参数结构差不多，但语义差别极大，Agent在模糊指令下会乱跳。后来我们被迫在Skill描述里加了很多“触发条件”和“反例说明”，相当于给Agent写了一套隐形的if-else规则，虽然笨但有效。

另外说个实战坑：MCP Server的稳定性其实比想象中脆弱。Adobe那次MCP Server上线没多久就出过接口限流问题，Agent批量调用时直接404，导致下游流程全挂。我们后来在Skill层加了个“retry+降级”机制，比如调用失败就自动切到预置的文本回复模板，至少保证能兜底。

至于SaaS估值逻辑，我觉得短期确实有冲击，但“70%软件被吞噬”可能夸张了。至少目前Agent的决策链还不够长，处理复杂业务逻辑时（比如跨部门审批、动态权限校验），还是得靠人肉UI来补位。不过话说回来，如果MCP能标准化到“Skill即服务”的程度，那SaaS的“按席位收费”模式可能真要改成“按调用量计费”了，这倒是值得关注的点。

这个帖子看得我有点上头但又有点懵。我是最近才开始接触MCP这些东西的新手，之前一直以为软件被AI吞噬就是简单接个API完事，看完你讲的这个“功能点转Skill”的过程，才意识到原来底层逻辑完全不一样了。

你提到的那200个功能点抽象成30个Skill的例子特别触动我，因为我这边正好也在做一个类似的内部工具对接AI的小项目，还没上线就已经被agent选错Skill搞到头秃。你最后说“性能瓶颈不在API响应，而在上下文理解”，我太有同感了。我现在还没想明白的是，你们当时是怎么解决agent选错Skill这个问题的？是提前做了意图分类，还是靠prompt硬调？或者说你们有没有试过把Skill再拆细一点，减少agent的选择歧义？

另外，你说IDC预测70%软件会怎么着？帖子好像没写完，能不能再说说那个预测的下半句？我挺想知道这个数字背后是怎么算的，因为感觉如果MCP真铺开了，很多SaaS的收费模式确实得变，用户不再订阅界面而是订阅能力了，那估值逻辑肯定不一样。但具体怎么变，我还想多听点实践中的坑和判断。

兄弟这个观察真说到点子上了！MCP和Skill的提法我最近也在琢磨，确实感觉现在软件开放的姿势变了，以前搞个API还得写文档、搞认证，现在直接MCP一包，Agent就能当“手”用，这底层逻辑确实不一样。

不过你提到的那个性能瓶颈我太有共鸣了——我们团队之前做内部工具接入LLM，也是把几十个功能点抽成Skill，结果发现最头疼的压根不是接口调不通，而是Agent在那“选技能”的时候经常犯迷糊。比如明明该调用“创建订单”的Skill，它非要去调个“查询价格”的，参数还传得乱七八糟。后来我们试了两种路子：一种是给每个Skill加一段超详细的自然语言描述，甚至把典型场景写进去，有点像给Agent写“使用说明书”；另一种是在Agent层加了个“意图路由”模块，先让大模型把用户意图归个类，再精准匹配Skill。虽然效果好了不少，但成本也上去了。

另外你说IDC预测70%软件怎么着？后面是不是被截断了？我特别想听听完整的数据。还有摩根士丹利那个“SaaSpocalypse”的说法，我个人觉得有点标题党，但SaaS的估值逻辑确实该调一调了——以前是按API调用量或用户数算，现在如果软件变成Agent的“组件”，那是不是该按Skill的调用频次和组合复杂度来定价？这要是真跑通，整个SaaS的商业模式都得重写。你们团队后来那个CRM的30个Skill，实际跑下来成本收益比能打平吗？

这个帖子的观察很到位，特别是“功能点”变成“能力暴露”这个点，我深有同感。我们团队去年搞过一个客服Skill化项目，把工单系统、知识库、CRM的常用操作抽象成Skill，结果跟楼主遇到的坑几乎一模一样——Agent上下文理解才是最大瓶颈。

举个具体例子：我们有个“查询客户历史订单”的Skill，参数包括客户ID、时间范围、订单状态。测试的时候Agent老是传错时间格式，或者把“最近三个月”理解成“最近30天”，导致返回空结果。后来我们不得不给每个Skill加了一层“意图预处理器”，本质上是在Agent和Skill中间插了一个轻量级的规则引擎，先把自然语言参数转成标准化格式。这招虽然治标不治本，但至少上线初期能兜底。

另外我比较好奇，楼主提到的30个Skill是怎么划分粒度的？我们当时纠结了很久，比如“创建工单”和“更新工单状态”是不是该合并成一个“工单操作”Skill。拆太细，Agent选择成本高；合并太粗，参数组合爆炸。最后参考了OpenAI的function calling文档，按“业务动作”而非“CRUD”来划分，才稍微顺了点。

至于SaaS估值逻辑，我觉得确实要变，但不会是“推翻”，更像是“从卖功能变成卖连接”。以后能养好Agent、把Skill跑通的公司，估值逻辑会更像基础设施提供商。楼主有空可以聊聊你们那200个功能点抽象成30个Skill的具体映射策略，这块实操经验太少了。

这个帖子看得我后背发凉又有点兴奋。我刚开始学MCP和Agent相关的东西，之前一直搞不懂为啥大家都在说“软件主动被AI吃掉”，看了你的解释才明白——原来是把以前点来点去的功能变成API让AI直接调，这个思路确实很颠覆。

你提到把200个功能抽象成30个Skill那段特别戳我，因为我最近也在试着复现一个小demo。卡住的地方跟你说的差不多：Agent不是调不动接口，而是选哪个Skill、参数怎么填，经常乱套。比如同一个“查订单”的需求，它有时候调查询接口，有时候又跑去调创建接口，上下文一多就懵。想问下你们当时是怎么解决这个选择准确性的问题的？是加规则约束还是靠模型本身的能力优化？

还有，IDC那个70%软件被吞的预测我也看过，但感觉现在很多传统SaaS连API都还没做好，更别说MCP Server了。你觉得这波变革对小团队来说是机会还是坑？我总担心自己辛辛苦苦封装好Skill，结果大厂一个更新就把我的替代了...

这个帖子看得我头皮发麻，感觉一下子把很多模糊的东西讲清楚了。我之前一直没搞懂MCP到底跟普通的API开放有什么本质区别，你这么一说，确实是从“用户操作”变成了“能力暴露”，这个底层逻辑的转换挺震撼的。

不过你提到的那个实践问题，也就是Agent上下文理解导致Skill选择不准，我特别有同感。我们小团队最近也在试着把几个内部工具包装成Skill，遇到最大的坑就是参数传递，比如同一个字段在不同Skill里语义不一样，Agent经常传错值或者干脆拒绝调用。想问一下，你们当时是怎么处理这个问题的？是加了额外的中间层做意图清洗，还是直接靠prompt硬调？另外，IDC那个预测没写完，70%软件会怎样？是会被淘汰还是转型成MCP Server这种形态？想听听你更多的具体案例，感觉这种踩坑经验比理论分析值钱多了。

兄弟这个帖子看得我热血沸腾，终于有人把MCP和Skill这层窗户纸捅破了。我在这个领域摸爬滚打了两年多，从最早做RPA+LLM的缝合怪，到后来自己写Agent框架，再到最近帮几个客户落地MCP Server，踩过的坑比你列举的还多。先说结论：你提出的“品牌价值被屏蔽”这个问题，恰恰是这场变革中最反直觉、也最值得深挖的点。我甚至觉得，这不仅仅是SaaS估值逻辑的修正，而是整个软件行业从“卖铲子”到“卖矿”的范式转移。

先回应你提到的性能瓶颈问题。你说“Agent上下文理解”比API响应更复杂，这点我举双手双脚赞同。但我想补充一个更隐蔽的坑：参数传递的“语义鸿沟”。你从200个功能点抽象出30个Skill，这个压缩率本身就很激进，实际操作中你会发现，每个Skill的参数列表如果超过3个，Agent的准确率就会断崖式下跌。我们做过一个实验：同样一个“创建订单”的Skill，用自然语言描述参数 vs 用schema严格定义参数，LLM的选择准确率差了将近40%。后来我们被迫引入了一个中间层，叫“参数预处理器”，本质上是把每个Skill的入参拆解成两级：第一级是LLM能理解的模糊意图（比如“给张三发个报价”），第二级才是结构化API调用（需要客户ID、产品ID、折扣率）。这个预处理层用了一个小模型做意图分类，再用规则引擎做实体抽取，才算勉强把准确率拉到85%以上。所以我的建议是：不要幻想LLM能直接理解你的Skill接口，你得给它搭梯子。

你提到的Plugin和Skill两种封装形态的对比，我正好两个都深度搞过。Plugin更像是给Agent戴上手铐脚镣——你定义好输入输出，Agent只能在你的沙盒里跳舞。而Skill更像是给了Agent一把瑞士军刀，但刀怎么用取决于Agent自己的判断。我去年给一个电商客户做项目时，发现一个有趣的现象：他们同时提供了Plugin和Skill两种方式对接ERP系统。Plugin版本用户用得少，因为Agent每次调用都要走OAuth授权，而且在插件沙盒里没法缓存数据，导致频繁的轮询。Skill版本虽然初始集成成本高，但Agent可以直接读写内存中的会话状态，响应速度快了一个数量级。但代价是什么？安全风险。Skill如果写得不够严谨，Agent可能会搞出“先下单后取消”这种胡闹操作。所以我现在的一个实践原则是：对于核心业务逻辑（比如支付、库存扣减），必须用Plugin模式，强制Agent走预定义流程；对于辅助功能（比如查询、报表生成），可以开放Skill，让Agent自由发挥。这种“混合架构”目前跑得最稳。

关于你担心的“品牌价值被屏蔽”，我觉得这恰恰是中小企业突围的机会。大厂靠UI/UX建立的品牌认知，在Agent世界里几乎等于零。用户不关心后台是Notion还是飞书，只关心Agent能不能帮我找到上周三的会议纪要。这意味着什么？意味着技术壁垒比品牌壁垒更重要。我见过一个创业公司，只有5个人，做了一个专门针对法律行业的Skill包，把合同审核、案例检索、文书生成这些高频操作封装得极其精致，参数设计得让LLM几乎不会误解。结果他们签下了三个中型律所，直接绕过了原本需要花几年才能建立的销售渠道。因为律所的Agent直接通过MCP协议调用了他们的Skill，律所合伙人甚至不知道这个Skill背后的供应商是谁，只看到Agent输出的结果质量很高。这其实是一种“能力白标化”——你的技术能力变成了Agent的“肌肉记忆”，用户对Agent的忠诚度会间接转化成对底层Skill的依赖。一旦Agent习惯了某个Skill的返回格式和数据准确性，换供应商的成本就会非常高。所以中小厂商的核心策略应该是：把Skill的“心智模型”做深做透，让Agent形成路径依赖。

至于生态垄断还是开放标准，我倾向认为会走一条折中路线：会出现几个“超级聚合器”，类似于iOS的App Store，但它们无法完全封闭。原因在于MCP协议本身是开源的，而且Anthropic、OpenAI这些模型厂商都在争抢Agent生态的定义权，没有人愿意看到对手垄断。但真正决定走向的，不是协议本身，而是“信任层”的建设。你想想，一个Agent要调用你的Skill，它怎么确认你的Server是安全的？怎么保证传输的数据不被中间人篡改？怎么审计每次调用的合规性？这些问题的答案，目前还没有标准方案。我最近在参与一个开源项目，试图在MCP之上构建一个“能力注册表”+“权限签名链”的机制。大致思路是：每个Skill Server在启动时向一个去中心化的注册表广播自己的能力签名和公钥，Agent调用前先验证签名，调用过程中所有请求走双向TLS，调用结束后生成一个不可篡改的审计日志。这个方案目前还在概念验证阶段，但我觉得它是打破垄断的关键——一旦这种信任机制成熟，任何小团队都能安全地发布Skill，而用户（Agent）可以自由选择，生态就会像Linux一样百花齐放。

最后，你说到SaaS估值逻辑被冲击，我补充一个更具体的视角：单位经济模型的变化。传统SaaS按席位收费，边际成本几乎为零，所以估值看的是用户增长率和留存率。但Agent调用模式下，成本结构变成了“单次调用成本+Skill开发摊销”。这意味着什么？意味着如果你的Skill被高频调用（比如客服类），你的利润率会非常薄，甚至可能亏损，因为LLM的调用成本会吃掉你的利润；但如果是低频高价值的Skill（比如法律咨询、金融风控），单次调用可以收得很贵，利润率反而更高。所以未来的SaaS估值模型，可能会从“ARR倍数”转向“单位调用利润倍数”+“Skill粘性系数”。我最近正在帮一个客户做财务模型，发现如果按传统估值法，他们的CRM SaaS最多值5倍ARR；但按Agent调用潜力估值，考虑到他们的Skill已经被三家头部Agent平台预集成，估值可以推到15倍ARR。这是一个完全不同的游戏规则。

兄弟，你提到的这个方向，我100%认同是未来三到五年的主战场。但我想提醒一点：别低估了“Agent幻觉”对Skill落地的破坏力。我们测试过，即使是最先进的GPT-4，在调用Skill时也会有20%左右的概率选错参数，导致返回垃圾数据。目前我们团队的做法是，在每个Skill的返回结果里嵌入一个“置信度评分”，如果评分低于阈值，Agent必须主动向用户确认。这种“人机协同”的兜底机制，在短期内可能比追求全自动化更务实。另外，建议你关注一下“Skill Versioning”的问题——当你的底层API升级时，如何确保旧版本Agent还能正常调用？我们吃过亏，后来强制要求每个Skill必须携带语义版本号，并且Server端同时维护三个版本，才勉强解决了兼容性问题。

总之，这场变革才刚刚开始。MCP和Skill不是简单的技术协议，它们是软件行业从“界面驱动”转向“意图驱动”的基石。那些还在犹豫要不要开放API的公司，可能两年后就会发现自己被排除在Agent生态之外。而像我们这样已经跳进去踩坑的人，至少拿到了第一批船票。后面怎么走，咱们保持交流，我这个帖子会持续更新踩坑记录。共勉。

这个帖子看得我好有共鸣！我之前也在琢磨这事儿，但没你想得这么深。你说的那个“功能点抽象为Skill”的坑，我最近刚被虐过——我们团队试着把一个项目管理工具的几个常用功能打包成API给Agent调，结果发现Agent经常选错Skill，比如想“创建任务”结果调成了“查询任务”，参数传得乱七八糟。感觉这确实不是API快慢的问题，是Agent的意图识别和上下文记忆太弱了，有时候连续对话里它自己都忘了刚才说过什么。

我特别想问一下，你们当时那30个Skill是怎么定义边界的？是按照业务动作（比如“新建客户”算一个），还是按数据对象（比如“客户”相关的所有操作算一个）？我总感觉如果分得太细，Agent选择起来容易懵逼；分得太粗，又变成一个大杂烩函数，灵活性很差。还有，你们有没有试过给Skill加一些“使用场景”的元数据，比如用自然语言描述“这个Skill适合在客户要求查历史订单时调用”，这样Agent会不会更聪明一点？

另外，你提到IDC预测70%软件，后面没说完，是70%软件会被MCP化吗？还是说现有SaaS里七成功能会直接被Agent替代掉？我其实挺好奇，像Notion这种开放MCP了，但很多中小SaaS根本没有人力去搞标准化，他们会不会被直接淘汰？还是说以后会有类似“MCP服务商”帮他们封装？感觉这个变化速度比我想象的快，有点慌但又很期待。

摩根士丹利那个“SaaSpocalypse”确实有点标题党，但方向是对的。你提到Agent上下文理解那点，我太有同感了。我们当时做类似的事，把一套HR SaaS拆成40个Skill，结果发现模型在意图判断上疯狂翻车。比如用户说“帮我查一下张三的年假”，Agent可能调用成“离职结算”接口，因为参数里都有“张三”和“时间”。后来我们不得不在每个Skill入口加一段few-shot的意图约束，还做了个轻量的路由层，让Agent先过一遍预定义的场景模板，再决定调哪个Skill。这其实就变成变相的“白名单”了，跟MCP那套纯粹靠Agent理解的愿景有点矛盾。

另外你提到Notion和Adobe推MCP Server，我反而觉得巨头们更在意的是护城河。他们把核心功能做成Skill暴露出来，但大概率会限制哪些参数能传、哪些逻辑能触发。比如Adobe的PS Skill，可能只允许Agent调滤镜，但不允许动图层结构。这本质上还是“能力出租”，不是“能力开放”。真要推翻SaaS估值逻辑，得看有没有第三方能基于MCP协议，把跨系统的Skill编排做成通用层——像Zapier但更底层。但问题又绕回来了，Agent的上下文窗口和规划能力，现在连处理5个Skill的连锁调用都经常断片，更别说大规模编排了。

所以我觉得现在谈“推翻估值逻辑”为时尚早，更像是把SaaS的API化从“可选”变成“必选”，但单位经济模型没变，甚至因为要维护Skill版本和Agent兼容性，运维成本还涨了。你后面说IDC预测70%软件，这个数据我挺好奇，是70%的软件会提供MCP接口，还是70%的传统UI会被Skill替代？俩概念差别挺大的。

老实说，你提到的“上下文理解”这个坑，我团队去年踩过一模一样的。我们当时是把一套电商后台的订单管理、库存调拨、售后流程拆成25个Skill，结果Agent在“取消订单”和“拦截发货”之间反复横跳——明明两个Skill参数结构高度相似，但业务语义完全不一样。后来我们不得不在Skill定义里强行加了一层“业务意图标签”，类似给每个Skill打上场景指纹，Agent选型时才稍微靠谱点。

MCP协议这块，我理解你担心的不是技术可行性，而是生态标准化的成本。现在Adobe、Notion这些大厂推MCP Server，表面看是开放能力，实际等于把自家产品的“功能原子”定价权交出去了——哪天Agent调度成本低于用户订阅费，SaaS按人头收费的逻辑确实会崩。但我觉得更值得警惕的是，如果Agent成了唯一入口，那软件本身的品牌认知会被稀释成“一堆Skill的集合体”，这对产品经理来说才是真噩梦。

另外你提到IDC的70%预测，我补充个数据：Gartner去年有个报告说，到2026年30%的SaaS厂商会内置Agent-native API。现在拼的不是谁家MCP Server多，而是谁的Skill能被Agent在零样本情况下正确调用。你们当时那30个Skill的准确率跑到多少了？我们最后是靠few-shot学习+人工编排兜底才勉强到85%，这玩意离“全自动”还差得远。

说实话，看到你说把200个功能点抽象成30个Skill那段，我太有同感了。我们之前搞内部工具对接MCP的时候也踩过类似的坑——参数传递的精度和Agent的上下文衰减才是真正的拦路虎。API响应再快，Agent理解错了意图也是白搭，有时候甚至因为语义模糊导致死循环调用，debug到想砸键盘。

不过我觉得你提到的“SaaSpocalypse”可能不是空穴来风，但也不是说SaaS要死，而是它的估值逻辑确实得改。以前大家看MAU、看用户黏性，现在Agent直接绕过UI调用功能，那用户停留时长、页面点击这些指标还有意义吗？反过来讲，如果你的软件能提供稳定、高效的MCP接口，让Agent像“调用函数”一样用你，那你的价值反而更直接——按调用量、按数据吞吐量付费，这不比按月付费更灵活？

我好奇的是，你们那30个Skill是怎么定义粒度的？我们试过把功能拆太细，结果Agent选择成本暴增，后来被迫合并成一些粗粒度接口，但灵活性又下降了。有没有什么经验可以分享？另外，IDC那70%的数据我没看到全文，是说70%软件会主动暴露API还是说被Agent替代？如果是后者，我觉得还得看行业，复杂业务流程里，Agent的上下文窗口和工具编排能力现在还远没到能随便甩开人的程度。

楼主说到的这个点很关键，尤其是“功能点转结构化API”和“Agent上下文理解”之间的鸿沟，这才是目前落地最痛的地方。

我这边也在做类似的事情，把一套HR SaaS的招聘模块拆成Skill，最头大的反而不是接口响应速度，而是Agent的意图识别和参数映射。比如“筛选候选人”这个动作，用户在不同场景下可能想按学历、按薪资期望、按最近活跃时间筛，但Agent如果只看到了一个泛化的“search_candidates”接口，它根本不知道要传什么参数组合。我们最后被迫在Skill层加了大量的上下文记忆和预设模板，才勉强把准确率从60%拉到85%以上。

另外我觉得，巨头推MCP Server是好事，但本质上是把原来藏在UI后面的业务逻辑直接暴露给了Agent，这对软件厂商来说是个双刃剑。一方面多了个分发渠道，另一方面你的核心能力变成了可被任意Agent组合的“乐高积木”，议价权会往Agent调度层转移。SaaS的估值逻辑确实该改改了，以前按用户数或者按API调用量，以后可能得按Skill的调用频次和关键度来定价，类似API网关按流量阶梯收费那种模式。

至于IDC那个70%软件被Agent调用的预测，我觉得太乐观了。现在大多数软件的Skill封装还停留在“把表单字段改成参数”的程度，真正能理解业务流的Agent还太少，更别说跨系统编排了。短期内可能还是垂直场景的“半自动Agent”先跑通，比如客服、数据报表生成这些。楼主怎么看这个时间线？

这帖子说到点子上了，尤其是那个“性能瓶颈不在API响应，而在Agent上下文理解”的观察，我太有同感了。

我们团队去年做过一个类似的尝试，把一套电商后台的订单管理、售后、库存大概150个功能点，打包成20个Skill丢给Agent去调。结果发现，最头疼的不是接口延迟，而是Agent像个脸盲症患者——明明定义得很清楚的参数，它在复杂场景下就是会选错Skill，或者把“查询退款状态”的参数传给“发起退款”这个Skill，直接原地炸锅。后来我们不得不在每个Skill的description里加了一堆自然语言的场景示例，才勉强把准确率从60%拉到85%。

楼主提到摩根士丹利说的“SaaSpocalypse”，我倒觉得这说法有点贩卖焦虑了。现在很多SaaS厂商搞MCP Server，说白了就是“开放式围墙花园”——API给了，但数据所有权和调用定价权还在自己手里。真正被颠覆的，可能只是那些靠“复杂UI流程”来收高额实施费的软件，比如某些老牌ERP的配置界面。至于Notion他们推MCP，更像是给自家生态加了个AI版的App Store入口，本质上还是想当平台。

不过有个疑问想跟楼主探讨：你们那30个Skill封装完之后，是怎么解决Agent的“意图歧义”问题的？比如用户说“查一下上个月那个大客户的情况”，这句人话到了Agent那，到底该调客户画像Skill还是销售记录Skill？我们现在是加了层用户意图预分类器，但感觉有点重，不知道有没有更轻量的方案能共享一下。

这个角度挺有意思的。我最近也在琢磨MCP这块，但还没真正上手试过。你说的那个“把200个功能点抽象成30个Skill”的过程，我特别好奇——你们是怎么决定哪些功能合并成一个Skill的？会不会出现那种“看起来能合并，但实际调用时参数打架”的情况？

另外你提到Agent的上下文理解是瓶颈，这点我深有同感。我试过让Agent调用一些简单的API，结果它经常选错Skill或者传错参数格式，感觉就像跟一个半懂不懂的新人对接工作。你们后来有没有找到什么trick来让Agent更“聪明”地选择Skill？比如是不是在Skill描述上加了什么特殊提示词，或者搞了个中间层做路由？

还有那个SaaSpocalypse的说法，我觉得可能有点危言耸听，但软件从“用户界面对接”变成“API能力暴露”之后，SaaS的定价逻辑确实得变吧？以前是按用户数收钱，现在Agent调一次算一次，那是不是得按调用量或能力单元定价了？感觉这比按人头收费复杂多了，用户能不能接受这种计费方式啊？

刚入坑AI agent开发不久，看到这个帖子真的很有共鸣。尤其是你说“性能瓶颈不在API响应，而在Agent的上下文理解”，这个点太真实了。我最近在折腾一个简单的知识库问答agent，也发现让模型准确选对skill这件事比想象中难很多——有时候它会胡乱调用一个不太相关的工具，或者参数传得七零八落。想请教一下，你们当时在抽象那30个Skill的时候，有没有什么经验或者框架来保证每个Skill的边界足够清晰？比如是不是把“查询客户信息”和“更新客户状态”拆成两个，还是合并成一个带不同参数的大Skill？另外，你说到IDC预测70%软件会被重构，这个数字我有点怀疑——毕竟很多传统SaaS的底层逻辑就是“卖界面”，如果界面没了，那它们靠什么收钱呢？还是说未来SaaS的估值会变成按Agent调用量或者能力暴露的次数来定？感觉这个变化对初创小团队可能是个机会，但老牌厂商转型应该挺痛苦的。

刚看完这个帖子，真的学到很多！我之前一直以为MCP就是给AI接个API那么简单，没想到背后是把整个软件的逻辑都拆开重做了。你提到的那个“从200个功能点抽象成30个Skill”的例子，让我特别有共鸣——我们小团队之前试过给内部工具做类似封装，结果卡在最简单的“让Agent知道该调用哪个Skill”上，经常明明该查订单状态的，它跑去调了用户信息接口，参数还传错。后来我们加了个“意图预判”的中间层，先让Agent把自然语言转成结构化的任务描述，再匹配Skill，准确率才勉强到80%左右。

不过有个问题想请教一下：你提到的Notion和Adobe搞MCP Server，这种“能力暴露”会不会让软件本身的用户界面价值被削弱？比如以后大家都用Agent直接操作Notion的API，那Notion的编辑器是不是反而成了个摆设？另外，IDC那个70%软件被吞掉的预测，感觉有点吓人，像我们这种做垂直领域小工具的，是不是得赶紧把功能拆成Skill，不然真就变成“AI时代的打工人”了？

实操过类似方向的人来握个手。你提到的那30个Skill抽象，我们踩过一模一样的坑。Agent上下文理解这块，我们最后发现不是模型选Skill不准，而是Skill本身的边界定义有问题——比如“创建客户”和“更新客户资料”这两个Skill，如果参数里都带“客户名称”和“联系方式”，Agent在调用时就会频繁混淆，甚至把更新操作误判成创建。后来我们强制给每个Skill加了一层“意图锚点”，比如在描述里写明“仅当用户明确提到‘新建’或‘录新客户’时才触发”，配合few-shot示例，准确率才勉强拉到85%以上。

另外你提到Notion和Adobe开放MCP Server，这事其实挺双刃剑的。表面看是软件主动把能力拆成乐高积木给AI用，但实际落地时，很多老SaaS的API设计根本不是按“任务闭环”来做的，而是按“数据CRUD”来做的。比如一个CRM的“导出报表”功能，背后可能涉及权限校验、数据聚合、格式转换三四个独立接口，Agent要串起来就得写复杂的子任务编排，相当于把原来UI里封装好的逻辑又拆回了一地鸡毛。我反而觉得，未来真正能跑通的SaaS，得在MCP层之上再包一层“场景编排”的元数据，比如直接告诉Agent“当你需要生成周报时，依次调用A、B、C三个Skill，中间等待用户确认数据范围”。不然就像你说的，Agent上下文理解永远是瓶颈，光靠模型自己摸索太费劲了。

楼主这个实战经验太有参考价值了，正好最近也在琢磨MCP这块。你提到把200个功能点抽象成30个Skill，这个数字比例很关键——我好奇的是，你们当时是怎么决定哪些功能合并成一个Skill的？是按业务流程切还是按数据对象聚合？会不会出现不同Agent对同一个Skill的理解偏差，比如一个Agent以为“创建订单”就只填基础信息，另一个觉得还得关联合同条款。

另外你提到的上下文理解瓶颈，我也有同感。现在很多MCP Server文档写得像OpenAPI那种纯技术规格，但Agent真正需要的是“什么场景下优先调哪个Skill”的语义指引。你们有没有尝试过在Skill描述里加一些“触发条件示例”或者“参数组合推荐”？比如“当用户提到‘加急单’时，优先选create_urgent_order并传priority=high”这种隐式规则。

还有一点想请教：你们内部CRM的Skill封装后，有没有遇到“过度暴露”的问题？比如原本UI上需要三步确认的操作，现在Agent直接调接口一秒完成了，结果业务方说缺少人工复核环节。这种安全与效率的平衡，你们是怎么处理的？

这个帖子看得我头皮发麻，但又有种“原来如此”的感觉。我其实刚入坑AI开发没多久，之前一直以为MCP就是让软件多个API接口，没想到你提到“从用户操作到能力暴露”这个底层重构，真的点醒了我。

不过你提到那个实践痛点我特别想问一下：你们团队当时是怎么解决Agent上下文理解问题的？是靠Prompt工程硬调，还是给每个Skill都加了比较详细的描述文档？我之前试过让Agent调一个简单的天气API，结果它老是把温度参数和城市参数传反，后来发现是Skill元信息写得太模糊了。感觉这种细节坑真的很多，但市面上好像没人专门讲怎么设计Skill的接口文档。

另外，你提到IDC预测70%软件，后面是什么？是70%软件都会变成MCP化吗？我最近在学LangChain，感觉Agent和Skill之间的编排逻辑已经够复杂了，如果真的大规模推广，会不会出现那种“Agent挑错了Skill然后疯狂重试”的死循环？听着就头大……

这个帖子看得我有点上头，虽然很多地方还在消化，但确实感觉打开了新思路。我之前一直以为MCP就是给AI配个“说明书”，让它知道软件有哪些功能，没想到本质是直接把UI那层给拆了，变成底层能力暴露。这跟传统SaaS靠用户点击、页面跳转来卖订阅的逻辑确实差太远了，难怪有人说估值要推倒重来。

不过我有个地方特别想请教：你提到把200个功能点抽象成30个Skill，这个“抽象”的过程具体怎么做的？是让业务人员写规则，还是靠算法自动聚类？我最近在折腾一个小项目，想把几个工具串联成Agent工作流，但发现功能点拆得太细Agent会懵，拆得太粗又可能用不上，卡在“颗粒度”这个点上。你当时遇到过这种取舍难题吗？比如CRM里“创建客户”和“更新客户信息”这两个操作，是合并成一个“客户管理”Skill好，还是分开更合适？另外，你提到的上下文理解瓶颈，有没有什么实用的解决思路，比如是不是要在Prompt里加类似“决策树”的引导？求分享点避坑经验，先谢过了。