1. 从“一镜到底”到“分镜脚本”为什么我们需要策略分解最近在跟几个做AI智能体LLM Agents的朋友聊天大家普遍有个感觉让一个大模型驱动的智能体去完成一个稍微复杂点的任务比如“帮我策划一次家庭旅行”结果往往不尽人意。它可能会给你一个冗长、混乱、甚至前后矛盾的方案一会儿说订机票一会儿又跳回去讨论目的地最后生成的行程表可能漏了酒店或者预算严重超支。这背后的核心问题不是大模型LLM的能力不足而是我们让它用了一种“一镜到底”的方式去思考和规划——试图用一个庞大的、单一的“策略”Policy去解决所有子问题。这让我想起了电影拍摄。没有导演会试图用一个长镜头拍完一整部电影而是会将其分解成一个个场景、镜头甚至细化到机位和演员走位。这种“分镜脚本”就是任务的分解与规划。在AI智能体领域我们面临的挑战是类似的如何让智能体学会自动地将一个复杂的、广义的规划问题Generalized Planning分解成可管理的子任务并且更重要的是如何让这些分解出来的“子策略”能够被识别、存储和复用到未来的新任务中这就是“分层广义规划”Hierarchical Generalized Planning与“策略分解复用”Learning and Reusing Policy Decompositions要解决的核心问题。简单来说我们不再期望智能体每次都从头开始“发明轮子”。相反我们希望它能像一个经验丰富的项目经理或工程师在面对新项目时能快速识别出“哦这个模块和上次那个项目的用户认证模块很像我们可以把那个设计拿过来改改用”“那个数据处理流程我们可以套用之前优化过的ETL模板”。这里的“模块”、“模板”在智能体语境下就是可复用的“策略分解”或“技能”。通过让LLM驱动的智能体学会这种分层与复用能力我们能够显著提升其解决复杂、长周期任务的可靠性、效率与一致性。这不仅是让智能体变得更“聪明”更是让它变得更“专业”和“高效”。2. 核心概念拆解广义规划、分层与策略分解在深入技术细节之前我们有必要厘清几个关键概念。这些概念构成了我们讨论的基石理解它们之间的区别与联系是设计有效系统的前提。2.1 广义规划 vs. 具体规划我们通常理解的“规划”比如用代码写一个“从A地导航到B地”的算法是针对一个非常具体、定义明确的问题。而广义规划Generalized Planning的目标要高一个层次它旨在生成一个通用的“规划器”或“策略”这个策略能够解决一整类问题而不仅仅是单个实例。举个例子具体规划给定“北京”和“上海”两个城市规划出一条具体的交通路线如高铁G1次。广义规划学习一个“城市间路径规划”的策略。这个策略的输入是任意两个城市及当前的交通状态输出是一个通用的行动序列如1. 查询两地间所有交通方式2. 根据时间、成本筛选3. 选择最优方式并预订。这个策略可以应用于“北京到上海”、“广州到深圳”等无数个具体问题。LLM本身已经具备了一定的广义规划潜力因为它能从海量文本中学习到各种任务的通用模式。但如何将这种潜力结构化、可控化地引导出来就是挑战所在。2.2 分层抽象管理复杂度的利器当任务变得极其复杂时如“开发一个简易电商网站”一个扁平的、线性的规划过程会变得难以管理和执行。分层Hierarchical思想的核心是引入抽象层级。高层的规划器负责制定粗粒度的目标如“实现用户系统”、“搭建商品展示页”、“集成支付功能”而低层的规划器或执行器则负责将这些目标具体化为可执行的动作如“调用用户注册API”、“编写商品数据库查询语句”。在LLM智能体框架中这通常体现为一种“管理者-工作者”或“目标-子目标”的架构。高层LLM作为“大脑”或“项目经理”负责任务分解和协调底层可能由多个LLM实例、代码解释器Code Interpreter、工具调用Tool Use等充当“执行者”负责具体实施。分层结构使得智能体能够处理远超其单次上下文窗口长度的复杂任务。2.3 策略分解从“做什么”到“怎么做”的模块化策略Policy在强化学习或决策理论中指的是从“状态”到“行动”的映射。在LLM智能体语境下我们可以将其宽松地理解为给定当前的任务描述和环境状态智能体应该采取的一系列行动或思考步骤。策略分解Policy Decomposition就是将这样一个复杂的策略打破成一系列更小、更专注、功能内聚的“子策略”或“技能”。每个子策略负责解决一个明确定义的子问题。例如“规划旅行”这个大策略可以分解为子策略A目的地与时间决策根据用户偏好预算、兴趣、时间推荐目的地并确定行程时长。子策略B交通安排根据起止点、时间和预算查询并比较航班/火车/汽车选项。子策略C住宿安排在目的地附近根据预算和评分筛选并预订酒店。子策略D日程编排将景点、活动、餐饮安排到具体的日期和时段。这些子策略本身也可以是分层的。例如“交通安排”子策略内部可能进一步分解为“查询”、“比较”、“预订”三个更细粒度的步骤。2.4 学习的核心如何让智能体自己“发现”好的分解这是最具挑战性的部分。我们如何让一个LLM智能体在完成任务的过程中自动地、增量地学习到有价值的策略分解这通常不是通过监督学习标注海量的分解数据而是通过基于经验的学习。主要有两种思路基于成功轨迹的反向工程当智能体通过某种方式可能是在人类反馈或密集试错后成功完成了一个复杂任务我们可以将其完整的“思考-行动”轨迹即一系列LLM调用、工具使用、代码执行的记录作为分析对象。通过分析这个轨迹识别出其中重复出现的模式、功能边界清晰的段落、以及输入输出接口明确的模块。这些被识别出的模式就可以被抽象和封装成一个候选的“可复用子策略”。基于失败或低效的反思与重构当智能体任务失败或效率低下时引导其进行“反思”Reflection。反思过程会分析失败的原因其中一个关键方向就是任务分解是否合理。例如反思日志可能指出“我在规划行程时试图同时考虑交通和住宿导致信息过载和决策冲突”。基于此智能体可以主动提出一个新的分解方案“下次应先独立完成交通规划确定大致抵达和离开时间后再以此为基础搜索住宿”。这个新的分解方案就被记录下来供未来类似任务尝试。注意这里的“学习”很大程度上依赖于LLM自身的推理和概括能力。我们设计的系统需要为LLM提供合适的“脚手架”比如固定的反思模板、轨迹分析工具如能计算代码块或工具调用相似性的函数来辅助它完成这种元认知任务。3. 复用机制设计构建智能体的“技能库”学会了分解下一步就是如何“复用”。复用的本质是建立一个可检索、可适配的技能库Skill Library。当新任务到来时智能体需要能快速从库中找到可能适用的子策略并将它们像乐高积木一样组装起来形成解决新任务的方案。3.1 技能的表征与索引如何描述一个子策略才能让它容易被找到简单用自然语言描述如“订酒店”是模糊且不精确的。一个更工程化的做法是为每个子策略建立结构化表征功能描述用一段精炼的自然语言说明这个子策略是“做什么”的What。前置条件描述执行这个子策略前环境或任务状态需要满足的条件Preconditions。例如“交通安排”子策略的前置条件可能是“已确定旅行起止城市、出发日期和返回日期”。后置条件/效果描述执行这个子策略后预期会改变或生成什么Effects。例如“交通安排”的后置条件是“生成了具体的交通班次选择和预订信息”。输入/输出接口明确该子策略需要什么格式的输入数据以及会产生什么格式的输出数据。这对于自动化组装至关重要。实现体子策略的具体内容。这可能是一段提示词Prompt Template一段可执行的代码Function或一个工具调用序列的规范。有了这些表征我们就可以为技能库建立索引。索引的关键在于相似性检索。当面对新任务时系统可以将任务描述或当前子目标与技能库中各个子策略的“功能描述”和“前置条件”进行向量相似度计算使用Embedding模型召回最相关的几个候选技能。3.2 技能的适配与组装检索到的技能很少能“开箱即用”。通常需要进行适配。例如检索到一个“预订国内航班”的技能但新任务需要“预订国际航班”。这时就需要LLM发挥其泛化能力根据新任务的上下文对原有技能的提示词或代码进行修改和调整。技能的组装则是一个更高级的规划问题。高层规划器或一个专门的“组装器”LLM需要决定解决当前任务需要哪些子技能这些子技能的执行顺序是什么有些技能有严格的先后依赖如何将一个技能的输出作为下一个技能的输入进行传递数据流衔接如何处理并行可执行的子任务这个过程本身也可以被学习并固化为更高级的“工作流模式”或“项目模板”加入技能库实现复用的递归提升。3.3 一个简化的技术实现示例假设我们使用LangChain或AutoGen这类框架来构建智能体。一个可复用子策略可以封装成一个Tool或一个Chain。# 伪代码示例定义一个“查询天气”的可复用技能 from langchain.tools import BaseTool from langchain.embeddings import OpenAIEmbeddings from pydantic import BaseModel, Field class WeatherQueryInput(BaseModel): 该技能的输入模式 location: str Field(description城市名称如‘北京’) date: str Field(description日期格式YYYY-MM-DD) class WeatherQuerySkill(BaseTool): name weather_query description 根据城市和日期查询天气预报。前置条件已知具体城市和日期。后置条件返回天气情况。 args_schema WeatherQueryInput def _run(self, location: str, date: str) - str: # 这里可以是调用真实天气API的代码 # 例如result call_weather_api(location, date) return f{location}在{date}的天气是晴朗25℃。 # 可以为技能计算一个向量表征用于检索 property def embedding(self): emb OpenAIEmbeddings() return emb.embed_query(self.description) # 技能库 skill_library { weather_query: WeatherQuerySkill(), # ... 其他技能如 hotel_search, flight_booking } # 当新任务需要“查询天气”时检索器通过比较任务描述和技能的description embedding找到这个skill。 # 高层规划器会生成类似这样的指令“现在需要为明天上海的活动做准备请调用‘weather_query’技能参数为 location‘上海’ date‘2023-10-27’。”在实际系统中技能的描述、适配和组装逻辑会复杂得多需要更精细的提示工程和流程控制。4. 实操挑战与经验心得让分解与复用真正工作起来理论很美好但落地时坑不少。结合一些实验和社区项目的经验我总结出以下几个关键的挑战和应对思路。4.1 挑战一分解的粒度与一致性难题问题分解到多细才算合适一个“写邮件”应该是一个技能还是应该分解成“构思大纲”、“撰写正文”、“检查语法”三个技能不同的任务、不同的LLM甚至同一LLM的不同随机种子都可能产生不一致的分解方案。应对思路领域引导在系统设计初期根据目标领域如旅行规划、代码生成、数据分析预先定义一些粗粒度的“领域概念”或“任务类型”为LLM的分解提供锚点。例如在旅行领域可以预设“交通”、“住宿”、“活动”、“餐饮”等顶级分类。基于效用的评估建立一个简单的评估机制来判断一个分解是否“好”。例如分解后的子任务是否更容易被现有技能库解决执行整个任务的步骤数或LLM调用次数是否减少了通过这种反馈系统可以倾向于选择那些被验证为更有效的分解模式并逐渐形成一致性。允许动态调整不要假设一次分解就是最终方案。智能体在执行过程中如果发现某个子任务过于复杂或失败应该允许其触发“再分解”过程将该子任务进一步拆解。4.2 挑战二技能检索的“语义鸿沟”问题基于向量相似度的检索很容易遇到“词不达意”或“过度联想”。例如任务描述是“帮我安排一次出差”可能被关联到“旅行规划”技能但出差和旅游在预算、审批、报销等子任务上差异巨大。直接复用可能导致错误。应对思路多维度检索不仅仅比较任务描述和技能描述还将“前置条件”、“历史使用场景”等纳入检索考量。可以设计一个混合检索器结合关键词匹配用于精确匹配如API名称和向量检索用于语义匹配。LLM作为重排序器先用向量检索召回Top-K个候选技能比如10个然后将这些技能的详细描述和新任务上下文一起交给一个LLM让它基于深层理解进行重新排序和选择甚至可以要求LLM指出直接复用可能存在的风险。强化技能描述的规范性人工或通过LLM优化使技能描述更加精确、无歧义包含关键的限制条件。例如“预订酒店”技能应明确描述为“为个人休闲旅行预订酒店需考虑价格和评分”而“预订差旅酒店”则描述为“为公司出差预订酒店需考虑协议价格和发票要求”。4.3 挑战三技能适配的可靠性问题让LLM自动修改一个技能的内部逻辑如提示词以适应新场景风险很高。它可能会在适配过程中引入错误、遗忘原有技能的核心约束或者产生不安全的代码。应对思路提供适配范例在技能库中不仅存储技能本身还存储一些成功的“适配案例”。当需要适配时系统可以检索类似的历史适配案例作为参考范例引导LLM进行安全的修改。这本质上是Few-shot Learning。限制适配范围不是所有技能都允许任意修改。可以为技能定义“可适配参数”和“不可变核心”。例如一个数据可视化技能的图表类型、颜色主题可以作为参数适配但其数据清洗和安全性检查的核心代码块应被锁定。适配后验证在将适配后的技能投入正式使用前设计一个简单的“沙盒测试”环节。例如用一组测试输入验证其输出是否符合预期或者让另一个LLM扮演评审者角色检查适配后的逻辑是否存在明显问题。4.4 挑战四长期技能库的维护与演化问题随着时间推移技能库会膨胀可能出现功能重复、过时甚至冲突的技能。如何维护这个库的健康度应对思路技能去重与合并定期或在新技能入库时计算技能之间的功能相似度。对于高度相似的技能可以尝试用LLM分析它们看是否能合并成一个更通用、更健壮的版本或者淘汰掉那个效果较差的版本。技能效用追踪为每个技能附加元数据记录其被调用的次数、任务成功率、执行效率如耗时等。低效用、低成功率的技能可以被标记、降权或归档。版本控制对技能实行简单的版本管理。当对一个技能进行重大适配或优化后保存为新版本而非直接覆盖。这有助于回滚和对比分析。5. 未来展望走向真正自主的“技能工匠”智能体目前基于LLM的策略分解与复用研究仍处于早期阶段大多数系统需要较多的人工设计如预定义技能模板、设计反思流程。但未来的方向是明确的让智能体越来越自主地完成“学习-分解-复用”的完整循环。一个更远景的想象是智能体不仅能复用技能还能创造新的基础技能。例如在多次完成“从网页提取价格信息”和“从文档提取联系人信息”后智能体可能抽象出一个更通用的“基于CSS选择器或固定模式的文本信息提取”技能。这类似于人类从具体经验中归纳出抽象知识的过程。此外多智能体协作将为技能复用带来新的维度。不同的智能体可以专精于不同领域的技能库它们之间可以通过“技能市场”进行共享和交易。一个擅长数据分析的智能体可以向一个擅长UI设计的智能体“购买”或“请求”一个图表美化技能。实现这些愿景离不开对LLM推理、规划、元认知能力的持续挖掘以及更精巧的系统工程设计。作为构建者我们现在的每一步实践——无论是设计一个更好的技能描述格式还是优化一次检索重排序流程——都是在为未来更强大、更通用的自主智能体添砖加瓦。这个过程本身就像是在教一个数字大脑如何更好地“思考”和“工作”充满了挑战也充满了令人兴奋的可能性。