来源
- 原始链接：https://www.latent.space/p/cognition
- 来源类型：网页正文与访谈逐字稿
- 来源标题：The Age of Async Agents — Cognition’s Walden Yan & OpenInspect’s Cole Murray
【AI 编程的重心从写代码转向建设软件工厂】
背景：这组摘录给出了全文最重要的演化框架：AI coding 先是补全工具，再是本地 Agent，下一阶段是能在后台独立推进任务的异步 Agent。
第一波 AI 编程工具让开发者更快，但开发流程仍被本地 IDE 限制：人在旁边看模型、接收或拒绝修改、一次交互推进一点。第二波是本地 Agent，可以在多个终端并发工作。现在进入异步 Agent 时代，重点变成通过 Agent 编排来驱动端到端开发。
AI 编程工具的目标不再只是帮人写代码，而是帮开发者建设生产软件的工厂。这个工厂由一组像队友一样协作的 Agent 组成：人给方向，给工具，最后审查它们的工作。
兴趣匹配度高。它直接改变问题框架：未来的关键技能不是让模型更会补全，而是设计任务、环境、工具、权限、记忆和验收回路。
【后台 Agent 的及格线是从规格说明走到可审查 PR】
背景：Cole 把 2025 年底的模型能力变化描述为一个工作流拐点。重点不是某个模型多聪明，而是它让新的交付闭环开始可用。
2025 年 12 月前后，模型能力到了一个新阶段：我们开始从手把手带着模型做事，转向让模型更自主地推进。只要规格说明足够好，系统就能以很小摩擦从需求走到完成的 Pull Request。这个范式本身改变了我们和 Agent 互动的方式，也让后台 Agent 变得实际。
随着模型变聪明，Cognition 发现 Devin 中一些原本必要的组件可以被移除。越来越多团队开始认真讨论：是否还需要人在 IDE 里盯着模型，还是可以把任务交到云端执行。
兴趣匹配度高。这里的判断标准很清楚：可用的 coding agent 不是能生成代码片段，而是能把明确规格推进到可审查、可测试、可合并的工程产物。
【关键架构分叉：把大脑和机器分开】
背景：后台 Agent 的第一性问题是它在哪里运行、拿到什么权限、如何处理状态。访谈里把这件事压缩成 harness in the box 和 out of the box 的取舍。
后台 Agent 系统首先要决定 Agent 实际在哪里运行。把 Agent 放在沙盒里更简单，状态集中，但安全代价更高，因为密钥往往也要进入沙盒。把 Agent 放在沙盒外，则让大脑运行在控制平面，沙盒只作为手来执行工具调用。这种架构更复杂，但安全边界更清晰。
Devin 从一开始就选择把大脑和机器分开。机器上只放用户允许 Agent 使用的最小权限密钥；大脑不从机器侧暴露出来。这样即使用户或 Agent 能在机器里自由操作，也不必把最敏感的控制部分暴露出去。
兴趣匹配度高。它把 Agent 安全从抽象原则落到架构边界：控制平面、执行环境、密钥范围、状态管理必须分开设计。
【真正难的不是调用工具，而是让仓库环境对 Agent 可运行】
背景：很多人低估 repo setup。模型能读代码是一回事，能在真实环境里启动、测试、验证变更是另一回事。
让 Agent 真正工作，难点不是只给它代码，而是让它的工作环境持续保持可运行：依赖、凭证、服务、应用启动和测试都要对齐。很多团队的开发环境靠口口相传，比如找某个人拿密钥，这对 Agent 完全不可扩展。
Docker 适合跑基础设施，但未必适合承载完整 Agent 执行环境。真实应用本身可能就依赖 Docker，再套一层会很别扭。完整虚拟机能支持更真实的应用运行、点击交互、录屏验证，甚至支持 Android、macOS、Windows 这类平台相关开发。
兴趣匹配度高。这条对企业落地尤其关键：Agent 的上限经常受制于工程卫生，而不是模型能力。可复现开发环境、最小权限密钥、快照恢复、真实 VM 都是生产级 Agent infra 的一部分。
【测试不是 computer use，而是代码库上下文驱动的验证编排】
背景：访谈里一个很有价值的反常识点是：测试的难点不在于 AI 会不会点按钮，而在于它能否理解并编排一个复杂系统。
人们谈 AI 测试应用时，容易过度关注 computer use：模型能不能识别按钮、发出正确坐标。但真正困难的是测试本身。一个变更可能横跨前端、后端和深层服务；系统必须知道如何用正确版本启动这些服务，如何触发特定功能，是否需要管理员权限、特性开关，甚至是否需要两个会话互相配合。
这些测试需要大量代码库上下文和编排能力。有些情况下，没有任何一个前沿模型能独立完成端到端测试，系统需要编排多个前沿模型一起解决。
兴趣匹配度高。它把验证从 UI 自动化拉回工程系统：可靠交付靠的是运行环境、触发路径、测试证据和验收标准，而不是单纯让模型操作屏幕。
【MCP 只是连接层，一等集成才决定 Agent 能不能进入公司】
背景：这组摘录讨论企业落地。工具协议能让 Agent 连接系统，但关键工作流经常需要自己做产品级集成。
后台 Agent 接入公司系统后才会产生跃迁：只读生产数据库、日志、内部知识库、Slack、GitHub 等都很重要。但接上工具只是开始，访问控制、合规和协作体验会变成新的问题。
给 Agent 一个 Slack MCP，让它能发消息，并不等于把它变成 Slack 里的同事。真正好用的 Slack 集成需要 webhook 回流、自然回复、避免刷屏、适配团队协作习惯。越是关键路径，越值得自己掌控和优化，而不是完全依赖现成通用接口。
兴趣匹配度高。它非常贴近 Hermes/MCP 的产品判断：协议解决可连接性，一等体验解决可用性。Agent 系统最终会在高频协作入口上重新做产品设计。
【记忆系统的难点是生成、检索、更新和遗忘，不是多存一点文本】
背景：Cognition 和 OpenInspect 都把 memory 视为未解决问题。这里的价值在于它把记忆拆成了可评估的工程问题。
记忆难在两件事：怎么生成，以及怎么检索。系统不能因为用户某一次要求开 draft PR，就永远记成所有 PR 都要是 draft；但它可以逐渐学到某个用户通常喜欢怎样处理 PR。拥有成千上万条记忆之后，系统还要在正确时间取出正确内容，同时避免把上下文塞满无用信息。
Devin 的一个方向是让记忆更像文件系统，让 Agent 可以自己导航。另一个方向是常驻 Agent：它维护自己的 memory.md，像某个产品或 issue 集合的永久 PM，记录优先级、负责人、后续动作，并在需要时主动提醒或创建任务。
兴趣匹配度高。它和你最近的多仓库 Agent、dmux、文件式通信、长期上下文管理是同一条线：长期可用的 Agent 需要可编辑、可检索、可遗忘的工作记忆，而不是简单的聊天历史堆积。
【多 Agent 的实用形态不是群聊，而是经理拆任务、子 Agent 隔离执行】
背景：这组摘录修正了对 multi-agent 的想象。真正可用的多 Agent 更像任务分解和隔离执行，而不是一群 Agent 在频道里互相聊天。
很多人期待 swarm 式的 Agent 世界：多个 Agent 到处互相发消息、互相协作。但实际日常最有用的形态仍然是一个上层 Agent 拆分工作，让其他 Agent 在相对隔离的环境里执行。每个子 Agent 有自己的机器，不共享环境，减少冲突。
子 Agent 也可以作为上下文管理工具：让它去找某个文件或实现，消耗掉的工具调用和 token 最后折叠成一个答案返回主 Agent。它看起来更像一个工具调用，而不是两个协作者持续对话。
兴趣匹配度高。它对你现在的 multi-repo / multi-pane agent workflow 很有参考价值：并行有价值，但边界、隔离、汇总和责任链比 Agent 数量更重要。
【失控的 vibe coding 会把代码库拉回最差工程师的模式】
背景：访谈后段最值得保留的警告是：只让 AI 狂写，短期看很快，长期会污染代码库的模式库。
如果连续两周让 AI 自由写代码，你可能会发现改一个按钮颜色时，它其实散落在十几个实现里，每处还有不同变体。这时必须重新引入代码审查和清理，确保软件以可扩展方式演进。
代码库会退化到最差工程师的模式。那个最激进使用 AI、又不审代码的人，会把自己的坏模式固化进代码库；之后 AI 会继续参考这些模式，把重复、臃肿和混乱放大。解决办法是定期清理重复、收敛抽象，并对模块边界保持严格。
兴趣匹配度高。这是 AI coding 管理的硬问题：代码库本身会变成模型的上下文和训练场，组织必须治理上下文质量，否则 AI 会放大最差实践。
【AI code smell 要制度化为 lint、Semgrep 和 review 规则】
背景：这组摘录非常实操。它没有泛泛说 AI 写代码质量差，而是描述了可检测的坏模式。
AI 为了避免失败，会写出过度防御的代码。明明知道对象有某个属性，它也会到处用 getattr，因为这样更不容易报错。很多团队已经把这种模式写成 lint 规则：只要 PR 里出现这类 getattr，就直接失败。
另一类常见坏味道是为了兼容一切而制造奇怪的导入导出、保留旧模块名、到处塞 any、dict string any、无类型元组。这些都可以通过 Semgrep 或其他静态规则识别。真正的经验来自反复观察 AI 代码模式，然后把坏味道固化成自动化防线。
兴趣匹配度高。这是可以直接迁移到团队实践的判断：AI 代码治理应该沉淀为规则、检查器和审查模板，而不是靠每次人工凭感觉指出问题。
【Agent-ready codebase 的目标是让 Agent 能本地跑完、测完、报告完】
背景：这组摘录把企业迁移方向讲得很具体。老代码库要迎接 Agent，不是买工具就够了，而是要改造本地开发和测试路径。
团队越多使用 AI Agent，越需要让 Agent 能做完整任务：不只是写代码，还要运行和测试。很多代码库一开始并不是为这件事设计的，因此需要本地数据库、本地 Docker Compose、本地 Postgres，避免为了运行测试而给 Agent 生产凭证。
Cognition 内部也在把核心组件迁移成纯本地开发即可测试，不需要接入真实线上服务。公司越老、服务越多、微服务越复杂，这种迁移越难，但现在可以用 AI 帮助做这类迁移。
兴趣匹配度高。它给出了组织层面的行动项：把代码库改造成 Agent 可操作资产。长期看，谁的代码库更 agent-ready，谁的 AI 编程收益上限更高。
【本地与云端 Agent 会分工：本地做快决策，后台跑到完整报告】
背景：Windsurf 2.0 这一段讨论的是未来 IDE 形态：本地窗口成为所有 Agent 的控制台。
理想工作流是：本地窗口成为本地 Agent 和后台 Agent 的统一控制台。需要人工审查时，把云端任务拉回本地；其他任务继续在后台跑。你不需要离开这个窗口，就可以审批问题、启动后台 Agent、接收测试结果。
本地 Agent 和云端 Agent 的理想行为不同。本地 Agent 应该更快，把决策权留给用户；后台 Agent 则应该持续运行，直到它完成测试并给出完整报告，再发下一条消息。
兴趣匹配度高。这条适合判断下一代 AI IDE：不是本地或云端二选一，而是 foreground 与 background 的接力系统。产品价值在于任务状态、上下文交接和验收证据。
【自主编码工厂的稀缺能力仍然是高品味端到端交付】
背景：全文结尾把技术趋势落回人。即使公司想变成 autonomous coding factory，人的能力并没有消失，而是换了位置。
很多公司现在都想把自己变成自主编码工厂。这个阶段反而容易低估高品味产品工程师的作用。真正值得找的人，是那些端到端交付过自己认可的、有品味产品的人。
后台 Agent 的价值也会扩展到工程之外：SRE 告警先由 Agent 收集日志、数据库和处置路径；PM 可以通过 Slack 触发小修复并生成 PR；客服能把客户问题转成完整工程上下文，减少来回追问。
兴趣匹配度高。它对应一个更大的组织判断：编码自动化会降低代码生成的稀缺性，但端到端产品判断、任务定义、质量标准和组织集成能力会更稀缺。
整体评价：兴趣匹配度很高。这篇最有价值的地方不是 Cognition 又融资了多少，而是它把后台编码 Agent 的真实生产问题讲完整了：架构边界、执行环境、测试验证、企业集成、记忆、多 Agent 编排、代码质量治理、agent-ready codebase、本地与云端接力。对你正在关注的 AI coding、上下文工程、多 Agent 协作和团队落地都有直接参考价值。