做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机制拆解：它只是一个接线员，不是一个压缩器先把结论说透：MCP（Model 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%，省的就是这么来的。
做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机制拆解：它只是一个接线员，不是一个压缩器先把结论说透：MCP（Model 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%，省的就是这么来的。