AI Agent ·

Agency Agents 是什么？开源 AI 专家团队框架完整指南

发布于 2026.08.13 约 8 分钟阅读

本文从个人开发者、产品小组、研发团队和企业治理四种场景拆解 Agency Agents。核心判断是：它适合提供角色配置与工作方法，但不等于完整的多 Agent 运行平台，正式使用前仍需补齐编排、权限、隔离、日志和人工审批。

截至 2026 年 8 月 13 日，Agency Agents 官方仓库 README 已列出 230+ 个角色化 Agent，覆盖工程、设计、产品、营销、测试和支持等方向。官方角色目录与统计

✅ 适合： 想快速给 Claude Code、Cursor 增加规划、开发、设计或审查角色的人。

❌ 不适合： 期待安装后自动获得任务调度、权限管理、沙箱和企业审计能力的团队。

结论：Agency Agents 开源框架本质上是角色化 Agent 配置集合，不是完整的多 Agent 运行平台。

这篇文章适合三类读者：需要快速创建开发、设计、测试或营销 Agent 的个人开发者；正在评估角色化 AI Agent 团队的产品与研发小组；准备把 Agent 任务放到长期在线环境运行的自动化负责人。

最后更新于 2026 年 8 月 13 日，本文已核对官方角色目录、安装脚本、支持工具与许可证信息。

Agency Agents 到底提供了什么？

Agency Agents 的核心单位不是一个新模型，而是一组可以被编码代理读取的角色文件。官方仓库将每个 Agent 拆成身份与性格、核心任务、工作流程、交付物、成功标准和沟通方式等部分。官方 Agent 设计说明

因此，某个“前端开发 Agent”并不会凭空拥有独立模型、独立账号或独立执行集群。它更像一份结构化的工作说明书，用来约束当前使用的模型如何思考、如何交付、哪些问题需要检查。

这一区分很重要：

角色配置集合： 提供人格、专业边界、流程和输出格式。
编码代理工具： 负责读取代码、修改文件、运行命令或调用工具。
运行平台： 负责排队、调度、并发、权限、日志、重试和资源隔离。
企业治理层： 负责身份、密钥、审批、数据留存和审计。

Agency Agents 主要解决第一层，并通过安装脚本适配第二层。它不会自动替代第三层和第四层。

从采用价值看，我们给它的评分是：

角色定义清晰度：8.5 / 10
多工具适配能力：8 / 10
上手速度：8 / 10
原生任务编排能力：3 / 10
企业权限与审计能力：2 / 10

这个评分不是说项目质量低，而是提醒我们不要把“角色很多”误解成“平台能力完整”。

工具适配范围与安装方式

官方仓库当前说明，Agency Agents 原生支持 Claude Code，并提供转换与安装脚本适配 Cursor、GitHub Copilot、Gemini CLI、OpenCode、Aider、Windsurf、Codex 等工具。官方多工具集成说明

对用户来说，差别主要在文件格式和作用范围：

Claude Code： Agent 文件复制到 ~/.claude/agents/。
Cursor： Agent 转换为项目目录下 .cursor/rules/ 中的 .mdc 规则文件。
其他工具： 根据工具要求转换成 Agent、Skill、规则或配置文件。

Cursor 官方文档说明，项目规则通常放在 .cursor/rules 中，并可以按文件路径或使用方式加载；AGENTS.md 则是更简单的项目级指令文件。Cursor Rules 官方文档

所以，Agency Agents 能接入多种 AI 编码助手，但这种“支持”主要指角色内容可以转换为对应工具能够读取的文件。它并不意味着 Agency Agents 在这些工具中拥有统一的后台调度系统。

安装时建议先克隆官方仓库，再只安装目标工具和必要角色：

bash

git clone https://github.com/msitarzewski/agency-agents.git
cd agency-agents

./scripts/convert.sh
./scripts/install.sh --tool claude-code

如果使用 Cursor，可以从项目根目录执行：

bash

./scripts/install.sh --tool cursor

官方脚本支持按工具或角色筛选。我们不建议一次性安装完整角色集合，否则提示词、规则和上下文容易互相覆盖。生产环境也不要直接依赖未经审查的最新主分支，最好固定提交版本，检查变更内容，再纳入团队仓库。

个人开发者的最小角色组合

个人项目最容易踩的坑，是一次安装全部角色。角色越多，提示词、规则和上下文越容易互相覆盖，最终表现为“每个 Agent 都能说一点，但没人真正负责”。

我们更建议采用一个最小闭环：

规划角色： 把需求拆成目标、约束、文件范围和验收条件。
执行角色： 修改代码、补充测试或生成文档。
审查角色： 检查功能、回归风险、安全问题和交付完整性。

例如开发一个小型 Web 功能时，规划角色先输出任务说明，执行角色只按照说明修改指定目录，审查角色最后检查差异和测试结果。

个人项目的判断标准不是“安装多少 Agent”，而是每个角色是否有清晰的输入和输出。一个角色至少应明确：

输入是什么文件、需求或决策。
输出是什么格式的文档、补丁或检查结果。
哪些情况必须停止并请求人工确认。
失败后如何重试，重试时不能重复破坏已有修改。

如果只是想验证 Agency Agents 是否适合自己的工作流，三个角色通常已经足够。先验证交付闭环，再考虑增加数据库、部署、性能或安全角色。

产品与内容小组的角色编排

产品或内容小组可以把角色分成四段：

需求研究： 收集用户问题、竞品信息和约束。
方案设计： 形成产品方案、信息架构或内容大纲。
内容生产： 输出页面、文档、脚本或营销素材。
质量检查： 检查事实、品牌、格式、SEO 和发布风险。

关键不是角色名称，而是输入输出契约。需求研究角色不能只给下一位 Agent 一段长文本，而应输出目标用户、已确认事实、未确认假设和待验证问题。方案角色则应引用这些字段，并明确哪些决定已经冻结。

如果没有契约，不同人格只会重复生成相似内容。产品经理 Agent 写一份方案，内容 Agent 再改写一遍，审查 Agent 继续提出泛泛建议，团队却没有新增可执行信息。

一个简单的交付契约可以要求每个角色输出以下内容：

本轮任务目标。
已使用的输入资料。
已确认事实与待验证假设。
具体交付物及文件位置。
未完成事项与阻塞原因。
下一位角色可以直接执行的动作。

这样做的价值是让 AI Agent 团队围绕交付物协作，而不是围绕“人格设定”互相聊天。

研发团队的并行与串行边界

多个专家 Agent 是否应该并行，不能只看任务数量，而要看任务之间是否共享状态。

适合并行的任务包括：

一个 Agent 阅读现有代码并输出架构说明。
一个 Agent 编写独立模块的测试。
一个 Agent 进行文档和接口示例检查。
一个 Agent 对既有变更做安全审查。

不适合直接并行的任务包括：

多个 Agent 同时修改同一个核心文件。
一个 Agent 正在改变数据库结构，另一个 Agent 同时生成迁移脚本。
规划尚未冻结，执行 Agent 已经开始大范围重构。
测试 Agent 依赖的接口还没有稳定。

涉及同一代码文件时，应使用分支或 Git worktree 隔离，再通过统一的合并门禁进入主分支。Git worktree 官方文档

一个稳妥的研发流程是：

规划角色只读代码，输出任务拆解和文件范围。
执行角色在独立分支中修改代码。
测试角色在同一分支或只读副本中运行测试。
安全角色检查依赖、权限、命令和敏感信息。
人工或主审查角色确认差异、测试和回滚方式。
通过门禁后才合并到主分支。

这里的“并行”主要发生在互不冲突的分析、测试和审查阶段，而不是让多个 Agent 无边界地同时写同一份代码。

企业落地的治理边界

Agency Agents 可以用于企业项目的试验阶段，但不能把它单独当作企业级运行方案。

企业使用时至少有五个现实限制：

权限边界不由角色文件自动提供。

一个名为“安全审查”的 Agent，不等于它只能读取安全相关目录。实际权限仍由 Claude Code、Cursor、操作系统、密钥配置和运行环境决定。

角色文件不等于身份系统。

企业需要知道是哪位员工、哪个项目、哪个 Agent、通过哪个凭证执行了什么操作。仅依赖对话记录，无法满足完整审计。

密钥可能进入上下文。

API 密钥、环境变量、配置文件和日志都可能被 Agent 读取。应采用最小权限、临时凭证、脱敏日志和独立项目账号。

数据留存规则需要单独设计。

代码、客户资料、内部文档和 Agent 输出是否允许保存，保存多久，谁能读取，都不是角色 Markdown 文件能够决定的。

失败重试可能放大风险。

如果 Agent 有写文件、执行命令或调用外部 API 的能力，自动重试可能重复提交、重复迁移或覆盖正确结果。

OWASP 的 AI Agent 安全指南把工具滥用、权限控制、敏感数据保护和安全日志列为重要治理问题。OWASP AI Agent 安全清单

因此，企业至少要在 Agency Agents 之外补齐：

独立运行账号与最小权限。
代码仓库、密钥和生产系统的分层隔离。
每次工具调用的日志与任务编号。
高风险命令的人工审批。
可删除、可重置、可回滚的临时环境。
失败重试上限和人工接管机制。

⚠️ 经验提醒： 角色文件写得越像“高级专家”，越不能把它当作权限证明。身份、授权和沙箱必须由外部系统强制执行，而不能依赖 Agent 自觉遵守。

远程运行环境的判断标准

小规模试验可以在本地完成。尤其是个人项目，只运行一个规划 Agent、一个执行 Agent 和一个审查 Agent 时，本地环境更容易观察文件变化，也方便人工确认命令。

当出现以下情况，就应考虑可重复的远程环境：

需要长期在线接收任务。
多个任务持续并发运行。
每个任务都需要独立依赖和工作目录。
本地电脑经常休眠、断网或切换项目。
团队成员需要复现同一套安装结果。
任务运行时间已经超过人工能够持续盯守的范围。

扩容依据不应是“角色总数量”，而应看三个指标：

同时运行的任务数。
单个任务的依赖安装和磁盘需求。
任务持续时间与失败重试次数。

如果只是安装了很多角色，但每次只调用一个 Agent，增加机器数量没有意义。相反，即使只有三个角色，只要规划、执行和测试需要长期并行，也可能需要隔离的远程环境。

对于希望把 Claude Code 或其他编码 Agent 放到远程 Mac 上运行的团队，可以先阅读 Mac 远程运行环境帮助，再根据是否需要持久工作区、图形界面和多人访问做选择。若任务需要 macOS 工具链，也可以对比 Mac mini 美国东部租用方案与本地设备的差异。

从试用到正式采用的验收清单

正式安装全部角色之前，我们建议拿一个真实项目做小规模验证。先选一个规划角色、一个执行角色和一个审查角色，连续跑完一个完整交付闭环。

[ ] 规划角色能否把需求拆成明确任务，而不是只生成长篇说明？
[ ] 执行角色是否严格限制在约定文件和目录范围内？
[ ] 审查角色是否能发现真实缺陷，而不是重复描述需求？
[ ] 三个角色的输出是否互补，是否存在大量重复内容？
[ ] 每个输出是否包含文件列表、命令、测试结果或待确认事项？
[ ] 执行失败后能否从上一个稳定状态重试？
[ ] 重试是否会重复写入、重复提交或覆盖已有修改？
[ ] 不同任务之间是否可能泄漏上下文、密钥或客户数据？
[ ] 人工评审是否有明确标准，而不是只看 Agent 的自我评价？
[ ] 是否能够保存任务编号、变更差异、测试记录和审批结果？
[ ] 是否能在不影响生产代码的临时环境中回滚？
[ ] 当任务持续运行时，是否有稳定的远程环境和断线恢复机制？

如果其中三项以上无法回答，说明团队现在缺的不是更多角色，而是工作流和治理基础。

Agency Agents 的许可证也应在引入前核对。当前官方仓库 README 标注为 MIT License，但企业仍应结合自身合规要求检查依赖、贡献代码和内部修改方式。官方许可证说明

我们建议怎样开始采用？

个人开发者可以从一个真实需求开始，不要先建立“完整 AI Agent 团队”。先让规划角色产出任务契约，再让执行角色完成一个小范围变更，最后由审查角色给出可验证的结论。

产品和内容小组应优先固定交付格式，例如需求研究必须包含事实、假设和待验证项；内容生产必须包含引用、目标读者和发布检查；审查角色必须指出阻塞问题和修改建议。

研发团队则应先建立分支、worktree、测试和合并门禁，再增加并行 Agent。关于多个 Agent 如何拆分任务，可以继续参考多个 AI Agent 并行开发工作流，重点观察任务依赖和文件冲突，而不是追求同时启动更多终端。

对企业来说，Agency Agents 更适合做角色标准化和流程试验。它能帮助团队快速把“谁负责规划、谁负责实现、谁负责审查”写清楚，但权限、密钥、日志、数据留存、人工审批和沙箱仍需要独立建设。

如果当前方案只是把所有角色复制到一台个人电脑上，常见缺点是环境不可复现、任务无法长期在线、多人协作缺少隔离，而且 Agent 一旦拥有过大的本地权限，失败后的影响范围也会扩大。需要让角色长期运行或并行处理任务时，使用 ZekVPS 的远程 Mac 环境会更容易保持工作区、依赖和访问方式稳定；但如果只是偶尔运行一次小任务，继续使用本地设备通常更划算。

更稳妥的路径是：先选一个规划角色、一个执行角色和一个审查角色，用真实项目完成一次验收；确认输出互补、失败可重试、权限可控制后，再根据并行数、运行时长和隔离要求决定是否迁移到远程环境。