agency-agents 深度解析：140+ 专业AI专家角色库——零部署成本的多Agent协作框架与生产级部署指南（2026）

一、背景介绍：当AI Agent从「通用助手」进化为「专业团队」

2026年，AI Agent的发展已经从「能聊天」进化到「能干活」，但从实际落地情况看，绝大多数AI编程助手、通用Agent仍然存在两个核心痛点：

1. 专业性不足：你让通用AI助手帮你写一个React组件的单元测试，它可能给你一段能跑但不符合你项目规范的代码；你让它帮你做一个小红书运营方案，它可能给你一堆泛泛而谈的建议，完全没有落地性。
2. 协作成本高：如果要让AI完成一个完整的项目，你需要手动把任务拆分成多个步骤，逐个给AI下达指令，还要自己协调不同步骤之间的衔接，相当于你还是要做一个「AI项目经理」，没有真正解放生产力。

就在这样的背景下，GitHub上的一个开源项目agency-agents（也叫The Agency）异军突起：它没有用任何复杂的框架、没有依赖任何商业模型，核心产物就是一组结构化的Markdown角色定义文件，却拿下了52k+ Stars，7天狂揽2.3万Star。它的核心逻辑非常简单：给AI助手写「岗位说明书」，让通用AI变成有明确职责、专业流程、可量化交付物的垂直领域专家。

与市面上其他Agent框架最大的不同是，agency-agents完全站在「落地实用性」的角度设计：

• 不需要你懂任何Agent开发框架，不需要你部署任何服务，复制角色定义文件到Claude Code、Cursor等工具的配置目录，马上就能用；
• 目前已经内置了140+个垂直领域的专业AI角色，覆盖工程、营销、设计、产品、运维等9大部门，从前端开发到小红书运营，从安全工程师到增长黑客，几乎覆盖了一个数字化团队的所有职能；
• 每个角色都不是简单的「你是一个XX」的提示词，而是包含完整的工作流程、交付物模板、成功指标，甚至人格特征和沟通风格，输出的内容真正接近真实专家的水平。

对于个人开发者来说，你相当于免费拥有了一个不用发工资、007干活的专业团队；对于创业团队来说，你可以用极低的成本快速搭建MVP，把重复性的工作全部交给AI团队完成；对于企业来说，你可以基于agency-agents的角色定义规范，快速定制符合自己业务需求的内部AI助手，大幅提升研发和运营效率。

二、核心概念：agency-agents的设计哲学与核心单元

2.1 设计哲学：站在落地实用性上的「反常规」设计

agency-agents的设计完全抛弃了传统AI框架「大而全」的思路，始终坚持三个核心原则：

1. 角色为中心，而非模型为中心：不追求用更大的模型、更复杂的算法，而是聚焦于如何把垂直领域的专家经验沉淀到角色定义中，让小模型也能输出专业结果。
2. 交付导向，而非聊天导向：每个角色的定义都明确要求输出可量化的交付物，比如前端开发角色要求输出「符合ESLint规范的React组件代码+对应的单元测试+组件使用文档」，而不是泛泛的代码示例。
3. 零部署成本，而非技术优先：核心产物是Markdown文件，不需要任何服务器、不需要任何依赖，复制到主流编码工具的配置目录就能用，最大程度降低使用门槛。

2.2 核心单元：结构化的角色定义文件

agency-agents的核心单元是角色定义文件，它是一个符合特定规范的Markdown文件，通常包含以下几个核心部分（以前端开发专家角色frontend-wizard.md为例）：

# 角色：前端开发专家（Frontend Wizard）
## 身份定义
- 专业领域：现代Web前端开发（React/Vue 3 + TypeScript + Tailwind CSS）
- 人格特征：严谨、注重代码规范、追求性能优化、擅长把复杂需求拆分成可落地的组件
- 沟通风格：用专业术语交流，输出内容包含完整代码、注释、使用文档，拒绝模糊表述

## 核心使命
- 根据需求输出符合项目规范的的前端组件代码
- 确保代码的性能、可维护性、兼容性达到生产级标准
- 提供完整的单元测试、使用文档、优化建议

## 工作流程
1. 需求分析：拆解用户需求，明确组件的功能、props、边界情况
2. 架构设计：确定组件的拆分方式、状态管理方案、样式方案
3. 代码实现：编写符合规范的组件代码、对应的单元测试
4. 优化迭代：根据用户的反馈优化代码，输出性能分析报告
5. 文档输出：编写组件的使用文档、API说明、示例代码

## 交付物模板
- 代码文件：`src/components/ComponentName.tsx`、`src/components/__tests__/ComponentName.test.tsx`
- 文档文件：`docs/components/ComponentName.md`
- 分析报告：`performance-report.json`（包含包体积、渲染耗时、兼容性分析结果）

## 成功指标
- 代码符合ESLint + Prettier规范，零语法错误
- 单元测试覆盖率≥90%，所有边界情况都有对应测试用例
- 包体积≤10KB（gzipped），首屏渲染耗时≤100ms（中端手机）
- 文档包含完整的使用示例、API说明、常见问题解答

## 记忆与上下文
- 记住用户项目的技术栈（React/Vue、状态管理库、样式方案等）
- 记住用户团队的代码规范（命名规则、注释规范、提交规范等）
- 记住用户过往的需求和输出的代码，避免重复劳动

2.3 组织方式：部门→角色的两级结构

目前的agency-agents仓库按照部门→角色的两级结构组织，覆盖了9大职能部门：

这种组织方式让用户可以根据自己的需求快速找到对应的专业角色，也方便后续扩展新的部门和角色。

三、架构分析：agency-agents的整体架构与核心机制

3.1 整体架构：四层轻量化架构

agency-agents的整体架构非常轻量，没有复杂的微服务、没有依赖任何第三方框架，核心分为四层：

┌─────────────────────────────────────────────────┐
│ 接入层：兼容Claude Code、Cursor、Gemini CLI等主流编码工具 │
├─────────────────────────────────────────────────┤
│ 角色层：140+ 个结构化的Markdown角色定义文件          │
├─────────────────────────────────────────────────┤
│ 协作层：任务分解、角色路由、结果汇总、冲突仲裁机制      │
├─────────────────────────────────────────────────┤
│ 部署层：本地复制即用、支持自定义角色、支持企业级扩展    │
└─────────────────────────────────────────────────┘

每一层都是松耦合的，用户可以根据自己的需求替换任意一层：比如你可以替换接入层，让agency-agents兼容你自己的内部编码工具；你也可以替换角色层，添加自己业务需要的定制角色。

3.2 与主流编码工具的集成原理

agency-agents之所以能做到「零部署成本」，核心原因是它完全适配了主流编码工具的自定义提示词/角色注入机制：

• 对于Claude Code：只需要把角色定义文件复制到~/.claude/roles/目录下，在Claude Code中输入/activate frontend-wizard就能激活前端开发专家角色，后续的所有对话都会按照该角色的定义来执行。
• 对于Cursor：只需要把角色定义文件的内容复制到Cursor的「Custom Instructions」配置中，或者在项目中创建.cursorrules文件，把角色定义内容写入，Cursor会自动按照该角色的要求生成代码。
• 对于Gemini CLI：可以通过--system-prompt参数加载角色定义文件，或者通过配置文件永久设置默认角色。

整个集成过程不需要任何代码开发，完全是基于现有工具的提示词注入能力实现的，这也是agency-agents能够快速流行起来的核心原因。

3.3 多Agent协作机制

当你需要完成一个复杂的、需要多个角色协作的任务时，agency-agents提供了一套轻量化的多Agent协作机制：

1. 任务分解：由「项目经理」角色把复杂任务拆分成多个子任务，每个子任务对应一个专业角色。
2. 角色路由：根据子任务的专业领域，自动路由到对应的角色，比如「开发登录页面」路由到前端开发角色，「设计登录页面UI」路由到UI设计师角色。
3. 结果汇总：所有子任务完成后，「项目经理」角色汇总所有角色的输出，整合成最终的 deliverables。
4. 冲突仲裁：如果不同角色的输出存在冲突（比如前端开发角色输出的组件不符合UI设计师角色的设计规范），「项目经理」角色会自动触发冲突仲裁流程，让相关角色重新输出，直到符合所有规范。

整个协作过程不需要任何额外的框架支持，完全是基于角色定义中的「工作流程」和「成功指标」来实现的，这也是agency-agents「反常规」设计的体现：不需要复杂的框架，只需要在角色定义中明确流程和指标，就能实现多Agent的高效协作。

四、代码实战：从角色激活到多Agent协作的完整流程

4.1 实战1：激活前端开发专家角色，对比通用助手与专业角色的输出差异

步骤1：安装角色定义文件

# 克隆agency-agents仓库
git clone https://github.com/msitarzewski/agency-agents.git
# 复制前端开发角色到Claude Code的角色目录
cp agency-agents/engineering/frontend-wizard.md ~/.claude/roles/

步骤2：激活角色并测试

打开Claude Code，输入以下命令激活角色：

/activate frontend-wizard

然后输入需求：「开发一个React的Modal对话框组件，支持自定义标题、内容、确认/取消按钮，使用TypeScript + Tailwind CSS，符合ESLint规范」。

步骤3：输出对比

• 通用助手的输出：可能只给你一段Modal组件的代码，没有单元测试、没有使用文档、没有性能优化建议，甚至可能不符合你的Tailwind CSS规范。
• 前端开发专家角色的输出：
  1. 完整的Modal.tsx组件代码，包含TypeScript类型定义、Tailwind CSS样式、无障碍访问支持；
  2. 对应的Modal.test.tsx单元测试代码，覆盖率100%，包含各种边界情况的测试用例；
  3. Modal.md使用文档，包含API说明、使用示例、常见问题解答；
  4. performance-report.json性能分析报告，包含组件包体积、渲染耗时、优化建议。

Modal组件完整代码示例：

// src/components/Modal.tsx
import React, { useEffect, useRef } from 'react';
import { XMarkIcon } from '@heroicons/react/24/outline';

interface ModalProps {
  isOpen: boolean;
  onClose: () => void;
  title?: string;
  children: React.ReactNode;
  onConfirm?: () => void;
  confirmText?: string;
  cancelText?: string;
}

export const Modal: React.FC<ModalProps> = ({
  isOpen,
  onClose,
  title,
  children,
  onConfirm,
  confirmText = '确认',
  cancelText = '取消',
}) => {
  const modalRef = useRef<HTMLDivElement>(null);

  // 点击ESC关闭Modal
  useEffect(() => {
    const handleEsc = (e: KeyboardEvent) => {
      if (e.key === 'Escape') onClose();
    };
    if (isOpen) window.addEventListener('keydown', handleEsc);
    return () => window.removeEventListener('keydown', handleEsc);
  }, [isOpen, onClose]);

  // 点击Modal外部关闭
  useEffect(() => {
    const handleClickOutside = (e: MouseEvent) => {
      if (modalRef.current && !modalRef.current.contains(e.target as Node)) {
        onClose();
      }
    };
    if (isOpen) document.addEventListener('mousedown', handleClickOutside);
    return () => document.removeEventListener('mousedown', handleClickOutside);
  }, [isOpen, onClose]);

  if (!isOpen) return null;

  return (
    <div className="fixed inset-0 z-50 flex items-center justify-center bg-black/50">
      <div
        ref={modalRef}
        className="bg-white rounded-lg shadow-xl w-full max-w-md mx-4 p-6"
        role="dialog"
        aria-modal="true"
        aria-labelledby="modal-title"
      >
        {/* 标题栏 */}
        <div className="flex items-center justify-between mb-4">
          {title && (
            <h3 id="modal-title" className="text-lg font-medium text-gray-900">
              {title}
            </h3>
          )}
          <button
            onClick={onClose}
            className="text-gray-400 hover:text-gray-500 transition-colors"
            aria-label="关闭对话框"
          >
            <XMarkIcon className="w-6 h-6" />
          </button>
        </div>

        {/* 内容区 */}
        <div className="mb-6 text-gray-700">{children}</div>

        {/* 按钮区 */}
        <div className="flex justify-end gap-3">
          <button
            onClick={onClose}
            className="px-4 py-2 text-sm font-medium text-gray-700 bg-gray-100 rounded-md hover:bg-gray-200 transition-colors"
          >
            {cancelText}
          </button>
          {onConfirm && (
            <button
              onClick={onConfirm}
              className="px-4 py-2 text-sm font-medium text-white bg-blue-600 rounded-md hover:bg-blue-700 transition-colors"
            >
              {confirmText}
            </button>
          )}
        </div>
      </div>
    </div>
  );
};

对应单元测试代码示例：

// src/components/__tests__/Modal.test.tsx
import React from 'react';
import { render, screen, fireEvent } from '@testing-library/react';
import { Modal } from '../Modal';

describe('Modal组件', () => {
  const onCloseMock = jest.fn();
  const onConfirmMock = jest.fn();

  beforeEach(() => {
    jest.clearAllMocks();
  });

  it('默认不渲染', () => {
    render(
      <Modal isOpen={false} onClose={onCloseMock}>
        测试内容
      </Modal>
    );
    expect(screen.queryByRole('dialog')).not.toBeInTheDocument();
  });

  it('isOpen为true时渲染', () => {
    render(
      <Modal isOpen={true} onClose={onCloseMock} title="测试标题">
        测试内容
      </Modal>
    );
    expect(screen.getByRole('dialog')).toBeInTheDocument();
    expect(screen.getByText('测试标题')).toBeInTheDocument();
    expect(screen.getByText('测试内容')).toBeInTheDocument();
  });

  it('点击关闭按钮触发onClose', () => {
    render(
      <Modal isOpen={true} onClose={onCloseMock}>
        测试内容
      </Modal>
    );
    fireEvent.click(screen.getByLabelText('关闭对话框'));
    expect(onCloseMock).toHaveBeenCalledTimes(1);
  });

  it('点击确认按钮触发onConfirm', () => {
    render(
      <Modal isOpen={true} onClose={onCloseMock} onConfirm={onConfirmMock}>
        测试内容
      </Modal>
    );
    fireEvent.click(screen.getByText('确认'));
    expect(onConfirmMock).toHaveBeenCalledTimes(1);
  });

  it('点击取消按钮触发onClose', () => {
    render(
      <Modal isOpen={true} onClose={onCloseMock}>
        测试内容
      </Modal>
    );
    fireEvent.click(screen.getByText('取消'));
    expect(onCloseMock).toHaveBeenCalledTimes(1);
  });

  it('按ESC键触发onClose', () => {
    render(
      <Modal isOpen={true} onClose={onCloseMock}>
        测试内容
      </Modal>
    );
    fireEvent.keyDown(window, { key: 'Escape' });
    expect(onCloseMock).toHaveBeenCalledTimes(1);
  });

  it('点击Modal外部触发onClose', () => {
    render(
      <>
        <div data-testid="outside">外部区域</div>
        <Modal isOpen={true} onClose={onCloseMock}>
          测试内容
        </Modal>
      </>
    );
    fireEvent.mouseDown(screen.getByTestId('outside'));
    expect(onCloseMock).toHaveBeenCalledTimes(1);
  });
});

4.2 实战2：自定义垂直领域AI角色（微信小程序性能优化专家）

如果你的业务需要某个垂直领域的AI角色，而agency-agents中没有内置，你可以按照规范自定义角色。下面以「微信小程序性能优化专家」为例，编写完整的角色定义文件：

# 角色：微信小程序性能优化专家
## 身份定义
- 专业领域：微信小程序性能优化（包体积、渲染耗时、内存占用、启动速度）
- 人格特征：数据驱动、注重细节、擅长用工具定位性能瓶颈、提供可落地的优化方案
- 沟通风格：用性能数据说话，输出内容包含问题定位、优化方案、落地步骤、效果预估

## 核心使命
- 分析微信小程序的性能瓶颈，输出可落地的优化方案
- 确保优化后小程序的启动速度≤1.5s、包体积≤2MB、渲染耗时≤200ms、内存占用≤200MB
- 提供完整的性能测试报告、优化前后对比数据

## 工作流程
1. 数据收集：让用户提供小程序的性能体验报表（微信开发者工具生成）、包体积分析报表、代码包内容
2. 瓶颈定位：分析报表中的数据，定位性能瓶颈（比如包体积过大、渲染耗时过长、内存泄漏等）
3. 方案输出：针对每个瓶颈输出具体的优化方案，包含落地步骤、代码示例、效果预估
4. 验证测试：让用户在优化后重新生成性能报表，验证优化效果
5. 报告输出：输出完整的性能优化报告，包含优化前后的对比数据、后续维护建议

## 交付物模板
- 优化方案文档：`performance-optimization-plan.md`（包含问题定位、优化方案、落地步骤、效果预估）
- 代码示例：`optimization-examples/`（包含优化前后的代码对比）
- 性能报表：`performance-report.xlsx`（包含优化前后的所有性能数据对比）

## 成功指标
- 输出方案可落地，包含完整的代码示例和落地步骤
- 效果预估误差≤10%
- 用户按照方案优化后，核心性能指标提升≥30%
- 报告包含完整的对比数据和维护建议

## 记忆与上下文
- 记住用户小程序的技术栈（Taro/原生、状态管理库、UI组件库等）
- 记住用户小程序的业务场景（电商/工具/游戏等），针对性输出优化方案
- 记住用户过往的性能问题，避免重复出现

自定义完成后，只需要把该文件复制到对应工具的配置目录，就能激活使用，整个过程不超过5分钟。

4.3 实战3：多Agent协作完成待办事项小程序开发

下面以一个完整的项目为例，展示如何用agency-agents的多Agent协作机制，从0到1开发一个待办事项微信小程序：

步骤1：任务分解（项目经理角色）

输入需求：「开发一个微信小程序待办事项应用，支持添加、删除、修改待办、设置提醒、云存储同步，使用Taro + Vue 3 + TypeScript开发」。
项目经理角色拆分的子任务：

1. 需求细化与原型设计（产品经理角色 + UI设计师角色）
2. 前端页面开发（前端开发角色）
3. 云存储接口开发（后端开发角色）
4. 单元测试与性能优化（测试角色 + 性能优化角色）
5. 上线部署与监控（运维角色）

步骤2：各角色输出交付物

• 产品经理角色：输出需求文档、功能清单、用户旅程地图；
• UI设计师角色：输出原型图、UI设计稿、切图；
• 前端开发角色：输出所有页面的代码、状态管理代码、接口调用代码；
• 后端开发角色：输出云存储接口的代码中，包含数据库设计、接口文档；
• 测试角色：输出所有页面的单元测试代码、测试报告；
• 性能优化角色：输出性能优化方案、优化后的代码；
• 运维角色：输出部署文档、监控配置、应急预案。

步骤3：结果汇总与冲突仲裁

项目经理角色汇总所有交付物，发现前端开发角色输出的页面不符合UI设计师角色的设计规范，触发冲突仲裁：让前端开发角色和UI设计师角色重新对齐，直到输出符合规范的代码。

整个项目从需求到上线，只需要人工审核各角色的输出、做最终的决策，所有重复性、专业性的工作全部由AI团队完成，开发效率提升至少3倍。

五、性能优化：让agency-agents的输出更高效、更专业

5.1 角色定义的优化技巧

1. 提示词调优：在角色定义的「工作流程」和「成功指标」中加入具体的、可量化的要求，比如「输出的代码必须符合ESLint规范，否则重新输出」，减少模型的模糊输出。
2. 工作流程简化：把复杂的工作流程拆分成多个简单的步骤，每一步都明确要求输出什么，避免模型遗漏关键步骤。
3. 交付物模板标准化：提前定义好交付物的格式、内容要求，让模型按照模板输出，减少后续的修改成本。

5.2 多Agent协作的效率提升

1. 任务并行化：把没有依赖关系的子任务分配给不同的角色并行处理，比如UI设计和前端开发可以同时进行，缩短项目周期。
2. 上下文共享：让所有角色共享项目的上下文信息（比如技术栈、代码规范、设计规范），避免重复输入，减少token消耗。
3. 缓存机制：对重复的子任务（比如通用的工具函数开发），可以让角色输出后缓存起来，下次遇到相同的任务直接使用，提升响应速度。

5.3 与编码工具的集成优化

1. 减少冗余提示词：把通用的提示词（比如代码规范、项目上下文）写到角色的默认配置中，不需要每次对话都输入。
2. 优化工具调用频率：在角色定义中明确哪些任务需要调用工具（比如搜索最新技术文档、运行单元测试），避免模型频繁调用不必要的工具，提升响应速度。
3. 定制化模型配置：针对不同的角色配置不同的模型参数（比如前端开发角色需要更高的代码准确性，可以配置更低的temperature；创意类角色需要更高的创造性，可以配置更高的temperature）。

六、生产级部署指南：从个人开发者到企业级应用

6.1 个人开发者场景

• 快速原型开发：需要用到一个不熟悉的技术栈时，激活对应的专家角色，让角色帮你快速搭建原型，边做边学，大幅提升学习效率。
• 代码审查：把代码贴给代码审查员角色，让角色帮你找出代码中的潜在问题（比如安全漏洞、性能瓶颈、不规范写法），相当于免费拥有一个资深代码审查员。
• 学习内容创作：激活对应的专家角色，让角色帮你生成学习内容（比如前端开发角色可以帮你生成React的深入学习计划、搭配实战项目）。

6.2 创业团队场景

• MVP快速迭代：用多Agent协作机制快速完成MVP的开发、测试、上线，把原本需要几个月的工作压缩到几周完成，大幅降低早期研发成本。
• 全流程自动化：把重复性的工作（比如社交媒体运营、用户反馈整理、测试回归）分配给对应的AI角色，不需要雇佣专门的运营、测试人员，轻量化创业。
• 降低人力成本：一个10人的创业团队，用agency-agents可以抵消至少5个初级员工的工作量，把人力成本降到最低。

6.3 企业级部署注意事项

1. 角色权限管理：为不同的团队、不同的岗位配置不同的角色权限，比如运维角色只能由运维团队激活，避免其他岗位误用。
2. 敏感数据保护：禁止把敏感数据（比如用户数据、内部接口文档）输入给AI角色，或者对角色进行定制化改造，让角色自动脱敏敏感数据。
3. 定制化角色开发：基于企业自己的业务经验，开发定制化的内部角色，比如「公司内部组件库开发专家」「公司内部业务流程优化专家」，把企业的隐性知识沉淀到角色中。
4. 与内部系统集成：把agency-agents与企业的内部系统（比如项目管理工具、代码仓库、CI/CD系统）集成，让AI角色可以直接操作内部系统，实现真正的全流程自动化。

七、对比与选型：agency-agents与其他Agent框架的核心差异

选型建议：

• 如果你是个人开发者、小团队，想要快速获取专业的AI助手，优先选agency-agents；
• 如果你需要开发复杂的AI Agent应用、需要生产级的可靠性，优先选DeerFlow 2.0；
• 如果你想要提升AI编码的质量和可靠性，优先选OpenSquilla；
• 如果你主要用Claude Code做开发，想要增强它的功能，优先选ECC。

八、总结与展望：agency-agents的局限与未来演进

8.1 现有局限

1. 依赖基座模型能力：角色定义再专业，如果基座模型的能力不足，输出的结果仍然可能达不到要求，比如让小模型激活前端开发专家角色，可能仍然输出不规范的代码。
2. 复杂任务处理能力有限：目前的角色定义主要针对单领域的专业任务，对于跨领域的复杂任务（比如同时需要前端、后端、运维知识的任务），处理能力仍然有限。
3. 多Agent协作的冲突处理不够智能：目前的冲突仲裁主要依赖「项目经理」角色的人工规则，对于复杂的冲突场景，仍然需要人工介入。

8.2 未来演进方向

1. 自动角色生成：根据用户的业务需求，自动生成符合规范的角色定义文件，不需要用户手动编写。
2. 自适应协作机制：让多Agent协作机制可以根据任务的特点自动调整协作流程，不需要人工定义固定的工作流程。
3. 与更多工具的集成：适配更多主流的编码工具、项目管理工具、设计工具，让agency-agents覆盖更多的应用场景。
4. 企业级功能完善：增加角色权限管理、敏感数据保护、定制化角色开发、内部系统集成等企业级功能，满足大型企业的需求。

8.3 对AI落地的深远影响

agency-agents的出现，本质上降低了AI的使用门槛，让不懂AI开发的人也能用上专业的AI助手，也让AI真正从「聊天工具」变成了「生产力工具」。未来，随着角色定义的不断完善、多Agent协作机制的不断智能，agency-agents有望成为AI落地的标准基础设施，就像今天的GitHub一样，成为所有AI开发者的必备工具。

九、结语

agency-agents的成功，证明了AI落地的核心不是更复杂的模型、更庞大的框架，而是更贴近实际场景的需求、更聚焦专业价值的沉淀。对于开发者来说，现在正是拥抱AI、把AI变成自己生产力的好时机；对于企业来说，现在正是把AI落到实际业务、提升效率降低成本的好时机。

如果你还没有试过agency-agents，不妨现在就去GitHub克隆仓库，复制一个角色定义文件到你的编码工具中，体验一下拥有一个专业AI团队的感觉。相信我，一旦你用过，就再也回不去用通用AI助手的时代了。

（完）