工作流交给 agent 前，先圈出不能撤销的步骤

Zach Lloyd 在推文里谈了一个设计取舍：工厂式基础设施里，要给“if this, then that”的确定性多少支持，给自由编排多少空间。

他们最后选了灵活方案。用户用 blueprint 定义工作流形状，看起来像 DAG。真正推进工作的，是 orchestration agent。它决定下一步怎么走，什么时候把人拉进来。这里没有 Zapier 那种确定性模式匹配。agent 看上下文和代码 blueprint 给出的指导，做判断，原文说用了类似 Jev classifier 的东西。指导不完整，或者人要求换路径，agent 能改道。

这个设计有一个容易被忽略的点：blueprint 描述形状，agent 掌握过程。团队要回答哪些节点必须可预测，哪些节点可以临场判断。

回复里三种视角。Zero Clicks 说：在重要处用图，其他地方自由。Asmir 问：偏离 blueprint 会不会反过来更新 blueprint？还是 agent 每次都从零判断。这个问题指向学习闭环。如果偏离只发生一次，系统不会积累经验；如果每次偏离都写回 blueprint，blueprint 会变成组织记忆。Daniel Lenton 的划分更直接：看步骤能不能撤销。能撤销，agent 先做，做完再告诉人。他之前被问太多小问题。这个判断有操作性。可逆性决定权限，比笼统说“人机协作”清楚。

我的判断：多数工作流系统把“灵活”当卖点，真正难的是圈出不可逆操作。付款、删除、对外发送、改生产配置，这些步骤需要确定性边界。草稿、检索、分类、内部流转，可以交给 agent。blueprint 不该是流程图装饰，它要能表达权限和回滚条件。orchestration agent 也不该每次都从零猜。偏离 blueprint 后是否更新 blueprint，决定系统是临时调度器还是能学习的工厂。原文没给答案。如果每次偏离都从头判断，blueprint 只是摆设。这个问题值得继续追。