AI

一、AI 代理的重点已经不只是“聊天”

普通大语言模型更多是在对话框中回答问题，而 AI 代理的使用方式明显不同。代理不仅要理解自然语言，还要调用工具、读取文件、执行命令、操作浏览器、控制桌面环境，甚至连接本地服务或外部软件。

在这种场景下，后端模型的角色已经从“聊天模型”变成了“行动系统的大脑”。它需要完成的不只是解释问题，而是持续推进任务：

  • 理解自然语言目标；
  • 拆解任务步骤；
  • 判断当前环境；
  • 选择合适工具；
  • 生成命令或代码；
  • 读取执行结果；
  • 发现错误并修正；
  • 在长任务中保持目标一致。

因此，选择 AI 代理后端模型时，不能只看聊天效果，也不能只看价格。真正重要的是：模型是否适合作为代理的大脑，是否能够稳定地与工具、终端、脚本、接口和真实系统配合。

二、Codex 的价值：强的不只是模型，而是一整套代理体验

Codex 类模型之所以适合 AI 代理，并不是因为它只会写代码，而是因为它比较适合真实操作环境。

在实际使用中，AI 代理经常会遇到这些情况：

  • 文件路径不确定；
  • 配置文件格式复杂；
  • 命令执行后出现报错；
  • 日志输出很长；
  • 工具权限不足；
  • 系统环境和预期不一致；
  • 任务中途需要改变方案；
  • 多轮执行后仍要记住原始目标。

普通聊天模型在这种场景中容易出现两个问题：
一是给出看似合理、实际不可执行的建议；二是任务一长就丢失上下文，开始偏离目标。

Codex 类模型的优势在于，它更擅长在“边执行、边观察、边修正”的过程中工作。它不只是回答“应该怎么做”，而是更接近于真正帮助完成任务。

这也是为什么在 OpenClaw 这类代理工具中，Codex 往往能给人一种“真的能干活”的感觉。

三、为什么需要寻找 Codex 的替代或补充模型

虽然 Codex 类模型很好用，但 AI 代理的 Token 消耗非常大。

普通聊天中，一次问答可能只消耗少量上下文；但代理任务不同。代理需要不断读取环境信息、工具结果、命令输出、文件内容和错误日志。每一次观察、计划、执行和修正都会消耗 Token。

尤其是下面这些任务，消耗会非常明显：

  • 本地项目代码修改；
  • Linux 系统配置；
  • 服务状态检查；
  • 网页搜索与整理；
  • 长日志分析；
  • 自动化脚本生成；
  • 多轮失败修正；
  • 游戏或外部软件控制；
  • 长时间持续运行的代理任务。

因此，如果完全依赖高价或有限额度的模型，长期使用成本会比较高。
这就引出了一个现实问题：

是否存在更便宜、可以接入 OpenClaw、又能在一定程度上接近 Codex 的模型？

围绕这个问题，可以重点关注 DeepSeek、Qwen、GLM、MiniMax、Kimi 等模型或平台。

四、便宜模型和 Codex 级模型不是一回事

在选择模型时，需要先区分两个概念：

  1. 低成本模型
  2. Codex 级代理模型

这两个概念不能混在一起。

低成本模型可能非常适合做批量摘要、文本整理、关键词提取、网页内容归纳、简单命令生成等任务。但这并不代表它适合复杂代码修改、长程代理执行和多轮错误修复。

相反，真正接近 Codex 的模型通常要具备这些能力：

  • 较强代码理解能力；
  • 较强工具调用意识；
  • 能够处理较长上下文；
  • 能够分阶段规划；
  • 能够根据执行反馈修正方案；
  • 不容易在多轮任务中跑偏；
  • 能够理解真实项目结构和系统环境。

因此，评估模型时不能只看“每百万 Token 多少钱”，也要看它能不能在代理环境中稳定完成任务。

便宜模型可以当副模型、消耗型模型、低风险任务模型；
强模型才适合当主力代理大脑。

五、DeepSeek：最值得优先测试的 Codex 替代候选

在可选模型中，DeepSeek 是一个非常值得优先测试的方向。

它的优势主要在于：

  • 成本相对较低；
  • 接口生态比较友好；
  • 适合接入 OpenAI-compatible API 风格的代理工具；
  • 可以作为 OpenClaw 后端模型；
  • 在代码、推理、长上下文、工具调用方面具备一定竞争力；
  • 适合作为 Codex 不够用时的补充或替代方案。

但 DeepSeek 也要分层使用。
不同档位的模型适合不同任务。

1. DeepSeek Flash 类模型

Flash 类模型更适合低成本日常任务，例如：

  • 网页整理；
  • 简单脚本；
  • 日志初步分析；
  • 文件分类；
  • 配置片段解释；
  • 命令草稿生成；
  • 低风险自动化操作。

它的优势是便宜、快、适合消耗型任务。
但如果任务涉及复杂代码、多轮修正、系统级变更，Flash 类模型未必足够稳。

2. DeepSeek Pro / Thinking 类模型

更强的 DeepSeek 模型适合承担更接近 Codex 的任务，例如：

  • 修改复杂代码；
  • 排查系统错误；
  • 编写多文件脚本；
  • 分析较长日志；
  • 生成结构化执行方案；
  • 与 OpenClaw 工具配合完成多轮操作；
  • 处理更复杂的自动化目标。

因此，DeepSeek 不是简单地“能不能替代 Codex”，而是要看具体任务。
对于日常代理任务，它很有价值；对于高难度长程编码任务，它可以作为强候选，但仍需要通过实际任务测试。

比较稳妥的使用方式是：

  • 普通任务用低价模型；
  • 复杂任务切换到更强模型；
  • Codex 可用时继续作为主力；
  • DeepSeek 作为备用和补充。

六、Qwen、GLM、MiniMax、Kimi 的不同定位

除了 DeepSeek，还有几条值得考虑的路线。

1. Qwen / 阿里百炼

Qwen 系列模型的优势在于选择多、价格层级丰富、生态成熟。
Flash 类模型适合做低成本副模型，尤其适合摘要、分类、抽取、简单文本处理和低风险自动化步骤。

如果目标是“便宜地给代理烧 Token”，Qwen 低价模型很适合作为辅助模型。
但如果目标是复杂代码代理，就不能只看最低价，而要选择更偏代码或更强能力的模型。

2. GLM

GLM 的优势在于对 coding agent、long-horizon agent、OpenClaw / Claude Code 类工作流有较明显的定位。

如果目标是寻找接近 Codex 使用体验的国产模型，GLM 值得测试。
不过需要注意，某些 coding plan 或套餐可能不是普通通用 API 余额，而是只适用于特定工具、特定 endpoint 或特定客户端。

购买前需要确认：

  • 是否支持 OpenAI-compatible API；
  • 是否能接入 OpenClaw；
  • 是否支持工具调用；
  • 是否限制使用方式；
  • 是否适合本地代理长期运行。

3. MiniMax

MiniMax 在 agentic model、coding、工程任务方面也值得关注。
它不一定是最低价路线，但可以作为代码代理和复杂自动化任务的候选模型。

如果 DeepSeek 和 Qwen 在某些任务上不够稳，可以再测试 MiniMax。

4. Kimi

Kimi 的长上下文能力和复杂任务处理能力比较强，适合长文档、长代码和复杂推理。
但从成本角度看，Kimi 未必是最便宜的选择。它更适合作为低价模型无法胜任时的强力候补，而不是一开始就作为大量消耗 Token 的基础模型。

七、推荐的模型组合策略

AI 代理模型选择不适合一次性押注。
最稳妥的方式是分层使用。

可以设计成这样的组合：

Codex：高质量主力任务
DeepSeek Pro / Thinking：Codex 不够用时的强替代
DeepSeek Flash / Qwen Flash：低成本日常任务
GLM / MiniMax / Kimi：后续进阶测试候选

这样的好处是：

  • 不会把所有任务都压在一个模型上；
  • 成本更可控；
  • 简单任务不浪费强模型额度；
  • 复杂任务仍有高能力模型兜底；
  • 可以根据实际体验慢慢调整主力模型。

真正的评估标准不是宣传页面，也不是单一跑分，而是代理在真实任务中的表现：

  • 是否能正确理解目标；
  • 是否会选择合适工具；
  • 是否能生成可执行命令；
  • 是否能识别执行错误；
  • 是否能修复问题；
  • 是否会破坏已有环境；
  • 是否能保持长任务一致性；
  • Token 成本是否可接受。

八、AI 代理控制本地软件：模型只是其中一部分

在讨论 AI 模型时，很容易过度关注模型本身。
但在 AI 代理系统里，模型只是其中一层。

一个真正可用的 AI 代理系统，至少需要四部分：

模型
工具
权限
工作流

模型负责思考；
工具负责执行；
权限决定能执行什么；
工作流决定是否安全、稳定、可恢复。

如果工具没有暴露给代理，再强的模型也只能猜。
如果权限不足，模型知道该怎么做也无法执行。
如果工作流混乱，模型可能会在复杂任务中越做越乱。

因此，模型选择和工具接入必须一起考虑。

九、OpenClaw 说“只能截图判断”意味着什么

在使用 OpenClaw 控制图形界面或游戏时，可能会遇到一种情况：代理表示自己只能通过截图判断当前状态。

这并不一定说明 OpenClaw 理论上只能截图。
更准确地说，是当前会话中暴露给它的工具能力有限。

如果 OpenClaw 只能看到截图工具、鼠标工具和键盘工具，那么它自然会像普通人一样：

  • 看画面；
  • 判断大概情况；
  • 移动鼠标；
  • 点击；
  • 输入文字；
  • 再看截图确认。

这种方式可以工作，但效率低、稳定性差。
尤其面对游戏、复杂软件、命令接口和模组能力时，只靠截图远远不够。

如果希望 OpenClaw 真正控制本地软件，就需要把软件能力包装成工具，让代理能够直接调用。

例如对于 Minecraft 这类场景，不能只让代理看截图，还应该暴露：

  • 执行游戏命令的工具；
  • 调用 WorldEdit 的工具；
  • 查询玩家坐标的工具；
  • 查询方块区域的工具；
  • 获取服务端日志的工具；
  • 截图确认工具；
  • 执行本地脚本的工具。

这样，代理就不再是“看图猜测”，而是可以直接操作游戏状态。

十、Minecraft 场景的意义：测试 AI 代理能力，而不是单纯玩游戏

Minecraft 自动建造只是一个测试场景。
它的价值不在于某一个具体建筑，而在于验证 AI 代理能否完成一个多步骤、可观察、可执行、可修正的任务。

在这个场景中，AI 代理需要：

  • 理解自然语言目标；
  • 根据环境做规划；
  • 调用工具执行命令；
  • 根据截图或日志确认结果；
  • 发现错误后修正；
  • 分阶段推进任务。

这正好可以测试模型作为代理大脑的能力。

因此，Minecraft 场景并不是文章重点本身，而是一个典型例子：
它说明了为什么模型能力、工具接口、权限设计和工作流都很重要。

十一、不要让 AI 只靠鼠标键盘玩游戏

如果 AI 代理控制 Minecraft，只靠鼠标键盘会很低效。

例如让代理模拟人类操作：

看截图
移动鼠标
按键盘
打开聊天框
输入命令
确认画面
继续操作

这种方式虽然直观，但问题很多：

  • 窗口焦点可能错误；
  • 输入法状态可能影响命令；
  • 鼠标点击位置可能偏移；
  • 截图判断可能不准确；
  • 执行速度慢；
  • 无法稳定读取游戏内部状态；
  • 大规模建造效率极低。

更好的方式是：

截图用于观察
命令用于执行
接口用于控制
日志用于确认
模型用于规划

也就是说，AI 不应该像人一样一格一格放方块，而应该像建筑规划者和调度系统一样，通过命令、脚本和接口完成任务。

十二、本地 Minecraft 自动化的推荐架构

如果要在本机运行 Minecraft，并让 OpenClaw 控制它，比较合理的架构是：

OpenClaw + 后端模型
        ↓
本地控制工具 / MCP 工具 / 脚本
        ↓
RCON / 命令接口 / WorldEdit / 模组能力
        ↓
本机 Minecraft 服务端
        ↓
Minecraft 客户端连接 localhost 观看画面

在这个架构中：

  • OpenClaw 负责协调；
  • 模型负责思考；
  • 本地工具负责执行；
  • Minecraft 服务端负责承载世界；
  • 客户端负责显示画面；
  • 截图负责阶段性确认。

这样做的体验仍然是本地游戏，不需要公网，也不需要远程服务器。
但从技术结构上，服务端和客户端分离，AI 代理可以通过服务端接口更稳定地控制世界。

十三、普通单人世界与本地服务端的区别

一个关键问题是：如果只运行普通单人世界，能不能使用 RCON？

通常情况下，普通单人世界不适合作为 RCON 控制对象。
RCON 是 Minecraft 独立服务端的功能，一般通过 server.properties 配置，例如：

enable-rcon=true
rcon.port=...
rcon.password=...

如果只是通过启动器进入普通单人游戏，通常没有一个稳定可配置的 RCON 服务端口供外部代理连接。

因此，如果目标是让 OpenClaw 稳定执行命令，更推荐在本机启动一个独立 Minecraft 服务端，再用客户端连接：

localhost

这样对使用者来说仍然是本地运行，但技术上更适合自动化。

普通单人世界适合手动游玩；
本地服务端更适合 AI 代理控制。

十四、本地运行时的端口和防火墙问题

如果所有东西都只在本机运行，就不需要考虑公网访问。

理想情况下，相关服务都只监听：

127.0.0.1
localhost

例如：

  • Minecraft 客户端连接本机服务端；
  • OpenClaw 通过本机 RCON 连接 Minecraft 服务端；
  • 本地 MCP 工具调用本机脚本；
  • 截图和日志都在本机完成。

这种情况下，一般不需要向公网开放端口，也不需要让局域网其他设备访问。
防火墙通常主要关心外部进入本机的连接，而 localhost 回环访问通常不需要像公网服务那样开放端口。

但安全原则仍然要明确：

只监听 localhost
不绑定 0.0.0.0
不做端口转发
不暴露 RCON
不开放公网
不让局域网随意访问

如果确实需要局域网访问，再单独考虑防火墙规则。
但对于本地 AI 自动化实验，最稳妥的方式是全部限制在本机。

十五、WorldEdit / 创世神模组的作用

Minecraft 建造任务如果只靠普通命令，效率仍然有限。
WorldEdit 或创世神类模组的价值在于，它们可以高效完成大范围编辑：

  • 批量填充方块；
  • 替换区域；
  • 复制粘贴结构；
  • 生成墙体、地面、屋顶；
  • 调整地形；
  • 保存和加载结构；
  • 快速撤销部分操作。

对于 AI 代理来说，这类模组非常重要。

如果代理能够调用 WorldEdit 命令，它就不需要像玩家一样慢慢摆放方块，而是可以：

先规划区域
再批量执行
然后截图确认
最后局部修正

这才是 AI 自动建造最有效率的方式。

十六、MCP 工具与本地控制脚本

要让 OpenClaw 使用 Minecraft 的能力，最好不要让它直接乱敲命令，而是封装一层本地工具。

例如提供一个本地控制工具：

mcctl

它可以支持：

mcctl say "OpenClaw connected"
mcctl cmd "time set day"
mcctl cmd "weather clear"
mcctl cmd "fill x1 y1 z1 x2 y2 z2 stone"
mcctl worldedit "//set oak_planks"
mcctl screenshot
mcctl log

进一步可以包装成结构化工具：

minecraft.run_command
minecraft.run_worldedit
minecraft.get_player_position
minecraft.take_screenshot
minecraft.read_server_log
minecraft.query_area
minecraft.build_from_blueprint

这样 OpenClaw 调用工具时，就不是靠猜测，而是有明确接口。

MCP 的作用就是把这些本地能力注册成代理可见、可调用的工具。
一旦工具注册成功，模型就可以根据任务需要选择调用它们。

十七、Minecraft Skill 的必要性

仅有工具还不够，还需要告诉代理如何使用这些工具。
这就需要一个专门的 Minecraft Skill。

Skill 可以写明规则：

这是 Minecraft 自动化任务。
优先使用 RCON、WorldEdit、命令接口和本地脚本。
截图只用于观察和确认，不作为主要操作方式。
不要优先使用鼠标键盘。
大面积修改前必须先规划。
不要修改未知区域。
不要破坏正式存档。
每个阶段后写日志。
高风险操作前暂停确认。

有了这样的 Skill，OpenClaw 才会更像一个懂规程的自动化助手，而不是只会看截图乱点的模型。

Skill 的价值在于给代理建立工作习惯。
它并不直接提升模型智商，但能显著提升任务稳定性。

十八、最小可行闭环

在真正做复杂任务前，应该先建立一个最小可行闭环。

例如：

自然语言指令
    ↓
OpenClaw 理解目标
    ↓
调用本地 Minecraft 工具
    ↓
服务端执行命令
    ↓
客户端画面变化
    ↓
截图确认
    ↓
日志记录

第一个测试任务可以非常简单：

让 OpenClaw 在 Minecraft 中执行一条 /say 命令，
然后执行一个小范围 /fill，
再截图确认结果。

这个闭环比任何大型目标都重要。
只要闭环成功，后面无论是自动建造、自动整理地形，还是更复杂的游戏内实验，都是规模扩大和流程优化的问题。

十九、模型选择与工具架构要分开判断

在这个讨论中，一个容易混淆的点是：模型能力和系统能力不是同一件事。

DeepSeek、Codex、Qwen、GLM、MiniMax、Kimi 决定的是“代理的大脑”。
OpenClaw、MCP、RCON、WorldEdit、脚本、权限配置决定的是“代理的手脚”。

如果只有强模型，没有工具，代理只能建议。
如果有工具但模型太弱，代理可能乱用工具。
如果模型和工具都有，但没有规则，代理可能破坏环境。
如果三者配合良好，代理才能真正完成任务。

一个稳定的 AI 代理系统应该是：

强模型负责复杂判断
低价模型负责日常消耗
工具接口负责可靠执行
Skill 负责工作规程
日志和截图负责反馈
权限边界负责安全

二十、实际购买与使用建议

在购买模型 API 或套餐时，建议避免一开始就重度投入。

更稳妥的路线是：

  1. 先尝试恢复或重置现有 Codex；
  2. Codex 可用时继续作为高质量主力；
  3. 如果额度不足，再小额购买 DeepSeek；
  4. 先用真实 OpenClaw 任务测试；
  5. 根据任务表现决定是否长期使用；
  6. 再考虑 Qwen、GLM、MiniMax、Kimi 等候选模型。

不要只看模型宣传，也不要只看榜单。
代理任务中的真实表现才是关键。

尤其要观察：

  • 是否会正确使用工具；
  • 是否会反复犯同类错误；
  • 是否能读懂命令输出；
  • 是否会破坏已有文件；
  • 是否能保持安全边界；
  • 是否能在多轮任务中不跑偏；
  • 是否能以可接受成本完成任务。

二十一、最终结论

AI 代理的核心不是单一模型，而是：

模型 + 工具 + 权限 + 工作流

Codex 的优势在于整体代理体验强，适合作为主力。
DeepSeek 是非常值得测试的低成本强候选，适合在 Codex 不够用时作为补充或替代。
Qwen 低价模型适合做副模型和消耗型任务。
GLM、MiniMax、Kimi 可以作为更强代理能力的后续候选。

对于本地自动化实验，尤其是控制 Minecraft 这类软件，最重要的不是让 AI 像人一样盯着屏幕点鼠标，而是把本地能力暴露成工具：

截图负责观察
命令负责执行
接口负责控制
日志负责反馈
模型负责思考
OpenClaw 负责协调

如果只给代理截图和键鼠，它就只能像普通人一样慢慢操作。
如果给它 RCON、WorldEdit、本地脚本、MCP 工具和专用 Skill，它就可以成为真正的本地自动化执行系统。

这也说明了 AI 代理发展的关键方向：
未来真正有价值的并不是单纯“模型会说什么”，而是模型能否在真实环境中稳定地调用工具、理解反馈、修正错误，并持续完成任务。

Leave a Reply

Your email address will not be published. Required fields are marked *