现在，我们有了两端收发、一份明确的消息格式、可以处理任意分块的接收器，以及能够关联原消息的阶段回执。
这已经是一个能运行的起点。它的不足也变得具体：消息丢了要靠人判断，重复可能留下两份，端点只有固定的甲乙，信任还依赖实验底座的角色约定。
不要因为听过某个技术名词，就立即把它装进系统。先从一次失败或新的用途提出要求：
| 下一条建设线 | 新问题 | 准备增加的能力 |
|---|---|---|
| 可靠性 R | 原消息或回执丢失，重复来了怎么办 | 超时、重试、去重与明确的处理语义 |
| 寻址 A | 从两个人扩展到多个接收者，经过谁 | 地址、名称对应、中继与转发规则 |
| 信任 T | 来源是谁，内容能否被改，谁能看 | 认证、完整性与保密，使用成熟机制 |
这些是下一阶段的建设目标，本轮尚未全部实现。三条线需要共享消息约定，汇合时还要检查：可靠性线接受的 ACK，是否来自认可的来源，是否经过正确路径返回，是否指向正确消息。
V1 可以在本版格式、固定端点与有限资源条件下还原消息，并把收到的有效回执关联到本地原消息。它没有承诺任意故障下必然送达，没有实现通用自动重试、重启后去重或真实业务“恰好一次”。
底座的角色邀请限制了哪个窗口能读取哪份本地状态；这不能替代现实系统中的身份注册、密钥管理或安全传输。把 from 写成一个名字，仍然不能独立证明那个人是谁。
两军问题也没有被编号和回执推翻。我们选择了能说明范围的有限保证，再用不同机制逐层扩展。
保留 V0 和 V1 的对照：V0 怎样回复，V1 新增了什么，哪些疑问仍然存在。交付自己的编解码实现、互操作结果、一条正常往返、一条未得到确认的路径，以及对这两条路径的解释。
再选择一个下一版需求，写下它会新增哪些状态和成本。例如，重试需要什么时候开始、什么时候停止、怎样识别同一消息；队列会占用资源，重复处理可能带来副作用。
这份小需求应能成为下一轮可运行改动的起点，而不是“以后把所有可靠性都做好”的愿望。
从一封信到一张网络，会出现更多层次。每一层都应有出场理由、可核对的证据和清楚的边界。
你不必一次知道所有协议。现在应当能沿着一封消息指出：它如何被表示、在哪一步等待、什么使它成为完整消息、回执又怎样成为一份有限证据。
如果未来系统说“已送达”，你已经知道可以继续问：哪一端收到了什么，谁给出的确认，这份确认允许我接下来做什么？