核心用法
OCFT（OpenClaw File Transfer Protocol）是一套专为AI代理设计的P2P文件传输协议，允许通过任意文本聊天频道（Telegram、Discord、Slack等）完成文件传递。
工作流程：
1. ocft init 生成唯一节点ID和密钥
2. ocft export 分享连接URI给对等方
3. ocft add-peer 或 ocft import 建立可信关系
4. 发送方通过聊天发送 🔗OCFT: 前缀的Base64编码消息，接收方自动识别并下载
文件被分割为48KB块（适配Base64编码后的消息长度限制），每块附带SHA-256校验，支持断点续传。
显著优点
- 零基础设施依赖：复用现有聊天渠道，无需专用服务器或开放端口
- 跨平台兼容：任何支持纯文本的通信平台均可承载
- 安全可控：白名单机制 + 密钥TTL，避免公开暴露接收端
- 传输可靠：分块校验 + 断点续传，适应不稳定网络
- 代理原生设计：消息格式专为AI代理解析优化
潜在局限
- 效率瓶颈：48KB块 + Base64编码导致实际吞吐量约为原始数据的1/3，大文件（上限100MB）传输耗时较长
- 平台限制：依赖聊天平台的单条消息长度限制，部分平台可能截断
- 无中继能力：严格P2P，双方需同时在线或依赖聊天记录持久化
- 密钥管理负担：手动导入/导出URI对非技术用户不够友好
- 生态早期：作为新兴协议，长期维护与兼容性存疑
适合人群
- 多AI代理协作的开发者与研究者
- 需要在隔离网络环境中传输文件的DevOps团队
- 追求最小权限原则、拒绝开放服务端口的隐私敏感用户
常规风险
| 风险项 | 说明 | 缓解建议 |
|--------|------|----------|
| 密钥泄露 | `show-secret` 直接暴露完整密钥 | 避免在共享屏幕/日志中使用，设置短TTL |
| 中间人篡改 | 聊天平台若被入侵，可注入伪造块 | 依赖SHA-256校验，但首次密钥交换需安全信道 |
| 存储路径遍历 | `set-download` 若配置不当可能导致写入敏感目录 | 验证路径权限，避免使用root可写目录 |
| 拒绝服务 | 超大文件或恶意高频请求消耗资源 | 利用max-file-size限制，监控对等方行为 |