AI IDE 与 Agent Harness：一次说清 Cursor、Codex 该怎么选

- 一、先把两个词掰开
- - [1.1 AI IDE：编辑器是本体，AI 是长在编辑器里的一层](#1.1 AI IDE：编辑器是本体，AI 是长在编辑器里的一层)
  - [1.2 Agent Harness：模型是发动机，Harness 是整台车](#1.2 Agent Harness：模型是发动机，Harness 是整台车)
  - [1.3 一个更直白的比喻](#1.3 一个更直白的比喻)
  - [1.4 边界在哪：一张表说清](#1.4 边界在哪：一张表说清)
- [二、2026 年的三条主流路线](#二、2026 年的三条主流路线)
- - [2.1 路线一：IDE 内 Agent（Cursor、Copilot、Windsurf）](#2.1 路线一：IDE 内 Agent（Cursor、Copilot、Windsurf）)
  - [2.2 路线二：终端 Agent（Claude Code、Codex CLI、Gemini CLI）](#2.2 路线二：终端 Agent（Claude Code、Codex CLI、Gemini CLI）)
  - [2.3 路线三：云端 Agent（Codex Cloud、Cursor Cloud Agent）](#2.3 路线三：云端 Agent（Codex Cloud、Cursor Cloud Agent）)
  - [2.4 为什么不能只看"模型能力"](#2.4 为什么不能只看"模型能力")
- 三、选型四问
- - [第 1 问：代码最终在哪里被改？](#第 1 问：代码最终在哪里被改？)
  - [第 2 问：谁来兜底：谁能碰哪些文件？](#第 2 问：谁来兜底：谁能碰哪些文件？)
  - [第 3 问：谁买单：额度怎么算、能不能进预算？](#第 3 问：谁买单：额度怎么算、能不能进预算？)
  - [第 4 问：上下文从哪来：规则怎么沉淀？](#第 4 问：上下文从哪来：规则怎么沉淀？)
- [四、Cursor 拆解：把 AI 装进 VS Code](#四、Cursor 拆解：把 AI 装进 VS Code)
- - [4.1 四层能力](#4.1 四层能力)
  - [4.2 关键差异：前台 vs 后台](#4.2 关键差异：前台 vs 后台)
  - [4.3 规则文件](#4.3 规则文件)
  - [4.4 适合谁](#4.4 适合谁)
- [五、Codex 拆解：一个 Harness，五个表面](#五、Codex 拆解：一个 Harness，五个表面)
- - [5.1 一个内核，多个表面](#5.1 一个内核，多个表面)
  - [5.2 权限模型：这是 Codex 最值得学的部分](#5.2 权限模型：这是 Codex 最值得学的部分)
  - [5.3 适合谁](#5.3 适合谁)
- 六、其他几种典型形态
- - [6.1 Claude Code：终端优先的长上下文专家](#6.1 Claude Code：终端优先的长上下文专家)
  - [6.2 Gemini CLI：GCP 生态与合规](#6.2 Gemini CLI：GCP 生态与合规)
  - [6.3 开源系：可审计与可定制](#6.3 开源系：可审计与可定制)
  - [6.4 主流 CLI 的"跳过权限"对照](#6.4 主流 CLI 的"跳过权限"对照)
- [七、上下文与协议层：2026 年真正在收敛的东西](#七、上下文与协议层：2026 年真正在收敛的东西)
- - [7.1 AGENTS.md：静态项目上下文层](#7.1 AGENTS.md：静态项目上下文层)
  - [7.2 MCP：Agent 的"手"](#7.2 MCP：Agent 的"手")
  - [7.3 A2A、AG-UI 与 Skills](#7.3 A2A、AG-UI 与 Skills)
- 八、面向不同人群的推荐路线
- - [8.1 关于"组合使用"](#8.1 关于"组合使用")
  - [8.2 三个常见误区](#8.2 三个常见误区)
- [九、2026 主流趋势判断](#九、2026 主流趋势判断)
- - 趋势一：从"选工具"转向"选运行时"
  - 趋势二：规则文件成为团队资产
  - 趋势三：权限模型从"信任"转向"可证明"
  - 趋势四：成本控制从"事后感知"变成"设计约束"
  - [趋势五：从单 Agent 到多 Agent 编排](#趋势五：从单 Agent 到多 Agent 编排)
  - 趋势六：视觉化交互成为标配
  - 趋势七：可复现性与评估
- 十、一页速查表
- 十一、写在最后
- 参考来源

如果你在 2026 年做技术选型，几乎一定会被同一组问题绊住：Cursor 和 Claude Code 到底差在哪？Codex 是不是"套壳"？我该买哪一个订阅？团队要不要统一标准？

这些问题的答案，几乎都藏在一对被混用的概念里------AI IDE 和 Agent Harness。把它们分清楚，选型就不再是背观点，而是做推导。

本文基于 2026 年 10 月的公开资料与实际使用体感，先讲清概念，再拆解 Cursor、Codex 这两个主流样本，最后给出按人群划分的选型路线与趋势判断。

一、先把两个词掰开

1.1 AI IDE：编辑器是本体，AI 是长在编辑器里的一层

AI IDE 指的是以代码编辑器为主体、把 AI 能力内建进去的产品形态。Cursor 是最典型的代表------它是 VS Code 的分支，而不是一个外挂插件。

判断一个工具是不是 AI IDE，看三个特征：

交互载体是窗口，不是终端。补全、内联修改、对话面板、差异审阅都在同一个视口里完成。
上下文以编辑器为中心：当前打开的文件、索引结果、符号引用、光标位置。
审批是逐次、实时的：因为人就在屏幕前，每一步改动的 diff 都能立刻看到。

它的优势非常实在：切换成本极低 。已经熟悉 VS Code 的开发者，几乎零成本迁移。它的短板同样实在：窗口本身就在打断你。一个需要跑半小时的活，你不可能一直盯着那个对话框。

1.2 Agent Harness：模型是发动机，Harness 是整台车

Agent Harness 指的是把一个模型包裹成能干活的智能体的运行时框架。它不是模型本身，而是模型与真实世界之间那层工程代码。

Harness 负责的事情非常具体：

Harness 的职责	具体在做什么
工具调用翻译	把模型输出的"意图"变成真实的 `exec`、文件读写、HTTP 请求
上下文管理	读哪些文件、何时压缩、超长时怎么截断、跨会话记忆怎么存
错误处理	命令失败重试几次、输出截断怎么拼接、异常怎么收敛
权限与沙箱	哪些目录只读、哪些命令要人点头、网络能不能通
成本与额度	跑多久停、烧到多少 token 强制中止
审批流	什么时候暂停、批准粒度是按命令还是按步骤

这一层是纯工程代码，和模型厂商没有绑定关系。这也是为什么同一个 Claude 模型，在 Cursor、Claude Code、Gemini CLI 里表现会差很多------不是模型变了，是车不一样。

1.3 一个更直白的比喻

如果只记一件事，就记住这个：

Agent 是司机，Harness 是车。

司机决定去哪里、怎么绕路；车决定你能不能安全地开、能不能在雨夜跑长途、导航失灵时会不会把你带沟里。换司机是换模型，换车是换 harness。

由此可以直接推出选型顺序：先定 harness（形态与边界），再挑 agent 能力（模型与体验）。

反过来先挑模型是最常见的错误。同一款模型套在不同 harness 里，实际产出效率能差出一倍------因为决定"一次任务要迭代多少轮"的，往往是 harness 的上下文管理和错误重试策略，而不是模型本身。

1.4 边界在哪：一张表说清

	AI IDE	Agent Harness
是什么	一类产品形态（Cursor、Windsurf）	一类运行时框架（Codex CLI、Claude Code 的内核）
主体	编辑器	命令行 / 运行时
上下文	当前文件 + 索引	整个仓库 + 指令文件 + 命令输出
审批粒度	每次改动看 diff	按命令 / 按步骤
典型风险	上下文太窄，看不全仓库	学习成本高，容易误操作
适合	小步快跑、UI 打磨	跨文件重构、批处理、CI

二、2026 年的三条主流路线

底层模型正在快速趋同------同一个 Claude、GPT、Gemini 跑在三个不同的载体上，能力上限接近，但交互成本完全不同。

2.1 路线一：IDE 内 Agent（Cursor、Copilot、Windsurf）

关键词：零迁移成本、视觉反馈、上下文即时。

适合"我正在写这个函数，帮我把它写完"以及"这个报错在哪"这类问题。Tab 补全是这里最被低估的能力------它不炫技，但它每天都在帮你省时间。

成熟形态已经不只是补全了：Composer 类多文件同步修改、Agent 模式自主读改验、云端 Agent 异步跑长任务，已经是标配而非加分项。

2.2 路线二：终端 Agent（Claude Code、Codex CLI、Gemini CLI）

关键词：仓库级上下文、可脚本化、能进 CI。

终端是开发者的原生环境。终端 Agent 能做的事，IDE Agent 基本都能做；反过来不成立------比如在 CI 里跑、批量改名三百个文件、跨仓库操作。

这一路线也是权限模型最成熟的一条。几乎所有主流 CLI 都提供了沙箱档位 + 审批策略的组合开关，后面第五节会详细讲。

2.3 路线三：云端 Agent（Codex Cloud、Cursor Cloud Agent）

关键词：关电脑也在干、任务即 PR。

提交任务 → 平台在隔离容器里跑完 → 产出带完整命令日志的 PR。这解决的是"长任务"和"批量化"两个 IDE 和终端都不舒服的场景。

云端 Agent 的天然优势是安全边界清晰：它在别人的沙箱里跑，跑坏了也碰不到你的机器。

2.4 为什么不能只看"模型能力"

一个反直觉的事实：在实测里，同一批任务，不同工具的模型质量差距往往小于工程差距。

真正拉开差距的是这些：

上下文给得准不准（agent 有没有找到该看的文件）
失败之后会不会自己收敛（改错了能不能发现并回退）
权限边界设得合不合适（敢不敢放手让它跑）
成本是否可控（一个任务烧掉多少额度）

这四项全部由 harness 决定。 所以，回到那句话：先定 harness。

三、选型四问

不要一上来就搜"2026 最好的 AI 编程工具"。先按顺序回答四个问题，答案会自己把候选名单收敛到两三个。

第 1 问：代码最终在哪里被改？

这是根问题，决定 harness 形态：

在 IDE 里 → AI IDE 路线（Cursor、Windsurf、Copilot）
在终端里 → 终端 Agent 路线（Claude Code、Codex CLI、Gemini CLI）
关掉电脑之后 → 云端 Agent 路线（Codex Cloud、Cursor Cloud Agent）

第 2 问：谁来兜底：谁能碰哪些文件？

这里有个必须掰开的概念：沙箱和审批是两个独立维度。

沙箱决定技术上能碰什么（可读目录、可写目录、能否联网）
审批决定什么时候停下来问你

很多人把两者混为一谈，最典型的误配是：把沙箱放到最宽，同时以为 on-request 会替你把关。实际上沙箱放到最宽时，agent 根本不越界，也就根本不会触发审批------那不叫安全，那叫不问。

第 3 问：谁买单：额度怎么算、能不能进预算？

成本失控是 2026 年团队放弃 AI 编程工具的首要原因，比"不好用"常见得多。

三种典型账本：

订阅打包：Codex 随 ChatGPT 订阅走，不单独按席位计费（截至 2026 年 8 月）
按量付费：Claude Code 按 token 计，用得多就是得多
企业版：Copilot Enterprise、Cursor Teams 这类，集中计费 + 审计日志 + 统一策略

选型时先算一笔账：你的日常任务量 × 典型任务消耗 ÷ 套餐上限。这个数字算不明白，后面的比较都是空谈。

第 4 问：上下文从哪来：规则怎么沉淀？

这是最容易被跳过、但最决定长期成败的一问。

工具可以换，但项目知识（怎么构建、目录怎么分、哪些文件不许动、代码风格是什么）必须沉淀成文件。2026 年的共识载体是 AGENTS.md。

不写规则文件的后果是：每次换工具、换模型，agent 都从零开始认识你的项目，所有踩过的坑再踩一遍。

四、Cursor 拆解：把 AI 装进 VS Code

4.1 四层能力

Cursor 2026 年的形态可以理解成同一个编辑器里塞了四种 Agent，它们的成本递增：

Tab 预测式补全 --- 猜你下一步要写什么，键入即成行，几乎无感
Composer / Inline Edit --- 选中一段，说一句就改，可跨多文件同步修改
Agent 模式 --- 自己读代码、跑命令、改文件，再回头验证
Background / Cloud Agent --- 任务丢进远程环境异步执行，能自动运行终端命令

版本节奏上，Cursor 3.0（2026 年 4 月）带来了 Agents Window 编排界面，3.7（2026 年 6 月）大幅升级了 Design Mode------直接把"指哪改哪"做成了标准流程，圈选元素就能下指令，不再靠 prompt 猜你的意图。

4.2 关键差异：前台 vs 后台

Cursor 的 Background / Cloud Agent 跑在远程环境中，可以自动运行终端命令，不需要逐次批准；而前台 Agent 默认每一步都要你点"同意"。

这条边界决定了"敢不敢放手让它跑"。它也解释了为什么 Background Agent 适合值班式任务：反正跑在隔离环境里，错了也只是产出个失败的 PR。

另外，Bugbot 负责合并前的自动代码审查，和云端 Agent 一起构成"提交前 + 合并前"的双保险。

4.3 规则文件

Cursor 同时认三种规则载体：

.cursor/rules --- Cursor 原生规则目录
AGENTS.md --- 开放格式，跨工具通用
CLAUDE.md --- CLI 场景下也会读

这意味着同一套规则可以在 IDE 和终端之间复用。

.cursor/rules 的典型写法（.mdc 文件，用 frontmatter 声明何时生效）：

markdown 复制代码

---
description: 数据库访问层规范
globs: ["src/repo/**/*.java"]
alwaysApply: false
---

- 所有 SQL 走 MyBatis Mapper，禁止在 Service 里拼字符串
- 事务注解只在 Service 层使用
- 列表查询必须分页，单页上限 200

4.4 适合谁

适合：日常业务开发、前端与 UI 打磨、刚上手 AI 编程的新手、已经在用 VS Code 生态的人。

不适合：需要长时间无人值守的任务、必须跑在 CI 里的流程、代码不能出内网的场景。

价格参考（2026 年中第三方整理，以官网为准）：Pro 约 $20/月、Pro+ 约$ 60/月、Ultra 约 $200/月、Teams Standard 约$ 40/人/月。Teams 版本额外提供集中计费、团队 Marketplace 和统一策略管理。

五、Codex 拆解：一个 Harness，五个表面

5.1 一个内核，多个表面

Codex 的 Rust 核心（CLI、运行时、app-server）是 Apache-2.0 开源的，各个端只是它的一层皮：

表面	形态	适合
CLI	终端交互式会话 + `exec` 模式	脚本化、可重复；`exec` 直接给 CI 用
IDE 扩展	VS Code / Cursor / Windsurf 都能装	不换编辑器也能用起来
桌面 App	多窗口并行开 agent（macOS / Windows）	同时推进好几条工作线
Codex Cloud	每任务一个隔离容器，产出 PR + 完整命令日志	长任务、可离线跑
移动端	ChatGPT App 内直接下达任务	通勤路上派活

再加上 codex review 这类代码审查集成（GitHub 上已有，GitLab 的 MR 审查处于 beta），它正在从"一个 CLI"变成"一个平台"。

5.2 权限模型：这是 Codex 最值得学的部分

Codex 把权限拆成两个正交维度，这是所有主流 CLI 里做得最完整的。

沙箱三档：

模式	文件修改	命令执行	网络	适用场景
`read-only`	禁止	禁止	禁止	代码审查、方案分析
`workspace-write`	仅工作区	允许	受限	日常开发（推荐默认）
`danger-full-access`	全部	全部	全部	仅在已做外部隔离的环境

审批策略 ：on-request（越界才问，日常首选）、never（适合 CI，非交互场景）、以及完全旁路。

日常推荐的组合就一条命令：

bash 复制代码

# 日常开发：工作区可写 + 出界才问
codex --sandbox workspace-write --ask-for-approval on-request

写进配置文件长期生效（~/.codex/config.toml）：

toml 复制代码

sandbox_mode = "workspace-write"
approval_policy = "on-request"

完全旁路的长选项名特别长，这是刻意的：

bash 复制代码

# 官方原话：只在已经做好外部隔离的环境里用
codex --dangerously-bypass-approvals-and-sandbox   # 简写 --yolo

日常开发绝对不要碰它。它意味着模型可以 rm -rf $HOME 而没有任何拦截。如果确实需要无人值守，正确的做法是 codex exec + 显式最小权限 + 一次性容器，而不是开旁路。

几个值得注意的细节演进：

独立审批 ID（v0.104.0+）：多步骤 shell 执行中每条命令单独审批，批准其中一条不会连带批准后面的
untrusted 审批档位已废弃（v0.149.0）
权限快捷键 （v0.150.0+）：可在编辑器里用 /keymap 绑定循环切换权限模式的按键
沙箱可靠性（v0.129.0）：Linux 沙箱启动强化，减少慢速文件系统下的竞态；内置 bubblewrap 升级

5.3 适合谁

适合：已经在用 ChatGPT 订阅的人（额度直接打包，最省心）、需要把 agent 塞进 CI 的团队、喜欢"提需求收 PR"工作方式的开发者、需要同时推进多条线的独立开发者。

不适合：要求完全离线、代码绝对不能出内网的场景；以及不习惯终端和权限模型的新手。

六、其他几种典型形态

6.1 Claude Code：终端优先的长上下文专家

Claude Code 的定位非常清晰：终端优先、面向大型代码库、擅长复杂重构。

它的核心资产是 CLAUDE.md------经过打磨的规则文件会被开发者称为"肌肉记忆"，写得好不好直接决定产出质量。配套能力包括 Skills 机制（把可复用能力封装成技能包）、Hooks（事件驱动的自动化）、Headless 模式和 Agent SDK（程序化调用）。

2026 年的两个重要变化：

AGENTS.md 兼容 ：新版 Claude Code 在目录里没有 CLAUDE.md 时，会检查并使用 AGENTS.md，用户可以在 /config 里切换这个行为
编排能力：Dynamic Workflows 可以编排数百个 subagent，Auto Mode 进一步降低交互成本

6.2 Gemini CLI：GCP 生态与合规

指令文件是 GEMINI.md。权限模型同样是沙箱 + 审批的组合，跳过权限的命令形如：

bash 复制代码

gemini --approval-mode=yolo --sandbox

在 GCP 生态和合规认证（SOC / ISO）上，它的完整度是最高的；个人免费额度调整后，部分能力迁到了 Antigravity。

6.3 开源系：可审计与可定制

OpenCode：MIT 协议、代码完全公开、多 Provider 接入、可二次开发，是"想看清 harness 到底怎么实现"的最佳样本
DeepSeek Harness：插件式架构，模型、工具、会话都可热插拔
Kimi 编程：兼容 Claude Code 生态，可以直接复用现成的配置与技能包
Hermes Agent / OpenClaw：面向本地与私有化部署，前者强调数据不出内网，后者强调本地个人助理与统一网关

如果你的核心诉求是可审计、可定制、数据不出内网，开源 harness 是绕不开的选项。

6.4 主流 CLI 的"跳过权限"对照

这张表建议收藏，是最容易踩坑的地方：

工具	日常推荐	非交互 / CI	完全旁路（仅限隔离环境）
Codex CLI	`--sandbox workspace-write --ask-for-approval on-request`	`codex exec` + 最小权限	`--dangerously-bypass-approvals-and-sandbox`（`--yolo`）
Claude Code	默认逐次批准	Headless / SDK 模式	`--dangerously-skip-permissions`
Gemini CLI	默认审批	`--approval-mode=never`	`--approval-mode=yolo --sandbox`

七、上下文与协议层：2026 年真正在收敛的东西

选型之外，还有一层更值得关注的事情：Agent 生态正在分层标准化。有标准的层跟着标准走，没标准的层才是你该投入的地方。

7.1 AGENTS.md：静态项目上下文层

被称作"agent 界的 .gitignore"的开放格式。写法很简单，就是一个 Markdown 文件：

markdown 复制代码

# 项目约定

## 构建与测试
- 构建：./mvnw -q clean package
- 单测：./mvnw test -Dtest=XxxTest
- 禁止跳过测试提交

## 目录约定
- controller 只做参数校验和转发
- 业务逻辑一律在 service 层
- 跨模块调用走 facade，不直接调 dao

## 禁止事项
- 不要修改 src/generated/**（由代码生成器产出）
- 不要在 pom.xml 里升级依赖版本

几个关键事实：

截至 2026 年初，已有超过 6 万个开源项目采用 AGENTS.md 格式
Claude Code、Cursor、Codex 等主流工具都已支持读取
它与 MCP、Agent Skills 构成互补的三层：静态上下文 / 动态工具 / 可复用能力

7.2 MCP：Agent 的"手"

MCP（Model Context Protocol）由 Anthropic 于 2024 年底推出，规定了工具与服务以何种标准方式向 AI 应用暴露能力。

要理解它的价值，先看没有它的时候：OpenAI 的 function calling 是一套 JSON Schema 约定，Anthropic 的 tool use 是另一套，各家 Agent 框架又各自封装一层。M 个框架 × N 个工具 = M×N 份重复劳动。

MCP 把"连接外部服务"标准化了。接入一个新工具只需要写一个 MCP Server：

json 复制代码

{
  "mcpServers": {
    "internal-api": {
      "type": "streamable-http",
      "url": "https://mcp.example.com/mcp",
      "headers": {
        "Authorization": "Bearer ${MCP_TOKEN}"
      }
    }
  }
}

2026 年的两个节点值得记住：

MCP 已被捐赠给基金会，首届官方 MCP 开发者峰会计划于 2026 年 4 月在纽约举行
规范持续演进，2026-07-28 版包含 Resources、Prompts、Tools、Roots、Sampling、Tasks 等能力

调试友好也是 MCP 被低估的优势：工具调用是同步的，请求发出去、结果拿回来、出错看得见。

7.3 A2A、AG-UI 与 Skills

A2A（Agent2Agent）：Agent 之间的任务委派与结果回传，是多 Agent 协作的基础
AG-UI：Agent 与用户界面的交互协议，把思考过程、审批流、工具状态渲染出来。做 AI 产品前端时的必答题
Agent Skills：把可复用能力封装成技能包，正在成为跨工具的"第二份 AGENTS.md"

一个实用判断：先学 MCP，需要跟别的 Agent 协作时再上 A2A，做前端界面时补 AG-UI。顺序符合技术发展规律------先解决连接，再解决协作。

八、面向不同人群的推荐路线

工具是为人服务的。按角色反推，比按功能正推靠谱得多。

人群	首选	理由	补充
学生 / 转行	Cursor 免费版或 Copilot	补全反馈即时，容错成本低	先学 `AGENTS.md` 的写法思路
日常业务开发	Cursor	IDE 零迁移，视觉反馈快	配合 Code Review Agent
复杂重构 / 大型仓库	Claude Code	长上下文 + 跨文件能力	规则文件是成败关键
大仓库批量改 + 自动提 PR	Codex	读整个仓库、自动跑测试、产出 PR	云端任务最省心
独立开发者	ChatGPT 订阅 + Codex	能力打包在已有订阅里，不额外烧钱	桌面 App 并行推进多条线
团队 Tech Lead	统一 harness + AGENTS.md	工具可以换，规则不能丢	配合 MCP 沉淀内部能力
企业 / 合规场景	Copilot Enterprise / Cursor Teams	审计日志、数据驻留、集中计费	权限策略要下发到每一端
数据不能出内网	OpenCode / 本地部署 harness	可审计、可本地接入模型	代价是自行承担维护成本

8.1 关于"组合使用"

这三者不互斥。2026 年比较常见的工作流是：

Cursor 写当下这 50 行、反复微调 UI
Claude Code 做跨文件重构、批量改命名
Codex Cloud 接住需要几十分钟的活，产出 PR
Codex review / Cursor Bugbot 做合并前的最后一道把关

选型的目标不是"选一个"，而是"每个工位配一个"。但组合的前提是规则文件统一------否则每个工具都在重新认识你的项目。

8.2 三个常见误区

误区一：以为 Cursor 只能补全。 它的 Agent 模式和 Background/Cloud Agent 早已是完整能力，2026 年的 Cursor 至少是"四种模式并存"。
误区二：以为 Codex 只是 CLI。 它已经横跨 CLI、IDE 扩展、桌面 App、云端、移动端五个表面。
误区三：把"哪个模型更强"当第一问题。 第一问题应该是"代码在哪里被改"。

九、2026 主流趋势判断

趋势一：从"选工具"转向"选运行时"

生态里已经有 33 款左右的 AI 编程工具（两年前这个数字大约是 5）。数量的膨胀必然带来新的抽象层：把 Claude Code、Codex、Cursor、OpenCode、Hermes 都当成可插拔的运行时，上层由自建框架统一调度，硬约束只有两条------审批和预算。

谁能把"换个运行时"这件事的成本降到接近零，谁就掌握下一轮入口。

趋势二：规则文件成为团队资产

AGENTS.md 从个人技巧变成团队约定，理由很朴素：工具会换，规则不该重写。同一份规则要在 IDE、终端、云端三处都生效，格式就必须开放、必须中立。

可以预期的是，规则文件会继续长出分层结构（全局 / 仓库 / 目录级）和条件触发机制，并向 CI 校验方向延伸。

趋势三：权限模型从"信任"转向"可证明"

read-only / workspace-write / danger-full-access 这类三档沙箱加独立审批策略，正在成为行业事实标准。背后的驱动力是审计要求：企业要能回答"上周 agent 到底动了哪些文件"。

接下来值得关注的演进方向：细粒度的工具级授权（不是整条命令放行，而是按具体参数约束）、操作留痕与回放、以及协议层的签名机制。

趋势四：成本控制从"事后感知"变成"设计约束"

2026 年最真实的痛点之一是"模型能力越来越强但成本失控"。harness 因此开始承担预算职责：分任务限额、超时强制中止、优先用小模型做简单判断、把大模型留给真正难的推理。

判断一个 harness 好不好，会越来越看它能不能让你放心地设预算上限。

趋势五：从单 Agent 到多 Agent 编排

Claude Code 的 Dynamic Workflows、Codex 的桌面 App 并行管理、Cursor 的 Agents Window，都是同一个方向。单个 agent 的线性会话已经装不下真实工作了。

但要清醒一点：多 Agent 的收益远小于它的宣传。任务拆分本身有成本，拆分质量差时，多个平庸 agent 协作不如一个强 agent 独立完成。真正的瓶颈从来是任务分解的清晰度，不是并发数。

趋势六：视觉化交互成为标配

Design Mode（指哪改哪）、Annotation Mode（圈选批注）这类能力在 2026 年密集出现在主流产品里。原因很实际：用文字描述"哪个元素"太痛苦，前端开发的反馈循环被 prompt 表达精度卡住了。

可预期的下一步是语音输入、多模态上下文（截图直接进对话），以及从"描述意图"到"直接操作界面"的进一步迁移。

趋势七：可复现性与评估

当 agent 开始自动提 PR，团队就必须回答"这次改动比上次好吗"。基准测试在工具选型中的权重正在上升，同时一套针对自己仓库的任务集（比如 30 个真实 PR 的修复任务）比公开榜单更有参考价值。

十、一页速查表

概念

Agent = 司机（负责想）；Harness = 车（负责做）
选型顺序：先定 harness，再挑 agent 能力

三条路线

IDE 内 Agent：零迁移、视觉反馈即时，适合小步快跑
终端 Agent：仓库级上下文、可进 CI，适合重构与批处理
云端 Agent：隔离环境执行、产出 PR，适合长任务

选型四问

代码最终在哪里被改？
谁能碰哪些文件？（沙箱 = 边界，审批 = 时机，两者独立）
谁买单、额度怎么算？
上下文从哪来？（AGENTS.md 写了吗）

主流工具一句话

Cursor：VS Code 分支，四种模式并存，迁移成本最低
Claude Code：终端优先，长上下文 + CLAUDE.md，复杂重构见长
Codex：Rust 开源内核 + 五个表面，权限模型最完整
Gemini CLI：GCP 生态与合规最全，GEMINI.md
OpenCode 等：MIT 开源、可审计可定制、私有化部署

权限速记

日常：workspace-write + on-request
CI：exec / headless + 最小权限
旁路：只进容器与一次性 Runner，日常别碰

十一、写在最后

AI 编程工具这一年的变化，本质上不是"AI 变强了"，而是边界清楚了：

模型是司机，能力上限由它决定，但一年之内各家模型的差距在缩小
harness 是车，工程质量决定你能不能把上限兑现出来
工具在变多，但真正拉开效率差距的是上下文管理、权限设计和成本控制这三件事
规则文件是唯一值得沉淀下来的资产

所以选型的正确姿势不是追最新、也不是比评分，而是回答清楚四个问题，然后把规则文件写好。工具会换第三次，规则不会白写。

AI IDE 与 Agent Harness：一次说清 Cursor、Codex 该怎么选

目录

一、先把两个词掰开

1.1 AI IDE：编辑器是本体，AI 是长在编辑器里的一层

1.2 Agent Harness：模型是发动机，Harness 是整台车

1.3 一个更直白的比喻

1.4 边界在哪：一张表说清

二、2026 年的三条主流路线

2.1 路线一：IDE 内 Agent（Cursor、Copilot、Windsurf）

2.2 路线二：终端 Agent（Claude Code、Codex CLI、Gemini CLI）

2.3 路线三：云端 Agent（Codex Cloud、Cursor Cloud Agent）

2.4 为什么不能只看"模型能力"

三、选型四问

第 1 问：代码最终在哪里被改？

第 2 问：谁来兜底：谁能碰哪些文件？

第 3 问：谁买单：额度怎么算、能不能进预算？

第 4 问：上下文从哪来：规则怎么沉淀？

四、Cursor 拆解：把 AI 装进 VS Code

4.1 四层能力

4.2 关键差异：前台 vs 后台

4.3 规则文件

4.4 适合谁

五、Codex 拆解：一个 Harness，五个表面

5.1 一个内核，多个表面

5.2 权限模型：这是 Codex 最值得学的部分

5.3 适合谁

六、其他几种典型形态

6.1 Claude Code：终端优先的长上下文专家

6.2 Gemini CLI：GCP 生态与合规

6.3 开源系：可审计与可定制

6.4 主流 CLI 的"跳过权限"对照

七、上下文与协议层：2026 年真正在收敛的东西

7.1 AGENTS.md：静态项目上下文层

7.2 MCP：Agent 的"手"

7.3 A2A、AG-UI 与 Skills

八、面向不同人群的推荐路线

8.1 关于"组合使用"

8.2 三个常见误区

九、2026 主流趋势判断

趋势一：从"选工具"转向"选运行时"

趋势二：规则文件成为团队资产

趋势三：权限模型从"信任"转向"可证明"

趋势四：成本控制从"事后感知"变成"设计约束"

趋势五：从单 Agent 到多 Agent 编排

趋势六：视觉化交互成为标配

趋势七：可复现性与评估

十、一页速查表

十一、写在最后

参考来源