把设计评审拆成三条流水线，WorkBuddy SubAgent 我是这么配的

多智能体这件事，我一开始理解偏了，以为就是同时开几个窗口，让几个 AI 各聊各的。把 WorkBuddy 的 SubAgent 跑通之后，我的看法变了。它真正解决的是任务排队，一件活干完再派下一件，不用所有事挤在同一个上下文里等着。

SubAgent 就是主 Agent 派出去的临时工。主 Agent 不干具体的活，只负责拆任务、派活、收结果；临时工各自带着自己的上下文去干，干完汇报，然后销毁。这个比喻我认，因为它跟我带外包的体验一模一样，最怕的是几个人在同一份文件上互相踩，活难本身还好。

我的环境是 macOS 桌面版 WorkBuddy，模型走自定义入口接的第三方 OpenAI 兼容接口。所谓 OpenAI 兼容接口，就是对方提供的地址和调用格式跟 OpenAI 那套一致，填进去就能用。不一定适用所有人，但思路是通的。

事情起因是上周三，我手上压着一批后台截图、一份 PRD 和三个 design-tokens.json，要给一套新后台做视觉评审。以前的做法是我自己一张张看，看到第四十张的时候眼睛就开始骗我了，颜色差两度都看不出来。

我先在 设置 里进 模型服务，选 自定义模型，把 Base URL 和 Key 填进去。这一步有个细节，主 Agent 和 SubAgent 用的是同一套 Key 和 Base URL，别分两处配，不然出问题的时候你得两头对，我第一次就吃了这个亏，查了快半小时才发现是 SubAgent 那边还挂着旧的 endpoint。

配好之后新建会话，在输入框旁边的技能入口里打开 SubAgent，选类型。WorkBuddy 里我常用三类。general-purpose 全能力，能读写文件能跑命令；Explore 只读，只能看不能改；Plan 偏分析规划。选错类型是后面一堆坑的源头。

我的拆法是三条线并行。第一条给 Explore，让它只读扫一遍截图目录，输出每张图对应的页面模块和当前色值。第二条给 Explore，让它读三个 design-tokens.json，把变量名和实际用色对齐，列出对不上的。第三条给 general-purpose，让它读 PRD，把设计约束拆成可校验的字段，Context、Goal、Inputs、Constraints 四块，每块都要能落成一句话。

这里有个关键点，任务简报不能写形容词。你写「风格要干净一点」，它给你的东西一定不干净。你得写「背景色仅允许取自 tokens 里的 --bg-* 系列，禁止出现第三个灰阶」。主 Agent 的活是把你的模糊需求翻译成可校验的字段，这件事只能你自己干，它替不了。

跑完大概二十分钟，比我一张张翻快太多了。三条线的结果互不污染，这点很舒服。Explore 那边扫图的时候不会把 PRD 的上下文带进去，输出干净得像刚洗完的杯子。

但是坑也不少。第一次我图省事，三条线全给了 general-purpose，结果负责读 PRD 的那条顺手把我 assets 目录里的原图重命名了，加了一堆前缀。我当时血压上来了。后来学乖了，凡是碰文件读写的活，一律先给 Explore，确认它只需要读，再考虑放权限。这个我两个月前写过一篇，说接完 DeepSeek 才敢让它碰素材目录，现在看还是太乐观，光按工具分级不够，得按 SubAgent 类型来。

还有一个坑是上下文不共享。主 Agent 拆完任务派下去，SubAgent 之间是看不见彼此结果的，所以汇总这一步必须由主 Agent 来做。我的做法是任务描述最后加一句，要求每条线输出固定字段，比如「模块名 / 当前值 / 期望值 / 是否一致」，四列对齐了它才汇总得动。字段名差一个字，整列就是空的，这个我跟它磨了很久。

协作上我是这么分的。设计稿的源文件和 tokens 文件放共享目录，团队里三个人都能读。

SubAgent 的配置和任务模板只有我能改，参数一乱，出来的东西全是噪音。评审结论导出成表之后丢群里，谁有异议在表上批注，不再口头对。

日常运维就两件事。一是每次跑完必看 SubAgent 的汇报，别只看主 Agent 的总结。临时工说的话里往往藏着它不敢往上报的问题。二是任务结束就关会话，别留着长会话连着跑，上下文越堆越脏，跟不洗的调色盘一样。

用到现在，我确实从执行者变成了只负责派活和验收的人。