多 agent 协作
orchestrate 自动拆解复杂任务分阶段推进,collaborate 让多个 agent 来回对话直到收敛
dispatch 是把一个任务派给一个模型,broadcast 是把同一个任务同时派给多个模型。但有些活一发一收搞不定:要么任务太大、得先拆成几个阶段一步步来;要么需要几个 agent 互相看对方的产出、来回改到满意。这两种场景分别对应 Vyane 的两个工具——orchestrate 和 collaborate。
这两个是 MCP 工具,不是 CLI 命令
vyane_orchestrate 和 vyane_collaborate 目前只通过 MCP 调用(也就是 agent 在会话里直接调),没有对应的 uv run vyane 命令行子命令。broadcast 则两种入口都有。
设计精髓:协作不是"让几个模型同时跑"
"多个 agent 一起工作"听起来简单,但真正难的不是并行,而是让它们真的协作。Vyane 在两点上和"并行执行"划清界限:
- agent 之间直接通信 —— 通过持久化的消息队列,agent 能读到彼此说了什么、给对方反馈,你不用在中间当传话筒。消息还能跨会话读取、按时机投递(不一定立刻送,可以等对方当前任务收尾)。
- 协作拓扑可以声明 —— 不是只有"主从"或"对等"两种。中心协调、层级委派、流水线接力都能配;还有一种无协调者的"圆桌":所有 agent 只往一块共享看板读写,谁也不用点名找谁,靠看板上的痕迹异步协同。这类似蜂群 / 蚁群靠共同环境(而非互相指挥)来协调,所以即使 agent 多起来,也不会因为"谁跟谁说话"而卡死。
诚实的边界:关键决策留给人
Vyane 不假装 agent 能全自主搞定一切。冲突、优先级、价值判断这些,需要人来拍板。系统的职责是让整个协作过程可追踪、可审计、可回滚——而不是夸大 AI 能替你做所有决定。这是它区别于"全自动 agent 群"的地方:诚实,不吹。
先分清:broadcast、collaborate、orchestrate 有什么不同
三个都是"多模型",但组织方式完全不一样,别混:
| broadcast | collaborate | orchestrate | |
|---|---|---|---|
| 一句话 | 同一任务并发问多家 | 几个 agent 来回对话到收敛 | 把大任务拆成阶段分派 |
| agent 之间 | 互不知道对方 | 能看到对方的产出、互相反馈 | 按阶段前后依赖 |
| 轮次 | 一轮(各发各的) | 多轮迭代 | 多阶段(计划→执行→审查→合并) |
| 收尾 | 拿回所有结果,可选对比 | 跑到"收敛"或到轮数上限停 | 走完整个阶段生命周期 |
| 典型用途 | 找共识 / A/B 对照 / 交叉验证 | implement→review→revise、辩论、多视角综合 | 一个 phase 里多张开发卡并行落地 |
核心区别:有没有来回
broadcast 像同时给几个专家发同一封邮件,各自回一封,他们彼此不通气。collaborate 像把几个人拉进一个会议室,一个人先出方案,另一个当场挑刺,第一个再改,直到没人再有意见。"agent 之间会不会来回对话",是 collaborate 和 broadcast 最本质的分界。
collaborate:多 agent 多轮协作
vyane_collaborate 实现的是真正的 agent 之间协作(内部叫 A2A,Agent-to-Agent):agent 会读到对方前几轮说了什么,给出反馈,然后迭代,直到系统判定"收敛"或触达轮数 / 时间上限。
它跟 broadcast(一次并发)、跟旧的线性 workflow(固定管道)都不同——关键在于轮与轮之间会带着上下文往前滚。
内置协作模式(pattern)
调用时必须指定一个 pattern。当前内置三种:
| pattern | 干什么 | 角色构成 |
|---|---|---|
review | 实现 → 审查 → 修订 的循环 | implementer 出方案,reviewer 挑问题,reviser 只改被点到的问题,循环到审查方无阻塞性问题 |
consensus | 多视角并行分析 + 综合 | 三个分析师分别从工程 / 设计架构 / 安全可靠角度并行分析,再由 synthesizer 汇总成统一建议 |
debate | 对抗式辩论 + 裁决 | advocate 力挺、critic 力驳,来回一轮反驳后由 arbiter 给出 ADOPT / REJECT / MODIFY 的裁决 |
只有这三种,别记成别的
内置 pattern 就是 review、consensus、debate 三种,写在 a2a/patterns.py 里。传其他名字会直接返回 "Unknown pattern"。想在会话里列出可用模式,把 list_patterns 设为 true 即可。
每个 pattern 都自带默认的角色→模型分配(比如 review 里 implementer 默认走 codex、reviewer 默认走 claude),你不指定就用默认。
主要参数
以 MCP 调用为准:
task:这次协作的目标 / 任务描述(必填)。pattern:用哪种模式,review/consensus/debate(必填)。providers:可选的角色→模型映射,传 JSON 字符串。比如'{"implementer": "codex", "reviewer": "gemini"}'。留空就用 pattern 的默认分配。max_rounds:覆盖最大协作轮数。0(默认)= 用 pattern 自己的轮数(内部按"模式迭代数 × 每轮角色数"算)。timeout:整场协作的墙钟秒数上限,默认1800(半小时)。sandbox:所有 agent 的操作权限,read-only(默认)/write/full。list_patterns:设为 true 时不跑协作,直接返回可用模式清单。
什么时候算"收敛"
协作不是无限循环。每完成一轮,Vyane 会按下面的顺序判断该继续还是停(先命中的先决定):
- 硬上限——到了最大轮数、超了墙钟时间,或者连续 3 轮失败,直接收尾。
- 明确信号——agent 输出里写了
CONVERGED(或 LGTM / APPROVED / "no issues found")就判定完成;写了NEEDS_INPUT就停下等用户补充;审查方点出"blocking / critical 问题"则继续下一轮。 - 产出稳定——如果这一轮的产物内容跟上一轮完全一样(哈希没变),说明已经磨不动了,判定完成。
- LLM 裁判——前面都拿不准时,才请一个模型当裁判给 CONTINUE / COMPLETE / NEEDS_INPUT / FAILED。这一层贵,只在含糊时兜底用。
返回的是一份完整的协作记录:每一轮谁说了什么、最终产物、收敛原因。
orchestrate:把复杂任务拆成阶段编排
vyane_orchestrate 面向的是"一个 phase 里要落一批卡"这种规模的活:它先把任务 / 一批 issue 规划成结构化的阶段计划,再把开发卡分派下去、跟踪审查与合并状态。
它是一个带生命周期状态的编排器,通过 action 参数选当前要做哪一步:
| action | 作用 |
|---|---|
plan | 用一句任务描述生成初始计划 |
phase-plan | 拿一批 issue(issues_json)规划出一个阶段:选出哪些是开发卡、怎么排布(只做 dry-run,不落地) |
phase-materialize | 把上面的阶段计划真正落成可派发的任务卡(需要绑定 collaboration_template) |
assign | 给某张卡指定角色 / agent |
execute | 执行某个已存的任务 |
status | 查当前编排任务的状态 |
review / merge | 跟踪分支的审查与合并状态流转 |
拓扑(topology):这批卡怎么排布
phase-plan 时用 topology 决定阶段内部的组织方式,三选一:
parallel-team(默认)——多张开发卡并行推进,各自隔离,适合互不冲突的任务铺开干。star——中心汇聚式。pipeline——流水线式,前一段的产出喂给后一段。
配套参数:max_dev_teams 限制这个阶段最多开几张有写权限的开发卡(默认 4);collaboration_template 把任务卡绑到真实的执行 harness 候选上(比如 phase_delivery_team),phase-materialize 时必填。
一次编排大致怎么串
因为是带状态的编排器,一次完整编排是按 action 一步步推进的。作为 MCP 工具调用,顺序大致是:
vyane_orchestrate(action="plan", task="把 review 流水线搬到新引擎")
│ 生成初始计划
▼
vyane_orchestrate(action="phase-plan", issues_json=[...], topology="parallel-team")
│ 规划出一个阶段(dry-run,选出开发卡、怎么排)
▼
vyane_orchestrate(action="phase-materialize", collaboration_template="phase_delivery_team")
│ 把阶段计划落成可派发的任务卡
▼
vyane_orchestrate(action="execute", task_id="...") # 执行某张卡
vyane_orchestrate(action="status") # 随时查进度
vyane_orchestrate(action="review" / "merge") # 跟踪审查与合并前几步(plan / phase-plan)是只读规划,不会真派活;只有 phase-materialize 之后才落成真实任务、execute 才真正执行。这样你能在动手前先看清楚"这个阶段要开哪几张卡、怎么排"。
orchestrate 和 collaborate 的分工
简单记:collaborate 是"几个 agent 围着同一个任务反复磨",orchestrate 是"把一个大任务切成几块、分派给不同的人 / 阶段"。前者解决"一个活要不要多方参与打磨",后者解决"活太大得先拆再管"。