Kimi Code：进行中的回合怎样接住新指令？
固定版本的静态源码切面。 本篇核对
MoonshotAI/kimi-code@75a894e9ad5e8d49509664b3daaa1bbc9bb39432，核对日期 2026-09-23。对象是新版 Kimi Code CLI 的packages/agent-core，不是旧kimi-cli，也不是 Kimi 模型。上游此提交的 LICENSE 为 MIT。本篇没有运行 CLI，也没有证明该提交对应当前安装包。
读完这一篇，应能判断：用户在 Agent 正忙时发来一句“先检查测试，再改文件”，这句话是立刻打断当前工具、排成下一个独立 turn，还是在当前 turn 的下一次模型请求前进入上下文？Kimi Code 的这个实现选择第三种，但存在停止、取消和上限的具体边界。
图的文字版 · 可编辑图源 · PNG 预览 · 逐段代码导读 · 来源台账
正在运行时：先缓冲，后注入
TurnFlow.steer() 总会记录 turn.steer。若已有 activeTurn，它将输入和 origin 放入 steerBuffer 并返回 null，没有在此处创建新 turn，也没有在此处中止正在执行的工具；若没有活动 turn，则走 launch() 启动一个 turn。源码：steer()
runStepLoop() 将 flushSteerBuffer() 安在 beforeStep：缓冲的输入按顺序作为 user message 追加到上下文，随后才执行压缩与注入，再由 loop 构造下一步的模型消息。因此“接住新指令”在这里是step 边界的上下文更新，不是对正在流式生成的模型响应或已发起工具调用的即时重写。源码：缓冲与追加 · 源码：beforeStep
一个容易漏掉的出口是模型本来准备结束且没有 tool_use。通用 runTurn() 此时调用 shouldContinueAfterStop；Kimi Code 的回调先刷新 steer 缓冲，有新输入就返回 { continue: true }，从而再运行一个 step。没有 steer 时才继续检查 goal outcome、Stop hook，最终停止。源码：loop 的停止检查 · 源码：继续优先序
设计取舍：互动性放在 step 边界
这个位置给进行中的 turn 一个接收新意图的机会，又保留了当前 step 的执行完整性。它也意味着 steer 到达后何时被模型看到，取决于当前模型请求或工具何时结束、能否进入下一 step；这里没有“立即生效”的时延保证。这是从上述源码得出的工程推断，不是交互延迟实测。
边界也不等于无条件续跑。runTurn() 在每个 step 前检查 abort 与 maxSteps；取消会 abort 活动 turn，非当前 ID 的定向取消则被忽略。runOneTurn() 把正常、取消、异常分别映射为 completed、cancelled、failed 的 turn.ended。源码：步数与中断 · 源码：取消 · 源码：结束映射
工具执行有另一道控制边界：runStepLoop() 把 authorizeToolExecution 接到 agent.permission.beforeToolCall(ctx)。这能说明权限决策位于工具执行之前，但本篇没有展开不同工具的审批策略、终端 UI 提示或拒绝后的完整消息路径。源码：授权回调
与 Pi、Codex 对同一问题的取舍
| 问题 | Kimi Code 此切面 | Pi 固定版 | Codex 固定版 |
|---|---|---|---|
| 忙时的新输入在哪里等 | TurnFlow.steerBuffer，在 step 边界刷新。 | Agent 的 steering/follow-up 队列；steering 在轮间检查，follow-up 在将结束时检查。 | 本书现有 Codex 篇只研究 exec_command 审批，未核对忙时新输入路径。 |
| 先学到的取舍 | 当前 turn 可以因 steer 继续一个 step；等待时间受当前 step 影响。 | 小核心显式区分插队和后续输入；coding-agent 再负责会话外壳。 | 先区分命令审批与执行沙箱，不能由该篇推断 turn 交互模型。 |
Pi 的对照依据是本书固定版的 Agent.prompt()、队列及 runLoop 导读；Codex 依据是固定版 exec_command 切面。表格不是功能优劣排名，也不把两个项目在不同范围内的“取消”视作等价操作。
学习路径与未覆盖项
先沿代码导读逐步重建 steer → flush → runTurn → continue/stop，再自己画出“新输入在模型停止之前和之后到达”两种时间线。接着读 Pi 的队列与会话，最后读 Codex 的命令审批，区分交互调度与执行授权。自测：若 steer() 返回 null，能否推断输入已被模型看到？若当前 step 一直不结束，图中哪条箭头仍未发生？
本篇主要是固定提交的 TurnFlow 与通用 loop 静态阅读。2026-09-24 又复跑该提交 agent-core 的 3 组 mock 测试，共 68 例通过；其中一个用例确实模拟了等待 Bash 审批时收到 steer，批准后同一 turn 的下一步看到它。测试与环境记录说明了具体命令和局限。我们仍未追踪 CLI/TUI 到 steer() 的全部入口、SDK/RPC 所有调用者、wire.jsonl 持久化与恢复、子 Agent 上下文隔离，也未测真实模型、并发抵达、取消竞争或最大步数附近的实际事件顺序。官方会话文档和子 Agent 文档可作后续入口，不能替代这些尚未完成的源码与运行核验。
图的文字说明 · kimi-code
本图只回答：进行中的 turn 接到 steer 后，模型何时可能看到它？ 上半部从左到右：steer(input) 在有活动 turn 时，把新输入写入 steerBuffer，不在该调用里创建新 turn；下一个 beforeStep 把缓冲按序追加为 user message，之后 executeLoopStep 构建模型消息并发起该 step。蓝色与绿色实线表示这条源码可见的控制顺序，并不表示等待时间固定。steer 与缓冲 · beforeStep · executeLoopStep 的次序
下半部从左到右：若模型完成一步且没有 tool_use，runTurn 在结束前调用 shouldContinueAfterStop；该回调先刷新 steer 缓冲。有新输入则继续下一 step；没有则还要检查 goal outcome、Stop hook，之后才可能结束。紫、绿、红箭头均为控制分支；“无”不是必然直接结束。runTurn 停止钩子 · Kimi Code 的优先序
图边界：取消、最大步数或异常都可能终止当前 turn；它没有描绘 CLI 输入路径、工具审批细节、会话持久化、goal 跨 turn 驱动或子 Agent。依据为固定提交的静态源码阅读，无运行轨迹。上游固定版本 · 步数与中断
图内为印刷可读性压短了两处提示：“缓冲不取消正在运行的 step”涵盖当前模型请求或工具；底部“仍可终止 turn”表示缓冲输入不保证一定进入一次后续模型请求。具体条件以上述正文和代码导读为准。
在线预览稿：书稿仍在校稿，系统篇以文内固定源码版本为准；静态阅读不等于运行验收。