如何设计一个可维护的自动化 Agent 工作流
把任务分流、状态、工具权限、执行记录和失败升级设计成一套可续接的执行系统。
本文目录 5 节 · 点击展开
自动化 Agent 最容易失控的原因，不是模型不够聪明，而是任务、状态、工具权限和失败处理混在了一起。这篇文章把它们拆成一套执行控制系统：先分流，再记账；先授权，再执行；每一步都可验证、可追踪、可续接。
- 01 任务分流
- 02 状态账本
- 03 工具边界
- 04 闭环记录
- 05 失败升级
先让任务走进正确的执行通道
同一个“帮我处理一下”的请求，可能只是一次可逆的小修，也可能会跨多个阶段、产生外部副作用。先决定流程重量，才能避免小任务被流程拖慢，也避免大任务靠对话记忆硬撑。
先决定流程重量，再开始执行
工作流不是越完整越好。用任务规模、状态风险和副作用三个信号，选择刚好够用的执行方式。
直接执行
不为了“小事”制造额外状态。
- 最小改动
- 局部验证
建立 TASK.md
把每次继续执行所需的事实外置。
- 阶段与进度
- 风险与验收
轻量 brief
用一页目标、边界和验证点，保持执行可读。
- 目标明确
- 不留长期负担
这不是审批流程。它只回答一个问题：为下一次继续执行，必须留下多少状态？ 能局部验证的任务直接做；有少量协作但不依赖长期状态的任务写 brief；只有必须分阶段验收、会中断续接或需要稳定记录风险与下一步时，才建立 TASK.md。文件多不等于一定要建状态文件。
用状态账本让大任务可以暂停后继续
TASK.md 不是聊天记录，也不是把每个念头都存下来。它是执行状态的事实来源：记录目标、当前位置、下一步和仍未关闭的风险。续接时仍要读取当前代码、项目规则和 git diff，确认外部事实没有在任务中断期间变化。
把“记忆中的进度”变成可交接的状态
适用于迁移、重构、规则调整、批处理和任何不能一次完成的任务。
最终效果、范围和验收标准。
当前阶段、已完成动作、下一步。
不可逆动作、依赖和人工判断。
实际改动、验证方式与遗留项。
小改一个函数、删几行规则或补一处文案时，不要为了“规范”新建状态文件。状态文件本身也有维护成本；它只应在任务会中断、会分批或会被他人接手时出现。
把模型判断和工具副作用放在两层
Agent 可以规划、比较和解释，但工具应该只做边界清晰的确定动作。真正可维护的设计，不是把工具包装得越来越深，而是让每次调用都回答四件事：谁授权、输入是什么、写到了哪里、结果怎样验证。
例如，网页自动化不要只返回“已完成”。它至少应返回目标元素、实际动作、页面反馈和异常信息；文件写入也要返回路径、变更摘要和可复核的结果。这样日志才是在描述事实，而不是在给成功贴标签。
每次执行都要形成一条可复盘的闭环
执行闭环的关键不是增加更多步骤，而是让每个阶段的输出成为下一阶段的输入。结果未验证时，它只是候选结果，不能被当作完成；需要人工判断时，工作流必须显式停在闸门前。
从请求到记录，不留“已经做了什么”的黑箱
这条轨道可以用于浏览器、文件、数据处理和内容生成等不同工具。
一个实用的日志条目不必很长：任务 ID → 工具动作 → 对象 → 结果 → 验证证据 → 下一步。保持格式稳定，才便于后续检索、排错和人工复核。
失败不是结束，而是一次有分级的升级
错误信息不等于失败处理。真正的失败处理要先隔离影响，再决定能否重试、能否回退，还是应该把带上下文的判断交给人。批量任务尤其不能把“一个失败”扩大成“整批状态不明”。
先守住状态，再决定重试、回退或交给人
每条失败路径都要有明确落点，避免异常被装饰器、重试循环或模糊提示吞掉。
先记录任务、对象、错误和已完成范围。
有限次数重试；每次记录条件与结果。
重试按明确对象执行回退并再次验证，不扩大修改或删除范围。
回退带上证据、选项和建议，而不是只报错。
人工确认最终，工作流的可靠性不来自“永不失败”，而来自失败时仍能说清：影响到什么、留下了什么状态、下一步由谁处理。