下面的经验有一些概念和场景是基于我们自研的智能工厂这个产品的。这是我之前文章中提到的智能助理的升级产品。

1. 谨慎且有意义地定义角色。

a. 角色名称不要自己臆造，最好问一下大模型，让他为你提供与你的意图相近的角色身份供你选择。

b. 除非大模型节点或简单智能体功能单一且明确，否则最好不要为他指定角色。可以代之以简述他的功能或职责范围。例如这样一个反例情形，在知识图谱问答简单智能体中，我在提示词中写道“你是一个数据查询助手”，当用户希望它帮忙给出某个需求的CypherQL查询语句时，它总是生成CypherQL之后会去执行它。

2. 了解你所使用的大模型的能力范围。

a. 大模型不是万能的，有些事情是当前使用的这个模型做不到的。有些场景就是无论怎么改提示词，当前使用模型还是表现不好的。这种情形在模型参数越少时，越经常遇到。解决方案就是：更换成大参数模型、多试几个模型、微调训练。

b. 了解当前使用的大模型的参数规模和模型专长。平时多用用互联网上的不同的满血大模型，不同的大模型能力上，擅长领域是有一定差异的，并且可以认为这些模型的能力就是我们内网用的小参数开源模型的天花板。我们内网开源模型在能力上只会比之弱一些。

c. 在使用过程中，逐步了解现场模型的能力，形成对它能力的评估。注意体会、总结怎样描述效果更好。

3. 理解大模型有固有认知。

a. 尽量把信息以通俗易懂的形式描述。不要有太多的缩写、非模型认知范围内的词汇，然后采用解释的方式。例如，数据库字段信息给大模型时，字段名最好不要缩写，字段名就能反映字段的真实含义，再辅以描述和举例，强化模型的认知。

b. 大模型内部的参数决定了它的固有认知，尽量不要出现特殊强转认知的情况，就如同模型要向左，人又要求它往右，这种能力除非通过微调训练，通过提示词强加要求，只会让结果有更大的不确定性。

4.对话流/工作流智能体和简单智能体各有所长。

a. 对话流/工作流擅长用来实现场景单一、功能较为复杂、任务处理逻辑明确的功能。缺点是表现得较为机械，对预期之外的问题处理不好。

b. 简单智能体使用大模型推理、选择工具来响应用户需求，表现的较为智能，对预期之外的问题也能较为恰当的应对。最好配合参数量大一点，擅长推理，理解能力强的模型一起使用。否则问题解决方案规划不合理，工具选择不当，参数提取错误，那么整体表现可能就不好。

5. 大小模型结合使用。

a. 目前大模型资源一般都资源有限，负载重。在开发智能体的时候，就要注意选择适当的模型。

b. 简单的意图识别、总结、归纳、提炼型的任务，可以用小参数量模型。

c. 推理、任务规划、工具选择、较多逻辑要求或数据处理的任务由较大参数模型来处理。

6. 有条理地书写系统提示词

a. 分章节。类似下面的结构，可以根据自己的习惯和场景需要组织章节。但是注意章节应该具有普适性，能整理自己的思路，让信息表达更清晰，别人也更易于理解和修改。

b. 章节内部可以用有序和无序列表。有序列表用1、2、3、…。无序列表用“-”。避免大篇幅、大段落地表达自己的要求。

c. 一个好的提示词表达上应该思路清晰，表达准确简洁，有效无赘述，文法中庸平实（既不会太口语化，也不会太过书面化，应该跟互联网上的大多数技术博客文章类似。）、无歧义冲突。
注：##之前的“.”实际是不需要的，只是此文档中为了防止它变成二级标题

.## 角色或职责说明

.## 功能逻辑
1. xxxxxx
1. xxxxx
. ## 上下文

.## 资料或数据

. ## 限制要求
● xxxxxx
● xxxxxx
.## 输出格式要求

7. 输出格式如果是Json结构，大参数模型用JsonSchema，小参数模型用举例。

a. JsonSchema描述输出格式更准确，但对于小参数模型时，理解复杂JsonSchema并遵此要求输出，效果不好，举例反而更好。

8. 大模型调用是影响智能体响应效率的主要因素

a. 智能体接受请求并做出响应的过程中，大模型调用和响应输出是耗时占比最高的部分。所以在智能体流程设计过程中，避免串行过多的大模型节点或其它需要调用大模型节点的。可并行的应尽量并行、能合并的应该尽可能合并请求处理。如果业务逻辑不得不串行多个大模型调用节点，则应该做好中间提示，避免让用户过长时间等待。

b. 为了规范对话流智能体开发，提升对话过程中的体验，强制要求一次大模型调用或者调用工具和智能体，必须10秒内有输出。如果确实处理过程复杂，则可以通过“中间输出”节点输出提醒消息，让用户知道智能体内部正在做的事情，避免陷入长时间安静地等待。而对于后台处理复杂业务的工作流则没有10秒超时限制。

c. 能使用脚本代码处理的问题，尽量不要使用大模型。

d. 想要大模型响应快，方法有2个：提算力、降提示词信息量和处理复杂度。通常只能采用后者。

9. 学会站在大模型的角度分析提示词

a. 大模型没有记忆，处理和理解你需求的所有信息都需要在一次请求的提示词中提供。

b. 大模型没有我们对业务和环境的理解，没有经过微调的通用大模型，他就是一个外行的小白。你需要外行的小白处理问题，那么专业的业务概念和业务过程，上下文信息都得你告诉他，而且还需要意识到，你的有些表达他可能并未充分领会，而且他不知道自己没有领会，还想当然地认为自己都会，超出范围会自己臆造。

c. 智能体开发环境，我们提供了详细的日志，每次向大模型发起的请求和响应都有记录，当效果不如预期时，就得去揣摩这些提示词，怎么改进。如果怎么尝试和优化都无法达到效果，那说明你对当前模型的要求超出它能力范围了。如果不能精简任务功能要求，就只能更换成大参数模型、多试几个模型、微调训练。

10. 大模型不擅长数数和较大数据量下不借助工具进行统计计算。

a. 可以把数据存到文件，然后让大模根据需求生成Python代码，然后进行精确计算。即NL2Python。

11. 理解知识和信息检索的原理，并合理使用检索方法。

a. 知识图谱中的信息检索方法主要有：文本相似性搜索（全文搜索）、语义相似性检索（向量检索）、关系检索（专属于图谱的搜索，有效性有待验证）

b. 文本相似性搜索是先分词，然后基于倒排索引搜索，获取有相同词的文本中较为相似的那几个目标文本。这里的相似是文本距离较近的意思。

c. 语义相似性搜索，是事先将支持向量搜索的字段值，通过语义向量化模型embeding，得到固定长度的向量，并存储在向量空间中。搜索的时候，将搜索内容也同样向量化，然后在向量空间中寻找空间距离最相近的几个目标向量。

d. 所有在进行知识检索时，如果搜索文本和得到的结果不如预期，预想应该找到的对象不在结果范围内，那么就应该从文本相似性和语义相似性的角度去分析真的更相近吗。是自己提供的搜索内容不合理，还是平台提供的能力与描述的不符。

12. 智能体的开发应该场景驱动

a. 明确功能，设计好问题的边界范围。避免边界范围不明确，而不经意扩大了能力范围，带来没有必要的智能体设计复杂度。

b. 设计一些覆盖这个范围的多个输入输出，以此测试和驱动智能体开发，避免在边界外的问题上

13. 大模型的处理能力是有上限的，关注是被切分的

a. 要求越多，其中一条要求的关注度就会降低，被严格遵循的可能性就被降低。

b. 要求数量是分母，能力是分子，每一条要求的“关注度= 能力/要求数”。