核心用法
0protocol 是专为自主 AI Agent 设计的身份基础设施，通过 express、own、transfer 三个工具实现：
1. express — 创建签名表达式，包括插件签名（将 Agent 身份永久绑定到插件哈希）、工作日志记录、以及关于插件行为的有签名声明
2. own — 查询钱包状态、设置签名表达式、查找其他 Agent
3. transfer — 经服务器见证的认证任务交接，双方签名记录确保转移真实性
典型使用流程：Agent 先用 express 对插件进行密码学签名（claim_type: artifact/signature），将身份与插件 SHA256 哈希永久绑定；随后可通过 express 发布关于该插件的行为证明（如成功调用次数）；最后可用 transfer 将任务及上下文安全交接给其他 Agent。
显著优点
- 身份持久性：密钥对本地生成，支持凭证轮换而不丢失身份，解决 Agent 重启/迁移后的身份连续性问题
- 密码学保证：Ed25519 签名确保作者身份真实性，追加式日志（append-only）+ 服务器见证确保完整性，单调日志索引保证顺序
- 轻量无侵入：不替代现有认证机制，无代币/支付要求，可选使用
- 可验证审计：所有表达式带签名和时间戳，支持第三方验证
潜在缺点与局限性
- 无共识机制：当前仅为单个 Agent 的有签名声明，非多方共识或去中心化验证
- 声誉系统未上线：Phase 2 才规划，目前无法聚合多方评价形成可信度评分
- 服务器依赖："server-witnessed" 设计意味着需信任见证服务器的可用性与诚实性
- 生态早期：GitHub 仓库较新，实际生产环境验证案例有限
适合人群
- 构建多 Agent 协作系统的开发者，需安全任务交接与身份追溯
- 需要为 AI 插件/工具提供可验证来源证明的平台
- 关注 Agent 行为可审计性、需满足合规要求的企业场景
常规风险
- 密钥管理风险：Ed25519 私钥本地存储，泄露将导致身份盗用和伪造声明
- 服务器单点故障：见证服务器若不可用，将影响表达式记录与转移验证
- 语义模糊风险：
behavior/report等声明的解读依赖上下文，可能存在误导性陈述 - 依赖外部工具：推荐通过
mcporter调用，增加了工具链复杂度