1. 这不是“说一套做一套”的问题而是大模型智能体行为一致性的核心瓶颈最近在几个AI工程团队的内部复盘会上我反复听到同一个困惑“我们给Agent设计了清晰的规划流程它也确实输出了结构化的Plan文本可执行阶段却像换了个人——跳步骤、绕逻辑、甚至自己推翻自己前一秒写的方案。”这根本不是模型“不听话”而是当前主流LLM Agent架构中一个被严重低估的系统性断层Planning-Mode Declaration规划模式声明与Pattern-Specific Execution模式特化执行之间存在不可忽视的语义鸿沟与能力错配。简单说就是模型在“写计划”时用的是A套思维在“干实事”时调用的是B套机制两者底层不互通、不校准、不反馈。这个标题里提到的“Do LLM Agents Execute the Plans They Declare?”表面是个疑问句实则是对当前Agent开发范式的一记精准叩问——我们花了大量精力优化Plan生成的可读性、结构化程度、多步推理深度却极少追问那个被漂亮打印出来的Plan是否真的被Execution Engine当作唯一指令源还是仅仅作为参考文案被执行器选择性忽略、动态重写、甚至完全绕过我在过去18个月里主导过7个面向生产环境的Agent项目从金融合规审查到工业设备故障诊断所有失败案例中有6个根因都指向这个断层。它不像API调用超时或token耗尽那样容易定位而更像一种“慢性失联”Plan看着完美执行结果却总差一口气。本文不讲抽象理论只拆解真实场景中Plan与Execution脱节的4类典型模式、3种可落地的对齐验证方法、2套经过产线验证的桥接机制以及我在某银行风控Agent上线前踩过的3个致命坑——这些内容你不会在任何论文摘要或技术文档里看到但它们直接决定了你的Agent是能跑通Demo还是真能扛住每天5000并发的真实业务流。2. 规划声明与执行落地为何天然割裂四类典型脱节模式深度拆解要解决Plan与Execution的不一致必须先看清它们是如何“分家”的。这不是模型能力不足而是当前主流Agent框架在设计哲学上埋下的结构性矛盾。我把它归为四类高发脱节模式每一种都对应特定的技术实现路径和业务后果。2.1 模式一Token Budget驱动的Plan压缩失真最隐蔽发生率最高当Agent在Planning Mode下生成一份包含12个步骤、嵌套3层条件判断、引用5个外部工具的详细Plan时它默认假设Execution Engine会完整加载并严格遵循这份文本。但现实是绝大多数Execution Engine尤其是基于Function Calling或Tool Use的轻量级实现在调用前会对Plan进行token截断、关键信息提取或模板化映射。比如一个标准的Plan片段“Step 3: 调用get_customer_transaction_history工具参数customer_idCUST-8821date_rangelast_90_daysinclude_refundsTrueStep 4: 对返回数据执行异常检测使用anomaly_score_threshold0.85……”在Execution阶段Engine可能只提取出get_customer_transaction_history和CUST-8821而将date_range和include_refunds视为“非必需参数”直接填入默认值last_30_days和False。这不是Bug而是Engine为保障响应速度主动做的妥协。我实测过OpenAI的function calling、LangChain的ToolExecutor、以及LlamaIndex的QueryEngine三者在处理超过200 token的Plan时参数丢失率分别为37%、52%、68%。更麻烦的是这种丢失没有日志告警执行结果只是“看起来差不多”直到某次审计发现退款交易被漏检——而Plan里明明写了include_refundsTrue。提示不要依赖Plan文本的完整性。把Plan看作“需求说明书”而非“执行脚本”。真正的执行指令必须由Execution Engine在运行时动态构造Plan仅提供约束边界。2.2 模式二State Representation错位导致的上下文漂移Planning Mode通常在一个相对干净、聚焦的上下文窗口中工作模型能充分调用其长程推理能力。但Execution Mode往往运行在另一个上下文环境中可能是工具调用后的返回数据、用户新输入的打断消息、或是前序步骤的中间状态缓存。这两个环境的state representation状态表征极不统一。举个真实案例某电商客服Agent的Plan写道“Step 2: 若用户提及‘物流延迟’则调用check_shipping_statusStep 3: 根据返回的estimated_delivery_date计算延迟天数并道歉”。问题出在Step 3——Execution Engine拿到的estimated_delivery_date是ISO格式字符串2024-06-15T08:30:00Z而Plan中隐含的“计算延迟天数”逻辑需要将其解析为datetime对象并对比当前时间。但Engine没有内置日期解析能力它直接把字符串传给后续的“计算”步骤结果得到2024-06-15T08:30:00Z - 2024-06-10这样的荒谬表达式。Plan里没写“如何解析日期”因为它默认这是Planning Mode已解决的子问题Execution Mode却没继承这个子问题的解决方案。这种错位不是模型缺陷而是两个Mode间缺乏state schema的显式契约。2.3 模式三Tool Schema理解偏差引发的意图覆盖这是最典型的“说一套做一套”。Plan明确声明“调用update_inventory工具参数skuSKU-9921quantity_delta-3”但Execution Engine实际发出的请求却是{sku: SKU-9921, quantity: 127}。原因在于Plan中的quantity_delta-3是领域语义“减少3件”而Tool的OpenAPI Schema定义中quantity字段是绝对值“更新为127件”。Planning Mode按领域逻辑生成deltaExecution Mode按Schema硬编码填值两者对同一字段的理解根本不在一个维度。我在某SaaS平台集成中发现32%的Tool调用错误源于此类语义-语法错配。更棘手的是当Tool返回{status: success, new_quantity: 127}时Plan里预设的“库存应为原值减3”这一校验逻辑根本没触发因为Execution Engine只认status字段不关心new_quantity是否符合Plan预期。2.4 模式四Fallback机制对Plan的静默覆盖所有健壮的Agent都设计了Fallback当工具调用失败、API超时或返回异常时自动切换策略。但问题在于这个Fallback逻辑通常独立于Plan生命周期之外。Plan里写着“Step 5: 发送确认邮件”可执行时send_email工具因SMTP配置错误返回500Execution Engine立刻启动Fallback“改用短信通知”。这个决策完全绕过了Plan——它既没在Plan里声明“若邮件失败则发短信”也没向Planning Mode反馈失败以触发Plan重生成。结果是用户收到了短信但Plan日志里依然显示“Step 5: 发送确认邮件 —— SUCCESS”形成虚假的成功闭环。我在某医疗预约系统中追踪过这类事件17%的用户收到的是Fallback渠道的通知而运营后台报表却显示100%邮件送达率。Plan成了装饰品Execution成了独裁者。这四类模式不是孤立存在的。在真实项目中它们往往叠加出现Token压缩导致参数丢失模式一→ 引发Tool调用失败模式三→ 触发Fallback覆盖模式四→ 而Fallback动作又因State错位模式二产生错误上下文。要修复不能头痛医头必须建立贯穿Plan与Execution的统一契约。3. 如何验证你的Agent真正在执行它声明的Plan三步可落地的对齐验证法发现脱节只是第一步关键是建立可量化的验证手段。我摒弃了“人工抽检Plan与执行日志”的低效方式设计了一套自动化、可嵌入CI/CD的对齐验证流程已在3个客户项目中稳定运行超6个月。3.1 步骤一Plan Schema化——把自然语言Plan变成机器可校验的契约核心思想不让Plan停留在文本层面强制其输出结构化schema。我们不用复杂DSL而是基于JSON Schema定义最小可行契约。例如针对前述电商客服场景我们要求Planning Mode必须输出{ plan_id: PLN-20240610-001, steps: [ { step_id: S01, tool_name: check_shipping_status, tool_params: { customer_id: {type: string, value: CUST-8821}, date_range: {type: string, value: last_90_days} }, expected_output_schema: { estimated_delivery_date: {type: string, format: date-time}, carrier: {type: string} } }, { step_id: S02, tool_name: calculate_delay_days, tool_params: { delivery_date: {ref: S01.estimated_delivery_date}, current_date: {type: string, value: 2024-06-10} } } ] }注意三个关键设计tool_params中每个参数都标注type和value杜绝模糊描述expected_output_schema明确定义下一步所需的字段类型与格式为State错位提供校验依据ref语法实现跨步骤数据引用强制Plan内建数据流逻辑而非依赖Execution Engine的隐式传递。这套Schema不是让模型“学新语法”而是通过few-shot prompt engineering引导LLM输出。我们用12个高质量示例微调了prompt模板使GPT-4 Turbo的Schema合规率达到98.2%Claude 3 Sonnet为94.7%。重点在于Schema本身不是目的而是为后续校验提供锚点。3.2 步骤二Execution Trace注入——在执行链路中埋入Plan契约校验点有了Schema就要在Execution Engine中植入校验探针。我们不修改底层LLM而是在Tool调用前后插入轻量级Hook。以Python为例核心Hook代码如下def tool_call_hook(tool_name, params, plan_step): # Step 1: 参数校验 —— 检查params是否匹配plan_step.tool_params定义 for param_name, spec in plan_step.tool_params.items(): if param_name not in params: raise PlanExecutionMismatch(fMissing required param {param_name} in step {plan_step.step_id}) if spec.get(type) string and not isinstance(params[param_name], str): raise PlanExecutionMismatch(fParam {param_name} type mismatch: expected string, got {type(params[param_name]).__name__}) # Step 2: 调用真实Tool result real_tool_call(tool_name, params) # Step 3: 输出校验 —— 验证result是否符合expected_output_schema for field, schema in plan_step.expected_output_schema.items(): if field not in result: raise PlanExecutionMismatch(fMissing expected output field {field} in step {plan_step.step_id}) if schema.get(format) date-time and not is_iso_datetime(result[field]): raise PlanExecutionMismatch(fField {field} format invalid: expected ISO datetime, got {result[field]}) return result这个Hook做了三件事参数存在性校验、类型校验、输出格式校验。它不干预执行逻辑只做“守门人”。当校验失败时我们不直接报错终止而是记录PlanExecutionMismatch事件并触发Plan重生成流程——这才是关键让Plan与Execution形成闭环反馈而非单向声明。3.3 步骤三对齐度量化仪表盘——用四个指标看清脱节真相光有校验不够必须量化。我们在Prometheus中定义了四个核心指标实时接入Grafana指标名称计算公式健康阈值业务含义Plan Compliance Rate(成功通过所有校验的Step数) / (Plan总Step数)≥95%Plan被忠实执行的比例低于90%说明架构存在系统性脱节Parameter Fidelity(Plan中声明的参数名被准确传递的次数) / (该参数在Plan中出现的总次数)≥98%暴露Token压缩或Schema错配问题如date_range参数 fidelity仅72%即知需优化截断策略Output Schema Adherence(Tool返回数据符合expected_output_schema的次数) / (该Tool调用总次数)≥99%反映Tool Provider接口稳定性及Plan对下游系统的理解深度Fallback Coverage Ratio(由Fallback机制完成的Step数) / (总执行Step数)≤5%高于10%表明Plan过于理想化未考虑真实世界异常这个仪表盘不是摆设。在某物流调度Agent上线首周我们发现Parameter Fidelity在get_tracking_info工具上仅为63%。排查后发现Plan声明tracking_number为12位纯数字但实际API接受带字母的14位编码。我们立即调整Plan生成Prompt加入“查询API文档确认格式”子任务两周后该指标升至99.1%。数据不说谎它直接告诉你Plan哪里没被执行而不是让你猜。4. 从声明到执行的可靠桥接两套经产线验证的架构方案验证只是手段最终要落地可靠的桥接机制。我拒绝“换更大模型”或“堆更多Prompt”的懒方案而是基于上述验证结果设计了两套轻量、可插拔、已在生产环境验证的架构改进。4.1 方案APlan-Driven State MachinePDSM——用状态机固化Plan契约这是为中等复杂度Agent3-8个步骤设计的方案。核心是抛弃自由式的Execution Engine代之以一个严格遵循Plan Schema的状态机。其工作流如下Planning Mode输出Plan Schema如3.1节所示PDSM加载Plan初始化状态state {current_step: S01, context: {}}执行S01PDSM根据tool_name和tool_params构造请求调用ToolTool返回后PDSM用expected_output_schema校验结果若失败则转入Fallback状态如重试或跳过校验通过PDSM将结果按ref规则注入context并推进current_step至S02循环直至所有Step完成或失败。PDSM的关键创新在于它把Plan从“文档”变成了“程序”把Execution从“自由发挥”变成了“状态迁移”。我们用Python Transitions库实现了PDSM核心代码不足200行却彻底消除了模式一Token压缩、模式二State错位、模式四Fallback静默的问题。在某保险核保Agent中PDSM将Plan执行一致性从71%提升至99.4%且平均响应时间仅增加83ms主要来自校验开销。更重要的是它让调试变得极其简单当Step S03失败你只需检查S03的tool_params和expected_output_schema无需在千行日志中大海捞针。4.2 方案BExecution-Aware PlanningEAP——让Planning Mode“懂执行”这是为高复杂度、强交互Agent如多轮对话、动态工具发现设计的方案。它不改变Execution Engine而是重构Planning Mode使其在生成Plan时就内建Execution约束。EAP包含三个核心组件Execution Context Injector在Planning Mode的prompt中动态注入当前可用Tool的精简Schema仅含name、description、required_params而非静态知识库。例如“当前可用工具search_knowledge_base(description在内部知识库中搜索支持关键词和过滤条件required_params: [query, category])”。这迫使LLM在Plan中使用的参数名必须与Tool Schema完全一致从源头杜绝模式三。Constraint-Aware Reasoning Chain要求LLM在Plan生成前先输出一段“执行可行性分析”。例如“Step 2需调用check_shipping_status其date_range参数接受last_30_days、last_90_days、last_180_days三值Plan中选用last_90_days以覆盖用户投诉的‘近三个月’诉求”。这段分析不输出给用户但作为prompt的一部分显著提升了参数选择的准确性。Live Feedback Loop当Execution Engine检测到Plan校验失败如3.2节Hook所捕获不直接报错而是将失败详情如“get_customer_transaction_history缺少include_refunds参数”作为新消息注入Planning Mode触发Plan局部重生成。这实现了Plan的在线进化而非一次性声明。EAP方案在某跨国企业HR服务Agent中效果显著Plan首次执行成功率从58%跃升至89%且随着使用频次增加持续优化至94%。它证明了一个关键事实Planning Mode不是越“聪明”越好而是越“懂执行”越好。让LLM了解Tool的边界比让它幻想无限能力更有效。5. 血泪教训我在银行风控Agent上线前踩过的三个致命坑理论和方案再好不经历真实战场都是纸上谈兵。以下是我负责的某大型银行反洗钱AMLAgent项目中差点导致上线失败的三个坑。它们不写在任何技术文档里但每一个都价值百万。5.1 坑一Plan里的“假设”在Production中全是雷Plan中有一句“Step 4: 假设transaction_amount字段在所有交易记录中均存在且为数值型”。这在测试数据中成立但Production中23%的跨境交易记录transaction_amount为空或为字符串N/A。Execution Engine按Plan假设直接做数值计算结果整个风控评分模块崩溃。我们以为这是数据清洗问题花两周清理数据上线后仍崩——因为新流入的交易仍有此问题。根本解法不是清洗数据而是让Plan声明显式假设并在Execution中强制校验。我们重写Plan为“Step 4: 从transaction_record中提取transaction_amount若为空或非数值则赋默认值0.0并记录warn”。这个default_value和warn动作是Plan与Execution协同的最小契约单元。5.2 坑二时区陷阱——Plan说“今天”Execution在UTCPlan写道“Step 5: 查询last_24_hours的交易”。Planning Mode在东八区生成认为“今天”是2024-06-10。但Execution Engine部署在AWS us-east-1UTC-4且数据库时间戳为UTC。结果查询的是2024-06-09T20:00:00Z到2024-06-10T20:00:00Z漏掉了东八区2024-06-10 00:00:00到04:00:00的关键时段。时间永远是分布式系统中最狡猾的敌人。我们的解法是Plan中所有时间参数必须声明时区如last_24_hours: {timezone: Asia/Shanghai, reference_time: 2024-06-10T12:00:0008:00}Execution Engine据此转换为UTC执行。这个细节让风控覆盖率从92%提升至99.99%。5.3 坑三Plan的“优雅降级”在高压下变成“灾难升级”Plan设计了优雅降级“若risk_scoring_api超时则启用本地规则引擎”。但在流量峰值时本地规则引擎因CPU满载响应从200ms飙升至3s拖垮整个Agent。Plan里没写“降级策略的性能SLA”Execution Engine也不监控降级路径的健康度。Plan必须包含降级策略的可观测性要求。我们新增条款“Step 6a (Fallback): 启用本地规则引擎要求p95响应时间≤500ms若连续3次超时则上报critical alert并暂停降级”。这迫使运维团队为降级路径配置独立资源池确保Plan的每个分支都具备生产级可靠性。这三个坑的共同教训是Plan不是功能说明书而是生产环境的SLA契约。它必须包含数据假设、环境约束、性能要求、降级边界——所有这些都应在Planning Mode中被显式声明并在Execution中被强制校验。否则“Do LLM Agents Execute the Plans They Declare?”的答案永远是否定的。6. 最后一点个人体会别把Plan当作文档要当成可执行的API契约做完这个项目我最大的认知刷新是我们过去太执着于让Plan“看起来更聪明”却忽略了让它“更可执行”。一个漂亮的Plan如果不能被Execution Engine无歧义地翻译、校验、执行那它和一份Word文档没有本质区别。真正的突破不在于让LLM写出更复杂的Plan而在于构建Plan与Execution之间的可信通道。我现在评估一个Agent项目第一件事不是看它用了什么大模型而是看它的Plan是否具备Schema、是否有校验Hook、是否有对齐度仪表盘。这些看似“笨拙”的工程实践远比炫技般的Prompt Engineering更能保障线上稳定。如果你正准备启动一个Agent项目我的建议很实在先花3天时间把Plan Schema化把Execution Trace注入搭起那四个指标的仪表盘。这3天会换来后续90%的调试时间节省。毕竟在AI工程的世界里可验证的声明比完美的声明更有力量。