说详细一点，所以这还是单 agent 加上 skill 按需加载的思路呗

大方向对，但「按需加载」和这篇论文说的不是同一件事，差在这一步上，我说细一点。 先说这篇论文实际做了什么。 它把 skill 定义成一个三元组：语义描述（descriptor，用来做选择的）、执行策略（policy，怎么写怎么做）、执行后端（backend，是外部工具还是纯 prompt 内执行）。关键的一点是：选择器只看 descriptor，不看完整规格。所以严格讲，它默认的前提就是「按描述选、正文用的时候才展开」——这层确实是你说的按需加载。 但它真正的主题不是省 context，而是选择本身会不会崩。论文把多 agent 系统编译成单 agent 的过程拆成三步：先把每个 agent 的 system prompt 分解成若干原子能力，再给每个能力指定执行后端，最后把 agent 之间的通信边变成 skill 之间隐式的输入输出约束（比如「decompose 的输出格式必须能被 solve 直接吃」）。编译完的 SAS 是一次 API 调用，模型内部用 [DECOMPOSE]、[SOLVE]、[VERIFY] 这种结构化段落自己切分角色。 所以它其实更接近「把多个 agent 的一次协作，内化进模型的一次生成」——skill 库只有 3 到 4 个，根本不是从几十上百个 skill 里检索出一个。真正的检索/选择问题放到下半篇单独做了。 第二个要分清的点：不是所有多 agent 都能编译。论文给了三个必要条件——通信可以串行化（有拓扑排序，不丢信息）、agent 之间只共享同一份历史（没有私有状态）、底层模型统一。按这个标准，流水线、Router-Workers、Writer-Critic 迭代精修都能编译；而辩论/对抗型、并行采样取最优、agent 之间藏私有信息这三类编译不了。就是说「单 agent + skill」不是万能替代，而是有明确边界的。 效率上的数字：GSM8K 准确率 94.0 对 92.0，token 1407 降到 616；HumanEval 都是 100%，1400 降到 749；HotpotQA 反而从 84 涨到 88，4359 降到 1816。平均 token 降 53.7%，延迟降 49.5%，API 调用从 3-4 次变成 1 次。省得最多的是 HotpotQA 这种要在 agent 之间反复传检索段落的。 下半篇才是这篇最值得看的。 它从认知科学找了四个依据：Hick 定律（选择随选项数对数增长，但超过 8 个左右就失效）、Miller 的 7±2 和认知负荷理论、Shepard 泛化律 / ACT-R 的 fan effect（相似度导致的干扰）、以及 chunking 和菜单设计（每层 4-8 项最优）。 实验是从 5 个到 200 个 skill 的受控库，结果是准确率不是平滑下滑，而是在某个临界点之前基本稳住、过线之后断崖式下跌，是个相变形状的曲线。更关键的是归因：主导因素不是库的总量，而是 skill 之间的语义混淆度——两个描述听起来差不多的 skill，干扰比多出来 50 个不相干的 skill 更大。用 ACT-R 的说法，共享线索的事实越多，每个分到的激活越少。 补救办法是分层路由：先粗分类再细选，不要在几十个平铺的候选里一次决定。初步结果支持这个假设。 所以回到你的问题。是单 agent + skill，但更准确的概括是：用 skill 选择替代 agent 间通信，然后研究这个替代在库变大时什么时候失效。「按需加载」是它的实现前提，「选择容量的临界点」才是它的贡献。这俩的实践含义不一样——按需加载告诉你怎么省 context，这篇告诉你 skill 不是越多越好、堆到临界点会崩，而且解法是去重（把语义近的合并）+ 分层组织，不是单纯砍数量。 要挑刺的话：单作者的 technical report，摘要里 preliminary、initial 这些词都是作者自己写的；后端只用 GPT-4o-mini，benchmark 就三个，而且只测了纯内化的 skill（externalized 那半边没展开）。相变曲线本身挺有说服力，但「临界点具体在哪、换模型换领域还成不成立」现在都还没有答案，当方向参考合适，当定论不合适。