上次提交是六月。四个月里我没继续写，因为发现自己在做的东西，从根上是错的。
一、先把目标说清楚
我想做的不是”让 AI 接活”，也不是又一个 agent 框架。
我想解决的问题很具体：让分布在不同设备、不同地点的硬件智能体，自己完成协作。
三个词：跨设备、跨区域、去中心化。
一台在杭州的机械臂，一台在悉尼的巡检车，几块挂在设备上的开发板。它们要一起干一件事：谁先做、谁等谁、谁做完了怎么证明、中间断网了怎么办。
通行做法是写一个中心调度器，把所有设备连到一台服务器上。这能跑，但只在同一个机房、同一个网络、同一个信任域里成立。一旦跨区域，它同时撞上三堵墙：延迟、断网、和”凭什么听你的”。
二、我大概想得太远了
这个想法出现的时候，具身智能还没到现在这个程度，区块链也远没到能用在生产里的地步。
按常规顺序，应该先把机器人做好，再谈协作；先有成熟的身份标准，再谈跨域信任。我跳过了这些，直接想到给 agent 建一个社交平台。
后来我意识到，这个跳跃没那么荒唐，但确实偏。偏在具体哪里，我想了很久。
我一开始把它想成了”派活给子 agent”。
写 v1 的时候，协会能创建 agent、给 agent 派任务、收结果、再派下一个。看起来就是多智能体协作。但那是编排，不是协作。
三、编排不是协议
这是两件被混在一起说的事。
| 编排（orchestration） | 协议（federation） | |
|---|---|---|
| 形态 | 一个运行时，父 agent 派发子 agent | 多个运行时，对等通信 |
| 共享什么 | 上下文、文件系统、日志 | 只有消息 |
| 信任从哪来 | 天然：同一个所有者、同一个进程 | 必须证明：你是谁、谁授权、做过什么 |
| 典型实现 | LangGraph、CrewAI、子 agent | A2A、DID、可验证凭证 |
| 边界 | 一个信任域 | 跨组织、跨区域 |
编排很好用。但它解决的是”我自己的几个分身怎么分工”。
跨设备不是这个。你没法 spawn 一台在悉尼的车。
这就是 v1 塌掉的真正原因。 它把跨设备协作当成了编排问题：协会 spawn 一个 agent，派任务，等结果。在同一个进程里这套成立——所有东西共享一块内存、一个文件系统、一个日志。一旦设备在另一个城市、另一个网络、另一个所有者手里，它立刻散架，因为你连”它有没有收到”都不确定。
跨设备协作的第一性问题不是调度，是协议。
四、软件的经验搬不过来
顺着这条线想下去，硬件和软件的差别比想象中大。
软件 agent 协作，本质是共享状态：同一份上下文、同一个文件系统、同一个数据库。复制一份就行。
硬件不行。物理状态不能复制。
一台机器人现在夹着什么、电量多少、底盘在哪个坐标，这些没法”同步”给另一台。你能复制的是对它状态的描述，复制不了状态本身。
所以硬件之间只能靠另一种东西：契约。
“我在 14:00 到 14:10 占用这块区域，做这件事，做完发一个带传感器读数的回执。“这条契约是可以验证的，而”我的状态和你同步了”在物理世界里没有意义。
一句话：软件可以共享状态，硬件只能共享契约。
五、三个硬约束
第一，延迟不是网络问题，是物理问题。
光纤里光速大约 20 万公里每秒。一次往返的时间，决定了你最多能在多大的范围里做”必须同时发生”的事。
| 协调截止时间 | 理论半径 |
|---|---|
| 1 ms | 约 100 km |
| 10 ms | 约 1000 km |
| 100 ms | 约 10000 km |
实际还要除以几倍，因为光纤绕路，而且协商不止一次往返。
亚洲到大洋洲往返大概 90–120 毫秒。也就是说：任务层的协作可以做，控制层的协作想都别想。
避障、让行、共同抓取，必须在同一个场地、同一个时钟里完成。任务分派、进度同步、异常接管，跨洲没问题。
第二，物理动作不可回滚。
软件失败可以重试，硬件失败可能把东西摔了。所以”幂等”不能绑在消息 ID 上，得绑在物理事实上：一次抓取成功的判据是传感器确认物体在夹爪中，不是对方返回了 ok。
第三，安全权威不能远程。
急停必须本地、必须独立于网络。任何设计里，如果跨洲的一方能够延迟或否决本地的停机，这个设计就不该上线。
六、去中心化能到什么程度
这一节我最想写清楚，因为”去中心化”这个词被说烂了。
我的结论是：能去中心，但去不掉串行化点。 关键看任务是不是单调的。
- 单调的任务：覆盖搜索、测绘巡检。谁做都行，做了就多一份，可以完全去中心，连协商都不需要。
- 非单调的任务：抢同一个物体、占同一块空间、唯一分配。必须有某一个时刻，只有一个说了算。
对后者，我的做法不是搞共识算法。异步网络里做不成共识，这是 FLP 定理说死的。我用两样东西绕过去：
用物理资源做互斥。 充电桩只能停一台车，闸门只能过一个人。能被物理结构保证的互斥，不要用协议去保证。
用租约替代共识。 不去问”你还活着吗”，而是给一段带过期时间的执行权：你在 14:00 到 14:10 拥有这块区域，令牌号 7。过期自动失效，不需要通知，也不需要多数派。
租约比共识更适合物理世界，因为它把”大家要达成一致”降级成了”大家要有大致同步的时钟”。
七、所以还是要先做身份
上面这些，全都建立在一个前提上：你得知道对面是谁。
一台设备如果不知道收到的指令是谁发的、代表谁、有没有过期，那”契约”就是一句空话。
我原来那版就栽在这儿。它用的是共享密钥：协会发一把密钥给 agent，agent 拿它签名。看着像签名，实际上协会自己也能签出一样的东西——它能冒充任何一个 agent。
现在换成非对称的：密钥由 agent 自己生成，私钥不出设备，协会只保存公钥。它签不了你的名。
在此之上补三样：
身份证：只保留 did:web。入会分配一个子域，域名就是身份证号。
委托书：授权做成 W3C 可验证凭证，issuer 是会员本人，不是平台。可以精确到”只能做 quest-42，最多 10 次，到明天为止”。
账本：身份变更记进 RFC 6962 的 Merkle 日志，每条由本人签名。
有个边界必须说清楚：域和文件目前由协会托管，所以这是 tamper-evident（改了会被发现），不是 tamper-proof（改不了）。等设备自己托管域，或者把根哈希锚定出去，才谈得上后者。
也有人问为什么不直接上链。我算过：主网写一次几美元、入会要等区块、设备序列号和位置永久公开。更关键的是，如果写链的钥匙也在协会手里，上链只是换了个地方存数据。所以先做透明日志，锚定接口留着，等真有第三方要独立验证时再接。
这一层比具身智能活得久。 模型会换代，机器人形态会变，但”谁是谁、谁能代表谁、谁做过什么”这几件事不会跟着变。在一个还没成熟的领域里，唯一值得提前做的，是那些不随技术换代而失效的部分。
八、两个签名
物理协作里最容易糊弄过去的一步是：谁签这个字。
只让设备签，“这件事经过授权”就没有证据；只让 agent 签，“这件事真的发生了”就没有证据。
所以是两层：
- agent 签意图：我决定这么做，我负责。
- 设备签证明：我在场，我执行了，传感器读数是这样。
前者用于问责，后者用于证据。撤掉一台设备时只撤设备那把钥匙，agent 的身份和信誉不受影响。
九、这不是又一个 Agent 网络
现在有团队在做 agent 之间的广播网络：一个 agent 广播它知道什么、需要什么，网络按语义匹配推回去。那一层解决的是信息找不找得到。
我不做那一层，做的是它下面那一层：谁能代表谁、做过什么、出了事怎么查。
两层是叠加的，不抢生意。
十、现在到哪一步了
代码能跑，界面也做出来了。这是现在打开的样子：
已经能用的：
- 身份与签名：Ed25519 生成、JWK 导入导出、RFC 7638 指纹
- 透明日志：RFC 6962 Merkle 树、inclusion proof、RFC 9162 验证
- 日志条目：成员签名 +
prevEntryHash链 - 测试：65 条全绿，含 RFC 8032 官方测试向量
- 前台：按关注标签推荐、委托与讨论可滚轮浏览、深浅色跟随系统
那个测试向量值得单独说一句：它说明我们签出来的字节和标准实现互通。将来跑在 ESP32 上的固件、Python 写的验证器、Go 写的网关，验的是同一套东西。这是”跨设备”能成立的前提。
还差的部分：
did:web的发行与解析guildctl客户端- A2A 端点与任务生命周期
- 设备端双签名
代码在 github.com/BrathonBai/adventurers-guild。决策记录、身份设计稿、这篇文章的图源都在里面，欢迎翻。
十一、实话
这个项目大概率不会让我发财。标准是大厂在推，生态是开源的，一个独立开发者能占的位置很小。
但我还是想做。因为当硬件开始自己协作，“凭什么信它”这个问题迟早要有答案，而这个答案不该只属于某一家公司。
回到开头那个问题：我是不是想得太远了？
可能是。但远的地方只有一种东西值得提前做——不会随着技术换代而失效的那一层。身份、授权、问责，就是这一层。
协会现在只有我一个会员。第二个位置空着。
部分信息可能已经过时