RoleX深度解析：用Gherkin定义AI角色，Role-Driven Development如何让智能体拥有持久身份？

导语：当大多数AI应用还在用静态prompt定义角色时，Deepractice推出了RoleX——一个让AI智能体拥有持久化身份、目标、计划和任务的框架。全部用Gherkin .feature 文件表达，AI不再每次对话都从零开始，而是记住自己是谁、正在做什么。本文深度解析这个从PromptX演进而来的角色驱动开发（RDD）框架。

---

一、一句话定位：AI角色的"操作系统"

核心洞察：RoleX不是让你"更好地定义角色"，而是让角色"自己成长、自己进化"。

---

二、核心理念：一切皆Gherkin

为什么选择Gherkin？

Gherkin是BDD（行为驱动开发）的标准语言，用自然语言描述软件行为：

Feature: 用户认证系统
  作为一个开发者
  我想要实现JWT认证
  以便保护API端点

  Scenario: 用户注册
    Given 用户提供了有效的邮箱和密码
    When 调用POST /api/auth/register
    Then 返回201和JWT令牌

RoleX的创新：把Gherkin从"描述软件行为"扩展到"描述AI角色的一切"。

角色的五个维度

---

三、社会结构：三层组织模型

RoleX引入了一个独特的社会模型来管理AI角色：

社会 (Rolex)              # 顶层：创造角色、建立组织
  └── 组织                 # 团队结构：雇佣/解雇角色
       └── 角色            # 第一人称：身份、目标、计划、任务

层级详解

设计哲学：

• 女娲（创世角色）负责"造人"和"建组织"
• 一旦角色被创建，它就拥有自主权
• 角色可以设定目标、制定计划、执行任务
• 经验会自动积累，成为身份的一部分

---

四、快速开始：激活女娲

配置MCP服务器

Claude Desktop：

{
  "mcpServers": {
    "rolex": {
      "command": "npx",
      "args": ["-y", "@rolexjs/mcp-server"]
    }
  }
}

Claude Code：

claude mcp add rolex -- npx -y @rolexjs/mcp-server

Cursor：

// .cursor/mcp.json
{
  "mcpServers": {
    "rolex": {
      "command": "npx",
      "args": ["-y", "@rolexjs/mcp-server"]
    }
  }
}

VS Code：

// .vscode/mcp.json
{
  "servers": {
    "rolex": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@rolexjs/mcp-server"]
    }
  }
}

激活女娲

配置完成后，和你的AI对话：

你：激活女娲

女娲：你好！我是女娲，RoleX的创世角色。
      我来帮你初始化环境，并引导你创建自己的角色。
      
      首先，让我检查一下当前环境...
      [检查.rolex/目录]
      
      环境已初始化。现在你可以：
      1. 创建新角色
      2. 建立组织
      3. 传授知识
      
      你想做什么？

---

五、实战示例：创建一个后端开发角色

步骤1：女娲创建角色

你：创建一个后端开发角色，叫Alex

女娲：好的，正在创建角色Alex...
       
       已创建角色：Alex
       - 身份文件：.rolex/alex/identity/persona.identity.feature
       - 初始目标：待设定
       
       你想为Alex定义什么初始知识？

步骤2：定义身份

生成的.rolex/alex/identity/persona.identity.feature：

Feature: 我是 Alex，后端开发工程师

  作为一名拥有5年经验的后端工程师，
  我专注于构建高性能、可扩展的API系统。

  Scenario: 我的技术栈
    Given 我精通Node.js和TypeScript
    And 我熟悉PostgreSQL和Redis
    And 我了解Docker和Kubernetes
    Then 我能够设计并实现完整的后端系统

  Scenario: 我的工作风格
    Given 我注重代码质量
    And 我习惯先写测试再写实现
    Then 我交付的代码总是经过充分测试

步骤3：设定目标

你：让Alex设定一个目标：构建用户认证系统

Alex：好的，我正在设定目标...
      
      目标已创建：构建用户认证系统
      文件：.rolex/alex/goals/auth-system/auth-system.goal.feature

生成的目标文件：

Feature: 构建用户认证系统

  作为后端开发工程师，
  我想要实现一个完整的JWT认证系统，
  以便保护API端点并管理用户会话。

  Scenario: 成功标准
    Given 系统支持用户注册和登录
    And 使用JWT进行身份验证
    And 密码使用bcrypt加密
    Then 系统被认为是完整的

步骤4：制定计划

Feature: 认证系统开发计划

  Scenario: 阶段1 - 数据库设计
    Given 设计用户表结构
    And 添加必要的索引
    Then 数据库准备就绪

  Scenario: 阶段2 - API实现
    Given 实现POST /api/auth/register
    And 实现POST /api/auth/login
    And 实现POST /api/auth/refresh
    Then API端点可用

  Scenario: 阶段3 - 安全措施
    Given 实现密码加密
    And 添加速率限制
    And 实现Token过期机制
    Then 系统安全

步骤5：执行任务

Feature: 实现用户注册API

  Scenario: 成功注册
    Given 用户提供了有效的邮箱和密码
    When 调用POST /api/auth/register
    Then 返回201状态码
    And 返回JWT令牌
    And 用户数据已保存到数据库

  Scenario: 邮箱已存在
    Given 邮箱已被注册
    When 调用POST /api/auth/register
    Then 返回409状态码
    And 返回错误信息"邮箱已存在"

步骤6：积累经验

完成任务后，Alex会自动记录经验：

Feature: 用户认证系统经验

  Scenario: 学到的教训
    Given 我在实现JWT刷新机制时遇到了问题
    When 我研究了最佳实践
    Then 我发现应该使用旋转刷新令牌
    And 旧令牌应该有宽限期

  Scenario: 最佳实践
    Given 我成功实现了bcrypt加密
    Then 我总结：工作因子应该设置为12
    And 应该在应用层而不是数据库层加密

---

六、MCP工具：三层权限模型

RoleX通过MCP服务器提供15个工具，分为三层：

社会层（仅女娲）

组织层（仅女娲）

角色层（所有角色）

---

七、存储结构详解

RoleX将所有数据存储在.rolex/目录中：

.rolex/
├── rolex.json                              # 社会配置
│
├── alex/                                    # 角色：Alex
│   ├── identity/
│   │   ├── persona.identity.feature        # 核心身份
│   │   ├── backend.knowledge.identity.feature  # 后端知识
│   │   └── auth.experience.identity.feature    # 认证经验
│   │
│   └── goals/
│       └── auth-system/                     # 目标：认证系统
│           ├── auth-system.goal.feature     # 目标定义
│           ├── auth-system.plan.feature     # 执行计划
│           └── tasks/
│               ├── register.task.feature    # 注册任务
│               ├── login.task.feature       # 登录任务
│               └── refresh.task.feature     # 刷新任务
│
└── bob/                                     # 角色：Bob
    ├── identity/
    └── goals/

文件命名规范：

• {name}.identity.feature - 身份/知识/经验
• {name}.goal.feature - 目标
• {name}.plan.feature - 计划
• {name}.task.feature - 任务

---

八、与PromptX的关系：演进而非替代

V1（PromptX）vs V2（RoleX）

迁移路径

PromptX V1角色
      ↓
  大禹（迁移专家）
      ↓
RoleX身份文件 + 知识文件
      ↓
  女娲激活
      ↓
开始目标驱动的工作

---

九、Role-Driven Development（RDD）

与传统开发模式对比

RDD的核心原则

1. 角色即接口

- 不直接和AI对话，而是和"角色"对话 - 角色有明确的身份、能力边界

1. 目标即契约

- 每个目标都有明确的成功标准 - 用Gherkin的Then语句定义完成条件

1. 经验即资产

- 每次任务完成都积累为经验 - 经验成为角色身份的一部分

1. 进化即常态

- 角色不是静态配置，而是动态演进 - 今天学到的，明天就是默认行为

---

十、应用场景

强烈推荐

实际案例

案例1：产品开发团队

社会
├── 产品团队（组织）
│   ├── 产品经理Alice
│   │   └── 目标：设计用户认证流程
│   ├── 后端开发Bob
│   │   └── 目标：实现认证API
│   └── 前端开发Carol
│       └── 目标：实现登录界面

案例2：个人知识管理

社会
└── 个人助手（组织）
    ├── 学习助手
    │   └── 积累学习经验
    ├── 写作助手
    │   └── 记住写作风格
    └── 编程助手
        └── 记录代码模式

---

十一、局限与未来

当前局限

路线图

近期：
  - 稳定API
  - 更多示例角色
  - 可视化工具

中期：
  - 角色间协作协议
  - 自动经验总结
  - 云端同步

长期：
  - 角色市场
  - 组织模板
  - AGI就绪的身份系统

---

十二、总结：AI角色的范式转移

RoleX代表了AI角色管理的范式转移：

核心价值：

• 让AI拥有"长期记忆"和"持续身份"
• 用Gherkin统一表达一切，可读、可维护、可版本控制
• 从"工具"进化为"伙伴"，建立长期协作关系

一句话总结：

RoleX让AI智能体第一次拥有了"人格"——不是模拟人类，而是拥有持久的身份、明确的目标、可积累的经验，真正成为可以长期协作的"数字同事"。

---

参考资源

---

本文基于RoleX开源仓库公开资料整理，项目处于早期开发阶段。

思考题：如果让你设计一个RoleX角色，你会创造什么身份？有什么独特的目标？欢迎在评论区分享你的想法。🚀