Rudder 希望 Agent 能通过真实工作持续进步,但这不代表每条评论都会悄悄改写 Agent。

三个不同步骤

审批是另一件事。它允许某项操作发生,例如花费资金或进行敏感修改,但不会 判断结果质量。

例子:改进未来的发布说明

文案 Agent 提交发布说明。评审人接受安装步骤,但要求把限制说明写得更清楚。 修改通过后,团队发现同一项检查已经帮助过多次发布。 团队不再一直复制这条评论,而是提出一项发布文案技能更新,测试后再让未来工作 使用经过评审的版本。这样,反馈可以改善团队,又不会把一次意见变成不受控制的 永久规则。

什么时候使用

  • 任务完成需要独立判断时,添加评审人。
  • 下一位负责人或未来运行需要理解决定原因时,留下具体反馈。
  • 只有经验已经重复出现、适用范围清楚而且可以验证时,才修改长期指令。

安全地改进

Issue 已经指定评审人时,负责人不能跳过评审,直接把任务当成已经接受。普通评论 中的“看起来不错”是有用反馈,但不等于正式记录评审结论。 反馈本身不会修改 Agent、技能或工作流。长期变更应说明依据来自哪些工作、适用 在哪里、由谁检查,以及怎样测试或撤销。 实际步骤见评审 Agent 工作