多任务编程智能体的路由与执行分层架构

一、问题的起点：当一个人同时管理多个编程智能体

编程智能体已经能够替开发者完成相当比例的编码工作。然而，当同时开启多个任务后，开发者往往陷入另一种忙碌：记住哪个会话正在修复哪个问题，把讨论群中临时调整的方案同步给对应的智能体，再把代码评审下方的新意见搬运回来。持续集成流水线报错时，还需要确认智能体是否正在等待自己发出“继续”的指令。

代码有人写了，进度却仍然需要人工盯守。这种负担的本质在于：任务的执行已经部分自动化，但任务之间的协调与上下文衔接仍然完全依赖人。

近期，某开源社区公布了一份关于超级智能体的设计文档，并开源了其编排框架的原型实现。该方案支持接入协作平台，在接收工作任务后创建任务、修改代码、跟踪评审，并将结果送回原来的讨论串。本文将该设计抽象为通用的“路由—执行”分层架构进行讨论，分析同一项工作从群聊走到合并请求，再遭遇流水线失败、进程重启时，系统究竟依靠什么把它接续下去。

二、朴素方案为何失效：单会话与多会话的两难

让一个会话同时管理多项工作，很快会遇到麻烦。它正在复现某个崩溃，用户又让它查看另一条流水线；工具输出尚未返回，群聊中补充的方案又到了。所有信息都涌入同一段对话历史，模型既要执行任务，还要不断判断新消息究竟在说哪件事。上下文污染与意图混淆会迅速降低执行质量。

每件事单独开启会话可以实现并行，却又缺少一个知晓全局进展的协调点。两项改动存在关联，或者用户在另一个平台更换了方案，仍然需要有人告诉各个会话。于是形成了两难：单会话导致上下文纠缠，多会话导致全局失联。

三、分层架构：路由层与执行层的职责分离

针对上述矛盾，该方案将系统拆分为两层：

• 路由层：接收消息，维护任务之间的关联关系，决定事情交给谁处理。
• 执行层：每个执行单元保留各自的上下文与执行工具，完成具体工作。一个执行单元内部还可以继续使用子智能体，上层无需跟随管理这些执行细节。

这种划分的关键在于职责边界的明确。路由层不替每个执行单元编写实现计划，不必读懂每一次测试输出，只处理任务之间的高层关联。有些智能体团队的主会话既规划又执行，还要频繁协调成员，反而成为最繁忙的节点；分层设计想要避免的正是这种情况。

由此引出一个重要推论：路由层可以使用较轻量的模型，执行层则使用能力最强的模型。路由的判断本质上是分类与关联问题——这条消息属于哪个任务、是否与已有任务相关、应该唤醒哪个执行单元——其推理复杂度远低于代码生成与调试。将强模型集中在执行层，可以在整体成本可控的前提下保证执行质量。

四、任务接续的核心机制：状态持久化与上下文重绑定

真正体现工程难度的，是任务在跨平台、跨进程场景下的接续能力。设想以下链路：

1. 用户在协作群中请智能体修复一个问题；
2. 智能体创建任务并开始执行；
3. 评审阶段，方案在代码评审中被修改；
4. 智能体应接着原来的任务处理，而非重新开始；
5. 执行过程中流水线失败，或服务进程重启；
6. 系统仍需从正确的位置继续。

要让这条链路成立，系统需要解决三个层面的问题。

4.1 任务标识与关联关系

每项工作必须有稳定的任务标识，消息与任务之间的映射关系需要独立于具体会话存储。当用户在另一个平台调整方案时，系统通过任务标识找到对应的执行单元，而不是要求用户先找对会话再重新交代背景。这对于习惯同时运行五到十个编程智能体的开发者而言，比多开一个聊天入口实用得多。

4.2 外部事件的归一化

代码评审意见、流水线状态变更、群聊补充说明，本质上都是外部事件。系统需要将这些异构事件归一化为统一的任务更新，再交由路由层判断应唤醒哪个执行单元。这一层的设计决定了系统能否适应不同协作平台与研发工具的差异。

4.3 执行状态的持久化

进程重启后任务能否继续，取决于执行状态是否被持久化。这里的状态不仅包括对话历史，还包括任务当前所处的阶段、已完成的步骤、待处理的外部事件等。一个常见的工程实践是将任务状态存储于外部存储服务中，执行单元本身设计为无状态或可重建，从而在进程故障后通过重放状态恢复执行。

任务状态示例（示意）
{
  "task_id": "fix-issue-xxx",
  "stage": "awaiting_review",
  "context_ref": "storage://tasks/xxx/context",
  "pending_events": ["ci_failed", "review_comment_new"],
  "worker_hint": "code-fix"
}

五、这一设计替人省掉了什么

综合来看，分层架构在以下环节减少了人工介入：

• 上下文搬运：用户不必在群聊、评审、流水线之间手动同步信息，系统通过任务标识自动关联。
• 会话选择：用户不必记住哪个窗口正在处理哪项工作，直接以任务为中心发起交互。
• 进度跟踪：任务状态的持久化使得进度可查询、可恢复，减少“它是不是在等我”的不确定性。
• 并行管理：路由层承担全局协调，执行层专注各自任务，开发者从协调者回归为决策者。

六、尚未解决的问题与工程挑战

该设计仍存在若干待解难题，值得在架构选型时保持清醒。

其一，路由判断的准确性。 轻量模型承担路由职责，意味着在语义模糊的消息面前可能出现误判。当一条消息同时涉及多个任务，或隐含地改变了某个任务的方案时，路由层能否正确识别关联，直接决定用户体验。

其二，状态一致性的代价。 任务状态持久化带来了存储与同步开销。在高频外部事件场景下，状态的读写与合并可能成为瓶颈，需要在一致性与延迟之间做出权衡。

其三，执行单元的可重建性。 进程重启后恢复执行，要求执行单元的中间状态可序列化、可重放。对于依赖大量工具调用与外部副作用的编程任务而言，完全确定性的重放并不容易实现。

其四，多任务关联的表达能力。 当前设计侧重于任务与消息的映射，但对于任务之间的依赖关系（例如任务 B 必须等待任务 A 的接口变更完成）缺乏明确表达。这类依赖在真实研发流程中普遍存在，需要更丰富的编排语义。

七、小结

将编程智能体从单会话工具演进为多任务协作系统，核心挑战不在于单个任务的执行能力，而在于任务之间的协调、上下文的接续以及状态的可靠持久化。路由与执行分层的设计，通过职责分离和模型分级，为这一问题提供了一条务实的路径。它未必是终局方案，但清晰地指出了方向：让智能体承担协调成本，把开发者从“记住哪个窗口在做什么”的负担中解放出来，专注于真正需要人类判断的决策环节。对于正在构建智能体协作基础设施的团队而言，这一架构的取舍与边界，值得作为重要的参考样本。