别乱叫 Agent

装了一堆 agents 以后，最常见的问题不是“不够用”，而是“不知道该叫谁”。

前端有 Frontend Developer，审查有 Code Reviewer，复杂一点还有 Architect、Reality Checker、MCP Builder、Project Manager。名字都挺对，放在那里也都像能派上用场。可真到一个具体任务面前，反而开始犹豫：是先叫架构，还是直接叫开发？写完以后让谁查？一个小改动要不要动用 orchestrator？

这才是 agency-agents 这类项目真正值得看的地方。不是它整理了多少角色，而是它有没有帮人从“我有很多 agent”走到“这件事该用哪个 agent”。

Agent 角色为什么会越用越散

它确实有帮助，但还不是一套完整的自动路由方案。

agency-agents 做得比较实在的一点，是 README 里的每个 agent 不只写名字，还写了 Specialty 和 When to Use。这两个字段看起来很普通，但对日常使用很关键。因为很多人卡住的地方，不是认不出“前端开发者”这几个字，而是不知道这个角色该在什么场景下出场。

比如 Frontend Developer 对应现代 Web 应用和 UI 实现，Code Reviewer 对应 PR 审查、质量门禁和代码指导，Reality Checker 更偏生产就绪检查。这样一来，agent 就不是一堆漂亮名片，而是开始有了入口条件。

从提示词到专业团队

但这还只是第一层。

真正有意思的是它里面有一个 Agents Orchestrator。这个角色不是再增加一个专家，而是试图管理专家之间的调用顺序。它的文件里写得很具体：先让 project-manager-senior 把规格拆成任务，再让 ArchitectUX 做技术和 UX 基础，然后进入开发和 QA 的循环。每个任务实现完以后，要找 EvidenceQA 做验证；最后再交给 testing-reality-checker 做总体验收。

这已经接近“什么时候该叫谁”的答案了。不是先随便叫一个最顺眼的 agent，而是按任务阶段来叫：没拆清楚时找 PM，没定结构时找架构和 UX，进入实现时找对应开发者，做完以后找 QA，最后找 Reality Checker。它解决的是完整开发链路里的 agent 编排问题。

Agent 跨工具安装路径

不过它解决得也有边界。

Agents Orchestrator 更适合完整项目或者比较重的功能开发。它默认你有规格文件，有任务列表，有开发和 QA 循环，也愿意接受一套比较严肃的流程。这个设计对做一整个功能很有用，但对日常那些零散任务就有点重。

比如“帮我看看这段组件为什么布局错了”“这篇文章要不要改标题”“这个脚本报错帮我定位一下”。这种任务如果也先 PM、再 ArchitectUX、再 Dev-QA Loop，就过度了。小任务需要的是快速判断，不是完整流水线。

日常使用时，可以先看 README 里的 When to Use。任务很明确，就直接按场景选 agent。界面实现找前端，接口设计找后端，安全问题找 Security Engineer，代码合并前找 Code Reviewer，发布前找 Reality Checker。

任务一旦不再是单点问题，而是需要从需求、架构、开发、验证一路走完的小项目，再考虑 Agents Orchestrator。这时候让 orchestrator 负责派人，比自己在一堆 agents 里来回挑更稳。

不是所有 Agent 都该装进项目

但它还没有完全解决一个更日常的问题：自动帮你从一句自然语言任务里判断该叫哪个 agent。

README 里有 Interactive agent selector web tool 和 Agent personality quiz，但它们还在 roadmap。也就是说，当前这个仓库更多是把 agent 文件、分类、安装和典型使用场景整理好了，还没有变成一个真正的“调度中枢”。你仍然需要自己判断任务属于哪一类，或者先叫 orchestrator 让它来拆。

这点反而要说清楚。否则很容易把它误解成“装完以后 AI 会自动知道该找谁”。按当前资料看，还没到这一步。

如果现在已经装了很多 agents，更实际的用法不是继续扩充数量，而是先做减法。

可以先把常用任务分成几类：写代码、查问题、做设计、审查质量、整理需求、发布验证。每一类只保留一两个最常用的 agent。日常任务直接叫对应角色；一旦任务跨过两个以上阶段，比如既要拆需求、又要实现、还要验证，再考虑叫 Agents Orchestrator。

这样用，agency-agents 的价值会清楚很多。它不是替你彻底消灭选择成本，而是给你一套可以抄作业的角色清单和编排样例。真正要落到自己的工作流里，还得把那一百多个角色收窄成自己的“常用席位”。

这也是看这个项目时最该留下的判断：agent 越多，越不能靠感觉调用。

一个 agent 库如果只负责让你装更多角色，最后只会更乱。agency-agents 有价值的地方，是它至少开始回答“谁在什么场景下出场”，并且用 orchestrator 给了一个重任务的调度模板。只是对日常小任务来说，它还需要你自己再做一层筛选和规则沉淀。

所以它不是终点，但可以当成一套起步材料。

先别把所有 agent 都装进工作流。先挑出真正反复用到的几个，再给它们写清楚触发条件。等任务复杂到单个 agent 扛不住，再让 orchestrator 出场。这样 agent 才像团队，而不是一屋子等着被点名的人。

项目地址：