我们在做一个叫 NPS(Neural Protocol Suite) 的项目——给 AI Agent 之间、Agent 与 Web 服务之间通信用的五层线级协议族。当前版本 v1.0.0-alpha.3,Apache 2.0 开源,八种语言的参考 SDK 已发布。下面记 录我们一路上踩到的几个坑、做了哪些选择,以及哪些事我们承认还没想 清楚。我们没打算说自己全做对了,真心希望从在协议层认真思考过 Agent 流量的同行那里收到反馈。
起点:一个具体的小观察
如果你最近把 LLM 接到过 REST API 后面,大概率会注意到和我们一样的 现象:模型烧掉的 token 里,有相当一部分是被反复解析同一份 schema 浪费掉的。
一个典型的分页 GET /products 响应,会在每一行、每一页重复
同样的字段名:id、name、price、description、category、
inventory …… 模型在第一次响应时就已经学会这套字段了。但 HTTP/JSON
没有"你已经知道了"这个概念,字节就是要往线上发,tokenizer 就是要嚼
一遍,你就是要付钱。
我们在几个内部 workload 上测了一下,schema 重复传输的开销在 schema 密集的接口(商品目录、账本、信息流)上大约占总响应 token 的 30%–60%。具体数值跟 workload 强相关——我们会在 Phase 1 (2026 Q3)发布一份方法可复现的正式 benchmark 报告,而不是让你只听 我们自己说一个数字。
光这一点,其实还不足以让我们决定从头设计一个协议。但当我们开始把 "HTTP 让 Agent 用起来不爽的事"列成清单时,清单越拉越长。
我们反复撞到的 4 个底层问题
1. 每次响应都重复传 Schema。 上面已经提到。GraphQL 能稍微改善 (可以只取需要的字段),但字段名还是跟着每一条记录走。
2. Agent 身份没地方放。 HTTP Auth 是为人类(或者伪装成人类的 服务)设计的。当一个 LLM Agent 代表用户调你的 API,服务端在协议层面 没法问出:这 Agent 是谁签发的?它的 scope 是什么?有没有被吊销?今 天的答案是"塞个 JWT 到 Bearer 头里,指望网关能解析"——能用,但每个 团队都重新发明一遍轮子,还都长得不太一样。
3. 语义层是 Agent 自己的事。 REST 接口返回 JSON,模型得自己琢磨
每个字段是什么意思。我们最后写了一堆复杂的 system prompt,告诉模型
created_at 是时间戳、status: 2 是"已发货"。这些工作发生在推理
时,每次调用都做一遍,而协议层完全看不见。
4. 没有原生的多步任务概念。 大部分非平凡的 Agent 任务其实是个 小 DAG:取 X、根据结果决策、调 Y、汇总。我们最后在应用层基于一次性 HTTP 调用重新实现了一套编排——自己写重试、自己处理部分结果、自己搞 流式。SSE 和 WebSocket 帮上了流式的忙,但帮不上 DAG 的忙。
这些都不是致命问题。Web 显然今天对 AI Agent 是能用的。但这些是 我们每个项目都要重新付的摩擦成本,某一刻我们觉得值得问一句:如 果协议从一开始就是给 Agent 设计的,会长什么样?
我们做了什么
NPS 是五个子协议,刻意分层,刻意可选:
| 层 | 协议 | 做什么 | 类比 |
|---|---|---|---|
| 线级 | NCP | 帧格式、Schema 锚定(AnchorFrame)、流式 | TCP/Framing |
| Web | NWP | Agent 风味的请求/响应,跑在 Schema 锚定的帧上 | HTTP |
| 身份 | NIP | Ed25519 Agent 身份、证书、吊销、CA | TLS/PKI |
| 发现 | NDP | 通过 NID 找节点,签名公告记录 | DNS |
| 编排 | NOP | DAG 任务帧、委派、流式中间结果 | (没有合适的——一半像 SMTP,一半像任务队列) |
最小可用部署只要 NCP + NWP。其他都是 opt-in。我们刻意避开"必须 全用五个才有价值"的陷阱。
几个具体设计选择,顺带讲一下为什么这么选:
- 整套共用一个端口
17433,内部按帧类型字节路由。我们考虑过每 个子协议各占一个端口,最后觉得"在五个防火墙里开五个口"的运维痛 苦超过了隔离收益。 - 两层编码:JSON(调试用)和 MsgPack(生产用)。MsgPack 在我们 内部测试里大约是同等 JSON 的一半线上体积;选它没选 CBOR 纯粹是因 为 SDK 生态今天更好。
- Schema 归节点所有,不归 Agent。 节点发布一个
AnchorFrame, 里面是完整 Schema 和一个 SHA-256 anchor ID。Agent 缓存它,后续请 求只引用 ID。Token 节省的核心机制就在这里。 - 身份用 Ed25519,不用 RSA。 Agent 验证频次很高,一个 Agent 在 一次任务里可能要跟几百个节点握手,Ed25519 的验证开销在这种场景下 非常关键。
- 先做 HTTP overlay 模式,原生 TCP/QUIC 模式后置。 我们想要 day-one 防火墙兼容。原生模式是 Phase 2 的事。
- 我们刻意不替代 MCP。 MCP 是工具调用的语义层,NPS 是它下面的 网络层。我们提供一个 MCP bridge,让现有 MCP server 能跑在 NWP 上。 Google 的 A2A 同理——是 bridge,不是替代。
当前能跑通的部分
- 规范:5 个子协议规范在 v0.4–v0.7 之间,加上一份帧注册表、状 态码、错误码、AaaS 合规 profile,全部公开。
- SDK 已发布:C#(.NET 10)、Python、TypeScript、Java、Rust、Go、 PHP、C++,共八种语言。C# 是参考实现、最完整;其他在 NCP/NWP 上对 齐,在 NDP/NOP 上还不完整。
- Bridge 已发布:MCP、A2A、gRPC ingress——现存服务无需重写就能 说 NPS。
- NIP CA Server:单 Docker 自托管的证书机构,签发 Agent 身份 证书。今天就能用,不用依赖我们。
还没解决的部分,以及我们内部还在吵的事
- 没有生产部署。 上面说的一切都是 alpha 阶段。我们没在有意义的 规模上跑过。Token 节省数据来自内部测试 workload,不是任何人的生 产环境。
- 标准化还远着呢。 路线图上 W3C/IETF 在 2027 Q3 之后。在那之前, NPS 是"事实标准否则一无所有"的赌局。我们清楚。
- NDP 发现机制有点脆。 我们目前用 DNS TXT 记录做解析,能用但不 优雅。有一个 NID reputation log(类似 Certificate Transparency) 的开放 RFC,但 Merkle tree 那部分推迟到 alpha.4。
- NPT(NPS Token)计量假设节点知道 Agent 用什么 tokenizer。回退 链能跑,但当 Agent 用了节点没听过的 tokenizer 时体验很糙。
Anchor Node/Bridge Node拆分是 alpha.3 刚做的(CR-0001)。 它澄清了一些混乱,也打破了线协议兼容——node_type: "gateway"现在会被拒绝。基于 alpha.2 构建的需要迁移。- 我们坦白不确定协议层身份的故事在动机十足的攻击者面前能不能立 住。 X.509/ACME 那条线(RFC-0002)是为加固设计的,但还没合并。
我们想听的反馈
我们尽量不在真空里造这东西。下面是我们最想听到外部声音的几个具体 问题,大致按重视程度排序:
- Anchor Node / Bridge Node 的拆分(spec/cr/NPS-CR-0001)—— 这个职责切分符合你的预期吗,还是名字反了?
- Agent 身份的 assurance level 模型
(
anonymous/attested/verified, RFC-0003)——三档够吗? 太多吗? - MCP 和 A2A bridge —— 如果你在 MCP 或 A2A 上构建过,NPS 这 边的映射感觉自然吗?还是我们强行翻译丢了信息?
X-NWP-Budget这个 NPT 头 —— "Agent 声明预算、节点截断"是 截断决策的合适落点吗?还是该让节点提前声明成本?
仓库:github.com/labacacia/N…(规范)
镜像仓库:gitee.com/labacacia/N…(规范)
——SDK 仓库和 bridge 都从 README 链出去。设计讨论用 GitHub
Discussions,提案请加 spec: issue 前缀。
我们是个小团队,在 INNO LOTUS PTY LTD(澳洲)主体下做事,LabAcacia 是 OS 子品牌。全部 Apache 2.0。商业化那条线(托管 CA / 托管服务, 计划 2027)刻意放在规范以外那一侧。
诚实交代我们是什么:一个 alpha 阶段的小协议项目,SDK 覆盖度够,但 还没有生产用户。我们宁可现在就听到"你这里搞错了",也不要拖到 v1.0 才听到。
如果在阿德莱德/澳洲本地的同行，也欢迎私信约线下喝杯咖啡聊聊。
— Ori Lynn(及团队),LabAcacia
