将 300 多个 AI 专家安装到 Claude Code 和 Cursor

速览：agency-agents 是 GitHub 上最大的精选 AI Agent 人格集合，截至 2026 年 9 月 1 日拥有 149,312 个 Star。它在约 20 个分类目录中提供 300 多个 Agent 定义文件，并通过一条命令将它们安装到 Claude Code、Cursor、Codex、Gemini CLI、OpenCode、Windsurf、Aider 和其他十多个工具中。你获得的是任务框架，而不是新能力。这些人格会改变 Agent 处理任务的方式，但不会补充模型原本不知道的事实，也不会跨会话持续存在。

本文深入介绍我们在 2026 年值得安装的五个开源 AI Agent 工具清单中的一个工具。

你的编码 Agent 通常只有一种人格：乐于助人的通用助手。让它审查认证流程，你得到的往往是合理但容易忘记的建议；让一个带有威胁模型和检查清单的安全审查员来做，你才会得到具体发现。

agency-agents 正是用来填补这个差距的。它最初源于 Reddit 上关于 Agent 专业化的一篇讨论，后来发展成一个庞大的角色目录，甚至因为数量太多而会让至少一种主流 Agent 运行时无法完整加载。下面介绍其中实际包含的内容、如何只安装需要的部分，以及人格库无法替你解决的两个问题。

AI Coding 交流群

如果你也在用 AI 写代码，或者正在研究 Cursor、Claude Code 这些工具，欢迎加入以下交流群。群里平时会聊一些 AI 编程的实际用法、开发工作流，还有各种新工具和新玩法。

你实际安装的是什么

每个 Agent 都是一个 Markdown 文件，不是一行 system prompt，也不是带代码的插件。文件包含身份和性格、核心任务、工作流程、带示例的技术交付物，以及成功指标。

截至 2026 年 9 月 1 日，按仓库目录中的 Markdown 文件统计，共有 20 个顶层分类目录和 312 个文件；排除 examples/ 目录后还有 306 个。分布明显偏向构建软件：

需要注意的是，仓库 README 仍然写着“230+ agents”，这句话已经过时，目录中的文件数量早已超过 300。

大多数开发者会从 engineering 分类开始，而其中的专业程度比一个提示词集合更高。除了常见的 Frontend Developer 和 Backend Architect，还有针对 Cisco IOS-XE、Juniper Junos 与 Palo Alto PAN-OS 的 Network Engineer，面向 ESP32、STM32 和 Nordic 平台的 Embedded Firmware Engineer，负责复盘和 on-call 准备的 Incident Response Commander，以及只读探索仓库、陈述事实而不是提出修改的 Codebase Onboarding Engineer。

最后一个角色很好地说明了这种模式的价值。带有明确禁止编辑要求的只读人格，确实是与默认 Agent 不同的工具，而成本只是一份文件。

安装时不要破坏现有配置

仓库提供转换和安装脚本。交互式流程会检测你已经安装的工具，并询问你想安装什么：

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

更合理的默认方式是指定目标工具和需要的分类：

# everything, into Claude Code
./scripts/install.sh --tool claude-code

# two divisions only
./scripts/install.sh --tool claude-code --division engineering,security

# named agents only
./scripts/install.sh --tool cursor --agent frontend-developer,ui-designer

# see what exists before committing
./scripts/install.sh --list teams
./scripts/install.sh --tool opencode --division engineering --dry-run

支持的目标包括 Claude Code、Cursor、Codex、Gemini CLI、OpenCode、GitHub Copilot、Windsurf、Aider、Kimi Code、Hermes、Antigravity、Osaurus 和 Mistral Vibe。macOS、Linux 与 Windows 还提供原生桌面应用 agencyagents.app，可以浏览角色、点击安装并自动更新，同时支持 Homebrew cask。

在安装全部内容前先读这一点。OpenCode 运行时目前只注册约 119 个 Agent，剩余内容会被静默丢弃，这是仓库针对上游 bug 的记录。使用 --division 安装子集可以避开上限，安装器在选择超限时也会发出警告。静默截断是最糟糕的失败模式：你想用的 Agent 不见了，却没有任何提示。

即使没有这个具体 bug，安装 300 个人格也不是好主意。无法记住的角色目录就不会被使用。安装你实际工作的两个分类，完整读几份文件，然后删掉不符合团队工作方式的内容。

人格会改变什么，又不会改变什么

人格是一种框架：它规定 Agent 关注什么、输出什么格式，以及怎样才算完成。这比听上去更有价值，因为糟糕的 Agent 输出往往不是模型答错，而是模型在优化错误的答案形状。

人格无法提供模型原本没有的信息。这是使用一周后最容易发现的限制，在 API 场景中尤其明显。

加载 Backend Architect，让它为你的内部计费服务编写客户端。它会针对自己臆测的响应结构，生成整洁且符合习惯的代码。它不可能知道你的服务在幂等键重复时返回带有不同错误封装的 409，也不知道分页游标是不透明游标而不是 offset。人格让代码组织得更好，却没有让代码变正确。

testing 分类也有同样的限制。QA 人格会根据自己的 API 心智模型编写全面测试，于是测试通过，却什么也证明不了。关于测试非确定性 AI Agent 的具体风险，以及真实结构变化时会发生什么，原文已有专门讨论。

解决办法是把契约交给 Agent，而不是希望人格弥补信息缺口。如果你的 API 在 Apifox 中设计，OpenAPI 规范就是事实来源：真实的数据模型、状态码和错误封装。Agent 读取这些内容，而不是从调用点反推。mock 也从同一份规范生成，包括人格永远不会主动伪造的错误分支；当现实与规范不一致时，测试套件会在 CI 中明确失败。

有用的心智模型是把两者配对起来：人格决定 Agent 如何工作，规范决定什么才是真的。若要将实时规范接入 Agent 的上下文，可以使用 Apifox，并指向已有项目。

第二个限制：人格不是团队

角色目录的比喻承诺了一个完整团队，但它并不能真正交付团队。

宣传看起来像是把一整家 agency 放在手边。实际情况是：你在一个会话中激活一个人格，完成一个任务，然后会话结束。第二天还要重新输入激活方式。这里没有分配，没有记录安全审查员上周二发现了什么，也没有同事可以查看结果，因为没有任何持久化机制。仓库里有九个分类只有在组织中才有意义，而安装它们的工具却完全没有组织概念。

如果你希望角色目录跨越单次终端会话，缺失的层就是工作管理。HiFox 正是为此设计的，下面将 agency-agents 与它的对应关系说清楚。

• HiFox 中的 Agent 是保存下来的配置，而不是每次重新输入的 prompt。它包含 instructions、runtime、skills、repositories 和 environment。你调好的人格可以重复使用，这正是 ~/.claude/agents/ 中 .md 文件想要实现的持久版本。
• Crew 是 leader Agent 加上其他 Agent 和人员。这让 division 概念拥有了真正的运行机制。Crew 采用 leader-first：leader 读取任务上下文，决定拉入哪些成员，并在一个地方合并结果，而不是每个专家同时启动后各自奔跑。
• 工作是被分配的，而不是被调用的。你像把任务交给队友一样将任务交给 Agent。任务位于 space、project 和 sprint 中，如果团队已经使用 Jira，还可以同步。
• 执行环境由你提供。你连接一个 Computer，可以是笔记本、服务器或容器；HiFox 使用该机器上已经安装的 Runtime。Claude Code 或 Codex 订阅负责执行，平台不会转售 Token。
• 输出可供审阅。进度、工具调用和结果会流回任务，Agent 输出则作为可回复的评论保存。Backlog 中的任务不会启动运行，因此可以在执行前准备工作。

简单说，agency-agents 提供职位描述，HiFox 提供分配、运行和审阅这些职位的地方。应把仓库当作角色定义库，用来创建真正的 Agent，而不是安装后遗忘的一堆文件。

以它们为模板编写自己的 Agent

这个仓库最持久的价值是格式。读过几份文件后，为自己的技术栈编写一个人格大约需要 15 分钟，而且针对团队的版本总是比通用版本更有用。

优秀文件中反复出现的结构包括：

• Identity and voice。规定 Agent 是谁、如何表达。看似只是外观，却能避免 Agent 在长任务中途漂回通用助手模式。
• Core mission。用一句话说明成功意味着什么。Codebase Onboarding Engineer 是很好的例子：只读探索、追踪代码路径、陈述结构和行为事实，不提出方案。
• Working process。Agent 要遵循的有序步骤，这是最值得借鉴的部分。带七步流程的审查人格会跨会话稳定输出，没有流程的版本则取决于模型当天的状态。
• Deliverables。写清楚具体产物和格式。与其写“生成报告”，不如写“输出包含严重程度、文件路径和行号的发现 Markdown 表格”。
• Success metrics。说明 Agent 如何判断自己完成了任务，同时也成为你检查结果的依据。

用于 API 工作的团队版本可以写成这样：

# API Contract Reviewer

## Mission
Verify that new or changed endpoints match the OpenAPI spec in this
repository before they reach review. Report mismatches. Do not edit code.

## Process
1. Read the spec for every endpoint touched by the current diff.
2. For each one, compare the handler against the spec: status codes,
   response schema, error envelope, required headers, pagination style.
3. Run the contract tests. Record failures verbatim.
4. Check that new endpoints were added to the spec, not just to the router.
5. Flag any response field present in code and absent from the spec.

## Deliverables
A table: endpoint, method, mismatch type, spec line, code line, severity.
No prose summary. No suggested fixes unless asked.

## Done when
Every endpoint in the diff appears in the table with a verdict, and the
contract test output is included as evidence.

这个文件很短，却比仓库中提供的 59 个 engineering 人格更适合后端团队，因为它点明了你的规范、测试和完成定义。第三步尤其关键：要求人格产生证据而不是观点，这正是可执行的审查与安慰性段落之间的区别。

incident response、迁移、依赖升级和 onboarding 也可以采用同样方法。保留文件结构和流程纪律，把通用内容替换成自己的内容。当 Agent 输出必须经得起交接给人员或另一个 Agent 时，格式契约承担了大部分工作。

Star 数量有意义吗

149,312 个 Star 确实很多，但需要加一个限定。人格仓库比其他类别更容易快速获得 Star，因为它们容易理解、容易分享，而且尝试成本为零。Star 只能说明有人认为这个想法不错，不代表对方现在仍在使用。

这个仓库可信的原因在于工作形态，而不是数字。它自 2025 年 10 月以来有真实贡献记录，使用 MIT 许可证，主动记录包括 OpenCode 注册上限在内的限制，Agent 文件也包含具体领域内容，而不是泛泛的角色描述。可以把它与那些达到高峰后便停止更新的“awesome prompts”仓库区分开。

判断它的方法是打开你熟悉的一个分类中的三份文件。如果 Frontend Developer 文件写出了优秀前端开发者确实会说的话，其余内容大概率也不错；如果读起来像招聘启事，就跳过这个仓库。

真正从中获得价值

一个更可靠的工作流程是：

1. 安装一个分类。选择与你日常工作匹配的分类，大多数读者可以从 engineering 开始。
2. 阅读文件。从头到尾读四五份，重点观察流程部分，因为那才是最值得保留的内容。
3. 编辑它们。加入你的技术栈、约定和完成定义。描述通用 React 团队的人格，不如包含你们测试规则的同一文件有价值。
4. 给编辑后的人格真实输入。带有 OpenAPI 规范的安全审查员可以发现契约问题；没有规范时，它只能生成一份检查清单。
5. 把真正有用的角色提升为持久 Agent。每周会使用两次的人格，应保存到工作管理系统中的 Agent，而不是在不同机器之间复制文件。

最后一步决定了团队能否规模化使用它，还是悄悄放弃。

FAQ

agency-agents 支持 Cursor 和 Codex，还是只支持 Claude Code？都支持。convert.sh 会为每个工具生成集成文件，install.sh --tool 用于指定目标工具。支持 Claude Code、Cursor、Codex、Gemini CLI、OpenCode、Copilot、Windsurf、Aider、Kimi Code 等。如果你在比较用于 API 工作的 Agent 客户端，需要自行评估各自取舍。

应该安装全部 300 个 Agent 吗？不应该。OpenCode 无法做到，因为运行时只注册约 119 个，其余会静默丢失。其他工具在技术上可能允许，但大部分角色你永远不会用到。按分类安装。

人格会让 Agent 更聪明吗？它会让 Agent 更有方向。事实问题的准确率，包括 API 实际返回什么，不会因此提高。那需要真正的规范，而不是更换人格。

运行安装脚本安全吗？脚本会把 Agent 定义文件写入工具的配置目录，这正是它的用途。仓库采用 MIT 许可证并公开完整源代码，--dry-run 可以在执行前展示将要进行的操作。先运行 dry run。关于允许 Agent 触碰哪些资源，应遵循最小权限原则。

它与 Agent framework 有什么区别？如果你想让多个角色同时运行，而不是每个会话只运行一个人格，那是并行 Agent 工具的职责。像 Strands 或 AgentKit 这样的 framework 在代码中提供运行时编排；agency-agents 提供改变现有 Agent 行为的 Markdown 文件。它们属于不同层次，不是同一类工具。

总结

agency-agents 是一个明确想法的最佳实现：Agent 知道自己扮演什么角色时，工作会更好。安装一个分类，阅读文件，把它们编辑成符合团队方式的版本，大约花 20 分钟就能获得实际价值。

但也要诚实面对它没有解决的两个问题。人格不知道你的 API 返回什么，这需要 Apifox；人格也不会持久化成团队可以查看和审阅的工作记录，这需要 HiFox。角色目录是一个好的起点，却不是组织，也不是事实来源。

开发必备：API 全流程管理神器 Apifox

介绍完上文的内容，我想额外介绍一个对开发者同样重要的效率工具 —— Apifox。作为一个集 API 文档、调试、设计、测试、Mock、自动化测试于一体的工具，Apifox 是目前提升研发效率的首选。

如果你正在开发项目，不妨试试其极其友好的界面设计，它完全兼容 Postman 和 Swagger 数据格式，导入数据非常方便，，即使是新手也能很快上手，点击这里即可注册使用。

值得一提的是，除了个人和常规团队使用，针对有高安全合规要求、或需要在内网环境协作的企业，Apifox 还提供了深度定制的私有化部署方案。

获取专属报价与部署方案

详细的私有化部署系统架构与安全白皮书

针对您公司规模的专属报价单

免费的 1v1 专属产品演示 (Demo) 机会

获取部署方案

* 提交后，我们的客户经理将在 1 个工作日内与您联系

林俊锋 企业微信

@Apifox 专属顾问

扫码备注: 私有化 + 公司名