核心要点速览
- Yue指出，只拿到父代理摘要的子代理，会和上下文压缩一样丢失信息。
- 在13.7万token上比较了单独执行、分支与传统方式，分支带回的上下文增量最小。
- 比起保住缓存，更要紧的是避免过大的输入；结论是不需要部分委派。
摘要一交出去，前提就偏了
Mainplane AI创始人、曾就职于Browser Use的Alexander Yue（@Alezander9）在2026年11月6日写道，许多harness都是同一套模式：父代理把自己知道的内容做成摘要，子代理只根据这份摘要做出假设并行动，结束后再把自己的工作整理成新的摘要交回。
他说，这种缺失和上下文压缩是一回事。没让写的邮件被写出来、只想问价格却完成购买，这类事故都从这里来。该帖浏览超过20万，收藏3000，点赞1841，转发118。
出处[1]
让同一上下文分叉的实验
在Yue尝试的检查点方案里，最初的代理握有该做之事的完整上下文，而且这些输入已经进入缓存。在作业位置将会话分支，分支侧用与父代理亲自处理时相同的判断推进任务。结束后仍共享前缀，因此父侧缓存保持温热。
测量使用Opus 5.5、13.7万token的会话。分支在时间和费用上不如单独执行，但返回上下文的增长幅度在三种方式里最小。
出处[1]
落点是：停止委派
看完数字后，Yue更看重的是避免过大的输入，而不是保住缓存。他说，原先交给子代理的许多工作，中间插入检索再串行推进，或者从一开始就把全新会话并行拆开，效果更好。
结论是，做完一部分再把剩余交给另一个工作者的模式没有容身之处。要么是自己不干活、只编排全局的超级代理，要么是能引用过往会话的长期运行代理。帖子以不要用人类分工的成见来设计harness收尾。
出处[1]
X（推特）首发原帖
可在 X 上直接查看创作者发布的原帖与互动详情。
