最近我看了一个很有意思的 GitHub 项目：msitarzewski/agency-agents。它的名字叫 agency-agents，直译有点像“代理公司里的代理人”，但更准确的理解应该是：一套把 AI 助手拆分成不同岗位专家的角色库。
很多人用 AI 写代码、写文案、做方案时，习惯把所有事情都丢给同一个助手。但真实工作不是这样运转的。一个产品从想法到上线，中间会经过产品、设计、前端、后端、测试、运维、市场、客服、财务、合规等多个角色。agency-agents 做的事，就是把这些角色变成可复用的 AI Agent 提示词和工作流程。
一句话概括：它不是一个自动执行任务的平台，而是一套可安装到不同 AI 工具里的“虚拟专家团队模板”。
agency-agents 是什么？
从仓库结构看，agency-agents 本质上是一组 Markdown 文件。每个文件代表一个 Agent，里面包含这个 Agent 的身份、职责、工作流程、沟通方式、交付物、成功指标等内容。
比如它有前端开发、后端架构、DevOps、UI 设计、UX 研究、增长黑客、SEO 专家、测试分析、客服响应、财务分析等角色。每个角色不是简单一句“你是某某专家”，而是写了比较完整的工作方式和输出要求。
我本地查看当前仓库时，除去示例和集成文档，核心 Agent 文件大约有 184 个，分布在工程、设计、营销、产品、项目管理、测试、支持、金融、游戏开发、空间计算、学术、专业服务等多个分类里。它更像是一个“AI 组织架构库”。
它解决了什么问题？
普通提示词最大的问题是太散。今天你让 AI 做前端，它可能只关注页面；明天让它做安全检查，它又可能忽略业务目标。agency-agents 试图解决三个问题。
第一，角色边界。 不同 Agent 有不同职责。前端开发关注界面实现、性能和可访问性；Reality Checker 关注证据和验收；Project Shepherd 关注排期、依赖和风险。这比让一个通用助手什么都做更清晰。
第二，交付标准。 很多 Agent 文件里会写明它应该交付什么，比如代码、测试、架构图、审计报告、市场方案、复盘模板等。这会迫使 AI 不只聊天，而是输出可检查的结果。
第三，协作流程。 项目里还有一个叫 NEXUS 的策略层，用来把多个 Agent 组织成流程。它强调阶段、交接、质量门、证据验证和失败重试，目标是避免多 Agent 协作时各说各话。
它不是传统意义上的自动化框架
这一点很重要。agency-agents 不是 AutoGPT 那类自动执行系统，也不是一个带数据库、队列、浏览器自动化和工具调用的完整平台。它不会自己跑任务，也不会自动帮你部署项目。
它更像一套“岗位说明书 + SOP + 工作模板”。你把这些角色安装进 Claude Code、Gemini CLI、Cursor、OpenCode、Aider、Windsurf、Kimi Code、Qwen Code 等工具后，再在具体会话里调用某个角色，让它按预设方式工作。
这种设计的好处是轻量，坏处也很明显：真正的执行能力取决于你使用的 AI 工具本身。工具能读文件、改代码、跑测试，它就能做更多；工具只能聊天，它就更多是一个提示词模板。
项目结构大概长什么样？
仓库大致可以分成几层：
- Agent 角色目录：如
engineering/、design/、marketing/、testing/、support/等，每个目录下都是具体 Agent。 - strategy 目录：提供 NEXUS 协作方法，包括 Full、Sprint、Micro 等不同模式。
- integrations 目录：提供不同 AI 工具的适配格式。
- scripts 目录：提供
convert.sh和install.sh，用于转换格式和安装到本地工具。 - examples 目录：展示多个 Agent 一起参与项目时可能产生的结果。
这种结构说明作者并不只是收集提示词，而是在尝试把提示词产品化、工具化、流程化。
怎么安装和使用？
如果你用的是 Claude Code，项目本身就比较贴近它的 Agent 格式，可以直接安装：
git clone https://github.com/msitarzewski/agency-agents.git
cd agency-agents
./scripts/install.sh --tool claude-code如果你只想安装某一类角色，也可以手动复制：
cp engineering/*.md ~/.claude/agents/如果你使用其他工具，可以先转换再安装：
./scripts/convert.sh
./scripts/install.sh也可以指定工具：
./scripts/install.sh --tool gemini-cli
./scripts/install.sh --tool cursor
./scripts/install.sh --tool opencode
./scripts/install.sh --tool aider
./scripts/install.sh --tool windsurf安装完成后，用法通常不是“运行 agency-agents”，而是在 AI 工具里调用某个角色。例如：
Activate Frontend Developer and help me build this React component.
Use Reality Checker to verify whether this feature is production-ready.
Activate Agents Orchestrator in NEXUS-Sprint mode for this MVP.也就是说，它改变的是你和 AI 协作时的组织方式，而不是替你提供一个新的命令行运行时。
典型应用场景
1. 独立开发者做产品
一个人做产品时，最大的问题不是不会写代码，而是经常缺少多角色视角。你可能写完功能却忘了可访问性，做完页面却没有增长方案，准备上线却没做测试清单。agency-agents 可以让你快速切换到不同专家视角，补齐盲区。
2. 小团队做 MVP
NEXUS-Sprint 这类流程适合小团队把一个功能或 MVP 拆成产品、设计、工程、测试、上线几个阶段。即使团队只有两三个人，也可以让 AI 扮演 PM、QA、架构师、增长顾问，帮忙梳理计划和风险。
3. 代码库审查和上线前验收
项目里有 Code Reviewer、Security Engineer、Reality Checker、API Tester、Performance Benchmarker 等角色。它们适合在上线前做一轮审查：代码有没有明显风险，接口有没有验证，性能有没有证据，是否只是“看起来能跑”。
4. 内容和增长工作流
营销目录里有 SEO、Baidu SEO、小红书、知乎、微博、短视频、播客、跨境电商等角色。对内容型网站、独立产品、出海项目来说，这些 Agent 可以提供选题、渠道策略、内容结构和发布检查清单。
5. 企业内部知识工作 SOP
企业里很多工作本质上是可标准化的：客服回复、财务跟踪、合规审查、报告生成、销售提案、项目复盘。agency-agents 提供了一种思路：把岗位经验写成 Agent 模板，再让 AI 按模板执行。
可能产生的影响
第一，提示词会从“单条技巧”走向“组织资产”。 过去很多提示词只是个人收藏，复制粘贴就完了。但像 agency-agents 这样的项目，把角色、流程、交付标准和工具适配都放进仓库，提示词开始变得像代码一样可以版本管理、审查和协作。
第二，AI 工具会越来越像一个可扩展团队。 以前我们说 AI 助手，默认是一个通用助手。现在更像是你有一个工具箱，里面有 PM、设计、开发、测试、运营、法务等虚拟角色。真正的价值不只是单个回答更好，而是任务可以被更合理地拆分。
第三，个人生产力会继续被放大。 一个会调用 Agent 的独立开发者，可能比以前更容易完成完整产品闭环：从调研、设计、开发、测试、上线到推广。它不等于一个人能替代整个公司，但会显著提高个人完成复杂任务的上限。
第四，也会带来新的质量风险。 角色越多，不代表结果越可靠。如果没有证据、测试、人工判断，多 Agent 只会让错误变得更有条理。项目里强调 Reality Checker 和质量门是对的，因为 AI 最容易犯的错就是把“说得像真的”包装成“已经验证过”。
第五，团队管理方式会变化。 未来团队可能不只是管理人，还要管理 Agent：谁能改代码，谁能审查，谁负责合规，哪些输出必须有证据，哪些建议必须经过人类确认。这会让“AI 工作流治理”变成新的管理能力。
我怎么看这个项目？
我觉得 agency-agents 最有价值的地方，不是它有多少个 Agent，而是它把“AI 协作”从聊天框里拽回了工程化思路：角色定义、流程拆分、交接模板、质量门、工具适配、版本管理。
它的不足也很明显。首先，它仍然主要是提示词资产，不是完整运行时；其次，不同 Agent 的质量会有差异，需要根据自己的业务重写；第三，如果直接全量安装，很容易信息过载。真正好的用法不是一口气使用 184 个角色，而是从 5 到 10 个最常用角色开始，逐步沉淀自己的版本。
对技术人来说，我更建议把它当成一个参考库：学习它如何定义角色、如何写交付标准、如何设计多 Agent 交接，再把其中适合自己的部分改造成个人或团队的工作流。
适合谁使用？
- 经常使用 Claude Code、Cursor、Gemini CLI、OpenCode、Aider 等 AI 编程工具的人。
- 独立开发者、站长、小团队，需要一个低成本的虚拟协作团队。
- 想把提示词系统化、版本化、团队共享的人。
- 正在研究 AI Agent 工作流、工具链集成、多 Agent 协作的人。
- 需要给企业内部岗位沉淀 AI SOP 的团队。
不适合谁？
- 只想要一个开箱即用 SaaS 平台的人。
- 不愿意阅读和改造提示词，只想一键自动完成所有工作的人。
- 没有验证流程，却希望 AI 自动替自己做关键决策的人。
- 对数据隐私、代码权限、业务边界没有控制意识的团队。
结语
agency-agents 代表了一种很明确的趋势：AI 不再只是“一个更聪明的聊天框”，而会逐渐变成一套可组织、可分工、可复用的工作系统。
它不会直接替你创业，也不会自动替你把项目做完，但它提供了一套很好的脚手架，让你用更接近真实团队协作的方式使用 AI。对于个人开发者来说，这可能就是从“我有一个 AI 助手”升级到“我有一支虚拟工作队”的开始。