这一章要回答什么

当系统开始支持人工审批之后，一个很现实的问题就会出现：

如果用户不止 reject 一次，而是连续多轮修改，这些反馈到底该怎么管理？

很多项目会把这个问题想得太简单，觉得只要把用户每次输入的 feedback 存下来，再下一轮原样回灌就行。
但当前项目的发展过程说明，这么做很快就会失控。

因为多轮反馈带来的不是“更多文本”，而是：

  • 问题会累积
  • 问题会收敛
  • 问题会重复出现
  • 问题之间会冲突

所以这章要讲的核心是：

当系统进入多轮修订时，你处理的已经不只是 feedback，而是一套“问题状态”。

为什么多轮 feedback 不能只靠文本累加

我们先看最直观、也最常见的做法：

  • 第一次 reject：保存一段 feedback
  • 第二次 reject：再保存一段 feedback
  • 重新生成时，把历史反馈全拼在一起

这种方式第一轮通常没问题，但很快会出三个大麻烦。

1. 上下文会越来越长

每多一轮 reject，就会多一段历史。
如果一直累加，Prompt 很快就会变得又长又乱。

2. 历史里会有重复问题

比如：

  • 第一次说“标题太平”
  • 第二次说“标题还是不够有判断”

本质上都在说同一个问题，但如果系统不知道归并，就会反复堆叠。

3. 新旧要求会互相冲突

例如：

  • 第一次说“标题更克制”
  • 第二次说“标题更有观点”

这时如果系统只是把两句话都传给模型，模型大概率会：

  • 自己瞎选一个
  • 做一个很平庸的折中
  • 或者看起来都改了，实际上谁也没满足

这也是为什么当前项目后来不再只依赖 feedback，而是开始引入更结构化的处理方式。

当前项目为什么引入 issue_board

当前项目后来新增了：

  • issue_board

它的意义在于：

把反馈从“用户说过的话”，变成“系统正在追踪的问题”。

这个变化非常关键。

过去：只有一段段反馈文本

系统知道用户说过什么，但不知道：

  • 哪些问题还没解决
  • 哪些已经解决
  • 哪些是同类问题
  • 哪些是冲突问题

现在：变成问题板

有了 issue_board 之后，系统开始能管理：

  • open issue
  • resolved issue
  • issue 类别
  • issue 证据
  • 最近出现在哪一轮

这说明系统已经从“聊天记录模式”进入“问题管理模式”。

effective_feedback 为什么很重要

issue_board 是状态层，effective_feedback 则更像它的压缩表达。

当前项目里：

  • issue_board 负责存结构化问题
  • effective_feedback 负责把当前还生效的要求整理成一份可直接注入 Agent 的文本

这两个层次一起工作，效果会比只保存原始 feedback 稳得多。

它解决了什么问题

它最大的作用是告诉系统：

下一轮真正该听什么。

不是历史上谁说过什么，而是：

  • 当前真正还没解决的问题是什么
  • 哪些要求还在生效
  • 哪些已经被覆盖或关闭

这能显著提升多轮修订时的收敛能力。

冲突是怎么出现的

只要开始多轮反馈，冲突几乎是必然的。

在当前项目里，比较典型的冲突包括：

  • 标题风格冲突
  • 开头写法冲突
  • 案例密度冲突
  • 结尾风格冲突

比如：

  • “标题更克制”
  • “标题更有观点”

或者：

  • “开头直接下结论”
  • “开头先用现象切入”

这些都不是模型应该自己瞎猜的事情。
因为它们本质上属于：

用户偏好或当前意图的裁决问题。

当前项目怎么检测冲突

当前项目没有一上来上复杂语义系统，而是用了一个很务实的方式：

  • 先把反馈拆成 item
  • 给 item 做简单分类
  • 同类别但方向相反时，认为发生冲突

比如在实现里，已经有一批基础分类：

  • title_tone
  • opening_style
  • example_density
  • conclusion_style
  • tone_style
  • structure_depth

这套方法不是最智能的，但非常适合 MVP，因为它先把“冲突治理”这件事跑起来了。

为什么冲突不应该由系统强行自动裁决

很多冲突看起来像语言问题，实际上是偏好问题。
比如：

  • 更克制，还是更有观点
  • 更分析，还是更有情绪
  • 更短，还是更完整

这类问题没有绝对标准答案。
所以当前项目后来的方向是：

系统负责发现冲突，用户负责确认最终结论。

这比让模型自己“猜一个最合理的解释”要稳得多。

当前项目的 conflict_resolution 是怎么工作的

当系统检测到冲突后，不会继续跑下去，而是会：

  1. 暂停任务
  2. 把任务状态切到 conflict_resolution
  3. 展示冲突项
  4. 让用户填写“最终生效结论”

这一步就是当前项目里的：

  • pending_conflict
  • conflict_resolution

用户确认后，系统会把这次裁决结果写回：

  • issue_board
  • effective_feedback

然后再继续后续流程。

这意味着：

冲突确认不是一个提示框，而是会真正改变后续上下文的状态。

这点特别重要。

“用户确认后写回有效上下文”为什么是关键

如果系统只是记录“用户曾经确认过什么”，但后面 Agent 看到的还是旧要求，那这套设计其实没有完成。

当前项目真正做对的地方在于：

  • 用户确认的最终结论，会写回当前生效上下文

也就是说，后续 Writer 或其他 Agent 再运行时，看到的不是：

  • 冲突双方原文

而是：

  • 已经裁决后的结论

这能极大减少系统继续在冲突里打架。

这条能力对多轮修订意味着什么

一旦有了：

  • issue_board
  • effective_feedback
  • pending_conflict
  • conflict_resolution

系统在面对多轮修订时的处理能力就会发生质变。

从“重复记笔记”变成“管理问题状态”

它不再只是把用户的话存下来，而是开始真正理解：

  • 哪些问题存在
  • 哪些问题已解决
  • 哪些问题需要用户裁决

从“堆积历史”变成“维护当前标准”

后续 Agent 真正依赖的，不再是全部历史，而是当前有效标准。

这会让系统变得更稳，也更容易调试。

当前项目下一步还可以怎么继续做

虽然现在这条链路已经跑通了，但后面仍然有很多值得继续加强的方向。

比如：

  • 更稳定的反馈分类
  • 连续多轮未解决问题的优先级提升
  • 已解决问题回退检测
  • 更清晰的 issue 生命周期展示

这些都能让系统更像“修订工作台”，而不仅仅是“多轮调用模型”。

这一章的结论

多轮 reject 出现以后，系统要处理的就不只是 feedback，而是一套持续演进的问题状态。

当前项目在这条线上已经做出的关键设计包括：

  • issue_board
  • effective_feedback
  • 冲突检测
  • pending_conflict
  • conflict_resolution

这套设计的本质是：

把多轮反馈从“历史文本”升级成“当前有效标准”。

下一章看什么

当系统已经能处理多轮反馈之后，下一个问题就是：

除了人工 reject 之外，系统能不能自己先判断内容质量？

下一章我们就讲当前项目里的质量闸门：

  • Dispatcher 一致性检查
  • Reviewer 的 pass / revise / rewrite
  • 自动回炉 Writer

也就是生成和校验如何在 Agent 系统里分工。