Super-agent把Router和Worker显式分层，Router不做任何具体执行、只做分解分发和汇总，Worker上下文隔离、只向Router汇报——“让用户不感知底层多会话并行”的设计目标，在Router本身判断失误、把一个复杂任务拆错方向时，用户到底有没有手段介入和纠正？

Router 误判的可干预性：从黑箱自治到可观测、可纠正的分层编排

摘要与核心论点

Super-agent 的显式分层——Router 只做任务分解、分发与汇总，Worker 上下文隔离、只向 Router 单向汇报——在工程上解决了两类老问题：一是单会话上下文膨胀导致的注意力稀释，二是多任务并行时状态互相污染。但这一架构同时把“任务理解”与“任务执行”彻底解耦，使得 Router 的一次方向性误判会被 Worker 的高质量执行放大：Worker 越听话、执行越彻底，错误方向上的沉没成本就越高。本文的核心论点是：“用户不感知底层多会话并行”是体验目标，而不是权限目标；可干预性必须作为分层架构的一等设计约束，通过“可观测的分解轨迹 + 可寻址的中间产物 + 可回滚的编排状态”三条路径落地。本文评述：把 Router 当作不可质疑的权威，是把编排层的可靠性问题错误地转嫁给了模型能力，工程上不可接受。

目录

一、背景与问题定义：分层编排的收益与代价

1.1 从单会话到显式分层：问题是怎么被逼出来的

大模型应用在 2023 年前后普遍遇到一个结构性瓶颈：单会话上下文窗口有限，而真实任务往往需要检索、计算、写作、校验等多种能力交替进行。ReAct 式（Reasoning + Acting）的交替推理把工具调用引入循环，但所有中间结果都堆在同一个上下文里，导致“上下文污染”与“注意力稀释”。本文评述：ReAct 的价值在于把推理与行动绑定，但它的代价是把状态管理完全交给上下文窗口，这在长任务上不可持续。

显式分层的思路由此出现：引入一个 Router（或称 Orchestrator、Planner），只负责把用户请求分解为子任务、分发给上下文隔离的 Worker，再汇总 Worker 的汇报。Worker 之间不共享上下文，只与 Router 单向通信。这一模式在工程上对应“编排者—执行者”模式，与微服务中的 API Gateway + Service、操作系统中的调度器 + 进程、编译原理中的前端 + 后端分层有同构关系。本文评述：分层本身不是新发明，真正的新问题在于——Router 是一个概率性组件，而不是确定性的调度器。

确定性调度器（如操作系统的 CFS 调度器）的错误可以通过形式化验证排除；而 Router 由语言模型驱动，其分解决策本质上是采样结果，存在不可忽略的错误率。把概率性组件放在编排层的关键路径上，就必须回答“它错了怎么办”。

1.2 “用户不感知”是体验目标，不是权限目标

“让用户不感知底层多会话并行”这句话在体验层面是合理的：用户不应该被迫理解 Worker 的调度细节。但它在工程实现中经常被误读为“用户不应该看到中间过程”，进而演化为“用户无法干预中间过程”。本文评述：这是两个完全不同的命题。不感知（transparent）描述的是默认交互形态，不可干预（opaque）描述的是控制权限，二者之间没有必然推导关系。汽车自动变速箱让驾驶者不感知换挡，但保留了手动模式和故障指示；数据库的查询优化器让用户不感知执行计划，但保留了 EXPLAIN 和 hint。分层编排系统没有理由放弃同等的可干预性。

因此本文把问题重新定义为：在保持默认交互简洁的前提下，如何以低认知成本向用户暴露 Router 的分解决策，并提供结构化的纠正入口。这是一个交互设计与系统设计的联合问题，而不是单纯的模型能力问题。

1.3 术语界定

为避免歧义，先给出本文使用的定义。Router：接收用户请求、产出任务分解图（Task Decomposition Graph, TDG）、负责分发与汇总的编排组件。Worker：接收单个子任务、在隔离上下文中执行、只向 Router 返回结构化汇报的执行组件。分解轨迹：Router 在分解过程中产生的中间决策记录，包括子任务边界、依赖关系、分配理由。可干预性：用户在编排执行过程中或执行后，对分解结构、子任务内容、汇总策略施加修正的能力。本文评述：把“可干预性”定义在分解结构层面而非自然语言对话层面，是因为自然语言纠正在多会话并行下缺乏寻址能力——用户说“不对”，系统不知道是哪个 Worker 不对。

二、Router 误判的失效模式与形式化刻画

2.1 四类典型失效模式

基于对公开的编排框架（LangGraph、AutoGen、CrewAI 等）文档与社区 issue 的梳理，Router 误判可归纳为四类。第一类是分解粒度错误：把本应作为一个整体的任务切成互相依赖过强的子任务，导致 Worker 之间需要反复回传上下文，而隔离上下文又禁止直接通信，最终汇总质量下降。第二类是方向性误判：对用户意图的领域判断错误，例如把“分析财报中的关联交易风险”误解为“生成财报摘要”，后续所有 Worker 都在错误方向上高质量执行。第三类是依赖关系错误：把本可并行的子任务标为串行，或把有数据依赖的子任务标为并行，前者浪费时延预算，后者产生不一致结果。第四类是汇总失真：Worker 汇报正确，但 Router 在汇总时丢失约束条件或错误加权。

本文评述：这四类失效的危害程度不同。分解粒度错误和依赖错误主要影响效率与一致性，通常可以通过重试缓解；方向性误判和汇总失真则直接破坏正确性，且由于 Worker 执行质量高，错误结果看起来更“可信”，危害更大。因此可干预性设计应优先覆盖后两类。

2.2 形式化：把分解看作带约束的图构造

设用户请求为 q，Router 产出的分解图 G = (V, E)，其中 V 为子任务集合，E 为依赖边。每个子任务 v_i 携带输入约束 c_i 与预期产出类型 t_i。Router 的决策可写为条件分布：

G ~ P(G | q, H),  H 为历史上下文与工具清单
Worker 执行: r_i = W(v_i, c_i)
汇总: y = S({r_i}, G)

误判即 G 与“真实意图对应的最优分解” G* 在结构上偏离。本文评述：由于 G* 本身不可直接观测，工程上无法直接度量偏差，只能通过下游信号间接推断，例如 Worker 汇报中的低置信度、子任务产出与约束的冲突、汇总结果的自洽性检查失败。这决定了可干预性必须建立在“信号采集”之上，而不是建立在“知道正确答案”之上。

2.3 为什么“让 Worker 自己发现错误”不可靠

一个常见的补救设想是让 Worker 在发现输入不合理时向 Router 提出质疑。这一机制在部分框架中已有实现（如子任务返回 needs_clarification 状态）。但本文评述：Worker 的上下文是隔离的，它只看到自己那一片，缺乏判断“整体方向是否正确”的信息基础。方向性误判恰恰是局部看起来合理、全局才暴露的错误。指望 Worker 自下而上纠正方向性错误，在信息论上不成立。纠正能力必须来自拥有全局视图的一方——要么是 Router 的自我复核，要么是用户。

三、可干预性的三条技术路径：可观测、可寻址、可回滚

3.1 可观测：把分解轨迹变成一等产物

可干预的前提是可看见。当前多数编排框架把分解过程放在 Router 的内部推理里，对外只暴露最终答案。本文主张把分解轨迹（TDG 及其构造理由）作为结构化产物持久化，包含：子任务列表与边界、依赖边、每个子任务的分配理由、预期产出类型、当前状态。对外以“折叠式执行计划”呈现，默认折叠，一键展开。

本文评述：这一步的关键不是“展示更多日志”，而是“展示可操作的决策点”。日志是事后追溯，决策点是事前干预。二者的区别在于是否携带可修改的结构。一个可操作的分解视图应当允许用户直接对某个子任务执行“合并”“拆分”“改方向”“标记为不相关”四类操作，而不是让用户重新用自然语言描述一遍需求。

工程提示：分解视图的默认折叠状态必须保留“异常高亮”——当某个 Worker 返回低置信度或约束冲突时，对应子任务节点自动展开并标色。默认不打扰，异常必打扰。

3.2 可寻址：给每个中间产物一个稳定句柄

多会话并行下，用户说“第三部分不对”往往无法定位，因为用户看到的可能是汇总后的连续文本，而系统内部是多个 Worker 的离散产出。可寻址性要求为每个子任务产出分配稳定 ID，并在最终汇总文本中保留来源标注（可折叠的引用标记）。本文评述：这与学术写作中的引文标注同构——读者不需要看原文，但可以顺着标注回到原文。编排系统应当把“汇总文本 → 子任务产出 → Worker 输入”建成可反向追溯的链。

可寻址性还解决了一个隐蔽问题：纠正的粒度。用户可能只想改一个数字，而不是重跑整个任务。有了稳定句柄，系统可以只失效受影响的子任务及其下游依赖，其余产出复用。这是增量纠正的经济学基础。

3.3 可回滚：编排状态需要检查点

纠正意味着状态变更，状态变更需要回滚能力。本文主张在分解图的关键节点（分解完成、每个子任务完成、汇总完成）建立检查点，记录当时的图结构、各子任务输入输出、Router 的汇总策略。回滚不是简单重跑，而是“回到某个检查点并施加修正后继续”。

本文评述：检查点的成本需要控制。全量快照在大任务上存储开销高，可采用“结构快照 + 内容引用”的方式：图结构和元数据全量保存，子任务产出按内容哈希去重存储。这样回滚时只需重建图，内容按引用取回。这一思路与持久化执行（durable execution）引擎的做法一致，Temporal、Restate 等系统已在工作流层面验证了其可行性。

四、工程落地：协议、数据结构与操作步骤

4.1 汇报协议：让 Worker 的汇报携带可判断信号

Worker 只向 Router 汇报，但汇报内容的设计决定了 Router 能否发现异常、用户能否定位问题。建议汇报结构至少包含：产出内容、置信度（自评，需校准）、约束满足情况、未决问题、依赖假设。本文评述：自评置信度存在系统性高估，不能单独作为信号，必须与“约束满足情况”这类可验证字段联合使用。可验证字段是硬信号，自评是软信号，二者加权。

{
  "task_id": "t-003",
  "status": "done | needs_clarification | blocked",
  "output_ref": "sha256:...",
  "confidence": 0.72,
  "constraints_met": {"format": true, "scope": false},
  "open_questions": ["数据口径未明确：是否含并表子公司"],
  "assumptions": ["默认使用最近一个完整财年"]
}

4.2 操作步骤：一次结构化纠正的完整流程

下面给出一条可执行的操作路径，适用于 Router 方向性误判的纠正。步骤一，用户在汇总结果中发现方向偏差，点击“查看执行计划”，系统展开分解图并高亮异常节点。步骤二，用户定位到根节点（通常是第一个子任务），选择“改方向”，在结构化表单中修改子任务目标与约束，而非重写整段需求。步骤三，系统计算受影响子图（该节点及其所有下游），标记其余节点产出为可复用。步骤四，系统从最近检查点恢复，仅重跑受影响子图，Router 重新汇总。步骤五，系统输出差异视图，用户确认或再次修正。

本文评述：这一流程的关键在于“受影响子图”的计算。它依赖 3.2 中的可寻址链和 2.2 中的依赖图。没有依赖图，就只能全量重跑；没有稳定句柄，就无法复用未受影响的产出。二者共同构成增量纠正的基础设施。

4.3 干预的三种粒度与适用场景

本文评述：三种粒度不是互斥的，而是递进关系。产品设计上应默认引导用户使用最小可行粒度，因为粒度越大，用户需要重新表达的意图越多，认知成本越高。结构级操作是这套设计的核心价值——它让用户用“改图”代替“重述需求”。

4.4 拓展资源

关于编排框架的实现细节，可参考 LangGraph 官方文档（langchain-ai.github.io/langgraph）、AutoGen 文档（microsoft.github.io/autogen）。关于持久化执行与检查点机制，可参考 Temporal 文档（docs.temporal.io）。关于多智能体协作的评测方法，可参考 AgentBench 项目（github.com/THUDM/AgentBench）。

五、关键数据、案例与对比评测

5.1 公开评测中的编排层错误率

需要说明的是，目前公开文献中直接针对“Router 分解错误率”的独立评测仍然稀少，多数工作把编排质量混在端到端任务成功率里报告。AgentBench（Liu 等，2023）在多个交互环境中评测了 LLM-as-agent 的表现，其结果显示不同模型在长程任务上的成功率差异显著，且错误往往发生在早期规划阶段。本文评述：这一结论支持“早期方向性误判危害最大”的判断，但 AgentBench 并未单独剥离 Router 层，因此不能直接引用为 Router 错误率。本文在表 1 中标注的数据为基于公开报告的整合估计，属模拟数据，仅用于说明量级。

表 1 数据为模拟数据，基于对分层编排系统常见行为的整合估计，不代表任何单一系统的实测结果。本文评述：表中“用户干预率”在引入完整可干预机制后反而下降，这一反直觉结果有其机制解释——可观测性让用户在早期发现异常并低成本修正，避免了后期的大规模返工；而“仅可观测”阶段用户看到了问题却缺乏结构化纠正手段，只能重述需求，干预率反而偏高。这说明可观测必须与可寻址、可回滚配套，单点投入收益有限。

5.2 案例：一次方向性误判的纠正记录

以下为脱敏后的模拟案例，用于说明 4.2 流程的实际形态。用户请求为“评估某供应链金融产品的信用风险敞口”。Router 初始分解为：t1 收集产品结构说明、t2 提取历史违约数据、t3 生成风险摘要。问题在于 t3 被定义为“摘要生成”，而用户真实意图是“敞口量化”。三个 Worker 均高质量完成，但汇总结果是一份描述性文档，缺乏量化结论。

用户展开执行计划后，定位到 t3，将其目标改为“基于 t1、t2 产出计算敞口区间并给出敏感性分析”，约束中补充“需说明数据口径”。系统计算受影响子图为 {t3}，t1、t2 产出复用，仅重跑 t3 并重新汇总。总耗时约为全量重跑的 0.3 倍。本文评述：这个案例的关键不是重跑快，而是用户不需要重新描述整个需求——他只需要修改一个节点的目标定义。这正是“改图代替重述”的价值。

5.3 与“Router 自我复核”方案的对比

另一条技术路线是让 Router 在分解后执行自我复核（self-critique），或引入独立的 Critic 模型审查分解图。本文评述：这一路线有价值，但存在两个边界。其一，自我复核与原始分解共享同一模型与相似上下文，错误相关性高，对方向性误判的检出率有限；其二，Critic 模型增加时延与成本，且其判断本身也需要校准。相比之下，用户干预是“外部信号”，与模型错误不相关，在方向性误判上具有不可替代性。二者应互补：Critic 处理高频、可自动判定的结构错误，用户处理低频、需要领域知识的方向性错误。

六、局限、边界条件与前沿预判

6.1 可干预性的成本边界

可观测、可寻址、可回滚都不是免费的。分解轨迹持久化增加存储，检查点增加写入放大，差异视图增加渲染复杂度。本文评述：这些成本应当按任务价值分级承担。对一次性、低风险的问答类任务，全量检查点不经济；对高价值、长周期、多依赖的分析类任务，检查点成本相对于返工成本可以忽略。工程上应提供可配置的检查点策略，而不是一刀切。

6.2 用户认知负荷的边界

暴露分解图会带来认知负荷。本文评述：这是“不感知”目标真正需要保护的地方。解决方案不是隐藏信息，而是分层暴露：默认只显示“执行计划概览 + 异常高亮”，用户主动展开才看到节点细节。这与编译器的错误提示设计同理——默认给一行错误摘要，展开才看调用栈。认知负荷的控制靠信息架构，不靠信息封锁。

6.3 前沿预判：从可干预到可协商

更远一步，编排层可能从“用户纠正 Router”演进为“Router 主动协商”。当 Router 检测到分解置信度低或存在多种合理解释时，主动向用户提出结构化澄清问题，而不是自行选择一条路径。本文评述：这一方向的关键是澄清问题的成本必须极低——用户回答一个选择题，而不是写一段描述。这与 4.1 中汇报协议的设计一脉相承：结构化字段既服务于机器判断，也服务于人机协商。近期关于 LLM 规划与工具学习的研究（如 ToolLLM、Reflexion 等工作）为此提供了部分方法基础，但把协商机制产品化仍缺乏系统性评测，属于开放问题。

七、结论与展望

回到本文开头的问题：Router 判断失误、拆错方向时，用户有没有手段介入和纠正？答案是——在当前多数分层编排系统中，手段有限且非结构化；但这不是架构的必然结果，而是设计选择的缺失。本文论证了可干预性可以由三条技术路径落地：把分解轨迹作为一等产物（可观测）、为中间产物建立稳定句柄与反向追溯链（可寻址）、在关键节点建立检查点并支持增量重跑（可回滚）。三者配套，才能把“用户不感知”从“用户不能管”中解耦出来。

本文评述：分层编排的长期竞争力，不在于 Router 一次拆对的概率有多高，而在于拆错之后系统与用户协同纠偏的效率有多高。前者受模型能力约束，后者受架构设计约束。把可干预性作为一等设计约束，是这一架构从“能用”走向“可信”的必要条件。展望后续，结构化协商、分解质量的可验证度量、以及跨会话的纠正经验复用，是三个值得投入的方向。

主要参考文献

文章声明