从单Agent到多智能体协同：基于 JiuwenClaw 构建企业级采购智能分析系统

从单Agent到多智能体协同：基于 JiuwenClaw 构建企业级采购智能分析系统

引言

很多企业第一次接触大模型应用时，最容易做出来的东西，其实是一个 ChatBot。

用户问一句，模型答一句。 如果只是做知识问答、文案生成、简单代码辅助，这种模式确实够用，甚至体验还不错。但只要把它放进真实业务系统里，很快就会发现一个问题：

企业业务不是“问答题”，而是一条连续的任务链。

比如在我比较关注的招采和医疗设备采购场景中，一个看似简单的问题：

“帮我分析一下 2025 年江西省 CT 设备采购情况。”

它背后并不是让模型随便总结几句话这么简单。

真正要完成这个任务，系统至少要经历这样一条链路：

这就不是一个“聊天机器人”能稳定完成的任务了。

因为这里面包含了多个不同性质的工作：有语义理解，有任务规划，有 SQL 生成，有工具调用，有数据分析，还有面向业务人员的表达输出。每个环节对能力的要求都不一样，失败方式也不一样。

一、为什么企业智能体真正需要的是 Coordination？

如果全部交给一个 Agent 去做，短期看起来很省事，长期一定会遇到三个问题。

第一个问题：单 Agent 会越来越臃肿

很多项目刚开始做智能体的时候，通常会给一个 Agent 塞进越来越多的职责。

一开始它只是回答业务问题，后来希望它能查数据库，再后来希望它能解析文件、生成 SQL、调用插件、输出报告，最后甚至还希望它能够判断异常、修复错误、管理上下文。

结果这个 Agent 的系统提示词越来越长，工具越来越多，规则越来越复杂。

表面上看，它变“强”了；实际上，它变“脆”了。

因为一个 Agent 同时承担太多职责之后，很容易出现职责边界不清的问题。它有时候该规划却直接生成 SQL，有时候该查询却开始编造分析，有时候明明工具调用失败了，却继续给出一个看似完整的结论。

这在企业场景里是非常危险的。

尤其是招采、采购、医疗设备这类数据分析场景，很多结果是要进入业务判断的。公告数量、金额汇总、供应商统计、城市分布，这些指标不能靠模型“感觉差不多”来回答，必须有明确的数据来源、统计口径和执行过程。

所以，企业智能体不能只追求“一个 Agent 什么都会”，更应该追求：

每个 Agent 只做好自己该做的事，然后通过协同机制把任务串起来。

这就是 Coordination 要解决的第一个问题： 让复杂任务从“一个大而全的 Agent”拆成“多个职责清晰的 Agent”。

第二个问题：工具很多，但缺少统一调度

企业智能体和普通聊天助手最大的区别，是它一定要连接业务系统。

比如我的医疗设备采购分析场景里，智能体可能需要连接：

• PDF 解析工具

• Markdown 清洗脚本

• 医疗设备抽取 Skill

• MySQL 查询插件

• DMS / MCP 服务

• BI 页面生成服务

• 日志系统

• 知识库系统

这些东西单独看都可以运行，但问题在于： 谁来决定什么时候调用哪个工具？谁来判断上一步是否成功？谁来把中间结果交给下一个角色？

如果没有统一调度，整个系统就会变成一堆松散的脚本。

开发阶段还能靠人手动串一下： 先跑解析，再跑抽取，再查数据库，再复制结果让模型总结。

但这不叫企业级应用，这更像是一个半自动工作流。

真正可落地的智能体系统，必须把这些能力组织起来。它需要知道：

• 当前任务处于哪一步？

• 上一步的输出是什么？

• 下一步应该交给哪个 Agent？

• 是否需要调用 Skill？

• 是否需要调用插件？

• 失败后要不要重试？

• 最终结果如何回传给用户？

这时候，Coordination 的价值就出来了。

它不是替代某一个工具，而是把 Agent、Skill、Plugin、Session、Task、Log 这些能力组织到同一个运行框架里，让它们能够围绕一个业务目标协同工作。

这也是为什么我认为 JiuwenClaw 这次最新版本值得重点关注。它真正值得看的地方，不只是新增了某个模型、某条命令或者某个插件，而是它正在强化一个更底层的能力：

把智能体从“单点调用”推进到“协同执行”。

第三个问题：企业任务必须可追踪、可复盘、可演进

很多大模型应用在 Demo 阶段看起来很惊艳，但进入企业业务后就会遇到一个硬问题：

结果出了问题，怎么排查？

比如系统回答：

“2025 年江西省 CT 设备采购主要集中在南昌市和赣州市。”

业务人员继续问：这个结论是从哪张表来的？有没有过滤公告类型？统计的是公告数量还是设备明细数量？

如果系统答不上来，那这个智能体就很难真正进入业务流程。

企业应用不怕复杂，怕的是不可控。 不怕模型犯错，怕的是不知道它在哪里犯错。 不怕任务失败，怕的是失败后无法复盘、无法修复、无法沉淀经验。

这也是 Coordination 和普通 Agent 对话模式最大的区别。

普通 Agent 更关注“这次能不能答出来”； Coordination 更关注“这个任务能不能被稳定执行、被追踪、被复盘，并在下一次做得更好”。

在企业智能体系统里，我们真正需要的是这样一种运行机制：

任务可以被拆解
角色可以被分工
工具可以被调用
过程可以被记录
错误可以被定位
经验可以被沉淀
能力可以持续演进

这就从“模型能力”进入到了“工程能力”。

从 ChatBot 到 Coordination，是企业智能体的必经阶段

如果用一句话总结，我认为企业智能体的发展大概会经历三个阶段。

第一个阶段是 ChatBot。

它解决的是“能不能问答”的问题。 用户提问，模型回答，适合轻量化知识问答和辅助创作。

第二个阶段是 Tool Agent。

它开始具备工具调用能力，可以查数据库、读文件、调接口。 但这个阶段通常还是围绕单 Agent 展开，复杂任务一多，就容易出现上下文混乱、调用链不稳定、职责过载的问题。

第三个阶段就是 Coordination。

它不再把 Agent 看成一个孤立的问答入口，而是把多个 Agent、多个 Skill、多个工具、多个任务状态组织成一套协同运行系统。

也就是说，系统开始从：

用户 → Agent → 答案

变成：

用户 → 任务规划 → 多 Agent 协作 → 工具执行 → 数据分析 → 结果交付

这个变化非常关键。

因为企业真正需要的，不是一个“更会聊天”的机器人，而是一个能够进入业务流程、承担任务节点、协调多种能力、最终交付结果的智能执行系统。

二、JiuwenClaw Coordination 的核心定位：不是“更聪明的对话框”，而是企业智能体的协同运行层

如果第一章解决的是“为什么需要 Coordination”，那么第二章要回答的就是另一个更关键的问题：JiuwenClaw Coordination 在企业智能体架构中到底处在什么位置？

很多人刚接触智能体框架时，容易把它理解成一个“套了工具调用的大模型聊天界面”。这种理解不能说完全错，但明显太窄了。因为一旦进入企业场景，我们真正要处理的就不是单轮问答，而是任务拆解、角色分工、工具调用、上下文流转、执行状态管理、异常恢复、过程追踪和经验沉淀。换句话说，企业智能体系统最难的部分，往往不是“模型能不能回答”，而是“模型和业务系统之间的执行链路能不能稳定跑起来”。

从这个角度看，JiuwenClaw Coordination 的价值就比较清晰了。它更像是一个位于模型能力和业务系统之间的智能体协同运行层。底层可以接入不同的大模型、不同的工具服务、不同的 Skills；上层可以面向采购分析、数据问答、文件处理、业务报告、自动化任务等具体企业场景。Coordination 负责把这些原本分散的能力组织起来，让它们围绕一个业务任务有序执行。

可以把它理解成下面这层结构：

这个位置非常关键。因为它不直接等同于模型，也不直接等同于数据库、BI 或脚本工具。它做的是中间那层“组织能力”：把模型理解能力、工具执行能力和企业业务数据连接起来。

2.1 从架构上看：JiuwenClaw 是任务协同中枢

在传统系统里，我们通常会把业务流程写死在代码里。比如一个采购数据分析流程，可能是后端服务接收请求，然后调用 SQL 生成模块，再调用数据库查询，再把结果交给报告生成模块。这种方式稳定，但灵活性不够；每新增一种问题类型，都要改逻辑、改接口、改分支。

而早期智能体方案则走向了另一个极端：把所有事情都交给一个 Agent。用户问一句，Agent 自己判断要不要查数据库、要不要生成 SQL、要不要调用工具、要不要总结。这样做看似灵活，但在复杂业务场景里很容易失控。原因也很简单：单 Agent 同时承担“规划者、执行者、校验者、解释者”的角色，一旦上下文变长、工具变多、规则变复杂，系统稳定性会快速下降。

JiuwenClaw Coordination 更适合放在两者之间。它既不是把流程完全写死，也不是把所有判断都交给一个 Agent 自由发挥，而是通过智能体协作、技能封装和工具编排，把复杂任务拆成多个可管理的执行单元。

用医疗设备采购分析来举例，一个完整任务可以被拆成几类职责：

这些职责如果都放在一个 Agent 里，系统提示词会变得非常庞大，且边界很模糊。而 Coordination 的思路是让不同 Agent 承担不同角色，再由协同机制把它们串起来。

也就是说，JiuwenClaw Coordination 更像一个“智能体任务调度中枢”。它关注的不是某一次回复是否漂亮，而是整个任务是否被正确拆解、正确分发、正确执行，并且能够留下可复盘的过程记录。

2.2 从组件上看：Agent、Skill、Plugin、Session、Log 共同构成协同闭环

如果只说“协同运行层”，可能还是有点抽象。我们可以把 JiuwenClaw Coordination 拆成几个更具体的构成部分来看。

第一个是 Agent。Agent 是任务角色的载体。它不只是一个模型实例，更像是一个被赋予特定职责、上下文和工具边界的业务角色。例如在医疗设备采购分析系统中，我们可以设计 Planner Agent、SQL Agent、Data Agent、BI Agent 和 Report Agent。Planner Agent 负责理解任务和拆解流程，SQL Agent 负责生成符合口径的查询语句，Data Agent 负责调用数据库工具，BI Agent 负责解释指标，Report Agent 负责把结果整理成业务报告。每个 Agent 的能力范围越清晰，整个系统就越容易调试和维护。

第二个是 Skill。Skill 是可复用能力的封装。它和临时 Prompt 最大的区别在于，Prompt 更像一次性的指令，而 Skill 更像经过沉淀的能力模块。比如“医疗设备明细抽取”“采购 SQL 生成”“金额字段归一化”“公告类型判断”“供应商排名分析”都可以沉淀成 Skill。当业务不断迭代时，我们不应该把所有经验都塞进一个越来越长的提示词里，而是应该把稳定的能力逐渐沉淀为可复用、可组合、可演进的 Skill。

第三个是 Plugin / Tool。这是智能体连接真实业务系统的入口。企业场景里，智能体不能只停留在文本生成层，它必须能够调用数据库、读取文件、执行脚本、访问浏览器服务、调用 MCP 或内部接口。比如你的 ChatBI 链路中，SQL 执行插件、DMS MCP、页面生成服务，本质上都属于工具层能力。Coordination 的作用，是让这些工具不是被孤立调用，而是在任务链路中被合适的 Agent 在合适的时机调用。

第四个是 Session。Session 解决的是上下文连续性问题。企业任务往往不是一次调用就结束，用户可能会追问“那南昌市具体有哪些项目？”“把供应商排名也列出来”“金额按区间再分一下”。如果没有会话上下文，系统每次都要重新理解任务，甚至可能丢失之前的查询条件。Coordination 中的 Session 能够帮助系统维护任务过程中的上下文状态，让多轮交互不是简单拼接历史，而是围绕同一个业务任务持续推进。

第五个是 Log / Trace。这是企业级落地里非常重要的一环。智能体系统不能只是给答案，还要能解释答案的来源。对于数据分析任务来说，我们需要知道它用了什么 SQL、查询了哪张表、返回了多少行、哪个 Agent 做了指标解释、哪个步骤发生过异常。日志不仅用于排错，也用于审计和复盘。尤其在采购分析、招投标辅助、医疗设备价格分析这类场景里，结论必须可追踪，不能只靠模型“生成得像”。

这几个组件放在一起，就形成了一个比较完整的协同闭环：

这也是 JiuwenClaw Coordination 相比普通 Agent 对话更值得关注的地方。它不是单点增强，而是在为企业智能体系统补齐“运行机制”。

2.3 在医疗设备采购分析场景中的整体架构设计

接下来我们把这个架构落到具体业务里。

我这里选择的业务场景是：基于医疗设备采购数据的智能分析系统。这个场景一方面有足够真实的业务复杂度，另一方面也比较适合展示 Coordination 的价值。因为它不是单纯问答，也不是单纯 SQL 查询，而是一条从业务意图到结构化结果再到分析报告的完整链路。

假设用户提出这样一个问题：

帮我分析 2025 年江西省 CT 设备采购情况，包括公告数量、涉及城市、主要供应商和采购金额分布。

在传统 ChatBot 模式下，模型可能直接开始回答。如果没有调用真实数据，它就会编造；如果让它直接生成 SQL，又可能忽略统计口径；如果让它同时查询和分析，又可能出现工具失败后继续输出结论的问题。

在 Coordination 架构下，这个任务会被拆成多个环节。

首先，Planner Agent 会识别这是一个采购数据分析任务，而不是普通知识问答。它需要提取时间范围、地域条件、设备名称、分析指标和输出形式。这里要特别注意，Planner Agent 不应该直接生成最终答案，它的职责是把自然语言问题变成结构化任务计划。

例如：

{
  "task_type": "procurement_bi_analysis",
  "domain": "medical_device_procurement",
  "filters": {
    "province": "江西省",
    "device_name": "CT",
    "publish_time_start": "2025-01-01",
    "publish_time_end": "2026-01-01"
  },
  "metrics": [
    "公告数量",
    "涉及城市数",
    "供应商数量",
    "采购金额"
  ],
  "dimensions": [
    "city",
    "vendor_name"
  ],
  "next_agent": "sql_agent"
}

然后，SQL Agent 接收这个任务计划，结合表结构和统计口径生成 SQL。在你的医疗设备采购宽表里，类似 dws_notice_medical_device_items_di 这样的明细表是比较适合做分析的，因为它保留了公告、设备、供应商、地区、金额等字段。但是 SQL Agent 必须遵守明确规则：只能生成 SELECT；时间过滤使用 publish_time；公告数量使用 COUNT(DISTINCT notice_id)；明细数量才使用 COUNT(*)；金额统计要考虑空值；原始明细查询必须加 LIMIT。

这一步是非常典型的企业约束。很多智能体系统失败，不是因为模型不会写 SQL，而是因为它不知道业务口径。比如公告数量和设备明细数量不是一回事；一个公告可能包含多个设备，一条设备明细也不等于一个采购项目。如果这些口径没有在 Coordination 的 Agent 或 Skill 中固定下来，后续报告就会出现看似合理但实际错误的结论。

接着，Data Agent 负责执行查询。它不需要解释业务含义，也不应该擅自改 SQL。它只负责调用数据库工具或 MCP 服务，并把结果以标准结构返回。这样做的好处是职责清楚：SQL Agent 负责“生成什么查询”，Data Agent 负责“可靠执行查询”，BI Agent 负责“解释查询结果”。一旦某一步失败，系统也能明确知道问题出在哪里。

随后，BI Agent 对返回结果做指标解释。它不是简单把表格翻译成自然语言，而是要根据业务语义分析数据。例如，哪个城市采购更活跃，供应商集中度是否较高，金额分布是否存在头部项目，是否需要进一步按设备品牌或型号拆分。BI Agent 的能力重点是“数据解释”，不是“数据获取”。

最后，Report Agent 把分析结果组织成适合业务人员阅读的报告。这里可以输出摘要、关键发现、数据表格、风险提示和进一步分析建议。如果接入页面生成服务，还可以继续把结果渲染成 BI 看板或可分享页面。

整体流程可以表示为：

这就是 Coordination 在业务架构中的实际形态。它不是把所有能力压到一个 Agent 身上，而是通过多角色协作，让每一步都更清楚、更稳定、更容易复盘。

2.5 为什么这个架构更适合企业级场景？

这套架构最重要的价值，是把智能体能力从“模型输出”提升到了“工程运行”。

在企业场景里，一个系统能不能上线，不只看它能不能在 Demo 中回答一个漂亮问题，更要看它能不能长期稳定处理不同问题。对于医疗设备采购分析这样的场景，用户的问题可能非常灵活：

比如：近三年MRI设备采购趋势如何？某供应商在哪些城市中标较多？不同品牌CT设备的价格区间有什么差异？

这些问题表面上都在问采购数据，但背后的 SQL 形态完全不同。有的是单值统计，有的是分组统计，有的是 TopN，有的是明细查询，有的是时间趋势。企业智能体要处理这些问题，必须具备稳定的任务拆解能力和查询规划能力，而不是每次都临时让模型自由发挥。

Coordination 架构的优势就在这里。

它可以把相对稳定的业务规则沉淀下来，比如：

公告数量 = COUNT(DISTINCT notice_id) 明细数量 = COUNT(*) 总金额 = SUM(COALESCE(total_price, 0)) 时间字段 = publish_time 设备名称过滤 = device_name LIKE 条件 明细查询必须 LIMIT 只允许 SELECT 单语句

这些规则可以进入 SQL Agent 的职责边界，也可以进一步沉淀成 Skill。这样，每一次查询都不是从零开始，而是在统一口径下执行。

同时，这套架构也更利于扩展。今天我们做的是 CT 设备采购分析，明天可以扩展到 MRI、DR、彩超、内镜、监护仪；今天分析的是江西省，明天可以分析全国或某个地市；今天输出的是文字报告，后面可以进一步接入页面生成服务，输出可视化看板。这些变化不需要推翻整个系统，只需要扩展 Agent、Skill 或工具链。

更重要的是，它具备可追踪性。每一次用户提问之后，系统应该能留下完整记录：Planner 如何理解任务，SQL Agent 生成了什么 SQL，Data Agent 返回了哪些数据，BI Agent 做了什么解释，最终 Report Agent 如何组织结论。只有这样，智能体系统才有可能被业务部门信任。

这也是我认为 JiuwenClaw Coordination 值得单独拿出来讲的原因。它不是一个“锦上添花”的功能，而是企业级 Agent 从原型走向落地时必须补上的那一层能力。

三、进入 JiuwenClaw 实战：从界面开始搭建 Coordination 任务链路

前面两章我们已经把问题和架构讲清楚了：企业智能体真正难的地方，不是让模型单次回答得更漂亮，而是让多个 Agent、Skill、Plugin 和业务系统能够围绕一个任务稳定协同起来。

从这一章开始，我们正式进入 JiuwenClaw 的实际操作演示。

围绕一个具体业务任务来展开：

基于医疗设备采购数据，完成一次“2025 年江西省 CT 设备采购情况分析”。

这个任务并不复杂到不可控，但足够代表企业场景。它既需要理解用户意图，也需要生成 SQL、调用数据工具、分析结果、输出报告，非常适合作为 Coordination 的演示案例。

3.1环境准备

通过pip可以直接安装JiuwenClaw：

# 创建名为 JiuwenClaw 的虚拟环境
python -m venv jiuwenclaw

# 激活 JiuwenClaw 虚拟环境（选择对应系统）
jiuwenclaw\Scripts\activate      # Windows
source jiuwenclaw/bin/activate   # MacOS

# 安装 JiuwenClaw
pip install jiuwenclaw

快速启动：

# 初始化 JiuwenClaw（首次启动）
jiuwenclaw-init

# 启动 JiuwenClaw
jiuwenclaw-start

JiuwenClaw提供了Web UI方便用户与AgentTeam交互，打开浏览器访问http://localhost:5173：

可以看到整个JiuwenClaw界面，之后点击配置信息”，点击“模型配置”即可配置想用的模型

配置好后可以点击"测试”看模型是否可用：

提示如图的“配置有效”，保存即可正常使用。

之后我们回到主界面，可以看到主界面有集群模式：

点击即可。

按钮	模式	适用场景
规划模式	agent.plan	规划模式，单任务规划
性能模式	agent.fast	智能执行，快速响应
集群模式	team	集群模式，多 Agent 协作

点击后进入Team模式，当你发送第一条消息时创建Team Agent实例。

3.2设计 Coordination 的 Agent 分工

在正式执行任务之前，我们需要先明确这次演示中有哪些 Agent 参与协作。

对于“医疗设备采购 ChatBI 分析”这个任务，至少设计五类 Agent。

1. Planner Agent：任务规划者

Planner Agent 是整个链路的入口角色。它不负责生成 SQL，也不直接分析结果，而是先判断用户问题属于什么任务类型。

例如用户输入：

帮我分析 2025 年江西省 CT 设备采购情况。

Planner Agent 需要识别出：

{
  "task_type": "database_analysis",
  "domain": "medical_device_procurement",
  "intent": "procurement_bi_analysis",
  "need_sql": true,
  "need_report": true
}

同时，它还要提取过滤条件、指标和维度：

{
  "filters": {
    "province": "江西省",
    "device_name": "CT",
    "publish_time_start": "2025-01-01",
    "publish_time_end": "2026-01-01"
  },
  "metrics": [
    "notice_count",
    "city_count",
    "vendor_count",
    "total_amount"
  ],
  "dimensions": [
    "city",
    "vendor_name"
  ]
}

Planner Agent 的职责边界要非常清晰： 它只做任务理解和规划，不直接输出最终业务结论。

这样做的好处是，后续每一步都可以基于 Planner 的结构化结果继续执行，而不是让每个 Agent 都重新理解一遍用户问题。

---

2. SQL Agent：查询生成者

SQL Agent 接收 Planner Agent 的任务计划后，负责生成符合业务口径的 SQL。

这里最重要的不是“会不会写 SQL”，而是“能不能遵守业务规则”。

例如在医疗设备采购明细表中，我们要提前固定几个关键口径：

公告数量 = COUNT(DISTINCT notice_id)
设备明细数量 = COUNT(*)
供应商数量 = COUNT(DISTINCT vendor_name)
采购金额 = SUM(COALESCE(total_price, 0))
时间过滤字段 = publish_time
地区过滤字段 = province / city
设备过滤字段 = device_name

对于本次任务，SQL Agent 可以生成几类查询。

第一类是按城市统计：

SELECT
    city,
    COUNT(DISTINCT notice_id) AS notice_count,
    COUNT(DISTINCT vendor_name) AS vendor_count,
    SUM(COALESCE(total_price, 0)) AS total_amount
FROM dws_notice_medical_device_items_di
WHERE province = '江西省'
  AND device_name LIKE '%CT%'
  AND publish_time >= '2025-01-01'
  AND publish_time < '2026-01-01'
GROUP BY city
ORDER BY notice_count DESC
LIMIT 50;

第二类是供应商 TopN：

SELECT
    vendor_name,
    COUNT(DISTINCT notice_id) AS notice_count,
    SUM(COALESCE(total_price, 0)) AS total_amount
FROM dws_notice_medical_device_items_di
WHERE province = '江西省'
  AND device_name LIKE '%CT%'
  AND publish_time >= '2025-01-01'
  AND publish_time < '2026-01-01'
  AND vendor_name IS NOT NULL
  AND vendor_name <> ''
GROUP BY vendor_name
ORDER BY notice_count DESC, total_amount DESC
LIMIT 20;

第三类是总体指标：

SELECT
    COUNT(DISTINCT notice_id) AS notice_count,
    COUNT(DISTINCT city) AS city_count,
    COUNT(DISTINCT vendor_name) AS vendor_count,
    SUM(COALESCE(total_price, 0)) AS total_amount
FROM dws_notice_medical_device_items_di
WHERE province = '江西省'
  AND device_name LIKE '%CT%'
  AND publish_time >= '2025-01-01'
  AND publish_time < '2026-01-01';

在实际系统中，SQL Agent 最好不要直接自由生成无限 SQL，而是基于几类模板来生成：

单值统计
分组统计
TopN 排名
时间趋势
明细查询
条件组合分析

这样可以降低 SQL 生成的不确定性，也更符合企业系统的安全要求。

---

3. Data Agent：数据执行者

Data Agent 的职责是调用数据库插件或 MCP 服务执行 SQL。

在 Coordination 设计中，Data Agent 不负责“想 SQL”，也不负责“解释数据”。它只负责执行和返回标准结构。

建议工具返回格式保持统一，例如：

{
  "status": true,
  "sql": "SELECT city, COUNT(DISTINCT notice_id) ...",
  "row_count": 11,
  "rows": [
    {
      "city": "南昌市",
      "notice_count": 32,
      "vendor_count": 18,
      "total_amount": 18500000
    }
  ],
  "error": null
}

这样做有两个好处。

第一，BI Agent 可以稳定消费 Data Agent 的输出，不需要猜测返回格式。

第二，如果执行失败，可以明确把错误留在 Data Agent 这一层，而不是让后面的分析 Agent 在没有数据的情况下继续编造结论。

企业智能体系统里有一条非常重要的规则：

没有拿到真实数据，就不要生成数据结论。

这条规则必须体现在 Coordination 链路中，而不是靠模型自觉。

---

4. BI Agent：指标分析者

BI Agent 接收 Data Agent 返回的数据后，负责做业务解释。

它的重点不是复述数据，而是回答：

哪些城市采购更活跃？
供应商是否集中？
采购金额是否集中在少数城市？
是否存在异常高金额项目？
后续是否需要进一步下钻？

比如，如果查询结果显示南昌市公告数量最高，BI Agent 不应该只写：

南昌市公告数量最高。

而应该进一步解释：

南昌市作为省会城市，医疗机构数量和大型医院资源较集中，因此在 CT 等大型影像设备采购中往往表现出更高活跃度。后续可以结合采购单位级别、医院类型和设备型号进一步判断其采购需求是来自新增配置、设备更新还是专科能力建设。

当然，BI Agent 的分析也必须谨慎。它可以提出“可能原因”和“进一步分析方向”，但不能把没有数据支撑的推测写成确定结论。

这也是严谨技术文章中要特别注意的一点： 业务分析可以有解释，但必须区分事实、推断和建议。

---

5. Report Agent：报告生成者

Report Agent 是最终输出层。

它负责把前面多个 Agent 的执行结果组织成一份清晰的分析报告。报告可以包括：

分析背景
查询条件
核心指标
城市分布
供应商排名
金额分布
关键发现
进一步分析建议

在实际业务系统中，Report Agent 可以根据不同使用对象输出不同风格。

如果面向运营人员，可以偏简洁：

重点看指标、排名和异常。

如果面向管理层，可以偏结论：

重点看趋势、集中度和决策建议。

如果面向数据分析师，可以保留 SQL 和数据口径：

重点看统计逻辑、字段来源和可复核路径。

这就体现了 Coordination 的另一个好处：同一套数据链路，可以在最后输出层适配不同业务角色，而不用改动前面的查询和执行逻辑。

3.3JiuwenClaw执行实战效果

如果你的 JiuwenClaw 已经可以通过内置插件、DMS MCP 或 SQL Runner 真实查询数据库，那么可以用下面这版：

请调用或使用 JiuwenClaw 内置的 teamskill-creator skill，为“医疗设备采购 ChatBI 分析”创建一个 Team Skill。

Team Skill 名称：
medical_procurement_chatbi_team

目标：
将医疗设备采购分析任务拆解为 Planner、SQL、Data、BI、Report 五类团队成员协作完成。

请生成 Team Skill 的完整定义，包括：
1. team skill 名称
2. 适用场景
3. team leader 职责
4. teammate 成员清单
5. 每个 teammate 的职责、输入、输出和限制
6. 成员之间的依赖关系
7. 任务板拆解规则
8. 失败处理规则
9. 输出报告格式
10. 如何将模拟数据输入替换为真实数据库查询结果

效果如下所示：

现在我们就可以开始询问：帮我分析 2025 年江西省 CT 设备采购情况，包括公告数量、涉及城市、主要供应商和采购金额分布。

右侧“团队成员”区域已经出现了：

这说明系统不是一个 team_leader 在模拟多个角色，而是已经通过 spawn_member 创建了多个成员。

这就是 Team-level Coordination 最直观的标志。从工具调用记录可以看到，JiuwenClaw 在集群模式下调用了 spawn_member 创建团队成员，并通过 send_message 向成员分发任务。这意味着当前任务已经从 Prompt 层面的角色模拟，进入到运行时层面的团队协作。

右侧任务事件日志里可以看到：

这非常关键。

它说明任务不是一次性完成的，而是被拆成了多个子任务，并且有明确的状态变化。

这就是 Coordination 的任务编排能力。

这几个成员分别对应前面设计的五类角色：

团队成员	对应职责
planner-1	任务规划，识别业务问题、过滤条件、指标和维度
sql-engineer-1	根据任务规划生成 SQL 或 SQL 模板
data-analyst-1	基于模拟数据或真实查询结果完成统计计算
bi-specialist-1	生成指标解释、图表建议和业务洞察
report-writer-1	汇总前面结果，生成最终业务报告

从界面右侧的“团队成员”面板可以看到，这些成员已经不再只是 Prompt 中的角色名称，而是真正进入了任务运行时。更关键的是，任务事件日志中也出现了明确的任务状态变化：

task_plan completed
task_sql completed
task_data claimed
task_charts created
task_report created

这说明任务已经被拆成多个子任务，并且按照依赖关系逐步推进。

在执行过程中，下游成员还会根据前置任务状态判断自己是否可以继续。例如 bi-specialist-1 会提示当前被 task_data 阻塞，需要等待数据清洗完成后再执行图表生成与洞察输出；report-writer-1 则会等待 task_charts 和 task_plan 完成之后，再生成最终报告。

这就是 Team-level Coordination 和 Prompt-level Coordination 的本质区别。

Prompt-level Coordination 更像是“一个 Agent 模拟多个角色说话”； Team-level Coordination 则是“多个真实成员围绕任务状态进行协作”。

对于企业级场景来说，后者的价值更大。因为真实业务任务往往不是一次性输出，而是存在前后依赖、状态阻塞、结果汇报和异常处理。只有当系统能够显式管理这些任务状态时，多智能体协作才有进入生产流程的可能。

更进一步看，Team-level Coordination 并不只是把几个成员名字列出来，而是让任务真正进入一条可执行的 DAG 链路中。也就是说，任务不是简单地从上到下“顺序输出文本”，而是在不同成员之间围绕依赖关系逐步流转。

从执行过程可以看到，planner-1 首先完成 task_plan，并将分析计划写入团队工作空间。这个阶段的输出并不是最终报告，而是一份结构化的分析计划，例如时间范围、过滤条件、核心指标、分析模块和图表建议。随后 sql-engineer-1 接收到任务通知，读取 analysis_plan.json，并根据规划结果生成 queries.sql。这里可以看到一个很重要的细节：SQL Engineer 并不是自由发挥，而是基于 Planner 已经确认的分析目标继续向下执行。

这一点在企业场景里非常重要。因为如果每个成员都重新理解一遍用户问题，系统很容易出现口径漂移。例如 Planner 认为要分析“2025 年江西省 CT 设备采购”，但 SQL Agent 如果重新理解成“全国 CT 采购”或“所有医疗设备采购”，后续分析就会失真。通过团队工作空间共享 analysis_plan.json，后续成员可以基于同一份任务定义继续执行，从而降低多智能体协作中的语义漂移风险。

从界面日志中也可以看到，sql-engineer-1 完成后，task_data 才被解锁并分派给 data-analyst-1。这说明任务依赖关系已经被系统显式管理起来。

这条链路看似简单，但它其实已经具备了企业级任务编排的基本形态：上游任务产出中间结果，下游任务读取中间结果并继续处理；如果上游未完成，下游成员就保持等待状态，而不是盲目执行。

在这轮演示里，data-analyst-1 接收的是模拟 JSON 数据。它并没有直接写报告，而是先完成数据清洗和统计汇总，并输出了多个中间文件：

其中，cleaned_data.csv 用于保存清洗后的结构化数据；data_summary.json 用于保存聚合分析结果；execution.log.md 用于记录数据处理过程、异常检测和执行日志。这个设计很符合企业数据任务的工程习惯：原始数据、处理结果和执行日志要分离保存，而不是全部混在最终回答里。

从 data-analyst-1 的执行摘要可以看到，本轮模拟数据共 8 条记录，清洗后全部通过过滤，无缺失值和明显异常值。汇总指标包括采购总金额 4,390 万元、平均单价 548.75 万元、涉及 6 个城市和 5 家供应商。这说明 Data Agent 的职责已经从“接收数据”推进到了“结构化计算”，并为后续 BI 分析提供了可信的中间结果。

接下来，bi-specialist-1 在 task_data 完成后开始执行 task_charts。它读取 cleaned_data.csv、data_summary.json 和 analysis_plan.json，并生成了 6 张可视化图表和一份洞察文件：

这一步很关键。因为它说明 BI Specialist 并不是只做文字分析，而是承担了可视化与洞察生成的角色。对于 ChatBI 场景来说，业务人员通常不只需要一个结论，还需要看到指标分布、排名、趋势和异常点。通过将图表统一输出到 charts/ 目录，后续 Report Writer 就可以在最终报告中引用这些图表，而不需要重新计算。

从执行结果可以看到，本轮图表覆盖了月度趋势、城市分布、供应商排名、品牌份额、金额区间和供应商规模关系。这基本对应了采购分析中最常用的几类视角：

时间：采购是否有明显周期变化
区域：哪些城市采购更活跃
供应商：市场份额是否集中
品牌：国产与进口品牌格局如何
金额：采购预算集中在哪些区间
关系：供应商规模与采购金额是否存在关联

这一步也让 JiuwenClaw 的 Coordination 从“任务执行”进一步走向“业务分析交付”。因为图表和洞察不是附属物，而是 ChatBI 最终面向业务人员时非常重要的表达形式。

最后，report-writer-1 在 task_charts 完成后接手 task_report。它读取 final_report.md 模板、analysis_plan.json、data_summary.json、insights.md 以及 charts/ 目录中的图表，最终生成完整的业务分析报告。

这就形成了一条完整的企业任务交付链路：从用户问题到任务规划，从 SQL 设计到数据清洗，从指标分析到图表生成，再到最终报告输出。更重要的是，整个过程不是一次模型回复，而是多个团队成员围绕同一个工作空间协同完成。

3.4任务输出文件：从对话结果到团队工作空间

在任务完成后，我继续追问了一句：请问输出的文件在哪个目录？JiuwenClaw 返回了团队共享工作空间路径.

并列出了本轮任务的主要交付文件：

final_report.md      —— 最终业务分析报告
analysis_plan.json   —— 分析计划
queries.sql          —— SQL 查询脚本
cleaned_data.csv     —— 清洗后数据
data_summary.json    —— 结构化分析结果
insights.md          —— 数据洞察
charts/              —— 6 张 PNG 可视化图表
execution.log.md     —— 执行日志

这个结果非常值得在文章中单独强调。因为它说明 JiuwenClaw Coordination 的输出不是临时展示在聊天窗口里的文本，而是可以落到工作空间中的文件资产。对于企业场景来说，这一点比单次回答更重要。

如果一个智能体系统只是回答一句话，那么它很难进入真实业务流程；但如果它能够生成可追踪的中间文件、可复用的 SQL、可审计的执行日志、可汇报的 Markdown 报告和可视化图表，那么它就开始接近真正的“业务执行系统”。

这里其实也体现了 Team-level Coordination 的一个核心优势：每个成员不是只在对话里“说自己完成了什么”，而是会把自己的结果沉淀到共享工作空间中。Planner 产出 analysis_plan.json，SQL Engineer 产出 queries.sql，Data Analyst 产出 cleaned_data.csv 和 data_summary.json，BI Specialist 产出 charts/ 与 insights.md，Report Writer 最终整合为 final_report.md。

换句话说，这条链路的交付物是分层的：

阶段	团队成员	主要交付物	作用
任务规划	planner-1	analysis_plan.json	固定任务目标、指标、维度和图表方案
查询设计	sql-engineer-1	queries.sql	保存 SQL 查询逻辑，便于后续接入真实数据库
数据处理	data-analyst-1	cleaned_data.csv / data_summary.json / execution.log.md	保存清洗数据、统计结果和执行过程
BI 分析	bi-specialist-1	charts/ / insights.md	生成图表和业务洞察
报告生成	report-writer-1	final_report.md	汇总生成最终业务报告

这张表可以作为本节的一个关键总结。它能让读者直观看到，Coordination 的价值不是把 Agent 名字换得更专业，而是把复杂任务拆成可交付、可检查、可复用的中间资产。

3.5最终报告效果：从模拟数据生成业务分析报告

打开 final_report.md 后，可以看到 JiuwenClaw 已经生成了一份结构相对完整的采购业务分析报告。报告标题为《2025 年江西省 CT 设备采购业务分析报告》，并明确给出了报告日期、数据范围、数据来源和编制单位。

报告开头部分直接给出了核心结论。例如，本轮模拟数据中，2025 年 2 月至 9 月江西省 CT 设备采购共 8 笔，总金额为 4,390 万元，平均单价为 548.75 万元/台，涉及 6 个地级市、5 家中标供应商和 5 个 CT 品牌。

这些结论来自前面 Data Analyst 输出的 data_summary.json，而不是 Report Writer 自己凭空总结。这个逻辑非常关键：Report Agent 的职责是组织和表达，而不是重新计算或编造数据。

在数据概览部分，报告通过表格展示了核心指标：

采购公告总数：8 笔
采购总金额：4,390 万元
采购设备总台数：8 台
平均单价：548.75 万元/台
涉及地级市：6 个
中标供应商：5 家
CT 品牌：5 个
数据时间跨度：2025-02 至 2025-09

这类指标非常适合采购管理、市场分析和运营看板使用。因为它不是单纯告诉业务人员“情况如何”，而是给出了可以继续下钻的统计入口。

在城市分布分析部分，报告进一步展示了各地市采购数量和金额分布，并嵌入了对应图表。从结果看，赣州市采购金额为 1,330 万元，占比 30.3%；南昌市采购金额为 1,200 万元，占比 27.3%；两地合计占比 57.6%。这个结论帮助业务人员快速识别采购活跃区域，也可以为后续区域市场分析提供线索。

值得注意的是，报告中还加入了“分析”段落。例如，赣州市单笔均价高于全省均值，显示出对高端设备的偏好；南昌市作为省会，采购品牌选择更多元。这类内容属于业务解释，但仍然基于图表和统计结果展开，没有脱离数据范围。

这正是我们希望 BI Agent 和 Report Agent 做到的事情： 既不是机械复述表格，也不是无依据扩写，而是在数据事实之上做适度业务解释。

3.6 JiuwenClaw Coordination 的工程价值

到这里，本轮演示已经形成了一个比较完整的闭环：

四、从模拟数据走向真实业务：让 Coordination 接入企业数据链路

到这里，其实整篇文章的核心链路已经跑通了。JiuwenClaw 在集群模式下完成了团队成员创建、任务拆解、DAG 流转、模拟数据分析、图表生成和最终报告输出。虽然当前演示使用的是模拟 JSON 数据，但这一步并不是“玩具示例”，而是在验证企业级智能体落地前最关键的一件事：这条多智能体协作链路是否可控、可追踪、可复用。从结果来看，Planner 产出了 analysis_plan.json，SQL Engineer 产出了 queries.sql，Data Analyst 产出了 cleaned_data.csv 和 data_summary.json，BI Specialist 产出了 charts/ 和 insights.md，Report Writer 最终生成了 final_report.md。这意味着每个成员都有明确职责，每个阶段都有中间资产，每个结果都可以被后续成员继续消费。后续真正接入企业数据库时，并不需要推翻这套流程，只需要把 Data Agent 的输入从模拟 raw_data.json 替换成 SQL Runner、DMS MCP 或内部数据服务返回的真实 rows 即可。

对于医疗设备采购 ChatBI 场景来说，下一步的工程重点就是把 queries.sql 接到真实业务表，例如 dws_notice_medical_device_items_di，并增加必要的 SQL 安全校验，包括只允许 SELECT、限制白名单表、禁止多语句、明细查询强制 LIMIT、统计口径固定为 COUNT(DISTINCT notice_id) 和 SUM(COALESCE(total_price,0)) 等。这样一来，用户输入“分析 2025 年江西省 CT 设备采购情况”时，系统就可以从任务规划开始，自动生成 SQL，调用真实数据查询，完成指标汇总、图表生成和报告输出。更重要的是，整个过程不再是一个黑箱回答，而是一条有任务状态、有成员分工、有文件产物、有日志记录的企业级执行链路。这也是 JiuwenClaw Coordination 最值得关注的价值：它让智能体从“会回答问题”进一步走向“能组织任务、能协同执行、能沉淀结果”的业务系统形态。对于招采、医疗设备采购、ChatBI、知识抽取这类复杂场景来说，这一步非常关键，因为真正能落地的不是一个更会聊天的模型，而是一套能够稳定接入企业流程、持续复用业务能力、并且可以被审计和复盘的多智能体协同系统。

参考资料：

• openJiuwen - 开源代码托管,代码协作 - AtomGit | GitCode
• openJiuwen