文 | 字母 AI
离开 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 的完整研发链条，而且都是核心作者。这个履历的含金量不在于项目数量，而在于他参与的是一条完整的技术演进路线。
但 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 上建立同样的优势。
