简介：本文对比了“将规则写入提示词”与“把AI封装为确定性执行组件”两种构建路径。文章从可控性、可恢复性、审计能力、Token成本、工程化程度和适用场景等维度展开分析，帮助开发者理解为什么单纯堆规则容易失效，以及如何通过执行环境、流程编排和状态管理让AI输出从“概率结果”走向“工程组件”，并给出选型与落地建议。
在大模型应用开发的早期阶段，很多团队的第一反应是：把需求、规则、示例、约束都写进提示词里，让模型自己遵循。随着规则数量从几十行膨胀到几百行，开发者开始普遍观察到一种现象：模型不再稳定地遵守指令，遗漏步骤、跳步、字段混淆、未经确认执行等情况频繁出现。
这带来一个核心问题：我们到底应该继续强化提示词约束，还是把AI从“自由决策者”改造成“受控执行组件”？
本文要对比的正是这两种构建路径：
这两种路径并不完全互斥，但在架构理念、可控性、资源消耗和扩展方式上存在明显差异。理解这些差异，有助于团队在项目早期做出更合适的设计选择。
提示词驱动型Agent的核心思路是：模型即控制器。开发者通过自然语言描述业务目标、操作步骤、字段要求、异常处理方式，让模型在对话过程中自主规划并执行任务。
这种方式的优点是上手快、改动灵活。业务规则发生调整时，通常只需要修改提示词文本，无需改动代码结构。对于探索性项目、演示原型或规则变化频繁的初期场景，提示词驱动可以快速验证可行性。
但问题在于，提示词本质上是“建议”而非“约束”。同一个提示词在不同模型、不同上下文顺序下，可能产生不同行为。当规则复杂到一定程度后，模型会出现选择性遗忘、规则优先级混乱、跨步骤字段污染等现象。
执行环境驱动的Agent改变的是职责分配方式。它的目标是让模型只负责“理解人话、做出判断、组织表达”，而将流程控制、数据校验、接口调用、状态转换等确定性行为交给外部程序。
在这种架构下，模型不再被要求记住每一步的具体规则。它只需要在每一个决策点输出结构化数据，例如JSON参数。执行环境负责校验这些参数是否合法、决定下一步调用哪个接口、记录当前状态、在失败时提供可恢复的路径。
这种架构的核心思想可以概括为：不改变“河的本性”，但为它修好“渠”。模型依然是一个概率系统，但它的输出被限制在预先定义好的轨道中运行。
两种路径在以下方面存在共性：
第一，都依赖大模型的语言理解和生成能力。 无论是否引入执行环境，自然语言到结构化意图的转换仍然需要模型完成。
第二，都追求任务自动化。 两者都希望减少人工介入，让系统能够根据用户输入自动完成后续操作。
第三，都面临模型不确定性问题。 即使引入执行环境，模型在语义理解、边界判断、歧义消解等环节仍然可能出错。执行环境只是降低错误传播范围，并不能完全消除错误。
第四，都需要持续调优。 提示词路径需要不断调整提示词内容，执行环境路径则需要维护流程定义、校验规则和状态机。两者的调优成本都不可忽视。
在提示词驱动型Agent中，可控性来自“模型对规则的理解程度”。模型理解得越准确，执行越可靠。但这种理解受模型版本、上下文长度、提示词顺序、示例数量等多种因素影响。
在执行环境驱动的Agent中，可控性来自“外部环境对模型输出的约束”。模型每次只输出一个局部决策，该决策必须通过校验才能进入下一步。即便模型在某一步出现偏差，环境也可以拦截并纠正，而不是让错误继续传播。
提示词驱动的Agent一旦在某一步出错，后续步骤往往会持续受影响。因为模型自己无法可靠地回滚状态，也很难准确判断错误发生在哪一步。常见的情况是：用户发现结果不对后，只能重新开始整个流程。
执行环境驱动的Agent则天然具备检查点和状态管理能力。每一步执行前都会记录状态，执行后校验结果。如果某一步失败，环境可以根据状态记录定位失败位置，重试当前步骤或回退到上一个有效状态。
提示词驱动的Agent通常需要在每轮对话中携带大量规则文本。规则越多，每次调用消耗的Token越多。此外，模型在模糊需求下可能会多次尝试、反复揣摩、走偏后重新开始，这些都带来额外的Token消耗。
执行环境驱动的Agent将规则从提示词中移除。模型只需要看到当前步骤的少量上下文和明确的任务指令。流程信息由环境维护，不需要在每轮对话中重复传输。这样可以显著降低单次调用和整体任务的Token消耗。
提示词驱动的Agent在审计方面存在天然劣势。它的内部推理过程不透明，每次决策路径难以复现。即使记录下完整对话，也很难确定模型当时为什么选择了某个操作。
执行环境驱动的Agent将每一次决策输入和输出都结构化了。环境可以记录每步的输入参数、校验结果、状态变化和接口返回，形成完整的执行轨迹。这对于生产环境的故障定位和安全审计非常关键。
提示词驱动的Agent在规则增多时需要修改提示词，而提示词越长，模型的遵循能力越差。这意味着它存在一个规则复杂度的天花板。
执行环境驱动的Agent在规则增多时，通常是在外部增加校验节点、流程分支或状态转换，而不是增加单次提示词长度。模型每次面对的上下文保持不变，因此扩展对模型性能的影响较小。
| 对比维度 | 提示词驱动型Agent | 执行环境驱动的工程化Agent |
|---|---|---|
| 规则存放位置 | 全部在提示词中 | 在外部执行环境中 |
| 模型职责 | 理解、规划、执行、校验 | 理解、局部判断、输出结构化参数 |
| 流程控制 | 模型自主决定 | 环境强制执行 |
| 失败恢复 | 通常需要重新开始 | 支持检查点、重试、回退 |
| Token消耗 | 规则越多消耗越大 | 规则增加对Token影响较小 |
| 审计能力 | 难以完整复现决策路径 | 可记录结构化执行轨迹 |
| 扩展方式 | 修改提示词 | 增加校验节点和流程分支 |
| 复杂规则遵循 | 规则越多越容易失效 | 与模型上下文解耦，稳定性更高 |
| 适用阶段 | 原型验证、探索性需求 | 生产环境、可审计场景 |
选型的关键不是“哪种方案更好”，而是“不确定性在哪个层面被消化”。
如果业务需求本身还不清晰，流程经常变动，那么过早引入执行环境可能增加维护负担。此时提示词驱动的灵活性更有价值。
如果业务规则已经相对稳定，但模型行为仍然不稳定，那么应该优先考虑把确定性逻辑从提示词中剥离。团队可以将最频繁出错的部分——流程顺序、字段映射、权限校验——先抽出来，逐步建立执行环境。
一个常见的折中做法是：保留模型对用户意图的理解能力，但规定模型只能输出预定义格式的结构化参数。这样既保留了灵活性，又降低了后续流程的不确定性。
从提示词驱动迁移到执行环境驱动，不是把提示词内容机械地翻译成代码，而是一次职责的重新划分。以下几点需要特别注意：
不要一次性迁移所有规则。 建议从最核心、最容易出错的两三个环节开始。例如先固定输入参数格式，再增加流程校验，最后引入状态管理。
避免把执行环境做成另一种“巨型提示词”。 如果外部程序本身变得非常复杂，维护成本可能超过提示词方式。执行环境应该保持清晰的状态边界和校验层级。
关注人机交互的边界。 有些步骤需要用户确认，有些步骤可以自动执行。迁移过程中要明确哪些决策必须由人做出，哪些可以由系统自动完成。
兼容性需要提前评估。 现有系统可能已经依赖提示词输出的某种格式。迁移过程中需要确保新结构能够与现有接口兼容，或者提供平滑的过渡期。
记录每一次策略调整。 执行环境让行为可追溯，但前提是需要有人持续维护这些记录。审计能力的价值只有在长期坚持下才能体现。
把AI当成“算法”来用，本质上是在做一件事：让模型在概率空间的输出，被一个确定性的外部框架所承接。这个框架不决定模型怎么思考，但决定模型的输出能不能被可靠地执行、验证和恢复。
提示词驱动和工程化执行环境并不是简单的替代关系。前者适合在不确定性高的阶段快速试错，后者适合在规则稳定后追求可靠运行。两者之间的迁移核心不是技术工具的更换，而是对“哪些事情应该交给模型、哪些事情应该交给代码”这一问题的持续回答。
当你发现规则写到200行、AI开始“叛逆”时，这通常不是一个提示词调优问题，而是一个架构信号：是时候让模型从“全局决策者”退回到“局部决策者”的位置上，把流程的轨道交给代码，让AI只做它最擅长的那部分。