Twenty AI 原生 CRM 架构解析：元数据驱动模型与权限设计

引言

在 CRM 领域，Salesforce 长期占据主导地位，但其封闭性和高昂的定制成本让中小企业望而却步。Twenty 作为开源 AI 原生 CRM 的新锐项目，以「可定制的数据模型」和「AI 原生架构」为核心卖点，试图打破这一局面。本文将从技术架构视角，深入解析 Twenty 的数据模型设计、权限控制机制，以及 AI 能力的原生集成方案。

元数据驱动的数据模型

传统 CRM 通常将数据模型固化在代码层，Leads、Contacts、Deals 等实体关系预先定义，用户只能在有限范围内扩展字段。Twenty 采用了完全不同的思路：元数据驱动（Metadata-Driven） 架构。

在 Twenty 的实现中，CRM 对象并非硬编码的表结构，而是通过元数据表动态定义。用户可以在界面上创建自定义对象（Custom Objects），定义字段类型（文本、数字、日期、关联等），系统会自动在 PostgreSQL 中生成对应的物理表结构。这种设计的核心优势在于：

• Schema 随业务演进：销售流程调整时，无需开发人员修改代码和迁移数据库，业务人员可直接在界面上调整对象结构
• 多租户隔离：每个工作空间（Workspace）拥有独立的元数据定义，互不影响
• 类型安全：底层使用 TypeScript + NestJS，配合 ORM 确保动态生成的表结构仍有类型约束

技术实现上，Twenty 维护了一套元数据注册表，记录对象定义、字段类型、关联关系等信息。当用户查询数据时，系统根据元数据动态构建 SQL 查询，而非依赖固定的表结构。这种设计与 Salesforce 的「平台即服务」理念异曲同工，但以开源方式交付。

三层权限架构设计

权限控制是 CRM 系统的核心能力。Twenty 的权限架构采用三层表设计：permissionSet、permissionSetAssignment 和 objectPermissions。

权限集（Permission Set）

Permission Set 是权限的容器，定义了一组可授予用户的权限规则。与传统 RBAC 模型不同，Twenty 允许一个用户拥有多个 Permission Set，权限之间可以叠加，提供更灵活的授权方式。

权限分配（Permission Set Assignment）

中间表 permissionSetAssignment 建立用户与权限集的多对多关系。这种设计支持临时授权场景，例如项目经理在特定时间段内获得额外数据访问权限。

对象权限（Object Permissions）

objectPermissions 表定义了针对具体 CRM 对象的访问控制，支持四种操作类型：

• Read：查看对象记录
• Create：创建新记录
• Edit：修改现有记录
• Delete：删除记录

目前 Twenty 已实现对象级权限（Object-Level Permissions），即控制用户能否访问某个对象类型。根据项目路线图，字段级权限（Field-Level Permissions）正在开发中，而行级权限（Row-Level Security）暂未列入近期计划。

对于需要行级数据隔离的场景（例如销售只能看到自己的客户），当前版本需要通过应用层过滤实现，或借助 PostgreSQL 的 RLS（Row-Level Security）功能在数据库层补充控制。

AI 原生能力的技术实现

Twenty 的「AI 原生」并非简单的 ChatGPT 集成，而是从架构层面为 AI 能力预留了扩展空间。

自然语言查询

系统支持用户用自然语言查询 CRM 数据，例如「显示本季度成交金额最高的 5 个机会」。实现路径包括：

1. 意图识别：LLM 解析用户输入，识别查询意图（查询 / 更新 / 统计）
2. Schema 感知：将元数据定义注入 Prompt，让 LLM 了解可用的对象和字段
3. 安全校验：生成的 SQL 需经过权限校验，确保用户只能访问授权范围内的数据
4. 结果限制：强制添加 LIMIT 子句，防止全表扫描导致性能问题

自动化工作流

Twenty 的工作流引擎支持基于事件的自动化处理。当 CRM 数据发生变化（如新线索创建、机会阶段推进），系统可以触发预定义的动作序列。AI 能力在此的集成点包括：

• 智能路由：根据线索内容自动分配给最合适的销售代表
• 内容生成：自动撰写跟进邮件或会议纪要
• 预测评分：基于历史数据预测成交概率

技术栈选型

Twenty 选择 NestJS 作为后端框架，这一决策对 AI 集成至关重要。NestJS 的模块化架构便于插入 AI 服务层，其依赖注入机制也让 LLM 客户端、向量存储等组件易于管理和替换。PostgreSQL 作为数据层，配合 pgvector 扩展可支持语义搜索场景，为 RAG（检索增强生成）提供基础设施。

工程实践建议

基于 Twenty 的架构特点，以下是可落地的实施建议：

数据模型设计

• 对象命名规范：建立团队级别的命名约定，避免元数据膨胀导致管理混乱
• 索引策略：对频繁查询的字段（如创建时间、负责人）建立索引，动态生成的表结构同样需要关注性能
• 归档机制：定期将历史数据归档到独立表或数据仓库，保持主库查询性能

权限配置

• 最小权限原则：为新用户配置基础 Permission Set，按需叠加额外权限
• 定期审计：利用 PostgreSQL 的审计日志功能，追踪敏感数据的访问记录
• 过渡方案：在行级权限正式支持前，通过视图（View）或应用层过滤实现数据隔离

AI 能力落地

• Prompt 版本管理：将系统 Prompt 纳入版本控制，追踪 LLM 行为变化
• 缓存策略：对高频自然语言查询的解析结果进行缓存，降低 LLM 调用成本
• 熔断机制：设置 LLM 调用超时和重试策略，避免 AI 服务异常影响核心 CRM 功能

总结

Twenty 代表了开源 CRM 的新方向：以元数据驱动打破传统 CRM 的刚性结构，以三层权限架构平衡灵活性与安全性，以 AI 原生设计拥抱大模型时代的数据交互方式。对于希望自建 CRM 的团队，Twenty 提供了一个可参考的架构蓝图 —— 不是简单地复制 Salesforce 的功能清单，而是重新思考 CRM 与 AI 融合的技术路径。

当然，作为新兴项目，Twenty 在权限粒度、企业级特性等方面仍有完善空间。但其开源属性和现代技术栈（NestJS + PostgreSQL + React）降低了二次开发的门槛，值得技术团队持续关注。

参考来源

• Twenty GitHub 仓库: https://github.com/twentyhq/twenty
• 权限架构讨论 Issue #10421: https://github.com/twentyhq/twenty/issues/10421

ai-systems