1. 项目概述从“能跑通”到“跑得好”的鸿沟“我的AI Agent终于调通LLM接口了”——如果你刚完成这一步恭喜你你刚刚跨过了AI应用开发的第一道门槛。但紧接着你可能会发现这个能“说话”的Agent其表现远不如预期它可能答非所问、逻辑混乱、拒绝执行指令或者干脆输出一堆无意义的字符。这时你才恍然大悟原来调用大语言模型LLM远不止是发送一个HTTP POST请求那么简单。那个看似简单的curl命令或者几行SDK代码只是打开了潘多拉魔盒的盖子里面真正复杂且决定成败的是提示词工程。很多人包括早期的我都曾陷入一个误区认为AI开发的核心是复杂的系统架构、高并发的服务部署或者精巧的算法。但在与LLM打交道的实践中我深刻体会到Prompt工程才是那个将原始算力转化为实际商业价值和应用能力的“翻译官”和“指挥官”。它不像传统编程那样有严格的语法和确定的输出更像是一门与“外星智能”沟通的艺术与科学的结合体。一个精心设计的Prompt其价值可能远超一百行优化后的代码。本文将基于我多次踩坑的经验深入拆解在AI Agent开发中如何超越基础的API调用通过系统的Prompt工程让你的Agent真正变得“聪明”且“可靠”。2. 核心认知转变LLM不是数据库而是“实习生”在深入技术细节前我们必须完成一次根本性的认知升级。这是所有高效Prompt工程的前提。2.1 从“查询-响应”到“任务-协作”的范式迁移调用传统API或查询数据库时我们遵循的是“精准查询确定返回”的模式。你发送一个结构化的SQL语句或一个参数明确的RESTful请求期望得到一个结构固定、内容确定的响应。如果返回错误那一定是你的请求格式不对或者服务端有bug。但LLM完全不同。把它想象成一个天赋极高但缺乏经验和背景知识的实习生。你不能对它说“SELECT * FROM knowledge_base WHERE topic‘AI’”然后指望它给你一张完美的表格。更恰当的协作方式是“小L我需要在明天的会议上向非技术背景的客户解释AI Agent的价值。请你根据我们之前讨论过的几个项目案例帮我起草一份三分钟左右的、通俗易懂的讲解稿重点突出降本增效和用户体验提升。”这个例子包含了与LLM协作的几个关键要素明确角色你定义了它的身份你的助手。交代背景你提供了任务场景向非技术客户汇报。给定约束你明确了输出格式三分钟讲稿和风格通俗易懂。指示重点你指明了内容方向结合案例聚焦价值。这种从“命令式编程”到“引导式协作”的思维转变是做好Prompt工程的第一步。你的Prompt不是在发送指令而是在构建一个能让LLM充分发挥其能力的“工作上下文”。2.2 理解LLM的“思考”机制概率与上下文为什么这种转变是必须的这需要稍微理解LLM的工作原理。LLM本质上是一个基于海量文本训练出来的、超级复杂的概率模型。它的“思考”过程是根据你提供的所有输入文本即上下文预测下一个最可能出现的词是什么如此循环往复生成整个回复。这意味着一切皆上下文你提供的Prompt就是模型生成回复时所依赖的全部“世界”。模型没有记忆没有外部知识除非你通过上下文提供它的所有判断都基于你给的这几个字、几百个token。输出具有概率性同一个Prompt多次运行可能产生略有不同的结果这是模型采样策略导致的正常现象不是bug。对格式敏感模型在训练时见过无数种文本格式问答、代码、列表、剧本等。你在Prompt中使用的格式会强烈地影响它选择以何种格式来回复。因此Prompt工程的核心目标就是精心构造一段文本上下文以极高的概率引导模型生成我们期望的输出。这就像给那位“天才实习生”一份极其清晰、详尽的工作说明书SOP。3. Prompt工程的核心要素与结构化设计理解了“为什么”我们来看“怎么做”。一个工业级可用的、用于AI Agent的Prompt绝不是一句简单的提问。它是一个结构化的文档。我通常将其分解为以下几个核心部分我称之为“Prompt脚手架”。3.1 角色定义为LLM戴上合适的“面具”这是最立竿见影的技巧。通过为LLM设定一个具体的角色你可以瞬间激活它在训练数据中与该角色相关的知识和行为模式。基础用法“你是一个资深的Python软件工程师。”“你是一位亲切的儿童故事讲述者。”进阶用法结合领域和风格。你是一位拥有10年经验、专精于金融风控领域的后端架构师。你的沟通风格严谨、准确喜欢用比喻解释复杂概念并且在给出方案时总是附带简要的利弊分析。实操心得角色定义要尽量具体。“专家”不如“资深运维工程师”“助手”不如“善于总结的会议纪要助手”。越具体的角色越能缩小模型的行为范围输出越可控。3.2 任务指令清晰、具体、可操作这是Prompt的骨架必须杜绝歧义。遵循“SMART”原则具体、可衡量、可达成、相关、有时限来构思你的指令。反面教材“帮我写点代码。”太模糊正面案例请编写一个Python函数名为validate_email。该函数接收一个字符串参数email。使用正则表达式验证其是否符合常见的电子邮件格式规范。返回一个布尔值True表示有效False表示无效。在函数内部添加详细的注释解释正则表达式每一部分的作用。为这个函数编写三个单元测试用例分别测试有效邮箱、无效邮箱格式错误和边界情况如超长字符串。注意事项指令应使用积极的、要求式的语言“请做…”“输出应包含…”避免开放式提问“你能…吗”除非你确实需要模型进行可行性评估。3.3 上下文信息提供必要的“弹药”LLM没有实时数据库所有任务相关的信息都必须由你提供在Prompt中。这包括背景信息项目介绍、相关数据、用户信息。参考材料相关的文章片段、数据表格、代码片段。历史记录多轮对话中之前几轮的问答内容。关键技巧位置很重要。最重要的上下文应该放在最靠近模型需要“回答”或“执行”部分的地方。通常的结构是角色 上下文 具体任务指令。3.4 输出格式规范让机器易于解析对于需要集成到自动化流程中的Agent输出的结构化至关重要。你必须明确告诉模型你想要的格式。指定格式“请以JSON格式输出包含以下字段summary, points, confidence。”指定语言“请用YAML列表输出以下内容。”使用分隔符这是一个强力技巧。在Prompt中明确使用如“””、“###”、“—”等标记来划分指令、上下文和输出区域甚至直接要求模型在输出中使用特定分隔符。你的输出必须严格按照以下格式【分析开始】 核心问题用一句话总结问题 根本原因列出1-3个根本原因 建议措施 - 措施一描述 - 措施二描述 【分析结束】避坑指南即使指定了JSON格式模型偶尔也可能在JSON前后添加解释性文字。解决方法是在指令中强调“只输出JSON对象不要有任何其他前后缀文本”并在你的调用代码中做好健壮性处理例如尝试从返回文本中提取JSON部分。3.5 思维链与分步指令引导复杂推理对于复杂任务直接要求结果往往会导致模型“跳步”和出错。这时需要引导模型展示其思考过程即“思维链”。简单引导在指令中加入“让我们一步步思考。”或“请先分析问题再给出解决方案。”复杂任务模板任务评估这个项目提案的技术可行性。 请你按以下步骤执行 步骤一提炼提案中的核心需求和技术指标。 步骤二逐一分析每个技术指标在现有技术栈下的实现难度和风险。 步骤三基于以上分析给出整体可行性结论高/中/低及主要论据。 现在请开始执行。这种方式不仅能让输出更可靠也让你能“窥见”模型的推理逻辑便于调试。4. 实战构建一个技术文档问答Agent的Prompt让我们通过一个完整案例将上述理论付诸实践。假设我们要构建一个Agent它能回答关于我们内部“Kubernetes运维手册”的问题。4.1 基础版Prompt能回答但不可控用户如何修复Pod一直处于Pending状态这是最糟糕的方式。模型会基于其训练数据中的通用K8s知识回答可能不准确也肯定不包含我们内部手册的特定规范如公司特定的标签、推荐的节点选择器等。4.2 进阶版Prompt提供上下文指定角色你是一个专业的Kubernetes运维专家负责解答同事关于集群运维的问题。 以下是我们内部的《Kubernetes运维手册v2.1》中的相关章节内容 【手册内容开始】 ... 故障排查章节 - Pod状态异常 1. Pending状态 - 可能原因1资源不足。检查节点资源CPU/Memory是否满足Pod请求。 - 可能原因2不满足节点选择器nodeSelector或亲和性规则。检查Pod配置的nodeSelector是否与任何节点的标签匹配。公司规定生产环境Pod应携带标签 env: prod。 - 可能原因3未满足PVC绑定。检查PersistentVolumeClaim是否处于Pending状态。 - 排查命令kubectl describe pod pod-name -n namespace查看Events部分。 ... 【手册内容结束】 现在请基于以上手册内容回答用户的问题。如果手册内容无法完全覆盖问题请基于你的专业知识补充但必须明确指出哪些是手册内容哪些是你的补充。 用户问题如何修复Pod一直处于Pending状态这个版本好多了。它定义了角色提供了精准的上下文并给出了回答的边界指令。4.3 工业级Prompt结构化、可解析、带验证对于一个真正的Agent我们往往希望它的输出能被下游系统如工单系统、监控仪表盘直接使用。因此我们需要更结构化的输出。# 角色与职责 你是一个严格的Kubernetes运维助手必须严格依据提供的《内部运维手册》进行回答。手册未提及的内容你应明确表示“根据手册未涉及此情况”不得擅自编造。 # 上下文信息 此处通过RAG技术动态插入与用户问题最相关的3段手册文本片段 # 用户问题 {{用户输入的问题}} # 输出指令 你必须按以下JSON格式组织你的回答且只输出此JSON对象无需任何其他解释 { “direct_answer”: “针对用户问题提供一个简洁、可直接操作的行动摘要2-3句话。, “analysis_steps”: [ “第一步...基于手册” “第二步...基于手册” ], “reference_sources”: [“来自手册第X章Y节” “来自手册第A章B节”], “confidence”: “高/中/低”, // 基于手册内容匹配度判断 “internal_rules_applied”: [“规则A...” “规则B...”] // 如涉及公司内部规则如标签规范在此列出 } # 处理逻辑 1. 仔细将用户问题与提供的上下文手册片段进行匹配。 2. 如果上下文能完全覆盖问题则confidence设为“高”analysis_steps严格引用手册。 3. 如果上下文部分覆盖则confidence设为“中”在direct_answer中优先依据手册缺失部分可简要补充通用知识并说明。 4. 如果上下文完全不匹配则confidence设为“低”direct_answer为“根据现有手册无法找到该问题的直接解决方案。建议查阅[相关官方文档链接]或联系高级运维。”这个Prompt模板已经具备了生产级应用的雏形。它通过动态插入上下文通常由检索增强生成技术实现指定了严格的、机器可读的输出格式并内置了回答置信度的判断逻辑。5. 高级技巧与避坑指南掌握了基础结构后一些高级技巧能让你事半功倍。5.1 少样本学习提供例子事半功倍对于格式复杂或逻辑要求严格的任务在Prompt中提供一两个输入输出的例子效果极其显著。你的任务是将自然语言指令转换为标准的Linux命令行。 请遵循以下示例的格式和逻辑 示例1 输入“给我看看当前目录下所有PDF文件的大小按从大到小排序。” 输出find . -name \*.pdf\ -type f -exec du -h {} | sort -hr 示例2 输入“终止所有名字里带‘test’的进程。” 输出pkill -f \test\ 现在请处理新的输入 输入“{{用户的新指令}}” 输出实操心得例子要典型要覆盖不同的情况。例子中的输入输出格式就是你期望的格式模型会极力模仿。5.2 温度与采样参数控制创造性与一致性除了Prompt内容调用API时的参数也至关重要。温度控制随机性。值越高如0.8-1.0输出越创造性、多样化值越低如0-0.3输出越确定、一致。对于需要事实准确、格式固定的Agent任务通常设置较低的温度0.1-0.3。Top-p另一种采样方式。通常与温度配合使用。对于需要严格控制输出的场景可以设置较低的温度和较低的top-p如0.9。避坑指南不要盲目追求“创造性”而调高温度。对于大多数功能性Agent稳定可靠的输出比天马行空的“聪明”更重要。先从低温度开始测试。5.3 系统提示词 vs 用户提示词利用好对话角色在OpenAI等平台的Chat Completion API中存在system和user以及assistant的角色区分。合理利用它们可以更好地组织Prompt。system用于设定全局角色、基础行为准则和高级指令。这部分内容通常贯穿整个对话会话为模型设定基调。适合放置“角色定义”和核心行为规范。user用于传递本次对话轮次的具体任务、上下文和问题。assistant用于提供少样本学习中的示例回复或在多轮对话中代表模型的历史回复。将长期有效的指令放在system中将本次特定的上下文和问题放在user中可以使Prompt结构更清晰也符合多轮对话的管理。6. 调试与迭代像优化算法一样优化PromptPrompt工程是一个高度经验性和迭代性的过程。没有一蹴而就的完美Prompt。6.1 建立评估体系在开发Agent时你需要定义清晰的评估标准来判断Prompt的好坏。例如事实准确性输出内容与已知标准答案的匹配度。格式合规率输出符合指定格式如JSON的比例。任务完成率对于指令性任务如“提取以下文本中的日期”成功完成的比例。人工评分让领域专家对输出的相关性、有用性进行打分。6.2 常见的失败模式与调优策略问题现象可能原因调优策略答非所问任务指令不够清晰角色定义模糊。重写指令使用更明确的动作动词“总结”、“列出”、“对比”强化角色定义增加限制词“仅基于以下文本”。忽略部分指令指令过于冗长或复杂模型“遗忘”了开头或中间的部分。简化指令将复杂任务拆分成多个简单Prompt链式调用使用分隔符强调关键指令将最重要的指令放在最后。输出格式错误格式描述不够严格模型在输出格式外添加了额外文本。使用“必须”、“严格按以下格式”、“只输出JSON不要有其他文本”等强约束词在少样本学习中提供完美的格式示例。幻觉编造信息上下文信息不足模型被要求回答其知识范围外的问题。强化上下文供给通过RAG在指令中加入“如果你不知道就明确说不知道”降低温度参数。表现不稳定温度参数过高Prompt本身存在歧义。降低温度如设为0.2审查并消除Prompt中的歧义表述增加确定性约束。6.3 工具链支持不要用记事本手动调试Prompt。建立你的工具链版本控制使用Git管理Prompt模板的迭代每次修改都有记录。测试集构建一个涵盖各种边界情况的测试用例集QA对每次修改Prompt后批量运行评估效果变化。A/B测试平台在生产环境灰度发布时可以对不同版本的Prompt进行A/B测试用真实用户反馈和数据来驱动优化。专用工具可以考虑使用LangChain、LlamaIndex等框架来模块化地构建和管理Prompt模板或者使用像Promptfoo这类专门用于评估和测试LLM提示词的工具。7. 从Prompt工程到智能体架构当单个Prompt变得复杂时它就成为了一个“智能体”的雏形。真正的AI Agent往往由多个Prompt、工具调用和记忆模块协作而成。规划一个顶层Prompt分析用户目标并将其分解为子任务序列。执行不同的子任务由不同的、高度特化的Prompt或调用工具来完成。反思一个评估Prompt检查执行结果决定是继续、重试还是终止。例如一个数据分析Agent的流程可能是规划Prompt理解用户问题“上季度销售趋势如何”决定需要调用“查询数据库工具”和“生成图表工具”。工具调用执行SQL查询获取数据。分析Prompt将数据结果和“生成季度销售趋势分析报告”的指令结合生成文本分析。图表Prompt将数据结果和“绘制折线图”的指令发送给代码生成工具生成绘图代码。整合Prompt将文本分析和图表代码整合成最终答案。在这个架构中每一个环节都是一个精心设计的Prompt。因此深入掌握Prompt工程是构建复杂、强大AI Agent的基石。回到开头那句话调用LLM的HTTP请求只是按下了这台强大引擎的启动按钮。而Prompt工程则是你手中的方向盘、油门和刹车决定了这台车是平稳驶向目的地还是四处乱撞。它没有终极的银弹答案只有基于对模型原理的深刻理解、对业务场景的精准把握以及无数次调试迭代后形成的直觉与经验。这份“真功夫”需要你在每一个具体项目中亲手去磨练。 从API调用到智能协作：Prompt工程如何让AI Agent真正可用
1. 项目概述从“能跑通”到“跑得好”的鸿沟“我的AI Agent终于调通LLM接口了”——如果你刚完成这一步恭喜你你刚刚跨过了AI应用开发的第一道门槛。但紧接着你可能会发现这个能“说话”的Agent其表现远不如预期它可能答非所问、逻辑混乱、拒绝执行指令或者干脆输出一堆无意义的字符。这时你才恍然大悟原来调用大语言模型LLM远不止是发送一个HTTP POST请求那么简单。那个看似简单的curl命令或者几行SDK代码只是打开了潘多拉魔盒的盖子里面真正复杂且决定成败的是提示词工程。很多人包括早期的我都曾陷入一个误区认为AI开发的核心是复杂的系统架构、高并发的服务部署或者精巧的算法。但在与LLM打交道的实践中我深刻体会到Prompt工程才是那个将原始算力转化为实际商业价值和应用能力的“翻译官”和“指挥官”。它不像传统编程那样有严格的语法和确定的输出更像是一门与“外星智能”沟通的艺术与科学的结合体。一个精心设计的Prompt其价值可能远超一百行优化后的代码。本文将基于我多次踩坑的经验深入拆解在AI Agent开发中如何超越基础的API调用通过系统的Prompt工程让你的Agent真正变得“聪明”且“可靠”。2. 核心认知转变LLM不是数据库而是“实习生”在深入技术细节前我们必须完成一次根本性的认知升级。这是所有高效Prompt工程的前提。2.1 从“查询-响应”到“任务-协作”的范式迁移调用传统API或查询数据库时我们遵循的是“精准查询确定返回”的模式。你发送一个结构化的SQL语句或一个参数明确的RESTful请求期望得到一个结构固定、内容确定的响应。如果返回错误那一定是你的请求格式不对或者服务端有bug。但LLM完全不同。把它想象成一个天赋极高但缺乏经验和背景知识的实习生。你不能对它说“SELECT * FROM knowledge_base WHERE topic‘AI’”然后指望它给你一张完美的表格。更恰当的协作方式是“小L我需要在明天的会议上向非技术背景的客户解释AI Agent的价值。请你根据我们之前讨论过的几个项目案例帮我起草一份三分钟左右的、通俗易懂的讲解稿重点突出降本增效和用户体验提升。”这个例子包含了与LLM协作的几个关键要素明确角色你定义了它的身份你的助手。交代背景你提供了任务场景向非技术客户汇报。给定约束你明确了输出格式三分钟讲稿和风格通俗易懂。指示重点你指明了内容方向结合案例聚焦价值。这种从“命令式编程”到“引导式协作”的思维转变是做好Prompt工程的第一步。你的Prompt不是在发送指令而是在构建一个能让LLM充分发挥其能力的“工作上下文”。2.2 理解LLM的“思考”机制概率与上下文为什么这种转变是必须的这需要稍微理解LLM的工作原理。LLM本质上是一个基于海量文本训练出来的、超级复杂的概率模型。它的“思考”过程是根据你提供的所有输入文本即上下文预测下一个最可能出现的词是什么如此循环往复生成整个回复。这意味着一切皆上下文你提供的Prompt就是模型生成回复时所依赖的全部“世界”。模型没有记忆没有外部知识除非你通过上下文提供它的所有判断都基于你给的这几个字、几百个token。输出具有概率性同一个Prompt多次运行可能产生略有不同的结果这是模型采样策略导致的正常现象不是bug。对格式敏感模型在训练时见过无数种文本格式问答、代码、列表、剧本等。你在Prompt中使用的格式会强烈地影响它选择以何种格式来回复。因此Prompt工程的核心目标就是精心构造一段文本上下文以极高的概率引导模型生成我们期望的输出。这就像给那位“天才实习生”一份极其清晰、详尽的工作说明书SOP。3. Prompt工程的核心要素与结构化设计理解了“为什么”我们来看“怎么做”。一个工业级可用的、用于AI Agent的Prompt绝不是一句简单的提问。它是一个结构化的文档。我通常将其分解为以下几个核心部分我称之为“Prompt脚手架”。3.1 角色定义为LLM戴上合适的“面具”这是最立竿见影的技巧。通过为LLM设定一个具体的角色你可以瞬间激活它在训练数据中与该角色相关的知识和行为模式。基础用法“你是一个资深的Python软件工程师。”“你是一位亲切的儿童故事讲述者。”进阶用法结合领域和风格。你是一位拥有10年经验、专精于金融风控领域的后端架构师。你的沟通风格严谨、准确喜欢用比喻解释复杂概念并且在给出方案时总是附带简要的利弊分析。实操心得角色定义要尽量具体。“专家”不如“资深运维工程师”“助手”不如“善于总结的会议纪要助手”。越具体的角色越能缩小模型的行为范围输出越可控。3.2 任务指令清晰、具体、可操作这是Prompt的骨架必须杜绝歧义。遵循“SMART”原则具体、可衡量、可达成、相关、有时限来构思你的指令。反面教材“帮我写点代码。”太模糊正面案例请编写一个Python函数名为validate_email。该函数接收一个字符串参数email。使用正则表达式验证其是否符合常见的电子邮件格式规范。返回一个布尔值True表示有效False表示无效。在函数内部添加详细的注释解释正则表达式每一部分的作用。为这个函数编写三个单元测试用例分别测试有效邮箱、无效邮箱格式错误和边界情况如超长字符串。注意事项指令应使用积极的、要求式的语言“请做…”“输出应包含…”避免开放式提问“你能…吗”除非你确实需要模型进行可行性评估。3.3 上下文信息提供必要的“弹药”LLM没有实时数据库所有任务相关的信息都必须由你提供在Prompt中。这包括背景信息项目介绍、相关数据、用户信息。参考材料相关的文章片段、数据表格、代码片段。历史记录多轮对话中之前几轮的问答内容。关键技巧位置很重要。最重要的上下文应该放在最靠近模型需要“回答”或“执行”部分的地方。通常的结构是角色 上下文 具体任务指令。3.4 输出格式规范让机器易于解析对于需要集成到自动化流程中的Agent输出的结构化至关重要。你必须明确告诉模型你想要的格式。指定格式“请以JSON格式输出包含以下字段summary, points, confidence。”指定语言“请用YAML列表输出以下内容。”使用分隔符这是一个强力技巧。在Prompt中明确使用如“””、“###”、“—”等标记来划分指令、上下文和输出区域甚至直接要求模型在输出中使用特定分隔符。你的输出必须严格按照以下格式【分析开始】 核心问题用一句话总结问题 根本原因列出1-3个根本原因 建议措施 - 措施一描述 - 措施二描述 【分析结束】避坑指南即使指定了JSON格式模型偶尔也可能在JSON前后添加解释性文字。解决方法是在指令中强调“只输出JSON对象不要有任何其他前后缀文本”并在你的调用代码中做好健壮性处理例如尝试从返回文本中提取JSON部分。3.5 思维链与分步指令引导复杂推理对于复杂任务直接要求结果往往会导致模型“跳步”和出错。这时需要引导模型展示其思考过程即“思维链”。简单引导在指令中加入“让我们一步步思考。”或“请先分析问题再给出解决方案。”复杂任务模板任务评估这个项目提案的技术可行性。 请你按以下步骤执行 步骤一提炼提案中的核心需求和技术指标。 步骤二逐一分析每个技术指标在现有技术栈下的实现难度和风险。 步骤三基于以上分析给出整体可行性结论高/中/低及主要论据。 现在请开始执行。这种方式不仅能让输出更可靠也让你能“窥见”模型的推理逻辑便于调试。4. 实战构建一个技术文档问答Agent的Prompt让我们通过一个完整案例将上述理论付诸实践。假设我们要构建一个Agent它能回答关于我们内部“Kubernetes运维手册”的问题。4.1 基础版Prompt能回答但不可控用户如何修复Pod一直处于Pending状态这是最糟糕的方式。模型会基于其训练数据中的通用K8s知识回答可能不准确也肯定不包含我们内部手册的特定规范如公司特定的标签、推荐的节点选择器等。4.2 进阶版Prompt提供上下文指定角色你是一个专业的Kubernetes运维专家负责解答同事关于集群运维的问题。 以下是我们内部的《Kubernetes运维手册v2.1》中的相关章节内容 【手册内容开始】 ... 故障排查章节 - Pod状态异常 1. Pending状态 - 可能原因1资源不足。检查节点资源CPU/Memory是否满足Pod请求。 - 可能原因2不满足节点选择器nodeSelector或亲和性规则。检查Pod配置的nodeSelector是否与任何节点的标签匹配。公司规定生产环境Pod应携带标签 env: prod。 - 可能原因3未满足PVC绑定。检查PersistentVolumeClaim是否处于Pending状态。 - 排查命令kubectl describe pod pod-name -n namespace查看Events部分。 ... 【手册内容结束】 现在请基于以上手册内容回答用户的问题。如果手册内容无法完全覆盖问题请基于你的专业知识补充但必须明确指出哪些是手册内容哪些是你的补充。 用户问题如何修复Pod一直处于Pending状态这个版本好多了。它定义了角色提供了精准的上下文并给出了回答的边界指令。4.3 工业级Prompt结构化、可解析、带验证对于一个真正的Agent我们往往希望它的输出能被下游系统如工单系统、监控仪表盘直接使用。因此我们需要更结构化的输出。# 角色与职责 你是一个严格的Kubernetes运维助手必须严格依据提供的《内部运维手册》进行回答。手册未提及的内容你应明确表示“根据手册未涉及此情况”不得擅自编造。 # 上下文信息 此处通过RAG技术动态插入与用户问题最相关的3段手册文本片段 # 用户问题 {{用户输入的问题}} # 输出指令 你必须按以下JSON格式组织你的回答且只输出此JSON对象无需任何其他解释 { “direct_answer”: “针对用户问题提供一个简洁、可直接操作的行动摘要2-3句话。, “analysis_steps”: [ “第一步...基于手册” “第二步...基于手册” ], “reference_sources”: [“来自手册第X章Y节” “来自手册第A章B节”], “confidence”: “高/中/低”, // 基于手册内容匹配度判断 “internal_rules_applied”: [“规则A...” “规则B...”] // 如涉及公司内部规则如标签规范在此列出 } # 处理逻辑 1. 仔细将用户问题与提供的上下文手册片段进行匹配。 2. 如果上下文能完全覆盖问题则confidence设为“高”analysis_steps严格引用手册。 3. 如果上下文部分覆盖则confidence设为“中”在direct_answer中优先依据手册缺失部分可简要补充通用知识并说明。 4. 如果上下文完全不匹配则confidence设为“低”direct_answer为“根据现有手册无法找到该问题的直接解决方案。建议查阅[相关官方文档链接]或联系高级运维。”这个Prompt模板已经具备了生产级应用的雏形。它通过动态插入上下文通常由检索增强生成技术实现指定了严格的、机器可读的输出格式并内置了回答置信度的判断逻辑。5. 高级技巧与避坑指南掌握了基础结构后一些高级技巧能让你事半功倍。5.1 少样本学习提供例子事半功倍对于格式复杂或逻辑要求严格的任务在Prompt中提供一两个输入输出的例子效果极其显著。你的任务是将自然语言指令转换为标准的Linux命令行。 请遵循以下示例的格式和逻辑 示例1 输入“给我看看当前目录下所有PDF文件的大小按从大到小排序。” 输出find . -name \*.pdf\ -type f -exec du -h {} | sort -hr 示例2 输入“终止所有名字里带‘test’的进程。” 输出pkill -f \test\ 现在请处理新的输入 输入“{{用户的新指令}}” 输出实操心得例子要典型要覆盖不同的情况。例子中的输入输出格式就是你期望的格式模型会极力模仿。5.2 温度与采样参数控制创造性与一致性除了Prompt内容调用API时的参数也至关重要。温度控制随机性。值越高如0.8-1.0输出越创造性、多样化值越低如0-0.3输出越确定、一致。对于需要事实准确、格式固定的Agent任务通常设置较低的温度0.1-0.3。Top-p另一种采样方式。通常与温度配合使用。对于需要严格控制输出的场景可以设置较低的温度和较低的top-p如0.9。避坑指南不要盲目追求“创造性”而调高温度。对于大多数功能性Agent稳定可靠的输出比天马行空的“聪明”更重要。先从低温度开始测试。5.3 系统提示词 vs 用户提示词利用好对话角色在OpenAI等平台的Chat Completion API中存在system和user以及assistant的角色区分。合理利用它们可以更好地组织Prompt。system用于设定全局角色、基础行为准则和高级指令。这部分内容通常贯穿整个对话会话为模型设定基调。适合放置“角色定义”和核心行为规范。user用于传递本次对话轮次的具体任务、上下文和问题。assistant用于提供少样本学习中的示例回复或在多轮对话中代表模型的历史回复。将长期有效的指令放在system中将本次特定的上下文和问题放在user中可以使Prompt结构更清晰也符合多轮对话的管理。6. 调试与迭代像优化算法一样优化PromptPrompt工程是一个高度经验性和迭代性的过程。没有一蹴而就的完美Prompt。6.1 建立评估体系在开发Agent时你需要定义清晰的评估标准来判断Prompt的好坏。例如事实准确性输出内容与已知标准答案的匹配度。格式合规率输出符合指定格式如JSON的比例。任务完成率对于指令性任务如“提取以下文本中的日期”成功完成的比例。人工评分让领域专家对输出的相关性、有用性进行打分。6.2 常见的失败模式与调优策略问题现象可能原因调优策略答非所问任务指令不够清晰角色定义模糊。重写指令使用更明确的动作动词“总结”、“列出”、“对比”强化角色定义增加限制词“仅基于以下文本”。忽略部分指令指令过于冗长或复杂模型“遗忘”了开头或中间的部分。简化指令将复杂任务拆分成多个简单Prompt链式调用使用分隔符强调关键指令将最重要的指令放在最后。输出格式错误格式描述不够严格模型在输出格式外添加了额外文本。使用“必须”、“严格按以下格式”、“只输出JSON不要有其他文本”等强约束词在少样本学习中提供完美的格式示例。幻觉编造信息上下文信息不足模型被要求回答其知识范围外的问题。强化上下文供给通过RAG在指令中加入“如果你不知道就明确说不知道”降低温度参数。表现不稳定温度参数过高Prompt本身存在歧义。降低温度如设为0.2审查并消除Prompt中的歧义表述增加确定性约束。6.3 工具链支持不要用记事本手动调试Prompt。建立你的工具链版本控制使用Git管理Prompt模板的迭代每次修改都有记录。测试集构建一个涵盖各种边界情况的测试用例集QA对每次修改Prompt后批量运行评估效果变化。A/B测试平台在生产环境灰度发布时可以对不同版本的Prompt进行A/B测试用真实用户反馈和数据来驱动优化。专用工具可以考虑使用LangChain、LlamaIndex等框架来模块化地构建和管理Prompt模板或者使用像Promptfoo这类专门用于评估和测试LLM提示词的工具。7. 从Prompt工程到智能体架构当单个Prompt变得复杂时它就成为了一个“智能体”的雏形。真正的AI Agent往往由多个Prompt、工具调用和记忆模块协作而成。规划一个顶层Prompt分析用户目标并将其分解为子任务序列。执行不同的子任务由不同的、高度特化的Prompt或调用工具来完成。反思一个评估Prompt检查执行结果决定是继续、重试还是终止。例如一个数据分析Agent的流程可能是规划Prompt理解用户问题“上季度销售趋势如何”决定需要调用“查询数据库工具”和“生成图表工具”。工具调用执行SQL查询获取数据。分析Prompt将数据结果和“生成季度销售趋势分析报告”的指令结合生成文本分析。图表Prompt将数据结果和“绘制折线图”的指令发送给代码生成工具生成绘图代码。整合Prompt将文本分析和图表代码整合成最终答案。在这个架构中每一个环节都是一个精心设计的Prompt。因此深入掌握Prompt工程是构建复杂、强大AI Agent的基石。回到开头那句话调用LLM的HTTP请求只是按下了这台强大引擎的启动按钮。而Prompt工程则是你手中的方向盘、油门和刹车决定了这台车是平稳驶向目的地还是四处乱撞。它没有终极的银弹答案只有基于对模型原理的深刻理解、对业务场景的精准把握以及无数次调试迭代后形成的直觉与经验。这份“真功夫”需要你在每一个具体项目中亲手去磨练。