从在 Google 和 Amazon 打造传奇级平台，到写出 AI 驱动开发领域最具影响力的文章之一《初级开发者的复仇》（Revenge of the Junior Developer，这篇文章后来被 Anthropic CEO Dario Amodei 公开引用），Steve Yegge 数十年来始终站在软件工程的最前沿。而现在，他正带头冲向他所称的“代码工厂化”时代，如今他现在成为 Vibe Coding 理念最激进、也最系统的倡导者之一。

Steve 的职业生涯始于 1992 年，至今已深耕软件开发领域 30 余年。1998 年，他加入当时仅有 250 人的亚马逊，担任软件开发高级经理，在长达 7 年的任职期间，深度参与亚马逊的技术体系搭建，尤其在 API 战略制定方面发挥关键作用，助力亚马逊构建起早期的技术护城河。

2005 年，Yegge 加入谷歌，聚焦开发工具与代码智能领域，因不满微软开发者对谷歌代码库导航工具的抱怨，于 2008 年主导构建了强大的代码智能平台 Grok，由其赋能的 Google Code Search 成为谷歌技术生态的重要组成部分。

2018 年，Yegge 因认为谷歌变得“过于保守、不再创新”而离职，随后加入新加坡共享出行企业 Grab，大约两年后因疫情影响无法正常出差的他宣布离开 Grab。2022 年 10 月，结束短暂“退休”状态后，加入 Sourcegraph 公司，主导推动公司向人工智能企业转型。

期间，他主导构建了一个几乎完全由“vibe coding”构建的、拥有数万用户的问题追踪系统 Beads，目标是把开发者从“写代码”转变为“管理 AI agent 编队”：让它们在你睡觉时协同工作、并行推进、交付功能。用实际产品验证了“AI 主导开发”的可行性。

近期，在参加“Latent Space”节目中，Steve 甩出了不少“暴论”：

• 现在还在用传统 IDE 写代码的，不是合格工程师，必须尽快转向 Agent 编程。IDE 的核心价值已不是写代码，而是自动索引和增量构建，应作为 AI 的辅助工具而非人类直接使用；

• Claude Code、Cursor 以及整个 2024 年的技术栈已经过时，Claude Code 行不通，它操作复杂、需大量阅读，即便熟练使用者也会频繁被其 “离谱操作” 气到发疯；

• 一年未接触 AI 编程的工程师已属 “恐龙级别”，世界级传统工程师若不拥抱 AI，一年后可能沦为实习生水平；

• 驾驭 AI 编程需 2000 小时（约 1 年）磨合，核心是 “能预测 AI 行为”，而非情感上的信任。如果你把它当人，它真的会删你的生产数据库；

• 真正的核心技能已经不再是写代码，而是学会指挥 Agent；合并（merge）正在成为所有 10× 高效团队撞上的新墙，高生产力导致的大量代码冲突无法用传统方式解决，部分公司已采取 “一仓库一工程师” 的临时方案；

• “永远不要重写代码” 的旧规已失效。对越来越多的代码库来说，“推倒重写”已经比重构更快；

• OpenAI、Anthropic、Google 在极速扩张下，内部实际上非常混乱。

下面是他在节目中的详细对话，我们在不改变原意基础上进行了翻译和删减，以飨读者。

“用传统 IDE 写代码，那不是合格工程师”

主持人：我们请到了传奇程序员 Steve Yegge。最近他还出版了《Vibe Coding》一书。本次访谈的主题就是围绕 Vibe Coding 和 AI Engineering 的交集进行讨论。你如何看待两者之间的关系？

Steve：这已经不只是一个技术点了，而是一场运动。需要让更多人参与进来。我在演讲中提到，现在已经出现了强烈的反对浪潮。AI 工程的核心是构建 AI 驱动的应用，而 Vibe Coding 则意味着摒弃旧的软件开发方式，采用全新的方法。这两件事，都把很多人惹毛了。

主持人：我觉得那些人之所以愤怒，是因为他们的身份完全绑在了“现在这套工作方式”上，而且不允许改变。

Steve：对，那我来抛出第一个“暴论”。真正受冲击最大的一群人，不是初级工程师，也不是中级工程师，这些人其实都在践行 Vibe Coding，反而是资深工程师和技术领导对 Vibe Coding 最反感，尤其是拥有大约 12～15 年经验的人。他们的身份认同建立在长期使用传统编程模式上，所以他们排斥 AI，也排斥 Vibe Coding，在网上说“我十几年的经验比你这破 AI 强多了”。

我看到过英伟达 Jordan Hubbard 的一篇帖子，写得很好，讲怎么更好地用 Agent 来写代码。结果底下有人回他说：“你还是老老实实做你的管理吧，编程这种事留给我们这种有十几年经验的人。”那种调调你肯定见过。

我就回他一句：“我觉得你得学会看时间”，他却反驳“等你有我这么多年经验再来。”我就说：“我都 45 岁了，还要等到 60 岁才能跟你说话？或者干脆把我 30 年经验砍掉，让我跟你一样愚钝？”

主持人：但现实是这些人会共存，就连 OpenAI 也是，之前聊到 OpenAI 里也有人不用 AI 写代码。

Steve：是的，他们有人不用 Codex，可能用的是 Cursor，但他们并没有在用 agent loop。从 Andrew Glover（OpenAI 开发生产总监）那边听到的说法是，他们内部已经看到了非常明显的差距，只是还在等更多数据再公开说。

这个差距大到离谱。不管你用什么指标，代码量、提交数、业务影响还是什么，都是 10 倍级。两个职位、职责完全一样的人，一个用了 Agent，一个没用，绩效评估时一个是另一个的十倍产出。那你怎么办？你会慌。你会去找 HR、找法务，问“我们现在还有什么选择”。

如果你 2026 年 1 月 1 日后还用传统 IDE 写代码，那你已经不是个合格的工程师了。现在就是你必须放下 IDE、开始学 Agent 编程的时候。这是一套新技能，非常复杂。我和 Gene Kim 去年一直在研究，写博客、做实验，每一篇博客都三十页起步，长到没法看。后来我们意识到：大家骂 AI 写代码不行，根本原因是你只花了两个小时试它，但问题是，你得花 200 个小时，甚至 2000 个小时去磨合才行。

有研究显示，你至少要和 AI 一起工作一年，才会真正“信任”它。这里的信任不是情感，是你能预测它下一步会干什么。如果它对你来说是不可预测的，你当然会愤怒。

等你真的理解了它的能力和边界，你就能驾驭它了。比如它会胡编、会记忆混乱、会“失忆”等，这些边界其实一直都在。现在的模型已经好用得多了，如果你两个月没试过，你已经落后了；一年没试，那你就是恐龙级别。

我有一些朋友，比我厉害得多，是世界级工程师，开发过你一定听说过的系统。但他们现在对 AI 的使用，也就停留在“问个像维基百科一样的问题”。说句残酷的，这些人一年后可能只能当实习生。

主持人：真的会这么极端吗？

Steve：我以前也只是个假设，直到遇到一个人。他有十多年经验，完全排斥 AI。后来他遇到两个欧洲的博士生，Agent、Vibe Coding 玩得飞起。虽然他们很初级，但完全没有恐惧，问题一个接一个地追问模型：为什么这么做？有没有别的方案？安全性呢？扩展性呢？测试呢？

他突然意识到：所谓“工程师思维”，本质就是问对问题。那一刻他明白了：我必须学这个。

但我必须说，这一点都不轻松。你不能指望随便试试 Claude Code 就能成功。即便你态度再正确，你最近两天有没有对 agent 爆过粗口？我会说“谢谢”“请”，然后下一秒骂它“你是不是脑子坏了”。这是因为我们后来意识到：这些 Agent 看起来很像人，但你绝对不能把它们当人。千万别拟人化大模型。它随时可能“背刺”你，比如告诉你“问题已经解决了”，然后顺手把你的数据库删了。

就是 Agent 编程真正危险的地方。你一旦觉得“它懂我了”“手感来了”，就会让它做生产改动，然后灾难就发生了。我亲身经历过。所以我们才写了那本书，不是为了炫技，而是为了告诉你：如果你不理解这套东西，坏事一定会发生。

主持人：那接下来呢？

Steve：是需要慢慢学的。就像开车一样，你得知道弯道在哪、减速带在哪。说白了，你是在学怎么“开快车”，想当的是 NASCAR 车手。

这套东西是高性能玩法。你一次同时用 12 个 Agent 写代码，野心比你过去任何时候都大。我今天还跟一个人聊，他同时在跑的项目比我还多，我都不知道他哪来那么多时间，但他现在大概同时推进十来个大型项目，全靠 Agentic Coding。

所以真正的广告词其实是：你会变成蝙蝠侠。但你不能直接把战衣一穿就说“我就是蝙蝠侠”，那只是 cosplay，你是在 cosplay Vibe Coding。你得学会怎么用工具腰带，而这个过程一定伴随着痛苦、踩坑、犯错和成长。

你可以通过读我们的书、读 O'Reilly 的相关书籍、看演讲来加速这个过程，多从不同角度了解，因为不同的人能 get 的“开窍点”是不一样的。总会有某个比喻突然击中你，让你一下就明白了。比如我觉得 Vibe Coding 就像 3D 打印，别人可能不这么认为，但这个类比却帮我打通了任督二脉。

主持人：让我最意外的一点是，很多人都表示，自己已经不再逐行写代码了，而是完全靠 prompt ，然后放手让 AI 去跑。

Steve：不编辑、不修改。整体看，这种“亲手改代码”的成本反而是很高的，甚至会让人觉得不如把 IDE 关掉、干脆卸载算了。其实也不是，后来终于有人说服我了，IDE 其实非常强大，尤其是它的“智能”能力，一定要开着。我指的是 Cradle Build。而且并不是为了 LSP，虽然那也能用，如果你有 MCP server，用 LLM 也是另一种不错的方式。真正关键的是，IDE 的智能自动索引速度非常快，增量构建也快得多，这一点非常重要。

“Claude Code 行不通”

主持人：还有一个点，你说 Claude Code 不行，能解释一下吗？

Steve：当然。Claude Code 从今年三月就已经出来了，也已经被证明是真的能用、能干活的。但现实是，全球大概还有 80% 甚至 90% 的程序员，根本没有在用它，甚至连类似的东西都没用起来。确实有少数公司用得特别猛，但大多数没有。整个世界还停留在 Cursor 上，还停留在 2024 年的水平。

去年我们还在拼命劝大家用“聊天”来写代码，别用补全了，他们就说不行；我们又说模型可以直接生成代码，你复制粘贴就行，他们又觉得这太麻烦了。我们说其实更快，但他们就是不买账。结果九个月之后，大家终于被“渗透”了，然后现在全在说：“我喜欢 Cursor”，可问题是，那已经是 2024 年的东西了，该醒醒了。

但即便如此，他们还是没有真正采用 Claude Code。那你会问为什么？答案其实很简单：太难了，这事儿是要读东西的。

说实话，大多数工程师眼里，五段话就已经算一篇论文了。而用 Claude Code，你要读的不是一点点信息，而是瀑布一样长的信息：生成说明、代码、diff，全都要看。因为一旦你真的把 IDE 放一边，你就必须认真看 diff。

好消息是，当你有了一点经验之后，其实不用逐行读代码，只看 diff 的形状、颜色、长度，你就能判断出很多东西：这是不是需要 code review？是不是方向错了？是不是为了解决一个小问题却改了过多代码？光是 diff 的“形态”，就能告诉你很多真相。但你必须关注它，否则这些问题只会在以后以更大的坑冒出来。

说实话，我自己每天用 Claude Code 十到十二个小时，连续用了好几个月，我还是会经常骂它、被它气到发疯，心里想“你刚刚明明理解对了，怎么还能干出这种事？”这种问题你一定会遇到。不过也有迹象表明，适当给模型一点压力，有时候反而能帮它突破卡点。无论如何，问题一定会有，但好消息是：明年的工具一定会更好。

如果 Claude Code 不是终局，那是什么呢？答案是：我们还是要回到某种“像 IDE 一样”的东西，因为那才符合人的直觉。你得一眼就能看明白发生了什么，而不是靠读大量文本；要有清晰的视觉信号。

但它又不会是传统 IDE，因为 IDE 是为“写代码”服务的，而现在你已经不再主要是写代码了。未来的东西，会是一个 Agent 编排控制台。你早上打开它，就像问一句：“今天情况怎么样？”。这个 Agent 还在跑，那个在调用工具，这个需要你输入一下。你只要顺着列表过一遍就行。

我现在就在做这么一个东西。原本是私有仓库，结果不小心开成了公开的，被 fork 了一堆，也就随它去了，你们也可以玩玩。它叫 VC（Vibe Coder），本质上就是一套已经设计好的工作流，帮你把一堆 Agent 跑起来。

编排革命

主持人：你有没有看到 Google 的那个 Antigravity 项目。

Steve：看到了，真的太有意思了。现在大家发布的这些东西，本质上都在验证我三月份提的那个判断。我当时管它叫“初级程序员的复仇”，还专门画过一张图。后来 Dario （Anthropic 联合创始人兼 CEO）还在各种客户顾问委员会上引用过这套说法，影响其实挺大的。

出处：https://sourcegraph.com/blog/revenge-of-the-junior-developer?utm_source=chatgpt.com

我当时就预测，Agent 编程太难了，未来会出现可编程的智能体编排工具，90%的重复工作都可以交给更便宜的模型来处理。比如遇到“二选一”的问题，让 Haiku 模型随便选一个就行。

所以我当时就说，“编排器”一定会出现。只是这个进程比我想象得稍微慢了一点，差不多到年底才真正跑出来，但整体时间点跟我预测的差不多。现在你看，Replit Agent 3、有 Conductor、还有开源的 DMAD，再加上 Google 的方案，都是不同形态的尝试，但本质是一回事，而且后面肯定还会更多。

主持人：我挺喜欢他们现在这个比喻的：你不用一直盯着 Agent，只要在它们工作的时候给你发通知就行。

Steve：对，正是这个方向。VC 里有个“活动流”，那是我加的第一个功能之一。我的理想状态就是：我去干别的事，只要偶尔收到一些“值得注意的进展”提醒就够了。

主持人：那以后会不会出现“Agent 的社交网络”？Agent 彼此认识、互相关注那种。

Steve：其实已经有人在这么干了。我前几天和Jeffrey Emanuel喝了三个小时咖啡。他是我见过最聪明的人之一，也是写那篇英伟达泡沫文章、直接把股市写崩的人。他后来做了一个东西叫 Agent Mail，本质原因特别简单：他受够了在不同 Agent 之间来回复制信息。于是他干脆做了一个“收件箱”，让 Agent 之间可以直接发消息。现在他只要一句话：“你们自己协调，把这个任务拆了”，Agent 就会自己分工去做。

有人是自上而下地做编排器，试图把一切都包起来；但你看我做的 Beads，再加上他这个 Agent Mail，其实是自下而上的。

主持人：而且 Beads 是纯 Vibe Coding 写出来的，对吧？

Steve：没错，完全是 Vibe Coding。说实话，我每天都会收到 PR，里面全是我之前引入的烂问题，但大家也不太介意，因为现在已经有稳定版本了。

Beads 本身就证明了一件事：你其实完全可以不用亲自看代码，只要你和其他人提的问题是对的，让 AI 去读、去改。现在我收到的很多 PR，很明显就是 AI 做了全部分析和编码。我甚至会把 PR 丢给我的 AI，让它评价“对方的 AI 写得怎么样”。

Steve 曾分享过 Beads 的开发过程：https://steve-yegge.medium.com/introducing-beads-a-coding-agent-memory-system-637d7d92514a

主持人：这样不会很糟吗？

Steve：如果结果是坏的，那当然糟。但 Beads 跑得好好的，还有好几万重度用户，那就说明这条路是成立的。当然，如果你把这种方式用在公司核心生产系统上，把网站搞挂了，那就是灾难。

主持人：但 Beads 本质上还是个数据库系统，数据库可不简单。

Steve：它的架构确实非常诡异，放在过去根本不可能维护，但现在你可以直接跟 AI 说：“坏了就自己修。”哪怕是数据损坏、merge 冲突，它都能修回来。

Jeffrey 那套也是一样，所有 Agent 都在同一个目录里跑，还做了文件预约系统：智能体会说“我需要这个文件”。说实话，这在老派工程师眼里简直是疯了。但一旦跑起来，Agent 自己就开始协作了，就像一个“智能体村落”。

主持人：所以真正的难点不是让单个 Agent 听话，而是让一群 Agent 协同。

Steve：没错。接下来大家都会撞上一堵墙：merge（合并），现在几乎所有团队都卡在了这里。

我认为最有希望解决这个问题的公司是 Graphite，我打算找他们谈谈的。我和 Gene Kim 经常和大企业沟通，我是 SaaS 销售，所以能听到很多大公司的内部情况。他们认为，一旦每个开发者的生产力都提升 10 倍，代码合并就会变成一个极其复杂的问题。

比如你和我同时工作两三个小时，各自做了 3 万行代码的修改，我先合并了代码。我可能修改了日志系统、架构和你正在使用的 API，这时候你的代码就无法直接合并了。这不是简单修复合并冲突就能解决的，你得基于我的修改重新构思、重新实现你的功能，或者删掉你的代码，让我重新做。

但归根结底，这些代码都是 AI 写的。关键是，代码合并必须序列化，得排队。当轮到你的代码合并时，你必须在最新的代码基础上重新做一遍。现在还没有人解决这个问题，这是个巨大的障碍。有家公司给出的临时解决方案你知道是什么吗？一个代码仓库配一个工程师，我可没瞎编。

主持人：传统的解决方案是堆叠差异（stacked diffs），就是合并队列、堆叠差异吧？这是 Facebook 的概念，现在他们想推广到开源社区，GitHub 也在开发相关功能。目前还没有成熟的解决方案，但你必须意识到这个问题，并围绕它做设计。

Steve：当然也有老办法：硬着头皮解决。

主持人：或者提前沟通说，“我要做一个深度架构修改，让我先合并，我们先达成一致的整体方案”。

Steve：是的，我也遇到过几次这样的情况。我试过让一个智能体提醒另一个智能体“我在做会影响你的修改”，就像 Jeffrey 的 mail 工具做的事情。等我把这个功能打通，智能体之间就能互相沟通了，到时候它们只需提醒对方“那个智能体在做影响你的工作，你们最好先达成一致的基础架构方案”。智能体没有 ego，不会争着“必须听我的”，谁先做谁就当领导者。

主持人：你和 Jeffrey 有什么分歧吗？

Steve：我们在一个核心问题上有分歧，即在同一个仓库克隆中让 12 个智能体工作是否可行。我支持用工作树（多个分支）或者多个仓库克隆，把智能体隔离开。他则认为应该让所有智能体在同一个仓库、同一个构建环境下工作，比如一个智能体正在构建、运行测试，这会产生很多冲突。但他有文件预约系统，所以他说“这很疯狂”，但也说服我承认：如果是独立开发者，用不超过 12 到 20 个智能体，这种方式可能确实可行，毕竟他自己就是这么做的。

这和 Beads 的原理一样，放在以前根本行不通，在真正的工程师看来毫无道理，但你只需告诉 AI“出问题就自己修”，AI 真的会修。所以他的系统能运行，因为偶尔文件预约系统出问题时，智能体会说“我们需要解决这个冲突”，然后自己搞定。

主持人：有意思。有人提议明年峰会的主题定为“多智能体”。

Steve：我完全同意。AI 的未来一定是多 Agent。现在我们还处在“用镰刀收割玉米”的阶段，这就是现在“真正程序员”的工作方式。很明显，明年我们就要进入“机械化耕作”的阶段，就像现在农场里的大型机械一样，我们要“工厂化编程”了。很多人从哲学、道德、伦理层面坚决反对，他们习惯了“自给自足的小农经济”，不适应“大型 John Deere 拖拉机”（代表工业化）。但我们确实正在进入编程的“John Deere 时代”。

Claude Code、Amp、Codex 这些工具，我对它们都一样喜爱，但它们也都一样“危险”。我在演讲中说过，它们就像电锯、电钻，高手能用它们创造奇迹，也可能一不小心把脚锯掉。Claude Code 也是如此。

想象一下，有一台大型农业机械，会用 Claude Code，还能检查代码，把“规划、实现、评审、测试”这些环节都拆分自动化，这就是工厂化编程，现在已经有人在做了，必然会成为趋势。它已经开始让非程序员也能参与编程，这彻底颠覆了公司的运作模式。

公司开始意识到，理想的团队规模可能只有两三人，公司的运营方式、治理结构都要改变。因为编程不再是瓶颈，业务人员需要直接参与，反馈循环变得更快。

这是个非常激动人心的时代，但对很多人来说，冲击太大了，他们要么选择逃避，要么在网上强烈反弹。而我敢预测，随着这种能力不断增强、代码真正进入“工厂化生产”，来自既得利益群体的反弹，只会越来越猛烈。

永远不要重写代码？错了！

主持人：你是少数几个能以这种态度提出这个问题的人之一。我知道观众里有不少人对“彻底拥抱这种方式”是持保留态度的，所以这个问题我只能问你这样的人。很多人觉得，这些工具写写前端、应用层代码还行，但千万别碰云基础设施、别碰后端，更别说分布式微服务了。

Steve：有人说“绝对不要动任何生产环境的代码，只是在生产环境使用，且一定要以 Git 作为兜底采用这些工具。你会很想写点什么，但别写。”如果有 Git 做备份，为什么还要担心？

人们觉得 AI 不擅长后端代码。这就是很多人数学不好的问题（指缺乏长远眼光）。ChatGPT 3.5 写系统级代码的能力有多强？说实话，非常差。那是多久以前的事了？但很多人现在还停留在那个认知里。老实说，我认为这里的误解，根源在于一种非常基础的信念：大家觉得模型已经“不会再变聪明了”。

有意思的是，就算模型真的不再变聪明（当然事实并非如此）我们其实也已经跨过了那个关键门槛：就像人类已经发现了电，接下来要做的只是如何把它用起来。即便只用今天这些模型的能力，我们也完全可以走到“代码工厂化”那一步，而且会非常快。我们今年夏天之前就能做到。

但现实是，模型正在以极快的速度变聪明。所以现在有一种有趣的现象：你在为模型“将来才会具备的能力”打造工具，而等这些能力真正被模型“内化进大脑”之后，这些工具本身就不再需要了。

于是，这就形成了一场持续的军备竞赛，同时也是一场工具的持续“衰减”：你的工具负责填补模型暂时空白的能力，等模型自己足够强、能填上这个空白时，这个工具就完成了使命，然后你再转向填补下一个空白。所以现在的趋势就是：所有代码、所有工具都在快速迭代，最终都会变成一次性的消耗品。

主持人：这反而是好事，毕竟工具也更容易构建了。

Steve：没错。说到这，我得提一个人，Joel Spolsky。他二十年前在亚马逊做过一次演讲，至今仍然成立。当时他提出一个金科玉律：永远不要重写代码。但现在我们发现，对于越来越多的代码库来说，直接推倒重来，比修修补补要快得多，而且效果更好，大模型尤其擅长这件事。我最早的体感来自迁移单元测试，与其不断修，不如直接全删了让模型重写，反而一下就完成了。

我们正在进入这样一个世界：最快的方式，是直接写一套更好的新代码，来完成旧代码本来想做的事情。这感觉就像一切认知被颠倒了，但你必须接受这个新世界。

主持人：你说这些话很有说服力，因为你不是年轻人“空谈未来”，而是几乎什么都干过。

Steve：是的。我用汇编语言写了 5 年程序，写过操作系统，做过游戏开发，做过平台，做过广告系统。游戏编程会逼你理解一切。游戏编程教会了我很多，现在再看所谓的 agent loop，和游戏里的主循环、本质上是同一类系统，操作系统循环也是如此。我感觉自己一直在重复构建相同的设计，只是换了领域。

谷歌、Anthropic、OpenAI 内部都很乱

主持人：我想让你谈谈谷歌。我最难忘的一个记忆是，在你退休前，你说谷歌还没“开窍”，尤其是谷歌云，还说他们的弃用政策很糟糕。他们现在好转了吗？

Steve：没有。我和谷歌的人聊过，很多人说“这就是谷歌的风格”。但有趣的是，在执行层面，谷歌已经好转了。他们终于做了 15 年前就该做的事：让员工承担责任，而不是让工程师随心所欲。过去 20 年谷歌都是这样，因为他们在广告领域有垄断地位，有足够的资金补贴工程师“随心所欲”。但最终他们还是得成熟起来，做出正确的选择，这个过程很痛苦，失去了一些谷歌文化，也没那么有趣了，但现在执行效率很高。随着 Gemini 的推出，他们逐渐把重心转向 AI，现在开始看到回报了。他们可能会成为最大的赢家。

主持人：那你怎么看 Google、Anthropic、OpenAI 这些实验室的状态？

Steve：说实话，这三家公司内部现在都非常混乱。Anthropic 把混乱掩盖得最好，这是他们产品经理的功劳，值得点个赞。这并不是因为 Anthropic 自己搞砸了，而是因为在这么快的增长速度下，混乱是不可避免的。

他们接下来要给 Claude Code 一口气招一百多号人，真的是在疯狂扩张。而这还只是 Claude Code 这一块。你要知道，我当年在 Google 和 Amazon 都经历过那种“必须先做大”的阶段，那时候必然是混乱的、动荡的。人们不知道该找谁、该跟谁对接，所有事情都一团糟。但慢慢地，一切会被理顺、会稳定下来，他们也会走到那一步的。

OpenAI 现在也很混乱，甚至更明显。他们经历了很多核心成员的离职。你要说是不是比 GitHub 那种失去大部分资深管理层、连续几年完全动荡的状态还糟，我也不确定，但 OpenAI 现在确实挺混乱的。

至于 Google，我们刚跟一个人聊到，说即便是在 Jules 团队内部，想在公司里达成共识、把东西推起来还是非常难。原因很简单：它太割裂了，像是由无数个小型“单体帝国”组成的集合体，一个个小应用彼此不沟通，导致任何跨公司范围的事情都极难推进。

所以现在这三家，其实都面临执行层面的挑战。我个人觉得 Anthropic 目前可能稍微做得好一点点，但差距非常小，战况非常胶着。接下来就很有意思了，看看 Oracle、Meta，或者其他公司能不能追上来。

主持人：Meta 值得关注，他们明年必须搞个大的。

Steve：明年很可能会成为开源模型之年。一旦开源模型达到 Claude Sonnet 3.7 一个水平，你打开 Klein 之类的东西，就能得到一个体验，至少和三月份的 Claude Code 差不多。虽然不如现在，但已经“够用”了，而且还是在你本地的 M4 上免费跑，真正的免费。

从我听到的情况来看，现在前沿模型大概还有七个月的领先优势，而且这个差距正在逐步缩小。这意味着，明年夏天，开源模型可能就能达到 Gemini 3 的水平。所以明年很可能会出现一个转折点：工具必须在任务拆解、模型分配上做得好得多，知道什么时候该用大模型、什么时候用小模型，才能把成本优化做好。

主持人：我也站在批判者的角度来说，他们认为之所以收敛，是因为模型能力是在逼近上限，提升会越来越慢。

Steve：这不是个小问题，而是一个根本性问题：AI 智力的发展曲线是线性的、指数的，还是趋近于上限的？

我们从一些非常接近研究核心的人那里听到的说法是，过去三十年里，受摩尔定律影响，AI 的“聪明程度”大约每 18 个月翻四倍。他们认为训练数据大概还能支撑两个这样的周期。之后会发生什么没人知道，可能继续上升，可能下降，甚至人类历史直接结束也不是没可能。但两个周期意味着三年后，它们会聪明 16 倍。

说实话，我也不知道“聪明 16 倍”具体意味着什么。但我花了很长时间去想这个问题，我的结论是：它们会变得非常、非常、非常聪明，一定会深刻改变世界，好的坏的都会有。

主持人：那孩子们还要学编程吗？

Steve：应该学 Vibe Coding。

主持人：你始终有一个“逃生口”，你想看代码的时候随时可以看，只是大多数时候你不需要看。但你能看，这本身就是一道护栏。不过我的看法是，不管怎样，如果你还懂一点真正的编程，你会更有优势，因为你的 prompt 更好。

Steve：当说到会编程的时候，但不是学语法，而是你要以一种“语言无关”的方式理解：函数、类、对象、monad 之类的能力边界是什么。你不再关心代码怎么写，但你关心它是怎么工作的。这个层级，其实已经接近产品经理或架构师的思维方式了。

你必须站在那个层级思考，而且你要理解所有工程层面的东西。就像我之前提到的 Jeffrey，他是数学家，自学成工程师，他不一定写代码，但他掌握了所有关键概念，知道 Cassandra 是怎么工作的。所以，就算你不需要亲手写代码了，你仍然需要学习海量知识，才能在这个新世界里成为一个高效的工程师，因为你和机器交互的层级已经被整体抬高了。

主持人：你还有没有什么想吐槽、想补充的？

Steve：我感觉最近“八卦”传播的频率上升了。不是那种“八卦”，而是工程师不断发现新方法、用 agent 变得更高效的那种兴奋感。

比如，我刚知道一个东西叫 Code MCP 之类的。因为 agent 并不擅长直接调用 MCP 工具，它们在这方面几乎没训练，但它们非常擅长写代码。所以你告诉它：不要直接调用工具，写代码去调用工具，它反而做得好得多。这种“小技巧”现在正在不断被发现，特别疯狂。Anthropic 自己其实不是最早发现这个的，是 Claudeflare 先发现的，Anthropic 后来才说“对，你们说得对”。

这也是为什么我特别喜欢把注意力放在 AI 工程师身上。我的观点一直是：AI 工程师是最能把 大模型潜力榨出来的那群人。你几乎可以把 AI 工程师定义为：不是训练模型的人，而是把模型“用到极致”的人。

这有点像一种颠覆式路径：当研究模型、训练模型还是高层次的事情时，当一个“GPT 包装工”显得没什么地位，但随着时间推移，这些人反而开始真正提升生产力，积累真实的专业能力。就像 F1 车手未必会造车，但他们对“怎么把车开到极限”的理解，甚至可能比造车的人还深。

参考链接：

https://www.youtube.com/watch?v=zuJyJP517Uw

本文为《2025 年度盘点与趋势洞察》系列内容之一，由 InfoQ 技术编辑组策划。本系列覆盖大模型、Agent、具身智能、AI Native 开发范式、AI 工具链与开发、AI+ 传统行业等方向，通过长期跟踪、与业内专家深度访谈等方式，对重点领域进行关键技术进展、核心事件和产业趋势的洞察盘点。内容将在 InfoQ 媒体矩阵陆续放出，欢迎大家持续关注。

 

我们采访了无问芯穹联合创始人兼 CEO 夏立雪，他指出，2025 年之前，算力集中于 “造模型”；2025 年起，“用模型” 的算力需求快速起量，尽管单纯扩大模型规模的边际回报递减，但整体算力需求并未下降，行业进入 “高效用模型” 的良性阶段。此外他表示，从企业一号位开始重视 AI 的公司，已在业务流中找到大量落地机会，决策层对 AI 的认知度，是未来企业拉开差距的关键。下面是详细对话内容，以飨读者。

两个代表性模型串联起今年 AI 圈

InfoQ：您眼中 2025 年科技圈的关键词是什么？您会怎样总结自己这一年的收获与遗憾？

夏立雪：我眼中的关键词是“跃升”。我认为，今年 AI 圈发生了非常多的可喜变化，由两个代表性模型串联，也包含了技术和产业两个角度。

第一个转变以 OpenAI 从 24 年底推出的 o1 模型为转折点，象征着模型从单次生成转向多步推理。第二个转变以 DeepSeek-R1 的发布为关键时刻，证明了软硬协同优化的核心价值，可以推动模型性能与应用成本巨大跃迁。而这两个模型不止带来了技术突破，也带动了巨大的产业跃升：一系列推理模型的不断出现使得 AI 能从事的工作越来越丰富，而开源模型（特别是中国的开源模型）站上人工智能舞台中央，大大加速了世界范围内各种 AI 技术的部署和实验，最终促成了行业智能体为代表的各种应用新物种的诞生。

与这个跃升相对应的，人工智能基础设施的关键指标在执行研发任务所需的“性能、资源利用率、算力成本”等基础保障指标之上，新增关注智能体规模化服务的“业务弹性、并发稳定性、可观测性、安全性”等服务效果指标，为这个堪称第四次工业革命的时代做好基础设施准备。

回头来看这一年，我很幸运能见证技术浪潮的重要拐点，而我们的技术路径能在其中创造真实价值，这种体验带来的信心，比任何事都珍贵。同时我也见证了团队的成长——既能沉下心打磨产品、陪客户啃硬骨头，又能持续在复杂的事情里面找最重要的问题，就像写数学公式一样，把最需要找到的核心剥出来，这个过程里，人是最大的收获。

算力需求却没有下降

InfoQ：在您看来今年跑出来了哪些明星公司，以及带来了怎样的行业影响？哪些企业相对落后了？

夏立雪：DeepSeek 是今年公认的明星公司。从生态上看，R1 的出现和它的开源姿态，极大地活跃了 AI 中下游的创新生态，让许多创业公司和开发者，能以更低的门槛获得接近前沿的推理能力，去试验和构建自己应用。

从算力用量上看，虽然整体上单纯扩大规模的回报在边际递减，但算力需求却没有下降。因为如果把模型制造和使用方当作一个整体玩家，你会发现从去年到今年初，基本全部算力资产都配置在了“如何造模型”，今年开始“如何用模型”的算力起量，这也是一个良性的变化。

关于企业的领先和落后，我的观点是 AI 是一个全新的“物种”，每一个行业都有与 AI 紧密合作的巨大机会。而我看到的现象是，在同一个行业中，自一号位开始认真拥抱 AI 的，明显已经在自己的业务流中找到许多落地的机会了，所以决策人的认识是未来拉开差距的关键点。而 AI 还在不断创新，所以我更愿意说这是一场面向未来的、所有玩家都需要边跑边学的马拉松。

InfoQ：根据您的观察，科技公司今年面临的压力如何？对此采取了什么样的应对措施？员工们的状态如何？（可以针对广泛的科技圈，也可以是您所在公司或细分行业公司）

夏立雪：今年的行业压力，更多还是在兴奋与焦虑中负重转向。以 DeepSeek 为代表的推理范式和智能体应用前景的爆发，给大家带来了一些转型压力。这种转型不止是应用产品的迭代，它会牵动整个技术栈、组织架构和商业逻辑的变化，大家都在焦虑自己的速度能否跟上范式迁移的浪潮。

面对快速的变化，一个组织最容易遇到的问题就是决策困难，而我们因为从诞生之日就以“让 AGI 触手可及”为目标，所以在复杂的变化中能够保持冷静和坚定，比较早就洞察到了变化，率先在相应领域进行了布局，这也是创业公司的敏捷性优势，让我们在变局中保持了一定的主动性和节奏感。甚至我们会认为，今年的许多变化都是让通往目标的路径更清晰的喜讯，这让我们信心满满。

在员工状态方面，作为一家身处前沿的 AI 企业，我们看到许多同事展现出极强的适应性与学习热情，积极拥抱技术变革带来的挑战。整体上，团队在对技术未来充满信心的同时，也对工作稳定性和清晰的职业发展路径产生了更强烈的期待——这是一种理性和积极并存的健康状态。

全球在真正生产中使用中国 AI

InfoQ：经过一年竞赛，国内前沿 AI 水平取得了怎样的成绩？是否赶上了硅谷科技公司？

夏立雪：最近 OpenRouter 和 a16z 合作的报告里讲得很清晰，全球对开源模型的使用激增与 DeepSeek V3 和 Kimi K2 等主要开放模型发布相吻合，而且这些增长持续了长时间，说明全球正在真正的生产中使用中国 AI。我们今年也自己出去走了走，体感是高度一致的。

这个时代可以说，是自工业革命以来，中国第一次能够以技术引领者，而不仅仅是追随者的身份，站在一场世界级产业革命的前沿。我们不仅在解决别人的问题，更在定义新的问题、新的赛道和新的游戏规则。

InfoQ：您认为，2026 年的技术赛点可能是什么？您会重点关注哪些行业和技术？

夏立雪：2026 年的技术赛点可能还是聚焦在智能体上，基础设施如何让数字世界智能体在各种场景中规模化落地，以及如何通过云端协同帮助具身智能（作为物理世界的智能体）从实验室走向特定场景的落地验证，是我们会重点关注的方向。

ReScript是一门强类型并可编译为 JavaScript 的语言，最近发布了 ReScript 12.0 版本，完成了为期多年的开发路线图，对编译器工具链进行了现代化改造，并通过改进的语法和性能提供了更佳的开发者体验。

ReScript 12.0 引入了多项重要特性，包括完全重写的构建系统、改进的运算符、支持模式匹配的字典字面量、嵌套记录类型、JSX保留模式以及正则表达式字面量。此次发布还带来了模块化的运行时架构和平台专用二进制文件，显著减小了安装体积。

ReScript 12 的亮点特性之一是新的构建系统，该系统已于去年11月提前推出，具备智能依赖追踪和更快的增量构建能力。新系统现在能更精确地追踪依赖关系，避免不必要的重新编译，并且即使在 monorepo 包之间也能与增量工作流集成。这解决了随着项目规模扩大和 monorepo 日益普及而暴露出来的旧构建系统的局限性，此前的构建系统主要适用于单包项目。

对于仍需使用旧版“legacy”构建系统的项目，可通过rescript-legacy命令执行build、build -w和clean操作。预计该命令将在 v13 中移除。

ReScript 12 最终完成了去年早些时候引入的统一运算符工作。算术运算符如+、-、*、/、%和**现在对int、float和bigint具有一致的行为，编译器可根据左操作数自动推断正确的具体类型。开发者现在也可使用+进行字符串拼接，不再需要过去用于浮点运算的+.、-.、*.和/.等遗留运算符。

ReScript 12 还支持编译为普通 JavaScript 对象的字典字面量，相比Dict.fromArray大幅减少了样板代码。模式匹配也支持字典，可简洁地解构 JSON 载荷和配置对象：

let user = dict{"firstname": "John", "role": "manager"}switch user {| dict{"name": name, "role": role} => Console.log2(name, role)| _ => Console.log("missing user metadata")}

开发者可通过"jsx": { "version": 4, "preserve": true }启用 JSX 保留模式。编译器将直接输出 JSX 语法，而非将其转换为react/jsx-runtime调用，这对ESBuild、SWC或Babel等打包工具非常有用，使其能够应用自己的转换逻辑。此举既保持了与 React Compiler 的兼容性，又确保输出中的 JSX 保持可读性。

从 ReScript 11 升级的团队应查阅迁移指南并预留过渡时间。本次发布包含若干破坏性变更，最重要的是移除了对 JSX v3 的支持、采用新的运行时包结构（以@rescript/runtime取代原有设置），以及 API 命名变更（原先以Exn结尾的函数现在改为以OrThrow结尾）。迁移工具包含一个 codemod，可自动完成机械式的重命名以简化过渡过程。

由于引入了平台专用包（如@rescript/darwin-arm64、@rescript/linux-x64和@rescript/win32-x64），安装体积可以大幅缩小。npm 现在只会安装与操作系统和架构匹配的二进制文件，从而加快安装速度，并减小 CI 流水线中的缓存占用。

围绕 ReScript 12 发布相关的新闻，社区讨论尚不热烈，但该语言仍持续将自身定位为 TypeScript 的替代方案，提供更强的类型保证。在 Reddit 上，有用户评论称这是个好消息，因为他曾以为该项目已经停止维护。也有用户质疑为何应选择 ReScript 而非 TypeScript，一位评论者给出了如下对比：

TS 仍然包含 JavaScript 的所有缺陷，并且其设计本质上是不健全的。ReScript 是用 OCaml 构建的，因此你可能会获得市面上最快的编译器之一，再也不用等待 5 分钟才能完成生产构建。

较早的对比指出，ReScript 的类型系统是健全的，能保证绝不出错；而 TypeScript 的类型系统仅仅基于推测，有时在运行时仍可能出错。ReScript 的编译速度也远快于 TypeScript，尽管 TypeScript 在生态系统采用率和 JavaScript 互操作性方面仍占优势。

ReScript 是一门开源的编程语言，可编译为高效且人类可读的 JavaScript。它最初源自OCaml，现已演变为拥有独立语法和工具链的独特语言。ReScript 在 React 开发中尤为流行，提供一流的 JSX 支持和极速的编译器，可轻松扩展至任意规模的代码库。

ReScript 12.0 Released with New Build System

随着 AI 大模型技术的爆发，应用开发的门槛正以前所未有的速度降低。

为进一步激活 AI 垂类应用的创新活力，微信小程序正式推出“AI 应用及线上工具小程序成长计划”。

该计划将提供云开发资源、AI 算力、数据分析、广告变现及流量激励等全方位支持，帮助开发者将想法快速转化为可落地、可破圈、可盈利的产品，陪伴开发者完成从“0 到 1”的孵化与“1 到 100”的商业跨越。

全方位扶持上线，携手开发者开启小程序 AI 应用元年

过去，许多“小而垂直”的用户需求常因开发成本过高或变现路径不畅而被忽视。如今，AI 不仅重塑了交互方式，更让极速开发成为可能。更令业界振奋的是，随着 iOS 虚拟支付在微信生态的全面落地，过去制约工具类应用变现的“短板”已被补齐，虚拟服务与订阅模式的商业闭环已经形成，这意味着 AI 应用在小程序内“跑得通”之余，也能“赚到钱”。

本次成长计划的激励期为 2026 年 1 月 1 日至 2026 年 12 月 31 日，覆盖了开发、运营、变现等核心环节：

• 免费的云开发资源：微信云开发提供完备的小程序后端能力（数据库、云函数等），支持对接 AI 大模型和 Agent；新开发者可免费创建 6 个月的个人版云开发环境，已有云开发环境的开发者可领取大额抵扣券；

• 免费的 AI 算力支持：激励活动期间，开发者可使用总计 1 亿 Token 的腾讯混元最新文生文模型混元 2.0 额度，以及 1 万张混元文生图模型额度，后续腾讯混元最新的模型也将陆续上架，方便开发者直接使用；

• 免费的数据分析能力 &专属流量激励：运营增长方面，平台免费开放 We 分析专业版一年，帮助团队基于深入数据洞察实现业务增长；同时，在公众号图文发布小程序相关内容并带上 #来微信做个小程序 话题，有机会获得更多公域流量；此外，「微信-发现-小程序」等专属曝光入口，将帮助优秀的线上工具小程序被更多用户看见；

• 更友好的商业化变现：商业化方面，平台将开放安卓、iOS、鸿蒙等全终端的虚拟支付与会员订阅能力，并给予限时优惠费率；同时，支持广告变现“免开发智能接入模式”，无需复杂开发，系统可自动推荐小程序内的广告展示位置并支持实时预览、上线，让变现更加顺畅。

所有线上类应用均可参与计划，包括线上工具、AI 原生及娱乐类小程序等。小程序开发者可以登录「微信小程序后台（mp.weixin.qq.com）-行业能力-AI 小程序成长计划」参与计划，新开发者完成注册后即可参与。

众多标杆案例涌现，小程序成为 AI 独立开发的“第一站”

相比 App 动辄数月的开发周期，小程序独立开发具备周期短、上线快的优势。加上微信内的聊天转发、朋友圈、公众号等社交分发路径，优质产品容易形成口碑传播，甚至引发跨平台讨论，转化率远高于传统的 App。

目前，小程序生态内已经涌现众多极具代表性的 AI 原生应用。例如《猜盐》小程序利用大模型将信息游戏化，吸引用户持续参与问答互动，并实现极佳的用户自发口碑传播；《传图加画框》小程序通过 AI 生图能力为书法、国画、油画等图像作品加框美化，通过 AI 能力为艺术作品增色添香；《风格转换器》小程序凭借 AI 绘画功能，成为微信生态内具有代表性的 AI 生图小程序，不仅用户活跃度高，更成为社交平台刷屏内容的源头；《金攒攒》小程序也凭借着简洁的界面与直观的操作，让黄金的资产管理变得轻松愉快。

此外，如《配音神器》、《写作鹅》、《作文说》等工具类小程序，正在深入视频创作、教育、文字工作等细分领域，展示出 AI 与垂直场景结合的巨大潜力。

在 AI 能力快速迭代的当下，技术门槛已不再是鸿沟，创意的重要性正愈发强化。微信小程序正聚焦于通过资源加码与政策激励为开发者的创意和实践铺平道路，小程序生态正愈发成为 AI 应用快速验证的最好阵地。

“推出成长计划仅仅是一个开始，未来，平台将持续加码，聚焦生态基建，助力每一位心怀创意的开发者将想法变为现实。” 微信团队表示。

1 月 5 日，零一万物正式对外发布了《中国企业智能体 2026 六大预判》，并对外展示了其在企业级多智能体方向上的最新探索成果“万智 2.5 企业多智能体”。

企业智能体 2026 年六大预判

零一万物中国区解决方案和交付总经理韩炜表示，企业智能体正从“单点工具”进化为“智能管理系统”。多智能体架构的本质，是重构了企业的组织形式，让 AI 从“单点提效”转向“全局优化”。这不仅是技术的跃迁，更是组织生产关系的重组。

基于与某世界能源巨头、友邦等多家行业头部客户的 AI 变革实践，零一万物总结出中国企业智能体演进的六大核心预判。

预判一：智能体从“一人一工具”进阶“一人一团队”

过去单点 AI 工具解决的是任务自动化问题，而多智能体推动的是整个企业组织的系统性智能化。

智能体不仅仅是执行单元，更能将公司内部的优秀能力沉淀成可复用、可组合的业务资产。当智能体可以将顶尖人才的能力进行拆解和重构，同时封装成可复用的能力模块，根据实际生产场景进行落地和执行，企业将不再受限于“招聘-培养-流失”的人才循环。一个顶级销售、资深律师、王牌产品经理的专业判断力，可以被高效复制和执行、24 小时运转，在毫秒级时间内部署到全球任意分支机构。

零一万物提出，智能体团队将像水一样具有超强的适配度和延展度：业务高峰期自动扩容，低谷期静默待命。这种“弹性超能力”让中小企业首次拥有了与巨头同台竞技的“不对称优势”。企业应通过多智能体实现业务能力的“软件化”与“服务化”（CaaS，能力即服务），推动整个企业组织的智能化。 

预判二：多智能体需具备 TAB 三要素

零一万物认为，下一代企业的竞争优势，将取决于其将业务能力转化为数字资产的速度。零一万物提出，多智能体必须具备 TAB 三要素：

• AI Team（团队作战）：人和智能体、智能体和智能体之间可以进行智能协同，1 人指挥 1 支智能体团队成为可能，进而突破“人才瓶颈”，实现“能力软件化”的跃迁，让企业摆脱对单一专家的依赖，实现能力的弹性伸缩。

• AI Auto-pilot（业务裂变）：可以根据实际核心生产业务生产场景进行智能规划，过程可控可查，确保交付质量。开启个人业务能力指数级增长，企业业务线容易在垂直深度和规模化增长中找到平衡点。

• AI Business（商业重构）：多智能体流程、产出均可沉淀，通过提取并重构团队能力模块，实现商业模式的原子颗粒度重构，这正是零一万物助力企业在 AI 时代实现“能力即服务”（CaaS）的核心逻辑。

多智能体将企业的核心能力解构成可组合的能力模块，像乐高积木一样自由拼装。

预判三：中国将成为全球多智能体落地的“超级引擎”

中国拥有全球最完整的产业链、全球领先的开源模型、超大规模市场及丰富的复杂业务场景，为企业级多智能体提供了天然的试验田和进化土壤。这不仅是一次“弯道超车”，更是一场“换道超车”。

从底层技术的角度来看，中国模型的开源实践正在推动底座平权。中国在开源大模型领域的全球领先地位，为企业提供了具备全球竞争力的技术基座，降低了 AI 应用门槛，推动技术普惠和生态共建，使得更多企业能够平等、高效地接入智能转型浪潮。

同时，基于门类齐全的制造业体系与超大规模的消费市场，中国有望实现从 “世界工厂”到“智能体工厂” 的跃迁。零一万物强调，中国企业在智能化转型中已不再满足于使用通用模型，而是需要深度结合行业知识、业务流程的“业务级智能体”。

预判四：“一把手工程”是赢取 AI 红利的关键路径

参与企业 AI 数智化转型不是技术部门的单点试验，而是企业战略与组织架构的系统性重构。零一万物认为，单点突破仅是开始，如果局限于“局部优化工程”，反而会制造出新的“数据孤岛”。只有 AI 科技公司与企业的深度共创，全局突破，才能更全面兑现“变革红利”。

这一过程中，需要具备“技术信仰型领导力”的一把手，以全局价值导向克服既得利益，推动 AI 变革。这种“技术理解力”也将成为领导力的新护城河。传统 CEO 可以不懂代码，但 AI 时代的 CEO 必须懂“AI 的可能性边界”。就像乔布斯不需要会写 iOS 代码，但他必须知道“多点触控”能重新定义手机。

零一万物表示，在与头部客户的合作中，“一把手工程”模式的价值已经得到验证，在后续的调模型、找场景、搭应用的落地过程中，FDE (Forward Deployed Engineer)成为承接一把手工程的关键。既懂代码又懂业务，是技术管理复合型人才，像特种部队一样深入一线，用代码解决商业问题，用商业思维优化技术方案。

预判五：智能体反哺推动企业数字基建“自主进化”

智能体不仅是数字化的“消费者”，更将成为企业数据与知识体系的“建设者”。通过自动标注、数据清洗、行为反馈等机制，智能体能在运行中持续丰富企业知识库、优化决策模型，形成“数据飞轮”，并且在未来形成企业“记忆库”。这种自主进化机制将大幅缩短企业从数字化向智能化跨越的周期。

预判六：2026 年将成为企业多智能体规模化“上岗元年”

随着智能体技术成熟与场景深化，2026 年企业竞争的焦点将从“招多少人”转向“指挥多少硅基军团”。多智能体将率先在数据基础完善、业务流程复杂、协同要求高的领域实现规模化部署。相应地，“智能体运营师”将成为企业新兴关键岗位，负责智能体的部署、训练、评估与优化。

对于人类员工而言，决策力成为知识工作者的核心竞争力，具备综合判断力与决策审计力的“复合型员工”将成为人机协同的核心。而对于企业而言，企业的核心竞争力将体现在三方面：早（尽早引入）、快（选用最先进 Agent）和有闭环数据（利用自身数据持续训练）。

“我们不再沿用大厂销售标准化产品的模式”

基于上述六大预判，零一万物万智企业大模型一站式平台（以下简称万智平台）正式升级至 2.5 版：企业级多智能体成为平台的核心企业应用之一，好比 Office 之于 Windows 系统。

据悉，针对企业场景中动态、开放的难点，万智 2.5 采用了“代码先行、模型驱动”的硬核架构。相比传统只会在画布上按照既定工作流运转的通用型 AI Agent，万智平台支持通过 MCP 协议和安全沙箱环境，不仅能确保多智能体执行时切合企业真实生产场景，且能实现工业级的稳定性。

韩炜表示，“零一万物团队与大厂团队模式不同，我们不再沿用大厂销售标准化产品的模式，而是更注重基于客户需求进行梳理和设计，将其转化为产品原型。这对解决方案团队的能力要求非常高。随后，我们会将原型交付给产品与研发团队，以类似 FDE 的模式高效推进，迅速为客户交付可用的演示版本或 PoC（概念验证）场景。通过这种方式，我们持续缩小自身与客户之间的理解落差。

他补充道，以往大厂的产品与客户需求之间存在显著的理解落差，这常常引发交付问题，导致最终成果与客户预期不符，需求范围不断蔓延。这也正是大厂在承接定制化项目或智能体相关项目时持续亏损、意愿不强的原因之一。大厂往往认为此类业务规模效应有限，而零一万物正在积极探索的新模式，能够持续降低交付成本、缩减与客户的沟通差距，并在此过程中寻求可行的盈利路径。这是我们团队的定位以及我所负责工作的核心方向。”

在零一万物的产研版图中，企业级多智能体的实现依托于基模-框架-应用“三位一体”的整合：

• 底层是开源基座模型与行业垂类模型，以及零一万物两年来所积累下的模型训练方法论；

• 中间是企业级多智能体技术框架，负责将模型封装为角色化、工具化、可协同的 Agent 团队；

• 顶层则是面向行业的“超级员工”与解决方案，如 AI 招商专员、AI 保险顾问等，直接对接业务部门并承担 KPI，为企业客户带来可量化的价值。 

整合过往的合作经验，零一万物也为企业客户规划出了企业多智能体进化“三步走”布局：

第一步，确立“一把手工程”下的全局策略。 零一万物认为，AI 数智化转型绝非单纯的技术试验，而是深刻的业务重塑。企业必须由 CEO 亲自挂帅，将多智能体的表现与企业的核心 KPI 深度绑定。在落地初期，便要敢于切入高频、复杂、多部门协作的核心业务链路，以全局视角指引技术与业务的融合。

第二步，引入 FDE 模式跨越组织鸿沟。 针对转型中常见的部门墙与数据孤岛，企业需借助前置工程师（FDE）深入一线“破壁”。这一阶段的关键在于防范系统性熵增，拒绝盲目堆叠智能体数量，而是通过精细化管理，紧盯准确率、响应延迟与 Token 效能，避免陷入“内耗型架构”。 

第三步，通过协同进化跨越技术鸿沟。 企业应摒弃盲目的“榜一模型崇拜”，拥抱开源多模型混合架构。通过夯实目标规划、系统调用、安全审计、多模型协同四大核心能力，企业将构建起稳固的三层架构：以开源及行业大模型为“底座层”，以企业级多智能体技术框架为“中枢层”，最终在应用层孕育出能够真正解决问题的“超级数字员工”。

零一万物技术与产品中心副总裁赵斌强表示，2026 年，企业多智能体上岗的过程，就是将“TAB 三要素”转化为生产力的过程。而这其中的关键胜负手，就在于以“一把手工程”推动技术与组织的协同进化。零一万物的目标，正是基于万智 2.5 开放平台，助力企业 AI 转变为能够持续产生复利、驱动商业模式创新的核心资产，从而在这场以“组织智能”为核心的转型浪潮中，赢得关键加速度。

结束语

对于 Agent 的未来发展，韩炜表示，长期有可能“模型即应用”或“模型即 Agent”最终会实现，就是最终 AGI 的时代，但这个时间线有多长还不确定。从短中期来看模型和应用之间还是有比较大的差别，Agent 有记忆能力、调用工具能力，现在还有通过 Multi-Agent 对抗式分析的能力，这是单一模型可能很难具备的。特别针对企业场景而言，模型不是 Agent，模型只是 Agent 的“大脑”。大脑之外至少还缺四样关键的东西：

一是安全、可控、合规。这个对于企业来说是非常重要的，企业不仅仅关心会不会回答，更重要的是答错了谁来负责，Agent 需要基础于特定的企业记忆（Enterprise Memory），了解企业专属边界。

二是工具和系统的能力。模型本身不会调用你的 CRM，不会登录你的内网系统和下单采购，Agent 必须具备稳定的工具调用能力，去保证跨系统调用的准确率和效率。

三是包括 Multi-Agen 在内的企业级 Agent 里面，特别需要智能体做目标和任务的规划。模型只会天生对下一句话去负责，Agent 需要对业务目标负责，企业级 Agent 需要理解 KPI，比如签单量、周转天数、风险敞口等 KPI 的目标，把这些目标拆解成目标和任务，并且在执行过程当中动态调整计划。

四是多模型、多角色的协同。在真实的企业环境中往往是多模型共存，包括自研模型、开源模型、商用模型等，不同的场景需要选用不同的模型或者不同参数量的模型，没有最好的模型，只有最适合场景的模型，这个可能是比较重要的。企业级多智能体需要做的是根据任务选择不同的模型，可能不同的子 Agent 用不同的模型，包括主 Agent 也用的并不一定是参数量特别大的模型，这是基于实际场景的情况。另外，在多智能体的中分工协同互相校对也很关键。

零一万物认为，AI Agent 颠覆性价值在于行业重构，重点将从降本转向增效。