跨国深谈← 返回←AI 的通用遥控器：为什么智能体行业还需要一个 ACP 协议

AI 的通用遥控器：为什么智能体行业还需要一个 ACP 协议

关联

人物 Alex Hancock

公司 Block · Goose · Zed · JetBrains

概念 ACP（智能体客户端协议） · MCP · harness · 智能体

这一集是一个短演讲，主角是 Alex Hancock——Block(旗下有 Cash App、Square 和 Tidal)的软件工程师，他维护开源智能体项目 Goose(最初是 Block 内部项目，后开源并捐赠给 Linux 基金会)，同时也是 MCP(模型上下文协议，即智能体调用工具的开放标准)的 Rust SDK 维护者 。他开场还开了个玩笑：上一位演讲者说 MCP 客户端维护者还没实现对「任务」的支持是因为聪明，而他本人就是维护者，「我可以告诉你们，其实只是因为我(懒)」。

问题：智能体被「专用遥控器」锁死

市面上有很多优秀的 harness(来自各大实验室、不同公司，也有很多基于开放标准的)，但它们的接口往往是自定义或专用的。最糟的情况是：某个 harness 只有一个客户端应用能控制它 。他用 web 打比方：这就好比你每连一个网站都得换一个特定浏览器或协议——那样根本不会有开放 web 。

而标准的意义在于创造生态和市场。在智能体领域，智能体「走出去干活」这一环已经有好标准了——MCP,全球有成千上万个 server,所有智能体都能连上去操作别的系统。

但 MCP 最强大的地方不在协议本身的任何特性，而在于所有人都在用它 。缺的是另一环：客户端软件如何给智能体分配任务、告诉它做什么、并拿到进展更新——这块还没有标准 。

方案：ACP

ACP(Agent Client Protocol,智能体客户端协议)由编辑器公司发起——Zed 和 JetBrains 组队提出，让客户端能控制 harness。他们的动机很直接：在编辑器里只写一个高质量客户端实现，就能控制任何 harness、发送任务、拿结果、看文件改动 。Goose 团队发现它相对中立、没有太多编辑器特有的功能，所以用途远不止编辑器，可以推广到更广的客户端软件 。

它的设计要点：

• 连接带能力协商：客户端和 harness 建立连接(带一组能力声明)，然后创建会话；会话里可以发送用户消息，智能体回以文本、图片、音频或进展更新 。
• 透明与授权：工具被调用时会推送通知(说明调了什么工具、元数据是什么)；还能发权限请求，让客户端向用户展示「这个工具调用要不要执行」。
• 简单且可扩展：用 JSON RPC 消息，不局限于原生协议，可以加自定义方法(惯例是加下划线前缀)。他特别看重这一点：如果 Codex、Goose 等各家团队都加自定义方法，大家就能看到生态里涌现出什么，哪些值得走上标准化轨道纳入协议本身——让协议由使用方式和社区来塑造 。

现场演示

他打开 Zed 编辑器，对一个单 HTML 文件项目问「介绍一下这个项目」，底层智能体是 Goose,走 Goose 的 ACP 接口，能看到它流式返回文本和工具调用信息 。然后用同一个智能体、换一个基于终端的第三方客户端(来自 Poolside AI),得到完全相同的体验——harness 侧只需一个实现，任何客户端都能用 。

他还展示了本地之外的远程能力。他们接手时 ACP 还没有远程支持，于是补上了 HTTP 传输(含 WebSocket 升级)，消息和协议语义不变 。他昨晚用 vibe coding(用自然语言让 AI 生成程序)随手写了个客户端，连到同一进程发指令——代码可以跑在容器里或云端，消息和库完全一样，本地远程轻松切换 。

四层技术栈全部可远程化

Goose 团队把智能体技术栈拆成四个组件：客户端(用户用的应用或无头应用)、harness(工具调用循环)、工具(通常就是 MCP)、模型 。现在 MCP 有远程传输，模型的 API 本来就是远程端点，再补上 ACP 的远程传输——四个组件都可以随意挪位置：可以全在一台机器上，harness 和客户端分开，模型或工具单独远程 。在标准上对齐并做好传输方案，正是能自由移动这套技术栈的关键 。

意义：客户端生态与市场

现有生态已经有编辑器、桌面应用、移动应用、终端工具等各类客户端在接 ACP 。他设想的前景：人们可以做个人客户端，按自己喜欢的方式编排智能体；可以为特定业务领域或某家公司定制客户端；也可以做白标客户端对接所有 harness 。更重要的是，一旦开辟出这个新类别、有了市场和多种选择，用户就能用脚投票，开发者会在用户体验质量上竞争，整体推高使用 AI 的体验 。

本集带走

• 行业的缺口在「遥控」这一环：MCP 解决了智能体出去调工具的标准，但客户端怎么给智能体派任务、收更新，此前各家都是自定义接口，最糟时一个 harness 只配一个客户端。
• ACP 是 Zed 和 JetBrains 发起的开放标准：设计极简(JSON RPC)、带能力协商、支持工具调用通知和权限请求，还允许加下划线前缀的自定义方法——协议进化靠社区实际用法推动。
• 补上 HTTP 远程传输后，四层技术栈(客户端/harness/工具/模型)每一层都可以独立远程部署，本地和远程用同一套消息和库，切换零成本。
• 一次 harness 实现，处处可接入：Goose 在 Zed 和终端客户端上给出完全相同的体验；想接入可以自己做客户端或给 harness 加支持，ACP 官网有入门指引。

MCP 最强大的地方不在于 MCP 本身的任何特性，而在于所有人都在使用 MCP。
And the most powerful thing about MCP is not anything about MCP itself, but it’s that everyone uses MCP.
—— Alex Hancock · [02:45]

比如 Codex 团队有自定义方法，Goose 团队有自定义方法，Klein 团队也有，无论谁，我们都能看到生态里涌现出什么，哪些值得走上标准化轨道纳入协议本身——让这个东西由使用方式塑造、由社区塑造。
Like if the Codex team has some custom methods, the Goose team has some custom methods, the Klein team has some custom methods, whoever, we can see what emerges in the ecosystem and what makes sense to get on a standards track and bring into the protocol itself so that this is sort of shaped by usage and shaped by the community.
—— Alex Hancock · [05:47]