智能体控制回路

智能体经常被画成一个简单的循环：观察、思考、行动，然后重复。这个示意图抓住了反馈机制，却隐藏了几乎所有决定系统是否可控的工程责任。

由谁决定模型可以观察什么？一个行动改变外部世界之前，由谁检查它是否允许执行？工具调用超时后，哪一份状态才是事实依据？如何区分有价值的迭代与只消耗 token、没有取得进展的循环？又由谁判断任务已经完成，这个判断依据什么证据？

这些责任不属于提示词，而属于模型外围的运行系统。模型可以在允许的行动中选择路线，但应用代码仍然必须负责运行过程的生命周期、可接受的状态转换、已经提交的状态、资源限制和行动后果。

本章定义的就是这套外围结构。它以“基础”部分已经建立的工作流与智能体边界、委托配置为前提，不会重新划分自主性，也不会规定规划方法、工具实现或记忆实现。本章的问题更具体：

当模型已经获得一部分行动路线的决策权时，系统应当如何以有边界、可观察、可恢复的方式逐步执行这些决策？

核心论点

智能体控制回路应当是由确定性运行框架负责的显式状态转换系统，而不是让模型反复提示自己，直到它声称任务已经完成。

在每一步中，运行框架应当：

读取目标、作为事实依据的任务状态和当前运行状态；
为下一次决策组装有明确边界的观察信息；
接收模型提出的行动或生命周期转换；
根据数据结构、权限、前置条件和资源限制验证这项提议；
执行通过验证的行动，并记录实际结果；
更新作为事实依据的状态，评估与任务相关的进展；
通过显式状态转换决定继续、等待、升级处理、失败、取消、到期或成功。

模型可以提出 finish，但应由运行框架根据已有证据判断任务是否满足成功条件。模型可以建议重试，但应由运行框架判断是否还允许再次尝试，以及相关条件是否发生了实质变化。最大轮数可以防止资源无限消耗，却不能把未完成的任务变成成功任务。

这样的职责分离保留了智能体真正有价值的能力——根据反馈调整行动路线，同时不把环境事实、行动权限或完成标准交给概率性组件决定。

问题

一次性模型功能的生命周期很短：构造输入、调用模型、验证输出，然后返回。智能体子系统则可能进行数量取决于输入的模型调用和行动，而且每个结果都会改变下一次决策需要看到的信息。

这个循环会跨越多个边界：

模型输出变成对应用代码的行动请求；
应用代码调用工具或改变外部环境；
环境返回数据、错误，或者结果不明确的部分执行状态；
这些结果成为下一次模型决策的上下文；
系统最终声称成功、失败，或者无法继续。

行业资料普遍把这个循环视为智能体的核心。Anthropic 将智能体描述为在循环中根据环境反馈使用工具的模型（Anthropic，2024）。OpenAI 将一次运行描述为持续执行、直到满足退出条件的循环（OpenAI，“A practical guide to building agents”）。ReAct 则展示了把任务推理与行动交错进行的价值，使后续决策能够利用外部环境返回的信息（Yao 等，2023）。

但“不断调用工具，直到模型不再发出工具调用”只是一个 API 层面的循环，并没有回答下面这些架构问题：

工具返回了 HTTP 200，但预期状态是否真的发生了变化？
写操作超时了，服务器究竟有没有提交？
模型生成了最终回答，但用户要求的产物是否真的创建完成？
验证器拒绝了结果，再修复一次是否有可能增加新的信息？
子智能体停止了，但它是成功、失败，还是仅仅耗尽了预算？
用户在行动执行期间取消任务，现在外部系统究竟处于什么状态？

如果系统无法表达这些差异，它看似灵活的行为就建立在隐藏且往往不安全的假设之上。

心智模型：由运行框架负责控制回路

早在大语言模型智能体出现之前，自主计算领域就已经把监控、分析、规划、执行、共享知识、传感器和执行器分开。IBM 的 MAPE-K 架构为区分环境观察、行动接口与决策组件提供了一个有价值的先例（IBM Research，2004）。

大语言模型智能体并不是经典反馈控制器，这个类比也不能保证系统稳定或收敛。它的价值在于帮助我们分离责任：

目标 + 作为事实依据的状态 + 限制
                 │
                 ▼
 观察 → 提议 → 验证 → 执行 → 记录与更新 → 核验
  ▲                                           │
  └── 继续 / 等待 / 升级 / 失败 / 停止 ───────┘

运行框架（harness） 是负责这个循环的确定性软件。它可以是应用代码、智能体框架、工作流引擎，也可以由多个相互协作的服务组成。这里的“确定性”并不表示所有下游服务都能按预期工作，而是指接受状态转换、提交状态、执行限制和记录实际过程的规则位于模型解释之外。

有些模型运行时会在一次 API 调用内部完成推理或多项由服务管理的操作，因此应用看到的控制回路可能粒度更粗。但外部契约仍然存在：会产生重要后果的操作必须经过可强制执行的接口；调用需要具备服务实际支持的限制与取消语义；返回状态和证据必须能够映射到应用自己的运行状态。对于模型服务没有暴露的内部决策，系统不应声称自己具备逐步观察能力。

下面六项责任不一定要分别实现成六个进程或函数，但必须能在系统设计和追踪记录中区分出来。

1. 观察

控制回路读取目标、当前任务状态、上一次行动结果、新的用户或环境事件、尚未完成的审批和剩余资源，然后为下一次决策构造合适的观察信息（observation）。

观察信息只是对环境的表示，并不等同于环境本身。它可能不完整、已经过时、格式错误，甚至包含恶意内容。工具声称“更新成功”是一项证据；随后从事实来源重新读取状态，通常能够提供更强的证据。“上下文组装与管理”将负责选择、来源记录、压缩和信任策略。控制回路在这里负责的是，记录每一次状态转换依据的是哪一个版本的观察信息。

2. 提议

决策组件提出一项有明确类型的状态转换。常见提议包括：

使用指定参数调用某项行动；
向用户询问缺失信息；
等待事件或审批；
调整或放弃当前路线；
创建一个有明确边界的子任务；
报告当前目标受阻或无法完成；
把任务升级给其他责任主体处理；
声明本次运行已经可以结束。

提议可以来自模型，也可以来自确定性代码。固定的验证错误不需要为了选择已知的错误处理路径而再次调用模型。相反，如果工具结果在语义上存在歧义，就可能需要把决策权重新交给模型。

追踪记录需要保存转换提议和与决策有关的记录，而不是模型内部的私有思维链。模型使用了哪些输入、请求什么行动、系统进行了哪些检查、观察到了什么结果，这些都是运行事实。模型后来生成的推理解释不能作为权威内部状态。

3. 验证

行动或生命周期转换被接受之前，运行框架应当在模型判断之外完成所有可以可靠执行的检查：

提议的数据结构是否合法；
当前状态下是否存在且允许使用这项行动；
参数是否符合约定的接口契约；
当前身份和授权是否允许执行；
必要的审批和前置条件是否已经满足；
时间、资源和步骤预算是否允许继续；
操作是否符合取消与重试策略；
当前运行状态是否允许发生这项转换。

验证可以拒绝、规范化、暂存、要求审批或接受一项提议。后续《能力、权限与执行边界》章节负责讨论执行约定和权限边界。本章关心的是，验证必须成为状态转换的正式关口，而不是写在提示词里的可选建议。

4. 执行

执行组件通过有明确边界的接口完成已经接受的行动。行动结果至少应当区分：

已确认成功，并返回相应证据；
已确认被拒绝或执行失败；
部分成功；
超时或中断，外部结果未知；
返回结果无效或不可信。

如果把这些情况全部压成一段文本，安全继续执行所需的信息就会丢失。一次写操作超时且结果未知，并不等同于执行失败；盲目重试可能造成重复的外部效果。“生产工程”将讨论幂等、补偿、检查点和分布式恢复。在架构层面，控制回路必须保留结果的语义，不能让模型靠猜测决定下一步。

5. 记录与更新

运行框架记录已经接受的状态转换、行动尝试、时间、相关配置、执行结果和新的运行状态。只有符合行动提交规则时，它才更新作为事实依据的任务状态。

对话记录并不足以承担这个责任。对话记录是为模型交互组织的输入历史，不一定能准确表示订单是否已经修改、文件是否已经写入、审批是否通过、预算消耗多少，以及还有哪些工作没有完成。“状态与记忆”章节将定义存储方式和有效性规则。对控制回路而言，最低要求是能够重新加载继续运行所需的事实，而不是让模型从自然语言中重建事实。

6. 核验并决定

一项行动完成后，系统需要分别回答两个问题：

实际发生了什么变化？
这个变化是否足以支持继续、等待、改变路线或进入终止状态？

工具调用成功不一定意味着任务取得进展，取得进展也不等于任务已经完成。下载十份文档可能增加了证据，也可能只增加重复内容或干扰信息。测试失败仍然可能提供有价值的新信息。再生成一版草稿也可能只是消耗资源，质量没有变化。

因此，验证器需要根据与风险相匹配的证据判断一项明确条件，运行框架再接受一项合法状态转换。模型可以参与这两个判断，但不能把它们悄悄合并为一句“任务已经完成”。

一次运行是状态机，不是一次对话

一次运行（run），是系统在已记录的配置、环境和限制下，尝试实现一个明确目标的完整过程。它可以包含多次模型调用、确定性状态转换、工具行动、暂停或子任务运行。

运行时至少应当区分以下状态，或者含义等价的本地状态：

状态	含义	必须保留的信息
已创建（created）	目标已经存在，但尚未开始执行。	目标、请求者、初始范围、配置和限制。
运行中（running）	运行框架可以选择并执行下一项状态转换。	当前任务状态、正在执行的步骤、剩余限制和取消信号。
等待中（waiting）	进展依赖预期事件、时间、回复或审批。	等待对象、截止时间、订阅或恢复条件和负责人。
受阻（blocked）	当前控制边界内无法继续负责任地推进任务。	受阻原因、已有证据、尝试过的路线和可能的升级方式。
成功（succeeded）	系统已经接受与任务相匹配的成功证据。	结果、验证结果、已提交效果和剩余限制。
失败（failed）	因明确且无法恢复的条件而结束，未达到成功状态。	失败类别、最后已知状态、已经提交的效果和恢复选项。
已取消（cancelled）	有权限的责任主体要求终止任务。	请求者、取消时间、执行中行动的状态和清理结果。
已到期（expired）	因截止时间、步骤、token、成本或其他硬性限制而停止。	触发的限制、部分结果、已经提交的效果和是否允许恢复。
已升级（escalated）	责任已经转移给人、工作流或另一个有明确边界的子系统。	接收方、原因、移交的上下文与状态，以及责任确认。

waiting 和 blocked 可以是暂停状态，而不是终止状态。关键是明确它们的语义。等待用户提供文档的运行不应显示为失败；无法推进的运行不应继续显示“运行中”；耗尽 token 限制的运行也不应因为生成了一份措辞流畅的总结就显示为成功。

具体状态名称不如合法状态转换重要。例如，已经取消的运行不应在未经重新授权的情况下继续提交排队中的行动；失败的子任务不能仅因为返回了文本就被父任务当作成功；等待中的任务恢复时应使用持久保存的状态，而不是依赖可能遗漏未决外部效果的临时总结。

完成任务需要证据

许多智能体 API 会在模型返回一条不再包含工具调用的消息时停止。这可以作为有用的协议层退出条件，但不能作为任务成功的通用定义。

完成证据可以采用多种形式：

确定性状态条件：要求的记录已经存在、字段符合约束，或者预期状态转换已经确认。
可执行检查：测试通过、查询结果满足预期不变量，或者生成的产物可以解析和运行。
独立的环境观察：系统重新读取行动影响的外部状态。
人工验收：有权限的人审查实际结果，并对接受决定负责。
模型评估：经过校准的评估器判断低成本检查无法表达的语义条件。

这些证据可以组合使用。会产生重要后果的行动通常需要比建议性草稿更强的证据。如果无法以合理成本建立独立验证，系统可以返回有明确边界的结果，同时列出证据、未解决问题和需要人工判断的部分，但不能用流畅表达悄悄代替证明。

τ-bench 通过比较对话结束后的数据库状态与预先标注的目标状态来评估工具型智能体，并用重复试验衡量可靠性。其初始实验表明，看似合理的交互并不能保证环境结果正确且一致（Yao 等，2024）。具体基准结果不能直接推广到所有系统，但它采用的评估边界值得借鉴：核验任务环境中真正发生了什么，而不只是检查智能体说了什么。

自我批评不等于外部反馈

追问同一个模型“你确定吗？”有时会改变答案，但没有增加新的证据。ICLR 2024 的研究发现，在没有外部反馈的推理任务中，通过提示触发的内在自我纠正常常无效，甚至会降低准确率（Huang 等，2024）。相比之下，CRITIC 在其评估任务中引入工具和外部来源提供的反馈后取得了改进（Gou 等，2024）。

这两项结果都不能成为适用于更新模型的普遍定律，但共同支持一个长期有效的区分：

再调用一次模型可以修改提议；只有新的信息或经过独立评估的信息，才能增强证据。

模型评估器仍然可能是合理的选择，但它是存在误报、漏报、配置敏感性和成本的测量工具，不是确定性判定器。

停止条件也是正确性的一部分

控制回路既需要说明任务为何停止的条件，也需要防止失控执行的硬性安全上限。

前一类条件包括：

成功证据已经满足目标；
无法恢复的失败使当前范围内的目标不可能实现；
所需信息或权限不可获得；
下一项重要行动需要审批或由其他责任主体处理；
用户取消或改变了目标；
根据明确策略，继续执行的预期收益已经低于成本与风险。

硬性安全上限包括：

最大步骤数或模型调用次数；
token、成本、工具调用或子任务预算；
最长运行时间或空闲超时；
按失败类型设定的最大重试次数；
递归或委托深度；
连续无进展状态转换次数；
可能产生外部效果的重复行动次数。

达到安全上限后，应根据约定进入 expired、blocked、failed 或 escalated，而不是进入 succeeded。

检测进展，而不只是检测活动

无进展检测应当比较不同步骤之间与任务有关的状态或证据。只检查工具名称是否重复过于粗糙，因为轮询、分页、迭代搜索和重复试验可能本来就是合理行为。反过来，一个循环也可能不断切换不同工具，却一直绕圈，没有改变任务状态。

有用的信号包括：

尚未满足的成功条件没有发生变化；
同一类失败反复出现，而输入、权限或策略都没有改变；
新的观察信息没有增加实质内容；
规范化后的行动与状态组合形成循环；
验证分数下降，或者测试失败没有变化；
继续一步的资源消耗已经超过其预期价值；
子任务反复返回同一个未解决的依赖问题。

这些只是检测信号，不是通用证明。在强制终止之前，它们可以触发重新规划、更换工具、请求信息或升级处理。

一篇近期预印本分析了 6,549 个公开智能体代码仓库，报告在其中 47 个项目中人工确认了 68 个实际上没有有效边界的智能体循环。该研究过于新，尚不能视为定论，但它提供了具体证据：框架引入的反馈路径和嵌套循环可能反复触发高成本或改变状态的操作，因此必须显式设置边界（Hou 等，2026）。

反馈质量决定控制回路能否有效工作

智能体只能根据接口允许它观察到的信息进行调整。SWE-agent 的研究表明，即使模型保持不变，改变智能体与计算机之间的接口也会显著影响软件工程任务表现（Yang 等，2024）。这里更一般的结论并不是每个智能体都需要专门设计的命令行，而是观察接口和行动接口本身就是推理系统的一部分。

良好的反馈应当：

有足够明确的类型，能够区分不同结果；
足够具体，能够支持下一次决策发生变化；
有明确边界，不会淹没下一次模型调用的上下文；
能够关联到产生它的行动和状态版本；
如实表达不确定性和部分执行效果；
与返回内容中可能存在的不可信指令分开。

错误信息应告诉控制回路接下来可以采取什么类型的响应。invalid_argument 表示应修改行动提议；permission_denied 表示应改变权限或升级处理，而不是重试；rate_limited 可能意味着需要等待；timeout_unknown_outcome 则要求再次写入前先核实外部状态。只返回一句“出了问题”，会迫使模型从自然语言中猜测生命周期语义。

常见控制回路形式

同一套生命周期可以支持多种控制结构。

直接行动回路

模型观察当前状态，提出一项行动，收到结果，然后再次选择。它适合下一步高度依赖最新反馈，而且每项行动都有明确边界的任务。

主要成本是模型调用次数。如果若干确定性操作总是一起发生，应将它们实现为一项由代码定义的行动或工作流，而不是要求模型每次重新发现这套固定顺序。

由计划辅助的控制回路

系统保留显式计划或任务清单，但每一步仍然使用最新观察信息，也可以调整路线。除非计划中的某些事项已经写入作为事实依据的状态，否则计划只是一项建议。

这种方式可以提高可理解性，也更容易发现遗漏，但环境改变后，过时计划也可能限制模型。“规划与任务分解”章节将进一步讨论规划何时值得引入。

验证—修复回路

系统先生成产物，然后验证明确条件，并只在证据表明存在缺陷时进行修复。固定的“评估器—优化器”工作流也可能使用相同形式，而不一定属于智能体。

验证器和修复器都可能产生错误。控制回路需要保留当前已知的最佳结果、限制修复次数，并防止较弱的验证器仅仅因为还剩下一轮，就用更差的产物替换更好的结果。

有明确边界的子任务运行

父任务向子任务委托限定的目标、工具、状态视图、预算和返回契约。子任务返回结构化终止状态和证据，而不只是返回一段消息。

嵌套循环会放大资源上限：父任务允许 5 个步骤，每步最多创建 5 个子任务，每个子任务允许 10 个步骤，在计算重试之前就可能授权 250 个子任务步骤。“多智能体系统”章节将负责协调结构；控制回路在这里需要保证预算、取消和失败能够跨边界传递。

可暂停的事件驱动回路

系统持久保存状态，在等待期间不反复调用模型，并在事件、时间、用户回复或审批到达时恢复。等待不等于“思考”，也不应让模型通过反复轮询自己来模拟时间流逝。

可靠的持久化和恢复属于“生产工程”。在架构层面，控制回路需要显式的等待状态和由确定性机制触发的恢复条件。

设计权衡

细粒度行动与粗粒度行动

细粒度行动能够提供更多检查点、证据和控制，但也会增加模型调用、上下文增长、延迟和执行顺序不一致的机会。粗粒度行动可以减少编排成本，却可能隐藏中间效果，使取消和恢复更加困难。

应围绕真正重要的决策和后果选择行动粒度。一个数据库事务可以是一项有明确边界的行动；一次开放式研究不应仅仅为了让架构图更简单，就被包装成不透明的单次工具调用。

立即执行与暂存执行

立即执行每项通过验证的提议可以降低延迟。暂存则允许系统在正式提交前完成验证、预览、审批、批处理和取消。正确选择取决于行动权限、可逆性和后果，而不是仅仅取决于模型的置信度。

完整对话记录与状态视图

传入完整历史实现简单，也能保留细节，但会把过时状态、不可信内容、失败尝试和对话残留混合在一起。专门构造的状态视图更有针对性、效率更高，却可能遗漏下一次决策所需的事实。“上下文组装与管理”章节将详细讨论这一权衡；无论采用哪种方式，控制回路都应保留原始记录。

集中控制与嵌套控制

单一控制回路更容易看清预算、状态和停止条件。嵌套循环可以隔离专业能力或上下文，也可以并行执行，但会增加生命周期状态、隐藏重试和部分失败。只有当子任务的边界比把决策留在本地更清晰时，才应增加子控制回路。

高频验证与关键节点验证

每一步都验证可以更早发现错误，却可能让成本和延迟主要消耗在验证上。只在最后验证，则可能让早期错误影响很长的执行过程。应在不可逆行动之前、外部效果不确定之后、阶段边界和任务声称完成时设置强验证，在其他位置使用成本更低的进展信号。

失效模式

由模型决定事实

系统把模型生成的总结当作当前任务状态。早期错误会变成“事实”，后续步骤也无法区分模型声明与已经提交的外部效果。应把作为事实依据的状态和环境证据保存在模型文本之外。

最终回答等于成功

模型不再调用工具，运行框架便把任务标记为完成，但用户要求的记录、产物或环境状态可能仍不存在。应把 finish 当作转换提议，并验证与任务相匹配的结果。

用对话记录充当状态机

系统根据最后几条消息推断生命周期。经过上下文压缩或进程重启后，取消、部分写入、待审批事项和已耗尽预算都会变得含糊。应显式保存运行状态和步骤状态。

没有新条件的重试

在参数、权限和环境都没有变化的情况下，同一行动因同一原因反复失败。成本不断增加，成功概率却没有实质变化。再次尝试之前，应要求条件发生变化、采用有边界的退避、改用其他策略或升级处理。

把最大步骤数当作完成规则

运行达到上限后，系统返回当前最佳回答并报告成功，把安全制动器误当成了完成证据。此时应如实返回已到期或部分完成状态，并列出尚未解决的工作。

把工具结果压成文本

成功、拒绝、部分执行和结果未知都变成下一条提示词中的字符串。模型只能猜测是否应该重试，可能造成重复外部效果。应在整个控制回路中保留有明确类型的结果语义。

把自我批评当作验证

模型重述或修改自己的回答，系统就把它当作独立验证。应尽可能使用外部检查，并把模型评估器视为需要校准的非确定性测量工具。

隐藏的嵌套循环

工具、智能体、评估器和任务移交都有自己的重试机制，父任务却只看到一次调用。系统应汇总预算，并向父任务暴露子任务状态、取消结果和已经提交的效果。

无法中断的行动链

系统只在一长串外部操作结束后检查取消信号。界面显示“已停止”，后台工作却还在继续。必须定义取消检查点、执行中行动的语义和后续核对要求。

把活动当作进展

更多搜索、更长的追踪记录和更多智能体制造了明显的忙碌感，却没有减少尚未满足的成功条件。应追踪与任务有关的状态和证据，而不是把步骤数量本身当作正面指标。

本手册的建议

实现之前，应为每个由模型决定行动路线的子系统编写一份控制回路契约：

契约字段	需要回答的问题
目标	这次运行要实现什么有明确边界的结果，由谁提出？
成功证据	哪些条件、检查、观察或审批足以支持进入 `succeeded`？
事实状态	哪些系统记录被视为当前事实，谁可以更新？
观察信息	每次决策可以看到什么、对应哪个版本，来源和信任状态是什么？
转换提议	模型可以请求哪些行动和生命周期变化？
转换关口	哪些数据结构、前置条件、权限、审批和预算由代码强制执行？
结果语义	如何表示成功、拒绝、部分执行、结果未知和无效响应？
进展	哪些实质状态或证据变化足以支持继续下一步？
运行状态	如何区分运行中、等待、受阻、成功、失败、取消、到期和升级处理？
限制	如何限制步骤、时间、token、成本、重试、递归、子任务和外部效果？
中断	谁可以暂停或取消，系统何时检查信号，执行中的行动如何处理？
升级处理	当前控制边界无法继续时，需要移交哪些证据和责任？
运行记录	保留哪些配置、提议、检查、行动结果、状态版本和验证结果？

可以据此用下面的形式审查一个最小控制回路：

加载作为事实依据的运行状态
处理外部取消、截止时间和恢复事件

当状态允许继续执行时：
    观察信息 = 组装有明确边界的观察信息（状态）
    转换提议 = 选择状态转换（观察信息）
    决定 = 验证（转换提议、状态、权限、限制）

    如果决定要求等待或升级处理：
        保存明确状态并移交责任
        停止本次执行

    结果 = 执行（已经接受的行动）
    状态 = 记录并更新（状态、决定、结果）
    判定 = 核验进展与完成条件（状态）
    状态 = 应用合法状态转换（状态、判定）

返回带有证据的终止状态或暂停状态

真实系统还需要并发控制、持久化、安全和恢复机制，这些超出了这段示意代码的范围。它的作用是明确责任：模型提出转换；运行框架负责验证、记录和改变状态；环境提供证据；验证器判断明确条件。

检查清单

参考资料及其用途

IBM Research，“An architectural approach to autonomic computing” 与 IBM 报告 H-0219 — 为分离监控、决策、共享状态、传感器和执行器提供长期系统工程先例；本章把它作为类比，而不是智能体具有经典控制稳定性的证明。
Yao 等，“ReAct: Synergizing Reasoning and Acting in Language Models” — 原始研究论文，支持在交互式语言模型任务中交错执行行动并利用环境反馈。
Anthropic，“Building effective agents” — Anthropic 工程文章，用于支持根据环境反馈使用工具、设置明确停止条件和采用简单可组合结构。
OpenAI，“A practical guide to building agents” — OpenAI 面向产品与工程的智能体构建文章，用于说明运行循环和退出条件；其中与具体产品有关的示例不被视为通用架构。
Yang 等，“SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering” — 原始研究论文，表明环境接口设计会显著影响智能体行为和任务表现。
Yao 等，“τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains” — 原始研究论文，支持检查环境结果并通过重复试验衡量可靠性，而不只评估对话内容。
Huang 等，“Large Language Models Cannot Self-Correct Reasoning Yet” 与 Gou 等，“CRITIC” — 用于区分没有外部依据的自我批评与获得外部反馈后进行的纠正。
Hou 等，“When Agents Do Not Stop: Uncovering Infinite Agentic Loops in LLM Agents” — 为缺少有效边界的反馈路径提供新近证据的预印本；本章明确把其结论视为有待进一步验证的研究发现。