一、终端 agent 又多一家"官方系"：这次轮到阶跃星辰
2026 年的终端编程 agent 赛道，竞争已经从"有没有"进入"路线之争"。Claude Code 与 Codex CLI 打响了第一枪，MiniMax 用开源的 minimax-code 展示了 BYOK 多提供商的打法，随后一个趋势越来越清晰：与其等社区给自己的模型做壳，模型厂商不如亲自下场。阶跃星辰（StepFun）就是这个逻辑的最新实践者。2026 年 9 月下旬，它的开源终端编程智能体 Step-Code 进入公众视野，仓库为 stepfun-ai/Step-Code。GitHub API 在 2026 年 9 月 27 日的快照显示：438 星、41 fork、TypeScript 编写、MIT 协议，仓库创建于 2026 年 6 月 1 日，最近一次 push 在 9 月 26 日，也就是说截至快照前一天，这个项目仍在活跃迭代。
先说清本文的分工，避免与站内已有内容重复。我们此前发过 终端编程 agent 横评，把 MiniMax Code CLI、Claude Code、Codex CLI 等放在同一张表里按七个维度打分，也单独深拆过 MiniMax Code CLI。本文不重复那份横评，而是聚焦 Step-Code 的两个样本价值：其一，它是新入场者；其二，它走的是"官方模型加官方壳"的绑定路线，与 BYOK 路线正好站在光谱两端。看懂这条路线的工程取舍与适用场景，比多记住一个工具名更有价值。
二、仓库事实：先看冷数据，再看宣传
先摆事实。截至 2026 年 9 月 27 日 GitHub API 快照，stepfun-ai/Step-Code 的关键数据如下：星标 438，fork 41，主要语言 TypeScript，许可证字段为 MIT，仓库创建于 2026 年 6 月 1 日，最近一次 push 在 2026 年 9 月 26 日，另有 44 个开放 issue。许可协议方面提醒一句：GitHub API 的 license 字段以 API 实测为口径写 MIT，最终口径仍以仓库内的 LICENSE 文件为准，这是核查开源项目的基本功。
再看官方定位。README 开头一句值得原文摘出："Swift execution, long-horizon reliability, and high token efficiency"，快速执行、长程可靠、高 token 效率。这三个词不是随便写的，后文的功能设计基本都围绕它们展开。而它的任务定义也非常朴素：Step Code 运行在终端里，覆盖完整任务环，读代码、改代码、跑测试。与许多喜欢讲故事的发布不同，这份 README 反而克制，通篇讲的是安装、登录、快捷键和迁移，几乎不谈愿景。这种克制本身就是一个信息：厂商把 Step-Code 当作工程工具而非概念产品来推。
还有一个容易被忽略的细节：仓库同时提供了简体中文版 README，中文开发者阅读门槛几乎为零。对一个国内厂商来说这是本职，但对比不少先把英文文档糊上去的开源项目，完成度上还是能看出态度差别。
三、两条路线：官方模型加官方壳，对阵 BYOK
Step-Code 最值得深挖的，不是某个单项功能，而是它的整体架构选择。按 README 的说法，默认入口只暴露一个内置模型提供商：Step（StepFun）。登录之后，它会自动发现当前 Step 端点可用的模型，你在 /model 里切换的，也只是 Step 返回的模型列表。换句话说，壳是官方的，模型也是官方的，两者是配套调优的关系。
这套绑定具体落到账户体系上，是四种 Profile，区别只在服务区域与计费方式：Step Plan 国内版与海外版都用浏览器 OAuth 登录，凭据自动刷新，用量包含在 Mini、Plus、Pro、Max 套餐里；Step Platform 国内版与海外版则用接口密钥，按请求付费。TUI 里 /login 打开登录流程，命令行可以用 step login；API key 方式则通过 STEP_API_KEY 环境变量传入，无头运行也可以直接加 --api-key 参数。凭据落在 ~/.stepcode/auth.json，权限 0600，/logout 清除。日常使用中，/status 查看当前会话与模型状态，step login status（或加 --json 参数）则用来检查 Step 凭据及其有效性，排查登录问题时相当顺手。
把它放回赛道里看，这条路线与 MiniMax Code CLI 的 BYOK 路线形成了鲜明对照。BYOK 的核心主张是"不锁定"：你的工作流不必绑死在某一家模型上，今天接 OpenAI，明天换 Anthropic，agent 本身不变。而"官方模型加官方壳"的主张正好相反：既然模型和壳是同一家人做的，token 效率、工具调用格式、长任务调度就可以深度协同调优，换取的是体验上限，付出的是自由度。
两条路线没有绝对优劣，只有场景匹配。如果你所在团队对供应商锁定高度敏感，或者需要在不同模型之间灵活切换，BYOK 路线更稳妥；如果你本来就在用 Step 系模型，或者看重官方宣称的协同调优收益，Step-Code 这种一体化路线反而省心。这也是我们 AI 编程 agent 横评 里反复强调的判断框架：先想清楚你要的是自由度还是优化深度，再看产品。
四、能力深拆：/goal 长任务、StepPage 一键发布、生态兼容
按 README 的功能清单逐项拆。
先看 token 效率与长任务。官方宣称 Step-Code 与 Step 模型协同调优，同一个任务消耗更少的 token。机制层面，长程任务会被拆分给多个并行子智能体，每个子智能体拥有独立的上下文，冗余内容不会进入主对话。这个设计思路与 Claude Code、Cursor、Codex 的对比 中讨论的子代理架构是同一流派：用一个调度者指挥一群执行者，各自维护干净的工作记忆。
再看 /goal。把一个目标交给 /goal，Step Code 会自主推进，不需要你一步步盯着；配套的 /cron 可以按计划周期运行；状态栏会显示当前任务的实时计时器。这三个细节合起来指向同一个方向：把 agent 从"问答工具"变成"常驻执行者"。长任务委派是 2026 年 agent 产品竞争的焦点之一，Step-Code 在第一版就把 /goal 与 /cron 做进了核心命令集，产品意图很明显。
第三是 StepPage，这是最容易被低估的一项。README 的描述是：本地页面就绪后，一条命令就能把它发布为可访问的静态网站，内置版本管理与回滚。开发、调试、交付的闭环全部收在同一个终端里完成。对快速做原型、给同事演示、发临时页面的场景，这条链路省掉的是整个部署环节，从终端直接到可分享的网址。
第四是生态兼容，这是官方明显下了功夫的部分。MCP 服务器与 Agent Skills 开箱即用，插件与多智能体编排同样开箱即用，大多数 Claude Code 插件直接兼容，通过 /plugin 管理。更有诚意的是迁移细节：Claude Code 与 Codex 的 MCP 配置在首次启动时自动导入，源文件不被修改，导入是幂等的，密钥永远不会被内联。已有的 CLAUDE.md 原样沿用，/init 则生成等价的 AGENTS.md 项目指南。这套设计翻译成人话就是：从 Claude Code 搬过来的成本，理论上接近于零。
第五是安全边界。四种权限模式，Ask、Read Only、Bypass、Autopilot，用 Shift+Tab 循环切换；而且在任何模式下，危险命令都需要单独的确认对话框。这条底线设计值得肯定，分级授权的思路也与本站权限对比类文章关心的是同一件事。
五、上手路径：安装、登录与第一天能做的事
安装走官方安装器，下载最新版本、校验和验证、装到 ~/.stepcode/bin 并更新 PATH。macOS、Linux 与 WSL 用：
curl -fsSL https://static-openapi.stepfun.com/stepcode/install.sh | bashWindows 的 PowerShell 对应：
irm https://static-openapi.stepfun.com/stepcode/install.ps1 | iex注意 README 明确说 Windows PowerShell 支持目前处于 beta，Windows 上官方建议在 WSL 里安装。装完开一个新终端验证：
step --version
step --help以后升级用 step update。
登录之后，进入项目目录启动：
cd /path/to/your/project
step第一天可以做的事，README 给了两个例子。先用一句提示词让 agent 熟悉项目："What is the tech stack of this project? What is each directory responsible for? How do I run it locally? Don't modify any files yet."，此时它只读不改；再让它做一件实际的事，比如给 src/api/errors.ts 里的错误码建一张参考表存到 docs/errors.md。这个由浅入深的路径设计得不错：先建立信任，再委派任务。
会话管理也是标配：step -c 继续最近一次会话，step -r 浏览历史挑一个恢复，TUI 里 /resume 找旧会话，/hotkeys 列出全部快捷键。除了交互式 TUI，它还有无头形态：step -p "..." 直接带任务启动，不进交互界面，适合脚本、CI 与批量作业。快捷键里也有几个值得记住的：@ 引用项目文件，!command 跑一条 shell 命令并把输出交给模型，流式输出过程中按 Enter 可以让消息排队，等当前工具调用结束后再送达，Esc 则随时中断正在跑的任务。这些细节单独看都小，合起来决定了它作为日常工具的手感。
想折腾源码的话，仓库本身用 Git、Node.js 与 pnpm 构建，clone 之后 pnpm install --ignore-scripts、pnpm run build、pnpm step 就能跑起来。卸载也交代得干净：删除 ~/.stepcode 目录即可移除全部数据。
六、跑分与冷思考：80.9% 之外值得想的事
官方新闻口径（经 AI 工具集 9 月 24 日转述）给出了一组相当亮眼的数字：Terminal Bench 2.1 以 80.9% 的通过率并列第一，且 token 消耗更低；在六款 Agent Harness 的对比中，其自建长程基准 Multi-Frame 以 73.3% 居首，平均 5.09M Tokens 为最低。
这里必须做口径标注：以上三项数字全部是阶跃星辰的自报口径，而非独立第三方复测。其中 Terminal Bench 2.1 是公开基准，横向可比性相对强，但自报成绩的测试配置与判定标准仍由厂商掌握；而 Multi-Frame 是厂商自建基准，题目、环境、判分都出自一家，参考价值要再打一个折扣。对基准数字保持克制的信任，是这个行业的基本素养，我们在 AI agent 基准可信度 一文里专门讨论过这个问题：厂商自报数据永远值得看，但决策不该建立在它上面。
然后是冷思考。438 星对一个上线不足四个月的开源项目来说是正常起点，但也仅此而已：这个体量意味着社区生态还没经过检验。44 个开放 issue 数量不算夸张，但对一个终端 agent 来说，issue 积累速度与处理质量，直接决定它的工程成熟度走向。更关键的是，"官方模型加官方壳"路线的成败，最终取决于 Step 系模型本身在编程任务上的竞争力，壳再好，发动机不行也白搭；反过来，如果 Step 模型持续进步，这个深度绑定的壳就可能成为体验最好的选择。这是一个把宝押在自家模型上的赌注，值得持续观察，不宜现在下结论。对普通读者来说，观察窗口其实很具体：看它的 issue 关闭速度与响应质量，看有没有第三方团队给出独立复测数据，看 Step 系模型在编程场景的迭代节奏。三件事有任何一件向好，这个项目的权重就该上调。
给一个务实的结论：已经在用 Step Plan 或 Step Platform 的团队，Step-Code 值得立即试用，迁移成本接近零；重度依赖多提供商的团队，把它当作观察对象，等生态与第三方复测数据再决定；所有团队的共同动作是，把厂商自报的 80.9% 当作线索而非答案。
常见问题
Q1： Step-Code 是免费开源的吗？ A1： 仓库以 MIT 协议开源（最终口径以仓库 LICENSE 文件为准），代码可自由使用、审计与修改。但开源不等于免费用模型：它默认只接 Step provider，模型用量要么走 Step Plan 的 Mini、Plus、Pro、Max 套餐内含额度，要么用 Step Platform 的 API key 按请求计费。
Q2： Step-Code 能接 OpenAI 或 Anthropic 的模型吗？ A2： 按 README 的说法不能。默认入口只内置 Step（StepFun）一个模型提供商，四种 Profile 只是选择服务区域与计费方式，并非独立提供商。如果你的团队需要 BYOK 多提供商自由度，路线更接近的开源对手是 minimax-code。
Q3： Windows 用户怎么安装？ A3： 官方提供 PowerShell 安装脚本，但 README 明确说该支持目前处于 beta，Windows 上建议在 WSL 里安装使用。安装器支持 --version 指定版本与 --install-dir 自定义目录。
Q4： 我已经是 Claude Code 用户，迁移成本高吗？ A4： README 给出的迁移路径相当顺滑：MCP 配置首次启动自动导入（源文件不修改、幂等、密钥不内联），大多数 Claude Code 插件直接兼容并用 /plugin 管理，已有 CLAUDE.md 原样沿用，/init 可生成等价的 AGENTS.md。
Q5： 80.9% 的 Terminal Bench 2.1 成绩可信吗？ A5： 这是阶跃星辰的自报口径，不是独立第三方复测；其中 Multi-Frame 73.3% 还是其自建基准，题目与判分都出自厂商一家。建议把它当作值得关注的信号而非决策依据，并保持对厂商跑分口径的审慎。