Agent 规划与执行分离架构的工程化设计：从职责解耦到四层防御

Agent 规划与执行分离架构的工程化设计从职责解耦到四层防御摘要在实践中Agent 的规划与执行要不要分离几乎是一个必答题。本文从经典的 Plan-and-Execute 模式出发梳理职责解耦的核心动机、与 ReAct 的取舍边界并在此基础上给出一套包含蓝图校验—动作围栏—轨迹追踪—熔断止损的四层防御体系讨论每一层的职责、实现要点与常见误区。文中观点基于公开资料与个人工程实践整理欢迎指正。一、问题的本质不只是一个 Planner 一个 Executor很多初学者的第一反应是把 LLM 拆成规划器 执行器两个模块就够了。这个回答只说对了一半——它描述了结构却没有回答为什么这样拆、以及拆开之后怎么保证不出事。在工程视角下规划与执行分离真正要解决的是以下几类典型问题[citation:2][citation:6]上下文失控同一个模型边推理边行动长到 10 步以上的任务会因中间结果干扰而跑偏且上下文窗口持续膨胀导致成本上升副作用难控推理逻辑和工具调用写库、发消息、调支付耦合在一起一旦幻觉或越权破坏已经发生不可调试没有清晰的决策边界出了问题难以复盘到底是哪个环节出错不可审计无法判断某次工具调用究竟是计划内的还是模型临时发明的。因此面试官真正考察的往往不是概念背诵而是你是否在生产环境里踩过这些坑、是否具备工程化的风险意识。二、Plan-and-Execute职责解耦的核心模式2.1 基本架构Plan-and-Execute 的核心思想是把决定做什么与实际去做拆开[citation:1][citation:2]User Goal │ ▼ ┌────────────┐ │ Planner │ 生成有序、结构化的步骤清单如 JSON 数组 │ (LLM) │ 步骤可包含描述、依赖关系、所需工具、预期输出 └────────────┘ │ plan ▼ ┌────────────┐ │ Executor │ 逐条执行步骤调用工具只接收当前步骤所需的上下文 │ (LLM) │ 将结果写入共享状态Shared State └────────────┘ │ ├── step result └──▶ [可选] Replanner根据执行结果修订剩余步骤几个关键约束这也是面试高频考点[citation:6][citation:13]角色职责副作用是否持有工具Planner分解目标、产出计划无通常无Executor按步骤调用工具、执行操作有有Replanner可选依据新信息调整后续计划无通常无最佳实践是Planner 不直接执行工具、Executor 不擅自发明步骤、两阶段之间有明确的计划校验环节。一旦 Executor 可以临时加戏或者 Planner 偷偷发了请求职责边界就被破坏后续的审计与熔断也都失去基础。2.2 一个最小可运行的示例下面参考公开的 Plan-and-Execute 实现[citation:2]给出一个精简版 Python 伪代码骨架importjsonimportanthropic clientanthropic.Anthropic()# ---- Planner只产出计划不调用任何工具 ----defcreate_plan(task:str)-list[str]:responseclient.messages.create(modelclaude-sonnet-4-20250514,max_tokens1024,messages[{role:user,content:f You are a task planner. Break the task into a numbered list of concrete, executable steps. Return ONLY a JSON array of step strings. Task:{task}}],)textresponse.content[0].text.strip()start,endtext.find([),text.rfind(])1returnjson.loads(text[start:end])# ---- Executor只执行单步上下文保持紧凑 ----defexecute_step(step:str,context:str,tools:list)-str:responseclient.messages.create(modelclaude-haiku-4-20250514,# 可用更便宜的模型max_tokens1024,toolstools,messages[{role:user,content:f Previous results:{contextorNone yet.}Current step:{step}Use tools as needed, return a concise result. }],)# 省略 tool_use 递归处理逻辑returnresponse.content[0].text要点Executor 只接收当前步骤 已累积结果而非完整历史这样既省钱又避免模型被无关上下文分心[citation:2][citation:14]。2.3 进阶形态ReWOO 与 LLMCompiler单纯的 Plan-and-Execute 仍存在串行调用慢、每步都要 LLM 等问题因此衍生出若干优化[citation:17]ReWOOReasoning Without ObservationsPlanner 生成带变量引用的计划如#E1引用前一步输出Worker 只做工具调用Solver 负责最终合成。优势是治理、可观测、可重复——Worker 只能执行 Planner 授权的操作。LLMCompilerPlanner 输出任务 DAG有向无环图调度器在依赖满足后立即并行执行声称可提速约 3.6 倍。这说明规划—执行分离并非只有一种实现工程上会按成本和并发需求演进。三、与 ReAct 的取舍没有银弹一个常见追问是“那它和 ReAct 什么区别什么时候该用哪个”[citation:3][citation:7]维度ReAct边想边做Plan-and-Execute先规划再执行规划方式每步实时推理决策先全局规划再按顺序执行灵活性高能响应新信息中等Replan 有一定滞后适用场景动态交互、对话、网页浏览、简单任务复杂多步、数据分析、报告生成、流程自动化实现难度简单Prompt 少量示例较复杂需要计划解析与异常处理主要风险易发散、“跑偏”计划过时、误差传递、额外延迟工程上的经验法则[citation:11][citation:14]简单、单步、需要即时反馈 →ReAct 或直接工具调用步骤多、依赖清晰、要求可审计 →Plan-and-Execute更常见的是组合使用粗粒度用 Plan-and-Execute 做总体规划每个子任务内部再用 ReAct 细粒度执行配合Plan-Execute-Replan——执行中观察结果、按需重规划。⚠️Replan 频率是关键参数太低 → 计划过时太高 → 等同于没有计划。经验值可设为每 3~5 步触发一次 Replan或在工具返回异常时触发[citation:11]。四、四层防御体系从能跑到敢上线职责解耦解决了架构清晰度但把 Agent 放到生产环境还需要一整套运行时治理。下面这套四层防御体系本质是把电影拍摄里导演—演员—场记—监视器的关系工程化。第一层蓝图校验层Plan Validation职责在规划开始前对用户的原始指令与生成的计划做安检。校验内容通常包括[citation:13]合法性指令是否符合业务规则、Schema 是否合法越权检测请求的操作是否超出当前用户/会话的权限陷阱识别是否为明显的 prompt injection 或恶意指令计划可行性工具是否存在、参数是否齐全、依赖关系是否闭环。这一层能挡掉大部分低级错误。值得注意的是公开的 Agent 安全实践强调策略引擎应独立于 Agent 逻辑之外防止 Agent 绕过或关闭校验[citation:4]。第二层动作围栏层Action Guardrails职责给 Executor 划定安全边界对每一次工具调用做运行时拦截。策略引擎通常校验以下维度[citation:4][citation:13]调用方是否有权限请求的数据是否与 Agent 用途一致是否超过速率限制或调用量阈值调用模式是否暗示侦察或数据外泄。最小权限原则Least Privilege是这里的基石每个 Agent 只应持有完成声明功能所需的工具并通过 Tool Manifest 在调用时强制校验越权调用应被拒绝并记录而非静默忽略[citation:12]。常见安全模式还包括[citation:13]幂等键Idempotency Key所有副作用调用必须可重入Dry-run / 计划审批高风险任务支付、删库、发邮件先展示计划、人工确认配额与限速按 Agent / 按用户设置上限遏制失控成本。第三层轨迹追踪层Trajectory Tracing职责作为系统的黑匣子完整记录每一步决策与执行支撑复盘与审计。需记录的字段可参考 Agent 审计规范[citation:16]字段含义trace_id全链路唯一 IDagent_id / user_idAgent 与触发用户标识input_content输入内容action_request动作请求policy_result策略引擎校验结果execute_result执行结果risk_score风险评分timestamp时间戳公开安全建议要求审计日志不可篡改、长期留存以支持取证[citation:4][citation:16]。在工程实践中还应追踪[citation:13]每一步的计划版本与决策依据工具调用的入参与出参对 PII 做脱敏每步资源消耗tokens、耗时、成本。发散检测也可在这一层实现监控是否出现重复状态、陷入循环达到阈值即中止[citation:13]。第四层熔断止损层Circuit Breaker Kill Switch职责当异常超过阈值时强制停止防止小问题演变为大事故。这是最后一道保命防线。区别于传统的异常捕获面向 Agent 的熔断器关注的是行为模式[citation:4][citation:12]异常/重复的 API 调用序列过度的资源消耗token、费用、调用频次与正常范围外的系统交互显著偏离基线的决策模式。触发后可进入安全模式暂停新操作、将待执行项排队等待审核、立即告警受影响会话被隔离并撤销活跃凭证[citation:4]。设计要点带外out-of-band熔断比 Agent 内置护栏更可靠——因为被攻陷的 Agent 可能伪造健康信号、绕过自身校验而基础设施层的监控不依赖 Agent 配合[citation:12]。一个三级熔断的参考实现[citation:16]一级警告低风险拦截累计 N 次 → 告警通知二级熔断触发 1 次高风险拦截 → 熔断所有权限人工审核后解封全局紧急熔断发现大规模异常 → 一键关停所有 Agent 执行权限。此外还应配备多层次的 Kill Switch单实例关闭、单能力关闭、全系统关闭按威胁严重程度逐级升级[citation:4]。关于智能触发条件的延伸思考呼应视频末尾的思考题除重复撞击次数外还可考虑——单位时间 API 调用速率偏离基线[citation:12]Token / 费用消耗突增[citation:12]敏感工具调用频次凭证、写操作、管理员 API[citation:12]子 Agent 生成深度超过声明的工作流深度[citation:12]连续失败率 / 重试次数状态重复度陷入相同状态的循环风险评分的滑动窗口均值。五、补充说明与争议点为了让结论更客观这里列出几个容易被忽略的权衡分离架构并非总是最优对于简单单步任务规划阶段反而增加延迟与成本对需要全程上下文的任务Executor 不得不加载完整历史成本优势消失[citation:14]。Plan-and-Execute 有已知缺陷串行工具调用慢、存在误差传递、上下文管理压力大[citation:15]。因此出现了 ReWOO、LLMCompiler 等并行/变量化方案[citation:17]。四层防御是工程经验的归纳非行业标准蓝图校验、动作围栏、轨迹追踪、熔断止损的分层命名是便于落地的组织方式不同团队会有取舍例如是否需要 Replanner、熔断是否带自愈等应以自身业务风险为准。自动自愈需谨慎部分方案建议熔断后不要自动重启 Agent以免清掉取证数据或重启一个已被攻陷的实例[citation:12]。六、小结回到面试问题“Agent 的规划与执行分离架构如何设计”一个相对完整的回答应覆盖三层架构层采用 Plan-and-Execute明确 Planner / Executor /可选Replanner 的职责边界说明与 ReAct 的取舍实现层结构化计划、紧凑上下文传递、最小权限工具网关、幂等键、Checkpoint 与重放治理层蓝图校验 → 动作围栏 → 轨迹追踪 → 熔断止损的四层防御保证出问题能发现、能复盘、能止损。这套思路的价值不在于用了多么高深的技术而在于体现了一种工程化思维把不可控的 LLM 行为通过边界、可观测性与兜底机制收敛成一个可上线、可追责、可止血的系统。参考与延伸阅读Plan-and-Execute 官方概念与代码示例[citation:2]Plan-and-Execute 模式分离规划与执行的架构[citation:14]ReAct vs Plan-Execute-Replan 对比与选型[citation:3][citation:7]Agent 安全运行时治理、策略引擎、审计与熔断[citation:4][citation:12]ReWOO、LLMCompiler 等进阶架构[citation:17]Agent Harness 工程化安全实践[citation:16]Planning vs Execution Agents 职责对比[citation:6]Agent 设计模式Plan-and-Execute[citation:18]