Skip to main content
Lead Agent 我踩过的坑都在交接上:信息丢了、超时重派导致重复执行、冲突没人拍板。拆任务容易,收尾难。

Q1: Lead Agent、Supervisor、Orchestrator 是什么关系?

这三个词经常混用,但侧重点不同: 一个完整的 Lead Agent 通常同时具备三者能力:
有多个 Agent 并不等于多 Agent 编排。如果分派规则是代码写死的(账单问题给 A、技术问题给 B),那本质是 Workflow 的路由模式;只有 Lead 在运行时动态决定怎么拆、拆多细、派给谁,才属于编排者—工作者模式。

Q2: Lead 怎么把一句话目标拆成可执行的任务树?

拆解的目标是一棵可调度、可验收的树,“分得越细越好”是常见误解。

拆解的五个硬约束

粒度怎么判断

经验值:子任务的工作量控制在 5-15 个工具调用以内。超过就该继续拆,少于 2 个就该合并。

Q3: 任务怎么分派?为什么”把完整对话历史丢给子 Agent”是错的?

分派是一次结构化交接,发一段任务描述远远不够。

交接契约

上下文隔离:只给”需要知道的”

子 Agent 不应该继承 Lead 的完整对话历史。原因有三:
  1. 成本。 几千 token 的历史乘以 N 个子 Agent,成本线性放大。
  2. 噪声。 无关的讨论会干扰子 Agent 判断,甚至让它重复 Lead 已经排除的方案。
  3. 一致性。 每个子 Agent 看到的历史版本可能不同,导致产物互相矛盾。
正确做法是维护一份任务简报(brief):目标、已确认事实、约束、验收标准。子 Agent 只读简报加自己的子任务。

路由策略

分派的质量取决于交接契约的质量。自然语言转述三层之后必然丢信息,结构化 Schema 才能保证子 Agent 拿到的是同一份事实。

Q4: 子 Agent 的结果怎么汇总?冲突了谁说了算?

汇总包含三个动作——校验、合并、裁决,拼起 N 份结果不算完成。

第一步:逐份校验

每个子任务返回后,Lead 先做机器校验:

第二步:合并

第三步:冲突裁决

冲突在多 Agent 系统里是常态,不能靠”让模型再聊一轮”解决。
关键原则:Lead 对最终结果负责。 不能把 N 份互相矛盾的结果直接丢给用户,让用户自己判断。

Q5: 子任务失败、卡死、跑偏,Lead 怎么处理?

四类失败与处理

越级上报

子 Agent 遇到以下情况不应擅自行动,而应带着上下文上报 Lead:
  • 需要更高权限(删除、发布、改生产配置)。
  • 发现任务前提不成立(接口不存在、需求矛盾)。
  • 多个方案代价接近,无法自主决策。
  • 连续失败达到阈值。

幂等性:重派的前提

所有写操作必须幂等,否则”超时后重派”会变成”重复下单”。常用做法:
  1. 每个任务带唯一 taskId,下游按 ID 去重。
  2. 写操作使用幂等键(idempotency-key)。
  3. 重派前先查询任务状态,不要盲目重试。

Q6: 怎么保证 Lead Agent 可观测、可评测?

多 Agent 最难的排障问题是:“到底是哪一步错了?“没有 trace,调试就是玄学。

必须记录的事件

核心指标

评测怎么做

  1. 固定任务集。 选 20-50 个真实任务,覆盖简单/中等/困难。
  2. 固定模型与 Harness。 只改编排策略,做 A/B。
  3. 自动校验产物。 能用 Schema 和测试校验的,不要用模型打分。
  4. LLM-as-a-Judge 只做补充。 用于主观质量,且要人工抽检校准。
  5. 回归门禁。 成功率下降超过阈值就阻断发布。

Q7: 成本与并发怎么控制?

多 Agent 的成本是乘法增长:子 Agent 数量 × 每轮上下文 × 轮次,按线性估算会严重低估。
每多一个 Agent,就多一次上下文组装、一次模型调用、一次结果校验和一层失败可能性。先用单 Agent 跑通基线,确认瓶颈确实是上下文或工具过载,再拆多 Agent。过早拆分只会增加调度复杂度。

Q8: 一个最小可用的 Lead Agent 实现长什么样?

这段代码对应的工程决策


Q9: 任务树和 DAG 到底有什么区别?为什么 Lead 应该产出 DAG?

机制差异

树适合”责任归属”,DAG 适合”执行调度”。Lead 真正需要的是后者:T3.1 后端接口 和 T3.2 前端入口 都依赖 T2.1 接口契约,如果用树表达,这条共享依赖会丢失,导致前端在契约未定时就开始实现。

粒度怎么量化

不要只说”适中”,给可执行的判断:

预算与早停

拆解必须有上限,否则 Lead 会”越拆越贵”:
每多一个叶子节点,就多一次上下文组装、模型调用、结果校验和失败可能。拆解前先问:这个拆分带来的成功率提升,能不能覆盖多出来的成本?答不上来就不拆。

Q10: 交接契约里哪些字段最容易被省略,后果分别是什么?

交接契约要让子 Agent 拿到同一份事实,发一段任务描述做不到这一点。字段缺失的后果可以逐条对应:

扩展后的契约

上下文隔离的边界

只给”需要知道的”,不是”Lead 知道的都给它”:
  • 给:目标、已确认事实、约束、验收标准、上游产物引用。
  • 不给:完整对话历史、已被排除的方案、其他子 Agent 的私有推理。
  • 原因:成本线性放大、无关讨论造成噪声、不同步的历史导致产物互相矛盾。
契约的质量决定分派的质量。自然语言转述三层之后必然丢信息,结构化 Schema 才能保证所有子 Agent 基于同一份事实工作。

Q11: 路由、超时重派、补偿与越级上报怎么串成一条可靠链路?

路由不是随机,是加权

冷启动没有历史数据时,用能力匹配 + 负载均衡兜底,并保留一定探索比例,避免某个 Agent 永远接不到任务。

超时重派必须幂等

超时不等于没执行。写操作超时后直接重派,会变成重复下单、重复发消息。

补偿事务

已经产生副作用的步骤失败时,不能”假装没发生”,要显式补偿: 补偿操作本身也必须幂等,且要记录在 trace 里,否则回滚会变成二次事故。

越级上报的触发条件

关键原则:决策权集中,执行权下放。 Worker 可以上报异常,但不应该擅自改变任务目标;Lead 负责拆解与裁决,并对最终结果负责。

及格回答 vs 满分回答

问题:“Lead Agent 怎么把任务拆给子 Agent,怎么保证最后能交付?”

及格回答(60-70分):
“主 Agent 把任务拆成几个子任务,分给不同的子 Agent 并行做,最后把结果合起来。需要给子 Agent 设超时,失败了就重试。”
问题出在:知道流程,但没讲清契约、依赖和裁决。 满分回答(90-100分):
“拆解产出的是任务树或 DAG,不是一段自然语言清单。每个节点必须有输入契约、输出 Schema、验收标准和显式依赖,子 Agent 只拿任务简报,不继承完整对话历史。”
“分派按能力、负载和历史成功率路由;执行时并行有上限,失败分瞬时、格式、方向和卡死四类处理。汇总先做机器校验,再按拼接、去重、归并合并,冲突按依赖、置信度或评审裁决,Lead 对最终结果负责。”
“最后靠 trace 和固定任务集做评测,看成功率、重派率和人工接管率。没有这些,多 Agent 只是把单 Agent 的问题放大 N 倍。“

常见追问

答题要点: 先找瓶颈,再拆分。高分回答: “单 Agent 遇到三类瓶颈才拆:上下文膨胀导致遗忘、工具超过十几个导致选错、角色冲突导致提示互相打架。拆分前先跑单 Agent 基线,如果瓶颈是模型能力而不是结构,拆了也没用。”
答题要点: 共享事实,不共享全部历史。高分回答: “共享的是任务简报和已确认事实,不是完整对话。共享记忆要有版本和权限,否则一个子 Agent 的错误结论会污染所有人。推荐做法是 Lead 维护一份只读的共享事实表,子 Agent 的私有推理留在各自会话里。”
答题要点: 决策权集中,执行权下放。高分回答: “子 Agent 自主决策会导致任务边界模糊、重复工作和无法收敛。正确分工是 Lead 负责拆解和裁决,Worker 负责在明确契约内执行。Worker 可以上报异常,但不应该擅自改变任务目标。”
答题要点: 投票需要独立且同权,Agent 不满足。高分回答: “多个 Agent 可能共享同一份错误上下文,投票会放大共识偏差;不同 Agent 的专业度也不一样,同权投票不合理。更可靠的是按依赖关系、置信度、历史正确率裁决,高风险场景引入评审 Agent 或人工。”
答题要点: 重复副作用。高分回答: “如果子任务包含写操作,超时可能只是响应慢,实际已经执行。直接重派会重复下单、重复发消息。必须先做幂等键和状态查询,确认未完成再重派,或者把写操作拆成独立可补偿的步骤。”
答题要点: 契约 + 校验 + 分级。高分回答: “Lead 负责拆解和验收,必须强;Worker 做边界清晰、可校验的任务,可以用便宜模型。前提是任务契约足够结构化、结果能机器校验。对于主观质量高的任务,仍然要给 Worker 配强模型或增加评审环节。”
答题要点: 从单 Agent 基线、交接、校验、并发四条线查。高分回答: “先对比单 Agent 基线,确认是不是拆分本身带来的损耗;再看交接契约是否丢信息,子 Agent 是否拿到错误上下文;然后看校验是否形同虚设,脏数据是否被继续传递;最后看并发是否触发限流或资源竞争。按 trace 逐步定位,不要先怪模型。”
答题要点: 深度、数量、预算三重限制。高分回答: “设置最大树深、最大叶子数和总 token 预算,任一超限就强制收敛。拆解节点必须给出拆分理由和预期产物,无法说明收益的拆解直接拒绝。再用历史数据评估拆解带来的成功率提升是否覆盖成本。“

八道深度追问:及格 vs 满分

八题覆盖”任务树 / 粒度 / 契约 / 隔离 / 路由 / 重派 / 裁决 / 预算”。回答顺序建议:结论 → 机制 → 代价 → 怎么验证。

追问 1:任务树和 DAG 有什么区别,为什么 Lead 要产出 DAG?

及格回答: 差不多,都是把任务拆开,DAG 就是有依赖的树。 满分回答: 树只能表达”隶属于谁”,每个节点只有一个父节点;DAG 能表达”依赖谁”,一个节点可以有多个前置。真实任务里共享依赖很常见,比如前后端都依赖同一份接口契约。如果只用树,这条共享依赖会丢失,导致前端在契约未定时就开工。Lead 产出 DAG 是为了能做拓扑调度:按入度为 0 就绪、按依赖被阻塞、失败时能精确知道哪些节点受影响。责任归属仍可用 owner 字段表达,但调度必须靠 DAG。

追问 2:拆分粒度如何量化,而不是凭感觉?

及格回答: 拆到每个子任务能独立完成就行。 满分回答: 我用五条可执行标准量化:产物唯一(能写成一个文件或一份报告)、工具可控(5 到 15 次调用)、可验收(标准能逐条检查)、可回滚(失败不影响已完成节点)、依赖显式(全部写进 dependsOn)。此外设最大树深 4 层、最大叶子数 20 个,防止无限拆解。验证方式是固定任务集对比不同粒度下的成功率和总成本,如果拆细后成功率提升覆盖不了多出来的调度与汇总成本,就说明拆过头了。

追问 3:交接契约里最容易被省略的字段是什么,后果是什么?

及格回答: 目标和验收标准吧,不写清楚子 Agent 会乱做。 满分回答: 最容易被省略、后果最严重的是 idempotencyKey 和 dependsOn。少了幂等键,超时重派会重复产生副作用;少了依赖声明,上游没完成下游就开跑。其次是 outputSchema,缺了它汇总阶段无法解析,会大面积返工;还有 owner,没有唯一责任人,Handoff 或重派之后就没人对最终结果负责。我的做法是把这些字段设成必填,缺一个就拒绝分派,而不是靠子 Agent 猜。

追问 4:为什么不能把完整对话历史给子 Agent?

及格回答: 因为 token 太多,成本高。 满分回答: 成本只是第一层,更严重的是噪声和一致性。完整历史里有大量与子任务无关的讨论,会干扰子 Agent 判断,甚至让它重复 Lead 已经排除的方案;更麻烦的是,不同子 Agent 看到的历史版本可能不同,产物就会互相矛盾。正确做法是维护一份任务简报:目标、已确认事实、约束、验收标准、上游产物引用。子 Agent 只读简报加自己的子任务,私有推理留在各自会话里。

追问 5:路由时能力、负载、历史成功率怎么加权,冷启动怎么办?

及格回答: 优先给能力匹配的,忙的就少派一点。 满分回答: 先做硬过滤再做打分:能力标签不覆盖的直接排除,熔断中的排除,然后按能力匹配、剩余容量、同类任务最近 N 次成功率加权打分。冷启动没有历史数据时,退化为能力匹配加负载均衡,并保留小比例探索,避免某个 Agent 永远接不到任务、永远没有数据。关键是权重不能写死,要能用线上数据回归校准,并记录每次路由决策,否则出了问题无法复盘。

追问 6:超时重派怎么避免重复副作用?

及格回答: 重试前先检查一下是不是已经完成了。 满分回答: 核心是幂等。每个写操作带唯一 idempotencyKey,下游按 key 去重;重派前先查任务状态,状态是 done 就直接返回已有结果,不要盲目重试。对于已经产生副作用但后续失败的步骤,要显式补偿,比如删除已上传的对象或作废草稿,补偿本身也必须幂等并写入 trace。最忌讳的是”超时了就当没发生,直接重跑”,那会把一次超时变成重复下单。

追问 7:冲突裁决为什么不能只靠投票?

及格回答: 投票比较公平,少数服从多数。 满分回答: 投票成立的前提是投票者相互独立且同权,而多 Agent 往往不满足:它们可能共享同一份错误上下文,投票只会放大共识偏差;不同 Agent 的专业度也不同,同权不合理。更可靠的是按依赖关系、置信度、历史正确率裁决,高风险场景引入独立评审 Agent 或人工。而且 Lead 必须对最终结果负责,不能把几份互相矛盾的结果直接丢给用户。

追问 8:预算和早停怎么设,怎么证明没有牺牲质量?

及格回答: 设个 token 上限,到上限就停。 满分回答: 预算要分层:单任务 token 和工具调用上限、全局任务预算、并发上限。早停以”验收标准已全部满足”为触发条件,预算是兜底红线,达到任一条件就立即结束,不再过度优化。为了证明没有牺牲质量,我会用固定任务集做对照:一组开早停、一组不设上限,比较成功率、返工率和单位任务成本。如果早停组成功率下降明显,说明阈值设得太激进;如果成本下降而质量持平,才是有效的早停。

延伸阅读与引用参考