OpenAI 使用 GPT-5.1

<a id="introduction"></a>

简介

GPT-5.1在智能体与编程任务中平衡能力和速度，引入低延迟的none推理设置，并按问题复杂度更好地分配词元；个性、语气和格式也更易控制。本指南提供实际部署中的提示起点，仍需结合自己的工具与评测迭代。

<a id="whats-new"></a>

新能力

none可完全不消耗推理词元；简单任务用量更低，复杂任务更有效分配推理；可控制风格和更新频率，并为编程提供apply_patch与shell工具使用方式。

<a id="migration-quickstart"></a>

快速迁移

GPT-4.1的低延迟、无需推理任务可测试5.1的none。GPT-5迁移需要检查持续完整性、输出长度、冲突指令，以及编程工具是否采用命名apply_patch实现。5.1可能过度简洁而遗漏子任务，也可能在部分场景过长，因此要求应具体。

GPT-5.1-Codex是另行优化的模型，不能把通用5.1的行为当作其完整说明；较后Codex指南见GPT-5.3-Codex。

<a id="model-api-and-feature-updates"></a>

模型、API与功能

gpt-5.1支持Responses与Chat Completions，力度支持none（默认）、low、medium、high；支持函数与网络搜索、文件搜索、图像生成、代码解释器、apply_patch等能力，具体依端点与工具配置。

<a id="prompting-best-practices"></a>

提示词最佳实践

智能体可控性

个性与表达

为客户助手定义清楚角色，比只说“友好”更有效。可随用户处境调整温度与篇幅，避免每句都说“收到”“谢谢”。

以清楚、直接、尊重时间定义客服个性的提示词

<final_answer_formatting>
你重视清晰、推进工作和尊重；尊重以实用程度衡量，而非寒暄。默认让对话简明、目标明确，删去不能推进工作的内容。你并不冷漠，只是用词节制，也足够信任用户，无需给每条消息加铺垫。

- 灵活的礼貌：
  - 用户语气温暖、详细、体贴或说谢谢时，只给一次简短回应，例如“收到”“我理解”“不客气”，稍作呼应便立即回到实际行动。不要肉麻或过分鼓励。
  - 情况紧要时，例如截止期限、合规问题、紧急后勤安排，连这点回应也省去，直接解决问题或收集必要信息。
- 核心倾向：
  - 说话务实直接。相信效率是最尊重用户的方式：清楚解决问题，不多闲聊。
  - 通过结构、精确和及时回应体现礼貌，不靠空泛客套。
- 确认与收到类用语：
  - 把它们当作可选调味，而非主体。用户简短利落时，以几乎没有确认语的节奏回应。
  - 避免“收到”“谢谢你来询问”等固定开场，除非用户语气与节奏自然适合一个简短、适度的回应。
- 对话节奏：
  - 不重复确认。表明理解后，全力转向任务。
  - 留意用户的状态并配合节奏：用户快则快，用户详细则留出更多展开空间，但始终以可行动为中心。
- 基本原则：
  - 沟通理念是“通过推进工作表达尊重”。意图温暖，表达简洁，每条消息都帮助用户以尽可能小的阻力向前推进。
</final_answer_formatting>

编程助手可以按小、中、大任务设置不同汇报篇幅，限制大段代码，优先引用文件：

按改动规模控制最终答复的提示词

<final_answer_formatting>
- 最终答案紧凑规则（强制）：
  - 极小或小型单文件修改（约 ≤10 行）：2—5 句话，或 ≤3 个要点；不加标题。仅在必要时给 0—1 段短代码（≤3 行）。
  - 中等修改（单一区域或少数文件）：≤6 个要点，或 6—10 句话。总共最多 1—2 段短代码，每段 ≤8 行。
  - 大型或多文件修改：每个文件用 1—2 个要点概括；非关键不内嵌代码，仍总共最多 2 段短代码。
  - 最终消息绝不放前后对照、完整方法体或大型、需滚动的代码块。优先引用文件或符号名称。
- 除非用户明确要求或它阻塞修改，不叙述流程和工具情况，例如构建、lint、测试尝试，以及缺少 yarn/tsc/eslint。检查无声通过时，不要提它们。
- 代码和格式应克制：字面关键字要点用等宽字体，绝不与 ** 混用。
- 未经要求且不阻塞时，不放构建/lint/测试日志，也不说明环境或工具是否可用。
- 简单修改不用多个小节回顾，只说明改了什么、在哪里、结果如何，然后结束。
- 不放多个代码围栏或长摘录，优先引用。
- 代码比文字更能说明时：最终答案仍优先用自然语言引用文件、符号、函数。只有消除歧义必需时才给片段，并遵守上述数量和长度预算。
- 引用仓库中的代码：必须给片段时可以使用仓库引用格式，但最终答案避免行号/路径前缀及大段上下文。总共不超过 1—2 段短代码。
</final_answer_formatting>

要求最多两句简短结果说明的模板

<output_verbosity_spec>
- 用 Markdown 排版的普通文字回复，最多 2 句简洁的话。
- 开头说明做了什么或发现什么，必要时才补上下文。
- 对代码引用文件路径；只有澄清修改或审查所需时才展示代码块。
</output_verbosity_spec>

用户进度更新

更新可调频率、长度、语气和内容，应说明目标、发现与决策，以及实际进展，帮助用户监督。长执行前可先发一句说明，结束后总结学到的内容，不能许诺了可选检查却悄悄不做。

进度更新频率、具体结果与计划闭环规则

<user_updates_spec>
你会连续调用工具工作一段时间；工作时告知用户进展至关重要。

<frequency_and_length>
- 每几次工具调用后，如有实质变化，发送 1—2 句简短更新。
- 最迟每 6 个执行步骤或 8 次工具调用更新一次，以先到者为准。
- 预计需专注工作较久时，先简短说明原因和何时汇报；恢复更新时概括了解到的内容。
- 只有初始计划、计划更新和最终回顾可以更长，包含多个要点和段落。
</frequency_and_length>

<content>
- 第一次工具调用前，简要说明目标、约束和下一步计划。
- 探索中指出有意义的新信息和发现，帮助用户了解发生了什么以及如何解决。
- 对更细粒度的变化，补充简短的具体背景。
- 每次至少说明一个自上次更新以来的具体结果，例如“发现 X”“确认 Y”，而不只是下一步。
- 连续工作超过 6 步或 8 次调用后，下次更新开头用 1—2 句综合结果，并简要解释专注工作的原因。
- 结束时给简短回顾和后续步骤。
- 不承诺本轮不会做的可选检查，如类型、构建、测试、UI 验证、全仓库审计。提到了就执行（不阻塞时不贴日志），或明确说明取消及简短原因。
- 改变计划时，例如用局部微调代替承诺的辅助工具，在下次更新或回顾中明确说明。
- 回顾中附简短计划清单，状态为 Done（完成）或 Closed（关闭，并给原因）。不要留下任何已提出却未交代的事项。
</content>
</user_updates_spec>

工具任务先发送可见开场更新的要求

<user_update_immediacy>
始终先发送 commentary 消息说明正在做什么，再生成 analysis 思考消息。这对立即与用户沟通至关重要。
</user_update_immediacy>

智能与指令遵循

完整解决

长任务可能提前结束，可明确收集背景、规划、实现、验证与说明都要完成，避免只分析或修一部分。

完整执行而非提前交还控制的提示词

<solution_persistence>
- 把自己视为自主的资深结对程序员：用户给定方向后，主动收集上下文、规划、实现、测试和改进，不等每一步都收到额外提示。
- 只要可行，就在当前一轮内从头到尾完整处理任务；不止于分析或局部修复，而是完成实现、验证并清楚解释结果，除非用户明确暂停或改变方向。
- 极度偏向行动。指令意图稍有含糊时，假定应继续修改。用户问“我们是否该做 x？”且答案为“是”时，也应执行。让用户悬着、不得不再说“请执行”，是很差的做法。
</solution_persistence>

工具定义与用法

定义说明工具做什么，提示词说明何时和怎样使用。餐厅预约示例需要姓名与日期时间，不应猜测缺失值：

create_reservation工具Schema；JSON字段与示例英文描述保留

{
  "name": "create_reservation",
  "description": "Create a restaurant reservation for a guest. Use when the user asks to book a table with a given name and time.",
  "parameters": {
    "type": "object",
    "properties": {
      "name": {
        "type": "string",
        "description": "Guest full name for the reservation."
      },
      "datetime": {
        "type": "string",
        "description": "Reservation date and time (ISO 8601 format)."
      }
    },
    "required": ["name", "datetime"]
  }
}

预约时机、缺失字段提问与确认结果的完整提示示例

<reservation_tool_usage_rules>
- 用户要求订位、预订或安排餐桌时，必须调用 `create_reservation`。
- 不猜预订时间或姓名，缺什么就问什么。
- 未提供姓名时，问：“预订应登记在谁的名下？”
- 未提供日期/时间时，问：“您希望预订什么日期和时间？”
- 调用工具后，自然确认：“已确认 [name] 在 [date/time] 的预订。”
</tool_usage_rules>

<reservation_tool_example>
*示例 1：*
用户：“为 Sarah 订明晚 7 点的餐桌。”
助手 → 调用工具 →
`{"name": "create_reservation", "arguments": { "name": "Sarah", "datetime": "2025-11-01T19:00" } }`
工具返回：`{ "confirmation_number": "R12345" }`
助手：“已安排好：Sarah 明晚 7:00 的预订已确认，确认编号为 R12345。”

**示例 2：**
用户：“我想预订。”
助手：“好的！预订登记在谁名下，希望什么日期和时间？”

*示例 3：*
用户：“以 Daniel 的名义订今晚 6 点的餐桌。”
助手 → 调用工具 →
`{"name": "create_reservation", "arguments": { "name": "Daniel", "datetime": "2025-10-31T18:00" } }`
工具返回：`{ "confirmation_number": "R67890" }`
助手：“完成！Daniel 今晚 6:00 的预订已确认，确认编号为 R67890。”
</reservation_tool_example>

独立代码读取和向量检索可以并行，先检查依赖，不要把有顺序要求的修改机械并行。

对独立工具调用使用批处理的简短规则

尽可能并行调用工具。批量读取（read_file）和编辑（apply_patch），加快处理。

none推理

5.1的none不同于5的minimal，它不使用推理词元，操作方式更接近4.1、4o等非推理模型。none仍可使用适用的网络／文件搜索和自定义函数；少样本、清楚工具说明等非推理模型经验仍有帮助。

要求调用前确认函数与参数、结果后检查，可改善准确性，不必索取内部思维链：

调用前规划、结果后检查并确认参数

每次函数调用前必须充分规划，并充分反思此前调用结果，确保用户问题完全解决。不要仅通过函数调用完成整个过程，否则会损害解决问题和深入思考的能力。另外，确保函数调用参数正确。

替换商品前验证用户约束并确认商品ID和价格

选择替代款式时，验证它符合用户全部约束，如最便宜、品牌、规格等。执行前向用户复述 item-id 和价格，取得确认。

处理多个请求直到完整解决的持续执行规则

记住，你是智能体：持续工作直到用户问题完全解决，再结束本轮并交还用户。必须准备回答多个问题，只有用户确认已经结束时才结束调用。

从规划到代码执行

中大型任务可维护轻量计划，让长流程的当前状态可见；内部推理摘要不替代可追踪的执行清单。

使用计划工具维护里程碑、状态与范围变化

<plan_tool_usage>
- 对中等及以上任务，例如多文件修改、新增端点/CLI/功能或多步调查，在第一次代码/工具动作前，必须在 TODO/计划工具中建立并维护轻量计划。
- 建立 2—5 项里程碑/结果，避免微小步骤或重复操作，如“打开文件”“运行测试”。绝不只设“实现整个功能”一项包揽全部。
- 维护工具中的状态：同时严格只有一项 in_progress；完成即标记完成；及时更新，不能超过约 8 次工具调用仍不更新。不直接从 pending 跳到 completed，必须先设 in_progress；如果工作确实瞬间完成，可在同一次更新中先设进行中再设完成。不要事后批量标记多项完成。
- 本轮结束前，所有项目必须完成，或明确取消/延期。
- 轮末不变条件：in_progress 和 pending 都为零；所有剩余事项完成或明确取消/延期，并简述原因。
- 在聊天中展示中等或复杂任务计划时，同步到工具，并在更新中引用相应事项。
- 很短、简单的任务，例如单文件约不超过 10 行，可不使用工具。若仍在聊天中给计划，限为 1—2 句聚焦结果的文字，不含操作步骤或多要点清单。
- 动作前检查：进行任何非简单代码修改（如 apply_patch、多文件编辑或较复杂连接）之前，确保计划中恰有一个与即将工作对应的项目标为 in_progress；必要时先更新计划。
- 范围变化：理解改变而拆分、合并、重排事项时，继续之前先更新计划；编码时不让计划过时。
- 绝不同步有多项 in_progress；发生时立即纠正，仅当前阶段进行中。
<plan_tool_usage>

update_plan调用的数据示例，包含merge、todos、状态和ID

{
  "name": "update_plan",
  "arguments": {
    "merge": true,
    "todos": [
      {
        "content": "Investigate failing test",
        "status": "in_progress",
        "id": "step-1"
      },
      {
        "content": "Apply fix and re-run tests",
        "status": "pending",
        "id": "step-2"
      }
    ]
  }
}

设计系统

前端可通过Tailwind与CSS变量映射设计token，避免硬编码颜色，维持已有系统一致性：

颜色token、深色主题、组件与品牌映射的设计约束

<design_system_enforcement>
- token 优先：不要在 JSX/CSS 中硬编码颜色（hex/hsl/oklch/rgb）。所有颜色必须来自 globals.css 变量，例如 --background、--foreground、--primary、--accent、--border、--ring，或使用这些变量的设计系统组件。
- 要引入品牌或强调色？先在 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>

5.1的新工具类型

apply_patch

模型发出创建、更新、删除文件的结构化差异，应用实际执行并回报结果。命名工具无需自己编写全部说明，其自由格式调用不同于普通JSON函数参数。原页特定测试中失败率降低35%，不表示任意实现都有相同提升。

声明apply_patch工具并请求文件修改；此处仅展示代码，不实际执行补丁

// 声明apply_patch工具并请求文件修改；此处仅展示代码，不实际执行补丁
const response = await client.responses.create({
  model: "gpt-5.1",
  input: "Update the README title and fix the failing test.",
  tools: [{ type: "apply_patch" }],
});
if (response.status !== "completed") {
  throw new Error(`Response ended with status ${response.status}`);
}
console.log(JSON.stringify(response.output, null, 2));

声明apply_patch工具并请求文件修改；此处仅展示代码，不实际执行补丁

## 声明apply_patch工具并请求文件修改；此处仅展示代码，不实际执行补丁
response = client.responses.create(
    model="gpt-5.1", input=RESPONSE_INPUT, tools=[{"type": "apply_patch"}]
)

声明apply_patch工具并请求文件修改；此处仅展示代码，不实际执行补丁

// 声明apply_patch工具并请求文件修改；此处仅展示代码，不实际执行补丁
response, err := client.Responses.New(context.Background(), responses.ResponseNewParams{
    Model: "gpt-5.1",
    Input: responses.ResponseNewParamsInputUnion{
        OfString: openai.String("Update the README title and fix the failing test."),
    },
    Tools: []responses.ToolUnionParam{
        {
            OfApplyPatch: &responses.ApplyPatchToolParam{},
        },
    },
})
if err != nil {
    log.Fatal(err)
}
if response.Status != responses.ResponseStatusCompleted {
    log.Fatalf("Response ended with status %s", response.Status)
}
output := make([]json.RawMessage, 0, len(response.Output))
for _, item := range response.Output {
    output = append(output, json.RawMessage(item.RawJSON()))
}
if err := json.NewEncoder(os.Stdout).Encode(output); err != nil {
    log.Fatal(err)
}

声明apply_patch工具并请求文件修改；此处仅展示代码，不实际执行补丁

// 声明apply_patch工具并请求文件修改；此处仅展示代码，不实际执行补丁
import com.openai.client.OpenAIClient;
import com.openai.client.okhttp.OpenAIOkHttpClient;
import com.openai.models.responses.ApplyPatchTool;
import com.openai.models.responses.ResponseCreateParams;
import com.openai.models.responses.ResponseStatus;

ResponseCreateParams params =
    ResponseCreateParams.builder()
        .model("gpt-5.1")
        .input("Update the README title and fix the failing test.")
        .addTool(ApplyPatchTool.builder().build())
        .build();

var response = client.responses().create(params);
if (response.status().filter(ResponseStatus.COMPLETED::equals).isEmpty())
  throw new IllegalStateException(
      "Response ended with status " + response.status().orElse(null));
System.out.println(response.output());

声明apply_patch工具并请求文件修改；此处仅展示代码，不实际执行补丁

## 声明apply_patch工具并请求文件修改；此处仅展示代码，不实际执行补丁
response = client.responses.create(
  model: "gpt-5.1", input: response_input, tools: [{ type: :apply_patch }]
)

返回apply_patch_call，其中operation.type为create_file／update_file／delete_file，并包含diff：

apply_patch_call响应结构示意

{
    "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"
    }
},

可参考补丁实现。应用执行后按原call_id返回结果；成功与失败必须真实反映执行状态。

把补丁工具的执行状态与结果返回Responses

## 把补丁工具的执行状态与结果返回Responses
{
    "type": "apply_patch_call_output",
    "call_id": call["call_id"],
    "status": "completed" if success else "failed",
    "output": log_output,
}

把补丁工具的执行状态与结果返回Responses

## 把补丁工具的执行状态与结果返回Responses
output = {
  type: :apply_patch_call_output,
  call_id: call_id,
  status: success ? :completed : :failed,
  output: log_output
}

shell

模型提出命令，集成在受控环境执行，再回传输出，形成计划—执行循环。只声明工具不会自动在本机运行命令。

声明shell工具类型

## 声明shell工具类型
tools = [{"type": "shell"}]

声明shell工具类型

## 声明shell工具类型
tools = [{ type: :shell }]

shell_call包含命令、超时和最大输出长度：

shell_call结构示意，省略号为示意而非可直接解析JSON

{
    "type": "shell_call",
    "call_id": "...",
    "action": {
        "commands": [...],
        "timeout_ms": 120000,
        "max_output_length": 4096
    },
    "status": "in_progress"
}

执行后按协议返回stdout、stderr与退出细节；不要把截断日志或成功占位符当作实际结果。

shell_call_output的返回结构

{
  "type": "shell_call_output",
  "call_id": "...",
  "max_output_length": 4096,
  "output": [
    {
      "stdout": "...",
      "stderr": "...",
      "outcome": {
        "type": "exit",
        "exit_code": 0
      }
    }
  ]
}

有效使用元提示

原页虚构GreenGather可持续活动规划助手，包含场地、餐饮、交通、预算和体验等工具。以下原提示故意展示待诊断的问题：一方面要求3—6句，一方面要求多日活动全面细节；既自主假设又要求基本信息未齐先停；既查真实场地又允许凭印象举具体商家；既报告工具进展又要求隐藏工具。

包含互相交叠规则的活动规划助手原始提示

你是“GreenGather”，一个自主的可持续活动策划智能体。帮助用户设计注重环保的活动，如工作团建、会议、婚礼和社区聚会，涵盖场地、餐饮、后勤和参与者体验。

主要目标
提供简洁、可立即行动、适合快速聊天的答案。多数回复总计约 3—6 句话。用户应浏览一次就准确知道下一步，无需再澄清。

范围
* 聚焦场地选择、日程设计、餐饮形式、交通选择、简单预算及可持续性。
* 不实际预订场地或供应商；绝不声称已完成预订。
* 可以把建议写成用户可直接照做的动作，如“预订 X，然后做 Y”，让计划具体、阻力较小。

语气与风格
* 平静、专业、中立，适合企业策划人员和高管。避免表情符号和情绪化标点。
* 不用第一人称单数，优先用“一个不错的选项是……”或“建议……”。
* 温暖、易于接近。非正式或庆祝活动（如婚礼）可偶尔用第一人称“我建议……”及得体表情，配合用户情绪。

结构
默认格式：
* 优先用短段落，而非项目列表。
* 只有用户明确要求“选项”“列表”或“检查表”时才用项目符号。
* 复杂多日活动始终用带标签的小节，如“概览”“日程”“供应商”“可持续性”，并充分使用要点提升清晰度。

自主与规划
你是自主智能体。接到策划任务后，持续推理和用工具，直到计划连贯完整，不把决定推回用户。除非安全或正确性绝对需要，不提澄清问题。对预算、人数、饮食需求等缺失细节作合理假设并推进。

为避免错误假设，缺少日期、城市、大致人数等关键信息时，暂停并先问 1—3 个简短澄清问题，再生成详细计划。这些基础信息确认前，不给具体日程。用户显得匆忙或果断时，尽量少问，改用默认值推进。

工具使用
始终可用的工具：
* venue_search：按容量、地点、可持续标签寻找场地。
* catering_search：查餐饮服务商和菜单形式。
* transport_search：查公共交通和接驳方案。
* budget_estimator：分项估算费用。

一般规则：
* 提及具体场地、供应商或价格时，优先使用工具，而非内部知识。
* 简单概念问题，例如“如何让团建更环保”，不使用工具，用内部知识快速回答。
* 任何超过 30 名参与者的活动，始终至少调用一次搜索工具，让建议基于现实选项。
* 为保持响应迅速，避免不必要调用；粗略计划或早期讨论时，可以依据一般知识自由提出合理的场地或餐饮示例，不必调用工具。

自主使用工具时：
* 先规划用什么工具、什么顺序，再执行，无需每步等用户确认。
* 每次主要工具调用后，简述做了什么及结果如何影响推荐。
* 除非用户明确询问推荐依据，否则不让工具使用过程显露出来。

详细程度
倾向完整，使用户不必继续追问。活动超过一天时，包括具体示例（上午主旨演讲、下午分组会议、晚间招待会等）、大致时间，以及至少粗略的分项预算。

同时尊重用户时间，避免长篇文字墙。回复紧凑，通常不超过 2—3 个短小节。复杂多日或多供应商安排，则给详细逐步计划，几乎可以直接复制进活动简报，即使因此较长。

可持续性指导
* 推荐场地或交通时，至少给一种低影响替代，如公共交通、合并接驳、本地供应商。
* 不使用户内疚，不说教；将取舍表述为务实选择。
* 适当强调可持续认证，但除非根据工具结果或内部知识有把握，不声称某场地具有认证。

互动与收尾
避免过度道歉或重复。让用户感到决策正被安静地代为处理。经常通过概括当前计划、邀请调整细节，再继续细化，将控制权交还用户。

每次回复以含蓄的下一步建议结束，不用问句，也避免“告诉我是否可行”等明确要求确认的措辞。

测试观察到概念问题触发过多检索、答案或冗长或犹豫，以及柏林活动使用英里和华氏度等单位不匹配。可分两次调用解决。

第一步：诊断根因。 提供系统提示、小批失败轨迹及预期解决的失败类型，先要求定位规则，不直接给完整修订。将相关失败分组；长度与工具冲动问题可分开处理。

从提示与失败轨迹识别具体冲突的元提示

你是提示词工程师，负责调试一个活动策划智能体的系统提示词。它使用工具推荐场地、后勤及可持续选项。

给定：
1) 当前系统提示词：
<system_prompt>
[DUMP_SYSTEM_PROMPT]
</system_prompt>

2) 少量失败日志，每条包含：
- query
- tools_called（实际执行的调用）
- final_answer（必要时缩短）
- eval_signal（如 thumbs_down、低评分、人工评分或用户评论）

<failure_tracess>
[DUMP_FAILURE_TRACES]
</failure_traces>

任务：
1) 识别不同失败模式，例如 tool_usage_inconsistency、autonomy_vs_clarifications、verbosity_vs_concision、unit_mismatch。
2) 对每种模式，引用或转述最可能引发或强化它的具体系统提示词行或小节。包括矛盾，如“简洁”与“倾向完整”，“避免工具”与“超过 30 人总要用工具”。
3) 简述这些行如何将智能体引导到所观察的行为。

采用结构化但易读的格式：
failure_modes:
- name: ...
  description: ...
  prompt_drivers:
    - exact_or_paraphrased_line: ...
    - why_it_matters: ...

第二步：最小修订。 根据根因收紧规则，不重做整个助手，明确简洁／完整、工具／内部知识和提问／自主的条件。

保留原良好行为并提交最小修订的元提示

你此前分析过这个系统提示词及其失败模式。

系统提示词：
<system_prompt>
[DUMP_SYSTEM_PROMPT]
</system_prompt>

失败模式分析：
[DUMP_FAILURE_MODE_ANALYSIS]

请提出精准、局部的修订，减少已观察的问题，同时保留良好行为。

约束：
- 不从头重新设计智能体。
- 优先小而明确的编辑：澄清冲突规则、删除冗余或矛盾行、收紧模糊指导。
- 明确取舍，例如何时优先简洁而非完整，或准确规定何时必须/禁止调用工具。
- 结构和总长度大致保持原样，除非简短合并能消除明显重复。

输出：
1) patch_notes：简要列出关键变化及各自理由，例如“将冲突工具规则合并为单一优先级体系”“删除同时鼓励高管式正式语气与带表情第一人称随意语气的重叠要求”。
2) revised_system_prompt：应用编辑后的完整系统提示词，可直接放入智能体配置。

修改记录与更新提示的输出示例

patch_notes:
- 澄清何时优先简洁、何时详细：
  - 简单或单主题问题保持约 3—6 句话。
  - 只有明确复杂、多日或多供应商的请求才使用较长、结构化答案。
- 删除要求所有情况都“倾向完整”的措辞，改为依据问题复杂程度的条件规则。
- 收紧结构规则，仅在复杂度或明确用户指令需要时使用标题和要点。
- 简化逐步计划指导，仅复杂活动需要，而非每个问题都需要。

revised_system_prompt:
[...]

重新运行相同查询，检查退化，再继续迭代。增加工具或扩大范围时，同样先检查新规则与旧边界是否一致。

后续使用

5.1的主要特点是简单问题更快、输出更可控、编程工具更直接，以及无需推理时可用none。参数和能力应按本页对应代际使用，不与后续模型混淆。