企业官网建设流程全解析

结论

任务拆解的「逻辑思考、内容拆分」由大模型 (LLM)完成；

任务的「顺序调度、流程流转、状态管理」由智能体编排框架负责。

模型负责动脑拆分，框架负责落地执行，二者协同工作。

一、角色分工详解

1. 大模型 LLM：唯一负责「任务拆解」本身

模型具备语义理解、逻辑推理、行业知识，是拆分动作的主体。

• 输入整体目标，推理出多级子任务、执行先后关系、分支判断；
• 输出结构化任务清单、任务描述、执行要求；
• 运行中也可根据中间结果，动态重新拆解、调整任务。

2.编排框架：不做思考，只做「流程调度」

框架是流程引擎，无推理能力，只负责承接模型给出的任务列表：

• 把每个子任务映射为流程节点；
• 控制串行 / 并行 / 分支 / 循环 / 重试 / 暂停；
• 调度 Agent、Tools、Skills 执行节点，传递上下文与结果；
• 记录任务进度、保存状态，保证流程跑通。

二、分场景举例（结合主流框架）

场景 1：基础线性流程（LangChain 链式编排）

需求：写一份产品周报

1. 用户输入总目标

帮我完成本周产品周报

1. 大模型执行任务拆解（核心步骤）模型推理后，输出结构化子任务：

2. 收集本周产品功能迭代数据

3. 整理用户反馈与问题

4. 搭建周报框架与大纲

5. 撰写正文内容

6. 校对文字、修正错误

7. LangChain 框架执行调度框架拿到任务列表，按照固定线性顺序依次执行：收集数据 → 整理反馈 → 搭大纲 → 写内容 → 校对上一个节点执行完毕，自动把结果传给下一个节点；全程按预设链路走完，不做动态变更。

关键点：拆任务靠模型，按顺序跑流程中的每个子任务靠框架。

场景 2：复杂动态流程（LangGraph 图编排）

需求：完成一份市场调研报告（含分支判断）

1. 用户总目标

完成新能源行业市场调研报告

1. 大模型初次拆解模型输出基础任务流：
2. 搜集行业公开数据
3. 数据完整性校验
4. 撰写报告主体
5. 合规审核发布

同时给出分支规则：如果数据缺失，退回重新搜集。

1. LangGraph 框架搭建流程并调度框架将任务转为图节点 + 流转边，配置分支逻辑：

• 节点 1：搜集数据 → 执行完成后进入节点 2（数据校验）
• 框架接收校验结果：
  • 结果 = 数据完整 → 流转至节点 3（撰写报告）
  • 结果 = 数据缺失 → 流转回节点 1（重新搜集）
• 全部节点走完，流程结束。

1. 动态二次拆解（进阶）若审核环节发现内容深度不足，框架暂停流程，再次调用大模型。模型二次拆解：新增「补充竞品分析」子任务；框架更新流程图，插入新节点继续执行。

关键点：分支判断、新增子任务，依旧是模型推理；节点跳转、循环、状态保存，由框架实现。

场景 3：多角色团队任务（CrewAI）

需求：团队协作完成项目方案

1. 用户总目标

输出一套完整的小程序开发方案

1. 大模型拆解+ 角色分配模型结合角色定位，拆分任务并匹配执行人：

• 产品角色：梳理需求、绘制功能框图
• 架构角色：设计技术架构、选型组件
• 文档角色：整合内容、输出正式方案文档

1. CrewAI 框架调度团队框架按照「团队 - 角色 - 任务」的规则，串行 / 并行分配工作：先执行产品任务 → 再执行架构任务 → 最后汇总生成文档；框架管控任务依赖、结果汇总、团队协作顺序。

关键点：任务拆分、角色匹配由模型完成；团队分工、任务流转由框架完成。

场景 4：极端对比：只靠模型 / 只靠框架

情况 A：仅用大模型，无编排框架

模型可以把「写报告」拆成：调研→大纲→写作→审核，但仅此而已（纸面计划，无法执行）。模型无法自动按顺序执行每一步、无法调用工具、无法保存进度，拆分结果只是一段文字，不能形成自动化流程。

情况 B：仅用编排框架，无大模型

框架是纯引擎，看不懂“写报告” 这个自然语言目标，完全无法自主拆分任务。只能执行开发者提前硬编码写死的固定步骤，不能应对未知、动态的需求。

三、一句话总结

1. 拆什么、先做什么、后做什么、缺了该补什么→ 大模型（思考与推理）
2. 怎么一步步执行、节点怎么跳转、出错怎么重试→ 编排框架（调度与管控）
3. 工程化智能体 = 模型做脑力拆解 + 框架做流程落地。