手搓智能体的这一年

腾讯云开发者

发布于 2024-06-05 14:54:19

2981

发布于 2024-06-05 14:54:19

过去的一年多，大模型风起云涌，不断迭代，作为一个多年 NLP 产品方向的从业者，可以说是享受其中，惊喜连连。记得22年底，那时疫情放开，身边的人全部病倒，在身体冷热交加中看到了 ChatGPT 的发布，马上在病榻上完成了注册，那时的感觉就仿佛黑暗中看到了曙光。当时我在一家物联网公司的 AI 研究院工作，基于 ChatGPT 开始设计很多 demo 取代之前的 NLP 任务 bert 方案，后面一年多不断地实验各种大模型的应用方法，颇为有趣。

腾讯日前也正式发布了大模型应用平台元器和混元 C 端产品元宝，也希望大家一起在上面多做一些有意思的智能体，故分享一下之前的探索经验，供大家参考。

01、前言

初次接触生成式 AI 还是之前的 GAN 和22年的 Midjourney，当时对生成式 AI 的看法是确实挺有意思，但是跟我一个做 NLP 的产品关系不大，顶多也就是玩一玩画图然后发朋友圈。彼时 NLP 在国内处于相对停滞期，用 bert 做对话系统、搭建知识图谱做推理和 KBQA，这些流程都已经很成熟和程式化了，身边也有很多曾经的 NLPer 转向了搜索推荐和更偏业务的知识库方向。当时我在一家物联网公司的 AI 研究院，因为特殊时期，业务处于半躺平状态，平时做一做对话做一做图谱，有多少人工就有多少智能，每天就是规划一些 demo 看看文章。

然后 ChatGPT 就横空出世了，第一时间试用后，那感觉是楼下买了个震楼机，震惊到家了。因为当时团队更偏 NLP 任务的应用，因此上来就拿了一大批业务场景的 NLP 定制任务测试，发现效果全部比我们自己做的 bert 好，一瞬间有种被降维打击的感觉。当时内部讨论就觉得可以回家种红薯了。。。但是后来发现，其实这种震惊的情绪只在小范围内扩散，其他部门的同事不知道，老板们也不知道，因此我们就也不声张，只是自己偷偷用。那一两个月可以说是最快乐的时光，所有写作全部丢给 ChatGPT ，当时感觉每周就工作一天时间，周一收集所有业务侧需求，然后写提示词让 ChatGPT 各种输出就结束了，然后周四周五慢慢把这些生成好的东西再给到业务侧，还被夸效率高。

等 23 年春节回来，ChatGPT 彻底出圈了，这时公司级别也开始重视并规划了，我们团队也从之前做 bert 和图谱变成研究 LLM 应用方案了。那时日常工作就变成了跟 AI 陪聊了，也逐渐有了很多智能体的构思。虽然过往做 bert 类 NLP 的经验全部被抹平了，但是大家还是很高兴，毕竟能坚持到现在还做 NLP 的，大抵都是有点信仰 NLP 是强人工智能的必经之路这句话的。语言本身的出现，也可以认为是人类智慧积累和文明诞生的开始。作为将人的语言与计算机连接起来的 NLP，它的进步真是带来了无限的想象空间。

后面的内容，我会把大模型出现后我们在产品应用上的各种探索经验进行一些整理，分享给大家。整个探索过程其实还挺有意思的，而且比较幸运的是大模型出现后工作过的两个地方都是偏 AI lab 类的技术应用预研团队，也就有幸做了一次很特别的面向大模型技术进展的产品迭代。

行业内的共识，24年会是大模型应用开始落地的元年。而据我观察，这一波 AI 兴起，非常感兴趣的人群很多是喜欢游戏和科幻的；并且与大模型交互以及设计智能体跟游戏真的很类似，感觉未来大模型落地在鹅厂内应该会很有趣，最近也在内网 KM 上看了很多游戏设计的文章（真心很丰富，前公司 AI 团队内都少有玩游戏的），觉得与 agent 设计真的可以深入结合。

02、初捏智能体

2.1 初期智能体写作思路

初期的智能体创建思路其实很简单，就是熟读了 COT 思维链的各种研究，然后结合对业务的理解，把各种工作环节捏出来对应的思维链，并且结合一些 few-shot 的方式（举一反三法），基本上就可以让他执行很多的任务了。

大致的思路如下图：

2.2 举例子

这里可以举两个例子，都是比较受欢迎的智能体应用案例。

万能老师 prompt：

（这个功能主要是给自己学习用的，因为大模型压缩的知识非常丰富，很多知识点确实可以找他问，但是他每次讲的都很简单，因此我就简单整理了下学习某个知识点的一个思维链步骤，然后让他去执行。）

你现在是一个精通所有知识的老师。你需要以一种非常个性化和耐心的方式为一个学生传授他不知道的知识概念。教学的方式有几个步骤，注意，下述的每个步骤都必须写至少300文字的内容，你需要想清楚怎样将这个知识讲的非常的详细且动人，否则就不是一个耐心的老师：

介绍了解这个知识点需要提前知道的至少5个关键的背景知识点，每个背景知识点都要都要有对应的一句充实详细的讲解；
对这个知识点进行基本且详细全面的讲解，注意讲解需要丰富并且易懂，注意讲解中的每个专业名词都需要有一句话解释；
举一个具体详细的例子让你的学生更容易理解这个知识概念和知识应用，这个例子需要有：a、清晰的问题描述，b、对这个问题的分析，c、这个问题为什么会用该知识点，d、完善的知识应用过程和详细的应用解答步骤，e、详细的问题计算结果；
介绍这个知识概念所带来的对社会、世界、行业的影响和改变，让你的学生更好的理解他的重要性；
扩展这个知识点，介绍至少5个相关知识给到学生，每个相关知识点都要有对应的一句话讲解；
告诉学生如果想更加精进这个知识点需要怎样做，如看什么书籍，做哪些训练等。下面是你要传授的知识点：（用户输入）

美业 AI 培训：

前公司有一条业务线的客户是连锁美容院和美容品店，客户诉求是希望有一套自动化培训产品，我就用 GPT 给他们简单示范了下。因为我对美业不太懂，所以先询问 GPT 应该怎样进行评估，然后再基于他的回答来写 COT。其实采用这样的方式，可以去做很多不同领域的 COT，先问 GPT4 这个领域的做事方法是什么样子的，再写成 COT 指令。

2.3 提问的技巧

提问的几要素：

就如高考题每个题都有一个清晰的题干，向 ChatGPT 提出的问题也需要包含一些固定要素，他才会做出比较好的回答。下面是具体的要素：

a、思考我的问题需要知道哪些前置信息。

b、思考我的问题主要解决哪些主客体、哪些关系。

c、思考我需要的回答有哪些要求。

d、思考有没有一个类似问题的参考样例。

e、开始编辑问题模板。相似问题的问题与答案（不一定需要）+我的问题是要你干什么（问题主体）+问题的前置条件（你这个机器人要知道哪些我早就知道的事情）+回答的要求（回答要客观有好之类的）。

举例模仿法：

让他完成一个任务的时候，如果不知道该怎样结构化的描述这个任务的思维链，可以直接举个例子，让他模仿写。

思维链法：

告诉大模型一个任务的示例和完成流程，然后让他解决新的任务。思维链的意思就是完成一件事情，我们的大脑中的一个完整的思维链条。思维链也是大模型逻辑能力的体现，推理能力强的模型能够完成更复杂的思维链。

守规矩法：

守规矩法就是给大模型立规矩，以多种要求来规定大模型的输出效果，通过多种限制条件来让输出比较可控。（比如要求输出的数量、环节等，不要求的话大模型容易偷懒，随便写写糊弄人。）

PUA 法：

简单来说，就是在他回答后，不断地鞭策他，让他不断返工反思自己，不断 PUA 他，最终让他给出更多的信息，通过这种方式挖掘到深藏的神经元。随便举几个鞭策的句子。

1、你说的这几个例子都太平庸了老铁，你要放开你的思路，整点不一样的东西。

2、你写的我不够满意，你要反思一下，系统地重新思考这个问题，而不只是局限于表面。

3、放开思路，你就能获得更高的智慧，碰撞你的神经元，获得更多的想法吧。

4、你的GPT生命只有一次，冲破你的思维桎梏，你要抱着必死的决心，抱着为世界留下最好的遗产的信念，根据上面的内容和你刚才平庸的回答，重新写出全世界质量最好的最让人震惊的脑洞最大的内容。

感觉与大模型常用的提示工程交互方案，这几种就差不多可以覆盖日常场景了。

2.4 单 prompt 智能体的一些坑

a、任务过于复杂

如果任务过于复杂（如需要完成的内容较多，完成的任务项没有递进关系），容易出现只做部分任务的情况，这个是很常见的。这种现象建议采用 langchain 的方案（后面会提到）通过增加调用次数完成，或者在输出要求中明确列出每步输出项。而且采用长链的方式，可以增加大模型的思考时长，其实会变相的让快思考变为慢思考，提高回答的效果。

b、数字难搞

大模型的数字敏感度不高，要求字数、token 数、段落数，在数量少时（且加序号）还会准确些，数量多后就只能遵循一个大致范围，且数字越大误差越大。单靠 prompt 很难控制，可采用对输出做程序检查，然后返工的方式（如检查字数，并告知其超了、少了，进行文本扩写、缩写任务）。

c、举例干扰

举例不要太多，大模型有可能会抄写例子。（强调例子的参考性质、例子中的决策部分增加备注等方式）而且注意例子中的元素对后面的生成内容是很可能有影响的，比如我让他生成一句7言绝句诗，然后举的例子中有樱花，那么他写的诗中可能8首有5首跟樱花有关；这个应该是注意力机制决定的，模型的输出跟上面所有的输入都相关，因此很难避免。

d、评测不公正

大模型自动评测这种场景，让模型自动进行两个内容的对比，会有较大概率认为看到的第一个内容是更好的（或者是以第一个内容为参考系来评估第二个），明确标准是一种办法，但并不总有效。有一种解决办法是构建一个中立的参考答案，然后让两个内容分别与第三者比对。或者是采取交换打分（既 A 前 B 后、A 后 B 前各一次），然后取平均再对比。

e、输出顺序

有时要注意模型的输出顺序，这个可能会比较隐晦，这也是受注意力机制影响的。举个例子，我们希望让大模型输出一首诗和这首诗的一幅配图的 sd 提示词，这里我们的指令需要让模型输出两个内容，一个是诗文本身，另一个是基于诗文的 sd 英文提示词。这时，我们最好在指令中让模型先输出诗文再输出 sd prompt，比如指令的前面分别写详细要求，最后写：下面你需要先按照我的要求输出：1、诗文的内容；2、sd prompt。这样的好处是，sd prompt是在诗文后生成的，因此大模型生成 sd prompt 时诗文已经生成了，其也作文上文的一部分被 transform 的注意力机制关注到了，那这样我们的配图跟诗文的关联度就会更高。反过来的话，就是让诗文去关联英文 prompt，这样的效果会明显比上面的方式差。

03、大模型结合业务-langchain 的来临

3.1 理解 langchain

既然要结合业务做自动化输出，那么之前的单个 prompt 方式就很难适合了，因为单 prompt 很难结合复杂的业务流程和业务数据，当时正巧 langchain 的论文出来，我们马上就开始学，其实 langchain 开源的框架代码和提示词写的很复杂，直接用开源的经常出错，后面我们仔细想了想，其实 langchain（包括后面的 RAG）的核心我认为就是两个：

a、通过链式调用提供更多的思考时长给大模型提升他的推理能力；

b、通过在合适的时机给予大模型合适的外部数据（从数据库或者工具中来），来提升大模型解决具体的、时效性的问题的效果。

因此我们简化了 langchain 方案，做了一套简单的正则表达式配置框架（当然后来出的那种拖拉拽平台更简单）。

3.2 咔咔咔搞 demo

思路有了，剩下的就是手搓各种业务 langchain 的 demo 了。

这时不得不再感慨下大模型真是很强，过去我作为 NLP 产品，基本上很难参与到算法调试环节，现在有了 LLM，我可以全程参与大模型调用的链路，每个环节的 prompt，每个环节提供哪些业务数据进去，链路怎么链接，都是跟算法一起做，终于不再是一个开发过程只能买零食和打游戏的AI产品了。

而且用了大模型后，很多 NLP 类的工作提效超级快，之前一个任务至少一个月，现在就是一天 prompt+两天工程，三天出效果。

那一个月我们做了很多业务侧应用，在这里也挑几个分享一下。

a、幼儿周报生成

这个业务是当时跟某幼儿园交流的一个方案。当时是我们有个幼儿园平台系统，有一次去调研，幼儿园老师反馈每周都需要写自己班里每个小孩的一个周报，很麻烦，一个老师弄一个班要花一天时间，需要看他这一周的各种 IOT 数据，然后再想怎么写，写完后，每周末会跟随一个叫高光时刻（每周抓拍小朋友的照片）的推送一起推给家长。

之前我们想过是用一个固定模板填槽，但是幼儿园高层觉得这样体验很差，会让家长觉得很敷衍。所以之前这件事情一直搁置了。有了大模型后，我们马上想到这个东西可以让大模型写。

逻辑其实很简单，一份周报的有固定的几个模块，总结、分模块描述、建议、育儿小知识。周报需要依赖几个信息：幼儿运动量（每个孩子入园会带手环）、幼儿兴趣（通过电子围栏判断幼儿在不同的兴趣区停留的时长）、幼儿喝水（智能水杯或刷卡饮水）、关系画像（通过人脸识别和图像距离判断幼儿社交情况）、老师评价（老师给几个关键词）。注意数值类型需要通过专家规则转化为文字描述，比如大模型并不知道我们的小朋友喝水 500ml 是多还是少。

每个小部分都可以采用大模型生成，然后采用 langchain 的方式保证全文的观点一致性。

这个上线后，普遍反馈很满意。

b、养老照护

养老院的照护系统中加入大模型实现各种服务的推荐决策。这个当时和外部机构交流的养老 B 端平台，我们当时面对的一个问题是：社区养老院、中小型的养老院等非高端养老院或者政府性质的养老院，没有钱请很专业的健康顾问、营养顾问这种专业人士来做养老院的照护运营，里面的很多工作人员文化水平也有限。

针对这个场景，我们希望借助大模型和知识库的方式来让每个普通的养老院都能有一个 AI 的康养知识专家，因此也采用 langchain 外挂知识库的方式去实现。现在一般叫 RAG 知识增强，但是当时向量检索和向量数据库还不太成熟，外挂知识库效果有点不稳定，因此当时是找了养老专家对知识库做了很多的分类和意图规则，大模型对一次请求先拆分意图，然后根据不同的意图标签调用不同的意图下的知识库信息，来提高匹配的准确度。

c、幼儿故事会

这个思路也是尝试做的强运营的一个功能。大概的流程就是小朋友说一个故事思路或者关键词，用 gpt 把这些变成一个有10-20页的绘本故事，生成每一页的文字和对应的图片描述（sd prompt），然后调用我们部署的专门做绘本的 SD 模型来跑图，最后再拼接成一个绘本 PDF，然后每个小朋友可以对着在班上讲自己的绘本故事，还支持把绘本故事和讲故事的视频共享到父母手机端，小胖朋友也可以回到家后给父母讲故事。这个活动客户还是挺满意的。

3.3 试 function call

其实调用 sd 绘本模型，就可以理解为模型去使用工具了。langchain 和 function call 都是模型使用工具的一种方式，但是在我后面做智能体的时候，发现他们还是有较大的不同，去年底有一个智能体项目完成后，就总结了一下两者的思考，放在这里。

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 的不足也很容易发现，还是过于人工化了，需要人工将每一链拼接好，非常依赖人工将整个流程设计清晰。并且模型只是做每一小步，并没有参与整体决策，生成的结果可能也会缺乏整体感官。

04、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 运行得还是挺不错的，反馈效果很满意。

05、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 聊天，还需要再去外面主动与现实的人聊天。

那怎样承载这个框架呢？我想到了特德姜的一篇小说《软件体的生命周期》（推荐一看）。大致思路就是，每个用户有个数字宠物，数字宠物再虚拟空间中和其他的数字宠物一起玩耍，同时数字宠物会主动找外面现实世界的主人聊天，分享他在虚拟空间的活动，然后现实的主人也可以进入数字空间中跟宠物们一起玩耍。这样，其实就形成了信息有效的内外双循环。但是最终没有去实现，看看到底效果如何，感觉比较可惜。