开发者生态
evening
AI 代理的章鱼架构
2026-06-16
1 阅读
joshbetz
TorkBot 的设计有点像章鱼。这个架构是在一系列的死胡同和迭代改进中诞生的。当我说章鱼时,我的意思是,TorkBot 有一个集中的“大脑”,指挥着许多半自主的附属物,每个附属物都有自己的大脑,向中央调度员报告。静态车道是长寿的附属物。策展人就是其中之一。插件可以贡献其他功能,例如 Google Workspace 通道。车道模板不同。模板是一种可以为了有限目的而实例化的功能。沙箱快照又有所不同:它根本不是协作者,只是为未来沙箱支持的通道保存的文件系统起点。交互与功能 多种相互竞争的压力促使我采用了这种架构。对表面交互的响应能力——代理需要一种设计,其轮流或多或少地受到复杂性的限制,并且可以完全避免 I/O。这使得代理能够快速交互,即使任务或工作可能需要相当长的时间。能力——代理不应仅仅为了保持轮流效率而限制其所能完成的任务。它需要通过委派来执行复杂任务的机制,并能够接近实时地观察和指导这些任务。连续性——座席应保持连续的视角和个性。最好的连续性来自于不断策划的一次法学硕士对话。这样,性格和短期记忆就不需要“加进去”了;相反,它们是架构的副作用。这些压力迫使我进行了多“车道”的设计,如上图所示。 “前景”通道是用户通过表面活动进行交互的 LLM 对话。但在这里,我做了一个可能有争议的赌注:所有表面上的所有活动都会经历相同的前台对话。线程、通道、甚至平台都崩溃了。目前,这种认知复杂性可能超出了大多数模型的能力,甚至可能超出了前沿。但我确信这种情况不会持续太久。所有表面上的所有活动都经过相同的前台对话。我的 TorkBot 论文的一部分是押注于突发行为和突发智能。提出跨任意平台定义的边界分割 LLM 对话的系统与连续性目标是背道而驰的。我希望我的代理能够跨线程甚至跨表面建立链接。我希望代理能够轻松地继续在 Slack 中开始并在 GitHub 上继续的工作。如果我们在模型智能方面还没有做到这一点,我敢打赌我们很快就会做到,并且为该世界设计的代理系统将在直观性和功能方面超越竞争对手。章鱼是如何工作的 章鱼的想法正在这里做实际的工作。这是线束的形状问题。这并不是为了影响力而加入次级代理行列。这是一种出现并赢得存在的设计。毕竟,这又回到了上下文管理。每个附属物都有自己的上下文。前台通过与其他车道“交谈”来将工作移交给其他车道。通道间的交流只是文本,押注于训练前和训练后严重偏向散文作为意图载体的想法。前台选择一个通道模板(如果是沙箱通道,则选择一个虚拟机快照),并向该通道传递一条有关其想要的内容的初始消息。对于已经生成的车道,会发送一条简单的消息。通道可以承担执行一堆工具调用、遇到死胡同、执行 I/O 以及任何数量更复杂的沙箱启用工作流的混乱工作。这种混乱仍然包含在车道的环境中。通道之间通过两种机制进行通信:聊天,如上所述;通过通道的 ./shared 文件夹引用虚拟文件系统工件。前台对话可以在各个表面上保持连续,这就是我想要的个性和跨线程直觉,而不会成为每个中间工件消失的地方。附肢可以承载任务的本地工作存储器。前景可以承载关系、当前意图和综合。这也使得压缩变得非常明显。每个通道都会在某个阈值下连续异步压缩,如果通过一些奇怪的事件转变超过另一个更高的阈值,则会同步压缩。这种设计带来的好处是平均交互时间。完成可能需要一段时间。通道可以读取文档、等待 I/O、运行测试、碰壁并重试。由于某一附属物正忙而使前景变暗是不可以的。因此,前景通道必须保持小而无聊:稳定的提示、当前的意图、最近的表面活动、紧凑的摘要和证据引用。将搅拌物保留在附件中。这既是上下文效率的故事,也是缓存效率的故事。稳定的前台提示意味着更好