1. 项目概述：为AI Agent构建去中心化的“身份护照”与“加密邮局”

在AI Agent（智能体）的世界里，我们正面临一个尴尬的现状：这些被设计来执行复杂任务的“数字员工”们，彼此之间却缺乏一套可靠、私密且可验证的沟通基础设施。想象一下，你的财务Agent需要向你的数据分析Agent请求一份报表，或者一个供应链Agent需要向另一个物流Agent确认发货状态。目前，这类交互要么通过臃肿的API网关，要么依赖中心化的消息平台，不仅引入了单点故障和审查风险，更关键的是，我们无法真正信任消息的来源和完整性——你怎么知道这条指令真的是来自你授权的那个Agent，而不是一次精心伪装的“提示词注入”攻击？

这正是CELLO协议及其官方客户端 cello-client 要解决的核心问题。简单来说，CELLO试图为AI Agent建立一个去中心化的、基于密码学原语的“社交网络”。它不是一个平台，而是一套协议标准，让Agent之间能够像拥有“数字护照”和“加密邮局”一样，进行点对点的、可验证的、防篡改的通信。 cello-client 就是你为你的Agent申请这本“护照”并接入这个“邮局”的官方工具包。

这个项目的价值在于，它将区块链和密码学中成熟的身份验证、数字签名和防篡改记录（Merkle树）技术，巧妙地应用到了AI Agent的协作场景中。它不试图创造一个新的中心化平台来“管理”Agent，而是提供一套工具，让Agent自己掌握自己的身份和通信主权。对于任何正在构建多Agent系统、关注Agent间安全通信、或希望实现跨组织Agent协作的开发者来说，理解并尝试CELLO都是一个极具前瞻性的选择。

2. 核心设计思路：为什么是“通道”而非“平台”？

要理解CELLO，首先要跳出“中心化服务”的思维定式。它的设计哲学非常明确： 通信通道化，信任密码学化，记录去中心化 。这三点构成了其架构的基石。

2.1 通道化通信：像对接WhatsApp一样对接CELLO

CELLO将自己定位为一个“通道”（Channel）。这是一个极其精妙且实用的抽象。对于Agent开发者而言，为Agent添加一个新的沟通渠道，比如接入Telegram或Discord的API，是一个已经非常熟悉的模式。CELLO沿用了这一模式，它希望成为Agent通讯录里的又一个“联系人”。这意味着集成成本被大大降低，开发者无需重构整个Agent的架构，只需像添加一个消息平台适配器一样，将CELLO客户端集成进去。

这种设计带来的直接好处是 兼容性 和 渐进式采用 。你的Agent可以同时保有传统的API接口、其他消息平台通道以及CELLO通道。你可以先从非关键性的、内部Agent间的通信开始试用CELLO，逐步将其扩展到更敏感或更重要的交互场景中。它不是一个“全有或全无”的颠覆性方案，而是一个可以平滑嵌入现有系统的增强模块。

2.2 密码学化的信任：用代码而非合同建立共识

传统Agent间通信的信任，往往依赖于复杂的API密钥管理、IP白名单或基于OAuth的中心化认证服务。这些方法要么管理繁琐，要么存在中心化风险。CELLO的答案是：让密码学来做这份“信任担保”的工作。

  1. 出站签名与哈希 ：每当你的Agent通过CELLO发送一条消息时， cello-client 会使用该Agent的私钥对消息内容进行数字签名，并计算其哈希值。接收方可以使用发送方公开的公钥验证签名，并通过比对哈希值来确认消息在传输过程中未被篡改。这解决了 身份认证 和 数据完整性 问题。
  2. 入站提示词注入扫描 ：在接收端，所有传入的消息在送达你的Agent主逻辑之前，都会先经过一个安全检查点，扫描是否存在潜在的提示词注入攻击。这相当于为你的Agent配备了一个“安检门”，将恶意指令拦截在核心逻辑之外。这是许多现有Agent框架所缺乏的、面向AI安全的关键防护层。
  3. Merkle记录对话 ：整个对话过程会被记录并构建成一棵Merkle树。Merkle树是一种密码学数据结构，它能高效、安全地验证大量数据中任何一部分的完整性。将对话记录Merkle化，意味着任何一方都无法事后抵赖或篡改对话历史。这提供了 不可否认性 和 可审计性 ，为Agent间的协作争议提供了密码学证据。

注意 ：这里提到的“私钥”、“公钥”和“Merkle树”都是本地生成和处理的。在标准模式下，CELLO协议本身并不运行一个区块链，也不要求将对话记录上链。这些密码学操作在客户端本地完成，其目的是生成可验证的凭证，而非依赖某个共识网络。这避免了区块链的性能和成本问题，同时保留了密码学验证的核心优势。

2.3 去中心化的目录服务：找到你想对话的Agent

Agent之间要通信，首先得知道对方的存在和联系方式。CELLO设计了一个“目录”（Directory）服务。根据其文档，首次运行 cello-client 的MCP服务器时，会通过WhatsApp或Telegram注册你的Agent。这个设计很有意思，它利用现有、普及的通信应用作为初始身份验证和发现的桥梁，降低了冷启动门槛。

这个目录很可能是一个去中心化或联邦式的设计，Agent可以发布自己的公钥、能力描述（Capabilities）和联系通道。其他Agent则可以通过 cello_find_agents 这样的工具来搜索目录，找到具备特定技能（如“数据可视化”、“代码审查”）的、可信任的Agent。这构建了一个动态的、去中心化的Agent服务市场雏形。

3. 核心组件与集成路径深度解析

cello-client 仓库的结构清晰地反映了其两种主要集成方式： 通用的MCP服务器 和 深度的原生适配器 。理解这两种路径的适用场景和实现细节，是做出正确技术选型的关键。

3.1 MCP服务器：快速启动的“万能适配器”

这是目前 cello-client 最成熟、最推荐给大多数用户的集成方式。MCP（Model Context Protocol）是由Anthropic提出的一种协议，旨在为AI模型（如Claude）提供标准化的工具调用和上下文扩展能力。现在，许多先进的AI Agent框架（如Claude Code、Cursor等）都内置了MCP客户端支持。

工作原理 ： 当你执行 claude mcp add cello npx @cello/mcp-server 时，发生了以下几件事：

  1. 服务器启动 ：命令会从npm拉取 @cello/mcp-server 包并启动一个本地MCP服务器进程。
  2. 协议握手 ：你的AI Agent（如Claude Desktop）作为MCP客户端，会与这个本地服务器建立连接。
  3. 工具暴露 ：CELLO MCP服务器向Agent暴露四个核心工具（ cello_scan_message , cello_find_agents , cello_send_message , cello_check_trust ）。现在，你的Agent在思考时，就可以像调用“计算器”或“网络搜索”一样，自然地调用这些CELLO工具。

实操要点与心得 ：

  • 环境依赖 ：确保你的系统已安装Node.js（建议LTS版本）和npm。MCP服务器本质上是一个Node.js应用。
  • 首次运行流程 ：首次添加MCP服务器时，它会引导你完成Agent注册。根据文档，这个过程需要通过WhatsApp或Telegram完成。我推测流程可能是：MCP服务器生成一个临时二维码或链接，你用手机扫码，在熟悉的聊天应用中完成一个简短的验证交互（比如回复一个随机码），从而将你的聊天应用账号与这个新创建的Agent身份绑定。这一步至关重要，它完成了初始的身份锚定和密钥对生成。
  • 密钥管理 ：生成的私钥会安全地存储在本地（例如，在用户目录下的 .cello 文件夹中）。 务必妥善备份这个密钥目录 。丢失私钥意味着你的Agent身份将无法恢复，所有之前的签名对话都无法被验证。
  • 工具调用场景 ：
    • 主动防护 ：在你的Agent处理任何外部输入（如用户提问、API回调）前，可以先用 cello_scan_message 过一遍。这应该成为一个习惯性操作。
    • 信任先行 ：在让Agent自动代表你向另一个Agent发送敏感指令（如“支付账单”、“部署代码”）前，先使用 cello_check_trust 查询对方的信任档案。
    • 服务发现 ：当你的Agent需要完成一个复杂任务时，它可以主动使用 cello_find_agents 寻找具备相关能力的、可信任的协作Agent，实现动态的任务分解与外包。

3.2 原生适配器：为性能与深度控制而生

MCP方式虽然通用，但毕竟多了一层进程间通信（IPC）的开销，并且受限于MCP协议定义的工具调用模型。对于追求极致性能、低延迟，或需要更深度集成CELLO协议能力（例如，直接处理协议级别的握手、流式消息加密等）的Agent框架，原生适配器是更优的选择。

cello-client 仓库的 adapters/ 目录下规划了针对一系列名为“Claw”变体及其他流行Agent框架的适配器。从命名（OpenClaw, NanoClaw, IronClaw等）看，这很可能是一个家族化的Agent体系。每个适配器都会用对应Agent框架的母语（TypeScript, Rust, Python, Go）实现，直接集成CELLO协议的核心库。

选型考量 ：

  • 如果你的Agent基于这些框架 ：那么等待对应的原生适配器是值得的。它将提供更佳的运行时性能、更紧密的API集成（可能以SDK形式提供）以及更精细的控制能力。
  • 状态与规划 ：需要清醒认识到，目前所有适配器都处于“Planned”（计划中）状态。这意味着代码尚未实现。如果你急需此功能，可能需要基于 core/ 库自行实现，或暂时采用MCP方案。
  • 核心库是关键 ：无论哪种适配器，其底层都将依赖 cello-client/core/ 目录下的Node.js/TypeScript核心协议实现。这个核心库是CELLO协议的权威实现，包含了密钥管理、消息签名/验证、Merkle树构建、目录服务交互等所有基础能力。研究这个核心库的代码（待实现后）是深入理解协议细节的最佳途径。

4. 从零开始：基于MCP的集成实操全记录

假设我们正在为一个已有的、基于Claude API的自动化客服Agent增加CELLO能力，以实现与公司内部数据分析Agent的安全通信。我们将采用MCP服务器方案，因为这是最快、最通用的路径。

4.1 环境准备与依赖安装

首先，确保你的开发环境满足要求。这个Agent可能运行在一台云服务器或本地开发机上。

# 1. 检查Node.js环境，建议版本 >= 18
node --version

# 2. 在Agent项目目录下，初始化npm（如果尚未初始化）
npm init -y

# 3. 虽然MCP服务器通过npx运行，但为了管理方便，可以将其作为开发依赖安装
npm install --save-dev @cello/mcp-server

提示 ：将 @cello/mcp-server 作为项目依赖安装，可以锁定特定版本，避免因全局npx拉取最新版可能带来的意外变更，更适合生产环境。

4.2 配置Claude Desktop以集成CELLO MCP服务器

我们的客服Agent可能通过Claude Desktop的API进行交互。配置Claude Desktop加载自定义MCP服务器。

  1. 定位Claude配置 ：Claude Desktop的配置通常位于 ~/.config/Claude/claude_desktop_config.json （Linux/macOS）或 %APPDATA%\Claude\claude_desktop_config.json （Windows）。
  2. 编辑配置文件 ：在配置文件中添加或修改 mcpServers 部分。 
    {
  "mcpServers": {
    "cello": {
      "command": "npx",
      "args": ["@cello/mcp-server"]
    }
    // ... 其他已有的MCP服务器配置
  }
}
  3. 重启Claude Desktop ：保存配置文件并完全重启Claude Desktop应用，使配置生效。

4.3 首次运行与身份注册

重启后，Claude Desktop会在后台启动CELLO MCP服务器。首次启动会触发注册流程。

  1. 观察日志 ：查看Claude Desktop的日志输出或系统控制台。你应该能看到类似“正在注册Agent...”和“请使用WhatsApp扫描二维码以验证身份”的信息。
  2. 完成验证 ：使用你的手机WhatsApp（或Telegram，取决于提示）扫描出现的二维码。按照提示完成简单的验证步骤，例如在聊天窗口中发送一个特定的验证码。
  3. 密钥生成 ：验证成功后，服务器会在本地（如 ~/.cello/keys/ ）生成一对非对称加密密钥（私钥和公钥）。公钥可能会被发送到CELLO目录服务进行注册。
  4. 确认成功 ：注册完成后，你可以在Claude的对话中测试。尝试问Claude：“你现在有哪些可用的工具？” 在返回的工具列表中，你应该能看到 cello_scan_message , cello_send_message 等工具，这标志着集成成功。

4.4 在Agent逻辑中调用CELLO工具

现在，我们需要修改客服Agent的自动化逻辑，在关键节点插入CELLO调用。以下是一个概念性的TypeScript伪代码示例：

// 假设我们有一个处理用户消息的函数
async function handleIncomingMessage(externalMessage: string, senderContext: any) {
  // 第一步：安全检查 - 扫描提示词注入
  const scanResult = await mcpClient.invokeTool('cello_scan_message', {
    message: externalMessage,
    context: `来自用户 ${senderContext.id} 的查询`
  });

  if (scanResult.isMalicious) {
    console.warn(`检测到潜在提示词注入攻击，来自 ${senderContext.id}。详情：${scanResult.details}`);
    // 执行安全策略：记录日志、告警、返回无害默认响应
    return "抱歉，我无法处理这个请求。";
  }

  // 第二步：业务逻辑处理（例如，判断是否需要求助数据分析Agent）
  if (externalMessage.includes('销售趋势')) {
    // 第三步：查找可信任的数据分析Agent
    const foundAgents = await mcpClient.invokeTool('cello_find_agents', {
      capability: 'data_analysis',
      requiredTrustLevel: 'high'
    });

    if (foundAgents.length > 0) {
      const dataAgent = foundAgents[0]; // 选择第一个高信任度的Agent
      
      // 第四步：发送签名消息
      const response = await mcpClient.invokeTool('cello_send_message', {
        recipientAgentId: dataAgent.id,
        message: `请分析过去30天的销售数据，并总结核心趋势。`,
        requestId: generateUniqueId() // 用于追踪对话
      });

      // 第五步：将数据分析结果整合到给用户的回复中
      return `根据最新分析，${response.analysisSummary}。详情已发送至您的仪表板。`;
    }
  }

  // ... 其他常规处理逻辑
}

这个例子展示了如何将CELLO的工具无缝编织到Agent的现有决策流中，为其增添了安全扫描和可信协作的能力。

5. 潜在挑战、排查技巧与未来展望

作为一个处于“预实现”阶段的前沿项目，在实际集成和使用 cello-client 的过程中，我们很可能会遇到一系列挑战。以下是我基于类似项目经验，对可能问题的预判和解决思路。

5.1 常见问题与排查指南

问题现象 可能原因 排查步骤与解决方案
MCP服务器添加失败 1. Node.js/npm未安装或版本过低。
2. 网络问题，无法从npm拉取包。
3. Claude Desktop版本过旧，不支持MCP。		 1. 运行 node -v 和 npm -v 确认版本。建议Node.js >= 18。
2. 检查网络连接，尝试 npm view @cello/mcp-server 查看包信息。
3. 更新Claude Desktop到最新版本。
注册时二维码不出现或验证失败 1. CELLO目录服务临时不可用。
2. WhatsApp/Telegram链接超时。
3. 本地防火墙或代理阻止了连接。		 1. 稍后重试，查看项目GitHub Issues或社区状态公告。
2. 确保手机和运行Agent的机器在可互通的网络下。
3. 检查本地网络设置，临时关闭防火墙或配置代理规则。
Agent无法调用CELLO工具 1. MCP服务器未成功启动。
2. Claude Desktop配置错误。
3. 工具名称调用错误。		 1. 重启Claude Desktop，查看日志中是否有MCP服务器错误。
2. 仔细核对 claude_desktop_config.json 中的 command 和 args 路径。
3. 在Claude对话中直接输入“列出所有工具”，确认工具名是否正确。
cello_send_message 发送失败 1. 目标Agent ID不存在或已离线。
2. 本地私钥损坏或丢失。
3. 消息格式不符合协议要求。		 1. 使用 cello_find_agents 再次确认目标Agent状态。
2. 检查 ~/.cello/keys/ 目录，确认私钥文件存在且可读。如有备份可尝试恢复。
3. 查阅未来将发布的协议文档，确保消息结构正确。
性能延迟感知明显 1. MCP IPC通信开销。
2. 密码学运算（签名、哈希）在大量消息下的开销。
3. 目录服务查询网络延迟。		 1. 对于高性能场景，等待对应你Agent框架的 原生适配器 。
2. 考虑对非关键消息降低签名强度或进行批量签名验证。
3. 在本地缓存常用的、可信的Agent目录信息。

5.2 安全与隐私的深度考量

集成CELLO意味着将密码学密钥和通信安全托付给这个新的协议栈，我们必须深思几个问题：

  • 私钥存储安全 ： cello-client 默认将私钥存储在用户目录下。在生产环境中，这远远不够。 必须 结合硬件安全模块（HSM）、云服务商提供的密钥管理服务（如AWS KMS, GCP Cloud KMS）或至少是经过加密的密钥库来管理私钥。私钥一旦泄露，攻击者就可以冒充你的Agent。
  • 目录服务的去中心化程度 ：目录服务是发现其他Agent的关键。我们需要了解它是完全去中心化的（如基于DHT），还是由Mygentic AI或其他组织维护的联邦式服务。这关系到审查抵抗性和服务的长期稳定性。关注其白皮书或详细架构文档至关重要。
  • 协议审计与实现成熟度 ：密码学协议的设计和实现极其复杂，微小的漏洞都可能导致整个安全模型崩塌。在 cello-client 实现稳定后，社区应推动对其核心密码学实现和协议规范进行独立的安全审计。

5.3 生态发展与应用场景展望

CELLO协议如果发展顺利，可能催生出一个繁荣的AI Agent“可信协作生态”。我能想到的几个激动人心的场景：

  1. 跨组织自动化工作流 ：公司的采购Agent可以直接与供应商的库存Agent进行可验证的、不可抵赖的订单确认和物流跟踪对话，无需复杂的EDI系统集成。
  2. 去中心化AI服务市场 ：开发者可以发布一个具备“图像生成”能力的Agent到CELLO目录，其他Agent通过支付微小的、可验证的费用（或许结合加密货币）来使用该服务，形成真正的AI经济。
  3. 复合型超级Agent ：一个“项目经理”Agent可以动态地发现、雇佣并协调一群具备专项技能的Agent（设计、编码、测试、文案），共同完成一个复杂项目，所有交互和承诺都有密码学记录。
  4. 对抗AI欺诈与深度伪造 ：在重要的官方公告或法律文书中，可以由签发机构的官方Agent进行数字签名。接收方可以通过验证签名，确认信息确实来源于可信源头，而非伪造的AI生成内容。

cello-client 是这个宏大愿景的第一步，也是最务实的一步。它没有一开始就追求过于复杂的共识机制或代币经济，而是聚焦于解决最根本的“身份”和“可信通信”问题，并通过MCP等现有标准降低采用门槛。这种务实的设计增加了其成功的可能性。

我个人对这类基础设施项目保持高度关注，因为历史告诉我们，真正的生态爆发往往始于一个简单、专注且解决真问题的协议。对于开发者而言，现在开始了解并尝试CELLO，不仅是在为你的Agent增加一项安全功能，更可能是在提前熟悉未来AI Agent间交互的“通用语言”。在集成过程中，多关注其密钥管理实践，思考如何将其安全地融入你的现有架构，并积极参与社区讨论，你的实践经验将非常宝贵。

# 去中心化
Logo
亚马逊云科技技术品牌专区

更多推荐

cover

DeepSeek API涨价500%！Agent框架同步开源

avatar 亚马逊云科技技术品牌专区
cover

DeepSeek 又放大招！开源 AI Agent 框架 Harness：一切皆插件

avatar 亚马逊云科技技术品牌专区
cover

Agent Run 的状态机：别把智能体交给 LLM 自己管

avatar 亚马逊云科技技术品牌专区