❄️ 我的个人专栏： 
《智能软件工程AI4SE》
《嵌入式面试总结》
《嵌入式处理器架构解析》
《嵌入式与虚拟化》
《嵌入式软件测试》
《AI Native 原理与实践》
🌟 Simplicity is the ultimate sophistication

摘要：本文是「AI Native 原理与实践」系列的第五篇，聚焦 AI Native 应用的系统架构设计。文章提出由基础设施层、数据管道层、模型服务层、智能编排层构成的四层架构，并以可观测与治理体系纵向贯穿全局：数据管道层负责数据接入、清洗、切分向量化与增量更新，让模型「有据可依」；模型服务层通过统一接入、能力抽象、模型路由与缓存限流，让模型能力「可用可治理」；智能编排层以固定流程、动态 Agent 与混合编排三种形态，把能力组织成业务价值；可观测与治理则通过链路追踪、质量评估、成本监控与安全合规保障系统「可信任」。文章还给出一次请求的典型数据流与五条工程落地建议，帮助读者从「能跑通 Demo」走向「能支撑生产」。

一、为什么需要一张架构全景图

在系列前几篇中，我们讨论了 AI Native 的基本理念、Prompt 工程、上下文工程以及 Agent 的基本形态。当这些能力从单个脚本演进为真实业务系统时，问题会迅速从「模型能不能答对」转变为「系统能不能稳定、可控、可扩展地持续答对」。

一个典型的 AI Native 应用，往往同时面临以下挑战：

• 数据来源复杂：业务数据库、文档库、对象存储、第三方 API、实时消息流并存，格式与更新频率各不相同。
• 模型能力多样：不同任务需要不同模型，涉及推理、嵌入、重排、多模态等多种能力，还要考虑成本与延迟。
• 编排逻辑复杂：一次用户请求可能触发检索、工具调用、多轮推理、结果校验等多个步骤。
• 质量与安全要求高：需要评估、监控、限流、降级、审计与合规。

如果没有一张清晰的架构全景图，团队很容易陷入「哪里出问题补哪里」的被动局面。架构全景图的价值在于：明确分层边界、统一组件职责、规范数据流向，让系统在演进过程中保持可理解、可维护。

二、AI Native 系统架构全景

我们把 AI Native 系统抽象为四层结构，自下而上分别是：基础设施层、数据管道层、模型服务层、智能编排层，并在纵向贯穿可观测与治理体系。

flowchart TD
    U[用户 / 业务系统] --> O[智能编排层]
    O --> M[模型服务层]
    O --> D[数据管道层]
    M --> D
    D --> I[基础设施层]
    O --> G[可观测与治理]
    M --> G
    D --> G
    I --> G

下面逐层展开说明。

三、数据管道层：让模型「有据可依」

数据管道层是 AI Native 系统的地基。模型本身不掌握业务事实，所有事实性、时效性、私有性的知识都需要通过数据管道注入到推理过程中。

3.1 核心职责

• 数据接入：对接业务数据库、文档系统、对象存储、消息队列与第三方 API。
• 数据清洗：去噪、去重、格式归一化、敏感信息脱敏。
• 切分与向量化：按语义边界切分文本，生成嵌入向量并建立索引。
• 增量更新：支持文档变更的增量同步与索引重建，保证知识时效性。

3.2 典型组件

组件	作用	常见选型
采集器	从各类数据源拉取原始数据	定时任务、CDC、Webhook
清洗管道	格式转换、去噪、脱敏	自研 ETL、流处理框架
切分器	按语义与长度切分文本	递归切分、语义切分
嵌入服务	将文本转为向量	Embedding 模型
向量库	存储与检索向量	Milvus、pgvector、Elasticsearch

3.3 设计要点

数据管道的质量，直接决定检索增强生成（RAG）效果的上限。切分策略、元数据设计与更新机制，往往比更换模型更能影响最终效果。

实践中建议：为每个数据块保留来源、更新时间、权限标签等元数据，便于后续做权限过滤、时效判断与结果溯源。

四、模型服务层：统一接入与能力抽象

模型服务层负责把多样化的模型能力封装为统一、稳定、可治理的服务接口。

4.1 核心职责

• 统一接入：屏蔽不同模型厂商的 API 差异，提供一致的调用协议。
• 能力抽象：将对话、嵌入、重排、多模态等能力抽象为标准服务。
• 路由与调度：按任务类型、成本、延迟、可用性选择合适模型。
• 缓存与限流：降低重复调用成本，保护后端稳定性。

4.2 关键设计

模型路由是模型服务层的核心。一个常见策略是：简单任务走小模型，复杂推理走大模型；对延迟敏感的场景优先使用缓存或轻量模型；当主模型不可用时自动降级到备用模型。

public interface ModelRouter {
    ModelClient route(ModelRequest request);
}

public class CostAwareRouter implements ModelRouter {
    private final ModelClient smallModel;
    private final ModelClient largeModel;

    public CostAwareRouter(ModelClient smallModel, ModelClient largeModel) {
        this.smallModel = smallModel;
        this.largeModel = largeModel;
    }

    @Override
    public ModelClient route(ModelRequest request) {
        if (request.getComplexity() <= Complexity.LOW) {
            return smallModel;
        }
        return largeModel;
    }
}

此外，模型服务层还应统一处理超时、重试、熔断、Token 计量与成本核算，让上层编排逻辑不必关心底层细节。

五、智能编排层：把能力组织成业务价值

智能编排层是 AI Native 系统的「大脑」，负责把数据管道与模型服务的能力组织成可执行的业务流程。

5.1 编排的三种形态

• 固定流程编排：步骤预先定义，适合稳定、可预测的业务场景，如文档问答。
• 动态 Agent 编排：由模型自主决定调用哪些工具、执行哪些步骤，适合开放式任务。
• 混合编排：关键步骤固定，局部环节交给模型决策，兼顾可控性与灵活性。

5.2 核心组件

组件	职责
意图理解	识别用户意图，决定任务类型与路由
上下文管理	组装对话历史、检索结果与工具输出
工具调用	封装外部 API、数据库查询、代码执行等能力
结果校验	对模型输出做格式校验、事实校验与安全过滤
状态管理	维护多轮会话与任务执行状态

5.3 一次请求的典型数据流

1. 接收用户请求，完成意图识别与任务分类。
2. 根据任务类型，从数据管道层检索相关上下文。
3. 组装 Prompt，调用模型服务层完成推理。
4. 如需工具调用，执行工具并将结果回填上下文。
5. 对最终结果做校验、格式化与安全过滤。
6. 返回结果，并记录全链路日志用于评估与优化。

六、可观测与治理：让系统「可信任」

AI Native 系统的输出具有不确定性，因此可观测与治理体系必须贯穿所有层次。

• 链路追踪：记录每次请求的检索、模型调用、工具执行与耗时。
• 质量评估：建立离线评测集与在线反馈机制，持续跟踪准确率与满意度。
• 成本监控：按业务维度统计 Token 消耗与调用成本。
• 安全合规：输入输出过滤、权限控制、审计日志与数据脱敏。

没有可观测性的 AI 系统，就像没有仪表盘的飞机：也许能起飞，但无法安全飞行。

七、工程落地建议

1. 先分层，再优化：先把四层边界划清，再针对瓶颈逐层优化，避免过早陷入细节。
2. 数据优先：在模型选型之前，先把数据质量与检索效果打磨到位。
3. 抽象模型接口：通过统一接口隔离模型厂商，保留随时切换的能力。
4. 编排可控：优先采用混合编排，在关键路径上保留确定性逻辑。
5. 治理前置：从第一天就接入日志、评测与成本监控，而不是事后补救。

八、小结

AI Native 系统架构的本质，是把数据、模型与业务逻辑通过清晰的分层与编排组织起来。数据管道层保证「有据可依」，模型服务层保证「能力可用」，智能编排层保证「业务可落地」，可观测与治理体系保证「系统可信任」。掌握这张全景图，才能在真实业务中构建出稳定、可扩展、可持续演进的 AI Native 应用。

下一篇，我们将深入智能编排层，讨论 Agent 的工具设计与多步推理实践。