Version: 0.9.65.dev.260503

后端：
1. 阶段 1.5/1.6
收口 llm-service / rag-service，统一模型出口与检索基础设施入口，清退 backend/infra/llm 与 backend/infra/rag 旧实现；
2. 同步更新相关调用链与微服务迁移计划文档

docs/backend/微服务四步迁移与第二阶段并行开发计划.md

@@ -36,6 +36,8 @@
 4. 消费侧已经按服务 consumer group 隔离，不再用一个 worker 吃全部事件。
 5. 当前仍是单体进程内多 worker 装配；worker 后续会跟随对应服务一起迁出，不在阶段 1 直接拆进程。
 
+阶段 1.5 / 1.6 也已经先落地完毕：`backend/services/llm` 和 `backend/services/rag` 已经成为当前 canonical 入口，`backend/infra/llm` 和 `backend/infra/rag` 的 `.go` 旧实现已删除，仅保留迁移说明文档。当前仍然是单体进程内多 worker 装配，llm / rag 先完成服务化收口，还没有进入 gozero 进程拆分。
+
 所以后续路线不是再补一次 outbox 基建，而是在这个阶段 1 基线上，按服务边界逐个把 gozero 服务、DAO / model / worker 和启动入口迁出去。
 
 ---
@@ -78,6 +80,8 @@ gozero 服务负责领域能力：
 > 说明：`agent` 和 `memory` 都可以单独成服务，不应再被写成“公共能力”；其中 `agent` 更像对外对话编排服务，`memory` 更像其支撑服务/worker 服务。
 >
 > 说明：`llm-service` 先抽成全仓统一模型出口，`rag-service` 再抽成检索基础设施服务；`rag-service` 只能依赖 `llm-service`，不反向依赖具体业务服务。
+>
+> 当前状态：`llm-service` / `rag-service` 这两个边界已经先做成 `backend/services/*` 的服务内模块，调用仍由 `backend/cmd/start.go` 在同一进程内装配，不是 gozero 独立进程。
 
 ### 3.3 事件层
 
@@ -118,8 +122,8 @@ gozero 服务负责领域能力：
 | --- | --- | --- | --- |
 | 0 | 语义冻结和基线确认（已完成） | 阶段 0 已作为历史基线保存；后续只在契约变化时回看 | `go test ./...`，`api / worker / all` 启动 smoke |
 | 1 | Outbox v2 基建（已完成，当前基线） | 当前已具备阶段 1 保存点：服务级 outbox 表、topic、group 和多 worker 装配已打通 | 已完成健康检查、服务级 outbox 写入/投递/消费 smoke、Kafka group lag 核对 |
-| 1.5 | 先抽 llm-service | 统一模型调用、provider 路由、流式输出和审计后 commit | course / active-scheduler / memory 模型调用 smoke |
-| 1.6 | 再抽 rag-service | 向量化、召回、重排、检索能力跑通后 commit | memory retrieve / rerank smoke |
+| 1.5 | 先抽 llm-service（已完成） | 已完成，`backend/services/llm` 作为当前 canonical 入口 | `go test ./...` + course / active-scheduler / memory 模型调用 smoke |
+| 1.6 | 再抽 rag-service（已完成） | 已完成，`backend/services/rag` 作为当前 canonical 入口 | `go test ./...` + memory retrieve / rerank smoke |
 | 2 | 先拆 user/auth | user 路由、JWT 签发和 token 额度治理独立后 commit | 注册/登录/刷新/登出 smoke + token quota 回归 |
 | 3 | 再拆 notification | notification 服务能独立消费和重试后 commit | notification E2E smoke + worker-only smoke |
 | 4 | 再拆 active-scheduler | 预览生成和确认链路通过 gozero 服务跑通后 commit | dry-run / preview / confirm smoke |
@@ -229,7 +233,7 @@ flowchart LR
 
 ---
 
-### 4.4 阶段 1.5：先抽 llm-service
+### 4.4 阶段 1.5：先抽 llm-service（已完成）
 
 目标：
 
@@ -237,6 +241,12 @@ flowchart LR
 2. 让 `course`、`active-scheduler`、`memory`、`agent` 对模型调用的依赖先收口到统一服务。
 3. 先把模型 provider 路由、流式输出、限流、审计这些共性收束起来，避免每个服务各写一份。
 
+当前状态：
+
+1. 代码已经落到 `backend/services/llm`。
+2. `backend/infra/llm` 的 `.go` 旧实现已删除，仅保留迁移说明。
+3. 仍由 `backend/cmd/start.go` 在同一进程内装配，尚未引入 gozero 独立服务进程。
+
 这一步要做的事：
 
 1. 把当前分散在业务服务里的模型调用入口改成统一调用 `llm-service`。
@@ -260,7 +270,7 @@ flowchart LR
 
 ---
 
-### 4.5 阶段 1.6：再抽 rag-service
+### 4.5 阶段 1.6：再抽 rag-service（已完成）
 
 目标：
 
@@ -268,6 +278,12 @@ flowchart LR
 2. 让向量化、召回、重排、向量库读写先进入独立服务。
 3. 明确 `rag-service` 只能依赖 `llm-service` 做 embedding / rerank，不反向依赖业务服务。
 
+当前状态：
+
+1. 代码已经落到 `backend/services/rag`。
+2. `backend/infra/rag` 的 `.go` 旧实现已删除，仅保留迁移说明。
+3. 仍由 `backend/cmd/start.go` 在同一进程内装配，尚未引入 gozero 独立服务进程。
+
 这一步要做的事：
 
 1. 把当前分散在 `memory`、`agent` 里的检索逻辑改成统一调用 `rag-service`。
@@ -474,6 +490,8 @@ flowchart LR
 
 当前建议按这个顺序推进：
 
+注：阶段 1.5 / 1.6 已完成，当前实际推进可从阶段 2 开始。
+
 1. 以阶段 1 的服务级 outbox 为当前基线，不再回头做共享 outbox 方案。
 2. 先切 llm-service，把统一模型出口从各业务服务里抽出去。
 3. 再切 rag-service，把检索基础设施从 memory / agent 里抽出去。