几家编码套餐（Coding Plan）与运行环境（Harness）的使用体验对比——环境篇

AI, Claude, Coding Agent, Cursor, LLM, 中文 Comments

笔者在上一篇文章中已经介绍了各个编码套餐（Coding Plan）支持的模型、上下文长度、视觉能力等方面的差异，本文主要着重于这些编码套餐在各个运行环境（Harness）中的差异和对应的能力补齐方案。

在公司的支持和各种大语言模型供应商、云厂商的活动的优惠下，从 2025 年 10 月至今，按照时间顺序，笔者主要尝试了以下几款编码套餐：

  • Claude Code 订阅（Anthropic 官方的 20 刀月度订阅，还使用了大约 1000 刀按需付费的额度）
  • Cursor Pro 订阅（20 刀月度订阅）
  • 智谱 Z.ai GLM 的 Coding Plan（用的是轻量版，做活动时候入的年度套餐，实付 192 元，折合一个月 16 元）
  • Google 的 Antigravity 提供的 Gemini 系列（主要是免费额度，偶尔体验一下，没有付费）
  • OpenAI 的 Codex（主要是免费额度，偶尔体验一下，没有付费）
  • 阿里云百炼的 Coding Plan（首月 2 折的 200 元人民币套餐，实付 40 元）
  • 联通元景 MaaS 平台的 Coding Plan（49 元人民币套餐，首月 30 元）
  • 联通云的 Coding Plan（首月免费，后续应该是 40 元每月）

这些编码套餐大部分时间都是在 Claude Code 这个 Harness（此处以及之后翻译成“运行环境”）中使用的，因此本文也会主要以 Claude Code 为主进行对比分析，正巧 2026 年 3 月的最后一天，Claude Code 因为上传 source map 到 npm 仓库而导致源码泄漏，这就为本文中原本的假设提供了更为具体和确切的验证条件。

除此之外，笔者还尝试了 OpenAI 的 Codex App、Google 的 Antigravity、OpenCode 及其衍生的一系列工具，至于其他运行环境，还没有来得及一一体验。但也算是体验了最具代表性的几个运行环境了（此处可以有 Moonshot Kimi CLI、Qwen Coder 等的广告位，欢迎通过 GitHub sponsorships 或者 Coding Plan 套餐赞助笔者）。

现在主流的运行环境都拥有一套系统提示词（System Prompt）、工具发现与调用架构（包括 MCP 和插件系统）、上下文管理与压缩、钩子（Hooks）和子 Agent 支持。本文不打算讨论老生常谈的系统提示词工程等内容，而是主要从运行环境的工具支持这方面来进行对比分析，包括原生内建的工具、工具调用架构、工具支持情况等：先说一些比较通用的情况，然后再针对各个运行环境各自的问题进行讨论。

各式各样的 MCP

MCP（Model Context Protocol）是模型上下文协议，是一种用于在模型和应用程序之间传递上下文信息的协议。它允许模型在执行任务时访问外部工具和数据，从而实现更复杂的任务。MCP 协议定义了一套标准化的接口和格式，使得不同的模型和应用程序可以相互兼容和交互。

有些 MCP 是用户想安装的，有些则是因为模型能力限制、用户不得不安装的——这一点尤其在 Claude Code 中使用一些国产模型的时候体现得比较明显，因为 Claude Code 这一环境本身是为了 Anthropic 的模型设计的，所以有一些假设，比如：

  • 视觉能力是原生的
  • 网络内容访问能力（包括 WebFetch 和 WebSearch）是通过 API 端点的服务器工具（Server tool）来支持的

而在没有原生视觉能力的情况下，就需要额外的 MCP 来补全这一短板，我称之为“能力补全的 MCP”，这里就以 Claude Code 为主，来详细介绍一下各家是如何补全各种能力的。

视觉能力补全

视觉能力是除了 Kimi 模型和阿里云百炼的 Qwen 系列之外，其他模型都不支持的，因此需要额外的 MCP 来补全这一短板。但是各家也有各家的策略，比如。

GLM 4.7 和 GLM-5 这两个主力模型是不支持视觉能力的（当然，近期 GLM-5.1V 也支持了原生视觉能力），在智谱 Z.ai 的模型列表里提供了类似于 GLM-4.6V 这样的视觉增强模型，并通过 MCP 服务来为 GLM-4.7 和 GLM-5 提供视觉能力，这个 MCP 甚至是不需要配置、直接可以通过 Anthropic 兼容的 API 端点的 image 参数格式直接来使用的，这点非常神奇，也是 GLM 非常方便、显得智谱非常聪明的一个地方（会放在 WebFetch 工具详细说这一点）。但是 Lite 套餐限制每个月 100 次 MCP 的总调用，超过这个限制就需要付费购买了，还是十分受限的，也许这也是为什么他们设计了不需要配置就可以使用的原因吧，毕竟也是一种收费手段。

MiniMax 的 M2.5 和 M2.7 也是支持视觉能力的，需要配置这样一个 MCP 服务器：

1
claude mcp add -s user MiniMax --env MINIMAX_API_KEY=api_key --env MINIMAX_API_HOST=https://api.minimaxi.com -- uvx minimax-coding-plan-mcp -y

配置之后，就可以直接通过 MiniMax 的 MCP 服务器来使用视觉能力了，虽然需要配置，但是文档没有说明需要额外收费，也还是十分方便的。

Kimi 的 K2.5 模型是支持视觉能力的，所以不需要配置，无论是 Kimi 自己的 API 端点还是阿里云百炼的 API 端点，都是支持直接通过 Anthropic 兼容的 API 端点的 image 参数格式直接来使用的。但是除了 Qwen3.5 Plus 之外，阿里云百炼的端点还提供了 GLM-4.7 和 GLM-5 等的不支持视觉能力的模型，因此就需要额外的配置，他们给出的解决方案是配置一个 Skill，来用 qwen3.5-plus 模型进行图片描述：

1
2
3
4
5
6
---
name: image-analyzer
description: 帮助没有视觉能力的模型进行图像理解。当需要分析图像内容、提取图片中的信息、文字、界面元素，或理解截图、图表、架构图等任何视觉内容时，使用此技能，传入图片路径即可获得描述信息。
model: qwen3.5-plus
---
qwen3.5-plus具有视觉理解能力，请直接使用qwen3.5-plus模型进行图片理解。

然后再喂给当前的模型使用，也是十分机智了。

网络搜索（WebSearch）能力补全

在 Claude Code 中，网络搜索能力是原生的、通过 Anthropic 的 API 端点的服务端工具来支持的（看 Claude Code 源码中也证实了这一点，是使用类似于 web_search_<date> 这样的服务端工具来支持的），但是其他模型供应商的端点并不总是支持，因此也需要额外的 MCP 来补全这一短板。

各家对这一工具的处理和配置方法上面视觉能力补全类似，除了 GLM 这边非常聪明地桥接了 web_search_<date> 这样的服务端工具到他们的 MCP 服务用来按月计量（当然，对于用户本身来说这点就很尴尬了）。

网络内容访问（WebFetch）能力补全

在最近版本的 Claude Code 中，网络内容访问工具（WebFetch）分为两步：

  1. 首先通过本机浏览器访问目标网站，获取到网页内容；
  2. 然后通过 Claude Code 的 API 端点将网页内容发送到一个小模型（写死的类似于 claude_haiku_<version>_<date> 这样的模型 ID）中，获取到网页内容的摘要，再把总结的内容发回给当前在使用的模型。

这里就有了处理方式的不同：

  • MiniMax 的 API 端点会自动处理模型的映射，就算是写死的小模型，也会自动映射到 MiniMax 的模型中，从而将总结内容发回给当前在使用的模型。
  • 阿里云百炼的 API 端点由于提供了各家不同的模型，必须设置一个模型参数、并且匹配对应的模型 ID，使用时没什么问题，但是到了 WebFetch 第二部这里，就会提示不支持的模型 ID 参数，导致 WebFetch 无法正常使用。这里我建议阿里云的工程师映射一个默认模型到任意模型 ID 参数上，从而让 Claude Code 的 WebFetch 工具的第二步正常工作，从而让用户能够正常使用 WebFetch 工具。

智谱 Z.ai 的 Anthropic 的操作在这里可以详细说明一下，这点操作非常神奇：

  • 他们可能检测了 API 端点的工具参数，如果其中有 WebFetch 的工具，并且模型想要产生想要的调用，就会直接在服务端使用他们的 WebRead 工具来获取网页内容，然后直接将总结的内容发回给当前在使用的模型。这就带来了一个便利——笔者测试出来，他们的 MCP 服务是部署在美国的，所以访问境外的网站、就算没挂代理，也可以获取到对应的内容（虽然是模型总结过的）。
  • 在问模型有什么可用的工具的时候，API 端点会“拦截” WebFetch 工具，并且告诉用户只有 mcp__web_reader__webReader 这样的工具，这个完全是 Claude Code 内部使用的 MCP 工具的名称格式，也是让笔者十分困惑的地方——明明没有配置任何 MCP 服务器，这样的“MCP 工具”是怎么被发现的呢？结果是他们的 Anthropic API 端点拦截并提供了虚假的、好像是本地配置好的 MCP 服务器，从而让用户只能够使用他们计次的 WebReader 工具。

详情可以在 https://x.com/IIInoki/status/2039457730029572336 查看，可以看到它也包含了 mcp__4_5v_mcp__analyze_image 这样提供视觉能力的虚假的、好像是本地配置好的 MCP 服务器，这点十分聪明、但也十分狡诈。

插件系统

各家的插件系统都挺繁荣了，这里我只提一个笔者用得特别多的 Claude Code 的 Ralph Loop 插件，可以用一个简单的循环来让模型反复执行某个任务，从而实现一些比较复杂的功能（并充分消耗用量，笑），别的运行环境中的插件都没法达到类似的效果，笔者曾经让 Claude Code 在一个任务中最多跑了 160 个小时，那周消耗了 20 亿的 Tokens，对于厂商来说，笔者这样的用户还是很恐怖的。

各个运行环境的优势和问题

下面会提一些各个运行环境的优势和问题，以及一些笔者个人觉得的建议。

Codex App

OpenAI 模型独一家，但是成熟度不足，就不多赘述了。

Claude Code

Claude Code 是笔者主力使用的运行环境，也是笔者最推荐的运行环境，没有之一。

除了上面提到的“能力补全”之外，另外一个需要注意的点是上下文的大小：由于 Claude Code 假定用户使用的都是 Anthropic 的模型，所以默认的上下文大小是 1M，但如果是其他模型，比如 GLM-4.7 和 GLM-5，上下文大小只有 200K，很容易出现上下文不足、但还远远没有达到压缩上下文条件的尴尬局面（毕竟假定是 1M），所以需要手动切换到 Haiku 模型，并指定 Haiku 映射到 GLM-4.7 或者 GLM-5 的模型来使用（因为 GLM 默认将 Haiku 映射到 GLM-4.5-Air，只有 128K 的上下文）。

这点对于 Kimi 还有 Minimax 的模型来说也同样适用。唯一的特例是 Qwen3.5 Plus 及其后续 Qwen3.6 Plus，它们本身是支持 1M 上下文的，所以不需要手动配置。如果有用户遇到类似的 400 错误，请检查一下模型的上下文长度和 Claude Code 假定的模型。

此外，Kimi CLI 的开发者还发现 Anthropic 还会在非第一方模型上避免缓存命中，会导致模型供应商的模型消耗更多的 Tokens，这点对 Coding Plan 的用户来说除了缓存命中带来的加速会消失之外，影响不大；但是对于模型供应商来说，却会导致成本（算力和储存）急剧升高。

OpenCode

OpenCode 同样也是笔者主力使用的运行环境，也是笔者最推荐的运行环境，没有之一，因为天生支持第三方模型，并且工具调用基本都是本地实现，不存在不支持的工具的问题，上下文长度也都可以根据模型调整，所以非常方便。

唯一可能出现的运行环境能力的方面的缺失就是图像能力，最好配合一个 MCP 服务器来使用——这里笔者可以支持一下 MiniMax 的不限量视觉能力 MCP 服务器（广告位招租）。

除此之外，OpenCode 也支持多种运行环境，比如 CLI、Web UI 和桌面 App 等，但笔者个人还是更喜欢 CLI 的方式，因为更方便、更灵活。

CLI

CLI 模式下类似于 Claude Code，但是在 macOS 默认终端自带透明度的时候，很多主题的内容都看的不是很清楚，别的倒是问题不大。

Web UI

这一模式可以通过 CLI 的 serve 命令来启动，但是使用过程中经常会有跨域 WebAssembly 加载失败的问题（主要是权限），需要手动配置，并且还已经有了针对 OpenCode 服务端的黑客工具，需要深思熟虑安全策略。

OpenCode 的套壳 OpenChamber

此外，笔者还试用了 OpenCode 的套壳 OpenChamber，这个套壳的桌面模式用起来还是挺舒服的，除了在长上下文的情况下会陷入 0.1s 死循环、不执行任何任务之外，别的都还好。但是早期开发版本可以理解。

Cursor IDE

Cursor 也算是一个比较不错的运行环境，支持多种模型，并且工具调用基本都是本地实现，原生支持的模型都是经过优选的，不存在不支持的工具和视觉能力的问题，所以非常方便。

但是如果使用第三方模型，配置和切换还是比较迷惑的，并且 Cursor 假定 OpenAI 端点和 Anthropic 端点是官方的，会直接传图像等数据，如果是国产的第三方模型，就会出现不支持的 API 参数的错误。没测试的内容是模型的上下文长度，不知道假设是多少。

Google Antigravity

Google Antigravity 是一个比较不错的运行环境，支持多种模型，并且工具调用基本都是本地实现，不存在不支持的工具的问题，所以非常方便。唯一的缺点就是价格比较贵，而且用量限制比较死，还是不太适合个人开发者使用。

总结

不同的编码套餐工具各有特色，厂商也尝试通过兼容端点来让用户能在不同的运行环境（Harness）中使用他们的模型，但是往往都会有一些或多或少的问题。但是笔者相信，随着时间的推移，这些问题都会被逐渐解决，并且厂商也会越来越重视用户体验，从而提供更好的服务。

一些笔者个人的建议：

  • 对于想要兼容 Anthropic 端口的模型供应商，建议在兼容端口上提供一个默认模型，从而让用户能够正常使用 WebFetch 等工具；
  • 模型供应商也可以像智谱 Z.ai 一样，考虑将工具调用直接映射到自己对应的 MCP 服务器，从而让用户能无感使用 WebSearch 和视觉能力；
  • 对于中转站的管理员（包括用户自己），请注意模型的上下文长度，避免出现在 Claude Code 中上下文不足、但还远远没有达到压缩上下文条件的尴尬局面；
  • 对于运行环境（Harness）的开发者，请尽量提供齐全的本地工具，从而避免使用不同 API 端点时的差异。

希望笔者这篇对比分析能对有所帮助，也欢迎大家分享自己的使用体验和建议。

InokiComputer Scientist

Ph.D in Computer Science, major in Embedded System and AI.