假设你对一个 AI Agent 说：“帮我找三家适合团队聚餐的餐厅，比较价格和距离，然后推荐一家。”

看起来只是一句话，但对 Agent 来说，里面其实藏着一串决策：先理解你到底要什么，判断信息够不够，要不要查地图和餐厅数据，查到结果以后怎么比较，发现某家没营业要不要重新搜索，什么时候算任务已经完成，以及最后到底由谁决定可以把答案交给用户。

很多人理解 Agent 时，容易把注意力放在“大模型有多聪明”或者“接了多少个 Tool”上。真正决定一个 Agent 是否可靠的，往往是另一件事：它有没有一个清晰、可控、能够结束的执行循环。

Agent 不是“会调用工具的聊天机器人”

普通聊天模型的工作方式相对简单：用户输入一段文字，模型生成一段文字。

Agent 多了一层重要能力：它可以在得到问题以后，不立即回答，而是先采取行动。

比如搜索网页、查询数据库、读取文件、执行代码、调用企业 API，再根据工具返回的结果决定下一步。

因此，一个通用 Agent 更接近下面这个循环：

接收任务 → 理解当前状态 → 判断下一步行动 → 执行动作 → 获取新信息 → 更新状态 → 判断是否完成 → 继续或输出答案。

可以把它想象成一个人在陌生城市里完成任务。

你告诉他：“帮我买一杯附近评价不错的咖啡。”

他不会站在原地思考十分钟，然后凭想象告诉你哪家最好。他会先确定当前位置，再搜索附近咖啡店，查看营业状态，比较距离和评价，最后选择一家。

如果第一家已经关门，他不会把“搜索完成”误认为“任务完成”，而是会继续寻找。

这正是 Agent 和一次性问答最大的区别：Agent 的核心不是生成，而是不断在“判断”和“行动”之间循环。

用户输入以后，第一件事不是调用 Tool

一个常见设计误区是：用户一提出任务，Agent 马上开始搜索、执行代码或者访问数据库。

看起来行动很快，实际上很容易做错事情。

Agent 真正应该做的第一件事，是建立一个任务状态。

这个状态至少要回答几个问题：用户最终想得到什么？有哪些明确约束？当前已经知道什么？还缺什么信息？完成任务需要满足什么条件？

例如用户说：

“帮我订明晚适合四个人谈事情的餐厅。”

如果 Agent 只提取出“餐厅”，然后立刻搜索，结果很可能没有意义。

“明晚”意味着时间约束；“四个人”影响座位；“谈事情”暗示环境不能太吵；如果要真正预订，还需要知道城市、具体时间，甚至用户是否允许直接提交预约。

因此，用户输入以后更合理的第一步是：

把自然语言请求转换成一个可以执行、可以检查是否完成的任务。

这一步很像项目经理接需求。

优秀的项目经理听到“帮我把官网做得更好”以后，不会立刻让工程师开始改代码。他会先弄清楚所谓“更好”到底指速度、转化率、视觉效果，还是搜索排名。

Agent 也一样。

如果连成功标准都没有定义，后面的每一步都可能很勤奋，但方向是错的。

下一步该思考，还是该调用 Tool？

这可能是 Agent 循环里最关键的判断。

一个简单的原则是：

如果下一步需要获得模型当前没有、而且不能可靠推断的信息，就应该考虑调用 Tool。

比如：

“解释什么是 TCP 三次握手。”

模型已有知识足够，通常不需要工具。

但如果用户问：

“今天北京天气怎么样？”

这就需要实时信息，继续在模型内部“想”并不会让答案变得更准确。这时应该调用天气工具。

再比如：

“分析这个 CSV 里哪个产品利润最高。”

模型知道怎么算利润，但它还没有真正读取和计算文件里的数据。这里需要执行数据处理，而不是继续抽象推理。

所以，“思考还是 Tool”并不是两个完全对立的动作。

思考负责回答：

我现在缺什么？哪个动作最可能减少这种不确定性？

Tool 则负责真正改变 Agent 所处的信息状态。

可以把 Tool 理解成 Agent 的“手和眼睛”。

大模型可以判断“我应该看看冰箱里还有没有鸡蛋”，但真正打开冰箱并获得结果，是工具做的事情。

这也解释了为什么 Tool 越多不一定越好。

如果 Agent 没有良好的行动选择机制，接入一百个工具，只会让它拥有一百种可能犯错的方法。

一次 Tool Call 结束，不代表任务结束

假设 Agent 的任务是：

“找出下周从上海到东京最便宜的三个航班。”

它调用一次航班搜索工具，返回十条结果。

任务完成了吗？

不一定。

Agent 还要检查日期是否符合要求，价格是不是同一口径，有没有重复航班，是否真的选出了三个结果，以及这些结果是否足够回答用户的问题。

因此，每次行动之后，都应该发生一次非常重要的步骤：

Evaluation，也就是状态评估。

Agent 要比较两个东西：

当前状态。

目标状态。

如果两者之间还有差距，就进入下一轮循环。

例如：

目标是“找到三个符合条件的航班”。

当前只有两个符合条件。

那就不能输出 Final Answer。

或者目标是“修改代码并确认测试通过”。

虽然代码已经修改，但测试失败。

任务仍然没有完成。

这种机制听起来简单，却直接决定 Agent 会不会出现一种非常常见的问题：做了一件相关的事情，就误以为自己完成了任务。

真正成熟的 Agent，判断的不是“我有没有行动”，而是“用户要求的成功条件有没有被满足”。

Agent 如何知道什么时候应该停下来？

如果让 Agent 永远循环“思考—调用工具—再思考”，理论上它可以一直找更多信息。

所以通用 Agent 必须拥有停止条件。

最主要的停止条件，是任务成功标准已经满足。

比如用户要求：

“总结这份合同中的五个主要风险。”

Agent 已经读取合同，识别风险，验证每一项都有文本依据，并整理出五点，这时继续搜索通常不会产生足够大的价值。

但现实系统还需要另一类停止条件：资源限制。

例如最大执行步骤、最大 Tool Call 次数、时间限制、费用预算，或者遇到无法获得的关键权限。

假设 Agent 需要读取一个没有访问权限的文件。

它尝试三次不会突然获得权限。

成熟的系统应该停止循环，告诉用户：“任务目前无法继续，因为缺少文件访问权限。”

所以，“完成”并不只有一种形式。

一种是：

成功完成。

另一种是：

确认无法继续，并清楚说明阻塞原因。

后者同样比无限重试可靠得多。

Final Answer 最好不是模型的一次冲动

最后一个问题很容易被忽略：到底谁负责判断可以输出 Final Answer？

最简单的 Agent，会让同一个大模型自己决定。

模型觉得任务完成，就直接回答。

这种方式容易实现，在简单场景里也够用，但它有一个明显问题：执行者同时也是验收者。

更可靠的设计，会把“能不能结束”做成一个独立的检查过程。

它可以是代码规则，也可以是状态机，还可以是另一个 Evaluator。

例如一个报销 Agent 的完成条件可以非常明确：

费用金额已提取。

发票已读取。

报销类别已确定。

必填字段全部存在。

用户授权状态满足要求。

只有这些条件全部通过，系统才允许进入 Final Answer 或真正提交报销。

这时真正掌握“结束权”的，不再只是语言模型，而是整个 Agent Runtime，也就是负责维护状态、执行工具、检查结果和控制循环的运行系统。

模型负责提出下一步。

Tool 负责执行。

Evaluator 负责检查。

Runtime 负责决定继续还是结束。

在简单 Agent 里，这几个角色可能由同一个模型完成；在高可靠场景里，它们通常会逐渐拆开。

这也是从 Demo 走向生产系统时很重要的一步。

一个完整 Agent，真正需要设计的是“循环”

如果要把通用 Agent 压缩成最小模型，可以记住这样一个流程：

用户提出目标以后，Agent 先建立任务状态和成功标准；然后根据当前状态选择下一步行动。能通过已有知识解决，就继续推理；需要外部信息或真实操作，就调用 Tool。

每次 Tool 返回结果以后，Agent 都更新状态，再检查目标是否已经满足。

满足，就进入 Final Answer。

没有满足，就开始下一轮。

如果遇到权限、预算、步骤限制等无法继续的问题，则结束任务并说明原因。

因此，设计 Agent 时，一个比“应该接哪些工具”更值得先问的问题是：

这个系统如何知道自己现在在哪里、还差什么，以及什么时候应该停下来？

工具决定 Agent 能做什么，大模型决定它可能有多聪明，而执行循环决定这些能力能不能稳定地变成结果。

真正可靠的 Agent，未必每一步都最聪明，但它知道什么时候该想、什么时候该行动，也知道什么时候任务已经结束。