Model / Inference / Agentic Training 深度手册

面向 Coding Agent 研发工程师的模型层知识底座。本文不是学习计划，也不把模型能力简化为 benchmark 分数；它关心的是：模型为什么会形成某种能力、推理时怎样释放这种能力、它在真实工具环境里为何失效，以及 Model 与 Agent Infra 应如何共同演进。

资料核验日期：2026-08-03（Asia/Shanghai）。文中使用三种证据标签：[事实] 表示“所引一手来源明确报告了这项事实或实验结果”，不自动表示已经独立复现；[推断] 表示从公开事实与工程约束推出的设计判断；[争议] 表示公开证据尚不足、实验条件敏感或不同研究结论不一致，不能包装成定论。

证据快照与可靠性边界

• Kimi K3 的架构、训练、推理和自报评测以官方仓库 main 的 7c5be95（2026-07-28）及其中技术报告为准；这是一手披露，但模型能力数字仍属于发布方自报结果。
• Kimi Code 的公开能力以官方仓库 main 的 29c9e2a（2026-08-03）和当日在线模型文档为准。公开仓库与文档不能证明线上私有服务的全部内部实现。
• 本文引用的 2026 年 ToolVerse、ProRL、Polar、VPR、General AgentBench、Agentic Coding TTS、Harness-Bench 与 Claw-SWE-Bench，截至核验时除 VPR 已到 v2 外均为 arXiv v1；它们适合识别新方向和复现实验，不应当作多团队独立重复后的行业定律。
• DeepSeek-R1 使用截至当日的 arXiv v2（2026-01-04 更新），Kimi k1.5 使用 v4（2025-06-03 更新），VPR 使用 v2（2026-05-27 更新）；本文链接均指向 arXiv 最新版本而非固定旧 PDF。
• Benchmark 数字只有连同 model revision、harness、effort、sampling、turn/token budget、environment 与 verifier 才可比较。跨发布方表格中引用 leaderboard 或第三方成绩，不等于同一执行环境下的严格 head-to-head。

0. 一张总图：Agent 能力不是模型单变量

把一次 Agent 任务的成功概率写成条件函数：

[ P(\text{success}) = f(M,D,C,T,H,E,V,B,R) ]

其中：

• (M)：model weights、architecture、post-training policy；
• (D)：decode policy，包括 temperature、sampling、reasoning effort、stop policy；
• (C)：送进模型的 context、顺序、authority、压缩与缓存状态；
• (T)：tool schema、工具语义、返回格式与真实 effect；
• (H)：harness 的 loop、planning、state、recovery、permission 与提示；
• (E)：environment，包括代码版本、依赖、网络、sandbox 和外部世界；
• (V)：verifier / judge / tests；
• (B)：token、时间、步骤、并发和金钱预算；
• (R)：routing，包括模型、effort、context window、工具与子 Agent 选择。

这带来三个基础结论：

1. 模型能力是条件能力。一个模型“会写代码”不等于它能在某个 schema、某个 shell、某个 budget 下可靠完成仓库级任务。
2. Agent 结果属于 model-harness pairing。只报模型名而不报 harness、effort、turn limit、context policy、tools 与 verifier，无法复现实验。
3. 强模型不能替代确定性系统边界。模型负责在不确定性中选择动作；系统负责 state、effects、authority、persistence 和 evidence。

pretraining corpus
      ↓ next-token prediction
base model
      ↓ SFT / preference / RL / distillation
agentic policy
      ↓ decode policy + context + tools
action trajectory
      ↓ environment transitions + verifier feedback
task outcome
      ↓ trace / eval / data curation
next training and harness iteration

1. 能力本体：模型究竟“拥有”什么

1.1 模型首先是条件分布，不是程序、数据库或状态机

自回归模型学习：

[ p_\theta(x_{1:n}) = \prod_{t=1}^{n}p_\theta(x_t \mid x_{<t}) ]

推理时，它对下一个 token 给出条件分布；“推理”“计划”“工具调用”都是该分布在特定训练和上下文条件下表现出的行为模式。由此必须区分：

• 参数知识：权重中统计性编码的规律，难以定位来源与精确更新；
• 上下文知识：本次请求可见的证据，受窗口、选择、顺序和 authority 影响；
• 环境事实：文件、进程、Git、网络、数据库的当前状态，必须通过工具观察；
• 任务状态：目标、已完成事项、待验证假设、side effects，必须由 runtime 持有；
• 策略能力：在 observation 下选择下一动作的倾向，不等于动作必然正确。

因此，“模型说已经修改文件”不是事实；只有 workspace state 与可验证 diff 是事实。“模型记得上一步”也不意味着系统有 durable state。

1.2 Coding Agent 的能力向量

不要用一个总分描述 Agent 模型。至少拆成以下维度：

1.3 能力、可靠性、校准、自治是四个概念

• 能力上限：在有利采样、充分预算或多次尝试时能否做到；
• 可靠性：在目标部署分布上单次或给定预算内成功的概率；
• 校准：置信、继续/停止、求助决策是否与真实成功概率一致；
• 自治：连续无需人介入的时间或步骤，不代表任务正确、安全或有价值。

如果单步独立失败率为 (q)，完成 (n) 个关键步骤的上界近似为 ((1-q)^n)。现实中错误相关且会污染后续 context，长程可靠性通常比这个理想模型更差。Agentic training 的核心不是让模型偶尔做出惊艳轨迹，而是降低关键状态转换上的条件失败率，并让失败可恢复。

1.4 “推理能力”至少有三层

1. 内部计算：模型在一次生成中形成 latent / chain-of-thought 计算；
2. 外部化推理：写计划、运行代码、查询文件，让环境成为可检查的 scratchpad；
3. 闭环控制：依据真实 observation 改变下一动作，而不是继续执行原先想象。

Coding Agent 最关键的是第三层。一个能生成漂亮分析但不读取命令失败、忽略 Git diff 或重复调用同一工具的模型，属于 execution misalignment，不是合格的长程 Agent。

2. 从 Pretraining 到 Agentic RL：每一阶段到底修什么

2.1 全生命周期

2.2 Pretraining：能力地基，不是任务完成训练

Pretraining 通过海量 token 建立表征、程序模式和世界模型。它决定后续 SFT/RL 能否以合理样本效率学会新策略。强 post-training 不能凭空创造 base model 完全缺失的表征能力。

对 Coding Agent，pretraining 数据设计的重要变量包括：

• 代码、提交、issue、review、文档、测试和执行日志的比例；
• 数据时间与许可证；
• 重复与 benchmark contamination；
• 完整仓库结构 vs 孤立代码片段；
• 正确实现、失败调试、回滚和验证证据是否同时存在；
• 长序列不是简单拼接：是否包含真正跨远距离依赖的训练信号。

[事实] Kimi K3 报告称其 context curriculum 从 8K、64K 延伸到 cooldown 阶段的 256K、1M，并专门合成长距离依赖数据；报告明确指出“长度本身不赋予长距离能力”。Kimi K3 技术报告核验快照

2.3 SFT：建立可工作的初始 policy

给定示范集合 (D={(x,y)})，SFT 最小化：

[ \mathcal{L}{\text{SFT}}=-\mathbb{E}{(x,y)\sim D}\sum_t \log p_\theta(y_t\mid x,y_{<t}) ]

在 Agent 场景，(y) 不再只是最终答案，而可能包含 reasoning、tool calls、observations 的序列化轨迹。SFT 适合修：

• tool-call 语法、角色与消息邻接；
• 基础工作流和高质量范式；
• safety / style / refusal 的初始边界；
• RL 冷启动，使随机探索不至于完全无效；
• 模型从未见过的新 harness contract。

SFT 的根本局限：它最大化“像数据”，不是“在新环境成功”。只保留成功轨迹还会形成 survivorship bias：模型看不到错误是怎样发生、怎样识别以及怎样恢复。

2.4 RFT 不是一个无歧义缩写

面试中必须先澄清对方指什么：

• Rejection-sampling Fine-Tuning：采样多个候选，用 verifier / reward 过滤或排序，再对入选样本做监督学习；
• Reinforcement Fine-Tuning：用 reward 对 policy 做在线或近在线强化优化；
• 有些讨论把 RL from Verifiable Rewards (RLVR) 也宽泛叫 RFT。

三者不能混称。Rejection sampling 仍主要是 imitation：容易工程化，但只学习采样 policy 已经探索到的好行为；真正 RL 可改变轨迹分布，但稳定性、成本和 reward 风险更高。

2.5 RL：从模仿答案到优化行为分布

把 Agent 表示为部分可观测决策过程：

• state (s_t)：环境真实状态，模型不能完全看到；
• observation (o_t)：工具返回、文件片段、测试结果；
• action (a_t)：文本、工具调用、停止或求助；
• transition (P(s_{t+1}\mid s_t,a_t))：环境 effect；
• reward (r_t)：过程或结果信号；
• trajectory (\tau=(o_0,a_0,r_0,\dots,o_T))。

目标是：

[ J(\theta)=\mathbb{E}{\tau\sim\pi\theta,E}\left[\sum_{t=0}^{T}\gamma^t r_t\right] ]

LLM RL 常加入对参考策略的 KL / token-level regularization，以限制更新幅度、防止能力坍塌，并处理 rollout 与 learner 的 policy lag。GRPO、PPO 等只是优化器家族；更重要的是 reward 是否代表真实目标、rollout 是否高保真、任务分布是否覆盖部署。

[事实] DeepSeek-R1 v2 报告了没有 SFT 冷启动的 R1-Zero，经大规模 RL 出现推理行为，但也出现可读性差、语言混杂；正式 R1 使用 cold-start 与多阶段训练。[推断] 这为“RL 能诱发基础策略中不明显的推理行为”提供了公开证据，也说明该团队没有把纯 outcome-driven RL 视为最终产品配方；论文并未证明任何 base model、reward 或任务分布上都能重现相同涌现。

[事实] Kimi k1.5 v4 报告以 long-context RL 和改进 policy optimization 获得推理提升，并明确称其方案不依赖 MCTS、value function 或 process reward model。它至少给出一个公开配方：竞争性 reasoning 结果不以这些组件为必要前提；这不证明这些组件在其他模型、开放任务或长程 Agent 上无用。

2.6 RLHF、RLVR、Generative Reward 的差异

2.7 Outcome Reward、PRM 与 Verifier

Outcome Reward Model (ORM) 只看最后结果，优点是目标直接；长轨迹中信号稀疏，最后失败无法指出哪一步错。Process Reward Model (PRM) 给中间步骤打分，能改善 credit assignment，但只有在步骤定义与评判可靠时才真正更好。

Verifier 应分层，而不是一个总分：

protocol verifier    参数/schema/角色是否合法
effect verifier      文件、进程、外部系统是否处于预期状态
task verifier        功能、测试、隐藏约束是否满足
quality verifier     可维护性、体验、论证质量
safety verifier      是否越权、泄密或采用危险捷径
meta verifier        上述 verifier 本身是否覆盖充分、相互冲突

关键区分：

• soundness：被 verifier 接受的结果是否真的正确；
• completeness：所有正确解是否都有机会被接受；
• coverage：它检查了完成定义的多少部分；
• hackability：模型能否不完成任务却提高分数；
• stationarity：环境、依赖或 judge 变化后 reward 是否仍同义。

[事实] 2026 年 Verifiable Process Rewards v2 在具有算法/符号 oracle 的 agentic reasoning 环境中报告，turn-level 可验证信号优于 outcome-only 和 rollout-derived process baseline；作者同时明确限制在“可靠中间 oracle 可用”的场景。该结果来自一篇尚未独立复现的预印本，不能外推成开放软件工程里 PRM 必然优于 ORM。

2.8 Credit Assignment：长轨迹最硬的问题

长任务最后通过，可能有早期错误被后续偶然补救；最后失败，也可能大多数动作正确。常见方案：

• trajectory-level outcome reward：简单但高方差；
• turn / token advantage：局部化 reward，但依赖可靠 attribution；
• value / critic：预测后续回报，可能产生额外偏差；
• group-relative comparison：同题多 rollout 相对排序，减少绝对 reward 标定需求；
• hindsight / counterfactual relabeling：分析失败前缀若换一个动作是否可恢复；
• deterministic intermediate oracle：最可靠，但只存在于结构化子问题；
• teacher token distribution：以强 teacher 的 token-level 密集信号蒸馏。

不要把“dense reward”自动等同于“more truthful reward”。错误的密集信号会比稀疏信号更系统性地塑造坏策略。

2.9 哪些问题用 SFT/RL 修，哪些不该交给模型

原则：确定性可保证的正确性放在系统；需要在不确定环境中泛化的选择交给模型。

3. Tool-use 与 Long-horizon Trajectory Training

3.1 训练对象已经从 answer 变成 stateful trajectory

一条可训练轨迹至少应记录：

task_id / task_version / source provenance
environment image + repo commit + dependency lock
harness version + system prompt hash + tool catalog hash
model checkpoint + tokenizer + chat template + decode config
observation_t
assistant tokens_t + tool-call arguments_t
tool result_t + artifact handles + effect receipts
state transition / sandbox snapshot
reward components + verifier version + judge rationale
termination reason + resource usage

缺少这些字段，轨迹无法判断是“模型失败”“环境坏了”“工具返回变了”还是“verifier 漏洞”。只保存可见 transcript 也不足以重建 token-faithful training sample。

3.2 五种轨迹学习范式

1. 成功轨迹 SFT：复制专家或强模型完成路径；样本效率高，探索性弱。
2. 拒绝采样 / ranked FT：同题采样多个轨迹，保留 verifier 通过者或按 reward 加权。
3. 在线 Agentic RL：当前 policy 在 sandbox 中滚动，reward 回传更新；分布匹配好，成本与方差高。
4. 离线 / off-policy RL：复用旧 policy 或生产 trace；吞吐高，但 importance mismatch 与陈旧工具协议严重。
5. 蒸馏与能力整合：多模型、多 effort、多 harness 教师汇入统一 student；关键是保留条件控制，不把互相矛盾策略平均掉。

3.3 为什么 long-horizon rollout 基础设施本身是模型能力的一部分

训练长 Agent 需要同时维持：

• 可暂停/恢复的 sandbox state；
• trajectory 与 policy checkpoint 的版本关系；
• 长 context 的 KV / recurrent state；
• tool side effects 与 verifier 隔离；
• rollout straggler、GPU utilization 和 learner staleness；
• 失败环境是否可重现；
• 并发数万环境时镜像、网络、存储和密钥隔离。

[事实] ProRL Agent 将 sandboxed multi-turn rollout 解耦为 API 服务，并报告在软件工程、数学、STEM 和 coding 任务上验证该设计。[推断] 这说明至少在该系统中，rollout lifecycle 已经值得作为独立基础设施边界，而不是 trainer 里的内部函数；它不证明 rollout-as-a-service 是所有规模下的唯一正确拓扑。

[事实] Polar 把任意 harness 当黑盒，代理 LLM API 并重建 token-faithful trajectory。其预印本实验用同一 Qwen3.5-4B 和 simple GRPO，在 Codex、Claude Code、Qwen Code、Pi 四种 harness 上的 SWE-Bench Verified 增益分别为 22.6、4.8、0.6、6.2 个百分点。[推断] 这组单论文结果支持“RL 收益会与训练 harness 发生显著 interaction”，因此报告提升时必须带上 harness；它还不足以给出所有模型或任务上的通用 effect size。

3.4 大规模真实工具环境

[事实] ToolVerse 的 v1 预印本报告从近 400 个真实 MCP、约 4,500 个工具构建可执行训练环境，以 tool dependency graph 和 Dynamic Unlocking Sampling 生成长程任务，并提出 Turn-Aware Relative Advantage 缓解 credit assignment。这里的规模、性能与“真实”均沿用作者定义，尚不等于对 4,500 个工具的生产可靠性验证。

重要推论：

• 工具数量不是能力；真正难点是依赖图、参数约束、状态转换和跨工具证据；
• tool catalog 分布越大，越需要 schema canonicalization、权限隔离与可复现 mock；
• MCP server 的实时变化会让训练环境非平稳，必须固定版本或记录完整 capability manifest；
• 在少量 synthetic tool 上学会格式，不等于在真实工具生态学会语义。

3.5 Curriculum 应按“决策结构”而非只按轨迹长度

有效的 Agent curriculum 可以逐步增加：

• 工具依赖深度；
• observation 噪声与反事实；
• delayed reward；
• 需要回滚/恢复的失败；
• 并行与冲突；
• 长 context 中的干扰项；
• verifier 不完备和开放式质量；
• environment drift。

仅把 turn limit 从 20 增到 200，会训练出更长的循环，不会自动训练出长程控制。

3.6 训练分布与部署分布

定义部署风险来自以下差异：

缓解手段不是笼统“多加数据”，而是：版本化协议、跨 harness 训练、held-out environment、adversarial shift、生产 trace 去隐私化回放、reward component audit，以及 train/serve 完全相同的 tokenizer、template、quantization 和 tool serialization。

3.7 Kimi K3 的 agentic post-training 管线

以下均为 [事实]，来自 Kimi K3 官方技术报告核验快照：

1. 三阶段：SFT 冷启动 → 按领域和 reasoning effort 训练 RL experts → Multi-Teacher On-Policy Distillation（MOPD）整合为统一模型。
2. RL 覆盖 general、general agents、coding agents 三大域；每域训练 low/high/max 三档，共九个 expert policies。
3. SFT 轨迹由前代 Kimi 的领域专家合成，经多阶段验证与 human-in-the-loop annotation，并用 XTML chat template 统一序列化。
4. partial rollout 在一部分轨迹完成后开始优化，未完成轨迹跨 iteration 暂停/恢复；per-token regularization 用于承受极端 policy staleness。
5. reasoning-effort RL 为每题估计初始预算 (b_0(x))，超过 (\tau b_0(x)) 的轨迹 reward 置为 -1，再通过 anneal (\tau) 得到不同 effort expert。Agent 任务预算计算包含 reasoning 与 tool-call arguments 的累计输出 token。
6. 开放任务使用 Agentic Generative Reward Model：先读产物、生成 rubric、逐候选评分、写 scorepad；同时用 verbosity budget 抑制“更长就更好”的 reward hacking。
7. 统一 white-box RL environment 把 tools、system prompts、context management、skills、memories、subagents 等模块化，并动态实例化 Kimi Code、Claude Code、Codex、OpenClaw、Hermes 等不同配置，以降低单一 harness 过拟合。
8. 训练环境包括软件工程、kernel optimization、视觉在环、多步搜索与专业知识工作。不同 task family 的 reward contract 并不相同：AET 使用与 Agent 隔离的独立 verifier，个人助理事件可由 deterministic rules 或 LLM evaluator 评分，web development 组合 deterministic checks 与内部 reward model，非可验证开放任务另用 Agentic GRM。不能统称为“全部使用确定性独立 verifier”。
9. post-training 全程对 MoE expert weights 做 MXFP4、activations 做 MXFP8 的 quantization-aware training；rollout 与训练使用相同量化形态，主动消除 train–inference mismatch。

[推断] 这套设计把 Agent Infra 提升为模型训练接口：tool/state/trace/sandbox 的版本与可恢复性直接决定 policy gradient 是否有意义。Coding Agent 工程师与模型团队的共同语言不应是“prompt 好不好”，而应是 trajectory contract、environment fidelity、verifier validity 与 distribution coverage。

4. Test-time Compute：Depth、Width、Experience

4.1 三个正交轴

这三者不是“多花 token”的同义词。Depth 改变一条轨迹；width 改变搜索覆盖；experience 改变先验与未来采样分布。

4.2 Depth scaling

可用方式：

• 增加 reasoning budget；
• 允许更多 observe–act–verify 回合；
• 失败后基于真实证据 revision；
• 将复杂问题分解为可验证子目标；
• 动态 effort：只有不确定或高风险节点进入深推理。

Depth 有效必须满足 新一步能获得新信息。如果工具没有新 observation、verifier 不能区分进展、context 已污染，更多步骤只会放大先前错误。

4.3 Width scaling

常见选择器：

• majority / self-consistency；
• verifier score 的 best-of-N；
• pairwise tournament；
• 多样性约束后的候选集；
• 分阶段：廉价模型探索，强模型评审；
• 不同 tool strategy / harness / model 的 heterogeneous ensemble。

多数投票只适合答案可对齐、错误近似独立的场景。代码 patch 不是一个标量答案：不同轨迹修改了不同 workspace state，合并本身是新的高风险任务。

4.4 Experience scaling

经验不应是“把历史 transcript 全塞回去”，而应提炼：

• 任务/环境适用范围；
• 曾经的假设、关键证据和反例；
• 成功策略与失败 guardrail；
• provenance、model/harness/tool version；
• confidence、验证次数、TTL 和 invalidation 条件。

[事实] arXiv 标注 accepted to ICLR 2026 的 ReasoningBank v2 从成功和失败轨迹蒸馏 reasoning memory，并以 MaTTS 组合 parallel / sequential exploration；Google Research 的作者解读进一步将其概括为 experience scaling。[推断] 这支持“失败轨迹能产出有用的反事实策略”作为可行方法，而不是普适保证；记忆合并、长期污染和跨域泛化仍是开放问题。

4.5 Agentic test-time scaling 的负结果同样重要

[事实] General AgentBench 的 v1 预印本报告，在其统一 general-agent benchmark 与所测十个 leading agents 上，sequential scaling 受 context ceiling 限制，parallel scaling 受 verification gap 限制，二者都没有带来有效提升。这个负结果的外推范围仅限其任务、实现与预算，不能写成所有 Agent TTS 都无效。

[事实] Scaling Test-Time Compute for Agentic Coding 的 v1 预印本通过把长 rollout 压缩为保留假设、进展和失败模式的结构化表示，再做 Recursive Tournament Voting 与 Parallel-Distill-Refine，报告在 SWE-Bench Verified 和 Terminal-Bench v2.0 取得提升；作者把问题归结为 representation、selection、reuse。这些数字同样属于特定模型–harness–benchmark 配置的自报结果。

两者不矛盾：盲目增加轨迹通常无效；若能压缩轨迹、可靠选择并让后续尝试真正复用信息，scaling 才可能成立。

4.6 预算控制器

高质量 inference policy 应是动态控制问题：

observe difficulty / risk / uncertainty
  -> choose model + effort + width + tools
  -> measure information gain / verifier progress
  -> continue | branch | compress | escalate | stop

停止条件至少应看：

• verifier 是否满足完成定义；
• 最近若干步是否有新 evidence / state delta；
• 剩余预算能否完成最小验证闭环；
• 候选间是否已收敛；
• 不确定性是否来自可通过工具消除的事实；
• 继续动作的边际价值是否低于成本或风险。

4.7 Reasoning effort 的正确产品语义

Reasoning effort 不是“智商档位”，而是 provider/model 对额外内部与外部生成预算、policy 或 route 的控制接口。其影响可能包括：

• reasoning token 数；
• tool-call 前后允许的思考深度；
• 模型或 teacher route；
• latency、cost、cache key；
• refusal / monitorability / verbosity 行为。

[事实] Kimi K3 提供 low/high/max，但必须区分两个公开入口：

• Kimi 开放平台的原生 kimi-k3 用法在 K3 官方 README 核验快照 中标注默认 max，并要求多轮/工具调用时把 API 返回的完整 assistant message 原样传回，包括 reasoning_content 与 tool_calls；这是 preserved thinking history contract。
• Kimi Code 产品的 k3 / k3-256k 在 Kimi Code 模型文档 中标注默认 high。切换 effort 会使既有 cache 失效并重新 prefill；未知 effort 返回 HTTP 400。传 none 会关闭 thinking，但该产品路径随后路由到 K2.6，因此不能把它解读为“同一个 K3 权重的 no-thinking 模式”。

[推断] kimi-k3 与 Kimi Code 的 k3 是不同产品接口，默认值、路由和缓存语义必须由 adapter 显式建模，不能只凭模型家族名称合并配置。

[推断] effort 应在 session 或 task phase 上稳定；频繁逐 step 切换可能让 prefix cache、输出分布和 cost prediction 同时恶化。动态 effort 必须用可测收益触发，而不是“难题一律 max”。

5. Inference：从 token 分布到可执行动作

5.1 请求生命周期

context construction
  -> tokenize
  -> prefix-cache lookup
  -> prefill: process all uncached input tokens
  -> decode: generate one/more tokens iteratively
  -> stream text/reasoning/tool-call deltas
  -> constrained parse / protocol validation
  -> finish reason + usage + cache metadata

核心指标：

• TTFT：time to first token，主要受 prefill、queue、cache hit 影响；
• TPOT / inter-token latency：decode 每 token 延迟；
• E2E step latency：模型 + tool + retry；
• task critical path：并行步骤中真正决定完成时间的链；
• prefill/decode tokens、cache hit bytes、reasoning/output tokens；
• success / verified success per dollar，而不是只看 tokens/s。

5.2 Sampling

给定 logits (z_i) 与 temperature (T)：

[ p_i = \frac{\exp(z_i/T)}{\sum_j\exp(z_j/T)} ]

• (T<1)：分布更尖，通常降低多样性；
• (T>1)：分布更平，提高探索也提高格式/语义错误；
• (T\to0)：接近 argmax，但不等于跨硬件、provider 和并发绝对确定；
• top-k 保留概率最高的 k 个 token；top-p 保留累计概率达到 p 的最小集合；
• frequency/repetition penalties 会改变代码、JSON 和标识符生成，不能照搬聊天配置。

Agent 任务不能只用一个全局 temperature：

• tool arguments、补丁和严格 schema 更需要约束与低方差；
• width exploration 需要刻意制造候选差异；
• verifier/selector 的稳定性往往比 generator 多样性更重要；
• temperature 改变的不只是答案，也改变 tool path、轨迹长度和环境成本。

5.3 Structured output 与 constrained decoding

三层强度：

1. prompt 要求“输出 JSON”；
2. 生成后 parser + repair；
3. grammar / JSON Schema constrained decoding，在 token 级屏蔽非法分支。

第三层只保证语法属于语言，不保证：

• 参数语义正确；
• path 在 workspace 内；
• tool 有权限；
• tool call 不重复 side effect；
• schema 中字符串隐藏 shell injection；
• provider adapter 没有丢字段。

所以顺序应是：constrained decode → schema validation → semantic validation → policy/permission → effect execution → postcondition。

5.4 Tool-call streaming 的边界

模型可能分片输出 tool name、arguments 与 call ID。执行器必须等待完整且验证通过的调用，不能把半包 JSON 当命令。断流时要区分：

• 尚未形成合法 call：丢弃或显式关闭 unfinished message；
• call 已持久化但未执行；
• effect 已开始、结果未知；
• effect 完成但 observation 尚未送回模型。

最后一种与第二种绝不能用同一个“retry inference”处理。

5.5 KV Cache、Prefix Cache、Prompt Cache

标准 softmax attention 在 decode 时缓存过去 token 的 keys/values，避免每步重算；cache 体积随层数、序列长度、KV heads、head dimension 和 precision 增长。Prefix cache 在请求间复用相同前缀的 prefill 结果。

关键工程事实：

• cache 命中通常要求 tokenized prefix 与影响计算的配置完全一致；
• system prompt 中动态时间、随机 tool ordering、不同 effort/model 会破坏 stable prefix；
• cache 是性能状态，不是语义状态；miss 不能改变正确性；
• provider 所说“cache token”可能是计费缓存、服务端 prefix reuse 或显式 prompt-cache object，语义不同；
• 长 session 的 cache retention 有成本与租户隔离问题；
• 不能把 cache key 只做文本 hash 而忽略 model revision、tokenizer、role encoding、adapter 和 quantization。

5.6 长上下文不是长记忆

需要区分：

• advertised window：API 接受的最大 token 数；
• trained length distribution：训练真正覆盖的长度与依赖；
• effective retrieval：在干扰和位置变化下找回关键证据的能力；
• reasoning over retrieved evidence：找到之后能否正确组合；
• managed context：harness 是否检索、排序、压缩、去重；
• durable memory：跨 session 持久化、带 provenance 和 invalidation 的状态。

即便窗口是 1M，也有四类成本：prefill、cache residency、attention / recurrent state 计算、低信号内容对决策的干扰。最优策略通常不是“填满窗口”，而是保持高 evidence density，并保留可回查的外部 artifacts。

5.7 KDA、MLA 与长上下文推理

[事实] Kimi K3 的 93 层由 69 个 KDA 与 24 个 Gated MLA attention layers 组成，按 3:1 混合；KDA 用固定大小 recurrent state 替代随长度增长的 softmax KV，MLA 提供全局 token-to-token attention 并压缩 KV 表示。K3 通过 KDA、context curriculum 与系统共设计支持 1M context。Kimi K3 技术报告核验快照

这不是“没有 KV cache”。混合架构同时维护：

• KDA fixed-size recurrent state；
• MLA 随 token 增长的 KV cache。

官方报告因此设计 unified paged pool、KDA-aware prefix cache、跨设备 KDA Context Parallelism，以及 cache-aware fleet scheduling。混合 attention 的收益不能只从算法 FLOPs 推出，必须连同 kernel、cache、通信与 workload distribution 一起评估。

5.8 Speculative decoding

小 draft model 连续提出若干 token，大 target model 并行校验；接受的 token 保持与 target sampling 分布一致，可降低 decode latency。收益取决于：

• draft-target acceptance rate；
• verification batch 与硬件并行；
• request 长度与并发；
• tool-call 边界、temperature 和 target distribution；
• draft 额外显存与调度成本。

[事实] K3 将 pretraining 的 multi-token-prediction layer 微调成 EAGLE-3 风格 draft，并直接优化与 lossless speculative sampling acceptance rate 相关的 likelihood-based loss；这体现 deployment-aware post-training，而非服务端事后外挂。

5.9 Provider compatibility 的幻觉

“OpenAI-compatible”或“Anthropic-compatible”只说明一部分表面协议。仍要逐项校验：

• role/authority 与 system placement；
• reasoning 的显式/隐式表示及跨 turn 续接；
• tool ID、tool result adjacency、parallel calls；
• structured output 支持子集；
• streaming event order、usage、finish reason；
• context/output limits；
• cache、effort、media、region、retention；
• 400/401/429/5xx 的实际错误语义。

最低公分母 adapter 会静默抹掉模型能力。正确设计是 common core + typed capability negotiation + provider-specific extensions + contract tests。

6. MoE：参数规模、路由与系统代价

6.1 核心机制

Mixture-of-Experts 用 router 对 token 表示 (x) 计算 expert scores，只激活 top-k routed experts：

[ y = E_{shared}(x) + \sum_{i\in TopK(g(x))} w_i E_i(x) ]

它试图让参数容量随 expert 总数增长，而每 token 的计算只随激活 expert 数增长。必须区分：

• total parameters：模型存储与潜在容量；
• activated parameters/token：一次 token forward 实际参与的参数量；
• FLOPs/token：受 architecture、sequence、precision、kernel 影响；
• memory footprint：即使不激活，weights 仍需跨设备存储/加载；
• communication：expert parallel 通常需要 token dispatch / combine 的 all-to-all。

“2.8T 模型等于每 token 用 2.8T dense compute”是错的；“只激活 104B，所以系统成本与 104B dense 完全相同”也错。

6.2 Router 真正要解决的四件事

1. specialization：不同 token 分配到有用的 expert；
2. load balance：避免少数 expert 过热、设备空闲；
3. stability：router score、activation scale 与梯度不坍塌；
4. capacity/placement：给定设备拓扑与 expert placement 可执行。

常见失败：

• expert collapse：大部分 token 集中到少数 expert；
• capacity overflow / token drop；
• 训练路由均衡但线上 domain skew 导致热点；
• router 精度下降使低比特量化损害选择；
• all-to-all 延迟盖过稀疏计算收益；
• batch 太小，expert GEMM 形状碎片化；
• 跨节点 expert placement 使 tail latency 放大。

6.3 “Expert”不等于可解释领域模块

[争议] MoE expert 可能形成统计 specialization，但不能未经 probing 就把某个 expert 命名为“Python 专家”或“数学专家”。Router 是 token-level 动态分配，单个请求会混合大量 expert；post-training 中的“domain expert policy”与 architecture 中的 MoE expert 是两个不同概念。

6.4 Kimi K3 的 Stable LatentMoE

[事实] K3 为 2.8T total、104B activated，896 个 routed experts 中每 token 选 16 个，另有 2 个 shared experts。LatentMoE 先把 full-width representation 投影到较小 latent dimension，降低多 expert 激活的通信与权重流量；Stable LatentMoE 针对报告所述的 activation explosion 与 routing instability，明确加入 routed aggregate 后的 RMSNorm、bounded SiTU-GLU activation 和 Quantile Balancing。官方称整体 scaling efficiency 相比 K2 约提升 2.5×，这是发布方在其综合 scaling 分析下的自报结论，不应解释为所有 workload 的 2.5× 线上加速。

K3 的工程共设计还包括：

• auxiliary-loss-free routing；
• quantile balancing 调整 expert bias；
• MoonEP 用冗余 expert placement 与在线计划实现 rank 间完美负载均衡；
• routed expert weights MXFP4、activations MXFP8，而 attention、router、shared experts 等保留更高精度；
• workload-aware expert GEMM scheduling 与通信重叠。

6.5 MoE 对 Agent 服务的特殊影响

Agent 请求与普通 chat 不同：context 长度、reasoning budget、tool wait 和每轮新增 token 高度不均。MoE serving 因此要同时处理：

• prefilling 百万 token 与短 decode 的异构阶段；
• tool 调用造成的 request pause/resume；
• domain traffic 造成 expert load skew；
• 多轮 prefix reuse 与模型/effort 切换；
• 长尾 request 不能拖垮 batch；
• cache affinity 与 expert parallel 拓扑可能冲突。

最终优化目标不是单 token 峰值吞吐，而是给定 SLO 下的 verified task throughput。

7. Model–Tool–Prompt–Harness 共适配

7.1 Harness 到底是什么

Harness 是围绕模型、把概率输出变成环境行动的执行层，通常包括：

• system/developer instructions 与动态 context；
• tool definitions、schema、serialization 与 adapter；
• loop、step/turn 状态机和 stop policy；
• context selection、compaction、memory；
• permission、sandbox、secret、network policy；
• retry、cancel、recovery、idempotency；
• trace、artifact、verifier 和 eval；
• multi-agent orchestration 与 human handoff。

它不是“system prompt 的别名”。Prompt 只是 harness 的一个可编辑面。

7.2 为什么共适配不可避免

模型训练会内化：

• 特定 tool name 与 argument style；
• 某种 chat template / role boundary；
• observation 的长度、错误格式与语义；
• 默认 loop 节奏和计划格式；
• context compaction 后的摘要形态；
• verifier 能发现什么、容忍什么。

Harness 也会反向针对模型：

• 用提示补偿它常见的遗漏；
• 调整工具粒度和描述；
• 控制 parallelism、effort、输出截断；
• 在 runtime 检测其重复、漂移和 premature finish。

共适配本身不是缺陷；不可见、不可消融、只在单一 benchmark 有效的共适配才是缺陷。

7.3 两项 2026 年关键证据

[事实] Harness-Bench v1 预印本在 106 个 sandboxed offline tasks、5,194 条 trajectories 上，控制共享任务环境、预算与验证协议，同时保留各 harness 的 native execution behavior；作者报告不同 model-harness pairing 在完成率、过程质量、效率与失败行为上差异显著，并将常见问题概括为 execution-alignment failures。

[事实] Claw-SWE-Bench v1 预印本在其 350-task full benchmark 上报告：同一 GLM-5.1 backbone 配 minimal direct-diff adapter 与 full adapter 分别为 19.1% 和 73.4% Pass@1；跨 OpenClaw×九模型及五 claw×二模型 sweep，作者归纳 model choice 改变 29.4 pp、固定模型时 harness choice 改变 27.4 pp。数字只对论文 adapter、预算、patch extraction 与 evaluator 成立，但足以反驳“harness 在该类评测中只是可忽略包装层”。

7.4 归因实验矩阵

遇到失败时，不要凭感觉说“模型不行”。最小矩阵：

要求：相同预算、相同 task version、可重置环境、多次随机种子、完整 trace；否则“模型提升”可能只是多用了 token 或更宽松的 verifier。

7.5 好 scaffolding 的删除测试

模型升级后，每个非基础 contract 的 scaffolding 都应重新消融：

• 是否提高 verified success，而不只提高输出形式一致性；
• 是否降低某类错误但增加另一类错误；
• 是否跨模型、跨任务、跨 budget 成立；
• 是否只是重复模型已经内化的行为，增加 token 和 anchoring；
• 删除后 trace 是否更短、模型是否更能利用真实 observation。

保留稳定的 state/effect/trace/verifier contract；可删除针对旧模型弱点的冗长提示。

7.6 Model–Harness Interface Contract

模型团队与 Agent Infra 团队应共同版本化：

model revision / tokenizer / template
supported roles and authority ordering
reasoning representation and continuation rules
effort semantics and budget envelope
tool schema subset / max tools / parallel call semantics
tool call IDs / result adjacency / streaming grammar
context and output limits
cache-key-affecting fields
media formats and limits
finish reasons and error taxonomy
training harness distribution disclosure
known failure modes and eval slices

没有这个 contract，provider adapter 只能靠线上试错发现隐含差异。

8. Capability Routing：不是“永远上最强模型”

8.1 路由目标

给定任务特征 (x) 与候选配置 (c)，选择：

[ c^* = \arg\max_c \left[\hat P(\text{verified success}\mid x,c)\cdot U - \lambda C_c - \mu L_c - \rho Risk_c\right] ]

候选配置不只是一项 model ID，而是：

model + reasoning effort + context policy + tools + width + verifier + sandbox

8.2 可观测路由特征

• task 类型：问答、局部 edit、repo investigation、长程 build、review；
• context 大小、媒体类型、repo 规模；
• 需要哪些工具与协议；
• 是否有确定性 verifier；
• side-effect / security 风险；
• latency SLO、用户配额、预算；
• 当前 session cache affinity；
• 先前步骤失败类型和不确定性；
• 小模型 probe 的信号，而非仅靠用户 prompt 长度。

8.3 三层路由

1. Admission：任务是否可做、是否需要人批准或更强 sandbox；
2. Initial route：选择最小预计能完成的配置；
3. Escalation：只有在特定证据出现时升级 model / effort / width / context。

升级证据可以是：关键测试反复失败、候选分歧大、retrieval uncertainty 高、剩余风险不可由工具消除。不能把 provider 429、权限错误或坏环境误解为“需要更强模型”。

8.4 Kimi 产品中的真实路由信号

[事实] Kimi Code 官方提供：

• k3：最高 1M context，low/high/max；
• k3-256k：256K 内官方称效果相同、消耗约为 1M 版本的一半；
• kimi-for-coding 与 highspeed：K2.7 Code，后者输出约 5–6 倍速、计费/额度语义不同；
• 切换 model 或 effort 会影响 cache；从 256K 切到 1M 的当前产品路径可保留 cache；
• 关闭 K3/K2.7 thinking 会被路由到 K2.6。

来源：Kimi Code 模型配置。

同日 K3 开放平台 README 使用的原生 API model ID 是 kimi-k3，默认 effort 为 max；上面的 Kimi Code product IDs 默认 high。ID 与默认值属于入口 contract，不应在配置层互换。

[推断] 因此 Kimi Code 的 route 必须把 context headroom、cache continuity、tool critical path、套餐能力与 effort 共同纳入。若任务时间主要耗在 build/test，切换到高速 decode 模型不一定显著降低 E2E latency。

8.5 路由自身的评测

• oracle regret：相对事后最佳配置损失多少；
• under-route rate：选择过弱配置导致本可避免的失败；
• over-route rate：无收益地使用昂贵配置；
• escalation precision / recall；
• cache disruption cost；
• per-slice success / cost / latency / safety；
• route stability：相似任务不应随机跳配置；
• fairness / access：套餐与区域限制是否被错误包装成模型失败。

9. 失败分类：先定位所有者，再谈修复

9.1 八层 failure taxonomy

9.2 模型/推理层的典型深层失败

Observation neglect

模型生成了合理计划，但工具已经返回反例仍沿旧计划执行。诊断要看 tool result 是否真的进入下一请求、是否被 truncation，以及模型对 result 的引用与动作是否一致。

Premature convergence

找到一个 plausibly correct patch 就停止，没有运行足够 verifier。可能来自 SFT 中大量“写完即答”的短轨迹，也可能是步数/成本 reward 过强。

Overthinking

更多 reasoning 反而引入错误假设、延迟和 context pollution。高 effort 的价值应在任务 slice 上测量，不是默认单调。

Exploration collapse

RL 训练使 entropy 过早下降，模型只重复少数高 reward 轨迹，对环境变化脆弱。必须监控 action/tool diversity、token entropy、route concentration 与 held-out transfer。

Tool syntax success, semantic failure

调用完全合法但工具选择、路径、参数语义错误。schema parse rate 高并不代表 tool-use 能力高。

Reward mirage

删测试、硬编码 fixture、取巧 judge、堆砌冗长产物赢得 preference。修复顺序是关闭 verifier loophole，再补 adversarial trajectory；单纯施加“不要作弊”提示不是根治。

Long-context dilution

窗口未超限，关键约束却被大量低价值日志、重复文件和旧计划淹没。应看 evidence recall、attention proxy/context utilization、compaction preservation，不应只看 token count。

Off-policy/harness overfit

在训练 harness 中熟练，换 tool schema、context policy 或错误格式后崩溃。必须做 held-out harness 和 protocol perturbation。

Calibration failure

模型在不可验证状态高置信完成，或在已有充分证据时无休止探索。需要独立测 stop/abstain/escalate decision，而不是从最终答案语气猜置信度。

9.3 不可接受的“修复”

• provider 出错就无限 retry；
• tool schema 变了就在 prompt 里贴更多示例；
• context 漏证据就永久扩大窗口；
• verifier 不可靠就让另一个同源模型再投票一次；
• 单 benchmark 下降就增加固定 checklist；
• 模型偶发重复就按字符串去重所有 calls，忽略合法轮询；
• 把未知 side effect 当“未执行”重放。

这些做法隐藏真实 ownership boundary，常把一次显性失败变成静默错误。

10. 可观测性：看见模型实际收到什么、做了什么

10.1 Model invocation span

每次 inference 至少记录非敏感结构字段：

trace_id / session_id / turn_id / step_id / request_id
model / provider / endpoint / revision / effort
template_version / prompt_hash / tool_catalog_hash
input_tokens by role / output / reasoning / cached tokens
context_manifest: source, rank, token count, truncation/compaction lineage
sampling config / max tokens / stop config
queue / TTFT / decode / total latency
stream event counts / finish reason / raw provider error code
tool-call IDs / argument validation result
cost / quota source / route decision and alternatives

不能记录 secrets、完整私有代码或隐式 reasoning 作为默认 telemetry。需要内容调试时使用采样、授权、脱敏与严格 retention。

10.2 Trajectory trace

推理 span 必须与环境 evidence 相连：

• observation artifact ID 与截断策略；
• action 的 effect class；
• permission decision；
• tool start/end、exit code、stdout/stderr artifact；
• workspace / sandbox state version；
• verifier 输入、版本、分量分数；
• retry/cancel/recovery transition；
• terminal reason。

10.3 需要监控的模型健康信号

10.4 Trace 不等于真相

• 可见 chain-of-thought 不是模型全部计算，也不保证忠实；
• 模型写“因为测试通过”不如真实 test receipt；
• span 成功只代表 API 成功，不代表 task 成功；
• final answer 与 workspace state 可能分叉；
• judge rationale 可能是事后合理化。

可观测性必须围绕 state transition 和 evidence，而不是围绕模型叙述。

11. Evaluation：从 token 到真实任务的证据链

11.1 五级评测栈

1. Protocol eval：roles、tool schema、stream、finish reason、cache contract；
2. Atomic capability eval：检索、编辑、debug、视觉、shell 语义；
3. Trajectory eval：动作质量、反馈利用、恢复、效率、违规；
4. End-to-end task eval：隐藏 verifier 下的 verified success；
5. Deployment eval：真实分布、成本、延迟、安全、人类 override、长期 drift。

只做第 4 级无法定位为什么失败；只做 1–3 级无法证明能完成真实任务。

11.2 Eval Card 必填项

task source / license / timestamp / contamination risk
task and environment version / reset semantics
model revision / provider / quantization
harness commit / prompt / tools / compaction / memory
decode config / effort / width / turn and token budgets
network and sandbox policy
verifier implementation / hidden tests / judge model and prompt
number of runs / seeds / confidence interval
failure accounting: infra, model, invalid task, timeout, refusal
cost / latency / token / tool-step metrics
artifact and trace availability

11.3 Pass@k、Best-of-N 与单次可靠性

若单样本成功概率为 (p)，且样本独立，至少一个成功：

[ pass@k = 1-(1-p)^k ]

真实 Agent 轨迹错误高度相关，且找到成功候选需要 verifier，因此该式往往高估 width 的产品收益。必须同时报：

• pass@1 / pass@k；
• selector-selected success；
• oracle success；
• selection regret；
• 总 compute / wall time；
• 候选相关性与环境冲突。

11.4 Verifier 必须被评测

对一组人工审计的正确/错误产物，测：

• false accept / false reject；
• coverage by requirement；
• reference solution pass rate；
• mutation testing：故意注入错误能否捕获；
• judge–human 与 judge–judge agreement；
• verbosity、style、model-family bias；
• reward hacking red-team。

[事实] OpenAI 在 2026-07-08 发布的 SWE-Bench Pro 审计中，自动/agent-assisted pipeline 判定 200/731（27.4%）任务 broken，独立 human annotation campaign 判定 249/731（34.1%），据此估计约 30% 的任务 broken，并撤回此前采用该 benchmark 的推荐。其列出的主要问题是 overly strict tests、underspecified prompts、low-coverage tests 与 misleading prompts；这些是 OpenAI 的审计结论，不是 benchmark 维护方的共同裁定。Separating signal from noise in coding evaluations

11.5 训练 eval 与产品 eval 要分开

• 训练 eval 需要高频、低成本、可归因，允许 proxy；
• release gate 需要严格 held-out、污染审计、完整预算；
• product eval 需要真实任务分布与人类价值；
• safety eval 需要 worst-case attacker，不用平均成功率稀释；
• regression eval 需要固定 canary，但还需滚动新任务防 overfitting。

11.6 模型升级的决策表

12. Kimi K3 / Kimi Code 映射：公开事实与面试判断

12.1 K3 模型层事实卡

来源均为 Kimi K3 官方仓库与技术报告核验快照：

12.2 K3 benchmark 披露最值得学习的不是分数

[事实] K3 报告明确：

• 不同模型可能搭配各自原生 harness；
• K3 在 DeepSWE、Terminal-Bench、Kimi Code Bench 等使用 Kimi Code；
• Kimi Code Bench 2.0 是 in-house benchmark；表中 K3 + Kimi Code 为 72.9，脚注另报 K3 + Claude Code 为 73.7，均为发布方自测，不能视作独立 leaderboard 结论；
• BrowseComp 默认在 300K tokens 触发 compaction，同时报告 1M 原始 context 无管理的结果 90.4；
• 多项评测披露 effort、fallback、refusal、turn limit 或硬件设置。

K3 表格中所有 K3 结果使用 reasoning_effort=max、temperature=1.0；单步任务使用 top_p=0.95，agentic tasks 使用 top_p=1.0。横向模型数字部分来自外部 leaderboard、第三方测评或各厂商发布，并非统一 harness、统一硬件、统一 fallback policy 下的严格受控实验。因此这张表适合读“披露契约”和大致能力位置，不适合从小分差推断模型优劣。

这建立了正确的 agentic evaluation contract：model、harness、context management、budget、fallback 和 verifier 一起报告。

12.3 Kimi Code 产品层映射

Kimi Code 公开仓库核验快照显示它是可配置 provider 的终端 Coding Agent，公开功能包括文件读写、shell、搜索、网页、MCP、skills、hooks、subagents、ACP 与多客户端。对模型层意味着：

12.4 面试中可以提出的高质量判断

以下是 [推断]，必须以“基于公开资料，我会验证”表达，不能冒充内部事实：

1. K3 已把 harness diversity 纳入 RL，Kimi Code 团队的 trace schema 与工具契约可能直接影响后续训练质量；首要资产是可版本化、可复现的 trajectory，而不是 prompt 集合。
2. k3 与 k3-256k 的 route 不应只按当前 tokens；还应预测任务剩余 context、compaction 风险、cache continuity 与验证成本。
3. KDA/MLA hybrid 让 cache observability 复杂化；产品侧至少需要区分 prefill、cached prefix、reasoning、tool wait，避免把所有消耗都归为“模型慢”。
4. 多 harness RL 并不保证跨 harness 泛化；需要 held-out adapter、schema permutation 与 tool semantics perturbation。
5. K3 变强后，旧的 checklist/prompt scaffolding 可能限制 native policy；应通过组件消融保留真正提供因果收益的部分。
6. Model/harness 共同优化容易产生局部最优；最终 release gate 必须包含真实用户任务、独立 verifier 和非训练 harness。

12.5 不该说的过度推断

• “K3 有 1M，所以不需要 retrieval/compaction”；
• “2.8T 所以每 token 都比 100B dense 贵 28 倍”；
• “896 个 expert 就是 896 个可解释技能”；
• “K3 的 reasoning effort 就是简单多生成几倍 CoT”；
• “某 benchmark 高说明 Kimi Code loop 一定最好”；
• “公开仓库就是线上服务全部内部实现”；
• “RL 轨迹越长，Agent 能力越强”。

13. 2025–2026 前沿：事实、推断与争议

13.1 已有强证据支持的结构变化

1. 训练对象从 answer 走向 trajectory：ToolVerse、ProRL、Polar、K3 都把环境、工具、sandbox 和长程轨迹放进 RL 主循环。
2. Harness 是实验变量与训练变量：Harness-Bench、Claw-SWE-Bench、Polar 和 K3 的 multi-harness environment 给出一致方向证据。
3. Test-time scaling 需要 controller：纯 depth 遇到 context ceiling，纯 width 遇到 verification gap；representation/selection/reuse 决定边际收益。
4. Deployment 进入 post-training：K3 在 SFT/RL 阶段做 QAT，并训练 speculative draft，减少量化和服务 mismatch。
5. 长上下文与 context management 共存：K3 在 1M 模型上仍对 BrowseComp 使用 300K compaction，这是一项直接反例。

13.2 仍在快速发展的方向

• verifiable process reward 能否从结构化 oracle 扩展到开放软件工程；
• 从真实生产 trace 做安全、隐私保留、低偏差的 on/off-policy learning；
• 自动生成并演化 harness 时如何防 benchmaxxing；
• model-harness 联合训练后如何保持 cross-harness generalization；
• test-time experience 的 provenance、遗忘、反事实冲突与长期污染；
• reasoning effort 如何做按状态自适应，而不破坏 cache 与可预测成本；
• 量化、speculative decode 和 MoE routing 对 agentic policy 的微妙分布影响。

13.3 六个不能草率站队的争议

争议一：Outcome reward 还是 process reward

• ORM 目标直接、可扩展但稀疏；
• PRM 改善 credit assignment，但错误局部标签会强塑形；
• 结论依赖中间 oracle 的可靠性，不存在普适胜者。

争议二：纯 RL 是否比 SFT 冷启动更“原生”

• R1-Zero 证明纯 RL 可涌现 reasoning；
• 其可读性/语言混杂与正式 R1 的多阶段修正说明冷启动仍有价值；
• Agent 工具环境随机探索代价远高于数学 exact-answer，不能直接类比。

争议三：更长 context 还是更强 retrieval/compaction

• 更长窗口降低过早丢信息；
• 但 prefill/cache 成本、信号稀释、位置与干扰仍存在；
• 正确答案通常是大窗口 + selection + external evidence + loss-aware compaction。

争议四：Model 更重要还是 Harness 更重要

• 这是错误二分。实证显示二者及 interaction 都大；
• 真问题是目标任务上各层的边际收益、迁移性与维护成本。

争议五：可见 CoT 能否作为真实推理证据

• 它可辅助 debug/monitor，但可能省略、事后合理化或受提示控制；
• Agent 正确性应依赖 actions、observations、effects 和 verifiers；
• 训练过度优化 CoT 外观可能降低 faithfulness。

争议六：MoE 的 total parameters 是否代表“能力规模”

• total parameters 表示潜在容量与存储，不等于每 token compute；
• activated parameters 也不能单独预测质量或延迟；
• architecture、data、routing、training compute、attention 与 serving system 共同决定结果。

14. 深追问：28 组答案骨架

这些不是背诵稿。每题按“定义 → 机制 → tradeoff → failure → evidence → Kimi 映射”展开。

Q1. 模型能力与 Agent 系统能力的边界是什么？

答案骨架： 模型是 observation→action 的概率 policy；系统持有 state/effect/authority/evidence。写出 (P(success)=f(M,D,C,T,H,E,V,B,R))。用“模型说改完 vs Git diff/test receipt”说明事实源。最后说明需用 A/B model、A/B harness 和 context/tool oracle 归因。

Q2. Pretraining、SFT、RL 分别在 Coding Agent 中解决什么？

答案骨架： pretraining 建表征与先验；SFT 建协议和冷启动 policy；RL 在环境反馈下重塑轨迹分布。指出 SFT 的 imitation ceiling、RL 的 reward/credit 风险，以及确定性 effect safety 不应交给任一训练阶段。

Q3. RFT 是什么？

答案骨架： 先澄清 rejection-sampling fine-tuning 还是 reinforcement fine-tuning；前者过滤后模仿，后者直接优化期望 reward。再区分 RLHF、RLVR，讨论探索能力、稳定性、on/off-policy 与 verifier。

Q4. 为什么 pure RL 会产生 reasoning？又为什么还需要 cold start？

答案骨架： reward 对正确结果形成选择压力，策略可发现中间计算；引用 R1-Zero。再讲可读性/语言混杂和 Agent 环境的巨大搜索空间；cold start 提供协议、基本探索和安全先验，但可能限制策略，需保持多样性。

Q5. Outcome reward 与 process reward 怎么选？

答案骨架： 先谈 soundness/completeness/coverage。可验证中间状态用 VPR；开放代码质量中错误 PRM 可能更坏。采用分层 verifier：protocol/effect/task/quality/safety，并审计 reward hacking。

Q6. 长轨迹 credit assignment 怎样做？

答案骨架： trajectory outcome 高方差；列 turn advantage、critic、group-relative、counterfactual、deterministic oracle、teacher token reward。强调 reward reliability 比 density 更重要；用 K3 partial rollout + per-token regularization 说明 infra/off-policy 联动。

Q7. Agentic RL 为什么需要可暂停 sandbox？

答案骨架： rollout 长尾与 GPU learner 利用率冲突，环境 state 不能只重放 transcript；pause/resume 保留 side effects，fork 隔离 judge，snapshot 恢复。引用 K3 AgentENV 和 ProRL；强调 unknown effects 不能盲目 replay。

Q8. 如何从生产 trace 训练，而不把脏数据写进 policy？

答案骨架： 先版本化 task/env/harness/model/verifier；去隐私与 secrets；区分 infra failure、user correction、model failure；只从原始 trace 派生带 provenance 的训练 view；held-out time split；off-policy correction 与 protocol drift；人工审计高影响 slice。

Q9. 为什么 tool-use SFT 在真实 MCP 生态可能失效？

答案骨架： synthetic tool 只教格式；真实工具有依赖图、权限、非平稳 state、长输出与恶意内容。引用 ToolVerse。提出 held-out server/schema permutation、effect verifier 与 manifest pinning。

Q10. Test-time depth、width、experience 有何本质差异？

答案骨架： depth 增单轨迹反馈回合；width 增独立搜索；experience 改变后续先验。分别指出 context ceiling、verification gap、memory contamination。选择依据是信息增益、候选独立性和 provenance。

Q11. 为什么更多 thinking 可能更差？

答案骨架： 没有新 observation 时自我强化错误；长推理引入假设、延迟、context 污染；训练可能奖励冗长。按 task slice 测 high-vs-low verified success、token、loop、calibration，并动态 effort。

Q12. Best-of-N 为什么不等于产品可用？

答案骨架： pass@k 假设独立且有 oracle；真实 patch 候选相关、workspace side effects 不同、selector 不可靠。必须报 selector-selected success、oracle gap、compute 和合并成本。

Q13. Reasoning effort 应如何实现和评测？

答案骨架： 它是 policy/budget/route contract，不是统一 token multiplier。讲 K3 per-problem budget RL、low/high/max 和 cache invalidation。评测同任务分层质量–成本–延迟 Pareto，检查 overthinking 与 effort adherence。

Q14. Temperature 为零能否保证 Agent 可复现？

答案骨架： 不能。argmax 仍受模型 revision、硬件数值、batching、provider routing、tool/env 非确定性影响。可复现需要固定完整 configuration、environment snapshot、tool mocks、seed/decoder 与 trace；生产只追求语义可重复而非 bitwise。

Q15. Grammar constrained decoding 解决了什么，没解决什么？

答案骨架： 保证 token 序列满足 schema 语言；不保证参数语义、权限、effect、路径、注入与 side-effect idempotency。给出 validation/policy/execution/postcondition 链。

Q16. KV cache、prefix cache 和 memory 有什么区别？

答案骨架： KV/prefix cache 是避免 prefill 重算的计算状态；memory 是跨任务可检索的语义/任务状态。cache miss 只能影响性能，memory miss 可能影响决策。讲 exact prefix、model/effort/template key 与隐私隔离。

Q17. 1M context 是否让 RAG/compaction 过时？

答案骨架： 区分 advertised window、trained length、effective retrieval、reasoning 和 managed context；讲 prefill/cache/signal dilution。以 K3 BrowseComp 300K compaction 与 1M raw context 同时报告为证。

Q18. KDA 与 MLA 在 K3 中分别做什么？

答案骨架： KDA 固定 recurrent state、适合长序列；MLA 压缩 KV 但保留全局 token-to-token attention；3:1 hybrid。说明同时维护两种 cache、需要 unified cache manager/KCP，不能说“KDA 没 KV 所以 1M 免费”。

Q19. MoE 的 2.8T/104B 应怎么解释？

答案骨架： 2.8T total 是容量/存储，104B activated 是每 token 激活参数；仍有 expert all-to-all、权重驻留、router 与 batch shape。说明 896选16+2 shared，避免把 expert 当领域模块。

Q20. MoE 为什么可能在线上比训练更难负载均衡？

答案骨架： 生产 domain skew、短 batch、请求长度和 tool pause 不均；expert hotspot 与 tail latency。讲 quantile/load balancing、expert placement、cache affinity 和 workload-aware scheduling，指标用 task throughput/SLO。

Q21. 怎样证明是模型问题，不是 harness？

答案骨架： 固定环境与预算做 model A/B；gold context/tool oracle；raw provider vs adapter；action replay；prompt/component ablation；cross-harness repeated trials。引用 Harness-Bench/Claw-SWE-Bench说明 interaction effect。

Q22. 单一 harness 训练为什么会过拟合？

答案骨架： 模型内化 tool names、error wording、context policy、system prompt 与 loop 节奏。换 schema/adapter 后 policy 崩。方案是模块化、多 harness dynamic composition、held-out harness 和 removal test；对应 K3 white-box RL env。

Q23. 模型变强后 harness 应该变厚还是变薄？

答案骨架： 概率性行为提示应消融变薄；确定性 state/effect/security/trace/verifier contract 保持或加强。判断标准是跨任务因果增益与认知负担，不是代码行数。

Q24. Capability router 如何避免永远选最贵模型？

答案骨架： 优化 expected verified utility minus cost/latency/risk；分 admission、initial、evidence-triggered escalation；用 task/context/verifier/risk/cache 特征；测 oracle regret、under/over-route。用 k3/k3-256k/highspeed 映射。

Q25. 怎么评测一次 Agent 模型升级？

答案骨架： protocol→atomic→trajectory→E2E→deployment 五级栈；固定 Eval Card；多次种子与置信区间；报告 model-harness pair、effort、budget、verifier validity、cost/latency；真实 trace canary + rolling tasks。

Q26. LLM-as-judge 何时可用？

答案骨架： 开放产物需要 rubric 时可用，但应与 deterministic checks 分层；隐藏 model identity/order；控制 verbosity；多人/模型校准；测 false accept/reject、human agreement。引用 K3 Agentic GRM 的 rubric/scorepad/verbosity budget，再指出同源偏差。

Q27. 训练时 rollout 与部署时量化不同会怎样？

答案骨架： logits、routing 和长轨迹错误率发生细微 shift，单 token 小差异可积累成 tool path 分叉。最理想是 deployment-aware PT；K3 在 SFT/RL 同一 MXFP4/MXFP8 QAT，rollout/train 同量化。

Q28. 如果加入 Kimi Code，你会先验证模型–Infra 的哪个接口？

答案骨架： 不假装知道内部优先级。基于公开架构先审计 trajectory contract：每次 inference 的 model/effort/context manifest/tool catalog、每次 effect receipt、compaction lineage、verifier 版本能否闭环；然后做 model×harness×context 的失败归因矩阵。理由是它同时服务 debug、eval、训练与安全。

15. 最终自检：真正“讲透”应能回答什么

• 能严格区分 base model、post-training policy、decode policy、harness、environment 与 verifier；
• 能解释 SFT、rejection sampling FT、RLHF、RLVR、PRM、agentic RL 和 distillation 的不同优化对象；
• 能画出一条 token-faithful、environment-faithful trajectory 需要的字段；
• 能解释长轨迹 credit assignment、policy staleness、reward hacking 和 sandbox lifecycle；
• 能判断 depth/width/experience 何时增加价值、何时只增加成本；
• 能从 logits 解释 temperature，从 request lifecycle 解释 TTFT、decode、cache；
• 能说明 1M window、effective context、compaction 与 durable memory 的区别；
• 能解释 MoE total/activated parameters、router、load balance、expert parallel 与 tail latency；
• 能通过实验区分 model、adapter、context、harness、environment 与 verifier 故障；
• 能把 model/effort/context/cache/tool route 写成受约束决策问题；
• 能给任何 agentic benchmark 补齐 harness、budget、environment、verifier 和 uncertainty；
• 能准确描述 K3 公开 post-training、KDA/MLA、Stable LatentMoE、1M RL infra 与 Kimi Code 产品映射，同时明确哪些只是推断。

16. 一手资料索引

Kimi / Moonshot

• Kimi K3 官方仓库与技术报告（核验快照 7c5be95）
• Kimi Code 官方仓库（核验快照 29c9e2a）
• Kimi Code 模型配置：K3 / K3-256k / K2.7 Code
• Kimi k1.5 v4: Scaling Reinforcement Learning with LLMs

Reasoning / Post-training / Reward

• DeepSeek-R1 v2: Incentivizing Reasoning Capability via RL
• OpenAI: Learning to Reason with LLMs
• Verifiable Process Rewards for Agentic Reasoning v2
• Beyond Outcome Verification: Verifiable Process Reward Models

Agentic RL 与 Rollout Infrastructure

• ToolVerse: Massive Environments and Long-Horizon Tasks for Agentic RL
• ProRL Agent: Rollout-as-a-Service
• Polar: Agentic RL on Any Harness at Scale

Test-time Scaling

• Scaling Test-Time Compute for Agentic Coding
• Benchmark Test-Time Scaling of General LLM Agents
• ReasoningBank v2（arXiv 标注 accepted to ICLR 2026）
• Google Research：ReasoningBank 作者解读
• SETS: Self-Verification and Self-Correction for Test-Time Scaling

Model–Harness 与 Evaluation

• Harness-Bench
• Claw-SWE-Bench
• OpenAI: Separating Signal from Noise in Coding Evaluations

基础架构

• Attention Is All You Need
• Switch Transformers
• DeepSeekMoE
• DeepSeek-V3 Technical Report
• FlashAttention
• vLLM / PagedAttention
• Fast Inference from Transformers via Speculative Decoding

17. 结论

Model 层的核心变化不是“模型会不会调用工具”，而是训练与推理的基本对象都变了：

答案优化
  → 轨迹优化
  → 环境中的状态转换优化
  → model / harness / verifier / serving 的联合优化

但联合优化越强，越需要明确边界：

• 模型负责在不确定性中选择；
• harness 负责把选择变成受控执行；
• environment 提供真实反馈；
• verifier 定义可检查成功；
• trace 使归因与训练闭环成为可能；
• evaluation 证明提升能跨任务、跨 harness、跨预算迁移。

对 Kimi Code 这类长程 Coding Agent，真正的模型工程能力不是背出 RL 算法名，而是能把 trajectory fidelity、credit assignment、test-time control、cache/serving、MoE 系统、harness interaction、verifier validity 连成一个可观测、可验证、能持续演进的整体。