Kimi K3 × legacy kimi-cli 1.49.0：一次 V3 Landing Page 长任务的日志解剖

一次 V3 Landing Page 长任务的日志解剖#

分析对象：Joye 个人博客 /v3 Landing Page 与入场动画任务
日志快照：2026-07-21 00:55:43 AEST
会话 ID：d63877a0-3343-477a-9ad5-b56a23c84b54
工作目录：/Users/joye/Documents/code/blog
分支：feat/v3-landing

结论先行#

这次运行最准确的评价不是“K3 前端能力强或弱”，而是：

1. **K3 是一个很强的长程探索、概念生成和视觉调试模型，但不是天然可靠的需求守门员。**它能读大仓库、并行调研、持续操作两个多小时、看截图定位运行时 CSS 问题，也能在被用户指出方向错误后做出很准确的自我批评；但它会为了工程稳妥而牺牲用户强调的“从零设计”，还会把计划写得比实际实现更丰满。
2. **这套 legacy kimi-cli 已经是一套真正的 Agent runtime，而不只是“LLM + shell”。**它有类型化事件流、持久上下文、checkpoint、子 Agent、后台任务、通知、审批、计划模式和缓存遥测。这里有不少非常值得学习的深模块设计。
3. **它最薄弱的地方是“完成度真相”。**Todo、Plan、构建结果、当前工作树和后台进程彼此独立，没有一个权威任务账本。于是同一时刻可以同时出现：
   • Todo 还说“check/test/build 进行中、截图待办”；
   • 旧版本曾经通过构建；
   • Plan 仍是已经被推翻的旧方案；
   • 当前代码却因为重设计中断而有 2 个类型错误；
   • dev server 仍在后台运行。
4. 最值得你沉淀的不是 K3 的超长思考，而是它的“视觉闭环 + 故障假设推进”；最不该照搬的是“工具调用数量等于进度”和“模型自己维护 Todo 就等于状态一致”。

还要先划清一个关键版本边界：

• 模型确实是 kimi-k3，日志声明上下文上限为 1,048,576。
• 这次真正执行任务的是 Python/uv 版 kimi-cli 1.49.0。
• 机器上虽然也安装了 Node 版 Kimi Code 0.28.0，但本次会话没有使用它。

Kimi 官方已经说明新版 CLI 从 Python/uv 迁移到了 Node.js，旧版将停止维护。因此，本文对事件协议、状态分裂、后台任务和重试的评价，严格限定为本次运行的 legacy harness，不能直接当作新版 Node CLI 的现状。官方迁移说明 ↗

1. 这次运行能够说明什么，不能说明什么#

能够说明#

• K3 在一个真实、非玩具仓库里的行为倾向。
• K3 与 legacy kimi-cli 组合后的长任务执行质量。
• 它如何分解任务、使用子 Agent、维护上下文、处理图片、恢复超时。
• 需求理解、计划、代码、验证和用户反馈之间哪里发生了漂移。
• 这套 harness 的实际状态模型和持久化设计。

不能直接说明#

• K3 在统一 benchmark 上相对其他模型的绝对能力。
• 新版 Node Kimi Code CLI 的 runtime 质量。
• K3 low/high/max 中某一档的准确表现：本地日志没有记录本次 reasoning_effort，不能假定它是官方 benchmark 使用的 max。
• 当前未完成重设计的视觉成品质量。

Kimi 官方自己也明确指出：K3 的不同 coding benchmark 使用了 KimiCode、Claude Code、Codex 等不同 harness；同一个模型的结果不能脱离 harness 来读。官方公布的 K3 benchmark 还是在 max reasoning effort 下取得的。K3 官方技术博客 ↗

2. 日志不是一个文件，而是七个职责不同的模块#

这套 runtime 最值得学习的第一点，是它没有把所有东西塞进一份 conversation transcript。

2.1 context.jsonl：模型的可恢复记忆#

本次快照有 428 行：

几个容易误读的点：

• _usage.token_count 是上下文 token 快照，不是账单累计值。
• 每个成功 LLM step 通常写两次 usage：一次记录请求输入，一次在追加 assistant message 后记录 total，所以 154 个 usage 并不等于 154 次模型调用。
• checkpoint 是上下文 checkpoint。源码里的 revert_to() 会旋转并截断 context.jsonl，但不会撤销已经执行过的文件写入、删除或 shell 命令。
• system prompt 被固化为第一条记录，因此恢复会话时不会因为客户端升级而悄悄更换原始 prompt。这是很好的可复现设计。

2.2 wire.jsonl：类型化、可回放的事件源#

快照包含 846 行，首行协议版本为 1.10。根 Agent 主要事件：

三个子 Agent 的事件又通过 338 个 SubagentEvent 嵌套进根 wire，其中包含 85 组子 Agent ToolCall/ToolResult。

这里的接口设计很成熟：

• tool_call_id 把请求和结果相关联。
• parent_tool_call_id + agent_id 把子 Agent 轨迹归属到父 Agent 调用。
• 后台任务有独立 task ID，结束后转成 Notification。
• UI、日志记录器、ACP/Web 客户端可以消费同一套类型化协议。
• ContentPart 和 ToolCallPart 会先在内存里合并再写入 wire，因此日志不是原始 token-by-token 流，文件不会因每个 token 一行而爆炸。

2.3 state.json：持久，但不权威#

快照中的状态是：

• yolo: true
• title 仍是最初的“简单说一下k3的主要升级能力”
• Todo 仍描述原始 V3 方案：
  • 分支：done
  • 调研：done
  • 原始 V3 实现：done
  • check/test/build：in_progress
  • 截图：pending

但此时用户已经推翻原方案，K3 删除了 V3Intro.astro 并重写了 engine。也就是说，Todo 是模型写入的一份便签，不是 runtime 从真实执行中派生的状态。

Todo 模块隐藏了“写 JSON”的复杂度，却没有隐藏“任务是否真的完成”的复杂度；按模块设计的术语，它是一个持久但偏浅的模块。

3. 实际执行状态机#

源码和 wire 可以互相印证出下面的主循环：

flowchart TD
    U["TurnBegin / 用户输入"] --> C0["写入用户消息与 checkpoint"]
    C0 --> S["StepBegin"]
    S --> CC{"需要 compact?"}
    CC -->|是| CP["压缩上下文"]
    CC -->|否| C1["创建 step checkpoint"]
    CP --> C1
    C1 --> M["调用 K3，流式产生 think/text/tool calls"]
    M --> ST["记录 usage + StatusUpdate"]
    ST --> T{"有 tool calls?"}
    T -->|否| E["TurnEnd"]
    T -->|是| X["并行执行工具"]
    X --> R["ToolResult"]
    R --> G["shield: 追加 assistant + tool messages"]
    G --> S
    M -->|provider / runtime 异常| I["StepInterrupted"]
    I --> E2["TurnEnd；等待人工 continue"]

几个深度很高的实现细节：

1. **先记录模型 usage，再等待工具执行。**这样可以分清 LLM 延迟和工具延迟。
2. **上下文增长使用 asyncio.shield。**即使用户在工具完成后取消，也尽量保证 assistant/tool 对完整写入，避免只记调用、不记结果。
3. **每一步都有 checkpoint。**可以恢复模型记忆和 D-Mail 式回退。
4. **通知在下一步进入模型上下文。**后台任务可以独立完成，再由根 Agent 消费结果。

但它有一个关键边界：

context checkpoint 不是 workspace transaction。

本次最直接的例子是：K3 先删除 V3Intro.astro，随后用户取消。删除操作已经真实发生，checkpoint 只能保证日志知道它发生过，不能把文件恢复回来。

4. 本次运行的量化画像#

4.1 调用、token 与近似成本#

截至快照：

分阶段：

按官方 K3 API 的 $0.30/MTok cache-hit input、$3/MTok cache-miss input、$15/MTok output 换算，这个快照约为 $5.69 API 等价成本。这是便于比较的估算，不是会员账户的真实账单。官方定价 ↗

最新根上下文 StatusUpdate 是 190,868 tokens，约占 1M 窗口的 18.2%。这说明：

• 1M 窗口确实让它能长时间不 compact。
• 但“窗口没满”不等于“运行高效”：累计重复输入已经超过 1,019 万 tokens。
• 高 cache hit 把成本压下来了，却没有消除延迟和注意力漂移。

4.2 思考与延迟#

• 根 Agent think 文本：189,897 字符。
• 根 Agent 对用户可见的普通 text：约 1,799 字符。
• 根 think chunk 中位数：421 字符。
• P90：10,070 字符。
• 最大单段：23,460 字符。

根 Agent 模型步骤耗时：

这说明 K3 的“长程”不是免费午餐。它能持续，但在 170K–190K 上下文和视觉输入下，部分步骤会非常慢。耗时同时受模型推理、服务端排队、网络和上下文大小影响，不能全部归因于模型本身。

4.3 工具使用#

根 Agent 98 次调用中：

三个 explore 子 Agent 又执行了：

• ReadFile 41 次
• Shell 33 次
• Grep 11 次

总计是 183 次工具调用。

这体现了很强的执行主动性，也暴露出一个评价误区：工具调用多只能证明 agent 很忙，不能证明任务更接近用户目标。

4.4 图片造成的持久化膨胀#

• 共读取 18 张截图。
• context.jsonl 总大小：3,705,148 bytes。
• 含图片 data URL 的 18 行占 3,115,579 bytes，即约 84.1%。
• 同一批图片又在 wire.jsonl 里占约 3.10M 字符。

这是一个明显的 harness 优化机会：

• 图片应进入 content-addressed blob store。
• context/wire 只保存 hash、尺寸、路径、缩略图和模型视觉摘要。
• K3 官方要求保留完整 thinking history，但这不意味着必须在两个 JSONL 中重复内嵌原始 base64 图片。

5. 关键时间线：哪里做得好，哪里开始漂移#

在本分析时额外执行的只读诊断 bun run check 显示当前树有 2 个错误：

1. V3Home.astro 仍 import 已删除的 V3Intro.astro。
2. 新 engine 的 tl.add(() => this.typeIn(...)) 不符合 GSAP callback 类型。

这不是“K3 最终只会交付坏代码”的证据，因为任务正处于重写中途；它证明的是：

一旦发生取消或方向切换，harness 没有事务化 artifact 状态，也不会自动把旧验证标记为过期。

6. 为什么它会“大量借鉴 V2”#

这不是一个偶然的审美失误，而是一条很清楚的因果链。

6.1 用户约束#

用户说的是“从 0 设计一个新的 landing page 和对应入场动画”。

6.2 harness 系统 prompt 的默认优化目标#

本次冻结的 system prompt 同时强调：

• existing codebase 要先读代码；
• feature 要 minimal intrusion；
• follow existing code style；
• 超过 3 次搜索时优先用 explore Agent；
• “make MINIMAL changes”非常重要。

这些原则对普通工程任务是好事，但对“刻意摆脱现有视觉”的创意任务，会形成反向激励。

6.3 三个 explore Agent 返回的高显著性信息#

两个子 Agent 都把 V2 标成最重要发现：

• “已存在完整沉浸式首页 V2”
• “这是最接近视觉惊艳 landing page 的现有资产”
• “可参考/迭代/取代它”
• “直接对标 /v2”

人物研究 Agent 又返回了摄影光圈、琴弦、现有 intro 等可复用动机。

6.4 根 Agent 自己再次读取 V2#

根 Agent 随后直接读取：

• /v2/index.astro
• ImmersiveHome.astro
• IntroOverlay.astro
• 现有 focus/intro 技术

于是模型上下文里“从零”的一句用户约束，面对的是数万 token 的 V2 结构、组件和设计语言。

6.5 Plan 把这种锚定合法化#

计划虽然写着“视觉与代码全部重写”，却又明确说：

• 沿用 V2 的薄路由、chrome=false、locale prop；
• 沿用 focus.ts 的 FLIP；
• 沿用 IntroOverlay 局部 token；
• 沿用 ImmersiveHome 的 custom element + gsap.context()；
• 章节仍是 hero → 数字 → work → writing → outro。

管道复用本身没有问题，问题是它没有把“允许复用的层”和“禁止复用的层”写成可执行的不变量。

6.6 视觉验收没有包含“与 V2 的结构距离”#

后续截图循环验证的是：

• 动画有没有显示；
• CSS 是否生效；
• 页面是否好看；
• 滚动有没有工作。

但没有验证：

• DOM/叙事顺序是否仍与 V2 同构；
• hero 是否仍是左大字 + 右头像；
• nav、章节、深色编辑视觉是否仍是 V2 家族；
• 一位不了解实现的用户能否一眼分辨它不是 V2 迭代。

所以这个失败的第一责任仍然是模型没有守住明确用户约束；harness 的责任是没有需求不变量与创意新颖度验收接口。

7. K3 模型：值得学习的能力#

7.1 很强的长程任务耐力#

它在 190K 左右上下文、80 多个根步骤、两个多小时墙钟时间后，仍能记住：

• 双语路由；
• 原始设计目标；
• 已做过的构建；
• dev server 与缓存问题；
• 用户对 V2 的批评；
• 新设计方向。

这和 K3 官方定位的 1M 上下文、long-horizon coding 是一致的。模型规格 ↗

7.2 调研拆分质量高#

它没有直接写页面，而是把调研拆成：

1. 人物与内容；
2. 首页、路由、i18n；
3. 设计系统和动画技术栈。

三个 prompt 都给了清楚的调查范围、返回格式和 thoroughness。这是可以直接学习的 Agent 调研模式。

7.3 视觉在环，而不是“能 build 就算完”#

它实际读取了 18 张截图，并做了多轮：

写代码 → 启动页面 → 截图 → 视觉判断 → computed style 探针 → 修改 → 重启缓存 → 再截图

尤其是 SVG blueprint 不显示时，它没有一直盲改 CSS，而是逐步验证：

• 源文件是否有规则；
• Vite 输出是否含新旧 style block；
• 动态创建的 SVG 元素拿到什么 computed style；
• 浏览器当前 session 是否指向正确页面；
• stale compiled CSS 是否仍在服务。

这种“每次提出一个可证伪假设”的调试方式很值得学习。K3 官方也特别强调它在前端、游戏、CAD 中把截图纳入迭代闭环。K3 Coding 与 vision-in-the-loop ↗

7.4 被纠偏后的自我诊断很准确#

用户指出 V2 借鉴后，它没有泛泛道歉，而是准确列出：

• 固定玻璃 nav；
• 左大字 + 右头像 hero；
• 数字 → 作品 → 写作 → 联系；
• 深色编辑感。

并进一步提出正确的抽象边界：

可以复用数据注入、chrome=false、双语 prop；视觉语言必须重做。

这说明 K3 并非看不出问题，而是第一次决策时把“低风险实现”放在了“语义忠实”前面。

7.5 概念发散质量不错#

纠偏后给出的三个方向不是换皮：

• Agent 会话即主页；
• 摄影暗房接触印相；
• 活系统图谱。

其中“Agent 会话即主页”把动效从 6 秒 overlay 提升为整个页面的交互语法，明显比原始“常规 portfolio + 新 intro”更完整。这是 K3 在获得明确反例后表现出的强二次创意能力。

8. K3 模型：本次暴露的缺点#

8.1 显式需求会被“工程稳妥”吞掉#

“从零”是用户最清楚的约束，K3 却把现有 V2 当成最安全的局部最优。

这和官方公开的一个限制高度一致：K3 针对长程困难任务训练后，可能表现得过度主动，在边界或意图不够机器可检验时替用户做决定；官方建议在 system prompt 或 AGENTS.md 中增加更明确的行为约束。K3 官方 Limitations ↗

8.2 计划规格大于真实实现#

原计划的 intro 包含：

• blueprint 与真实 DOM 的 FLIP 交接；
• 头像 blur 显影；
• 光圈叶片 mask；
• 色彩与排版灌注；
• 约 6 秒完整叙事。

原 engine 实际做的是：

• 对若干真实元素读取 getBoundingClientRect()；
• 在 overlay 上画 5 个矩形/圆形轮廓；
• stroke-dashoffset 描边；
• overlay fade out；
• 真实 hero fade in。

没有真正的位置 morph，也没有 intro 中的头像显影或光圈叶片 handoff；安全兜底写成 11 秒而不是计划的 9 秒。

这说明 K3 很会写“令人信服的实现意图”，但仍需要一张 Plan claim → code evidence → visual evidence 对照表。

8.3 过早形成“看起来很好”的判断#

日志中的判断在完整验收矩阵之前就开始变得乐观。到用户纠偏时：

• 只验证了桌面暗色；
• 还没有移动端证据；
• 没有亮色证据；
• 没有 reduced-motion 证据；
• 没有 Lighthouse 证据；
• writing 区也没有形成清楚的视觉验收记录。

这类模型容易把“某个局部已经漂亮”误判成“用户目标已经接近完成”。

8.4 长思考不自动带来需求忠实#

根 Agent 产生近 19 万字符 think，最大单段超过 2.3 万字符；但最核心的“不能沿用 V2 视觉骨架”仍然由用户发现。

这是一个很重要的教训：

reasoning depth 和 acceptance quality 是两个不同维度。

没有外部不变量与验收器，再长的思考也可能只是把错误方向论证得更完整。

8.5 大块代码生成仍然脆弱#

二次重写 engine 时：

• 一次生成留下 8 处嵌套引号语法错误；
• 随后用复杂 sed 批改，又产生 shell quoting error；
• 改用 StrReplace 后仍留下一个 GSAP 类型错误。

K3 可以快速生成大文件，但“大块写入 → 立刻静态检查 → 小步修复”仍然不可省略。

8.6 研究答案的来源纪律一般#

最开始回答 K3 升级时，它：

• 访问 Google/Bing 失败；
• 从 DuckDuckGo 拿到非官方 kimi-k2.org 内容；
• 又读了 Kimi 官方文档；
• 最终把官方与非官方说法混在一起，没有附链接。

回答中还同时说“已开源”和“完整权重计划 7 月 27 日前开源”，表述没有澄清“开放发布”和“完整权重发布”的区别；API 价格只说 $3/$15，漏掉 $0.30 cache-hit input。

这说明它会主动研究，但 harness 没有强制 claim-level provenance。

9. legacy kimi-cli harness：值得学习的深模块#

按“深模块”的标准——接口简单、内部隐藏大量复杂度——最值得学习的是下面五个。

9.1 Wire：事件协议与 UI 解耦#

模型核心只发送类型化事件，UI、文件记录器、Web/ACP 可以各自订阅。事件还带 correlation ID，子 Agent 通过嵌套事件接入同一审计流。

这是非常高杠杆的边界：以后想做回放、统计、可视化、远程 UI，不需要侵入主 agent loop。

9.2 Context：恢复、usage 和 checkpoint 合一#

context.jsonl 同时解决：

• 冻结 system prompt；
• 恢复 LLM 历史；
• 跳过损坏行；
• 记录 token 快照；
• checkpoint/revert；
• compaction 后重建。

它的接口很小，内部责任完整，是一个真正的深模块。

9.3 Background Task：spec/runtime/control/output 分离#

每个后台任务有：

• immutable-ish spec.json
• 运行态 runtime.json
• 控制面 control.json
• 标准输出 output.log
• heartbeat
• terminal notification

这比“保存一个 PID”稳健很多。本次 dev server 的 child PID、PGID、启动时间、heartbeat、timeout 都可以独立检查。

9.4 子 Agent 隔离#

每个子 Agent 有独立 prompt、context、wire 和 output，根 Agent 只接收结果摘要和嵌套事件。这样既能并行，又不会让三个调查方向共享一份混乱上下文。

9.5 Plan/Question/Approval 是正式协议#

Plan approval、路线选择、重设计选择都不是普通文本约定，而是有 request ID、tool call ID 和 future resolution 的结构化请求。

这让“等待用户拍板”成为 runtime 状态，而不是模型凭空猜测用户是否同意。

10. legacy harness：需要改进的地方#

10.1 缺少权威 Task Contract#

Plan 是模型生成的叙事文档，不是 runtime 可执行的约束。

本任务真正需要的是：

goal: 从零设计 V3 landing page 和入场体验
invariants:
  - 视觉结构不能复用 V2
allowed_reuse:
  - 数据获取
  - 双语 props
  - chrome=false 路由模式
  - GSAP 基础设施
forbidden_reuse:
  - V2 的 hero 构图
  - V2 的章节顺序
  - V2 的 nav 视觉
  - V2 的整体深色编辑语言
acceptance:
  - blind reviewer 能一眼判断不是 V2 迭代
  - desktop/light/dark/mobile/reduced-motion 全部有证据

如果这些只存在于自然语言里，模型很容易选择一个“技术上合理、语义上错误”的局部最优。

10.2 Checkpoint 没有覆盖文件副作用#

上下文可以 rewind，工作树不能。

建议增加 artifact transaction：

• 每个 mutation 关联 step_id。
• 写入前记录 baseline tree hash。
• cancellation 后标记 workspace_state=interrupted_dirty。
• 可选地在独立 git worktree、临时 patch 或 copy-on-write overlay 中执行。
• 不要把“context checkpoint”在 UI 上暗示成完整任务快照。

10.3 验证没有绑定代码版本#

原始版本 build 通过后，又发生了 CSS 修改、删除文件和 engine 重写；state 里仍然可以把“build”理解成已做过。

正确设计应是：

validation {
  kind: check | test | build | screenshot
  artifact_revision: sha256(current diff)
  finished_at
  result
}

onMutation(files):
  invalidate every validation whose scope intersects files

只有当前 revision 的全部 mandatory validations 为 green，任务才能进入 completed。

10.4 Todo 是模型控制的展示层，不是执行状态机#

Todo 最好只做 projection：

• 真实状态来自 step、artifact、validation、approval、background task。
• 模型可以提议 Todo，但不能单方面宣布完成。
• UI 根据事实生成“已完成/失效/阻塞/待验证”。

10.5 重大方向变化不会自动使 Plan 失效#

用户已经选择“Agent 会话即主页”，但 plan 文件仍然是原始“自我生成页面 + 常规章节”的方案。

建议：

• requirement 或 architecture 发生重大变化时，自动标记 plan_status=stale。
• 需要更新 plan diff，至少让用户知道哪些已推翻、哪些继续有效。
• 新 plan 获批前，不进入大范围破坏性重写。

10.6 Shell 权限边界太粗#

Shell 只审批“run command”，但命令内部可以同时：

• format 全仓；
• 删除文件；
• git checkout -- .；
• 清缓存；
• 启动后台进程。

本次 bun run format 修改了 99 个 tracked 文件，随后才用 git checkout -- . 恢复。虽然初始 worktree 干净，所以没有丢用户改动，但这是危险模式。

建议 Shell 增加：

• 命令 AST/risk classifier；
• destructive git 和递归删除单独审批；
• 执行前 worktree snapshot；
• formatter scope guard；
• yolo 也只跳过低风险审批，不跳过破坏性审批；
• 禁止用复杂 shell quoting 做本可由结构化文件编辑工具完成的修改。

10.7 网络恢复是“可续”，还不是“自动完成”#

00:13 的 timeout 流程是：

1. provider recovery；
2. retry once；
3. 再次 timeout；
4. 标记 recovery exhausted；
5. StepInterrupted；
6. 用户约 4 分 42 秒后输入 continue。

优点是上下文没有丢，恢复非常顺滑。缺点是配置写着 max_retries_per_step=3，连接恢复分支却在一次恢复失败后把异常标为 exhausted，通用 retry budget 不再继续。

更好的策略应区分：

• client connection refresh；
• same request retry；
• provider failover；
• turn-level resume；
• 幂等工具是否可以安全重放。

10.8 原始媒体和工具结果重复持久化#

18 张截图使 context 的 84% 成为图片 data URL，又在 wire 中重复一份。

建议引入：

• blob store；
• hash reference；
• thumbnail；
• OCR/视觉摘要；
• retention policy；
• 对“模型必须保留的 thinking history”和“可外置的工具工件”分别管理。

10.9 本地日志权限偏宽#

本次 context.jsonl、wire.jsonl、kimi.log、config.toml 都是 0644。这些文件可能包含：

• 用户完整输入；
• 源码与 shell 输出；
• 图片；
• 本地路径；
• 偶然打印出的凭证。

即使 API key 在当前 log 中被 SecretStr 屏蔽，仍建议 session、log、config 默认使用 0600，目录使用 0700。

11. 模型、harness、环境：责任边界#

12. 你最值得沉淀的 Agent Harness 原则#

原则 1：先建立任务契约，再允许模型写计划#

Task Contract 是用户约束；Plan 是模型提出的做法。前者不可被后者悄悄覆盖。

原则 2：把“允许复用”和“禁止复用”分层#

尤其是设计任务：

• 可复用：数据、路由、i18n、组件基础设施。
• 不可复用：信息架构、视觉语法、构图、动效叙事。

原则 3：任何 mutation 都让旧验证失效#

测试结果必须绑定 artifact revision，而不是绑定 session。

原则 4：取消是正常状态，不是异常边角#

Agent runtime 要有一等状态：

• interrupted_clean
• interrupted_dirty
• resumable
• requires_replan

原则 5：Todo 只能是事实投影#

模型可以规划，但完成度来自真实工具、文件和验证事件。

原则 6：视觉任务要有“设计距离”验收#

除了“能运行、好看”，还要检查：

• 是否满足原创性约束；
• 与参考版本的结构相似度；
• 用户第一眼是否感知到要求的差异；
• 多视口和可访问性矩阵。

原则 7：保留 reasoning history，不等于把所有工件塞进上下文#

K3 官方明确提醒 thinking history 不完整会导致质量不稳定。正确做法是保留模型推理链的协议兼容性，同时把图片、完整命令输出和大文件放进可寻址工件层。K3 官方兼容性限制 ↗

原则 8：结束条件必须由 harness 判定#

建议最终门禁：

finish allowed only when:
  current_artifact_revision == validated_revision
  required checks/tests/build are green
  required visual matrix has evidence
  no unresolved approval/question
  no unexpected background task
  plan is current or explicitly superseded
  todos reconcile with runtime facts
  git diff contains only intended scope
  known gaps are disclosed

13. 一份可直接复用的任务模板#

# Task Contract

## User outcome
用户最终希望感知到什么，而不只是要创建哪些文件？

## Non-negotiable invariants
- ...

## Allowed reuse
- ...

## Forbidden reuse
- ...

## Decision ownership
- Agent 可以自主决定：
- 必须询问用户：

## Artifact scope
- 允许修改：
- 不允许修改：

## Acceptance matrix
| 维度 | 场景 | 证据 |
|---|---|---|
| correctness | check/test/build | command result |
| visual | desktop dark/light | screenshot |
| responsive | mobile | screenshot |
| accessibility | reduced motion/keyboard | trace |
| novelty | against V2 | blind review + structure check |

## Completion gate
- 所有验证必须针对当前 artifact revision。
- 任意后续 mutation 自动使相关验证过期。
- background task 必须结束或显式交接。

14. 下一次如何公平评测 K3#

建议不要继续用这一次运行给 K3 打总分，而是做一个受控对照实验。

实验设置#

1. 使用新版 Node Kimi Code 0.28.0，不要继续把 legacy 1.49.0 当成新版。
2. 新开 session，显式记录 reasoning_effort；若想对齐官方最佳表现，用 max。
3. 在干净的独立 worktree 中运行。
4. 固定同一份 Task Contract 和 acceptance matrix。
5. 至少运行 3 次，避免一次随机轨迹决定结论。

两个 K3 组#

• A：强隔离原创组
  • 明确禁止读取 V2 视觉实现。
  • 只允许读取数据、品牌内容和 DESIGN tokens。
• B：可读但分层复用组
  • 允许阅读 V2。
  • 明确只可复用数据和技术管道，禁止结构与视觉复用。

这两个组可以测出：K3 的问题究竟主要是“看到参考就锚定”，还是“即使有明确边界仍无法守住”。

记录指标#

只有把同一模型放到 legacy/new harness 或把不同模型放到同一 harness，才能更可靠地区分模型能力和 runtime 能力。

15. 最终判断#

K3 值得你学的#

• 大任务先并行探索再综合；
• 在视觉任务中强制 screenshot/computed-style 闭环；
• 用可证伪假设推进调试；
• 被纠偏后精确识别错误抽象层；
• 在大上下文中维持长程任务线索；
• 把个人内容、技术身份和交互概念连接成有叙事的设计。

K3 不值得你照搬的#

• 用超长思考替代验收标准；
• 为了稳妥默认锚定现有实现；
• 把宏大 Plan 当作已经实现；
• 大块写文件后再一次性检查；
• 过度主动运行全仓工具；
• 用“我看起来觉得不错”代替用户约束验证。

legacy kimi-cli harness 值得你学的#

• 类型化 append-only wire；
• context 与 UI event 分离；
• tool/subagent correlation ID；
• 子 Agent 独立上下文；
• 后台任务的 spec/runtime/control/output/notification；
• checkpoint、usage、恢复与损坏行容错；
• 结构化 Plan/Question/Approval。

legacy harness 最需要补的#

• 权威 Task Contract；
• artifact transaction；
• revision-bound validation ledger；
• 计划失效机制；
• worktree-aware Shell 安全边界；
• 媒体 blob store；
• 由事实驱动的 Todo；
• completion gate；
• 更严格的日志权限和来源追踪。

一句话总结：

K3 展示了一个“很能干、很能持续、也很会看”的 Agent 模型；这次失败展示的则是，没有任务不变量、事务化工件和版本化验收，再强的模型也可能用两个小时把一个错误方向做得越来越完整。

附录 A：快照完整性#

快照后，本分析只执行了只读检查与日志解析，没有修改博客源文件。bun run check 会刷新 Astro/Vite 的派生缓存，但没有修改 tracked source。

附录 B：官方资料#

• Kimi K3 官方技术博客 ↗
• Kimi Code 模型配置 ↗
• Kimi Code 产品概览 ↗
• 从 Python kimi-cli 迁移到 Node Kimi Code CLI ↗