OpenClaw中的Kimi K3与dsh对比：完成5个任务，但速度慢了9倍，成本则高出48倍

我让我的 OpenClaw 工作代理去处理 Kimi K3——这是 Moonshot 旗下的旗舰级推理模型。我让它执行了与八月份测试 DeepSeek Harness (dsh) 时相同的五项小型编程任务。Kimi K3 全部顺利完成了这些任务。当天，我又用 dsh 对 DeepSeek V4-Flash 进行了两次测试。与第二次测试（缓存已预热）相比，Kimi K3 的执行时间要长约 9倍（309.9秒对比35.7秒），成本也高出约 48倍（0.531美元对比0.011美元）。至于第一次冷启动测试（耗时44.8秒、成本0.024美元），两者在时间和成本上的差距分别约为7倍与22倍。

随后，我给 Kimi K3 下达了 dsh 之前用来生成小工具的像素艺术标志设计任务。它一共尝试了三次才成功：第一次什么都没生成；第二次虽然写出了完整的小工具代码，却将其保存到了错误的文件夹中，且因超时被中断，起初我并未察觉；第三次则是在我缩短了任务描述并要求它跳过规划步骤后才顺利完成的。下面展示的就是第三次尝试所生成的小工具；其中第二步中的配置陷阱尤其值得借鉴。

设置说明：我在什么环境下运行的

以下是我在 2026年9月11日于自己的设备上执行的命令及其实际输出结果：

$ node -v
v24.18.0
$ openclaw --version
OpenClaw 2026.9.2 (3928bad)
$ dsh --version
0.1.1-rc.2
$ openclaw plugins list --json | jq -c '.plugins[] | select(.id=="moonshot") | {id, enabled, version}'
{"id":"moonshot","enabled":true,"version":"2026.9.2"}
$ openclaw config get models.providers.moonshot.models.0.compat
{
  "supportsReasoningEffort": true,
  "supportsTemperature": false,
  "supportedReasoningEfforts": [
    "low",
    "high",
    "max"
  ]
}
$ openclaw config get models.providers.moonshot.models.0.contextTokens
262144

在运行任何命令之前，有两点需要注意：

• K3始终会进行推理。 该插件默认发送 reasoning_effort: "max" 参数，同时也接受 low、high 以及 max 这些值；我运行基准测试时使用了 --thinking max 参数。此外，该插件还会忽略所有采样相关设置（如 temperature、top_p 等），因为 K3 会自行固定这些参数；我的模型配置项中也有 supportsTemperature: false 这样的说明。即便是要求“回复内容必须为：PONG.”这样的简单指令，也需要消耗53个推理标记，因此请预留相应的预算。
• 虽然宣传中称其支持1百万上下文长度，但我设置了上限。 OpenClaw的Moonshot目录中显示K3可处理1,048,576个标记的上下文内容。不过我在模型配置里将 contextTokens: 262144 设为262144，这样各会话的上下文长度就能与其他模型保持一致。实际上，在设置了此上限后，可用的上下文长度约为256k而非1百万。若提高该数值，缓存读取成本及每轮交互的延迟也会随之上升。

操作流程：从基础到进阶

步骤1至3可帮助你搭建起一个可运行的模型；步骤4与5则是我后续所执行的操作。

步骤1：安装插件并设置密钥

这些步骤均来自 OpenClaw 官方的 Moonshot 文档。在我的服务器上，插件与密钥早已配置完毕，因此我只执行了最后一行命令进行检查（其输出结果见上方的设置说明块）。

openclaw plugins install @openclaw/moonshot-provider
openclaw gateway restart
openclaw plugins list --json | jq -c '.plugins[] | select(.id=="moonshot") | {id, enabled, version}'

该插件会从 MOONSHOT_API_KEY 这个环境变量中读取密钥。我将此变量保存在网关服务所加载的环境配置文件中，而我的 openclaw.json 文件中并未包含任何密钥信息。如果希望有人引导你完成设置，文档还提供了 openclaw onboard --auth-choice moonshot-api-key 这一命令。默认的 API 端点为 https://api.moonshot.ai/v1；中国地区则使用 https://api.moonshot.cn/v1（对应的认证选项为 moonshot-api-key-cn）。

该插件支持的模型包括 K3、K2.7 Code 以及 K2.7 Code HighSpeed。它能自动处理 Kimi 模型的特殊要求：对于 K2.7 模型而言，请求参数中必须省略 thinking 与 reasoning_effort 这两个字段，而插件会替你完成这一操作。请注意环境变量的名称：MOONSHOT_API_KEY 对应的是 Moonshot 开放平台；KIMI_API_KEY 则属于 Kimi Code 订阅服务专用的密钥（该服务路径为 kimi/kimi-for-coding）。

步骤2：将工作代理指向K3

在基准测试期间，我的 openclaw.json 文件中的相关内容如下；此时我将工作代理的名称改为了 worker：

{
  agents: {
    entries: {
      worker: {
        model: {
          primary: "moonshot/kimi-k3",
          fallbacks: ["deepseek/deepseek-v4-flash", "deepseek/deepseek-v4-pro"],
        },
      },
    },
  },
  models: {
    providers: {
      moonshot: {
        baseUrl: "https://api.moonshot.ai/v1",
        api: "openai-completions",
        timeoutSeconds: 1200,
        models: [
          {
            id: "kimi-k3",
            name: "Kimi K3",
            reasoning: true,
            input: ["text", "image"],
            cost: { input: 3, output: 15, cacheRead: 0.3, cacheWrite: 0 },
            contextWindow: 1048576,
            maxTokens: 131072,
            contextTokens: 262144,
            compat: {
              supportsTemperature: false,
              supportsReasoningEffort: true,
              supportedReasoningEfforts: ["low", "high", "max"],
            },
          },
        ],
      },
    },
  },
}

有一个陷阱差点导致出现回归问题：在 OpenClaw 2026.9.2 版本中，模型条目里的 compat 块会直接 替换 插件自带的 compat 对象，而不会进行合并。我之前使用的配置仅包含了 supportsTemperature: false 这一项，结果导致插件对推理耗算力的支持功能被悄悄禁用了。因此，如果你确实需要设置 compat，请务必像上面那样完整地编写整个对象。

步骤3：冒烟测试及其生成的JSON数据

每个基准测试任务都是通过类似这样的调用来执行的，且每次都会使用全新的会话密钥：

openclaw agent --agent <your-agent-id> --model moonshot/kimi-k3 --thinking max \
  --session-key "<fresh-key>" --message-file prompt.txt --json > out.json

以下是从PONG任务的记录中提取出的重要字段：

$ jq '.result | {harness: .meta.agentMeta.agentHarnessId, model: .meta.executionTrace.winnerModel, usage: .meta.agentMeta.usage}' out.json
{
  "harness": "openclaw",
  "model": "kimi-k3",
  "usage": {
    "input": 15068,
    "output": 70,
    "reasoningTokens": 53,
    "total": 15138,
    "cost": {
      "total": 0.046254
    }
  }
}

harness: "openclaw" 表示该轮次是在OpenClaw自身的运行环境中执行的；而如果该轮次是通过Codex应用服务器来执行的，则会显示为 "codex"。winnerModel: "kimi-k3" 则说明该轮次确实是在K3模型上运行的，而并未回退到成本更低的模型。reasoningTokens 的数值包含在 output 中（总量为输入与输出之和），因此这53个推理标记也是70这个总数的一部分。

基准测试：相同的5项任务

这些就是dsh文章中所测试的五个任务。每个任务都在全新的临时文件夹中执行，且Kimi每次任务都会开启新的会话。同一天，我也在V4-Flash模型上重新运行了dsh，并在相关设置文件中指定使用deepseek-v4-flash模型。首次运行时，由于缓存尚未预热，耗时44.8秒且花费0.024美元；下表所列的是第二次运行的结果，此时缓存已处于“热状态”，这也是我测试过的速度最快、成本最低的dsh运行结果——除非另有说明，本文中所有对比数据均以此为准。各模型的提示词内容并不完全相同：dsh会在启动它的文件夹中运行，因此其提示词中提到了“当前目录”；Kimi的提示词则给出了每个任务文件夹的绝对路径；此外Kimi还额外添加了修复Bug的提示：“若未安装pytest，请先通过‘pip install --user pytest’进行安装”（实际上pytest早已安装完毕，Kimi也并未执行该安装命令）。V4-Pro与Gemma-4-26B的相关数据则取自8月份发布的dsh文章，并未重新测试。表中的“耗时”指的是整个任务流程所需的时间。Kimi所用的令牌数量及成本数据源自OpenClaw返回的JSON信息，dsh的数据则来自其自身的运行日志。

任务	Kimi K3	dsh V4-Flash（同日测试）	dsh V4-Pro（8月历史数据）	Gemma-4-26B（8月历史数据）
回复“PONG”（启动后执行一次调用）	✅ 6.1秒 · 0个工具	✅ 1.7秒 · 0个工具	✅ 2.8秒	✅ 13.2秒*
编写并运行FizzBuzz程序	✅ 22.8秒 · 2个工具（写入、执行）	✅ 5.3秒 · 3个工具	✅ 8.4秒 · 2个工具	✅ 4.9秒 · 2个工具
修复两个Bug以使单元测试通过（测试代码未作改动）	✅ 86.6秒 · 6个工具（执行、写入、编辑）	✅ 11.3秒 · 7个工具	✅ 15.8秒 · 7个工具	✅ 10.4秒 · 8个工具
用150字以内总结一个由6个模块构成的代码库	✅ 65.5秒 · 10个工具（读取、执行、写入）	✅ 5.1秒 · 7个工具	✅ 10.9秒 · 7个工具	✅ 12.1秒 · 7个工具
在3个文件及对应测试中重命名某个函数并确保测试通过	✅ 128.9秒 · 9个工具（执行、写入；仅用一次sed命令即可完成所有文件修改）	✅ 12.3秒 · 11个工具	✅ 18.2秒 · 12个工具	✅ 12.2秒 · 11个工具
总耗时	309.9秒	35.7秒	56.1秒	52.8秒
令牌数量：输入未缓存/从缓存读取/输出（推理用）	91,470 / 355,328 / 9,990（4,053）	6,141 / 147,328 / 4,697（1,984）	41.4k / 107k / 3.2k	40.5k / 237k / 5.6k
成本	约0.531美元（每百万令牌的价格分别为3美元、15美元与0.30美元）	约0.011美元（每百万令牌的价格分别为0.44美元、1.32美元与0.014美元）	约0.072美元	仅产生电费支出

工具调用次数即对应任务中实际使用的工具数量。Kimi的数据取自OpenClaw返回的JSON信息中的toolSummary.calls字段，括号内为所用工具类型；dsh的数据则来自其运行日志。*该数值为模型在冷启动状态下的首次运行结果。Kimi的计费标准依据我在OpenClaw平台上填写的参数设定，该平台亦以此计算各任务成本；当前实际费率可查阅Moonshot定价页面。V4-Flash模型的计费标准沿用了dsh文章中的峰值费率（参见DeepSeek定价说明）；V4-Pro与Gemma-4-26B的相关数据则直接取自该文章。

表格所反映的信息如下：

• 所有任务在各类模型下均顺利完成。 Kimi成功完成了全部五个任务：“PONG”响应符合预期；FizzBuzz程序输出了正确的15行结果；修复Bug的操作仅涉及两处改动——一处遗漏了return语句，另一处本应为== 0的条件被误写为== 1——测试代码未作任何修改且全部通过。代码库总结部分则是一段仅含107个单词的段落，准确描述了六个功能相同的模块；重命名操作仅需一次sed命令即可完成四个文件的修改并同步更新测试方法，最终所有测试亦顺利通过。我在提示词中要求对整个文件夹执行一次空的grep操作，而该文件夹内恰好还有我自行保存的提示词副本，因此Kimi同样对该文件执行了sed命令并在回复中如实说明了这一点。这些都属于较为简单的任务；我并未测试涉及多个文件的代码重构场景。
• Kimi需要消耗更多资源用于推理。 K3模型在这五个任务中共使用了53、241、315、1,586与1,858个推理用令牌（总计4,053个）。而V4-Flash上的dsh同样具备推理能力，但用量较少：分别为0、52、834、5与1,093个（总计1,984个）。Kimi耗时更多的原因正是其需要执行更多推理步骤以及额外的操作。
• 缓存机制大幅降低了成本。 每个Kimi任务启动时都会发送约15,000个令牌用于传递系统提示词及工具定义信息。在这五次任务中，Kimi共发送了91,470个未缓存的输入令牌，并从缓存中读取了355,328个令牌（仅重命名任务就读取了157,952个）。这意味着80%的提示词内容均来自缓存，其计费价格仅为每百万令牌0.30美元，远低于未缓存情况下的3美元/百万令牌标准。若全部按未缓存计费计算，总成本本应达1.49美元左右，而实际成本仅0.53美元，可见缓存机制使成本降至原来的三分之一左右。即便如此，0.30美元/百万令牌的费率仍属高端水平：该数值约为V4-Flash模型缓存读取费率的21倍（后者为0.014美元/百万令牌）。
• 处理简单任务时V4-Flash更具优势。 在缓存处于热状态的情况下，dsh的运行速度约为Kimi的9倍，成本仅为其1/48；若模型处于冷启动状态，则速度与成本优势分别约为7倍及1/22。无论何种情况结论均一致：仅重命名操作一项，Kimi便需耗时128.9秒且花费0.180美元，而dsh仅需12.3秒并消耗0.0043美元。

Kimi K3在OpenClaw与dsh中的对比概览

两者均为能够读取文件、执行Shell命令且按Token数量计费的工具。它们的区别主要在于开发方以及使用方式。

	OpenClaw中的Kimi K3	dsh
开发方	模型：Moonshot AI；代理循环程序：OpenClaw	DeepSeek（负责模型与工具框架），MIT
从脚本中调用	openclaw agent --agent <id> --model moonshot/kimi-k3 -m "…" --json	dsh --profile headless "…"
切换模型方式	修改 model.primary 文件中的 openclaw.json 参数	编辑 ~/.dsh/settings.yaml 文件
无界面模式下的基准测试（5个小任务）	耗时309.9秒，费用约0.531美元，全部任务均完成	耗时35.7秒，费用约0.011美元，全部任务均完成（使用的是V4-Flash模型；冷启动情况下则需44.8秒，费用约0.024美元）
生成像素艺术小部件（相同指令）	尝试了3次，其中2次成功生成了小部件；此处展示的结果耗时7.4分钟，费用约0.47美元	尝试了2次，成功生成小部件的那次耗时25分钟，费用约0.49美元
测试版本	OpenClaw 2026.9.2，Moonshot插件版本为2026.9.2	0.1.1-rc.2（开发者预览版）

此前本网站上发布的对比文章中曾包含Reasonix这一工具。不过我在2026年9月9日便已不再使用Reasonix，因此它并未出现在此处；其相关介绍可参见7月份的原文，该文现作为历史记录保留。另外我还让MiniMax M3运行了同一套测试程序；MiniMax与Moonshot属于不同的公司，关于此次测试的详细情况请参阅独立文章。

趣味测试：同样的任务要求，Kimi与dsh的对比

在dsh的文章中，所谓的“趣味测试”是指根据文字描述用V4-Flash制作出本网站标志的像素艺术小部件。我给Kimi提供了完全相同的任务说明，并计时观察其表现。具体要求如下：

• 仅需一个纯原生JavaScript文件，即 ll-pixel-logo.js，该文件不能依赖任何外部库或网络请求；它需要在每个带有 .ll-pixel-logo 类名的元素中绘制出适配高分辨率屏幕的画布，同时提供 window.LLPixelLogo.mount(el) 接口。此外还需提供一个演示用的 index.html 文件以及一份 README.md。
• 必须是程序化生成的图案，而非手绘的位图： 图案为一个40×40的网格，由 isLit(col, row) 函数决定哪些像素点被点亮；具体形状为一个环形区域（半径范围0.82R至R）以及两个倾斜的“L”形结构，每个“L”又由两个经过剪切处理的平行四边形构成。
• 交互功能： 指针靠近时产生排斥效果并带有回弹动画；点击时有明显的视觉反馈；存在细微的闲置状态动画；需支持“减少动态效果”模式；同时还需包含自检功能（通过 node --check 命令以及无需DOM环境的点亮像素计数）。

像素艺术小部件大比拼页面完整列出了任务要求。

Kimi的处理过程如下：

• 第一次尝试（直接使用原始任务说明）： 运行8.8分钟后终止，未生成任何代码，花费约0.31美元。K3分析了参考标志的几何结构并规划了实现方案，但最终并未编写出任何成果文件。dsh的初次尝试情况类似——它在10分钟内一直在脑海中构思如何绘制位图，不过当时的任务说明其实允许使用手绘位图。
• 第二次尝试（重新发送任务说明）： 最终生成了一个完整的小部件，但所有文件被保存在工作进程的独立目录中而非我设定的监控路径下，耗时约15分钟，花费0.72美元。在运行约8分钟后，它输出了323行代码的 ll-pixel-logo.js 文件、演示页面、README说明及两个测试文件；随后反复调试直至所有测试通过并生成了简短报告。由于文件存放位置不对，我起初以为第二次尝试毫无成果，因此约7分钟后便启动了第三次尝试。
• 第三次尝试（任务说明有所简化且增加了限制条件）： 耗时7.4分钟，顺利生成了全部三个必需文件，花费0.47美元。我在原始说明基础上添加了 TARGETED — write the widget file in one tool call, no exploration, no planning, no verification loop. 的指令，同时修改测试部分内容为 Do NOT do a "node --check" or playwright test — just write the files and print a short report listing what you wrote. 最终生成的小部件具备指针排斥与回弹效果、点击时产生破碎重组动画、细微的闪烁效果以及“减少动态效果”模式。相关验证结果详见后文。

三次尝试分别耗时8.8分钟、15分钟和7.4分钟，花费分别为0.31美元、0.72美元及0.47美元——合计约1.50美元即可完成两个小部件的开发。第三次的花费数据来自其生成的JSON记录；前两次因未生成正式记录，故费用是根据OpenClaw系统对单次会话设定的单价累加得出，该数值恰好与第三次的实际费用相符。

大约一小时后，在同一工作进程中运行的MiniMax M3模型也检测到了第二次尝试生成的文件，它同样执行了测试并声称这些成果为其自主完成。相关细节可见于 MiniMax M3编程代理介绍 页面；目前Kimi与dsh各自制作的小部件均已出现在 像素艺术小部件大比拼 页面中。

Kimi生成的代码中，ll-pixel-logo.js 文件开头约30行内容如下：

/*!
 * ll-pixel-logo.js — interactive pixel-art LaserLloyd logo widget.
 *
 * Self-contained vanilla JS: no dependencies, no build step, no network.
 * Embed on any page with:
 *
 *   <div class="ll-pixel-logo" data-size="320"></div>
 *   <script src="ll-pixel-logo.js"></script>
 *
 * Every .ll-pixel-logo element gets a <canvas> mounted inside it at load.
 * Programmatic API: window.LLPixelLogo.mount(el) -> instance.
 *
 * Art: 40x40 pixel grid, rasterised procedurally from geometry (ring + two
 * interlocking italic Ls). Interactions: pointer repulsion with spring-back,
 * click/tap shatter-and-reassemble, idle shimmer/twinkle, reduced-motion
 * support. Mouse and touch. No scroll hijacking (all listeners passive).
 */
(function () {
  'use strict';

  // -- constants ------------------------------------------------------------
  var VERSION = '1.0.0';
  var GRID = 40;                                // logical grid: GRID x GRID cells
  var BLUE   = [31, 63, 143];                   // #1f3f8f logo blue
  var HILITE = [46, 168, 255];                  // #2ea8ff highlight blue
  var AMBER  = [255, 182, 74];                  // #ffb64a twinkle amber
  var CYAN   = [0, 230, 207];                   // #00e6cf max-displacement glow

  var CENTER = GRID / 2;                        // grid centre coordinate (20)
  var R_OUT = 19;                               // ring outer radius (cells)
  var R_IN = 0.82 * R_OUT;                      // ring inner radius
  var SLANT = Math.tan(20 * Math.PI / 180);     // ~20 deg italic shear

Kimi借助 makeL 辅助函数分别生成两个平行四边形以组成每个“L”形结构；通过 inPara 辅助函数判断点是否在指定范围内，进而由 isLit 函数决定像素点是否点亮。所有相关参数（如环形半径范围0.82R至R、倾斜角度为 Math.tan 计算出的20°、弹簧系数与阻尼值等）均集中定义在文件顶部。最终生成的397行代码的 ll-pixel-logo.js、40行内容的 index.html 以及79行内容的 README.md 均可从 /assets/uploads/2026/09/kimi-codex/ 路径下载使用。

dsh制作的小部件（其源码见于 此链接，相关介绍可参见 dsh初探文章）实现逻辑也类似：两者均依据几何算法生成环形区域与两个倾斜的“L”形图案，也都提供了 window.LLPixelLogo.mount 接口且都兼容 prefers-reduced-motion 设置。但参数取值不同：dsh设定的外环半径为19.7、内环为0.80R，倾斜角度约为24°（对应数值0.453）；Kimi则采用19、0.82R及20°的数值。此外Kimi绘制的线条更细——其“L”形结构的宽度仅为3个像素单位，而dsh的设计中该数值分别为4.2与3.8。正因如此，Kimi版图案点亮了510个像素点，而dsh版本则点亮了656个。尽管两者都无法与原始参考标志完全一致，但远观时仍能辨认出相似的轮廓。值得一提的是，dsh在第二次尝试中还主动添加了Node单元测试及Playwright自动化测试脚本；而Kimi在第三次尝试时则严格遵守指令未执行任何测试操作。

我在Kimi的小工具上执行的验证命令

2026年9月11日，我针对此页面所提供的代码副本再次执行了这些命令，代码位于 /assets/uploads/2026/09/kimi-codex/ 目录下：

$ wc -l ll-pixel-logo.js
397 ll-pixel-logo.js
$ node --check ll-pixel-logo.js && echo "node --check passed"
node --check passed

另外还有两项检查是我私下进行的，使用的是两个很小的辅助脚本（每个脚本都不到20行），这些脚本并未对外发布。因此这里仅介绍其实现方法，而非可直接复制执行的命令：

• 点亮单元格计数。 我在Node环境中加载了该小工具的文件，并模拟了一个虚拟的DOM环境（即没有实际作用的canvas、window和document对象）。接着调用了文件中自带的 isLit(col, row) 函数，对整个40×40网格中的每个单元格进行了检测，并按象限统计了被点亮的单元格数量。结果显示共有510个单元格被点亮：左上象限124个，右上象限103个，左下象限160个，右下象限123个。
• 挂载功能检查。 同样在虚拟DOM环境下，我确认了该文件确实将 window.LLPixelLogo 定义为一个对象；同时调用该对象上的 mount() 方法时并未抛出异常，而是返回了一个对象。

仅圆环区域（即那些中心点到原点的距离介于0.82R与R之间的单元格，其中R=19）就包含了510个被点亮单元格中的352个，剩下的158个则属于两个“L”形区域。这些辅助脚本是我自己编写的，并非Kimi所写；它们仅用于简单测试，并非在浏览器中运行：您现在正在阅读的页面才是真正在浏览器中运行的版本。

为什么此模型无法通过 Codex 运行？

OpenClaw 还提供了一个 Codex 适配插件，该插件可运行真正的 Codex 应用服务器（它负责管理 @openai/codex 0.153.4）。不过本文所述内容均不会经过该插件处理，因为它无法支持此类模型：其路由检查机制 configuredModelRouteNeedsCodex 对于任何标准化后的提供商标识不是 openai 的模型都会返回 false。Moonshot 的提供商标识为 moonshot，因此像 moonshot/kimi-k3 这样的路由根本无法到达 Codex 运行时环境。“兼容 OpenAI”并不等同于“兼容 Codex 适配机制”。

因此，Kimi 模型实际上是在 OpenClaw 自身的运行循环中执行的，其运作方式与其他所有 OpenClaw原生支持的模型相同。这样一来，你就无法使用 Codex 的线程恢复功能、压缩机制、动态工具桥接功能以及特定的应用服务器执行模式。如果确实需要这些功能，目前已知的变通方法是使用 codex-router——这是一个本地桥接工具，它会将 Codex 的请求导向 127.0.0.1:4202 端点并转发给 Kimi（具体参见其 README）。为了让插件能够识别这种配置设置，必须将插件的 appServer.homeScope 参数设为 "user"，如此一来 OpenClaw 就会将你本地的 ~/.codex（或 $CODEX_HOME）目录与插件共享，而非为每个 OpenClaw 代理单独维护独立的 Codex 状态。目前我尚未决定是否接受这种做法，因此也尚未实现它。

注意事项（都是我亲身遇到过的）

• 要求过于宽泛的指令可能会让推理模型陷入停滞，而超时反而可能掩盖了成功的结果。 第一次尝试时，模型思考了8.8分钟却没写出任何代码；第二次尝试时，它写出了可正常运行的代码，但由于超时导致文件被保存在了错误的文件夹中，因此看起来像是又一次失败。解决办法是给出更简洁的指令：TARGETED — write the widget file in one tool call, no exploration, no planning, no verification loop. 同时需明确指出目标文件夹路径。K3至今仍能理解这种指令；只是不会再无限制地规划下去。无论退出状态如何，都请查看本次会话生成的文件内容以及该智能体的工作空间。
• 非成功退出码并不一定意味着任务失败，务必检查生成的文件。 第一次执行FizzBuzz任务时，系统返回了退出码1，提示未找到合适的模型，最后还显示“⚠️ 已达到API速率限制，请稍后重试”。但实际上它已经成功生成了 fizz.py 文件且该文件可正常运行。再次尝试时系统回复“已创建并运行完毕”，仅此信息表明任务完成。我的脚本会将每次运行的JSON数据写入同一文件，因此第一次失败运行的记录被覆盖了；不过其退出码与最终提示仍保留在相关日志中。表格中展示的是后续一次正常完成的运行结果。
• 切勿直接复制其他测试环境中的已完成文件夹。 我原本打算通过复制dsh环境下的已修复文件来创建Kimi环境的修复文件夹，但那时dsh早已完成了修复工作，于是Kimi的首次修复尝试发现文件其实早已正确无误，仅进行了验证而已。正确的做法是从原始未修改的源文件中复制所需内容。后来我重置了文件夹并重新运行了一次；表格中记录的就是这次后续运行的结果。

这对我而言意味着什么

在这五项任务中，Kimi K3的表现虽然正确，但速度较慢且成本较高。对于一些简单的任务，使用 V4-Flash 版本的 dsh 仅需约九分之一的时间即可完成相同工作，成本也仅为原来的四十八分之一（初步测试结果）。此次基准测试之后，我将负责执行任务的 AI 代理从 Kimi K3 切换到了 MiniMax-M3；而 Kimi K3 则继续留在原位置——即我的审核代理之后。毕竟对于需要细致检查的环节而言，慢一点但更精准的回答是值得付出更高成本的。

相关链接：DeepSeek Harness (dsh)（本次测试所使用的工具及基准数据来源），像素艺术小部件对比测试（三种小部件的直观对比），MiniMax M3（截至 2026年9月11日我的工作代理所使用的模型），以及 我的 AI 代理实际成本分析（各模型的价格对比）。