三家公司一周内出手，编码 Agent 进入团队基础设施时代

本文最初发布于博客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这样的受控后端。它们之间是层级关系，而非相互替代的关系，大多数团队最终都会同时采用多种方案。 记忆的成本 团队记忆既是一项生产力功能，同时也构成安全与治理的潜在风险面。 一旦代理能够在不同会话间携