更好与你协作：将用户纠正编译为编码 Agent 的运行时强制执行

TL;DR TRACE 将交互式 LLM agent 中的用户纠错实时编译为运行时原子规则，在下一次任务完成前强制检查，使偏好违规率从 100% 降至最低 2.0%，解决记忆系统无法可靠遵守用户偏好的问题。

问题

问题背景

LLM 驱动的交互式编码代理（如终端助手、IDE 插件）正嵌入日常开发流程。用户期望代理能从历史纠正中学习偏好，但现实是：上一轮明确纠正过的行为，下一轮往往依然违反。这种“重复摩擦”严重制约了代理的长期可用性。

现有方法局限

当前主流方案依赖记忆系统（如 Mem0）存储用户偏好，并在后续任务中将记忆片段注入 prompt，试图让模型“自行遵守”。然而，这种做法存在根本性的获取–遵守鸿沟：记忆仅提供了信息访问，没有保证行为落地。实测数据显示，即使记忆库包含相关偏好，仍有 57.5% 的适用检查点被违反。原因在于：

• 模型对长上下文中的约束容易遗忘或选择性忽略；
• 人类纠正通常带有语境省略和模糊描述，难以直接映射为可操作的检查；
• 记忆检索的精度和时机与即时行为控制脱节。

为什么这个问题难/重要

技术挑战有三：其一，用户纠正往往是自然语言片段，需自动转化为精确、可执行的原子规则；其二，规则需在代理执行流水线中实时编译与强制介入，而不能仅靠软指导；其三，必须平衡纠正的过拟合与泛化，避免规则僵化。从工程角度看，若每次纠正都需用户在未来手动重申，代理的交互效率将无法收敛，直接拉低生产力工具的采纳度。因此，业界迫切寻求一种能让代理“一次纠正、持续生效”的机制。

行业类比

好比 CI/CD 中的 lint-staged 钩子，TRACE 为编码代理提供了随用户反馈自动生成的“偏好测试”，在任务完成前强制通过——规则不再来自开发者预设，而是源自用户自身的聊天纠正。

核心洞察

• **偏好记忆不等于偏好遵守**：即使为智能体配备显式记忆（如 Mem0），仍有 57.5% 的适用偏好检查被违反，表明仅将用户纠错存入向量数据库并不能保证后续任务遵守。与传统记忆方案不同，TRACE 将用户纠错转化为**编译型运行时检查**，在代理完成动作前强制验证，填补了“访问到偏好”与“实际遵守”之间的系统化鸿沟，为交互式 LLM 代理的持久可靠性提供了新范式。
• **用户纠错可编译为高效、可泛化的原子规则**：TRACE 使用轻量级 LLM 从聊天记录中挖掘用户纠错，将其重写为原子规则，并嵌入到代理的运行环境中进行强制执行。这种**测试时规则获取（Test-time Rule Acquisition）** 不依赖开发人员预先编写检查逻辑，且规则对任务分布变化具有鲁棒性——在 ClawArena 上，OOD 偏好违反率从 100% 降至 2.0%，显著优于纯记忆方案，证明编译式执行能降低跨会话的重复摩擦。

方法

输入来源

TRACE 的输入是 用户与编码代理的聊天会话，其中包含用户对代理行为的修正指令（例如“以后完成后清理日志文件”）。这些修正被收集为原始反馈，无需事先定义模式。

关键模块

1. 规则挖掘与原子化（Rule Acquisition）

使用一个轻量级 LLM（见论文 C.1 实现细节）从会话中检测并抽取用户修正，将其重写为原子规则。每条规则是一个可独立检查的约束，例如：“任务完成后必须删除所有 .log 文件”。这一过程将模糊的自然语言偏好转化为结构化、可验证的指令。

2. 规则生命周期管理（Lifecycle）

规则并非一成不变：系统会跟踪规则的生成、冲突检测、过期失效等。当用户后续发出相反修正时，旧规则会被撤销或更新，避免规则库膨胀与冲突。

3. 编译时强制执行（Compiled Enforcement）

原子规则被编译为运行时检查代码（如 Python 断言或脚本），嵌入到代理的工具执行层中。在代理完成任务并返回最终结果前，这些检查必须全部通过（可配置重试策略，见 C.3）。强制执行分为多个层级（例如文件存在性、内容模式匹配），确保规则被严格贯彻，而非仅仅作为提示提供给模型。

输出效果

代理在后续任务中自动遵循编译后的规则，无需用户重复修正。实验显示，TRACE 将分布内偏好违反率从 100% 降至 37.6%，分布外降至 2.0%，同时任务通过率持平或超过最强记忆基线。

与同类方法的差异

TRACE 的规则源于用户会话修正，而非开发者预定义；与记忆系统（如 Mem0）不同，它不依赖模型在推理时回忆规则，而是通过编译为确定性检查强制执行，从根本上避免“记得住但做不到”的访问-合规鸿沟（Access–Compliance Gap）。

实验

实验设计

实验基于两个编码代理任务基准评估 TRACE 的偏好合规能力：

• ClawArena：真实编码场景的代理任务，用于衡量偏好违规率，区分分布内（in‑distribution）与分布外（out‑of‑distribution）任务。
• MemoryArena‑derived tasks：从 MemoryArena 衍生出的记忆密集型任务，重点评估任务成功（task pass）与偏好违规。

所有实验均采用 模拟用户交互环（simulated user‑in‑the‑loop），用户偏好以聊天修正的形式注入。基线对比包括 Mem0 记忆系统——一种代表性的偏好存取方案，以及无任何偏好记忆的朴素代理。

关键发现

• ClawArena 上偏好违规大幅下降：分布内任务从 100.0% 降至 37.6%，分布外任务从 100.0% 降至 2.0%，表明 TRACE 编译的运行时检查对已见和未见任务类型都有效，尤其对规则泛化能力出色。
• MemoryArena 上任务成功与偏好合规兼顾：违规率从 100.0% 降至 60.5%，同时任务通过率 持平或优于最强记忆基线。可见编译式强制并不会牺牲代理完成任务的能力。
• 减少重复修正：Mem0 虽然存储了偏好，仍有 57.5% 的应用偏好检查被违反；TRACE 通过将修正编译为原子规则并在运行时强制检查，显著降低了用户需要在后续会话中重复申明相同修正的频率。

与基线对比的深度解读

Mem0 提供了偏好“存取”，但 存取 ≠ 合规：代理可能在生成时忽略记忆，而 TRACE 的编译式强制在任务完成前必须通过规则检查，从根本上改变了偏好施加的时机与方式。与传统开发者预先编写的运行时检查不同，TRACE 的规则完全提取自 用户自己的聊天修正，既非预设亦非泛化，因此更贴合个人工作流。分布外仅 2.0% 的违规率暗示规则具有原子性带来的强组合能力，能泛化到未见任务。MemoryArena 上任务通过率不变说明额外检查开销可控，且并未引入新的功能障碍。总体而言，编译用户修正为运行时强制 是一种低侵入性、高可靠性的解决方案，弥补了记忆系统仅“记住”但不“保证”的缺陷，对长期运行的编码代理生态具有实际部署价值。

行业影响

解决的核心问题

交互式 LLM agent 在日常使用中经常重复犯同样的错误，用户上一次的纠正往往无法在后续会话中被可靠遵循。TRACE 提供了一种 编译时规则获取与运行时强制执行 的轻量方案，使得 agent 能像人类员工一样“记住并遵守”用户偏好。

落地场景

任何依赖 LLM agent 与用户频繁交互的产品均可受益：

• 编程助手（Copilot、Cursor、Windsurf）：自动遵守用户特定的代码风格、命名规范、架构约束。
• 智能客服/销售机器人：确保回复始终符合企业政策，避免每次都需要人工监修。
• 内容创作与审核工具：固化创作者或平台的风格指南、敏感词规则，防止反复违规。
• 个人助理 / AI OS：学习用户对日程管理、邮件措辞的偏好，无缝执行。

商业价值

• 降低支持成本与用户摩擦：用户不必反复修正 agent 的同一类错误，减少重复沟通所带来的时间浪费和体验恶化。
• 提升付费转化与留存：更“懂你”的 agent 能显著提高用户满意度和依赖度，直接拉动订阅收入。
• 释放人工审核带宽：在客服、内容平台等场景，运行时规则检查可将人工从机械性纠偏中解放出来，聚焦更高价值工作。

与现有产品/工作流的接口

TRACE 是一种 drop-in skill-layer pipeline，可轻松嵌入现有 agent 运行时：

1. 对话检测层：在用户- agent 对话中插入轻量级 LLM 检测纠正意图，挖掘规则。
2. 规则编译层：将纠正重写为原子规则，并生成可执行的运行时检查（如代码片段、linter-like 检查）。
3. 执行层：于 agent 完成任务前强制运行检查，类似 CI 中的 pre-commit hook，检查失败则触发重试或修改。

• 可直接集成到 LangChain、AutoGen 等框架中，作为 agent 的 enforcement callback 或 post-generation check。
• 已有开源库 tellonce 提供可部署的技能实现。

具体用例

1. 企业级编程助手：某团队使用编程 agent 开发微服务，但 agent 常违反内部错误处理规范（如必须使用自定义异常而非裸 raise）。用户纠正后，TRACE 自动提取规则“所有 raise 必须使用 AppException 子类”，并编译为 AST 检查器。后续生成代码若违反，agent 会被强制修改，大幅减少 code review 中同类重复问题。
2. 电商场景的 AI 客服：商家设置退款政策为“14 天内无条件退货”，但 AI 有时给出错误窗口。通过 TRACE，商家在对话中纠正“退款期限是 14 天，不是 30 天”，系统自动将这一规则加入运行时知识库，之后的客服回复都会经过该规则校验，避免产生客诉和退款纠纷。

综上，TRACE 将 agent 的“记忆”升级为可验证的“契约”，为商用 agent 的可靠性与可维护性提供了一条低成本的渐进式路径。

局限

• **规则提取与编译的质量依赖用户纠正的清晰度和模式覆盖率**：TRACE 从用户对话中挖掘纠正并编译为原子规则，但实际用户的纠正可能含糊、不完整或隐含上下文，导致规则提取遗漏或错误。论文也在实验中使用模拟用户，其纠正行为经过严格定义（附录 A），真实场景中用户的纠正方式更加多变，规则编译的泛化能力尚未验证。如果用户纠正本身不一致，编译出的规则可能相互冲突，而现有的生命周期解析策略（如优先级覆盖）未必能平滑处理所有情况。
• **运行时执行检查可能引入额外延迟与计算开销**：TRACE 在 agent 完成任务前需逐一执行编译后的规则检查，对于规则数量较多或检查本身需要调用 LLM 作判定的场景（如某些语义规则），会显著增加单次任务的端到端延迟。论文在实验中通过轻量级 LLM 做检测和编译以控制成本，但并未给出在大量规则累积下的延迟与吞吐量指标，也未讨论如何平衡严格执行与响应时间，这在生产环境部署中是一个重要限制。
• **与记忆系统的对比实验中，TRACE 仍残留部分偏好违反**：在 MemoryArena 衍生任务上，TRACE 仍留下 60.5% 的 in-distribution 违反率（即使优于基线），表明硬规则并不能覆盖所有偏好类型，尤其是那些需要情境化判断的“软偏好”。此外，TRACE 依赖预定义的 verifier 接口（如文件存在检查、模式匹配），对于需要语义理解的偏好，其效果会随着规则复杂度上升而下降。该问题也限制了 TRACE 在不那么结构化的 agent 任务上的推广。