多数产品仍停留在 AI 增强（旧应用上加功能）或 AI 外挂（对话框套在 CRUD 外）。AI Native 是另一种契约：推理走在 价值交付的关键路径 上，输入、记忆、工具、失败模式、成本与反馈 作为同一系统一并设计——而不是在业务代码末尾多一次模型调用。

下文按 系统设计 组织：分层边界、编排选型、运维接缝与演进关卡。它与偏交互设计的文章（不确定性呈现、适当依赖）互补，回答 屏幕背后该建什么，才能让 AI 行为在生产中可观测、有边界、可持续改进。

1. 产品中的三档「AI 含量」

| 档位 | 形态 | 典型症状 | 设计时要问 | |------|------|----------|------------| | AI 增强 | 确定性应用 + 可选辅助 | 上线热闹，留存平平 | 辅助是否改变主流程，还是旁路？ | | AI 外挂 | 聊天壳 + 旧 API | 用户重复输入系统已有上下文 | 状态归线程还是归领域聚合？ | | AI Native | 模型在产品闭环内 | 失败模式被设计而非线上撞见 | 能否把一次用户结果追溯到检索、工具、策略与人机门禁？ |

AI Native 不要求 处处 Agent。它要求 每次模型调用 在架构中有明确位置：看见什么上下文、能改什么、如何度量与回归。

2. 先定义闭环，再选技术栈

在选厂商或向量库之前，写清产品优化的 闭环：

  1. 用户意图与载体 — 用户带入什么（选中项、文件、工单 ID）？哪些绝不能靠模型猜？
  2. 上下文组装 — 检索、记忆、计算各提供什么？新鲜度与 ACL 谁负责？
  3. 动作面 — 只读综合 vs 提议变更 vs 自主执行？
  4. 人机门禁 — 哪些状态迁移要显式批准、双人复核或角色校验？
  5. 持久化与审计 — 合规、回放、训练/评测存什么——不止聊天记录？
  6. 反馈 — 编辑、拒绝、点赞、任务成败如何回流到 Prompt、检索或路由？

若一张白板画不清这条链，多半是在做 Demo。闭环即 AI 模块的 限界上下文——类似 DDD 里聚合根的职责边界。

用户意图 → 上下文组装 → 推理/规划 → [门禁?] → 副作用 → 审计 → 反馈 → (更新检索/Prompt/路由)

3. 参考架构（逻辑分层）

把 AI Native 当作 有显式契约的分层，而非「在 Controller 里调 OpenAI」。

flowchart TB
  subgraph Experience
    UI[按延迟分级的 UI 模式]
    HITL[审核 / 批准界面]
  end
  subgraph Orchestration
    ORCH[工作流 / Agent 运行时]
    ROUTE[模型与工具路由]
  end
 subgraph Knowledge
    RAG[RAG 流水线]
    MEM[记忆分级]
  end
  subgraph Action
    TOOLS[工具注册表]
    POL[策略引擎]
  end
  subgraph Platform
    OBS[链路 / 评测 / 成本]
    GOV[脱敏 / 租户 / 限流]
  end
  UI --> ORCH
  HITL --> ORCH
  ORCH --> ROUTE
  ORCH --> RAG
  ORCH --> MEM
  ORCH --> TOOLS
  TOOLS --> POL
  ORCH --> OBS
  RAG --> GOV
  MEM --> GOV

| 层 | 职责 | 不应做 | |----|------|--------| | 体验层 | 按 SLA 分级的界面、流式、审核 UX | 嵌入检索 SQL 或工具凭证 | | 编排层 | 步骤、分支、重试、取消、幂等键 | 承载长期业务不变量 | | 知识层 | 分块、索引、检索、记忆读写策略 | 绕过 ACL 或租户隔离 | | 动作层 | 工具 Schema、执行、补偿 | 把模型输出当 URL/SQL 直接执行 | | 平台层 | 链路、评测 harness、成本归因、脱敏 | 上线后再补的「运维插件」 |

单体还是微服务是次要的，接缝 才重要：换嵌入模型、换 LLM 厂商、换向量库时，业务规则不应重写。

4. 延迟分级与体验模式

用户感知的是 意图是否被满足，不是毫秒表。按 SLA 拆分入口——勿用一个按钮有时秒回、有时卡八秒。

| 分级 | 目标感知延迟 | UX 模式 | 后端模式 | |------|--------------|---------|----------| | 行内辅助 | <500ms 或立刻开始流式 | 幽灵文本、行内修正、联想 | 小模型 / 缓存检索 / 边缘路由 | | 交互草稿 | 2–8s 渐进输出 | 流式 + 停止 + 可编辑 | 单次或短链 | | 分析任务 | 秒～分钟 | 异步任务 + 通知 + Diff | 队列、Worker、检查点 | | 后台监测 | 持续 | 摘要、告警、看板 | 定时检索 + 规则 + 模型总结 |

反模式： 在 HTTP 请求线程上跑长链 Agent。模式： 早返回 jobId，SSE/WebSocket 推送进度，支持取消与部分结果物化。

分级也分离 成本预算 与 模型路由——行内辅助不应误触最贵推理模型。

5. 编排：何时用哪种模式

| 模式 | 适用 | 风险 | 控制 | |------|------|------|------| | 单次补全 | 分类、改写、结构化抽取 | Schema 漂移 | 结构化输出 + 校验器 | | 固定链 | 稳定流水线（检索→摘要→格式化） | 对新意图脆弱 | 链版本化；步骤 Feature Flag | | 工具增强循环（ReAct 类） | 步骤可变、需外部数据 | 死循环、滥调工具 | 步数上限、白名单、预算 | | 规划 → 批准 → 执行 | 变更、扣费、发布 | 过度门禁疲劳 | 仅作用于高影响工具 | | 监督者 / 工作者 | 并行子任务再合并 | 重复劳动、合并冲突 | 共享草稿区 + 合并策略 |

生产环境变更的默认： Dry-run 预览 → 人工或策略门禁 → 带审计行的 幂等 执行。

编排状态应 持久化（DB 或工作流引擎），不能只在内存——用户会刷新，Worker 会挂，模型会超时。

6. 记忆架构

「记忆」不是一张表。按 TTL、ACL、评测预期 分级：

| 分级 | 范围 | 示例 | 失效 | |------|------|------|------| | 工作记忆 | 当前轮 / 工具草稿 | ReAct 中间步骤、临时 JSON | 提交后丢弃 | | 会话记忆 | 对话线程 | 澄清、钉住的约束 | TTL + 用户清空 | | 情节记忆 | 用户或项目历史 | 过往工单摘要 | 用户删除；保留策略 | | 语义记忆（RAG） | 组织知识库 | 文档、Runbook、代码 | 源变更触发重索引 |

宜尽早写进规范的规则：

  • 写路径： 不是每句模型输出都入库——需显式「记住」或带 Schema 的结构化抽取；
  • 读路径： 记忆查询与主库同等 租户 + 角色 ACL；
  • 冲突： 会话钉选优先于 stale RAG；来源矛盾时展示 出处；
  • 评测： 黄金集测检索 与 记忆注入，不只测最终文案。

7. RAG 是流水线，不是勾选项

生产级 RAG = ETL + 检索 + 排序 + 上下文打包 + 回归测试：

入库 → 解析/分块 → 嵌入 → 索引（+ 元数据/ACL）
查询 → 改写? → 混合检索 → 重排 → 打包上下文 → 生成 → 引用

比「选哪个向量库」更关键的决策：

| 决策 | 权衡 | |------|------| | 块大小 / 重叠 | 精度 vs 上下文窗口浪费 | | 元数据过滤 | 租户、产品、文档版本、生效日 | | 混合检索 | 向量漏精确 SKU；BM25 漏 paraphrase | | 重排模型 | 延迟 vs Top-K 精度 | | 上下文预算 | 超 Token 时丢什么——应排序而非粗暴截断 | | 引用契约 | 模型必须引用 span ID；UI 校验链接 |

反模式： 嵌入一次永不重建，答案过时怪模型。模式： 索引代际与源版本绑定；每次索引或 Prompt 变更跑评测集。

8. 工具与动作层

工具是 带责任的远程调用。按对外 API 标准设计：

  • 按工作流/租户 白名单——非「模型任意挑 OpenAPI」；
  • 入参/出参 JSON Schema；畸形调用在执行前拒绝；
  • 创建/扣费/发送带 幂等键；
  • 最小权限 凭证（ scoped token，非管理员 DB）；
  • Dry-run 返回 Diff 预览；
  • 部分失败有 补偿 或人工回滚手册。

勿把模型原文交给 eval、Shell 或 SQL。仅参数化工具。

策略引擎位于编排与执行之间：角色、金额上限、环境（生产/预发）、数据分级（PII 拦截）。

9. 边界优于提示词

冗长 System Prompt 会随版本、语言与攻击面 漂移。硬边界 落实提示词只能「建议」、无法保证之事：

| 机制 | 约束 | |------|------| | 工具白名单 | 爆炸半径 | | 输出 Schema / 语法 | 可解析性 | | 推理前脱敏 | PII/密钥不进上下文 | | 推理后过滤 | 拦截模式；无引用则降级主张 | | 租户 Token/速率上限 | 成本与滥用 | | 模型路由规则 | 草稿用小模型，贵模型只走审核路径 |

Prompt 管 语气与任务框；边界管 安全、成本与正确性契约。Prompt 像代码一样版本化；变更跑 回归评测。

10. 人机协同即架构

HITL 不是免责声明，是 状态机设计：

已提议 → [审核 | 策略自动通过] → 已提交 → (可选) 通知
       ↘ 已拒绝 → 记日志 → 可能调整检索/路由

| 风险等级 | 默认门禁 | 自治阶梯 | |----------|----------|----------| | 只读摘要 | 流式 + 出处 | 可自动 | | 代发消息草稿 | 发送前审核 | N 次接受后可放宽 | | 财务 / 法务 / 生产配置 | 双人或强确认 | 无策略引擎勿全自动 | | 批量导出 | 显式确认 + 审计 | 保持人工 |

仅当 离线指标 支持时才提高自治：任务成功率、修复成本、 override 率、事故数——不是 Demo 惊艳度。

11. 可观测性、评测与持续改进

传统 APM 不够。AI Native 需要按请求的 Trace Span：

  • 检索候选 + 分数（采样）；
  • Prompt 模板版本 + 哈希；
  • 模型路由、Token、延迟、成本；
  • 工具调用（名、参数哈希、结果）；
  • 人机门禁结果；
  • 用户编辑距离 / 拒绝原因。

尽早建 黄金评测集——50～200 个真实任务及期望行为（有引用、不调工具、遇 PII 拒答）。在以下变更时运行：

  • Prompt；
  • 模型升级；
  • 索引重建；
  • 路由阈值。

离线评测门禁发布；在线 Shadow 验证漂移。 否则每次上线都是在用户信任上做盲 A/B。

12. 失败模式与降级

设计 降级阶梯，而非二元 Toast：

| 失败 | 对用户 | 对系统 | |------|--------|--------| | 模型超时 | 部分草稿 + 重试 | 降级模型或仅检索模式 | | 检索未命中 | 「授权文档中无依据」 | 放宽检索一次；仍无则 abstain | | 工具失败 | 说明哪步动作失败 | 幂等重试；勿盲目循环 | | 上下文溢出 | 摘要旧轮次 | 结构化压缩，勿静默丢弃 | | 策略拦截 | 清晰原因 + 替代路径 | 安全审计日志 | | 厂商故障 | 排队或只读功能 | 多厂商路由（若合同允许） |

Abstain（拒答） 是能力——自信的错误比「据授权来源无法确认」代价更高。

13. 多租户、成本与路由

把 成本当作一等维度：

  • 租户 Token 预算与软/硬上限；
  • 模型路由：分类用小/快，综合用大；
  • 缓存嵌入与重复检索；
  • 离线任务错峰批处理；
  • 向产品团队展示 成本归因（功能 × 租户 × 模型）。

路由策略放在 配置中心，不要散落在 Handler 的 if 里——与模型实验的 Feature Flag 同一套路。

14. 演进路径：Copilot → 受控自治

带 显式关卡 的务实路线：

  1. 只读 Copilot — RAG + 引用；无工具；建立评测基线；
  2. 仅提议工具 — 变更预览；度量 override 率；
  3. 策略门控自动 — 低风险路径在规则内自动提交；
  4. 监督式 Agent — 多步 + 检查点；窄域场景；
  5. 更广自治 — 仅在有事故手册、Kill Switch 与回归预算时。

因「Agent 是未来」跳过 1–2，往往是在 客户投诉 而非 评测看板 上学会工具越权。

15. 反模式（清单）

  • 应用已有结构化状态，却只用 聊天 作唯一界面；
  • 上帝 Prompt 替代产品规则与 ACL；
  • 在用户-facing 延迟分级上 同步 跑多工具 Agent；
  • 只存全文对话作为 唯一 审计物；
  • 工具副作用 无幂等；
  • 所有分级与租户 共用一个模型；
  • Prompt 变更 无评测回归 即发布；
  • RAG 索引 写一次永不维护；
  • 对 不可逆 操作第一天就全自动。

小结

AI Native 架构是 含随机组件的系统工程：

  1. 闭环优先 — 意图、上下文、门禁、审计、反馈；
  2. 分层接缝 — 体验、编排、知识、动作、平台；
  3. 延迟与成本分级 — 不同界面、模型与后端；
  4. RAG 与记忆即流水线 — ACL、版本、评测；
  5. 工具即受治理 API — 白名单、Schema、幂等、策略；
  6. 可观测 + 黄金集 — 用证据发布，而非赌运气；
  7. 分阶段提高自治 — 提议 → 策略 → 自动，每关有度量。

模型每周都在换；边界、链路与评测 harness 才是在替换中维持可信产品的底座。交互设计解决用户如何校准依赖；底层系统 则要在生产中赢得这种依赖。