你交给 AI 一项研究任务：先翻几十份文件，再上网核对资料，写代码分析数据，最后交出一份能复查的报告。它可能每一步都说得像模像样，却在半路用错文件、忘记前面的结论，或者代码报错后干脆从头再来。Apodex 1.1 想解决的正是这类问题：不只让模型回答问题，而是让它把一项复杂工作持续推进到可检查的成品。
论文把这种能力称为 working capability，即“工作能力”：围绕现实目标持续取得有用、可验证的进展。这里的 Agent（智能体），是能反复观察情况、制定计划，并调用搜索、文件和代码工具的 AI。值得注意的是，目前所有性能结论都来自 Apodex 团队自己的论文；论文虽提供了大量设计说明，却没有在供稿材料中披露主表的具体得分、完整对照模型和统计检验。因此，这更像一份值得研究的系统路线图，还不能证明 Agent 已经普遍接管真实复杂劳动。
先把“答得好”换成“活干完”
普通聊天模型的基本单位是一问一答。Apodex 1.1 换了一个衡量单位：完成的工作。
一项任务不只有提示词和最终回复。它还包括初始文件、可用工具、操作预算、过程中不断变化的状态，以及一份 delivery contract——交付契约，也就是“最后必须交什么、满足哪些条件、怎样才算完成”。自然语言报告可以是交付物，但模型说一句“已经完成”并不等于成功。结果还要经过测试、重新计算、来源核对、结构化标准或人工审查。
这就是“可验证交付”：判断重点从文字是否像样，移到事情是否真的办成。例如，代码修改要能通过测试；报告中的关键数字要能追溯到文件或计算；研究结论要能对应到证据。
长程工作流尤其考验状态维护。它像接手一个要走几十步的项目：哪些文件是最新版，哪些结论已被推翻，哪条分支仍在运行，都必须记清。早期一个小错如果没有及时隔离，后面几十步可能全部建立在错误前提上。失败恢复也不是简单重跑，而是保留仍然有效的成果，只撤销受影响的部分。
两条扩展路线
Apodex 1.1 没有只靠增加模型参数，而是沿两个方向扩展能力。
第一条叫 Environment Scaling，可译为“环境扩展”。它扩大模型训练和执行时接触的文件、搜索与代码环境。文件环境训练模型识别权威版本、处理多种格式并保留来源关系；搜索环境要求它发现资料、筛选来源、对齐论断与证据；代码环境则让它修改可执行状态，再通过测试和产物检查确认结果。
关键不在于接入更多工具，而在于让工具操作真正改变任务世界，并让变化可以验证和重放。论文称，其文件任务登记体系覆盖 33 个领域、318 种职业和 1,208 类交付物。不过，文件越多不等于任务越难。真正的难点可能是权威资料藏得更深、业务逻辑链更长，或者交付要求必须从上下文中推断。
第二条叫 Agentic Coordination Scaling，即“智能体协作扩展”。主 Agent 会把目标拆成任务分支，按需委派给不同子 Agent；结果不必等所有分支结束才统一返回，而是可以异步汇入。主 Agent 随后更新共享计划，终止已经过时的工作，或根据新证据开出新的分支。
这更像一个会动态改排期的项目组，而不是同时问几个模型再投票。论文强调，扩展变量不是 Agent 的数量，而是系统能否随着目标变化，继续组织有用的工作。
AgentOS 是那本共享账簿
文件、搜索、代码和多个 Agent 如果各自保存一套上下文，很快就会出现版本混乱。Apodex 1.1 因此使用共享执行框架和 AgentOS。后者是持续保存任务状态的运行层，可以把工作区、文件版本、证据来源、任务分支、工具结果与失败记录放在同一套状态中。
论文还把任务分解写到一块显式 task board——任务看板。看板记录每个分支的目标、依赖、执行状态、负责人和返回的证据。一个结果可以立即解锁后续任务；某个前提被推翻时，系统只需让依赖它的分支失效，而不必抹掉其他已经完成的工作。
用户也能在执行途中介入。若只是调整优先级或补充资料，系统更新相关分支，并保留不受影响的成果；若用户改变了目标、交付物或验收条件，论文则把它视为一份新的任务契约，不过仍可沿用有效的工作区状态。
它怎样学会“做项目”
训练材料不再只是问题与答案。Apodex 1.1 使用两类过程记录：一类是模型在文件、搜索和代码环境中的执行轨迹；另一类是多 Agent 进行拆解、委派、汇总、重规划和恢复的协作轨迹。
系统先通过 SFT（监督微调，即用示范过程教模型模仿正确行为）建立共同的工具操作与协作方式，再用 agentic RL（面向智能体行为的强化学习，即根据长程执行结果调整策略）改进过程中每一步的选择。运行失败、基准错误、专家意见和用户反馈又会被归类为能力缺口，用来决定下一轮应构造哪些任务与环境。
论文把这个循环称作受控的工程流程，并明确说它不是模型不受约束地自行修改自己。这一区分很重要：所谓“自我演化”，在这里是团队依据失败记录重新分配训练资源，而不是系统自由改写自身目标。
为什么现在值得看
Apodex 1.1 抓住了 Agent 走向实用的一道分水岭：复杂劳动的瓶颈往往不是某一道题不会，而是几十次操作能否保持一致。模型可能会推理，却未必能维护文件权威性；会写代码，却未必能从报错中恢复；会搜索，却未必能让结论对应证据。
因此，它最有价值的部分不是“Heavy-Duty Solver”这一宣传性目标，而是把进展、状态、来源、恢复和验收放进同一套任务定义。论文还区分了两种评测方式：ReAct 用较少的外部编排观察模型自身能力；Agent Team 则衡量经过组织的并行协作能带来多少系统级提升。这让“模型更强”与“系统投入了更多协调和计算”至少在概念上可以分开讨论。
团队称，Apodex 1.1 在专业工作、金融、科研、数学、编程和搜索任务中进入领先性能区间，且模型规模小于许多前沿系统；35B 参数的 Apodex 1.1 Mini 也被称为保留了较强工作能力，并可在本地部署。但这些都是单一论文信源中的概括性表述，现有材料不足以把它们改写成“行业第一”或“已经可靠”。
局限与未知
- 供稿材料没有给出关键基准的具体得分、完整对照模型、评测协议或统计显著性，因而无法判断所谓“领先区间”究竟领先多少，也难以排除系统脚手架和额外计算带来的影响。
- “可本地部署”没有附带显存需求、量化方式、推理速度和硬件配置。35B 参数说明了模型规模，却不能单独说明普通设备能否实用运行。
- 论文展示的是能力设计与团队自报评测，不是大规模生产部署证据。更稳妥的结论是：Apodex 1.1 正在搭建一套让 Agent 承担复杂工作的基础设施，而不是 Agent 已经开始普遍接管复杂工作。