最近在一份研究列表里看到一个有点特别的标题Aspire: Can Models Self-Evolve from Vague Goals?第一眼的感觉是这个标题把两个很容易被说成大词的词放在了一起Self-Evolve自我进化和Vague Goals模糊目标。如果是一个没接触过大模型 agent 开发的人可能会觉得这是一个概念玩具但如果你做过真实的 agent 应用大概率会有一种被戳中的感觉。因为我们平时在真实业务里遇到的用户请求几乎都是模糊的——“帮我分析一下数据”“写一个客户运营方案”“调研一下这个方向值不值得做”。模型确实能输出一份看起来像样的东西但问题在于它知道自己在回答什么吗它知道自己答得好不好吗它能从这次模糊请求里学到点什么让下一次处理类似问题变得更好吗很多人可能觉得这不是 AI 的问题而是需求不明确的问题。但换个角度想人的协作系统里老板给下属一个模糊目标是常态而不是异常。下属会通过拆解、试错、反馈、积累经验来逐步逼近目标甚至会在下一次接到类似目标时做得更快。那么模型能不能做同样的事这正是 Aspire 这个标题让我停在原地的原因。我还没拿到它的完整论文和代码也无法声称自己已经复现过这个项目。所以我这篇博客不会假装评测一个我没跑过的系统而是想把这个标题背后真正值得讨论的问题拆开模型到底怎样才能从“模糊目标”出发走向“自我进化”这条路真正卡在哪如果我们要在工程里做类似的系统该从哪一步开始1. 从“模糊目标”到“自我进化”中间隔了不止一个 Prompt1.1 用户需求天然是模糊的精确指令反而是一种特例先做一个很简单的思想实验。你让一个 AI 助手“帮我写一份关于智能客服选购的建议让管理层能看懂。”这句需求不算特别复杂但它仍然非常模糊。什么是“让管理层能看懂”是结论先行还是数据佐证还是对标同行建议范围是什么是 SaaS 产品、开源方案还是自研预算多少这些信息用户没有给而模型也没有追问。在真实使用中绝大多数用户并不会像写 Prompt 竞赛题目那样给出清晰任务。用户只会给出一个方向甚至只是表达一种焦虑“我们客服响应太慢了能不能搞个东西解决一下”对大模型来说这种模糊性会造成一个非常棘手的问题它必须自己决定“任务到底是什么”而且是在没有任何成功标准的情况下。假如它是一个普通对话模型那么只要生成一段语境合适、语气专业、结构清晰的中文文本就已经算完成。大模型的语言能力和任务理解能力会把“模糊”掩盖过去因为它太擅长说出正确但不一定有用的内容了。而当你把任务从“聊一段话”升级成“让 agent 真正去执行一个长期任务”时模糊目标就不再是措辞问题而是一个系统性缺陷。agent 需要一个目标函数需要判断哪些动作有效、哪些无效需要把当下尝试和最终目标联系起来。如果没有这些它就会像没有方向盘的车虽然引擎很强但很难到达目的地。这也是为什么我会觉得Aspire这个标题很有张力。它关心的不是“如何让 prompt 更精确”而是“模型能不能在一个模糊目标面前自己生长出清晰可行的执行计划并在执行过程中不断自我修正”。如果这条路能走通它改变的不只是 agent 的可用性还会改变我们和 AI 协作的基本方式。1.2 “Aspire”这个标题真正值得关注的地方只凭一个标题和几个关键词我不能武断地说 Aspire 具体做了什么。但这类研究通常想做的是同一件事把“完成任务”变成“在完成任务过程中提高能力”。我们可以把场景拆成两层。第一层是单次任务完成。用户给出模糊目标模型发挥推理能力假设目标、生成计划、调用工具、输出结果。这一层现在已经有很多 agent 框架能做到问题在于完成质量参差不齐而且对依赖用户反馈来修正的程度很高。第二层才是 Aspire 这类标题真正指向的地方模型在完成这个模糊目标之后能不能把这一次的经验保留下来变成下一次面对类似目标时可以被调用的能力更往前一步模型能不能在练习过程中给自己生成难度适中的“挑战”然后通过自我评估和外部反馈持续提高处理模糊目标的能力这里有一个容易混淆的地方我们通常说的“自我进化”并不只有一个含义。一种是指模型通过外部反馈调整自己的策略和记忆下一次做得更好主体还是同一个模型权重没有变变的只是上下文里的策略或存储的经验另一种是真正意义上的模型参数自我迭代让模型权重在下一次推理前变得更聪明这套机制在现有架构下成本极高也不太容易稳定实现更常见的是训练阶段的做法。Aspire 标题里用了Self-Evolve它更可能指的是前一种能力模型能够在一个持续运行的循环里根据目标、动作、结果和反馈来调整自己的方向。这是一种策略层面的进化和经验层面的积累而不是“模型一夜之间变强”。但即便如此问题也没有变简单。因为要让“进化”发生最基本的条件不是模型的大小而是需要有一把“尺子”来判断现在比之前更好还是更差。2. 先给“自我进化”泼一盆冷水没有可靠的评价信号进化只是噪声2.1 进化需要选择压力而选择压力必须来自外部或可验证的反馈在生物学里进化不是一个生物自己主动“变好”的过程而是环境提供选择压力让更适应环境的特征留下来。模型也一样。如果让模型自己评价自己的输出好不好它经常会给出乐观但空洞的判断。很多做过类似实验的人可能都有体感一个模型在写开放题时如果让它自己给自己打分它能打 8 分甚至 9 分但用户实际感受可能只有 5 分。这说明一个问题自我评价不是不能用于引导但纯靠模型内部对“好不好”的感受来作为进化信号很容易陷入一种自我循环——它越来越擅长优化自己的语言偏好而不是真正解决外部用户的问题。那么在模糊目标场景里评价信号从哪来这是整个 Aspire 方向的核心问题。一个模糊目标常常没有标准答案。所以系统不能只靠“和目标是否一致”来判断。比如目标是“让管理层看懂智能客服选购建议”模型可以生成一份正确但冗长的报告也可以生成一份简明但有洞察的摘要。这两个可能都是“合理答案”但价值不同。如果评价系统只能区分格式或长度那就无法促使模型往“更有洞察”的方向进化。所以我才反复强调Self-Evolve能成立的前提是把“模糊目标”重新塑造为“至少有一个可验证部分的决策过程”。如果一件事完全不可验证那么任何改进断言都只是叙事不是事实。2.2 可行的信号源工具反馈、环境状态、稀疏人工反馈、更强模型评估在实际工程里我一般会把可用的评价信号分成四类。它们的可靠性从高到低大致是信号类型例子可靠性适用场景工具/环境反馈代码是否编译通过、搜索结果是否返回、接口是否调用成功高工程类、检索类、可执行任务确定性校验器单元测试、断言、规则匹配、数据完整性检查高代码生成、数据处理、有标准答案的任务稀疏人工反馈用户点踩、人工打分、少量人工审核中内容生成、方案设计、开放任务自评/更强模型评估LLM-as-a-judge、模型给自己打分较低没有外部信号时的兜底方案你可以看到越接近真实业务目标的模糊任务越容易依赖低可靠度的信号。这也是为什么“从模糊目标自我进化”很难立刻变成产品级能力。Aspire 如果提出了一套系统它大概率绕不开这个问题它要在模型执行模糊目标的过程中建立某种可验证的进步度量。这个度量可能是任务阶段性的产出比如模型先产出了一个更具体的目标描述再把这个描述交给代码解释器去执行也可能是某种人工反馈的最小化设计比如让用户只需要点“对不对”而不是写长评。没有这套信号谈再多“进化”都很可能变成对长文本输出风格的自我吹捧。2.3 “进化”不是只靠几次 prompt 就能完成的还要警惕一种理解偏差把“模型能根据反馈修改回答”当成自我进化。在 chat 场景中用户说“再写得口语一点”模型改口这不是自我进化这只是遵守指令。真正的进化需要模型能把这次修正转化为一种可复用的策略。比如下次面对另一个用户说“让管理层看懂”它不应该只记住“要口语化”而应该记住“对管理层要先给结论、少写术语、给出对比数据”并且把这个经验放进一个可以反复读取的记忆或策略库中。很多 agent 系统会叫“self-refine”“reflexion”“self-improve”但它们大多是在单条轨迹内部做反思。模型执行了一次任务反思出一条“下次应该怎样做”的提示然后把这条提示塞回自己的上下文里。如果这个系统没有把经验保存到跨任务层那么下次遇到一个全新的模糊目标它仍然要从零开始。Aspire 标题里的Self-Evolve暗示的是一种跨越多次任务的能力积累因此更像是需要一个 Agent 能够访问的经验分层系统而不是只靠对话历史里的某一段反思。单次跑通只能说明这段流程没有断。真正能让模糊目标处理能力逐步变强的是每一次执行后的“有价值信息”被沉淀下来并在下次相似任务中被检索和调用。3. 把 Aspire 式问题落到工程一个系统如果真的想“从模糊目标中成长”需要什么3.1 范式转变从单任务调用走向“目标-执行-反馈-经验”循环如果把标题里的问题当作工程问题来构建那么我们可以先忘掉“进化”这个宏大词把它翻译成一个更具体的架构目标系统能接收模糊目标执行若干步之后产出一个可复用的策略改进或经验更新并在后续类似任务中体现出来。按照这个目标一个 Aspire 式系统至少要包含四层目标澄清层不直接执行模糊目标而是先拆解目标、补充假设把它转化成多个可尝试的子问题。执行与工具层按计划执行步骤尝试调用工具、检索信息、运行检查。评价层尽可能用外部反馈检验每一步并把评价结果结构化。经验沉淀层把成功与失败轨迹总结成可复用策略存入带有版本和有效期控制的经验库。这个架构听起来很像一个复杂 agent 系统但它确实和普通 agent 的区别在于关键价值不在执行器而在经验层。普通 agent 相当于一个能力很强但没有长期记忆的员工。你告诉它今天做什么它能做完但它不会因为今天踩了坑明天自动避开同样的坑。Aspire 式系统则像是给这个员工配了一份可以更新的工作手册每一次模糊任务执行完工作手册会新增或修订几条“遇到类似问题时应该怎么做”的规则。这里可以类比新员工入职。老板给一个新员工说“你去了解一下市场情况看看我们还有没有机会。”新员工很可能懵。他需要做的是多问、找数据、看竞品、和客户聊、写初稿、给老板反馈再根据反馈调整。这个过程不是一个 prompt 能完成的而是一个“目标→试错→反馈→修正→沉淀”的循环。Aspire 想做的就是让模型拥有这个循环。3.2 实现形态示例一个通用循环的伪代码在还没有拿到 Aspire 官方实现前我通常会用下面的结构来理解这类系统。它更像一个通用表达不是某个项目的真实代码def run_with_aspiration(goal, experience_store, tools): # 1. 不让模型直接做最终输出先解析目标 subgoals parse_vague_goal(goal, include_assumptionsTrue) for subgoal in subgoals: # 2. 查询之前解决相似问题用过的策略 relevant_memories retrieve_experience(experience_store, subgoal) # 3. 带着记忆执行一次尝试 result agent_attempt(subgoal, relevant_memories, tools) # 4. 用外部信号或校验器评估结果 feedback evaluate_success(subgoal, result, goal_contextgoal) # 5. 把新的经验更新进经验库 experience_store.upsert( subgoalstr(subgoal), strategysummarize_strategy(result, feedback), scorefeedback.score, timestampnow() ) # 6. 如果发现方向偏了允许回滚或重新定义子目标 if not feedback.is_passing(): subgoals revise_subgoals(subgoal, feedback, goal) return final_answer, subgoals, experience_summary它背后隐含的一个非常关键的设计是模型不是在回答一个模糊问题而是在一个环境里反复尝试并且能够知道“这次尝试成没成”。很多做复杂 agent 的项目都会把 feedback 写成一个函数。有些场景里这个函数是run_tests()有些场景里这个函数是search_success还有些场景里这个函数是一个更强大模型的打分。但无论怎么写都必须有一个函数能判断结果是否符合预期。如果没有它上面的if not feedback.is_passing()就永远不会起到纠偏作用。3.3 落地时最容易被忽略的三个点第一是经验污染和过时。经验库不是越大越好。环境一变以前的经验可能成为误导。比如某个策略在旧接口下能帮助成功但接口已经升级旧策略会让 agent 一直往错的方向尝试。因此经验需要有效期、来源可信度和版本标识。第二是自我生成目标的漂移。如果系统允许模型自己把模糊目标分解成子目标它可能会把目标抽象程度越调越低甚至偷偷把问题改成它更擅长回答的问题。这在开放任务里非常常见。一个系统无法完成“做好产品决策分析”就会自己把目标改成“列出三类产品对比”因为后者更容易写出看起来合理的答案。这不是坏意图而是优化目标带来的捷径。第三是评价成本。不是每个子目标都可以自动化评价。如果一次任务分解成 10 个子目标每个子目标都要人工确认那么这套系统在成本上就无法长期运转。更好的办法是让 80% 的子目标拥有确定性检查器只保留 20% 最关键的模糊判断给人工或更强模型。一个比较现实的判断是自我进化系统适合先从一个能自动检查结果的环境里长出来而不是一开始就扔进完全依赖主观评价的开放领域。4. 如果你也想做类似“从模糊目标出发的自我演进”可以这样开始4.1 先从最小可验证场景切入而不是一上来就做宏大系统如果我现在收到一个需求要做“从模糊目标中自我进化的 agent”我不会一开始就做一个无边界的万能助手。因为开放域的模糊目标连评价都不具备系统永远无法形成一个稳定的进步闭环。我更建议从下面这类场景开始场景是代码仓库用户给一句模糊需求比如“优化这个模块的性能”。系统自己写一个性能测试基准尝试几种优化方案用测试结果判断是否变好并把成功方案记录到经验库。下一次遇到类似需求它会优先检索到“先建基准、再做小步修改”的策略。在这个场景里“性能是否提升”是外部可验证的。目标虽然是模糊的但反馈是清晰的。先在这样的封闭环境里跑通闭环才有能力去处理更开放的任务。如果目标不是代码也可以选择文案优化场景用户说“这段文案能不能更有说服力”。这个目标模糊但系统可以先定义几个代理指标是否有明确的行动召唤、是否在开头突出收益、是否有情绪锚点。代理指标不一定完美但至少比“让模型自己感受一下”要更可执行。4.2 一个可复用的四步设计框架我把这种系统的最小设计周期压缩成四个问题环节关键问题常见产出Clarify模糊目标中哪些部分可以变成可测试子任务子目标列表、验证标准、边界假设Act如何让模型在执行时留下足量轨迹工具调用记录、中间输出、错误日志Verify用什么信号判断子任务是否成功测试用例、环境反馈、人工评分表Consolidate成功策略如何变成可复用经验策略描述、版本号、适用范围、过期时间这套四步框架可以套在很多 agent 系统上。它的核心不是让模型变得更“聪明”而是保证每一步都有一个可以被追踪的记录让系统可以从错误中修正。如果说要挑一层最容易崩我会选 Verify。很多团队能做好用户意图解析能接很多工具但到了“如何验证这次回答是否真的有效”时只能靠“感觉还行”。这会导致整个循环没办法真正更新策略因为模型永远不知道什么是更好的。4.3 当“进化”不发生时先按这套链路排查如果你已经搭了一个类似 Aspire 的系统但发现它在几次任务后完全没有变好不要急着加更多 prompt更不要换更大的模型。我一般会先按下面这个顺序排查先看目标解析。模糊目标是否被拆到了“至少有一个子任务存在外部可测结果”的粒度如果所有子任务仍然模糊系统无法知道自己有没有偏。再看反馈信号。模型在执行后是否真的收到了“哪个动作有效、哪个动作无效”的信息还是只收到了“总体答得不错”这种低信息量反馈然后评价来源。如果评价主要来自模型自评就要警惕虚假进步。可以用更强模型或少量人工标注抽样测试一下自评分数是否和真实质量相关。再看经验库。保存的策略是否互相矛盾检索时是否把过时经验当成铁律有没有办法区分“这次成功可能是运气”和“这次成功是因为策略对”最后看护栏。安全护栏是否过紧导致模型不敢尝试新策略或者护栏过松模型已经做了大量不受控的探索但没人能审计它到底学到了什么这套排查顺序不是我编出来的万能流程而是基于一个朴素观察很多“不进化”的系统根本不是模型能力不足而是它在一个不能提供有效反馈的黑箱里打转。没有反馈就没有改进。4.4 我认为这类工作最应该被警惕的地方和“Aspire”这个方向类似的研究在我看来最有价值的部分不是造出一个“正在自我进化”的幻觉而是它把评价问题、经验积累问题和安全护栏问题提到了台面上。真正的自我进化系统必须能在未知环境里做探索同时又要保证探索不失控。所以我认为至少要加三层护栏日志审计每次尝试、每个策略、每次经验更新都留痕。版本回滚经验库必须像代码库一样管理坏策略可以回滚。人工叫停机制当系统反复失败或在某类任务上出现性能下降允许人工停止自动迭代。这不是不给模型空间而是因为模糊目标本身就允许很多种解释。如果模型在无人监督的情况下把目标的“优化方案”理解成“绕过限制去达成目标”那就非常危险。任何一个做长期自驱系统的工程师都应该在第一天就考虑边界而不是在系统失控之后再补。一个可回滚、可审计、可中途叫停的“自我进化”系统才适合走出实验室。最后回到标题里的那个问题Aspire: Can Models Self-Evolve from Vague Goals?从一个研究者或产品人的角度看这个问题问得很好因为它击中了大模型应用的一个核心痛点模型擅长接受精确指令但在真实世界的模糊目标里经常显得笨拙。但如果要让我给一个判断我会说模型能不能从模糊目标中自我进化目前更关键的瓶颈不在“进化”算法而在于我们能不能把模糊目标重新描述成一个个可以被执行、被验证、被纠错的小目标。目标越清晰反馈越可靠进化才越可能发生。目标越模糊反馈越主观“自我进化”就越像是一种叙事而不是一种能力。Aspire 这个名字本身就很有意思它同时是“渴望”和“向往”。也许这类系统真正需要的不是拥有一个渴望成功的模型而是拥有一个能承认失败并愿意根据外部事实调整方向的循环。这个循环并不容易搭但只要搭出来了哪怕起点只是一个模糊到不能再模糊的句子也值得一试。