Peer-to-Peer Agents

上下文视角：上下文在平级 Agent 之间双向流动——不再是单向注入，而是互相交换，形成动态的共享认知。

上一节讲了人类作为上下文的最终仲裁者。即便进入多 Agent 协作，这一点不变——但上下文的流动方式会变得更复杂。

层级式 vs 平级式

在 Sub Agent 的世界里，关系是层级结构：主 Agent 是将军，Sub Agent 是士兵。将军发令，士兵执行，然后汇报。上下文单向流动，清晰可控。

P2P 模型打破层级。多个 Agent 平级协作，没有绝对的指挥者，只有围绕共同目标的多视角碰撞：

前端 Agent："我需要一个 /users/{id} 接口。"
后端 Agent："直接暴露数字 ID 有遍历攻击风险，改 UUID。而且单条查询在列表页会 N+1，不如提供批量接口。"
测试 Agent："收到，我根据新方案先写两个集成测试锁定行为。"

关键区别：Agent A 的输出不是返回给"上级"，而是直接进入 Agent B 的上下文。B 的推理结果又回到 A。上下文在对等体之间互相交换、互相构建。

为什么绝大多数工具选择层级式

答案：协调开销。

N 个 Agent 的团队，潜在通信渠道是 N × (N-1) / 2。3 个 Agent 是 3 条信道，5 个就是 10 条，10 个是 45 条。协调成本呈二次增长（quadratic, O(n²)），不是线性的。

而且实际运行中通信类型远不止 A ↔ B 一种。peer 之间的直接对话、协调者广播、共享任务状态——两个 Agent 就有这么多信道。消息模型通常是 fire-and-forget：发出不等 ACK，接收方已关闭也不报错。你不能假设每条消息都被处理了。

具体的代价：

错误 cascade：一个 Agent 幻觉了，错误结论通过消息链污染整个协作网络
Debug 极难：最终结果出错时，定位"是哪个 Agent 的哪个决策出了问题"是分布式系统的经典难题
Token 成本翻倍：每个 Agent 独立计费，通信本身也消耗 token
时序竞争：每个 Agent 有独立的处理节奏，消息到达和处理不同步——分布式系统的经典难题，主角换成了 LLM

层级委派模型简单、可控、经济。对绝大多数日常开发任务，它已经够用。

截至目前，严格意义上支持 Agent 间双向消息的产品屈指可数。这里说的不是 orchestrator → worker 的单向委派，而是 agent A 直接给 agent B 发消息、B 可以回复甚至挑战 A。

大部分产品——包括许多标榜"多 Agent"的工具——实际上是并行执行（各干各的不互相通信）或层级委派（上级指挥下级）。从"并行执行"到"团队协作"这一步，比想象中难得多。

什么任务值得平级协作

P2P 不是默认选择。默认仍然是层级式或单 Agent。

快速否决条件：如果任务可以独立拆解为子任务，且每个子任务有明确的完成标准——不需要 P2P。 用 Sub Agent 就够了。

P2P 只在以下条件同时满足时才值得考虑：

任务无法清晰拆解：子任务之间有深度依赖，一个决策会连锁影响其他部分
需要多领域知识融合：比如"设计一个兼顾用户体验、技术可行性和商业目标的注册流程"——需要产品、设计、工程三个视角共同商议
目标是探索性的：没有唯一正确答案，多个 Agent 从不同角度头脑风暴、互相激发，比单 Agent 线性思考更有效

P2P 的威力在于视角碰撞和集体智慧，不是简单的并行执行。

上下文的双向流动

来看 P2P 协作中，上下文具体怎么流动。

── 第 1 轮：Agent A 发起 ──

Agent A（前端专家）提出需求：

json

// → REQUEST (Agent A → LLM API)
{
  "system": "你是前端专家，关注用户体验和接口设计...",
  "messages": [
    { "role": "user", "content": "我需要一个获取用户信息的 API，最好是 /users/{id}，返回 JSON。" }
  ]
}

json

// ← RESPONSE (LLM API → Agent A，SSE 流)
{
  "role": "assistant",
  "content": "建议接口设计：GET /users/{id}，返回 { id, name, email, avatar }。需要后端确认字段可用性和性能影响。"
}

P2P 框架捕获 Agent A 的输出，传递给 Agent B。

── 第 2 轮：Agent B 挑战 ──

Agent B（后端专家）的上下文中现在包含了 Agent A 的提议。注意 messages 比第 1 轮更长——因为 Agent A 的输出已经被注入：

json

// → REQUEST (Agent B → LLM API)
{
  "system": "你是后端专家，关注性能、安全和数据库设计...",
  "messages": [
    { "role": "user", "content": "协作上下文：前端专家提议 GET /users/{id}，返回 { id, name, email, avatar }。请从后端角度评估此方案。" },
    { "role": "assistant", "content": "收到，我来分析这个接口设计..." },
    { "role": "assistant", "content": "发现两个问题：1) 暴露数字 ID 有遍历攻击风险 2) 单条查询在列表页会 N+1。建议改用 UUID + 批量接口。" }
  ]
}

json

// ← RESPONSE (LLM API → Agent B，SSE 流)
{
  "role": "assistant",
  "content": "直接暴露数字 ID 有安全风险（遍历攻击）。建议：1) 使用 UUID 替代自增 ID；2) 提供批量接口 GET /users?ids=uuid1,uuid2 解决 N+1 问题。这需要前端调整调用方式。"
}

Agent B 的响应又被框架送回 Agent A 的上下文，形成闭环。每一轮交换，共享认知都在变得更丰富、更准确。

现实比这两轮干净的交互更混乱。A 发了方案，B 可能在处理别的消息没看到。A 不知道 B 是没收到还是在想，又催了一次。B 终于回了，A 正在处理另一条消息——两个 Agent 就能互相催成一团。这不是 bug，是 P2P 的固有特征：每个 Agent 有独立的 context window 和处理节奏，时序竞争在所难免。

这是前沿

坦率说，P2P Agent 协作是公认的前沿方向，但生态远未成熟。目前支持真正 peer messaging 的工具极少，大多数框架（如 AutoGen、MetaGPT）面向的是"构建 Agent 的人"，不是"使用 Agent 工具的人"。

对你来说，理解 P2P 的工作方式有一个实际价值：当你遇到真正需要多视角碰撞的复杂问题时，你可以手动扮演多个角色与 Agent 对话——"如果你是后端工程师，你会怎么评价这个接口设计？"——其实就是在模拟 P2P 协作。

本节小结

上下文流动：从单向（层级）到双向（平级），上下文不再是"注入→产出"的线性路径，而是在对等体之间网状交换。每个 Agent 的输出都同时是其他 Agent 的输入。
风险：协调开销呈二次增长（O(n²)）。一个 Agent 的幻觉会通过消息链 cascade 到其他 Agent，导致集体跑偏。在复杂的交互历史中做根因分析极难——分布式系统的经典痛点。
可审计性：Agent 之间的所有消息必须可追溯、可重放——但完全可见意味着把所有通信灌入协调者的 context window，成本太高。多数实现选择折中：传递摘要而非全文。

这是教程的最后一个概念节点。

回到第一原则：上下文的质量决定输出的质量。 从第一节到这一节，我们看到了上下文从静态规则（System Instructions）到动态工具调用，从单 Agent 的线性累积到 Sub Agent 的隔离与摘要，再到 P2P 的网状交换——载体在变，流动方式在变，但这条原则始终不变。

你理解了上下文怎么流动，就理解了 Agent 怎么工作。剩下的，就是用起来。

Peer-to-Peer Agents ​

层级式 vs 平级式 ​

为什么绝大多数工具选择层级式 ​

什么任务值得平级协作 ​

上下文的双向流动 ​

这是前沿 ​

本节小结 ​

Peer-to-Peer Agents

层级式 vs 平级式

为什么绝大多数工具选择层级式

什么任务值得平级协作

上下文的双向流动

这是前沿

本节小结