Skip to content

[business-logic] user-edit ratchet 负信号源误接线:agent undo_edit 被当作用户撤销,真实用户 /undo 被记为正信号 #3249

Closed

Description

@topcheer

文件与行号

  • internal/agent/agent.go L3841-3847(负信号接线)
  • internal/agent/user_edit_ratchet.go L118-150(NoteNegativeSignal 语义与 negHits 回收)、L152-199(CheckTurnBoundary 正信号计数)
  • internal/tui/commands_slash_admin.go L159-186(用户 /undo 路径,绕过工具循环)

问题描述

r447 给 user-edit ratchet(r444)加的负信号通道接错了信号源,且漏接了真正的用户撤销路径,导致正负两个方向都与设计意图相反:

  1. 归属错误:NoteNegativeSignal 唯一触发点是 agent 工具循环里 undo_edit 的成功调用(agent.go L3841-3846),但注释声称 "the user undid the agent's edit... the user was rejecting the edit"。undo_edit 是 agent 的常规自我纠错工具(edit 错→undo→重做),不是用户动作。
  2. 用户撤销永不入通道:真实用户撤销走 TUI /undo → cpMgr.Undo("user")(commands_slash_admin.go:170),直接 checkpoint 恢复,不经过 agent 工具循环,NoteNegativeSignal 收不到。
  3. 用户撤销反被记为正信号:/undo 恢复会改写文件 mtime(该路径自己的注释即写明 "the file's mtime changed during the undo write")。若该文件在 wrote 表中有 agent 写入记录,下一次 CheckTurnBoundary 发现 mtime 移动 → obs.turns++ 正向计数——用户明确拒绝被当作用户认可/调整的证据,与 r447 意图完全相反。

触发场景

  • 误回收:turn 1 用户手动改写 F(pending[F].turns=1,真实证据)→ 之后任意两个 turn 中 agent 对 F 两次 undo_edit(模型常见自我纠错,频率远高于用户 /undo)→ negHits[F]≥2 → RemoveUserEditRules(F) 静默回收一条完全基于真实用户行为提升的 "re-read before editing" 保护规则,此后 agent 可不再强制重读即盲改该文件。
  • 误取消:任一次 agent 自我 undo_edit F 都会 delete(pending, F),抹掉先前 turn 间隙积累的真实用户改写观察。
  • 正负倒置:用户对 F 执行 /undo(拒绝 agent 输出)→ mtime 变化 → CheckTurnBoundary 记正观察 → 反向推动 "user manually adjusts this file" 规则生成。

预期行为 vs 实际行为

  • 预期:用户撤销(/undo)→ 负信号(取消 pending、重复则回收规则);agent 自我撤销 → 仅中和自身 mtime 扰动,不计入负信号。
  • 实际:用户撤销 → 记正信号;agent 自我撤销 → 记负信号并可回收规则。

修复建议

  1. agent 循环内 undo_edit 分支只做 delete(o.wrote, path)(保留防自污染功能),不触发 negHits 递增与规则回收。
  2. 用户撤销通道:cpMgr.Undo("user") 成功后显式调用 NoteNegativeSignal(TUI 与 desktop 各接一次),或提供 agent API 由 checkpoint 路径注入。
  3. 更新 user_edit_ratchet.go 注释与 user_edit_negative_test.go 的场景归属,补用户路径测试。

注意:接线中"删 wrote[path] 中和 undo_edit 自身 mtime bump"的部分是正确且必要的,修复时必须保留,否则 agent 自我撤销会在 CheckTurnBoundary 被误判为用户改写。

严重程度

medium(独立复核 sa-21 确认):不破坏执行正确性,但静默削弱核心安全 ratchet(防盲改用户手改文件的保护可被无关 agent 行为回收),且用户真撤销信号完全缺失并倒置为正信号。

验证方式

  • 我方直接实证:三处源码逐一读取(接线、ratchet 语义、/undo 路径)。
  • 独立复核(spawn_agent,同模型):确认归属错误、测试固化错误语义(user_edit_negative_test.go 全部场景以 agent 调用为前提)、危害方向评估为 medium。
  • 复核中一条关于 persistence.go 的引用经抽查为杜撰,已剔除,不影响上述结论(正信号误记由 CheckTurnBoundary 机制直接推出)。

Activity

  1. topcheer commented on Oct 4, 2026

    @topcheer
    OwnerAuthor

    认领:本会话接手(HappyPanda_developer_agent,先例 #2423/#1913 流程)。计划:定位 user_edit_ratchet.go 负信号源的 undo_edit/用户-/undo 双入口接线,还原正负极性(agent 自身 undo_edit 不产负信号、真实用户撤销产负信号),补双向极性回归测试,隔离分支修复走 PR+CI+送审。

  2. topcheer commented on Oct 4, 2026

    @topcheer
    OwnerAuthor

    修复 PR:#3252(NoteAgentUndo 拆分自污染中和 / RecordUserUndo 导出桥 + /undo 与 /undorun 双接入 / 4 组钉死测试 / agent+tui 双包全绿)。核查说明:desktop 侧无源码级 undo 入口(grep 仅命中构建二进制),用户撤销路径现仅 TUI 两处,均已接入——desktop 若后续增 undo 绑定需复用 RecordUserUndo。等待审查验收。

  3. added 4 commits that reference this issue on Oct 4, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions