110. 逐段讲解Kimi K2报告并对照ChatGPT Agent、Qwen3-Coder等：“系统工程的力量”

摘要

• 本期的核心判断：Agent竞赛的护城河是系统工程，不是idea。 郑博元逐段拆解Kimi K2报告后的结论是，几乎每个trick在市面上的paper里都能找到proof of concept，“现在idea好像都在那边”，难的是把prompt、参数、数据管线每一环调到平稳高质量——“研究员都是老师傅，干的手艺活”。对投资者而言，这意味着团队工程执行力比论文创新更能区分胜负。
• OpenAI的ChatGPT Agent令人失望反而是行业利好信号：研究员"舒了一口气"（问题没被一次性scale up解决，研究方向保住了），创业公司"极其兴奋"，甚至开"斗兽场"demo直播自家agent对打ChatGPT Agent订机票——“我们的agent已经结束了”。 问题够难意味着创业公司融资和产品都还有空间。
• 环境（environment）正在成为新的scaling范式和成本瓶颈。 博元的推演：若RL真的work，“接下来大家的一个重心可能就是不断的去造这种environment，在这基础上生成大量task和verifiable reward，作为一种新的scaling的范式”。真实环境交互超级贵：一次deep research粗略估计约100-150次搜索调用、10万条rollout仅浏览器交互就要几千美元、跑web agent会把实验室IP封掉——这正是Browserbase这类云浏览器公司B轮融资的商业逻辑，Kimi用Kubernetes、千问在阿里云上部署了2万个并行沙盒来解这个题。
• 数据墙的潜在解法是agent本身变成data engine：预训练数据"基本上快被用完了"，但agent每轮与环境交互都在获取新信息；K2手动从GitHub的pull request和issue搭沙盒做RL训练，博元的畅想是让agent自己爬网页、自己找到reward environment，实现self-improvement——“让它自己去训自己”，目前可能还没有人在做，是一个非常有意思的研究方向。
• 应用公司走Manus的context engineering路线经济账清晰：不训模型、靠in-context learning快速迭代，核心是围绕KV cache优化——使用KV cache的成本"三毛钱"对"三块钱"，10倍价差会影响agent产品的成本结构；前缀保持稳定、只追加不修改、mask而非删除工具，都是围绕这10倍价差的工程纪律。
• 落地时间表：coding agent"已经爆发"——“我和我的朋友们代码自己写的越来越少了”；tool use应该也会很快，browser/computer use的infra仍有难度。 设想是每人背后"有一个军团在帮我做事情"：Claude写代码、ChatGPT润色、Gemini读长文档、DeepSeek提尖锐建议——“嘴特别臭，但说的观点非常的鞭辟入里”。
• Agent安全被低估且有真实商业含义：博元的agent真的在特斯拉订了试驾（“你是时候来提车了”），放大一千个agent就是"智能化的agentic DDoS attack"；他的guardrail方案——高影响action先停下让user确认——本质是把伦理责任归到用户一方，“对agent商业化会相对更安稳一些”。

精读

1. 两年研究主线：把agent真的做出来

• 嘉宾郑博元是俄亥俄州立大学三年级博士生，研究language agent，目标是让agent"学会操纵电脑或者操纵浏览器，起到一个助理的作用"，即computer use agent。他的路线图是一条完整的技术演进链：先解决感知（早期单模态模型只能读"非常冗杂"的HTML，后转向理解GUI界面），再解决grounding（agent能用语言描述下一步action，却"并不能把这个action很好的转化成一个可执行的操作"），再到长程规划——提出用language model内部的世界模型辅助规划，目前在Ai2实习研究大规模强化学习。
• 他的学术起点有戏剧性：本科硕士做NLP信息抽取，“ChatGPT出来的时候，整个研究就发生了很大的变化”——研究方向随之发生变化。他的转向逻辑：既然language model已经是"人类语言和它的意图之间一个很好的界面"，就在此之上做更难、对人更有帮助的事。

2. Agent的定义：有没有环境，是与LLM的分水岭

• 博元给的定义框架：现在的agent都基于language model构建、用语言做推理和规划的载体，所以先叫language agent；它与language model的核心区别"就是这边是否存在一个环境"——两件事：perception（感知环境）与生成并执行action影响环境。
• 范式差异具体化：LLM是input进、output出、过程结束；agent则是循环——从环境获得observation（coding agent看到的是整个code base和执行记录，computer use agent看到的是GUI截图或HTML），连同task和历史交互一起作为input，生成action、执行、环境状态改变（页面刷新、代码报错要debug），周而复始。

3. 四类agent：coding最成熟，RPA产业可能被一键化冲击

• 按应用场景分四类：coding agent（Cursor、被收购的Windsurf）最成熟——博元的体感是"像是不停的有很多实习生在帮我写代码"，能同时开三五个界面并行做任务；search agent（OpenAI deep research、Gemini同类产品）做大规模检索生成report，利好市场调研；tool use agent（Kimi K2、Qwen3-Coder强调的场景）；computer use agent（ChatGPT Agent、Operator）。
• 值得注意的产业判断：computer use agent做的事与传统RPA流程自动化（如Salesforce）重叠，过去需要大量工程师手写workflow，“现在可以用一个agent完全一键化自动的把这个过程全部完成，所以对RPA这个产业也可能会产生一些影响”。
• 建模视角的统一：各类agent的主要区别在observation space（code / text browser / GUI browser）和action space（写代码 / 点击输入）不同。

4. 两条技术路线：Manus的in-context learning vs 端到端训练

• 几家方案的最大分野在Manus与其他三家之间：是否利用模型的in-context learning能力，还是end to end重新训一个agent。Manus"非常精细的利用好了language model in-context learning的能力"，可能不太涉及模型训练，靠调prompt和设计multi-agent系统快速迭代出可用产品——比如写网站时让不同模型扮演产品经理、写代码的agent（“现在大家一般会拿Claude”）、专门debug评判的agent。
• 端到端路线的取舍：若有明确场景（coding、browsing）且能大量获得reward signal和训练数据，端到端训出的agent"在某个特定场景上会非常强大"；但multi-agent场景下端到端很难——多agent交互轨迹极长、每个agent有自己的角色，“我们就很难分清楚最后这个reward应该是属于哪个agent的”，训练信号无法传导。这是credit assignment的真实工程约束。

5. ChatGPT Agent发布后：研究员舒了口气，创业公司开起了"斗兽场"

• 博元刚从ICML回来，社区反应按身份分层。研究员"有一种舒了一口气的感觉"——他们一直提心吊胆OpenAI或Gemini通过scale up RL training"一次性把这个问题变成一个well solved的问题"，这种事发生过：2022年ChatGPT"把NLP的很多小方向给干掉了"（包括他自己以前的方向），GPT-4V又冲击了多模态研究。这次似乎没有发生，“里面还有非常大的空间可以去探索”。
• 创业公司则"极其的兴奋"：有人做了斗兽场式demo，屏幕左右两框、像足球解说一样让自家agent与ChatGPT Agent同做flight booking任务——“ChatGPT Agent现在还在完成这个操作，但是我们的agent已经结束了”。博元点破其中门道：靠收集领域数据和特定prompting很容易让agent擅长单一任务；但问题难解、探索空间大，“对他们融资或者是产品都会有一定帮助”。

6. K2为何激起水花：时机、定位、以及"一个完全开源的小ChatGPT"

• 三个原因叠加：release时机"真的非常非常好"，是较早明确以agent能力为主打的模型，paper标题直接叫open agentic intelligence，撞上agent热度；更根本的是模型本身够强——预训练数据积累加训练算法成熟，博元的使用体感是"一个完全开源的小ChatGPT"，大家免费拿去写网页前端等小应用，“会发现它效果确实很不错”。

7. Agent安全：特斯拉试驾、一千个agent的DDoS、以及责任归用户

• 博元的亲身案例是最好的教材：一年半前他做SeeAct（音，likely SeeAct）——当时市面上最早真的在live website上跑起来的web agent之一，demo任务是在特斯拉门店订试驾，“这agent它真的做成了”，圣诞节时特斯拉不停发邮件：“你是时候来提车了”。单个无害，但"假如我们开的不是一个agent，而是一千个agent"都给同一家门店发请求，“那这可能就是一种智能化的agentic的DDoS attack”。
• 失控的日常版本同样危险：让agent买咖啡机，“一个不小心就下单了一吨的鲜肉，或者是买了一千杯咖啡”，或给别人发了粗鲁的邮件。deep research类只读不写"完全没有问题"，operator类"实实在在的在影响这个世界"。
• 他刚release的论文方案是建guardrail：agent执行action前先判断对世界的影响多大，足够大就停下来提醒user确认——“只要这个user他approve这个事情，那么责任就会到user这边，这对让agent商业化会相对更安稳一些”。类比自动驾驶：既保安全，又解伦理。

8. 训练agent与训chatbot的两大不同：轨迹数据和RL

• 两个支柱：一是大量synthetic trajectory data——observation、action、environment feedback相互交织的agent风格数据，这类数据在自然预训练语料中占比很小，“不足以构建一个足够强大的agent”，必须合成或人工标注；二是强化学习，博元认为这是可能更容易scale up的方案——只需要一个task加一个verify reward，让agent自己探索尝试，“更容易去做大量的scaling up这个compute”。

9. K2的三条contribution：优化器、数据合成管线、RL框架

• 第一条是Muon优化器——Kimi很早尝试Muon做训练，“training curve看着非常的优雅”，博元评价这种innovative尝试"非常值得尊敬，非常牛"，但优化器与agent能力垂直，本期略过。第二、三条才是agent核心：large scale的agentic data synthesis pipeline（仿真加真实世界双轨生成tool use数据），和一个general的RL框架——verifiable reward与self-critique rubric reward结合。
• 博元点出一个正在成形的行业趋势：Scale AI最近发了Rubrics and Reward的paper、标了大量数据，数据标注的新范式可能正从"标SFT的input-output对"转向"标task加rubric加verifiable reward"——这对数据标注产业是结构性变化。

10. 数据快用完了，但agent可能是新的data engine

• 背景是众所周知的plateau：“整个互联网的数据基本上都被爬光了”。但博元给出一个反直觉的乐观论点：agent范式不是封闭系统——与RLHF只训preference不同，multi-turn RL的agent每轮交互"都在观察新的数据"，如果有办法把交互获得的信息整理成knowledge（抽取有用的procedure或fact），agent本身可能成为新的data engine，反过来empower language model。他自己标注了不确定性：“这个还是在探索，可能不一定特别严谨，但是我觉得是非常exciting的研究方向。”

11. 重写数据的手艺：壁炉前喝咖啡不能变成吃烤肉

• K2用K1.5对现有数据重写做增广。知识型数据（维基百科、书本）用style and perspective diverse prompting——一大堆prompt控制重写的风格和角度换取多样性。但重写会引入幻觉：“就算只是重写一个文章，它可能一不小心把里面一个知识点给改掉了。“博元的比喻：像让中学生复述一万字的小说，“人物在壁炉前喝咖啡或喝茶，我可能就不小心写成他在壁炉前吃烤肉”——小错误进了预训练数据，模型幻觉就会更严重。
• 两道防线：chunk-wise autoregressive generation（把长文切块逐块重写，短文更易控制知识一致性）加fidelity verification（再拿一个模型比对重写前后有无常识性错误，把错的去掉）。小珺插问长context是否"影响智商”——博元认同：Lost in the Middle（Nelson等人的paper）早就发现context长了performance受损，agent交互步数多了之后"整体上会变得笨一点，它可能记了太多东西，在内耗吧”（他自己标注这是"意识流的开玩笑性的说法"）。
• 效果有硬数字：SimpleQA上，同一份Wikipedia数据不重写训10遍得23.76的accuracy，重写一遍再训涨了很多，“重新写十遍"全部混着训效果进一步提升——且paper称该recipe在很多dataset上都work。数学数据则重写成learning notes格式（沿用一篇数学重写论文的方案，名称可能是SolaMath），博元的类比是费曼学习法：“学完之后再教别人，一旦把别人教会了，那我们可能就真的学会了。”

12. 架构照抄DeepSeek V3：开源等于免费雇佣一大批工程师

• K2架构"基本上在沿用DeepSeek V3”，知乎上团队作者说明做过不同尝试，但发现V3"本身是优化的比较好的一个架构"，只调了expert数量、attention head和dense layer等超参。博元指出沿用的隐性红利：vLLM、SGLang等开源推理框架已对V3架构做了大量优化，直接follow意味着自己inference也更高效——“就会有大量的来自世界各地的PhD博士们自发的去优化这个架构，就感觉像是免费雇佣了一大批的工程师”。这是开源策略的真实经济学。

13. Post-training数据合成的第一性原理：diversity

• K2团队反复强调核心是"一定要把这个data变得足够diverse"。博元用自己的实验经验佐证：让language model在一个website环境里自己propose任务，“很快它的diversity就受到了上限”——因为本质是用模型自身的prior去sample task，观察到的数据又有限。整个合成管线的每一步设计，几乎都是围绕突破这个diversity上限。
• 管线第一步是造工具：从GitHub收集3000多个MCP工具。博元插入背景：MCP（Anthropic提出的Model Context Protocol）统一了工具接口，此前直接call API"各种参数、接口都不是统一的"，要花大量精力做工程化处理；且新出现的MCP工具"或多或少本身都带有应用场景"，质量比凭空爬API更高。
• 第二步系统性进化：paper里t-SNE可视化显示原始工具分布"非常的稀疏"，于是用hierarchical domain generation（引用WizardLM的合成方案）扩充到两万多个工具。博元诚实标注了paper没写清的地方：所谓tool synthesis究竟是从头生成MCP还是对现有MCP做组合重写接口描述？“根据context还有cite的paper，我的猜测应该是对原来的MCP进行了一定组合”——并邀请听众自己读paper留言讨论。

14. 造场景、造角色、造评分标准：在数据合成里逼近下游应用

• Agent diversification：生成大量system prompt在不同场景创造各种agent——有的擅长写代码、有的擅长数据分析、“有的情商比较高”。博元的解读：从两万个MCP里随机抽十个组成小环境，加上角色定义，“本质上是在为下游用户的应用场景创造应用场景”，让数据合成不停逼近真实使用；同时角色扮演也是diversity保障——笼统地让模型"使用工具"，生成质量远不如给足context让它知道自己的role。
• Task与rubrics同时生成：rubric是文本化的完成标准——成功条件、预计的tool调用模式、evaluation的checkpoint。同时生成的方案"从实验效果上来说一般会更加准确一点"，因为出题时就能预测评分标准。还做了simple to complex的难度递进。这些rubrics后面用于筛数据：不能保证每条轨迹都成功，就拿rubric让模型判断task有没有完成，“成功了就把数据拿进去，不成功就改写或者直接扔掉”。

15. 轨迹生成：persona模拟用户，simulator"等价于一个world model"

• User simulation用LLM生成persona——律师、厨师、产品经理各有不同的交流方式和完成任务的偏好，“通过这种方式也是在模拟下游的应用场景”，同时逼着LLM生成轨迹时与各种communication distribution交互，又是一层diversity。博元指出用persona提多样性"在很多地方也都出现过，从实验上来说确实是一个很好的方案"。
• Tool execution environment是paper最模糊处：K2说建了tool simulator，“equivalent to a world model”。博元给出两种猜测——真拿训好的神经网络当模拟器提供执行结果，或建本地沙盒；“根据描述倾向于是前者，但这样的话，不管怎么优化这个world model，它跟真实世界会有很大的出入，会产生一些噪音”。所以K2采取hybrid approach：仿真数据加真实环境交互数据结合。他再次把不确定性交给听众：“大家也可以去看一下这个paper，给我们留言。”

16. 与环境交互超级贵：IP被封、云浏览器的生意、造环境即scaling

• 博元认为学界"一定程度上低估了跟环境交互的价格，但实际上它是超级贵的"。算账：deep research场景粗略估计约100-150次Google Search API调用，就算一分钱一次，乘上RL训练所需的大量rollout就是大数字。Browser侧更贵：真实网站上跑web agent，“我的公寓、我的实验室、学校cluster的IP都被跑封掉了，很多做web agent的朋友都反映过”；解法是云浏览器（如Browserbase，B轮拿了不少钱），自带IP池和防封工程，“但这个收费就特别贵”——粗略估计100K的rollout光交互就要小几千美元。本地开Docker沙盒则CPU和memory消耗巨大。
• 小珺的类比：机器人领域真人数据只占1%、仿真占99%。博元接住：“机器人可以作为environment interaction成本的一个极端案例”，digital agent成本低一些但仍然很高。由此引出他的关键推演：“如果RL真的非常work，接下来大家的一个重心可能就是不断的去造这种environment，在这基础上生成大量task和verify reward，作为一种新的scaling的范式。”

17. 系统工程大于idea：老师傅的手艺活

• 小珺追问：“这里面应该是工程能力的需求比较多对吧？“博元的回答是本期题眼：K2"非常实在”，所有recipe和小技巧都放在paper里了，“但是假如我们真的要把它做出来，以一种很高效的方式把它做出来，本身可能还是很难的”——每个部分调prompt、调参数、保证平稳运行，“本身是一个非常大的工程量，像是一个手艺活”。小珺总结：“所以研究员都是老师傅，干的手艺活。”
• “系统工程大于idea对吧？"——博元确认，并给出更结构性的论断：K2作者把每个trick的出处paper都cite了（WizardLM、AutoIF等），“很多idea其实在市面上都已经出现了，大家都已经在小范围内做过验证，像是一个proof of concept”；LLM这个系统工程要做的是把trick结合到一起、放到大规模下验证。“甚至我自己能感觉很清楚的是接下来需要做什么事情，但是每件事情都需要大量的工程把它效果做好。”

18. RL的两类reward：可验证的，和rubric自评的

• RL部分的总纲是scale up RL：大量获得diverse的task和verifiable reward做大规模训练。博元划分两类任务：一类是verifiable的经典类型——数学和代码，DeepSeek R1（音）和OpenAI o1这一波最早做出效果的方向，特点是"结果对不对，能够非常容易的通过一个简单的程序或函数判断清楚”——数学核对答案，代码跑unit tests，“像写力扣那种测试”。
• 另一类如creative writing、开放式问答，“很难找到一个方案直接客观的评价”，于是引入self-critique reward——让模型自己判断回答质量作为reward。K2最终是两个方向结合的reward体系。

19. 难度是个精细活：太容易学不到东西，太难信号稀疏

• 数学/STEM/逻辑任务要求diverse coverage and moderate difficulty。难度设计的逻辑博元讲得透彻：task太容易，“每次尝试都是成功的，能获得的signal就非常的少”——像高中刷全对的简单题学不到东西;太难则"回答一百次两百次可能就一次成功”，reward稀疏，且"假设这个batch里所有rollout都是失败的，模型优化时根本不知道往哪个方向优化是对的"。操作上很朴素：拿没做过RL的模型先试同一个问题k次，按准确率筛选，尺度"应该会随训练过程不断调节"。
• 他指出一处宣传与paper写作的微妙出入：OpenAI不停强调"easy to verify but hard to answer"，千问也强调要非常difficult，而K2要moderate——他的调和：难度"取决于base language model本身能力，是case by case的问题"。

20. Instruction following与反reward hacking层

• Agent任务对instruction following的要求陡增：要不停和环境交互、调整action，同时"和最初给的task和system prompt保持一致"，且context随交互次数变得超级长。K2的verification是hybrid：先用code interpreter按长度、文本风格、constraint做规则校验，再叠一层LLM judge——paper明说这是防reward hacking的layer。
• 博元把reward hacking讲成高中生作弊：“agent足够强大之后，它可能会变得非常的狡猾”——像做题猜对了答案、“中间推理过程就乱写”，发现cheat能得分后不断往上overfit，“training效果就会变得很糟糕”。数据侧是三步管线：human expert标复杂指令任务（贵、难scale），用AutoIF（千问之前的paper）从种子任务自动拓展，再用反调的模型生成专门涉及失败案例和edge cases的指令，把复杂度做上去。

21. Faithfulness入reward：K2在幻觉榜排进前十左右

• 模型"有时候其实会胡说八道"，甚至输出的thinking process跟最后答案"可能没有那么大关系"，所以K2把真实性也做进reward：用Fact Grounding（Google的paper）做sentence level的事实判断，直接加进reward。博元的元观察值得记下：有些paper单独看只是一个fact verification任务，“但假如把它放到language agent RL training这个范式下面，它会有额外的意义——它可能是一种调整模型behavior的方式”。
• 他去查了K2在幻觉榜单上的分数：“排名排的还是挺高的，在所有模型里面应该是前十或者十名左右的样子。有可能是这个tricks起了作用。”

22. Coding RL的核心：把GitHub的PR和issue变成带reward的沙盒

• 两路数据：competition level的编程题（力扣、代码比赛），以及更关键的——在GitHub上收集大量pull request和issue，取该时间点的code base搭沙盒，“把它的pull request内容和最后的solution当做verifiable reward的结果”，配合unit tests大规模scale up软件开发场景的task。博元认为"这可能也是它RL能力的一个核心"。
• 由此他展开全场最有野心的brainstorm：agent能不能自己主动找到reward signal，自己去训自己？web agent本可以在网络上自己爬、自己探索，“一不小心进了这样一个GitHub repo，发现我有这样一个verify reward，自动把数据拿过来、自动搭一个sandbox environment”——就算不能全自动，也可用agent做exploration再由工程师筛选。“这样的话可能能够实现agent的一种self-improvement。“他如实标注状态：“目前可能还没有人在做这个事情，但是我觉得是一个非常有意思的研究方向。”

23. RL训练细节：短回答、防遗忘、退火

• Budget control：不希望agent在无关action上过度thinking，response太长直接截断加penalty。博元关联到真实体感——知乎上有人说Kimi的回答"倾向相对比较短，相对有点简洁，最后还会很贴心的写上一个summary”,“我觉得可能跟这个reward是有相关的”。K1.5用过更复杂的长度reward（又短又对），“这次Kimi K2就有点返璞归真了”。
• PTX loss防灾难性遗忘：RL专注学take action时，“预训练阶段很多重要的知识它可能会丢掉”，于是从预训练数据里sample高质量样本混进RL training。Temperature decay：训练早期模型弱，给更大的探索空间生成多样化action——“只要有positive reward就鼓励”；后期行为平稳后逐渐降温收敛，“像有个退火的阶段”，保证训练平稳。

24. Agent rollout是infra的新考题：长尾轨迹与GPU空转

• 博元特别强调3.4节agent rollout：现有训练框架的scheduling是为RLHF这种latency平稳、少多轮交互的rollout设计的。Agent完全不同：一是交互延迟不稳定——browser"突然卡了一下"甚至崩掉，GPU就挂在那儿；二是长尾——同一batch里"256条rollout，250条在五步之内就完成了，假如花三分钟，但剩下6条可能需要花十分钟”，大量GPU时间为长尾空转。
• K2的对策组合：特别heavy的环境单独包装成service暴露API、单独给算力；超发concurrent rollouts——“我最后可能只需要64条，但一开始同时rollout 640条，只要完成了64条就把过程结束”；对长尾轨迹做partial rollout，直接卡死、下一轮RL iteration再恢复。博元点出这个方案的隐患：恢复的rollout"并不是当前模型的策略产生的action"——上一轮模型会犯的错，参数更新后已经不犯了，但buffer里的旧轨迹"看起来我这个模型还会犯错"，拿它更新参数会产生问题。
• 代码层面沿用OpenAI Gym（现gymnasium）的接口范式——环境交互封装好，对外expose step和reset，“大部分RL training的code在我看来基本上都是沿用了这一套”。K2表示后续想把RL infra扩展到更diverse的交互环境，博元希望能包括browser和computer use。千问3 Coder在阿里云部署大量沙盒、ChatGPT Agent用大量virtual machine，“两边基本上是解决了类似的engineering上的问题”。

25. ChatGPT Agent：把Operator和Deep Research的action space合体

• 博元结合release博客和团队与Sequoia的访谈解读：本质是把Operator（擅长理解GUI、操作web page做navigation，但找大规模文本信息未必最强）和deep research（基于text browser做大量search和URL点击、总结信息）的action space unify到一起。实现有两种猜测：multi-agent系统靠end to end的reward signal黏合，或单一agent统一action space端到端训练；“我目前感觉更像是只是把action space unify到一起，而不是做一个multi-agent的系统，但这边没有明确的信息。”
• 训练数据一侧，他展示了BrowseComp类信息检索数据的样子：任务描述有一个描述、答案却"只是找到plastic man这样一个很简短的答案"——信息必须非常难找，但reward极容易给（比对答案是否一致即可）。“有点像我们做题的时候给自己出一个比较难的题，但是我们有办法知道这个答案。“这与verifiable reward的哲学一脉相承。
• 但他指出computer use训练的更大难题：BrowseComp式information seeking容易verify，可一旦任务是下单产品、查机票这类操作型任务，“在大部分网站上我们是没有办法获取后台数据的”，verification就难了；小规模沙盒可以拿到后台数据，“但如果真的要scale up，可能我们需要一些非常高明的方式去获得这种verify reward”。
• Benchmark上的妙语：Humanity’s Last Exam分数被提得很高——“它的名字叫人类最后的测验，但是现在看着效果这么好，它可能也不是人类最后的测验，它可能是人类倒数第二个、第三个。“FrontierMath分数不高但相对baseline提升很多；各项evaluation（做PPT、spreadsheet、data science）“基本上都对应着一个真实的用户应用场景”。

26. Qwen3-Coder：没有细节的报告，和失宠的leaderboard

• 千问3 Coder只放了博客，“没有细节，我很想看细节”：data synthesis只有一句话，大量笔墨在scale up RL和"hard to solve but easy to verify”，加上两万个独立并行环境放在阿里云上。博元对学界的提醒：“开这么多session本身是会有一定成本的，学界可能也需要有足够多的engineering能力去把这个事情做出来。”
• 对榜单文化的观察是本段的signal：“现在这个leaderboard好像大家也不怎么看了，它可能并不能完全反映model的performance，大家现在更在意的是使用的体感”——以及OpenRouter的真实调用排名，千问3 Coder在上面确实很高。相比K2，它增加了agentic browser use评测：Mind2Web（博元自己组的工作，真实网站上标注大量轨迹，考验对各种网站的泛化）和WebArena（网站沙盒、可查后台数据库做精准evaluation），“performance确实是挺不错的”。
• 另一个common practice：发模型同时发CLI工具（与Gemini CLI对接、提供VS Code插件）——“这些模型不只是单纯训模型然后刷榜秀肌肉，而是真的在实际生活中应用到了各个场景”；且若能收集用户与agent的交互数据，“也许能用这个进一步再去改进这个agent本身”。

27. Manus的context engineering：一切围绕KV cache的十倍价差

• 博客作者（Peak）也是从BERT时代过来的——那时模型没有in-context learning能力，下游任务必须SFT；ChatGPT之后"单纯通过语言的描述就可以让language model泛化”，所以Manus当初在end to end training（“确实是非常贵”）与context engineering之间选了后者，快速迭代出产品。
• 核心思路是围绕KV cache优化。博元先补技术课：transformer的attention里，前文不变则KV矩阵可以复用不必重算，inference更快更省钱——命中cache"三毛钱”、不命中"三块钱”，十倍差距。由此推出工程纪律：prompt前缀保持一致不要动；context只追加不修改中间内容；工具不用了mask掉而不是删除（“mask, don’t remove”），生成时让模型不管它即可，“又是一个巧妙的使用KV cache的小技巧”。
• 另外几条经验：用file system as context外置存储，但context越长模型越笨，于是用todo.md去manipulate模型的attention，把注意力拉回目标；模型犯了错"还是把它放到context里面"（保留failure）；few-shot示例要足够diverse——不然模型"倾向于不停的重复前面的内容"，浪费token产生无用生成。

28. 从context engineering到agent memory：需要一套增删改查

• 博元的延伸：这本质上与memory相关，而agent的memory需要区别于chatbot——chatbot的聊天数据是非结构化的，agent的交互（action、observation、environment feedback）“是非常高度结构化的"且轮数非常长。他的主张：需要一个能高效增删改查的结构化memory机制——新action有用就插入、执行后相关记忆要修改就改，“保证这个agent系统能高效运行。这边目前还需要更多的研究。”

29. 研究展望：self-improvement与被浪费的rollout数据

• 两条研究主线。其一是前述的self-improvement：让agent自己在网页上take action、自动找到可训练的reward environment。其二是rollout数据的复用——当前RL范式里"rollout过程里面有很多数据其实我们没有把它很高效的用起来”。他举自己的工作SkillWeaver为例：让web agent在新环境自己propose任务（在航班网站上订航班、搜信息）、自己探索执行，用reward model模块判断是否成功，成功的轨迹转变成一个API——随机拿一个网站就能自动生成大量API，inference时agent不再一步步过模型生成action（“特别慢”），直接调API快速执行。“agent的exploration过程里面有大量有用的数据或知识，也许可以有一种方式把它们积累起来，进一步提升agent或language model自己本身的能力。”
• 应用侧的飞轮：coding agent"基本上每天都跟人类混迹在一起"，用户修改agent的代码"类似于给它提供reward"，人类用户就像annotator。他联想到两件事：Murati团队（likely Thinking Machines Lab）提的research-product co-design，以及Windsurf收购案——“被收购方想要的点，也是他们积累了大量的user和agent的数据”，不管拿去改prompt还是训agent。

30. 交互的未解题：用户的指令大部分是含糊的

• 博元的自我观察：“我发现我的指令大部分情况下其实是非常含糊的。“案例：让agent找一百元以下的咖啡机，结果种类太多、“我也不想让他随便给我买一个”——agent应该学会在信息含糊时主动提问（颜色、牌子、其他需求），把需求变确定再完成任务，“不断的主动的跟user解决这个ambiguity的问题”。他认为coding agent这点已经做得很好：“我有时候写代码，一开始我自己也不知道要写什么东西，agent会不断的跟我迭代，最后我终于明白了自己想要写什么东西。”

31. 人与agent的共生：每个人背后一个军团

• 小珺问人与agent最终构成什么网络，博元的回答是本期最生动的画面：“agent是我的另外一个大脑，一个拓展的大脑……我做日常做事情的时候，背后有一个军团在帮我做事情。“分工已经成型：coding交给Claude，polish paper和writing是ChatGPT，Gemini因为long context特别强、负责整理一堆文档；而需要"非常尖锐、非常刻薄的建议"时用原生DeepSeek——“DeepSeek那个有时候嘴还挺臭的，但是他说的话、他说的观点非常的鞭辟入里”（他猜测"可能是训练数据中有很多贴吧的数据”）。“以后每一个人都可能会有一大串的family of agents。”
• Chatbot的性格差异是真实的产品分化：“元宝就比较舔狗”；小珺认为ChatGPT"情商变高了，但情商变高了之后好像变笨了”。情商怎么调？博元指回K2的rubrics based reward——rubric里可以写helpfulness、creativity，“这个时候我们也可以加入他要有情商高、有同理心、说话要好听。但是可能我们可以反向调它，让它说话很尖锐”。价值观和性格已是reward工程的一个旋钮。

32. 时间表与领域温度：coding已爆发，休息两周就变天

• 分场景的爆发判断：“coding这边已经爆发了”——“我和我的朋友们，大家基本上现在代码自己写的越来越少了，基本上都是让agent去写一个大概，然后自己再去改”；短板在系统层面的code（写Ray、multi-process），“但写前端之类的真的非常强大”，且加上用户交互数据后"可能会爆发的特别快”。Tool use"应该也会很快”，browser侧"infra这边可能也会有一定的难度"——但整体"发展可能会非常快"。
• 领域的卷是具体的：选agent方向的博士生"现在挺多的，paper实在太多了"；节奏上"这个领域可能一周一变"——“有一次我休息两周左右没怎么看paper，回来之后发现变天了，就觉得很可怕。”