The Agency：用 55 个 Markdown Prompt 搭出 AI Agent 虚拟公司

The Agency 是一个开源 AI Agent 角色库。

它不是一个复杂的运行平台，也不是带任务队列、记忆系统和调度引擎的多 Agent 框架。它的核心非常直接：用一批 Markdown 文件定义不同的专业角色，让 LLM（大语言模型）在执行任务前先进入某个岗位的工作方式。

换句话说，它更像一套“AI 员工手册”。

每个 Agent 都是一份结构化 Prompt，里面描述了这个角色是谁、擅长什么、处理任务时遵循什么流程、输出什么交付物，以及什么样的结果才算合格。把这些内容加载到 Claude Code 或其他 LLM 里，模型就不再只是泛泛回答问题，而是按某个专业角色的标准来工作。

开源地址：

https://github.com/msitarzewski/agency-agents

它解决的不是“模型会不会”，而是“模型按什么方式做”

直接把任务丢给 LLM，经常会遇到三个问题：

The Agency 的做法是把“专家角色”提前写好。

例如一个前端工程师 Agent，不只是写一句“你是前端工程师”，而是会定义它关注 React、Vue、Angular 这些前端技术栈，也会约束它在交付组件时考虑可访问性、状态管理、响应式布局、代码质量和测试方式。

这种角色定义比普通 Prompt 更接近岗位说明书。

一个典型 Agent 文件可以拆成这些部分：

# Agent Name

## Identity
说明这个角色是谁，具备什么专业背景，默认以什么视角思考问题。

## Mission
说明这个角色的核心目标，避免回答跑偏。

## Capabilities
列出角色擅长的任务范围，例如 API 设计、用户研究、性能测试。

## Workflow
定义处理任务的步骤，例如先澄清需求，再给方案，再产出交付物。

## Deliverables
规定输出内容，比如代码、测试清单、设计说明、用户画像、增长实验方案。

## Quality Bar
说明什么样的结果才算合格，用来约束输出质量。

这个结构的价值在于：它把“我要一个专家帮忙”变成了“让模型按照专家的职责和流程完成任务”。

The Agency 的整体结构

The Agency 把 55 个 Agent 分成 9 个部门，覆盖软件项目里常见的工程、设计、市场、产品、测试、支持和专项技术角色。

flowchart TB
    Agency[The Agency<br/>AI Agent 角色库]

    Agency --> Engineering[工程部]
    Agency --> Design[设计部]
    Agency --> Marketing[市场部]
    Agency --> Product[产品部]
    Agency --> PM[项目管理部]
    Agency --> Testing[测试部]
    Agency --> Support[支持部]
    Agency --> Spatial[空间计算部]
    Agency --> Specialized[专门化部]

    Engineering --> FE[前端工程师]
    Engineering --> Backend[后端架构师]
    Engineering --> Mobile[移动端开发]

    Design --> UI[UI 设计师]
    Design --> UX[UX 研究员]
    Design --> Prompt[图片提示词工程师]

    Marketing --> Growth[增长黑客]
    Marketing --> Content[内容创作者]
    Marketing --> Reddit[Reddit 社区建设者]

    Specialized --> Orchestrator[Agents Orchestrator<br/>多 Agent 协调]

这些角色不是简单地按岗位名堆在一起，而是围绕真实任务场景拆分。

这里面有些角色比较常规，比如前端工程师、后端架构师、项目经理；也有一些更偏细分场景的角色，比如 Whimsy Injector。

Whimsy Injector 可以理解为“趣味注入师”。它的职责不是随便给产品加彩蛋，而是判断某个有趣元素是否真的服务于功能或情绪体验。也就是说，惊喜必须增强体验，而不是分散用户注意力。

这种角色就体现出 Agent 设计的关键：好的角色 Prompt 不只是描述“做什么”，还要描述“不应该怎么做”。

单个 Agent 如何影响 LLM 输出

The Agency 的工作方式可以用一个简单流程表示：

flowchart LR
    Task[用户任务] --> Select[选择合适 Agent]
    Select --> Prompt[加载 Agent Markdown]
    Prompt --> LLM[Claude Code 或其他 LLM]
    LLM --> Output[按角色标准输出交付物]
    Output --> Review[人工检查与迭代]

普通提问可能是这样：

帮我写一个 React 表格组件。

加载前端工程师 Agent 后，任务会变成更明确的工作上下文：

你现在以 Frontend Developer Agent 的方式工作。

任务：
构建一个 React 用户列表组件，支持搜索、分页、加载状态和空状态。

技术限制：
- 使用 TypeScript
- 使用函数组件
- 状态管理只用 React hooks
- 样式使用 CSS Modules

交付物：
- 组件代码
- Props 类型定义
- 基本使用示例
- 需要覆盖的测试点

这样做有两个好处。

一是模型更容易按专业流程处理任务。它不会只给一段能跑的代码，还会考虑类型、边界状态、组件 API 和测试点。

二是交付结果更容易复用。团队可以把常用 Agent 固定下来，让同类任务保持接近的输出格式。

多 Agent 协作时，Orchestrator 负责拆任务

The Agency 里比较特殊的角色是 Agents Orchestrator。它不是某个单一专业岗位，而是用来协调多个 Agent。

复杂任务往往不是一个角色能完整处理的。例如“设计并实现一个新用户引导流程”，里面同时涉及产品、UX、UI、前端、测试和增长分析。

可以按这样的方式拆分：

sequenceDiagram
    participant User as 用户
    participant Orchestrator as Agents Orchestrator
    participant Product as 产品 Agent
    participant UX as UX 研究 Agent
    participant UI as UI 设计 Agent
    participant FE as 前端工程师 Agent
    participant QA as 测试 Agent

    User->>Orchestrator: 提出新用户引导需求
    Orchestrator->>Product: 拆解目标、用户价值和功能范围
    Product-->>Orchestrator: 返回需求说明
    Orchestrator->>UX: 分析用户路径和痛点
    UX-->>Orchestrator: 返回用户流程建议
    Orchestrator->>UI: 设计界面结构和视觉表达
    UI-->>Orchestrator: 返回界面方案
    Orchestrator->>FE: 实现 React 组件和交互
    FE-->>Orchestrator: 返回代码与使用说明
    Orchestrator->>QA: 设计测试点和验收清单
    QA-->>Orchestrator: 返回测试方案
    Orchestrator-->>User: 汇总完整交付物

这个流程的重点不是让 AI 完全自动接管项目，而是让每个阶段都有明确的“专家视角”。人仍然需要决定任务边界、检查输出质量，并处理真实业务里的取舍。

在 Claude Code 中使用

Claude Code 是 Anthropic 面向编程场景的命令行工具。The Agency 可以把这些 Agent 文件放到 Claude Code 的 agents 目录中，让 Claude Code 在执行任务时调用对应角色。

基本步骤如下：

git clone https://github.com/msitarzewski/agency-agents.git

mkdir -p ~/.claude/agents

# 根据仓库中的实际目录，把 Agent Markdown 文件复制进去
cp -R agency-agents/path/to/agents/* ~/.claude/agents/

复制完成后，就可以用自然语言指定角色。例如：

让前端开发帮我构建一个 React 搜索组件，要求支持键盘操作、加载状态和空结果提示。

或者：

让后端架构师设计一个用户积分系统的 API，包括数据表、接口路径、权限控制和异常情况。

Claude Code 会根据对应 Agent 的角色设定、工作流程和交付标准来组织回答。

如果某个任务涉及多个角色，可以先让 Orchestrator 拆分工作：

让 Agents Orchestrator 帮我拆解“上线一个邀请返利功能”需要哪些角色参与，
并给出每个角色的输入、输出和验收标准。

不用 Claude Code，也可以当通用 Prompt 模板

The Agency 的本质是 Markdown Prompt，所以它不依赖某个固定运行环境。只要使用的 LLM 支持长上下文，就可以把某个 Agent 文件复制进去，然后追加具体任务。

通用模板可以写成这样：

你现在按照下面的 Agent 定义工作。

<粘贴某个 Agent 的 Markdown 内容>

任务：
为一个面向独立开发者的 SaaS 产品设计首页信息架构。

背景：
- 产品提供自动生成 API 文档的能力
- 用户主要是后端工程师和技术团队负责人
- 希望突出节省维护文档的时间

输出要求：
- 首页模块结构
- 每个模块的核心文案
- 主要 CTA
- 需要避免的表达方式

这种用法适合 ChatGPT、Claude、Gemini 或本地大模型。关键是不要只粘贴角色定义，还要把任务背景、限制条件和交付格式说清楚。

一个完整任务最好包含这些信息：

适合用在哪些场景

The Agency 更适合“需要稳定专家视角”的任务，而不是所有问题都套 Agent。

使用时容易踩的坑

Agent Prompt 不等于真实专家能力

角色定义只能改变模型的工作方式，不能让模型突然掌握它原本不会的事实，也不能保证所有输出都正确。

例如性能基准测试 Agent 可以帮你设计测试方案、整理指标、解释结果，但它不能凭空知道你系统的真实吞吐量。真实性能仍然要靠压测工具、运行环境和监控数据。

Prompt 越长，任务越要具体

Agent 文件本身已经占用一部分上下文。如果任务描述再很模糊，模型容易把大量篇幅花在解释通用原则上。

不推荐这样写：

帮我做一个产品方案。

更好的写法是：

使用 Product Manager Agent。

目标：
为一个面向远程团队的异步站会工具设计 MVP。

限制：
- 开发周期 4 周
- 团队只有 1 名前端、1 名后端
- 不做移动端 App

输出：
- 核心用户
- 主要使用场景
- MVP 功能列表
- 不做的功能
- 4 周版本计划

多 Agent 不要滥用

很多任务一个 Agent 就能完成。强行引入多个角色，会带来额外的上下文消耗，也会让输出变得冗长。

可以按任务复杂度选择：

需要把角色改成自己的工作标准

开源角色库给的是通用设定。真实使用时，最好根据团队习惯修改。

可以补充这些内容：

## Team Constraints
- 前端统一使用 React + TypeScript
- 后端接口遵循 REST 风格
- 所有接口必须考虑权限和审计日志
- 输出代码时必须包含错误处理
- 不允许引入未经批准的新依赖

也可以把交付格式固定下来：

## Output Format
每次输出必须包含：
1. 方案概述
2. 关键取舍
3. 实现步骤
4. 风险点
5. 验收标准

这样 Agent 才会更贴近实际团队，而不是停留在通用专家模板。

一个合理的使用方式

把 The Agency 当成“专家 Prompt 基础库”会更准确。

它适合用来做三件事：

1. 为常见任务建立稳定角色
2. 为不同岗位沉淀工作流程
3. 为 LLM 输出设置清晰交付标准

它不适合被理解成一个已经能独立运营的 AI 公司。真正有价值的用法，是把这些角色接入自己的开发、设计、产品或运营流程中，再根据团队标准持续调整。

当任务需要专业视角时，选择合适的 Agent；当任务足够复杂时，再让 Orchestrator 拆分协作。这样用起来既不会把简单问题复杂化，也能在复杂任务里减少“模型想到哪写到哪”的不确定性。