35B 模型跑出 GPT-5.6-Sol 的金融分析分Apodex 把 Agent 的「工作能力」写进了参数里Hugging Face 每日论文2026-08-25 精选8 月 24 日 Hugging Face 每日论文榜排到第一名的位置是一篇 70 位作者联名、长度超过 50 页的技术报告Apodex 1.1arxiv:2608.23283。它给出的不是一个新 benchmark而是一种叫「工作能力」working capability的新能力维度——能让一个模型在文件、搜索、代码三种真实环境里从「回答问题」过渡到「把任务做完交差」。最反直觉的是当 35B 参数的 Apodex 1.1 Mini 配上一个叫「异步 Agent Team」的协作模式后它在 FrontierFinance 这个高难度金融研究基准上打到了 50.2 分超过了同榜单上的 GPT-5.6-Sol46.8、Gemini-3.1-Pro30.5与开源大尺寸的 DeepSeek-V4-Pro45.5和 GLM-5.242.8拉开了明显差距。一件反直觉的事小模型反而更「工作」过去一年多AI 行业形成了一种近乎默认的等式模型越大、任务越复杂、效果越好。这套等式在对话、写文、简单问答上确实成立但一旦把任务换成长达数小时、需要查资料、读文件、改代码、交叉验证的研究型工作等式就开始失效——大模型的「参数容量」并不天然能转化为「按交付物定义的工作能力」。Apodex 1.1 给出的解释是过去 agent 类系统把太多事情交给「运行时编排」去做orchestration on top of model把模型本身当成一个不怎么会做事的「响应器」。这导致两件事必然发生编排层在多代理、异步、状态保持、错误恢复上的开销越来越大且不能被模型本身消化模型只在「被调度」时工作调度一断、协作一停整个任务的进度就退化回「单次生成」Apodex 1.1 的 70 位作者用一种「两条 Scaling 同时拉」的方式把这件事拆开环境维度上的 Environment Scaling 把可执行的文件、搜索、代码环境变得多样且可验证协作维度上的 Agentic Coordination Scaling 把「分任务、派子代理、回收异步结果、重排计划」训练成模型本身的内部行为而不是堆在外的脚本。维度训练目标解决的问题论文对应方法Environment Scaling让模型在不同可执行环境里学习如何把任务做完编排层独自承担环境适配模型不会「动手」文件 / 搜索 / 代码三类可验证环境扩展Agentic Coordination Scaling让模型自身会分解、委派、整合、回收异步结果协调只能依赖外部脚本单代理上下文拥堵异步 Agent Team 训练在模型内AgentOS 公共底座提供状态、轨迹、复查的统一执行底座两条 Scaling 的能力无法对齐到同一条执行线任务无感知 runtime承载两条 ScalingStatement Review 独立校验关键结论在交付前必须经独立校验模型自己既写又审结论易被自洽偏好污染外部独立 verifier 检查后再交付这四条共同把「工作能力」从「编排层外挂」搬到了「模型内化」是 35B Mini 能反超大模型的最直接解释。「异步 Agent Team」到底在做什么「异步」二字听起来像工程优化实则指向一个根本不同的训练范式。Apodex 1.1 的 Agent Team 不是一个被固定角色表researcher、coder、verifier填好的多代理系统而是「任务驱动的临时队伍」主代理lead agent先对问题做整体推理把它分解成可研究的子问题子代理subagents按子问题临时构建——每个子代理有自己的上下文、prompt、工具集子代理之间的结果不互相阻塞可以异步返回主代理按「收到即可继续」的方式整合而不是「等所有分支跑完再决策」这套设计的核心收益在 FrontierFinance 这类长程研究任务上变得非常具体。论文给出的数字是当 Apodex 1.1 Mini 从 ReAct 切到 Agent Team 时FrontierFinance 从 40.0 提到 50.210.2、FrontierScience-Research 从 45.0 提到 51.76.7、APEX-Agents 从 24.2 提到 27.73.5。注意一个细节异步 Agent Team 不是「跑得越多越好」而是「跑得越对越好」。论文里强调Apodex 部署在生产环境时协调子代理的上限是 150 个、单任务总步数可达 15000 步——但同样配置下并不是所有任务都需要触顶过深的并行反而会因为「上下文互相污染」拉低准确率。AgentOS把状态从「对话上下文」里搬出来异步协作一旦上量最先崩的一定是「状态」。传统 ReAct 系统的状态几乎全堆在模型上下文里每多一个子代理、每多一步工具调用上下文就涨一截等到千步级别几乎必然触发「上下文拥堵 早期探索被遗忘」的退化。Apodex 1.1 的解法是把状态搬出对话上下文交由一个叫 AgentOS 的 runtime 统一管理。AgentOS 不关心任何具体任务它只负责四件事维护持久工作区与工具状态把运行时事件转成模型可观察的 observation在长轨迹里保留「有用的进度」控制中间产物如何变成最终交付更具体一点AgentOS 在 Agent Team 模式下把协调层建在同一个底座上——它不重新定义底座而是在底座之上叠加 Task Board、Agent Bus、Statement Review 三件东西Task Board 把协调者拥有的「解题进度」存到模型对话历史之外Agent Bus 把 runtime 的执行状态以可观察的方式暴露给协调者Statement Review 在关键结论交付前由独立的 verifier 角色做一次「外部检查」论文里的 AgentOS 状态契约图state contract清楚画出了 /inputs只读、/workspace按隔离模式区分私有/共享、/outputs共享交付三块边界。子代理在自己的 /workspace 里写中间结果主代理可以查、但 sibling 看不到/outputs 是唯一允许最终交付物写入的位置。这种「状态外置」的设计让异步 Agent Team 即使跑到 150 个子代理、15000 步也不会因为上下文溢出而失忆——所有「解题进度」都被结构化存盘需要时被 AgentOS 重新喂回模型。35B Mini把 frontier 性能塞进 8GB 显存如果说异步 Agent Team 是「软件侧」的工程那 35B Mini 的存在就是「硬件侧」的信号。Apodex 团队同步开源了 Apodex 1.1 Mini35B-A3B MoE 架构整份权重可以在 RTX 4090 / 5090 等单卡上跑起来。论文里给的数据是配 ReActFrontierFinance 40.0、FrontierScience-Research 45.0、APEX-Agents 24.2配 Agent TeamFrontierFinance 50.2、FrontierScience-Research 51.7、APEX-Agents 27.7横向对比同榜单的更大体量系统Gemini-3.1-Pro 在 FrontierFinance 30.5、FrontierScience-Research 16.7GPT-5.6-Sol 在 FrontierFinance 46.8、APEX-Agents 39.9DeepSeek-V4-Pro 在 FrontierFinance 45.5、APEX-Agents 24.3。35B Mini Agent Team 的组合在 FrontierFinance 上超过了除 Gemini-3.1-Pro 之外的所有对比系统在 APEX-Agents 上与 DeepSeek-V4-Flash34.4有差距但高于多数开源系统。这不是说 35B 比 70B/300B 更「聪明」——它说的是在「工作能力」这个新维度上把环境多样性、协作范式、可执行底座同时拉满可以让一个中等参数模型在「实际完成任务」这件事上追平甚至超过更大参数系统。「工作能力」为什么不能只用 benchmark 衡量论文反复强调一个观点传统 benchmark 衡量的是「回答的准确度」而「工作能力」衡量的是「按交付物定义的可验证完成度」。这个区别在论文的评测设计里被严格执行ReAct 视角单代理顺序跑反映模型本身的工作 policy 强度Agent Team 视角协作范式叠加反映「协调 额外算力」的额外增益在 FrontierFinance 这类研究型任务上Apodex 1.1 用 ReAct 就已经打到 48.7 分Agent Team 把它推到 54.3提升 5.6 分。论文里把这种「模型-系统双视角」的拆分叫做「性能带」performance band结果——它回答的是「哪一类系统在什么算力预算下能做哪一类工作」而不是「哪个模型在哪个榜单上更高」。这种评测视角本身是一个信号研究者越来越意识到把 agent 系统当成「模型 编排」拆开评测是不够的真正决定长程任务完成度的是「模型 协作 环境 底座」的整体协同。FrontAgent把整套工作范式打包进一个命令行如果论文只是给数字那它只是又多了一篇 SOTA 报告。Apodex 1.1 的工程诚意在于它把整套 Agent Team AgentOS 的能力打包进了一个叫 FrontierAgent 的开源工具开发者可以在 macOS / Linux 上用一条命令起一个终端 TUI跑 ReAct 或 Agent Team。仓库ApodexAI/FrontierAgent里给出几个值得注意的工程细节两个开箱即用的工作流ReAct 单代理顺序跑、Agent Team 协调者 子代理异步并行Docker 可用时自动用容器隔离执行环境不可用时回落到本地 runtime异步人为干预跑 Agent Team 时可以临时输入新指令协调者在下一个安全 turn 边界注入已跑的子代理被允许跑完内置评测框架支持 BrowseComp、FrontierFinance、FrontierScience-Research、APEX-Agents、HLE、OneMillion-Bench 等 14 个基准这套工程包装把论文里的两条 Scaling 真正变成了「可在自己机器上跑的 agent 系统」。对于今天已经在做 RAG / agent / 工具调用产品的团队来说这是 2026 年 8 月最值得立刻 clone 下来跑一遍的代码之一。局限两条 Scaling 都不是「训一遍就完事」论文自己承认了几条边界。第一Agent Team 的异步并行上限取决于「任务可分解度」。如果一个任务本身不可并行必须先读完 A 才能读 B异步 Agent Team 会退化成顺序执行收益大打折扣。论文里给出的 150 子代理、15000 步是「上限可达」不是「每次都达到」。第二Statement Review 引入的额外 verifier 调用是有成本的。当任务的关键结论密度很高时verifier 调用的次数会显著增加论文没有给出 verifier 调用次数 vs 总成本的具体曲线但工程团队落地时必须把这个成本算进去。第三35B Mini 的 frontier 性能来自「环境多样性 协作范式 训练数据」三件同时拉满任何一件降级比如只跑 ReAct、不异步、不验证都会让分数明显回落。换句话说这套系统不是一个「训好就通用」的模型而是一个「按工作范式配套使用」的系统。第四Apodex 1.1 的论文承诺未来把工作能力前置到 pretraining 阶段Apodex 2.0但这条路径目前尚未落地。当下的 Apodex 1.1 仍然是「scaling up the loop, not the pretraining」它能从 GPT-5.6-Sol 手里抢到 FrontierFinance 的领先位置不是因为模型参数被压进了更多知识而是因为「会做事」这件事被训练进了参数里。论文之外值得思考的事把这篇论文读完最值得带走的认知是「工作能力」这件事的瓶颈不在模型大小而在协作范式环境多样性训练目标三件同时拉满。过去一年整个 agent 赛道的进化路径大致是单代理 ReAct → 固定角色的多代理 → 异步协作的多代理 → 训练在工作范式里的多代理。Apodex 1.1 把最后一步做实了并且用 35B 这个不算夸张的尺寸证明了「工作能力」可以跟 frontier 大模型同台竞技。这件事对正在做 agent 落地的团队意味着当你在评估「是该把模型换大、还是把协作范式重做一遍」时看 Apodex 1.1 那一列 ReAct 到 Agent Team 的分数跳变比看任何一个 SOTA 模型卡都更有参考价值。而对做模型训练的团队来说这篇论文传递的另一条信号同样重要环境多样性本身就是 scaling 的一个面。把可执行环境的种类从 3 个扩到 30 个、把 verifier 从 1 个扩到 5 个、把异步回收策略从「等所有分支」换成「流式回收」这些工程动作所产生的 scaling 效应可能比单纯把 pretraining 数据再加一倍更直接。这也是为什么 Apodex 在论文里反复强调 Environment Scaling 是「scaling surface」——它是一个可被独立拉满的轴而不是模型大小的附属品。