目标、规划与终止

概念 · 智能体 AI 详解

目标、规划，以及知道何时算完成。

两个问题决定了一个智能体是有用还是一场烧钱的大火：它如何决定该做什么，以及它如何知道何时该停。本篇在概念层面讲规划——从"不规划，只反应"到"预先规划一切"的谱系，以及为什么中间地带通常才是对的——然后讲那个被低估的难题：终止。一个无法可靠判断自己已完成的智能体，比一个偶尔出错的智能体更危险。

STEP 1

目标 vs 任务 vs 动作：三个层级，别混为一谈。

这里思路马虎会导致一种特定的、常见的故障，所以把术语钉死：

目标（Goal）——用户实际想要的结果，通常是模糊的、用英语陈述的。"确保我们的文档不再引用已废弃的 API。"成功是一个世界的状态，而非一个步骤。
任务（Task）——智能体把目标分解成的一个具体子目标。"找出每一个提及 v1 的文件"；"判断哪些提及已过时"；"修复或上报它们"。
动作（Action）——单次工具调用。search_files("v1")。循环执行的原子单元。

常见的故障：一个智能体优化了动作层或任务层，却丢了目标。它勤勉地跑搜索、开文件、改东西——每个动作局部看都合理——并在技术上"完成了任务"，而用户的实际目标却没达成（它修了文档却弄坏了一个代码示例；它回答了字面问题却没回答意图中的问题）。让目标保持显式并被反复核对就是解药，这也是为什么最好的智能体会周期性地重新自问"我正在做的事还在服务于原始目标吗？"

STEP 2

规划谱系。

"智能体规划吗？"不是一个是非问题。存在一个谱系，而正确的位置取决于任务的可预测性：

REACTIVE  ───────────────────────────────────►  DELIBERATIVE
(no explicit plan)                          (full plan up front)

│ Pure ReAct        │ Plan-then-execute  │ Hierarchical
│ decide one step,  │ write a plan, then │ plan goals → tasks →
│ act, observe,     │ execute it step by │ replan a subtree when
│ decide again.     │ step, replan if    │ a task fails; keep the
│ No stored plan.   │ blocked.           │ rest of the plan.
│                   │                    │
│ Best when each    │ Best when the      │ Best for long, multi-
│ step's result     │ steps are roughly  │ stage tasks where a
│ genuinely changes │ knowable up front  │ late failure shouldn't
│ what to do next.  │ and order matters. │ discard everything.

反应式那一端（ReAct 模式：交替进行推理和行动，一次一步）最简单，是短任务的默认选择——它不需要计划，因为每个观察直接告知下一步动作。深思熟虑那一端先写一份显式计划。计划之所以有帮助，有一个具体原因：它们让目标始终摆在模型面前。上下文里一份写好的计划，是一个持续的提醒，抵抗 STEP 1 里那种目标漂移。当环境不可预测到第二步计划就已经错了、而模型把精力浪费在捍卫一份已死的计划而不是适应时，计划就有害了。

来自当前实践的实用默认做法：从反应式（ReAct）开始。只有当轨迹显示智能体在多阶段任务上跟丢了主线时，才加入一个显式规划步骤——症状是一个每一步都做得称职、却最终走到用户不想去的地方的智能体。规划是对长跨度目标连贯性的一个修复，而非一个默认要加的特性。大多数短的智能体任务根本不需要计划。

STEP 3

终止：真正的难题。

这里有一个没人会警告新手的不对称。决定下一个动作是 LLM 擅长的事——通常有一个合理的下一步，模型能找到它。决定"我完成了，现在应该停"是 LLM 系统性地不擅长的事，原因是结构性的：模型是一个下一令牌预测器，而"再产出一个有帮助的动作"几乎总是比"宣布完成并停止"更可能的延续。模型的训练把它往"继续"的方向拉。任由其自行判断，智能体的两个自然故障模式是停得太早（因为有一个看似合理的答案可用就在一个只做了一半的目标上宣布胜利）和永不停止（总能找到再检查一件事的理由）。

因此一个健壮的智能体绝不单独信任模型来决定终止。它组合了：

一个显式的完成定义——最好是可检验的，而非凭感觉。"完成" = "所有 v1 引用要么被移除、要么被标注为有意保留，并由一次重新扫描返回零个未标注命中来验证"。一个智能体（或外壳程序）能测试的成功标准，胜过"模型认为自己完成了"。
一个验证步骤——在宣布完成之前，智能体对照标准重新检查自己的工作，最好用一个读动作来观察实际的最终状态，而非假定它的写入成功了。
硬性预算——智能体循环那篇里的步数/令牌/时间/金额上限。它们不是主要的停止条件；它们是当前两者失败时的兜底，而它们一定会失败。
一个升级出口——"如果我在预算内无法满足标准，就停下来，带着我的发现交回给人类。"一次干净的放弃是一次成功的终止；一直挣扎到预算烧光则不是。

在你构建智能体之前就陈述完成标准，并尽可能让它可检验。如果你写不出一个任务的"完成"是什么意思，你就无法为它构建一个可靠的智能体——你只能构建一个运行到预算耗尽的智能体，然后期望输出还不错。"模型会知道自己何时完成"，就像它的表亲"模型会知道何时停止"一样，是一种期望，而非一个设计。

STEP 4

合起来看：一个良构的智能体任务。

本节的一切都汇聚到一份清单上。当你能填齐以下所有项时，一个任务就可以交给智能体了——而尝试填齐它们这个动作本身，就是判断智能体是否真是合适工具的最佳测试：

目标——陈述为一个期望的最终状态，而非一个流程。（"收件箱里没有超过 24 小时未回复的账务邮件"，而非"回复邮件"。）
工具——目标所需的最小读写动作，写动作在代码中被限定范围并限流。
完成标准——一个可检验的完成定义，最好还有一个能观察它的验证动作。
预算——显式的步数、令牌、时间和成本上限，依据观察到的轨迹来定，而非猜的。
升级路径——智能体完不成时怎么办：交给谁，带什么上下文。
每个写动作的自主性等级——来自自主性阶梯：哪些写自由运行，哪些需要批准。

如果你能填齐这六项，你就有了一个良构的智能体任务，剩下的就是工程。如果你发现你无法写出一个可检验的完成标准，或目标其实不是一个状态，或反正每个写动作都需要批准——那不是你规格里的一个缺口，那是任务在告诉你它想要的是一个工作流、一个聊天机器人或一个人。下一篇"何时该用智能体（以及何时不该）"，就是把这个领悟变成一个决策程序。