线上已在跑：还要不要在本仓加 Spring AI？
结论（拍板）：继续在
tour-mate-platform里做，不重构旧业务，不先拆独立 AI Server。
用「新限界上下文 + Port 隔离 + 开关默认关」保护现网。等助手真有流量或模型故障会拖垮主站时，再拆进程。
1. 你的担心拆开看
| 担心 | 是否成立 | 怎么处理 |
|---|---|---|
| 线上已经在跑（哪怕只有自己测） | 成立：任何改动都可能发版带风险 | 新接口 + 配置开关默认 false；不改现有活动/订单 Controller |
| DDD 被 Spring AI 污染 | 只有「Domain 直接依赖 ChatClient」才会 | Domain 只认 ILlmPort；Spring AI 放 Infrastructure |
| 要不要先独立部署才安全 | 独立进程隔离更好，但一个人两套发布/鉴权更危险 | 先同进程、开关隔离；拆分是以后的优化 |
「自己测试用的线上」和「有真实用户的生产」风险等级不同，但习惯要按生产来：开关、不改旧路径、Key 不进仓库。
2. 市面上怎么做（很少重构老项目）
真实产品几乎不会为了加助手把旧系统推倒重来。常见是三条路，按公司规模往右走：
同进程模块（起步）
→ 独立「模型网关 / AI 服务」（隔离超时与扩缩）
→ 再对外 MCP / 多 Agent 平台（少数）| 类型 | 典型做法 | 会不会重构主站 |
|---|---|---|
| 电商 / 出行 App 里的「智能客服、搜一搜」 | 主站或 BFF 里接模型；查商品/订单走原有 API | 否，加入口和编排 |
| 中后台 Copilot（飞书、内部运营） | 先嵌在 Admin；工具调现有权限接口 | 否 |
| 大厂到一定量 | 拆 AI Gateway（限流、多模型、超时），主站仍是业务真相 | 抽网关，不重写交易 |
| 独立「AI 产品」公司 | 本来就是 AI 服务，业务系统是别人的 | 不适用你 |
你看到的「独立 AI Server」，多半是：
- 模型调用要单独扩容 / GPU；或
- 编排是 Python；或
- 安全组要求 Key 不能进业务机；或
- 已经有独立团队
不是「接入助手必须先拆服务」。业务系统保持 DDD，AI 是新的触发方式——和当初加微信支付、加 OSS 是同一类事：Infrastructure 多一个 Adapter，Domain 多一个 Port。
3. 对现有六边形的影响（按这个做就接近零）
不要：新建一套平行的活动/订单模型，或让 ActivityAggregate 依赖 Spring AI。
要：AI 只是新入口，Tool 调已经存在的 ApplicationService。
trigger/assistant/AssistantController 新文件，旧 Controller 不动
domain/assistant/ 新包：编排、Intent、IAssistantApplicationService
domain/assistant/port/out/ILlmPort 出站 Port，不含任何 spring-ai 类型
infrastructure/assistant/SpringAiLlmAdapter 唯一允许 import spring-ai 的地方
app 装配 Bean、配置 tourmate.assistant.enabled依赖方向（和现有纪律一致）：
Trigger → Domain Port
Domain assistant → 现有 IActivityQueryApplicationService（同层调用，已有先例）
Infrastructure → Domain（实现 ILlmPort）
Domain ✗ 不得依赖 spring-ai / 厂商 SDKMaven 起步用包级即可，不必先加第七个 module。若你心理上更怕「依赖泄漏」，可以再加 tour-mate-platform-assistant，但第一期收益不大。
Spring AI 的 jar 只进 infrastructure（或 app），不要进 domain / api / types。这和 ADR-038「API 不加序列化框架」是同一类纪律。
4. 保护现网的最低措施（比拆服务更重要）
tourmate.assistant.enabled=false作为生产默认；本地/测试 profile 再打开。- 只新增
/api/assistant/**，现有/api/activity/**、订单、IM 零改动（最多复用查询方法，不改签名）。 - 模型 Key、Base URL 走环境变量；未配置时 Bean 不创建或健康检查失败，不影响主站启动（
@ConditionalOnProperty）。 - 助手限流单独做，避免刷对话拖垮 Tomcat 线程（模型调用要设超时，建议 10～20s，且不要占满默认线程池——必要时单独
TaskExecutor）。 - 发版可先关开关上线空模块，确认主站无回归后再打开。
这样「加了 Spring AI」≈ 多一段不会执行的代码，和你加过 Actuator、内容审核 Adapter 的风险同级。
5. 什么时候才值得独立 AI Server
出现下面 任意两条 再拆，不要提前：
- 助手 QPS 或 Token 成本已经需要单独扩容
- 模型超时 / 厂商故障导致主站线程或健康检查抖动
- 编排改 Python（LangGraph）且要长期跑生产
- 多个系统要共用同一套 Tool（那时才是 MCP / 独立服务的理由）
拆的时候也是 抽 Adapter + 编排，主站继续提供 Tool API，不是重构 DDD。
6. 和「新开一个 AI 项目」这句话怎么对齐
- 能力上：你在做 AI 应用开发（新窗口、新专题）。
- 仓库上：还是这一个 Git，多一个
assistant包。 - 进程上：还是现在这个 Spring Boot 进程，多一个默认关闭的开关。
市面产品：加助手 = 加模块；做大了 = 抽网关。几乎没有「为了助手把出行主站重写成 AI 项目」这种路径。