Agency Agents：把一个 AI 编程助手，变成一支“虚拟专家团队”

当我们使用 Claude Code、Codex 或 Cursor 编写代码时，经常会遇到一个问题：同一个 AI 既要理解需求，又要设计架构、实现功能、检查安全问题，最后还要负责测试。

结果往往是每个环节都做了一点，却没有一个环节足够深入。

开源项目 Agency Agents 提供了另一种思路：不要让一个通用 AI 扮演所有角色，而是为不同任务准备不同的专业 Agent。

需要开发页面时调用前端工程师，需要设计接口时切换后端架构师，代码完成后再交给代码审查和测试 Agent。整个过程更像是在组织一支虚拟软件团队。

它并不是新的 AI 模型

Agency Agents 不是大模型，也不是一个独立的 AI 编程工具。

它的核心是一套专业 Agent 配置库。项目把不同岗位需要具备的职责、工作流程、专业规则和交付标准整理成结构化提示词，再将其安装到 Claude Code、Codex、Cursor 等 AI 工具中。

简单来说，普通提示词可能只是：

你是一名资深前端工程师，请帮我开发这个页面。

而 Agency Agents 中的前端开发 Agent 会进一步规定：

• 应该关注哪些技术领域
• 开发时遵循什么流程
• 必须满足哪些性能指标
• 如何处理无障碍和响应式设计
• 应该进行哪些测试
• 最终交付内容采用什么结构
• 应该如何向用户说明实现结果

它更像一份“岗位说明书、工作流程和质量检查表”的组合，而不只是一句话的人设提示。

230 多位不同领域的 AI 专家

项目按照真实团队的组织方式，将 Agent 分成多个部门。

工程部门包含前端开发、后端架构、移动端、DevOps、数据库优化、RAG、AI 工程、代码审查等角色。

测试部门负责功能验证、API 测试、性能测试、无障碍测试和最终质量检查。

除此之外，它还提供了产品、设计、安全、营销、销售、项目管理、客户支持等大量非研发角色。

其中一些角色非常细分，例如：

• Frontend Developer：负责 React、Vue、Angular、性能与无障碍
• Backend Architect：负责 API、数据库和服务端架构
• RAG Pipeline Engineer：负责切片、检索、重排与效果评估
• Code Reviewer：检查安全性、可维护性和代码质量
• Database Optimizer：分析索引、慢查询和数据库迁移
• Reality Checker：在交付前寻找遗漏和潜在问题
• Minimal Change Engineer：只完成必要修改，避免扩大需求范围
• Agents Orchestrator：负责协调多个 Agent 完成复杂项目

从这个角度看，Agency Agents 并不是在追求一个“无所不能的超级 Agent”，而是在尝试进行 AI 能力的专业化分工。

一个 Agent 文件里有什么

以项目中的 Frontend Developer Agent 为例，它主要包含以下内容：

身份与专业定位

Agent 会被明确设定为现代 Web 应用和 UI 实现专家，强调性能、细节、用户体验与技术准确性。

核心任务

它需要负责组件开发、设计系统、接口集成、状态管理、性能优化、PWA、跨浏览器兼容等工作。

强制规则

例如默认采用移动端优先设计、关注 Core Web Vitals、遵循 WCAG 无障碍标准、提供键盘操作和屏幕阅读器支持。

标准工作流程

它会按照项目初始化、组件开发、性能优化、测试和质量保证等阶段推进任务。

交付物模板

最终回答不仅要给出代码，还需要说明技术选型、组件结构、性能策略、缓存方案和无障碍实现。

这种设计能够让 AI 在处理任务时保持相对稳定的关注重点，减少“写完功能就结束”的情况。

从单个专家到多 Agent 协作

除了单独使用某个角色，Agency Agents 还提供了一个 Agents Orchestrator。

它尝试按照软件团队的协作方式组织完整流程：

需求分析
   ↓
产品经理拆分任务
   ↓
架构师设计技术方案
   ↓
开发 Agent 实现
   ↓
测试 Agent 验证
   ↓
失败则返回开发阶段修改
   ↓
最终集成测试

编排器要求每项任务必须经过质量检查。测试不通过时，任务会携带反馈重新交给开发 Agent；连续失败后，再进入升级处理。

仓库的示例目录展示了 Landing Page、创业 MVP、产品研究等多 Agent 工作流。

不过，这里需要区分“Agent 定义”和“Agent 运行能力”。

Agency Agents 主要提供角色与流程说明。真正的并行执行、上下文传递、子 Agent 调度和权限管理，仍然取决于 Claude Code、Codex 等宿主工具是否支持相应能力。

换句话说，它提供的是专家团队的“岗位配置”，不是负责运行整个团队的底层模型平台。

可以用在哪些 AI 编程工具中

项目提供了转换和安装脚本，可以把同一套 Agent 配置适配到不同工具，包括：

• Claude Code
• Codex
• Cursor
• GitHub Copilot
• Gemini CLI
• Qwen Code
• Kimi Code
• OpenCode
• Aider
• Windsurf
• OpenClaw

不同工具使用的配置格式并不相同。

例如 Cursor 使用 .mdc 规则文件，Codex 使用自定义 Agent TOML，Kimi Code 使用 YAML，而 Aider 会把多个角色合并进 CONVENTIONS.md。

项目中的转换脚本负责处理这些格式差异。

以 Codex 为例，基本使用方式是：

./scripts/convert.sh --tool codex
./scripts/install.sh --tool codex

转换完成后，相应配置会被安装到：

~/.codex/agents/

随后便可以在任务中指定某个角色：

使用 Frontend Developer Agent 实现这个页面。

或者：

使用 Code Reviewer Agent 审查刚才的修改。

不建议一次安装全部 Agent

230 多个角色看起来很有吸引力，但实际使用时，角色并不是越多越好。

大量 Agent 之间难免存在职责重叠。例如高级开发、软件架构师、后端架构师和代码审查员可能会针对同一个问题给出不同甚至相互冲突的建议。

如果工具把大量规则同时注入上下文，还可能带来：

• Token 消耗增加
• 任务执行速度下降
• 指令相互冲突
• AI 过度设计
• 输出大量不必要文档
• 简单任务被复杂化

对于程序员，更合适的做法是先选择一个最小团队：

Frontend Developer
Backend Architect
Code Reviewer
Security Engineer
Reality Checker

日常开发可以采用一条简单工作流：

开发 Agent 实现
        ↓
Code Reviewer 审查
        ↓
Reality Checker 验证

只有在项目足够复杂时，再加入产品经理、架构师和编排器。

它真正有价值的地方

Agency Agents 最值得关注的，不一定是其中某个具体角色，而是它展示了一种设计 AI 工作流的方法。

一个可靠的 Agent 不应该只有人设，还应该明确：

1. 它负责什么
2. 它不负责什么
3. 它必须遵守哪些规则
4. 它按照什么流程工作
5. 它需要交付什么
6. 如何判断任务是否完成
7. 失败以后应该如何处理

这套结构非常适合用来学习如何编写自己的 Agent、Skill 或项目级 AI 规范。

相比直接照搬全部角色，更推荐从仓库中挑选结构较好的 Agent，再结合自己的技术栈进行修改。例如加入团队自己的：

• TypeScript 规范
• Vue 或 React 组件约定
• Git 提交规则
• API 错误处理方式
• 测试覆盖要求
• 数据库迁移流程
• 安全检查清单
• 部署和回滚策略

这样得到的 Agent，通常会比通用角色更符合真实项目。

中文用户也有社区版本

项目 README 中还收录了社区维护的中文版本：agency-agents-zh。

中文版本在翻译上游角色的基础上，增加了一些中国市场相关岗位，例如：

• 小红书运营
• 微信公众号运营
• 抖音与 B 站内容策略
• 飞书、钉钉集成
• 国内电商和政务场景

不过，中文版本属于独立维护的社区分支，与英文上游的更新速度和角色数量可能不完全一致。正式使用前，最好确认目标 Agent 是否同步了最新修改。

总结

Agency Agents 可以看作一座开源的“AI 岗位说明书仓库”。

它没有创造新的模型能力，却通过角色分工、工作流程、质量标准和交付模板，让通用 AI 更容易表现出稳定的专业倾向。

对于普通使用者，它可以提供一批即插即用的专家角色；对于开发者，它更适合作为设计 Agent 和多智能体工作流的参考资料。

最合理的使用方式不是召集 230 多位 AI 专家同时开会，而是根据任务选择三到五个合适角色，组成一支职责清楚、流程简单、结果可以验证的小团队。