嘉宾郑博源从研究者视角给出了Agent的严格定义：Agent的核心在于与环境的交互。Language Model只接收input输出output，而Language Agent需要感知环境（Perception）并生成与执行动作（Action）来影响环境，形成observation-action-feedback的循环。
Language Model：input → output，过程结束。
Language Agent：observe环境 → 结合task和历史交互 → 生成action → 执行获得环境feedback → 循环反复。关键差异在于是否存在一个可交互的环境，以及Agent是否能通过action影响该环境。
本期讨论的技术报告涵盖Kimi K2、ChatGPT Agent、Qwen3-Coder三个端到端训练的模型，以及Manus基于In-Context Learning的工程方案。最大的路线分歧在于：是否通过端到端训练来构建Agent。
郑博源透露，在ICML会议上，研究者对ChatGPT Agent的反应是"舒了一口气"，因为大家一直担心OpenAI会一次性通过scale up解决Agent问题，把学术小方向"干掉"。这种情况已发生过多次：ChatGPT冲击了NLP，GPT-4V冲击了多模态研究。而初创公司则"极其兴奋"，甚至搞"斗兽场"demo与ChatGPT Agent对比——这证明问题足够难，探索空间足够大，对融资和产品都有帮助。
Kimi K2的论文标题明确claim这是一个Agentic Intelligence模型，是较早在宣发上聚焦Agent能力的大模型。其三大核心贡献分别涵盖优化器、数据合成和强化学习。
这是本期的核心判断。Kimi K2 paper中每个部分用到的trick，对应的paper都已经在学术会议上出现过——WizardLM、SlowMath等都是已有的proof of concept。但LLM这样一个系统工程，需要把各种trick结合到一起，放在language model training范式下验证作用，并将scale放到特别大。现在idea都"在那边"，每件事情都需要大量工程去把效果做好。
面对预训练数据枯竭（"整个互联网的数据基本上都被扒光了"），Kimi K2在预训练阶段采用了系统性的数据重写方案来缓解瓶颈。
对Wikipedia、书本、知识密集型文档，使用Kimi K1.5进行风格和视角多样化改写（Style and Perspective Diverse Prompting）。但改写过程不可避免会产生幻觉——即不小心改变了原文中的事实知识。
| 方案 | SimpleQA准确率 | 说明 |
|---|---|---|
| 原始数据训练10次 | 23.76% | Baseline，纯重复训练 |
| 重写1遍后训练 | 显著提升 | 单次改写已有效果 |
| 重写10遍混合训练 | 进一步提升 | 最激进方案，效果最好 |
沿用SlowMath论文方案，将高质量数学文档重写为学习笔记格式。其思想类似费曼学习法——自己学完后教给别人，如果能把别人教会，说明自己真的学会了。这种更密集、重新组织过的格式能帮助模型更高效地学习数学知识。
Post-training阶段是与Agent能力最相关的部分。Kimi K2构建了一个大规模的Agentic数据合成流水线，核心目标只有一个：Diversity（多样性）。
在GitHub上收集大量MCP（Model Context Protocol，Anthropic提出的标准化工具调用协议）工具。MCP的出现极大简化了Tool Use研究——统一的接口标准使得数据合成不再需要为每个API做大量工程适配。用t-SNE可视化显示，原始工具分布稀疏。
通过Hierarchical Domain Generation方式（基于WizardLM方案），对原有MCP进行组合、重写接口描述和操作逻辑，生成更多工具。可视化显示扩展后的工具分布变得非常稠密，覆盖更多领域。
生成大量System Prompt，创造各种角色的Agent（数据分析专家、程序管理者、高情商助手等）。本质上是在模拟下游用户的应用场景，通过角色扮演"逼着"LLM生成更diverse的数据。
在MCP出现之前，研究者需要为每个API接口做大量工程适配，各种参数和调用方式都不统一。MCP提供了标准化协议后，工具收集和数据合成变得极为便利。而且MCP工具本身自带应用场景和使用意义，数据质量天然高于凭空爬取的API。这是标准化协议推动研究进展的典型案例。
对每个Agent配置（System Prompt + 工具子集），用LLM生成对应的task和Rubrics（评价标准）。例如：选了10个市场营销/数据分析的MCP工具 + 生成"数据分析专家"的System Prompt → 进一步生成"调研所有GPU供应商的价格情况"等任务。
用LLM生成User Persona（用户画像），模拟不同身份（产品经理、律师、厨师等）的沟通需求、交流方式和任务偏好。这既是模拟下游应用场景，也是保证数据diversity的重要手段。
RL训练的核心是Scale Up——获得大量diverse的task和verifiable reward，进行大量训练。但并非所有任务都能获得客观的verifiable reward。
| 类型 | Reward来源 | 核心挑战 |
|---|---|---|
| 数学/STEM/逻辑 | 答案对比、推导验证 | 控制难度：太简单学不到东西，太难reward稀疏 |
| 复杂指令跟随 | Rule Verification + LM Judge双层 | 防止Reward Hacking |
| 事实忠实度 | Sentence-level Fact Grounding | 减少幻觉，确保thinking与answer一致 |
| 代码能力 | 竞赛题目 + GitHub PR/Issue | 构建大规模沙盒环境 |
类比高中刷题：如果只做简单题，全对但学不到东西；如果题目太难，回答100次都失败，模型不知道往哪个方向优化。需要的是刚好有挑战但又能偶尔成功的难度。具体做法：先用未经RL训练的模型尝试K次，根据准确率筛选合适难度的任务，并随训练进程动态调节。
为此，Kimi K2采用Code Interpreter验证 + LM Judge双层机制：先用程序检查长度、文本风格、约束条件等硬指标，再用LM Judge作为防止Reward Hacking的safety layer。
对于Creative Writing、开放性问答等无法获得客观verifiable reward的任务，Kimi K2引入了Self-Critic Rubrics Reward机制。
传统范式是标注SFT的input-output数据对。新兴趋势是标注Task + Verifiable Reward / Rubrics Reward。这可能是数据标注领域的范式转移——从直接给答案，到给出评价标准让模型自己探索。Scale AI最近发布的rubrics and reward paper也在推动这一方向。
郑博源指出，Rubrics中可以写入helpfulness、creativity等维度，也可以加入"情商高、有同理心、说话好听"——甚至可以反向调节让模型说话尖锐。这解释了为什么不同模型"性格"迥异：DeepSeek"嘴臭但鞭辟入里"（可能因为贴吧训练数据），ChatGPT"情商变高但好像变笨了"（过度alignment），元宝"比较舔狗"。模型性格本质上是Reward设计的产物。
Agent训练的RL Infra面临传统RLHF不曾遇到的工程挑战。传统RL每轮rollout延迟相对稳定且不涉及多轮交互，但Agent训练完全不同。
浏览器可能突然卡住、网络不稳定、Browser直接崩溃。如果没有对training做优化，GPU就一直卡在那里等待，utilization极低。
一个batch中256条rollout，可能250条在5步内完成（3分钟），但剩下6条需要30步才能完成（10分钟）。大部分GPU时间在为那6条等待——造成巨大浪费。
长尾rollout被暂停后在下一个iteration恢复时，其中的action不是当前模型策略产生的。模型参数已更新但buffer中的rollout还是旧的，可能导致训练方向偏移。
| 公司 | 环境Infra方案 |
|---|---|
| Kimi K2 | 用gVisor（Google的高并发容器方案）同时host大规模concurrent sandbox；重环境单独包装成service+API；过量并发rollout（需要64条就开640条）；长尾rollout直接截断（Partial Rollout） |
| Qwen3-Coder | 在阿里云上部署20,000个parallel environment |
| ChatGPT Agent | host大量virtual machine做rollout环境 |
ChatGPT Agent的核心策略是将Operator（Browsing Agent）、Deep Research（Search Agent）和Tool Use三种能力统一到同一个Agent中。
Operator擅长理解GUI、操作浏览器、进行navigation，但找大量文本信息未必最强。Deep Research基于text browser做大量search和URL导航来总结信息。创始团队认为两种能力天然互补。实现上更可能是直接将action space统一（单一Agent能browsing+search+tool use），而非搭建多Agent系统。
Information seeking类任务容易获得reward（答案比对即可），但如果任务是"下单一个产品"或"预约餐厅"，Agent需要做大量browsing操作，而大部分网站的后台数据是无法获取的，无法验证任务是否真正完成。可以在小规模沙盒中训练（能访问数据库），但要scale up就需要"非常高明的方式"去获取verifiable reward。这是Computer Use Agent RL训练的核心瓶颈。
Qwen3-Coder（千问3-Coder）相比Kimi K2增加了Agentic Browser Use评估维度，在WebArena和Mind2Web等基准上展示了不错的表现。但博客式发布缺乏细节。
Qwen3-Coder直接对接Gemini API接口，同时提供CLI工具和VS Code插件。这反映了一个common practice：发模型的同时发CLI工具。这不仅证明模型真正在实际场景中应用（而非纯刷榜），更重要的是——如果能收集到用户与Agent的交互数据，也许能用来进一步改进Agent本身。
Manus首席科学家PIK发布了关于Context Engineering的博文，分享了如何在不做模型训练的情况下，通过精细管理上下文来最大化Agent性能。
Manus的整体思路围绕KV Cache复用展开。使用KV Cache时推理成本约0.3元，不使用时约3元——10倍的成本差距。
让prompt前文保持一致，KV Cache可以直接重用，不需要重新计算。
Context中不动中间内容，只在末尾追加新内容，保证KV Cache的有效性。
当某些工具（MCP）不再使用时，不要从context中删除，而是将其mask掉——让模型生成时忽略即可，但KV Cache结构保持完整。
用文件系统管理context内容，结构化地控制Agent的注意力。
当context不断增长导致模型"变笨"时，用todo.md来manipulate模型的attention焦点。
模型中间出现的failure不要删除，继续保留在context中——错误信息也是有价值的上下文。
放入context的example要足够diverse，否则模型会倾向于不断重复前面的内容，产生无用的重复生成。
经典的"Lost in the Middle"现象（模型难以attend到长文本中间的内容）在Agent场景下被放大——随着交互轮数增加，前面的步骤信息逐渐被"遗忘"。用郑博源开玩笑的话说："context塞了越来越多东西，它在内耗。"Manus通过context engineering的工程手段来缓解这个问题。
郑博源从亲身经历出发，阐述了Agent安全的紧迫性。不同类型的Agent风险等级完全不同。
环境交互成本是Agent训练中一个被学界"一定程度低估"的核心问题。郑博源给出了多个具体的成本估算。
| 场景 | 交互方式 | 成本挑战 |
|---|---|---|
| Search Agent | Google Search API | 单次1分钱，但Deep Research单次任务约100-150次搜索，大规模training需要巨量rollout |
| Browser Agent | 真实网站交互 | IP被封（极普遍现象）；Cloud Browser服务（如BrowserBase）收费极贵 |
| 本地沙盒 | Docker容器 | CPU/Memory成本高，大量并发sandbox对环境消耗大 |
| 机器人 | 物理世界操作 | 极端案例：真实数据需要人现场操纵机器人，仿真数据占99% |
郑博源估算，仅100K条browser trajectory的环境交互成本就可能达到数千美元。BrowserBase这类Cloud Browser服务之所以能获得大额融资，正是因为这个需求真实且迫切。如果RL训练效果持续验证为强大，接下来的重心可能就是不断造Environment，在此基础上生成大量task + verifiable reward，作为新的scaling方式。
Agent Memory是一个需要大量新工作才能做好的领域，与传统Chatbot Memory有本质区别。
这个领域目前还需要更多研究。Agent的交互历史包含大量procedure knowledge（过程性知识），如何结构化地积累和利用这些知识，是提升Agent能力的关键方向。
Kimi K2的研究者手动在GitHub上找PR/Issue建sandbox做RL训练。但如果Agent本身能够自己在网站上爬取、探索，自动找到reward signal和training environment呢？Agent可能成为一个Data Engine——自己发现新数据、自己建环境、自己做RL训练，实现Self-Improvement循环。目前这还是brainstorm层面，但郑博源认为是"非常有意思的研究方向"。
"我和我的朋友们，代码自己写的越来越少了，基本都是让Agent写一个大概然后自己改。"系统层面代码（RL、Multi-process）还不够强，但前端等领域"真的非常强大"。
Infra支撑正在完善，MCP生态日益丰富。
环境交互成本和稳定性仍是核心瓶颈，但发展速度可能超预期。
这印证了"Research和Product相互迭代"的趋势：产品积累用户数据 → 改进模型/prompt → 更好的产品 → 更多数据。用户在使用Agent的过程中，本质上就是一种Annotator，在不断提供各种reward信号。
Kimi K2 paper中每个trick都有对应的已发表论文，idea并不新。真正的壁垒在于：能否将数十个已验证的小trick整合到一个大规模训练流水线中，并在scale up后依然保持质量。这不是科学发现的问题，而是系统工程的手艺活。"研究员都是老师傅"——prompt调优、数据筛选、参数调整的sense，可能比idea本身更稀缺。
传统SFT标注input-output对，新范式是标注Task + Rubrics/Verifiable Reward。这一转变意义深远——不再告诉模型"正确答案是什么"，而是告诉它"怎么判断你做得好不好"，让模型通过RL自己探索解决路径。这本质上是从教知识到教方法论的转变。
如果RL持续有效，下一阶段的竞争核心可能不是算力、不是模型架构，而是谁能构建最丰富、最真实的训练环境。BrowserBase融到大笔资金、各家在云上部署数万sandbox——Environment正在成为AI训练中一种新的基础设施，其重要性可能比拟预训练时代的数据。
Deep Research只读不写，完全安全；Computer Use Agent可以下单、发邮件、修改设置，影响不可逆。1个Agent订错试驾是笑话，1000个Agent同时发请求就是DDoS。Guardian Rail不仅是技术方案，更是伦理与责任归属的设计——让User approve后，Agent的责任归属才有法律意义。
20,000个parallel environment、大量GPU时间、Cloud Browser费用——Agent RL训练的成本门槛正在急速攀升。学界能跟上idea但很难跟上engineering。反过来说，学界在proof of concept层面的工作仍然不可替代——WizardLM、SlowMath等小规模验证工作，正是工业界大规模集成的"零件库"。
Manus用纯context engineering在不训练模型的情况下做出可用产品，证明了ICL路线的实用价值。在端到端训练难以覆盖的多Agent协作场景中，ICL路线可能更具优势——因为多Agent的RL训练面临reward归属难以分配的根本困难。两条路线可能长期共存，适用于不同场景。
Agent与环境的交互不是封闭系统——每次交互都有新数据进来。如果能从exploration中自动提取knowledge、自动发现reward signal、自动构建训练环境，Agent就可能成为一个自我进化的data engine。这与预训练时代"数据即将耗尽"的焦虑形成对比——Agent范式下，数据可以被创造，而不只是被消耗。
DeepSeek嘴臭但深刻、ChatGPT情商高但可能变笨、元宝"舔狗"——这些用户体感上的差异，本质上都是Reward设计和Alignment策略的结果。Rubrics中加入"有同理心"就温和，加入"尖锐直接"就犀利。当我们说一个模型"变了性格"时，其实是Rubrics Reward的权重被调整了。
"我现在每天很多代码都是Agent写的，我做的事情更多是修改它。"当PhD学生可以同时开3-5个Agent并行处理不同任务时，编程的含义正在从"写代码"变为"管理和审查Agent的输出"。程序员的核心能力从代码实现转向系统设计、质量判断和reward设计——这恰好呼应了本期"系统工程大于idea"的主题。