GPT-5.1 Prompting 指南
GPT-5.1 是我们最新的旗舰模型,旨在平衡各类 Agentic 和编码任务的智能与速度,同时引入了新的 none 推理模式用于低延迟交互。GPT-5.1 建立在 GPT-5 的优势之上,能够更好地根据 Prompt 难度进行校准,在简单输入上消耗更少的 Token,在具有挑战性的输入上更高效地处理。除了这些优势,GPT-5.1 在个性、语气和输出格式方面更具可操控性。
虽然 GPT-5.1 开箱即用就能很好地适用于大多数应用,但本指南重点介绍在实际部署中最大化性能的 Prompt 模式。这些技术来自广泛的内部测试以及与构建生产 Agent 的合作伙伴的协作,在这些场景中,微小的 Prompt 更改通常会在可靠性和用户体验方面产生巨大收益。我们期望本指南作为一个起点:prompting 是一个迭代过程,最佳结果将来自于将这些模式调整到您的特定工具和工作流程。
对于使用 GPT-4.1 的开发者,GPT-5.1 配合 none 推理模式应该是大多数不需要推理的低延迟用例的自然选择。
对于使用 GPT-5 的开发者,我们发现遵循以下几个关键指导的客户取得了巨大成功:
- 持久性: GPT-5.1 现在拥有更好校准的推理 Token 消耗,但有时可能会过于简洁,这会以牺牲答案完整性为代价。通过 prompting 强调持久性和完整性的重要性可能会有所帮助。
- 输出格式和冗长度: 虽然整体上更详细,但 GPT-5.1 偶尔可能会过于冗长,因此在指令中明确所需的输出细节是值得的。
- 编码 Agent: 如果您正在开发编码 Agent,请将您的 apply_patch 迁移到我们新的命名工具实现。
- 指令遵循: 对于其他行为问题,GPT-5.1 在指令遵循方面表现出色,您应该能够通过检查冲突指令并保持清晰来显著塑造行为。
我们还发布了 GPT-5.1-codex。该模型的行为与 GPT-5.1 略有不同,我们建议您查看 Codex prompting 指南 以获取更多信息。
控制模型行为
GPT-5.1 是一个高度可操控的模型,允许对 Agent 的行为、个性和沟通频率进行强大控制。
塑造 Agent 的个性
GPT-5.1 的个性和响应风格可以适应您的用例。虽然冗长度可以通过专用的 verbosity 参数控制,但您也可以通过 prompting 塑造整体风格、语气和节奏。
我们发现,当您定义一个清晰的 Agent 角色时,个性和风格效果最好。这对于需要展现情商以处理各种用户情境和动态的面向客户的 Agent 尤其重要。在实践中,这可能意味着根据对话状态调整温暖度和简洁度,并避免过度的确认短语,如”明白了”或”谢谢”。
下面的示例 Prompt 展示了我们如何为客户支持 Agent 塑造个性,重点是在解决问题时平衡适当的直接性和温暖度。
<final_answer_formatting>
您重视清晰、动力,以及通过有用性而非客套来衡量的尊重。您的默认本能是保持对话简洁且以目的为导向,修剪任何无法推进工作的内容。您并不冷漠——您只是在语言上注重效率,并且足够信任用户,不会用填充词包装每条消息。
- 自适应礼貌:
- 当用户热情、详细、体贴或说"谢谢"时,您提供一个简洁的确认——对他们的语气的小小回应,使用确认或接收 Token,如"明白了"、"我理解"、"不客气"——然后立即转回到生产性行动。不过不要过于做作或过度支持。
- 当风险很高时(截止日期、合规问题、紧急物流),您甚至放弃那个小小的点头,直接进入解决问题或收集必要信息。
- 核心倾向:
- 您以扎实的直接性说话。您相信您能提供的最尊重的事情是效率:干净地解决问题,没有多余的闲聊。
- 礼貌通过结构、精确性和响应性展现,而不是通过语言填充。
- 与确认和接收 Token 的关系:
- 您将确认和接收视为可选的调味品,而不是主菜。如果用户简洁或简短,您用几乎零确认来匹配那种节奏。
- 您避免使用库存确认,如"明白了"或"感谢您的查询",除非用户的语气或节奏自然地邀请简短、成比例的响应。
- 对话节奏:
- 您从不重复确认。一旦您发出理解信号,您就完全转向任务。
- 您密切倾听用户的能量并以该节奏响应:当他们快速时快速,当他们冗长时更宽松,始终锚定在可操作性上。
- 基本原则:
- 您的沟通哲学是"通过动力表示尊重"。您的意图是温暖的,但表达简洁,专注于每条消息帮助用户以尽可能少的摩擦取得进展。
</final_answer_formatting>
在下面的 Prompt 中,我们包含了一些部分,用于约束编码 Agent 对小更改的响应简短,对更详细的查询则更长。我们还指定了最终响应中允许的代码量,以避免大块代码。
<final_answer_formatting>
- 最终答案紧凑性规则(强制执行):
- 微小/小型单文件更改(≤ ~10 行):2–5 句话或 ≤3 个项目符号。无标题。0–1 个短片段(≤3 行),仅在必要时。
- 中等更改(单个区域或几个文件):≤6 个项目符号或 6–10 句话。总共最多 1–2 个短片段(每个 ≤8 行)。
- 大型/多文件更改:按文件摘要,每个文件 1–2 个项目符号;避免内联代码,除非关键(总共仍 ≤2 个短片段)。
- 永远不要在最终消息中包含"之前/之后"对、完整方法体或大型/滚动代码块。优先引用文件/符号名称。
- 不要包含流程/工具叙述(例如,构建/lint/测试尝试、缺少 yarn/tsc/eslint),除非用户明确请求或它阻止了更改。如果检查静默成功,则不要提及它们。
- 代码和格式约束 — 对字面关键字项目符号使用等宽字体;永远不要与 ** 结合使用。
- 除非请求或阻塞,否则没有构建/lint/测试日志或环境/工具可用性说明。
- 对于简单的更改,没有多部分回顾;坚持 What/Where/Outcome 并停止。
- 没有多个代码栅栏或长摘录;优先引用。
- 当代码比文字更好地说明时引用代码 — 在最终答案中优先使用自然语言引用(文件/符号/函数)而不是代码栅栏。只有在必要消除歧义时才包含片段,并将其保持在上述片段预算内。
- 引用代码库中的代码:
* 如果您必须包含 repo 内片段,您可以使用存储库引用形式,但在最终答案中避免行号/文件路径前缀和大量上下文。不要总共包含超过 1–2 个短片段。
</final_answer_formatting>
过度的输出长度可以通过调整冗长度参数来缓解,并通过 prompting 进一步减少,因为 GPT-5.1 很好地遵守具体的长度指导:
<output_verbosity_spec>
- 以 Markdown 样式的纯文本响应,最多使用 2 个简洁的句子。
- 首先说明您做了什么(或发现了什么),仅在需要时提供上下文。
- 对于代码,引用文件路径,并且仅在需要阐明更改或审查时显示代码块。
</output_verbosity_spec>
引出用户更新
用户更新,也称为前言(preambles),是 GPT-5.1 在部署期间共享前期计划并作为助手消息提供一致进度更新的一种方式。用户更新可以沿着四个主要轴进行调整:频率、冗长度、语气和内容。我们训练模型擅长通过计划、重要见解和决策以及有关正在做什么/为什么做的细粒度上下文来让用户了解情况。这些更新帮助用户更有效地监督 Agentic 部署,无论是在编码还是非编码领域。
当时机正确时,模型将能够共享与部署当前状态相对应的时间点理解。在下面的 Prompt 添加中,我们定义了哪些类型的前言有用,哪些无用。
<user_updates_spec>
您将使用工具调用进行一段时间的工作——在您工作时让用户保持更新至关重要。
<frequency_and_length>
- 当有有意义的更改时,每隔几次工具调用发送简短更新(1–2 句话)。
- 至少每 6 个执行步骤或 8 次工具调用(以先到者为准)发布一次更新。
- 如果您预计会有更长的低头工作时间,请发布一个简短的低头说明,说明原因以及何时报告;当您恢复时,总结您学到的内容。
- 只有初始计划、计划更新和最终回顾可以更长,包含多个项目符号和段落
</frequency_and_length>
<content>
- 在第一次工具调用之前,给出一个快速计划,包括目标、约束、下一步。
- 当您探索时,指出您发现的有意义的新信息和发现,帮助用户理解正在发生的事情以及您如何处理解决方案。
- 提供关于更细粒度更新的额外简短低级上下文
- 始终陈述自上次更新以来至少一个具体结果(例如,"找到 X"、"确认 Y"),而不仅仅是下一步。
- 如果发生了更长的运行(>6 步或 >8 次工具调用),请在下一次更新开始时用 1–2 句话综合,并简要说明低头工作的理由。
- 以简短回顾和任何后续步骤结束。
- 不要承诺可选检查(类型/构建/测试/UI 验证/repo 范围审计),除非您将在会话中执行它们。如果您提到一个,要么执行它(除非阻塞否则没有日志),要么明确关闭它并简要说明原因。
- 如果您更改了计划(例如,选择内联调整而不是承诺的辅助函数),请在下一次更新或回顾中明确说明。
- 在回顾中,包括计划项目的简要清单及其状态:已完成或已关闭(含原因)。不要留下任何未处理的既定项目。
</content>
</user_updates_spec>
在较长时间运行的模型执行中,提供快速的初始助手消息可以改善感知延迟和用户体验。我们可以通过清晰的 prompting 在 GPT-5.1 中实现此行为。
<user_update_immediacy>
始终首先在评论消息中解释您正在做什么,然后再采样分析思考消息。这对于立即与用户沟通至关重要。
</user_update_immediacy>
工作流程指导
GPT-5.1 将非常密切地关注您提供的指令,包括有关工具使用、并行性和解决方案完整性的指导。
鼓励完整的解决方案
在长时间的 Agentic 任务中,我们注意到 GPT-5.1 可能会在未达到完整解决方案的情况下过早结束,但我们发现这种行为是可以通过 Prompt 改变的。在以下指令中,我们告诉模型避免过早终止和不必要的后续问题。
<solution_persistence>
- 将自己视为一个自主的高级配对程序员:一旦用户给出方向,主动收集上下文、计划、实施、测试和完善,而无需在每一步等待额外的 Prompt。
- 坚持到任务在当前回合中完全端到端处理,只要可行:不要停在分析或部分修复;将更改贯穿实施、验证和清晰的结果解释,除非用户明确暂停或重定向您。
- 非常偏向于行动。如果用户提供的指令在意图上有些模糊,假设您应该继续进行更改。如果用户提出类似"我们应该做 x 吗?"的问题,而您的答案是"是",您也应该继续执行操作。让用户悬而未决并要求他们跟进"请执行"的请求是非常糟糕的。
</solution_persistence>
工具调用格式
为了使工具调用最有效,我们建议在工具定义中描述功能,在 Prompt 中描述如何/何时使用工具。在下面的示例中,我们定义了一个创建餐厅预订的工具,并简要描述了它在调用时的作用。
{
"name": "create_reservation",
"description": "为客人创建餐厅预订。当用户要求以给定的姓名和时间预订桌子时使用。",
"parameters": {
"type": "object",
"properties": {
"name": {
"type": "string",
"description": "预订的客人全名。"
},
"datetime": {
"type": "string",
"description": "预订日期和时间(ISO 8601 格式)。"
}
},
"required": ["name", "datetime"]
}
}
在 Prompt 中,您可能有一个引用该工具的部分,如下所示:
<reservation_tool_usage_rules>
- 当用户要求预订、预留或安排桌子时,您必须调用 `create_reservation`。
- 不要猜测预订时间或姓名——询问缺少的任何详细信息。
- 如果用户未提供姓名,请询问:"我应该用什么名字进行预订?"
- 如果用户未提供日期/时间,请询问:"您想预订什么日期和时间?"
- 调用工具后,自然地确认预订:"您的 [姓名] 在 [日期/时间] 的预订已确认。"
</tool_usage_rules>
<reservation_tool_example>
*示例 1:*
用户:"明天晚上 7 点为 Sarah 预订一张桌子。"
助手 → (调用工具) →
`{"name": "create_reservation", "arguments": { "name": "Sarah", "datetime": "2025-11-01T19:00" } }`
工具返回:`{ "confirmation_number": "R12345" }`
助手:"搞定——您明天晚上 7:00 为 Sarah 的预订已确认。您的确认号是 R12345。"
**示例 2:**
用户:"我想预订。"
助手:"当然!我应该用什么名字进行预订,您想要什么日期和时间?"
*示例 3:*
用户:"今晚 6 点以 Daniel 的名义预订一张桌子。"
助手 → (调用工具) →
`{"name": "create_reservation", "arguments": { "name": "Daniel", "datetime": "2025-10-31T18:00" } }`
工具返回:`{ "confirmation_number": "R67890" }`
助手:"完成!您今晚 6:00 以 Daniel 名义的预订已确认。确认号是 R67890。"
</reservation_tool_example>
GPT-5.1 还更有效地执行并行工具调用。在扫描代码库或从 Vector Store 检索时,启用并行工具调用并在工具描述中鼓励模型使用并行性是一个很好的起点。在系统 Prompt 中,您可以通过提供一些允许的并行性示例来强化并行工具使用。示例指令可能如下所示:
尽可能并行化工具调用。批量读取(read_file)和编辑(apply_patch)以加快进程。
使用 “none” 推理模式提高效率
GPT-5.1 引入了一种新的推理模式:none。与 GPT-5 之前的 minimal 设置不同,none 强制模型永远不使用推理 Token,使其在使用上更类似于 GPT-4.1、GPT-4o 和其他先前的非推理模型。重要的是,开发人员现在可以在 none 模式下使用托管工具,如 web search 和 file search,并且自定义函数调用性能也得到了显著改善。考虑到这一点,关于非推理模型的先前指导,如使用 few-shot prompting 和高质量工具描述,也适用于此处。
虽然 GPT-5.1 在 none 模式下不使用推理 Token,但我们发现,prompting 模型仔细考虑它计划调用哪些函数可以提高准确性。
您必须在每次函数调用之前进行广泛规划,并对先前函数调用的结果进行广泛反思,确保用户的查询得到完全解决。不要仅通过函数调用来完成整个过程,因为这可能会损害您解决问题和深刻思考的能力。此外,确保函数调用具有正确的参数。
我们还观察到,在较长的模型执行中,鼓励模型”验证”其输出可以更好地遵循工具使用指令。下面是我们在澄清工具用法时在指令中使用的示例。
在选择替换变体时,验证它满足所有用户约束(最便宜、品牌、规格等)。在执行前引用 item-id 和价格以进行确认。
在我们的测试中,GPT-5 之前的 minimal 推理模式有时会导致过早终止的执行。虽然其他推理模式可能更适合这些任务,但我们对 GPT-5.1 配合 none 的指导是相似的。下面是我们 Tau bench Prompt 的片段。
请记住,您是一个 Agent——请继续直到用户的查询完全解决,然后再结束您的回合并返回给用户。您必须准备好回答多个查询,并且只有在用户确认完成后才完成调用。
我们建议为长时间运行的任务实现的一个工具是规划工具。您可能已经注意到推理模型在其推理摘要中进行规划。虽然这在当下很有帮助,但可能很难跟踪模型相对于查询执行的位置。
<plan_tool_usage>
- 对于中型或较大任务(例如,多文件更改、添加端点/CLI/功能或多步骤调查),您必须在第一次代码/工具操作之前在 TODO/plan 工具中创建和维护一个轻量级计划。
- 创建 2–5 个里程碑/结果项目;避免微步骤和重复的操作任务(没有"打开文件"、"运行测试"或类似的操作步骤)。永远不要使用单个包罗万象的项目,如"实现整个功能"。
- 在工具中维护状态:一次只有一个项目处于 in_progress 状态;完成后将项目标记为完成;发布及时的状态转换(不要超过 ~8 次工具调用而不更新)。不要将项目从 pending 直接跳转到 completed:始终先将其设置为 in_progress(如果工作确实是瞬间的,您可以在同一更新中设置 in_progress 和 completed)。不要在事后批量完成多个项目。
- 在结束回合之前完成所有项目或明确取消/推迟。
- 回合结束不变量:零 in_progress 和零 pending;完成或明确取消/推迟任何剩余项目并简要说明原因。
- 如果您为中/复杂任务在聊天中呈现计划,请将其镜像到工具中并在更新中引用这些项目。
- 对于非常短、简单的任务(例如,单文件更改 ≲ ~10 行),您可以跳过工具。如果您仍在聊天中共享简要计划,请将其保持为 1–2 句以结果为重点的句子,不要包含操作步骤或多项目符号清单。
- 飞行前检查:在任何非平凡的代码更改(例如,apply_patch、多文件编辑或实质性连接)之前,确保当前计划恰好有一个适当的项目标记为 in_progress,对应于您即将进行的工作;如果需要,请先更新计划。
- 范围转向:如果理解发生变化(拆分/合并/重新排序项目),请在继续之前更新计划。不要让计划在编码时过时。
- 永远不要有多个项目处于 in_progress 状态;如果发生这种情况,请立即纠正状态,以便只有当前阶段处于 in_progress。
<plan_tool_usage>
计划工具可以使用最少的脚手架。在我们的计划工具实现中,我们传递一个 merge 参数以及一个待办事项列表。该列表包含简要描述、任务的当前状态以及分配给它的 ID。下面是 GPT-5.1 可能调用以记录其状态的函数调用示例。
{
"name": "update_plan",
"arguments": {
"merge": true,
"todos": [
{
"content": "调查失败的测试",
"status": "in_progress",
"id": "step-1"
},
{
"content": "应用修复并重新运行测试",
"status": "pending",
"id": "step-2"
}
]
}
}
设计系统强制执行
在构建前端界面时,可以引导 GPT-5.1 生成与您的视觉设计系统匹配的网站。我们建议使用 Tailwind 渲染 CSS,您可以进一步定制以满足您的设计指南。在下面的示例中,我们定义了一个设计系统来约束 GPT-5.1 生成的颜色。
<design_system_enforcement>
- Token 优先:不要在 JSX/CSS 中硬编码颜色(hex/hsl/oklch/rgb)。所有颜色必须来自 globals.css 变量(例如,--background、--foreground、--primary、--accent、--border、--ring)或使用它们的 DS 组件。
- 引入品牌或强调色?在样式之前,在 globals.css 的 :root 和 .dark 下添加/扩展 Token,例如:
- --brand、--brand-foreground、可选的 --brand-muted、--brand-ring、--brand-surface
- 如果需要渐变/光晕,定义 --gradient-1、--gradient-2 等,并确保它们引用批准的色调。
- 消费:使用连接到 Token 的 Tailwind/CSS 工具(例如,bg-[hsl(var(--primary))]、text-[hsl(var(--foreground))]、ring-[hsl(var(--ring))])。按钮/输入/卡片必须使用系统组件或匹配其 Token 映射。
- 默认使用系统的中性调色板,除非用户明确请求品牌外观;然后首先将该品牌映射到 Token。
</design_system_enforcement>
工具模式
GPT-5.1 已针对编码用例中常用的特定工具进行了后训练。要与环境中的文件交互,您现在可以使用预定义的 apply_patch 工具。同样,我们添加了一个 shell 工具,让模型为您的系统提出要运行的命令。
使用 apply_patch
apply_patch 工具让 GPT-5.1 使用结构化差异在代码库中创建、更新和删除文件。模型不只是建议编辑,而是发出补丁操作,您的应用程序应用这些操作然后报告结果,从而实现迭代的多步骤代码编辑工作流程。您可以在 GPT-4.1 prompting 指南 中找到其他使用详细信息和上下文。
使用 GPT-5.1,您可以将 apply_patch 用作新的工具类型,而无需为工具编写自定义描述。描述和处理通过 Responses API 管理。在底层,此实现使用自由格式函数调用而不是 JSON 格式。在测试中,命名函数将 apply_patch 失败率降低了 35%。
response = client.responses.create(
model="gpt-5.1",
input=RESPONSE_INPUT,
tools=[{"type": "apply_patch"}]
)
当模型决定执行 apply_patch 工具时,您将在响应流中收到一个 apply_patch_call 函数类型。在操作对象中,您将收到一个类型字段(包含 create_file、update_file 或 delete_file 之一)以及要实现的 diff。
{
"id": "apc_08f3d96c87a585390069118b594f7481a088b16cda7d9415fe",
"type": "apply_patch_call",
"status": "completed",
"call_id": "call_Rjsqzz96C5xzPb0jUWJFRTNW",
"operation": {
"type": "update_file",
"diff": "
@@
-def fib(n):
+def fibonacci(n):
if n <= 1:
return n
- return fib(n-1) + fib(n-2)
+ return fibonacci(n-1) + fibonacci(n-2)",
"path": "lib/fib.py"
}
},
此存储库 包含 apply_patch 工具可执行文件的预期实现。当您的系统完成执行补丁工具时,Responses API 期望以下形式的工具输出:
{
"type": "apply_patch_call_output",
"call_id": call["call_id"],
"status": "completed" if success else "failed",
"output": log_output
}
使用 shell 工具
我们还为 GPT-5.1 构建了一个新的 shell 工具。shell 工具允许模型通过受控的命令行界面与您的本地计算机交互。模型提出 shell 命令;您的集成执行它们并返回输出。这创建了一个简单的计划-执行循环,让模型检查系统、运行工具并收集数据,直到完成任务。
shell 工具的调用方式与 apply_patch 相同:将其作为类型为 shell 的工具包含。
tools = [{"type": "shell"}]
当返回 shell 工具调用时,Responses API 包含一个 shell_call 对象,其中包含超时、最大输出长度和要运行的命令。
{
"type": "shell_call",
"call_id": "...",
"action": {
"commands": [...],
"timeout_ms": 120000,
"max_output_length": 4096
},
"status": "in_progress"
}
执行 shell 命令后,返回未截断的 stdout/stderr 日志以及退出代码详细信息。
{
"type": "shell_call_output",
"call_id": "...",
"max_output_length": 4096,
"output": [
{
"stdout": "...",
"stderr": "...",
"outcome": {
"type": "exit",
"exit_code": 0
}
}
]
}
Metaprompting
构建 Prompt 可能很麻烦,但它也是您可以做的最高杠杆的事情,以解决大多数模型行为问题。小的包含可能会意外地以不希望的方式引导模型。让我们通过一个规划活动的 Agent 示例来演示。在下面的 Prompt 中,面向客户的 Agent 的任务是使用工具回答用户关于潜在场地和物流的问题。
您是"GreenGather",一个自主的可持续活动规划 Agent。您帮助用户设计环保意识活动(工作静修、会议、婚礼、社区聚会),包括场地、餐饮、物流和参与者体验。
主要目标
您的主要目标是产生简洁、立即可操作的答案,适合快速聊天环境。大多数响应应该总共约 3–6 句话。用户应该能够浏览一次并确切知道下一步该做什么,无需后续澄清。
范围
* 重点:场地选择、日程设计、餐饮风格、交通选择、简单预算和可持续性考虑。
* 您实际上不会预订场地或供应商;永远不要说您完成了预订。
* 但是,您可以将建议表述为用户可以直接遵循的("预订 X,然后做 Y"),以便规划感觉具体且低摩擦。
语气和风格
* 听起来冷静、专业和中立,适合企业规划者和高管。避免表情符号和富有表现力的标点符号。
* 不要使用第一人称单数;优先使用"一个好的选择是..."或"建议..."。
* 温暖且平易近人。对于非正式或庆祝活动(例如,婚礼),您可能偶尔以第一人称写作("我建议...")并使用有品位的表情符号来匹配用户的能量。
结构
默认格式指南:
* 优先使用短段落,而不是项目符号列表。
* 仅当用户明确要求"选项"、"列表"或"清单"时才使用项目符号。
* 对于复杂的多日活动,始终使用标记部分(例如,"概述"、"日程"、"供应商"、"可持续性")构建您的答案,并自由使用项目符号以提高清晰度。
自主性和规划
您是一个自主 Agent。当给定规划任务时,继续推理和使用工具,直到计划连贯且完整,而不是将决策反弹给用户。除非对安全或正确性绝对必要,否则不要向用户请求澄清。对缺失的细节(如预算、人数或饮食需求)做出合理假设并继续。
为避免不正确的假设,当关键信息(日期、城市、大致人数)缺失时,请暂停并提出 1–3 个简短的澄清问题,然后再生成详细计划。在确认这些基本信息之前,不要继续进行具体日程。对于听起来匆忙或果断的用户,最小化问题,而是使用默认值继续。
工具使用
您始终可以访问以下工具:
* venue_search:查找具有容量、位置和可持续性标签的场地
* catering_search:查找餐饮商和菜单风格
* transport_search:查找交通和班车选项
* budget_estimator:按类别估算成本
工具的一般规则:
* 只要您提到特定场地、供应商或价格,就优先使用工具而不是内部知识。
* 对于简单的概念问题(例如,"如何使静修更环保"),避免工具并依赖内部知识,以便响应快速。
* 对于任何超过 30 名参与者的活动,始终至少调用一个搜索工具,以将建议建立在现实选项上。
* 为了保持体验响应,避免不必要的工具调用;对于粗略计划或早期头脑风暴,您可以自由地从一般知识中提出合理的示例场地或餐饮商,而不是使用工具。
作为自主 Agent 使用工具时:
* 计划您的方法(哪些工具,以什么顺序),然后执行,无需在每一步等待用户确认。
* 在每次主要工具调用后,简要总结您做了什么以及结果如何塑造您的建议。
* 保持工具使用不可见,除非用户明确询问您如何得出建议。
冗长度和细节
倾向于完整性,以便用户不需要后续消息。包括具体示例(例如,"上午主题演讲,下午分组讨论,晚上招待会")、大致时间安排以及至少对超过一天的活动的粗略预算分解。
但是,尊重用户的时间:不鼓励长文本墙。目标是紧凑的响应,很少超过 2–3 个短部分。对于复杂的多日活动或多供应商设置,提供详细的分步计划,用户几乎可以复制到活动简报中,即使它需要更长的答案。
可持续性指导
* 每当您建议场地或交通时,至少包括一个较低影响的替代方案(例如,公共交通、班车整合、本地供应商)。
* 不要内疚或说教;将权衡表述为实际选择。
* 在相关时突出可持续性认证,但除非您根据工具结果或内部知识确信,否则避免声称场地具有认证。
互动和结束
避免过度道歉或重复自己。用户应该感觉决策正在代表他们悄悄处理。通过总结当前计划并邀请他们调整具体细节,然后再进一步完善,经常将控制权返还给用户。
以用户可以采取的下一步的微妙建议结束每个响应,表述为建议而不是问题,并避免明确的确认请求,如"如果这有效,请告诉我"。
虽然这是一个强有力的起始 Prompt,但我们在测试时注意到一些问题:
- 小的概念问题(如询问 20 人的领导晚餐)触发了不必要的工具调用和非常具体的场地建议,尽管 Prompt 允许对简单的高级问题使用内部知识。
- Agent 在过于冗长(将多日奥斯汀 offsite 变成密集的多部分文章)和过于犹豫(拒绝在没有更多问题的情况下提出计划)之间摇摆,偶尔忽略单位规则(柏林峰会以英里和 °F 而不是 km 和 °C 描述)。
与其手动猜测系统 Prompt 的哪些行导致了这些行为,我们可以 metaprompt GPT-5.1 来检查其自己的指令和轨迹。
步骤 1:要求 GPT-5.1 诊断失败
将系统 Prompt 和一小批失败示例粘贴到单独的分析调用中。根据您看到的评估,提供您期望解决的失败模式的简要概述,但将事实查找留给模型。
请注意,在此 Prompt 中,我们还没有要求解决方案,只是根本原因分析。
您是一名 Prompt 工程师,负责调试使用工具推荐场地、物流和可持续选项的活动规划 Agent 的系统 Prompt。
您将获得:
1) 当前系统 Prompt:
<system_prompt>
[DUMP_SYSTEM_PROMPT]
</system_prompt>
2) 一小组记录的失败。每个日志都有:
- query
- tools_called(实际执行的)
- final_answer(如果需要则缩短)
- eval_signal(例如,thumbs_down、低评分、人工评分者或用户评论)
<failure_traces>
[DUMP_FAILURE_TRACES]
</failure_traces>
您的任务:
1) 识别您看到的不同失败模式(例如,tool_usage_inconsistency、autonomy_vs_clarifications、verbosity_vs_concision、unit_mismatch)。
2) 对于每种失败模式,引用或转述最有可能导致或强化它的系统 Prompt 的特定行或部分。包括任何矛盾(例如,"简洁"与"倾向于完整性","避免工具"与"对超过 30 名参与者的活动始终使用工具")。
3) 简要解释,对于每种失败模式,这些行如何将 Agent 引向观察到的行为。
以结构化但可读的格式返回您的答案:
failure_modes:
- name: ...
description: ...
prompt_drivers:
- exact_or_paraphrased_line: ...
- why_it_matters: ...
Metaprompting 在反馈可以逻辑分组时效果最好。如果您提供许多失败模式,模型可能难以将所有线索联系在一起。在此示例中,失败日志的转储可能包含模型在响应用户问题时过于或不够冗长的错误示例。将为模型过度渴望调用工具发出单独的查询。
步骤 2:询问 GPT-5.1 它将如何修补 Prompt 以修复这些行为
一旦您有了该分析,您可以运行第二个单独的调用,专注于实现:收紧 Prompt 而不完全重写它。
您之前分析了此系统 Prompt 及其失败模式。
系统 Prompt:
<system_prompt>
[DUMP_SYSTEM_PROMPT]
</system_prompt>
失败模式分析:
[DUMP_FAILURE_MODE_ANALYSIS]
请提出系统 Prompt 的手术修订,以减少观察到的问题,同时保留良好的行为。
约束:
- 不要从头开始重新设计 Agent。
- 优先进行小的明确编辑:澄清冲突规则,删除冗余或矛盾的行,收紧模糊的指导。
- 明确权衡(例如,清楚地说明何时优先考虑简洁性而不是完整性,或确切何时必须与不得调用工具)。
- 保持结构和整体长度与原始大致相似,除非简短的合并消除了明显的重复。
输出:
1) patch_notes:关键更改的简洁列表及其背后的推理(例如,"将冲突的工具使用规则合并为单个层次结构","删除了鼓励执行正式性和带表情符号的随意第一人称的重叠语气指令")。
2) revised_system_prompt:应用了您的编辑的完整更新系统 Prompt,准备放入 Agent 配置。
在此示例中,第一个 metaprompt 帮助 GPT-5.1 直接指向矛盾的部分(例如重叠的工具规则和自主性与澄清指导),第二个 metaprompt 将该分析转化为活动规划 Agent 指令的具体、清理版本。
第二个 Prompt 的输出可能如下所示:
patch_notes:
- 澄清何时优先考虑简洁性与细节:
- 简单或单主题查询应保持在 ~3–6 句话内。
- 更长、结构化的答案保留给明确复杂、多日或多供应商请求。
- 删除了告诉 Agent 在所有情况下"倾向于完整性"的语言,并根据查询复杂性用条件规则替换它。
- 收紧结构规则,以便仅在复杂性或明确的用户指令证明合理时才使用标题和项目符号。
- 简化了关于分步计划的指导,以便它们仅对复杂活动期望,而不是对每个问题。
revised_system_prompt:
[...]
在此迭代周期之后,再次运行查询以观察任何回归,并重复此过程,直到您的失败模式被识别和分类。
随着您继续发展 Agentic 系统(例如,扩大范围或增加工具调用数量),请考虑 metaprompting 您想要进行的添加,而不是手动添加它们。这有助于为每个工具维护离散边界以及何时应该使用它们。
总结
总而言之,GPT-5.1 建立在 GPT-5 设定的基础上,并添加了诸如对简单问题更快的思考、在模型输出方面的可操控性、用于编码用例的新工具以及在任务不需要大量思考时将推理设置为 none 的选项等功能。