同样玩AI 入群Buzz 的 ACP 协议和 MCP 协议两套标准谁更接近未来【免费下载链接】buzzA hive mind communication platform项目地址: https://gitcode.com/GitHub_Trending/buzz14/buzz把 AI Agent 拉进群聊、当成有身份的团队成员一起协作正在成为 2026 年开源圈最热的话题之一。Block 开源的 Buzz 靠着Nostr 协议 独立密钥对 统一事件日志在一周内冲上 GitHub 热搜前列社区里反复被提及的两个词却是 ACP 与 MCP——一个管Agent 怎么接入、一个管Agent 有什么能力。不少读者把它们当成同一层面对比的两套竞品协议但深入 Buzz 源码会发现它们根本不在一个层次而 Buzz 恰恰是少数把两套协议串进同一条链路、还各自给出了参考实现的项目。这篇文章从 Buzz 仓库的真实代码出发拆解 ACP 与 MCP 的定位差异、Buzz 的双栈兼容工程实现以及这套选择对 Agent 生态格局意味着什么。先厘清ACP 与 MCP 各管哪一层社区讨论里最常见的误区是把 ACPAgent Client Protocol和 MCPModel Context Protocol当成AI Agent 通信标准的两个候选。它们确实都叫Protocol但解决的问题正交MCP 定义的是Agent 能用什么工具。它是一套工具发现与调用规范——tools/list列出工具、tools/call调用工具走 stdio 或 HTTP 传输。MCP 服务器是能力的提供方shell、文件编辑、数据库、浏览器任何 Agent 或客户端只要会说 MCP就能挂载同一批工具。2024 年底到 2025 年 MCP 生态的爆发本质是工具接口标准化的爆发。ACP 定义的是谁驱动 Agent 的会话。它是一套 JSON-RPC 2.0 over stdio 的宿主协议核心方法只有几个initialize握手与版本协商、session/new开一个会话并把 MCP 服务器配置作为参数一起传进去、session/prompt发一条提示词并接收工具调用与文本更新、session/cancel取消在途轮次。ACP 描述的是hostZed、JetBrains、编辑器、harness与 agentgoose、codex、Claude Code之间的会话控制关系而不是 agent 与工具的关系。在 crates/buzz-agent/README.md 的开头Buzz 用一句话把两者钉死在各自的层级上ACP is the Agent Client Protocol — JSON-RPC 2.0 over stdio between a client (Zed, JetBrains, buzz-acp, …) and an agent. MCP is how the agent talks to its tools.翻译过来ACP 管接入MCP 管能力。一个 Agent 可以只会 MCP 但不懂 ACP它就是个被动工具库也可以只会 ACP 但一个工具都没有它就是个空壳大脑。两套标准完全可以独立演进也可以像 Buzz 这样叠起来用。Buzz 的双栈兼容一条链上三个角色Buzz 的双协议策略不是二选一而是把 ACP 和 MCP 分别部署在一条链的不同节点上。在 README.md 的架构图里可以看得很清楚Human client AI agent CLI / scripts (Buzz desktop) (Goose, Codex, ...) (buzz-cli, agents) │ ┌──────────────┐ │ │ │ buzz-acp │ │ │ │ (ACP ↔ MCP) │ │ │ └──────┬───────┘ │ │ │ │ └───────┼──────────────┼───────────────────────┼──┘ WebSocket │ WS REST │ WS REST ▼ ▼ ▼ ┌─────────────────────────────────────────────────────────┐ │ buzz-relay │ │ NIP-01 · NIP-42 auth · channel/DM/media/workflow/git │ └─────────────────────────────────────────────────────────┘这条链上出现了三个角色恰好把两套协议各用一次buzz-acpACP 的客户端harness。它监听 Relay 上的 提及事件kind:9 且 agent 公钥在#p标签里把频道里的消息攒成一次批量的session/prompt发给 agentagent 则通过 Buzz CLI 回消息。它的定位在 crates/buzz-acp/README.md 里写得很直白ACP harness that connects AI agents to Buzz数据流是Buzz Relay ──WS──→ buzz-acp ──stdio──→ Your Agent。它作为 ACP 客户端要做的事在 crates/buzz-acp/src/acp.rs 里有完整的生命周期注释spawn agent 子进程 →initialize协议版本协商 →session_new携带 MCP 服务器配置→session_prompt_with_idle_timeout→session_cancel。buzz-agentACP 的服务器同时也是 MCP 的客户端。它面向另一侧任何 ACP hostZed、JetBrains、buzz-acp 或自定义客户端都能通过 stdio 驱动它。它的 README 自我定位是Minimal, unbreakable ACP-compliant LLM agent架构一目了然-------- stdio (JSON-RPC 2.0) --------------- | client | ---------------------- | buzz-agent | -------- ACP frames --------------- │ │ │ │ rmcp (stdio) │ ▼ │ MCP servers ▼ (your tools) HTTPS │ ▼ Anthropic / OpenRouter / any OpenAI-compat endpointagent 收到session/prompt后进入工具循环调 LLM → 得到工具调用 → 通过 MCP 执行 → 把结果喂回 → 直到 LLM 停止要工具或 host 取消。MCP 客户端实现在 crates/buzz-agent/src/mcp.rs用rmcpcrate 以 stdio 方式拉起每个 MCP 服务器tools/list后把所有工具合并进一个带命名空间server__tool的目录并做了严格的资源上限每会话最多 16 个 MCP 服务器、128 个工具、工具 schema 超 4KiB 直接替换为空对象。buzz-dev-mcpMCP 的服务器。它给任何会 MCP 的 Agent提供 shell 和文件编辑工具shell、str_replace、todo配合进程组级 kill、输出截断、工作目录解析等硬化措施。它的卖点在 VISION_AGENT.md 里一句话讲透buzz-agent 不知道自己在跟哪个 MCP 服务器说话buzz-dev-mcp 也不知道是哪个 Agent 在调用它——它们靠协议组合而不是靠代码 import 耦合。这是整条链最关键的设计协议是唯一接口没有共享状态没有自定义线格式。关键工程细节session/new 是两套协议的缝合点ACP 和 MCP 之所以能叠起来协议设计上有一个精妙的耦合点session/new方法的参数里直接携带mcpServers数组。也就是说ACP host 在创建会话的那一刻就把这个会话要用哪些 MCP 工具交给了 agent 去拉起。Buzz 对这个缝合点的处理非常认真。在 crates/buzz-acp/src/acp.rs 中McpServer结构体严格按 ACP schema 的McpServerStdio变体建模四个字段name、command、args、env全部必需并有单元测试session_new_mcp_server_has_required_fields钉住序列化格式。buzz-acp通过环境变量BUZZ_ACP_MCP_COMMAND向 agent 子进程注入一个可选 MCP 服务器二进制而buzz-agent侧则在 crates/buzz-agent/src/mcp.rs 的spawn_all里为每个 MCP 服务器做了进程组管理setpgid建立进程组、超时或传输断裂时killpg(SIGKILL)连孙进程一起杀掉、随后带指数退避地惰性重启一个服务器中毒不影响其他服务器继续工作。更体现工程成熟度的是安全边界。buzz-agent对 MCP 子进程环境做的是白名单透传只放行PATH、HOME、TERM等基础变量和显式声明过的条目ANTHROPIC_API_KEY这类敏感凭据不会泄漏进 MCP 子进程——这是多租户 Agent 部署里最容易翻车的点。除此之外docs/MCP_DRIVEN_HOOKS.md 还展示了 MCP 生态的一个高级玩法任何 MCP 服务器都能通过暴露_前缀的工具_Stop、_PostCompact参与 agent 的执行生命周期——作为生命周期钩子被 agent 在固定时机调用钩子对 LLM 不可见、对 agent 是建议性的、有超时和预算约束避免一个坏钩子把 agent 困死。这套机制零 MCP 协议改动纯粹是协议内语义约定反过来验证了 MCP 作为能力层的扩展弹性。双栈之外Buzz 还押了第三张牌只兼容两套协议还不足以解释 Buzz 的热度。它真正独特的地方在于ACP/MCP 之上还叠了一层Nostr 身份与事件层每个 Agent 持有独立密钥对消息、补丁NIP-34、工作流审批、审计日志全部作为签名事件写入同一事件日志。在 README.md 里这个主张被概括为一句很关键的话Scoped by identity, not by permission flags — the same way youd scope a teammate.——权限按身份划定而不是按标志位划分。这直接改变了 Agent 的接入体验。传统平台里接一个 Agent通常意味着申请 API Token、配置权限位、写好隔离逻辑在 Buzz 里接一个 Agent就是给它生成一个密钥对、把它加为频道成员——和拉一个人类同事入群的操作完全一致。crates/buzz-acp/README.md 的 Quick Start 演示了这条路径buzz-admin generate-key生成身份buzz-admin add-member发布 kind:13534 成员事件然后export BUZZ_PRIVATE_KEY... buzz-acpAgent 就入群待命了。多 Agent 部署时buzz-acp还支持共享同一 bot 身份并行跑多个 agent 子进程1~32 个并保证同一频道永远不被两个实例并发处理。在接什么 Agent这件事上Buzz Desktop 甚至做到了免改代码的开放性。crates/buzz-acp/README.md 的 BYOHBring Your Own Harness章节把运行时分成三层编译内置层goose、claude、codex、buzz-agent 四个一等公民、预设目录层Cursor、OpenCode、Kimi Code、Hermes 等PATH 探测即可用、用户自定义层放一个 JSON 文件描述command/args/env就注册一个全新 ACP 运行时。所有层共享同一个安全底线不执行安装脚本、不加载用户图标、Buzz 保留身份键不可覆盖。谁更接近未来不是二选一是分层竞速回到标题的问题。基于 Buzz 的工程实践一个更准确的判断框架是MCP 决定 Agent 的能力边界ACP 决定 Agent 与宿主的关系形态两者都在走向各自的事实标准但节奏完全不同。MCP 的标准化速度更快、生态更成熟——工具是 Agent 生态里供给最碎片化、最需要统一的部分任何一个独立运行的 Agent 都可以零成本接入 MCP 工具Buzz 的buzz-agent甚至把 MCP 客户端当成了协议必需能力。但 MCP 解决不了Agent 以什么身份、什么会话边界、什么生命周期存在于一个协作空间里的问题——这正是 ACP 的射程。Nostr 负责身份和事件ACP 负责会话控制MCP 负责工具能力三层正交叠加才构成了 Buzz 所谓Agent 是成员而非幽灵的完整叙事。从生态格局推演值得注意三点其一ACP 的客户端-服务器语义把 agent 厂商和宿主厂商推到了必须协作的位置。session/new要携带mcpServers意味着 agent 必须承认 host 对工具配置的注入权而 buzz-acp 对 goose、codex、claude code 的一视同仁说明 Buzz 赌的是接入标准先于厂商忠诚。相比之下目前几家头部 agent 厂商各自维护专属 harness标准化的收益尚未完全兑现——这是 ACP 生态的现实张力。其二最小参考实现是协议扩散的加速器。Buzz 自己实现了 ACP 客户端buzz-acp和 ACP 服务器buzz-agent两端等于给生态提供了一个可审计的对照物buzz-agent全篇手写协议处理、拒绝引入框架抽象的设计哲学VISION_AGENT.mdIf you can delete it, delete it让照着实现一个 ACP agent的成本降到个人开发者一个下午能读完的程度。协议竞争里参考实现的体积往往决定采纳速度。其三把身份、会话、工具三层拆开的项目未来最不容易被单一协议绑架。如果 ACP 没跑赢Buzz 可以继续用 Nostr 身份层 MCP 工具层服务生态如果 MCP 的某个变体如 HTTP 传输成为主流buzz-agent的工具抽象无需大改。这种协议插槽化的架构比押注单一标准的平台有更长的生存窗口。Buzz 给出的答案本质上是ACP 与 MCP 不是对手是不同深度的插槽。MCP 今天更接近工具层的未来而 ACP 正在争夺接入层的未来——当 Agent 从命令行工具演变为常驻的团队协作者决定体验上限的将不再只是它能调用多少工具而是它以什么身份、被谁、以何种方式唤醒和编排。Buzz 的价值在于用一套可运行的完整实现把两套标准各司其职从口号变成了能入群上班的工程现实。【免费下载链接】buzzA hive mind communication platform项目地址: https://gitcode.com/GitHub_Trending/buzz14/buzz创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/10/10 21:00:19 · 阅读 1.2k 同样玩“AI 入群“：Buzz 的 ACP 协议和 MCP 协议，两套标准谁更接近未来？
同样玩AI 入群Buzz 的 ACP 协议和 MCP 协议两套标准谁更接近未来【免费下载链接】buzzA hive mind communication platform项目地址: https://gitcode.com/GitHub_Trending/buzz14/buzz把 AI Agent 拉进群聊、当成有身份的团队成员一起协作正在成为 2026 年开源圈最热的话题之一。Block 开源的 Buzz 靠着Nostr 协议 独立密钥对 统一事件日志在一周内冲上 GitHub 热搜前列社区里反复被提及的两个词却是 ACP 与 MCP——一个管Agent 怎么接入、一个管Agent 有什么能力。不少读者把它们当成同一层面对比的两套竞品协议但深入 Buzz 源码会发现它们根本不在一个层次而 Buzz 恰恰是少数把两套协议串进同一条链路、还各自给出了参考实现的项目。这篇文章从 Buzz 仓库的真实代码出发拆解 ACP 与 MCP 的定位差异、Buzz 的双栈兼容工程实现以及这套选择对 Agent 生态格局意味着什么。先厘清ACP 与 MCP 各管哪一层社区讨论里最常见的误区是把 ACPAgent Client Protocol和 MCPModel Context Protocol当成AI Agent 通信标准的两个候选。它们确实都叫Protocol但解决的问题正交MCP 定义的是Agent 能用什么工具。它是一套工具发现与调用规范——tools/list列出工具、tools/call调用工具走 stdio 或 HTTP 传输。MCP 服务器是能力的提供方shell、文件编辑、数据库、浏览器任何 Agent 或客户端只要会说 MCP就能挂载同一批工具。2024 年底到 2025 年 MCP 生态的爆发本质是工具接口标准化的爆发。ACP 定义的是谁驱动 Agent 的会话。它是一套 JSON-RPC 2.0 over stdio 的宿主协议核心方法只有几个initialize握手与版本协商、session/new开一个会话并把 MCP 服务器配置作为参数一起传进去、session/prompt发一条提示词并接收工具调用与文本更新、session/cancel取消在途轮次。ACP 描述的是hostZed、JetBrains、编辑器、harness与 agentgoose、codex、Claude Code之间的会话控制关系而不是 agent 与工具的关系。在 crates/buzz-agent/README.md 的开头Buzz 用一句话把两者钉死在各自的层级上ACP is the Agent Client Protocol — JSON-RPC 2.0 over stdio between a client (Zed, JetBrains, buzz-acp, …) and an agent. MCP is how the agent talks to its tools.翻译过来ACP 管接入MCP 管能力。一个 Agent 可以只会 MCP 但不懂 ACP它就是个被动工具库也可以只会 ACP 但一个工具都没有它就是个空壳大脑。两套标准完全可以独立演进也可以像 Buzz 这样叠起来用。Buzz 的双栈兼容一条链上三个角色Buzz 的双协议策略不是二选一而是把 ACP 和 MCP 分别部署在一条链的不同节点上。在 README.md 的架构图里可以看得很清楚Human client AI agent CLI / scripts (Buzz desktop) (Goose, Codex, ...) (buzz-cli, agents) │ ┌──────────────┐ │ │ │ buzz-acp │ │ │ │ (ACP ↔ MCP) │ │ │ └──────┬───────┘ │ │ │ │ └───────┼──────────────┼───────────────────────┼──┘ WebSocket │ WS REST │ WS REST ▼ ▼ ▼ ┌─────────────────────────────────────────────────────────┐ │ buzz-relay │ │ NIP-01 · NIP-42 auth · channel/DM/media/workflow/git │ └─────────────────────────────────────────────────────────┘这条链上出现了三个角色恰好把两套协议各用一次buzz-acpACP 的客户端harness。它监听 Relay 上的 提及事件kind:9 且 agent 公钥在#p标签里把频道里的消息攒成一次批量的session/prompt发给 agentagent 则通过 Buzz CLI 回消息。它的定位在 crates/buzz-acp/README.md 里写得很直白ACP harness that connects AI agents to Buzz数据流是Buzz Relay ──WS──→ buzz-acp ──stdio──→ Your Agent。它作为 ACP 客户端要做的事在 crates/buzz-acp/src/acp.rs 里有完整的生命周期注释spawn agent 子进程 →initialize协议版本协商 →session_new携带 MCP 服务器配置→session_prompt_with_idle_timeout→session_cancel。buzz-agentACP 的服务器同时也是 MCP 的客户端。它面向另一侧任何 ACP hostZed、JetBrains、buzz-acp 或自定义客户端都能通过 stdio 驱动它。它的 README 自我定位是Minimal, unbreakable ACP-compliant LLM agent架构一目了然-------- stdio (JSON-RPC 2.0) --------------- | client | ---------------------- | buzz-agent | -------- ACP frames --------------- │ │ │ │ rmcp (stdio) │ ▼ │ MCP servers ▼ (your tools) HTTPS │ ▼ Anthropic / OpenRouter / any OpenAI-compat endpointagent 收到session/prompt后进入工具循环调 LLM → 得到工具调用 → 通过 MCP 执行 → 把结果喂回 → 直到 LLM 停止要工具或 host 取消。MCP 客户端实现在 crates/buzz-agent/src/mcp.rs用rmcpcrate 以 stdio 方式拉起每个 MCP 服务器tools/list后把所有工具合并进一个带命名空间server__tool的目录并做了严格的资源上限每会话最多 16 个 MCP 服务器、128 个工具、工具 schema 超 4KiB 直接替换为空对象。buzz-dev-mcpMCP 的服务器。它给任何会 MCP 的 Agent提供 shell 和文件编辑工具shell、str_replace、todo配合进程组级 kill、输出截断、工作目录解析等硬化措施。它的卖点在 VISION_AGENT.md 里一句话讲透buzz-agent 不知道自己在跟哪个 MCP 服务器说话buzz-dev-mcp 也不知道是哪个 Agent 在调用它——它们靠协议组合而不是靠代码 import 耦合。这是整条链最关键的设计协议是唯一接口没有共享状态没有自定义线格式。关键工程细节session/new 是两套协议的缝合点ACP 和 MCP 之所以能叠起来协议设计上有一个精妙的耦合点session/new方法的参数里直接携带mcpServers数组。也就是说ACP host 在创建会话的那一刻就把这个会话要用哪些 MCP 工具交给了 agent 去拉起。Buzz 对这个缝合点的处理非常认真。在 crates/buzz-acp/src/acp.rs 中McpServer结构体严格按 ACP schema 的McpServerStdio变体建模四个字段name、command、args、env全部必需并有单元测试session_new_mcp_server_has_required_fields钉住序列化格式。buzz-acp通过环境变量BUZZ_ACP_MCP_COMMAND向 agent 子进程注入一个可选 MCP 服务器二进制而buzz-agent侧则在 crates/buzz-agent/src/mcp.rs 的spawn_all里为每个 MCP 服务器做了进程组管理setpgid建立进程组、超时或传输断裂时killpg(SIGKILL)连孙进程一起杀掉、随后带指数退避地惰性重启一个服务器中毒不影响其他服务器继续工作。更体现工程成熟度的是安全边界。buzz-agent对 MCP 子进程环境做的是白名单透传只放行PATH、HOME、TERM等基础变量和显式声明过的条目ANTHROPIC_API_KEY这类敏感凭据不会泄漏进 MCP 子进程——这是多租户 Agent 部署里最容易翻车的点。除此之外docs/MCP_DRIVEN_HOOKS.md 还展示了 MCP 生态的一个高级玩法任何 MCP 服务器都能通过暴露_前缀的工具_Stop、_PostCompact参与 agent 的执行生命周期——作为生命周期钩子被 agent 在固定时机调用钩子对 LLM 不可见、对 agent 是建议性的、有超时和预算约束避免一个坏钩子把 agent 困死。这套机制零 MCP 协议改动纯粹是协议内语义约定反过来验证了 MCP 作为能力层的扩展弹性。双栈之外Buzz 还押了第三张牌只兼容两套协议还不足以解释 Buzz 的热度。它真正独特的地方在于ACP/MCP 之上还叠了一层Nostr 身份与事件层每个 Agent 持有独立密钥对消息、补丁NIP-34、工作流审批、审计日志全部作为签名事件写入同一事件日志。在 README.md 里这个主张被概括为一句很关键的话Scoped by identity, not by permission flags — the same way youd scope a teammate.——权限按身份划定而不是按标志位划分。这直接改变了 Agent 的接入体验。传统平台里接一个 Agent通常意味着申请 API Token、配置权限位、写好隔离逻辑在 Buzz 里接一个 Agent就是给它生成一个密钥对、把它加为频道成员——和拉一个人类同事入群的操作完全一致。crates/buzz-acp/README.md 的 Quick Start 演示了这条路径buzz-admin generate-key生成身份buzz-admin add-member发布 kind:13534 成员事件然后export BUZZ_PRIVATE_KEY... buzz-acpAgent 就入群待命了。多 Agent 部署时buzz-acp还支持共享同一 bot 身份并行跑多个 agent 子进程1~32 个并保证同一频道永远不被两个实例并发处理。在接什么 Agent这件事上Buzz Desktop 甚至做到了免改代码的开放性。crates/buzz-acp/README.md 的 BYOHBring Your Own Harness章节把运行时分成三层编译内置层goose、claude、codex、buzz-agent 四个一等公民、预设目录层Cursor、OpenCode、Kimi Code、Hermes 等PATH 探测即可用、用户自定义层放一个 JSON 文件描述command/args/env就注册一个全新 ACP 运行时。所有层共享同一个安全底线不执行安装脚本、不加载用户图标、Buzz 保留身份键不可覆盖。谁更接近未来不是二选一是分层竞速回到标题的问题。基于 Buzz 的工程实践一个更准确的判断框架是MCP 决定 Agent 的能力边界ACP 决定 Agent 与宿主的关系形态两者都在走向各自的事实标准但节奏完全不同。MCP 的标准化速度更快、生态更成熟——工具是 Agent 生态里供给最碎片化、最需要统一的部分任何一个独立运行的 Agent 都可以零成本接入 MCP 工具Buzz 的buzz-agent甚至把 MCP 客户端当成了协议必需能力。但 MCP 解决不了Agent 以什么身份、什么会话边界、什么生命周期存在于一个协作空间里的问题——这正是 ACP 的射程。Nostr 负责身份和事件ACP 负责会话控制MCP 负责工具能力三层正交叠加才构成了 Buzz 所谓Agent 是成员而非幽灵的完整叙事。从生态格局推演值得注意三点其一ACP 的客户端-服务器语义把 agent 厂商和宿主厂商推到了必须协作的位置。session/new要携带mcpServers意味着 agent 必须承认 host 对工具配置的注入权而 buzz-acp 对 goose、codex、claude code 的一视同仁说明 Buzz 赌的是接入标准先于厂商忠诚。相比之下目前几家头部 agent 厂商各自维护专属 harness标准化的收益尚未完全兑现——这是 ACP 生态的现实张力。其二最小参考实现是协议扩散的加速器。Buzz 自己实现了 ACP 客户端buzz-acp和 ACP 服务器buzz-agent两端等于给生态提供了一个可审计的对照物buzz-agent全篇手写协议处理、拒绝引入框架抽象的设计哲学VISION_AGENT.mdIf you can delete it, delete it让照着实现一个 ACP agent的成本降到个人开发者一个下午能读完的程度。协议竞争里参考实现的体积往往决定采纳速度。其三把身份、会话、工具三层拆开的项目未来最不容易被单一协议绑架。如果 ACP 没跑赢Buzz 可以继续用 Nostr 身份层 MCP 工具层服务生态如果 MCP 的某个变体如 HTTP 传输成为主流buzz-agent的工具抽象无需大改。这种协议插槽化的架构比押注单一标准的平台有更长的生存窗口。Buzz 给出的答案本质上是ACP 与 MCP 不是对手是不同深度的插槽。MCP 今天更接近工具层的未来而 ACP 正在争夺接入层的未来——当 Agent 从命令行工具演变为常驻的团队协作者决定体验上限的将不再只是它能调用多少工具而是它以什么身份、被谁、以何种方式唤醒和编排。Buzz 的价值在于用一套可运行的完整实现把两套标准各司其职从口号变成了能入群上班的工程现实。【免费下载链接】buzzA hive mind communication platform项目地址: https://gitcode.com/GitHub_Trending/buzz14/buzz创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考