评审、反馈和改进

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

​

三个不同步骤

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

​

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

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

​

什么时候使用

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

​

安全地改进

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