AI Agent 到底是什么：模型之外的那层循环才是关键

"Agent"这个词如今被用得极其宽泛——从一次简单的函数调用，到能连续跑上几天的研究机器人，都被冠以 Agent 之名。但剥开外壳，它真正指的东西相当具体：一个被放进循环里的语言模型。它能采取行动、观察结果、决定下一步，直到给出答案，或者被运行时的轮次、时间、成本、策略限制叫停。

同一个模型，不同的"外壳"

普通的模型调用是一次性的往返：你发一个 prompt，模型基于已有知识和粘贴进来的内容生成文本，交互结束。它不能查资料、不能验证自己的答案，也不能重试——除非你再发一次请求。

模型变成 Agent 时，模型本身没有发生任何变化。变化的是它周围的代码。原本响应一次就停下的逻辑，现在变成了一个 harness（外壳/编排层）：它把模型的工具请求和工具返回结果一轮又一轮地喂回给模型。

一个直观的对比：酒店客人写下"我的空调坏了"。普通调用会回复一段表示同情的话，承诺联系维修——但实际上没有生成工单，也没有人被告知。而一个 Agent 会识别客人和房间信息、查阅维修政策、创建维修工单、分配可用人员、启动 SLA 计时，并通知客人。

差别不在于模型更聪明，而在于模型被允许触碰真实世界的流程。

循环：思考、行动、观察

理解 Agent 最有效的方式，是看它的核心循环。假设一个 HR 助手只有一个工具 search_hr_docs(query)，有人问：父亲未使用的育儿假能否结转？

1. 思考。 回答需要育儿假政策，应该去搜索它。
2. 行动。 调用 search_hr_docs("parental leave")。
3. 观察。 返回"父亲享有 30 天育儿假"——这回答了"有多少天"，但没回答"能否结转"。
4. 再次行动。 调用 search_hr_docs("carry forward policy")。
5. 再次观察。 返回"未使用的育儿假最多可结转 10 天到下一年"。
6. 停止。 两个事实都到手了，模型写出最终答案。

如果你写过重试逻辑，这个形状并不陌生。唯一的区别在于：下一步操作由模型自己提出。但运行时依然强制约束最大轮次、单次调用截止时间、取消机制和总成本预算——无论模型多想继续跑下去。

工程洞察

模型从不直接触碰数据库、API 或文件。它发出结构化的工具请求，由编排器校验、执行并返回结果。模型只能通过应用程序选择暴露的能力接触外部世界。

这条边界是整个安全模型的基石。它意味着"模型能做什么"完全由你决定，而不是由模型的想象力决定。

工具调用（Tool Use / Function Calling）机制。 文中的循环之所以能成立，靠的是模型具备输出结构化工具请求的能力——这是近年 LLM 的一项关键能力，通常称为函数调用或工具调用。其原理是：开发者在请求中附带一份工具清单（每个工具有名称、用途说明和 JSON Schema 形式的参数定义），模型在生成时不再只输出自然语言，而是可以输出一段符合该 Schema 的结构化数据，例如 {"name": "search_hr_docs", "arguments": {"query": "parental leave"}}。编排器解析这段数据、校验参数、真正执行对应函数，再把结果作为一条新消息拼回上下文。模型本身并不会执行任何东西，它只是"说出"想调用哪个工具、传什么参数。这也解释了为什么工具描述和参数 Schema 的措辞会显著影响 Agent 表现：模型只能依据这些文字来判断某个工具该不该用、怎么用。

五个组成部分，以及自主性的边界在哪

一个 Agent 由五部分组成：

组成部分	作用
模型	根据已观察到的一切决定下一步
工具	读取或改变模型文本之外事物的唯一途径
记忆与上下文	当前情境：本次对话及迄今为止的工具结果
策略与护栏	Agent 可以做什么、不可以做什么，例如超过退款限额需审批
循环	运行思考、行动、观察，并判断是否停止

最常见的错误，是把"是不是 Agent"当成非黑即白的判断。在上面酒店的例子里，模型擅长的是识别"空调发出怪声"属于维修请求，并挑出正确的工作流。而工单生命周期、SLA 计算、权限、审批和审计事件，都应该留给确定性代码。

换句话说：让模型决定采取哪个动作，让你的工作流引擎决定这个动作如何执行。

这条分界线是很多 Agent 项目成败的关键。把太多东西交给模型自主决定，会带来不可控的成本和不可审计的行为；把太少东西交给模型，又退化成硬编码的规则系统。合理的做法是让模型处理它真正擅长的部分——理解模糊的自然语言意图、在多个候选动作中做出选择——而把状态机、权限校验、幂等性、审计这些交给传统工程手段。

幂等性（Idempotency）与审计。 文中提到应把"幂等性、审计"交给传统工程手段，值得稍作展开。幂等性指同一个操作执行一次和执行多次，对系统状态的最终影响相同。这在 Agent 场景中格外重要，因为循环可能因超时、重试或模型误判而重复发起同一个工具调用——如果"创建工单"不幂等，就可能生成一堆重复工单。常见做法是给每次意图性操作分配一个唯一标识（idempotency key），执行端据此去重。审计则指把每一次思考、工具请求、工具结果、策略拦截都记录下来，形成可回溯的事件流。二者共同保证 Agent 的行为既不会因重试而搞乱状态，也能在事后被完整复盘——这正是"让确定性代码决定动作如何执行"的具体落点。

为什么这个定义很重要

把 Agent 定义为"模型 + 循环 + 工具 + 策略约束"，而不是某种神秘的自主智能，能带来几个实际好处。

它让 Agent 的行为变得可测试——你可以单独测试循环逻辑、工具实现、策略拦截，而不必每次重跑整个模型。它让成本变得可预测——最大轮次和总预算约束就写在运行时里，不依赖模型的"自觉"。它也让故障排查有了清晰的层次：是模型选错了动作，还是工具返回了错误结果，还是策略不该拦截这次调用，一眼可辨。

当你下次听到"Agent"这个词时，不妨追问一句：它的循环是怎么写的？工具暴露了哪些？护栏设在哪一层？这些问题的答案，比"用了哪个模型"更能决定一个 Agent 系统的实际表现。

可测试性与评估（Eval）。 把 Agent 拆成模型、工具、循环、策略几个可独立替换的部件，直接带来的好处是可测试性。你可以在不调用真实模型的前提下，用固定输入单测循环的终止判断；用桩（stub）替换工具，验证编排器对错误返回的处理；用一组录制好的历史工具结果，回归测试策略拦截规则。对于确实需要模型参与的部分，则可以采用离线评估：准备一批问题与期望的工具调用序列，批量跑通并统计命中率，而不是每次改动都靠人工肉眼看几条样例。这种分层测试与评估的思路，是把 Agent 从"演示能跑通"推进到"可以持续迭代、敢于上线"的关键，也是这个务实定义最大的工程价值之一。