上下文窗口：一个根本性瓶颈
每个 LLM 都在上下文窗口内运行，这是一个有限的内存缓冲区，限制了模型在任何给定时刻可以主动处理的信息量。
当你要求 AI 研究多个实体，上下文窗口会迅速填满。不仅仅是每个实体的原始信息，还包括：
- 原始任务规范和要求
- 一致输出格式的结构模版
- 每个项目的中间推理和分析
- 交叉引用和比较笔记
- 所有先前项目的累积上下文
模型面临一个不可能的选择：明确失败或开始走捷径，它总是选择后者。
更大的上下文窗口也无法解决
- 上下文衰减不是二元的。 检索准确性会随着与当前位置的距离而下降——即“迷失在中间”现象。上下文开头和结尾的信息比中间的信息更可靠被回忆起来。
- 处理成本不成比例的增长。 处理 400k token 上下文的成本不仅仅是 200k 成本的两倍——它在时间和计算资源方面呈指数级增长。这使得大规模上下文处理在许多用例中在经济上不切实际。
- 问题在于认知负荷。 即使有无限的上下文，要求单个模型在数十个独立研究任务中保持一致的质量也会产生认知瓶颈。模型必须在项目之间不断切换上下文，维护比较框架，确保风格一致性，同时执行核心研究任务。
- 上下文长度压力。 模型的“耐心”在某种程度上由其训练数据中样本的长度分布决定。当前 LLM 的后训练数据混合仍然主要由为聊天机器人式交互设计的相对较短的轨迹主导。因此,当助手消息内容的长度超过某个阈值时,模型自然会经历一种上下文长度压力,促使它加速总结或诉诸于不完整的表达形式,如要点列表。
上下文窗口是一个约束，但它更深层架构限制的症状是：单处理器、顺序范式。
架构转变：并行处理
何时使用： 涉及多个需要一致性分析的类似项目的任何任务。
何时不使用： 每个步骤都严重依赖于先前结果的深度顺序任务，或单处理器处理更具有成本效益的小任务（少于 10 个项目）。
不再要求一个处理器顺序处理 n 个项目，而是部署 n 个并行子代理同时处理 n 个项目。
多智能体架构运行方式：
- 智能分解： 主控制器分析你的请求并将其分解为独立、可并行化的子任务。这涉及理解任务结构、识别依赖关系并创建连贯的子规范。
- 子代理委托： 对于每个子任务，系统启动一个专门的子代理。它们每一个都是功能齐全的实例，每个都具有：
- 完整的虚拟机环境
- 访问完整的工具库
- 独立的互联网连接
- 全新的、空的上下文窗口
- 并行执行：所有子代理同时执行。每个子代理专注于其分配的项目，执行与单项目任务相同深度的研究和分析。
- 集中协调： 主控制器维护监督，在子代理完成工作时收集结果。子代理之间不相互通信，所有协调都通过主控制器流动，这防止上下文污染并保持独立性。
- 综合与整合： 一旦所有子代理都报告完成，主控制器将结果总合成一个单一的、连贯的全面报告。这一步骤利用了主控制器的全部上下文容量，它没有被原始研究工作所负担。
优化的缘由
- 规模化的一致质量。 每个项目都得到相同的处理，没有退化曲线，没有编造阈值，也没有质量悬崖。
- 真正的水平可扩展性。 架构随任务大小线性扩展，而不是像基于上下文的方法那样呈指数级扩展。
- 显著加速。 瓶颈从顺序处理时间转移到了综合时间。
- 降低幻觉率。 每个子代理都在其认知舒适区运行，子代理可以进行真实研究、验证事实并保持准确性。
- 独立性和可靠性。一个子代理工作中的错误或幻觉不会污染其他子代理，降低了系统性风险。