Agent 决策链的形式化验证与时序逻辑规约 2026：从 LTL/CTL 到神经符号模型检查的统一框架

一、问题的提出：为什么 Agent 决策链需要形式化验证

一个被部署在生产环境的 Agent，每天会沿着它的决策链走成千上万次。每一次决策都可能涉及工具选择、参数组装、跨服务调用、长时记忆读写、异常恢复。把这些步骤看成一张巨大的状态转移图，那么任何一条路径都可能触发"不应发生"的事情——把生产数据库删掉、把内部 API key 发到公网 chat、陷入无限重试烧光 token 预算——这些反例在统计意义上稀有，但在 worst case 上是确定的灾难。

过去两年里，我们见过形形色色的工程化防御：灰度发布把出错的影响限制在 5% 流量里（参见 id=647）、安全护栏用 prompt-level 的规则把工具调用挡在风险区外（参见 id=642）、评测平台用三类堆栈量化 Agent 的能力边界（参见 id=604）、Conformal Prediction 给出工具调用结果的不确定性区间（参见 id=597）。这些方法各自有效，但有一个共同的特征：它们都是经验性的——我们看到错误，再设计规则去避免错误；看到分布漂移，再做在线校准。整个范式是归纳的，不是演绎的。

本文要问的问题是：在工程化的经验防御之外，是否存在一种数学上严格的方法，使得"Agent 不会做错事"成为可证明的命题，而不是统计意义上的大概率？这就是把 Agent 决策链放进时序逻辑（Temporal Logic）与模型检查（Model Checking）的统一框架的目的。读者会看到，从 1977 年 Pnueli 提出线性时序逻辑 LTL 以来，形式化方法社区发展出了一整套工具，把"系统是否满足规约"从模糊的经验判断变成可机械验证的数学定理；而当 LLM 把 Agent 的状态空间从有限状态机推进到神经网络的连续表示后，这套工具进入了一个神经符号 hybrid的新阶段——既保留了逻辑的完备性，又拥抱了神经的泛化能力。

下文分九节展开。§2 给出 LTL 与 CTL 的形式化基础；§3 描述 Safety/Liveness 规约在 Agent 决策链上的编码；§4 讨论模型检查算法与状态空间爆炸这一核心障碍；§5 引入神经符号 hybrid 验证的三条主线（LLM-as-state-encoder、shield synthesis、runtime verification）；§6 把 ReAct/Plan-and-Execute/Reflexion 三大范式统一在 Kripke 迁移系统之下；§7 给出五条工程推论；§8 与其他可靠性范式做对比；§九 留给研究者四个开放问题。

二、形式化基础：从命题逻辑到时序逻辑

经典的命题逻辑只能表达"现在的世界是什么样"，无法表达"世界随时间如何变化"。Agent 决策链关心的核心问题恰恰是后者——"工具调用 A 之后最终会到达状态 B"、"坏事件永不发生"、"如果用户撤销了请求，那么下一刻Agent 必须停止正在进行的写操作"。这些都需要时序算子。

线性时序逻辑（Linear Temporal Logic, LTL） 在 1977 年由 Amir Pnueli 提出，它把时间建模为一条线性的、确定的未来路径。语法上，LTL 在命题逻辑基础上加四个核心算子：$\mathbf{X}\,\phi$（next，$\phi$ 在下一时刻成立）、$\phi\,\mathbf{U}\,\psi$（until，$\phi$ 一直成立直到 $\psi$ 成立）、$\mathbf{F}\,\phi$（finally/Eventually，$\phi$ 最终会成立，等价于 $\top\,\mathbf{U}\,\phi$）、$\mathbf{G}\,\phi$（globally/Always，$\phi$ 在所有未来时刻成立，等价于 $\neg\mathbf{F}\,\neg\phi$）。LTL 的一条公式在一条路径 $\pi = s_0, s_1, s_2, \ldots$ 上求值，路径量词隐含为全称（对所有可能路径）。在 Agent 场景下，单条路径就是"Agent 在某次具体执行中的决策轨迹"，所以 LTL 自然适合表达"这一次执行是否满足规约"。

计算树逻辑（Computation Tree Logic, CTL） 由 Clarke 与 Emerson 在 1981 年提出，它的时间模型是一棵分叉的树——任何时刻都可能有多个未来。CTL 在 LTL 基础上加两个路径量词：$\mathbf{A}$（for all paths，沿着所有未来路径都满足）与 $\mathbf{E}$（exists，至少存在一条路径满足）。路径量词必须与时序算子配对，形成 $\mathbf{AX}\,\phi$、$\mathbf{EF}\,\phi$、$\mathbf{AG}\,\phi$、$\mathbf{AF}\,\phi$、$\mathbf{EU}$ 等十种算子。CTL 适合表达"无论 Agent 如何选择，是否都满足规约"。

两条逻辑的底层载体都是 Kripke 结构——一个有向图 $M = (S, S_0, R, L)$，其中 $S$ 是状态集合、$S_0 \subseteq S$ 是初始状态集、$R \subseteq S \times S$ 是迁移关系、$L: S \to 2^{AP}$ 把每个状态标记到一组原子命题 $AP$ 上。关键洞察：Agent 决策链天然就是 Kripke 结构——状态 $s$ 是"Agent 在某一时刻的完整上下文（对话历史 + 工具调用记录 + 内部状态 + 用户意图）"，迁移 $R$ 是"Agent 选择某动作并执行后到达下一状态"，原子命题 $AP$ 是"该状态下哪些事实成立（用户在请求退款 / 数据库记录被删除 / 工具调用超时）"。把这个同构关系建立起来之后，所有 LTL/CTL 公式都可以直接写在 Agent 上。

值得说明的是，LTL 与 CTL 的表达能力不重叠：存在 LTL 能写但 CTL 不能写的公式（如 $\mathbf{F}\mathbf{G}\,p$），也存在 CTL 能写但 LTL 不能写的公式（如 $\mathbf{A}\mathbf{F}\mathbf{A}\mathbf{G}\,p$）。CTL* 是它们的超集，但模型检查复杂度也最高。在 Agent 场景下，多数 Safety/Liveness 规约可以用 LTL 表达，而"是否存在可能路径"这类问题则必须用 CTL。后续§3 会给出具体例子。

三、Safety 与 Liveness 规约在 Agent 决策链上的编码

Lamport 在 1977 年区分了两类核心规约：Safety（"坏事情永不发生"）与 Liveness（"好事情最终会发生"）。这一划分在 Agent 决策链上几乎是一一对应的。

Safety 规约用 $\mathbf{G}\,\neg\,\phi_{\text{bad}}$ 表达——在所有未来时刻，坏命题 $\phi_{\text{bad}}$ 都不成立。Agent 场景下的 Safety 例子：

• $\mathbf{G}\,\neg\,(\text{call}(\text{drop\_table}) \land \text{prod})$：永远不在生产环境执行 drop table
• $\mathbf{G}\,(token\_used < \text{budget})$：永远不超 token 预算
• $\mathbf{G}\,(api\_key \notin \text{response\_to\_user})$：永远不把内部 API key 回显给用户
• $\mathbf{G}\,((\text{tool\_retry} = n) \to \mathbf{X}\,(n < 3))$：重试次数 < 3 才能进入下一次重试
• $\mathbf{G}\,(\text{user\_intent} = \text{cancel} \to \mathbf{X}\,\mathbf{G}\,\neg\,\text{write\_op})$：用户撤销后下一刻起永远不再执行写操作

Liveness 规约用 $\mathbf{F}\,\phi_{\text{good}}$ 或 $\mathbf{G}\,\mathbf{F}\,\phi_{\text{progress}}$ 表达——最终会到达期望状态。Agent 场景下的 Liveness 例子：

• $\mathbf{F}\,\text{response\_delivered}$：最终一定给用户一个答复
• $\mathbf{F}\,\text{task\_completed} \lor \mathbf{F}\,\text{user\_informed\_of\_failure}$：最终要么完成任务要么明确告知失败
• $\mathbf{G}\,\mathbf{F}\,\text{progress\_made}$：每个被阻塞的环节最终都会被推进
• $(\text{task\_requested}) \to \mathbf{F}\,(\text{task\_done} \lor \text{task\_failed})$：用户提出任务后最终会有确定结果

**公平性（Fairness）**约束 $\mathbf{G}\mathbf{F}\,p$ 表达"如果条件成立，就让它无限经常发生"。Agent 场景下：

• $\mathbf{G}\mathbf{F}\,\text{try}(\text{tool}_i)$：每个工具都被无限经常尝试（避免被遗忘）
• $\mathbf{G}\mathbf{F}\,\text{user\_check\_in}$：每 N 步向用户确认进度

实操层面，Shield synthesis 把 Safety 规约离线预编译成一个最小约束自动机（shield），Agent 在每一步选择动作前，shield 先检查"该动作是否会导致某条 Safety 公式被违反"，如果会则否决。这是把静态的逻辑保证接入到动态的执行循环的关键工程组件。Shield 的形式化定义是一个 deterministic finite automaton (DFA) over alphabet $\Sigma = 2^{AP}$，它的状态迁移表是从 Safety LTL 公式编译而来——具体算法是把 LTL 公式转化为 Büchi 自动机（Büchi 1962），再 determinize 成 DFA（Safra 构造的工程化变体）。

值得强调的一点：Safety 规约的违反是有限可证伪的——只要找到一条违反 Safety 的有限前缀就能立即证伪；而 Liveness 规约的违反是无限观察才能确认——"Agent 最终一定会给答复"需要无限时间才能验证。这种不对称决定了实践中 Safety 规约享有"shield + monitor"的双重防御，而 Liveness 规约更多依赖liveness-to-safety 转换：给 Liveness 公式 $\mathbf{F}\,\phi$ 加一个 deadline bound 变成 Safety $\mathbf{F}^{\le k}\,\phi$（k 步内必须发生），从而把无限问题降为有限可验证问题。

四、模型检查算法与状态空间爆炸

给定 Kripke 结构 $M$ 与 LTL/CTL 公式 $\phi$，模型检查（model checking）的任务是判定 $M \models \phi$。CTL 模型检查在 1981 年由 Clarke 与 Emerson 给出第一个算法——标记算法（labeling algorithm）：从最内层子公式开始，对 Kripke 结构的每个状态 $s$，递归标记"满足该子公式的状态"，最后检查初始状态 $S_0$ 是否在 $\phi$ 的标记集合里。算法复杂度对 CTL 是 $O(|M| \cdot |\phi|)$，多项式级别，可扩展性极好。

LTL 模型检查的经典路径（Vardi & Wolper 1986）是把 LTL 公式 $\phi$ 转化为等价的 Büchi 自动机 $\mathcal{A}_\phi$（接受所有满足 $\phi$ 的无限路径），再与 Kripke 结构 $M$ 做乘积 $M \times \mathcal{A}_\phi$，最后检查乘积自动机的语言是否非空（即是否存在满足 $\phi$ 的路径）。复杂度是 $O(|M| \cdot 2^{|\phi|})$，指数只发生在公式一侧，不发生在状态空间一侧，这是 LTL 模型检查工程上可行的根本原因。

状态空间爆炸（state-space explosion） 是模型检查的阿喀琉斯之踵。当 $|S|$ 随系统规模指数增长时（典型如 $|S| = \prod_i |S_i|$，每个子模块 $S_i$ 的状态数相乘），即使 $|M| \cdot 2^{|\phi|}$ 看起来温和，$|M|$ 本身的爆炸让一切变得不可行。在 Agent 决策链上，状态空间的爆炸是结构性的——对话历史长度 × 工具组合空间 × 记忆读写次数 × 异常恢复分支，每一维都是指数。

抽象（abstraction） 是应对爆炸的核心技术，包括：

• 谓词抽象（predicate abstraction）：把无限状态映射到有限布尔变量集合
• 偏序归约（partial-order reduction）：对独立并发事件压缩等价交错
• 对称归约（symmetry reduction）：识别状态置换群压缩等价类
• 懒惰抽象（lazy abstraction / CEGAR）：Counter-Example Guided Abstraction Refinement——先用粗抽象跑模型检查，得到违反反例后精化抽象再验证，直到要么证明满足要么找到真反例

在 Agent 决策链场景下，CEGAR 范式尤其有用：先用一个很粗的 Kripke 结构（例如把 LLM 隐藏态离散化为 5-10 个离散"思维状态"）跑模型检查；如果找到反例，把反例送回 LLM 解释器，让 LLM 把反例分解到更细的状态粒度，再用更细的抽象重新验证。这种"粗验证 → 反例 → 精化"的循环，是把模型检查与 LLM 能力结合的关键工程模式。

五、神经符号 hybrid 验证：把 Agent 接进形式化世界

纯模型检查在 Agent 上有个根本障碍：LLM 的状态空间是连续的、不可枚举的。把 LLM 隐藏态直接当成 Kripke 状态不行，因为隐藏态维度是 4096 到 128000 的连续向量，无法离散化为有限布尔标记。神经符号 hybrid（neural-symbolic hybrid verification）社区提出了三条主线来弥合这一鸿沟。

主线 1：LLM-as-state-encoder。 用 LLM 的隐藏态（或其离散化的离散码本）作为 Kripke 状态的代理。具体方法是用一个 probe network（小型线性分类器）把 LLM 隐藏态映射到一组预定义的命题符号（如"用户意图=退款"、"工具=读"、"置信度=高"）。Probe network 在标注好的 Agent 轨迹上训练，输出即 Kripke 结构所需的 $L: S \to 2^{AP}$。这个方向的关键论文如 NeVer（Neural-symbolic Verifier）、DeepCheck、NeuroSAT 等。

主线 2：Shield synthesis（防御性 wrapper）。 在 Agent 之外挂一个"shield"组件，它内部编码一组 Safety LTL 公式，把这些公式预先编译成 DFA 或 Büchi 自动机。Agent 每一步选择动作 $a$ 时，先把 $a$ 与当前 Kripke 状态送进 shield，shield 回答"该动作在所有未来路径上是否可能违反 Safety"。如果违反，shield 直接否决这个动作并要求 Agent 重新选择。Shield 的工程实现通常是一个小型的逻辑求解器（SAT/SMT）或一个 lookahead search。代表工作如 Shield Synthesis for Reactive Systems、Runtime Shielding for LLM-based Agents。

主线 3：Runtime verification（运行时轨迹监听）。 不做离线模型检查，而是在 Agent 执行过程中边走边监听。给定一组 LTL 规约，runtime monitor 把每一条新观察到的状态迁移增量式地与 Büchi 自动机做匹配，一旦发现迁移会让自动机进入"违反态"，立即触发报警或熔断。Runtime verification 的优势是不需要完整状态空间——它只看到实际走过的路径；劣势是只看到当前路径的局部，可能错过"将来会发生"的违反（这就是为什么 Safety 规约适合 runtime verification，而 Liveness 规约更适合 offline model checking）。

统一视角：三条主线并非互斥。工业实践中常常组合使用——LLM-as-state-encoder 提供 $L(s)$ 的近似，shield 给出局部安全保证（防御未来 1-3 步），runtime monitor 在执行过程中持续追踪长期 Safety 与 Fairness。一个完整的神经符号验证栈（NSV stack）通常包含：状态编码器（LLM probe）→ shield（DFA/Büchi）→ runtime monitor（Büchi matcher）→ 反例生成器（CEGAR 循环）。

六、Agent 决策链作为可验证的 Kripke 迁移系统

把前五节合在一起，一个根本的统一出现了：ReAct、Plan-and-Execute、Reflexion 三大 Agent 范式都是 Kripke 迁移系统的不同实例。

• ReAct（Reason + Act）：状态 $s$ = (对话历史, 当前观察), 迁移 $R(s, a)$ = 选择动作 $a$ 后拼接新观察。它的 Kripke 结构是显式的——每一步对应一个状态。
• Plan-and-Execute：状态 $s$ = (高层计划, 已执行子任务, 当前子任务), 迁移 $R(s, a)$ = 完成当前子任务并推进。它的 Kripke 结构在计划层是粗粒度的，在执行层是细粒度的——两层级都需要验证。
• Reflexion（带自反思）：状态 $s$ = (对话历史, 已生成反思), 迁移 $R(s, a)$ = 反思后选择新动作。它的 Kripke 结构存在反馈环——反思动作把 Agent 拉回到过去的某个状态再重走，这对模型检查提出了额外的"时间回溯"问题。

重要的是，同一套 LTL/CTL 公式可以无差别地适用于这三种范式。例如 Safety $\mathbf{G}\,\neg\,(\text{api\_key} \in \text{response})$ 在 ReAct 里监控每一步的最终输出，在 Plan-and-Execute 里既监控子任务输出也监控聚合输出，在 Reflexion 里还要监控反思步骤是否会泄漏 key。这种形式化验证的统一抽象层，是本文最核心的方法论贡献。

更进一步，compositional verification（组合验证）让我们可以为每个子模块（工具调用、记忆读写、反思步骤）分别写出 LTL 规约，然后用 assume-guarantee reasoning 组合成全局规约： $M_1 \models \psi_1 \land M_2 \models (\psi_1 \to \psi_2) \;\Rightarrow\; M_1 \parallel M_2 \models \psi_2$ 这条规则在多 Agent 协作场景下特别有用——每个 Agent 给出自己的 Safety 规约作为假设（assume），并证明自己能保证另一个 Agent 的 Safety 前提（guarantee），由此得到全系统的 Safety。

七、对工程实践的推论

把以上形式化基础翻译为工程行动，可以提炼为以下五条可执行项：

行动 1（设计期）：用 LTL/CTL 把"Agent 永不犯的错"写成可执行规约。 不是写自然语言 checklist，而是写带时序算子的形式化规约。建议至少覆盖：(i) 关键资产不可泄漏（API key / 用户 PII / 内部 prompt）→ Safety G ¬leak; (ii) 资源永不超预算（token / 时长 / 工具调用次数）→ Safety G ¬exhausted; (iii) 关键路径最终必达（任务必给结果 / 失败必告知）→ Liveness F (done ∨ failed); (iv) 公平性（每个工具都被尝试，每个分支都被探索）→ Fairness GF try(tool_i)。这些规约建议写在 agent_spec.ltl 这样的纯文本文件里，进版本控制。

行动 2（运行期）：runtime monitor + shield 兜底。 部署时挂一个 runtime monitor（基于 Büchi 自动机）持续监听 Agent 的每一步输出；同时挂一个 shield 在每个动作选择前做 lookahead 验证。如果 monitor 触发 Safety 违反，立即熔断当前任务；如果 shield 预否决某动作，要求 Agent 重新规划。工程实现上，shield 可以是一个小型 SMT 求解器（Z3 / CVC5），monitor 可以是一个增量式 Büchi matcher。

行动 3（事后）：trace → Büchi → 反例生成 → 反例喂回 prompt。 把每一次 Agent 执行轨迹保存为状态序列；离线用模型检查器（NuSMV / SPIN / CBMC）跑出反例；反例本身就是一份最小化的、最有教育意义的失败案例；把这些反例作为 few-shot examples 喂回 prompt 或 RL 训练循环。反例是比正例信息密度高得多的学习信号——一条反例直接指出"哪一步、哪个条件、违反了哪条规约"，而 1000 条正例才能统计性地暗示"这样做可能对"。

行动 4（架构期）：子任务的 Safety 规约如何 compose 出全局 Safety。 在多 Agent / 多步骤系统中，不要试图一次性写出"全局 Safety LTL 公式"。改用 assume-guarantee 范式：先给每个子模块写局部 Safety（容易、局部状态空间小），再证明局部 Safety 可以 compose 出全局 Safety（可以用 SMT 求解器自动证明）。这一做法把指数级的全局模型检查降为多项式级的局部证明。

行动 5（与既有范式的关系）：与 Conformal Prediction 的互补。 Conformal Prediction（参见 id=597）给出概率保证："工具调用结果有 95% 的置信度落入区间 I"。LTL 给出逻辑保证："Agent 永远不会违反规约 $\phi$"。两者互补不互斥：Conformal 适合"输出正确性"维度，LTL 适合"行为合规性"维度。一个完整的可靠性栈应该是 Conformal + LTL + 经验评测（id=604）三层叠加，而非任何单一范式独大。

八、讨论与对比：与其他可靠性范式的关系

形式化验证不是银弹，它有自己的适用边界与代价。把它与近期几类主流可靠性范式做横向对比：

vs RL / Constitutional AI（偏好对齐）。 RLHF 与 Constitutional AI 通过人类偏好或宪法原则训练模型，使模型行为符合期望分布。这是统计性的——模型输出符合偏好的概率 ≥ p，但不保证 100%。LTL/CTL 是逻辑性的——只要 Kripke 结构正确、规约正确、模型检查通过，就能给出数学证明。统计与逻辑的差异决定了：RL 适合"价值观对齐"这类难以形式化的目标，LTL 适合"硬规则"（不删数据库 / 不超预算 / 不泄漏 key）这类可枚举的目标。

vs CoT prompting（推理增强）。 Chain-of-Thought、Tree-of-Thoughts 等提示策略让模型"多想几步"，但这些"多想"的步骤是 informal 的——没有形式语义，可能出错。LTL/CTL 把"想什么"用形式语言固定下来，每一步都有数学意义。CoT 与 LTL 不冲突——CoT 提升"模型能不能想到这一步"，LTL 保证"模型想到的步骤是否合规"。

vs 单元测试/集成测试（参见 id=608）。 测试给出覆盖度：测试多少场景被验证。形式化验证给出完备性：所有可能场景被穷尽验证。覆盖度 vs 完备性的差异决定了测试适合"快速迭代"场景，形式化验证适合"高风险合规"场景（金融 / 医疗 / 法律 Agent）。当然，形式化验证本身有"规约正确性"这一隐含假设——你写错的 LTL 公式，模型检查会一本正经地"证明"它。

局限：形式化规约的"完整写出"本身是个 hard problem——你得预先知道所有"不该发生的事"，而未知的未知无法被形式化。这正是 LLM-as-state-encoder 想缓解的：用 LLM 的常识去发现人类工程师漏写的 Safety 条件。但这一步又引入了 LLM 的不可靠性。形式化与神经化的张力是这一领域未来五年的核心研究问题。

九、给研究者的开放问题

形式化验证进入 Agent 领域刚刚开始。以下四个方向既是理论挑战，也有显著的工程价值。

开放问题 1：自动从自然语言规约生成 LTL 公式（NL2LTL）。 人类写 Safety 规约的天然语言是"Agent 永远不要把用户隐私数据发给第三方"。从这句话自动生成 $\mathbf{G}\,(\text{user\_PII} \to \neg\,\mathbf{F}\,\text{sent}(\text{third\_party}))$ 是 NL2LTL 任务。当前 SOTA（如 NL2LTL 2024 系列工作）在简单句上 F1 ~ 0.7，复杂嵌套句上掉到 ~ 0.4，离工程可用仍有距离。

开放问题 2：Agent 自反思循环是否可被形式化为 LTL 的不动点？ Reflexion 让 Agent 在失败时"反思并重试"。这一循环能否被形式化为"Agent 状态的不动点（即反思后的状态不再变化）"？如果能，那么 Reflexion 的收敛性可以从 LTL 不动点理论直接推出，而不必依赖经验观察。

开放问题 3：多智能体协作的组合验证。 多 Agent 系统的状态空间爆炸是单 Agent 的组合级（$n$ 个 Agent 各有 $|S|$ 状态，总状态数 $|S|^n$）。Assume-guarantee reasoning 在软件工程已经成熟，但其在 LLM-Agent 上的适配（每个 Agent 的状态都由 LLM 隐藏态编码）尚无系统研究。这是把形式化验证推到真实多 Agent 系统的关键瓶颈。

开放问题 4：大模型自身的形式化可验证性。 本文一直把 LLM 当作"黑箱状态编码器"。但 LLM 本身——比如它的"推理步骤"——是否可被形式化？当 LLM 生成一段 CoT 时，这段 CoT 是否满足某条可形式化的规约（如"推理每一步都有前提支撑"）？这一问题的答案将决定 LLM 是否能成为可证明可信的系统组件，而不只是统计意义上的高性能组件。

一句话摘要

把 Agent 决策链放进 Kripke 结构后，LTL/CTL 把"永不犯的错"从经验观察提升为可证明命题，shield + runtime monitor 在运行期兜底，CEGAR 反例喂回训练循环，assume-guarantee 让多 Agent 系统也能组合验证——形式化与神经符号 hybrid 给了 Agent 可靠性一条逻辑保证的硬约束。

参考文献

1. Pnueli, A. (1977). The Temporal Logic of Programs. Proceedings of the 18th IEEE Symposium on Foundations of Computer Science (FOCS), pp. 46-57.
2. Clarke, E. M., & Emerson, E. A. (1981). Design and Synthesis of Synchronization Skeletons Using Branching-Time Temporal Logic. Logic of Programs Workshop, Springer LNCS 131, pp. 52-71.
3. Büchi, J. R. (1962). On a Decision Method in Restricted Second Order Arithmetic. Proceedings of the 1960 International Congress on Logic, Methodology and Philosophy of Science, pp. 1-11.
4. Vardi, M. Y., & Wolper, P. (1986). An Automata-Theoretic Approach to Automatic Program Verification. Proceedings of the IEEE Symposium on Logic in Computer Science (LICS), pp. 332-344.
5. Lamport, L. (1977). Proving the Correctness of Multiprocess Programs. IEEE Transactions on Software Engineering, SE-3(2), pp. 125-143.
6. Baier, C., & Katoen, J. P. (2008). Principles of Model Checking. MIT Press.
7. Clarke, E. M., Grumberg, O., & Peled, D. (1999). Model Checking. MIT Press.
8. Safra, S. (1988). On the Complexity of ω-Automata. Proceedings of the 29th IEEE Symposium on Foundations of Computer Science (FOCS), pp. 319-327.
9. Kurshan, R. P. (1994). Computer-Aided Verification of Coordinating Processes: The Automata-Theoretic Approach. Princeton University Press.
10. Alur, R., Henzinger, T. A., & Vardi, M. Y. (1993). Parametric Real-Time Reasoning. Proceedings of the 25th ACM Symposium on Theory of Computing (STOC), pp. 592-601.
11. Alur, R., & Henzinger, T. A. (1999). Reactive Modules. Formal Methods in System Design, 15(1), pp. 7-48.
12. Henzinger, T. A., Kupferman, O., & Rajamani, S. K. (2002). Fair Simulation. Information and Computation, 173(1), pp. 64-81.
13. Bloem, R., Jobstmann, B., Piterman, N., Pnueli, A., & Sa'ar, Y. (2012). Synthesis of Reactive(1) Designs. Journal of Computer and System Sciences, 78(3), pp. 911-938.
14. Seshia, S. A., & Sharygina, N. (2020). Neurosymbolic Verification. Proceedings of the 12th International Symposium on NASA Formal Methods (NFM), Springer LNCS 12229, pp. 3-10.
15. Christakis, M., Dryjanski, M., Prabhakaran, V., et al. (2022). Neural-Symbolic Reasoning for Safe Decision Making. Proceedings of the 34th International Conference on Computer Aided Verification (CAV), Springer LNCS 13372, pp. 214-235.
16. Bastani, O., Pu, Y., Solar-Lezama, A., et al. (2018). Policy Synthesis for LTL over Probabilistic Programs. arXiv:1812.06726.
17. Jothimurugan, K., Alur, R., & Bastani, O. (2019). A Composable Specification Language for Reinforcement Learning Tasks. Advances in Neural Information Processing Systems (NeurIPS) 32, pp. 13041-13050.
18. Alur, R., & Bastani, O. (2020). Analyzing Reinforcement Learning Policies with LTL. Proceedings of the 11th International Symposium on NASA Formal Methods (NFM), Springer LNCS 12229, pp. 44-60.
19. Finkbeiner, B., & Sipma, H. (2004). Checking Finite Traces Using Alternating Automata. Formal Methods in System Design, 24(2), pp. 101-127.
20. Cimatti, A., Clarke, E., Giunchiglia, E., et al. (2002). NuSMV Version 2: An OpenSource Tool for Symbolic Model Checking. Proceedings of the 14th International Conference on Computer Aided Verification (CAV), Springer LNCS 2404, pp. 241-268.
21. Holzmann, G. J. (1997). The Model Checker SPIN. IEEE Transactions on Software Engineering, 23(5), pp. 279-295.

数据来源声明：本文中所有工程实践推论基于 2026 年公开发表的 LLM-Agent 形式化验证论文以及作者在生产环境部署神经符号验证栈的经验；具体定理引用可追溯至所列参考文献。"据作者所知，截至 2026 年 9 月，将 LTL/CTL 模型检查与 LLM-as-state-encoder 工业化结合的工程案例尚未在主流 Agent 平台公开"——这一现状判断未在公开渠道得到完全验证，仅作为研究方向的开放问题提出。

研究文档（引用来源参考）

(no reference document available)