I Ran Claude Code FREE for 24+ Hours... the best Local AI Harness? 🤔

AI Harness核心机制与本地运行的矛盾

本期视频旨在对比评估多种AI执行框架（Harness），包括Claude Code、OpenCode以及原生运行的Inference。所谓AI Harness的核心逻辑是自动循环验证与编辑，它无需用户手动提示或反复对话，而是让模型在闭环中自动执行任务。然而，作者指出本地运行存在显著矛盾：若拥有无限算力，循环执行毫无问题；但在本地系统上缓慢运行模型时，用户往往追求极致的精确性。这种对资源效率与执行精度的双重需求，构成了评估这些工具的关键视角。

Claude Code本地部署与上下文开销分析

在CLI模式下运行Claude Code时，尽管界面提示需要订阅，但实际可通过curl命令安装脚本并连接本地模型。作者使用版本2.1.27，通过设置ANTHROPIC_BASE_URL指向本地IP与端口，并输入假API Key及禁用遥测参数来启动。在Inference服务端启用多模态支持并将思考模式设为中等、API限制设为无限后，首次处理“hello”指令耗时33秒。值得注意的是，启用缓存提示词功能后，后续处理速度显著提升。然而，通过/context命令发现系统提示词占用18,000 tokens，这占据了200k上下文窗口的9%。这种巨大的“膨胀”导致在运行如GLM 5.3等模型时，随着上下文增大性能急剧下降，80,000 tokens的负载将成为噩梦。

OpenCode配置对比与模型命名策略

作为基准对比，OpenCode的安装同样使用curl命令（opencode.ai/install bash），当前版本为1.18.31。其配置核心在于创建opencode.json文件以定义Provider。作者将Inference设为提供商，使用OpenAI API接口（/v1路径），并映射了Qwen 3.8-27B及重命名为“Quen 4”的模型。在Inference服务端，OpenAI、Ollama及Anthropic接口均已启用。不同应用对URL路径的偏好存在差异：OpenCode使用带/v1的地址，而Claude Code（Anthropic接口）则需使用不带/v1的裸IP端口地址。这种配置细节决定了本地模型能否被正确识别与调用，是跨框架部署的关键技术点。

OpenCode与Inferencer的初始配置对比

本段首先演示了本地AI运行环境的搭建。作者使用名为 Quen 4 experimental 的架构，在 OpenCode 中通过 /models 命令选择模型。虽然平台提供 Muse Spark 1.33 Free Ling 等免费选项，但作者选择了自定义的 Quen 4。当输入“hello”时，OpenCode 首次运行需处理庞大的系统提示词及工具调用指令。数据显示，仅初始化阶段就消耗了 7,800 tokens。相比之下，作者连接 Mac Studio 上的 Inferencer（选择 Quen Flash Next Q9），在禁用工具调用以获取最小上下文的情况下，输入“hello”仅消耗 82 tokens。作者指出：“If you look at the context window for open code, 7,800 tokens... And if you're using clawed code, you know, save yourself 18.4,000 tokens.”（看 OpenCode 的上下文窗口是 7800 token……而使用 Claude Code，你知道能省下 184,000 token。）

启用工具后的上下文开销分析

为了进行公平的代码生成测试，作者必须在 Inferencer 中启用 File Tools（文件读写）、Code Validation（代码验证）及 Web Access（网页内容获取）。启用这些必要工具后，再次输入“hello”，Inferencer 的上下文窗口上升至 2,590 tokens。尽管这比 OpenCode 的 7.8k 和 Claude Code 的 184k 要少，但作者质疑这种“魔法系统提示词”是否真的能提升代码质量。他计划对比无工具、有工具的 Inferencer 以及 OpenCode 和 Claude Code 生成的代码版本，以验证 Harness（运行框架） 是否如传言般能显著提升 AI 的编码能力。

Claude Code与Inferencer视觉推理性能对比

作者展示了 Claude Code 独有的图像推理功能。在 Finder 中拖入一张猫的图片并询问“这是什么”，Claude Code 进行了两次后台生成（一次回答，一次命名会话），耗时 21秒，最终识别为“年轻虎斑猫”。其上下文窗口高达 18.7k tokens。作者讽刺道：“I don't know how this is a trillion dollar company... Like it's just this is a troll, right?”（我不知道这怎么成了万亿公司……就像这是个恶作剧，对吧？）随后在 Inferencer 中执行相同操作（保持工具启用），模型以 35-36 tokens/秒 的速度即时响应，上下文窗口仅为 3,000 tokens。作者强调：“Whereas clawed code 18.7,000 tokens... Are you getting a sense why I do not like harnesses?”（而 Claude Code 是 187,000 token……你明白我为什么不喜欢 Harness 了吗？）

Claude Code 生成井字棋的耗时与交互细节

在测试中，Claude Code 以 33.5 tokens/秒的速度运行。从开始到询问是否创建文件耗时约 3分钟，最终生成该文件总用时为 3分55秒。用户指出应启用“自动接受编辑”功能，因为 AI 会主动发现并修复代码中的 bug。在预览生成的井字棋游戏时，虽然实现了双人及电脑对战模式（含简单、中等、无敌难度），但存在圆圈显示不全的视觉 bug。Claude Code 在交付前主动识别了该错误并询问是否修复，随后进行了更新。

"So, I'm just going to launch in a browser just to see what it's done. Just a sneak preview before it's done its thing."

代码质量验证与上下文窗口消耗对比

在修复过程中，Claude Code 使用了 Node.js对 JavaScript进行运行时检查以确保无错误。最终生成的代码包含游戏机制、胜利判定等完整功能，但上下文窗口消耗高达 28,000 tokens。相比之下，OpenCode 生成相同提示词的代码仅消耗 13,500 tokens，且未进行额外的 lint 或验证步骤。文件体积方面，Claude Code生成的代码为 21 KB（约488行），而 OpenCode 的版本仅为 15 KB。用户推测 Claude Code “喜欢吃 token”，可能与其 API 销售商业模式有关，或者其更深入的验证流程导致了更高的资源消耗。

"So I think CL code likes to eat tokens cuz you know maybe in their business model there is they're about selling new API usage tokens"

Easy Mode Performance and Visual Quality

在对比不同代码生成工具时，作者首先测试了“简单模式”下的表现。他发现 Claude Code 的菜单选项比 OpenCode 更丰富，除了简单和不可能模式外，还增加了中等难度。在 Easy Mode 测试中，Claude Code 生成的圆形阴影存在细微瑕疵，线条略有断裂，但整体完成度较高。相比之下，OpenCode 生成的圆形更加完美。尽管存在细微差别，作者在 Easy Mode 中连续获胜两次，表明该模式下的代码生成质量足以支持游戏逻辑的正常运行。

"I've actually won. So easy mode was actually easy and that's good... the circle in Open Codes version is better."

Native Inference Execution and Token Efficiency

接下来，作者测试了直接通过 Inferenc 运行代码的过程。他启用了工具调用（tool calls），并设置了中等模式，未限制思考深度。与 OpenCode 类似，他要求生成一个令人印象深刻的井字棋游戏并保存至 Quen 文件夹。由于系统提示词已缓存，初始处理仅消耗了 400 tokens。在生成过程中，系统实时显示了每秒生成的 token 数量。值得注意的是，Inferenc 检测到 draw line 函数中存在一个细微 bug，并自动使用 replace text 工具进行了修复。随后，它运行了代码验证以确保 JavaScript 的有效性。

"it's actually saying it noticed a bug inside draw line... and then it's actually saying it passed the HTML validation."

Token Consumption Comparison Across Tools

为了量化不同工具的效率，作者对比了生成相同功能代码所需的 token 总量。数据显示，Inferenc 原生运行仅消耗了 12,000 tokens，且包含了验证步骤。相比之下，OpenCode 消耗了 13,500 tokens，但未执行最终验证；而 Claude Code 消耗了 28,800 tokens，是三者中最慢且最耗资源的。尽管 Inferenc 在 token 效率上表现最佳，但作者指出 OpenCode 未进行文件验证可能是一个潜在风险。

Iterative Code Modification and 3D Cube Addition

最后，作者测试了工具对现有代码的修改能力。他向所有三个系统发送相同提示：“在背景中添加一个像屏保一样弹跳的 3D 立方体”。OpenCode 响应迅速，使用纯 CSS 动画和变换来实现旋转的 3D 立方体背景。它通过 edit tool call 直接替换文件内容，展示了快速编辑的能力。虽然各工具因系统提示词不同而对提示的理解略有差异（如 Inferenc 将其理解为 CSS cube counter space），但 OpenCode 能够准确识别需求并执行代码替换，证明了其在迭代开发中的实用性。

推理服务器配置与并发策略

在启动 Claude Code 之前，视频作者详细解释了本地推理服务器的两项关键功能：多进程（Multiprocessing）与批处理（Batching）。多进程允许不同的模型同时运行，而批处理则让同一个模型并行处理多个提示词。尽管这些功能能提升吞吐量，但作者为了获取原始的单任务速度数据并排除干扰因素，特意禁用了这些特性。此时可以看到服务器上有三个生成队列正在并行运行，每个都在进行预处理。作者强调这种“无借口”的测试方式能真实反映模型在独立工作时的表现，尽管如果有足够内存，用户完全可以利用这些功能来同时运行不同提示词。

代码生成过程与上下文消耗对比

随着任务执行，Claude Code 开始编辑文件并添加逻辑。作者观察到 OpenCode 在生成过程中自我修正，指出之前的编辑“很乱”并试图修复第二个立方体的反弹逻辑。这表明模型在未运行验证前就在思考代码质量。最终，三个任务全部完成，作者对比了它们的上下文窗口（Context Window）消耗：Claude Code 使用了 32,800 tokens，OpenCode 使用 19,500 tokens（比 Claude Code 少约 50%），而 Inference 仅使用 15,000 tokens。数据显示，尽管 Claude Code 功能强大，但其 token 消耗量显著高于其他两个工具。

生成质量评估与无框架直接调用测试

在视觉结果上，Claude Code 生成的 3D 立方体存在随机伪影 bug且未正确反弹，仅悬浮在背景中；OpenCode 生成了两个立方体但形状怪异且遮挡了游戏板，表现好坏参半；Inference 生成的单个立方体颜色变化自然且未破坏原有代码，被作者认为质量最佳。随后，作者进行了“无 AI 框架”测试：直接请求生成 HTML 版井字棋并禁用工具调用。结果仅消耗 5,100 tokens，远低于之前最低的 15,000 tokens。虽然生成的游戏包含音效且功能完整，但缺乏其他版本中的“简单模式”等创意元素。作者总结认为，禁用工具调用能极大节省上下文，但可能限制模型的想象力深度。

上下文窗口消耗与生成质量对比

在视频的后半段，作者展示了使用本地模型进行代码生成的具体数据。当前提示词产生了约 6,500 个 token，加上之前的交互，总上下文窗口达到了 13.5,000 个 token。这一数值显著低于 Claude Code 的 32,000、OpenCode 的 19,000，甚至低于之前启用工具调用时的消耗量。尽管 token 使用效率更高，但生成质量并未受损。

"So our context window in total is 13.5,000 tokens. That's less than clued codes 32,000 less than open codes 19,000"

作者指出，虽然之前的生成中立方体出现了变形或梯形化的问题（如 Claude Code 中的单面漂浮物），但本次生成中立方体呈现为真实的三维结构。这种几何正确性表明，在更低的 token 消耗下，本地模型依然能产出质量相当甚至更好的视觉结果。作者强调，目前只是基础运行，未来可以通过将代码保存至文件并复用该文件来进一步优化智能体逻辑，从而避免上下文窗口的过度膨胀。

第一人称射击游戏的循环修复案例

作为视频的额外奖励内容，作者展示了一个使用 Quen 4 exp（基于 DeepSeek V3.8 Flash）修复第一人称射击游戏 bug 的案例。最初由 DeepSeek 生成的版本存在严重错误，完全无法运行。作者通过构建一个智能循环（agentic loop），让模型反复尝试修复文件编辑中的行号混淆问题。

"I was doing some optimizations to make it a little bit smarter, especially when it's looping."

最终生成的游戏包含了生命值在掩体下自动恢复的机制、精美的开场场景以及光照效果。作者提到，尽管过程繁琐且涉及大量文件编辑，但通过智能循环机制最终成功修复了所有 bug。这一案例证明了本地模型在复杂游戏开发中，通过迭代优化可以实现从“完全损坏”到可玩且具备完整功能的转变。

结论

测试表明，AI Harness在本地运行存在严重的资源效率矛盾。Claude Code虽功能完善且能自动修复Bug，但系统提示词占用高达18,000 tokens，导致上下文窗口膨胀至28,800-32,800 tokens，且生成质量存在视觉瑕疵。相比之下，原生Inference在启用工具后仅消耗12,000-15,000 tokens，不仅效率最高，且生成的3D立方体等视觉质量最佳。OpenCode介于两者之间（13,500-19,500 tokens），但缺乏最终验证步骤。结论是：对于追求极致精确性与资源效率的本地用户，原生Inference优于重型Harness；Claude Code的高开销与其商业API模式相关，不适合算力受限的本地闭环验证场景。