我为什么留下它
这篇文章真正有价值的地方，不是教人把所有流程都变成 Agent，而是要求产品团队先回答：任务路径是否确定、失败是否可观察、结果能否审批和恢复？
Anthropic 把“由代码预先定义路径的 Workflow”和“由模型动态决定过程与工具的 Agent”分开讨论，并建议从最简单、可组合的方案开始。对我而言，这不是保守，而是把复杂度当作需要证明的成本。
它怎样影响我的实践
在生成式媒体生产线上，分镜任务、素材状态、人工审核和镜头级重做更适合显式 Workflow：每一步都需要状态，失败需要定位，最终结果需要人确认。
只有当目标开放、路径无法预先枚举，而且 Agent 能从工具和环境得到真实反馈时，我才愿意放开更多自治。即使这样，费用、迭代次数、工具权限和不可逆动作依然需要硬边界。
阅读时抓住三件事
- Workflow 与 Agent 不是新旧关系。 它们适合不同的问题结构。
- 透明比炫技重要。 使用者应该知道系统计划做什么、执行到哪里、为何停下。
- 框架不是产品判断。 抽象层能加快原型，也可能遮住提示词、工具调用和失败原因。
什么时候适用
- 正在决定 AI 功能应该使用单次调用、固定 Workflow 还是 Agent loop；
- 需要设计工具边界、人工审批、运行观察和失败恢复；
- 产品早期担心为了“Agent”概念过度设计系统；
- 团队需要一套共同语言讨论自治、成本与可控性。
不要怎样误用
- 不要把它当成某个 Agent 框架的选型清单；
- 不要据此推断多 Agent 一定优于简单流程；
- 不要用“模型会自己判断”替代权限、安全、评测和回滚设计；
- 高不可逆成本、缺少审批或恢复能力的任务，不应仅凭这篇文章开放自治。
原文发表于 2024-12-19。Anthropic 目前在页面顶部明确提示，部分工具生态已经变化；因此我保留的是架构判断，而不是当年的工具名单。