1、为什么先做多 Agent 产品，而不是平台

为什么先做多 Agent 产品，而不是平台 ## 这一章要回答什么 很多人第一次做 Agent，脑子里想的不是“先做一个能解决问题的产品”，而是： - 多模型接入 - 工具调用框架 - 工作流编排 - Agent 市场 - 权限系统 - 长期记忆 - 多租户后台 这些方向都没有错，但它们更像“平台能力清单”，而不是一个第一版项目应该承担的目标。

很多人第一次做 Agent，脑子里想的不是“先做一个能解决问题的产品”，而是：

• 多模型接入
• 工具调用框架
• 工作流编排
• Agent 市场
• 权限系统
• 长期记忆
• 多租户后台

这些方向都没有错，但它们更像“平台能力清单”，而不是一个第一版项目应该承担的目标。

这章想讲清楚一件事：

对于大多数个人开发者来说，做 Agent 的第一步不是先做平台，而是先做一个场景明确、链路完整、可以被用户真正使用的产品。

为什么平台思路容易失控

平台思路最吸引人的地方，在于它看起来很“通用”、很“高级”、很“有想象空间”。
但第一版就走平台路线，通常会遇到三个问题。

1. 边界很难收住

你很难说清楚第一版到底只做什么，不做什么。

因为一旦你说自己在做“Agent 平台”，用户自然会期待：

• 可以接很多模型
• 可以加很多工具
• 可以自定义流程
• 可以配置很多角色
• 可以适配很多业务场景

最后项目会变成一个不断扩张的待办清单。

2. 很难验证真实价值

平台能力本身不是用户最终要买单的东西。

用户真正关心的是：

• 这东西能不能帮我把事情做完
• 它到底帮我省了什么时间
• 它能不能稳定地产出结果

如果你只做了一堆“能力底座”，却没有一个完整场景跑通，就很难知道这些能力到底有没有价值。

3. 工程复杂度上升得太快

平台会天然把你推向很多高复杂度问题：

• 抽象层怎么设计
• 插件接口怎么定
• 工作流 DSL 怎么定义
• 多角色怎么编排
• 状态机怎么泛化

这些问题并不是不能做，而是太早做，往往会拖慢你验证产品价值的速度。

为什么先做产品更合理

和平台相比，先做产品的好处非常直接。

1. 更容易定义一个完整闭环

产品一定要围绕一个具体任务来设计。

比如当前项目的任务闭环就是：

1. 用户创建写作任务
2. Dispatcher 规划标题和文章主线
3. Research 整理研究摘要
4. Writer 生成初稿
5. Reviewer 做审核把关
6. Writer 生成修订稿
7. 用户确认最终结果

这条链路是不是完整、哪里卡住、哪里有价值，都很容易看清楚。

2. 更容易做出“可演示”的成果

平台第一版通常很难一眼看出价值。
但产品不一样。

当前项目最后能直观看到：

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

这比“支持多 Agent 编排”更容易让人理解，也更容易说服别人继续投入。

3. 更容易逼出真正需要的平台能力

先做产品还有一个很重要的价值：

你会在做产品的过程中，自然知道哪些能力值得被抽象出来。

比如当前项目就是这样一步步演进出来的：

• 先有固定 Agent
• 再发现规则不能写死在代码里，于是做了 rules.md
• 再发现任务不是一次性跑完，于是做了审批断点
• 再发现失败不可避免，于是补了自动重试
• 再发现多轮反馈会互相打架，于是补了冲突确认和 effective_feedback
• 再发现调试只看 Prompt 不够，于是补了 Context Breakdown

这些能力不是先靠“想象”出来的，而是在真实产品里被需求推出来的。

当前项目为什么选“多 Agent 写作产品”

这个仓库最后落地的是一个：

面向技术 / AI 自媒体文章写作的多 Agent 工作台

它不是一个通用平台，而是一个被刻意收窄的产品。

之所以选这个方向，是因为它同时满足几件事：

• 输入清楚：选题、角度、读者、风格、字数
• 输出清楚：提纲、初稿、审核意见、最终稿
• 角色边界清楚：规划、研究、写作、审核
• 结果可演示：页面上能直接看到产物
• 工程复杂度可控：可以先用 FastAPI + SQLite 单机跑起来

这就是一个非常适合入门的 Agent 产品场景。

“先做产品”在这个项目里具体意味着什么

如果我们把当前项目拆开看，会发现它从第一天起就不是“自由编排平台”，而是一个围绕具体业务目标设计的系统。

固定角色，而不是无限角色

当前项目只保留了 4 个 Agent：

• Dispatcher
• Research
• Writer
• Reviewer

这让职责边界足够清楚，也降低了调试成本。

固定流程，而不是自由工作流

当前主链路是固定的：

plan -> research -> draft -> review -> revision

这条链路由代码控制，模型只负责具体内容生成。

先做可用性，而不是先做抽象能力

当前项目优先补的是：

• 任务中心
• 模型配置
• 规则管理
• 失败重试
• 中断任务
• 回收站
• 数据导出

这些东西听起来没有“平台”那么酷，但它们直接决定产品能不能被持续使用。

平台什么时候才值得做

这并不是说平台永远不该做。
而是说平台应该建立在已经跑通的产品之上。

更合理的顺序通常是：

1. 先做一个具体场景的产品
2. 在产品里跑通任务闭环
3. 观察哪些能力是重复出现的
4. 再把这些能力抽成更通用的组件

对当前项目来说，未来真正有机会抽象的平台能力可能包括：

• 上下文构建器
• 质量闸门
• 反馈归并与冲突裁决
• 可配置流程步骤
• Agent 定义与模型绑定

但这些都应该是在产品基础上抽象，而不是在产品还没成立时先设计出来。

这一章的结论

做 Agent 的第一步，最稳的方式是：

1. 先选一个足够具体的场景
2. 做出完整任务闭环
3. 把配置、日志、错误恢复、人工确认都补起来
4. 再把里面沉淀出的共性能力抽出来

一句话说：

先做产品，后抽平台。

下一章看什么

既然第一步应该先做产品，那么下一个问题就是：

什么样的场景，适合作为多 Agent 产品的第一个 MVP？

下一章我们就结合当前项目，讲清楚为什么最后选的是“技术 / AI 自媒体写作”，以及一个好场景应该怎么收敛。