子代理省的从来不是时间，是上下文，可你派活那一刻账就已经算错了

摘要：子代理最流行的那套用法是“探路派便宜模型、执行派贵模型”，而做这套工具的厂商自己已经把这条默认改了——官方内置的探索型子代理从某个版本起不再固定跑最便宜那档，改成继承主会话的模型并封顶，理由写在文档里：它永远不比你已经选的那个更贵，也不会更便宜到看不懂地形。更麻烦的是另一条被忽略的硬约束：最便宜那一档模型的上下文窗口只有旗舰档的五分之一，而子代理最经典的用法恰恰是往里塞几十万词元的日志。同样反直觉的还有缓存——三档模型的起缓存门槛不是一个数，最便宜那档的门槛是最贵那档的八倍，很多子代理的固定前缀正好卡在中间，主会话里能缓存，挪进子代理就静默失效且不报错。这篇把派活这件事拆成五个可以按顺序问的问题，给出装得下、判断力、缓存复用三条路由维度，并解释同一个派活接口为什么会同时存在两种完全相反的经济学。

先摆两组打架的数据。

一组来自实践社区的共识：把子代理当上下文垃圾回收用，探路派便宜模型、执行留给贵模型，端到端成本能降一半以上。

另一组来自做这套系统的厂商自己的工程复盘：他们把研究型任务做成多智能体架构之后，词元消耗是普通对话的十五倍，换来的是相对单个旗舰模型高出九成的表现。

一个在省钱，一个在花钱，用的是同一个派活接口。

这不是谁错了。这是两件被同一个词盖住的不同的事，而分不清它们，正是大多数团队的词元账单失控的起点。

子代理到底在替你省什么？

先把最容易搞混的一条讲清楚：子代理省的不是墙上时钟的时间，是主会话的上下文占用。

这不是我的个人偏好，官方文档里写得相当直白。在Claude Code关于创建自定义子代理的那篇文档里，“该用主会话还是该用子代理”那张对照里，“延迟”被明确放在了该留在主会话的那一侧，理由的原话是：子代理从零开始，可能需要时间去收集上下文。

厂商自己没把它当加速器。这句话值得抄在显示器上。

那它当什么用？同一篇文档开头给的定位是：当一个附带任务会用搜索结果、日志或者你之后再也不会引用的文件内容淹没主对话时，用子代理——它在自己的上下文里干完那摊活，只把摘要交回来。

合适的形状：输入大、输出小、无状态

这三条要同时成立，缺一条价值就掉一大截。

• 输入大。子代理要读的东西比它要还的东西多一个数量级以上。读三个文件回答一句话，值；读一个文件回答一句话，不值。
• 输出小。能压成结构化摘要。如果输出的形状要看它读到什么才能定，说明你还没想清楚要它干什么。
• 无状态。它不需要知道主会话此刻的假设，主会话之后也不需要它的中间过程。

反过来读这三条，就得到了不该拆的场景。最典型的是迭代式排查：你在追一个问题，形成假设、验证、修正，每一步喂下一步。这里派子代理会把工作记忆切断——它继承不到你刚形成的那个假设，而摘要按定义就不包含那个假设。

第二典型的是父会话稍后还要再读一遍的情况。子代理返回“这五个文件要紧”，然后父会话把这五个文件全打开重读——同一份内容付了两次钱。这种事比想象中常见得多，而且在账单上完全看不出来，因为两笔都是正常的读取。

被隔离掉的到底是什么东西

“污染”这个词用得有点笼统，值得拆一下。子代理隔离的其实不是无用信息，而是那些会让后续判断变差的中间产物——试错时读过又证明无关的十几个文件、检索时命中又被排除的一堆候选、报错重试留下的三份几乎相同的堆栈。

这些东西的共同点是：它们在当时是必要的，事后是负担，而且模型不会自己把它们标记成过期。站内那篇讲上下文工程真正的杠杆是删不是加的文章里有一条实证结论正好接在这儿——上下文变长带来的退化不是一条平滑曲线，是撞悬崖，有的模型在某个长度突然塌方；而且伤害大小取决于问题与目标信息的语义相似度。

把这两条合起来读就得到一个不太舒服的推论：你在短上下文里跑通的验证，对长上下文没有预测力。所以“这条流程我试过没问题”这句话，在会话跑长之后是不作数的——而子代理正是为数不多能把这条曲线按住的手段。

为什么“并行更快”这个直觉在生产里几乎总是错的？

Cognition团队2025年6月12日那篇被反复引用的《别造多智能体》，作者Walden Yan给的两条原则原文很短：

Share context, and share full agent traces, not just individual messages.
Actions carry implicit decisions, and conflicting decisions carry bad results.

翻成人话是：要共享上下文，而且要共享完整的执行轨迹而不只是单条消息；每一个动作都夹带着隐含的决策，而互相冲突的决策一定带来糟糕的结果。

他给的反例是造一个像素小鸟游戏：一个子任务的智能体误解了指令，做了一个类似超级马里奥的背景；另一个子任务的智能体做的小鸟角色风格完全不搭。最后主体被迫把这两个各自跑偏的产物整合起来。

他对失败原因的判断是：决策变得太分散，上下文没法被充分共享。他给的最简方案是单线程线性架构；任务太长装不下时，再引入一个专门的模型把行动与对话的历史压缩成关键细节。

唯一的判据：交接契约能不能在派活之前写死

那个像素小鸟的例子里，真正出错的不是并行本身，是“背景该是什么风格”这个决策没有被任何人做出来，于是两个子代理各自做了一遍，做的还不一样。

由此得到一条能直接用的判据：只有当你在派活之前就能把每个子代理的返回结构写出来，才用并行派工。写不出来，说明有决策还没做，那就先在主会话里把它做掉。

站内那篇拆多智能体协作怎么配、三种并行方案怎么选的文章讲的是配置层面的怎么做，这条判据补的是要不要做——两件事分开问，顺序别反。

第三方框架把这件事拆成了两种拓扑

这条判据不是某一家的私货。LangGraph官方文档把多智能体系统归纳成监督者与交接两类拓扑，区别正好落在决策权归谁：监督者模式里，由一个中心节点决定下一步交给谁，子节点只管干活；交接模式里，每个智能体自己决定要不要把控制权移交给另一个，以及移交时带上什么。

把它和前面那条判据对上就很清楚了：监督者模式要求你在设计期就把分工写死，交接模式把这个决定推迟到运行时。写得死的用监督者，写不死的说明你对任务的理解还不够，那用交接模式也只是把没做的决定丢给模型去做，而模型做这个决定的依据比你少。

这也解释了为什么那么多多智能体项目在演示里很漂亮、上生产就散架：演示用的是路径固定的任务，任何一种拓扑都跑得通；生产里的任务路径不固定，于是设计期写死的那份分工开始和实际需要的分工对不上，而没有人会在中途去改它。

那厂商自己为什么反着来？

现在回到开头那组打架的数据，因为它是这篇文章里最值得琢磨的地方。

Anthropic工程博客那篇复盘自家多智能体研究系统怎么造出来的文章给了几个很硬的数字：这套系统由一个旗舰档的主导智能体做规划，并行拉起三到五个次级档的子智能体，各自独立检索、各自评估工具结果、把发现交回主导者综合，最后还有一道单独的引用核对；内部评测里它比单个旗舰档模型高出九成以上。代价是词元消耗大约是普通对话的十五倍。

还有一个更值得注意的发现：在他们的浏览类评测里，光是词元用量这一个变量就解释了约八成的表现方差，工具调用次数和模型选择只解释剩下那部分。

把这两件事放在一起，事情就清楚了：他们不是在省钱，他们是在用钱买表现。而社区那套“子代理降本六成”的做法，目的是省钱。同一个接口，两个方向相反的目标。

两种经济学，两套账

这张表最有用的是最后一行。两种用法的失败长得完全不一样，所以只看总账单是判断不出来的。一条隔离噪声型的线，账单降了两成就算成功；一条并行探索型的线，账单降了两成大概率说明它根本没跑起来。

“词元用量解释八成方差”这句话该怎么读

那个八成的数字很容易被读成“多花钱就有用”，但它真正的含义要更刺一点。

它说的是：在那组评测里，一个系统表现好不好，主要不取决于它用了什么模型、调了几次工具，而取决于它总共处理了多少词元。工具调用次数和模型选择加起来只解释剩下的那部分。

这条对做架构的人有两个后果，方向相反：

• 好消息是，并行确实有效——多个独立上下文窗口同时推理，加起来的处理量是单个窗口做不到的，这就是那九成提升的物理来源。
• 坏消息是，如果表现主要由处理量决定，那么任何以减少处理量为目标的优化，都是在拿表现换成本。“既省钱又提质”这种话在这个维度上不太成立，你只能在某一段区间里做得比别人更有效率。

所以这两派的分歧其实可以调和成一句话：省词元的做法能省的是无效处理量，省不到有效处理量头上。子代理隔离噪声，省的是主会话反复重读那堆废弃中间产物的量，这部分本来就没产生价值；而并行探索增加的是有效处理量，它买的是覆盖面。前者该省，后者省不得，把两者混成同一笔账才是问题所在。

那条被两边都跳过的判据

社区那套建议是“调度用便宜模型，叶子节点用贵模型”，理由是调度只是路由和状态跟踪；厂商的做法正好相反，主导者用旗舰档。两边都对，因为它们说的“调度”不是一件事。

判据可以浓缩成一句：这个调度器要不要决定“问题是什么”。

• 如果它只是把已经定义好的三件事分给三个人，然后等结果拼起来——那是路由，便宜模型足够。
• 如果它要把一个模糊的问题拆成若干个可以并行的子问题，还要在结果回来之后判断哪些可信、哪些矛盾、缺了什么再派一轮——那是全场最难的一步，省在这里等于省错了地方。

厂商那套研究系统属于后者：把一个开放式的研究请求拆成子查询，本身就是整个任务里认知负荷最高的动作。社区那套博客写作管线属于前者：选题、调研、写作、配图这四步是人事先定死的。

便宜模型探路这条默认路由，厂商自己已经改了

这一节是我核材料时最意外的一处。

官方内置了一个叫Explore的只读探索型子代理，用来在不改动任何东西的前提下搜索和理解代码库。早期版本它固定跑在最便宜那一档模型上——这正是社区那条“探路派便宜模型”建议的来源。

但从版本2.1.198起，这条默认被改掉了。现在的行为是：Explore继承主会话的模型，并且在官方接口上封顶在旗舰档——文档给的理由原话是，这样Explore永远不会跑在比你已经为这个会话选定的那个模型更贵的模型上。主会话跑在中档，Explore就跑中档；主会话跑在最便宜那档，Explore也跑那档。

注意这个改动的方向：默认值从“尽可能便宜”变成了“不比你贵”。这两句话听起来差不多，实际差得很远——前者是成本优先，后者是一致性优先，成本封顶。

为什么会往这个方向改

文档没有解释动机，但从工程上不难推：便宜模型探回来的那份地形图，执行那一步的模型未必看得懂。

探路子代理的输出是一份高度压缩的摘要，压缩的过程本身就是一次判断——哪些细节值得留、哪些可以扔。压缩得越狠，对压缩者的判断力要求越高。一个能力档次明显低于执行者的模型做这件事，扔掉的可能恰恰是执行那一步唯一需要的那条线索。

这个失败模式在账单上完全看不见：探路那一步很便宜，执行那一步也正常完成了，只是结果差一点。你会以为是执行模型不行。

顺便，官方文档也保留了退路：你自己定义一个同名的子代理就能覆盖内置的那个，并且自己指定模型字段。所以想继续走便宜路线是可以的，只是这件事从默认变成了显式选择——它逼你为这个决定负责，这个变化本身比默认值是什么更重要。

最便宜的那一档，装得下你要它读的东西吗？

这是我认为整个话题里最被忽略的一格，而且它是一道硬墙，不是一个权衡。

几乎所有讲子代理的材料都会举同一个例子：派一个便宜模型去扫几十万词元的日志，定位失败模式，返回一段堆栈。这个例子有个问题——按当前的模型阵容，最便宜那一档根本装不下几十万词元。

按官方模型总览页给出的规格，旗舰档和中档的上下文窗口都是一百万词元级别，而最便宜那一档是二十万。差五倍。

这张表右边那一列和左边那一列合在一起看，会看出一件相当反直觉的事：子代理最经典的用法是往里塞大输入，而最便宜的那一档恰好是窗口最小的那一档。这两件事在方向上是打架的。

所以“扫大日志派便宜模型”这条建议，在今天要么得改成中档，要么得先分片再派。分片这件事本身又有成本——它需要一个知道该按什么维度分的东西，而那又是判断力。

被截断的失败长什么样

更麻烦的是超窗的失败方式。它通常不表现为报错，而表现为子代理只读到了前面一部分就开始回答，而且答得挺像样。它不知道自己没读完。

站内那篇讲词元估算工具那把尺子刻的是哪一代分词器的口径的文章里有一条结论正好接在这儿：本地估出来的词元数和真实口径能差出五成，也就是说你以为塞了十五万，实际可能已经过线。派活之前先量一遍，别靠估。

窗口这一格该放在哪一层去看

站内那篇讲智能体骨架的六层该按什么顺序建的文章有一条结论可以直接借过来：真正撑住稳定性的是评估与容错这两层，而它们通常被排在最后。窗口这件事就是典型的容错层问题——它不是能力问题，是边界问题，而边界问题只有装了传感器才看得见。

具体到子代理，最省事的传感器是一行断言：派活之前把输入量一遍，超过目标模型窗口的八成就直接抛错，别让它跑。宁可失败得很响，也别成功得很安静。这一行代码的性价比，比这一整节讲的所有选型考虑加起来都高。

冷启动税到底是多少，为什么它不是一个固定数字？

每派一次子代理都有固定开销：系统提示重新计算、项目规则文件重新加载、工具描述重新注入。社区常给的经验值是每次三五千词元，低于一万词元的有效工作量就不划算。

这个量级大体没问题，但“固定开销”这个说法不准确——它不固定，而且不均匀。

官方文档里有一条几乎没人引用的说明：内置的Explore和Plan这两个子代理会跳过项目规则文件和父会话的版本控制状态，理由是让研究保持快速和廉价；而其余所有内置子代理，以及你自己写的每一个自定义子代理，两样都会加载。

换句话说，免税待遇只发给两个官方子代理。你自己写的那七八个专家子代理，每一个每一次派活都要把整份项目规则文件重新读一遍。项目规则文件写到三千词元，七个子代理各派一次，光这一项就是两万一千词元，而这些内容主会话里本来就有一份。

站内那篇讲项目规则文件不是写得越详细越好、最优行数是多少的文章原来的论据是注意力稀释，这里给了它第二条更算得清的理由：规则文件的长度会被子代理的数量乘一遍。

缓存那一格才是真正的分水岭

但冷启动税还不是最贵的那部分。最贵的是缓存。

按官方提示缓存文档给出的价格倍率，缓存写入是基础输入价的1.25倍，缓存读取只有0.1倍。也就是说一段稳定前缀只要被复用一次以上，成本就降到了原来的十分之一附近。主会话之所以跑几十轮还不至于破产，很大程度上靠的是这一格。

问题是缓存是按模型分区的。你为了省钱把子代理换成另一档模型，等于换到了一个空的缓存分区——那段本来能按十分之一计价的前缀，在子代理这边要按1.25倍重新写一遍。

然后是这篇文章里我最想让人记住的那个数字。同一份文档里列了各模型的最小可缓存前缀，而这个数不是单调的：

最便宜那一档的起缓存门槛，是最贵那一档的八倍。

这件事的后果很具体：一个子代理的固定前缀——它自己的系统提示加上工具描述——很容易落在一两千词元这个区间。这个长度在旗舰档和中档都能进缓存，挪到最便宜那一档就进不去了，而且没有任何提示。你以为省了钱，实际是把一段本来能按十分之一计价的内容，换成了每次全价重算。

怎么查？文档给的办法很直接：看返回里的缓存读取词元数。如果重复派活很多次它一直是零，那就是没进缓存，去比对长度和门槛。

顺带还有一条同源的坑：同一份文档的失效层级表里写着，工具定义只要变动，工具、系统、消息三层缓存全部作废。所以那种“按任务动态增删工具”的设计，看着灵活，代价是每改一次就把整条会话的缓存清零一次。

把一次真实的派活算成数字

抽象的倍率不如一笔具体的账好使。假设一个搜索型子代理，固定前缀是系统提示八百词元加工具描述一千二百词元，共两千词元；项目规则文件三千词元；每次工作输入两万词元，输出五百词元。一天派四十次。

看最后一行。它是四种配置里看起来最省的那个——模型最便宜、前缀最短、规则文件也没加载——实际是唯一一个每次都要全价重算固定前缀的。为了省钱做的三件事，最后一件把前两件的收益抵消掉了，而且没有任何提示。

这个坑之所以隐蔽，是因为它的三个成因单独看每一个都是对的：换便宜模型对、精简前缀对、不加载不需要的规则文件也对。是它们凑在一起才越过了那条门槛线，而门槛线在文档的另一页上。

顺带说，这类“单独审查每一项都合规、凑一起才出事”的故障，在站内做过基础设施排查的那几篇里反复出现过。它的通用特征是：没有任何一个环节可以被指认为犯错的那一环，所以复盘会开完通常没有结论。

那到底该按什么路由模型？

社区那套说法是“按决策复杂度路由，不按输入体量”。这句话本身没错，但只够一半——它假设了所有模型都装得下、缓存行为都一样，而上面两节说明这两个假设都不成立。

补全之后是三个维度，按顺序问：

1. 装得下吗？把实际输入量量一遍，超过最便宜那档的窗口，这一档直接出局，不用讨论价格。
2. 输出需要判断力吗？需要取舍、需要从零碎证据里综合、需要决定问题是什么的，往上走一档。只需要准确不需要创造的，中档就够。确定性的分类和格式转换，最便宜那档最划算。
3. 这段前缀会被复用多少次？只派一次的，缓存不用考虑；一天要派几十次的，先确认前缀长度过了那一档的门槛，过不了就把前缀补厚，或者干脆别降档。

第三条听起来很怪——为了让缓存生效而故意把提示词写长——但账是这么算的：把一段一千八百词元的前缀补到四千一百词元，多出来的部分第一次全价写入，之后每次按十分之一读取。派活超过三次就回本了。这不是优雅的做法，是门槛设成阶梯就一定会产生的套利空间。

成本模型里最容易漏的两项

常见的单次派活成本公式是：冷启动开销乘输入单价，加上工作输入乘输入单价，再加输出乘输出单价。这个公式漏了两项，而漏掉的这两项恰恰在生产里占比最大：

• 缓存分区切换的损失。本来能按0.1倍读取的部分，换模型后按1.25倍重写。前缀越长，这一项越大。
• 父会话重读的重复计费。子代理读过、父会话又读一遍的那部分，在两边都是正常读取，账单上没有任何标记。

观测上我建议记两个比值，按子代理分桶：开销词元除以工作词元，以及缓存读取词元除以总输入词元。第一个长期高于0.3，说明委派策略有问题；第二个长期接近零，说明你的子代理压根没吃到缓存。站内那篇拆订阅档、团队版与接口计费到底怎么算、省钱机制在哪的文章可以配着看，那篇讲的是账面价格，这里讲的是这些价格在多代理结构下怎么被放大或抵消。

工具权限继承那一格，最容易漏的是什么？

子代理会继承一样很多人低估的东西：工具权限。官方文档对内置子代理的表述是，每一个都继承父会话的权限，再叠加额外的工具限制。

标准防御是最小权限白名单：搜索型子代理只给读文件和搜索，写注释型子代理只给读和改文件、不给命令执行。这条大家都知道。

但有一格几乎所有人都漏：技能工具。文档里写得很清楚——如果不把技能这个工具从子代理的工具清单里去掉（或者放进禁用列表），子代理在执行过程中仍然可以自己发现并调用项目级、用户级和插件提供的技能。

这一格为什么危险，稍微推一下就明白：你给一个子代理配了只读权限，觉得很安全；但它能调用的某个技能内部可能会执行命令、写文件、发网络请求。你限制的是它直接能做什么，没限制它能借谁的手。

这条在提示注入的场景下尤其要紧。如果一段注入指令从外部内容——比如抓回来的网页、用户提交的评论——钻进了子代理的输入，它就能借技能这条路触发父会话本来会拦下来的操作。站内那篇讲从安全评审到权限模型与提示注入防御的文章给了完整的防御面，这里只补一句：白名单要连技能一起白名单，只列工具是漏的。

一份能直接照着走的派活检查清单

把前面几节压成五个按顺序问的问题。任何一步答“否”就停在主会话里做。

1. 有效输入是不是超过一万词元？低于这个量级，冷启动税吃掉全部收益。
2. 输出能不能压到两千词元以内，且结构在派活前就写得出来？写不出来，说明还有决策没做。
3. 父会话之后需不需要看原始证据？需要，就别拆——摘要漏掉的那个细节往往就是根因。
4. 目标模型装得下这些输入吗？量一遍，别估。
5. 这段前缀会被复用几次，过了那一档的缓存门槛没有？高频复用的，缓存这一格的权重高于单价。

还有一条不属于清单但值得单列的经验：同一形态的任务在主会话里处理过至少三次之后，才值得抽成一个固定的专家子代理。专家化过度的代价是七个子代理各自维护一份提示词，每个一个月被调用两次，质量在你不知道的情况下缓慢漂移。这跟微服务拆早了是完全一样的病。

这套东西落到独立站运营的活上是什么样？

上面全是工程语言，落到实际业务上其实很好对号入座。

最后那一行是本文两条主线交汇的地方，也是我见过最多人踩的一格：它看起来是最标准的子代理场景，恰恰因为标准，大家会直接照抄“派便宜模型”这条建议，然后撞上窗口。

一个美妆站的真实返工

去年年底帮一个做护肤的出海站搭产品页批改流水线，第一版设计得挺漂亮：五个专家子代理，分别管标题、描述、成分表、结构化数据、内链，全部派最便宜那档，主会话负责调度和合并。

跑了两周，两个毛病同时冒出来。

第一个是内容打架。成分表那个子代理按法规口径把某个成分写成了标准名，描述那个子代理按营销口径写成了俗名，同一个页面上两个名字。这就是那条“互相冲突的决策带来糟糕结果”的原话在电商页面上的样子——没有任何一个子代理做错了，是“该用哪个口径”这个决策从来没有人做过。

第二个是账。五个子代理各自的固定前缀都在两千词元上下，全都卡在最便宜那档的门槛下面，四十个页面跑一轮就是两百次全价重算。当时没意识到，只觉得比预期贵。

返工的做法很朴素：五个砍成两个。第一个负责“读”——把页面现状、法规口径、竞品同类表述一次性读完，返回一份统一的事实清单；第二个负责“写”——拿着这份清单一次性把五处全改了，中间不再拆。口径冲突消失了，因为它现在只在一个上下文里被决定一次。

成本也降了，但降的原因跟我们最初以为的完全不一样：不是因为用了便宜模型，是因为派活次数从五次降到两次，而且合并后的前缀过了缓存门槛。

这件事之后我给自己定了条规矩：拆子代理之前先问一遍，被拆开的这几件事之间有没有共享的判断。有的话，那个判断必须在拆之前做完，或者干脆别拆。

还有一件事值得连起来看。本批另一篇讲内容自动化的触发器该挂在业务事实上、产出要有回执的文章，讲的是流水线层面的可发现性；这篇讲的是流水线内部单个环节的派活决策。两者是同一件事在两个尺度上的表现——没有回执你不知道整条线好不好，没有那两个比值你不知道单次派活值不值。两个尺度都装了仪表，才谈得上调优。

保哥的一句话总结

子代理是个动力工具，大多数任务不需要动力工具。默认留在主会话，能说出“我要隔离掉哪一段污染”或者“我要并行探索哪几条互不相干的路”才派活。说不出来的时候派出去的那些，通常不是在解决问题，是在把问题换个地方发生。

常见问题解答

子代理和技能到底怎么选？

判据只有一条：父会话需不需要对中间推理过程保持无感知。需要隔离的，用子代理；不需要隔离、只是想复用一段指令的，用技能。技能跑在父会话的上下文里，它是提示词扩展，不产生隔离；子代理是独立的一次调用，有自己的上下文窗口和系统提示。官方文档在“该用子代理还是主会话”那节之后专门补了一句，想要可复用的提示词或工作流就考虑技能，说的是同一件事。

把调度器换成便宜模型，一定能省钱吗？

不一定，取决于这个调度器要不要决定问题是什么。如果它只是把已经定义好的几件事分发下去、等结果拼起来，那是路由，换便宜模型通常有效；如果它要把一个模糊的问题拆成可并行的子问题，还要判断回来的结果哪些可信、缺了什么再派一轮，那这一步是全场认知负荷最高的，省在这里省错了地方。做这套系统的厂商在自家研究型产品里用的正是旗舰档做主导者。

为什么我给子代理换了便宜模型，账单反而涨了？

最常见的两个原因都跟缓存有关。一是缓存按模型分区，换模型等于换到空分区，本来能按十分之一读取的前缀要按1.25倍重新写入；二是最便宜那一档的最小可缓存前缀是四千多词元，是旗舰档的八倍，很多子代理的固定前缀落在中间，在主会话能缓存、挪过去就静默失效。查法是看返回里的缓存读取词元数，长期为零就是没进缓存。

项目规则文件要不要给子代理加载？

官方的做法是分开对待：内置的探索型和计划型子代理会跳过规则文件和父会话的版本控制状态，其余内置子代理和所有自定义子代理都会加载。这意味着规则文件的长度会被子代理的数量乘一遍，写到三千词元、七个子代理各派一次，光这一项就两万多词元。所以子代理用得多的项目，规则文件更该精简，这跟注意力稀释是两条独立成立的理由。

子代理的工具白名单，除了工具还要限制什么？

技能。这是最容易漏的一格：如果不把技能这个工具从子代理的工具清单里去掉或者加进禁用列表，子代理在执行过程中仍然可以自己发现并调用项目级、用户级和插件提供的技能。后果是你限制了它直接能做什么，但没限制它借别人的手做什么——某个技能内部可能会执行命令或者发网络请求。有外部内容进入子代理输入的场景下，这条尤其要紧。

怎么知道自己的委派策略是不是坏的？

按子代理分桶记两个比值。第一个是开销词元除以工作词元，长期高于0.3说明拆得太碎，冷启动税占了主导；第二个是缓存读取词元除以总输入词元，长期接近零说明子代理压根没吃到缓存。这两个数都能从接口返回的用量字段里直接算出来，不需要额外埋点，但默认没人看，得自己接一个看板。

权威参考资料