Skip to content

metagpt----ext----aflow----scripts----prompts----prompt.py.md

Latest commit

 

History

History
200 lines (112 loc) · 11.8 KB

metagpt----ext----aflow----scripts----prompts----prompt.py.md

File metadata and controls

200 lines (112 loc) · 11.8 KB

.\MetaGPT\metagpt\ext\aflow\scripts\prompts\prompt.py 详细设计文档

该文件定义了一系列用于指导大语言模型（LLM）进行问题求解、代码生成、答案验证和方案评估的提示词模板。这些模板构成了一个多步骤推理框架的核心，支持从问题分析、代码实现、测试反思到方案择优的完整流程。

整体流程

graph TD
    A[用户输入问题] --> B{选择处理流程}
    B --> C[使用ANSWER_GENERATION_PROMPT进行逐步推理]
    B --> D[使用PYTHON_CODE_VERIFIER_PROMPT生成可执行代码]
    B --> E[使用REFLECTION_ON_PUBLIC_TEST_PROMPT分析失败测试]
    B --> F[使用REVIEW_PROMPT审核解决方案]
    C --> C1[输出思考过程和最终答案]
    D --> D1[输出包含solve函数的Python代码]
    E --> E1[输出反思和改进后的代码]
    F --> F1[输出审核结果(True/False)和反馈]
    G[多个解决方案] --> H{选择集成策略}
    H --> I[使用SC_ENSEMBLE_PROMPT基于一致性投票]
    H --> J[使用MD_ENSEMBLE_PROMPT基于能力择优]
    I --> I1[输出最一致的方案ID]
    J --> J1[输出最有能力的方案ID]
    K[被审核为错误的方案] --> L[使用REVISE_PROMPT进行修订]
    L --> L1[输出修订后的代码]
    M[原始解决方案] --> N[使用FORMAT_PROMPT提取简洁答案]
    N --> N1[输出仅包含关键词的答案]
Loading

类结构

该文件不包含类定义，仅包含全局字符串常量（提示词模板）。
所有内容均为模块级变量。

全局变量及字段

ANSWER_GENERATION_PROMPT

用于指导模型分步思考并生成最终答案的提示词模板。

类型：str

FORMAT_PROMPT

用于从解决方案中提取简短、精炼答案的提示词模板。

类型：str

SC_ENSEMBLE_PROMPT

用于在多个解决方案中通过一致性（如投票）选择最可靠答案的提示词模板。

类型：str

PYTHON_CODE_VERIFIER_PROMPT

用于指导模型根据数学问题生成完整、可独立运行的Python代码的提示词模板。

类型：str

REFLECTION_ON_PUBLIC_TEST_PROMPT

用于指导模型分析代码在测试中失败的原因并提出改进方案的提示词模板。

类型：str

MD_ENSEMBLE_PROMPT

用于在多个解决方案中评估并选择最可能解决问题的方案的提示词模板。

类型：str

REVIEW_PROMPT

用于指导模型以批判性思维审查解决方案正确性并返回布尔结果的提示词模板。

类型：str

REVISE_PROMPT

用于指导模型根据审查反馈修订错误解决方案并生成正确Python代码的提示词模板。

类型：str

全局函数及方法

关键组件

提示词模板系统

定义了多个用于指导大语言模型（LLM）进行代码生成、答案提取、方案评估和代码审查等任务的标准化提示词模板。

代码生成与验证提示词

包含 ANSWER_GENERATION_PROMPT 和 PYTHON_CODE_VERIFIER_PROMPT，用于引导LLM生成分步思考过程、最终答案以及符合特定格式要求的、可独立运行的Python代码。

答案提取与格式化提示词

包含 FORMAT_PROMPT，用于从一段较长的解决方案文本中精确提取出简短、格式化的最终答案。

方案集成与选择策略

包含 SC_ENSEMBLE_PROMPT 和 MD_ENSEMBLE_PROMPT，定义了两种不同的集成策略：一种基于答案出现频率（一致性），另一种基于解决方案的解决能力（择优），用于从多个候选方案中选择最优解。

代码审查与迭代优化流程

包含 REVIEW_PROMPT、REFLECTION_ON_PUBLIC_TEST_PROMPT 和 REVISE_PROMPT，构成了一个完整的代码质量保障循环：首先对解决方案进行置信度审查，然后对测试失败的代码进行根因分析和反思，最后基于反馈对错误的解决方案进行修订和重写。

问题及建议

已知问题

  • 硬编码的提示词模板：所有提示词模板都以硬编码字符串的形式存储在模块中。这导致模板内容难以修改、扩展或根据不同环境（如不同语言、不同模型）进行定制，增加了维护成本。
  • 缺乏结构化验证：提示词模板中包含了期望的输出格式（如 "thought" 和 "answer" 字段），但代码本身没有提供任何机制来验证大语言模型（LLM）的输出是否符合这些格式要求，可能导致下游处理逻辑出错。
  • 潜在的模板注入风险：部分提示词模板（如 ANSWER_GENERATION_PROMPT、FORMAT_PROMPT）直接使用 {input}、{problem_description} 等占位符，并通过字符串格式化填充。如果用户输入内容包含特殊字符或恶意构造的字符串，可能干扰提示词的预期结构，尽管风险较低，但仍需注意。
  • 代码可读性与维护性：所有提示词集中在一个文件中，随着数量增加，文件会变得冗长，难以快速定位和修改特定提示词。缺少对每个提示词用途、输入输出格式的详细注释或文档。
  • 重复的模式：多个提示词（如 SC_ENSEMBLE_PROMPT 和 MD_ENSEMBLE_PROMPT）在结构上高度相似（都包含 {question} 和 {solutions} 占位符，并要求在 "thought" 和 "solution_letter" 字段输出），但没有被抽象为可复用的基础模板，存在代码重复。

优化建议

  • 外部化配置提示词：将提示词模板移至外部配置文件（如 JSON、YAML）或数据库。这样可以实现动态加载、环境隔离（开发/生产）、以及更方便的版本管理和A/B测试。
  • 引入提示词构建与验证层：创建一个 PromptBuilder 类或函数集，负责安全地组装提示词（如转义用户输入中的特殊字符）并验证LLM返回的结果结构是否符合预期（例如，检查是否包含必需的字段）。这能提高系统的健壮性。
  • 模块化与分类管理：根据功能（如“答案生成”、“代码验证”、“反思与修订”）将提示词拆分到不同的子模块或类中。每个类可以管理一组相关的提示词，并提供更清晰的接口和文档。
  • 抽象通用模板模式：识别并提取重复的提示词模式（例如，需要“思考过程”和“最终答案”两段式输出的模式），创建基础模板或父类。具体的提示词可以继承或组合这些基础模板，减少重复并提高一致性。
  • 增强文档与类型提示：为每个提示词变量添加详细的文档字符串（docstring），说明其用途、期望的输入变量格式、以及LLM应遵循的输出格式。考虑使用类型别名或 TypedDict 来定义复杂的提示词参数结构，提高代码的清晰度和IDE支持。
  • 考虑国际化（i18n）支持：如果系统有面向多语言用户的需求，应提前设计提示词的国际化和本地化方案，例如将模板与语言标识符关联，而不是在代码中直接写入特定语言的文本。

其它

设计目标与约束

本模块的设计目标是提供一个集中、可维护的提示词（Prompt）库，用于支持一个基于大语言模型（LLM）的代码生成与问题求解系统。其核心约束包括：

  1. 可读性与可维护性：提示词以清晰的字符串常量形式定义，便于开发者阅读、修改和扩展。
  2. 结构化与模块化：每个提示词对应一个特定的任务（如答案生成、格式提取、代码验证、反思等），职责单一，便于组合和调用。
  3. 上下文无关性：提示词本身不包含运行时状态或逻辑，是纯文本模板，其执行依赖于外部LLM引擎和传入的动态参数。
  4. 文本模板化：所有提示词均使用Python的f-string或format方法预留占位符（如{input}, {problem}），以便在运行时注入具体的任务上下文。

错误处理与异常设计

本模块作为静态的字符串定义库，不包含直接的运行时逻辑，因此其本身不涉及传统的错误处理（如异常捕获）。其“错误处理”主要体现在提示词的设计层面：

  1. 输入验证的缺失：模块不验证传入占位符的参数类型、格式或是否缺失。错误的参数注入（如类型错误、KeyError）将在调用str.format()时由Python解释器抛出标准异常（如KeyError, IndexError）。责任在于调用方确保参数正确。
  2. 提示词歧义性：潜在的“错误”是提示词指令不清晰导致LLM输出不符合预期格式。这需要通过人工迭代优化提示词文本来缓解，属于设计期而非运行期问题。
  3. 安全性与注入：由于直接进行字符串格式化，存在提示词注入（Prompt Injection）的潜在风险，如果外部输入未经清洗直接填入占位符。调用方需对不可信输入进行适当的过滤或转义。

数据流与状态机

本模块不管理数据流或维护状态机。它在系统中扮演数据（提示词模板）提供者的角色。典型的数据流如下：

  1. 触发：系统其他组件（如求解器、验证器、集成模块）根据当前任务阶段（如“生成初始答案”、“验证代码”、“集成多个结果”）选择对应的提示词常量。
  2. 组装：调用方获取提示词字符串，并使用具体的上下文数据（如用户问题、生成的代码、测试结果）通过字符串格式化填充占位符，生成完整的、可发送给LLM的提示。
  3. 消费：组装后的完整提示被发送至外部的LLM服务（如OpenAI API、本地模型），LLM的输出再由调用方组件进行解析和处理，推动系统进入下一个状态（如代码执行、结果比较）。

模块本身是无状态的，每次访问都返回相同的字符串常量。

外部依赖与接口契约

  1. 外部依赖：
    • Python 解释器：需要支持多行字符串和f-string/format语法的Python环境（Python 3.6+）。
    • LLM 服务/引擎：本模块定义的提示词预期被一个能够理解自然语言指令的大语言模型所消费。模块不关心LLM的具体实现（API或本地部署）。
  2. 接口契约（对调用方）：
    • 提供常量：模块通过全局变量（如ANSWER_GENERATION_PROMPT）公开其提示词。调用方通过变量名导入和使用。
    • 参数契约：每个提示词变量都是一个字符串模板，其中包含用花括号{}标明的占位符。调用方在使用str.format()或f-string进行格式化时，必须提供与所有占位符名称完全匹配的关键字参数。例如，使用ANSWER_GENERATION_PROMPT时必须提供input参数。
    • 格式契约：部分提示词（如SC_ENSEMBLE_PROMPT, MD_ENSEMBLE_PROMPT, REVIEW_PROMPT）明确要求LLM的输出遵循特定的JSON-like结构（包含"thought"和"answer"或"solution_letter"字段）。调用方需要负责解析LLM的响应以提取这些结构化字段。模块本身不提供解析工具。

配置与可调性

  1. 硬编码配置：所有提示词的文本内容目前以硬编码字符串形式存在于源代码中。这是最主要的配置方式。
  2. 可调性维度：
    • 内容调整：通过直接修改本Python文件中的字符串常量，可以调整指令的详细程度、步骤、输出格式要求等，以优化LLM的输出质量。
    • 参数化：通过改变格式化时传入的参数，可以动态适应不同的问题、解决方案和上下文，使得同一提示词模板能用于广泛的任务。
  3. 扩展机制：添加新的提示词只需在模块中定义一个新的字符串常量并遵循现有的命名和文档风格。删除或停用某个提示词只需注释掉或移除对应的常量定义。这种设计提供了较高的灵活性和可扩展性。