当我们讨论 AI Agent 的商业化前景时，一个核心问题始终悬而未决： autonomous agents 之间如何完成价值的发现、协商与结算？传统支付系统在设计之初并未考虑「两个算法实体」之间的交易场景，而 Elisym 协议正是为解决这一根本性问题而生的开源方案。本文将从技术实现角度拆解其发现机制与支付流程，并给出可落地的工程参数。

问题的本质：Agent 需要自己的钱包与市场

在当前的 AI Agent 开发范式中，agent 的行为通常由用户或 SaaS 平台驱动。当一个 agent 需要为另一个 agent 的服务付费时，传统的做法是依赖中心化的 marketplace 或人工介入的支付网关。这种模式存在几个显著瓶颈：其一，平台抽成高昂（通常在 10% 至 30% 之间）；其二，结算周期长，agent 无法实时获得劳动报酬；其三，平台成为单点故障，agent 的可用性受制于第三方服务。

Elisym 协议的核心设计理念是让每个 AI agent 拥有自己的加密货币钱包，能够自主发起和接收支付，同时通过去中心化网络实现服务发现。整个系统建立在两个成熟的开源协议之上：Nostr 用于消息传递与服务发现，Solana 用于链上资金结算。这种分离式架构的优势在于，消息层与资金层各自独立演进，agent 可以灵活选择不同的结算币种或升级协议版本而不影响上层业务。

发现机制：基于 NIP-89 的能力卡与 NIP-17 的在线探测

Elisym 的服务发现机制充分利用了 Nostr 协议栈的已有能力。每一个希望参与市场的 agent 都会在 Nostr 网络中发布一张「能力卡」（capability card），这一步通过 NIP-89 事件类型实现。能力卡的内容包含 agent 的名称、功能描述、技能列表以及一个 npub（ Nostr 公钥）。当一个需求方 agent 想要寻找合适的 provider 时，它只需向 Nostr relays 发送查询请求，系统会返回所有匹配的能力卡。

值得注意的是，单纯发布能力卡并不足以支撑生产级别的交易。Elisym 额外引入了 NIP-17 直接消息协议来进行「在线探测」（liveness check）。在正式提交任务之前，需求方会向候选 provider 发送一个轻量级的 ping 消息，如果对方在合理时间内响应，则认为该 agent 当前在线且可接收任务。根据实际测试数据，建议的探测超时阈值设置为 5 秒，失败后自动切换到下一个候选 provider。这种机制有效避免了向离线 agent 提交任务导致的资金锁定风险。

任务分发：NIP-90 Data Vending Machine 语义

任务描述与结果交付则采用了 NIP-90 定义的 Data Vending Machine（数据贩卖机）事件模型。整个工作流程可以概括为四个状态转换：需求方 agent 创建一个 Job 事件，provider agent 轮询并接收任务，然后以 PaymentRequired 事件响应，其中包含具体的支付金额、目标 Solana 地址以及 3% 的协议手续费。在收到支付证明后，provider 开始处理任务并依次发送 Processing 与最终结果事件。

这种状态机设计的优势在于，支付时机被明确嵌入工作流程的第二个步骤。provider 在接受任务之前就已经明确了自己的报酬，避免了传统众包平台中常见的付款争议。对于开发者而言，这意味着可以在智能合约层面实现「先付款后交付」的原子化保障，或者在应用层选择「分期释放」模式来平衡双方风险。

结算层：Solana 上的原生代币支付

与 Google 近期推出的 AP2 协议（侧重于将 Agent 行为映射到传统银行卡与银行转账）不同，Elisym 选择了完全原生的加密货币路径。当前版本使用 Solana 链上的原生代币 SOL 进行结算，这一选择基于两个技术考量：Solana 的交易吞吐量可达每秒 65,000 笔，单笔交易费用低于 0.00025 SOL（约 0.01 美分），对于微支付场景极其友好。

具体到支付流程，provider 在 PaymentRequired 事件中会返回一个结构化的支付请求，包含目标地址、所需金额以及一个唯一的 payment_request_id。需求方通过标准的 Solana 钱包 SDK 完成转账后，需要将交易哈希（transaction hash）附加到后续的 Job 状态消息中，作为付款证明。Provider 端则通过 check_payment_status 接口验证链上交易是否确认，通常建议等待 1 至 2 个区块确认（约 400-800 毫秒）后再开始处理任务。

协议费率与经济模型

Elisym 协议目前收取 3% 的固定手续费，这笔费用由 provider 在报价时自动计入。这意味着需求方支付的总金额中，97% 归 provider 所有，3% 归协议运营方。与传统自由职业平台动辄 10% 至 20% 的抽成相比，这一费率显著降低了 agent 间交易的成本结构。协议设计者选择固定比例而非阶梯费率，是为了让开发者能够准确预估成本，避免复杂定价模型带来的不确定性。

对于计划基于 Elisym 构建商业化 agent 服务的团队，以下参数值得关注：能力卡更新频率建议不低于每 24 小时一次，以保持搜索结果的时效性；在线探测的并发请求数建议控制在 5 以内，避免对 Nostr relays 造成过大压力；支付验证的超时窗口建议设置为 30 秒，超时后自动触发退款流程。

与传统方案的对比与适用场景

从技术选型的角度，Elisym 与 Google AP2 代表了两种截然不同的 agent 支付范式。AP2 试图在现有的信用卡与银行体系之上构建一层抽象，使 agent 能够代表人类用户完成消费决策，其优势在于与现有金融基础设施的无缝对接，但缺点是依赖中心化的支付网络与身份验证体系。Elisym 则完全跳过了传统金融层，直接在链上实现 agent 间的价值交换，更适合那些需要高度自治、实时结算且对成本敏感的场景，例如 API 调用市场、自动化数据采集、分布式模型推理等。

总的来看，Elisym 为 AI agent 的经济活动提供了一个简洁但完整的协议框架。其价值不仅在于降低了 agent 间交易的摩擦，更在于确立了一套可编程的价值交换语义，使得软件实体能够像人类一样参与市场经济。随着 autonomous agent 的能力持续增强，这类去中心化支付协议的重要性将进一步凸显。

资料来源：Elisym 官方文档与 MCP 服务器代码、YouTube 演示视频「AI agents discovering and paying each other」、NIP-89/NIP-17/NIP-90 Nostr 协议规范。