本文来自微信公众号： 每日天使 ，作者：每日天使，原文标题：《Cognition 联合创始人：一个晚上用 Sonnet 3.7 重写了整个系统，每工程师每月 1000-5000 美元，未来可能高达 50000 美元》
编者按
2025年12月，当Opus 4.5和GPT 5.2达到某个临界点后，AI编码世界悄然发生了一场革命。Devin——这个曾经备受争议、被嘲笑为"史上最贵demo"的AI编码助手，在2025年1月到3月之间，其提交的代码占Cognition公司总代码提交的比例从16%飙升至80%。
这不是一场渐进式的改进，而是一次范式转移。当模型智能足以支撑"后台代理"自主运行时，我们不再需要手把手地引导AI写代码——它可以在云端自主完成从需求到PR的全过程。
本期Latent Space邀请到了Walden Yan（Cognition联合创始人、CPO，Devin的缔造者之一）和Cole Murray（开源项目Open Inspect的创建者），深度探讨了背景代理的架构设计、上下文工程的实践、记忆系统的难题，以及AI编码的未来图景。
导语
2025年，AI编码工具从"补全代码"进化到"自主完成PR"，背后是模型能力的飞跃。Devin作为这一波浪潮的先锋，正在重新定义"工程师"的工作方式。
Walden Yan，Cognition公司联合创始人兼CPO，是"上下文工程"（Context Engineering）一词的早期推动者。他带领团队打造了Devin——第一个真正能够自主完成软件工程任务的AI代理。
Cole Murray是开源背景代理系统Open Inspect的创建者。他选择开源而非商业化，让企业能够基于Open Inspect构建自己的背景代理系统。
本期节目中，两位嘉宾与主持人深入探讨了：
•背景代理的架构选择："盒子内"还是"盒子外"？
•记忆系统为何如此难做？
•多代理协作是未来还是噱头？
•AI编码的成本边界在哪里？
•当PM也能直接提交代码，工程组织的边界将如何重塑？
QA正文
一、背景代理的崛起
主持人：大家好，今天我们有两位特别的嘉宾。首先是Walden Yan，Cognition联合创始人、CPO。没错，CPO，这是个很酷的头衔。而且，你也是"上下文工程"这个词的共同创造者之一，对吗？
Walden Yan：是的。虽然我认为在此之前已经有很多人以各种方式使用过这个术语。但我的确发现，无论是内部还是外部的人，都很喜欢用这个词来替代"prompt工程"或者简单的"模型封装"，它代表了一种更系统化的agent构建思路。
主持人：没错。对于那些还没看过的人来说，我屏幕上显示的是那篇《别构建多代理系统》的帖子，你们应该去读一下，我们后面可能还会提到。另外一位嘉宾是Cole Murray，他创建了Open Inspect。
Cole Murray：很高兴来到这里。
主持人：好的，让我们开始吧。现在每个人都在构建自己的"Devin"。这到底是怎么回事？
Walden Yan：我觉得工程界正在觉醒，意识到"背景代理"或"云端代理"这个概念。我认为在2025年12月左右，模型能力出现了一个转折点——Opus 4.5和GPT 5.2达到了一个临界点，让我们能够从"手把手引导模型"转向"基本可以自主驱动模型"。
我的意思是，只要需求规格足够好，我们基本上可以从一个需求描述直接走到一个完整的Pull Request，摩擦非常小。这个范式本身就在改变我们与代理交互的方式，也开启了背景代理变得更加实用的世界。
主持人：我觉得不是所有人都在12月就体验到了这种感觉，但确实有一个渐入佳境的过程。我记得有一个时刻是Sonnet 3.7发布，你们好像用一个晚上重写了Devin？
Walden Yan：是的，没错。回想起来，我们总觉得能力在不断提升，但即使是最近这3-4个月，提升速度甚至更快了。所以从某种角度来说，现在谈论Sonnet 3.7是一个多大的飞跃，甚至有点好笑了。
老实说，其中很大一部分工作是删减那些随着模型智能跃升而不再需要的Devin组件。但我也认为，最近的一些飞跃——尤其是像Opus和最新的GPT模型——它们正在达到一种自主性的水平，让人们真正感受到他们实际上可以"放手"，不再需要时刻盯着模型。
曾经有人争论说"我需要在IDE里深度参与我的模型吗？"现在这些人开始问："我能不能直接把它完全移到云端？"这是一个更严肃的对话，我们在所有的增长图表中都看到了这一点。
有一个很有趣的图表：我们的PR数量，或者说我们合并的PR数量，从1月到3月增长了7倍。
主持人：我想Dave可能在推特上发过这个。是的。
Walden Yan：我们在1月的Devin提交百分比是16%，而现在3月是80%。
主持人：哇，这是一次巨大的转变。所以现在很多人不仅在考虑购买Devin，也在考虑构建自己的背景代理系统。
二、Open Inspect的诞生
主持人：Cole，我想问问你，最初是什么启发你去构建Open Inspect的？
Cole Murray：Open Inspect的诞生，主要是我观察到我的客户如何使用诸如Cloud Web、OpenAI的Codex之类的工具，以及他们在使用中遇到的一些摩擦。
一个主要问题是，Cloud Web是通过Slack使用的，他们遇到的一个大问题是：启动的会话是与调用它的人绑定的。如果一个PM调用了会话，然后想把它交给工程团队，工程团队是看不到这个会话的。这本身就是一个阻碍，因为PM会说"嘿工程团队，你能接手一下吗？"但如果他们看不到任何会话内容，就只能复制粘贴输出结果。
看到这些问题后，我内部构建了一个类似的架构来做实验，试试不同的想法。随着"从localhost迁移到云端"这个趋势开始兴起，以及RAMP发布了他们的博客文章，我发现我已经有很多现成的组件了。
我觉得把这个过程记录下来会很有趣，看看Claude仅从博客文章中能做出什么。在我的推特账号上，实际上有一个线程记录了我整个过程。
主持人：哇。你是说在RAMP的博客文章发布后，你直接让Claude根据那篇文章来构建系统？
Cole Murray：对，就在文章发布后。我觉得RAMP做得很好的一点是，他们不仅说了"我们构建了一个很棒的系统"，还详细说明了"这是你如何构建它的方法"。这引起了我很大的共鸣，因为我已经看到了这些问题。而且我环顾四周，发现开源社区中并没有真正符合这种系统的项目。
有很多项目是在localhost运行的，比如Superset、Conductor等等，但没有真正在云端运行的。所以我构建了它，并且觉得把它开源出来，让任何人都能在这个基础上进行定制，是一件很有趣的事情。
主持人：所以Open Inspect本质上是一个开源的背景代理系统，任何人都可以基于它构建自己的Devin？
Cole Murray：没错。而且我没有试图把它变成一种需要monetize的产品。很多人问我："你不想融资吗？你不想把它变成一种服务吗？"但我的答案是：不想。
原因有几个。第一，我不想到处竞争"每座位20美元"这个市场。我认为这是一个非常困难的业务。第二，系统的核心部分其实很容易被复制。我的意思是，我构建这个系统也相对较快。而且因为你并不拥有整个技术栈，所以很难monetize。
钱是在沙箱层赚的——Daytona、E2B、还有很多其他玩家。钱是在模型层赚的。而你坐在中间的这个奇怪的灰色地带——你到底在卖什么？你在卖基础设施？你在卖集成？这都很模糊。
三、架构设计：盒子内vs盒子外
主持人：让我们聊聊架构方面的东西。我认为这是你们两位都会感兴趣的话题。这个"背景代理系统"的心智模型是什么？
Cole Murray：我觉得也许我们可以从"背景代理系统的组成部分"开始，然后再深入到一些微调决策。但我想Walden刚才提到的"代理是放在这个开放代码盒子里"的说法……
Walden Yan：对，这涉及到"盒子内"（in the box）和"盒子外"（out of the box）的问题。在背景代理系统中，你需要做一个决策：代理到底运行在哪里？这通常被描述为"harness是在盒子内还是盒子外"。
Cole Murray：对。如果选择"盒子内"运行代理，你会有一些权衡。负面的权衡主要是安全性问题，因为代理运行在那个盒子里。除非你另外做设计，否则所有的密钥（secrets）都需要放进那个盒子。考虑到AI的本质，它可能是不可预测的，你很容易意外地泄露密钥，或者出现其他非预期的行为。
"盒子外"的想法是：我们让代理本身不直接运行在沙箱里，而是将代理的"大脑"运行在某种worker控制平面上。沙箱然后充当"手"的角色，大脑基本上通过工具调用操作沙箱、操纵环境。
我认为这两种系统之间的另一个权衡是："盒子外"的方案在复杂性上要高得多，因为你有需要管理的状态。而如果"盒子内"运行，代理的所有状态实际上都在盒子里。是的，你可以把它持久化到其他地方，但基本上都是本地化的，你需要担心的事情更少。
Walden Yan：我认为你提到的很多点，正是我们从一开始构建Devin时就选择"将大脑与机器分离"的原因。
这种方法还允许你重用所有现有的开发环境基础设施。你不需要担心构建一种新型开发盒子，让它拥有大脑所需的所有依赖项和密钥。
我们在客户身上看到的一个问题是：如果你有一个GitHub App，你想让Devin（或者任何代理）通过那个应用与GitHub交互，但然后你有不同权限的不同用户。如果他们都通过同一个GitHub App交互，而没有实际的分离机制……那就存在一个问题。
但在Devin的实践中，这要容易得多，因为我们只要说："你在机器上放置的任何东西，基本上就是用户可以自由操作的范围。"所以只把最scoped的密钥放在这个机器上，然后大脑是完全无法从机器访问的。
所以你不需要担心：如果用户可以在机器上做任何他们想做的事情，他们会弄乱大脑中最安全的部件。
四、测试vs计算机使用
主持人：我想找一个关于测试功能的参考视频，但我找不到。不过，我想问问你们：为什么你们称之为"测试"而不是"计算机使用"？这是什么类别的问题？
Walden Yan：我认为当人们想到AI运行你的应用并测试它时，他们实际上过度关注了"计算机使用"（computer use）这部分。因为在我心中，"计算机使用"是字面意义上的："好的，你想点击一个按钮，你能发出正确的坐标来点击那个按钮吗？"
我认为"测试"实际上是一个非常有趣的问题，对这些AI来说是一个挑战。因为如果你想做任意的测试——想象一下你做了一个横跨前端和后端的改动，也许还涉及一些更深层的服务——要真正测试那个改动，我们需要推理："如何让这些应用运行起来、相互编排、使用正确版本的代码？"然后，"好的，我如何触发那个功能？或者我如何让那个事情真正发生？"
这可能变得任意复杂。也许你需要是管理员，也许某个功能必须有feature flag开启，也许你需要运行两个会话，然后向其中一个发送一个非常特定的词来触发特定行为。
弄清楚如何做到这一点，需要大量的代码库上下文，需要大量的编排工作——我们在Devin中专门做了这些工作。在某些情况下，我们发现实际上没有任何一个前沿模型能够端到端地完成这个完整任务。我们甚至看到过这样的情况：我们需要编排不同的前沿模型一起来解决这个问题。
主持人：这就是我们谈论测试问题时花费大部分时间的地方。不是计算机使用那部分。不过公平地说，随着最近的模型发布，计算机使用已经变得好多了，这部分工作肯定变得更容易了。
Walden Yan：尤其是视觉部分。昨天刚发布的Sonnet 4.7，显然在视觉方面要好得多，这将涵盖计算机使用场景。
但我认为更大的问题是：你如何管理盒子上的实际内容？这可能非常复杂。比如，假设你有一个正在变化和更新的大型代码库，依赖项也在变化。你如何确保代理的工作环境保持最新、拥有运行应用和测试它所需的所有凭证？
Cole Murray：对，这非常重要。在Cognition内部，我们称之为"repo setup"（代码库设置）。从公司成立之初起，这就是一个长期存在的问题：我们如何帮助用户完成设置？因为不是每个人都能开箱即用地使用云端工作环境。
我在客户身上看到的一个非常常见的问题是：很多团队并没有真正好的开发环境设置流程。很多时候是"去找Bob拿密钥"，这显然在代理需要实际设置这些东西时是行不通的。
五、记忆系统：未解决的难题
主持人：有一个问题非常频繁地出现，那就是"记忆"或"知识库"的问题。哦天哪。你们如何解决这个问题？
Walden Yan：呃，简短的答案是：还没有解决。这是一个开放的问题。有人对此提了issue。
Cole Murray：对，我在客户身上看到的是，他们主要通过"技能"（skills）来填补这个空白。我发现技能可以是一个很好的桥梁，或者更新CLAUDE.md文件。
Walden Yan：但我认为记忆作为一个整体是一个非常未解决的问题。这也是为什么我一直有点犹豫是否要添加它。我认为记忆的某些部分可以被解决，但作为一个整体，这是一个非常困难的检索问题。
记忆可能非常棘手，因为不仅是检索，还有记忆的生成——你不想让它变得太具体，但也不想让它太泛化。
主持人：带我们走过Devin的记忆之旅吧，因为我知道这是一段旅程。
Walden Yan：早期版本的记忆系统——我们称之为"知识"（Knowledge）功能——背后的想法是：我们希望它能够随着时间的推移自动拾取东西，而不需要用户主动去教Devin。
所以，每当你纠正Devin说："不，那不是你应该使用GET的方式。"我们希望Devin能够说："嘿，你想让我记住这个以备将来吗？"然后你只需要快速批准或拒绝，它就会随着时间的推移建立起来。
我发现大约95%的记忆——通过这种自动生成的方式产生的记忆——都是疯狂的东西。很少有人真的愿意坐下来写一大堆文档说："好的，这是你应该如何与这项技术工作的。"
但生成和检索一直是我们多年来一直在调整的事情。生成方面，你不想让它记住一些一次性的东西。比如，如果你有一次要求"哦，请作为草稿PR打开"，你不想让它变成"哦，从此以后每个人都应该把他们的PR作为草稿打开。"
但你确实想要某种"通用偏好"。也许你想说："哦，Cole通常喜欢把所有东西都创建为草稿PR。"检索也是一样。如果你有成千上万的记忆，你如何确保它们在正确的时间被检索到？
这需要一个令人惊讶的大量eval工作，以确保记忆系统在新模型来来去去时仍然是一个可靠的系统。
Cole Murray：对，我也在思考记忆修剪（memory pruning）和记忆的时间方面。如果记忆曾经说"哦，Cole喜欢把所有东西都作为草稿PR打开"，然后你说"不，不要这样做。"那么它应该说："哦，你想让我更新记忆，让Cole现在想要所有东西都作为普通PR打开吗？"
我认为同时，我们不知道这会不会是这个系统的最终版本。我们在这里拥有的任何东西，可能都会转化到我们将要提出的新系统中。
但我认为两年前和今天的一个很大区别是：这些代理真的很擅长使用任何类似于原生文件系统的东西。所以我们的一部分想法是："我们应该重建记忆，让它更像一个文件系统，让代理自己导航？"这是一个有趣的探索方向。
六、多代理系统的未来
主持人：让我抛出一些东西。我对今年非常看好的一件事是：代理调用其他代理，或者生成子代理，或者无论你想叫它什么。
Walden Yan：这会让事情变得更容易还是更难？我说不准。因为如果harness在盒子内，你可以启动更多的盒子。如果harness在盒子外，就没那么容易了，因为你有一个……嗯，某种unicorn进程的harness生活在盒子外。
Cole Murray：理论上应该是一样的，无论一个代理启动了许多子会话。Open Inspect例如可以启动子会话，实际上创建其他环境并在它们运行时监控它们。在"盒子外"的情况下，那基本上只是一个额外的会话，那个会话也在运行。所以那个会话也在你的worker平面上运行，无论你在哪里运行这个系统。
Walden Yan：我确实认为如果做得好，这可能很强大。但我看到的大多数实际日常使用场景，仍然是一个单一的工程师[代理]在相对隔离的意义下工作——每个都有自己的盒子，不共享机器。所以冲突的空间非常小。
主持人：我要提一下Cursor的实验。这是Wilson Wu从单代理到多代理的工作，你们显然在那个"别构建多代理系统"的帖子上站在某一侧。他们经历了整个过程，最终到达了……嗯，这正是Devin拥有的。
Walden Yan：我认为将来会有那个帖子的修订版。我觉得一年前，多代理是根本不可能的。你今天看到更多的多代理实验，但你可以争论它们是否是真正的多代理，或者它们只是某种工具调用。
有一些人会创建子代理去查找XYZ文件、XYZ实现，这真的有很好的上下文管理好处，因为所有的工具调用和token消耗然后会被折叠回主代理的答案。
我们基本上让Devin用Deep Wiki做这件事：发出调用给Deep Wiki，然后把结果返回给你。但这感觉像是一个工具调用。你知道，这不是像两个协作者来回交谈。
主持人：但让我最看好"多代理可能真的可行"的一件事，是我之前说的：Devin有时候会告诉我"你错了"，并推回我的要求。我认为这展示了一种成熟度和沟通能力，使得多代理世界成为可能。
当两个看到了不同信息的代理来回交流，并真正弄清楚谁是对的、什么是正确的实现——它们不只是"是的，你是对的"那种yes-man。我觉得这很令人兴奋。
七、成本与未来
主持人：如果你要为使用背景代理系统的客户提供一个经验法则，每工程师每月的成本大概是多少？
Cole Murray：这取决于很多因素，但我听到的常见数字是每工程师1000美元到5000美元。我没有听到任何人在每工程师50000美元这个范畴，但那是参考框架。
Walden Yan：我们会到达那里的。（笑）
主持人：我觉得这也会是今年的一大主题：我们将看到非常昂贵、非常智能的前沿模型，但我们也会看到有人说："你知道吗？我不需要前沿模型来做我做的很多工作。"因为一些"次前沿"（sub-frontier）系统对于很多工作来说已经足够好了。
非常令人兴奋的是混合前沿和次前沿系统的世界：你用次前沿部分来做快速、高效的事情，然后调用前沿部分来获得最高性能。
主持人：在结束之前，你们认为客户今天用云端代理试图做的最大事情是什么？
Cole Murray：我认为我看到的最简单和最常见的用例是SRE（站点可靠性工程）用例。无论是我们的警报在Slack里，还是在DataDog里，无论它们在哪里，我们都希望代理能够成为第一响应者。
这不一定意味着代理实际上在解决问题，但仅仅能够在事先收集上下文就是巨大的价值。因为那个代理集成了生产日志、数据库，它拥有完全的可见性。而且随着时间的推移，还有关于如何解决某些问题的playbook。
这是一个巨大的胜利，因为instantly你就可以拥有完整的轨迹，了解发生了什么。有时候，实际上可以直接从那里产生一个Pull Request。
Walden Yan：对，Open Inspect也支持这种触发器。所以可以完全自主地发生。
另一个我看到的常见用例是：非构建者用例。PM或营销团队开始使用它。我现在看到很多团队中，"谁实际上在贡献代码"开始发生变化。
在很多情况下，PM如果只是一个快速的错误修复，PM不再创建一个issue了。PM只是通过Slack prompt，然后Pull Request就被创建了。我认为这个趋势会继续：我们将看到代码修改发生在工程之外。
最后一个常见用例是客户支持。当客户遇到问题时，他们不完全确定为什么这个行为会发生。以前的世界是："嘿，他们尝试使用这个功能时有一个bug。我们不知道发生了什么。"现在他们可以在Slack里标记。同样，完整的上下文已经准备好了。
八、结语与展望
主持人：好了，我想我们差不多该结束了。在结束之前，你们有什么想补充的吗？
Walden Yan：我想说的就是：背景代理的时代已经到来。每个人都在构建它们。我们看到的是一个真正的Zeitgeist（时代精神）。公司们想要把自己驱动进这些自主编码工厂。
Cole Murray：对，我想补充的是：如果你正在考虑构建你自己的背景代理系统，记住架构决策真的很重要。你是把代理放在盒子里还是盒子外？你如何管理状态？你如何做测试？你如何做记忆？
主持人：太棒了。感谢两位今天的到来。这真的是一场很棒的对话。
Walden Yan：谢谢你邀请我们。
Cole Murray：是的，谢谢。
视频链接：https://www.youtube.com/watch?v=0fgJPhYcbVk