多智能体编排实战：从需求拆解到7×24小时自动交付的完整指南

一、为什么需要多智能体协同系统

在大模型应用从单轮对话走向复杂任务自动化的过程中，开发者很快会遇到一个瓶颈：单一模型调用无法完成需要多步骤、多角色、长周期协作的任务。例如“调研市场—设计方案—开发实现—测试验证—交付汇报”这类完整流程，任何一个环节的偏差都可能导致整体失败。

多智能体系统的核心价值在于将复杂任务拆解为多个可独立执行的子任务，由不同的智能体分别承担不同角色，通过协作完成整体目标。这类似于软件工程中的微服务架构，每个服务负责单一职责，服务之间通过明确接口通信，最终组合出完整的业务能力。

但多智能体系统对底层模型提出了严苛要求。单一对话中的理解能力只是基础，真正的挑战在于三个方面：

1. 长任务稳定性：几十轮甚至上百轮对话后，模型仍能保持原有的输出质量和决策逻辑；
2. 超长上下文保持：任务前期产生的关键信息（如需求细节、调研结论）在后期仍能被准确引用；
3. 跨轮次任务链路：一个角色输出的结果能被下一个角色正确接收、理解并继续处理。

下文将以一个具体的“竞品价格监控看板”需求为例，完整展示这套系统从设计到运行的整个过程。

二、整体架构与工作流设计

在设计多智能体系统前，需先明确几个关键决策：

决策一：消息入口选型。 为保证7×24小时运行，消息入口需要具备异步能力，即用户发出需求后无需持续在线等待结果。常见的方案包括企业微信机器人、钉钉自定义机器人、飞书机器人或简单的Webhook服务。在本方案中，以飞书群机器人作为统一入口和结果回传通道。

决策二：智能体角色定义。 参考经典项目管理角色，定义四个核心智能体：

角色	职责	输出物
总管（协调者）	接收需求、解析意图、拆分任务、调度下游智能体、汇总结果	任务拆解清单、进度更新
市场分析师	进行竞品调研、市场分析、需求可行性评估	市场调研报告
产品设计师	基于调研结果进行功能设计、交互流程规划	产品设计文档
开发工程师	负责代码生成、接口调试、系统部署	可运行代码及部署说明

决策三：上下文传递机制。 多智能体间的信息传递不能依赖模型隐式记忆，必须通过显式消息传递。每个智能体的输出需结构化（如Markdown文档），并在触发下一智能体时作为上下文注入。

整体工作流程图如下：

用户（飞书消息） → 总管智能体
    ├─ 任务拆解 → 分配至市场分析师
    │   ├─ 分析师完成调研 → 报告回传总管 + 抄送用户
    │   └─ 总管审核无误 → 转至产品设计师
    ├─ 产品设计师产出方案 → 回传总管 → 转至开发工程师
    ├─ 开发工程师生成代码 → 回传总管
    └─ 总管汇总交付物 → 飞书通知用户

下面以具体案例逐步演示。

三、实战案例：竞品价格监控看板

3.1 需求下达与初步解析

在飞书群中向总管智能体发送如下需求：

需求：搭建一个竞品价格监控看板。支持录入竞品链接，定时采集价格/原价/优惠/库存状态，提供趋势图和异常波动标记，并在低价、剧烈波动、缺货时通过飞书预警，支持Excel导出。

总管接收到消息后，首先进行意图识别与任务拆解。该需求包含以下几个核心子任务：

1. 竞品数据采集模块（需确定数据源、采集频率、解析规则）；
2. 数据存储方案（需考虑数据量、查询性能、扩展性）；
3. 看板可视化（趋势图、波动标记）；
4. 预警通知机制（多条件触发、防重复通知）；
5. 数据导出功能（Excel格式）。

总管将调研任务分配给市场分析师，同时告知用户流程已启动。

3.2 市场调研阶段

市场分析师收到任务后，会主动展开调研，调研维度包括：

• 目标竞品范围：哪些主流电商平台的竞品数据值得监控？
• 数据可获取性：各平台是否开放API，还是需要采用页面解析方式？
• 字段标准：价格、原价、优惠、库存这些字段在不同平台的定义与差异；
• 现有技术方案：行业常见的爬虫框架、数据处理管线、可视化方案。

分析师输出的调研报告结构如下：

# 竞品价格监控看板——市场调研报告
## 1. 竞品与平台覆盖
- 建议覆盖主流电商平台，重点监控TOP 20竞品SKU
- 数据更新频率建议为每小时一次
## 2. 数据采集技术方案
- 优先采用各平台官方开放API（若可用）
- 备选方案：基于无头浏览器的页面结构解析
- 需处理反爬机制，如请求频率控制、验证码识别等
## 3. 字段定义与标准化
- 价格：实时成交价，需区分促销价与日常价
- 原价：商品详情页展示的划线价
- 优惠：满减、优惠券、会员价三类优惠的叠加规则
- 库存状态：有货/无货/预售三种状态
## 4. 技术选型建议
- 数据采集：调度框架+浏览器自动化工具
- 数据存储：时序数据库更适合价格趋势分析
- 可视化：开源BI工具或轻量级前端框架即可实现
- 通知：消息平台机器人Webhook
## 5. 风险评估
- 各平台接口稳定性差异较大
- 页面结构变动可能导致解析失败，需设计巡检机制
- 需关注数据采集频率的合法性边界

报告完成后，分析师将完整报告发送给总管，同时将摘要消息私发给用户，便于用户随时掌握进展。这里的设计要义是：总管与用户都能获取阶段产出，但用户接收的是精简摘要，避免信息过载。

3.3 产品设计阶段

总管收到调研报告后，先进行质量审核。审核要点包括：调研是否覆盖需求中的关键点、技术选型是否合理、是否有明显逻辑遗漏。确认无问题后，将需求原文与调研报告一并转交给产品设计师。

产品设计师的产出是一份可指导开发的技术方案，包含：

# 竞品价格监控看板——产品设计方案
## 1. 系统架构
- 采集层：定时任务调度器 + 多平台采集适配器
- 存储层：时序数据库存储价格序列，关系型数据库存储元数据
- 服务层：看板API服务，提供趋势数据、预警规则配置
- 展示层：前端看板页面，支持趋势图与异常标记
- 通知层：消息平台机器人Webhook，支持条件触发
## 2. 功能模块明细
### 2.1 竞品录入
- 支持批量导入竞品链接
- 支持手动添加与编辑
- 对每个链接自动识别所属平台
### 2.2 数据采集定时任务
- 默认每小时采集一次，支持自定义频率
- 采集字段：价格、原价、优惠金额、库存状态
- 采集异常时自动重试，最多3次，仍失败则记录告警
### 2.3 趋势图与异常标记
- 展示30天、7天、24小时三个时间粒度的价格趋势
- 异常标记规则：
  - 单次价格降幅超过5%标记为“价格波动”
  - 连续3次采集价格持续下降标记为“低价趋势”
  - 库存状态从有货变为无货标记为“缺货预警”
### 2.4 飞书预警通知
- 预警条件引擎支持规则配置（如价格低于阈值、波动超限、缺货）
- 每条预警基于SKU维度去重，同一SKU同一预警类型30分钟内不重复推送
### 2.5 Excel导出
- 支持按时间范围导出价格数据
- 导出字段包含：SKU名称、采集时间、价格、原价、优惠、库存状态、平台
## 3. 数据模型设计
- sku表：id、名称、链接、平台、创建时间
- price_record表：id、sku_id、价格、原价、优惠、库存状态、采集时间
- alert_rule表：id、sku_id、条件类型、阈值、启用状态
- alert_log表：id、sku_id、触发类型、触发时间、推送状态
## 4. 接口设计
- POST /api/skus 录入竞品
- GET /api/skus/{id}/price-trend 获取趋势数据
- POST /api/alerts/rules 配置预警规则
- GET /api/export?sku_id=&start=&end= 导出Excel

这份设计文档的价值在于，它将市场调研中的定性信息转化为可以指导开发的定量需求，并明确了数据模型与接口边界。

3.4 开发实现与交付

开发智能体收到产品设计文档后，开始编写代码。在此阶段，需要特别关注以下几点：

代码生成的上下文管理。 开发智能体需要同时读取产品设计文档、需求原文以及可能的历史对话记录，确保生成的代码完全符合设计约束。例如，必须实现设计文档中定义的四个数据表、五个接口，以及预警去重逻辑。

自测与验证。 开发智能体不能只生成代码就结束，还需进行基本的逻辑自查，例如检查定时任务是否正确配置、数据库连接是否可用、接口参数是否与前端约定一致。

以下是一个简化的预警规则判断伪代码示意：

def check_alert(sku, price_record, alert_rules):
    for rule in alert_rules:
        if rule.condition == "PRICE_BELOW":
            if price_record.price <= rule.threshold:
                trigger_alert(sku, "价格低于阈值", price_record.price)
        elif rule.condition == "PRICE_DROP_RATIO":
            drop_ratio = (price_record.previous_price - price_record.price) / price_record.previous_price
            if drop_ratio >= rule.threshold:
                trigger_alert(sku, "价格剧烈波动", f"{drop_ratio:.2%}")
        elif rule.condition == "OUT_OF_STOCK":
            if price_record.stock_status == "无货":
                trigger_alert(sku, "缺货预警", price_record.stock_status)

开发完成后，开发智能体将完整的项目代码、部署说明、环境依赖文件一起打包，回传给总管。

3.5 汇总与最终交付

总管在收到开发交付物后，执行最终审核。审核内容包括：

1. 代码是否覆盖了需求中的全部功能点；
2. 是否提供了完整的部署脚本与环境要求；
3. 是否有基础的使用说明文档。

审核通过后，总管将以下内容整理打包，发送给用户：

• 项目代码压缩包（含依赖配置文件）；
• 部署与启动指南；
• 看板功能清单与后续优化建议。

用户收到交付物后，可直接按指南在本地或服务器上启动服务，完成看板的搭建。

四、关键实践经验总结

4.1 上下文管理：让智能体“不失忆”

在多智能体系统中，上下文管理是决定成败的关键因素。实践中推荐以下策略：

• 显式传递而非依赖隐式记忆：每个智能体的输出必须结构化保存，并在必要时完整传给下一个智能体。禁止让智能体依靠自身记忆去回忆上一轮结果。
• 分段压缩：当上下文过长时（如超过模型窗口限制），需对前期内容进行摘要或提取关键信息，而非截断丢弃。例如，调研报告中“技术选型建议”比完整报告更重要。
• 角色记忆隔离：不同角色的智能体只应看到与自己任务相关的上下文，避免信息干扰。

4.2 任务链路保持：防止“跑偏”

在长达数十轮的对话中，智能体容易逐渐偏离原始需求。以下机制有助于保持任务链路：

• 定期回看原始需求：在每个关键节点（如调研完成、设计完成、开发完成），总管智能体应重新核对原始需求，确保产出未偏离目标。
• 结构化中间产物：所有中间产物使用统一的Markdown格式，标明“需求来源”“当前阶段”“输出内容”等元信息，便于追踪。
• 异常分支处理：当某智能体输出的内容质量低于预期（如调研报告未覆盖关键平台），总管应触发“退回重做”流程，而不是带着低质量输入继续下游任务。

4.3 可靠性保障：应对模型输出不一致

大模型作为非确定性组件，可能在不同轮次对同一问题给出不同答案。为提升整体可靠性，可以采取：

• 固定范本提示：为每个角色提供标准化的提示模板，约束输出格式和内容结构；
• 校验规则注入：在关键阶段加入规则校验，例如检查输出是否包含必填字段、格式是否正确；
• 人工兜底节点：在交付最终结果前设置一个人工审核环节，确保最终交付物的可用性。

agent-agent-">4.4 扩展性思考：从3个Agent到Agent军团

当前案例仅用了4个智能体，但在实际业务中可能需要更多角色，如数据分析师、测试工程师、运维工程师等。扩展的要点在于：

• 角色注册与发现机制：新增角色时无需修改已有角色的代码，只需在总管的角色配置表中注册；
• 依赖关系声明：每个角色需声明自己的输入依赖与输出类型，便于总管自动编排调度顺序；
• 并行执行能力：对于相互独立的调研任务（如同时调研平台A和平台B的数据可获取性），可并行调度多个分析智能体，加速整体流程。

五、结语

本文以一个完整的竞品价格监控看板开发流程为例，展示了多智能体协同系统从需求解析到最终交付的全过程。核心要点可归纳为：

1. 明确的角色分工是任务拆解与执行的基础；
2. 显式的上下文管理保证了跨阶段信息不丢失；
3. 结构化中间产物让每一步可追踪、可审核；
4. 合理的异常处理机制保障了系统的鲁棒性。

这套方法论并不依赖于任何特定的模型或平台，而是遵循通用的软件工程原则。对于希望构建自己Agent军团的开发者而言，建议从小规模场景起步（如2-3个角色），验证流程稳定后再逐步扩展。当任务链路足够健壮、上下文管理足够精细时，7×24小时的自动化交付就不再是理想，而是一个可落地的工程实践。