Recursive开源了面向本地编程智能体的Flint模型权重（Apache 2.0），采用约398亿参数的混合专家架构并公布了性能与运行要求。公司强调自动化研究系统Eureka Machine参与了架构搜索、量化和底层优化，但人类监督仍在，实际本地部署和性能需在相同条件下验证。
Recursive发布了面向本地编程智能体的Flint，并以Apache 2.0许可开放模型权重。按照其官方模型卡，Flint采用混合专家架构，总参数量为398亿，每生成一个token约激活25亿参数，支持代码库调查、缺陷修复、功能实现和测试编写。
这次发布的另一条主线是模型的开发方式。Recursive在公告中称，一个由人类研究人员与智能体组成的小团队，在不到四个月内从零构建了Flint；公司的自动化研究系统Eureka Machine参与了数据、训练方案、基础设施和推理优化等环节。不过，这仍是有人类参与和监督的研发实践，并不意味着已经实现无需人工干预的递归自我改进。
时间上，TechCrunch于2026年10月21日发表的报道明确称，Flint在当天发布。该报道随后于10月22日更新；Recursive公告本身未标出明确发布时刻。因此，应将10月21日作为有媒体正文支持的公开发布日期，而不是把更新日期或新闻采集时间当作首发时间。
面向本地编程，但不是“25亿参数的内存需求”
Flint的定位不是单纯的代码补全，而是作为编程智能体的模型基础：读取项目、生成修改方案、提出工具调用，并根据执行结果继续工作。官方模型卡列出的能力包括文本输入输出、推理和多轮工具使用。
这里需要区分模型和执行环境。Flint负责生成文本与工具请求，真正读取文件、修改代码或运行测试的是连接它的智能体框架。模型具备工具调用能力，不等于它自身已经提供了完整、安全的开发环境。
混合专家架构则解释了它为何能够在较大的总参数规模下减少每个token的计算量。Flint的每个MoE层包含256个路由专家，每个token选择其中6个，另有一个始终启用的共享专家。官方所说的约25亿激活参数包含输出层，而不是整个模型的存储规模。
因此，“每个token激活25亿参数”不能理解为只需装入25亿参数的权重，更不能据此断言任意笔记本都能运行。当前Hugging Face主仓库提供的是BF16检查点，模型卡将完整下载规模标为约80GB，并另外为NVIDIA与Apple Silicon运行时准备量化版本。
具体的本地门槛应看运行方案。Recursive的使用文档为其优化后的Mac推理引擎rec列出的要求，是M4 Pro、M5 Pro或M5 Max芯片，以及至少48GB统一内存。这与“普通笔记本普遍可用”有明显区别。BF16检查点、量化模型和不同推理后端，也不能视作同一套资源要求。
本地运行的吸引力在于，开发者可以在不依赖远程模型API的情况下处理代码、离线工作，并避免按token支付模型调用费用。但这些收益以实际采用本地推理为前提；智能体调用的外部服务、网络工具和遥测设置，仍需要单独检查。
性能数字需要连同测试条件一起看
Recursive公布的发布评测中，Flint在Terminal-Bench 2.1上得分54.9%，在SWE-bench Pro v2上为89.7%，在SWE-bench Verified上为74.2%。公司据此宣称，它在总参数量低于500亿的MoE模型中具有领先的编程智能体表现。
这些属于开发者发布的测试结果，不是本文独立运行模型所得的结论。模型卡也提醒，不同来源的评估设置存在差异：Flint的Terminal-Bench测试使用Terminus 2，SWE-bench测试使用mini-swe-agent；智能体任务报告的是至少五次尝试的平均pass@1，而不是让模型多次尝试后只选最好的一次。
另一个影响可比性的细节是，Flint在Terminal-Bench中将通过网络检索直接取得答案的情况记为未成功，而其他开发者公布的结果未必采用相同处理方式。因此，单看排行榜数字，并不足以判断不同模型在相同环境下的真实差距。
速度方面，Recursive称，借助其优化推理引擎，Flint在M4 Pro MacBook Pro上的短上下文生成速度超过每秒125个token，在其公告所称的64GB NVIDIA RTX Spark设备上超过每秒150个token。这些数字反映特定硬件、模型表示方式和推理栈下的生成速度，不能直接换算为修复一个软件问题所需的总时间。
实际编程还涉及读取提示、推理长度、工具等待、测试执行和失败后的重试。Recursive也承认，面对复杂任务，Flint可能比大型闭源编程模型需要更多指导，并建议用户把工作拆成较小的子任务，给出明确指令。
512k宣传上限与当前检查点配置并不相同
上下文长度是此次发布中需要保留来源差异的一项规格。
官方公告称Flint最高支持512k token上下文，但建议编程及其他任务保持在256k以内，以获得更好的结果。与此同时，当前Hugging Face模型卡明确列出的上下文配置是262,144个token，包含提示与生成输出；使用文档也将托管配置列为262,144个token，并要求本地部署遵循实际运行时设置。
这些表述不能简化成“下载后默认就有512k可用上下文”。开发者需要核对具体检查点、后端配置、量化精度和缓存设置。对智能体而言，代码、对话历史、工具定义、工具返回结果、推理过程和最终答案都会占用上下文，内存是否足够也会限制实际可用长度。
模型卡同时提醒，上下文配置只是容量上限，并不保证模型在所有长度和任务上都保持相同准确率。
Eureka Machine参与了什么？
按照Recursive的描述，Eureka Machine围绕既定目标提出想法、实现方案、运行实验，再根据结果决定下一轮尝试。它可以并行探索多条方向，并复用此前实验中的有效发现。
在Flint的开发中，公司披露了三个较具体的例子。
首先是架构搜索。团队从总参数量约350亿、激活参数约30亿的基线出发，让系统探索不同专家配置和宽度，最终选择了约400亿总参数、每token激活约25亿参数的设计。Recursive称，这一配置在其搜索范围内预计能更好地平衡速度与编程能力。
其次是量化。公司称，系统搜索了降低内存占用的方案，包括把输出层量化至4比特，再以16比特模型为教师，通过离线蒸馏恢复精度。按其公布的结果，最终NVFP4版本在相关基准的综合得分上，与16比特版本相差不超过0.7分。这仍是厂商测量，不能推定所有量化格式和部署环境都有相同表现。
第三是底层计算优化。Recursive称，系统为低比特投影、MoE运算、注意力和提示处理生成了专用计算内核，并针对M4与M5芯片生成了融合整个解码前向过程的Metal内核。这说明其速度主张并非只建立在减少激活参数上，也依赖模型格式与硬件实现的联合优化。
这些工作延续了Recursive此前公开的研究路线。在早期自动化研究报告中，公司已把固定预算模型训练、训练加速和GPU内核优化作为实验对象，并强调需要检查系统是否利用评估漏洞获取虚假提升。
类似问题也出现在其他研究智能体实践中。本站此前对腾讯混元Hyra-1.0的报道也讨论了这一验证难题：当智能体能够大量生成和筛选方案时，评估器能否识别数据泄漏、计时漏洞或其他奖励投机，会直接影响所谓“进步”是否成立。
开放权重之后，仍要验证真实开发表现
Flint采用Apache 2.0许可，为下载、修改和集成提供了明确的权重使用基础。Recursive的文档也列出了rec、Ollama、LM Studio、llama.cpp以及GPU服务方案等不同接入路径。不过，具体兼容性仍取决于模型版本和运行时，不能仅凭工具列表就假定任意现有安装均可直接加载。
模型卡对风险的说明也很直接：Flint可能生成错误代码、有害内容或不恰当的工具调用；结构化工具调用格式本身，不能阻止模型选择危险或错误的动作。用于真实项目时，仍需限制文件与命令权限、审查修改，并运行测试。
因此，这次发布可以从两个层面理解。一方面，Flint为具备相应硬件的开发者增加了一个可本地部署、可修改的编程模型选择；另一方面，它提供了自动化研究系统参与完整模型研发的公开案例。
但“参与开发”与“自主完成研发”之间仍有距离。不到四个月的开发周期，本身不足以量化Eureka Machine节省了多少人力或计算成本；厂商公布的性能和优化结果，也需要外部在相同条件下复现。Flint的后续价值，将取决于它能否在真实代码库中稳定完成工作，以及自动化研究带来的改进能否经受检查，而不只是发布时的速度数字和排行榜名次。