背景
当前 lark reply 主链路为：
ConversationGAgent -> IChannelLlmReplyRunDispatcher -> AgentRunDispatcher -> AgentRunGAgent -> ConversationReplyGenerator -> ChatRuntime
这条链路的局部行为已经有不少测试覆盖，但跨 actor handoff 的完成语义仍然不够清楚，尤其是：
- accepted
- committed
- delivered
- finalized
这几个阶段之间的边界目前更多是靠读代码理解，而不是由明确契约表达。
问题
现在最容易混淆的地方包括：
NeedsLlmReplyEvent 已提交，不等于用户已经收到回复- dispatcher accepted，不等于 downstream delivery 已完成
AgentRunGAgent terminal，不等于 channel 侧可见回复已经最终收尾reply ready / dropped / failed 分别处于哪个 completion phase 还不够显式
如果这几层语义不清楚，后续测试和实现都容易把弱保证误写成强保证。
目标
明确并落地 reply chain 的 completion semantics，让每一层只承诺已经真实发生的阶段。
范围
- 明确 accepted / committed / delivered / finalized 的边界
- 明确同步返回值与异步事件分别承诺什么
- 对齐
ConversationGAgent、dispatcher、AgentRunGAgent 的语义表达
- 去掉隐式、模糊、容易误读的完成态表达
验收标准
- 有简短设计说明 / ADR 补充 / 架构说明
ConversationGAgent、dispatcher、AgentRunGAgent 的完成态语义一致- code review 时不需要再靠“读代码猜语义”来判断某个状态的真实含义
- 结果足够明确，可以支撑后续 chain-level contract tests
背景
当前 lark reply 主链路为：
ConversationGAgent -> IChannelLlmReplyRunDispatcher -> AgentRunDispatcher -> AgentRunGAgent -> ConversationReplyGenerator -> ChatRuntime这条链路的局部行为已经有不少测试覆盖，但跨 actor handoff 的完成语义仍然不够清楚，尤其是：
这几个阶段之间的边界目前更多是靠读代码理解，而不是由明确契约表达。
问题
现在最容易混淆的地方包括：
NeedsLlmReplyEvent已提交，不等于用户已经收到回复AgentRunGAgentterminal，不等于 channel 侧可见回复已经最终收尾reply ready / dropped / failed分别处于哪个 completion phase 还不够显式如果这几层语义不清楚，后续测试和实现都容易把弱保证误写成强保证。
目标
明确并落地 reply chain 的 completion semantics，让每一层只承诺已经真实发生的阶段。
范围
ConversationGAgent、dispatcher、AgentRunGAgent的语义表达验收标准
ConversationGAgent、dispatcher、AgentRunGAgent的完成态语义一致