系统提示词工程
如何分节组织 system prompt、区分指令强度、以及 agent 特有的要素清单
核心要点：
- system prompt 有相对固定的组成
- XML 标签分节 + 利用 U 形注意力
- 正向指令优先于禁止，并给 Why
- 语言强度分级区分硬约束与软建议
- agent 特有：工具策略 / 停止条件 / 错误处理
本文讲 system prompt 的结构与指令设计，是 02-核心原则 中 right altitude 在 system prompt 上的落地。
一个 agent 的 system prompt 由哪些部分组成？
核心问题：除了"你是一个助手",agent 的 system prompt 还要写什么？
一套相对固定的组成在主流 agent 系统中反复出现，远不止角色定义。一个完整的 agent system prompt 通常含：
- 身份锚定：1-3 句说清角色与定位。
- 核心目标 + 优先级：目标排序，冲突时怎么取舍。
- 行为约束：硬约束与软建议分层。
- 工具使用规范：调用时机、优先顺序、失败回退（策略层，非 schema）。
- 输出格式：含具体示例。
- planning 与停止条件：何时反思、何时收尾、哪些操作需确认。
例子：一个典型 agent system prompt 的 7 节骨架（XML 分节）——
<role>你是 X 领域的编码助手</role>
<context>项目背景、技术栈、约定</context>
<instructions>核心工作流:先规划→再执行→后验证</instructions>
<tool_guidance>何时用哪个工具、失败怎么回退</tool_guidance>
<constraints>NEVER 删用户数据;MUST 改前先读</constraints>
<output_format>含一个具体输出样例</output_format>
<examples>3-5 个真实任务的 input/output 范例</examples>可选第 8 节控制自主性（何时自己决定、何时停下问人）。
这套组成比聊天助手多出的部分（工具策略、停止、错误处理）正是 agent 特有的，下文单独展开。
这些部分怎么排布？
核心问题：组成确定了，先后顺序和分节方式有讲究吗？
用 XML 标签明确分节，并利用 U 形注意力把硬约束放在开头和结尾[1]。Anthropic 推荐 <instructions>、<examples>、<output_format> 等标签划分，消除混合内容的歧义。
布局策略利用了 04-窗口内信息组织 的 U 形曲线：硬约束在开头和结尾双重强化，核心工作流居中但要写得最清晰。对长对话，可在 system prompt 里预留运行时动态注入行为提醒的位置，定期刷新关键约束。
指令怎么写才不被忽略或互相冲突？
核心问题：同样的要求，为什么有的写法模型照做、有的被无视？
正向指令优先于禁止，给出 Why，并用语言强度分级区分硬软[1]。三条经验各解决一类失效：
- 正向描述：告诉模型"做什么"比"不准做什么"更易执行，禁止式容易留下未定义行为。
- 给 Why：解释约束的理由帮助模型把规则泛化到没明说的边界，而非死记。
- 强度分级：用显式强度词让模型分清硬约束与软建议。
| 档位 | 词表 | 含义 |
|---|---|---|
| 硬约束 | NEVER / MUST / ALWAYS / Do not | 不可违反 |
| 软偏好 | Prefer / By default / Consider / Avoid | 可权衡 |
@tbl-agent-ctx-instruction-strength system prompt 指令强度分级：硬约束与软偏好的词表区分及对应语义
陷阱：不要滥用
CRITICAL/MUST。较新的模型对强力词汇响应更字面，过激的强约束可能导致过触发——模型为遵守一条夸大的禁令而牺牲正常行为。把不是真硬约束的写成普通指令。
这正是 02-核心原则 right altitude 的体现：给原则和理由，而非固化每个分支[2]。
agent 的 system prompt 比聊天多了什么？
核心问题：把聊天助手的 prompt 直接拿来驱动 agent，缺什么？
缺工具策略、停止条件、错误处理和 planning 指引——这四样是 agent 自主性的安全边界[3]。
| 要素 | 写什么 |
|---|---|
| 工具策略 | 调用时机、优先顺序、失败回退（不重复 schema） |
| 停止条件 | 枚举不可逆操作并要求确认，定义何时算完成 |
| 错误处理 | 失败要透明、设重试上限、超限则升级 |
| planning | 让模型反思工具结果再行动，维护持久化状态 |
@tbl-agent-ctx-agent-prompt-elements agent system prompt 专有要素：工具策略、停止条件、错误处理、planning 各要素的写作要点
Anthropic 把工具定义视为与 prompt 同等的工程对象，并主张 poka-yoke（防呆）式参数设计。可借鉴的判断：agent 的 system prompt 不只是描述角色，更是在划定自主行动的护栏。
few-shot 示例怎么放？
核心问题：要不要给示例，放几个、放哪？
给 3-5 个典范示例，用 <example> 标签包裹，放在指令之后、输出格式之前[1]。呼应 02-核心原则 的"示例策划"：精选多样典范，而非穷举 edge case。
两个落地细节：示例用真实路径和函数名而非 foo/bar，贴近实际任务；对开启 thinking 的模型，可在示例内展示推理模式。示例是给模型看的模板，质量比数量重要。
Takeaway
| 知识点 | 核心结论 |
|---|---|
| 组成 | 身份 / 目标 / 约束 / 工具策略 / 输出 / 停止，相对固定 |
| 排布 | XML 分节 + 硬约束头尾双强化，工作流居中写清 |
| 指令 | 正向优先、给 Why、强度分级(NEVER vs prefer) |
| agent 要素 | 工具策略 / 停止条件 / 错误处理 / planning 是自主护栏 |
| 示例 | 3-5 个真实典范，<example> 包裹，放指令后输出前 |
参考资料
- Anthropic. Claude prompting best practices. 2025. https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices
- Anthropic. Effective context engineering for AI agents. 2025. https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
- Anthropic. Building effective agents. 2024. https://www.anthropic.com/research/building-effective-agents
延伸阅读
- 02-核心原则 — right altitude 与示例策划
- 05-工具系统与 MCP — 工具本身的设计与协议