headcount：172个技能装进公司组织架构，中文版README来了

当保存的提示词超过三十条，混乱就开始了。你会忘记自己有什么，两条提示词干着几乎相同的事却分不清哪条是最新的，懒得翻找时干脆往会话里粘贴一整条"巨型提示词"，其中一半内容和当前任务毫无关系。

headcount 是针对这个问题的回答。它把智能体技能按公司结构组织起来：一位首席执行官，16个部门，172项技能。每个部门作为独立插件安装，项目只加载自己需要的部分。技能以 department:skill 形式寻址，跨部门名称不会冲突。

原仓库是 cbrock84/headcount，2047 颗星，Markdown 编写，MIT 许可。中文翻译版 README 现已发布在 yangshun2005/headcount-cn。本文主要讨论后者，因为它的翻译做了一件普通翻译通常不会做的事。

headcount 到底是什么

官方一句话介绍：一个按公司结构组织的智能体组织——15+ 部门，125+ 技能，每个可独立安装，并引用了裁决该问题的标准与监管机构。运行于 Claude Code 和 ChatGPT。

README 自己的数字是 16 个部门和 172 项技能。一句话介绍说的是 15+ 和 125+。两个数字都出现在原材料中，这里不做调和，也不该假定较小的数字就是过时的——README 里的部门表格是更细粒度的来源。

结构思路是值得理解的部分。多数提示词库是一张平铺列表，headcount 是一棵树，每个分支上都有安装边界。CEO 办公室位于顶部，带 7 项技能，下面的各部门各自携带自己的技能，并在 .claude/agents/ 中附带一份智能体章程。章程让部门可以被作为子智能体委派，拥有自己专属的写入范围——即 agent-hierarchy 技能描述的"生产者/审计者"分离。

寻址是带命名空间的。security:threat-modeling、finance:unit-economics、demand-generation:landing-page-cro-expert。你可以用自然语言提问，让匹配机制加载技能；也可以在需要特定视角时按名称调用：

/finance:financial-modeling

关于 .claude/agents/ 与智能体章程：在 Claude Code 的约定中，.claude/agents/ 目录用于存放子智能体（subagent）定义文件，每个文件声明一个可被主智能体委派的角色，包含其职责描述、可用工具集和权限边界。headcount 把每个部门落到这个目录下，等于把一个 Markdown 写的“专家人设”注册成了可编程调用的执行单元。所谓“生产者/审计者”分离，指的是同一任务由两个写入范围互不重叠的智能体分别执行与复核，审计者只能读取生产者的产出而不能改写它，从机制上降低自证正确的风险。这也是为什么部门不只是提示词集合——它同时携带了权限声明，这层权限由宿主工具（Claude Code 或 Codex）强制执行，而非依赖模型自觉遵守。理解这一点，才能明白为什么“按部门安装”既是上下文预算问题，也是权限隔离问题。

安装方式，以及决定一切的那个约束

Claude Code 下的安装命令：

/plugin marketplace add cbrock84/headcount
/plugin install security@headcount

然后按需添加部门——/plugin install it-operations@headcount，依此类推。

ChatGPT 和 Codex 使用同一仓库。你把它添加为插件市场（ChatGPT 读取 .agents/plugins/marketplace.json 下的清单），或者把想要的部门复制到自己项目的 .agents/skills/ 目录。技能文件在两端完全相同，只有清单文件不同，而两个清单都从同一目录树生成——所以一处修复会同时落地到两边。这正是 AGENTS.md 的作用。

下面这个约束解释了整个设计。在 ChatGPT/Codex 侧，技能描述共享约 8000 字符的上下文预算。16 个部门加起来大约 50000 字符。只安装实际会用到的部门不是洁癖——这是唯一能塞得下的方式。如果你曾疑惑为什么插件系统要费心做按部门粒度划分、而不是一次性大安装，这个比例就是答案。

安装部门不会动你的项目。它给助手添加技能，不向你的仓库写入内容，不添加依赖，也不会自行运行任何东西。

关于 8000 字符技能描述预算：Claude Code、ChatGPT 插件与 Codex 在会话启动时，会把所有已加载技能的名称与描述注入系统上下文，供模型判断何时触发。这部分内容常驻且无法按需卸载，因此构成硬性预算。以英文描述平均每条约 40–60 字符估算，8000 字符大致只够容纳 100–200 条精简描述；若部门描述写得详细，容量会迅速收缩。16 个部门合计约 50000 字符，意味着一次性全装会超出预算数倍，模型要么截断接收、要么直接拒绝加载，两种结果都会让触发机制失效——你以为装了 172 项技能，实际生效的可能只有零头。按部门安装因此不是风格选择，而是让系统保持在可运行区间的必要操作。同样的逻辑也适用于其他插件生态：凡是把元数据常驻进上下文的系统，最终都会演化出按需加载的边界。

中文版额外带来了什么

中文仓库是原 README 的翻译，日期为 2026-10-14，原始版本保留为 README_en.md。截至撰写时，星数为零——它今天刚发布，没必要假装不是。

有趣之处在于它不只是翻译。页面带有两个明确分离的层次：

• 顶部的中文快速上手部分，明确标注为补充性导览材料，不属于原文。它回答中文开发者前五分钟会遇到的问题：这解决什么问题，最短运行路径是什么，有什么要求，有哪些坑。
• 下方的翻译版 README 正文，页面声明力求忠实原文。

这个拆分比听起来更重要。忠实翻译 headcount 的 README 能给你部门表格和安装命令，但不会告诉你 ChatGPT 侧 8000 字符预算正是应该装两个部门而非十六个的原因。原 README 确实提到了预算——但它埋在一个你只有先形成错误心智模型之后才会读到的章节里。中文页面把它提前拉到了导览部分，同时附注了"安装部门不会修改你的仓库"，以及"原文未说明操作系统、硬件或版本要求"。

最后这一点是一个值得指出的小诚实信号。很多翻译版 README 会悄悄用听起来合理的需求填补空白。这一版写的是"原文未说明"，然后继续。国内网络部分也是如此：它说原文未提及镜像或加速下载，而不是编造一个可能不存在的镜像。

对中文开发者来说，实际差异在于入门成本。安装路径是三条命令加一个自然语言问题，导览部分让你无需用第二语言读完整个 README 就能到达那里。department:skill 寻址方案、自动加载行为、"应该先装哪些部门"，都在翻译正文开始前就有了答案。

页面还邀请对翻译不准确之处提 issue 或 PR，这对一份会随上游变化而漂移的翻译文档来说是正确姿态。

关于插件市场清单（marketplace manifest）：marketplace.json 是宿主工具识别“上哪里、按什么名字装插件”的索引文件，通常声明插件名、来源仓库、版本与包含的目录。headcount 的巧妙之处在于，同一棵技能目录树生成了两份清单——一份给 Claude Code，一份给 ChatGPT/Codex（位于 .agents/plugins/marketplace.json）。技能文件本身不做任何改动，只有索引格式因平台而异。这种“单一数据源、多目标清单”的做法，避免了分叉维护常见的版本漂移：修一处技能描述，两边清单指向的文件同时更新。AGENTS.md 在这种架构里承担的是跨平台一致性说明的角色，相当于告诉任何读取它的工具“技能在哪、怎么装、注意什么”。如果你的团队同时使用多个智能体平台，这个清单生成模式比手工同步更值得借鉴。

真正值得评估的部分

技能本身是散文。Markdown 文件描述专家应如何应对问题。security:threat-modeling 是否产出有用结果，取决于你运行它的模型和你的系统具体情况，我并没有拿真实的威胁模型测试过。我的样本量是零。把部门表格当作覆盖范围的地图，而不是产出质量的证据。

可验证的是结构。带命名空间的寻址防止冲突。按部门的安装边界尊重真实的上下文限制。智能体章程在委派时给部门专属写入范围。还有一层文档，在没有重写源文件的前提下，为第二类受众做了可导航化。

如果你有一个已经失控的平铺提示词文件夹，安装很便宜也可逆——添加一个市场，装一个部门，看看匹配机制是否真的会在你的问题上触发。如果你读中文，从中文页面开始；导览部分是最快抵达可用配置的路径。如果不读，原 README 和 docs/GETTING-STARTED.md 覆盖了同样内容。

有一点需要注意：中文仓库是翻译版，所以它会滞后跟踪上游。翻译日期是 2026-10-14。如果原仓库在那之后新增部门，中文页面要等人更新才会有。

中文文档：https://github.com/yangshun2005/headcount-cn

作者是独立企业 AI 交付顾问——私有 LLM 部署、RAG、智能体工作流、AIOps。