Codex、Claude Code、OpenCode 与中国 CLI 智能体：一篇讲清 AI 如何真正操作电脑

很多人第一次看到 Codex 在 Mac 上剪视频、操作剪映、修改代码、调用 Git，甚至同时派出多个 agent 干活时，都会产生一种错觉：模型似乎已经钻进电脑，获得了鼠标、键盘和终端，开始像一个真正的人类工程师那样工作。

其实没有那么神秘。

大模型仍然只是“大脑”。真正让它获得行动能力的，是外面那一整套 agent runtime：文件系统、Terminal、Git、浏览器、Computer Use、MCP、插件、权限控制、任务循环与上下文管理。Claude、GPT、Kimi、Qwen 是大脑；Codex、Claude Code、Kimi Code、Qwen Code、OpenCode 是身体和工作制度；FFmpeg、Git、Shell、浏览器与剪映，才是它真正拿在手里的工具。

一旦把这四层分开，今天看似纷繁复杂的 AI coding 生态，立刻就清楚了。

一、先建立一个最重要的四层模型

这四层经常被混在一起，于是才会出现许多似是而非的问题：Kimi K3 能不能执行 CLI？OpenCode 是不是一个模型？Codex 能不能剪视频？Claude 订阅能不能直接登录 OpenCode？

答案分别是：

• Kimi K3 是模型，本身不执行 CLI；Kimi Code 或其他 agent runtime 才负责执行。
• OpenCode 不是模型，而是一个开源 coding agent 外壳和运行时。
• Codex 可以组织视频剪辑，但真正执行裁剪、转码和合成的是 FFmpeg 等本地工具。
• Claude Code 官方客户端可以使用 Claude 订阅 OAuth；OpenCode 不能合规地复用这套订阅凭证。

模型决定上限，agent 决定它怎么思考和循环，工具决定它能做什么，权限决定它到底能走多远。

这才是整件事的底层结构。

二、Codex为什么能在本地Mac上剪视频

Codex 不是 Premiere，不是 Final Cut，也不是剪映，更不是一个内置视频引擎。它能完成视频剪辑，是因为它可以把自然语言要求翻译成工具调用，再在本地反复检查结果。

最典型的工作流是：

1. 用 ffprobe 读取视频的编码、分辨率、帧率、时长和音轨。
2. 根据用户要求生成 ffmpeg 命令。
3. 执行裁剪、拼接、转码、压缩、抽帧、混音、水印或字幕烧录。
4. 检查输出文件、时长、分辨率和编码是否符合预期。
5. 必要时重新调整参数，再执行一轮。

因此，Codex 在本地最擅长的是确定性剪辑：

说实在的，CLI 剪视频和 GUI 剪视频是两种完全不同的生产方式。前者像数控机床，参数明确，结果可重复，适合批量和自动化；后者像剪辑台，依赖画面观察、时间线拖拽、模板和审美判断。Codex 两种都能参与，但效率、成本和稳定性并不相同。

三、所谓“鼠标插件”，本质是Computer Use

抖音里常见的“AI 直接操作剪映”，通常不是某个神秘的剪映专用插件，而是 Computer Use 一类视觉操作能力。

它的基本循环并不复杂：

获取屏幕截图
    ↓
模型识别窗口、按钮、文本和当前状态
    ↓
决定下一步点击、输入、滚动或拖拽
    ↓
执行鼠标键盘动作
    ↓
再次截图并判断结果

在 macOS 上，这类能力通常需要 Screen Recording 和 Accessibility 权限。它能够打开应用、点击按钮、输入文字、切换窗口、使用剪贴板，也就能原则上操作剪映、Photoshop、Excel 或各种没有 API 的老软件。

但“能操作”不等于“操作得最划算”。GUI 会遇到弹窗、动画、界面改版、按钮位移、拖拽误差和加载延迟。每一步又都需要截图、视觉理解、动作决策和结果确认，于是一次本来只需一条 FFmpeg 命令的任务，可能变成几十轮交互。

所以最合理的组合通常是：

• 确定性处理交给 FFmpeg、Shell 和脚本。
• 必须使用模板、滤镜、特效或平台专属能力时，再交给 Computer Use 操作剪映。
• 最终成片仍由人检查节奏、字幕、画面和审美。

Computer Use 解决的是“这个软件没有开放接口，我仍然要操作它”的问题。它是通用鼠标和眼睛，不是专业剪辑引擎。

四、为什么Computer Use通常比CLI更费额度

问题不在于插件被单独收了一道税，而在于它需要处理的信息和交互轮次更多。

CLI 任务通常长这样：

读取少量文本 → 生成命令 → 执行 → 读取文本结果

Computer Use 则更接近：

截图 → 视觉识别 → 定位控件 → 决策 → 点击 → 再截图 → 判断 → 重试

两者的消耗差异来自四个地方：

因此，同样是在 Mac 上完成任务，优先级通常应该是：API 或结构化工具，其次是 CLI，最后才是 GUI 自动化。不是因为 GUI 不先进，恰恰是因为 GUI 为人类设计，信息丰富却不够确定；CLI 为机器设计，朴素，却精准。

五、Codex App与Codex CLI不是两套完全隔离的系统

一个常见理解是：Codex App 和 Codex CLI 分别安装在两个路径，使用两套配置、两套 hooks、两套 Git 和两套权限。这个判断只对了一半。

它们确实是不同的交互表面，但共享相当一部分底层状态。

CLI 更像高效执行器。它离 Shell、Git、测试和日志最近，在路径明确、命令明确、目标明确时，通常速度更快、上下文更短、token 性价比更高。

App 更像工程工作台。它的价值不只是套一个图形界面，而是把任务、线程、worktree、浏览器、插件、截图、Computer Use、长任务和结果预览组织在一起。它牺牲了一部分极简性，换来了更强的协调能力。

所以不能简单说 App 必然比 CLI 低效。如果在 App 里仍然主要调用 Terminal 和结构化工具，差距可能很小；真正显著增加成本的，是截图、GUI 操作、浏览器长链路、多 agent 并发和高强度推理。

安装位置也确实不同：CLI 通常是一个命令行可执行文件，Desktop App 则位于 macOS 的应用目录。但用户配置、项目规则和许多运行状态，会围绕 ~/.codex 与项目内 .codex 目录汇合。它们是同一套 Codex 生态的不同驾驶舱，不是互不相识的两台机器。

六、Codex App与ChatGPT App的市场分工

ChatGPT 与 Codex 的边界，也不是“一个能聊天，一个能写代码”这么简单。

ChatGPT 面向的是通用知识工作：文档、搜索、分析、写作、图片、表格、研究与日常办公。Codex 面向的是工程执行：代码仓库、Terminal、Git、测试、worktree、hooks、MCP、代码审查、自动化和长期任务。

两者面对的是不同的高频用户。ChatGPT 要成为知识工作者的通用入口；Codex 要成为工程师和自动化工作流的执行中枢。底层模型、插件架构和部分桌面能力可以共享，但产品的重心完全不同。

七、Codex与Claude Code：不是简单抄袭，而是高速趋同

Claude Code 的先发优势非常清楚。2025 年 2 月 24 日，Anthropic 随 Claude 3.7 Sonnet 发布 Claude Code research preview。它从一开始就是 terminal-first 的 coding agent：搜索代码、读取文件、编辑、运行测试、调用命令行工具，甚至提交和推送代码。

OpenAI 在 2025 年 5 月 16 日发布 Codex research preview 时，重点还是云端软件工程 agent。此时两者的产品形态并不相同：Claude Code 已经在程序员每天使用的 Terminal 里形成自然工作循环，Codex 更像一个异步云端工程师。

随后差距快速缩小。

从产品史看，Claude Code 是 terminal coding agent 的先发标杆，Codex 则在 2025 年下半年到 2026 年上半年完成了一次非常猛烈的平台化追赶。

能不能因此说 Codex “抄袭” Claude Code？从官方资料无法证明。更准确的说法是：当行业确认“模型加Terminal加工具循环”是有效形态之后，所有主要厂商都在向同一组工程答案收敛。项目规则文件、hooks、skills、subagents、MCP、权限审批、非交互模式，这些能力会越来越相似，就像浏览器最终都会有标签页、地址栏和开发者工具。

但是趋同不代表完全相同。

Claude Code仍然强在哪里

• Terminal-first 的交互更早成熟，工作流连贯，agent loop 的体感自然。
• CLAUDE.md、hooks、commands、skills 和社区实践积累较深。
• Claude Sonnet 系列长期在 agentic coding、代码理解和复杂重构上口碑稳定。
• 对长期使用 Terminal 的工程师而言，认知负担很低。

Codex强在哪里

• CLI、Desktop App、IDE、Cloud、SDK、Slack 等多种表面协同发展。
• sandbox、exec policy、审批和企业治理体系更强调边界控制。
• App 中的 worktree、任务并行、可视化审查和桌面工具整合更突出。
• 从单个 coding agent 向多任务工程平台扩张得很快。

所以，到 2026 年再问“谁全面领先”，答案已经不像 2025 年初那么简单。Claude Code 在 CLI 手感和成熟度上仍有积累，Codex 在平台广度、桌面编排和多表面协作上追得极快。差距仍然存在，但已经从代际差距，变成不同设计取向之间的差距。

八、Codex也有workflow、loop和多agent

Claude Code 的 workflow 和 loop 往往显得自然：读取任务、搜索代码、制定计划、修改、测试、发现问题、再次修改，直到收敛。Codex 也有同类设计，只是官方命名和触发方式不同。

Codex 使用的主要术语是：

• Agent loop：模型在观察、行动、验证之间循环。
• Subagents：把子任务委派给独立 agent。
• Subagent workflows：由主 agent 规划和协调多个子任务。
• Multi-agent operations：创建、等待、恢复、发送消息和关闭 agent。
• Goal mode：围绕长期目标持续推进，而不是只完成一轮问答。
• Worktrees：让不同 agent 在隔离的 Git 工作树中并行修改。

其内部逻辑大致如下：

Codex 内置或常见的 agent 角色包括 default、worker 和 explorer，也允许在用户或项目配置中定义自有 agent。主 agent 可以执行 spawn_agent、send_input、wait_agent、resume_agent 和 close_agent 等操作。

一个现实差异是：Claude Code 的 agent loop 往往更像默认行为，Codex 的多 agent 编排则更强调显式委派。用户如果明确要求“派两个 agent 分别研究”“每个模块一个 worker”“先让 explorer 查资料”，通常更容易看到 Codex 的分流过程。

九、中国大陆已经出现真正的CLI coding agent

中国模型厂商并没有停留在“提供一个 API，让别人接入 Claude Code”的阶段。到 2026 年，已经出现数个形态完整的 CLI coding agent。

第一梯队：已经具备完整CLI agent形态

第二类：模型很强，但官方CLI并非核心产品

国内第一梯队已经具备 Claude Code/Codex CLI 大约六到八成的产品形态：能理解仓库、修改文件、运行 Shell、调用 MCP、使用项目规则、执行非交互任务，也开始支持 subagents、skills 和 hooks。

真正的差距主要不在“能不能改代码”，而在更深的工程层：长期任务是否稳定，权限模型是否清晰，复杂任务能否持续收敛，多 agent 是否真正可控，worktree 与 Git 是否成熟，失败恢复是否可靠，企业审计和生态是否完善。

功能列表可以在几个月内追平，工程稳定性和社区方法论需要时间。这一点，才是今天中外 coding agent 最真实的距离。

十、Kimi K3已经是顶级开放权重agent模型，但它不是CLI

Kimi K3 是 Moonshot AI 发布的开放权重、多模态、面向 agent 任务的模型。官方资料显示，它采用 2.8T 总参数、104B 激活参数（每 token 从 896 个专家中激活 16 个）的稀疏 MoE 架构，支持最高 1M context，并针对代码、工具调用、浏览和长任务进行了重点训练。

它可以通过 Kimi Code CLI 使用。用户进入 Kimi Code 后通过 /model 选择 k3 或 k3-256k，也可以使用 OpenAI-compatible 或 Anthropic-compatible API 接入其他 agent runtime。

但必须再次强调：

Kimi K3负责理解和决策，Kimi Code负责读文件、执行命令和修改代码。

这和 GPT 加 Codex、Claude 加 Claude Code 是同一层关系。

K3大致相当于什么水平

按照 Kimi 官方公布的评测，K3 在多个 agentic coding、Terminal、浏览和计算机操作基准上，已经进入 Claude Opus 4.6/4.8、GPT-5.5 一带的竞争区间，部分项目接近或超过更强闭源模型。

例如官方表格中：

表中 K3 数据整理自 Moonshot 官方公布的 Kimi K3 评测（技术博客与模型页，链接见文末「Kimi与中国CLI Agent」），核对于 2026-08-02——其中 GPQA Diamond 93.5、Terminal-Bench 2.1 88.3、BrowseComp 91.2 与官方数值一致。对比列（GPT-5.5、Claude Opus 4.8）取自各自官方口径，harness 与推理预算未必对齐，横向比较仅供参考。

这些数字不能机械理解为“K3全面超过Opus”。不同模型可能使用不同 agent harness、推理预算、温度和工具环境，官方自测也应保留审慎。但它至少说明一件事：K3 已不是廉价替代品，而是可以在真实 coding agent 与长上下文任务中正面对比顶级闭源模型的开放权重模型。

如果拿 2025 年初的 GPT-4.5 做参照，K3 已经明显更强，尤其是在代码、Terminal、工具调用、长上下文与 agent 工作流上。GPT-4.5 是当时强大的通用聊天模型，却不是今天这种为长链路工具执行而生的 agent 模型。

更稳妥的结论是：

• K3 明显超过 GPT-4.5 所代表的上一代通用模型水平。
• 在 CLI 编程和工具任务上，可视为 Opus 4.6 级别的有力竞争者。
• 在复杂抽象判断、超长任务稳定性、表达质量和安全边界上，不能宣称全面超过 Claude Opus。
• 日常任务可以优先使用 k3-256k 控制消耗；大型仓库和超长资料再使用 1M context 的 k3。

十一、OpenCode是什么：开源agent外壳，不是模型

OpenCode 的官方定义是“开源 AI coding agent”。安装它，相当于安装了一套可在 Terminal、Desktop App 或 IDE 中运行的 agent 系统，而不是下载了一个独立大模型。

它负责的事情包括：

• 扫描和理解项目目录。
• 读取、搜索、写入和修改文件。
• 执行 Bash 命令和测试。
• 调用 LSP、MCP、Web Search 与自定义工具。
• 管理 build、plan 和 subagent 等角色。
• 控制工具权限是 allow、deny 还是 ask。
• 把任务状态、工具结果和历史上下文重新交给模型，形成 agent loop。

OpenCode 背后仍然必须有一个模型 provider。它通过 AI SDK 与 Models.dev 支持大量云端模型和本地模型，用户安装后通常需要执行：

brew install anomalyco/tap/opencode
cd /path/to/project
opencode

然后在 OpenCode 内完成：

/connect   连接模型供应商
/models    选择具体模型
/init      初始化项目规则，生成AGENTS.md

模型可以是 Anthropic Claude、OpenAI GPT、Kimi、Qwen、DeepSeek，也可以是 Ollama 等本地模型。配置的本质是 provider_id/model_id，例如：

{
  "model": "anthropic/claude-sonnet-4-5"
}

所以，OpenCode 的商业和技术价值并不在于“它拥有最强模型”，而在于模型可替换。今天接 Claude，明天换 GPT，某些任务用 Kimi，离线环境用本地模型，agent 的工具、权限和项目工作流仍可保留。

这是开源外壳路线最迷人的地方，也是它最现实的代价：你获得选择权，同时要自己处理 API、模型差异、上下文费用、权限和兼容性。

十二、OpenCode不能合规复用Claude Pro/Max订阅OAuth

这是 OpenCode 使用中最容易踩坑，也最需要说清楚的一点。

Claude Code 官方 CLI 支持 Claude Pro、Max、Team 和 Enterprise 等订阅用户通过 /login 走 OAuth 登录。但这套授权的用途，是用户在 Anthropic 自有应用中使用 Claude Code。

Anthropic 的官方法律与合规说明明确指出：Claude 的订阅 OAuth 凭证面向原生 Anthropic 应用；第三方开发者和产品不应提供 Claude.ai 登录，也不应代用户转接 Free、Pro 或 Max 凭证。第三方集成应该使用 Claude Console API Key，或通过受支持的云服务商接入。

OpenCode 官方与社区记录也已经把这件事写明：过去存在让 OpenCode 复用 Claude Pro/Max 订阅的 OAuth 插件，但 Anthropic 明确禁止这种方式；2026 年 3 月，应 Anthropic 法务要求，OpenCode 移除了内置的 Claude 订阅 OAuth 插件与相关 system prompt。

因此，当前稳定、合规的接入方式是：

• 使用 Anthropic Console 创建的 API Key。
• 通过 Amazon Bedrock、Google Vertex AI 等官方支持渠道。
• 使用 OpenRouter、Vercel AI Gateway 等第三方 API provider，但需接受其价格、隐私和可用性条款。
• 如果只想消费 Claude Pro/Max 订阅，使用 Anthropic 官方 Claude Code CLI。

OpenCode 中的典型配置流程是：

启动 opencode
  ↓
/connect
  ↓
选择 Anthropic
  ↓
输入 Anthropic Console API Key
  ↓
/models 选择 Claude 模型

网上可能仍能找到第三方 OAuth 插件、旧教程或绕行方案。它们“暂时能用”不代表合规，也不代表长期稳定。Anthropic 有权限制这类凭证，用户还要承担账号风控与突然失效的风险。

一句话概括：Claude Code订阅属于官方客户端消费权，Anthropic API Key才是第三方agent的正式通行证。

十三、如何选择：别先问谁最强，先问任务属于哪一层

面对 Codex、Claude Code、OpenCode、Kimi Code 和 Qwen Code，最实用的选择方法不是寻找一个永远第一的排行榜，而是看自己的任务和约束。

还可以用一条更朴素的决策链：

1. 有 API，就先用 API。
2. 有 CLI，就优先用 CLI。
3. 有结构化文件格式，就直接读写文件。
4. 只有图形界面时，再使用 Computer Use。
5. 任务能拆分且边界清楚时，才派多个 agent。
6. 模型越贵、上下文越长，越要控制无效截图、重复日志和无边界探索。

技术世界喜欢炫耀“AI 已经会自己操作电脑”，但真正决定生产力的，从来不是它点了多少次鼠标，而是它能否选择正确工具、保持清晰边界、验证真实结果，并在失败之后继续收敛。

结语：大模型正在从会说话，变成会做事

过去我们评价一个模型，看它知道多少、写得多好、考试多少分。现在评价一个 agent，要看它能不能进入真实环境，理解项目，调用工具，管理权限，拆分任务，发现错误，持续修正，最后交付一个可以被验证的结果。

这是一场从“语言智能”到“行动智能”的迁移。

Claude Code 率先证明了 Terminal 可以成为大模型的工作场；Codex 用极快速度把这套能力扩展到 App、Cloud、SDK、worktree 和多 agent；OpenCode 把外壳开源，让模型成为可以更换的大脑；Kimi、Qwen、腾讯和字节则证明，中国厂商已经不再满足于只提供模型 API，而是在争夺 agent runtime、CLI 入口和开发者工作流。

说到底，未来真正有价值的，不是某一个模型在某一天多领先三分，而是谁能建立一套稳定、可控、可迁移、可验证的工作制度。模型会换，价格会降，榜单会变，订阅政策甚至可能一夜之间收紧；但项目规则、工具体系、知识资产、权限边界和工作流，可以留下。

大脑终会越来越多。真正稀缺的，是身体，是秩序，是让智能持续做成事情的能力。

也许，这才是 CLI agent 革命真正开始的地方。

官方资料与延伸阅读

OpenAI Codex

• Introducing Codex
• Codex is now generally available
• Introducing the Codex app
• Codex Hooks
• Git worktrees
• Subagents
• Computer Use
• GPT-5.5 model documentation
• GPT-5-Codex model documentation

Claude与Anthropic

• Claude Code authentication
• Claude Code legal and compliance
• Claude API authentication

OpenCode

• OpenCode GitHub repository
• OpenCode documentation
• OpenCode providers
• OpenCode models
• OpenCode agents
• OpenCode tools

Kimi与中国CLI Agent

• Kimi K3 GitHub repository
• Kimi K3 官方技术博客（含评测数据）
• moonshotai/Kimi-K3 · Hugging Face（开放权重与模型卡）
• Kimi Code models
• Kimi Code GitHub repository
• Qwen Code GitHub repository
• Qwen3-Coder introduction
• Trae Agent GitHub repository
• Tencent CodeBuddy CLI documentation
• DeepSeek agent integrations