协作模型 · Miraptor Docs

共享上下文协作：角色转换

共享上下文的协作里，每个阶段都是一个独立 agent（有自己的系统提示词和工具集），但它继承了前序 agent 的完整轨迹——像接班的同事翻阅前任留下的全部工作日志。核心优势是信息零损耗，每个 agent 都能回顾之前任何阶段的细节；挑战则在于如何让当前 agent 专注于自己的核心职责，而不被继承来的大量历史信息干扰。

多阶段角色转换是一种工作流式编排——执行路径（例如需求澄清 → 实现 → 审查）预先定义。从进程角度看更清楚：这是同一个进程依次执行不同阶段的代码，换的是代码段、内存自始至终是同一份，并非多进程，所以“不算真正的多 Agent”的观点有其道理。仍把它纳入多 Agent 框架，是因为有切实的设计收益：当各阶段的系统提示词、工具集、关注点都不同时，把各阶段看作共享同一段轨迹的多个 agent，每个“身份”的提示词和工具集可以独立打磨，阶段边界也天然成为质量门控点。做法是根据当前阶段动态切换系统提示词和工具集——不创建新实例、只在同一会话中更新上下文；角色切换了，但对话历史和任务状态始终连续共享，agent 在新角色下仍能访问之前阶段积累的所有信息。

跨领域角色转换更进一步：不再是预先规划好的线性流程，而是 agent 根据用户需求的变化，自主判断应该切换到哪个专业角色。同样共享一段对话历史，后一个角色天然知道前面已经做了什么。

相比之下，不共享上下文才代表真正的多 Agent 协作：每个 agent 是独立实体，有自己的上下文、轨迹和状态，协作完全依赖显式的结构化数据传递。

多 Agent 系统就是一套操作系统

分类与判据把通信对应到 IPC、把上下文共享对应到线程/进程。这个类比可以走得更远：

操作系统	多 Agent 系统
程序（可执行文件）	静态前缀（系统提示词 + 工具定义）
进程的内存	轨迹
CPU	LLM
fork / kill / ps	spawn_subagent / cancel_subagent / list_agents
共享内存 / 消息传递	共享文件系统 / 消息

程序是静态代码、进程是一次运行；同样，静态前缀决定 agent 是谁、轨迹记录它走到哪。LLM 扮演 CPU——自身不保存状态，靠加载不同上下文分时服务许多 agent。换一颗更快的 CPU 程序照常运行；换一个更强的模型，agent 还是原来那个 agent——它的身份和记忆在前缀与轨迹里，不在权重里。 这套抽象正是 1970 年代 Actor 模型的 LLM 版，操作系统与分布式系统的成熟经验大多可直接借用。唯一失效之处：进程间传递字节、逐位保真；agent 间传递语义、每次转述都可能失真——这是“失败模式”要专门处理的新问题。

数据平面：Agent 眼中的虚拟文件系统

不共享上下文的协作靠两套与拓扑无关的基础设施。数据平面是共享文件系统——实际是一个虚拟文件系统，来源、生命周期、权限各异的存储挂载到同一目录树，agent 通过统一的 read_file/write_file 访问。默认隔离、共享须显式声明，通常四类区域：Agent 专属工作区（私有 scratchpad，随实例销毁，隔离试错、保持主上下文精简）、多 Agent 共享空间（协作 agent + 用户可见，随任务持久，并发冲突高发处）、外部挂载资源（Google Drive/Notion 经适配器映射为挂载点，受外部权限约束、最终一致性、以只读为主）、系统内置资源（Skills 等只读共享、跨会话稳定）。“文件路径作为通用接口”是这套设计的价值：agent 间交接产物传的是轻量路径字符串，而非把内容载入上下文。

控制平面：消息、状态、终止、调度

控制平面有四项常被忽略的能力。消息传递：点对点适合少量固定拓扑，数量增多且需异步并行时改用消息总线（发布/订阅，发送方无需知晓消费者），消息带结构化信封（发送者/目标/类型/负载）以便路由与追溯。状态查询：拉取式 get_status 用处远小于预期（子 agent 一创建就跑到完成，不像批处理作业在排队状态间流转），更自然的是两大范式——用消息问答/主动汇报，或用共享文件系统的轨迹持久化（子 agent 把轨迹实时写成 JSONL，主 agent 直接读=读另一进程的内存，最细粒度但费 token；更常用约定进度文件 progress.md，还附带靠“最后修改时间”做卡住检测）。轨迹持久化的深意是：轨迹即 agent 的全部状态——把它实时持久化等于随时握有检查点，崩溃/断电/关会话后重放轨迹 + 静态前缀即可恢复，与数据库的预写日志（WAL）是同一思想；子 agent 因此天然可恢复、可审计、可移交。执行终止：优雅终止（安全点响应、清理资源、返回 ack）为首选，强制终止为兜底；终止沿创建关系级联（借鉴 Go 的 context——取消一个 agent，其派生的子 agent 随之取消，杜绝孤儿）。资源与调度：token、资金、并发额度是 agent 世界的稀缺资源，落在 Manager 或运行时——设步数/token 预算、按难度选模型、并发上限、抢占。

三种拓扑

对等协作（2-3 个平等 agent 迭代改进）最经典的用途是治一类极常见的失败——过早终止（偷懒式假完成 / 过早放弃 / 假成功），三者的根源都是“验证之前，‘完成’只是模型的一句宣称，不是证明”。把宣称变成证明正是 Loop 工程的课题：由验证器而非模型自己判定“是否真的可以停”，业界共识是“循环的瓶颈在验证器，而不在模型”。承担验证的正是提议者-审核者范式。为什么不能一个 agent 自己生成再自己审查？因为审查若不引入新信息，就只是“让模型再想一遍”——研究证实纯自我纠正几乎无效（GPT-4 把对的改错比把错的改对更多），Reviewer 的价值来自它能接触 Proposer 生成时不具备的新信息（测试结果、渲染截图、编译错误、外部搜索）。其他对等形态：Debate（辩论，但等思考预算下常与单 agent 持平——多个 agent 处理同一段文本，串行传递中间结论只会丢信息、不会凭空创造，此论证不否定多次独立采样聚合或生成-验证不对称）、Brainstorm、Panel。

管理者模式（5+ 子任务、需动态调度、复杂依赖）把每个专门 agent 建模为 Manager 可调用的工具——“调用 agent 和调用普通工具没有本质区别”，带来可扩展性与异构性。两个要点：子 agent 应返回结构化摘要而非全量轨迹（否则 Manager 上下文爆炸）；Plan-and-Act 证明弱规划者是最关键的瓶颈——最强的模型和最精心的提示词应给规划者（这与 Ch4“审查者需能力相近”不冲突：那说的是审查场景，这说的是规划-执行分工）。

去中心化模式（无运行时中心控制者，控制权像接力棒流转）动机是模拟人类组织的分工制衡，微服务称之为编舞（choreography）对编排（orchestration）。不共享上下文下移交要显式决定传什么——移交包 = 任务描述 + 已确认的事实与约束 + 结构化产物的引用，刻意不传全量轨迹。三个案例由伪到真：MetaGPT（SOP 固定流水线，但共享消息池 + 按角色订阅的解耦通信是亮点）、AutoGen group chat（共享对话记录 + 中心化调度的混合形态，风险是活锁）、OpenAI Swarm（每个 agent 配 handoff 选项、真正的对等移交，风险是成环需移交次数上限）。

跨组织协作：A2A

以上都假设 agent 同属一个团队。跨组织时需要标准化互操作协议——A2A 之于 agent，就是 TCP/IP、DNS 之于进程。三要素:Agent Card（能力元数据名片，解决跨组织发现）、任务生命周期管理（Task 状态机:已提交/进行中/需要输入/已完成/失败，原生支持长任务与流式进度）、不透明协作（只交换任务与产物 Artifact，不暴露内部提示词与实现）。A2A 与 MCP 对照:MCP 解决 agent↔工具互操作，A2A 解决 agent↔agent；它不取代团队内的消息总线，只在跨信任边界时才需要。

失败模式

多 Agent 引入了单 agent 不存在的新型失败。分布式容错把故障分两类:崩溃故障（停止工作）与拜占庭故障（不停工作但给错误信息）——agent 的故障天生是拜占庭式的:它很少径直停止，而是继续给出看似可信的错误结论，且不会主动声明自己错了。这解释了为什么修补单环节收效甚微——只能靠独立冗余去发现；确定性外部反馈（测试、编译器、数据库查询）之所以珍贵，是因为它是系统里唯一不会说谎的部件。两种最常见的:

共享文件系统的并发冲突:简单冲突（丢失更新）用乐观锁（读时记版本号、写时检查是否被改）;但多个 Coding Agent 改同一代码库更主流的是工作副本隔离（各自 Git 分支/worktree 并行、冲突推迟到合并点）——与“隔离优于压缩”同源。语义冲突（文件层面无冲突但逻辑矛盾，如图片重编号使引用失效）需要更高层的一致性校验。
错误的级联放大:一个错误经多个 agent 逐层强化（传话游戏），因“一致性”反而获得更高可信度。交叉验证是断链关键——让某 agent 以独立视角只看原始证据和最终结论、不看前序思考过程；确定性外部工具是最可靠的“断链器”。过早终止的对称反面是循环失控(token 成本失控 / 理解债 / 认知投降)——解药同样是显式预算与终止条件、扎根真实观测的验证器、人始终是“循环的工程师”。

工程实践

Zapvol 的多 Agent 落在这两个平面上:控制平面是 Agent Team 协调模型——以 mailbox 为中心的消息传递（对应本页的消息总线 + 信封），Agent Team 实现提供成员间通信与共享任务列表;数据平面是子代理的共享工作区（对应“多 Agent 共享空间”,交付 artifacts 传路径而非内容）。子代理走的正是不共享上下文的隔离路线——在自己的上下文里探索、只回传结构化摘要（对应“子 agent 返回摘要而非全量轨迹”,也是隔离优于压缩）。何时用 task（隔离子代理）、何时用 team（对等协作）的边界判断见委派模式。崩溃可恢复则由压缩的只追加记录兑现——正是本页“轨迹即状态、WAL 可重放”的落地。