从 Demo 到生产环境：深度解析 AI Agent 核心循环（Agent Loop）的架构演进

最近在研究 DeepSeek Harness（下文简称 DSH）的架构设计时，有一句话让我印象很深：“Everything is a plugin”（万物皆插件），甚至连最核心的 Agent Loop 本身也是一个可替换的插件。

我第一反应是好奇：Agent Loop（智能体循环）说到底不就是“调模型、跑工具、再调模型”吗？写成代码也就十几行，把它做成插件有什么意义？

顺着过去四年 Agent 技术的演化往回看，我才算彻底想明白这件事。从 2022 年底 ReAct 论文发表至今，那个循环的核心逻辑确实没怎么变，但围绕这个循环的“工程假设”已经被彻底颠覆了。

这篇文章想探讨的核心思想只有一句话：随着模型越来越聪明，Loop 本身的代码正在变得越来越薄；但为了把模型放进真实的生产环境，Loop 对外的工程契约却变得越来越厚。

一、从“哄着模型写作文”到“原生工具调用”：ReAct 循环是怎么来的？

要理解 Agent Loop，得先回到 2022 年底 ReAct 论文刚发表的时候。

那时候的大模型就是一个纯粹的“文字接龙机器”，根本没有什么工具调用的概念。你想让模型帮你查天气，只能靠写提示词（Prompt）跟它约定好一套“写作文的格式”。比如你在提示词里规定：

“遇到不会的问题，你必须先写一行 Thought: 说明你的思考过程，然后另起一行写 Action: 加上你要调用的工具名字和参数，写完就立刻停笔。”

于是，一次交互在底层是这样跑的：

模型乖乖输出两行纯文本： Thought: 用户问北京天气，我需要调用搜索工具。 Action: search("北京天气")
外面的程序拿到这段文字后，用正则表达式（或者字符串匹配）去硬抠 Action: 后面的内容，解析出函数名 search 和参数 "北京天气"。
程序去真正执行这个搜索接口，拿到结果 "晴，25度"。
程序把这个结果包装成一行文字 Observation: 晴，25度，直接拼接到刚才那段文字后面，再把整篇长文重新发给模型，让模型接着往下写。

这就是最早的 ReAct。你会发现它极其脆弱：模型只要稍微“自由发挥”一下——比如把英文冒号写成了中文冒号，或者参数里多加了个引号——外面的正则表达式就会解析失败，整个循环当场崩溃。

原生 Function Calling 的原理：把“文字约定”变成“API 协议”

为了解决“正则抠字眼总是出错”的问题，OpenAI 在 2023 年 6 月推出了原生的 Function Calling（函数调用）。

它的核心原理其实并不神秘，主要做了两件事：专门微调模型 + 升级 API 数据结构。

输入端（传结构化说明书）：你不再需要在提示词里用大白话教模型怎么写格式了，而是在调用 API 时，通过一个专门的 tools 参数，把你有几个工具、每个工具叫什么名字、接收什么类型的参数（用 JSON Schema 格式），像传说明书一样传给模型。
输出端（专门的字段分流）：模型经过了专门训练，当它觉得需要用工具时，不再输出普通聊天文本了，而是直接返回一个专门的结构化字段 tool_calls，里面规规矩矩地装着 JSON 格式的函数名和参数（比如 {"name": "search", "arguments": "{\"city\": \"北京\"}"}）。

注意，很多初学者以为 Function Calling 是大模型自己去把函数执行了，其实根本不是！ 大模型依然只负责“动嘴”（输出 JSON 格式的调用请求），真正“动手”去跑代码的，依然是你本地的循环（Loop）。Loop 拿到 tool_calls 里的参数，在本地执行完函数，再把结果包装成一条角色为 tool 的特殊消息传回给模型。

这样一来，虽然告别了正则解析报错的年代，但 ReAct 的核心循环骨架保留了下来，变成了今天大家最熟悉的十几行代码：

while True:
    # 1. 把历史消息和工具说明书发给模型
    response = model.generate(history, tools=my_tools)
    history.append(response)

    # 2. 如果模型只回了普通文字，没返回 tool_calls，说明说完了，退出循环
    if not response.tool_calls:
        break

    # 3. 本地执行模型要求的工具，把结果塞回历史，进入下一轮循环
    tool_results = run_tools(response.tool_calls)
    history.extend(tool_results)

在写 Demo 的时候，这十几行代码堪称完美。因为它在暗中默认了五条非常天真的假设：

一步一动作：模型每次只调一个工具，或者几个互不冲突的工具，本地闭着眼睛挨个执行就行。
思考只是普通文字：模型的思考过程不需要特殊照顾，拼在历史记录里就行。
不调工具就是做完了：下一步干什么全听模型的；只要 response.tool_calls 为空，就代表任务圆满结束。
运行期间没人打扰：循环跑起来之后是封闭的，用户不会中途插话改需求，也不用停下来等人工审批。
程序永远不会崩：所有状态都放在内存的 history 数组里，不用考虑断电或进程重启。

然而，当技术继续演进、Agent 进入真实生产环境后，这五条假设被一条接一条地打破了。

二、动作越变越大：并发调度与“怎么停下来”成了难题

Function Calling 只是把“一步调用一个工具”变稳定了，但很快人们发现：一步只调一个工具，来回对话的轮次太多、太慢了。于是动作的表示方式又经历了两次升级，直接把 Loop 推向了深水区。

1. 并行调用与 CodeAct：把“调度难题”甩给了 Loop

并行工具调用（Parallel Function Calling）：2023 年底，模型升级了，可以在一次回复的 tool_calls 数组里同时塞进好几个工具请求。比如你问“北京和上海今天谁更热？”，模型一次返回两个 search 请求，而不是先查完北京、等结果回来再查上海。
代码即动作（CodeAct）：2024 年初更进一步，与其让模型一个个选工具，不如直接给模型一个代码沙箱。模型一步直接写一段 20 行的 Python 脚本，在脚本里自己写循环、写条件判断、连续调用多个接口。

这两次升级看起来是给模型提效了，实际上却把复杂的调度和安全问题甩给了外面的 Loop：当模型一口气返回 5 个工具调用时，Loop 能无脑开启 5 个线程并发跑吗？不能。如果前两个工具是“查询账户余额”（只读，无副作用），它们可以并发跑；但如果第三个工具是“扣除账户 100 元”，第四个又是“查询账户余额”，这时候 Loop 必须识别出第三个工具有修改状态的副作用，必须像一道屏障一样等前两个跑完、单独执行完第三个，才能去跑第四个。

所以，在 DSH 或 OpenAI SDK 这类成熟的框架里，Loop 已经不再是简单地 run_tools() 了，它内部必须维护一个带并发上限的滚动池，还要根据工具是否有副作用（只读 vs 修改）来做顺序屏障和排队。

2. “不调工具就结束”不再成立

除了调度变复杂，动作的演化还打破了另一条核心假设：模型没有返回 tool_calls，真的就代表任务做完了吗？

在真实的业务里，“结束”分裂成了三层完全不同的含义：

模型层面的结束：模型这次输出没带 tool_calls。
业务层面的结束：用户的需求真的被完整解决了。
系统层面的终止：因为成功、报错、用户手动点击停止、或者触发了最大循环次数上限，Loop 被迫停下了。

这三者在生产环境里经常是错位的：

假性完成：你让 Agent 对比过去三个月的账单，它刚查完第一个月，就偷懒输出了一段分析文字并且不再调用工具了。按照上面那十几行代码的逻辑，if not response.tool_calls: break，循环“正常退出”了！但从业务上看，任务根本没做完。
死循环超限如何收场：反过来，如果模型卡在死循环里，反复用不同参数查同一份账单，直到撞上了系统设定的“最多循环 15 次”的防呆上限，这时候 Loop 该怎么停？
有的框架（如 OpenAI Agents SDK）选择把超限当成系统异常，直接报错中断；
而有的产品（如 OpenCode）则认为半成品对用户也有价值：当达到第 15 步时，Loop 不再允许模型调工具，而是偷偷往历史里塞一句系统指令——“你的步数额度已用完，请立刻基于目前已查到的信息，向用户总结已完成的进展和尚未完成的部分”——让模型体面地交卷。

到底该报错中断，还是该体面总结？这取决于你的业务场景：写代码、查资料，给个阶段性总结很有用；但如果是银行转账、改套餐，做了一半假装总结交卷就是重大事故。所以“怎么停下来”根本不是一个固定的算法，而是 Loop 必须向外暴露的产品策略接口。

三、推理模型的出现：Loop 得替模型保管“看不懂的黑盒”

原型里的第二条假设是“模型的思考过程只是普通文字”。在早期 ReAct 里确实如此，Thought 就是写在提示词里的一行字，开发者的框架可以随便对历史消息做裁剪、清理或格式转换。

但自从 OpenAI o1、Claude 3.7/4、DeepSeek-R1 等推理模型（Reasoning Models）普及后，这条假设彻底失效了，而且失效的方式极其隐蔽。

为什么不能再丢掉模型的“思考过程”？

以前推理模型只在回答最终问题前思考一次。但现在的推理模型支持“交错思考（Interleaved Thinking）”——也就是模型在“调第一个工具 -> 看结果 -> 调第二个工具”的每一步之间，都在进行深度的内部推理。

为了防止用户伪造或篡改模型的思考过程，各家模型厂商对“思考状态”做了严格的校验设计：

Anthropic (Claude) 规定：它的 API 本身不在服务端存状态。当开启扩展思考并调用工具时，客户端在发起下一轮请求时，必须把模型上一轮输出的 thinking 数据块（里面包含了一段由 Anthropic 私钥加密的 signature 签名）原封不动、一字不差地传回去。如果你漏传了，或者顺手改了一个字符，API 直接返回 400 报错。
OpenAI (Responses API) 则选择把加密的推理状态保存在服务端（通过 ID 引用）或要求客户端原样带回。OpenAI 官方做过对比测试：同样是 GPT-5，保留多步之间的推理状态，比每次丢掉推理状态（传统的 Chat Completions 接法），在复杂任务基准 TAUBench 上的得分直接高出 5%。

评测与生产中最隐蔽的坑：“静默降级”

Anthropic 直接报 400 错误其实还算仁慈，因为它逼着开发者必须把状态接对。最可怕的是很多开源推理模型（如 DeepSeek、Qwen、MiniMax 等）以及第三方 API 网关的接入现状。

很多开发者的 Agent 框架沿用了两年前的代码，在组装下一轮消息时，只提取了模型的回复正文（content）和工具调用（tool_calls），把模型返回的思考过程字段（有的叫 reasoning_content，有的叫 reasoning）随手就扔掉了。

最要命的是：扔掉之后，程序完全不会报错，请求照常成功，模型也照样能回答，唯一的后果是模型悄悄变笨了！为什么？因为当模型在进行第 5 步推理时，它回头看前 4 步的历史记录，发现里面的 <think></think> 标签全都是空的。模型看到的假象是：“我前面四步居然连想都没想，就瞎调了一通工具”，这严重偏离了它训练时的数据分布，导致后续推理质量断崖式下跌。

2025 年底 MiniMax 官方就曾专门发文提醒开发者，很多接入方因为没正确回传多轮思考内容，导致 M2 模型表现大幅受损；而按照规范把每一轮的思考状态完整传回去之后，模型效果最多能提升 35%。

这对 Loop 工程提出了一个全新的要求：Loop 和底层模型之间多了一层隐性耦合。 Loop 不能再把历史消息当成普通字符串随意清理或改写了。在 DSH 的源码里，每条助手消息都会附带一个私有的 replayState 字段并写入持久化日志——Loop 自己并不去解读这段数据，但它必须像保管黑盒一样，替模型原原本本地存盘，并在下一轮原封不动地还给模型。

四、控制权的钟摆：下一步到底听谁的？

原型里的第三条假设前半句是：“下一步做什么，完全由模型决定”。但过去四年里，工业界在这个问题上经历了一次非常有意思的“钟摆运动”：

第一阶段（嫌模型太笨，靠外力补救）：2023 年前后，大家发现模型直接跑 ReAct 容易迷失方向或漏掉步骤，于是发明了各种外挂算法——比如失败了让模型写段自我反思重跑一遍的（Reflexion），或者先让一个规划器（Planner）写出完整步骤图、再让执行器照着跑的（Plan-and-Execute）。
第二阶段（收回控制权，开发者画图）：2024 年初 LangGraph 大火。大家觉得不能让模型自由发挥了，干脆由程序员用状态图（Graph）把每一步的跳转逻辑画死，模型只允许在固定的节点内部干活。
第三阶段（推理模型崛起，重回“薄 Loop”）：到了今天，你会发现像 Claude Code、Codex CLI、DSH 这类顶尖的 Coding Agent，它们的 Loop 又变回了极其简单的形态，没有复杂的图编排，也没有外部 Planner。为什么？因为推理模型把“规划、分解任务、自我检查和纠错”内化到了自己的思考过程（Thinking）里，原本属于外部编排框架的活，被模型能力本身吸收了。

那这是不是意味着工作流编排（Workflow）彻底没用了？并不是，这取决于业务犯错的代价。在写代码、搜资料这种场景下，探索错了可以撤回重来，把控制权完全交给模型（薄 Loop）能获得最大的上限和灵活性；但在金融退费、电信改套餐这种强监管流程里，步骤顺序和审批要求是铁律，控制权绝不能交给模型，必须由确定性的工作流（Workflow）来主导，模型只负责在具体节点里做意图理解。

内层 Loop 与外层多 Agent 协同

所以，我不喜欢把“单 Agent 循环”和“多 Agent 编排”当成两个割裂的领域，它们本质上都是执行控制（Execution Control），只是处于不同的层级：

内层控制：管的是单个 Agent 内部一步接一步（Step & Turn）怎么推进、怎么终止。
外层控制：管的是多个 Agent 之间的控制权怎么交接。常见的无非三种模式：

把子 Agent 当工具用：主 Agent 派活并原地等待，子 Agent 跑完把结果当工具返回值交回来，控制权一直在主 Agent 手里。
控制权移交（Handoff）：像客服转接专员一样，主 Agent 把会话彻底交给另一个 Agent，自己退下。
异步后台委派：主 Agent 派出几个后台子 Agent 去跑长耗时任务，自己继续跟用户聊天；子 Agent 跑完后通过发通知把结果送进收件箱。

想清楚这两层的边界，架构就会非常清爽：外层负责搭架子和派活，内层每个 Agent 依然只跑自己那个最简单、最薄的 Loop。

五、循环的开放：用户随时会插话，机器随时会重启

原型的最后两条假设是：“运行期间外界不会插手”和“所有状态都在内存里”。在玩具 Demo 里这没问题，但在真实的产品里，这两条几乎从不成立。

1. 当用户在 Agent 干活时中途插话

真实场景下，Agent 执行一个复杂任务可能要跑三五分钟，连续调用十几次工具。这时候用户看着屏幕上的进度，随时可能插手：

用户发现它方向偏了，立刻发一句：“别查三个月了，只看最近两个月！”——这要求立刻纠偏（Steer），改变当前正在跑的任务方向。
用户突然想起一件事，发一句：“等查完账单，顺便帮我导出成 Excel。”——这要求排队（Queue / Followup），等当前这轮任务彻底跑完了，再作为下一轮任务启动。
用户顺嘴问一句：“顺便问下，你们客服电话是多少？”——这是旁路提问（如 Claude Code 的 /btw），要求并行回答，而且绝对不能污染当前主任务的上下文历史。

一旦允许中途插话，Loop 就不能再是个闷头狂奔的 while 循环了，它必须在每一轮之间设立严格的收件箱（Inbox）与安全接纳边界。

为什么叫“安全边界”？假设 Agent 正在执行一个耗时 2 分钟的数据库查询工具，第 10 秒的时候用户发来了一句“只看最近两个月”的纠偏指令。Loop 绝对不能在第 10 秒强行把这句话塞进历史消息里——因为此时上一个工具请求已经发出去且还没返回结果，强行插入一条用户消息会直接破坏大模型 API 要求的“助手调用工具 -> 工具返回结果”的成对消息结构，导致接口报错。正确的做法是：用户的纠偏指令先进入收件箱排队，等这 2 分钟的工具执行完毕、结果写回历史之后、在发起下一次模型请求之前的那个安全缝隙（Pre-step），Loop 才从收件箱里把用户的纠偏指令认领出来，正式带入下一轮推理。

2. 状态外置：区分“给模型看的上下文”和“系统的执行事实”

如果一个工具调用需要等待主管人工审批（可能明天才点同意），或者服务器在运行中途突然重启，靠内存里的 history 数组就全完了。所以现代 Agent 必须把状态外置到持久化的事件日志（Session Log）里。

在这里，工程上必须严格区分两种完全不同的状态：

模型可见上下文（Context）：这是为了发给模型做下一次推理而组装出来的消息列表。当对话太长时，它可以被裁剪、被替换、被压缩成摘要。
权威执行事实（Execution State）：这是系统底层记录的“哪个工具在什么时间被调用了、是否成功、用户审批过了什么”的铁证日志。上下文可以被压缩，但执行事实绝对不能被压缩抹掉！

举个崩溃恢复的例子你就明白了：假设 Agent 调了一个“向客户退款 100 元”的接口，请求刚发出去，还没等银行接口返回结果，Agent 所在的服务器断电重启了。等服务器重启恢复这个会话时，Loop 查了一下持久化日志，发现只有“工具调用开始”的记录，没有“工具执行结果”的记录。这时候 Loop 该怎么办？能自动重新调一次退款接口吗？绝对不能，否则可能造成重复退款！

在 DSH 的恢复机制里，遇到这种情况，系统不会重跑工具，而是会自动补一条状态为 TOOL_OUTCOME_UNKNOWN（结果未知） 的记录交给模型，并附带系统说明：“上次执行在此处中断，结果未知。如果是只读或幂等操作你可以重试；如果是会产生副作用的修改操作，请先调用查询工具核实外部状态，或直接询问用户。”

你看，让系统诚实地承认“我不知道刚才那步成没成功”，这就是 Loop 对外契约的一部分。

六、为什么说“细节全是魔鬼”？看三个边界踩坑反例

前面讲了这么多边界和契约，如果不遵守会怎样？我们看三个真实工程里最容易踩坑的场景，就能明白为什么简单的 while 循环应付不了生产环境：

反例一：挂错位置的“防死循环钩子”

为了防止模型陷入无限调用工具的死循环，我们需要加一个最大步数限制。在 DSH 的文档里曾建议开发者：可以把限制逻辑挂在 turn-stopping（本轮即将结束）这个扩展钩子上。但如果你去翻它的源码，会发现一个哭笑不得的 Bug：turn-stopping 这个事件，只有在“模型本步没有调用工具，准备自然停下”的时候才会被触发！如果模型真的疯了，每一步都在疯狂调用工具，它就永远不会进入“准备停下”的状态，你挂在那里的防死循环钩子也就永远不会被执行。真正的硬性步数上限，必须挂在每一步开始前必然经过的 pre-step 钩子上。差一个挂载位置，防线就形同虚设。

反例二：当“用户中途纠偏（Steer）”撞上“上下文自动压缩”

假设 Agent 正在分析过去三个月的账单，历史消息已经快把上下文窗口塞满了。这时候用户发来一句纠偏（Steer）：“别看三个月了，只看最近两个月！” 恰巧在同一时刻，系统检测到上下文超长，触发了自动压缩（把前面的历史对话总结成一段简短的摘要）。

如果 Loop 的时序契约没设计好，会发生什么？

时序错乱：如果先收了用户的纠偏消息写进历史，紧接着触发压缩，这句最新的纠偏指令就会被和旧历史一起揉进摘要里，力度被大大稀释。正确的顺序必须是：先从收件箱认领纠偏指令暂存 -> 仅对已有的旧历史做压缩生成摘要 -> 把用户的纠偏指令作为最新的一条消息，追加在摘要的后面。
语义覆盖：做压缩摘要的模型在总结旧历史时，并不知道外面刚刚来了一条纠偏指令，所以它生成的摘要里依然写着“当前任务：分析三个月账单”，后面紧跟着一句用户的“只看最近两个月”。如果下一次再触发压缩，这两句话很可能被合并成一段自相矛盾的描述。这说明上下文压缩组件必须感知到 Steer 指令的“修正语义”，而不是当成普通聊天记录去总结。

反例三：主 Agent 已经交卷了，后台子 Agent 才跑完

假设主 Agent 派了三个后台子 Agent 去查三个不同渠道的数据。前两个很快查完回来了，第三个因为网络卡住了一直没动静。主 Agent 等不及了，觉得前两个渠道的数据已经够说明问题，就先给用户输出了最终总结，结束了当前这轮对话（Turn）。

结果十分钟后，第三个子 Agent 终于跑完了，尽职尽责地把结果通知送回了主 Agent。在很多框架的默认实现里，收到子 Agent 的完成通知会自动唤醒主 Agent 开启新一轮推理。于是用户就会在界面上看到诡异的一幕：一个十分钟前就已经显示“回答完毕”的对话框，突然自己“诈尸”又开始输出了！这到底算是贴心的补充，还是莫名其妙的打扰？内层的 while 循环根本回答不了这个问题。这揭示了“前台对话轮次的结束”和“后台任务生命周期的结束”是两个维度的状态，必须由外层的控制策略和前端 UI 交互共同设计契约来解决。

七、结语：Agent 工程的五大版图与“薄 Loop，厚契约”

聊到这里，我们就可以跳出代码细节，给整个 Agent 工程画一张清晰的全景图了。在我看来，一个生产级的 Agent 系统，其实是由五个职责分明的工程领域拼起来的：

工程领域	核心解决的问题	主要包含的内容
1. 行为工程	Agent 应该怎样思考和说话？	Prompt 架构、Skills（技能包）、角色设定、行为规范与约束

| | 2. 上下文工程 | 每次请求时，模型能看到什么？ | 历史消息投影、记忆提取、RAG、动态注入、上下文压缩、KV 缓存复用

| | 3. 工具工程 | Agent 的手脚能做什么？ | 工具 Schema 设计、并发调度管线、权限审批、沙箱隔离、错误返回语义

| | 4. 执行控制工程 | 下一步谁决定？何时停？控制权怎么交接？ | 内层：Step/Turn 状态机、终止策略、插话接纳边界、生命周期钩子

外层：子 Agent 委派、Handoff 移交、并行与确定性 Workflow
| | 5. 运行时工程 | Agent 如何跨时间、跨进程可靠地活着？ | Session 持久化日志、收件箱队列、分布式锁与租约、崩溃尾部修复、预算计量

(注：在这五个垂直领域之下，可观测性、评测体系和安全审计则作为横向底座贯穿全局。)

现在，我们可以回答文章最开头的那个问题了：为什么区区十几行的 ReAct 循环，值得被做成插件、定义成一套公开协议？

因为在过去四年里，大模型能力的飞跃，正在把规划、反思、多步推理不断吸收进模型内部，这让 Loop 本身的算法实现变得越来越薄；但与此同时，为了把 Agent 放进真实世界，应对中途打断、推理状态保真、崩溃恢复和多智能体协同，所有的工程复杂度都被推到了循环的边界上，让 Loop 对外承诺的契约变得越来越厚。

薄的东西，才值得被灵活替换；厚的契约，才值得被写成标准协议。

所以，今天我们谈 Agent Loop 工程，早就不是在讨论怎么写那个 while 循环了。它的真正定义是：去设计并守护一套控制契约，让模型在自由推理的同时，整个执行过程依然是可观察、可干预、可恢复的。

把内核做薄，把契约做厚——这就是从玩具 Demo 走向生产级 Agent 架构的必经之路。

参考与延伸阅读： 本文关于演进脉络与架构细节的讨论，参考了 ReAct (2022)、CodeAct (2024) 等经典论文，OpenAI Responses API、Anthropic Extended Thinking、MiniMax M2 等官方技术文档，以及 DeepSeek Harness (DSH)、OpenCode、OpenAI Agents SDK、Pydantic AI 等开源项目的最新源码与规范。