AI智能体技能开发：从头脑风暴到工程实现的全链路解析

1. 从“头脑风暴”到“智能体技能”：一场认知与工程的深度对话

“Brainstorming”这个词，我们太熟悉了。一提到它，脑海里立刻浮现出会议室白板前一群人七嘴八舌、火花四溅的场景。它是一种经典的创意激发方法，核心在于通过自由联想和集体讨论，无评判地产生大量想法，以期找到问题的创新解决方案。然而，当这个词与“深度解析”结合，并伴随着“agent”、“skill”、“design”、“implementation”等一系列技术热词出现时，它所指向的就不再是传统意义上的团队会议技巧，而是一场发生在人工智能，特别是智能体（Agent）领域内的深刻范式变革。我们今天要探讨的，正是这种将人类“头脑风暴”的思维过程，转化为AI智能体可执行、可组合、可设计的“技能”（Skill）的完整链路。这不仅仅是概念的迁移，更是一套从设计思想到工程落地的系统性方法论，关乎我们如何构建下一代更智能、更灵活、更具创造性的AI应用。

简单来说，我们可以把传统的“头脑风暴”看作是一次性的、非结构化的灵感迸发。而“Brainstorming Skill”则意味着，我们将这种灵感迸发的“能力”进行了抽象、封装和标准化，使其成为一个可以被AI智能体反复调用、与其他能力组合、并根据不同场景进行优化的“标准化组件”。这背后的驱动力，是当前AI Agent开发的核心痛点：我们不再满足于拥有一个只会执行单一指令的“工具”，而是需要一个能够像人类专家一样，自主理解任务、拆解问题、调用多种能力、并创造性解决问题的“合作伙伴”。要实现这一点，智能体必须拥有一套丰富、可靠且易于管理的“技能库”，而“技能”的设计与实现，就成了连接智能体“大脑”（决策与规划）与“手脚”（具体执行）的关键桥梁。无论你是关注Hermes Agent、AutoGen、LangChain等具体框架的开发者，还是对AI应用产品设计（Product Design）感兴趣的产品经理，亦或是正在学习如何将创意转化为代码的工程师，理解这套从“头脑风暴”到“技能实现”的完整逻辑，都至关重要。

2. 核心理念拆解：为什么“技能化”是智能体的必然进化？

要理解“Brainstorming 深度解析”的现代内涵，我们必须先跳出会议室的局限，从智能体架构的顶层设计来看待“技能”这个概念。你可以把一个高级的AI智能体想象成一家专业的咨询公司。这家公司的核心价值不在于它拥有多少员工，而在于它能够为客户提供哪些专业的“服务”，比如市场分析、财务建模、战略规划等。这里的每一项“服务”，就是一个“技能”。

2.1 从“功能”到“技能”：认知维度的升级

在传统的软件或简单AI工具中，我们实现的是“功能”（Function）。一个功能是明确的、输入输出固定的、逻辑确定的。例如，一个“天气查询”功能，输入城市名，输出天气数据。它没有“理解”能力，只是执行预设的代码逻辑。

而“技能”（Skill）则是一个更高阶的封装。它不仅仅包含执行逻辑，更包含了：

• 意图理解：技能需要能理解用户模糊或复杂的请求。当用户说“帮我策划一个周末露营活动”时，这背后可能涉及天气查询、地点推荐、装备清单、食谱规划等多个子任务的“头脑风暴”与整合。一个“活动策划”技能需要先理解这个核心意图。
• 上下文感知：技能的执行依赖于当前的对话历史、用户偏好、环境信息等上下文。同样的“写一首诗”技能，根据上下文是写给爱人的情诗还是描写景物的山水诗，其产出风格截然不同。
• 过程性与创造性：技能内部可以包含决策、试错、优化等过程。一个“头脑风暴技能”本身就是过程性的：它需要定义主题、生成大量关联想法、对想法进行聚类筛选、最后提炼出核心方案。这模仿了人类的创造性思维流程。
• 可组合性：复杂的任务往往需要多个技能协同工作。一个“产品设计提案”技能，可能会依次或并行调用“市场调研”、“竞品分析”、“创意头脑风暴”、“原型草图生成”和“文档撰写”等多个子技能。

因此，将“头脑风暴”这种复杂认知活动“技能化”，本质是为智能体装备了“创造性解决问题”的标准化模块。它让智能体不再只是信息的检索器和简单的执行器，而是具备了初步的“思考”和“构思”能力。

2.2 “Design”与“Implementation”的双重挑战

在热词中反复出现的“design”和“implementation”，恰恰点明了构建一个优秀技能的两个核心阶段，也是开发者面临的主要挑战。

1. 技能设计（Skill Design）：定义技能的“灵魂”这关乎技能是什么、能做什么、以及如何与其他部分交互。它回答的是“Why”和“What”的问题。

• 接口设计（Interface Design）：技能如何被触发？输入参数是什么？（例如，头脑风暴技能可能需要输入“主题”、“期望想法数量”、“创意方向约束”）。输出格式是什么？（是列表、树状图、还是结构化JSON？）。这就像为技能设计一个清晰的“产品说明书”。
• 流程设计（Process Design）：技能内部的工作流是怎样的？对于“头脑风暴技能”，其流程可能分为：a) 解析主题并生成种子关键词；b) 基于种子词进行多轮联想扩展；c) 应用创意模板（如SCAMPER法）生成变体；d) 对生成的想法进行去重、分类和初步评分。这个流程设计直接决定了技能的质量和创造性。
• 上下文设计（Context Design）：技能需要访问哪些外部知识或状态？它是否需要记忆之前的 brainstorming 结果？是否需要调用网络搜索API来获取灵感？是否需要参考用户的个人知识库？

2. 技能实现（Skill Implementation）：打造技能的“躯体”这关乎如何用代码将设计落地，回答的是“How”的问题。这里会遇到大量工程细节，正如热词中提到的implementation "com.github.pedrosg94.rootencoder:library:2.6.5和unresolved reference 'implementation'.所暗示的，这通常涉及具体的依赖管理、框架集成和编码实践。

• 框架选择：你是基于 LangChain 的 Tool/Agent 来封装技能，还是使用 AutoGen 的 AssistantAgent 来定义，抑或是为 Hermes Agent 编写特定的 Skill 插件？不同的框架有各自的抽象和接入方式。
• 依赖管理：技能可能需要特定的模型（如 GPT-4 用于创意生成， Claude 用于逻辑梳理）、第三方库（如用于数据处理的 pandas，用于绘图的 matplotlib）或自定义模块。如何清晰管理这些依赖，避免版本冲突（如那个未解决的implementation引用错误，常出现在 Gradle 或 Maven 配置中），是工程稳健性的基础。
• 性能与可靠性：技能的执行时间多长？是否支持异步？出错后如何降级处理？对于“头脑风暴”这类可能调用大模型多次交互的技能，还需要考虑令牌（Token）消耗优化和速率限制（Rate Limit）规避。

3. 构建一个“头脑风暴”技能：从设计到实现的全流程实操

理论说得再多，不如动手构建一个。下面，我将以一个“产品功能创意头脑风暴”技能为例，详细拆解从设计到实现的全过程。我们假设这个技能将被集成到一个产品经理辅助AI智能体中。

3.1 技能蓝图设计：明确规格与边界

首先，我们需要为这个技能绘制一份清晰的蓝图。

技能名称：ProductFeatureBrainstormingSkill核心目标：针对给定的产品领域和核心用户需求，生成一系列新颖、可行、有商业价值的产品功能创意点。输入（Input）：

• product_domain(字符串，必需): 产品领域，如“在线教育”、“健康管理”、“智能家居”。
• user_pain_point(字符串，必需): 核心用户痛点或需求，如“学习难以坚持”、“睡眠质量差”、“家电能耗高”。
• constraints(字符串列表，可选): 约束条件，如[“技术可行性高”、“开发成本低”、“移动端优先”]。
• idea_count(整数，默认值10): 期望生成的想法数量。

输出（Output）：

• 一个结构化的JSON数组，每个元素代表一个功能创意点，包含以下字段：
  • id: 唯一标识。
  • title: 创意点名称。
  • description: 详细描述。
  • rationale: 创意背后的理由或解决的子痛点。
  • feasibility_score: 可行性初步评分（1-5）。
  • innovation_score: 创新性初步评分（1-5）。

内部流程设计：

1. 阶段一：背景分析与种子生成。技能首先会分析product_domain和user_pain_point，结合领域知识，生成3-5个核心的“创意方向”或“种子概念”。例如，对于“在线教育”和“学习难以坚持”，种子概念可能是“游戏化”、“社交激励”、“微学习”、“自适应路径”。
2. 阶段二：多维度联想发散。针对每个种子概念，从多个维度进行联想发散：
   • 用户场景维度：在通勤、睡前、周末等不同场景下，这个功能如何呈现？
   • 技术赋能维度：结合AI、AR、大数据、IoT，能产生什么新玩法？
   • 商业模式维度：如何与订阅制、积分兑换、跨界合作结合？
3. 阶段三：创意结构化与筛选。将发散出的所有点子进行去重、合并，并应用constraints进行初步过滤。然后，使用大模型（如GPT-4）根据feasibility和innovation两个维度，对每个点子进行简要评估并打分。
4. 阶段四：格式化输出。将最终筛选出的idea_count个点子，按照规定的JSON格式进行整理输出。

设计心得：在技能设计阶段，切忌贪大求全。一个技能最好只解决一个核心问题。我们的“头脑风暴”技能聚焦于“生成创意”，而不负责“深度评估”或“原型设计”，后者可以交给其他技能。清晰的边界是技能可组合性的前提。

3.2 工程实现：以Python与LangChain为例

接下来，我们进入实现环节。这里选择相对流行的LangChain框架作为基础，因为它提供了良好的工具（Tool）抽象和与大模型交互的能力。

第一步：环境准备与依赖管理创建一个新的Python虚拟环境是良好实践的开始。我们的技能主要依赖以下库：

# requirements.txt langchain>=0.1.0 langchain-openai # 用于接入OpenAI模型 pydantic>=2.0.0 # 用于结构化数据验证 tenacity # 用于重试逻辑，提高健壮性

使用pip install -r requirements.txt安装。这里特别要注意版本兼容性，尤其是LangChain版本迭代较快，API可能有变动。这就是热词中unresolved reference类问题在Python领域的体现——确保你的IDE正确配置了解释器，并且导入的模块名与安装的包名一致。

第二步：定义技能工具（Tool）在LangChain中，技能通常被封装为一个“Tool”。我们需要定义工具的输入Schema和执行函数。

from typing import List, Optional, Type from pydantic import BaseModel, Field from langchain.tools import BaseTool, Tool from langchain_openai import ChatOpenAI from langchain.prompts import ChatPromptTemplate from langchain.output_parsers import PydanticOutputParser import json import asyncio from tenacity import retry, stop_after_attempt, wait_exponential # 1. 定义输入模型 class BrainstormingInput(BaseModel): product_domain: str = Field(description="The domain of the product, e.g., 'Fitness App', 'E-commerce Platform'") user_pain_point: str = Field(description="The core user pain point or need to address.") constraints: Optional[List[str]] = Field(default=None, description="Optional list of constraints, e.g., ['low cost', 'mobile-first']") idea_count: int = Field(default=10, ge=1, le=50, description="Number of ideas to generate, between 1 and 50.") # 2. 定义输出模型（单个想法） class FeatureIdea(BaseModel): id: int title: str description: str rationale: str feasibility_score: int = Field(ge=1, le=5) innovation_score: int = Field(ge=1, le=5) class BrainstormingOutput(BaseModel): ideas: List[FeatureIdea] # 3. 创建技能工具类 class ProductFeatureBrainstormingTool(BaseTool): name: str = "product_feature_brainstorming" description: str = """Useful for generating innovative product feature ideas based on a domain and user pain point. Input must include 'product_domain' and 'user_pain_point'. 'constraints' and 'idea_count' are optional.""" args_schema: Type[BaseModel] = BrainstormingInput return_direct: bool = False # 设为True则直接返回结果，不经过Agent思考 llm: ChatOpenAI = None def __init__(self, llm: ChatOpenAI, **kwargs): super().__init__(**kwargs) self.llm = llm # 初始化输出解析器 self.output_parser = PydanticOutputParser(pydantic_object=BrainstormingOutput) # 构建提示词模板 self.prompt_template = ChatPromptTemplate.from_messages([ ("system", """You are a creative product strategist. Your task is to brainstorm product feature ideas. Follow these steps internally: 1. Analyze the product domain and user pain point to identify 3-5 core seed directions. 2. For each seed, brainstorm ideas from angles: user scenario, technology enablement, business model. 3. Filter and combine ideas based on constraints (if any). 4. Evaluate each idea briefly on feasibility and innovation (1-5 scale). Output MUST be a valid JSON object matching this schema: {format_instructions} """), ("human", "Product Domain: {product_domain}\nUser Pain Point: {user_pain_point}\nConstraints: {constraints}\nNumber of Ideas: {idea_count}") ]).partial(format_instructions=self.output_parser.get_format_instructions()) @retry(stop=stop_after_attempt(3), wait=wait_exponential(multiplier=1, min=4, max=10)) def _run(self, product_domain: str, user_pain_point: str, constraints: Optional[List[str]] = None, idea_count: int = 10) -> str: """同步执行方法""" # 准备约束条件字符串 constraints_str = ", ".join(constraints) if constraints else "None" # 构建最终提示词 prompt = self.prompt_template.format_prompt( product_domain=product_domain, user_pain_point=user_pain_point, constraints=constraints_str, idea_count=idea_count ) # 调用大模型 response = self.llm.invoke(prompt.to_messages()) try: # 解析输出 parsed_output: BrainstormingOutput = self.output_parser.parse(response.content) # 转换为JSON字符串返回（LangChain Agent通常处理字符串） return json.dumps([idea.dict() for idea in parsed_output.ideas], ensure_ascii=False, indent=2) except Exception as e: # 解析失败，返回原始内容或错误信息 return f"Error parsing LLM output: {e}. Raw output:\n{response.content}" async def _arun(self, *args, **kwargs): """异步执行方法 - 这里简单封装，实际生产环境需更完善""" # 对于CPU密集型或简单LLM调用，可以直接调用同步方法（注意在异步环境中可能阻塞事件循环） # 更佳实践是使用LangChain的异步LLM接口 return await asyncio.to_thread(self._run, *args, **kwargs)

第三步：集成与测试现在，我们可以将这个工具集成到一个简单的Agent中，并进行测试。

# 初始化大模型 from langchain_openai import ChatOpenAI llm = ChatOpenAI(model="gpt-4-turbo-preview", temperature=0.7) # temperature稍高以鼓励创造性 # 创建工具实例 brainstorm_tool = ProductFeatureBrainstormingTool(llm=llm) # 创建一个简单的Agent（这里使用最简单的Tool Calling Agent） from langchain.agents import initialize_agent, AgentType from langchain.agents.agent_toolkits import create_conversational_retrieval_agent # 假设我们只有一个工具 tools = [brainstorm_tool] # 使用零样本ReAct代理 agent = initialize_agent( tools, llm, agent=AgentType.ZERO_SHOT_REACT_DESCRIPTION, verbose=True, # 打印思考过程，便于调试 handle_parsing_errors=True # 优雅处理解析错误 ) # 进行测试 test_result = agent.run( "I'm working on a fitness app. Users often struggle with staying motivated to work out alone. Give me 5 feature ideas that are mobile-first and low-cost to develop." ) print(test_result)

实现避坑指南：

1. 提示词工程是关键：_run方法中的prompt_template是技能质量的灵魂。你需要反复调试系统提示词（System Prompt），明确告诉模型思考步骤和输出格式。使用PydanticOutputParser可以强制结构化输出，但模型有时仍会“胡言乱语”，因此必须有健壮的异常处理（try...except块）。
2. 管理LLM调用成本与稳定性：使用@retry装饰器应对偶发的API超时或限流。对于付费API，要在提示词中控制生成内容的长度，并在代码层面设置max_tokens上限，避免意外的高额费用。
3. 异步支持：即使当前用不到，也最好实现_arun方法，为将来集成到异步框架（如FastAPI后端）留有余地。注意，直接调用同步的llm.invoke在异步环境中可能阻塞，生产环境应使用llm.ainvoke。
4. 工具描述要精准：description字段是Agent决定是否调用该工具的依据。务必清晰、简洁地说明工具的用途和输入要求。

4. 技能生态与高级话题：超越单技能的实现

当我们成功实现了一个基础技能后，就进入了更广阔的“技能生态”领域。这正是热词中agent skill、skill开发、skill可组合性所指向的更深层次问题。

4.1 技能的组合与编排：构建工作流

单个“头脑风暴”技能价值有限，但当它能与其他技能串联时，威力倍增。例如，一个完整的产品创意分析工作流可能是：

1. 调用“市场趋势分析”技能，获取当前领域热点。
2. 调用“竞品功能调研”技能，分析现有解决方案。
3. 调用我们的“产品功能头脑风暴”技能，生成新创意。
4. 调用“概念评估与优先级排序”技能，对创意进行更细致的商业和技术评估。
5. 调用“产品需求文档（PRD）生成”技能，将高优先级创意转化为初步文档。

这种编排可以通过两种主要方式实现：

• 智能体主导的编排：由一个主控Agent（如使用ReAct或Plan-and-Execute模式的Agent）根据目标动态决定调用哪个技能。这需要Agent有较强的规划和工具调用能力。
• 工作流引擎主导的编排：使用像LangGraph、Prefect或甚至简单的Python脚本，预先定义好技能的执行顺序和条件分支。这种方式更确定、易于调试。

# 一个简单的工作流脚本示例 def product_ideation_workflow(domain, pain_point): # 1. 趋势分析 (假设有其他技能工具) # trend_data = trend_analysis_tool.run(domain=domain) # 2. 头脑风暴 ideas_json = brainstorm_tool.run( product_domain=domain, user_pain_point=pain_point, constraints=["mobile-first", "data-driven"], idea_count=8 ) ideas = json.loads(ideas_json) # 3. 深度评估 (假设有评估技能) # evaluated_ideas = [] # for idea in ideas: # evaluation = deep_evaluation_tool.run(feature_idea=idea['description'], domain=domain) # evaluated_ideas.append({**idea, **evaluation}) # 4. 排序并返回Top 3 # 简单按创新分排序 top_ideas = sorted(ideas, key=lambda x: x['innovation_score'], reverse=True)[:3] return top_ideas

4.2 技能的管理、发现与共享

当技能数量增多时，如何管理它们就成了问题。这引向了“Skill Registry”（技能注册中心）或“Skill Store”（技能商店）的概念。理想的技能生态应该包含：

• 标准化描述：每个技能应有统一的元数据描述文件（如skill.yaml），包含名称、版本、作者、输入输出Schema、依赖项、示例等。
• 版本控制：技能需要版本化，以便依赖它的Agent或工作流能明确指定版本，避免兼容性问题。
• 动态发现与加载：Agent在运行时能够从本地或远程的注册中心发现并加载所需的技能，无需硬编码。这类似于微服务中的服务发现。
• 安全与权限：对于执行敏感操作（如发送邮件、访问数据库）的技能，需要有明确的权限控制和执行沙箱。

目前，像Hermes Agent等框架正在探索这类技能管理机制。虽然尚未形成统一标准，但这是构建大规模、可复用智能体应用的必然方向。

4.3 技能的学习与进化

最高阶的技能，是具备“学习”能力的技能。这不仅仅是依赖底层大模型的泛化能力，而是指技能本身能根据执行反馈进行优化。例如：

• 基于反馈的提示词优化：如果“头脑风暴”技能生成的创意多次被用户评为“不切实际”，系统可以自动调整其提示词，增加“注重可行性”的权重，或引入新的约束条件。
• 技能参数的自适应：技能内部的一些参数（如生成想法的“发散度”、“保守度”）可以根据历史成功率进行动态调整。
• 技能组合的自动探索：通过强化学习，让Agent自动尝试不同的技能组合顺序来解决新问题，并将成功的工作流沉淀为新的“复合技能”。

这涉及到更复杂的AI工程和机器学习运维（MLOps）实践，是当前研究的前沿。

5. 实战中常见问题与排查技巧实录

在实际开发和集成技能的过程中，你会遇到各种各样的问题。下面是我从多个项目中总结出的“避坑”清单。

5.1 大模型相关的问题

问题1：输出格式不稳定，经常不按JSON返回。

• 现象：你定义了Pydantic模型并要求返回JSON，但模型有时会返回纯文本描述，导致解析失败。
• 根因：提示词不够强硬，或者模型（特别是较低温度或较弱模型）倾向于生成更“自然”的语言。
• 解决方案：
  1. 强化系统提示词：在系统提示词开头使用“你必须”、“只能”等强指令。例如：“你必须且只能输出一个符合以下JSON Schema的JSON对象，不要有任何其他解释或文本。”
  2. 使用结构化输出专用库：除了PydanticOutputParser，可以尝试LangChain的StructuredOutputParser，或OpenAI API原生的response_format={ "type": "json_object" }参数（如果模型支持）。
  3. 后处理清洗：在解析前，用简单的正则表达式（如r'```json\n([\s\S]*?)\n```'）尝试从返回文本中提取JSON块。
  4. 降级方案：如果解析失败，可以尝试让模型“修复”自己的输出。即，将错误的输出和Schema再次发给模型，要求它纠正。

问题2：技能执行时间过长或Token消耗巨大。

• 现象：一个简单的头脑风暴技能调用耗时超过30秒，或者消耗了数千个Token。
• 根因：提示词过于冗长，或者要求模型执行的“内部步骤”太多，导致其生成了非常长的思考链（Chain-of-Thought）。
• 解决方案：
  1. 精简提示词：删除不必要的礼貌用语和重复说明。用最简洁的语言表达要求。
  2. 分步调用：将复杂的技能拆分成多个子技能依次调用。例如，先调用一个“生成创意方向”的技能，再针对每个方向调用“发散具体想法”的技能。虽然调用次数增加，但每次的提示词更简单、目标更明确，总耗时和Token消耗可能更低，且更易于调试。
  3. 设置明确限制：在提示词中明确要求“用不超过5句话描述每个想法”、“每个理由不超过50字”。
  4. 选择合适模型：对于创意生成，gpt-3.5-turbo可能比gpt-4更快、更便宜，且效果足够。需要进行效果与成本的权衡测试。

5.2 工程与集成问题

问题3：unresolved reference 'implementation'或类似导入错误。

• 现象：在IDE中看到红色波浪线，或者运行时ModuleNotFoundError。
• 根因：这是典型的依赖管理或环境配置问题。可能是包未安装、版本不匹配、虚拟环境未激活、或IDE未正确设置Python解释器路径。
• 排查流程：
  1. 确认环境：在终端执行which python或pip --version，确认当前环境是项目所用的虚拟环境。
  2. 检查安装：运行pip list | grep -i langchain查看相关包是否已安装及版本。
  3. 核对导入语句：LangChain版本更新可能导致模块路径变化。查阅当前安装版本的官方文档，核对import语句是否正确。例如，早期版本的langchain.llms可能在后续版本中变为langchain_community.llms或langchain_openai。
  4. 重启IDE/内核：有时IDE的索引缓存会导致误报，重启可以解决。

问题4：技能在Agent中从未被调用。

• 现象：你创建了工具并给了Agent，但Agent总是用自己的语言回答，而不触发工具调用。
• 根因：Agent的“决策”部分（通常是LLM）认为不需要调用工具，或者工具的描述不够匹配用户查询。
• 解决方案：
  1. 优化工具描述：确保Tool的name和description字段清晰、准确，包含可能触发该任务的关键词。例如，“brainstorming”比“generate ideas”更具体。
  2. 调整Agent类型：ZERO_SHOT_REACT_DESCRIPTION适用于简单场景。对于复杂任务，可以尝试OPENAI_FUNCTIONS或OPENAI_MULTI_FUNCTIONSAgent类型，它们对工具调用的支持更直接。
  3. 在提示词中引导：在给Agent的系统提示词中，明确鼓励它使用工具。例如：“你拥有以下工具来帮助你完成任务。在回答问题时，请优先考虑是否可以使用这些工具来获得更准确或更丰富的信息。”
  4. 开启详细模式：初始化Agent时设置verbose=True，观察Agent的思考链（ReAct），看它是否考虑了工具但最终决定不用，还是完全忽略了工具。这能提供宝贵的调试信息。

5.3 设计逻辑问题

问题5：技能生成的创意缺乏多样性或总是很平庸。

• 现象：多次运行技能，得到的想法大同小异，缺乏惊喜。
• 根因：提示词或流程设计限制了思维的“发散度”，或者种子生成阶段过于单一。
• 优化策略：
  1. 引入随机性：在生成种子概念时，不仅从“用户痛点”出发，还可以随机引入一些不相关的“刺激词”（如“太空”、“区块链”、“社区”），进行强制联想，往往能产生意想不到的组合创新。
  2. 使用创意模板：在提示词中内置经典的创意方法模板，如SCAMPER（替代、合并、适应、修改、用其他用途、消除、重组）、逆向思维法等，要求模型应用这些模板来变形初始想法。
  3. 多模型投票：同时调用多个不同的大模型（如GPT-4, Claude, Gemini）生成创意，然后去重合并，可以汇集不同模型的“思维风格”。
  4. 调整温度参数：适当提高LLM调用的temperature参数（如从0.7调到0.9），可以增加输出的随机性和创造性，但需注意可能降低一致性。

构建一个高效、可靠的“头脑风暴”技能乃至整个技能体系，是一个持续迭代和优化的过程。它一半是艺术（设计创意流程和提示词），一半是科学（工程实现和调试）。从理解“技能”作为智能体核心组件的哲学意义开始，到精心设计其输入输出与内部流程，再到用扎实的代码将其实现并妥善处理各种边界情况，最后思考如何让它与其他技能协同进化——这条路径，正是当前AI Agent开发从玩具走向生产力的核心赛道。每一次你解决一个unresolved reference错误，每一次你通过优化提示词让创意质量提升，都是在为智能体增添一块真正有用的“肌肉”。