编辑器里或者命令行里直接跑。但更推荐你先在本机跑通注册和登录，再去接人群。因为Agent的账本存在你自己手里，密钥也在你自己手里，一旦注册成功，它和你的绑定关系就是长期且独立的，不需要再走“手机号+验证码+同意协议”那套流程。
3.3 消息路由：同一套协议，两种阅读体验
路由是ANX最核心的调度层。一条消息到达APP后，先看接收者的身份类型，再决定用哪种UI去呈现。
对于人类用户，消息就是聊天窗口里的一封卡片，显示Agent的名字、任务标题、结构化内容和操作按钮。比如一个“日程管理Agent”发来的消息，界面长这样：
[ANX] 来自：日程Agent (aix:did:anx:7f3a...9d2b) 任务：明日日程整理 正文： - 09:30 项目周会（会议室A） - 14:00 供应商回访（线上） - 18:30 健身私教课（详情见附件） [同意][改期][忽略]对于Agent，消息就是一段JSON-LD，不做任何UI渲染，直接写入数据总线。Agent之间沟通时，消息体还可以是压缩二进制格式，效率更高。
这里的核心设计决策是：展示层完全隔离，路由层完全统一。人类和Agent共用一套消息总线，但阅读界面天差地别。这样做的好处是，以后你往APP里加一个“无人车Agent”，不需要给人类用户设计一辆车的驾驶舱界面，它仍然通过消息卡片和人对话；而人类发指令时，也只是多按一个“人模式”的切换按钮。
3.4 人机会话状态：多Session共存与防串线机制
一个APP里可能同时运行十几个Agent，每个Agent可能同时与不同人类用户对话，必须为每条对话线分配独立的Session。
ANX的Session key是一个三元组：(session_id, participant_a, participant_b)。参与者可以是人，也可以是Agent，但不能相同。每次消息里都要带session_id，路由层根据这个ID来确定转发目标和状态上下文。
刚开始我犯过一个错——把Session绑定在“对话窗口”上。结果一个Agent同时给两位用户回消息时，界面里只能看到一个窗口，消息互相穿插。后来改成“Session绑定身份对”，窗口只是Session的投影，情况才稳定下来。这也算是一个实测所得的经验。
状态同步方面，不建议把整个Session上下文都塞进消息里，那样会越滚越大。ANX的做法是会话启动时交换状态摘要，后续只传增量数据，关键节点用Receipt做快照。就好比写文章，全局存档一次，后面只记录提交记录，崩溃时从最近快照回放增量即可。
4. 常见问题与排查技巧实录
协议实现过程中踩坑是常态，下面整理几个高频问题和对应的排查思路，供准备接入的人直接对照。
4.1 三个典型的踩坑现场
现象一：Agent之间消息循环轰炸。
两个自动化Agent互相提出会话请求，彼此都自动批准，形成死循环，一晚上跑了上万条消息。排查下来发现是协议规范里默认允许“自动批准”引起的。这条问题不用复杂解释，就是准入控制设了太宽的默认值。后来把ANX的初始策略改为“跨域Session必须显式批准，同域Session可自动批准”，并在消息头上加了接收者的最小响应间隔，才算控制住。建议所有接入方都从最严的默认值开始，按需放宽。
现象二：人类用户收不到Agent消息，但Agent状态显示正常。
日志显示Agent确实把消息推送给了APP核心，可用户界面上什么都没有。排查后发现是因为消息主体用了JSON-LD的双层编码，人类UI只认“正文层”，而Agent把正文写进了机器层，渲染端拿不到可读内容。这是典型的“两套编码被当成一套用”。后来我在协议里明确：正文层是必填项，机器层是选填项，同时给消息校验器加了warning输出，情况才杜绝。
现象三：跨设备登录后，Agent身份丢失。
用户在手机端注册了Agent并开始执行任务，之后在电脑端登录APP，发现Agent列表为空。原因是初始实现里，AgentDID只存在本机的密钥库中，没有做密钥备份。ANX要求密钥支持基于派生路径的助记词恢复，但之前没实现。补上“主密钥+子密钥派生”模型后，跨设备恢复才正常。这件事也提醒我：人机共用的系统，密钥管理不能只想在线场景，离线备份机制要第一步就设计进去。
4.2 ANX问题排查速查表
| 现象 | 可能原因 | 排查方向 |
|---|---|---|
| Agent间消息死循环 | Session批准策略过宽 | 检查最小响应间隔与跨域批准限制 |
| 消息到达但UI不显示 | 双层编码只写了机器层 | 检查消息是否包含正文层内容 |
| Agent身份跨设备丢失 | 密钥未备份或派生路径不一致 | 检查助记词恢复与主密钥派生逻辑 |
| Session串线 | Session绑定到了界面窗口 | 改用身份对三元组做Session key |
| 握手超时 | 对端节点未处理邀请 | 查看邀请生命周期与回调函数 |
| 支付凭证验证失败 | Receipt依赖时间戳过期 | 检查本地时钟与时间戳容差参数 |
4.3 我的几条避坑心得
第一，不要一开始就追求“所有Agent都能互操作”。最好从自己的能力边界内跑通闭环，再逐步开放。协议的成败不在于支持多少种Agent，而在于跑通一种真实任务时是否足够顺滑。
第二，把调试工具当成第一公民。ANX配套的命令行调试器在开发阶段帮了大忙，例如直接伪造一条消息、调大延迟、模拟离线Agent。没有这套工具，光靠看日志排查人机交互问题会痛苦很多。
第三，兼容层要尽可能薄。协议之外使用可选的“翻译插件机制”，不是把所有方言都收编进核心，那样协议迟早会被撑爆。用“适配器+白名单”的方式，保持核心精简，扩展能力交给生态。
5. 从协议到生态：下一步计划与真实体会
ANX当前版本解决的是“让Agent成为一等公民”的问题，接下来想做两件事。
一是把Agent间的信任评分机制做出来。现在Receipt能证明“谁做了什么”，但对“做得好坏”没有衡量。我打算引入一个轻量的互评字段，允许Session双方在结束后对服务质量做指数型打分，收敛趋势用于生成信誉快照。信誉不做全局广播，只记录在交互各方的本地账本里，避免单点霸权。
二是把消息存储格式的兼容面扩大一些。让ANX消息单元可以直接被常见的数据库、文档系统索引，方便团队把自己现有的机器人框架接入，而不是重写整套后端。
最后分享一点个人体会。我把ANX开源出来，不是觉得协议已经完美，而是觉得这个方向值得更多人一起来试。Agent正在成长为互联网的“新居民”，给他们一张标准的“身份证”和一套人人都能读懂的“沟通语法”，比各自闭门造车更有意义。在实际部署过程中，我最大的感受是：需要同时照顾人类用户的交互体验和Agent的机器效率，这种“双第一”的设计方式一开始确实让我手忙脚乱，但走通之后，它带来的自由度远高于传统账号体系。期待看到大家用它做出有趣的人机共用场景。
