企业官网建设流程全解析

很多人讲 Agent，都会讲 Plan、Act、Observe、Reflect。

规划、执行、观察、反思。听起来很完整。

但工程里最常见的失败，是把这套闭环写成 prompt 里的几段话：你先计划，再执行，再反思，再继续。结果模型每一步都在“自我总结”，日志写了一堆，事情没往前走多少。

真正有用的 Agent 闭环，不是让模型多说几句反思，而是把任务执行做成一套可恢复的状态机。

计划要能被检查。执行要能被追踪。观察要能落到外部状态。反思要能改变下一步动作。停止条件要明确。

缺一个，闭环都会变成表演。

一、Plan 不是“我要做三步”

很多 Agent 的计划，看起来像这样：

1. 分析需求。

2. 调用工具。

3. 返回结果。

这不叫计划。这叫废话。

一个可执行计划，至少要包含：

• 目标是什么。

• 当前已知信息是什么。

• 缺什么信息。

• 每一步用什么工具。

• 每一步的成功标准是什么。

• 哪些动作有风险。

• 什么时候需要用户确认。

• 什么时候停止。

比如“帮我整理客户投诉并发起退款审批”，计划不能只写“先查客户，再查订单，再退款”。

应该拆成：

• 校验客户身份。

• 查询订单和付款记录。

• 判断是否符合退款规则。

• 生成退款草案。

• 如果金额超过阈值，进入人工审批。

• 审批通过后再调用退款工具。

• 全链路写审计日志。

计划不是给读者看的，是给系统执行和校验用的。

二、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 的价值，是把世界的真实反馈拉回来。

没有工具返回、状态表、错误码、审计 ID，Agent 的观察就容易变成“我觉得”。

四、Reflect 只在需要时发生

反思不是每一步都要做。

很多动作不值得反思：格式转换、简单查询、固定字段校验、低风险信息整理。你让模型每一步都 Reflect，只会增加成本和噪声。

我更建议做“反思触发门”。

只有出现这些情况，才进入 Reflect：

1. 工具失败。

2. 工具结果和计划预期不一致。

3. 连续重试仍无进展。

4. 任务风险等级升高。

5. 发现缺少关键上下文。

6. 外部状态发生变化。

反思的输出也不应该是一段漂亮总结，而应该是下一步策略：

• 补充参数。

• 换工具。

• 缩小任务范围。

• 请求用户确认。

• 升级人工处理。

• 停止执行。

如果 Reflect 不能改变下一步动作，它就是噪声。

五、Replan 不能太频繁

Replan（重新规划）很有用，也很危险。

有些 Agent 一遇到错误就重新规划，结果计划越改越远。最开始用户只是要查一个合同，最后 Agent 给自己加了“生成报告、通知负责人、创建工单”的任务。

重新规划必须有边界。

我通常会加三个条件：

第一，原计划的关键前提被推翻。比如用户身份不匹配，订单不存在，接口不可用。

第二，目标不变，只调整路径。不能借 Replan 偷偷扩大任务范围。

第三，高风险变更需要人工确认。尤其是新增执行动作、扩大权限、改变业务结果。

Replan 的核心不是让 Agent 更自由，而是让它在失败后还能回到正确轨道。

六、最小实现：一张任务状态表

如果你要从工程上实现这个闭环，不要先写复杂框架。

先建一张任务状态表。

字段可以很朴素：

• task_id

• user_goal

• current_plan

• current_step

• step_status

• tool_name

• tool_input

• tool_output

• observation

• reflection_result

• next_action

• risk_level

• approval_required

• trace_id

• created_at / updated_at

再加一个执行循环：

1. 生成计划。

2. 取当前步骤。

3. 做执行前校验。

4. 调工具。

5. 写观察结果。

6. 判断是否触发反思。

7. 必要时重新规划。

8. 判断完成、等待、失败或升级。

这就是最小闭环。

它比“在 prompt 里要求模型自我反思”靠谱得多。

七、什么时候不要做复杂 Agent

还有一句实话。

不是所有任务都需要 Agent 闭环。

如果任务是固定流程、低风险、高确定性，比如表单校验、模板生成、标准检索，普通 workflow 可能更好。

Agent 闭环适合这些场景：

• 步骤不确定。

• 需要根据外部反馈调整路径。

• 工具可能失败。

• 需要多次信息补全。

• 任务有风险分级。

• 需要人机协同。

如果任务本身就是确定流程，硬套 Agent，往往只是把简单系统做复杂。

结尾

Agent 的规划、执行、反思闭环，不是一个漂亮名词。

它的工程本质是：把不确定任务拆成可检查步骤，把工具反馈变成状态，把失败变成可恢复路径。

我会用一句话判断一个 Agent 闭环有没有价值：

成功时少废话，失败时有退路。

做不到这一点，再多 Reflect 都只是模型在写工作总结。