本文最初发布于博客 TheNewStack。
在 6 月的第一周，有三家供应商将编码代理推向了单开发者循环之外。
Cognition 在 6 月 2 日发布了Devin Desktop。
同一天，微软在 Build 2026 大会上介绍了Rayfin。
Augment Code 在 6 月 3 日宣布所有团队套餐支持Cosmos。
这三次发布位于同一新兴技术栈的不同层次上：
Devin Desktop 为团队提供了一个单一的控制台来管理它们。
Rayfin 管理哪些代理构建的应用程序可以部署到企业中。
Cosmos 协调一系列代理。
总体而言，这三点标志着一种转变：编码工具正逐渐从个人工具转变为团队基础设施。对于任何见证过版本控制系统发展历程的人来说，这种趋势并不陌生。
版本控制最初是在一台工作站上为个人提供便利，然后 Git 和持续集成将其转变为共享基础设施，提供分支、审查和整个团队必须遵守的策略。编码代理今天正在走同样的路。这篇文章提及的参考点是每个工程团队都已经知道的：拉取请求、CI 管道、访问策略和将它们联系在一起的控制平面。
从面向开发者的代理框架到面向团队的代理框架
几周前，我争论说代理编码工具已经趋于同质化，竞争已经从模型转移到了代理框架上，即围绕智能代理的工作流程和审批层。在SWE-bench Verified等公共编码基准测试中，顶级系统相互之间现在已经非常接近，产品差异化越来越多地来自治理框架、计划步骤、工具使用、评审环节和投入生产的路径。
那个论点假设一名开发者使用一个治理框架。六月的发布打破了这一假设，将治理框架交给了整个团队。团队治理框架必须完成个人治理框架不需要做的事情。它必须记住不同人员和不同会话中的决策，以免每周一都要重新讨论相同的命名规范。它必须协调多个并行工作的代理，确保它们不会互相干扰。而且，当需要做出判断时，它必须为人类提供一个立足点，这与审阅者在拉取请求中扮演的角色相同。
想象一下，一个开发者在笔记本电脑上运行脚本，一个团队通过具有缓存状态和审计日志的共享 CI 系统运行相同的作业，即使工作看起来相同，但责任归属却截然不同。
Augment Cosmos：面向整个生命周期的控制平面
Augment Code公司的 Cosmos 旨在在软件开发的整个生命周期中协调团队已经在运行的代理。Augment 描述的代理贯穿需求分类、需求规格说明、实现、评审、测试、部署和反馈等阶段，它们相互协调，并在需要人工判断时让人类参与进来。这些专用代理共享记忆，因此，一个代理所学到的知识不会在其会话结束时丢失。
最合适的类比是 CI/CD 控制平面。管道不会为你编写代码；它只是决定该运行什么，以什么顺序运行，以及在更改发布之前必须通过什么环节。Cosmos 就扮演了这一角色，为一组代理提供支持，保存共享的上下文以及代理运行的规则。
考虑一个在凌晨 2 点呼叫值班工程师的事件。在 Augment 自己的事件管理故事中，由于 Cosmos 代理在工程师加入之前接起了警报，收集了上下文，并开始调查，所以工程师接手时面对的不是一张白纸，而是已经有一些进展。这种做法带来的好处在于实现了信息共享与协调，使下一位代理能够接续上一位的工作继续推进。
所谓的冷启动问题（代理没有上下文可以使用）正是 Cosmos 试图解决的问题。代理在会话之间几乎是无状态的，这就是为什么一个工具在第一周编写出了合格的代码，在第十二周却重复出现了相同的错误。共享记忆层将这些分散的更正变成了整个团队可以重用的东西。
Cognition Devin Desktop：管理员控制台
Devin Desktop 同样源于开发者视角的转变。Cognition将其称为新一代 Windsurf。该平台将“代理控制中心”设为 IDE 的默认界面，使工程师能够在一个地方管理本地和云端代理、拉取请求以及上下文信息。名为“空间”（Spaces）的功能允许相关代理共享上下文并协作完成任务。
Cognition 称 Devin Desktop 为“代理中立”平台。它支持代理互操作性开放标准——代理客户端协议（ACP），任何兼容 ACP 的代理都能在 Devin Desktop 中与 Devin 并行运行。因此原则上，团队可以在同一控制面板上，针对不同任务分别运行 Codex CLI 和基于 Claude 的代理。这种中立性是通过 ACP 适配器实现的，而非直接集成到每个商业化的 Codex 或 Claude 接口中。这很重要，因为大多数团队已经在组合使用多种工具，而且没有人希望使用只能管理单一供应商代理的控制台。
试想一下：一位技术负责人在周五将待办事项拆分成八个工单，分别交给不同的代理，然后在周一花时间审查这八个拉取请求，而不是亲手编写代码。Devin Desktop 正是为这样的工作日而打造的，它保留了完整的编辑器，以便人类进行最后的编辑。与倾向于提供固定方案的 Cosmos 不同，Devin Desktop 更像是一个控制面板，它尊重你已经选定的代理。
微软 Rayfin：治理代理交付的内容
Rayfin 的运作逻辑截然不同。它并非用于管理代理，而是聚焦代理产出最多的产物——应用程序后端，为其提供标准化的受控部署路径。Rayfin 于 Build 2026 大会上发布，这是一个开源的 SDK 和 CLI，允许开发人员和编码代理通过代码定义完整的应用程序后端（包括数据模型、业务逻辑、身份验证和访问策略），然后将其部署到 Microsoft Fabric 上。
一旦应用进入 Fabric，它就继承了组织已经在运行的安全、合规和治理机制，其数据存储在 OneLake 中，而不是一个新的数据孤岛上。Replit 是首发合作伙伴。因此，Replit 中的代理可以定义后端并将其发送到一个受管控的租户。微软指出的这个问题确实存在。代理式编程工具部署应用程序的速度远超任何治理机制的跟进能力，而每个不受管控的应用程序，都意味着在评审人员的关注范围之外又多了一座数据孤岛。
这就好比平台工程中所说的“铺好的道路”，这条受支持的路径让合规之路变得轻松便捷。Rayfin 致力于成为代理构建后端过程中“铺好的道路”，让应用程序在投入生产时便已融入数据资产体系，而非在安全审查后才被生硬地附加上去。这是组织层面的输出控制，而不是工作的协调。因此，它拓展了应用场景，而非简单地重复既有的模式。Rayfin 目前处于预览阶段，与 Replit 集成是首个合作项目而非全面整合，随着预览的进行，治理深度将逐渐明朗。
每个平台的适用场景
这三次发布回答了不同的问题，选用哪个工具取决于工程组织对哪个问题的感受最强烈。
一个被代理生成的拉取请求所淹没的团队会面临协调问题。一个运行五种不同代理的团队会面临管理问题。一个代理不断部署不受控应用的团队会面临控制问题。下面的表格将每个需求映射到为其构建的平台，并列出了相关的权衡。
实际上，这些类别之间的界限开始变得模糊。一家大型工程组织既可以使用 Cosmos 进行协调，也可以通过 Devin Desktop 管理一些第三方代理，还可以将代理构建的应用程序路由到 Rayfin 这样的受控后端。它们之间是层级关系，而非相互替代的关系，大多数团队最终都会同时采用多种方案。
记忆的成本
团队记忆既是一项生产力功能，同时也构成安全与治理的潜在风险面。
一旦代理能够在不同会话间携带约定、事件历史、客户背景、凭证、架构决策以及评审反馈，买家就不得不思考：这些记忆存储在哪里？谁可以查看它们？如何消除它们？以及当合同结束时，这些信息是否会随团队一同离开。正是那个让代理在整个组织中发挥作用的层级，也是锁定效应加剧的层级，因为企业积累的背景信息远比读取它的代理更难迁移。
未来展望
对于工程团队而言，这些参考点依然还是比较熟悉。Cosmos 是代理持续集成（CI）的控制平面，Devin Desktop 是集群的操作控制台，而 Rayfin 则如同铺好的道路，确保输出始终在安全边界内。这三者背后的逻辑转变在于：代理不再仅仅是个人生产力工具，而是变成了组织制定策略的对象——就像组织在源代码控制和部署方面所做的那样。
对于买家而言，决定性因素在于哪个平台托管了团队的代理、它们共享的记忆以及记录的审批。如果像 Agent Client Protocol 这样的标准能保持这一管理层的可移植性，那么团队就能跨供应商组建自己的代理集群。如果做不到这一点，代理 SDLC 就会固化为相互竞争的控制平面，每个平面都有自己的记忆、权限和生产部署路径。GitHub 和 Cursor 已经在构思各自的解决方案，而接下来的关键问题在于：这一个团队层是否会像单人开发工具那样趋于统一，还是会四分五裂。
声明：本文为 InfoQ 翻译，未经许可禁止转载。
原文链接：https://thenewstack.io/coding-agents-team-infrastructure/
