上下文共享与否分别意味着什么？
- 共享上下文: 后续 Agent 接收前一个 Agent 的完整对话历史与轨迹，每个阶段切换系统提示词与工具集后就成为新 Agent，但保留前任全部记忆;
- 共享上下文类比: 团队里需求分析师写完文档，开发者不只看文档，还能看到分析师与用户的所有沟通记录;
- 共享上下文优势: 信息不丢失，每个 Agent 都能回顾之前任何阶段的细节;
- 共享上下文代价: 上下文可能快速膨胀，且继承来的历史会干扰当前职责;
- 不共享上下文: 每个 Agent 维护完全独立的上下文与对话历史，彼此无法直接访问对方的"思考过程";
- 不共享上下文类比: 不同部门各自在工位上独立工作，通过共享文档与会议纪要交换信息，而不是时刻盯着别人的屏幕;
- 不共享上下文优势: 模块化与隔离性更好，每个 Agent 只关注与职责相关的信息，新增 Agent 无需改动现有内部逻辑，只需定义接口与数据格式;
- 不共享上下文代价: 必须通过显式通信机制传递信息;
不共享上下文时，Agent 之间如何传递信息？
- 理论源头: 操作系统教科书的进程间通信（IPC）只有两大范式——共享内存（一方写入、另一方读取同一块存储）与消息传递（把数据显式发送给对方）;
- 推论: Agent 间通信机制同样落在两个范式之内，常见实现有三种;
| 通信机制 | 对应 IPC 范式 | 适用场景 |
|---|
| 工具调用参数（下游 Agent 封装成工具） | 消息传递（随调用同步） | 需要类型确定、结构清晰的数据 |
| 共享文件系统（读写共享目录下的中间产物） | 共享内存 | 产物较大或需要持久化 |
| 消息总线（Message Bus，经中转站转发） | 消息传递（异步投递） | Agent 数量多、需异步并行与解耦 |
- Agent 不直接调用彼此，而是把消息发到消息总线，由总线转发给目标 Agent;
- Go 名言: "不要通过共享内存来通信，而要通过通信来共享内存"——两种范式各有取舍，不共享上下文时通常更倾向消息传递;
协作拓扑有哪三种典型形态？
- 对等协作模式（Peer Collaboration Pattern）: 少量 Agent 按固定拓扑形成迭代改进循环，如起草者与评论者反复多轮提高质量;
- 管理者模式（Orchestration Pattern）: 一个中心化 Manager Agent 负责任务规划与调度，多个子 Agent 各负责特定子任务;
- 去中心化模式（Decentralized Pattern）: 没有运行时的中心控制者，Agent 之间像人类一样互相沟通、协作完成任务;
- 选择依据: 子任务数量、依赖复杂度、是否需要动态调度、是否允许单点故障，见 对等协作模式、管理者模式、去中心化模式;
"协作拓扑"与 Graph 工程是什么关系？
- Graph 工程: 2026 年 7 月开始流行的说法，指显式设计执行图——节点是 Agent、普通程序或人工决策，边定义任务依赖、条件路由与失败后的去向，结构化状态在节点之间流动;
- 包含关系: 协作拓扑正是 Graph 工程中的多 Agent 子集，对等协作、管理者编排、去中心化移交都是不同的图拓扑;
- 上下文: 提示 ⊂ 上下文 ⊂ Harness ⊂ Loop ⊂ Graph 的层级关系见 Harness 工程;