知道“先做产品，不先做平台”之后，下一步最关键的问题就是：

第一个 Agent 产品应该选什么场景？

这个问题看起来像产品选题，实际上直接影响后面的所有工程设计：

  • Agent 怎么拆
  • 流程怎么定
  • 上下文怎么组织
  • 页面怎么设计
  • 成果怎么展示

选对场景，很多设计会自然长出来。
选错场景，系统会一直处在“勉强能跑，但很难做好”的状态。

一个好的 Agent MVP 场景，通常具备什么特点

从当前项目倒推，一个适合作为第一版的场景，最好满足下面这几个条件。

1. 输入清楚

用户最好能明确说出自己要什么。

比如当前项目的输入就是：

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

这些输入天然适合做成表单，也方便被多个 Agent 共享。

2. 输出清楚

如果一个任务最后产出的东西很模糊，就很难判断 Agent 到底做得好不好。

当前项目的输出就很明确：

  • 标题
  • 提纲
  • 初稿
  • 审核意见
  • 最终 Markdown

这让每一步都能被检查，也方便做人工确认。

3. 中间过程可拆角色

并不是所有任务都天然适合多 Agent。

如果一个任务本质上只是“一次问答”，那硬拆出多个角色，通常只是增加复杂度。
但写作不同，它天然可以拆成：

  • 规划
  • 研究
  • 写作
  • 审核

这就给了多 Agent 足够的存在价值。

4. 结果容易展示

MVP 最大的目标之一，是让你能快速向别人证明这个东西“已经有用”。

文章写作的产物非常适合展示：

  • 页面里直接能看
  • 用户很容易比较前后版本
  • 审核意见也容易理解

这比很多“后台自动化”场景更适合当第一版。

5. 不依赖太多外部系统

第一版最好避免过强的外部依赖。

如果场景一上来就需要：

  • 对接多个 SaaS
  • 拿复杂权限
  • 调用很多企业系统
  • 写大量同步逻辑

那工程复杂度会被迅速抬高。

当前项目虽然有搜索和模型调用，但整体依赖仍然相对可控，所以很适合做入门型产品。

为什么“文章写作”是一个很好的入门场景

当我们把上述条件放在一起看，会发现文章写作几乎天然适合做多 Agent MVP。

输入和输出都足够清楚

它不是一个完全开放的问题，而是一个相对收敛的创作任务。

输入是任务信息，输出是文章产物。
这让流程非常容易围绕“任务”组织起来。

能自然拆出多个角色

写作不是单一步骤完成的，它天然有多个阶段：

  • 先确定方向
  • 再补资料
  • 再写初稿
  • 再审稿修订

这让多 Agent 协作变得自然，而不是为了多 Agent 而多 Agent。

容易加入人工确认

文章写作特别适合加入 HITL（Human in the Loop）节点。

因为用户很容易在这些阶段做判断：

  • 这个标题和方向是不是对的
  • 初稿是不是跑偏了
  • 最终稿是不是能发

这比很多完全自动化场景更容易形成“人机协作”的产品体验。

为什么进一步收窄到“技术 / AI 自媒体写作”

“文章写作”虽然已经不错了，但还不够聚焦。
如果继续泛化成“什么文章都写”，会出现几个问题：

  • 风格差异太大
  • 规则不好写
  • Agent 目标太散
  • 质量标准不一致

所以当前项目又进一步收窄成：

技术 / AI 自媒体写作

这样做有几个非常现实的好处。

1. 读者画像更明确

当前文章的目标读者通常是：

  • 技术从业者
  • AI 产品观察者
  • 个人开发者
  • 对新工具有兴趣的内容创作者

一旦读者更清楚，内容的深浅、术语密度、写法风格就更容易控制。

2. 题材结构更稳定

这类文章常见的结构其实很稳定：

  • 现象或问题切入
  • 产品 / 技术对比
  • 原理和使用场景拆解
  • 实战建议或结论

这使得 Dispatcher、Writer、Reviewer 都更容易形成稳定规则。

3. 审核标准更容易收敛

技术 / AI 文章的基本质量要求也更清晰：

  • 不要明显跑题
  • 不要乱造数据
  • 不要概念偷换
  • 不要空泛喊口号
  • 最好有结构、有判断、有案例

这正好适合后续引入“质量闸门”和人工审批。

当前项目中的场景定义是什么

如果用一句话概括当前项目的核心任务，可以写成：

给定一个技术 / AI 主题和写作要求，生成一篇适合自媒体发布的中文 Markdown 文章。

任务通常包括这些字段：

  • topic
  • angle
  • audience
  • tone
  • length
  • must_include
  • must_avoid

最终产出通常包括：

  • 标题
  • 提纲
  • 初稿
  • 审核意见
  • 修订稿

这个任务定义既足够清楚，又有足够空间让多个 Agent 协作。

为什么这个场景还能逼出很多“真实问题”

一个好的 MVP 场景，不只是“能跑”，还应该能逼出工程上的真实问题。
写作场景在这方面特别有价值。

会自然逼出上下文问题

不同 Agent 看到的输入不一样：

  • Dispatcher 看题目和角度
  • Research 看题目和必须覆盖点
  • Writer 看研究摘要和反馈
  • Reviewer 看文章正文和当前要求

这让“上下文怎么构建”变成了真实问题，而不是纸上谈兵。

会自然逼出多轮反馈问题

文章很少一次就完美。
用户会 reject，会补充要求，会产生相互冲突的意见。

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

  • issue_board
  • effective_feedback
  • pending_conflict
  • 冲突确认

这些都来自真实场景的推动。

会自然逼出质量控制问题

写作场景非常容易出现：

  • 标题跑偏
  • 初稿跑题
  • 审核发现“得重写”

所以当前项目后来补了：

  • Dispatcher 一致性检查
  • Reviewer 结构化质量闸门
  • 自动回炉 Writer

这说明场景本身能把系统往更真实的产品形态推。

这一章的结论

第一个 Agent MVP 最好选：

  • 输入清楚
  • 输出清楚
  • 适合拆角色
  • 容易展示
  • 工程复杂度可控

当前项目最终选择“技术 / AI 自媒体写作”，不是因为它最宏大，而是因为它非常适合把多 Agent 产品的核心问题都跑出来。

下一章看什么

场景定下来以后，下一个问题就变成：

第一版到底该用什么技术栈，才能最快把这个产品跑起来？

下一章我们就结合当前项目，讲清楚为什么最后选的是 FastAPI + Jinja2 + SQLite，以及这套技术栈如何支撑多 Agent MVP。