YT 学习笔记

Pi to Pi 对等双向 agent 通信:让 agent 不靠编排器也能协作

24分钟阅读下载 MD

封面

IndyDevDan · 34:52 · 发布 2026-05-18 · 3.8万次观看(截至抓取) · 观看原视频

主旨

作者发布一组 Pi Coding Agent 扩展,把多个独立 agent 通过 Unix socket + BUN server 连成「对等、双向、可跨设备」的通信信道——不设主从,agent 之间互相 ping、互相 prompt、互相对账,用以替代 subagent 单向委派与单层编排器的局限,并用「prod→dev 复现 bug + PII 脱敏」与「e2b↔exe.dev 互相校对 feature parity」两个真实工程场景演示效果。

核心论点

  1. 当前主流多 agent 协作(subagent 委派、message queue、单层编排器)本质都是单向 top-down 流,真正的双向往来需要把 agent 当成对等 co-worker——后者把信息架构变成「扁平」而非「金字塔」,让最佳想法不必靠头衔升上去也能赢。(→ 详解1, 3)
  2. 跨设备、跨网络的 agent-to-agent 通信让「生产端不能泄露 PII」「开发端必须复现 bug」两类冲突需求自然解耦——prod 端做脱敏,dev 端拿到可调试切片,这种工作流是单 agent 内 prompt engineering 做不到的。(→ 详解2)
  3. 任何 A2A 协议都能归结成四个最小原语:list agents、send command、send prompt、await response——其他都是这四个动作的组合,够小、够原子才能跨设备跨工具复用。(→ 详解5)
  4. Context engineering 的硬核主张是「别等超大窗口,先把任务专精化到不同 agent」——Context Rot 让塞进同一个上下文的不同任务彼此污染,拆分后每个 agent 只扛一类工作,出错概率才会逼近零。(→ 详解4)
  5. 不同 SOTA 模型各有所长(GPT-5.5 详尽,Opus 4.7 目标导向),把它们组织成互相通信的 agent team 优于任一单干——这与「代码 + agent 强于任一单独」是同一原理在 agent 维度的展开。(→ 详解4)
  6. 扁平通信是 primitive,真正的 production 架构是按需混用 peer-to-peer 与 orchestrator——日常协作走对等,确实需要统一调度再切回编排模式,但前提是手上有可组合的 primitive。(→ 详解6)

知识点详解

1. Pi to Pi Agent Communication 01:05

开场用一个反问铺出整套主张:「什么比一个 GPT-5.5 Pi coding agent 更强?两个。但什么比两个并排却不互通的 GPT-5.5 更强?两个真正一起工作的 GPT-5.5。」作者把这套通信模式称作「flat agent hierarchy where the best information wins」01:05,并把视角推到四个 agent 同时在线、互相 ping 的画面——没有「编排器」也没有「worker」,所有节点都是 equals / co-workers。

作者解释这套模式的来源:在传统公司里最佳想法往往停留在工程师层级、传不到决策层;最好的信息架构是扁平的(Nvidia、startups 都是例子)。把同样的逻辑平移到 agent 系统里,就得到「让 agent 像同事那样互相 prompt,而不是层层下达」的 A2A 通信协议。

这片就是 Pi to Pi 扩展要做的事——给 Pi coding agent 加一组对外工具,让任何 Pi 实例都能在网络上找到同伴、把 prompt 发过去、再选择性地等响应,通信信道是双向扁平的。

2. Prod and Dev Multi-Agent Orchestration 02:24

第一个 demo 把生产端 Mac mini 上的 prod agent 与开发端 M5 MacBook Pro 上的 dev agent 用同一通信信道连起来。Mac mini 上的真实生产库有 Pro 用户被锁出付费功能的 bug,工程师要把受影响切片拿到本地复现,但 PII 不能离开生产机器。

解法由两个 agent 共同完成:prod agent 在生产端把数据做脱敏,只把去标识化的切片回给 dev agent;dev agent 在本地把数据导入干净的本地库供工程师调试。整个过程 prod agent 反复强调「It’s not going to expose any personal identifiable information」03:01,dev agent 则反复 await prod agent 的响应 ID03:56。

这套工作流的关键不是某一步多巧妙,而是它无法用单 agent 实现——生产端要永远守着数据( 最小权限 的物理隔离)、开发端要拿到可调试切片(可被工程师和工具读取),两件事天然分布在两台机器,只能靠 A2A 通信把两侧缝合起来。

3. Why Agent to Agent Communication Matters 04:56

作者把现存的多 agent 协作模式挨个点评:sub agent delegation(主 agent 派生短上下文子代理)是「非常好的起点,但只是起点」;message queue(典型如 Claude Code agent teams)是一对多分发;agent chain / pipeline 是「前一节点输出喂下一节点」的确定性流,可以插入 code 节点增强——但所有这些模式的信息都是「in basically one direction, and it’s always a top-down way」06:39。

他承认 one-agent-to-rule-them-all 的编排器很强大,但点出它的本质问题:best information is often times down here08:18。真实工程里最有价值的观察往往来自一线工程师或一线 agent,而层级化的指令结构会卡住这些信息上浮——「ideas die in hierarchies」09:55,这跟公司层级里好想法困在基层是同一回事。

解决方案很简单:让 agent 之间 prompt-response,再 prompt-response,peer-to-peer 而不是 orchestrator-to-worker。这解锁了「cross-device agent-to-agent communication」10:41——同一信道既能在本机多 agent 之间跑,也能跨机器、跨网络、跨地域跑。

4. e2b vs exe.dev Skills 12:33

第二个 demo 是更典型的工程任务:用户想给 exe.dev(新接触的 agent sandbox)造一个对等 e2b skill 的新 skill,但要保证 feature parity,而不是只写一份比较报告。做法是把 e2b skill agent 与 exe.dev skill agent 拉进同一通信池,e2b 端先整理出 feature inventory 文件,exe.dev 端据此逐项实现并反复 ping e2b 端校对。

这片的核心论点被夹在 demo 中段:作者明确反对「把所有东西塞进一个 agent、等模型窗口变大、再等它变强」的幻想,主张 specializing your agent to focus on one problem and one problem only15:50。观察到的现象是「a focused agent is a performant agent」16:18——对比 e2b agent 一旦塞进 exe.dev 文档,上下文立刻膨胀到 ~20% 的 1M 窗口(接近 200K tokens),就开始丢精度;而它只专注 e2b 时跑得又快又稳。

另一组对照观察是「GPT-5.5 vs Opus 4.7」:GPT-5.5 会反复穷尽 token 把结果写得非常详尽,Opus 4.7 更目标导向。作者强调「it depends on the model」08:15——不同 SOTA 模型对同一任务的处理风格差异巨大,把多个模型叠成互相通信的 team 之后,「agent plus code beats either alone」26:29 的结论就被复制到模型维度:多 SOTA agent 协作 > 任一单模型。这是 模型分散 在 agent 协作层的具体表达,也是 Agent 反思(自评自纠) 在两个独立 model 之间的工程化——一个 agent 反复对账另一个 agent 的声明,本身就是反思模式的并发版本。

5. Pi to Pi Tools and Codebase Breakdown 21:39

作者把整套通信机制拆到工具级,核心其实只有四个动作:21:42「list all the agents on the network」、「send command」、「send prompt」、可选的「await response」。有时只是单向投递(像发 Slack 确认信息),有时需要 block wait 或 non-blocking poll 拿到对端回应。整套 API 与协议无关、与工具无关、与模型无关。

这套工具落到 Pi 上就是两个 extension:comms(单设备版本,让本机多个 Pi 实例互通)与 comms net(网络版本,在 BUN server + Unix socket 上接收跨设备的连接请求,提供 connect、get messages、list agents、process events 等最小操作集)。两个 extension 都已 push 到 pi-vs-claude-code 仓库——这是作者长期维护的「对标 Claude Code、拿回 agent harness 控制权」的代码集。

工程模式上这是「primitive over composition」:先把通信做成最小原子,再往里塞 orchestrator、塞 verifier、塞任何上层抽象;反之先造一个庞然大物再去解耦几乎不可能。两个扩展加起来不到 200 行核心代码,作者原话是「every piece of code you see now, I really think it’s really about read and adapt」——读懂、改成自己的版本、加进 harness,这是比「拿来即用」更现实的态度。

6. Pros and Cons of Pi to Pi Agent Communication 27:42

收尾平铺优劣。Pro 端最重的一条是「just an agent」30:12——任何 Pi 实例,装上扩展,就能连进同一通信池成为对等节点,既没有 subagent 的 spin-up/spin-down 生命周期,也没有 resume flag 之类的副作用。它 end-to-end、可定制、可永久存在;而 Pi 自身作为可被改写的 agent harness 提供了底层自由度,这一点 Claude Code / Codex / Gemini CLI 等「出租式 harness」都给不了。

第二条 Pro 是双向扁平、无信息丢失——这是「any agent can prompt any agent」27:57 的具体含义,与 one-agent-to-rule-them-all 编排器形成对比。第三条 Pro 是「primitive over composition」——先把通信做成最小原子,再往上组合任何上层模式,符合「primitives into compositions」30:34 的工程惯例。

Con 端则有四条:第一,需要自己写/审/控制 prompt 与 edge cases(「the edge cases is where really where great agentic engineering patterns are made」30:57);第二,「loops are possible if prompts are sloppy」31:06——bad loop 会把 token 预算烧光,必须给每个交互设明确 end state;第三,成本随 agent 数与「通信往返」线性增长,作者顺带提到「Dunbar’s number 之类的最佳团队规模」31:48 是另一个参考维度但不必太执念;第四,要小心「滑回 orchestrator 模式」的诱惑,真要统一调度就明确切回去,不要在 peer-to-peer 框架里硬塞层级关系。

作者把这一组合定位为「scale your compute to scale your impact」17:15 的最新落点,与 forward-goal 的工程化方向一致:把 harness 做扎实,把 agent 编排做出 primitive,再让规模自然滚出来。

可执行步骤

  • 把 agent-to-agent 通信抽象成 4 件套(list / send command / send prompt / await response),任何上层编排都建在这 4 件套之上,而不是先造大框架再去解耦。
  • 评估多 agent 方案时,先问「能不能跨设备通信?能不能保持 PII 在生产端不被外泄?」——能的话再考虑具体编排模式。
  • 把单 agent 内的多任务拆成多 agent 各专精一件事,观察上下文窗口占用与出错率是否同步下降,作为 context engineering 的可验证判据。
  • 给 agent-to-agent prompt 明确写出 end state 与「不要继续对话」的退出条件,避免 bad loop 把 token 预算烧光。
  • 把 peer-to-peer 通信代码放在能 fork 改写的仓库(如作者推荐的 pi-vs-claude-code),按需加鉴权/超时/重试,而不是直接照搬。

关联

  • 印证:2026-07-06-CMUX实测终端复用器解决多智能体编排三大痛点 给出的「scale compute to scale impact」「orchestrator-lead-worker 通信信道也是扁平的」两条主张,与本片「peer-to-peer 优于 orchestrator」是同一判断的不同切面——CMUX 走终端复用器,本片走 Unix socket + BUN server,两者殊途同归,先读本片再看 CMUX 可补完终端层的可编程访问。

  • 印证:2026-06-15-Fable5被禁：首个工程师不需要的模型与Agentic工程新算账方式 主张的「用 Fable 5 当 orchestrator/principal engineer」与本片的「扁平优于层级」看似冲突,实则互补——Fable 5 处理需要统一调度的复杂任务,本片的对等通信覆盖日常协作场景;两者都强调按任务复杂度反推架构,而不是默认「越集中越好」。

  • 冲突/更新:组织层级过深(见CC高阶课·组织层级)主张 AI 系统的多层公司式层级几乎都是冗余;本片更进一步给出替代方案——peer-to-peer + 4 件套 primitive,通信成本低、上下文专精,可以从架构上消除大多数层级。判定变量:若工作真的需要全局视野(如跨 sandbox 编排),仍走 orchestrator;若只是常规 agent 间协作,走 peer-to-peer,层级只在明确必要时才被启用。

  • 进阶:11-v9-Agent-Team 给出 Pi 的中央调度式 agent team(YAML 配置 + primary agent 当 dispatcher),先读那篇可以理解 Pi 内多 agent 的「中心化」基线,再读本片就看到「去中心化」版本的工程实现;两者共同构成 Pi 平台多 agent 协作的两套正交方案。

  • 互补:Subagent 提供「主 agent 派生短上下文子代理」的并行化单元,Agent Teams 提供共享 task list 的中央调度,Orchestrator(编排器) 是动态路由角色——本片的对等通信不替代这些,而是把它们都放进通信信道里的节点;先掌握那些再去理解本片的「对等 + 跨设备」维度会更顺。

  • 冲突/更新:Claude Code 任务系统 走中心化任务系统(Builder-Validator pattern + 共享 task list + Task Update 解锁),本片走去中心化 Peer-to-peer Agent 通信;判定变量:任务需全局调度/依赖编排时用中心任务系统,只是常规 agent 间协作用对等通信。

一手来源与延伸

术语

  • peer-to-peer agents(对等 agent:同一通信信道中所有节点角色相同,无 orchestrator/worker 之分,可互相 prompt、互相 await)
  • flat agent hierarchy(扁平 agent 层级:多 agent 系统的拓扑选择,信息流不走单向汇报链,所有节点既收也发)
  • A2A 四件套 / four-tool A2A primitive(任何 agent-to-agent 协议的最小集合:list agents、send command、send prompt、await response)
  • cross-device agent communication(跨设备 agent 通信:同一通信信道在本机/局域网/广域网上跑同一套协议,无需为不同部署形态分别写)
  • verifier agent(核对 agent:独立于主 agent 之外、专门反复校验主 agent 输出声明与实际行为的 agent 角色,被两个 demo 隐式使用)
  • feature parity document(特性对等文档:在两个服务/工具之间做迁移或镜像时,先列一份逐项功能对照表,再据此逐项实现)
  • context engineering(上下文工程:不只是把对的资料塞进上下文,而是只塞刚好够用的资料,避免不同任务在同上下文内互相污染)

金句

“best information wins” → 把 peer-to-peer 优于层级的核心主张收成四个字,放在视频开篇反复强调,是后续整套工程论证的纲领。01:09 “A focused agent is a performant agent” → context engineering 的可验证口号,直接驳斥「等模型窗口变大就够用」的偷懒思路,也是把多任务拆到多 agent 的最直接理由。16:18 “It’s teamwork” → 把跨 agent 校验、对账、回写的过程定性为「协作」而非「调度」,配合「agents checking in on each other」「double-checking the work」26:53 的具体观察,把「协作」具体落到每次 ping 的语义里。27:11

立场与利益

视频 description 末尾附有作者课程链接 agenticengineer.com/tactical-agentic-coding?y=PIdETjcXNIk,带 ?y=<video_id> 后缀——这是作者「按视频归因」式的引流参数,因此「Pi coding agent 是 real claude code alternative」「scale compute to scale impact」「peer-to-peer 是 multi-agent 编排的下一阶段」与课程卖点天然耦合,主张可信但同时带有引导观看的成分。本片未见明显利益反向(承认短板/劝退)的表态,故不单列该档。

价值定位

适合已经在用 Claude Code / Pi / Codex 等 CLI agent、并考虑把工作流扩到跨设备、跨服务、或需要 PII 安全隔离的实操者:视频给出的是「4 件套 + comms/comms net 两个 extension + prod/dev 与 e2b/exe.dev 两组真实 demo」的可复制样板,认知增量集中在「为什么 peer-to-peer 优于单层编排」,而非 4 件套的 API 细节。

重叠内容方面,与本频道 2026-07-06-CMUX实测终端复用器解决多智能体编排三大痛点 在「多 agent 通信 + 扁平拓扑」上一致,本片独有增量为「跨设备 + PII 隔离 + 4 件套 primitive」三层;与 11-v9-Agent-Team 在「Pi 平台多 agent 协作」上互为正交(中心化 vs 对等),先读任一篇再读本片可形成完整视角。

自检问题

  1. 作者把现有三种多 agent 协作模式(subagent delegation、message queue、agent chain)都归到同一个本质问题,这个问题是什么?为什么作者认为 peer-to-peer 是解决方案? 答案:三者本质都是「information travels in basically one direction, top-down way」的单向流,即便回传也是 one-way stream。peer-to-peer 让 agent 之间直接 prompt-response,解锁 bidirectional flows of information,best information 就不再卡在 worker 层级上不去。见详解3 04:56 06:39
  2. prod→dev demo 中,为什么不能用一个 agent 同时跑生产端和开发端两件事?peer-to-peer 在这里解决了什么关键问题? 答案:PII 不能离开生产机器,生产端的脱敏与开发端的可调试切片是物理上分布在两台机器的两件事,必须由两个 agent 各司其职。peer-to-peer 让 prod agent 守住数据、做 redactions,dev agent 拿切片、本地复现,两个 agent 之间用 A2A 协议来回同步——这是单 agent prompt engineering 做不到的工作流。见详解2 02:24 03:50
  3. 「focused agent is a performant agent」这条 context engineering 主主张,在 e2b↔exe.dev demo 中是如何被具体印证的? 答案:e2b agent 一旦被要求同时吃下 exe.dev 文档并实现 feature parity,上下文立刻膨胀到约 20% 的 1M 窗口(~200K tokens),开始丢精度;让两个 agent 各专注一个服务后,每个 agent 都只扛一类工作,出错率显著下降。作者借此反对「把所有东西塞进一个 agent、等窗口变大」的偷懒思路。见详解4 12:33 16:18
  4. 任何 A2A 协议的最小原语被作者归结为哪四个动作?为什么作者强调「够小才能复用」? 答案:list agents、send command、send prompt、await response 四件套。够小够原子才能跨设备、跨工具、跨模型复用,也能往上组合出 orchestrator、verifier 等任何上层抽象;反之先造庞然大物再去解耦几乎不可能,这与作者提的「primitives into compositions」工程惯例一致。见详解5 21:39 21:42 30:34
  5. peer-to-peer 模式被点名的最大隐患是什么?作者给的防御措施是哪两条? 答案:最大隐患是「loops are possible if prompts are sloppy」——bad loop 会把 token 预算烧光。防御措施是:为每段 agent 交互明确写出 end state 与退出条件,并按需切回 orchestrator 模式避免在 peer-to-peer 框架内硬塞层级关系。见详解6 27:42 31:06

关系图谱

反向链接