AIWorks的Multi-Agent是怎么实现的

Multi-Agent 这几年被讲得很多。讲概念时，它通常会被描述成一组智能体分工协作：有的负责规划，有的负责检索，有的负责执行，有的负责总结。听起来很自然，但真正做成产品时，问题会落到更具体的层面。

用户在页面上怎么配置多个 Agent？这些 Agent 之间的关系怎么表达？主 Agent 怎么知道自己可以调用哪些子 Agent？子 Agent 执行完以后，结果怎么回到主 Agent？如果过程出错，系统又怎么知道错在哪一步？

这篇文章不讨论 Multi-Agent 的宏大叙事，也不把它包装成某种神秘能力。我们只看 AIWorks 里Multi-Agent 是如何实现的。

为什么不把所有事情交给一个 Agent

单个 Agent 能处理很多事。最直接的做法，是把背景、角色、业务规则、任务描述、工具使用说明、输出格式都写进一个很长的 prompt 里，让模型自己判断下一步该做什么。

简单应用这么做没问题。甚至很多内部工具一开始就是这么做的：一个 Agent，一个 prompt，几个工具，能跑就行。但应用复杂以后，问题会很快出现。

• 第一，prompt 会越来越长。一个 Agent 既要理解用户问题，又要判断是否需要知识库，又要决定是否调用工具，还要组织最终输出。职责越多，prompt 越难维护。后面想改一个能力，很容易影响另一个能力。
• 第二，调试边界会变得模糊。一次回答不符合预期，到底是需求理解错了，知识检索结果不对，工具参数生成错了，还是最终总结出了问题？如果所有逻辑都混在一个 Agent 里，排查时只能反复改 prompt。
• 第三，产品配置不够清楚。对应用搭建者来说，一个复杂 Agent 到底包含哪些能力，哪些能力可以单独调整，哪些能力应该被复用，很难从一大段 prompt 里看出来。

Multi-Agent 的意义不在于多放几个模型就更智能。更现实的理解是：它是一种拆分复杂度的方式。主 Agent 负责理解用户输入和协调任务，子 Agent 承担更明确的专项任务。每个 Agent 有自己的 prompt、工具和知识库，职责边界更容易看见，也更容易调试。AIWorks 的Multi-Agent 编排页面就是围绕这个思路设计的。

AIWorks 的Multi-Agent可视化编排界面

在Agent编排页面里，我们设计的用户能够操作的节点类型很克制，只有start和agent两类节点。start表示应用的入口，agent表示一个可配置、可运行的智能体。每个 Agent 面板里可以选择模型、编写 prompt、配置工具、知识库和子Agent。多个 Agent 之间通过连线表达可调用关系。

这个产品形态的选择很重要，它不仅会影响用户理解系统的方式，也会影响后端的实现。从产品视角看，这种设计形态相当于让用户绘制一张 Agent 协作图，从而也能更直观地看到整体拓扑图。

Multi-Agent 可视化编排强调的是调用关系，而不是流程步骤的表达，因此与普通流程图有所不同。在 Agent 可视化编排页面中，多个 Agent 之间使用虚线连接，虚线表示可被调用，而不是必然调用。

可视化编排背后的数据结构

前端页面上的节点和连线，保存时会被序列化为一个包含nodes和edges的JSON结构。后端收到这份数据结构后进行解析，生成Graph对象。

GraphEngine：两种模式，一套底座

GraphEngine 是 AIWorks 的图执行引擎，基于 LangGraph 构建。它支持两种模式：Workflow 模式（普通工作流）和 Agent 模式（Multi-Agent 场景）。两种模式用同一套底座——LangGraph 的 StateGraph——来组织节点和边。

跨节点的公共内存：VariablePool

多个 Agent 协作，必须有个地方存放跨节点传递的数据。AIWorks 用 VariablePool 解决这个问题。变量命名遵循 {节点id}.{变量名} 的规范，避免了不同节点之间的变量污染。

Agent 节点内部：ReAct 循环

单个 AgentNode 的运行逻辑是一个 ReAct（Reasoning + Acting）循环：调用模型、判断是否需要工具调用、执行工具、继续推理，直到生成最终回答。

最核心的设计：子 Agent 也是一种工具

AIWorks Multi-Agent 最关键的一个设计决策是：子 Agent 对主 Agent 的大模型来说，和普通工具没有区别——都通过 function calling 暴露。模型根据当前对话上下文和工具描述，自主判断该不该调用某个能力。

子 Agent 跑完之后，结果怎么回来

子 Agent 执行完之后，结果不能直接返回给用户。它要先回填给父 Agent，让父 Agent 基于这个结果继续推理，决定下一步——要么再调用另一个子 Agent，要么已经有足够信息可以生成最终回答了。

事件流：让执行过程对人可见

AIWorks 用 SSE（Server-Sent Events）把执行过程实时推送出来。整个执行链路的每个关键步骤都有对应事件，前端订阅这个事件流，可以实时展示当前在执行哪个 Agent、是在调用模型还是执行工具、有没有子 Agent 被触发。

结语

AIWorks 的 Multi-Agent 可以理解成一条从编排图到执行图的链路。前端用 start 和 agent 节点表达多 Agent 应用结构，后端把这些节点和连线解析成 Graph。运行时，子 Agent 被包装成 function tool，由父 Agent 通过模型决策触发，再由 GraphEngine 完成路由、状态管理和结果回填。

这套设计没有把 Multi-Agent 处理成纯提示词技巧，而是落到了可配置、可执行、可观察的工程机制上。对 AI 应用开发来说，这比单纯堆 prompt 更接近可维护的工程形态。