FrogNano-4B-2609：微软把一个 4B 编程智能体发布到了 Hugging Face，却从未宣布

该仓库于 2026 年 9 月 17 日随首次提交一起上线，检查点本身则在四分钟后落地。然后便是一片沉寂。微软 AI 没有发布任何推文，微软研究院博客上没有条目，也没有发布页面。七周之后 microsoft/FrogNano-4B-2609——一个四十亿参数级的编码智能体，构建于 Qwen3.5-4B 之上——至今仍然没有任何公告为其背书，而这份沉默正是这个模型发布过程中最重要的事实。它确实拥有的，是一张声称附有论文和测试框架的模型卡、一个结果证明是测试框架而非论文的 GitHub 仓库，以及一个 createdAt 为 2026 年 9 月 17 日，却置于一张写着 "Release date 22-SEP-2026" 的模型卡之下。两个日期都是临时拼凑出来的；两者都不能算错；它们彼此并不一致。

实际发布的是什么

以下所有内容现在都可以在 hub 上核对，本文中的每一个数字都来自 Microsoft 自己的模型卡，或来自该仓库本身的字节计数。没有任何内容由第三方复现——任何地方都没有 Artificial Analysis 条目，没有竞技场评分，也没有对 FrogNano 的独立评估。

• 权重 — Microsoft 组织下的一个公开仓库，无门槛，在 Hub 上标注为 MIT，15 个文件，无下载门槛，也无需签署任何协议。

• 磁盘上的权重 — 9.32 GB，分布在两个 safetensors 分片中，包含无优化器文件集在内的 596 亿字节仓库数据，索引中有 738 个张量。

• 架构——Qwen3_5ForConditionalGeneration，继承自Qwen3.5-4B的密集32层混合堆栈，外加一个24层视觉塔，卡片上称其为继承而来且从未进行后训练。

• 卡片自身的参数栏——"500M-5B"。那是一个范围，而非一个具体数值，而下载的文档才是更精确的资料。

• 许可证 — 卡片的前置页写的是 MIT。卡片正文本身却写的是 Apache License 2.0，而 GitHub 上的测试框架确实随附了一个 MIT LICENSE 文件。这两处说法针对的是同一发布版本中的不同构件。

• 公告——无。微软研究院博客上没有，团队自己的研究网站上没有，Hugging Face 组织动态里也只是个仓库列表，除此之外什么都没有。

最后那句话，才应该为读者定下阅读本文其余部分的姿态。一个悄悄上传的检查点，并不比一个对外公布的检查点低一等——它的说明卡往往更长，因为没人会为了新闻稿而把它删短。但它没有经过对外公布的发布能免费获得的那道筛选：让别人来看它。

这些得分，以及每一分分别是由谁得到的

Microsoft 报告称，FrogNano 在 SWE-bench Verified 上达到 61.5%，在 SWE-bench Pro 上达到 37.6%，在 Terminal-Bench 2.0 上达到 31.1%，在 PatchEval-Verified 上达到 47.3%，这些均为通过 Leaf harness 测得的 Avg@3 解决率。同一张卡片给出了起点：Qwen3.5-4B 在相同 harness 和预算下，在 SWE-bench Verified 上得分 39.4%。五轮强化学习迭代使其依次经过 49.1%、53.1%、56.7%、59.1% 和 61.5% —— 相比基础模型提升 22.1 个百分点，Microsoft 自己的表述将其约整为约 56% 的相对提升。

关于那个阶梯，有两点值得停下来琢磨，因为它们是摘要可能出错的地方，而不是供应商出错的地方。

第一个是 Iter 5 的数据出入。卡片的主表显示最终迭代为 61.5%；而论文自己的效率附录报告同一组五个检查点的递进值为 48.2%、53.4%、58.3%、58.6% 和 61.6%。只有最后一个数字是接近的，也只有最后一个数字是人人都会引用的那个。应当把最终数值视为稳定结果，而把中间各档视为对不同对象的测量，因为在另一种聚合方式下，它们显然就是如此。

第二点是，FrogNano 并非在每一个维度上都比其起步时所基于的模型更优。其公布的并行工具调用率为 1.71%。模型卡坦言，后续迭代失去了在单轮中触发多个工具调用的能力，而团队的整合工作部分就是为了恢复这一能力。一个能解决更多问题、却几乎不发出并发调用的模型，是一种实实在在的工程权衡，而不是一个脚注。

测试框架就是产品，而代码仓库就是那个测试框架。

FrogNano 不能自行运行。它会向五个工具发出结构化调用——Read、Write、Edit、Glob 和 Bash——并且必须有某个东西在隔离环境中执行它们并返回输出。那个东西就是 Leaf，而在这里，这条轨迹会做出一些略微不寻常的举动。

模型卡片的“其他相关资产”一行链接到一份技术报告 aka.ms/frognano-tech-report，以及一个位于 github.com/microsoft/FrogNano 的评测框架。aka.ms 这个链接并不指向 PDF；它直接重定向到 arXiv 摘要页，而真正的报告就在那里。与此同时，该 GitHub 仓库里没有训练代码、没有强化学习配方，也没有检查点。它自己的 README 描述的是一套评测框架，该框架在 Kubernetes 沙箱中针对一个兼容 OpenAI 的端点运行编程智能体，并回指那篇 arXiv 论文来说明训练过程。因此，卡片上的这两个资产链接，一个指向论文，另一个指向论文的回应，而这个名字是两者共用的。

对任何打算使用这个模型的人来说，这一点都很重要，原因很实际。文档给出的部署方案是 SGLang 搭配 --reasoning-parser qwen3 和 --tool-call-parser qwen3_coder，而评测框架要求端点本身就已经能处理工具调用和推理。解析配置稍有差错，模型就会在评测框架期望 JSON 的地方输出文本，从外部看，这完全就像是一个糟糕的模型，而不是糟糕的配置。卡片明确指出，任何匹配的分数都要求匹配的检查点、分词器、服务配置、任务镜像和评估协议——这等于厂商在告诉你，评测框架占了结果的一半。

同样值得向任何评估硬件配置的人直白说明：在模型卡所评估的上下文长度下，9.32 GB 的检查点并不等于 9.32 GB 的推理问题。评估运行在大约 131K 的总 token 量上，步数预算为 150 步。内存随上下文扩展，而非随权重扩展；而模型卡称最低 GPU 配置仍“必须在发布前验证”——这句话出现在一个已经可以下载的模型上。

训练实际上做了什么，用一段话说明

这篇论文的贡献不在模型本身，而在于这个循环。TaskPilot 从真实的代码仓库快照中生成候选软件工程任务，用当前检查点针对这些任务运行 rollout，保留那些处于策略有时能解决、有时不能解决的边缘附近的候选任务，并丢弃那些永远过于简单或永远不可能完成的候选任务。被接受的集合用于训练下一个检查点。随后，那个下一个检查点会校准下一轮任务生成，因此任务分布会随着策略的变化而变化。总共约有 1,500 个经过验证的环境。没有蒸馏：模型卡明确说明，针对智能体的后训练没有使用更强模型的解题轨迹、动作、推理痕迹或补丁目标。更强的模型负责编写任务；它们并不演示答案。

Microsoft 运行该循环五次迭代后，报告在任何整合之前就获得了 8.7 个百分点的提升，并在运行中途加入了日志长度惩罚，因为推理轨迹的增长速度超过了其改进速度。

模型卡异常直白地指出了整个方法在哪些地方脆弱。训练数据以 Python 为主，且主要是英语；卡片中声明的支持自然语言集合只有英语，别无其他，并且明确没有声称基础模型具有更广泛的多语言覆盖能力。性能对测试框架以及测试质量很敏感。生成的补丁“可能在通过现有测试的情况下仍不正确或不安全”。4B 的模型卡用一句每位读者都应记住的话结束了那一段：未经合格的人工审查以及独立的回归测试和安全测试，不得使用。这是一份关于厂商自身产品的厂商声明，而且它比上面任何一行评分表都更有用。

这让买家处于什么境地，又让路由器处于什么境地

FrogNano 并不是一个供你调用的模型。它没有第一方 API，没有托管端点，也没有无服务器镜像。它是一个检查点，要使用它，要么在 Kubernetes 托管的沙箱背后搭建你自己的 SGLang 部署，要么把它作为组件放进你已经在运行的智能体技术栈中评估。这就是当下完整的采用路径，任何公告都不会改变它的形态。

路由层在这里能如实做到的事，比乍一听要窄。如果计划是在你自己的测试框架内，把自托管的 FrogNano 与托管式编码模型进行比较，那么托管的那一半，才是受益于放在一把密钥之后、而不是再签一份合同的那一半：OrcaRouter 通过一个 OpenAI 兼容端点承载 200 多个模型，加价为 0%，这意味着供应商目录价原样透传，供应商调价当天就会在我们这边生效。对于一场结果由每个已解决问题成本、而非单一基准分数决定的横向评测来说，这一点很重要。我们不托管 FrogNano，也没有相关时间表；权重和部署服务的工作都由你来做。

能够解决这个问题的三件事

首先，一次独立复现。本文中的每一个数字——61.5、37.6、31.1、47.3——都是由训练该模型的实验室得出的，使用的是同一实验室维护的评测框架，对照的是同一实验室测得的基座模型数值。这是一幅完整且内部一致的图景，同时也是一个闭环。有用的检验是：一个没有利益相关的人，能否在同样的 500 个任务上复现从 39.4 到 61.5 的跃升，且没有微软对任务集所做的校准工作。

第二，必须有人端到端地核查这个测试框架的说法。代码库是公开的，这已经比许多发布版本做得好，但它是评估装置。如果这五个工具和沙箱隔离确实是性能机制，那么第三方按已发布的配置运行，结果就应接近已公布的数字。如果并非如此，那这个差距才是真正的发现。

第三，也是最容易回答的：微软应该说明这是一款产品，还是一份论文产物。卡片的分发部分将权重、卡片和测试框架视为交付物，这读起来更像是发表而非发布。“发布日期 22-SEP-2026”读起来像发布。一个已宣布的模型本可以在博客文章的第一句话中消除这种歧义，但并没有博客文章。

在那之前，正确的姿态正是发布本身所暗示的那种。FrogNano-4B-2609 是一个真实、可下载、采用 MIT 和 Apache——也许并非如此——许可的检查点，附带一张异常详尽的模型卡、一个公开评测框架、一个真正的方法论构想，以及一个从未被任何没有 Microsoft 邮箱地址的人碰过的记分牌。对一个实验室来说，这是一件完整而有趣的产物。对一支即将在凌晨三点把智能体放到代码仓库面前的团队来说，这是一条值得追踪的线索，而不是一个值得做出的决定。