异步智能体时代 — Cognition的Walden Yan与OpenInspect的Cole Murray
The Age of Async Agents — Cognition's Walden Yan & OpenInspect's Cole Murray
Cognition联合创始人Walden Yan与OpenInspect创建者Cole Murray在播客中讨论了后台agent系统的架构演进。Yan指出，2025年12月Opus 4.5和GPT-5.2等模型能力提升后，agent可自主从规格说明生成完整pull request。Devin在仓库中的提交占比从1月的16%升至3月的80%，PR使用量增长7倍。Murray介绍了OpenInspect的开源设计，强调箱外架构（agent与沙箱分离）在安全性和权限管理上的优势。双方探讨了记忆系统、MCP集成、测试功能及多agent协作的挑战，认为单agent模式当前更实用。
好，我们现在在录音室，与 Cognition 联合创始人兼 CPO Walden Yan 一起。
嗯，很高兴来到这里。
这个头衔很酷。没错，也是"上下文工程"（context engineering）这个词的创造者。
是的，是的。虽然我觉得之前已经有很多人以各种方式使用过这些术语，但我确实发现，无论是内部还是外部，大家都挺喜欢从"提示工程"（prompt engineering）或"模型包装"（model wrapping）升级到一种更审慎的方式来构建 agent。
对，对于那些还没跟上这个话题的人，我屏幕上现在显示的是《不要构建多 Agent 系统》那篇文章，你们应该读一读，我们可能也会提到。还有 Cole Murray，他创建了 OpenInspect。
很高兴来到这里。
好，那我们就来聊聊吧。每个人都在构建自己的 DevIn。这是怎么回事？
嗯，我觉得工程界正在逐渐意识到后台 agent、云端 agent 这类概念。我认为在 2025 年 12 月左右出现了一个转折点，当时 Opus 4.5 和 GPT-5.2 这些模型的能力达到了一个新水平，我们不再需要手把手地引导模型，而是可以基本上自主地驱动它。我的意思是，只要规格说明足够好，我们几乎可以从规格直接走到一个完整的 pull request，中间几乎没有摩擦。光是这个范式，我觉得就改变了很多我们与 agent 交互的方式，也打开了后台 agent 变得更实用的世界。
我觉得对 Carl 来说，每个人在 12 月都经历了这个。但我觉得这就像是一个不断加速的过程，对吧？比如有一个时刻，我记得是 Sonnet 3.7，你们好像一夜之间重写了 Devin 之类的。
是的。对，对。
那么描述一下 2025 年，或者从你们的角度看是什么感觉？
回想起来，我们一直觉得它在加速，但即使到现在，从今天往回看过去的三四个月，它加速得更快了。所以现在谈论 Sonnet 3.7 的飞跃有多大，其实有点好笑。老实说，我们当时做的很多工作就是去掉 Devin 中那些随着智能提升而不再需要的部分。但我也觉得，最近很多飞跃，尤其是像 Opus 和最新的 GPT 模型，它们已经达到了一个自主性水平，人们真的发现可以完全放手。那些曾经争论"我是不是需要在 IDE 里和模型一起深入细节？"的人，现在开始认真考虑"我能不能直接把它完全搬到云端？"我们在内部的所有增长图表中都看到了这一点。有一个有趣的图表显示，我们的 PR 或合并 PR 的使用量增长了 7 倍，我忘了是从什么时候开始的了。
我觉得 Div 可能发过推文。
对。
是的。
在过去大概两个月、三个月左右的时间里，它增长了 7 倍。然后你看我们的工程人员增长，大概只增加了 10% 左右。
我们当时都不敢发布这个数据。所以这是 Devin 在所有 Devin 仓库中的提交占比，1 月份是 16%，现在 3 月份是 80%。
对。
现在确实是一个巨大的转变。所以很多人现在在考虑购买 Devin，但也在尝试自己构建，这很合理。而且有很多——我构建 Devin 的过程很有趣，所以我能理解为什么其他人也想构建自己的云端 agent。
对。
嗯，也许听听你最初是什么启发你构建 OpenInspect 的会不错。
对。OpenInspect 的诞生主要源于我的客户观察他们如何使用像 Cloud Web、OpenAI 的 Codex 这样的工具，并看到了其中一些摩擦点。主要是 Claude Web 是通过 Slack 使用的，他们遇到的一个大问题是，这些启动的会话只对通过 Slack 调用它的人可见。
嗯。
所以如果 PM 发起了会话，然后想把上下文传给工程团队，工程团队是看不到这个会话的。这本身就是一个障碍，因为 PM 会说"嘿，工程团队，你们能介入一下吗？"但除非他们复制粘贴出来，或者只看到返回的单个回复，否则没什么可介入的。所以看到这些问题后，我在内部构建了一个类似的架构，只是为了实验，测试不同的想法，因为这种从本地主机迁移的趋势开始显现。当 Ramp 发布他们的博客文章时，我已经有了很多现成的组件，只是觉得看看 Claude 仅凭那篇博客文章能做出什么会很有趣。在我的 X 账号上，其实有一个直播记录，我一边做一边发推。
哦，哇。
比较 GPT 和 Claude 两者在完成这个任务时的表现。
是在公告发布的时候还是别的什么？
就在它发布之后。
好的。
我们可以把它放在节目笔记里。
好的。
对。
有帮助的是，我已经知道如何验证这个系统。我知道我在找什么。我觉得 Grant 做得很好，他清晰地说明了构建这样一个系统的技术细节。这不仅仅是"嘿，我们建了一个很棒的系统的"，而是"这是你也可以构建它的方法"。所以我对此很有共鸣，因为它正好对应了我已经看到的问题。而且我环顾四周，在开源社区里并没有真正看到符合这种类型的系统。有很多在本地主机上运行的，比如 Superset、Conductor 等等，但没有一个真正在云端运行。所以我就构建了它，并且觉得把它开源，让任何人都能有一个基础来在上面进行混搭，会很有意思。
所以实际上在 Devin 发布之后，就有了 OpenDevin，后来变成了 All Hands。我不知道你有没有试过那个——
对，我正想说，OpenInspect 让我很感兴趣的一点是，你没有试图把它变成可以赚钱的东西。有很多这样的开源项目会立刻去寻求 VC 融资。
所以我想知道 OpenDevin 的情况。
对。对。你是怎么考虑这个问题的？我觉得这很有意思。
我认为，根据我在客户那里看到的情况，后台 agent 系统将成为他们公司内部的关键基础设施。正因为如此，我想把它开源，这样他们就可以 fork 它，加入任何他们想要的定制。至于那个问题，我经常被问到"哦，你会融资吗？你会把它变成一个服务吗？"
我肯定你收到过邀约。
嗯，但主要是我出于几个原因不想这么做。第一，我觉得我不想为了每个座位 20 美元去竞争。我认为那是一个非常困难的生意。我觉得它的主要部分很容易被复制。我的意思是，我很快就构建了它，而且我认为因为你并不拥有整个技术栈，所以很难变现。在沙箱层，有 Daytona、E2B 和其他很多玩家在赚钱。在模型层，也有玩家在赚钱。而你处在一个奇怪的灰色地带，你到底在卖什么？你卖的是基础设施，也许是集成能力。
我们来问问这位，你在卖什么？
嗯，这个问题有好几层。实际上，你提到基础设施挺有意思的，因为我们刚开始做 Devin 的时候，也得自己去琢磨怎么搭建基础设施，因为——
你比其他人早两年就得开始搞这个，对吧？
对，没错。而且包括内部的东西——一开始其实挺粗糙的。比如我们直接用云服务商（像 EC2）的原始虚拟机来搭，启动速度特别慢。尤其是关掉机器、保存状态，然后再让 Devin 重新启动的时候，它得冷启动差不多 10 分钟，因为这些系统本来就不是为这种反复开关的使用场景设计的。所以我们不得不自己去解决这些问题。结果现在，我们卖 Devin 的时候，有一项服务就是：你不用操心计算资源这块，我们来搞定。如果你愿意，我们可以在你的云环境里运行。不过除了产品本身，我后面还想聊聊 agent 和智能调优的部分，但我觉得 Cognition 做的很大一部分工作，就是确保你的公司能学会、用上并采纳这些编码 agent。因为尤其是对全球那些大型企业来说，很多人想在日常工作中用 AI，但由于项目规划的方式，加上不是每个人都懂怎么用 AI，所以有一支工程师团队能帮你上手、配置好所有需要的集成和自动化，让你真正达到用 AI 提升效率的水平，这非常有帮助。所以我们就是这么做的。我们也会作为思想伙伴，和客户一起合作。
那我们聊聊架构方面的事吧。我觉得这总是你们俩之间讨论的话题。你是想从这种心智模型开始，还是别的？我把话头交给你们。
好，我觉得我们可以先大致讲讲后台 agent 系统由哪些部分组成，然后再深入探讨一些决策上的细微差别。
不过我想 Walden 刚才说的意思是，agent 就像在一个开放的代码箱子里，对吧？这是基础设施，然后那是 agent。你们讨论过是把 agent 放在箱子里还是箱子外。能展开说说吗？
好。在后台 agent 系统中，你需要决定 agent 实际运行的位置。这通常被称为"箱内"或"箱外"的 harness。如果选择箱内运行，你会做出一些权衡。负面权衡主要是安全性，因为 agent 在箱子里运行。除非你特别设计，否则你所有的密钥也得放进那个箱子里。考虑到 AI 的不可预测性，你很容易不小心泄露密钥，或者出现其他意外行为。而箱外运行的意思是，agent 本身不直接在沙箱里运行，而是让所谓的"大脑"在某种 worker 或控制平面中运行。那个沙箱就充当"手"，大脑通过它来操作环境、调用工具。我觉得这两种系统之间的另一个权衡是，在我看来，箱外运行要复杂得多，因为你需要管理状态。而箱内运行时，agent 的所有状态实际上都在箱子里。当然，你也可以把它持久化到别处，但所有东西都是本地化的，你需要操心的事情更少。
我觉得你提到的很多点，正是为什么我们从一开始就把 Devin 设计成所谓的"大脑与机器分离"。这样做还有一个好处是，你可以复用现有的 DevBox 基础设施。这样你就不必太担心去造一种全新的 DevBox，里面要包含大脑所需的所有依赖，以及你提到的密钥。比如我们见过一些客户遇到的问题：你有一个 GitHub 应用，想让 Devin（你的 agent）通过这个应用和 GitHub 交互。但不同用户有不同的实际权限。没错。如果他们都通过同一个 GitHub 应用交互，而决定 agent 行为的系统和机器上的实际密钥之间没有真正的分离，那就会出问题——很难做权限分离。但在 Devin 的实践中，这就简单多了，因为我们规定：机器上放什么，就决定了用户和 agent 能做什么的范围。所以只把最受限的密钥放在那台机器上。而大脑从机器上是完全不可访问的。所以即使用户可以随意操作机器，你也不用担心大脑中最安全的部分被搞乱。
我正想说——我有一张 OpenAI 的图。我不知道这算不算"箱内"或"箱外"，他们确实用这个来描述。然后最近 Anthropic 也做了"管理 agent"——这是他们的东西。我不知道，反正都是同一模式的不同变体，对吧？
对，这应该算箱外。
对。
他们可能更喜欢这样，因为工作量更少。
我觉得工作量更大，但在我看来，这是两者中更好的架构。
好吧。
只是这样做会引入一些复杂性。
有一件事我没看到很多其他玩家做得好：如何管理箱子里实际有什么？这可能会很复杂，原因很多。比如，你有一个很大的代码仓库，经常变化和更新，依赖也在变。你怎么确保 agent 的工作环境始终保持最新？并且拥有运行应用、测试以及所有你想让自主 agent 做的事情所需的凭证？所以是仓库设置。对，没错。在 Cognition 内部，我们把仓库设置称为最难的部分——从公司成立以来就一直是个长期问题：怎么帮人们搞定设置？因为不是每个人都有现成可用的云端工作环境。你觉得这对你的客户来说也是个常见问题吗？
对，这非常常见。在我的咨询工作中，很大一部分就是帮团队解决这个问题。很多团队其实没有很好的开发者环境设置，甚至根本没有。很多时候就是"去找 Bob 要密钥"。这显然在 agent 需要自己设置环境时行不通。所以大多数团队都在用 Docker Compose 或某种微服务架构。然后——
你指的是生产环境吗？
不是生产环境。比如用 OpenInspect，主要是用来交互和修改代码。也有其他用例，但你可以通过 CLI、MCP 或其他工具把它接入生产系统，主要用于 SRE 这类场景。但你并不一定需要通过这个系统去测试生产环境中的内部微服务。
对，你提到了 Docker Compose。我觉得我们有些朋友早期走的一个方向是用 Docker 容器，把 Docker 作为模型的抽象层。有很多原因让我觉得 Docker 容器并不理想。首先，Docker 容器并不是真正的安全边界，其次，如果你在跑实际的应用，很多时候这些应用本身就用了 Docker，然后你就得考虑 Docker 嵌套 Docker，这真的很奇怪。所以我认为，让虚拟机（VM）跑起来之所以是个难题，原因就在这里。我们为什么选择虚拟机？因为我们意识到，要做这类事情，实际上需要完整的虚拟机。尤其是现在，跑应用、点来点去、发屏幕录制这些操作本身就有价值，而且这种价值还在不断叠加。但这也是我看到人们在搭建自己的系统时经常遇到的一个决策点：我们到底该把 agent 放在机器里面还是外面？用 Docker 还是别的什么？你现在会推荐人们用什么？
我觉得 Docker 可能不是用来跑 agent 的好方案，但用来跑你的基础设施还不错，因为这跟你的工程师们可能已经在用的配置差不多。如果他们没用 Docker，那我也不知道他们在用什么了，但他们大概率已经在用 Docker Compose 了。
对。我一直对 WebContainers 有点情结。不知道你们试过没有。
哦，试过。
对我来说，它本来应该像是 Docker Lite 那种东西。
没，我没试过。
嗯。
不过，我觉得任何你搭建好的、对开发者体验友好的环境，自然也会让 agent 容易配置。一旦你搞定了本地开发的那一套，基本上也就解决了 agent 在沙盒环境里的设置问题。OpenInspect 也有钩子（hooks），你可以跑一个 setup.sh 脚本，预装所有东西。然后你可以预先快照那个构建，这样它就能瞬间启动。之后还有第二个钩子，用来在沙盒恢复时还原状态。这样你就可以让所有微服务都跑起来，在沙盒里获得跟本地机器上几乎一样的体验。
我们还在想的一个问题是不同类型的虚拟机服务。你们有没有遇到过客户需要 macOS 专用虚拟机或者 Windows 专用虚拟机的情况？
目前还没有。
世界上有很多技术只适用于特定类型的机器，对吧？比如你要构建一个必须在 Windows 上跑的 .NET 应用，或者更常见的是，你想开发 iOS 或 macOS 应用。
对，Commission 支持这类选择吗？
从底层架构上来说，因为我们做了分离，所以是支持的，但实际的工作还在进行中。我们最近刚添加的一个功能（还在 beta 阶段）是支持 Android 开发。要做到这一点，我们需要支持虚拟机内的嵌套虚拟化（nested virtualization），因为虚拟机本身是一个虚拟化的 Firecracker 实例，然后你还要在里面再跑一个 Android 模拟器。这里面有一些奇怪的性能问题，所以它还在 beta 阶段。我们需要想清楚这些问题，但这为想做 Android 开发的人解锁了很多可能性。
我本来想找一个关于测试功能的参考视频，但没找到。不过我记得你做过测试功能。为什么叫测试，而不是叫计算机使用（computer use）？或者说，这个问题的通用类别是什么？
当人们想到 AI 运行你的应用并测试它的能力时，我觉得他们往往过度关注计算机使用这部分。因为在我看来，计算机使用就是字面上的：你知道要点击哪个按钮，能不能发出正确的坐标去点那个按钮。而我认为测试对这些 AI 来说，其实是一个很有意思的解题挑战。因为如果你要做任意测试，想象一下你做了一个改动，涉及前端和后端，甚至可能还有更深层的嵌套服务。要真正测试那个改动，我们需要推理：首先，如何用正确的代码版本把这些应用编排起来，让它们互相配合？然后，如何触发这个功能，或者如何让事情真正发生？这可能会变得非常复杂。你可能需要是管理员，某个功能可能需要通过 feature flag 开启，你可能需要跑两个会话，然后向其中一个发送一个特定的词来触发某个行为。要搞清楚怎么做，需要大量的代码库上下文，需要很多我们专门做的编排工作。在某些情况下，我们发现实际上没有哪个前沿模型（frontier model）能独立完成这个完整的端到端任务。我们见过一些情况，需要把不同的前沿模型编排在一起，共同解决这个问题。这就是我们在思考测试问题时花最多时间的地方，而不是计算机使用那部分。顺便说一句，计算机使用随着最近模型的进步已经好多了，让那部分工作确实变得更容易了。
对，尤其是昨天发布的 4.7，据说在视觉方面好多了，这也会涵盖计算机使用。
为所有这些建立评估（evals）也需要花时间，而且让评估正确也很棘手。你有没有见过那些自己构建 agent 的客户，需要开始搭建评估来确保功能不会退化？
倒不是传统意义上的评估，但具体到测试这部分，我们已经开始做了。我刚添加了对截图的支持，理论上你也可以做视频。我需要加一个插件来实现，但它们本身是原生支持的，而且这是一个被强烈要求的功能。尤其是在 Cursor 的录制视频出来之后。我觉得那对所有人来说都很有启发：哦，这确实是个很好的功能。我觉得 Devin 你们早就有了这个功能。
对，他是第一个。
哦，我明白截图是怎么工作的了。对，我觉得没什么特别不明显的。基本上，一旦你知道要构建什么产品功能，你就可以直接给它一个 prompt，然后它基本上就能跑起来。
我觉得 Walden 说得对，计算机使用其实是更大的测试问题的一个子集。而且我认为这跟你正在开发的代码库非常相关。这不是一个开箱即用就能解决的问题。你确实需要代码库的上下文，才能真正知道怎么测试它。而且我认为，在后台 agent 系统的情况下，幸运的是你本地就有那个代码库，你知道什么在变化，然后可以检查它，并用它来驱动模型。
对，没错。
对于还没见过的人，这是一个它如何运作的例子。比如，PR完成后，你点击“测试通过”，它就会给你返回一段视频。我特别喜欢的是它会标注——这里字很小，但它确实标注了它在测试什么。然后，你还能看到光标和一切。所以，我不知道，嗯，这里的工程实现，你想展示什么都可以，因为这就是那种“哦，感受到AGI时刻”的感觉，对吧？因为一旦我看到这个，我其实就不需要——我希望我能在Slack里直接合并，而不是去GitHub，因为我不需要看代码。我知道它没问题。
也许未来可以。嗯，底部的注释对我来说也是一个很大的改进，当我加上它们的时候。
是啊，就像是在问：我在看什么？
你想展示什么？没错。有一长串意想不到的小细节，最终对这类端到端指标——比如你实际合并代码的速度——产生了很大影响。我们早期花了很多时间调整的一个体验是，这些工具在GitHub上应该提供什么样的正确体验。
当然。
因为我认为，大多数工具在构建agent时，会想：“哦，它会为你创建PR。” 我们试图更进一步，说：“哦，如果我们能确保你直接在GitHub上与Devin互动呢？” 所以我们确保你可以在GitHub上评论，而Devin实际上会收到这些评论并回复。但这里其实需要做相当多的调整，因为你可以想象，比如我们最近有了Devin Review，Devin Review会在自己的PR上发评论，然后Devin又得去处理。
它回复自己的评论，这真的很绕。所以，嗯，我喜欢它在这里更新说我已经评论了，但通常只是我说：“嘿，合并，修复任何合并冲突。”
是的。所以当Devin修复自己的评论时，你可能会担心：“哦，看，也许它会无限循环。” 但我们做了很多工作来确保它不会，既通过确保评论是高信号的，也通过让agent对哪些评论它应该立即去修复、哪些评论它觉得“等等，我认为你错了”保持深思熟虑。实际上，我最喜欢的时刻之一就是当我试图让它做不同的事情时，Devin告诉我我错了。嗯，但调整这种行为，实际上对GitHub体验的实用性有很大影响。是的。
是的。我也想提一下，我认为将AI审查员集成到系统中是这个后台系统的关键部分。嗯，OpenInspect确实有这个功能。它有一个GitHub代码审查员，你可以控制提示词。嗯，它也能做评论，但还不是自动的。功能是有的，但还没有完全——
所以你需要主动请求它？
哦，是的，你需要。你可以在GitHub上@它，然后无论你给GitHub机器人起什么名字，它都会跟进。
好的。
然后，如果你有合并冲突或你要求它解决的其他问题，它就会解决。但它目前还不是自动的。
嗯，我很好奇，当你帮助客户实施OpenInspect时，他们最常要求但还需要额外补充的东西是什么？
我认为很多都归结为将其实际集成到公司中。搭建后台agent系统是一回事，但如果它没有真正集成到你的更大生态系统中，它就没那么有用。我的意思是，能够启动会话是有用的，但我们真正想要的是将它连接到我们所有的其他系统，无论是带有只读凭证的生产数据库、日志、Confluence还是内部知识库系统。我认为这就是我看到公司巨大飞跃的地方。对于可能不熟悉具体如何操作的公司来说，这也可能是一个挑战，尤其是当他们处于合规性要求较高的环境中，访问控制可能非常严格。如何有意识地思考这些问题？我发现这是这类系统带来的问题之一。
是的，我们发现，像MCP显然已经引发了巨大的爆发：“哦，你可以把它集成到所有这些不同的东西上。” 但为了真正做好集成并获得正确的体验，我们经常发现必须自己构建一些临时方案。我认为Slack就是一个很好的例子。你可以给你的agent一个Slack MCP，然后它就能在Slack上给你发消息。但实际上，我们在Slack中把Devin当作同事来使用，它从一开始就是这样构建的。但要做到这一点，你实际上需要支持返回的webhook，对吧？然后Devin必须以自然的方式回复，并且希望不要在你的频道里刷屏太多，惹恼公司里的人。所以你必须把这种体验调整得恰到好处，尤其是在有很多来回沟通的时候。我们发现，在这些地方，我们实际上不得不超越简单的MCP集成。
我刚刚打开了MCP市场。我知道这工作量不小。嗯，我的意思是，最终的答案是不是要第一方控制所有顶级的MCP？这是不是——
我希望有一个世界，你能拥有比MCP更具表现力的东西。
好的。
那种东西是双向的，不仅仅是一套工具，而是一个能与之交互、并在所有这些界面中提供正确体验的恰当系统。
所以实际上MCP规范里有采样功能，但没人用它。对吧。
所以我认为另一部分是，我们实际上发现，当MCP规范开始变得过于复杂时，它就失去了最初作为简单一步连接承诺的价值。就像现在，我们得去弄清楚如何支持所有这些不同的变体，在很多情况下，它开始看起来很像只是构建第一方集成。
是的，我认为这还取决于它对你们公司有多关键，对吧？如果几乎每个会话都要用到它，那么拥有它以便你能在上面进行优化，而不是仅仅使用现成的方案，可能是有意义的。
是的。太棒了。其他MCP呢？还有什么？呃，抱歉。嗯，我不知道这是不是太局限于集成方面了，但还有什么？比如构建OpenInspect或Devin时，你们真正达成共识的其他要素是什么？
是的，我认为一个非常频繁出现的问题是记忆或知识库这个概念。
哦，天哪。
是的。
你们怎么解决？
呃，简短的回答是，还没解决。嗯，这是一个——有一个公开的issue，有人在问这个问题。
嗯，好吧，我——呃，DeepWiki还没有索引任何关于记忆的内容。
嗯，我在我的客户中看到的主要解决方案是通过Skills。我发现Skills可以在一定程度上弥补这个缺口，或者更新ClaudeMD。但我认为记忆作为一个整体是一个相当未解决的问题，这也是我一直犹豫是否要添加它的原因。我认为记忆的某些部分是可以解决的，但作为一个整体，这是一个非常困难的检索问题。
哦，天哪，RAMP没有写任何关于记忆的内容。我看到零个搜索结果。
记忆功能要做好其实相当棘手，因为它既涉及检索，又涉及记忆的生成。你并不希望它只是机械地记住非常具体的细节。
跟我们讲讲 Devin 的记忆功能发展历程吧，我知道这经历了不少演变。
第一个相对稳定的记忆版本是我们称之为 Knowledge 的系统。我们的想法是让它随时间自动学习，而不需要用户主动去教 Devin 东西。所以，每当用户提醒 Devin"等等，Git 不是这么用的"，我们希望 Devin 能主动说："嘿，你想让我记住这个，以后注意吗？"然后用户只需快速批准或拒绝，系统就会逐渐积累。我发现 Devin 大约 95% 的记忆——或者类似的高比例——都是通过这些自动生成的机制产生的。很少有人愿意坐下来写长篇文档，详细说明"你应该这样使用这项技术"之类的。生成和检索这两方面，我们多年来一直在不断调优。生成方面，你不想让它记住一次性的请求，比如"请以草稿 PR 形式打开"，然后它就认为以后所有人都应该以草稿 PR 形式提交。但你确实希望有一些通用的规则，比如"Cole 通常喜欢以草稿 PR 形式创建内容"。检索也是如此。如果你有成千上万条记忆，如何确保在正确的时间检索到正确的信息？这很难做好，因为既要避免在上下文中塞入大量无用信息，又要保证准确性。随着新模型的不断出现，为了确保记忆系统保持可靠，我们做了大量评估工作，数量惊人。
嗯。
关于记忆修剪，你有什么可以分享的吗？
对。
还有记忆的时间维度方面。
对，没错。
嗯。
目前，系统可以编辑记忆。比如，如果记忆里写着"Cole 喜欢把所有东西都做成草稿 PR"，你可以说"不，别这样"，然后系统会问："你想把记忆更新为 Cole 现在希望所有东西都做成公开 PR 吗？"不过，我们也不确定这是否是系统的最终形态。现在积累的经验很可能会转化到我们即将推出的新系统中。但我认为，两年前和现在的一个重大区别是，这些 agent 非常擅长原生地使用任何类似文件系统的结构。所以我们也在思考：是否应该把记忆重建得更像文件系统，让 agent 自己去导航？这是一个有趣的探索方向。在技能（skill）方面也有一些想法。
我现在正在查看 OpenClaw 的记忆功能。OpenClaw 有一个每日记忆日志，对吧？你可以把它当作一个文件系统来 grep，它就是一个事实来源。我不知道这是不是最好的方式，可能噪音很大。但至少如果你丢失了某些信息，你可以重新发现它，或者对更久远的、不再被调用的记忆应用某种遗忘算法。
我们一直在尝试推动 agent 在公司内部的使用边界，其中一个方法是让 agent 拥有一个类似 memory.md 的文件，就像你的永久项目经理一样，专门处理某一类问题。比如，我们内部有一些 Slack 频道，可能有一个专门针对某个产品（比如 DeepWiki）的频道。你可以想象，你希望有一个永不停止的 Devin，它始终在线，但会维护一个记忆文档，记录诸如"当前需要修复和优先处理的首要任务是什么？"、"谁负责接下来的工作？"等信息。Devin 甚至可能会定期 @ 你。这是一个有趣的尝试，看看我们如何让 Devin 不仅仅用于工程，还能向上游延伸到工程流程之上。也许 Devin 只是创建工单，然后由人类或其他 Devin 去执行。
我比较喜欢的一个自动化功能是每周研究竞争对手，然后给我提建议。这就是自动化。我现在找不到它了，但基本上就是让它看看竞争对手，然后提建议。当然，我可以在提示词里加上"这是你之前提过的 3 个建议，我不想再看到了"。但我其实希望，比如当我拒绝一个 PR 时，它能自动更新记忆，这样我就不用再回去更新定时同步了。不过，这算是个功能请求吧。
我们可能很快就会改版。OpenInspect，在你参与的这段时间里，有没有什么功能是你尝试实现，后来又不得不推翻重做的？
目前还没有。但我一直在想的是，我最初的设计是每个集成都作为一个独立的包存在。比如 Slack 机器人负责处理 webhook，然后与控制平面交互。但随着系统越来越集成，特别是与 GitHub 机器人集成的加入，我正在考虑把所有东西都集中到中央控制平面。因为现在我开始收到一些请求，比如希望能够监控实际合并的 PR，以及跟踪我当前打开了哪些 PR、有多少被合并、有多少评论出现等等，以便了解系统的健康状况。对于 GitHub 应用来说，只有一个 webhook。那么问题就来了：我是把这个 webhook 放在 GitHub 机器人包里？这有点奇怪，因为那个包主要是用于代码审查的，放在那里不太合理。还是说，我应该把它集中化？这是我正在考虑的一个决策。另一个我们之前提到过的问题是，执行环境（harness）是在沙箱内还是沙箱外。我认为长期来看，架构最终会回到沙箱外。我添加的一些新工具会回调到控制平面，这样沙箱里就不需要保存密钥了。所以长期来看，我可能会把 agent 本身从沙箱中移出来，但目前这样也还行。
关于把 agent 从沙箱中移出来，我有个小问题。
我——
今年我非常看好的一点是 agent 调用其他 agent，或者生成子 agent，随便你怎么称呼。
对。
这会让事情变得更难还是更容易？我拿不准。因为如果执行环境在沙箱内，你可以直接生成更多沙箱。但如果执行环境在沙箱外，就没那么容易了，因为你有一个像独角兽宠物一样独特的执行环境，它活在沙箱外面。
理论上来说，方式是一样的，对吧？无论一个 agent 是否在其中启动了多个子会话，比如 OpenInspect 就可以启动子会话，创建其他环境并进行监控。如果是开箱即用的情况，那基本上就是额外运行一个会话。这个会话也在盒子之外运行，在你的工作平面（worker plane）上，无论你在哪里运行它。然后你只需要考虑你的顶层 agent 如何与它交互。我确实认为这会变得更复杂，因为架构更困难了，但我觉得一旦你搞清楚了，应该就没问题了。
是的，Walden，我想把这个问题抛给你，我称之为“元 Devin 管理”，就是 Devin 调用 Devin、Devin 调度 Devin、查询轨迹之类的。你构建过什么，或者有什么没发布的东西吗？
我觉得我们观察到的一个令人惊讶的现象是，这些独立的 agent 相互协作、并行工作，大多还是遵循了相同的“管理者-子 agent”模式。很多人对那种 agent 群到处互相交流的场景感到兴奋。我们实际上给了 Devin 一个 MCP，这样它们可以随意向其他 Devin 发送消息、创建新的 Devin 等等。但我觉得这反而会创造一个相当混乱的世界。所以我们发现，日常最实用的方式仍然是单个 agent。关键在于如何划分工作，让其他 Devin 在相对隔离的环境下处理，每个都有自己的盒子，不共享机器。这样冲突空间很小，这就是你今天必须建立的模式。
我想提一下 Cursor 的实验，对吧？这是 Wilson Lin 关于从单 agent 到多 agent 的研究。你显然以反对构建多 agent 而闻名，但他们经历了整个过程，最终得出的结论正是 Devin 已经做到的。
我觉得那篇文章迟早会有修订版。告诉我们吧。我认为一年前多 agent 几乎完全不可行。今天确实能看到更多多 agent 的实验，但你可以争论，它们真的是多 agent 吗，还是只是工具调用？比如，有人会创建子 agent 去查找某个 XYZ 文件或实现。这在上下文管理上有很大好处，因为所有工具调用和 token 消耗最终都会压缩成主 agent 的答案。这样做有很多好处。我们基本上让 Devin 通过 DeepBookie 来做这件事，调用 DeepBookie 并返回结果。但这感觉像工具调用，而不是两个协作者真正来回交流。但让我对多 agent 可能实现感到最乐观的，是我之前提到的，Devin 有时会告诉我我错了并反驳。我认为这展示了当今通信的成熟度，让多 agent 世界成为可能。比如，两个看到不同信息的 agent 如何相互交流，判断谁是对的？正确的实现是什么？它们不只是唯唯诺诺的应声虫。Claude 似乎总是说“你是对的”。
或者“你完全正确”。
你完全正确。
是的。你看到 Codex 应用的那个恶搞和话题了吗？就是 Codex 应用。设置里有个小彩蛋。如果你进去，比如主题或外观，那里有各种颜色代码，最上面是“绝对”，用的是 Anthropic 的颜色，真是个恶搞。
我喜欢那个彩蛋。你自己发现的吗？
不，是有人在推特上发的，我就在想这是真的吗？因为有时候人们发推只是为了逗你玩，但确实如此，Anthropic 的颜色。
是的，我们已经走出了那种只会说“你完全正确”的阶段，它们可以进行真正的对话和来回交流。
是的，你也可以通过提示让它更具对抗性之类的。
对。
对我来说，这更像是智能，对吧？这不仅仅是一个愚蠢的工具，它实际上在反驳你。
你提到那篇博客文章时，有一篇他们让一群 agent 一起工作，构建了一个浏览器。
对，对，我觉得就是那篇。
你可以有一个——
我觉得是同一篇。
对，对。我们发现一个令人惊讶的成功经验是，不要搞什么群，只要一个 Devin，它有自己的上下文维度，让它一直运行，给它一些疯狂的任务。我们让它重建一个 Windows 操作系统。它居然做到了，只要运行足够长时间。这是 Andrew 搞的吗？对，对。有很多演示我们最终没发，因为发太多 demo 了。但我喜欢这个，因为它表明多 agent 仍然有点令人兴奋的魅力，可能还超出了它实际为系统能力带来的增量。但这绝对是未来。我们正朝那个方向前进，已经能看到进展了。
如果我要稍微反驳一下，因为我对此还不太确定，但我请过 OpenAI 的 Ryan Lopopolo 来播客，他是个大炮，对吧？天哪。我的编码 agent 完成了。我下载了一个叫 Pong Ping 的东西，不知道你们听说过没。它从热门游戏里提取音效包，比如《命令与征服》和《魔兽争霸》，然后在完成时播放。就像工作、工作之类的。总之，我从 Cursor 代码库和 Ryan 那里学到的是，有一种大炮式的方法，试图放松单 agent 的瓶颈。我觉得这可能是需要解决的一个非常重要的问题。我不认为有人真正解决了，因为那样你就需要在 agent 之上再加一个审查者来管理一切。Ryan 可能会强烈反对我说他没解决，他认为自己完全解决了。但我认为这很重要，因为那是个瓶颈。我觉得 Devin 有时很慢，因为我想，嗯，这很可读、很合理，但也比它本可以的速度慢——我想要一个按钮，直接说“把这个并行加速 1000 倍，看看会发生什么”。我不知道这在未来是否可行。
是的，我们也在内部做过实验，尝试构建完整的产品，比如我们知道自己最终会发布的产品。但暂时先试试看能不能纯粹靠 vibe coding 叠加、自动合并、不做代码审查来完成。然后有一个基准测试：你能坚持多少周，直到不得不扔掉这个代码库？实际上，我们为《星际迷航 3》读过这个。
你发现了什么？
我们发现去年12月时，最先进的做法大概需要跑两周。两周结束后你会发现，嘿，想改个按钮颜色？结果这个按钮在10个不同地方实现，各有各的变体，哦，你还漏了一个，那个地方颜色还稍微不一样。你会想，好吧，这——工作量太大了。不如同时做代码审查，确保我们掌控全局。我们实际上在清理代码，确保它以可扩展的方式完成。
对，在此基础上，我觉得那种"你不需要看代码"的想法通常是个坏主意。我有个梗——什么时间线？
好吧，你觉得这个说法什么时候会成立？
我觉得可能在一段时间内，你仍然应该继续看自己的代码。我合作过的很多团队，那些拥抱AI原生、AI优先编码的团队，遇到的一个问题是：你的代码库会退化到你最差工程师的水平。因为那个对AI特别热衷、又不审查代码的工程师，他的模式会固化到代码里，然后AI开始引用他的模式。于是他那20个if-else来回嵌套的块，AI会认为这就是做事的方式，然后开始指数级地扩散这种垃圾代码。我发现，一个不错的应对方法是定期清理，无论是人工还是通过系统检测重复代码，然后处理掉。否则你会搞出12个格式化日期的辅助函数，必须处理，不然它会继续蔓延。
在一定范围内，我觉得有些重复是可以接受的，然后偶尔做一次垃圾回收，对吧？对，我和很多工程负责人聊过，关键是要在模块之间设定非常严格的边界。作为架构师、CTO，你的职责就是明确说：好，这是你们和你们之间的硬性契约。你们在这个黑盒里做什么是你们的事，随便。但这两边之间，必须非常清晰，任何变动都要由人或我来签字确认，就这样。我不知道你们有没有其他补充或建议。
嗯，关于人类在哪些地方有用，我发现一些很深层的基建问题，有时只要有一个真正深谙此道的专家，就能带来巨大改变。我实际看到过这在构建agent时发挥作用。我们有几个朋友尝试自己构建编码agent。我反复听到的一个共同问题是：grep在agent的机器上非常慢。很多人，大概因为他们用AI，自己又没有很深的基建背景，就说：好，我们自己建一个自定义的grep索引，让它飞快，绕过这个问题。我们大概一年半前在早期构建Devin时也遇到这个问题，当时我们显然没有AI可以直接问怎么做，你不能随便搭个新grep索引。
你是说你们手写了Devin？
什么？对，你能相信我们手写了这些代码吗？我们的基建人员非常出色，他们研究后说：哦，你知道吗？我们意识到这个问题的根本原因其实很简单，但很细节——很多虚拟机底层用的不是真实文件系统，而是网络文件系统，数据实际上缓存在S3上。所以每次grep时，实际上都在做网络调用。这就是为什么grep在这些机器上极慢。这又回到我们为了让这些机器正常工作而做的各种疯狂基建工作。如果你自己尝试，会有无数这样的小细节。所以我们最终不得不换掉那个网络文件系统。
对，我记得有篇相关文章，对吧？Silas写过一篇关于虚拟文件系统的。
哦，那又是另一回事了。那是块差异文件存储格式，我们构建的一种文件系统格式，让虚拟机可以快速启动和关闭。基本思路是：想象你有一个1TB的磁盘，你的agent只写了100行代码在上面，保存和恢复这个磁盘需要多久？大多数系统没有针对这种情况优化，所以工作量是TB级别的，因为你要保存所有内容再恢复。在我们的系统中，我们尝试构建一个增量叠加的文件系统。每次保存和恢复机器时，只做与文件系统差异成正比的工作。这大大缩短了Devin的启动时间。不过这个现在可能已经过时了，Devin内部有更新的系统，但确实有很多小细节要处理好，才能让Devin的日常体验良好。
这严格来说不是agent本身，而是agent基建。当你作为公司销售agent时，你卖的是agent加agent基建。
对，至少我们是这么做的。另一个好处是，把agent边缘和基建整合在一起，我们现在可以在任何环境中部署Devin。不需要等底层基建提供商去支持VPC、本地部署或FedGovCloud。我们可以自己搞定：既然我们拥有基础设施，怎么为你搭建起来？
对，而你们依赖Cloudflare。
Cloudflare运行控制平面。沙箱由Modal支持。
对。
贡献者刚加了Daytona。E2B在路线图上，而且已经有一个抽象层，任何贡献者想添加新提供商都可以加进去。
对。
太棒了。那么，你们合作的客户一般怎么处理？他们会尝试和这些第三方提供商签合同吗？还是自己内部做虚拟机？
我看到大多数用Modal。我觉得Modal有很好的——
给Modal点赞。给Modal点赞。
我觉得Modal的产品很棒，基本涵盖了所有沙箱需求，快照是其中很大一块。而且他们还提供GPU，整体来说是个很不错的选择。
对，没争议。
Modal很好，尤其是他们的容器产品最自然。特别是如果你愿意放弃完整的虚拟机需求，Modal是个可以快速启动东西的地方。
对。
有没有这种情况——Modal很Python化，但我觉得大部分工作负载已经转向JavaScript了。不知道你们有没有同感。
嗯，所以，所以，好吧。
我创办 Lanespace 和 AIE 这些项目的时候，大概一半用 Python 一半用 JS，对吧？差不多这个比例。现在我觉得这不对了。JS 已经赢了。不知道你们怎么看，可能我有点夸张，认知领域还有 C#、Java 之类的，但就全新的应用来说，你们有这种感觉吗？这重要吗？
我觉得这个领域里我看到的大多数库都是 Python 原生优先，尤其是在可观测性领域。不过话说回来，整个系统用同一种语言还是很有吸引力的，特别是前后端通信时，可以用统一的类型系统，这非常方便。
对。
这就是我不用 Modal 的原因。用 Modal 就得跑 JS。我是说，你可以在 Modal 里跑 JS，但就是多了一步，不是运行时的原生操作。
嗯，我不太确定，我的看法还不明确。
你有数据吗？
不知道。我不喜欢 Python 的一点是，每当 AI 写 Python 代码时，它总是用一些最奇怪的写法。
哦，是因为它混用了 Python 2 和 3 的写法吗？
对，我觉得就是混用了 2 和 3。不知道你有没有注意到，它总喜欢在对象上用 has attribute。简直了，真是的。
是啊。
但你不应该那么做。它应该报错才对——
因为它是在库代码上训练的。
我觉得更像是，从我看到的来看，这是一种奖励机制，它本质上不想——
哦，不想报错。对。
它不想让代码失败。所以即使它知道对象有这个属性，它也会用 getattr 来调用。对于很多转向更自主编码的客户，我们把它加进了 lint 规则：如果你用 getattr，你的 PR 就会失败。
哦，这个话题有意思。能再多说说吗？还有哪些是 AI 编码的迹象，需要你设置防护措施？
我们刚才聊到了 Opus 4.7。这个新模型的一个特点是写很多注释，不是每行都注释那种，而是像写 PRD 一样，在每个函数上面写一大段。但我要说，公平地讲，这些描述不像以前那样是垃圾内容。以前是"哦，这个函数是做什么的"，现在是"哦，这是实际的推理过程，为什么选这个方案，有哪些替代方案，为什么不用那些替代方案"。信息量还是太大。但我在想，如果你想要系统能长期自我维护，这方向可能还是对的。
哦，它们把规格说明写在了代码里。
对，脱离上下文写在代码里。
所以你认可这种做法？
但与此同时，这是个棘手的问题。也许我们可以给用户一个设置，控制代码的详细程度。我不太喜欢这样。我也想说，我喜欢注释，但请删掉它们。不过我能想象，未来某种类似的做法可能会成为现实。你们知道 Git AI 吗？知道。对，我们聊过。Git AI 的理念是，如果你运行一个 agent，实际发给 agent 的 prompt 应该和代码一起存储在 Git 元数据中，这样未来的 agent 可以引用它，代码审查机器人也可以引用。理想情况下，决策的背景信息始终和代码共存。这有点像给每个注释写 PRD 那种做法的更隐蔽版本。
对。我在等真正的利好场景，就是完全摆脱 Git。我还没到那一步，但我在找，因为那会是一个重大转变。
说到可见的垃圾内容，我经常在 GPT 模型上看到的一个模式是，不惜一切代价保持向后兼容。
它很喜欢这样。
它会做一些奇怪的 import X export，这样就不用修改模块的名字。我注意到 Claude 4.6 也开始这样做了。
哦不。
我觉得这又是一种奖励机制，它不想让失败发生。你可以通过 Semgrep 之类的工具来解决，这种行为很容易识别。但这是你只有在看到代码模式后才能学会的东西。
对。
未类型化的 tuple 是个大问题，就是随便放个 any 进去，比如 dict string any。这些也可以通过 lint 来解决。
好。还有别的吗？像 lint 这样的工具，还有 Devin Review，当然现在不是免费的了，但还在用。
我们建议团队在使用更多 AI agent 时注意一点，就是本地测试。最终，你希望 agent 能完成全部工作，不只是写代码，还要能运行和测试。很多代码库一开始并不是为此设计的。比如，你可能需要本地数据库、本地 Docker Compose 和 Postgres，这样就不用给 agent 任何生产环境的凭证来运行和测试代码。我们内部也做了很大调整，让很多核心组件可以纯粹在本地开发环境中测试，不需要集成任何线上服务。说实话，公司越老，要往这个方向调整的改动就越多。但现在你可以用 AI 来帮你完成这个迁移。
公司越老，为了做本地开发需要改的东西就越多？我觉得是这样。还是我理解错了？你是说大多数人都是直接集成所有服务来构建，没有切换到本地的代码路径？
尤其是当有很多不同的服务和微服务架构时，做这种切换，代码库越大就越难。如果你从一开始就构建正确，那可能还行。但世界上有很多公司在 Docker 出现之前就起步了，所以迟早得做迁移。
Devin 很擅长做 mock 服务器。对。我特别想做的一个项目，有点像 Little Snitch。
不知道你们有没有听说过 Little Snitch。
我电脑上就装了 Little Snitch。
它像一个中间人，能显示所有进出的流量。然后你可以从那里重建服务器，对吧？然后创建本地 mock。所以只要观察一会儿流量，你就能本地 mock 所有东西。
对。
这个想法有意思。
酷。不知道这个能不能成，但我想聊聊 Claude 代码泄露的事。因为通常我请 Anthropic 的人来，就不能聊这个。你们从 Claude 代码里学到什么了吗？
我挺惊讶的，RA 们对泄露不太感兴趣。我们没花太多时间在上面。
我就是随便问问——
不，我没怎么深入研究。
有道理。好的，在结束之前还有一件事。Windsor 2.0，你们又发布了一个新功能。是的。大致背景是，当你足够多地使用后台 agent 时，有时你会想把它们带到前台来。而那种从本地到云端的交接处理起来很棘手。然后，Devin 或者说 Cognition 已经做到了这一点。
是的，对我来说，这试图解决的最大差距还是：如何让测试过程尽可能快？当它能自主测试并给你发送视频时，那简直太神奇了。但有些非常困难的事情确实需要拉到本地来做。是的。我们只是希望 Windsurf 能成为你所有 agent 的本地指挥中心，包括后台 agent 和本地 agent。你可以想象，哦，好的，这个 agent 需要我审核一些东西。我就把它拉下来，把其他 agent 移到后台，去测试它。好了，搞定。然后进入下一个，对吧？你在后台有一些问题需要修复，只需点击批准。好的，设置好，启动一个后台 agent 去修复它。我希望有一个世界，我不用离开这个窗口，你知道，也许另一个我需要想办法少花时间的地方是 Slack，但也许，你知道，有一天我们也会想把这些也整合进来。
是的。那么，这需要本地和云端的二进制文件完全一样吗？
这里有趣的是，本地 agent 和云端 agent 的行为，我认为在理想状态下其实有些不同。我认为本地 agent，你希望它们更快一些，让用户来做决策。实际上不要试图自主去测试东西。而在后台 agent 模式下，当你启动它时，我认为 agent 应该假设我发送给用户的下一条消息应该包含用户需要的一切，并且，你知道，不要运行一下就停下来，而是持续运行直到完成测试。
好的。
所以你有——
所以那只是一个稍微不同的 prompt。
是的。但由于多种原因，因为我们做了很多工作来确保 Devin 能与不同的 Git 提供商、不同的操作系统和虚拟机配合工作，我们希望尽可能多地共享这些逻辑。所以出于我们自己的实际目的，我们尽量共享尽可能多的部分。
是的。是的。我的意思是，我无法想象在本地和云端之间来回切换需要多少工作。所以恭喜你们发布了这个功能。是的。
谢谢。
好的。在我们结束之前还有什么要讨论的吗？就是你们午餐时聊的那些。
也许聊聊用例。你觉得你的客户目前用云端 agent 做的最主要的事情是什么？
你想再问一遍吗，这样我们可以有个干净的片段？
是的，他刚才在喝水。是的，我想聊的是用例。你认为你的客户今天来找你，主要想用云端 agent 做什么？
是的，我认为我在所有人身上看到的最简单、最常见的用例是 SRE 用例。这个想法是，无论我们的告警是在 Slack、Datadog 还是其他地方，我们都希望 agent 成为第一响应者。这不一定意味着 agent 真的能解决问题，但能够提前收集上下文信息就已经非常了不起了，因为 agent 与生产日志、数据库集成，拥有完全的可见性，并且随着时间的推移还能掌握处理某些问题的 playbook。这对团队来说是一个巨大的胜利，因为你可以立即获得系统内正在发生的事情的完整轨迹。而且，很多时候还能直接从中生成一个 pull request，这是一个相当流畅的体验：错误出现，pull request 完成。OpenInspect 也支持为此触发一个动作。所以这可以完全自主地发生。
专门针对 Datadog，还是说——
它支持 Sentry，支持通用 webhook。如果有人想添加 Datadog，他们也可以。
是的。
我看到的其他用例是针对非开发者的场景，比如产品经理或市场团队。我看到很多团队中，谁在贡献代码的概念正在发生变化。在很多情况下，如果只是一个快速的小 bug 修复，产品经理不再创建 issue 了。产品经理直接通过 Slack 发 prompt，然后 pull request 就被创建了。所以我认为这是一个巨大的胜利。我认为这种趋势会继续下去，我们会看到代码修改发生在工程部门之外。我看到的最后一个常见用例是客户支持。
是的。
当他们遇到客户问题时，他们不完全确定为什么会出现这种行为。以前的情况是，嘿，客户尝试使用这个功能时出现了一个 bug，我们不知道发生了什么。但现在，他们在 Slack 中标记这个问题。同样，完整的上下文已经准备好了。然后他们可以直接标记工程团队，并完全理解这个问题，完全绕过了以前像“哦，你能从他们那里获取更多信息吗？”这样的痛点。
我想在此基础上补充的是，我还看到持续安全扫描、持续安全审查也是一个非常重要的用例。SRE 用例在内部我们称之为自动分类，因为我们希望每一条进来的消息——无论是告警还是 bug 报告——都能让 Devin 在其它任何事之前就开始分类处理。我们已经非常深入地投入这个用例，以至于我们基本上试图让你无需离开 Slack 就能与之交互。所以，再次强调，让与 Devin 的交互从报告进来的那一刻起就非常流畅，它能回复报告，并且你可以在那里直接提问，拥有关于所有问题的完整代码库上下文。这与客户支持也非常相关。我认为我们发现的一点是，CLI 有时对非技术人员来说很难使用。但是，一个在线聊天界面，任何人都可以提问，非常直观，不假设你有任何技术知识，但能访问你代码库的所有部分，这对支持人员、销售人员以及任何可能需要回答关于代码库问题的人来说都非常有用。所以，是的，很好的提法。
这可能是一个非常昂贵的用例。对于人们应该在这方面花多少钱，有没有一个经验法则？因为你有无限的预算，但其他人没有。我不知道这是不是一个可以回答的问题，因为它显然取决于很多因素。
我认为这真的取决于人们如何使用它。我认为如果人们负责任地使用它并从中获得价值，那么，你可以确定预算。我听到的常见数字是每个工程师 1000 美元到 5000 美元。
是的。
作为一个参考，我还没听说过每个工程师 50000 美元这样的数字。
我们会达到的。是的，我确实见过这么高的数字。是的。我认为这也是未来一年的一个大主题：我们会看到非常昂贵、非常智能的前沿模型。同时，我们也会看到有人说，你知道吗，我很多工作不再需要前沿模型了，因为一些前沿模型实际上已经足够好地完成很多工作了。
另外，值得一提的是，你开创了 SmartFriend，这是一种混合方案。
我对这样一个世界很感兴趣：你基本上拥有混合的前沿和次前沿系统，利用次前沿部分实现极快、极高效，同时调用系统前沿部分，从而在大多数情况下仍能获得前沿性能。是的。
我试着搜索，但 Twitter 搜索完全坏了。from 字段直接消失了。这很让人难过，因为我真的很喜欢——
我可能得找个时间发个新帖子，讲讲 Smart Friend 的回归。
是啊。是啊。我是说，Anthropic 现在已经正式采用了它。
没错。
好的，不错。我想就这些了。这真是一次很棒的讨论，很高兴能请到你们。后台 agent 现在已经成为现实，每个人都在构建它们。我们聊了很多关于生产环境的问题，以及为什么你会选择一种架构而不是另一种。是的，有很多值得期待的东西。
是的，我觉得现在这个领域有一种真正的时代精神，公司们都想把自己变成这些自主编码工厂。而我们也在做很多努力来支持这一点。所以欢迎任何听众来和我们聊聊，无论是使用 Devin 还是与我们合作。
是的。在招人吗？
当然。
具体是什么方向？就举一个特别有意思的职位描述吧。
我认为人们目前低估了在这个领域里，拥有极高品位的产品工程师所起的作用。
而考验就是，你端到端地交付过什么有品位的产品？
如果你交付过你认为有品位、并且引以为豪的东西，那你就应该来和我们聊聊。
是的，对我来说，任何希望进一步发展其工程团队的企业——我做的很多咨询都围绕这个。那些可能刚开始 AI 之旅的团队，无论是用 Cursor 还是 Cloud Code，他们需要有人来引导他们穿越前沿技术，而不仅仅是完成最初的部署。正如提到的，从你部署了后台 agent 到如何真正将其完全整合到公司中并实现其真正价值，这中间还有很多工作要做。
是的。
好的。那么，谢谢你们来做客。
酷。
谢谢邀请。
嗯。
谢谢。