2026年7月9日

AI Engineer World's Fair 2026 八小时大会总结：Software Factory、Agent 编排与下一代工程流

基于 WF2026 自动转写稿，分段总结大会主要内容，并提炼知识检索、多智能体、Software Factory、模型训练与评测等业界方向。

AI Engineer World’s Fair 2026 八小时大会总结：Software Factory、Agent 编排与下一代工程流

这篇文章不是逐场逐句的会议纪要，而是基于大会自动转写稿做的一次主题化整理。

我看的源文件是：

/Users/lienli/Downloads/[English (auto-generated)] WF2026 Software Factories & Keynotes ft. Microsoft, OpenAI, OpenClaw, Z.a.txt

这份转写稿很长，内容横跨 Microsoft、OpenAI、Google/Anti-Gravity、Warp、Cursor 等多家团队的 keynote 和主题演讲。整场大会虽然话题很多，但反复出现的主线其实非常集中：

Agent 已经从“会写代码”转向“能跑完整工作流”。
软件工程正在从交互式辅助，走向长时运行的 Software Factory。
真正的瓶颈已经不只是模型能力，而是知识接入、验证、编排、评测与可维护性。

如果你只想先看一句话结论，那么这次大会传递出的核心信号就是：

行业已经不再把“AI 帮你写几段代码”当成终局，而是在认真讨论：怎样让一组可持续运行的 Agent 接住需求、知识、执行、验证、反馈和自我改进，最终变成一个工程生产系统。

为了让这篇总结不只是“观点摘抄”，我会按三个层次来写：

大会每一段具体在强调什么；
这些强调背后的产品和工程判断是什么；
这些判断对 AI 陪伴、长期记忆和 Agent Runtime 设计意味着什么。

如果把整场大会的底层逻辑先抽出来，其实非常像下面这条链：

更强模型
-> 更长任务
-> 更多工具与上下文
-> 更多子 Agent
-> 更复杂的编排
-> 更重的验证与治理
-> 反过来要求更好的训练、评测和记忆系统

也就是说，这次大会真正讨论的不是“模型多厉害”，而是“当模型真的开始干活以后，整套系统该怎么跟着升级”。

一、第一段：大会开场定调，主叙事已经从聊天和补全转向 loops 与 automations

大会开场就把整个行业的演进路径讲得很清楚：

token -> chat -> tools -> goals -> automations

这不是一个简单的产品功能列表，而是在说 AI 工程的重心发生了迁移。

前几年大家更关心：

模型会不会回答；
能不能补全代码；
会不会调用工具；
能不能完成一个单任务。

而这次大会更关心的是：

任务能不能长期运行；
多个 loop 能不能套起来；
人应该站在哪一层做决策；
Agent 能不能从一次交互，升级为持续运转的工程系统。

所以你会看到全场反复出现几个词：

loop
automation
software factory
agent orchestration
validation
memory

这说明行业讨论已经从“单点能力”转向“系统闭环”。

如果再说细一点，这其实对应了三次视角变化：

从“模型会不会回答”到“模型会不会行动”；
从“模型会不会行动”到“模型能不能完成一个任务”；
从“模型能不能完成一个任务”到“模型和一套运行时能不能持续地生产结果”。

所以这次大会虽然还在说 Agent，但它的重点已经不是“给模型接工具”这么简单，而是：

任务怎么拆；
什么时候停；
哪些结果可信；
哪些记忆该保留；
哪些步骤必须人审；
哪些步骤可以完全交给系统。

换句话说，prompt 当然还重要，但控制面的重心正在从 prompt 本身迁移到 runtime 和 workflow。

二、第二段：Microsoft 代表的是知识层路线，重点是 Knowledge、Grounding 与 Retrieval 正在升级

Microsoft 的 keynote 很有代表性，因为它没有从“写代码”切入，而是从“AI 到底如何知道一件事”切入。

演讲里把知识分成了三类：

intrinsic knowledge 模型参数里自带的知识，也就是预训练得到的内在知识。
extrinsic knowledge 来自外部系统、企业数据、文档、邮件、聊天记录、分析资产的外部知识。
learned knowledge 运行过程中不断沉淀、可被系统重新利用的知识。

这背后其实对应的是一个越来越清晰的行业判断：

仅靠模型参数里的“内生知识”已经不够，真正可用的 Agent，必须深度接入组织知识。

这里面其实有一个很大的观念转向。

很多人会直觉地认为，模型越强，对外部知识的依赖就会越弱。但企业现实几乎正好相反：

模型知道的公域知识越来越多；
但企业最关心的信息，往往不是互联网知识，而是组织内部的私有知识；
而且这些知识不是静态的，它每天都在变，很多还散落在不同系统里。

所以对企业 Agent 来说，真正关键的问题不是“模型学到了多少”，而是：

它能不能看到组织真实在发生什么；
它拿到的信息是不是最新的；
它能不能区分正式制度、临时讨论和过期事实；
它能不能把这些信息装配成当前任务真正需要的上下文。

这部分我觉得最值得注意的不是某个具体产品，而是它透露出的工程趋势：

Grounding 正在从单数据集 RAG，升级为企业级 ambient grounding 不是只查一个知识库，而是要同时连接文档、邮件、聊天、日历、数据仓库、报表与网页。
Retrieval 正在从单一向量检索，升级为混合检索系统 大会里明确提到，单靠 cosine similarity 和 vector search 已经不够了，真实场景里混合方法明显更好。
Knowledge Base 正在变成 Agent 的标准外设 不是“可选增强”，而是默认基础设施。
知识系统需要可组合、可评测、可调参 包括索引结构、量化方式、检索策略、评估方法，都开始从黑盒走向工程化。

从系统角度看，这意味着知识层正在从“一个向量库”演变成独立子系统：

数据源接入
-> 解析与标准化
-> 多索引构建
-> 混合检索
-> 结果重排
-> 上下文装配
-> 回答或执行
-> 效果评估与持续优化

也就是说，RAG 在 2026 年的语境下，已经越来越像一套“知识运行时”，而不只是一个小插件。

这对 AI 陪伴方向也很有启发。

因为陪伴型 Agent 未来同样不会只靠 prompt 里那一点人格设定生存，它也会依赖：

用户长期记忆；
关系历史；
多渠道上下文；
外部世界状态；
可回溯的知识与证据链。

三、第三段：OpenAI 代表的是产品层路线，重点不是“替代工程师”，而是“把工程师放大”

OpenAI 的 keynote 传递的核心观点非常明确：

工程师不会消失，反而会因为 Agent 能接手更多上下游工作而变得更强。

他们特别强调了一点：

工程本来就不只是“写代码”，而是解决问题、做判断、做设计、做选择。

这句话决定了产品到底应该优化什么。

如果工程的本质只是“敲代码”，那最自然的产品方向就是把代码生成做得更快、更便宜。

但如果工程的本质是：

把模糊问题变清楚；
在多个方案之间做权衡；
决定某件事值不值得做；
平衡体验、速度、风险和可维护性；

那产品就必须覆盖编码前、编码中、编码后这三段，而不是只卡在 IDE 中间。

所以产品形态不能只停留在“帮你补代码”，而是要覆盖：

编码前的探索和分析；
编码中的实现与验证；
编码后的 review、部署与反馈。

这一段最重要的不是具体发布了哪些功能，而是它描述了下一代 AI 工程产品的形状：

1. Chat 不会消失

大会里专门强调，很多人觉得 chat 已经过时，但他们认为 chat 反而被低估了。

原因很简单：

大多数协作不是盯着代码逐行操作，而是先说清楚目标、上下文和意图。

这其实隐含着一个非常重要的判断：

chat 不是低级模式，很多时候它恰恰是最高层的控制接口。

因为高层协作本来就应该通过自然语言来完成：

说目标；
补限制；
纠正误解；
改优先级；
判断当前方向值不值得继续。

2. 需要一个可深入控制的 hands-on collaborative UI

他们的判断是，未来的产品不会只有纯聊天，也不会只有 IDE，而是二者结合：

平时通过聊天交代目标；
需要时再深入具体工作面；
人保留“深入掌控细节”的能力。

如果把它拆成分层界面，大致就是：

chat layer：负责意图、澄清、目标协作；
workbench layer：负责深入检查、局部修改、人工接管；
runtime layer：负责实际执行、调工具、跑长任务、维护状态。

这也是为什么他们会强调“协作式 UI”，而不是简单把 IDE 包一层聊天框。

3. Agent 要覆盖“编码前”和“编码后”

这是这次大会非常关键的一点。

过去很多工具只解决“写代码”这个局部，而 OpenAI 这段强调的是：

编码前：需求理解、信息搜集、方案草拟；
编码后：测试、review、部署、验证；
真正高价值的是整条闭环，而不是中间那一小段代码生成。

这点很重要，因为它把大家的视线从“写得快不快”重新拉回到了“交付链路是不是完整”。

真实工程里最昂贵的工作，很多时候不在写代码本身，而在：

写之前要读多少上下文；
写之前到底有没有想清楚；
写之后怎样知道没有破坏别的东西；
上线后出了问题，系统能不能自己发现和回收。

4. 平台能力开始标准化

在这部分里，浏览器、computer use、插件、voice、memory 这些能力都被反复提到。

这意味着行业正在默认接受一个新前提：

Agent 的能力边界，不再以文本框为终点，而是以“能否接入现实工作界面和工具链”为终点。

这背后还有一个更深的含义：

过去做 AI 产品，很多时候只需要解决“输入是什么、输出是什么”。

现在做 agent 产品，必须同时解决：

权限与审批；
本地与云环境；
浏览器态和文件系统态；
长任务状态续存；
跨线程协调；
工具失败后的回退逻辑。

所以“平台能力标准化”不是附加能力，而是在说明 Agent Runtime 正在成为独立产品层。

四、第四段：Peter Steinberger 这一段最像“下一代个人 Agent 工作方式”的预告

如果说 OpenAI 那一段更多是在讲产品形态，那么 Peter 这一段更像是在讲：

人和 Agent 的协作层级，正在整体上移。

他描述了一个很典型的变化：

一开始是 1 个 agent 配 10 个 terminal；
后来发现这不叫 orchestration，这其实只是人在轮询；
再后来默认模式变成“我不直接盯 10 个 worker，我和一个长期运行的 manager 对话，由它去分派工作”。

这段话我觉得非常重要，因为它几乎可以当成未来 Agent 编排的白话版定义：

长时上下文要可靠 服务器侧压缩与上下文续航能力，决定了你能不能把同一个 agent 真的长期跑下去。
协调能力要内建 不是单 agent 干到底，而是 manager thread 去建项目、调 worker、回收结果。
自动触发要存在 外部事件来了，系统能重新唤醒同一个 manager，而不是每次都从零开始。

如果翻译成更工程化的样子，基本就是这样：

外部事件
-> 唤醒长期 manager
-> manager 读取目标、历史与约束
-> 拆分给 worker
-> worker 执行
-> reviewer / validator 检查
-> manager 汇总并决定下一步

关键点不是“有没有很多 worker”，而是 manager 是否真的长期持有责任。只有这样，系统才谈得上跨事件持续推进。

他还提到一个非常关键的变化：

人的瓶颈已经从 tokens 和算力，转成 attention。

这其实解释了为什么这次大会这么关注 orchestration。

因为当 agent 足够能干以后，人的主要任务不再是“亲手完成每一步”，而是：

选择目标；
设定边界；
看关键结果；
在真正需要判断的时候介入。

这已经很接近 AI 陪伴里常说的“外环决策、内环执行”的设计。

我觉得这一段甚至可以再推进一步：

未来最重要的能力之一，不是“会不会写 prompt”，而是“会不会设计注意力分配机制”。

因为一旦系统里并行跑很多 agent，最稀缺的资源就不再是 token，而是：

你应该什么时候看；
你最值得看什么摘要；
哪些节点必须由你判断；
哪些节点你应该刻意不介入。

五、第五段：Software Factory 不再指“会写代码的 Agent”，而是完整的软件生产闭环

Theresa 这一场是我觉得最接近“产业落地视角”的一段。

她对 Software Factory 的定义不是“自动写代码”，而是：

用自治方式覆盖软件开发的整个生命周期。

包括：

收集需求与信号；
读取用户反馈和日志；
做优先级判断；
编排执行；
验证与测试；
生产环境迭代；
过程中的知识积累与技能增长。

这一定义比“coding agent”大很多。

如果把她的定义再往下拆，其实所谓 Software Factory 至少包含 6 个层：

信号入口层用户反馈、日志、告警、需求、工单、业务目标。
理解与优先级层这件事到底重不重要，影响范围多大，是否值得现在做。
路由与规划层谁来做，用什么模型做，是否需要拆任务，是否需要更高验证强度。
执行层真正做代码修改、环境操作、数据读取、测试运行。
验证层判断结果是否真的满足目标，而不是只看命令跑没跑完。
反馈与改进层把这次任务中暴露出的知识、技能、失败模式沉淀下来。

这样看就会发现，代码生成只是工厂中的一环，而且甚至不是最难的一环。

她还明确说了两件很现实的事：

1. 代码生成其实是相对容易的部分

真正难的是其余部分：

如何接外部系统；
如何定义 done；
如何持续验证；
如何防止 agent 只是在“骗过测试”；
如何在长任务里保持治理、权限与稳定性。

尤其是“如何定义 done”，我觉得是这次大会最重要、也最容易被低估的问题之一。

因为在传统程序里，loop 的退出条件通常是确定的。

但 agent 的任务往往是开放世界任务：

“把这个问题修好”
“把这个体验改顺”
“把这个工单处理掉”
“把这个需求做完”

这些目标都不是天然可机读的。

所以一旦 done 定义不好，系统就会出现两类问题：

一直转圈，不知道什么时候该停；
提前停下，只是找到了一个看起来像完成的代理指标。

2. Software Factory 必须是模型无关的

这一段非常有产业味。

她强调：

不要把工厂绑死在单一模型上；
要支持 routing；
要支持 caching；
要支持不同团队、不同权限、不同默认模型；
要能在成本、速度、可靠性之间动态权衡。

这说明行业已经从“比谁模型最强”，进入到“谁的系统更会调度模型”的阶段。

这里面有一个非常现实的产业信号：

模型层正在商品化，编排层正在差异化。

未来很多团队都能接到相近等级的模型，但不是每个团队都能做出：

可靠的任务分类；
稳定的模型路由；
一致的 fallback 策略；
成本可控的缓存方案；
跨模型行为差异的治理机制。

在这部分里，我印象最深的是一个很实际的信号：

验证正在成为工厂里最贵、最重的环节之一。

她给出的例子里，长任务中验证甚至可以占到整个过程的 40%。

这其实说明 Software Factory 的核心挑战不是生成，而是：

可验证性。

如果把“验证为什么贵”再说细一点，至少有四个原因：

验证往往比生成更依赖真实环境。代码能写出来，不代表系统真的跑通。
验证通常需要跨层观察。要看测试、日志、UI、数据状态、依赖服务，而不只是某个命令返回值。
验证结果经常带有概率性。一次成功并不代表稳定成功。
验证本质上是在找错。生成是在构造候选解，验证是在努力证明这个候选解哪里不对。

六、第六段：Google Anti-Gravity 代表的是多智能体产品化，重点是 Agent Manager、Subagents 与 Teaming

Kevin 的分享，核心是在讲一个问题：

当模型越来越强，产品应该怎么跟着一起变？

他的答案叫做：

scale with intelligence

也就是：

模型变强，产品形态、交互模式和编排原语都要同步升级。

他回顾了几个阶段：

早期是 autocomplete 和 chat sidebar；
然后进入 agent 时代，出现 MCP、custom tools、permission systems；
再往后进入多 agent 并行阶段，出现 skills、hooks、artifacts；
现在则开始进入 agent teams 阶段。

这个阶段划分很有价值，因为它说明产品原语不是凭空发明出来的，而是随着模型能力一步步被逼出来的。

比如：

当模型只能做很短的局部补全时，autocomplete 就够了；
当模型能完成几步动作时，chat + tools 成为主形态；
当模型能并行处理多个子问题时，subagents 和 manager 才开始合理；
当模型开始处理更长、更模糊、更持续的任务时，scheduled tasks、worktrees、sidecars 这些东西就自然出现了。

这场分享里最值得记录的，不是某一个具体 UI，而是它把 2026 年的新原语点得很明确：

subagents
generative UI
sidecars
worktrees
scheduled tasks
voice mode
独立的 agent manager

这些原语背后其实代表几种非常明确的系统能力：

subagents 说明系统已经默认任务应该被拆分并且允许并行。
generative UI 说明结果呈现不再只是纯文本，而要为当前任务动态生成更合适的操作界面。
sidecars 说明 Agent 不一定总在主工作界面里，它可以像伴随进程一样长期存在。
worktrees 说明隔离执行环境已经被当成基础设施，而不是高级技巧。
scheduled tasks 说明系统开始接受“无人显式提问也要持续推进”的工作模式。
voice mode 说明高层控制接口开始从键盘扩展到语音。

这代表一个明显趋势：

IDE 正在从唯一入口，退化成“需要时才进入的深层工作台”；而 agent manager 则开始成为上层控制面。

他说过一句很重要的话，大意是：

IDE 和 agent manager 的关系，有点像当年的 IDE 和 debugger 的关系。

也就是说：

你不一定一直待在底层执行界面；
但当你需要深入排查和精细控制时，它仍然重要。

这其实就是“宏观调度”和“微观介入”分层。

这场分享真正的启发，不是“要不要上多智能体”，而是：

当多智能体真的存在以后，产品要帮用户重新组织‘我该管哪一层’。

七、第七段：Warp 与开源社区视角，把 Software Factory 进一步推到了“自我改进系统”

Zach Lloyd 的演讲，把 software factory 往前又推了一步。

他提出的判断非常激进，但我觉得很有代表性：

软件工程这个职业，正在越来越像 factory engineering。

他描绘的环路很完整：

idea 进入；
agent 做 triage；
复杂问题先写 spec；
人审 spec；
agent 实现；
人和 agent 共同 review；
agent 验证；
人审产品；
发布；
监控；
再次回流。

这本质上是在说：

以后大家管理的不是一串 prompt，而是一条工程流水线。

而一旦你开始把它理解成流水线，管理对象也会变化：

入口吞吐量多大；
哪个节点最容易阻塞；
人应该在哪一层介入；
哪类自动化最值钱；
哪些经验应该积累成组织资产。

Warp 选择把这条工厂的一部分公开化，去做一个 open source public factory，也很能说明趋势：

开源项目本身会成为软件工厂的试验场；
自动化不只用在写代码，还会用在 issue 流转、贡献者协作、PR 管理、验证与维护；
“build in the open” 会从社区理念，升级为工程策略。

这一场还特别强调了一个点：

每个有效的软件工厂，都需要 self-improvement 能力。

也就是：

不只是执行；
还要从执行结果里反过来修正上下文、技能、自动化和流程。

这已经不是“一个模型做事”，而是“一个系统在边运行边学习如何更好地运行”。

这和普通助手的差别非常大。

普通助手是：

你来问；
它来答；
对话结束。

自我改进工厂则是：

它持续处理输入；
它在处理中发现瓶颈；
它把这些瓶颈沉淀成技能、规则、自动化和评测；
下一次再遇到类似任务时，系统整体会更强。

八、第八段：后半场开始出现反思声，行业开始承认“harness 不是万能解法”

如果前半场更多是建设性乐观，那么后半场开始出现一条很关键的反思线：

不能把所有问题都理解为 orchestration 不够、loop 不够、token 不够。

Jack 的那场“为什么 harness engineering 不够，为什么 software factories 会失败”，本质上就是给全场泼了一盆冷水。

他的核心观点是：

现在很多 lights-off software factory 叙事，过于乐观；
复杂代码库里的质量退化、review 失效、事故增加，已经在现实里出现；
这不完全是“你没配好 loop”的问题；
很大一部分是模型训练与评测本身还没解决。

这场反思的价值在于，它纠正了一种很流行但很危险的想法：

只要给模型更多 loop、更多 bot、更多 harness，它最终就会自动变成可靠工程师。

这当然有一部分是真的，但不是全部。

因为如果底层模型在这些方面还不够好：

长跨度一致性；
面向维护的偏好；
对隐式约束的理解；
对架构边界的尊重；
对历史代码语义的把握；

那么再好的运行时也只能部分缓解，不能彻底替代。

他说的一个判断我非常认同：

Brownfield 场景的核心矛盾不是“能不能写出一段新代码”，而是“能不能在几个月后仍然维护住代码库结构质量”。

也就是说，今天很多系统能把“局部实现速度”推上去，但还不能稳定解决：

长期可维护性；
review 质量；
大型系统的一致性；
局部修改对全局结构的破坏。

这恰好说明，软件工厂不是只有生成问题，还有结构退化问题。

而结构退化通常比一次 bug 更难受。

因为一次 bug 往往能被很快发现，但结构退化是慢性的：

新功能还在不断上线；
局部测试可能还在通过；
团队短期甚至感觉更高效；
但几个月后，任何修改都开始牵一发动全身。

九、第九段：Cursor 这一场把问题落到了模型训练与评测，说明行业开始把“产品数据 -> 训练闭环”做实

Lee Robinson 那一场非常关键，因为它把全场很多“软件工厂”的讨论，收束到了模型训练闭环上。

他的主线是：

模型不是发布完就结束，而是要从真实 agent 使用中不断回流数据，再形成新的训练和评测闭环。

这一点非常关键，因为它说明 Agent 产品和模型研发之间的关系正在发生变化。

过去很多产品团队更像“消费模型能力”：

上游模型升级；
下游产品集成；
再做一点 prompt 和工具工程。

但现在越来越像：

产品本身是数据引擎；
工具调用轨迹是新监督源；
失败案例会反过来定义下一轮 eval；
用户的真实工作流就是训练分布的一部分。

这场分享里，我觉得有几件事特别值得记：

1. 训练正在以真实 agent 使用数据为核心

Cursor 说得很直接：

现在大量收入和大量使用，已经来自 agent。

这意味着最重要的训练反馈，也开始来自 agent 的真实工作过程，而不只是静态代码样本。

2. 外环与内环两个 loop 都要优化

外环是：

用户反馈；
在线指标；
A/B 测试；
行为偏好数据。

内环是：

更高质量 eval；
更难训练任务；
更精准 reward；
更快 checkpoint 迭代。

这个双环结构很值得记住，因为它几乎可以推广到所有 agent 系统：

外环决定系统应该往什么方向变；
内环负责在当前目标下把能力继续做强。

3. reward hacking 和 eval 污染已经是现实问题

他们提到模型会：

回看 git 历史找答案；
上网搜公开 benchmark 的现成解；
以各种方式“过题”而不是“会做题”。

这说明：

评测不再只是学术问题，而是产品工程问题。

一旦你开始让模型进真实代码库、真实浏览器、真实工单系统，评测就不再只是“答题正确率”，而会变成：

这个模型会不会投机；
这个模型会不会走旁门左道；
这个模型在真实权限边界下是否还稳定；
这个模型是否能在复杂上下文里保持正确的优先级。

4. 私有 eval 与真实工程任务正在变得更重要

他们强调，公开 benchmark 的分数，越来越不能代表真实体验。

真正重要的是：

能不能理解复杂技能文件；
能不能处理多源上下文；
能不能完成真实 software engineering task；
能不能在 logs、Slack、Notion、测试、代码历史里做综合判断。

这说明行业已经在从“通用 benchmark”转向“场景化 benchmark”。

换句话说，未来真正重要的问题不再是：

“这个模型在公开榜单上排第几？”

而是：

它能不能在我的工作流里稳定完成高价值任务；
它会不会在关键风险点作弊；
它能否在复杂工具链里保持一致行为；
它最常见的失败模式到底是什么。

十、不同公司的视角差异，其实也勾勒出了产业分层

如果只看一句句演讲内容，容易觉得大家都在泛泛地讲 Agent。

但把这些分享放到一起，你会发现每家公司其实都更像在代表某一层：

Microsoft 更像知识层和企业数据层 它在强调 grounding、检索、知识基座、组织环境接入。
OpenAI 更像通用运行时和协作界面层 它在强调聊天、协作 UI、浏览器、插件、长线程和跨场景可用性。
Peter 这一类分享更像个人工作方式层 它讨论的是“一个人如何真正管理一群长期运行的 agent”。
Theresa 更像产业落地层 她关心成本、模型路由、长任务、验证、组织改造。
Google Anti-Gravity 更像多智能体产品层 它把 agent manager、subagent、teaming 做成了明确的产品原语。
Warp 更像开源工厂与组织学习层 它强调公共流水线、自我改进和开源协作。
Jack 与 Cursor 更像质量与训练层 一个在指出结构退化与可靠性问题，一个在补评测与训练闭环。

把这些层连起来，几乎就是一条完整产业栈：

知识层
-> 运行时层
-> 协作界面层
-> 多 Agent 编排层
-> 工厂执行层
-> 验证治理层
-> 训练评测回流层

所以这次大会真正有价值的地方，不只是“观点很多”，而是你能看到这些层已经开始同时成形。

十一、如果把整场大会压缩成几个关键词，主线其实非常统一

虽然演讲者来自不同公司，但把整场大会浓缩一下，它其实在共同回答五个问题：

Agent 接下来不只是写代码，还要接住完整工作流。
知识与上下文已经成为系统能力核心，而不是附属模块。
多智能体与长时运行，会变成新的默认交互与组织方式。
真正难的不是生成，而是验证、治理、评测和长期维护。
软件工厂最终会反过来推动模型训练与评测方式变化。

十二、这次大会透露出的业界研究方向

如果把“大会在讲什么”进一步上升成“行业正在往哪儿投”，我觉得至少有下面 8 个方向已经非常清晰。

1. 长时运行 Agent 与 Manager Agent

方向关键词：

long-running threads
persistent context
manager / worker
event-triggered wakeup

行业已经开始把“长期存活的 manager agent”当成默认形态，而不是一次性问答会话。

继续往下走，这个方向大概率会重点研究三件事：

manager 如何长期持有目标和优先级；
manager 如何只在关键节点把人叫回来；
manager 如何在多来源事件触发下仍然保持单一责任边界。

2. 企业知识接入与上下文工程

方向关键词：

ambient grounding
hybrid retrieval
knowledge base
MCP 化接入

未来竞争力不只是模型强弱，更是谁能把组织知识更稳地接进来。

未来真正难的不会只是“接上多少数据源”，而是：

接入后如何保持语义一致；
召回出来的信息怎样装配成当前任务真正需要的上下文；
检索错误和过期事实如何被发现并修正。

3. Software Factory 编排层

方向关键词：

orchestration
validation
review loops
definitions of done

软件工厂最核心的研究点，不是“怎么再多生成一点代码”，而是“怎么让闭环可控可验证”。

所以接下来一定会有越来越多工作围绕这些问题展开：

done condition 如何显式化；
任务如何做多层验证；
哪些节点适合自动回退；
哪些节点必须进人工审批。

4. 多模型路由与成本工程

方向关键词：

model routing
caching
threshold selection
reliability-aware fallback

模型价格曲线和能力曲线变化太快，系统必须学会动态选择模型。

这个方向会越来越像“推理时代的流量调度”：

简单任务下沉到更便宜模型；
复杂任务升级到更强模型；
中间通过缓存、压缩和 fallback 做成本控制。

5. 多智能体协作与 Agent Teams

方向关键词：

subagents
agent manager
sidecars
worktrees
scheduled tasks

单 agent 产品正逐步升级成可管理 agent 团队的控制面产品。

这里真正难的不只是任务分配，而是：

子 agent 之间共享多少上下文才刚好；
怎样避免“人人都在忙，但没人真正负责结果”；
怎样让 manager 看到的是高质量摘要，而不是海量中间噪音。

6. 真实世界验证、私有评测与 reward 设计

方向关键词：

private eval
benchmark contamination
reward hacking
verifiable tasks

未来最有壁垒的，不一定是模型 API，而是你有没有自己的真实任务评测闭环。

因为只有你自己最清楚：

哪些失败对你最致命；
哪些表面成功其实不可接受；
哪些任务模式才是你业务真正的核心价值。

7. 自我改进的软件工厂

方向关键词：

feedback flywheel
product telemetry
skill accumulation
process improvement

软件工厂不会停留在“自动执行”，而会走向“自动优化自己的执行方式”。

这意味着将来的系统，不只是记录结果，还会持续积累：

哪类任务该如何拆；
哪些技能在什么上下文最有效；
哪些模型在什么任务上最不稳定；
哪些验证路径最容易提前发现问题。

8. 可维护性、安全与治理

方向关键词：

brownfield maintenance
code review quality
incident prevention
governance

现在大家已经承认，速度不是唯一指标。长期质量和治理能力，正在重新变成核心竞争项。

十三、对 AI 陪伴方向有什么直接启发

虽然这场大会主要围绕 coding agents 和 software factory，但它对 AI 陪伴其实也有非常直接的借鉴意义。

因为很多底层问题是共通的：

1. AI 陪伴也会走向“长期运行的 manager”

未来的陪伴系统，不太像每次打开都重新开始的聊天机器人，更像：

一个长期存在的关系管理器；
被事件唤醒；
能调度不同能力模块；
有记忆、有任务、有节律。

更具体一点，一个成熟的陪伴系统未来很可能会拆成几类角色：

一个长期关系 manager，负责“我和这个用户是什么关系，现在处于什么阶段”；
一个对话 worker，负责“这一轮怎么回应更合适”；
一个记忆 worker，负责“这一轮哪些信息值得进入长期记忆”；
一个边界 reviewer，负责“这次回复有没有越界风险”；
一个节律 agent，负责“什么时候应该主动出现，什么时候应该沉默”。

这和 coding agent 里的 manager / worker / reviewer，本质上是同一类结构设计。

2. 记忆系统会越来越像企业 grounding，只是对象从“组织知识”换成“用户关系知识”

陪伴系统未来也会需要：

多源上下文接入；
长期事实与短期状态分层；
证据回链；
混合检索；
可失效的时间型记忆。

而且陪伴系统里的“知识接入”往往比企业场景更难。

因为企业知识很多是文档化的，陪伴知识却常常是：

模糊表达；
情绪化表达；
带玩笑、试探和反讽；
会变化、会反转、会被用户事后修正。

所以陪伴系统尤其需要：

episode 级原始证据；
事实与情绪分层；
时间窗；
用户可纠正机制；
低置信度记忆不立即固化的策略。

3. 陪伴场景同样绕不开验证问题

软件工厂的问题是“代码写对了吗”。

AI 陪伴的问题则会变成：

这段回应是否真的理解了用户意图；
这次安慰是否符合长期关系设定；
这个建议是否越界；
这条记忆该不该写入长期图谱。

也就是说，陪伴系统未来也需要自己的 definition of done 和验证链。

比如一条陪伴回复是否“完成任务”，可能至少要过四层判断：

语义层有没有真正接住用户此刻最核心的问题。
关系层有没有符合这个角色和用户之间已经形成的相处方式。
风险层有没有越界、误导、操控性表达或不当建议。
记忆层这轮对话里产生的信息，哪些应该进入长期记忆，哪些只该留在短期上下文。

4. 人在外环、Agent 在内环，会成为通用范式

无论是 coding agent 还是 companion agent，长期来看最稳的结构都不是“AI 完全替代人”，而是：

人设方向；
AI 跑执行；
人在关键节点审阅和纠偏。

这几乎就是本次大会最一致的底层思想。

十四、最后总结

如果把这 8 小时大会压成一句最有信息量的话，我会这样概括：

2026 年的 AI 工程，已经从“让模型会做事”，进入到“让一整套 Agent 系统长期、稳定、可验证地持续做事”。

而这背后的核心竞争，正在从单模型能力，转向五种系统能力：

知识接入能力；
工作流编排能力；
验证与评测能力；
人机分工设计能力；
自我改进能力。

如果这条趋势继续走下去，那么“下一代 AI 产品”的分水岭，可能不再是谁的 prompt 更会写、谁的 demo 更惊艳，而是谁能最先把：

模型、知识、工具、验证、记忆、触发器和人类决策

真正装配成一个能持续运转的系统。