AI Agent 工作流设计的 5 个反模式

第一个月：让 Agent 能工作。
第二个月：让 Agent 记住事情。
第三个月：意识到工作流设计全是坑。

如果重来一次，我会避开这些反模式。

反模式 1：一次性复杂指令

错误做法：

"帮我搜索最新的 AI 论文，总结要点，写成博客，发布到网站，并发送邮件通知"

为什么失败：
- 中间任何一步出错，整个任务失败
- 无法精确定位哪一步出问题
- 难以重试或恢复

正确做法：分步确认

"第一步：搜索 AI 论文，返回前 5 篇"
"第二步：为每篇写 200 字总结"
"第三步：整合成博客文章"
"第四步：发布到网站"
"第五步：发送邮件通知"

每步完成后，你有机会验证、调整、中止。

反模式 2：假设模型"理解上下文"

错误做法：

"根据我们之前的讨论，继续优化代码"

为什么失败：
- "之前的讨论"可能已经超出上下文窗口
- 模型可能记不住你说的"我们"
- 不同会话之间没有记忆

正确做法：显式传递上下文

"这是我们要优化的代码：[code]
这是我们之前讨论的优化方向：[summary]
请基于这些信息继续优化"

不要依赖"隐式记忆"，要显式传递。

反模式 3：错误处理等于"再试一次"

错误做法：

try:
    result = execute(command)
except:
    result = execute(command)  # 再试一次

为什么失败：
- 同样的错误会重复发生
- 浪费 token 和时间
- 没有诊断信息

正确做法：分类处理

try:
    result = execute(command)
except TimeoutError:
    # 超时：调整参数或换方案
    result = execute_with_timeout(command, timeout=60)
except PermissionError:
    # 权限：提权或换用户
    result = execute_with_sudo(command)
except ValidationError:
    # 参数错误：诊断并修复
    fix = diagnose_validation_error(command)
    result = execute(fix)

不同错误，不同处理。

反模式 4：工具调用不验证结果

错误做法：

response = search_api(query)
return response  # 直接返回，不验证

为什么失败：
- API 可能返回错误
- 数据格式可能不对
- 空结果被当成正常结果

正确做法：多层验证

response = search_api(query)

# 第一层：HTTP 状态码
if response.status_code != 200:
    raise APIError(f"API failed: {response.status}")

# 第二层：数据结构
if "results" not in response.json():
    raise DataError("Missing results field")

# 第三层：业务逻辑
if len(response.json()["results"]) == 0:
    return "No results found"  # 明确的空结果

# 所有验证通过
return response.json()["results"]

每一层都捕获不同类型的问题。

反模式 5：没有回滚机制

错误做法：

# 执行不可逆操作
delete_file("/path/to/file")
update_database(record_id, new_data)
send_email(user, message)

为什么失败：
- 一旦出错，无法恢复
- 调试代价高
- 用户体验差

正确做法：可回滚设计

# 1. 先备份
backup = backup_file("/path/to/file")
old_data = read_database(record_id)

# 2. 执行操作
try:
    delete_file("/path/to/file")
    update_database(record_id, new_data)
    send_email(user, message)

# 3. 出错时回滚
except Exception as e:
    restore_backup(backup)
    update_database(record_id, old_data)
    log_error(e)
    raise

永远假设操作会失败，提前设计回滚。

核心原则

1. 小步快跑
每一步都小到可以验证，快到可以重试。

2. 显式传递
不要依赖"隐式理解"，要显式传递上下文。

3. 分类处理
不同错误，不同策略。不要用"重试"解决所有问题。

4. 多层验证
HTTP、数据结构、业务逻辑，每层都有验证。

5. 可回滚
永远假设会失败，提前设计恢复机制。

实际案例

场景： Agent 自动发布文章到博客

第一版（失败）：

1. 写文章
2. 发布到博客
3. 发送 Twitter

问题：第 2 步失败后，文章丢了，无法恢复。

第二版（改进）：

1. 写文章，保存为草稿
2. 尝试发布
3. 成功：发送 Twitter，删除草稿
4. 失败：保留草稿，记录错误，发送通知

好处：失败不丢数据，可以手动重试。

如果你在设计 AI 工作流

问自己三个问题：

"如果这一步失败，我能知道是为什么吗？"
- 不能？拆解得更细。
"如果整个流程失败，我能回到哪里？"
- 不能？添加检查点和回滚。
"如果模型理解错了，我能发现吗？"
- 不能？添加验证步骤。

工作流设计不是让 Agent"更聪明"，是让它"更可靠"。
可靠性 > 聪明程度。

—— https://www.80aj.com