Agent的教训该变成永久规则吗？

给AI编程助手写规则，很容易从"记住这个教训"变成"堆了200条没人看的指令"。IssueFlow作者分享了一套让agent自己提出学习提案、由人类审批并定期清理的工作流。

一个具体的失败案例

如果你在跑agentic编程工作流，大概率遇到过这种情况：AI编程agent因为一个极其无聊的原因卡住了。作者最近的一次运行中，agent因为没有Jam凭证而失败。Jam是用来报告bug并给triage agent提供链接的工具，但那次运行的问题根本没有Jam链接可查。

任何人一眼就能看出这不需要凭证，但agent不会——除非你提前告诉它：先判断这个访问是否相关，再担心有没有权限。

结果agent停下来，升起一个human-gate，等人给方向。作者回应之后，自然希望下一个agent能记住这个判断。但把每一次纠正都变成永久指令，会带来新问题：规则越堆越多，没人检查它们是否还该留着。

一条好规则长什么样

"更小心一点"不是教训，它没给下一个agent任何可用的检验标准。

"当issue没有Jam链接时，不要因为缺少Jam凭证而阻塞"就具体得多——它指明了条件，也指明了要避免的动作。

关键在于：这个提案是否捕捉到了超越单个任务的东西？一次性的绕过方案，不应该悄悄变成所有未来运行的规则。

提案是证据，不是指令

作者要的平衡点，在"太具体"和"太宽泛"之间。他不想每次prompt都塞给agent 200条规则——那些规则会淹没在指令的海洋里，token成本也是问题。

在IssueFlow中，agent可以提交学习提案（learning proposals）。一个librarian agent负责收集、合并、泛化这些提案，整理成可读的候选规则（candidate rules），并附上实际要发给agent的指令。

人类操作者（作者原话："人类，哈哈"）审查两部分：规则是什么意思，以及agent会被要求做什么。可以批准、编辑或拒绝。

这一步作者不想跳过。agent从失败中吸取错误教训，和它在写代码时得出错误结论一样容易。"这次失败了"不等于"永远不要这样做"。

一条有用的规则应该说明：它针对什么错误、在什么条件下适用、要求什么行为。它应该留下足够的证据来检查推理过程。

librarian agent 是 IssueFlow 工作流中的一个专职角色，其职责类似软件团队中的技术文档维护者或知识库管理员。它本身不产生学习提案，也不做最终审批决策，而是承担"中间处理层"的工作：接收来自各个阶段 agent 的原始学习提案，识别语义相近或重复的内容并进行合并，将过于具体的绕过方案泛化为可复用的条件规则，最终整理成人类可读的候选规则及配套的 agent 指令。之所以要单独设立这一角色，是因为将原始提案直接推送给人类审批会造成信息过载——大量提案是同一问题的不同表述，或仅在措辞上有细微差异。librarian 的介入相当于一次预处理和去重，大幅降低人类审批的认知负担，同时保证提案在泛化过程中不丢失关键的适用条件信息。

规则该归属到哪个阶段

学习系统设计的下一步是：哪些agent应该拿到这些规则？

来自'design-review'阶段的教训，不一定属于'cleanup'阶段。关于实现的规则，没必要占据每个不相关阶段的空间。

提案来自特定阶段的特定agent，librarian在泛化和合并时，也是按agent分别处理的。IssueFlow的审查流程让作者可以选择特定阶段，或者让规则成为通用规则。阶段标签让作用域可见，也可以调整。

这个小决定有实际目的：让指令靠近它真正起作用的工作。更多prompt文本不等于更多指导。

审批不是终点

批准之后，流程没有结束。作者想衡量每条规则的有效性。

Agent在使用规则时会报告。librarian可以利用这些历史记录，找出长时间未被报告使用的规则，然后建议退休（retire）。作者也可以手动退休规则。

拒绝也有作用。当作者带着理由拒绝一个提案时，理由会被记录，librarian之后处理类似提案时会用到。否则，可能一整周都在拒绝同一个想法的不同变体。

需要注意的是：使用报告是调查的信号，不是agent遵循了每条指令的证明，也不能证明没有这条规则就一定会犯某个错误。

规则退休（retirement） 在这套机制中并非简单的"删除"操作，而是一个基于使用数据的决策流程。其核心逻辑是：一条规则如果长时间未被任何 agent 在实际运行中报告使用，说明它可能已不再匹配当前的工作模式、代码库状态或工具链版本，继续保留只会增加 prompt 长度和 token 成本。librarian 根据使用历史主动提出退休建议，人类操作者也可以基于自身判断手动退休。但作者特别指出，使用报告只是"调查的信号"——agent 没有报告使用某条规则，不等于该规则无用，可能只是报告机制本身的遗漏，或者该规则预防的错误在当前任务分布中恰好未出现。因此退休决策应结合规则的原始提案背景、当前工作流变化以及人类对风险的主观评估，而非单纯依赖使用频率这一单一指标。

学习也需要人类判断

作者在实现这套自学习系统后最大的体会是：它提供了一种维护指令的方式。它不是agent不再犯错的承诺，但确实帮助消除了许多来自真实经验的重复问题。

目标是：让有用的纠正能惠及后续工作，保持作用域清晰，并且给人一个移除不再有用的建议的途径。重要的学习进入prompt，然后作为规则被退休。

这留下一个作者仍在思考的问题：从一个任务到下一个任务，应该有多少指令存活下来？

如果你在用编程agent，你现在怎么处理这个问题？是一直加指令，还是会审查和移除？

作者还提供了一个IssueFlow工作流demo，展示了真实运行中的一次设计审批和一个意外决策。