阶跃Step 3.7 Flash:Codex Agent的国产大模型最佳搭档
最近 Codex 的热度确实很高。
它最吸引人的地方,不只是帮你生成几行代码。现在的 Codex 已经蜕变为一个全能的 Agent:能够阅读项目、理解上下文、修改文件、执行命令,再根据执行结果继续调整。OpenAI 官方文档也明确提到,Codex CLI 默认以 Agent 模式运行,具备读取文件、运行命令、修改项目目录内代码的能力。
但国内开发者在实际使用中,往往会遇到不少现实问题。
访问稳定性和账户配额都不好保证,Plus/Pro 订阅的成本也需要精打细算。公司的网络策略、团队合规要求、API 预算管控,都会让直接使用 Codex 变得不那么顺畅。
这让我开始思考,是否可以保留 Codex 这套优秀的代码 Agent 交互框架,但把背后的模型替换成自己能够稳定调用的大模型 API。
这个思路其实并不绕。Codex CLI 本身支持通过 API key 登录,并且允许在配置文件里设置 model_provider、base_url、env_key 等自定义模型服务参数。只要模型接口兼容、配置正确,完全可以把其他大模型 API 接入 Codex 的工作流,让它继续执行读代码、改代码、跑任务这一整套 Agent 操作。
接下来唯一需要回答的问题就是:如果要给 Codex 接入一个国内模型,到底应该选择哪一个?
恰好这个时候,阶跃发布了最新的开源 Flash 版本 —— Step 3.7 Flash。
这个模型的定位本来就不是一个单纯的对话聊天模型,而是更专注于服务 Agent 创造者的 Flash 模型。
它在长上下文、搜索、Coding、多模态、工具调用等能力上做了重点强化,目标场景也非常明确:帮助开发者以更高的性价比搭建自己的 Agent。

这不正好就是为国内开发者丝滑使用 Codex 而设计的吗?
Codex 负责提供代码 Agent 的操作框架:阅读项目、修改文件、执行命令、连续推进任务。
Step 3.7 Flash 负责提供模型能力:理解需求、处理上下文、生成代码、根据反馈修正结果。
一个提供手脚,一个充当大脑,配合起来刚好。
所以这篇文章就只做一件事:实际测试,看能不能把 Step 3.7 Flash 顺利接进 Codex,让它成为更适合国内开发者的 Coding Agent 底座。
如何将阶跃 Step 3.7 Flash 接入 Codex Agent 工作流
前面已经提到,要让 Codex 调用第三方大模型,只需要修改 config.toml。
找到 Codex 的 config.toml 文件,将开头部分改成下面的配置即可。
model_provider = "custom"
model = "step-3.7-flash"
model_reasoning_effort = "medium"
model_reasoning_summary = "none"
model_supports_reasoning_summaries = false
disable_response_storage = true
[model_providers.custom]
name = "StepFun"
base_url = "https://api.stepfun.com/v1"
env_key = "STEP_API_KEY"
wire_api = "responses"
别忘了在本地环境变量中,把 STEP_API_KEY 设置为阶跃星辰 Step 3.7 Flash 的 API Key。
完成之后打开 Codex 工具,不论是 Codex APP,还是像我这样使用 VS Code 中的 Codex 插件,只要看到下面的提示,就说明配置成功了。

如果你使用了 cc-switch,配置也很简单:先把 cc-switch 更新到新版本,然后新增一个 Codex 接入点,正常填写 API 地址和 Key 信息即可。

接下来就可以开始实战测试了。
实战任务一:用一张图片构建武侠小说阅读网站
第一个任务我没有选择复杂的业务系统,而是给 Step 3.7 Flash 安排了一个更直观的题目 —— 创建一个中国武侠小说主题的阅读网站。
而且,是仅凭一张图片就开始整个网站的搭建。
它需要先看懂一张带有武侠风格参考的图片,从中提炼出水墨、竹影、宣纸、剑客剪影这些视觉元素;然后通过视觉搜索补充素材方向;接着把这些设计元素转化成网页结构;最后还要调用工具生成代码,并根据页面截图继续迭代修改。
使用的参考图片如下:

给它的提示词大致是这样的:
我想做一个中国武侠 / 侠义小说阅读网站,网站名叫「江湖夜读」。
主要收集整理金庸古龙的武侠小说,要找到所有的小说,要在这个网站上可以直接阅读。
再整理出各个小说中的人物,武器,武功,情节等等,存档之后制作成小说的档案,方便用户查看。请做好规划,要保证数据的完整性和准确性,不要偷懒。
网站风格参考当前目录下的图片。
这个任务看起来“只是做个网页”,但实际上里面嵌入了好几层能力要求:
- 理解图片内容
- 拆解复杂需求
- 规划网站整体结构
- 生成前端代码
- 处理内容信息架构
- 自主推进任务流程
我并没有告诉它要拆分成几个子 Agent,也没有一步一步指导具体怎么做。只给了一个最终目标:做一个真实可阅读的武侠小说网站。
它需要自己完成资料检索、来源判断、视觉理解、页面设计、代码生成以及最终的自检。
这更贴近 Step 3.7 Flash 作为“面向 Agent 创造者”的真实使用方式:用户只给出目标,由模型自己去组织整个过程。

最终的效果在我看来是合格的。页面结构、信息分区、小说阅读功能、人物档案等模块都搭建了起来,整体完成度不错。

唯一的小遗憾是网站 UI 和我给的参考图之间还有一些距离,水墨的韵味、留白的气质、江湖的意境都可以继续打磨,首页的排版也还有优化空间。
不过这些都属于视觉细节,完全可以在后续用 Codex 持续迭代。对我来说,这次测试最重要的结论就是:Step 3.7 Flash 能够接住一个开放式的任务,并且在 Codex 的工具链里把它推进到可运行的结果。
这一点非常关键。
很多模型在聊天窗口里表现得很聪明,一旦进入真实项目就开始散架。能在 Agent 工作流里稳定跑起来,才算真正可用的模型。
实战任务二:打造跨设备互传小工具
不知道大家平时有没有在手机和电脑之间互传资料的习惯,我倒是经常需要这样做。以前依赖微信,但很多时候电脑端微信并没有打开,用起来还是有些不方便。
也尝试过网上的一些方案,总觉得不太称心。于是就想干脆自己动手做一个,毕竟自己做的工具,可控性和安全性都能得到保证。
说干就干,我使用 Codex 的 goal 模式,把下面这段提示词交给它,然后就开始等待结果。
做出一个可运行的轻量素材中转站 MVP,支持 Android 和 iOS 客户端上传文字、链接、图片和文件,电脑 Web 端可以查看、复制和下载。完成标准是:本地开发环境可以启动,移动端和 Web 端都能登录同一个私人空间,至少完成一次文字上传、图片上传、文件上传、Web 端查看和下载的完整闭环。后端使用 Cloudflare Workers、R2 和 D1,前端使用 Expo React Native。不要引入复杂账号系统,第一版只使用私人访问码。每完成一个阶段后运行可用的测试或启动命令,并记录修改内容、验证结果和下一步。如果遇到平台权限、依赖冲突或 Cloudflare 配置缺失,先尝试最小修复,仍无法继续时停止并列出需要我补充的配置。
这个任务就更接近真实开发了,它需要同时处理:
- 移动端 App
- Web 管理端
- 后端接口
- Cloudflare Workers
- R2 文件存储
- D1 数据库
- 私人访问码登录
- 上传、查看、复制、下载的全流程闭环
这早已不是“写个 Demo”那么简单了。

结果让我有点惊喜。Step 3.7 Flash 在 Codex 里的运行速度很快,整体完成度也很高。
它把项目结构完整地搭了出来,移动端、Web 端、后端都完成了基础实现,还把本地启动方式、需要补充的 Cloudflare 配置、后续部署步骤都整整齐齐地整理了出来。
整个任务在本地耗时大约 16 分钟。

来看一下当前的效果。这是 Web 端界面:

这是 App 端的界面:

虽然目前的功能还比较基础,但已经可以完全解决我日常互传资料的困扰了,操作体验变得非常丝滑。
这个项目我也开源了,大家可以在 GitHub 上搜索 zhouwei713/huchuan 获取。

同时我也发布了一个 Android APP 版本,如果暂时不方便自己部署整套系统,也可以直接使用我搭建好的服务。
Step 3.7 Flash 在接入 Codex 之后,不仅仅能写代码,更能完成一个小产品的第一版闭环。
这和普通的对话式辅助编码差别很大:聊天模型给的是片段,而 Agent 工作流交付的是完整过程。在真实开发里,最耗人的往往就是过程,Step 3.7 Flash 与 Codex 的组合,恰好能很好地完成这项工作。
总结:寻找真正能跑进工作流的国产大模型
这次把 Step 3.7 Flash 接入 Codex,我最大的感受是:国产大模型真正体现价值的地方,并不只是在聊天窗口里的回答有多漂亮,而应该是能进入真实工作流,稳稳接住上下文、工具和反馈。
Codex 这类工具已经把代码 Agent 的操作框架搭建好了,接下来真正关键的,就是谁能成为这个框架里稳定、好用、性价比高的大脑。
Step 3.7 Flash 这次想证明的,正是这一点。它可以成为 Agent 创造者手中那个高频、实用、可随时接入的基础模型。
如果你正在开发 Agent,或者想把某个重复工作变成自动化流程,我的建议是别只看模型的评测榜单。直接拿一个真实任务去试。
让它读项目。 让它改代码。 让它跑命令。 让它失败一次,然后自己再修。
因为模型到底能不能用,最终不看发布会,也不看参数表。能真正跑进你的工作流里,持续推动任务前进,才是真本事。
最好的模型,一定是那个能陪你把事情做完的模型。

