这一章要回答什么

到这里，系统已经有了：

  • 固定场景
  • 固定执行流
  • 后台工作台
  • 重试和审批能力

接下来很快会遇到另一个现实问题：

如果所有 Agent 规则都写死在代码里，这个系统还能不能持续迭代？

答案通常是否定的。

因为一旦你开始真实使用，Prompt 和角色规则一定会高频变化：

  • 标题太平，要改
  • 审稿太松，要改
  • 写作风格太空，要改
  • 研究摘要不够结构化，也要改

如果每次改规则都要改 Python 代码，成本会越来越高。

所以当前项目做的下一步，就是：

把 Agent 规则从代码里抽出来，做成真正可配置、可回滚、可比对的系统。

第一步：把规则从代码里抽成文件

当前项目给每个 Agent 都准备了独立规则文件：

  • src/agents/rules/dispatcher/rules.md
  • src/agents/rules/research/rules.md
  • src/agents/rules/writer/rules.md
  • src/agents/rules/reviewer/rules.md

这样做有几个直接好处。

1. 角色边界变清楚

当规则在单独文件里时，你会更容易问自己：

  • 这个 Agent 的职责到底是什么
  • 它不应该做什么
  • 它的输出格式应该长什么样

这比把所有 Prompt 混在代码里更清楚。

2. 修改规则不再等于修改执行器

一旦规则和执行器解耦，Agent 的“行为定义”和“执行逻辑”就分开了。

这意味着：

  • 想改风格，不一定要改 Python
  • 想调整角色边界，不一定要动流程代码

3. 更接近真实 Agent 产品

很多成熟的 Agent 系统里，Prompt 或规则本来就是一种“运营资产”。
把它们留在代码里，只会让迭代越来越笨重。

第二步：把规则编辑能力放进后台

仅仅抽成文件还不够。
如果只能靠编辑器去改，那对实际使用仍然不够友好。

所以当前项目后面又加了：

  • Agent 列表页
  • Agent 规则编辑页

这意味着：

  • 规则不再只是开发者能碰的东西
  • 后台里就能查看和修改
  • 调整 Prompt 不需要重新进代码上下文

对一个 Agent 产品来说，这一步非常关键。
因为它代表 Agent 已经从“内部实现细节”变成“可管理对象”。

第三步：保存规则历史

只允许修改还不够，因为 Prompt 调优天生就带着试验性质。
你今天改了一版，明天可能发现效果变差了。

所以当前项目又加了规则历史：

  • agent_rule_versions

每次保存规则前，会先把旧版本记录下来。

这样做的价值非常大：

  • 能追踪规则是怎么一步步变化的
  • 能回看效果为什么变了
  • 调坏了可以回滚

换句话说，这一步是在给 Prompt 工程补“版本控制”。

第四步：做 diff，让变化看得见

有历史版本之后，下一个问题就是：

改了什么？

如果你只能看两份大段文本，判断成本还是很高。
所以当前项目又补了 diff。

当前规则页里可以看到：

  • 当前版本 vs 历史版本
  • 行级变化
  • 增删改位置

这一步的价值在于：

  • 改动可视化
  • 回滚更有依据
  • 团队协作时更容易对齐

为什么“规则可配置”会反过来改变系统设计

一旦你认真做这件事，你会发现 Agent 系统开始变得更像一个真正可运营的产品。

1. 你会更认真定义每个 Agent 的职责

因为规则一旦可见，你就没办法再含糊。

你必须说清楚：

  • Dispatcher 负责什么
  • Research 负责什么
  • Writer 负责什么
  • Reviewer 负责什么

2. 你会更容易做角色差异化

当规则是独立文件时，不同 Agent 可以自然形成差异：

  • Dispatcher 更重“方向和标题”
  • Research 更重“信息整理”
  • Writer 更重“结构和表达”
  • Reviewer 更重“质量和风险”

3. 你会更愿意做“规则之外的结构化控制”

当 Prompt 越写越多时，你会发现仅靠自然语言约束还是不够。
这也是为什么当前项目后来不只保留规则文件，还进一步做了：

  • Quality Gate
  • effective_feedback
  • issue_board

也就是说，规则系统会逼着你思考：

哪些约束适合写在文本里，哪些约束应该做成结构化状态。

当前项目里的一个重要经验

做规则系统时，很容易走向两个极端：

极端一：全部写死在代码里

这样做短期快，但长期维护成本高。

极端二：过早做成非常复杂的 DSL

这样做看起来很通用，但第一版通常会很重。

当前项目采取的是一个更务实的中间路线：

  • 先用 rules.md 承载自然语言规则
  • 再用历史版本和 diff 提升可控性
  • 真正需要强约束时，再引入结构化状态

这条路线非常适合入门项目。

这一章的结论

一个真正可配置的 Agent 系统，至少应该做到：

  • 规则从代码里抽出来
  • 规则可以编辑
  • 规则有版本历史
  • 规则可以 diff
  • 规则可以回滚

这样 Agent 才不只是一个 Python 函数，而是一个能被持续运营和迭代的角色。

下一章看什么

到这里，这个项目已经有了产品闭环、可用性能力和规则系统。
最后一个问题是：

从当前 MVP 往下走，最合理的演进方向是什么？

下一章我们就把视角拉高一点，看上下文、质量控制、部署、测试和更多 Agent 应该怎么演进。