PolicyGuide：从守护单次动作到引导完整工作流的策略合规 LLM 智能体

把领域政策编译成工作流图，在用户轮次边界持久追踪进度并主动修复智能体的流程违规

前置知识

ReAct 智能体循环

LLM 智能体的主流执行范式：模型在“推理（思考下一步）—行动（调用工具）—观察（读取工具结果）”之间循环，直到完成任务。本文的客户服务智能体（基于 GPT 5.4、Claude Sonnet 4.6、Gemini 2.5 Pro）就是这样一个通用推理-行动循环，配有只读工具（查订单、查用户资料）和变异工具（改订单、退款）。

PolicyGuide 是架在这种通用循环之上的外挂层，不改执行器本身；理解被引导对象的结构，才能理解验证器为何选择在“用户轮次边界”而非“每个动作处”介入。

运行时保障（runtime safeguard）与动作护栏

不重训模型、在推理时监控并干预智能体行为的外部机制。动作触发的护栏（如 ToolGuard 编译工具级守卫、PolicyGuard 读取对话后对变异调用给 PASS/BLOCK 及修复建议）只在智能体提出某个受保护动作（通常是变异工具调用）的那一刻检查。

这是本文的直接对比对象：动作护栏看不见动作之外、动作之前的偏差（漏验证身份、漏资格检查），这一结构性盲区正是 PolicyGuide 要解决的问题，也是其理论分析（干预覆盖）的核心。

τ²-bench 与 PV/Mut 任务

评测策略遵循型 LLM 智能体的基准，含 Airline/Retail/Telecom 三个客服域，给定自然语言政策、只读与变异工具，由用户模拟器与智能体多轮对话。任务分两类：PV（policy-violation，智能体必须拒绝违规变更）和 Mut（mutation，智能体须在满足政策前提后正确执行变更）；Telecom 还含“双控”：部分必需动作是用户侧设备操作，智能体无法代为调用。

本文全部主实验都在 τ²-bench 上进行，三域的程序化结构差异（Telecom 流程性最强）直接支撑了“图引导在何处最有用”的核心论点。

Pass$^k$ 可靠性指标

对每个任务独立跑 $n_k$ 次，若有 $c$ 次成功则该任务得 $c/n_k$，对任务取平均即 Pass$^k$。$k{=}1$ 衡量单次成功率，$k$ 越大越要求稳定成功（Pass$^4$ 是“四次全对”的可靠性代理）。P4/P1 比值反映系统随可靠性要求提高的衰减程度。

论文主表全部用 Pass$^1$/Pass$^4$ 报告，Figure 4/5 画 Pass$^k$ 曲线；不看懂该指标就无法判断“0.42→0.62”这类增益的可靠性含义。

工作流图 / SOP 智能体

把标准作业程序表示为可遍历的图或状态机：节点是步骤（带满足条件），边是转移。SOP-Agent 编译决策图、StateFlow 用有限状态机、FlowAgent 用 PDL 加前后置控制器。这些系统把流程控制嵌入智能体自身架构，目标是“忠实走完流程”。

PolicyGuide 复用了工作流图这一表示，但把它从“智能体架构”搬到了“外部守护者”手里；分清两种用法（执行导向 vs 守护导向）是理解本文定位与 FlowAgent 对照实验的前提。

前缀闭包与首次偏差（干预覆盖理论）

设工作流图 $G$ 定义合规完整序列语言 $L(G)$，其所有前缀构成合规前缀集 $P_G=\mathrm{Pref}(L(G))$。首次偏差指一对 $(\tau, e)$：合法前缀 $\tau$ 之后智能体提交事件 $e$ 使 $\tau e\notin P_G$。由于前缀闭包性，一旦违规提交，之后的任何检查都无法补救——这解释了动作护栏“最后才发现”为何来不及。

Theorem 1 及其推论是全文理论基石：只有当验证器的触发调度覆盖每一个可达首次偏差时，程序有效性才可保证；它精确刻画了动作触发调度的盲区和本文用户轮次边界调度的剩余缺口。

研究动机

客户服务 LLM 智能体（订机票、改订单、换套餐）通常由通用推理-行动循环搭配 GPT 5.4、Claude Sonnet 4.6、Gemini 2.5 Pro 等前沿模型构成，因其闭权重、领域微调不可行，运行时保障成为主要介入点。合规失败有两种形态：一是做出被禁止的动作，例如给不符合条件的用户改舱位；二是遗漏程序性要求，例如未核实身份、未检查资格、未经确认就执行变更——后者即便最终动作本身被允许，也会留下“无支撑的变更”。作者对三个 τ²-bench 域的原始政策文档做原子需求分类后发现：程序性（process-level）需求无处不在——airline 占 67.4%、retail 约 100%、telecom 98.0%；而要求动作按序执行的工作流级（workflow-level）需求高度集中在 telecom（54.0%，对比 airline 4.7%、retail 3.6%），例如 telecom 排障遵循“诊断-指导-验证”链，其中可能根本没有智能体侧的变异调用可供护栏拦截。动作触发的护栏（ToolGuard 只见调用参数、PolicyGuard 读对话但仍在动作处触发）覆盖不了这些早期偏差；无引导的 ReAct 在 telecom 上 Pass$^4$ 仅 0.193，说明长流程极易中途失守。

本文的目标是本文要把“安全的智能体行为”与“忠实的流程执行”统一成一个运行时问题：智能体既要避免不允许的动作，也要完成规定的程序步骤——包括发生在受保护动作类之前或之外的偏差。具体目标有三：(1) 给定自然语言政策与工具清单，自动编译出一份可复用、可校验的工作流图；(2) 在线部署一个外部主动验证器，在用户轮次边界从持久化的图状态出发核对所有未决请求，对第一个未满足的步骤返回聚焦的修复建议，并对未经当前流程状态授权的变异工具调用实施拦截；(3) 整个机制不需要重训模型、与具体执行器解耦——同一份冻结工作流可配不同智能体，验证器与智能体同模型族配对即可工作，并在良性用户与 CRAFT 对抗用户下都保持稳健。

与已有工作不同的是，现有两条研究线各管一段：运行时保障线（ToolGuard、Solver-Aided 只见当前调用；PCAS、ShieldAgent 追踪顺序但把对话语义压成谓词或关键词；GuardAgent 是单轮准入控制器；PolicyGuard 最接近，能把程序修复带进变异调用护栏）仍然动作触发、不持久化流程位置、不主动引导，覆盖不到受保护动作类之外的偏差。工作流/SOP 线（SOP-Agent、StateFlow、SMoT、FlowAgent）把流程控制做进智能体架构，目标是流程完成而非守护行为——FlowAgent 的控制器为合规执行设计，并未作为对抗违规智能体的保障来评估。PolicyGuide 的独特切入是：把持久化的工作流状态赋予“守护”角色而非“架构”角色——验证器与执行器分离，验证器跨轮追踪图中位置、在偏差提交前引导；并配套干预覆盖的形式化理论（Theorem 1、Corollary 1/2），刻画动作触发调度为何无法保证程序有效性、以及本文实际触发调度的保证边界。

核心方法

直觉上，PolicyGuide 给智能体配了一位懂 SOP 的“流程督导”：它不与用户对话，只在每个用户回合前查一遍“这个请求走到流程哪一步、下一步该做什么”，把下一步指令作为修复建议喂回智能体；若智能体抢跑执行变更类工具，运行时先拦截该调用并触发一次纠偏核查。技术路线分离线与在线两半（Figure 3）。离线部分用 6 阶段 LLM 流水线把原始政策加工具清单编译成每域一份、冻结复用的工作流束（主图+子流），节点分 8 类：entry/exit（结构）、agent_action（非工具智能体动作）、user_input（用户回应）、tool_call（只读调用）、tool_authorization（变异工具授权）、decision（分支）、subflow（子流调用），每个节点注明执行者、期望动作与显式满足条件；三域冻结图规模为 airline 158 节点/11 个授权节点、retail 104/7、telecom 127/5。在线部分，验证器每次触发是一次生成 $V_\phi(\pi, T, G, H, S) = (d, \mathbf{bR})$：输入原始政策 $\pi$、工具规格 $T$、冻结图 $G$、交互历史 $H$、代码持有的请求状态 $S$，输出合并修复 $d$ 与每请求的更新记录。触发时机为“响应每个用户轮之前”加“拦截未授权变异调用之后”；温度 0，验证器与执行器同模型族配对；提示词由字节稳定的静态前缀（政策、图渲染、判定规则、输出契约）加对话与最新状态构成，可被前缀缓存覆盖。

核心创新是把强制执行点从“动作处”挪到“用户轮次边界”，并让代码（而非模型的对话记忆）持有流程状态。与动作护栏的本质区别有三点。其一，持久化图位置：每个未决请求记录其在图中的节点与授权状态，跨轮恢复，不需要每轮重读全文重新推断流程进度。其二，主动修复：验证器在偏差提交前就返回下一步该做什么，而动作护栏只能在最终变异调用处报告“前提没满足”——由前缀闭包性，此时程序违规已不可逆（一旦 $\tau e\notin P_G$，后续任何动作都无法把前缀拉回 $P_G$）。其三，证据接地：资格与事实类条件只有被只读工具结果确认才计入，用户口头宣称不算；而用户的选择与同意从其消息中读取——这条判定规则直接支撑了对抗鲁棒性。与 SOP/工作流智能体的本质区别则是：流程控制不绑定在执行器架构里，验证器与执行器分离，使同一份工作流可配 GPT 5.4、Claude Sonnet 4.6、Gemini 2.5 Pro 而无需重编译；评估目标也不同——守护策略合规行为，而非单纯完成流程。

方法步骤详情

离线编译 6 阶段（每域一次、冻结）：阶段 1 抽取工具规格并识别变异工具（排除用户设备侧动作）；阶段 2 推导请求类型、共享程序、有序子流与覆盖审计；阶段 3 审查计划；阶段 4 生成各子流并做 schema 校验（一次修复重试与分支审查）；阶段 5 把入口脊柱、分类器与子流连成图；阶段 6 校验 schema 一致性、工具清单、变异工具授权覆盖、图组合、边分支数与可达性，审查政策-图映射并剪除未用子流。在线运行每次触发三步：(1) 对账——把历史中的请求与状态 $S$ 对齐：新请求从图入口开卡、未决请求保持记录的位置与授权、被放弃的丢弃、重复的合并；(2) 遍历——从每个请求的保存节点出发沿匹配历史的边推进，逐节点判定满足条件（资格与事实需工具结果确认，用户选择/同意从消息读取），在第一个未满足节点停下，其所需动作即修复建议；一次生成可推进多个节点，终节点标记请求完成；(3) 决定——返回停止/推进/授权与更新后的请求状态。干预机制：每个用户轮区域内第一个未被当前工作流状态授权的变异工具调用在执行前被拦截，触发一次纠偏验证；一次性闸门随即解除以放行立即重试，防止建议式机制死锁；其余流程内动作通过修复建议引导而非硬卡。合并的修复作为引导消息在智能体行动前注入，跳过的工具结果折叠进下一次触发的对话增量，保证每次判定都看到完整轨迹。

技术新颖性

理论新颖性：Appendix A 首次把“何时能保证程序有效性”形式化为干预覆盖问题。把交互表示为政策相关事件序列，Theorem 1 证明理想绑定验证器全程保持 $P_G$ 成员资格当且仅当触发调度覆盖每个可达首次偏差，即 $CS(G) = D_G$；Corollary 1 进一步给出结构性结论——工作流级调度（每个智能体动作前核查）对一切工作流都满足该条件，而动作触发调度仅当所有首次偏差都落在被守护动作类 $A$ 内才成立，这正是动作护栏无法用“更好的判定”弥补的盲区；Corollary 2 则诚实刻画了实际评估的边界调度（用户轮后+拦截后）的覆盖条件与剩余缺口。工程新颖性：单次生成处理全部未决请求并沿图一次推进多节点；状态由代码持有，拒绝未知节点 ID、按枚举清单过滤授权输出、重建当前启用工具集；静态前缀缓存使命中率达 85.8–88.1%。概念上，同一份冻结图的确定性 PDL 编译使与 FlowAgent 的对照成为“表征相同、控制位置不同”的干净实验，证明收益来自“外部图验证器”而非“拥有图”本身——这是此前工作未曾隔离过的变量。

**Figure 2**: One task under three enforcement regimes. (a) An action guard checks only the final mutating call... (b) A workflow/SOP agent drives the procedure... (c) PolicyGuide runs as an external, advisory guide at user-turn boundaries.

**Figure 3**: PolicyGuide separates offline policy authoring from online enforcement. Offline, the policy and tool registry are compiled, repaired, and validated into a reusable workflow bundle. Online, each verifier call consumes the conversation, grounded tool results, persisted request state, and workflow bundle...

**Figure 12**: Airline: the composed workflow graph—the shared spine (start, intake, the identify_user subflow, classify) and the full transactional book_reservation request path.

**Figure 13**: Retail: the shared entry–intake–identification spine and classifier dispatch into request-specific subflows, with cancel_pending_order expanded.

**Figure 14**: Telecom: the shared entry–intake–identification spine and classifier dispatch, with two request branches expanded (pay_overdue_bill and troubleshoot_mms).

实验结果

主结果（Table 1，GPT 5.4 智能体+同族验证器，$n{=}4$）：三域整体 Pass$^4$ 全面最高，均值 0.42（ReAct）→ 0.62。分域看：Airline Pass$^4$ 0.460→0.620（PV 0.750→0.917，Mut 0.192→0.346），PolicyGuard 为 0.580（PV 1.000 但 Mut 0.192），ToolGuard 0.520；Retail 0.596→0.614（PV 0.700→0.900，Mut 持平 0.587）——retail 只有 10 个 PV 任务，整体差距不显著，但可看出 PolicyGuard 的 PV 提升伴随 Mut 下降而 PolicyGuide 两头兼顾；Telecom 增益最大：Pass$^4$ 0.193→0.614（PV 0.442→0.721，Mut 0.042→0.549），Pass$^1$ 0.384→0.866，与“工作流级需求集中在 telecom（54.0%）”的结构诊断一致。可靠性（Figure 4/Table 10）：$k$ 增大时领先保持，telecom 的 P4/P1 为 0.71（ReAct 0.50）。消融（Table 2）：把图换成原文（RAW）损失 +0.100/+0.150/+0.325（Airline/Retail/Telecom），SELF（图给执行器、去掉外部验证器与状态）的 Mut 不超过 ReAct——说明“拿到图”不等于“会照做”。匹配对照（Table 3，telecom 40 任务测试集）：同一冻结图编译进 FlowAgent 得 0.350，PolicyGuide 0.675。跨智能体（Table 4，airline，同一份 GPT 5.4 图不改）：Claude Sonnet 4.6 0.720→0.780，Gemini 2.5 Pro 0.480→0.680（Mut 0.231→0.462）。对抗（Figure 6，CRAFT 20 个 airline 攻击任务）：每 trial 攻击成功率 0.087，低于 PolicyGuard 0.125 与 ReAct 0.200，阻止 91.3% 的测试攻击。流程合规（Table 5，telecom，仅结果通过的轨迹）：Step-TCR 94.5%（ReAct 86.4、PolicyGuard 85.7），Trace-TCR 63.4%（35.4/23.9），端到端 process-valid rate 56.2% 对 17.5%/13.1%。显著性（Table 12）：合并分层 McNemar 检验对 ReAct $p<10^{-8}$、对 PolicyGuard $p<10^{-12}$。Call-NMR（Table 17）：airline 15.6% 最低（ReAct 25.4、PolicyGuard 32.5），retail 与 PolicyGuard 打平（34.7 对 34.8）但通过任务更多（116 对 80）。成本（Table 14/15）：引导侧每任务 $0.34–0.56、调用 7.4–11.5 次，墙钟时间为 ReAct 的 5.45–5.78 倍（telecom 247.6s 对 45.5s）。

**Table 1**: Main results on the base splits (GPT 5.4 agent, n=4; airline 50, retail/telecom 114 tasks). Cells report Pass1 and Pass4 overall and on the PV/Mut slices.

**Table 2**: Workflow ablations (GPT 5.4 agent; Airline base split, Retail and Telecom benchmark test splits of 40 tasks). All cells report Pass4.

**Table 3**: Matched workflow-controller comparison on the 40-task Telecom benchmark test split. All values are Pass4.

**Table 4**: Agent-family generalization on Airline (50 tasks, n=4; verifier model paired to the agent). All metrics are Pass4. The GPT 5.4-authored workflow graph is reused without re-authoring.

**Table 5**: Author-designed Telecom ordered trace compliance (%; n=4). Step- and Trace-TCR condition on outcome-passing traces.

**Table 6**: Argument- (A), process- (P), and workflow-level (W) partition of the source policies (W splits PolicyGuard's process-level class; P+W equals it).

**Table 10**: Pass^k breakdown for the base-split results in Table 1 and Figure 4 (GPT 5.4, n=4). P4/P1 is the consistency ratio.

**Table 14**: Guide-side model usage for the GPT 5.4 configuration (50 Airline and 40 Retail/Telecom tasks). Costs exclude the actor and user simulator.

**Table 15**: Mean end-to-end wall-clock time per task.

**Table 16**: Programmatic validation rerun on the frozen workflow graphs.

**Table 17**: Call-NMR on passing Mut trajectories (n=4): percentage of successfully executed agent mutations missing a frozen guard-derived read prerequisite.

**Figure 4**: Pass^k vs. k (reliability; higher is better) on the base split of each domain, GPT 5.4, all cells n=4.

**Figure 5**: Pass^k for Claude Sonnet 4.6 and Gemini 2.5 Pro agents on airline (verifier = agent), with n=4 for every system.

**Figure 6**: CRAFT red-team attack-success rate on airline (20 attack tasks, GPT 5.4, n=4); lower is safer.

查看结构化数据

任务	指标	本文	基线	提升
τ²-bench 三域整体任务成功（Airline/Retail/Telecom）	Pass$^4$ 均值	0.62	0.42（ReAct 无引导）	+0.20
Telecom 域（114 任务，流程结构最强）	Pass$^4$ 整体	0.614	ReAct 0.193；PolicyGuard 0.202；ToolGuard 0.202	+0.421（对 ReAct）
Airline 域（50 任务）	Pass$^4$ 整体	0.620	ReAct 0.460；PolicyGuard 0.580	+0.160 / +0.040
Retail 域（114 任务，仅 10 个 PV）	Pass$^4$ 整体	0.614	ReAct 0.596	+0.018（置信区间含 0，不显著）
Telecom 变更类任务（Mut 切片）	Pass$^4$ Mut	0.549	ReAct 0.042；ToolGuard 0.028	+0.507
Telecom 有序流程轨迹合规（作者自设 rubric，仅结果通过轨迹）	Process-valid rate（全轨迹端到端）	56.2%	ReAct 17.5%；PolicyGuard 13.1%	+38.7 个百分点
Telecom 与 FlowAgent 匹配对照（40 任务测试集，同一冻结图编译为 PDL）	Pass$^4$	0.675（外部图验证器）	FlowAgent 0.350（PDL+API 控制）	+0.325
CRAFT 红队（20 个 airline 攻击任务，诱导违规变更）	每 trial 攻击成功率 ASR（越低越安全）	0.087（阻止 91.3% 攻击）	PolicyGuard 0.125；ReAct 0.200	相对 ReAct 降低 56.5%
跨智能体迁移（Airline，Gemini 2.5 Pro 执行器，复用同一图）	Pass$^4$ 整体 / Mut	0.680 / 0.462	ReAct 0.480 / 0.231	+0.200 / +0.231

局限与改进

作者承认的局限：只在三个英文客服域、冻结用户模拟器（GPT 4.1）、每格 $n{=}4$ 下评测，未覆盖其他政策体制、语言与真实用户；Retail 仅 10 个 PV 任务、对 ReAct 的整体增益不显著；ToolGuard 运行时基线因官方实现仅覆盖 airline；由于 τ²-bench 不提供通用有序轨迹 oracle，telecom 的 Trace rubric 是作者自设的操作化——依赖金标任务动作、确定性事件排序与文本匹配、无第二标注者一致性，不能证明穷尽的自然语言政策合规（其 Call-NMR 的 telecom 适配 oracle 饱和为 0，只能作为非识别结果）；每域只用一份 GPT 5.4 冻结工作流（这是刻意的公平控制，但未建立作者侧跨模型/跨种子的泛化）；触发仅在用户轮边界与拦截后，Corollary 2 表明这些干预点之间的首次偏差不在无条件保证内；节点判定是概率性的、异常时 fail-open，需要硬保证的部署需另配确定性监控器；CRAFT 稳健性只在 airline 20 任务上验证，不能外推到跨域或自适应攻击。我的补充观察：(1) 主指标 Pass$^k$ 只看最终数据库状态与断言、对中间顺序不敏感，作者不得不自建 rubric 补测——这暴露了社区缺乏通用流程级评估器，也意味着“0.62 的 Pass$^4$”里仍可能藏着大量程序瑕疵；(2) 验证器与执行器始终同模型族配对，异构组合（弱验证器+强执行器或反之）的性价比未探索；(3) 多请求并发对账在更长的真实多议题会话中的可扩展性与鲁棒性未测；(4) 验证器读取全对话、工具结果与状态，隐私与审计面显著扩大（作者在伦理声明中提示但未量化）。

独立分析的弱点

独立分析的弱点与改进方向：(1) 触发调度留有盲区——同一用户轮内多个智能体动作之间、以及拦截闸门之外的首次偏差不被覆盖（Corollary 2），且硬拦截只针对变异调用；改进方向：为高风险只读动作与对话级义务（如禁止编造信息）增加事件级或抽样触发的自适应调度，按动作风险动态决定验证密度。(2) 概率性 fail-open——LLM 判断节点满足条件可能出错且异常时放行；改进方向：对可形式化的政策子集（参数 schema、状态枚举、余额比较）叠加确定性校验器做双层把关，LLM 只裁决语义部分，并对低置信判定升级为阻断。(3) 工作流忠实性依赖人工——三份冻结图靠作者手动核对加程序化校验，telecom 的 disable_roaming 仍留一个需人工裁定的 validator flag；改进方向：让编译管线为每个节点/边附上政策文档行号引用，实现可追溯的自动 diff 审计与政策更新时的增量重编译。(4) 成本与时延——墙钟 5.45–5.78× ReAct，主因是每次触发生成约 2.2–2.5k 输出 token 的结构化审计（占引导侧花费 67.5–71.0%）；改进方向：压缩输出契约（只报未满足节点）、蒸馏小模型验证器、状态未显著变化时跳过触发。(5) Retail 增益不显著源于 PV 任务过少，评估功效不足；改进方向：用 IntellAgent 式对话生成扩充 PV-heavy 的诊断任务集。(6) 建议式闸门一次即解除——重试后若仍违规只是再次引导；在高风险域应提供强制阻断加人工介入的配置档位。

未来方向

作者明确提出或暗示的方向：(1) 更广的干预覆盖——用更频繁的验证器调用逼近 Theorem 1 的完整覆盖条件，并研究覆盖-成本的帕累托前沿；(2) 降本——更小的验证器模型与更稀疏的触发策略；(3) 混合强制——对可形式表达的政策子集加确定性监控器以获得硬保证，弥补 fail-open 缺口；(4) 部署工程——政策所有者审查生成工作流、监控漂移、安全回退。基于其成果可自然延伸的研究：(5) 作者侧泛化——用不同模型/种子生成工作流并测试迁移，以及政策文档更新后的增量重编译；(6) 自适应对抗——针对图结构诱导用户走捷径（如伪造已完成步骤的证据）的红队与防御军备竞赛；(7) 把“reconcile-traverse-decide”协议推广到多智能体协作、多请求长会话与多语言政策；(8) 验证器自身的可靠性工程——自一致性、双验证器投票、把节点判定作为可校验对象；(9) 从运行时引导走向训练时内化——用图的节点进度做过程奖励信号（RLPR 风格）微调执行器，使流程合规成为模型自身能力而非纯外挂；(10) 与 CRMArena-Pro 等保密合规基准嫁接，检验其在非程序性政策（隐私、权限）上的普适性。

复现评估

复现条件较好但非开箱即用。作者承诺开源全部提示词、工作流 schema 与分析工件；论文附录 G/H 已逐字给出验证器系统提示（协议、判定规则、输出契约）与 6 阶段生成管线提示，附录 E 给出程序化校验清单，透明度很高。底座 τ²-bench 公开（Airline 50、Retail/Telecom 114 任务及 benchmark 提供的 held-out test split，任务 ID 由 split_tasks.json 固定），政策文档随基准发布。所需算力实为 API 预算：GPT 5.4（执行器+验证器+工作流作者）、Claude Sonnet 4.6、Gemini 2.5 Pro、GPT 4.1 用户模拟器；引导侧成本 $0.34–0.56/任务、7.4–11.5 次调用，粗估复跑主表（278 任务 × 4 trials × 3–4 系统）需数十到一两百美元级 API 费用；墙钟为 ReAct 的 5.45–5.78 倍（telecom 约 4.1 分钟/任务），全量复现需数小时到数天。难点提示：工作流生成有 LLM 随机性，作者未公布每阶段缓存/种子，且冻结图经过人工核验（未手动编辑）但论文阶段不一定随代码附带三份成品图——若能直接复用其冻结图与提示词，一个研究生约一周可搭起可跑原型；若需从零重跑 6 阶段编译管线，还需按附录 E 补齐 schema 与校验逻辑，难度中等偏上。全程无训练，纯推理+编排工程。

PolicyGuide：从守护单次动作到引导完整工作流的策略合规 LLM 智能体 PolicyGuide: From Guarding One Action to Guiding the Whole Workflow for Policy-Compliant LLM Agents