实施路线图
角色：当前方案的阶段化落地计划
说明：本文回答“先做什么、后做什么、每个阶段做到什么才算过关”。本轮路线图只围绕现有正式组件清单展开，不通过路线图引入新的组件。
总体原则
企业级智能体平台的推进顺序应该是：
- 先证明业务价值。
- 再把试点沉淀成可复用的平台能力。
- 最后把治理、观测、评测和发布机制做成常规能力。
这条路线避免两个常见错误：
- 一开始就按“大平台”投入，导致建设周期过长、业务迟迟见不到价值。
- 只做一个演示型试点，后续每个场景都重建一套底座。
阶段总览
| 阶段 | 时间参考 | 主要目标 | 核心交付物 | 退出条件 |
|---|---|---|---|---|
| 第一阶段 | 0 到 30 天 | 用单一高价值场景验证价值 | 试点应用、最小知识链路、最小治理链路、基础指标 | 能被真实用户试用，且有明确验收数据 |
| 第二阶段 | 30 到 90 天 | 把试点升级为可控的生产能力 | 统一入口、权限、观测、灰度发布、第二个场景复用 | 第二个场景可以复用同一底座，运行风险可控 |
| 第三阶段 | 90 到 180 天 | 形成平台化能力和组织协作机制 | 标准组件边界、发布流程、评测体系、运维基线 | 平台能承接多业务线，且不依赖单点工程师经验 |
| 持续阶段 | 180 天以后 | 建立长期治理和成本优化闭环 | 评测运营、容量规划、成本路由、审计复盘 | 治理和优化进入常规运营，而不是专项项目 |
阶段与组件启用关系
| 阶段 | 必须启用的核心组件 | 说明 |
|---|---|---|
| 第一阶段 | APISIX、一条主平台路线、LlamaIndex、LiteLLM、vLLM、Qwen、PostgreSQL、Redis、MinIO、Weaviate、LangFuse | 先完成最小可试用闭环 |
| 第二阶段 | 在第一阶段基础上补齐 Casbin、OpenTelemetry、Prometheus、Grafana、Loki、k6，并引入 LangGraph | 进入生产治理和复杂流程能力 |
| 第三阶段 | 按需补齐 OpenMetadata、SeaTunnel、dbt Core、Apache Tika 的全链路治理，以及条件启用 Milvus / Elasticsearch | 进入平台化和规模化阶段 |
第一阶段：0 到 30 天
目标
用最小范围完成一个真实场景闭环，优先证明价值，而不是一次性建设全部平台能力。
建议任务
- 选定一个高价值、低耦合、可量化的场景，优先考虑 内部知识助手。
- 选择一条主平台路线：
Dify、RAGFlow或Coze Studio三选一。 - 打通
APISIX -> 门户 / BFF -> 主平台路线 -> LiteLLM -> vLLM的最小链路。 - 建立
PostgreSQL、Redis、MinIO、Weaviate的最小可用底座。 - 用
LlamaIndex建立可控的知识接入、检索和引用链路。 - 引入最小审计和最小
LangFuse观测能力。
阶段交付物
- 一个可供真实用户试用的试点应用
- 一组可演示的知识问答或流程辅助用例
- 一版初始评测集和验收指标
- 一份试点边界清单，明确“这阶段不做什么”
阶段门槛
- 至少有一组可复现的业务指标，例如命中率、节省时间、工单分流率。
- 至少有一条完整的权限和审计链路。
- 至少有一个失败场景能被复盘，而不是只能凭感觉调整。
本阶段不做
- 不同时并行两条主平台路线。
- 不为了未来可能的需求一次性上齐全部扩展底座。
- 不把试点临时脚本直接当成长期生产架构。
第二阶段：30 到 90 天
目标
把单场景试点升级为可控的生产能力，并验证平台复用是否成立。
建议任务
- 补齐统一入口、身份透传和细粒度授权链路。
- 建立
staging环境、灰度发布和回滚流程。 - 补齐
OpenTelemetry + Prometheus + Grafana + Loki + LangFuse的双层观测。 - 引入第二个场景，并复用现有底座，而不是复制一套新系统。
- 把高风险工具动作纳入人工确认和审计流程。
- 用
k6建立关键链路容量基线。
阶段交付物
- 第二个可运行场景
- 统一入口与统一发布流程
- 首版观测面板和异常处理预案
- 高风险动作的审批与回滚机制
阶段门槛
- 第二个场景接入时无需新建一套底座。
- 关键链路有容量数据，而不只是功能演示。
- 线上问题能通过日志、追踪和审计快速定位。
本阶段不做
- 不随意增加新的正式组件。
- 不把每个业务部门的特殊需求都做成独立技术栈。
- 不把治理和评测留到“上线之后再补”。
第三阶段：90 到 180 天
目标
形成标准化的平台层、运维层和治理层，降低跨场景复制成本。
建议任务
- 明确主平台路线、
LangGraph、LlamaIndex、LiteLLM、Casbin的长期职责边界。 - 将知识接入、索引发布、Prompt、工具和模型路由都纳入统一发布管理。
- 建立跨部门的评测集、审计抽样和例行复盘机制。
- 把入口层、检索层、模型层和治理层按负载分别扩容。
- 根据数据规模判断是否需要从
Weaviate演进到Milvus。
阶段交付物
- 平台级组件边界文档和运行基线
- 统一发布和回滚手册
- 评测与审计例行机制
- 多环境、多场景运行的容量数据
阶段门槛
- 平台可支撑多业务线接入。
- 关键组件有明确所有者和运行边界。
- 变更可以受控发布，异常可以快速回滚。
持续阶段：180 天以后
长期演进方向
- 扩充领域评测集和失败样本库
- 细化模型路由、成本治理和容量规划
- 沉淀多 Agent 模板和场景复用资产
- 建立季度级审计、回顾和架构收敛机制
长期保持的纪律
- 评测、观测、审计、压测必须持续运行，不能只在上线前出现一次。
- 组件清单保持收敛，只有在现有边界明显不足时才评估是否调整。
- 平台治理和业务价值指标一起看，不能只追求技术指标。
三条持续主线
1. 治理主线
- 权限模型持续收敛
- 高风险动作持续纳入人工接管
- 发布前评测与审计抽样常态化
2. 数据主线
- 数据分类分级和责任人机制持续补全
- 知识索引质量、引用可追溯和增量更新持续优化
- 失效数据、冲突数据和重复数据持续清理
3. 运行主线
- 关键链路 SLO、容量基线和成本基线持续更新
- 事故复盘和回滚预案常态化演练
- 组件边界持续收敛，避免平台复杂度无序增长