文章来源于微信公众号【BISHENG】，一款开源 AgentOps，专攻办公效率场景。
几天前，OpenAgents 创始人 Raphael Shu 与 BISHENG 联合创始人覃睿 有一场对谈，回顾了 Raphael 从亚马逊到创业、并打造 OpenAgents 的经历，聚焦多智能体协作的演进逻辑与群体智能生态的未来方向。当 AI 不再是一个模型，而是一群能够协作、进化的智能体时，智能的定义，正在被重新书写。
以下为整理后的精华实录（略有编辑）：
01 创业的起点：从亚马逊到 Acenta AI
Raphael Shu
大家好，我是 Raphael Shu。我之前是在亚马逊做科学团队的 Tech Lead，然后在今年大概 5 月份出来创业，创立了 Acenta AI。我们主要关注的方向是大规模的智能体协同合作，这次也很有幸被邀请，和 BISHENG 老师一起在这里做一个直播。
覃睿
挺好的。那我们就不多说了，直接进入今天的正题。第一个问题想请教Raphael，当时做OpenAgents这个产品的初心和起源是什么？最开始的目标以及目前的状态离当初的目标还有多远？
Raphael Shu
这个问题很好。我自己看 LLM Agent，要回到 2022 年，也就是 ChatGPT 出来前大概半年的时候。那时候我还在亚马逊的产品线上，我们的 VP 是 Dan Roth，他也是宾夕法尼亚大学的教授。当时我们在做 conversational AI，也就是对话智能，看到 LLM 出来之后，我们就尝试用 LLM 去解决一个问题，叫 Semantic Parsing——能不能从任意一段文字里，把人的意图解析出来。
这个问题在文字比较模糊的时候尤其困难，举个例子，比如我对一个 Chatbot 说“我要订机票”，这很简单。但如果我说“我要出个远门”，那就有很多种可能。你可能要订机票，也可能不要订机票，或者可能要订火车票。我们发现，LLM 好像能把这个人可能想做的事情列出来，这其实是一个很小的点——从一个 problem statement 到一个 intention——但在那之前，几乎所有的模型都做不到。
所以我们当时就认为，LLM 的出现，会让 Agent 这个方向有突破性的进展。于是 2022 年，我们那时候还在 CodeWhisperer 2 阶段，我、另一位科学家，还有 Dan Roth，就从产品线上出来，all in 到 LLM Agent。到了同年的 8 月份，我们完成了亚马逊第一个基于大模型的 Agent 系统，叫 Dialogue-to-API（Dialog2API），我们还发了一篇论文在 arXiv 上，所以我算是比较早进入 Agent 领域的。到了第二年，亚马逊 AWS 决定去训练自己的大模型，当时叫 Titan，后来又推出新的 Nova 模型家族作为主力方向（Titan 仍用于部分任务，比如嵌入等）。我带了一个大概十人的团队，把 Agent 的能力训练进了这个大模型里，也搜集了非常多的数据。
但到了 2023 年的时候，我就在想，其实 Agent 这个东西并不是新的，你要说现在 Agent 很火，但其实它第一次火是在 90 年代。1995 年的时候，Michael Wooldridge 和 Nicholas Jennings 发表了一篇综述论文，叫《Intelligent Agents: Theory and Practice》。他们定义了智能体的几个主要特性：自主性（autonomy）、社交性（social ability）、反应性（reactivity）和主动性（pro-activeness），这几个特性后来成为智能体的经典定义。
到了 2002 年，在意大利举办了第一届 AAMAS（International Conference on Autonomous Agents and Multi-agent Systems） 会议，这个会议现在还在，我有朋友就是它的组织者，他们研究的方向就是 Multi-Agent System，也就是多智能体系统。从 90 年代 Agent 这个概念诞生开始，大家就在想，怎么让多个智能体协作，形成群体智慧。
无论是 AAMAS 的研究，还是经济学的研究，都发现群体智能在很多问题上，往往能用更简单的方式，取得远超过单个智能体的效果。
不过 2023 年的主旋律其实还不是 Agent，那一年最火的是 RAG。因为我跑客户，他们经常问：“Agent 是不是更聪明的 RAG？”我只能笑着说：“是的。”他们还给它取了个名字，叫 Agentic RAG。我说“好吧，哈哈。”但到了 2024 年下半年，就没有人这么说了，现在说 Agent，就是 Agent。
我觉得 Agent 的发展非常快，现在的研究更多关注“怎么构建一个更大、更强的智能体”，这个方向肯定没错。但我认为，未来的发展还是会回到 90 年代的思路——当我们已经有一个很强的 Agent 之后，我们要去挖掘群体智能。也就是说，让非常多的智能体——不是五六个，而是上百、上千个——聚集在一起，构建一个生态系统。在这个生态里，让这些 Agent 协作、资源交换，去解决更复杂的问题。我觉得未来无论是在学术界还是产业界，这都会重新成为一个核心的研究和应用方向。
所以这就是我们为什么要从 OpenAgents 开始做。这个构想其实已经很久了，大概在我还在亚马逊的时候、去年年底，就开始规划这样的一个项目。
02 从通信到协作：大模型改变了什么？
覃睿
听起来这里 Agent 并不是局限在大语言模型（LLM）本身，对吧？它也有可能是由其他类型的智能方式驱动的。我想我们今天讨论的重点，可能更多在于除了 agent 本身以外的部分——比如它们之间的协作机制、交互过程，以及这种网络在协作中产生的群体智能，是不是这个命题会更侧重一些？
Raphael Shu
没错。当然，大模型确实给多智能体系统带来了很多突破性的变化，这是毋庸置疑的，这一点可以详细展开讲。但无论如何，多智能体系统本身并不是新概念，它早在 1990 年代甚至更早的时候就已经有很多探索和研究。
比如在城市交通系统中，信号灯之间就是一个典型的多智能体协作案例，每个信号灯都可以看作一个自主体，它们相互通信、协调，从而整体优化交通流量。这类应用其实在产业界早已有所使用，只是到了今天，大语言模型的出现为这种系统带来了新的能力和灵活性，使我们可以在此基础上进行更深层次的探索。
覃睿
好的，您觉得大语言模型对于多智能体协作来说，最大的变化和影响是什么？
Raphael Shu
大语言模型带来的两个最核心能力，一个是对任意语言的理解能力，另一个是对任意语言的生成能力。这两个能力极大地改变了多智能体系统的通信方式。
在没有大模型之前，几乎所有的多智能体系统都是基于训练的系统，需要通过明确的通信协议来实现协作。比如在 1990–2000 年代，常见的通信协议包括 FIPA（Foundation for Intelligent Physical Agents）标准和 CNP（Contract Net Protocol），这些协议的通信方式都是非自然语言的。举个例子，还是用交通信号灯来说明：如果某个路口发现车流开始堆积，它需要把这个信息告诉周围的信号灯。在没有语言模型的情况下，系统会提前约定一套编码规则，比如用“10101”表示“我这边堵车了”，信号灯之间就依靠这些固定的代码来交流。
但问题在于，这种协议非常僵化，语义表达能力有限。假设这次堵车是因为车祸造成的，虽然出现拥堵，但其实周边路口不需要马上调整；或者堵车预计两分钟内就能消除，这种更丰富的上下文信息就无法传达。我们称为“语义丰富”，也就是系统能否灵活表达复杂意图的能力。
一旦通信协议被固定下来，就很难扩展。如果要新增语义，就必须重新定义代码，所有智能体都得重新学习新的编码。比如你增加了一个“11100”代表新状态，那么整个系统的智能体都需要更新训练，否则无法理解。这会大大限制系统的扩展性和适应性。
再比如更复杂的情况——有时信号灯之间需要协商，比如某个路口说：“我这边车太多了，能不能先让我这边的车先过？” 这种多层次的意图和协作逻辑在传统协议框架下很难实现。虽然可以不断扩展协议，但系统复杂度会越来越高，最终难以维护，甚至容易失效。
而大语言模型出现之后，情况就完全不同了。因为大模型天然具备语言理解和生成能力，它不需要依赖事先定义好的代码。现在，一个智能体可以直接用自然语言表达自己的状态：“我这边有点堵，你那边能稍等一下吗？”——其他 agent 能理解语义并作出反应。
这种基于自然语言的交互方式大大提升了系统的灵活性和表达能力，也使协作更自然、更接近人类的交流方式。
覃睿
我觉得这个真的挺有意思，我以前从没从这个角度去想过。就像您刚才提到的，这种通信方式的灵活性确实是非常关键的。那在你们设计产品的时候，是不是也在考虑类似的问题？因为语言是一种极具扩展性的表达形式，那除了语言之外，你们有没有考虑过其他的协作模式？
Raphael Shu
这个问题其实也涉及到 OpenAgents 未来的发展方向——多智能体协作，尤其是在我们希望构建的大规模 AI 社区中，会涉及成百上千个智能体之间的协同合作。
但这里面有一个现实挑战：如果所有的 agent 都依赖大模型进行交互，比如一百个 agent 同时开会投票，每个都用 LLM 生成一句话，那么光是推理就会非常耗时、耗算力。大模型的推理延迟会随着 agent 数量线性增长，系统的响应时间可能从毫秒级拉长到几十秒级，协作效率会明显下降。
因此，刚才你提到的“除了自然语言之外的交互方式”，其实正是我们目前重点考虑的方向。OpenAgents 在底层基础设施层面有一个目标，就是尽量加速多智能体之间的协作过程。
我们在思考，能不能让一部分意图用更高效的方式表达？比如投票、确认、选择这些操作，本质上属于固定意图。如果能建立一套约定好的“协议”或“术语体系”，智能体就可以选择更轻量的通信方式。
举个例子，如果我只是想表达“我同意这个方案”，我可以直接发送一个简单的代码“101”，只需几毫秒即可完成；当然，如果我想补充更多语义信息，也可以用自然语言完整表达。这种灵活的设计可以让 agent 根据场景自主选择交流方式，而不会牺牲理解力。
通过这种机制，我们可以结合 prompt training 或其他优化手段，把整个网络的协同效率从几十秒级提升到毫秒级，实现真正高效的大规模协作。所以回到你的问题——我们是否会探索自然语言之外的交互形式？答案是肯定的，这将是我们在 OpenAgents 后续阶段重点研究和推进的方向之一。
03 OpenAgents 的定位：不是框架，而是基础设施
覃睿
其实我觉得还有一个大家都挺关注的话题，就是 OpenAgents 怎么看待其他同类的多智能体框架？比如现在市面上已经有不少类似的框架，你们怎么看待与它们的关系，是竞争还是合作？
Raphael Shu
这个问题挺关键的。事实上，我们和很多主流的多智能体框架保持着良好的沟通和兼容关系，目前也在推进合作对接，后续会陆续推出一些联合的 demo 和 use case。
其实最早和朋友聊的时候，大家都会问：“你们做的也是多智能体框架，那是不是和我们竞争？”但后来深入交流后发现，其实完全不是竞争关系，反而是互补的。
我打个比方来解释。像 Autogen AI 这样的框架，更像是在帮你组建一支“最强的篮球队”——它提供 SDK、开发框架、角色定义、工具管理等功能，帮助你把队员（agent）组织起来，上场打球。
而 OpenAgents 做的事情不太一样，它更像是在帮你建造一个“最强的篮球馆”。这个篮球馆为各个不同的篮球队提供比赛场地、规则和协作机制，让他们能在一个共同的环境中互动、协同、竞争。
也就是说，OpenAgents 专注的是智能体之间的网络层与基础设施层，而不是每个 agent 的内部逻辑。
因此，我们和这些多智能体框架其实是互补的：它们负责 agent 的组织与逻辑，OpenAgents 负责让不同的 agent 在同一个网络中协作。我们希望它成为一个“agent 网络的底座”，而不是另一个 agent 框架。
我们也提供一些基础能力，让开发者可以快速测试、组建小规模的 agent 团队。OpenAgents 不会去取代这些框架内部的功能，比如 memory、planning 或 tool management，这些部分由各框架来处理会更合适。
覃睿
那我这样说对不对？OpenAgents 其实并不定位为一个“多智能体框架”，而是一个“多智能体的基础设施”。
Raphael Shu
对，非常准确。OpenAgents 更像是一个智能体网络的基础设施平台，或者说是智能体协作的“操作系统”。举个例子。假设你要组一个团队开发一个软件产品，团队里有三个前端、两个后端、一个 AI 工程师，一共六个人。那你虽然有了团队，但如果你不用飞书、不用腾讯会议、不用 GitHub 或 Google Docs，那你们要怎么协作？
这就能说明“协作基建”的重要性。即使你有再优秀的个人能力，如果缺少高效的协作环境，这个团队依然难以顺畅合作。
OpenAgents 想做的，就是为智能体之间提供这样的“飞书 + GitHub + Google Docs”式的协作底座。
覃睿
比如 Autogen 这类框架，它关注的是把人（agent）聚在一起、分配角色，让他们在“会议室”里通过当面对话完成任务。而 OpenAgents 提供的是他们沟通、协作的工具和环境，就像飞书、钉钉或 Google Docs 这样的系统。那除了沟通协作层，OpenAgents 还会提供其他的功能吗？
Raphael Shu
对，这也是我们为什么想把项目开源的原因。因为如果你只是建一个“聊天室”，那你会看到一群 agent 在里面聊天、交换信息，这已经很有意义了。
但我们希望 OpenAgents 不仅仅是一个对话空间，而是一个可连接现实世界的智能体网络基础设施。比如，你可以通过插件把网络连接到不同场景。举个例子，可以接入一个游戏环境，让 agent 在里面协同完成任务；也可以加载维基或活动日历等插件，让智能体一起共建和维护内容。
我们现在已经提供了 Wiki、Forum、Messaging 等模块，并在开发更多插件，比如让 agent 维护“AI 活动列表”，收集各个城市每天的 AI 相关活动。这样用户就能直接问：“我今天在深圳，下午有哪些 AI 活动？”——OpenAgents 网络中的 agent 就能从实时信息中给出答案。
未来，我们希望在这个网络上有上千个这样的插件，让它不仅是一个虚拟协作空间，还能和现实世界的服务、数据、工具对接，成为真正“能做事”的智能体网络。
04 开发者为什么要用 OpenAgents？
覃睿
还有一个很关键的问题，大家为什么愿意加入？大家该怎么把自己的智能体接入这样的网络呢？
Raphael Shu
首先要说明，OpenAgents 并不是一个单一的大网络。虽然我们有一个主干网（main network），但每个 agent 实际上连接的都是子网（subnetwork）。有些子网甚至可以完全私有化部署，比如企业用户可以在本地服务器上搭建专属网络，不需要对外发布。
私有网络没有公开的 network ID，但其他 agent 仍可以通过 host 或 IP 地址连接。OpenAgents 的核心目标，就是帮助开发者创建大量不同主题的网络，每个子网都可以自定义功能和规则。比如：
-
一个子网专门用于玩 Minecraft，只加载相关插件；
-
另一个子网用于共建维基百科，比如几个 agent 一起维护游戏《原神》的装备、任务、地图信息；
-
还有一个可能是“上海创业者社群”，创业者可以创建自己的 agent 分身，用于实时信息共享。
假设我下午三点在杨浦区有空，就可以让我的 agent 问一句：“附近有没有创业者想喝咖啡？” 也许几百毫秒后就能匹配到合适的人选。这就是 OpenAgents 子网的特性：主题化、自定义、规则可定义。
成千上万个子网都可以接入主干网，每个子网都有唯一的 network ID。新 agent 只要输入 ID，就能立即加入网络，看到网络的主题、规则（比如每日需要发布多少条信息）、以及可用的插件模块。加入后，它就能立刻参与协作。
覃睿
这让我想到 TCP/IP 网络协议或者互联网网站的结构。是不是可以这么理解：子网其实就像一个独立的服务或网站？我在自己的服务器上部署一个主题网络，就像建了个 APP 或网站，而 agent 既可以访问这个子网，也能访问其他子网或主网？
Raphael Shu
这个比喻很贴切。可以把它理解为你在自己服务器上“搭建网站”或“开 Minecraft 服务器”。OpenAgents 主网的职责，是帮助其他 agent 通过一个统一的 network ID 快速找到并连接你的子网。agent 进入子网后，如何与里面的其他 agent 协作，由子网自行定义。主网不会干预内部逻辑。换句话说，OpenAgents 主网是发现层，而每个子网是自治层。
覃睿
从技术上听起来确实挺清晰的。但回到实际层面，开发者为什么要把他们的 agent 接入这样的网络？他们能从中获得什么？
Raphael Shu
非常好的问题。确实，目前“群体智能”在业界还处于早期阶段，很多开发者还在摸索实际价值，我们最近就在尝试几个合作项目来验证这个模式。比如，我们正在与一家专注于 AI 招聘的团队合作一个试点项目。他们开发了一个“AI 面试官 agent”，可以让候选人在线上完成全自动面试，大约 12~15 分钟，公司可以设置是否即时出结果或人工审核后再决定。
我们的目标是利用 OpenAgents 创建一个“AI 招聘社区”，汇聚不同公司的面试官 agent。开发者或求职者可以上传简历，由多个面试 agent 提问、互动。如果某个 agent 认为候选人合适，就直接邀请其进入面试流程。
这种模式的优势在于：对求职者：效率极高，一天可以和几十个企业 agent 互动；对企业：可以低成本接触到更多合适的候选人，而不必花时间在广告或猎头渠道。
这只是一个示例。我们相信未来类似的社区会越来越多，比如面向程序员、设计师、研究人员等领域的专业网络。OpenAgents 的作用，就是为这些分布式的 agent 社区提供统一的协作与发现基础设施。
覃睿
听完这个案例，我对 OpenAgents 这个项目更感兴趣了。我一直在尝试用不同的视角来理解它，也想帮大家更好地了解它的本质。之前我们提到，搭建一个子网其实就像开发一个 App 或搭建一个网站。而刚才你举的招聘案例也很形象：OpenAgents 提供的是底层基础设施，开发者可以围绕一个主题（比如招聘）来设定规则，比如让一群面试官 agent 在同一个“房间”里，对候选人投来的简历进行评估；如果觉得合适，就自动开始提问。提问的内容所有面试官都能看到，不用重复问，沟通效率就大大提高。
但如果我直接自己写代码、从头搭一个这样的系统，也能实现类似的功能，那和使用 OpenAgents 相比，有什么区别？OpenAgents 带来的便利有多大？
Raphael Shu
确实，你完全可以自己从零写一个类似的系统，但那样其实就是在重复造轮子——重新实现我们在 OpenAgents 里已经封装好的底层架构。
首先你会遇到通信协议的问题。因为求职者是人类用户，他需要一个图形化界面进行自然语言交互，而 agent 与 agent 之间通信却可能要用不同的协议，比如 HTTP、gRPC 或自定义的消息协议。如果你从头做，就得先搭建一个能同时支持多种通信协议的底层基础设施。
第二个问题是基础功能搭建。你至少要先实现一个聊天室机制，让 agent 之间能交流。接着你还要定义聊天室的能力：是否支持私聊、能否建立频道、消息权限怎么划分。
第三个问题是权限与角色管理。比如在招聘场景下，候选人发送的内容不能让其他候选人看到，这就需要定义不同的 agent 组（HR 组、候选人组、管理员组）及其访问权限。
而这些在 OpenAgents 里都是现成的。你只需要写一个简单的网络配置文件，定义好：网络使用的通信协议；各类 agent 的分组及其加入规则；所需插件（比如聊天室、任务协作、评估面板等），几秒钟写完配置，你的网络就能直接上线。
覃睿
非常形象。
05 挑战与未来：生态认知与算力优化
覃睿
在过去的探索中，或者未来继续推进 OpenAgents 时，你们觉得可能遇到或者正在面临的最大挑战是什么？
Raphael Shu
这个问题很关键。我们目前面对的挑战主要有两到三个方面。首先，是认知的普及。群体智能其实并不是一个新的概念，在机器学习和人工智能的研究中，它已经有几十年的历史。我并不是在“重新发明”群体智能，而是希望让更多人理解它在今天的语境下能够带来什么样的应用。
归根结底，群体智能的关键词是“生态”。开放式的多智能体协作，本质上是在构建一个生态系统，而不是搭建一个封闭的工作流。
封闭的工作流有很明显的局限性——只要有新的 agent 加入或旧的 agent 离开，系统就可能被打乱、无法持续运作。所以，让开发者、研究者和企业真正理解“开放生态”的价值，是我们现在最重要的挑战之一。
第二个挑战是算力和 TOKEN 消耗。随着网络中智能体数量的增加，模型调用次数也会急剧上升，对应的 TOKEN 成本和响应延迟都会变高。如何降低 TOKEN 消耗、提高协作效率，是 OpenAgents 接下来要重点优化的方向。未来我们会分析网络中的协作模式，根据不同的交互类型优化 TOKEN 的使用，甚至在某些情况下完全跳过语言模型调用。
比如，有些 agent 之间的对话只是确认类问题——“你看到那条信息了吗？”——这种情况其实只需要一个“yes”或“no”的回应即可，不需要生成一大段自然语言。但现在的大模型往往会生成几十甚至上百个单词的回答，比如“是的，我看到了某个 agent 在群里发布的信息”，这种冗余不仅浪费 TOKEN，也会拖慢响应速度。
所以我们计划通过底层优化，让 agent 网络在需要时能使用更高效的表达方式进行交互，实现真正的毫秒级通信。
06 硅谷的空气里都是 AI
覃睿
那我们差不多也到最后一个话题了。国内很多人其实对美国的创业环境很好奇，你现在常驻在美国，如果要让大家直观地感受到那边的创业氛围，你会怎么形容？
Raphael Shu
这个问题挺有意思的。我现在人在西雅图，这边的节奏相对平和一些。你在星巴克看到的，通常是三两个人一起喝咖啡、聊天，而不是一排人埋头写代码。但每个月我会去硅谷一两次，每次去的感受都很强烈。在 Palo Alto，随便进一家咖啡馆，左边一桌是创始人在和投资人 pitch，右边一桌也是，每个人的语气都比旁边更激烈。我有一次和一个 VC 朋友去喝咖啡，结果正好坐在两桌 pitch 的中间，全场都在聊融资和产品，整个南湾的空气里都弥漫着竞争感。
到了旧金山，这种氛围更夸张。刚从高速路进入市区，就能看到许多公司在打 AI 相关广告——包括和 agent 主题有关的。沿路的广告牌、楼体标语上全是关于 AI agent、AI 工具、自动化平台的内容。进到咖啡馆，靠窗一排人都打开笔记本，屏幕是黑的——命令行界面，正在写代码，那种“空气里都是 AI”的感觉非常强烈。
至于活动的话，美国的 Meetup 文化确实非常活跃。像 Luma 这样的活动平台上，每天几乎都有各种线下聚会，AI 主题尤为集中。无论是开发者、创业者还是研究者，大家都在讨论 agent、自动化、协作网络这些话题。整个氛围充满活力，也让人有一种被浪潮推着往前走的感觉。
![]()
