1. 项目概述当AI智能体学会“即兴创作”最近在AI智能体Agent的圈子里一个概念被反复提及Inference-Time Skill Synthesis翻译过来就是“推理时技能合成”。这听起来有点玄乎但如果你玩过一些开放世界游戏比如让角色在从未预设过的场景下组合出全新的动作来解决问题你大概就能理解它的魅力。SkillGen正是这个概念下一个追求“验证”与“可靠”的实践方向。它要解决的不是一个新问题而是一个老难题如何让一个已经训练好的智能体在面对超出其训练数据范围的、全新的、未知的任务时不是简单地“报错”或“胡言乱语”而是能够动态地组合其已有的基础能力合成出一个可行的新技能并且这个合成过程本身是可控、可解释、可验证的。这和我们常说的“微调”或“提示工程”有本质区别。微调是让模型去学习一个新的任务分布需要数据和算力是“离线”的。提示工程是引导模型调用其已有知识但面对真正的新颖组合任务往往力不从心。而SkillGen瞄准的是“推理时”——模型已经部署任务实时到来没有机会重新训练。此时智能体需要像一个经验丰富的工程师手头只有一套标准工具基础技能却要现场设计并制造一个专用工具合成技能来完成特殊订单。这里的核心挑战在于“Verified”已验证意味着合成出的技能不能是“理论上可行”而必须是“实践中可靠”其执行过程或结果需要某种形式的保障或验证。对于从事Agent开发、AI应用落地的朋友来说这直接关系到系统的鲁棒性和泛化能力。想象一个客服Agent它学过处理“退货”和“查询物流”但没学过“因物流延误导致的特殊换货流程”。在Inference-Time Skill Synthesis的理想状态下它应该能自主将“查询物流状态”、“判断是否超时”、“启动换货流程”这几个基础技能按逻辑串联并验证这个串联计划是否满足公司政策如超时天数然后执行。这远比让Agent回答“我不会”或需要人类频繁接管要有价值得多。SkillGen正是试图将这种“即兴创作”能力从一种偶然的涌现现象转变为一种可设计、可验证的系统性能力。2. SkillGen的核心设计思路与架构拆解要理解SkillGen我们不能把它看作一个单一的模型或算法而应视为一套赋予智能体“动态技能组合”能力的架构范式。其核心思想是解构与重组。2.1 技能的定义与表示首先什么是“技能”在SkillGen的语境下技能不是一个模糊的概念而是一个可执行的、封装的、具有明确输入输出规范的功能单元。通常一个技能可以表示为Skill (Name, Description, Preconditions, Effects, Implementation)Name Description技能的名称和自然语言描述用于技能检索和理解。Preconditions执行该技能前世界状态必须满足的条件。例如“发起支付”技能的前提可能是“用户购物车非空”且“用户收货地址已确认”。Effects执行该技能后对世界状态产生的改变。例如“发起支付”的效果是“生成待支付订单”并“用户账户进入扣款流程”。Implementation技能的具体实现。这可以是一段代码如API调用、一个提示词模板、或调用另一个模型/工具。这种形式化的表示是技能合成的基础。它使得技能可以被机器理解和推理而不仅仅是人类阅读的文档。2.2 推理时合成的流程SkillGen的核心流程发生在用户查询到达之后可以分解为以下几个阶段任务解析与技能检索智能体首先解析用户请求将其分解为子目标或关键约束。然后它在技能库中检索可能与每个子目标相关的基础技能。这里的关键是检索的召回率与精度需要利用技能的描述、前提和效果进行语义匹配。技能规划与组合这是合成的核心。智能体需要像一个规划器将检索到的离散技能组合成一个有序的行动序列即计划使得这个序列的总体效果能够满足用户请求的最终目标。这本质上是一个自动规划问题。经典的规划算法如STRIPS、PDDL或基于大语言模型的规划方法都可以在此应用。组合不仅要考虑功能可达性从初始状态通过技能序列能否到达目标状态还要考虑效率、成本等约束。计划验证与可行性分析合成出计划后并非立即执行。SkillGen的“Verified”特性在此体现。系统需要对合成计划进行验证逻辑一致性验证检查计划中每个技能的前提条件是否都能被前序技能的效果满足。避免出现“无米之炊”的情况。约束满足验证检查计划是否满足用户或系统附加的约束如“总耗时不超过5分钟”、“总成本低于100元”。安全与合规性验证检查计划是否触犯安全规则或业务合规条款。这一步可能需要调用规则引擎或策略模型。 只有通过验证的计划才会被认定为“已验证的合成技能”进入执行阶段。技能执行与状态监控执行合成出的技能序列。在执行过程中持续监控世界状态是否与预期一致。如果某个技能执行失败或产生意外效果需要触发重规划或失败处理机制。2.3 架构组件选型考量实现这样一个系统在架构上需要精心选型技能库存储需要一个支持高效语义检索的向量数据库如Milvus, Pinecone来存储技能嵌入同时需要一个关系型或图数据库来存储技能间的逻辑关系如技能A的效果是技能B的前提。规划器对于确定性环境基于符号的规划器如FastDownward效率高、可验证性强。对于复杂、不确定的环境基于大语言模型的规划器如ReAct, Plan-and-Solve灵活性更好但验证难度更大。一个混合架构LLM生成候选计划符号验证器进行检验是当前务实的选择。验证器这是“Verified”的保障。可以是一个轻量级的定理证明器、一个规则引擎如Drools甚至是一个用于预测计划成功率的判别式模型。其复杂度和严格程度需要根据应用场景的风险容忍度来权衡。执行引擎负责按顺序调用技能的实现。它需要具备事务管理、错误回滚和状态快照的能力确保计划执行的原子性和一致性。实操心得技能粒度的权衡技能定义得太粗如“解决客户问题”则失去了合成的意义定义得太细如“读取数据库字段X”则规划空间爆炸验证复杂。一个实用的经验法则是一个技能应对应一个原子性的业务操作或一次确定的模型调用。例如“调用天气API获取某城市气温”是一个好技能“与用户寒暄”可能就不是因为它太模糊。通常我们从现有系统的API或工作流节点开始定义技能这是一个不错的起点。3. 核心细节技能合成中的验证机制实现“Verified”是SkillGen区别于普通规划系统的关键。验证机制确保了合成技能的可靠性而不是“黑盒”生成的、可能出错的指令序列。这里我们深入几种可行的验证实现路径。3.1 基于符号逻辑的形式化验证这是最严格的一种验证方式。它将技能的前提、效果以及世界的初始状态、目标状态都用形式化逻辑语言如一阶逻辑来描述。规划器生成的计划可以被转化为一系列状态变迁定理。验证器的工作就是证明给定初始状态S0执行计划P中的技能序列后得到的状态Sn logically entails逻辑蕴含目标状态G。这可以通过自动定理证明器如Z3, Prover9来完成。优势如果验证通过理论上可以100%保证计划在逻辑上是正确的假设模型对世界的抽象是准确的。劣势对技能和状态的形式化要求极高需要专业的逻辑知识且难以处理现实世界中大量的不确定性和非结构化信息。一个简化示例 假设我们有技能PickUp(obj): 前提At(robot, loc) ∧ At(obj, loc) ∧ HandEmpty(robot)效果Holding(robot, obj) ∧ ¬HandEmpty(robot) ∧ ¬At(obj, loc)技能Place(obj, loc): 前提Holding(robot, obj) ∧ At(robot, loc)效果At(obj, loc) ∧ HandEmpty(robot) ∧ ¬Holding(robot, obj)初始状态At(robot, A) ∧ At(Box, A) ∧ HandEmpty(robot)目标状态At(Box, B)规划器可能合成计划[PickUp(Box, A), Move(A, B), Place(Box, B)]假设有Move技能。验证器需要逐步证明执行这个序列后At(Box, B)为真。3.2 基于模拟的执行前验证对于无法完全形式化的复杂环境如涉及非确定性API调用、自然语言交互一种更实用的方法是在真正执行前在一个“沙盒”或模拟环境中快速运行一遍合成计划。轻量级模拟为每个技能开发一个简化的、确定性的模拟版本。例如“发送邮件”技能的模拟版本只是记录日志而不是真的调用SMTP服务器。验证器在模拟环境中运行计划检查最终模拟状态是否满足目标并记录过程中是否有技能因前提不满足而失败。基于模型的预测使用一个训练好的世界模型来预测执行每个技能后的状态变化。通过前向传播预测计划执行后的最终状态并与目标状态对比。优势能处理更复杂、不确定的场景实现相对简单。劣势验证的正确性依赖于模拟环境或世界模型的保真度。“模拟通过”不等于“实际可行”。3.3 基于运行时监控的断言检查这是一种“边执行边验证”的轻量级方法。它为每个技能的关键点植入“断言”。技能前提断言在执行每个技能前强制检查其前提条件在当前真实世界状态下是否成立。如果不成立立即终止计划并触发异常处理。技能效果断言在执行每个技能后检查其预期的核心效果是否达成。例如调用支付API后断言“订单状态变为已支付”。这可能需要查询数据库或调用验证接口。优势实现简单能快速捕获运行时错误防止错误扩散。劣势这是一种“事后”验证无法在执行前保证整个计划的可行性。它更侧重于保障单个技能的执行可靠性而非整个合成逻辑的正确性。3.4 混合验证策略在实际的SkillGen系统中通常会采用混合策略形成多道防线静态语法与类型检查首先检查合成计划中技能调用的参数类型是否匹配序列是否基本合法如避免连续调用互斥的技能。轻量级逻辑验证使用一个简化的、不完整的逻辑验证器快速排除明显矛盾的规划例如要求同一个物体同时出现在两个地方。沙盒模拟验证对通过前两步的计划在沙盒中运行进行集成测试。运行时断言监控在实际执行时进行断言检查。注意事项验证的成本与收益平衡验证越严格系统可靠性越高但推理延迟也越大可能影响用户体验。在电商推荐场景一次失败的技能合成可能只是导致推荐不精准在金融交易或医疗辅助场景失败可能导致严重损失。必须根据应用场景的风险等级来决定验证机制的深度和广度。一个通用的原则是对于高风险操作必须包含形式化验证或高保真模拟验证对于低风险操作运行时断言可能就足够了。同时可以设计分级验证策略对初步评估风险低的计划采用快速通道风险高的计划走严格验证通道。4. 实操构建一个简易的文本处理SkillGen原型为了让大家有更直观的感受我们抛开复杂的机器人或业务流程用一个相对简单的文本处理场景来演示如何构建一个SkillGen原型。假设我们有一个智能体其核心任务是响应用户对文本的复杂操作请求。它拥有以下基础技能技能A: 提取摘要(Summarize(text, max_length)): 输入一段文本和最大长度输出摘要。技能B: 翻译(Translate(text, target_lang)): 输入文本和目标语言代码如’zh’, ‘en’输出翻译结果。技能C: 情感分析(SentimentAnalysis(text)): 输入文本输出情感极性正面/负面/中性。技能D: 关键词提取(ExtractKeywords(text, top_k)): 输入文本和关键词数量输出关键词列表。现在用户提出一个复杂请求“请把这篇英文文章的核心观点用中文总结出来并分析其情感倾向。”4.1 技能的形式化表示简化版我们用一个Python字典列表来模拟技能库skills_library [ { name: Summarize, description: 生成文本的摘要, preconditions: {input_type: text, has_content: True}, effects: {output_type: text_summary}, implementation: summarize_function # 指向实际函数 }, { name: Translate, description: 将文本翻译成目标语言, preconditions: {input_type: text, has_content: True, target_lang_specified: True}, effects: {output_type: translated_text, language: target_lang}, implementation: translate_function }, { name: SentimentAnalysis, description: 分析文本的情感倾向, preconditions: {input_type: text, has_content: True}, effects: {output_type: sentiment_label}, implementation: sentiment_function } ]4.2 任务解析与规划我们使用一个大语言模型如GPT-4作为任务解析器和规划器。步骤1任务解析将用户请求解析为结构化目标“输入英文文章。目标1. 获得中文摘要。2. 获得情感倾向。”步骤2技能检索与规划LLM根据技能库描述规划出可能的技能序列。它可能会推理出要获得“中文摘要”需要对原文先“摘要”再“翻译”或者先“翻译”再“摘要”。考虑到摘要模型可能对英文优化更好选择先Summarize英文再Translate到中文。“情感倾向”分析可以直接对原文进行。 因此合成计划为[Summarize(原文), Translate(摘要, ‘zh’), SentimentAnalysis(原文)]。4.3 验证机制实现基于运行时断言我们为每个技能实现前提检查def execute_skill(skill_name, params, world_state): skill find_skill(skill_name, skills_library) # 1. 前提检查验证 for precondition, required_value in skill[preconditions].items(): if precondition has_content: if not params.get(text): raise PreconditionFailed(fSkill {skill_name} requires non-empty text.) elif precondition target_lang_specified: if not params.get(target_lang): raise PreconditionFailed(fSkill {skill_name} requires target_lang parameter.) # ... 其他前提检查 # 2. 执行技能 result call_implementation(skill[implementation], params) # 3. 效果断言可选 if skill_name Translate: assert result[language] params[target_lang], Translation language mismatch. # 4. 更新世界状态此处简化为将结果存入上下文 world_state.update({f{skill_name}_result: result}) return result # 执行合成计划 world_state {original_text: english_article} plan [ (Summarize, {text: world_state[original_text], max_length: 200}), (Translate, {text: None, target_lang: zh}), # 注意text需要依赖上一步结果 (SentimentAnalysis, {text: world_state[original_text]}) ] context {} for step_idx, (skill_name, params) in enumerate(plan): # 处理参数依赖例如Translate的text参数来自上一步Summarize的结果 if params.get(text) is None and step_idx 0: prev_skill_name, _ plan[step_idx-1] params[text] context.get(f{prev_skill_name}_result) try: result execute_skill(skill_name, params, world_state) context[f{skill_name}_result] result print(fStep {step_idx1} [{skill_name}] succeeded: {result}) except PreconditionFailed as e: print(fStep {step_idx1} [{skill_name}] failed verification: {e}) # 触发重规划或失败处理 break在这个原型中execute_skill函数内的前提检查就是我们的“验证”环节。它确保了每个技能在执行前其输入是符合预期的。虽然这没有验证整个计划的逻辑但防止了因无效输入导致的低级错误。4.4 更高级的验证计划级检查我们可以增加一个计划验证器在规划完成后、执行前运行def validate_plan(plan, initial_state): 简化版的计划验证检查数据流依赖是否满足。 available_data set(initial_state.keys()) for step in plan: skill_name, params step skill find_skill(skill_name, skills_library) # 检查参数是否都已就绪 for param_name, param_value in params.items(): if param_value is None: # 表示依赖前序输出 # 需要检查前序步骤是否有产出该数据 # 这里简化处理假设参数名对应前序技能名‘_result’ required_data f{skill_name}_input_{param_name} if required_data not in available_data: # 更智能的做法是查找哪个前序技能的effects能提供所需数据 return False, fParameter {param_name} for skill {skill_name} is not available. # 模拟执行更新可用数据 available_data.add(f{skill_name}_result) return True, Plan is valid. is_valid, message validate_plan(plan, {original_text: some_text}) if not is_valid: print(fPlan validation failed: {message}) # 请求重新规划这个验证器检查了计划中技能之间的数据流是否连贯确保不会出现“未生产先消费”的情况。5. 工程落地中的挑战与应对策略将SkillGen从原型推向生产环境会面临一系列工程挑战。以下是几个关键问题及应对思路。5.1 技能库的构建与维护挑战技能库是系统的基石。如何从零开始构建一个覆盖面广、描述准确、互操作性好的技能库业务逻辑变更时如何高效更新技能库策略自动化技能挖掘从现有的代码库、API文档、工作流日志中自动提取技能模式。利用LLM解析函数注释和调用关系生成初步的技能描述和前提/效果假设再由人工审核。技能版本管理为每个技能引入版本号。当技能的实现如API接口或效果描述发生变化时创建新版本。系统在规划和验证时需要明确指定技能版本或兼容最新版本。技能图谱构建不仅存储技能本身还构建技能之间的关系图谱如“技能A的效果是技能B的前提”、“技能C和技能D互斥”。这能极大提升规划效率和验证能力。5.2 规划器的效率与质量挑战当技能库规模变大成百上千规划问题的搜索空间会指数级增长。如何快速找到高质量甚至最优的可行计划策略分层规划将技能按抽象层次分级。先进行高层规划使用宏观技能再对每个宏观技能进行细化分解为底层技能。这类似于人类的“先定战略再定战术”。启发式搜索为规划算法设计领域特定的启发式函数。例如优先选择效果与当前目标最匹配的技能优先选择执行成本低的技能。利用LLM的生成与排序用LLM直接生成多个候选计划然后使用一个轻量级的验证器或评分模型对这些计划进行快速过滤和排序选择最优的几个进行深度验证。5.3 验证的完备性与性能损耗挑战严格的验证如形式化验证、高保真模拟计算成本高会增加推理延迟。如何在可靠性和实时性之间取得平衡策略离线验证与在线快速检查结合对于常见的、高频的技能组合可以提前进行深度验证并将验证结果如“计划P在条件C下有效”缓存起来。在线时只需进行快速的缓存匹配和轻量级条件检查。概率性验证与置信度对于难以完全验证的计划可以计算其执行成功的置信度。系统可以设置一个置信度阈值高于阈值的直接执行低于阈值的则要求人工确认或执行更严格的验证。异步验证与乐观执行对于延迟不敏感的场景可以采用“乐观执行”策略先执行计划同时异步进行深度验证。如果验证失败再执行补偿操作回滚或修正。这要求系统具备良好的事务和状态管理能力。5.4 错误处理与重规划挑战即使计划经过验证实际执行时仍可能因环境变化如API临时故障、数据异常而失败。系统如何优雅地处理失败并恢复策略细粒度的技能状态回滚每个技能应设计成幂等或可补偿的。执行引擎需要记录每个技能执行前的状态快照。当某个技能失败时能够回滚到上一个一致的状态点。基于失败原因的定向重规划失败后不是简单从头开始规划。系统应分析失败原因如“前提不满足网络超时”、“效果未达成支付余额不足”然后基于当前最新的世界状态只对计划的后半部分进行重新规划或替换掉失败的技能。人机协同处理当自动重规划多次失败或遇到高不确定性时系统应主动将问题、上下文和已尝试的方案提交给人类操作员请求指导。人类的反馈又可以作为新的训练数据帮助系统未来更好地处理类似情况。实操心得从封闭世界到开放世界的过渡最初的SkillGen系统最好部署在“封闭世界”假设下即技能的效果是确定的环境变化是有限的如企业内部系统。在这个范围内打磨验证和规划机制。然后逐步引入不确定性例如将调用外部公开API的技能标记为“非确定”为其执行结果添加置信度并设计相应的降级方案。切忌一开始就追求完全开放环境的通用智能那会引入太多不可控因素导致系统难以稳定运行。采用“由内而外由确定到不确定”的扩展路径是工程上更稳健的做法。6. 典型应用场景与未来展望SkillGen的思想可以渗透到众多需要智能决策和执行的领域。6.1 行业应用场景智能客服与工单处理客户问题千变万化。客服Agent可以将“查询订单”、“生成退货单”、“计算退款金额”、“发送通知短信”等作为基础技能。当遇到“我要退货但商品已经用了优惠券怎么算退款”这类复杂问题时Agent能合成“查询订单详情-计算优惠分摊-计算应退金额-生成退款工单”的新流程并验证退款金额是否符合平台规则。自动化运维与故障修复运维系统拥有“重启服务”、“扩容实例”、“回滚版本”、“检查日志”等技能。当监控报警“网站响应慢”时AIOps Agent可以合成诊断计划“检查日志看错误-检查资源使用率-如果CPU高则扩容-如果代码错误则回滚”并验证每一步操作的风险如回滚是否会影响其他服务。个性化内容生成与营销营销Agent拥有“分析用户画像”、“生成广告文案”、“设计海报”、“选择推送渠道”等技能。针对一次新品推广它可以合成个性化营销计划“分析目标用户群偏好-生成契合该偏好的文案-设计对应风格的海报-选择该用户群活跃的渠道推送”并验证内容是否符合品牌规范。科研辅助与数据分析研究助手拥有“检索文献”、“提取数据”、“运行统计模型”、“生成图表”、“撰写摘要”等技能。面对“帮我分析A因素对B疾病的影响趋势”的请求它可以合成分析流程“检索近五年相关文献-从文献中提取A与B的数据-进行元回归分析-生成趋势图表-撰写分析摘要”并验证数据来源的可靠性和统计方法的适用性。6.2 技术演进展望SkillGen目前仍处于早期阶段其未来发展可能会围绕以下几个方向技能的自进化当前的技能库主要靠人工定义和维护。未来的系统可能具备“技能发现”能力能从智能体与环境的交互历史中自动识别出重复有效的行动模式并将其抽象、验证后沉淀为新的基础技能加入技能库实现能力的自我增长。跨智能体的技能共享与合成不同的智能体可能拥有不同的技能专长。一个开放的“技能市场”或“技能网络”可能形成智能体可以通过安全、可信的方式调用其他智能体的技能从而合成出远超自身能力范围的复杂解决方案。验证即服务形式化验证、模拟验证等技术门槛高。未来可能出现专门的“验证即服务”平台提供标准化的接口接收技能描述和计划返回验证结果和反例。这将降低SkillGen系统的构建难度。与基础模型更深的融合当前的规划与验证LLM扮演了重要角色。未来基础模型可能内生出更强的规划与推理能力甚至能将技能的“前提”和“效果”以一种更隐式、更灵活的方式掌握使技能合成更加自然和强大而无需依赖严格的形式化表示。从我个人的实践来看SkillGen代表的“推理时技能合成”范式其最大的价值在于为AI智能体提供了一种系统化的泛化能力。它不追求用一个模型解决所有问题而是通过组合已有的、可靠的模块来应对新问题。这种思路在软件工程中早已是黄金法则——组合优于继承。对于AI应用开发者而言与其苦苦等待一个全能模型不如开始着手构建你的“技能原子库”并思考如何让它们智能地组合起来。这条路虽然起步有门槛但一旦走通构建出的系统将具备真正的灵活性和鲁棒性能够持续适应快速变化的需求这才是智能体长期价值的体现。