灵活性 vs 确定性的永恒矛盾
大模型的魅力在于其模糊推理与强大的通识解决能力，但工业级系统的核心底线是确定性（Determinism）与可预测性。如果一个智能体在部署上线时偶尔会跳过代码测试步骤直接上线，那它就是不可用的。
状态机边界包络架构
在我们的架构中，大模型被限制为“状态内部的执行引擎”或“转移条件的判断函数”，而不能随意决定下一步的状态跳转：
- 状态机严格定义合法状态集：
[INIT, PLAN, CODE, TEST, REVIEW, DEPLOY, ROLLBACK]； - 每个状态定义明确的进入条件、超时策略与退出断言；
- 只有当
TEST状态的所有自动化检查通过后，状态机底层代码才会执行状态迁移，模型无权越级。
落地步骤：把自由循环改造成受控状态机
- 画转移表。从业务里真实存在的阶段出发列状态，再显式写出每个状态允许去向哪些后继状态，未写出的迁移一律非法；
- 收敛模型权限。模型只能出现在两类位置：状态内部产出内容（如 CODE 阶段写代码），或作为转移条件的建议者输出候选，最终由确定性代码校验并裁决；
- 给每个转移配断言。退出条件必须是机器可判定的（测试通过、构建成功、评审通过），不能是"模型认为完成"；
- 持久化状态与事件日志。每次迁移先落盘再执行副作用，进程崩溃后从上一个合法状态恢复，而不是从头重跑。
粒度取舍：状态机该画多细
| 粒度 | 适用场景 | 优点 | 代价 |
|---|---|---|---|
| 粗（5–8 个状态） | 常规研发流水线 | 实现快、易沟通 | 单状态内部仍有失控空间 |
| 中（阶段再分子状态） | 多工具协作的长任务 | 断言覆盖更细 | 转移表维护量上升 |
| 细（每步外部动作一状态） | 金融等高合规场景 | 几乎无自由发挥余地 | 灵活性明显下降 |
经验值：先从粗粒度起步，只有在某个状态里反复出事故时才向下拆分，避免一开始就建成难以演进的巨型状态图。
验证方法：回放与故障注入
两个可执行的验收动作。回放测试：同一输入集重复运行若干轮，比对状态轨迹序列，非法转移数必须为零；故障注入：分别让 TEST、REVIEW 阶段的检查失败，确认系统按转移表走向预期的回退或 ROLLBACK 状态，而不是卡死或跳过。配合 人在回路（Human-in-the-Loop）中断与恢复架构：让关键决策始终受控 处理需要人工裁决的分支，可靠性会更完整。
常见故障速查
| 现象 | 原因 | 处理 |
|---|---|---|
| 任务在两个状态之间来回抖动 | 转移条件互相矛盾 | 补全转移表并设最大循环次数 |
| 模型输出匹配不到任何后继状态 | 判定函数返回了枚举外的值 | 输出限定为合法枚举并加解析重试 |
| 超时后状态永久悬挂 | 未配置超时策略 | 每个状态设超时并指向显式失败态 |
| 恢复后副作用被重复执行 | 先执行后记录 | 迁移前先持久化意图日志 |
小结
这套架构是否落地成功，标准只有一条：任意一次线上运行的日志里，都能还原出一条完整、合法、可回放的状态轨迹，且没有一次"检查未通过却发生了迁移"的记录。如果模型仍偶尔绕过检查，问题不在提示词，而在转移裁决代码没有真正收回写状态的权力——先修权限，再谈优化生成质量。