生成式技能组合：让AI智能体灵活应对复杂任务的架构与实践

1. 从“单一技能”到“组合拳”为什么我们需要生成式技能组合最近在折腾大语言模型驱动的智能体时我遇到了一个挺典型的瓶颈。我手头有一个能写代码的智能体还有一个能分析数据的智能体它们各自在自己的“一亩三分地”里都干得不错。但当我需要完成一个“爬取某网站数据清洗后生成分析报告”的复杂任务时问题就来了。我得手动把任务拆解先启动爬虫智能体等它干完再把数据喂给分析智能体中间还得自己处理数据格式转换。整个过程笨拙、低效而且完全不具备可扩展性。这让我开始思考我们训练或赋予智能体的那些独立“技能”比如“文本摘要”、“代码生成”、“SQL查询”在真实世界里往往是孤立无用的。真正的价值在于让智能体能像人类一样根据动态变化的目标将这些原子技能灵活地组合、编排打出一套解决问题的“组合拳”。这就是“生成式技能组合”要解决的核心问题。简单来说Generative Skill Composition不是让智能体学习一个新技能而是赋予它一种“元能力”——根据未知的、复杂的任务描述动态地生成一个由多个已有基础技能构成的执行计划并协调这些技能按序或并行执行最终达成目标。这背后的驱动力非常直接我们不可能为每一个可能出现的复杂任务都预先训练一个专用模型或编写一套固定流程。世界是开放和变化的智能体要想真正有用必须具备这种动态规划和组合的能力。这不仅是效率问题更是智能体能否从“玩具”走向“工具”的关键一步。2. 拆解“技能组合”核心组件与工作流要实现生成式技能组合我们不能只靠大语言模型“灵光一现”的指令跟随。它需要一个系统性的架构将规划、检索、执行、验证形成一个闭环。下面这张图概括了一个典型智能体在面临复杂任务时内部进行技能组合决策与执行的完整工作流flowchart TD A[复杂任务输入] -- B[“任务规划与分解brLLM核心”] B -- C[“技能库检索与匹配”] C -- D{“技能是否可用”} D -- 是 -- E[“生成技能执行计划brSkill Plan”] D -- 否 -- F[“反馈与规划调整”] F -- B E -- G[“按计划调度与执行技能”] G -- H[“执行结果验证与评估”] H -- I{“任务是否完成”} I -- 是 -- J[输出最终结果] I -- 否 -- F这个工作流的核心可以分解为几个关键组件它们共同协作才能实现可靠的技能组合。2.1 技能库智能体的“武器库”技能库是整个体系的基石。它不是一个简单的函数列表而是一个结构化的、可描述的技能集合。每个技能条目至少应包含技能名称与唯一ID用于精确调用。自然语言描述详细说明这个技能能做什么输入输出是什么。例如“技能fetch_webpage。描述给定一个有效的URL获取该网页的HTML内容并返回。”函数签名/接口明确定义输入参数的类型、格式以及返回值的结构。这是机器可读、可执行的部分。前置与后置条件这个技能执行需要什么前提如“需要用户已登录”以及执行后会改变什么状态如“会在数据库创建一条记录”。这对于自动化规划至关重要。元数据如技能类别、创建者、版本、成功率历史统计等。一个设计良好的技能库其描述的质量直接决定了LLM在规划时能否正确理解和选用它。描述模糊的技能就像工具箱里一把用途不明的工具智能体根本不知道什么时候该用它。2.2 技能规划器任务拆解与蓝图绘制这是LLM发挥核心作用的地方。规划器接收用户的复杂任务指令结合技能库中所有技能的描述进行以下推理任务分解将“写一份行业分析报告”分解为“搜索最新行业动态”、“收集主要公司财务数据”、“对比分析优劣势”、“生成报告摘要”等子目标。技能匹配为每一个子目标从技能库中寻找最匹配的一个或多个技能。例如为“搜索最新行业动态”匹配web_search技能为“生成报告摘要”匹配text_summarization技能。依赖关系解析确定子任务之间的顺序。显然“收集数据”必须在“分析数据”之前“分析数据”又必须在“生成报告”之前。有些任务可以并行如同时搜索A公司和B公司的信息。生成可执行计划最终输出一个结构化的技能执行计划Skill Plan。这个计划通常是一个有向无环图DAG或一个步骤列表明确每一步调用哪个技能、输入参数是什么、输出结果如何传递给下一步。注意规划器完全依赖对技能描述的“理解”。如果技能库中有一个data_visualization数据可视化技能但描述只写了“生成图表”那么LLM可能不会在“写一份报告”的任务中主动调用它。但如果描述改为“根据结构化的数据如JSON格式的列表生成适用于分析报告的折线图或柱状图并返回图片文件路径或Base64编码”那么LLM在规划“生成报告”时就很可能在分析数据后插入这个技能来让报告更直观。2.3 技能执行器与状态管理按图索骥的实干家规划器画好了“蓝图”执行器负责“施工”。它需要调度技能按照计划中的顺序或依赖关系依次或并行地调用具体的技能函数。管理输入输出将上一步技能的执行结果正确地格式化为下一步技能所需的输入参数。这中间常常涉及数据格式的转换和提取。维护对话/任务状态在整个多步执行过程中记住上下文。例如用户可能在报告生成后说“把第三点讲得更详细些”执行器需要能定位到“第三点”对应的原始数据和生成步骤并重新触发相关技能链。执行器是相对“笨”但必须可靠的组件。它严格遵循计划并处理执行中的异常如技能调用失败、返回结果格式不符等然后将这些异常反馈给上层以触发重规划。2.4 验证与反思确保组合不出错这是智能体从“执行”走向“可靠”的关键一环。技能组合后结果不一定正确。验证模块负责结果检查检查最终输出是否真正满足了用户的初始请求。这可以通过规则如报告必须包含摘要、数据、结论、通过另一个LLM调用进行验证或与历史成功案例进行比对来实现。过程反思如果任务失败或结果不佳反思环节会分析是规划出了问题技能选错了或顺序不对还是某个技能本身执行有误。例如如果web_search返回的内容质量太差导致后续分析出错反思机制可能会建议“在搜索技能后增加一个content_filter或relevance_check技能”。技能库更新基于反思系统可以自动或经人工确认后更新技能的描述、前置条件甚至建议创建新的复合技能将一段经常连续成功的技能链打包成一个新的高阶技能。3. 实战构建一个简易的“技能组合”智能体理论说再多不如动手搭一个。下面我将用一个简化但完整的例子展示如何用Python构建一个具备基础技能组合能力的智能体。我们假设有一个为内部数据分析师服务的智能体它的技能库目前有三个技能。3.1 定义技能库我们首先用字典定义一个简易的技能库。在实际项目中这可能会存储在数据库或向量数据库中以便语义检索。skill_library { fetch_csv: { description: 从指定的本地文件路径或URL读取CSV格式的数据文件并将其解析为Python的pandas DataFrame对象。, function: lambda path: pd.read_csv(path), # 简化实际应有错误处理 input_schema: {path: string}, output_schema: {dataframe: pandas.DataFrame} }, clean_data: { description: 对一个pandas DataFrame进行基础数据清洗包括删除全为空值的列、填充指定列的缺失值用中位数或均值。, function: lambda df, fill_columnsNone: df.dropna(axis1, howall).fillna(df[fill_columns].median() if fill_columns else df.median()), input_schema: {dataframe: pandas.DataFrame, fill_columns: list[string] (optional)}, output_schema: {cleaned_dataframe: pandas.DataFrame} }, generate_summary: { description: 针对一个pandas DataFrame生成一份文本摘要包括数据维度、各数值列的基本统计信息均值、标准差等。, function: lambda df: f数据共{df.shape[0]}行{df.shape[1]}列。\\n \\n.join([f列 {col}: 均值{df[col].mean():.2f}, 标准差{df[col].std():.2f} for col in df.select_dtypes(include[np.number]).columns]), input_schema: {dataframe: pandas.DataFrame}, output_schema: {summary_text: string} } }3.2 实现基于LLM的规划器这里我们使用OpenAI的GPT-4模型作为规划器的大脑。我们通过精心设计的提示词Prompt让LLM根据任务和技能库生成一个JSON格式的计划。import openai import json def plan_with_llm(user_task, skill_library): 使用LLM根据用户任务和技能库生成执行计划。 # 1. 将技能库信息格式化为文本供LLM参考 skill_descriptions [] for skill_name, skill_info in skill_library.items(): desc f- {skill_name}: {skill_info[description]} 输入: {skill_info[input_schema]} 输出: {skill_info[output_schema]} skill_descriptions.append(desc) skills_text \\n.join(skill_descriptions) # 2. 构建规划提示词 prompt f 你是一个任务规划AI。请根据用户的任务描述和可用的技能列表生成一个分步执行计划。 每一步计划必须对应一个具体的技能并明确其输入参数。上一步的输出可以作为下一步的输入。 可用技能列表 {skills_text} 用户任务{user_task} 请以严格的JSON格式输出计划格式如下 {{ plan: [ {{ step: 1, skill: 技能名称, input: {{参数名: 参数值或$上一步输出键名}} }}, ... ] }} 如果任务无法用现有技能完成请将plan设为空列表[]。 只输出JSON不要有其他任何解释。 # 3. 调用LLM response openai.ChatCompletion.create( modelgpt-4, messages[{role: user, content: prompt}], temperature0.1 # 低温度保证输出格式稳定 ) # 4. 解析LLM的回复 try: plan_json json.loads(response.choices[0].message.content) return plan_json.get(plan, []) except json.JSONDecodeError: print(LLM返回了非JSON格式。) return []3.3 实现执行器与状态追踪执行器负责按计划运行并管理每一步的输出状态。class SkillComposerAgent: def __init__(self, skill_lib): self.skill_lib skill_lib self.execution_context {} # 用于存储每一步的输出 def execute_plan(self, plan): 执行给定的计划 final_result None for step in plan: step_num step[step] skill_name step[skill] skill_input_raw step[input] print(f[Step {step_num}] 执行技能: {skill_name}) # 1. 解析输入参数将类似 $prev_output_key 的引用替换为实际值 resolved_inputs self._resolve_inputs(skill_input_raw) # 2. 获取技能函数 skill_func self.skill_lib.get(skill_name, {}).get(function) if not skill_func: print(f错误: 技能 {skill_name} 不存在于技能库中。) return None # 3. 执行技能 try: output skill_func(**resolved_inputs) except Exception as e: print(f错误: 执行技能 {skill_name} 时失败: {e}) return None # 4. 存储输出到上下文供后续步骤使用 # 约定每个技能的输出以 step_{step_num} 为键存储 output_key fstep_{step_num} self.execution_context[output_key] output print(f 输出已存储至上下文键: {output_key}) final_result output return final_result def _resolve_inputs(self, raw_inputs): 解析输入参数处理对之前步骤输出的引用以$开头 resolved {} for key, value in raw_inputs.items(): if isinstance(value, str) and value.startswith($): # 引用之前步骤的输出例如 $step_1.dataframe ref_path value[1:].split(.) ctx_key ref_path[0] # 如 step_1 if ctx_key in self.execution_context: obj self.execution_context[ctx_key] # 简单处理假设引用的是整个对象。实际可能需要处理嵌套属性。 resolved[key] obj else: raise ValueError(f无法解析输入引用: {value}上下文键 {ctx_key} 未找到。) else: # 静态值 resolved[key] value return resolved3.4 端到端运行示例现在让我们把整个流程串起来给智能体一个任务。# 模拟用户任务 user_task 我有一份销售数据在 /data/sales.csv请帮我清洗一下数据然后生成一份数据摘要。 # 步骤1: 规划 print( 阶段1: 任务规划 ) execution_plan plan_with_llm(user_task, skill_library) print(生成的计划:, json.dumps(execution_plan, indent2)) # 步骤2: 执行 if execution_plan: print(\\n 阶段2: 计划执行 ) agent SkillComposerAgent(skill_library) final_output agent.execute_plan(execution_plan) print(\\n 最终结果 ) print(final_output) else: print(LLM认为无法用现有技能完成此任务。)在这个例子中LLM规划器很可能会生成如下计划{ plan: [ { step: 1, skill: fetch_csv, input: {path: /data/sales.csv} }, { step: 2, skill: clean_data, input: {dataframe: $step_1.dataframe, fill_columns: [revenue, units_sold]} }, { step: 3, skill: generate_summary, input: {dataframe: $step_2.cleaned_dataframe} } ] }执行器会依次运行fetch_csv-clean_data-generate_summary并将上一步的输出自动传递给下一步最终得到清洗后的数据摘要文本。4. 超越基础高级模式与实战避坑指南上面的简易实现揭示了核心原理但在生产环境中远远不够。要让技能组合智能体真正可靠必须考虑以下高级模式和常见陷阱。4.1 动态规划与重规划当计划赶不上变化最初的计划可能出错。比如fetch_csv技能执行成功但clean_data技能执行时发现数据格式异常抛出了错误。一个健壮的智能体不能就此崩溃。解决方案是实现重规划Re-planning机制。当某个技能执行失败或验证模块发现中间结果不符合预期时系统将当前状态已成功步骤的结果、错误信息连同原始任务再次提交给LLM规划器要求它基于“当前已完成的步骤和遇到的错误”生成一个新的、修正后的后续计划。例如如果clean_data失败错误是“列 ‘revenue’ 不存在”重规划的提示词会包含“步骤1fetch_csv已成功输出dataframe包含列 [‘date’, ‘sales’, ‘profit’]。步骤2clean_data失败原因为 ‘KeyError: revenue’。请调整计划以完成‘清洗数据并生成摘要’的任务。” LLM可能会生成新计划将clean_data的fill_columns参数改为[‘sales’]或者插入一个新的inspect_columns技能先查看数据。实操心得重规划的次数必须有限制如最多3次否则可能陷入死循环。同时将错误信息清晰地格式化后再喂给LLM至关重要。直接抛出的Python Traceback对LLM不友好最好转换为“技能X失败原因参数Y的值Z无效”这样的自然语言描述。4.2 技能检索的优化从关键词到语义搜索当技能库膨胀到几百上千个时在提示词中列出所有技能描述是不现实的会耗尽上下文窗口。这时需要技能检索模块。向量化检索将每个技能的描述文本通过嵌入模型如text-embedding-3-small转换为向量存入向量数据库如ChromaDB、Pinecone。当新任务到来时将任务描述也转换为向量进行相似度搜索召回最相关的Top K个技能再将这K个技能的详细信息送给LLM做精细规划。分层检索将技能分类如“数据获取”、“数据处理”、“可视化”、“文件操作”。先让LLM或一个分类器判断任务涉及哪些大类再从这些类别的子集中检索具体技能减少搜索范围。元数据过滤结合技能的其他元数据如所需权限、执行成本、历史成功率等在检索时进行过滤优先选择更可靠、更经济的技能。4.3 复合技能与技能抽象提升复用与规划效率在运行过程中系统可能会发现某些技能组合如fetch_csv-clean_data-generate_summary频繁地为了同一个高层目标“加载并概览一份数据”一起出现。每次都让LLM从头规划这三个步骤既低效又消耗Token。此时可以引入复合技能的概念。系统可以自动或由管理员将这条成功的技能链“打包”注册为一个新的高阶技能比如叫load_and_summarize_data。这个新技能有自己的描述和接口输入文件路径输出摘要文本。之后当遇到类似任务时LLM可以直接调用这个复合技能一步到位。这本质上是技能的抽象和复用是提高智能体执行效率和降低复杂性的关键。它让智能体能够积累经验形成自己的“套路”和“最佳实践”。4.4 可靠性的基石验证、评估与技能描述工程技能组合的可靠性瓶颈往往不在LLM的规划能力而在技能的“边界”是否清晰。技能描述的模糊性是万恶之源如果web_search技能的描述是“搜索信息”LLM可能会在任何需要信息的场景滥用它即使内部有更精确的数据库查询技能。描述必须尽可能精确包括边界条件。例如“在公开互联网上使用搜索引擎API根据关键词列表查找近一年内的相关新闻或技术文章返回标题、链接和片段。不适用于查询内部知识库、实时数据或需要复杂交互的网站。”强化结果验证不能无条件相信任何技能的输出。对于关键步骤应增加验证技能。例如在调用execute_sql技能后可以自动调用一个validate_query_result技能检查结果行数是否在合理范围内、是否包含异常值等。建立评估闭环记录每一次技能组合执行的完整轨迹计划、输入、输出、用时、成功与否。定期分析这些日志可以发现哪些技能组合的成功率高哪些技能的描述经常被误解哪些任务类型当前技能库无法覆盖。这些数据是迭代优化技能库和规划策略的黄金燃料。5. 开源框架与未来展望目前已经有一些优秀的开源项目在探索智能体的技能组合与工作流编排它们提供了更成熟的基础设施。LangChain / LangGraphLangChain的“智能体”概念本身就包含了工具技能的使用。LangGraph更进一步允许你以图Graph的形式显式地定义智能体的状态和调用流程非常适合实现复杂的、带循环和条件分支的技能组合计划。AutoGen由微软推出的多智能体对话框架。其核心思想是让多个角色化的智能体如程序员、产品经理、测试员通过对话来协作完成任务。这可以看作是一种更动态、更交互式的技能组合形式每个智能体封装了一组相关技能通过协商来分解和执行任务。CrewAI一个基于角色和任务的智能体编排框架。它强调将任务分解、角色分配、执行和验证流程化提供了更高层级的抽象方便管理复杂的多智能体项目。从我个人的实践来看生成式技能组合是LLM智能体从“聊天演示”走向“生产级应用”的必由之路。它解决的正是复杂任务自动化中“灵活性”与“可靠性”的矛盾。未来的方向可能会集中在更鲁棒的规划结合符号规划器与LLM利用前者保证逻辑正确性后者处理模糊性。技能的自动发现与生成智能体能否通过观察人类操作或阅读文档自动将一段操作序列抽象、描述并注册为一个新技能跨智能体的技能共享形成一个“技能市场”不同的智能体可以发布、发现和调用彼此的技能形成真正的能力网络。构建这样的系统最大的挑战往往不是技术本身而是如何设计出清晰、无歧义的技能接口和描述以及如何建立有效的验证与评估体系。这更像是一场与模糊性作斗争的软件工程而LLM是我们手中最强大的但也最需要被谨慎约束的武器。