作者｜TFaaS 产品研究 · 2026 年 9 月

过去一年，几乎所有大模型厂商都在赶同一件事：接入 MCP。

MCP（Model Context Protocol，模型上下文协议）正在成为 Agent 时代的 HTTP。插件市场一天上线几十个新工具，知识库、Prompt 模板、MCP Server 成了 MaaS 产品的新三件套。

行业默认一个假设：协议接得够全、工具上得够多，Agent 体验就会自动变好。

真实情况恰恰相反。开发者依然要自己拼 Prompt、挂知识、调工具、兜底异常；企业客户依然不敢把写操作交给 Agent；普通用户的感知依然是——问问题可以，办事情不行。

协议完成了标准化，能力货架越摆越满，任务完成率却没有迎来质变。问题从来不在「能不能接上能力」，而在我们从一开始就误解了 MCP 三类能力的产品形态。

MaaS 卖的从来不该是模型、工具和知识，而是一条能跑通、可管控、可复用的任务流。

01 MCP 成了标配，MaaS 却还在卖「五金货架」

MCP 的普及速度，超过了绝大多数协议标准。

2024 年 11 月 Anthropic 发布 MCP，半年内 OpenAI、Google、微软全线跟进。到 2026 年稳定规范落地，公开 MCP Server 已达数千个，覆盖搜索、数据库、研发、办公、运维等主流场景。

但 MaaS 厂商的竞争焦点，高度集中在「接入数量」上。某头部云厂商的发布口径是：支持数百个工具、数十类知识库连接、上千个 Prompt 模板。

能力数量和任务完成率，从来不是线性关系。

根据 2026 年 Q2 多家 Agent 开发平台公开调试日志的抽样统计，纯 ReAct（推理—行动循环）模式下，涉及 5 步以上外部调用的复杂任务，端到端一次成功率普遍只有20%–40%。口径是：无人工干预、无额外工作流编排、默认模型配置。

工具更多了，成功率没有同步涨上去。

今天的 MaaS，是五层割裂的货架

当前主流 MaaS 产品，是一个「模型为中心」的分层堆叠结构，而且五层各自独立售卖、独立计费、独立控制台：

开发者的真实工作流，是在四个控制台之间反复横跳，最后还要在自己的业务代码里写异常重试和结果校验。

这就像一家五金店：螺丝、木板、电线、水管一应俱全，但店员不会帮你盖房子，房子盖歪了也不负责。

协议把能力接进了平台，却把「能力之间如何协同」的复杂度，完整转移给了开发者和用户。用户买到的是一堆合格零件，而不是一个能交付结果的产品。

需要划清一条边界：单轮问答、纯内容创作这类不需要外部能力的任务，今天的 MaaS 已经足够好用。问题集中在多步骤、要读写外部系统、有明确交付要求的任务型场景——而这恰恰是 Agent 被寄予厚望的核心场景。

02 协议只定义了「怎么接」，没定义「怎么串」

回到规范原点：三类能力各有边界

MCP 2026-07-28 稳定规范，把外部能力清晰地分成了三类。

规范的边界划得很清楚：可寻址的数据归 Resource，可复用的任务入口归 Prompt，需要执行的动作才归 Tool。

但 MCP 解决的只是「互通」问题：跨系统的能力如何被发现、鉴权、统一调用。它从未定义能力之间按什么顺序编排、上下文窗口如何分配、结果如何校验、循环何时终止、失败如何兜底、成功链路如何沉淀。

MCP 解决的是「能力能不能接上」的问题，而产品要解决的是「任务能不能跑成」的问题。

全链路存在六个产品断裂点

沿着一个提示词从输入到交付的完整路径走一遍，能看到六个明确的断裂点：

最深层原因：架构是跟着计费单元长出来的

表面原因是产品没做编排，第二层原因是协议没覆盖协同。再往下挖第三层：

MaaS 从第一天起，计费单元和组织方式就是围绕模型 token 设计的，不是围绕任务设计的。

产品资源按模型调度组织，成本核算按 token 消耗划分，控制台按资源类别搭建。在这样的计量逻辑下，自然会长出「资源货架」，而不是「任务流水线」。

最强的反方质疑是：这只是厂商产品成熟度不够，等生态自然演进，编排能力会被补齐。这个质疑站不住——只要还按 token 收费，厂商的核心激励就是卖更多 token，而不是帮用户用更少调用把事办成。只有计量单元从 token 变成任务，产品目标才会和用户目标对齐。这不是成熟度问题，是商业模式问题。

03 一个提示词，穿过 21 个原子节点

任务复杂度不是一种抽象感受，它可以被拆成不可再分的原子动作：每个节点只有一个职责，有明确的输入输出，可以独立验证、独立优化。

把三类能力的原子链路全部展开，再加上规划、推理、校验、交付，一个提示词从输入到任务闭环，完整穿过6 大阶段、21 个原子节点，并包含两类循环分支。

经过验证的架构是「确定性骨架＋动态分支补全」：核心步骤、必选工具、校验节点用 DAG（有向无环图）固定，保证大方向不跑偏；骨架之外的异常分支交给模型动态规划，比如测试失败后自主去查日志。

边界要讲清楚：开放调研、创意探索可以给高自主度；交易、运维、数据修改类生产任务，必须骨架优先，并设循环次数与成本上限的硬终止条件。

05 破局：从模型即服务到任务流即服务

下一代产品形态，可以命名为TFaaS（Task-Flow-as-a-Service，任务流即服务）。它的核心动作只有一个：把 21 个原子节点全部平台化，最小交付单元从「模型 token」变成「可运行的任务包」。

入口层：从 Prompt 文本到可运行任务包

最小售卖单元从 Prompt 文本升级为任务包，它包含六部分：Prompt 模板、资源依赖、工具链、参数规则、校验规则、输出契约。用户补齐参数即可运行，不必再跨三个页面手动拼装。

配套做一个 Prompt 编译器：输入任务目标、参数、可用资源工具和目标模型特性，编译出当前环境下最优的实例化 Prompt，实现一次编写、多模型适配。参数按「上下文提取→资源读取→追问用户」的优先级自动补全，每个参数标注来源与可信度。

上下文层：从消息拼接到结构化沙箱

每个任务启动时创建独立的结构化上下文沙箱，内部分五个固定分区，各有独立的 token 配额和淘汰策略：

在此之上做类虚拟内存的 token 预算调度：不常用内容压缩成摘要「换出」，需要细节再「换入」。资源读取改为三级按需加载——先读摘要判断相关性，再定位具体片段，只有全文审查类任务才读全文。同等窗口可承载十倍以上有效信息。

规划层：从二选一站队到双轨规划器

双轨规划器用任务包沉淀的最佳实践生成确定性 DAG 骨架，异常和开放分支交给模型实时补全；规划路径全程可视化，支持人工暂停、改计划、指定下一步。

工具侧建立能力画像中心：每个工具接入后自动跑评测用例，生成包含成功率、耗时、成本、风险等级、常见失败原因的「能力指纹」，同类工具按指标排序、支持主备兜底。调用前再加一道前置裁判，先校验格式，再校验参数来源可信度、操作是否超出任务目标，高风险操作生成预览卡人工确认。

执行层：从裸奔调用到三级隔离沙箱

工具执行按风险分级进入不同环境：

前置一个统一工具网关：凭证全部加密托管，模型和用户接触不到；自动适配多版本 MCP 和私有协议，承担熔断、重试、降级。工具结果必须归一化：成功只留相关字段、大结果转资源引用，错误翻译成「原因＋修复建议＋下一步」让模型自愈；循环终止控制器锁死次数与成本上限，连续两轮无新信息即强制终止。

推理质量层：从单模型打全场到分级流水线

推理环节改为多模型分级路由：任务规划用强推理模型，参数提取、结果摘要交给轻量模型，多模态识别用专属模型。一个任务多模型协同，同等效果下推理成本可下降 50%–80%（理论区间，需按场景实测，保守目标先取 30%）。

上下文组装做布局优化：依据模型注意力特性，把硬约束和结论放在头尾、参考资料放中间。输出阶段设三重质量门禁——合规门禁拦敏感内容，事实门禁把每条结论与资源和工具结果比对、无来源即标注，任务门禁检查是否覆盖全部目标；不通过只重生成对应段落，每个结论都可溯源。

交付沉淀层：从返回文本到交付物资产化

输出契约化：任务包预先声明交付形态，生成后自动渲染成文档、图表、PPT、结构化 JSON 或业务动作，对话给摘要、下载给完整文件、API 给结构化数据，不再二次加工。

交付改为分阶段验收：规划确认、高危操作确认、初步结果确认三个卡点，交付时附带执行报告，列清用了哪些资源、调了哪些工具、花了多少成本、哪些结论不确定。

最关键的是资产化：任务成功后，一键把完整链路固化成可复用的任务应用，可以分享、发布、定时执行、API 调用、批量跑。成功一次，永久复用。

下一代 MaaS 的竞争，不是谁的模型跑分更高，而是谁能让用户根本不用关心模型。

06 商业模式变革与三步落地

计费：从卖 token 到卖任务完成

TFaaS 采用按任务完成度计费：简单任务按次计价，复杂任务执行前给出成本区间并锁定上限，任务失败按未完成节点退费；企业客户用订阅制打包 token、工具调用、沙箱和存储；高度非标场景继续保留 token 计费，二者长期并存。

这一步会反转厂商的优化激励：按 token 收费，厂商天然希望调用更多；按任务收费，厂商才有动力用最短路径、最少调用把事办成。厂商的利润目标和用户的成本目标，第一次对齐。

反方担心「完成」难以界定。解法是用任务包里的输出契约和完成度校验，把「完成」变成可机器判定的事项；标准化程度高的场景先行，判定规则无法标准化的场景不进入按任务计费。

壁垒：从模型选型绑定到任务资产绑定

模型能力正在快速趋同，单一模型的领先窗口期越来越短。TFaaS 时代的护城河有四条：任务包生态、调度优化数据、企业级安全沙箱与合规能力、客户沉淀的私有任务资产。

其中最后一条最牢固：当一个团队把几十条核心流程固化成任务应用后，迁移成本不再是换一个模型 API，而是重写整套业务流程。

三步落地路径

任务包，才是 Agent 时代最小的数字资产。

结尾

最后给出三个判断。

第一，未来一年，MCP 会像 HTTP 一样成为无人讨论的基建标配，仅靠接入协议数量构建的壁垒会快速消失。

第二，大模型会从「产品本身」退居为任务流里的一个推理节点，客户买单的理由从模型参数变成任务确定性。

第三，最先跑通任务流闭环、把计费单元从 token 换成任务的平台，会拿到 Agent 生态的下一张入场券。

当所有人都在比谁的工具更多时，真正的问题只有一个：

你愿意为什么付费——是一堆零件，还是一个盖好的房子？

参考资料

说明：文中 20%–40% 成功率、70%–80% 工程失败占比为行业工程抽样口径，随任务类型波动，正式发布前建议补充一手调研数据。