多 Agent 协作模式 · 05 综合项目

把三轴、原理、失败模式揉进一个真实项目

前四章分别建了三轴坐标(01 拓扑 / 协调 / 通信)、原理账本(02 token、权衡、上下文隔离、何时不该用)、一套实操骨架(03)、12 个失败模式(04)。这一章把它们揉进一个真实项目——一个竞品调研 agent 系统——逼你在动手前先判别:这里该用哪根轴上的哪个取值,为什么。基于 LangGraph 1.0(2025-10)写于 2026-06;下文代码用来演示判别落点,均未在本机执行(标 2026-06)。

本章你要建立的心智模型

  • 多 agent 系统的设计先于实现:动手写 graph 前,拓扑 / 单vs多 / 上下文 / 可靠性这四个判别决策已经定了大半成败。
  • 每个判别决策都挂在前面某一章的具体小节——拓扑回 01 §1.2 与 02 §2.2,单vs多回 01 §1.5 与 02 §2.5,上下文回 02 §2.4,可靠性回 04 失败模式。
  • "备选 → 选哪个 → 为什么 → 代价"是判别的完整四段;只说"选 supervisor"而不报代价,等于没判别。
  • 同一套四轴判别,换个场景(实时客服)取值会翻转——判别能力是迁移的,结论不是。

5.1项目背景:竞品调研 agent 系统

需求

给公司建一个「竞品调研」agent 系统。输入一个主题(如「2026 年开源向量数据库格局」),系统要:并行查多个独立信源(官方博客、GitHub release notes、技术媒体评测、社区论坛),每个信源各自深挖(多轮检索 + 摘要),最后汇总成一份带引用的调研报告——每条结论后面挂得到来源链接。

这个需求的形状很关键——它正好踩在 01 §1.5「单 vs 多分界」的判别线上:子任务(查 4 个信源)彼此独立、可以同时进行,每个信源要烧掉大量上下文(多轮检索的中间结果),而最终交付物是一份高价值报告。这三个特征——独立、并行、各自吃 context——是 Anthropic 在 multi-agent research system 里给出的「值得上多 agent」的判据。

但「踩在线上」不等于「应该跨过线」。下面四个判别决策,每一个都要先报备选、再选、再说为什么、最后报代价。这是设计任务,不是步骤实现——先把决策做对,§5.4 才给参考实现。

表 5.1 · 系统要素(先把角色和信源理清,再做判别)
要素职责吃多少 context
Lead(主控)拆解主题为 N 个信源子任务、派活、收子报告、汇总写报告看子报告摘要,不看各信源原始检索流水
Source worker ×N每个绑一类信源,多轮检索 + 摘要 + 标引用每个吃满自己那条信源的检索历史(高)
Writer(汇总)把 N 份子报告合成带引用的最终报告看 N 份结构化子报告,不看原始网页

5.2设计任务:四个跨章判别决策

下面四个决策,每个对应不同章节,每个都有一个并不直白的正确答案。先合上后文,对每个决策自己想 30 秒——你选哪个,付什么代价——再展开对照。这是本章 discrimination 的核心:判别能力只在被迫做选择、而不是被讲解抚平的时刻长出来。

表 5.2 · 四个判别决策与它们各自的章节锚(先看清"哪个决策回哪一章")
编号判别决策章节锚(回链)
D1拓扑:单 agent / supervisor+并行 worker / swarm 三选一01 §1.2 拓扑结构 + 02 §2.2 拓扑选择权衡
D2要不要上多 agent:这场景值不值约 15× token01 §1.5 单 vs 多分界 + 02 §2.5 何时不该用
D3上下文:共享 state 还是 per-worker 隔离02 §2.4 通信与上下文隔离
D4可靠性:防哪些失败模式、怎么防04 失败模式(多个)

D1 · 拓扑:单 agent / supervisor+并行 worker / swarm?

表 5.3 · D1 备选
备选怎么做风险 / 代价
单 agent + 工具一个 agent 顺序查 4 个信源,自己写报告4 条信源串行 = 延迟叠加;单条上下文塞 4 信源的检索流水,长程后注意力稀释
Supervisor + 并行 workerLead 派 N 个 source worker 同时跑,收子报告后交 Writer 汇总Lead 易成瓶颈(04 §4.7);约 15× token;要处理并行写回(04 §4.9)
Swarm(去中心 handoff)worker 之间自由 handoff、互相补充信源之间本无依赖,handoff 无意义;易死循环 / 踢皮球(04 §4.8)
展开判别(先想再点):选哪个 · 为什么 · 代价

选 supervisor + 并行 worker。

为什么:

  • 子任务(4 类信源)彼此独立——没有"必须先查 A 才能查 B"的依赖。独立 + 可并行,正是 02 §2.2 里 supervisor 拓扑的甜区。
  • Swarm 适合「需要互相协商、动态决定下一步交给谁」的场景;信源调研里 worker 之间无协商需求,上 swarm 只会引入 04 §4.8 的 handoff 死循环风险,没有收益。
  • 单 agent 在「子任务可并行且各自吃满 context」时会同时输两场:延迟串行叠加 + 单条上下文被 4 条信源的检索流水撑爆。这正是 01 §1.5 判别线的另一侧。

代价(不报代价就不算判别):Lead 是显式单点,子任务多时会成瓶颈(04 §4.7 的修复是给 Lead 减负——只让它路由,不让它做重活);并行 worker 写回同一 state 要用 reducer,否则触发 04 §4.9 的并发写冲突;整体 token 约 15×(D2 专门算这笔账)。

章节锚:01 §1.2 拓扑结构(三种拓扑的定义)+ 02 §2.2 拓扑选择权衡(为什么这场景落在 supervisor)。

D2 · 要不要上多 agent:这场景值不值约 15× token?

这是最容易被跳过、却最该先问的决策——D1 已经默认了「上多 agent」,但多 agent 本身就是要被论证的,不是默认项。Anthropic 给的经验数是:多 agent 系统消耗约 15× 单 agent 对话的 token。

表 5.4 · D2 备选
备选什么时候对风险 / 代价
单 agent(不上多)子任务有强依赖、必须串行;或交付物廉价、token 预算紧本场景下延迟 + 上下文稀释(见 D1)
多 agent(接受 15×)子任务独立可并行 且 单次交付价值高,能摊薄 15× 成本约 15× token;调试 / 可观测成本上一档(04 §4.11、§4.12)
workflow(固定编排,非 agent)步骤完全固定、无需 LLM 动态决策路由信源数量 / 深挖轮次需动态决定,固定 workflow 不够灵活
想一想

同样这套竞品调研系统,如果改成给个人用户免费用、每天调上万次——D2 的答案会不会翻?

展开答案(先停 10 秒再点)

会翻。15× token 在「单次高价值交付」(如给战略团队一份季度竞品报告)下能被摊薄——一份报告值几百块人力,多花点 token 无所谓。但放到「每天上万次免费调用」,15× 直接把单位经济模型打穿。同一拓扑的成本,在不同业务上下文里值不值,结论相反。这正是 02 §2.5「何时不该用多 agent」的核心——不该用的第一判据往往不是技术,是单位经济。

展开判别(先想再点):选哪个 · 为什么 · 代价

选多 agent(接受约 15× token),前提是限定在「高价值、低频」的调研场景。

为什么:本场景交付物是一份供决策用的调研报告,单次价值高、调用频次低(不是面向海量终端用户的实时功能)。子任务独立可并行(D1 已确认)+ 单次价值高 = 15× 的两个前置条件都满足。02 §2.5 把这两条列为「值得上多 agent」的合取条件,缺一条就该退回单 agent。

代价:除了 token,多 agent 的可观测和评估成本显著上升——出错时要先定位是哪个 worker(04 §4.11),评估报告质量要同时看 N 条信源的贡献(04 §4.12)。这两项工程成本要预先计入预算,否则上线后无法运维。

章节锚:01 §1.5 单 vs 多分界(判据)+ 02 §2.5 何时不该用(15× 的合取前置条件)。

D3 · 上下文:共享 state 还是 per-worker 隔离?

表 5.5 · D3 备选
备选怎么做风险 / 代价
全共享(所有 worker 看同一条完整 message 历史)不隔离,所有检索流水进同一 statecontext clash(04 §4.5):博客 worker 被论坛 worker 的检索噪声干扰;token 浪费
Per-worker 隔离 + 结构化回传每个 worker 独立上下文跑深挖,只把结构化子报告(结论 + 引用)写回共享 state回传字段设计不当会漏信息(04 §4.4 隔离过度);要定义清楚回传 schema 之外的"摘要契约"
全隔离(worker 间零共享,连主题约束都不传)每个 worker 只拿到一句信源名缺共享意图 → 各查各的、口径不一,合并时冲突(04 §4.6)
展开判别(这题最微妙——隔离的"度"是 capstone 区分度最高的点)

选 per-worker 隔离 + 结构化回传。这正是 Anthropic multi-agent research system 的核心做法:每个 subagent 在自己隔离的上下文窗口里探索,主控只汇总它们的压缩输出,而不是把所有原始 token 堆进一条历史。

为什么:

  • 每个信源的深挖会产生大量中间检索结果(网页全文、失败的查询)。这些对别的 worker 是纯噪声——博客 worker 不需要看论坛 worker 翻了哪些帖子。全共享 = 04 §4.5 的 context clash,注意力被互相污染。
  • 但「隔离」不能滑到「全隔离」。worker 之间要共享同一份调研意图(主题、口径、要回答的子问题),否则各查各的,合并时口径冲突(04 §4.6)。所以隔离的是检索流水,共享的是意图 + 结构化结论。
  • 回传走结构化字段(每条结论带 source_url),让 Writer 能机械地拼引用,而不是从一坨自由文本里猜哪句话来自哪。

代价:回传 schema 设计是真功夫——字段太窄会触发 04 §4.4「隔离过度→子 agent 缺信息」(Writer 拿不到足够上下文去判断结论可信度);要在「隔离噪声」和「保留足够信息」之间找平衡点,这个平衡点没有银弹,要靠对任务的理解定。

章节锚:02 §2.4 通信与上下文隔离(隔离的机制与边界)+ 04 §4.4 / §4.5 / §4.6(隔离过度、不隔离、合并冲突三个失败模式)。

D4 · 可靠性:防哪些失败模式、怎么防?

前三个决策定了系统的形状;D4 定它在真实环境里不会崩。竞品调研系统跑在不可靠的外部世界上(网页超时、信源宕机、并行写回),04 章的 12 个失败模式里,有四个直接命中这个架构。

表 5.6 · D4 · 命中本架构的失败模式与防法
失败模式(来自 04)在本系统怎么发生怎么防
并行写回竞态(04 §4.9)N 个 worker 同时把子报告写回共享 state回传字段用 operator.add reducer,让 LangGraph 把并行结果安全合并成 list,而非互相覆盖
单 worker 失败拖垮全局(04 §4.10 错误传播)论坛信源超时,整份报告卡死worker 内 try/except 降级为"该信源不可用"占位结论,不让单条失败冒泡终止全局
Lead 成瓶颈(04 §4.7)Lead 既路由又做重活(自己也查信源)Lead 只做拆解 + 路由 + 触发汇总,不亲自检索;重活全下放给 worker
无法定位哪个 worker 出错(04 §4.11)报告里某条结论是错的,但不知出自哪条信源每条回传结论强制带 source_name + source_url,让错误可溯源到具体 worker
展开判别:为什么是这四个、代价在哪

为什么挑这四个:它们是「supervisor + 并行 worker + 外部信源」这个组合结构性带来的失败模式,不是随便挑的。并行→竞态(§4.9);外部依赖→错误传播(§4.10);中心拓扑→瓶颈(§4.7);多 worker→溯源难(§4.11)。04 里另外 8 个(如 §4.1 过早上多 agent、§4.8 swarm 死循环)已在 D1/D2 的拓扑选择阶段被规避掉了——好的拓扑决策会提前消掉一批失败模式,这本身就是 D1 的价值。

代价:每个防护都加复杂度——reducer 要正确定义、降级逻辑要测试、溯源字段贯穿整条回传链路。可靠性不是免费的;它换来的是系统能在真实环境联调而不是"看起来对"。

章节锚:04 §4.9 并行竞态 / §4.10 错误传播 / §4.7 supervisor 瓶颈 / §4.11 可观测。

5.3自己实现(先别看参考实现)

四个判别决策定了,现在把它落成可运行的 graph。在展开 §5.4 参考实现前,先自己写一版——基于 LangGraph 1.0 的 StateGraph + Send 并行原语 + create_react_agent。下面是验收 checklist:不看实现细节,只描述可观测的行为。你的版本能让这些行为成立,就算过。

验收 checklist(可观测行为)

  • 并行性:给 4 个信源,4 个 worker 同时启动(不是顺序一个接一个)——日志里 4 个 worker 的开始时间应接近重合。
  • 隔离性:每个 worker 的检索中间结果不出现在别的 worker 的上下文里(D3);只有结构化子报告进共享 state。
  • 安全合并:4 份子报告并行写回,最终 state 里是一个长度为 4 的 list,没有互相覆盖(D4 §4.9)。
  • 容错:人为让 1 个信源超时,系统仍产出报告,并在报告里标注"该信源不可用",而非整体崩溃(D4 §4.10)。
  • 可溯源:最终报告每条结论后面挂得到 source_url(D4 §4.11 + D3 结构化回传)。
  • Lead 不做重活:Lead 节点的代码里没有检索调用,只有拆解 + 路由 + 触发汇总(D4 §4.7)。
提示

并行 fan-out 用 Send("source_worker", {...}) 在条件边里返回一个 list——N 个 Send = N 个 worker 真正并行。回传字段用 Annotated[list, operator.add] 让并行结果自动合并。这两件事一起满足"并行性 + 安全合并"两条验收项。写完再展开 §5.4 对照。

5.4参考实现与系统架构

Lead(主控) 拆解 + 路由,不检索 Send × N(并行 fan-out) Worker · 官方博客 隔离上下文 Worker · GitHub 隔离上下文 Worker · 媒体评测 隔离上下文 Worker · 社区论坛 隔离上下文 web search release API web search forum search 结构化子报告 → operator.add reducer(安全合并为 list) 防并行写回竞态 · 04 §4.9 Writer(汇总) 合成带引用报告
图 5.1竞品调研 agent 系统参考架构。注意:Lead 到 worker 的朱红 fan-out 线是 Send × N 并行派发(D1);4 个 worker 各自隔离上下文、工具用虚线框(D3);所有子报告先汇到中间那条 reducer 横杠再交 Writer——这条横杠就是 D4 §4.9 防并行写回竞态的落点,不是装饰。

下面是参考实现。演示用、未在本机执行(2026-06)——重点看每段代码体现了哪个判别决策,而不是当成可直接上线的脚手架。

research_system.py · 状态与 worker(体现 D3 隔离 + D4 reducer) Python
# 1 │ 状态:用 operator.add 让并行 worker 的子报告安全合并(D4 · 04 §4.9)
import operator
from typing import Annotated, TypedDict
from langgraph.graph import StateGraph, START, END
from langgraph.types import Send
from langgraph.prebuilt import create_react_agent
from langchain_anthropic import ChatAnthropic

class Finding(TypedDict):
    source_name: str          # 溯源(D4 · 04 §4.11)
    source_url: str           # 每条结论挂得到来源(D3 结构化回传)
    claim: str

class ResearchState(TypedDict):
    topic: str
    sources: list[str]                              # Lead 拆解出的信源清单
    # 关键:reducer 把 N 个并行 worker 的回写合并成一个 list,而非互相覆盖
    findings: Annotated[list[Finding], operator.add]
    report: str

llm = ChatAnthropic(model="claude-sonnet-4-5")

# 每个 worker 是一个独立 create_react_agent —— 自带隔离上下文(D3)
def make_worker(source_name: str, tools: list):
    agent = create_react_agent(llm, tools=tools)
    def worker(state: dict) -> dict:
        # state 里只有这条信源的 task,看不到别的 worker 的检索流水(D3 隔离)
        prompt = f"就主题「{state['topic']}」深挖信源 {source_name},每条结论附 source_url。"
        try:
            result = agent.invoke({"messages": [("user", prompt)]})
            findings = parse_findings(result, source_name)   # 解析为 Finding 列表
        except Exception:
            # 单 worker 失败降级为占位,不冒泡终止全局(D4 · 04 §4.10)
            findings = [Finding(source_name=source_name,
                                source_url="", claim="(该信源本次不可用)")]
        return {"findings": findings}   # 经 reducer 安全并入共享 state
    return worker

findings: Annotated[..., operator.add] 这一行就是 D4 §4.9 的防护——LangGraph 见到 reducer,会把 N 个并行节点对同一字段的写入合并而非让最后一个覆盖前面。没有它,4 个 worker 并行写回只剩 1 条。

try / except 降级 是 D4 §4.10:单条信源超时只产出一个占位 Finding,报告照出,不整体崩。

每个 worker 独立 create_react_agent 是 D3 隔离——worker 的 state 里只有自己的 task,看不到兄弟 worker 的检索历史。

research_system.py · Lead 并行派发 + 组装(体现 D1 + D4 §4.7) Python
# 2 │ Lead 只拆解 + 路由,不亲自检索(D4 · 04 §4.7 防瓶颈)
def lead(state: ResearchState) -> dict:
    # 真实场景这里用 LLM 把 topic 拆成信源清单;此处写死演示判别落点
    return {"sources": ["官方博客", "GitHub", "媒体评测", "社区论坛"]}

# 条件边:N 个 Send = N 个 worker 真正并行(D1 supervisor + 并行 worker)
def fan_out(state: ResearchState):
    return [Send(s, {"topic": state["topic"]}) for s in state["sources"]]

# Writer 看 N 份结构化子报告,不看原始网页(D3)
def writer(state: ResearchState) -> dict:
    cited = "\n".join(f"- {f['claim']}  [来源]({f['source_url']})"
                      for f in state["findings"] if f["source_url"])
    return {"report": synthesize(state["topic"], cited)}

g = StateGraph(ResearchState)
g.add_node("lead", lead)
g.add_node("官方博客", make_worker("官方博客", [web_search]))
g.add_node("GitHub",  make_worker("GitHub",  [release_api]))
g.add_node("媒体评测", make_worker("媒体评测", [web_search]))
g.add_node("社区论坛", make_worker("社区论坛", [forum_search]))
g.add_node("writer", writer)

g.add_edge(START, "lead")
g.add_conditional_edges("lead", fan_out)          # fan-out:并行派 4 个 worker
for s in ["官方博客", "GitHub", "媒体评测", "社区论坛"]:
    g.add_edge(s, "writer")                       # 4 条汇到 writer,靠 reducer 合并 findings
g.add_edge("writer", END)
app = g.compile()

[Send(s, ...) for s in sources] 是 D1 的落点——条件边返回一个 Send 列表,LangGraph 同时启动这批节点。这一行让"并行性"验收项成立。

lead 节点里没有任何检索 是 D4 §4.7——Lead 只产出信源清单,重活全在 worker。

表 5.7 · 四个判别决策的最终选择与落点(对照表)
决策选择代码 / 架构落点章节锚
D1 拓扑Supervisor + 并行 workerSend × N fan-out 条件边01 §1.2 + 02 §2.2
D2 单 vs 多上多 agent(限高价值低频)整个 supervisor graph 的存在前提01 §1.5 + 02 §2.5
D3 上下文Per-worker 隔离 + 结构化回传独立 worker agent + Finding schema02 §2.4
D4 可靠性reducer + 降级 + Lead 减负 + 溯源operator.add / try-except / 瘦 Lead / source_url04 §4.9 / §4.10 / §4.7 / §4.11

5.5亲手画一张图

亲手画一张图

合上教程,在纸上或 Excalidraw 里画你设计的多 agent 系统结构——只画 3-5 个节点。每个节点(或连线)旁边标上三轴取值:拓扑(单 / supervisor / swarm)、通信(共享 state / 隔离 + 结构化回传)。再额外标出:哪条线是并行 fan-out、哪里有 reducer 防竞态。

画完再对照本章 §5.4 的架构表(表 5.7):你画的图里——并行 fan-out 那条线标出来了吗?worker 是不是画成了"隔离上下文"而不是共享一条历史?合并处有没有标 reducer?Lead 旁边有没有写"不检索"?哪一处没标出来,就是对应那个判别决策(D1/D3/D4)还没真正建进心智模型的地方——回去翻对应小节。

5.6把四个决策连成一棵判别树

四个决策不是平行清单,它们有先后依赖:先问"值不值上多 agent"(D2),再选拓扑(D1),拓扑定了才谈上下文(D3)和可靠性(D4)。画成一棵树,下次遇到新场景就能顺着走。

D2 · 子任务独立可并行 且单次价值高? 退回单 agent / workflow 02 §2.5 否 D1 · 选 supervisor + 并行 worker 01 §1.2 · 02 §2.2 是 D3 · 隔离上下文 + 结构化回传 02 §2.4 D4 · reducer + 降级 + 减负 + 溯源 04 §4.9 / §4.10 / §4.7 / §4.11
图 5.2多 agent 设计判别树。注意:根节点是 D2(值不值上多 agent),不是 D1(拓扑)——拓扑只在"决定上多 agent"之后才谈。左下"退回单 agent"那条"否"分支是最常被工程师跳过、却最该先走的路;多数过早上多 agent 的失败(04 §4.1)都源于没走这一步。

5.7反思问题

  1. 四个决策里,哪个你想得最快、哪个最难?最难的那个,回看哪一章帮到了你?(多数人 D1 拓扑想得快——supervisor 几乎是直觉;D3 上下文隔离的"度"最难,因为它卡在 02 §2.4 的隔离与 04 §4.4 隔离过度之间,没有银弹答案。)
  2. 如果场景从「竞品调研」换成「实时客服」(用户在线等回复、要求秒级响应、一次只处理一个用户问题)——四个决策里哪些必须改?为什么?
  3. D2 的"否"分支——如果有人坚持"这个调研系统就该上多 agent,因为听起来更高级",你用本章哪个具体数据 / 判据反驳?
反思参考方向(不是唯一答案,先自己想)
  1. D1 通常最快(拓扑有强直觉),D3 最难——隔离的"度"要在 02 §2.4 与 04 §4.4 之间权衡,回传 schema 设计是真功夫。这说明上下文工程(哪个 agent 看什么)是多 agent 设计里最综合的一环,也是面试区分度最高的题。
  2. 换成实时客服:D1 翻转——单个用户问题通常不可拆成独立并行子任务,应退回单 agent(或带工具的单 agent);D2 翻转——实时高频 + 单次价值低,15× token 打穿单位经济,明确不该上多 agent;D3 大幅简化——单 agent 无 worker 间隔离问题;D4 重心从"并行竞态"转向"延迟 / 超时兜底"(用户在线等不起重试链)。四轴判别方法不变,取值几乎全翻——这就是"判别能力可迁移、结论不可迁移"。
  3. 用 D2 的两条合取判据 + 15× 数:多 agent 只在「子任务独立可并行」且「单次交付价值高到能摊薄约 15× token」时才划算(来源:Anthropic multi-agent research system)。"听起来高级"不是判据;若该调研是低频高价值场景,结论恰好成立,但论证要落在这两条上,而非"高级"。

§本章 self-check

先合上教程,把答案写在纸上或编辑器里。写完再点开对照——直接点开等于把这一节当再读一遍。

  1. 本章把根节点定为 D2(值不值上多 agent)而不是 D1(拓扑)。为什么这个顺序很重要?把顺序反过来会埋下哪个失败模式(04 第几条)?
  2. D3 选了"隔离上下文 + 结构化回传"。如果滑向全隔离(worker 间连主题口径都不传),会触发 04 哪条失败模式?滑向全共享又触发哪条?
  3. 参考实现里 findings: Annotated[list[Finding], operator.add] 这一行删掉,会出现什么可观测的错误行为?对应 D4 的哪个判别点?
  4. 场景换成"实时客服",D1 和 D2 各自怎么变?用一句话说清"为什么判别方法不变、取值却翻了"。
  5. 四个决策里,哪个跨的章节最多?这暗示多 agent 设计中哪种能力最综合、最值得练?
答案(先做完再展开)
  1. D2 在前,是因为"上不上多 agent"本身要被论证——多 agent 不是默认项。先定 D1 拓扑等于默认了"上多 agent",跳过了 15× token 的成本论证,正是 04 §4.1「过早上多 agent」的成因。顺序反了 = 把最该质疑的前提当成了起点。
  2. 全隔离(连意图都不传)→ worker 各查各的、口径不一,合并时冲突,命中 04 §4.6「子 agent 结果合并冲突」;全共享 → 各 worker 的检索噪声互相污染上下文,命中 04 §4.5「不隔离→context clash」。正确解是隔离检索流水、共享意图 + 结构化结论,落在两者之间。
  3. 删掉 reducer 后,4 个并行 worker 对 findings 的写入会互相覆盖,最终 state 里只剩最后一个写回的 worker 的结果(甚至直接报并发更新冲突)——报告只剩 1 条信源。对应 D4 的 04 §4.9「并行竞态 / 共享 state 写冲突」。
  4. D1:实时客服单个用户问题不可拆成独立并行子任务 → 退回单 agent;D2:实时高频 + 单次价值低 → 15× token 不划算,不该上多 agent。判别方法(问"子任务独立可并行吗 / 单次价值高吗")完全不变,但这两个问题的答案在新场景里都翻了 → 取值翻、方法不翻。
  5. D4 跨 04 的四条(§4.9 / §4.10 / §4.7 / §4.11)章节最多;D3 跨 02 §2.4 + 04 §4.4/§4.5/§4.6。两者都指向上下文工程 + 可靠性工程——即"哪个 agent 看什么、出错了怎么不崩"——是多 agent 设计里最综合、最该练的能力,也是把"会画拓扑图"和"能上线"区分开的地方。
进阶挑战 · 刚好够不着

给系统加一层"信源可信度加权"

现在 Writer 把 4 份子报告平等对待。真实竞品调研里,官方博客的一手信息往往比匿名论坛帖可信。给系统加一层可信度加权:每条 Finding 带 confidence,Writer 在结论冲突时(博客说支持 X、论坛说不支持 X)按可信度裁决,并在报告里显式标注分歧而非悄悄取一边。

这个改动会动到本章哪几个判别决策?画出新的 Finding schema 和 Writer 的裁决逻辑要点。

提示(卡住再展开)

主要动 D3(结构化回传 schema 要加 confidence 字段,且可信度该由谁定——worker 自报容易虚高,更稳的是 Lead 在派活时按信源类型预置权重)和 D4("显式标注分歧"是 04 §4.6 合并冲突的正解——不是消除冲突,而是暴露冲突让人判断,对应 04 §4.11 可观测的精神)。D1/D2 不变——拓扑和"该不该上多 agent"不受影响。难点在:可信度若让 worker 自评会失真,把它上提到 Lead 的派发阶段(信源类型 → 预设权重)更可靠,这又回到了 D4 §4.7"Lead 该承担什么"的边界讨论。