1. 背景与问题定义
1.1 企业智能化的核心挑战
在企业环境中，信息系统通常具有以下特征：
- 生命周期长、稳定性要求高
- 与业务深度绑定，难以重构
- 系统间标准不统一
- 供应商生态封闭或更新缓慢
- 权限体系与审计要求严格
这意味着传统的 AI 集成思路难以直接落地。例如：
- 在 ERP 内增加预测模块需改动主系统逻辑
- 在 CRM 内增加智能洞察需获得供应商配合
- 在 DMS 内启用文档自动分析需突破权限边界
更重要的是，企业往往需要同时面对多个系统，各个系统的 AI 改造难度不一致、成本成倍增加。
因此，我们相信：AI 不应直接嵌入系统，而应覆盖在系统之上。
1.2 从“系统升级”为中心转向“智能层”为中心
与其对每个系统进行彼此独立的 AI 增强，不如构建一个统一、抽象、可控制的智能层，使其成为企业级基础设施。
此智能层需要满足：
- 不依赖底层系统
- 能共享企业数据语义
- 能跨系统提供智能任务
- 不破坏任何系统原有逻辑
- 与模型供应商、系统供应商解耦
Sidecar 架构正是在这一背景下形成的解决路径。
2. 架构目标与整体方法
Sidecar 架构的目标在于：
- 保持系统独立性：不侵入任何现有应用
- 提供统一智能层：封装上下文解析、智能推理、工具调用能力
- 跨系统兼容：适配企业内部各类业务平台
- 可审计可治理：满足审计、权限与可控性
- 支持渐进式演进：从局部流程到全系统覆盖
概括而言，方法由三部分构成：
- Sidecar：在用户侧收集上下文并提供交互
- Core Service：集中承载智能能力
- Adapter & Data Service：负责系统间的对接与数据标准化
其逻辑关系可表示为：
现有系统负责“提供基础数据/界面”；Sidecar 负责“使用”；Core Service 负责“承载”；Adapter 层负责“连接”。
3. 参考架构：由四层组成的企业智能层
3.1 Sidecar 交互层
Sidecar 独立于业务系统运行，通过解析当前页面内容生成上下文，以非侵入方式提供智能建议、自动化操作、摘要、比对等能力。
特点：
- 不修改系统前端或后端
- 直接在用户界面侧捕获业务语境
- 统一将上下文发送到核心智能层
- 可跨 ERP、CRM、MES 等多系统使用
3.2 核心智能服务层（Core Service）
Core Service 包含多个组件 ：
- API Gateway：用于认证、鉴权、审计
- Context Normalizer：将页面内容“转换”为统一的领域语义
- Intelligent Engine
- Agent
- Prompt
- Tools
- Orchestrator（编排器）
智能引擎负责：
- 从意图推断需要的工具
- 进行模型推理
- 合成可执行的业务建议与自动化操作
值得强调的是：智能引擎不直接访问业务系统，仅通过工具层进行访问或写入。
3.3 统一数据与工具层（Tools & Data Service）
Data Service 提供领域统一模型（如订单、文档、客户、偏差事件、设备记录等） ，避免上层智能逻辑直接面对系统差异。
工具层则提供如下抽象能力：
- 数据查询工具
- 文档解析工具
- 向量检索工具
- 内部 API 调用工具
- 工作流执行工具
智能层无需关心底层数据形态，而只需调用工具。
3.4 系统适配层（Adapter Layer）
每个系统有独立适配器，实现：
- 字段映射
- 格式转换
- 权限检查
- 数据过滤与补全
因此，系统可被逐步纳入智能层，无须一次性建设。
4. 典型应用场景
Sidecar 方案超越特定行业，可泛化到多个企业级系统。
4.1 ERP（采购、库存、供应链）
- 自动识别页面字段生成趋势分析
- 对单据自动生成核对与校验建议
- 基于上下文执行常规比较或预测任务
4.2 CRM（客户管理、商机推进）
- 自动补全文档或会议纪要
- 生成客户特征摘要、风险预测
- 快速检索与当前客户相关的内部案例
4.3 DMS（文档管理）
- 文档摘要、差异比对
- 智能搜索与语义检索
- 模板辅助生成
4.4 MES / QMS / 合规系统
- 针对当前记录自动生成分析
- 自动提取关键字段
- 生成标准化报告、解释、相关记录链接
这些场景的共同特点在于：
- 可以理解页面上下文
- 不依赖原系统改造
- 业务价值明确
- 成本可控，迭代快速
5. 可演进性的保障
该架构具备显著的可演进性，原因包括：
5.1 架构解耦
Sidecar 架构通过交互层、智能层、工具层与适配层的功能边界实现明确解耦。各层之间仅依赖稳定接口，内部实现可独立演进。例如，UI 改动不会影响智能引擎；新增智能能力不会影响系统适配层；模型替换也不会触动权限机制。这种分层结构降低了升级复杂度，使企业能在不扰动现有系统的前提下持续迭代智能能力。
5.2 领域中心的抽象
智能层引入统一的领域数据模型，避免智能逻辑与各业务系统的字段差异直接耦合。通过 Data Service 接管语义对齐工作，来自 ERP、CRM、QMS、MES、DMS 等异构系统的数据在进入智能引擎前均完成标准化。
这种抽象机制不仅提升 Agent 的稳定性，也使智能行为可跨系统迁移，为企业构建“面向业务语义”的长期知识基础。
5.3 工具化机制
工具化机制确保智能层的访问能力在安全与可控范围内运作。所有跨系统操作均以“工具（Tool）”的形式封装，工具内部负责权限校验、数据过滤与审计记录，从源头避免越权访问。同时，工具层采用插件化接口设计，企业可通过新增工具模块扩展 Agent 能力，而无需修改核心架构或现有流程。
这种可插拔的扩展方式降低了智能能力增长的边际成本，是实现长期演进的重要基础。
5.4 渐进式落地策略
Sidecar 架构支持从局部场景逐步扩展至全域智能化。企业可从单一流程或特定系统启动试点，通过实际业务反馈完善上下文抽取、工具能力与适配器设计；在价值被验证后，可将智能层扩展至更多页面、更多系统与更多部门。
这一“试点—扩展—沉淀”的路径避免了大规模系统变更带来的风险，使智能化推进节奏与业务稳定性相兼容。
6. 安全性与合规性
Sidecar 架构采用“权限前置、审计优先”的安全设计：
- 所有请求必须通过 API Gateway
- 权限检查在工具层完成，严格遵循系统授权范围
- 核心服务层保持无状态，不存储敏感业务数据
- 所有操作可追踪、可审计，满足合规性要求
7. 实施建议
企业在落地此架构时，可遵循以下路线：
- 识别高价值场景：优先选择可被页面语境驱动的工作。
- 建设统一领域模型：确保企业内部语义的一致性。
- 工具优先：逐步将企业关键动作标准化为可调用的“工具”。
- 试点—复用—扩展：先在单场景试点，再按部门或系统扩展。
- 形成智能层资产：长期沉淀模型、工具与上下文能力。
8. 结论
本文提出的基于 Sidecar 的智能层架构，是一种可适配 ERP、CRM、MES、QMS、DMS 等异构系统的普适性 AI 集成方法。在系统不可轻易改造的前提下，该方案为企业提供了一条稳定、安全、可演进、跨系统的智能化路径。
随着企业智能化需求的不断增长，此架构有潜力成为未来企业数字基础设施的重要组成部分。