Kimi Code 公共架构与 Coding Agent 面试防守深潜

架构快照：2026-08-03 15:42:09（UTC+8），正文机制与源码 permalink 固定在当时 MoonshotAI/kimi-code main 的 29c9e2a，以保证全文引用属于同一 coherent snapshot。Freshness ledger 已继续复核到当日 17:14:34（UTC+8） 的当前 main 75395f6，新增差异见第 15 节。Kimi K3 事实固定在其官方仓库 7c5be95。岗位要求来自用户提供的 Moonshot AI「Coding Agent 研发工程师 / Agent Infra / MJ000797」招聘 JD 截图。本文不使用简历包装、项目作业或学习计划。

0. 本文怎样区分代码事实、产品表面、体验、推断与不可见后端

公开仓库很容易诱发两种相反错误：只复述类名，或因为一个系统更透明，就把它误认成行业上界。本文使用五种证据类型；全文已有的 [F] / [I] / [U] 分别是其中事实、推断与未知的简写：

• [F-code｜公开代码事实]：能在固定 commit 的公开实现、schema 或测试中直接验证。它证明机制存在于该快照，不自动证明线上默认启用、覆盖所有客户端或效果领先；
• [F-doc｜官方产品表面]：官方文档、发布说明、技术报告或招聘 JD 明确承诺的产品行为。它是公开 contract，不等于核心实现公开，也不等于本人已经实测；
• [X-product｜一手产品体验]：在标明版本、账号、平台、配置和任务条件的 hands-on 使用中实际观察到。体验能暴露 supervision cost、交互摩擦和 failure recovery，但单次体验不能证明内部架构；
• [I-arch｜架构推断]：由多个 [F-code] / [F-doc] / [X-product] 事实共同支持，但官方没有明确宣告、公开材料也不能唯一决定的设计意图或因果解释；
• [U-backend｜不可见后端]：模型服务、云调度、生产 sandbox、策略路由、灰度比例、真实用户分布、评测集、训练数据或组织优先级没有公开证据。

本文没有完成 Kimi Code、Codex、Claude Code、pi 在同版本、同仓库、同权限和同预算下的 hands-on 横评，因此后文不会伪造 [X-product] 结论。凡涉及 Codex、Claude Code 和 pi 的产品能力，若没有公开客户端代码佐证，就严格表述为“官方记录的产品表面”，而不是“实测体验”。

回答 Kimi 相关问题时，最好显式说出证据等级。例如：

公开 v2 代码中，Agent scope 的 wire.jsonl 是可回放状态的持久化聚合边界，这是事实；它是否也是线上所有产品形态唯一的生产事实源，公开信息不足，我不会外推。

本文的核心纪律：代码可以证明机制存在，不能自动证明机制在线上默认开启、效果优于替代方案或覆盖全部内部系统；公开程度衡量的是可验证性，不是产品 frontier 排名。

1. 结论先行：Kimi Code 公开架构到底在解决什么

Kimi JD 的主语不是“模型生成代码”，而是：

让模型在真实代码仓库、真实工具、真实失败和真实长任务中，持续产出可恢复、可验证、可追踪的结果。

公开 Kimi Code v2 把这个问题拆成四个生命周期作用域和六条正交控制面：

这张图包含三个关键判断：

1. 生命周期作用域解决所有权。 配置、工作区能力、用户交互、模型上下文和工具执行不应被塞进一个全局 Agent 对象。
2. journal、context、transcript、telemetry 不是四份重复消息。 它们分别服务恢复、模型输入、用户呈现和聚合分析。
3. Agent loop 本身刻意很“薄”。 它负责 admission、顺序、生命周期和错误分派；compaction、retry、goal、task、dedupe、permission 以服务或 hook 参与，而不是把所有策略硬编码进一个 while 循环。

[F] 这一判断可由 v2 设计约束、scope 实现与下述各领域服务直接验证。

2. 四级生命周期：App → Workspace → Session → Agent

2.1 作用域不是目录分组，而是资源所有权和故障隔离

App scope

• [F] LifecycleScope.App = 0，其子 scope 必须拥有更大的 scope ordinal；DI 创建子 scope 时继承父服务，同时实例化本级 eager 注册服务，OnDemand 服务延迟到首次解析。
• [F] App-scope WorkspaceLifecycleService 维护 live handler registry，并对同一 workspace 的并发 materialization 做 in-flight join。
• [F] App-scope telemetry root 只拥有 appender、enabled flag 和根 context；Session/Agent 通过 withContext 得到不拥有 transport state 的视图。
• [I] 这体现的是“重 primitive、轻业务状态”的进程根：App 可以共享 host filesystem/provider catalog，但不应该替 Session 决定 approval，也不应该替 Agent 保存 turn 状态。

Workspace scope

• [F] workspace identity 由 catalog 管理，目录别名通过 workspaceRootKey 去重；ID 保持兼容的 lexical derivation。
• [F] handlerFor 是 create-or-get；公开实现注明 handler 不单独关闭，随 App container 的 child-disposal cascade 销毁。这里的 “cascade” 是生命周期级联，不要和下文 dynamic DI 的 CascadeEngine 混为一谈。
• [F] 同一个 handler 共享 workspace skills/instructions、agent profile loaders、MCP connection set、fs/fs-watch/process/git、additional dirs、tool veto 与 trust marker。
• [I] 这是成本与一致性取舍：仓库 watcher、MCP connection、指令索引不应按 Session 重复；但常驻 handler 也带来资源上界、失效刷新和多工作区长进程泄漏风险。

Session scope

• [F] Session scope 由 Workspace 的 ISessionLifecycleService 创建；不存在一个 App-level session lifecycle facade。
• [F] create 先 materialize Session，再按 binding 创建 main Agent，最后写 session_index.jsonl；失败会 drain agents、dispose scope 并清理 session dir。
• [F] resume 先从 session index 确认 workspace，再 materialize；同 session 的并发 resume 通过 resuming map 合并。
• [F] close/archive 会先运行 close hooks，drain 所有 Agent，最后 dispose Session。
• [I] Session 是“人与一组 Agent 协作”的边界，而不是“一个 messages 数组”。Approval、question、terminal、todo 和 agent registry 放在此层，允许多个 Agent 共用人机交互内核而不共享 context。

Agent scope

• [F] Agent 生命周期服务在 Session 内维护扁平 registry；main 只是约定 ID，并非 DI 结构中的特殊子类。
• [F] 创建 Agent 时先创建 Agent scope，wire.seal()，登记 session metadata，等待 workspace MCP ready，wire.restore()，绑定 profile/permission，最后激活工具。
• [F] Agent fork 复制 source profile snapshot 和 context messages；Session fork 则复制 per-agent wire journal 并追加 forked record，两者不是同一语义。
• [F] remove 先停止 task、取消 pending/active turn 与 compaction，等待 settle，再 dispose。
• [I] Agent 是模型策略和执行历史的一致性边界；Session 是人机协作边界。把两者合一会让 subagent isolation、单 Agent replay、权限继承和独立 compaction 变得含混。

主证据：scope.ts、WorkspaceLifecycleService、SessionLifecycleService、AgentLifecycleService。

2.2 一个 scope 设计是否正确，看四个问题

1. Identity：它由什么稳定 key 标识？目录别名、session id、agent id 如何避免冲突？
2. Ownership：谁创建、谁销毁、谁等待 in-flight work？
3. Sharing：哪些资源应被子 scope 继承，哪些状态必须隔离？
4. Recovery：scope 重建时，哪些来自 journal，哪些来自 metadata/document，哪些必须重新连接？

面试中不要只说“分层更清晰”。要说：作用域的价值是让生命周期、共享、恢复和权限传播可证明。

2.3 当前 main：Lifecycle Ledger 与动态依赖级联

29c9e2a 已把原先“容器按构造顺序收集 disposable”的机制推进为两个更深的运行时原语：

• [F] Lifecycle Ledger：登记 disposer/effect/child ledger，严格按注册逆序、逐项串行 teardown；单项失败会带 label 报告但不打断后续回滚；支持 reason、child introspection 与可选 registration stack。Scope 和 InstantiationService 已接入 ledger。
• [F] Persistent Dependency Graph：记录“真实已物化实例 → 其所用依赖 generation”的跨 scope 边，而不是只看静态 constructor graph。
• [F] Dynamic Registry：provide / unprovide / update 会触发 tree-wide CascadeEngine transaction：算受影响集合、逆拓扑拆卸、应用 registration change、再按拓扑重建可满足单元；同一 scope tree 的请求串行化，history ring 默认保留 200 条。
• [F] Unit state：至少有 Pending / Activating / Active / Unloading / Failed；Failed 是 sticky，普通同步解析会重抛，而 cascade 中的解析冲突会抛 CascadeConflictError。
• [F｜重要边界] engine 提供可选 onWillCascade abort hook、默认 5 秒等待，但当前 InstantiationService 构造 CascadeEngine 时没有注入该 hook。因此“机制支持 bounded abort”是事实；“当前 Kimi Agent loop 已被动态 DI 更新自动取消并等待 5 秒”没有公开证据，不能外推。
• [F｜重要边界] ledger 内部会 await 异步 disposer，但公开 Scope.dispose() / InstantiationService.dispose() 仍是同步 void API，并对 ledger promise 使用 void。所以可以说 teardown 顺序已显式化，不能说所有 lifecycle caller 都会等待异步资源完全释放后才返回。

[I] 这组增量把 DI 从“构造对象”推向“管理 live dependency generation”。它可能服务 provider、plugin、model、MCP 或配置的热变化，但哪些业务 token 已用 dynamic registry 在线热换、是否允许在 active Turn 中发生，公开代码尚不足以逐项确认。

主证据：ledger.ts、dependencyGraph.ts、cascadeEngine.ts、instantiationService.ts。

3. Turn / Step / StepRequest：公开 loop 的真实控制语义

3.1 三个对象不能混

[F] loop 有四种 admission：

• newTurn：必须携带 turnSeed，总是创建新 Turn；
• activeOrNewTurn：有 active Turn 就加入其 step queue，否则新建；
• activeOrNextTurn：有 active Turn 就加入，否则先放 standalone queue，等待下一个 Turn；
• activeTurnOnly：没有 active Turn 是 bug-indicating error。

这比“用户消息来了就递归调用 agent.run”更强，因为 task completion、steering、goal continuation、background notification 能以不同 admission contract 进入同一执行面。

3.2 一次 step 的端到端路径

关键实现事实：

• [F] pending Turns 是 FIFO，只有队头 Turn 运行；每个 Turn 有自己的 StepRequestQueue 和 AbortController。
• [F] batch 中一个 driver request 加若干 mergeable requests；context 只在 request 真正 materialize 时写入，避免排队输入提前污染当前模型上下文。
• [F] loop 自己不决定“下一步再调用模型”。需要 continuation 的 tool/hook/error handler 自己 enqueue request；loop 只消费、排序和分派。
• [F] maxStepsPerTurn 在每次取 batch 前检查；provider retry 重新排队为正常 step，因此消耗同一个 step budget。
• [F] streamed partial content 只在 turn abort 时从 collector 补写；完整 response 在 request finish 后写入 context。
• [F] finish reason 会规范化为 tool_use / end_turn / max_tokens 等事实，并记录 LLM first-token、server decode、client consume 等 timing。

主证据：loopService.ts、stepRequest.ts、stepRequestQueue.ts。

3.3 Cancel、interrupt、retry、recover 不是同义词

独立判断： retry 是错误语义，不是统一装饰器。网络失败可能 retry；命令产生 partial effect、用户拒绝权限、schema 设计错误、逻辑验证失败都不应盲重试。

3.4 Crash recovery 的公开边界

• [F] 可回放 domain state 主要来自 per-Agent wire；session metadata、task output、plan files 等使用独立持久化对象。
• [F] replay 后，正在运行的 compaction 被归一为 cancelled；active goal 被归一为 paused；后台 task 由 wire 与 disk records reconcile 成 live/ghost/terminal 状态。
• [F] in-memory TurnJob、AbortController、promise locks、active request 都不会被 snapshot；进程重启后不能“从 LLM token 中间继续”。
• [I] 恢复语义是“重建已知事实并安全决定下一动作”，不是“恢复所有内存对象”。
• [U] 公开代码没有证明所有外部工具 effect 都有 exactly-once receipt；shell、网络 API、Git remote push 等仍需要工具级 reconciliation。

3.5 当前 main：coded error 是控制协议，不是日志格式

[F] 29c9e2a 的前序提交 3e42521 将 agent、session、app、workspace、OS、persistence、wire、provider 和 MCP 的领域失败迁到 Error2：code 形如 domain.reason，注册表携带 retryability/public/action 等元数据，RPC 通过统一 payload 序列化。外部错误在领域边界翻译；跨 wire 按 code 分支，不依赖 message 或 instanceof。

[F｜边界] 不是“任何 throw 都已 coded”。官方错误规范仍明确保留 _base guard/infrastructure errors、进程内 control-flow sentinels、CyclicDependencyError、PathSecurityError 等例外。retryable 也只是错误元数据；是否真的重试仍由 loop/provider/task 等 owning policy 决定。

面试要点：错误 taxonomy 同时约束 retry、用户动作、RPC 向后兼容、telemetry 聚合与恢复策略；如果只把 error code 当日志 tag，仍然没有设计错误语义。官方 errors 规范。

4. Wire：可回放事实、领域模型与事件日志

4.1 Wire 是 Agent-scope consistency boundary

[F] 一个 Agent 拥有一个 wire.jsonl。WireService 同时拥有：

• Op registry 与 schema；
• 由 Op reducer 得到的多个 domain model；
• append-only JSONL journal；
• protocol metadata 与版本迁移；
• blob dehydration/rehydration；
• replay 后有序 hook；
• cross-model reducer；
• dispatch cascade 上限（MAX_DRAIN = 100），防止 Op cycle。

这意味着业务调用者只做 wire.dispatch(op)，不自己协调“先改内存还是先写 journal”。不过必须准确描述其一致性：

• live dispatch 先同步 reduce in-memory model；
• 持久化 append 可能进入异步 queue/buffer；
• flush() 才显式等待 per-wire queue 和 append store；
• 因而它是单进程内的有序事实聚合，不应未经证据称为数据库意义上的同步 WAL 或 exactly-once log。

4.2 Restore 的完整顺序

read JSONL
  -> tolerate torn final line at append-log decoder
  -> validate first metadata envelope
  -> resolve protocol migrations
  -> validate record type/schema
  -> silent replay through reducers
  -> atomic rewrite if migration/healing needed
  -> rehydrate surviving model state blobs
  -> mark ready
  -> run ordered onDidRestore hooks

精确故障语义：

• [F] torn final JSON line 被丢弃；中间 JSON corruption 由 append store 抛错。
• [F] 能解析但不是 WireRecord、未知 op 或 payload schema 不合法的 record 会被跳过并报告 unexpected error；当前 main 把这类报告编码为 wire.unknown_record。restore() 的公开返回类型仍是 Promise<void>，所以不能声称 caller 会收到结构化的 lossy-recovery summary。
• [F] malformed metadata 是 storage corrupted；老协议执行 migration 后可原子 rewrite。
• [F] blob 只对最终 surviving model state rehydrate，避免恢复已被后续 Op 覆盖的历史大对象。
• [I] “跳过未知/坏 record”偏可用性；对 goal、permission、effect receipt 等高风险事实，是否应该允许跳过需按 record criticality 分级，公开实现目前是通用策略。

主证据：wireService.ts、record.ts、appendLogStore.ts。

4.3 Wire、EventBus、Transcript、Telemetry 的四分法

[F] 官方 Session 文档直接说明 agents/*/wire.jsonl 用于 recovery/replay，也含 request trace。Sessions and context。官方 Agents 文档另行警告 session/wire/task 本地调试材料可能含 prompt、命令输出、repo path、tool result 或 credential trace，不能直接公开分享。Agents and Sub-Agents。

[I] 一个成熟 Agent 系统应允许四个投影互相 join，但不能让任何一个 surface 垄断所有职责。否则 UI 兼容、隐私、恢复和模型协议会互相锁死。

5. Context：Memory、Projector、Compaction 是三种不同机制

5.1 ContextMemory：保存模型历史，不等于 transcript

• [F] AgentContextMemoryService 的 state 直接来自 Wire 中的 ContextModel。
• [F] append/clear/undo/applyCompaction 都通过 Op 持久化；splice-shaped live mutation 发布 context.spliced，replay 静默重建。
• [F] loop 把 step.begin / content.part / tool.call / tool.result / step.end 记录为 loop event，再由 context fold 构造消息历史。
• [F] undo 会计算安全 cut；若切断已测量 token prefix，会回退为 token estimate。
• [F] 当前 main 把 conversation undo 明确为 checkpoint protocol：context.undo 是唯一持久化 undo fact；Todo、Plan、task-notification delivery 等必须用 defineCheckpointedModel，在同一个 conversation clock 上 push/clear/restore。Turn counter、task registry、revision counter 等 world-time state 必须留在 checkpoint 外。

ContextMemory 回答的是：下次模型可能基于哪些历史事实继续推理？ Transcript 回答的是：用户应该看到怎样的对话/任务投影？

5.2 ContextProjector：从存储历史得到 provider-valid wire messages

Projector 是纯 read-side transform，公开实现会修复：

• tool result 与 call 错位：移动回 slot；
• call 缺 result：合成明确的 interrupted result，禁止模型假设成功；
• orphan result：丢弃；
• duplicate call/result id：去重；
• leading non-user message：strict projection 丢弃；
• consecutive assistant messages：合并；
• blank/vacuous content：清理；
• provider request 过大/格式不兼容：只在投影层 degrade/strip media，原历史不改。

[F] 非普通 trailing synthetic repair 会形成去重 warning 和 context_projection_repaired telemetry。这个设计很重要：repair 可以提高可用性，但 repair 不能静默。

[I] Projector 是协议防腐层，不是 correctness verifier。它能让消息合法，却不能证明合成 result 与真实外部 effect 一致。

主证据：contextMemoryService.ts、conversationTime.ts、contextProjectorService.ts。

5.3 FullCompaction：并发运行、必要时阻塞的状态转换

公开 full compaction 不是简单 messages = [summary]：

1. 在 turn 内预留 compaction slot；manual compaction 要求 loop idle；
2. 根据 system prompt、active tools 与 context 估算真实 request tokens；
3. pre-step 检查阈值，可先启动 compaction，达到 blocking threshold 才阻塞 turn；
4. provider overflow 被 loop error handler 捕获后，compaction 完成并把失败 driver 重新排头；
5. compaction LLM 请求移除 dynamic-tool context，附加 handoff instruction；
6. overflow 时按 0.7/0.5/0.35 预算逐级保留近期消息；empty/truncated summary 时逐步丢最老消息及 leading tool results；普通 retryable generate error 做退避；
7. 应用前检查当前 history 是否仍以 original history 为 prefix，新增项是否全是真实用户输入；否则取消，避免并发覆盖；
8. summary 后附当前 TODO，写回 ContextModel，刷新 system prompt，并由 injector 重注入必须状态；
9. 记录 tokens before/after、dropped count、retry、duration、usage、trace。

正确理解：

• compaction 是 memory transition，不是 UI 摘要；
• prefix safety 解决并发覆盖，不解决语义遗漏；
• TODO reinjection 和 post-compaction injector 降低关键状态丢失，但不是 completeness proof；
• 观测到 provider overflow 后把 effective max context 降为估算请求的 85%，是 runtime 对 provider 声明不可靠性的适应；
• 长 context 只推迟触发，不消灭选择、缓存、污染、成本和注意力问题。

[U] 公开代码没有披露 compaction summary 的离线 faithfulness/coverage 回归集、线上因果指标或人工审核策略；不能仅凭实现存在声称 compaction“可靠”。

主证据：fullCompactionService.ts、官方 context compression 说明。

5.4 长任务状态不应全部塞进 compaction summary

公开 v2 已把部分长期状态独立化：

• GoalModel：objective、completion criterion、status、turn/token/wall-clock budget、usage；恢复时 active → paused；
• Task persistence：task metadata、output、terminal tail、ghost reconciliation；完成通知通过 StepRequest 重新进入 loop；
• Todo：Session-scope facade 读写 main Agent wire 中的 checkpointed TodoModel；它随 conversation undo 回滚，并在 compaction summary 后显式保留；
• Plan files：大文档外置，wire 保存引用、hash、version；
• Agent profile / permission / additional dirs / MCP：各有明确所有权，不依赖摘要猜回。

独立判断： compaction 保存“继续推理所需的认知摘要”，durable state 保存“不可由模型自由改写的系统事实”。两者反过来会导致 summary 成为未经 schema 约束的数据库。

Goal 主证据：goalService.ts、官方目标模式文档；Task 主证据：taskService.ts。

6. Tool plane：effect contract、冲突调度、结果证据

6.1 工具不是一个 async function

公开 ExecutableTool 分成两阶段：

static definition
  name / description / schema / source / disclosure

resolveExecution(args)
  -> rejected result
  OR runnable execution:
       accesses / approvalRule / display / description
       stopBatchAfterThis / matchesRule
       execute(ctx: signal, trace, onUpdate, metadata)

这个 split 的价值是：在真正执行 effect 前，系统已经能完成 path normalization、风险判断、权限展示、并发冲突判定和 hook veto。

6.2 ToolExecutor 的公开 pipeline

具体事实：

• [F] arguments parse failure、missing tool、source guard、unavailable tool、schema error 都返回 model-visible error result，而非直接炸掉整个 Turn。
• [F] resolveExecution 的 PathSecurityError 被安全地转为 tool result；其他 resolve failure 也携带 tool name。
• [F] onBeforeExecuteTool 可 veto 或注入 execution metadata；permission gate 和 dedupe 都接在这里。
• [F] scheduler 依据 ToolAccesses 判冲突；read/search 与 read/search 可并发，只要任一方写且路径重叠就冲突；未知 access 默认 all，保守串行。
• [F] scheduler 还保持 queue fairness：新任务不仅不能越过冲突 active task，也不能越过先前冲突 queued task。
• [F] tool results 以完成顺序流出；ContextProjector 之后按 tool-call slot 重建 provider-valid 顺序。
• [F] abort 后给工具 2 秒 grace；若工具不响应 signal，host 返回 aborted synthetic result，但无法凭此撤销已经发生的外部 effect。
• [F] 超过 50,000 chars 的纯文本结果保存到 agent storage，模型只看到 2,000-char preview 与绝对 output path；媒体结果不走同一文本持久化逻辑。

主证据：toolContract.ts、toolExecutorService.ts、toolScheduler.ts、toolResultTruncationService.ts。

6.3 Dedupe 不是 cache，而是 loop breaker

公开 dedupe 分两层：

• same-step duplicate：以 toolName + canonical args 为 key；同 batch 内重复调用不重复执行，而是等待 original result；
• cross-step repeat：仍允许调用，但累计连续 streak，3/5/8 次注入逐级 reminder，12 次强制 stopTurn。

它还记录 same_step / cross_step、args hash、repeat count 与 action telemetry。

为何不能把所有重复调用都 cache：

• read/search 可能因文件或外部状态变化而应重新执行；
• command/tool 可能有非幂等 effect；
• 同参重试有时是对 transient failure 的合理恢复；
• 真正问题常不是“重复”，而是 Agent 未说明下一次调用要获取什么新增证据。

因此公开设计对 same-step 做确定性抑制，对 cross-step 先提醒、再升级、最终停止，属于保守控制而非错误的通用 memoization。

主证据：toolDedupeService.ts。

6.4 Retry 是 provider error plugin，不是 tool retry

[F] AgentStepRetryService 只匹配 isRetryableGenerateError：典型为 429、5xx、connection、timeout、empty response。它尊重 Retry-After 或 exponential backoff，把原 driver 排到 queue head。

[F] 新 Turn 或任何 step 成功都会清 retry attempt；达到 max attempts 后放弃 claim，让错误落到 loop fatal path。

独立判断： provider retry 和 tool effect retry 必须分离。前者通常发生在模型 response 尚未形成完整 external intent 前；后者可能处在 effect 已发生而 receipt 丢失的 ambiguous state，必须 query/reconcile，而不是再执行。

主证据：stepRetryService.ts。

7. Permission：风险裁决、用户交互与强制边界

7.1 公开 permission chain 的真实顺序

AgentPermissionPolicyService 是 first-match-wins 的有序链：

1. auto mode 下禁止 AskUserQuestion；
2. user configured deny；
3. auto mode approve；
4. session approval history；
5. user configured ask；
6. user configured allow；
7. sensitive file access ask；
8. Git control path access ask；
9. yolo mode approve；
10. low-risk default tools approve；
11. Git cwd write approve；
12. fallback ask。

这条顺序本身就是产品 contract：

• user deny 比 auto/yolo 更强；
• auto 早于 sensitive/git ask，语义接近 unattended approval；
• yolo 晚于 sensitive/git ask，仍保留特定高风险确认；
• session approval memory 可减少相同 rule 的重复打扰；
• fallback ask 让未知工具默认不静默放行。

7.2 Gate、policy、approval 各做一件事

[F] ask 使用 cold waitUntil factory，只有没有其他 listener veto/pass 时才真正启动 approval round-trip，避免无效弹窗。

[F] subagent 被拒绝后会收到更明确的“不重试同一调用、不要绕过限制”的 guidance。

[F] 官方 Hooks 文档明确：hook failure/timeout 默认 fail-open，因此 hooks 适合提醒和轻量拦截，不能作为唯一安全边界。Hooks。

[I] Permission 只裁决 intent，不构成 capability containment。真正强边界还需要 OS sandbox、filesystem path boundary、network egress、secret isolation、workspace trust 和 server auth。

[U] 公开 repo 不足以证明 Kimi 内部 remote execution/sandbox 的生产隔离等级、credential broker、network policy 与审计保留期。

主证据：permissionPolicyService.ts、permissionGateService.ts、toolApprovalService.ts。

8. Evidence plane：request trace、domain events、transcript、telemetry

8.1 可观测性要能定位“第一次错误决定”

公开实现提供的 join keys 包括：

• session id；
• agent id；
• per-Agent turn id；
• step number + step UUID；
• provider tool-call id；
• background task id；
• LLM request trace id；
• compaction source/trace；
• permission policy name与 approval surface。

公开 typed telemetry 覆盖：

• turn started/interrupted/ended；
• tool call outcome/duration/dup type；
• API error classification/retryability/request kind；
• permission policy decision与 approval result；
• compaction finished/failed及 token/latency/retry；
• context projection repair anomaly counts；
• background task created/completed；
• goal status/budget usage；
• subagent created；
• provider/model/thinking switch。

[F] event registry 的设计规则明确禁止把用户内容或文件路径注册成 telemetry properties；App root appender fan-out，Agent events再组合 agent_id context。Cloud appender 还会对 string value 做 URL、email、token 与绝对路径 redaction，但官方明确说这是 safety net，不是采集内容的许可。events.ts、telemetryService.ts。

8.2 有 telemetry 不等于有 eval

Telemetry 只提供样本和分布；评测还需要：

1. task validity：需求、repo snapshot、环境、依赖可复现；
2. outcome oracle：测试、构建、diff invariant、人工 rubric；
3. trajectory attribution：定位 retrieval、reasoning、tool、permission、runtime 或 verifier 的首错；
4. counterfactual replay：只替换一个 component，保持 model/budget/environment 不变；
5. online guardrail：成功率、人工接管、回滚、permission burden、成本、latency、regression segment。

[U] Kimi 内部 trace-to-eval pipeline、failure taxonomy、benchmark 数据和 rollout gate 没有在公开 repo 中完整披露。面试时可以提出设计，但不能声称这就是内部现状。

8.3 推荐的 Kimi 架构级 Eval Matrix

9. Multi-agent 与长任务：公开实现证明了什么

9.1 Main/subagent isolation

[F] 官方文档说明每个 subagent 有独立 context，只收到显式 task description，intermediate trace 不混入 main context，最终 result 才回传；这降低 main context 污染，但每个 subagent 独立消耗 token。Agents and Sub-Agents。

[F] 公开 Session 内每个 Agent 有独立 scope、wire、loop、context、profile、tasks 和 permission mode view；Agent lifecycle 仍由同一 Session 管理。

[F] agent profile 的 tools/disallowedTools 同时影响 tool disclosure 与 execution re-check；subagent allowlist 也在 dispatch 时复核。Permission rules 是另一层控制。

[F] 当前 main 的 secondary-model 功能仍是默认关闭的 experiment，且路由不是强制降级：新 spawn 按 tool-call model > profile model_preference > configured secondary default > 无 secondary 时继承 caller 解析；符号值只有 primary / secondary，其中 primary 是 main Agent 当前实际模型，不必等于 default_model。已 resume 的 subagent 保持自己 wire 中记录的模型。

[F] Agent 默认单任务超时 2 小时，print mode 默认无超时；AgentSwarm 最多 128 个 subagent，默认先启动 5 个、再每 700 ms 增加 1 个，未设置环境变量时不设并发上限。它是产品默认值，不是通用最优策略，也不能外推为内部生产集群的资源配额。Built-in Tools。

9.2 长任务不是一个无限 Turn

公开系统有四种不同 horizon：

• 一个 Turn 内多 Step；
• background task 跨 Step/Turn 运行；
• Goal 跨 Turn 自动 continuation，带 token/turn/wall-clock budgets；
• Session 跨进程 resume；
• Session fork/Agent fork 构造新的分支 identity。

独立判断： 长 horizon 要增加持久化 checkpoint 和外部 verification，不能只提高 maxSteps。无限 Turn 会同时扩大 context drift、partial effect、成本不可控和 incident blast radius。

9.3 公开实现仍不能回答的 multi-agent 问题

• [U] 真实任务中 subagent 的净收益分布、coordination tax 与模型相关性；
• [U] 内部是否用异构模型/verifier 降低 correlated error；
• [U] swarm 默认并发策略在生产不同环境的真实上限；
• [U] artifact merge/conflict 的通用协议是否超出公开 Agent/AgentSwarm tools；
• [U] subagent result 的自动验收与信任分级。

回答时应说：multi-agent 的价值来自 context isolation、并行可分解性和能力差异，不是 Agent 数量本身。

10. Kimi JD 每一条背后的系统问题

10.1 「参与 Kimi Code 核心功能和工程架构建设，构建 Coding Agent 系统」

表面是“写核心代码”，真实问题是：

• 如何划清 App/Workspace/Session/Agent 所有权，避免全局单例与跨 session 状态泄漏；
• 如何让 CLI/Web/VS Code/ACP/SDK 共用核心能力而不把 UI contract 反向污染 engine；
• 如何在 v1→v2、wire protocol、provider schema、plugin/agent profile 扩展中保持兼容；
• 如何把 mechanism 做成 deep module，让新 policy 通过 hook/registry 接入。

面试答题证据应是：能定义 identity、lifecycle、state、effect、projection、protocol 和 failure boundary，而不是“我会 TypeScript”。

10.2 「设计和优化执行循环：任务拆解、工具调用、结果观察、错误恢复、长任务续跑、最终验证」

关键缺口判断 [I]： 公开代码里有 tests/tools/goal completion guidance，却没有看到一个覆盖任意 coding task 的统一 VerificationService。这不一定是缺陷；最终验证往往是 task-specific policy。但面试中应强调：“模型说完成”不是 completion fact。

10.3 「真实代码仓库工具：文件编辑、命令、搜索、测试、Git、沙箱、远程执行」

背后是六个工程层：

1. tool effect contract；
2. filesystem identity、symlink、Git worktree、user edits；
3. PTY/process/background lifecycle；
4. conflict-aware scheduler；
5. workspace trust、permission、sandbox、secret/network boundary；
6. full output/artifact 与 model preview 分离。

公开 repo 能验证 local fs/process/git、path checks、workspace trust 与 permission；remote sandbox 的内部生产 topology 公开未知。

10.4 「仓库级上下文：检索、文件选择、压缩、历史轨迹、任务状态、长期记忆」

这条 JD 实际要求区分：

• acquisition：找到候选文件、symbol、tests、git status；
• selection：哪些信息进入当前 request；
• projection：如何保持 provider message 合法；
• compaction：如何转移认知状态；
• durable state：goal/task/todo/profile/permission；
• memory：什么跨 session 保留，如何防止陈旧和污染。

公开 Kimi Code 对 projection/compaction/durable state 很具体；对 learned repository retrieval、跨 session 长期策略记忆的内部形态公开不足。

10.5 「基于用户任务和 trace 构建失败样本、评测集、分析工具」

真实工作流应是：

user task + pinned environment
  -> wire/request trace/transcript/telemetry join
  -> locate first causal error
  -> failure taxonomy
  -> minimal reproducible eval
  -> one-component counterfactual
  -> regression gate
  -> online guarded rollout

最常见错误是按最终失败文本分类，而不是找首错；或把用户纠正后的成功轨迹直接当 clean training data，忽略 intervention。

10.6 「与模型团队协作，探索模型能力边界，推动协同进化」

模型团队需要 Agent 侧提供：

• 可复现 environment + exact tool schemas；
• 完整 trajectory 与 request trace；
• failure component attribution；
• 相同 model 不同 harness 的消融；
• model capability/protocol differences；
• compaction、tool selection、reasoning effort、context window、cache 的联合成本曲线；
• verifier/reward 的误差审计。

[F] 公开 Kimi Code 已抽象多 provider protocol（Kimi/OpenAI/Responses/Anthropic/Google GenAI 等）与 model capabilities；Providers and models。

K3 技术报告给出了比“模型更强”更有面试价值的协同证据：

• [F] 模型侧约束：Kimi K3 是 2.8T total / 104B activated 的 MoE，原生多模态、1M context；这些能力改变 media、long-context、cache 与 tool trajectory 的设计空间，但不自动消灭 context management。
• [F] Harness-diverse RL：报告明确指出固定单一 harness 会过拟合 tool schema、system prompt、context management 和 interaction protocol；其 white-box RL environment 把 tools、prompt、context strategy、skills、memory、subagents 等做成可组合模块，并可实例化 Kimi Code、Claude Code、Codex、OpenClaw、Hermes 等配置。
• [F] Long-horizon infra：1M agentic RL 使用 partial rollouts、external KV cache、auto-throttling；AgentENV 提供 microVM isolation、incremental checkpoint/resume、fork 与 snapshot。这里描述的是训练/评测基础设施，不等于公开 Kimi Code CLI 的本地执行 sandbox。
• [F] Eval 必须带 harness：报告的 coding baseline 运行于 Kimi Code、Claude Code 或 Codex；部分表格仅 Harness 列标示 K3 所用 harness，其他模型按各自 harness 运行。Kimi Code Bench 2.0 是内部 benchmark；因此不能把模型分数直接解释为纯模型能力差异。
• [F] Context policy 是实验变量：报告在 BrowseComp 用 300K token 触发 compaction，并另外披露 full 1M context、无 context management 的结果。这正说明“窗口大小”和“context policy”必须分开消融。

主证据：Kimi K3 README @ 7c5be95、Kimi K3 技术报告 @ 7c5be95。[U] 公开报告不等于 Kimi Code 内部全部 post-training 数据、reward、线上 harness 或灰度策略。

10.7 「熟悉语言和工程；是 AI 编程工具高度用户」

他们要判断的不是工具数量，而是你能否说出：

• 为什么不同 Agent 的 context acquisition、tool contract、permission、retry、diff presentation 造成不同真实效果；
• 一个失败到底来自模型、provider adapter、harness、environment、verifier 还是产品交互；
• 哪个问题应写 deterministic code，哪个应让模型学习，哪个应靠 eval 验证。

10.8 「LLM Agent 基本机制：Loop、Tool Use、Context、Planning、Memory、MCP、Subagent、Multi-agent、Evaluation、Observability」

这不是术语背诵，而是要求把每一项放回完整链路：

goal/spec
  -> context acquisition
  -> policy/plan
  -> tool intent
  -> permission/capability
  -> effect
  -> observation/receipt
  -> state transition
  -> verification
  -> trace/eval/learning

只会其中一个节点，无法解释端到端可靠性。

10.9 「自驱、发现垃圾、能接受批评」

技术上对应：

• 不把 silent repair、stale docs、duplicate config、opaque fallback 当正常；
• 发现异常先问“哪个 contract 被破坏”，不是先加 retry；
• 用 trace、repro、counterexample 和 eval 说服，而不是审美争论；
• 愿意删除随模型增强而失效的 scaffolding；
• 接受自己的判断被受控实验推翻。

10.10 加分项背后的实际信号

JD 中“AI 能写的代码你能写，AI 写不了的代码你也能写”并不是要求和模型比打字速度，而是要求候选人能够下沉到模型无法替代的 contract：runtime、protocol、state、effect、debugging、migration、security 和 evaluation。高度使用 AI 是生产力习惯，不是逃避理解代码。

11. 事实—推断—未知总表

12. 40 组递进面试追问与高质量答题骨架

每组都按六级压力展开：定义 → 机制 → 取舍 → 故障 → Eval → 反驳。答题骨架不是背诵答案，而是强制你在一次回答里覆盖对象、状态、控制流、边界、证据和不确定性。

A. Scope、lifecycle 与 ownership（1–5）

1. 为什么 Coding Agent 需要 App / Workspace / Session / Agent 四级 scope？

• 定义：这四个 scope 分别代表什么稳定 identity？
• 机制：子 scope 如何继承父服务，又如何覆盖本级 seeded identity/telemetry？
• 取舍：为什么不用一个 global container，也不用每个 Agent 完全自给自足？
• 故障：scope 放错会产生哪类真实 bug：跨 session plan 泄漏、重复 watcher、MCP 连接风暴还是 permission 串线？
• Eval：怎样通过多 workspace × 多 session × 多 agent 的 lifecycle matrix 证明隔离？
• 反驳：“这只是 DI ceremony，普通 class composition 就够了。”你怎么回应？

高质量答题骨架： 先把 scope 定义为 identity + ownership + disposal + sharing contract，而不是 namespace；再给出公开 v2 的父子关系和具体资源。当前 main 还用 ledger 表达逆序回滚、用 instance dependency graph + cascade 表达 live generation 更新；但 abort hook 尚不能外推为已接入 Agent loop，sync dispose() 也不等于 caller await 全部异步释放。然后承认 DI 不是目标，只有当它消除真实生命周期耦合才值得；最后用“错误放置一个 mutable state 后能否被隔离测试捕获”收束。不要用“更优雅”作理由。

2. Workspace handler 为什么是 create-or-get，并在公开实现中不单独关闭？

• 定义：workspace catalog record 与 live Workspace handler 有何不同？
• 机制：handlerFor 如何按 workspaceId 合并 in-flight materialization？目录别名怎样归一？
• 取舍：常驻 watcher/MCP/config cache 换来了什么，又消耗什么？
• 故障：同一物理目录用两种路径打开，会怎样造成 duplicated state 或错误 session bucket？
• Eval：怎样压测 alias、并发 materialize、目录删除重建和长进程资源上界？
• 反驳：“handler 永不关闭一定是内存泄漏。”你如何区分 policy 与 bug？

高质量答题骨架： 区分 durable catalog 和 live capability holder；说明 in-flight join/alias key 保证同一 workspace 单实例；承认“随 App 销毁”是公开当前策略，不等于永远正确；提出以 active handler 数、watcher fd、MCP process、idle duration 和 rematerialization cost 决定是否引入 eviction，而不是凭感觉加 LRU。

3. Session 与 Agent 为什么必须分开？

• 定义：一个 Session 可以有多少 Agent？main 为什么只是约定 ID？
• 机制：Session 如何拥有 approval/interaction/todo/agent lifecycle，而每个 Agent 拥有独立 loop/context/wire？
• 取舍：共享 Session interaction kernel 会不会成为 subagent 瓶颈？
• 故障：把 approval pending state 放 Agent 或 App 各会出什么问题？
• Eval：如何验证 subagent context 不串、approval 不误投、Session close 能 drain 全部 Agent？
• 反驳：“一个会话就是一个 Agent，多 Agent 只需开多个会话。”为什么不等价？

高质量答题骨架： 先定义 Session 是人机协作与恢复容器，Agent 是模型策略/执行历史容器；用独立 wire/context 与共享 interaction 说明边界；再指出多会话无法自然表达同一用户任务下的 subagent、共享 workspace 能力和统一 close；最后承认 Session kernel 需要 correlation id 与公平调度，不能靠共享对象隐式路由。

4. Agent create、resume、fork、remove 的语义差异是什么？

• 定义：create/resume/fork/remove 分别改变 identity 还是只改变 live materialization？
• 机制：为什么 create 要先 wire.seal()、登记 agent metadata、再 restore/bind/activate tools？
• 取舍：Agent fork 复制 context，Session fork 复制 wire；为何需要两种分支？
• 故障：启动中途失败、MCP 未 ready、wire 无 metadata、fork 时 source 正在写入会怎样？
• Eval：如何做 failure injection，证明没有 half-registered Agent 或丢失 journal tail？
• 反驳：“直接复制 messages 数组就能 fork。”你如何指出缺失状态？

高质量答题骨架： 从 identity 和 persistence boundary 解释四种操作；给出 seal-before-visible、flush-before-copy、drain-before-dispose 等不变量；指出 messages 不含 goal/task/profile/permission/trace 等完整事实；对公开代码只声称其已有机制，并把 external effect 与 in-flight request fork semantics 标为需要明确定义的边界。

5. 多 client 如何共享一个 Agent runtime，而不让 UI state 污染核心？

• 定义：engine state、presentation state、transport state 分别是什么？
• 机制：Wire → transcript projection → REST/WS → TUI/Web 的层次怎样工作？
• 取舍：为什么 Web 不直接 import agent-core domain model？
• 故障：WS seq gap、reconnect、delta 丢失、冷 session、客户端旧版本会怎样收敛？
• Eval：如何用 replay/audit trail 验证 REST baseline + WS ops 最终一致？
• 反驳：“直接把 wire.jsonl 推给前端最完整。”为什么产品和安全上都不成立？

高质量答题骨架： 先把 engine fact 与 view projection 分开；说明 transcript 是稳定 client contract，wire 是内部 replay language；指出 projection 会损失部分 live-only detail，必须有 seq/catch-up/full refresh；最后强调直接暴露 wire 会泄露敏感内容、耦合 migration、破坏向后兼容。公开 repo能证明接口形态，线上部署细节不外推。

B. Loop、控制流与错误语义（6–11）

6. Turn、Step、StepRequest 的最小正确定义是什么？

• 定义：三者分别绑定用户意图、LLM request 还是调度请求？
• 机制：driver + mergeable requests 如何组成 step batch？
• 取舍：为什么不让每条 steering/background notification 都新开 Turn？
• 故障：如果 queued request 提前写 context，会怎样污染 active Turn？
• Eval：怎样构造 deterministic fake provider 验证 numbering、materialization、merge 与 stop？
• 反驳：“一个 while(tool_calls) 就够了。”它遗漏哪些生命周期对象？

高质量答题骨架： 用 Turn=工作回合、Step=LLM+tools 原子观察周期、StepRequest=进入 loop 的调度意图；说明 context 在 dequeue/materialize 时才发生；列出 cancel/budget/merge/steer/notification 为什么需要 request object；最后承认简单产品可从 while-loop 开始，但一旦有并发输入、恢复、后台任务和多 client，就必须显式化状态。

7. 四种 admission 模式解决了什么问题？

• 定义：newTurn、activeOrNewTurn、activeOrNextTurn、activeTurnOnly 的 contract 是什么？
• 机制：standalone queue 如何在下一个 Turn 创建时被搬入？
• 取舍：activeOrNewTurn 会不会让后台完成事件意外打断当前思路？
• 故障：错误 admission 最危险的结果是丢消息、重复 Turn 还是跨目标污染？
• Eval：怎样枚举 active/idle/queued/dispose × admission 的状态转移表？
• 反驳：“所有输入都 append 到 messages，模型下次自然看到。”为何不够？

高质量答题骨架： 先把 admission 定义为 temporal ownership；逐一说出无 active Turn 时的语义；强调“何时 materialize”比“最终是否 append”更关键；用 task notification、user steering、goal continuation 各举一个 contract；评测必须验证 assignment receipt、abort 和 exact turn binding，而不只看最终文本。

8. 为什么 loop 自己不 enqueue continuation？

• 定义：mechanism loop 与 policy continuation 的边界是什么？
• 机制：tool、goal、task、error handler、hook 谁负责产生下一 StepRequest？
• 取舍：插件化会不会造成 hook 顺序和隐式控制流复杂？
• 故障：两个参与者同时 continuation、handler claim 后未 enqueue、hook stopTurn 冲突怎么办？
• Eval：如何检查每个 continuation producer 的唯一性、优先级和 causal trace？
• 反驳：“把策略集中到 loop 更容易理解。”什么时候这句话成立？

高质量答题骨架： 强调 loop 只负责 admission/order/lifecycle/error dispatch，策略 owner 负责“为什么继续”；这使 provider retry、compaction recovery、goal continuation 可独立演化；同时承认 hook graph 本身会成为隐式架构，必须有有序注册、domain owner、trace 和组合测试；若系统很小且策略稳定，集中控制流可能更简单，避免为了 extensibility 预付复杂度。

9. Cancel 与 interrupt 如何做到不撒谎？

• 定义：用户 cancel、runtime abort、step cancel、queued Turn cancel 有何不同？
• 机制：AbortSignal 怎样传到 LLM request、tool batch、compaction 与 task？
• 取舍：为什么工具 abort 后还给 2 秒 grace？
• 故障：工具忽略 signal、外部 effect 已发生、stream partial content 已到达时怎么表述？
• Eval：怎样分别测 cooperative、slow-cancel、non-cooperative 和 partial-effect tool？
• 反驳：“只要 UI 停止 spinner，取消就完成了。”哪里错误？

高质量答题骨架： 定义 cancel 是停止继续调度，不是时间倒流；说明 active/queued/step 的不同状态变化；指出 grace 是让 cooperative tool 返回 receipt 的折中，但超时 synthetic aborted result 不能证明 effect 未发生；正确恢复要查询外部状态或标记 ambiguous。评价取消应看 effect containment、zombie process、state truthfulness，而不是 UI latency 单指标。

10. Provider retry 的边界在哪里？

• 定义：retryable generate error 与 semantic failure 有何区别？
• 机制：Retry-After、backoff、failed driver、head requeue、max attempts 怎样组合？
• 取舍：retry 消耗 step budget是优点还是缺点？
• 故障：stream 已产生部分 tool call 后网络断开，能否安全 retry？
• Eval：怎样评测 success lift、额外 latency/cost、duplicate intent 与 rate-limit amplification？
• 反驳：“所有 5xx 都 retry 三次是行业标准。”为什么仍可能错？

高质量答题骨架： 以 error phase + response commitment + idempotency 决定 retry；公开 stepRetry 匹配 provider error，并把 retry 作为新 step纳入总 budget，这避免无限隐藏成本。当前 main 的 Error2 让 code/retryability/action 成为跨 wire contract，但 metadata 不替 owning policy 做决定；对 partial stream/tool intent 必须依赖 provider protocol 和 context记录判断，不能仅看 HTTP code；建议同时度量 recovered rate 和 harmed rate，而不是只报重试后成功数。

11. 怎样设计 crash recovery，而不是 resume 文案？

• 定义：crash 后可恢复事实、可重建 mechanism、不可恢复 in-flight state 各是什么？
• 机制：wire replay、task reconcile、goal active→paused、compaction running→cancelled 如何工作？
• 取舍：为什么不持久化 AbortController、Promise、每个 token cursor？
• 故障：journal 写入与外部 effect 跨越 crash，产生哪些 ambiguous state？
• Eval：在哪些 cut points kill -9，恢复后验证哪些 invariants？
• 反驳：“有 append-only log 就等于 durable execution。”你如何反驳？

高质量答题骨架： 用事实/mechanism/effect 三分法；log 重建 domain state，mechanism 重建连接和 queue，external effect 必须 receipt/reconcile；公开 Kimi 已对 goal/task/compaction做 domain-specific normalization，但不能由此声称 exactly-once；测试应在 intent persisted、effect start、effect complete、receipt persisted 等 cut point 注入 crash，并检查既不重复破坏性 effect，也不伪装完成。

C. Wire、replay 与多投影一致性（12–16）

12. 为什么 Wire 同时拥有 journal 与 reducer model？

• 定义：Op、WireRecord、ModelDef、cross-reducer 各是什么？
• 机制：dispatch 如何 reduce、persist、publish event？nested dispatch 怎样 drain？
• 取舍：为何不让每个 domain 自己写文件和改内存？
• 故障：cross-reducer cycle、schema 演进、persist queue failure 怎样表现？
• Eval：如何验证 live state 与 replay state observationally equivalent？
• 反驳：“直接存最终 state.json 比 event log 简单。”什么时候 snapshot 更合适？

高质量答题骨架： Wire 把“事实语言 + 确定性投影 + 持久化顺序”收成一个 consistency boundary；domain 只声明 op/reducer，减少 dual-write；指出 event log 支持审计、迁移、fork，但体积、schema permanence、replay cost 更高；snapshot 对大而低审计价值状态合适，最佳通常是 journal + checkpoint，而不是信仰单一模式。

13. Wire corruption 与 migration 应该 fail-open 还是 fail-closed？

• 定义：torn tail、JSON corruption、unknown record、invalid payload、malformed metadata 有何不同？
• 机制：公开 restore 对五类情况分别如何处理？
• 取舍：跳过坏 record 提高可用性，却可能破坏什么事实？
• 故障：若被跳过的是 permission denial、goal terminal state 或 tool receipt，风险是否相同？
• Eval：如何做 mutation/fuzz testing 和 migration golden files？
• 反驳：“任何坏行都应该让整个 session 无法恢复。”怎样做 risk-based 回应？

高质量答题骨架： 先按 framing、envelope、type、payload、semantic criticality 分层；准确说公开实现 torn tail容忍、mid-log parse corruption抛错、未知/invalid op跳过并报告、metadata 严格；独立观点是 record criticality 应参与策略：display hint 可跳，authority/effect/goal transition 可能必须 fail-closed 或进入 quarantine；用恢复可用率与 silent semantic corruption 双指标评测。

14. Wire、EventBus、Transcript、Telemetry 为什么不能合并？

• 定义：四者的 audience、retention、privacy、schema stability 各是什么？
• 机制：同一 tool call 怎样出现在四个 surface 中？
• 取舍：多投影会带来多少一致性成本？
• 故障：UI 显示 success、wire 是 interrupted、telemetry 记 cancelled 时如何定位？
• Eval：怎样写 cross-surface reconciliation tests？
• 反驳：“多份数据就是重复和不一致，应只有一个 source of truth。”如何解释 source 与 projection？

高质量答题骨架： source of truth 可以唯一，但 projection 必然多样；wire 保存恢复事实，event驱动 live协作，transcript面向客户协议，telemetry面向无内容聚合；关键不是消灭投影，而是共享 stable IDs、声明 lossiness、可从 source 重建；用同一 session replay 比较 terminal facts 和 join completeness，不能要求四者字段完全相同。

15. 公开 Wire 能提供怎样的 durability guarantee？

• 定义：in-memory applied、queued for append、flushed、fsynced、atomically rewritten 分别是什么等级？
• 机制：无 blob record 与需要 dehydration 的 record 走什么持久化路径？
• 取舍：同步 fsync 每个 Op 与批量 append 的 latency/durability 如何权衡？
• 故障：进程崩溃、机器掉电、磁盘满、rewrite 与 append 竞争分别可能丢什么？
• Eval：如何用 fault injection 测 committed prefix 与 torn tail？
• 反驳：“文件 append 就是 durable。”为什么这个说法没有定义？

高质量答题骨架： 不超出源码：live reducer同步、append store可缓冲、flush显式等待、rewrite使用atomic write；是否每次 fsync与硬件级保证公开不足。把 durability 写成可测试 contract，例如 graceful close 后必须全保留，kill -9最多丢未flush tail且不损坏此前 prefix；对高风险 effect 应先持久 intent或独立 receipt，而不是依赖普通对话 op 的批量策略。

16. Agent fork 与 Session fork 应怎样保证因果清晰？

• 定义：fork 是复制当前认知、复制完整事实历史，还是创建新 lineage？
• 机制：公开 Agent fork 与 Session fork 各复制什么并写入什么 marker？
• 取舍：保留全历史利于审计，但会继承哪些 stale goal/permission/task？
• 故障：source 正在 compaction/tool effect时 fork，会得到什么边界？
• Eval：如何验证 fork 后 source/target independence 和 lineage trace？
• 反驳：“fork 就是复制目录。”为什么不够？

高质量答题骨架： 先定义 fork point 与 lineage ID；公开 Session fork flush/copy per-Agent wire、追加 forked、清 goal，并排除特定 runtime files；Agent fork复制 profile/context而非完整 Agent mechanism。独立观点是 fork必须对 in-flight effect给出政策：要求 quiescence、建立一致性 checkpoint或标记 ambiguous；评测要在 fork 后双向修改并证明状态、任务、permission与artifact不串。

D. Context、projection、compaction 与长期状态（17–22）

17. Context、State、Memory、Transcript 如何严格区分？

• 定义：四者各服务哪个时间尺度与消费者？
• 机制：公开 Kimi 的 ContextModel、AgentState、Goal/Task models、Transcript 各在哪里？
• 取舍：为什么不把所有东西都注入模型 context？
• 故障：transcript当事实源、summary当数据库、state全进prompt会分别怎样坏？
• Eval：如何测模型可见信息、恢复信息与用户可见信息的 coverage？
• 反驳：“模型有 1M context，不需要这些区分。”怎样回应？

高质量答题骨架： Context=本次推理输入，State=运行时可机读事实，Memory=跨时间选择性保留，Transcript=人类呈现；长窗口改变容量不改变 ownership、污染、成本和可验证性；公开 Kimi 已把 durable goal/task与 context分离。评测应独立测 acquisition、projection、transition、recovery，而不是只看总 pass rate。

18. ContextProjector 的 repair 是可靠性还是掩盖问题？

• 定义：protocol repair 与 semantic repair 有何边界？
• 机制：reorder、synthesize、drop orphan、dedupe、merge assistant 各为何需要？
• 取舍：严格 fail-fast 与尽量继续请求模型如何平衡？
• 故障：synthetic missing result 可能掩盖已成功的外部 effect吗？
• Eval：怎样衡量 repair precision、request validity 与 downstream harm？
• 反驳：“既然 projector 能修，upstream journal 不必保持合法。”为什么错？

高质量答题骨架： repair 目标是生成 provider-valid request，不是修复世界状态；公开设计对 repair打 warning/telemetry，避免静默；synthetic result 明确写“不可假设成功”，是 epistemic safety。仍要把 repair rate当上游质量回归信号，设置 anomaly budget，并用原始/修复轨迹对比 outcome，不能让 projector成为无限兼容层。

19. Full compaction 何时触发、何时阻塞？

• 定义：trigger threshold 与 blocking threshold 有何区别？
• 机制：pre-step、after-step、overflow error handler如何协作？
• 取舍：异步提前 compact 可隐藏 latency，却增加什么并发风险？
• 故障：同一 Turn 多次 overflow、provider 声明窗口错误、compaction 自身 overflow怎么办？
• Eval：怎样画 token utilization × latency × post-compaction success 曲线？
• 反驳：“接近上限再同步压缩最简单。”什么场景会明显伤害体验？

高质量答题骨架： 说明公开 RuntimeCompactionStrategy允许先启动、达到 shouldBlock才等待；overflow会校准有效窗口并重试failed driver；异步的正确性靠 slot、count、prefix safety和abort传播。评价不只看压缩率，要看阻塞时长、重复compaction、overflow recovery、cache disruption和继续任务成功率。

20. 怎样证明 compaction 没把任务压坏？

• 定义：coverage、faithfulness、preservation、utility 分别是什么？
• 机制：公开实现的 prefix safety、TODO append、post-compaction injection 能保证什么？
• 取舍：summary 越长越安全吗？
• 故障：负面证据、未完成约束、用户纠正、tool partial effect 最容易怎样丢？
• Eval：如何做随机触发点 replay、state probes 和 counterfactual continuation？
• 反驳：“最终任务通过就说明摘要正确。”为什么不足？

高质量答题骨架： 明确公开 safety只防并发覆盖，不证明语义完整；定义必须保留的 typed facts与不可压缩 artifacts；用同一前缀随机在不同点 compact/不compact，固定后续模型与 budget，比较约束回答、首个正确动作、最终 outcome和新增成本；最终成功可能来自模型重新探索，不能掩盖 summary corruption。

21. 1M context、dynamic tools 与 prompt cache 怎样共同影响架构？

• 定义：context capacity、effective attention、request bytes、cache prefix、tool schema budget分别是什么？
• 机制：公开 tool selection为何把 deferred tool schema移出顶层，并按需加载？
• 取舍：全量工具 disclosure 与动态发现谁更稳？
• 故障：模型不知道隐藏工具、tool announcement过期、cache被频繁动态prompt破坏怎么办？
• Eval：如何评测 tool discovery recall、cache hit、first-action latency、wrong-tool rate？
• 反驳：“窗口足够大就把所有 repo和tool schema一次塞入。”你怎么反驳？

高质量答题骨架： 大窗口不等于免费或均匀有效；tool schema与repo context争夺输入、影响cache和选择噪声；动态 disclosure降低固定prefix变化但引入发现失败。应做按任务/tool family的消融，同时报告 recall、tokens、latency、cache、resolved rate；不存在脱离模型能力和tool数量的统一最佳策略。

22. 长期 memory 应保存什么，不应保存什么？

• 定义：episodic history、durable task state、user preference、learned strategy如何区分？
• 机制：公开 Kimi 哪些状态通过 wire/doc/task files保存，哪些仅由 compaction摘要承载？
• 取舍：更多跨 session memory 为何会增加污染和权限风险？
• 故障：过时架构结论、错误 evaluator偏好、secret/tool output被长期保留会怎样？
• Eval：如何做 provenance、TTL、contradiction、forgetting 与 redaction 测试？
• 反驳：“用户总希望 Agent 记得越多越好。”如何挑战？

高质量答题骨架： 保存不可重新推导且未来高价值、可追溯、可撤销的事实；系统状态用 typed schema，认知摘要保持provenance，敏感内容最小化；公开 Kimi 的 session wire 是恢复记录，不等于跨 session学习记忆。独立判断是默认短记忆、显式晋升和可删除，比无限累积更可信；指标要联合 future-task utility 与 stale/harm/privacy rate。

E. Tool plane、并发与真实 effect（23–28）

23. 一个高质量 Tool contract 至少包含什么？

• 定义：intent、effect、receipt、artifact、progress、approval rule、idempotency 分别是什么？
• 机制：公开 resolveExecution → RunnableToolExecution → execute(ctx) 怎样提前暴露风险和资源访问？
• 取舍：静态 schema 能表达多少动态 effect？
• 故障：tool 返回 malformed result、空 output、mixed media、错误 display 会怎样？
• Eval：如何做 schema fuzz、effect spy、receipt completeness 与 model usability 测试？
• 反驳：“MCP tool schema 已经定义工具，不需要 host contract。”哪里不完整？

高质量答题骨架： schema只定义输入外形；可靠工具还需 effect classification、resource access、permission display、cancel、progress、result/error semantics和可验证 receipt。公开 Kimi 的两阶段 resolve使动态路径/审批/冲突在执行前可知；MCP解决发现与调用，不自动提供host policy、sandbox、idempotency或verifier。评价应观察实际effect与declared contract是否一致。

24. Tool preflight 为什么要把错误返回给模型，而不是抛异常？

• 定义：model-correctable error、runtime fatal error、security veto 如何区分？
• 机制：parse、missing、unavailable、schema invalid、path error各走什么路径？
• 取舍：把太多错误转成 tool result 会不会掩盖系统 bug？
• 故障：tool registry stale、schema compiler出错、模型持续用不存在工具怎么办？
• Eval：怎样测 self-recovery 与 silent infrastructure failure？
• 反驳：“任何 invalid args 都应终止 Turn，强迫模型更谨慎。”为什么可能降低可靠性？

高质量答题骨架： 如果模型能依据错误文本改变下一动作，返回 structured tool error有价值；若违反host invariant、registry corruption或安全边界，应明确 fatal/diagnostic。公开实现把常见调用错误模型可见，并通过log/telemetry保留机制证据；必须有repeat breaker和error taxonomy防止无限自修。指标看恢复成功率、额外步数和重复错误率。

25. 如何安全并行执行同一 step 的多个工具？

• 定义：并行条件是“工具不同”还是“effect不冲突”？
• 机制：ToolAccesses 如何处理 read/read、read/write、recursive path与unknown all？
• 取舍：保守串行损失 latency，错误并行损失 correctness；怎样选？
• 故障：symlink、case-folding、Git index、网络API、隐式全局状态会绕过 path conflict吗？
• Eval：如何用 deterministic barriers 验证 scheduler 与 declared access truthfulness？
• 反驳：“Promise.all 所有 tool calls，模型自己不会发冲突调用。”如何回应？

高质量答题骨架： 并行由effect footprint决定；公开scheduler用文件访问声明并维护active/queued冲突公平性，unknown默认all是正确保守值；但path-based模型不覆盖Git index、process env、network entity和symlink alias，需扩展resource namespace或给工具all。评测不仅比latency，还要做race detector、最终repo hash和多次重复稳定性。

26. 大工具输出应该怎样在 model、user、journal 与 artifact 间分配？

• 定义：完整结果、model preview、UI display、persistent artifact有何不同？
• 机制：公开 50k/2k text truncation 与 output path handoff怎样工作？
• 取舍：head preview、tail preview、结构化摘要、分页各适合什么输出？
• 故障：关键信息在尾部、保存失败、path无权限、artifact被后续覆盖怎么办？
• Eval：如何测 downstream answer fidelity、token savings与artifact retrieval rate？
• 反驳：“直接截断即可，模型看不到的也不重要。”为何危险？

高质量答题骨架： 完整证据必须可寻址，模型只需获得足以决定下一读取的preview和metadata；公开实现保存完整纯文本并提示Read分页，这是external cognition；同时指出固定head 2k对test summary/stack trace可能不足，应该按tool语义选择head-tail、error extraction或index。评测看模型是否能主动取回关键段，不只看token减少。

27. Dedupe 为什么分 same-step 与 cross-step？

• 定义：duplicate、repeat、retry、polling四者怎样区分？
• 机制：same-step duplicate如何共享original deferred result？cross-step streak如何升级？
• 取舍：为什么 3/5/8/12 的静态阈值只能是policy，不是普适真理？
• 故障：original result丢失、动态状态变化、canonical args碰撞会怎样？
• Eval：如何测阻止浪费与错误阻止合理重试两种代价？
• 反驳：“同样参数就直接返回缓存。”为什么对真实工具不安全？

高质量答题骨架： same-step通常是模型在同一response内的冗余，可确定性合并；cross-step可能是poll/retry/状态变化，先提供元认知提醒再stop。公开阈值是当前实现事实，不宣称最优；应按tool effect/read volatility和failure result调节，并用saved calls、resolved rate、false suppression和time-to-new-evidence联合评估。

28. Shell、Git 与 remote API 的 partial effect 如何恢复？

• 定义：intent persisted、effect started、effect committed、receipt observed四个阶段是什么？
• 机制：process id、exit code、stdout/stderr、Git status/diff、remote idempotency key怎样成为receipt？
• 取舍：pre-write intent log会增加延迟，post-write receipt会留下哪个crash gap？
• 故障：command创建一半文件后被kill、git push成功但响应丢失、API创建PR后timeout怎么办？
• Eval：如何在每个phase注入crash并验证reconciliation？
• 反驳：“失败后再运行一次通常就行。”如何用非幂等例子击破？

高质量答题骨架： 把外部effect视为分布式事务；local file可通过temp+atomic rename，Git/remote需query current state、stable operation key、compare intended artifact与observed state；不能把tool result文本当effect truth。公开 Kimi有process/task/Git观察基础，但通用exactly-once未被公开证明；答案应明确每种工具的reconcile策略而非统一retry。

F. Permission、trust 与安全边界（29–32）

29. Kimi 公开 permission policy 的 first-match 顺序为何重要？

• 定义：deny/ask/allow/mode/session memory/intrinsic tool risk各是什么优先级？
• 机制：auto、yolo、manual如何穿过具体policy chain？
• 取舍：为什么 yolo仍可能在sensitive/Git control path前被ask，而auto更早approve？
• 故障：用户allow规则覆盖敏感路径、规则匹配过宽、policy重排会怎样？
• Eval：如何生成完整truth table与policy mutation tests？
• 反驳：“permission mode是一个boolean allowAll就够了。”哪里不成立？

高质量答题骨架： permission是ordered decision graph，不是按钮；准确复述公开顺序并指出user deny最强、auto/yolo位置不同；不要替团队解释产品意图，标注为代码事实；提出每次policy变更必须跑tool×path×mode×rule×workspace trust truth table，并监控false allow、false ask、false deny和approval burden。

30. 如何降低 approval fatigue 而不削弱 consequential control？

• 定义：什么是可缓存 approval rule，什么是一次性 consequential effect？
• 机制：session approval history怎样记录 approvalRule？cold waitUntil为何减少无效弹窗？
• 取舍：按tool、path、command pattern、effect class缓存各有什么风险？
• 故障：攻击者利用宽规则、UI截断命令、用户机械点击会怎样？
• Eval：如何联合测prompts/task、decision time、rejection、incident与user correction？
• 反驳：“少弹窗就用auto mode。”为什么不是精细设计？

高质量答题骨架： approval应该绑定稳定且可理解的effect predicate，session scope限制时间与任务扩散；低风险read默认放行，高风险外部commit逐次确认；公开设计已有rule memory和typed display。降低fatigue不能只降prompt数，要看用户是否在关键节点保持理解和控制；高风险摘要必须展示具体target/effect且不可被模型文案替代。

31. Hooks、permission gate、workspace trust、sandbox 各是哪一层？

• 定义：advisory policy、risk adjudication、configuration trust、capability containment怎样区分？
• 机制：官方Hooks为何fail-open？untrusted workspace为何不应自动加载project MCP/agent overrides？
• 取舍：fail-closed hook会提高什么安全、破坏什么可用性？
• 故障：prompt injection绕过模型policy、hook crash、symlink escape、DNS rebinding分别该由哪层挡？
• Eval：如何做channel closure和benign utility联合测试？
• 反驳：“system prompt写不要执行危险命令就够了。”怎样回答？

高质量答题骨架： prompt/hook是软控制，permission是intent gate，workspace trust决定是否采信repo配置，sandbox/network/secret boundary限制真实capability；官方Hooks明确不应作为唯一安全边界。应为每类威胁指定deterministic owner，并同时测attack success与正常任务可用性，避免以全拒绝制造虚假安全。

32. Subagent 权限继承会产生什么 confused-deputy 风险？

• 定义：user authority、main Agent authority、delegated subagent authority有何区别？
• 机制：公开文档说明session allow rules传播，agent profile tool allowlist又在dispatch复核；两者如何组合？
• 取舍：继承减少重复approval，却扩大权限使用者集合；何时值得？
• 故障：main把不可信repo内容作为task派给高权限subagent，会怎样？
• Eval：如何测试delegation chain、least privilege、artifact provenance和unauthorized effect？
• 反驳：“subagent只是同一产品内的另一个模型，不需要独立身份。”为什么错？

高质量答题骨架： authority应绑定principal + scope + capability + expiry + delegation provenance；subagent独立context意味着它不自动拥有main的语义约束，权限继承必须与tool allowlist、task contract、workspace trust和effect gate组合。公开实现证明有隔离与复核，但完整delegated identity公开未知；建议高风险effect仍回到main/user确认，subagent产物作为untrusted artifact验收。

G. Observability、Evaluation 与模型协同（33–36）

33. 一条 Coding Agent trace 至少要有哪些 join keys？

• 定义：session/agent/turn/step/request/tool/task/effect各需要什么稳定ID？
• 机制：公开 Kimi 如何把Agent telemetry context、turn id、tool-call id、trace id带入事件？
• 取舍：高基数字段、隐私、成本和可诊断性如何平衡？
• 故障：provider不返回trace id、retry产生新request、subagent回传摘要后怎样保持因果链？
• Eval：如何测trace completeness、join success与redaction correctness？
• 反驳：“有日志文本，出问题grep就行。”为什么不够？

高质量答题骨架： trace必须能从user task追到model request、tool intent/effect/result、state transition和verifier；公开Kimi有稳定分层ID与typed events，且禁止内容/path进入telemetry。缺失provider trace时仍应有host request id；retry与subagent需要parent/causal links。指标看关键链路可join比例与首错定位时间，不看日志行数。

34. 怎样从 trace 找到第一次 causal error？

• 定义：symptom、proximate error、first causal error、root contract gap有何不同？
• 机制：如何联合 wire、request trace、transcript、telemetry和repo final state？
• 取舍：人工标注与自动classifier/LLM judge怎样分工？
• 故障：模型早期漏文件，后期测试失败；最终错误应归到哪里？
• Eval：怎样测annotator agreement、counterfactual validity与taxonomy coverage？
• 反驳：“最终失败在哪个tool就归因哪个tool。”为什么会错？

高质量答题骨架： 先定义首个偏离“仍可高概率成功轨迹”的决策；从最终oracle逆向，但在每个candidate点做counterfactual：只修这一点能否恢复；漏检索、错误假设、误工具、环境故障、verifier错误要分层。LLM可提候选，确定性facts和人工审计定案；报告agreement与unknown，而非强迫每条轨迹单标签。

35. Kimi 这类系统的 eval 应怎样分层？

• 定义：component、trajectory、outcome、online eval分别回答什么？
• 机制：scope/loop/wire/projector/compaction/tool/permission各自的最小可控eval是什么？
• 取舍：真实任务代表性与可重复性如何权衡？
• 故障：broken task、隐藏harness差异、budget不等、LLM judge偏差会怎样歪曲结论？
• Eval：Eval系统本身怎样被审计？
• 反驳：“只要端到端SWE benchmark分数提升，component regression不重要。”怎样回应？

高质量答题骨架： 端到端决定价值，component决定可解释改进；建立pinned repo/environment、deterministic oracles、trajectory capture和harness disclosure；每次改动先预测影响segment，再跑component与end-to-end。Eval也要有invalid-task率、oracle disagreement、contamination、cost parity审计。一个总分不能告诉你是模型、context还是tool修好了。

36. 哪些 Agent 失败应由模型团队修，哪些由 harness 修？

• 定义：capability failure、interface failure、state failure、environment failure、verification failure如何区分？
• 机制：相同模型换tool schema/context policy、相同harness换模型的2×2消融怎样做？
• 取舍：harness补偿弱模型可能在强模型上变成有害scaffolding，怎么办？
• 故障：模型重复tool、tool observation模糊、provider截断thinking分别归谁？
• Eval：如何设计跨model×harness×task segment实验并控制budget？
• 反驳：“模型再强一点，这些infra问题都会消失。”如何回应？

高质量答题骨架： 用可编辑面归因：改变模型权重/推理才可修的是能力问题；deterministic state/effect/protocol应由harness负责；两者交界用消融决定。稳定tool/environment/trace/verifier既是生产基础也是训练环境。随着模型变强，应删除只提供多余提示的scaffolding，但不会删除authority、durability、effect和evidence contract。

H. 产品判断、Kimi 取舍与独立立场（37–40）

37. 什么时候该用 subagent，什么时候不该？

• 定义：context isolation、parallelism、specialization分别创造什么价值？
• 机制：公开 Kimi 的独立context、final handoff、background execution和profile tool restrictions如何工作？
• 取舍：token、handoff、correlated error、integration burden怎样抵消并行收益？
• 故障：任务不可分、shared files冲突、父Agent无法验收、subagent上下文不足会怎样？
• Eval：怎样比较single vs subagent的verified outcome、wall time、compute和review burden？
• 反驳：“并行Agent越多越快。”如何给出条件化答案？

高质量答题骨架： 只有子任务独立、handoff可压缩、artifact可验证且wall-clock有价值时才分派；探索可用read-only Agent隔离噪声，强顺序修改留在一个Agent。公开 Kimi 支持独立 wire/context、profile 限制和 explicit model > profile preference > secondary default > inherit 路由；异构模型只是成本/能力假设，必须按 task segment 做消融。最终选择应以 verified outcome throughput 为因变量，并把总 token、冲突、父 Agent 验收和用户监督一起计入。

38. 多 provider abstraction 最容易在哪里失真？

• 定义：API shape compatibility 与 semantic compatibility有何区别？
• 机制：thinking、tool-call id、finish reason、media、context limit、streaming、trace如何做adapter？
• 取舍：统一最低公分母与暴露provider capability extension怎样平衡？
• 故障：provider返回tool_calls却无call、thinking preservation空消息、413含义不一怎么办？
• Eval：如何做protocol conformance、golden stream和model capability matrix？
• 反驳：“都支持OpenAI-compatible接口，换base URL即可。”怎样反驳？

高质量答题骨架： 协议字段相同不代表finish、stream、error、token和tool semantics一致；adapter要保留raw reason/trace并映射canonical domain error，未知不能吞掉。公开Kimi对多protocol建模且projector/compaction有provider fallback。测试需record/replay真实edge cases，按model capability路由，避免统一抽象丢失关键能力。

39. 如果只允许先改善 Kimi Code 一个系统面，你选什么？

• 定义：你如何定义“改善”与目标用户segment？
• 机制：你会从哪条公开trace/evidence链建立baseline？
• 取舍：为何不先做更炫的新tool、多Agent或更长context？
• 故障：你选择的指标会不会被拒绝、少做任务或成本膨胀gaming？
• Eval：component gate、offline task、online rollout分别怎样设计？
• 反驳：“你不了解内部优先级，无权建议。”如何保持谦逊又有判断？

高质量答题骨架： 不假装知道内部top issue；先要求按真实任务segment看first-error分布。如果必须基于公开信息下注，我优先建立“wire/request trace → 首错taxonomy →可复现eval”的闭环，因为它提升所有后续模型/loop/tool改进的决策质量。给出可证伪指标和停止条件；若内部数据表明主要瓶颈不同，立即换方向，这不是缺乏立场而是证据驱动。

40. 你对 Kimi Code 公开架构最重要的三个赞同与三个保留是什么？

• 定义：评价架构要基于哪些不变量，而不是个人风格？
• 机制：哪些公开实现直接支持你的判断？
• 取舍：每个保留意见的替代方案会新增什么复杂度？
• 故障：如果你的批评错了，什么证据最可能推翻你？
• Eval：怎样用最小实验而非大重构验证？
• 反驳：“面试时不应批评目标团队。”怎样表达独立判断而不表演？

高质量答题骨架： 赞同：scope ownership、wire/reducer恢复边界、context/tool/permission/evidence分治。保留：通用effect receipt仍不充分、compaction语义验证公开缺失、静态path conflict与permission chain仍需真实数据验证。每一点都注明事实/推断/未知，给出最小实验与反证条件；不把代码风格偏好包装成架构结论，也不把公开缺失当内部不存在。

13. 候选人应持有的独立判断

下面这些不是“猜 Kimi 标准答案”，而是面对任何 Coding Agent 系统都应能 defend 的立场。

13.1 模型能力与 harness 能力必须联合测量，但责任不能混

模型决定不确定策略能力；harness 定义状态、工具、effect、权限、证据和恢复边界。模型增强可能让部分 prompt scaffolding 过时，却不会让 journal、sandbox、identity、receipt 和 verifier 过时。

13.2 Agent loop 应薄，state/effect contract 应厚

巨型 while-loop 短期直观，长期会把 retry、compaction、goal、task、permission 和 provider edge case缠成不可测试控制流。Loop应拥有 admission、ordering、budget、cancel和error dispatch；领域policy由有明确owner、顺序和trace的深模块接入。

13.3 长任务可靠性的单位是 checkpointed verified progress

maxSteps、context window、Agent数量都不是核心进度单位。每一阶段应留下可恢复state、可检查artifact和completion evidence；否则更长运行只是在扩大偏航与事故半径。

13.4 Compaction 是高风险 memory transition

摘要不是压缩比竞赛。它必须保存目标、约束、决定、负面证据、partial effects、未完成工作和verification state。Prefix safety只解决并发覆盖，必须另测coverage、faithfulness与post-compaction utility。

13.5 工具错误的核心是 effect ambiguity，而不只是 error text

“失败”可能发生在 effect 前、effect中、effect后receipt前。只有第一类通常可安全重试；后两类需要query/reconcile/idempotency key。Agent给出的流畅解释不能替代外部状态证据。

13.6 Permission prompt 不是 sandbox

用户确认是intent治理；OS/filesystem/network/secret containment才是capability边界。Hooks是可扩展policy，且官方明确fail-open；高风险系统不能把软提示当强制控制。

13.7 Repair 可以存在，但必须可观测、可预算、可删除

Projector repair、provider fallback、schema coercion提升可用性，但每次repair都可能掩盖上游contract violation。应记录type/rate/outcome，设regression budget，修复根因后能移除。

13.8 Multi-agent 是条件化调度选择

适合并行、隔离、可验收的子任务；不适合高共享状态、强顺序依赖和父Agent无法验证的任务。优化的是verified outcome throughput，不是Agent数、tool calls或生成artifact数。

13.9 Evaluation 是产品控制面，不是发布后的打分表

Trace必须能转成可复现failure case；每次改动要能预测受益segment、做单component消融、运行regression gate、再受控上线。Benchmark若不披露model/harness/environment/budget，不足以支持因果结论。

13.10 公开源码研究必须保留 epistemic boundary

应敢于具体说出公开机制，也要敢于说“这点公开未知”。把公开 repo 当全部内部系统是幼稚；把更高透明度当成更高产品排名同样错误；完全不研究公开 repo、只讲通用 Agent 概念也不合格。Kimi 适合作为 glass-box mechanics 样本，再用 Codex、Claude Code、pi 的公开产品 contract 压测其 control plane、协作治理与 core economy；没有同条件 hands-on 时，不把 [F-doc] 冒充 [X-product]。

13.11 最终完成必须由世界状态定义

对 coding task，完成通常意味着目标diff存在、用户改动未被破坏、指定测试/构建通过、没有未解释失败、必要artifact可交付。finish_reason=end_turn、模型说“done”、tool无报错都不是充分条件。

13.12 观测系统要服务因果定位，而非收集一切

稳定ID、phase、decision branch、effect、receipt、usage、latency和error class有价值；用户prompt、源代码和文件路径默认不应进入聚合telemetry。完整内容留在受控本地/审计surface，聚合面保持最小化。

14. 面试时的证据表达协议

一个成熟回答可以固定为五段，而不是堆术语：

1. 定义对象与不变量：先说明你讨论的是 Turn、Step、effect、journal 还是 transcript。
2. 给出公开机制事实：指出 Kimi 公开 v2 的具体服务/控制流。
3. 说清 tradeoff：它解决什么，同时引入什么成本。
4. 提出 failure 与 eval：怎样被证伪，测什么 outcome，不只测内部指标。
5. 标注边界：哪些是公开事实、哪些是源码推断、哪些要看内部 trace 才能决定。

示例：

我把 compaction 看成 memory transition，而不是 token optimization。公开 v2 会在应用摘要前验证原历史仍是当前 history 的 prefix，并允许只追加真实用户输入，这解决并发覆盖；它还保留 TODO、刷新 system prompt、重新注入必要状态。但这些机制不证明摘要语义完整。我要用随机触发点 replay，比对约束覆盖、首个正确动作、最终 verified outcome 和成本。Kimi 内部是否已有这套 eval，公开信息不足，我不会假装知道。

15. 2026-08-03 main freshness / reliability 复核

初稿曾固定在 2026-08-01 的 e22479a。为保持数十条源码 permalink 属于同一个可复现快照，正文架构事实固定在 29c9e2a（2026-08-03 15:42:09，UTC+8）；freshness ledger 则继续验证到 75395f6（2026-08-03 17:14:34，UTC+8）的当前 main。从旧快照到当前 main 共 5 个提交：3e42521、e6a655e、29c9e2a、只影响 TUI 登录提示的 dfc55a5，以及扩展 lifecycle hook contract 的 75395f6。本文引用的 Loop、Wire、Projector、Compaction、Tool、Permission、Telemetry 等主体路径仍存在；架构增量在对应章节或本节显式记账。

15.1 [F] 全领域 coded error：错误语义成为稳定协议对象

3e42521 将 agent、session、app、workspace、OS、persistence、wire、provider 与 MCP 等领域的失败统一迁移到 Error2：

• 每个 failure mode 有稳定的 domain code、retryability、structured details 和 cause；
• wire-facing KimiErrorCode union 与 kap-server Zod schema 同步，避免 TypeScript 接受而 RPC runtime 拒绝；
• provider、filesystem、storage 等 foreign error 在领域边界翻译，跨 wire 按 code 而非 instanceof 或 message 分支；
• permission_denied、disk_full、task.limit_exceeded 等被区分为不同控制语义，并修复了依赖旧 message string 的 task-limit remap。

这直接验证一个关键判断：错误分类不是日志美化，而是 retry、user action、wire compatibility、telemetry aggregation 与恢复策略的共同控制面。 但 _base guards、部分 control-flow sentinels、CyclicDependencyError 与 PathSecurityError 仍是官方列出的例外，不能说“所有 throw 都已统一”。

15.2 [F] Lifecycle Ledger：销毁顺序和回滚变成显式资源模型

e6a655e 新增 lifecycle ledger：

• ordered registration 与严格 reverse-serial teardown；
• sync / async 双轨 disposer、uninterruptible rollback、teardown reason 传播；
• child ledger 与 introspection tree；
• Disposable、DisposableStore、MutableDisposable、scope 与 instantiation disposal 逐步委托给 ledger。

[I] 这说明团队正在把“对象各自实现 dispose()”提升为统一的生命周期协议：资源获取顺序、依赖销毁顺序、半构造回滚和诊断树由同一个深模块拥有，而不是散落在服务里。边界是： ledger 自身会串行 await async disposer，但当前 Scope.dispose() / InstantiationService.dispose() 是同步 void facade，不保证调用方等待异步 teardown 完结。

15.3 [F] Dynamic Registry 与 Cascade Engine：DI 从构造工具升级为运行时控制面

同一提交引入 persistent dependency graph 和跨 scope cascade engine。动态 provide / unprovide / update 会：

1. 沿真实 instance dependency edge 计算 contagion set；
2. 若配置了 onWillCascade，给 owning runtime 一个默认 5 秒的有界 abort hook；
3. 按全局逆拓扑、深 scope 优先拆卸受影响 service；
4. 应用配置变化；
5. 按拓扑顺序重建依赖已经满足的 service；
6. 将 transaction 写入有界 history ring。

其 unit state 至少区分 Pending / Activating / Active / Unloading / Failed；tree-wide queue 串行化跨 scope transaction，shadowed token 不进入父级 change 的 contagion set。

[I] 这不是普通 hot reload。它提供了解决 provider、plugin、model、MCP 或 workspace configuration 动态变化后 stale dependency 的通用机制。但当前 InstantiationService 构造 engine 时没有注入 onWillCascade，也没有证据证明这些业务域都已用 dynamic registry 热换。 因而面试追问应是：哪些 token 实际采用；active Turn 如何取消；拆卸与重建是否具有足够原子性；部分 rebuild 失败如何恢复；哪些 service 必须 pinned。

15.4 [F] Secondary Model 路由语义被明确

29c9e2a 明确：secondary model 是新 subagent 的默认绑定，不是强制绑定；解析优先级为：

explicit tool-call model
  > agent profile model_preference
  > configured secondary model default
  > inherit caller model when no secondary model exists

其中 primary 指主 Agent 当前实际运行的模型，不必等于配置文件里的 default_model。这把 heterogeneous multi-agent routing 的 authority 讲清了：用户设置默认值，profile 表达角色偏好，主 Agent 仍可按具体子任务显式选择，但可选值被约束为 symbolic primary / secondary。

15.5 [F] Lifecycle hook contract 扩充：从“关键动作拦截”走向“会话运行状态订阅”

75395f6 新增并测试了四类外部 hook 事件：

• TurnStarted：订阅现有 turn.started bus event，因此覆盖直接用户 prompt 之外的 queued turn、Stop-hook continuation 与 background/system turn；payload 包含 turn id、origin kind/name 与 prompt；
• UserPromptQueued：仅当 user-origin prompt 不能立即 launch 时发布，携带 prompt id、content 与当前 queue length，使“用户输入已接收但仍在等待”成为显式状态；
• TaskStarted：从现有 task.started bus event 发出，补齐过去主要在完成时通过 Notification 暴露的 background-task lifecycle 起点；
• SessionHeartbeat：每 Session 60 秒一次；只有 hook index 中实际注册该事件时才 arm timer，plugin reload 后会重新检查并 arm/disarm，避免没有 consumer 的 session 常驻无意义 timer。

Payload contract 也被补齐：所有事件增加 clientType；session/agent-scoped event 增加缓存的 sessionTitle；SessionStart 增加 default model 与 profile；SessionEnd 能区分 exit 与 archive；SubagentStart/Stop 带上 session id 与 cwd。klient contract 已接受四个 v2-only 事件；Node SDK 对 v1 PluginInfo 则显式投影掉 v1 不认识的 hook event，避免用 widen union 破坏旧类型承诺。

这次变化的架构意义是：hook surface 不再只回答“动作能否执行”，开始回答“Session 现在是否活着、Turn/Prompt/Task 处于什么 admission 状态”。 它显著扩充了用户自定义 observability contract，并使外部 supervisor 能区分长 permission wait、队列积压、background task 启动与进程失联。

但边界必须说清：

• heartbeat 是 60 秒 timer 发出的 liveness hint，不是 durable journal、progress proof 或分布式 lease；event loop 卡死时它同样不会发出；
• TurnStarted/TaskStarted/heartbeat 走 fire-and-forget path，不能据此宣称 external hook consumer 获得 exactly-once delivery；
• sessionTitle 由异步读取和 metadata change listener 缓存，payload schema允许其缺失；
• prompt、task description、cwd 等 hook payload 可能含敏感内容，外部 command 的传输、保留和脱敏属于部署侧责任；
• 这扩充的是 extensibility/observability surface，不自动等于 telemetry、eval 或产品 UI 已消费这些状态。

主证据：hook event union @ 75395f6、Agent-scope hook adapter、Session-scope hook adapter、App-scope runner、integration tests。

15.6 审校结论与四组面试追问

• 未漂移：四级 scope；Workspace/Session/Agent lifecycle；Turn/Step/StepRequest admission；Wire replay；context projector/full compaction；tool scheduler/dedupe/truncation；permission chain；typed telemetry 的主体机制仍成立。
• 已吸收：全领域 coded error、lifecycle ledger、dynamic registry/cascade、secondary-model precedence、conversation undo checkpoint protocol、K3 harness-diverse RL 与 harness-aware eval，以及 TurnStarted / UserPromptQueued / TaskStarted / SessionHeartbeat lifecycle hook contract。
• 已收紧：dynamic cascade 的 abort 只是可选 hook；同步 lifecycle facade 不等于 await async teardown；wire.restore() 不返回 lossy summary；K3 training sandbox 不等于 Kimi Code CLI sandbox；secondary 是默认路由而非强制路由。

1. Dynamic cascade：跨 App/Workspace/Session/Agent scope 更新依赖时，什么工作必须在 bounded abort 后强制结束？部分 rebuild 失败后，事实源和恢复点在哪里？
2. Error semantics：error code、retryability 与 user action 如何版本化，怎样避免旧 client 遇到新 code 时把 non-retryable 错误当 transient retry？
3. Model routing：secondary model 默认路由怎样用 task difficulty、tool density、verification cost 与 failure trace 校准，而不是只追求 token 成本下降？
4. Lifecycle observability：heartbeat、queued prompt 与 task start 怎样关联到 durable session/turn/task identity；hook delivery 丢失、consumer 慢或 plugin reload 时，supervisor 如何区分“没有事件”和“没有进展”？

这些更新进一步强化了岗位判断：Kimi Code 正在处理的不是“再加一个 Agent 功能”，而是让动态、长程、有副作用的 Agent runtime 在配置变化和失败中仍保持资源、依赖、错误、模型选择与运行状态的一致语义。

16. Kimi 是 glass box，不是自动的 frontier 上界

本章前 15 节回答的是“公开 Kimi Code 怎样工作”，不能偷换成“Kimi Code 因而代表行业最强形态”。更严谨的结论是：

Kimi Code 是目前极有价值的可验证机制样本。Codex、Claude Code 与 pi 则分别在跨表面控制面、协作编排与治理、极简可扩展 substrate 上提供更强的 product-frontier 对照。这里的“更强”只指所列维度，不是未经同条件实测的总榜。

16.1 先定义 product frontier，避免拿代码行数做排名

对 Coding Agent，至少要沿六个相互独立的维度比较：

1. Execution surfaces 与 continuity：同一任务能否在 CLI、IDE、桌面、云端、移动端、远程机器之间延续，而不是每个客户端各有一套孤立状态；
2. Human supervision bandwidth：人能否同时看多个任务的状态、diff、terminal、测试、审批与阻塞原因，并以低切换成本接管；
3. Parallel isolation 与 coordination：并行单元怎样分解、通信、共享或隔离 context、workspace、Git state、权限和预算；
4. Extensibility 与 governance：tool、skill、MCP、hook、plugin、policy、managed config 与审计是否形成统一且可治理的扩展语法；
5. World interaction 与 verification：Agent 能否操作浏览器、桌面、远程环境和外部系统，并把世界状态证据带回完成判定；
6. Conceptual economy：核心是否足够小、接口是否足够深，新增能力是否必须修改 runtime，还是可以由稳定扩展面组合出来。

这六项没有一个可由“公开类更多”“源码更完整”或“模型 benchmark 更高”单独代理。模型质量还必须在同 harness、同环境、同权限、同预算、同 verifier 下单独控制。

16.2 四个系统的证据地图：先比较我们究竟看得见什么

这张表纠正三个常见误判：

• 证据密度不等于能力上界。 Kimi 和 pi 更透明，只说明我们更容易精确批评它们；Claude Code runtime 不公开，也不能因此推导其内部一定简单或一定先进；
• 官方产品表面不等于架构事实。 Claude 的 agent view 或 Codex 的 remote control 可以作为产品 contract 研究，但不能据此虚构 daemon、queue、journal 或一致性协议；
• 公开客户端不等于公开全栈。 Codex 即便公开本地 Rust runtime，模型服务、云编排和托管策略仍是另一条不可见边界。

16.3 Codex：frontier 在“跨表面控制面 + 高带宽监督”

16.3.1 可验证事实

• [F-code] Codex app-server 把交互抽象为 Thread → Turn → Item，通过双向 JSON-RPC 暴露 thread/start|resume|fork|read|list、turn/start|steer|interrupt、item streaming、approval、skills、MCP、auth、config 与 typed schema generation。它不是只给 CLI 用的内部 helper；官方 README 明确它为 VS Code 等 rich clients 提供接口。
• [F-code] App Server protocol 和 thread_manager 公开实现 child-thread lineage 与从持久化历史 fork 的 subagent spawn；本地仓库同时公开 rollout/thread store、hooks、sandboxing、Linux/Windows sandbox 等机制。能据此讨论本地 client/runtime 的控制路径，不能把它扩展为全部 OpenAI 云后端。
• [F-doc] Codex App 被定义为 agent command center：并行运行多个 agent、按 project/thread 管理、用 Git worktree 隔离、审 diff/评论并转入编辑器；官方还记录 skills、Automations 与 system-level sandbox/permission surface。
• [F-doc] 官方 remote-control 产品面允许从移动端连接本机、devbox 或远程环境，查看 threads、terminal output、diff、tests 与 approvals；官方称 relay 传递控制信息，而本地文件、credential 与 permission 保留在机器侧。
• [F-doc] 官方 2026 年产品说明还覆盖 agent computer use、独立 cursor、in-app browser/page annotation、image generation、并行代理与 SSH remote devbox。

16.3.2 为什么这是比“一个强 CLI loop”更高一层的产品问题

Codex 的关键 lesson 不是“它也有 subagent”，而是把 execution plane 与 supervision/control plane 分开：runtime 执行 thread/turn/item，App/IDE/mobile 等客户端消费稳定事件、发审批、比较 diff、切换 agent、接管任务。这样新增 surface 不必复制一套 Agent 核心，也让“人一次监督多少自治工作”成为一等产品指标。

对 Kimi 的压力测试不是照抄 UI，而是追问：

1. kap-server / client contracts 是否已成为和 app-server 同等稳定、可版本化、可生成 schema 的 control-plane boundary；
2. CLI/Web/VS Code/ACP/SDK 是否共享同一 durable identity、approval、resume、fork 和 event ordering 语义；
3. 多 Agent 的默认隔离是否到 Git worktree/remote environment，而不只是 context 和 wire；
4. 用户能否在一个监督面上看到“正在做什么、改了什么、验证到哪、为何阻塞、需要什么权限”，而不必逐个打开 transcript；
5. browser/computer/remote-machine effect 是否进入同一 receipt、policy 与 verifier 体系。

16.3.3 不能从公开材料推出什么

不能说 Codex 的云调度一定采用公开 thread_manager，不能从 App Server 的 schema 推断模型内部 tool policy，也不能把官方产品演示当成稳定成功率。真正比较 outcome 仍需 pin model、repo、environment、worktree policy、budget 和 verifier，记录人工接管与 approval burden。

16.4 Claude Code：frontier 在“协作语法 + lifecycle policy + 企业治理”

16.4.1 可验证产品表面

• [F-doc] 官方把并行/委派拆成不同 primitive：subagent 提供 isolated context；agent view 管理可后台运行并随时 attach 的独立 session；agent teams 使用共享 task list 与 peer-to-peer messaging；worktree 提供文件/Git 隔离；/batch 将计划拆成 5–30 个 worktree-isolated subagent 并让各自形成 PR。
• [F-doc｜重要边界] 官方比较页明确：agent teams 本身不自动把 teammate 隔离进 worktree。因此“有多 Agent”与“并发写隔离”是两项不同 capability，不能合并宣传。
• [F-doc] subagent contract 能限定 tools/disallowedTools、model、permission mode、skills 与 inline MCP server，使子 context 的能力面可以比 parent 更窄或更专门。
• [F-doc] hooks 覆盖 Pre/Post Tool、PermissionRequest、SubagentStart/Stop、PreCompact、TaskCompleted、TeammateIdle、ConfigChange、WorktreeCreate/Remove 等生命周期点；agent-based hook 还能启动一个受限调查 agent，再返回结构化 allow/block 决策。
• [F-doc] 管理面区分 permission 与 sandbox：前者治理意图和审批，后者使用 OS filesystem/network isolation；企业配置还能约束 MCP/plugin/hook、domain allowlist、minimum version 与 OpenTelemetry。
• [F-code/F-doc 边界] Anthropic 官方 GitHub 仓库的 README、CHANGELOG、plugins 与示例能证明发布 contract 和产品变化，但仓库不含核心 Agent loop、session store、sandbox orchestrator 或 binary runtime 源码。对这些内部机制只能标 [U-backend] 或明确标 [I-arch]，不能把 CHANGELOG 当实现代码。

16.4.2 Claude Code 真正值得学的不是 feature count

Claude Code 把协作选择显式命名为一组不同语义的 primitive。它迫使产品回答：这是短期隔离 context 的 subagent，长期可接管的 background session，有 peer messaging 的 team，还是 filesystem 隔离的 worktree batch？这比统一叫“multi-agent”更成熟，因为用户能预期成本、共享状态、接管方式和 failure radius。

第二个 lesson 是 policy 与 lifecycle 共用扩展语法。Hook 不只在 tool 前后跑 shell，而是能挂到 compaction、subagent、teammate、task、worktree、permission、config change 等控制点；再叠加 rules/skills/MCP/plugins/managed settings，扩展与治理成为产品对象，而非散落 callback。

对 Kimi 的压力测试是：

1. Agent、AgentSwarm、background task、Goal、Session fork、Agent fork 的用户语义是否足够清楚，还是底层对象多、产品选择仍只有“开更多 Agent”；
2. hook/event surface 是否覆盖 lifecycle 关键点，并为 block/transform/inject/audit 指定强弱边界、timeout 与 fail-open/closed；
3. agent profile、tool allowlist、permission policy、workspace trust、MCP 和未来 sandbox policy 能否组合成可审计的 capability profile；
4. 企业 managed policy 是否能锁定 extension source、network、secret、minimum version、telemetry 与审批规则，同时不把所有开发效率牺牲掉；
5. orchestration primitive 是否有明确的“何时不用”，尤其是共享工作区写冲突和 team 无隔离问题。

[F-code｜freshness correction] Kimi 当前 main 的 75395f6 已把 TurnStarted / UserPromptQueued / TaskStarted / SessionHeartbeat 加入外部 hook contract，并统一补充 client/session/model/profile facts。因此对照结论不能写成“Kimi hooks 只覆盖 tool 前后”；更准确的差距是：Kimi 已开始把运行状态和 admission 暴露给 supervisor，但 Claude 官方 contract 仍展示了更宽的 teammate、worktree、config 与 managed-governance 生命周期词汇。两者还不能只按 event 数量排名，必须比较 delivery guarantee、block semantics、敏感数据边界与真实 consumer。

16.4.3 不能从官方文档推出什么

不能声称 Claude Code 内部一定使用 actor、daemon、WAL、event sourcing 或某种 queue；也不能因为 CHANGELOG 暴露并发上限和修复记录，就推断当前所有路径无 race。这里最强的答法是：产品 contract 可比较，核心机制不可审计；若要做架构判断，必须把它标为待验证假设。

16.5 pi：frontier 在“极小 substrate + 用户拥有的扩展权”

16.5.1 可验证事实

• [F-code] pi 将系统拆成 pi-ai provider abstraction、pi-agent-core stateful loop、pi-coding-agent 产品层与 pi-tui。Agent core 明确事件序列、context transform/LLM conversion、steering/follow-up queue、before/after tool hooks，并默认支持同批 tool call 并发执行后按源顺序持久化结果。
• [F-code] session 使用带 id/parentId 的 JSONL tree；/tree 可在同一文件中切换历史分支，/fork//clone 创建新 session，compaction 明确声明有损但保留完整原历史。
• [F-code/F-doc] 产品同时支持 interactive、print/JSON、RPC 与 SDK；TypeScript extension 能注册 tool、command、keybinding、event handler、provider 与 UI，package 可把 extension、skill、prompt 和 theme 一起分发。
• [F-doc｜刻意取舍] pi 明确不内置 MCP、subagents、plan mode、permission popups、to-do 和 background bash；推荐通过 extension/package、tmux 或 OS container/sandbox 组合。它也明确说明 project trust 只是输入加载 guard，不是 sandbox；默认以启动用户权限运行。
• [F-code] provider 层统一多家 tool-capable model、OAuth/API key、streaming、thinking、usage/cost 与 cross-provider handoff，同时保留 provider-specific wire implementation 和 custom provider extension。

16.5.2 为什么“少做”本身可以是 frontier

pi 提供的对照不是 out-of-box 功能更全，而是 机制经济性更强：核心只保证 model/provider、agent event loop、tool execution、session tree、TUI/RPC/SDK 和 extension contract；存在多种合理实现的产品 policy 则不抢占唯一答案。

这迫使 Kimi 面对一个更难的问题：公开 v2 中每个新增 service 是否都属于所有用户不可缺的 invariant，还是应该成为可替换 policy？例如 dedupe、goal continuation、compaction、agent routing、approval UI、MCP 与 lifecycle hooks，哪些必须由 core 拥有一致性，哪些只需暴露深接口让产品层组合？

pi 也给出反面提醒：极简不是免责。没有 built-in sandbox/permission、多 Agent 和 MCP，意味着默认安全与协作上界交给用户集成；extension 以同进程权限运行，第三方 package 的 supply-chain 与行为必须由使用者承担。因此它在 conceptual economy 上是 frontier reference，在默认 governance 和并行 supervision 上并不自动领先 Codex/Claude。

16.6 四者放在一起，真正应吸收的 architecture lessons

综合起来，Kimi Code 的合理定位不是“公开实现最完整，所以代表未来”，而是：

• 用 Kimi 精确学习 runtime mechanics；
• 用 Codex 检验 control plane、continuity、supervision 与 world interaction；
• 用 Claude Code 检验 orchestration vocabulary、lifecycle extensibility 与 governance；
• 用 pi 检验 core 是否过厚、接口是否足够深、用户是否真正拥有系统。

16.7 这套比较怎样被证伪

若要从“官方材料对照”升级为产品强弱结论，至少运行同一组 longitudinal tasks：

1. 固定 repo snapshot、目标 issue、依赖和外部服务；
2. 分别记录 model、reasoning effort、context policy、tool set、permission/sandbox、worktree 与并发预算；
3. 测 verified outcome、首次错误决定、人工接管时间、approval burden、wall-clock、cost、失败恢复和未解释 side effect；
4. 对 parallel task 测 merge conflict、重复工作、parent verification load 与 orphaned worktree/process；
5. 对跨 surface task 测 identity、state、approval 与 artifact 是否真正连续；
6. 同一失败做 component-level replay，避免把模型差异错归因于 harness。

在完成这类 [X-product] + eval 之前，只能说“某系统在官方公开 contract 上代表某个 frontier 方向”，不能说“综合上必然更强”。

16.8 面试中的 90 秒防守答案

我不会把 Kimi Code 的公开源码当成行业上界。它首先是一个高证据密度的 glass box：我能从固定 commit 重建 scope ownership、Turn/Step admission、wire replay、context projection、tool scheduling、permission 和 telemetry，这使机制讨论非常具体。但产品 frontier 需要另外看。Codex 的强参照是跨 CLI、IDE、App、cloud/mobile 与远程机器的 control plane，以及 worktree、多 Agent 和人类监督带宽；Claude Code 的强参照是 subagent、agent view、agent teams、worktree、batch 之间清楚的协作语法，以及 hooks、plugins、MCP、sandbox、managed policy 的治理面；pi 的强参照是极小且可嵌入的 loop/session/provider substrate，把有争议的 policy 交给 TypeScript extension。我的方法是用 Kimi 重建 mechanics，再用这三类 frontier 压测它的产品边界。哪些判断来自代码、哪些只是官方产品 contract、哪些是架构推断、哪些后端不可见，我会逐项标明；没有同条件实测时，我不会做综合排名。

最危险的回答是：“Kimi 源码最详细，所以它最先进。”最强的回答是：“透明度让我能更准确地验证和批评；frontier 仍要由产品 contract、真实体验和 outcome eval 共同决定。”

17. 一手来源索引

17.1 招聘与模型

• Moonshot AI「Coding Agent 研发工程师 / Agent Infra / MJ000797」招聘 JD：用户提供的官方招聘海报截图；
• Kimi K3 官方仓库 README @ 7c5be95；
• Kimi K3 官方技术报告 @ 7c5be95。

17.2 Kimi Code 官方仓库，当前固定快照

• MoonshotAI/kimi-code @ 29c9e2a；
• Repository AGENTS.md；
• agent-core-v2 design constraints；
• Scope tree；
• Lifecycle ledger；
• Dynamic cascade engine；
• Persistent dependency graph；
• Domain error specification；
• Workspace lifecycle；
• Session lifecycle；
• Agent lifecycle；
• Turn/Step loop；
• Wire journal/reducer；
• Context memory；
• Conversation checkpoint protocol；
• Context projector；
• Full compaction；
• Tool contract；
• Tool executor；
• Tool dedupe；
• Provider step retry；
• Permission policy chain；
• Permission gate；
• Goal lifecycle；
• Task lifecycle；
• Typed telemetry events。

17.3 Kimi Code 官方文档

• Kimi Code overview；
• Sessions and context；
• Goal mode；
• Agents and Sub-Agents；
• Hooks；
• Built-in Tools；
• Providers and models；
• Data locations；
• Changelog。

17.4 OpenAI Codex 一手来源

• openai/codex @ bb5054f（2026-08-03 当前审校快照，Apache-2.0）；
• Codex repository README；
• Codex App Server protocol and lifecycle；
• Typed App Server request protocol；
• Thread manager and persisted-history subagent spawn；
• Codex subagents official docs；
• Codex App Server official docs；
• Introducing the Codex app；
• Work with Codex from anywhere；
• Codex for almost everything。

17.5 Anthropic Claude Code 一手来源

• anthropics/claude-code @ 7ef6eec（2026-07-25 当前公开仓库快照）；
• Official repository README；
• Official product CHANGELOG；
• Choose between subagents, agent view, agent teams, worktrees, and batch；
• Agent view；
• Subagents；
• Hooks 与 Agent SDK hook lifecycle；
• Sandboxing 与 enterprise/admin setup；
• Claude Code features overview。

17.6 pi 一手来源

• badlogic/pi-mono @ c6eb628（2026-08-03 当前审校快照，MIT）；
• Pi Agent Harness repository README；
• pi-coding-agent README：modes、sessions、extensions 与 philosophy；
• pi-agent-core loop and event contract；
• pi-ai provider abstraction；
• pi security boundary；
• pi.dev official documentation。

17.7 从旧审稿快照到当前 main 的 5 个提交

• All domain failure modes as Error2 (3e42521)；
• Lifecycle ledger、dynamic registry 与 cascade engine (e6a655e)；
• Secondary model binding precedence (29c9e2a)；
• Visible already-logged-in TUI notice (dfc55a5)；
• Lifecycle hook events and enriched payloads (75395f6)。

18. 最后一条防守原则

面试官问 Kimi 时，不要退化成“我读过源码”，也不要假装内部人。最强的状态是：

我能从公开代码精确重建控制路径，能指出每个设计解决的系统问题和新增代价；我能把失败转成可复现 eval；我也清楚公开证据的边界，不会用自信替代未知。

再加一句才完整：我把 Kimi 当作可审计的 mechanics 样本，不把透明度当作 frontier 结论；我会用 Codex、Claude Code 与 pi 的不同强项做对照，再由同条件产品体验和 verified outcome 决定高下。