Kimi K3 上生产：先修 agent 环，再谈模型
K3 上线首先是 harness：写权限、1M 上下文喂什么、合并前门禁——不是再写一篇 benchmark 通稿。
Agent 跑绿了，直到有人看见 diff 里动了 migrations/。不是 K3「失控」——我们把写范围放在仓库根、往上下文里塞了 90 万 token 日志 指望模型自己悟。模型很听话：在错的层里改得理直气壮。
Kimi K3 发布解读 讲规格；这篇讲 K3 外面的环：Moonshot API 或 Kimi Code、1M 怎么喂、合并前怎么拦。DevCove 2026-07-25 快照：K3 #7、指数 57、表内首块约 161s——按 批处理 / agent 规划，别默认当秒回 IDE chat（除非你们的壳子把延迟藏好了）。
白板上怎么画 harness
┌──────────────────────────────────────────────┐
│ 人：范围 + 验收测试 │
├────────────────────┬─────────────────────────┤
│ 上下文（ curated） │ 工具面（shell/MCP/网） │
├────────────────────┴─────────────────────────┤
│ K3（API 里推理档写清楚） │
├──────────────────────────────────────────────┤
│ CI + 人审 diff（硬要求） │
└──────────────────────────────────────────────┘
环弱，换哪个 frontier 都像烂模型。先修框，再换名。
| 层 | 烂默认 | 更好默认 |
|---|---|---|
| 范围 | 「修一下服务」 | 写清包名 + 允许改 的路径 |
| 上下文 | 整库粘贴 | 规格切片 + 失败测试 + 一篇 ADR |
| 工具 | shell 全开 | 白名单；破坏性命令要人点 |
| 输出 | 一次改一堆文件 | 分步小 patch |
1M 是预算，不是垃圾场
1.05M 窗口容易诱发「全上传」。MoE 再大也不替你做策展。
| 值得喂 | 别喂 |
|---|---|
| 用户故事 + 非目标 | 整包 node_modules / 生成 SDK |
| 一张架构锚点 | 五十篇没排序的 README |
| 最新一段 CI 失败 | 全量历史日志 |
| 一个 golden test | 整套测试贴进 prompt |
我们给 拼上下文 设 15 分钟上限。若策展比修 bug 还久，这 ticket 就不该交给 agent。
Kimi Code 还是 HTTP API
| 路径 | 什么时候选 |
|---|---|
| Kimi Code | 要 Moonshot 终端 agent 默认体验 |
HTTP API（kimi-k3） | 嵌进自建编排 |
| 第三方 IDE | 仅官方支持时——查清数据 residency |
安全审的是 权限，不是榜分。K3 benchmark 高不会自动批准生产库写权限。
验收环（不能省）
工单
→ 收束工具的 agent（K3）
→ 单测 + 集成测
→ lint / 类型
→ 人读 diff（不看摘要糊弄）
→ 发布分支跑 ship checklist
K3 有时比旧默认 patch 更宽。更宽就要 更宽 的 review，不是更快合并。
我们仍选 Opus 的情况
Claude Code 已合规时，同快照 Opus 5 high 往往交互更顺——见 K3 vs Opus 5。Moonshot 合同在、1M 任务成本要紧、或 Kimi Code 贴 ops 时，才优先试 K3。
运维规矩： GitHub 限流别用 partial 快照覆盖；agent 重试也一样——别因为「通常能过」就关门禁。
链接： 排名 · 方法论 · Ship checklist
证据日期： 2026-07-25；上线前核对 Moonshot API 文档。