企业官网建设流程全解析

顺序、并行、辩论、会商：OpenMAIC 四种交互模式背后的编排逻辑

【免费下载链接】OpenMAICOpen Multi-Agent Interactive Classroom — Get an immersive, multi-agent learning experience in just one click项目地址: https://gitcode.com/GitHub_Trending/op/OpenMAIC

一句话生成一门课，只是 OpenMAIC 的前半场；后半场是这门课如何"活"起来——多个角色化 AI 智能体在同一间教室里，以何种次序、何种节奏、何种协作方式展开对话。社区对 OpenMAIC 的拆解文章里，经常把它的课堂交互归纳为四种模式：顺序、并行、辩论、会商，对应四类截然不同的教学节奏。但如果你翻开源码会发现，这四种模式并不是四套独立引擎，而是同一台"编排内核"（LangGraph 导演图 + 共享记忆）在不同教学意图下的四种姿态。本文以仓库源码为准，拆开这台内核：导演节点如何做消息路由、白板账本如何充当共享记忆、模式切换的开关藏在哪一行代码里，以及为什么选错模式会让一堂 AI 课从"生动"变成"失控"。

四种交互模式，四种课堂节奏

先给四种模式一个清晰的课堂坐标：

• 顺序（Sequential）：一次只让一个智能体发言，轮次依次推进。对应传统课堂的"讲—练—答"节奏，也是 OpenMAIC 里"自由问答"的默认形态——AI 老师通过幻灯片、图表或白板讲解，学生随时追问。
• 并行（Parallel）：多个智能体同时产出内容或观点，互不阻塞。OpenMAIC 中"并行"体现在两个层面：一是生成侧的并行场景内容生产，二是同一白板上多个智能体各自落笔、最后汇合成一张协作成果。
• 辩论（Debate）：不同立场的智能体围绕一个话题轮番发言、互相反驳。对应 README 中"多个不同人设的智能体围绕话题展开讨论"的圆桌辩论。
• 会商（Collaborative）：智能体围绕同一任务协作推进、互相补充，最终形成一致产出。对应项目制学习（PBL）——"选择一个角色，与 AI 智能体协作完成结构化项目，包含里程碑和交付物"。

值得注意的是，社区文章还流传着另一组英文命名——Referral、Monopolistic、Equal、Collaborative——它们描述的是"谁掌握话语权"的交互语义，与上面四种节奏是同一枚硬币的两面。而仓库里真正支撑这些形态的，是下面这台统一编排器。

编排内核：导演图与"单轮契约"

打开 lib/orchestration/director-graph.ts，文件头注释直接交代了全部拓扑：

START → director ──(end)──→ END │ └─(next)→ agent_generate ──→ END

这是一个基于 LangGraph StateGraph 构建的状态机。关键在于注释里的"单轮契约"：

Each request runs at most one director→agent cycle. The client serializes multiple requests to drive multi-agent discussions. There is no maxTurns cap — the topology is the bound.

每一轮 HTTP 请求最多执行一次"导演决策 → 单个智能体发言"的循环，多智能体的长篇讨论由客户端把多次请求串行化拼出来。这个设计极其克制：服务端图本身不循环，天然杜绝了"死循环烧 token"的经典事故；轮次上限不由maxTurns参数决定，而由拓扑结构本身决定。讨论的延续靠客户端一次次携带directorState（turnCount、agentResponses、whiteboardLedger）回传，形成无状态服务端 + 有状态客户端的组合。

导演节点（directorNode）内部还有一套按智能体数量分叉的策略：

• 单智能体：纯代码逻辑，零 LLM 调用。第 0 轮直接派发唯一智能体，后续轮次cue_user把话筒交还学生；
• 多智能体：第 0 轮若携带triggerAgentId（讨论发起者），走代码快路径直接派发；其余轮次才调用 LLM 让"导演"决定下一位发言人、USER还是END。

单智能体场景连导演的 LLM 调用都省了，这解释了为什么 OpenMAIC 的问答课堂延迟低、成本可控——编排器的开销是随智能体数量阶梯式增长的。

切换模式的开关：藏在导演提示词里

模式不是靠枚举参数切换的，而是靠discussionContext注入导演提示词。在 director-prompt.ts 中，只要请求携带discussionTopic/discussionPrompt/triggerAgentId（见buildInitialState对request.config.discussionTopic的解析），导演提示词就会多出一段# Discussion Mode：

Topic: "..." Prompt: "..." Initiator: "..." This is a student-initiated discussion, not a Q&A session.

随之而来的还有第一条规则的分叉：

讨论模式：讨论发起者先开口，老师回应引导，然后其他学生补充观点； 问答模式：老师（teacher 角色，优先级最高）通常先回答学生的问题。

这就是"辩论/会商"与"顺序问答"之间的真正开关：同样是多智能体轮番发言，导演决策的约束完全不同——讨论模式下发起者拥有首轮话语权，老师被定位为"引导者"而非"解答者"；问答模式下老师是天然的优先发言人。而triggerAgentId还承担了一个性能职责：首轮派发走代码快路径，绕开一次 LLM 决策调用。

课堂侧的触发则来自场景动作 DSL。在 skills/agent-runtime/stage-dsl/references/actions.md 中，discussion动作的字段只有三个：topic（必填）、prompt（可选补充指令）、agentId（可选指定发言人）。生成侧规范则在 packages/@openmaic/generation/templates/slide-actions/system.md 里对讨论密度做了硬约束——"不要给每一页都加讨论，一门课最多 1-2 次，且优先放在开放式、引发思考的页面"。这等于在生成阶段就把"辩论模式的滥用"挡在了门外。

共享记忆：从消息路由到白板账本

"会商"与"辩论"模式最考验的不是谁发言，而是智能体们是否记得彼此说过什么、画过什么。OpenMAIC 的共享记忆由三块拼成：

1. 消息历史：convertMessagesToOpenAI(state.messages, agentId)做智能体感知的角色映射——其他智能体的话被映射为user角色，让当前发言者把它们当作"对方的观点"来回应（director-graph.ts）；
2. 对话摘要：summarizeConversation()把冗长历史压成紧凑摘要喂给导演，避免上下文爆炸拖垮决策质量；
3. 白板账本（whiteboardLedger）：每个智能体的wb_*动作（绘图、公式、图表、代码、删除、清空）都被追加进账本，导演每次决策前都能"重放"账本，算出白板当前元素数量与贡献者名单（director-prompt.ts 的summarizeWhiteboardForDirector）。

白板账本还有一句非常工程化的提示——当元素超过 5 个时：

⚠ The whiteboard is getting crowded. Consider routing to an agent that will organize or clear it rather than adding more.

导演会主动把一个"负责整理/清空白板"的智能体排进下一轮。这就是会商模式里"协作不演变成涂鸦"的隐形调度规则：共享记忆不只是记录，还驱动着编排决策。

防御性编排：把"失控"写进代码

多智能体课堂最常见的三宗罪——立场漂移、死循环、上下文爆炸——在 lib/chat/pi/tools/call-agent.ts 的call_agent工具里都有对应的硬防护：

• 轮次硬顶：工具描述明写"Hard limit: at most N classroom agent turns…Once the limit is reached, finish with cue_user or close_session"，超出即拒绝调用并强制收尾；
• 连续空转防护：MAX_CONSECUTIVE_EMPTY_TURNS = 2——模型连续两轮吐出空内容（比如推理吃光了输出预算）就判定为故障，终止智能体调用，防止"空响应绕过计数"导致的无限重试；
• 非法发言人拦截：agentId不在课堂名册中直接拒绝，返回可用名单，杜绝导演"点一个不存在的学生"；
• 动作白名单：getEffectiveActions(agentConfig.allowedActions, sceneType)按场景类型过滤动作——比如白板未打开时，spotlight/laser 等幻灯片动作会被剥离，属于"即使导演判断失误，智能体也越不了权"的纵深防御。

与之配套的是生成侧的并行控制：配置文档 packages/docs/content/docs/configuration.mdx 中的PARALLEL_SCENE_CONCURRENCY——"并行场景内容生成；0 或未设置则串行"。这为"并行"模式补上了资源维度的答案：并行不是无限并行，而是由一个显式并发数约束的可控并行。

选错模式的课堂会怎样

最后回到教学视角。模式本身没有优劣，只有是否匹配教学目标：

• 目标是从零讲清一个概念 →顺序问答。老师独白 + 学生追问，信息密度最高。若此时强行开圆桌辩论，多智能体各执一词会稀释主线，学生抓不住重点——生成侧"最多 1-2 次讨论"的约束正是为此；
• 目标是激发多角度思考 →辩论。需要发起者（triggerAgentId）先立论、老师引导、多方补充。若选成顺序模式，学生会只听到一个立场，思考被单向灌输；
• 目标是协作产出（推导、方案、项目）→会商。白板账本保证"谁画了什么"全程可溯，导演按拥挤度调度整理者。若错用并行模式，多个智能体同时落笔而不互相响应，白板会变成各说各话的拼贴；
• 目标是快速覆盖多个独立知识点 →并行。靠PARALLEL_SCENE_CONCURRENCY控制的生成并发，与白板上的多路协作。

社区复盘里反复出现的"立场漂移、上下文爆炸、讨论变成各说各话"，追到源码层面，几乎都能对应到上述某个防护机制的缺失或误配：没有账本就没有可追溯的会商；没有单轮契约就没有可控的轮次；没有角色映射就没有真正的"观点交锋"。

结语

OpenMAIC 的四种交互模式，本质是同一台导演图状态机在不同提示词约束、不同共享记忆组合下的四种运行姿态。教学意图决定模式，模式决定路由规则，而工程防护决定这套系统能不能在真实课堂上长时间稳定运行。对开发者而言，读懂 director-graph.ts 的单轮契约与 director-prompt.ts 的模式分叉，比记住任何"四种模式"的营销式命名都更有价值——因为前者是你能改的代码，后者只是别人替你总结的标签。

【免费下载链接】OpenMAICOpen Multi-Agent Interactive Classroom — Get an immersive, multi-agent learning experience in just one click项目地址: https://gitcode.com/GitHub_Trending/op/OpenMAIC