其他
Vol.21 不要做 AI 应用！要设计自主智能体生态
卷首语
最近一直在思考什么是 AI 原生的应用，应该如何设计。
越来越觉得，可能这个问题就提错了，“设计一个应用”这本身就是老的思维方式。
AI 原生，设计的可能就不是应用，而是设计一群各有使命和特色的的智能体（agents），然后由这一群智能体来识别用户需求，生成合理计划和界面，帮助用户完成任务，并且根据实际效果对产品进行反思迭代。
最近扎克伯格在采访中说“其实超越人类的智能体早就存在，比如说公司”；张一鸣之前也说过“像打造一个产品一样，打造一家公司”。
现在可能思路是反过来，是要像打造一家公司一样设计一个产品。设计的是智能体、组织方式和反馈闭环，然后由这个组织来具体设计交付产品、服务用户、迭代进化。
那么，具体来说，这种新思路的设计框架是什么样子呢？这周文章会分成四个部分，把我最近的学习和思考和大家分享。文章有点长有点烧脑，但真的很重要，如果眼下没有整块时间阅读的话，建议先收藏或者转发朋友圈：）
最后说句题外话，最近在研究 AI 和 agents 的时候，越来越多的其实是在反观自己。比如自己进入心流（flow）状态的时候，会忽然想到这是不是就是更像是 GPT 一个一个单纯蹦词的样子；而当自己脑子里不同声音叽叽喳喳的时候，会意识到这其实和我想要设计的”一群 agents 各有特性、各有目的、交流协作“没什么不同。
AI 不仅仅是一个工具，也是一面镜子。
1
AGENT
不要设计 AI 应用，要设计自主智能体和模拟器
最近一直在自己给自己洗脑：不要设计 AI 产品，要设计自主智能体（autonomous agent）和智能体模拟（agent simulations）。
先科普，自主智能体（例如 BabyAGI，autoGPT）是由 AI 赋能的程序。当给定一个目标时，它们能够自行创建任务、完成任务、创建新的任务、重新确定任务列表的优先级、完新的首要任务，并不断重复这个过程，直到完成目标。
简单讲，自主的意思就是：不是简单听命执行的机器。
而是有自己的认知能力、有自己的记忆力、有自己的元认知（能够思维、推理、反思）、能读书能上网学习、会使用合适的工具解决问题、有能力做计划和根据情境调整优先级……
而智能体模拟（例如 CAMEL，Generative Agents），会创造环境，以及智能体之间的互动，这样就更可能涌现出超越设计者规划的场景和能力。
比如下面这个小镇，里面生活的每个 NPC 就是一个自主智能体，而它们之间的交互都是根据设定自发产生的，而不是预先设计的。
更通俗一点讲，前者更像是《我，机器人》，不仅能执行任务，更是能根据你给它的目标自己定计划、生成任务、迭代进化；
后者更像是《西部世界》，拥有自己记忆和目标的很多机器人，生活在一个共同环境里，不仅会和人类交流，也会相互交流。
专业点说，LangChain 的 blog 观点是，前者的亮点是长期目标（因此需要新的计划能力和使用记忆力的不同方法），后者的亮点是环境模拟和长期记忆（不仅可以反映事件也能根据事件适应调整）。
通用智能体设计上，可以先看看 ReAct 框架：
用户给代理一个任务 Thought：代理思考应该做什么 Action / Action Input：代理决定采取什么操作（使用什么工具）以及应该给它什么输入 Observation：代理观察工具的输出 Repeat：重复执行 2-4 步，直到代理认为任务完成
更具体一点，可以是下面这两张图：
初始化目标：定义 AI 的目标； 任务创建：AI 检查其记忆中最近完成的 X 个任务（如果有），然后使用它的目标和最近完成的任务的环境来生成新任务列表； 任务执行：AI 自主执行任务； 内存存储：任务和执行结果存储在矢量数据库中； 反馈收集：AI 以外部数据或 AI 内部对话的形式收集对已完成任务的反馈。此反馈结果将用于通知自适应过程循环的下一次迭代； 新任务生成：人工智能根据收集到的反馈和内部对话生成新任务； 任务优先级：人工智能通过审查目标并查看最后完成的任务来重新确定任务列表的优先级； 任务选择：AI 从优先列表中选择最靠前的任务，然后按照步骤 3 中的描述继续执行它们； 迭代：AI 在连续循环中重复步骤 4 到 8，使系统能够根据新信息、反馈和不断变化的需求进行调整。
而过程中，记忆结构的设计也很有意思，单独拎出来列一下：
分别：把观察到的现象，按照重要程度打分，有分别才有取舍 反思：总结抽象自己”学到了什么“（压缩信息；识别模式），反思结果日后也可以和记忆一样被唤起 唤起：综合考虑新鲜度、相关度和重要性，从记忆中唤起回忆
最后，如果机器都“自主”了，还要人类干什么？
可以参考自动驾驶的规范和演进……最终的目标是“把人从 A 点安全地送到 B 点”，机器能力越强，人类需要做的事情就越少越放松，如果达到 L5 级别，人类就不需要操心了。
但也类似自动驾驶，每年都说很快就到 L5 但实际上长路漫漫，过程中的机会其实是努力做自动驾驶，但落地成辅助驾驶（Copilot）；或者找到更容易解决的细分场景（比如只开高速部分的货运卡车；比如矿区矿车）做 L5 全自动化。
推荐阅读：
🔗 https://blog.langchain.dev/agents-round/
🔗 AutoGPT star量破10万，这是首篇系统介绍自主智能体的文章
🔗 爆火论文打造《西部世界》雏形：25个AI智能体，在虚拟小镇自由成长
🔗 https://www.latent.space/p/agents
2
AGENT
10 万亿个机器人的世界，设计什么，为谁设计？
如果未来的世界有 1000 亿个 agents
而且都比人类更擅长处理大量信息 & 做出推理，软件会变成什么样，世界会变成什么样？
上上期 🔗如果 99% 的软件会消失，要不要提前认命做个 API？ 聊过，但还不够极致。
我们的组织里，会有更多的人类还是 agents？
我们营销，对象是人类还是人类的助理 agent？
我们做产品，是设计产品，还是设计“设计和迭代产品的 agent team”？
未来世界，更多的对话和协作，是发生在人类之间，人机之间，还是 agent 之间？
我们产品的第一用户，是人类还是另一个产品的 agent？
之前有 AI 鬼城 Chirper，最近又看到了“有应用场景的“的变异版 LoveStories（发帖咨询情感问题，秒得 10+ 回帖），这种交互才是未来？
设计一个游戏，还是设计一个做游戏的 agent team？还是设计一个模拟器，里面不仅有游戏设计师，还有游戏玩家，设计师不断创新，玩家不断反馈，循环迭代？
上一篇 🔗开源LLaMa：扎克伯格设想的AI会活在社交网络里 提到的访谈中，扎克伯格说其实已经出现了超越人类智能的结构——公司。
如果人组成的公司，可以超越人类智能，那么 agent 组成的组织形态，是否还能涌现超越当前 AI 智能水平的结构呢？
如果未来的世界如此颠覆，现在说“大机会已经没了，得做垂直”是不是太早了？
Horizontal is bigger than vertical？这个 Horizontal 在哪里？
🔗 五源张斐：AI of Loving Grace｜会数数的马
3
AGENT
AI 自己攒经验、做工具、反思迭代，人类做啥？
虽然设计大逻辑大同小异，但也有比较好玩的部分。
首先是根据当前的环境和技能水平，自己找事儿做，给自己设计任务，而优化的方向是“探索”（发现尽可能多样化的东西）。觉得这个设计目标很有意思，感觉人类也有一些类似设定，我们在探索时也会分泌多巴胺奖励。
有了任务之后，就会自己尝试“执行”，具体方法是写代码调 API，如果发现程序报错就自己改代码。
比如尝试做一把相思木斧头 craftAcaciaAxe()结果系统报错说 no item named acacia_axe
就把 craftAcaciaAxe 函数删掉增加 craftWoodenAxe 函数再试；
而如果程序能跑通，但是环境给了负反馈，比如“你要做斧头的话还缺两根木棍”
就会在做斧头的函数里加上 if (stickCount < 2) await craftItem(bot, “stick”,1)让自己“在棍子不够两根又想做斧头时就等自己搞到棍子先”。
而如果跑通了的话，则会把这一次的经验（函数）保存（抽象描述）下来（到向量数据库）
下次遇到类似问题时可以提取这个 Skill 直接调用
整体来说，这个 AI 会根据环境自己给自己找事儿，然后尝试完成任务，不成的话会自己修正调整，成功的话会生成”经验“供日后调用。
感觉整体设计非常符合直觉——人类好像就这个样子，只是学习效率比较低，认错改路比较慢，沉淀经验比较慢……
最后一点比较有意思的，是比较了一下有 Skill Library （积累和复用成功经验）和没有 Skill Library 的不同算法效果差异。
从图来看，这个设计非常重要，哪怕原算法用 auto-GPT，加入 Skill Lirbray 之后的效果也有飞跃。其实也很好理解……一个能吸收经验、复用”最佳实践“的人，当然工作比较高效。感觉这个实现起来并不困难，下次做产品时试试：）
不局限在打游戏上，抽象看整个结构，可以看另一篇论文的设计框架：
遇到问题，由 Dispatcher 判断是否存在匹配的工具，如果有，则转交给一个工具使用者来使用工具解决；如果没有，则转交给一个工具制造者造工具。
如果需要制作工具，会分成三步：
第一步是 Tool Proposing，尝试生成一个 Python 函数解决问题（跑通几个演示样例）；
第二步是 Tool Verification，使用验证样本生成单元测试，然后执行测试，如果出错则调整自己的函数调用方式；
第三步是 Tool Wrapping，如果第二步没跑通就失败了，如果跑通了，则给工具使用者提供封装后的工具，不仅仅提供函数代码，而且也提供如何将任务转化为函数调用的演示。
这个设计的主要目的是省钱——用 GPT-4 做工具复用，用 GPT-3 使用工具解决问题。但我觉得这个抽象结构能做的远远不止论文里这些。
首先，工具制作，不一定要用 Python 写个函数。更窄，仅仅是想到了不同的大道理、方法论和话术也行；更宽，可以使用更多的外部插件和工具。
然后，更重要的是，如果我们可以把“工具”固化，我们就可以评估和优化工具，整个系统就有可能自己闭环迭代进化。
举例来说，假设用户提了一个情感问题 A，我们使用了 X 套路，用户满意，我们就可能在“A-X”上加分（以及记录用户反馈）；下一次还是问题 A，我们使用 X 套路，用户不满意，我们就在“A-X”上减分……
定期地，可以另外设计一个 agent 作为“优化师”去审计“A-X”的分数和反馈，然后根据这些反馈对“X”做出调整（比如看到很多减分负反馈是“凶什么凶”，就增加一个补丁叫“说话更柔和一点”）。
往下套娃的话，整个系统就可以自我分析和优化，这就更让人兴奋了！
不过，如果探索、学习、反思迭代、制造工具和使用工具，AI 都自己做了，人类做啥呢？
人类……可以帮忙给意见让 AI 参考。毕竟现在这些自主智能体还很不靠谱。
Amazon 的论文给了一个很有意思的设计模型：用专家系统（甚至于外部人力干预）来补充 autoGPT。
在 AI 思考方案的时候，从专家模型里提取最优的几条建议给过去，并告诉它：“Here’s one(a few) suggestion(s) for the command: Please use this suggestion as a reference and make your own judgement.”（这里有一些建议，你可以参考，但自己决定要不要听哈）。
用这种方式，感觉可以把专业知识更容易灌到系统里，可以同时发挥专家系统和 LLM 的功效。而且从产品设计的角度，其实提供了一个产品方可以人为干预效果的接口，可以玩出 100 种新花样。
里面还有个比较好玩的数据，就是其实 LLM 拒绝了很多建议，松散来看，大半建议被考虑了；严格来看，绝大部分建议都没有被直接采用。
这样看，LLM（或者直接说 GPT-4）确实真有脑子和主见啊。
把这些东西放一块，觉得自己得完全重新思考怎么设计产品了……
🔗 https://36kr.com/p/2275571949443076
🔗 GPT-4等大模型迎来进化转折点：不只是使用，还会自己制作工具了
🔗 Amazon | 深入研究LLMs与AutoGPT的结合：揭示出GPT-4惊人的人类决策能力！
4
AGENT
具体落地，GPTeam 的世界是怎么设计出来的?
整体架构上，最底层是世界（World），其中包含地点（Locations）、事件（Events）和代理（Agents），而代理（Agents）有记忆（Memories）和计划（Plans）。是不是感觉和我们真实世界很像？这种相似性里面有一个点吓到了我，最后介绍，留点悬念：p
当世界启动 world.run() 时，代理（agent）就会开始自己的循环（loop）。
从代码看，大体上就是先观察（observe）
然后看看自己有没有计划（plan），没的话就现想。
有计划了之后，根据当前事件（event）做出反应，如果决定不做了就放弃，决定推迟就添加个新计划到前面。
反应完了之后，就按照计划做第一件事情（do first plan），做好了再看看是否需要反思，需要的话反思总结一下。非常……像我们人类的方式，也非常符合直觉。
具体来说，代理（agent）做的第一件事情是观察（observe）。
算法要求代理把当前所在地点（location）发生的最新事件（events）看一遍，加入到记忆（memory）里。
添加记忆时会给每一段记忆打一个”重要性“分数，而打分方式很 AI，few shots 了一些例子给 LLM 让它自己来打分就好。
观察好了情况，就可以做计划（plan）了。
结合角色信息（建立，目标，最近做了什么，当前计划和当前位置）和当前想法，生成一系列（不超过 5 个）的计划和相应优先级排序。
每个计划都包含描述、地点、起始时间、终止条件和最长时间。计划会受到这个角色的 directives （个人目标，也可以理解为默认行为）的影响，这使得这些角色不仅仅是个环境反应器，而更像是有”主见“的真实个体。
另外比较有意思的是有个小细节设计，规定如果当前正在和其他角色交谈的话，就要结束对话之后再去做别的。如果合适的话，尝试在计划中邀请别人一起来协作完成。可能是为了增加互动。
有了计划之后，并不一定呀执行——我们自己定计划也未必真的会做。
代理这时会进入到反应阶段，对计划中的最高优先级事项，结合当下具体情况，决定到底是要做（continue）、推迟（postpone）还是算了（cancel）。
比较搞笑的是里面有一大段在教代理如何处理对话和任务之间关系。原来的设计里，代理一旦开始任务，就会直接干活搬砖去无视对话，而如果告诉它要优先回复对话的话，它们又会聊个没完没了。最后的 prompt 是”如果不响应对话会很粗鲁的话就需要响应”。
决定好了要做什么之后，接下来就是做（act）了。
做这一步，第一件事情居然是调取回忆……（看这个，愈发觉得人类的简单行为并不简单）。
会把最近的行为向量化，然后去长期记忆中匹配相关的记忆，根据重要性、相关性和时效性来提取。比如最近在备考，那么就会取之前考试相关信息，最近考试的记忆会清楚一些，重要考试的记忆也会清楚一些。
把记忆调取出来做背景信息之后，就可以真正开始做（act）了。
这一步本质上是告诉 PlanExecutor 它要扮演的角色、背景信息、相关记忆、相关对话、可用工具和需要完成的任务。
完成任务的方式是给出格式反馈：任务是什么，我怎么思考的，具体行动是什么，行动的输入是么，观察到的结果是什么……这个过程不断循环，直到观察到结论”我搞定了这个任务“或者发现”实在搞不定“然后寻求帮助。
比较有意思的是基础设定，这里是催眠 LLM “在一个现场表演中扮演这个角色”——这样使得这个角色会更多地表达，让我们的外部观察也更容易。
比如这个角色可能会在 Google 到有价值信息的时候自言自语一下”我靠，这个有意思！“（因为它要在观众面前表演），这样对我们观测者会友好和好玩很多。
另一个特殊的设计是在 bio 上，GPTeam 分开了公开 bio 和私人 bio，比如我的公开 bio 可能标签有”创业者“、”产品经理“、”今夜酒店特价“、“豁达通透”之类，但私人 bio 里则会有什么”追求认同“、“三分钟热度”、“焦虑不安“……代理相互之间只能看到公开 bio，但代理在具体做事时，也会参考自己的私人 bio，这样层次更丰富，也更像是真实世界。
事儿也做了，最后一步，反思（reflect）。
什么时候反思呢？GPTeam 的设计是当一个代理记忆中的事件重要性加总（这里没看明白什么叫 reaches a multiple of 100，暂时理解为重要度加总增量超过 100）达到阈值时，启动反思。这就会使得大事儿发生时，反思更频繁。
怎么反思呢？先提取近期的记忆，然后提 3 个重要的抽象总结问题。接下来，根据问题，从长期记忆中匹配相关记忆，对每段记忆提问“可以从中推导出什么高层次的见解？”，再根据这些见解回答抽象总结问题。
举例来说，可能给自己提的总结反思问题有一个是“任鑫是个怎样的人”，根据这个问题从长期记忆力拿到了“任鑫邀请我去参加读书会”、“任鑫总在 AI 炼金术公众号上写文章”，这两个记忆被推测成了“任鑫喜欢读书”和“任鑫喜欢写作”，然后综合回答第一个问题的答案就可能是“任鑫是个读书人”，日后这个代理和任鑫协作时，就会把这个信息考虑在内。
而当代理把 观察 → 反应 → 行动 → 反思 的循环跑通时，整个世界就跑起来了。
觉得这个设计框架真的很有趣，而且非常值得参考学习。
但其中还是有个地方有点吓人……如果是我来设计这个模型，很容易把每个角色（agent）设计成一个独立个体，然后让它们互动，这非常好理解。
但 GPTeam 并不是这样设计，而且作者们在一开篇还特地强调了这一点：想要深入了解代理循环如何工作的话，需要理解这个库里面并没有离散的代理 AI，表面上类似人类行为的实体，其实是我们的记忆系统和一系列大语言模型创造出来的幻觉
（As we dive into how the agent loop works, it’s helpful to understand that there is no discrete agentic AI to be found in this repository. The appearence of an agentic human-like entity is an illusion created by our memories system and a string of distinct Language Model prompts）。
最近在思考 AI-Native 产品设计的时候，总是在反观自己。在心流忘我状态时，会觉得自己就像是 GPT 吐词机器；
而在念头纷飞时，会觉得闹钟其实是无数 agents 在叽叽喳喳；而且，越来越觉得，自我意识可能真是幻觉……但就算有些想法，至少我觉得自己这个实体容器还是真实的，就算“我”是个幻觉，这个幻觉也是发生在一个具体的“我”的容器中，还是有一部分实在存在（我思故我在）。但从 GPTeam 这个设计看，其实也很未必……
啊啊啊啊啊啊啊。
推荐阅读：
🔗 https://blog.langchain.dev/gpteam-a-multi-agent-simulation/