解读

面试官想验证两点：

1. 你是否能把提示链（Prompt Chain）的“链式依赖”抽象成有限状态机（FSM）；
2. 当链上任意节点出现幻觉、格式污染、工具调用失败等异常时，能否用状态回退而非简单重试，保证Agent 输出一致性与用户体验连续性。
   国内落地场景里，还要兼顾高并发低延迟与合规审计，因此回退必须可追踪、可灰度、可热更新。

知识点

• 有限状态机五元组：S 状态集、Σ 输入字母表、δ 转移函数、S₀ 初态、F 终态集
• 提示链节点异常分类：语义漂移、JSON 解析失败、工具返回空值、安全对齐拒绝
• 回退策略：单步回退、跳段回退、熔断回退
• 状态快照：上下文哈希 + LLM 温度种子 + 工具版本号
• 审计需求：回退事件必须写入 国密 SM4 加密日志，并带traceId供监管抽查

答案

我设计的机制叫 “三级快照 FSM 回退引擎”，核心思路是把整条提示链编译成一张确定性有限状态机，并在关键状态节点插入快照钩子。具体实现如下：

1. 状态机构建
   把每个提示模板映射为一个状态节点；节点内保存prompt_id、输入 schema、输出 schema、下游转移条件。转移条件用布尔表达式描述，例如“output.score > 0.8 ∧ output.format == ‘json’”。整张状态机以Protobuf序列化后存入etcd，支持热更新。

2. 快照点策略
   只在成本≥200 token或调用外部工具的节点后做快照，快照内容包含：

   • 上下文向量（最后 1k token 的向量均值，用于语义相似度比对）
   • LLM 生成结果原文
   • 工具返回的原始字节流
     快照以Redis Hash存储，TTL 设为24h，Key 规范为 snap:{traceId}:{stateId}。

3. 异常检测与回退
   异常触发器分为同步检测与异步检测：

   • 同步：在节点输出后200ms 内做JSON Schema 校验与正则黑名单过滤；失败即走单步回退。
   • 异步：把输出放入Kafka Topic，由对齐小模型在1s 内打分；若安全分 < 0.95 则发送回退指令到 Agent，走跳段回退。
     回退时引擎把快照上下文重新注入 LLM，并附加**“异常原因”system prompt**，让模型在零温度下重新生成，确保确定性。

4. 熔断与兜底
   同一 traceId 连续回退 ≥3 次即触发熔断，状态机直接跳转到终态 F_fail，返回**“服务繁忙，请稍后重试”，并记录errorCode=FSM_FALLBACK_503**，方便API 网关做降级映射。

5. 合规与可观测
   每次回退都写审计日志，字段包括：traceId、回退前状态、回退后状态、异常类型、快照 key、国密签名。日志通过Filebeat同步到省政务云 Kafka，留存180 天以备监管抽查。

该机制已在国有大行智能客服场景落地，异常率从 2.7% 降到 0.3%，平均回退耗时 380ms，P99 延迟增加 < 5%，满足等保 2.0 与银保监合规要求。

拓展思考

• 多 Agent 协同时，可把每个子 Agent 封装成复合状态，异常回退升级为跨 Agent 协商：通过Raft 日志同步快照，实现分布式一致性回退。
• 若提示链动态生成（如由 LLM 自己决定下一步工具），可引入分层 FSM：上层为元状态机负责“链的链”编排，下层为即时编译的微型 FSM，实现运行时回退边界自动划定。
• 在国产芯片（如华为昇腾）上，可把快照向量相似度计算卸载到CANN 算子，将回退耗时再降30%，满足政务内网****纯国产替代需求。