这一章要回答什么

做完后台之后，很多人会有一种错觉：

“页面有了、任务能跑了，这个系统已经差不多可以用了。”

现实通常不是这样。

一个真实的 Agent 系统很快就会遇到这些情况：

  • 模型接口超时
  • 返回中断
  • 某一步失败后整条链路卡死
  • 用户想立刻停止任务
  • 删除了任务又后悔
  • 想把数据备份出来

这章讲的是：

怎么把一个能运行的 Agent 原型，补成一个真的可用的系统。

为什么“可用性能力”经常比 AI 能力更重要

这是很多入门项目最容易忽略的一点。

用户对一个 Agent 系统的第一感受，往往不是：

  • 模型够不够强

而是：

  • 出错了会怎么样
  • 能不能恢复
  • 我能不能停下来
  • 我能不能找回之前的数据

也就是说，真正决定系统能不能长期使用的，常常是这些非 AI 能力。

当前项目后来不断补的，也正是这些东西。

失败重试：不要让一次超时毁掉整条链路

模型调用最常见的问题不是“完全不可用”，而是：

  • 超时
  • 连接断开
  • 返回不完整
  • 临时网络错误

如果每次失败都要用户重新创建任务，体验会非常差。
所以当前项目补了自动重试机制。

当前项目的重试逻辑是什么

系统会记录：

  • 最近失败的 Agent
  • 最近失败的步骤
  • 错误类型
  • 当前重试次数
  • 最大重试次数

然后在可重试错误下，自动从失败步骤继续，而不是整任务重跑。

这一步非常关键，因为它让系统具备了“断点续跑”的基本能力。

为什么“从失败步骤继续”很重要

假设流程已经跑完了：

  • Dispatcher
  • Research
  • Writer draft
  • Reviewer

最后只是在 Writer revision 超时。
这时如果整任务重跑，不仅浪费成本，也让用户非常难以接受。

所以当前项目的策略是：

能从失败步恢复，就不要把整条链路推倒重来。

自动回炉：把明显不合格的内容挡在用户看到之前

当前项目后面又往前走了一步，不只是“失败重试”，还加入了“质量不达标时自动回炉”。

发生了什么变化

现在 Reviewer 不再只是输出一段自然语言，而是会给出结构化结果：

  • pass
  • revise
  • rewrite

其中：

  • rewrite 表示当前初稿质量太差，应该整体重写

这时系统不会立刻把这份内容交给用户，而是会：

  1. 自动回炉一次 Writer draft
  2. 再次跑 Reviewer
  3. 通过后才继续进入后面的 revision

为什么这属于“可用性”而不是“更聪明”

因为它不是为了追求更花哨的 Agent，而是为了减少明显低质量内容进入人工审批。

这对产品体验很重要：

  • 用户不需要每次都帮系统做基础质检
  • 任务流程更顺
  • 多轮 reject 的概率也会下降

最近还做了什么优化

为了让自动回炉更稳，当前项目还给这段流程单独调了调用策略：

  • 自动回炉 Writer draft 使用更长超时
  • 第二次 Reviewer 也使用更长超时
  • revision 也做了更稳的参数设置

并且已经通过自动化测试和真实任务跑通验证。

任务中断：允许用户说“停”

Agent 系统不是视频播放器，用户不可能永远等它跑完。

真实使用里，用户很常会遇到：

  • 发现选题不想写了
  • 模型明显跑偏
  • 任务排队太久
  • 想先停下来改配置

所以当前项目加入了任务中断能力。

当前中断能力包含什么

系统支持：

  • 用户主动发出中断请求
  • 当前步骤后续流程不再继续
  • 当前模型结果不再写回数据库
  • 任务状态变成 cancelled

这让产品体验从“只能等待”升级成“我能控制它”。

回收站：让删除动作变得可逆

任务系统里一个非常容易被忽略的细节，就是删除。

如果一上来就硬删除，用户迟早会踩坑。
所以当前项目采用的是两段式删除：

  1. 先移入回收站
  2. 再允许恢复或彻底删除

这虽然不是 AI 能力，但却是成熟产品感的重要来源。

数据导出：给系统留后路

当一个产品开始真正使用时，你很快会发现：

  • 想迁移环境
  • 想做备份
  • 想导出当前任务数据
  • 想把一份完整快照交给别人排查问题

所以当前项目补了导出页面，支持把数据库内容导出来。

这类能力的价值在于：

  • 降低试验成本
  • 方便迁移
  • 方便故障分析

为什么这些能力会反过来影响你的系统设计

一旦你认真补这些“可用性能力”，整个系统的设计思路也会被拉得更成熟。

你会更重视错误分类

不是所有错误都应该统一处理。
有些错误适合重试，有些不适合。

你会更重视状态持久化

没有清楚的状态，就做不好重试、中断和恢复。

你会更重视用户可见性

当前项目的故障面板、重试记录、失败步骤展示，都是在解决“系统不能只知道自己错了，用户也要看得懂”这个问题。

当前项目最近补上的两个“很实战”的点

这一章如果只讲传统的“重试、中断、回收站”，还少了两个现在已经非常关键的新能力。

1. 冲突确认

当多轮 reject 产生相互冲突的意见时，系统现在不会强行自己裁决，而是会：

  • 先检测冲突
  • 暂停在 conflict_resolution
  • 让用户确认最终生效结论
  • 再写回 effective_feedback

这也是一种“可用性能力”，因为它在避免系统越改越乱。

2. 上下文调试

现在任务详情页里不只显示 Prompt，还能看到：

  • Context Breakdown
  • LLM Call
  • Quality Gate

这大大提升了排障能力，也让系统更可维护。

这一章的结论

一个 Agent 系统想真正可用，至少要补上这些能力：

  • 失败重试
  • 失败步骤恢复
  • 任务中断
  • 回收站
  • 数据导出
  • 多轮反馈冲突处理
  • 调试信息可视化

这些能力看起来不像“AI 本身”，但它们往往决定产品到底能不能长期使用。

下一章看什么

当系统已经可用了，下一个很自然的问题就是：

Agent 还能不能继续只靠代码里的 Prompt 硬写？

下一章我们就讲，如何把 Agent 从“写死行为”升级成“可配置角色”，也就是当前项目里的规则文件、版本历史、diff 和回滚。