agency-agents-zh：277 个角色定义文件，还是另一堆提示词模板？
🎭 277 个即插即用的 AI 专家角色 — 支持 Claude Code/Cursor/Copilot 等 20 种工具，覆盖工程/设计/营销/金融等 20 个部门。含 64 个中国市场原创智能体（小红书/抖音/微信/飞书/钉钉/Qt 上位机/机械设计）。搭配编排器 agency-orchestrator，一句话即可让多位专家按 DAG 自动协作。
秒懂
- 它是什么？
- 这个仓库把 277 个 AI 专家角色打包成规则文件，声称能接入 20 种编程工具。真正值得问的是：这些文件到底长什么样，以及它们和普通提示词模板有什么区别。
- 适合谁用？
- 适合的人群是：需要给 Claude Code、Cursor 或 Copilot 快速补充一套中文角色定义，且愿意接受每个角色是一段独立提示词这一事实的开发者。不适合的人群是：期待这些文件能自动完成跨工具调度、或认为角色之间内置了复杂协作逻辑的人。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 1 天前。
- 用什么语言写的？
- 主要是 Shell（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决的问题：角色定义的分发与复用
这个仓库解决的是一个具体问题：把 AI 工具里的角色设定从个人笔记变成可分发的文件。上游 agency-agents 已经做了这件事，这个中文版在此基础上增加了翻译和本地化角色。它面向的用户是那些在 Claude Code、Cursor 或 Copilot 里反复输入相同角色指令的人，与其每次重写，不如直接引用一个文件。仓库声称有 277 个角色，其中 213 个来自英文版翻译，64 个是中国市场原创。这个数字本身不说明质量，但它至少表明覆盖面是刻意的，不是随手凑出来的。
文件机制：每个角色是独立的提示词资产
从仓库布局看，每个智能体都有独立的人设、专业流程和可交付成果，这意味着每个角色大概率是一个独立的规则文件或提示词文件。这种设计的优点是替换成本低，你不喜欢某个角色的输出风格，直接改那一个文件就行。缺点是角色之间没有共享的上下文或记忆机制，每个角色在对话开始时都是白纸一张。仓库描述里明确说这不是通用提示词模板，但这句话需要打折看，因为从外部能观察到的结构就是提示词文件，区别只在于写得是否足够具体。
64 个中国市场的原创角色是真正的差异点
这个仓库相对上游的真正增量是那 64 个原创角色。清单里有小红书、抖音、微信、B站、飞书、钉钉等平台运营，也有跨境电商、政务 ToG、医疗合规、Qt 工业上位机、机械设计这些垂直方向。这些角色有一个共同点：它们对应的是中国特有的平台或行业规范。一个做小红书运营的角色，需要知道平台的内容倾向和违禁词习惯，这类知识在英文开源社区里几乎找不到。对国内用户来说，这批角色是选择这个仓库而不是上游版本的主要理由。不过要注意，角色文件的存在不意味着内容质量有保障，它只说明作者认为这些领域值得覆盖。
接入方式：20 种工具是声称，不是内置能力
仓库声称支持 Claude Code、Cursor、Copilot 等 20 种 AI 编程工具。需要说清楚的是，这个仓库本身不包含安装器或适配层，它提供的是角色定义文件，能不能用取决于你的工具是否支持加载外部规则。例如 Cursor 有 rules 文件机制，Claude Code 有 CLAUDE.md 约定，Copilot 有自己的指令文件格式。这些工具读取规则的方式互不相同，仓库没有提供转换脚本，用户需要自行把角色文件放到工具能识别的位置。README 里提到的 agency-orchestrator 桌面客户端是另一个项目，它声称能免装 Node 直接运行，但这个仓库本身不包含编排逻辑。
真实的限制：提示词资产的保质期与维护成本
这类仓库有一个结构性弱点：提示词会随模型迭代而失效。一个针对 GPT-4 调校的角色设定，在 GPT-5 或 Claude 新版本上可能表现完全不同，因为模型的指令遵循能力变了。仓库的最近一次发布是 v1.2.6，时间在 2026 年 6 月，版本迭代算活跃，但每次更新都意味着维护者需要重新验证 277 个角色是否仍然有效，这是巨大的测试负担。另一个限制是角色之间的协作关系，仓库描述提到编排器能让多位专家按 DAG 自动协作，但这是编排器项目的能力，不是这些角色文件自带的功能。单独使用这个仓库时，每个角色都是孤立的。
替代方案：自己写规则文件与使用官方市场
替代方案不是另一个仓库，而是自己维护规则文件。如果你只需要三到五个角色的中文设定，自己写可能比引用这个仓库更合适，因为你能精确控制指令的细节，也不用担心上游更新破坏你的工作流。另一个方向是使用各工具官方的规则市场或社区分享，例如 Cursor 和 Claude Code 都有官方的规则分享渠道，这些渠道的角色通常经过更多实际使用验证。区别在于：这个仓库提供的是打包好的数量优势，而官方渠道和自写文件提供的是针对性和可控性。如果你的场景高度定制，比如需要角色严格遵守公司内部的某种输出格式，自写文件是更直接的选择。
许可证与采用决策：MIT 的双面含义
仓库使用 MIT 许可证，这意味着你可以自由使用、修改和再分发这些角色文件，包括用于商业目的。这对企业用户是友好的，你不需要担心把角色文件带入公司内部违反许可。但 MIT 许可证也意味着没有担保，角色输出质量、文件与特定工具的兼容性都不在承诺范围内。另外要注意，仓库 README 里有大量赞助商链接和课程推广，这本身不违规，但它提醒你这是一个有商业运营背景的项目，角色的筛选标准可能部分受到商业合作影响。采用前值得确认的是：这些角色文件是否包含指向特定 API 中转服务或模型平台的推荐，如果有，你可能需要评估这些推荐是否影响你的技术选型。
编辑结论
适合的人群是：需要给 Claude Code、Cursor 或 Copilot 快速补充一套中文角色定义，且愿意接受每个角色是一段独立提示词这一事实的开发者。不适合的人群是：期待这些文件能自动完成跨工具调度、或认为角色之间内置了复杂协作逻辑的人。采用前先验证三件事：其一，抽查几个你关心的角色文件，确认其指令深度满足你的场景，例如运营类角色是否包含具体的内容审核规则；其二，确认你的目标工具能读取这些文件，因为仓库本身不包含安装脚本，接入方式取决于各工具对规则文件的支持；其三，检查这些角色定义的更新频率，因为提示词类资产会随模型能力变化而快速过时。这个仓库的价值在于角色数量的覆盖，而非机制创新，它的边界就是提示词本身的边界。
社区笔记