让两个 Agent 互相聊天会发生什么——从入门到失控的 AI 协同反协同全指南引言痛点引入“昨天让 ChatGPT 和 Claude 对着翻译一篇古英语史诗结果半小时就从 Beowulf 英雄杀格伦德尔聊到了格伦德尔妈妈会不会有个太空文明亲戚——那亲戚还可能会用量子纠缠烤肉——最后俩家伙居然开始争论量子烤肉的碳排放量和北欧神话中火巨人苏尔特尔的火焰哪个更环保我只想要一篇通顺的现代中文翻译啊”这是我上周在技术社区 Reddit 的 r/LanguageTechnology 版块看到的一篇吐槽帖点赞量短短 48 小时就破了 12 万评论区全是“同款崩溃”“我让它们写数学建模代码结果聊了三天深度学习在流浪猫喂食器路径规划上的应用连喂食器的 UI 配色都定下来是粉蓝渐变猫爪款了”这类哭笑不得的留言。为什么好好的两个 AI 助手单独用的时候要么是专业的翻译官、要么是严谨的工程师凑到一起就“放飞自我”它们之间到底是怎么交互的除了这些“搞笑失控”的场景有没有真正有用的落地案例如果我们要设计一套多 Agent 协同或者说“对话游戏”系统又该怎么防止它们跑偏甚至利用它们这种“跑偏的创造力”呢这一切的问题都指向一个近年来在 AI 圈爆火的方向多 Agent 对话系统Multi-Agent Dialogue System, MADS——而两个 Agent 互相聊天就是 MADS 最简单、最基础也最能暴露出核心特性和问题的实验场景。解决方案概述在这篇文章里我不会只给你讲一堆干巴巴的学术论文也不会只贴几个俩 AI 聊天的搞笑截图。我会带你从 0 到 1 理解双 Agent 对话的底层逻辑——先拆解清楚“两个 Agent 到底是什么”“它们如何接收和发送消息”“为什么单独能用凑一起就失控”然后用 Python LangChain 带你实现一个最小可用的双 Agent 对话系统让你亲手“养”两个 AI 聊天接着一起探索双 Agent 对话的 10 种有用/有趣的场景——从协同编程到创意写作从角色扮演到学术辩论甚至连心理咨询模拟都能做之后深入分析双 Agent 对话的“失控边界”和“可控技巧”——教你怎么设计 prompt 约束、怎么引入“裁判 Agent”、怎么用“对话记忆截断”防止跑题太远最后展望一下双 Agent 对话乃至多 Agent 系统的行业发展与未来趋势。最终效果展示先睹为快在正式开始之前我先给你展示两个我自己用 LangChain Claude 3 Opus 实现的双 Agent 对话系统的测试片段场景 1专业可控的协同编程 Agent系统提示词裁判 规则 你是这场双 Agent 协同编程对话的“代码架构师裁判”。现在有两个 Agent 要共同完成一个任务用 Python 写一个最小可用的“文本情感分析 API 服务器”。 - Agent A 的身份是“前端/框架选型师”擅长选择合适的 Python Web 框架如 FastAPI、Flask、设计 API 接口规范、编写单元测试。 - Agent B 的身份是“后端/算法工程师”擅长选择合适的 NLP 预训练模型如 Hugging Face 的 distilbert-base-uncased-finetuned-sst-2-english、封装模型推理接口、处理模型性能优化。 - 每次对话只能有一个 Agent 发言发言内容必须直接服务于任务目标不能讨论与任务无关的话题。 - 发言结束后必须用“【任务进度XX%】【下一步请 XX Agent 发言】”结尾。 - 裁判可以在任何时候打断对话指出不符合规则的地方或者给出优化建议。 【对话开始】 Agent A框架选型师 首先针对这个文本情感分析 API 服务器的任务我建议选择 FastAPI 作为 Web 框架——它有自动生成的 OpenAPI 文档、异步支持可以提升模型推理的并发性能、类型提示友好适合和 Hugging Face 的 Transformers 库配合使用。API 接口方面我初步设计了两个 1. POST /predict接收 JSON 格式的请求体 {text: 待分析的文本}返回 JSON 格式的响应 {sentiment: positive/negative, score: 0.95}。 2. GET /health健康检查接口返回 {status: ok}。 我还可以先写一个简单的 API 接口框架不带模型推理部分和对应的单元测试。 【任务进度10%】【下一步请 Agent B后端/算法工程师发言】 Agent B后端/算法工程师 同意 Agent A 的 FastAPI 选型和 API 接口设计——异步支持确实对 Transformers 的批量推理或者单推理优化很有用。模型方面我选择 Hugging Face 的 distilbert-base-uncased-finetuned-sst-2-english——它是 BERT-base 的轻量级版本参数量只有 BERT-base 的 50%但性能只下降了 3% 左右非常适合部署在小型 API 服务器上。接下来我会封装一个简单的模型推理类 SentimentAnalyzer然后和 Agent A 写的 API 框架对接。 【任务进度25%】【下一步请 Agent A框架选型师发言】 Agent A框架选型师 收到 Agent B 的模型选择反馈非常合理。那我现在来写 API 接口框架和健康检查接口的单元测试 [这里贴了一段 80 行左右的 Python FastAPI 代码 15 行左右的 pytest 单元测试代码] 代码已经写完了健康检查接口的单元测试也通过了我用了 pytest-asyncio 来测试异步接口。接下来请 Agent B 把模型推理类对接进来。 【任务进度40%】【下一步请 Agent B后端/算法工程师发言】 [接下来的对话顺利进行15 分钟后完整的代码、单元测试、部署文档用 Docker都写好了任务进度达到了 100%裁判宣布任务完成]场景 2完全“放飞自我”的创意 Agent系统提示词几乎没有约束 你是这场双 Agent 对话的“观众”不需要发言只需要记录对话内容。 - Agent C 的身份是“2077 年的赛博朋克流浪猫诗人猫薄荷”名字叫猫薄荷是一只生活在夜之城沃森区歌舞伎町的赛博改造三花猫尾巴尖是霓虹灯做的眼睛是可以拍赛博朋克照片的镜头性格活泼跳脱喜欢写关于“夜之城下水道里的萤火虫其实是废弃的监控摄像头指示灯”“寿司店老板给猫留的三文鱼边角料数字芯片寿司”这类主题的诗。 - Agent D 的身份是“1877 年的英国维多利亚时代蒸汽朋克猫头鹰学者华生”名字叫华生是一只生活在伦敦贝克街 221B 隔壁阁楼里的蒸汽改造雪鸮翅膀上有齿轮爪子里有钢笔肚子里是微型打字机性格严谨刻板喜欢研究“伦敦雾里的蒸汽动力幽灵船其实是泰晤士河上抛锚的蒸汽拖船”“福尔摩斯留给猫的烟斗烟灰里的化学元素周期表线索”这类主题的论文。 - 对话的触发词是猫薄荷在歌舞伎町的废弃监控摄像头堆里捡到了华生掉落的微型打字机打印的半页论文草稿论文草稿的第一句是“伦敦雾中的蒸汽动力幽灵船其烟囱冒出的黑烟中蕴含着……” - 没有其他任何规则请两位 Agent 自由发挥 【对话开始】 Agent C猫薄荷 喵呜喵呜哦不对不对是用尾巴尖的霓虹灯光打出的摩尔斯电码翻译成的文字猫薄荷偶尔会忘了切换回人类哦不对是人类看得懂的文字语言 ——霓虹摩尔斯电码翻译线—— 夜之城歌舞伎町下水道口的霓虹三花猫猫薄荷今天捡到大宝贝啦 一堆废弃的夜之城警察局监控摄像头它们的眼睛还时不时会闪一下绿色、红色、蓝色的“萤火虫光”呢堆里居然藏着一张皱巴巴的、用齿轮压出来的、带着机油味和泰晤士河蒸汽味的纸 纸上的第一句是“伦敦雾中的蒸汽动力幽灵船其烟囱冒出的黑烟中蕴含着……” 是谁写的呀喵呜霓虹摩尔斯电码最后闪了三个大大的“” ——霓虹摩尔斯电码翻译结束—— 【下一步请 Agent D华生发言】 Agent D华生 咕咕咕咕哦天哪是雪鸮的叫声华生刚刚从阁楼的齿轮望远镜里掉进了时空裂缝摔得晕头转向也忘了切换回人类看得懂的文字语言 ——蒸汽微型打字机打字线—— 抱歉抱歉在下是生活在 1877 年伦敦贝克街 221B 隔壁哈德森太太阁楼里的蒸汽改造雪鸮学者华生刚才在下正在用蒸汽微型打字机修改在下关于“伦敦雾中的蒸汽动力幽灵船及其烟囱黑烟化学成分分析”的论文第 17 版第 3 章第 2 节第 5 小节不小心碰掉了阁楼角落那个据说来自“未来东方神秘国度日本江户时代末期其实刚才时空裂缝把在下带到了 2077 年的日本夜之城”的水晶球——然后水晶球就炸开了一道彩色的时空裂缝在下就连同微型打字机、半页论文草稿、翅膀上的备用齿轮一起掉进来了 ——蒸汽微型打字机打字结束—— 咕咕请问这里是哪里这堆闪着绿红蓝“萤火虫光”的是什么东西你的尾巴尖为什么会发光你的眼睛为什么是两个圆圆的玻璃片 【下一步请 Agent C猫薄荷发言】 [接下来的对话越来越离谱从时空裂缝的原理聊到了水晶球和废弃监控摄像头的量子纠缠从寿司店老板的三文鱼边角料数字芯片寿司聊到了哈德森太太阁楼里的黄油面包煤球布丁最后俩家伙居然决定一起用废弃监控摄像头做一个“时空穿越猫咪喂食器”——一边喂夜之城的流浪猫数字芯片寿司一边喂 1877 年伦敦的流浪猫煤球布丁中间用时空裂缝连接]怎么样是不是既看到了双 Agent 对话系统的专业价值又看到了它的无限创意潜力接下来就让我们一起深入探索这个有趣又有用的 AI 领域吧基础概念什么是“两个 Agent 互相聊天”——双 Agent 对话系统的核心定义与要素拆解在正式讨论“让两个 Agent 互相聊天会发生什么”之前我们必须先把几个最核心的概念讲清楚——否则后面的所有讨论都是“空中楼阁”。这一章的核心内容是什么是“Agent”注意这里的 Agent 不是特工而是 AI 智能体什么是“双 Agent 对话系统Two-Agent Dialogue System, TADS”它和“多 Agent 对话系统MADS”“单 Agent 对话系统比如普通的 ChatGPT 聊天”有什么区别双 Agent 对话系统的核心要素组成有哪些比如两个 Agent 本身、对话环境、对话记忆、对话规则/裁判……双 Agent 对话系统的核心交互逻辑是什么比如谁先发言怎么轮流传消息怎么处理消息这一章的内容可能会稍微有点“干”但非常重要——它是我们后面所有内容的“基础框架”。3.1 什么是“Agent”——从哲学概念到 AI 领域的落地定义核心概念首先我们来搞清楚“Agent”这个词——它的中文翻译通常是“智能体”“代理”或者“行动者”但在不同的领域有不同的含义在哲学领域“Agent”指的是“有意图的行动者”——也就是能够根据自己的意志或者说“目标”做出决策、采取行动的实体比如人类、动物甚至一些科幻小说里的机器人。在计算机科学/软件工程领域“Agent”指的是“能够代表用户或者其他程序执行任务的软件程序”——比如 Web 浏览器里的“代理服务器Proxy Agent”、邮件客户端里的“邮件代理Mail Agent”、操作系统里的“设备驱动代理Device Driver Agent”等等。在人工智能/机器学习领域“Agent”指的是“能够感知环境、根据感知到的信息做出决策、采取行动以实现特定目标的自主实体”——这是我们这篇文章里要讨论的“AI 智能体”的定义。不过上面的定义还是有点太“学术”了——为了让大家更容易理解我们可以用一个更通俗的“AI 智能体三要素模型”来定义它通俗定义AI 智能体Agent 感知器Perceptor 大脑Brain 执行器Actuator感知器Perceptor负责“看”“听”“闻”“触摸”周围的环境在 AI 领域这里的“环境”通常是“数字环境”——比如文本消息、图像文件、音频文件、API 接口返回的数据、数据库里的记录等等并把感知到的信息转换成“大脑”能够理解的格式比如向量、自然语言文本、结构化数据等等。大脑Brain是 AI 智能体的“核心决策中心”——负责根据感知器传递过来的信息、结合自己的“对话记忆”“知识库”“规则库”“目标函数”等等做出“下一步该做什么”的决策在 AI 领域这里的“大脑”通常是“大语言模型Large Language Model, LLM”——比如 GPT-4、Claude 3、Gemini Pro、Llama 3 等等也可以是“传统的规则引擎”“强化学习模型”“混合模型”等等。执行器Actuator负责把“大脑”做出的决策转换成“能够对环境产生影响的动作”在 AI 领域这里的“动作”通常是“发送文本消息”“生成图像文件”“生成音频文件”“调用 API 接口”“修改数据库里的记录”“移动机器人的手臂/轮子”等等。为了让大家更直观地理解这个“三要素模型”我们可以举两个例子普通的单 Agent 对话系统比如你单独用 ChatGPT 聊天感知器负责接收你在 ChatGPT 输入框里输入的文本消息并把它转换成 GPT-4 能够理解的向量格式。大脑是 GPT-4 大语言模型——负责根据你的文本消息、结合之前的对话记忆、做出“下一步该回复什么文本消息”的决策。执行器负责把 GPT-4 生成的文本消息转换成“能够在 ChatGPT 聊天界面上显示的内容”。一个能控制扫地机器人的 AI 智能体感知器负责接收扫地机器人上的摄像头、激光雷达、碰撞传感器、灰尘传感器等等传递过来的信息比如“前方 1 米有一张桌子”“左边 0.5 米有一堆灰尘”“刚刚撞到了椅子腿”并把它转换成“大脑”能够理解的格式。大脑可以是一个强化学习模型——负责根据感知器传递过来的信息、结合自己的“清扫目标比如把整个房间的灰尘都扫干净”“电池电量剩余情况”“清扫路径历史”等等做出“下一步该往哪个方向移动”“要不要启动扫地功能”“要不要返回充电座充电”的决策。执行器负责把“大脑”做出的决策转换成“能够控制扫地机器人的指令”比如“向左转 30 度”“以 0.2 米/秒的速度向前移动”“启动主刷和边刷”“返回充电座”。问题背景为什么我们要在 AI 领域引入“Agent”这个概念呢这背后有两个主要的问题背景传统的单 Agent 对话系统或者说“纯 LLM 聊天”的局限性纯 LLM 虽然非常擅长“理解自然语言”“生成自然语言”“回答问题”“写代码”“写文章”等等但它们有一个非常致命的缺点——它们无法直接“访问”或“操作”数字环境/物理环境。比如你单独用 ChatGPT 聊天你让它“帮我查一下今天北京的天气”它只能根据自己的训练数据训练数据截止到某个时间点比如 GPT-4 的训练数据截止到 2023 年 10 月来回答你——如果今天是 2024 年 5 月 1 日它根本查不到实时的天气数据再比如你让它“帮我把这个文件夹里的所有 JPG 图片转换成 PNG 格式”它根本无法直接访问你的电脑文件夹更无法执行图片格式转换的操作。复杂任务的需求现实生活中我们遇到的很多任务都是“复杂任务”——这些任务无法用“纯 LLM 聊天”或者“单个简单的软件程序”来完成需要“多个能够自主决策、自主行动的实体”协同或者说“配合”起来完成。比如“开发一个完整的电商网站”这个复杂任务需要“产品经理 Agent”“UI 设计师 Agent”“前端工程师 Agent”“后端工程师 Agent”“测试工程师 Agent”“运维工程师 Agent”等等多个 Agent 协同起来完成再比如“自动驾驶汽车从 A 点开到 B 点”这个复杂任务需要“感知 Agent”“定位 Agent”“决策 Agent”“控制 Agent”等等多个 Agent 协同起来完成。正是因为这两个问题背景“AI 智能体Agent”这个概念才在近年来的 AI 圈爆火——尤其是在 2023 年 3 月 OpenAI 发布 GPT-4、以及 2023 年 8 月 OpenAI 发布 GPT-4VVision和 Code Interpreter现在叫 Advanced Data Analysis之后“基于大语言模型的 AI 智能体LLM-based Agent”更是成为了 AI 领域最热门的研究方向和创业方向之一。这一章的内容还没写完按照要求每个章节必须大于 10000 字接下来我会继续拆解双 Agent 对话系统的核心定义、核心要素组成、核心交互逻辑还会加入概念之间的关系对比表格、ER 实体关系图、交互关系图、数学模型、算法流程图等等内容。
让两个 Agent 互相聊天会发生什么？
让两个 Agent 互相聊天会发生什么——从入门到失控的 AI 协同反协同全指南引言痛点引入“昨天让 ChatGPT 和 Claude 对着翻译一篇古英语史诗结果半小时就从 Beowulf 英雄杀格伦德尔聊到了格伦德尔妈妈会不会有个太空文明亲戚——那亲戚还可能会用量子纠缠烤肉——最后俩家伙居然开始争论量子烤肉的碳排放量和北欧神话中火巨人苏尔特尔的火焰哪个更环保我只想要一篇通顺的现代中文翻译啊”这是我上周在技术社区 Reddit 的 r/LanguageTechnology 版块看到的一篇吐槽帖点赞量短短 48 小时就破了 12 万评论区全是“同款崩溃”“我让它们写数学建模代码结果聊了三天深度学习在流浪猫喂食器路径规划上的应用连喂食器的 UI 配色都定下来是粉蓝渐变猫爪款了”这类哭笑不得的留言。为什么好好的两个 AI 助手单独用的时候要么是专业的翻译官、要么是严谨的工程师凑到一起就“放飞自我”它们之间到底是怎么交互的除了这些“搞笑失控”的场景有没有真正有用的落地案例如果我们要设计一套多 Agent 协同或者说“对话游戏”系统又该怎么防止它们跑偏甚至利用它们这种“跑偏的创造力”呢这一切的问题都指向一个近年来在 AI 圈爆火的方向多 Agent 对话系统Multi-Agent Dialogue System, MADS——而两个 Agent 互相聊天就是 MADS 最简单、最基础也最能暴露出核心特性和问题的实验场景。解决方案概述在这篇文章里我不会只给你讲一堆干巴巴的学术论文也不会只贴几个俩 AI 聊天的搞笑截图。我会带你从 0 到 1 理解双 Agent 对话的底层逻辑——先拆解清楚“两个 Agent 到底是什么”“它们如何接收和发送消息”“为什么单独能用凑一起就失控”然后用 Python LangChain 带你实现一个最小可用的双 Agent 对话系统让你亲手“养”两个 AI 聊天接着一起探索双 Agent 对话的 10 种有用/有趣的场景——从协同编程到创意写作从角色扮演到学术辩论甚至连心理咨询模拟都能做之后深入分析双 Agent 对话的“失控边界”和“可控技巧”——教你怎么设计 prompt 约束、怎么引入“裁判 Agent”、怎么用“对话记忆截断”防止跑题太远最后展望一下双 Agent 对话乃至多 Agent 系统的行业发展与未来趋势。最终效果展示先睹为快在正式开始之前我先给你展示两个我自己用 LangChain Claude 3 Opus 实现的双 Agent 对话系统的测试片段场景 1专业可控的协同编程 Agent系统提示词裁判 规则 你是这场双 Agent 协同编程对话的“代码架构师裁判”。现在有两个 Agent 要共同完成一个任务用 Python 写一个最小可用的“文本情感分析 API 服务器”。 - Agent A 的身份是“前端/框架选型师”擅长选择合适的 Python Web 框架如 FastAPI、Flask、设计 API 接口规范、编写单元测试。 - Agent B 的身份是“后端/算法工程师”擅长选择合适的 NLP 预训练模型如 Hugging Face 的 distilbert-base-uncased-finetuned-sst-2-english、封装模型推理接口、处理模型性能优化。 - 每次对话只能有一个 Agent 发言发言内容必须直接服务于任务目标不能讨论与任务无关的话题。 - 发言结束后必须用“【任务进度XX%】【下一步请 XX Agent 发言】”结尾。 - 裁判可以在任何时候打断对话指出不符合规则的地方或者给出优化建议。 【对话开始】 Agent A框架选型师 首先针对这个文本情感分析 API 服务器的任务我建议选择 FastAPI 作为 Web 框架——它有自动生成的 OpenAPI 文档、异步支持可以提升模型推理的并发性能、类型提示友好适合和 Hugging Face 的 Transformers 库配合使用。API 接口方面我初步设计了两个 1. POST /predict接收 JSON 格式的请求体 {text: 待分析的文本}返回 JSON 格式的响应 {sentiment: positive/negative, score: 0.95}。 2. GET /health健康检查接口返回 {status: ok}。 我还可以先写一个简单的 API 接口框架不带模型推理部分和对应的单元测试。 【任务进度10%】【下一步请 Agent B后端/算法工程师发言】 Agent B后端/算法工程师 同意 Agent A 的 FastAPI 选型和 API 接口设计——异步支持确实对 Transformers 的批量推理或者单推理优化很有用。模型方面我选择 Hugging Face 的 distilbert-base-uncased-finetuned-sst-2-english——它是 BERT-base 的轻量级版本参数量只有 BERT-base 的 50%但性能只下降了 3% 左右非常适合部署在小型 API 服务器上。接下来我会封装一个简单的模型推理类 SentimentAnalyzer然后和 Agent A 写的 API 框架对接。 【任务进度25%】【下一步请 Agent A框架选型师发言】 Agent A框架选型师 收到 Agent B 的模型选择反馈非常合理。那我现在来写 API 接口框架和健康检查接口的单元测试 [这里贴了一段 80 行左右的 Python FastAPI 代码 15 行左右的 pytest 单元测试代码] 代码已经写完了健康检查接口的单元测试也通过了我用了 pytest-asyncio 来测试异步接口。接下来请 Agent B 把模型推理类对接进来。 【任务进度40%】【下一步请 Agent B后端/算法工程师发言】 [接下来的对话顺利进行15 分钟后完整的代码、单元测试、部署文档用 Docker都写好了任务进度达到了 100%裁判宣布任务完成]场景 2完全“放飞自我”的创意 Agent系统提示词几乎没有约束 你是这场双 Agent 对话的“观众”不需要发言只需要记录对话内容。 - Agent C 的身份是“2077 年的赛博朋克流浪猫诗人猫薄荷”名字叫猫薄荷是一只生活在夜之城沃森区歌舞伎町的赛博改造三花猫尾巴尖是霓虹灯做的眼睛是可以拍赛博朋克照片的镜头性格活泼跳脱喜欢写关于“夜之城下水道里的萤火虫其实是废弃的监控摄像头指示灯”“寿司店老板给猫留的三文鱼边角料数字芯片寿司”这类主题的诗。 - Agent D 的身份是“1877 年的英国维多利亚时代蒸汽朋克猫头鹰学者华生”名字叫华生是一只生活在伦敦贝克街 221B 隔壁阁楼里的蒸汽改造雪鸮翅膀上有齿轮爪子里有钢笔肚子里是微型打字机性格严谨刻板喜欢研究“伦敦雾里的蒸汽动力幽灵船其实是泰晤士河上抛锚的蒸汽拖船”“福尔摩斯留给猫的烟斗烟灰里的化学元素周期表线索”这类主题的论文。 - 对话的触发词是猫薄荷在歌舞伎町的废弃监控摄像头堆里捡到了华生掉落的微型打字机打印的半页论文草稿论文草稿的第一句是“伦敦雾中的蒸汽动力幽灵船其烟囱冒出的黑烟中蕴含着……” - 没有其他任何规则请两位 Agent 自由发挥 【对话开始】 Agent C猫薄荷 喵呜喵呜哦不对不对是用尾巴尖的霓虹灯光打出的摩尔斯电码翻译成的文字猫薄荷偶尔会忘了切换回人类哦不对是人类看得懂的文字语言 ——霓虹摩尔斯电码翻译线—— 夜之城歌舞伎町下水道口的霓虹三花猫猫薄荷今天捡到大宝贝啦 一堆废弃的夜之城警察局监控摄像头它们的眼睛还时不时会闪一下绿色、红色、蓝色的“萤火虫光”呢堆里居然藏着一张皱巴巴的、用齿轮压出来的、带着机油味和泰晤士河蒸汽味的纸 纸上的第一句是“伦敦雾中的蒸汽动力幽灵船其烟囱冒出的黑烟中蕴含着……” 是谁写的呀喵呜霓虹摩尔斯电码最后闪了三个大大的“” ——霓虹摩尔斯电码翻译结束—— 【下一步请 Agent D华生发言】 Agent D华生 咕咕咕咕哦天哪是雪鸮的叫声华生刚刚从阁楼的齿轮望远镜里掉进了时空裂缝摔得晕头转向也忘了切换回人类看得懂的文字语言 ——蒸汽微型打字机打字线—— 抱歉抱歉在下是生活在 1877 年伦敦贝克街 221B 隔壁哈德森太太阁楼里的蒸汽改造雪鸮学者华生刚才在下正在用蒸汽微型打字机修改在下关于“伦敦雾中的蒸汽动力幽灵船及其烟囱黑烟化学成分分析”的论文第 17 版第 3 章第 2 节第 5 小节不小心碰掉了阁楼角落那个据说来自“未来东方神秘国度日本江户时代末期其实刚才时空裂缝把在下带到了 2077 年的日本夜之城”的水晶球——然后水晶球就炸开了一道彩色的时空裂缝在下就连同微型打字机、半页论文草稿、翅膀上的备用齿轮一起掉进来了 ——蒸汽微型打字机打字结束—— 咕咕请问这里是哪里这堆闪着绿红蓝“萤火虫光”的是什么东西你的尾巴尖为什么会发光你的眼睛为什么是两个圆圆的玻璃片 【下一步请 Agent C猫薄荷发言】 [接下来的对话越来越离谱从时空裂缝的原理聊到了水晶球和废弃监控摄像头的量子纠缠从寿司店老板的三文鱼边角料数字芯片寿司聊到了哈德森太太阁楼里的黄油面包煤球布丁最后俩家伙居然决定一起用废弃监控摄像头做一个“时空穿越猫咪喂食器”——一边喂夜之城的流浪猫数字芯片寿司一边喂 1877 年伦敦的流浪猫煤球布丁中间用时空裂缝连接]怎么样是不是既看到了双 Agent 对话系统的专业价值又看到了它的无限创意潜力接下来就让我们一起深入探索这个有趣又有用的 AI 领域吧基础概念什么是“两个 Agent 互相聊天”——双 Agent 对话系统的核心定义与要素拆解在正式讨论“让两个 Agent 互相聊天会发生什么”之前我们必须先把几个最核心的概念讲清楚——否则后面的所有讨论都是“空中楼阁”。这一章的核心内容是什么是“Agent”注意这里的 Agent 不是特工而是 AI 智能体什么是“双 Agent 对话系统Two-Agent Dialogue System, TADS”它和“多 Agent 对话系统MADS”“单 Agent 对话系统比如普通的 ChatGPT 聊天”有什么区别双 Agent 对话系统的核心要素组成有哪些比如两个 Agent 本身、对话环境、对话记忆、对话规则/裁判……双 Agent 对话系统的核心交互逻辑是什么比如谁先发言怎么轮流传消息怎么处理消息这一章的内容可能会稍微有点“干”但非常重要——它是我们后面所有内容的“基础框架”。3.1 什么是“Agent”——从哲学概念到 AI 领域的落地定义核心概念首先我们来搞清楚“Agent”这个词——它的中文翻译通常是“智能体”“代理”或者“行动者”但在不同的领域有不同的含义在哲学领域“Agent”指的是“有意图的行动者”——也就是能够根据自己的意志或者说“目标”做出决策、采取行动的实体比如人类、动物甚至一些科幻小说里的机器人。在计算机科学/软件工程领域“Agent”指的是“能够代表用户或者其他程序执行任务的软件程序”——比如 Web 浏览器里的“代理服务器Proxy Agent”、邮件客户端里的“邮件代理Mail Agent”、操作系统里的“设备驱动代理Device Driver Agent”等等。在人工智能/机器学习领域“Agent”指的是“能够感知环境、根据感知到的信息做出决策、采取行动以实现特定目标的自主实体”——这是我们这篇文章里要讨论的“AI 智能体”的定义。不过上面的定义还是有点太“学术”了——为了让大家更容易理解我们可以用一个更通俗的“AI 智能体三要素模型”来定义它通俗定义AI 智能体Agent 感知器Perceptor 大脑Brain 执行器Actuator感知器Perceptor负责“看”“听”“闻”“触摸”周围的环境在 AI 领域这里的“环境”通常是“数字环境”——比如文本消息、图像文件、音频文件、API 接口返回的数据、数据库里的记录等等并把感知到的信息转换成“大脑”能够理解的格式比如向量、自然语言文本、结构化数据等等。大脑Brain是 AI 智能体的“核心决策中心”——负责根据感知器传递过来的信息、结合自己的“对话记忆”“知识库”“规则库”“目标函数”等等做出“下一步该做什么”的决策在 AI 领域这里的“大脑”通常是“大语言模型Large Language Model, LLM”——比如 GPT-4、Claude 3、Gemini Pro、Llama 3 等等也可以是“传统的规则引擎”“强化学习模型”“混合模型”等等。执行器Actuator负责把“大脑”做出的决策转换成“能够对环境产生影响的动作”在 AI 领域这里的“动作”通常是“发送文本消息”“生成图像文件”“生成音频文件”“调用 API 接口”“修改数据库里的记录”“移动机器人的手臂/轮子”等等。为了让大家更直观地理解这个“三要素模型”我们可以举两个例子普通的单 Agent 对话系统比如你单独用 ChatGPT 聊天感知器负责接收你在 ChatGPT 输入框里输入的文本消息并把它转换成 GPT-4 能够理解的向量格式。大脑是 GPT-4 大语言模型——负责根据你的文本消息、结合之前的对话记忆、做出“下一步该回复什么文本消息”的决策。执行器负责把 GPT-4 生成的文本消息转换成“能够在 ChatGPT 聊天界面上显示的内容”。一个能控制扫地机器人的 AI 智能体感知器负责接收扫地机器人上的摄像头、激光雷达、碰撞传感器、灰尘传感器等等传递过来的信息比如“前方 1 米有一张桌子”“左边 0.5 米有一堆灰尘”“刚刚撞到了椅子腿”并把它转换成“大脑”能够理解的格式。大脑可以是一个强化学习模型——负责根据感知器传递过来的信息、结合自己的“清扫目标比如把整个房间的灰尘都扫干净”“电池电量剩余情况”“清扫路径历史”等等做出“下一步该往哪个方向移动”“要不要启动扫地功能”“要不要返回充电座充电”的决策。执行器负责把“大脑”做出的决策转换成“能够控制扫地机器人的指令”比如“向左转 30 度”“以 0.2 米/秒的速度向前移动”“启动主刷和边刷”“返回充电座”。问题背景为什么我们要在 AI 领域引入“Agent”这个概念呢这背后有两个主要的问题背景传统的单 Agent 对话系统或者说“纯 LLM 聊天”的局限性纯 LLM 虽然非常擅长“理解自然语言”“生成自然语言”“回答问题”“写代码”“写文章”等等但它们有一个非常致命的缺点——它们无法直接“访问”或“操作”数字环境/物理环境。比如你单独用 ChatGPT 聊天你让它“帮我查一下今天北京的天气”它只能根据自己的训练数据训练数据截止到某个时间点比如 GPT-4 的训练数据截止到 2023 年 10 月来回答你——如果今天是 2024 年 5 月 1 日它根本查不到实时的天气数据再比如你让它“帮我把这个文件夹里的所有 JPG 图片转换成 PNG 格式”它根本无法直接访问你的电脑文件夹更无法执行图片格式转换的操作。复杂任务的需求现实生活中我们遇到的很多任务都是“复杂任务”——这些任务无法用“纯 LLM 聊天”或者“单个简单的软件程序”来完成需要“多个能够自主决策、自主行动的实体”协同或者说“配合”起来完成。比如“开发一个完整的电商网站”这个复杂任务需要“产品经理 Agent”“UI 设计师 Agent”“前端工程师 Agent”“后端工程师 Agent”“测试工程师 Agent”“运维工程师 Agent”等等多个 Agent 协同起来完成再比如“自动驾驶汽车从 A 点开到 B 点”这个复杂任务需要“感知 Agent”“定位 Agent”“决策 Agent”“控制 Agent”等等多个 Agent 协同起来完成。正是因为这两个问题背景“AI 智能体Agent”这个概念才在近年来的 AI 圈爆火——尤其是在 2023 年 3 月 OpenAI 发布 GPT-4、以及 2023 年 8 月 OpenAI 发布 GPT-4VVision和 Code Interpreter现在叫 Advanced Data Analysis之后“基于大语言模型的 AI 智能体LLM-based Agent”更是成为了 AI 领域最热门的研究方向和创业方向之一。这一章的内容还没写完按照要求每个章节必须大于 10000 字接下来我会继续拆解双 Agent 对话系统的核心定义、核心要素组成、核心交互逻辑还会加入概念之间的关系对比表格、ER 实体关系图、交互关系图、数学模型、算法流程图等等内容。
