重点落在——用 LangChain / LlamaIndex 把这些能力升级成“企业级智能工作流编排”。

---

在前四篇里，已经把一个企业智能助手从 0 搭到了「能用」：

1. ​（一）​ DeepSeek + RAG：能查企业知识库、回答问题
2. ​（二）​ 接入钉钉 / 企业微信：同事在 IM 里 @ 机器人就能问
3. ​（三）​ 多轮对话 + 工具调用：会追问、会查系统、会办事
4. ​（四）​ 反馈 + 日志闭环：能根据真实使用持续优化

但你很快会发现，这样的「单个助手」面对真正的企业流程时还是不够用，比如：

• 采购审批：申请 → 审批 → 询价 → 签合同 → 入库 → 付款
• 客服处理：查订单 → 对照政策 → 生成补偿方案 → 提交审批 → 记录 CRM
• 用人流程：发起 HC → 审批 → 面试排期 → Offer 流程 → 入职任务

这些都是多步骤、多系统、多角色协同的流程，远远超出了「一轮问答 + 一次工具调用」的范畴。

这一篇，我们就做一件事：

在现有 DeepSeek + RAG + 工具调用的基础上，
引入 LangChain / LlamaIndex，搭建一个可以「拆解任务、调度多个 Agent、跨系统协作」的 企业级智能工作流编排能力。

---

一、为什么要引入“工作流编排”？

1. 单助手能做什么，不能做什么？

前几篇里的企业助手已经能：

• 理解自然语言需求
• 从知识库检索出相关内容（RAG）
• 调用工具（查订单、查 HR、建工单）
• 进行多轮对话，澄清信息

但在真实业务里，你经常遇到这种需求：

「帮我走完这一次采购，从申请到合同到付款都搞定。」

这背后包含：

1. 解析需求（金额、用途、预算归属）
2. 判断审批流（部门负责人 / VP / CEO）
3. 在采购系统创建申请单
4. 通知对应审批人，等待结果
5. 选择合适供应商、比价
6. 生成合同，走法务审核
7. 入库登记，通知财务付款
8. 完成后记录全流程日志

问题在于：
单个 Agent 只能在一次对话里「局部地」做某一步，而企业真正需要的是：

• 跨多步的任务拆解和编排
• 对话状态和业务状态的统一管理
• 可观测、可回放、可审计 的业务流程

这就是智能工作流编排要解决的核心问题。

2. LangChain / LlamaIndex 分工与组合

从大量实践和对比资料可以看到一个比较稳定的认识：

• LangChain 更偏向做「工作流与 Agent 编排」
  • 强在：Chain、Agent、Tools、LangGraph（图式工作流）、与各类 LLM/工具集成
• LlamaIndex 更偏向做「数据检索与知识工作流」
  • 强在：文档解析、索引、RAG、文档型工作流、Agentic Document Workflows[2][3]

一个很自然的组合策略是：

• 用 LlamaIndex 管理企业知识（政策文档、流程文档、手册等），继续为你的 DeepSeek RAG 提供强力支持
• 用 LangChain / LangGraph 负责：
  • 将一个复杂业务拆成多个节点（Node）
  • 在节点之间路由（条件分支 / 并行 / 循环 / 重试）
  • 在每个节点里调相应的 Agent / 工具（包括 LlamaIndex 的 Query Engine）

简单一句话：

LlamaIndex：让 Agent 懂“书”
LangChain：让多个 Agent 懂“配合干活”

---

二、一个典型目标：自动化采购审批工作流

先定义一个足够典型又不至于过于复杂的目标流程：

场景：员工想采购一台 2 万元的服务器，用于测试环境。

我们期望智能工作流做到：

1. 从自然语言中解析关键信息：
   • 金额（2 万元）
   • 用途（测试环境服务器）
   • 申请人信息（从 IM 平台用户映射）
2. 根据公司采购制度（知识库 / LlamaIndex）确定审批流：
   • <5000 元：部门负责人
   • 5000–20000 元：VP
   • >20000 元：CEO
3. 在采购系统创建采购申请单：
   • 写入 amount / purpose / applicant / department 等字段
4. 同步给对应审批人：
   • 钉钉 / 企业微信通知
   • 记录日志
5. 审批通过后：
   • 触发供应商选择 Agent：自动对比历史采购记录 + 供应商评分
   • 生成初始合同文本，发给法务系统
6. 最终生成一个统一的「采购流程记录」，便于审计与追踪。

这条链条中，既有：

• 知识层面（采购制度、审批规则） → 适合 LlamaIndex / RAG
• 流程层面（节点顺序、条件分支、重试） → 适合 LangChain / LangGraph
• 系统集成（采购系统、IM、法务系统、财务系统） → 适合以 Tool 抽象成“可调用能力”

---

三、核心技术选型与架构

1. 总体架构

可以在你前面几篇的基础上，把系统扩展为：

钉钉 / 企业微信 / Web
         ↓
   对话入口（IM 网关）
         ↓
   企业智能助手（DeepSeek + 多轮 + 工具）
         ↓
   工作流编排层（LangChain / LangGraph）
         ↓
 ┌───────────────┬───────────────┬───────────────┐
 │  LlamaIndex   │ 企业业务系统   │  外部服务等   │
 │（知识RAG）    │（采购/CRM/HR） │（搜索/邮件） │
 └───────────────┴───────────────┴───────────────┘

• 对话入口 + 基础助手仍然延续前三篇的设计
• 本篇新增一层「Workflow Orchestrator」​：
  • 接收“任务级”请求（例如「帮我完成一次采购」）
  • 用 LangChain / LangGraph 描述工作流图
  • 调用多个 Agent / 工具 / LlamaIndex 查询
• 底层的数据检索仍然用 LlamaIndex 做 RAG

2. 关键组件拆分

你可以按下面的方式组织代码（逻辑结构，具体文件名自行调整）：

enterprise-ai-workflow/
├── config/                  # 配置 & 环境
├── core/
│   ├── workflow_graph.py    # LangGraph 工作流定义
│   ├── agent_factory.py     # 根据角色创建对应 Agent
│   └── tool_registry.py     # 统一工具注册 & 封装
├── agents/
│   ├── procurement_agent.py # 采购需求解析 & 申请创建
│   ├── approval_agent.py    # 审批逻辑 & 人工确认
│   ├── supplier_agent.py    # 供应商比价与选择
│   └── document_agent.py    # 基于 LlamaIndex 的政策/流程查询
├── tools/
│   ├── procurement_api.py   # 调采购系统
│   ├── contract_api.py      # 调合同/法务系统
│   ├── notification_api.py  # IM 通知、邮件通知
│   └── hr_api.py            # HR / 权限相关
└── api/
    └── workflow_entry.py    # 提供 /start_workflow 接口给对话层调用

---

四、用 LangChain 描述一个可运行的采购工作流

下面给出的是一个「可照着改」的设计思路与伪代码层级的实现，方便你按需细化。

1. 定义工作流状态（State）

工作流不是一次对话，而是一个有生命周期的「任务」。
建议用一个状态对象来集中管理业务信息：

# core/state.py
from dataclasses import dataclass, field
from typing import List, Dict, Any

@dataclass
class ProcurementState:
    applicant: str = ""           # 申请人
    department: str = ""          # 部门
    amount: float = 0.0           # 金额
    purpose: str = ""             # 用途
    urgency: str = "normal"       # 紧急程度
    procurement_id: str = ""      # 采购单号
    approval_status: str = "pending"  # 审批状态
    approver: str = ""            # 当前审批人
    supplier: str = ""            # 选定供应商
    contract_id: str = ""         # 合同ID
    logs: List[Dict[str, Any]] = field(default_factory=list)

2. 用 LangGraph 建一个“节点图”

LangGraph 的思路是：有状态图（StateGraph） + 节点函数（Node） + 条件边（Edge）​。

# core/workflow_graph.py
from langgraph.graph import StateGraph, END
from .state import ProcurementState
from agents.procurement_agent import run_procurement_agent
from agents.approval_agent import run_approval_agent
from agents.supplier_agent import run_supplier_agent
from tools.contract_api import generate_contract

def create_procurement_workflow():
    graph = StateGraph(ProcurementState)

    # 1）解析用户需求 → 填写 amount / purpose / applicant
    graph.add_node("parse_request", run_procurement_agent)

    # 2）根据金额/制度决定审批路径
    graph.add_node("run_approval", run_approval_agent)

    # 3）审批通过后选供应商
    graph.add_node("select_supplier", run_supplier_agent)

    # 4）生成合同
    graph.add_node("generate_contract", generate_contract)

    # 边（直线流程）
    graph.add_edge("parse_request", "run_approval")
    graph.add_edge("run_approval", "select_supplier")
    graph.add_edge("select_supplier", "generate_contract")
    graph.add_edge("generate_contract", END)

    # 设置入口
    graph.set_entry_point("parse_request")

    return graph.compile()

每个节点（Node）接收并返回 ProcurementState，内部可以：

• 调 LLM（DeepSeek）解释自然语言
• 调业务系统 API
• 写入 logs 方便审计和回放

3. 采购 Agent：解析自然语言 + 创建申请

# agents/procurement_agent.py
from langchain_openai import ChatOpenAI
from langchain_core.prompts import ChatPromptTemplate
from tools.procurement_api import create_procurement_request
from core.state import ProcurementState

llm = ChatOpenAI(model="deepseek-reasoner-671b", temperature=0.1)

PROMPT = ChatPromptTemplate.from_messages([
    ("system", """你是企业采购助理，负责从用户自然语言中提取采购信息：
- 采购金额（数值）
- 用途（简要描述）
- 是否紧急（如有提到‘本周必须到位’则为紧急）

输出 JSON，字段：amount, purpose, urgency。"""),
    ("user", "{user_input}")
])

def run_procurement_agent(state: ProcurementState) -> ProcurementState:
    # 假设 state.logs[0] 里存了原始用户输入
    user_input = next((log["content"] for log in state.logs if log.get("type") == "user_input"), "")
    if not user_input:
        return state

    prompt = PROMPT.format_messages(user_input=user_input)
    resp = llm.invoke(prompt)
    import json
    info = json.loads(resp.content)

    state.amount = float(info["amount"])
    state.purpose = info["purpose"]
    state.urgency = info.get("urgency", "normal")

    # 创建采购申请（调用内部系统）
    result = create_procurement_request(
        applicant=state.applicant,
        amount=state.amount,
        purpose=state.purpose
    )
    state.procurement_id = result["procurement_id"]
    state.logs.append({"step": "create_procurement", "result": result})
    return state

4. 审批 Agent：结合制度（LlamaIndex）判定审批流

这里可以把公司采购制度文档丢给 LlamaIndex，做一个专门的「采购制度 Agent」。

# agents/approval_agent.py
from core.state import ProcurementState
from agents.document_agent import query_policy  # LlamaIndex 封装

def run_approval_agent(state: ProcurementState) -> ProcurementState:
    # 用 LlamaIndex 查询制度
    policy_text = query_policy("采购审批规则")
    # 可以简单写规则，也可以让 LLM 依据 policy_text 判断
    if state.amount < 5000:
        approver_role = "部门负责人"
    elif state.amount < 20000:
        approver_role = "VP"
    else:
        approver_role = "CEO"

    # 这里可以真正查组织架构系统，找出具体人
    approver = f"{approver_role}张总"
    state.approver = approver

    # 模拟给审批人发 IM / 邮件
    # 也可以设计为“等待审批回调”节点，这里先简化为直接通过或挂起
    if state.amount < 20000:
        state.approval_status = "approved"
    else:
        state.approval_status = "pending_ceo"

    state.logs.append({
        "step": "run_approval",
        "approver": approver,
        "status": state.approval_status,
        "policy_snippet": policy_text[:200]
    })
    return state

---

五、如何把 LlamaIndex 嵌入到工作流里

在这个架构下，LlamaIndex 不再是一个“单独的 Demo”，而是作为任意节点里可调用的“知识服务”：

1. 初始化 LlamaIndex RAG 服务

# agents/document_agent.py
from llama_index.core import VectorStoreIndex, SimpleDirectoryReader
from llama_index.embeddings.openai import OpenAIEmbedding
from llama_index.llms.openai import OpenAI

# 假设你已经准备好了 policies/ 目录，放采购/人事/财务等制度PDF或Markdown
_documents = SimpleDirectoryReader("policies/").load_data()
_embed_model = OpenAIEmbedding(model_name="text-embedding-3-small")
_index = VectorStoreIndex.from_documents(_documents, embed_model=_embed_model)
_llm = OpenAI(model="deepseek-reasoner-671b")

def query_policy(query: str) -> str:
    """针对公司制度 / 流程做语义检索"""
    query_engine = _index.as_query_engine(similarity_top_k=3, llm=_llm)
    resp = query_engine.query(query)
    return resp.response

2. 在工作流节点中调用 LlamaIndex

前面的 run_approval_agent 就是一个例子：
在审批逻辑中，实时查询「采购审批规则」，避免硬编码制度到代码里。

同理，你可以：

• 在客户投诉工作流中查询「延迟发货补偿政策」
• 在 HR 流程中查询「调薪 / 晋升制度」
• 在 IT 运维中查询「变更管理流程」

从而做到：制度更新 → 只需更新文档，不必改代码。

---

六、把“工作流入口”接回你的企业助手

当前有两条消息路径：

1. 普通问答 / FAQ / 日常聊天
   → 还是走第三篇的多轮对话 + RAG + 工具调用逻辑

2. 任务类 / 流程类请求（例如：「帮我走一次采购」、「帮我查查这单、给个补偿方案」）
   → 需要转到「工作流编排层」

1. 简单的意图路由设计

在对话层加一个轻量的“意图识别”：

# pseudo-code in assistant layer
if intent in ["采购流程", "下单采购", "采购申请"]:
    # 创建一个工作流实例
    workflow_id = start_procurement_workflow(user_input, user_id)
    reply("已为你发起采购流程，我会分步骤来帮你处理。")
elif intent in ["客户投诉", "订单延迟", "快递问题"]:
    workflow_id = start_customer_service_workflow(...)
    reply("已为你创建投诉处理流程，我先帮你查订单和相关政策。")
else:
    # 继续走普通问答路线
    answer = rag_assistant.answer(user_input)

2. 工作流的生命周期管理

• start_*_workflow() 创建一个 ProcurementState 或其他 State 的实例，写入数据库（或 Redis）
• 每个节点执行完会更新状态，并决定下一步：
  • 如果需要用户补充信息 → 在 IM 里追问；
  • 如果需要等待第三方系统回调（审批结果） → 把状态置为 waiting，由后台任务/定时器唤醒；
• 整个流程结束后，将完整状态写入审计日志表。

---

七、企业落地要点与实践建议

1. 不要一上来就「全流程智能化」

建议迭代路线：

1. 第 0 步：只把当前已经人工很重、流程比较规范的一个场景拿出来
   • 如：固定金额段的采购；标准化的客户投诉流程
2. 第 1 步：先用 LangChain / LlamaIndex 做「半自动工作流」
   • 机器负责信息收集、制度解释、草拟方案
   • 最后仍由人工点击确认/执行
3. 第 2 步：在有足够日志与正/负样本后，逐步放开更多「自动执行」节点
   • 特别是低风险、高频、金额/影响较小的流程

2. 严格区分「建议」与「操作」

• 建议类：例如「建议选 A 供应商，因为……」→ 可以直接自动给出
• 操作类：比如「创建采购单 / 发起付款 / 解锁账号」→ 强烈建议加一道人工确认，或在 IM 里提示「请确认是否执行」。

3. 强调可观测性和回放能力

• 每个节点的输入 / 输出都要记录：
  • 包括 LLM 的中间推理（可以用 LangChain 的 callback / tracing）
  • 工具调用的参数 / 返回结果
• 出现争议时，可以完整回放整条「智能流程」的执行轨迹，做到：
  • 谁发起
  • 每一步做了什么
  • 模型说了什么
  • 系统执行了什么
  • 最终结果如何

4. 和前一篇的「反馈闭环」联动

第五篇的工作流编排，不是代替第四篇，而是一个扩展使用场景。
你可以：

• 对每次流程而不是每轮对话做满意度调查（“本次采购流程体验如何？”）
• 用这些反馈分析：
  • 哪些节点经常出错 / 漏掉信息
  • 哪些制度文档经常被查但解释不清
  • 哪些建议方案被人工频繁修改

从而把「流程层面的优化」纳入整体大模型系统的持续改进。

---

八、小结：从“能问问题”到“能跑业务”

这一篇我们从一个具体、典型的企业场景——采购审批——出发，讲清楚了：

1. 为什么在已有的 DeepSeek + RAG + 工具调用之上，还需要一层 工作流编排
2. LangChain / LangGraph 和 LlamaIndex 在这个体系中的分工与组合方式
3. 如何把一个业务流程拆成若干节点，用 StateGraph 管理全局状态
4. 如何在节点里：
   • 用 LlamaIndex 做制度 / 政策 / 文档检索
   • 用 Tools 调企业内部系统（采购、合同、IM 通知等）
5. 又如何把这层“工作流大脑”接回到你前几篇搭好的企业助手和 IM 接入上