典型场景
角色：场景选择与优先级判断页
说明：本文不是案例堆叠页，而是帮助团队判断“什么场景适合先做、需要什么能力、上线前要管住什么”。本页只使用当前正式组件清单，不引入新的组件。
场景选择原则
优先落地的场景通常同时满足四个条件：
- 业务价值清晰，能被真实指标衡量。
- 数据范围相对清楚，权限边界容易定义。
- 能在 4 到 12 周内形成可试用版本。
- 失败成本可控，允许人工兜底和逐步放量。
场景优先级矩阵
| 场景 | 业务价值 | 集成复杂度 | 治理敏感度 | 适合作为首批场景 |
|---|---|---|---|---|
| 内部知识助手 | 高 | 低到中 | 中 | 是 |
| 服务台智能分诊 | 高 | 中 | 中到高 | 是 |
| 流程自动化 Agent | 中到高 | 高 | 高 | 第二批更合适 |
| 数据分析助手 | 高 | 高 | 高 | 需要更严格治理后再做 |
场景与组件组合速览
| 场景 | 主控组件 | 知识 / 数据组件 | 模型与治理组件 |
|---|---|---|---|
| 内部知识助手 | Dify / RAGFlow / Coze Studio | LlamaIndex + Weaviate | LiteLLM、LangFuse、Casbin |
| 服务台智能分诊 | 主平台路线 + LangGraph | LlamaIndex + Weaviate | LiteLLM、Casbin、OpenTelemetry |
| 流程自动化 Agent | LangGraph | OpenMetadata、dbt Core、LlamaIndex | LiteLLM、Casbin、LangFuse |
| 数据分析助手 | LangGraph | OpenMetadata、dbt Core、PostgreSQL | LiteLLM、Casbin、LangFuse |
场景一：内部知识助手
业务目标
让员工通过自然语言快速查询制度、流程、产品说明、售后知识和项目资料，减少人工查找和重复问答。
推荐链路
门户 / 企业 IM -> APISIX -> 主平台路线 -> LlamaIndex -> Weaviate -> LiteLLM -> vLLM
如需更复杂的问答状态控制，可在编排层补充 LangGraph。
关键能力
- 文档同步与增量索引
- 基于部门、角色和项目的权限过滤
- 引用来源展示与回答依据留痕
- 失败问题回流成评测样本
治理重点
- 知识入库前完成分类分级和责任人标注
- 检索阶段做权限过滤，而不是只在登录时判断
- 输出保留引用和版本来源
- 对敏感制度、合同、客户资料保留更严格的可见范围
验收指标
- 常见问题命中率
- 有效引用率
- 平均检索与回答时延
- 员工查询耗时下降比例
上线边界
适合作为第一阶段试点，但不建议一开始就覆盖全公司全部知识域。更合理的方式是先选单一部门、单一主题或单一业务域。
场景二：服务台智能分诊
业务目标
对 IT、HR、财务或客户服务工单进行自动分类、初步答复和分派，减少一线重复劳动。
推荐链路
渠道入口 -> APISIX -> 门户 / 工单集成层 -> 主平台路线或 LangGraph -> 工单工具 -> LiteLLM
知识回答部分仍通过 LlamaIndex + Weaviate 提供支持。
关键能力
- 意图识别与表单补全
- 工单系统双向集成
- 规则和模型联合判断
- 高风险动作的人机确认
治理重点
- 自动分派规则必须可审计、可回放
- 误分派、误关闭、误通知要能回滚
- 写动作和外发动作必须走工具级授权
- 需要监控升级转人工率和误判率
验收指标
- 自动分派准确率
- 首次响应时长
- 转人工率
- 工单处理总时长下降比例
上线边界
这类场景已经从“回答问题”进入“触发动作”，因此上线前必须补齐审计、授权和人工确认链路，不能只凭模型效果过关。
场景三：流程自动化 Agent
业务目标
将跨系统流程拆成可观测、可中断、可恢复的任务链，例如知识发布、销售线索处理、审批前校验或交付检查。
推荐链路
业务入口 -> APISIX -> 门户 / BFF -> LangGraph -> 工具 / 外部系统 -> Casbin -> 审计与观测
标准知识平面仍可复用主平台路线，但流程主控建议由 LangGraph 承担。
关键能力
- 状态机驱动任务编排
- 节点级日志与任务回放
- 超时、重试和补偿逻辑
- 人工审批插槽
治理重点
- 明确每个节点的输入、输出和责任人
- 对外部系统写入保留审批和回滚机制
- 对超时、重复执行和部分失败建立补偿策略
- 对跨系统流程建立全链路 Trace
验收指标
- 流程成功率
- 平均处理时长
- 人工介入比例
- 失败后恢复时间
上线边界
不建议把它作为第一个场景。更稳妥的顺序是先用知识助手和服务台场景沉淀入口、知识和治理能力，再进入自动化流程。
场景四：数据分析助手
业务目标
让业务人员以自然语言查询数据、解释指标变化、辅助生成分析结论和图表摘要。
推荐链路
业务门户 -> APISIX -> LangGraph -> OpenMetadata / dbt Core / PostgreSQL -> LiteLLM -> 结果解释
知识解释仍可结合 LlamaIndex，但核心风险在查询权限、口径一致性和结果正确性。
关键能力
- 指标口径和元数据管理
- 基于
dbt Core和治理后数据层的受控查询 - 结果解释和引用依据展示
- 数据权限隔离与沙箱控制
治理重点
- 不允许模型绕过权限直接查询原始数据
- 对高风险查询、全表扫描和外发数据做限制
- 建立人工验真和异常复核流程
- 把“看起来合理但实际错误”的问题纳入评测集
验收指标
- 指标解释准确率
- 查询成功率
- 错误结论发现率
- 业务分析耗时下降比例
上线边界
这一类场景风险不在“不会答”，而在“答得像对的”。因此它通常不应先于权限、审计和评测基线落地。
推荐落地顺序
- 内部知识助手
- 服务台智能分诊
- 流程自动化 Agent
- 数据分析助手
这个顺序背后的逻辑是：先做数据边界清楚、失败成本低的场景，再逐步进入动作型和高风险场景。
场景与能力映射
| 场景 | 主要依赖能力 | 当前关键组件 |
|---|---|---|
| 内部知识助手 | 知识接入、检索、引用、权限过滤 | LlamaIndex、Weaviate、LiteLLM、LangFuse |
| 服务台智能分诊 | 编排、工具调用、审计、人工确认 | Dify / RAGFlow / Coze Studio、LangGraph、Casbin |
| 流程自动化 Agent | 有状态执行、回放、补偿、审批 | LangGraph、APISIX、Casbin、OpenTelemetry |
| 数据分析助手 | 元数据治理、受控查询、结果解释 | LangGraph、OpenMetadata、dbt Core、PostgreSQL、LiteLLM |