技术 · 熟练
能通信，不等于能协作
纵向是下属，横向是同伴 —— 两者的信任模型不是一件事
「agent 之间能通信」这句话底下藏着两种完全不同的保证。一种是你（宿主）怎么知道一个能力服务提供了什么、怎么调用它 —— 这是纵向那一层；另一种是两个互不可见的 agent 之间怎么发现彼此、怎么交接任务与结果 —— 这是横向那一层。纵向那一层可以做得轻：无状态核心、显式发现、可缓存列表结果、多轮往返（长任务移进扩展）；横向那一层必须做得重：发现凭据、带生命周期的有状态任务、可在中途要求补输入。关键不在选哪个，而在知道它们各自不保证什么 —— 协议能让交换变得有规矩，但它不证明被发现的能力可信、不证明对面懂你的意图。
方法 · 一图看懂
1
先判每条连接属于哪一层 — 判据只有一条：对面有没有独立意图（宿主可控 = 纵向 · 自主不透明 = 横向）
2
纵向那一层查三件事 — 有没有显式发现 · 列表结果能不能缓存 · 长任务是否走扩展以免拖住主通道
3
横向那一层查四件事 — 发现凭据是什么 · 任务有没有生命周期 · 中途要补输入怎么办 · 数据与凭据的回收条件
4
给每条横向连接补「不保证清单」 — 不保证可信 / 不保证懂意图 / 不保证完成即目标状态，各写一句兜底动作
5
做一次断开实验 — 在测试环境里刻意触发超时 / 半成品 / 拒答，看你的编排走到哪一步才发现
原理 · 为什么有效
两层的差别是信任模型的差别，不是功能的差别。纵向那层里，能力服务是你的下属：宿主完全掌控调用时机、参数与结果，服务本身没有独立意图，所以协议可以做得轻 —— 无状态传输不要求应用无状态，工具返回一个显式句柄让模型跨调用携带即可。横向那层里，对面是一个自主且不透明的同伴：你看不见它的内部状态，它拿着你委派的数据与凭据去干活，返回一个你说不清怎么来的产物 —— 于是协议必须补上发现（自述的卡片 · 签名可选）、状态机（可进入要求补输入的中间态并在同标识下续跑）、以及结果流转。这正是设计者面对的现实：不透明性无法靠协议消除，只能靠流程管理。所以横向协议再完整，它保证的也只是「交换过程有规矩」。把两件事混成一件，就会出现两种典型误用 —— 该轻的地方背上了会话状态，该重的地方只剩一张自述卡片当信任锚。
适用场景
适用：你在决定「要不要再引入一个协议」· 已经在用工具协议、现在想加 agent 间协作 · 团队里有人把「能通信」当成「协作已解决」· 要做多 agent 编排的架构评审。
不适用：只有一个 agent 且只调本地工具（横向那层还不存在）· 纯提示词层面的编排（不涉及跨进程 / 跨组织）。
前提：你需要知道自己现在用的是哪一层、有几条横向委派。如果连「哪些动作跨了进程」都说不清，先做这一步，别急着比协议。
自测 · 5 问
我现在用的那套，是纵向还是横向？还是两者都在用？
如果对面那个 agent 明天换了一个实现，我这边的失败会出现在哪一步？
我有没有把「握手成功」当成「这个能力可信」？
我给了对面哪些数据与凭据？它们有没有回收条件？
当对面返回「完成」，我靠什么确认它就是我要的状态？
怎么上手 · 验证步骤
顺序是「先画现有连接面 → 再判每条该走哪一层 → 再定信任边界 → 最后做一次断开实验」。前两步是纸面工作（一小时级），第三步是补齐「发现 ≠ 可信」的处置规则，第四步最有价值：故意让对面超时或返回半成品，看你的编排走到哪一步才发现——只在纸面上假设「应该会失败」不算做过。
做完怎么自己对照检查：① 能不能一句话说清每一条委派走的是哪一层 ② 每条横向委派是否有超时 / 半成品 / 拒答三种分支的处置 ③ 信任锚是否被写清（自述、签名可选、需要额外验证什么）④ 断开实验是否真做过，以及它暴露出的第一个卡点在哪。