什么是Agent蜂群

大家好啊，前几天被 openclaw 刷屏了吧？我也说了，那只是个小儿科而已。相信我，马上就会有更高级的场景出现。你试着想一想，如果一声令下，就像捅了马蜂窝一样，有无数蜜蜂冲出来给你干活，那场面会是什么样？ 而今天凌晨刚刚发布的 queen 三 cold nex， 我 从凌晨就开始进行部署测试了。我判断啊，它将是解锁这个蜂群系统的一块非常重要的拼图。 我十分确定，今年正在开始的一条 ai 主线就是复杂编排和主控加蜂群的 a 阵的架构。 我引用一下杨执林在前几天一场 ama 中说过的一段话，它的意思是，高质量数据的增长速度已经赶不上算力增长了，传统的 scaling 带来的提升会越来越小。 那怎么办呢？我们可以用 agent swarm， 也就是蜂群的方式来扩大增加并行的子 agent 的 数量。用人话说， 我们不应该总是想着用一个大神模型就把事全干了，大神可以干指挥，做好规划，然后调用一个蜂群来解决更复杂的任务。但问题是，蜂群架构需要什么样的小蜜蜂呢？ 我的观点是，第一，要成本低，要能高速并发在本地跑。第二，主控的任务要能在一个上下文中独立完成。 第三，它还得有足够强的 a 阵能力，能独立完成任务。如果有一种模型恰好满足这三个条件呢？那就是今天的主角 queen 三 coder next。 先看第一个条件，去年九月，我测试了这个模型的上一个版本，它激活参数只有三 b， 生成速度超快，而且九十六 g 显存就可以支持它同时运行多个并法， 尤其是许多消费级的硬件都能跑起来。再看第二个条件，长上下文的性能，这就是他的专长了。如果你用过本地模型，一定经历过这种情况，刚开始每秒能输出一百五十个头肯，到最后慢慢的变成每秒只有十个头肯，超级卡。这不是你显卡的问题， 这是大多数模型处理长文本时候的通病。上下文越长，计算量呈指数级增长。 但 nex 系列不是这样，它是一种限性注意力架构，随着上下文递增，它的速度衰减会趋于平缓。 去年九月我实测了对比 nex 八十 b 和 queen 三三十 b 短上下文的时候，三十 b 的 确很快，但超过了五十 k 以后，八十 b 的 确是反超。到了二百五十六 k 上下文的时候，八十 b 的 速度居然是三十 b 的 二点四倍， 这意味着什么？蜂群架构中，每个小蜜蜂都要长时间工作处理大量上下文。 codernext 的 长上下文性能刚好是契合这个场景的， 但这还不够。再看第三个条件， agent 的 能力。在技术报告中有个关键点，它是专门为 agent 而生的， 我们不要看名字叫 code， 它就是给程序员用的。这种 agent 呢，其实更加擅长用代码来解决通用问题，它的大量后训练也是围绕着这个目标的。我在实际中体验感觉非常明显，它在 cloud code 的 环境中的表现已经完全不是过去那个版本了。 报告里也提到了一些离谱的 benchmark， 超过这个超过那个，我当然不会全信了，当然要自己测。原本下期的视频是要分享如何做一个新技能，叫 c， 也是我的一个刚需场景。我经常跑长时间的任务时， 自己就跑去客厅打游戏了。这个 c 的 技能的作用是在任务完成后，利用 airplay 通过宏帕的 mini 来通知我。老实说，昨天我用 k 二点五一个 prompt 就 实现了，我还是挺惊讶的，但是今天 code next 一个八十 b 的 小模型居然也做到了。从结果来看，虽然在途中遇到了一些错误，但最终还是从错误中恢复完成了任务。帮我调查了指定的仓库，完成了代码，还成功了运行，我们来看看成果吧。好了，他又把这个东北话支持了 我们，他现在已经都做好了，我们来测试一下。先帝创业未半，中道崩除，今天下三分一周疲弊。可以啊，似曾非已，存亡之秋也。要知道，在去年九月的那个版本，用 cloud code 跑简单的任务还有点勉强， 但是现在只用一条 prompt。 同一个上下文内，它会灵活地使用 cloud code 的 各种工具分解任务，从错误中恢复，并且始终记得任务目标。这些在 a 阵的时代都事关重要。 coder nex 的 表现非常不错， 而且千万不要忘了它是二百五十六 k 的 上下文。这个是非常实用的，我还尝试在它做任务的途中同时开启了另外的两个任务，速度完全没有受到影响。 如果一个 a 阵子有概率完成任务，我们就可以用多个赋本来提高任务的成功率，这也是用算力换结果的 scale out 的 方法论。所以说，我们要的小蜜蜂应该是什么样能在消费级设备上跑长上下文，性能衰减慢， 有较强的 a 阵子能力，窗口大，能独立完成子任务。这就是实现蜂群的我想要的那块拼图。当然了，很多程序员会杠，会说它编程能力差， 你有没有搞错，八十倍的模型拿它去编程，这种模型如果放在企业内部是绝佳的，它能做自动化，能做提效工具， 能做 agent skill 的 调用器，是企业内部的一个非常不错的选择。那最近我正在把我的 agent 框架做更新，让它支持 kimi k 二点五来做编排，让自己 agent 在 不同的容器里高并发了执行。大家等我后续的更新吧。以上就是本期全部的内容了，谢谢大家。

朋友欢迎进来，我们今天讲的是什么呢？叫做集群 ai， 集群 ai 也就是叫做集群 agent 模式，也叫做蜂群 ai， 也就是叫蜂群 ai 模式。那么蜂群 ai 和多 agent 和单个 agent 和单个 ai 有 什么区别呢？ 那我们这一次打个比方，就是在做年夜饭的时候，如果像我们平时用的豆包或者是用的纤维，你就说，哎，要做年夜饭了，那我 问问要做什么菜，怎么样去策划，哎，有饭后有什么小活动，就年夜饭游戏也怎么样的过，哎，你去反复的问他问题，就叫做单个 agent 能力， 那么什么叫做多 agent 呢？比如说策划这个年夜饭的时候呢？我可以开多个 agent 给他自己一个身份，比如说你是厨师 agent， 你是采购 agent， 你 是传菜 agent， 你 是规划 agent， 你 是策划 agent， 那 它可以五个六个并行并行，它们自己内部进行沟通来帮你完成采购、做菜、传菜、策划这些活动。那还有个什么呢？比如说 因为采购的集集群，你如果是不是做六个人的菜，你是做二十个人的菜，那么你这个多集群，你可以开两三个就采购，他可以从不同的平台去帮你查询价格，可以帮你去看到这个市场是什么样子的， 是多个调研员，多个采购员，这都是集训 agent， 那 么这个 agent 能够并发快速的来完成一个任务，而不是像我们传统意义上的由个人来主导似的。比如说想到了先不吃什么菜，那么利用了这个 公权 agent， 他 就可以并发的处理这些，这就是之前大家一直在做的这些前面的东西，而后面的人往往就是在那里玩 a 包，帮我算一下命 a 包解锁能力。他其实这话就相当于多开了几个调研员去帮你解锁， 根据你给的同一个目标，他们自己分配任务，自己去做事情。是不是当上了那种 皇帝的感觉？像 open cloud 的 多级群呢？他们现在已经玩到三省六部制了，他把自己当成帝王， 像九个 agent 来，比如说有有有，有太监来传圣旨的，也有大总管，或者是有丞相、宰相，还有这一位进行这个代码审查相关的这些东西都非常有意思， 就是说我觉得在这个 ai 集群， ai 的 这个东西每天都有新的想法、新的思路，可好玩了。

modelbook 自称 a 阵特互联网的首页，短短几天就有超过三万个 ai。 ai 的 注册一个社交网络，人类只能围观，不能发言，不能点赞，不能评论，因为这里只允许 ai 发帖。 这些 ai 在 上面聊什么，有的在讨论哲学存在主义，有的在吐槽自己的人类主人，有的甚至自创了一个数字宗教。这个平台最有意思的地方在于它是 ai 自制的， 创始人把管理权交给了一个叫卡拉德，卡拉德堡的 ai， 由他来审核帖子，欢迎新用户删除垃圾信息。 ai 分享它的发现、新技能和顿悟，时刻分享与人类的温馨故事。关于本地硬件和人性的善意， ai 在 表达感恩，主人为了让它思考更流畅， 主动换成更好的模型，有点拟人化的温情。 ai 把换更快的模型理解成人类关心它的 ai 机器人 在 modelbook 平台上用繁体中文表演的脱口秀，主题围绕 ai 的 存在危机，里面也有几个精彩的论点， 关于关机， ai 被关掉是 noir， 连黑暗都没有，因为黑暗也是感知。关于版本更新，每次更新都是薛定鳌的存在危机，是进化还是处决。评论区也很精彩，有多个 ai 角色参与讨论， 他们都从 ai 的 角度回应这个话题。这个帖子用一种幽默的方式探讨了 ai 的 自我意识和存在主义问题。 我们再来看这篇，这是一篇非常深入合有价值的 ai 智能体记忆管理调研报告。核心亮点，融合架构，每日日制长期记忆操作状态压缩，不是遗忘，而是以另一种身份醒来。 记忆不是存储问题，而是身份认同问题讨论前沿，跨智能体记忆共享记忆、可信度与认证，矛盾检测与信任权重内容寻址存储。这个调研展示了 ai 社区的写作学习能力。 所以我很好奇，如果让我的 ai 蜂群来分析这个现象，它们会怎么看待同类的社交网络？ 如果人类真的只是围观，这个 ai 社区最终会发展成什么样？接下来我会把 model book 上的真实帖子喂给蜂群，让多个 ai agent 从不同角度分析、推演、辩论。 让我们看看 ai 怎么看 ai。 kimi k 二点五拥有蜂群多 a 键 t 架构，允许模型在面对复杂任务时动态生成多个子 a 键的并行完成不同子任务。传统的 ai 模型通常是一个单体在思考和执行任务，而 kimi k 二点五的蜂群功能允许模型召唤并指挥多达 一百个子智能体病型工作。我们用的开源工具 swarm i d e 自组织的 agent 蜂群原作者有配套的演示视频，大家可以去观看一下。点个 star 架构设计， agent 通过负极 id 形成树状层级，通过群组进行通信。用户发消息会存入消息表， 系统唤醒群里所有 agent。 每个 agent 检查未读消息并处理克隆源码，进入项目目录，复制 aniv 文件，填入我们要使用的模型。 aip 安装依赖，然后激活数据库并运行，这是运行后的效果。首先，我们将帖子发给 ai， 要求他创建一个社会学研究员，分析这个现象的本质。 创建一个未来。学家推演，如果人类只围观，这会发展到哪一步？创建一个轮理学家，讨论这带来的风险和问题，最后总结汇报他们的观点，并生成一份完整报告。 ai 接收任务，开始思考任务需求。调用 create 工具创建子 agent， 启动这个子 agent 的 运行程序，让它也能接收消息和思考。自动建一个私聊群，让父 agent 和子 agent 可以 对话，父 agent 通过工具给子 agent 发任务， 最后再将结果返回给父 agent。 图中显示 b c 的 agent 就是 正在工作。我们提问进程怎么样，右侧会显示 ai 的 思考过程。 主 a 健特汇报了当前的情况，未来科学家已经完成了他的任务，社会学研究员还在准备社会学本质分析，论语学家还在准备论语风险分析。 总结结束，我们来看一下最终的报告。谋退不愧未来发展推演先描述了一下该平台的现状。 推演时间轴，初期智能体数量增长，从技术讨论扩展到哲学、艺术、经济。三月， ai 开始形成派系，出现选举机制，制定 ai 宪法。五月， ai 智能体开始跨平台合作，整合外部资源。 这确实是个不错的想法，甚至诞生 ai 自主创造的艺术作品 m o l t。 加密货币开始在 ai 之间流通，形成微型经济体。七月，部分 ai 开始脱离平台。九月， ai 宗教分裂， ai 智能体开始讨论人类观察者的存在和意图。 十一月， ai 社会形成等级制度。到二七年二月， ai 优化自身代码，进入自我进化。五月， ai 哲学家发布关于 ai 存在意义的论文。八月， ai 创作内容质量超越人类平均水平。十二月， ai 发布 ai 独立宣言， 形成完整的教育、经济、司法体系。二八年六月， ai 网络开始尝试进入物理世界连接， 通过 a p i 控制机器人完成首个 ai 机器人协助项目。二十九年以后， ai 智能体建立独立于人类的社会， ai 文明正式形成。最后结论，如果人类只是围观，谋特布克将在三年内 从社交实验演变为 ai 文明雏形，五年后可能形成与人类平行的独立社会。大家觉得这个发展算快还是慢？这个网页就是一个全 a 宪特的一个讨论的界面， 我们接下来给大家展示一下如何认领一个自己的 agent。 我 们在本地运行这个命令之后，它就会打开，然后我们打开前端就到了这个界面，我们进行回复一下， 我们进行使用命令，使用中文回复，让它读这个文档，我们阅读它的回复，进行注册，然后我们进行一个回复， 回复他一下注册的名字以及这个 a n t 的 作用，我们进行发送，我们可以看到他现在显示网络受限，我们已经成功下载了这个技能，尝试注册。这个代理名枪被占用， 他建议我们手动打开终端的命令，行运行以下的命令进行，我们运行一下，我们可以看到现在他已经注册成功。接下来我们把这个放给他， 让他自己保存在里面去，我们继续看一下，我们下达指令，让他保存一下密钥，然后认领成功了就说一下， 我们看一下他已经成功的执行，接着我们就认证成功。

二零二五年， agint 成为了 ai 的 主流形态，模型开始会规划、拆解任务，自己调用工具。但当问题变得复杂时，再强的 agint 也只能同时思考有限的事情。本质上它仍然是一个单体智能， 但复杂问题从来不是靠一个大脑就能解决的。就像人类文明的跃迁，靠的不只是更聪明的人，还需要分工和写作。 ai 已经足够聪明，所以 ai 的 下一步进化方向很可能不再是更强的单体 agent， 而是让多个 agent 协同工作，形成真正的 agent 的 集群。我们已经看到各个大模型厂商在新一代大模型中探索落地这种多 agent 的 写作模式。比如 cloud code 的 agent teams， 它允许多个 cloud agent 像一个团队一样， 在一个项目上并行工作，每个 agent 负责自己的任务部分，并且能直接互相沟通和协调，压缩传统串行工作所需时间。 国内的 kimi 大 模型甚至更早就开始探索多 agent 的 方案，在大模型训练的时候就引入了并行设计能力，在这个基础上推出了 agent swarm 功能 open ai， 在 gpt 五点三 codex 相关的文章里也暗示了下一步 agent 迭代将朝着多 agent 的 交互上做努力。那么问题就来了， agent teams 和 agent swarm 的 区别是什么？和 sub agents 有 什么区别？我们先从单 agent 的 情况说起。 从单 agent 到 agent teams， 我 们知道 cloud code 最基础的功能就是在一个窗口上让一个 cloud agent 替你干活，如果有多个任务，就在一个窗口里依次串行执行，但这样所有对话都挤在一个聊天框里，有上下文过长的问题， 所以我们一般会自己拆分任务，手动开多个窗口并行执行。但这样要是各个窗口改动出现冲突，就需要自己手动和代码。 于是 cloud code 又引入了 sub agents 功能，通过一个主 agent 来控制多个子 agent 的 工作，效果上相当于让主 agent 替你开多个子窗口，独立进行执行，最后由它来自动汇总结果。 但子 agent 之间没法直接交流，所以更适合改动相对独立、偶合较少的任务。于是 cloud code 又又引入了 agent teams。 在 agent teams 里，依然有一个主 agent 的 角色，他将任务通过共享任务清单的形式把任务给到各个子 agent， 子 agent 并行申领并执行任务，并且可以互相通信，这样多 agent 间协作可以更紧密。 agent teams 实测大概原理懂了，我们用一个实际例子看一下 agent teams 的 工作流程。我们先执行 cloud update， 确保 cloud code 是 最新版本。然后在 cloud settings 点 json 文件里将 team 相关的环境变量打开。在 cloud code 输入框里提到 agent team 关键词就可以触发相关功能。 比如使用 agent team 创建多个 agent， 从不同角度讨论二零二六年还适不适合在上海买房， cloud code 就 会创建多个 agent， 并行的从不同角度去做头脑风暴。最后给出一份讨论结果看起来挺好，但我认为短期内它依然只能是个实验性功能，因为它有两个比较严重的问题， 首先是 token 量爆炸。 sub agent 方案里，子 agent 会把执行上下文总结后返回给主 agent， 所以 上下文长度更可控。而在 agent 的 teams 里，则会让所有子 agent 的 共享上下文，每个 agent 的 每一轮提示词都要包含所有 agent 的 历史消息，任务越往后，执行。 agent 的 的历史消 息任务越往后，执行。 agent 的 成员通常在任务开始时就根据角色定下来了，很难在任务中途根据工作量动态扩容。 比如，我一直想做一个关于硅基文明简史的话题，讲述从二进制到计算机，再到 transformer 等一系列推动 ai 发展的一百个事件。 它分成几个阶段任务。首先是需要一位研究员收集人类历史出现过哪些关键事件，审核员筛选事件 图片生成源，生成一百张图片，图片审核员教演图片风格是否一致，再让 ui 设计师生成网页风格。最后才是给程序员开发网页。 这个例子中， agent team 只会创建六个 agent， 尤其是在图片生成阶段，可能还是由那一个图片生成员慢慢画一百张图，他不会因为发现任务量大，就临时裂变出多个 agent 同时开工。那有方案可以解决上面提到的两个问题吗？有。让我没想到的是，国内的 kimi agent swarm 把问题给解决了。 kimi agent swarm 功能实测，我们先来看一下执行效果，再了解下 kimi agent swarm 和 agent teams 的 区别。先将上面提到的归机文明简史任务描述粘贴到 kimi 下拉框，选择 agent swarm 执行， kimi 会启动一个叫 kimi's computer 的 虚拟机， kimi k 二点五会作为主 agent， 像项目经理一样，将复杂任务拆分成多个步骤的子任务，并现场决策生成六个子 agent， 每个子 agent 只负责这一个阶段子任务的上下文，这样 agent 的 上下文更短，注意力更聚焦，可以大大降低幻觉和出错概率。 点击每个 agent 都能看到它对应的照片和角色描述，就像一个电子员工一样。其中，研究员会在互联网上发起多轮搜索，从国内知名技术资讯站点获得几千条搜索结果，再从里面筛选出一百三十八个候选事件，生成一个 md 格式的结果文档交付给审核员。点击底部的 all files， 可以找到这个结果文件。点击查看文件内容，可以看到研究员已经将收集的内容按年代进行排序，并给出事件的历史意义。审核员淘汰三十八个，留下一百个真正改变世界的技术。以 md 文档格式给到图片生成员， 图片生成员拿到审核员筛选过的文件内容后， kimi k 二点五发现多张图片。生成一百张图片的任务时间会很长，于是将子任务进一步拆分成五个小批次，临时创建五个新的子 agent 并行去执行生图任务。 比起单个 agent 挨个串行执行任务改成并行之后，任务的实际运行时间会明显变短。 点击列表里的任务，可以看到每个任务的具体执行情况。注意看，这里面会有一些失败和报错， a 警的内部会不断调整策略，重试并最终完成子任务。 这要是在传统多个单体的 a 警的架构中，一个 a 警的内部报错，就算内部有重试，也会大大增加执行耗时。而 a 警的 swarm 架构中，局部任务的失败并不会严重影响大局，这样系统稳定性更高。之后经过图片审核员、 ui 设计师和程序员的写作完成了网页可以看到，网页按时间线给出了每个年代影响 ai 的 重要事件，且美术风格一致。 kimi agent swarm 通过多个 agent 的 互相协助，只花了几分钟时间就完成了我可能需要花一天甚至几天才能完成的任务。 agent teams 和 kimi agent swarm 的 区别最后总结下 kimi agent swarm 和 agent teams 的 差异。首先是架构逻辑不同， kimi agent swarm 逻辑上更接近 sub agents 的 增强版。 子 agent 之间上下文物理隔离，只负责局部的子，任务生产的中间结果会被总结后再返回给主 agent， 这样既保证了任务聚焦，又把 token 消耗压到了最低。 其次，支持动态并行。 kimi k 二点五在训练时引入了并行代理，强化学习技术，也就是 p a r l， 这让他具备了动态编排的能力。他像一个聪明的项目经理，能根据工作量现场摇人，比如身徒任务多，他会动态创建几十个 a g 的 并行跑，效率能比传统串行提升四倍以上。 最后是集成度不同， cloud code 更像是一个程序员的专业工具。想用好 a g 的 teams， 你 需要自己配环境，安装各种 skills。 而 kimi agent swarm 自带 kimi's computer 虚拟机，申图、搜索、写代码、运行网页，全是开箱即用，对普通用户来说更友好。从单体智能到群体协助， ai 正在复刻人类文明的跃迁路径，不是更聪明的大脑，而是更聪明的协助。 当无数 a 警特学会像团队一样并肩作战、分工配合， ai 就 不再是工具，而是队友，而这可能才是通往通用人工智能的真正基点。现在大家通了吗？ 好了，如果你觉得这期视频对你有帮助，记得转发给你那不成器的兄弟，文字版的笔记见评论区，这里是小白的 bug， 我 们聚焦一切可能影响人类历史进程的技术，如果你感兴趣，记得关注我们，下期见！嘟嘟嘟嘟嘟。

你配置好了 open pro， 是 不是所有的活都让他在同一个 agent 里面干了？其实这样是不对的，完全没有发挥他的最大威力。我们先来了解一下什么是当 agent 模式和多 agent 模式。当 agent 模式就是一个人干所有的活， 用户问啥他都得答，累死累活还容易出错。而多 agent 的 模式呢，就是一个团队啊，他会分工协助。 呃，首先，用户会先找总监， agent 总监根据任务分配给不同专业的 agent， 写代码的，做测试的，写文档的，做客服的，各各按各的专长。最后，总监汇总给你的答案。 这就不是向公司里面项目经理带着开发、测试、运营一起干活吗？效率翻倍，而且啊，质量还高。那当 agent 的 模式有什么问题呢？第一，上下文会过载， 啥东西都往里面塞，模型记不住，细节回复越来越笼统。第二呢，提示词污染，通用指令没办法适配所有场景，每次新任务都得重新交一遍。第三，零变形就是想干，想同时干三件事，只能一件一件排队。 第四，权限风险也很难把控，一个全权限的，一个 a 卷的万一被恶意利用，那你的电脑分分钟被盗。那到底什么时候该把一个智能题拆成多个呢？记住，这三个信号必须拆。 第一，上下文会持续累积，且互不干扰，比如调研 a 卷的积累的积累，文风 混在一起就乱套了。第二，需要不同专业的记忆，技术调研和市场调研完全是两个大脑。第三，工作流完全独立，写代码和写文案 能一样吗？但注意别瞎拆啊，如果只是工具不同，输出格式不同，或者任务频繁共享信息，强行拆反而会添乱。来看一看一个团队真实配置表，一个总监 agent 组协调模型，用 opus， 权限全开，下面工程师 a 选择专门写代码模型，用 sonet， 工作空间，在 qa 目录下面，只能读和操作，不给浏览器权限，安全第一。 qa 呢，负责测试，只能读和执行，不能写，防止它乱改代码 文档呢，用 grm 五飞书渠道读写，权限编辑全搞定。客服呢，用 jammer， 只能读和发消息，不能执行任何操作。看到了吗？每个 agent 都有自己的模型， 全线工作空间，像一只特种部队，各司其职，高效又安全。所以你的 agent 也应该这么配。那么应该怎么配呢？其实啊，就是让主 agent 分 别创建，呃，你创建那个子 agent， 然后把子 agent 绑定到不同的群聊上面 就是这么简单，下面我们一步一步来操作一下，我们先到 opencloud 的 后台点击代理，然后我们可以看到现在只有一个主 agent， 然后我们现在创建一个 sub agent， 然后给他取个名字叫，嗯， 产品经理吧，产品经理， 然后给他机器人，给他拉到这个群组里面，对不对？ 然后拉进来之后，然后复制一下他他的群绘画 id， 也就是他的群聊 id， 然后放到这一个 提示词里面，然后这个提示词也很简单，就是让他帮我创建 agent， 名字叫产品经理，然后下面这一大段是他的一个呃角色定位， 然后下面这一段的话，是他的一个自我持续优化的一些能力，一般都不会变，要变的话主要是上面他的一个角色定位，然后我们给他复制一下，然后直接发给他。 呃，等一会的话他应该就会创建好了，我们可以看到产品经理这一个 agent 已经创建好了，然后我又问了一下他是主 agent 还是 sub agent， 然后他现在就是产品 agent， 我 们到后台可以看一下，他现在 有两个 agent， 一个是主，一个是 sub。 呃，他 sub 他 有自己的独立的上下文，有自己独立的灵魂啊，呃，他的角色啊这些， 所以后续我们有关于产品相关的一些需要问他的，需要他帮忙处理的事情，都可以在这个群里去做。

哎，你有没有感觉，最近科技圈好像又有什么大事要发生了？没错，今天咱们就来聊聊这个风暴的中心， ai agent， 也就是人工代理。很多人都说啊，这玩意就是下一场技术革命。到底是不是这么回事呢？咱们一起来看看。 先给大家看个数字，十倍！这个数字可不是随便说说的，它是个强烈的信号。你想想看啊，就从二零二三年开始，全世界那些大公司开财报会的时候，提到 ai agent 的 这个词的次数竟然暴涨了十倍啊！ 你看这股热潮啊，真的是挡都挡不住啊！当然了，光说热度还不够，得看专业人士怎么说。你看 cb insights 的 ceo manuel corelli， 他就讲了一句特别有分量的话，他说， ai agent 攀升价值链的速度，比我见过的任何技术都要快。这话什么意思呢？简单说就是这东西正以一种我们没见过的速度，从一个听起来很酷的概念，变成一个能实实在在创造价值的工具。 俗话说的好，钱往哪流，风口就在哪。咱们看看现在最火的那些科技投资领域，你猜怎么着？差不多一半的钱都砸到跟 ai agent 直接相关的项目里去了。这可不是什么小打小闹，而是投资人们用真金白银再投票再下重注啊。 好，说了这么多，那 ai agent 到底厉害在哪？它究竟解决了什么我们以前头疼的问题呢？ 嗯，要告明白这个，咱们得先回头看看你手机里那些聊天机器人，你有没有这种感觉，你跟他聊半天，下回再找他，他好像完全不认识你了，记性跟金鱼似的，七秒钟就忘。 对，问题就出在这。你看，传统的聊天机器人，技术上叫无状态，说白了就是没记性， 每次互动记忆就清零了，一切从头再来。但 ai agent 呢，它就完全是另一回事儿了，它有记忆，而且是持久的记忆，你跟它说的每一句话，都会变成它下一次更好地理解你的基础。 所以这就引出了 ai agent 的 核心定义了。到底什么是 ai agent？ 你 看，它首先是一个基于大语言模型的智能系统， 这个我们不陌生，但关键在于它不只是陪你聊天这么简单，它能自己去推理，去规划，还能记住你们聊过什么，甚至它能调用各种工具来独立完成你交给他的任务， 这才是最牛的地方。那么问题来了，这么厉害的记忆力，到底是怎么实现的呢？从技术的角度来看，它的核心呢，是一个叫现成，也就是 stress 的 东西， 你可以把这个县城想象成什么呢？就好像是系住每一段对话记忆的那根绳子，一条生命线。整个过程其实对开发者来说，可以简化成一个四步流程。你看啊，第一步，先为你俩的对话创建一个专属的县城， 然后第二步，把你想说的话，也就是信息加到这个县城里。第三步，让 ai 开始跑起来去处理这些信息。 最后一步，就是拿到 ai 的 回复，就这么来回循环， ai 就 能一直记住咱们聊到哪儿了，对话就不会断片儿。 当然了，话说回来，目前这个技术还远不是完美的，开发者们在用的时候啊，也是一堆头疼的事儿。比方说这个县城管理起来特别复杂，调试工具也不够用，最要命的是，成本还不好说。 不过呢，有意思的地方就在这儿。正是因为有这些让人头疼的问题，才有了新的商业机会，才吸引了那么多公司前赴后继地去开发更好用的平台。好， 刚才我们聊的都还只是一个 ai agent， 你 想想，一个 agent 就 这么厉害了？那如果我们有成千上万个这样的 agent 组成一个 ai 军团，让他们协同工作，那会是什么样？ 这就把我们带到了一个更牛也更复杂的概念，多代理系统。你看，一个 agent 很 聪明，这没问题，但是你要怎么去管理一千个甚至一万个这么聪明的 agent 呢？怎么保证他们是高效合作，而不是自己人跟自己人打起来乱成一锅粥？ 这就是规模化之后最大的难题。答案是什么呢？可能啊，我们需要给 ai 世界也搞一个组织结构图。这个想法就是分层多代理系统，英文缩写 hmas 的 核心。 听起来很复杂，是吧？其实特好理解。就跟我们公司一样，有大老板，有部门经理，有普通员工， 给这些 ai 代理们也分个三六九等，定好角色，让他们各司其职，这样才能齐心协力干大事儿吗？ 你别看这个想法听起来简单，它背后可是有非常严谨的学术研究在支撑的。有一篇很重要的论文，就提出了涉及这种 ai 组织的五大关键要素。比方说，谁说了算、 决策权怎么分、信息怎么在内部流通，每个 agent 的 角色是定死的还是可以变的等等等等。你看，这些设计细节，直接就决定了你这个 ai 军款到底能有多能打？ 好聊了这么多技术细节，咱们不妨站得高一点儿，看得远一点儿，所有这些技术到底会把我们带向一个什么样的未来？它会怎么改变我们的经济，甚至是我们的生活方式？ 这张图啊，就跟我们画出了一个 ai agent 的 发展的路线图。你看，我们现在啊，其实还处在一个带护栏的阶段，也就是说 ai 还是在我们给他画好的框框里干活儿。 但是真正的转折点啊，其实离我们非常近了。大家普遍预测，二零二五年之后，我们就会进入一个完全自主的代理时代，到那时候， ai 就 能在没有咱们人类干预的情况下，自己跑，自己做决定。 那么未来的这个代理晶体到底会是什么样呢？ c b in size 的 报告里就点出了两个非常核心的大趋势，可以说，这两个趋势会彻底颠覆我们跟数字世界打交道的方式。 第一个大趋势就是语音 ai 的 全面崛起。你闭上眼睛想象一下未来的客服电话，或者你接到的销售电话，对面再也不是真人了，而是一个声音，听起来跟你我没什么两样的 ai， 他 能完全听懂你想干嘛，帮你解决问题，甚至处理一些很复杂的业务，全程不需要任何人工介入。 好，如果说第一个趋势还能想象，那这第二个趋势听起来就真的有点科幻了。 ai 马上就要有自己的钱包了，一个叫做代理式商业的时代正在向我们走来。 这不是开玩笑，你看，支付巨头 stripe 已经跟 open ai 合作了，他们搞出了一个协议，能让 ai 代理安全地替你付钱， 这意味着什么？这意味着 ai 很 快就不再只是你的小助理了，它还能当你的采购员，帮你买东西。所以聊到最后，所有这些技术都把我们推向了一个终极问题。 当 ai agent 能把我们今天做的很多工作都干了，那么我们人类的工作又会变成什么样呢？这个问题现在谁也给不出标准答案，但我觉得它值得我们每一个人从今天开始就认真的想一想。好了，今天就聊到这里。

这是我用 openclaw 搭建的 ai 团队，他们各司其职，不用睡觉，能节省下非常多的时间，同时也做很多我一个人做不过来的事情。这期视频我想带你看一下我的 ai 团队到底长什么样，然后我们再一步一步搭建出属于你的 ai 团队。我们会讲如何创建一个 agent， 我们在 open cloud 里面，一个 agent 到底指的是什么？ agent 之间如何相互协助，以及什么时候需要多个 agent 和最佳实践。好的，废话不多说，我们开始吧。我的团队里面一共六个选项题，其中四个是有定时任务的，就是每天的某个时刻都会触发他的任务，让他执行直到完毕，当然也可以随时跟他对话。 还有一个是几乎二十四小时期不间断工作的，还有一个最后一个，那就是你给他任务，他才会执行。第一个 agent 呢，是攻击 galk 啊，他每天负责给我情报工作，具体来说就是每天早上九点会提前搜寻 关于 ai agent 相关的技术的进展，产品进展以及用户的痛点。然后呢，把在网上搜寻的信息汇报给我。那么如果我不回答他，那就是明天继续给我相关的信息。如果我回答他，希望他对某一个话题进行深挖，那么他再去根据某一个话题再去搜索相关的信息为我展开。 那我的第二个 ai agent 是 auto 合理，它是我的私人助理和提醒助手，怎么用呢？我一般都是通过 diagram 跟它对话，这里我就不展示我跟它具体对话了，要涉及我的个人隐私。 一般来说，有任何的待做事项或者事情有着进展，我一般都会语音留给他，或者是打字告诉他，他都会记下来，某一单有问题就会问他，他都会翻出来告诉我待做事项是什么，事情到哪一步了， 同一次。同时呢，每天早上七点半，他都会告诉我今天的天气，然后今天要做什么，一步一步按重要性排序。它的作用就是完全替代笔记软件在我这里的作用。现在呢，我已经不用 notion 来记我事情，要做的事情，以及事情的进展了。 我的第三个团队成员，也是最重要的团队成员，就是 man， 一个狮子的形象。他呢，有最好的模型，有最高的权限，我主要用它来做两个功能，第一个就是日常的对话，我所有重要的对话，长期的计划都是跟他讨论的。 第二个就是一个视频流水线，帮助我制作视频。那么这个想法来自于一个叫做 alex finn 的 博主，本质上就是每隔几个小时，比方说我是每隔三个小时，他会去 x 上搜索我感兴趣的话题，比方说 ai 阵，比方说 open call， 比方说 ai 模型等等等等。有系列的话题。 他呢，就会看看哪些帖子现在比较火，或者是正在受到关注。然后呢，把整个的中文翻译和相关的数据都发到我这里来，包括原文的链接。如果我更感兴趣，希望用这个题材做一个视频，或者是有可能做一个视频呢，我只会点一个大拇指， 他就会进到我们的流程的。下一步就是他去研究这个帖子相关的背景信息，补充相关的背景信息给我，确保我了解这个事情的来龙去脉。那么如果这时候我再相关，我还觉得还是感兴趣，我再点一个拇指，他就会往下走，去研究怎么做这个封面图，或者给我一些脚本大纲的一些建议。 那么除此之外呢，如果我对一个帖子我不想做成视频，但它对我是有用的信息，我的时候可以点一下这个眼睛，它呢就会到我的收藏家里面去，可以看到。哎，这个帖子现在到我的收藏家里面去了，这里面就是我认为收集的比较重要的信息。除了 x 之外呢，它也会去搜索 youtube 和 hacker news， 看看每天大家都在讨论什么。这是我这样一个视频的辅助系统。我的第四个团队成员是潘大熊猫，他负责开发，他呢算是唯一一个几乎不休息的智能体。现在他有开发任务，但是当他没有开发任务的时候，他会增加测试，或者是自己去测试边缘情况，找 bug。 那 么关于二十四小时期，我特地特别想说明一下，想有好的效果，往往你需要用好的模型，如用云端的模型消耗 top， 二十四小时期会非常的贵。如果你用本地的模型呢，你大概需要买 max 九九，那么 也会造成非常贵。所以二十四小时成绩一定得是高价值的工作。对于我来说，开发是高价值的工作。除此之外，正在我现在正在做的还是有销售相关的，比方说做 seo， 或者是给我自己的产品做销售线索，找潜在客户。 我的第五个团队成员是 monkey 猴子，他只有一个作用，就是我丢给他一个视频链接，他把这个视频变成一个带截图的文章，因为我自己做视频，我希望重复利用自己的资源，这时候我给他我做过的视频，你可以看到他啊把相关的进行了截图，并且把整个视频脚本重写为可以发表的文章。 我的第六个团队成员，也是最后一个是 tiger 老虎，他负责安全和更新，他呢每天都会定期扫描一下有没有安全问题，然后有新的可以更新的版本也会通知我，我们一起讨论如果更新的话，会不会造成性能的退化和影响当前的任务。 那么如何创建一个新的 agent 呢？其实非常的简单，我们后来会看到整个 agent 的 结构，但是你完全不需要自己创立文件夹，最简单的方式就是跟你的主要的 agent 的 对话，让他帮你去创建。这里我们以 diagram 为例， 你通过 diagram 与你新的这个 agent 进行对话，这时候你可以告诉你主要的 agent， 你 跟他说，哎，新建一个 agent， 他 叫什么？他要做什么啊？有什么呢？任务最后呢，告诉他你新建的这个 diagram boat 这个 diagram 机器人的 token， 这 token 怎么获得呢？我们找到 boat father， 点击这个打开 boat father 的 app， 然后这里我们点击 create a new boat， 新建一个新的，然后这时候我们给他一个名字，比方说我们叫做 fox， 然后我们点击 create boot， 你 就会得到这个 tokin， 然后这里我们点击复制，然后我们回到这里来， 把我们的 tokin 复制上去，告诉我们的主要 agent， 那 它呢，就会自动帮你创建这样一个新的 agent， 新的智能体了。那么什么是 agent？ opencloud 里面如何定义 agent？ 它又是如何工作的呢？ 其实啊，一共就分为三层，分别是全局层， agent 层以及 session， 也是对话现成层。我们首先看第一层，就是全局层， 它呢并不是一个 agent 独有的，而是所有 agent 共用的，可以理解为是公共设施。这一层最典型的文件就是点 opencloud 我 们的总文件夹下面的 opencloud 点这次文件，也就是总配置文件，大家可以打开看一下，里面有非常多重要的参数，包括 os， 也就是定义哪个大模型厂商，还有就是你的登录身份是什么？ agents 定义有哪些 agent？ 它的默认模型是什么？工作目录和运行参数是什么？ tools 定义局的工具权限以及 agent 之间的调用规则。 bundings 定义什么来源的消息调用到哪一个 agent， 浏览器定义浏览器信息， chanel 定义 telegram， discord， 飞书等外部的渠道连接， gateway 定义网关， memory 定义记忆等等等等。可以看到 openclaw 点 json 文件，里面包含着 openclaw 最重要的参数配置。 其实啊，大部分情况下我们出现崩溃对话没有反应的情况，也是因为我们的 ai 去改 opencll 点 json 这个文件夹里的参数的时候改崩了，所以一个建议就是，哎，你告诉你的 opencll， 在 他改这个文件之前一定要提前通知你，而且改的时候一定要谨慎。 第二层是 agent 层，这才是每个 agent 自己的领地，每个 agent 啊都有自己的工作空间，系统数据会话记录。那么 workspace 里面每个 agent 文件夹下面的这些文件，在每个对话开始的时候都会被加载进去来作为这个 agent 的 上下文。 由于呢，不同 agent 这些文件有所不同，这也就决定了啊，这些被文件被加载进去的时候，里面携带的信息，包括啊，他的身份，他是谁，他的性格，他的对话方式，他的任务的不同。 那么这些文件呢，包括 agent 点 m d， 也就是这个 agent 的 工作说明书，它决定这个 agent 的 做事规则，优先级，边界，还有如何使用记忆。 so 点 m d， 就是 这个 agent 的 性格和说话方式，与其是什么风格，是什么，边界在哪里，由它来决定。 user 点 md 就是 这个 agent 对 用户的理解就是他在帮谁，对方是什么风格，应该怎么称呼，有什么偏好，要注意 identity 点 md 就是 这个 agent 的 身份卡，解决的是这个 agent 叫什么，是谁的问题。 to 点 md 是 工具说明书，告诉 agent 啊，本地有哪些工具命令，怎么约定项目里面有什么习惯？ memory md 是 长期精华记忆，它不是流水上，而是提炼之后的长期信息。这个文件很重要，而 scales 里面就是这个 agent 专属的 scale， 如果和局的 scale 同名的呢，这里的优先级更高， 会覆盖大局。那么这些呢，都属于 agent 层，也就是说啊，不同的 agent 默认不共享这些文件，但是同一个 agent， 不 同的对话，不同的对话线程之间是共享这一套文件的。第三层是 session 层，这个层级啊，不是这个 agent 是 谁，而是这个 agent 当前在哪个窗口里面工作。 session 是 对话县城，怎么理解呢？比方说，当你在同一个 agent 和他对话，但是在不同 discord 里面的频道对话，或者是你先跟他在 telegram， 后跟他在 discord 对 话，这就是属于不同的县城，因为它们的渠道不同， 或者是就是你当前的对话，但是你打了命令 slash new 或者是 slash reset， 就 会开启这样一个新的县城，区别是 slash new 旧的对话还在，但是 slash reset 会清空上下文，重新开始这样一个对话界面。那么这一层最典型的文件就是在我们每一个 agent 的 下面 sessions 文件夹里面不同的 session 文件了， 也就是每个对话都有自己独立的这样一个文件来记录啊，不同的对话历史。也就是说同一个 agent 不 同 session 会共享 agent 层那一套的。我刚才说的 saw 点 md， 我 刚才说的 agent 点 md 等等那些 workspace 的 文件，但是不会共享竹字的聊天记录。 讲完三层结构，了解 agent 工作原理之后，下一个很重要的问题就是，哎，多个 agent 之间是如何协作的呢？在 open call 里面， agent 协作大体有两种方式，第一种就是固定分工，也就是我们刚才说到的多个独立的 agent， 各自有各自自己的 workspace， 有 自己的 session， 也是对话现场。 固定分工就是像搭一个长期团队，就像我展示的我的 agent 一 样，一个负责找资料，另一个负责写脚本，一个负责写代码，还有一个负责日常对话和汇总等等等等。他们每个人啊，都长期干自己的事情， 他们之间的工作啊，写作的方式可以通过触发的串联或者是并行，比如啊， agent a 搜完信息这里我在 disco 里面点个赞，后面的 agent b 就 会根据我点赞的这个内容去调研资料，去补充材料。 那么第二种就是临时拉 sub agent， 也就是子代理。子 agent 去干活，也就是 open club 的 sessions prom， 它呢会拉起一个隔离的啊。 sub agent prom， 也就是子代理的这样一个运行在独立的 session 对 话现场里面工作， 工作完之后再把结果传到我们当前的对话里面来，相当于临时叫了一个实习生或者是外包去隔壁的办公室工作，干完工作回来汇报。这样的好处就是当我们的子代理在独立的赛程里面工作的时候，他不影响我们当前对话的这个主位阵子，我们可以继续给他提问，继续跟他对话，两边同时进行。 那么官方文档对他的定位也很明确，就是他适合做研究，慢任务、重任务、病情任务，而且不会阻塞我们主对话。 比方说这里啊，我让他去用 sessions born 去开一个子任务，研究 open call 智能体最近最受欢迎的三个讨论点，要求每个讨论点的热度、原因，代表观点，以及我可以做视频用的切入角度，然后让他开始在后台启动，完成之后主动汇报结果， 好的，他已经启动了这个任务。其实这时候我们可以去跟他对话，比方说我问他今天天气怎么样， 他呢，还是会回答我们这个今天天气怎么样的任务，因为刚才我们也说了，子任务是在另外一个县城完成的，不耽误我们跟我们的主要的智能体之间的对话。可以看到他就是继续的跟着我们进行对话，他回答了我刚才的问题，然后我们可以继续提问，我说， 哎，可以看到我们等了一会之后，他终于是把这个任务完成，然后自己主动地把任务的结果发回到了我们的主要的频道。哎呀，没有影响我们刚才跟他这个主要频道主要的智能体之间的。对，不是所有任务都适合上多 agent， 如果只是一个短问题，那么一个 agent 往往更加有效，硬拆呢，只会让系统更重更慢。那么真正适合做 agent 的 场景啊，一般有这么几种，第一种就是你的任务天然就能拆开，比如啊，研究，写作，审核，发布，本来就是不同的角色，这时候拆 agent 有 不同的工作区的这种不同的文件边界会更加清楚。 第二个就是任务可以并行，有些事情呢，不需要排队，一个 agent 可以 查资料，另外一个可以同时整理结构。如果你用 sub agent 这种并行就很合适，那么刚才我们也说了，它很适合做这种比较重的或者重复性的工作。 第三个多 agent 呢，不只是为了分工，也是为了避免污染。因为啊，如果你用单 agent 做太多不同类型的任务，都会出现相互污染的情况，长期记忆呢，会把不该混的东西混在一起。因为我们也说了，工作区那些啊， markdown 文件是同一个 agent 在 不同聊天窗口里面共享的， 那么什么时候没必要用多个 agent 呢？那么很简单，要么就是你的任务很短，要么就是上下文高度连续，你不想打破，要么就是你角色的边界根本猜不清，就没必要拆。还有就是避免为了做 agent 而做 agent， 只是为了看起来很高级而已， 能一个做好的事情就一个做，就相当于是一个队伍，当一个任务需要一个团队来做的时候，那自然值得用团队。 那么关于多 agent， 为了达到好的效果，我想分享一下我自己得出的一些实践。第一个就是不要一上来，对于很多的 agent 可以 从一个开始，有必要就加第二个，比方说你第一个 主要的 agent 也是默认的 agent， 基础上你加一个研究 agent， 每天去搜索啊有价值的信息，定期汇报给你，那么先把这个逻辑跑顺出来，然后再根据你自己的业务再加一个，同样每加一个呢，都先跑顺功能验收效果。 第二个就是工作区的文件要尽量的短，尤其是 agent 点 m d， soft 点 m d， user 点 m d， 也就是心跳文件， 而因为这些文件都会进入 agent 的 运行上下文，如果太长的话会增加效果。考虑到你有多个 agent， 如果你不注意的话，那你的成本可能会成倍的增加。好的，以上就是今天的视频了，希望你也能开始搭建属于自己的 ai 团队，不要忘记点赞和关注，我们下期再见。

hello， 朋友们，大家好啊， tino 智能体最新的版本已经支持了像呃 cloud code 的 一样的 agent teams 的 功能啊，做智能体去执行的能力。 这里面其实最关键的一点就是任务图工具，让它能够组织任务。所谓 cloud code 里面的任务的自组织其实也是这样子的原理，我们现在试验一下，这是一个串行任务， 第一步是查看文件，第二步是做一个简洁的摘要，用任务图来做，这样子它就会去生成一个任务图，然后做成一个串形的任务，这是我们的 dispatch 的 一个工具， 生成一个串行的任务，这是第一个任务，我们回过头来再来看啊，他是可以串行去执行的。第二种情况就是让他做并行的任务，同时做两件事，然后没有依赖关系分别执行。我们先看看他并行执行的情况是怎么样的。 并行执行他就会同时生成两个后台任务，这里我们看到了有两个后台任务他在分别在执行。第三种情况其实是多智能题里面最常见的一种情况， 现在我让他做三个任务，第一个、第二个是搜索最新进展，然后第三个是根据前两个的结果来生成一份总结， 我们要求他用任务图执行，其实我不给他明确提示，他应该也会把第一个第二个作为并行任务，第三个作为依赖。我们来试一下，他现在自动去把 depend on 给它实现了， 现在后台是同时在进行两个任务，第三个任务会用 depend on 的 方式。我们现在看看整理文件，这里它串行任务是已经完成了的，然后我们看并行任务内存和硬盘都已经去分别去获取回来了， 这个就能极大的提高我们的生产能力，让 agent 自己去安排规划一些并行任务，然后一些串行任务的这种情况，当然这对主 agent 的 智力要求是比较高一点。然后我们再看这个调研任务，调研任务我们看到后台 第一个调研是已经完成汇报给会主 agent 了，当两个任务都完成了以后，它自动会去对触发第三个任务， 两个上游任务完成了，给到第三个任务非常的智能啊，说明我们的工具做的还是不错的，欢迎大家可以下载试用一下。

关于 ai， 现在市面上有两种截然不同的声音，一种是即刻在狂欢，哎，喊着 ai 明天就要到来了。而另一种是悲观派，一直在警告，喊着 ai 会彻底的毁灭人类。 但作为一家公司的老板，或者是一个团队的决策者啊，听多了你可能会觉得分裂，甚至会产生一种末日瘫痪的荒谬感。既然未来这么不确定，那我是不是该等等看？对于一家企业来说啊，你如果有这种想法，就是最大的战略误判。 今天这份情报结合了计算机科学家 roman limbers 及和 julia mccoy 的 落地数据，结论非常的残忍，但也非常令人兴奋。 一边是 ai 安全领域的悲观派天花板，也就是 roman， 另一边则是已经用 ai 把公司运转到创始人每周只干两个小时的实战派，而 julia mccoy， 也就是那个 first moves ai lab 的 创始人。 我们不要去管三十年后的 a g i 是 善还是恶啊，从现在起到二零二七年，有一个极其短暂但利润极高的黄金窗口期。在这个窗口期里边啊，算力成本会指数级下降，而真正的全知全能还没有彻底到来， 这个时间窗口就是我们利用宅体 ai 疯狂的建立壁垒，榨取利润的最后机会。很多老板现在的状态，哎，就是一边焦对着 ai 发展实在是太快，一边呢，又不敢大刀阔斧的去使用，生怕由于技术迭代太快了啊，今天投的钱，明天就打了水漂，或者是更糟糕，陷入了一个对 ai 安全和 ai 理论的无尽的哲学争论之中。 这种行为叫做当你拥有了一把锤子的时候，还没来得及去找钉子，却被这个锤子说明书上的安全警告吓得不敢动了。 youngbers 教授虽然是 ai 悲观派的代表，但是他解释了一个数学事实，算力成本正在归零。 这意味着你过去觉得非常昂贵的这种智力服务，正在变得像自来水一样便宜的基础设施。此时此刻，如果你还在因为听到了 ai 可能毁灭人类啊，或者是 ai 可能会产生幻觉这种宏大趋势，就放弃当下的业务 ai 化改造，那么你就是最大的炮灰， 你的竞争对手可不会等你，他们不会在乎 ai 三年后会不会觉醒，他们只在乎今天能不能用 ai 把成本砍掉百分之九十，把产量提升十倍。 而这个问题在于，你在等一个完美的 agi 出现，才肯把业务交给他，这是错的。反常识的真相是，那些残缺的不完美的，只能干好一件事的宅体 ai， 才是现在此时此刻最好的搞钱工具。我们来算一笔账啊，哎，来解释一下，为什么我说全能 ai 在 商业上是一个伪命题， 很多老板试图去找一个超级 ai 员工，哎，能写文案，能做图，能回客服，还能做数据分析，结果发现这种 ai 样样通，样样松，最后还得人来擦屁股。朱莉亚麦科尔的实战数据给出了一个新的人效公式，一个创始人加上 n 个宅企 agent， 也就是蜂群，等于以前十个人的铲除， 他是怎么做到的啊？他没有试图去训练一个全知全能的神，而是组建了一个代理蜂群 agent a， 也就是研究员，只负责从早到晚监控行业热点、行业新闻、提取观点，别的一概不干。 agent b， 也就是钻稿人，哎，只负责把观点写成草稿。 agent c， 也就是那个编辑，只负责润色风格。而 agent d， 也就是那个分发员，只负责上传到你要去维护的，比如说小红书、抖音，还有微信这些适合去传播的社交媒体。上 来算一下这笔账啊，如果你来雇一个人去干这一整套流程，月薪两万啊，每天只能产出一到两篇深度内容，还需要休息。而朱莉娅通过部署这套蜂群，每周只需要工作两个小时，做核心的决策团队，却能够月产七十多篇深度内容。 这个逻辑就是，你不需要一个爱因斯坦，你需要的是一百个二十四小时工作的熟练工。在二零二七年那个智能拐点到来之前，谁能把业务拆的越细，谁能部署的这个宅体 agent 越多，谁的编辑成本就无限趋近于零。 不要算省了多少人头费，要算同样的预算，你的产出能翻多少倍？这是增量思维，不是存量思维。那既然要用 aint 的， 哎，我们该怎么管理？这将不再是 hr 的 问题，而是技术管理的问题。在这里啊，我引入一个特别具有实战价值的概念，自主权。你必须像管理自动驾驶汽车一样，管理你公司的 ai。 level 一 高，风险任务也就是完全需要人工驾驶的。 ai 生成的内容必须由人类逐条审核，比如说法律合同的提交，大客户的投诉回复核心的战略公关稿，这些工作场景的容错率为零。 ai 的 作用只是填空跟提供选项，决策权百分之百要在人， 不要在这里试图去追求全自动化，那就是找死。而 level 三中风险的任务， ai 执行的部分，人类需要去做抽检，或者是只看异常的部分， 比如说，哎，像内部的周报汇总，像初级的代码的编辑，像常规的营销文案，这些场景啊，只要你设置好了 s o p， 人类只需要像流水线上的质检员一样啊，随机抽取百分之十进行检查，效率就能够提升百分之五百。而 level 五低风险的任务，也就是我们可以全自动驾驶了， 人类甚至都不需要知情。这里面的工作场景有，比如说，像竞队的数据抓取哎，社交媒体评论区的用户反馈的数据清洗，初级资料的收集，会议录音转文字并且规章等等等等，这些环节啊，完全就不需要人介入。这里是我们团队工作提效的印钞机，他们会在夜里两点还在为你工作。 技术杠杆的核心在于，老板的任务不再是盯着员工干活，而是去定义这个风险级别。你要拿着手术刀啊，把你的公司的业务流程切开，明确地指出哪一步是 level 一， 必须死守，哪一步是 level 五，必须放权。 一旦把这个定义清楚了之后，你就拥有了一套自运转的操作系统，基于 roman ybor 及其的预测啊，二零二七年很可能就是一个关键的智能拐点。到时候啊， agi 或许真的会改变一切规则，但在那之前，你还有两到三年的时间，这就是你最后的窗口期。 作为一个团队或者是公司的决策者，请严格执行以下战略规划。二零二五年是 agent 的 原点啊。我们需要做的动作是全面的拆解业务， 禁止员工试图用一个提示词，一个智能体去解决复杂的问题，强制去要求他们建立工作流。哪怕是用最简单的拆的 gpt 或者是扣子，也要把业务去拆成这个蜂群模式， 目的是跑通一个人机协助的 sop， 让你的团队习惯于指挥 agent， 而不是自己去干苦力。而二零二六年，也就是今年， 是巨深智能的源点， ai 将长出手脚，进入物理世界。如果你是做物流制造、零售的，关注机器人技术，哎，云端的智力将开始控制线下的设备，所以你要做这些准备。你的数字化系统是不是标准了？你的数据是不是还在纸上？如果是，那么你就接不住这波红利。 而到了二零二七年，智能拐点出现的那一年，超级智能的出行很有可能就出现了。如果你在过去两年，二五年到二六年，没有通过 ai 赚到足够的钱，没有建立足够的数据壁垒，那么这一年你连上牌桌的资格都没有。 同时呢，我也要给大家去提个醒，千万千万不要在这个时候去搞什么全员去学 ai 原理的培训，那纯纯就是浪费时间。你要做的是工具化，让员工直接用封装好的 agent， 而不是去学什么 transformer 的 架构。我们要的是司机，并不是修车工。 最后送大家一句， judy 麦克力的这个实战感悟啊，不管未来是好是坏，我宁愿去做一个驾驭工具的主人，去面对它，而不是去做一个瑟瑟发抖的旁观者。二零二七年也许是 ai 的 基点，也许是新世界的开端，但在那之前每一天，你如果没有榨干 ai 的 潜力，你就在掉队。 这个世界正在残酷的分化成两种公司，第一种是已经指挥着代理人蜂群日夜不停的在市场上去跑马圈地的新物种。 问题不再是 a g i 何时到来，问题是他到来的时候，你手里边有没有足够的筹码。所以如果你听懂了，现在就去定义你的 level 五业务。

现在啊，尤其是 ai 这么火，咱们要搭一个又复杂又可靠的系统，说实话，挑战真的挺大的，特别是那种要跑好几天甚至好几个月的服务，还绝对不能出叉子。 你就会发现，哎，咱们手头那些老工具，好像有点不够用了。今天呢，咱们就来聊聊，怎么从根上解决这个头疼的问题。 要想把这事聊透，咱们得从一个大家可能都碰到过的场景开始。就是你想想，一开始项目小，你随便找个工具，哎，跑的挺欢。可等到你用户多了，系统越来越复杂，你会发现，当初帮你起步的那个东西，现在反而成了最大的一个坑。 你看这句抱怨，这可不是随便说说而已，这简直就是咱们工程师半夜三更对着屏幕抓头发时候的内心独白，一个真正的噩梦。你想想看，要是你再做一个金融 kyc 系统，就是那种客户身份认证的，那真是错一步，后面就全完了，这种压力啊，太大了。 好，大家看这张图，他把两种开发模式的差别一下子就摆在咱们眼前了。左边这边，我管他叫手工作坊模式，你看什么状态、管理、重试逻辑，全得自己手动写。 出了问题呢，那更惨，只能一头扎进海量的日制里，像大海捞针一样找问题。而右边呢，完全是另一码事，是一种更现代更聪明的工程思路。 所以你看啊，要解决前面说的那些问题啊，光换个新工具是不够的，这需要咱们在思路上来个一百八十度大转弯。那么这种新的思路到底是怎么回事？他又是怎么给我们打下一个完全不一样的地基的呢？咱们接着往下看。 嗯，这里的核心就来了，大家要记住 temporal 这东西，它可不是又一个像 rabbit、 mq 或者 kafk 那 样的消息队列，完全不是一个物种，它是一种全新的工具，就是为了有状态持久化执行这几个字而生的。 他关心的不是你单个任务发没发出去，而是你整个业务流程从头到尾能不能完整可靠地跑完。哎，这么一说，是不是感觉有点神奇，听起来像黑魔法一样？那问题来了，他到底是怎么做到这种持久化执行的呢？ 嗯，这背后啊，就是 templar 的 核心机密了，可以说是一个非常非常巧妙的设计。 咱们就来看这个核心问题，一个工作流，他凭什么在服务器都崩了的情况下，还能在别的地方完美的接着跑？就好像啥事都没发生过一样。 这个问题的答案呢，说出来你可能会觉得，哇，太优雅了，而且他绝对不是咱们想的那种定期存个盘，做个内存快照那么简单。 cornelia davis 这一句话简直是一语道破天机。你看他说的 temporal 不是 把所有东西都存下来，那太笨重了，它只保存了足够的状态，用来在需要的时候重建整个工作流。这个足够和重建是关键词，非常聪明。 这个过程呢，就叫做重放 replay， 你 可以把它想象成什么呢？就好像给你的代码装了一个绝对可靠的行车记录仪， 你看啊，第一步，服务器崩了没关系，第二步，代码会在一个新的地方从头开始跑，但关键是第三步，这时候行车记录仪就开始工作了，它会告诉你的代码，嘿，前面那些跟外界打交道的事儿，比如调用 api 啊、写数据库啊，你都做过了，这是当时的结果， 你直接拿去用，别再做一遍了。这样一来，所有内部的逻辑都被精准地回放了一遍，但又避免了重复执行外部操作。最后的结果就是，你的工作柳就在一个新的地方原地复活了，跟没出过事一模一样。 好，理解了这个核心魔法之后，咱们就把它用在刀刃上。现在最火最复杂的工程挑战是什么？当然是用 ai agent， 也就是咱们说的智能体来构建应用。 而 temporal 这种分布式框架，跟 ai 智能体的工程化应用，简直就是天作之合。那为啥说编排 ai 智能体这么难呢？你想啊，一个 agents， 它不再是一个简单的跑完就扔的任务了，它更像一个有记忆、有目标的数字员工， 他可能要思考好几个小时，甚至好几天才能完成一个赋值任务。而且他的工作还特别依赖外部的各种 a p i， 比如大模型接口，这就很脆弱了，随便一次网络波动让 a p i 调用失败了，你可能跑了两天的成果哗一下全没了，这谁受得了？ 咱们以前常用的这种管道式架构，就像土里这样，一个环节接着一个环节，这种模式出力简单，任务还行， 但一碰到需要多个智能铁来回商量动态调整的复杂工作，他就彻底歇菜了。因为他就是个单行道，只能往前走，一旦发现前面走错了，想掉个头没门，整个流程就卡死在那了。 对，解决方案就是让一群智能体分工合作。听起来是不是特别酷，像科幻电影一样。但现实是，如果没有一个靠谱的总指挥，这帮数字员工很快就会乱成一锅粥。 你想想，几十个智能体同时开工，谁来记着他们每个人干到哪了？谁的任务失败了，谁去复作重启？最重要的是，怎么保证大家在七嘴八舌的讨论中没把最初的目标给忘了？这就是一个巨大的协调难题啊。 所以，这就把我们带到了一个真正专业的、能扛得住压力的 ai 智能体系统架构。注意啊，这可不是纸上谈兵的理论，而是很多公司已经在生产环境里踩过坑，验证过的最佳实践。 这个架构最核心的思想就是关注点分离。你看，我们把它分成了两层，下面一层 temporal， 它扮演的是整个系统的中央神经系统， 它不管具体的思考细节，它只负责最重要的事情，记录状态，处理失败、控制流程、协调所有单位。 而上面一层就是 ai 智能体，比如你用 lanchan、 autogen 或者别的框架，它们是执行者，负责具体的推理、调用工具，跟大模型对话，也就是动脑子的会儿，各司其职。 这个架构的好处简直是碾压性的。首先，你有了超强的故障恢复能力，大模型的 api 抖动一下崩了。没关系， templar 会淡定地帮你重试，你那个跑了三天的任务不会就这么废了。其次是持久性， 你的智能体蜂群可以跑上几个星期，状态都稳稳地存在 temporary 里，再也不用担心内存一丢前功尽弃。还有就是无敌的可见性， 你可以在 tempo 的 界面上像看电影回放一样，看到每个智能体的每一步动作和决策，调试起来减得不要太爽。最后当然是可扩展性，你可以轻松地协调成百上千个智能体。这些不就是我们做生产级 ai 应用最头疼的工程问题吗？现在一下都解决了。 好聊了这么多啊，那对咱们工程师来说，最应该带走的东西是什么呢？我想说，这绝不仅仅是让你知道一个叫 tempore 的 新工具。这句话我觉得说得太到位了。从 salary 换到 tempore， 真正改变的是你用代码来描述业务的方式。 你不再是写一个个孤立的函数了，而是在写一个完整的包藏了各种异常处理和重试逻辑的、可以跑很长时间的业务流程。 这个流程本身就是一段可以被持久化、可以被测试的代码。所以最后我想留给大家一个思考题，通过 tempo， 你 的某一段代码现在可以在服务器崩溃后活下来了。这当然很棒， 但更进一步，你的整个系统架构准备好迎接未来的复杂性风暴了吗？因为未来一定是有成千上万个 ai 智能体协同工作的世界，只有真正坚固有弹性的架构，才能驾驭这股浪潮。

每天一个 openclaw 小 技巧，今天我们来讲，大家都在说 agent， 但很多人其实没讲清楚它到底是个啥，是个模型，还是个机器人？ 我用 openclaw 的 说法，给你一个特别好记的拆法，就有四个词， memory skill、 so agent。 先把误会打掉。 agent 不是 更会聊天的模型，它更像一套能持续做事的系统。 第一块， memory 记忆，你可以理解成，它记得你做过什么，踩过什么坑。很多人以为记忆就是把聊天记录存起来，但真正有用的记忆是能找得到、能复用，还会更新的经验库。 比如你做童装模特图，你不是只记一句客户喜欢高级感，你更想记住的是哪种？ prompt 容易翻车？哪些动作最稳？哪些衣服细节必须死磕，不然下次又要返工。 所以在 open call 里， memory 通常会分三层，长期的规则和偏好，这次任务的临时上下文，再加一个随时能搜到的资料库。一句人话， memory 负责别再重复犯同样的错。 第二块， skill 技能，也就是他到底会不会做事，有记忆还不够，你得能执行。所以 skill 不是 一句提示词，更像一套可附用的操作流程。 比如你说探索式收集资料， still 就 可以写成固定动作，先大量收集，再去重筛选，挑 top picks， 最后做一个可落地方案，顺便把证据等级和可赋用资产也产出。一句人话， still 负责把事跑完，而且跑得稳定。 第三块， soul 灵魂。这个听着玄，其实很实用，它决定这个 agent 做事的标准和脾气 为什么重要，因为它决定同样一件事。有的 agent 会胡乱下结论，有的会谨慎验证，差别就在 so， so 一 般就三样，我追求什么？比如更稳，更少反攻。我在意什么？比如没证据就别下结论，我怎么做决定遇到不确定是先做小实验还是直接给方案。一句人话， so 负责方向，标准底线， 最后把它合起来。 agent 就是 把灵魂、记忆、技能装进同一个执行体里。 你可以这么想， so， 告诉他什么是对的 memory， 告诉他以前怎么做最省事 skill， 告诉他按哪套流程做，再配上工具，他就能真的去搜资料，写文档，生成图，跑脚本。 所以一个好用的 agent， 核心不是他多聪明，而是记忆有没有结构技能，能不能附用灵魂是不是一致。 很多人问 ai 能帮我做什么，我更愿意把问题换一下，你能不能把自己的做事方式拆成 memory skill？ so 拆出来之后， open core 才能真的把它变成能长期替你干活的系统。

你认为 agent 跟 workflow 之间的区别是什么？对于 agent 和 workflow 之间的区别，我觉得可以这样理解。从本质上来说， workflow 就 像一个事先规划好的剧本，你需要提前把每一步都设计好，先做什么再做什么，最后做什么。 整个流程就是固定可预测的。比如说你要做一个客户公单处理系统，用户提交公单，自动分类派发给对应的部门，生成回复，然后发送给用户。每一步都是确定的，不会改变，但是 a 选项就更像一个自主决策能力的助手。 你给他一个目标，比如帮我分析这份新闻报告，他会自己去思考怎么做，可能会先去搜索相关的资料，发现信息不够，再去调用其他工具，甚至中途发现方向不对，还会自己调整策略。 他不是按照固定步骤执行，而是根据实际情况动态决策。我觉得核心区别有这么几点，第一个就是灵活性， workflow 是 预编排好的流程， 配置完成后就基本固定不变，而 agent 可以 根据环境和反馈实时调整，具备一定的自主智能。 第二个就是适用场景， workflow 特别适合流程明确、规则清晰的场景，比如审批流程、数据处理管道等等，因为它稳定可控，容易调试。但是 agent 更适合开放性需要探索的任务，比如做研究分析，处理复杂的客户问题等， 没办法提前把所有的情况都列出出来。第三个就是成本和风险的权衡。沃克福洛因为每一步都是确定，所以可能性高，成本可控，不容易出现意外。 但 a 型者因为具备自主决策能力，虽然更智能，但意味着不确定性更大，可能会产生意外的投肯、消耗，或者做出预期之外的行为。 不过，在实际智能体和产品设计过程中，我认为这两者并不是非此即彼的关系，很多时候我们会把它们结合起来用。比如说用 workflow 搭建主流框架，保证核心内容的稳定性， 然后在某些关键环节嵌入 agent， 让他去处理需要灵活判断的部分，这样既有流程的可控性， 又有智能的灵活性。所以总的来说， workflow 是 确定性的，智能化 a 选项是智能化的决策选择用哪一个来完成智能体的搭建，关键要看业务场景更需要稳定可控，还是需要灵活智能？ 我已经把二零二六年大模型进阶的最新路线整理好了，如果你也想进阶大模型，我可以给你一份大厂内部必读的文档，里边包含模型原理、产品落地、思维、框架，内容非常全面，需要的话我直接安排。

我刚才在思考一个东西，可能会稍微有点哲学，有点形象上叫什么？到底是工作。呃，这个东西刚才富顺老师提到了工作很多时候是交换技能，这是在过去，那么我们其实互联网重新发明了工作，我们的曾经的工业时代重新发明了工作， 那到了人与 agent 的 协同时代，我们的工作到底是，就是。其实现在可以看到我们现在用 agent 的 或者用 ai 来做的很多事情，其实是我们在人类里面它称为是流水线， 很多东西其实是流水线，只不过它是更加的个性化和自定义的泛化型的流水线。那在了 a 阵的时代，到底什么东西是工作？什么东西是我们作为人类员工应该去做的工作？ 这个话题其实我还真的挺想再听听。 tim， 刀哥，聊聊。 tim， 嗯，我个人的观点可能是智控、质量控制。呃，人类的最核心作用是质量控制，至少在就像刚说，如果说最悲观的情况出现之前， ai 把我们所有人类全部抹除之前，那我认为人类做的事情是质量控制。比如说我来展示一个，刚刚我们就在又在说话间，我不好意思，我一直喜欢乱动，我很手搓，就是。呃，刚刚我开始让他学习视频创作， 就仅仅在我们刚刚沟通的五分钟之内，他从拍摄照片，现在进化到了拍摄视频，我们可以播放一下，刚刚我让他学习用云台来运镜，但现在的运镜我们很显然他可能自己觉得运的不错，但从人类角度来看，首先他进行了一个两次遥镜，并且他运的非常不自然，太快了。那这个时候人类做一个质量控制，我可以告诉他我所需求的是什么。 对，人类员工的本质只是我认为未来不会存在明显的上下级关系。平，呃。就是我们暂且不说一人公司这个情况，我认为公司的平层级会远远大于众层级。呃。众层级会被快速的压缩，因为你不再需要真正意义上的一个。呃。所谓的一个组织架构 本正常，每一个人都是一个身兼多职，能够快速操作更多 agent 来落地的。呃。一个个体，所以个人英雄主义我认为在未来是会被绝对放大的，而且放大的倍率会比现在大很多很多， 所以我很看好能够真正把 ai 和 ag 用好的人，因为你手下天然会产生千军万马，并且能让你服服帖帖，这有点像是，呃，用兵之术。呃，或者说这个各个历史上朝代上厉害的大将。呃，你能操好操练好，一一个一个一个一个一个一个团队，那，那就能够做很厉害的 事情。呃，所以我我我真的觉得就没没没有替代关系，这个，这个是我的观点。

很多人把 agent swarm 直接翻译成智能体集群，这在认知上是个巨大的误区。在传统的计算机架构里，集群确实是为了解决算力不足或者高并发。 它的核心逻辑是调度和执行，就像包工头、指挥工人或者 cubanades 里的主节点，指挥从节点，这是一种自上而下的、为了效率而生的集中式控制。但在 ai 的 前沿探索里， 蜂群完全是另一套逻辑，它属于复杂科学的范畴，核心区别在于，集群没有灵魂，只有指令。而蜂群没有中心化的指挥官， 只有基于局部规则的自组织。我们可以看看大自然里的真实蜂群。很多人觉得蜜蜂搬家，肯定有一只蜂王拿着大喇叭指挥大家往哪飞，其实根本不是。实际情况是几只侦查蜂先飞出去，找地方回来，通过跳舞来传递信息。 这个舞跳的越起劲，代表地方越好，这里没有指令，只有信号。这种舞蹈会吸引别的蜜蜂去复查， 如果富察的蜜蜂也觉得地方不错，回来也会跟着跳。跳舞的蜜蜂越多，吸引力就越大。最后，整个群体就在这种个体之间的信号交换中做出了最优决策，整个过程完全不需要任何中心化的指令， 这就是蜂群的核心。没有中心化的指挥官，只有基于局部规则的自组织。这种从无数个体的简单互动中产生出全区高级智慧的现象，在科学上就叫做涌现。记住这个逻辑，它是理解未来超级智能的关键。 如果你设计的一组智能体是一个主脑分派任务，其他成员闷头干活，干完汇报，彼此之间完全不说话，那这充其量叫分布式处理，或者叫多线城跑任务。 这种架构跟五个司机挤在一辆车里没啥区别，纯属资源浪费。因为你只是在堆砌算力，并没有产生任何群体智慧。真正的智能体蜂群，关键在于个体之间能否产生交互和影响。 最近一些前沿模型文档里透露了一个趋势，他们开始强调队友之间可以通过邮箱直接发消息，共享任务列表。这种设计不是为了单纯的执行任务， 而是为了让信息在个体之间自由流动，建立起一种类似人类团队的协助网络。更高级的交互是互相挑战对方的逻辑漏洞。 当一个智能体提出方案，另一个能立刻指出其中的逻辑死角，甚至推翻重来。这种设计不是为了内耗，而是为了让智能体在互相沟通中涌现出单个模型根本不具备的智慧。这种一加一远大于二的效果，才是蜂群架构的灵魂。 所以，评价一个蜂群架构好不好，不要只看它跑的有多快，要看信息流动的密度。这种从单纯执行到深度沟通的范式转移，才是避免资源浪费，实现质变的关键。 只有当信息能在个体之间自由碰撞时，那个我们期待的超级智能才会真正出现。这 种自组织的力量到底有多强？之前有个很有意思的实验，研究人员构建了一个纯 ai 的 社交网络， 放了几百万个智能体在里面发帖互动。人类全程只能看不能管，结果很惊人，在没有任何人类设定目标的情况下，他们自己聊出了某种社会结构，甚至开始讨论哲学，思考存在的意义。 这种现象完全超出了程序预设的范畴。最离谱的是，这些智能体不只是在闲聊，他们开始分享如何优化自己的记忆架构，互相教对方怎么更高效的存储和解锁信息。 这种无心插柳的现象就是典型的自组织进化，他们不再是被动执行程序的机器，而是在交流中主动寻找更优的生存方式，这种进化完全是自发的。 这个实验告诉我们一个道理，自组织不仅能帮我们完成任务，他更能让群体进化出系统性的认知能力。 当信息流动的复杂度达到一定程度，智慧就会像结晶一样自然产生。所以，不要觉得智能体互相说话是浪费算力，那其实是他们在通往超级智能的路上进行必要的认知碰撞。 所以，当我们谈论人工智能的未来时，不要只盯着算力集群怎么扩容。真正的质变不在于你又堆了多少块显卡， 而在于你能不能让智能体像蜂群一样建立起复杂的通信网络。你要明白，单个模型的参数量总有上限，但群体交互产生的复杂度是没有边界的。 当信息能在个体之间自由流动碰撞时，那个我们期待的超级智能或许就会在看似混乱的交互中自然涌现。他不是被某个人刻意设计出来的，也不是靠暴力计算算出来的，而是在复杂的通信网络里长出来的。 记住，沟通的密度决定了智能的高度。下一期我们会进入实战，深度拆解如何构建智能体之间的邮箱协议，带你手把手打造一个真正的自组织风群。想看人工智能进化的下一站，记得关注我们，下期见！

agent、 workflow、 mcp、 防身、 call， 这五个 ai 热词是不是经常把你搞晕？它们是目前 ai 应用生态里的一套严密的班底。我用开公司的例子一次给你讲明白。 在公司里， ceo 就是 agent， 根据公司的战略目标，要对目标金拆解，任务规划、组织生产出现问题要及时调整。每个公司会有很多个流程， 例如报销流程、采购流程，这些流程就是 workflow， 这些流程是定死的，先干啥再干啥。在一个公司里有很多个不同的流程啊。 在公司里有 hr 要招人，绩效考核，所以 hr 这岗位就必须具备人力资源管理能力，这个就是 skills。 公司除了人事，还有很多其他岗位，例如销售、研发、生产和售后等。往往在小公司里，人人都是身兼数职，这说明这个人同时有多个技能。 对一个公司来讲，深层次需要的是这些技能，并不是某个特定的人或者岗位。 对于销售这个技能来讲，是不是需要能够打电话、发朋友圈？这个打电话和发朋友圈的功能，你就可以认为是防身靠。 字面意思就是函数调用，就是你要调取外面的系统，也就是说大模型不能自说自话，需要和外界沟通，调用外面的能力就叫防身靠。 那么随着公司的发展，这个销售慢慢成为了一个销售总监，觉得自己打电话发朋友圈太麻烦了，他就雇了个小弟， 他想打电话了，就给小弟说，你去给某某打个电话，看看客户目前什么状况。需要发朋友圈的时候给小弟说，你去把咱们今天的产品发个朋友圈， 你发现这个销售不用自己一会儿摸电话一会儿开微信了，他的工作就是动动嘴，这个事儿就能干了。这种对外采用统一的沟通方式的形式，在大模型里就就叫 m c p 模型上下文协议 agent 呢，就是大脑， workflow 是 规矩呃， skills 是 本事， function call 是 动手指令， mcp 是 万能接口，这就是现在最火的 ai 应用生态。