这一章要回答什么

当一个多 Agent 执行流已经能跑起来以后，很多项目会停在这里：

  • 一个输入表单
  • 一个“开始执行”按钮
  • 一段最终输出

如果只是做 demo，这样已经够了。
但如果你的目标是“做产品”，这远远不够。

这章要讲的是：

为什么一个 Agent 系统必须被做成后台工作台，而不是一次性脚本或单页 demo。

当前项目为什么没有停在“一个表单”

当前项目最后演进成了一个完整后台，而不是只保留“创建任务”页面。
这是因为真实产品天然会提出更多需求：

  • 用户要查看历史任务
  • 用户要知道任务现在跑到哪一步
  • 用户要在失败时重试
  • 用户要配置模型
  • 用户要修改 Agent 规则
  • 用户要导出结果

如果没有一套后台，这些能力很难持续使用。

当前项目的后台由哪些部分组成

当前工作台已经具备比较完整的产品骨架。

1. 概览页

概览页负责给出整个系统的当前状态，例如：

  • 任务总数
  • 正在运行的任务
  • 已完成任务
  • 最近任务

这类信息能让系统从“黑盒”变成“有全局视角的产品”。

2. 创建协作任务页

这里是任务的入口。

用户不是对着一个聊天框随便提需求，而是明确填写：

  • 选题
  • 角度
  • 读者
  • 风格
  • 字数
  • 必须覆盖
  • 需要避免

这让输入更加结构化，也更有利于后续构建 Agent 上下文。

3. 任务中心

这是后台最重要的页面之一。

它负责展示：

  • 任务状态
  • 当前标题
  • 最近更新时间
  • 失败情况
  • 进入详情页的入口

并且支持：

  • 重试
  • 中断
  • 删除

如果没有任务中心，系统几乎无法被管理。

4. 任务详情页

这是当前项目最有“产品感”的页面之一。

它不只是看结果，还能看到：

  • 流程进度
  • Agent 执行记录
  • 上下文快照
  • Context Breakdown
  • LLM Call
  • Quality Gate
  • 审批区

换句话说，任务详情页既是：

  • 操作页
  • 调试页
  • 复盘页

5. 模型配置页

模型配置没有写死在代码里，而是独立做成了页面。

当前已经支持：

  • 添加模型
  • 设置默认模型
  • 给不同 Agent 绑定不同模型

这让系统更接近真实产品，而不是只能靠改代码换模型。

6. Agent 管理页

当前项目不仅能看 Agent 列表，还能进一步编辑每个 Agent 的规则文件。

这一步很重要，因为它意味着：

Agent 不再只是代码对象，而是后台里的可运营对象。

7. 导出页和回收站

这些功能听起来像“后台细节”，但对真实产品很重要：

  • 导出帮助备份和迁移
  • 回收站减少误删风险

它们让系统更像长期使用的工具，而不是临时 demo。

为什么“任务中心”是 Agent 产品的核心

很多人会把任务中心看成附属功能，其实它是核心中的核心。

原因很简单：

Agent 系统不是一次性的，它天然是“任务型产品”。

只要是任务型产品，用户就一定会关心：

  • 我的任务有多少个
  • 哪些还在跑
  • 哪些失败了
  • 哪个最值得先处理

当前项目里，任务中心和任务详情页一起承担了“可管理性”这件事。
没有这两层，整个系统的可用性会大幅下降。

模型配置为什么必须独立出来

模型配置一开始如果写死在代码里，短期看很省事，长期看会非常痛苦。

因为很快就会出现这些需求：

  • 想试不同模型
  • 想给不同 Agent 绑不同模型
  • 想临时切默认模型
  • 想对比不同供应商效果

当前项目把这层独立出来后，带来了几个现实好处：

  • 换模型不用改 Python
  • Dispatcher / Research / Writer / Reviewer 可以分别绑定
  • 模型配置更适合运维和调试

这一步本质上是在把“模型调用”升级成“模型管理”。

后台工作台还带来了什么额外价值

一旦你开始认真做后台，很多之前看不到的问题就会被暴露出来。

1. 你会更重视状态设计

页面要展示什么，往往反过来逼着你把状态存清楚。

比如当前项目里，任务页和详情页的存在，逼出了这些状态字段：

  • status
  • current_agent
  • current_step
  • awaiting_checkpoint
  • last_error_type
  • retry_count

2. 你会更重视调试能力

用户在页面里能看到什么，会直接决定问题能不能排查。

这也是为什么当前项目后来补了：

  • LLM Call
  • Context Breakdown
  • Quality Gate
  • 故障面板

3. 你会更重视“人机协作”体验

当前项目的审批区后来也持续演进了：

  • 从双表单变成单输入框双按钮
  • 确认继续 用绿色
  • 退回修改 用红色
  • 冲突确认保留独立表单

这些都说明后台不是“顺手做个壳”，而是产品体验的重要部分。

这一章的结论

一个可用的 Agent 产品，不能只有执行链路，还必须有一套后台工作台来承载：

  • 任务管理
  • 结果查看
  • 审批交互
  • 模型管理
  • Agent 管理
  • 导出与清理

如果说前一章解决的是“系统能不能跑”，这一章解决的就是：

系统能不能被持续使用。

下一章看什么

把它做成产品之后，问题还没有结束。
你很快会发现，最影响体验的往往不是功能，而是这些“脏活累活”：

  • 模型超时
  • 任务失败
  • 任务要中断
  • 误删恢复
  • 数据备份

下一章我们就讲，怎样把一个“能跑”的 Agent 产品补成一个真正可用的系统。