郭达雅补上了字节最后一块短板

离开DeepSeek的郭达雅，成为大厂争夺的焦点（详见《为什么大厂必须抢郭达雅》）。

如今郭达雅的去向尘埃落定，据晚点消息，字节成为这场争夺战的胜利者。

郭达雅可是AI圈的大红人，网上流传着一种说法，阿里给出了post-train负责人的职位，腾讯和百度也都开出了很高的价码。

可郭达雅最后偏偏选择了字节。

要知道，字节在多模态上已经做到全球领先，Seedance 2.0曾问鼎在各类视频生成排行榜，可郭达雅研究的方向显然和这块有点远。

更让人好奇的是，就算如此，字节还愿意给郭达雅开出接近亿元年包的待遇（对此消息，字节副总裁表示不实）。

答案藏在字节最近半年的一系列动作里。

2026 年初，字节启动了针对 agent 和 Coding 的组织整合。

梁汝波在全员会上说，2026年的重中之重是AI模型能力要做到行业前列。从Trae独立拆分SOLO，再到扣子平台升级到2.5版本。这些动作指向同一个方向：字节在为agent时代做准备。

而郭达雅，恰好是最懂如何让agent跑起来的人。

01

字节有短板

字节的多模态能力很强，吴永辉、周畅、郁博文、蒋路这些大牛陆续加入Seed团队，他们给字节带来了一套完整的多模态研发体系。

但字节在数学推理、代码智能和agent这三个方向上，始终没能建立起明显优势。

Seed 2.0在AIME、HMMT、IMOAnswerBench这些竞赛型题目上很猛，很多分数已经站在了全球的第一梯队。

但是如果往科学推理和开放知识任务上看，你会发现有很多问题。

Seed 2.0在GPQA Diamond上落后于GPT-5.2和Gemini 3 Pro，在SuperGPQA上也低于Gemini 3 Pro和Claude Opus 4.5。

更明显的是SimpleQA Verified和FactScore这类事实准确性指标，Seed 2.0和Google、OpenAI、Anthropic这些企业的高端模型还有不小距离。

这说明它的竞赛解题能力已经很强，但知识稳健性、科学问题里的长链条判断、以及“知道自己不知道什么”的能力，还差点火候。

再看AI编程。

Seed 2.0在Codeforces和LiveCodeBench v6上表现很强，说明算法题和在线编程能力不差。但在SWE-Bench Verified上，它低于Claude Opus 4.5和GPT-5.2。Claude Opus 4.5最高得分80.9%，GPT-5.2 得分80.0%，而Seed 2.0 Pro在这个基准的第三方实测成绩仅为76.5%，甚至还没有入榜单前10。

在Terminal Bench 2.0上，它也落后于GPT-5.2和Claude Opus 4.5。

在Multi-SWE-Bench、SWE-Bench Pro、SWE-Evo、Aider Polyglot这些更接近真实软件工程和长期维护的指标上，Seed 2.0的排名都不高。

这些真实环境的测试很重要。尤其是对于Trae这种AI+IDE的产品来说，能在这些测试里跑出高分，代表你的产品能在复杂项目里不犯错，并且还具备回滚、验证、解释的能力。

最后就是agent。

其实字节不是没有Agent能力，甚至是说Seed 2.0的搜索、使用工具、视觉agent，它都跑出了不错的成绩。

它在BrowseComp、BrowseComp-zh、DeepSearchQA上表现突出，说明Seed 2.0的搜索、浏览和整理信息能力已经非常可以了。

但是，但一旦换成MCP-Mark、VitaBench、SWE-Evo、SWE-Bench Pro这类考验模型长期执行、多工具组合、真实终端操作、复杂软件工程能力的基准，Seed 2.0的表现就不太行了。

这其实也正是agent最难做的地方，你得连续地去理解目标、拆解任务、调用工具、写代码、验证结果、在失败后修正路线。

可问题就是，它不容易发掘。如果说是多模态上的问题，把狗画成了猫，一眼你就能看出来。agent不一样，它是藏在那些又繁琐又无聊的步骤里的。

就拿SWE-Bench Verified来说。这个测试是把真实GitHub项目里的issue交给模型，让它读仓库、定位相关文件、修改代码，再用项目原有测试判断补丁能不能通过。

这里没有哪一步是炫技，全是工程里的脏活累活。

模型如果一开始理解错issue，后面改得越多越偏。如果找对了文件却漏了一个边界条件，测试照样过不了。如果只修当前报错，又引入新的回归，最后也算失败。

agent的难点就在这里，中间你只要错一步，整个任务就会塌。

那数学和代码能力为啥也很重要呢？

因为它们是agent的骨架。

数学推理提供的是长链路上的自洽能力，代码能力提供的是把想法变成可执行动作的能力。

所以郭达雅的加入，补的是底层能力。

字节已有眼睛，有入口，有场景，有算力和工程组织。它欠缺的，是一个能把代码智能、数学推理、强化学习后训练和Agent执行连成一条线的人。

02

郭达雅最擅长的，不只是写代码

郭达雅容易被外界用“代码大模型专家”来概括，这个说法没错，但有点窄。

他的研究总结就是一句话：让模型理解代码也有语法，有数据流，有调用关系，有上下文，还有可以被执行和验证的结果。

郭达雅在DeepSeek的两年多时间里，参与了从Coder、Math等专项模型，到V2、V3、R1的完整研发链条，而且都是核心作者。这个履历的含金量不在于项目数量，而在于他参与的是一条完整的技术演进路线。

2024年1月，郭达雅作为第一作者推出DeepSeek-Coder系列，覆盖1.3B到33B参数的开源代码模型。这个系列在多项基准测试中登顶当时开源代码模型SOTA，不仅能理解复杂代码逻辑，还能高效生成高质量代码。

但DeepSeek-Coder的价值不止于此。它为DeepSeek在代码领域站稳脚跟奠定了基础，更重要的是，它验证了一套从数据构建、模型训练到能力评估的完整方法论。

一个月后，郭达雅主导了DeepSeek-Math的研发。这个项目以DeepSeek-Coder-Base-v1.5 7B为基础，针对数学能力进行继续训练，额外使用了120B数学相关token。

但真正关键的是DeepSeek-Math论文中提出的GRPO算法，让模型对同一问题生成多个答案并相互比较学习，大幅降低了训练成本。

GRPO后来被应用到DeepSeek-R1的训练中，成为R1推理能力飞跃的核心技术，因此让DeepSeek-R1的训练成本低至仅29.4万美元。

从DeepSeek-Coder到DeepSeek-Math，再到R1，郭达雅做的是一套可以迁移、可以复用的技术体系。这个模型可以用，拿出来优化优化，到下一个模型效果更好。

代码能力可以迁移到数学推理，数学推理的训练方法可以迁移到通用推理。这种技术迁移能力，正是字节目前最需要的。

郭达雅加入字节后，担任的是Seed agent的方向负责人之一。这其实也是郭达雅从博士期间就开始研究的方向。他在DeepSeek 期间积累的经验，可以直接应用到字节的agent研发中。

字节在2026年初启动了针对agent和Coding的组织整合。

但它又不是那种单纯的团队合并，字节是准备去建立一套新的研发体系。郭达雅的加入，为这个体系提供了技术基础。

他可以把在DeepSeek积累的代码预训练、数学推理、强化学习这些技术，系统性地应用到字节的agent研发中。

郭达雅的技术路线与字节的业务需求高度匹配。字节的下一代模型重点就是agent能力的优化。

郭达雅从博士时期的CodeBERT开始，到DeepSeek-Coder，再到参与V2、V3、R1的研发，这条技术路线完整覆盖了从代码理解到推理能力的全链路。这正是字节需要的。

更重要的是，他带来的不只是技术，还有一套完整的方法论。

GRPO这个方法的核心思想是让模型自己学会判断答案的好坏，而不是依赖人工标注。到了后来的DeepSeek-R1里，不需要人工标注的推理轨迹，仅通过纯强化学习也能有效激发大模型的推理能力，并自然涌现出自反思、验证、动态策略调整等行为模式。

这套方法论对字节的价值在于，它可以降低对高质量标注数据的依赖，可以让模型在训练过程中自己发现规律。

前面我已经说过了，agent是在跑的时候任何一个环节都不能出错，处理的任务往往是开放式的，很难通过人工标注来覆盖所有情况。

如果能让模型自己学会判断任务完成的好坏，自己学会调整策略，那agent的能力上限就会大幅提升。

郭达雅离开DeepSeek的一个原因是他很看好agent方向，不过当时在DeepSeek内部agent的优先级不高。这才导致他最终选择了字节。

字节则非常看重agent方向，愿意投入资源，给了郭达雅足够的施展空间。

03

未来可能出现的产品，不会只是一款更聪明的豆包

郭达雅加入字节后，最直接的影响会体现在豆包的代码能力上。

字节现在已经有了Trae这个AI原生IDE，也有豆包Code模型，但这些产品的底层能力还不够强。

参考DeepSeek-Coder的性能提升方法，字节很可能会推出一个专门针对代码优化的豆包Coder模型。这个模型不会是简单的参数堆叠，而会在代码理解和生成的深度上做文章。

郭达雅在CodeBERT和GraphCodeBERT中提出的双模态预训练和数据流结构建模，可以直接应用到豆包Coder的训练中。

火山方舟推出了Coding Plan订阅套餐，支持豆包、DeepSeek和Kimi等多个模型，采用Anthropic原生协议，配置简单。

不过目前来看，火山方舟更多的是在做模型接入和工程优化，走的是多模型聚合+工程化优化的路子，还没有形成自己的技术壁垒。

火山的套餐里有一个Auto模式，就是说你发起一个编程任务后，它会根据任务类型、响应速度、模型效果、成本等因素，自动路由到更合适的模型。

这个能力本身有用，但还偏工程优化。它知道哪个模型适合当前任务，却不一定能把这个判断沉淀成模型能力。

郭达雅加入后，它能把Auto模式产生的大量真实开发任务，反过来变成Doubao-Seed-Code的训练燃料。

比如某类前端重构任务DeepSeek更稳，某类测试修复Kimi更好，某类终端任务豆包失败率高。

平台如果能记录任务类型、模型选择、补丁是否通过测试、用户是否采纳、失败原因在哪里，就能形成一个很稀缺的代码Agent数据闭环。

郭达雅擅长的可验证任务，正好可以把这些反馈变成后训练系统。

这样一来，火山方舟的壁垒就变了。

它把外部模型接进来，然后在真实开发场景里持续观察模型、比较模型、训练模型。

别人的多模型聚合，停在分发层；字节的多模型聚合，有机会长出一个自我进化的代码模型。

还有一点，由于火山目前的Coding Plan的定义是面向个人开发者的轻量AI编程订阅服务。所以郭达雅完全有机会带领字节开发出一个企业版的Coding Plan。

但是企业和个人对AI编程的需求差距大很多。

企业要的是旧系统维护、代码迁移、测试补齐、安全修复和内部工具开发。火山方舟可以推出一个类似“代码库医生”的agent产品。

agent接入企业代码仓库后，自动扫描依赖、识别坏味道、补单测、修漏洞、做版本升级，最后生成可审查的PR。

针对大型代码库的长期理解、测试反馈的迭代利用、企业权限与数据安全的合规处理，正是郭达雅的技术强项，他完全可以打造出一款能长期维护项目的工程化agent。

同时，字节在视频生成上的优势，也可以和代码能力结合。

一个可能的方向是视频内容的程序化生成，就像世界模型一样。用户描述想要的视频效果，AI生成一段可以控制Seedance的代码。

这段代码可以精确控制镜头运动、场景切换、音画同步等参数。这种程序化的方式，可以让视频生成更加可控，也更容易迭代优化。

数学推理能力的提升，会让豆包在需要精确计算和逻辑推理的场景中表现更好。

字节还可以推出一个专门针对科研和工程场景的豆包版本，就像OpenAI的Prism一样，支持复杂的数学建模、数据分析、算法设计等任务。

这个版本可以集成形式化证明能力，确保推理过程的严格性。这对于金融、医疗、工业等对可靠性要求高的行业非常重要。

郭达雅的加入，不是简单的人才引进，他体现出来的是字节在AI战略上的调整。字节在多模态上已经做到了全球领先，现在需要在代码智能和agent上建立同样的优势。