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( namecalculator, description计算一个数学表达式的结果支持加减乘除和括号。, funccalculate, 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_here4.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__( nameweb_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__( namecalculator, 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__( nameget_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_keyos.getenv(OPENAI_API_KEY)) class Planner: def __init__(self, modelgpt-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( modelself.model, messages[ {role: system, content: system_prompt}, {role: user, content: user_input} ], temperature0.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(fLLM返回的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 None3. 智能体主引擎 (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, indent2, ensure_asciiFalse)}) # 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[ftask_{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 [ 北京和上海的天气怎么样, 计算一下(1527)*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规划不合理或技能选择错误如上例。解决方案技能描述优化为每个技能编写更精确、无歧义的描述包括明确的输入输出示例。例如calculator的描述应强调“仅用于纯数学表达式”。少样本示例Few-shot在系统提示词中提供几个优秀的任务分解示例引导LLM模仿。规划验证与重试在正式执行前可以加入一个“规划验证”步骤。例如用另一个LLM调用或一套规则来检查规划的逻辑合理性和技能参数的有效性。如果验证失败则让规划器重新生成。引入专业规划器模型使用在任务分解上微调过的专用小模型或者使用思维链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不是最复杂的那个而是最能无缝融入你的工作流、安静可靠地帮你解决问题的那个伙伴。