方案综述
角色：站点导读页
说明：本文帮助读者快速理解“这套方案解决什么、由哪些核心能力组成、应该从哪些页面开始读”。
这套方案解决什么
“企业级智能体开源系统方案”关注的不是单点模型接入，而是围绕企业真实生产环境，给出一套可长期运行的系统建设方法：
- 把模型、知识、工具、工作流和多 Agent 能力纳入同一条受控链路。
- 把权限、审计、评测、容量验证和发布门槛从第一版就纳入设计。
- 把试点系统沉淀成可复用的平台底座，而不是每个场景重搭一遍。
- 在开源优先的前提下，保留私有化部署、边界可控和持续演进能力。
这套方案不解决什么
为了避免误解，也要明确它不直接提供以下内容：
- 不直接等于某一个业务应用的完整交付代码。
- 不承诺所有企业都采用同一条主平台路线，只提供收敛后的选择规则。
- 不把所有外部系统集成细节都写进主方案页。
- 不把“能演示”当成“能生产”，所以治理和部署要求会比 Demo 更严格。
当前方案的一句话理解
当前推荐架构可以概括为：
APISIX + 门户 / BFF + 一条主平台路线 + LangGraph + LlamaIndex + LiteLLM + vLLM + 数据治理链路 + 双层观测治理体系
这意味着：
- 入口统一收敛
- 主平台路线收敛为一条
- 复杂流程由专门运行时承接
- 模型调用统一经过模型网关
- 知识、治理、观测和部署都不是事后补丁
适合哪些读者
| 读者角色 | 建议先读什么 | 主要关注点 |
|---|---|---|
| 管理层 / 决策者 | 方案、实施路线图 | 业务价值、投入顺序、组织协同 |
| 架构师 | 总体架构、技术选型、协议与标准体系 | 模块边界、协议口径、长期演进 |
| 安全 / 治理团队 | 安全与治理、数据治理层（企业 AI 数据底座） | 身份、权限、审计、数据控制 |
| 实施团队 | 组件、部署与发布、典型场景 | 组件职责、部署形态、落地顺序 |
推荐阅读路径
路径一：快速了解全貌
路径二：从治理视角进入
路径三：从实施视角进入
核心原则
1. 平台化优先于项目化
不要为每个业务场景单独搭一套 Agent 系统。应优先沉淀模型网关、知识检索、工具接入、权限与审计、统一观测等共性能力。
2. 编排层与模型层解耦
模型会持续变化，业务流程也会快速变化。两者必须通过统一接口解耦，避免因为更换模型或供应商而重写全部流程。
3. 治理内建而非后补
权限、脱敏、敏感动作、人工接管、发布评测和容量验证都不应放到试点成功后再补。
4. 当前方案优先收敛
公开站点只展示一个当前状态，因此组件、协议和路线都要收敛，不把内部备选同时写成公开默认方案。
适合优先落地的场景
| 场景 | 适合原因 | 主要能力要求 |
|---|---|---|
| 内部知识助手 | 价值明确、数据边界较清晰、便于试点 | 知识接入、权限过滤、引用留痕 |
| 服务台智能分诊 | 可直接体现效率收益 | 工具调用、审计、人工确认 |
| 流程自动化 Agent | 能体现平台化价值 | 状态机、回放、审批、补偿 |
| 数据分析助手 | 价值高，但治理要求更高 | 查询安全、指标口径、人工验真 |
交付边界
本方案默认交付三类成果：
- 文档站：面向管理层、架构师和实施团队的统一方案说明。
- 平台蓝图：明确开源组件选型、模块边界、治理要求和部署拓扑。
- 实施路线：从 PoC、试点到生产推广的阶段目标和验收口径。
它不直接替代：
- 具体业务系统改造项目
- 企业内部主数据治理项目
- 各业务部门自定义流程和表单建设工作