AI原生客户互动平台的工程演进

第一代软件自动化任务，下一代软件自动化决策。

从规则引擎到AI原生

过去的十四篇文章里，Atlas 从一个简单的通知服务，逐步成长为全球分布式客户互动平台。如今它每天处理数十亿事件、执行复杂客户旅程、自动跨区域扩展、故障自动恢复、持续部署、安全保障、成本优化，还通过内部开发者平台支撑几百位工程师。

从传统软件工程的角度看，Atlas 已经完工。但业务方问了一个基础设施无法回答的问题：

此刻，我们应该给这个客户发哪条通知？

不是明天，不是等报表出来，也不是等数据科学家导出 CSV。就是现在。

这个问题标志着从构建分布式系统，转向构建智能分布式系统。

规则引擎的瓶颈

最初 Atlas 依靠业务规则：

if(user.isPremium()) {
    sendPremiumOffer();
}
if(cart.isAbandoned()) {
    sendReminder();
}
if(user.hasNotLoggedInFor30Days()) {
    sendRetentionCampaign();
}

一开始很好用。直到产品团队创建了数百个、数千个活动。不同国家需要不同策略，用户行为不断变化，每周都要跑实验。规则引擎里堆积了成千上万的条件，没有工程师能全部理解。业务逻辑变得无法推敲。

于是 Atlas 不再问“这个用户是否匹配规则”，而是问：

这个用户有多大概率会互动？

平台不再返回 TRUE/FALSE，而是返回一个分数：

• 购买概率：87%
• 打开概率：62%
• 流失风险：11%

软件不再是二元决策，而是评估概率。

数据才是真正的产品

在引入机器学习之前，Atlas 已经握有非常宝贵的资产：事件。每次互动都会产生数据流：

通知送达 → 通知打开 → 商品浏览 → 购物车创建 → 完成购买 → 续订

单个事件平平无奇，聚合起来就描述了客户行为。机器学习并不创造智能，它只是发现已有数据中隐藏的模式。

特征管道

原始事件不能直接用于预测，模型需要特征。比如：

• 最近30天打开通知的次数
• 平均购买金额
• 最常互动的时段
• 设备类型
• 国家
• 上次活跃会话
• 活动点击率

Atlas 把原始事件转换成结构化特征：

Kafka 事件
    │
    ▼
特征管道
    │
    ▼
特征仓库

每个 AI 服务共享同一份特征基础，而不是各自重复计算。

在线与离线特征

有些特征变化很慢：国家、订阅类型、注册日期。有些每秒钟都在变：当前会话、购物车商品、最近搜索、当前设备。

Atlas 将它们分开存储：

离线特征仓库 → 历史数据
─────────────────────
在线特征仓库 → 实时特征

预测请求同时结合两者，在保证准确性的同时不牺牲延迟。

推荐服务

顾客打开 App 时，过去的 Atlas 问：“哪个活动在投放？”现在的 Atlas 问：“哪个活动最相关？”

顾客 → 推荐服务 → 最佳活动 → 通知平台

通知服务变成了执行引擎，推荐引擎决定执行什么。职责保持分离。

实时推理

比如客户正要放弃购物车。Atlas 不会等明天的批处理。

购物车事件 → Kafka → 特征更新 → 推断 → 工作流决策 → 通知

整个决策耗时小于 300 毫秒。客户互动变成了上下文相关的，而不是按计划触发的。

AI 不会替代规则

很多平台犯的错误，是用机器学习完全替代确定性业务规则。Atlas 两者并用：

业务政策 → 推荐模型 → 政策校验 → 最终决策

例如模型推荐一个促销活动，但业务政策发现用户已经退订营销通知，Atlas 就什么都不发。

AI 负责建议，政策负责决策。

构建反馈闭环

智能系统靠反馈不断改进。每次预测都会产生结果：通知打开了吗？购买了吗？还是被忽略了？这些结果回到训练管道，明天的模型从今天的行为中学习。平台持续自我进化。

模型版本管理

之前我们为 API 做版本管理，模型也需要同样的纪律。新模型先服务小部分流量：5% → 25% → 50% → 100%，持续对比效果。如果互动率下降，就立刻回滚，和回滚软件一模一样。

特征漂移

生产环境出过一次事故：推荐准确率突然下降。基础设施健康，模型没变，代码没变——问题出在数据上。客户行为已经变了，模型还在用过时的假设做决策。

现在 Atlas 持续监控：

• 特征分布
• 预测置信度
• 转化率
• 训练与服务的一致性

机器学习系统需要像微服务一样进行运维监控。

AI 用于运维

Atlas 不只用 AI 服务客户，也用来帮工程师。比如 Kafka 消费滞后增加时，旧告警只会说“消费滞后过高”。现在 Atlas 关联事件链：

部署 → 延迟上升 → 消费滞后 → 重试尖峰 → 可能原因：某 worker 发布版本

它不再汇报症状，而是给出可能根因，故障响应速度快得多。

预测性自动扩缩容

过去的自动扩缩容响应 CPU 达到 85% 才扩容。Atlas 现在根据历史流量模式预测需求：每周一早上 9 点流量增加 220%，基础设施在流量到达前就扩容好了。客户永远感觉不到资源紧张。

预测代替了反应。

人在环路

并非每个 AI 决策都应该自动执行。Atlas 把决策分级：

• 低风险：自动执行
• 中风险：工程师审核
• 高风险：人工审批

比如调整通知时机可以自动，删除活动需要人工，拉黑客户账户一定要审批。

目标不是去掉人，而是帮人做更好的决策。

Atlas 的 AI 架构总览

客户事件 → Kafka Topics → 特征管道 / 分析 / 运维
                              │
                              ▼
                          特征仓库（在线+离线）
                              │
                              ▼
                          推荐模型 → 政策引擎 → 工作流引擎 → 通知平台

注意一个重点：人工智能没有替代 Atlas，它变成了平台里的另一个服务。遵循同样的架构原则：松耦合、事件驱动、独立部署、可观测、版本化、有韧性。

AI 是普通的生产负载，不是特殊系统。

工程权衡

目标不是让每个决策都用 AI，而是识别哪些地方预测真的能改善业务结果。

经验教训

对 AI 的最大误解，是认为它和软件工程根本不同。在生产环境，它没有不同。模型同样需要版本管理、监控、回滚、测试、可观测性、安全、部署管道——和我们在 Atlas 里构建的任何服务一样。

真正的创新不是加一个机器学习模型，而是把它集成到可靠的工程平台中。Atlas 不是因为我们部署了一个模型才变聪明，而是因为周围有一套让模型安全演进、优雅失败、持续改进的架构。

这就是 AI 演示和 AI 平台的区别。

系列总结与下一步

15 篇文章，Atlas 从简单的通知 API 成长为现代分布式系统的蓝图。覆盖了异步消息、事件驱动、分布式工作流、全球扩展、实时分析、微服务弹性、分布式事务、多语言持久化、流量工程、持续交付、可观测性、零信任安全、成本优化、平台工程、AI 原生架构。

下一步将推出新系列：Building Atlas: Disaster Recovery & Planetary Resilience，探讨多区域双活架构、区域切换零停机、全球数据复制、RPO/RTO、混沌工程、容灾演练、数据主权、跨区域消息、全局一致性、黑天鹅工程。

因为分布式系统的终极测试，不是它在正常日子里表现如何，而是它在一切出问题的那一天表现如何。