团队想给客服系统加 AI 能力，产品经理一句"接个大模型"听起来轻巧。真要做时，我发现最大的问题不是模型效果，而是：AI 该放在系统哪一层？和现有业务怎么融？出错了怎么办？这层边界不清，迟早把核心交易拖下水。
边界划分：AI 是增强，不是核心
我的第一原则是：AI 能力必须处在非关键路径。下单、扣款、库存这些核心链路，绝不直接调大模型。AI 只在"建议""辅助""摘要"这类增值环节出现。比如客服系统，AI 负责生成"建议回复草稿"，最终发送仍由人工或既有规则引擎确认。这样即使 AI 全挂，核心业务照常跑，只是少了智能化那一层。
异步解耦：别让 AI 卡住主流程
大模型调用动辄几百毫秒到几秒，同步嵌在主流程里会把吞吐拖垮。我们的做法是用消息队列把 AI 计算和主流程切开：
// 主流程只发事件，不等待
kafkaTemplate.send("ai-summary-tasks",
new SummaryTask(orderId, transcript));
// AI 消费者异步处理，结果写回另一张表/缓存
@KafkaListener(topics = "ai-summary-tasks")
void handle(SummaryTask t) {
String summary = llm.summarize(t.transcript());
summaryRepo.save(t.orderId(), summary);
}主流程 P99 因此不受 AI 延迟影响，AI 慢了顶多"摘要晚到几秒"，用户体验是"先看到原始内容、后看到摘要"，完全可接受。
流量特征的差异
| 维度 | 核心交易 | AI 增强 |
|---|---|---|
| 延迟要求 | < 50ms | 可接受 1-5s |
| 失败容忍 | 极低，需强一致 | 较高，可降级 |
| 资源波动 | 平稳 | 随 prompt 长度剧烈波动 |
| 调用方式 | 同步+事务 | 异步+重试 |
降级方案：AI 不是永远在线
大模型 API 会限流、会超时、会抽风。我们设计了三级降级：
- 超时降级：单次调用超 3 秒，返回"暂时无法生成，请稍后再试"或缓存的旧结果；
- 限流降级：API 返回 429，本地退化为"基于规则的模板回复"，虽然不聪明但能答；
- 全量降级：AI 服务整体不可用时，开关一键关掉所有 AI 入口，系统退回纯规则版，功能不丢。
降级开关走配置中心（如 Nacos），秒级生效，不用发版。我们甚至做了"灰度降级"——某个租户出问题只关它一个，不影响全局。
与业务融合：把 AI 当"有状态的组件"
AI 不是外接黑盒，它要读业务上下文才有用。我们建了一层"AI 上下文装配器"，在调模型前把订单状态、用户画像、知识库片段拼成结构化上下文，模型输出再经"业务校验器"过滤（比如不允许 AI 承诺超出实际库存的发货时间）。这层装配和校验，是 AI 真正融入业务的关键，也是最容易偷懒省略、最后出事的地方。
成本与 ROI 评估
AI 能力要算账。我们给每个 AI 入口建了成本看板：每次云模型调用的 token 成本、本地模型摊销的 GPU 折旧、人工审核兜底的人力。客服摘要场景，上线前人工写回复人均 3 分钟/单，AI 草稿把时间压到 40 秒；按客服 30 人、日均 200 单算，每月省下约 480 个人工时，折算人力近 8 万，而 AI 调用月费约 1.2 万，ROI 明显为正。但负 ROI 的场景也存在——一个内部小工具接了 AI 润色，使用频次低、云费用却不低，评估后我们关掉了它。AI 不是接了就赚，得用成本看板持续审视"这笔智能值不值"。
还有一类隐性成本常被忽视：模型版本升级。云端模型半年一迭代，效果变好也可能行为偏移，我们的回归测试集每次升级都要重跑，这部分人力也要算进 ROI。把账算全，才不会被"接入即增效"的叙事带偏。
写在后面
现在回头看，《AI 能力接入现有系统的架构设计》本身不算多难，难的是线上真出问题那十分钟里的判断。经验都是这么来的。