[Feature] 从人工驳回与门禁返工反馈中沉淀项目规则：自动聚合重复纠正为规则候选，审核后注入后续 Run

未关闭
  • 哪里不对？
#426 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
8/100
Issue 类型
功能
描述清晰度
基本清楚
活跃度
活跃
技术栈
go
领域
ai, backend

调研方向

Start by reading how human feedback is stored today: recordHumanContext in internal/engine/run_ops.go, internal/engine/human_context.go, and the injection point in internal/engine/prompt.go. Then read RuleDefinition and CatalogRepo.PutRule in internal/domain/assets.go and internal/repo/catalog.go. Done means a feedback event creates a pending, deduplicated candidate that, once accepted, is injected into later runs of the same project. This spans several subsystems, so it needs maintainer design input before coding.

由索引模型根据 Issue 内容生成。

描述

背景与借鉴来源

同一个项目里，人对 Agent 的纠正往往是重复的：「改接口要同步更新 openapi」「这个仓库的测试用 make test-unit 不要用 go test ./...」「提交信息要带需求号」……这些话在每次 Run 的驳回/返工里被一遍遍重写，Agent 下一次新 Run 仍然会犯同样的错。业界主流 Agent 已经把「从反馈里沉淀规则」做成了一等能力：

  • cline/cline（https://github.com/cline/cline ，约 7.1 万 star，2026-11-13 仍有推送）：/newrule 命令根据当前对话里用户反复强调的偏好生成 .clinerules 规则文件，以后的任务自动加载。文档原话：「Use /newrule when you find yourself repeating the same instructions across tasks」。
  • continuedev/continue（https://github.com/continuedev/continue ，约 3.6 万 star，2026-11 有推送）：Agent 模式内置 create_rule_block 工具，用户说「Create a rule for this」即由 Agent 根据对话生成 .continue/rules 下的规则。
  • GitHub Copilot agentic memory（https://docs.github.com/en/copilot/concepts/agents/copilot-memory ）：coding agent / code review 在工作中自动记录仓库级「记忆」，每条带出处引用，使用前对照当前代码校验是否仍然成立，长期不用自动过期。
  • OpenHands/OpenHands（https://github.com/OpenHands/OpenHands ，约 9.3 万 star）：仓库级 microagent（.openhands/microagents/repo.md）作为跨任务常驻上下文，可由 Agent 自己补写。

共同点：人的纠正 → 候选规则 → 人确认 → 后续任务自动注入，并且规则带出处、可停用。

LoopForge 现状与不足

LoopForge 已经有规则资产和知识沉淀，但人类反馈没有进入这条链路：

  1. 人工反馈只在单个 Run 内生效。 驳回/返工/补充上下文走 internal/engine/run_ops.go（约 L336、L596 调用 recordHumanContext），由 internal/engine/human_context.go 写进 Run.HumanContext、节点的 NodeRun.Feedback 和 human-context.md 产物；internal/engine/prompt.go（约 L70）只把它拼进同一节点下一次尝试的提示。门禁返工理由 GateResult.Reason/ActionRequired（internal/domain/run.go）也一样。Run 结束后这些反馈就沉在历史里，下一个需求的 Run 完全看不到。
  2. 知识沉淀只认 Agent 自己写的 knowledge.md。 internal/repo/run_knowledge.go 的 KnowledgeArtifacts 只按文件名 KnowledgeArtifactBasename 捞候选；internal/knowledge/service.go 的 Submit/Publish 审核后写回外部知识库 MCP（WriteDocument），而外部知识库是只读检索，不是每次必注入的约束。人类反馈既不会成为候选，也没有「发布为项目规则」的出口。
  3. 规则资产本身已经具备承载能力。 internal/domain/assets.go 的 RuleDefinition 有 ProjectID、Global、WorkflowIDs、Priority，CatalogRepo.PutRule（internal/repo/catalog.go）可写入——缺的只是从反馈生成候选、审核、带出处落库的流程。

结果是：同类纠正在不同需求上重复出现，返工次数（NodeRun.ReworkCount）降不下来，而平台里没有任何地方能看到「这条纠正已经说过 N 次了」。

建议方案

1. 反馈采集为「规则候选」

  • 新增实体 LearnedRuleCandidate（归属新的 LearningsRepo，或并入 CatalogRepo，遵守 AGENTS.md 的 repo 分层），字段：projectId、workflowId、nodeId/agentId、kind（human_rework / human_context / gate_rework）、sourceRunId、sourceNodeId、attempt、原始反馈文本、提炼后的规则草稿、occurrences、status（pending / accepted / rejected / merged）。
  • 采集点：recordHumanContext 调用处、门禁 rework 决策落库处；只采集人工输入和门禁的 rework 理由，不采集模型自由输出。
  • 去重聚合：同项目内对规范化后的反馈文本做相似度判断（先用简单的归一化 + n-gram/Jaccard，后续可接嵌入），相似的合并到同一候选并 occurrences++，保留全部出处 Run 链接。

2. 候选提炼

  • Run 终结后（或每日定时）用项目当前的执行器跑一个轻量「规则提炼」任务：输入为该候选的反馈原文和对应节点产出摘要，输出「一句话可执行规则 + 适用范围（全项目 / 某 SOP / 某角色）」。一次性的、只针对本需求的内容判定为「不可沉淀」直接标记 rejected 并写明理由。
  • 也提供 Agent 侧入口：在 Agent MCP 里加 propose_rule 工具（类似 Continue 的 create_rule_block），Agent 在被纠正时可主动提出候选，同样进入审核队列，Agent 不能直接写规则。

3. 审核与发布

  • 在现有「知识库审核」页旁增加「规则建议」队列：按 occurrences 降序，展示出处 Run/节点和原始反馈；操作：接受（可编辑文本、选择作用域）、合并到已有规则、拒绝。
  • 接受后生成或更新 RuleDefinition：ProjectID 为当前项目；作用域为某 SOP 时 Global=true + WorkflowIDs；为某角色时追加到该 Agent 的 Rules。规则内容尾部自动附「来源：Run xxx 节点 yyy，YYYY-MM-DD」。
  • 规则带 origin=learned 标记和 lastHitAt；超过 N 天（可配，默认 90）没有任何 Run 注入且无人引用时在审核页提示「建议停用」，不自动删除。

4. 效果可见

  • 在 Run 详情中标出本次注入了哪些 learned 规则；在项目分析里统计「接受规则后同类反馈的再出现次数」，用于判断规则是否有效。

验收标准

  • 在 SOP Run 中对某节点执行「驳回并补充说明」后，项目的「规则建议」队列出现一条候选，包含原始反馈、出处 Run/节点/尝试号的可点击链接。
  • 同一项目两次不同 Run 给出语义相同的纠正（如「改接口要更新 openapi」措辞略有不同），只生成一条候选且 occurrences=2、出处列出两个 Run。
  • 门禁 Agent 以 rework 结论退回时，其 Reason/ActionRequired 同样进入候选；pass / fail 不产生候选。
  • 审核人接受候选并选择作用域为「某 SOP」后，rules 表新增一条 ProjectID=该项目、Global=true、WorkflowIDs 含该 SOP 的规则；该项目此后新建的该 SOP Run 的节点提示中包含这条规则，其他项目不受影响。
  • 拒绝的候选不会生成规则，且同样文本再次出现时合并到已拒绝候选（计数增加、不重复弹出），审核人可重新打开。
  • Agent 调用 propose_rule 只能产生 pending 候选，无法直接写入或修改 RuleDefinition。
  • 采集与提炼不保存任何凭据：反馈文本入库前经过现有的脱敏逻辑；提炼任务失败不影响原 Run 状态。
  • repo / handler 分层符合 AGENTS.md（新实体有归属 Repo、新领域有自己的 handler struct），新增表通过 migrations/ 下的 SQL 脚本提供；单元测试覆盖采集、去重合并、接受后规则注入三条路径。
主要语言
Go
星标
141
派生
28
平均合并
1 天 15 小时
30 天内合并 PR
113

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

Tencent/LoopForge 的其他 Issue

查看 Tencent/LoopForge 的全部 Issue

相似的 Issue

更多 Go Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。