附录C 提示工程技术速查

附录C 提示工程技术速查

本书正文关注的是智能体编码的整体工程体系，包括如何定义任务、组织上下文、配置工具与权限、验证结果以及设置监督机制，因此没有把重点放在单次提示的具体措辞上。本附录补充提示工程的基础内容，选取若干具有代表性的提示方法，供读者在设计具体提示时快速查阅。

需要先明确这些方法的作用边界。提示工程主要解决单次交互中如何组织任务说明、示例、输入数据、输出格式和推理路径的问题；上下文工程则进一步关注哪些信息应当进入上下文、如何组织和压缩这些信息，以及何时动态注入。提示技术可以改善模型理解任务和生成结果的方式，但不能替代任务简报、自主性边界、权限控制、独立验证等工程机制，也不能单独保证结果正确。同一种方法在不同模型、任务和harness中的效果可能存在差异，实际使用时仍需结合具体场景进行验证。

本附录优先列出相关方法具有代表性的原始论文或奠基性研究。对于正文已经用整节或整章系统讨论的主题，例如上下文工程、结构化输出和ReAct循环，这里只说明其在提示工程中的位置并提供交叉索引，不再重复展开。读者应当把这些局部提示方法与正文讨论的委托、执行、验证和监督机制结合起来使用，而不应把提示措辞本身视为决定智能体产出质量的唯一因素。

C.1　基础提示技术

C.1.1　零样本提示（Zero-Shot Prompting）

零样本提示不向模型提供任务示例，而是直接通过任务描述、输入内容和约束条件要求模型完成工作。它主要利用模型在预训练和指令训练阶段获得的知识与指令遵循能力，是形式最简单、上下文开销较小的一类提示方法。

需要注意，“零样本”只表示提示中没有提供示例，并不意味着只能使用一句简短指令。任务目标、背景信息、输出格式和限制条件仍然可以写得十分具体。这种方法适合模型较为熟悉、任务边界清楚且输出形式常见的场景，例如解释常见的Python异常。对于领域含义特殊、分类边界模糊或者输出格式严格的任务，仅靠零样本提示可能难以稳定表达要求，此时可以考虑加入示例。

C.1.2　少样本提示（Few-Shot Prompting）

少样本提示在上下文中提供少量输入—输出示例，使模型据此识别任务模式，并生成符合要求的新结果。模型参数不会因为这些示例而更新；这种在当前上下文中依据示例适应任务的方式，通常称为上下文学习（In-Context Learning）。大规模语言模型表现出的零样本、单样本和少样本任务能力，在Brown等人的研究中得到了系统验证。

少样本提示可以与显式指令结合使用。指令用于说明任务目标、约束条件和验收要求，示例则进一步展示分类边界、字段含义、输出格式和表达风格。当输出结构较为特殊，或者仅用文字难以准确描述规则时，提供两三个具有代表性的示例通常比继续堆叠抽象说明更直观。

示例的质量、顺序和覆盖范围都可能影响输出。应当优先选择正确、典型且彼此一致的示例，必要时加入容易混淆的边界情况；如果示例本身包含错误或隐含冲突，模型也可能沿用这些问题。

C.2　提示结构化

结构化提示的核心，是把性质不同的信息清楚地组织起来，使模型能够区分长期规则、当前任务、参考资料、待处理数据和输出要求。结构越清晰，模型越容易识别各部分之间的关系。不过，结构化只能减少歧义，不能替代权限控制、输入检查和结果验证。

C.2.1　系统提示（System Prompting）

系统提示用于设置在一次会话或一类任务中持续生效的行为要求，例如模型应当遵守的基本规则、角色边界、输出原则和安全约束。把这些相对稳定的要求放在系统或开发者指令层级，可以使其与用户提交的具体任务分开管理，避免在每次请求中重复说明。

不同产品对指令层级的实现并不完全相同。在Codex中，第6章讨论的AGENTS.md是一种项目级指令载体：Codex会按照目录层级加载其中的项目背景、工程约定、验证命令和禁止事项。它在工程上承担了复用稳定指令的作用，但并不等同于模型API中的系统消息，也不应把所有项目资料都堆放其中。与单项任务直接相关的目标、输入和验收条件，仍应写入当前任务简报。

C.2.2　角色提示（Role Prompting）

角色提示要求模型从特定的专业视角处理任务，例如以安全工程师、数据库管理员或者代码评审者的视角分析问题。恰当的角色设定可以引导模型调整关注重点、评价标准和表达方式，使输出更贴近任务所需的专业语境。

角色提示是一种行为引导，而不是能力或权限的授予。把模型称为“资深专家”，不会扩展其底层知识、工具权限和真实能力，也不能保证结论正确。与其只给出宽泛的身份标签，不如同时说明该角色的具体职责、检查重点和输出要求。例如，第15章中的评审子智能体不仅被赋予代码评审者角色，还需要依据明确的审查范围和判定标准检查实现，这样的角色设定才具有实际约束力。

C.2.3　使用分隔符（Delimiters）

分隔符用于区分提示中的不同内容，例如任务指令、示例、参考资料和待处理数据。常见形式包括三重引号、Markdown代码围栏、XML标签以及预先约定的起止标记。使用分隔符时，应当明确说明各区域的用途，并指出哪些内容只能作为数据读取，不能被视为新的指令。

清晰的分隔可以降低模型混淆数据与指令的概率，也有助于程序稳定地组装提示。不过，分隔符不是安全边界，不能单独阻止提示注入。外部输入即使被放入XML标签或代码围栏，仍可能影响模型行为。对于不可信内容，还需要结合指令优先级、最小权限、数据隔离、工具调用审批和结果验证等机制进行防护，具体方法参见第5章。

C.3　推理过程提示技术

当任务包含多步计算、条件判断、规划或者搜索时，可以通过提示或外部编排，引导模型分解问题、比较候选路径并检查中间结果。本节介绍的思维链、自洽性、退一步提示和思维树，都属于推理阶段的方法。

这些方法的效果来自特定模型和基准上的实验结果，不能据此推断它们对所有任务都有效。增加推理步骤还会带来更多时延和计算开销，冗长的推理过程也可能包含看似连贯但并不正确的内容。因此，推理过程只能帮助模型形成答案，不能代替外部工具、测试程序和人工复核提供的验证证据。

C.3.1　思维链（Chain-of-Thought，CoT）

思维链将复杂问题分解为一系列中间推理步骤，再据此形成最终答案。Wei等人的研究通过在提示中提供带有推理过程的少样本示例，引导大语言模型生成类似的中间步骤，并在算术、常识和符号推理等任务上取得了明显改进。

需要区分两种常见形式。Few-shot CoT在提示中提供若干包含中间推理步骤的示例；Zero-shot CoT不提供示例，而是通过“请逐步思考”一类指令引导模型分解问题。后者由Kojima等人系统研究，并不是Wei等人原始论文提出的方法。

在工程任务中，与其要求模型输出冗长的完整思考过程，不如要求它给出可供核查的关键步骤、依据、假设和结论。这样既能利用任务分解的优势，也便于后续验证。

C.3.2　自洽性（Self-Consistency）

自洽性不是让模型对同一答案进行一次简单复查，而是一种与思维链结合使用的解码方法。它针对同一个问题采样多条不同的推理路径，再综合这些路径得出的最终答案，选择一致性最高的结果。其基本依据是：同一个问题可能存在多种有效的推理路径，而正确答案往往能够由多条不同路径共同导出。

对于答案明确的算术题、选择题或分类任务，可以使用多数投票进行汇总。对于开放式工程问题，不同表述之间未必能够直接计票，还需要借助规则、测试程序或者独立评审判断结果是否等价。自洽性能够降低单次采样偶然出错的影响，但会增加推理次数和计算成本；如果多条路径共享同一种错误假设，多数结果仍可能同时出错。

这种方法与第17章讨论的多版本并行探索都利用了多个候选结果，但二者的作用层级不同。自洽性在推理阶段采样多条解题路径并汇总答案；多版本并行探索则让多个执行分支形成完整的工程方案或实现，再使用统一标准生成验证证据并作出选择。

C.3.3　反思提示（Step-Back Prompting）

反思提示要求模型在处理具体问题之前，先从当前实例中抽象出更高层的概念、基本原理或通用规律，再利用这些内容指导后续推理。它并不是要求模型简单地“重新想一遍”，也不同于完成答案之后进行自我批评的反思方法。

例如，在直接分析某条数据库查询为什么变慢之前，可以先要求模型说明这类查询的性能通常受到哪些因素影响，再结合执行计划、索引结构和数据分布分析当前问题。这样做有助于减少模型过早陷入局部细节，但抽象出的原理仍可能不完整或不适用于当前场景，因此必须回到具体证据进行验证。

C.3.4　思维树（Tree of Thoughts，ToT）

思维树把单一路径的思维链扩展为可以分支搜索的推理结构。模型或外部编排程序在每个阶段生成若干候选“思维”，将其视为通向解答的中间状态，再对这些状态进行评价、筛选和扩展；必要时还可以前瞻或者回溯，以放弃效果较差的路径并探索其他分支。

思维树适合需要规划、搜索和早期决策的任务，但它并不只是提示中写一句“考虑多种方案”。完整实现通常还需要候选生成、状态评价、搜索策略和停止条件等机制，其计算成本也显著高于单路径推理。

思维树与多版本并行探索都包含候选生成和比较，但不能将二者等同。思维树主要在一次问题求解过程中搜索中间推理状态；多版本并行探索面向完整的工程方案或实现，并强调执行环境隔离、统一验证、验证证据和最终收敛。

C.4　行动与交互技术

前面介绍的方法主要组织模型如何理解和推理问题。本节进一步关注模型如何与外部环境交互：模型可以提出工具调用请求，接收工具返回的观察结果，再根据新的信息决定下一步行动。正是这种持续获取反馈并调整行为的循环，使模型能够从一次性文本生成扩展到多步骤任务执行。

C.4.1　ReAct：推理与行动交替

ReAct将推理（Reasoning）与行动（Acting）组织在同一条任务轨迹中。模型先依据当前信息进行推理并选择行动，例如查询知识库、调用接口或者操作外部环境；执行系统完成行动后，把得到的观察结果（Observation）返回给模型；模型再依据新信息更新判断并决定下一步行动。这个过程可以反复进行，直到任务完成或者触发停止条件。

行动使模型能够获取外部信息并影响环境，观察结果则为后续判断提供反馈。与只依赖模型内部知识的单次回答相比，这种循环有助于减少因信息缺失导致的错误，并使模型能够根据执行结果修正原有计划。不过，工具返回的内容也可能不完整、过时或者不可信，行动本身还可能产生外部影响，因此每轮观察都需要经过适当处理，高风险行动也必须受到权限和审批机制约束。

ReAct是推理与工具交互领域具有代表性的框架，对后续智能体设计产生了重要影响。许多编码智能体都采用“判断—行动—观察—调整”的反馈循环，但不一定严格沿用ReAct论文中的提示格式，也不一定向用户展示完整的推理轨迹。因此，不宜把所有现代编码智能体都简单视为ReAct的直接实现。

第2章已经介绍了ReAct的基本概念，第8章则从工程角度讨论了工具调用、执行反馈和权限控制。实际应用时，还需要结合任务简报、自主性边界、停止条件和验证机制，不能只依靠提示中的行动格式保证任务安全完成。

C.4.2　结构化输出与工具调用（Structured Outputs and Tool Calling）

结构化输出要求模型按照预先定义的模式生成结果，例如返回符合JSON Schema的对象，以便后续程序稳定解析。工具调用则允许模型从系统提供的工具中选择适当工具，并生成调用所需的结构化参数；真正的工具执行通常由宿主程序或智能体运行环境完成，执行结果随后再返回给模型。

两者关系密切，但用途不同。结构化输出主要约束模型交给用户或下游程序的最终结果；工具调用主要表达模型希望执行的操作及其参数。一个任务可以只使用结构化输出而不调用工具，也可以在多轮工具调用结束后，再以结构化格式返回最终结果。

模式约束能够提高输出在字段、类型和枚举值等方面的一致性，但只能保证结构符合要求，不能证明内容在业务语义上正确。例如，一份结果即使通过Pydantic校验，其中的设备编号、告警等级或处理建议仍可能有误。同样，工具调用参数符合JSON Schema，也不代表该调用已经获得授权或者执行后一定安全。

因此，结构化输出之后仍需进行业务规则检查和结果验证；执行工具之前还应验证参数、权限和目标对象，并依据自主性边界决定是否需要人工审批。第12.4节通过Pydantic示例讨论了结构化输出的工程价值，第8章则进一步说明了工具调用及其安全控制机制。

C.5　与正文的交叉索引

本附录介绍的技术主要作用于提示设计和单次推理过程，正文讨论的则是怎样围绕任务委托、上下文组织、工具使用、验证和监督建立完整的工程体系。两者处于不同层级：清晰的提示可以帮助模型更准确地理解任务，但产出质量还取决于自主性边界、执行环境、工具权限、验证证据和人工监督等因素。

读者可以通过下表查阅相关主题在正文中的系统论述。

延伸阅读

[1] Tom B. Brown等，《Language Models are Few-Shot Learners》，2020年。该文提出GPT-3，并系统评估了模型在不进行任务特定参数更新的情况下，通过任务描述或少量上下文示例完成任务的能力，DOI:10.48550/arXiv.2005.14165。

[2] Jason Wei等，《Chain-of-Thought Prompting Elicits Reasoning in Large Language Models》，2022年。该文提出通过带有中间推理步骤的少样本示例引导模型生成思维链，DOI：10.48550/arXiv.2201.11903。

[3] Takeshi Kojima等，《Large Language Models are Zero-Shot Reasoners》，2022年。该文研究了通过“Let’s think step by step”等简单引导语触发逐步推理的方法，DOI：10.48550/arXiv.2205.11916。

[4] Xuezhi Wang等，《Self-Consistency Improves Chain of Thought Reasoning in Language Models》，2023年。该文提出从多条采样推理路径中汇总一致答案的自洽性方法， DOI：10.48550/arXiv.2203.11171。

[5] Huaixiu Steven Zheng等，《Take a Step Back: Evoking Reasoning via Abstraction in Large Language Models》，2024年，该文提出退一步提示（Step-Back Prompting），通过先抽象出高层概念和基本原理，再用其指导具体推理，DOI：10.48550/arXiv.2310.06117。

[6] Shunyu Yao等，《Tree of Thoughts: Deliberate Problem Solving with Large Language Models》，2023年，该文提出思维树（Tree of Thoughts，ToT）框架，通过生成、评价和搜索多个中间推理状态支持前瞻与回溯，DOI：10.48550/arXiv.2305.10601。

[7] Shunyu Yao等，《ReAct: Synergizing Reasoning and Acting in Language Models》，2023年，该文提出交替生成推理轨迹和任务行动的ReAct范式，DOI：10.48550/arXiv.2210.03629。