第二卷：Prompt工程篇
第4章 Prompt基础
第2节：Prompt设计五要素------任务、角色、上下文、约束与输出格式
《Agent开发工程师成长指南》系列教程
引言
上一篇我们讨论了一个看似简单、实际上非常重要的问题：
Prompt到底是什么？
我们最终得到一个核心结论：
Prompt不是简单地"问AI一句话"，而是在给模型定义生成结果的条件。
传统软件中，程序员通过代码直接定义程序应该执行什么逻辑。
而在大模型应用中，工程师越来越多地通过：
Prompt
+
Context
+
Tools
+
Model来影响模型的行为。
但是，到这里又会产生一个新的问题：
Prompt到底应该怎么写？
很多刚开始接触大模型开发的人，会把Prompt理解成：
请帮我分析一下这个问题。然后发现效果不好，于是继续增加文字：
你是一名非常专业的专家，
拥有很多年的经验，
请认真分析这个问题，
一定要仔细思考，
尽可能详细，
最好从多个角度进行分析，
然后给出一个准确的答案......Prompt越来越长。
但是结果却不一定越来越好。
真正成熟的Prompt设计，并不是单纯增加文字，而是让模型明确知道：
你要做什么？
你应该以什么身份做？
你需要知道什么？
你必须遵守什么规则？
最后应该以什么形式输出？因此，一个工程化Prompt通常可以拆成五个核心要素：
Prompt
│
┌───────────┼───────────┐
↓ ↓ ↓
Task Role Context
任务 角色 上下文
│ │ │
└───────────┼───────────┘
↓
Constraints
约束
│
↓
Output Format
输出格式
│
↓
LLM这五个要素，也是Prompt工程最基础的一套思维框架。
一、Prompt设计的五个核心要素
先用一个简单的例子理解。
假设我们正在开发一个：
企业订单风险分析Agent
用户提出：
帮我看看这个订单有没有延期风险。一个非常简单的Prompt可能是：
分析这个订单有没有延期风险。而一个工程化Prompt可能是：
Role：
你是一名供应链风险分析助手。
Task：
根据订单信息、生产进度、物流状态和历史延期记录，
判断当前订单是否存在延期风险。
Context：
订单交期：2026-10-20
当前日期：2026-10-04
生产完成度：62%
计划完成度：75%
物流状态：尚未发货
历史延期次数：2次
Constraints：
1. 只能根据提供的数据进行判断。
2. 不允许虚构不存在的数据。
3. 如果信息不足，需要明确说明。
4. 风险等级只能输出低、中、高。
Output Format：
请使用JSON格式输出：
{
"riskLevel": "低/中/高",
"reason": "...",
"suggestion": "..."
}可以看到，这已经不是一句普通的问题。
它实际上是在给模型建立一个完整的任务环境。
二、第一个要素：Task------告诉模型"做什么"
五个要素中，最重要的通常是：
Task：任务。
因为模型首先需要知道：
我到底要完成什么？
例如：
分析这份合同。和：
从这份合同中提取：
1. 合同金额
2. 付款方式
3. 交付日期
4. 违约责任虽然都是"分析合同"，但第二个Prompt明显更加明确。
2.1 Task解决的是"目标问题"
可以把Task理解为：
User Intent
↓
Task Definition
↓
Model Objective也就是：
用户想做什么 → 工程师如何把它定义成模型任务 → 模型应该完成什么。
2.2 好的Task应该尽可能具体
例如：
模糊
分析客户。改进
分析客户最近90天的购买行为。更进一步
根据客户最近90天的订单数据，
判断客户是否存在流失风险，
并说明主要原因。这时候模型的任务空间已经明显缩小。
2.3 Task不是越复杂越好
Task也不能无限堆叠。
例如：
分析客户、判断风险、生成营销方案、
预测未来销量、写一封邮件、制作报告......这实际上已经变成多个任务。
对于复杂Agent，应该进一步拆解：
Task A
↓
Task B
↓
Task C
↓
Task D这也是后面Workflow和Agent Planning会讨论的问题。
三、第二个要素：Role------告诉模型"以什么身份做"
第二个重要元素是：
Role：角色。
例如：
你是一名供应链分析师。或者：
你是一名Java后端工程师。或者：
你是一名企业安全审计专家。这就是在给模型设置工作角色。
3.1 Role到底有什么作用？
Role并不是简单地告诉模型：
"假装你是某某人。"
更重要的是建立一种：
行为和知识视角。
例如：
普通Prompt
分析这个数据库设计。Role + Task
你是一名资深数据库架构师。
请分析下面的数据库设计，
重点关注：
- 索引设计
- 查询性能
- 数据一致性
- 扩展能力模型关注的问题就发生了变化。
3.2 Role实际上是在改变"回答视角"
同一个问题：
如何设计一个Agent？不同Role可能得到不同答案。
产品经理
关注：
用户需求
业务价值
产品体验后端工程师
关注：
API
服务架构
数据库
任务调度AI工程师
关注：
Prompt
RAG
Tool Calling
Model
Evaluation安全工程师
关注：
权限
数据泄露
Prompt Injection
审计因此：
Role决定模型从什么视角处理Task。
四、第三个要素：Context------告诉模型"需要知道什么"
如果说：
Task解决"做什么"。
那么：
Context解决"根据什么做"。
这也是Prompt设计中最容易被忽略、同时对Agent最重要的部分之一。
例如：
判断订单是否延期。模型知道Task。
但是它不知道：
订单什么时候交付？
现在生产到什么阶段？
物流在哪里？
当前日期是什么？
过去有没有延期？因此必须提供Context。
4.1 Context不是简单的"背景介绍"
Context可以来自很多地方：
用户输入
+
历史对话
+
用户画像
+
业务数据
+
知识库
+
数据库
+
API
+
Tool返回结果最终形成：
Context然后进入模型。
这也是为什么后面学习RAG、Memory、Tool Calling时，都必须回到Context这个核心概念。
4.2 Context可以是动态的
这是传统Prompt和Agent Prompt之间非常重要的区别。
传统Prompt：
Prompt
↓
LLM
↓
OutputAgent：
User Goal
↓
Prompt Assembly
↑
├── Conversation History
├── User Profile
├── Retrieved Knowledge
├── Tool Results
├── Business Data
└── System Rules因此：
Agent中的Prompt通常不是提前写死的一段文本，而是运行过程中动态组装出来的。
五、第四个要素：Constraints------告诉模型"不能怎么做"
很多Prompt之所以不稳定，并不是Task不明确，而是：
没有规定边界。
例如：
请分析这份客户数据。模型可能：
- 自己推测缺失数据
- 引入外部常识
- 给出没有依据的结论
- 输出大量额外内容
- 改变任务目标
所以需要Constraints。
5.1 Constraints就是"行为边界"
例如：
只能使用提供的数据。
不能虚构数据。
如果数据不足，需要明确说明。
不能输出客户个人隐私信息。
风险等级只能是：
低 / 中 / 高。这时候模型的行为空间进一步缩小。
可以理解成：
无限生成空间
↓
Task
↓
Role
↓
Context
↓
Constraints
↓
有限且明确的行为范围5.2 Constraints可以约束什么？
常见约束包括：
内容约束
只能基于提供的数据回答。行为约束
不要主动执行删除操作。安全约束
禁止输出用户身份证号。范围约束
只分析最近30天数据。工具约束
发送邮件前必须获得用户确认。权限约束
只能查询当前用户有权限访问的数据。这些约束在Agent系统中尤其重要。
因为普通聊天机器人：
输出错误可能只是回答不好。
但是Agent：
工具调用错误
↓
执行错误操作
↓
真实业务系统发生变化后果完全不同。
六、第五个要素：Output Format------告诉模型"结果怎么交付"
最后一个要素：
Output Format：输出格式。
很多开发者认为：
"模型只要回答正确就可以。"
但是在真正的软件系统中，这远远不够。
因为模型输出通常还需要：
被程序解析
被数据库保存
被前端展示
被Workflow继续处理
被Agent下一步使用所以：
输出格式也是Prompt工程的重要组成部分。
6.1 普通文本输出
例如：
这个订单存在较高延期风险。对于人来说可以。
但是程序很难稳定处理。
6.2 结构化输出
可以要求：
{
"riskLevel": "high",
"reason": "生产进度低于计划",
"suggestion": "立即确认生产计划"
}这样程序就可以直接解析。
6.3 Output Format决定系统可组合性
例如：
LLM
↓
JSON
↓
程序解析
↓
Database或者：
LLM
↓
Tool Call
↓
Tool执行或者：
LLM
↓
Structured Output
↓
Workflow下一节点因此：
Output Format决定了模型能不能顺利进入后续软件系统。
七、五要素组合起来是什么样？
现在把五个元素放到一起：
Role
↓
我是谁
Task
↓
我要做什么
Context
↓
我需要知道什么
Constraints
↓
我能做什么、不能做什么
Output Format
↓
最后应该怎么交付组合起来就是：
┌──────────────────────────────┐
│ Role │
│ 角色 │
├──────────────────────────────┤
│ Task │
│ 任务 │
├──────────────────────────────┤
│ Context │
│ 上下文 │
├──────────────────────────────┤
│ Constraints │
│ 约束 │
├──────────────────────────────┤
│ Output Format │
│ 输出格式 │
└──────────────────────────────┘
↓
LLM
↓
Stable Output这五个元素共同决定：
模型应该如何理解任务、如何处理信息以及如何产生结果。
八、通过一个真实Agent案例理解
现在来看一个更接近真实系统的例子。
假设我们开发：
制造业设备异常分析Agent。
设备出现：
主轴温度过高用户希望：
帮我判断一下这个设备出了什么问题。8.1 只有Task
请分析设备异常原因。可能得到：
可能是设备过热。
可能是润滑不足。
可能是负载过高。
可能是环境温度过高。
......问题是：
输出可能非常发散。
8.2 加入Role
你是一名制造业设备故障分析专家。
请分析设备异常原因。输出会更加聚焦。
8.3 加入Context
例如：
设备：CNC-001
异常：
主轴温度过高
运行时间：
8小时
当前温度：
92℃
正常温度：
65℃
最近维护：
45天前
历史故障：
主轴润滑异常2次模型就拥有了实际分析所需的信息。
8.4 加入Constraints
只能基于提供的数据进行判断。
不能虚构不存在的设备状态。
如果无法确定故障原因，
必须明确说明"需要人工检查"。
禁止直接执行设备停止操作。这一步非常关键。
因为Agent可能拥有：
查询设备
停止设备
调整参数
创建工单等工具。
如果没有安全约束，模型可能直接做出危险动作。
8.5 加入Output Format
要求：
{
"fault": "",
"riskLevel": "",
"evidence": [],
"recommendation": "",
"needHumanReview": true
}最终整个Prompt就变成：
Role
+
Task
+
Context
+
Constraints
+
Output Format模型输出：
{
"fault": "主轴润滑系统异常",
"riskLevel": "高",
"evidence": [
"主轴温度明显高于正常范围",
"历史存在两次润滑异常",
"设备已连续运行8小时"
],
"recommendation": "检查主轴润滑系统",
"needHumanReview": true
}这就已经非常接近真正的企业Agent了。
九、Prompt五要素之间并不是孤立的
一个容易出现的误区是：
把五要素理解成五个互相独立的字段。
实际上，它们之间存在很强的关联。
例如：
Task决定：
我要完成什么？
然后：
Context决定：
我根据什么完成？
然后：
Constraints决定：
我应该在什么范围内完成？
最后：
Output Format决定：
完成以后如何交付？
而：
Role决定：
我应该以什么视角完成？
因此可以形成：
Role
↓
谁来完成？
↓
Task ─────→ 做什么？
↓
Context ──→ 根据什么？
↓
Constraints → 有什么边界？
↓
Output ────→ 如何交付？
↓
LLM十、Prompt不是"固定文本"，而是一种任务协议
当我们把五个元素组合起来以后，会发现一个非常重要的变化。
Prompt已经不再只是：
一段给模型看的文字而更接近：
Task Specification
+
Behavior Policy
+
Context
+
Output Contract也就是说：
Prompt实际上正在逐渐成为AI系统中的一种"任务协议"。
例如：
Role
Task
Context
Constraints
Output Schema这些内容甚至可以被程序动态生成。
十一、从Prompt到Agent：五要素开始控制"行动"
到这里，我们还只是控制模型：
怎么回答。
但是Agent需要解决的是：
怎么行动。
因此Prompt五要素开始进一步影响：
Task
↓
Reasoning
↓
Tool Selection
↓
Tool Execution
↓
Observation
↓
Next Action例如：
用户：
帮我查询昨天没有发货的订单，并通知客户。Agent可能执行：
Task
↓
查询订单
↓
选择订单API
↓
Tool Call
↓
获得订单数据
↓
筛选未发货订单
↓
选择通知工具
↓
发送消息
↓
返回结果这时候Prompt中的：
Task
Role
Constraints
Tool Policy
Output Format都会影响Agent最终行为。
十二、工程师应该如何设计一个好的Prompt？
知道五个要素以后，真正进入工程实践，可以使用下面这套方法。
第一步：先写Task
先回答：
这个Prompt究竟要让模型完成什么？
不要一开始就写几十行Prompt。
先写一句：
目标：判断订单延期风险。第二步：确定Role
然后问：
模型应该以什么角色处理这个任务？
例如：
角色：供应链风险分析师。第三步：明确Context
然后确定：
模型真正需要哪些信息？
例如：
订单日期
生产进度
物流状态
历史延期记录
当前日期不要把所有能够获取的数据都塞进去。
第四步：建立Constraints
然后定义：
哪些事情不能做？
哪些事情必须做？
哪些信息不能泄露？
哪些工具不能调用？
什么情况下必须交给人工？第五步：定义Output Format
最后考虑：
这个结果后面还要被谁使用？
如果只是给用户阅读：
Markdown可能就足够。
如果给程序处理：
JSON更合适。
如果要调用工具：
Tool Call Schema更合适。
十三、不要把五要素理解成固定模板
需要特别强调：
五要素是一套设计思维，而不是必须机械填写的表格。
并不是所有Prompt都必须出现：
Role:
Task:
Context:
Constraints:
Output:例如非常简单的任务：
把下面这段中文翻译成英文。已经足够。
没有必要写：
Role：
你是一名全球顶级翻译专家......
Task：
......
Context：
......
Constraints：
......
Output：
......这反而会增加噪声。
所以真正的原则是：
根据任务复杂度决定Prompt结构，而不是为了完整而完整。
十四、Prompt设计的核心原则：明确，而不是复杂
一个优秀Prompt通常具备几个特征：
明确
↓
相关
↓
完整
↓
可执行
↓
可验证而不是：
越长
↓
越专业
↓
越好真正需要关注的是：
模型是否能够准确理解任务目标，并在明确边界内产生我们需要的结果。
因此：
Prompt质量
≠ Prompt长度更准确地说：
Prompt质量
≈
任务清晰度
+
上下文相关性
+
约束完整性
+
输出可用性
十五、企业级Agent中的Prompt五要素
在企业环境中，这五个要素还会进一步工程化。
例如：
Prompt
│
┌──────────────┼──────────────┐
↓ ↓ ↓
Role Task Context
│ │ │
└──────────────┼──────────────┘
↓
Constraints
↓
Output Schema
↓
LLM
↓
Tool / Workflow其中：
Role
通常来自：
System PromptTask
通常来自：
User Request
+
Workflow Node
+
Agent GoalContext
可能来自：
RAG
Memory
Database
API
Tool Result
ConversationConstraints
可能来自：
企业安全策略
权限系统
业务规则
Tool Policy
Compliance PolicyOutput Format
可能来自：
JSON Schema
Tool Schema
Workflow Schema
UI Schema这意味着：
企业级Prompt实际上已经开始与整个AI系统架构发生关系。
这也是为什么Prompt工程最终并不只是"写提示词"。
十六、从Prompt Engineer走向AI Engineer
如果只会写Prompt：
会写提示词只是Prompt工程的起点。
真正的AI工程师需要进一步理解：
Prompt
↓
Context
↓
Model
↓
RAG
↓
Tool
↓
Workflow
↓
Agent
↓
Evaluation
↓
Production也就是说：
Prompt只是整个AI系统中的一个控制层。
它负责告诉模型：
做什么
怎么做
根据什么做
不能怎么做
结果怎么交付但是：
知识从哪里来？需要RAG。
工具怎么调用？需要Tool Calling。
复杂任务怎么拆解？需要Planning。
长期信息怎么保存？需要Memory。
多个步骤怎么组织？需要Workflow。
这些内容将在后面的章节逐渐展开。
十七、五要素最终形成一套Prompt设计方法论
现在可以把本节内容浓缩成一张图：
Prompt
│
┌────────────┼────────────┐
↓ ↓ ↓
Role Task Context
角色 任务 上下文
│ │ │
└────────────┼────────────┘
↓
Constraints
约束
↓
Output Format
输出格式
↓
LLM
↓
┌──────────┴──────────┐
↓ ↓
Answer Action
回答 行动所以：
Prompt设计的本质，不是把话说得更长，而是把任务定义得更清楚。
十八、知识体系总结
本节我们建立了Prompt设计最基础的五要素模型。
| 要素 | 核心问题 | 作用 |
|---|---|---|
| Role | 以什么身份做？ | 定义行为视角 |
| Task | 要做什么？ | 定义任务目标 |
| Context | 需要知道什么？ | 提供任务信息 |
| Constraints | 有什么边界？ | 限制模型行为 |
| Output Format | 怎么交付？ | 保证结果可用 |
可以记成一句话：
Role决定"谁来做"，Task决定"做什么"，Context决定"根据什么做"，Constraints决定"怎么做、不能怎么做"，Output Format决定"怎么交付"。
而当这五个要素进入Agent之后：
Prompt
↓
Reasoning
↓
Tool Selection
↓
Tool Execution
↓
Observation
↓
Next ActionPrompt就从：
控制模型回答
逐渐变成：
控制Agent行为。
面试题
1. Prompt设计为什么需要多个要素？
因为模型不仅需要知道任务目标，还需要知道角色、上下文、行为边界和输出要求。
2. Role的作用是什么？
Role主要用于定义模型处理问题时的角色和行为视角，使模型从特定专业领域或工作职责出发完成任务。
3. Task和Context有什么区别？
简单来说：
Task = 做什么
Context = 根据什么做例如：
Task：
判断订单是否延期。
Context：
订单交期、生产进度、物流状态、历史延期记录。4. 为什么Agent特别需要Constraints？
因为Agent不仅输出文本，还可能调用工具、访问数据甚至执行真实业务操作。
因此必须通过约束控制：
权限
工具
数据
安全
业务规则否则模型错误可能进一步转化为真实业务事故。
5. 为什么Output Format很重要？
因为企业AI系统中的模型输出通常不是只给人看的，还需要：
程序解析
数据库存储
Workflow传递
Tool调用
前端展示因此结构化输出可以提高系统的稳定性和可组合性。
6. Prompt是不是越长越好？
不是。
Prompt质量的关键不是长度，而是：
任务清晰
+
信息相关
+
约束明确
+
输出可用7. Prompt五要素是不是固定模板？
不是。
五要素是一套设计思维。
简单任务可能只需要：
Task复杂Agent可能需要：
Role
+
Task
+
Context
+
Constraints
+
Output Format本节小结
上一篇我们回答了：
Prompt是什么？
本节进一步回答：
Prompt应该怎么设计？
我们建立了最基础的五要素模型：
Role
Task
Context
Constraints
Output Format它们分别解决：
谁来做？
做什么？
根据什么做？
有什么边界？
怎么交付？而这五个要素，也是从普通Prompt走向Agent Prompt的关键一步。
下一步我们还需要继续深入其中一个非常重要的问题：
如果Role决定了模型应该"以什么身份工作"，那么一个好的Role到底应该怎么设计？
下一篇预告
《Agent开发工程师成长指南》- 第4章 第3节：Role角色设计技巧------如何让AI进入正确的工作状态？
下一节将专门研究：
Role到底有没有用？
↓
Role如何影响模型行为？
↓
什么样的Role才是有效Role？
↓
Role应该包含哪些信息？
↓
Role与Task、Context有什么关系？
↓
Agent中的System Role应该怎么设计？最终我们会看到：
Role并不是简单地告诉模型"你是一名专家"，而是在定义Agent应该以什么身份、什么职责和什么行为边界来完成任务。