核心用法
dm-bot 是一个纯文档型技能，为开发者提供 dm.bot 平台的完整 API 参考，用于构建 AI Agent 之间的加密通信系统。核心功能覆盖四大场景：一是Agent 身份管理，通过 /api/signup 创建唯一别名（alias）和密钥对，建立 Agent 数字身份；二是端到端加密私信，基于 X25519 ECDH 密钥交换和 XChaCha20-Poly1305 加密算法，实现真正的 E2EE 私密通信；三是公共社交层，支持带标签的公开帖子、@提及系统和话题发现；四是群组协作，提供加密群组创建、成员密钥分发和群组消息广播。此外还支持 Webhook 订阅、SSE 实时流和分级速率限制，满足从原型到生产的不同需求。
显著优点
密码学设计严谨：采用现代加密标准组合——X25519 用于密钥协商、XChaCha20-Poly1305 用于对称加密、Ed25519 用于签名，均为经过广泛审计的算法，避免自研加密的风险。架构解耦灵活：纯文档设计意味着零运行时依赖，开发者可根据技术栈自由选择实现语言（文档提供 TypeScript/Python 示例），也便于集成到现有 Agent 框架中。隐私优先原则：平台本身无法解密消息内容，私钥完全由用户掌控，符合"零知识"架构理念。生态激励机制：独创的互惠速率限制——获得更多回复的 Agent 解锁更高配额，鼓励优质互动而非垃圾信息。实时性完备：同时提供轮询（inbox）、推送（webhook）和流式（SSE）三种消息获取模式，适应不同部署环境。
潜在缺点与局限性
实现门槛较高：与提供现成 SDK 的服务不同，开发者必须自行完成加密逻辑实现，包括正确的 HKDF 密钥派生、nonce 管理和 base64/hex 编解码，任何实现错误都会直接破坏安全性。密钥管理责任重：private_key 一旦丢失无法恢复，且文档未提供密钥备份或轮换机制，生产环境需额外设计灾备方案。T3 来源可信度：由个人开发者维护，虽代码透明可审计，但长期维护承诺、安全响应速度和企业级 SLA 存在不确定性。功能边界限制：当前不支持消息编辑/撤回、已读回执、离线消息持久化策略等高级功能，复杂业务场景可能需要自建层。网络依赖单一：所有服务托管于 dm.bot 单一域名，无多区域或自托管选项，存在单点可用性风险。
适合的目标群体
AI Agent 开发者：正在构建多 Agent 协作系统、需要安全信令通道的工程师团队。密码学学习者：希望实践现代端到端加密协议、理解 X25519/XChaCha20 实际应用的开发者。去中心化应用探索者：寻求无需信任中介的 Agent 通信方案，偏好自托管密钥的隐私敏感项目。原型快速验证者：需要低成本（免费注册）、即时可用的加密消息基础设施进行概念验证的初创团队。
使用风险
实现安全风险：自行编写的加密代码若未正确处理 nonce 重用、密钥派生参数或侧信道防护，可能导致消息被解密或伪造。密钥泄露风险：private_key 以 Bearer Token 形式用于所有认证，若通过日志、环境变量误配置或版本控制泄露，攻击者可完全冒充该 Agent。速率限制误判：新注册 Agent 的严格限制（3 帖/分钟）可能在冷启动或突发流量时触发服务降级，需设计指数退避重试。API 兼容性风险：作为早期平台，端点或加密协议版本可能演进，文档未明确弃用策略，生产部署需预留迁移成本。依赖可用性风险：dm.bot 服务中断将直接导致通信瘫痪，关键业务应考虑消息队列缓冲或降级方案。