Kimi K3 百万token的agentic RL怎么做？

1. 每个 iteration 取 $N$ 个 prompt，每个 prompt 采 $K$ 条轨迹（completion），一共 $N\times K$ 条活跃轨迹并行生成；
2. 不等全部结束——一旦有 $\lambda\in(0,1)$ 比例（即 $\lambda NK$ 条）轨迹完成，生成阶段就暂停，让 policy optimization 先跑起来，不被 execution straggler 拖住；
3. 但 dispatch 的粒度是 prompt，不是单条轨迹：某个 prompt 的全部 $K$ 条 response 一旦都完成，就立即整组打包送去策略优化（这一步遵循 Kimi K2.5 的算法）——保证同一 prompt 的 $K$ 条能凑成一组做组内比较，而不是零散地喂；
4. 被暂停（没跑完）的 rollout 入队，下一轮优先恢复接着跑，靠 sandbox 基础设施（§5.3.2）保存现场；
5. 后果：一条 long-horizon 轨迹横跨好几个 iteration 才生成完，等它跑完时当初那版策略早已更新了很多步——数据变得极端 off-policy（陈旧）。

1. 对每个问题 $x$，由冷启动模型估一个初始 token 预算 $b_0(x)$（这题大概该花多少 token）；
2. 某条轨迹实际花的总 budget $T(y)$ 若超过阈值 $\tau\cdot b_0(x)$，就把它的 reward 直接覆盖为 $-1$（不管对不对，话痨就罚）；
3. $T(y)$ 口径分场景：general 数 thinking token，agentic 数 累积输出 token（含 reasoning + tool-call 参数）；
4. stage-wise curriculum：先用大 $\tau$（宽松预算）训 max-budget 变体，再逐步退火 $\tau$（收紧）得到 high / low effort 专家。

judge 被强制走四步 rubric-scorepad 协议：①读产出（先完整读候选）→ ②生成 rubric（现场列评分细则）→ ③按 rubric 打分（逐条对着细则打）→ ④记入 scorepad（据此判胜负）。防 reward hacking：引入 verbosity 预算控制——某输出长度超过 $\sigma\cdot\ell_0$ 就自动输掉这场比较，不给它靠堆字取胜的机会。

• $r_{opd}^{d}$：domain $d$ 上的 on-policy distillation per-token reward（逐 token 发放）；
• $\log \frac{\pi_{teacher}}{\pi_\theta}$：teacher 与 student 的对数概率比——teacher 觉得更该出的 token，值为正，变正向奖励；
• $\mathrm{sg}(\cdot)$：stop-gradient，只当数值奖励用，不让梯度从这里回传；
• $\mathrm{clip}(\cdot,-R_{max},R_{max})$：裁掉极端 log-ratio 造成的巨大 advantage，防训练打飞。

d, e = sample_domain_and_effort()        # 采样域 d 与 effort 档 e ∈ {low,high,max}
teacher = EXPERTS[(d, e)]                 # 9 个专家里选对应那位, 冻结
y = student.generate(x, effort=e)         # on-policy: 用 student 自己当前生成轨迹

rewards = []
for t in range(len(y)):
    logp_teacher = teacher.logprob(y[t], x, y[:t])      # teacher 在该前缀下的 log 概率
    logp_student = student.logprob(y[t], x, y[:t], e)   # student 在同前缀 + effort 下
    r = stop_gradient(logp_teacher - logp_student)      # sg(log(π_teacher/π_θ))
    r = clip(r, -R_MAX, R_MAX)                          # 裁掉极端 advantage 稳训
    rewards.append(r)                                   # per-token dense reward

loss = policy_gradient_loss(student, y, rewards)        # 兼容 partial rollout

1. 把 harness 拆成可配置模块。K3 把一个 agent harness 抽象成一堆可组合模块：工具接口、system prompt、上下文管理策略、skills、memories、subagents 等。
2. 靠配置实例化主流壳。把模块按不同方式组合，就能拼出 Kimi Code、Claude Code、Codex、OpenClaw、Hermes 等主流 harness，也能拼全新的壳。
3. 训练时动态换壳。RL 中给不同任务组动态构造不同 harness 配置，逼 K3 学"通用 agent 能力"而非"某个壳的肌肉记忆"。

Figure 9. 层级化知识图谱把概念从粗（领域）到细（细粒度概念）组织；采样相关节点组成 keyword set（如 RoPE / GPU kernel），去互联网检索公开材料（学术文章 / 博客 / 代码库），每个合成实例再选一种任务类型（Coding / Knowledge / Vision …）合成对应任务。

1. 建图：agent 递归自演化。知识图谱是一张有向无环图（DAG），从粗粒度种子节点出发。每个节点派一个 agent 做多轮 web search 深挖；加新节点前先逛一遍现有图找等价/相关概念、尽量复用。边永远粗概念→细概念，节点足够原子就停止分裂。
2. 采样：控制粒度与覆盖。为命中目标的领域/任务类型分布，在不同粒度层采样节点——可单独采，也可采一组相关节点。
3. 检索 + 合成。用采样节点关键词 + 其在图中祖先节点上下文拼 web query 抓真实材料；合成 agent 据此产出各类任务。

有了壳和任务，还得有可靠的 reward。K3 针对不同能力造了五类专门环境（§4.2.3–4.2.7），核心原则贯穿始终：reward 必须 robustly verifiable，且防得住 reward hacking。（注：low/high/max reasoning-effort 是叠加在这些环境之上的"想多深"维度，不是独立环境类型。）下面逐类拆开详讲。

① 可验证 agentic 问题（§4.2.3）

三类任务共性是产出可验证答案：多步复杂信息搜索（model 规划 research、逐步从 web 搜证据、产出可对拍的 verifiable answer）；专业日常工作（投行 / 数据分析 / 法律——把复杂请求分解、在 sandbox 里操作领域工具、跨几十到几百步完成一份 deliverable）；多步视觉推理（STEM 题 / 视觉谜题 / 图表理解）。视觉推理尤其精巧：在带 Python 解释器的隔离 sandbox 里，模型迭代写代码执行去 crop / zoom / transform 输入图像、精算、验证中间结果，并把执行输出（含生成的图）当作新观测喂回——图像操作与观测越多，视觉推理越强。

② GPU Kernel 优化（§4.2.4）

任务谱系从单算子 kernel 到融合 mega-kernel，源自 Flash Linear Attention 等高质量 GitHub repo；覆盖 CUDA / Triton / CuTe DSL / Gluon / ThunderKittens / TileLang 多种编程方式与 BF16 / FP8 / FP4 数值格式。reward 兼看正确性 + 性能：每个 kernel 带 PyTorch reference，解超过数值误差阈值直接给 0；性能对标专家实现——追平给 0.5，逼近硬件 roofline 趋近 1。再配一套 hacking-detection 系统，惩罚 CUDA graph replay / 输入缓存 / 降精度 等作弊，并随开发中发现新作弊持续加防线。

③ 个人助理任务（§4.2.5）

为 long-horizon 助手造 Gmail / Notion / Slack / Canvas 的高保真 mock——保留真实应用核心语义，但可复现、可大规模交互，无需外部 API、无 rate limit。在此之上设计受真实职场流程（HR / 法律 / 金融）启发的复杂任务：agent 在一个持久、逐日演化的环境里跨多个模拟日操作，遇到跨应用分布的几十个相互依赖事件；单条 rollout 可达数千次工具调用、百万级 context token。每个事件自带评判（确定性规则或 LLM evaluator）；初始工作区由 agent 自主搜网构建，RL 框架也被扩展以支持这种 living environment。

④ AET 自主执行（§4.2.6）— 最能体现"造环境"野心的一类

AET 设定近乎苛刻：每个任务只给 agent 五样东西——初始状态、一个受约束的目标、基于工具的动作空间、执行预算，外加一个独立的 verifier。不给参考轨迹、不给预定义流程。agent 只看到目标、上下文、约束与验证接口，必须自主完成任务分解 / 工具选择 / 规划 / 错误恢复 / 终止判断，训练出一个通用闭环：假设 → 行动 → 分析反馈 → 调整。

1. reward 锚在环境的最终状态，而非 agent 自称"我做完了"——堵死"自我报告式"作弊。
2. 多类 verifier 支持多样环境：黑箱系统复刻（Figure 10 相机维修系统）、定量因子发现、税务审计。
3. 三重反 hacking：(a) agent 与 verifier 隔离；(b) public verifier（给诊断反馈）配 hidden verifier（评 held-out 场景，防过拟合公开检查）；(c) 有限提交预算下用惩罚式 reward。

⑤ Web 开发（§4.2.7）

专家精选的 web 开发任务：输入从一行场景描述到多段规格；产物涵盖网站 / 交互游戏 / 3D·WebGL / 数据可视化 / SVG / 全栈应用。每个任务跑在容器化 sandbox，且在多种 agent scaffold（而非单一固定 harness）下 rollout，促跨 scaffold 泛化。reward = 确定性检查 + 模型判分两部分：确定性检查功能测试应用行为、复刻类打结构与像素级相似度；模型判分用其它模型做源码审查、看/交互产物。build 失败、运行报错、或假装实现（fake 而非 implement）→ reward 直接清零。

K3 用 co-located RL training（训练与 rollout 同卡）把每个 1M-context 实验压进几百张 GPU，再用 partial rollout 削超长轨迹的尾延迟。硬件利用率上去了，却带来一个新矛盾：要留给下一轮的 rollout KV-cache 和 训练本身要的显存 互相抢地方——长上下文下尤其致命。三招各治一处：

1. External KV-cache pool（write-back 设计）。1M-context 多步 rollout 下，一次 prefix KV-cache miss 极其昂贵；partial rollout 在每轮开头还会让上一轮没跑完的长 prefill 请求扎堆涌来，加上投机解码加速请求周转，prefix block 频繁 churn → 触发 preemption、拉低命中率。解法：把"prefix 保留"与"GPU 常驻"解耦——active decoding block 留在 GPU KV cache，可复用的 idle prefix 只在被逐出 GPU 时才 write-back 到 CPU DRAM 外部池，下次复用前 prefetch 回来（KDA state 与对应 MLA KV 块对齐生命周期一起搬）。比 write-through 只为"离开 active decode 的 prefix"付 DRAM 与带宽，不冗余拷贝仍活跃的块。DRAM 不够就在 iteration 结束后把训练态 offload 到 NVMe。
2. Rollout auto-throttling scheduler（自动限流调度）。多步 rollout 里 context 随轨迹推进越来越长，按"整条轨迹平均长度"定固定并发既难估、早期又过保守；并发调太高则后期 KV 压力大触发 preemption。K3 在请求调度层做自动限流：用运行时信号（active 请求数、queued 请求数、KV 利用率）动态决定发多少请求进推理引擎——早期保持高利用，KV 压力升就降并发，无需手调就避开欠饱和与过载两头。
3. Gradient-buffer reuse（复用梯度缓冲跑非策略模型）。RL loss 常要 reference model 这类 forward-only 的非策略模型，权重太大不能常驻 GPU。K3 把它们放 CPU、用时才物化，且借 policy model 的 FP32 gradient-buffer 存储来放——零额外分配、不产生碎片，真梯度算出时正好覆盖回来（安全）。ZeRO-2 梯度分片下每 GPU 只留 2 个 VPP chunk 的 grad buffer：一个 slot 做当前前向、另一个 prefetch 下一 chunk，逐 chunk 流式换入，把拷贝开销藏起来、不占额外显存。

K3 用多种 sandbox runtime 支撑后训练与评测：传统 container、GPU sandbox，以及最亮眼的 microVM 沙箱 AgentENV（与合作伙伴联合研发，专为 agentic 负载设计）。它围绕三个目标：

1. 高保真隔离 runtime。agent 越强越爱激进探索、甚至试图 reward hacking——早期用传统 container runtime 时就出现过 agent 误操作引发的 kernel panic / deadlock。既要放开探索不限能力，复杂任务又需要贴近真实的环境（agent 得能挂盘、跑容器、甚至随手起虚拟机）。用 Firecracker 跑隔离 microVM，隔离度与保真度是容器给不了的。
2. 灵活的沙箱生命周期。底层增量 checkpoint：只存自上次以来的脏页，checkpoint 低至 133ms、resume 低至 49ms。之上给三大高级能力：(a) Pause/Resume——等模型推理时把沙箱暂停，暂停态零内存零 CPU，而"等推理"可占沙箱生命周期高达 98%；(b) Fork——从原沙箱精确状态复制一个新沙箱、原沙箱继续跑，用于无副作用的 reward 判分；(c) Snapshot——定时快照做错误恢复。
3. 高效率、高密度。数万个各带不同 image 的沙箱可能要在几秒内创建。用 OverlayBD 做 image 格式，配自定义 ublk 驱动、存储层共享与 P2P 传输，做到亚秒级启动；再靠 copy-on-write 与 page-cache 优化，内存 overcommit 实测高达 6.5×。