面向智能体AI的提示工程

标题：面向智能体AI的提示工程

来源URL：https://machinelearningmastery.com/prompt-engineering-for-agentic-ai/

发布日期：2026-05-19T12:00:06+00:00

Markdown内容：

在本文中，您将学习当提示工程应用于智能体AI系统时，其根本性变化是什么，以及哪些原则和模式能够实现大规模下智能体的可靠行为。

我们将涵盖的主题包括：

• 为何提示智能体不同于提示聊天机器人，以及上下文工程在实际中的含义。
• 每个智能体提示所需的四个组成部分：系统提示、工具、示例和上下文状态管理。
• 使智能体更可靠的推理架构，从思维链（Chain of Thought）到ReAct和Reflexion。

引言

您可能已经花时间学习如何有效地提示AI：更好的措辞、更清晰的指令、更充分的前置上下文。这些知识确实有用，但一旦您进入智能体AI领域，它们的效用就有限了。

在聊天窗口中有效的提示技巧，一旦AI开始跨多个步骤执行操作，就会立即失效。一个精心设计的问题只会产生一个良好的响应；而一个设计良好的智能体提示，则是引导一个系统——它读取文件、调用API、做出决策、委派给子智能体、从错误中恢复，并最终交付完整输出，而您无需干预每一步。这是两种截然不同的学科：一个是提问，另一个是设计系统的思考方式。

本文关注的是后者。它面向的是那些已超越聊天、迈向智能体的构建者和实践者，他们希望了解提示在自主系统内部究竟如何运作，可靠的模式是什么样子，以及大多数人常犯的错误在哪里。

为何提示智能体不同于提示聊天机器人

当您提示一个聊天机器人时，您的唯一任务是生成一个良好的后续回复。您写一段话，模型回复，您调整后再试。反馈循环短且可见。如果输出错误，您可以立即看到并重新提示。

智能体并非如此运作。智能体接收一个目标，制定计划，跨多个步骤执行，使用工具，生成中间输出以供后续步骤使用，最终交付最终结果。问题是，第一步中的模糊指令并不会在第一步就明显失败；它会逐渐偏离。到了第七步，智能体实际上正在执行它从您的提示中推断出的内容——而这可能完全不是您的本意。而此时，您已经消耗了大量计算资源、时间和工具调用才走到这一步。

这就是智能体提示的核心挑战：您的提示效果分布在时间和多个步骤中，而非集中于单次响应。

还有一个加剧这一问题的结构性问题。关于上下文退化的研究表明，随着智能体上下文窗口中token数量的增加，模型准确回忆和推理这些信息的能力会下降，研究人员称之为“上下文腐烂”（context rot）。每一次工具调用的结果、每一次中间输出、每一个已完成的步骤都会增加token数量。在长任务的中途，一个在设计不良的上下文上运行的智能体，可能会丢失最初明确陈述的约束条件。

这正是Anthropic工程团队引入上下文工程概念的原因——它是提示工程的自然演进。他们的观点是：提示工程问的是“哪些词是正确的？”而上下文工程问的是“在执行的每个时刻，模型应拥有怎样的最优信息集合？”这是一个更大、更具架构性的问题，也是构建可靠行为智能体的正确问题。

Anthropic的上下文工程（来源）

每个智能体提示所需的四个组成部分

基于Lilian Weng的基础框架和Anthropic的工程指导，一个设计良好的智能体依赖于四类上下文。每一类都需要精心设计，任何一处的随意处理，都是失败的主要根源。

系统提示

系统提示是智能体在整个任务中所遵循的“任务简报”。它定义了智能体扮演的角色、可用的工具、必须遵守的约束条件，以及应交付的输出。它是您整个智能体架构中最重要的文本，同时也是最容易写坏的部分。

Anthropic的工程团队描述了两种失败模式，它们代表了错误做法的两端。一方面：过度指定。提示中塞满僵化的if-else逻辑，试图预判所有可能场景，硬编码本应由模型判断的行为。这类提示极其脆弱——只要遇到一个未预见到的边缘情况，整个系统就会出错。另一方面：不足指定。使用模糊、高层次的目标，假设模型拥有它实际上不具备的上下文。这类提示迫使智能体填补您自己都没意识到的空白。

正确的做法是Anthropic所称的“恰当的抽象层级”：足够具体以有效约束行为，又足够灵活以应对您未明确编写的场景。以下是其实际表现：

弱系统提示：

1 您是一个乐于助人的研究助手，帮助用户完成研究任务。

强系统提示：

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15 你是一名研究助理，协助 B2B SaaS 产品团队整合竞争情报。你可访问网络搜索工具和文件写入工具。你的工作将在任何决策前由产品经理审核。

当你接到研究任务时：

1. 若目标不明确，需在开始前澄清范围
2. 优先从一手来源（公司官网、官方公告、财报电话会）搜索信息，再使用二手来源
3. 标注任何超过 12 个月的信息为可能过时
4. 不要对竞争对手的战略做出结论——仅报告发现，由人类自行解读

输出结构化报告，包含：执行摘要（3–5 句）、按类别划分的发现，以及包含 URL 的来源部分。使用 Markdown 格式。

第二版并未对代理可能采取的每个动作进行过度具体化。它为代理提供了清晰的角色背景、行为约束、来源优先级层级、关于应得出和不应得出结论的范围界定，以及输出格式。这些是启发式规则，而非脚本，这正是它们具备持久性的原因。

工具

你赋予代理的每一个工具都是一个决策点，也消耗 Token 成本。工具描述会占用注意力预算。功能重叠的工具会造成歧义。根据 Anthropic 的指导，生产环境中代理最常见的失败模式之一是工具集臃肿，导致代理无法可靠判断在特定情境下应使用哪个工具。

判断标准很简单：如果你作为人类，面对代理所处的情境，无法立即判断应使用哪个工具，那么代理也无法可靠地做出判断。每个工具应仅承担一项职责，其描述必须明确其用途，参数需足够具象，无需外部文档即可使用。

弱工具描述：

{
  "name": "search",
  "description": "Search for information"
}

强工具描述：

{
  "name": "web_search",
  "description": "在公共网络上搜索有关某一主题的最新信息。当你需要获取可能近期发生变化或不在你训练知识中的事实、新闻或数据时使用。请勿用于检索任务上下文中已提供的文档。",
  "parameters": {
    "query": "一个由 3–8 个词组成的具体、有针对性的搜索查询",
    "max_results": "返回结果数量（默认：5，最大：10）"
  }
}

更强的版本不仅说明工具的功能，还明确指出何时使用、以及——关键的是——何时不应使用。这一边界正是防止代理对上下文中已存在的信息默认执行网络搜索、从而浪费 Token 和时间的关键。

示例（少样本提示）

研究表明，示例在塑造代理行为方面优于指令列表。当模型看到两到三个具体的输入-输出对时，会激活上下文学习，识别模式并将其转换逻辑应用于新输入，其可靠性往往高于纯自然语言指令。

对于代理而言，示例具有特定目的：它们展示的是预期的推理格式、输出结构和决策风格——而不仅仅是正确答案。一个好的少样本示例应展示思考过程，而不仅仅是最终结果。

示例：数据分析师代理的两样本提示

示例 1：
输入："总结 Q1_sales.csv 中的销售数据"
思考：我需要先读取文件以理解其结构，然后再进行总结。
行动：read_file("Q1_sales.csv")
观察：文件包含列：Date, Region, Product, Revenue, Units。共 547 行，覆盖 2025 年 1 月至 3 月。
思考：现在我可以进行总结了。我将按地区和产品计算总计，并识别出表现最佳者及关键趋势。
输出：[结构化摘要，含总计、表现最佳者及一条关键趋势]

示例 2：
输入："将我们的定价与竞争对手比较"
思考：这个目标过于模糊，无法直接操作——我需要知道应关注哪些竞争对手，以及要对比哪些产品。
输出："为准确比较定价，我需要两个信息：应关注哪些竞争对手？以及你要对比哪些产品？请明确后我将继续。"

请注意，示例二展示了代理识别模糊性并暂停以寻求澄清——这是你希望明确展示的行为，因为仅靠指令本身无法自然体现这一点。

消息历史与上下文状态

消息历史包括代理在当前任务中产生的所有先前对话轮次、工具调用结果和中间输出。它也是长期运行代理中“上下文腐化”的主要来源。

Anthropic 的研究 将 Transformer 的注意力机制描述为注意力预算：上下文窗口中的每个 Token 都在争夺模型的注意力，随着上下文增长，该预算会被拉伸。尽管模型在较长上下文中仍保持能力，但在信息检索和长程推理方面的精确度相比短上下文有明显下降。

实际影响是：将所有内容——每个工具结果的完整内容、每个中间步骤——都塞入上下文窗口，会使代理在任务深入过程中变得“更笨”。

更好的方法是即时上下文：不是预先加载所有相关数据，而是代理仅维护轻量级引用（文件路径、存储的查询结果、URL），并在需要时即时获取所需内容。Claude Code 处理大型代码库的方式正是如此：它存储文件路径，采用定向读取，而非将整个仓库加载进上下文。模型仅看到当前步骤相关的特定文件，从而保持活跃上下文精简、注意力集中。

真正有效的推理架构

代理的推理结构，与提示内容本身同样重要。谷歌团队2022年发表的研究提供了基础性证明：在“24点游戏”谜题中，一个前沿模型的成功率从4%提升至74%——这并非来自模型升级，而是因为它被赋予了一种结构化的推理方式。模型本身并未变得更聪明；是它的推理架构变强了。

思维链（Chain of Thought, CoT）

思维链提示是最简单的架构升级，也是所有其他方法的基础。它不再直接从问题跳到答案，而是让模型在输出前显式地生成其推理步骤。

Wei 等人的原始研究表明，仅在提示末尾添加“让我们一步步思考”就能显著提升多步问题的准确率。这句话会激活模型的推理模式。模型将内部推理过程外化，这不仅提高了准确性，也让推理过程变得可见且可审计——这对任何高风险应用都至关重要。

基础 CoT 提示添加示例：

1

2

3

4

5

6

7

8

9

10 你是一个财务分析代理。

在接到分析任务时，始终在生成输出前思考以下问题：

• 我有哪些数据？缺少哪些数据？

• 我做出了哪些可能错误的假设？

• 这些数据最可能的解读是什么？

• 什么信息会改变我的结论？

然后基于上述思考，输出你的分析结果。

关键在于，CoT 在推理结构与任务类型匹配时效果最佳。财务分析所需的推理步骤不同于代码调试或竞争性研究。请根据代理的实际职责定制其思考框架。

ReAct（推理 + 行动）

ReAct 是使用工具的代理的主导模式。其名称源于它所实现的循环：思考 → 行动 → 观察 → 思考。模型首先推理下一步该做什么，然后使用工具执行行动，观察结果，并基于所学内容再次推理。该循环持续进行，直至任务完成。

ReAct 的强大之处在于，它将模型的推理建立在真实证据之上。模型不再在真空环境中推理并生成自信但虚构的答案，而是必须在每一步用真实工具输出来验证其假设。

ReAct 提示模板：

1

2

3

4

5

6

7

8

9

10

11

12

13

14 你是一个拥有 web_search 和 save_file 工具的研究代理。

请使用以下循环完成任务：

Thought: [思考你已知的信息和下一步需要查找的内容]

Action: [选择一个工具并明确说明如何使用它]

Observation: [此部分将由工具结果自动填充——请勿自行填写]

Thought: [思考观察结果告诉了你什么，以及下一步该做什么]

...重复直至完成...

Final Answer: [输出最终结果]

永远不要跳过 Thought 步骤。没有经过 Thought 合理论证的行动，绝不执行。若观察结果出乎意料，请先分析原因，再决定后续步骤。

ReAct 循环的实际示例：

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21 任务：“查找 Notion 团队版的当前定价，并与 Coda 的团队版进行比较。”

Thought: 我需要获取两个产品的最新定价。我将分别搜索，以获得准确、最新的数据，而非依赖训练数据。

Action: web_search("Notion 团队版定价 2025")

Observation: 截至2025年3月，Notion 团队版年付为每人每月16美元，月付为每人每月20美元。

Thought: 我已获得 Notion 的定价，现在需要 Coda 的定价。

Action: web_search("Coda 团队版定价 2025")

Observation: Coda 团队版年付为每人每月30美元。

Thought: 我已获取两个数据点。在年付情况下，Notion 明显更便宜。我应注明每个价格的验证时间。

Final Answer: [结构化对比定价、付款方式及数据获取日期]

该循环迫使代理明确采取具体行动、观察真实结果，并据此更新推理，而非仅凭内部假设生成响应。

Reflexion（自我修正）

Reflexion 在 ReAct 的基础上更进一步。在完成一项任务或关键步骤后，代理会将其输出与原始目标进行对比，识别具体失败或遗漏，并在继续或交付最终结果前生成修正计划。这是构建能够自主发现错误、无需每一步都依赖人工干预的代理的关键方法。

Reflexion 提示补充：

1

2

3

4

5

6

7

8

9

10

11 在完成每个主要任务步骤后，在进入下一步前，执行一次自我检查：

Reflection:

• 此输出是否完整回应了原始要求？

• 我是否做出了任何无法由所获取数据验证的主张？

• 我是否遗漏了原始任务中明确说明的任何约束条件？

• 如果我是审查此结果的人，我会指出哪些问题？

如发现遗漏或错误，请在继续前予以修正。

明确说明你发现了什么，以及你做了哪些修改。

Reflexion 实际应用示例：

1

2

3

4

5

6

7

8

9

10

11

12

13[代理完成了一份竞争对手分析报告的初稿]

Reflection: 对照原始任务复核——用户要求包含定价、功能对比和市场定位。我覆盖了定价和功能，但未涉及各竞争对手在营销材料中的定位表述。该部分内容缺失。

修正中：将额外搜索各竞争对手官网及近期新闻稿，以捕捉其定位表述，再交付最终报告。

Action: web_search("竞争对手A定位宣传语 2025")

...

Reflexion 在质量比速度更重要的任务中最有价值：报告、分析和结构化文档。自检循环会增加延迟，但能显著降低不完整或不一致的输出到达最终用户的概率。

实践中的上下文工程

理解理论是一回事，将其转化为你实际编写的代理提示词则是另一回事。以下四种模式涵盖了最具影响力的实践方法。

保持系统提示词的适当高度

两种极端都会让你付出代价。过度指定的提示词试图脚本化代理的每一个决策；它读起来像嵌入在自然语言中的流程图，一旦现实与脚本不符，它就会崩溃。而不足指定的提示词则给代理一个模糊的目标，并假定它拥有其并不具备的上下文。

恰当的高度应为代理提供清晰的角色背景、行为原则和输出期望，同时不试图预先回答它将面临的每一个决策。当你发现自己在系统提示词中写下“如果用户问 X，就做 Y；如果用户问 Z，就做 W”时，这表明你已陷入过度指定。请用原则替代 if-else：“优先考虑准确性而非速度。存疑时，获取最新数据，而非依赖先前上下文。”

编写结果提示词，而非步骤列表

这一原则同样适用于更广泛的代理工具。告诉代理要交付什么，比告诉它每一步该怎么做效果更好。步骤列表会限制代理在某一步未按预期执行时的适应能力，而在多步骤任务中，步骤几乎从不会完全按预期进行。

步骤列表（脆弱）：

1. 打开 CSV 文件
2. 找到收入列
3. 按地区汇总数值
4. 写一段描述结果的文字
5. 将输出保存为 report.docx

结果提示词（稳健）：

分析工作目录中的销售 CSV 文件，生成一个 Word 文档，内容包括：

• 各地区的总收入
• 表现最佳的地区及其简要原因分析
• 你发现的任何数据质量问题（缺失值、格式不一致）

保存为 report.docx

结果版本告诉代理最终产品应该是什么样子。代理自行决定如何达成目标，并能在 CSV 文件包含意外列或地区名称格式不一致时灵活调整。

使用即时上下文而非预加载上下文

将你认为代理可能需要的所有内容预先加载到上下文窗口中是一种自然的本能，但却是降低长任务性能的可靠方式。相反，应设计代理保持轻量级引用，并在需要时才获取具体信息。

实践中，这意味着你的系统提示词应指明信息所在位置，而非直接包含信息本身：

数据访问

客户数据存储在 /data/customers.csv。 产品目录位于 /data/products.json。 不要提前加载这些文件。仅在任务当前步骤中，使用 read_file 工具配合精准查询，加载相关行或字段。

这能保持任务全程的活跃上下文精简，为每个步骤中真正重要的推理保留注意力资源，而非用仅在后期才相关的数据填满窗口。

动态角色预热

如果在运行时注入上下文相关的角色信息，而非硬编码，单一代理架构即可服务截然不同的用户群体。这对同时面向技术与非技术用户、或根据用户角色调整语气与深度的代理尤为有用。

运行时注入示例：

根据会话开始时的用户角色注入

非技术用户：

role_context=""" 用户为无技术背景的业务利益相关者。 请用通俗语言解释发现，避免术语。必要时使用类比。 永远不要展示原始数据——必须先进行解释。 """

技术用户：

role_context=""" 用户为资深数据工程师。请使用精确的技术术语。 在有助于澄清时，包含相关 SQL 或代码片段。 聚焦实现细节，而非高层摘要。 """

system_prompt = base_system_prompt + "\n\n" + role_context

单一代理架构，两种截然不同的输出——无需为每种用户类型维护独立的代理或提示文件。

多代理系统的提示设计

单一代理存在局限。需要并行工作流、多个领域专业知识，或生成与审查之间相互制衡的复杂任务，更适合由多代理系统完成。主流模式是“协调者-工作者”架构：一个代理接收目标，将其分解为子任务，将每个子任务委派给专门的工作者代理，并整合结果。

提示一个多代理系统，意味着分别提示每个代理，同时设计它们之间的交接流程。每个代理都必须清楚自己的职责、应接收的输入以及应交付的输出。它无需理解完整架构——只需理解自己在其中的角色即可。

协调者系统提示：

你是一个研究协调代理。你的职责是协调一组专业代理完成研究任务。 你可访问三个工作者代理：

• search_agent：从网络检索信息。

向其发送：明确的搜索目标及所需输出格式。

• analysis_agent：分析数据并识别模式。

向其发送：结构化数据及具体的分析问题。

• writer_agent：生成精炼的书面输出。

向其发送：结构化发现结果及目标文档格式。

你的职责：

• 将用户的任务分解为每个代理的明确子任务
• 在委派前，精确说明每个代理应交付的内容

• 在传递给下一个代理之前，验证每个代理的输出是否符合规范
• 从所有代理的结果中合成最终输出

不要试图自己完成任何专业性工作。

工作代理系统提示（search_agent）：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

你是一个专业的搜索代理。你从协调者那里接收一个明确的搜索目标，并返回结构化的研究结果。

你将收到的输入：

• 一个清晰的搜索目标
• 所需的输出格式（例如：项目符号、JSON、表格）

你的职责：

• 执行有针对性的网页搜索以实现目标
• 仅返回直接回应目标的信息
• 标记任何超过6个月的信息
• 不做解释或主观评论——仅返回发现结果

你无需理解更宏大的任务。请完全专注于你被赋予的搜索目标。

此处的核心设计原则是最小化共享上下文。每个工作代理仅知道完成其任务所需的信息。它不需要完整的任务上下文、用户的过往历史，或其他代理正在做什么。这使得每个代理的上下文保持精简，降低了任务间相互污染的风险，并在出现问题时更容易调试。

常见错误及修正方法

即使意图良好的代理提示，也会因可预测的原因失败。以下是出现频率最高的五个问题：

1. 给代理太多工具：更多的工具看似提供更多能力，但会在每个决策点造成模糊性。如果两个工具都可能适用于同一场景，代理会犹豫、不一致地选择，或使用错误的工具。解决方案：在每次部署前审计你的工具集。如果你无法立即且明确地判断哪个工具适用于某个特定场景，请删减，直到你能做到为止。
2. 成功标准模糊：如果代理不清楚“完成”是什么样子，它会不断继续、反复质疑自己的输出，或在错误的节点停止。像“完成分析”这样的模糊终点会引发主观解读；而像“交付一个包含这四个部分的Word文档，所有内容均来自提供的CSV文件”这样的具体要求则不会。每个任务规范都应明确定义输出格式、预期内容，以及代理认为自身完成前必须满足的条件。
3. 上下文过载：将所有背景文档、先前会话历史和参考数据一次性塞入上下文窗口，会因注意力预算被过度摊薄而降低长任务的性能。请使用即时检索（just-in-time retrieval），仅在需要时加载特定数据，而非一开始就全部加载。
4. 缺少示例：指令告诉代理该做什么，示例则展示什么是成功。对于任何你将重复执行的任务模式，两到三个精心挑选的示例，其价值远超额外一页的说明文字。模型能从示例中推断出格式、语气、决策风格和输出结构，而这些是自然语言描述无法完全捕捉的。
5. 将多步骤代理当作单次对话：聊天机器人的提示可以模糊，因为人类可以实时纠正。而一个自主运行15个步骤的代理，在交付最终输出前没有任何纠正机制。你在提示中留下的每一个模糊点，都会变成代理自行做出的决策，而这些决策会在后续每一步中累积放大。请在前期投入更多时间设计提示——这将换来更少的失败运行和更可靠的输出。

结论

面向代理式AI的提示工程，并非同一技能的高级版本，而是一种基于不同前提的全新学科。聊天提示的目标是获得一个良好的回应；上下文工程的目标则是设计一个可靠系统——该系统能在多个步骤中做出一致决策、正确使用工具、管理自身的注意力预算，并在无需你每一步干预的情况下交付完整成果。

目前从代理式AI中获益最多的团队，已经不再问“我该怎么更好地措辞？”，而是开始问：“这个模型在每一步需要知道什么，才能表现得如我所愿？”这种从“措辞”到“架构”的转变，才是真正的杠杆所在。从正确的抽象层级开始设计系统提示；为代理提供它能明确区分的工具；向它展示你期望的推理风格示例；然后在任务执行过程中保持上下文精简。这四个习惯，比任何单个巧妙的提示都更能带你走得更远。

如需进一步阅读，Anthropic 的上下文工程文章 是对底层原理最实用的深度解析；提示工程指南的代理章节 则以更多技术深度介绍了 ReAct、Reflexion 及相关架构。在你构建系统时，建议将这两份资料保持打开状态。

##### 暂无评论