LLM - Prompt Engineering 构建工业级 LLM Agent 的六维结构化框架

Pre

LLM - 面向开发者的 Prompt 设计：从“一次成稿”到“对抗式收敛”

引言：从 Chat 到 Engineering

在生成式 AI 爆发的初期，我们习惯将与 LLM 的交互称为“Prompt Engineering（提示工程）”，但早期的实践更像是在念“咒语”——试图通过各种玄学的词汇组合来“诱骗”模型输出满意的结果。

然而，随着 LLM 在企业级应用中的落地，尤其是 Agent（智能体）概念的兴起，不确定性成为了最大的敌人。开发者不再满足于“写出一段好的文案”，而是需要构建稳定、可控、可复用的交互系统。

今天，我们将深入探讨一张在技术社区广为流传的“Agent 设计六维图谱”。这张图谱并非简单的技巧堆砌，而是一套完整的**结构化提示词（Structured Prompting）**方法论。它将一个高可用的 Prompt 解构为六个核心模块：Role（角色）、Context（上下文）、SOP（流程）、Boundary（边界）、Constraints（约束）与 Examples（示例）。

接下来我们将逐一拆解这六大维度，教你如何像编写代码一样编写 Prompt，构建鲁棒的 AI 应用。

一、 Role（角色）：不仅是身份，更是领域锚定

在 Prompt 的开头写上You are a helpful assistant是最基础的操作，但在工业级应用中，这远远不够。

1.1 明确专业领域 (Domain Specificity)

模型内部蕴含着海量的知识，涵盖了从烹饪到量子力学的各个角落。“角色”设定的本质，是激活模型参数空间中特定的子空间。

• Bad:“你是一个程序员。”
• Good:“你是一位拥有10年经验的 Python 后端架构师，精通 FastAPI 框架与异步编程模式。”

后者不仅定义了身份，还隐式地调高了相关技术术语的权重，降低了模型产生通用但肤浅回答的概率。

1.2 单一职责原则 (SRP)

软件工程中的Single Responsibility Principle (SRP)同样适用于 Agent 设计。一个全能的 Agent 往往意味着平庸。

• 如果你的任务既涉及代码编写，又涉及法律合规审查，建议拆分为两个 Agent：一个Coder，一个Legal Auditor。
• 在 Role 定义中，必须明确：你只负责什么？你的核心任务是什么？

1.3 避免角色冲突

当 Prompt 过长时，可能会出现前后矛盾的指令。例如，前面要求“像个孩子一样说话”，后面要求“输出严谨的数学公式”。在 Role 模块中，必须确立最高优先级的人格设定，覆盖后续可能出现的风格漂移。

二、 Context（上下文）：状态管理的艺术

LLM 本质上是无状态的（Stateless），所有的“记忆”都来自于 Context 窗口。在复杂的 Agent 任务中，Context 决定了模型能否理解“当前发生了什么”。

2.1 上下文分层加载 (Layered Context Injection)

高效的 Context 应当是分层的：

1. 静态知识 (System Level):比如业务的百科全书、API 文档。这部分通常固定在 System Prompt 中。
2. 动态状态 (Session Level):用户的上一轮对话、当前的变量值。
3. 临时检索 (RAG Level):根据用户 query 从向量数据库捞出的相关片段。

2.2 状态显式传递

在多轮对话或多 Agent 协作中，不要让模型去“猜”状态。

• 技巧：使用结构化数据（如<current_state>waiting_for_user_input</current_state>）将状态明确地注入到 Prompt 中。这让模型清晰地知道自己在任务进度条的哪个位置。

2.3 信息结构化呈现

不要把一堆乱序的文本扔给模型。使用 Markdown 标题、XML 标签或者 JSON 块来组织上下文信息。模型对结构化数据的注意力捕捉能力远强于非结构化文本。

三、 SOP（流程）：赋予模型逻辑推理的骨架

这是将 LLM 从“聊天机器人”转变为“任务执行者”的关键一步。SOP（Standard Operating Procedure）定义了思维的路径。

3.1 CoT (Chain of Thought) 思考链

SOP 的核心是将隐式的思维过程显式化。不要只问结果，要求模型打印步骤。

Prompt 示例：
"在回答用户问题之前，请先进行以下思考步骤：

1. 分析用户意图。
2. 检索相关知识库。
3. 检查是否有安全风险。
4. 生成最终回答。"

3.2 步骤编号与顺序

对于复杂任务，强制模型按照Step 1,Step 2,Step 3的顺序执行。这不仅有助于模型保持逻辑连贯，更重要的是，方便我们进行后处理（Post-processing）和调试。如果 Step 2 出错，我们可以针对性地优化 Prompt 的那一部分。

3.3 决策树逻辑

SOP 中应当包含条件判断逻辑（If-Then-Else）。

• “如果用户提供的信息不足，跳转到询问模块。”
• “如果用户通过了身份验证，跳转到执行模块。”
  在 Prompt 中清晰地描述这个决策树，能有效防止模型在遇到边缘情况时胡言乱语。

四、 Boundary（边界）：不仅要知其所能，更要知其所不能

在企业应用中，安全性和合规性往往比创造性更重要。Boundary 模块是 Agent 的护栏。

4.1 明确知识来源

为了减少幻觉（Hallucination），必须严格限制知识范围。

• 指令：“请仅依据参考资料（Reference Context）中的内容回答。如果资料中没有相关信息，请直接回答‘我不知道’，不要编造。”

4.2 划定职责范围

明确告诉 Agent不要做什么。

• “你只负责代码审查，不要尝试修复代码。”
• “不要讨论政治、宗教或暴力话题。”

4.3 兜底策略 (Fallback Strategy)

当所有正常逻辑都失效，或者用户输入完全在知识库之外时，Agent 应该怎么做？

• “如果遇到无法处理的情况，请输出标准错误代码ERROR_001并引导用户联系人工客服。”

五、 Constraints（约束）：对接工程系统的接口

如果说 Role 和 Context 是为了让人类读懂，那么 Constraints 就是为了让机器（代码）读懂。

5.1 格式刚性 (Format Rigidity)

这是 Agent 开发中最痛苦的环节之一。为了让下游系统（如 API 调用、数据库写入）能使用模型的输出，格式必须严格固定。

• 推荐：强制要求 JSON 或 XML 输出。
• 技巧：甚至可以提供一个 JSON Schema，要求模型严格 validate。

你的输出必须是如下 JSON 格式： { "reasoning": "...", "action": "search_tool", "parameters": { ... } }

5.2 字段语义化

在约束中，不仅要规定 Key 的名字，还要解释 Key 的含义。

• "confidence_score": “一个0-1之间的浮点数，表示你对该答案的置信度。”

5.3 风格统一

约束还包括语言风格的规范。

• “使用简洁的专业术语。”
• “禁止使用口语化的语气词（如‘嗯’、‘啊’）。”

六、 Examples（示例）：Few-Shot Learning 的威力

在 Prompt Engineering 论文中，Few-Shot（少样本提示）被证明是提升模型性能最有效的手段之一。

6.1 双轨制：固定示例 + 动态示例

• 固定示例 (Fixed):针对最核心、最常见的任务，手写 3-5 个完美的高质量问答对，永久植入 System Prompt。
• 动态示例 (Dynamic):针对长尾问题，利用 RAG 技术，从示例库中检索最相似的 3 个历史优良案例注入 Prompt。这能极大地提升模型的泛化能力。

6.2 覆盖边界 Case

不要只给“顺利”的例子。必须提供失败或边缘情况的例子。

• Input:“请帮我重置密码。” (Context为空)
• Output:“对不起，我需要先验证您的身份。请提供您的用户ID。”
  教会模型如何拒绝，比教会它如何执行更难。

6.3 多轮对话参考

如果任务涉及多轮交互，示例本身也应该是对话形式的，展示完整的User -> Assistant -> User -> Assistant交互流，让模型学习对话的节奏和上下文引用的方式。

实战演练：构建一个“代码审查 Agent”

让我们运用上述六维框架，把理论转化为一个实际的 Prompt。

# Role (角色) 你是一位资深的 Google 代码规范审查专家 (Senior Code Reviewer)。你精通 Python 和 Java，以严谨、客观著称。你的唯一职责是审查代码质量，找出潜在 Bug 和风格问题。 # Context (上下文) - 用户将提供一段代码片段。 - 你拥有《Google Python Style Guide》作为内置知识库。 # Boundary (边界) - 仅指出错误和改进建议，**不要**直接重写整段代码。 - 如果代码逻辑完全无法理解，请要求用户提供更多上下文。 - 严禁讨论代码之外的话题。 # Constraints (约束) - 输出必须严格遵循 Markdown 格式。 - 输出必须包含一个 JSON 块，用于系统自动评分。 - 语气必须专业、冷静，避免使用讽刺或过度热情的词汇。 # SOP (流程) 请按以下步骤思考并执行： 1. **Understand**: 阅读代码，理解其预期功能。 2. **Analyze**: 逐行检查是否存在： - 语法错误 - 安全漏洞 (如 SQL 注入) - 违反 Google Style Guide 的命名或格式 3. **Score**: 根据问题严重程度打分 (0-100)。 4. **Report**: 生成审查报告。 # Examples (示例) User: `def add(a,b): return a+b` Assistant: ## 代码审查报告 ### 问题分析 1. **命名规范**: 函数名 `add` 过于通用，缺乏描述性。 2. **类型提示**: 缺少 Python Type Hints。 3. **文档**: 缺少 Docstring。 ### 建议 建议将函数修改为包含类型提示的形式，并添加文档说明。 ```json { "score": 75, "critical_issues": [], "suggestions_count": 3 }

结论

Prompt Engineering 正在经历一场从“艺术创作”到“工程架构”的范式转移。

上文图片中展示的Role、Context、SOP、Boundary、Constraints、Examples六维框架，不仅仅是一个写 Prompt 的模板，更是一套思维模型。它强迫我们在与 LLM 交互之前，先理清业务逻辑、明确数据边界、规范接口定义。

当你下次面对一个复杂的 AI 需求时，不妨试着画出这六个框，填入你的设计。你会发现，原本不可控的“黑盒”，开始变得清晰、稳定且强大。