多Agent龙虾(创新架构)：一句话组建AI打工团队的分工执行深度解析

一、行业背景：从单体LLM到多Agent协作的范式跃迁

1.1 单体模型的瓶颈

大语言模型在过去两年取得了惊人的进步，但在实际落地中，我们始终面临一个核心矛盾：一个模型再强，也只是“一个人在战斗”。 当用户提出一个复杂需求，比如“帮我开发一个基于GraphRAG的智能问答系统”——这个需求天然横跨了战略分析、项目管理、前端架构、算法设计等多个专业领域。让一个LLM同时扮演所有角色，输出往往沦为“大而全却浅尝辄止”的四不像：每一点都沾边，但每一点都不够深入。 这背后的技术根因是： * **上下文窗口的竞争**：当单一Prompt试图承载多个角色的指令，有效上下文被摊薄，模型难以在每个维度都深入。 * **角色混淆**：同一个模型在“战略视角”和“代码实现”之间频繁切换，导致输出风格割裂。 * **缺乏协作结构**：单体模型无法享受“前序角色的输出作为后序角色的输入”这种流水线增益。

1.2 多Agent协作的崛起

2024年以来，从AutoGen到CrewAI，从LangGraph到OpenAI Swarm，多Agent框架如雨后春笋般涌现。但大多数框架停留在“编排层”——它们解决了“谁先谁后”的问题，却没有解决每个Agent凭什么专业的问题。 这就像组建了一个团队，每个成员只有岗位名称，没有专业技能手册。结果就是：5个Agent开会讨论，5个都在说车轱辘话。 多智能体龙虾系统的核心创新，正在于将“角色定义 + 专业技能 + 流水线协作”三者一体化：每个龙虾Agent不只是有一个名字，而是拥有一份完整的SKILL.md技能手册，内含核心技能、辅助技能、软技能的层次化定义，以及具体的应用场景示例。

1.3 为什么是龙虾？

龙虾（Lobster）——甲壳坚硬、钳子分工（一只碎壳、一只切割）、蜕壳重生。这恰好是多Agent系统的隐喻：每个Agent外壳坚固（角色边界清晰），左右钳各有分工（核心技能+辅助技能），且能随业务蜕壳升级（技能体系可迭代）。

---

二、核心技术架构：龙虾团队的“操作系统”

2.1 整体架构概览

``` ┌──────────────────────────────────────────────────────┐ │ 前端 (index.html + app.js) │ │ ┌─────────┐ ┌──────────┐ ┌────────────────────┐ │ │ │ 数字员工 │ │ 开会模式 │ │ WebSocket消息渲染 │ │ │ │ 卡片网格 │ │ 六边形布局 │ │ (agent_start/ │ │ │ │ (10只龙虾)│ │ 气泡发言 │ │ agent_chunk/ │ │ │ └─────────┘ └──────────┘ │ agent_done/ │ │ │ │ multi_agent_ │ │ │ │ complete) │ │ │ └────────────────────┘ │ └──────────────────────┬───────────────────────────────┘ │ WebSocket (ws://localhost:8001/api/chat/ws) ┌──────────────────────┴───────────────────────────────┐ │ 后端 (FastAPI + StreamHandler) │ │ ┌──────────────────────────────────────────────────┐ │ │ │ StreamHandler (核心调度引擎) │ │ │ │ handle_chat() → 路由分发 │ │ │ │ ├── "多数字员工规划" → handle_multi_agent_chat │ │ │ │ ├── "财经分析" → web_agent_chat │ │ │ │ └── "数学画图" → math_agent_chat │ │ │ └──────────────────────────────────────────────────┘ │ │ ┌────────────┐ ┌─────────────┐ ┌──────────────┐ │ │ │ QwenService│ │ SkillLoader │ │ Conversation │ │ │ │ (LLM调用) │ │ (SKILL.md解析)│ │ Manager │ │ │ │ AsyncOpenAI│ │ (脚本执行) │ │ (JSON持久化) │ │ │ └────────────┘ └─────────────┘ └──────────────┘ │ └──────────────────────────────────────────────────────┘ │ ┌────────────────────────┴───────────────────────────────┐ │ 技能层 (skills/ 目录) │ │ 总经理/项目经理/前端工程师/算法工程师/ │ │ 产品经理/ UI设计/数据分析师/个人秘书/ │ │ 客服/财经分析/多数字员工规划/ │ │ 每个目录: SKILL.md + scripts/ + references/ │ └──────────────────────────────────────────────────────────┘ ```

2.2 三层架构的职责划分

| 层次 | 组件 | 核心职责 | | :--- | :--- | :--- | | **交互层** | 前端HTML/CSS/JS | 数字员工卡片展示、开会模式、WebSocket消息渲染、Markdown/LaTeX排版 | | **调度层** | StreamHandler | 多Agent流水线编排、WebSocket消息协议、上下文传递、对话持久化 | | **技能层** | SKILL.md体系 | 角色定义、技能分类、参考文档、可执行脚本 | 这种三层分离的设计使得：换模型不影响协作逻辑，改协作流程不影响技能定义，增减员工只改SKILL.md。

---

三、分工执行的核心机制：5阶段顺序流水线

3.1 流水线设计哲学

多智能体龙虾系统的分工执行，本质上是一个带上下文传递的顺序流水线（Sequential Pipeline with Context Passing）。 不同于传统的并行多Agent模式（各Agent独立回答后投票/汇总），龙虾系统选择了顺序模式，原因有三： 1. **真实团队的协作是串行的**：在现实软件公司中，总经理先分析，项目经理再规划，工程师再执行——信息天然有序流动。 2. **上下文累积增益**：后序Agent能看到前序Agent的完整输出，站在“巨人的肩膀上”深入，而非从零开始。 3. **避免角色冲突**：并行模式下多个Agent可能给出矛盾建议，顺序模式通过信息流方向天然消解冲突。

3.2 五阶段流水线详解

以 `handle_multi_agent_chat()` 方法为核心，整个协作分为5个阶段： ``` 用户需求 │ ▼ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ Stage 1 │──▶│ Stage 2 │──▶│ Stage 3 │──▶│ Stage 4 │──▶│ Stage 5 │ │ 总经理 │ │ 项目经理 │ │ 前端工程师 │ │ 算法工程师 │ │ 项目经理 │ │ 需求分析 │ │ 任务分配 │ │ 前端方案 │ │ 算法方案 │ │ 总结交付 │ └──────────┘ └──────────┘ └──────────┘ └──────────┘ └──────────┘ 300字 400字 500字 500字 500字 ```

Stage 1：总经理——需求分析与战略定位

``` general_manager_prompt = f""" 你扮演微学AI软件公司的【总经理】角色。请根据用户提出的需求，从战略和全局角度进行分析。 用户需求：{message} 请给出专业的需求分析，描述一下需求的意义和价值，背景。 请用专业但易懂的语言进行阐述。输出一段话即可，只要输出300字左右。 """ ``` 设计要点： * 总经理只接收用户原始需求，不携带其他Agent的输出——确保“第一视角”的纯粹性。 * 字数限制300字——强制聚焦，避免战略分析沦为长篇大论。 * 提示词强调“意义和价值”——总经理的角色定位是“Why”而非“How”。 输出示例（假设用户需求为“开发一个AI面试助手”）：

Stage 2：项目经理——任务拆解与分工规划

``` pm_prompt = f""" 你扮演微学AI软件公司的【项目经理】角色。基于总经理的需求分析，请进行项目规划和任务分配。 用户原始需求：{message} 总经理分析：{response_text} # ← 携带Stage 1的输出 请给出： ## 1. 项目里程碑规划 ## 2. 具体的任务分解 ## 3. 各角色的职责分工 ## 4. 时间线和优先级建议 """ ``` 设计要点： * 项目经理接收用户原始需求 + 总经理分析——双输入保证任务拆解既有业务依据又有战略方向。 * 结构化输出模板（4个二级标题）——引导模型按项目管理框架思考，减少发散。 * 字数限制400字——比总经理多100字，因为任务拆解需要更多细节。 上下文传递的关键：注意 `{response_text}` 变量在Stage 2中被复用，此时它保存的是总经理的输出。这种“变量接力”是整个流水线的核心机制。

Stage 3：前端工程师——前端技术方案

``` frontend_prompt = f""" 你扮演微学AI软件公司的【前端工程师】角色。请从前端开发角度分析需求并给出技术方案。 用户需求：{message} 项目计划：{response_text} # ← 此时携带的是Stage 2项目经理的输出 请给出： ## 1. 前端技术架构建议 ## 2. 关键技术选型 ## 3. 界面设计方案要点 ## 4. 用户体验优化建议 请给出专业的前端开发方案。只要输出500字左右。最后回答已经开始干活了。 """ ``` 设计要点： * 前端工程师接收的是项目经理的任务分配，而非总经理的战略分析——信息流的粒度在逐级细化。 * 末尾“已经开始干活了”——模拟真实工程师的行事风格，增强沉浸感。 * 字数增至500字——技术方案需要具体的架构描述和选型理由。

Stage 4：算法工程师——算法实现方案

``` algo_prompt = f""" 你扮演微学AI软件公司的【算法工程师】角色。请从算法和技术实现角度分析需求并给出解决方案。 用户需求：{message} 前端方案：{response_text} # ← 此时携带的是Stage 3前端工程师的输出 请给出： ## 1. 核心算法设计 ## 2. 技术实现方案 ## 3. 数据处理流程 ## 4. 性能优化策略 """ ``` 设计要点： * 算法工程师看到的是前端方案——这意味着算法设计可以与前端接口对齐，避免“前后端不匹配”的经典问题。 * 输出框架更偏向“实现层”——核心算法、数据处理、性能优化，这些都是可落地的技术细节。 * 与Stage 3形成前后端协作的自然闭环。

Stage 5：项目经理——总结交付

``` summary_prompt = f""" 你扮演微学AI软件公司的【项目经理】角色。请根据前面各角色的分析，生成项目总结和交付文档。 用户原始需求：{message} 总经理分析：{general_manager_response} 项目经理任务分配：{pm_response} 前端工程师方案：{frontend_response} 算法工程师方案：{algo_response} 请综合所有分析内容，输出一份完整的项目总结和交付文档，包含： ## 1. 项目概述与背景 ## 2. 需求分析总结 ## 3. 技术方案概述 ## 4. 交付清单和时间节点 ## 5. 项目工程文件包 """ ``` 设计要点： * 全量上下文汇聚：Stage 5是唯一一个能看到所有前序Agent输出的阶段——项目经理在此刻扮演“信息枢纽”。 * 变量命名从 `response_text` 变为具名变量（`general_manager_response`, `pm_response` 等）——因为需要精确引用每个角色的输出。 * 输出交付文档而非讨论——标志着从“分析”到“交付”的转换。

3.3 上下文传递的数据流图

``` message (用户原始需求) │ ├──▶ Stage 1: 总经理 ← {message} │ │ │ ▼ general_manager_response ├──▶ Stage 2: 项目经理 ← {message} + {general_manager_response} │ │ │ ▼ pm_response ├──▶ Stage 3: 前端工程师 ← {message} + {pm_response} │ │ │ ▼ frontend_response ├──▶ Stage 4: 算法工程师 ← {message} + {frontend_response} │ │ │ ▼ algo_response └──▶ Stage 5: 项目经理 ← {message} + {general_manager_response} + {pm_response} + {frontend_response} + {algo_response} │ ▼ summary_text (最终交付) ``` 注意一个精妙的细节：Stage 2-4中，每个Agent只看到前一个Agent的输出（通过 `response_text` 变量接力），而非全部前序输出。这是有意为之的信息过滤——避免上下文过长导致模型注意力分散，同时保证信息流的线性递进。 而Stage 5则打破了这个规则，全量汇聚所有输出——因为项目经理的总结角色需要“上帝视角”。

---

四、WebSocket实时协作协议：龙虾们的“对讲机”

4.1 自定义消息类型体系

龙虾系统定义了一套轻量但完备的WebSocket消息协议，专门服务于多Agent协作场景： | 消息类型 | 方向 | 语义 | 关键字段 | | :--- | :--- | :--- | :--- | | `agent_start` | Server→Client | 某Agent开始响应 | agent_index, agent_name, agent_a vatar, agent_description | | `agent_chunk` | Server→Client | Agent的流式输出片段 | agent_index, content, done | | `agent_done` | Server→Client | 某Agent完成响应 | agent_index | | `multi_agent_complete` | Server→Client | 全部Agent协作完成 | (空) | | `status` | Server→Client | 系统状态通知 | status, message, skill | | `chunk` | Server→Client | 普通聊天流式片段 | content, done | | `error` | Server→Client | 错误信息 | error, details | 这套协议的设计哲学是：用最小的消息类型集合，覆盖多Agent协作的完整生命周期。

4.2 消息流转时序图

4.3 agent_index的角色映射

`agent_index` 是前端区分“当前谁在说话”的关键标识： | agent_index | 角色名称 | 阶段 | 头像 | | :---: | :--- | :--- | :--- | | 0 | 总经理 | 需求分析 | 总经理-龙虾.png | | 1 | 项目经理 | 任务分配 | 项目经理-龙虾.png | | 2 | 前端工程师 | 前端方案 | 前端工程师-龙虾.png | | 3 | 算法工程师 | 算法方案 | 算法工程师-龙虾.png | | 4 | 项目经理 | 总结交付 | 项目经理-龙虾.png | 前端通过 `agent_index` 精确控制每条消息的归属渲染——同一个项目经理在Stage 2和Stage 5使用相同的头像和名称，但 `agent_index` 不同，UI可以分别展示。

4.4 流式输出的工程实现

每个Agent的输出都通过 `qwen_service.chat_stream()` 实现逐token推送： ``` async for chunk in qwen_service.chat_stream([{"role": "user", "content": prompt}], model=model): response_text += chunk await self.send_agent_chunk(agent_index, chunk, done=False) await self.send_agent_chunk(agent_index, "", done=True) ``` 关键设计： * **增量推送**：每收到一个token就立即推送给前端，而非等全部生成完毕——用户可以实时看到每个龙虾“边想边说”。 * **空chunk + done=True**：作为流结束标志，与内容chunk区分开。 * **变量累积**：`response_text += chunk` 在内存中持续拼接完整回复，供后续阶段作为上下文使用。

---

五、分工执行的三大应用场景

5.1 场景一：全链路软件项目开发（核心场景）

触发方式：选择“多数字员工规划”技能。 这是龙虾系统最核心的分工执行场景。用户输入一句话需求，5个阶段自动流转： ``` 用户: "帮我开发一个基于GraphRAG的智能问答系统" 龙虾团队协作过程: