无论是方法调用、DTO、RPC 还是事件消息，本质上都是结构化协议。
而在真实世界中，尤其是 AI 参与的场景里，交互首先出现的是语义意图，而不是稳定结构。 DAD（Domain Actor Design），是一种面向 AI 时代的领域建模方式，其核心系统单元是 AI Actor。 一、Actor 模型：不是并发技巧，而是领域单元
Actor 模型的本质是：
Actor 是独立运行的实体
Actor 之间只通过消息交互
Actor 内部状态不可被外部直接访问
Actor 自行决定如何处理收到的消息
Actor 模型真正解决的是：
如何在不共享状态、不直接调用的前提下，让复杂系统保持自治。
在 DAD 中，Actor 不再只是并发模型，而是领域的最小自治单元。 二、传统 DDD 消息化后的真实问题
即便系统已经采用“消息驱动”：
消息依然是固定结构
接收方必须提前知道结构
发送方必须知道对方能处理什么结构
结果是：
领域之间的耦合，从方法签名，转移成了消息结构。
在 AI 时代，这种问题被进一步放大：
AI 产生的输入天然不稳定
表达可能正确，但结构不完整
系统无法容忍“语义正确但结构不完美”的请求
三、DAD 的核心单元：AI Actor
在 DAD 中，领域的最小自治单元是 AI Actor。
AI Actor 由三个部分组成：
Agent + Mailbox + 领域服务程序
这是一个职责清晰、边界严格的结构。 四、AI Actor 的三个组成部分（最终定义）
1️⃣ Agent：AI Actor 的唯一边界
Agent 才是 AI Actor 的物理与逻辑边界。
所有进入 Actor 的信息，必须先经过 Agent。
Agent 的职责是：
（1）语义解析与校验（入口关卡）
接收外部消息（JSON / 文本 / 混合）
判断：
对方想做什么
信息是否语义完整
是否属于当前 Actor 的职责范围
❌ 不合格的消息：
直接返回语义化错误
告知问题在哪里、缺什么
不会进入领域执行路径
结构正确 ≠ 语义合法
（2）意图 → 结构化任务
当语义被确认后，Agent 会：
将“意图”转换为结构化任务
明确：
任务类型
已确认的数据
执行前置条件
Agent 不决定如何执行，只负责：
把“我理解了”变成“你可以执行了”。
（3）执行结果的语义化输出（出口）
领域服务程序执行完成后：
返回的是结构化执行结果
Agent 负责：
解释执行结果
组织语义响应
返回给原消息发送方
Agent 是唯一的语义入口，也是唯一的语义出口。
2️⃣ Mailbox：领域服务的任务串行化机制
Mailbox 不是 AI Actor 的边界，也不承担语义职责。
Mailbox 的唯一目的：
保证领域服务任务的顺序性与一致性。
它的特点是：
FIFO
可持久化
只存结构化任务
不理解任务含义
不参与任何业务决策
Mailbox 的存在意味着：
领域服务程序只面对确定、可执行的任务
Actor 内部状态不会被并发破坏
Actor 可以安全重启并恢复执行
3️⃣ 领域服务程序：Actor 的执行体
领域服务程序是：
一个持续运行、由 Mailbox 驱动的 Actor 执行体。
它内部包含：
执行循环
状态机
领域对象代码
业务规则
状态 / 事件持久化逻辑
领域服务程序的特征非常明确：
只接收结构化任务
串行执行
不解析语义
不暴露方法
不直接与外部通信
领域对象代码全部存在于领域服务程序内部。
五、AI Actor 的完整消息处理流程（最终闭环）
这是 完整且不可省略的 AI Actor 消息生命周期。 ① 外部消息到达 Agent（Actor 边界）
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
千斤顶
照妖镜
