看我如何用多 Agent 协同工作

写小东西，一个助手就够。做 App 这种要好几个角色轮着上的活，我现在更愿意拆成一支小队，各聊各的。

我攒过不少用 Agent 的方式

这一两年，常见用法我基本都试过。

有时就一个窗口聊到底。有时给同一个助手不停装 Skill、接工具，盼着它越来越全能。改脚本、改文案、查报错，这样用确实爽，少切换。

工作里另一些事，我会主动换招。

尤其做 App。节点多、角色杂，硬塞给一个助手，构建过程更容易飘。那种时候，我更喜欢多 Agent 一起干。

做 App 时，我更想要一支小队

真做 App，很少是「你说一句，一个脑子答完」。

更像流水线。有人盯范围和优先级，有人写实现，有人找回归，有人做验收。节点不同，判断标准也不同。项目经理想的是里程碑和取舍，开发想接口和状态，测试想边界和复现，验收只关心这版能不能过。

这些全扔进同一个全能助手，聊天记录很快变成杂物间。上周的交互稿、某次接口命名吵架、半截失败日志、验收口径，缠成一团。下一句明明只是「登录失败的提示改清楚一点」，它却可能把测试用例或排期讨论一起拖出来。

所以我给自己定了默认班底：

• 项目经理：拆任务、排节点、盯范围
• 开发：实现、改代码
• 测试：找问题、写复现、盯回归
• 验收：对照目标，判断能不能过

美术资源真多的时候，再加一个美术 Agent。平时不加。小队够用就行，别为了显得很 AI 硬凑人数。

多开几个窗口还不够。每个 Agent 尽量有自己的工作空间和技能，上下文隔开。开发不用背整份验收话术，测试也不必被半截产品讨论带跑。我自己用下来，这样做出的 App 更稳一点：谁负责什么清楚，返工也少扯皮。

什么时候，多 Agent 协同更划算

多数人和我一样，日常还是单一助理用得多。单助手经常是对的，这点先说死。

任务同质、链路短、上下文本来就干净，硬拆小队只会多付切换成本。改句文案、问个 API、查一个孤立报错，一个助手通常更快。

我会认真考虑多 Agent，多半是下面几件事叠在一起：

1. 角色差得远，判断标准也不一样
2. 上下文会互相污染，A 节点的细节混进 B，答案容易歪
3. 需要交接或并行：开发改完测试接，测试踩坑再回到开发，别在同一段混聊里硬撑
4. 想长期分桶：同类事下次还找同一个人，技能和材料留在它自己的空间里

做 App，这几条几乎都会撞上。写周报、翻译一段话、问天气，通常撞不上。

也有反例。你其实一个人在写原型，所有节点都经你手，拆四个 Agent 可能只是仪式感。小队有用，是因为角色真的分叉了，不是名词好听。

第三态：一个入口调度，多个实体干活

多 Agent 不等于你必须自己当总机，挨个点开联系人。

我更常这么用：私人助理当入口，背后多个专职实体干活。

你跟入口说目标，比如「这周把登录链路做到可验收」。它去拉开发、测试，必要时拉验收。真正动手的，还是各自带着干净上下文的专职 Agent。

这里有两件事别混：

• 单入口：少点几下，省事
• 单上下文：所有角色记忆搅进同一锅

我要省事，不要搅锅。入口可以统一，上下文按实体分开。

我在 AgentUp 里就是这么用的。通讯录里既有私人助理，也有专职角色；跨界时由入口调度，别把项目经理、开发、测试的脑子缝成一个。

单 Agent 还是多 Agent，对照着选

前面说散了，收成一张表更好查：

做 App，右边这列几乎都会撞上。写周报、翻译一段话、问天气，通常还是左边。懒得挨个点开时，可以私人助理当入口，专职实体在后面干活。

下次做 App，至少把「实现」和「测试」拆成两段干净上下文，看返工有没有少，就是最小验证。

我正在用 AgentUp 这样用

这套选法不一定绑某个产品。我自己做进了 AgentUp：像加联系人一样加角色，私人助理可调度，专职 Agent 自带工作空间与技能。为什么做成通讯录，写在这篇创造日志里。

单一助理我还在用，而且用得很多。遇到 App 这种多身份、多节点的构建，我才会主动换成小队。隔开上下文，各干各的，我比较放心。