第 7 章 — 高级协作与动态模式
LLM Primer IV: Designing AI Cognition with MCP 章节走读的第七篇。当拓扑没法在设计时画出来 — 当下一步对的方向取决于上一步发现了什么 — 第 6 章那些模式就不够用了。
这一章为什么存在
第 6 章那些模式共享一个架构特征,这个特征在更难的任务上变成了拖累:拓扑在设计时就定死。工程师画好流水线、给阶段命名、决定谁喂谁,运行时不再重新考虑。对形状已知的任务,这是优点。对真正意义上形状是涌现出来的任务 — 该挑哪个专家取决于用户实际问了什么、计划本身得边做边搭出来 — 固定拓扑就成了一个笼子。
这一章走动态模式:roundtable(几个 agent 迭代到共识),router(运行时把请求委派给专家),magentic 编排(边干边搭计划)。每一种买到了简单模式给不了的能力。每一种引入了简单模式躲掉的故障 — 不停机、错路由、计划失控。
7.1 群聊和 roundtable:maker-checker、多方共识
群聊编排把几个 agent 放进一个共享的对话上下文,让他们轮流发言。最简单的形式是双 agent 的 maker-checker 循环:maker 产出一个候选,checker 按一份评分标准打分,maker 按反馈修改,在通过或步数预算耗尽时停。语言模型在评估上比在生产上量级更准,前提是两件事被框对 — 一个被要求在同一次调用里既写又自评的模型倾向于护着第一次尝试;同一个模型在干净上下文里看到同样的输出加清晰评分标准,会明显挑剔得多。
诚实的故障模式有三。串通 — 当 maker 和 checker 用同一个模型同一个 prompt,checker 什么都批准。防御是真正区分角色,理想上用不同模型。不停机 — 严格的 checker 拒绝每一个候选;编排器必须接受 "目前最好" 或者升级。checker 漂移 — 在共享 roundtable 上下文里,checker 开始批准它早先会拒绝的东西,因为 maker 的辩解在积累。2025 年末有个反直觉的现场发现:最可靠的 maker-checker 系统不让 checker 看到候选是怎么产生的。无状态 checker — 只给候选和评分标准 — 把正确拒绝率提高 30 到 50%。共享上下文是工具,不是默认。
多方 roundtable 把这个模式扩成几个专家加一个主持人。代价涨得快:token 花销随共享 transcript 增长,延迟随轮数增长,agent 卡在岔路上的情况在生产里见过。让它能工作的纪律 — 每轮 token 有界、结构化的轮次输出、显式的终止标准 — 就是 "一场有产出的会议" 和 "本应该是一封邮件的会议" 之间的差别。
7.2 Handoff 和路由:动态委派
Handoff 编排走的是另一条路:一次只有一个 agent 处理对话,active agent 在它干完或请求转向另一个专长时可以交班。Router — 通常自己也是 LLM — 读对话状态,输出路由决策:"留在当前" 或 "用这段上下文摘要交给专家 X"。摘要是路由层和专家之间的合同。
最难的工程问题是识别什么时候该 handoff。错路由是最常见的故障:router 把账单问题送去了技术支持,技术支持尽力答,用户得到一个不沾边的答案。防御要分层:置信度低于某个阈值时让人接手、专家有显式的 "这不是我领域" 动作、记录每一次路由决策方便复盘。
另外两个故障模式塑造生产设计。Handoff 循环 — 专家 A 送给 B,B 送回 A — 靠检测重复 handoff、强行换另一种处置来防。上下文丢失 — 每次 handoff 摘要是有损的,下一个专家可能会问用户已经说过的事 — 靠把完整对话存在任何专家上下文之外、把摘要当主载荷、原始历史按需提供来防。专家数量长大时,扁平 router 变脆;2025 年沉淀下来的模式是分层路由 — 一个粗 router 选大类,大类专属 router 选具体专家。两层是生产里的甜区。
7.3 Magentic 编排:边干边搭的计划
对那些一开始拆不出来的任务 — 调查数据库为什么慢、调试一个陌生系统、研究一个复杂主题 — 前面那些模式都不够。Magentic 编排,以微软 Magentic-One 框架命名,是这一族模式:一个 manager agent 持有一份 任务台账,边干边更新。台账有显式的位:原始目标、当前理解(可能精修)、有优先级的待办子任务、完成的子任务及结果、可能需要修正计划的新发现、停止条件。Manager 每一步读台账、决定下一步派给谁、把结果整合回去。
强项是真正的开放性。"调查数据库为什么慢" 没法先拆好 — 下一个子任务取决于瓶颈最后是网络、查询计划还是热点行。任何固定流水线都处理不了这种;任何静态 handoff 拓扑都没法在还不知道相关专长是什么的时候路对。
代价在所有维度上都是这一章里最重的:延迟、token、工程努力、运维风险。Token 花销超线性增长,因为台账每轮都被读。被收录的故障模式很尖锐。计划失控 — manager 开子任务的速度比关的快,台账无界增长。目标漂移 — 学得越多,manager 把目标重新表述得离用户意图越远。计划震荡 — 每个新发现触发一次计划修改,没有任何承诺持续够久到能推进。沉淀下来的模式是 有界 magentic 循环:对开放子任务数、总 worker 调用数、墙钟时间设预算,触线就升级。生产里跑没有预算的 magentic 系统,偶尔会在 manager 在任何实际预算内都解不掉的任务上烧掉几百美元 token。
7.4 在这些模式里挑选
三个问题做筛选。拓扑是不是事先已知?是的话留在第 6 章的静态模式。这项工作从对外部检查的迭代里得益吗?是的话 maker-checker 循环是该加的东西 — 可以嵌进任何其他模式。规划有多开放?有清楚边界的话 handoff 或顺序处理够;真的涌现的话 magentic 是必要的,带着它的代价接下来。
2025 年金融服务行业一个有教育意义的反面案例:一个被选为 magentic 的客户 onboarding 工作流(因为团队对框架的灵活性很兴奋)被换成了固定顺序流水线。每次 onboarding 成本从约 7 美元降到 80 美分;完成率上升。在更具体的工具就够用时伸手抓最通用的工具,这种模式在软件工程里不新鲜,在多 agent 编排里特别显眼,因为通用性是用 token 付的。
第 7 章接下去会怎么走
第 6、7 章规定了 agent 怎么协调。它们没规定 agent 在哪里跑、语言模型怎么跟工具同地、部署拓扑在进程、机器、网络边界这一层是什么样。两个有完全一样编排逻辑的系统可以被部成截然不同的样子 — 不同的延迟画像、不同的成本结构、不同的安全姿态。第 8 章覆盖这个维度。
明天 — 第 8 章:部署形态。MCP 可以被物理部署的三种大体不同方式 — 模型跟 server 在一起、模型在 client 里、混合 — 各自在延迟、成本、运维复杂度、以及它们各自更可能引起什么故障上的现实权衡。
