我用step-3.7-flash从零造网站、真上网查资料，顺手和 DeepSeek V4 Flash 做了个对照

step-3.7-flash发布的时候，官方给它的定位是“面向生产级 Agent 的高效率 Flash 模型”。我第一反应其实挺警惕的。这两年谁家发模型不说自己面向 Agent？这个词已经快被用烂了。

但它讲的角度又确实有点意思。它不是单纯说“我更聪明”或者“我更便宜”，而是在讲一件更工程的问题：一个模型能不能在真实的多轮任务里，又快、又稳、又省地把一件事从头干完。

这个角度我喜欢。因为 Agent 不是一次问答。它得规划、写代码、调工具、读报错、修 bug、查资料、核对事实，最后还要真的交付一个能用的东西。

所以我没去跑那种单点 benchmark，而是干了点糙活：给它一个真实工程任务，让它自己从零干到底。然后再拉一个同级别的对手过来，同样的任务、同样的提示词、同样的评分器，看谁更利索。

对手我选了 DeepSeek 2026 年 4 月底发的deepseek-v4-flash。理由很简单：两者都是 Flash 机型，都主打高性价比，也都适合拿来做 Agent 场景的执行模型。

下面是这两天跑下来的结果。

01

让它俩从零造个能用的网站

我给的任务是造一个短链接服务：你丢进去一个长 URL，它返回一个短链接，别人点进去会 302 跳转，还能统计点击量。

听起来挺简单，对吧？真做起来细节不少。

后端要用http.server和 SQLite 写 REST 接口，要处理 302 跳转语义，要保证点击计数正确，还要拒绝非法 URL。前端要有一个能粘贴、生成短链、查看统计的页面。最后还得有一套真的把服务器跑起来、挨个接口测试一遍的端到端测试。

加起来要写十来个文件。这已经不是“帮我补全一个函数”的活了，而是一个小型全栈工程任务：要会拆结构，要会协调多文件，要会启动服务，要会读测试失败。

结果呢？两个模型都干成了。评分器独立复核，都是10/10。

但过程差别很明显：

step 这边明显更“想得清楚”：21 回合、只返工 1 次就把事情办完了。DeepSeek 用了 31 回合、返工 5 次，token 烧了差不多 3 倍。

这里有个反直觉的地方。

DeepSeek 的 token 单价其实比 step 便宜，尤其输出价便宜很多。但在这个 Agent 任务里，它为了完成同一件事多烧了 3 倍 token，最后总账反而贵了将近八成：$0.107 vs $0.060。

这就是我开始重新理解“Agent 效率”的地方。我们平时挑模型，容易盯着“每百万 token 多少钱”。但在 Agent 场景里，你真正付的钱是：

单价 × 完成任务实际消耗的 token。

一个绕路少、判断准、返工少的模型，哪怕标价更贵，总成本也可能更低。Agent 效率不是某一步快不快，而是整条链路下来少走了多少弯路。

插一句：step也翻过车

其实就这个短链接任务，它第一次跑是失败的，只过了 4/10。

我没删那次记录，因为它失败得特别有代表性。

当时它架构、路由、数据库都写得像模像样，但所有带 body 的 POST 请求都会返回“JSON 格式错误”。我扒开代码看，问题出在这一行：

`length = int(rfile.headers.get("Content-Length", 0))`

rfile是个字节流，根本没有headers这个属性。请求头在self.headers上。

所以每个 POST 请求一进来就抛AttributeError。但更坑的是，它给这段逻辑套了一个特别宽的except Exception，把真实错误吞掉了，外面统一报成“JSON 格式错误”。

于是模型自己看到的永远是：输入格式不对。

接下来它一连纠错二十多轮，全在朝错误方向使劲，最后也没定位到那行 bug。

这事儿很像人类工程师深夜 debug：问题明明在 A，报错却指向 B，然后你对着 B 较劲到天亮。

我手动只改了这一行，重新评分，4/10 直接跳到 9/10。这说明它不是不会做这个系统，而是栽在一个单点低级 bug 上。

更有意思的是：同一个任务、同一套提示词，我第二天重跑一次，它自己避开了这个坑，干干净净 10/10。

这两件事放在一起，才是我觉得大模型 Agent 现在最真实的样子：

它会写出和人一样的低级错误，也会被一个过宽的except坑死；

单次运行有方差，同一道题它能 4 分，也能满分；

所以你看到任何“某模型一把跑通了某任务”的演示，都应该多问一句：跑了几次？是不是手气好？

02

逼它真去上网查东西

上一个测试虽然复杂，但有个问题，那就是模型在沙箱里写代码，实际上是跟外部世界隔绝的。

可“生产级 Agent”还有很重要的一面：它得能真的伸手去够外部世界。比如查最新文档、调真实 API、搜索实时信息，并且知道什么时候该查、什么时候该停、什么时候不能编。

于是我又出了道更狠的题：做一份开源项目发版速报。

具体任务是查 uv、Ruff、Bun、Vite、Zig 这五个更新很快的开源项目，找出它们此时此刻最新的稳定版本号、发布日期和一句话新特性，写成一份带真实来源链接的简报。

这道题光靠记忆绝对做不出来。这几个项目几天就发一个版本，“当前最新版本”是严格的实时事实。

模型要是凭训练数据写，版本号大概率会过时。

评分标准是这样的，它不光检查模型有没有真的搜索、引用的链接能不能打开，还会自己重新联网搜一遍，把当下真实版本号和模型写的结果对账。

顺便说个工具链上的小插曲：step 自己也支持联网搜索，但我手头这个 key 当时没有触发有效联网，原因可能是权限或配置。为了不把工具链问题混进模型能力，我这轮统一接了 Serper，让两个模型都走同一个真实搜索工具。

我先单独让 step 跑了一次比较“较真”的深搜版。那次它搜了 39 次，磨了 18 轮才动笔，评分器独立复核9/9，包括最硬的实时版本核对。

那次 step 查到的结果是：

这五个版本号，在 2026-06-01 当天评分器重新搜索核对后，全部对上。

过程里有个细节我挺喜欢。trace 里有一句过程记录，大意是：

如果某个事实没有依据，就再搜一遍，而不是猜。

这种“宁可多查一次，也不张嘴编”的克制，才是我理解里的生产级 Agent。真实业务里，Agent 最怕的不是慢一点，而是看起来很自信地胡说八道。

当然，这里面也能看到它的毛病：这次就是搜得有点上头，前后搜了快 40 次才动笔，对细节较真到有点过。这也是研究型 Agent 的典型问题：可靠性和收敛速度之间要找平衡。

为了做横向对比，我又用同一个研究任务、同一套工具和同一个评分器，拉 DeepSeek 跑了一组对照。

那成本和速度这一局谁赢？这次有些变化：

这次两边 token 消耗只差一成多，DeepSeek 的低单价优势就体现出来了：总成本反而比 step 便宜 23%，首字也更快。

所以到底谁更划算？我跑完这两道题，答案变成了四个字：

看任务。

短链接全栈任务里，step 少烧了三分之二 token，所以哪怕单价更高，总账也便宜四成多。联网研究任务里，两边 token 接近，DeepSeek 的低单价就赢了。

这恰好说明一件事：Agent 场景里的性价比，不是看价格表上谁便宜，而是看完成同一件事的总成本结构。

03

那 step 到底快不快？我专门较了个真

前面两局有个现象很稳定：step 的生成速度，也就是每秒吐多少 token，一直更高；DeepSeek 的首字反应，也就是你问完到它开始输出，一直更快。

但 Agent loop 里的速度数据是“脏”的。里面夹着长上下文、工具调用、网络等待和各种中间步骤，不能直接拿来判断纯生成速度。

所以我单独写了一个干净的小基准：同样 5 个 prompt，都要求输出约 260 token，纯流式，每个模型各跑 15 次，取中位数。

还有一个公平性问题：DeepSeek 默认开 thinking，会多生成推理 token。为了不被这个影响，我测了两种 DeepSeek：默认 thinking，以及手动关 thinking。

结果是：

两个结论都得说：

第一，论纯生成速度，step 快了一倍多。我本来担心是不是 DeepSeek 开 thinking 才显得慢，结果关掉 thinking 后，它反而更慢了。也就是说，这里 step 的优势不是靠对方“开思考”衬托出来的，而是真实解码吞吐更高。

第二，论首字反应，DeepSeek 快了一倍多。

换个说法就是：step 更像“起步稍慢，但跑起来很快”；DeepSeek 更像“反应很快，但后面匀速慢一些”。

如果你的任务是几句话的快问快答，首字延迟会很影响体感；如果你的任务是长输出、多文件、多轮工具调用，step 的高吞吐和少绕路就会更有价值。

04

两天跑下来，我对“生产级 Agent”这词的看法

把这一圈跑完，我对step-3.7-flash的判断是：

它确实更像一个“能干活的 Agent 模型”，而不只是一个会答题的聊天模型。

它能拆解多文件工程任务，能自己把服务器跑起来挨个接口验证，能接真实搜索工具查实时信息，能在事实没依据时继续检索而不是乱编。在全栈任务里，它用更少回合、更少纠错、更少 token 完成了同样目标；在专项基准里，它的纯生成速度也明显更快。

但也有一些需要改进的点：

它会写低级 bug，也会被一个过宽的except坑到二十多轮爬不出来；

单次运行有方差，同一道题它能 4/10，也能 10/10；

DeepSeek 在首字延迟、token 接近任务的成本上，也有自己的赢面。

所以如果你问我step-3.7-flash值不值得上，我的答案会比较具体：

如果你的活是多轮、多文件、长输出、工具调用密集的 Agent 任务，它“少绕路 + 生成快”的特点，会实打实帮你省时间、省 token，甚至在单价更高时省总成本。

如果你的场景主要是短平快对话，或者每次任务 token 消耗本来就不大，那首字延迟和单价可能会更重要。

按自己的活挑模型，没有什么工具是“全场景最强”的。

如果你也想试step-3.7-flash，我建议别先拿它闲聊，直接丢一个真实 Agent 任务进去，看它的 trace：有没有规划、有没有少绕路、工具调用稳不稳、最后结果能不能被独立检查。

API 接入：https://platform.stepfun.com

在线体验：https://studio.stepfun.com

模型文档：https://static.stepfun.com/blog/step-3.7-flash/