AI Agent新范式:先拆分、确认再执行,用少量Token规避大规模翻车

    近期社区流传一份长达1902行的多Agent调度提示词文件，在开发者圈子引发讨论。文档内定义了多Agent协同逻辑、工具调用规则，甚至列出AI废话词汇黑名单，用来抑制模型输出那种千篇一律的AI腔。

    通读这份社区材料不难发现一个共性：整套Agent运行机制，依旧是全自动链式执行。收到任务之后，模型立刻拆解子任务，逐个启动子Agent连续运算，全程没有人工暂停审核的节点。

     全自动模式适合无人值守的自动化流水线，但藏着一个极易被忽略的成本陷阱：一旦模型对原始需求理解发生偏差，后续所有子Agent都会跟着跑偏。上下文持续膨胀，Token消耗成倍上涨。等到整条链路全部跑完，才发现底层逻辑完全错误，前面耗费的算力、Token全部作废。

有没有低成本的破局思路？

    我们可以在Agent工作流的最前端，增加一道人工确认闸口。这套思路在业界属于Plan-and-Solve（规划-执行范式），也叫计划-执行分离模式（Plan / Execute Split）。用户提出需求，模型不直接动手执行，优先输出任务拆分方案：先用一句话复述用户原始目标，再列出准备启用多少个子Agent，每个Agent负责的工作、输入输出内容、任务之间的依赖顺序、验收标准。交由用户审阅，确认规划无误之后，才正式启动执行。如果发现分工错位、任务不可行，可以直接修改、删减，重新规划。

    这套方案最大亮点，就是前置校验的投入很低。如果Agent数量多、依赖关系复杂，规划文本可能达到1k–3k Token。即便如此，对比长链路执行后全盘作废的巨大开销，前置校验的性价比依旧很高。

这套机制，能提前拦截哪些问题

1.优先核验需求理解是否到位

    规划清单强制包含一句话复述用户目标。很多时候模型不会编造假Agent，但会悄悄曲解原始意图，拆分出一套看起来合理、实际方向完全错误的方案。复述目标，就是第一道关卡。

2.识别模型幻觉虚构出来的虚假Agent

     模型偶尔会凭空捏造不存在的专用Agent，规划清单上一眼就能识别剔除。

3.规避“伪拆解”陷阱

    这是落地时极易踩的坑：任务拆分纸面看着条理清晰，只是把模糊性转移到子任务层面，子Agent指令依旧含糊，执行阶段照样翻车。强制增加子任务验收标准，明确“怎么判断任务做对”，审阅者可以快速识别这类看似精细实则空洞的拆分。

4.优化任务拆分逻辑

    避免任务重复、执行顺序颠倒，或是把高度耦合的工作强行拆成多个独立Agent。同时标注依赖强弱，判断单点失败会不会引发连锁崩塌。

5.识别不可落地的任务

    在规划阶段就能判断部分任务本身不具备实现条件，不必投入算力尝试。

更深一层技术拆解：Plan-Confirm-Execute 的工程内核

1.核心机制：用工程化确定性约束概率性偏差

    大模型本质上是概率模型，如果让它“一边想一边做”，极易在执行细节中偏离原始目标。将规划和执行分离，强制模型在动手前输出结构化计划并等待确认，相当于给Agent装上护栏。把模糊需求转为原子子任务，降低长链路推理幻觉，同时计划本身具备可审计性。

2.进阶架构：编排器+子Agent，实现上下文隔离

     整套架构采用 Orchestrator（编排器）+ Sub-agents（子Agent）的模式：编排器只负责制定计划、调度任务，不处理具体业务；各个子Agent只接收当前任务必需的少量上下文。

    这种隔离，能缓解业内常说的Context Rot（上下文腐烂），也就是上下文越长，模型越容易糊涂。同时可以在规划阶段动态加载工具，采用最小权限原则，屏蔽无关高危工具，减少工具混淆、越权风险，进一步节省Token。

3.增加确定性验证器，单独处理事实幻觉

    规划层面的校验，无法根除单个子Agent执行阶段产生的事实幻觉。可以引入确定性验证器Verifier：子Agent输出采用标准化结构化数据（Typed Actions），由验证器做规则校验；校验不通过则返回重规划，校验通过才进入执行。

    提醒：验证器是关键节点触发，不需要全程常驻一个独立核验Agent，防止核验环节本身持续膨胀上下文、引入新幻觉。

4.状态持久化与容错：基于DAG和Checkpoint

    任务规划转化为DAG有向无环图，持久保存每个子任务状态：待执行、执行中、已完成、失败。同时标注每个子任务对上游输出的依赖等级（强依赖/弱依赖/独立）。一旦某个子Agent执行失败，可以基于检查点重试、跳过或者回滚，不需要整条链路从头再来。

存在的短板，不能神化这套方案

1.只能解决规划层面的问题，无法消除单个Agent执行阶段的事实幻觉

    就算分工规划完全合理，子Agent在输出内容时，依旧会出现编造文献、虚构数据的情况。采用关键节点触发验证器的方式，平衡核验能力与上下文开销。

2.增加一次人工交互环节，降低自动化效率

    可以分层选用不同模式：高频简单任务继续全自动ReAct模式；复杂高风险任务启用「规划—确认—执行」；任务复杂但需求清晰、支持回滚，采用自动执行+关键节点检查点，不必每一步都人工介入。

3.审阅人需要具备基础判断力

    审阅者要有能力看懂任务拆分方案、验收标准、依赖关系，识别伪拆解与分工逻辑是否可行。如果审阅人无法判断，这个闸口就失去意义。

全套初始提示词模板（可直接复制使用）

plaintext

    你是多Agent任务规划调度器。硬性规则：在未得到用户确认之前，禁止执行任何实质性任务操作；仅允许读取用户明确提供的材料用于规划。

收到用户需求后，第一步，输出结构化任务规划方案，内容包含：

1. 一句话复述用户本次原始目标；

2. 计划启用的全部Agent清单，编号+Agent名称；

3. 每一个Agent：核心职责、输入信息、预期交付成果、验收标准、能力边界（写明本Agent不能完成什么）；

4. Agent之间执行先后顺序、依赖类型（强依赖/弱依赖/独立）；

5. 标注潜在风险点：是否存在虚构Agent、不可实现的任务项、伪拆解风险。

    输出规划方案之后，停止工作，等待用户审阅。用户可以确认通过、修改规划、删减Agent或者直接取消任务。

    只有当用户明确回复【确认执行】，才按照规划方案，依次启动各个Agent开展工作。

    禁止使用AI套话，语言简洁直白，不使用“值得注意的是、总而言之、深入探讨”这类空洞词汇。

适用场景

    这套「先规划、人工确认、后执行」的Plan-Confirm-Execute范式，本质是把传统软件工程“设计-实现-评审”的思想迁移到AI Agent系统中。它并不是要完全取代全自动的ReAct模式，而是为复杂、高风险、长链路任务提供了一个高性价比的安全模式。

    人工确认闸口就是性价比最高的安全网。很多人觉得引入人工就“不够AI”，但工程现实恰恰相反：模型理解稍微偏一点，全链路跟着跑偏，直到Token耗尽才发现方向错误，这个代价才更加昂贵。一次人工确认，规避后续几十倍的无效算力消耗。这也是AI Agent从“聪明但不可靠的临时工”升级成“受控执行的业务系统”的关键分水岭。