当前AI编程工具领域呈现百花齐放态势，Cursor、Trae、Claude Code、Codex等国内外产品竞相角逐。继前期发布的Claude Code入门指南获得积极反馈后，应读者广泛需求，本文将系统解析OpenAI官方出品的Codex编程助手，深入探讨其核心竞争力、部署方案、上手路径及避坑技巧。

Codex脱颖而出的核心优势

Claude Code虽功能强大，但存在两大显著短板：免费额度限制严格且定价高昂，同时Anthropic官方账号管控政策导致封号风险持续高企。针对此类痛点，开发者社群频繁咨询OpenAI是否有对标方案。答案明确肯定——Codex不仅具备同等编码能力，更在系统稳定性与GitHub集成方面表现优异，成为值得信赖的替代选择。

Codex全景解读：不只是代码生成器

Codex是OpenAI官方推出的智能编码解决方案，具备需求理解、代码生成、命令执行与缺陷调试等核心能力。其设计架构支持四种运行模式，全面覆盖差异化使用场景：

• CLI命令行模式：在终端环境中运行，满足纯键盘操作偏好，实现黑框式全局控制
• App桌面应用：提供图形化界面，兼容macOS与Windows系统，规避终端交互复杂性
• Web网页版本：浏览器直接访问，免安装部署，适配临时设备或应急代码调整需求
• IDE插件形态：深度整合VS Code、Cursor及Windsurf，实现编辑器内无缝调用，自动携带代码上下文

四种模式无绝对优劣，建议根据个人操作习惯与具体场景灵活选用。终端爱好者优选CLI，可视化需求选择App，轻量场景使用Web，日常开发则推荐IDE插件。

2026年Codex重大更新解读

将Codex简单定义为"OpenAI版Claude Code"已无法涵盖其完整价值。自2026年起，Codex完成从对话式编码助手向"AI工作流系统"的战略转型。

根据官方更新日志，2026年4月核心迭代包含三项关键升级：

1. Codex App 26.415（2026-04-16发布）：桌面端升级为全功能AI工作台，新增内置浏览器、任务侧边栏、GitHub PR处理、制品查看器、记忆系统、多终端支持、多窗口管理及Windows托盘适配等特性

2. GPT-5.5模型集成（2026-04-23上线）：GPT-5.5正式接入Codex，显著增强复杂实现、代码重构、深度调试、测试验证等重型任务处理能力，使其从脚本生成工具升级为可承接生产级项目的工程平台

3. Codex CLI 0.128.0（2026-04-30发布）：命令行引入持久化/goal工作流，支持长期目标的创建、暂停、恢复与清理；同步新增codex update指令，并在权限控制、沙箱隔离与插件扩展方面实现精细化提升

上述演进揭示了一个本质转变：评估Codex的标准不应仅停留在"能否编写代码"，而应聚焦于"能否承接工作流中重复性、复杂性、跨文件、需验证的工程任务"。本教程聚焦入门实践，高级功能将在后续专题中深度展开。

Codex最佳应用场景分析

以下五类开发者最适合立即投入Codex生态：

1. 已订阅ChatGPT Plus/Pro用户：建议优先体验Codex，每月20美元以上的订阅价值将得到充分释放，超越常规文本生成场景
2. 偏好图形化界面：厌恶终端交互，期望通过鼠标点击完成核心操作
3. 重视账号稳定性：需要官方工具构建可靠备用工作流，规避封号风险
4. 寻求低成本试错：Codex包含在现有订阅内，以官方客户端显示为准，建议先验证可用性再决策
5. 认可GPT模型代码能力：对GPT系列在代码编写、解释与修改方面的表现持有信心

未订阅ChatGPT服务的用户同样可通过配置国内大模型API实现低成本接入，后续章节将提供完整方案。

Codex安装全攻略：四种方式任选

Codex部署流程简洁高效，主流配置环境均可顺利完成。以下分模式详解操作步骤：

环境准备

系统需预装Node.js与git，在终端执行以下命令验证：

node --version
npm --version
git --version

若环境缺失，请先行安装。此环节为前置依赖，任何遗漏均可能导致后续报错。

Node.js获取地址：https://nodejs.org/zh-cn/download Git获取地址：https://git-scm.com/install/windows

特别提示：Windows用户如遭遇环境配置障碍，建议优先选用App模式。CLI模式虽可用，但如遇疑难可考虑WSL方案或直接切换至App。

CLI模式安装

命令行模式面向终端重度用户，提供两种安装途径：

# npm全局安装
npm install -g @openai/codex

# Homebrew安装（限macOS）
brew install --cask codex

安装验证命令：

codex --version

返回版本号即表示成功。若执行失败，请优先核查Node.js、npm全局路径配置及网络连通性。

App模式安装

Windows用户可通过微软商店获取： https://get.microsoft.com/installer/download/9PLM9XGG6VKS?cid=website_cta_psi

先前我一直使用Cursor进行“氛围编程”（vibe coding），却频频被token快速消耗的问题困扰。恰好我订有ChatGPT Plus，于是决定转投Codex体系。

然而，受众所周知的环境限制，即使开启了网络代理，当我在VSCode中通过Remote-SSH连接远程服务器后，依然遇到了登录异常，见下图：

本以为这只是个小网络故障，结果从下午排查到深夜。最终定位到三个层面的问题交织在一起：代理出口、OAuth回调以及插件IPC权限。过程踩了不少坑，整理出来希望能帮到有同样遭遇的朋友。

首先，我在远程服务器上确认当前代理链路走向：

echo $http_proxy $https_proxy $all_proxy
curl -x http://127.0.0.1:7890 https://api.ipify.org; echo
curl -x http://127.0.0.1:12789 https://api.ipify.org; echo

发现本机7890端口已被占用。我便将远程入口端口改为12789，并让它转发至本机实际代理端口（本机为7897）。

本机SSH config最终配置如下：

Host <你的服务器名称>
  HostName <你的服务器IP>
  User <你的用户名>
  RemoteForward 12789 127.0.0.1:7897
  LocalForward 1455 127.0.0.1:1455

两条转发缺一不可。RemoteForward负责让远程服务器借助本机代理出网，LocalForward则用于浏览器OAuth回调回流至远程服务器的1455端口。

之后回到远程，将Shell环境中的代理统一指向12789（即SSH反向转发入口）：

export http_proxy=http://127.0.0.1:12789
export https_proxy=http://127.0.0.1:12789
export all_proxy=socks5h://127.0.0.1:12789
export NO_PROXY=localhost,127.0.0.1,::1
export no_proxy=$NO_PROXY

验证出网是否成功：

curl --max-time 10 -x http://127.0.0.1:12789 https://api.ipify.org; echo

此时返回了一个新的出口IP，表明远程已确实走通了本机代理链路。

接着，我在远程的Cursor设置里配置HTTP代理：

{
  "http.proxy": "http://127.0.0.1:12789",
  "http.proxySupport": "on",
  "http.noProxy": ["localhost", "127.0.0.1", "::1"]
}

至此，网络连接和OAuth回调环节基本没问题，已经能够通过Codex CLI成功登录。然而，Codex插件却在这时卡死不动。

这一步最为坑人，起初我一度以为是网络问题再次发作。后来仔细查看日志，才发现是IPC权限错误。排查使用了下面几条命令：

grep -R "codex-ipc\|EACCES" ~/.cursor-server/data/logs -n
ls -la /tmp/codex-ipcid

结果发现机器上/tmp/codex-ipc的属主是另一个用户，权限为drwxrwxr-x，我并无写入权限，因此插件无法在其中创建ipc-1007.sock。解决办法并非重装插件，而是给自己设立一个私有的TMPDIR，让IPC不再落入共享的/tmp/codex-ipc中。

2026年4月的港股市场，一家新锐企业引爆了投资圈。

迅策科技挂牌未满四个月，市值从156亿港元狂飙至1100亿，涨幅高达500%。德意志银行为其开出351港元的目标价，全球顶级投资机构KKR账面浮盈超过40亿港币，而当初A轮入局的首批资本，账面回报已突破惊人的500倍。

就在同一个月，国内电商平台上涌现出大量售卖"Token"的店铺。标价从数元到数十元不等，商品描述充斥着"稳定中转"“低价API"“免翻墙"等诱人字样。

同样名为"Token”，却分属于两个平行宇宙——一边是资本追捧的千亿级上市公司，一边是游走于灰色地带的个体小商户。这个小小的词汇，承载着两种天差地别的商业逻辑。

第一重世界：倒卖Token的灰色地带

先拆解那些网店究竟在贩卖什么。

OpenAI、Anthropic、Google等AI巨头采用双重策略：既推出按量计费的商业API，也提供免费档位的网页版服务。后者面向终端用户，但底层调用的仍是真实模型能力。

技术爱好者发现，网页版登录后生成的OAuth令牌具备调用模型的完整权限。通过拦截并中转这些Token，完全能将"免费额度"包装成"API服务"对外分销。

整个产业链由此成型：批量注册账号囤积OAuth凭证，搭建中转层实现请求转发，以低于官价30%-70%的定价卖给开发者和个人用户。

中间商攫取的是信息溢价与技术门槛。免费额度本身零成本，但普通用户既不了解利用方式，也缺乏自建能力。3到10倍的加价幅度成为行业常态。

但这只是灰色产业链的冰山一角。更主流的玩法是"正规采购，分层转售”。

GitHub上斩获3.2万Stars的开源项目One-API成为行业基础设施。用户只需填入各家大模型的API密钥，系统便自动完成接口聚合、负载均衡、多账号轮换与计费管理。Docker一键部署，启动成本控制在3000-8000元之间。

技术部署毫无壁垒，真正的护城河在于市场端——获客成本、信任建立、持续运维，这些都无法用开源代码解决。

用户为何甘愿支付溢价？答案浓缩为四个字：省心、避险。

官方渠道强制要求外币信用卡支付，国内大量开发者望而却步；各家API规范迥异，同时接入需编写三套代码；官方服务偶发限流，单点故障导致业务停摆；更致命的是封号风险，因IP异常或支付问题触发风控的案例在开发者社区屡见不鲜。

中转平台恰好击中痛点：支持微信支付宝人民币结算、统一接口实现模型无缝切换、多线路冗余保障服务稳定、密钥池轮换分散封号风险。用户购买的并非神秘渠道，而是风险溢价与便利性。

有人将这门生意推向了极致。OpenRouter平台聚合了数百个AI模型接口，用户通过其统一入口调用，平台抽取5%的流转佣金。年处理调用费用突破1亿美元，意味着年入500万美元的中介费。a16z为其注资4000万美元，估值达到5亿美元。

颇具戏剧性的是，OpenRouter创始人Alex Atallah此前缔造了NFT巨头OpenSea。当NFT浪潮退去，他将"聚合平台"思维平移至AI领域——不生产模型，只做流量分发。这是一种永续收费站模式：只要AI调用需求存在，过路费便可源源不断。

无论是淘宝小店还是OpenRouter，本质均为流通套利。低价收储，溢价分销，盈利空间取决于信息差与操作便利性。但这类模式的致命缺陷同样显著：差价空间易被价格战侵蚀，平台政策收紧即断粮，客户掌握直连路径后随时可能跳单。

第二重世界：炼Token的千亿赛道

迅策的"Token"则是完全不同的物种。

2025财年，迅策营收12.85亿元，同比增长103%。真正惊艳的是增长曲线——上半年仅1.98亿，下半年暴增至10.87亿，环比激增449%。客户数稳定在230家，但客单价从272万跃升至559万。

增长动力并非来自客户扩张，而是存量客户的深度穿透。

其Token定价高达10-100美元/百万Tokens，是Anthropic同类产品的十倍以上。当通用Token价格持续走低，其垂类Token为何逆势上涨？

核心在于企业AI落地的真实痛点。金融、制造、医疗等行业的核心数据散落在十几个异构系统中，格式混乱、标准缺失、知识孤岛现象严重。未经处理的原始数据如同原油，再强大的模型也无法直接消化。

迅策扮演的正是数字炼油厂角色。通过实时数据湖仓、行业知识图谱、RAG增强检索与智能体编排，将各行业脏数据"炼制"为可直接投喂大模型的高质量场景Token。

通用Token可能需要100次交互才能得到有效结果，而迅策的垂类Token一次命中。客户核算的是综合成本而非单价。即便贵十倍，但省却99次无效调用，总成本反而下降50%-70%。

更关键的是其"三维增长引擎"：收入=Token单价×调用频次×模块渗透率。三个维度同步提升：垂类场景稀缺性支撑价格攀升，AI应用深化带动调用量爆炸，产品模块渗透创造交叉销售。这构成了指数级增长飞轮。

2026年Q1，其Token相关ARR（年度经常性收入）季度环比暴增300%。德银预测2025-2028年营收CAGR达76%，经调整净利率从6.9%攀升至24.4%。

倒卖Token赚的是"搬运费"，炼Token卖的是"精炼燃料"。前者按吨交易原油，后者按升供应航空煤油，十倍价差天经地义。

两种模式的核心分野

将两个世界并置，分界线清晰可见。

倒卖模式攫取流通价值。 低买高卖，依赖信息差与便利性，天花板由透明度决定——一旦客户掌握直连方式，价值瞬间归零。

炼制模式创造转化价值。 将数据原油转化为场景燃油，依赖技术壁垒与行业know-how，护城河随数据飞轮转动而加深。

一个宣称"我为你省麻烦"，另一个承诺"我让你的数据成为AI燃料"。前者是增值服务，后者是基础设施。

增长逻辑更是云泥之别。

倒卖呈线性特征——每新增一个客户增加一份收入，但客户可随时流失。价格战挤压利润，政策变动切断供给，规模越大风险越集中。

炼制呈指数特征——同一客户场景越深，调用量越大；行业知识图谱越完善，精炼成本越低；客户数据反哺模型，壁垒越用越厚。迅策将其总结为"数据清洗技术优化→调用效率提升→场景拓展→调用量增长→营收扩大→研发投入加码"的正向循环。

简言之，一个"搬砖"，一个"炼钢"。搬砖日日归零，炼钢一旦成炉，边际成本递减。

但1100亿市值背后，市场已注入极高预期。

迅策必须直面三大拷问：

其一，场景Token的定价权是否可持续？ 10-100美元的溢价建立在垂直场景稀缺性上。但阿里云、腾讯云、天翼云等巨头正携数据资源优势强势入局。当金融、制造等行业的数据精炼能力成为大厂标配，垂类Token的稀缺溢价能否维系？

其二，盈利拐点是否真实可靠？ 2025下半年经调整净利5013万元首次转正，但全年仍亏1.3亿。综合毛利率从76.68%骤降至61.66%，应收账款周转天数长达131天，金融资产减值损失从1805万飙升至1.61亿。盈利质量与持续性有待更多财报验证。

其三，Token收入占比能否快速提升？ 当前Token付费收入占比仅5%，公司计划2026年底提至20%-30%。若下半年增速不及预期，市场情绪可能急剧反转。毕竟500倍回报的背面，是对应量级的业绩预期。

千禧年互联网泡沫中，无数".com"公司享受过离谱估值，退潮后才发现多数在裸泳。迅策确有本质不同——它踩在真实产业趋势上，具备技术壁垒与客户粘性。但千亿市值需要千亿业绩支撑，这是无法逃避的算术题。

Token经济的未来启示

两个世界的并置，揭示了一个更深层的趋势：

Token正成为AI时代的核心结算单位，但围绕Token的商业模式已分化为两条迥异路径。

路线一是"搬运"——将Token从低价区转运至高价区，赚流通环节的辛苦钱。门槛低、启动快、天花板明显、生命周期短。淘宝个体户、API聚合商、全球收费站均属此列。

路线二是"精炼"——将原始数据转化为高纯度场景Token，赚技术赋能的价值钱。门槛高、启动慢、天花板极高、生命周期长。迅策在垂直行业的数据炼化即为代表。

两条路线的定价逻辑完全背离：搬运价值随通用Token降价而内卷，精炼价值随场景稀缺性而攀升。

国家数据局监测显示，中国日均Token调用量从2024年初的1000亿，激增至2025年底的100万亿，2026年3月进一步突破140万亿——两年增长超千倍，单季增幅达40%。这轮指数级爆发既哺育了搬运路线的毛细血管，也撑起了精炼路线的千亿巨头。

但周期总有拐点。当AI支付与接入基础设施日臻完善，搬运路线的生存空间将持续萎缩。而精炼路线的护城河，却会随着行业数据飞轮的转动愈发坚固。

倒卖Token是一门生意，但难成基业。炼Token才是AI时代的真命题。

只是，在炼油厂投产之前，必先熬过漫长的烧钱期。迅策从2016年蛰伏至2025年，整整十年才迎来下半年首次盈利。千亿市值是终点而非起点，是犒赏而非入场券。

昨晚十点半，屏幕那头的客户正笨拙地尝试将API密钥与基础接口地址填入Claude Code配置栏。我这边连续截取了十几张标注图，配合着一步步文字说明，整整指导了四十分钟。

“要不…你直接远程操作吧？“对话框里终于跳出这句话。

连接远程桌面的瞬间，我熟练地在三十秒内完成了所有参数配置。客户当场充值了五美元试用额度。这类场景今年已重复上演二十余次，每次都在提醒我：我的用户群体，从来不是理想模型里的技术从业者。

行业观察家的理论模型与现实落差

前日拜读某篇分析API中转站赛道的深度文章，其构建的「不可能三角」框架令我陷入沉思：合规性、跨境大模型服务、本土市场扩张，三者构成无法共存的顶角，必须舍弃其一。

该文断言，99%的运营者会主动放弃合规角，由此推演出四大系统性代价：行业准入门槛趋近于零、业务天花板清晰可见、道德风险持续累积、定价话语权完全丧失。笔触冷静犀利，将这门生意的底层困境剖解得淋漓尽致。

文中列举的生存法则，我逐条对照自检，竟无一能落地执行。

理想策略与落地困境的冰火两重天

第一条：聚焦开发者与小团队，坚决规避C端用户。

现实却是我80%的客户连GET请求与POST请求的区别都说不清。他们通过闲鱼搜索"Claude Code"而来，听闻AI工具能提升效率便想尝鲜的普通用户。若严格筛选客户画像，我的日活订单将归零。这并非战略选择，而是生存所迫。

第二条：隐去大模型品牌名称以降低风险。

可这门生意的本质就是售卖Claude、GPT等头部模型的调用权限。若模糊化处理品牌标识，用户购买意愿将断崖式下跌。这不是可选项，而是价值传递的基本前提。

至于设立双法人主体、零广告投放、提前布局海外身份等建议——逻辑上无懈可击，却离我当前「每日应对封号危机」的生存阶段太过遥远。

圈内人的真实战况：号池吞噬一切利润

运营中转站的最大开支绝非服务器租赁，而是账号池的滚动维护。服务器月费仅需数百元，在成本结构里几乎可以忽略。

但账号池是个无底洞——持续采购、养号激活、紧急补号，构成了一条永不停歇的资金消耗链。官方风控策略每周微调，你上周验证有效的规避手法，本周可能彻底失效。不是阶段性封禁，而是全天候对抗。

清晨醒来，批量检测脚本总能给我"惊喜”：昨夜又有三成账号失效。这种感觉如同经营实体店铺，却每天无法预知能开启几扇营业门。更残酷的是定价博弈：提价则用户流失至竞品，降价则本就微薄的利润被账号损耗直接吞噬。

最终醒悟，日常运营的真实形态不是精细化管理，而是持续不断的灾难恢复。

明知山有虎的坚守逻辑

Token即AI时代的电力基础设施——人人必需，处处可用，且需求量呈指数级增长。对普通创业者而言，寻找「年入百万级」且具备高度确定性的项目，中转站几乎是唯一解。

它拥有恰到好处的准入壁垒，又恰好踩在刚性需求的红利期。诚然存在合规隐患，存在账号池覆灭风险，但试问当下哪个平民生意没有致命短板？

开奶茶店需赌对选址，做直播电商需砸钱买量，玩自媒体需熬过漫长的冷启动。相较之下，中转站至少能在首月实现现金回流。那位作者在外围画出了完美的规避箭头，而我身处三角旋涡中心，发现每面墙都是必经之路。

不是看不懂终局，而是看清所有陷阱后，仍认定这场博弈的期望值为正。

![Image](https://watermelonwater.tech/insights_imgs/Token中转站生意终局解析5.webp]

这两年有个词被反复滥用，那就是 AI 原生，AI Native。可一旦认真追问“到底什么才算 AI 原生”，立刻就会发现各家各派全在自话自说，梳理下来通常会在以下三个层面混为一谈：

1. AI 原生思维；
2. AI 原生系统/架构；
3. AI 原生应用/团队；

一旦这三个维度缠在一起，很容易就囫囵吞枣般地抛出一句大而化之的论断：只要把 AI 当成底座，一切就都是 AI 原生。

结果呢？仍旧很虚，依然搞不懂评判标准是什么。但这其实很正常，因为：

在高速发展期，标准本来就是缺失的。

就像移动互联网早期，真正奠定移动端交互范式（Tab、图文流）的是微博，随后微信做了收敛，后来抖音用视频给出了另一种“原生”答案，而小红书又拿出一套截然不同的解法。

这件事本来就没有考试一般的标准答案，有人愿意用，用得舒服，就是硬道理。

什么是真正的 AI 原生应用？

回到 AI 原生应用这个主题，我觉得昨天一位前同事的话格外传神：

所谓 AI 原生，不就是 AI 自己生出来的嘛。

先别笑，由 AI 而生，为 AI 而生，恰好就是一个判断 AI 原生挺不错的标尺。以下就有两个极其典型的例子：GEO 和 CLI 改造。

GEO：为模型而生的内容工程

第一，GEO 这个产品形态，完完全全是因 AI 而诞生的。它天生就适应模型的习惯，专门去创造对模型亲和的内容与服务。

更准确地说，如果大模型不存在，就根本不会有 GEO，正如没有浏览器/搜索引擎就不会有 SEO 一样。

SEO 时代优化的是搜索引擎，目标是让用户在搜索结果前排看见你；
GEO 时代优化的则是模型的知识选择机制，目标是让 AI 在回答问题、执行任务时，优先采纳你。

两者的本质差别在于：

1. SEO 争的是展示位；
2. GEO 争的是引用权、解释权，甚至调用权。

目标不同，载体不同，行为也就彻底不同。 因此，GEO 从一开始就不是写给人类阅读的，而是一套写给模型消费的内容工程。

于是，GEO 所关注的便不再只是关键词、标题和外链，而是：

最近不少工程师朋友在讨论：OpenAI Codex、Claude Code、Google Antigravity、OpenCode，这些工具到底有什么本质区别？做工程、做产品的团队，或者初创企业，又该优先掌握哪一个？

如果只是把它们当作四个独立的软件来比较，很可能会陷入“哪个更强”的表层争论。更准确地说，它们代表了AI编码代理（AI Coding Agent）正在成型的四种工程路线：

1. OpenAI Codex：平台化工程Agent路线
2. Claude Code：代码库深度理解与多文件执行路线
3. Antigravity：以Agent为中心的IDE路线
4. OpenCode：开源可控、模型灵活选配路线

本文并不打算做一份“最强排行榜”，而是想从真实工程实践出发，解释清楚：当我们着手构建一个像 Project Velocity 这样的AIoT系统时，如何理解这四种Agent工作方式的差异，以及它们各自适合什么样的场景。

一、为什么不能只问“哪个Agent写代码最快”

很多人刚开始接触AI编码代理时，最容易关注这些问题：哪个生成代码速度最快？哪个模型最聪明？哪个最接近人类程序员的思维习惯？

这些问题当然有价值，但它们还远远不够。因为真实的工程开发从来不只是写一个函数。

以 Project Velocity 为例，我们正在做的是一个端到端的 MCU–Edge–Cloud AIoT 系统，涉及：

• STM32F103 节点运行 Zephyr RTOS；
• 节点上连接着传感器、继电器、红外、LCD、按键、CAN 总线；
• Edge 侧用 RK3588 / Linux 作网关；
• 上层通过 MQTT、OPC UA、ThingsBoard 实现遥测、控制与可视化；
• 还需要考虑硬件映射、协议转换、日志、测试、远程维护和版本管理。

在这种复杂系统里，AI Agent的工作远不止“帮我写代码”。它必须理解：

• 硬件资源在哪里，哪些 GPIO、I2C、UART、CAN 已被占用；
• Zephyr 的 device tree overlay、prj.conf、main.c 之间如何保持一致；
• Edge gateway 的数据模型与云端如何对应；
• 修改了一处代码，会不会影响协议、测试、部署以及后续的维护。

所以，真正应该问的问题不是“哪个Agent最出色”，而是**“哪一种Agent的工作方式，最贴合你当前工程场景的需求？”**

二、Codex 路线：从代码补全走向工程任务委派

Codex 代表的是一种十分清晰的平台化路线。它并不仅仅停留在一个聊天窗口里，也不是简单的IDE插件，而是逐渐渗透到多个开发环境：本地终端、IDE、Web、GitHub、云端执行环境、PR review，甚至支持多任务并行。

这条路线的核心不再是“补全下一行代码”，而是：你可以把一个工程任务整体交给 Agent，它在自己的上下文中阅读代码、修改文件、运行命令、检查输出，然后把结果交给你来审核和合并。

在 Project Velocity 这类项目中，我们可以把许多任务委派给 Codex：

从去年开始，整个AI世界愈发呈现出“乱花渐欲迷人眼”的景象：

1. 前一日刚推出Manus，次日便冒出一个Lovart；
2. Cursor的热度尚未消散，Claude Code 就已经成为AI编程领域事实上的领先者；
3. 刚还在讨论提示词怎么写，资深的从业者就断言RAG已经过时，随之抛出“上下文工程”的概念；
4. 正当我们为Coze的开源而惊叹时，Google Nano Banana已经刷遍了朋友圈；
5. 飞书发布会还在浓墨重彩地介绍多维表格，钉钉便迅速跟进，强势推出AI表格；
6. 医疗AI领域的OpenEvidence估值高达120亿美元，法律AI Harvey的估值据说也接近110亿。

随后，OpenClaw骤然走红，迅速掀起了一场“百虾大战”：

而结果大家都已了然——OpenClaw 并没有活跃太久便逐渐式微，与此同时，Hermes 又接踵而至。

正是在这种情形下，我反而生出一丝庆幸：在AI时代，如果学得足够慢，似乎也就真的不用急着去学了……

与此同时，互联网公司的裁员消息此起彼伏，一则颇为夸张的传闻称某小破站裁员比例高达60%！

出于对就业市场整体情绪的关切，我在几个社群中对产研人员进行了调研，结果令人感慨：超过一半的人认为，到2026年很可能会有半数程序员面临失业，接近三分之一的人认为这一概率“有一定可能”。

此后，OPC风向渐起，若换作你我是普通打工人，又如何能不为未来焦虑？

那么，老板们的处境就轻松吗？

看不懂的老板

他们当然同样焦虑。仅就我在年后接触的众多老板来看，其焦虑程度甚至更为深重，而原因也十分直接——他们确实难以看懂。

比较典型的一个案例是：西安一位企业主带着整个管理团队专程赶来成都，只为当面与我交流一回……

他们所从事的是传统工业信息化领域，偏重ERP模块，公司已经稳定运营了15年。

按照老板本人的说法，在过去，他们一直顺风顺水，一切都在既定轨道上推进。可AI一出场，就将他们彻底打懵了。如今不单是他们感到困惑，就连金蝶、用友这类大厂也同样满头雾水，而那些大企业调整航向则更加迟缓。

据该公司的技术负责人讲述，老板几乎焦虑得夜不能寐，天天追问接下来该如何转型，还经常在深夜往群里转发大量关于AI的信息。

我完全能理解他们的焦虑，只不过接下来的场面就有些令人意外了：在简要介绍了自家业务之后，他们竟然直接向我发问，问我他们接下来应当制定怎样的AI战略。然而，这个问题我又怎能轻易回答？

一方面，这里存在信息量的巨大不足；另一方面，这当然还有价值对等的问题……

混乱是因为角度问题

无论是上述的打工者还是老板，他们都深陷焦虑。在AI时代，焦虑几乎成为一种常态，其背后隐藏着许多耐人寻味的故事。比如，最近频繁出现的“蒸馏.skill”就是其中之一：

我无从知晓是哪位极具创意的同行最先提出了蒸馏一词，并将其定义为skill来实现，我猜测最初可能只是无心之举，然而后继的发展却十分夸张：

1. 还真有老板跑来跟我说，想把某人的能力“蒸馏”一下；
2. 也确实有员工因此而担心自己会被“蒸馏”掉。

天哪，真是“内行看门道，外行看热闹”。如果你真正使用过skill，或者真正尝试去做一次所谓的蒸馏，你就会明白这件事有多么不靠谱。问题倒不在于完全不可行，而是意义极为有限。类似的事情在两年前，我们早就利用Coze实践过了。我印象中，那时流行的是奥德彪式艺术表达：

看似很危险，实则一点也不安全
年轻时很穷，干了几年终于不年轻啦
趁年轻你的多吃苦 老了你就习惯了
虽然路途遥远， 但你别担心，也挣不到什么钱
是金子总会发光，但大家都是老铁
爱情不是生活的全部 打工才是
……

所有这些语句读起来很痛快，但终究只是形式上的相似。我举一个最简单的例子来说明：

1. 试着蒸馏出一个协和医院顶级专家的skill；
2. 再蒸馏出一个“法外狂徒张三”的skill；

如此生成的“东西”所提供的医疗建议或法律意见，你敢采纳吗？

所谓蒸馏、skill，似乎并没有多少人真正把OpenEvidence与Harvey的估值当回事……

写到这里，或许有人会感到疑惑：开头还在讨论焦虑，为何现在又开始吐槽起来了？

实不相瞒，因为我实在演不下去了——其实我几乎一点也不焦虑，之前的焦虑，不过是刻意表演出来罢了……

相应地，我也绝非单纯为了吐槽。之所以这样说，是想告诉大家：其实，你们也大可不必如此焦虑。接下来，我将带你用一种工程视角去观察AI的发展，或许你的心态就会从容得多：

宏观视角看AI

AI发展至今已经三年多，我们首先要问的是：如何从宏观上总体把握这三年的AI演进？

大家可以先回想一下，在你脑海中，那些标志性事件都有哪些？

请回顾那些真正有影响力的AI事件、那些为你的工作与生活带来改变的AI产品，或者那些对就业市场产生巨大冲击的AI时刻，先后又有哪些？

我们梳理这些事件，为的是将AI世界划分为不同的阶段，这是一种分类思维，分类一旦清晰，看待问题便会愈加透彻。

一个相当经典的分类法，是OpenAI的Sam Altman所提出的L1至L5分级，确实能够说明一些问题：

我们可以对照这张图大致勾勒时间线：

2022年底，ChatGPT 3.5 的发布，标志着我们正式跨入以大模型为核心的AI时代。

整个2023年，堪称百模大战时期，国内标志性的事件是文心、智谱等模型的相继面世，然而都未能激起太大波澜。2023年是国内的AI 1.0阶段，各家训练类公司最终留下的，更多是一地鸡毛。

进入2024年，我们常说的AI 2.0时代到来，那是一个以RAG为主导的阶段。当时的情况相当微妙：经历过百模大战的消耗，许多公司账上已近枯竭，对“训练”二字深恶痛绝。

Anthropic 将筹码押在终端，Cursor 死守 IDE，OpenAI 则开辟云端异步代理——三条截然不同的技术路线，对应三款工具对未来编程形态的完全对立的设想。本文从底层架构到六类真实开发场景，逐一拆解它们的能力边界，同时涵盖成本对比、组合策略与下半年趋势判断，帮助你摆脱“该选哪个”的焦虑，找到最高效的工具搭配方式。

AI 编程工具的选择困难，正在成为开发者绕不开的新痛点。面对 Claude Code、Cursor、Codex 这三款话题度最高的帮手，很多人下意识会问：哪一个最好用？但这个问题本身就有误区——因为它们根本不是同一类产品，无法用一把尺子丈量。Anthropic 相信命令行才是未来，Cursor 赌开发者离不开 IDE，OpenAI 则直接把编程变成了后台异步任务。三家公司对“AI 该如何参与编码”给出了完全不同的答案，也就意味着不存在通吃的赢家，只有和手头场景贴合度最高的那一个。

💡 本文核心主张： 不存在“最好的工具”，只有“最适合当下任务的工具”。吃透它们各自的设计哲学和适用边界，才可能做出真正落地的选型。

一、先看清设计理念：三种路线的底层假设

选工具的第一步不是罗列功能，而是读懂它背后藏着什么假设。功能只是皮肤，真正划定能力疆域的是它对“AI 编程应该以什么形态存在”这一问题的回答。

🏗️ AI 编程工具的三种技术路线

Claude Code：终端就是整个工作室

Anthropic 的判断非常激进：未来的开发者根本不需要图形界面，命令行足矣。Claude Code 被设计成一个纯粹的 CLI 工具，不与任何特定编辑器绑定，它在终端里直接读写文件、执行 shell、运行测试、操作 git。这份“原始感”带来了几个其他工具很难复制的优势：

• 无边界工具链整合：
  通过 MCP（Model Context Protocol）可以对接 GitLab、Jira、数据库、日志平台，不受 IDE 生态的约束，几乎任何系统都能接入。
• Hooks 驱动的自动化流水线：
  在代码生成前后自动触发 lint、format、测试，把质量把关变成后台默认行为。
• 子代理并行推进：
  能将复杂任务拆解给多个 Agent 同时执行，大幅缩短整体耗时。

当前版本 v2.1.x 配合 Opus 4.6 模型，具备 200K token 上下文窗口。学习门槛的确不低，需要习惯终端工作流、学会精准编写 prompt、理解 MCP 配置。但一旦跨过这道坎，处理复杂工程任务的效率会有肉眼可见的提升。

从终端敲下指令到 Agent 吐出最后一个字，背后走过了很长一段链路：

1. 消息先被入口收拢，转换成内部统一的消息对象；
2. 会话和上下文被重新组织；
3. 模型开始多轮推理，必要时调用工具；
4. 过程过长时，系统还要整理上下文、保留历史记录，并在任务结束后尝试沉淀经验。

走过这条链路，Hermes‑Agent 的骨架大致浮现出来。但这种方式更像一次源码漫步，遇到什么模块就解释它在消息路径上的职责，撞见某个工程细节就顺手拆解为什么这么做。

问题也恰在于此：跟着流程走容易熟悉框架，却很难真正理解那些散布各处的设计抉择。例如：

1. Profile 为什么依赖 HERMES_HOME 做隔离？
2. 系统提示词为什么越稳定的越要靠前放置？
3. 记忆为何要在会话开始时冻结成快照？
4. 上下文压缩后为什么不覆盖旧会话，而是用父子链新开一个会话？

这些细节单独拆开来看都不算大，甚至只是很小的工程取舍。可一旦放在一起，它们共同指向了一个问题：

Agent 要真正进入工作流，需要的是一套围绕模型构建的工程约束。

上一篇我们沿着消息看见了模块如何运转。这一篇换一个视角：这些模块组合在一起，究竟构成了什么？为什么这些看似零散的设计，最终会汇聚到同一个系统层——Harness。

更进一步：未来的软件是否也要开始为 Agent 做设计和改造？

Harness 是什么

在软件工程里，test harness 是一个成熟的概念：它是指围绕被测代码搭建的基础设施，负责提供输入、捕获输出、管理执行环境，让测试变得可重复、可自动化。被测代码本身不必修改，harness 从外部包裹它，替它处理所有外部依赖和环境问题。

大模型的本质只是一段文字输入，经过推理后输出一段文字。但它不会自己调工具，也不会替你管理上下文、处理错误、记住上一次做过什么。这些能力需要外面有一层系统来补全。

现在我们把这层系统称为 Harness。我更愿意把它看成 Agent 的运行时：模型提供能力，而任务如何推进、工具如何调用、状态如何保存，都交给这层系统。模型是能力源，Harness 决定这股能力能不能从演示走向真实。

几乎所有 Agent 项目的起步阶段都差不多：接入一个模型，写一段系统提示词，挂几个工具函数，再搭一个聊天入口。这个阶段很容易见到效果，尤其针对简单任务、少量工具、模型规模足够时，表现往往相当不错。

但用户的意图没有边界，不会只扔一个孤立问题。今天让 Agent 查资料，明天让它接着昨天的结论修改方案，后天又补充一条新限制。任务执行到一半，会发现文件权限不足、需要确认；运行测试时环境不对；工具返回的错误难以理解。再加上上下文越拉越长、工具列表越来越多，原先“模型加函数”的结构很快就会撑不住。

此时难点已从“会不会调用工具”转换成“能不能在一套可控系统里做事”。如果不在系统层面处理这些问题，就只能把它们塞进 prompt。一开始可能有效，任务一长，这些说明书式的指令很快就会被模型遗忘。这些判断不能全凭模型去猜，必须在模型外面有一层系统把这些事管起来。

起初它们像一堆零散的工程补丁，放在一起看，就是 Harness 的雏形。下面我们沿着 Hermes‑Agent 里几个最典型的设计往下走，每个点都不大，但放到一起，会看到一个 Agent 从聊天壳朝着运行时系统生长的过程。

LLM 与系统

上一篇从一条消息开始。用户输入一句话，表面只是请 LLM 帮忙做事，但系统内部早已发生了多层转换。入口层先把不同来源的消息统一起来：命令行、Telegram、Slack、飞书、Email，这些入口的交互方式截然不同，进入核心后都会被收敛成一套内部的消息对象。

往外走时亦然：模型不需要知道飞书怎么传附件、Discord 怎么带文件，它只需吐出统一的媒体协议，再由网关转换回各自平台的格式。这一步是把平台差异挡在 Agent 核心之外。

再往下是 AI Agent 的主循环：它先决定调用什么工具，系统去执行，然后把结果拿回来，它再根据结果判断下一步，如此反复，直到给出最终回答，或者预算耗尽，又或者用户主动打断。

Agent 做事不会一帆风顺，中间会报错，也需要模型根据工具的执行结果不断思考、重试。一个真正能工作的 Agent，必须允许这种来回调整，否则就只能处理短任务。任务一旦复杂，要么执行不下去，要么直接返回一个看似合理的假结果。

2026 年开年以来，AI 领域迎来两波巨大福利：

第一是 OpenClaw 的爆发，并非因为它直接解决了多少深层问题，而是它首先为 Agent 的普及做出了空前贡献；同时，OpenClaw 基本奠定了由 Agent 驱动 Skills 的基础交付范式。

第二是 Claude Code 源码的泄露，这为许多正在 Agent 赛道上创业的团队提供了大量高质量范本。在 CC 之前，大家对“Harness 驾驭工程”的理解仍是模糊的。

不过，前景虽好，现实依然存在不少问题。根据我的观察与实践：目前 Agent 技术远未成熟，OpenClaw 在执行任务的稳定性与安全性上仍有巨大的提升空间。

因此，后续必然会有越来越多的 Agent 涌现，每次迭代都能前进一小步，比如最近逆势而上的“Hermes”：

Hermes Agent 从 2 月底开源首月即破 2.2 万星，至 4 月 8 日发布 v0.8.0 版本后，单日新增 6400+ 星，不到两个月 GitHub 总星标突破 4.7 万，多日占据全球开源榜首。

OpenClaw VS Hermes

近来常听到“OpenClaw 已死，Hermes 称王”“Hermes 碾压 OpenClaw”之类的言论，说实话，听得有些烦，虽然我自己偶尔也会使用类似标题……

这个 Hermes 到底是个什么东西，又凭什么能与 OpenClaw 一较高下？我们这里还是要回归本质，尽量从工程角度（少量源码切入），为大家展开论述。

首先，OpenClaw 是一个用 TypeScript 编写的 AI 助手平台，工程化程度相当高。我之前写过几篇拆解文章，在本篇开头有链接，可以回顾查看。

Hermes Agent 则由 Nous Research 团队开发，使用 Python 编写，是一套可开源商用的 Agent 平台：