智能体进化：超越提示词的自主决策架构设计

今天我们要探讨的论文《AgentSPEX: An Agent Specification and Execution Language》，直指一个日益凸显的痛点：当智能体（Agent）需要处理的任务复杂度不断攀升时，我们还能继续将所有执行逻辑都塞进提示词里，依赖大模型“即兴发挥”吗？

过去，许多智能体的开发方式相当直接。开发者编写一段系统提示词，定义模型的角色、任务目标、可用工具及基本处理原则，然后就让模型在对话历史中自主推进。对于简单场景，这种方式确实便捷高效——模型可以边思考、边调用工具、边调整策略。

然而，一旦任务链条变长、逻辑变复杂，问题便接踵而至。

设想一个智能体需要完成的任务流程：先理解用户需求，再进行信息检索，接着阅读网页内容、整理中间结果，然后调用代码执行环境，最后生成分析报告。在这个过程中，究竟哪一步该使用哪个工具？哪一步的上下文需要保留？哪一步的历史信息可以安全丢弃？某一步执行失败后能否自动重试？这些关键的控制逻辑，往往都隐藏在模型自身的“黑箱”决策中。开发者看到的可能是一个流畅的对话过程，但真正的流程控制却模糊不清，难以调试和优化。

AgentSPEX 旨在解决的，正是这个“流程黑箱”问题。它提出了一种面向智能体的规格说明与执行语言，允许开发者使用结构化的 YAML 文件来明确定义任务流程。模型依然负责其擅长的语义理解和内容生成工作，但整个任务如何拆分、步骤间如何流转、变量如何传递、子任务如何调用、执行过程如何记录——这些核心的控制逻辑，则交由系统来统一管理和执行。

这篇论文真正具有启发性的地方，不在于它采用了 YAML 格式，而在于它推动了一种开发范式的转变：复杂的智能体不能永远依赖一段提示词来即兴发挥，它需要一份可以被清晰定义、系统化执行、方便调试、灵活复用乃至完整回放的“流程说明书”。

为何仅依赖提示词构建智能体愈发困难

当前许多智能体系统都近似遵循 ReAct（推理-行动）范式：模型先进行推理，再决定是否调用工具，根据返回结果继续推理，并决定下一步行动。这种模式的优势在于灵活性高，但劣势也恰恰源于过于灵活。

当任务仅包含两三个步骤时，让模型自行决定下一步行动并无大碍。可一旦任务扩展到十几个甚至几十个步骤，整个执行过程就会演变成一个难以捉摸的“隐式状态机”。状态信息散落在冗长的对话历史里，控制流完全取决于模型的每一次生成，中间变量则混杂在一段段自然语言描述中。开发者很难精确判断：智能体此刻到底处于哪个执行阶段？

这带来了巨大的工程不确定性和维护挑战。

例如，对于同一个任务，今天模型可能选择先搜索网页，明天却可能先撰写大纲。在某次执行中，模型将搜索结果总结成关键变量传递给后续步骤；另一次执行中，它可能直接把整页原始内容塞进后续的上下文里。某一步骤出错后，模型有时能自动尝试修复，有时却会沿着错误方向越走越远。开发者想要调试某个具体步骤，往往不得不从头开始运行整个任务，效率极其低下。

这并非模型自身能力不足的问题，而是开发方式本身存在局限。将复杂流程写入提示词，看似是在定义流程，实则只是给模型提供一段“行动建议”。模型是否真正理解、是否严格遵守、能否在长上下文交互中保持一致行为，都缺乏强有力的约束。AgentSPEX 的核心洞见正在于此：复杂智能体的工作流程，不应该只写给模型“阅读”，更应该写给系统去“严格执行”。

AgentSPEX 的解决方案：将智能体流程编写为规格文件

AgentSPEX 的基本形态是一份 YAML 文件。开发者可以在其中定义智能体的名称、目标、模型配置、可用工具、输入参数，以及最核心的部分——工作流步骤。这个 workflow 部分，正是任务执行过程的蓝图。

在工作流定义中，开发者可以明确指定普通任务步骤、持续对话步骤，还可以设置条件判断、循环逻辑、并行执行以及子模块调用。变量如何设置、用户输入如何接收、最终结果如何返回，都能在这里得到清晰的定义。

它看起来有点像传统的工作流引擎，也类似于低代码平台中的流程编排工具，但其服务对象是智能体。关键在于，普通工作流主要处理确定性逻辑，而 AgentSPEX 的每个步骤内部，仍然可以调用大语言模型，让其完成理解、生成、总结、规划等开放性认知任务。

这就形成了一种巧妙的混合架构：外层由系统负责确定性的流程控制与状态管理，内层则由模型处理需要开放推理和创造性发挥的部分。

这种职责分工至关重要。因为构建智能体的真正难点，不在于所有事情都能被提前预设，也不在于所有事情都应该交给模型自由发挥。更合理的路径是：把确定的流程边界和顺序控制交给系统，把需要自然语言理解和创造性推理的部分留给模型。

以生成一篇论文研究报告为例。系统可以明确规定流程：先提取论文基本信息，再生成检索问题，接着调用搜索总结模块，最后合成分析文章。至于每个步骤内部如何概括要点、如何判断研究价值、如何组织语言表述，完全可以交给模型自由发挥。但步骤之间的执行顺序、变量的传递方式、模块的调用关系，不再依赖模型的临场决策，而是由系统保证。

这正是 AgentSPEX 与普通提示词方案的根本区别。前者是告诉系统“请按此流程调度模型执行”，后者仅仅是告诉模型“建议你按这个流程做”。

Task 与 Step：显式化的上下文管理能力

AgentSPEX 中一个关键设计，是区分了 task（任务）和 step（步骤）。

task 更像一个独立的任务单元。它会开启一个相对全新的上下文，将输入变量交给模型处理，然后将输出结果传递给后续流程。step 则更像连续对话中的步骤，它会保留之前的对话历史，适合那些需要多轮交互和连续工具调用的场景。

这个区分看似只是语法细节，实则切中了智能体开发中的一个常见痛点。

许多智能体表现不稳定，问题往往不出在模型能力上，而是上下文管理过于混乱。一个长任务运行下来，前面读过的网页内容、工具返回的结果、中间生成的草稿、失败的尝试记录、用户中途补充的信息……全都被塞进同一个不断增长的上下文里。模型在后续每一步中，都不得不从这一大堆历史信息中重新判断哪些信息重要、哪些可以忽略。

AgentSPEX 让开发者能够显式地控制上下文边界。某一步如果只需要前一步的摘要，就只传递摘要；某一步如果需要连续的工具调用和对话，就保留完整的对话历史；某个子任务完成后，只将结构化的结果返回给主流程，而不是把整个冗长的执行过程都带到后面。

这对工程稳定性至关重要。在开发智能体时，我们常提及“上下文管理”，但在很多现有系统中，这仅仅意味着不断裁剪历史消息长度，或者依赖模型自行总结。AgentSPEX 更进一步，将上下文管理嵌入到工作流结构本身，让每个步骤“能看到什么信息”、“应该输出什么结构”，都成为可设计、可控制的对象。

Workflow 调用 Workflow：智能体能力的模块化

AgentSPEX 另一个重要的设计，是允许一个 workflow 调用另一个 workflow。

这意味着复杂的智能体可以被拆解为多个可复用、可组合的模块。例如，一个论文分析智能体可以包含文献信息提取模块、联网搜索模块、内容摘要生成模块、报告写作模块。每个模块都有明确的输入和输出接口，也可以被其他智能体或工作流调用。

这一点对于智能体平台的设计尤为关键。

如今很多平台会同时涉及工具、技能、工作流、子智能体、多智能体协作等概念，但这些概念之间的边界常常模糊不清。一个“读取网页并总结”的能力，既可以被包装成一个工具，也可以被称为一项技能，还可以被当作一个子智能体。概念越多，平台往往越复杂，用户也越难理解和使用。

AgentSPEX 的思路更为统一：只要一个能力可以被描述为明确的输入、执行过程和输出，它就可以被封装成一个 workflow。这个 workflow 既可以作为独立的智能体运行，也可以作为子模块被其他 workflow 调用。

这样一来，智能体的能力就不再只是某个智能体内部的私有提示词，而是可以沉淀为可复用、可测试、可版本管理、能被不同智能体组合调用的能力模块。

从产品视角看，这很像智能体平台未来应具备的“能力组件化”。平台不应只让用户创建一个智能体并编写一大段角色设定。更好的方式是，让用户能够沉淀一组职责明确、接口清晰、可独立测试、能被不同智能体复用的能力模块。

真正成熟的智能体平台，最终比拼的可能不是谁的聊天入口更多，而是谁能将这些能力模块组织得更清晰、更易用、更高效。

执行引擎（Harness）才是关键：流程不是写给模型看的

这篇论文最核心的工程思想，其实体现在 Agent Harness（执行引擎）上。

AgentSPEX 不仅提出了一种 YAML 工作流描述语言，还配套了专门的执行引擎。这个引擎会解析工作流文件、校验结构、管理变量状态、处理条件分支/循环/并行/子模块调用，并逐步调度模型和工具执行。

这也是它与“把流程写进提示词”模式的根本区别所在。

如果只是将工作流写成自然语言描述并放入系统提示词，模型仍然需要自己理解这套流程，并在每一步判断下一步该做什么。流程越复杂，模型的认知负担就越重——它不仅要完成具体的认知任务，还要同时扮演流程解释器、状态管理器和错误处理器。

AgentSPEX 的方式，则是将流程解释与执行控制这项工作从模型身上剥离出来。系统负责严格执行预定义的流程，模型则专注于完成其擅长的局部认知任务。模型无需在每一步都重新理解全局流程，只需根据当前步骤的明确输入，完成指定的理解、生成或推理动作即可。

这实际上是智能体工程化中一次非常重要的职责分工。

大语言模型擅长处理自然语言、开放问题和模糊信息，但它并不适合承担所有确定性的控制逻辑。计算机系统则擅长确定性的流程执行、状态保存、变量传递和异常处理。将这两者混为一谈，短期看开发速度快，长期看系统将变得难以维护、调试和优化。

AgentSPEX 的价值，正是重新划清了这条边界。

可观测、可恢复、可重放：复杂智能体离不开调试系统

AgentSPEX 还特别强调了可观测性、状态恢复和轨迹重放能力。

一个复杂的智能体任务可能运行很久，中间会调用大量工具，生成众多中间结果。如果任务运行失败，开发者需要确切知道失败发生在哪一步、失败前有哪些变量状态、模型当时看到了什么上下文、工具返回了什么内容。

AgentSPEX 的执行引擎会记录完整的执行过程轨迹，并在步骤完成后保存检查点。这样，任务意外中断后可以从最近的检查点状态恢复运行，而非每次都不得不从头开始。

更有价值的是执行轨迹重放功能。

开发智能体时，常会遇到一种情况：你只想修改某一步的提示词或参数，但前面几步可能包含了搜索、阅读网页、生成摘要、调用代码环境等耗时操作。为了验证第七步修改后的效果，重新运行前面所有步骤不仅成本高昂，还会引入新的随机性——因为模型每次生成都可能不同，搜索结果也可能变化，最终很难判断效果变化究竟源自于代码修改，还是源于前序步骤的随机差异。

有了轨迹重放，开发者可以复用前面已执行过的结果，从指定步骤继续运行。这样就能固定上游条件，只观察特定步骤修改后的实际影响。

这对智能体开发极为实用。在传统软件工程中，我们非常重视日志、断点调试、单元测试和回归测试。智能体工程同样需要类似的能力。否则，每次调试都像是在重新召唤一个充满随机性的过程，开发者很难建立稳定的性能预期和调试效率。

AgentSPEX 的检查点和轨迹重放机制，实质上是在为智能体开发补上关键的调试与运维基础设施。

实验结果与工程意义

论文在多个基准测试上评估了 AgentSPEX，覆盖科学问答、数学推理、内容写作、论文理解和软件工程等任务。结果显示，采用 AgentSPEX 结构化的智能体在这些任务上表现更加稳定和良好。

但这里需要避免一个误解：AgentSPEX 带来的效果提升，不应简单地理解为“YAML 让模型变聪明了”。更准确的解读是，论文试图证明：当复杂的任务流程已被清晰设计出来后，将流程交给系统强制执行，通常比把流程描述塞进提示词让模型自行解释执行更为稳定和可控。

这一点对智能体的产业化开发至关重要。

许多团队在构建复杂业务智能体时，会将多步骤流程写入系统提示词，例如先做需求分析，再生成执行计划，接着调用工具，然后校验结果，最后输出报告。这看起来流程完整，但模型每次是否真的严格按此流程执行，仍然是一个概率问题，缺乏强制约束。

AgentSPEX 将这件事变成了一个系统工程问题。流程不再只是提示词中的文本建议，而是执行引擎中的刚性控制结构。模型可以在每个步骤内充分发挥其语言理解和生成能力，但不能随意跳过流程步骤、改变变量传递方式或绕开预定义的执行顺序。

这也是智能体从技术演示走向生产系统必须经历的变化。演示阶段，模型的偶尔自由发挥甚至可能显得更“聪明”或灵活；但在生产阶段，系统更需要的是行为的稳定性、流程的可控性和结果的可复现性。AgentSPEX 所探讨的，正是这种从“看起来能跑”到“可以被工程化管理”的范式转变。

对智能体平台发展的启发

未来的智能体平台，不能只提供“创建智能体、编写提示词、绑定几个工具”这几个基础功能。这样的入口适合快速试验和原型验证，但支撑不了复杂的业务场景。复杂业务需要的是工作流描述语言、模块化能力封装、显式的上下文边界管理、结构化变量传递、调试与回放机制、版本控制以及运行状态监控。

换句话说，智能体平台不能只满足于做一个“更会聊天的机器人”配置后台，而要逐渐演进为一套真正的智能体软件工程平台。

在这个平台里，提示词优化只是其中一环。更重要的是：复杂任务如何拆解？通用能力模块如何沉淀和复用？外部工具如何标准化接入？变量如何在步骤间安全传递？执行失败后如何定位和恢复？历史版本的效果如何对比分析？某次异常输出如何精确复现？

这些能力听起来可能不如“智能”二字那么吸引眼球，但它们恰恰决定了智能体能否真正融入并稳健地支撑起实际的业务流程。

AgentSPEX 的意义正在于此。它将智能体从“一个会调用工具的大语言模型”的简单概念，重新拉回到软件工程的严谨视角中。只要智能体需要承担复杂、长期、可靠的任务，它就必须具备规格定义、流程控制、状态管理、执行日志和调试机制这些软件工程的基本要素。

安全治理的延伸价值

虽然这篇论文并非专门探讨 AI 安全，但它对智能体的安全治理仍有重要启发。

原因很简单：只有当智能体的执行流程变得显式化、结构化之后，安全治理才有了更具体、更可操作的落脚点。

如果智能体的所有行为逻辑都隐藏在提示词和动态生成的对话历史中，安全系统最多只能在输入和输出两端进行内容检测。但如果智能体的任务被拆分为多个明确定义的步骤，每一步都有明确的输入输出规范，每个工具调用都有记录，每个变量都有其来源和去向，那么权限控制、上下文隔离、风险动作确认和执行审计就更容易实现。

例如，某个 workflow 可以规定：从网络获取的网页内容必须先经过安全摘要模块处理，不能直接进入代码执行步骤；某个高风险工具的调用必须经过人工确认或二次授权；某类外部文件只能在沙箱环境中读取解析，不能被传递给外部 API；当发生异常或风险行为时，可以通过轨迹重放来复现完整的执行路径，便于审计和分析。

这些都属于安全治理的延伸空间。当然，本文的主线仍需聚焦于智能体工程化。AgentSPEX 首要解决的是复杂智能体如何被描述、执行、调试和复用的问题，更高的安全性与可控性只是这个结构化过程所带来的自然收益。

总结与展望

AgentSPEX 这篇论文真正值得关注的地方，不在于它发明了一种 YAML 格式，而在于它提出了一个清晰的工程判断：复杂智能体的执行逻辑，不能一直隐藏在提示词里。

提示词适合表达任务目标、角色设定和行为约束，但不适合承载日益复杂的流程控制逻辑。大语言模型擅长处理开放性认知任务，但不适合独自承担状态管理、变量传递、异常恢复和执行回放等系统职责。智能体要进入真实业务场景，就必须逐渐具备软件工程系统应有的结构和工具链。

AgentSPEX 指出的方向，正是将智能体的“如何做事”从模型的自由发挥中剥离出来，转变为系统可以解释、调度和严格执行的工作流。

这也将成为未来智能体产品的一条重要分水岭。早期的智能体比拼的是底层模型能力和提示词编写技巧，而下一阶段的智能体平台，比拼的将是工程化能力。谁能把任务流程编排、上下文管理、能力模块化、工具集成、日志调试体系管理得更好，谁就更接近真正可落地、可运维、可信任的智能体平台。