编辑文档 - 213天涨到10万Star：这个"AI外包团队"让我重新认识了Agent

标题

工具栏

点击或拖拽上传图片

支持 PNG, JPG, GIF, WebP 格式

内容 (Markdown 格式)

![051501.png](/uploads/f6805cb3c50142b5902eef12ee1c46ae.png)
**一个从Reddit帖子起步的项目，213天积累了97,392 Stars，覆盖11种主流AI编码工具——它到底是怎么做到的？**

---

## 它是什么？

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

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

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

**数据来源**: [github.com/msitarzewski/agency-agents](https://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里都有一个字段：

```yaml
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](https://github.com/msitarzewski/agency-agents/blob/main/examples/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个是不合理的

---

## 规模有多大？

| 指标 | 数值 |
|------|------|
| Stars | **97,392**（2026-05-15 GitHub API查询） |
| Forks | **16,162** |
| Agent总数 | **147个** |
| 覆盖部门 | **12个** |
| 支持工具 | **11种** |
| 仓库年龄 | **213天**（2025-10-13创建） |
| 日均增长 | **~457 Stars/天** |
| 语言 | Shell（bash脚本） |
| License | MIT |

目前仍在活跃维护（最新提交：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工具的原生格式：

| 工具 | 格式 | 安装路径 |
|------|------|----------|
| Claude Code | `.md`原生 | `~/.claude/agents/` |
| GitHub Copilot | `.md` | `~/.github/agents/` |
| Cursor | `.mdc rule` | `.cursor/rules/` |
| Windsurf | `.windsurfrules` | `.windsurfrules` |
| Aider | `CONVENTIONS.md` | 项目根目录 |
| OpenCode | `.md` (mode: subagent) | `.opencode/agents/` |
| OpenClaw | SOUL.md+AGENTS.md+IDENTITY.md | `~/.openclaw/` |
| Gemini CLI | Extension + SKILL.md | `~/.gemini/extensions/` |
| Antigravity | SKILL.md | `~/.gemini/antigravity/skills/` |
| Qwen Code | SubAgent YAML | `~/.qwen/agents/` |
| Kimi Code | YAML spec | `~/.config/kimi/agents/` |

安装只需两步：

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

---

## 中文社区

[@jnMetaCode](https://github.com/jnMetaCode) 维护的 [agency-agents-zh](https://github.com/jnMetaCode/agency-agents-zh) 已翻译141个Agent，另有46个中国市场原创Agent。

---

## 和传统Prompt模板的本质区别

| | 传统Prompt模板 | agency-agents |
|---|---|---|
| 深度 | 泛泛的"你是一个XXX" | 完整角色+工作流+交付标准 |
| 人格 | 无 | 每个Agent有独特说话风格 |
| 可度量性 | 无 | 每个Agent有Success Metrics |
| 工具适配 | 单一工具 | 11种工具自动适配 |
| 协作设计 | 无 | 有Sequential Handoff + NEXUS编排方案 |
| 上下文管理 | 无 | 需要人工粘贴（基础模式） |

---

## 踩坑记录

1. **README里Agent数量不一致**：正文写147个，Stats区写144个，Issue [#519](https://github.com/msitarzewski/agency-agents/issues/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时，遇到过什么问题？有没有好的实践分享？评论区聊聊。**

摘要

标签多个标签用逗号分隔

分类