分层组合性AI助手：从任务分解到技能调用的智能体架构实践-育师

1. 项目概述：什么是“分层组合性”AI助手？

最近在捣鼓AI Agent（智能体）项目时，我反复琢磨一个词：Hierarchical Compositionality，翻译过来叫“分层组合性”。这听起来有点学术，但说白了，它解决的是一个非常实际的问题：如何让一个AI助手，从只会执行单一指令的“工具人”，进化成一个能像人类一样，把复杂任务拆解、规划、并调用各种技能组合完成的“得力伙伴”？比如，你随口说一句“帮我策划一个周末家庭烧烤派对”，一个具备分层组合性的AI助手，应该能自动理解这需要分解为“确定人数与预算”、“采购食材清单”、“查看天气预报并准备备用方案”、“安排活动流程”等多个子任务，并且知道先做什么后做什么，甚至能调用日历、电商、天气查询等不同工具来执行。这背后的核心思想，就是分层组合性。

为什么这个概念现在这么火？因为当前大多数所谓的AI Agent，还停留在“if-else触发器”或“单轮对话专家”的层面。它们或许能很好地完成一个定义明确的小任务（比如“查一下明天北京的天气”），但面对开放、动态、多步骤的复杂需求时，就显得力不从心，缺乏真正的“智能”规划与协调能力。分层组合性正是为了赋予AI这种“分而治之”和“灵活组装”的高级能力。它不仅仅是技术的堆砌，更是一种设计哲学，关乎如何构建一个稳健、可扩展且真正实用的辅助型AI智能体。如果你正在关注AI Agent开发、学习其架构，或者想知道如何从零搭建一个属于自己的智能助手，理解分层组合性将是你的必修课。接下来，我将结合我自己的实践和踩过的坑，带你深入拆解这个核心概念，并看看如何将其落地到一个可运行的辅助AI Agent项目中。

2. 核心设计思路：像搭积木一样构建智能

构建一个具备分层组合性的AI Agent，其设计思路的核心在于模仿人类的认知和解决问题的方式。我们不会试图用一个巨大的、包罗万象的模型去解决所有问题，而是设计一套系统，让智能体学会“分解任务、调用技能、组合结果”。

2.1 核心理念拆解：任务、技能与层级

首先，我们需要明确几个关键概念：

任务（Task）：用户提出的最终目标，通常是模糊或复杂的，例如“优化我的个人财务”、“为新项目制定营销方案”。
子任务（Sub-task）：通过对主任务进行分解得到的一系列更具体、可执行的目标。分解的依据可以是步骤顺序、功能模块或依赖关系。
技能（Skill）/工具（Tool）：智能体能够执行的最小原子操作单元。一个技能通常对应一个具体的函数调用或API接口，例如“调用搜索引擎API查询信息”、“执行Python代码进行数据分析”、“调用日历服务创建事件”。
组合（Composition）：根据任务需求，动态地将不同的技能按照一定的逻辑（顺序、并行、条件分支）组装起来，形成一个可执行的工作流。
层级（Hierarchy）：这体现在多个维度：
- 任务分解层级：主任务 -> 一级子任务 -> 二级子任务 … 形成一个树状或图状结构。
- 控制流层级：高层控制器负责宏观规划和任务分发，中层协调器负责子任务调度和技能组合，底层执行器负责具体技能调用。
- 知识/技能库层级：基础通用技能（如计算、查询）位于底层，领域特定技能（如财务分析、代码生成）位于上层。

设计背后的“为什么”：采用这种架构，首要目的是解决复杂性问题。一个庞大的、端到端的模型很难同时保证在众多领域的精度和效率。通过分解，我们可以让更专业的“小模型”或“技能”去处理擅长的部分。其次，这极大地提升了可维护性和可扩展性。新增一个功能，只需要开发一个新的“技能”并将其注册到技能库中，智能体的能力边界就自然扩大了，而无需改动核心架构。最后，这带来了更好的可解释性。我们可以清晰地追踪智能体解决问题的每一步：“它为什么这么做？”“它调用了哪些工具？”“中间结果是什么？”，这对于调试和建立用户信任至关重要。

2.2 主流架构模式选型

在实际项目中，我们通常不会从零发明轮子，而是基于一些成熟的架构模式进行构建。目前主要有两种主流思路：

1. 基于提示工程（Prompt Engineering）与规划器（Planner）的模式这是目前最流行、入门门槛相对较低的方式。其核心是利用大语言模型（LLM）强大的理解和生成能力作为“大脑”（规划器）。

工作流程：用户输入 -> LLM规划器分析意图并分解任务 -> LLM规划器为每个子任务选择合适的技能（通过描述匹配）-> 执行引擎调用技能 -> 收集结果返回给LLM规划器进行汇总或下一步决策 -> 输出最终结果。
优势：非常灵活，无需预定义严格的流程，LLM可以处理开放域和未知任务。开发速度快，主要工作是编写清晰的技能描述和设计有效的提示词（Prompt）。
挑战：依赖LLM的稳定性，可能存在“幻觉”（编造不存在的技能或步骤）。执行链路可能较长，延迟和成本较高。对提示词设计的要求很高。
典型框架/工具：LangChain、LlamaIndex、AutoGen等框架提供了大量用于构建此类Agent的组件。

2. 基于工作流引擎（Workflow Engine）与状态机（State Machine）的模式这种方式更偏向传统软件工程，确定性更强。

工作流程：预定义一系列任务模板和流程（如流程图）。用户输入后，由分类器确定匹配的模板 -> 工作流引擎按模板定义的步骤依次执行，在特定节点调用对应的技能 -> 引擎根据执行结果（成功/失败）决定下一步走向（分支、循环）-> 最终输出结果。
优势：执行过程稳定、可控、可预测。性能好，延迟低。非常适合业务流程固定、逻辑严谨的场景（如客服工单处理、数据ETL流水线）。
挑战：灵活性差，无法处理预定义流程之外的任务。开发和维护流程模板的工作量较大。
典型框架/工具：Apache Airflow、Prefect、Camunda等BPMN工具，或自研基于状态机的引擎。

选型建议：对于探索性、创意性强的辅助Agent（如创意写作助手、研究分析助手），模式一（LLM规划器）更具优势。对于重复性、规范性强的任务（如月度报告自动生成、系统巡检），模式二（工作流引擎）更可靠。在实际复杂项目中，两者常常结合使用：高层用LLM做动态规划，底层具体模块用固定工作流保证稳定性。

3. 关键组件与实现细节

无论选择哪种架构模式，一个具备分层组合性的AI Agent通常都包含以下几个关键组件。这里我以更通用的“LLM规划器”模式为例，深入每个组件的实现细节。

3.1 任务分解与规划模块

这是智能体的“大脑”，负责理解用户意图并将其转化为可执行计划。

实现要点：

提示词（Prompt）设计：这是核心中的核心。你需要设计一个系统提示词，明确告诉LLM它的角色、可用技能以及输出格式。

# 一个简化的规划提示词示例 system_prompt = """ 你是一个任务规划专家。请将用户的请求分解为一系列具体的子任务，并为每个子任务分配合适的技能。 你拥有的技能库包括： - web_search(query): 使用搜索引擎查询网络信息。 - python_executor(code): 执行一段Python代码并返回结果。 - calculator(expression): 计算数学表达式。 - get_weather(city): 获取指定城市的天气信息。 - send_email(to, subject, body): 发送电子邮件。 请严格按照以下JSON格式输出你的规划： { "original_task": "用户原始请求", "sub_tasks": [ { "id": 1, "description": "子任务1描述", "skill": "技能名称", "parameters": {"参数1": "值1", "参数2": "值2"} }, ... ] } """

规划迭代与反思：一次分解可能不完美。高级的Agent会引入“反思”机制。即，当一个子任务执行失败或结果不理想时，将错误信息反馈给规划器，让其重新规划或调整参数。这相当于让智能体具备了“试错”和“学习”的能力。
长期与短期记忆：为了处理多轮对话中的复杂任务，Agent需要记住之前的上下文（短期记忆）和重要的历史经验（长期记忆）。这可以通过向量数据库存储对话历史和相关知识片段来实现，在规划时作为参考信息输入给LLM。

实操心得：

规划提示词里一定要明确输出格式（如JSON），并做严格的输出解析和校验，否则后续步骤无法自动化。对于复杂任务，可以要求LLM先输出一个“大纲”或“里程碑”，再进行细粒度分解，这比要求它一步分解到底更稳定。

3.2 技能库与工具调用层

这是智能体的“手和脚”，是能力的具体承载。

实现要点：

技能标准化封装：每个技能都应被封装成一个统一的函数或类，具有清晰的输入输出定义。例如：

class Skill: def __init__(self, name, description, func, input_schema, output_schema): self.name = name self.description = description # 用于给LLM理解技能用途 self.func = func # 实际执行的函数 self.input_schema = input_schema # 输入参数格式，如JSON Schema self.output_schema = output_schema # 输出格式 # 示例：定义一个计算器技能 def calculate(expression: str) -> str: try: # 警告：实际生产中要对表达式做严格的安全过滤！ result = eval(expression, {"__builtins__": {}}, {}) return str(result) except Exception as e: return f"计算错误: {e}" calculator_skill = Skill( name="calculator", description="计算一个数学表达式的结果，支持加减乘除和括号。", func=calculate, input_schema={"type": "object", "properties": {"expression": {"type": "string"}}}, output_schema={"type": "string"} )

技能发现与匹配：规划器如何知道该调用哪个技能？通常有两种方式：
- 描述匹配：将技能的描述（description）和当前子任务描述一起输入给LLM，让LLM选择最匹配的技能。这是最灵活的方式。
- 函数签名匹配：预定义技能的函数签名（名称、参数类型），LLM根据对任务的理解来填充参数。OpenAI的Function Calling就是这种模式的典范。
技能执行与安全：这是重中之重。必须建立一个安全的沙箱环境来执行技能，特别是对于代码执行、系统命令等高风险操作。要严格限制权限、资源（CPU/内存/时间）和可访问的网络范围。

注意事项：

永远不要相信来自LLM或用户的直接输入去执行危险操作。对于python_executor这类技能，必须使用像Docker容器、seccomp沙箱，或者至少是restrictedPython这样的安全解释器。参数必须经过严格的验证和清洗。

3.3 工作流编排与状态管理

这是智能体的“中枢神经系统”，负责协调各个模块，管理任务执行的生命周期。

实现要点：

状态机设计：一个任务从开始到结束，会经历多个状态，如PENDING（等待规划）、PLANNING（规划中）、READY（就绪，等待执行）、EXECUTING（执行中）、SUCCESS/FAILED（成功/失败）、PAUSED（暂停）。你需要设计一个状态机来管理这些转换。

执行引擎：这是驱动整个流程的循环。一个简单的引擎逻辑如下：

class SimpleAgentEngine: def run(self, user_input): task_state = {"status": "PENDING", "input": user_input} # 步骤1：规划 task_state["status"] = "PLANNING" plan = self.planner.plan(user_input) task_state["plan"] = plan task_state["status"] = "READY" # 步骤2：按序执行子任务 for sub_task in plan["sub_tasks"]: task_state["current_sub_task"] = sub_task task_state["status"] = "EXECUTING" skill = self.skill_registry.get_skill(sub_task["skill"]) if not skill: task_state["status"] = "FAILED" task_state["error"] = f"技能未找到: {sub_task['skill']}" break try: result = skill.execute(**sub_task["parameters"]) sub_task["result"] = result task_state["last_result"] = result except Exception as e: task_state["status"] = "FAILED" task_state["error"] = str(e) break # 步骤3：汇总与输出 if task_state["status"] == "EXECUTING": # 所有子任务成功执行完毕 task_state["status"] = "SUCCESS" final_output = self.summarizer.summarize(plan, task_state["last_result"]) return final_output else: return {"status": "FAILED", "error": task_state.get("error")}

上下文传递：子任务之间往往有数据依赖。比如，子任务A“查询北京明天天气”的结果，需要传递给子任务B“根据天气决定是否建议带伞”。执行引擎需要维护一个全局的上下文字典，存储每个子任务的输出，后续子任务可以引用这些值（例如通过{{sub_task_1.result}}这样的模板语法）。

实操心得：

一定要为工作流设计“断点续传”和“手动干预”的能力。复杂任务可能执行很久，如果中途失败或需要调整，能够从某个子任务重启，而不是从头开始，体验会好很多。同时，记录详细的执行日志，这对于调试和优化规划逻辑至关重要。

4. 从零搭建一个简易辅助AI Agent

理论说了这么多，我们来动手实现一个极简版的、具备分层组合性的AI助手。这个助手能理解“帮我查一下北京和上海的天气，然后告诉我哪里更暖和”这样的复合请求。

4.1 环境准备与依赖安装

我们使用Python，并选择OpenAI的GPT模型作为规划器的大脑（你也可以替换为其他兼容API的模型，如DeepSeek、通义千问等）。

# 创建项目目录并初始化虚拟环境 mkdir hierarchical_ai_agent && cd hierarchical_ai_agent python -m venv venv source venv/bin/activate # Linux/Mac # venv\Scripts\activate # Windows # 安装核心依赖 pip install openai python-dotenv requests

创建一个.env文件来存储你的OpenAI API密钥：

OPENAI_API_KEY=你的_api_key_here

4.2 核心代码实现

我们创建三个主要文件：skills.py（技能库），planner.py（规划器），agent.py（主引擎）。

1. 技能库 (skills.py)

import os import requests from typing import Dict, Any import json class Skill: """技能基类""" def __init__(self, name: str, description: str): self.name = name self.description = description def execute(self, **kwargs) -> Any: raise NotImplementedError class WebSearchSkill(Skill): """模拟网络搜索技能（实际可接入SerperAPI等）""" def __init__(self): super().__init__( name="web_search", description="使用搜索引擎查询信息。输入应为搜索关键词。" ) def execute(self, query: str) -> str: # 这里是模拟，实际应调用搜索引擎API print(f"[技能执行] 正在搜索: {query}") # 模拟返回结果 mock_results = { "北京天气": "北京：晴，15~25°C，微风。", "上海天气": "上海：多云，18~28°C，东南风3级。", "Python教程": "Python是一种高级编程语言..." } return mock_results.get(query, f"未找到关于'{query}'的明确信息。") class CalculatorSkill(Skill): """计算器技能（做了安全限制的简易版）""" def __init__(self): super().__init__( name="calculator", description="计算数学表达式的结果，支持加减乘除(+-*/)和括号。" ) def execute(self, expression: str) -> str: print(f"[技能执行] 正在计算: {expression}") # 非常基础的安全检查，实际应用需要更严格的沙箱 allowed_chars = set("0123456789+-*/(). ") if not all(c in allowed_chars for c in expression): return "错误：表达式包含非法字符。" try: # 使用eval有风险，仅用于演示。生产环境务必使用ast.literal_eval或更安全的计算库。 result = eval(expression, {"__builtins__": {}}, {}) return str(result) except Exception as e: return f"计算错误: {e}" class WeatherSkill(Skill): """天气查询技能（模拟）""" def __init__(self): super().__init__( name="get_weather", description="获取指定城市的天气信息。" ) def execute(self, city: str) -> str: print(f"[技能执行] 正在查询{city}的天气") # 模拟数据 weather_data = { "北京": "天气：晴，温度：15~25°C，湿度：40%，风向：北风微风。", "上海": "天气：多云，温度：18~28°C，湿度：65%，风向：东南风3级。", "深圳": "天气：阵雨，温度：22~30°C，湿度：85%，风向：南风4级。" } return weather_data.get(city, f"抱歉，暂未收录{city}的天气信息。") class SkillRegistry: """技能注册中心""" def __init__(self): self.skills: Dict[str, Skill] = {} def register(self, skill: Skill): self.skills[skill.name] = skill def get_skill(self, name: str) -> Skill: return self.skills.get(name) def get_skill_descriptions(self) -> str: """获取所有技能描述，用于构造提示词""" desc_list = [] for name, skill in self.skills.items(): desc_list.append(f"- {name}: {skill.description}") return "\n".join(desc_list) # 初始化技能注册表并注册技能 registry = SkillRegistry() registry.register(WebSearchSkill()) registry.register(CalculatorSkill()) registry.register(WeatherSkill())

2. 规划器 (planner.py)

import openai import json import os from dotenv import load_dotenv from skills import registry load_dotenv() client = openai.OpenAI(api_key=os.getenv("OPENAI_API_KEY")) class Planner: def __init__(self, model="gpt-3.5-turbo"): self.model = model def plan(self, user_input: str) -> dict: """调用LLM进行任务分解和规划""" system_prompt = f"""你是一个高效的任务规划AI。请将用户的请求分解为一系列顺序执行的子任务。 你可以调用的技能如下： {registry.get_skill_descriptions()} 请分析用户请求，并输出一个JSON格式的规划。JSON结构必须严格如下： {{ "original_task": "用户原始请求", "sub_tasks": [ {{ "id": 1, "description": "清晰描述第一个子任务要做什么", "skill": "技能名称，必须是上面列表中的一个", "parameters": {{"参数名": "参数值"}} // 参数必须严格匹配该技能所需的输入 }}, // ... 更多子任务 ] }} 注意：子任务之间可以有依赖，后一个任务可以使用前一个任务的结果（在参数中用‘前一个任务的结果’指代，执行引擎会处理）。请确保分解合理，技能选择准确。""" try: response = client.chat.completions.create( model=self.model, messages=[ {"role": "system", "content": system_prompt}, {"role": "user", "content": user_input} ], temperature=0.1, # 低温度保证输出稳定性 response_format={"type": "json_object"} # 要求返回JSON ) plan_json = response.choices[0].message.content plan = json.loads(plan_json) return plan except json.JSONDecodeError as e: print(f"LLM返回的JSON解析失败: {e}") print(f"原始返回: {plan_json}") # 返回一个兜底的简单规划 return { "original_task": user_input, "sub_tasks": [{ "id": 1, "description": user_input, "skill": "web_search", # 默认回退到搜索 "parameters": {"query": user_input} }] } except Exception as e: print(f"规划请求失败: {e}") return None

3. 智能体主引擎 (agent.py)

import json from planner import Planner from skills import registry class SimpleAgent: def __init__(self): self.planner = Planner() self.context = {} # 用于存储任务执行过程中的上下文信息 def run(self, user_input: str): print(f"\n=== 用户请求 ===") print(user_input) # 1. 规划 print(f"\n=== 任务规划中 ===") plan = self.planner.plan(user_input) if not plan: return "抱歉，任务规划失败。" print(f"规划结果: {json.dumps(plan, indent=2, ensure_ascii=False)}") # 2. 执行 print(f"\n=== 开始执行子任务 ===") all_results = [] for sub_task in plan.get("sub_tasks", []): task_id = sub_task.get("id") description = sub_task.get("description", "") skill_name = sub_task.get("skill", "") params = sub_task.get("parameters", {}) print(f"\n[子任务 {task_id}] {description}") print(f" 调用技能: {skill_name}, 参数: {params}") skill = registry.get_skill(skill_name) if not skill: print(f" 错误：未找到技能 '{skill_name}'") all_results.append(f"子任务{task_id}失败：技能不存在") break try: # 这里可以添加更复杂的参数预处理（例如，替换上下文变量） result = skill.execute(**params) print(f" 结果: {result}") # 将结果存入上下文，供后续任务引用（简单实现：按ID存储） self.context[f"task_{task_id}_result"] = result all_results.append(result) except Exception as e: print(f" 执行出错: {e}") all_results.append(f"子任务{task_id}执行失败：{e}") break # 3. 汇总 (这里简化处理，直接返回所有结果) print(f"\n=== 任务执行完毕 ===") final_output = f"原始任务：{plan['original_task']}\n\n执行结果汇总：\n" + "\n".join([f"- {r}" for r in all_results]) return final_output if __name__ == "__main__": agent = SimpleAgent() # 测试用例 test_queries = [ "北京和上海的天气怎么样？", "计算一下(15+27)*3等于多少？", "先查一下北京的天气，再查一下上海的天气，然后告诉我哪里温度更高。", ] for query in test_queries: result = agent.run(query) print(result) print("\n" + "="*50 + "\n")

4.3 运行与效果分析

运行python agent.py，你会看到类似以下的输出：

=== 用户请求 === 先查一下北京的天气，再查一下上海的天气，然后告诉我哪里温度更高。 === 任务规划中 === 规划结果: { "original_task": "先查一下北京的天气，再查一下上海的天气，然后告诉我哪里温度更高。", "sub_tasks": [ { "id": 1, "description": "查询北京市的天气情况", "skill": "get_weather", "parameters": { "city": "北京" } }, { "id": 2, "description": "查询上海市的天气情况", "skill": "get_weather", "parameters": { "city": "上海" } }, { "id": 3, "description": "比较北京和上海的温度，指出哪里更高", "skill": "calculator", "parameters": { "expression": "需要从天气结果中提取数字比较，这里LLM规划有瑕疵，实际应设计一个‘比较’技能或由LLM直接分析" } } ] } === 开始执行子任务 === [子任务 1] 查询北京市的天气情况 调用技能: get_weather, 参数: {'city': '北京'} [技能执行] 正在查询北京的天气 结果: 天气：晴，温度：15~25°C，湿度：40%，风向：北风微风。 [子任务 2] 查询上海市的天气情况 调用技能: get_weather, 参数: {'city': '上海'} [技能执行] 正在查询上海的天气 结果: 天气：多云，温度：18~28°C，湿度：65%，风向：东南风3级。 [子任务 3] 比较北京和上海的温度，指出哪里更高 调用技能: calculator, 参数: {'expression': '需要从天气结果中提取数字比较，这里LLM规划有瑕疵，实际应设计一个‘比较’技能或由LLM直接分析'} [技能执行] 正在计算: 需要从天气结果中提取数字比较，这里LLM规划有瑕疵，实际应设计一个‘比较’技能或由LLM直接分析 结果: 计算错误: invalid syntax (<string>, line 1) === 任务执行完毕 === 原始任务：先查一下北京的天气，再查一下上海的天气，然后告诉我哪里温度更高。 执行结果汇总： - 天气：晴，温度：15~25°C，湿度：40%，风向：北风微风。 - 天气：多云，温度：18~28°C，湿度：65%，风向：东南风3级。 - 子任务3执行失败：invalid syntax (<string>, line 1)

分析：我们的智能体成功地将复合请求分解成了三个子任务，并正确调用了前两个天气查询技能。然而，在第三个“比较”任务上失败了，因为LLM错误地选择了calculator技能，并生成了一个非数学表达式作为参数。这暴露了当前简单架构的一个关键问题：规划器的能力局限和技能匹配的误差。

5. 进阶优化与常见问题排查

上面的简易版暴露了不少问题，一个健壮的工业级Agent需要更多考量。

5.1 规划失败的优化策略

问题：LLM规划不合理或技能选择错误（如上例）。
解决方案：
1. 技能描述优化：为每个技能编写更精确、无歧义的描述，包括明确的输入输出示例。例如，calculator的描述应强调“仅用于纯数学表达式”。
2. 少样本示例（Few-shot）：在系统提示词中提供几个优秀的任务分解示例，引导LLM模仿。
3. 规划验证与重试：在正式执行前，可以加入一个“规划验证”步骤。例如，用另一个LLM调用或一套规则来检查规划的逻辑合理性和技能参数的有效性。如果验证失败，则让规划器重新生成。
4. 引入专业规划器模型：使用在任务分解上微调过的专用小模型，或者使用思维链（Chain-of-Thought）、思维树（Tree-of-Thoughts）等更高级的提示技术来提升规划质量。

5.2 技能执行中的常见坑

问题一：技能执行超时或崩溃。
- 排查：为每个技能设置超时限制（如signal或multiprocessing）。记录详细的错误日志，包括输入参数和执行环境信息。
- 解决：实现技能执行的隔离（如进程隔离），确保一个技能的崩溃不会导致整个Agent挂掉。对于失败的任务，根据策略决定重试、跳过还是上报。
问题二：技能返回结果格式不符合预期。
- 排查：在技能封装层就加入结果验证，使用output_schema（如JSON Schema）校验返回结构。
- 解决：对于不稳定的外部API，设计结果解析器和兜底逻辑。例如，天气API可能返回不同结构的数据，需要适配层来统一格式。
问题三：技能依赖或资源冲突。
- 排查：明确技能的资源需求（如需要网络、需要访问特定文件、需要GPU）。
- 解决：在技能注册时声明其依赖和资源需求。工作流引擎在执行时进行资源调度，避免冲突（例如，两个技能不能同时写入同一个文件）。

5.3 上下文管理与数据流

问题：子任务间如何传递数据？如上例，任务3需要任务1和2的结果。
解决方案：设计一个上下文管理器。它维护一个键值存储，子任务的结果可以存入（如weather_beijing: “15~25°C”）。后续子任务的参数可以支持模板变量，如“请比较{{weather_beijing}}和{{weather_shanghai}}的温度”。在执行前，引擎负责将模板变量替换为实际值。这比依赖LLM在参数中模糊描述要可靠得多。

5.4 评估与迭代

如何知道你的Agent变强了？你需要一套评估体系。

构建测试集：覆盖各种类型的用户请求（简单、复合、边界、模糊）。
定义评估指标：
- 任务完成率：有多少比例的任务被正确分解并执行完毕？
- 技能调用准确率：规划器选择的技能是否正确？
- 结果满意度（人工或模型评估）：最终输出是否真正解决了用户问题？
持续迭代：根据评估结果，有针对性地优化提示词、技能描述、增加新技能或改进错误处理逻辑。

6. 项目扩展与未来方向

当你掌握了基础的分层组合性AI Agent构建方法后，可以考虑以下几个扩展方向，让你的助手变得更强大：

动态技能学习：允许Agent在运行时发现新的API或工具，并通过阅读文档自动生成该技能的描述和调用方式，注册到技能库中。这需要结合代码生成和API Schema理解能力。
多智能体协作：将复杂的子任务进一步委托给更专业的“子智能体”去完成。主Agent充当协调者，子Agent们各司其职（如一个专精数据分析，一个专精文本撰写），它们之间通过消息传递进行协作。框架如AutoGen专门为此设计。
长期记忆与个性化：为Agent配备向量数据库，存储每次交互的历史和重要信息。当用户再次提出相关请求时，Agent可以“记得”之前的对话和用户的偏好，提供更个性化的服务。
人类在环（Human-in-the-loop）：对于关键决策或不确定的任务，让Agent学会主动向用户提问或请求确认。例如，“您说的‘优化财务’是指减少开支，还是增加投资？我需要更明确的目标才能继续。”
可解释性与可控性：提供可视化的工作流界面，让用户能看到Agent的“思考过程”（规划树），并能在关键节点进行干预、修改参数或否决某项操作，增加用户对AI的信任感和控制感。

构建一个真正智能、实用的辅助AI Agent是一个持续迭代的过程。分层组合性提供了清晰的设计蓝图，但每一步都充满了工程细节的挑战。从我个人的经验来看，起步时不要追求大而全，从一个能解决你实际工作中某个具体痛点的小任务开始（比如自动整理日报、智能回复常见邮件），逐步扩展其能力边界，你会对这套架构的价值有更深刻的理解。记住，最好的AI Agent不是最复杂的那个，而是最能无缝融入你的工作流、安静可靠地帮你解决问题的那个伙伴。