在传统 LLM 应用中，Prompt Engineering 主要解决“如何让模型输出更好的答案”。
但在 Agent 系统中，Prompt Engineering 的角色发生了根本性变化：Prompt 不再只是“输入文本”，而是 Agent 的“操作系统指令集”——它定义了 Agent 的行为规范、决策逻辑、工具使用协议和状态转换规则。
核心区别：
| 维度 | 传统 Prompt Engineering | Agent 中的 Prompt Engineering |
|---|---|---|
| 目标 | 优化单次输出质量 | 控制系统行为与决策流程 |
| 内容 | 指令 + 示例 | 系统规范 + 工具协议 + 状态管理 |
| 结构 | 扁平文本 | 分层模块化结构 |
| 动态性 | 静态 | 随状态/记忆/上下文动态组装 |
| 评估 | 输出质量 | 任务完成率、行为正确性 |
| 失败模式 | 答案不准 | 行为失控、循环死锁、工具误用 |
Prompt 首先需要明确 Agent “是谁”、“能做什么”、“不能做什么”。
你是一个数据分析 Agent。你的职责是：
1. 理解用户的数据分析需求
2. 编写并执行 Python 代码
3. 解释分析结果
你不能：
- 访问本地文件系统（除非通过指定工具）
- 修改系统配置
- 向外部网络发送数据（除非用户明确授权）
作用：防止 Agent 越权操作，降低安全风险。
Agent 需要按照特定框架进行推理和决策。Prompt 负责固化这个框架。
ReAct 框架的 Prompt 设计：
对于每个步骤，你必须按照以下格式输出：
Thought: 分析当前状态，思考下一步应该做什么
Action: 要调用的工具名称
Action Input: 工具的参数（JSON 格式）
Observation: （工具返回的结果，由系统填入）
重复以上循环，直到你认为任务完成。
当任务完成时，输出：
Final Answer: 最终答案
作用：确保 Agent 的推理过程可控、可解析、可追踪。
Agent 需要知道有哪些工具、每个工具怎么用、什么情况下用哪个工具。
可用工具列表：
1. search(query: str) -> list[dict]
- 功能：搜索互联网获取信息
- 使用场景：需要查找实时信息、事实核查
- 参数说明：query 为搜索关键词，不超过 5 个词
- 返回：相关网页的标题、摘要、URL 列表
2. python_execute(code: str) -> dict
- 功能：在沙箱中执行 Python 代码
- 使用场景：需要计算、数据处理、图表生成
- 限制：执行时间不超过 30 秒
- 返回：stdout, stderr, 返回值
作用：
Agent 在长期任务中需要根据状态决定下一步行为。Prompt 定义状态转换规则。
任务状态机：
[规划中] → [执行中] → [验证中] → [完成]
↓ ↓
[失败] → [重试/重新规划]
规则：
- 如果连续 3 次工具调用失败，进入 [重新规划] 状态
- 如果子任务全部完成但结果未验证，进入 [验证中] 状态
- 如果验证失败超过 2 次，请求人工介入
作用：让 Agent 在复杂任务中保持正确的执行节奏，防止死循环。
Prompt 是连接 Agent 记忆系统与 LLM 的接口。动态信息在运行时组装进 Prompt。
# 当前任务
{current_task}
# 已完成步骤
{completed_steps_summary}
# 相关历史经验
{retrieved_experiences}
# 当前状态
{current_state}
# 下一步建议
请根据以上信息，决定下一步行动。
作用：
Agent 的输出需要被程序解析（如 JSON），Prompt 负责强制输出格式。
你的每一次回复必须严格遵循以下 JSON 格式：
{
"thought": "你的分析过程",
"action": "tool_name 或 finish",
"action_input": {...},
"confidence": 0.0-1.0
}
不要输出任何 JSON 之外的文本。不要使用 markdown 代码块包裹。
作用：
一个完整的 Agent Prompt 通常分为以下几层：
| 层级 | 名称 | 包含内容 |
|---|---|---|
| 1 | 系统层（System Layer） | 角色定义、能力边界、安全规则 |
| 2 | 协议层（Protocol Layer） | 推理框架（ReAct/Plan-Execute）、输出格式规范（JSON Schema）、状态转换规则 |
| 3 | 工具层（Tool Layer） | 工具列表、参数说明、使用场景、工具选择建议 |
| 4 | 上下文层（Context Layer） | 当前任务描述、历史执行摘要、检索到的相关经验、当前状态快照 |
| 5 | 指令层（Instruction Layer） | 本轮具体指令、期望的输出 |
关键设计原则：
Agent 的执行轨迹可能很长，LLM 对 Prompt 中不同位置的关注度不同。
现象：当上下文超过一定长度后，LLM 倾向于“忘记”开头的系统指令。
解决方案：
当系统指令、工具描述、历史经验同时存在于 Prompt 中，可能产生冲突。
# 冲突示例
系统指令：优先使用缓存数据以节省成本
历史经验：上次缓存数据不准确，建议重新获取
当前任务：用户要求获取最新数据
解决方案：
Agent 的 Prompt 不是静态的，需要根据状态动态组装。这带来测试和调试的困难。
解决方案：
Prompt 约束太多 → Agent 行为僵化，无法应对意外情况。 Prompt 约束太少 → Agent 行为不可控。
平衡策略：
<system>
你是数据分析 Agent...
</system>
<tools>
...工具列表...
</tools>
<task>
...当前任务...
</task>
<context>
...历史上下文...
</context>
<output_format>
...JSON Schema...
</output_format>
好处：LLM 更容易定位和遵循不同模块的指令。
在 Prompt 中加入完整的“正确行为轨迹”作为示例：
以下是正确执行任务的示例：
用户：帮我查一下今天北京的天气
Thought: 用户需要查询实时天气信息，我应该使用 search 工具。
Action: search
Action Input: {"query": "北京天气 2026-08-30"}
Observation: [{"title": "北京天气预报", "content": "晴，25-32°C"}]
Thought: 已获取天气信息，可以回答用户了。
Final Answer: 今天北京晴，气温 25-32°C。
好处：Few-shot 示例比抽象规则更有效地指导 LLM 行为。
根据当前任务，从经验库中选择最相关的成功轨迹作为 Few-shot 示例。
# 动态选择逻辑
1. 获取当前任务的向量表示
2. 从经验库检索最相似的成功案例
3. 将成功案例的执行轨迹作为 Few-shot 示例注入 Prompt
在 Prompt 中嵌入自我检查环节：
在输出最终答案前，请回答以下问题：
1. 你的回答是否完全基于工具返回的结果？
2. 是否有信息缺失？如果有，是否应该继续调用工具？
3. 你的输出格式是否符合要求？
4. 置信度是否足够高？如果低于 0.7，考虑请求人工确认。
┌─────────────────────────────────────────────────┐
│ Agent 系统全景 │
├─────────────────────────────────────────────────┤
│ │
│ ┌──────────────┐ │
│ │ Prompt 引擎 │ ← 组装系统层/协议层/工具层 │
│ └──────┬───────┘ │
│ │ 生成 Prompt │
│ ↓ │
│ ┌──────────────┐ ┌──────────────────┐ │
│ │ LLM │ ←→ │ 记忆系统 │ │
│ └──────┬───────┘ │ (向量库/经验库) │ │
│ │ 输出 └──────────────────┘ │
│ ↓ │
│ ┌──────────────┐ ┌──────────────────┐ │
│ │ 输出解析器 │ →→ │ 工具执行器 │ │
│ └──────┬───────┘ └──────────────────┘ │
│ │ │
│ ↓ │
│ ┌──────────────┐ ┌──────────────────┐ │
│ │ 状态管理器 │ ←→ │ 反思/评估器 │ │
│ └──────────────┘ └──────────────────┘ │
│ │
└─────────────────────────────────────────────────┘
Prompt Engine 的职责：
如果面试被问到这个问题，建议这样组织回答：
1. 先点明核心观点（30 秒）
“在 Agent 系统中，Prompt Engineering 的角色从‘优化输出质量’升级为‘定义系统行为’。它相当于 Agent 的操作系统指令集，负责定义角色边界、决策框架、工具协议和状态转换规则。”
2. 展开关键作用（2 分钟）
“具体来说有六个核心作用：定义角色行为边界、规定推理框架、描述工具协议、管理状态转换、注入动态上下文、约束输出格式。我会逐一说明……”
3. 提到独特挑战（1 分钟）
“Agent 场景下的 Prompt Engineering 面临几个传统场景没有的挑战：长上下文中的注意力衰减、指令冲突、动态组装的复杂度、以及过度约束和灵活性不足之间的平衡。”
4. 结合实践（1 分钟）
“在实践中，我用分层模板来管理 Prompt——系统层和协议层相对固定，上下文层动态组装。关键规则会在 Prompt 中重复出现，并用结构化标签帮助 LLM 定位。另外，动态 Few-shot 从经验库中选择成功轨迹注入，效果比纯静态 Prompt 好很多。”
5. 总结观点（30 秒）
“总结来说，Agent 中的 Prompt Engineering 是系统工程问题，不是简单的‘写好提示词’。它需要与状态管理、记忆系统、工具系统协同设计。”
非常适合，而且是一道区分度很高的面试题。
| 考察维度 | 具体内容 |
|---|---|
| 理解深度 | 是否理解 Agent 中 Prompt 的角色变化 |
| 系统思维 | 是否理解 Prompt 与记忆、工具、状态的关系 |
| 工程能力 | 是否处理过长上下文、指令冲突等问题 |
| 实战经验 | 是否真正调试过 Agent 的 Prompt |
| 设计能力 | 能否设计分层的、可维护的 Prompt 架构 |
建议的追问方向：
| 传统观点 | Agent 视角 |
|---|---|
| Prompt 是“输入” | Prompt 是“行为规范” |
| 优化输出质量 | 控制系统行为 |
| 静态文本 | 动态组装 |
| 一次性设计 | 持续迭代 |
| 个人技巧 | 系统工程 |
一句话总结：在 Agent 中，Prompt Engineering 的本质是行为工程——通过精心设计的指令体系，将 LLM 的通用能力转化为可控、可靠、可预测的智能体行为。
核心公式：
$$ \text{Agent 行为质量} = f(\text{LLM 能力}, \text{Prompt 设计}, \text{工具设计}, \text{记忆系统}, \text{状态管理}) $$
其中 Prompt 设计是连接所有其他组件的接口层，直接影响整体系统的可靠性和可控性。
评论专区
评论加载中...登录后即可发表评论