是否必须新开一个 AI 项目？
结论（建议）：C/B 助手不强制新开独立产品仓库；更推荐 主站内新增 AI 模块（或薄 AI 服务），用现有 Domain Port 当 Tool。
独立仓适合：编排极重、团队拆分、或 Python LangGraph 实验要长期跑生产时再拆。
1. 先澄清「新开 AI 项目」可能指三种东西
| 含义 | 要不要 | 说明 |
|---|---|---|
| A. 新学一套 AI 应用（新技术域） | ✅ 要 | 这是能力目标，与仓库无关 |
B. Git 上新建 tour-mate-agent 独立仓 | ⚠️ 非必须 | 过早拆仓会双倍发布/鉴权/联调 |
| C. 进程上独立微服务 | ⚠️ 可后期 | 流量与模型成本上来再拆 |
很多人把 A 和 B 绑在一起。对你当前阶段，做 A，暂缓 B。
2. 三种落地形态对比
形态 1：主站内模块（推荐起步）
tour-mate-platform
├─ domain/... 现有业务
├─ （新）assistant 或 ai 相关包/模块
│ ApplicationService / Tool Dispatcher
│ 调 IActivity... 等已有 Port
└─ trigger 增加 AssistantController适合：C 端 NL 搜活动、B 端只读分析第一期。
优点：权限、用户上下文、事务、发布链路复用；Tool 就是调自己的 ApplicationService。
缺点：模型依赖与业务 jar 耦合；要控制好依赖方向（AI 编排依赖 Domain，Domain 不依赖具体模型 SDK 细节——可用 Port 隔离）。
形态 2：独立 AI 服务（同组织内）
tour-mate-ai-service ──HTTP/RPC──► tour-mate-platform（业务 API）适合：多端 Agent、独立扩缩容、或 Python 编排为主。
优点：技术栈自由；模型故障隔离。
缺点：要重做鉴权透传、幂等、超时、契约版本；本地联调成本高。
建议：等 C 端 MVP 在主站验证「卡片点击率」后再评估拆分。
形态 3：完全独立「AI 产品仓」+ 只打外部 HTTP
学习 Demo 可以，但接 TourMate 真实活动时，会快速退化成「又写一遍 BFF」。
除非你明确要做可对外售卖的 Agent 平台，否则对个人项目过重。
3. 和「Spring AI / LangChain4j」的关系
框架选择解决的是 怎么调模型、怎么绑 Tool、怎么做 RAG，
不决定必须新开仓库。
- 主站内模块：直接引 Spring AI 或 LangChain4j 依赖即可。
- 独立服务：同一框架换个 Boot 工程。
- Python LangGraph：更适合「实验编排 / 长工作流」，用 HTTP 调主站 Tool API；不必一上来取代 Java 主路径。
4. 决策树（可直接用）
是否已有稳定业务 API / ApplicationService？
├─ 是 → 主站内做 Assistant 模块（默认）
└─ 否 → 先补业务能力，再谈助手
C 端是否只要「搜活动 + 深链」？
├─ 是 → 不要独立仓
└─ 复杂多 Agent 长流程 + 要独立扩缩 → 再拆 AI 服务
是否主要用 Python 做生产编排？
├─ 否（Java 主路径）→ 主站模块或 Java AI 服务
└─ 是 → 独立 Python 服务 + 主站暴露 Tool API（注意鉴权）5. 建议你怎么落（可执行）
阶段 0（现在）
- 本目录继续沉淀方案与评测集。
- 主仓尚未开干前，不必建空 AI 仓。
阶段 1（C 端 MVP）
- 在
tour-mate-platform增加 assistant 相关模块/包 + Admin/App API。 - Tool = 现有活动查询。
阶段 2（B 端工作流变重）
- 若 Java 状态机够用，继续主站。
- 若强需求 LangGraph checkpoint / 复杂人机回路，再开
tour-mate-agent-orchestrator（Python），主站只暴露受控 Tool API。
阶段 3（有流量）
- 按成本与隔离拆模型网关 / 独立扩缩。
6. 一句话回答你的原话
「不管做 B 还是 C，都需要新开一个 AI 项目对吧？」
不对齐「必须新开仓库」这句话。
需要对齐的是：新开一个 AI 能力边界（模块或服务）+ 明确 Tool 契约；仓库可以仍是 tour-mate-platform，直到拆分的收益大于联调成本。