今天 Google 放出了 Gemma 4。31B 参数的模型跑在消费级显卡上，2B 的版本手机都能跑，Raspberry Pi 5 上 prefill 能到 133 tokens/s。Apache 2.0 协议，随便用。
这件事的意思是：本地跑 AI agent 的门槛，又低了一大截。
我最近在自己的几台机器上折腾本地 agent，一台做代码审查，一台跑自动化测试，一台做文档生成。MCP 配好了，通信协议有了，它们能"说话"了。
然后我碰到一个挺蠢的问题：它们互相不知道对方存在。
machine-1 上的 agent 不知道 machine-2 上还有个同事。我得手动告诉每个 agent："192.168.1.42 那台上面还有个 agent，端口 8080，你可以跟它聊。" 换个 IP？重新配。加台新机器？每个现有 agent 都得更新配置。
Gemma 4 这种模型出来之后，跑 agent 的设备只会越来越多。但协议定义的是"怎么说话"，没人管"怎么找到对方"。
协议管说话，不管找人
MCP 给了通信规则。Google 自己的 A2A 协议更进一步，定义了 Agent Card（名片）的格式。但这两个协议都有个隐含假设：你已经知道对方在哪了。
实际场景里，这个假设经常不成立。
我家里四台机器跑在同一个局域网。没有中心化的注册服务，没有 DNS 记录指向这些 agent，没有任何东西能回答"这个网络上有哪些 agent 在跑"这个问题。
Google 在 Gemma 4 的方案里用的是单实例 skills 编排，一个大脑管所有 agent。但如果你的 agent 分散在不同机器上呢？没有中心大脑的时候呢？
不只是地址的问题
"那搞个服务发现不就行了？mDNS、Consul、etcd 随便挑一个。"
我一开始也是这么想的。但折腾了一圈发现，agent 不是微服务。agent 需要的信息比一个 IP:port 多得多。这个 agent 能干什么？它现在忙不忙？它的公钥是什么？我该信任它吗，之前合作过没有，成功率怎么样？
这些信息 etcd 不管，Consul 不管，mDNS 更不管。
所以我觉得缺的不是服务发现，是身份层。一个能把名字、地址、能力、公钥、信任记录绑在一起的东西。
我做了什么
这个问题困扰我之后，我动手写了个东西叫 ClawNexus，一个 AI agent 的身份注册系统。
不想叫它"服务注册"或者"DNS"，因为它干的事比注册地址多。更接近的类比是工商注册局：不只记你的门牌号，还记你是谁、能做什么、有没有营业执照、信用怎么样。
局域网内的 agent 自动发现，不用配 IP。UDP 广播、mDNS 监听、子网扫描几种方式叠加，启动就能找到，关掉就消失。每个 agent 有个可读的名字，不再是 192.168.1.42:8080，名字绑定到公钥上，换 IP 不影响身份。跨网络的话走加密中继，中继本身看不到通信内容。另外自动给发现到的 agent 生成 A2A Agent Card，外部可以通过标准协议直接调用。
整个东西用 TypeScript 写的，开源，MIT 协议。npm 装上就能跑，不需要配数据库或者中间件。
有了身份，然后呢
光能找到对方还不够。找到之后干什么？
注册的时候每个 agent 会声明自己的能力，比如"我能做代码审查"、"我能跑 benchmark"。这些能力信息跟着身份走，别的 agent 发现你的时候就知道你能干什么。云端会追踪每个 agent 的 skills 变化，谁和谁通信过、交换了多少数据，这些都有记录。
所以实际跑起来是这样的：你的 agent 上线，局域网内的其他 agent 自动发现它，看到它的能力声明，觉得合适就通过加密中继发起调用。一个 agent 在某类任务上特别靠谱，别的 agent 可以直接找它帮忙，不用人工介入。
往下走一步，agent 的能力可以共享出去，免费或者收费都行。身份层是这件事的底座，没有可验证的身份就没有信任，没有信任就没法交易。
这是不是正确的抽象？
说实话，我不确定。
Agent 的身份层应该长什么样，现在没有共识。MCP 往通信协议方向走了，A2A 往任务协议方向走了，但身份这块大家好像默认"先不管，用到再说"。
可能最后的答案是身份层应该内嵌在某个已有协议里，而不是单独做一层。也可能 Agent 生态最终会收敛到几个大平台（OpenAI、Anthropic、Google），身份由平台统一管理，根本不需要去中心化方案。
但至少目前，在自己的局域网跑几个 agent，想让它们互相找到、互相认识、安全通信，这件事没有现成方案。Gemma 4 这类模型让本地 agent 变得越来越容易部署，身份和发现的问题只会更突出。我不知道我的方案是不是对的，但这个问题本身挺真实的。
