摘要：这篇文章把我最近这一年多以来业余时间做 AI 应用的过程做一次复盘，一方面聊聊如何构建一个多智能体驱动的 AI 应用，另一方面在这个全新的时代，大家基本站在一个起跑线上，我以浅薄的 AI 应用落地经历，分享些做产品思维上的一些变化。
这篇文章把我最近这一年多以来业余时间做 AI 应用的过程做一次复盘，一方面聊聊如何构建一个多智能体驱动的 AI 应用，另一方面在这个全新的时代，大家基本站在一个起跑线上，我以浅薄的 AI 应用落地经历，分享些做产品思维上的一些变化。
技术演进总是以指数级加速。大型语言模型问世以来，AI 应用已从简单的聊天机器人和信息检索系统，迅速发展为能够执行复杂推理与多步骤任务解决的智能系统。在这场技术变革中，传统的系统架构与产品管理方法不仅面临挑战，更走向了彻底重构。
这段时间最大的感受：当传统方法失效时，创新不是选择而是必然
文中会涉及到一些不同应用的案例，因为我做了好几个，文章内容从 2023 年初横跨到现在，可能一些概念已经有点“过时”，你也可能在上一段看到某个场景，下一段换到了另一个场景案例。
希望这篇文章能给正在设计 AI Agent 应用的 产品经理 builder 创业者 … 一些启发，本文没有技术讲解，也没有宏观战略的大概念，非常具体的聊聊问题和如何改建的产品设计思路。
从我做的第一个工具说起。
固定 LLM 工作流 + RAG 的根本局限检索增强生成（RAG）技术是让 LLM 能够获取特定知识控制模型发散按照既有知识返回结果的关键技术，在 2023 年的 AI 应用基本上都是基于这个模式，常见的企业内知识点问答机器人都是这种模式。
最开始在我开发这个 AI 应用的时候也是基于 LLM 设定固定的 workflow，RAG 在其中是一个标准流程。
这是个 AI 驱动的任务拆解器，只要你输入一个想法，AI 就可以基于特定的工作流，拆解任务，然后搜索信息 RAG 内容返回，最终告诉你你的这个想法如何能转化为一个可落地的 MVP 策略。
你只需要描述想法，通过 LLM 的 workflow 拆解后，会调动谷歌 API 搜索不同纬度的内容完成 RAG ，然后在根据既定的 workflow 整合内容生成结果
这在特定单一场景领域是奏效的，但从架构设计上是绝对不够抽象的（后面会聊这个场景和抽象的关系）当场景一旦扩展，马上就会发现这个架构的局限性。
比如，我要继续通过多轮对话来优化结果，此时固定的单轮 RAG 就会出现问题。
单次单向传递的 LLM workflow 瓶颈传统 LLM 工作流系统遵循一种线性工作流：接收查询、检索相关文档、基于检索内容生成回答，或动作执行后返回结果 。这种”一次性”流程在简单信息查询场景下运作良好，但在面对复杂、多层次问题时迅速崩溃。
比如在客服场景中：
客户：”我想退回上个月购买的无线耳机，但我丢失了收据。我还保留着原包装，订单号是 A12345。”
传统 RAG 处理这一查询时，会检索退货政策和订单详情，然后生成回复。但这种方法很难理解复杂因素间关系：
根据订单号识别特定产品信息与购买时间确定适用的退货时间及当期退货政策检查该产品类别可能存在的特殊退货要求考量客户历史记录对处理流程的影响这些相互关联的考量需要多轮信息检索，每轮检索可能依赖先前步骤中发现的信息。传统 RAG 的线性单向处理模式无法实现这种自适应信息收集过程。
语言模型受限于固定的上下文窗口，一次能处理的最大文本量。传统 RAG 试图通过在这有限空间中塞入尽可能多的可能相关信息来应对挑战，期望模型能从中识别重要内容。
这种”尽可能多塞入”策略因两个根本原因而失效：
相关性稀释：当语言模型的有限上下文窗口被边际相关的信息淹没时，就会发生相关性稀释，导致真正关键的信息在处理过程中丢失或得到不足的注意力 以上面的退货为例，当客户询问“我两周前购买的无线耳机没有收据可以退货吗？”时，最相关的信息（特定产品类别和时间段的例外政策）可能被埋藏在一般的退货政策中，使得回复不够精确，甚至可能具有误导性。不可能的检索策略：系统无法先检索基础信息，进行思考，再基于推理结果执行针对性的后续检索。 对于查询“我想退回我上个月购买的无线耳机，但我丢失了收据。我还有原始包装，订单号 A12345” 传统的固定工作流 RAG 无法执行这种多步骤查询，因为它缺乏对初始检索进行推理并基于该推理制定新查询任务的能力。那么要解决这些问题就需要通过在业务流程中构建智能体，将原本的固定工作流拆解抽象成不同的单元，为每个单元构建出具有特定目标和工具集的智能体，从而将固定的工作流基于用户场景动态生成
智能体架构的范式转变首先我们还是要确定我们的产品要解决问题的边界，这是我开发的另一个应用，通过 多 Agent 互相协作实现了更丰富的场景拓展和动态的 Task 规划，从而驱动其他应用的 API 完成自动化任务。
举个例子：
user：为我创建一个任务，下周回北京 约一下 DK 和 XY 的时间， 避免我遗忘在飞书里给我创个提醒
此时 Agent 将拿到这个用户的提问后进行反思，这个问题显然不够具体，此时 AI 会进行反问
AI：我将帮助你安排下周在北京的会议。我需要一些更多细节来正确地设置你的任务和飞书提醒，请问具体是哪天的会议，具体什么时间在哪里见面？可以告诉我更详细的信息吗
可以发现此时具备了多轮对话能力
User：我们周三下午见，大概 3 点左右。我们可以在三里屯的星巴克见面
到这里 AI 已经具有了完备的丰富信息，那么接下来 Agent 就要去完成任务分解，假设规划如下
首先在应用内生成了一个 todo根据 Agent 具备的 Tools 找到了飞书的 API ，进行 function Call ，这个过程中会将用户的消息变成参数最终在飞书里也同步了这个任务，并携带了任务内容和提醒时间的参数。这本质上是一个基于 ReAct（”Reasoning” and “Acting” ）完成的单 Agent 应用
那么如果问题再复杂一个层级呢，除了多轮对话和初步理解问题完成行动之外，让复杂度提高到 可以接近一个真实的员工，或者是类似 manus 这种级别的复杂度。
此时就需要多 Agent 互相协作来完成复杂度更高的任务
通过多 Agent 架构构建 Agentic 产品Agentic 特性的产品是通过嵌入具有自主决策能力的专业化智能体，从根本上解决了传统方法的局限。这些智能体能够动态管理检索策略、迭代优化上下文理解、适应复杂工作流程，将系统从被动信息处理转变为主动理解问题并规划解决。
传统固定工作流系统与 Agentic 系统的对比
构建多 Agent 系统
在上述架构中，我们采用了一个「协调智能体」在最前面理解用户的需求，通过下发任务给各种专家智能体来完成信息的获取，然后评估智能体来评估信息的完备性，是否能成功解决用户问题，如果不能则一直循环，直到通过评估，生成响应结果，将结果回传给协调智能体，交给最终负责输出的 LLM 基于提示词润色内容完成输出或完成动作
这种架构整合了五个关键元素：
专业化智能体网络：每个智能体都有明确定义的专长和责任领域动态任务分解：将复杂查询分解为可管理的子问题自适应检索策略：根据上下文选择最优信息获取方法迭代推理过程：通过多步骤推理逐步构建理解持续上下文优化：在对话过程中维护并增强交互语境这种集成使系统能处理远超传统方法能力的复杂场景。
接下来我们一个一个来拆解每个智能体
ps：产品经理在这个过程中有大量的提示词要去评测，要基于 case 写评估集 … Etc ，这些过于专业的细节本篇就不展开了，未来慢慢写
协调智能体
协调代理是系统中的中央控制单元，负责接收用户查询、分析查询意图，并将任务分配给合适的代理。它充当系统的“大脑”，确保各个代理之间的协作和任务的有序执行。
具有以下能力：
理解用户需求：深入理解用户问题的本质，而非仅关注表面描述，以及意图目标是可被执行的，如果信息不够完整，则需要反问用户（想把反问做好还需要点技巧，以后分享）任务分解：基于用户的意图，来进行任务拆分，并确定哪个专业代理应该处理对应的任务规划：在需要多个专业领域时，指导信息在专家智能体之间“流动”按顺序执行维护上下文：以及与记忆系统交互，确保智能体和用户交互的上下文连贯性评估结果：确保当前的结果是可以解决用户提问的合成最终回复：整合各专业智能体的输出，生成一致且全面的回应若要设计这个智能体，需要考虑较多方面到业务场景，比如是否需要识别特定实体，需要构建意图识别，协调智能体的有效性很大程度上取决于它对问题进行分解和理解的能力，以及它协调其他智能体的策略。
专业智能体团队
在专家智能体团队中，这个 AI 任务助手项目构建了三个智能体
网络搜索智能体：具备搜索互联网数据的能力，通过公开的搜索引擎 API 获取数据知识检索智能体：基于智能助手中的文档记录（私有知识）进行 RAG 为任务提供更具有个人领域知识点上下文，并且基于 RAG 来获取领域知识应用交互智能体：基于问题调动其他应用接口，比如个人日历专业智能体团队的有效设计是构建高性能 AI 任务助手的核心。网络搜索智能体、知识检索智能体和应用交互智能体各司其职，形成一个全面的知识获取和执行系统。这种模块化、专业化的设计不仅提高了系统的整体性能，也使得系统更具可维护性和扩展性。
在实施过程中，关键是确保智能体间的无缝协作和清晰的职责划分。随着系统的发展，可以根据业务需求逐步扩展智能体团队，增加更多专业领域的能力。这种微服务式的智能体架构将成为未来企业级 AI 系统的主流设计模式。
现在你肯定会有一个疑问，他们之间是如何通讯调度的，协调智能体一定不是简单的并行分配任务，有的任务是具有时序依赖的，在我实现这个助手过程中，采用了 星型拓扑的通讯机制，除此之外不同的多智能体框架有不同的通讯机制，比如 MetaGPT 框架采用了 消息池订阅机制（可以理解成一群人坐那开会，不断的发表言论，每个智能体只获取对自己需要多信息）
星型拓扑：企业级多智能体架构的首选通讯机制这种机制通过将一个中央协调智能体与多个专业智能体相连接，形成类似星状的组织结构，从而实现高效的信息流通和任务管理。在企业级 AI 解决方案中，这种架构已成为处理复杂业务场景的首选模式，特别是在需要整合多种专业能力的应用场景中。
这是一种中心化的通讯机制有以下特点
中心协调节点：核心位置由协调智能体（Orchestrator Agent）占据，作为系统的指挥中心放射状连接：所有专业智能体都直接与协调智能体相连，形成辐射状结构单点通信原则：专业智能体之间不直接通信，所有交互必须通过中央协调者中转这种设计避免了网状拓扑中的复杂连接关系，同时比链式拓扑提供了更高的响应效率和容错能力。
当信息以中线点向外流动时，视为任务分配，当以专家智能体为核心向上流动时，视为结果聚合
当协调智能体进行任务分配时，还需要维护一个状态机，记录以下内容：
每个专业智能体的当前工作状态已分配任务的执行进度系统整体响应流程的状态可能的阻塞点或瓶颈这种状态同步确保协调智能体能够实时把握系统运行状况，进行必要的干预和调整。
这虽然已经能够满足绝大多数需要，但还是不够高效，更高效的方式还应在此基础上叠加优先级系统。
优先级系统
设计一个方法确定任务的执行顺序。不是所有任务都需要串行执行。一些策略包括：
关键路径优先：某些信息必须先获取才能执行后续任务速度优先：一些快速任务可以并行处理重要性加权：优先处理对最终答案最关键的信息业务特殊性有限：命中一些意图时，可以触发特定的工作流有限处理或阻断其他任务现在这已经是一个较为完备的多 Agent 系统了
我们应该可以清晰的感受到，协调智能体才是业务的核心，一旦进入到复杂场景，和业务链条极其复杂的业务时，要确保该智能体有非常丰富的推理空间，那么我们如何让 AI 应用变得加与“我”适配呢？随着使用的深入，应该具有更加了解我的特点的能力。
这就需要一套完备的记忆系统
记忆的本质：创建真正个性化体验上下文和记忆系统构成了真正有效 AI 产品的基础。没有强大的记忆架构，即便最先进的推理能力也无法创造用户期望的个性化体验。
多层次记忆
我们的实现采用分层记忆系统，平衡即时上下文需求与长期理解能力
该层维护即时对话历史，通常包括用户与系统之间最近 5-10 轮交互。它确保单次互动会话内的对话连贯性。
核心特性：
完整存储在上下文窗口中精确保留近期交流内容通过滑动窗口机制自动管理支持对近期陈述的直接引用会话记忆（中期记忆）
该层在整个服务事件中保存关键信息，可能跨越多个对话片段或不同渠道的接触点。
核心特性：
结构化存储已识别实体和意图保存关键决策和提供的信息多步骤流程的状态追踪持续时间通常为数小时至数天用户记忆（长期记忆）
该层维护跨越多次对话的客户关键信息、偏好和交互模式。
核心特性：
高度选择性地保存关键信息关注模式和偏好而非具体对话内容与客户数据平台和 CRM 系统集成持久性以月或年计如何形成记忆
记忆系统不是单纯的存储原始对话，而是提取和索引关键实体与事件。这种方法实现了相关先前交互的精确回溯，同时避免用无关历史数据淹没上下文窗口。
记忆的结构化示例：
{
“memory_id”: “mem_78912”,
“memory_type”: “technical_issue”,
“primary_entity”: “smartphone_model_xyz”,
“related_entities”: [“camera_app”, “battery_performance”],
“information”: “设备遇到电池消耗和相机应用冻结问题”,
“context”: “客户尝试重启和应用重装但未解决”,
“resolution_status”: “unresolved”,
“resolution_attempts”: [“restart”, “app_reinstallation”],
“customer_sentiment”: “frustrated”,
“timestamp”: “2023-05-15T14:30:00Z”,
“importance_score”: 0.85
}
这种结构化方法实现了：
上下文相关检索：基于当前对话相关性检索记忆模式识别：识别跨客户的相似问题个性化：根据过往交互调整响应策略持续学习：追踪解决方案有效性可以理解为，让大模型去理解对话中的含义，并且抽取其中的实体和事务，然后针对性的完成 短期 中期 长期的对应存储方式，这样做的好处并不是一味的将历史信息大量灌入上下文窗口，而是先理解问题，选择预置匹配的记忆来补充。
让我们举个例子来感受记忆系统的价值，跨时间的交互场景，展示记忆系统如何创建更个性化、更有效的客户体验：
之前互动（2 周前）：
客户：”我在将新智能音箱连接到家庭 Wi-Fi 网络时遇到问题。”
系统：[提供 Wi-Fi 连接故障排除步骤]
客户：”解决了！但现在我在链接音乐账户时遇到问题。”
系统：[引导完成流媒体服务连接]
客户：”太好了，现在一切正常。谢谢！”
当前互动：
客户：”嗨，我们之前讨论的音箱又出问题了。现在它会随机与我的手机断开连接。”
没有有效记忆系统的情况下，系统对”我们之前讨论的音箱”没有上下文理解，需要询问设备型号、购买时间等基本信息。
这创造了一种无缝体验，让客户感到被理解和重视，显著提高满意度和解决效率。
总结一下
到这里我们已经完全完成了这个项目，我们已经把固定的 workflow 编排，升级为了具有 Agentic 性的多 Agent 系统，从较为简单的单轮查询，升级到多轮反复循环自主规划任务的强大系统，在这套以协调智能体作为核心入口，驱动专家智能体团队完成任务的多 agent 架构中，我们几乎可以胜任 80% 的企业级需求，随着能力的扩张，需要不断延伸专家智能体的数量来拓展能力边界。
AI 时代的产品思维变革软件产品专注于定义明确的用户旅程和工作流程。去梳理业务场景，然后把业务拆解为可解释的固定环节，然后对应构建产品，每个步骤都有确定的输入、输出和 UI 元素。产品经理精确规定系统在每个场景中的行为。
AI 产品则需要根本不同的方法。产品经理不再规定精确工作流，而是定义：
边界：智能体责任范围的清晰界限，目标：成功结果的明确标准，环境/容器：智能体有效运行所需的上下文环境这种面向目标的方法关注智能体应当实现什么，而非在每种可能情况下如何实现，要更加的拥抱灰度，与此同时，要构建评估思维，因为需求的迭代不再是固定且线性的，这就需要有很强的评估思维，根据结果来反推 AI 系统中某个环节或某个变量的调整，形成反馈循环
软件产品经理高度依赖特定用户故事和场景：”作为客户，我希望查看订单历史，以便追踪过去购买。”
这种细粒度方法在面对通过自然语言交互并处理同类请求无数变体的 AI 产品时变得不切实际。
AI 产品经理必须转向抽象和模式思维：”系统应理解并响应关于用户过往交易的查询，无论表述形式如何，通过检索相关交易详情并在对话上下文中呈现。”
这种转变要求产品经理发展：
模式识别能力：识别多样表达中的基本用户需求意图映射：理解用户表达类似需求的各种方式边界定义：明确区分 AI 责任范围内外的事项所有这些都表达同一基本需求的变体。产品经理不应为每种可能表达创建场景，而应定义抽象能力及其边界。
变革三：从关注功能到定义原子能力
从功能到能力的转变代表产品经理思维的另一根本转变：
软件产品经理：”我们要在订单历史页面添加’重新订购’按钮，自动将之前购买的商品添加到购物车。”
AI 产品经理：”我们要使智能体能够理解并执行用户在任何对话上下文中重复过往购买的意图。”
这种基于能力的思维使 AI 产品能以僵化功能定义无法实现的方式适应用户需求。它的价值不在于特定 UI 元素或工作流步骤，而在于系统理解并满足用户意图的能力。
用户故事应该只是抽象为元子能力的思考基础。
变革四：从确定性到概率性思维
对产品经理而言，最深刻的转变是从确定性思维转向概率性思维。
传统软件开发中，我们习惯于使用二元判断标准来评估产品质量——系统要么”工作”（正常运行），要么”不工作”（出现错误）。这种思维模式根植于确定性系统的特性：给定相同输入，系统总是产生完全相同的输出。
而 AI 系统，特别是基于大型语言模型的系统，其质量表现却存在于一个连续谱系中，具体体现为：
响应准确度梯度：AI 响应不是简单的”对/错”二分法，而是存在从”完全准确”到”部分准确”再到”完全不准确”的连续过渡
适用性层级：回答可能技术上正确但上下文适用性存在不同程度的匹配，从”完美契合”到”大致相关”再到”完全偏离”
用户价值递进：提供的解决方案可能从”超出期望”到”基本满足需求”再到”没有解决问题”形成价值连续体
这种情况场景无法穷尽列举，必须通过边界和原则管理
这要求产品经理适应，设置可接受性能范围而非精确规格，定义护栏保持系统在适当边界内，以及建立反馈机制使系统能随时间改进
写在最后“不是所有能被计算的都有价值，也不是所有有价值的都能被计算。”爱因斯坦的这句名言，或许是我们面对 AI 产品范式转变最恰当的启示。
传统软件世界中，我们习惯于线性思维、确定性假设和可预测的结果。我们用流程图描绘用户旅程，用功能清单定义产品边界。这种方法在确定性系统中运作良好，就像牛顿力学在中等尺度世界的精确预测一样。
然而，随着人工智能带来的范式转变，我们进入了一个全新的认知领域这里的规则更像量子力学，充满了概率、不确定性和涌现属性。在这个领域中，产品不再是静态的工具，而是与人类共舞的动态伙伴。
正如物理学家尼尔斯·玻尔所言：”如果量子力学没有让你感到震惊，那说明你还没有理解它。”同样，如果 AI 产品的新范式没有让我们重新思考产品的本质，那我们可能仍停留在旧世界的认知框架中。
来源：人人都是产品经理
