实测137k token会话后，我认为子代理根本不该存在

子代理是 AI 失败的最大原因。在大多数框架中：1. 主代理写下它所知内容的摘要。2. 子代理仅从该摘要开始，并做出假设。3. 子代理工作并回传其完成内容的新摘要。

这与压缩（compaction）的缺陷相同：所有摘要都是有损的。这就是你的助手如何生成你从未想要的电子邮件，或者购买了你只是让它查询价格的东西。

所以我尝试了一些新方法：检查点代理（checkpoint agents）。初始代理拥有关于需要完成什么的完整上下文。并且该输入已被缓存。

从会话当前位置分叉。将分叉发送到前面去执行任务，它将完全按照主代理本来会做的那样执行；它们的上下文是相同的。

更好的是，当分叉完成时，主代理的缓存会被子代理保持活跃（它们共享相同的前缀）。

我在一个使用 Opus 5.5 的 137k token 会话上进行了测量：
→ 主代理自行完成：67 秒，$0.38，上下文 +8-17k
→ 检查点：117 秒，$0.68，上下文 +2k
→ 经典子代理：123 秒，$0.57，上下文 +4-5k

但我的发现是：避免大输入比保持缓存更重要。而且大多数子代理任务要么通过检索串行完成，要么从一开始就拆分为在新会话上并行执行，效果更好。

我认为子代理委派根本没有立足之地。应该要么是一个只负责编排而不做实际工作的超级代理，要么是一个可以从之前会话中检索信息的长期运行代理，而不是一个部分完成任务并将其余工作委派给其他工作代理的工作代理。

不要基于我们对人类行为的假设来设计框架。