subagent独立上下文但不继承父会话历史，subagent_fork带父会话记忆，workflow并行执行固定结构任务，ralph每轮换新Agent防止钻牛角尖——四个内置多Agent工具的选择本身就构成一个认知负担，一个只想“让几个Agent同时干活”的用户，到底该按什么信号来判断该用哪一个，选错了的代价又是什么？

以“上下文契约”为主线，拆解多Agent编排工具的选型信号、误选代价与工程路径

摘要与阅读导引

多Agent编排工具的设计初衷是降低并行工作的门槛，但当一个系统同时内置 subagent、subagent_fork、workflow、ralph 四个语义相近、边界模糊的工具时，选择行为本身反而成了新的认知负担。本文不打算做一份“功能对照表”式的使用手册，而是试图回答一个更根本的问题：这四个工具真正的差异变量是什么？笔者认为，答案不在“并行度”或“任务类型”这类表层标签上，而在上下文契约（context contract）——即子Agent与父会话之间关于“记忆如何传递、结构如何约束、迭代如何终止”的一组隐式约定。理解这组契约，选型就从“猜”变成了“判”。

全文围绕三条主线展开：其一，建立上下文契约的三维模型（记忆继承度、结构约束度、迭代重置度），并据此推导出可操作的选型决策树；其二，逐一剖析四个工具在该模型中的坐标位置、适用信号与典型误用模式；其三，量化误选代价——包括token成本、上下文污染、结果不可复现性三类可观测损失，并给出工程上的兜底策略。文末讨论多Agent编排从“工具选择”走向“契约声明”的演进趋势。

目录

一、问题的提出：当“并行”成为一种负担

1.1 认知负担的来源不是工具太多，而是差异不可见

在单Agent时代，用户的心智模型很简单：给一个任务，拿一个结果。多Agent工具引入后，用户需要额外回答三个问题——要不要拆、怎么拆、拆完怎么合。这本是编排系统应当替用户承担的决策，但当系统把四个语义相近的工具同时暴露给用户时，决策责任被下放回了用户侧。更麻烦的是，这四个工具的名称并不能直接映射到它们的真实差异上：subagent 和 subagent_fork 都叫“子Agent”，差别藏在“是否继承父会话历史”这一行文档里；workflow 和 ralph 都涉及“多轮”，差别藏在“结构是否固定”与“每轮是否换人”这两个实现细节里。

笔者认为，这种“名称同质、差异隐蔽”的设计，本质上把工具选择变成了一次信息不对称下的决策。用户看到的是一组并列选项，实际面对的却是一组正交维度上的不同取值。不理解维度，就只能靠试错；而试错的成本，在多Agent场景下被显著放大——每一次误选都可能意味着一次完整的上下文重建、一轮无效的token消耗，甚至一次不可复现的结果偏差。

1.2 一个被忽视的事实：四个工具解决的是不同层次的问题

如果把这四个工具放进软件工程的类比框架里，会发现它们其实不在同一个抽象层次上。subagent 与 subagent_fork 解决的是“隔离与共享”的问题——子任务要不要看到父任务的上下文；workflow 解决的是“结构与调度”的问题——多个子任务之间是固定流水线还是动态依赖；ralph 解决的是“收敛与逃逸”的问题——当一个Agent陷入局部最优时，如何强制它跳出。三者分别对应上下文、拓扑、动力学三个层面，把它们并列成“四个选项”，本身就是一种抽象层次的混淆。

本文评述：把不同抽象层次的工具并列，是API设计中的常见陷阱。它降低了单个工具的上手门槛，却抬高了工具组合的认知门槛。真正友好的编排接口，应当先让用户声明“我要什么契约”，再由系统映射到具体工具，而不是让用户自己去猜。

二、分析主线：上下文契约的三维模型

2.1 什么是上下文契约

本文把“上下文契约”定义为：父会话与子Agent之间，关于信息传递、执行约束与生命周期的一组约定。它不是某个具体API参数，而是用户在使用工具时对“子Agent会看到什么、会被什么限制、会在何时结束”的预期集合。契约一旦错配，用户对结果的预期就会系统性偏离实际行为——这正是误选代价的根源。

借鉴分布式系统中“一致性模型”的分类思路（Tanenbaum & van Steen, 分布式系统原理与范型），笔者认为上下文契约可以从三个正交维度刻画：记忆继承度（子Agent能看到多少父会话信息）、结构约束度（子Agent的执行路径被预先规定到什么程度）、迭代重置度（多轮执行中，Agent实例是否被替换）。这三个维度共同构成一个三维坐标系，四个工具分别是该坐标系中的四个点。

2.2 三维模型的定义与取值

需要强调的是，这三个维度并非完全独立。记忆继承度高的工具，往往迭代重置度低（因为继承本身依赖实例延续）；结构约束度高的工具，往往记忆继承度低（因为固定结构倾向于用显式接口而非隐式历史来传递信息）。这种相关性意味着，用户在选型时只需抓住一到两个主导维度，就能大幅缩小候选集。

2.3 为什么用“契约”而不是“功能”作为主线

功能视角的对照表有一个致命缺陷：它描述的是工具“能做什么”，而用户真正需要判断的是“做了之后我会得到什么、失去什么”。契约视角把关注点从能力清单转移到预期管理上。举例来说，subagent 与 subagent_fork 在“能否并行”这一功能上是等价的，但在“子Agent是否知道父会话里已经排除过的方案”这一契约上是相反的。前者可能导致子Agent重复父会话已经否决的路径，后者则可能让子Agent被父会话的偏见锚定。功能表看不出这层差异，契约模型可以。

笔者认为，多Agent工具文档最该写清楚的，不是“这个工具能并行几个任务”，而是“这个工具会让子Agent继承什么、忽略什么、遗忘什么”。前者是性能参数，后者才是决策依据。

三、四个工具的契约坐标与适用信号

3.1 subagent：低继承、低约束、低重置的“干净隔离”

subagent 的核心契约是上下文隔离：子Agent拥有独立的上下文窗口，不继承父会话的历史消息，只接收调用时显式传入的任务描述。这意味着父会话中已经讨论过的背景、已排除的方案、已确认的约束，除非被写进任务描述，否则子Agent一概不知。它的结构约束度低（子Agent可自由规划），迭代重置度也低（同一子Agent实例在其生命周期内持续累积）。

适用信号非常明确：当子任务可以脱离父会话语境独立完成，且你希望避免父会话的偏见污染子任务判断时，选 subagent。典型场景包括：让一个子Agent独立审查一段代码而不告诉它“这段代码是谁写的、为什么这么写”；让一个子Agent从零开始做文献检索而不受父会话已有结论的引导。反之，如果子任务强依赖父会话中未显式记录的信息，subagent 会造成信息断层。

一个常见的误用是：用户把 subagent 当作“省token的手段”，期望它因为不继承历史而更便宜。这个预期部分正确，但代价是子Agent可能重复父会话已经做过的工作。笔者认为，subagent 的经济性应这样评估：省下的继承token，是否小于重复劳动带来的新增token。当父会话历史很长、而子任务又高度依赖该历史时，subagent 反而更贵。

3.2 subagent_fork：高继承、低约束、低重置的“记忆延续”

subagent_fork 与 subagent 的唯一实质差异在于记忆继承度：fork 出的子Agent完整继承父会话的历史，在此基础上继续工作。这带来两个直接后果。正面后果是子Agent无需重复父会话已建立的事实基础，可以直接在已有结论上推进；负面后果是父会话中的错误假设、已否决但未明确记录的方案、甚至语气偏好，都会被一并继承，形成“锚定效应”。

适用信号是：子任务必须在父会话已建立的事实基础上推进，且这些事实难以用一段任务描述完整复述。典型场景包括：父会话已经完成了需求澄清，现在要 fork 出多个子Agent分别实现不同模块；父会话已经完成了一轮分析，现在要 fork 出子Agent做交叉验证。此时若用 subagent，用户需要把父会话的结论手工摘要成任务描述，既费时又容易遗漏。

本文评述：fork 的“继承”是一把双刃剑。工程上更稳妥的做法是“选择性继承”——只继承事实性消息，过滤掉探索性、否定性的中间过程。但当前多数实现只提供全量继承或零继承两个极端，这本身就是一个值得改进的设计空间。

3.3 workflow：低继承、高约束、低重置的“固定流水线”

workflow 的核心契约是结构先行：多个子任务之间的依赖关系、执行顺序、数据传递接口，都在执行前以固定结构（通常是DAG或有向流水线）声明。每个节点是一个相对独立的执行单元，节点之间通过显式声明的输入输出传递数据，而非隐式共享上下文。因此它的记忆继承度低（节点间不共享历史），结构约束度高（路径预先规定），迭代重置度取决于节点实现，通常为低。

适用信号是：任务可以被分解为若干边界清晰、接口明确的阶段，且阶段间的依赖关系在执行前即可确定。典型场景包括：文档处理流水线（抽取→清洗→结构化→校验）、代码生成流水线（需求解析→接口设计→实现→测试生成）、数据分析流水线（加载→变换→聚合→报告）。workflow 的最大优势是可预测性与可复现性——同样的输入，走同样的路径，得到结构一致的结果。

workflow 的局限同样明显：它对“执行中才发现的新依赖”不友好。如果第二阶段的结果暴露出第一阶段遗漏了某个输入，固定结构无法动态插入新节点，用户只能回退重跑。笔者认为，workflow 的适用边界可以用一句话概括：当你能在动手前画出完整的流程图时，用 workflow；当你画不出来时，别硬画。

3.4 ralph：低继承、低约束、高重置的“强制逃逸”

ralph 的核心契约是每轮换新：多轮迭代中，每一轮都新建一个Agent实例，上一轮的上下文不传递给下一轮，只传递上一轮的产出结果（或对结果的评价）。这一设计的动机是打破“钻牛角尖”——当同一个Agent实例在连续多轮中反复沿着同一条错误路径推进时，它的上下文已经被错误假设污染，越走越偏。换新实例相当于强制清零，让新一轮从结果而非过程出发重新判断。

适用信号是：任务需要多轮迭代，且存在“局部最优陷阱”风险。典型场景包括：开放式创意生成（每轮换人避免风格固化）、对抗性审查（每轮换审查者避免形成固定偏见）、长程调试（每轮换调试者避免被错误假设锚定）。ralph 的代价是每轮都损失了上一轮的推理过程，只保留结果，因此不适合那些“推理链条本身就是资产”的任务。

笔者认为，ralph 的价值常被低估。在多数多Agent系统中，最大的浪费不是并行度不够，而是同一个Agent在错误方向上反复投入。ralph 用“重置”换“逃逸”，是一种典型的以空间换方向的策略，其收益在开放式任务上尤为显著。

3.5 四工具契约坐标总览

这张表的价值不在于“记住四个组合”，而在于提供了一个反查机制：当你面对一个任务时，先问自己三个问题——子任务需要父会话的历史吗？执行路径能预先画出来吗？多轮迭代有钻牛角尖的风险吗？三个答案分别对应三个维度的高低，组合起来就能定位到工具。这比“凭感觉选”可靠得多。

四、选型决策树：从信号到工具的映射

4.1 三个前置问题

在进入决策树之前，用户需要先回答三个前置问题，它们对应三维模型的主导维度。第一个问题：子任务是否需要父会话中未显式记录的信息？如果答案是“是”，记忆继承度必须高，候选集收缩为 subagent_fork；如果“否”，则排除 fork。第二个问题：执行路径能否在执行前完整画出？如果能，结构约束度应高，候选集指向 workflow；如果不能，排除 workflow。第三个问题：多轮迭代是否存在钻牛角尖风险？如果存在，迭代重置度应高，指向 ralph；如果不存在，指向 subagent。

这三个问题之所以有效，是因为它们分别对应了三个维度上“高取值”的触发条件。用户不需要理解维度的抽象定义，只需要对具体场景做是非判断。笔者认为，这种“问题驱动”的选型方式，比“工具驱动”的对照表更符合人的认知习惯——人擅长回答具体问题，不擅长在多个并列选项中做全局比较。

4.2 决策树的具体形态

Q1: 子任务需要父会话历史中未显式记录的信息吗？
├─ 是 → subagent_fork（记忆延续）
│        └─ 追问：多轮迭代有钻牛角尖风险吗？
│             ├─ 是 → 考虑 fork + ralph 组合（每轮 fork 新实例）
│             └─ 否 → 纯 subagent_fork
└─ 否 → Q2: 执行路径能在执行前完整画出吗？
         ├─ 是 → workflow（结构先行）
         │        └─ 追问：节点间需要共享隐式上下文吗？
         │             ├─ 是 → 重新评估，可能不适合 workflow
         │             └─ 否 → 纯 workflow
         └─ 否 → Q3: 多轮迭代有钻牛角尖风险吗？
                  ├─ 是 → ralph（每轮换新）
                  └─ 否 → subagent（干净隔离）

这棵决策树有一个隐含假设：用户对任务的性质有足够清晰的判断。现实中，很多任务的边界是模糊的——用户既不确定子任务是否需要父会话历史，也不确定路径能否预先画出。这种情况下，笔者的建议是从最保守的选项开始：先用 subagent 跑一轮，观察子Agent是否因为缺少上下文而重复劳动；如果重复严重，升级到 fork；如果发现路径可以固化，迁移到 workflow；如果发现多轮迭代在原地打转，引入 ralph。这种“渐进式升级”比一次性选对更现实，因为选型本身也是一个需要反馈的决策过程。

4.3 组合使用的边界

四个工具并非互斥，组合使用在多类场景中是必要的。例如“fork + ralph”组合：每轮 fork 出新的子Agent，既继承父会话的事实基础，又避免单实例的累积偏见。再如“workflow 内嵌 subagent”：workflow 负责阶段调度，每个节点内部用 subagent 做独立处理，兼顾结构可预测性与节点内隔离。但组合也带来新的复杂度——契约叠加后，用户更难预测最终行为。笔者认为，组合使用的前提是每一层的契约都能被单独验证：先验证 workflow 的调度逻辑，再验证节点内 subagent 的隔离效果，最后验证两者叠加后的整体行为。跳过单层验证直接上组合，是误选代价被放大的常见原因。

本文评述：组合使用的本质是契约的嵌套。嵌套层数越多，行为越难预测，调试成本越高。工程上应遵循“最小嵌套原则”——能用单层解决的，不叠加第二层；必须叠加时，为每一层保留独立的可观测指标。

五、误选的代价：三类可观测损失

5.1 token成本损失：可量化但常被低估

误选最直接的代价是token消耗。以“本应使用 fork 却误用 subagent”为例：子Agent因缺少父会话历史，需要重新建立事实基础，这部分重复劳动消耗的token，往往超过 fork 继承历史所消耗的token。反过来，“本应使用 subagent 却误用 fork”时，子Agent继承了大量与当前子任务无关的历史，这些历史在每次推理中都被重复编码，形成持续的token开销。

需要说明的是，具体的token倍率高度依赖任务形态与上下文长度，本文不给出虚构的量化数字。工程上可行的评估方法是：对同一任务分别用两种工具跑一次，记录输入token与输出token，计算差值。这种A/B测量虽然朴素，但比任何理论估算都可靠。笔者建议把这种测量固化为团队的工具选型流程——选型不靠猜，靠测。

5.2 上下文污染损失：隐蔽且难以回溯

比token更隐蔽的代价是上下文污染。fork 的继承机制会把父会话中的错误假设、已否决方案、甚至语气偏好一并传给子Agent。子Agent在这些“污染”基础上推理，可能得出看似合理实则偏离的结论。更麻烦的是，这种偏离往往在结果层面才暴露，而结果已经经过了多轮加工，回溯到“污染源”的成本很高。

上下文污染的另一个来源是 workflow 的接口设计不当。如果节点间通过隐式的全局状态传递数据，而非显式声明的输入输出，那么上游节点的中间产物会以非预期方式影响下游节点。这类问题在固定结构中尤其难排查，因为结构本身“看起来”是清晰的，污染藏在接口的实现细节里。笔者认为，workflow 设计的一条硬规则是：节点间只通过显式声明的接口传递数据，禁止共享隐式状态。这条规则牺牲了一点灵活性，换来的是可排查性。

5.3 结果不可复现损失：对工程可信度的侵蚀

第三类代价是结果不可复现。ralph 的每轮换新机制，虽然能有效逃逸局部最优，但也引入了随机性——每轮新实例的推理路径不同，最终结果可能因轮次顺序、实例初始化差异而变化。对于需要可复现结果的场景（如合规审查、基准测试），这种随机性是不可接受的。误用 ralph 的典型表现是：用户为了“提高质量”引入多轮换新，结果发现同一输入两次运行得到不同结论，无法向利益相关方解释。

不可复现的代价在工程上被严重低估。它不只是“结果不一样”，而是整个系统的可信度被侵蚀——当用户无法预测系统行为时，他们会倾向于不用系统，或者用更保守的方式使用系统，从而抵消了多Agent带来的效率增益。笔者认为，可复现性应当作为多Agent编排的一等公民指标，与质量、成本并列。对于必须可复现的场景，ralph 应被限制在“探索阶段”使用，最终产出阶段切换到确定性更高的工具。

5.4 三类损失的权衡关系

这张表揭示了一个规律：越隐蔽的损失，越需要前置的兜底策略。token损失可以直接计量，事后切换即可；上下文污染和不可复现性则需要在设计阶段就埋好观测点。笔者认为，多Agent系统的成熟度，很大程度上体现在“是否为每类损失都准备了可观测指标”——没有观测，就没有纠错。

六、工程实践：契约声明与兜底策略

6.1 把契约显式化：从“选工具”到“声明契约”

工程上降低选型负担的最有效手段，是把隐式契约显式化。具体做法是：在调用任何多Agent工具之前，先用一段结构化声明描述本次任务的三维取值，再由一个薄封装层把声明映射到具体工具。这样，用户面对的不再是四个并列选项，而是三个需要填写的维度。封装层的伪代码如下：

# 契约声明示例（伪代码，非特定框架API）
contract = {
    "memory_inherit": "none" | "full" | "summary",  # 记忆继承度
    "structure":      "free" | "dag",               # 结构约束度
    "reset":          "never" | "per_round",        # 迭代重置度
}

def dispatch(contract, task):
    if contract.memory_inherit == "full":
        return subagent_fork(task)
    if contract.structure == "dag":
        return workflow(task)
    if contract.reset == "per_round":
        return ralph(task)
    return subagent(task)

这段代码的关键不在实现，而在把选择逻辑从用户脑中转移到代码里。用户只需回答三个语义化的问题，映射规则由团队统一维护。当工具新增或语义调整时，只需改映射层，用户侧无感。笔者认为，这是多Agent编排从“手工艺”走向“工程化”的必经一步。

6.2 兜底策略：为每类损失准备观测点

兜底策略的核心是“可观测”。针对token损失，最直接的做法是记录每次调用的输入输出token数，按工具类型聚合，形成基线；当某次调用的token显著偏离基线时告警。针对上下文污染，可行的做法是让子Agent在输出中显式标注“哪些结论依赖父会话继承的信息”，便于人工抽查。针对不可复现性，做法是固定随机种子（若工具支持）或对关键路径做多次运行取交集。

这些观测点的搭建成本不高，但收益显著。笔者在实践中观察到，多数多Agent系统的“玄学问题”，根源都是缺少观测——用户感觉“结果不对”，但说不出哪里不对，因为没有任何中间指标可供对照。把观测点补齐，很多问题会从“玄学”变成“工程问题”，可定位、可修复。

6.3 一个可操作的落地步骤

把上述思路落地，可以按以下步骤推进。第一步，梳理团队近期的多Agent使用记录，按三维模型给每次使用打标签，统计各工具的误用率；第二步，针对误用率最高的组合，设计A/B测量，量化token损失与质量差异；第三步，编写契约声明封装层，把选型逻辑固化；第四步，为三类损失各设一个观测指标，接入现有监控；第五步，定期复盘，根据观测数据调整映射规则。这五步不需要一次性完成，可以从误用率最高的场景切入，逐步扩展。

对于想进一步深入多Agent编排的读者，可以参考以下拓展资源：Anthropic 的 多Agent系统研究页面、LangChain 的 LangGraph 编排文档、以及 Microsoft 的 AutoGen 多Agent框架教程。这些资源分别从研究、编排、框架三个角度提供了可操作的参考，建议结合本文的契约模型对照阅读。

七、前沿预判：从工具选择到契约编排

7.1 编排接口的演进方向

从近两年的框架演进看，多Agent编排接口正在经历一次范式迁移：从“暴露工具”转向“声明意图”。早期的框架倾向于把底层能力直接暴露给用户，让用户自己组合；较新的框架则倾向于让用户声明“我要什么效果”，由框架负责选择与调度。这一迁移的驱动力，正是本文讨论的认知负担——当工具数量超过用户的比较能力时，暴露工具反而降低了可用性。

笔者认为，这一迁移会沿着“契约声明”的方向深化。未来的编排接口可能不再有 subagent、fork、workflow、ralph 这样的并列选项，而是让用户填写一组契约参数（继承什么、约束什么、何时重置），由系统自动映射到最优执行策略。这种设计把选择权从“记忆工具名”转移到“理解任务性质”上，更符合用户的真实认知负荷分布。

7.2 值得关注的研究问题

围绕上下文契约，仍有若干开放问题值得研究。其一是选择性继承的粒度：当前实现多为全量或零继承，能否按消息类型（事实/假设/否定）做选择性继承？其二是契约的自动推断：能否从任务描述中自动推断三维取值，减少用户的手工声明？其三是契约组合的形式化验证：多层嵌套的契约叠加后，如何保证行为符合预期？这些问题目前尚无成熟答案，但已有一些初步探索，例如基于消息类型的上下文压缩、基于任务分类的编排策略推荐等。

需要提醒的是，这些研究方向的价值不应被高估为“替代用户判断”。至少在可预见的未来，任务性质的判断仍需人来完成，工具能做的是把判断的结果更可靠地映射到执行策略上。笔者认为，多Agent编排的终极形态不是“全自动”，而是“人机分工清晰”——人负责判断任务性质，系统负责执行契约。

八、结论

回到文章开头的问题：四个内置多Agent工具的选择为什么构成认知负担？因为它们的名称掩盖了真实差异，而真实差异藏在“上下文契约”这一未被显式表达的维度里。本文提出的三维模型（记忆继承度、结构约束度、迭代重置度）把隐式差异显式化，把“猜工具”转化为“答问题”，把选型从经验判断转化为可验证的工程流程。

选错的代价并非不可承受，但确实存在且可观测：token成本、上下文污染、结果不可复现，三类损失分别对应不同的可观测性与兜底策略。工程上的应对之道，一是把契约声明显式化，用封装层承接选型逻辑；二是为每类损失准备观测点，让问题从“玄学”变“工程”；三是遵循渐进式升级与最小嵌套原则，避免一次性押注复杂组合。

最后，笔者认为，多Agent工具的价值不在于“能并行几个”，而在于“契约是否清晰”。一个契约清晰的单工具，胜过四个契约模糊的并列选项。编排系统的设计者应当把精力从“增加工具”转向“澄清契约”，用户也应当把精力从“记住工具名”转向“理解任务性质”。当契约成为共识，选择就不再是负担。

主要参考文献