第一课：产品形态：从”工具”到”抽象组合”的范式转变
我的理解
本课的核心论点是：Agentic AI 代表着从”提供固定工具给人用”到”AI 自由组合抽象能力生成解决方案”的范式转变。传统软件依赖预设的菜单和按钮，用户须明确每一步操作；而 Agentic AI 抽离出理解目标、获取上下文、调用工具、多轮决策、产出成品这五种核心能力，让用户只需声明目标，AI 即可像编排乐高积木一样动态组合工具与自我纠错，完成从需求到落地的全流程。文章进一步指出，这种高自由度带来的安全与可控性问题催生了”AI 行为仪表盘”、沙箱隔离、权限审计等基础设施需求，使 Agentic AI 产品的设计远非”加个语言模型”那么简单。在后半部分，课程引入多智能体系统，强调其真正的抓手并非特化 Prompt，而是对上下文的”分而治之”：通过 Planner-执行层结构拆分上下文窗口、按角色选配不同成本/性能的模型，既缓解上下文爆炸又优化成本与容错。整体上，本课勾勒了 Agentic AI 从单 Agent 编排到多 Agent 协同的演进路径，为后续讨论技术架构与产品形态奠定了概念基础。
相关链接
- Ch01-L02 Agentic AI的范式转变 —— 呼应本课”从工具到抽象组合”的范式革命论述
- Ch02-L01 三种编程思维 —— 本课引用 Comment/Prompt/Objective-Oriented 三种心智模型说明抽象性升级曲线
- Ch02-L05 对比Devin —— 本课多次以 Devin 为案例讨论计划视图与快速迭代两种产品形态
- Ch02-L06 Cursor配置教程 —— 本课将 Cursor 作为抽象能力组合在小范围体现的实例
- Ch03-L00 引言 —— 本章引言，预告了本课所展开的”抽象能力组合”视角
原文
Lesson 15 of 18 第一课：产品形态：从“工具”到“抽象组合”的范式转变 Agentic AI 用到的抽象能力
在前面的章节里，我们已经从一个相对直观的角度看到了 Agentic AI 的工作方式，也了解了像 Cursor 那样的工具如何通过 Comment-Oriented、Prompt-Oriented 和 Objective-Oriented 这三种模式来帮助我们把 AI 的潜能最大化。对很多刚刚接触这个领域的同学来说，可能还停留在“嗯，这样做确实比以前的 ChatGPT 更高效一点”这样的第一印象层面。可实际上，像我们在第一章里分析的那样，从一条指令直接完成整条工作流，是一场远超出我们想象的范式革命。尤其当我们跳到一个更高的抽象层次来审视，就会发现 Agentic AI 不再只是让我们写代码更爽的“工具”，而开始具备“可以组合不同能力、对外部世界产生真实影响”的潜力，进而形成了完全不同于传统软件的产品形态。
之所以称这是一个“范式转变”，是因为我们不再依赖具体的指令集或脚本语言，而是把 AI 当成一个可以组合若干抽象能力的“抽象生成器”。要知道，传统软件总是倾向于给用户列出一条条菜单、一个个按钮或命令，让用户在这些预先设计好的“固定格式”里完成任务。用户需要很清楚自己点哪个按钮才能实现某个功能。
但 Agentic AI 在本质上先抽离出了五种核心能力：理解你的目标、对话式地获取上下文、去调用外部工具、多轮决策执行，以及产出所需的最终成品。然后根据具体场景，它可以随时组合这些能力——这跟“我写一个 Python 脚本，用 requests 抓取数据，用 matplot 绘图，再在命令行安装依赖”这种传统流水线工作流很不一样。它是站在更高层面，把每个子任务对应到某个抽象能力上，再动态决定要不要调用某个 Python 工具、要不要从网络获取数据、要不要搜索更多信息……等所有步骤都在后台默默进行，直到满足我们给出的目标。
如果光是从结果看，似乎就是“哎呀，AI 更自动了一些”“我少花了点力气”。可要是站在产品或商业应用的角度，就会感到这个转变非常惊人：以前我们见过的 AI 系统，不管怎么强，也离不开“用户给它什么数据”，它就“处理并且输出”。那种系统更像是一个计算电路或一个咨询专家，你得把材料备好、把问题拆分好，它才能一次次回答你。而 Agentic AI 已经具备了主动把“如何搜集材料”“如何拆分问题”“怎么把中间产物拼起来”这一整套流程包办下来的实力。也就是说，人类甚至不需要关心中间的操作细节，而只要负责确定目标。这样的一种人机关系，在许多行业应用中会产生我们过去无法想象的效能提升——从个人效率，到企业生产力，都会受它的冲击。
在这种工作方式下，AI 所做的不仅是一次性的回答，而是一种“抽象式的编排”，就像在脑海里先画出了一幅流程图：先判断源图片信息，再调用一个图像处理工具试着执行某条命令，如果不行就根据报错信息改命令或装新的依赖，然后重复多次直到搞出结果，最后把结果文件放到一个我能找到的地方。在同一个请求里，它会组合“工具调用”与“自我纠错”的过程，这跟我们原先在命令行里敲一串命令，然后出现错误再自行谷歌搜索的工作流已经大不相同。
这就是从“工具”到“抽象组合”最大的差别：传统软件或旧式 AI 主要是提供若干固定的工具接口给人用，而 Agentic AI 则可以使用若干工具接口自己组合成“解决方案”。对很多产品经理而言，这意味在设计新一代 AI 应用时，我们再也不用把“我有哪几个功能点”写成一张菜单栏让用户手动点选，而是要思考怎么把背后的抽象能力摆在 AI 的可调用范围之内，然后让用户只需要表达目标就行。让 AI“探索式”地去决定这当中每一步要调哪个工具、要拿哪部分数据、要先做什么后做什么。说白了，这是一次用户交互模式的大翻新。以前做软件都要先想“用户点击按钮 -> 跳转到新页面 -> 填表 -> 再点击完成”。而现在可能变成“你对 AI 说一句想干什么，它自己调按钮、调函数，最后给你结果。”
自由组合的抽象能力 = 新范式
这种思维的变化跟我们在历史上见过的几次“大转折”类似，比如当年云计算出现时，人们从“我自己装服务器”转变为“我只要传个容器上去让它自动扩容”。一开始也会有人困惑：“那这会不会太不踏实？我还得学运维吗？”但慢慢适应后，我们发现它的自由度和效率爆表。同理，现在 Agentic AI 这种高自由度的抽象组合方式，可能也会让一部分用户刚开始有些无所适从：我们明明以前都一步步按脚本来写，现在 AI 竟然能同时操作终端、装依赖、甚至搜索网络信息，这是不是太有“自主性”了？可正是因为它能跨越这个“自主执行”的门槛，才让我们可以真正把大部分杂务扔给 AI，自己只专注在最有创造力的地方。
在这一节里，我们想讨论的“产品形态”问题，正是要点明：这种可自由组合的抽象能力，本质上会带来新的产品层次，也就是从“点状或线性操作”进化成“通用编排引擎”。以前要想完成一个复杂场景，可能需要集成好多个单一工具，要写各种 Glue Code（也就是把不同工具粘起来的脚本或配置），要在团队里安排专门的人去维护这些中间层。而 Agentic AI 在理想情况下，只需确定它能获取哪些工具和资源，就能在“灵活的对话+决策”里即兴编排，无需大量人工搭桥。对企业或开发者而言，这种巨大便利让他们能够在很短时间内，就用很少的人力，快速构建起一个“从指令到落地结果”的自动化流程。
有人会问：“这样是不是有点像编排软件，比如一个强大的 CI/CD 平台，或者一种低代码的流程自动化工具？”确实，在理念上有点相似，但最大的区别是 Agentic AI 在编排过程中，依赖的是它的通用语言理解和大模型推理能力，也就是说，它不需要你事先画一张严格的流程图才懂得下一步该怎么做，更不需要你给它列一个“错误码 1234 时跳转到 A 分支，错误码 5678 时跳转到 B 分支”的死板逻辑。它可以根据自然语言描述、命令行报错信息、已知的上下文内容等动态去决定该如何修正下一步指令，而且在必要时还可以选择去搜索或爬取新的信息，这在传统流程工具中是没法用纯配置方式实现的。
当然，这也给人带来很大的不安和不确定性。对一些受监管或对于安全性极度敏感的场景，比如医疗诊断、金融交易，我们或许不能容忍 AI 随便执行不受控的脚本。那这种担忧完全正常，因为 Agentic AI 的核心，就是在打破很多过去的软件边界，这其中是否会出现混乱与风险，短期来看肯定存在。我们只能说，现在的 Agentic AI 工具多半也有一些安全限制，比如在 Cursor 或 Windsurf 里，即使使用 Agent 模式，系统也会强制我们对某些命令手工点击确认，避免 AI 直接把整个系统给删除了。还有一些更复杂的安全架构，会把 AI 所在的环境放进一个容器或沙箱里，保证它对外界的破坏力可控。在商业落地时，如果是面向大型企业或公共部门，更要留意权限管理、审计日志、出错回滚等等机制。但不管怎么说，从“可控风险”的角度看也好，或者“更高效、更自动化”的角度看也好，这个范式转变已然呼之欲出，我们终究会在各行各业看到它的巨大影响。
更何况，现在还只是 Agentic AI 的早期。我们才刚刚摸到一点点门槛，但已经有 Cursor、Windsurf、Devin、Microsoft AutoGen 等众多框架开始实验，比如给 AI 一个浏览器、给 AI 一个图像理解模块、让 AI 同时驱动好几个子 AI 模块……这种不断叠加能力的过程，就像在几块“乐高积木”之间自由组合：让 AI 自己能做文字处理、做图片处理、做数据分析，还能读写文件、执行脚本、进行自我纠错。如果我们把每种操作都当做一块可插拔的“抽象能力”，那当它们组合到一定规模，AI 就可以完成非常惊人的任务。就像当年云计算搭建了一层层抽象后，我们从租服务器进化到租数据库、租大数据平台，直到“干脆把整条业务逻辑都托管到云端”。Agentic AI 迟早也会出现“干脆把整条业务流程都托管给 AI”这样的场面。
自由度与可控度的权衡
具体到产品形态上，这意味着未来会出现各种“全自助式 AI 平台”，允许用户直接在对话中说“我想要一个网站，包含前端首页、用户注册、数据库后端、还要支持第三方登录”，然后 AI 就能调度一系列工具自动生成项目结构、安装依赖、做前后端联调、在出现 bug 时自己调试，最后在 Docker 里给你打包运行起来。以前我们在 Demo 中只能看到“这有个小例子，我让 AI 写了点 Python 爬虫，太神了吧”，但这只是冰山一角。在 Agentic AI 的思路下，其实可以让 AI 一口气做完所有你能想到的事情。从个人的角度，这简直就像是雇了一个可以 24 小时不睡觉的超级实习生；从企业的角度，这或许会革掉传统外包或低代码平台的命。
有人会说：“好是挺好，但这玩意前途难道就没有任何阻力？”其实阻力肯定不小，除了前面说的安全和监管问题，还有用户心智的转变，以及对 AI 错误或幻觉的容忍度问题。比如，你可能无法马上相信 AI 会一步步把网站搭好，然后不会在某个关键节点把数据库给误删了。就算它不误删数据库，有些逻辑也可能因为大模型推理出错而出大岔子。在这种环境里，人类或许还是要在某些关键点进行检查和确认，这就需要在产品形态中预留一个可视化的“AI 行为仪表盘”。
这种“AI 行为仪表盘”在很多新近的 Agentic AI 工具里都已经初现端倪，类似 Cursor 在 Agent 模式下，每执行一个命令前，都会弹出提示让人类点击确认；又或者 Devin 会显示一个“工作计划”视图，让你看到它当前执行到哪一步。实际上，这些尝试都是在回答同一个问题：给了 AI 这么多能力之后，要如何才能让用户保持必要的掌控感，同时又不扼杀 AI 的高自由度？答案很可能是设立某些可视化的、可审计的管理面板，让用户能够看到“AI 刚才调用了哪个工具、运行了哪行命令、得到了什么输出”，并在需要时进行拦截或重新定义。就像管理真实的团队一样，你可以定下某种程度的放权，但遇到重大事项必须审批。Agentic AI 之所以令人兴奋，就在于它把过去只能人工串起来的环节全部自动化了，但这也意味着要在“自由”和“可控”之间找到平衡。
由此可见，我们在谈“从工具到抽象组合”的时候，实际上是把一连串重大的新问题或新挑战带进了产品层面：要不要让 AI 有 100% 自由执行所有命令？要怎么记录它的每次调用？要如何在出现失误时进行人工介入或自动回退？用户该不该亲眼看见整个多步决策链？对于那些对安全性要求高、或者数据合规性要求强的场景，是否需要给 AI 准备一个“隔离区”来执行高风险操作？当我们把这些问题都汇总起来，就会发现打造一款 Agentic AI 产品不再是“加个语言模型”就能完成，而是必须在系统底层构建一整套围绕抽象能力组合的基础设施，把工具访问、权限管理、错误监测、上下文存储等都考虑进来。
当然，对于早期的个人或小团队来说，可能不需要做得那么全面。很多人开始用 Agentic AI，只是想在本地电脑上装个像 Cursor 这样的编辑器，让它帮忙自动地完成一些小脚本或图像处理任务，安全风险可控，自己也能实时看到出错情况。也有人喜欢把 Agentic AI 跑在 Docker 容器里，就算 AI 出了什么幺蛾子，也不会真正伤到宿主系统。对于规模更大的团队，则可以利用类似 Windsurf 或微软 AutoGen 提供的扩展接口，把 Agentic AI 的执行过程封装在一个可监控、可审计的环境中，再根据企业需求来开启或限制某些功能。就像之前我们提到的那样，这套体系和云计算的管理模式其实有不少相似之处——只不过云计算主要管理硬件资源调度，而 Agentic AI 则要管理“AI 对外部工具的调用流程”。
回到产品形态这个主题，我们不难看出，它将随着这些“抽象能力”的普及度和成熟度而不断演化。现在还处在早期，有的产品只实现了少量特性，比如只能执行命令行和读写文件，还不支持上网搜索；有的则把浏览器交互、视觉识别等更高级的能力也纳进来；有些产品则非常注重“做事前先给一套完整计划”，像 Devin 那样会列一个 Todo 清单；而另一些产品更倾向于“直接尝试 -> 发现问题 -> 纠正”的快速迭代模式。无论是哪一种，核心点在于：它们都企图让 AI 在内部自己编排多步操作，不再只给用户一个一次性回答，再被动等候下一次询问。对比我们在上一章提到的三种编程心智（Comment-Oriented、Prompt-Oriented、Objective-Oriented），就能感受到这背后隐含的“可抽象性”其实是步步升级的。从一开始只能行内自动补全，到后来能大范围修改或多文件重构，再到现在能跨多个工具自由行动、自动调试，这是一条深度递增的曲线。
仔细想想，这种演化与“抽象”的概念结合在一起，正是我们所说的“从工具到抽象组合”。为什么说它是抽象？因为在用户眼里，所有的安装依赖、编写脚本、处理错误日志、甚至选择最合适的爬虫库，这些具体的执行细节都是隐形的，AI 自己去搞定就好。用户只需要抽象地声明“我想要做这件事”，或者“我想要达成一个怎样的目标”。而为什么说它是组合？因为在真正执行的过程中，AI 是把一个个“可调用的能力”像乐高一样拼接起来用的。比如先调用 Python 解析某个 HTML 网页，然后调用 GPT 来 Summarize 这段文本，再用一个计算器工具做数学运算，最后写入一个 Markdown 报告并检查有没有缺失。整条流程对用户来说就是“一句话发需求”，对 AI 来说却是一连串多步决策+工具使用。
多智能体系统
在过去一两年里，我们见证了 Agentic AI 这个概念从“小规模试验”一路走到“多领域融合”。最初，大家常常把注意力集中在“给一个 AI 配上一堆脚本和工具，让它能自动安装依赖、执行命令行，遇到错误还能自我修复”，这的确是一个相当震撼的进步。但当我们放远目光，就会发现 Agentic AI 的演变并不仅仅是给单个语言模型加外挂那么简单。越来越多的团队已经开始琢磨：是否可以有不止一个 AI，而是一支 AI“团队”？让不同的智能体（Agent）各自分工、再互相沟通和协作，来完成那些比单一模型更庞大、更分散的任务。这个想法被称为“多智能体系统”，或者“多 Agent 协同”。
在想象层面，这听起来就像把几位风格各异的角色凑到同一个虚拟会议室里：有的专攻数据分析，有的擅长图像处理，还有的能写漂亮的文档。他们之间彼此对话、交换信息，每位 Agent 都能调用各自的工具。最终，如果人类只发一句“给我做一份市调报告，统计数据放在 Excel，排版成 PDF，顺便把几个关键图表插进来”，这一群数字“雇员”就能你来我往、分头行动，在某个时刻合力产出我们要的结果。
然而，一旦真的动手搭建多智能体系统，你会很快发现事情并不如想象那样顺滑，甚至会比单个大模型带来更多挑战。为什么有些多 Agent 协同平台效果不错，有些却频频翻车？有人直觉地认为，这大概是因为“每个 Agent 的 Prompt 不一样，或者它们各自专注的领域不同”，所以就能互相合作。可在大多数基于大型语言模型（LLM）的现实应用里，这种“特化 Prompt”固然重要，但它并不是多智能体系统最核心的驱动因素。更关键的一点其实隐藏在“上下文管理 (Context Window Management)”之中，也就是说，如何有效地处理多轮对话里堆积的大量信息，避免让一个大模型在庞杂的任务细节中迷失自己。
换句话说，多智能体系统之所以能起到效果，往往依赖“用多个上下文窗口去分摊”而不是把所有细节都塞进同一个语言模型的对话里。一个常见的做法是，引入一个顶层“规划者”（Planner Agent），它扮演领导或大脑的角色，负责全局的思考和决策。下层的“执行者”（Developer Agent、Writer Agent、Designer Agent 等）则各自拿到 Planner 分配的子任务，处理完后只把简要的进度或成果汇报回去，Planner 依旧能保持自己的上下文干净清爽，从而维持高层视角，而不至于陷入执行层的庞杂日志里。
举个具体例子，Planner 并不需要知道某段图像处理脚本的每一行命令，只需要在关键时刻判断“图像处理完成了吗？如果报错，需要换哪个库？”这就类似在公司里，项目经理不必亲自阅读每一行代码，只要能让程序员报告“任务做成什么样了”，并且在出现阻碍时再讨论解决方案。这样的大脑-执行层结构，能把上下文需求拆分到不同的语言模型或不同的对话空间里，减少无用信息对 Planner 的干扰。对于那些对话窗口有限的大模型而言，这种拆分可以极大地降低“上下文爆炸”的难度，让它专注于更宏观的规划和推理。
除了能解决上下文爆炸问题，多智能体系统还有另一大好处：它给了我们更多“选模型”的灵活度。很多人知道，不同的 LLM 不仅性能差别大，成本也千差万别。有的 GPT 系列版本价格昂贵，但推理能力超群；有些模型如 Claude 或相对轻量的 Gemini-2，费用可控，而且在日常撰写文档或处理一些初级任务时依旧堪当大任。多智能体系统可以利用这个差异，让 Planner 这样的重要核心角色使用更昂贵但更强大的模型，比如 O1（这里只是举例子，表示高阶大模型），因为 Planner 不需要频繁地调用，只要在关键时刻做决策或规划即可；而 Developer、Writer、Translator 这些更高频的小工种，则可以用成本更友好的模型支撑。如果某个执行者“跑”得多，也不影响整体费用太夸张，还能充分发挥各模型的适配场景。就好比我们在现实公司里，对最高端的专家多付点薪酬，再让普通员工承担日常繁重工作，组织效率往往能显著提升。
当然，读到这里，你也许还想问：为什么不把所有能力都塞进一个最强的模型里，让它全权负责？表面上看，这种“单体大模型”很纯粹，但在实践中，一来容易在执行细节中迷失，二来成本成倍上升。如果某些初级操作都由顶级大模型做，未免也太铺张。更何况，在一些非常细分的领域里，专用模型（例如专攻生物序列分析或财务审计）可能表现优于通用大模型，把它纳入多智能体系统里，会带来效率和质量的双重提升。这就让多模型协作具备了现实意义，也为团队根据需求与预算做灵活调度提供了可行的路径。
那么，这种多智能体系统在执行流程中，具体会经历什么样的阶段？大体可以简化为：人类用户发出一个总目标，Planner 先拿到它，做一轮高级别的拆解和推理，得出若干子任务。然后 Planner 会决定哪个子任务交给哪个 Agent（这个 Agent 可能是 Developer、Researcher、Translator、或别的角色），传递过去的上下文只包含和该子任务紧密相关的部分。Agent 做完以后，把关键信息或汇报要点发送回 Planner。Planner 若觉得差不多，就进入整合阶段；若发现还有很多漏缺，就发起更多迭代或把新的工作分配给别的 Agent。如此往复，这个团队型协作就可以持续地完成更复杂的目标，包括并行处理多个子模块。对外界而言，这个过程也许只是一两分钟的运算，但背后或许经历了十几个回合、上千行中间信息的来回交换。
在这样一套流水线里，最大的难点并不一定是每个 Agent 的局部功能，而是如何保持“轮次间的记忆”和“上下文的聚焦”。如果 Planner 被过多的细枝末节淹没，思考质量就会大打折扣，甚至陷入混乱。所以往往我们会让各执行 Agent 提交极简化的汇报，把大量的过程数据留在它自己的对话内，不要一股脑抛给 Planner。这样既节省了 Planner 的上下文窗口，也能让 Planner 用最干净的空间做高层推理。你可以把这种机制想象成：在大公司里，一个小组长不会把所有 debug 日志全端给 CEO，只会按需简报，CEO 也会基于这份简报继续思考下一步方针。对多智能体系统来说，如果没有这道“信息梳理”环节，它就跟单一的大语言模型的行为没什么区别，可能依旧会被缠在大大小小的技术细节里抽不开身。
另一方面，多 Agent 协同对“容错”和“鲁棒性”也提出了更高要求。一个 Developer Agent 可能在解析网页的时候碰到报错；另一个 Writer Agent 做完初稿的文字风格不符合要求。Planner 要不要让 Developer Agent 重试爬虫？要不要指示 Writer Agent 立刻改成精简风格？这些微小的分工与纠错逻辑，往往需要在多智能体系统的底层做一些额外的调度和监控。我们也经常见到有些开源项目在多 Agent 协同里跑着跑着就陷入死循环，两个 Agent 像复读机一样互相汇报错误信息，然后都不肯停止——这也是上下文管理失效的典型案例。要让多 Agent 系统真正成熟，就得在这类意外场景上多花心思，设计合理的熔断和回退策略。
说到这里，你也许会有更大胆的遐想：未来如果这种多智能体系统能变得相当稳定，那我们是不是就能部署一整队 AI，几乎覆盖从运营到研发的所有角落？从技术上看，并非不可能，但也要看到，当前大模型的思维能力距离真正的“通用智慧”依旧有差距。多智能体系统更像是“将上百个脚本和资源组合成若干独立 but 小型的 AI 单元”，不是让它们个个都变成全能大脑，而是利用“拆分上下文、各司其职、分而治之”的方式实现协作。要说它“完美解决”了所有难题还尚早，但在一些不那么严苛的场景里，它能大幅节省人工整合或上下文维护的负担。
因此，如果你想在自己的项目里尝试多智能体的思路，可以从几个要点入手：第一，弄清哪些任务特别依赖上下文拆分，把 Planner 和执行者分开，把信息流动的格式定清楚；第二，考虑不同任务对模型性能和成本的要求，把关键决策位留给最昂贵且最强大的模型，而把日常频发的工作交给更轻量的模型；第三，为每个执行 Agent 提供一个自己的小“上下文区域”，只有在必要时才汇报给 Planner——这样 Planner 不会被无关信息拖累，也能腾出精力思考更宏观的问题。最后，别忘了预留一套容错机制，防止意外故障时系统死循环或黑屏。
要提醒的是，即使多 Agent 协同给我们带来了上下文与成本方面的优势，你仍然要审慎对待安全性与数据保护。因为现在不只是单个 AI 需要访问你的敏感文件，可能有多个 Agent 都能触达外部资源。彼此间如何隔离权限？如何杜绝它们误删文件或泄露机密？这些都是工程实践中绕不开的难点。就像任何新兴的技术方案一样，多智能体系统一方面在打开生产力的想象空间，一方面也对管理和安全提出新的挑战。
总之，多智能体系统并不只是换了几句 Prompt 就能“多合一”，它背后真正的抓手在于对上下文的分而治之，以及对模型资源的灵活选择。让 Planner 保持高视角，不卷入太多执行细节，等到需要做决策时再登场；而执行层可以更频繁地与人类或外部工具交互，却不会污染 Planner 的注意力。这些机制加在一起，给了“我问你做”再上一层楼的机会，也为未来更大规模、更复杂的 Agent 协同奠定了雏形。如果你也有兴趣把多智能体系统运用到自己的产品或团队，可以先从一个小型试点入手，摸索如何设计信息流、定义 Agent 边界、挑选合适的模型，然后一步步累积经验。终有一日，也许我们会看到一个专属的小宇宙在你电脑或云端里热火朝天地运转，每个数字化员工都各司其职，为你的目标协同拼搏——那时候，你或许会回想起当初第一次认识多 Agent 协同时的好奇与兴奋，感慨道，这还真是 Agentic AI 中相当有远景的一种进化形态。