AI Engineer Code Summit 2026 @aiDotEngineer 连续两天会议，合计超过 18 小时、31 场主题演讲。OpenAI、Anthropic、Google DeepMind、TypeSafe、Cloudflare、Cognition、Lovable、Ramp、Amp 等团队都带来了干货分享。咱们展开看看都讲了什么、对咱们有哪些启发？！ https://x.com/i/article/2121220783456542720

AIE CODE 两天18小时31场演讲解读：Cloudflare 决策模型、Anthropic 千 Agent 协作与 Cognition 软件工厂

AI Engineer Code Summit 2026 连续两天会议，合计超过 18 小时、31 场主题演讲。OpenAI、Anthropic、Google DeepMind、TypeSafe、Cloudflare、Cognition、Lovable、Ramp、Amp 等团队都带来了干货分享。

第一天：https://www.youtube.com/live/ZZ19zhYnDKY?si=tQWR90fBm2Ay10zR

第二天：https://www.youtube.com/live/y9JtCCZP2MQ?si=OAk5FXekx5AQBtSy

更多 Code Summit 主题视频可以关注：

把两天的演讲放在一起，能看到两种变化同时发生：人正在把软件开发交给可以持续工作的 Agent，也在把智能判断直接放进软件，让它不必事事等待用户提问。

这两件事看似都叫“自动化”，需要解决的问题却不同。前者要让生成的改动经得起验证，后者要让软件在真实世界里作出可靠决定。速度、状态、权限、判断和责任，因而成了比“模型会不会写代码”更重要的问题。

System One 的意义，是让软件直接使用判断

首日的 System One 主题，不能简化成“小模型比大模型便宜”。TypeSafe 的 Diogo Almeida 提出的挑战更尖锐：为什么 AI 能完成复杂研究，却仍难以可靠地承担许多日常自动化？

他的解释是，现有模型大量围绕“帮助人、让人满意”优化，而自动化需要的是能够被程序直接使用、对结果负责的判断。这是他的产品与训练路线判断，不等于已经证明人类反馈强化学习是一切可靠性问题的根源。

Jev 给出的答案，是把输出限定为选择、评分或是非判断，并返回概率，而不是生成一段听起来合理的解释。程序事先定义可选答案，再决定不同概率意味着执行、复核还是交给更强的模型。

这种接口改变了智能进入软件的位置。它可以出现在路由、排序、证据检查等细小步骤里，不必每次都启动一个会思考、会调用工具的完整 Agent。类型正确也不等于事实正确。TypeSafe 文档明确说明，概率校准针对一组预测，不能保证单次答案必然正确。

Cloudflare 的 Michelle Chen 展示了这种分工。Clef 负责有明确选项的决策，Clairic 从非结构化输入中提取有类型的值，再由大模型处理需要开放推理和生成的部分。在 CI 故障示例里，先筛选工具、提取 PR 编号和日志错误，再把真正需要处理的问题交给大模型，而不是反复传入几十个工具和整段日志。Clairic 当时仍是预览能力。

Glean 的 Chinmay Goyal 给出的判断标准很实用：答案能否事先列出来？如果能，考虑决策模型；如果要生成自由文本，就仍需要生成模型。他们把 Jev 用在专家路由、后续问题排序和引用支持性检查中，再通过离线评测、内部试用和客户实验逐步放行。

UiPath 则展示了另一种组合。先让大模型提出邮件分类，再用廉价判断处理大量邮件，根据各分类的分布反过来修订类别。类别稳定后，日常流程可以不再依赖大模型。其重排序实验还把候选文档分组比赛、逐轮晋级，说明更便宜的判断允许尝试过去不划算的计算方式。

Workday 的 Scott Roberts 把它推进交互层：用户还在输入，系统就判断意图，选出请假、工资等任务卡片，逐步补齐信息。这里是选择和填写已有界面，不是每个按键都重新生成一套网页。他也明确声明，这些演示使用合成数据，当时不在生产环境。

这一整组案例给第二日的软件工厂加了一条约束：不是所有步骤都值得交给最强的通用 Agent。先分清需要判断、需要执行，还是需要开放探索，往往比增加推理更有效。

模型周围的规则在减少，模型之外的系统在扩张

Google DeepMind 的 Philipp Schmid 说自己删掉了大量运行框架代码。他比较过多工具框架，以及主要使用 Bash、额外提供图片查看能力的简单框架。后者让强模型自行写脚本，把多个操作合并在一次调用里。

在他的约 350 项自有任务评测中，不同框架的完成分数接近，简单框架却更省 token 和费用。他也说明每项只跑过一次，分数差异可能有噪声。这不能证明“Bash 永远最好”，但提醒人们，旧模型需要的细粒度工具与提示词，可能正在妨碍新模型。

第二日 Armin Ronacher 对 Pi 的观察与此相互印证：工具核心没有剧烈改变，模型变强已经带来很大收益。Factory 的 Luke Alvoeiro 和 Warp 的 Zach Lloyd 则进一步介绍了用程序编排工具、只返回相关结果，以及对运行流程做真实任务重放和评估。

一段技能评估分享补充了反面：模型懂某个概念，未必知道具体字段和参数。删掉重复知识之后，仍要比较有无技能时的任务表现，不能只看上下文缩短了多少。

另一边，Lydia Hallie 的补录解释了为什么删提示词不等于删控制。模型能从代码读懂的信息，不必重复塞进 CLAUDE.md；可一旦涉及不能承受的错误，就不能仅依赖它理解意图。

她区分了自动审批分类器、明确拒绝规则、操作系统沙箱和云会话。批准一次测试命令，不代表批准它的依赖脚本读取密钥；限制这类副作用，需要执行环境真正拦住访问。云机器可以丢弃，但它已经推出去的提交、已经发出的消息，不能因为机器被销毁就当作没有发生。

所以两天看似矛盾的主张，其实发生在不同层次。可以减少替模型逐步思考的安排，同时加强由执行环境实施的权限、隔离与验证。真正该删的是过时的指导，不是安全边界。

想让 Agent 放手试，先给它一份可复制的现实

Databricks 的 Ankit Mathur 把基础设施问题讲得很具体。Agent 要修复一条数据管道，不能只读日志、给出一个理论，也不能随便在生产数据上反复运行。写入未必幂等，读取也可能昂贵。

他们尝试把表、计算和治理一起分支，给不同 Agent 独立探索不同假设。以 Neon 为基础，数据库、对话、记忆、文件系统和沙箱都需要能保留起点、隔离后续修改。否则一个分支写下的临时结论，就可能污染其他分支。

Lovable CTO Fabian Hedin 展示了类似思路在产品中的实现。Agent 历史是追加事件日志，实际送给模型的提示词由历史重新构建。历史可以分叉，摘要可以随模型调整，执行进程则可以被替换，不必让一项长任务绑死在某个进程上。

计算机本身也有检查点，保存磁盘、内存与运行进程，用写时复制降低并行探索的成本。需要注意，Fabian 明确说他们并不能像 Git 合并代码那样直接合并两条 Agent 历史；分叉之后仍要通过通信处理结果。

Cognition 第二日的分享把同一个问题落到了开发环境。他们用 Docker Compose 和第三方服务的模拟版本，让服务可以在单台虚拟机中运行，并按小时重建环境。这样，Devin 才能从客户问题走到复现、修复和返回验证视频，而不只是提交一份看起来正确的补丁。

Duolingo 的插播分享提供了一个更朴素的反例：在没有 Xcode 的 Linux 环境里生成 iOS 测试，Agent 要等 CI 才知道编译与检查失败。迁移到 Mac 运行环境后，才可以在打开 PR 前自行构建和检查。

这些工作看起来不像模型突破，却决定了 Agent 能否从“提出建议”变成“亲自验证”。模型需要的不只是更多上下文，还需要一个能安全试错、看到真实反馈的地方。

验证要检查事实，不能只检查另一个模型的说法

Lauren Tan 在首日的工程分享中，把优先级排得很清楚：先改善代码与架构，再使用类型、静态检查和测试，然后是运行与形式化验证，最后才是文字规则和技能。

她的例子并不玄妙。在产品代码里限制容易误用的 React 用法，用目录和依赖检查阻止 Electron 主进程代码进入渲染进程，把反复纠正 Agent 的经验写成可执行检查。否则，仓库里的临时补丁会被下一批 Agent 当成既有规范继续复制。她还介绍了用 TLA+ 检查跨设备通知流程、用 Lean 检查特定算法的尝试，并强调形式化验证不是万能保证。

她自报团队上月交付约 1.1 万个 PR、PR 回退比例约 0.5%。这些数字不是代码质量的完整证明。更值得学的是，把纠错变成下一次无法轻易重复的约束，并审查截图、视频、状态模型等验证产物。

ZoomInfo 的 Brian Kennedy 说明，增加一个大模型裁判，也未必足够。一个 Agent 声称已安排邮件，实际工具只创建了待办，根本没有安排发送。裁判已经拿到失败回执，却仍相信了总结。

按他们对 500 个生产步骤的人工复核，原裁判约 65% 的判断正确。团队随后把宽泛的“工作做好了吗”，改成能够对照工具回执回答的窄问题，再用 Jev 返回接受、重做或停止的概率。不确定区间仍交给大模型，并先在影子模式中记录结果，不直接接管生产。这既是更换模型，也是重写了判断对象。

Bun 的 Jarred Sumner 第二日从另一面谈同样的事。他们考虑过把 Claude Code 重写为 Rust，却担心测试也要一起迁移，连判断正确性的依据都变了。Bun 的实现迁移则可以复用独立的 TypeScript 测试。

他当天的中心是 AOT 提前编译器，而不是“Claude Code 已经改写成 Rust”。团队用既有测试、不同执行模式的差分和模糊测试验证编译器，还要检查生成代码质量与构建时间。测试通过，并不自动等于工程可用。

Google DeepMind 的 Melvin Johnson 则从训练端补上这一环：任务要有足够难度，评分要考虑质量与维护性，隐藏测试和评分环境必须隔离。模型最后声称完成的工作，要能从实际轨迹找到依据；如实报告部分完成，应该优于编造成功。

这些分享分别从代码约束、审查、测试和训练切入，却暴露了同一种失败：如果“通过”的证据也由执行者自由解释，系统很容易只学会把成功说得更像成功。

上千 Agent 协作，先得解决状态、记忆和恢复

Anthropic 的 Lance Martin 介绍了约 1000 个 Fable 5.2 Agent、约 30 小时完成费马大定理证明 Lean 形式化的实验。一个负责人协调 999 个辅助 Agent，主要通过 Git 和 SQL 数据库分工。

这是把已有证明变成计算机可以检查的形式，不是发现新证明。会前官方说明还明确列出非零起点，包括 60 个目标陈述、经典路线的一句话提示、相关定义和此前已证明的 47 条引理。它不能被解释成“只要堆 1000 个 Agent，就能从空白解决任意难题”。

这个实验的重要性，在于模型能够用相对简单的共享工具，自行建立任务表、笔记和协调方式。但共享本身也会制造风险。

首日插播中，微软工程师 Girish 以个人实践提出了一个提醒：子 Agent 系统就是分布式系统。一条未经测量的结论写进共享上下文，再被三个 Agent 引用，并不等于得到三份独立证据。超时也不等于没有执行；如果外部写入已经完成，重试整项任务可能重复创建记录。

他提出带来源和版本的事实记录、明确的部分完成与未知状态、有限并发，以及绑定具体动作的授权。它们解决的是可追溯与协调问题，不会自动让来源正确，也不提供通用的回滚能力。

Tanmay Sah 与 Dolly Sah 的 UndoBench、EvoUndo 研究进一步区分了任务成功和恢复成功。Git 可以撤销仓库变化，却撤不回已经发生的 API 调用、数据库写入或通知。系统需要在修改前记录原状态，根据副作用选择重试、恢复或补偿，再由独立验证器确认恢复结果。一个提高能力的自我修改，也可能同时降低可恢复性。这些研究有各自的状态与实验范围，不是能撤销任意生产动作的通用工具。

记忆同样不能只增不减。Databricks 用离线计算整理冲突，Meta 的值班 Agent 根据使用效果晋升或淘汰记忆，Lance 的 dreaming 实验则重新检查历史和笔记，修正错误并整理 Wiki。这些都是维护外部记忆，不是自动更新模型权重。

Exa CTO Jeffrey Pinner 补上的是外部事实。他介绍的 ATLAS 要求找到符合条件的实体，并补齐整行信息。按 Exa 本场自报，单靠模型知识约 9%，关键词搜索约 28%，组合语义检索、扩展来源与提取后约 56%。这不是全行业统一收益，但说明搜索应返回有用证据，而非把更多网页原样塞进上下文。

这几组案例合起来，比“多 Agent 更聪明”更具体：共享什么、怎样标记尚未验证的信息、错误怎样过期、动作怎样确认，才决定协作是否可靠。

自治应当逐项获得，不能一次性打开

Factory 的 Luke Alvoeiro 在首日回顾了 Missions 的限制。把计划一次说清、让 Agent 连续执行，适合部分迁移任务，却不适合会不断变化的工作。每个里程碑都加对抗审查，还可能把范围越审越大。

他们转向 Workstreams：围绕长期目标配置身份、环境、记忆与协调 Agent，从信号进入、形成规格，到实现和合并持续运行。团队可以逐步取消检查点，而不是第一天就决定全信或全不信。验证规则读取主干版本，避免某项改动顺手改掉判断自己的规则。

Meta 的值班团队也采用逐级授权。最初只调查，再到起草修复、等待审批，最后才独立处理低风险事项。是否升级，要看错误代价、是否容易发现，以及这个动作已有的表现。关键生产处置仍由人负责。团队也强调，代码修复仍经过正常人工审查与 CI；自主处理低风险事项，不等于自动接管生产。

这与第二日 Cognition 把“任务”提升为“长期职责”的方向一致。改善尾部延迟，不只是一轮优化，还包括监测、告警、持续分解和汇报。它也解释了为什么维护 Agent 的运行状态、处理卡住的任务，会变成正式的工程工作。

Kiro 的 Doug Clauson 展示了另一条纠偏经验。早期把每条 AI 审查意见都当成必须修复的问题，团队陷入不断增加复杂度的循环。后来他们区分阻断项与建议，分开架构、根因、体验和代码检查，依据放行记录作决定，再用真实流程验证发布。协调层当时还有开发预览的限定。

Sonar 的 Andrew Finch 则把检查扩展为 PR、发布后验证、持续维护与知识积累四个循环。新漏洞和逐渐积累的复杂度，不一定能在某一次 PR 中发现。他说工厂应是灯光调暗，而非完全熄灯，人仍要处理高风险改动、架构和业务取舍。

这里仍然存在真实分歧。Lauren 和 Kiro 更强调把日常逐行审查转移到环境与验证记录；Factory 的 Dexter Horthy 发布反 Slop 宣言时，仍强调理解作品、承担质量责任，不能把思考也一并外包。二者不是一句“人只看结果”就能抹平的。

生产速度上去之后，账单会出现在别处

Gimlet Labs 的 Natalie Serrino 从推理速度开始讨论这个问题。她的 PPT 编辑示例里，推理约占八成耗时。推理加速之后，工具调用就会变成更显眼的瓶颈。快 token 和高吞吐也不是同一目标，基础设施需要按工作负载选择。Gimlet 的做法是把模型的不同部分分配给 GPU 和其他类型的加速器，尝试在计入网络开销后取得端到端收益，而非单纯增加同一种机器。

她讲的实时安全演示，意图是说明延迟会改变 Agent 的使用方式：从事后观察转向请求仍可阻止时作出判断。它是特定演示，不是已经证明可以拦住所有未知攻击。

Harvey 的插播分享则记录了下游失控。一次故障触发大量重复告警，约 900 个 Agent 在数小时内追查同一个问题；后来又有用户短时间提交约 950 项任务，挤满集群。修复方法是去重、容量限制、公平队列、预算和自动停用，而不是换一个更聪明的模型。

其团队也坦言，代码产量增长后合并队列成了尚未解决的问题。第二日 Uber 的插播正好深入这一层，讨论合并队列准入、昂贵改动延后、冲突关系调整，以及怎样避免把已有推测构建白白作废。

Steve Yegge 把问题继续推向用户。他说自己的游戏工厂一度每天产生几十到上百项功能，玩家却要求慢下来，给出路线图。他们根本来不及理解和测试这些变化。这是个人项目经验，不是一般产能基准，却提出了大会里很少见的约束：客户也有吸收变化的上限。

所以 PR 数、token 数和 Agent 数都只能说明局部活动。Cognition 自报过去一年合并 PR 数约增 40 倍、工程人数约增 2.7 倍，依然不能直接换算成同倍率业务生产率。更完整的衡量，还要包括等待、返工、事故、成本，以及用户是否真正受益。

公司会重新分工，但不必变成一群孤立的超级个体

Ramp 的 Zach Bruggeman 没有把 Inspect 的价值归结为个人多开会话。团队提供全公司可用的默认环境，好的工具和使用方式可以统一改进；会话在公司内部默认公开，让同事能看到别人怎样调查、验证和交付。

他讲了一个共同排查遥测错误的线程。用户、平台工程师与 Agent 在同一处追问证据，直到修复。修复结果固然重要，更重要的是原本私下完成的调查变成了可以参与、学习和继续协作的过程。他明确反对把“孤狼操作者”当成终点。

Amp 的 Quinn Slack 第二日给出了一种规模更小的组织实验。约 21 人的团队在分拆与招聘受限的条件下，减少交接，把客户问题、讨论和开发放进共享 Agent 会话。修复后还查出其他受影响客户，主动通知和补偿。

他自报 Amp 已盈利、年度经常性收入（ARR）超过 1 亿美元。这不是审计结果，也不能推出所有公司都该取消产品或支持岗位。小团队、高持股激励和直接接触客户，都是不能省略的条件。

ArtCraft 的 Brandon Thomas 则把讨论推向用户的所有权。开放代码、本地文件、MCP 与 CLI，让客户可以改造工具，而不是只能等待平台增加功能。他自述 Photoshop 类应用已有约六成功能覆盖，但没有独立统一测评；AutoCraft 当时也仍是计划开源。

这与 Armin 的担忧形成了必要张力。人人都能制造自己的软件，不意味着文件格式、开放协议和共同维护会自动出现。便宜的定制软件可以减少平台依赖，也可能带来新的孤岛。

真正没达成共识的，是谁来决定“值得做”

OpenAI 的 Jason Liu 在第二日开场强调品味与野心，能描述自己喜欢什么，也能判断别人会喜欢什么。它与首日 Diogo 的主张有一处重要相遇：不要只把智能用于更快完成旧动作，还要探索软件过去做不到的事。

但他们强调的价值并不完全相同。Diogo 鼓励新的软件实验，甚至不必立刻有商业价值；Diffusion 的 Justin McCarthy 则把成熟系统的持续改进，与尚未找到产品方向的探索分开。对后者过早建立生产流程，只会更高效地做错事。

Lovable 把业务结果接进反馈，Google DeepMind 的 Ishaan Dey 讨论怎样随模型能力重做界面假设，Thariq Shihipar 则给出了一个可理解的中间层。他把游戏拆成底层引擎，以及自己可以阅读、修改的玩法规则，不要求掌握引擎每行实现，却仍能亲手控制作品。

Simon Willison 的首日结尾也没有停在“模型只会造不好玩的游戏”。他先讲模型生成的游戏无趣，随后承认，在继续迭代和模拟对战后，另一个项目变得好玩了。对他来说，连这个曾被认为属于人的判断范围，也在受到能力进步的挑战。

这使两天的结论不可能只是“AI 负责实现，人永远负责创意”。更现实的问题是，团队怎样持续检验目标、把反馈交给系统，又在需要时保留改变方向的能力。