三模块发布结构
client 管契约，starter 管装配，strategy 承载绝大多数业务实现。真正的业务边界在 strategy 内部五个领域。
ENGINEERING REVIEW + TARGET ARCHITECTURE · 2026-08-16
智能运营策略中心
从确定性 Journey Orchestrator 到 Agent 驱动的千人千面运营平台
现有状态机可以保留，智能内容能力应独立建设。策略中心继续负责资格、实验、频控、旅程和副作用；Agent 平台负责文案、图片与渠道内容，自动审核后直接投放，BPM 只审批版本和系统性异常。
01
项目快照
已验证现状 · 基于 2026-08-12 的主分支静态分析
- Java 文件
- 316
- Java 代码
- 约 24,100 行
- Proto 契约
- 7
- 运行入口
- 21
- 核心数据表
- 10
- 测试文件
- 0
当前系统不是模型驱动的 AI 决策引擎，而是一个用户级 Journey Orchestrator。未来不需要推翻它：应把它升级为确定性决策与执行底座，并在外部增加可治理的 Agent 内容生产平面。
业务完整度 8/10
架构清晰度 7/10
可靠性 4/10
可测试性 2/10
02
系统架构
数据库状态是事实源，Binlog 与 MQ 驱动长链路继续向前。
异步状态机
分支与动作记录写库后，由 KBus 监听状态变化并投递下一事件，适合大人群、长等待和可回放的运营链路。
扩展机制
人群、条件、动作和效果分别由 Factory + Handler 扩展，外部系统调用集中在基础设施适配层。
03
核心执行流程
从策略上线到批次完成，核心对象在四条泳道中推进。
04
能力边界
业务能力已经覆盖一次完整的主动运营闭环。
4
人群来源
- 文件上传
- CDP 人群包
- 第三方实时推送
- MDS 取数
9
分流条件
- GMV 与组织归属
- 微信联系状态
- 活动与任务进度
- 通知、外呼效果
8
运营动作
- 活动、企微、外呼
- 站内信、弹窗、短信
- RPA 建联
- 创建工单
3
推进方式
- 立即递归分流
- 延迟消息等待
- 等待效果后分流
- 条件未知延迟重试
明确边界：GMV 条件当前仍是占位实现；事件型策略虽有枚举模型，当前可确认的完整主链路仍以定时触发和第三方人群推送为主。
05
千人千面未来架构
双控制面：策略中心管确定性决策与执行，Agent 平台管内容生产。
目标态设计，不是当前实现清单。青色模块可复用或增强现有能力，绿色模块需要新增，金色模块属于 BPM 与治理边界。
Agent 不进入现有并列 Action
内容生成拥有独立子状态机。只有用户级 ContentBundle 进入 READY，才能创建投放指令，避免生成和发送无序并发。
每个用户都有独立内容版本
文案按用户生成；P2 等高价值用户可生成用户级图片，大规模人群采用生成式底图与用户级动态组合。
学习只进入下一版本
内容、模型、提示词、策略和用户决策全部留痕。效果反馈离线优化下一版本，不在线篡改正在运行的不可变版本。
06
千人千面智能促报名流程
从活动版本审批到直接投放、自动报名、报名后接管和 DiD 反馈。
先决策，再生成
资格、报名状态、实验、预算和频控先通过，避免为不能触达的用户消耗模型和图片成本。
文案与图片并行
两类 Agent 共用同一事实简报和用户上下文，渠道适配完成后统一进入自动审核。
发送必须消费 READY 内容包
DeliveryIntent 只引用已就绪内容包，并以全局幂等键保证重试不重复触达或报名。
报名不是终点
报名成功后创建任务托管计划，以净增完成商家数而不是报名率作为北极星指标。
07
十二个关键模块
围绕活动事实、确定性决策、内容生产、可靠执行和效果闭环拆分。
复用 / 增强现有
新增平台能力
BPM / 治理
CampaignSpec 中心
统一活动时间、A/B/C 类型、资格、截止日、报名参数、退出协议和结构化达标条件。
用户上下文中心
生成带版本与时间戳的画像快照，限定允许进入生成模型的个性化字段。
实验、预算与频控
稳定哈希切分 90/10，对模型、图片、渠道和外呼成本统一预算与跨策略频控。
截止时间节奏引擎
用动态 Deadline Scheduler 替代固定等待，按剩余时间选择标准、压缩、并行或临期路径。
Journey 编译与执行
复用分支状态机，增加 P1-P4、下一最佳动作、事件触发、冷却与解冻语义。
Agent Orchestrator
编排活动理解、用户洞察、文案、图片、渠道适配、审核和评分的依赖与重试。
ContentBundle 资产中心
保存用户内容、素材引用、模型与提示词版本、事实来源、风险结论、回退和 TTL。
自动审核与 BPM
单条内容自动审核；BPM 只审批政策、发布版本、生成规则和系统性异常。
DeliveryIntent 与 Outbox
将内容包、渠道、计划时间和幂等键持久化，并保证状态与投放事件原子提交。
报名事务服务
封装现有 activity_draw，补充知情确认、退出、状态核验和审计协议。
任务托管计划
新增 task_plan_create，按结构化达标条件创建自动执行、进度回执和助推计划。
事件、效果与 DiD
统一曝光、回复、报名、拒绝和经营事件，度量净增完成商家、成本、投诉与实验增量。
08
审批边界与能力映射
让 BPM 管版本风险，不让人工审批阻塞千人千面的实时链路。
RULE 01
审批版本，不审批用户
审批对象是政策、策略图、提示词、图片规范、阈值和回退模板。
RULE 02
单条失败不阻塞
自动审核失败时使用已审批模板；生成超时、预算不足也走同一降级路径。
RULE 03
系统性风险才停版本
违规集中爆发、投诉激增或模型漂移时自动暂停对应版本并创建 BPM 异常单。
四个 BPM 闸门
| 闸门 | 审批对象 | 对运行时的影响 |
|---|---|---|
| G1 · 活动政策 | A 类默认报名、B 类一键确认、退出机制、权益范围 | 未通过不得发布活动 |
| G2 · 策略版本 | 人群、实验、节奏、频控、预算、渠道权限 | 发布不可变 StrategyVersion |
| G3 · 生成策略 | 模型、提示词、品牌与图片规范、审核阈值、回退模板 | 发布 GenerationPolicy，用户内容自动执行 |
| G4 · 异常处置 | 系统性合规失败、投诉激增、模型漂移 | 暂停问题版本，其他版本继续运行 |
当前能力如何演进
| 当前代码能力 | 未来处理 | 必须补齐 |
|---|---|---|
| 分支 / Action / Effect 状态机 | 保留为 Journey 执行内核 | 事件触发、动态节奏、冷却解冻 |
| 数据库 + Binlog + MQ | 保留事实源和异步推进 | Outbox、统一幂等、超时恢复与安全重放 |
activity_draw | 作为报名事务底层动作 | 知情确认、退出、结果核验和审计 |
create_ticket | 不承担精细任务托管 | 新增 task_plan_create 和结构化任务计划 |
固定 DELAY | 仅用于简单固定等待 | 新增 Deadline Scheduler，保证链路不跑过截止日 |
| 企微文本与弹窗 Redis 标记 | 继续作为渠道适配底座 | 交互卡片、内容包引用和报名确认前端 |
| GMV 条件占位实现 | 短期不作为 P2 判定依据 | 先由 MDS/CDP 产出 Top20% 标签，再逐步内建 |
| 事件策略枚举 | 保留模型概念 | 补完整 Event Trigger Gateway 和用户级执行主链路 |
09
架构优势
值得保留并继续放大的部分
- 01
领域边界基本成立
策略、分流、条件、动作、效果没有全部堆在 RPC 层。
- 02
显式状态模型
批次、分支、动作与效果均有清晰状态，长等待可以持久化。
- 03
面向大人群设计
分库分表、游标扫描、批量聚合与动态配置均已进入实现。
- 04
外部依赖有适配边界
渠道与数据调用集中在 infra，便于替换和隔离。
10
主要风险
按业务影响与修复紧迫度排序
初始人群消息失败会永久漏用户
同步发送失败只记录日志，任务仍累计人数并推进翻页断点。漏掉的用户无法自动补发，批次还可能长期无法完成。
单点渠道副作用与本地状态之间没有恢复闭环
单点外部渠道成功后若进程在写成功状态前退出，记录会停留在执行中；重复事件又会因为记录已存在而跳过。
危险运维能力与正式管理接口混部
硬删除、任意改状态、模拟推送、查询敏感业务字段等能力需要独立权限域和完整审计。上游是否已有保护仍需内网核验。
状态机复杂度与测试投入不匹配
仓库没有测试，消息重复、乱序、部分失败、条件重试和版本切换缺少自动化回归保障。
状态比较与基础配置存在漂移
Binlog 前后值使用对象引用相等；MyBatis 版本与分页数据库类型也不一致，应统一并补测试。
11
未来落地路线
先把现有执行链路变得可恢复，再逐层开放确定性决策、Agent 内容和自动闭环。
-
阶段 0 · 可靠性前置
先修复现有 P0 断点
消息失败不推进断点；建立 Outbox、统一幂等、渠道对账、超时恢复、状态机测试和安全重放。
-
阶段 1 · 确定性底座
补齐促报名的决策能力
上线 CampaignSpec、稳定实验、P1-P4 标签、动态节奏、跨渠道频控、事件触发和报名事务协议。
-
阶段 2 · Agent 灰度
从只生成到直接投放
先 Shadow 生成，再灰度 P1/P2；上线 ContentBundle、自动审核、回退模板、DeliveryIntent 和内容效果归因。
-
阶段 3 · 完成率闭环
开放任务托管与自学习
上线 task_plan_create、自动执行与助推、冷却解冻、原生 DiD；学习结果只进入下一不可变版本。
VERIFICATION
结论边界
当前态已验证：模块结构、Proto 契约、启动装配、状态模型、定时任务、消费者、Binlog Resolver、DAO、外部适配与 Git 历史。
未来态性质：基于当前代码边界与“智能促报名 2.0”业务草案形成的目标设计，不表示这些模块已在仓库中实现。
仍需业务确认：A 类默认报名政策、外呼单价与产能、企微好友覆盖率、图片生成预算、投诉阈值和任务代做能力边界。
构建限制：本地缺少内部 Maven 父 POM，构建在依赖解析阶段停止；这不等于代码已经被证明编译失败。