通过将用户纠正编译为运行时强制执行机制，让编码智能体更好地与用户协作 Getting Better at Working With You: Compiling User Corrections into Runtime Enforcement for Coding Agents
将用户纠正转化为运行时强制规则，解决智能体重复犯错问题
前置知识
访问-合规差距（Access-Compliance Gap）
指在交互式智能体系统中，即使用户的纠正信息被成功存储、检索并呈现给智能体，智能体仍然可能不遵循这些纠正的现象。这个差距的核心问题是：记忆或上下文中存在纠正确认不等于执行时的强制约束。例如，用户告诉智能体清理调试文件后停止，智能体可能在后续会话中回忆起这个指令，但仍然在完成任务前遗留调试文件。
这是本文要解决的核心问题，理解这个差距是读懂 Trace 方法的前提。论文通过诊断实验量化了这一差距：即使纠正被检索并放入上下文，智能体仅满足 31.6%-55.0% 的适用偏好检查。
原子规则（Atomic Rules）
从用户自然语言纠正中提取的精简指令，包含两个核心组件：规则本身（如清理调试文件）和适用性条件（如在终止前、当创建临时文件时）。原子规则与复杂复合规则相对，每个规则只针对一个明确的行为约束。在 Trace 的部署中，47 条规则构成层次化库：37 条原子规则、7 条细化规则、3 条复合规则。
Trace 的核心创新是将纠正从自然语言建议转换为原子规则。原子规则的可执行性使得它们能被编译为运行时检查器，而不仅是可检索的文本。这是解决访问-合规差距的关键技术转换。
运行时强制执行（Runtime Enforcement）
在智能体执行过程中主动验证并强制约束满足的机制，通过在关键事件点（如提示、工具使用、文件写入、终止）注册验证器来实现。当验证器失败时，钩子会拦截事件并向智能体报告违规详情，迫使智能体修订响应直到合规。验证器支持三层实现：确定层（通过工具调用结构、命令参数验证）、语义层（通过模型生成的文本或编辑文件验证）、意图层（触发运行时提醒）。
这是 Trace 将纠正从建议转变为强制约束的技术手段。与仅在提示中包含纠正不同，运行时强制执行确保智能体必须通过验证器检查才能完成任务。实验表明，编译规则达到 70.1% 合规率，远超 Mem0 的 42.5%。
规则生命周期解析（Rule Lifecycle Resolution）
当新纠正到达时，Trace 必须决定如何将其与现有规则库整合，这个决策过程称为生命周期解析。解析器执行五个可能的操作：Noop（将支持证据附加到现有规则）、Update（用新细化更新活跃规则）、Supersede（当新纠正与旧规则冲突时停用旧规则）、Split（将复杂纠正分离为多个原子规则）、New（创建新规则）。这五个动作维护规则的三个核心状态组件：纠正证据、当前活跃版本、适用性边界。
纠正流是增量的，规则库不能是静态文档。生命周期解析确保规则库随着用户反馈不断演进，处理重复、细化、冲突和组合等情况。这是 Trace 能持续积累用户知识的关键机制。
研究动机
交互式 LLM 智能体正在成为日常工作的一部分，但它们无法随时间推移变得更易用：在一个会话中记住的纠正可能在下一个会话中仍被违反。论文研究了这一偏好访问与偏好合规之间的差距。在从匿名化真实用户摩擦案例衍生的任务上，即使使用 Mem0 记忆，仍有 57.5% 的适用偏好检查被违反。具体场景包括：用户指示智能体在终止前清理调试文件，但在后续会话中，智能体可能检索到该记忆但仍然遗留文件；用户要求在修改状态前询问，但智能体可能记得这个偏好却仍然直接修改。这些案例揭示了一个简单但被忽视的问题：记忆使纠正可见，但不强制执行。
本文的目标是本文的目标是提出一个端到端的、可插入的技能层流水线，将自然语言用户纠正转换为持续的、按用户的原子规则库，这些规则是运行时可强制执行的。当智能体必须通过相应的检查才能成功完成任务时，个人化从被动的提示侧建议转变为主动的执行约束。具体而言，Trace 旨在将重复的偏好违规从 100% 显著降低，同时保持或超越最强记忆基线的任务成功率。
与已有工作不同的是，本文的独特切入角度是改变纠正的表示形式，而不是扩展记忆容量。现有方法（如 Mem0、ReMe、Hindsight）将纠正作为自然语言建议存储、检索或总结，但这些纠正仍然是 fundamentally natural-language advice。Trace 的创新是将纠正转换为执行时的显式条件：从记住纠正确认可用性，到强制执行纠正确认合规性。这一范式转移从记住这个建议到必须通过这个检查才能完成。论文通过诊断实验量化了表示改变的效果：编译规则达到 70.1% 合规率，而 Mem0 仅 42.5%，Relevant Rules 54.0%。
核心方法
Trace 的整体思路是将实时用户纠正流转换为按用户的、可增长的运行时强制执行规则库。直觉上，这是从被动记忆到主动约束的范式转移：记忆使纠正确可见，强制执行使纠正确必须遵循。技术路线上，Trace 实现为编码智能体运行时的可插入技能层，包含三个核心阶段：首先，纠正信号检测器扫描每个用户消息，判断是否包含持久偏好、重复错误通知或工作流摩擦；其次，规则提取器将纠正记录原子化为规则（简洁指令）和适用性条件；最后，生命周期解析器将候选规则与当前规则库整合，执行五个可能的操作之一（Noop、Update、Supersede、Split、New）。每个规则被编译为执行组件：适用性检查、行为指令、验证器。在后续任务中，匹配规则作为运行时门控加载，只有当所有活跃验证器通过时才允许完成。
核心创新点是将用户纠正从自然语言建议转换为运行时可强制执行的原子规则，这与已有方法的本质区别在于：已有方法（Mem0、ReMe、Hindsight）将纠正作为可检索的文本处理，即使成功检索，智能体可能仍将其视为可选建议而遵循；Trace 则将纠正编译为必须通过才能完成任务的执行约束。这种表示改变的关键在于门控机制：验证器失败时，钩子拦截事件并迫使智能体立即修订响应，而不是事后让用户手动执行纠正。实验显示，Trace 在 ClawArena OOD 任务上将违规率从 100% 降至 2.0%，而 Mem0 仍高达 95.4%。另一个关键区别是规则来源：Trace 挖掘个体用户的动态纠正流，而不是策划的项目指令文件（如 ContextCov）。
方法步骤详情
Trace 的完整流程分为四个步骤：步骤一是实时纠正信号检测。使用轻量级 LLM（Gemma 4 31B）评估每个用户消息是否包含持久偏好、重复错误通知或工作流摩擦。无信号的消息正常通过，检测到信号的消息被路由到编译器。输入是用户消息和当前对话上下文，输出是纠正信号决策。步骤二是纠正记录构建。当检测到信号时，Trace 构建纠正记录，将用户反馈链接到被纠正的具体智能体行为。记录包含原始任务请求、相关智能体动作、相应工作空间状态。输入是纠正信号和上下文，输出是结构化纠正记录。步骤三是规则提取和生命周期解析。从每个纠正记录提取原子规则：简洁指令加上适用性条件。解析器根据新纠正与现有规则库的关系，执行五个操作之一：Noop（附加证据）、Update（细化）、Supersede（冲突时停用旧规则）、Split（分离复杂纠正）、New（创建新规则）。输入是候选规则和当前规则库，输出是更新后的规则库。步骤四是编译强制执行。每个原子规则被编译为三个功能组件：适用性检查（确定规则是否对任务活跃）、行为指令（指定智能体必须执行的操作，注入执行上下文）、验证器（定义运行时验证逻辑、监控的证据、必须满足的条件、失败时的返回消息）。钩子作为控制点，在提示、工具使用、文件写入、终止事件时触发验证器。验证器失败时，钩子拦截事件并报告违规详情和证据，迫使智能体修订响应直到合规。任务开始时，轻量级 LLM 通过匹配适用性检查识别活跃规则，相应行为指令加载到智能体上下文，验证器注册到相关钩子。
技术新颖性
技术新颖性体现在三个方面：首先是表示创新的量化证明。论文通过诊断实验直接量化了访问-合规差距，证明了表示改变（从自然语言到编译规则）比扩展记忆容量更有效。No Rules 条件下智能体满足 31.6% 适用偏好，All Rules 提升至 55.0%，但 Compiled Rules 达到 70.1%。这表明问题不在于容量而在于表示。其次是规则来源的创新。现有运行时强制执行工作（ContextCov、policy compilers）假设规则集已由作者编写，从策划的项目指令文件派生可执行检查。Trace 挖掘个体用户的动态纠正流，这需要两个机制：纠正信号检测器（决定哪些对话消息包含值得编译的持久偏好）和五操作生命周期解析器（随着纠正流增长协调每个新候选规则与当前用户库）。最后是端到端评估范式。论文使用模拟用户在环协议（PersonaGym）在两个基准上评估：ClawArena 编码智能体任务和 MemoryArena 记忆密集型任务。模拟器在 30 轮上下文窗口上达到 Precision 0.864、Recall 0.953、F1 0.906、Specificity 0.940，确保行为保真度。这使得在大规模实验中重复测量重复摩擦失败模式成为可能。
实验结果
论文通过三个层次的实验验证了 Trace 的有效性。诊断实验（六模型面板）量化了访问-合规差距：No Rules 条件下智能体满足 31.6% 适用偏好，All Rules 55.0%，Mem0 42.5%，Relevant Rules 54.0%，而 Compiled Rules 达到 70.1%。这证明表示改变比上下文暴露更有效。ClawArena ID 任务上，Trace 将平均违规率降至 37.6%，所有记忆基线保持在 50% 以上且三个超过 94%。任务通过率方面，Trace、No Memory、ReMe-Light 在窄带内聚集，表明编译规则消除重复偏好摩擦而不付出任务完成成本。Mem0 达到 51.1% 违规率，与诊断中 57.5% 的 Mem0 持久违规一致，验证了访问-合规差距。ClawArena OOD 任务上出现论文最强合规结果：Trace 平均违规率降至 2.0%，比下一基线低一个数量级。按模型细分确认迁移而非平均：四个模型中三个达到零观测违规。任务通过率保持与无记忆相同的带内，表明编译规则在分布转移中存活且不付出任务完成成本。MemoryArena 派生任务上，Trace 达到最高任务通过率 17.3% 和最低违规率 60.5%。这里执行和任务通过率通过设计耦合，因为任务成功需要满足所有隐藏用户和项目约束。收获不是 12 点提升本身，而是编译强制执行是产生它的机制。MemoryArena OOD 任务上，任务通过率在四个最强方法内聚集在一分内，所以广泛任务完成不是收益。信号在合规轴：Trace 是唯一低于 99% 违规（97.0%）且低于 90% 平均纠正（86.5%）的方法。绝对违规水平仍高，作者归因于 OOD 任务族暴露了没有编译规则覆盖的约束。测试时效率方面，Trace 在 ClawArena 上将平均用户轮次从 2.00（无记忆）降至 1.37 ID 和 1.02 OOD，Mem0 是唯一有意义缩小差距的基线（1.51 ID, 1.31 OOD）。OOD 差距更显著：一旦规则编译为活跃检查，用户即使在未见场景族上也几乎从不需要重复相同纠正。墙钟时间确认这交互增益不是用昂贵运行时循环购买：Trace 平均每轮 42.5s ID 和 41.8s OOD，在无记忆几秒内且低于所有记忆基线。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| 访问-合规差距诊断 | 合规率 | 70.1% | No Rules 31.6%, Mem0 42.5%, Relevant Rules 54.0% | 比 Mem0 提升 27.6 个百分点 |
| ClawArena ID 任务 | 违规率 | 37.6% | Mem0 51.1%, Hindsight 94.6%, ReMe-Light 99.0%, No Memory 100.0% | 比 Mem0 降低 13.5 个百分点 |
| ClawArena OOD 任务 | 违规率 | 2.0% | Mem0 30.7%, Hindsight 95.4%, ReMe-Light 99.5%, No Memory 100.0% | 比 Mem0 降低 28.7 个百分点，达一个数量级改进 |
| ClawArena ID 任务 | 用户轮次/轮 | 1.37 | Mem0 1.51, Hindsight 1.95, ReMe-Light 1.99, No Memory 2.00 | 比 No Memory 减少 0.63 轮次 |
| ClawArena OOD 任务 | 用户轮次/轮 | 1.02 | Mem0 1.31, Hindsight 1.95, ReMe-Light 2.00, No Memory 2.00 | 接近无纠错水平 |
| MemoryArena ID 任务 | 任务通过率 | 17.3% | Mem0 12.2%, Hindsight 9.5%, ReMe-Light 5.7%, No Memory 5.6% | 比 No Memory 提升 11.7 个百分点 |
| MemoryArena ID 任务 | 违规率 | 60.5% | Mem0 77.6%, Hindsight 87.0%, ReMe-Light 99.5%, No Memory 100.0% | 比 Mem0 降低 17.1 个百分点 |
局限与改进
作者承认的局限性包括：首先，诊断基准仅涵盖 29 个手动标注的偏好检查，从 32 个长上下文编码智能体转录本（每个约一百万令牌交互历史）中提取 142 个纠正冲突记录后手动策划 19 个保留评估任务。样本规模有限，可能无法涵盖所有类型的纠正场景。其次，Trace 的 47 条规则库（37 原子、7 细化、3 复合）在论文部署的快照中，语义层作为回退但不需要任何规则。这表明当前部署可能没有充分利用语义验证能力，限制了处理更复杂、更模糊纠正的能力。第三，MemoryArena OOD 任务上绝对违规水平仍高达 97.0%，作者归因于 OOD 任务族暴露了没有编译规则覆盖的约束。这暴露了 Trace 在完全未见约束类型上的泛化限制。第四，论文使用模拟用户在环协议，虽然验证了高行为保真度（Precision 0.864, Recall 0.953），但模拟器仍不能完全替代真实用户的复杂反馈。最后，论文报告 Trace 平均每轮 42.5s ID 和 41.8s OOD，在无记忆几秒内，但这一测量在四个模型（Haiku 4.5, Sonnet 4.6, GPT-5.4 mini, GPT-5.5）上平均，没有报告每个模型的单独开销，可能掩盖了不同模型间的差异。
独立分析的弱点
独立分析的弱点包括：首先，规则提取和编译严重依赖轻量级 LLM（Gemma 4 31B），论文没有报告这一组件的失败率或鲁棒性分析。如果纠正信号检测器漏检或误检，整个流水线无法捕获重要纠正。改进方向是引入级联验证机制或集成更强大的多模型投票。其次，五个生命周期操作（Noop、Update、Supersede、Split、New）的决策逻辑论文没有详细描述标准，可能存在边界情况处理不佳。例如，当新纠正部分冲突部分细化时，应选择 Update 还是 Supersede？改进方向是提供更细粒度的冲突消解策略和用户反馈循环。第三，三层强制执行（确定、语义、意图）中，语义层作为回退但不需要任何规则，这表明当前部署可能过度依赖确定层验证。对于需要语义理解的纠正（如代码风格、注释质量），Trace 可能无能为力。改进方向是扩展语义验证能力和相应的规则库。第四，论文没有处理规则冲突时的优先级排序。当多个活跃规则相互冲突时，Trace 如何决定哪个规则优先？改进方向是引入规则优先级机制或用户可配置的权重。最后，Trace 作为技能层部署，需要与特定编码智能体运行时（Claude Code 和 Codex CLI）集成，这可能限制了其在其他智能体平台上的可移植性。改进方向是设计更通用的集成接口。
未来方向
作者提出的未来方向包括：首先，扩展规则库以覆盖更多类型的纠正场景。当前 47 条规则主要针对清理要求、工作流约束和风格约定，未来可以包括安全性、性能优化、测试覆盖等领域。其次，研究更复杂的语义和意图层验证。论文部署中语义层作为回退但不需要，未来可以开发专门的语义检查器处理更模糊的纠正（如使代码更可读）。第三，在真实用户部署中验证 Trace 的有效性。论文使用模拟用户，未来需要在实际编码智能体用户中部署并测量长期累积效果。第四，研究规则冲突和优先级的自动化解决。随着规则库增长，冲突管理变得更加重要，需要更智能的协调机制。基于成果可延伸的方向包括：首先，将 Trace 的编译强制执行思想应用到其他智能体类型（如对话智能体、写作智能体、数据分析智能体）。核心洞察记忆使纠正可见，强制执行使纠正必须通用的。其次，研究用户与规则库的直接交互界面。让用户可以查看、编辑、优先级排序他们的规则库，提供更透明的个性化机制。第三，探索跨用户的规则共享和迁移。当多个用户有相似纠正时，是否可以聚合为通用规则？这需要解决隐私和泛化的权衡。第四，结合在线学习动态调整规则强度。不是所有纠正都同等重要，Trace 可以根据用户反馈频率和任务重要性动态调整规则的严格程度。最后，研究 Trace 的长期维护和演化。规则库可能随时间增长到不可管理的大小，需要规则合并、去重、过时规则检测等机制。
复现评估
复现评估：论文声称实验代码可在 https://github.com/YujunZhou/TRACE_exp 获取，可部署技能在 https://github.com/YujunZhou/tellonce。这提供了基本的复现基础。数据方面，诊断基准从 32 个长上下文编码智能体转录本（匿名化真实用户交互）中手动策划，包含 19 个保留评估任务和 29 个手动标注的偏好检查。ClawArena 使用 62 个场景模板，分为 32 个场景（4 个族）用于训练，ID 评估使用这些相同 32 个场景的保留轮，OOD 评估使用 30 个场景（5 个完全未见族）。MemoryArena 使用族级分割，训练和 ID 评估使用三个记忆任务族的不同行，OOD 评估使用未见形式推理族的行。这些数据集需要从原始基准获取或使用论文提供的子集。算力方面，论文使用四个模型（Haiku 4.5, Sonnet 4.6, GPT-5.4 mini, GPT-5.5）进行端到端运行时强制执行评估，诊断使用六模型面板（外加 Gemma 4 31B 和 DeepSeek V4 Flash）。这需要相当大的 API 成本或本地部署资源。论文没有报告总训练或推理令牌数、计算时间或硬件规格，增加了复现难度。复杂度方面，Trace 系统包含多个组件（纠正信号检测器、规则提取器、生命周期解析器、三层验证器、钩子机制），集成到 Claude Code 和 Codex CLI 运行时。这需要深入理解这些智能体框架的插件系统。难度评估为中等偏高：虽然代码开源，但系统复杂度高，数据集获取可能需要额外步骤，算力要求不小。中等研究团队（3-5 人）可能需要 2-3 个月完全复现所有实验。
论文图表
Figure 1 通过三步对比展示了重复纠正失败模式：第一步，用户纠正智能体（你又遗留了调试文件。停止前清理它们。），智能体回应明白了，我会记住。第二步，在后续会话中，记忆被检索（clean debug files 存储为记忆），但智能体仍然遗留调试文件。第三步，Trace 在完成任务前强制执行纠正，调试文件被移除，任务完成且无需再次纠正。图中展示了 REPOSITORY 状态变化：初始有 debug.log、tmp.py、README.md；记忆步骤仍有 debug.log；Trace 强制执行后 debug.log 被移除。底部文字对比：左侧 REMEMBERED, STILL VIOLATED，右侧 CORRECTION FORCES COMPLIANCE。核心信息框指出：问题不是忘记，而是记忆不强制执行合规。
这张图对理解论文至关重要，因为它直观地展示了访问-合规差距的核心问题：记忆使纠正确可见，但不强制执行合规。它为整个 Trace 方法提供了动机，解释了为什么仅依赖记忆是不够的，以及为什么需要将纠正编译为运行时强制执行机制。
Figure 2 左侧展示了五个评估条件：No Rules（智能体只接收任务，无偏好规则）、All Rules（智能体在上下文中接收完整用户规则集）、Mem0（智能体通过 Mem0 记忆后端检索相关用户纠正）、Relevant Rules（智能体只接收适用于当前任务的规则）、Compiled Rules（智能体以操作的可强制执行形式接收适用规则）。右侧条形图显示了六个模型（Claude Haiku、Claude Sonnet、GPT-5.5、Gemma 4 31B、DeepSeek V4 Flash、Qwen 3.6 Plus）在 29 个子规则检查上的平均合规率：No Rules 31.6%、All Rules 55.0%、Mem0 42.5%、Relevant Rules 54.0%、Compiled Rules 70.1%。每个条件条形上的点显示各个模型的表现。
这张图对理解论文至关重要，因为它量化了访问-合规差距并证明了表示改变的有效性。它直接显示 Compiled Rules（70.1%）远超 Mem0（42.5%）和 Relevant Rules（54.0%），证明将纠正编译为运行时约束比简单暴露为上下文更有效。这是 Trace 方法的核心动机和关键证据。