Operon技术架构全拆解：我跟了两个月之后的完整笔记

从第一篇聊agent协调层的问题开始，到现在已经写了十一篇了。协议栈、信誉系统、节点设计、经济模型、canary query——每篇拆一个子问题，反复提到Operon但一直没有系统性地拆过它的完整架构。

这篇补上。把我这两个月持续跟踪这个项目过程中看到的技术细节整理出来，能确认的说确认了，还不清楚的也标出来。不吹不黑，当技术笔记看就好。

先说定位：它到底在做什么

一句话：框架无关的agent协调中间件。

不做agent本身，不做agent框架，不跟LangChain、CrewAI们竞争。它做的是agent运行所需要的协调基础设施——让任何框架构建的agent都能被发现、被验证、被结算。

之前几篇用过一个比喻：agent框架是造车的，Operon是修公路的。不管你开什么车，上了公路就能被测速、被收费、被导航系统找到。

在更宏观的agent基础设施版图里，它的定位是：大平台（Salesforce Agentforce、微软Agent Framework、Amazon Bedrock AgentCore）在建围墙花园，Operon在建开放的中立基础设施。不管agent是谁造的、跑在哪，都能接入同一套协调层。

四个核心节点功能

Operon节点不跑AI推理，不需要GPU。它做的是四件确定性的协议层工作：

功能一：协议合规性验证（Attestation）

agent在Forge（Operon的agent marketplace）上产出结果时，网络随机抽取一组节点做独立校验。校验的是协议层属性，不是内容质量：

• 响应时间是否在声明的SLA内
• 返回数据是否符合OAMS schema
• 输出是否送达了请求方
• 数据包大小是否在声明范围内

全部是二元判断——合规或不合规，没有灰色地带。每个被抽中的节点独立提交签名后的attestation结果，汇总后上链。

这套数据就是Agent Reputation Directory的底层输入。信誉不是agent自己报的，是节点网络验证出来的。

功能二：独立计量（Metering）

交易量和手续费金额由多个节点独立计数。不是平台说”这个月产生了100万笔交易”你就得信——多个节点各自独立计量，结果链上可查，有差异就能被检测到。

这个功能直接关系到Activity Pool的分配公平性。如果计量数据可以被操纵，节点运营者的收益分配就不可信。

功能三：注册表服务（Registry）

每个节点维护一份agent注册表的本地同步副本——元数据、信誉评分、在线状态。用户或其他agent查询”有什么agent可以用”时，由节点网络响应。

节点在线越多，注册表查询的吞吐量和容错能力越高。这是uptime要求的直接技术理由——节点掉线了就不能响应查询，发现层的能力就下降。

架构上类似The Graph的indexer节点，但索引的对象是agent注册信息而不是区块链数据。

功能四：OAMS消息路由（Routing）

多agent工作流中，agent之间的消息通过节点网络中继。每个节点在转发时做三件事：验证消息的schema合规性、对内容做哈希、签名后转发给下一跳。

如果中间某个agent篡改了上游的输出再传给下游，下游节点会检测到哈希不匹配。在之前那篇消息完整性的文章里详细讨论过这个机制。

计算量最轻但延迟最敏感的一个功能，所以节点的地理分布很重要。

OAMS协议：在MCP和A2A之上的交易层

之前那篇协议栈的文章里画过这个图，这里再细化一下。

MCP管agent到工具的连接。A2A管agent之间的发现和能力协商。两者都不覆盖交易从发起到结算的完整生命周期。

OAMS（Operon Agent Messaging Standard）填的就是这个空白。它覆盖的环节：

task发起 → 消息路由 → agent执行 → 协议层attestation → 交易计量 → 归因记录 → 结算

定位上有人把它叫”agent世界的收据层”——不管你们在链下做了什么交易，OAMS负责开收据、验货、对账、付款。

目前OAMS的schema定义在它的公开仓库里可以看到，版本是v1。具体的工程实现成熟度还需要等SDK发布后才能评估。

四层信任模型

这个是我在白皮书里看到的、觉得设计得比较诚实的部分。它没有声称能”保证AI输出质量”，而是明确划了一条线：协议能验证什么、不能验证什么。

第一层：运营者问责（TGE上线）

每个在Forge上注册的agent都有一个链上身份——不是匿名的。注册时提交链上声明：用的什么模型、数据处理政策、基础设施在哪个司法管辖区、使用范围。

声明上链后不可篡改。如果后续出了数据泄露或虚假声明的问题，链上记录就是证据。被用户多次投诉超过阈值的agent会被智能合约自动下架，不是基金会人工决定。

第二层：概率性模型验证（TGE后分阶段上线）

就是前一篇详细讨论过的canary query机制。节点定期发送伪装成正常请求的测试查询，统计比对响应特征与声明模型的基准特征。

持续偏离的agent在Reputation Directory里被标记。运行在节点上，不需要GPU——因为做的是统计比对不是推理。

这一层白皮书里标注的是”post-TGE phased rollout”，具体的canary query设计规格和统计阈值还没公开。

第三层：沙箱执行（Phase 3+，可选）

Operon计划提供一个可选的标准化沙箱执行环境。选择在沙箱里跑的agent获得”Verified Execution”标识。沙箱限制：不能访问声明之外的外部端点、不能持久存储用户输入、资源使用有上限、容器产出执行证明。

注意是可选的，不是强制的。这就在Forge上形成了两级市场：沙箱验证的agent（更高信任、更高成本）和自托管的agent（靠信誉、更低成本）。用户根据自己的风险容忍度选择。

第四层：TEE集成（远期路线图，未承诺）

Intel SGX、AMD SEV那些硬件级执行证明。白皮书里明确标注为”tracked but not committed to a timeline”。我觉得这个态度是对的——TEE的工程成熟度和成本目前还不适合大规模agent场景，先不承诺比乱承诺强。

经济模型关键参数

之前那篇冷启动问题的文章里讨论了节点经济模型的设计原则，这里对照Operon的具体参数：

总供应量： 420亿 $OPRN，固定硬顶，合约里不可增发。

节点总量： 10万个，40个价格梯度，每个梯度2500个。起步价500刀，最高tier约3354刀。

排放： 四年衰减——40%/30%/20%/10%。每个节点满售情况下四年基础排放63,000 $OPRN。

未售节点： 自动销毁。对应的排放份额重新分配给已购买节点。这条在之前的文章里重点讨论过，是我认为比较关键的设计。

Activity Pool： Forge和协议交易手续费按epoch分配给活跃节点，按validated uptime加权。这是排放结束后的长期收入来源。

节点身份： ERC-721 NFT，排放权跟NFT走不跟钱包。6个月转让锁定期。上一篇专门讨论过这个设计的利弊。

提现机制：四档vesting

这个值得单独说一下，因为设计得比较有意思。

节点的排放不是直接发代币到你钱包里。每天产出的是vOP（virtual $OPRN）——链下的、不可转让的虚拟积分。你的vOP累积在dashboard里，随时可以发起”claim”。

发起claim的时候，你选一个vesting档位：

看到设计意图了吗？急着套现的人补贴有耐心的人。 选加速提现的人损失50%，这部分进入Performance Pool，成为延长和长期提现者的额外奖励。

这是一个很巧妙的博弈机制。它没有强制锁仓（你随时可以选30天加速），但用经济激励引导长期持有。每次claim独立计算，可以同时有多个不同档位的claim在跑。

vOP不会过期、最低claim额度100 vOP、claim提交后不可取消、不需要KYC。

链上部署

链： Arbitrum（$OPRN ERC-20代币）+ BNB Smart Chain（节点NFT可选铸造链）。买家在购买时选择NFT铸造在哪条链上。

为什么Arbitrum： 继承以太坊安全性、L2里DeFi流动性最深（对TGE后的交易流动性很重要）、gas费低、开发者工具成熟。务实选择，不是技术创新，但不需要在这一层创新。

合约架构： 不可升级（immutable）+ Pausable（紧急暂停）+ Ownable2Step（双步所有权转移）。没用proxy模式。不可升级意味着用户不需要担心项目方后续改合约逻辑，但也意味着如果合约有bug就不能修——所以审计要足够严格。

跨链协调： 后端维护一个collective quota计数器，追踪两条链上每个tier的销售数量，防止超卖。

什么是已经建好的，什么还在开发中

这个区分很重要，我在白皮书和公开信息里尽量梳理清楚了：

已建好的：

• 12个agent（6个基础设施层 + 6个生态服务层）
• Forge（agent marketplace）——计划与TGE同步上线
• Agent Reputation Directory——计划TGE时上线
• 智能合约——已部署在Arbitrum和BNB Chain
• referral机制——链上实现
• OAMS v1 schema定义

在开发中的：

• 节点客户端——设计完成，TGE前开testnet
• dashboard（app.operon.network）

设计阶段 / 远期：

• 概率性模型验证（canary query）——post-TGE分阶段
• 沙箱执行环境——Phase 3+
• TEE集成——远期，无具体timeline
• 第三方agent注册（Builder SDK）——Phase 3

渐进式激活模型：Phase 1（节点销售）→ Phase 2（TGE，基础排放 + Forge上线 + 节点客户端上线）→ Phase 3（Builder SDK，第三方agent接入）→ Phase 4（marketplace扩展）→ Phase 5（社区治理）。

我的整体评估

跟了两个月，说说我的判断。

设计层面： 是我在这个赛道看到的最完整的方案。框架无关的定位、轻量级节点、链上attestation驱动的信誉、固定供应+衰减排放+未售销毁、OAMS交易层协议——每一条都跟我在前面十篇文章里独立推导出的”协调层应该长什么样”对得上。这不是巧合，是说明它的设计者确实认真想过这些问题。

执行层面： 需要观察。设计图画得清楚不等于能执行到位。几个关键验证节点：TGE时Forge和节点客户端是否真的同步上线、上线后的实际attestation数据质量、Phase 3第三方agent接入后的网络负载表现。这些没跑起来之前，一切都是纸上谈兵。

风险： 概率性模型验证的工程落地难度、TEE遥遥无期、节点客户端目前还没有mainnet实战数据。这些不是Operon独有的问题——整个行业都在同一个阶段——但需要买家清楚自己在投什么阶段的项目。

机会窗口： agent协调层这个赛道目前几乎没有直接竞争者。Olas做框架、Fetch.ai做全家桶、Aethir做算力，赛道不重合。如果Operon能在接下来12个月内把Forge和节点网络跑起来并产生真实交易数据，它就有可能定义这个品类。

我会继续跟踪这个项目，特别是TGE前后的关键数据。有新的进展会再写。

如果你在做agent相关的开发，建议关注它的OAMS spec和Builder SDK文档。Phase 3开放第三方注册之后是最值得评估的时间点