那一步根本不必自动化

一项拟议的同步流程有二十个方框。第七步把状态复制进电子表格，第八步为邮件平台重新整理表格，第九步给经理发邮件，请他批准导入。计划书问的是：第七到第九步该由哪个代理执行？

先要问这些方框为什么存在。这只是示例，不是对真实团队的审计。

一场工作流设计讨论把工作分成四类：删掉步骤、使用普通代码、使用代理，或保留人的决定。真正有用的选择发生在挑模型之前。删掉一步，也许就不需要围绕它搭建的整套机制。

从客户能看见的结果开始

说清工作流必须交付什么。对于商店到邮件系统的连接，结果可能是“已经购买的客户不再收到购物车提醒”。这意味着要有状态、时间和抑制发送的规则，却不意味着必须有电子表格、每晚完整导出，或经理的收件箱。

下方 Tajo 示意图把审核集中在拟议映射和启用前的边界。它没有实现购物车提醒抑制。要实现这个结果，操作员必须先定义购买信号和抑制规则。增加一个映射字段不能替代这两项决定。

Tajo概念示意图 · 示例数据

运行前检查同步

将客户更新同步到我的邮件平台。

Tajo MCP 应用草稿

客户同步

商店邮件平台

字段映射

源字段	目标字段	规则
email	EMAIL	直接映射
first_name	FIRSTNAME	直接映射
last_name	LASTNAME	直接映射

模拟数据预览通过

已映射 3 个字段 · 未写入目标系统

启用前需要批准。

预览映射创建草稿

此示意布局参考 Tajo 的映射工具。模拟数据预览和已保存草稿都不会启用同步。

从结果往回沿现有路径检查。每一步都问：它消失后会有什么失败？真正的控制有答案：同意状态会丢失、付款争议会被忽略，或可能未经授权发送消息。习惯性的交接也许只有历史理由：旧系统需要一个文件。

“删除”这一类不是抹去保护措施的许可。先检查每步的目的，再决定归类。

1. 必要结果

   客户得到的结果
   逆向追踪
2. 检查步骤

   目的与控制
   删去多余步骤
3. 保留的工作

   有负责人、可测试

审视的目的是找出交付物和真正保护它的依赖。如果表格承载了一项别处没有的业务判断，就算文件消失，这项判断也必须保留。

步骤类型	要问的问题	示例购物车流程中的情形
删除	它保护或产生必要结果吗？	无人读取的重复导出
普通代码	规则是否精确、稳定？	确认购买后抑制提醒
模型判断	是否需要范围明确的解释？	把自由文本请求分类给相应团队
人或获批政策	是否授予权限或带来重大后果？	批准访问客户数据

这张表是设计工具，不代表任何公司实际步骤的分类结果。

把精确规则写进代码

API 调用、字段校验、时间戳比较或权限检查，不会因为模型临场发挥而变得更好。代码可以表达不变量，重复运行并给出可检查的失败。能明确写出规则时就用代码。

在购物车示例里，购买事件可能迟到或重复。程序应识别订单、比较当前状态，并在已知购买时拒绝发送提醒。若无法确认是否购买，就需要“不确定”状态。模型不能自行授权猜测客户没有购买。

也有工作难以用精确规则表达。客服请求可能写着：“我昨天买的，但收据上还是旧地址。”把消息分给哪个团队，可以交给边界明确的语义判断。输出应该是已知团队或“不确定”，而非可以随意更改订单的开放式指令。模型的判断与执行访问控制和写入状态的代码要分开。

一个代理可能把步骤藏起来

“一个代理读懂工作流，就能把一切都做完。”演示可能显得如此简单。实际运行时，仍要说明它为什么能看记录、可以采取哪些行动，以及错误行动如何撤销。权限过大的代理常把原来的步骤藏进提示词，也抹去原本方便审计的标签。

另一个反对意见是四类审视本身耗时。确实如此，所以要控制范围。选一个客户结果，列出交付它所需的步骤，问每步贡献了什么。只有能缩减工作或厘清责任，审视才值得做。把所有相邻系统都详查一遍，只是再添一个方框。

用一条正常记录和一条失败记录测试分类。如果被删步骤其实承担控制，测试应揭示出来。如果无法通过样例评价模型判断，就收窄它或把决定交还给人。如果每个客户例外都要改代码，就把稳定机制与本地业务规则分开。

审视还需要停止条件。团队可以无休止地拆解任务，直到分类成本超过省下的工作。每个保留步骤有负责人、触发条件和可测试的存在理由时，就该停止。记录一个可能改变设计的不确定点，在最小的真实范围里检验。例如，同步中要问购买事件能否及时到达，以取消已排队的提醒。集成指南给出更广的规划顺序；四类划分防止这个顺序保留不必要的步骤。工作流或权限变化后再复查分类。

成本最低的一步，是结果从来不需要的那一步。