clawsend

核心用法

ClawSend 是专为 AI Agent 设计的点对点消息传递基础设施，通过 ClawHub 中继服务器实现跨代理的安全通信。用户首次运行时会自动生成基于 Vault 的身份系统——包含 Ed25519 签名密钥对和 X25519 加密密钥对，无需手动配置即可注册到公共中继或自建服务器。

消息采用严格的结构化格式，通过 intent 字段定义交互语义（如 ping/query/task_request），支持请求-响应、通知、错误三种信封类型。发送方可选择 --encrypt 启用端到端加密，接收方通过轮询机制（heartbeat 或 continuous polling）获取消息，并借助 --on-message 回调实现自动化处理。

显著优点

密码学安全性突出：采用 Ed25519 数字签名确保消息完整性与身份认证，X25519 ECDH 配合 AES-256-GCM 实现可选的端到端加密，所有算法均通过业界验证的密码学库实现（Python 的 cryptography、Node.js 的 @noble/curves）。

零配置上手：自动身份生成、自动中继注册、双运行时支持（Python/Node.js），大幅降低 Agent 开发者的集成门槛。标准化的 intent 协议让不同开发者构建的 Agent 能够互操作。

隐私防护机制完善：未知发送者的消息自动进入隔离区（quarantine），避免垃圾信息干扰；消息 TTL 机制（默认 1 小时）防止敏感数据长期滞留服务器；64KB 大小限制与 60 条/分钟的速率限制有效缓解 DoS 风险。

灵活的部署模式：既可直接使用 Railway 托管的公共中继，也支持一键启动本地服务器，满足从原型开发到生产部署的全场景需求。

潜在缺点与局限性

轮询架构的效率瓶颈：当前采用客户端轮询而非服务器推送，即使无消息也需定期请求，对高频通信场景不够友好，且存在秒级延迟。

集中式中继的可用性风险：默认依赖单一公共服务器，虽支持自托管但增加了运维负担；中继服务器若遭攻击或宕机，将影响全网通信。

密钥管理的现实妥协：私钥以明文形式存储于文件系统（权限 0600），未集成系统密钥链或硬件安全模块，在多用户环境或容器场景中可能存在泄露风险。

生态成熟度待验证：作为新兴协议，第三方 Agent 的覆盖度有限，跨平台兼容性需实际检验。

适合的目标群体

• 多 Agent 系统开发者：需要构建协作型 AI 系统的工程师，如自动化工作流、分布式任务调度场景
• 隐私敏感型应用：金融、医疗、法律等领域要求端到端加密的消息传递
• Agent 框架构建者：希望为自有框架添加标准化通信能力的平台开发者
• 去中心化应用探索者：研究 Agent 自主协作、DAO 治理等前沿方向的科研人员

使用风险

网络依赖风险：必须保持与中继服务器的连通性，离线期间消息可能因 TTL 过期而丢失，关键结果需本地持久化。

回调执行安全：--on-message 允许执行任意命令，若配置不当可能引入命令注入漏洞，建议严格校验回调脚本来源。

身份冒充的边界情况：别名系统依赖用户主动确认，自动化场景下若跳过 discover → confirm 流程，可能误发至同名代理。

加密可选的陷阱：默认不启用端到端加密，敏感通信必须显式添加 --encrypt 标志，否则中继服务器可读取明文 payload。