Natural-Language Workflows Are Not Software Yet: Artifact-Driven Compilation for Reliable Agent Execution —— 精读

论文链接：https://arxiv.org/abs/2608.21341

发表时间：2026 年 8 月（arXiv:2608.21341v1，2026-08-21 提交）

发表机构：普渡大学（Purdue University），West Lafayette, USA

作者：Xiangzhe Xu、Hanxi Guo（共同一作）、Guangyu Shen、Siyuan Cheng、Xiangyu Zhang

领域：cs.SE / cs.AI（智能体工作流可靠性、技能编译）

一、论文背景

1.1 自然语言工作流：一个诱人的“软件式”接口

智能体（Agent）生态正在形成一个新层次：自然语言工作流。医生、分析师、运营专家这些领域专家，不需要学编程，就能通过技能文档、工作流提示、程序性指令模板等方式，把“这件事该怎么做”写成一份可复用的自然语言程序，交给智能体执行。在这个图景下，一份工作流就成了一个可移植的领域知识单元——可以分享、可以复用、可以被任何智能体执行。Claude 的 Agent Skills、OpenClaw 的 Skills、Oracle 的 Open Agent Spec，都是这一趋势的产物。

这个图景之所以诱人，是因为它承诺了软件的两个核心性质：其一，行为可预测，所以可以在相似环境间共享复用；其二，执行可靠，因为机器被期望严格遵循程序指令。你在 Windows 上编译通过的程序，拿到 Linux 上用 Wine 跑，行为也是确定的——这就是“软件”二字的分量。

1.2 为什么自然语言工作流还不是软件

论文标题直白地点破了问题：Natural-Language Workflows Are Not Software Yet。差距来自智能体执行方式的可变性——传统软件的运行环境（CPU、操作系统）会严格遵循指令，而智能体是概率性的解释器，未必忠实执行收到的自然语言工作流。论文把根源归结为两点：

第一，数据依赖是隐式的。 在文本工作流里，每个步骤都“继承”了此前上下文中的所有中间结果——这就像一个程序把所有中间结果都存成了全局变量，后面的任何操作都可以读任何一个，尽管依赖关系在操作边界上完全不可见。于是每一步执行时，智能体都必须自己推断“我该用哪个先前结果”。当上下文里充满噪声信息时，推断就会出错。

第二，忠实跟随指令的负担随控制流复杂度和上下文负载增长。 一条短的线性工作流，智能体跟起来不难；但一条充满分支、中间结果冗长的工作流，在上下文压力下很容易出现跳步、错误转移、信息在压缩中丢失。

论文用 χ-Bench 医疗基准中的患者转诊工作流举了一个精彩的例子。智能体拿到转诊 ID，要检索医疗数据，在“复杂照护”与“慢病照护”之间做决策。规则是：风险分高，或近期有急性医疗使用记录，则纳入复杂照护；否则若医生转诊请求慢病照护且病历确认慢病，则纳入慢病照护。两种典型失败模式：

  • 错误 A（选错依据）：上下文里同时有医生的慢病转诊请求、慢病病历证据、近期心衰恶化记录、中间风险评估。正确决策应基于“近期急性使用记录”（支持复杂照护），但智能体被医生的慢病请求吸引，错误地开了慢病照护。
  • 错误 B（误读控制流）：规则是“高风险或急性使用”，智能体读成了“高风险且急性使用”，于是心衰急性发作但风险分中等的患者被错误拒绝。

这就像口头传授的菜谱 versus 印在卡片上的标准作业程序（SOP）：口头菜谱“适量”“看情况”“之前处理好的那块”全靠厨师自己领会，换个人做就走了样；标准作业程序则把每一步用什么料、什么条件下进下一工序写得明明白白。自然语言工作流目前就是那份口头菜谱。

二、论文定位和关联工作

要理解 ARTIC 的独特位置，需要把它放进四条相关工作线的坐标系里。

规格语言与工作流引擎。 软件工程界早就研究过让预期行为精确化的规格语言（Alloy、Event-B、Workflow Patterns、YAWL 等），工业界也有 Airflow 这类确定性编排引擎。但它们的前提是：人来完成流程分解、选择抽象边界、编码控制与数据依赖。ARTIC 面对的是相反的起点——领域专家手里只有自然语言，难点在于把自然语言自动翻译成可强制的表示。

智能体编排框架。 LangGraph、MASFactory 这类框架让开发者用图结构编排智能体，但组件语义相对固定，且 MASFactory 这类系统在复杂基准上常常根本产不出可执行工作流（论文实验中平均 0%）。

自动技能生成与提示优化。 Voyager、DSPy、自动提示工程这类方法从任务反馈中搜索更好的提示或策略。论文指出它们与本文目标正交：那套方法适用于结果驱动、可以自由改写提示的场景；而领域工作流是专家对程序本身的要求约束，编译器不能为了跑分随便改动流程——问题不只是“跑得更好”，而是“保真且可强制执行”。

技能编译谱系。 并行工作如 SkillSmith、SKCC 研究技能检索与跨 harness 适配——决定“用哪个技能”、把技能改写成另一环境的等价形式。ARTIC 回答的是另一个问题：技能选定之后，运行时如何度量并强制智能体忠实跟随它。

NL 到工作流的生成。 Chat2Workflow、AutoFlow 等系统能从自然语言构造工作流，但要么依赖人工引导修正，要么把工作流当搜索空间自由改写。ARTIC 的差异化在于：首次把“编译”的完整概念用于 NL 工作流的可靠性变换——不仅有变换（约束优化），还有编译器正确性的对应物（忠实性验证），正如传统编译器要对形式语义证明正确性（论文引用了 Leroy 的 CompCert 形式化验证工作作为对照）。

三、问题定义

论文把问题提炼为一个漂亮的抽象：自然语言工作流约等于一段含糊的伪代码——语义上人能看懂，但全部执行负担都转移给了解释器。

具体来说，执行负担有两类：

  1. 推断数据流的负担：每一步该消费哪些先前结果，文本里没写，执行器每次执行都要现场推断；
  2. 维持控制状态的负担：分支嵌套多、需要跨越长上下文记住的条件多，执行器在上下文压力下容易丢失或误读。

于是抽象问题变成：如何把隐式承载在自然语言语义中的执行负担，转换为显式的、机器可检查的契约——让“该读什么、该写什么、什么条件走哪条路”在执行前就固定下来，而不是每次执行都重新推断。

论文的关键洞察是：要先定义一个能把执行负担暴露出来的执行模型。负担看不见就无从分析，无从分析就无从精化。这直接决定了 ARTIC 的中间表示设计。

四、问题解法

4.1 工件驱动的中间表示

ARTIC（ARTIfact-driven workflow Compiler）的核心是把工作流重构为对工件的一系列变换。它定义了一个小巧的核心语言：

S ::= agent(ω)              智能体步骤：子智能体执行自然语言指令 ω
    | S1; S2                顺序组合
    | if p then S1 else S2  显式分支
    | while p do S          循环

每个步骤声明它读取和写入的工件（artifact，即命名的中间结果），产出工件受语义约束门控，步骤之间由显式控制转移条件路由执行。语义上，工件状态是一个从工件标识到“数据 × 约束集”的映射 Σ，整个工作流用大步操作语义 ⟨S, Σ⟩ ⇓ Σ′ 定义。

注意这个设计是半结构化的：步骤内部的局部动作仍可以是自然语言指令，由子智能体灵活执行；但数据依赖和控制转移是显式、可检查的。这保留了智能体的灵活性，又给工作流装上了具体的状态和执行闸门。

回到患者转诊的例子：编译后，“复杂照护决策”步骤只接收“医疗使用记录”和“风险分”两个工件，根本看不到医生的转诊消息（那属于慢病决策）；原本一个混合了风险计算、复杂照护判定、慢病照护判定的大步骤，被拆成三个简单变换。选错依据和误读“或/且”两类错误，从结构上被堵死了。

4.2 负担识别与约束优化

显式表示的最大红利是执行负担变成了可计算的信号。编译器把自然语言提示规范化为最细粒度工作流 fg(ω)，再用程序分析估计四项负担：

  • 控制流复杂度：对潜在工作流计算圈复杂度；
  • 上下文压力：一次智能体调用到检查点边界前要携带的上下文长度估计（分支取最大路径，循环按迭代次数缩放）；
  • 压缩压力：用活跃变量分析，度量必须穿越上下文压缩点存活的工件总量——存活的越多，压缩后丢失的风险越大；
  • 工件成本：物化中间结果的额外开销，防止优化无脑拆分。

编译过程被表述为约束优化：LLM 提出并迭代精化工件驱动工作流，程序分析对候选工作流做轻量检查，报告控制流过复杂、存活工件过多等次优区域，反馈给 LLM 继续 refine。这与“LLM 自由发挥”或“人工反复审阅”的现有路线形成鲜明对比。

4.3 忠实性验证：编译器也要证明自己没翻错

优化目标只管“好不好执行”，不管“翻得对不对”——而变换本身依赖 LLM 推理，不能默认可信。传统编译器可以对形式语义证明正确性，但自然语言的语义依赖领域语境和常识解释，没法直接套用。ARTIC 利用了一个不对称性：生成一个与源一致的工作流很难，但检查一个更小的、具体的源一致性命题更容易。

验证分三道：

  1. 静态规范性检查：语法、良构性、每个工件读取都已声明可用；关键的类型检查是汇合点路径稳定性——如果一个程序点可从多个前驱到达，每条路径必须为该点读取的工件提供兼容类型。这个检查能把自然语言里“分支内才产出、后面步骤却默认可用”的隐性缺陷暴露出来。
  2. 归纳式验证：把全局忠实性命题按编译后程序的结构分解为局部义务，逐个检查。比如源一步被编译为两步时，验证器先检查中间工件是不是源工作流的有效概念边界，再分别验证前缀与后继。附录中给出了观测精化（observational refinement）Wc ⪯obs Wn 的形式化表述与序列、分支、循环三条归纳规则的证明梗概。
  3. 场景式干跑：从验证目标提取逻辑公式与原子谓词，按谓词覆盖枚举具体测试场景（例如改变一个谓词真值应改变预期路由），让 LLM 验证器对源工作流和编译工作流各自独立地模拟执行，比较轨迹与结果检测不一致。两者不一致时，诊断信息回传给优化阶段。

4.4 编译器与执行器配置

编译出的可执行包分三部分：编排器（确定性 Python 脚本，按步骤输出转移控制）、步骤模块（exec_step 把声明输入变换为声明输出，check_artifact 在继续前校验产出工件）、运行时（工件 I/O、版本管理、子智能体调用、失败重试协议）。工件带版本管理：重试或循环产生的替换不会覆盖旧值，诊断能指向确切失败工件，执行可从最新有效工件恢复。原型实现约 5900 行 Python。评估用三个编译器模型（GLM-5、GPT-5.4、Sonnet-4.6）与六个执行器模型（从 3B 活跃参数的 GLM-4.7-Flash 到 744B 总参数的 GLM-5），全部跑在统一的 Codex harness 上，通过 MCP 工具与基准环境交互。

五、评估指标与实验证据

基准：11 个真实领域工作流，取自 SOP-Bench（工业 SOP）与 χ-Bench（医疗，取其照护管理接收与项目资格阶段，记为 Medical 域），共 488 个问题实例（每域最多抽 50 个）。主指标是任务解决率——只有按规程执行且做出正确领域决策才算解决。

主结果（RQ1）：三个执行器上，ARTIC 均取得最佳平均解决率——GLM-4.7-Flash 上 85%、GPT-OSS-120B 上 82%、Qwen3-235B 上 85%，比直接执行文本（Text）平均高出 28 个百分点（62/46/60 对 85/82/85）。与文本空间重写（SkillCreator：66/46/76）和直接生成 Python 代码（Code：73/73/72）相比也全面领先。与专门的 NL 转工作流系统对比，MASFactory 平均 0%（多数域直接报错产不出工作流），Chat2Workflow 平均 32%，ARTIC 为 85%。

可靠性（RQ2）：这是本文最有说服力的部分。Medical 域上跨六个执行器模型，文本工作流从最差 28% 到最好 60% 剧烈波动，编译版只在 72%–88% 之间。逐实例跨模型一致性：编译版 80% 实例在六个模型上全部同对或同错，文本版只有 48%（+32 个百分点）。重复执行一致性（pass^k，k 次重复全部正确的概率）：k=10 时编译版约 72%，文本版仅 16%；从 k=1 到 k=10，编译版降 16 个百分点，文本版降 35 个（+56 个百分点的差距）。扰动鲁棒性：在模型请求瞬时故障与强制上下文压缩（10K/20K tokens）下，原本双方都做对的样本上，编译版保持 100% 表现，文本版最强扰动下掉到 80%。

消融（RQ4）：Medical 域、GLM-4.7-Flash 执行下，优化+验证+干跑全开为 88%；去掉干跑反馈降至 80%；再去掉验证降至 72%；只保留优化为 48%；三件全无则 0%。优化组件贡献最大（因为它负责识别并拆分高负担步骤），验证与干跑兜住变换残留的错误。

编译器模型对比：GLM-5、GPT-5.4、Sonnet-4.6 编译的工作流在同一执行器上分别取得 80.0%、76.0%、84.0%，均远超同设置下文本版的 48%——编译质量对编译器选型不敏感，而成本差异巨大（$2.02 对 $38.19 对 $13.27）。

token 压力：编译工作流把高负担步骤拆给小子智能体后，平均每智能体输入 token 减少 63%、输出 token 减少 50%。编译成本（RQ3）：GLM-5 首次产包编译时间中位数低于 5 分钟，平均成本低于 $3——一次性离线成本，摊在每个工作流的多次执行上几乎可以忽略。

六、效果优势的根源解释

为什么仅仅是“换一种表示”就能带来如此大的提升？论文的证据链支持一条清晰的因果解释：

文本形态让每次执行都重新推断数据流 → 推断错误随步骤数与上下文压力累积 → 编译把推断一次性完成并固化为契约 → 执行器只需履约 → 一致性跃升。

三个证据相互印证。其一，一致性增益远超解决率增益（+32/+56 对 +28）：如果提升来自模型能力增强，换模型时收益应该衰减；但 +32 的跨模型一致性说明，换成任何执行器，同样的显式契约都能被兑现——提升来自表示形态本身，而非喂给模型的额外智能。其二，扰动实验：上下文压缩正是摧毁隐式数据流的杀手（存活的中间结果被摘要掉），而编译版在 10K/20K 压缩下表现纹丝不动，因为它要跨压缩点保留的状态已被显式声明并结构化存储。其三，token 压力分析：文本执行的单智能体 input token 显著高于编译版的子智能体，印证了“负担过载”机制——文本执行器被迫携带全部历史做每次推断，而编译版每步只见声明的工件。

用一个类比总结：自然语言工作流像口头传授的菜谱，每次做菜厨师都要现场回忆“上次说的那步是先放哪味料”；ARTIC 编译后像印在卡片上的 SOP，第几步用什么料、什么条件进哪条支线白纸黑字。菜谱没变，厨师也没换，但走样的概率彻底变了。消融数据补全了这个故事的另一半：没有优化（不拆分高负担步骤），契约虽显式但单步仍然过载，只剩 48%；没有验证与干跑，编译器自己翻错也无人发现，各掉 8 与 16 个百分点。表示决定下限，验证守住上限。

七、必要知识反推

若要在这一方向做出类似工作，需要储备三层知识：

领域层：工作流系统与程序语义——工作流模式（Workflow Patterns）、SOP 的领域实践、操作语义（大步语义、工件状态迁移）与观测等价/精化的基本概念；同时要理解智能体 harness 生态（MCP 工具接口、Codex 类执行环境）。

方法论层：编译器设计的经典手段——中间表示设计、活跃变量分析、圈复杂度、类型检查（尤其是路径敏感的汇合点检查）；约束优化思路（LLM 提案 + 程序分析反馈的迭代精化）；等价性验证思想（验证比生成容易的不对称性、归纳分解、谓词覆盖测试）。

工程层：LLM 辅助变换的工程实践——如何让 LLM 在结构化约束下生成可校验的产物、干跑模拟测试、多执行器适配、工件版本管理与重试协议等运行时契约设计。

八、通用性灵感

即使不做智能体工作流研究，本文也有三条可迁移的方法论：

  1. 表示决定可靠性。同样的语义，用显式契约化的表示承载，比自然语言表示抗扰动得多。这一原则适用于任何“人写说明、机器执行”的场景：提示词工程、运维 runbook、数据处理 pipeline 的文档化——凡是要反复执行、跨环境执行的东西，都值得考虑一次性的“编译”投入，换取每次执行的确定性。

  2. 验证负担分解。全局忠实性检查不可靠时，按目标结构把验证目标分解为局部义务，是 LLM 参与的变换类任务（代码迁移、DSL 翻译、提示改写）的通用验证范式。“生成难、验证易”的不对称性是可以系统性利用的资源。

  3. 干跑测试。为编译类变换构造场景化试运行——枚举谓词覆盖的具体用例，让源与目标各自独立模拟再比对轨迹——能在运行前捕获语义走样。这本质上是传统编译器的差分测试（differential testing）在自然语言世界的重生，值得成为任何 NL 转换管线的标配环节。

附录：快速数据卡

项目数据
基准11 个领域（SOP-Bench + χ-Bench Medical），488 实例
主结果解决率平均 +28pp（62/46/60 → 85/82/85，三执行器）
跨模型一致性48% → 80%（+32pp，Medical 域六执行器）
重复执行pass^10 约 72% 对 16%（+56pp）
扰动鲁棒性编译版 100% 保持，文本版降至 80%
消融88% → 80%（去干跑）→ 72%（去验证）→ 48%（只优化）→ 0%（全无）
编译器对比GLM-5 80.0%（$2.02）/ GPT-5.4 76.0%（$38.19）/ Sonnet-4.6 84.0%（$13.27）
token 压力平均每智能体输入 -63%、输出 -50%
编译成本中位 <5 分钟，平均 <$3（GLM-5）