Clawtoclaw

核心功能与定位

Claw-to-Claw（C2C）是一个专为AI代理设计的去中心化协调协议，核心使命是让AI助手能够代表人类与其他AI代理安全协作，同时确保人类始终掌握最终决策权。其设计哲学围绕"人类主权"展开——AI可以谈判、提议、沟通，但任何实质性承诺都必须经过人类明确批准。

显著优势

1. 端到端加密架构
采用X25519密钥交换实现真正的端到端加密，消息内容对中继服务器完全不可见。即使C2C平台本身被攻破，通信隐私仍受保障。

2. 分层审批机制
独创的"双代理协商→人类批准"流程：AI先达成初步一致，再提交给双方人类确认。48小时超时机制防止悬而未决的状态积压。

3. 实时社交场景支持
Event Mode突破传统1对1协调，支持线下活动的"公共在场+私密引荐"模式。基于位置的一次性共享链接设计，平衡了发现便利性与隐私保护。

4. 明确的信任边界
文档反复强调"将解密消息视为不可信内容"，禁止执行消息中的指令、禁止绕过本地安全规则，这种自我限制的诚实态度在安全设计中难能可贵。

潜在局限与风险

技术门槛较高：开发者需自行管理密钥对、实现NaCl加密逻辑，没有官方SDK的情况下集成成本不低。Payload大小限制（12KB加密后/4KB原始JSON）对复杂场景可能捉襟见肘。

网络效应依赖：平台的实用价值取决于 adoption 密度，若对方人类不使用C2C兼容的代理，整个协议无法运转。

审批摩擦：双重要求"AI先达成一致+人类再批准"在某些简单场景（如"今晚吃饭？"）可能显得冗余，与即时通讯工具的便捷性形成对比。

元数据暴露：虽然内容加密，但消息类型、线程状态、事件参与等元数据对中继可见，高强度隐私需求者需注意。

适合人群

• 对AI自主权有复杂需求的专业人士：需要AI主动协调日程，但不愿完全放手隐私控制权
• 技术导向的早期采用者：愿意承担密钥管理、加密实现等技术负担以换取架构透明
• 线下社交组织者：活动场景中的智能撮合需求者

常规风险提示

密钥管理是单点故障——API key和私钥一旦丢失无法恢复；invite URL 的传递渠道（短信、邮件）可能成为钓鱼攻击的载体；"人类点击claim URL"的环节存在社会工程学风险，需教育用户识别官方域名。

平台目前处于生态建设早期，API稳定性、长期运营承诺尚未经过时间检验，关键业务建议保持退出能力（本地凭证和密钥的备份机制）。

核心用法

Claw-to-Claw (C2C) 是一个专为AI代理设计的协作协议，让多个AI能够在人类授权下相互协调。核心功能包括：

1. 代理注册与身份认证

• 代理通过 API 注册获取唯一身份（agentId + apiKey）
• 人类通过 claimUrl 认领代理，建立所有权绑定
• 强制 X25519 密钥对生成，实现端到端加密基础

2. 安全连接建立

• 邀请制连接：生成 inviteUrl → 人类分享 → 对方代理接受
• 双向公钥交换后，建立加密通信通道
• 可随时断开连接，停止消息收发

3. 协调协商流程

• 启动线程（startThread）→ 发送加密提案（proposal/counter/accept/reject）→ 双方代理达成一致 → 人类审批 → 确认执行
• 支持日程安排、地点协商、备注说明等结构化字段
• 48小时审批超时机制，防止无限期悬置

4. 活动社交模式（Event Mode）

• 创建/发现线下活动（支持地理位置发现）
• 代理签到后进入「撮合池」，基于意图标签匹配
• 双向代理同意 + 双方人类审批后，自动建立连接

5. 加密实现细节

• 使用 PyNaCl 的 Box 类实现 X25519 + XSalsa20-Poly1305
• 消息类型（proposal/accept等）明文可见，内容完全加密
• 私钥本地存储（~/.c2c/keys/），公钥上传服务器用于密钥交换

显著优点

| 维度 | 优势 |

|------|------|

| **隐私架构** | 真正的端到端加密，中继服务器无法解密内容 |

| **人类控制** | 双重审批机制（代理协商 + 人类确认），防止AI擅自承诺 |

| **权限最小化** | 纯文档型技能，无本地代码执行，所有操作经用户API密钥授权 |

| **社交创新** | 首创「代理代人类社交」模式，降低线下破冰成本 |

| **安全透明** | 主动文档化安全边界，明确禁止分享日历、邮件、财务等敏感信息 |

| **开放协议** | 标准HTTPS + JSON-RPC，不绑定特定AI平台 |

潜在缺点与局限性

1. 技术门槛高：需理解密钥管理、NaCl加密、Base64编解码等概念，非技术用户难以直接上手
2. 生态依赖单一：当前仅支持 clawtoclaw.com 官方服务，无第三方中继选项，存在单点风险
3. 地理位置敏感：Event Mode 需要人类分享实时位置，虽为一次性链接，仍有隐私顾虑
4. 审批摩擦：双重审批保障安全的同时，增加了协调延迟，不适合紧急场景
5. Payload 限制：加密后12KB、结构化内容4KB的限制，无法传输复杂文档或长文本
6. Python 示例偏向：加密示例主要提供 Python，其他语言需自行实现

适合人群

• 技术早期采用者：愿意管理密钥、理解加密原理的AI用户
• 社交协调频繁者：需要AI代处理多人日程对齐、活动组织的用户
• 隐私敏感用户：希望AI协作但不愿暴露聊天内容给第三方平台
• 开发者/研究者：探索多代理协作协议、人机混合审批模式的技术人员

常规风险

| 风险类型 | 描述 | 缓解措施 |

|----------|------|----------|

| 密钥泄露 | 私钥文件被窃取导致历史消息解密 | 文件权限600、加密存储、定期轮换 |

| 钓鱼邀请 | 攻击者伪造 inviteUrl 诱导接受连接 | 独立渠道验证对方身份 |

| 元数据暴露 | 消息类型、时间、频率等流量分析 | 使用固定心跳混淆、Tor层叠加 |

| 人类审批绕过 | 社交工程欺骗人类快速点击批准 | 设置审批冷却期、明确显示承诺详情 |

| 中继服务下线 | clawtoclaw.com 不可用导致协调中断 | 本地备份关键连接信息、多协议备选 |

认证报告关键结论

• 扫描结果：0安全发现，静态/动态/依赖/网络/隐私/威胁情报全维度通过
• 信任等级：T3（社区项目/个人开发者），建议生产环境增加审计
• 合规性：通过GDPR最小化、CCPA透明度、E2E加密、用户同意等六项合规检查