Devin后台代理架构深度解析：80%代码由AI提交的背后

当Devin仓库中80%的代码提交都来自AI，而工程团队人数仅增长10%时，我们正在见证软件工程的一个转折点。Latent Space播客最近邀请了Cognition联合创始人兼CPO Walden Yan（沃尔登·严）和OpenInspect创建者Cole Murray（科尔·默里），深入探讨了后台代理（Background Agent）的架构设计、实际落地挑战以及这一领域的未来走向。

从手持编程到后台自治：AI编程代理的能力跃迁

沃尔登回顾了关键转折点。大约在2024年12月前后，随着新一代模型的发布，AI编程代理从"需要手把手指导"跨越到了"基本可以自主驱动"的阶段。这意味着只要给出足够好的规格说明，代理就能从需求直接生成完整的Pull Request，几乎无需人工干预。

这种范式转变在Cognition内部体现得尤为明显：Devin合并的PR数量在两三个月内增长了7倍，而工程团队人数仅增长约10%。更惊人的是，Devin在自家仓库中的代码提交占比从1月的16%飙升至3月的80%。

沃尔登还提到了一个标志性事件——Sonnet 3.7发布时，团队在一个晚上就用它重写了Devin的大量代码，本质上是"剥离了因模型智能提升而不再需要的部分"。这种模型能力的指数级增长，让后台代理从概念验证变成了实际可用的生产力工具。

核心架构决策：大脑与沙箱的分离设计

后台代理系统面临的首要架构决策是：代理（Agent）应该运行在沙箱内部（in the box）还是外部（out of the box）？

沙箱内运行（In the Box） 的优势是简单——所有状态都在沙箱内，管理起来更容易。但缺点是安全风险：所有密钥都必须放入沙箱，而AI的不可预测性可能导致密钥泄露。

沙箱外运行（Out of the Box） 则将代理的"大脑"放在独立的控制平面上，沙箱仅作为"双手"执行操作。这种架构更复杂，但安全性更好，且能复用现有的开发环境基础设施。

Cognition从一开始就选择了"大脑与机器分离"的架构。沃尔登举了一个实际例子：当不同用户通过同一个GitHub App与代理交互时，如果大脑和机器没有分离，就很难实现权限隔离。分离架构下，机器上只放最小权限的密钥，大脑完全不可从机器端访问。

科尔也认同这是更优的长期架构，OpenInspect目前虽然采用沙箱内运行，但正在逐步向外部迁移。

环境配置：后台代理最被低估的难题

两位嘉宾不约而同地指出，仓库环境配置（Repo Setup）是后台代理最持久的难题。很多团队的开发环境配置流程是"去找Bob要密钥"——这对AI代理显然行不通。

沃尔登分享了一个有趣的基础设施故事：早期很多团队发现grep在代理的虚拟机上极其缓慢，于是试图构建自定义grep索引。但Cognition的基础设施团队发现，根本原因其实很简单——这些虚拟机底层使用的是网络文件系统，每次grep操作实际上都在发起网络调用。解决方案不是重建索引，而是更换文件系统。

这类细节还包括：Cognition自研了一种增量文件系统格式，使得VM的保存和恢复时间与文件系统的diff成正比，而非整个磁盘大小。这将Devin的启动时间从"冷启动10分钟"大幅缩短。

MCP集成的理想与现实

虽然MCP（Model Context Protocol）生态爆发式增长，但要真正做好集成远比"接一个MCP"复杂得多。沃尔登以Slack集成为例：简单的MCP只能让代理发消息，但Devin需要像同事一样在Slack中自然交互——支持webhook回调、控制消息频率、避免刷屏。

沃尔登表示，他更希望有一种比MCP更具表达力的双向协议，而不仅仅是一组工具调用。当MCP规范变得过于复杂时，它就失去了"简单一键连接"的初衷，最终还是回到了构建第一方集成的老路上。

科尔补充了一个实用原则：如果某个集成几乎每个会话都会用到，那就值得自己拥有它并做深度优化，而不是依赖通用的MCP。

记忆系统：AI代理尚未完全解决的难题

记忆（Memory）是两位嘉宾都承认"尚未完全解决"的问题。Devin的记忆系统经历了多次迭代：

• 自动生成优先：95%的记忆来自自动提取，而非用户主动编写。当用户纠正Devin时，系统会询问"要不要记住这个？"
• 生成质量控制：不能把一次性的偏好（如"这次用Draft PR"）泛化为永久规则
• 检索精度：数千条记忆中如何在正确时机检索正确内容，同时不让上下文爆炸
• 记忆编辑：支持更新和修正已有记忆

沃尔登透露了一个有趣的探索方向：既然现在的模型非常擅长使用文件系统，是否应该把记忆系统重建为类似文件系统的结构，让代理自己导航？

多代理协作：从炒作回归务实

沃尔登曾发表过著名的"不要构建多代理"的观点，但他承认这个立场可能需要修订。一年前多代理完全不可行，但现在模型已经展现出了真正的沟通成熟度——Devin有时会反驳用户的错误指令，这种"不再当应声虫"的能力让多代理协作成为可能。

不过，实践中最有效的模式仍然是管理者-子代理模式：一个主代理分配任务，子代理在各自隔离的环境中独立工作，尽量减少冲突。Cognition甚至给了Devin一个MCP来创建和管理其他Devin实例，但"群体智能"式的自由交互目前仍然会制造混乱。

一个有趣的实验是：团队尝试纯粹通过AI编码构建真实产品，完全不做代码审查。结果发现，大约两周后代码库就会退化到不可维护的程度——按钮在10个地方重复实现，颜色不一致，技术债务指数级增长。

AI编码的代码卫生问题与应对策略

两位嘉宾分享了多个AI编码的常见反模式：

• GPT模型倾向于不惜代价保持向后兼容，产生奇怪的import/export链
• Python代码中频繁出现hasattr和getattr，本质是模型的"奖励黑客"行为——避免代码报错
• 无类型元组泛滥，到处使用Dict[str, Any]
• 过度注释：某些模型会在每个函数上写段落级别的注释，虽然内容质量不错（包含决策推理和替代方案分析），但信息量过大

应对策略包括：将这些反模式加入lint规则（如禁止getattr）、使用Semgrep等工具自动检测、定期安排人工或AI进行代码清理。

沃尔登提出了一个重要的架构原则：严格控制模块间的边界。作为架构师，你的工作是定义模块之间的硬性契约，模块内部可以由AI自由发挥，但跨模块的变更必须经过人工审批。

落地场景：从SRE自动化到全员编程

科尔总结了客户最常见的三大使用场景：

1. SRE自动分诊：代理作为告警的第一响应者，自动收集上下文、分析日志、甚至直接生成修复PR
2. 非工程人员编程：PM不再创建Issue，而是直接在Slack中描述需求，代理自动生成PR
3. 客户支持增强：支持团队遇到问题时，代理自动分析代码库提供完整上下文，跳过"能否获取更多信息"的来回沟通

在成本方面，科尔透露目前常见的预算范围是每位工程师每月1000到5000美元，但随着更强大的前沿模型出现，这个数字可能会继续攀升。沃尔登则对"智能路由"（Smart Routing）——混合使用前沿模型和次前沿模型——表示了浓厚兴趣，认为这将是降本增效的关键方向。

结语

后台代理正在从早期采用者的玩具变成企业级基础设施。但正如这次对话所揭示的，真正的挑战不在于让AI写代码，而在于环境配置、安全隔离、记忆管理、集成深度、代码质量控制等一系列工程问题。对于想要构建或采用后台代理的团队来说，理解这些"冰山下的部分"可能比选择哪个模型更为重要。