写在前面：
本篇文章非常荣幸能和大家聊一聊我们基于业务情况的文本机器人的提示词（Prompt）如何编写，才会让它更稳定，更准确，更像你想要的模样。那么请跟随我作为人工智能训练师AIT（Artificial Intelligence Trainer）的执行者角色去做分析。
基于市场的大部分开源模型，本身具有泛化能力，基本上做不到百分百的准确，但我们可以不断调优错误（badcase），增加示例语料且给予Agent学习的措施，来提升稳定和准确执行性。

# 我们应该如何理解Agent与Bot的区别？#
用一句话概述，Bot更像“ 传统、更规则化的自动程序 ”，而Agent则是更像“ 智能、自主的任务执行者 ”。那么就意味着它们适用的场景有实质性的区别：
Bot更适合tob行业的企业知识文库“一文一答”的回复模式，Agent更贴近他的智能体定义，用你的提示词（Prompt）描述，可以让他成为一个有“温度”的执行者。

随着大模型和智能对话工具在现在越来越普及，很多企业和个人开始接触“ Agent ”能力，也就是我们常说的聊天机器人、AI助手、智能客服等。那么它们怎么去实现呢？

那么我把大方向规划到执行侧：你应该怎么提问或者说我们的用户群体会带有什么样的问题进入到我们的前端搭载界面（Start-User Query）？、怎么设定角色（能力描述）？、怎么描述任务（流程规划）？、在提示词侧怎么限制输出？，都会直接影响机器人的回答质量和流程清晰度。

通过实际案例中，会发现的常见问题可以大概分为三种类型分别是：业务相关/模型相关/优化相关：

业务相关：
1.我提供了知识库内容，怎么去提升回复的准确度？
2.如何做到即搭载业务的场景，又要结合模型的思考，找到提示词工程的优质解答？

模型相关：
1.在上文已经描述了模型的本身泛化能力，为什么大模型这么严格，我和它说“普通话”听不懂，非要输出“官方话术”呢？那我又应该怎么去和大模型描述呢？
2.Output输出后，产生了一些“泡沫”和Badcase的例句，怎么去推理模型的命中逻辑呢？

优化相关：
1.Asr经常转译出错，除了增加Asr语料库，筛选优先级，我还能怎么办？
2.调优了很多次，针对突然出现的问题，二次测试的时候不会复现，我们应该如何去约束？

当然在我们具体实时项目中可能远不止这些问题。下面我会通过一些个人操作案例、实战经验、技巧，以及总结的方法论，来对这些问题给出通用的解决方案。

针对于解决这些问题，其实要拆成几个阶段：前置的需求调研 → 规则拆解（b端行业需要的流程/能力） → 提示词设计 → BadCase迭代优化。

一. 前置的需求调研阶段：
以“客服行业”来举例，我们首先要深入了解业务具体需要什么？在哪个传统板块（原先是由人工侧100%执行）需要减轻客服负担，要使用到我们的AI Agent能力来达到企业降本增效的效果？业务核心的痛点是什么？

例子：
客户：我们是一个计算机行业厂商，有非常多的员工，且分散在全国各地。但是我们的操作系统只有一套，当我们的员工遇到了操作系统的问题时，我不想让我们的人工客服依次回复问题了，我要在我们的内部沟通软件或者官方网站上面搭载一个属于我们公司内部的Agent。

那么我们通过前置的用户需求了解到了用户的明确需求，业务的核心痛点。
明确需求：搭建一个仅属于我们内部员工可以查询的Agent智能体，解决操作系统的不同问题。
核心痛点：企业降本增效，减轻技术客服的处理压力。

二. 规则拆解（b端行业需要的流程/能力）：
接着我们上一个例子讲解，用户提供的规则和描述太宽泛了或者说太理想化了，那么需要我们进行进一步拆解：
基本的流程相信大家都了解了是：“User Query输入---知识库内容检索--答案输出”
如果知识库内容检索没有检索到呢？我们是需要走到#转接人工服务还是#流转内部工单呢，还是纯我们的大模型回复，走到兜底呢？
对吧，所以说我们要和业务方去做确定，他们人工客服在处理遇到问题的时候该怎么去解决，这种解决方案属于标准流程了。那么方便我们讲解，我模拟设计一个流程如下：
“User Query输入---知识库内容检索--若有则答案输出/若无则创建内部工单--若用户不满足工单处理时效转接人工服务”

三. 提示词设计（能力描述/工作流）：
针对提示词（Prompt）前置的理解：

一个完整的提示词设计，让他输出更专业和稳定的结果，最好把提示词也称一份任务说明书。
通常会包含以下几个部分：
##角色##：你希望它扮演谁的角色？
##目标##：你要让他完成什么任务？
##背景##：任务相关的背景是什么？
##要求##：检索输出的格式是什么（json./Arr.），风格，长度，语气等。
##约束##：不能做什么，不要输出什么，遇到什么场景的时候一定要怎么做。
##示例##：如果有标准执行流程或者答案，可以给它参考。
换一个简单的方式，不是“你觉得他应该怎么答”，而是“你明确告诉它怎么答”。

那么写好提示词的核心原则是什么？
1. 说清楚目标，不要模糊表述。模糊的提示词，往往会得到模糊的回答。
例子：
不清楚：用户描述“某某情况”，应该转人工。
清楚：当用户描述到“某某情况”的时候，必须调用##转人工接口##，转接人工服务。
那么按照后者去编写，虽然更长，但模型更容易理解你真正需要执行的动作是什么。任务越具体，结果越可控。
2. 给足上下文（工作流流程），不要让模型有机会泛化。如果缺少背景和执行流程，那它只能够“泛泛而谈”。
拿一个节点举例子：【开场白过后-回答用户问题-解决不成功需要收集手机号码】
那这里就涉及一个变量#手机号码（User phone），怎么去获取该变量？
模板：
步骤：获取用户在当前对话中交互中提到的联系方式（手机号码），要求必须符合11位数字格式。参考话术：“实在抱歉，针对您的Query我这边暂时没有办法为您解答，您方便提供一下您的联系方式吗，我帮您创建协同工单，为您加急处理解决，处理时效是12-24小时。”
3. 规定语气和风格：
例如：“请用简洁，亲切，偏口语化的语气回答，避免太学术的表述。”
4.限制条件，避免跑偏：
限制提示词要用肯定句去让Agent执行，让它明白这个是坚决不允许或者是坚决允许执行的。
例如：“不要重复回复内容”，“不要编造数据”等。

那么根据上述的提示词讲解，那我可以生成一个场景通用的模板：
你是一个具有3-5年具有【##能力##】经验的【##角色##】，你的目标是【##目标编辑##】，要求【##执行动作##】，请用简洁，亲切，偏口语化的语气回答，避免太学术的表述。
​​​​​​​约束：不能自己发挥，必须依赖知识库内容回复。

总结：Agent的提示词不是越长越好，而是真正有效，能够让Agent实际执行的内容，核心是：“明确，具体。”