郑博元访谈深读：Kimi K2 之后，Agent 竞争进入系统工程

一、Agent 的边界在环境，不在“会不会思考”

访谈把 Agent 从模型中剥离出来的关键，是一个可反复改变状态的环境。Coding Agent 看到代码库、运行日志和测试结果；Search Agent 看到网页、检索结果和待核对的来源；Tool-Use Agent 看到工具的 schema、返回值与错误；Computer Use Agent 看到截图、HTML 和点击后的新页面。它们的共性不是名字，而是 observation → action → feedback 的循环。

因此“Agent 爆发”必须分场景讨论。Coding 已经拥有较短的反馈链，Browser/Tool Use 的难点则转移到环境基础设施、权限和长程恢复；不能用前端代码生成的体感，替代对真实世界行动风险的判断。

二、两条路线不是二选一：Context Engineering 与端到端训练各自买什么

Manus 的路线是把现有模型的 In-Context Learning 能力调到极致：角色拆分、提示词、工具、Filesystem、状态管理和多 Agent 编排可以快速迭代，适合产品先跑起来。Kimi K2、Qwen3-Coder 等则把特定场景的轨迹、奖励和环境写回训练，使模型在 Coding、Tool Use 或 Browser Use 上获得更强的原生倾向。

三、Kimi K2 的关键贡献：把 Agent 训练写成一条“数据编译器”

官方资料把 Kimi K2 描述为约 1T 总参数、32B 激活参数的 MoE 模型，并报告了大规模预训练与 Muon 优化器。访谈没有把优化器本身神化，而是把注意力放到两个与 Agent 更直接相关的贡献：大规模 Agentic Data Synthesis Pipeline，以及结合可验证奖励与 Rubric 自评奖励的 RL 框架。

这套思路的深层含义是：数据不再只是静态文本，而是由任务规格、工具目录、模拟器和评价器共同编译出的训练样本。模型公司真正需要规模化的，可能不是“再爬一遍互联网”，而是把新环境转换成多样、保真、可回放、可验证的学习轨迹。

四、从 MCP 工具到任务 Rubric：Agent 数据怎样被“制造”出来

访谈中最具工程含量的部分，是对工具数据管线的拆解。工具不是简单列一个 API 清单，而是先从约三千个 MCP 工具出发，合成更丰富的工具集合，再为任务配置角色、系统提示、用户目标、成功标准、人物/风格和模拟器；随后在真实世界或沙盒里运行、过滤并留下可训练的轨迹。具体规模和比例属于节目讲解口径，应与官方报告的公开实验设置分开阅读。

任务合成的难点是多样性。若让同一个模型在有限网站上自动提出任务，它很快会重复自己的先验；引入人工任务、不同模型、角色、工具组合和难度控制，才能扩大状态覆盖。难度也不能一味拉高：过简单没有学习信号，过困难则只有噪声和超长失败轨迹，最佳区间应由训练曲线和真实迁移共同决定。

安全是这条管线的一部分，而不是上线前的独立闸门。工具权限、系统提示、恶意网页、错误参数和不可逆动作都必须在任务生成、执行、过滤和部署时分别处理。

五、RL 的价值来自“可验证”与“可探索”的组合

对代码、数学和逻辑任务，是否编译、测试是否通过、证明是否成立，能提供相对清晰的 verifiable reward；对开放式写作、研究和交互质量，单一答案往往没有唯一标准，才需要 Rubric、自评、互评或用户反馈。Kimi K2 采用二者组合的思路，正是承认现实目标既有硬约束，也有软质量。

访谈还提到一组训练稳定性工程：控制 rollout 长度和预算、加入长度惩罚、用 PTX loss 保留预训练知识、逐步调整温度，以及处理并发、环境服务、部分 rollout 和 stale trajectory。它们常被忽略，但决定了“论文里能跑”是否能变成“产品里稳定”。

六、ChatGPT Agent：把研究、浏览与行动合成一个产品动作空间

官方介绍把 ChatGPT Agent 描述为能够研究、浏览网页、使用工具并执行任务的产品，并强调用户控制、确认和安全边界。访谈把它理解为 Operator 与 Deep Research 等能力的合流，这是一种基于产品行为的解释，不等于 OpenAI 公布了完全相同的内部实现。

无论内部架构如何，产品层的变化很重要：用户不再只接收一段回答，而是把目标交给一个会访问网页、读取信息、调用工具、形成中间状态的执行者。于是“回答是否正确”必须升级为“它在谁的权限下做了什么、哪些动作需要确认、失败后能否回滚、结果如何审计”。

Computer Use 的安全边界比纯文本回答更具体：一个错误点击可能改变外部账户状态，一千个并行代理则可能变成对网站的集中压力。防护不应只依赖“模型更聪明”，还需要 action guard、速率限制、沙盒、审批和可撤销设计。

七、Qwen3-Coder：长程 Coding 的增量主要在环境和工具

Qwen 官方博客公开了 Qwen3-Coder 的大规模 MoE、长上下文、代码生成、浏览器和工具使用方向，并提供 Qwen Code CLI 等使用入口。节目中提到的具体并行环境数量属于嘉宾讲解口径；可确认的机制是：为了训练长程 Coding/Browser Agent，需要大量彼此隔离、可重置、能返回真实反馈的环境服务。

“Hard to solve but easy to verify”解释了 Coding 为什么适合 RL，却不能掩盖工程成本。每一个环境都要处理依赖、权限、网络、超时、状态清理、数据泄露和正确性判定；并行数越大，调度、监控与存储就越像一个分布式系统，而不是一段训练脚本。

八、Manus 的 Context Engineering：记忆管理其实是计算管理

Manus 的公开经验不是“提示词写得更长”，而是围绕 KV Cache 组织上下文：稳定前缀、追加式写入、在不删除内容的情况下用 mask 隐藏暂时不用的部分，再借助 Filesystem 与 Todo 文件把长期状态移到模型外部。这样既复用缓存、降低推理成本，又给 Agent 一个可读写的工作区。

但这条策略有一个内在张力：上下文越长，缓存越能复用，模型却可能越难把注意力放到真正重要的内容。解决方案不是把所有东西都塞进 prompt，而是让状态有结构：目标、当前计划、已验证事实、失败记录、待确认事项和权限分开存放；错误不能因为摘要而消失，应该保留来源和可回滚版本。

九、自我提升闭环：Agent 先学会寻找自己的课程

访谈最后把问题推向更远处：如果 Agent 能在网站、代码库和工具环境中自主探索，它是否可以自己发现适合训练的任务、奖励和环境？Kimi K2 中由研究人员挑选 GitHub Pull Request/Issue 并搭建沙盒，仍是人类设计课程；更自动的路线则是让 Agent 先提出候选任务，再由人或验证器筛选，最后把成功轨迹压缩成可复用的 Skill、API 或程序知识。

这个闭环的难点不是“能不能自己点网页”，而是奖励发现：Agent 必须区分真正的新任务与重复噪声，判断环境是否安全，理解何时应该提问以消除歧义，并把一次成功压缩成对未来有效而不过拟合的程序。自我提升如果没有独立验证，可能只是自我评价的循环。

最后的“Agent family”也可以用系统工程理解：一个人把 Coding、写作、长文档整理、批评和检索交给不同 Agent，个性差异来自模型、系统提示、奖励和上下文的组合。多 Agent 不等于多人开会；只有当角色、状态和交接协议减少了错误，分工才有必要。