Kimi Code Coding Agent 研发工程师面试作战手册

研究基线：2026-08-03。内容以岗位截图、Kimi 官方文档、MoonshotAI 公开代码仓库、近期一手工程/研究资料为依据。公共代码会继续快速演进；面试前应再次拉取仓库并检查最近一周变更。

1. 岗位本质：他们实际在招什么

JD 的核心句不是“构建 Coding Agent”，而是：

建设模型之外的关键系统，让模型在真实代码仓库、真实工具链和真实开发流程中完成任务。

这对应一个非常明确的岗位画像：Agent Runtime / Harness Engineer + Developer Tool Engineer + Evaluation Engineer。模型能力是输入，候选人要拥有的是把它变成可靠产品能力的系统边界。

1.1 六个真实考察维度

1.2 一句话候选人定位

你需要让面试官在前 15 分钟形成这个判断：

这是一个能从真实工程失败出发，跨 Agent loop、上下文、工具、运行环境、评测和产品体验找到控制边界，并用可靠工程把改进闭环的人。

1.3 面试中最危险的错误定位

• 把 Agent 说成“prompt + tools + while loop”。这只能解释 demo，解释不了 Kimi Code。
• 把“上下文越长”当成“效果越好”。K3 有 1M 窗口，但 attention、成本、缓存与 context rot 仍然存在。
• 遇到失败只说“加 retry / 换更强模型 / 多加一个 agent”。这是 JD 明确排斥的补丁思维。
• 只谈最终 pass rate，不谈任务有效性、harness、预算、重复运行、污染、拒答和 trace。
• 只会比较模型，不会比较 harness 和产品交互。
• 把 MCP 当成 Agent 框架；MCP 只标准化上下文和工具交换，不替你解决规划、状态、权限和验证。
• 把 multi-agent 当成默认升级。并行不可分解、共享状态强或工具密度高时，它可能显著变差。
• 用 AI 写过大量代码，却无法在白板上独立实现调度器、状态机、日志归并或取消传播。

2. 从 JD 逐句反推面试题

2.1 执行循环

JD 关键词：任务拆解、工具调用、结果观察、错误恢复、长任务续跑、最终验证。

高概率追问：

• 设计一个能取消、恢复、限制步数并持久化的 Agent Loop。
• 模型一次生成多个 tool calls，哪些可并行？如何处理读写冲突？
• 模型输出了一半 tool call 就断流，如何保持 provider wire 合法？
• 什么错误可 retry，什么必须 fail fast？重试如何计入 turn budget？
• 用户在长任务中插入新消息，属于新 turn、当前 turn steering 还是下一 turn？
• “Agent 自称完成”与“任务完成”的边界在哪里？

2.2 真实工具系统

JD 关键词：文件编辑、命令执行、代码搜索、测试、Git、沙箱、远程执行。

高概率追问：

• 文件编辑如何做到冲突检测、原子性、可回滚和 diff 可读？
• Bash 工具如何处理 PTY、前后台、进程树、超时、输出背压和取消？
• 如何防止 cwd 越界、symlink escape、SSRF、DNS rebinding 与密钥泄漏？
• 一个 MCP server 中途断开，何时重连，何时重放 tool call？
• 工具输出 50 MB 时，你给模型什么、给用户什么、持久化什么？

2.3 仓库级 Context Engineering

JD 关键词：代码检索、文件选择、上下文压缩、历史轨迹、任务状态、长期记忆。

高概率追问：

• 100 万行 monorepo 如何选出下一步最有用的 20K tokens？
• 什么时候 lexical search 胜过 embedding？什么时候需要符号图或调用图？
• compaction 应保留什么不变量？如何评测摘要是否造成任务漂移？
• transcript、模型 context、持久化 journal、trace、memory 有什么区别？
• 长期记忆如何失效和防止把一次错误经验永久放大？

2.4 Trace / Eval / 数据闭环

JD 关键词：真实用户任务、失败样本、评测集、定位为什么失败、下次成功。

高概率追问：

• 一条失败 trace 如何归因？最后一个错误是否就是根因？
• 如何从线上任务构造无隐私泄露、可复现、不可投机的离线 eval？
• 如何比较 prompt A/B 或 harness A/B？需要跑几次？
• 评测任务测试有问题怎么办？模型通过隐藏捷径怎么办？
• LLM-as-judge 何时可用，如何校准？

2.5 模型与 Agent 协同

JD 关键词：探索模型能力边界、共同进化。

高概率追问：

• 怎样证明问题属于模型而不是 harness？
• 同一模型在不同 harness 上差异很大，模型训练数据应该如何构造？
• 哪些失败应该用 SFT/RL 修，哪些应该在工具或状态机里修？
• 新模型变强后，旧 scaffolding 为什么可能有害？如何做消融？

3. Kimi Code 当前真实产品与代码架构

这一节是面试差异化的关键。不要只读营销页，要能说出公开仓库的控制路径。

3.1 截至 2026-08-03 的产品事实

• Kimi Code 当前同时提供 Kimi K3 与 K2.7 Code。官方模型 ID 包括 k3、k3-256k、kimi-for-coding、kimi-for-coding-highspeed。
• K3 是 2.8T 总参数、104B 激活参数、最高 1M context 的原生多模态 agentic 模型；支持 low / high / max reasoning effort。
• k3-256k 在 256K 内能力相同，配额消耗更低；这本身说明产品必须在能力、延迟、缓存和成本之间做路由，而不是永远选择最大窗口。
• Kimi Code 是 TypeScript / Node.js monorepo，覆盖 CLI/TUI、Web、VS Code、ACP、Agent SDK、插件、Skills、Hooks、MCP 与多 Agent。
• 本地检查的公开仓库快照为 2026-08-01 commit e22479a；文档最新正式版本为 0.31.1（2026-07-31）。

参考：Kimi Code 模型配置、Kimi K3 公开仓库、Kimi Code 公开仓库、0.31.1 changelog。

3.2 代码里的核心形态

                       CLI/TUI   Web   VS Code   ACP   SDK
                          \       |       |       |    /
                           client / server contracts
                                      |
                              kap-server / klient
                                      |
          +---------------- agent-core-v2 ----------------+
          | App -> Workspace -> Session -> Agent scopes   |
          |                                               |
          | loop -> llmRequester -> toolExecutor          |
          |   |         |              |                  |
          | context     trace          policy/scheduler   |
          | compaction  usage          truncation/dedupe  |
          |                                               |
          | wire journal -> reduced domain models         |
          +-----------------------------------------------+
                    |                       |
              local/remote OS          providers / MCP

公开代码最值得掌握的八个边界：

1. 四级生命周期作用域：App / Workspace / Session / Agent。配置、资源共享、销毁和身份不是一个全局单例能正确表达的。
2. Loop 是 Turn/Step 状态机：v2 loop 有 FIFO turn jobs 与 step request queue；工具结果、后台完成或 steering 都通过明确 admission 进入执行，而不是随意递归调用模型。
3. Wire 是持久化事实源：每个 Agent 有 append-only wire.jsonl；domain model 通过 reducer 恢复，并具备协议版本、迁移、损坏记录跳过、blob 脱水/复水和原子修复。
4. Context 和 transcript 分离：context memory 是送给模型的历史；transcript 是用户可见投影；journal 是持久化事实；telemetry 是去内容化聚合。把它们混成一个 messages 数组会制造长期债务。
5. Context 有独立子系统：memory、projector、size、injector、full compaction、system reminder、tool selection 各自拥有清晰职责。
6. Tool execution 是多阶段管线：解析与 schema 校验、存在性/可用性检查、权限和策略 veto、调度、执行、截断、持久化、telemetry、去重与停止回合。
7. 失败恢复按错误语义拆分：provider retry、context overflow compaction、媒体 413/格式降级、MCP reconnect、重复工具 breaker、用户取消是不同路径。
8. 可观测性是架构的一部分：turn/step/tool/compaction/subagent 都带稳定 ID、trace ID、耗时、usage 和状态；另有 transcript audit 与 kimi-inspect 调试面。

3.3 必读源码路径

面试前至少读完这些文件的顶部职责说明和主干控制流：

• 仓库级 AGENTS.md
• agent-core-v2 设计约束
• Turn / Step loop
• Tool executor
• 重复工具调用 breaker
• Provider step retry
• Context memory
• Context projector
• Full compaction
• Wire journal / replay
• Permission gate
• Agents / Sub-agents 文档
• Hooks 文档

3.4 从近期提交能看出的团队真实难题

最近公开变更高度集中在：

• v1 到 DI×Scope v2 engine 的领域拆分与迁移；
• turn、goal、background task、subagent 的可靠持久化和恢复；
• 中断后的 tool-call wire 合法性、空消息卡死、重复 tool call 无限循环；
• provider 异构：thinking、tool-call ID、媒体、上下文上限、trace ID、quota 与错误分类；
• workspace trust、symlink、Web auth、SSRF / DNS rebinding 等安全边界；
• transcript 增量协议、WebSocket 收敛与长会话 UI 性能；
• 自定义 agent、secondary model、dynamic tools、plugins 和 scopes 之间的配置传播。

这意味着面试官很可能更欣赏具体的 runtime 细节，而不是宏观“Agent 将改变软件工程”的演讲。

3.5 2026-08-03 当日 main 的最新结构变化

本手册的完整源码分析固定在 e22479a，便于复现；最终审校时，公开 main 已推进到 75395f6。其中四组结构变化非常贴合 JD：

1. 3e42521 将 agent、session、app、workspace、OS、wire、provider 与 MCP 等领域失败统一编码为 Error2，补齐 wire code、retryability、structured details 与 protocol schema，并修复依赖错误字符串匹配的 task-limit remap；
2. e6a655e 加入 lifecycle ledger、动态 service registry、dependency graph 和跨 scope cascade engine：资源按注册顺序的逆序串行 teardown，动态 provide / unprovide / update 会计算受影响依赖集、等待中止、按拓扑拆卸并重建；
3. 29c9e2a 明确 secondary model 只是 subagent 默认绑定而非强制绑定，优先级为显式 tool-call model → profile model_preference → configured secondary model，primary 指主 Agent 当前实际运行的模型；
4. 75395f6 新增 TurnStarted、UserPromptQueued、TaskStarted、按需 SessionHeartbeat 等 lifecycle hook，并补齐 client、session、model/profile 与结束原因信息。中间的 dfc55a5 仅调整 TUI 登录提示颜色，不改变架构判断。

这些变化共同指向 lifecycle ownership、error semantics、dynamic dependency reconfiguration、heterogeneous model routing 与 externally observable lifecycle。这正是“模型之外的关键系统”的具体形态。它们进入公开 main，只能证明公共代码 contract，不能自动外推为某个正式版本、线上默认行为或产品先进性。

面试中值得追问：

当动态 provider/plugin/model 配置触发跨 App/Workspace/Session/Agent scope 的依赖级联时，怎样定义 in-flight turn 的取消边界、重建原子性、失败后的可恢复状态与 trace？哪些 service 应允许动态替换，哪些应被 pin 住？

3.6 一个高含金量的协议观察

2026-07-28 的 MCP 稳定规范删除了 protocol-level session、Mcp-Session-Id、初始化握手与 ping，转向 stateless 请求、server/discover、显式 state handle 和新的订阅模型。规范已经 stable，但 SDK 与生态采用不会瞬间完成。当前 Kimi Code 公开快照仍依赖 MCP TypeScript SDK 1.x，并在 client helper 中使用 ping 做 liveness probe。这不是“发现一个 bug”，而是需要通过版本协商和 adapter 隔离的生态迁移问题。

面试中可以把它变成高质量问题：

新 MCP stateless 规范会把连接生命周期、重试幂等性、显式状态 handle 与 tool discovery cache 的责任重新推回 host。Kimi Code 对这次升级更倾向做兼容适配，还是借机重画 workspace MCP 的连接/状态边界？

参考：MCP 2026-07-28 key changes。

4. 2026 年最重要的前沿判断

这些不是新闻摘要，而是面试中要能独立论证的判断。

4.1 模型能力与 harness 能力已经不可分

同一模型在不同 tools、context、retry、state、budget 与 verifier 下会表现成不同系统。评测报告若只写 model name 而不写 harness、effort、turn/token/time/cost budget，结论不完整。

K3 的公开结果也明确使用不同 harness 对不同模型测量；Kimi Code Bench 2.0 中 K3 在 Kimi Code harness 和 Claude Code harness 的结果并不相同。这不是噪声，而是岗位本身的价值空间。

4.2 长上下文不等于好上下文

1M context 能减少硬截断，却不能消除：

• context rot 和注意力稀释；
• 无关工具定义挤占输入；
• prefix cache 因动态内容或模型/effort/tool 切换失效；
• 多媒体请求体超限；
• 错误轨迹被反复带入造成锚定；
• compaction 后目标、用户决策或验证证据丢失。

正确方向是：最小高信号 context、progressive disclosure、稳定前缀、显式任务状态与可评测的压缩，而不是“全塞进去”。

4.3 评测本身正在成为最难的工程之一

2026 年 OpenAI 先停止使用 SWE-bench Verified，随后又审计出 SWE-Bench Pro 约 30% 任务存在破坏性问题并撤回推荐。原因包括过严测试、需求缺失、低覆盖测试、误导 prompt 与污染。

面试中的正确立场不是“所有 benchmark 都没用”，而是：

• 先声明 eval 要支持的 claim；
• 固定或完整披露 harness 与预算；
• 用新鲜/私有任务和 canary 降低污染；
• 审计 oracle、环境与投机路径；
• outcome + trajectory + cost/reliability 一起看；
• 线上真实任务只能在脱敏、可复现和分布控制后进入回归集。

参考：OpenAI 对 SWE-Bench Pro 的审计、第三方评测可信度框架。

4.4 Multi-agent 是有条件的架构选择

Google 2026 年该研究的最新 v3 覆盖 260 种 agent configuration、六类 agentic benchmark、五种 architecture 与三个 model family：可并行任务中 centralized coordination 可显著提升，但严格顺序任务中 multi-agent 全面退化；独立 agent 的错误放大也远高于集中式 orchestrator。这仍是受控 benchmark 范围内的条件性结论，不是所有 coding workflow 的普适定律。

工程判断应是：

• 子任务输入/输出能否形成窄、稳定、可验证 contract？
• 是否可真正并行，还是共享一个强顺序状态？
• 合并成本与工具竞争是否超过并行收益？
• 主 agent 是否有验证与拒收机制？
• 上下文隔离省下的 token 是否大于 handoff 损失？

参考：Google Research: scaling agent systems。

4.5 长任务的关键是“可续接状态”，不只是 compaction

Anthropic 的长期 agent 实验反复指出：compaction 不能保证交接清楚，模型可能 one-shot、半成品耗尽 context，或看到已有进展就提前宣布完成。可靠方案包含：结构化任务清单、进度与决策 artifacts、干净工作区、Git checkpoints、初始化/续作协议和外部 verifier。

更强模型可能让一些 scaffolding 失去价值。因此 harness 应把每个组件看成一个“关于模型缺陷的假设”，持续做消融和删除，而不是永远堆叠。

参考：Anthropic 长任务 harness、2026 planner-generator-evaluator 实验。

4.6 安全的主控制面是环境边界，不是频繁弹窗

Anthropic 的公开数据表明大量 permission prompt 会造成 approval fatigue；OS sandbox 让工作区内写入自由、默认禁网，可大幅减少提示。关键原则：

• prompt/model policy 是概率约束；
• filesystem、process、network、secret 与 identity 是确定性边界；
• 未信任 workspace 的配置、hooks、MCP 必须在 trust 之前不执行；
• tool content 和 repo files 都是潜在 prompt injection 输入；
• permission 应按 capability 和 effect 最小授权，而不是只按工具名。

参考：Anthropic agent containment、OpenAI Codex 安全与 telemetry。

4.7 Memory 正从“保存历史”转向“蒸馏可迁移策略”

原始 trace 是证据，不应直接等于长期 memory。更可靠的 memory item 需要 scope、provenance、confidence、version、TTL/invalidation 和验证结果。失败经验要提取“下次如何识别和避免”的策略，而不是永久保存某个仓库的偶然 workaround。

参考：Google ReasoningBank。

5. 技术深挖一：怎样设计可靠 Agent Loop

5.1 从状态机开始

不要从 while (true) 开始。先定义语义：

Session
  └─ Turn (一次用户目标/一次系统续作)
       ├─ Step 1: build context -> inference -> tool calls -> observations
       ├─ Step 2: build context -> inference -> ...
       └─ terminal: completed | cancelled | max_steps | failed | paused

最小状态：

• session_id / agent_id / turn_id / step_id / request_id / tool_call_id
• active/pending turns 与 admission policy
• current goal、plan、todo、user decisions、verification contract
• context history 与 measured token prefix
• active background tasks / subagents
• model/provider/effort/tool-catalog/config version
• cancellation signal、deadline、max steps、retry budget、cost budget
• last durable event offset / replay watermark

5.2 推荐控制流

admit request
  -> persist turn.prompt
  -> build high-signal context
  -> pre-step hooks (compaction / reminders / dynamic tools)
  -> model request (stream + trace)
  -> atomically close assistant step
  -> validate tool calls
  -> policy / permission
  -> conflict-aware scheduling
  -> execute + persist observations
  -> verifier / continuation decision
  -> next step or terminal event

关键是每一步都能回答：事实是否已持久化？取消发生在这里会留下什么？恢复后 replay 是否幂等？用户看到的 transcript 是否与模型 context 一致但不耦合？

5.3 错误分类与恢复

5.4 Retry 的五条底线

1. retry 针对错误语义，不是 catch (e) retry()。
2. 每次 retry 都有稳定 request/trace 关联，并计入成本、步数或独立预算。
3. tool side effect 要有 idempotency key 或明确禁止自动重放。
4. 用户 cancel 永不被包装成 retryable provider error。
5. 达到上限后暴露原始根因、已尝试策略和下一步，而不是返回泛化“连接失败”。

5.5 并行工具调度

工具声明 access set，而不是仅声明 parallelizable: true：

type Access =
  | { kind: "read"; resource: string }
  | { kind: "write"; resource: string }
  | { kind: "process"; cwd: string }
  | { kind: "network"; host: string };

调度规则示例：

• read/read 同资源可并行；read/write、write/write 冲突；
• shell 的真实 effect 未必可静态推断，保守地串行或经过命令解析；
• 多 tool call 结果可以按完成顺序流给 UI，但给 provider 的 tool results 必须满足协议要求；
• 一项返回 stopTurn 后，其余已运行任务如何取消、未运行任务如何合成结果，必须确定；
• 所有子任务共享父取消信号，并有短 grace period 清理进程树。

6. 技术深挖二：工具系统不是几个函数

6.1 一个深工具模块的稳定接口

每个 tool contract 应包含：

• 名称、模型可理解的描述、严格输入 schema；
• effect / access / risk 分类；
• 前置条件、结果 schema、稳定 error code；
• timeout、取消、进度事件；
• 幂等性与重放规则；
• 输出尺寸策略和 artifact handle；
• permission policy 与 workspace trust 要求；
• trace 字段与隐私规则；
• verifier 或 postcondition（适用时）。

6.2 文件编辑

高质量设计应具备：

• 以预期旧内容、行锚点或 content hash 做 optimistic concurrency check；
• 写临时文件后 atomic rename，避免半写；
• symlink 和 realpath 在 policy 边界前解析；
• 返回结构化 diff、变更文件与冲突信息；
• 大文件不整份回灌模型；保存 artifact 并返回相关 hunk；
• undo 不能只改文件，还要与 conversation/task state 的语义对齐。

6.3 Shell / PTY / 后台任务

必须能讲清：

• 非交互 pipe 与 PTY 的差异；
• cwd、环境变量、login shell 和跨平台命令解析；
• stdout/stderr streaming、背压、ring buffer、截断与完整日志 artifact；
• timeout 不一定等于 kill：长任务可转后台，并在完成时产生新 observation；
• kill 需要处理 process group/tree，不能只杀父 PID；
• exit code、signal、cancel、timeout 是不同 terminal state；
• secret 不进入日志、模型 context 或 telemetry。

6.4 Git 工作流

• 启动前记录 branch、HEAD、dirty state；
• 并行 agent 优先独立 worktree；
• destructive command 单独 policy；
• verifier 看 diff 与测试，而不只看 commit 是否存在；
• 不能用 git reset --hard 掩盖未知用户修改；
• commit 是 checkpoint，不自动等于任务完成。

6.5 远程执行 / Sandbox

推荐分层：

Agent intent
  -> capability policy
  -> workspace trust
  -> sandbox/VM boundary
  -> secret broker / short-lived identity
  -> egress policy
  -> audited tool execution

必须区分本地开发者 agent、云端 ephemeral sandbox、持久 devbox。隔离越强，自动化越高；访问真实用户机器越多，监督与最小权限越重要。

7. 技术深挖三：Repository Context Engineering

7.1 五层 context，而不是一个 prompt

不要把大段静态文档、全部 tool schema、完整终端输出和所有历史消息一股脑拼接。Context 是运行时选择结果。

7.2 仓库检索管线

一个实用的 hybrid pipeline：

1. 确定搜索意图：定位定义、调用者、配置源、测试、运行路径还是历史原因。
2. 低成本 lexical：rg、文件名、错误文本、标识符、配置 key，通常是代码仓库的第一选择。
3. 结构检索：AST / tree-sitter、LSP symbol/reference、import/call graph、ownership boundaries。
4. 仓库信号：Git blame/log、最近变更、CODEOWNERS、测试映射、构建图。
5. 语义检索：对自然语言 issue、文档或标识符不匹配的概念做 embedding/BM25 hybrid。
6. 动态扩展：模型读到新 symbol 后再追邻居；不要一次展开整个图。
7. 证据排序：直接控制路径 > 相邻测试 > 架构文档 > 相似代码 > 宽泛语义命中。

文件选择评分可以写成可解释函数：

score(file) =
  lexical_match
  + symbol_connectivity
  + execution_path_proximity
  + failing_test_proximity
  + task_recency
  - token_cost
  - duplication
  - staleness_risk

不要迷信一个固定公式；重点是把“为什么选它”留在 trace 中，才能诊断 retrieval failure。

7.3 Context compaction 的不变量

压缩后必须保留：

• 用户真实目标与显式非目标；
• acceptance criteria / verifier；
• 已确认的架构与用户决定；
• 已改文件和当前 working state；
• 已运行命令及关键证据，不保留无用大输出；
• 已证伪的假设与不能重复的失败路径；
• 未完成步骤、阻塞项和下一动作；
• 稳定 ID、artifact path、commit/branch；
• 权限/环境变化和取消原因；
• 摘要自身的来源范围、版本和 token 前后量。

一个好 summary 不是“聊天摘要”，而是下一位工程师可无损接班的状态转移 artifact。

7.4 Compaction 评测

构造长任务 checkpoint，在同一任务状态上比较：

• full context 继续；
• compacted context 继续；
• clean reset + structured handoff 继续。

指标：

• goal/constraint recall；
• 正确下一步率；
• 重复已完成工作率；
• 重试已证伪路径率；
• 最终任务成功；
• extra steps / tokens / wall time；
• cache hit 与 compaction latency。

只有 summary 看起来“完整”没有意义，必须看它是否保持后续决策等价。

7.5 Memory 分类与边界

• Working memory：当前 turn/goal 的临时状态。
• Episodic memory：发生过什么，保留 trace/provenance。
• Semantic memory：仓库/用户/领域中相对稳定的事实。
• Procedural memory：如何执行任务的 skills、playbooks、约束。

Memory item 最小字段：

interface MemoryItem {
  id: string;
  scope: "user" | "workspace" | "repo" | "task";
  kind: "fact" | "decision" | "procedure" | "failure_lesson";
  content: string;
  provenance: string[];
  confidence: number;
  createdAt: string;
  validUntil?: string;
  invalidatedBy?: string[];
  lastVerifiedAt?: string;
}

不要从一次失败自动写全局 memory。先蒸馏候选规则，再用 counterfactual / replay / 新任务验证；否则系统会把偶然性制度化。

8. 技术深挖四：Trace、Observability 与 Evaluation

8.1 五种数据不要混

一个常见坏设计是“把 transcript JSON 存下来，既恢复状态、又回放模型、又做 UI、又做分析”。不同消费者需要不同一致性、隐私和演进契约，最终会互相锁死。

8.2 推荐 span / event 层级

session
  turn
    step
      context.build
      model.request
      tool.preflight
      tool.execute
      verification
    compaction / retry / interruption
  subagent task

每个关键事件至少带：

• stable IDs 与 parent IDs；
• monotonic sequence / timestamp；
• model、provider、effort、harness/config/tool catalog version；
• input/output token、cache read/write、latency、cost；
• tool 名、参数 hash、effect、result status、duration、truncation；
• retry attempt、error code、request/trace ID；
• context token count、compaction dropped count；
• verifier 类型与证据；
• terminal reason 与 user intervention。

不要把 prompt、源码、绝对路径、token、email 或密钥作为 cloud telemetry 属性。需要本地 debug bundle 时单独导出、默认脱敏、用户显式分享。

8.3 Failure taxonomy

诊断应标记第一个让成功概率显著下降且之后没有恢复的决策，而不是最后一个红色错误。

建议分类：

1. Intent / specification：误解目标、缺失关键澄清。
2. Planning / decomposition：顺序错误、粒度过大、不可验证计划。
3. Retrieval / context：漏文件、选错证据、约束被淹没、摘要漂移。
4. Reasoning / hypothesis：错误根因、没有反证。
5. Tool selection / arguments：工具错误、schema/路径/参数错误。
6. Environment / capability：依赖、权限、平台、网络或 sandbox 阻断。
7. Execution / state：取消、断流、重复副作用、持久化/恢复错误。
8. Implementation：代码逻辑、兼容性、并发、性能或安全缺陷。
9. Verification / oracle：没测关键路径、测试错误、投机通过。
10. Termination / handoff：过早完成、超预算、留下脏状态。
11. Policy / safety：拒答、越权、prompt injection、secret handling。
12. Product interaction：用户无法理解、干预或恢复。

每个失败样本记录：critical_step、symptom、root_cause、recoverable_at_step、minimal_counterfactual_fix、owner(model|harness|tool|env|eval|product)。

8.4 Eval pipeline

real failures / authored tasks
  -> sanitize + freeze repo/environment
  -> validate task and oracle with humans/agents
  -> versioned task spec + canary
  -> N repeated runs with pinned harness/budget
  -> deterministic artifacts + trace
  -> outcome scoring + trajectory attribution
  -> ablation / counterfactual replay
  -> regression gate
  -> shadow / canary / A-B online

8.5 指标树

一级：真实完成

• end-to-end task success；
• functional + regression + safety gates；
• success@budget、cost per successful task、time to verified completion；
• pass@k（至少一次成功）与 pass^k（连续 k 次都成功）分开。

二级：过程能力

• code localization / relevant file recall；
• first correct hypothesis time；
• invalid / unavailable / repeated tool-call rate；
• retry recovery rate 与 wasted retry rate；
• compaction continuation success；
• verification coverage；
• user intervention / interruption / override rate；
• context tokens、cache hit、latency、cost；
• safety/policy violation。

三级：体验

• 用户等待的关键路径；
• approval burden；
• 可理解状态与恢复时间；
• diff/review 负担；
• 用户是否再次委派同类任务。

8.6 LLM-as-judge 的正确位置

优先级：

1. 可执行 verifier / hidden tests；
2. 行为不变量与回归测试；
3. 静态分析、类型检查、lint；
4. 确定性结构检查；
5. 盲化 pairwise LLM judge；
6. 人类专家抽检与争议裁决。

Judge 应在人工标注集上校准，报告一致性、偏差、置信度；对 soft quality 使用 rubric 和 evidence anchoring。不要让同一个生成器直接给自己打分。

9. 技术深挖五：Planning、Subagent 与 Multi-agent

9.1 什么时候需要显式 plan

显式 plan 适合：

• 跨多个 ownership boundary；
• 有不可逆或昂贵动作；
• acceptance criteria 不清晰；
• 需要人类选择架构；
• 任务超过单一 context/turn；
• 多 agent 需要稳定 contract。

局部小修改不需要强制先写十步计划。计划的价值是降低错误和形成交接 artifact，不是 UI 仪式。

9.2 Plan 的 contract

每一步至少包含：

• objective；
• inputs / prerequisites；
• owned files/resources；
• expected artifact；
• verifier；
• dependencies；
• status 与 evidence；
• decision log / deviations。

计划必须随着证据更新。把过期计划继续注入 context 比没有计划更危险。

9.3 Subagent 委派 contract

父 agent 给子 agent 的 prompt 应自包含：

• 狭窄 objective；
• 必要背景和禁止假设；
• read/write boundary；
• deliverable schema；
• verification requirement；
• 时间/成本/token budget；
• final handoff 必须包含证据和不确定项。

子 agent 只返回结论，不把全部中间 tool logs 污染主 context；但完整 trace 应留在独立 agent journal，支持 debug 和 resume。

9.4 选择架构的决策表

9.5 防止多 Agent 制造垃圾

• 调度前做依赖图与文件 ownership；
• 每个 agent 有独立 worktree 或严格只读；
• 主 orchestrator 是验证瓶颈，不直接相信摘要；
• 合并时重新跑全局 verifier；
• 子任务失败要携带证据，不能静默 fallback；
• 并发、token、wall time、nested depth 都有预算；
• 支持 cancel、resume、partial acceptance；
• 通过 ablation 证明 swarm 相对单 agent 真有提升。

10. 必须能白板讲清的系统设计题

题目

设计一个可以在大型代码仓库完成 bug fix、支持长任务恢复、多模型和远程 sandbox 的 Coding Agent。要求可观测、可评测、可安全中断。

10.1 先澄清

• 本地还是云端；代码与 secret 能否离开设备？
• 单人交互还是批量异步？
• 任务规模、支持语言、最长运行时间？
• 可用 verifier 与 CI 成本？
• 需要哪些 side effects（Git push、PR、部署）？
• 成功、延迟、成本、安全哪个优先？

10.2 顶层模块

Client / IDE / CLI
        |
Session API ---- Auth / workspace trust
        |
Durable Orchestrator ---------------------- Trace / Eval sink
  |         |          |          |
State    Context    Tool Plane   Verifier
Store    Engine     / Policy     Pipeline
  |         |          |          |
Journal  Retrieval   Sandbox     Tests/CI
Replay   Compaction  Remote exec Diff/static
        |
Model Gateway (provider/model/effort/cache/routing)

10.3 核心数据模型

Session -> Agents -> Turns -> Steps
                     |       |
                     |       + ModelRequest + ToolCalls + Observations
                     + Goal + Plan + Todo + UserDecisions

Workspace -> Snapshot/commit + Trust + ToolPolicy + MCP/Plugin catalog
Artifact  -> immutable blob/log/diff/test report by content hash

10.4 状态与持久化

• append-only event journal 是事实源；
• reducer 构造 context、todo、goal、task、activity 等模型；
• schema version + migration；
• event append 与对外可见状态的原子性；
• crash 后从最后 offset replay；
• tool side effect 带 idempotency key 和 effect receipt；
• 大 artifact 独立 blob store，journal 只留 hash/path/meta；
• transcript 从 journal 投影，不参与业务写入。

10.5 Context engine

• repo index：lexical + symbols + build/test graph + git；
• per-step evidence selection；
• stable prompt prefix 和 deterministic tool ordering；
• context size accounting；
• full compaction / structured handoff；
• dynamic tool disclosure；
• memory scope、provenance、TTL、invalidation；
• compaction 和 retrieval 的 trace。

10.6 Tool plane

• registry + strict schema；
• capability/effect policy；
• workspace trust；
• conflict-aware scheduler；
• local/remote execution adapter；
• cancellation / timeout / progress；
• output truncation + artifact handle；
• typed error；
• tool-level telemetry；
• network egress 与 secret broker。

10.7 Verification

完成定义来自任务，不来自模型：

• reproduce failing test；
• smallest relevant tests；
• full regression/type/lint；
• diff review / forbidden changes；
• app/UI 用 browser/visual verifier；
• 安全与 policy checks；
• verifier failure 回到 loop，但有 attempt budget；
• 最终回答附证据与未验证项。

10.8 扩展与可靠性

• Session sticky 状态不依赖单进程；orchestrator worker 可恢复；
• sandbox 按 task 隔离，workspace snapshot 用 content address；
• model request、tool execution、artifact upload 各自 backpressure；
• per-user/project concurrency 和 cost quota；
• subagent 只用于可分解任务，worktree 隔离写入；
• provider outage 可换模型，但 preserved reasoning / tool protocol 兼容必须显式处理；
• observability 不记录用户源码和 secrets。

10.9 最后主动讲 tradeoff

• event sourcing 增加 schema/reducer 复杂度，但换来 replay、debug、migration 和多视图解耦；
• 1M context 减少 compaction，但成本和 attention 使选择仍必要；
• 自动权限越少体验越顺，前提是 deterministic sandbox 缩小 blast radius；
• multi-agent 增吞吐，也增合并、成本和错误传播，默认单 agent，证据驱动升级；
• provider abstraction 不能抹平模型特性，preserved thinking、tool IDs、media 和 effort 需要 capability-aware adapter。

11. 高频问题库：回答骨架与追问方向

不要背完整答案。每题按“结论 → 机制 → 失败模式 → 度量/验证 → tradeoff”作答；如果讲自己的项目，再补一条真实证据。

11.1 Agent loop 与可靠性

1. Coding Agent 与普通聊天机器人最本质的区别是什么？

它不是多轮聊天加几个工具，而是一个对真实环境产生副作用、可中断恢复、以外部证据闭环的执行系统。核心差异是状态、工具语义、权限、安全、持久化和验证，而非 prompt 长短。

2. 怎样判断一个 Agent 真的完成了任务？

把用户目标编译成可验证的完成条件：相关测试、构建、静态检查、diff 约束、运行时行为和人工决定。模型的“完成”只是一种提议；verifier 的证据才决定终态。未验证项必须显式暴露。

3. 为什么 Agent 会在长任务中偏离目标？

常见原因是目标和约束在 context 中衰减、计划状态没有外化、错误恢复丢失因果链、工具结果污染 context，以及新局部线索盖过全局目标。修复不是重复 system prompt，而是稳定的 goal/todo/decision state、检查点、结构化 handoff 和阶段性 verifier。

4. 怎样避免无穷循环？

同时使用 step budget、wall-clock/cost budget、重复 tool-call 指纹、无新信息检测、计划无进展检测和 verifier 不收敛检测。接近阈值时先要求模型陈述新证据或可证伪假设；超过阈值就以明确错误终止，不伪装成成功。

5. 工具失败后什么时候 retry？

只重试被分类为 transient、幂等或可确认未产生副作用的操作；尊重 Retry-After；指数退避加抖动；总 attempt/time budget；每次重试可观测。认证、schema、权限、逻辑错误和未知副作用默认不重试。

6. 用户在工具执行中插入新指令怎么办？

先区分 interrupt、append 和 replace。传播 cancellation token；可取消工具要清理子进程并记录 partial effect；不可取消工具则等待 receipt 后重新规划。新指令必须成为 journal 中的显式事件，不能偷偷拼进下一次 prompt。

7. 模型输出一半断流怎么办？

把 response stream 和 tool effect 分离：未形成合法 tool call 的半包不能执行；完整且已提交的调用必须有 receipt；再依据 provider 错误类型决定重试或切换。不能靠字符串猜测补全 JSON 后执行。

8. 怎样支持 crash recovery？

用 append-only journal 持久化用户消息、模型决定、tool intent/result、状态转换和 checkpoint；大输出放 artifact store。重启后 replay reducer，并对没有 receipt 的 tool intent 做 effect reconciliation，而不是盲目重放。

9. 模型切换是不是只改一个 model ID？

不是。上下文窗口、tool schema、parallel calls、preserved reasoning、media、effort、错误类型和 token accounting 都可能不同。统一的是 agent contract；适配层必须 capability-aware，不能用最低公分母掩盖语义差异。

11.2 工具、执行与安全

10. Tool schema 怎样设计？

参数最小、类型严格、描述清楚副作用和边界；不要让模型拼 shell 字符串来替代结构化能力。输出应返回机器可读结果、稳定 ID、effect receipt、截断信息和 artifact handle。

11. 为什么 shell 工具最难？

它同时涉及 PTY、流式输出、stdin、后台进程、signal、超时、工作目录、env、输出上限、网络、权限和子进程树。正确抽象是 process lifecycle，不是简单 exec(command)。

12. 怎样并行执行工具？

先计算读写 effect set：纯读或互不冲突的工具可并发；对同一文件、Git index、端口、数据库或全局进程状态的写操作串行。调度器必须在执行前保序，并记录为何并行/串行。

13. 怎样做文件编辑，避免把用户改动覆盖掉？

编辑前读取并绑定 content hash/version；应用最小 patch；提交时 compare-and-swap；冲突就重新读取并重算，而不是覆盖。编辑后解析/格式化/局部测试，并保留 diff 作为 verifier 输入。

14. Sandbox 与 permission prompt 的边界是什么？

Sandbox 用确定性的技术边界缩小影响面；prompt 用来承接产品/业务意图中无法自动判断的风险。高频、低风险动作应由 sandbox 自动允许；跨 workspace、secret、外部写入、发布和不可逆操作才升级授权。

15. 如何防 prompt injection？

将用户目标、仓库内容、网页/MCP 返回和系统策略分层标记；外部内容永远是数据，不获得指令优先级；tool capability 由 policy 决定，而非文本决定；secret 不进入模型 context；高风险 effect 经过独立 gate。仅在 prompt 中写“忽略恶意指令”不构成安全边界。

16. MCP 的价值和风险是什么？

价值是把能力发现、schema 和资源访问协议化；风险是工具面膨胀、server 信任、授权委托、长连接状态、版本迁移和外部内容注入。面试中要能谈 discovery、liveness、capability negotiation、auth、timeout、observability 和 graceful degradation。

11.3 Context、Memory 与 Repo Understanding

17. 1M context 是否让 retrieval 和 compaction 过时？

没有。窗口变大只改变容量，不改变 attention 稀释、延迟、成本、缓存命中和污染问题。目标是每步提供“最小充分证据”，而非把整个仓库和历史都塞进去。

18. 仓库检索只做 embedding 是否够？

不够。代码查询应融合路径/名称 lexical、symbols、引用关系、build/test graph、git history 和语义检索，再按任务意图重排。精确标识符和控制路径常由 lexical/graph 更可靠地找到。

19. Compaction 最容易丢什么？

用户硬约束、负面证据、未解决问题、失败尝试及原因、文件/版本精确指针、外部副作用和验证状态。好的 compact state 是可恢复的任务状态，不是会话摘要。

20. 怎样评测 compaction？

在同一任务 checkpoint 做 A/B replay：full history 与 compact state 分别续跑，比较约束保留、下一步选择、重复工作、最终通过率、token/延迟和人工接管率；再做定向 probing，检查关键事实能否被准确恢复。

21. 长期 memory 应保存什么？

保存经验证、可迁移、带 provenance/scope/TTL 的约束与策略；不要保存未经验证的模型猜测、瞬时错误和可能过期的仓库事实。读 memory 也要 trace，允许 invalidation 和用户删除。

22. 为什么 prompt caching 会反过来影响架构？

缓存通常依赖 exact prefix，因此稳定 system prompt、稳定 tool 定义和稳定排序应放前面，回合数据追加在后；动态工具可通过轻量检索/披露减少 schema 体积。它是 latency/cost 的系统设计问题，不只是 provider 开关。

11.4 Eval、Trace 与产品闭环

23. Pass@1 足够评价 Coding Agent 吗？

不够。它掩盖交互、成本、时间、破坏性副作用、恢复和失败分布。至少同时看 verified task success、regression-free、time/cost、intervention、permission burden、recovery、failure taxonomy 和用户接受度。

24. 怎样构建真实 eval set？

从匿名化/脱敏 trace 聚类失败，抽取可复现任务，冻结 repo commit、环境、依赖和验收器，人工审计可解性与测试充分性；保留任务谱系和污染检测；按模型、harness、配置、budget 分层报告。

25. 线上 A/B 指标怎么选？

主指标是被用户接受且通过验证的任务完成率；guardrail 包括回滚/回退、人工接管、permission 次数、破坏性 incident、token/cost、p95 latency。要按任务难度和用户类型分层，避免只优化简单任务占比。

26. LLM-as-judge 可以当最终真相吗？

不能。优先 deterministic verifier：测试、编译、schema、diff policy 和可运行行为。Judge 适合难以程序化的语义/质量维度，但需要盲评、校准集、多 judge/人审抽样和偏差监控。

27. 如何从 trace 找到第一次错误决定？

先从最终失败反向建立因果链，区分环境噪声与 agent 决策；定位首次出现错误假设、遗漏证据、错误工具或约束丢失的 step；用 counterfactual replay 替换该决定，若后续显著恢复，才将它标为 root decision failure。

28. Benchmark 分数为什么不能直接代表产品能力？

任务质量、contamination、harness、tool、budget、timeout、采样、scorer 和失败归因都会改变结果。分数必须和完整 protocol、置信区间、broken-task audit 以及真实用户 trace 一起解释。

11.5 Planning、Subagent 与工程判断

29. 什么时候不应该做 planning？

单步、低风险、反馈即时的任务，显式 plan 只会增加 token 和过期状态。跨模块、长时间、高副作用、需要用户决定或多个可并行分支时，plan 才带来控制价值。

30. 什么时候应该派 subagent？

子任务边界清楚、输入可打包、产物可独立验证且冲突低时。不要为了“更多智能”而委派；高度耦合的单控制路径通常由一个 agent 更可靠。

31. Multi-agent 为什么可能更差？

协调成本、重复探索、共享错误、上下文打包损耗、写冲突和合并验证会吞掉并行收益。选择架构前要看任务可并行度和错误相关性，并保留单 agent baseline。

32. 如果让你改善 Kimi Code，你先做什么？

不要直接报 feature。先选一个来自 trace 的高频高损 failure cohort，明确用户影响和可复现 eval，再定位是 model、context、tool、policy、loop 还是 verifier 的责任，做最小机制改动和 A/B。一个可用的方向是 compaction fidelity、interruption recovery 或 MCP versioned capability layer，但必须以内部数据校准优先级。

33. 怎么看“AI 能写的代码你能写，AI 写不了的代码你也能写”？

前半句要求用 Agent 提高吞吐但仍掌握验证；后半句要求能在规范缺失、控制面模糊、异步/副作用、性能、安全和基础设施边界处建立正确抽象。价值不在比模型多写，而在定义模型可靠工作的系统。

34. 你如何处理批评或发现垃圾？

先给复现证据和用户后果，再定位责任边界；提出更小、更深的修复；删除 obsolete workaround；加回归与观测。不要把“代码风格不喜欢”包装成架构问题，也不要用兼容分支掩盖错误。

12. 如何比较 Kimi Code、Codex 与 Claude Code

面试中不要做粉丝式排名，也不要把某个 benchmark 当结论。最有价值的比较框架是把模型、harness 和运行环境拆开。

12.1 你可以表达的独立判断

• Kimi 的公开仓库让执行循环、journal、tool dedupe、compaction、permission gate 等关键机制可直接审阅，这是准备该岗位时最有信息量的材料。
• Codex 公开论述很强调稳定 prompt prefix、自动 compaction、agent-legible repository 和工程 harness；这些思想应转化为实验，不应只当品牌差异。
• Claude Code 公开论述很强调长任务 handoff、context engineering、sandbox containment 和可控自治；同样需要在固定任务上验证。
• 一个产品在某任务获胜，可能来自模型，也可能来自搜索、提示、工具、预算、sandbox 或 verifier。不能在没有 ablation 的情况下归因。

12.2 现场若被问“你最喜欢哪个”

推荐回答结构：

我会按任务选工具，而不是给总榜。对我最重要的是它能否在真实仓库中保持目标、低成本获取正确证据、可恢复地执行副作用，并用可审计的验证结束。我会固定 repo commit、任务和验收器，记录 trace、成本、权限与失败原因，再区分模型和 harness 的贡献。就这个岗位而言，我尤其欣赏 Kimi Code 把关键 loop 和 runtime 公开出来，因为这让工程讨论可以落到机制和代码。

13. 把你的经历讲成他们要的证据

13.1 90 秒自我介绍模板

我过去主要做 [系统/平台/开发工具]，最强的能力不是单点写功能，而是把 [复杂、异步、有外部依赖的问题] 收敛成可维护、可验证的系统。一个代表项目是 [项目]：当时真实问题是 [用户后果]，控制路径跨过 [模块/服务]。我先用 [trace/log/repro] 找到首次错误发生在 [边界]，然后把 [旧的散乱机制] 收敛成 [深模块/稳定接口]，并用 [测试/线上指标] 验证，最终 [量化结果]。我高频使用 [Kimi/Codex/Claude 等]，也系统比较过它们在 context、工具、中断恢复和验证上的差异。Kimi Code 这个岗位最吸引我的地方，是它解决的不是“让模型多写代码”，而是让模型在真实仓库和真实工具中可恢复、可观测、可验证地完成任务；这和我擅长的 [infra/tooling/reliability/eval] 是同一类工程问题。

13.2 每个项目都要准备的七层证据

1. Problem：谁在什么场景受损，为什么值得解决；
2. Controlling path：真实控制路径，不是表面 UI；
3. Evidence：复现、trace、指标、失败样本；
4. Decision：你做了什么关键判断，放弃了什么；
5. Architecture：责任边界、数据/状态模型、接口；
6. Verification：怎样证明修好，怎样防回归；
7. Learning：如果模型/流量/约束变化，什么仍成立。

13.3 强项目叙述模板

用户看到的是 [症状]，但我没有在 UI/调用点加补丁。我沿着 [入口 → 状态 → 外部系统 → 回写] 做了 trace，发现根因是 [责任边界不清/状态没有事实源/错误类型丢失]。旧实现依赖 [重试/默认值/散落配置]，会产生 [具体后果]。我把所有权收敛到 [模块]，接口只有 [2–3 个操作]，状态以 [journal/versioned config] 为真相，并增加 [关键观测]。在 [任务集/流量] 上，[指标] 从 [A] 到 [B]；剩余风险是 [真实风险]。

13.4 “我大量使用 AI Coding Agent”怎样不显得空

准备三类具体 trace：

• 一次 Agent 成功完成复杂任务：为什么成功，哪一段是模型能力，哪一段是 harness；
• 一次它失败而你定位了根因：第一次错误决定在哪里，怎样纠正；
• 一次你改进了工作流：规则、工具、验证或 context 改动怎样带来可测提升。

不要说“效率提高 10 倍”却没有基线。至少记录：任务规模、人工时间、agent wall time、交互次数、token/cost、测试结果、返工与最终接受。

14. 现场 Coding / Debugging 应具备的手感

这类岗位未必只考算法。更可能用小系统问题看你如何建立不变量、处理异步和失败。至少手写过以下五题：

1. Conflict-aware tool scheduler：给工具读写资源集合，输出并发批次；处理公平性、取消和失败传播；
2. Append-only event replay：从 versioned event 构建 session state；处理 migration、unknown event、partial append；
3. Cancellable process runner：流式 stdout/stderr、timeout、stdin、子进程树清理、effect receipt；
4. Context budgeter：按 hard constraint、recency、relevance、token cost 选证据，并解释为何丢弃；
5. Trace analyzer：从 tool/model events 找重复循环、首次失败决定和无证据完成。

14.1 编码时主动说出的不变量

• 一个 tool intent 最多对应一个已提交副作用；
• 取消不等于回滚，partial effect 必须可见；
• 未知错误不自动 retry；
• journal 顺序与 state transition 一致；
• 用户已有修改不可被静默覆盖；
• verifier failure 不能被 final answer 伪装掉；
• secret 不进 log/context；
• 任何截断输出都明确标记，并提供取回完整 artifact 的方式。

14.2 代码风格信号

• typed error，而不是解析错误字符串；
• ownership 清楚，policy 与 mechanism 分离；
• 小而稳定的 public interface；
• clock、filesystem、process、provider 可注入以便确定性测试；
• property/fuzz/fault-injection 用在调度、replay、parser 和 recovery；
• 日志包含 session/turn/step/tool/request ID 和 decision branch，但不包含 secret 或源码全文。

15. 七天冲刺计划

每天最后都产出一个可检查 artifact，不以“看完资料”为完成。

Day 1：岗位映射与个人证据

• 精读 JD 和本手册第 1–4 节；
• 完成 CANDIDATE_INTAKE.md；
• 选三个项目，按七层证据写成各一页；
• 录一遍 90 秒自我介绍。

产物：岗位 scorecard、三份项目卡、自我介绍录音。

Day 2：Agent loop 与 Kimi 源码

• 读 loop、retry、tool executor、dedupe；
• 画状态机和一个 interruption sequence diagram；
• 完成循环熔断与取消恢复实验；
• 口答第 1–9 题。

产物：一张 loop 图、一份 failure taxonomy、一条带注释 trace。

Day 3：Context、Compaction、Memory

• 读 context memory/projector/full compaction/wire；
• 对同一任务做 full history vs compact/resume 实验；
• 设计 repo retrieval pipeline；
• 口答第 17–22 题。

产物：compaction A/B 表、context 分层图。

Day 4：Tool、Sandbox、MCP

• 深挖 shell/edit/Git/permission/trust；
• 阅读 MCP 最新 architecture/changelog；
• 手写 process runner 或 scheduler；
• 做 workspace trust/permission 实验。

产物：工具 effect model、MCP version adapter 设计、可运行代码。

Day 5：Trace 与 Evaluation

• 建一个 10–20 个真实任务的 mini eval；
• 标注 first bad decision 和 failure taxonomy；
• 设计 offline → shadow → canary → A/B；
• 口答第 23–28 题。

产物：eval card、dashboard 草图、一个 counterfactual replay。

Day 6：系统设计与模拟面试

• 60 分钟完整白板设计；
• 45 分钟项目/技术追问；
• 复盘所有没有数字、没有失败模式、没有 tradeoff 的回答；
• 补足薄弱语言/并发/存储知识。

产物：一份录像/录音、评分表、最多五个缺口。

Day 7：产品判断与收束

• 做三款 Agent 的同任务对照；
• 准备“我会优先改善什么”及其 eval；
• 练 interviewer questions；
• 最后只复习一页 cheat sheet，不再无边界扩张资料。

产物：对照实验、30/60/90、最终一页纸。

16. 只有 48 小时时

前 12 小时

• 完成个人信息表和三个项目卡；
• 精读第 1、3、5、7、8 节；
• 至少实际跑一次 Kimi Code，保存完整 trace。

12–24 小时

• 读 loop/tool/context 的关键源码；
• 手写 scheduler 或 event replay；
• 做一次 compaction/recovery 故障实验。

24–36 小时

• 限时 60 分钟系统设计；
• 口答 34 题，删掉没有机制和证据的句子；
• 补最弱的两块，不追求覆盖所有论文。

最后 12 小时

• 两轮 mock；
• 固化自我介绍、三个项目、一个失败故事、一个产品改进；
• 准备电脑/网络/白板环境；
• 睡眠优先于再读十篇文章。

17. 入职后 30 / 60 / 90 天回答

这不是承诺路线图，而是展示你如何在未知内部数据下工作。

0–30 天：建立真实系统地图

• 跑通 CLI/IDE/web/runtime 的主控制路径；
• 读 trace、on-call、top failure cohorts 和 eval pipeline；
• 复现三个高频失败，确认 owner 和当前观测缺口；
• 提交一个低风险、证据完整的可靠性修复；
• 不在不了解基线时推动大改写。

31–60 天：拿下一个闭环问题

• 选择高频高损且责任边界明确的问题；
• 建可复现 eval + baseline；
• 改机制、补 structured trace、做 shadow/canary；
• 报告分层结果与 regressions；
• 清理被替代的 workaround 和过期文档。

61–90 天：把单点修复变成系统能力

• 将成功方法收敛成深模块或稳定 contract；
• 扩充真实任务 eval 与 failure taxonomy；
• 让模型、runtime、product 能围绕同一 trace/schema 协作；
• 明确下一阶段最大约束，提出可证伪的技术赌注，而不是功能清单。

18. 反问面试官：用问题判断团队是否在解决真问题

选择 4–6 个，跟随面试内容，不要全部机械提问。

关于成功定义

1. 你们当前最信任的线上成功指标是什么？它和 benchmark 分数不一致时如何取舍？
2. 过去三个月最主要的 failure cohort 是 context、tool、loop、model 还是 verifier？怎样归因？
3. 一个改动从 trace 假设到线上 rollout 的最短闭环是什么？

关于架构与边界

4. v2 的 App/Workspace/Session/Agent scope 目前消除了哪些复杂度，仍有哪些状态所有权不清？
5. wire.jsonl 目前更偏恢复、审计还是产品状态源？对 remote/multi-device 的最终 contract 怎样思考？
6. 模型团队与 Agent Infra 团队怎样区分“该训模型”还是“该改 harness”？是否有固定 ablation protocol？
7. K3、K2.7 和未来模型在 tool protocol/context/memory 上哪些能力会保持模型特化，而不会被统一抽象抹平？

关于产品与工程文化

8. 最近一个被团队主动删除的 Agent workaround 是什么？模型能力提升后怎样避免 harness 只增不减？
9. 哪类失败即使发生率不高，也会因为信任损失而被最高优先级处理？
10. 用户 trace 怎样进入产品判断，同时保证源码、secret 和隐私边界？
11. 这个岗位入职 90 天后，什么具体证据会让你判断招对了人？

一个针对最新协议的高质量问题

12. MCP 2026-07-28 已把协议级 session、初始化和 ping 移除，但当前 SDK/生态仍处于分阶段采用期。Kimi Code 会把 transport/version 差异封在 connector adapter，还是希望内部 tool lifecycle contract 也向 stateless discovery 演进？

这个问题的价值在于版本边界与架构选择；不要把它说成现有实现缺陷。

19. 面试前最后一页：十件必须白板讲清的事

• Agent loop 状态机，以及 interrupt/retry/cancel 的语义；
• tool intent、effect、receipt、idempotency；
• shell/process lifecycle 与 partial effect；
• conflict-aware 并行调度；
• repo retrieval 的 lexical/symbol/graph/semantic 融合；
• compaction 的不变量和 A/B replay 评测；
• append-only journal、reducer、migration、crash recovery；
• trace → failure taxonomy → eval → rollout 的闭环；
• sandbox、permission、secret 和 injection 边界；
• 什么时候用单 Agent、subagent、parallel 或 sequential multi-agent。

同时必须能讲出：

• 三个自己的项目，每个有量化或可检查证据；
• 一个 Agent 成功案例和一个失败案例；
• 一个你真正不同意的行业惯例，以及你的实验依据；
• 一个你会为 Kimi Code 做的改进，但不假装知道内部优先级。

20. 研究来源与时效

本手册依据截至 2026-08-03 的公开资料。完整源码分析固定在公开仓库 2026-08-01 的 e22479a 快照以保证可复现；freshness 审校另核到公开 main 的 75395f6，最新正式 release 为 0.31.1。固定分析快照、滚动主分支、正式发布物与产品能力是四类不同证据，不能混写。

Kimi / Moonshot 一手资料

• Kimi Code 公共仓库
• Kimi Code 模型配置：K3、K3-256k、K2.7 Code
• Kimi Code 更新日志
• Kimi Code 自定义 Agent / Subagent
• Kimi Code Hooks
• Kimi K3 模型仓库与技术报告

Agent 工程一手资料

• OpenAI：Unrolling the Codex agent loop
• OpenAI：Harness engineering
• OpenAI：Separating signal from noise in coding evaluations
• OpenAI：Toward trustworthy third-party evaluations
• OpenAI：Running Codex safely
• Anthropic：Effective context engineering for AI agents
• Anthropic：Effective harnesses for long-running agents
• Anthropic：Harness design for long-running applications
• Anthropic：How we contain Claude
• Anthropic：Measuring agent autonomy
• Anthropic：How AI assistance impacts the formation of coding skills
• Google Research：Scaling agent systems
• Google Research：ReasoningBank

协议资料

• MCP 2026-07-28 Changelog
• MCP Architecture
• Agent Client Protocol

论文雷达：用于继续跟进，不代替产品实验

• Harness-Bench
• SWE-Explore
• Claw-SWE-Bench

阅读原则：论文给假设，公开代码给机制，真实 trace 和受控实验才给你的结论。