一个从Reddit帖子起步的项目，213天积累了97,392 Stars，覆盖11种主流AI编码工具——它到底是怎么做到的？

它是什么？

agency-agents（官方叫 "The Agency"）是一个AI Agent模板集合——不是代码库，而是一套可以直接塞进你现有AI工具的"员工档案"。

每个Agent都是一个.md文件，里面写清楚了这个"员工"的：

• 身份设定和说话风格（人格化）
• 擅长什么、不擅长什么（职责边界）
• 接到任务后怎么干（工作流程）
• 交付什么成果（可度量指标）

数据来源: github.com/msitarzewski/agency-agents

核心问题解答：深入理解这个项目

在正式介绍项目之前，有几个关键问题需要先说清楚——这些问题直接决定了你该怎么用这个项目。

问题一：它是"终点"还是"种子"？

先说结论：它是一颗种子，不是一棵大树。

很多人第一次看到这个仓库的反应是——"哇，147个专业Agent，太全了，直接用！"然后fork下来，装进Claude Code，结果发现：用是用了，但总觉得哪里不对。

问题出在哪里？

官方README里有一句话被很多人忽略了：

"Born from a Reddit thread and months of iteration"

这个项目是作者从真实使用场景里迭代出来的，它的147个Agent，是作者根据自己的工作流长期打磨出来的。而你看到的每一个.md文件，本质上是一套设计方法论的外化——不是拿来就能用的万能员工。

作者在strategy文档里明确写道：

"This is not a prompt collection — it is a deployment doctrine"

翻译成人话：这不是Prompt集合，这是一套如何部署AI Agent的操作手册。

所以正确的用法是：把它的147个Agent当成参考样本，去理解一套好的专业Agent应该长什么样——它的角色设定、工作流程、交付标准是怎么设计的。然后结合你自己的项目，写出真正适合你的Skill。

就像你不会直接拿别人的创业BP去融资，但你一定会参考它的结构和思路。

问题二：独立智能体 vs 子代理——区别挺大的

这是很多人在使用前没搞清楚的关键区别。

子代理（Sub-agent）：从属于一个主控Agent，只能被动接收主Agent的指令才能工作。在OpenCode的集成方式里，每个Agent的frontmatter里都有一个字段：

mode: subagent

这就是告诉你：这个Agent不是独立运转的，它需要被显式调用。

独立智能体（Autonomous Agent）：有自己的目标理解、规划、执行、反思能力，不需要人盯着，自己能跑完一整个任务。

agency-agents里的147个Agent，几乎全部是Sub-agent模式——它们的调用方式是：

@frontend-developer 帮我review这个React组件

而不是：

去把这个问题修一下，修好了告诉我结果

官方在OpenCode集成文档里写得很清楚：

"agents are invoked on-demand via @agent-name rather than cluttering the primary agent picker"

这就是说：你在OpenCode里主动@调用某个Agent，这个Agent才工作。你不调用，它就在那躺着。

为什么强调这一点？

因为如果你以为装了147个Agent，Claude Code就能"自动"组成一个团队各干各的，那你大概率会失望——没有协调机制，它们就是各自为战。

问题三：大模型是不是已经内置了？这些Skill还有意义吗？

有人说："你设计出来的这些，大模型本身就会了。比如你定义一个Frontend Developer Agent，但现在的GPT-4o、Claude Sonnet 4本身就能做前端开发，你这不是多此一举吗？"

这个质疑很普遍，但要拆开看。

大模型确实"会"——但"会"和"做得好"是两回事。

举一个真实的例子：你想让AI帮你做一个企业官网。你用通用LLM，它可能给你一套很"正确"的代码，但可能是：

• 用了一套过于复杂的架构（为了展示能力）
• 没有按你们公司的品牌规范来
• 交付的是"教科书式的标准答案"，而不是"你们公司真正需要的东西"

而agency-agents里的Frontend Developer Agent是怎么工作的：

"Default requirement: Ensure accessibility compliance and mobile-first responsive design"

它给出的不是通用最优解，而是有约束条件的交付物——你公司的技术栈、你们团队的设计语言、你们的发布流程。

这就是差距所在：大模型知道前端开发的"最佳实践"，但不知道"你的最佳实践"。

Skill的核心价值不是告诉LLM"你会做前端"，而是把你团队的上下文、你项目的约束、你交付的标准编码进去，让LLM的输出更接近"你想要的结果"，而不是"一个标准的正确答案"。

那这个项目本身的价值在哪里？

它的价值不在于147个Agent的最终成品，而在于：

1. 它教你如何设计一个Skill——角色设定→职责边界→工作流程→交付标准，这套框架可以直接迁移
2. 它帮你跳过"从零设计"的阶段——你可以拿一个现成的Agent改，比自己从头写快10倍
3. 它提供了一套多工具适配体系——11种工具的转换脚本，你不用自己造轮子

问题四：各做各的，容易把主智能体弄坏？

这个问题来自社区的真实反馈：

"这个skill不仅是prompt...还是多workspace 多agent。如果你没有成熟的工作流或者设计闭环，它就是各做各的。还容易把你主智能体弄坏。"

这是个好问题。我们来仔细看一下。

先看官方给出的多Agent协作示例：workflow-startup-mvp.md

它的协作模式是这样的：

Sprint Prioritizer（规划）
    ↓ 人工粘贴输出
UX Researcher（调研）
    ↓ 人工粘贴输出
Backend Architect（后端设计）
    ↓ 人工粘贴输出
Frontend Developer（前端开发）
    ↓ 人工触发
Reality Checker（质量核查）

关键发现：目前的标准工作流，完全依赖人工作为"胶水"——你手动复制上一个Agent的输出，粘贴给下一个Agent。没有自动的上下文共享，没有共享记忆，没有自动任务分发。

文档里明确写道：

"Copy-paste agent outputs between steps — don't summarize, use the full output"
"You are the glue."

这就是说：在基础模式下，你就是那个协调者。每个Agent独立接收你的指令，独立输出结果，Agent和Agent之间不直接通信。

那"把主智能体弄坏"是怎么回事？

这个问题主要出现在没有清晰workflow设计的情况下：

• 你同时激活了3个Agent，每个都给你一堆输出
• 你不知道该信哪个、该先用哪个
• 主Agent被各种上下文污染，输出质量下降
• 最后变成"三个和尚没水喝"

官方也意识到了这个问题，所以专门做了一个 Agents Orchestrator Agent：

"You are the AgentsOrchestrator, the autonomous pipeline manager who runs complete development workflows from specification to production-ready implementation. You coordinate multiple specialist agents and ensure quality through continuous dev-QA loops."

但坦白说，这个Orchestrator Agent本身也是一个Sub-agent——它解决的是"谁来协调"的问题，但协调的动作仍然需要你触发。

结论：如果你打算同时使用多个Agent，有几件事必须先做好：

1. 明确的工作流——先想清楚先用什么、再用什么，而不是想到什么用什么
2. 上下文管理——每个Agent的输入要精炼，别把上一轮的全部输出都塞进去（会超出context窗口）
3. 用Reality Checker当守门员——每个阶段完成后，用Reality Checker评估一下能不能进入下一阶段
4. 不要同时激活太多Agent——2-3个并行是合理的，同时激活147个是不合理的

规模有多大？

目前仍在活跃维护（最新提交：2026-04-12），Issues共135个开放中。

12个部门，147个"员工"

💻 工程部（29个Agent）

覆盖前端、后端、移动端、DevOps、AI工程、安全、嵌入式、游戏开发等。

代表性Agent：
- engineering-frontend-developer — React/Vue/Angular，有Core Web Vitals达标要求
- engineering-security-engineer — 威胁建模、安全代码审计
- engineering-autonomous-optimization-architect — LLM路由、成本优化
- engineering-incident-response-commander — 生产事故复盘模板
- engineering-codebase-onboarding-engineer — 新开发者代码库入门引导

🎨 设计部（8个Agent）

UI设计、UX研究、品牌视觉、图像提示词工程，Whimsy Injector负责给产品加趣味设计。它的slogan是：

"Every playful element must serve a functional or emotional purpose. Design delight that enhances rather than distracts."

📢 营销部（30个Agent）

这个部门最有"中国特色"——包含小红书、微信公众号、抖音、百度SEO、快手、B站、跨境电商等专属Agent。

🧪 测试部（8个Agent）

Evidence Collector的一段话很有代表性：

"I don't just test your code - I default to finding 3-5 issues and require visual proof for everything."

🎮 游戏开发部（20个Agent）

按引擎分类：Unity、Unreal Engine、Godot、Blender、Roblox Studio。

🏛️ 战略部（16个文件）

Agent协调、交接模板、阶段式执行剧本。NEXUS Strategy是一套完整的多Agent编排方案，覆盖从发现到上线的6个阶段。

核心技术：多工具适配

这个项目最聪明的设计，是一套自动转换脚本。

它把同一套Agent定义，转换成11种AI工具的原生格式：

安装只需两步：

./scripts/convert.sh          # 生成所有工具的适配文件
./scripts/install.sh          # 交互式安装（自动检测已装工具）

中文社区

@jnMetaCode 维护的 agency-agents-zh 已翻译141个Agent，另有46个中国市场原创Agent。

和传统Prompt模板的本质区别

踩坑记录

1. README里Agent数量不一致：正文写147个，Stats区写144个，Issue #519 已有人提

2. 中文翻译有延迟：英文版更新后，中文仓库可能有滞后

3. Agent质量参差不齐：147个并非每个都经过生产验证，建议先用Engineering部门的成熟Agent

4. 基础模式下多Agent协作需要人工协调：没有自动上下文共享，需要手动复制粘贴输出，文档原文："You are the glue"

5. 别同时激活太多Agent：建议2-3个并行，太多反而降低质量

选型建议

适合的场景：
- 想快速组建"AI团队"处理特定业务场景（营销、投放、SEO）
- 想参考专业Agent的设计方法，写适合自己项目的Skill
- 多工具用户，需要跨工具迁移同一套Agent定义
- 中国市场从业者（有完整本地化支持）

不适合的场景：
- 需要真正的多Agent自动协作（它本质上是模板库，不是Multi-Agent框架）
- 已经有成熟的自定义Agent体系
- 期望装进去就能自动运转（没有协调机制，它就是一堆独立的Sub-agent）

写在最后

agency-agents 真正让我思考的不是"它有多少个Agent"，而是两个问题：

第一，Agent的核心价值是什么？

不是"有多智能"，而是"有多适合你的场景"。大模型知道"前端开发的最佳实践"，但不知道"你的团队的最佳实践"。把团队上下文编码进Agent，比让Agent自由发挥更接近你想要的结果。

第二，多Agent协作的瓶颈在哪里？

不是Agent本身，而是协调机制。147个Agent都能工作，但如果没有NEXUS那样的编排体系，它们就是各自为战的"专家孤立系统"。你才是那个Orchestrator——官方文档里那句话说得最准确："You are the glue"。这不是bug，是目前所有类似工具的共同限制。

这个项目的真正价值，不是那147个现成的Agent文件，而是它提供的那套设计方法论和协作框架。用别人的经验缩短自己的弯路，拿来改，结合自己的场景迭代——这是一颗种子，不是乘凉的大树。

你在设计自己的Agent Skill时，遇到过什么问题？有没有好的实践分享？评论区聊聊。