BLOGE
0.9.8-RC1在线版 · 事实校验 2026-09-15 · English
第四阶段回顾 —— 生命周期模型（第 14–17 章）
你现在已经可以走出“一次性 graph”的边界，用更清晰的方式建模长生命周期编排。
你学到了什么
第 14 章——多轮 Session 把原本只放在附录中的 session 内容提升到了主线阅读路径。你学会了如何用 SessionGraph、ONCE phase 和 ROUND phase 描述跨越多次外部信号的交互；持久化和重启恢复还需要 durable manager 与 store。
第 15 章 —— 状态机 引入了显式生命周期建模。你学会了如何用状态、事件迁移、守卫条件和超时规则，让状态推进过程保持可见，而不是藏在一堆分支和循环里。
第 16 章 —— 组合 Session 与状态机 展示了如何把两种运行时组合起来而不丢失信号所有权和生命周期边界。你学会了：嵌套组合是有价值的，但绝不是对称的，真正重要的是外层运行时拥有主要业务生命周期。
第 17 章——把非确定性 Agent 放进确定性生命周期 增加了受限工具调用循环。你学会了限制工具和轮数，并让显式 graph——而不是模型——拥有退出与失败策略。
你现在应该能做到
- 判断一段流程应该建模成 graph、
session、状态机，还是它们的有意识组合 - 把一段多轮交互拆成
ONCE/ROUNDphase，并为其设置明确的限制和超时策略 - 用事件迁移、自动迁移、守卫迁移和超时迁移建模显式生命周期
- 解释嵌套流程中究竟由哪个运行时拥有信号、恢复和身份
- 在嵌套输出路径里保留状态和 phase 的来源信息，而不是把它们压平
这个阶段的常见错误
| 错误 | 为什么会犯 | 如何纠正 |
|---|---|---|
把每个 await 都升级成 session | 感觉 session 是“更高级”的工具 | 只有真正多轮的交互才该用 session；只有一次挂起 / 恢复的流程依然适合普通 graph |
| 把状态机当成“高级版 branch 节点” | 表面上看也还是条件分流 | 先问自己：命名状态和回退迁移是不是业务模型的核心 |
忘了配 phase 级 max_rounds | session 总上限看起来像是已经够了 | 每个真实 ROUND phase 都要显式设置自己的轮次上限 |
| 在嵌套流程里忽视所有权 | 两套运行时似乎都能挂起 / 恢复 | 永远先选外层所有者，所有信号都先进入那个边界 |
| 误以为内嵌 session 与内嵌状态机是对称结构 | 表面语法看起来很相似 | 记住当前约束：状态机里的内嵌 session 必须同步完成 |
新增核心词汇
| 术语 | 含义 |
|---|---|
SessionGraph | 由一组命名 phase 构成的多轮交互定义 |
ROUND phase | 会按信号 payload 恢复，并可持续重复直到 until 命中的 phase |
SessionExecutor | 用于启动、发信号、恢复和终止 session 的运行时入口 |
StateMachineDef | 由命名状态和迁移构成的不可变生命周期定义 |
| 守卫迁移 | 只有当某个基于状态输出的谓词成立时才会触发的迁移 |
| 生命周期所有权 | 在嵌套编排中，由外层运行时拥有信号、恢复和业务身份的原则 |
| 受限智能体循环 | 明确工具、轮数上限、退出条件和 graph 所有失败行为的工具调用循环 |
试一试：说出生命周期 Owner
一个客服工单有 30 天生命周期，一段四轮客户对话，每轮里的 agent 最多调用两个工具。请画三个嵌套框，分别标出谁拥有工单状态、会话轮次和工具循环退出。如果两个框同时声称拥有同一个迁移，就重画边界，直到每个决策只有一个 owner。
下一步
第五阶段回顾 将把重心从生命周期模型转向技术信心：测试、可观测性、Spring 接线和规模化运行。先从第 18 章 —— 测试你的 Graph开始。