Kimi K3作为编程代理运行在Moonshot上：将其集成到OpenClaw中，与dsh进行基准测试，并请求它生成一个像素艺术风格的徽标小部件。

我让我的 OpenClaw 工作代理去处理 Moonshot 公司的旗舰推理模型 Kimi K3，并让它完成我在八月份用来测试 DeepSeek Harness (dsh) 的那五项小型编程任务。Kimi 全部顺利完成了这些任务。同一天，我让 DeepSeek V4-Flash 也执行同样的五个任务：结果显示，Kimi 的运行时间大约是 DeepSeek V4-Flash 的 9倍（309.9秒对比35.7秒），成本则约为其 48倍（0.531美元对比0.011美元）。随后我又给了 Kimi 一份 dsh 用来生成小工具的像素艺术标志设计需求说明。Kimi 总共尝试了三次：第一次直接使用原始需求说明，结果什么也没生成；第二次虽然使用了相同的需求说明，但它把完整的小工具代码写到了错误的文件夹里，而且因超时被强制中断，所以我一开始没注意到它的成果；第三次则是在我缩短了需求说明并指示它跳过规划步骤后才成功。

老实说：路径A与路径B的对比

这里所演示的全是路径A的情况：Kimi K3模型通过Moonshot服务提供商来驱动OpenClaw自身的代理循环。在我的测试环境中，该服务提供商早已配置完毕，因此只需简单更改模型设置即可让系统使用Kimi模型。

路径B则是将Kimi模型置于真正的Codex应用服务器之后运行，而该服务器正是由OpenClaw的Codex适配插件所管理（该插件负责处理 @openai/codex 0.153.4版本）。不过我并未自行构建这一环境，本文中的示例也均未通过Codex运行。原因就在插件的代码中：其路由检查函数 configuredModelRouteNeedsCodex 会针对所有供应商ID并非 openai 的服务返回 false。由于Moonshot服务提供商的ID为 moonshot，因此像 moonshot/kimi-k3 这样的路由根本无法被转发至Codex运行时环境。

目前已知的变通方案是使用 codex-router，这是一个本地桥接工具；根据其说明文档，它能将Codex的请求引导至 127.0.0.1:4202 端口并转发给Kimi模型。不过要让适配插件识别这种设置，需将插件的 appServer.homeScope 参数设为 "user"，这样一来OpenClaw的适配环境就会与本地的 ~/.codex（或 $CODEX_HOME）目录共享配置信息，而非为每个OpenClaw代理单独维护Codex运行环境。我个人目前还不确定是否愿意接受这种设置方式，因此路径B目前仍只是理论上的选择。

路径A也存在一些局限性需要留意：在生成的轮次记录中会出现 agentHarnessId: "openclaw" 字段，其格式与其他OpenClaw原生模型的输出一致。不过你无法享受到Codex的线程恢复功能、数据压缩机制、动态工具桥接能力以及应用服务器执行模型等特性。如果确实需要这些功能，路径B才是唯一的选择。

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

以下是我在 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百万上下文长度，但我将其上限设为26万。 OpenClaw的Moonshot目录显示K3可处理1,048,576个标记的上下文内容。不过我在模型配置中设置了 contextTokens: 262144，这样其会话长度便与其他模型保持一致。实际上，在设置此上限后，实际使用的上下文长度约为25.6万标记，而非100万。
• 缓存机制是控制成本的关键。 每个任务开始时都需要加载约1.5万个标记的系统提示与工具定义内容。但第一步之后，大部分内容都会从缓存中读取；此时每百万标记的成本仅为0.30美元，远低于原本的3美元。就本次重命名任务而言，仅从缓存中读取的内容就多达157,952个标记。

操作流程：从基础到进阶

步骤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，就务必像上面那样完整写入整个对象。

contextTokens: 262144 这一行数值正是设置说明中所建议的上限值。若您调高该数值，预计会话过程中的缓存读取开销以及每轮处理的延迟都会随之增加。

步骤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" 是路径A的标志。若是通过Codex应用服务器执行的任务，该值则会显示为 "codex"。winnerModel: "kimi-k3" 表明该任务确实是在K3模型上运行的，而非降级使用了成本更低的模型。reasoningTokens 的数值包含在 output 中（总数等于输入令牌数加上输出令牌数），因此这53个推理令牌正是70这个总数的一部分。

对比测试：OpenClaw中的Kimi K3与dsh

两者均为能够读取文件、执行Shell命令且按Token数量计费的智能代理。不过它们的开发方以及使用方式有所不同。

	OpenClaw中的Kimi K3（路径A）	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模型，第二次运行时速度更快）
像素艺术小工具制作测试	共尝试了3次，其中2次成功生成了所需小工具；此处展示的结果耗时7.4分钟，费用约0.47美元	共尝试了2次，成功的一次耗时25分钟，费用约为49美分
测试版本	OpenClaw 2026.9.2，Moonshot插件版本为2026.9.2	0.1.1-rc.2（开发者预览版）

此前本网站上的对比测试中曾设有Reasonix这一项。不过我在2026年9月9日便已停用该服务，因此此处不再列出；其相关介绍可参见7月份的专题文章。此外，我还使用MiniMax M3进行了同样的测试；MiniMax与Moonshot属于不同的公司，关于该测试的详情请参阅另一篇专题文章。

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

这些正是dsh那篇文章中所测试的五个任务；每个任务都在一个全新的临时文件夹中执行，且针对Kimi的每个任务都开启了新的会话。同一天，我也在V4-Flash模型上重新运行了dsh对这些任务的测试，并在相关设置文件中指定使用 deepseek-v4-flash 模型。不过提示词的内容并不完全相同：dsh会在其启动目录中运行，因此其提示语中提到了“当前目录”；而Kimi的提示语则给出了每个任务文件夹的绝对路径。此外，Kimi的修复程序还添加了这样一条指令：“如果未安装pytest，请先通过‘pip install --user pytest’进行安装”（实际上pytest早已安装完毕，Kimi也并未真正执行该安装操作）。表格中的“第二次运行”数据即由此产生：第一次运行时的耗时为44.8秒，费用约为0.024美元（此时缓存尚为空）；而本文中用于对比的数据正是第二次运行的结果。V4-Pro与Gemma-4-26B的相关数据则来自八月份发布的 dsh相关文章，并未重新测试。表格中所列的耗时为整个流程所耗费的时间。Kimi所使用的token数量及费用数据源自OpenClaw返回的JSON信息，而dsh的数据则来自其自身的会话日志。

任务	Kimi K3（路径A）	dsh V4-Flash（同日运行）	dsh V4-Pro（八月历史数据）	Gemma-4-26B（八月历史数据）
回复“PONG”（启动后执行一次调用）	✅ 6.1秒 · 0个工具	✅ 1.7秒 · 0个工具	✅ 2.8秒	✅ 13.2秒*
编写并运行FizzBuzz程序	✅ 22.8秒 · 2个工具（写入、执行）	✅ 5.3秒 · 3个工具	✅ 8.4秒 · 2个工具	✅ 4.9秒 · 2个工具
修复两个错误以确保单元测试通过（测试代码未改动）	✅ 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秒
Token使用量：输入/缓存读取/输出（推理用）	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美元（每百万Token的价格分别为3美元、15美元及0.30美元）	约0.011美元（每百万Token的价格分别为0.44美元、1.32美元及0.014美元）	约0.072美元	0美元（仅产生电费成本）

工具调用次数即实际使用的工具数量。Kimi的数据源自OpenClaw返回的JSON信息中的 toolSummary.calls 字段，括号内标注的是具体工具类型；dsh的数据则来自其会话日志。*表示模型在冷启动后进行的首次调用。Kimi的计费标准依据我在OpenClaw平台上录入的参数计算得出；当前价格请查阅 Moonshot定价页面。V4-Flash的费用计算采用与dsh原文章相同的费率标准（参见 DeepSeek定价说明）；V4-Pro与Gemma的数据则沿用了原文章的记录。

表格所反映的信息如下：

• 所有任务均成功完成。 这些任务都没有难倒Kimi。在修复错误时测试代码完全未受干扰；重命名操作仅需使用一次 sed 命令即可完成，随后单元测试也顺利通过了，甚至还用 grep 命令确认旧函数名已不存在。
• Kimi需要更多时间用于推理计算。 K3模型在这五项任务中分别使用了53、241、315、1,586及1,858个推理类Token（总计4,053个）。而V4-Flash上的dsh同样具备推理能力，但所需Token数量要少得多：分别为0、52、834、5及1,093个（总计1,984个）。Kimi耗时更多的原因正是其需要进行更多的推理计算与操作步骤。
• 缓存机制显著降低了成本。 执行五项任务时，Kimi共发送了91,470个未经缓存处理的输入Token，同时从缓存中读取了355,328个Token；也就是说其输入的Token中有80%均来自缓存。若这些Token均需按非缓存计费标准处理的话，总费用将升至约1.49美元，而非当前的0.53美元。
• 处理简单任务时V4-Flash更具优势。 V4-Flash完成全部测试仅耗时35.7秒，费用约为0.011美元；与Kimi相比，其速度提升了9倍且成本降低了48倍，而最终结果完全一致。仅就函数重命名这一项而言，Kimi便耗费了128.9秒及0.180美元，而dsh仅需12.3秒及0.0043美元即可完成。

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

在dsh提交的测试中，它根据书面需求利用V4-Flash技术制作了一个像素艺术风格的网站标志小部件。我将完全相同的需求说明交给Kimi，并记录了其完成时间。具体需求如下：

任务要求：制作交互式像素艺术版LaserLloyd标志小部件

请制作一个可独立运行且便于嵌入的像素艺术版LaserLloyd标志（参见reference-logo.png）：白色背景上有一个深蓝色圆环，颜色代码为#1f3f8f；圆环内包含两个倾斜排列的大写字母“L”——左上方的“L”的竖笔位于右下方“L”的横线之下，二者呈对角线排布。

交付内容（全部放入同一文件夹中）

1. ll-pixel-logo.js — 仅一个纯原生JavaScript文件即可，无需任何依赖、编译步骤或网络请求。任意网页只需通过以下代码即可嵌入该小部件：<div class="ll-pixel-logo" data-size="320"></div> 加上 <script src="ll-pixel-logo.js"></script>。该脚本会自动查找所有带有.ll-pixel-logo类名的元素并在其中生成<canvas>画布。该小部件需具备响应式特性：画布宽度自动适配容器尺寸，且在高分辨率屏幕上依然清晰；同时需提供window.LLPixelLogo.mount(el)接口。
2. index.html — 一个演示页面，展示该小部件在三种不同尺寸下的效果，并附带简短的交互说明。
3. README.md — 详细说明如何嵌入该小部件、各种交互方式以及可用的自定义属性。

美术设计方面

• 像素网格大小为40×40。 切勿手动绘制位图（不要直接写类似‘#’或‘.’的字符串——那样效率极低且容易出错）。而是应通过算法自动生成像素图案：编写一个isLit(col,row)函数，当某个像素点满足以下条件时返回true：(a)该点位于半径在0.82R至R之间的圆环上；(b)该点属于两个倾斜排列的“L”字母的一部分——每个“L”由两个平行四边形构成（竖笔与横线均呈约20°的倾斜角度），且左上方的“L”的横线恰好位于右下方“L”的竖笔之下，与参考图一致。请调整少量参数以确保最终效果在200像素尺寸下与参考图相符。所有需绘制的像素点信息应在初始化时预先计算完毕。
• 调色板设定：标志主色为#1f3f8f；高亮色为#2ea8ff与#00e6cf；琥珀色为#ffb64a；背景设为透明。

交互功能（本测试的核心——请务必让交互体验有趣）

• 鼠标悬停/触摸移动：指针附近的像素点会产生物理般的响应效果——比如被像流体或磁力般推开，随后在阻尼作用下逐渐复位；此时这些像素点会发出#2ea8ff或#00e6cf色系的辉光。整个动画需以60帧/秒的速率流畅运行，不可出现卡顿现象。
• 点击/触摸：请设计一种酷炫且令人满意的效果。只需选择一种核心效果并完美实现即可：比如整个标志碎裂成无数像素点并向外飞散，随后在重力与反弹作用下重新组合成完整标志（耗时约1.5–2秒）；又或者让一道“激光”扫过画布，将标志逐像素地重新绘制出来，过程中伴随闪烁的火花。重复点击时也应保持良好体验（不可中途中断动画）。
• 闲置状态：小部件应呈现细微的动态效果——比如缓慢的闪烁或偶尔有像素点发光——使其看起来始终活跃而非静止，但绝不可干扰用户操作。
• 需遵循prefers-reduced-motion: reduce设置：此时仅渲染静态标志即可，悬停时的辉光效果也应关闭。
• 需同时支持鼠标与触摸操作；不得占用滚动功能。

质量标准

• 代码需整洁且具备完整注释；除LLPixelLogo外不可出现其他全局变量。缩进使用两个空格，总代码行数控制在400行以内。
• 代码必须能在file://协议下无报错运行。请自行测试：可编写简易Node脚本或使用任何工具进行语法检查与功能验证（注意无法使用jsdom环境——只需执行node --check命令即可）。此外还需编写一个不涉及DOM环境的单元测试：比如统计发光像素点的数量，并确认圆环及两个“L”字母均出现在正确位置。
• 最终需输出简短报告：说明自己完成了什么、如何嵌入该小部件以及已验证的功能点。

Kimi的处理过程如下：

• 第一次尝试（使用原始需求说明）：仅用时8.8分钟便终止，未生成任何代码，费用约为0.31美元。 K3分析了参考图并考虑了几何原理与实现方案，但最终并未编写出任何交付文件。实际上dsh的初次尝试也遭遇了类似情况：它在脑中反复构思如何手动绘制位图，耗时约10分钟，不过当时需求说明仍允许使用手绘方式。
• 第二次尝试（再次使用原始需求说明）：最终生成完整小部件，但代码存放位置有误，费用约为0.72美元。 大约8分钟后它便生成了包含323行代码的ll-pixel-logo.js，又接着制作了演示页面、README文档及两个测试文件。它反复调试直至所有测试通过后才编写报告。可惜所有内容都存入了该工作代理的独立工作区而非我设定的监控文件夹中，因此当15分钟限时结束时它仍未能发送回复。从我的视角看第二次尝试似乎毫无成果，于是我在约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.该小部件实现了指针排斥与回弹效果、点击时的碎裂重组动画、闲置时的闪烁效果以及对ll-pixel-logo.js设置的响应。相关验证细节见下节。

三次尝试分别耗时8.8分钟、15分钟及7.4分钟，产生的费用依次为0.31美元、0.72美元与0.47美元——总共约1.50美元便完成了两个小部件的制作。第三次的费用数据源自其专属的JSON记录；前两次因未生成记录而无法直接获取金额，故费用数值是OpenClaw系统对每次会话按消息数量计算后的总和；这一总和恰好与第三次的实际费用相符。

大约一小时后，第二次尝试生成的小部件又重新出现了：原来在同一工作环境中运行的MiniMax M3模型发现了那些文件，并自行执行了测试后将结果视作自己的产出。该过程详见MiniMax M3运行记录；Kimi制作的两个小部件也与dsh的作品一同展示在像素艺术小部件对比页面上。

以下是Kimi生成的prefers-reduced-motion文件的开头约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 K3制作的小部件的实际运行效果，未经任何改动：

Kimi借助inPara辅助函数构建出两个“L”字母——每个字母均由两个平行四边形构成；在isLit函数中则利用Math.tan函数判断像素点是否属于目标区域。所有关键参数——如圆环半径范围0.82R至R、20°的倾斜角度以及弹簧阻尼系数等——均被集中定义在文件开头处。

Kimi生成的所有文件——包含397行代码的ll-pixel-logo.js、40行内容的index.html以及79行文本的README.md——均可通过/assets/uploads/2026/09/kimi-codex/路径访问，原始需求说明则作为BRIEF.md存放于此。

为便于对比，以下是dsh生成的小部件的开头约30行代码，可通过/assets/uploads/2026/08/deepseek-harness/ll-pixel-logo.js查看：

/*!
 * ll-pixel-logo.js — interactive pixel-art LaserLloyd logo widget.
 * Vanilla JS, zero dependencies, no network requests, works from file://.
 *   <div class="ll-pixel-logo" data-size="320"></div>
 *   <script src="ll-pixel-logo.js"></script>
 * Auto-mounts on .ll-pixel-logo elements; window.LLPixelLogo.mount(el) too.
 * Knobs: data-size, data-speed, data-static.
 */
(function (global) {
  'use strict';
  // ---- 0. palette -----------------------------------------------------
  var BLUE = [31, 63, 143];      // #1f3f8f — logo blue
  var HI = [46, 168, 255];       // #2ea8ff — hover / repulsion glow
  var AMBER = [255, 182, 74];    // #ffb64a — twinkle spark
  var CYAN = [0, 230, 207];      // #00e6cf — deep glow
  // ---- 1. art: procedural 40x40 raster (no hand-drawn bitmap) ----------
  // A cell is lit when it belongs to the ring or to one of the two slanted
  // interlocking Ls. Each L is two parallelograms (stem + foot), described by
  // top-left (ax,ay), width w, height h, sheared by SLANT (bottom edge shifts
  // left): TL=(ax,ay) TR=(ax+w,ay) BL=(ax-SLANT*h,ay+h). The upper-left L's
  // foot runs right and tucks under the lower-right L's stem, like the ref.
  var GRID = 40;                 // cells per side
  var RING_R = 19.7;             // outer ring radius (cells)
  var RING_IN = 0.80 * RING_R;   // inner ring radius (reference ~0.808R)
  var SLANT = 0.453;             // shear of stems/feet (~24deg)
  var LETTERS = [
    { ax: 15.0, ay: 5.2, w: 4.2, h: 10.6 },   // upper-left L: stem
    { ax: 10.2, ay: 15.8, w: 15.0, h: 3.8 },  // upper-left L: foot
    { ax: 24.7, ay: 13.8, w: 4.2, h: 14.7 },  // lower-right L: stem
    { ax: 18.0, ay: 28.5, w: 15.0, h: 3.8 }   // lower-right L: foot
  ];

两个小部件的生成逻辑完全一致：均通过几何算法生成圆环与两个倾斜排列的“L”字母，也都提供了window.LLPixelLogo.mount接口且同样支持prefers-reduced-motion设置。不过二者使用的参数有所不同：dsh设定的外环半径为19.7、内环半径为0.80R且倾斜角度为0.453（约24°）；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所写；它们仅用于简单测试，并非在浏览器环境中运行——您现在阅读的页面才是真正的浏览器运行结果。

注意事项（我实际遇到过的坑）

• “兼容 OpenAI”并不等于“兼容 Codex 调用方式”。 Moonshot 的 /v1/chat/completions 接口作为 OpenClaw 的提供商运行良好，但 Codex 配套插件只接受 provider id 为 openai 的路由。如果你确实需要 Codex 的会话恢复功能以及动态工具桥接能力，那么只能选择方案 B（即 codex-router 桥接方式）。详见上文的方案 A 与方案 B对比。
• K3 总会进行推理，哪怕只是回复些简单内容。 比如要求“仅回复：PONG”，它仍消耗了 53 个推理令牌。这是设计使然且可预测的；请提前预留相应预算。
• compat 配置块是替换而非合并原有设置。 如果你在模型配置中加入 compat 以禁用 temperature 参数，也需一并复制插件中相关的 reasoning-effort 字段，否则这些设置会悄无声息地丢失。
• 宣传中的 1M 上下文长度其实受我的上限限制。 官方目录称支持 1,048,576 个令牌；但我的 contextTokens: 262144 设置意味着实际会话容量仅为 256k。需手动调高此值，否则不会自动生效。
• 缓存折扣确实存在，但计费标准仍是旗舰级费率。 每百万个缓存读取令牌收费 $0.30，这一数值约为 dsh V4-Flash 费率 $0.014 的 21 倍。即便如此，使用缓存后成本仍降至无缓存时的约三分之一。
• 开放式创意需求可能让推理模型陷入僵局；超时反而可能掩盖成功结果。 第一次尝试耗时 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 的工作目录，结果 Kimi 首次运行便检测到文件已修正而仅完成验证。随后我重置目录并重新执行，表格记录的是第二次运行数据。另外注意：dsh 默认在启动所在目录工作；我的首个脚本未执行 cd 切换至任务目录，导致文件被写入错误位置，最终不得不重做全部五个任务。
• 两个生成的控件均无法完全还原参考徽标样式。 需求说明要求调整参数使控件在 200px 尺寸下呈现出原徽标效果。实际发布前恐怕还需花十分钟微调笔触粗细与倾斜角度才行。

这样的结果对我意味着什么

在这五项任务中，Kimi K3虽然答对了，但速度很慢且成本高昂。对于一些简单的任务，运行在 V4-Flash 上的 dsh 仅用约九分之一的时间便完成了同样的工作，成本也仅为 Kimi K3 的 1/48 左右。此次基准测试之后，我将负责执行任务的智能体从 Kimi 切换为 MiniMax-M3；而 Kimi K3 则继续留在原处——也就是我的审核智能体之后。在这种情况下，虽然它的响应速度较慢，但给出的答案更为谨慎可靠，这样的代价也是值得的。

至于路径 B——即连接至 Codex 应用服务器的代码路由机制——目前还只是停留在纸面上；我需要先确认 homeScope: "user" 所共享的数据内容是否安全。在此之前，在我本地系统中，“作为编程智能体的 Kimi”实际上是在驱动 OpenClaw 的原生处理流程，其运作方式与其他任何基于 OpenClaw 的模型并无二致。

相关链接：DeepSeek Harness (dsh)（我用来对比测试的框架，基准测试与任务说明均出自此处），MiniMax M3（截至 2026年9月11日，我的工作智能体所使用的模型），Reasonix（已停用；我于 2026年9月9日将其从系统中移除），以及 我的各类 AI 智能体实际所需的成本（关于不同服务定价的综合对比）。