浙大蚂蚁联手打造“全能AI助理”
这项由浙江大学与蚂蚁集团联合开展的研究发布于2026年8月，论文以预印本形式公开，编号为arXiv:2608.05013，研究团队同时开源了完整代码与运行轨迹数据，供学术界复现与参考。
每个人的一天里都藏着无数琐碎又重要的任务。早上需要查资料、整理文件，下午要做演示文稿、发邮件，晚上还得分析数据、写报告。这些任务横跨网页浏览、文件编辑、代码运行等不同"战场"，还夹杂着图片、表格、文档等各种形式的内容。对人类来说，这些都是习以为常的日常操作，但对AI来说，这恰恰是最难啃的硬骨头。
当前的AI助手普遍擅长回答单一问题，比如"帮我翻译这句话"或者"解释一下这个词"。然而一旦任务变得复杂——比如"帮我查一下这个话题的最新研究，然后整理成PPT，同时确保格式符合公司规范"——大多数AI就开始掉链子：要么忘记了最开始的要求，要么在切换任务环境时把前面收集到的信息弄丢了，要么直接因为要处理的内容太多而"撑不住"。
浙江大学与蚂蚁集团的研究团队正是盯准了这个痛点。他们构建了一套名为OneDayAgent的系统，专门用来处理这类跨越多个步骤、多个环境、多种内容形式的复杂日常任务。在一个包含104道真实任务的标准测试集上，OneDayAgent取得了0.821的综合得分，刷新了该测试集的最高纪录。
一、AI在日常任务面前为什么会"崩"
要理解OneDayAgent解决了什么问题，先得搞清楚AI在处理复杂日常任务时会碰到哪几道坎。
把复杂任务比作一次长途自驾旅行。在旅途开始时，你规划好了路线：先去A城加油，再到B城取快递，最后在C城见朋友，全程还要确保车上装着礼物、不超重、按时到达。这个任务有多个环节、有约束条件、还涉及不同的地点和行动。
AI在这种"长途旅行"中面临的第一个麻烦叫做"目标漂移"。随着任务一步步推进，AI会逐渐把最初的要求忘掉。就像你在路上走着走着，忘了要给朋友带礼物这件事，到最后空手赴约。早期设定的格式要求、字数限制、特定的信息来源……这些约束条件在经历了大量的中间步骤之后，往往已经从AI的"记忆"里悄悄溜走。
第二个麻烦叫做"状态丢失"。AI在完成任务时需要在不同环境之间跳转——从网页跳到文件编辑器，再跳到代码执行环境。每次跳转就像搬家，如果没有妥善打包，之前收集的证据、生成的中间文件、记录下来的关键信息就可能在搬运过程中散落一地，后续步骤不得不重新来过，甚至直接用错了或漏掉了重要内容。
第三个麻烦叫做"上下文爆炸"。AI处理信息有一个容量上限，就像一辆卡车的载重有上限一样。任务执行的时间越长，积累的对话记录、工具返回的内容、中间结果就越多，最终把卡车压垮——要么AI开始遗忘早期内容，要么直接报错停工。
这三个问题并不是互相独立的，它们会相互叠加：丢失了状态会加剧目标漂移，上下文爆炸又会进一步加速状态丢失。单独修补其中一个，并不能让整个系统稳定运转。这正是OneDayAgent想要系统性解决的问题。
二、OneDayAgent是怎么工作的：一个精密的"任务调度中心"
OneDayAgent的设计逻辑可以用一个工厂流水线的比喻来理解。传统的AI处理任务，就像让一个工人独自完成所有工序，从原材料到成品，中间不休息、不交接、不检查——一旦某个环节出了问题，整条流水线就乱了。OneDayAgent则把这条流水线拆成了几个有明确分工的工位，每个工位做好自己的事，工位之间有规范的交接流程，最后还有专门的质检环节。
整个系统围绕三项核心能力展开。
第一项能力是任务拆解。接收到用户的复杂请求后，系统中有一个专门的"规划员"角色，负责把大任务切成若干个有序的小任务。每个小任务都是一个相对独立、有明确目标的执行单元。比如"帮我改进这份花卉主题PPT"这样的任务，规划员会把它切成"第一步：从维基百科查找花语相关资料并下载配图"和"第二步：按照要求修改PPT文件"这样两个步骤，而不是让AI一口气把所有事情都做完。这样做的好处是，每次AI只需要盯着一个具体目标，不容易"分心"或者遗忘约束。
第二项能力是全局验证与修复。即便每个小任务都完成了，也不代表最终交付物真的满足了用户的原始要求。OneDayAgent在所有小任务结束后，会专门跑一个"检验员"流程，把最终结果和最初的用户需求、每个小任务的答案、以及生成的文件逐一对照检查。如果发现有遗漏或者不一致的地方，系统不会重新从头做一遍，而是针对具体的缺陷进行定点修复，就像汽车下线前的质检发现某个螺丝松了，只需要拧紧那颗螺丝，而不是把整辆车拆掉重装。修复之后还会再检验一次，确认问题真的解决了。
第三项能力是执行记忆管理。这是OneDayAgent应对"上下文爆炸"的核心手段。系统在处理任务的过程中，会对各种信息进行分级压缩处理。网页搜索返回的大段内容会被精简成结构化的摘要片段；长文档会被压缩成有限篇幅的预览；每个小任务结束时，不是把整个执行过程的记录原封不动传给下一个任务，而是只传递"答案摘要"和"生成的文件"这两样最关键的东西。当累积的对话记录接近AI的容量上限时，系统会自动触发一个LLM生成的技术摘要，把早期的交互历史压缩成一段精炼的总结，同时保留系统指令、用户原始任务和最近几轮的详细记录不变。如果情况紧急，还会触发一个兜底的强制裁剪机制，删掉那些信息价值最低的历史片段。
这三项能力并非各自为战。任务拆解创造了天然的"交接节点"，让记忆管理有机会在每次交接时进行精简；全局验证站在最终成果的角度反过来检验前面所有步骤是否真的服务了用户的原始意图。三者组合在一起，构成了一个能够在长时间、多环境、大容量任务中保持稳定运行的执行框架。
在工具层面，OneDayAgent打通了一套覆盖日常任务所需环境的工具接口。网页搜索和页面访问用于从互联网获取信息，Google Scholar和OpenAlex用于查阅学术文献，Python解释器和命令行工具用于执行代码和处理数据，文件读写编辑工具用于操作本地文档，图像分析和图像生成工具用于处理视觉内容。所有这些工具都在同一个"观察-推理-行动"的循环中统一调用，AI不需要为了使用不同工具而切换到不同的工作模式。
三、测试舞台：一道道真实的日常难题
OneDayAgent选择在AgentIF-OneDay这个测试集上接受考验。这个测试集由多家机构联合构建，包含104道覆盖工作、学习和生活场景的真实任务，总共设置了767个细粒度的评分点。每道题都要求AI不只是说说而已，而是要真正交出一份可以检验的"作业"——可能是一份修改好的Excel表格、一个生成的图表、一篇按照特定格式写好的报告，或者一个处理过的演示文稿文件。
测试任务被分成三种类型。第一种叫"开放式工作流执行"，考验AI能不能按照一套明确的多步骤指令完成任务，同时不丢失中间的关键约束条件。第二种叫"隐式指令推断"，考验AI能不能从提供的材料中自行推导出隐含的规则，然后把这些规则应用到新任务上，而不是让用户明说每一个要求。第三种叫"迭代精炼"，考验AI能不能在现有文件的基础上进行修改和扩展，同时保持文件的整体一致性，不破坏已有的部分。
评分方式非常严格：每个评分点都是二元判断（满足/不满足），满足加分，触发违规条款扣分，最终得分被归一化到0到1之间。这意味着AI不能靠"大体上差不多"来蒙混过关，每个细节都会被盯住。
OneDayAgent在这104道题上取得了0.821的综合得分，超越了测试集排行榜上所有其他系统，包括ChatGPT官方的Agent版本（0.626）、Manus（0.645）、Genspark（0.635）、Codex使用GPT-5.5 medium后端（0.664）以及此前排名最高的AutoClaw（0.799）。更值得关注的是，这个领先优势不是靠某一个子类得分特别高撑起来的，而是在所有任务类型、所有领域、所有评分维度上都排在第一位。
四、拆掉一个零件，看看系统会不会散架
研究团队没有满足于拿到好成绩，他们进一步做了一套"拆解实验"，把系统的组件一个个摘掉，看看每个部分到底贡献了多少，以及摘掉之后系统会怎么表现。
实验设置了四种配置。"完整版"保留所有模块；"仅拆解版"去掉验证和修复功能；"仅验证版"去掉任务拆解功能；"裸奔版"同时去掉拆解和验证，只保留最基础的执行能力。注意：记忆管理模块在所有配置中都保留了，因为一旦把它也去掉，任务根本没办法完成，系统会直接因为容量溢出而崩溃。
裸奔版的综合得分是0.771。单独加上任务拆解，得分提升到0.804。单独加上验证修复，得分同样达到0.804。把两者都加上，得分升到0.821。两个模块各自带来大约3.3个百分点的提升，合在一起带来5个百分点的提升，比两者之和略小——这说明两个模块部分地修复了相同的失败案例，它们并不是完全互补的关系。
更有意思的是两个模块的"成本差异"。任务拆解版本平均每道题需要38.1分钟完成，比裸奔版的27.6分钟多了整整10分钟多，工具调用次数也增加了大约60%。验证修复版本则只需要29.7分钟，比裸奔版多出2.2分钟，却能达到和任务拆解完全相同的得分。如果用"每分钟换来多少得分"来衡量效率，验证修复是最划算的选项；如果目标是把得分压到最高而不在乎时间，那就把两个模块都开着。
另外，完整版虽然整体表现最好，但在104道题中，仍然有12道题在裸奔版下得分更高，有13道题在仅拆解版下得分更高，有17道题在仅验证版下得分更高。这个现象说明，开启所有模块能抬高系统的整体上限，但并不是每道题都能从额外的模块中受益，有时候简单反而更快更好。
五、系统在实际运行时是什么样子的
除了得分数字，研究团队还详细分析了系统在真实运行中的行为模式，这些细节让人对OneDayAgent的实际表现有了更具体的感知。
在任务拆解深度方面，104道题中，只有16道题被当作单一步骤直接执行，绝大多数任务都被拆成了2到4个子任务。拆解得越深，执行成本越高：只有1个子任务的题目平均需要20.6分钟、17次工具调用，而拆成5个子任务的题目则需要117.2分钟、156次工具调用。这个规律说明任务越复杂、系统自动生成的子任务越多，同时也反映出拆解深度和任务难度之间有着直观的对应关系。
在验证与修复流程方面，104道题中有95道在第一次验证时就通过了，9道题进入了修复流程，其中6道在修复后成功，3道最终仍然失败。失败后需要修复的任务集中出现在几个特定场景：迭代精炼类任务、学习领域任务、以及任务本身预计耗时较长的场景。这个分布说明验证修复机制不是一个普惠性的得分提升器，而是一个专门针对高难度、高风险任务的保险机制——它能发现并修复一部分最棘手的失败，但不是万能的。
在上下文压力方面，104道题中有35道触发了自动压缩机制，压力最大的一道题在压缩前后累计处理了约35万个词符（token）的上下文内容。但关键的发现是：触发压缩的次数和最终得分之间几乎没有相关性，相关系数接近于零。这意味着压缩机制在保持任务质量的同时有效地控制了容量压力，而不是以牺牲质量为代价来续命。
六、换一个大脑，框架还能用吗
OneDayAgent的一个重要设计目标是"通用性"——同一套框架应该能配合不同的AI后端使用，而不是和某一个特定模型深度绑定。为了验证这一点，研究团队用五个不同来源、不同规模的模型分别跑了完整的104道题测试。
这五个后端模型分别来自三个不同的公司：智谱的GLM-5.2（参数量744B）、谷歌的Gemini-3.1-Pro-Preview（参数量未公开）、阿里巴巴的Qwen3.5-397B-A17B（有效参数约17B）、Qwen3.6-27B（27B参数）、以及Qwen3.5-9B（9B参数）。五个模型的综合得分分别是0.821、0.743、0.708、0.613和0.624。
所有五个后端都能把104道题全部跑完，没有因为不兼容框架而出现崩溃或者大面积失败，这本身就验证了框架的通用性。得分从最低的0.613到最高的0.821，跨度不小，说明后端能力对最终表现有显著影响，但这种影响是在同一个框架内的能力差异，而非框架本身的适配失败。
在规模与能力的关系上，整体趋势是模型越大表现越好——从Qwen3.5-9B到Qwen3.5-397B-A17B，得分确实随着规模增大而提升。但这个趋势并不是铁律：Qwen3.6-27B（27B参数）的得分反而低于Qwen3.5-9B（9B参数），这说明参数量不是决定一切的，模型的训练方式、指令跟随能力、工具使用能力都在发挥作用。Gemini-3.1-Pro-Preview据推测参数量超过1万亿，但得分仍然低于GLM-5.2，这进一步印证了"参数规模是个参考维度，但不是唯一维度"的结论。
五个后端在相同框架下表现出了截然不同的执行风格。GLM-5.2得分最高，但代价是最高的执行成本——平均每道题53.6分钟、51.6次工具调用、585.7KB的上下文数据。Gemini-3.1-Pro-Preview则走了一条精简路线，平均只需21.4分钟、18.7次工具调用、118.1KB上下文，用更少的资源换来了第二高的得分。Qwen3.6-27B则触发了最高的修复率，56.7%的任务在第一次验证后需要进入修复流程，这说明这个模型更容易在执行阶段出现遗漏，需要修复机制来弥补。这些差异表明，同一套框架在不同后端手中会自然演化出不同的执行风格，而不是强制所有后端走同一条路。
七、一个真实案例：PPT改到崩了又救活
研究团队在论文中展示了一个具体的执行案例，这个案例很好地体现了OneDayAgent的设计逻辑在实战中如何发挥作用。
用户的任务是改进一份"花语"主题的PPT：基于维基百科更新起源内容，用表格对比东西方对花卉的不同解读，改写第八张幻灯片，从Pexels图库插入一张花卉图片，删除第九张幻灯片，并修改最后的结论。这是一个典型的多步骤、涉及网页查找和文件编辑的混合任务。
系统把任务拆成两个子任务。第一个子任务：查找维基百科上关于花语的内容，并找到一张Pexels上的玫瑰图片，把所有素材保存下来备用。这个子任务顺利完成，用了20次工具调用，输出了研究笔记文件、内容JSON文件和图片文件。第二个子任务：把第一步收集到的素材应用到PPT文件上，完成所有修改。然而这个子任务失败了——只调用了1次工具，返回了一个文件描述符错误（一种底层的文件操作错误），没有产出任何文件。
综合模块在汇总两个子任务的结果时，诚实地标记了这个失败：第一步成功，第二步失败，最终交付物缺失。验证模块随后确认：核心交付物——修改后的PPT文件——根本没有被生成，判定任务未完成。
进入修复流程后，系统根据验证模块给出的具体缺陷描述，重新运行了12次工具调用，用python-pptx库（一个专门处理PPT文件的Python工具）从零完成了所有修改，生成了一个13MB的PPT文件。第二次验证确认：六项修改要求全部到位——第二张幻灯片的起源内容已被替换为来自维基百科的花语学文字，包括奥斯曼帝国根源、玛丽·沃特利·蒙塔古（1718年）、哈默-普格斯塔尔（1809年）和夏洛特·德拉图尔（1819年）的历史记载；第四张幻灯片右上角插入了从Pexels获取的玫瑰图片（文件体积13MB可印证图片确实存在）；其余修改也均已到位。任务最终通过。
这个案例展示了OneDayAgent在遭遇执行失败时的处置逻辑：不是掩盖问题、不是重头再来，而是精确定位问题、定点修复，并在修复后重新验收。
说到底，OneDayAgent解决的是一个在AI领域长期被忽视的实际问题：不是如何让AI变得更聪明，而是如何让AI在执行复杂、漫长、跨环境的任务时不掉链子。浙江大学与蚂蚁集团的团队用三个相互咬合的机制——任务拆解、记忆管理、验证修复——构建了一套让AI能够"善始善终"地完成日常复杂任务的执行框架。
对普通用户而言，这项研究的意义在于：AI助手未来能够更可靠地处理那些横跨多个步骤、涉及多种工具的真实任务，而不只是在简单问答上表现出色。不过研究团队自己也坦承，目前的测试仅限于一个特定的评测集，是否适用于更广泛的场景还需要进一步验证；此外，系统目前在没有沙箱隔离的环境下运行，存在一定的安全风险，这是未来版本需要解决的工程问题。
后续还有不少值得思考的方向：不同任务是否应该动态选择最合适的模块组合，而不是一律开启全部功能？验证模块本身的准确性如何保证？在资源有限的设备上，这套框架能否以更轻量的方式运行？这些问题留给了未来的研究者去探索。对想深入了解技术细节的读者，可以通过arXiv编号2608.05013获取原论文，代码和运行轨迹也已公开在论文提到的代码仓库和数据集平台上。
Q&A
Q1：OneDayAgent和普通AI助手有什么本质区别？
A：普通AI助手擅长单轮问答，一旦任务涉及多个步骤或多种环境就容易出错。OneDayAgent的核心差异在于它有三套专门的保障机制：自动把复杂任务切成有序子任务、在执行过程中压缩和传递关键状态信息、以及在任务完成后对照原始需求做全局检验和定点修复。这三个机制组合起来，让它能完成普通AI助手会"掉链子"的长流程任务。
Q2：OneDayAgent换不同AI模型还能用吗？
A：可以。研究团队用五个来自不同公司、不同规模的模型分别测试了同一套框架，所有模型都能正常运行，得分从0.613到0.821不等。框架本身不依赖特定模型，但不同模型在框架内会产生不同的执行风格，比如有的模型更倾向于多次调用工具、有的则更精简，这些差异会影响最终得分，但不影响框架的基本可用性。
Q3：AgentIF-OneDay测试集是什么，0.821的得分意味着什么？
A：AgentIF-OneDay是一个评测AI处理日常复杂任务能力的标准测试集，包含104道需要交付真实文件或数据的任务，共设767个细粒度评分点，覆盖工作、学习和生活场景。0.821的得分是该测试集目前公开记录的最高分，超过了ChatGPT官方Agent版本的0.626、此前最高的AutoClaw的0.799等系统。评分标准较严格，每个细节都会被逐项核查。