13 万 Star。2 万多 Fork。254 个角色。名字里还带「Agency」。
一听就像——装了这个项目，你一个人就能运营一家 AI 驱动的软件公司。醒醒。Agency Agents 不是 254 个自动干活的数字员工。它甚至不运行任何模型。它只是 254 份写好了的角色说明书。
这篇文章不吹参数。我翻完了仓库里 17 个部门、254 个 Markdown 文件，装到了 Codex 和 Claude Code 里跑过，然后把该说的和不该期待的都说清楚。
它到底是什么——把「Agency」这个词先放下
Agency Agents 是 Michael Sitarzewski 发起的开源项目。它干的事其实就一件：把「前端开发」「后端架构」「产品经理」「安全工程师」这些岗位写成结构化的 Markdown 文件，再通过转换脚本，让它们能被 Codex、Claude Code、Cursor 等 AI 编程工具直接加载使用。
三层架构很清楚：
- Agency Agents（角色文件）：定义角色职责、工作步骤、交付物、验收条件。纯文本，零运行。
- 转换脚本（scripts/）：把 Markdown 转成 Codex 要的 TOML、Cursor 要的
.mdc规则、Claude Code 能直接读的原生格式。 - 宿主工具（Codex/Claude Code/Cursor）：实际执行推理、写代码、调工具、跑测试。角色文件只是给它加了份「你是 XX 岗位」的脑内预设。
换句话说：角色文件是剧本，宿主工具才是演员。 剧本写得好，能省下大量重复解释的时间；剧本再好，不会替演员背台词、走位和临场发挥。
一个 Agent 文件里写的不是魔法
翻开仓库里的 Frontend Developer，结构比你想象的完整：
- YAML 元数据：角色名、用途、图标色、沟通风格
- 角色身份：明确的职责边界（不是「你会前端」，而是「你负责界面实现、交互、响应式、可访问性，遇到后端决策时标出依赖」）
- 工作步骤：分析→设计→实现→测试→文档，有顺序
- 交付物要求：代码、组件、测试、说明——不止「给个建议」
- 验收条件：什么样的结果算做完了
这比「你是一名资深前端，请帮我看下代码」高了一个层级。但别被措辞骗了——文件里写的「生产可用」「达到性能指标」是对模型的要求，不是项目帮你证过的认证。你仍然得自己跑测试、看截图、做人工复核。
254 个角色长什么样
17 个部门，分布不太均匀：
| 部门 | 角色数 | 代表岗位 |
|---|---|---|
| 专项岗位 | 54 | 法律、供应链、教育、行业顾问 |
| 工程 Engineering | 49 | 前后端、架构、DevOps、数据库、AI |
| 营销 Marketing | 36 | SEO、内容、社交媒体、微信、抖音、GEO |
| 游戏开发 | 20 | 关卡、叙事、技术美术 |
| GIS | 13 | 地理信息、遥感、制图 |
| 安全 Security | 10 | 应用安全、云安全、身份审计 |
| 设计/测试/销售 | 各 9 | UI/UX、QA、销售策略 |
| 付费媒体/项目管理 | 各 7 | 广告投放、项目推进 |
| 学术/空间计算/支持 | 各 6 | 研究、XR、客户支持 |
| 财务/产品 | 各 5 | 财务分析、产品管理 |
| 医疗 | 3 | 医疗场景 |
工程+专项+营销占了主体。游戏、GIS 和医疗这类垂直领域虽少，但质量不差——尤其是对个人开发者来说，这些你平时根本不会想到的角色，翻一眼可能就打开思路。
三种安装方式，从最省事到最可控
方式一：桌面应用（零命令行）
直接去
Windows 用户注意：安装包暂未代码签名，首次启动 SmartScreen 会拦一下。只从官方 Release 页面下载，别走网盘和不明镜像。
方式二：命令行装到 Codex
git clone https://github.com/msitarzewski/agency-agents.git
cd agency-agents
./scripts/convert.sh --tool codex # Markdown → TOML
./scripts/install.sh --tool codex # 装到 ~/.codex/agents/装完后在 Codex 里这样用：
Use the Frontend Developer agent to review this component.方式三：只装一个部门到 Claude Code
# 不装全部，只拿工程和安全
./scripts/install.sh --tool claude-code --division engineering,security不想全装是对的。254 个角色塞进全局目录，噪声远大于价值。按项目装、按阶段启，比「全员到齐」有效得多。
别全装——5 个角色足够跑一个真实项目
以做一个小型 Web 产品（登录 + 付费功能）为例，这五个就够了：
- Product Manager → 理清目标用户、范围边界、验收条件
- Backend Architect → 数据结构、鉴权、支付回调、失败恢复
- Frontend Developer → 界面实现、交互、响应式
- Application Security Engineer → 越权检查、密钥、会话、输入验证
- Reality Checker → 别信「看起来完成了」，要截图、要构建结果、要测试通过
关键不在数量——在于每个角色有明确的输入和可验证的输出。PM 先产出验收条件，开发照着实现，安全和安全审查读真实代码说话，Reality Checker 收尾。Agency Agents 自己不会帮你串这条流水线，你得在宿主工具里逐步委派、验证、推进。
跑通一次之后，再考虑加 Technical Writer 写部署文档，或者 Game Developer 做交互细节。
它解决了什么、解决不了什么
四个实打实解决的问题：
- 省掉重复写角色提示词的功夫——常见岗位的职责、步骤、交付格式都写好了，拿来改改就能用，甚至不安装，直接翻阅文件里的检查清单都值
- 同一套角色跨工具迁移——Codex 用 TOML，Cursor 用
.mdc，OpenClaw 拆成 SOUL/AGENTS/IDENTITY，转换脚本帮你处理格式差异，比手工维护五六套副本强太多 - 强化的交付物和验收意识——好角色不只告诉你「怎么回答」，还要求代码、报告、指标、证据，这对压制 AI 编程工具「口头完成然后什么都没给」的毛病特别有用
- 岗位参考目录——254 个角色本身就是一份岗位清单，提醒你：一个功能除了编码，还有安全、测试、文档、发布和运营要做
四个不解决的事：
- 角色多≠效果好——大量全局角色增加选择噪声，宿主工具可能在相似角色间随机切换。少而精才是正道
- 部分角色有技术栈假设——比如 Reality Checker 里出现了特定目录结构和截图命名，你的项目没这些路径，它是不会自我修正的
- 提示词不能替工具权限——文件里写着「执行安全审计」，不代表模型能访问你的生产环境；写着「验证界面」，不代表它真的打开浏览器看过
- 第三方 Agent 指令也是供应链输入——它能指导 AI 运行命令、读文件、改项目。装之前看一眼源文件变更记录，优先项目级安装，别因为名字专业就随便给权限
谁该用、谁别碰
适合你，如果你：
- 已经在用 Codex、Claude Code 或 Cursor，想建立稳定的角色模板
- 需要在多个 AI 工具间复用规则
- 想为代码审查、安全、测试和文档补上结构化的检查清单
不合适，如果你：
- 期待装上就自动组成一家「AI 公司」
- 项目已有成熟且定制化的 Agent/Skill 体系
- 不想读英文提示词，也不打算根据实际项目调整规则
看法
Agency Agents 的成功不在于发明了新协议或新模型——它只是把大量职业角色整理成了统一、可转换、可安装的开放目录。
这个方向真有用。对个人开发者，它能迅速补齐角色意识和交付清单；对团队，它可以做内部 Agent 规范的起点。但我建议你把「254 个 Agent」念成「254 份角色说明书」——不要神化它。
先挑 Product Manager、Frontend Developer、Backend Architect、Security Engineer、Reality Checker 五个角色，装到一个测试项目，跑通一次真实小功能。跑完之后，你自己会知道要不要加、加哪些。
评论(0)