AWS Kiro尝试让编码Agent脱离编辑器

我们很高兴你来到这里。每周一至周五，我们都会为你送上 TNS 的优质内容，帮助你及时掌握新闻动态，始终保持最佳状态。

请查看收件箱中的确认邮件，你可以在邮件中调整偏好设置，甚至加入更多群组。

在你喜爱的社交媒体平台上关注 TNS。

在 LinkedIn 上关注 TNS。

等待第一期 TNS 新闻简报期间，不妨先看看最新的精选与热门文章。

选择一个 coding agent，可能很快就不再意味着还得换用新的编辑器或终端。本周，这一设想距离现实又近了一步：AWS 介绍了 Kiro 如何用一套基于 Agent Client Protocol 的统一架构，取代原有的三套独立 agent harness。这项改造让 Kiro 的客户端能够通过共享协议与其 Agent 通信。最终，开发者或许可以分别独立选择 coding 工具与 AI Agent。

此前，IDE 依赖 TypeScript harness，CLI 使用 Rust，而 Web 端体验则依赖 Python。如今，这三者已经整合为一个独立的统一 agent harness，以单独进程的形式运行在 workspace 旁边。

工程上的简化固然值得关注，但影响更深远的是它背后的架构决策：AWS 选择 Agent Client Protocol（ACP）作为 Kiro 客户端与 Kiro 自有 Agent 之间的接口。ACP 最初诞生于 Zed，目前由 Zed 与 JetBrains 共同开发。即使面对自家组件，AWS 仍然选择采用生态协议，这意味着它将客户端与 Agent 之间的边界视为标准化接口，而不是专有实现中的内部细节。

协议成为架构边界

Kiro 工程师所描述的演进过程，对于任何构建过可扩展软件的人来说都不会陌生。早期采用共享库的尝试未能维持清晰的职责分离。客户端应用通过直接调用内部 API，逐渐积累了越来越多与特定 Agent 相关的逻辑，导致双方边界变得愈发模糊。

将 Agent 移入独立进程解决了这个问题。现在，客户端只通过 ACP 与 Agent 通信，而执行环境则成为实现细节。无论 Agent 运行在开发者本地工作站上，还是运行在云端 sandbox 中，客户端交互所使用的都是同一套协议。

协议保持标准化，差异化则通过扩展实现。

AWS 特意选择扩展 ACP，而不是创建专有变体。团队引入了 20 多个可由 Agent 调用的方法、15 个可由客户端调用的方法，以及 20 种通知类型，全部归入 _kiro/ namespace。AWS 还为 Web 和 iOS 客户端实现了 WebSocket transport，同时在本地执行场景中继续使用 ACP 标准的 stdio transport。custom agents、lifecycle hooks 等扩展，如今在 Kiro 的所有使用入口中共享同一套配置模型；与此同时，每个客户端仍然可以自由提供原生用户体验和平台专属工具。

协议保持标准化，差异化则通过扩展实现。

AWS 并不是唯一得出这一结论的厂商。

多家厂商正不约而同地采用同一理念

今年 6 月，Microsoft 在 Build 大会上推出了实验性的 ACP 客户端 Intelligent Terminal 0.1，它能够发现本地安装的 Agent CLI。GitHub Copilot CLI 是默认 Agent，但这套架构从设计之初就有意支持多种实现。

随后在 7 月，JetBrains 通过 ACP 将 Junie 引入 ReSharper 2026.2。该公司将这次集成描述为迈向更广泛协议支持的早期一步，而不是已经完成的最终实现。

尽管这些产品发布在成熟度上存在显著差异，但它们都汇聚到了同一项架构原则上。Microsoft 使用 ACP 将终端与 Agent 实现解耦；JetBrains 正在把该协议引入自己的 IDE 技术栈；AWS 则已经在自家产品内部对这条边界进行了标准化。

这种模式与 Language Server Protocol（LSP）为编程语言工具带来的变化非常相似。LSP 将编辑器与语言智能能力分离，而 ACP 正在开始将开发者体验与 Agent 实现分离。这样一来，不再需要每个编辑器都为每一种 Agent 构建专用集成；双方都可以面向一套通用协议进行开发，将集成复杂度从 N × M 的关系逐步降低到 N + M。

协议实现了互操作性，但并未抹平产品差异。

厂商特有的能力不可避免地会重新引入一定程度的专用化。Kiro 使用 namespace 扩展的方式，正体现了这种权衡。第三方 ACP 客户端可以获得标准化体验，而 Kiro 自有客户端则能享受更丰富的能力，包括实时 steering、specifications，以及高级权限管理。

协议实现了互操作性，但并未抹平产品差异。

治理成为新的竞争层

通信方式标准化之后，创新的重心便转移到了其他地方。

与 transport 相比，Kiro 最重要的差异化能力体现在策略管理上。该平台使用统一的 capability model，取代了两套互不兼容的权限系统。这个模型以 Cedar 为基础；Cedar 是 AWS 的授权语言，在设计中采用了形式化验证技术。

此前，CLI 依赖基于正则表达式的 allow list 和 deny list，而 IDE 实现的则是基于前缀的匹配。新的 capability model 围绕功能意图对权限进行抽象。fs_read、fs_write、shell、web_fetch、mcp 和 subagent 等 capability，代表的是不同类别的操作，而不是某个具体工具。例如，拒绝 fs_read 将阻止所有文件读取操作，无论这些操作由哪个工具执行。

策略会在多个 scope 中进行评估，包括 MDM、user、workspace、agent profile 和 session，其中明确的 deny 规则拥有更高优先级。

ACP 本身仅提供基础的工具审批语义。AWS 则在这一基础之上构建了一套丰富得多的治理模型。随着企业采用速度加快，这一层很可能成为产品差异化的主要阵地。身份集成、审计、授权、策略继承和 sandboxing，至少会与协议兼容性同等重要。

同样需要明确区分 ACP 与 MCP。MCP 标准化的是 Agent 与外部工具及服务之间的通信方式，而 ACP 标准化的是客户端与 Agent 之间的通信方式。二者解决的是技术栈中彼此互补的层次，并不是相互竞争的协议。

一个尚未获得默认分发优势的生态标准

ACP 的采用情况中，有一点尤其值得注意：它出现在哪里，以及尚未出现在哪里。

截至 2026 年 8 月，Visual Studio Code 尚未采用 ACP 作为编辑器与 Agent 架构之间的原生边界。Microsoft 当前对 ACP 的实现出现在 Intelligent Terminal 中，而不是编辑器本身。

一旦客户端与 Agent 之间的边界实现标准化，Agent 就会成为可替换组件，而不再是深度耦合、嵌入特定开发工具中的功能。

尽管尚未得到行业最大编辑器平台的采用，ACP 仍在多个独立实现中持续积累势能。这说明，该协议的成功依靠的是自身的架构价值，而不只是分发优势。

对开发者来说，这预示着一次根本性的转变：他们使用的编辑器或终端，将不必再决定他们能运行哪一种 coding agent。这些选择正逐渐彼此独立。一旦客户端与 Agent 之间的边界实现标准化，Agent 就会成为可替换组件，而不再是深度耦合、嵌入特定开发工具中的功能。