@yoheinakajima: 在 arxiv 论文 #2 中，我处理了论文 #1 中的最后一个主题：@activegraphai 作为自我改进代理的架构可供性 self-improv…

在 arxiv 论文 #2 中，我处理了论文 #1 的最后一个主题：@activegraphai 作为自我改进智能体的架构使能“Regimes：一个可审计、留出验证门控的改进循环，在 LongMemEval 上使用 ActiveGraph 进行演示”我通过一个可重现的门控自我改进循环展示了这一点，该循环在 longmemeval 问题上自主显示出适度的改进。论文：https://arxiv.org/abs/2606.10241 —— # 一个可审计、留出验证门控的改进循环：在 LongMemEval 上使用 ActiveGraph 进行演示 来源：https://arxiv.org/html/2606.10241（2026 年 6 月 8 日） ###### 摘要 自主改进循环难以信任，因为改进过程通常是附加在智能体上的外部脚手架：失败未被记录，诊断无法重放，每个提升或丢弃的决策都落在侧数据库中，而非智能体自身的历史中。我们表明，一个事件溯源的智能体运行时消除了这一摩擦，并将受控改进转变为头等的工作流。当智能体的状态是仅追加事件日志的确定性投影时，失败被记录，记录的运行从日志中精确重放，候选补丁限定于类型化的流水线接缝，门控可审计，且每次提升或丢弃本身就是一个事件。我们使用 Regimes 进行演示，这是一个基于 ActiveGraph 运行时的改进循环。Regimes 诊断失败的评估，在智能体流水线的特定点提出修复，并仅当该修复通过静态检查、沙盒执行、样本内评估和留出示例验证时，才提升该修复。该循环是目标无关的：通过一个通用接口，相同的控制流可针对不同的智能体任务运行。ActiveGraph 使得这一过程可审计而非仅凭传闻：该运行时是事件溯源的，因此记录的运行从日志中确定性地重放，模型和工具响应被缓存（在缓存可用时）以进行精确重放，并且循环自身的历史（诊断、提议修复、门控结果、提升或丢弃）本身就是一个可审计的事件日志，而非一个侧数据库。我们在 LongMemEval-S 上演示该循环，其中主要的失败不是检索，而是调和：相关证据已存在于已整理的上下文中，但读取器仍然回答错误。在五个带种子的留出划分上，Regimes 发现了读取器提示的修复，这些修复使最终留出准确率在四个划分中提升了 +0.05 到 +0.10，在一个过度提升的划分中提升了 +0.01。两个划分在简单的配对检验下各自显著（种子 5 的值未经其四步顺序提升结构校正）；合并的翻转计数为正，但应视为描述性结果，因为这些划分来自同一 500 问题池。详细统计数据（每划分的 McNemar 检验、合并的不一致数以及同池注意事项）位于结果部分而非此处。案例研究展示了自主改进的希望与局限。留出验证门控拒绝了许多过拟合候选，包括几乎所有检索重加权修复，而弱划分揭示了一个具体的下一步改进：更严格的提升阈值和考虑平台期的停止规则。更广泛地说，发现的提示修复自身指向更远：其成功揭示了哪些证据使用行为重要，而其退化则揭示了何时不应触发该行为。持久的智能体改进应将这些行为转化为受保护的确定性算子，这些算子基于检测到的结构而不是粗略的散文规则进行条件判断。持久的贡献包括：ActiveGraph 作为可审计的基础设施，使得受控改进循环变得可行；其支持的可重现的留出验证门控循环；将每个失败路由到流水线位置的失败机制分类法（其相对于未路由基线的边际价值是主要的开放问题）；以及提示作为发现探针的假设。 ## 1 引言 长时间运行的智能体会以重复且可诊断的方式失败。随着智能体积累历史、在其上检索、整理上下文并读取该上下文以回答问题，每个阶段都可能出错，且相同的错误类型会重复出现。缺失的不是另一个点修复，而是一个循环：能够检测到重复的失败，提出修复，安全地测试修复，并且仅在修复对未经过度调优的示例有效时才保留它。本文提出了这样一个循环，称为 Regimes，并以一个智能体任务作为详细的案例研究。两个自然语言层面的承诺塑造了设计。首先，一个修复仅在它对留出示例有效时才被保留，而不仅仅是对用于编写它的示例有效。我们称之为留出验证门控的提升，它将真正的改进与仅仅过拟合循环偶然看到的候选区分开来。其次，相同的循环应能在不重写其核心的情况下针对不同的智能体任务运行。我们称之为目标无关性：诊断、门控和轮换逻辑通过一个通用接口与任何任务对话，仅任务特定的部分（如何评估它，其流水线的哪些部分可以编辑，如何标记其失败）被替换。ActiveGraph 是核心故事的一部分，而非部署细节。该循环运行在 ActiveGraph 运行时上（Nakajima，2026（https://arxiv.org/html/2606.10241#bib.bib4）），这是一个事件溯源系统，其状态是仅追加事件日志的确定性投影，并带有记录模型和工具响应的缓存。这就是使自主改进可审计而非仅凭传闻的原因：一次运行从其日志中精确重放，无需新的模型调用，评估受控且可重复，循环自身的历史（每次诊断、每个提议修复、每个门控结果、每次提升或丢弃）本身就是一个可审计的事件日志，而非一个侧数据库。自我改进的主张的可信度取决于记录它的基础设施，而事件溯源的基础设施让读者能够审计每一步。这就是基础设施而非算法成为杠杆的地方。案例研究是 LongMemEval-S（Wu et al.，2024（https://arxiv.org/html/2606.10241#bib.bib7）），一个长上下文记忆基准。在同一基础设施上的先前分析发现，确定性检索大多数时候已将正确的证据放入上下文，因此主要的剩余失败不是检索，而是调和：相关证据存在于已整理的上下文中，但读取器仍然回答错误。我们给这个失败起了一个简短名称以便复用，即 assembly-internal，意指证据已被整理到上下文中但使用不当。重新排序检索到的轮次无法修复它，因为这些轮次已在上下文中；只有改变读取器使用证据的方式才能做到。该循环有一个小型词汇表，在此一次性定义并一致使用。失败机制是诊断出的问题失败原因（例如，证据在上下文预算处被丢弃，或 assembly-internal）。动作接缝是流水线中循环允许编辑的部分（重新加权检索分数，重新排序已整理的轮次，或编辑读取器的提示）。机制到接缝的映射是从诊断出的机制到可处理它的接缝的固定路由。因此，循环用一句话概括为：诊断主要的失败机制，将其路由到对应的接缝，让语言模型在该接缝处编写一个修复，并仅当修复通过静态检查、沙盒执行、样本内评估和留出验证时才提升它。修复是可执行的补丁，针对命名的流水线点；对于调和案例研究，重要的接缝编辑读取器提示片段，因此有效的修复是读取器提示编辑，而非任意生成的运行时代码。一个想法贯穿全文，值得一开始就直白陈述：被提升的提示不是终点。一个提示修复是一个高带宽的探针。当独立发现的修复不断编码相同的证据使用行为，而它们偶尔的退化恰好揭示了该行为何时不应触发时，提示已指向一个候选的确定性算子。该循环的持久价值较少在于它提升的提示，而更多在于该提示所揭示的算子。这将适度的准确率增益重新定位为一种发现工具，并连接了案例研究结果（第 5 节）、失败分析（第 5.9 节）和未来议程（第 8 节）。这也是为什么基础设施在实验之后仍然重要：这些探针揭示的算子应该作为事件日志本身的类型化投影（第 8.4 节）。Regimes 处于四个成熟方向的交汇点：自我改进智能体（SICA，Robeyns et al.（2025（https://arxiv.org/html/2606.10241#bib.bib5））；GRASP，Moll et al.（2026（https://arxiv.org/html/2606.10241#bib.bib3）））、留出验证的提示与程序优化（DSPy，Khattab et al.（2023（https://arxiv.org/html/2606.10241#bib.bib2）））、可执行的失败模式分析（MAST，Cemri et al.（2025（https://arxiv.org/html/2606.10241#bib.bib1））；AgentDebug，Zhu et al.（2025（https://arxiv.org/html/2606.10241#bib.bib10）））以及长上下文记忆基准（LongMemEval 和 LongMemEval-V2；Wu et al.，2024（https://arxiv.org/html/2606.10241#bib.bib7）；Wu et al.，2026（https://arxiv.org/html/2606.10241#bib.bib8））。贡献从使能基础设施到具体案例研究排序如下： 1. 1.ActiveGraph 作为受控改进循环的可审计基础设施：事件溯源、从日志进行确定性重放、缓存的模型和工具响应，以及循环自身历史记录为事件，使得自主改进易于构建、重放、检查、约束和审计。实证部分表明这种能力是真实的：循环干净地跨任务重新定位（第 4 节），并产生一个经过留出验证、完全可审计的改进运行（第 5、6 节）。 2. 2.Regimes 作为建立在该基础设施之上的一个改进循环：诊断、提议、门控、提升、轮换，完整历史记录为事件，在一种读取器下对一项任务（LongMemEval-S）进行了演示。其目标无关性在接口和控制流层面确立，而非作为多任务实证结果。 3. 3.一个拒绝过拟合修复的留出提升门控，在动作空间扩展到自由文本提示编辑之前已安装。门控是循环的信任护栏，也是它与先前门控优化器（DSPy、GRASP）共享的组件，而非其新颖之处：一次运行的样本内 +0.18 降至留出 +0.04，门控将过拟合部分拒之门外。 4. 4.一个失败机制分类法，将每个失败路由到可处理的流水线位置（评分、组装或读取器提示）。路由是循环的组织启发式方法；诊断步骤是否在向留出门控的作者提供失败示例之外增加价值，在此仅得到间接支持，是主要的开放问题（第 5.8 节，威胁 11）。 5. 5.一个 LongMemEval-S 案例研究，显示出适度但一致的改进：五个带种子划分中四个的留出增益为 +0.05 到 +0.10，第五个接近零，而第五个划分本身是一个有信息量的过度提升发现。 6. 6.一个假设，从发现的修复和两个分析的退化中归纳得出：提示修复是有用的发现探针，但之后应成为受保护的确定性算子，基于检测到的结构而非粗略的散文规则触发。此处未构建或评估任何算子；这是一个前瞻性赌注，而非实验结果。基础设施支持的循环在接口和控制流层面是目标无关的，通过将循环以字节相同的循环行为重新定位到一个结构不同的第二任务（文本到 SQL）上进行了演示。我们并未声称循环在多个任务上进行了实证改进；测量的改进特定于单一读取器（claude-sonnet-4-6）下的 LongMemEval-S。经过校准的声明一次性陈述以框定后续内容：一个事件溯源运行时使得诊断-路由-修复循环变得可行且可审计，并且在 LongMemEval-S 上，该循环产生了一个适度、方向一致的留出改进，五个划分中两个各自显著，合并计数仅作为描述性的同池摘要显著。持久的贡献是基础设施支持的机制加上其提示修复所揭示的证据使用算子，而非基准上的新纪录。读者指南。论文有一条主线：事件溯源运行时使受控改进循环变得可行，Regimes 是这样一个循环，LongMemEval 是压力测试，受保护算子则是结论。第 2 节将该工作置于自我改进智能体、提示优化和失败分类法之中。第 3 节定义循环及其词汇。第 4 节通过将循环重新定位到第二个任务来测试其是否真正目标无关。第 5 节报告 LongMemEval 案例研究，包括多种子复制和种子-101 过度提升发现。第 6 节审计测量本身，包括机制分类器和确定性声明。第 7 节列出威胁。第 8 节论证为什么被提升的提示自身指向受保护算子，并简要勾勒设计。第 9 节和第 10 节给出设计教训并总结。 ## 2 背景与相关工作 自我改进与门控循环。SICA（Robeyns et al.，2025（https://arxiv.org/html/2606.10241#bib.bib5））展示了一个 LLM 编码智能体，它编辑自己的代码库以提高基准性能，消除了元智能体与目标智能体的分离。Regimes 表明改进循环可以在事件溯源基础设施上保持目标无关性的同时，保留确定性重放能力。Reflexion（Shinn et al.，2023（https://arxiv.org/html/2606.10241#bib.bib6））是基础性的口头反思先驱，其中智能体编写失败轨迹的自然语言批评，并在后续尝试中以此作为条件。ExpeL（Zhao et al.，2024（https://arxiv.org/html/2606.10241#bib.bib9））将口头反馈扩展到跨轨迹规则提取。最接近的同辈是 GRASP（Moll et al.，2026（https://arxiv.org/html/2606.10241#bib.bib3）），值得精确比较，因为这是本文贡献最容易被误读之处。GRASP 的重心是一种算法性的自我改进方法：提出自然语言技能，通过留出性能进行门控，并保留那些泛化的技能。Regimes 的重心是一个运行时故事：如果智能体建立在事件溯源图上，那么改进循环自然易于构建、重放、限定范围和审计，而 Regimes 正是这样一个循环。两者确实在一个独立得出的发现上重叠：验证门控，而非技能或转换编写器，是使结果真实的组件。GRASP 通过消融研究（去除门控后准确率降至基线）证明了这一点；Regimes 通过留出门控丢弃过拟合转换和折扣过拟合提示子句来证明。但门控是共享的先前技术（DSPy 在 2023 年就已依赖留出验证），并非区分因素。Regimes 增加的内容位于门控之前和之后：基础设施使整个循环成为头等工作流，因此失败被记录，诊断确定性重放，候选补丁限定于类型化接缝，每次提升或丢弃的决策是智能体历史中的一个事件，而不是外部表中的一行。两种方法在编辑内容和目标方向上也不同：GRASP 门控一个自然语言技能库作为部署产物，用于结构化程序环境（FHIR ta