Agency Agents

一份 AI 专家人格名单，一人一份 markdown，按部门分组：工程、设计、市场、付费媒体、产品、项目管理、研究、销售、财务、医疗、游戏开发、地理信息、学术、专业角色与支持。每份文件都带 frontmatter、确定的语气与工作方法；安装方式是把某个部门拷进工具的 agent 目录，或跑一个会针对目标工具转换整份名单的脚本。配套的桌面应用可以浏览整个集合、装进 Claude Code、Cursor、Codex、Gemini CLI、OpenCode、Qwen 等，并保持更新。这个仓库诞生自一个 Reddit 帖子。

谁做的457 次提交里有 197 次出自他，也是把外部贡献整合进来的人。这个项目是真正多作者的——GitHub 的贡献者列表上有五十个人（那正是这份列表停止计数的地方），且 444 次提交挂在已关联账号上。贡献者当中还有 claude。

1. 01

   十五万五千个星，零个 release

   这些数字是本档案记录到的最大的：155,273 星、25,048 fork、1,127 watcher、370 个文件、155 个未关闭 issue。同时它没有任何 release、也没有任何 tag——对一个这个体量的项目来说值得注意：分发靠的是安装脚本和一个配套桌面应用，而不是带版本的下载，所以没有一个已发布的产物能让版本号指过去。历史是来自五十位贡献者的 457 次提交——五十正是 GitHub 贡献者列表停止计数的地方——其中 444 次挂在已关联账号上。第一次提交的日期是 2025-10-13，自称是「五十一个专家 agent」。README 把起源归于一个 Reddit 帖子。

2. 02

   它到底是什么

   每个 agent 都是一份带 YAML frontmatter 的 markdown，有自己的语气和工作方法，而它们按公司的方式分组，而不是按软件的方式：工程、设计、市场、付费媒体、产品、项目管理、研究、销售、财务、医疗、游戏开发、地理信息系统、学术、专业角色与支持。一份 divisions.json 描述这套分类，两个脚本负责看守它。把名单装进某个工具，要么是把一个目录拷进那个工具的 agent 目录，要么是带着目标名跑一次安装脚本。配套应用做的是同一件事，只是用浏览器和一次点击，覆盖 Claude Code、Cursor、Codex、Gemini CLI、OpenCode、Qwen 等，并自动更新它装过的东西。README 的主张——是专精而不是通用提示词模板、有人格、以交付物为中心——是那种容易宣称、难以在这个体量上维持的话；而真正有意思的证据不在 README 里，而在仓库为了让它继续成立所做的那些事上。

3. 03

   一份名单，十三种工具

   「到处都能用」的隐藏成本是一道转换，而有一条 pull request 用一行字暴露了它的代价：它保住了转换后正文里的水平分割线，从而恢复了十三个工具、一百三十一个 agent 文件里的内容。一条把单份源文档跑成十三种输出格式的转换管线，有十三次机会、每个文件一次又一次地、悄无声息地弄丢一点点——而修复不是一个重新设计，而是一条关于水平线的规则。同一位贡献者那一串里还包括：在写入任何东西之前拒绝重复 slug、自动转换失败后停下、以及守住共享的目标路径。这就是「无论读者手上是什么工具都能用」这个价值主张要交的普通税。

4. 04

   一次静默的部分安装，起因是 SIGPIPE 和一个选项

   这个仓库里最好的 bug，离「看不见」只有一行 shell 的距离。安装器把选中的 slug 列表管道给一个安静的 grep，而 pipefail 选项是开着的。当匹配出现在列表靠前的位置时，grep 在生产者写完之前就退出，生产者收到断管信号，于是即便那个 slug 匹配成功，整条管道仍然报失败。而安装器的每一步都会跳过失败的 agent 继续往下走，脚本最终仍然以成功退出——所以 --division engineering --link 在六十四个 agent 里只装了十二三个，却什么也没说。两次幂等运行选出了不同的子集，先是十四、再是四十六，同样没有报错。修法是用 here-string 取代管道；回归测试把匹配的 slug 放在一条两万零一项列表的开头，好让这个竞争变成确定性的而不是偶发的。一个「只装了你要求的一部分却返回成功」的工具，比一个直接失败的工具更糟——而只有把同一条命令再跑一遍，你才会发现它。

5. 05

   十五个 pull request，一次合并，以及解释这件事的那段回复

   有一位贡献者花了一段时间审计安装器与 CI，发了十五个 pull request。维护者把它们合成一次合并落地，好让任何一个都不与下一个冲突，每一次提交都原样带着原作者的名字进来；然后在一段回复里解释了为什么——这是一次真正的审计而不是随手一改，因为每一个 PR 都附了一个在修复之前会失败的测试，这才让十五处改动能在一轮里被审完。他单独点出那条水平线修复恢复了 131 个 agent 的内容，以及那条目标路径修复关掉了一条真实的数据丢失路径。然后他提了一个请求——既然安装器和 CI 文件几乎被所有东西共用，下一轮先开一个 issue 把清单列出来，好让顺序先谈定、互不相撞。这是一个维护者把一次险情转化成了贡献流程。

6. 06

   贡献路径是一份清单加两个脚本

   新增一个 agent 是有形状的。pull request 模板会问 agent 的名字、类别与专长，并带一份清单：遵循贡献指南里的模板、包含带名字／描述／颜色的 frontmatter、给出具体的代码或模板而不是描述。提交者会自报验证结果——agent 通过 lint、部门检查通过——而一份漂移清单是在一批改动的末尾统一重生成一次，而不是每个改动各生成一次。一份 21 KB 的贡献指南加上一份 9 KB 的中文翻译，把其余的都写清楚了。最近的队列读起来正好是流程想要的样子：两天里三个 agent，每一个都关掉一个具名 issue，每一个都论证了自己为何不是既有角色的重复——一位 ServiceNow 平台开发者，与只是把 ServiceNow 列为三种平台之一的 IT 服务经理不同；一位 Abaqus 有限元专家，与只在概念层面提过一次「有限元分析」的土木工程师不同；一位政策文档生成器，与只审别人起草的文档的审查角色不同。

7. 07

   一个把角色转换成技能，并把会话一起附上的 PR

   有一条 pull request 在结构上做了件有意思的事：把一个既有的 agent 角色转换成 Claude Code 技能，并在正文里解释了区别。产物是一份短的、常驻的指令文件加一个触发关键词描述，模板则拆成按需加载的参考文档；没有角色、也没有工具隔离，作者写道，因为这是应当在当前对话里直接起作用的领域知识，而不是一个独立的 agent 身份。这是同一份专长的两种打包方式之间一条真实的界线，而这个仓库现在两种形态都有。不那么显眼的是：这条 PR 里带着产出它的那次会话的链接。把过程记录连同改动一起发布是件小事，几乎没有项目这么做，而它把提案变成了一件审查者可以核对的东西，而不是一份只能选择相信的摘要。

8. 08

   五十个名字、一个很大的份额，以及贡献者列表上的一个模型

   贡献分布既偏斜又健康：最大的份额是 197 次提交，而它背后是来自许多国家的几十个一到两次提交的贡献——一份由人群而不是由一个人拼起来的名单。共同作者尾注讲了另一半故事。它们有 128 条，而且把模型和人混在一起：Claude Opus 4.6 占二十九次、Opus 4.8 二十次、两种百万上下文合计二十六次、Fable 5.1 与 Sonnet 4.6 各八次、Copilot 三次，还有一次来自 Mistral Vibe。与它们并列的是人类共同作者——那正是「结对」被如实记录下来的样子。而 claude 本人也以两次提交出现在贡献者列表里。一个由人群贡献的 agent 人格仓库，其共同作者账本正日益在人与其协作的模型之间平分——这是一幅关于这门实践走到哪里的、相当准确的画像。