Agent 工程与评测实验室

外观

Kimi Code 案例

本页速览 剖析月之暗面自研 coding agent Kimi Code 的 harness 设计——普通对话 / Plan / Goal / Swarm 四级自主性阶梯加实验性 Tower 模式，「始终询问 / 必要时询问 / 完全自动」三档权限，内置终端与可操作浏览器的验证闭环，以及它作为「国内模型厂自研 coding harness」样本的独特位置。

本页含时效性内容，数据截止于 2026-10；JD、价格、产品功能等信息可能已变化，引用前请核对原始出处。

Kimi Code 案例 ​

Kimi Code 是月之暗面（Moonshot AI）的自研 coding agent：CLI 先行，2026 年 7 月 16 日旗舰模型 Kimi K3 发布当天即可在 Kimi Code 中使用（据发布报道），K3 的完整权重随后于 7 月 27 日按修改版 MIT 许可开放（据掘金报道）；桌面版 Kimi Code Desktop 于 2026 年 9 月发布——官方变更记录把 1.0.0 标在 2026-09-17（官方 changelog），官方发布稿与媒体报道集中在 9 月 21 日。

从产品形态看，它是"CLI + 桌面工作台"的双壳结构，直接对标 Claude Code 与 Cursor 的中间地带。但从 harness 研究视角看，Kimi Code 最值得解剖的不是"又一个国产 coding agent"，而是它把一个通常藏在设置页里的问题——该给 agent 多大自主权——提升成了产品的一等公民：四种工作模式构成一条自主性阶梯，三档权限模式构成一条风险闸门，两个维度正交组合。这是"自主性分级设计"在国内头部产品里最完整的一次显性化。

为什么这个案例重要

权限与人机协作一章的核心命题是："agent 的能力上限由自主性决定，但信任度由权限系统决定。"多数产品把这句话实现为一个审批弹窗；Kimi Code 把它实现成了两套正交的分级体系——模式决定"agent 给自己多大任务"，权限决定"agent 动手前要不要问你"。拆开这两轴，是理解它全部设计的钥匙。

自主性阶梯：从对话到 Tower ​

Kimi Code 把工作模式做成四个显式档位（外加一个实验档），每一档对应一种任务形态与放权程度。以下定义据官方发布稿与官方 changelog：

模式定位自主性人在回路的位置
普通对话边界清楚的小任务单轮委托每轮对话即确认
Plan影响面较大、需要先确认方案的任务先分析出执行计划，不动手计划经人审阅、反馈、确认后才执行
Goal需要多轮推进的长任务围绕明确目标持续执行并自检可暂停、恢复、取消、转后台
Swarm可并行推进的复杂工程主 Agent 拆任务，调度 Subagent 分工，汇总结果审阅汇总结果
Tower（实验性）规模较大、可拆分的工程多个 Agent 围绕同一目标并行推进事后验收

这条阶梯的设计语言值得逐档读：

Plan 是"先审方案再放权"。 它对应的正是权限与安全里"动手之前的计划审批"这一闸口——但 Kimi Code 把它从"某个操作前的弹窗"升格为一种持久的工作模式：整个执行阶段都建立在一份经过人确认的计划工件上。这与 规划与任务分解中"外化状态"的主张一致——计划一旦成为工件，跑偏就有了对照系。

Goal 是长时程任务的最小封装。 "围绕目标持续执行和检查"+"可暂停、恢复、取消"意味着 harness 内部有显式的目标状态与检查点，而不只是把对话一直续下去。对照 frontier 里长时程研究的处方（停止与预算控制、状态外化、关键节点回写），Goal 模式是这些工程教训的产品化形态。

Swarm 与 Tower 的区别是编排结构，不是数量。 Swarm 是 orchestrator-worker：主 Agent 拥有分解与汇总的权力，Subagent 是被调度的执行单元——这是 子代理一章论证过的工程默认值。Tower 则撤掉了这个中心：多个 Agent 围绕同一目标并行，没有明显的总指挥。官方给它贴上"实验性"标签是诚实的——多智能体研究（frontier：Anthropic 的 15 倍 token 成本、MAST 的失败模式分类学）早已指出，去掉单点编排换来的并行探索，代价是协调与验证成本陡增。把两种结构同时摆上架、让用户按任务可分解性自选，比"all in 多 agent"的宣传姿态清醒得多。

一条被显性化的设计原则

四个模式回答的是同一个问题："这一步，agent 可以自主决定多大的一件事？" 普通对话是"这个回答"，Plan 是"这份方案"，Goal 是"这个目标"，Swarm/Tower 是"这个工程"。把自主性做成阶梯而不是开关，意味着厂商承认"全自主 vs 全人工"之间最有价值的区域在中间——且中间区域需要分层，不能只有一档。

权限三档：与模式正交的风险闸门 ​

模式轴之外，Kimi Code 还有一条独立的权限轴：始终询问 / 必要时询问 / 完全自动三档，敏感操作弹出审批卡片确认（官方 changelog、官方帮助中心）。CLI 里对应 /ask-when-needed、/never-ask 等切换命令（官方速查表）。

据第三方对 CLI 版本的拆解（GitCode 博客），三档的语义大致是：

  • 始终询问（默认）：只读操作自动放行，写文件、执行命令等逐一确认——全程掌控型；
  • 必要时询问：普通工具调用自动批准，但敏感操作仍会询问——访问 .env、SSH 私钥等敏感文件，或执行 shutdown、rm -rf 这类危险命令；
  • 完全自动：全部自动执行，适合可控环境与批量任务。

两轴正交组合的乘积才是真实的安全态势：Goal + 完全自动意味着"agent 围绕目标长跑且全程不请示"，只适合沙箱化的环境；Swarm + 始终询问则可能因为子任务数量爆炸而把审批弹窗变成新的瓶颈。模式决定效率上限，权限决定风险下限——这与 Claude Code 的权限设计（四种权限模式 + allow/ask/deny 规则，见权限与安全）是同一问题的两种产品化答案：Claude Code 把粒度做细（规则、hooks），Kimi Code 把档位做显（三档 + 审批卡片）。

一段诚实的版本史：危险命令护栏的反复

据第三方媒体 Cocoloop 对 CLI 变更记录的追踪，2026 年 9 月初 CLI 在两天内连着改了权限逻辑：v0.40.0 给危险命令（shutdown、rm -rf 等）加了内置护栏——完全自动模式下直接拒绝，其他模式执行前必须确认；两天后的 v0.41.0 又把拦截撤了，"危险命令不再拦截"，文档没有解释原因。这个反复本身就是 harness 工程的真实处境：安全护栏与可用性之间存在真实张力，"完全自动"到底包不包括能毁掉系统的命令，没有教科书答案，厂商只能在用户反馈里校准。（此节为第三方报道，官方未公开说明变更理由。）

环境集成：把验证闭环搬进窗口 ​

Desktop 版的结构（据官方发布稿，以下功能描述均逐字核对于该页）是"一个窗口装下整个交付环"：

text
┌─────────────────────── Kimi Code Desktop ───────────────────────┐
│  会话区（工具调用、思考过程、每轮修改的文件全程可见）              │
│    · 文件路径一点即开，支持预览                                    │
│    · 截图标注：框选屏幕区域 + 评论，直接发给 Agent                  │
│  右侧面板：按文件/按轮次审阅 diff，可预览 Markdown/HTML 等         │
│  内置终端：直接跑构建、测试、格式检查，看 Git 命令输出               │
│  内置浏览器：Agent 可直接操作浏览器做页面交互与效果验证；            │
│    用户可标注网页元素，自动捕获元素信息 + 截图 + 评论                │
│  Git 状态区：当前分支、领先/落后、文件变化、关联 PR 状态             │
└─────────────────────────────────────────────────────────────────┘

从 harness 视角，这里有两个值得点名的设计。

第一，内置浏览器不是功能堆砌，而是验证环节的闭环。 "Agent 可以直接操作浏览器，完成页面交互和效果验证"——前端任务里"改完 → 起服务 → 截图 → 比对"这条验证链，在终端系 agent 里要靠模型自己拼 Playwright 之类的工具调用来搭建；Kimi Code 把它变成了环境自带能力。这正是 Cursor 案例里"厚 harness"论证的延伸：环境已经在免费生产的信号和动作，做成内置能力就比让模型现搭便宜。把前沿进展里 Anthropic "evaluator 用 Playwright 实际操作运行中的应用来验收"的研究生成—评估结构，与这里的"agent 自己操作浏览器验收"对照看，是同一条思路的产品端落地。

第二，人在回路的输入方式被拓宽了。 截图标注、网页元素标注（自动附带元素信息、截图和评论）把"指哪改哪"做成了一等交互——人给 agent 的反馈不再局限于自然语言描述"左上角那个按钮"，而是直接指给模型看。这本质上是在给上下文工程加一条高带宽、低歧义的输入通道。

另有两个影响 harness 定位的产品决策：Desktop 与 CLI 共享任务（"本地的 CLI 任务会直接出现在桌面端"），说明agent 核心与交互壳是分离的；设置面板中可管理"默认模型、模型供应商"——官方支持配置第三方模型供应商（官方发布稿），即 harness 不锁死自家模型。后者在"模型厂自研 harness"的坐标系里是个耐人寻味的开放姿态。

样本意义：模型厂自研 harness 的中国答卷 ​

把 Kimi Code 放进 frontier 的"工业界军备竞赛"图景里，它补上了此前案例集中空缺的一格：国内头部模型厂自研 coding harness 的完整样本。此前站内的垂直整合案例（Claude Code、Cursor）都来自美国厂商，开源可组合路线的对照（DeepSeek Harness）虽然同样出自中国团队，但押的是生态而非产品体验。Kimi Code 证明的是另一件事：模型厂自研 harness 的路线——模型与 harness 协同迭代、围绕自家模型的行为特点打磨工具与提示词——在国内同样成立，且因为 K3 权重开源，这条路线还多了一层"开放权重 + 自有 harness"的组合形态。

值得记住的一个结构性事实：Kimi Code 的模式与权限设计，与模型能力存在联动——自主性阶梯敢开到 Swarm/Tower 这一档，前提是模型在长程规划与多步工具调用上撑得住。月之暗面把 K3 的 agentic 能力作为发布重点（据艾瑞网报道，K3 在 Agentic 类别平均得分 91.2；第三方基准数据，仅供参考），同时把自主性分级做成产品骨架——harness 的放权刻度，是跟着模型能力表走的。这反过来也提示了一个风险：切换第三方模型供应商时，同一档自主性背后的实际可靠性可能已经变了。

一个可核对的注脚

本文的分析在一个 Kimi Code CLI 会话中完成——也就是说，写作环境本身就是分析对象。可以作证的两点：CLI 环境确实向 agent 暴露了 Plan 模式与权限模式的配置面（与官方文档描述一致）；harness 的"自主性分级"不是营销话术，而是 agent 在运行时能感知到的真实系统状态。第三方口吻保持完毕，以下继续。

边界与取舍 ​

  • 自主性阶梯的信任校准是用户的功课。 四档模式 + 三档权限给出的是自由度，不是安全保障。"Goal + 完全自动"在非沙箱环境跑长任务，风险敞口与任何同类产品无异——官方帮助中心自己也警告"不要在敏感目录中启动"（官方帮助中心）。
  • Swarm/Tower 的账单尚未公开。 多 agent 模式的 token 放大系数、子任务间的验证机制，官方均未披露细节；Tower 挂着"实验性"标签，意味着编排结构仍在探索期。
  • 模型基准仍有差距要正视。 据第三方报道，K3 在部分编程基准上仍低于顶尖闭源模型（如 DeepSWE 上 67.5 对 GPT-5.6 Sol 的 73.0，艾瑞网，第三方数据）。harness 的放权刻度走得再细，单步可靠性的地基还是模型。
  • Desktop 的历史很短。 1.0 发布于 2026 年 9 月中旬，长任务稳定性、大仓库表现都缺乏公开的长周期数据。本页描述的是设计，不是耐久性结论。

从 Kimi Code 学到的 ​

  1. 把自主性做成阶梯，而不是开关。 Plan → Goal → Swarm → Tower 的梯度让"放权"有了中间态；每升一档，任务工件（计划、目标、子任务）就厚一层，人的审阅点就从操作级移到方案级。
  2. 模式与权限是两轴，不要混为一谈。 模式管"agent 揽多大的事"，权限管"动手前问不问人"。两轴正交，才能表达"大胆拆任务、小心执行"这类真实诉求。
  3. 验证能力内置，比让模型自己搭便宜。 内置浏览器 + 截图标注把"改完自己验收"从 prompt 工程变成了环境能力——环境能给的动作，就不要让模型用工具调用现拼。
  4. harness 的放权刻度要跟着模型能力表走，并且要敢标"实验性"。 Tower 的标签是一种诚实：编排结构的成熟度配不上宣传时，如实标注比硬上更能积累信任。

延伸阅读 ​

参考资料 ​