11.8 万 Star 的 agency-agents，把一整家公司的 232 个岗位写成 Agent 花名册

先看一组不太正常的数据。

2025 年 10 月 13 日建仓，到 2026 年 6 月 29 日，msitarzewski/agency-agents 拿到了 11.8 万 Star，1.94 万 Fork，MIT 协议，主语言写的是 Shell。八个月，11 万星。

你想想看，一个主要是 Markdown 文件的仓库，凭什么长成这样。不是推理框架，不是 CLI 工具，连个像样的运行时都没有，里面装的全是「人设」。

我翻了一圈，才反应过来它做了一件很讨巧的事。它把一家公司完整的组织架构图，拆成了 232 个带人格的 Agent，分在 16 个部门里，前端工程师、渗透测试员、Reddit 社群运营、CFO、土木工程师、Bilibili 内容策略师，应有尽有。然后给你一个脚本，一键装进 Claude Code、Cursor、Codex、Gemini 这些工具里。

你买的不是工具，是一份花名册。

它不是 Agent 框架，是「内容层」

这点要先说清楚，不然你会误判这个项目。

市面上 Agent 项目有两种。一种是造引擎的，像 Hermes Agent、browser-use，给你一套调度、记忆、工具调用的骨架，你往里填 Prompt。另一种是造人设的，agency-agents 属于这种，它不造引擎，只造人。

它甚至不绑死任何一个 Agent 工具。README 里列了一长串支持的平台，Claude Code、GitHub Copilot、Antigravity、Gemini CLI、OpenCode、OpenClaw、Cursor、Aider、Windsurf、Qwen Code、Kimi Code、Codex，12 种。装的方式各不相同，Claude Code 是 .md 丢进 ~/.claude/agents/，Cursor 是 .mdc 规则，Codex 是 TOML，Aider 干脆把所有 Agent 编译成一个 CONVENTIONS.md。

也就是说，它赌的是「不管你用哪个 Agent 工具，都需要专业人设」这一层，把自己定位成上游的内容供应商。引擎会换，人设不会。

这个定位挺聪明的。坦白讲，这也是它能跨工具爆发的根本原因，它不和任何一家 Agent 平台竞争，反而给所有平台供货。

一个 Agent，到底装了什么进去

光看「232 个 Agent」这个数字没感觉，拆一个看看才知道分量。

随便挑一个 Engineering 部门的 Code Reviewer。它不是「你是一个代码审查专家，请帮我审查代码」这种一句 Prompt。它的文件结构是固定的，前面是 frontmatter，后面跟着几大块。Identity & Memory 写它的身份和记忆，Core Mission 写核心使命，Critical Rules 写这个领域不可妥协的规则，Technical Deliverables 带真实代码示例，Workflow Process 写工作流，最后还有 Success Metrics。

Evidence Collector 这个测试岗的人设里有一句话，我很喜欢。

I don’t just test your code, I default to finding 3-5 issues and require visual proof for everything.

我不只是测你的代码，我默认要找出 3 到 5 个问题，而且每件事都要可视化证据。这种话术不是模板能写出来的，它是真有人在生产环境里踩过坑，才知道「要求可视化证据」是个值得写进人设的硬规则。

Whimsy Injector 这个设计岗的人设更有意思，它的工作是往产品里注入「 whimsy」，小惊喜、彩蛋、微交互。但它给自己划了边界。

Every playful element must serve a functional or emotional purpose. Design delight that enhances rather than distracts.

每一个玩心元素必须服务于功能或情感目的，是增强而不是干扰。你看，连「搞怪」这个岗位都讲究克制，这就是成熟组织里的人该有的样子。

每个 Agent 大概 50 到 200 行，232 个加起来 README 自己说「10,000+ lines of personality, process, and code examples」。这些不是 Prompt 堆砌，是岗位知识工程化。

16 个部门，藏着对「完整公司」的理解

光看部门划分，就能看出作者的组织想象力。

Engineering、Design、Paid Media、Sales、Marketing、Product、Project Management、Testing、Security、Support、Spatial Computing、Specialized、Finance、Game Development、Academic、GIS。这 16 个里，前 10 个是常规科技公司都有的，但后面几个很说明问题。

Spatial Computing 部门放了 visionOS Spatial Engineer、macOS Spatial/Metal Engineer，赌的是空间计算会成为一个独立工种。Game Development 部门按引擎分，Unity、Unreal、Godot、Blender、Roblox Studio 各有一套，连 Roblox 的 Luau、DataStore、服务端权威模块架构都写进去了。Academic 部门更绝，放了人类学家、地理学家、历史学家、叙事学家、心理学家，专门给世界观构建和叙事设计做学术背书。

Marketing 部门对中国市场的覆盖密度高得离谱。Xiaohongshu Specialist、WeChat Official Account Manager、Zhihu Strategist、Baidu SEO Specialist、Bilibili Content Strategist、Kuaishou Strategist、Douyin Strategist、China E-Commerce Operator、Private Domain Operator，连 Livestream Commerce Coach 都有。这背后大概率有中国贡献者的深度参与，社区翻译表里 jnMetaCode 维护的中文版就有 141 个翻译 Agent 加 46 个中国本土原创。

说真的，这种覆盖度不是一个人能写出来的，它是个社区工程。

装起来，比想象中克制

安装体验我特意看了一下，作者在「让你装得进去」这件事上花了真功夫。

核心是一套 convert.sh 加 install.sh 的组合拳。convert 负责把统一的 .md 人设文件，转换成 12 种工具各自的格式。install 负责扫描你装了哪些工具，给你一个交互式的勾选界面，你打勾它装，不想要 Engineering 部门可以不装。

# 装全部到 Claude Code
./scripts/install.sh --tool claude-code

# 只要 engineering 和 security 两个部门
./scripts/install.sh --tool claude-code --division engineering,security

# 只要前端和 UI 两个 Agent
./scripts/install.sh --tool cursor --agent frontend-developer,ui-designer

这个 --division 和 --agent 的细粒度选择很重要。232 个 Agent 全塞进一个工具会出事，README 里直接点了一个 OpenCode 的上游 bug，它的运行时只注册大约 119 个 Agent，多出来的会被静默丢弃。所以安装器在超量时会警告你，建议你装子集。

这种诚实我挺欣赏的。它没有装作「全平台完美支持」，而是把已知平台的坑写进文档，还做了防护。

还有个细节，现在出了一个原生 App，叫 Agency Agents，macOS、Linux、Windows 三端都有，能图形化浏览整个花名册，一键装到各个工具里，还自动更新。Homebrew 一行 brew install --cask msitarzewski/agency-agents/agency-agents 就能装上。

从 clone 脚本到原生 App，这个演进路径挺标准的，也说明项目在认真做分发。

花名册的水分和天花板

这地方我得说实话，不然后面会有人踩坑。

第一，这些 Agent 是静态文件，不是自主智能体。 它们只是带结构的人设描述，能不能真的交付，完全取决于你用的底层模型和工具的执行能力。Code Reviewer 写得再好，如果你用的模型本身代码能力不行，它也找不出 3 到 5 个问题。Agent 的天花板，永远是人设的下限乘以模型的上限。

第二，「232 个 Agent」有水分。 Marketing 部门一个中国平台就一个 Agent，Xiaohongshu 一个、Douyin 一个、Kuaishou 一个，本质是同一套运营方法论套不同平台参数。真要算「方法论」，可能也就 60 到 80 个，剩下的是变体。这不是坏事，但你别被 232 这个数字唬住。

第三，没有真正的编排。 README 里有个 Scenario 叫「Full Agency Product Discovery」，号称 8 个部门并行工作，但点进去看，是「8 个 Agent 被同时部署」产出一份统一计划。这是人工调度 8 个 Agent，不是 Agent 之间自主协作。想让它自己组队干活，还得你自己写编排逻辑，或者交给 Hermes Agent 这种框架。

第四，Fork 数偏高有玄机。 11.8 万 Star 配 1.94 万 Fork，Fork 比例大约 16%，比一般项目高。一个纯 Markdown 仓库这么高比例的 Fork，大概率有大量是 fork 去改一份自己用的，真正活跃贡献的是少数。看社区翻译表就懂，主流语言版本基本都出自 jnMetaCode 和 sscodeai 两个人之手。

岗位即资产，是它真正押注的范式

写到最后，我想说点自己的判断。

agency-agents 表面上是个 Agent 仓库，骨子里验证的是一个可迁移的工程判断，「岗位描述」可以从招聘文档变成可分发的数字资产。传统公司是「岗位描述 + 招人 + 培训」，人走了知识就带走。agency-agents 把这条路反过来，岗位知识先固化成 Agent 人设，谁来了即装即用，人走了文件留下。

这个判断的价值不在于现在的 232 个 Agent 有多好用，而在于它建立了一种范式，一个岗位可以被工程化成一个 Agent，然后被复制、被改进、被组合。它给了一个可命名的模式，姑且叫「岗位资产化」，把组织里最易流失的隐性知识，变成可版本控制、可 fork、可分发的显性文件。

你想想看，如果这套思路跑通，以后创业公司的第一份资产，可能不是产品代码，而是一份这样的 Agent 花名册。这个判断放到任何知识密集型团队的工具选型上都成立，谁能把岗位经验沉淀成可复用的 Agent，谁就降低了人员流动带来的知识损耗。

现在入局，一点都不晚。