长任务Agent设计规范，让工作流真实落地

一、概述：三件事 × 三次交互

处理一个复杂任务，系统究竟需要做哪些事？答案是三件性质截然不同的事————缺一不可，且顺序无法颠倒。 这并非方法论层面的选择，而是信息论上的必然： * **理解拆解**：发生在信息不完整的阶段，目标是把模糊的用户意图转化为有向无环图（DAG）。如果这一步偷懒了，直接跳去执行，子任务的边界就会模糊不清，后续任何修复的代价都会被放大数倍。 * **分配执行**：这是一个调度问题。核心是用最少的agent来覆盖所有能力需求，同时最大化并行度。而这个阶段做得好坏，完全取决于前一步拆解的精度。 * **监控验证**：必须贯穿整个执行过程，而不是等到最终输出才来检查。一个错误如果在链路末端才发现，修复成本是在源头发现的n倍。

阶段	职责	时机	核心产物
理解与拆解	解析用户意图 → 拆解为子任务 DAG → 识别依赖关系 → 输出 agent 需求清单	事前	任务 DAG + agent 需求清单
分配与执行	匹配垂类 agent → 装填蒙版 → 并行调度 → 异常捕获	事中	执行状态流 + 中间输出
监控与验证	进度心跳 → 验证门判定 → 阻碍识别 → 置信度审查 → 回溯修复	事中	验证报告 + 合格输出

1.2 三次交互的边界

用户并不关心系统内部的调度细节，但在两个关键时刻，他们必须能介入进来：一是（交互1），二是（交互2）。剩下的时间，用户只需等待最终交付。

交互1：用户输入问题 → 系统输出工作流 + agent 清单
交互2：用户审核方案 → 调整/确认 agent 边界与编排逻辑
交互3：系统装填蒙版 → 执行 → 交付工作成果

这是用户最后一次能低成本修正系统理解偏差的机会。一旦确认，执行阶段的任何方向修正成本都会高得吓人。交互2向用户展示的是agent清单，清晰地列出每个agent的职责边界、蒙版摘要、输入/输出规格，而不是底层代码或实现细节。用户需要看得懂，并且能给出有效的反馈。 执行中发现的阻碍，优先在交互3内部通过重新规划来解决，而不是直接退回交互2。判断是否需要退回的唯一标准是：。只有在这种情况下，原有的DAG才被视为不可修复，必须由用户重新确认任务边界。

---

二、理解与拆解：DAG 构建

2.1 意图解析

用户的输入通常是自然语言，充满了歧义、隐含的前提和遗漏的条件。意图解析阶段的目标，就是把这些模糊信息转化为。 意图解析的输出包括以下几个关键部分： * ：用户最终想要什么，用一句话精炼概括。 * ：格式、时限、质量标准、禁止事项等一切限制。 * ：用户觉得是常识、没有明说，但系统又必须知道的假设。 * ：系统自己无法消解的歧义，会在交互1中直接呈现给用户。 > 用户输入：“帮我写一份竞品分析报告” 意图解析结果：

核心目标：输出一份结构化竞品分析文档
约束条件：（未指定）
隐含前提：对象是用户所在行业的竞品（待确认）
歧义点：
  - 竞品范围（国内/国际？几家？）
  - 分析维度（功能/价格/市场份额/用户口碑？）
  - 输出形式（Markdown/PPT/Word？）

在交互1中，系统会把工作流草案和这些歧义点一同呈现给用户，请用户在交互2中确认。

2.2 子任务 DAG

DAG（有向无环图）是任务拆解的标准形式。每个节点是一个子任务，边表示依赖关系——上游的输出是下游的输入。 1. ：每个节点只做一件事，输入输出类型必须清晰明确。 2. ：所有依赖关系必须画线连接，严禁任何隐式依赖。“你懂我意思就行”这种想法，是大多数错误的根源。 3. ：没有依赖关系的节点天然可以并行，DAG构建时就应该主动识别并标记出来。 4. ：第一个节点（入度为0）和最后一个节点（出度为0）必须显式标注，这是规划的地基。

错误类型	描述	示例
隐式依赖	子任务之间有实际依赖但 DAG 中未连边	摘要任务依赖全文但 DAG 中与全文节点无边
过度拆分	粒度过细，子任务之间需要大量上下文传递	每个段落独立为一个节点，导致前后文断裂
粒度不均	部分节点承载了多个独立子任务	“调研+写作”作为单一节点
环形依赖	依赖关系成环，无法排拓扑序	A 需要 B 的输出，B 需要 A 的输出

---

三、蒙版激活梯度

3.1 核心思想：为什么不是开关

直觉上，给agent设置能力范围，最直接的方式是“开关”——允许使用的知识域写进白名单，其余拒绝。这个思路在传统软件系统中再合理不过了，但在LLM agent这里，它行不通。 举个例子，一个在训练时看过大量数学文献的模型，你无法在推理时命令它“不想数学”。它的数学知识以分布式权重的形式存在于整个神经网络中，没有一个可以断开的开关。即便你用prompt强行告诉它“你不懂数学”，它可能会在回复中声称不懂，但生成的内容依然会受数学知识的潜移默化。 因此，蒙版的设计目标不是，而是做到两件事： 1. ：调节各知识域在生成中的权重。 2. ：当非主激活域的知识被调用时，必须留下记录。 把这两点结合起来，才能实现可追溯、可审计的知识边界管理。

3.2 形式化定义

假设总知识空间为 K = {k₁, k₂, ..., kₙ}，对每个agent Aⱼ 和每个知识域 kᵢ，我们定义一个蒙版激活值：

m(Aⱼ, kᵢ) ∈ [-1, 1]
m =  1 → 主激活域（核心能力区，自由调用）
m =  0 → 静默域（不主动激活，泄漏风险存在）
m = -1 → 抑制域（显式反激活，注入抑制 prompt）
m ∈ (0, 1)  → 背景域（半激活，可被动触发但需声明）
m ∈ (-1, 0) → 弱抑制域（不鼓励，不绝对禁止）

三个激活域按阈值划分：

主激活域  M_main   = { kᵢ | m(Aⱼ, kᵢ) > θ_main }
背景域    M_bg     = { kᵢ | θ_bg < m(Aⱼ, kᵢ) ≤ θ_main }
静默域    M_silent = { kᵢ | m(Aⱼ, kᵢ) ≤ θ_bg }

默认阈值：θ_main = 0.7, θ_bg = 0.3

* θ_main = 0.7：留出0.3的缓冲带，防止主激活域定义得过于狭窄，导致任务完成率下降。 * θ_bg = 0.3：低于这个值的知识域，即便被激活了，也应被视为噪声，需要强制阻断。 * 这两个阈值可以按任务类型调整，但调整必须在装填阶段完成，执行过程中禁止动态修改。

3.3 泄漏声明规则

当agent Aⱼ 在推理过程中使用了 kᵢ，且 kᵢ ∉ M_main(Aⱼ)，必须按以下规则处理：

规则1：kᵢ ∈ M_bg → 允许使用，但必须在输出中标记：[蒙版泄漏 | agent=Aⱼ | 域=kᵢ | 强度=m(Aⱼ,kᵢ)]

规则2：kᵢ ∈ M_silent → 先判断：
  a. 该知识对当前任务必要 → 不能抑制，回溯到分配层调整蒙版
  b. 该知识是模型自发激活 → 抑制 prompt 触发，阻断本轮推理

原因在于，背景域知识（M_bg）的存在本身是合理的。agent的核心能力往往需要周围知识作为支撑，彻底切断会导致生成质量严重下降。标记泄漏的目的，是让验证层知道“这段输出用了非主激活域的知识”，进而在置信度判断时给出适当的折扣，而不是直接判定为错误。

...根据该公司2023年财报（[蒙版泄漏 | agent=A3 | 域=财务分析 | 强度=0.45]），
其营收增速为18%，与行业均值持平...

3.4 双路径生成

路径1（主路径）：M_main 内封闭生成
路径2（泄漏路径）：M_main + M_bg 开放生成，标记所有泄漏

输出优先取路径1。当路径1无法完成时，启动路径2并附带泄漏报告。

* 路径1失败的判定条件：生成中止（无法产出结构完整的输出）或生成输出与任务要求的核心维度完全不匹配。 * 路径2的泄漏报告须包含：泄漏域列表、各域激活强度、泄漏总量（用以评估置信度折扣力度）。 * 路径2的输出自动进入L2标准验证，不可直接绿灯放行。

---

四、置信度判断机制（物质还原验证）

4.1 定位：生成层与验证层的分工

蒙版梯度负责——控制agent在生成内容时，知识域激活的范围。而置信度判断负责——在内容生成完毕后，审查输出的事实可靠性。 这两个机制各司其职，但会相互触发：蒙版泄漏会提高验证层的审查强度，验证层发现的问题也可能反过来要求调整蒙版。

4.2 为什么不用交叉一致性

传统多agent验证的主流方案是“交叉一致性”：让多个agent独立完成同一个任务，对比输出的一致性程度，一致性强就视为可信。 但这个方案有一个根本性的缺陷：。 三个模型完全可以同时犯同一个错误。比如，它们可能都读到了一篇被广泛引用但本身存在事实错误的文献，交叉比对的结果会高度一致，但这个结论本身却是错的。 本规范采用：把结论下沉到事实层，逐一追查每个论据的物质基础。核心问题不是“别人也这么说吗”，而是“这件事在现实世界里真的存在吗”。

4.3 四步验证流程

输入：子 agent Aⱼ 的输出结论 C

Step 1 — 论点-论据拆解
C → { (p₁, E₁), (p₂, E₂), ..., (pₙ, Eₙ) }
每个 pᵢ 是一个论点，Eᵢ = {eᵢ₁, eᵢ₂, ...} 是支撑 pᵢ 的论据集合

Step 2 — 论据分层
对每个 e ∈ Eᵢ：
  ├─ 可验证事实 → 进入物质还原
  ├─ 推理推导   → 递归拆解其依赖的事实基础
  └─ 经验判断   → 标记为 soft-claim，置信度权重折扣

Step 3 — 物质还原
对每个可验证事实 e：
  ├─ 事实存在且准确  → verified
  ├─ 事实存在但偏差  → 标记偏差度 δ(e)
  ├─ 事实不存在      → falsified → 触发不合格
  └─ 事实无法验证    → uncertain → 标记置信度折扣

Step 4 — 判定
├─ 存在任意 falsified  → 不合格
├─ 仅 uncertain + verified → 合格（置信度折扣）
└─ 全 verified → 合格（全置信度）

推理推导本身不是事实，但其有效性完全取决于前提事实是否成立。因此，我们需要递归拆解，直到最终的叶节点。这些叶节点必须是可验证事实或soft-claim，不存在纯逻辑的无穷推导链。 偏差度是一个0到1的连续值，0表示与事实完全一致，1表示与事实完全相反。偏差度不会直接触发不合格，但它会计入论点pᵢ的置信度权重，并在最终判定中影响总置信度分数。

4.4 分层触发（成本控制）

全量的物质还原成本太高，因此我们按三级触发：

L1 — 轻量验证（默认对所有输出执行）
├─ 结构化字段完整性检查（必填字段是否齐全）
├─ 输出格式合规检查（是否符合约定的输出 schema）
└─ 表面矛盾检测（同一输出内部是否存在自相矛盾）
│
├─ 通过 → 绿灯放行，不进入 L2
└─ 不通过 → 触发 L2

L2 — 标准验证（L1 不通过时触发）
├─ 论点-论据拆解（Step 1-2）
├─ 物质还原关键论据（抽样 30-50%，优先抽取支撑核心论点的论据）
│
├─ 通过 → 合格（置信度折扣标注）
└─ 不通过 → 触发 L3

L3 — 深度验证（L2 发现 falsified 时触发）
├─ 全量论据物质还原
├─ 监督 agent 介入
├─ 上游 + 下游独立 agent 介入
└─ 结果：合格 / 不合格 → 重做

这里需要强调一点，不是随机抽样，而是优先级抽样。 1. 支撑核心论点（权重最高的pᵢ）的论据优先还原。 2. 来自泄漏路径（路径2）的论据优先还原。 3. 包含强确定性断言（比如“一定”、“必然”、“从未”这些词）的论据优先还原。

4.5 三级介入机制

一旦判定为不合格（存在任意falsified），立即启动三级介入：

监督 agent（过程视角）
├─ 复盘 Aⱼ 的执行日志（每一步 prompt 输入 + 输出）
├─ 判断：违规使用了静默域知识？执行步骤跳步？指令理解偏差？
└─ 输出：故障原因分类 + 改进建议

上游 agent（输入视角）
├─ 检查 Aⱼ 收到的输入是否完整且正确（与预期输入规格对比）
├─ 判断：上游传递了错误数据？前置条件未满足？输入格式不符？
└─ 输出：输入侧问题定位 + 责任归属

下游 agent（消费视角）
├─ 检查 Aⱼ 的输出是否可被下游消费（依下游的输入规格验证）
├─ 判断：格式错误？字段缺失？语义不可解析？类型不匹配？
└─ 输出：输出侧问题定位 + 消费障碍描述

角色	自身盲区	独有可见区域
监督 agent	看不到输入/输出的语义合理性	执行过程异常、步骤跳跃、指令偏差
上游 agent	看不到 Aⱼ 的执行过程	输入空间全貌、前置条件状态、数据血缘
下游 agent	看不到 Aⱼ 的执行过程	预期消费格式、语义可解析性、下游状态

这种三角覆盖设计确保：。如果只让其中任意一个单独介入，都会有系统性的漏检风险。

4.6 重做策略

原样重跑的问题是显而易见的：如果根因没修复，再次执行只会重现同一个错误，白白浪费算力，还延误交付。

重做步骤：
1. 定位根因（监督 agent 输出）
2. 修正根因：
   ├─ 输入问题     → 修正上游输出，原 agent 重做
   ├─ 蒙版问题     → 调整激活梯度，原 agent 重做
   ├─ 能力缺口     → 更换 agent 或扩展蒙版
   └─ 过程问题     → 注入 process guard（执行约束 prompt），原 agent 重做
3. 重跑 + L2 验证（重做后的输出强制进入 L2，不得走 L1 绿灯）
4. 仍不合格 → 挂起，等待人工介入

满足以下任一条件，系统会自动挂起并通知人工介入： * 同一节点重做次数 ≥ 3 次。 * 回溯深度达到硬上限（默认 3 层）。 * L3 验证后仍判定为不合格。 * 监督 agent 判定故障原因为“任务本身不可完成”。

---

五、阻碍识别与回溯协议

5.1 阻碍分类

阻碍识别的目标是，把“出错了”这个模糊信号，转化为“哪类错、怎么修”的具体指令。四类阻碍的判定标准和修复策略完全不同，必须在识别后立刻进行分类，而不是用一套统一的重试逻辑笼统处理。

A类 — 瞬态故障（Transient）
判定标准：同一输入重跑能过（故障与输入无关）
典型场景：API 超时、模型服务不可用、并发写冲突
修复策略：原地重试，指数退避，不改变任何输入或蒙版
上限：重试 3 次后降级为 B类或 C类重新评估

B类 — 参数失配（Parametric）
判定标准：agent 能力足够，但入参或指令不匹配
典型场景：prompt 未覆盖边缘情况、上下文被截断、输入格式错误
修复策略：回溯到父节点，修正参数后重新派发（不换 agent，不动蒙版）
注意：B类和 C类的判定边界在实践中容易混淆——关键问题是“换一组正确的参数，现有 agent 能完成吗”
答案是“能” → B类；答案是“不能” → C类

C类 — 能力缺口（Capability Gap）
判定标准：当前蒙版下 agent 不具备必要能力，无论输入如何调整都无法完成
典型场景：需要数值计算但 agent 仅文本能力，需要实时数据但 agent 无工具调用权限
修复策略：回溯到分配层，换 agent 或扩展蒙版
注意：扩蒙版可能引入新的泄漏风险

D类 — 拆解错误（Decomposition Error）
判定标准：子任务划分本身有问题，不是执行层的错
典型场景：隐式依赖未写入 DAG、拆分过细导致上下文断裂、节点边界划定错误
修复策略：回溯到规划层，重新拆解 DAG
触发条件：当同一 DAG 路径的多个节点连续发生 B类或 C类阻碍时，应升级评估是否为 D类

5.2 回溯层级与回滚边界

层级      回滚范围              兄弟节点处理
────       ────────               ────────────
节点级    只回滚当前节点          不影响（独立执行）
父节点级  回滚父节点 + 所有子节点  父节点下全部失效，需重新派发
路径级    回滚整条依赖链          链上全部失效，链外保留
全局级    回滚整个 DAG            全部失效，相当于从头开始

1. ：严禁自动推断回溯范围。“我觉得回滚父节点就够了”是典型的工程陷阱——不确定时，请选择更保守（更大范围）的回溯层级。 2. ：兄弟节点能否存活，唯一的判断标准是，而不是物理位置上的远近。完全独立的兄弟节点可以存活；存在任何逻辑依赖的兄弟节点，一律随父节点回滚。 3. ：默认 3 层。达到上限必须强制挂起，等待人工介入。这个上限不是性能约束，而是系统的自我保护机制——无限递归回溯会让整个执行状态变得不可追溯。 4. ：每次回溯都必须记录完整信息：

{
  "timestamp": "2026-06-22T11:30:00Z",
  "node_id": "A3",
  "fault_type": "B",
  "rollback_level": "父节点级",
  "root_cause": "prompt 未覆盖多语言输入场景",
  "fix_action": "扩展 prompt 覆盖范围，重新派发",
  "second_run_result": "pass"
}

---

六、机制衔接

6.1 主循环

主循环是四个机制（拆解、蒙版、验证、回溯）的集成视图，描述了从一个完整任务输入到最终交付的全链路过程：

用户输入
↓
交互1：理解拆解 → 子任务 DAG + agent 清单（含蒙版摘要）
↓
交互2：用户审核 → 确认方案 / 提出修改
↓
交互3：装填蒙版 → 并行执行各节点
↓
├─ 验证门 L1
│   ├─ pass → 继续下一节点
│   └─ fail → 阻碍识别
│   ├─ A类 → 原地重试（指数退避）
│   ├─ B类 → 父节点回溯，修正参数，重新派发
│   ├─ C类 → 分配层回溯（换 agent / 扩蒙版）
│   └─ D类 → 规划层回溯（重拆 DAG，视情况退回交互2）
│
├─ 验证门 uncertain（L1 标记不确定）
│   └─ 进入 L2 标准验证
│   ├─ L2 pass → 置信度折扣标注 → 继续
│   └─ L2 fail（发现 falsified）→ 进入 L3
│     └─ L3：全量还原 + 三级介入
│     ├─ L3 合格 → 置信度折扣标注 → 继续
│     └─ L3 不合格 → 重做
│       └─ 重做仍不合格 → 挂起人工介入
↓
全节点完成 → 汇聚最终输出 → 交付用户

6.2 蒙版梯度与置信度判断的交叉

C类阻碍（能力缺口）有两条修复路径：换agent或扩蒙版。扩蒙版是成本较低的选择，但会引入新的知识域激活，潜在地产生泄漏风险。以下是完整的交叉链路：

C类阻碍触发蒙版调整
→ 将某知识域 kᵢ 从 M_silent 提升到 M_bg
→ 执行时走泄漏路径（路径2），所有 kᵢ 的使用标记泄漏声明
→ 输出强制进入 L2 标准验证
→ 若 L2/L3 发现 falsified，且根因追溯指向新引入的泄漏域 kᵢ：
   → 说明“扩蒙版修能力缺口”对当前任务不适用
   → 回退策略：不回退蒙版（已有泄漏日志），改为更换 agent
   → 记录本次失败路径，防止下次对同一类任务再次尝试扩蒙版策略

没有这条链路，系统很可能会陷入一个无限循环： 1. C类阻碍 → 扩蒙版 → 执行。 2. 扩蒙版引入新泄漏 → 验证失败 → 再次扩蒙版。 3. 无限扩展蒙版，直到所有知识域全部激活，蒙版机制形同虚设。 “失败路径记录”是防止这种无限循环的关键。系统会记住“这种修法对这类任务不管用”，下次遇到相同的场景，直接跳过扩蒙版，进入换agent的路径。

6.3 交互2 的重入边界

通常情况下，交互3内部的所有问题都应该通过回溯闭环来解决，不退回交互2。但以下几种情况例外：

触发条件	退回原因	用户需要做的事
D类阻碍 + 回溯深度已达上限	DAG 根本性错误，系统无法单方面修复	重新确认任务边界和拆解方式
人工介入后确认任务不可完成	用户预期与系统能力存在根本性落差	调整任务目标或降低质量要求
用户主动请求重新规划	用户在等待过程中发现需求变化	重新确认 agent 清单和编排逻辑

---

附录A：术语表

术语	定义
蒙版（Mask）	agent 的知识域激活配置，定义其在各知识域上的激活强度 m(Aⱼ, kᵢ)
激活梯度	m(Aⱼ, kᵢ) ∈ [-1, 1]，连续值表示 agent 在特定知识域上的激活程度
主激活域（M_main）	m > θ_main 的知识域集合，agent 可自由调用
背景域（M_bg）	θ_bg < m ≤ θ_main 的知识域集合，可被动触发但需声明
静默域（M_silent）	m ≤ θ_bg 的知识域集合，不主动激活，泄漏时需阻断
泄漏声明	agent 使用非主激活域知识时必须附加的标记，声明域和强度
物质还原	将论据追溯到客观事实并验证其存在性的过程
falsified	物质还原的否定结果：论据声称的事实不存在于现实世界
verified	物质还原的肯定结果：事实存在且准确
uncertain	物质还原的不确定结果：事实无法验证，置信度折扣处理
偏差度 δ(e)	0-1 连续值，衡量论据与事实的偏离程度
验证门	子任务输出点的自动判定机制，三分输出：pass / fail / uncertain
三级介入	不合格触发时监督 agent + 上游 agent + 下游 agent 的联合诊断
回溯	将执行状态回滚到某个安全点并修正后继续
DAG	有向无环图，子任务依赖关系的标准表示形式
process guard	注入到 prompt 中的执行约束，防止 agent 重蹈已知的过程问题

---

附录B：设计决策记录（ADR）

ADR-01：为什么不用开关式权限控制蒙版

最简单的agent能力边界控制方式，就是白名单——允许的知识域写进白名单，其余的拒绝。 改用连续激活梯度 + 泄漏声明。 LLM的知识是分布式权重，无法在推理时真正隔离。强行用prompt说“你不知道X”，模型可能会声称不知道，但知识仍然会影响生成内容。连续梯度加强制声明的组合，把“无法完全禁止”这个事实，转化成了“可以完全追踪”的机制。

ADR-02：为什么验证层不用交叉一致性

多agent交叉一致性验证是行业里常见的方案，实现起来相对简单。 改用物质还原验证。 交叉一致性是形式验证，无法检测多个模型同时犯同一个错误的情况，比如它们共同引用了一个错误的信息源。物质还原是实质验证，每个论据都必须追溯到现实世界的事实基础。代价是成本更高，因此设计了分层触发（L1/L2/L3）来控制验证成本。

ADR-03：为什么三级介入选上游+下游，不是随机两个agent

不合格后需要额外的agent介入诊断，最省事的方法就是随机选两个。 固定选择上游agent + 下游agent，再加上监督agent。 故障诊断的有效性，完全取决于诊断者的“视角覆盖”。上游持有输入空间，下游持有消费规格，监督持有执行过程——这三者刚好覆盖了故障链路的全部维度，而且盲区互不重叠。随机选取的agent，很可能存在大量的视角重叠，从而形成诊断盲区。