什么样的数据能让AI智能体真正变聪明？一个ACE透镜下的答案

你有没有想过一个问题：教一个孩子学骑自行车，和教他背乘法口诀表，需要的东西完全不一样。

背乘法口诀表，你只需要一本书、一份练习册。可教骑自行车，你得有一辆真车、一片空地、还得让他真的摔几次跤才能学会平衡。

现在的AI智能体训练，正在经历一场类似的转变。过去我们训练大语言模型,主要是喂给它海量文本,让它学会"接话"。但现在的AI智能体不一样了,它们要调用工具、操作系统、搜索信息、修改文件,要在真实或模拟的世界里"动手做事"。这种训练需要的数据,早就不是简单的一问一答,而是一套完整的"实战演练"。

问题是,这套实战演练的数据该怎么生成?什么样的数据才算好数据?

这正是2026年这篇来自华为和上海交通大学联合团队的论文想要回答的核心问题。论文的标题里有个关键词叫ACE,这不是随便起的名字,而是三个英文单词的缩写:准确性（Accuracy）、复杂性（Complexity）、多样性（divErsity）。这三个词构成了一副透镜,透过它,你能看清楚过去几年里那些五花八门的智能体数据生成方法,到底哪些是真本事,哪些只是花架子。

数据生成为什么这么难

先说说这件事到底难在哪里。

如果只是让AI生成"用户问A,模型答B"这样的单轮对话,难度不算太高。但智能体数据不一样,它要求四样东西同时成立:一个能真实交互的环境,一个在这个环境里合理的任务,一段完整的动手过程,以及一个判断这段过程做得对不对的标准。

这就像你要给厨师出一道考题,不能只写"做一道菜"完事。你得先准备好一个真实的厨房(有炉子、有食材、有刀具),再定一个具体要求(做一道能满足特定人群口味的菜),然后厨师要真的动手炒,最后还得有个评委来尝一尝、打个分。这四件事任何一件出了岔子,整套考题就作废了。厨房里的炉子是坏的,菜谱要求根本做不出来,厨师炒到一半偷懒乱来,评委瞎打分——这四种情况,随便发生一种,数据就是垃圾数据。

论文提出了一个统一的说法,把智能体数据拆成四个部分:环境规范、任务信号、交互实现、验证器。

环境规范*：描述智能体能在其中做事的"世界",比如有哪些工具可以调用、数据库里存了什么、规则是什么。任务信号*：用户想要达成的目标,可能是一句明确指令,也可能是逐渐透露的隐藏意图。交互实现*：智能体实际执行的一连串动作和观察到的反馈。验证器*：判断这次交互算不算成功的标准,可以是一段可执行的测试代码,也可以是一个AI评委的打分。

这套拆解方法有个好处,它能把工具调用、软件工程、网页操作、机器人控制这些看起来完全不搭界的领域,用同一套语言描述出来。就像不管是修车还是做菜,你都可以问"工具够不够、任务清不清楚、过程对不对、结果谁来判"。

数据从哪儿来:两条生成路线

论文把现有的生成方法分成了两大类:正向生成和逆向生成。

正向生成很好理解,就是按照自然的因果顺序来:先搭好环境,再根据环境出题,最后让模型或人去完成任务。这条路线的逻辑跟盖房子一样,先打地基(环境),再画图纸(任务),最后施工(交互)。

这里环境的来源又分了三条支线。第一条是直接从现实世界搬,比如爬取真实的API文档、软件仓库、网站。这条路子的好处是真实可靠,但坏处是文档写得乱七八糟、依赖关系一团糟的情况很常见。第二条是让大模型自己"编"出一套工具和规则,这样做起来快,但编出来的东西有时候悬浮在空中,压根不像真实场景里会出现的工作流。第三条是工程师直接写代码,搭建一个可以真实运行、可以重置状态的程序化环境,这条路最扎实,但成本也最高,得有人专门去写、去测、去维护。

如果不走程序化构建这条路,只靠纯文本描述环境会怎样

答案是环境里那些微妙的状态变化根本没法验证。你没法知道调用一个接口之后,系统内部到底发生了什么变化,只能靠"看起来合理"来判断对错。这就好比你想验证一份菜谱靠不靠谱,却没有真的厨房让你试做,只能盯着文字猜测,这道菜大概率能成功。

逆向生成则反其道而行之,不按"环境→任务→交互"这个顺序走,而是换个起点。

论文里细分了三种逆向思路。第一种是任务优先,先定好想要考察的能力,再反过来搭建能承载这个任务的环境。比如你想训练模型做数学题时学会用代码工具,那就直接把已有的数学题改造成需要调用代码解题的形式。第二种是轨迹优先,先让模型或者探索程序在环境里随便逛,把它实际走出来的、被验证有效的路径记录下来,再倒推出一个匹配这段路径的任务描述。第三种是结构优先,先画一张工具依赖图或者任务蓝图,再按照这张图把具体的对话内容填进去。

这三条逆向路线里,轨迹优先的思路特别有意思。它有点像侦探破案,不是先定好一个案发现场再让人去调查,而是先观察一段真实发生的行为轨迹,再反推出这段行为背后对应的是什么样的委托任务。

如果不做轨迹优先,只靠人工先写任务描述会怎样

论文里提到,这样写出来的任务经常和实际能执行的路径对不上,任务写得挺像那么回事,但真正跑起来的时候,发现环境根本支撑不了这个任务的完成,或者最合理的解决方案跟出题人设想的完全是两码事。轨迹优先解决的正是这个"闭门造车"的问题,先看清楚这条路到底能不能走通,再回头写任务描述,天然就保证了任务的可执行性。不过它也有代价,探索程序能发现的场景是有限的,它没走过的地方,你自然也生成不出对应的任务。

现在你应该能感受到,这篇论文真正的野心不是简单罗列"有哪些生成方法",而是想告诉你,同一套底层逻辑,可以从四个不同的入口进去。这就好比装修房子,你可以先定好整体户型再往里面填家具(正向),也可以先想清楚要过什么样的生活再倒推房子该怎么设计(任务优先),还可以先找一套现成的老房子照着模仿(轨迹优先),或者先画一张详细的施工图再照图施工(结构优先)。

准确性:数据能不能信

现在进入ACE这三个字母里的第一个,也是论文反复强调的重中之重:准确性。

论文有一句话说得很直白:数据的困难程度或者多样性,弥补不了数据本身的错误。

这句话值得单独拿出来说一说。

也就是说,如果一份数据看起来很难、很新颖,但它本身是错的,那这份数据的价值是负的,而不是打了折扣的正的。一道数学题如果连答案本身都是错的,那这道题再难、再新颖,教出来的学生也是学了个寂寞,甚至可能学到错误的解题思路。

准确性到底体现在哪几个层面?论文拆解得很细,分成了环境准确性、任务准确性、交互准确性、验证器准确性四块。

环境准确性,是指工具的接口描述、数据库状态、状态转移规则这些东西内部是不是自洽的。举个例子,如果一个模拟的电商环境里,商品库存的数字前后对不上,那基于这个环境生成的所有任务和交互,从一开始就建立在流沙上。

任务准确性,是指出的这道题在给定的环境里到底能不能做出来。这里论文特别提到了一个容易被忽视的点:很多真实场景里,任务不是一开始就完整说清楚的,而是通过用户一轮一轮的对话逐渐透露出来的。这种情况下,判断任务准不准确,不能只看最开始那句话,还得看后续透露的信息前后是不是逻辑一致。

交互准确性,是这四块里最直接影响训练效果的一块。因为训练模型的时候,模型是直接照着这段交互过程去模仿的,如果这段过程本身包含错误的操作、编造的观察结果,模型学到的就是错的行为模式。

验证器准确性,是判断"这次任务算不算成功"的那把尺子准不准。这一点在强化学习里特别关键,因为验证器直接决定了奖励信号,如果验证器本身有漏洞,比如它只检查了表面结果没检查过程是否合规,那模型很可能学会钻验证器的空子,而不是真正学会解决问题。

论文里提到一个很形象的现象:如果反复针对同一个固定的验证器去优化,模型最终学会的可能是讨好验证器的招数,而不是完成任务本身该有的能力。

这就好比一个学生反复刷同一套模拟题,时间久了他背下的是这套题的答案规律,而不是这门学科真正的知识。如果不引入独立的复核机制,只靠一个固定的验证器反复打磨,你迟早会培养出一个"应试高手"而不是真正解决问题的能力。

那怎么保证准确性?论文总结了四种在生成流程里贯穿始终的做法。

第一种是分层检查,便宜的规则检查放在前面,昂贵的模型判断和人工复核放在后面,这样能先筛掉明显错误,把有限的审查资源留给真正有争议的样本。第二种是约束驱动构建,提前用蓝图或图结构限制生成范围,不让一个不合理的计划污染后续所有轮次。第三种是执行验证,直接把生成的动作放到真实工具或环境里跑一遍,看结果对不对,而不是光凭"看起来合理"就放行。第四种是反馈驱动的修复,发现某个环节失败了,就针对性地重新生成,而不是简单粗暴地整批丢弃。

这四种做法背后其实有一个共同的哲学:验证不是生成流程结束后的一道"质检关卡",而应该贯穿整个生产过程的每一个环节。

复杂性:难度不是越高越好

第二个字母C,代表复杂性。这一part论文的观点特别值得展开,因为它打破了一个大家可能下意识会有的误解:是不是数据越难,训练效果越好?

答案是否定的,而且论文给出了一个很清晰的框架来解释为什么。

论文提出,复杂性不是一个绝对的、放之四海而皆准的数值,而是相对于特定学习者的。同一道题目,对一个能力弱的模型来说可能难如登天,对一个能力强的模型来说可能轻松拿下。复杂性应该用"这道题在给定模型和配置下的失败概率"来衡量,而不是靠题目表面的长度、涉及的工具数量这些"看起来很难"的表面特征。

这一点特别反直觉。很多人下意识觉得,任务链条越长、涉及的步骤越多,难度就越高。但论文明确指出,更多的节点、更多的分支,不一定意味着更难。一条明确摆出来的推理链,反而可能直接把答案暴露出来;一个额外加上去的约束条件,反而可能帮你排除掉大量错误选项,让搜索空间变小了。

真正有用的训练数据,应该落在一个特定的区间里,论文管这个叫"可学习带宽"。

太简单的题目,模型闭着眼睛都能做对,这种数据是冗余的,练一百遍效果跟练一遍差不多。太难的题目,模型无论怎么努力都做不对,这种数据也没什么用,因为它连一次成功的示范都提供不了,模型学不到任何有效的经验。真正有价值的,是那些模型现在做不太好、但通过学习能够逐步掌握的题目,这个区间会随着模型能力的提升而不断往前移动。

这就好比健身房里的杠铃片配重。你要是让一个刚开始健身的新手直接举一百公斤,他连杠铃都举不起来,这次训练对肌肉增长没有任何帮助,反而可能拉伤。可你要是一直让一个已经能举八十公斤的老手只举二十公斤热身重量,他的肌肉早就习惯了这个负荷,再练一百次也不会有明显长进。真正让肌肉持续变强的,是那个让他每次都需要咬牙坚持、但确实能完成的重量区间,而且随着他越来越强壮,这个合适的重量区间也在跟着往上走。

论文里提到了几种具体调节难度的手法。有一种叫"结构化控制",在生成任务之前先构建一张依赖关系图,人为设定需要经过几步、有没有分支、有没有需要同步汇总的节点。还有一种叫"信息控制",故意在最初的请求里隐藏一部分信息,让这些信息需要通过后续对话轮次才能补齐,这样就制造出了"需要澄清、需要追问"的难度。

但这两种手法都有一个前提:被藏起来的信息必须真的能被找回来,加上去的约束必须真的能影响解题过程。

否则,你制造出来的不是有意义的复杂性,而是纯粹的歧义和干扰项。如果一道题故意藏了一条永远也找不到答案的关键线索,这道题不是变难了,而是变得无解了,这种"难"对训练没有任何帮助,反而会让模型学到错误的猜测习惯。

论文还特别提到了一种"失败驱动"的难度校准方法。就是让模型先在一批候选任务上实际跑一遍,统计每道题的真实通过率,只保留那些通过率处在某个目标区间里的题目,而不是靠人工估算这道题"看起来"有多难。这种做法的好处是,它是完全基于模型真实表现来的,不受出题人主观判断的干扰。

多样性:数量不等于覆盖面

第三个字母E,代表多样性。这一part论文提出的洞察同样打破了常识:数据量大,不等于数据多样。

想象一下,你有十万条训练数据,但这十万条里九成八都是在描述同一种场景,只是换了几个人名和数字,这样的数据集从数字上看很庞大,但从有效信息量上看极其贫瘠。

论文里给出的核心判断标准是:多样性不是看你收集了多少个样本,而是看这些样本是不是要求模型做出真正不同的行为。

如果两条数据只是文字表述不一样,但对应的解决思路、动作序列完全相同,那这两条数据在有效意义上是同一条数据。就像一本练习册里出了一百道题,但这一百道题其实全是同一个公式换了不同数字,学生刷完这本册子,并没有学到一百种不同的解题能力,他只是把同一种能力反复练习了一百遍。

论文把多样性拆成了四个层面:环境规范多样性、任务信号多样性、交互实现多样性,还有一个容易被忽略的生成器与来源多样性。

环境规范多样性,不是简单地看你用了多少个工具、多少个应用,而是看这些工具、应用背后,实际的操作前提、产生的效果、暴露的信息路径是不是真的不一样。论文举了个例子,给同一个应用换个权限设置,或者藏起一部分隐藏状态,这种改变带来的行为差异,可能比单纯多加一个新API接口带来的差异要大得多。

任务信号多样性,关注的是任务本身要求达成的目标、涉及的约束条件、用户表达意图的方式是不是覆盖了足够广的范围。这里论文特别提醒,像"澄清、拒绝、部分完成、恢复纠错、成功完成"这些不同的任务结局,应该被当成本质上不同的任务类型来对待,而不是简单地一股脑归到"困难任务"这个大筐里。

交互实现多样性,则关注的是同一个环境、同一个任务,是否存在多条不同但都有效的解决路径。论文强调,这里的区分标准是"行为上是否真的不同",而不是"看起来长得不一样"。两条路径如果都能到达有效的目标状态,那它们展现的是不同的策略;但如果只是模型犹豫、绕了几个弯又走回原路,这种差异只是执行过程中的噪声,不算真正的多样性。

如果只靠增加样本数量,而不去检查这些样本背后行为模式是否重复,会发生什么

论文里引用了几项研究的对比结果:一些采用结构化覆盖策略的方法,在数据预算相同甚至更小的情况下,反而能取得比单纯堆数量更好的效果。这说明真正决定训练效果的,不是数据规模这个数字本身,而是这个数字背后到底覆盖了多少真正不同的场景和策略。

这就好比图书馆藏书量。一个图书馆号称有十万册藏书,听起来很唬人,但如果仔细一查,发现其中八万册都是同一本畅销小说的不同印次和不同封面版本,那这个图书馆实际能给读者提供的知识广度,远不如一个只有两万册但每本书主题都不重样的小型图书馆。衡量图书馆价值的,从来不是书架上摆了多少本书,而是这些书能带你去多少个你从没去过的地方。

复杂性与多样性的博弈

这三个维度之间不是各自独立、互不干扰的,它们之间存在真实的张力,论文用了不小的篇幅讨论这些权衡。

比如复杂性和多样性之间就有矛盾。如果一套生成系统一门心思盯着模型当前做不好的那批题目死磕,短期内确实能提高训练效率,但这样做的代价是,其他领域、其他技能、以及那些相对简单但对巩固基础很重要的题目,覆盖率会跟着下降。反过来,如果生成系统只顾着追求覆盖面广,却不管这些数据是不是已经被模型轻松掌握了,那这种"广"也是没有实际训练价值的广。

准确性和多样性之间同样存在张力。越是想扩大覆盖面、尝试更多新奇的工具组合和场景搭配,出现工具不兼容、目标不可达、状态前后矛盾这类问题的概率就越高。论文的态度很明确:多样性的扩张必须在准确性得到保证的前提下进行,而不能反过来,为了追求新颖就放松对正确性的审查标准。

这三者之间的关系,让人想起团队管理里经常遇到的一个两难。你既要保证团队里每个人做的事情都是对的、没有出错(相当于准确性),又要保证每个人手头的任务难度匹配他现在的能力水平,既不能闲得发慌也不能被压垮(相当于复杂性),同时还得保证团队整体覆盖的业务范围足够广,不能所有人都挤在同一个小领域里内卷(相当于多样性)。这三件事任何一件做过头,都会拖累另外两件,真正优秀的管理不是把某一项做到极致,而是找到三者之间那个动态平衡的支点。

论文最后还提出了几个面向未来的思考方向,其中一个特别值得琢磨,叫作"自我演化的智能体"。

传统的数据生成是一次性的,先造好一批数据,再拿去训练。但自我演化系统的想法是把数据生成变成一个持续的闭环,系统一边观察模型现在哪里做得不好,一边针对这些薄弱环节生成新的练习题,练完之后再看效果,再决定下一步生成什么。这听起来很美好,但论文也指出了一个隐患:如果生成数据的系统、学习数据的模型、判断对错的验证器全都在同一个闭环里互相适应,它们很可能一起犯同一个错误而不自知,就像三个人组成的评审团,如果三个人的判断标准从一开始就是错的,那他们互相打分再多轮,也不会发现问题所在。论文认为,想要打破这种循环里的自我强化,必须引入一些独立于这个闭环之外的、固定不变的检验标准,比如留出一部分从来不参与训练的测试任务,定期拿这些任务来检验模型的真实进步。

写在后面

读完这篇论文,我印象最深的其实不是ACE这个框架本身,而是它反复强调的那句话:准确性是一切的前提,复杂度和多样性都不能拿来弥补数据的错误。

这句话听起来朴素,但实际操作起来非常反直觉。因为在实际的数据工程里,人们太容易被"这份数据看起来很复杂很新颖"这种表象所迷惑,而忽略了去追问它到底对不对。

论文里还有一个细节让我觉得挺有意思,就是关于"环境数量"和"环境质量"的对比。论文提到有研究发现,一小批经过充分验证、可靠性高的环境,效果能超过数量大得多但验证不充分的环境集合。这个发现某种程度上颠覆了"数据规模决定一切"的朴素直觉,数据这件事上,少而精有时候真的能打败多而糙。

这也让我想到一个更远的联想:人类教育里其实一直存在类似的争论,题海战术到底有没有用?这篇论文虽然讨论的是AI训练数据,但它给出的答案某种程度上也回应了这个老问题,如果那些题目本身覆盖的知识点是重复的、难度是不匹配的,做再多遍也提升有限。真正的进步,来自于持续地找到那些既对、又难度适中、又和你已经会的东西不一样的新问题。

这篇论文没有解决的一个问题是,当模型能力已经远远超过人类专家能设计出的任务难度时,谁来判断什么才是"合适的复杂度"?这个问题恐怕不会有简单的答案。

Q&A

Q1：ACE框架是什么？

A：ACE是准确性、复杂性、多样性三个英文单词首字母的缩写,是这篇论文提出的用来分析和指导AI智能体训练数据生成的分析框架,核心观点是准确性是数据能否被使用的前提条件,复杂性和多样性则决定了在准确的数据里应该优先保留哪些、突出哪些。

Q2：为什么说数据难度不是越高越好？

A：因为复杂性是相对于特定学习模型而言的,同一道题对能力弱的模型很难,对能力强的模型可能很简单。真正有用的数据应该落在模型"现在做不好但通过学习能掌握"的区间里,太简单的数据是冗余的,太难的数据模型根本学不会,两者都没有训练价值。

Q3：为什么数据量大不代表数据多样？

A：因为多样性看的是样本背后要求的行为模式是否真的不同,而不是样本数量本身。如果十万条数据只是换了措辞但对应同一种解决思路,这些数据在有效意义上是重复的。论文提到有研究显示,结构覆盖更好的小数据集,效果能超过单纯堆数量的大数据集。