2026/9/4 11:51:19
FEATURED · 精选文章 
先抛一个问题如果你让一个大模型去完成“把这个项目的文档体验优化一下”这种目标会发生什么大概率是模型先追问你一堆问题再给你一份看起来正确、但几乎不可执行的行动计划。如果你让它自己定目标、自己造任务、自己练习、自己总结技能它又会陷入自说自话越做越偏。大模型应用真正卡脖子的地方已经不是单轮推理能力而是它能不能为一个模糊目标负责把宽泛的意图拆成可验证的子目标再通过一轮轮试错沉淀出可复用的能力。Aspire 这个研究命题问的正是这件事。它的标题很直接Can Models Self-Evolve from Vague Goals?直译过来就是“模型能从模糊目标中自我进化吗”这个问题看起来偏学术但和每个正在做 Agent、做自动化、做复杂任务系统的人都有关系。因为它指向的是下一代智能体最核心的能力面对没有标准答案的目标自己生成训练信号自己找到解决方案并把经验沉淀下来。这篇文章不会假装复述 Aspire 论文的每一个细节而是把这条研究路线拆开讲清楚模糊目标为什么难自我进化为什么不是简单加一个反思 prompt一个可落地的“模糊目标自进化”闭环应该由哪些环节组成。最后我会给出一套最小原型的代码骨架让不搞科研的工程师也能在自己的项目里验证这类思路。1. 这篇文章真正要回答的问题先说判断自进化的核心不是让模型“自己反思”而是让模型在缺乏外部监督信号时自己构建一套可验证的学习循环。如果有一天大模型真的能自主进化它的起点一定不是精确指令而是模糊目标。原因很朴素——现实世界里的任务绝大多数都是模糊的。“写一份月度运营报告”“优化搜索相关性”“让用户更容易上手产品”这些目标都没有唯一标准答案。真要做起来人脑会先把目标澄清成范围、约束、交付物和验收方法再去找信息、搭建方案、验证效果。今天的大模型和 Agent 框架在这里明显不足它们擅长在用户已经把流程拆好、指令写明确时做执行却不擅长自己承担“从模糊到清晰”的那部分认知工作。所以这篇研究命题真正在挑战的是如果给模型一个模糊目标不告诉它具体怎么做模型能否自动澄清目标补充必要的约束和边界 2.3. 自己分解出可执行的子任务生成用于练习的输入场景在无人工标注的情况下获得反馈把成功的经验抽象成技能沉淀到长期记忆里在下一次面对相似目标时直接调用已有技能。换句话说它把“模型会做题”升级成了“模型会自己出题、自己判卷、自己整理错题集”。这已经是自主智能体研究的核心配方。这篇文章最想让你带走的是两件事一是建立一套分析“模型自我进化”的概念框架避免一听到 Self-Evolve 就觉得是玄学二是拥有一个可以立刻动手的最小实验方案真正理解这类系统在工程上需要面对哪些坑。2. 概念拆解Vague Goal、Self-Evolve 与 Aspire 到底在说什么2.1 模糊目标不是“写得不清楚的 Prompt”很多讨论把模糊目标等同于一个质量很差的 Prompt这是最常见的误解。Prompt 不清晰是表达问题而 Vague Goal 是任务本质问题。一个模糊目标通常有三个特征边界不明确不知道做到什么程度算完成。评价不唯一不同人来做路径和结果可能差异很大。探索空间大目标本身没有给出任何可执行的步骤提示。典型的例子是“提升 API 文档体验”。这里的难点不在语法而在于系统需要自己定义什么叫“体验好”是加载更快是示例更多是排版更清晰还是覆盖更完整这些含义在不同产品阶段权重不同。模糊目标里天然隐藏着多种可能的选题模型先要做的是“定义问题”而不是“回答问题”。对于当前 RAG 架构或基于大模型的 Agent 而言系统会把模糊目标当成普通指令处理最常见结果就是模型直接生成一个宽泛的方案文档看起来逻辑完整实际上没有任何一步能被程序自动验证。这也是为什么很多 Agent 项目做到后面会感觉“能聊天、不能干活”——它缺少逼迫自己做出可验证产物的机制。2.2 Self-Evolve从自我改进到自我进化大模型领域的自我改进并不新鲜。Self-Instruct、Self-Refine、Self-Rewarding 这些方法都已经在“模型生成内容后再用模型自己给出的反馈去优化”这条路上走了很远。但注意这类方法大多有一个隐含前提任务的评分标准仍然来自人类设定的模板或清晰偏好。Self-Evolve 的关键差异在于进化的游戏规则也要由系统自己探索。它的理论原型可以追溯到处在封闭规则空间里的自我对弈AlphaGo 类系统内部包含清晰的“胜负”信号所以能通过左右互搏持续提升。可一旦规则不封闭比如目标是“把搜索体验做好”就不存在一个天然裁判能告诉模型当前这次尝试是好是坏。于是模型的自我进化必须同时解决两个问题如何在没有裁判时定义好坏以及如何把“这次成功”变成“下次也能成功”。Aspire 的研究视角正是把这两个问题结合到同一个循环里。从命名看Aspire 强调“志向”或“渴望”模型需要先对一个模糊目标产生执行意愿和路径想象再启动训练循环。这个说法比“自我改进”更贴合目标设定阶段的主动性。3. 从模糊目标到技能沉淀Aspire 式闭环如何运转如果要把一个模糊目标变成自我进化的原料研究问题会自然拆成四个环节。这四个环节并不是 Aspire 独有的而是这类系统都必须面对的公共骨架。3.1 意图澄清与目标框架化系统拿到“让文档更好用”这类目标第一件事不是动手而是把模糊目标变成一系列假设。这些假设包括当前文档最可能的痛点是什么目标用户可以按什么维度细分哪些数据能反映文档体验这一步看似只是多思考一圈其实是整个闭环里最关键的部分。因为后续所有自动生成的练习任务、评价指标和技能沉淀都受这个初始假设影响。如果目标框架化做得不好系统可能在一个错误的理解上越优化越远。这也是自进化系统最危险的地方它不是不会学习而是可能很有信心地学错。3.2 自生成练习任务传统机器学习需要数据集而自进化系统需要自己构造训练环境。当目标被澄清成一组假设后系统要生成多个具体的练习场景。例如假设“开发者找不到 API 的请求示例”那就可以自动构造一个练习场景从某段 API 文档中生成代码示例并让另一个程序去执行它。这类自生成任务的价值在于提供了“可执行密度”把“让文档更好用”变成一句句可以被跑起来验证的断言。比如“示例代码能通过编译”“教程步骤在干净环境能复现”“错误码解释中能查到对应数字”。没有这些可执行断言系统对改进与否是无感知的。3.3 执行、反馈与迭代生成练习任务后系统用自己的策略去尝试并把结果交给一个反馈模块。反馈模块可以是程序运行测试也可以是调用另一个模型做评价现实系统通常两者结合能用代码验证的用代码不能用代码验证的让模型给结构化打分。从这里能看出一个核心原则自进化系统的可靠性上限取决于反馈模块的可靠性。如果反馈是大模型生成的自由文本系统就很难稳定优化如果反馈是一组合法的布尔断言系统就有了稳定学习的锚点。Aspire 这类研究之所以愿意探索模糊目标本质上是在扩大“可反馈”的边界。3.4 技能沉淀与复用一次成功的尝试如果不被沉淀下次面对相似目标时模型还得从头开始。自进化系统区别于普通强化学习或在线学习的一点就是它会把成功过程抽象成可复用技能写入一个独立于模型参数的技能库中。技能并不是一段简单的答案而是“在什么类型的目标下、按什么步骤、用哪些验证方式、可以复用哪段经验”的结构化记录。从工程角度看这等于一套自动成长的 RAG 知识库从研究角度看这等于让模型拥有简化的外部工作记忆。实现方式上它不一定要微调模型权重也可以表现为检索增强的 Prompt 组件。4. 为什么难模糊目标自进化的四个核心挑战即便闭环拆清楚了真实工程里仍存在几个难以绕过的问题。第一反馈信号缺失。在 AlphaGo 场景里赢就是赢输就是输。但在“优化文档体验”“增加用户黏性”这样的目标下没有天然的奖惩信号。系统必须在每一步自己构造局部反馈而局部反馈与全局目标之间往往存在偏差。比如系统可能发现“增加更多示例代码”能通过当前自建测试但在真实用户场景里文档速度变慢反而伤害体验。第二探索与利用的矛盾。如果系统每次都复用已经成功的技能它会在小范围里表现稳定但很难发现更好的解法。如果它不断尝试新路径成本会飙升结果可能长期不稳定。模糊目标空间巨大用随机采样的方式探索效率极低系统需要主动选择“哪些新场景最值得尝试”。第三错误固化。自进化系统每迭代一轮都可能把上一轮的错误理解带进下一步。模型对自己生成的评价标准往往缺乏怀疑能力一旦某个错误做法被写进技能库并长期复用纠正成本会非常高。这不是理论风险而是自进化系统在实际运行中最容易被观察到的退化模式。第四评估问题。如果目标是模糊的系统如何知道“它真的变好了”研究者最终只能用一些下游任务或人类评审来验证。但验证一旦依赖人类就失去了自动进化的意义。所以当前这类系统都处在“半自动进化”阶段人类会定期检查技能库质量、调整评价标准。这四个挑战决定了 Aspire 这类研究很难给出一个“全自动、无限进化”的答案。更实际的目标是在人类划定的安全边界内让模型自主完成一部分目标澄清、任务生成和经验沉淀动作。5. Aspire 与已有 AI 技术路线的边界和关系把 Aspire 放进当前技术版图里对比更容易理解它的位置。技术路线目标来源反馈来源沉淀方式适用场景传统监督微调人类标注人类标注模型权重更新单一能力、数据充足RLHF / DPO人类偏好人类排序/打分权重更新让模型输出更符合人类偏好Self-Instruct种子指令模型自评或人工规则数据扩充扩充指令数据、减少人工标注Self-Refine明确任务模型反馈生成器多轮上下文内修正文本润色、单轮改进RAG / 工具调用用户当前问题工具真实返回外部数据库/工具结果知识问答、操作真实系统Aspire 类自进化模糊高目标自建断言 模型评价外部技能库 权重更新长期自主系统、复杂目标拆解从表格能看出Aspire 类路线比 Self-Instruct、Self-Refine 更强调“目标模糊性”和“进化的可持续性”。它同时吸收了强化学习中“试错”的思想和 RAG 中“外部知识沉淀”的做法却不等于其中任何一种。现在很多 Agent 框架其实都走到了 Aspire 想解决的路口框架能调用工具、能读文档、能多步规划但规划完成后没有自动反馈机制。Agent 做一次是碰运气做一百次也无法稳定进步。Aspire 对工程界的启示是没有反馈闭环的编排只是流程自动化带着技能沉淀的尝试才叫进化。6. 最小复现思路搭一个可验证的模糊目标自进化原型概念讨论容易停在哲学层面。接下来设计一个可以跑通的最小闭环目标是在本地验证“一个模糊目标能否被模型拆成可验证的子目标并通过自动练习沉淀技能”。6.1 原型目标与边界为了方便演示我们把模糊目标限定在一个适合自动验证的场景里“让我用某个公共 API 时不再需要反复看文档。”这不是一个完全开放的目标但足够模糊它可能是缺少代码示例、缺少参数枚举、缺少错误码解释也可能是文档本身太分散。给定这个目标系统需要定义问题、生成练习场景、尝试解决并验证最后沉淀“通用 API 文档增强”技能。为了让实验不过度复杂原型只探索其中一条路径把目标澄清为“为每个 API 端点生成一个可执行的调用示例脚本”。这个示例脚本能不能运行由真实 API 或 mock 服务来验证。由此我们就能构建一个自动评分的循环。需要说明的是这是一个教学原型不是完整论文实现。重点是通过它理解各模块职责以及模型反馈与真实执行之间的配合。6.2 环境准备本原型不依赖任何特殊框架只需要满足以下条件Python 3.9 以上环境可以调用一个 LLM 服务OpenAI 兼容接口、本地 vLLM、或国内云厂商的模型服务都可以准备一个 mock API 服务或使用任意一个地址稳定的公共测试 API需要有基础的 json、subprocess、pathlib 库。版本细节以实际项目为准。因为大模型服务商的接口经常变化下面代码里把调用客户端的部分放在单独模块方便你替换。7. 关键代码实现与效果验证7.1 辅助模块封装先写一个通用的ask_llm函数把模型调用隔离出来。这样后面每一步都只关注业务逻辑。# 文件路径aspire_demo/common.py import json from typing import Any def ask_llm(system_prompt: str, user_prompt: str, json_mode: bool True) - Any: 统一的大模型调用入口。 实际使用中请替换为你的模型客户端例如 from openai import OpenAI client OpenAI(api_key..., base_url...) 返回 JSON 对象时建议让模型只输出 JSON并用 json.loads 解析。 # 伪代码示意 # response client.chat.completions.create( # modelyour-model, # messages[ # {role: system, content: system_prompt}, # {role: user, content: user_prompt}, # ], # temperature0.7, # ) # content response.choices[0].message.content # return json.loads(content) if json_mode else content raise NotImplementedError(请将 ask_llm 替换为你实际使用的模型客户端)重点说明自进化系统比普通对话更要求“结构化输出”。如果模型不能稳定返回合法 JSON整个闭环都会崩溃。所以工程上建议给模型提供 JSON Schema或者在解析失败时自动重试一次。7.2 第一步模糊目标分解拿到模糊目标后第一步要求模型生成一个澄清计划。这一阶段不追求完美但必须包含“可验证的验收标准”。# 文件路径aspire_demo/decompose.py import json from common import ask_llm SYSTEM_PROMPT 你是一个任务规划器。用户输入的目标是模糊的没有给出具体步骤。 你的职责是 1. 澄清目标补充必要约束 2. 输出可自动验证的验收标准 3. 把目标拆成 3~5 个子目标每个子目标都必须能被代码或脚本验证。 请只输出 JSON。 def decompose_vague_goal(goal: str) - dict: user_prompt f 用户原始目标{goal} 请按以下 JSON 结构输出 {{ clarified_goal: 澄清后的一句话目标, assumptions: [关键假设1, 关键假设2], success_criteria: [可自动验证的验收标准], sub_goals: [ {{id: 1, description: 子目标描述, verification: 如何验证}} ] }} raw ask_llm(SYSTEM_PROMPT, user_prompt, json_modeTrue) return json.loads(json.dumps(raw)) if isinstance(raw, str) else raw if __name__ __main__: goal 让我用某个公共 API 时不再需要反复看文档 plan decompose_vague_goal(goal) print(json.dumps(plan, ensure_asciiFalse, indent2))运行后你会看到模型输出澄清目标、假设与子目标。如果模型给出的验收标准仍然不可执行说明你的 System Prompt 约束还不够强。这个阶段的失败不是模型笨而是你允许它输出模糊文本的空间太大了。在实际闭环里这一步产物会被保存下来作为后续练习场景生成的上下文。它相当于自进化系统的“任务定义文件”。7.3 第二步生成练习场景并执行假如模型澄清出的子目标之一是“为 /users 端点生成一个可执行的调用脚本”接下来就要自动构造练习环境。为了验证脚本真的能运行这里用一个稳定的 mock API 地址作为测试目标。# 文件路径aspire_demo/execute.py import subprocess import tempfile from pathlib import Path from common import ask_llm MOCK_API_BASE https://mock.example.com/api SYSTEM_PROMPT 你是一个代码生成器。你需要根据 API 文档和用户需求生成一段可直接运行的 Python 脚本。 脚本必须包含 main() 函数并在 if __name__ __main__: 中调用。 脚本只能使用标准库和 requests 库。 请只输出 JSON格式为 {script: 完整的 python 代码字符串, explanation: 关键实现说明} def generate_script_for_endpoint(endpoint: str, doc_text: str) - str: user_prompt f API 地址{MOCK_API_BASE}{endpoint} 接口文档摘要 {doc_text} 请生成可直接运行的调用示例脚本。 raw ask_llm(SYSTEM_PROMPT, user_prompt, json_modeTrue) if isinstance(raw, str): raw json.loads(raw) return raw[script] def run_script(script: str) - tuple: 在临时文件中执行生成的脚本返回 (是否成功, 输出文本)。 with tempfile.TemporaryDirectory() as tmp: file_path Path(tmp) / generated_script.py file_path.write_text(script, encodingutf-8) proc subprocess.run( [python, str(file_path)], capture_outputTrue, textTrue, timeout30, ) if proc.returncode 0: return True, proc.stdout return False, proc.stderr if __name__ __main__: endpoint /users doc GET /users 返回用户列表每个用户包含 id, name, email。 script generate_script_for_endpoint(endpoint, doc) ok, output run_script(script) print(执行成功 if ok else 执行失败) print(output)这是一个“真实执行优先”的典型例子。脚本能不能跑通不是模型说了算而是进程返回值说了算。执行错误信息会作为反馈信号传回给模型让它进入下一轮修正。7.4 第三步把成功尝试沉淀为技能当脚本执行成功后下一步是把这次尝试抽象为技能。沉淀的内容不是代码原文而是一个可复用的知识单元遇到什么类型的目标时应该采用什么方案、什么验证方式。# 文件路径aspire_demo/skill_store.py import json from datetime import datetime from pathlib import Path SKILL_STORE Path(skill_library.json) def load_skills() - list: if SKILL_STORE.exists(): return json.loads(SKILL_STORE.read_text(encodingutf-8)) return [] def save_skill(skill: dict) - None: skills load_skills() skills.append(skill) SKILL_STORE.write_text( json.dumps(skills, ensure_asciiFalse, indent2), encodingutf-8, ) def build_skill_from_attempt( original_goal: str, sub_goal: str, endpoint: str, script: str, verification_result: str, ) - dict: return { skill_name: api_doc_code_example_generation, trigger_conditions: [目标是生成 API 调用示例, 目标是提升文档可直接运行率], original_goal: original_goal, sub_goal: sub_goal, endpoint: endpoint, verification_result: verification_result, created_at: datetime.now().isoformat(), code_example: script, } if __name__ __main__: skill build_skill_from_attempt( original_goal让我用某个公共 API 时不再需要反复看文档, sub_goal为 /users 端点生成可执行的调用脚本, endpoint/users, scriptprint(mock example), verification_resulttrue, ) save_skill(skill) print(技能已写入 skill_library.json)这样生成的技能库会越来越大后续系统遇到相似目标时可以按关键字匹配先读取已有技能再决定是否从零生成。从工程视角看这就是一套“自动成长的外部记忆”。7.5 如何验证闭环生效闭环是否生效不是看单次生成是否成功而是观察下面几个状态变化目标澄清质量提升同一类模糊目标连续出现多次后模型给出的 assumptions 是否越来越贴近真实约束子任务完成率提升新生成的脚本能首次直接跑通的比例是否上升技能库命中率新任务到来时系统能从技能库直接获取可用方案而不是每次都从零生成失败记录反馈执行失败时模型下一轮是否基于真实报错修正代码而不是凭空改逻辑。如果缺少真实执行环境只让模型自己评价自己的输出那么整个闭环就退化成“一个模型写、另一个模型打分”的自我安慰循环。这也是为什么最小原型必须引入subprocess这样的真实运行器来验证。8. 常见问题与排查思路在自己跑原型时下面几类问题出现频率最高。问题现象可能原因排查方式解决方案模型输出的 JSON 总是解析失败模型没有遵循结构化输出约束打印原始输出日志在 prompt 中给出严格 JSON Schema或使用模型的 JSON Mode澄清后的目标与用户原意偏差很大初始目标约束信息不足检查assumptions字段加入任务领域说明和禁止事项增加一轮人工复核生成的脚本反复执行失败反馈信息没有真正传给修正环节检查修正 prompt 中是否包含执行的 stdout/stderr把错误信息原样拼进下一轮修正 prompt系统一直生成相似的低质量方案探索机制缺失采样固定观察 temperature 设置和 prompt 模板引入参数变化、多次采样、对结果去重技能库越来越大检索不到有效技能技能没有字段化存储查看 skill JSON 结构加入触发条件、适用场景、验证方式的字段并做索引模型自评分很高但实际执行低分内部评价和外部执行不一致对比模型评价与执行结果增加真实执行判定的权重限制模型自评的使用范围这套排查逻辑的核心只有一句话把外部可验证的信号和模型内部判断分开记录。凡是能用脚本判定的就不要交给模型自由文本评价。当一个系统开始对“它自己是否做得对”产生幻觉时通常不是模型能力不够而是设计者把外部真相丢掉了。9. 工程落地建议与风险边界原型能跑通之后如果想把这类思路带到真实产品或研究项目里下面的建议值得参考。第一给模糊目标设硬约束。模型自主澄清目标并不等于无限授权。工程上要为每个模糊目标预设不可违反的边界条件比如“不允许修改生产环境”“不允许请求超过 N 个外部服务”“生成代码只能在沙箱中执行”。边界条件要写进目标框架化阶段而不是等模型开始行动后再拦截。第二反馈信号要分层设计。第一层是编译、运行、接口调用等硬信号优先级最高第二层是规则断言比如校验返回字段是否齐全第三层才是模型评价通常用于开放性结果打分。真实项目里只有三层信号共同通过才允许沉淀技能。第三技能库必须保留版本和审查入口。自动沉淀的技能一旦进入检索库会影响后续所有任务。建议每个新技能都标记“待人工确认”状态只有在经过抽检后才真正进入可被检索的正式技能池。看起来多了一步人工实际上避免了大范围错误扩散。第四为长期进化定义停止条件。自进化系统不是越跑越省钱恰恰相反长期运行的推理和验证成本可能显著放大。更现实的做法是把这套循环离线跑先对一批历史模糊目标批量学习形成技能库再以只读方式把技能库接入在线服务。在线部分只负责检索和调用不负责持续试错。从风险角度看这套系统的最大隐患是“自主目标漂移”模型在多次迭代后可能把原始模糊目标替换成自己更擅长解决的技术问题。对应措施是每次技能沉淀时都把原始目标、澄清目标、最终成果放在同一条审计记录里任何一步偏差过大都自动终止。10. 总结与后续实践建议现在回到标题里的问题模型能从模糊目标中自我进化吗目前最稳妥的回答是“可以有限地做到但你需要给它配备三类外部系统”——结构化目标澄清机制、真实可执行的任务验证器、受人类审查的技能库。没有这三样自进化只会演变成自欺欺人的文字游戏。读完这篇文章如果只带走一个实践思路那就是先从一个最窄的领域开始尝试。选择一个你能通过代码脚本判定成败的模糊目标让模型自动澄清、自动生成练习任务、自动执行验证再手动检查技能库。跑通这样一个小闭环后你对“Self-Evolve”的理解会远超阅读十篇论文。如果想继续深入了解可以从 Self-Instruct 和 Self-Refine 这两个基础方法读起然后对比着看最近关于推理时自我修正、LLM-as-a-Judge、以及外部验证器设计的论文。你会发现Aspire 这个命题的价值不是提出了一种全新训练算法而是把很多散落的路线统一到了一个驱动力更明确的框架上让模型拥有自己的目标然后为这个目标负起验证和纠错的责任。建议收藏这篇文章尤其是第五节的概念对比表和第八节的排查表等你真正动手搭自进化 Agent 时会回来需要它们的。
从模糊目标到自我进化：Aspire如何推动大模型自主闭环
先抛一个问题如果你让一个大模型去完成“把这个项目的文档体验优化一下”这种目标会发生什么大概率是模型先追问你一堆问题再给你一份看起来正确、但几乎不可执行的行动计划。如果你让它自己定目标、自己造任务、自己练习、自己总结技能它又会陷入自说自话越做越偏。大模型应用真正卡脖子的地方已经不是单轮推理能力而是它能不能为一个模糊目标负责把宽泛的意图拆成可验证的子目标再通过一轮轮试错沉淀出可复用的能力。Aspire 这个研究命题问的正是这件事。它的标题很直接Can Models Self-Evolve from Vague Goals?直译过来就是“模型能从模糊目标中自我进化吗”这个问题看起来偏学术但和每个正在做 Agent、做自动化、做复杂任务系统的人都有关系。因为它指向的是下一代智能体最核心的能力面对没有标准答案的目标自己生成训练信号自己找到解决方案并把经验沉淀下来。这篇文章不会假装复述 Aspire 论文的每一个细节而是把这条研究路线拆开讲清楚模糊目标为什么难自我进化为什么不是简单加一个反思 prompt一个可落地的“模糊目标自进化”闭环应该由哪些环节组成。最后我会给出一套最小原型的代码骨架让不搞科研的工程师也能在自己的项目里验证这类思路。1. 这篇文章真正要回答的问题先说判断自进化的核心不是让模型“自己反思”而是让模型在缺乏外部监督信号时自己构建一套可验证的学习循环。如果有一天大模型真的能自主进化它的起点一定不是精确指令而是模糊目标。原因很朴素——现实世界里的任务绝大多数都是模糊的。“写一份月度运营报告”“优化搜索相关性”“让用户更容易上手产品”这些目标都没有唯一标准答案。真要做起来人脑会先把目标澄清成范围、约束、交付物和验收方法再去找信息、搭建方案、验证效果。今天的大模型和 Agent 框架在这里明显不足它们擅长在用户已经把流程拆好、指令写明确时做执行却不擅长自己承担“从模糊到清晰”的那部分认知工作。所以这篇研究命题真正在挑战的是如果给模型一个模糊目标不告诉它具体怎么做模型能否自动澄清目标补充必要的约束和边界 2.3. 自己分解出可执行的子任务生成用于练习的输入场景在无人工标注的情况下获得反馈把成功的经验抽象成技能沉淀到长期记忆里在下一次面对相似目标时直接调用已有技能。换句话说它把“模型会做题”升级成了“模型会自己出题、自己判卷、自己整理错题集”。这已经是自主智能体研究的核心配方。这篇文章最想让你带走的是两件事一是建立一套分析“模型自我进化”的概念框架避免一听到 Self-Evolve 就觉得是玄学二是拥有一个可以立刻动手的最小实验方案真正理解这类系统在工程上需要面对哪些坑。2. 概念拆解Vague Goal、Self-Evolve 与 Aspire 到底在说什么2.1 模糊目标不是“写得不清楚的 Prompt”很多讨论把模糊目标等同于一个质量很差的 Prompt这是最常见的误解。Prompt 不清晰是表达问题而 Vague Goal 是任务本质问题。一个模糊目标通常有三个特征边界不明确不知道做到什么程度算完成。评价不唯一不同人来做路径和结果可能差异很大。探索空间大目标本身没有给出任何可执行的步骤提示。典型的例子是“提升 API 文档体验”。这里的难点不在语法而在于系统需要自己定义什么叫“体验好”是加载更快是示例更多是排版更清晰还是覆盖更完整这些含义在不同产品阶段权重不同。模糊目标里天然隐藏着多种可能的选题模型先要做的是“定义问题”而不是“回答问题”。对于当前 RAG 架构或基于大模型的 Agent 而言系统会把模糊目标当成普通指令处理最常见结果就是模型直接生成一个宽泛的方案文档看起来逻辑完整实际上没有任何一步能被程序自动验证。这也是为什么很多 Agent 项目做到后面会感觉“能聊天、不能干活”——它缺少逼迫自己做出可验证产物的机制。2.2 Self-Evolve从自我改进到自我进化大模型领域的自我改进并不新鲜。Self-Instruct、Self-Refine、Self-Rewarding 这些方法都已经在“模型生成内容后再用模型自己给出的反馈去优化”这条路上走了很远。但注意这类方法大多有一个隐含前提任务的评分标准仍然来自人类设定的模板或清晰偏好。Self-Evolve 的关键差异在于进化的游戏规则也要由系统自己探索。它的理论原型可以追溯到处在封闭规则空间里的自我对弈AlphaGo 类系统内部包含清晰的“胜负”信号所以能通过左右互搏持续提升。可一旦规则不封闭比如目标是“把搜索体验做好”就不存在一个天然裁判能告诉模型当前这次尝试是好是坏。于是模型的自我进化必须同时解决两个问题如何在没有裁判时定义好坏以及如何把“这次成功”变成“下次也能成功”。Aspire 的研究视角正是把这两个问题结合到同一个循环里。从命名看Aspire 强调“志向”或“渴望”模型需要先对一个模糊目标产生执行意愿和路径想象再启动训练循环。这个说法比“自我改进”更贴合目标设定阶段的主动性。3. 从模糊目标到技能沉淀Aspire 式闭环如何运转如果要把一个模糊目标变成自我进化的原料研究问题会自然拆成四个环节。这四个环节并不是 Aspire 独有的而是这类系统都必须面对的公共骨架。3.1 意图澄清与目标框架化系统拿到“让文档更好用”这类目标第一件事不是动手而是把模糊目标变成一系列假设。这些假设包括当前文档最可能的痛点是什么目标用户可以按什么维度细分哪些数据能反映文档体验这一步看似只是多思考一圈其实是整个闭环里最关键的部分。因为后续所有自动生成的练习任务、评价指标和技能沉淀都受这个初始假设影响。如果目标框架化做得不好系统可能在一个错误的理解上越优化越远。这也是自进化系统最危险的地方它不是不会学习而是可能很有信心地学错。3.2 自生成练习任务传统机器学习需要数据集而自进化系统需要自己构造训练环境。当目标被澄清成一组假设后系统要生成多个具体的练习场景。例如假设“开发者找不到 API 的请求示例”那就可以自动构造一个练习场景从某段 API 文档中生成代码示例并让另一个程序去执行它。这类自生成任务的价值在于提供了“可执行密度”把“让文档更好用”变成一句句可以被跑起来验证的断言。比如“示例代码能通过编译”“教程步骤在干净环境能复现”“错误码解释中能查到对应数字”。没有这些可执行断言系统对改进与否是无感知的。3.3 执行、反馈与迭代生成练习任务后系统用自己的策略去尝试并把结果交给一个反馈模块。反馈模块可以是程序运行测试也可以是调用另一个模型做评价现实系统通常两者结合能用代码验证的用代码不能用代码验证的让模型给结构化打分。从这里能看出一个核心原则自进化系统的可靠性上限取决于反馈模块的可靠性。如果反馈是大模型生成的自由文本系统就很难稳定优化如果反馈是一组合法的布尔断言系统就有了稳定学习的锚点。Aspire 这类研究之所以愿意探索模糊目标本质上是在扩大“可反馈”的边界。3.4 技能沉淀与复用一次成功的尝试如果不被沉淀下次面对相似目标时模型还得从头开始。自进化系统区别于普通强化学习或在线学习的一点就是它会把成功过程抽象成可复用技能写入一个独立于模型参数的技能库中。技能并不是一段简单的答案而是“在什么类型的目标下、按什么步骤、用哪些验证方式、可以复用哪段经验”的结构化记录。从工程角度看这等于一套自动成长的 RAG 知识库从研究角度看这等于让模型拥有简化的外部工作记忆。实现方式上它不一定要微调模型权重也可以表现为检索增强的 Prompt 组件。4. 为什么难模糊目标自进化的四个核心挑战即便闭环拆清楚了真实工程里仍存在几个难以绕过的问题。第一反馈信号缺失。在 AlphaGo 场景里赢就是赢输就是输。但在“优化文档体验”“增加用户黏性”这样的目标下没有天然的奖惩信号。系统必须在每一步自己构造局部反馈而局部反馈与全局目标之间往往存在偏差。比如系统可能发现“增加更多示例代码”能通过当前自建测试但在真实用户场景里文档速度变慢反而伤害体验。第二探索与利用的矛盾。如果系统每次都复用已经成功的技能它会在小范围里表现稳定但很难发现更好的解法。如果它不断尝试新路径成本会飙升结果可能长期不稳定。模糊目标空间巨大用随机采样的方式探索效率极低系统需要主动选择“哪些新场景最值得尝试”。第三错误固化。自进化系统每迭代一轮都可能把上一轮的错误理解带进下一步。模型对自己生成的评价标准往往缺乏怀疑能力一旦某个错误做法被写进技能库并长期复用纠正成本会非常高。这不是理论风险而是自进化系统在实际运行中最容易被观察到的退化模式。第四评估问题。如果目标是模糊的系统如何知道“它真的变好了”研究者最终只能用一些下游任务或人类评审来验证。但验证一旦依赖人类就失去了自动进化的意义。所以当前这类系统都处在“半自动进化”阶段人类会定期检查技能库质量、调整评价标准。这四个挑战决定了 Aspire 这类研究很难给出一个“全自动、无限进化”的答案。更实际的目标是在人类划定的安全边界内让模型自主完成一部分目标澄清、任务生成和经验沉淀动作。5. Aspire 与已有 AI 技术路线的边界和关系把 Aspire 放进当前技术版图里对比更容易理解它的位置。技术路线目标来源反馈来源沉淀方式适用场景传统监督微调人类标注人类标注模型权重更新单一能力、数据充足RLHF / DPO人类偏好人类排序/打分权重更新让模型输出更符合人类偏好Self-Instruct种子指令模型自评或人工规则数据扩充扩充指令数据、减少人工标注Self-Refine明确任务模型反馈生成器多轮上下文内修正文本润色、单轮改进RAG / 工具调用用户当前问题工具真实返回外部数据库/工具结果知识问答、操作真实系统Aspire 类自进化模糊高目标自建断言 模型评价外部技能库 权重更新长期自主系统、复杂目标拆解从表格能看出Aspire 类路线比 Self-Instruct、Self-Refine 更强调“目标模糊性”和“进化的可持续性”。它同时吸收了强化学习中“试错”的思想和 RAG 中“外部知识沉淀”的做法却不等于其中任何一种。现在很多 Agent 框架其实都走到了 Aspire 想解决的路口框架能调用工具、能读文档、能多步规划但规划完成后没有自动反馈机制。Agent 做一次是碰运气做一百次也无法稳定进步。Aspire 对工程界的启示是没有反馈闭环的编排只是流程自动化带着技能沉淀的尝试才叫进化。6. 最小复现思路搭一个可验证的模糊目标自进化原型概念讨论容易停在哲学层面。接下来设计一个可以跑通的最小闭环目标是在本地验证“一个模糊目标能否被模型拆成可验证的子目标并通过自动练习沉淀技能”。6.1 原型目标与边界为了方便演示我们把模糊目标限定在一个适合自动验证的场景里“让我用某个公共 API 时不再需要反复看文档。”这不是一个完全开放的目标但足够模糊它可能是缺少代码示例、缺少参数枚举、缺少错误码解释也可能是文档本身太分散。给定这个目标系统需要定义问题、生成练习场景、尝试解决并验证最后沉淀“通用 API 文档增强”技能。为了让实验不过度复杂原型只探索其中一条路径把目标澄清为“为每个 API 端点生成一个可执行的调用示例脚本”。这个示例脚本能不能运行由真实 API 或 mock 服务来验证。由此我们就能构建一个自动评分的循环。需要说明的是这是一个教学原型不是完整论文实现。重点是通过它理解各模块职责以及模型反馈与真实执行之间的配合。6.2 环境准备本原型不依赖任何特殊框架只需要满足以下条件Python 3.9 以上环境可以调用一个 LLM 服务OpenAI 兼容接口、本地 vLLM、或国内云厂商的模型服务都可以准备一个 mock API 服务或使用任意一个地址稳定的公共测试 API需要有基础的 json、subprocess、pathlib 库。版本细节以实际项目为准。因为大模型服务商的接口经常变化下面代码里把调用客户端的部分放在单独模块方便你替换。7. 关键代码实现与效果验证7.1 辅助模块封装先写一个通用的ask_llm函数把模型调用隔离出来。这样后面每一步都只关注业务逻辑。# 文件路径aspire_demo/common.py import json from typing import Any def ask_llm(system_prompt: str, user_prompt: str, json_mode: bool True) - Any: 统一的大模型调用入口。 实际使用中请替换为你的模型客户端例如 from openai import OpenAI client OpenAI(api_key..., base_url...) 返回 JSON 对象时建议让模型只输出 JSON并用 json.loads 解析。 # 伪代码示意 # response client.chat.completions.create( # modelyour-model, # messages[ # {role: system, content: system_prompt}, # {role: user, content: user_prompt}, # ], # temperature0.7, # ) # content response.choices[0].message.content # return json.loads(content) if json_mode else content raise NotImplementedError(请将 ask_llm 替换为你实际使用的模型客户端)重点说明自进化系统比普通对话更要求“结构化输出”。如果模型不能稳定返回合法 JSON整个闭环都会崩溃。所以工程上建议给模型提供 JSON Schema或者在解析失败时自动重试一次。7.2 第一步模糊目标分解拿到模糊目标后第一步要求模型生成一个澄清计划。这一阶段不追求完美但必须包含“可验证的验收标准”。# 文件路径aspire_demo/decompose.py import json from common import ask_llm SYSTEM_PROMPT 你是一个任务规划器。用户输入的目标是模糊的没有给出具体步骤。 你的职责是 1. 澄清目标补充必要约束 2. 输出可自动验证的验收标准 3. 把目标拆成 3~5 个子目标每个子目标都必须能被代码或脚本验证。 请只输出 JSON。 def decompose_vague_goal(goal: str) - dict: user_prompt f 用户原始目标{goal} 请按以下 JSON 结构输出 {{ clarified_goal: 澄清后的一句话目标, assumptions: [关键假设1, 关键假设2], success_criteria: [可自动验证的验收标准], sub_goals: [ {{id: 1, description: 子目标描述, verification: 如何验证}} ] }} raw ask_llm(SYSTEM_PROMPT, user_prompt, json_modeTrue) return json.loads(json.dumps(raw)) if isinstance(raw, str) else raw if __name__ __main__: goal 让我用某个公共 API 时不再需要反复看文档 plan decompose_vague_goal(goal) print(json.dumps(plan, ensure_asciiFalse, indent2))运行后你会看到模型输出澄清目标、假设与子目标。如果模型给出的验收标准仍然不可执行说明你的 System Prompt 约束还不够强。这个阶段的失败不是模型笨而是你允许它输出模糊文本的空间太大了。在实际闭环里这一步产物会被保存下来作为后续练习场景生成的上下文。它相当于自进化系统的“任务定义文件”。7.3 第二步生成练习场景并执行假如模型澄清出的子目标之一是“为 /users 端点生成一个可执行的调用脚本”接下来就要自动构造练习环境。为了验证脚本真的能运行这里用一个稳定的 mock API 地址作为测试目标。# 文件路径aspire_demo/execute.py import subprocess import tempfile from pathlib import Path from common import ask_llm MOCK_API_BASE https://mock.example.com/api SYSTEM_PROMPT 你是一个代码生成器。你需要根据 API 文档和用户需求生成一段可直接运行的 Python 脚本。 脚本必须包含 main() 函数并在 if __name__ __main__: 中调用。 脚本只能使用标准库和 requests 库。 请只输出 JSON格式为 {script: 完整的 python 代码字符串, explanation: 关键实现说明} def generate_script_for_endpoint(endpoint: str, doc_text: str) - str: user_prompt f API 地址{MOCK_API_BASE}{endpoint} 接口文档摘要 {doc_text} 请生成可直接运行的调用示例脚本。 raw ask_llm(SYSTEM_PROMPT, user_prompt, json_modeTrue) if isinstance(raw, str): raw json.loads(raw) return raw[script] def run_script(script: str) - tuple: 在临时文件中执行生成的脚本返回 (是否成功, 输出文本)。 with tempfile.TemporaryDirectory() as tmp: file_path Path(tmp) / generated_script.py file_path.write_text(script, encodingutf-8) proc subprocess.run( [python, str(file_path)], capture_outputTrue, textTrue, timeout30, ) if proc.returncode 0: return True, proc.stdout return False, proc.stderr if __name__ __main__: endpoint /users doc GET /users 返回用户列表每个用户包含 id, name, email。 script generate_script_for_endpoint(endpoint, doc) ok, output run_script(script) print(执行成功 if ok else 执行失败) print(output)这是一个“真实执行优先”的典型例子。脚本能不能跑通不是模型说了算而是进程返回值说了算。执行错误信息会作为反馈信号传回给模型让它进入下一轮修正。7.4 第三步把成功尝试沉淀为技能当脚本执行成功后下一步是把这次尝试抽象为技能。沉淀的内容不是代码原文而是一个可复用的知识单元遇到什么类型的目标时应该采用什么方案、什么验证方式。# 文件路径aspire_demo/skill_store.py import json from datetime import datetime from pathlib import Path SKILL_STORE Path(skill_library.json) def load_skills() - list: if SKILL_STORE.exists(): return json.loads(SKILL_STORE.read_text(encodingutf-8)) return [] def save_skill(skill: dict) - None: skills load_skills() skills.append(skill) SKILL_STORE.write_text( json.dumps(skills, ensure_asciiFalse, indent2), encodingutf-8, ) def build_skill_from_attempt( original_goal: str, sub_goal: str, endpoint: str, script: str, verification_result: str, ) - dict: return { skill_name: api_doc_code_example_generation, trigger_conditions: [目标是生成 API 调用示例, 目标是提升文档可直接运行率], original_goal: original_goal, sub_goal: sub_goal, endpoint: endpoint, verification_result: verification_result, created_at: datetime.now().isoformat(), code_example: script, } if __name__ __main__: skill build_skill_from_attempt( original_goal让我用某个公共 API 时不再需要反复看文档, sub_goal为 /users 端点生成可执行的调用脚本, endpoint/users, scriptprint(mock example), verification_resulttrue, ) save_skill(skill) print(技能已写入 skill_library.json)这样生成的技能库会越来越大后续系统遇到相似目标时可以按关键字匹配先读取已有技能再决定是否从零生成。从工程视角看这就是一套“自动成长的外部记忆”。7.5 如何验证闭环生效闭环是否生效不是看单次生成是否成功而是观察下面几个状态变化目标澄清质量提升同一类模糊目标连续出现多次后模型给出的 assumptions 是否越来越贴近真实约束子任务完成率提升新生成的脚本能首次直接跑通的比例是否上升技能库命中率新任务到来时系统能从技能库直接获取可用方案而不是每次都从零生成失败记录反馈执行失败时模型下一轮是否基于真实报错修正代码而不是凭空改逻辑。如果缺少真实执行环境只让模型自己评价自己的输出那么整个闭环就退化成“一个模型写、另一个模型打分”的自我安慰循环。这也是为什么最小原型必须引入subprocess这样的真实运行器来验证。8. 常见问题与排查思路在自己跑原型时下面几类问题出现频率最高。问题现象可能原因排查方式解决方案模型输出的 JSON 总是解析失败模型没有遵循结构化输出约束打印原始输出日志在 prompt 中给出严格 JSON Schema或使用模型的 JSON Mode澄清后的目标与用户原意偏差很大初始目标约束信息不足检查assumptions字段加入任务领域说明和禁止事项增加一轮人工复核生成的脚本反复执行失败反馈信息没有真正传给修正环节检查修正 prompt 中是否包含执行的 stdout/stderr把错误信息原样拼进下一轮修正 prompt系统一直生成相似的低质量方案探索机制缺失采样固定观察 temperature 设置和 prompt 模板引入参数变化、多次采样、对结果去重技能库越来越大检索不到有效技能技能没有字段化存储查看 skill JSON 结构加入触发条件、适用场景、验证方式的字段并做索引模型自评分很高但实际执行低分内部评价和外部执行不一致对比模型评价与执行结果增加真实执行判定的权重限制模型自评的使用范围这套排查逻辑的核心只有一句话把外部可验证的信号和模型内部判断分开记录。凡是能用脚本判定的就不要交给模型自由文本评价。当一个系统开始对“它自己是否做得对”产生幻觉时通常不是模型能力不够而是设计者把外部真相丢掉了。9. 工程落地建议与风险边界原型能跑通之后如果想把这类思路带到真实产品或研究项目里下面的建议值得参考。第一给模糊目标设硬约束。模型自主澄清目标并不等于无限授权。工程上要为每个模糊目标预设不可违反的边界条件比如“不允许修改生产环境”“不允许请求超过 N 个外部服务”“生成代码只能在沙箱中执行”。边界条件要写进目标框架化阶段而不是等模型开始行动后再拦截。第二反馈信号要分层设计。第一层是编译、运行、接口调用等硬信号优先级最高第二层是规则断言比如校验返回字段是否齐全第三层才是模型评价通常用于开放性结果打分。真实项目里只有三层信号共同通过才允许沉淀技能。第三技能库必须保留版本和审查入口。自动沉淀的技能一旦进入检索库会影响后续所有任务。建议每个新技能都标记“待人工确认”状态只有在经过抽检后才真正进入可被检索的正式技能池。看起来多了一步人工实际上避免了大范围错误扩散。第四为长期进化定义停止条件。自进化系统不是越跑越省钱恰恰相反长期运行的推理和验证成本可能显著放大。更现实的做法是把这套循环离线跑先对一批历史模糊目标批量学习形成技能库再以只读方式把技能库接入在线服务。在线部分只负责检索和调用不负责持续试错。从风险角度看这套系统的最大隐患是“自主目标漂移”模型在多次迭代后可能把原始模糊目标替换成自己更擅长解决的技术问题。对应措施是每次技能沉淀时都把原始目标、澄清目标、最终成果放在同一条审计记录里任何一步偏差过大都自动终止。10. 总结与后续实践建议现在回到标题里的问题模型能从模糊目标中自我进化吗目前最稳妥的回答是“可以有限地做到但你需要给它配备三类外部系统”——结构化目标澄清机制、真实可执行的任务验证器、受人类审查的技能库。没有这三样自进化只会演变成自欺欺人的文字游戏。读完这篇文章如果只带走一个实践思路那就是先从一个最窄的领域开始尝试。选择一个你能通过代码脚本判定成败的模糊目标让模型自动澄清、自动生成练习任务、自动执行验证再手动检查技能库。跑通这样一个小闭环后你对“Self-Evolve”的理解会远超阅读十篇论文。如果想继续深入了解可以从 Self-Instruct 和 Self-Refine 这两个基础方法读起然后对比着看最近关于推理时自我修正、LLM-as-a-Judge、以及外部验证器设计的论文。你会发现Aspire 这个命题的价值不是提出了一种全新训练算法而是把很多散落的路线统一到了一个驱动力更明确的框架上让模型拥有自己的目标然后为这个目标负起验证和纠错的责任。建议收藏这篇文章尤其是第五节的概念对比表和第八节的排查表等你真正动手搭自进化 Agent 时会回来需要它们的。 
