Agent 的规划、执行、反思闭环怎么实现？别把 Reflect 写成小作文

很多人讲 Agent都会讲 Plan、Act、Observe、Reflect。规划、执行、观察、反思。听起来很完整。但工程里最常见的失败是把这套闭环写成 prompt 里的几段话你先计划再执行再反思再继续。结果模型每一步都在“自我总结”日志写了一堆事情没往前走多少。真正有用的 Agent 闭环不是让模型多说几句反思而是把任务执行做成一套可恢复的状态机。计划要能被检查。执行要能被追踪。观察要能落到外部状态。反思要能改变下一步动作。停止条件要明确。缺一个闭环都会变成表演。一、Plan 不是“我要做三步”很多 Agent 的计划看起来像这样分析需求。调用工具。返回结果。这不叫计划。这叫废话。一个可执行计划至少要包含目标是什么。当前已知信息是什么。缺什么信息。每一步用什么工具。每一步的成功标准是什么。哪些动作有风险。什么时候需要用户确认。什么时候停止。比如“帮我整理客户投诉并发起退款审批”计划不能只写“先查客户再查订单再退款”。应该拆成校验客户身份。查询订单和付款记录。判断是否符合退款规则。生成退款草案。如果金额超过阈值进入人工审批。审批通过后再调用退款工具。全链路写审计日志。计划不是给读者看的是给系统执行和校验用的。二、Act 不是盲目调工具执行层最容易犯两个错。第一个错是模型拿到计划就直接调工具参数缺了也猜。第二个错是工具调用成功就认为任务成功。企业 Agent 不能这么做。Act 阶段要先做几件事参数是否齐全。参数来源是否可信。当前 Agent 是否有权限。工具是否适合这个意图。是否需要 dry-run。是否属于高风险动作。尤其是付款、删除、发消息、改权限、审批、关单这类动作模型最多准备操作不应该直接越过系统护栏。执行不是“模型想做什么就做什么”。执行是模型提出动作系统验证动作。三、Observe 要看外部状态不是看模型感觉Observe观察经常被写得很虚。模型调用工具后说“我观察到任务已经完成。”这不够。观察应该来自外部系统的结构化结果。比如{ tool:create_refund_request,status:success,request_id:RF-10086,next_status:waiting_approval,audit_id:AUD-7788}或者失败{ status:failed,error_code:POLICY_NOT_MATCH,message:订单已超过可退款期限,retryable:false,next_action:ask_human_review}Observe 的价值是把世界的真实反馈拉回来。没有工具返回、状态表、错误码、审计 IDAgent 的观察就容易变成“我觉得”。四、Reflect 只在需要时发生反思不是每一步都要做。很多动作不值得反思格式转换、简单查询、固定字段校验、低风险信息整理。你让模型每一步都 Reflect只会增加成本和噪声。我更建议做“反思触发门”。只有出现这些情况才进入 Reflect工具失败。工具结果和计划预期不一致。连续重试仍无进展。任务风险等级升高。发现缺少关键上下文。外部状态发生变化。反思的输出也不应该是一段漂亮总结而应该是下一步策略补充参数。换工具。缩小任务范围。请求用户确认。升级人工处理。停止执行。如果 Reflect 不能改变下一步动作它就是噪声。五、Replan 不能太频繁Replan重新规划很有用也很危险。有些 Agent 一遇到错误就重新规划结果计划越改越远。最开始用户只是要查一个合同最后 Agent 给自己加了“生成报告、通知负责人、创建工单”的任务。重新规划必须有边界。我通常会加三个条件第一原计划的关键前提被推翻。比如用户身份不匹配订单不存在接口不可用。第二目标不变只调整路径。不能借 Replan 偷偷扩大任务范围。第三高风险变更需要人工确认。尤其是新增执行动作、扩大权限、改变业务结果。Replan 的核心不是让 Agent 更自由而是让它在失败后还能回到正确轨道。六、最小实现一张任务状态表如果你要从工程上实现这个闭环不要先写复杂框架。先建一张任务状态表。字段可以很朴素task_iduser_goalcurrent_plancurrent_stepstep_statustool_nametool_inputtool_outputobservationreflection_resultnext_actionrisk_levelapproval_requiredtrace_idcreated_at / updated_at再加一个执行循环生成计划。取当前步骤。做执行前校验。调工具。写观察结果。判断是否触发反思。必要时重新规划。判断完成、等待、失败或升级。这就是最小闭环。它比“在 prompt 里要求模型自我反思”靠谱得多。七、什么时候不要做复杂 Agent还有一句实话。不是所有任务都需要 Agent 闭环。如果任务是固定流程、低风险、高确定性比如表单校验、模板生成、标准检索普通 workflow 可能更好。Agent 闭环适合这些场景步骤不确定。需要根据外部反馈调整路径。工具可能失败。需要多次信息补全。任务有风险分级。需要人机协同。如果任务本身就是确定流程硬套 Agent往往只是把简单系统做复杂。结尾Agent 的规划、执行、反思闭环不是一个漂亮名词。它的工程本质是把不确定任务拆成可检查步骤把工具反馈变成状态把失败变成可恢复路径。我会用一句话判断一个 Agent 闭环有没有价值成功时少废话失败时有退路。做不到这一点再多 Reflect 都只是模型在写工作总结。