同样是 Sol,"油耗"却差一倍?AI 拼的不只是"大脑",更是"外围装备"

5 秒结论: 就算用的是同一个模型,每次往上下文里塞什么、调用模型多少次、带着多少工具返回结果、在哪里做压缩,消耗量都可能差得很大。如果说模型是发动机,那 Codex、OpenCode 这类"套件"(业内叫 harness)就是变速箱、喷油系统、导航和维修师傅的总和。发动机一样,油耗未必一样。

1. "同样的 5 小时额度,居然能干双倍的活"——先说清楚,这是个人体验,不是评测

有位开发者在社交平台上发帖说:他从 Codex 换成 OpenCode,用 ChatGPT 账号登录,跑的还是同一个 GPT-5.6 Sol,结果在同样的 5 小时额度和每周额度里,感觉能多干一倍以上的活。

评论区里,有人推荐另一个套件 pi,有人怀疑是上下文上限的设置不一样,也有人想通过路由器或遥测数据(记录使用情况的数据)看看实际消耗。

这里最关键的一点是:没有人证明过"用 OpenCode 官方就能多用一倍"。这是个值得重视的观察,但并不是控制变量的对比实验。

另一方面,OpenAI 对 Codex 用量的说明是:不按固定的消息条数计算,而是随模型、任务在哪里运行、复杂程度、上下文、推理、速度、工具等因素而变化。部分套餐同时有 5 小时额度和每周额度。

所以,"换了套件之后油耗变了"这件事本身,从原理上看相当正常。

2. 套件(harness)到底是什么——AI 本体之外的"所有东西"

只看模型的话,事情很简单。

Sol = 大脑。

但真正的编程智能体,大脑周围还围着一大堆设备:

• 系统指令(system instruction)怎么编排
• 读哪些文件
• 保留多少 token 的历史对话
• 向模型展示多少个工具,比如命令行、GitHub
• 工具输出(tool output)带到下一轮多少
• 失败后重试几次
• 规划、实现、审查各转几圈
• 在上下文溢出之前要不要压缩
• 要不要拆给子智能体(subagent)
• 什么时候判定"做完了"

这一整套东西,就是广义上的 harness。

OpenAI 自己在介绍 Codex 时也用了"harness"这个词,用来说明连接模型与各个客户端、工具、对话状态的 App Server。

所以,

模型相同 ≠ 整个系统相同。

就像同样装 V8 发动机,2 吨重的 SUV 和轻巧的车身,油耗不可能一样。

3. 拖垮 AI 油耗的元凶,多半是"每一轮都得扛着走的行李"

智能体的消耗量,可不是简单看"回复写了多少字"。

在很长的会话里,每次推理都会带上:

• 很长的对话历史
• 庞大的 system prompt
• AGENTS.md 和各种规则
• MCP 的工具定义(tool schema)
• 从 GitHub 读来的大量文件
• 命令行的超长日志
• 测试结果
• 过去的失败记录
• 下次重试要用的信息

只带一次的话很轻。

问题在于,这些东西要重发、重新理解 10 次、20 次、30 次。

比起"读了 100KB 的日志",扛着 100KB 级别的上下文反复调用模型,影响往往更大。

再比如,套件 A 用 15 轮就把一项任务做完,而套件 B 走"规划→确认→探索→再探索→审查→再审查",用了 30 轮,那么哪怕模型相同,差距也是理所当然的。

油耗不光取决于发动机性能,而是被

行李 × 往返次数 × 重试次数

拖垮的。

4. OpenCode 有意思在哪——ChatGPT 登录、MCP、压缩装在同一个盒子里

按 OpenCode 官方文档,连接 OpenAI 时可以选 ChatGPT Plus/Pro,在浏览器里完成认证。这条路径和手动输入 API 密钥是分开的。

另外,OpenCode 作为 MCP 客户端,本地 MCP 和远程 MCP 都能添加。

也就是说可以搭出这样的结构:

OpenCode → GitHub MCP → 数据库 MCP → 自己的 API → 其他外部工具

OpenCode 还有自动压缩(compaction)功能,会把长会话里较旧的活跃上下文换成一个"存档点"。现行文档里,自动压缩默认开启,并给出了保留生成的摘要加上最近大约 15,000 token 的配置示例。

这与其说是"删掉旧对话",不如说更像是:

仓库里留着全部历史,下次出击只装必要的行李

这样的设计。

不过它也不是万能的。OpenCode 自己就提醒过:MCP 服务器接得越多,工具定义等内容占用的上下文就越多,尤其是 GitHub MCP 这种体量大的,很容易把上下文挤满。

接了 20 个 MCP 还自以为"这下无敌了",就好比让勇者把整座仓库都穿在身上。

5. 从 ChatGPT 通过 MCP 操控一切,思路其实也差不多

把 ChatGPT 放在中央,经由 MCP 或外部连接器去操作 GitHub、服务器、云、存储等等,这种结构本质上同样是"模型 + 套件 + 工具"。

画成接线图很简单:

ChatGPT → MCP / 连接器 → GitHub、服务器、云、存储

ChatGPT 负责判断,MCP 充当手脚,各个服务保存着现实世界一侧的状态。

OpenCode 也是同样的道理:

OpenCode → MCP / 命令行 / API → 代码仓库、服务器、云

区别在于:对话状态放在哪里,工具循环(tool loop)在哪里跑,上下文在哪里压缩。

所以对于"这和从 ChatGPT 用 MCP 操控一切是不是一回事?"这个问题,答案基本是肯定的。

同一种建筑思路,只是指挥室的产品名不同。

6. 那么,能不能从 ChatGPT 把活儿丢给 OpenCode?

OpenCode 官方明确支持"作为使用 MCP 的一方"。不过,我引用的官方文档里,并没有把 OpenCode 本身直接做成通用 MCP 服务器的模式,明确给出的入口是 HTTP/OpenAPI 服务器加 SDK,或者 ACP。

用 opencode serve,可以把 OpenCode 以无界面(headless)的 HTTP 服务器形式启动,通过 OpenAPI 用程序控制会话和智能体。也有 JS/TS SDK。

所以,如果想从 ChatGPT 那边把活儿交给 OpenCode,比较干净的结构是这样的:

ChatGPT → 轻薄的 MCP 桥接层 → OpenCode Server → Sol → MCP / 命令行 / API → GitHub、云等

MCP 桥接层对外提供的工具,可以少到极致:

• opencode_run_task
• opencode_get_status
• opencode_get_result

这三个就够了。

不用每次把 GitHub 的几十个工具定义和巨大的日志带进 ChatGPT 这一侧,漫长的实际工作都在 OpenCode 里完成,最后只把结果送回来。

到了这一步,"改善油耗"才算成了一种设计。

7. 真想降低消耗,比起少用 AI,更要减少"回头找 AI"的次数

最常见的失误,就是以为换个便宜的模型就能解决一切。

模型选择当然有用。

但在长时间的自动化作业里,更管用的是下面这种分工:

1. 确定性的处理交给脚本
2. 状态(state)和回执(receipt)由机器一侧保存
3. 只启用需要的工具
4. 超长日志先摘要、提取,再交给模型
5. 同一个文件不要反复重读
6. 把失败原因和下一步行动(next action)存成状态
7. 只有模糊的判断才交回给高性能模型
8. 只把最终的线上环境回读确认(production readback)交还给人

理想的状态是:

AI = 负责处理模糊性的角色

脚本 / 工作流 = 负责跑确定流程的角色

GitHub / 数据库 / 状态 = 负责记忆的角色

如果每次都让 AI 去想"接下来要干嘛来着?",那每一次都要把仓库重新盘点一遍。

要是让机器提前写好 nextAction,AI 就只在需要的时候才叫出来。

8. 不过,"用 OpenCode 同样额度就一定更划算",目前还说不上

从 OpenAI 官方能确认的是:Codex 和 Work 共用同一份使用额度,按套餐有 5 小时额度和每周额度,而且用量会随上下文、工具等因素而变化。

从 OpenCode 官方能确认的是:可以使用 ChatGPT Plus/Pro 认证。

但是,经由 OpenCode 的 ChatGPT OAuth 使用,在 OpenAI 一侧是否按与 Codex 完全相同的计量公式、相同的内部系数来消耗,以及用 OpenCode 到底总能划算多少倍,这样的对比表,双方的官方资料里都没有。

因此,

"跑了双倍"是一份有意思的实测报告。

"一定能跑双倍"则是未经确认的。

这两件事最好别混在一起。

真要比较的话,要在同一个仓库、同一个模型、同一项任务、同一个结束条件下,记录:

• 模型调用总次数
• input/output token
• 压缩次数
• 工具调用次数
• 实际耗时(wall-clock time)
• 完成的改动数量
• 重试次数
• 最终测试结果

看的不是"用了几个小时",而是每完成一项成功任务消耗了什么。

那才是真正的油耗。

9. 结论——AI 时代,选完模型之后最管用的是"接线"

以前,话题的中心是"哪个模型最聪明"。

到了智能体时代,光看这个不够了。

即便是同一个模型,

• 上下文怎么塞
• 工具有几个
• 状态管理
• 压缩
• 重试
• 结束判定
• 与外部工作流怎么分工

这些不同,都会让完成的工作量不一样。

模型是发动机。

套件则是把喷油系统、变速箱、导航、维修站团队,乃至后备箱容量全都打包在一起的整套系统。

所以"明明是同一个 Sol,怎么差这么多?"反倒是一个很自然的疑问。

而当你开始用 MCP 把多个服务连起来的那一刻,你做的事情就已经从"使用 AI"变成了

围绕 AI 设计一个工作场所。

最后说句最扎心的实话:最强的 MCP,不是"什么都问 AI"。

而是增加那些不必问 AI 的环节。

参考资料

• OpenAI, Unlocking the Codex harness: how we built the App Server https://openai.com/index/unlocking-the-codex-harness/
• OpenAI Help Center, 使用 ChatGPT 套餐里的 Codex https://help.openai.com/ja-jp/articles/11369540
• OpenAI Help Center, 在 Work 和 Codex 中管理 GPT-6 Astra 的用量 https://help.openai.com/ja-jp/articles/20001516-managing-usage-with-gpt-6-astra-in-work-and-codex
• OpenCode Docs, Providers https://opencode.ai/docs/providers
• OpenCode Docs, MCP servers https://opencode.ai/v2/docs/mcp-servers
• OpenCode Docs, Compaction https://opencode.ai/v2/docs/compaction
• OpenCode Docs, Server / SDK https://dev.opencode.ai/docs/server/ https://dev.opencode.ai/docs/ja/sdk/
• OpenCode Docs, ACP https://opencode.ai/v2/docs/cli/acp/