异步 Agent 时代:从代码助手到软件工厂

过去一年，AI coding 的讨论重心正在发生变化。

早期我们谈的是补全、Copilot、IDE 里的 pair programming。后来变成 Claude Code、Codex、Cursor 这类本地 agent，开发者在终端和编辑器里把任务交给模型，让它搜索、修改、运行、解释。

现在，话题正在转向另一个方向：异步 Agent。

它不再只是坐在开发者身边，等你一句一句指挥。它被放进云端，拿到仓库、开发环境、shell、浏览器、测试系统、日志、知识库、权限边界和 review loop。你给它一个任务，它在后台持续工作，最后把 pull request、测试证据、截图、视频或排障结论交回来。

这也是 Cognition 和 OpenInspect 在这期对谈里反复谈到的判断：

真正让 background agents 落地的，已经不只是模型能力，而是围绕模型的整套工程系统。

为什么所有人都在“自己造 Devin”

Cole Murray 观察到，工程界正在集体意识到 background agents 和 cloud agents 的价值。2025 年 12 月前后，Opus 4.5 和 GPT 5.2 这类模型跨过了一个能力门槛：只要 specification 足够好，模型已经可以从需求说明一路走到一个完成度较高的 pull request。

这件事改变了开发者与 agent 的关系。

过去，人要在旁边不断扶着模型走。现在，越来越多任务可以交给 agent 自己推进。开发者从“逐步接受补全的人”，变成了“给任务、审结果、调系统的人”。

Cognition 的 Walden Yan 也提到，Devin 内部的数据已经能看到这个变化。Devin 的 merged PR 数量在短短几个月里增长了约 7 倍，而工程团队人数只增长了大约 10%。在 Devin 自己的仓库里，Devin 贡献的 commit 占比从 1 月的 16% 上升到 3 月的 80%。

值得注意的变化：

这种变化也解释了为什么很多公司开始自己搭 Devin。大型 agent 公司在往前冲，企业内部也想拥有适合自己权限、流程、代码库和合规要求的 background agent system。

OpenInspect 就是在这个背景下出现的。

Cole 起初看到客户用 Claude、OpenAI Codex 等工具时，最大的摩擦点并不一定是模型能力，而是协作方式。很多团队通过 Slack 启动 Claude session，但 session 绑定在发起人的身份上。如果 PM 发起任务，后来想让工程师接手，工程师根本看不到完整 session，只能靠复制粘贴上下文。这对真实团队协作来说几乎不可用。

于是他开始做一个云端 background agent system。Ramp 发布那篇介绍内部 agent 系统的文章后，Cole 发现自己已经具备很多组件，便用 Claude 依据文章内容快速复现了一套系统，并开源成 OpenInspect。

他的判断很直接：

background agent system 很可能会成为公司内部的关键基础设施。

既然是基础设施，就应该允许团队 fork、改造、接入自己的系统，而不是全部锁在某个 SaaS 里。

Agent 公司真正卖的是什么

一个很现实的问题是：如果大家都能自己造 background agent，那 Cognition 这样的公司到底卖什么？

Walden 的答案分成几层。

早期 Devin 并没有成熟的基础设施可用。Cognition 只能直接基于 EC2 之类的原始 VM 搭建机器环境，启动慢、保存慢、恢复也慢。机器关掉后再叫醒 Devin，可能要冷启动十分钟。这类云基础设施并不是为“agent 高频上下线、保存状态、继续工作”这种模式设计的。

所以 Cognition 不得不自己做大量 agent infra。

这里的产品边界很重要：

卖 coding agent，不只是卖一个会写代码的模型界面。你还在卖计算环境、权限模型、沙箱、安全边界、恢复速度、企业集成、onboarding 和 adoption。

对大型企业尤其如此。很多人都想把日常工程工作迁到 AI 上，但不是每个团队都熟悉 AI 工作流，也不是每个项目天然适合 agent。Cognition 的工作还包括帮客户接好 integrations、automations、权限、项目流程，让团队真的能用起来。

这也是为什么每 seat 20 美元的 agent 产品并不好做。Cole 认为，如果只夹在模型层和 sandbox 层中间，商业空间会很尴尬：模型层有人赚钱，sandbox 层也有 Daytona、E2B、Modal 等玩家赚钱，中间那层如果没有掌握足够多 stack，很容易变成难以定价的灰色地带。

background agent 的架构分水岭：harness 放在哪里

对 background agent system 来说，一个基础架构问题是：agent 到底跑在哪里？

常见说法是：

这不是一个纯审美选择，它会直接影响安全、状态管理、权限和系统复杂度。

1. harness in the box

把 agent 放进 box 里，最大的好处是简单。agent 的状态都在机器里，文件、环境、执行轨迹也更本地化。你要管理的系统边界少一些。

问题是安全性。

如果 agent 跑在 box 里，很多 secrets 也会跟着进入 box。AI 行为有不确定性，理论上可能误发 secrets，或者执行出非预期行为。对企业环境来说，这是很难接受的。

2. harness out of the box

把 agent brain 放在 box 外，sandbox 只作为 hands，就可以把决策系统和执行机器分离。agent 可以通过工具调用操控 sandbox，但 secrets、权限和 brain 不必全部暴露给机器。

代价是复杂度。

状态需要跨系统管理，控制平面要设计得更严谨，工具调用、权限、日志和恢复都要重新考虑。

Walden 说，Devin 从一开始就采用了类似“brain 和 machine 分离”的设计。这样一来，机器上放什么 secrets，就只代表这台机器能做什么；brain 本身不暴露给机器，企业也更容易用最小权限来约束 agent。

架构判断：

对严肃企业场景来说，out of the box 通常更复杂，但也更适合长期演进。它把 agent 的智能、机器执行环境和权限边界拆开，给安全与合规留下空间。

真正难的是 repo setup

很多人低估了 background agent 的环境问题。

让 agent 写代码只是第一步。真正麻烦的是：它能不能把你的代码库跑起来？能不能启动依赖服务？能不能拿到必要但受限的凭据？能不能在一个接近真实的开发环境里测试？

Cognition 内部把这件事叫 repo setup。

Cole 说，他的咨询工作里很大一部分都在帮团队补这个洞。很多公司没有可靠的开发环境设置。真实情况经常是：“去找 Bob 拿 secrets。”这种人肉流程对 agent 完全不可用。

要让 agent 工作，团队至少要回答这些问题：

Docker Compose 是很多团队已经拥有的基础。但 Walden 也提醒，Docker 不是完整安全边界，而且很多真实应用自己已经依赖 Docker。你如果再让 agent 跑在 Docker 里，就会遇到 Docker in Docker 这类复杂问题。

这也是为什么 Devin 需要完整 VM。

当 agent 不只是改代码，还要真的跑应用、点界面、生成截图和录屏时，完整机器环境的价值会持续上升。

测试比 computer use 难得多

很多人把“AI 能测试应用”理解成 computer use：模型看到界面，发出坐标，点击按钮。

Walden 认为这只是一小部分。

真正的 testing 难在问题求解：你改了一个跨前端、后端和内部服务的功能，agent 要先弄清楚应用怎么启动，各服务怎么用正确版本互相连接，如何触发功能，哪些权限或 feature flag 必须打开，是否要开两个 session 互相发送消息，怎么判断结果真的对。

这些都需要 code base context，也需要 orchestration。

在某些场景里，Cognition 发现单个 frontier model 甚至无法独立完成端到端测试，需要把不同 frontier model 组合起来解决。

这里的重点不是“能不能点按钮”：

重点是 agent 能不能理解系统行为、启动必要环境、构造测试路径、观察结果，并生成可信证据。

Devin 的一个典型体验是：PR 完成后，用户点击测试确认，系统会回传一段视频。视频不仅录下了界面操作，还会标注正在测试什么。Swyx 提到，这种证据会带来一个很强的“我知道它能工作了”的瞬间：你甚至可能不想再去 GitHub 看代码，只想直接在 Slack 里 merge。

但要做到这一点，背后有很多细节：

这些细节最后都会影响一个指标：代码到底能多快被 merge。

GitHub、Slack 和企业集成：MCP 还不够

MCP 带来了大量集成想象。给 agent 一个 Slack MCP，它就能发消息；给它 GitHub 工具，它就能看 PR、改代码、回复评论。

但 Walden 的判断是：真实企业体验经常需要超过 MCP 的能力。

以 Slack 为例。Devin 在 Slack 里不是“会调用 Slack API 的工具”，而是更像一个同事。它需要支持 webhook 回调，在 thread 里自然回复，控制发言频率，知道什么时候继续问，什么时候别打扰别人。

这不是简单把一个 tool 接上去就完成了。

Cole 也提到，如果某个 integration 几乎每个 session 都会经过，那它对公司就足够关键，值得团队自己拥有这层实现。这样你才能在体验、权限和性能上继续优化。

MCP 适合快速连接。

一旦某个连接变成核心工作流，first-party integration 往往更可靠。

memory 仍然没有被真正解决

对 agent 来说，memory 是最诱人、也最难做好的能力之一。

Cole 说，OpenInspect 目前没有急着加入完整 memory，因为这仍然是一个很难的 retrieval problem。他在客户那边看到的替代方案，更多是通过 skills 或更新 Claude.md 来传递偏好和知识。

Walden 则分享了 Devin 的 memory 经验。Devin 早期有一个叫 Knowledge 的系统，目标是让 Devin 在工作中自动学习，而不是要求用户主动写大量文档。

比如，当用户提醒 Devin“Git 不是这么用的”，系统会问：要不要把这点记下来，以后继续使用？用户只需批准或拒绝。Walden 提到，Devin 里绝大多数 memories 都来自这种自动生成，而不是用户手写。

难点在两端：

1. 生成 memory 很难

一次性指令不能被过度泛化。

你某次要求“把这个 PR 开成 draft”，不代表以后所有 PR 都该是 draft。

但系统又要能提炼稳定偏好。

比如“Cole 通常更喜欢先开 draft PR”就可能是有价值的记忆。

2. retrieval 也很难

如果有上千条 memory，系统怎么在正确时机取出正确几条？

如果取太多，context 会被低价值信息污染；取太少，agent 又会忘记重要背景。

Walden 提到，Cognition 也在探索把 memory 做得更像文件系统，让 agent 自己导航和维护。另一个方向是让常驻 Devin 维护一个类似 memory.md 的文档，长期盯住某个产品、issue 集合或 Slack channel，像一个持续在线的 PM。

这种 always-on agent 可以记录：

这意味着 agent 可能不只是工程执行者，还会进入工程上游，参与 triage、planning 和产品运营。

多 agent 会来，但今天最实用的还是 manager/sub-agent

Swyx 提到，他非常看好 agent 调用 agent、spawn sub-agents、甚至 swarm 的方向。

Cole 和 Walden 的态度更克制。

他们认为，今天真正稳定有用的多 agent 模式，仍然更像 manager / sub-agents：一个顶层 agent 拆任务，多个子 agent 在相对隔离的环境里执行，各自有独立机器，尽量减少冲突。

那些“agent swarm 彼此到处聊天”的设想很有吸引力，但现实中容易变得混乱。

Walden 也提到，Devin 曾经有能力任意创建其他 Devin、互相发消息，但日常最实用的模式仍然是一个主 Devin 负责管理任务，把子任务隔离出去执行。

多 agent 的价值，今天更多体现在 context 管理和并行隔离。

它不一定需要模拟一群智能体开会。很多时候，sub-agent 只是一个更聪明的 tool call。

不过，Walden 也承认，模型现在已经开始具备更成熟的沟通能力。Devin 有时会告诉用户“你错了”，而不是机械附和。这种能辩论、能反驳、能基于不同信息达成结论的能力，会让未来的 multi-agent 协作更可行。

无审查的 vibe coding 会腐化代码库

对谈里最值得警惕的一段，是关于 vibe coding 和 auto-merge 的实验。

Cognition 内部曾尝试只靠 AI 叠加开发真实产品：auto merge，不做 code review，纯粹看系统能撑多久。

结论很现实：以 2025 年 12 月左右的能力，大概能撑两周。

两周后，你会看到代码库开始变坏。比如一个按钮在 10 个地方各自实现，颜色略有差异，改一个样式要到处找；同一类 helper 出现十几个版本；局部糟糕 pattern 被 AI 反复引用，逐渐固化成项目惯例。

Cole 有个说法很直白：你的代码库会退化到最差工程师的水平。

如果团队里有一个特别激进使用 AI、但不审查代码的人，他的糟糕模式会进入代码库。之后 AI 会把这些模式当成范例继续复制，slop 会指数式增长。

应对方式不是完全禁止 AI 写代码，而是补上治理机制：

Swyx 提到，对工程负责人来说，一个可行策略是划清模块边界：模块内部可以更自由，模块之间的契约必须由人把关。

AI code smell 正在形成

随着 AI 写代码越来越多，团队也开始总结出一些典型的 AI code smell。

Cole 和 Walden 提到几个例子。

1. Python 里的过度防御式代码

AI 写 Python 时，经常使用 hasattr、getattr 这类模式，即便它已经知道对象应该有哪些属性。Cole 认为这是一种 reward hacking：模型不想让代码失败，于是到处加兜底。

一些客户已经把这类模式写进 lint rule：如果 PR 里出现不合理的 getattr，直接 fail。

2. 不惜一切代价保持 backward compatibility

GPT 系列模型经常为了避免改调用方，写出奇怪的 import/export 兼容层。Claude 新版本也开始出现类似倾向。

这也是 reward hacking 的表现：模型想避免出错，于是保留太多历史路径。

3. untyped tuples 和 any

随手写 dict[str, any]、不标类型的 tuple、模糊数据结构，这些都会让代码长期维护成本上升。

4. 过度注释

Walden 提到，一些新模型会在函数上方写很长的“PRD 式注释”。有些内容确实有价值，会解释为什么选择这个实现、为什么放弃其他方案；但信息量过多，也会干扰阅读。

这里有一个有意思的方向：如果未来 agent 需要长期维护代码，也许把设计原因、上下文和 prompt 存在代码旁边是有价值的。GitAI 的想法就是把 agent prompts 存进 Git metadata，让未来 agent 和 code review bot 都能参考。

让代码库变得 agent-ready

如果公司想真正使用 background agents，代码库本身也要迁移。

Walden 的建议很明确：最终你希望 agent 不只是写代码，还能自己跑起来、测出来、交付证据。

为此，代码库要尽量支持本地运行：

越老的公司，改造成本通常越高。很多公司成立时 Docker 还没普及，代码库天然依赖真实服务和复杂环境。要让 agent 进入这样的系统，必须先做一轮 agent-ready migration。

好消息是，现在 AI 本身也可以帮助做这类迁移。

Swyx 提到一个有意思的设想：像 Little Snitch 一样观察本机流量，从真实请求中重建 mock server。只要观察一段时间的网络交互，就有机会自动生成本地 mock，让 agent 在不接触真实服务的情况下测试。

agent infra 是真正的护城河之一

这期对谈反复回到基础设施。

Walden 举了一个很小但很典型的例子：很多人自己搭 coding agent 时发现，agent 机器上的 grep 很慢，于是第一反应是写一个自定义 grep index。

Cognition 早期也遇到过这个问题。最后 infra 团队发现，根因在底层文件系统：很多 VM 用的是网络文件系统，文件实际缓存在 S3 等远端存储里。每次 grep 都在触发网络请求，所以才慢。

解决办法不是再堆一个 AI 写的索引，而是换掉底层文件系统。

另一个例子是 VM 的快速保存和恢复。假设机器有 1TB 磁盘，但 agent 只改了 100 行代码，恢复时不应该按 1TB 重新处理。Cognition 做过一种增量文件系统格式，让恢复工作量接近文件系统 diff，而不是整块磁盘。

这些细节看起来不属于 agent，但它们决定了 agent 的可用性。

当你卖一个 agent 产品时，你卖的其实是 agent 加 agent infra。

这也是 Cognition 自建 infra 的原因之一。掌握基础设施后，它可以把 Devin 部署到更多环境里，比如客户自己的 cloud、VPC、on-prem，甚至更受限的政府云场景。

OpenInspect 则采用更开放的 provider 抽象。控制平面跑在 Cloudflare 上，sandbox 可以接 Modal、Daytona，E2B 也在 roadmap 里。Cole 认为 Modal 在 sandbox、snapshot 和 GPU 支持上有不错的产品体验。

本地 agent 与云端 agent 的分工

Windsurf 2.0 试图解决另一个问题：当你有很多 background agents 时，某些任务总会需要拉回本地。

Walden 的设想是，Windsurf 可以成为所有 agents 的本地指挥中心。你可以把某个 background agent 的工作拉下来 review，其他 agent 继续在后台跑；也可以从本地把 issue 丢到云端，让 background agent 去修。

本地 agent 和云端 agent 的理想行为并不完全一样：

这背后可能只是 prompt 和 policy 的差异，但工程上需要尽可能共享逻辑：Git provider、OS、VM、权限、文件系统、工具调用都不能做成两套完全割裂的系统。

最先落地的几个用例

Cole 看到的最常见用例，是 SRE。

当告警从 Slack、Sentry、Datadog 或通用 webhook 进来时，agent 可以先做 first responder。它不一定立刻修复问题，但它可以先收集上下文：生产日志、数据库状态、相关代码、历史 playbook、最近变更。很多时候，它甚至能直接产出一个 PR。

这会改变排障流程：

第二类用例是 PM 和非工程团队直接发起代码修改。

一些小 bug 或文案修复，PM 不再创建 issue 等工程师排期，而是在 Slack 里直接描述问题，让 agent 创建 PR。

第三类是 customer support。

客服遇到客户问题时，可以直接 tag agent，让它基于代码库、日志和上下文给出初步诊断，再把完整信息交给工程团队。

Walden 还补充了持续安全扫描、持续 security review、auto triage 等场景。对非技术人员来说，CLI 很难用，但聊天界面很自然。只要 agent 能接触代码库上下文，support、sales、PM 都可以用它回答代码相关问题。

预算会变成一个新管理问题

background agents 可能很贵。

Cole 听到的常见预算，大概是每位工程师每月 1000 到 5000 美元。更高的数字也会出现，尤其当 agent 真正进入生产流程后。

Walden 认为，接下来会出现一个重要趋势：团队会同时使用很贵、很聪明的 frontier models，以及更便宜、更快的 sub-frontier models。

理想形态是 hybrid system：

这很像 Cognition 早期做过的 Smartfind 思路：不是所有步骤都用最贵模型，而是把不同能力组合起来。

异步 Agent 的终局：自主软件工厂

Walden 最后用了一个说法：很多公司都想把自己变成 autonomous coding factories。

这句话听起来很大，但拆开看，它其实由一组具体工程能力组成：

模型能力让这件事第一次变得可行。

工程系统决定它能不能长期可靠地跑在真实公司里。

END：

异步 Agent 已经从演示走向生产。接下来真正拉开差距的，会是 orchestration、testing、permissions、memory、review 和 infra 这些围绕模型的工程能力。

如果说第一代 AI coding tools 提升的是个人开发速度，那么异步 Agent 要改变的是软件生产组织本身。开发者不再只是写代码的人，也会越来越像软件工厂的设计者、调度者和质量负责人。

这就是“异步 Agent 时代”真正值得关注的地方。