为什么说这才是"真正的"多 Agent 协作？
- 结构: 每个 Agent 都是独立实体，拥有自己的上下文、轨迹与状态;
- 隔离: 彼此无法直接访问对方的"内心活动";
- 依赖: 协作完全依赖三种通信机制——工具调用参数、共享文件系统、消息总线，详见 协作的两个设计维度;
多 Agent 系统与操作系统如何对应？
表10-2 多 Agent 系统与操作系统的对应关系
| 操作系统 | 多 Agent 系统 |
|---|
| 程序（可执行文件） | 静态前缀（系统提示词 + 工具定义） |
| 进程的内存 | 轨迹 |
| CPU | LLM |
| 内核 | Agent 运行时 |
| 系统调用 | 工具调用 |
| fork（创建子进程） | spawn_subagent |
| kill（发送信号） | cancel_subagent |
| ps（列出进程） | list_agents |
退出码与 wait() | 子 Agent 返回的结构化摘要 |
| 共享内存 / 消息传递 | 共享文件系统 / 消息 |
- 理论同源: 私有状态、异步消息、可创建新成员正是 1970 年代 Actor 模型的基本设定（Hewitt 等，IJCAI 1973）;
- 定位: 多 Agent 系统不妨看作 Actor 模型的 LLM 版本，因此操作系统与分布式系统的成熟经验大多可以直接借用;
进程式隔离带来哪些工程好处？
- 独立开发: 每个 Agent 可以独立开发和测试，新增能力不需要改动现有代码;
- 故障隔离: 某个 Agent 出了故障也不会把错误状态传染给其他 Agent（但语义级错误仍会传播，见 多 Agent 的失败模式）;
- 真并发: 多个 Agent 可以真正并发执行——上下文完全独立，不存在资源竞争;
不共享上下文的代价是什么？
- 信息同步: 各 Agent 如何对任务状态保持一致的理解，信息在传递中会不会丢失或重复;
- 调试: 出了问题需要翻看多个 Agent 的日志才能拼出完整执行过程;
- 推论: 接口规范、数据格式与通信协议的设计因此变得至关重要;
两套基础设施分别承担什么职责？
- 数据平面: 共享文件系统，作为 Agent 间交换产物、与用户交换文件的持久媒介;
- 控制平面: 通信与控制机制，支持消息传递、状态查询、执行终止与资源调度;
- 拓扑: 依据协作关系与控制流特征，不共享上下文的协作分为对等协作、管理者、去中心化三种架构;