你跟AI说帮我搞定今天所有事,它真的做到了

想象一下这个场景：

早上你对AI助手说："帮我准备明天的客户提案。需要查一下客户公司最近的财报，整理成摘要，然后根据我们的产品线做一份匹配方案，做成PPT，最后发邮件给老王确认时间。"

对人类来说，这是一个正常的工作日上午。但对现在的AI来说，这是一个噩梦。

问题不在于AI不够聪明。GPT-5.5能写代码，Claude能做推理，Gemini能看图片。问题在于：当你把一个需要跨越多个工具、持续好几个小时、中间会出错需要回头修的任务交给AI时，它很快就"迷路"了——忘了最初的目标，丢了中间的状态，上下文窗口溢出，最后给你一个半成品。

浙大ZJUNLP团队决定解决这个问题。他们做了一个叫OneDayAgent的系统，让AI真正能"干一整天的活"。

在说OneDayAgent怎么解决之前，先看看现有的AI到底卡在哪。

你让AI做一道数学题，它做得很好。你让它写一段代码，也没问题。但当你让它完成一个"长时程任务"——需要多个步骤、跨多个工具、中间有各种附件和约束条件——它就会遇到三个经典问题：

目标漂移。 任务进行到第5步时，AI已经忘了第1步你说的核心要求是什么。就像一个员工做着做着就走偏了，最后交出来的东西跟你想要的不一样。

状态丢失。 AI在做第3步时用了一个文件，到第7步需要引用这个文件的处理结果，但它已经不记得了。上下文窗口就那么大，前面的信息被挤掉了。

上下文溢出。 一个复杂任务涉及大量中间结果、工具调用记录、文件内容。这些东西累积起来很快就超过了模型的上下文窗口限制。模型要么截断、要么崩溃。

之前的研究分别针对这三个问题提出过解决方案。但关键问题是：没有一个系统能同时处理这三个问题，还能跨不同的模型使用。

OneDayAgent的核心思路是：不要试图让模型本身变得更聪明，而是给模型套上一个"工作框架"——就像给一个聪明但健忘的员工配一个项目管理工具。

这个框架做三件事：

1. 把大任务拆成小任务

当你给出一个开放式请求，OneDayAgent不会让AI一口气做完，而是先把它分解成若干个有边界的子任务。每个子任务有明确的输入、输出和验收标准。

这就像项目管理中的WBS（工作分解结构）。你不说"做提案"，而是拆成"查财报→整理摘要→匹配方案→做PPT→发邮件"五个子任务，每个子任务独立执行、独立验证。

好处是什么？如果第3步出了问题，不需要从头来过，只需要重做第3步。这大幅降低了失败成本。

2. 在上下文压力下保持记忆

这是最巧妙的部分。OneDayAgent不把所有中间结果都塞进上下文窗口，而是维护一个"执行记忆"——只保留当前子任务需要的信息，其余的存到外部。

打个比方：你做PPT时不需要同时打开财报原文、邮件记录、产品手册。你只需要当前步骤用到的信息。OneDayAgent就是这样管理的——它在上下文压力下动态调整保留哪些信息，丢弃哪些，需要时再从外部取回。

这解决了一个根本矛盾：复杂任务需要大量信息，但模型的上下文窗口有限。OneDayAgent通过"按需加载"而不是"全部塞入"来化解这个矛盾。

3. 验证并修复最终成果

子任务全部完成后，OneDayAgent不会直接把结果交给你。它会对最终交付物做一轮验证——检查是否满足最初的要求，是否有遗漏，格式是否正确。如果发现问题，它会自动修复。

这就像员工交作业前自己先检查一遍。听起来简单，但之前的AI agent系统大多没有这一步——它们要么完全依赖模型"一次性做对"，要么需要人工检查。

研究团队建了一个叫AgentIF-OneDay的测试集，包含104个长时程任务。这些任务覆盖工作、学习和生活场景，需要跨环境操作、处理多模态输入。

OneDayAgent配合GLM-5.2后端，拿下了0.821的总分，创下新的SOTA。

但更有意思的是跨模型表现。同一个OneDayAgent框架，不做任何调参，直接换到另外4个不同家族的后端模型上——全部能跑。不同模型跑出来的"执行风格"不同：有的激进，有的保守，有的擅长拆解，有的擅长修复。但框架本身是通用的。

这一点非常重要。它意味着OneDayAgent不是"为某个模型量身定制的"，而是一个通用的"工作框架"——就像一个好的项目管理流程，不依赖于具体哪个员工来执行。

OneDayAgent解决的是AI从"聊天工具"走向"工作工具"的最后一步。

现在的AI已经很会聊天了。你问它问题，它能在几秒内给出答案。但真实世界的工作不是"问答"，而是"项目"——需要规划、执行、检查、修复，跨多个工具，持续很长时间。

之前AI agent的失败，很大程度上不是因为模型不够聪明，而是因为没有"工作框架"。就像一个天才员工如果没有项目管理工具、没有任务看板、没有验收流程，面对复杂项目一样会手忙脚乱。

OneDayAgent证明了一件事：AI agent的核心瓶颈不在模型能力，而在工程框架。 给模型套上合适的工作框架，它就能从"秒回消息"进化到"干一整天的活"。

这跟软件工程的历史如出一辙。早期的程序员靠个人能力硬扛复杂项目，后来有了敏捷开发、CI/CD、代码审查等工程框架，复杂度才被管理住。AI agent正在经历同样的转折点。

企业落地的想象空间

把这个思路放到企业场景里：晶澳的工艺工程师每天要查IEC标准、比对SOP、调取产线数据、生成报告。这些步骤之间有明确的依赖关系，但每个步骤又可能出问题——标准版本更新了、产线数据缺失、报告格式不对。OneDayAgent的"拆解→执行→验证→修复"框架正好匹配这种工作流。

更重要的是跨模型通用性这一点。企业不会绑死在一个模型上——信创要求用国产模型，不同场景可能用不同模型。OneDayAgent证明框架可以跨5个模型不调参通用，这对企业落地来说是极大的降低门槛。

框架比模型重要。 不要等着更强的模型来解决问题。用OneDayAgent的思路——任务拆解、执行记忆、验证修复——给现有模型套上框架，就能大幅提升长时程任务的表现。

通用性是关键指标。 你的agent框架如果只能跑一个模型，那就是过度拟合。真正的工程框架应该能跨模型使用，就像OneDayAgent跨5个模型不调参一样。

验证环节不可省。 很多agent系统只管"执行"不管"验收"。OneDayAgent的自动验证修复机制是最简单但最有效的改进——交付前自己检查一遍，听起来朴素，效果显著。

论文地址：arxiv.org/abs/2608.05013

机构：浙江大学ZJUNLP

状态：Ongoing work

AI能聊天不奇怪，能上班才是真本事。