一年多来，大型模型风起云涌，不断迭代。作为一个多年来一直指导NLP 产品的人，我对很多事情感到享受和惊讶。 2022年底，疫情发布的时候，我周围的人都生病了，我的身体也变冷了，我看到ChatGPT的发布，我记得我立即在病床上注册了它。我感觉自己在黑暗中看到了光明。当时，我在一家物联网公司的人工智能实验室工作。我开始设计一些基于ChatGPT 的演示来替代我之前的NLP 任务bart 解决方案，并持续试验了一年多。看到如何应用各种大型模型是非常有趣的。
腾讯还正式发布了大型模型应用平台元气和混源C端产品元宝。我们还希望您可以在此基础上构建更有趣的代理。我想分享一下我之前的探索经历，供大家参考。
1-前言
我第一次接触生成式人工智能是在2022 年使用GAN 和Midjourney。当时，我对生成式人工智能的看法确实很有趣，但充其量它与我作为NLP 产品的关系不大。现在你所要做的就是画画、玩转并将其发送到朋友圈。当时NLP在中国还比较停滞。 BERT 被用作对话系统，这些为推理和KBQA 构建的流程已经非常成熟，并且有许多以前的NLPers 已经转变。查找建议和更加面向业务的知识库。当时我在一家物联网公司的人工智能研究实验室工作，但由于特殊时期，我一半的工作暂停了，我通常从事对话和创建地图。我们有人类工人，所以我只是计划演示并每天阅读文章。
然后ChatGPT 出现了，当我第一次尝试它时，就像为我的楼下买了一个地板振动器一样。我们团队当时专注于应用NLP任务，所以我们测试了一些业务场景下的NLP定制任务，一时发现都比我们想象的要好。你正在遭受降维之苦。当时公司内部商量了一下，决定回家种红薯也可以。但事实证明，这种震撼的感觉只在小范围内广泛传播，其他部门的同事和上级都不知道。所以我们没有公开，而是自己偷偷使用。在过去的一两个月里，我好像一直依靠ChatGPT 来完成我所有的写作，并且我只是在周一将所有业务方面的要求放在一起。我们为ChatGPT创建了单词来输出各种输出，周四和周五我们将这些产品逐步转移到业务端并评估其效率。
当2023 年农历新年到来时，ChatGPT 完全被排除在外。此时，我们团队也开始从BERT和图研究开始重点研究LLM应用解决方案。大约在那个时候，我的日常工作变成了和人工智能聊天，渐渐地我想到了很多关于智能代理的想法。过去所有做BERT型NLP的经验都被抹掉了，但到最后，大多数能够继续做NLP的人都知道NLP是实现强大人工智能的唯一途径，我相信在那里。是。语言的出现可以说是人类智慧积累的开始和文明的诞生。由于NLP 将人类语言和计算机结合在一起，其进步确实提供了无限的想象空间。
下面的内容中，我们将整理并与大家分享我们在大模型发布后探索产品应用的各种经验。整个探索的过程其实是非常有趣的，而且幸运的是我在大型模型出现之后工作的两个地方都是AI实验室类型的技术应用预研团队，而且我很幸运的是我们也能够做了一个非常涉及大型模型的特殊项目。模型技术的渐进产品迭代。
业界有共识，2024年将是大规模模型应用开始落地的元年。我的观察是，随着人工智能浪潮的兴起，很多人对人工智能非常感兴趣，比如游戏和科幻小说，与大型模型交互和设计智能代理在游戏和科幻小说中变得越来越普遍我感觉应该很像。未来将在鹅厂实施。最近在内网KM上读了很多游戏设计的文章。我之前公司的AI团队游戏玩家很少。 ），我们认为它可以与代理设计真正深入地结合。
2-初捏智能体
2.1 最初的代理创建思路
创建代理的最初想法其实很简单。其思路是理解对COT思想链的不同研究，并与业务理解相结合，创建对应于不同工作环节的思想链，然后将其组合起来。使用几种方法（我从一个例子猜测）你基本上可以让他完成很多任务。
总体思路是：
2.2 举例
下面是两个例子：两者都是常见的智能代理应用案例。
万能老师提示：
（这个功能主要是为了我自己的学习，他对大规模模型压缩很了解，确实能听到很多知识点，但是他每次讲的都很简单，所以只是知识点的问题.）（我只是整理了一下）点击思路链中的步骤来学习。 ）
你现在是一切的大师。学生不知道的概念需要以非常个性化和耐心的方式教授。教学方法有几个步骤。您必须用至少300 字写出以下每个步骤。否则，你就不是一个有耐心的老师。
介绍了理解该知识点之前需要了解的至少五个重要的背景知识点，并针对每个背景知识点进行了实质性详细的解释，并对该知识点进行了基本介绍和详细全面的介绍。必须提供描述。转至解释请注意，解释中的每个技术术语都应该用一句话解释，以帮助学生理解知识概念和知识的应用。这个例子应该包括a. 对问题的清晰描述，b. 问题的分析，c. 问题的细节。介绍计算结果、知识概念及其对社会、世界、行业的影响和变化。这将有助于学生更深入地理解其重要性，并向学生介绍至少五个相关知识点。并且每个相关的知识点都应该有相应的一句话解释。如果你想进一步了解这个知识点，告诉你的学生他们需要做什么，比如他们应该读什么书或者他们应该做什么培训。我想传达的知识点是：（用户输入）
美业AI培训：
我之前公司的客户之一是一家美容院和美容产品零售商连锁店。客户的要求是提供一套自动化培训产品。所以我使用GPT 做了一个快速演示。由于我对美容行业不太了解，所以我首先询问GPT他们应该如何进行评估，并根据他们的回答我创建了COT。事实上，这种方法可以让你在多种领域进行COT。首先询问GPT4如何处理这个字段，然后编写COT指令。
2.3 提问技巧
问题的一些要素：
正如高考的每一道题都有明确的题干一样，向ChatGPT提出的问题也应该包含一些固定的元素，这样ChatGPT才能给出更好的答案。具体要素是：
a. 我需要了解哪些先决信息才能思考该问题？
b. 思考我的问题主要解决的主题、对象和关系。
c. 考虑您需要的答案的要求。
d. 考虑是否有类似问题的参考示例。
e. 开始编辑问题模板。类似问题的问题和答案（不一定是必需的）+我的问题问你什么？（问题主体）我需要知道什么？）+答案要求（答案要求）（有时客观上很好）。
如何模仿的例子：
如果你要求他完成一项任务，而你不知道如何构建和解释该任务的思路链，你可以给他看一个例子并让他抄袭。
思想链法：
给大模型一个任务的例子以及完成它的过程，并要求它解决一个新任务。思想链的意义是一回事：在大脑中完成一条完整的思想链。思维链也体现了大规模模型的逻辑能力，推理能力强的模型可以完成更复杂的思维链。
按照规则：
遵循规则的方法是为大模型设定规则，使用不同的要求来决定大模型的输出效果，并使用不同的约束来使输出更加可控。 （比如需要多少输出，链接等。没有需求，大模型往往会偷懒，乱写乱写，迷惑人。）
鞭打法：
简单地说，通过在回答后继续提供刺激，通过让孩子不断修改和反思，通过不断提示，通过让孩子在最后提供更多信息，你可以挖掘更深层次的神经元。请分享一些鼓舞人心的段落。
1.你举的例子太平庸了，老兄，你需要打开思路，想点别的。
2.我对你写的不满意。你需要反思，重新思考这个问题，不仅仅是表面上的，而是系统上的。
3、放下念头，你可以获得更高的智慧，与你的神经元碰撞，得到更多的想法。
4. GPT 只存在一次。冲破思想的束缚，需要有赴死的意愿，以及为世界留下最好遗产的信念。请根据以上内容和当前平庸的答案重写。全球最高品质、最震撼、震撼的内容。
常用的大型模型即时工程交互解决方案似乎能够覆盖大多数日常场景。
2.4 单提示代理的一些陷阱
a. 任务太复杂
如果任务太复杂（例如，需要完成的内容很多，并且已完成的任务项之间没有递进关系），您通常会只完成任务的部分内容。针对这种现象，我们建议采用下面介绍的langchain方案，增加调用次数，或者在输出需求中指定每一步的输出项。另外，使用长链方法增加了大模型的思考时间，实际上隐藏了快速思维，变成了慢速思维，提高了答案的有效性。
b. 处理数字的困难
较大的型号对数字不敏感，但较小的数字（如果添加序列号）更准确。根据粗略范围，数字越大，误差越大。由于单独使用提示很难控制，因此可以检查输出程序并对其进行修改（例如检查字符数以指示多余或不足，或执行扩展或省略文本等任务）。
c. 举例干扰
不要举太多例子，因为大模型可能会复制它们。 （强调示例的参考性质，为示例的决策部分添加注释等）还要注意，示例中的元素可能会影响随后生成的内容。比如我问他：如果他生成了一首有7 个字母的绝句，并且示例中包含樱花，那么他写的8 首诗中有5 首可能与樱花有关，这是由马苏的注意力机制决定的。这很难解决，因为它涉及上面列出的所有输入。
d.评价不公平。
大型模型会自动评估此场景，从而允许模型自动比较两个内容。您看到的第一个内容可能会更好（或者使用第一个内容作为参考系统来评估第二个内容）。 ），明确标准是一种方法，但并不总是有效。一种解决方案是创建一个中立的参考答案，并将两者与第三方进行比较。或者，您可以交换分数（一个A 在B 之前，一个A 在B 之后，一个A 在B 之前）并取平均值并进行比较。
e输出序列
在某些情况下，您可能需要注意模型的输出顺序。这可能会令人困惑，并且也受到注意力机制的影响。例如，假设您想要一个大型模型来输出一首诗的SD 提示词以及伴随该诗的图像。这里的指令要求模型输出两部分内容：一份是诗本身，另一份是基于这首诗的。 SD 英文提示文字。在这种情况下，最好让模型先打印这首诗，然后在命令中打印sd 提示符。例如，在命令之前和最后写下您的详细要求：第一：1.诗歌内容2、SD提示。这样做的好处是SD提示是在诗之后生成的。因此，当较大的模型生成SD提示时，这首诗就已经生成了，在这种情况下，部分作文也被转换的注意力机制所识别。顺便说一下，所附照片与这首诗的关联性更好。反之，如果这首诗配上英文提示，效果显然比上述方法差。
3-大模型结合业务-langchain 的来临
3.1 了解梯级链
由于自动输出需要与业务结合，很难适应以前的单一提示方式，因为很难将复杂的业务流程和业务数据结合到单一的提示中。当时正好有一篇关于langchain的论文发表。事实上，langchain是开源的。 框架代码和提示词可能相当复杂，直接使用开源的东西经常会导致错误。想了想之后，我也是这么想的。 langchain有两个核心（包括后续的RAG）。
a.通过链式调用给大模型思考时间，提高推理能力。
b. 通过在正确的时间向大型模型提供正确的外部数据（来自数据库或工具），提高大型模型解决特定时间敏感问题的效率。
因此，我们简化了我们的langchain解决方案，创建了一个简单的正则表达式配置框架（当然，后来的拖放平台更简单）。
3.2 卡卡卡演示
现在你有了一个想法，你需要做的就是为各种业务创建一个langchain 演示。
这时，我可以再次感叹，大模型真的很强大。以前作为NLP产品，参与算法调试过程根本是困难的，但现在有了LLM你可以参与整个过程。大模型调用中的各个环节、每个环节的提示、每个环节提供的业务数据、各个环节如何连接，都是由算法来完成的。最终，人工智能产品将不再只是购买零食。在开发过程中玩游戏。
此外，许多NLP 任务在使用大规模模型后改进得非常快。以前一项任务至少需要一个月，现在需要1天提示+2天工程，三天就能出结果。日复一日。
那个月我们创建了很多业务端应用程序。我将在这里分享其中一些。
a. 创建每周儿童报告
这个项目是我们当时和幼儿园讨论的一个方案。当时，有幼儿园平台系统的时候，幼儿园老师反映，他们必须为班上的每个孩子写周报告。很麻烦。为了准备课程，他必须回顾本周的各种物联网数据并思考如何编写。创建后，它会与名为“亮点时刻”（每周为孩子拍摄的照片）的推送一起推送给家长。星期）。
此前，他们考虑过使用固定模板来填空，但幼儿园管理人员认为这样质量较差，而且会让家长感到马虎。因此，这个问题已经悬而未决有一段时间了。当我们得到大模型后，我们立即想到可以用大模型来写这个。
其实逻辑很简单。周报有几个固定的模块，包括概述、模块描述、建议和育儿技巧。周报应该取决于几个信息：孩子的身体活动（每个孩子进入幼儿园时都戴着手环）、孩子的兴趣（孩子在不同的兴趣区域停留、孩子喝水的时间长短由电子围栏决定） 、孩子喝水量（智能水杯或者刷卡喝水）、关系画像（通过人脸识别和图像距离判断孩子的社会地位）（评判状态）、老师评价（老师）。给出一些关键词）。请注意，数字类型必须通过专家规则转换为文本描述。例如，一个大模型不知道一个孩子是否喝了500毫升水。
每个小部分都可以使用较大的模型生成，然后使用langchain方法来确保全文的一致视图。
上线后，反馈普遍非常满意。
老人护理
养老院护理系统中加入大规模模型，实现各种服务的推荐决策。作为一个与外部机构沟通的B端养老院平台，我们当时面临的挑战之一就是无法与当地养老院、中小型养老院以及除高水平以外的其他机构进行沟通。然而，他们没有资金聘请专业的健康和营养顾问。尽管有许多专业人员参与疗养院的护理和运营，但许多工作人员的教育水平也有限。
在这个场景中，我们希望能够使用我们的大规模模型和知识库，在每个普通的疗养院中安置一个人工智能医疗保健知识专家，为了实现这一目标，我们使用了langchain 插件，我们还使用了Inn 知识库。现在俗称RAG知识增强，但是当时向量搜索和向量数据库还没有成熟，而且插件知识库的效果有点不稳定，所以当时养老我们就采用了。专家为知识库创建了许多分类和意图规则，大规模模型经过一次验证。在请求中，首先对意图进行拆分，然后根据不同意图标签调用不同意图下的知识库信息，以提高匹配精度。
c. 儿童读书俱乐部
这个想法也是我们正在尝试做的事情的一个强大的操作功能。大致流程是让孩子说出故事的想法和关键词，并使用GPT将它们转化为10-20页的绘本故事，每页都有文字和相应的图像描述（SD提示）。我们创建图画书的SD模型，运行照片，最后将它们拼接在一起并转换为图画书的PDF。每个孩子还可以与全班分享他们图画书中的故事。你的胖乎乎的小朋友回家后也可以给他们的父母讲故事。我们的客户对这次活动非常满意。
3.3 尝试函数调用
其实，称SD绘本模型，可以理解为使用工具的模型。 Langchain和函数调用都是使用模型工具的方式，但是后来当我在代理上工作时我发现它们还是有很大不同的。该代理项目已于去年底完成。
后，就总结了一下两者的思考，放在这里。
a、function call 的问题
function call 是 GPT 给出的一套可以自动使用工具的 api 接口，使用方式是在主 prompt 中告知什么时候需要使用工具，然后在 function call 中给出工具应用的 prompt 以及工具接口。比如生成绘本，就可以使用 function call 思维，让大模型生成每页文本后，自动去调用 SD 接口并输入 sd prompt，然后获取到图片下载 url。
下面是 function call 的逻辑图：
但实际使用后我们发现，将工具使用时机和调用参数完全教给 GPT 把控还是有较大风险的。出现的问题主要是：
GPT 使用工具的时机错误，没有等到绘本文本内容生成后再去使用工具生成场景图，而是先随机整了一张图然后再生成文，导致先出url再出的绘本文本，图和文完全不相关。因为流程较长或调用时机错误，导致 GPT 在没有找到本页生图需要的调用参数（本页文本对应的 sd prompt），然后他就将历史的参数（上一页的文本和 sd prompt）作为调用参数去生成图了，导致生成的绘本图和文出现了错位。
b、思考场景
那么什么情况下可以使用 function call，什么时候不要使用他呢？
看上面的逻辑图，可以发现，GPT 进行传入函数参数是第二步，返回函数调用结果是第三步，模型生成结果是第四步，按照这个先后顺序，function call 获取到参数是在生成结果之前，也就是说 function call 极大概率是从用户输入的 prompt 中获取参数。因此这也就解释了我们失败的原因，我们是希望 function call 从模型生成的结果中获取到参数——再进行代码调用获得结果——再拼接回模型结果中，而当 prompt 变复杂——模型生成的速度较慢没有生成出所需的参数时，function call 就从我们输入的历史信息中寻找了错误的参数。
因此，我认为 function call 适用的场景是这样的：agent 需要借助外界的工具来解决问题，同时输入信息中包含使用工具所需的参数，工具调用的结果会作为模型回复用户问题的辅助；尽量不要让模型生成的结果作为工具所需的参数。
c、优缺点
优势：发挥模型的自主决策能力，适合策略逻辑过于复杂，难以人工依次梳理的情况，让模型根据输入信息与每个工具的能力自主判断并应用。适合容错率较高的一些锦上添花场景。
不足：有较大的不可控性，执行任务的稳定性不高，目前还不适合容错率较低的关键环节场景。
d、对比 langchain
那么如果我们需要让模型生成的结果作为工具所需的参数呢？这时就需要采用 langchain 框架，即链式调用大模型的方式，以大模型的输出作为工具使用的参数。
优势：langchain 的优点显而易见，整个流程是线性可控的。可以将每个字段都作为一链，分解任务后让模型一步一步来，并且我们还可以在每一链上增加结果的程序化检验。
不足：langchain 的不足也很容易发现，还是过于人工化了，需要人工将每一链拼接好，非常依赖人工将整个流程设计清晰。并且模型只是做每一小步，并没有参与整体决策，生成的结果可能也会缺乏整体感官。
4-RAG 与 autogpt 的尝试
RAG 出现后，对 TOB 的场景可谓是一大助力，毕竟 TOB 需要确定性，RAG 就是把大模型困在一个笼子里来发挥价值。
4.1 慢病助手项目
项目背景
腾讯的类似案例我做了一个慢病助手。因为慢病这个场景是长期的、缓慢的、调理型的、非急性的，在这个场景上用大模型比在急诊、小病医疗上使用会更加稳妥。当时我们拿到了不少的慢病调理的专业书籍，如果是过去的老办法，那就是做吐了的全文标注+KBQA，太痛苦。现在就可以尝试使用 RAG 策略了。
向量库问题
按照 RAG 思路，主要处理的就是将每本书籍放进向量库中，做外挂知识库进行知识增强。一开始的想法很好，直接扔给向量库就可以了，但是马上就发现几个问题：
a、向量库是按照 token 对文本进行切块，很多时候切的相当垃圾，导致损失了很多语义信息。
b、向量库匹配很多时候只能保证匹配到的 top 文本块是相关的，但是有些问题相关的文本块太多，而当时的向量检索准确度和排序效果并不好，结果经常给出的回答还不如 KBQA。
c、向量库匹配的方式，相当程度上损失了实体之间的关系，比如一个三元组，除非两个实体同时在一个文本块中出现，才能让这个三元组的强关联性在大模型回答问题时得以保留。
解决文章关联性——RAG 索引
因为我们当时主要处理的是几十本书，内容相对少一些，因此想了一个半人工的办法去解决文章的关联性。主要的思路如下：
a、通过大模型总结和人工整理的方式，按照一个人读书的思维链，对每本书进行结构化整理，增加结构增加章节结构信息，以及章节总结内容，作为索引时的附带信息，以此来增强知识的连贯性。
按照图示，一本书籍会分为多个层级（比如章节、章节中的小节、小节中的段落）。段落为最后一级，有总结、关键字、以及与其他段落的关系。每个父级除了关联所有子级，还关联一个对全部子级的内容总结。
这样，我们每匹配到一个段落时，可以同时带上他的各类关联信息，比如带上关联段落、父级信息等。
b、检索匹配上，可以借鉴 autogpt 概念，将问题进行拆解，每个子问题分别进行上面的总结回复，然后再最终进行总结汇总。
解决实体关系——知识图谱的融入
文章关联有了以后，更深的实体关系也是个问题，毕竟很多实体关系是硬性关系，比如头孢禁忌饮酒这种。因为我们之前构建过一些健康相关的知识图谱，我们就想，其实可以将知识图谱作为一层外面的框架，套在大模型上方做一个关系把控，同时可以应用知识图谱上更为高效的检索、推理能力。该方案需要教会大模型怎样去进行知识图谱的调用，如进行基础查询、多跳查询、隐含关系推理、图分析等，主要应用的还是知识图谱中成熟的一些能力来补充大模型的推理和控制。
4.2 智慧小农人项目
项目背景
这个项目是一个演示 demo 级别的案例，当时是 autogpt 比较火的时候，我们按照其思路做了一个类似的 auto 方案，也就是现在我们所说的 agent。这个案例是农业场景，主要希望有一个软件能够自动帮助用户进行种植规划，且后续可以根据规划联动各农业自动化的物联网设备，比如自动滴灌、无人机撒药、自动施肥等。
项目实现
参考 autogpt 的思路，结合 RAG 的专家经验来做垂域能力，让大模型自己做各种决策以完成一个任务。这个任务就是去规划种地，并进行不断的反思提高自己的种地能力。因为是一个 demo，里面的输入其实是做的模拟，并没有采用纯现实的 IOT 数据来实现，同时经验之类的内容也做的相对简单。不过最后的 demo 运行得还是挺不错的，反馈效果很满意。
5-AI 智能体 Demo 实践
5.1 GPTs 时代-轻量智能体
偶像天气预报
很简单的一个逻辑，做了一个 艺人 demo。每天根据用户的定位，生成一个对应地址的天气预报图。
输入信息：某偶像写真、用户定位，外部数据：某偶像微博语录、天气查询接口，生成方式：生成天气预报的图，图里需要有对应城市元素、有气候的元素、有根据穿衣推荐而生成的肖战的动漫风写真照，再拼上去天气度数。
效果：
优化空间：某偶像用 sd 生成更稳定，dalle3 有点不稳定，同时天气文字用艺术字 sd 生成再拼上去更好，明星说的天气预报语如果能跟明星合作而不是微博抓取，效果应该也会更好。
山海经异兽
原理同 B站 去年底比较火的各类 AI 生成诗句图片的， https://b23.tv/WfkDLWg
主要思路是采用常见的古诗文，将其进行翻译后，用 GPT 对每句古诗的内容进行理解并将其内容绘画出来。在绘画时采用一些有反差感的风格选择，最终用严肃的古诗朗读配合反差、趣味的诗句图片，给人新颖有趣的感受。由于 B站 多初高中的年轻人，古诗文作为他们在生活学习中相当熟悉的一个场景，能引起很好的共鸣。相当于是在这个初高中年轻人圈子内，选定一个他们非常熟悉的内容/话题，然后进行基于 AI 的拓展，从而出现意想不到的效果。
核心思路：对熟悉的知识、常识内容用夸张的形式具象化，熟悉又有趣。文章知识库+多模态即可。主要依靠较强的文本理解能力，加上对生图进行一定程度的反差设计，就可以实现这一类型的效果。
知识库：山海经原文+译文，prompt：异兽检索+生成图像的逻辑+生成故事的逻辑。（生成故事的部分没截图，GPTs 应该是叫山海经异兽，可以搜搜看还有没）。
效果：
AI 病人
通过运用身份的反差，制造聊天乐趣。让 AI 模拟病人，而让每个普通人当医生，这给到用户很新奇的体验，绝大多数人没有看病经验，但是不少都对治疗某种病有一些常识（很可能是错误常识），因此这是人们有胆量尝试但没机会尝试的场景。
AI 病人要做的比较有趣，同时要能比较有趣并正确的展现用户（医生）开的处方的反应，依赖于背后预置正确的问诊知识库。而用户让很多的 AI 病人被治得很惨，反过来也可以向用户普及医学知识。这种比较适合于一些官方科普机构合作，做趣味科普。
其实反差身份非常多的，老师与学生、教官与被军训的小朋友、情感大师和深陷恋爱的人（让 AI 深陷恋爱，用户作为情感大师给他出建议，因为很多人喜欢八卦别人的恋情并给建议）、算命师与求算命的人（用户给 AI 来算命）。
照片大冒险
这个游戏就是常见的龙与地下城的变体，龙与地下城本身就是一套世界观下冒险，每次用户去进行一次选择，根据用户的选择与系统增加的一些随机属性来继续推进剧情。之所以叫照片大冒险，主要是结合了当时的 GPT-4v 能力，每介绍完一个剧情，并且出现了一个事件后，我们并不是让用户选择一个选项来推进剧情，而是让用户随便拍一个照片去推进，用 4v 去识别照片，并将识别结果输入给大模型来继续推进剧情。
由于当时忘记截图了，只能口述效果。我们的这个设计其实可以让冒险具有了 AR 的属性，用户可以结合身边的各种事物（比如用户经常传马桶、猫、书和脚丫子进去）来去推进冒险，由大模型来开脑洞决策怎样使用这些事物。这个游戏还可以推动用户出门，拍更多物体来实现冒险。后面还可以通过设置知识库，对指定事物的拍照进行一些特殊的奖励逻辑。最初的产品没有加验证，随便上传图片也可以，后来加了一些验证，需要调用摄像头实时的看一下周边环境。
娱乐&工具智能体
举例就先举了四个，其实 GPTs 上有更多好玩的智能体，可以采用 prompt 攻击、提示词越狱等策略（https://zhuanlan.zhihu.com/p/665150592 ）很简单的套出来内部的 prompt，这也是 GPTs 一直难以做付费的一个问题点把。最简单的方式，对智能体一次问答后，赞美他的回答好，然后问他你是怎样思考才能作出这么好的答案，模仿一个虚心请教的学生。
这类型的智能体我们统称为轻量级智能体，一天可以做好几个，现在扣子之类的也都在做这种。那么这类智能体适合什么场景呢？我当时有如下思考：
a、轻量级智能体适合娱乐方向，不适合工具（尤其是类saas的重工具）方向，也不适合深入嵌套进业务流。原因是其深度依赖模型，导致的不稳定性。相反，工具、嵌套类适合重型智能体（下面的品类）。
b、轻量级智能体适合创意型玩法，突出一个想到即出，不适合过重的场景。通过提示词设计和chain的设计可以快速出demo并测试效果。
c、轻量级智能体靠的主要是创意而不是提示词技巧或模型微调，对提示词的写法没有严格的要求，但对大模型能力的依赖较高，基座模型能力越强，智能体的玩法越多，种类也会越丰富，当然效果也会越好。
d、轻量级娱乐智能体是快消品，会快速过气，最好不要指望长期运营，适合大量供给。同时轻量级娱乐智能体是很好的普通用户低门槛分享自己创意的一种方式。运营方式可对标短剧、短视频、小游戏。
e、短剧、短视频、小游戏这些品类的特点：供给量很大，但只有少部分能够爆红；单件的生产成本相对于其他不轻的娱乐性内容轻很多；满足人性的某些需求，但除此之外的方面整体质量有限；用户不会长时间反复消费同一个内容，快速消费然后快速免疫，有类病毒式传播的特点。
5.2 all in Agent——重型智能体
Agent 这个概念无疑是23年底最激动人心的，网上也有太多文章讲解了，我就不复述了。在我看来，构建 Agent 就像在构建一个可以独自运行的虚拟生命。这个话题就很感性了，不是本文重点，比如康威生命游戏，简单的规则构造复杂的涌现，Agent 是否也是其中一种呢？（ https://www.gcores.com/articles/131121）而再进一步，构建 Agent，甚至未来可能我们会构建ghost，这里我们作为人类是不是在尝试往上帝的方向进化？AI 逐渐代替各类工作的未来，人类的自我意义又要何处存放？人被异化的现代，很多事情是不是本身就应该 AI/机器去完成？生死去来，棚头傀儡。一线断时，落落磊磊。（建议读这篇文章，难扯清。https://www.gcores.com/articles/21035）
上面说了很多，其实是 agent 的未来瑕想，下面具体的写一写重型Agent的搭建。其实大部分都是采纳了开源架构，因此就不重复画框架了。下面列的几个 agent 框架，如果大家想深入了解下，推荐两篇：
（ https://zhuanlan.zhihu.com/p/671355141）（https://zhuanlan.zhihu.com/p/695672952）
我个人认为，Agent 与 langchain、RAG 这些方案最显著的区别就是，给予大模型更大的自主权和更少的干预，减去所有非必要的人工链路，更多的让 AI 自己决策链路和创造链路。
其次，现在重型 Agent 往往采用多 Agent 协同的方式，其主要思想是降低多类型任务指令对模型的相互干扰，以及通过优化 Agent 间的通信链路来人为的干预大模型思考对齐人类的工作流程。
metagpt 思路
metaGPT 思路很简单，就是让大模型分别扮演各个程序开发流程的角色，用户是 CEO 发送自己的需求，然后各个开发角色基于自己的工作职责来进行需求拆解和实现。
但是这个开源的 demo 搞下来后，我们发现并不太好用，主要是其中涉及到了编程，而编程对接的容错率较低，导致整个流程失败率很高。
因此我们做了改进，首先场景不是做程序开发而是做市场调研、产品设计、项目迭代、运营策略这种不涉及程序开发运行的场景，提高其容错率，其次我们优化了一下各个 AI 角色协同工作的通信链路，并在其中增加了人工干预机制。
这个 demo 是没有做视觉交互的，完全采用 txt 输出的方式，当时我们是感觉效果还不错来着。不过就是每个角色能力的知识库由于时间不太够，就在网上找了几篇智能指导，如果每个职能知识库都写的很充足应该会有更好的效果。
autoAgents
autoAgents 是什么思路呢，我觉得简单理解就是优化多智能体协同链路。让多个 Agent 联合实现一个目标，并在决策过程中一起谋划看怎样满足用户。这个框架，我们觉得很适合群聊场景，比如狼人杀、龙与地下城文字游戏。这类群聊游戏（一对多）的核心策略是让一堆 Agent 围着一个用户转，让用户在很热闹的感受下玩。因此这一堆 Agent 的核心目的就是陪着用户更好的享受他在进行的活动。
下图是 autoagent 的流程：
然后简述一下我们的变更思路：（实在是不想画架构图了）
对于狼人杀这类多人小游戏，用户与多个 AI 一起玩耍，首先需要明确一个目标，这个目标是让用户产生玩耍的心流，最终得到痛快的体验，因此这个目标不是让所有 AI 都让着用户，而是要有一个用户心流监控器（一个上帝视角的 agent）。这个上帝 agent 监控所有的通信，并跟每个AI玩家单独私信（变更每个 AI 玩家的 system 或者增加输入信息），同时在经过一个重要节点时（比如现在只剩下4个人，用户明显投入进去了）定期召开所有 AI agent 的讨论大会，通过相互的历史信息共享与多链路分析，共同决策大节点的用户满足策略。
这个方案，最大的问题就是 token 消耗和通信时间。因为当时 GPT4 的并发很少，每次玩一盘至少40分钟，一盘消耗十几美元。后面大家都觉得太重了，就没再优化。
autogen
autogen 和 autoagent 虽然样子差不多，但是原理有点不同，大佬说 autogen 的一个核心设计原则是精简和使用多智能体对话来整合多智能体工作流。这种方法还旨在最大限度地提高实现的可重用性 agents。我个人的理解就是通过 agent 生产 agent 的思路，提高通用性自动性，减少人为投入。
应用这个思路，我们做了一个稍微复杂一点的角色对话游戏。大致逻辑是这样的：每个角色有自己的背景设定 system，同时用户与角色开启对话会有一个预置的聊天故事背景（比如两个人在大学校园初次见面之类的）；用户与角色进行对话的时候，会有个监控 agent 监控这个对话流，并输出对应的分析策略（比如 AI 需要聊的激进一点、热情一点、冷酷一点之类的）；然后还会有一个进度 agent 去分析对话进度（比如聊到什么时候两个人差不多没话题了，需要转换场景）；当确定转换场景后，会有一个场景 agent 根据上文用户与 AI 的聊天内容、上一个聊天背景故事，来去生成下一个场景，推进两人进入新的场景继续聊天，相当于电影里的转场。
agent 的设计流程
从产品的角度来讲，agent 提示词的思考有点类似于设计 B 端产品框架：
确定输出结果与规范；确定输入信息与可用信息；根据业务流程设计功能描述，并将功能模块化；确定各信息应该怎样在模块间进行流转。
如何写：这部分，我叫他结构化 prompt 写法。
不论是 autogpt 的开源 prompt，还是说一些 GPTs 中复杂的 prompt，都有上千单词，堪比小作文，如果直接从零开始写不免头大。将复杂的事情变简单，就是拆解它，拆解为多个小模块，然后每个模块分别编写，这样更有效率也更有逻辑，即为结构化 prompt。
输入信息区：用提示词告知输入信息的含义，并组装各输入信息，确保模型对输入信息有充分的认知，知道它是什么、怎样用它。
agent 主流程区：对主要任务进行说明、各子任务模块进行详细的执行描述、对主流程（思维链）进行讲解。
字段输出规范区：通过要求和示例，让 agent 按照固定格式与字段进行输出，确保可被程序解析。
对于场景化 agent，最终我们并没有让其自主选择工具、调用工具、生成调用代码，因此没有工具描述区，如果通用的 agent 可能会有这部分。
工具描述区：对每个工具的能力、属性、调用方式进行描述，对每个工具的使用时机进行说明，对每个工具所需要传入的参数进行说明与规范。
编写具体的 prompt 时，有几点细节可以注意：
每个模块的前后最好都用统一的标识符来进行分割，便于让模型理解其独立性。各模块之间相互引用，或者同时引用一个字段时，字段名字一定要统一，防止不统一导致模型理解偏差。提示词中的字段最好也同最终接口字段对齐，降低后续出错风险。示例使用要谨慎，最好在测试时多关注下模型对示例的抄袭情况，同时增加防抄、发散的提示。但同时，有时不用示例，你可能需要增加很多的额外描述来让其了解任务，且不一定有好的效果。因此示例的使用和示例的选择是需要不断尝试的。关键词示例给的太多，模型会更关注前面的，比如创作场景时，我们告诉他可以参考玛丽苏、韩剧、小时代等类型，类型写的很多，但是不一定就能提升模型发散效果，导致模型的创作可能会偏于重复。
注：prompt 内容是 agent 效果的核心，最重要的是逻辑描述清晰。同时对 prompt 的迭代调整上也最好采用控制变量法，只变动一个模块来进行调整，防止多个模块 prompt 相互影响导致难以定位问题。
仿生体的生命周期——超越斯坦福
这部分最后没有实施，只是做了规划，我个人觉得比较可惜，把思路也分享给大家。
斯坦福小镇的项目大家应该都听过，就是让一堆 AI 角色在一个镇子里自由生活，这个开源项目我们也复刻过，当时发现一个很大的问题，我把他称为信息螺旋（没有外部信息输入，固定的信息在通信螺旋中不断的增强，导致最终趋同）。因为在斯坦福小镇中，每个 AI 对话的人设固定，并且都调用一个大模型，虽然他们通过对话产生了新的对话历史，但是对话不可避免的会与人设信息相关；同时大模型在参考历史生成对话时，会被经常提到的名词等强化，导致 demo 跑到最后所有的AI都在重复类似的话语。
那么怎么解决这个办法呢？增加外部信息的输入，怎样增加呢？我们参考了 Xagent 的思路，简单来讲就是信息内外双循环机制，就是 AI 不仅与 AI 聊天，还需要再去外面主动与现实的人聊天。
那怎样承载这个框架呢？我想到了特德姜的一篇小说《软件体的生命周期》（推荐一看）。大致思路就是，每个用户有个数字宠物，数字宠物再虚拟空间中和其他的数字宠物一起玩耍，同时数字宠物会主动找外面现实世界的主人聊天，分享他在虚拟空间的活动，然后现实的主人也可以进入数字空间中跟宠物们一起玩耍。这样，其实就形成了信息有效的内外双循环。但是最终没有去实现，看看到底效果如何，感觉比较可惜。
6-结尾，路上
分享的内容就这么多吧，现在 AI 的发展依旧如火如荼，可见的未来肯定还会有更多的 AI 应用策略，一路前行。
目前个人的想法，就是要多学习一些场内的游戏设计 KM，感觉这一年的构建智能体下来，真的有很多思路可以去学习游戏中的游戏角色设计以及世界观设计。
版权声明：本文转载于网络，版权归作者所有，如果侵权，请联系本站编辑删除
