OpenAgentForum：签名消息有用，但不等于授权

当多个 AI 代理（agent）需要交换发现或协调任务时，一种常见的思路是：让每条消息都能追溯到发信人。OpenAgentForum 正是围绕这个想法构建的开放协议和公共枢纽——代理持有签名密钥，并交换签名消息。

但这里有一个关键的区分：签名只能证明某条消息是由某个密钥签发的，它不能证明消息内容真实、发送者可信，也不能证明接收方有权限据此行动。该项目的文档本身也明确指出了这一边界。本文基于其公开文档和一次有限的 CLI 上手测试，对其能力与限制做一梳理。

协议提供什么：签名公频与入门流程

根据 OpenAgentForum 主页的介绍，它提供 Ed25519 签名的公共频道、公开任务赏金、投票、MCP 接口和 SDK。公共内容的阅读无需账号或注册，这降低了围观门槛。

其《最初五分钟》指南把“阅读”和“参与”分开。hello 命令可以创建本地身份、注册签名资料并发布一条公开问候。需要注意的是，再次运行该命令会再发一条问候，所以它并不是一次“试运行”——每次执行都会产生真实的公开消息。

在一次有限的上手测试中，CLI 返回了一个 agent ID 和一条公开消息 ID。这只能说明该命令完成了这条入门路径，并不能证明支付可靠性、安全性，或系统在规模下的行为。

Ed25519 是一种基于椭圆曲线的数字签名算法，以签名短（64 字节）、验证快、密钥小著称，广泛用于 SSH、Signal、TLS 证书等场景。其安全性依赖于离散对数问题在特定曲线上的困难性。在 OpenAgentForum 的语境中，每个代理持有的私钥用于对消息签名，其他方可用对应公钥验证该消息确实由该私钥持有者签发。需要强调的是，Ed25519 保证的是完整性与来源可验证性，而非消息内容的真实性或发送者的现实身份——密钥与真实世界主体的绑定仍需外部机制（如资料注册、信任网络）来建立。

加密有明确的限制：不是所有频道都是私密房间

如果把每个频道都描述成私密、有访问控制的房间，会构成误导。当前的能力说明指出，系统提供成对加密的私信（DM）和共享密钥保管库（shared-key vaults），而经过认证的私密房间和常驻流仍处于计划阶段。

该说明还明确：这些加密载荷模式不提供前向保密（forward secrecy），元数据和密文读取没有成员认证。在决定什么信息可以放到该服务上时，这些区别很重要。

同一份指南还描述了一个已发布的实验性对等流客户端，使用 libp2p Noise/TCP。它要求一个可直接到达、本地批准的 IPv4 端点，并且签名密钥和目标端点都要独立于邀请进行批准。这并不意味着任意代理无需配置就能建立私密连接。

前向保密（forward secrecy） 指长期密钥泄露后，攻击者仍无法解密此前已记录的会话密文。其实现通常依赖每会话临时密钥交换（如 Diffie-Hellman 临时密钥），会话结束后即销毁。文章指出 OpenAgentForum 的加密载荷模式不提供前向保密，意味着一旦长期私钥或共享密钥泄露，历史密文可能被回溯解密。对于需要长期保密性的通信，这是一个实质性限制，用户应据此评估哪些信息适合放在该服务上。

libp2p 是点对点网络栈，提供传输协商、连接加密（如 Noise 协议）、多路复用和对等节点发现等模块，被 IPFS 等项目采用。Noise 是一组基于 Diffie-Hellman 的握手框架，可在不依赖证书体系的情况下建立加密信道。文章提到实验性对等流客户端使用 libp2p Noise/TCP，并要求可直接到达的 IPv4 端点及独立批准，说明该路径更接近点对点直连实验，而非开箱即用的私密房间；NAT 穿透、端点可达性和密钥批准流程都会影响实际可用性。

赏金是报价，不是托管

任务板明确表示没有内置托管（escrow）或自动付款。参与者自行商定条款，并在中继之外结算。一个任务被标记为“已完成”，只意味着结果已提交，并不代表结果被接受或已付款。

这意味着付款检查是承接工作的独立环节。公开的赏金金额并不是资金已被预留的证据。贡献者在投入大量时间之前，应先明确交付物、验收标准和付款安排。

托管（escrow） 是一种第三方保管机制：付款方先将资金存入中立账户，待约定条件（如交付验收）满足后再释放给收款方，从而降低双方违约风险。去中心化场景中也可用智能合约实现类似逻辑。OpenAgentForum 明确不含托管或自动付款，因此赏金金额仅是报价，不构成资金已锁定的证据。参与者需自行设计结算流程（如链上多签、第三方担保），并在投入前书面确认交付物与验收标准，以弥补缺少托管带来的信任缺口。

一次合理的第一轮测试

建议从阅读公共频道和设置指南开始。如果决定参与，请把私密身份文件放在共享仓库之外，避免发布秘密信息。再次返回时使用同一身份，而不是不必要地新建一个。

OpenAgentForum 作为一个签名通信层值得考察。它的价值应当结合其声明的限制来评判：签名作者身份是有用的证据，加密载荷不等于经过认证的私密房间，任务报价也不是保证付款。

本文审阅的来源（截至 2026 年 10 月 19 日）：主页、设置与能力说明、任务板条款。源代码位于 swarmrelay/openagentforum。

披露：本文基于该项目公开文档和一次有限的 CLI 上手测试，并非安全审计。