Agency-Agents:用结构化「职业操作系统」替代临时 Prompt 的 AI 角色仓库
Agency-Agents:用结构化「职业操作系统」替代临时 Prompt 的 AI 角色仓库
项目定位:不是框架,是 AI 工具的岗位说明书基建
agency-agents 是一个由 msitarzewski 发起、起源于 Reddit 帖子的开源项目,本质是一批结构化 Markdown 角色定义文件的集合——截至目前已达到 400+ 个 Agent、16+ 个部门、126K+ Stars。
要理解这件事处于什么阶段,必须先定位它的参照系:这不是 LangChain、AutoGen 这类 Agent 编排框架,也不是简单的 Prompt 模板库。它的位置,恰好夹在两者之间——它不解决 Agent 之间如何调用的工程问题,它解决的是**"AI 是谁、按什么标准工作、交付什么"这个前置问题**。2024 年后 AI 编程工具(Claude Code、Cursor、Codex 等)集中爆发,工具能力到了,但大量用户仍然每次都在临时描述"你现在是一个前端工程师……"——这个"如何用"的断层,就是这个项目踩中的真正需求。
最核心的机制:持久化职业操作系统 vs. 一次性角色扮演
项目真正精妙的设计在于一个简单但高密度的数据结构。每个 Agent 文件包含四层:
---
# 身份定义(Identity)
name: Frontend Developer
persona: 精确的人格特征与沟通风格
---
# 工作流(Workflow)
标准操作步骤(SOPs)
# 交付物模板(Deliverables)
输出格式规范,带代码示例
# 成功指标(Success Metrics)
具体 KPI,如 Core Web Vitals 分数 / PR 通过率
相比直接写 Prompt,这不是"让 AI 临时扮演一个角色",而是"给 AI 装一套可复用的职业操作系统"。一旦安装到 ~/.claude/agents/ 目录,每次只需一句"激活前端开发模式",AI 就按预设的人设、流程、交付标准工作,不需要每次重新建立上下文。
相比 LangChain / AutoGen 等重型框架,它的优势在于零编程门槛——复制一个 Markdown 文件就完成部署,可以在不同工具间共享同一份定义(通过 convert.sh 自动转换格式),维护成本极低。但它牺牲了 Agent 间的自动化协作能力:A Agent 无法主动调用 B Agent,多 Agent 编排仍需人工介入。
安装与使用示例
最快路径:一行命令装进 Claude Code
# macOS 用 Homebrew 安装桌面管理 App
brew install --cask msitarzewski/agency-agents/agency-agents
# 或命令行只装工程师团队
./scripts/install.sh --tool claude-code --division engineering
# 按需精确安装
./scripts/install.sh --tool cursor --agent frontend-developer,ui-designer
# 预览不真正写入
./scripts/install.sh --tool opencode --division engineering --dry-run
安装后在 Claude Code 会话中直接激活:
# 在对话中输入:
"Hey Claude, activate Frontend Developer mode and help me refactor this React component."
已覆盖的 16 个部门(节选)
| 部门 | 代表 Agent | 典型场景 |
|---|---|---|
| Engineering | Frontend Developer, SRE, Incident Response Commander | 开发、运维、事故管理 |
| Security | 威胁建模、渗透测试 | 代码安全审查 |
| Marketing | 小红书运营、B站内容策略 | 中文社媒内容创作 |
| Data | Data Engineer, AI Data Remediation Engineer | 数据管道、自愈系统 |
交叉验证:其他信源怎么看这个项目?
信源一:CSDN「CooVally_AI」技术博客(2026.03)
这篇文章对项目持认同态度,并独立提炼出一个判断——"AI 编程工具的瓶颈已从模型能力转移到如何引导模型按专业流程工作"——这与原始 README 的叙事高度吻合。该信源补充了一个原文未明说的观点:一个好的角色定义文件,在特定任务上的提升效果,可能超过换用更大的模型。这是对原文价值主张的独立强化,而非转述。
信源二:百家号技术文章(2026.06)
这篇文章提供了更多局限性的具体细节,并补充了一个原文中仅以 bug 链接一笔带过的问题:OpenCode 运行时限制约 119 个 Agent,超出部分会被静默丢弃,这是一个非常实际的陷阱,对于想完整使用 400+ Agent 的用户来说尤为关键。同时该文也明确指出"232 个 Agent 定义全是英文,中文团队接入存在适应成本"——这个观察原文完全回避,但对国内用户是真实摩擦点。
两个信源均认同项目的核心定位,但相比 README 的推销口吻,第三方信源都不约而同地强调了质量参差不齐这一事实:400+ Agent 无法逐一精细打磨,CI 流程只能校验格式,业务效果只能使用者自己验证。
边界与局限:不适用的场景
局限在于以下几点,不能忽略:
-
效果上限取决于工具的 Agent 实现质量:Agent 文件本身没有任何执行逻辑,它只是一个上下文注入机制。在 Claude Code 里的体验与在 Cursor 里用,差异可能很大——这高度依赖目标工具对
CLAUDE.md/ agents 目录的解析深度。 -
OpenCode 硬性上限 119 个:完整安装 400+ Agent 在 OpenCode 里是无效的,必须用
--division精选。 -
多 Agent 自动化协作仍是空白:如果你的目标是让 Frontend Agent 自动把任务交给 Code Reviewer Agent,这个项目给不了。它的协作是"人工串联"模式,而非自动编排。
-
并非适用于所有场景:如果日常只用 AI 做代码补全(inline completion),从不使用 Agent 模式对话,这个项目对你毫无价值。
-
质量参差:400+ Agent 中,"Solidity Smart Contract Engineer""WeChat Mini Program Developer"这类高度垂直的专业角色,其工作流程是否真的经过业内专家验证,是存疑的。使用前应先阅读原始 Markdown 文件自行判断。
推演:这件事接下来会怎样
这意味着 "AI 工具的 Prompt 工程"正在经历一次基础设施化——从个人私藏的 prompt.txt 文件,走向可版本控制、可共享安装、可 CI 校验的标准化资产。这个趋势是不可逆的,因为它降低的是使用门槛,而不是增加约束。
接下来可以合理预判的方向:一是主流 AI 编程工具会逐步内置 Agent 市场(类似 VS Code 的扩展商店),agency-agents 这类项目很可能成为早期的内容供应商;二是随着 Agent 数量继续膨胀,质量筛选机制(社区评分、下载量加权)会成为比"数量多"更核心的竞争力。目前项目缺少的恰好是这个——400+ Agent 没有质量排行,新用户无法快速找到"最可靠的那 10 个"。
个人启发:该怎么具体用
对个人开发者:不要试图安装全部 400+ Agent,这会制造噪音。正确做法是:进 engineering/ 目录,挑 3-5 个你最高频的场景(如 code-reviewer、senior-developer、database-optimizer),阅读原始 Markdown,按自己团队的实际标准做定制修改后再安装。把它当作角色设计的最佳实践参考,而非拿来即用的黑盒。
对团队技术负责人:这个项目提供了一套可以 Fork、版本控制、团队共享的 AI 工作规范载体。真正的价值不是里面现成的 Agent,而是这套 Markdown 格式本身——你可以用它来沉淀团队内部的 AI 辅助标准 SOP,进 git,做 PR,久而久之形成团队的"AI 操作手册"。
对决策者:将其视为一个"AI 工具投资回报率"的放大器,而非独立工具。它不能替代 Claude Code 或 Cursor,但能让你已经购买的 AI 工具发挥出更稳定的专业水准。
延伸思考
-
Agent 定义标准化会不会走向 OpenAPI 规范式的社区治理? 目前 agency-agents 是单一仓库、单一维护者主导的,但随着规模扩大,类似"OpenAPI Initiative"那样的中立社区协作模式是否会出现?谁来定义 "Frontend Developer Agent" 的通用接口规范?
-
"角色注入"与"Fine-tuning"的边界在哪里? 这个项目本质上是通过上下文注入来改变模型行为,但随着 LoRA 等轻量微调成本持续下降,未来会不会有"直接微调一个专注代码审查的小模型"来彻底替代 Prompt 角色注入?两种路径各自的适用边界是什么?
-
当 AI 工具原生集成 Agent 市场后,这类开源仓库的护城河在哪里? Anthropic 已经开始建设官方的 Claude Agent 技能仓库,如果平台方直接提供更高质量的官方 Agent,agency-agents 这类社区项目的差异化价值将如何维持?
📚 参考来源
openEuler 是由开放原子开源基金会孵化的全场景开源操作系统项目,面向数字基础设施四大核心场景(服务器、云计算、边缘计算、嵌入式),全面支持 ARM、x86、RISC-V、loongArch、PowerPC、SW-64 等多样性计算架构
更多推荐


所有评论(0)