AI Agent 工作流不是把一句“帮我自动完成”丢给工具，而是把目标拆成输入、步骤、工具、检查点、退出条件和人工确认。设计的目的不是追求自主性，而是让每一步可见、可中断并能退回。
先确认目标
本文解决什么问题？
这篇文章解决“AI Agent 工作流怎么设计”的问题。重点是先区分固定 workflow 与动态 agent，再给新手一个能落地、能复核的结构，而不是默认采用复杂自动化或多 Agent。
先区分 workflow 和 agent
Anthropic 的工程文章把两者区分为：
- workflow：LLM 和工具沿预先定义的代码路径执行。
- agent：LLM 根据环境反馈动态决定过程和工具使用方式。
输入稳定、步骤明确、结果可验证的固定任务，优先用简单 workflow；只有当步骤难以预先写死、确实需要模型动态判断时，才评估 agent。Anthropic 也建议从满足需求的简单方案开始，因为更高复杂度会带来成本、延迟和错误累积风险。
不要把生产账号、客户数据、资金操作直接交给没有人工确认的 Agent。第一版要默认“可撤销、可检查、可中断”，高风险动作每次都停下来等待人批准。
一个可用工作流包含什么
| 模块 | 要写清楚什么 | 例子 |
|---|---|---|
| 目标 | 最终要得到什么 | 生成一篇文章大纲 |
| 输入 | Agent 可以使用哪些资料 | 关键词、参考文章、产品说明 |
| 步骤 | 先做什么、后做什么 | 先列结构，再写初稿，再自检 |
| 工具 | 可以调用哪些工具 | 浏览器、文件系统、代码测试命令 |
| 验证 | 怎么判断完成 | 是否覆盖关键词、是否有内链 |
| 边界 | 不能做什么 | 不发布、不改生产数据 |
| 退出 | 什么情况结束或暂停 | 目标完成、重试超限、证据不足 |
| 退回 | 失败后回到哪一步 | 来源不足时退回资料收集 |
一手资料如何约束设计
- Anthropic：Building effective agents说明 workflow 与 agent 的区别、简单方案优先，以及常见组合模式的适用条件。
- OpenAI：A practical guide to building agents建议按只读或写入、可逆性、账号权限和财务影响给工具分级，并让高风险动作触发人工监督；重试超限也应交还给人。
- NIST AI RMF Core强调先建立治理和使用情境，再持续识别、测量和管理风险，并记录人类监督、系统限制和退出判断。
这些资料提供设计原则，不证明某个固定步数、更复杂编排或多 Agent 一定更好。
常见模式与适用边界
| 模式 | 适合条件 | 不适合或必须补的边界 |
|---|---|---|
| Prompt chaining | 任务能清楚拆成前后依赖的固定子任务 | 每一步都要有门槛；不能让错误输出无检查地传下去 |
| Routing | 输入类别明确，分类结果能被验证 | 类别含糊或误路由代价高时，要有默认人工入口 |
| Parallelization | 子任务相互独立，或确实需要多视角复核 | 有强依赖的步骤不能硬拆并行；合并规则要预先写清 |
| Evaluator-optimizer | 有明确评价标准，反馈能指导下一轮修改 | 没有退出条件会循环消耗；评价器本身也需要抽样复核 |
先选满足任务的最简单模式。若一个普通函数、规则表或单次模型调用已经能完成目标，就不必增加 agent。
可以直接照做
5 分钟工作流草稿
用下面格式先写一版，不要超过 6 行：
- 任务：这条工作流只解决什么问题？
- 输入：每次固定提供什么材料？
- 步骤：先做什么、再做什么、最后做什么？
- 检查：每一步产出怎么判断合格？
- 暂停点：哪些动作必须等人工确认？
- 失败处理：结果不合格时退回哪一步？
这份草稿能跑通，再考虑接工具、定时任务或多 Agent。
样本任务与可复现输入：把会议记录变成待办草稿
这是一条低风险流程样本，不代表生产效果。先固定一份由本站构造的脱敏输入：
会议记录：
1. 已决定：内容编辑在 7 月 28 日前补齐 API 文章的错误码说明。
2. 已决定：发布前必须由技术复核人检查示例请求。
3. 讨论：下周也许增加点击埋点，但负责人和日期尚未确定。
4. 未决定：是否把旧模型文章跳转到新教程，需要再看访问数据。
执行约束固定为：
只提取明确决定事项。
每条待办必须保留原句编号；负责人或日期缺失时写“待确认”。
只输出草稿，不发送消息、不创建真实工单。
讨论项和未决定项进入“待确认”，不能改写成已批准任务。
先用这份脱敏记录人工对照。若输出遗漏、把讨论当决定，或连续两次仍无法满足检查条件，就停止自动重试并交还给人。
结果样例与验收记录
合格输出可以是：
| 类型 | 待办或问题 | 负责人 | 日期 | 原句 |
|---|---|---|---|---|
| 已决定 | 补齐 API 文章的错误码说明 | 内容编辑 | 7 月 28 日 | 1 |
| 已决定 | 发布前检查示例请求 | 技术复核人 | 待确认 | 2 |
| 待确认 | 是否增加点击埋点；如增加需补负责人和日期 | 待确认 | 待确认 | 3 |
| 待确认 | 是否将旧模型文章跳转到新教程 | 待确认 | 待确认 | 4 |
这张表是人工依据固定输入制作的预期结果，用于检查 Agent 输出，不是生产运行记录。一次真实运行还要保存：原始输入版本、模型与提示版本、每步输出、人工修改、重试次数和最终是否只停留在草稿。
失败边界与人工接管
- Agent 把“讨论、也许、未决定”改写成已批准任务。
- 待办无法指回原句，或擅自补负责人、日期和优先级。
- 输入含客户隐私、账号密钥或不应进入模型的会议内容。
- 输出准备触发发送、建单、删除、付款或生产配置，而流程没有逐次人工批准。
- 同一检查错误连续两次仍未修正，或工具返回结果无法验证。
发生任一项就停止自动推进，保留输入与日志并交给人处理；不能靠无限重试把不确定性变成看似确定的结果。
设计步骤
把目标缩小到一次交付
不要写“帮我运营网站”，而是写“根据 1 个关键词生成一篇文章大纲，并列出需要补充的资料”。
列出输入和禁止事项
告诉 Agent 可以读哪些文件、不能访问哪些账号、不能执行哪些操作。边界越明确，越少跑偏。
拆成可见检查点
每个检查点都要有可见输出，例如关键词表、文章结构、初稿、自检清单。
设置退出和退回条件
写清完成、证据不足、重试超限和工具失败时分别结束、暂停或退回哪一步。
按工具风险设置人工确认
只读工具与可逆草稿可以先在隔离环境测试；发布、付款、删除、群发和生产配置必须在执行前让人确认。
运行前检查清单
| 检查项 | 要写清楚 |
|---|---|
| 使用情境 | 谁使用、影响谁、在哪个环境运行 |
| 成功条件 | 哪个可见输出代表完成，谁负责验收 |
| 退出条件 | 完成、重试超限、证据不足和异常分别怎么停 |
| 失败退回 | 每个失败点回到哪一步，是否保留原始输入 |
| 日志 | 记录哪些决策和工具结果，如何避免保存敏感信息 |
| 人工职责 | 谁能批准高风险动作，谁负责事故处理 |
工具风险可以先按最小三档管理：
| 风险级别 | 例子 | 默认处理 |
|---|---|---|
| 低 | 读取脱敏文件、生成不外发草稿 | 允许在隔离环境运行，保留日志 |
| 中 | 写入草稿文件、创建可撤回的测试记录 | 执行前展示预览，提供撤销与范围限制 |
| 高 | 付款、发布、删除、群发、生产配置、客户账号操作 | 每次都暂停，由有权限的人明确批准 |
常见工作流模板
内容生产工作流
关键词输入 → 搜索意图判断 → 大纲 → 初稿 → 内链建议 → 人工审校。
适合文章站、公众号、小红书笔记和产品文档。关键是不要跳过人工审校。
代码修复工作流
问题描述 → 复现步骤 → 写测试 → 修改代码 → 跑测试 → 总结改动。
适合小范围 bug 修复。必须有测试命令，否则 Agent 很容易只给出看似合理的改动。
客服知识库工作流
问题收集 → 分类 → 标准答案 → 风险标记 → 人工复核 → 上线。
适合重复问题多的业务。涉及退款、合同、医疗、法律等内容时，要保留人工审批。
如果你不知道怎么写 Agent 工作流，就先写“输入是什么、输出是什么、失败了怎么发现”。这三件事比工具名字更重要。
FAQ
Agent 工作流一定要用自动化平台吗？
不一定。早期可以先用 Codex、Claude Code、Dify、Coze 或普通对话工具模拟流程。真正稳定后，再决定是否平台化。
一个工作流能不能越复杂越好？
不能这样判断。先用能满足目标的简单方案；只有当评估结果证明现有方案不足时，再增加步骤、工具或动态决策。
怎么判断工作流设计成功？
先定义可复现的验收样本、允许错误和人工接管条件，再测试是否满足。没有这些记录，不能只凭一次看似正确的输出判断成功。
阅读结论
总结
AI Agent 工作流设计的核心，是先判断固定 workflow 是否足够，再把目标、工具、检查、退出、退回和人工职责写清楚。低风险样本先在隔离环境验证，高风险动作始终保留明确的人类批准。