OpenAI把Codex“拆开卖了”文章转载于字母AI
OpenAI昨天一口气打出了四张大牌。
Agents API、GPT-Live-1 API、Data agent、ChatGPT for Financial Services,一天横跨Agent、语音、数据和金融四条产品线,每一条都值得单独拿出来说道。
但这四张牌里,最值得看的可能还是Agents API。
因为这一次,OpenAI把Codex“拆开卖了”。
原本藏在Codex背后、负责让Agent持续工作、调用工具、管理上下文和协同多个Agent的那套能力,被抽出来打包成了云端API,交给所有开发者调用。
1
Codex即服务?
其实,OpenAI早就在拆Codex了。
早在2025年4月,OpenAI刚发布o3和o4-mini那会儿,就把Codex CLI开源了。它有点像OpenAI版的Claude Code,直接就装在本地终端里。Agent怎么跑,怎么调用工具,都明明白白地放在GitHub上,你愿意折腾,就可以自己拿回去改,自己跑。
不过那个时候只是单纯地把东西给了出来,至于你会不会用、想怎么用,那都还是你自己的事。
一个月后,Codex云端版,也就是我们今天所熟悉的那个产品,才正式上线。用户可以把代码仓库交给它,一个任务对应一个独立的云端沙盒,Codex可以自己改代码、跑测试、修bug,还能同时处理多个任务。
又过了几个月,在2025年的10月份,OpenAI发布了Codex SDK。
简单来说,SDK就是给开发者的一套工具包,让Codex不只作为独立产品使用,也可以塞进别人的应用里。SDK允许开发者用几行TypeScript代码启动同一个驱动Codex CLI的Agent,拿到结构化输出,还能保留任务状态,在暂停之后继续跑。
但是呢,SDK主要适合在程序里调用Codex,还没有把完整的Codex交互能力开放出来。它很适合后台的工作流、自动化脚本、服务端的程序。但如果你想做一个像Codex IDE那样的完整客户端,还是有些困难。
于是到了2026年2月,OpenAI正式公开Codex App Server,第一次系统地把Codex里面那套Harness讲清楚了。
OpenAI明确解释,Codex Web、CLI、IDE扩展和Mac App看起来是不同的产品,但底下其实都在运行同一套Codex Harness,也就是负责Agent Loop、Thread、工具执行、认证和管理状态的那层东西。
App Server给这一整套Harness加了一套双向JSON-RPC接口。JetBrains、Xcode或者其他客户端,不需要重新造一个Agent Loop,直接启动App Server,就可以驱动完整的Codex。
有了App Server,其他产品就可以直接接上完整的Codex Harness。
不过走到这里,还有最后一个麻烦没解决。
SDK控制的是本地Codex Agent,App Server本身也是一个需要开发者启动和维持的常驻进程。虽然把Codex接进产品这事已经解决了,但想把它稳定地跑成一个线上的服务,还是有点困难。
举一个比较具体的例子,如果你用App Server做一个自己的Coding Agent网站,前端已经接上了Codex,但当用户点下“修复这个仓库”之后,后续的大量运行和基础设施问题,都还需要你自己想办法解决。
然后就到了8月19日,这一天,OpenAI把过去一年陆续开放的CLI、SDK、App Server统一放进了“开放Codex Harness”的平台叙事里,并明确把Codex从一个产品提升成了平台。
再然后就是(美国时间)9月10日,也就是昨天,Agents API正式开放公测。
这一次,开发者只需要告诉API四件事——任务、模型、工具、运行环境——就可以直接创建一个Agent。负责长会话上下文压缩、工具调度和subagent协作的Codex Harness由OpenAI自己托管和维护。
甚至就连Agent真正干活的机器都能自己选,是用OpenAI的沙盒、自己的基础设施,还是Cloudflare、E2B、Modal等第三方环境,都可以。Harness由OpenAI提供,执行环境由开发者决定。
官方的口径很明确,Agents API本身不额外收费。也就是说,Harness托管、长会话管理等能力,并没有再单独收一层Agent平台费。
开发者按实际使用的模型Token和工具付费;如果使用OpenAI自己的托管沙盒,计算资源另算。
把这一年多串起来,OpenAI一直在做同一件事:把Codex从一个具体产品,一层一层拆成可以被复用的能力,同时让开发者越来越不需要自己操心。
如果一定要给这条产品线起个名字,它其实很像当年的SaaS,只不过这次被服务化的不是软件,而是Codex。
Codex as a Service。
1
Harness也开始分叉了
盯上Harness的当然不止OpenAI。
DeepSeek Harness(后文简称DSH)发布的时候,就给出了一个非常响亮的等式:Agent = Model + Harness。
在DeepSeek看来,模型只是Agent的一半,另一半则是负责让它理解环境、调用工具、管理状态、持续执行任务的Harness。两者互相协调,Agent才能真正执行任务。
DSH把Harness本身做成了一套高度模块化的开放框架:模型、工具、Skills、Session、沙盒、存储、Agent Loop、调度,甚至UI都可以替换。
“一切皆插件”的口号可不是说着玩玩而已,最好大家都来写插件,都来适配DSH,最后不管上面跑的是DeepSeek,还是别的模型,底下都可以是同一套Harness。
这和OpenAI现在走的方向刚好形成了一个挺有意思的对照。
OpenAI虽然也把Codex harness开源了,但Agents API明显是在往另一个方向走:Harness你可以用自己的,也可以拿走开源的,但如果你嫌麻烦,还可以直接不管,让我来替你安排。
所以我们认为,它更像是一种“服务”。OpenAI负责托管和持续维护Harness,开发者只需要决定要让Agent干什么、用什么工具、在哪里执行。甚至以后模型升级了,Harness怎么跟着改,OpenAI也准备一起包了。
某种意义上,现在Harness这一层隐约出现了两条路线:
以DeepSeek为代表的路线更像是在建设开放生态,把每一个零件都做成插件,让开发者自己组装;而以OpenAI为代表的一方则像在押注云服务,把钱和需求给到位,剩下的我帮你解决。
我们甚至可以认为,一个想让Harness越来越像Linux,另一个则想让Harness越来越像AWS。
当然了,这只是个比喻。OpenAI也开源了Codex Harness,DeepSeek未来也并非没有可能提供更多的托管服务。但至少在现阶段,两边产品的重心差别明显。
有意思的是,在把Harness变成服务的这条线上,Anthropic其实比OpenAI更早一步。
早在2025年9月,Anthropic就推出了Claude Agent SDK,把Claude Code背后的工具、上下文管理、权限系统和subagent能力开放给开发者,让别人也能拿这套东西做Agent。
今年4月,它甚至比OpenAI更早推出了Claude Managed Agents。Session、Harness和沙盒被拆成三个独立层:Anthropic负责托管harness和长任务,沙盒既可以由Anthropic提供,也可以接入别的执行环境。这个思路和今天的Agents API其实已经相当接近,Anthropic自己给它的定义就是“一个用于长期Agent任务的托管服务”。
所以某种意义上,OpenAI这次是在沿着Anthropic已经走过的路继续往前走,区别只不过是OpenAI手里有一个更“产品化”的Codex。
但因为Codex和Claude Code长期给人的产品印象还是不太一样,所以即使它们讲的是同一套故事,带来的感觉也大相径庭。Claude Code给人的感觉更像是让开发者坐在终端里和Agent一起写代码,而Codex App一开始强调的就是“同时监督多个长期Agent”的界面。
顺带一提,谷歌也早已加入这条路线。今年5月的I/O大会上,Gemini API推出Managed Agents,同样把Antigravity Harness和沙箱做成了托管服务。但谷歌的牌面不止于此,这一点咱们后面再讨论。
不过话说回来,谁先谁后好像也不是那么重要……最后当然是谁把自家的Harness变成开发者默认的那一层,谁才能吃下最大的蛋糕。
1
谁是大赢家?
说到底,为什么现在模型公司都开始抢Harness了?
就像是DSH给出的等式那样,Agent = Model + Harness,模型可以告诉Agent下一步应该做什么,但真要把一个任务从头跑到尾,它还得知道文件在哪里、需要调用哪个工具、出了错怎么恢复、结果最后要写在哪里。
换句话说,模型决定Agent的能力上限,而Harness越来越决定它到底能不能把活做完。
而一旦竞争的维度从“智力”走向“执行力”,最占优势的,未必是那些模型做得最好的AI公司。
因为Agent真正开始干活之后,需要的那些东西——邮件、文档、会议、通讯、账号权限等等——往往掌握在传统平台公司手里。
国内最近打得热闹的“办公Agent大战”,其实就是一个非常典型的例子:大厂在互联网平台时代积累下来的那些东西,以前更多只是各自生态里的部分功能,但到了Agent时代,这些东西恰好就是Agent真正干活时需要调用的工具。
现在大家做办公Agent,表面上是比谁家的AI员工更聪明、更有本事,背后其实也在重新利用自己过去积累的平台优势。谁手里有更多企业数据、文档、工具和权限,谁就更容易让Agent真正把事情做完。
模型公司需要一点点接入它们没有的入口,而那些做了十几年办公软件和互联网平台的公司,本来就掌握着这些入口。
换句话说,AI公司要重新连接现实世界,而平台公司手里原本就有一大串钥匙。
沿着这条路往前看,如果非要找一个最有优势的“全家桶”选手,谷歌恐怕是最夸张的那个。
从TPU、云基础设施、Gemini,到Search、Workspace、Chrome和Android,谷歌几乎覆盖了AI从底层技术到最终用户的所有关键环节。Search、Gmail、Calendar、Drive、YouTube、Maps等产品,又天然构成了一套可以被Agent调用的数字环境。这些资产在上一代互联网里是一个个独立入口,到了Agent时代,却可以被重新组织到同一个任务之下。
事实上,谷歌已经开始把散落在各个产品里的Agent能力,在底层往同一套执行系统里收。Gemini Spark、Gemini API里的Managed Agents,乃至Search里的部分Agent体验,背后正在逐渐共享同一套Antigravity Harness。
但到了用户这一端,事情还是有点乱。
今天谷歌同时有Gemini Spark、Workspace Studio、Antigravity、Gemini Enterprise,以及Search里的Information agents。它们面对的用户和场景各不相同,但对于普通人来说,当他们想把一件复杂的事情整个交给谷歌,还是不知道应该找谁。
对谷歌来说,它已经拥有完成这一切所需的大部分条件,缺的只是一个足够简单的产品答案。
而如果谷歌真把这件事做明白了——无论是做出了一个统一的Agent工作台,还是让同一个Agent执行系统穿透整个谷歌生态,让用户习惯“有问题找谷歌”,全球Agent市场的竞争格局恐怕都要再变一变。
话虽如此,谷歌就算真把这套“全家桶”塞进一个Agent,国内用户大概率也只能先围观一下。
还是先看看国内的Agent大战,接下来还会怎么打吧。
Gemini, MoonPay, Dallas Fed, BIS 这一周在 Agentic Finance 上交汇了作者 Charlie,常驻硅谷参与和观察前沿科技十五年,聚焦AI如何重构金融服务、支付网络、与资本市场。Fintechnize 与【沙丘路的毛圈狮子】创始人,Venture Partner @ Generative Ventures。曾任OSL美洲支付负责人,加密货币独角兽 Strike 副总裁(参与萨尔瓦多比特币法案,并负责拉美比特币闪电网络和稳定币支付业务),万亿级基金 Franklin Templeton 宏观与货币分析师,全球支付巨头Adyen早期成员。文章为个人观点,不是投资建议。
过去一周,金融行业里发生了几件表面上完全不在一个频道里的事情。
8月25日,Google Cloud推出了面向金融机构的Gemini Enterprise for Financial Services,把AI进一步推进KYC、信用分析、投资组合监控、债券发行和金融研究这些真正接近核心业务的工作流。
两天以后,MoonPay宣布把PayBox接入Solana上的Kamino,用户已经可以通过Claude或者ChatGPT这样的交互入口发起借贷和获取收益。
与此同时,Dallas Fed发布了一篇看起来没那么性感的研究,讨论如果存款可以24小时实时转移,而AI又能够自动替企业和个人比较收益,银行一直以来依赖的存款粘性会发生什么。
再往后一天,BIS在讨论稳定币与代币化存款时,又提到了刚刚完成真实资金测试的Project Agorá。
单独看,每一件事都可以被归到一个熟悉的新闻分类里:Google是企业AI,MoonPay是加密金融,Dallas Fed是银行研究,Project Agorá是央行和商业银行研究下一代跨境支付基础设施。
但如果把它们放在一起,能看到一条更值得注意的线索。
过去两三年,我们一直在讨论AI什么时候会真正改变金融。但我越来越觉得,这个问题问得不够准确。真正的分界线从来不是AI什么时候“更懂金融”,而是它什么时候开始被允许代表人去做金融决策,并且真的能够移动资金。
这两者之间的差别,可能比从搜索引擎到ChatGPT还大。
几年前我刚开始研究生成式AI和Fintech结合的时候,整体判断其实相对保守。那时候金融行业最现实的应用仍然是客服、报告、反欺诈、费用管理、内部知识检索和各种提高员工效率的工具。这些当然有价值,但基本都停留在“AI站在钱的旁边帮忙”,并没有真正碰到钱。
原因也很简单。一个模型写错一段市场文案,可以重新修改;一个模型如果替企业把500万美元转错了地方,显然不是点一下“撤销”就能解决。金融机构对黑箱的容忍度天然比普通软件公司低得多。准确性、权限、审计、责任归属、监管要求,任何一个环节没有解决,模型再聪明,也只能做助手。
而最近几个月真正值得注意的变化,并不是行业突然相信“全自动AI理财”马上会到来,而是越来越多公司开始把“让AI动钱”这件事拆成一系列更小、更可控的授权。
Robinhood今年推出Agentic Trading时,并没有让一个模型直接接管用户全部资产,而是专门设置一个允许AI操作的独立账户。到第二季度末,这类账户已经接近10万个,管理资产超过1亿美元。
Ramp走的路线更加不性感,却可能更接近真实企业财务的演化路径。它的AI并不是直接取代CFO,而是先读取公司的报销、付款和会计政策,对高把握度的情况自动处理,把异常情况交还给人。
Rocket Money最近推出的Rowan也体现了类似趋势:它不再只是给用户看一张“你这个月花了多少钱”的图,而是可以在后台发现订阅、发消息提醒、帮助取消服务、谈判账单,甚至按照预设规则完成储蓄转账。
这些产品放在一起看,会发现市场并没有从“人工操作”直接跳到“机器完全自主”,而是沿着一条更现实的路径前进:先观察,再建议,再准备动作,再由人批准,然后逐渐把那些规则清楚、风险可控的动作交给机器执行。
这也是为什么我觉得,Agentic Finance真正重要的概念并不是“自动化”,而是“授权”。
今天企业员工拿着一张公司信用卡,本身就是一种金融授权。他当然不能把公司银行账户里的钱全部花掉,但可以在一定商户类别、金额和审批规则内自主消费。基金经理、企业财务负责人、采购经理,本质上也都是在一个事先定义好的授权框架里替别人管理资金。
AI Agent真正要做的,并不是发明一种全新的金融制度,而是把这种我们早就习以为常的授权关系变成机器可以理解和执行的规则。
比如,一家公司完全可以告诉一个AI财务代理:必须保留至少30天运营现金;剩余资金只能放在指定银行或者高评级产品;不能产生外汇风险;单笔资金移动超过50万美元必须人工批准;只有当收益差超过20个基点时才值得切换;任何新出现的交易对手都必须经过人工审核。
一旦这些规则可以被机器直接理解,事情就发生了本质变化。AI不需要获得无限权力,也不需要成为一个完全不受监管的“机器人对冲基金”。它只需要在边界内自主行动。
这也是最近Google、MoonPay、Visa、Mastercard这些公司做Agent支付时越来越明显的共同方向。表面上大家都在讨论AI如何付款,真正花大量精力解决的却是权限:谁授权,授权多少,授权到什么时候,哪些商户和账户可以碰,什么情况下必须停下来重新找人确认,最后出了问题如何留下完整的审计记录。
所以我现在越来越相信,未来Agentic Finance最重要的产品之一,甚至不一定是某个更聪明的大模型,而是一套足够可靠的“金融授权系统”:它能把一句很模糊的人类指令——比如“帮我把公司闲钱管好”——翻译成几百条可以被机器严格执行的规则。
从这个角度再看MoonPay最近半年的动作,就比单独看它和Kamino合作有意思得多。
3月,MoonPay推出Open Wallet Standard,重点解决AI怎么安全使用钱包、怎么在不接触私钥的情况下获得有限的签名权限;5月,它收购DFlow,把交易执行基础设施补进来;6月又收购Entendre,增加对账、财务、资金管理和报表能力;7月推出PayBox,把卡和钱包直接接进Claude、ChatGPT这样的交互环境;到了8月,再通过Kamino把借贷和收益管理接进来。
单独看,每一步都不算惊天动地。连在一起看,却很像是在拼一套面向AI Agent的金融底层能力:先解决身份和权限,再解决执行,再解决财务运营,最后开始碰信用、借贷和资产配置。
这也是Agentic Payments和Agentic Finance真正的区别。
前者回答的是:AI怎么替我付钱?
后者问的是:AI怎么替我管理资产负债表?
一旦进入第二个问题,支付就只剩下其中一个动作。现金放在哪里、什么时候借钱、抵押什么资产、闲置资金赚多少收益、什么时候做再平衡、如何管理流动性和风险,这些原本需要企业财务团队、银行家或者投资经理不断做出的判断,都开始有可能进入机器的执行范围。
可是这里一直还有一个基础设施上的矛盾。
如果AI可以每秒计算一次最佳方案,钱本身却仍然只能按照银行营业时间、跨境代理行、批量清算和人工对账的速度移动,那么再聪明的Agent也没有太大意义。它像一辆性能极好的跑车,却只能开在一条坑坑洼洼的乡间土路上。
这也是Project Agorá值得放进这篇文章的原因。
Project Agorá本身不是一个AI项目。它是BIS Innovation Hub和国际金融协会联合推动的实验,研究如何把代币化的商业银行存款和央行准备金放进一个多币种、可编程的平台里,以改善批发跨境支付。
它与Agentic Finance之间真正的联系,并不是“BIS也开始做AI”,而是它正在研究AI最终需要调用的另一块金融基础设施:钱本身能不能变得更容易被机器读取、组合和执行。
今年7月,28家金融机构和央行已经在受控环境里完成真实资金测试,涉及瑞郎、欧元、英镑、日元、韩元和美元。测试规模本身非常小,远远谈不上生产环境,但它至少验证了一件事情:商业银行存款和央行货币并不是天然只能活在今天这些缓慢、彼此割裂的系统里,它们同样可以进入一个支持条件触发、原子结算和自动执行规则的环境。
BIS自己对此仍然非常谨慎。系统之间怎么互联,法律上的最终结算怎么认定,智能合约出了问题谁负责,网络安全、治理以及几十年旧系统怎么迁移,这些问题都远远没有解决。所以把Agorá写成“下一代全球金融系统已经建好了”,显然是夸大。
但它至少证明了一个容易被crypto叙事掩盖的问题:可编程货币并不一定等于稳定币,也不一定意味着银行被绕过去。传统银行存款本身,也可能变成可以被软件调用的金融资产。
而真正有意思的地方,也恰恰从这里开始。
因为银行今天正在投入大量资源消灭资金流动里的摩擦,但这些摩擦过去某种程度上本来就是银行商业模式的一部分。
这正是Dallas Fed那篇文章最值得注意的地方。
一家银行的存款为什么值钱?
当然有很多很高大上的原因。企业把5000万美元放在JPMorgan,不只是因为懒得开户,背后可能绑定着信贷额度、外汇、工资支付、现金管理、托管以及多年的客户关系。这些东西不会因为隔壁银行利率高了10个基点就突然消失。
但另一个原因没有那么高大上,却同样真实:搬钱太麻烦。
今天一家公司的账户里有200万美元暂时闲置,A银行给4.20%,B银行给4.35%。为了15个基点,财务团队是不是每天早上都要重新检查一次?是不是值得重新登录、比较交易对手风险、做资金划拨、考虑清算时间,再重新做一轮对账?还要保证明天工资和供应商付款不会受到影响。
绝大多数时候,答案都是算了。
钱就继续放在那里。
这就是金融体系里一个很少被单独拿出来讨论的资产:人的惰性。
Dallas Fed的文章说得很直接,运营存款之所以有粘性,一部分就来自资金无法快速重新配置的现实摩擦。如果未来即时结算、代币化存款和AI Agent同时成熟,寻求更高收益的客户理论上就可以在自己几乎不做任何操作的情况下完成资金切换。
AI不会觉得15个基点“不值得折腾”。
它没有周一早上的会议,不会忘记,也不会因为今天很忙就把这个事情拖到下周。对于它来说,不断比较不同金融产品的边际注意力成本几乎为零。
这当然不意味着未来所有企业存款都会像热钱一样每五分钟换一家银行。客户关系、信用额度、监管要求、风险管理仍然存在,资金切换也永远不会真正达到零成本。
但问题在于,它根本不需要发展到这么极端,才会影响银行。
Dallas Fed以美国银行体系接近17万亿美元的相关存款做了一个敏感度测算。如果存款的平均停留期限缩短10%,银行体系承担期限转换的能力可能减少大约5800亿美元的“十年期等值风险敞口”;如果存款利率对市场利率变化的敏感程度提高10%,银行可承担的久期风险可能减少约7000亿美元。
这并不是说AI会让美国银行突然少放7000亿美元贷款。把这个数字简单解释成“贷款能力减少7000亿美元”并不准确。
它真正说明的是另外一件事情:存款粘性本身就有巨大的经济价值。
如果未来可编程货币和AI Agent只是让这份粘性稍微弱一点,银行负债端的成本和期限结构就可能跟着变化。
过去大家谈可编程货币时,看到的通常都是好处:结算更快、对账更少、成本更低、可以全天运行,也可以把支付条件直接写进交易逻辑里。
但它还有一个很少被强调的另一面:钱一旦更容易移动,持有钱的人就拥有了更多选择权。
对于资产持有者来说,这是效率;对于把这些钱当作稳定资金来源的机构来说,却意味着更激烈的竞争。
银行为了让钱像软件一样运行,也可能必须接受一个结果:钱开始按照软件的速度比较价格。
这就把问题带到了我最近一直在思考的另一个方向。
过去我一直认为,金融本质上是一个分销(distribution)生意。
银行争的是谁拿到工资直接入账,信用卡公司争的是谁成为消费者最常用的那张卡,券商争的是谁占住投资者的手机屏幕,财富管理机构争的是谁拥有客户关系。大量Fintech产品花几十亿美元获客,本质上都在争夺同一个东西:谁能站在用户和金融产品之间。
因为谁拥有分销,谁就有机会决定哪个产品被看见。
但AI Agent可能会让这场竞争逐渐从“分销”(distribution)变成“资金路由”(routing)。
以前你会问:我最喜欢哪家银行?
未来更重要的问题可能是:我的财务Agent把哪些银行放在可接受交易对手名单里?
以前基金公司想办法让自己的货币基金排在App首页。
未来Agent可能直接判断:当收益差超过18个基点、流动性满足要求、交易对手风险低于某个阈值时,资金应该自动去哪里。
以前贷款机构拼广告、品牌和销售渠道。
未来Agent可能直接比较实际利率、抵押要求、提前还款条件以及企业当前的现金流状况,再决定应该调用谁的资金。
到了这里,真正值钱的东西就不再只是“用户有没有下载你的App”,而是你有没有进入机器的默认规则。
谁被写进授权范围,谁就有资格参与竞争;谁最终赢得资金路由,谁就拿到了资金流。
Agentic Commerce改变的是需求流向哪里。
Agentic Finance改变的是资本流向哪里。
所以如果今天我是一个银行CEO,我当然会关心AI能不能减少分析师写报告的时间,能不能把KYC和反欺诈调查自动化,这些都是非常现实的效率提升。
但更长期的问题可能是另外一个:
当我的企业客户拥有一个24小时工作的财务Agent以后,我凭什么继续拥有他的下一美元?
最聪明的银行未必会抵抗这场变化,反而可能最早把Agent放进自己的体系里。客户日常运营资金继续留在活期账户,暂时不用的钱自动进入收益更高的存款或者基金,需要流动性时再自动回来;外汇、贷款额度、抵押品和付款也都可以被一起优化。这样即使Agent不断寻找更优解,资金仍然可以留在同一家银行生态内部。
从这个角度来看,Project Agorá这样的探索未必会削弱银行,甚至可能帮助受监管的商业银行货币在稳定币时代继续保持核心地位。
所以这并不是一个“AI加Crypto最终干掉银行”的简单故事。真正危险的,未必是银行本身,而是那些长期以来把客户不愿意比较、不愿意切换、嫌麻烦,当成自己护城河的金融商业模式。
过去一家银行很重要的优势,是客户搬走太麻烦。下一阶段真正强的银行,可能必须证明一个完全相反的命题:客户随时都可以走,但他的AI算完以后,依然决定把钱留在这里。
过去十几年,Fintech最激烈的战争发生在手机屏幕上。大家争日活、争主账户、争最常用的那张卡,争谁离用户更近。
下一轮很多真正重要的金融战争,可能根本没有界面。
它发生在后台的一套授权规则里,发生在一张可接受交易对手名单里,发生在十几个基点的收益差里,也发生在AI判断“这笔钱此刻应该去哪里”的那一瞬间。
所以Agentic Finance真正值得问的问题,可能从来都不是:AI什么时候会替我们管理钱?而是,当越来越多的钱开始按照机器可以理解的规则,自动寻找自己的最佳去处以后——
谁还有资格决定,这些钱最终留在哪里?文章转载于字母AI OpenAI昨天一口气打出了四张大牌。 Agents API、GPT-Live-1 API、Data agent、ChatGPT for Financial Services,一天横跨Agent、语音、数据和金融四条产品线,每一条都值得单独拿出来说道。 但这四张牌里,最值得看的可能还是Agents API。 因为这一次,OpenAI把Codex“拆开卖了”。 原本藏在Codex背后、负责让Agent持续工作、调用工具、管理上下文和协同多个Agent的那套能力,被抽出来打包成了云端API,交给所有开发者调用。 1 Codex即服务? 其实,OpenAI早就在拆Codex了。 早在2025年4月,OpenAI刚发布o3和o4-mini那会儿,就把Codex CLI开源了。它有点像OpenAI版的Claude Code,直接就装在本地终端里。Agent怎么跑,怎么调用工具,都明明白白地放在GitHub上,你愿意折腾,就可以自己拿回去改,自己跑。 不过那个时候只是单纯地把东西给了出来,至于你会不会用、想怎么用,那都还是你自己的事。 一个月后,Codex云端版,也就是我们今天所熟悉的那个产品,才正式上线。用户可以把代码仓库交给它,一个任务对应一个独立的云端沙盒,Codex可以自己改代码、跑测试、修bug,还能同时处理多个任务。 又过了几个月,在2025年的10月份,OpenAI发布了Codex SDK。 简单来说,SDK就是给开发者的一套工具包,让Codex不只作为独立产品使用,也可以塞进别人的应用里。SDK允许开发者用几行TypeScript代码启动同一个驱动Codex CLI的Agent,拿到结构化输出,还能保留任务状态,在暂停之后继续跑。 但是呢,SDK主要适合在程序里调用Codex,还没有把完整的Codex交互能力开放出来。它很适合后台的工作流、自动化脚本、服务端的程序。但如果你想做一个像Codex IDE那样的完整客户端,还是有些困难。 于是到了2026年2月,OpenAI正式公开Codex App Server,第一次系统地把Codex里面那套Harness讲清楚了。 OpenAI明确解释,Codex Web、CLI、IDE扩展和Mac App看起来是不同的产品,但底下其实都在运行同一套Codex Harness,也就是负责Agent Loop、Thread、工具执行、认证和管理状态的那层东西。 App Server给这一整套Harness加了一套双向JSON-RPC接口。JetBrains、Xcode或者其他客户端,不需要重新造一个Agent Loop,直接启动App Server,就可以驱动完整的Codex。 有了App Server,其他产品就可以直接接上完整的Codex Harness。 不过走到这里,还有最后一个麻烦没解决。 SDK控制的是本地Codex Agent,App Server本身也是一个需要开发者启动和维持的常驻进程。虽然把Codex接进产品这事已经解决了,但想把它稳定地跑成一个线上的服务,还是有点困难。 举一个比较具体的例子,如果你用App Server做一个自己的Coding Agent网站,前端已经接上了Codex,但当用户点下“修复这个仓库”之后,后续的大量运行和基础设施问题,都还需要你自己想办法解决。 然后就到了8月19日,这一天,OpenAI把过去一年陆续开放的CLI、SDK、App Server统一放进了“开放Codex Harness”的平台叙事里,并明确把Codex从一个产品提升成了平台。 再然后就是(美国时间)9月10日,也就是昨天,Agents API正式开放公测。 这一次,开发者只需要告诉API四件事——任务、模型、工具、运行环境——就可以直接创建一个Agent。负责长会话上下文压缩、工具调度和subagent协作的Codex Harness由OpenAI自己托管和维护。 甚至就连Agent真正干活的机器都能自己选,是用OpenAI的沙盒、自己的基础设施,还是Cloudflare、E2B、Modal等第三方环境,都可以。Harness由OpenAI提供,执行环境由开发者决定。 官方的口径很明确,Agents API本身不额外收费。也就是说,Harness托管、长会话管理等能力,并没有再单独收一层Agent平台费。 开发者按实际使用的模型Token和工具付费;如果使用OpenAI自己的托管沙盒,计算资源另算。 把这一年多串起来,OpenAI一直在做同一件事:把Codex从一个具体产品,一层一层拆成可以被复用的能力,同时让开发者越来越不需要自己操心。 如果一定要给这条产品线起个名字,它其实很像当年的SaaS,只不过这次被服务化的不是软件,而是Codex。 Codex as a Service。 1 Harness也开始分叉了 盯上Harness的当然不止OpenAI。 DeepSeek Harness(后文简称DSH)发布的时候,就给出了一个非常响亮的等式:Agent = Model + Harness。 在DeepSeek看来,模型只是Agent的一半,另一半则是负责让它理解环境、调用工具、管理状态、持续执行任务的Harness。两者互相协调,Agent才能真正执行任务。 DSH把Harness本身做成了一套高度模块化的开放框架:模型、工具、Skills、Session、沙盒、存储、Agent Loop、调度,甚至UI都可以替换。 “一切皆插件”的口号可不是说着玩玩而已,最好大家都来写插件,都来适配DSH,最后不管上面跑的是DeepSeek,还是别的模型,底下都可以是同一套Harness。 这和OpenAI现在走的方向刚好形成了一个挺有意思的对照。 OpenAI虽然也把Codex harness开源了,但Agents API明显是在往另一个方向走:Harness你可以用自己的,也可以拿走开源的,但如果你嫌麻烦,还可以直接不管,让我来替你安排。 所以我们认为,它更像是一种“服务”。OpenAI负责托管和持续维护Harness,开发者只需要决定要让Agent干什么、用什么工具、在哪里执行。甚至以后模型升级了,Harness怎么跟着改,OpenAI也准备一起包了。 某种意义上,现在Harness这一层隐约出现了两条路线: 以DeepSeek为代表的路线更像是在建设开放生态,把每一个零件都做成插件,让开发者自己组装;而以OpenAI为代表的一方则像在押注云服务,把钱和需求给到位,剩下的我帮你解决。 我们甚至可以认为,一个想让Harness越来越像Linux,另一个则想让Harness越来越像AWS。 当然了,这只是个比喻。OpenAI也开源了Codex Harness,DeepSeek未来也并非没有可能提供更多的托管服务。但至少在现阶段,两边产品的重心差别明显。 有意思的是,在把Harness变成服务的这条线上,Anthropic其实比OpenAI更早一步。 早在2025年9月,Anthropic就推出了Claude Agent SDK,把Claude Code背后的工具、上下文管理、权限系统和subagent能力开放给开发者,让别人也能拿这套东西做Agent。 今年4月,它甚至比OpenAI更早推出了Claude Managed Agents。Session、Harness和沙盒被拆成三个独立层:Anthropic负责托管harness和长任务,沙盒既可以由Anthropic提供,也可以接入别的执行环境。这个思路和今天的Agents API其实已经相当接近,Anthropic自己给它的定义就是“一个用于长期Agent任务的托管服务”。 所以某种意义上,OpenAI这次是在沿着Anthropic已经走过的路继续往前走,区别只不过是OpenAI手里有一个更“产品化”的Codex。 但因为Codex和Claude Code长期给人的产品印象还是不太一样,所以即使它们讲的是同一套故事,带来的感觉也大相径庭。Claude Code给人的感觉更像是让开发者坐在终端里和Agent一起写代码,而Codex App一开始强调的就是“同时监督多个长期Agent”的界面。 顺带一提,谷歌也早已加入这条路线。今年5月的I/O大会上,Gemini API推出Managed Agents,同样把Antigravity Harness和沙箱做成了托管服务。但谷歌的牌面不止于此,这一点咱们后面再讨论。 不过话说回来,谁先谁后好像也不是那么重要……最后当然是谁把自家的Harness变成开发者默认的那一层,谁才能吃下最大的蛋糕。 1 谁是大赢家? 说到底,为什么现在模型公司都开始抢Harness了? 就像是DSH给出的等式那样,Agent = Model + Harness,模型可以告诉Agent下一步应该做什么,但真要把一个任务从头跑到尾,它还得知道文件在哪里、需要调用哪个工具、出了错怎么恢复、结果最后要写在哪里。 换句话说,模型决定Agent的能力上限,而Harness越来越决定它到底能不能把活做完。 而一旦竞争的维度从“智力”走向“执行力”,最占优势的,未必是那些模型做得最好的AI公司。 因为Agent真正开始干活之后,需要的那些东西——邮件、文档、会议、通讯、账号权限等等——往往掌握在传统平台公司手里。 国内最近打得热闹的“办公Agent大战”,其实就是一个非常典型的例子:大厂在互联网平台时代积累下来的那些东西,以前更多只是各自生态里的部分功能,但到了Agent时代,这些东西恰好就是Agent真正干活时需要调用的工具。 现在大家做办公Agent,表面上是比谁家的AI员工更聪明、更有本事,背后其实也在重新利用自己过去积累的平台优势。谁手里有更多企业数据、文档、工具和权限,谁就更容易让Agent真正把事情做完。 模型公司需要一点点接入它们没有的入口,而那些做了十几年办公软件和互联网平台的公司,本来就掌握着这些入口。 换句话说,AI公司要重新连接现实世界,而平台公司手里原本就有一大串钥匙。 沿着这条路往前看,如果非要找一个最有优势的“全家桶”选手,谷歌恐怕是最夸张的那个。 从TPU、云基础设施、Gemini,到Search、Workspace、Chrome和Android,谷歌几乎覆盖了AI从底层技术到最终用户的所有关键环节。Search、Gmail、Calendar、Drive、YouTube、Maps等产品,又天然构成了一套可以被Agent调用的数字环境。这些资产在上一代互联网里是一个个独立入口,到了Agent时代,却可以被重新组织到同一个任务之下。 事实上,谷歌已经开始把散落在各个产品里的Agent能力,在底层往同一套执行系统里收。Gemini Spark、Gemini API里的Managed Agents,乃至Search里的部分Agent体验,背后正在逐渐共享同一套Antigravity Harness。 但到了用户这一端,事情还是有点乱。 今天谷歌同时有Gemini Spark、Workspace Studio、Antigravity、Gemini Enterprise,以及Search里的Information agents。它们面对的用户和场景各不相同,但对于普通人来说,当他们想把一件复杂的事情整个交给谷歌,还是不知道应该找谁。 对谷歌来说,它已经拥有完成这一切所需的大部分条件,缺的只是一个足够简单的产品答案。 而如果谷歌真把这件事做明白了——无论是做出了一个统一的Agent工作台,还是让同一个Agent执行系统穿透整个谷歌生态,让用户习惯“有问题找谷歌”,全球Agent市场的竞争格局恐怕都要再变一变。 话虽如此,谷歌就算真把这套“全家桶”塞进一个Agent,国内用户大概率也只能先围观一下。 还是先看看国内的Agent大战,接下来还会怎么打吧。
