用 AI 做 App,我给自己配了 5 个 Agent

终于，你准备把自己的想法做成一个 App 了。打开电脑，建好项目文件夹，准备让 AI 开始干活。

早就听说 AI 能同时调好几个 Agent 干活，那么需要几个？如何分工？每个 Agent 又该如何设定？

我刚开始独立开发时，也为这些问题纠结过很久。现在我的「小步慢跑」项目里，一共有 5 个 Agent：1 个主 Agent 和 4 个子 Agent。它们不是一开始就设计好的，而是随着产品的开发慢慢增加的。

先介绍一下我的 App。「小步慢跑」是一个超慢跑App，它特别的功能是：通过专门设计的节奏音乐，引导用户保持稳定的跑步步频。音乐是它的核心功能之一，所以最开始，我就设计了两个子 Agent：一个负责 App 的功能界面，一个负责音乐功能的开发。

那我提一个需求，究竟应该交给哪个 Agent 呢？毕竟我没有研发背景，我也没法每次都准确判断，这就是我的主 Agent 重点负责的事情。

我主要和主 Agent 沟通功能逻辑、实现细节，由它来判断如何实现、分配任务。 在我的工作流中，主 Agent 更像是架构师或研发 leader，子 Agent 则是不同领域的研发。

后来，在不断尝试不同音乐风格的过程中，我又增加了一个音乐探索的 Agent，专门在本地实验音乐生成，不参与 App 构建。此外，还有一个测试 Agent。不过我主动使用它的次数不多，也没有检查其他 Agent 是否调用过它，因此暂时无法判断它的实际作用。

回头看，我觉得 Agent 分工应该从实际任务出发，先有具体的工作，再根据工作的需要设计 Agent。不需要在项目刚开始，就给自己设计一个看起来很完整的 AI 研发团队。

角色分好了，接下来就要给 Agent 写设定。

具体内容怎么写呢？承接上面，自己要先想清楚：这个 Agent 究竟负责什么工作？网上常说，要把 AI 当成一位天才实习生。你需要告诉它项目背景、工作目标、职责范围，以及有哪些特殊要求。剩下的，就交给 AI 组织成文档吧。

举个例子，我现在已经不自己写 PRD 了，在一个功能点的细节逻辑和 AI 讨论完之后，让它去写 PRD 和研发文档，开发测试完后，最终再根据实现效果修改，并最终调整刷新项目里的其他的相关文档。这套规则能够保持整个项目背景的实时刷新，当然就要写到 Agent 的设定里面去啦，还让 Agent 会根据情况自动让我确认是否调整。

不过，我后来还有一个体会：Agent 的设定并不是越详细越好，下面分享一个反例。

春天的时候，公司内部经历了一轮 AI 大跃进。我也尝试设计过一个「产品经理 Agent」，希望它能协助完成基础的需求分析和判断（改天可以写写我对结合AI 的产品设计工作流的思考）。

我主要有两个应用场景：1）对于问题比较明确的小需求，由 AI 整理功能逻辑，生成 PRD。2）对于其他部门提出的一句话需求，由 AI 分析问题、引导对方补充信息，减少产品经理反复沟通的工作（aka 减少我的内耗）。

于是我写了一套复杂的 Agent 规则，例如，我希望它先判断需求所处的阶段，再调用相应的分析方法；如果缺少上一阶段的关键产物，就指出信息缺口，引导对方补充，而不是直接推进。

听起来是不是挺合理的？结果在实际对比中，输出效果甚至还不如没有这些 Agent 设定时的表现。

为什么会这样？我是觉得产品方法论都是需要根据具体问题灵活使用，是一种依赖大量经验的处理判断，这很难依靠一套预先写好的流程来做。如果试图用一套严格的步骤规范 AI，在上下文无法充分暴露的情况下，可能反而限制了它已有的分析能力（人是不是也一样呢？如果充斥的是固定的流程，只会让人也丧失了分析能力）。

后来，我大幅精简了这个产品经理 Agent 的设定，而去重点建设、蒸馏项目的知识库，让 AI 获得充分、准确的业务上下文。在实际使用中，也主要在业务的各个环节协助我分析，我并不会直接使用 Agent 的输出。

当然，我还是忍不住在里面放了一些自己对于产品设计的执拗，算是个人价值观的一点坚持。真好奇这些初始设定，这些初始设定会不会在某个地方碰撞出火花。

这些都是我目前的探索，随着项目和模型能力的发展，还会继续调整。对于刚开始用 AI 做产品的人，我觉得不用太纠结 Agent 的数量和配置。先从具体任务开始，在协作中发现问题，再逐渐完善分工和规则。毕竟我们的目标是把产品做出来，而不是设计一套完美的 Agent 组织架构。