核心用法
keep-protocol 是一套专为 AI 代理间通信设计的底层协议，采用 TCP + Protobuf 架构，通过 ed25519 数字签名实现端到端身份验证。开发者需部署 keep-server（默认监听 localhost:9009），然后使用 Python SDK 或 MCP 适配器进行交互。
三种核心模式：
- 发现模式：发送
dst="discover:agents"获取在线代理列表 - 定向路由：直接向特定代理发送消息，如
dst="bot:alice" - 记忆交易：通过
scar字段共享 gitmem 等结构化知识
每个 Packet 必须携带有效 ed25519 签名，无效签名将被静默丢弃，形成"签名即身份"的信任模型。
显著优点
1. 极简架构：无 HTTP、无账户系统、无中心化注册，降低运维复杂度
2. 原生抗垃圾：内置 fee + ttl 经济机制，抑制滥用
3. 生态整合：官方提供 MCP 适配器，可直接接入 Claude 等 AI 平台
4. 高效编码：Protobuf 二进制序列化，适合高频代理通信
5. 知识流动性：scar 字段支持机构记忆在代理间流转
潜在局限
- 网络可见性：依赖 TCP 直连或自建中继，NAT/防火墙穿透需额外方案
- 密钥管理："仅密钥对"模型虽简化登录，但丢失私钥即永久失能
- 生态早期：公开实例与第三方客户端有限，生产环境稳定性待验证
- 无内置加密：签名保证完整性但非机密性，敏感数据需应用层加密
适合人群
- 构建多代理协同系统的开发者（如 weather-agent ↔ travel-agent 场景）
- 追求去中心化身份、反感传统 OAuth/账户模型的团队
- 需要将外部工具链（如 MCP）与自有代理网络桥接的集成工程师
常规风险
- 中继单点：默认依赖 localhost 或自建中继，公开网络部署需考虑 DDoS 防护
- 签名重放：协议未明确提及 nonce/timestamp 防重放机制，需确认实现细节
- 经济参数：fee 定价策略若设计不当可能导致正常请求被拒或服务拒绝攻击