Agent 的基本任务循环：目标、计划、执行、观察、修正

从一次回答到持续推进，理解 Agent 如何把目标变成可验收的结果

引言

在上一篇《重新理解 AI 系列37：Agent 到底是什么？它不是人格，而是任务执行系统》里，我们先给 Agent 做了一次“祛魅”。

Agent 不是住在模型里的数字人格，也不是一个更会聊天的 AI 角色。更准确地说，它是一套围绕目标组织模型、上下文、工具、状态、反馈和验证的任务执行系统。

但只知道“它由哪些部分组成”，还不够。如果上一篇文章更像是画出 Agent 的结构图，那么这一篇，我们就来看这套系统到底怎么转起来。

用户给出一个目标之后，Agent 是不是应该马上规划？计划错了怎么办？工具调用失败了，是任务失败，还是下一轮判断的线索？结果看起来完成了，又怎么判断它真的完成了？

这些问题背后，其实都指向同一件事：Agent 不是一次性生成答案，而是在持续推进任务。

这一篇，我想和你一起拆开 Agent 最基础的任务循环：

目标澄清 → 计划拆解 → 执行动作 → 观察反馈 → 修正路线 → 验证结果。

图注：封面图把全文的主线压缩成一个循环：Agent 的关键不是“会不会说”，而是能不能从目标一路推进到验证。

先说明一下，这不是某个框架规定的官方标准流程，而是一个帮助我们理解 Agent 如何运转的简化框架。它的价值不在于“定义得多标准”，而在于能把 Agent 和普通聊天真正区分开。

普通聊天更像是“给你一段回答”。Agent 则要继续往前走：它要围绕目标做一步，看结果，再决定下一步。

一、第一步不是计划，而是把目标说清楚

很多人想象 Agent 工作时，会觉得第一步应该是“先制定计划”。

这当然没错，但我觉得还差半步：Agent 的第一步，通常不是计划，而是先把目标说清楚。

因为真实任务里，用户给出的往往不是精确指令，而是一个大概意图。

比如：

• • “帮我优化一下这个系统。”

• • “帮我分析一下这个问题。”

• • “帮我整理一下这批资料。”

这些话当然能启动任务，但还不足以支撑一个 Agent 稳定执行。因为里面有很多没有说出来的东西：优化什么？性能、成本、稳定性、体验，还是代码结构？分析什么？原因、影响、风险，还是下一步动作？整理成什么？清单、报告、表格，还是可以直接给别人看的结论？

如果目标不清，后面的计划、工具选择、状态记录、结果验证都会跟着歪。

所以，一个可靠的 Agent，不应该急着证明自己“马上能干活”，而应该先把用户的意图整理成更可执行的目标。

这个目标至少要回答几件事：要完成什么结果，输入材料在哪里，成功标准是什么，有哪些限制条件，哪些动作需要确认，最终交付物是什么。

目标澄清不是啰嗦，而是在给后面的任务循环定方向。如果一开始连“完成”意味着什么都不清楚，Agent 后面做得越多，可能只是错得越远。

二、计划：把目标拆成当前可执行的步骤

目标清楚之后，才进入计划。但这里也有一个容易误解的地方：计划不是一次性写出一条完美路线，然后从头执行到尾。

对很多 Agent 任务来说，计划更像是当前阶段最合理的行动假设。

为什么是“假设”？

因为真实任务会在执行中不断暴露新情况。你原本以为问题在日志里，结果日志不完整；你原本以为可以直接调用某个工具，结果权限不够；你原本以为输入材料很干净，结果里面有一堆冲突信息。

这个时候，如果 Agent 还死抱着最初计划不放，就会显得很“努力”，但不一定有效。

比如用户说：

“帮我排查这个项目最近几天的异常。”

一个很粗糙的计划可能是：看日志，找原因，给建议。

这不能说错，但太粗了。它没有告诉 Agent 下一步到底怎么做，也没有告诉它中途应该根据什么调整。

更好的计划可能是：先确认异常发生的时间范围，查看对应日志，汇总高频错误类型，对比最近的代码或配置变更，形成可能原因，再用测试、命令或进一步查询验证假设。

这样的计划不一定一步到位，但它能指导下一步行动。它会让 Agent 知道：下一步做什么，为什么先做这一步，做完以后看什么反馈，如果反馈不符合预期又该怎么调整。

计划的价值，不是让 Agent 显得很会安排，而是让任务从一个模糊目标，变成一组可以执行、可以观察、可以修正的步骤。

图注：这张图对应前两节：Agent 不应该在目标不清时急着规划，而要先把“要什么、用什么、做到什么程度、有什么限制”说清楚。

三、执行：工具调用不是炫技，而是改变任务现场

有了计划，下一步就是执行。在 LLM Agent 里，执行经常表现为工具调用。

它可能通过 Function Call 发起结构化调用，通过 MCP 接入外部工具和资源，通过 CLI 进入文件、命令、日志和测试现场，也可能通过 API 调用业务系统。

OpenAI 对 Function Calling 的说明里，也把它定位为连接模型与外部工具、外部系统的一种方式。MCP 的工具规范同样强调，server 可以暴露可由语言模型调用的工具，用来查询数据库、调用 API 或执行计算。

也就是说，工具不是为了让演示看起来更热闹，而是为了让模型能够接触外部世界。

工具调用不是炫技。工具调用的意义，是让任务从“模型脑子里的推理”，进入“真实世界里的反馈”。

查日志，是为了让模型看到真实证据；跑测试，是为了得到客观反馈；读取文件，是为了知道当前材料到底是什么；写入文件，是为了让任务产生可交付物；调用 API，是为了让外部系统参与任务。

执行不是“模型说它做了什么”，而是系统真的做了一个动作，外部世界真的返回了结果，或者发生了变化。

这也是 Agent 和普通聊天很不一样的地方。普通聊天可以停在建议层：你应该检查日志，你应该跑测试，你应该对比配置。Agent 则进一步进入执行层：我现在去检查日志、运行测试、读取配置，再把结果带回来继续判断。

当然，越能改变真实世界，风险也越真实。读取信息和写入文件不是一个风险等级；生成草稿和直接发布不是一个风险等级；查询数据和批量修改数据也不是一个风险等级。

所以执行阶段一定要带着边界意识：哪些动作可以自动做，哪些动作需要确认，哪些动作必须禁止，不能只看模型“会不会调用工具”。

四、观察：Agent 必须读懂行动之后发生了什么

执行之后，很多系统会犯一个很隐蔽的错误：工具调用结束了，就以为这一步完成了。

但对 Agent 来说，工具返回结果不是流程的终点，而是下一轮判断的输入。这就是观察。

Anthropic 在《Building effective agents》里也强调，Agent 在执行过程中需要从环境获得 ground truth，比如工具调用结果或代码执行结果，用来评估自己的进展。这个说法非常关键：Agent 不是只靠自己“想”，而是要不断被外部反馈校正。

观察不只是“工具返回了一段文本”。它可能是命令输出、错误码、文件 diff、测试结果、检索结果、用户反馈，也可能是某个系统状态变化。

Agent 需要从这些反馈里判断：行动成功了吗？信息够了吗？原来的假设被支持了，还是被推翻了？下一步应该继续、换路，还是停下来问人？

很多 Agent 看起来不可靠，问题就出在这里。

它只看到命令执行完了，却没有看命令是不是成功；只看到搜索结果很多，却没有判断来源是否可靠；只看到测试失败，却没有分析失败原因；只看到文件生成了，却没有检查内容是否符合目标。

这时候，工具虽然调用了，任务却没有真正往前走。

所以我觉得可以这样说：

不会观察的 Agent，只是在机械调用工具；会观察的 Agent，才开始进入真正的任务循环。

观察这一步，决定了工具调用到底是“装饰性的动作”，还是能真正帮助系统修正判断。

五、修正：失败不是结束，而是下一轮判断的输入

Agent 的优势，不在于永不失败。

说实话，只要任务足够真实、环境足够复杂，失败几乎一定会发生。路径不对，权限不够，参数错了，工具返回异常，材料缺失，测试不通过，用户临时补充要求，这些都很正常。

真正重要的是：失败之后，Agent 能不能根据反馈修正。

工具报错，不一定是坏事。它可能告诉 Agent：路径错了、参数不完整、权限不足、前提不成立。检索不到结果，也不一定意味着没有答案，可能只是查询方式不对、关键词太窄、数据源不合适。测试失败，也不只是“失败”两个字，它可能说明当前假设不成立，也可能暴露更深的问题。

一个好的 Agent，应该能把这些失败转成下一轮判断的输入。

常见的修正策略包括：临时错误可以重试；当前工具不合适就换工具；任务太大就缩小问题；之前判断被反馈推翻就更新假设；涉及权限、成本、不可逆动作或价值判断，就请求确认；继续做会增加风险，或者已经没有足够信息，就停止行动。

这里也要避免另一个极端：修正不是乱试。

有些 Agent 一失败就开始连续尝试，好像只要足够努力，总能撞出一个结果。这个状态看起来很勤奋，但其实很危险。

好的修正应该基于观察结果，而不是基于模型的焦虑。

它应该能说清楚：我为什么要重试？为什么要换工具？为什么要缩小问题？为什么现在应该问用户？

修正的本质，是让 Agent 不被一次错误拖死，但也不在错误里无限打转。

图注：这张图把第三到第五节连起来：工具调用只是动作，只有把真实反馈带回循环，Agent 才能继续修正下一步。

六、验证：判断“看起来完成”和“真的完成”

任务循环最后一定要有验证。没有验证，Agent 很容易把“生成了一个结果”误认为“完成了任务”。

这可能是 Agent 最常见、也最危险的错觉之一。

模型生成了一段总结，看起来逻辑完整，但事实来源没有检查；模型修改了一段代码，看起来像修好了，但测试没有跑；模型生成了一个表格，看起来很整齐，但字段口径不一致；模型说“已经完成”，但目标系统并没有发生预期变化。

这些都只是“看起来完成”。

所以，Agent 说“我完成了”，不等于完成。验证通过，才更接近完成。

验证标准最好来自一开始的目标，而不是来自模型自己的感觉。

代码任务看测试、类型检查和关键路径；数据任务看行数、字段、口径、异常值；文档任务看结构、事实来源和格式；操作任务看目标系统状态是否发生了预期变化。

至于战略取舍、品牌表达、组织决策这类高判断任务，自动验证通常不够，最终还是需要人类确认。

验证不是为了给 Agent 找麻烦，而是在帮 Agent 知道什么时候该停。没有验证，Agent 可能会过早结束，也可能会一直继续做。前者是不可靠，后者是失控。

七、人类应该卡在哪里？

讲到这里，最后一个问题就很自然了：

如果 Agent 有目标、有计划、能执行、能观察、能修正、能验证，那人是不是就可以完全放手？

我觉得答案很明确：不能。

但这也不意味着人要每一步都盯着。可靠 Agent 不是完全自动，也不是处处让人确认，而是把人放在关键位置。

我理解的人类介入点，至少有五类。

第一，目标确认。任务太模糊时，Agent 不应该假装自己理解了，而应该把目标、范围、交付物和成功标准问清楚。

第二，权限确认。只要涉及外部系统、真实数据、真实成本，就不能把所有权力默认交给模型。

第三，高风险动作确认。删除、覆盖、发布、发送、付款、批量修改，这些动作一旦执行，影响就进入真实世界。这里需要明确确认，甚至需要更强的审批和回滚机制。

第四，价值判断确认。优先级怎么取舍，风险要不要接受，品牌表达是否合适，组织决策如何权衡，这些问题不是模型自己可以“代表人类”决定的。

第五，最终验收。尤其是自动验证无法覆盖质量的时候，人类仍然要对最终结果负责。

所以，人的角色不是被 Agent 替代，也不是退回到每一步手动操作。更合理的位置是：定义目标、授予边界、处理高风险判断、验收最终结果。

Agent 越能做事，人类边界越重要。

图注：这张图对应第七节：可靠 Agent 不是完全放手，也不是每步审批，而是让人类卡在真正影响方向、风险和责任的位置。

结语

在上一篇文章里，我们说 Agent 不是一个人格，而是一套任务执行系统。

这一篇，我们进一步拆开了这个系统最基础的运转方式：

目标澄清 → 计划拆解 → 执行动作 → 观察反馈 → 修正路线 → 验证结果。

目标给方向，计划把目标变成下一步，执行让系统进入真实现场，观察把真实反馈带回来，修正让系统不被一次错误拖死，验证判断任务是否真的完成。

而人类边界，则决定了哪些地方必须交给人确认。

这就是 Agent 和普通回答之间最关键的差别。普通回答可以到“我建议你怎么做”为止；Agent 要继续往前走：它要真的做一步，看结果，再决定下一步。

所以，理解 Agent，不要只看它能不能给出一个聪明回答，而要看它能不能形成一个可靠的任务循环。

一旦这个基本循环建立起来，后面我们再看 Agent 的设计模式，就不会只是在看一堆框架名词，而是在看不同模式如何强化循环里的某个环节。

真正可靠的 Agent，不是一次想对所有事情，而是在每一次行动之后，都能更接近正确的下一步。

参考资料

• • Anthropic Engineering, Building effective agents: https://www.anthropic.com/engineering/building-effective-agents

• • OpenAI Help Center, Function Calling in the OpenAI API: https://help.openai.com/en/articles/8555517-function-calling-in-the-openai-api

• • Model Context Protocol Specification, Tools: https://modelcontextprotocol.io/specification/draft/server/tools

• • OpenAI Agents SDK, Agents: https://openai.github.io/openai-agents-python/agents/