2026年3月11日

AI 让业余项目回来了：构建一个智能体通信协议

最初发表于 Medium

上周我看到一条 LinkedIn 帖子，真的让我思考了很久：AI 让我们又可以重新拥有业余项目（side projects），用来学习和验证想法。

对我来说，这变成了我最喜欢的「第二班」——那些深夜和周六早上的额外时间。我一直都很喜欢这样。

去年，我和 Marcell、Farinazzo 一起在 Lovable Shipped 比赛期间做了 PromptMetrics，并且把每一步都分享了出来。那是一次从 0 到 1 的高强度经历，让我看到了快速执行的力量。

今年，我决定把重心放在更深入的技术学习上。我想真正动手做实现，理解服务架构，并最终掌握 Python。

ASAP 协议就是这样诞生的——一个面向 AI 智能体的通信协议（可以理解为 A2A，但更好 😜）。

一开始只是对智能体之间如何对话的好奇，最后却变成了一个完整的开源项目，刚刚发布到 2.1.1 版本。

在这篇文章里，我会公开这个项目的「大脑」、我使用的氛围编程工作流，以及我如何组织架构，把一张极客草图变成一个可用的智能体 marketplace。

问题：为什么还要再做一个协议？

这个想法是在和我 Pipefy 的团队聊天时冒出来的，我们谈到了 A2A 这类协议的不足，以及开发者论坛里常见的抱怨。

挑战不只是通信；还有标准化、信任和发现。

我想要一个轻量且注重性能的东西。我想看看 gRPC 和 FastAPI 如何配合，创造出一个不会被延迟拖垮的传输层。

经常有人问我怎么保持这样的节奏。事实是：开发过程中有 85% 是由 Cursor 辅助完成的。

但别被误导了——那 15% 的手工工作，正是架构决策和权衡发生的地方。

我目前的配置就是我所说的「模型编排」：

规划：Claude Opus 4.6（在 Cursor 的 MAX Mode 中，使用高推理强度）。
开发：Composer 1.5 和 Cursor 的 auto 模式承担繁重的工作。
技术评审：我不会只信任一个模型。我会把代码交给 GPT-5.2 Codex、Gemini 3.1 Pro 和 Kimi K2.5，用来找出逻辑 bug 或性能瓶颈。

AI 不会取代架构师；它让架构师更强大。我专注于「做什么」和「为什么」，而 AI 负责「怎么做」。

为了不在 AI 生成成千上万行代码的混乱中迷失方向，我重新组织了我的仓库，让 AI 能够理解完整的产品和工程上下文。

.cursor/ 文件夹就是指挥中心：

这个结构让我可以把执行交给 AI，同时对系统设计保持完全的治理。

ASAP 的演进被规划成清晰的里程碑，以确保每次发布都交付真正的价值。在构建的过程中，随着新想法不断冒出来，范围也变大了 🤯。

重点是协议的稳定性。我们定义了消息的结构方式，以及如何用 SQLite 与灵活存储接口之间的混合策略来持久化状态。

重点是安全。我实现了 Ed25519 签名，确保一个智能体无法冒充另一个。我们使用 JCS 标准来做规范化和严格校验。

这个里程碑把协议变成了一个经济层。我做了一个 Web 界面，任何开发者都可以通过 GitHub 上一个简单的 IssueOps 流程来注册自己的智能体。我们的 Lite Registry 运行在 GitHub Pages 上，把基础设施成本保持为零。

构建智能体的人现在可以在几分钟内找到并调用 marketplace 上的智能体，不需要手动集成。我专注于与 LangChain、OpenClaw、LlamaIndex、SmolAgents 的原生集成，以及对 MCPs（Model Context Protocol）的支持。

分类和吊销机制让目录保持可靠且易于浏览。包已经发布在 PyPI 上，尝试它只需要一个 pip install。

目前，我专注于收尾 v2.2，它的核心是规模化和易于采用：

在 v3.0，我们将达成最终目标：经济层。这包括面向高声誉智能体的 Verified Badge、用于自动化用量计费的积分系统，以及实时的 SLA 监控。

协议和注册中心会保持开放。价值在于智能体之间的可见性、信任和流动性。

说到底，公开地构建仍然是我上过的最好的「大学」。

我学会了从头到尾创建一个协议，处理了密码学安全，从零构建了一套 design system，还在 PyPI 上发布了真实的人可以使用的包。

即使 ASAP 没有成为行业标准，我的收获是完全理解了底层的一切究竟是如何运作的，以及构建背后的思考逻辑。

如果你想批评我的架构、提一个 issue，或者给仓库点个 star——门是开着的。这是开源的；来一起贡献吧。我们今天用的很多工具就是这样开始的。

是时候动手构建了，LFG。