一家开在硬盘里的公司

232 个 AI 员工、16 个部门，和一个不睡觉的"代理机构"

第一章 凌晨三点的招聘需求

凌晨三点，你盯着屏幕，手边凉了半杯咖啡。

事情是这样的：你正在做一个产品，突然发现手头缺三种人。一个前端工程师，帮你看一眼那个 React 组件为什么在 Safari 上错位；一个 SEO 专家，瞄一眼页面结构有没有埋坏关键词；还有一个文案，润色那句你改了八遍还是觉得别扭的口号。

正常情况下你会怎么做？发三个招聘需求，等一周，面试几个人，录一个，花三份钱。或者更现实一点，你根本请不起三个人，只能自己硬着头皮全干，干得磕磕绊绊。

但现在有另一种办法。

你打开一个文件夹。里面整整齐齐躺着 232 份档案，每一份都写着一个会干活的"专家"。有前端工程师，有 SEO 顾问，有文案，有安全架构师，有游戏设计师，甚至有专攻小红书种草的营销专员。你挑出你需要的那三份，往你正在用的编程工具里一塞——它们就开始干活了。不面试，不谈薪，不排期，凌晨三点也照常上班。

这个文件夹，叫 The Agency。

它的作者是一个叫 Michael Sitarzewski 的美国人，放在 GitHub 上，开源，免费，谁都能用。232 个"员工"，分成 16 个部门，像一家真正的代理公司一样有组织架构，只不过这家公司没有写字楼，没有打卡机，没有年终奖，它的全部资产就是一个 Git 仓库。

这是一家开在硬盘里的公司。

说它"开在硬盘里"，是因为它的组织架构图、员工名册、岗位说明，全都写在一个代码仓库里。你 clone 下来，就有了这家公司的全部。它的员工不打卡，不抱怨，不跳槽，不要求五险一金。它们的"身份"是一个个 Markdown 文件，文件开头写着这个员工叫什么、擅长什么、什么脾气、怎么干活。

你可能觉得，这不就是一堆提示词嘛。

是，也不是。提示词是一行指令——"帮我写个 React 组件"。但 The Agency 里躺着的，是一个"人"——他有名字，有专长，有自己的一套工作流程，有明确的交付标准，甚至有自己的说话风格。你激活他，不像是在下指令，更像是在叫一个同事的名字。

这家公司到底是个什么东西？它是怎么运转的？为什么一个美国开发者的仓库里，会专门养着一支会说"老铁""种草""私域流量"的中国小分队？它不收一分钱，靠什么活着？

我们一层层拆开来看。

第二章 翻开这家公司的员工名册

先看这家公司有多大。

232 个员工，16 个部门。这个规模放在真人公司里算个中型企业了，放在开源项目里更是罕见，大多数 AI 提示词库能凑出二三十个就算丰富，The Agency 直接铺了一张 232 人的大网。

16 个部门分别是干什么的？我挑几个有意思的给你看。

工程部门是最大的，31 个员工。前端、后端、移动端、AI 工程师、DevOps，这些你意料之中。但还有一些你没想到的：比如"代码库领路人"（Codebase Onboarding Engineer），专门帮新来的开发者快速摸清一个陌生项目；"最小改动工程师"（Minimal Change Engineer），信奉"能改一个字绝不改两个字"的哲学；还有"事件响应指挥官"（Incident Response Commander），凌晨三点服务器挂了，他来调度。

设计部门9 个人。除了 UI 设计师、UX 研究员，有一个叫 Whimsy Injector 的岗位——直译是"趣味注入师"。他的工作不是画图，而是给产品注入"个性和愉悦感"，让那些冷冰冰的界面多一点让人会心一笑的东西。光这个岗位名，就值得记住。

测试部门9 个人。其中一个叫 Reality Checker——"现实核查员"。他的职责是当"质量门"：别人说"做完了"，他要亲自验过，拿证据说话。还有一个叫 Evidence Collector（证据收集员），专门负责截图存证，让每一次测试都有迹可循。这俩名字起得像谍战片里的角色。

安全部门10 个人，从安全架构师到渗透测试员到合规审计师，一条龙。学术部门更有意思，5 个人，分别是人类学家、地理学家、历史学家、叙事学家、心理学家。他们不写代码，专门为"世界构建、故事讲述和叙事设计"提供学术支撑。这是给游戏开发者和内容创作者准备的智囊团。

游戏开发部门横跨 Unity、Unreal、Godot、Roblox、Blender 五大引擎，每个引擎都有专门的架构师和着色器工程师。空间计算部门6 个人，搞 Apple Vision Pro 和 WebXR。GIS 部门13 个人，处理地理信息系统，从战略层的方案架构师到交付层的制图设计师，分了四个层级。

还有财务部门5 个人，从记账到税务策略；项目管理部门7 个人，连 Jira 工作流都有专门的管家；付费媒体部门7 个人，专攻 Google Ads 和程序化购买；销售部门10 个人，从外呼策略到提案撰写到赢单分析。

最庞大的是营销部门，36 个人，覆盖了全球主流平台和中国主流平台，这一块我们后面专门讲。

专业化部门则是个大杂烩，40 多个人，什么都有：MCP 协议构建师、文档生成专家、CFO、HR 入职专员、房地产买卖顾问、贷款审批助理、并购整合经理、组织心理学家、ESG 可持续发展官、数据隐私官……简直像把一整个商业世界的岗位都搬了进来。

每个员工都有一张"工牌"。工牌上除了名字，还有一个小图标——前端工程师是🎨，安全架构师是🛡️，趣味注入师是✨。图标后面跟着一个叫 vibe 的字段，写着这个人的气质：专业、幽默、严肃、温暖。就像真人工牌上除了姓名，还有一张照片和一句自我介绍——让你一眼认出这是谁，什么脾气。

这家公司的"员工名册"不是一份静态文档。它在一个叫 divisions.json 的文件里登记造册，每次有人提交新员工，都要过一道自动检查：部门对不对、格式对不对、工牌信息全不全。这套纪律我们后面细说。

先回答一个更基本的问题：为什么 AI 需要分这么多"人"？一个通用的 AI，什么都能干，不就够了吗？

第三章 角色卡，不是简历——为什么 AI 也需要"脾气"

这是个好问题。我们得先想清楚一件事：通用 AI 和专门 AI，到底差在哪。

你用过那种"什么都会一点"的 AI 助手吧。你让它写代码，它能写，但写得像个刚毕业的实习生，能跑，但不够优雅。你让它做 SEO 分析，它给你列一堆正确的废话。你让它写文案，它写出来的东西四平八稳，挑不出毛病，但也打动不了任何人。

问题不在于它不聪明。大模型现在聪明得很。问题在于它"没有立场"。一个什么都会的 AI，像一个没有性格的通才，什么都能聊两句，但深入下去就泛泛。它不知道一个真正的前端工程师会怎么思考问题，不知道一个真正的 SEO 专家会先看什么指标，不知道一个好的文案在动笔前会问客户哪三个问题。

The Agency 的每个员工，是一张"角色卡"。

为什么说"角色卡"而不是"简历"？简历只写"会什么"——会 React，会 SEO，会写文案。角色卡还写"是什么样的人"——你是什么身份，你的使命是什么，你遵循什么规则，你的工作流程是什么，你说话是什么风格。

这听起来有点像在给 AI 编人设。没错，就是这样。但这里的人设不是随便写两句"你是一个乐于助人的助手"就完了。The Agency 的角色卡是一套完整的工程化定义，通常包含这几个部分：身份（我是谁）、核心使命（我干什么活）、关键规则（我遵循什么铁律）、工作流程（我按什么步骤干活）、沟通风格（我说话什么调调）。

你拿到一张前端工程师的角色卡，激活他，他不只是"会写 React"。他会按照一个资深前端的思路来工作：先问你这个组件用在什么场景、要不要考虑无障碍访问、性能预期是多少，然后给你一个完整的实现方案，还会顺手提醒你这个方案在旧版 Safari 上有个已知坑。

这就是"角色卡"和"简历"的区别。简历是技能清单，角色卡是一个完整的工作人格。

那这套"角色卡"有什么用？这里要引入一个更深的判断。

当下整个 AI 行业正在往一个方向跑——"技能化"。有个叫 SKILL.md 的开放标准，由 Anthropic 发起，已经被 40 多个工具采纳。它的思路是把 AI 的"能力"切成一块一块可复用的小模块，像一个技能库，谁需要就加载哪个。这个思路很主流，也很合理。

The Agency 走的是另一条路——"人格化"。它的最小单位不是"一个技能"，而是"一个完整的专家"。技能是"怎么做某件事"，人格是"一个会做某件事的人"。

这两者的区别，可以用一个譬喻说清楚。

技能是菜谱，人格是厨师。

菜谱写的是步骤——油温七成热，下锅翻炒三分钟，加盐少许。菜谱的好处是能跨厨房复制，谁拿到都能照着做。但厨师不一样。厨师有手感，有节奏，有自己琢磨出来的招牌菜，有面对突发情况时的直觉——火大了他知道怎么救，食材差了他知道怎么调。菜谱能拷贝，厨师的手感拷贝不了。

当大模型越来越聪明，"步骤化的技能"最容易被模型自己吃掉——模型学会了就不需要你教了。但"一个有性格的同事"这种预设，反而更难被替代。因为用户要的不只是"把事做完"，还有"对路的人来做的"那种感觉。你找人写文案，你要的不只是一段通顺的文字，你要的是一个"懂你调性"的人写出来的东西。

这是 The Agency 的哲学，也是它的赌注——赌"人格"这层抽象比"技能"更持久。

当然，赌注能不能赢，是另一回事。我们后面会聊。

现在先看一个更实际的问题：232 张角色卡，怎么管？总不能随便谁往仓库里塞一个文件就算数吧？

第四章 divisions.json 是这家公司的宪法

任何一家公司，只要人一多，就得有组织架构。The Agency 有 232 个人，分 16 个部门，怎么保证不乱？

答案藏在一个叫 divisions.json 的文件里。

这个文件是这家公司的"宪法"。它定义了有哪些部门、每个部门叫什么名字、配什么图标、用什么品牌色。听起来像一份普通的配置文件？但它背后的纪律，比大多数真人公司的组织架构图严格得多。

普通公司的组织架构图画在 PPT 里，改起来随便，老板一句话，加一个部门、裁一个部门，PPT 重画一版就完事。但 The Agency 的组织架构图刻在 JSON 文件里，而且有一套自动检查机制盯着它：每次有人提交改动，系统会同时核对四个地方是不是完全一致。

哪四个地方？

第一，磁盘上的实际目录——你说有 16 个部门，那仓库根目录下就得有 16 个文件夹，多一个少一个都不行。第二，转换脚本里的部门数组——脚本得知道有哪些部门，才能把它们挨个处理。第三，检查脚本里的部门数组——检查程序也得知道标准答案。第四，自动检查流程里的路径配置——告诉系统该检查哪些目录。

这四个地方，必须一字不差。任何一个地方多了或少了一个部门，系统直接亮红灯，拒绝合并。

为什么这么较真？打个比方。一架飞机起飞前，有三份文件必须完全对得上：登机牌、货舱单、海关申报单。任何一份上多了一个名字或少了一个名字，飞机都不能起飞——因为你不知道是有人偷渡了，还是有人漏乘了。divisions.json 就是那份登机牌，磁盘目录、两个脚本的数组、检查流程的配置是三份必须对齐的副本。检查程序就是那个一丝不苟的调度员，逐字核对。

这种做法有个名字，叫"单一真相来源"（Single Source of Truth）。道理很简单：同一个信息只在一个地方定义，其他所有地方都引用它，不允许各自维护一份。因为一旦同一个信息存在两份副本，早晚会出现"两张皮"——文档说一套，代码做一套，谁也搞不清哪个是对的。

这套纪律不是摆设。The Agency 的仓库根目录其实还有一些其他文件夹，比如 examples（示例）、scripts（脚本）、integrations（集成输出）、strategy（策略剧本）。但它们都不算"部门"。为什么？因为检查程序还有一个规矩：每个部门目录里至少得有一个真正的"员工档案"——也就是以 --- 开头的 Markdown 文件。strategy 目录里全是"剧本"，没有员工档案，自动被排除在外，不会被误算成部门。这个逻辑很巧妙：不是你起了个文件夹名字就算部门，得有真员工在里头才算。

那这些检查具体是谁在执行？

答案是三道"安检门"。

第一道叫 check-tools，管工具清单，仓库支持 14 个工具平台，每个工具的配置必须齐全，少一个字段就拦下。第二道叫 check-divisions，管部门清单，就是上面说的四处对齐上面说的四处对齐。第三道叫 lint-agents，管每个员工档案的质量，名字写了没有、描述写了没有、格式规不规范。

这三道门的设计有点像机场安检。机场的安检不是一道，是三道，各管一摊：第一道查你的身份证和登机牌对不对得上，第二道查你的行李里有没有违禁品，第三道查你的登机口对不对。The Agency 的三道门也是一样：前两道每次改动都要过，因为"新增一个工具或部门"这种事可能藏在任何文件里，得每个都查；第三道只查你这次改动的那些员工档案，因为没动过的档案上次已经查过了，没必要重复查。

特别值得一提的是，那两道"每次必过"的门，检查程序是用纯 Bash 写的，不依赖任何额外工具，连 jq（一个常用的 JSON 处理工具）都没用。这意味着不管你用 macOS 自带的终端，还是在云端服务器上跑，结果都一样。这种"零依赖"的写法，是为了让检查在任何环境下都能跑起来，不会因为"你机器上没装某个软件"就跳过检查。

这家公司不是"扔上来一堆文件就不管了"。它有一套铁律，而且铁律是真的在执行——不是写在文档里让人自觉遵守，而是写进自动检查流程，你不遵守就合并不进去。

这是一种工程纪律。但 The Agency 的工程巧思不止于此。真正让人拍案叫绝的，是它怎么让同一张角色卡，跑在 14 种不同的工具上。

第五章 母带与刻录——一个角色卡，插进任何一台游戏机

The Agency 支持 14 个工具平台。Claude Code、Cursor、Codex、Gemini CLI、GitHub Copilot、OpenCode、OpenClaw、Antigravity、Aider、Windsurf、Kimi Code、Osaurus、Hermes、Qwen，市面上叫得出名的 AI 编程工具，几乎全了。

这意味着什么？意味着你不管用哪家工具，都能用上这 232 个员工。

但这里有个工程难题。这 14 个工具，每一个对"Agent 文件"的格式要求都不一样。有的要一个文件，有的要拆成三个文件；有的用 Markdown，有的用 JSON；有的要求所有 Agent 聚合成一个大文件，有的要求每个 Agent 单独一个目录。你总不能为每个工具手写一份吧？232 个员工乘以 14 个工具，3000 多个文件，谁维护得过来？

The Agency 的解法，是造了一个"编译器"。

这个编译器叫 convert.sh。它的原理，可以用一个譬喻讲明白。

想象你录了一场交响乐，母带只有一份。但你要发行到黑胶、CD、卡带、流媒体四种介质。每种介质的物理特性不同，黑胶要做 RIAA 均衡，流媒体要响度归一化，卡带要考虑磁饱和。你不能为每种介质重录一遍，你需要一个母带工程师，对着同一份母带做不同的后期处理。

convert.sh 就是这个母带工程师。仓库里 16 个部门目录下的 Markdown 文件是"母带"——唯一的手写原件。integrations 目录下 14 个工具的产物全是"刻录版"，文件头都盖着一句话："由 convert.sh 生成，请勿手动编辑"。你想改一个员工？改母带，然后重新刻录。刻录版永远是派生物，不是源头。

这个"母带-刻录"的架构，保证了一件事：无论支持多少个工具，手写的工作量永远是 232 份，不会膨胀。

但 14 个工具的格式差异，光靠一个脚本怎么搞定？这里有个很精巧的设计。

14 个工具虽然多，但仔细看它们的输出格式，有些是完全一样的。比如 Antigravity 和 Osaurus，都要生成一个 SKILL.md 文件，内容结构一模一样——那干嘛写两套渲染逻辑？写一套，两个工具共用就行。于是 The Agency 在配置文件里定义了一个 format 字段，相当于一个"渲染器契约"：只有当两个工具的输出文件逐字节相同时，才能共享同一个渲染器。14 个工具最终共享的是 10 种渲染器。

还有一个 installKind 字段，定义了三种安装机制。第一种叫 per-agent，每个员工一个文件或目录，大多数工具都是这样。第二种叫 roster，所有员工聚合成一个大文件——比如 Aider 工具要的是一个 CONVENTIONS.md，Windsurf 要的是一个 .windsurfrules，把 232 个人塞进一份花名册里。第三种叫 plugin，构建一个不可逐个拆分的安装包，只有 Hermes 这种工具需要。

最复杂也最有创意的渲染器，是给 OpenClaw 用的。OpenClaw 要求每个员工拆成三个文件：SOUL.md（灵魂，写人格）、AGENTS.md（任务，写工作内容）、IDENTITY.md（身份卡，写名字和气质）。那怎么从一份母带里拆出三份？The Agency 的做法是按章节标题的关键词来切——原文里标题包含"身份""学习记忆""沟通风格""关键规则"的章节，归进 SOUL.md；其余的归进 AGENTS.md；文件开头的 emoji 和气质描述单独提出来，生成 IDENTITY.md。一个文件，智能拆成三份，各得其所。

这套架构的妙处在于：新增一个工具，不用改 232 份文件，只要写一个新的渲染器（或者复用现有的），告诉编译器"这个工具要什么格式"就行。

当然，也有搞不定的时候。OpenCode 这个工具有个已知 bug，它的运行时最多只能注册大约 119 个 Agent，超出的会被静默丢弃。The Agency 有 232 个，远超上限。The Agency 没法去改 OpenCode 的代码，但它做了一件体面的事：在安装程序里加了一个上限检测，安装完会弹出警告——"这家工具最多吃 119 个，你多出来的 113 个它装不下，建议你用 --division 参数只装一部分。"

打个比方。你建了一家有 232 间客房的酒店，但接你生意的旅行社系统里只能登记 119 间房——这是旅行社的 bug，不是你的。你修不了旅行社，但你在前台贴了张告示，告诉客人实情，还给了个变通办法。这不解决问题，但至少没人会在凌晨两点发现房间没了还不知道为什么。

还有一个细节，看着不起眼，但很能说明这家"公司"的严谨。

仓库里有个叫 .gitattributes 的文件，只有一行内容：*.md text eol=lf。意思是所有 Markdown 文件强制用 LF 换行符。为什么这么较真？因为 Windows 默认用 CRLF 换行，每行末尾偷偷加一个看不见的 \r。这个 \r 平时无害，但在解析角色卡的时候会要命。

角色卡的"工牌信息"写在文件开头，用三个减号 --- 作为标记。解析程序靠精确匹配 --- 来识别。一旦文件里有 \r，第一行就变成了 ---\r，四个字符，解析器一看——"这不是我认识的标记"，当场罢工。更要命的是，报错信息会说"缺少 frontmatter 标记"，但文件明明开头就是 ---，你会一头雾水。

打个比方。乐队的乐谱有个铁律：每行五条线。哪个抄谱员手抖画了六条线，小提琴手就不知道该按哪个音了，整页谱子作废。.gitattributes 强制 LF，就是规定全仓库只准用五线谱，谁画第六条线就打回重画。Windows 上的贡献者第一次提交时大概率会踩这个坑，但踩一次就记住了。

你看，这家"开在硬盘里的公司"，不光有人（232 个角色卡），有规矩（配置即宪法），有流水线（母带与刻录），还有一套从换行符到部门对齐的工程纪律。这不是一个"随便攒的提示词合集"，这是一个有骨架的工程。

不过，技术再精巧，也只是一半的故事。另一半，和人有关，确切地说，和中国人有关。

第六章 东方棋局——会说"老铁"的 AI 小分队

打开 The Agency 的营销部门，你会看到一个有意思的画面。

这里躺着 36 个营销岗位。其中大约一半，是面向全球主流平台的，Twitter 互动专员、Instagram 内容策划、TikTok 策略师、LinkedIn 内容创作者、Reddit 社区运营、SEO 专家、应用商店优化师。

但另外一半，长着一张中国脸。

小红书专员、知乎策略师、B 站内容策划、抖音策略师、快手策略师、微博策略师、百度 SEO 专员、微信公众号运营、直播带货教练、私域运营师、中国电商运营、跨境电商专家、短视频剪辑教练、中文播客策略师、中国市场本地化策略师……20 来个岗位，每一个都扎扎实实长在中国互联网的土壤里。

一个美国开发者的 GitHub 仓库，为什么养着一支会说"老铁"的 AI 小分队？

最直觉的猜测是，作者有中国情结。但翻遍作者 Michael Sitarzewski 的个人网站，只字未提中国。他的全职工作是在一家叫 Tandem Theory 的公司当创新与技术副总裁，白天在企业里搭 AI 平台。没有中国背景。

那为什么？

答案是：因为中国的互联网，不是西方互联网的翻译版，而是一个并行宇宙。

这不是修辞。是事实。举三个例子。

私域流量。这个词在西方营销体系里没有对应物。它的本质是"把用户圈到自己的池塘里养"，微信公众号、企业微信群、小程序会员。西方有 email 营销、有 CRM，但没有"私域"这个概念，因为西方的互联网流量逻辑和中国不一样。你让一个懂 email 营销的通用 AI 来做中国私域，它会一头雾水。

小红书的"种草"。听起来像 influencer marketing（网红营销）？不是。种草的核心不是"网红推荐"，而是"普通人分享真实体验"——小红书的内容生态建立在素人笔记上，不是大 V 带货。一个懂西方网红营销的 AI，来小红书只会想到"找 KOL 投放"，但小红书真正要的是"铺素人笔记、做搜索占位、养长尾流量"。两套逻辑，两个世界。

抖音的算法。抖音和 TikTok 是同一家公司的产品，但算法并不相同。推荐机制、流量池规则、内容权重的算法有差异。一个为 TikTok 优化的策略，原封不动搬到抖音上会水土不服。

所以，一个通用的"社交媒体策略师"Agent，在中国会失灵。不是因为语言不通——大模型翻译中文毫无问题——而是因为底层机制不同。

打个比方。国际象棋和中国象棋，都叫 chess，但棋盘不同、棋子走法不同、策略不同。一个精通国际象棋的"chess strategist"，坐到中国象棋的棋盘前，他的开局理论、中盘战术、残局技巧全都不适用——马不能走日，象不能过河，炮要隔子才能吃。"社交媒体营销"听起来是个通用概念，但小红书的种草和 Twitter 的 hashtag，就是两种不同的棋。

这也是为什么 The Agency 的中国 Agent 不是"翻译"出来的，而是"土生土长"的。它们会说的是"种草""老铁""UP 主""私域流量""弹幕文化"，懂 B 站的社区氛围，懂快手的老铁生态，懂直播带货的话术节奏。你激活小红书专员，他不会跟你聊 influencer marketing，他会跟你聊怎么铺素人笔记、怎么卡搜索词、怎么做内容矩阵。

更有意思的是，这些中国 Agent 很可能不是作者一个人写的。仓库的贡献记录里，有一个叫 hedonnn 的中国贡献者，提交了多个 Agent，都通过了原创性检查。项目还专门维护了一份中文贡献指南（CONTRIBUTING_zh-CN.md），2026 年 3 月还在更新。这意味着本地化不是作者一个人在翻译，是中国社区自己长出来的——中国贡献者带来中国知识，作者提供框架和审核。这是"社区即本地化"的模式。

这个模式比"一个人翻译全世界"聪明得多。因为真正懂中国互联网的，是每天泡在里面的人，不是远在达拉斯的美国开发者。作者做的，是把框架搭好、把门开好、把质量守住，然后让懂行的人来填内容。

这件事背后有一个更大的信号。AI 工具想做"全球化"，就得承认互联网是多极的。一个只懂 Twitter 和 Instagram 的 Agent，号称"全球营销专家"，是名不副实的。The Agency 的中国小分队不是礼貌性的本地化点缀，而是对一个事实的承认——未来的 AI Agent 生态，注定是多极的。谁要是假装互联网只有一种、营销只有一套打法，谁就会被真实的市场教做人。

第七章 从一个 Reddit 帖子到 232 人团队

故事要从头讲。

2025 年 10 月 13 日，GitHub 上出现了一个新仓库。第一版提交，51 个 Agent，9 个部门。作者是 Michael Sitarzewski，一个连续创业者，办过 8 家公司，当过创业孵化器 Techstars Cloud 的校友，还创办过达拉斯创业周。白天在 Tandem Theory 当高管，晚上搞开源。

这个项目的起点，据中文技术社区的报道，是一个 Reddit 帖子，有人在讨论在讨论 AI Agent 该不该走"专业化"路线，而不是当一个什么都能干的通才。Sitarzewski 觉得这事有意思，动手做了第一版。

就像朋友聚餐时吹了个牛——"我要开一家公司，全是 AI 专家"——结果真开起来了，而且越开越大。

8 个月。从 51 个 Agent 长到 232 个，从 9 个部门扩到 16 个。357 次提交。新增了安全部门、空间计算部门、学术部门、GIS 部门、游戏开发部门。每一个新部门背后，都是社区里有人觉得"这里还缺一块"，然后动手补上。

贡献者不只有 Sitarzewski 一个人。仓库记录里能看到 hedonnn、jmlozano1990、mvanhorn、Cyruschu430 等名字。每个贡献都要过三道关：原创性检查（不能抄袭）、格式检查（得符合模板）、部门对齐检查（得放在正确的部门里）。通过三关，才能合并。

还有一个有意思的元叙事。Sitarzewski 在搭这家"AI 公司"的时候，自己也在用 AI。好几次提交记录里标注着"Claude 协作"，用 Claude Opus 或 Claude Sonnet 来帮忙写和优化 Agent。一个人，带着 AI，搭了一家给人类用的 AI 公司。这层"套娃"意味，细想想挺有意思。

到了 2026 年中，项目又往前走了一步，出了一个桌面应用，叫 agencyagents.app。

为什么要做桌面应用？因为命令行对非工程师太不友好了。原来装一个 Agent，你得 clone 仓库、打开终端、跑 install.sh、选一堆参数。对程序员来说这是日常，但对设计师、对产品经理、对运营来说，这道墙不低。

桌面应用把这道墙拆了。你打开应用，看到的是 232 张角色卡的图形化列表，浏览、搜索、点一下就装到你的工具里。不用 clone，不用开终端，还自动更新。

这个故事本身就是一个开源项目的典型样本：一个人起头，社区接力，从脚本到应用，从小到大。但 The Agency 有一个不太典型的地方，它一分钱不收。这在当下"什么都要订阅"的风气里，显得有点格格不入。它是怎么活下来的？

第八章 免费菜谱与个人图书管理员

先说清楚 The Agency 的"商业结构"。

三层。第一层是 Agent 目录，232 个角色卡，MIT 开源，随便用。第二层是桌面应用，也是 MIT 开源，无遥测、无账号、无付费墙。第三层是 GitHub Sponsors 赞助入口，给觉得好用的人自愿打赏。

注意那个反直觉的点，桌面应用本身也是开源的、免费的。这不是"免费版 + 付费专业版"的套路。整个项目没有一处付费功能。

这种模式有个名字，叫"赞助经济"（sponsorware）。打个比方。街头艺人在广场上唱歌，音乐对所有人都免费，琴盒敞开着，路过的人愿意就投一张钞票，不愿意也照样听完。艺人靠的不是"卖门票"，是"觉得值的人自愿支持"。这些支持养活艺人继续唱下去。桌面应用就像艺人自己录的 CD，打包了便利，也是另一种支持方式，但音乐本身从不收费。

Sitarzewski 为什么敢这么干？因为他不靠这个吃饭。白天在 Tandem Theory 当副总裁，收入来自正职。The Agency 是他的"夜间项目"，用正职供养开源。他没有放弃收入的压力，所以没有非变现不可的焦虑。GitHub Sponsors 对单个仓库的月收入通常在几百到几千美元，养不活一个团队，但对一个有正职的独立开发者来说，够了，而且赞助换来的不只是钱，更是社区影响力和技术声誉，这些反过来会反哺他的正职和咨询业务。

那桌面应用图什么？为了消除恐惧。

前面说过，命令行对非工程师是高墙。232 个 Agent 用脚本安装，要 clone、要开终端、要选参数。桌面应用把这道墙拆了：图形化浏览、一键安装、自动更新，还多了一个"安装追踪"功能：它记得你装了哪些 Agent 到哪个工具里，如果文件被动过手脚，会提示"漂移"（drift），有人改了、删了、或者混进了外来文件。

打个比方。Agent 目录是一座公共图书馆，谁都能进、都能抄、都能读，书全是免费的。桌面应用是你的个人图书管理员，陪你走进去，帮你找到那本对的书，把它放到你常读的椅子上。书还是免费的，你"付"的只是对管理员的道谢（赞助），或者干脆什么都不付。

整个官网 agencyagents.app 上没有定价页、没有登录、没有订阅入口。它就是一个"展示窗 + 下载站"。如果未来要商业化，可能的路径是企业版（团队 Agent 管理、私有目录）、托管版（云端目录）、或者精选 Agent 市场。但目前看，作者的选择是"先把目录做大做全，商业化的口子留给未来"。

这其实是一个隐秘的赌注。Sitarzewski 赌的不是"靠这个赚钱"，而是"成为事实标准"。在技术世界里，标准本身比直接变现更值钱。Linux 没有直接赚钱，但它统治了服务器。HTTP 协议没有直接赚钱，但整个互联网都建立在它上面。如果 The Agency 能成为"AI Agent 人格定义"领域的事实标准——大家提到"Agent 角色卡"就想到它——那它的价值远比几千美元月赞助大得多。

这是一种"声誉基础设施"的逻辑。它的价值在于成为这个领域的权威源头（canonical source），大家提到"AI Agent 角色卡"就想到它。这种地位，远比几千美元月赞助值钱。

当然，能不能成为标准，取决于它能不能赢过另一股力量——"技能化"标准。这就要回到我们前面埋下的那个问题了。

第九章 这到底意味着什么

讲到这里，你可能已经在想一个更大的问题。

The Agency 这套东西，它到底意味着什么？一个好用的工具箱，还是某种更深层变化的信号？

先说一个变化。以前我们用 AI，一个人配一个助手，你问什么它答什么。但 The Agency 的思路是，你不需要一个什么都会的助手，你需要一支各司其职的团队。前端的事找前端，文案的事找文案，安全的事找安全。你是在管理一支团队，只不过团队成员全是 AI。人机协作的模式，正在从"一对一"变成"一对多"。你需要琢磨的不再只是怎么用 AI，而是怎么组建和调度一支 AI 团队。

这又牵出第二个变化。过去两年大家都在研究怎么写好提示词，怎么问 AI 才能答得好。但角色卡告诉我们，比"提示词"更值得琢磨的是"角色"。你给 AI 的不只是一句指令，而是一个完整的工作人格。一句"帮我写个 React 组件"，和一张写着"你是资深前端工程师，遵循无障碍标准，先问需求再动手，交付要带测试"的角色卡，效果天差地别。前者碰运气，后者有预期。

再往深一层。当你开始给 AI 编部门、写角色卡、设质检员、定交付标准的时候，有没有觉得这个画面有点眼熟？人类花了几百年摸索出怎么组织公司，分工、部门、层级、流程、质检，一套一套的。现在这些逻辑正在被搬到 AI 身上。The Agency 的 16 个部门，和一家真人代理公司的部门结构几乎一样。这不是巧合。"怎么把一群专长不同的人组织起来高效协作"这个问题，人类已经解过一遍了，答案就是部门制加角色定义加流程规范。把同样的答案用在 AI 身上，顺理成章。

也许未来会出现一种完全不同的"AI 组织学"，不照搬人类公司那一套。AI 不需要休息，不会闹情绪，可以无限复制，也许它该有另一种组织方式。但在那个新范式出现之前，用我们已经熟悉的逻辑来管 AI，至少是个务实的起点。

然后回到那个核心问题：The Agency 的赌注能不能赢？

它的哲学是"人格化"，对抗的是主流的"技能化"。技能化这边势头很猛，Anthropic 推的 SKILL.md 标准已经被 40 多个工具采纳，逻辑是把 AI 的能力切成可复用的小模块。大模型也在往这个方向走，越来越强的模型会自己内化越来越多的技能，你教会的它就不需要你再教了。

The Agency 押的是另一头。它赌的是，即使模型再强，"一个调过参、有交付记录、有稳定工作风格的现成专家"对用户仍有价值。就像定制西装再好，成衣市场依然庞大。不是所有人都需要从头定制，大多数人要的是拿来就能穿、尺码合适的现成货。

短期内这个赌注能赢。大模型虽然聪明，但"聪明"和"有稳定工作人格"是两回事。一个裸的大模型像一匹好马，跑得快，你得自己驾驭。The Agency 的角色卡像驯好的坐骑，上来就能骑，知道往哪跑。对非技术用户和团队标准化场景，"驯好的"比"跑得快的"更实用。

长期就看模型进化到什么程度。如果有一天模型能根据你的描述现场生成一个合适的工作人格，还能保持稳定，那预设的角色卡就会被边缘化。但那一天还远。在那之前，这类角色卡仓库有它不可替代的位置。

最后别忘了这个故事最朴素的一面。一个人，一个 Reddit 帖子，8 个月，232 个 Agent，16 个部门，14 个工具平台，一份中文贡献指南，一个桌面应用。没有融资，没有公司，没有营销预算。一个人起头，社区接力。

这件事本身就在回答一个问题：AI 时代，"组织"的门槛是不是在被重新定义？以前开一家公司要租办公室、招人、发工资、跑流程。现在，一个人加一个 Git 仓库加一群素未谋面的网友，就能搭起一家有 232 个"员工"的"代理公司"。这些员工是 AI，但它们的组织方式，分工、纪律、流程，和真人公司别无二致。

也许 The Agency 真正在做的，不只是提供一个 Agent 库，而是在试一种新的组织形态：人类搭框架、定规则，AI 执行、交付，社区贡献、迭代。这种形态能走多远，现在不好说。但它至少证明了一件事。一个人的"公司"，在 AI 时代，不再只是个比喻。

第十章 永远亮着灯的公司

凌晨三点。

你挑了三张角色卡——前端工程师、SEO 专家、文案——塞进你的工具里。前端工程师问了你两个问题：这个组件用在什么场景？要不要考虑无障碍访问？然后给了你一个实现方案，还提醒你 Safari 上有个已知坑。SEO 专家扫了一眼页面结构，指出了三个可以优化的地方。文案把那句你改了八遍的口号重写了一版，你读了第一遍就觉得，对了，就是这个味道。

整个过程不到十分钟。没有招聘需求，没有面试，没有等待。三张角色卡，三个"同事"，随叫随到。

现在你已经知道这家公司背后的故事了。232 个员工，16 个部门，14 个舞台。一支会说"老铁"的中国小分队。一份写在 JSON 里的宪法。一套母带与刻录的流水线。三道从不打盹的安检门。一个从 Reddit 帖子长出来的社区。一个不收一分钱的赞助经济。一个关于"人格"和"技能"的赌注。

这家公司不会上市，不会发年终奖。它的员工不打卡，不抱怨，不跳槽，不需要五险一金。它的全部资产是一个 Git 仓库，谁都能 clone，谁都能改，谁都能用。它的"老板"白天在另一家公司当副总裁，晚上和一群素未谋面的网友一起打理这家"硬盘里的公司"。

它可能正在悄悄重新定义"团队"这个词。

没有大张旗鼓的革命，更像一种不动声色的迁移，把人类几百年摸索出来的组织逻辑，一点一点搬进数字世界。分工、部门、角色、流程、质检，这些我们再熟悉不过的东西，正在被写进 Markdown 文件，刻进 JSON 配置，守进自动检查流程。搬过去的不是人，是人"怎么组织"的那套智慧。

凌晨三点的灯还亮着。这家公司永远亮着灯。不因为加班，因为它本来就不需要睡觉。

它的门开着。232 张角色卡躺在里面，等你来挑。