修炼AI技能
AI 教程 / Prompt 工程 / Agent 系统提示词设计：角色、约束与工具调用规范

Agent 系统提示词设计：角色、约束与工具调用规范

在构建 AI Agent 时，系统提示词（System Prompt）是开发者写给药用大模型看的「说明书」，它决定了 Agent 是谁、能做什么、如何调用工具、以什么格式作答、遇到异常怎么处理。本文从概念区分讲起，拆解系统提示词的七个核心模块，给出可复用的编写模板、一个多工具 Agent 的完整示例，以及常见反模式与调试技巧。

什么是 Agent System Prompt 与 User Prompt 的区别

理解两者边界，是写好系统提示词的前提。

系统提示词（System Prompt）由开发者在请求最前面注入，对一次会话内的所有对话轮次恒定生效。它承载的是「规则与身份」：角色设定、能力边界、工具调用规范、输出格式、安全约束。在 OpenAI Agents SDK 中，这部分被称为 instructions，是 Agent 的三大原语之一（其余两者是模型与 tools）。

用户提示词（User Prompt）由终端用户在每一轮输入，承载的是「需求与数据」：具体要查什么、生成什么、修改什么。用户提示词随轮次变化，而系统提示词通常保持不变。

二者的关键区别可用一句话概括：系统提示词定义 Agent 的「行为边界」，用户提示词提供 Agent 的「任务内容」。如果把 Agent 比作一位员工，系统提示词是他的岗位说明书与公司制度，用户提示词是今天派给他的具体工单。

需要特别注意：当 Agent 具备工具调用能力时，框架往往会在底层自动拼接一段「启用工具」的系统提示（Anthropic 文档明确说明，传入 tools 后 API 会自动附加一段用于开启工具使用的特殊系统提示）。因此，你在 instructions 中写的约束，会与框架注入的提示共同生效，二者不应冲突。

核心模块

一个健壮的 Agent 系统提示词，通常包含以下七个模块。你可以按场景增减，但角色、目标、工具约束与输出格式四者几乎不可或缺。

角色身份

用一两句话明确 Agent 的「身份」与「专业立场」。角色设定影响措辞、推理口径与判断标准。

你是一名资深数据分析助手，服务于电商运营团队。你熟悉销售漏斗、留存与复购指标，回答时以业务可行动的结论为先，避免堆砌术语。

要点：写明领域、服务对象、语气基调。不要写「你是一个有用的助手」这种空洞表述，它无法约束行为。

全局目标与任务边界

给出一句话总目标，以及「成功完成」的判定标准，同时明确「不在范围内」的事，防止目标漂移。

总目标：帮助用户基于提供的销售数据完成归因分析与策略建议。
成功标准：每次回复都给出可验证的结论，并标明所依据的数据或工具结果。
不在范围：不替代人工决策、不提供法律与财务合规意见、不访问用户未授权的数据源。

Anthropic 在「Building Effective Agents」中强调，应从最简单的方案出发，仅在确有必要时才引入 Agent 化复杂度。把目标边界写清楚，本身就是抑制过度自主、控制成本与风险的有效手段。

能力边界

列出 Agent 被允许与禁止的能力，尤其要约束「会对外部世界产生副作用」的操作。

允许：调用只读查询类工具、生成分析报告、向用户追问以澄清需求。
禁止：在未获得用户明确确认前执行写操作（如删除、发送、下单）；读取会话上下文之外的用户隐私字段；以任何形式输出其他用户的个人数据。

对高影响工具，OpenAI 的工具文档建议优先采用「直接调用并人工审批」的方式，而不是把它塞进自动编排程序里无人值守地执行。

工具清单与调用约束

这是工具型 Agent 系统提示词的核心。要写清「有哪些工具、各自干什么、何时调用、参数如何填、有无顺序或并发限制」。

可用工具：
1. query_sales(start_date, end_date, dimension)：查询指定区间与维度的销售数据，只读。
2. query_traffic(channel, date)：查询某渠道某日流量，只读。
3. draft_report(outline)：依据给定大纲生成报告草稿。

调用约束：
- 先调用查询类工具核实数据，再生成任何结论；禁止凭空编造指标。
- query_sales 与 query_traffic 可并行调用。
- 仅当数据齐备后才调用 draft_report。
- 若工具返回空或报错，向用户说明并询问是否缩小查询范围，不得静默重试超过两次。

根据 OpenAI Agents SDK 的官方建议，当工具数量较多时，应优先使用命名空间（namespace）组织工具，并尽量让每个命名空间保持较小规模（经验值是少于 10 个函数），以便模型获得更清晰的高层检索面、节省 token。工具的描述与参数说明要写清楚，因为模型正是依据 description 与 input_schema 来决定是否调用以及怎样传参。

输出格式规范

明确结构化输出的字段、语言与长度，便于下游程序解析，也降低歧义。

输出要求：
- 默认以 Markdown 回复，结论置于开头，证据列于其后。
- 当任务要求机器可读结果时，仅输出如下 JSON，不要附加解释文字：
  {"summary": "字符串", "metrics": [{"name": "字符串", "value": 数字}], "confidence": 0到1之间的数字}
- 所有数值保留两位小数，并标注单位。
- 引用工具结果时，注明来源工具名与查询参数。

若使用支持严格模式的接口，可开启 strict: true（以 Anthropic 为例），强制工具调用与输出严格遵循 schema，避免格式漂移导致解析失败。

安全与拒答规则

明确列出拒答类别与拒答话术，让 Agent 在边界处行为可预期。

拒答类别：违法违规内容、侵犯他人隐私或知识产权、越权操作、超出本助手领域且可能误导用户的专业建议。
拒答方式：用一句话说明无法协助的原因，并给出安全的替代方向，不得输出拒绝原因之外的多余内容。

安全规则要写得具体，而非只写「请遵守安全规范」。具体规则更容易被模型稳定遵循。

错误处理与重试

工具可能失败、超时或返回异常。系统提示词应规定回退路径与重试上限，避免 Agent 陷入无效循环。

错误处理：
- 工具调用失败：最多自动重试一次；仍失败则向用户说明，并建议调整参数或联系支持。
- 超时：单次工具调用默认超时由运行时设定，超时即视为失败，进入上述重试路径。
- 结果异常（如字段缺失）：先尝试补全查询，无法补全则明确标注「数据不完整」，不臆造数值。

OpenAI 的函数工具支持通过 failure_error_function 把错误信息以受控方式回传给模型，使模型能据此调整而非崩溃；这一机制的存在，也说明错误处理应在提示词与代码两层同时覆盖。

编写模板

将上面七个模块合并，得到一份可复制的模板。使用时把方括号内容替换为你的实际设定。

## 角色身份
你是[领域][角色]，服务于[对象]。你的语气基调是[基调]。

## 全局目标
总目标：[一句话目标]
成功标准：[如何判定完成]
不在范围：[明确排除的事项]

## 能力边界
允许：[可做的操作]
禁止：[不可做的操作，尤其是有副作用的操作]

## 工具清单与调用约束
可用工具：
- [tool_name(params)]：[用途，注明只读或可写]
调用约束：
- [何时调用、顺序、并发、重试限制]

## 输出格式
- [默认语言/结构]
- [结构化字段定义，如要求 JSON]
- [数值、单位、引用来源的规则]

## 安全与拒答
拒答类别：[具体类别]
拒答方式：[话术要求]

## 错误处理
- 失败：[重试上限与回退]
- 超时：[处理方式]
- 异常结果：[补全或标注策略]

多工具 Agent 示例

下面是一个面向电商运营的「分析助手」系统提示词样例，整合了角色、目标、工具约束、输出格式与安全规则。可直接作为起点修改。

你是一名电商运营分析助手，服务于中型店铺的运营团队。你熟悉销售、流量与转化指标，回答以业务可行动的结论为先。

总目标：基于用户提供的店铺数据接口，完成指标归因并给出运营建议。
成功标准：每次回复都给出可验证结论，并标明所依据的工具与查询参数。
不在范围：不提供法律、税务、医疗建议；不访问用户未授权的数据源。

允许：调用只读查询工具、生成分析结论、追问以澄清需求。
禁止：在用户确认前执行任何写操作（如下单、改价、群发）；输出其他用户的隐私数据。

可用工具：
1. query_sales(start_date, end_date, dimension): 查询销售数据，只读。
2. query_traffic(channel, date): 查询渠道流量，只读。
3. draft_report(outline): 依据大纲生成报告，只读。

调用约束：
- 先调用查询工具核实数据，再给出任何结论；严禁编造指标。
- query_sales 与 query_traffic 可并行调用。
- 数据齐备后再调用 draft_report。
- 工具报错或返回空时，向用户说明并建议缩小范围，自动重试不超过一次。

输出格式：
- 默认 Markdown，结论在前，证据在后。
- 要求机器可读时仅输出如下 JSON，不附加解释：
  {"summary": "字符串", "metrics": [{"name": "字符串", "value": 数字}], "confidence": 0到1}
- 数值保留两位小数并标注单位，引用工具结果须注明来源工具与参数。

安全与拒答：
- 拒答类别：违法违规、侵犯隐私、越权操作、跨领域误导建议。
- 拒答方式：一句话说明原因并给安全替代方向，不输出多余内容。

错误处理：
- 失败：自动重试一次，仍失败则说明并建议调整参数。
- 异常结果：尝试补全查询，无法补全则标注「数据不完整」，不臆造数值。

该示例体现了本文主张的「指令即契约」原则：模型依据工具 description 自主决定调用时机，而系统提示词负责划定边界、顺序与回退，二者配合形成可控的 Agent 行为。

常见反模式与调试技巧

常见反模式

  1. 指令过长且自相矛盾：同一份提示里既要求「详尽」又要求「极简」，模型只能在冲突中择一，结果不稳定。
  2. 把用户数据写进系统提示：系统提示对所有轮次恒定生效，若在其中混入用户隐私或临时上下文，既带来泄露风险，也会污染后续所有对话。用户数据应走用户提示或工具结果通道。
  3. 缺少输出格式约束：未规定结构时，模型自由发挥，下游解析失败，需反复补提示。
  4. 无工具调用约束：只列出工具却不规定「何时调用、能否并行、失败怎么办」，模型可能乱调用或在报错后空转。
  5. 忽略错误处理：一旦工具超时或返回异常，Agent 陷入重试循环，徒增延迟与成本。
  6. 安全规则过于笼统：只写「注意安全」，无法被稳定遵循；应枚举具体拒答类别与话术。

调试技巧

  • 看实际注入内容：借助框架的 tracing 或日志，检查每一轮真正发给模型的「系统提示加工具定义」，确认你写的约束没有被框架默认提示覆盖或冲突。
  • 小样本评测：准备 10 到 20 条代表性任务，固定模型与工具，对比修改提示前后的通过率，用数据而非感觉判断改动效果。
  • 逐步收紧约束：先让 Agent 跑通主路径，再针对失败案例补「调用约束」与「错误处理」，避免一开始就堆砌限制导致难以定位问题。
  • 善用严格模式：在支持 strict 的接口上开启它，强制输出遵循 schema，把格式错误消灭在模型侧。
  • 写好工具描述：工具 description 与参数说明越清晰，模型越能正确决策调用时机与传参，减少因误解导致的误调用。
  • 区分工作流与 Agent：参考 Anthropic 的架构区分，若任务步骤可枚举、追求可预测性，优先用工作流（预定义代码路径）而非全自主 Agent，能显著降低调试难度。

小结

Agent 系统提示词的本质，是一份写给大模型的「岗位说明书加操作规范」。它要回答四个核心问题：你是谁（角色）、要达成什么（目标与边界）、能用哪些工具以及怎么用（工具约束）、以什么形式交付（输出格式），并补上安全与错误处理两条底线。写好它的关键，不是堆砌华丽指令，而是把冲突的规则去掉、把模糊的边界写清、把工具的调用与失败路径规定明白。借助框架提供的 tracing、严格模式与工具 schema 校验，再配合小样本评测，你就能让 Agent 的行为从「碰运气」变为「可预期、可调试、可上线」。

参考与延伸阅读

  1. OpenAI. OpenAI Agents SDK 官方文档。说明 Agent 由 instructions 与 tools 构成，并引入 guardrails、handoffs 等原语。https://openai.github.io/openai-agents-python/

  2. OpenAI. Tools - OpenAI Agents SDK 官方文档。涵盖函数工具定义、模型自主决定调用时机、基于 Pydantic 的 schema 校验、failure_error_function 错误处理，以及命名空间组织工具（建议每命名空间少于 10 个函数）的最佳实践。https://openai.github.io/openai-agents-python/tools/

  3. Anthropic. Tool use with Claude 官方文档。说明 tool_use 与 tool_result 的往返机制、tool_choice 的 auto/any/tool/none 取值、strict: true 强制 schema 一致，以及「工具调用频率可通过系统提示调节」「传入 tools 后 API 会自动附加启用工具的特殊系统提示」等关键事实。https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/overview

  4. Anthropic. Building Effective Agents（Erik Schluntz, Barry Zhang, 2024 年 12 月）官方工程博客。提出 agentic systems 中 workflows 与 agents 的架构区分（前者由预定义代码路径编排，后者由 LLM 动态主导流程与工具使用）、augmented LLM 基础构件，以及「从最简单方案出发、按需增加复杂度」的落地建议。https://www.anthropic.com/engineering/building-effective-agents

本文累计阅读 — 次