[控场AI]
· 4 分钟阅读· 2,392 字

AI智能体是怎么工作的?拆解核心的Agent Loop

AI智能体是怎么工作的?拆解核心的Agent Loop

所有AI Agent本质上都是同一个「模型决策+代码执行」的四步循环,搞懂它就理解了所有智能体平台。

本文拆解了AI Agent底层通用的「Agent Loop」机制,指出无论是编程助手、客服机器人还是各大厂商的托管平台,驱动它们的都是同一套四步循环:应用发送请求与工具清单→模型返回结构化工具调用→应用代码执行工具→结果写回历史后再次调用模型,直至模型给出纯文本答案为止。文章强调了一个最易被误解的核心:模型只做决策,从不亲自执行任何操作,真正的执行者始终是开发者自己的代码。在工程层面,作者还点出两个实际构建时必须面对的问题:每轮重发完整历史导致长任务成本膨胀,以及缺少轮数与预算上限可能引发死循环,并给出了缓存、压缩等对应手段。

编程助手、浏览器智能体、客服机器人——你听说过的几乎每一个AI Agent,底层都跑在同一个简单的循环之上。Anthropic、OpenAI、AWS 近期都推出了各自的托管式智能体平台,名字各不相同,但引擎其实是同一套。搞懂这个循环,你就理解了它们全部。

一个比喻:永远不离开料理台的主厨

想象一位主厨,她从不离开自己的操作台。她读过订单后喊一声:「给我拿番茄来!」助手跑去取回。她再看一眼,决定下一步该做什么。她自己从不走进储藏室。

这正是大语言模型与工具协作的方式。模型负责「思考和决策」,但从不亲自执行动作;真正跑腿取货的,是模型之外的代码。理解了这个分工,就抓住了Agent设计的核心。

助手负责取回工具结果

Agent Loop 的四个组成部分

真正的机制由四个部分构成:你的应用(App)、模型(Model)、你的工具(Tools),以及对话历史(Conversation History)。整个流程在这四者之间循环流转。

第一步:发送请求与工具清单

你的应用把用户的请求发给模型,同时附上一份模型「可以使用」的工具列表。每个工具都有一个名字和一套输入 schema(输入参数的结构定义),告诉模型这个工具能干什么、需要哪些参数。

每个工具都有名字与输入schema

输入 schema 通常以 JSON Schema 格式描述,例如一个 getOrder 工具的 schema 可能声明它需要一个字符串类型的 order_id 参数。模型在训练阶段已经学会读懂这类结构化描述,因此能在推理时自主判断:当前任务是否需要调用某个工具,以及应该传入什么参数。工具清单的设计质量直接影响 Agent 的行为——描述模糊的工具会导致模型误调用或参数填写错误,而过多的工具则会分散模型的注意力,增加选错工具的概率。实践中,工具名称和描述字段(description)是模型做决策的主要依据,写清楚「这个工具在什么场景下使用、不适合什么场景」往往比罗列参数更重要。

第二步:模型返回「工具调用」而非答案

关键之处在于:模型此时并不直接给出答案,而是返回一个「工具调用」(tool call)——一个结构化的请求,比如 getOrder,并把参数填好。在 Claude 的 API 中,这时的停止原因(stop reason)会标记为 tool_use,明确告诉你的应用:模型想调用一个工具。

第三步:由你的代码执行工具

收到工具调用后,是你的应用去真正运行这个工具。这是整个机制里最容易被误解的一点:模型永远不会自己执行任何操作,执行的是你的代码。 模型只是「决策者」,调用数据库、访问 API、读写文件这些实际动作,全部发生在你的程序里。

由你的应用运行工具

第四步:把结果写回历史并再次调用

工具跑完后,你的应用把结果追加进对话历史,再一次调用模型。于是循环开始了:调用 → 工具 → 结果 → 再调用……如此往复,直到模型以纯文本形式给出回答、不再发起任何工具调用为止。那就是最终答案,Claude 会把它标记为 end_turn。

OpenAI 的 Agents SDK 以同样的方式结束循环,并且在一次运行超过 max turns(最大轮数)限制时会抛出错误。可见不同厂商的平台虽然命名不同,但「循环直至无工具调用」的终止逻辑是一致的。

模型给出最终答案,Claude标记为end turn

两个必须留意的工程细节

理解了循环本身,还有两个在实际构建中绕不开的问题。

第一,每一轮都会把完整的历史再发送一次。 这意味着任务越长,上下文越大,调用就越慢、越贵。常见的应对手段是缓存(caching)和压缩(compaction)——前者复用已处理过的上下文,后者则对历史做精简,二者都能有效控制长任务的成本膨胀。

第二,一定要给循环设上限。 设置轮数上限(turn limit)和预算上限(budget),可以防止 Agent 陷入「原地打转」的死循环。一个没有封顶的 Agent,既可能把费用烧穿,也可能永远跑不出结果。

缓存(caching)在主流 API 中通常以「prompt caching」的形式提供:若本次请求的上下文前缀与上一次完全相同,服务端可复用已计算的 KV 缓存,从而降低延迟和 token 费用。Anthropic 和 OpenAI 均支持此特性,但需要开发者在请求中显式标记可缓存的边界。压缩(compaction)则是另一种思路:当对话历史超过一定长度时,用一段更短的摘要替换早期的多轮对话,牺牲部分细节换取上下文窗口的空间。两种方案并不互斥,长任务 Agent 往往需要同时使用:先靠缓存复用稳定的系统提示和工具定义,再靠压缩处理不断增长的历史对话。

一句话总结这套机制

所谓 AI Agent,本质就是「一个处在循环中的模型,加上替它干活的你的代码」。模型负责一轮轮地判断下一步该调用什么工具,而真正的执行、结果回填、循环控制与成本管理,都由应用层承担。无论是编程助手还是客服机器人,无论底层是 Claude 还是 OpenAI,剥开外壳看到的都是同一个 Agent Loop。当你下次评估或自己动手搭建一个智能体时,先问清楚它的工具清单、终止条件和成本控制策略,基本就能看透它的运作方式。

分享:

相关推荐