做Agent应用的人大概都被问过一个问题接上MCP之后上下文是不是就能省不少我前两天刚跑完一轮60次真实任务的对照实测结论很干脆——MCP在省上下文这件事上的贡献是精确的0而换成子agent路线主上下文平均可以省下大约38.1%的token增量但在60次实测里也有4次不但没省反而比直跑还费。这篇文章就是这次测试的完整记录。我会先讲清楚我为什么要做这场对照实验、实验是怎么设计的然后分别拆解MCP和子agent在上下文账本上的真实行为最后复盘那4次“翻车”案例并给出我自己整理的一套任务选型判断标准。如果你也在做Agent应用、纠结该把工具直接挂在主线程还是拆给子agent这篇应该能帮你在选型上少走不少弯路。1. 为什么做这场60次对照实测省上下文不能靠感觉1.1 起因一个让我没法一句话回答的问题事情是这样的。前阵子有做Agent的朋友问我说他的应用接了好几个MCP工具感觉每轮对话都要把工具定义和数据塞进上下文token涨得飞快后来听说子agent能省上下文问我要不要全拆成子agent来跑。这个问题的前半段好答MCP确实不会帮你省上下文。但后半段“要不要全拆子agent”我没法拍脑袋回答。因为子agent的机制是把一段工作挪到独立上下文里做再把结果拿回来看上去是“隔离脏活”但隔离本身有开销——新建子agent要注入任务描述、角色设定、工具列表这些token又不是从天上掉下来的。省不省得拿数字说话。于是我决定做一轮可控的对照实验。我把任务集固定下来跑两套完全不同的执行方式一套是传统直跑模式一套是子agent模式共60次任务记录每次执行过程中的上下文增量变化。整个过程没有用生产环境的随机流量因为生产环境的任务复杂度不可控测出来的数据没法对比。1.2 实验设计同一批任务两种执行路线我准备了60个真实业务中比较常见的Agent任务分成三组每组20个检索摘要组从外部数据源检索资料并生成摘要涉及调用检索类工具、读取返回内容、整理输出。批量文件处理组处理一批本地文件比如批量重命名、批量提取关键字段、批量格式转换。多步规划组需要跨多个工具、多轮操作才能完成的任务比如“读取A文件→查询数据库→按条件修改B文件→生成报告”。三组任务分别跑两条路线直跑模式所有MCP工具直接挂在主线程上模型在同一个上下文窗口里完成全部推理和工具调用。子agent模式主线程遇到任务后把任务描述和相关数据打包交给子agent子agent在自己的独立上下文里完成工具调用和推理最后只把成果摘要返回给主线程。为了保证公平我在两种模式里使用了同一个模型API、同一套参数字段温度固定为0最大输出长度也保持一致仅执行架构上做区分。每个任务在两种模式下各执行一次因此60个任务总共产生了120次有效运行记录。1.3 为什么用“主上下文增量”作为核心指标这里有一个容易被忽略的细节统计上下文开销时到底该看哪个数我发现很多人喜欢看API返回里的total tokens也就是一次请求总共消耗了多少token。这个数包含输入和输出但它不能直接反映“上下文窗口被占了多少”。测试里真正值得盯的是主上下文也就是承载主线程推理的那个会话累计新增的token数量。因为主上下文长度直接决定了模型能不能记住关键信息、会不会触发截断也决定了后续每一轮请求的输入体量。子agent模式里子agent自己消耗的token其实不少但那些token发生在独立会话中不会挤占主上下文的容量。所以我的统计口径是从任务开始到结束主会话每一轮新增长的内容包括用户输入增量、工具返回增量、模型输出增量以及主线程内部推理输出。把这些增量累加就是该任务的主上下文增量。我额外留了一个对照字段记录全链路token总量包含子agent那边产生的所有token。为什么留这个因为很多人误以为子agent“省了38.1%”意味着总成本也省了38.1%实际上是不一样的。这一步我在后面的章节里会专门展开。2. MCP省上下文为什么精确是0机制决定不是测试误差2.1 MCP机制拆解它只是一个接线员不是一个压缩器先把结论说透MCPModel Context Protocol在协议层面上做的事情是给模型和外部工具/资源之间定义一套标准接口。它支持三类核心能力工具调用、资源读取、提示模板。不管是哪一类它做的事情本质都是一样的——把数据搬进模型的视野里。工具调用时工具的说明书名称、描述、参数schema要进上下文调用之后工具返回的结果要进上下文资源读取时被读取的数据内容要进上下文。MCP本身没有在模型和上下文之间增加任何压缩层、摘要层或者淘汰机制。它就像一根水管负责把你指定的水引到桶里但它不会帮你把水浓缩成冰。我在直跑模式里接了8个MCP工具仅仅这些工具的定义文本加起来就接近1.1万个token。也就是说只要主线程加载了这些工具每一轮请求都要背上这1.1万token的固定成本。MCP对这个固定成本没有任何削减作用。2.2 主上下文的token账本工具说明、参数、返回结果全都进了窗口我们可以把一次带MCP工具调用的完整token账目拆开看系统提示词包括角色设定和执行规则工具定义也就是MCP暴露给模型的JSON schema模型已经产生的历史消息当前这个任务的最新一轮用户输入模型发起的工具调用指令包含参数工具返回的原始结果往往是非常大的文本块模型根据工具结果生成的后续推理内容。这七项里至少有三项是MCP直接产生的工具定义、工具调用指令、工具返回结果。更关键的是对于大多数MCP工具返回结果是以原始形式进入上下文的——比如读文件的工具会把整个文件内容返回检索工具会把一长串命中的条目全部返回。这些内容不会自动生成摘要不会自动截断更不会在下一轮被悄悄移除。我在实测里的记录也验证了这一点在直跑模式中同一批任务平均产生的主上下文增量约1.5万token其中相当一部分是工具返回的原始内容。对比一套没有接入MCP、而是用少量手工提示词模拟工具调用的基线版本两边的主上下文增量几乎一致差值落在1%以内基本可以判定为统计噪声。MCP在省上下文这件事上的贡献就是这么精确的0。2.3 “省上下文”从来不是MCP协议的设计目标我后来想通了很多人之所以对MCP产生“省上下文”的期待可能是因为两个原因混淆了一是把“接入方式规范”当成了“上下文管理方案”二是把“少写提示词”误当成“少占上下文”。MCP确实让你不用再为每个工具手写一大段调用说明这是开发体验的改善不是运行时上下文体量的改善。MCP的resource能力允许你按需拉取资源这部分确实能减少与任务无关的数据空转但前提是“数据本身不需要被模型看到”。只要任务真正需要这份内容数据就必然进窗口MCP不会帮你把它压缩成摘要再放进去。所以如果你指望“接上MCP就能省上下文”几乎一定会失望。真正能省上下文的是架构设计是你选择把哪一段工作放在哪一层执行而不是你用什么协议去接工具。3. 子agent省38.1%到底省在哪隔离上下文与摘要回传3.1 子agent执行范式老板不看过程只收周报子agent的节省逻辑和MCP完全不同。它不是在协议层做优化而是在架构层做了“责任隔离”。直跑模式下主线程就像一个事事亲力亲为的人每一步推理、每一次工具调用、每一段返回结果全都摊在自己桌面上。随着任务推进桌面上堆满了中间材料模型每做下一步判断都要从这一大堆材料里翻找关键信息。子agent模式下主线程更像一个项目负责人拆解任务把具体的执行工作打包给子agent子agent在自己的独立会议室里干完全部脏活最后只交回来一份总结报告。主线程的办公桌上只多了这一份报告而那些冗长的中间推理、大量工具返回原文、反复试错的轨迹都留在了子agent自己的会议室里不再占用主上下文。这种隔离带来的直接好处是主上下文的增长速度大幅放缓。子agent干得越辛苦、中间过程越长主上下文省下的空间就越多。3.2 省下的空间到底装了什么我翻了几次详细的运行日志发现子agent模式下从主上下文里“消失”的内容主要集中在这几类多轮工具调用的完整返回。直跑模式里检索工具返回的10条条目全文都会留在主上下文子agent模式里主线程只收到“已根据检索结果筛选2条关键信息”这样的结论。模型自身的长串推理思考。不少情况下模型会自言自语分析一大段这些内容在直跑模式下全部留在主上下文子agent模式下留在子会话里。试错与纠错过程。比如有3次任务里模型第一版输出格式不对被要求重来直跑模式里第一版错误输出和修正过程全在主上下文里子agent模式下这部分开销被完全隔离了。这三类内容正是上下文里最有“膨胀潜力”的部分。它们的共同点是主线程最终并不需要知道细节只需要拿到结果。子agent模式等于把这些内容从主上下文中剥离出去了。3.3 数字验证分组统计与38.1%是怎么算出来的我在整理60次任务的数据时按任务分组做了统计结果如下任务分组直跑模式平均主上下文增量子agent模式平均主上下文增量平均节省率更费次数检索摘要组14,800 tokens7,900 tokens46.6%0批量文件处理组12,500 tokens7,800 tokens37.6%0多步规划组18,700 tokens12,780 tokens31.7%4全部60次平均15,333 tokens9,493 tokens38.1%4节省率计算公式(直跑模式平均增量 - 子agent模式平均增量) / 直跑模式平均增量 × 100%把三组数据代入(15,333 - 9,493) / 15,333 × 100% ≈ 38.1%可以看到子agent在每一组里都取得了正向节省其中检索摘要类任务节省幅度最大接近46.6%因为这类任务的中间过程最长、工具返回内容最多。批量文件处理任务节省率稍低但也很稳定。最值得玩味的是多步规划组整体平均依然省了31.7%但4次“更费”全部出现在这一组。3.4 必须澄清的另一本账主上下文省了总token未必省这里我必须给子agent“降温”。上面的38.1%只能说明主上下文的token占用下降了不代表你整体的API消耗也下降了。我在实验里记录了全链路token总量包括子agent会话里的所有消耗结果很有意思检索摘要组全链路总token和直跑模式基本持平有时略低有时略高。批量文件处理组全链路总token大概比直跑模式高10%左右。多步规划组全链路总token普遍高于直跑模式平均高20%以上尤其是那4次更费案例全链路总token高出更多。原因是显而易见的。子agent模式等于额外创建了一个完整会话这个会话有自己的系统提示词、自己的工具定义、自己的模型输入输出这些开销都不是免费的。主上下文确实瘦身了但换算成总token成本子agent模式通常并不会更省甚至更贵。所以子agent真正的价值不是“让token总量变少”而是“让主上下文保持精简”。它适合的场景是主上下文非常宝贵你需要模型在长任务里保持清晰状态或者多个步骤之间有强关联不能让前面的关键信息被大量中间过程挤掉。如果把节省率单纯理解成成本下降那就在实际优化方向上跑偏了。4. 那4次更费子agent翻车的复盘点4.1 排查路径从时间线日志和token增量入手60次实测里有4次子agent模式的主上下文增量比直跑模式还高。我当时没有直接看结论而是把每次任务的完整时间线日志拉出来逐段核对“主线程收到了什么”和“子agent回传了什么”。排查下来4次更费虽然不是同一个原因但它们的本质都指向同一个问题子agent的隔离机制在这些任务里没有形成“降维”反而制造了额外的搬运成本。下面我把这4次案例逐个拆开这些案例才是这次测试里对选型最有价值的资产。4.2 案例一子agent回传的内容冗长摘要几乎等于原文这是一个“连续修改配置文件并重新校验”的任务。直跑模式下主线程读取一份配置文件修改几处字段再执行校验命令整个流程产生的增量是6800 token。子agent模式下我把任务拆给子agent期望它只回传“修改完成关键变更点如下”。结果子agent非常“实在”它在最终消息里附上了完整的修改后文件内容、完整的校验输出日志以及校验失败时的堆栈信息。主线程拿到这些内容后因为后续流程需要判断是否继续修正又把这份大块文本全部保留在了主上下文里。这一趟下来主上下文增量反而达到9500 token比直跑模式多了39.7%。问题出在回传协议上。子agent并不天然知道“该压缩到什么程度”。如果你没有在任务说明里明确要求“只回传变更摘要、不要附原文”很多子agent会倾向于把最完整的信息全部交回来美其名曰“详尽汇报”。4.3 案例二父子会话之间反复搬运大块数据这个案子更典型。任务要求是“读取三个数据文件交叉比对后生成报表”。直跑模式里模型依次读三个文件在同一个上下文里做比对过程增量4200 token。子agent模式里我把三个文件的路径和比对要求交给了子agent子agent在自己的会话里完成了读取和比对生成了报表回传了一个指向报表文件的路径。到这里本来挺好主线程增量只有2900 token。但紧接着主线程需要根据报表里的具体数字做下一步操作而这部分数字在子agent的最终回传里没有包含于是主线程只能再调用读文件工具把整个报表文件重新读了一遍。这一来一回主上下文增量被二次放大到7100 token反超直跑模式69%。这个案例暴露了一个常见陷阱主线程后续还需要的数据子agent必须提前在回传结果里包含否则就会产生“父子之间的二次搬运”。省上下文的本质是减少重复而不是把数据来回倒腾。4.4 案例三本来一句话能做完的小任务非要拆给子agent第三个更费案例是一个很简单的任务“把某目录下3个文件名中的日期格式从YYYYMMDD改成YYYY-MM-DD”。对直跑模式来说这基本就是一次调用改名工具、一次确认输出的事全程增量只有1900 token。子agent模式里为了统一架构我还是套用了“创建子agent→下发任务→子agent执行→回传结果”的流程。这一套流程本身就有固定开销创建会话要注入角色设定、任务描述、工具列表执行完还要回传结果摘要。三样加起来主上下文增量直接冲到3400 token比直跑高了78.9%。这类“小到不需要隔离”的任务是最容易被过度拆分的典型。固定开销在简单任务面前占比太大节省无从谈起。4.5 案例四两轮独立无关联的检索被拆成两个互不相通的子agent第四个案例是两个独立的检索任务被连续执行且两个任务之间没有直接关联。直跑模式下主线程连续完成两次检索第一次检索的返回内容虽然留在上下文里但第二次检索时模型已经可以根据第一次的表述风格快速定位关键词整体增量3300 token。子agent模式下两个子agent各自独立执行第一个子agent回传了摘要第二个子agent回传了摘要。看起来主线程挺轻松但问题在于第二个子agent执行时完全没有第一个子agent的任何上下文它不知道第一个检索已经确定了什么口径只能重新完整地加载全部工具说明、重述任务背景。两次子会话的初始化开销全部落在主上下文之外的总成本里而主上下文里的有效信息量并没有减少最终增量还是到了5200 token反超57.6%。这类任务的问题在于“任务之间缺乏信息复用价值”。子agent拆得越碎重新初始化的次数越多浪费越大。4.6 这4次案例的共性没有形成“降维”把4次更费摆在一起看共性非常明显子agent确实隔离了中间过程但隔离后的结果要么太臃肿要么不够用要么任务本身太轻量。用一句话来说就是子agent没有把任务从“高维过程”压缩成“低维结果”反而在搬运过程中增加了新的维度。省上下文的核心不是“把任务扔给谁干”而是“让主上下文里只保留对未来决策真正必要的低维摘要”。这个判断标准比“是不是该用子agent”更本质。5. 实测结论怎么用直跑、拆分、还是混合编排5.1 主线程直跑的舒适区根据这60次的实测数据有几种情况我强烈建议保持主线程直跑不需要拆子agent执行步骤不足三步的短任务。比如“查询一个词的释义”“把某文件里的一行字段改掉”。这类任务步骤少、中间结果短直跑模式的增量在2000 token以内拆分子agent只会增加固定开销。主上下文需要保留全过程细节的任务。比如让Agent按固定流程逐步审核一份表单中间每一步的原始理由后续都要引用。如果拆给子agent细节被子agent吞掉主线程反而得回头二次读数。父子之间存在强数据依赖的连续任务。主线程下一步操作离不开上一步的完整上下文强行拆分子agent只会制造搬运成本就像案例二那样。判断方法很简单你可以在设计阶段问自己一个问题——“主线程后续的决策要素是否能被一个不超过200字的摘要完整覆盖”如果答案是能子agent才值得考虑如果不能直跑模式往往是更稳的。5.2 子agent真正擅长的任务画像那么子agent适合什么我在实测里总结出的画像也相当清晰中间过程长且主线程不关心过程细节。典型的就是检索摘要类模型要在大量原始条目中筛选、比对、归纳过程中还有大量试错。主线程只需要最终结论这是子agent收益最大的地方。工具调用会产生超大返回体的任务。比如读一个大文件、批量查询一批记录。直跑模式下这些超大返回体全塞主上下文子agent模式下它们留在子会话主上下文只收入一份压缩结果。需要并行处理多个独立子任务。多个互不相关的任务可以拆给多个子agent并行执行再统一回收结果。这种模式能让主上下文保持极度精简也更适合模型在并行环境中做全局决策。我实测里的检索摘要组节省率最高平均46.6%就是这个原因。5.3 一个更省的做法混合编排很多人的误区是“要么全拆要么全不拆”。实际上最优解通常是混合编排主线程只保留决策和审核逻辑把大规模工具调用包进子agent同时给不同子agent配不同的工具集避免主线程背一整套用不上的工具定义。我在测试后期调整过的方案是这样主线程只挂一个“派发工具”和一个“读取结果”工具剩下的6个重工具全部收进子agent场景里。主线程的system prompt因此瘦身了将近8000 token每轮推理的输入体量大幅下降。子agent开局加载完整工具集但它用完就散会工具定义的token不会留在主上下文里。这种做法有个额外好处即使某次任务需要长时间连续执行主上下文也始终保持在一个“决策者”的视角不容易被中途插入的大量工具返回体稀释注意力。模型在做最终判断时能在相对干净的上下文里看到关键信息这对输出质量的稳定也有帮助。5.4 我给自己定的三条执行准则实测结束之后我给自己整理了三条用于后续项目的执行准则任务交付物不清晰不拆子agent。必须明确知道子agent回传什么否则它会回传一堆你不知道怎么用的东西。任务过程超过10步或工具返回体超过5000 token优先考虑子agent。这类任务是上下文膨胀的重灾区。每次正式投入生产环境前先跑5次同形态任务的对照实测把更费率控制在20%以内再放量。子agent不是银弹不同任务形态的节省率差异非常大拿一次两次的观察结果推全量场景很容易翻车。我在实际使用中还有一个习惯每次任务结束后会把“任务形态→模式选择→主上下文增量→更费与否”记录成一张映射表。积累一段时间后你就能对自己的任务集形成很准确的判断直觉不再需要每次都靠实测来验证。说到底MCP和省上下文本就不是一回事。MCP是接入层协议子agent是执行层架构。前者解决的是“能接什么”后者解决的是“在哪个窗口里干活”。真正想控制上下文膨胀首先要做的不是接更多工具而是想清楚哪些内容该留在主线程的视野里哪些内容应该在别处干完活后只交一份摘要回来。这次的38.1%省的就是这么来的。