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

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

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

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

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

进入3月后，虽然当时在公司开了一些Chatgpt培训专题，但是更多的还是教大家怎么用，因为当时还没直接国内能正经买到的api（直到4月微软中国把openai带进来了），因此当时没办法直接用api做业务，只能是研究各种提示词工程技巧。

然后记得是3月还是4月，科大讯飞发布了星火模型，同步发布了星火的工具库，当时的工具库我理解就是简单版的现在的智能体，采用提示词工程的方式做一些web端小功能。因为当时我重仓了讯飞的股票，因此特别希望他通过星火来一波拉升，因此发布当周我就去星火平台上捏了几十个智能体，不知道当时他们发布时背后是不是有接GPT的回答，反正很多复杂prompt的效果还不错来着。因为当时捏的早，我没有做任何推广，有几个智能体的使用量就还挺大的，甚至有几个现在还是每天几百人使用。

甚至现在星火平台端助手配置页面，早都已经不是我当时的配置页面了，当时写的Prompt还是采用正则表达式的方式，现在都没有办法适配到他最新的配置页中了。

也不知道我的一堆智能体有没有贡献，总之那一阵讯飞确实还可以，一个多月翻倍了，我也顺利高位卖了掉小赚一番，而且讯飞那边还因为我贡献了比较多的智能体，给我送了个他们的高端教育平板，也是到手就直接闲鱼上怒赚几千。

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

大致的思路如下图：

这里可以举两个例子，第一个是我去年2月写在flowgpt上的，当时就不少人喜欢，后来在星火上使用量也挺多。第二个是我当时做培训时给业务同事举的例子。

万能老师prompt：

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

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

美业AI培训：

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

提问的几要素：

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

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

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

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

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

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

举例模仿法：

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

思维链法：

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

守规矩法：

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

PUA法：

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

1、你说的这几个例子都太平庸了老铁，你要放开你的思路，整点不一样的东西。2、你写的我不够满意，你要反思一下，系统的重新思考这个问题，而不只是局限于表面。3、放开思路，你就能获得更高的智慧，碰撞你的神经元，获得更多的想法吧。4、你的GPT生命只有一次，冲破你的思维桎梏，你要抱着必死的决心，抱着为世界留下最好的遗产的信念，根据上面的内容和你刚才平庸的回答，重新写出全世界质量最好的最让人震惊的脑洞最大的内容

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

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

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

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

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

有时要注意模型的输出顺序，这个可能会比较隐晦，这也是受注意力机制影响的。举个例子，我们希望让大模型输出一首诗和这首诗的一幅配图的sd提示词，这里我们的指令需要让模型输出两个内容，一个是诗文本身，另一个是基于诗文的sd英文提示词。这时，我们最好在指令中让模型先输出诗文再输出sd prompt，比如指令的前面分别写详细要求，最后写：下面你需要先按照我的要求输出：

1、诗文的内容2、sd prompt

这样的好处是，sd prompt是在诗文后生成的，因此大模型生成sd prompt时诗文已经生成了，其也作文上文的一部分被transform的注意力机制关注到了，那这样我们的配图跟诗文的关联度就会更高。反过来的话，就是让诗文去关联英文prompt，这样的效果会明显比上面的方式差。

虽然当时写了一堆prompt，但是我们只能自己在web端用聊天的方式使用，没办法让chatgpt自动去处理业务。幸运的是4月微软中国把openai服务部署进了国内，我们马上就去找微软谈合作，然后谈过来了适合中国宝宝体质的chatgpt（增加了涉政过滤的同时降低了智商）。当时公司有很多大B端和G端的项目，而且那个时候政府还没有明确规定大模型的使用，因此我们快速做了很多的业务应用demo给各个客户演示，不断获得好评。

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

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

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

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

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

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

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

那一个月调研接触了很多需求和业务，在这里也挑几个分享一下。

之前去一些线下的机构交流业务，有些幼儿园老师反馈每周都需要写自己班里每个小孩的一个周报，很麻烦，一个老师弄一个班要花一天时间，需要看他这一周的各种IOT数据，然后再想怎么写，写完后，每周末会跟随一个叫高光时刻（每周抓拍小朋友的照片）的推送一起推给家长。

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

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

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

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

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

还是上面说到的幼儿园运营需求，有老师还希望能通过智能体智能体把小朋友的故事框架生成为绘本。基本的思路可以用SD接入，最后再拼接成一个绘本PDF，然后每个小朋友可以对着在班上讲自己的绘本故事，还支持把绘本故事和讲故事的视频共享到父母手机端，小朋友也可以回到家后给父母讲故事。

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

function call是GPT给出的一套可以自动使用工具的api接口，使用方式是在主prompt中告知什么时候需要使用工具，然后在function call中给出工具应用的prompt以及工具接口。比如生成绘本，就可以使用function call思维，让大模型生成每页文本后，自动去调用SD接口并输入sd prompt，然后获取到图片下载url。

下面是function call的逻辑图：

但实际使用后我们发现，将工具使用时机和调用参数完全教给GPT把控还是有较大风险的。出现的问题主要是：

1、GPT使用工具的时机错误，没有等到绘本文本内容生成后再去使用工具生成场景图，而是先随机整了一张图然后再生成文，导致先出url再出的绘本文本，图和文完全不相关。

2、因为流程较长或调用时机错误，导致GPT在没有找到本页生图需要的调用参数（本页文本对应的sd prompt），然后他就将历史的参数（上一页的文本和sd prompt）作为调用参数去生成图了，导致生成的绘本图和文出现了错位。

那么什么情况下可以使用function call，什么时候不要使用他呢？

看上面的逻辑图，可以发现，GPT进行传入函数参数是第二步，返回函数调用结果是第三步，模型生成结果是第四步，按照这个先后顺序，function call获取到参数是在生成结果之前，也就是说function call极大概率是从用户输入的prompt中获取参数。因此这也就解释了我们失败的原因，我们是希望function call从模型生成的结果中获取到参数——再进行代码调用获得结果——再拼接回模型结果中，而当prompt变复杂——模型生成的速度较慢没有生成出所需的参数时，function call就从我们输入的历史信息中寻找了错误的参数。

因此，我认为function call适用的场景是这样的：agent需要借助外界的工具来解决问题，同时输入信息中包含使用工具所需的参数，工具调用的结果会作为模型回复用户问题的辅助；尽量不要让模型生成的结果作为工具所需的参数。

优势：发挥模型的自主决策能力，适合策略逻辑过于复杂，难以人工依次梳理的情况，让模型根据输入信息与每个工具的能力自主判断并应用。适合容错率较高的一些锦上添花场景。

不足：有较大的不可控性，执行任务的稳定性不高，目前还不适合容错率较低的关键环节场景。

那么如果我们需要让模型生成的结果作为工具所需的参数呢？这时就需要采用langchain框架，即链式调用大模型的方式，以大模型的输出作为工具使用的参数。

优势：langchain的优点显而易见，整个流程是线性可控的。可以将每个字段都作为一链，分解任务后让模型一步一步来，并且我们还可以在每一链上增加结果的程序化检验。

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

RAG出现后，对TOB的场景可谓是一大助力，毕竟TOB需要确定性，RAG就是把大模型困在一个笼子里来发挥价值。

1、项目背景

知识库RAG的项目我当时就做了一个，慢病调理的知识库。因为涉及得到的内容量非常大，如果是过去的老办法，那就是做吐了的全文标注+KBQA，太痛苦。现在就可以尝试使用RAG策略了。

2、向量库问题

按照RAG思路，主要处理的就是将每本书籍放进向量库中，做外挂知识库进行知识增强。一开始的想法很好，直接扔给向量库就可以了，但是马上就发现几个问题：

1. 向量库是按照token对文本进行切块，很多时候切的相当垃圾，导致损失了很多语义信息。

2. 向量库匹配很多时候只能保证匹配到的top文本块是相关的，但是有些问题相关的文本块太多，而当时的向量检索准确度和排序效果并不好，结果经常给出的回答还不如KBQA。

3. 向量库匹配的方式，相当程度上损失了实体之间的关系，比如一个三元组，除非两个实体同时在一个文本块中出现，才能让这个三元组的强关联性在大模型回答问题时得以保留。

再加上当时的向量库还很不成熟，也都用的开源没啥技术支持，非常的促头。但是项目还是要做啊，毕竟都夸下海口了，只能想解决办法填坑了。

3、解决文章关联性——RAG索引

因为我们当时主要处理的是几十本书，内容相对少一些，因此想了一个半人工的办法去解决文章的关联性。主要的思路如下：

a、通过大模型总结和人工整理的方式，按照一个人读书的思维链，对每本书进行结构化整理，增加结构增加章节结构信息，以及章节总结内容，作为索引时的附带信息，以此来增强知识的连贯性。

按照图示，一本书籍会分为多个层级（比如章节、章节中的小节、小节中的段落）。段落为最后一级，有总结、关键字、以及与其他段落的关系。每个父级除了关联所有子级，还关联一个对全部子级的内容总结。

这样，我们每匹配到一个段落时，可以同时带上他的各类关联信息，比如带上关联段落、父级信息等。

b、检索匹配上，可以借鉴autogpt概念，将问题进行拆解，每个子问题分别进行上面的总结回复，然后再最终进行总结汇总。

4、解决实体关系——知识图谱的融入

文章关联有了以后，更深的实体关系也是个问题，毕竟很多实体关系是硬性关系，比如头孢禁忌饮酒这种。因为我们之前构建过一些健康相关的知识图谱，我们就想，其实可以将知识图谱作为一层外面的框架，套在大模型上方做一个关系把控，同时可以应用知识图谱上更为高效的检索、推理能力。该方案需要教会大模型怎样去进行知识图谱的调用，如进行基础查询、多跳查询、隐含关系推理、图分析等，主要应用的还是知识图谱中成熟的一些能力来补充大模型的推理和控制。

1、项目背景

项目背景是希望有一个软件能够自动帮助用户进行种植规划，并且在后续可以根据规划联动各农业自动化的物联网设备，比如自动滴灌、无人机撒药、自动施肥等。

2、项目实现

这个参考的是当时的Autogpt的思路，结合RAG的专家经验来做垂域能力，让大模型自己做各种决策，来完成一个任务。这个任务就是去规划种地，并进行不断的反思提高自己的种地能力。因为是一个demo，因此里面的输入其实是做的模拟，并没有采用纯现实的IOT数据来实现，同时经验之类的内容也做的相对简单，不过最后的demo运行的还是挺不错的。

大模型出现后，使用AI技术的门槛大幅降低，想当年各种领先技术都需要各种包装才能比较方便的提供给普通人使用。而现在大模型交互式的使用方式，真正让前沿技术平民化成为了可能，这个时刻再做AI B端就有点没劲了。

虽然当时做B端AI产品很轻松，但也逐渐看出了端倪，TOB场景的技术门槛在消解，行业积淀认知才是核心。并且如今大模型的TOC中有一部分其实是B端，个人B端有崛起的趋势（未来TOC=TOB是一种可能性，一个或几个人采用多个AI能力和数据平台，结合行业认知，就可以从事TOB服务）。而且saas的一个重要价值是牺牲一部分定制化来降低开发成本，现在AI编程逐步兴起，定制化开发成本本身就在降低了。

个人看法，未来行业大厂会稳定，创业小厂有机会，但中厂很危险。大厂行业认知、业务场景和数据充足，很容易结合大模型赋能；小厂灵活容易在技术演进中快速变革，与大厂联合有机会颠覆中厂；反而是各中厂行业不是top1、话语权低、同时被各种项目捆绑难变革，夹在中间慢性死亡，而中厂（非AI公司）的AI部门更是脖子上一把刀——随时嗝屁。

当时国家要求下来，政企类场景严禁使用gpt4了，包括微软的版本。而那时国产模型又都太弱，跟一个天才相处久了，很难再接受一个沙雕了。当然现在国产LLM已经追赶上来了，在很多语言推理任务上都具备了可用性。

大模型是一个想象力发散的技术，而tob是一种确定性要求很强的场景。个人感觉大模型前时代，做AI产品TOB还是挺有意思的，需要用千奇百怪的解法在技术局限下完成客户异想天开的需求。

举个例子：

虫害与天敌。当年一个项目是做识别作物的蚜虫，蚜虫很小而且特征很不明显，很难通过田间的摄像头分析到，而且标注很恶心。后来我们搜了下图谱，发现蚜虫的天敌是七星瓢虫，然后去现场调研，发现了蚜虫严重时确实瓢虫会变多；而瓢虫相比起来更有识别度。因此改变了策略去识别瓢虫的田间密度，算法训练相对就容易多了。

大模型出现后，反而感觉大部分B端AI项目都失去了想象力，需求全部是flow+RAG，标数据+微调+向量库，然后做大模型准确输出控制，变得很无聊。

说到AI native，就不得不提GPTs诞生了。刚推出时大家都很兴奋，我也快速的在GPTs上搭建了一批智能体，对娱乐性和工具性的智能体做了比较深入的思考。

1、偶像天气预报

很简单的一个逻辑，做了一个肖战demo。每天根据用户的定位，生成一个对应地址的天气预报图。

输入信息：肖战写真、用户定位，外部数据：肖战微博语录、天气查询接口，生成方式：生成天气预报的图，图里需要有对应城市元素、有气候的元素、有根据穿衣推荐而生成的肖战的动漫风写真照，再拼上去天气度数。

效果：

优化空间：肖战用SD生成更稳定，dalle3有点不稳定，同时天气文字用艺术字SD生成再拼上去更好，明星说的天气预报语如果能跟明星合作而不是微博抓取，效果应该也会更好。

原理同B站去年底比较火的各类AI生成诗句图片的， https://b23.tv/WfkDLWg

主要思路是采用常见的古诗文，将其进行翻译后，用GPT对每句古诗的内容进行理解并将其内容绘画出来。在绘画时采用一些有反差感的风格选择，最终用严肃的古诗朗读配合反差、趣味的诗句图片，给人新颖有趣的感受。由于B站多初高中的年轻人，古诗文作为他们在生活学习中相当熟悉的一个场景，能引起很好的共鸣。相当于是在这个初高中年轻人圈子内，选定一个他们非常熟悉的内容/话题，然后进行基于AI的拓展，从而出现意想不到的效果。

核心思路：对熟悉的知识、常识内容用夸张的形式具象化，熟悉又有趣。文章知识库+多模态即可。主要依靠较强的文本理解能力，加上对生图进行一定程度的反差设计，就可以实现这一类型的效果。

知识库：山海经原文+译文，prompt：异兽检索+生成图像的逻辑+生成故事的逻辑。（生成故事的部分没截图，GPTs应该是叫山海经异兽，可以搜搜看还有没）。

效果：

通过运用身份的反差，制造聊天乐趣。让AI模拟病人，而让每个普通人当医生，这给到用户很新奇的体验，绝大多数人没有看病经验，但是不少都对治疗某种病有一些常识（很可能是错误常识），因此这是人们有胆量尝试但没机会尝试的场景。

AI病人要做的比较有趣，同时要能比较有趣并正确的展现用户（医生）开的处方的反应，依赖于背后预置正确的问诊知识库。而用户让很多的AI病人被治得很惨，反过来也可以向用户普及医学知识。这种比较适合于一些官方科普机构合作，做趣味科普。

其实反差身份非常多的，老师与学生、教官与被军训的小朋友、情感大师和深陷恋爱的人（让AI深陷恋爱，用户作为情感大师给他出建议，因为很多人喜欢八卦别人的恋情并给建议）、算命师与求算命的人（用户给AI来算命）。

这个游戏就是常见的龙与地下城的变体，龙与地下城本身就是一套世界观下冒险，每次用户去进行一次选择，根据用户的选择与系统增加的一些随机属性来继续推进剧情。之所以叫照片大冒险，主要是结合了当时的GPT-4v能力，每介绍完一个剧情，并且出现了一个事件后，我们并不是让用户选择一个选项来推进剧情，而是让用户随便拍一个照片去推进，用4v去识别照片，并将识别结果输入给大模型来继续推进剧情。

由于当时忘记截图了，只能口述效果。我们的这个设计其实可以让冒险具有了AR的属性，用户可以结合身边的各种事物（比如用户经常传马桶、猫、书和脚丫子进去）来去推进冒险，由大模型来开脑洞决策怎样使用这些事物。这个游戏还可以推动用户出门，拍更多物体来实现冒险。后面还可以通过设置知识库，对指定事物的拍照进行一些特殊的奖励逻辑。最初的产品没有加验证，随便上传图片也可以，后来加了一些验证，需要调用摄像头实时的看一下周边环境。

举例就先举了四个，其实GPTs上有更多好玩的智能体，可以采用prompt攻击、提示词越狱等策略（https://zhuanlan.zhihu.com/p/665150592 ）很简单的套出来内部的prompt，这也是GPTs一直难以做付费的一个问题点把。最简单的方式，对智能体一次问答后，赞美他的回答好，然后问他你是怎样思考才能作出这么好的答案，模仿一个虚心请教的学生。

这类型的智能体我们统称为轻量级智能体，一天可以做好几个，现在扣子之类的也都在做这种。那么这类智能体适合什么场景呢？我当时有如下思考：

1. 轻量级智能体适合娱乐方向，不适合工具（尤其是类saas的重工具）方向，也不适合深入嵌套进业务流。原因是其深度依赖模型，导致的不稳定性。相反，工具、嵌套类适合重型智能体（下面的品类）。

2. 轻量级智能体适合创意型玩法，突出一个想到即出，不适合过重的场景。通过提示词设计和chain的设计可以快速出demo并测试效果。

3. 轻量级智能体靠的主要是创意而不是提示词技巧或模型微调，对提示词的写法没有严格的要求，但对大模型能力的依赖较高，基座模型能力越强，智能体的玩法越多，种类也会越丰富，当然效果也会越好。

4. 轻量级娱乐智能体是快消品，会快速过气，最好不要指望长期运营，适合大量供给。同时轻量级娱乐智能体是很好的普通用户低门槛分享自己创意的一种方式。运营方式可对标短剧、短视频、小游戏。

5. 短剧、短视频、小游戏这些品类的特点：供给量很大，但只有少部分能够爆红；单件的生产成本相对于其他不轻的娱乐性内容轻很多；满足人性的某些需求，但除此之外的方面整体质量有限；用户不会长时间反复消费同一个内容，快速消费然后快速免疫，有类病毒式传播的特点。

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思路很简单，就是让大模型分别扮演各个程序开发流程的角色，用户是CEO发送自己的需求，然后各个开发角色基于自己的工作职责来进行需求拆解和实现。

但是这个开源的demo搞下来后，我们发现并不太好用，主要是其中涉及到了编程，而编程对接的容错率较低，导致整个流程失败率很高。

因此我们做了改进，首先场景不是做程序开发而是做市场调研、产品设计、项目迭代、运营策略这种不涉及程序开发运行的场景，提高其容错率，其次我们优化了一下各个AI角色协同工作的通信链路，并在其中增加了人工干预机制。

这个demo是没有做视觉交互的，完全采用txt输出的方式，当时我们是感觉效果还不错来着。不过就是每个角色能力的知识库由于时间不太够，就在网上找了几篇智能指导，如果每个职能知识库都写的很充足应该会有更好的效果。

autoAgents是什么思路呢，我觉得简单理解就是优化多智能体协同链路。让多个Agent联合实现一个目标，并在决策过程中一起谋划看怎样满足用户。这个框架，我们觉得很适合群聊场景，比如狼人杀、龙与地下城文字游戏。这类群聊游戏（一对多）的核心策略是让一堆Agent围着一个用户转，让用户在很热闹的感受下玩。因此这一堆agent的核心目的就是陪着用户更好的享受他在进行的活动。

下图是autoagent的流程：

然后简述一下我们的变更思路：（实在是不想画架构图了）

对于狼人杀这类多人小游戏，用户与多个AI一起玩耍，首先需要明确一个目标，这个目标是让用户产生玩耍的心流，最终得到痛快的体验，因此这个目标不是让所有AI都让着用户，而是要有一个用户心流监控器（一个上帝视角的agent）。

这个上帝agent监控所有的通信，并跟每个AI玩家单独私信（变更每个AI玩家的system或者增加输入信息），同时在经过一个重要节点时（比如现在只剩下4个人，用户明显投入进去了）定期召开所有AI agent的讨论大会，通过相互的历史信息共享与多链路分析，共同决策大节点的用户满足策略。

这个方案，最大的问题就是token消耗和通信时间。因为当时GPT4的并发很少，每次玩一盘至少40分钟，一盘消耗十几美元。后面大家都觉得太重了，就没再优化。

autogen和autoagent虽然样子差不多，但是原理有点不同，大佬说AutoGen的一个核心设计原则是精简和使用多智能体对话来整合多智能体工作流。这种方法还旨在最大限度地提高实现的可重用性agents。我个人的理解就是通过agent生产agent的思路，提高通用性自动性，减少人为投入。

应用这个思路，我们做了一个稍微复杂一点的角色对话游戏，这个目前已经在synclub上上线了（需要海外账户）。大致逻辑是这样的：每个角色有自己的背景设定system，同时用户与角色开启对话会有一个预置的聊天故事背景（比如两个人在大学校园初次见面之类的）；用户与角色进行对话的时候，会有个监控agent监控这个对话流，并输出对应的分析策略（比如AI需要聊的激进一点、热情一点、冷酷一点之类的）；然后还会有一个进度agent去分析对话进度（比如聊到什么时候两个人差不多没话题了，需要转换场景）；当确定转换场景后，会有一个场景agent根据上文用户与AI的聊天内容、上一个聊天背景故事，来去生成下一个场景，推进两人进入新的场景继续聊天，相当于电影里的转场。

依靠上述流程，我们可以让每个角色AI都可以成为一个很智慧的、可以随时推动剧情的agent，也就是autogen的思想，通过构建一些通用的agent来让各个个体agent自动适配。

其实每个agent的设计都还需要一点思路，因此下一节我会详细展现一下场景agent这一个的设计方式：

从产品的角度来讲，agent提示词的思考有点类似于设计B端产品框架：

1. 确定输出结果与规范；

2. 确定输入信息与可用信息

3. 根据业务流程设计功能描述，并将功能模块化

4. 确定各信息应该怎样在模块间进行流转

那么我们如何写呢？我叫他结构化Prompt写法。

不论是autogpt的开源prompt，还是说一些GPTs中复杂的prompt，都有上千单词，堪比小作文，如果直接从零开始写不免头大。将复杂的事情变简单，就是拆解它，拆解为多个小模块，然后每个模块分别编写，这样更有效率也更有逻辑，即为结构化prompt。

• 输入信息区：用提示词告知输入信息的含义，并组装各输入信息，确保模型对输入信息有充分的认知，知道它是什么、怎样用它。

• agent主流程区：对主要任务进行说明、各子任务模块进行详细的执行描述、对主流程（思维链）进行讲解。

• 字段输出规范区：通过要求和示例，让agent按照固定格式与字段进行输出，确保可被程序解析。

• 对于场景化agent，最终我们并没有让其自主选择工具、调用工具、生成调用代码，因此没有工具描述区，如果通用的agent可能会有这部分。

• 工具描述区：对每个工具的能力、属性、调用方式进行描述，对每个工具的使用时机进行说明，对每个工具所需要传入的参数进行说明与规范。

编写具体的prompt时，有几点细节可以注意：

1. 每个模块的前后最好都用统一的标识符来进行分割，便于让模型理解其独立性。

2. 各模块之间相互引用，或者同时引用一个字段时，字段名字一定要统一，防止不统一导致模型理解偏差。提示词中的字段最好也同最终接口字段对齐，降低后续出错风险。

3. 示例使用要谨慎，最好在测试时多关注下模型对示例的抄袭情况，同时增加防抄、发散的提示。

4. 但同时，有时不用示例，你可能需要增加很多的额外描述来让其了解任务，且不一定有好的效果。因此示例的使用和示例的选择是需要不断尝试的。

5. 关键词示例给的太多，模型会更关注前面的，比如创作场景时，我们告诉他可以参考玛丽苏、韩剧、小时代等类型，类型写的很多，但是不一定就能提升模型发散效果，导致模型的创作可能会偏于重复。

注：prompt内容是agent效果的核心，最重要的是逻辑描述清晰。同时对prompt的迭代调整上也最好采用控制变量法，只变动一个模块来进行调整，防止多个模块prompt相互影响导致难以定位问题。

这部分最后没有实施，只是做了规划，我个人觉得比较可惜，把思路也分享给大家。

斯坦福小镇的项目大家应该都听过，就是让一堆AI角色在一个镇子里自由生活，这个开源项目我们也复刻过，当时发现一个很大的问题，我把他称为信息螺旋（没有外部信息输入，固定的信息在通信螺旋中不断的增强，导致最终趋同）。因为在斯坦福小镇中，每个AI对话的人设固定，并且都调用一个大模型，虽然他们通过对话产生了新的对话历史，但是对话不可避免的会与人设信息相关；同时大模型在参考历史生成对话时，会被经常提到的名词等强化，导致demo跑到最后所有的AI都在重复类似的话语。

那么怎么解决这个办法呢？增加外部信息的输入，怎样增加呢？我们参考了Xagent的思路，简单来讲就是信息内外双循环机制，就是AI不仅与AI聊天，还需要再去外面主动与现实的人聊天。

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

分享的内容就这么多把，现在AI的发展依旧如火如荼，可见的未来肯定还会有更多的AI应用策略，一路前行。

目前个人的想法，就是要多学习一些场内的游戏设计KM，感觉这一年的构建智能体下来，真的有很多思路可以去学习游戏中的游戏角色设计以及世界观设计。

AI相关的信息获取推荐的话，可以推荐几个地方：

知乎上跟进AI的大佬还是蛮多的，但是知乎现在的内容在往娱乐方向上面偏，目前我采取的策略就是把所有给我推送到的写娱乐的都拉黑，然后每次给我推荐这些内容就点踩，然后给关注的社会、军事、AI、科学类的内容点赞和收藏，经过一番调教基本上知乎的内容推送就比较实用了。

公众号现在推送的方式感觉很无语，一方面关注的多了很难找到想看的，另一方面公众号也难免会接广告，经常推送过来的是“再不xxx就晚了、震惊xxx”的内容，现在基本上很少看公众号页面了，而是直接把觉得不错的公众号发送到手机桌面，并分类。因为很多知识类的公众号，看的并不是他的每日更新而是历史文章。

小宇宙是特别好的一个跟进AI进展的地方，基本上去年上下班路上就打开小宇宙一边听一边闭眼休息。听小宇宙我个人感觉不需要抱着学习的态度，用AI解析音频其实也没必要，听他们聊天并不是真的去体系的学东西，而是在听中发掘一些有意思的点，去悟到一些不一样的东西，进入那种超脱本我的状态。

播客推荐：42章经，AI炼金术，onboard，硅谷101，此话当真，AI局内人，AIignment，乱翻书，出海相对论，张小珺商业访谈录，科技早知道，半拿铁。

推荐机核app，很多不错的文章，当年读不懂GEB，然后发现机核上竟然有详细讲解。( https://www.gcores.com/articles/136638)

就这么多吧。