三年前，我曾写过一篇文章，讨论为什么 Salesforce 是一家伟大的公司。当时我的核心观点是：它真正的护城河并不在功能本身，而在于极其灵活的数据模型——哪怕这种灵活性伴随着复杂与痛苦。
但从那篇文章写下到今天，软件世界已经发生了巨变。最显著的变化，莫过于生成式 AI 与大语言模型的飞速发展。随着模型能力逐渐成熟，我们开始看到真正意义上的 Agent 工作流 出现：它们可以从多种数据源中获取信息，在长时间跨度内执行复杂行动。
也正是这些变化，让传统 CRM 架构的底层问题暴露得愈发明显。许多团队发现，他们很难在现有系统中真正落地 agentic workflows（智能体工作流）。
Agent 时代，对系统提出了全新的要求
Agent 并不是“更聪明的用户”，它们对系统的要求是本质不同的。
在人类使用 CRM 的世界里，几乎不可能出现两个用户在完全同一时间对同一条记录执行完全相同的操作。即便是拥有几千人的大型团队，也很少会产生大量冲突性的修改。
但在 Agent 世界里情况完全不同。即使是一家小公司，也可能同时运行成千上万个高度并行的 Agent，这会极大放大冲突与不一致的风险。
传统平台尝试通过“外挂 AI 能力”来解决这个问题，例如引入向量数据库（Pinecone、Turbopuffer 等），作为主数据的副本来支持语义搜索。但这种方案存在两个致命问题：
数据复制是延迟的，无法保证实时一致
结构化查询与非结构化语义检索难以统一
在数据库领域，这个问题有一个明确的名字：一致性（Consistency）——系统在某一时刻是否能准确反映真实状态。
Universal Context：CRM 里的 External Consistency
Universal Context 是第一个在 CRM 领域实现 External Consistency（最高级别事务一致性） 的系统。
这意味着：
Agent 用来遍历 Attio 内部数据的语义向量，与系统中的其他数据始终保持完全同步。
更重要的是，这种一致性不仅服务于 Attio 内部的 Agent。
通过我们全新的 MCP Server，运行在 ChatGPT、Claude Code 等外部平台上的 Agent，也可以获得完全一致的数据视图与高级索引能力。
这件事解锁了一个全新的可能性：
不同平台上的 Agent，可以在同一个实时一致的“单一事实源”上协作。
举个例子：
如果一个运行在 Claude Code 中的 Agent 研究了某个联系人，并写下一条关于兴趣偏好的备注——在传统系统（如 HubSpot 或 Salesforce）中，这条信息往往需要一段时间，才能被其他 Agent“看见”。
而在 Attio 的 Universal Context 中，一个此刻运行在 ChatGPT 里的 Agent，可以立刻在相关查询中命中这条新信息。
Schema 本身，就是 Context
要让 Agent 真正服务于 GTM（Go-To-Market）组织，它们必须能够理解数据的结构、关系与访问方式。
今天许多 MCP Server 已经解决了“能访问数据”的问题，但仍然缺少对“数据长什么样”的理解。不同系统的索引方式和语法差异巨大，使得 Agent 很难稳定地在跨数据源场景中推理和决策。
人类世界里，我们通常用数据仓库来解决这些问题。但对于 Agent 来说，数据仓库依赖 ETL 流程，本质上是一个延迟且不一致的副本，并不适合实时的 agentic workloads。
Agent 需要的是：
一个统一、准确、强一致的数据模型，作为其决策和评估结果的基础。
这也是 AI 原生 GTM 系统的核心问题之一。
Attio 的 Particle 数据模型采用灵活的图 + 关系结构，为 Universal Context 提供了一种统一语言，让 Agent 可以探索和索引整个 GTM 数据宇宙。
从结构化数据（姓名、邮箱），到动态丰富的数据（职位、行业），再到非结构化的私有数据（邮件、笔记、通话记录），Universal Context 将所有信息融合为一个安全、清晰、可推理的环境。
这是 Agent 可以自由探索、构建、实验和持续优化的“游乐场”。
生成式应用逻辑的真正价值
Salesforce 有一个常被忽视、却极其强大的能力：Apex。
Apex 于 2007 年推出，是一种强类型、私有的编程语言，允许开发者通过代码扩展平台能力。它的革命性在于：
只要投入足够的时间和成本，你几乎可以把 Salesforce 改造成任何你想要的样子。
这也是 Salesforce 长期难以被替代的重要原因之一——当你的业务逻辑被编码进成千上万行、只运行在单一平台上的代码时，迁移成本会变得极其高昂。
但到了 2026 年，编码 Agent 正在彻底改变软件的构建方式。
问题不再是时间和人力，而是：
你是否拥有一个允许 Agent 自由生成、执行和迭代代码的平台？
没有代码执行能力，Agent 的能力将被严重限制。
Apex 的问题在于：它是一个基于 2007 年 Java 5 的复杂私有分支，对 Claude Code、Cursor 等现代编码 Agent 并不友好。Salesforce 也意识到了这一点，因此才会投入大量资源训练专用模型（如 xGen-Code、CodeGen），但这是一条逆生态而行的道路。
App SDK：为 AI 设计的编译目标
去年，我们发布了 Attio App SDK：
一个基于 TypeScript 的代码沙箱，运行在完全托管的 serverless 环境中，支持 React。
我们的核心设计目标只有一个：
让它成为 AI 的“编译目标”。
整个环境和库从一开始就被设计成对 LLM 友好、宽容、可理解。
借助庞大的 TypeScript 与 npm 生态，Agent（如 Claude Code）可以直接复用成熟工具链，完成全自动的构建、测试和部署流程。
与 Apex 依赖私有 IDE 和专属工具链的部署模式相比，差异一目了然。
我们相信：
代码生成不是下一代 GTM 工具的一个功能，而是整个系统的地基。
“配置 vs 代码”的对立正在瓦解。编码 Agent 让任何人都能生成、测试并持续优化高度定制化的逻辑。随着 Ask Attio 这样的 Agent 能力不断增强，最终用户甚至不需要意识到“代码”的存在——他们只需要提出需求，就能获得可用的应用。
CRM 的 AI 未来
Universal Context 的发布，连同 Ask Attio 与基于 MCP 的工具链，是我们迈向 Agent 原生 CRM 的一个重要里程碑。
前方的路线图仍然令人兴奋：
我们将持续扩展现有 Agent 的能力，引入新的 Agent 与交互界面，让更多客户真正释放 AI 的巨大潜力。
