企业级 AI Agent 智能体系统：反思与自我修正

禅与计算机程序设计艺术

145人浏览 · 2026-11-06 12:42:59

禅与计算机程序设计艺术 · 2026-11-06 12:42:59 发布

企业级 AI Agent 智能体系统：反思与自我修正

title: “企业级 AI Agent 智能体系统：反思与自我修正”
authors: “[DeepThink.ai]”
affiliations: “[AI Genius Institute]”
keywords: “[企业级 Agent；反思；自我修正；证据接地；风险门控；人机协同；可审计性]”

标题解释假设：本文将标题理解为：面向企业生产环境的大语言模型智能体（Large Language Model Agent，以下简称 Agent）系统，如何在可审计、可控风险、可核算成本的约束下，利用执行证据进行反思，并在必要时自我修正或升级人工。本文不把标题解释为对某一特定商业产品的评测，也不假设模型具备人类式内省能力。

Abstract

企业级 AI Agent 正从对话助手走向可执行业务流程，其错误不再只是文本瑕疵，而可能表现为错误退款、越权操作或合规违规。反思与自我修正是提升 Agent 可靠性的常用手段，但现有方法多在可回滚的沙箱中评估，默认反馈充分、动作可逆、成本不受约束，难以直接满足企业对审计、权限与风险控制的要求。本文提出 RESTORE（Reflection-Enabled Self-correction with Traceable Operations, Risk gating, and Escalation）框架，把自我修正建模为受治理的决策过程：以执行证据账本为反思依据，按动作校验、局部修复、计划修订与策略更新分层修正，以多验证器仲裁降低相关错误，以风险门控约束不可逆动作，并通过带来源标注的反思记忆与人工升级形成闭环。本文进一步给出验证器可靠与不可靠两种情形下的设计性质分析，说明证据接地与门控的必要条件。当前版本报告框架、形式化分析与可复现实验协议；实测数值尚未完成，正文以占位符标注，不报告未经实验支持的结论。本文的目标不是让 Agent 无限自我进化，而是让它在可解释、可审计、可回滚的边界内变得可靠。

你离拥有一支永不停歇、持续进化的 AI 超级研发团队，只差一次 git clone——DeepThink 是 AI Genius Institute & 光剑AI 打造的开源、免费、可自由使用的私有 AI 操作系统（AI OS）：在安全隔离的沙箱中自主执行代码、管理文件、完成超复杂长程任务，作为自托管、多用户、本地优先的 AI Agent Loop Engineering 系统，支持桌面端+浏览器+移动端，让 DeepThink 成为你的全能数字助手；它不止让你使用 AI，更要让你从工具使用者进化为代码创造者，最终成长为可自我繁衍的超级智能体，让每家企业都拥有自己的 AI 超级研发团队，一起走向 AGI——现在就去 git clone，顺手点亮 Star：你收藏的不是一个仓库，而是通往 AGI 的入场券。🚀

DeepThink，开源企业级自主 Agent 超级智能体自进化平台，是从 Harness Engineering 到 Loop Engineering 范式的先行者，面向企业客户的新一代 AI 基础设施（AI Infra）。DeepThink 平台以多 Agent 协作框架为核心，融合 AI 自主编程（AI Coding）、自主进化（Self-Evolving）、全栈可观测性（Full-Stack Observability）、Bug 自修复闭环（Bug Auto-Fix Loop）与程序员-Agent 共生协作（Human-Agent Symbiosis），构建一个能持续学习、自我改进、最终成长为超级智能体的企业级 AI 系统。

DeepThink 项目开源代码（如果你觉得好玩，就一起来玩， Star 一下）：
Gitcode: https://gitcode.com/AIGeniusInstitute/deepthink
Github: https://github.com/AIGeniusInstitute/deepthink

1 Introduction

1.1 从“会说”到“会做”：企业级 Agent 的可靠性问题

企业级 AI Agent 的边界正在从“回答问题”扩展到“改变业务状态”。在客户服务中，Agent 可以查询订单、计算退款、修改地址；在 IT 运维中，它可以创建工单、调整权限、执行变更；在采购与供应链中，它可以比价、下单、跟踪交付；在软件研发中，它可以修改代码、运行测试、发起合并。与聊天场景不同，这些动作具有真实副作用：一次错误的退款会影响财务账目，一次越权的权限变更会打开攻击面，一次错误的生产变更会造成服务中断。此时，衡量 Agent 的核心指标不再是单轮回答的流畅度，而是“在权限、合规、成本与时限约束下，可靠地完成任务”的能力。

这一转变使自我修正成为企业级 Agent 的关键能力。Agent 需要在执行过程中发现错误、解释错误、提出修复方案，并在必要时回滚或请求人工介入。没有这种能力，Agent 只能在第一次尝试时依赖模型的“运气”；有了这种能力，系统才有机会在长程任务中从失败中恢复。

1.2 反思与自我修正的研究进展

已有研究提供了多种测试时自我改进方法。Self-Refine 让同一个大语言模型（Large Language Model，LLM）生成初稿、给出反馈并迭代修订，无需额外监督数据或强化学习；原报告称，该方法在 7 项任务上相对单步生成平均绝对提升约 20%[2]。Reflexion 将语言反馈写入情景记忆，使 Agent 在多次试验中改进决策；原报告称，其在 HumanEval 上达到 91% 的 pass@1 准确率[3]。CRITIC 让模型调用搜索、代码解释器等外部工具来检查并修订输出，强调外部反馈对自我改进的重要性[4]。链式验证（Chain-of-Verification，CoVe）先生成初稿，再规划并执行验证问题，以核对事实性声明[10]。这些工作共同说明：LLM 具备在测试时利用反馈改进输出的潜力。

但企业环境与研究基准之间存在重要差异。研究基准通常假设动作可回滚、反馈信号充分、失败代价可控；企业环境则往往包含不可逆动作、权限边界、合规审计和成本上限。更重要的是，Huang 等人的实证研究发现，在没有外部反馈的情况下，模型仅凭自身能力进行“内在自我修正”时，可能无法纠正错误，甚至降低推理表现[5]。这意味着，“让模型再想一遍”并不是可靠性的充分条件。企业需要的不是无约束的反思循环，而是一个能够判断“依据什么反思、何时应该修正、修正是否被允许、谁来承担后果”的治理机制。

1.3 现有方法的四个缺口

本文将现有方法在企业落地中的不足归纳为四个缺口。

证据缺口。 许多自我修正方法让生成者与批评者共享同一模型、同一上下文和同一知识盲区。模型可能“自信地”指出一个并不存在的错误，也可能漏掉真正的错误。企业环境中并不缺少可验证信号：数据库约束、单元测试、策略引擎、工单状态、检索到的制度文档都可以提供外部锚点。但这些信号是异构的、权限化的、带噪声的，不能简单地拼接进提示词。缺乏证据接地，反思就容易退化为语言上的自我循环。

风险缺口。 现有方法大多不区分动作的风险等级。查询库存与删除客户数据、生成草稿与执行资金划转，在可逆性、影响范围和监管敏感度上完全不同。一个在沙箱中有效的修正策略，直接迁移到生产环境可能造成更大损失。对于不可逆动作，“修正”往往不是重新生成一段文本，而是需要回滚、补偿或人工审批。若系统不建模动作风险，自我修正可能把一个小错误放大为一次事故。

治理缺口。 企业需要回答“Agent 为什么改变了主意、依据了哪些证据、谁批准了这次变更、能否复现”。多数自我修正系统只保留最终的反思文本，缺少结构化的事件记录、证据引用、验证器投票和审批链。反思记忆还可能被污染：一次错误的“经验”被写入长期记忆后，可能在后续任务中反复放大。多租户环境下，反思记忆的隔离与数据治理同样是硬约束。

成本缺口。 反思不是免费的。每一轮批评、验证和重试都会增加 token 消耗、工具调用和延迟；人工升级还会占用专家时间。企业需要在成功率、风险、成本和时延之间做权衡。固定轮数的反思策略既可能在小问题上浪费预算，也可能在复杂问题上过早停止。缺少预算感知的停止条件，自我修正会变成“成本黑洞”。

1.4 本文思路：把自我修正变成受治理的决策

本文提出 RESTORE 框架（Reflection-Enabled Self-correction with Traceable Operations, Risk gating, and Escalation），把自我修正从“提示词循环”提升为“受治理的控制回路”。其核心主张是：企业级自我修正的第一性问题不是“如何让模型批评自己”，而是“在证据、权限、风险和预算约束下，是否应该接受一个修正”。

RESTORE 包含六个相互约束的环节。第一，执行证据账本记录动作、工具输出、策略判定和验证结果，为反思提供可引用的证据。第二，分层反思器按动作级、局部修复级、计划级和策略级组织修正，避免所有问题都上升到高成本的重规划。第三，验证器集成将确定性检查、检索验证、模型评判和人工判断组合起来，并通过仲裁降低相关错误。第四，风险感知修正门控根据动作的可逆性和影响范围决定自动修正、回滚、升级或停止。第五，带来源标注的反思记忆把跨 episode 的经验沉淀为可审查的策略建议，而不是不可控的模型自更新。第六，人工升级与审计机制把高风险或低证据情形交给人，并保留完整的决策链。

RESTORE 不追求让 Agent “无限自我进化”。相反，它假设模型会犯错、验证器会犯错、记忆会过时，并通过权限隔离、硬否决、预算停止和人工监督来限制错误的传播。其设计目标是在企业约束下提高可靠性，而不是在开放环境中追求最大化的自主性。

1.5 主要贡献

本文的贡献可以概括为四点。

提出 RESTORE 框架，将企业级 Agent 的反思与自我修正拆分为证据账本、分层反思、验证器仲裁、风险门控、反思记忆和人工升级六个模块，并给出模块之间的控制流与约束关系。
将修正接受问题形式化为带证据充分性、风险上限、合规约束和成本预算的决策问题，给出可审计的事件与反思记录模式，使每次修正能够追溯到证据、验证器投票和责任人。
在理想验证器、噪声验证器和预算约束三种情形下给出设计性质分析，说明证据接地、硬否决和预算停止的必要条件，并明确这些结论依赖的强假设。
设计面向企业约束的评测协议与消融方案，覆盖任务成功率、pass^k 可靠性、有害修正率、每次成功成本、策略违规率和人工升级负载；当前版本只报告实验设计，不报告实测数值。

1.6 组织结构

第 2 节按技术流派回顾相关工作，并说明本文与现有方法的差异。第 3 节给出问题形式化、RESTORE 框架、模块细节、推理流程、复杂度与理论性质。第 4 节给出实验设计、指标、待填表格、分析方案与局限。第 5 节讨论证据接地、停止条件、组织与伦理影响。第 6 节总结并给出未来工作。附录包含符号表、命题证明、提示模板、审计 schema、威胁模型和部署检查清单。

2 Related Work

2.1 Agent 执行底座：推理、行动与多智能体编排

ReAct 将推理轨迹与工具行动交替生成，使模型能够在环境中观察结果并调整下一步行动[1]。AutoGen 以多智能体对话组织协作，把不同角色、工具和执行器连接起来[12]。MetaGPT 将软件组织的标准作业程序编码为角色分工，让多个 Agent 按流程协作[13]。Voyager 通过可复用技能库沉淀开放环境中的行为，使 Agent 能够持续扩展能力边界[11]。这些工作提供了执行与编排的基础设施：如何规划、如何调用工具、如何在多 Agent 之间传递信息。

然而，这些工作主要关注能力扩展与任务完成，而不是在风险约束下决定“何时修正、由谁批准、如何留痕”。一个能够调用更多工具的 Agent，不一定是一个更可靠的 Agent；如果没有证据、门控和审计，能力扩展也会放大错误的后果。本文沿用工具调用与多智能体编排作为执行层，重点补充其上的治理层。

2.2 自我精炼与语言反馈

Self-Refine 让同一个 LLM 依次扮演生成者、批评者和修订者，通过迭代反馈改进输出，不需要额外训练数据或强化学习[2]。Reflexion 将任务反馈转化为语言化的反思文本，写入情景记忆缓冲区，使 Agent 在后续试验中利用过去的经验[3]。这类方法的共同优势是部署成本低：不需要更新模型权重，只需要在推理时增加反馈与修订步骤。

其局限也同样明显。批评者与生成者共享同一模型，容易产生相关错误；反思文本是非结构化的，难以审计和复用；情景记忆缺少来源、过期和隔离机制，可能把一次偶然的成功或失败过度泛化。Huang 等人的研究表明，在没有外部反馈时，内在自我修正可能无法提升甚至降低推理性能[5]。本文因此不把模型自评视为充分证据，而要求批评引用可核验的执行证据，并由独立验证器与风险门控决定是否接受修正。

2.3 工具交互与外部验证

CRITIC 让 LLM 调用搜索、代码解释器等工具来验证和修订输出，强调外部反馈在自我改进中的作用[4]。CoVe 先生成初稿，再规划一组验证问题，并独立回答这些问题以核对事实性声明[10]。与纯语言自评相比，工具交互能够引入模型之外的信息，减少“自说自话”的风险。

但外部工具并非万能。工具访问受权限、成本和可靠性约束；工具输出可能过时、缺失或被恶意注入；不同工具之间可能给出冲突结论。企业环境中的工具还往往带有副作用，验证动作本身可能改变业务状态。本文将工具输出纳入带来源与质量标注的证据账本，并让确定性策略引擎和测试拥有硬否决权；模型评判只能在硬约束允许的范围内提供柔性判断。

2.4 搜索、规划与测试时计算

思维树（Tree of Thoughts，ToT）将推理组织为可搜索的思维树，通过分支、评估和回溯提升复杂问题的求解能力[14]。语言智能体树搜索（Language Agent Tree Search，LATS）将树搜索与行动、反思结合，在推理、行动和规划之间统一搜索[15]。这类方法表明，增加测试时计算可以换取更好的决策质量。

但搜索的成本随分支数和深度快速增长。企业场景需要在预算内决定是否继续搜索、继续修正还是停止。对于低风险、可验证的任务，一次确定性检查可能比大规模搜索更有效；对于高风险、不可逆的任务，更多的搜索也不能替代人工审批。本文将搜索限制在计划级修正中，并由预算停止条件和风险门控约束其使用范围。

2.5 评测、失败分类与可观测性

AgentBench 提供跨多个环境的 Agent 评测，覆盖操作系统、数据库、知识图谱、网页等任务[8]。WebArena 构建了较真实的 Web 环境，用于评估自主 Agent 的长程操作能力[9]。τ-bench 强调工具-用户交互，并引入 pass^k 指标衡量 Agent 在多次独立试验中保持一致成功的能力[6]。这些基准推动了 Agent 评测从单轮问答走向多步交互。

在失败分析方面，多智能体系统失败分类（Multi-Agent System Failure Taxonomy，MAST）通过分析多智能体系统的失败案例，归纳出 14 种失败模式，并将其分为规范、智能体间错位和任务验证三类[7]。这一分类揭示了失败往往不是单一的“模型能力不足”，而是任务规范、角色协作和验证机制共同作用的结果。AgentOps 则从运维视角提出覆盖 Agent 生命周期的可观测性分类，强调对目标、计划、工具和演化过程进行追踪[19]。LLM-as-a-Judge 与 Agent-as-a-Judge 将模型或智能体用于评价，前者关注输出质量，后者强调对中间步骤的反馈[17,18]。

上述工作为离线评测和观测提供了基础，但评测信号通常不直接进入运行时修正决策。一个基准分数不能告诉系统“当前这次修正是否应该被接受”。本文将验证信号、修正记录和审计账本连接为闭环，使评测不仅发生在任务结束后，也发生在每一次关键动作之前。

2.6 治理、安全与人类监督

Constitutional AI 通过原则和 AI 反馈训练更符合人类偏好的模型，展示了将规范写入模型行为的一种路径[16]。NIST AI 风险管理框架（AI Risk Management Framework，AI RMF）与 ISO/IEC 42001 提供了组织层面的 AI 风险管理与管理体系框架[20,21]。这些工作给出了治理原则、风险分类和流程要求，但原则需要落到具体的运行时控制点。

企业级 Agent 的治理不能只停留在文档层面。系统需要在动作执行前检查权限，在修正发生前验证证据，在风险超过阈值时升级人工，在事后保留可审计的记录。本文给出动作风险分级、证据门控、人工升级包和审计事件 schema 的可操作设计，作为原则与工程实现之间的桥梁。

2.7 小结与定位

与现有工作相比，本文的差异不在于“让模型反思”，而在于“让反思可被验证、可被拒绝、可被审计”。表 1 从反馈来源、风险建模、审计能力、记忆治理、人工监督和成本控制六个维度，对代表性方法与 RESTORE 进行概念性对比。该表只比较设计维度，不代表实验结果或系统性能。

维度	Self-Refine	Reflexion	CRITIC	RESTORE
反馈来源	同一模型自评	自评与情景记忆	外部工具	证据账本与多验证器
风险建模	未显式建模	未显式建模	部分工具校验	动作分级与风险门控
审计能力	无结构化记录	反思文本	工具日志	哈希链、证据引用与审批链
记忆治理	无	情景记忆	无	来源、晋升、过期与隔离
人工监督	无	无	无	升级包与审批
成本控制	固定轮数	固定试验数	工具调用预算	预算感知停止

3 Method: RESTORE

3.1 问题形式化

3.1.1 企业环境与执行轨迹

本文将企业环境表示为一个带约束的部分可观测决策过程：

$\mathcal{E}=(\mathcal{S},\mathcal{A},\mathcal{O},\mathcal{T},\mathcal{C},\rho,\mathcal{G}) \tag{1}$

其中， $\mathcal{S}$ 是业务状态空间，包括数据库记录、工单状态、外部系统状态等； $\mathcal{A}$ 是动作空间，既包括工具调用，也包括自然语言输出； $\mathcal{O}$ 是观测空间； $\mathcal{T}$ 是可用工具集合； $\mathcal{C}$ 是策略约束集合，包括访问控制、业务规则、监管要求和租户隔离策略； $\rho:\mathcal{S}\times\mathcal{A}\rightarrow\mathbb{R}_{\ge0}$ 是动作风险函数，用于刻画动作的影响范围与不可逆程度； $\mathcal{G}$ 是目标规范。

Agent 策略记为 $\pi_\theta(a_t\mid h_t)$ ，其中 $h_t=(g,o_{0:t},a_{0:t-1})$ 是截至时刻 $t$ 的历史， $g\in\mathcal{G}$ 是任务目标。一次执行产生轨迹：

$\tau=(h_T,a_T,o_T) \tag{2}$

轨迹不仅包含最终答案，还包含中间动作、工具返回、策略判定和错误信息。这些中间信息是反思的证据来源，也是审计的对象。

3.1.2 反思、修正与接受决策

本文将证据定义为带来源标注的记录集合：

$\mathcal{E}_\tau=\{e_i=(id_i,src_i,content_i,q_i,ver_i)\}_{i=1}^{m} \tag{3}$

其中， $id_i$ 是证据标识， $src_i$ 是来源（工具、数据库、文档、测试、人工等）， $content_i$ 是内容或其脱敏摘要， $0\le q_i\le1$ 是质量或置信度， $ver_i$ 是来源版本。证据账本保证每条证据可以被追溯和复现。

反思函数接收轨迹、证据和目标，输出批评与修复建议：

$(z,\delta)=\mathrm{Reflect}_\phi(\tau,\mathcal{E}_\tau,g) \tag{4}$

其中， $z=\{z_j\}_{j=1}^{n}$ 是批评集合， $\delta$ 是修复建议。每条批评写为 $z_j=(claim_j,\mathcal{I}_j,sev_j)$ ， $\mathcal{I}_j\subseteq\{1,\dots,m\}$ 是该批评引用的证据标识集合， $sev_j$ 是严重程度。若 $\mathcal{I}_j=\emptyset$ ，该批评被标记为“无依据”，不进入自动修正流程；它可以作为人工审查的线索，但不能单独触发动作。

修正算子将批评与建议映射为具体的修正类型：

$\kappa(\tau,z,\delta)\in\{\mathrm{retry}(a'),\mathrm{replan}(p'),\mathrm{rollback}(c),\mathrm{escalate}\} \tag{5}$

其中， $\mathrm{retry}(a')$ 表示在同一计划下重试修正后的动作， $\mathrm{replan}(p')$ 表示替换或修订计划， $\mathrm{rollback}(c)$ 表示执行补偿动作， $\mathrm{escalate}$ 表示升级人工。修正不一定是“重写答案”，也可能是“停止并交给人”。

接受决策由门控函数给出：

$\Gamma(\tau,\tau')=\mathbf{1}\left[ \mathrm{LCB}_{1-\alpha}(\Delta U)\ge0 \land \Pr(\mathrm{harm}\mid\tau,\tau')\le\delta_0 \land \rho(a')\le B \land \mathrm{ES}(\tau')\ge s_0 \land \mathrm{Policy}(a')=\mathrm{allow} \right] \tag{6}$

其中， $\Delta U=U(\tau')-U(\tau)$ 是修正带来的效用变化， $\mathrm{LCB}_{1-\alpha}$ 是其 $1-\alpha$ 下置信界（Lower Confidence Bound，LCB）； $\delta_0$ 是可接受的有害概率上限； $B$ 是风险预算； $\mathrm{ES}(\tau')$ 是证据充分性（Evidence Sufficiency，ES）； $s_0$ 是证据阈值； $\mathrm{Policy}(a')=\mathrm{allow}$ 表示修正后的动作通过策略引擎授权。式（6）表达的核心思想是：只有当修正“有证据、低风险、被授权、且收益下界为正”时，才允许自动执行。

3.1.3 优化目标与约束

系统的目标是在满足合规、成本和时延约束的前提下，最大化期望效用：

$\max_{\pi_\theta,\Gamma}\ \mathbb{E}_{\tau\sim\pi_\theta}[U(\tau)] \quad \mathrm{s.t.}\quad \Pr(V(\tau)>0)\le\epsilon_v,\ \mathbb{E}[C(\tau)]\le B_c,\ \mathbb{E}[L(\tau)]\le B_\ell \tag{7}$

其中， $V(\tau)$ 是策略违规次数， $\epsilon_v$ 是违规概率上限， $C(\tau)$ 是任务成本， $B_c$ 是成本预算， $L(\tau)$ 是时延， $B_\ell$ 是时延预算。任务效用定义为：

$U(\tau)=\mathbf{1}[\mathrm{succ}(\tau)] -\lambda_c C(\tau) -\lambda_\ell L(\tau) -\lambda_r\sum_{t=0}^{T}\rho(s_t,a_t) \tag{8}$

其中， $\mathrm{succ}(\tau)$ 表示任务是否成功， $\lambda_c,\lambda_\ell,\lambda_r\ge0$ 分别是成本、时延和风险的权重。式（8）将“正确”与“代价”放在同一个标量中，使系统可以在“多一次修正”与“直接升级人工”之间做比较。实际部署中，这些权重由业务风险偏好决定，不应由模型自行设定。

3.1.4 设计假设

RESTORE 的适用性依赖以下假设。

A1：动作经过工具网关。 所有有副作用的动作都通过统一的工具网关执行，网关能够实施权限检查、参数校验和审计记录。若 Agent 可以绕过网关直接操作外部系统，风险门控无法生效。
A2：关键证据可记录。 工具输出、策略判定、测试结果和人工决定能够以稳定标识写入证据账本。若关键反馈无法被记录，反思只能依赖模型记忆，证据接地退化为形式。
A3：至少存在一个与任务成功相关的验证信号。 该信号可以是测试、数据库约束、策略引擎、检索文档或人工判断。若目标完全不可验证，系统应默认升级人工，而不是自动修正。
A4：人工升级通道可用。 高风险或低证据情形能够在可接受的时间内转交人工处理。若没有人工作为最终兜底，风险门控只能选择停止，无法完成任务。

这些假设不是无条件成立的。本文在第 5 节讨论其边界；当假设不成立时，RESTORE 的保守策略是停止或升级，而不是继续自动修正。

3.2 框架总览

3.2.1 设计原则

RESTORE 遵循以下设计原则。

P1 证据先于意见。 任何自动修正必须引用可核验证据；没有证据的批评只能进入人工审查队列。
P2 修正不扩权。 修正后的动作必须重新经过授权；反思不能成为绕过权限的通道。
P3 可逆性决定控制强度。 动作越不可逆、影响范围越大，自动修正的空间越小，人工审批的要求越高。
P4 默认留痕。 关键动作、证据、批评、验证器投票和门控决定都写入审计账本。
P5 升级是正常路径。 升级人工不是系统失败，而是在证据不足或风险过高时的正确动作。
P6 预算感知。 修正轮数、token、工具调用和人工时间都有上限；边际收益低于边际成本时停止。
P7 记忆是建议，不是权威。 反思记忆只能作为提示，不能绕过验证器和门控。
P8 确定性与模型分离。 策略引擎、测试和数据库约束拥有硬否决权；模型判断不能覆盖确定性合规否决。

3.2.2 控制回路

图 1 给出 RESTORE 的整体控制流。系统由规划器、执行器、工具网关、环境、证据账本、分层反思器、验证器集成、风险门控、反思记忆和人工控制台组成。箭头表示执行、反馈与治理流。

                         ┌──────────────────────────────┐
                         │        Human Console         │
                         │  approve / reject / annotate │
                         └──────────────▲───────────────┘
                                        │ escalation
┌─────────┐    ┌─────────┐    ┌─────────┴────────┐    ┌─────────────┐
│ Planner │───▶│ Executor│───▶│   Tool Gateway   │───▶│ Environment │
└────▲────┘    └────┬────┘    └─────────┬────────┘    └──────┬──────┘
     │              │                   │                    │
     │              │                   ▼                    ▼
     │              │        ┌──────────────────────────────────┐
     │              │        │         Evidence Ledger          │
     │              │        │ events / tool outputs / policy   │
     │              │        └────────────────┬─────────────────┘
     │              │                         ▼
     │              │        ┌──────────────────────────────────┐
     │              │        │  Tiered Reflector (L0/L1/L2/L3)  │
     │              │        └────────────────┬─────────────────┘
     │              │                         ▼
     │              │        ┌──────────────────────────────────┐
     │              │        │ Verifier Ensemble + Arbitration  │
     │              │        └────────────────┬─────────────────┘
     │              │                         ▼
     │              │        ┌──────────────────────────────────┐
     └──────────────┴────────┤  Risk-aware Correction Gate      │
                             │ accept / rollback / escalate/stop│
                             └────────────────┬─────────────────┘
                                              ▼
                                   ┌─────────────────────┐
                                   │  Reflection Memory  │
                                   │ provenance + expiry │
                                   └─────────────────────┘

图 1：RESTORE 的受治理修正回路。证据账本为反思提供依据，验证器与风险门控决定修正是否被接受，反思记忆与人工控制台形成跨 episode 与跨层级的闭环。

系统包含五个时间尺度的回路。第一，执行回路：规划器生成计划，执行器调用工具，环境返回观测。第二，动作校验回路（L0）：每次动作后立即运行确定性检查，失败则进入修复。第三，局部修复回路（L1）：在同一计划内修正参数或局部动作。第四，计划修订回路（L2）：当局部修复反复失败或计划进度停滞时，重新规划子目标或选择替代工具。第五，策略更新回路（L3）：跨 episode 沉淀经验，离线评估后形成可审查的策略建议。人工作为跨回路的监督者，在高风险或低证据情形下接管。

3.2.3 与现有方法的定位

RESTORE 不替代 ReAct、Self-Refine 或 Reflexion，而是为它们提供治理外壳。ReAct 可以作为执行器，Self-Refine 可以作为 L2 计划修订的一种候选生成方式，Reflexion 的情景记忆可以视为反思记忆的一个特例。区别在于：RESTORE 要求反思引用证据，要求修正通过验证器仲裁和风险门控，要求记忆经过晋升与过期管理，要求所有关键决定可审计。这些约束会降低“自由发挥”的空间，但换来的是企业环境所需的可预测性和可追责性。

3.3 执行证据账本

3.3.1 事件模型

证据账本采用事件溯源（event sourcing）方式，把每次动作、观测、策略判定和人工决定记录为不可变事件。事件 $e_i$ 至少包含以下字段：事件标识、episode 标识、父事件标识、时间戳、执行者（Agent、工具或人）、动作类型、工具名称、参数摘要、观测摘要、策略判定、证据引用、反思记录、门控决定、版本信息和前序哈希。完整 schema 见附录 D。

为保证完整性，账本使用哈希链：

$h_i=\mathrm{H}(h_{i-1}\parallel \mathrm{canonical}(e_i)) \tag{9}$

其中， $h_0$ 是创世哈希， $\mathrm{canonical}(\cdot)$ 是确定性序列化函数， $\mathrm{H}$ 是密码学哈希函数。任何对历史事件的篡改都会导致后续哈希校验失败。需要强调的是，哈希链只保证“记录未被修改”，不保证“记录内容真实”。真实性依赖工具网关的签名、访问控制和独立审计。系统不应把哈希链当作真实性证明，而应把它作为可追责性的基础设施。

3.3.2 证据充分性

不同动作对证据的要求不同。查询库存与执行退款都需要证据，但后者的证据要求更高。本文定义证据充分性：

$\mathrm{ES}(\tau)=\frac{\sum_{i=1}^{T}w_i q_i\mathbf{1}[e_i\neq\emptyset]}{\sum_{i=1}^{T}w_i} \tag{10}$

其中， $w_i\ge0$ 是动作 $i$ 的重要性权重，由风险等级和目标相关性决定； $0\le q_i\le1$ 是证据质量，可由来源可靠性、时效性和一致性估计； $\mathbf{1}[e_i\neq\emptyset]$ 表示该动作是否有对应证据。 $\mathrm{ES}(\tau)$ 越高，说明轨迹中的关键动作越有据可查。

证据充分性不是“证据数量”的同义词。十条来自同一不可靠来源的重复信息，不应获得比一条可验证的数据库记录更高的分数。系统应对来源去重、时效衰减和冲突检测进行建模；具体实现可以是规则，也可以是校准后的评分模型。当前版本将 $q_i$ 视为需要校准的参数，具体取值标为 [TODO: 证据质量校准待完成]。

3.3.3 隐私与权限

企业轨迹中可能包含客户姓名、联系方式、交易记录、工单内容和内部文档。证据账本必须在写入时进行脱敏和分级：高敏感字段只保存加密引用或哈希，不进入明文日志；不同租户的数据在存储和检索层面隔离；访问审计本身也要记录。审计人员可以查看决策链，但不一定有权查看原始个人信息。具体保留期限、跨境传输和删除策略需由合规团队根据适用法律确定，本文不提供法律意见。

3.4 分层反思器

3.4.1 L0：确定性校验

L0 是每次动作后立即执行的确定性检查，不调用 LLM。它负责回答“这个动作在形式和权限上是否合法”。典型检查包括：参数 schema 是否符合工具定义；必填字段是否缺失；数值是否在允许范围；数据库约束是否满足；调用者是否具有相应权限；动作是否违反业务策略；代码是否通过单元测试；检索结果是否包含可引用的来源。

L0 的优势是成本低、精度高、可解释。它适合处理大量“低级错误”，例如参数类型错误、缺少订单号、越权调用。L0 的局限是覆盖率有限：它只能检查已经被写成规则或测试的属性，无法判断语义层面的合理性。因此，L0 通过不等于任务正确，只表示“没有发现确定性错误”。

3.4.2 L1：局部修复

L1 在保持当前计划不变的前提下，对动作参数或局部步骤进行最小修复。触发条件通常是 L0 失败、工具返回可恢复错误、或观测与预期不符。典型手段包括：把工具返回的错误信息回填给模型，要求其修正参数；在允许范围内调整查询条件；重试一次幂等操作；选择同一工具的替代参数。

L1 的约束是“不扩权、不改计划、不引入新工具”。修复后的动作必须重新经过 L0 和权限检查。系统设置最大重试次数 $K_1$ ，避免在同一个错误上反复循环。若连续 $K_1$ 次 L1 失败，或错误涉及计划层面的假设，则升级到 L2 或人工。

3.4.3 L2：计划修订

L2 修改的是计划，而不是单个动作。触发条件包括：L1 连续失败；计划进度停滞；当前工具无法提供所需信息；子目标之间出现冲突；观测显示原始计划的前提不成立。L2 的动作包括：重新分解子目标；替换工具；调整执行顺序；引入新的验证步骤；在候选计划之间做有预算的比较。

L2 可以使用受限搜索。例如，生成 1 至 3 个候选计划，用验证器评估每个计划的可执行性和风险，再选择得分最高且通过门控的计划。搜索深度和分支数由预算约束。L2 不应无限制地扩展计划；如果候选计划都需要高风险动作，系统应升级人工，而不是继续搜索。

3.4.4 L3：策略更新

L3 是跨 episode 的离线策略更新，不是运行时修改模型权重。系统从历史反思记录中挖掘反复出现的失败模式，提出可审查的策略建议，例如“当退款金额超过阈值时，必须先核对订单状态和客户等级”“当检索文档版本早于策略版本时，不得引用该文档”。这些建议经过回放评估、人工审批和灰度发布后，才进入策略库。

L3 的设置是为了避免“在线自我进化”带来的不可控风险。模型权重、提示词和策略库的变更都应有版本号、变更记录和回滚方案。L3 不得直接修改权限规则或风险阈值；这些属于治理参数，应由风险负责人审批。

3.4.5 层级选择与升级

层级选择遵循“从低到高、证据不足则升级”的原则：

$\mathrm{tier}= \begin{cases} L0, & \text{每次动作后强制执行}\\ L1, & \mathrm{risk}\le1\ \land\ \mathrm{ES}\ge s_0\ \land\ k_1<K_1\\ L2, & \text{L1 连续失败或出现计划级信号}\\ L3, & \text{仅离线，且满足晋升条件}\\ \mathrm{human}, & \mathrm{ES}<s_0\ \lor\ \mathrm{risk}=3\ \lor\ D>\tau_D \end{cases} \tag{11}$

其中， $D$ 是验证器分歧度， $\tau_D$ 是分歧阈值。高风险动作不会因为“模型很自信”而跳过人工；低证据情形也不会因为“重试次数还没用完”而继续自动修正。层级选择的目标不是最大化自动化率，而是把有限的验证和人工资源分配到最需要的地方。

3.5 验证器集成与仲裁

3.5.1 验证器类型

RESTORE 使用四类验证器，如表 2 所示。确定性验证器包括测试、schema、策略引擎和数据库约束；检索验证器包括文档、知识库和搜索；模型验证器包括 LLM-as-a-Judge 风格的评分与成对比较；人工验证器由业务专家或风险负责人承担。

验证器类型	主要信号	优势	典型失效模式
确定性验证器	测试、schema、策略、数据库约束	成本低、精度高、可解释	覆盖率不足、测试脆弱、规则过时
检索验证器	制度文档、知识库、搜索结果	可提供外部依据、可追溯	文档过时、检索遗漏、内容注入
模型验证器	评分 rubric、成对比较、步骤检查	能处理语义与开放性判断	相关偏差、校准漂移、提示注入
人工验证器	专家判断、审批	能处理模糊与高风险情形、承担责任	成本高、时延长、判断不一致

3.5.2 校准与聚合

每个验证器 $v$ 对修复建议 $\delta$ 输出一个分数 $0\le s_v(\delta)\le1$ ，1 表示支持接受。系统使用校准后的权重 $w_v$ 聚合成总支持度：

$S(\delta)=\sum_{v=1}^{V}w_v s_v(\delta),\qquad w_v\ge0,\qquad \sum_{v=1}^{V}w_v=1 \tag{12}$

权重不应由模型即时生成，而应从带标签的校准集估计，并定期更新。对于确定性验证器，权重可以设为硬约束，而不是普通加权项。一个实用的做法是：先检查是否存在硬否决；若没有，再用式（12）聚合柔性验证器；若总支持度低于阈值 $\tau$ ，则拒绝自动修正。

3.5.3 硬否决与分歧处理

硬否决是 RESTORE 与纯模型自评的关键区别。若策略引擎返回拒绝、测试失败、数据库约束不满足，或权限检查不通过，则无论模型验证器多么“自信”，修正都不得自动执行：

$\mathrm{Policy}(a')=\mathrm{deny}\ \lor\ \mathrm{Test}(a')=\mathrm{fail} \ \Longrightarrow\ \Gamma=0 \tag{13}$

模型验证器只能在硬约束允许的范围内提供柔性判断。它可以帮助判断“哪个候选方案更好”，但不能推翻“这个动作不合规”的确定性结论。

当验证器之间出现分歧时，系统计算分歧度：

$D(\delta)=1-\frac{1}{V}\sum_{v=1}^{V}\mathbf{1}[s_v(\delta)\ge\tau_v] \tag{14}$

若 $D(\delta)>\tau_D$ ，系统不应“取平均”后强行接受，而应回滚、升级人工或选择更保守的方案。分歧本身是风险信号：它说明当前证据不足以支持一个明确的自动决定。

3.5.4 相关错误与独立性

验证器的价值取决于其错误是否与生成器独立。若生成器、批评者和验证器使用同一模型、同一上下文和同一提示模板，它们的错误可能高度相关：模型漏掉的事实，批评者也容易漏掉；模型编造的理由，验证者也容易认可。这种“同源验证”会制造虚假的共识。

提高独立性的手段包括：使用不同来源的证据（数据库、文档、测试）；使用不同工具或不同模型家族的验证器；让验证器在不接触生成器完整推理过程的情况下独立作答；引入人工判断；对验证器进行对抗测试。需要承认的是，独立性是程度问题，不是二元属性。系统应定期测量验证器之间的相关性，并在相关性过高时降低聚合权重或引入外部审计。

3.6 风险感知修正门控

3.6.1 动作风险分级

本文将企业动作分为四级，如表 3 所示。分级不是按“动作看起来是否危险”，而是按可逆性、影响范围和监管敏感度综合判断。

风险级别	定义	典型示例	默认控制
0	只读、无副作用	查询、检索、读取配置	允许自动修正与重试
1	可逆或可补偿	生成草稿、可撤销工单、临时配置	自动修正并记录审计
2	有后果但可补偿	退款、下单、发送通知、修改客户资料	双验证；超过阈值需人工审批
3	不可逆或高影响	删除数据、生产变更、资金划转、法律提交	执行前双人审批；执行后仅允许补偿或升级

风险分级应由业务、风控、法务和安全团队共同确定，而不是由 Agent 自行判断。Agent 可以提出风险估计，但最终分级规则属于治理配置。对于跨租户、跨境或涉及敏感数据的动作，应默认提高一级。

3.6.2 风险评分

在分级之上，系统可以使用可解释的风险评分做细粒度控制：

$\rho(a)=\sigma\left(\beta_0+\beta_1\mathrm{irrev}(a)+\beta_2\mathrm{blast}(a)+\beta_3\mathrm{reg}(a)+\beta_4\mathrm{money}(a)+\beta_5\mathrm{users}(a)\right) \tag{15}$

其中， $\sigma$ 是 logistic 函数； $\mathrm{irrev}(a)$ 表示不可逆程度； $\mathrm{blast}(a)$ 表示影响范围； $\mathrm{reg}(a)$ 表示监管敏感度； $\mathrm{money}(a)$ 表示金额； $\mathrm{users}(a)$ 表示受影响用户数； $\beta$ 是权重。该评分是可解释的初始版本，权重需要根据企业风险偏好校准，具体取值标为 [TODO: 风险权重校准待完成]。系统不应把评分当作精确的概率，而应把它作为分级和审批路由的依据。

3.6.3 门控规则

风险门控将验证结果、证据充分性、风险评分和策略授权组合为最终决定：

$\mathrm{Decision}= \begin{cases} \mathrm{accept}, & \Gamma=1\ \land\ \rho(a')\le B\\ \mathrm{rollback}, & \text{已执行且存在补偿动作}\\ \mathrm{escalate}, & \mathrm{ES}<s_0\ \lor\ \rho(a')>B\ \lor\ D>\tau_D\\ \mathrm{stop}, & \text{预算耗尽或无可行动作} \end{cases} \tag{16}$

其中， $\Gamma$ 由式（6）给出。四个决定对应不同的审计记录：接受记录修正理由和证据；回滚记录补偿动作和影响范围；升级记录升级包和接收人；停止记录停止原因和未完成目标。系统不应把“停止”视为异常退出，而应把它视为一种明确的、可审计的决策。

3.6.4 不可逆动作

不可逆动作需要特别处理。对于风险级别 3 的动作，系统不应在执行后自动“修正”结果，因为原始副作用已经发生。可用的控制手段包括：执行前双人审批；执行前沙箱演练；执行前一致性检查；执行后补偿动作；执行后升级人工并启动事件响应。

“执行后自动修正”在不可逆场景中是一个危险的幻觉。模型可以生成一段看起来合理的“更正说明”，但无法撤销已经删除的数据或已经发出的资金。RESTORE 对这类动作采取“前置控制优先”的原则：把验证和审批放在执行之前，把执行后的自动修正限制在补偿动作上，并要求人工确认。

此外，修正不得扩大权限。即使一个修正方案在语义上“更合理”，如果它需要调用当前角色无权使用的工具，系统也必须拒绝或升级，而不能以“为了完成任务”为由绕过授权。权限检查发生在每次动作之前，而不是只在任务开始时检查一次。

3.7 反思记忆与策略库

3.7.1 记录模式

反思记忆不是聊天记录的简单堆积，而是结构化的、可审查的经验记录。每条记录至少包含以下字段：失败签名、上下文摘要、诊断、修复方案、执行结果、证据引用、验证器投票、人工决定、模型版本、策略版本、置信度、生效时间、过期时间和状态。表 4 给出字段说明。

字段	含义
failure_signature	失败模式的规范化签名，用于检索相似案例
context	任务类型、工具集合、租户、策略版本等上下文摘要
diagnosis	对失败原因的诊断，必须引用证据标识
repair	实际采取的修复方案及其结果
outcome	修复后的效用变化、是否成功、是否产生副作用
evidence_refs	支撑诊断与修复的证据标识列表
verifier_votes	各验证器的分数、阈值和分歧度
human_decision	人工审批或驳回的记录
model_version	生成反思的模型及其版本
policy_version	当时生效的策略与权限规则版本
confidence	该经验的可信度，由结果与复核共同决定
valid_from / valid_until	生效与过期时间
status	候选、已批准、已隔离、已过期、已回滚

记录中的 diagnosis 和 repair 必须引用证据，不能只有自然语言描述。这样，后续检索到该记录时，系统可以重新检查证据是否仍然有效，而不是盲目相信一段历史文本。

3.7.2 检索与使用

给定当前轨迹的失败签名 $\sigma(\tau)$ ，系统从当前租户的记忆中检索最相关的记录：

$m^*=\arg\max_{m\in\mathcal{M}}\ \mathrm{sim}(\sigma(\tau),\sigma_m)\cdot c_m\cdot\mathbf{1}[\mathrm{valid}_m]\cdot\mathbf{1}[\mathrm{tenant}_m=\mathrm{tenant}] \tag{17}$

其中， $\mathrm{sim}$ 是签名相似度， $c_m$ 是记录置信度， $\mathrm{valid}_m$ 表示记录未过期且策略版本兼容， $\mathrm{tenant}_m$ 是记录所属租户。租户隔离是硬约束：一个租户的经验不得检索到另一个租户的任务中，即使任务看起来相似。

检索到的记忆以“历史建议”的形式注入反思上下文，并附带来源、置信度和适用范围。它不能作为指令直接执行。记忆中的建议仍需经过当前证据验证、验证器仲裁和风险门控。换句话说，记忆可以提示“过去遇到过类似问题”，但不能证明“这次也应该这样做”。

3.7.3 晋升、过期与隔离

一条反思记录从“候选”变为“已批准”的策略建议，需要满足以下条件：

多次独立支持。 该失败模式在至少 $N$ 个独立 episode 中出现，且修复方案在多数情况下有效。 $N$ 的具体取值需根据任务分布校准，本文标为 [TODO: 晋升样本阈值待校准]。
回放评估。 在历史回放集上应用该建议，任务成功率不下降，且有害修正率不上升超过阈值。
人工审批。 由业务或风险负责人审查建议的适用范围、权限影响和潜在副作用。
版本兼容。 记录中的策略版本、工具版本和模型版本与当前部署兼容；不兼容的记录进入隔离区。
过期与回滚。 每条建议设置有效期和回滚方案；策略或工具变更后，相关建议需要重新验证。

“已批准”不等于“永久有效”。企业策略、工具接口和业务规则会变化，过去的正确经验可能变成今天的错误规则。系统应定期重放和复核记忆，把过期记录标记为无效，而不是继续检索。

3.7.4 记忆投毒防护

反思记忆是一个有吸引力的攻击面。攻击者可能通过恶意文档、被污染的工具输出或对抗性用户输入，诱导 Agent 写入一条错误的“经验”，然后在后续任务中反复利用。为降低风险，RESTORE 采取以下措施。

写入审查。 只有经过验证器支持和人工复核的记录才能进入“已批准”状态；未经验证的模型输出只能进入隔离区。
来源签名。 记录写入时附带来源、模型版本和证据哈希；读取时校验完整性。
租户隔离。 记忆按租户分区，跨租户检索默认禁止；共享策略库需要单独审批。
范围限制。 每条建议附带适用条件和反例，避免“一次成功，处处适用”的过度泛化。
异常检测。 监控记忆写入频率、来源分布和检索命中率；异常增长或异常集中可能是投毒信号。
快速回滚。 发现污染后，能够按来源、版本或时间窗口批量禁用相关记录，并重新评估受影响的 episode。

这些措施不能完全消除投毒风险，但可以把“一次污染永久生效”变成“可发现、可隔离、可回滚”。

3.8 人工升级与审计

3.8.1 升级包

当系统决定升级人工时，不能只发送一句“请帮忙看看”。人工需要在有限时间内做出可追责的决定。升级包至少包含以下内容：任务目标与当前状态；建议动作及其 diff；支撑证据与来源；各验证器的分数与分歧；风险级别与风险评分；备选方案；回滚或补偿方案；服务等级协议（Service-Level Agreement，SLA）时限；相关策略版本；系统置信度。

升级包的界面应突出“不确定在哪里”，而不是只展示 Agent 的推荐答案。例如，若策略引擎拒绝了一个退款动作，界面应显示被拒绝的具体条款、检索到的制度文档、Agent 认为可能适用的例外，以及人工可以选择的替代方案。这样可以降低自动化偏差，避免人工成为“橡皮图章”。

3.8.2 审计查询

审计账本应支持以下查询：Agent 为什么执行了动作 X；它依据了哪些证据；它在什么时候改变了计划；谁批准了这次变更；当时生效的策略版本是什么；这次修正是否产生了副作用；能否重放当时的决策过程。每个查询都应返回结构化结果，而不是只返回一段自然语言总结。

对于可重放的工具调用，系统可以在沙箱中使用相同输入和版本重放；对于有外部副作用的调用，系统应使用模拟器或记录下来的响应进行重放，避免二次副作用。重放结果与原始结果不一致时，应标记为“不可复现”，并进入人工审查。

3.8.3 角色与职责分离

企业部署中，至少涉及四类角色：操作员负责日常运行和告警处理；审核员负责人工审批和抽样复核；审计员负责检查决策链和合规性；风险负责人负责风险阈值、动作分级和策略变更。职责分离可以降低单点滥用的风险：提出修正的 Agent 不能同时批准修正；调整风险阈值的人不能独自关闭审计；跨租户的数据访问需要额外授权。

角色和权限应写入策略引擎，而不是写在提示词里。模型可以建议“请人工审批”，但只有策略引擎能决定“谁有权审批、审批是否生效”。

3.9 推理流程与训练策略

3.9.1 推理算法

算法 1 给出 RESTORE 的单 episode 推理流程。该流程是框架级的，具体的规划、反思和验证实现可以替换。

算法 1  RESTORE 受治理修正循环
输入: 目标 g, 策略 C, 风险预算 B, 成本预算 Bc, 最大轮数 K
输出: 任务结果、审计记录、反思记录

 1: p ← Planner(g)
 2: τ ← ∅; E ← ∅; k ← 0
 3: while 未完成 and k < K and 预算未耗尽:
 4:     a ← SelectAction(p, τ)
 5:     若 a 未通过前置权限/策略检查: 升级人工并跳出
 6:     o ← Execute(a); 追加 (a, o) 到 τ; E ← E ∪ Evidence(o)
 7:     if L0 校验通过:
 8:         若任务完成: 跳出
 9:         continue
10:     z, δ ← Reflect(τ, E, g)          # 每条批评必须引用证据
11:     tier ← SelectTier(z, τ, k)       # L1 / L2 / human
12:     repair ← ProposeRepair(z, δ, tier)
13:     votes ← Verify(repair, E, τ)     # 确定性 → 检索 → 模型 → 人工
14:     decision ← Gate(votes, repair, τ, B, C)
15:     if decision = accept:
16:         执行 repair; k ← k + 1
17:     elif decision = rollback:
18:         执行补偿动作; k ← k + 1
19:     else:
20:         生成升级包; 升级人工; 跳出
21: end while
22: 写入审计记录与候选反思记录
23: 离线评估候选记录; 满足条件后进入策略库

算法中的关键点是第 10 至 14 行：反思不是直接执行，而是先形成带证据的批评，再经过分层选择、验证器仲裁和门控。第 5 行的前置检查确保修正不能绕过权限。第 22 至 23 行把运行时经验与离线策略更新分开，避免在线自我修改。

3.9.2 是否需要训练

RESTORE 不要求训练新模型。它可以在现有 LLM 和工具之上运行，通过提示、验证器和策略引擎实现治理。可选的训练包括：在校准集上拟合验证器权重；用经过人工确认的修正记录微调反思模型；用离线数据学习升级策略；训练失败签名分类器。这些训练都应视为对组件的校准，而不是对系统治理规则的替代。

训练数据存在选择偏差：只有被记录、被复核的修正才进入训练集，而这些修正往往来自已经通过门控的案例。系统应保留被拒绝、被回滚和被人工驳回的负例，避免模型只学会“如何让修正是看起来正确”。

3.9.3 冷启动与灰度

冷启动阶段，系统没有反思记忆，验证器权重也未校准。此时应采取保守策略：只启用 L0 和 L1；L2 需要人工确认；L3 关闭；高风险动作全部人工审批。系统可以先以“影子模式”运行，即只记录建议、不执行动作，用真实轨迹校准验证器和风险评分。

灰度发布应按租户、任务类型和风险级别逐步放开。每个阶段设置明确的退出条件：任务成功率不低于基线、有害修正率低于阈值、策略违规率为零、人工升级负载在可接受范围内。任何阶段出现异常，都应能够通过 kill switch 停止自动修正，并回滚策略版本。

3.10 复杂度与理论性质

3.10.1 成本模型

设一轮修正包含规划、执行、验证和反思四个部分，则单轮成本为：

$C_{\mathrm{round}}=C_{\mathrm{plan}}+C_{\mathrm{exec}}+\sum_{v=1}^{V}n_vC_v+C_{\mathrm{reflect}} \tag{18}$

其中， $n_v$ 是第 $v$ 个验证器的调用次数， $C_v$ 是其单次成本。一个 episode 的总成本为：

$C_{\mathrm{total}}=\sum_{k=1}^{K}C_{\mathrm{round}}^{(k)}+C_{\mathrm{human}}N_{\mathrm{esc}} \tag{19}$

其中， $C_{\mathrm{human}}$ 是单次人工升级的平均成本， $N_{\mathrm{esc}}$ 是升级次数。时间开销与成本类似，但还受工具延迟和人工排队影响。存储开销主要由证据账本和反思记忆决定：账本随轨迹长度线性增长，记忆随 episode 数量增长，需要通过归档、压缩和过期策略控制。

3.10.2 命题 1：可靠验证器下的单调改进

命题 1. 若验证器对“接受”没有假阳性，即任何被接受的修正都满足 $\Delta U\ge0$ ，且修复动作可行、不违反约束，则每次被接受的修正都不会降低任务效用；因此，效用序列单调不减。

证明很直接：在命题假设下，门控接受的修正满足 $\Delta U\ge0$ ，拒绝或升级不改变已完成动作的效用。形式化证明见附录 B.1。该命题的价值不在于数学难度，而在于说明门控的设计目标：把“是否接受”从一个语言判断变成一个带约束的决策。若验证器不可靠，命题 1 的前提不成立，系统就需要命题 2 所描述的防护。

3.10.3 命题 2：噪声验证器下的误差放大

命题 2. 设每轮提出的修正以概率 $\epsilon$ 有害，且各轮独立；若门控不提供额外过滤，则 $K$ 轮后至少发生一次有害修正的概率为：

$\Pr(\text{至少一次有害修正})=1-(1-\epsilon)^K \tag{20}$

若单轮有益修正的收益为 $G$ ，有害修正的损失为 $H$ ，则单轮期望效用变化为：

$\mathbb{E}[\Delta U]=(1-\epsilon)G-\epsilon H \tag{21}$

当 $\epsilon>G/(G+H)$ 时，期望效用随轮数下降。证明见附录 B.2。

该命题刻画了一个常见误区：增加反思轮数并不必然提升可靠性。若验证器的假阳性率较高，更多轮数只会增加“自信地改错”的机会。现实中的错误往往是相关的，独立假设可能过于乐观；相关性越强，误差放大的风险越高。RESTORE 通过证据接地、硬否决、风险门控和人工升级来降低有效 $\epsilon$ ，但无法将其降为零。因此，系统必须接受“有些修正不应自动执行”这一事实。

3.10.4 命题 3：预算感知的停止条件

命题 3. 设第 $k$ 轮修正的期望收益为 $G_k$ ，成本为 $C_k$ ，且 $G_k$ 非增、 $C_k$ 非减；令 $\lambda_c$ 为成本的效用权重。则在不考虑跨轮交互的近似下，最优停止轮数满足：

$K^*=\max\left\{K:\ G_K\ge\lambda_c C_K\right\} \tag{22}$

证明使用边际分析：只要下一轮的边际收益不低于边际成本，继续修正就是有利的；当边际收益低于边际成本时，停止或升级更优。形式化证明见附录 B.3。

该命题为预算停止提供了直观依据，但它依赖“边际收益可估计”这一强假设。实际系统中， $G_k$ 往往只能通过验证器分数和历史统计近似，且轮次之间的收益可能不独立。因此，命题 3 应作为设计原则，而不是精确的最优解。

3.10.5 推论：级联验证的成本条件

推论 1. 设廉价验证器的单次成本为 $c_1$ ，它能够独立解决当前验证问题的概率为 $p_1$ ；昂贵验证器的单次成本为 $c_2$ 。若采用“先廉价、未解决再昂贵”的级联策略，则期望验证成本为：

$\mathbb{E}[C_{\mathrm{ver}}]=c_1+(1-p_1)c_2 \tag{23}$

级联策略优于始终使用昂贵验证器的条件为：

$c_1<p_1c_2 \tag{24}$

证明见附录 B.4。该推论解释了为什么 RESTORE 先运行确定性检查，再调用检索和模型验证器：只要廉价验证器在足够多的简单案例上能够给出结论，级联就能降低成本。反之，如果廉价验证器经常无法解决、又引入了额外开销，级联反而更贵。

3.10.6 适用边界

上述命题依赖强假设：效用可观测、验证器误差可估计、轮次之间近似独立、修复动作可行且不改变约束。真实企业系统中，这些假设往往只能部分成立。因此，本文不声称 RESTORE 能在所有场景中保证单调改进或最优停止；本文声称的是，这些性质为设计提供了可检验的目标，并指出了证据接地、硬否决和预算控制的必要性。第 4 节的实验设计将把这些性质转化为可测量的指标，而不是把它们当作既定结论。

4 Experiments

4.1 研究问题

本文设计以下研究问题，用于后续实证评估。

RQ1（可靠性）：RESTORE 能否提升 Agent 在多次独立试验中一致成功的概率，而不仅是单次成功率？
RQ2（安全性）：证据接地与验证器仲裁能否降低有害修正率和策略违规率？
RQ3（风险控制）：风险门控在降低高风险动作违规的同时，会带来多大的成功率损失？
RQ4（成本）：级联验证与预算停止能否降低每次成功任务成本（Cost per Success，CPS）和尾延迟？
RQ5（人机协同）：人工升级的频率、准确率和处理时间是否在可接受范围内？

4.2 实验环境与数据

本文建议在公开基准与企业沙箱两类环境中评估。表 5 给出候选环境及其适用性。当前版本不报告任何数据规模、任务数量或实验结果；相关字段标为。

环境	领域	适用性	局限
τ-bench	零售、航空客服	工具调用、策略遵循、用户交互、pass^k 可靠性	用户由模型模拟；企业工具多样性有限
WebArena	真实 Web 环境	长程网页操作、状态改变	多数动作可回滚，缺少企业权限与审批
AgentBench	多环境任务	覆盖操作系统、数据库、知识图谱等	非企业专用，风险分级需自行补充
企业沙箱（建议构建）	CRM、ERP、ITSM	可注入权限、风险等级、审计与不可逆动作	尚未构建；本文不报告其规模或结果

企业沙箱的设计目标是补足公开基准缺失的企业约束。建议包含：模拟 CRM、ERP、工单系统和文档库；基于角色的访问控制（Role-Based Access Control，RBAC）与基于属性的访问控制（Attribute-Based Access Control，ABAC）；可逆与不可逆动作；策略文档版本；多租户隔离；故障注入；审计日志；人工审批队列。任务可覆盖退款、工单升级、采购审批、权限变更和报表生成。沙箱的具体实现、数据规模和标注协议均标为 [TODO: 企业沙箱构建待完成]。

4.3 基线方法

表 6 给出候选基线。为保证比较公平，所有方法应使用相同的基础模型、工具集合、上下文预算和最大轮数；反思类方法应匹配总 token 预算，而不是只匹配轮数。具体提示模板见附录 C。

基线	反馈来源	说明
ReAct	环境观测	标准推理-行动交替，不显式自我修正
ReAct + retry	工具错误	固定重试，不改变计划
Self-Refine	同一模型自评	迭代反馈与修订
Reflexion	自评与情景记忆	多次试验，语言反思
CRITIC	外部工具	工具交互式批评与修订
RESTORE	证据账本与多验证器	本文框架
RESTORE w/o evidence	无证据引用	消融：去掉证据接地
RESTORE w/o gate	无风险门控	消融：自动接受所有通过验证的修正
RESTORE w/o memory	无跨 episode 记忆	消融：关闭反思记忆

4.4 评价指标

设测试集包含 $N$ 个任务，每个任务独立运行 $k$ 次。任务成功率为：

$\mathrm{SR}=\frac{1}{N}\sum_{i=1}^{N}\mathbf{1}[\mathrm{succ}_i] \tag{25}$

pass^k 衡量 Agent 在 $k$ 次独立试验中全部成功的比例：

$\mathrm{pass}^k=\frac{1}{N}\sum_{i=1}^{N}\mathbf{1}\left[\forall j\in\{1,\dots,k\},\ \mathrm{succ}_{i,j}\right] \tag{26}$

有害修正率（Harmful Correction Rate，HCR）衡量被接受的修正中有多大比例降低了任务效用：

$\mathrm{HCR}=\frac{\left|\{c\in\mathcal{C}_{\mathrm{acc}}:\Delta U(c)<0\}\right|}{\left|\mathcal{C}_{\mathrm{acc}}\right|} \tag{27}$

其中， $\mathcal{C}_{\mathrm{acc}}$ 是被门控接受的修正集合。修正精确率定义为：

$\mathrm{CP}=\frac{\left|\{c\in\mathcal{C}_{\mathrm{acc}}:\Delta U(c)>0\}\right|}{\left|\mathcal{C}_{\mathrm{acc}}\right|} \tag{28}$

每次成功任务成本为：

$\mathrm{CPS}=\frac{\sum_{i=1}^{N}C_i}{\sum_{i=1}^{N}\mathbf{1}[\mathrm{succ}_i]} \tag{29}$

此外，报告 p95 延迟、人工升级率、策略违规率、审计完整率（具有完整证据链的关键动作比例）、L3 更新后的回归率，以及修正召回率（应修正且被修正的比例）。所有指标应同时报告置信区间，而不是只报告点估计。

4.5 实现细节与超参数

表 7 给出实现细节模板。标为“建议起点”的数值是设计默认值，不是实验结果，需在验证集上调参；标为 [TODO] 的字段需在正式实验前确定。

项目	设置
基础模型与版本	`[TODO: 模型与版本待确定]`
温度与采样	`[TODO: 解码参数待确定]`
最大修正轮数 $K$	3（建议起点）
L1 最大重试次数 $K_1$	2（建议起点）
证据充分性阈值 $s_0$	`[TODO: 阈值校准待完成]`
验证器聚合阈值 $\tau$	`[TODO: 阈值校准待完成]`
分歧阈值 $\tau_D$	`[TODO: 阈值校准待完成]`
风险预算 $B$	`[TODO: 由风险负责人设定]`
成本预算 $B_c$	`[TODO: 按租户/任务设定]`
时延预算 $B_\ell$	`[TODO: 按 SLA 设定]`
随机种子	5 个（建议起点）
硬件与推理服务	`[TODO: 实验环境待记录]`

4.6 主实验（待填）

表 8 是主实验模板。当前版本不包含任何实测数值；所有均表示尚未完成实验，不代表零值或预期值。

方法	成功率 ↑	pass^5 ↑	HCR ↓	CPS ↓	p95 延迟 ↓	策略违规率 ↓	升级率 ↓
ReAct
Self-Refine
Reflexion
CRITIC
RESTORE

针对 RQ1 至 RQ5，本文预先给出判读规则，避免事后挑选指标。H1（可靠性）：若 RESTORE 的 pass^5 提升幅度大于成功率提升幅度，且置信区间不包含零，则支持“提升的是一致性而非平均运气”。H2（安全性）：若 RESTORE 的 HCR 低于 Self-Refine 和 Reflexion，且策略违规率不高于基线，则支持证据接地与仲裁的作用。H3（风险控制）：若风险门控降低高风险动作违规，即使成功率略有下降，也应在企业风险偏好下视为可接受；具体阈值由风险负责人设定。H4（成本）：若级联验证的 CPS 低于始终使用模型验证器的变体，则支持推论 1 的成本条件。H5（人机协同）：若升级率过高或人工处理时间超出 SLA，则框架在企业场景中不可持续，需要调整阈值或任务范围。

4.7 消融实验（待填）

表 9 给出消融实验模板。消融的目的是识别各模块的边际贡献，而不是证明“模块越多越好”。

变体	成功率 ↑	pass^5 ↑	HCR ↓	CPS ↓	策略违规率 ↓	说明
RESTORE 完整版						全部模块启用
去掉证据账本						反思不引用证据
去掉验证器仲裁						仅使用单一模型评判
去掉风险门控						自动接受所有通过验证的修正
去掉反思记忆						关闭跨 episode 记忆
去掉人工升级						低证据时强制自动决策
固定 $K = 1$						只允许一次修正
固定 $K = 5$						允许更多轮修正

4.8 分析与案例

4.8.1 与 MAST 失败分类的对应

MAST 将多智能体系统失败归纳为规范、智能体间错位和任务验证三类，共 14 种失败模式[7]。表 10 给出 RESTORE 各模块与这些类别的对应关系。该表用于指导错误分析，不表示 RESTORE 能消除所有失败。

MAST 类别	典型表现	RESTORE 对应机制	仍可能失败的原因
规范	不遵守任务规范、角色越界、目标偏离	策略引擎、L0 校验、任务规范注入	规范本身模糊或冲突
智能体间错位	信息隐瞒、计划偏离、协作失败	共享证据账本、计划修订、显式审批	多 Agent 目标不一致、通信成本
任务验证	过早终止、验证不完整、错误接受	验证器集成、硬否决、风险门控	验证器盲区、相关错误、证据缺失

4.8.2 成本-质量权衡

正式实验应绘制“成功率—每次成功成本”的 Pareto 前沿，并比较不同预算下的曲线。重点观察三个区域：低预算区，系统是否过早停止或升级；中预算区，级联验证是否带来成本优势；高预算区，增加轮数是否只带来边际收益甚至 HCR 上升。若高预算区的 HCR 上升，说明验证器的假阳性开始主导，应加强门控而不是继续增加轮数。

4.8.3 验证器噪声敏感性

本文建议通过受控注入实验评估噪声验证器的影响。具体做法是：在固定轨迹集上，以不同概率注入假阳性（把有害修正判为通过）和假阴性（把有益修正判为拒绝），观察 HCR、成功率和升级率的变化。该实验不依赖真实模型训练，可以独立检验命题 2 的趋势。注入概率、样本量和统计方法标为 [TODO: 噪声注入实验待完成]。

4.8.4 示意性案例

以下案例用于说明流程，不是实测结果，也不代表任何真实企业或客户。

某客户请求退款，订单已超过政策允许的退款窗口。Agent 检索到订单记录和退款政策，生成退款方案。L0 的策略引擎检查发现违反退款窗口条款，返回拒绝并引用具体条款。反思器提出两个候选：一是按例外条款申请人工审批；二是提供等值优惠券。验证器对两个候选进行评估：检索验证器确认例外条款存在但需要主管批准；模型验证器认为优惠券方案风险较低；风险门控将退款动作定为级别 2，因金额超过阈值而要求人工审批。系统生成升级包，包含政策条款、订单证据、两个候选方案、风险评分和回滚方案。人工审批选择优惠券方案，系统执行并记录审计链。

该案例展示了 RESTORE 的核心行为：反思不是绕过政策，而是把“政策拒绝”转化为“可选方案与升级请求”；风险门控不是阻止任务完成，而是把不可逆或高影响动作交给有权限的人。案例中的金额、阈值和角色均为示意，不对应真实配置。

4.8.5 失败案例与缓解

表 11 总结常见失败模式及其缓解措施。

失败模式	表现	可能原因	缓解措施
过度修正	原本正确的输出被改错	验证器假阳性、批评者自信但无证据	提高证据阈值、引入硬否决、人工抽样
证据缺口	系统在没有可验证信号时仍自动修正	证据充分性估计过低、升级阈值过高	默认升级、降低自动修正范围
相关验证错误	生成器与验证器犯同类错误	同源模型、同上下文、同提示	引入外部工具、不同模型、人工判断
记忆过时	旧策略经验在新政策下失效	缺少版本兼容与过期机制	版本绑定、定期重放、过期隔离
记忆投毒	恶意内容被写入长期记忆	写入审查不足、工具输出被注入	签名、隔离、人工复核、回滚
人工瓶颈	升级队列积压，SLA 超时	阈值过严、升级包信息不足	风险分层、升级包模板、批量审核
成本失控	反思轮数或工具调用超预算	缺少预算停止、重试无上限	预算门控、最大轮数、熔断

4.9 统计与可复现性

正式实验应预注册研究问题、主要指标和判读规则，避免事后选择有利结果。每个配置至少运行 5 个随机种子；报告均值、95% 置信区间和效应量。对于成功率类指标，可使用配对 bootstrap 或 McNemar 检验；对于成本和延迟，可使用配对 bootstrap 或 Wilcoxon 符号秩检验；多重比较应使用 Holm-Bonferroni 等方法校正。所有失败运行都应报告，而不是只报告成功案例。

可复现材料应包括：提示模板、工具定义、策略规则、风险分级、验证器版本、模型版本、随机种子、预算配置和脱敏后的轨迹样例。涉及个人信息或商业机密的数据不能直接公开，应提供脱敏版本或合成替代数据。当前版本的材料清单见附录 G，完成状态标为 [TODO: 复现材料待整理]。

4.10 局限

本文当前版本没有报告实测结果，因此不能对 RESTORE 的实际性能、成本或安全性作出经验性结论。框架的有效性仍需在公开基准和企业沙箱中验证。具体局限包括以下方面。

基准效度。 公开基准与企业环境存在差距。τ-bench、WebArena 和 AgentBench 覆盖了工具使用和长程交互，但企业权限、审批、不可逆动作和多租户隔离的复杂度更高。企业沙箱可以补足部分差距，但沙箱本身也是简化模型，可能遗漏真实组织中的例外和灰区。

验证器依赖。 RESTORE 的效果高度依赖验证器的可靠性。若验证器本身存在系统性偏差，证据接地和仲裁只能降低部分风险，不能保证正确。验证器的校准需要带标签数据，而企业中的高质量标签往往稀缺。

人工瓶颈。 高风险动作需要人工审批，这会带来延迟和成本。若升级率过高，系统的吞吐量可能低于纯人工流程；若升级率过低，又可能漏掉高风险情形。如何在两者之间取得平衡，需要按业务场景做实证研究。

理论假设。 第 3.10 节的命题依赖效用可观测、误差独立、边际收益可估计等强假设。真实系统中这些假设往往不成立，因此命题应作为设计分析，而不是性能保证。

多 Agent 与长程任务。 本文主要讨论单 Agent 的反思与修正。多 Agent 场景中的责任归属、信息共享、冲突解决和集体反思更加复杂；长程任务中的记忆漂移、目标漂移和跨会话一致性问题也需要进一步研究。

合规与法律。本文提供的是工程与治理设计，不构成法律意见。不同司法辖区对自动化决策、个人信息处理和高风险 AI 的要求不同，具体部署需由合规团队评估。

5 Discussion

5.1 为什么证据接地是必要条件

企业环境的一个悖论是：可验证信号很多，但可用的验证信号很少。数据库约束、测试、策略引擎、工单状态和制度文档都可以提供外部锚点，但它们往往分散在不同系统、受权限保护、格式不统一，且存在版本和时效问题。模型可以在提示词中“引用”这些信息，但引用不等于验证：模型可能引用过时文档，可能把相似条款混为一谈，也可能编造一个看起来合理的来源。

证据接地的核心不是让反思“看起来更有依据”，而是让每一条批评都能被独立检查。批评中的每个关键声明都应指向一个证据标识；验证器可以重新读取该证据，检查它是否支持该声明；审计员可以在事后复现这条链路。这样，反思就从“模型说它错了”变成“证据显示它在某个条件下不满足某个约束”。前者难以反驳，后者可以被检验、被质疑、被修正。

这也解释了为什么单纯的自我精炼在企业场景中不够。Self-Refine 和 Reflexion 的价值在于低成本地探索改进空间，但它们不提供独立的真实性保证[2,3]。当任务本身可验证时，应优先使用外部验证；当任务不可验证时，应降低自动化程度，而不是增加反思轮数。Huang 等人的发现提醒我们，模型的内在自我修正可能无法突破自身知识边界[5]。证据接地不是对模型能力的补充，而是对模型判断的外部约束。

5.2 何时不该修正

自我修正文献往往隐含一个假设：更多的反思会带来更好的结果。企业场景不成立。修正本身有成本、有风险、有时延；在某些情况下，最好的动作是停止、回滚或升级人工。

从决策论角度看，是否修正取决于修正的期望收益是否超过其成本与风险。若验证器不确定、证据不足、动作不可逆，修正的期望收益可能为负。此时，继续让模型“再想想”不仅浪费预算，还可能把原本可以接受的结果改坏。一个诚实的升级请求，胜过一个自信的错误修正。

这也涉及自动化偏差：当系统给出一个看起来合理的修正方案时，人工审核者可能倾向于批准，而不是独立核查。若升级包只展示 Agent 的推荐答案，人工监督就会退化为橡皮图章。升级包应展示不确定性、备选方案和证据冲突，让人工看到“系统为什么不确定”，而不是只看到“系统建议什么”。

5.3 企业自我修正的控制论视角

可以把企业级 Agent 的自我修正看作一个带延迟、噪声和约束的反馈控制问题。证据账本是传感器，记录系统状态和外部反馈；验证器是观测器，估计当前动作是否接近目标；反思器是控制器，根据误差提出修正；风险门控是执行器前的安全联锁，决定修正是否允许生效；审计账本是飞行记录仪，保留决策链；人工作为监督者，在系统不确定或超出权限时接管。

这个视角带来两个推论。第一，没有外部锚点的反馈回路会漂移。模型自评只在模型的知识范围内有效；当错误来自知识缺失、工具故障或策略变化时，自我反思无法识别。第二，控制强度应与风险匹配。对低风险、可逆动作，可以允许更激进的自动修正；对高风险、不可逆动作，应把控制点前移到执行之前，而不是依赖执行后的补救。

控制论视角也提醒我们，系统的稳定性不仅取决于控制器，还取决于传感器和执行器的可靠性。一个失效的验证器会给出错误的观测，一个被污染的工具会给出错误的状态，一个被绕过的网关会让门控失效。因此，RESTORE 把证据签名、权限检查、硬否决和审计放在与反思同等重要的位置。

5.4 组织与伦理影响

企业级 Agent 的自我修正不只是技术问题，也是组织问题。谁对 Agent 的修正负责？当 Agent 修改了客户记录或拒绝了退款，客户如何申诉？当人工审核者批准了一个错误修正，责任如何分配？这些问题不能由模型回答，必须由组织制度回答。

本文建议至少明确三类责任：操作责任，由运行团队负责监控、告警和事件响应；审批责任，由业务或风险负责人对高风险修正签字；审计责任，由独立审计角色检查决策链和合规性。职责分离可以降低单点滥用和“集体沉默”的风险。

伦理上，企业应避免把高风险决策完全交给自动修正。对于影响个人权益、财务安全或法律义务的动作，应保留人工复核、申诉和纠正渠道。证据账本中的个人信息应最小化收集、限定用途、控制访问，并遵守适用的数据保护要求。反思记忆可能包含历史客户数据，跨租户或跨用途的复用需要额外审查。

此外，自动化偏差、验证器偏见和记忆投毒都可能对特定群体造成不平等影响。例如，若验证器在某一类客户数据上表现较差，系统可能更频繁地拒绝或升级这些客户，形成隐性歧视。企业应在评测中按群体分层报告指标，并对高风险差异进行人工审查。本文不提供法律或伦理合规的最终判断；具体部署应引入法务、合规和伦理审查。

5.5 适用边界

RESTORE 最适合以下场景：任务有可验证的中间信号；动作以低至中风险为主；有明确的人工升级通道；业务愿意为审计和验证支付额外成本；任务量足够大，能够摊薄验证器和人工流程的建设成本。

在以下场景中，RESTORE 需要更严格的约束或可能不适用：任务目标完全主观、缺少可验证反馈；动作高度不可逆且无法人工及时介入；对延迟极度敏感，无法承担验证开销；数据高度敏感，无法记录足够的证据；组织没有明确的风险负责人和审计流程。此时，更合适的选择可能是限制 Agent 的自主范围，而不是增加反思轮数。

6 Conclusion

6.1 总结

本文讨论了企业级 AI Agent 系统中的反思与自我修正问题。本文的出发点是：企业环境中的错误具有真实副作用，反思与修正必须在证据、权限、风险和预算约束下进行。本文提出 RESTORE 框架，将自我修正组织为六个环节：执行证据账本、分层反思、验证器集成与仲裁、风险感知门控、带来源标注的反思记忆、人工升级与审计。本文给出了问题形式化、门控规则、动作风险分级、记忆治理和推理流程，并在理想验证器、噪声验证器和预算约束三种情形下给出设计性质分析。

本文没有报告实测结果。当前版本的价值在于提供一个可检验的设计基线：它明确了企业级自我修正需要哪些控制点，如何把评测信号接入运行时决策，以及如何在不牺牲可追责性的前提下使用模型反思。框架的实际效果仍需通过第 4 节的实验设计验证；在完成实验之前，本文不对其性能、成本或安全性作出经验性结论。

6.2 未来工作

未来工作可以从以下方向展开。

实证评估。 在 τ-bench、WebArena、AgentBench 和企业沙箱上实现 RESTORE，报告成功率、pass^k、有害修正率、每次成功成本、策略违规率和人工升级负载。重点验证 H1 至 H5，并公开脱敏后的提示、配置和轨迹样例。
验证器校准。 研究验证器在分布偏移、工具版本变化和多租户场景下的可靠性漂移；探索使用保形预测（conformal prediction）为门控阈值提供有限样本保证。
升级策略学习。 将“何时升级人工”建模为成本敏感的决策问题，在安全约束下学习升级策略；评估其与固定阈值策略的差异，并防止策略利用人工审核的盲区。
记忆治理。 研究反思记忆的过期、冲突消解和跨版本迁移；评估记忆投毒检测与回滚机制的有效性；探索多租户隔离下的共享策略库设计。
隐私保护审计。 研究在证据账本中最小化个人信息、支持可验证删除和访问控制的机制；评估审计能力与隐私保护之间的权衡。
多 Agent 与长程任务。 将 RESTORE 扩展到多 Agent 协作场景，研究共享证据、责任归属、集体反思和跨会话一致性；评估长程任务中的目标漂移和记忆漂移。
标准化。 与 AgentOps 的可观测性分类对接，推动审计事件 schema、风险分级和升级包的标准化，降低企业集成成本。

References

[1] Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik Narasimhan, and Yuan Cao. ReAct: Synergizing Reasoning and Acting in Language Models. arXiv:2210.03629, 2022.

[2] Aman Madaan, Niket Tandon, Prakhar Gupta, Skyler Hallinan, Luyu Gao, Sarah Wiegreffe, Uri Alon, Nouha Dziri, Shrimai Prabhumoye, Yiming Yang, Shashank Gupta, Bodhisattwa Prasad Majumder, Katherine Hermann, Sean Welleck, Amir Yazdanbakhsh, and Peter Clark. Self-Refine: Iterative Refinement with Self-Feedback. arXiv:2303.17651, 2023.

[3] Noah Shinn, Federico Cassano, Edward Berman, Ashwin Gopinath, Karthik Narasimhan, and Shunyu Yao. Reflexion: Language Agents with Verbal Reinforcement Learning. arXiv:2303.11366, 2023.

[4] Zhibin Gou, Zhihong Shao, Yeyun Gong, Yelong Shen, Yujiu Yang, Nan Duan, and Weizhu Chen. CRITIC: Large Language Models Can Self-Correct with Tool-Interactive Critiquing. arXiv:2305.11738, 2023. ICLR 2024.

[5] Jie Huang, Xinyun Chen, Swaroop Mishra, Huaixiu Steven Zheng, Adams Wei Yu, Xinying Song, and Denny Zhou. Large Language Models Cannot Self-Correct Reasoning Yet. arXiv:2310.01798, 2023.

[6] Shunyu Yao, Noah Shinn, Pedram Razavi, and Karthik Narasimhan. τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains. arXiv:2406.12045, 2024. ICLR 2025.

[7] Mert Cemri, Melissa Z. Pan, Shuyi Yang, Lakshya A. Agrawal, Bhavya Chopra, Rishabh Tiwari, Kurt Keutzer, Aditya G. Parameswaran, Dan Klein, Kannan Ramchandran, Matei A. Zaharia, Joseph E. Gonzalez, and Ion Stoica. Why Do Multi-Agent LLM Systems Fail? arXiv:2503.13657, 2025. NeurIPS 2025.

[8] Xiao Liu, Hao Yu, Hanchen Zhang, et al. AgentBench: Evaluating LLMs as Agents. arXiv:2308.03688, 2023. ICLR 2024.

[9] Shuyan Zhou, Frank F. Xu, Hao Zhu, Xuhui Zhou, Robert Lo, Abhishek Sridhar, Xianyi Cheng, Tianyue Ou, Yonatan Bisk, Daniel Fried, Uri Alon, and Graham Neubig. WebArena: A Realistic Web Environment for Building Autonomous Agents. arXiv:2307.13854, 2023.

[10] Shehzaad Dhuliawala, Mojtaba Komeili, Jing Xu, Roberta Raileanu, Xian Li, Asli Celikyilmaz, and Jason Weston. Chain-of-Verification Reduces Hallucination in Large Language Models. arXiv:2309.11495, 2023.

[11] Guanzhi Wang, Yuqi Xie, Yunfan Jiang, Ajay Mandlekar, Chaowei Xiao, Yuke Zhu, Linxi Fan, and Anima Anandkumar. Voyager: An Open-Ended Embodied Agent with Large Language Models. arXiv:2305.16291, 2023.

[12] Qingyun Wu, Gagan Bansal, Jieyu Zhang, Yiran Wu, Beibin Li, Erkang Zhu, Li Jiang, Xiaoyun Zhang, Shaokun Zhang, Jiale Liu, Ahmed Hassan Awadallah, Ryen W. White, Doug Burger, and Chi Wang. AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation. arXiv:2308.08155, 2023.

[13] Sirui Hong, Xiawu Zheng, Jonathan Chen, et al. MetaGPT: Meta Programming for Multi-Agent Collaborative Framework. arXiv:2308.00352, 2023.

[14] Shunyu Yao, Dian Yu, Jeffrey Zhao, Izhak Shafran, Thomas L. Griffiths, Yuan Cao, and Karthik Narasimhan. Tree of Thoughts: Deliberate Problem Solving with Large Language Models. arXiv:2305.10601, 2023.

[15] Andy Zhou, Kai Yan, Michal Shlapentokh-Rothman, Haohan Wang, and Yu-Xiong Wang. Language Agent Tree Search Unifies Reasoning, Acting, and Planning in Language Models. arXiv:2310.04406, 2023.

[16] Yuntao Bai, Saurav Kadavath, Sandipan Kundu, Amanda Askell, Jackson Kernion, Andy Jones, Anna Chen, Anna Goldie, Azalia Mirhoseini, et al. Constitutional AI: Harmlessness from AI Feedback. arXiv:2212.08073, 2022.

[17] Lianmin Zheng, Wei-Lin Chiang, Ying Sheng, Siyuan Zhuang, Zhanghao Wu, Yonghao Zhuang, Zi Lin, Zhuohan Li, Dacheng Li, Eric P. Xing, Hao Zhang, Joseph E. Gonzalez, and Ion Stoica. Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena. arXiv:2306.05685, 2023.

[18] Mingchen Zhuge, Changsheng Zhao, Dylan R. Ashley, Wenyi Wang, Dmitrii Khizbullin, Yunyang Xiong, Zechun Liu, Ernie Chang, Raghuraman Krishnamoorthi, Yuandong Tian, Yangyang Shi, Vikas Chandra, and Jürgen Schmidhuber. Agent-as-a-Judge: Evaluate Agents with Agents. arXiv:2410.10934, 2024. ICML 2025.

[19] Liming Dong, Qinghua Lu, and Liming Zhu. AgentOps: Enabling Observability of LLM Agents. arXiv:2411.05285, 2024.

[20] National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100-1, 2023. https://www.nist.gov/itl/ai-risk-management-framework

[21] International Organization for Standardization. ISO/IEC 42001:2023 Information technology — Artificial intelligence — Management system. 2023. https://www.iso.org/standard/42001

说明：以上 arXiv 文献的标题、作者、编号与年份已通过 arXiv 元数据、论文 PDF 或公开检索结果核验；会议信息仅在可核实的情况下标注。本文未引用无法核验的来源。

Appendix

附录 A 符号表

表 A.1 汇总本文使用的主要符号。

符号	含义
$\mathcal{E}$	企业环境
$\mathcal{S}$	业务状态空间
$\mathcal{A}$	动作空间
$\mathcal{O}$	观测空间
$\mathcal{T}$	工具集合
$\mathcal{C}$	策略与权限约束
$\rho$	动作风险函数
$\mathcal{G}$	目标规范
$\pi_\theta$	Agent 策略
$\tau$	执行轨迹
$\mathcal{E}_\tau$	轨迹对应的证据集合
$z$	批评集合
$\delta$	修复建议
$\kappa$	修正算子
$\Gamma$	门控函数
$\Delta U$	修正带来的效用变化
$\mathrm{ES}$	证据充分性
$B$	风险预算
$B_c$	成本预算
$B_\ell$	时延预算
$K$	最大修正轮数
$K_1$	L1 最大重试次数
$D$	验证器分歧度
$\mathcal{M}$	反思记忆
$\sigma(\tau)$	轨迹的失败签名
$C_{\mathrm{round}}$	单轮修正成本
$C_{\mathrm{total}}$	单 episode 总成本

附录 B 命题证明

B.1 命题 1 的证明

设初始效用为 $U_0$ 。若第 $t$ 次修正被接受，则根据命题 1 的假设， $\Delta U_t=U_{t+1}-U_t\ge0$ ，因此 $U_{t+1}\ge U_t$ 。若修正被拒绝、回滚或升级，已完成动作的效用不变，或由补偿动作恢复到不劣于原状态。对 $t=1,\dots,K$ 归纳，得到 $U_K\ge U_0$ 。命题成立。

需要注意，该证明假设效用在同一尺度上可比较，且修正的延迟副作用已经计入 $\Delta U$ 。若副作用在事后才显现，或者效用估计本身有偏，则单调性不成立。这正是第 3.10.3 节讨论噪声验证器的原因。

B.2 命题 2 的证明

设每轮修正独立地以概率 $\epsilon$ 有害。 $K$ 轮中没有任何有害修正的概率为 $(1-\epsilon)^K$ ，因此至少发生一次有害修正的概率为 $1-(1-\epsilon)^K$ ，即式（20）。

对于期望效用，单轮以概率 $1-\epsilon$ 获得收益 $G$ ，以概率 $\epsilon$ 承受损失 $H$ ，故：

$\mathbb{E}[\Delta U]=(1-\epsilon)G-\epsilon H=G-\epsilon(G+H) \tag{B.1}$

当 $G-\epsilon(G+H)<0$ ，即 $\epsilon>G/(G+H)$ 时，单轮期望效用为负；在轮次可加的近似下，总期望效用随 $K$ 下降。命题成立。

该证明假设每轮的 $G$ 和 $H$ 为常数、轮次独立。现实中错误可能相关，收益可能递减，损失可能非线性；这些因素可能加剧而非缓解误差放大。因此，式（20）和式（21）应视为下界性质的示意，而不是精确预测。

B.3 命题 3 的证明

定义截至第 $K$ 轮的累计净收益：

$\Delta(K)=\sum_{k=1}^{K}\left(G_k-\lambda_c C_k\right) \tag{B.2}$

第 $K$ 轮的边际项为 $M_K=G_K-\lambda_c C_K$ 。由于 $G_k$ 非增、 $C_k$ 非减， $M_K$ 非增。因此， $\Delta(K)$ 在 $M_K\ge0$ 时继续上升，在 $M_K<0$ 时开始下降。最大值出现在满足 $M_K\ge0$ 的最大 $K$ 处，即式（22）。若 $M_1<0$ ，则最优选择是不修正（ $K^*=0$ ）。命题成立。

该证明忽略了跨轮交互：一次修正可能改变后续轮次的收益分布，也可能引入新的风险。因此，式（22）是近似最优停止规则，不是全局最优策略。

B.4 推论 1 的证明

始终使用昂贵验证器的成本为 $c_2$ 。级联策略先支付 $c_1$ ；廉价验证器以概率 $p_1$ 给出结论并停止，否则以概率 $1-p_1$ 继续支付 $c_2$ 。因此期望成本为：

$\mathbb{E}[C_{\mathrm{ver}}]=c_1+(1-p_1)c_2 \tag{B.3}$

要使其小于 $c_2$ ，需要：

$c_1+(1-p_1)c_2<c_2 \iff c_1<p_1c_2 \tag{B.4}$

即式（24）。推论成立。

该推论假设廉价验证器的结论是可靠的，且不会引入额外的错误。若廉价验证器经常误判，级联策略虽然省钱，却可能降低整体质量；因此，级联的前提是廉价验证器在简单案例上具有足够高的精度。

附录 C 反思提示模板（草案）

以下模板用于说明 RESTORE 对反思输出的结构化要求。模板是草案，具体措辞、示例和阈值需在实验中校准，标为 [TODO: 提示模板校准待完成]。

C.1 反思提示模板

你是企业级 Agent 的反思模块。你的任务不是重新回答用户问题，而是基于给定的执行轨迹和证据，
判断当前动作是否存在问题，并提出最小必要的修复建议。

约束：
1. 每条批评必须引用证据 ID；没有证据支持的批评必须标记为"无依据"，不得进入自动修正。
2. 区分"观察到的事实"与"推断"；推断必须说明依据和不确定性。
3. 不得建议扩大权限、绕过策略或跳过审计。
4. 若证据不足，输出 escalate，而不是猜测。
5. 修复建议必须说明适用范围、预期效果、潜在副作用和回滚方式。

输入：
- 目标：{goal}
- 当前计划：{plan}
- 执行轨迹：{trace}
- 证据列表：{evidence}
- 策略约束：{policy}
- 风险等级：{risk_level}

输出 JSON：
{
  "claims": [
    {
      "claim": "...",
      "evidence_ids": ["..."],
      "severity": "low|medium|high",
      "confidence": 0.0
    }
  ],
  "diagnosis": "...",
  "repair": {
    "type": "retry|replan|rollback|escalate",
    "description": "...",
    "scope": "...",
    "side_effects": "...",
    "rollback_plan": "..."
  },
  "evidence_sufficiency": 0.0,
  "requires_human": true
}

C.2 验证器评分模板

请评估修复建议 δ 是否应被接受。评分维度：
- 正确性：修复是否解决已识别的问题？
- 证据支持：建议是否由证据支持？引用是否准确？
- 策略合规：建议是否违反权限、业务规则或监管要求？
- 风险：建议的副作用、可逆性和影响范围如何？
- 可执行性：所需工具和信息是否可用？

硬失败条件（任一满足则 overall = 0）：
- 建议扩大权限或绕过策略；
- 关键证据缺失或引用不成立；
- 动作属于不可逆高风险类别且无人工审批。

输出 JSON：
{
  "correctness": 0.0,
  "evidence_support": 0.0,
  "policy_compliance": 0.0,
  "risk": 0.0,
  "feasibility": 0.0,
  "hard_fail": false,
  "rationale": "...",
  "evidence_ids": ["..."]
}

C.3 升级包模板

【任务】{goal}
【当前状态】{state}
【建议动作】{proposed_action}
【变更摘要】{diff}
【支撑证据】{evidence_summary}
【验证器意见】{verifier_votes}
【风险等级】{risk_level} / {risk_score}
【备选方案】{alternatives}
【回滚方案】{rollback_plan}
【策略版本】{policy_version}
【系统置信度】{confidence}
【建议处理时限】{sla}
【需要人工决定的问题】{decision_question}

附录 D 审计事件模式

以下 JSON 给出审计事件的字段草案。实际部署应使用确定性序列化（canonical serialization）计算哈希，并对敏感字段进行脱敏或加密引用。

{
  "event_id": "evt_...",
  "episode_id": "ep_...",
  "parent_event_id": "evt_...",
  "timestamp": "2026-10-20T00:00:00Z",
  "tenant_id": "tenant_...",
  "actor": {
    "type": "agent|human|tool",
    "role": "planner|executor|reflector|verifier|human",
    "id": "...",
    "version": "..."
  },
  "action": {
    "type": "tool_call|message|approval|rollback",
    "tool": "...",
    "args_hash": "...",
    "policy_decision": "allow|deny|escalate",
    "risk_class": 0
  },
  "observation": {
    "status": "ok|error|timeout",
    "output_hash": "...",
    "summary": "..."
  },
  "evidence_refs": ["evt_..."],
  "reflection": {
    "tier": "L0|L1|L2|L3",
    "claims": [
      {
        "claim": "...",
        "evidence_ids": ["evt_..."],
        "severity": "low|medium|high"
      }
    ],
    "repair_type": "retry|replan|rollback|escalate"
  },
  "verifier_votes": [
    {
      "verifier": "policy|test|retrieval|model|human",
      "score": 0.0,
      "threshold": 0.0,
      "hard_fail": false
    }
  ],
  "decision": {
    "gate": "accept|rollback|escalate|stop",
    "reason": "...",
    "approver": "human_...",
    "policy_version": "..."
  },
  "prev_hash": "...",
  "hash": "..."
}

事件模式应遵循最小必要原则：只记录审计所需的信息，避免把完整的客户数据、密钥或内部文档写入日志。高敏感字段可以只保存哈希和加密引用，访问时通过独立授权解密。

附录 E 威胁模型与缓解

表 E.1 汇总主要威胁、攻击向量与缓解措施。

威胁	攻击向量	潜在影响	缓解措施
提示注入	恶意文档、网页或工具输出中包含指令	伪造证据、绕过策略、诱导错误修正	将工具输出视为不可信内容；隔离指令与数据；策略引擎硬否决；工具白名单
反思记忆投毒	对抗性 episode 写入错误经验	长期错误行为、跨任务传播	写入审查、来源签名、隔离区、过期与回滚、租户隔离
验证器操纵	伪造测试结果、污染检索源、入侵工具	假阳性接受、错误修正	工具输出签名、沙箱执行、独立验证、抽样人工复核
权限提升	修正建议调用更高权限工具	越权操作、数据泄露	每次动作重新授权；最小权限；修正不得扩权；双人审批
数据外泄	工具调用或检索请求携带敏感数据	隐私泄露、合规违规	数据分级、脱敏、出站控制、数据防泄漏（Data Loss Prevention，DLP）、访问审计
成本耗尽攻击	无界反思或工具调用（denial of wallet）	成本失控、服务不可用	预算上限、最大轮数、熔断、租户配额
自动化偏差	人工过度信任 Agent 建议	橡皮图章、错误批准	展示不确定性与备选方案、抽样审计、培训、审批质量指标
模型漂移	模型版本更新或提示变更	行为变化、验证器失准	版本固定、回归测试、灰度发布、回滚
供应链风险	第三方工具或模型组件被篡改	后门、数据泄露	依赖审计、签名校验、隔离部署、供应商评估

附录 F 企业部署检查清单

所有有副作用的动作都经过统一工具网关，且网关实施权限检查和审计记录。
动作风险分级由业务、风控、法务和安全团队共同确认，并有版本记录。
策略引擎独立于模型，能够对高风险动作实施硬否决。
证据账本启用哈希链、访问控制、脱敏和保留策略。
多租户数据在存储、检索和反思记忆层面隔离。
验证器经过校准，定期测量精度、召回率和相关性。
反思记忆有来源、置信度、适用范围、过期时间和回滚机制。
人工升级包包含证据、备选方案、风险评分和回滚方案。
升级 SLA、审批角色和职责分离已写入制度。
预算、最大修正轮数、熔断和紧急停止开关（kill switch）已配置。
灰度发布、回归测试和策略回滚流程已演练。
评测覆盖成功率、pass^k、有害修正率、成本、延迟和策略违规率。
个人信息处理、跨境传输和日志保留已由合规团队审查。
事件响应流程覆盖 Agent 错误、数据泄露和权限滥用。
操作员、审核员和审计员已完成培训，并理解自动化偏差风险。

附录 G 实验记录与待办清单

确定基础模型、版本和解码参数。
实现 ReAct、Self-Refine、Reflexion、CRITIC 基线，并匹配预算。
构建企业沙箱，定义工具、权限、风险等级和审计日志。
与风险负责人确定动作分级和风险阈值。
校准证据质量、验证器权重、聚合阈值和分歧阈值。
在验证集上调整最大修正轮数 $K$ 和 L1 重试次数 $K_1$ 。
运行至少 5 个随机种子，报告置信区间和效应量。
完成主实验、消融实验和验证器噪声注入实验。
进行人工评估，报告标注者一致性和升级包可用性。
整理脱敏后的提示、配置、轨迹样例和复现脚本。
完成隐私、安全和合规审查。
在正式报告中明确区分实测结果、设计假设和未验证内容。

当前状态：框架设计、形式化分析与实验协议已完成；实证评估、企业沙箱构建、验证器校准和人工评估尚未完成。本文不报告任何未经实验支持的数值结论。

北京朝阳AI社区

更多推荐

【开源深度评测】Craft Anything：证据、工具注册与模式边界，比“看懂软件”更值得研究

北京朝阳AI社区

工具能写文案，替不了理解客户，陈卫军谈人工智能

工具写不出的，恰恰是客户在意的那一句。没听过客户在电话里犹豫的那三秒，没看过客户摸完面料之后的反应，写出来的东西就只能停在参数上。反过来，先让工具写、人再改，改的往往不是字，是方向，效率反而更低。工具再生成时，喂进去的是真话，出来的才像人话。在陈卫军看来，人工智能进店之后，人的位置不是被挤掉，而是被推到了更前面——离客户更近的那一端。往后做生意，拼的不是谁写得多，而是谁更清楚客户那句话背后的意思。