TeamGrid

从代理机构内部的不满，到全球性的基础设施

我在 2013 年创办 TeamGrid，源于我从代理机构内部熟知的一种挫败感：日常工作很少因为业务本身复杂而崩溃，真正崩溃的原因是工具之间不能相互对话。每一个项目都横跨日历、任务管理工具、CRM、计费工具与聊天软件 —— 而每一次系统之间的交接都丢失上下文。我们没有选择在问题之上再缝一个集成，而是决定去构建本应存在于这些工具之下的那一层。

随后是两年安静的开发。我们在 2015 年上线，被评为 Product Hunt 当日 #1 产品，数月内就有超过 200 家代理机构上线使用。其后的几年，我们把早期增长沉淀为客户可以长期依赖的基础设施 —— 加深数据模型、扩展产品边界，并打造一款公司愿意长期使用的产品。

2022 年，我们将总部迁至迪拜。这是一次有意识的选择：迁入一个位于欧洲、亚洲与中东交汇处的市场 —— 一家面向全球扩张的公司所需要的运营环境，匹配监管的清晰、人才的可获得性，以及覆盖多个时区的能力。

平台背后的数字

今天的 TeamGrid 已不再是一款小众工具。它是企业每天赖以运转的运营基础设施，数字也反映出这一点。

到 2020 年，客户已通过 TeamGrid 完成超过十亿美元的开票。到 2025 年，这一数字翻了三倍，超过三十亿美元。该平台支持全球 1,600 多家公司的工作 —— 从独立代理机构到运行数百个席位的企业团队。这些不是虚荣指标 —— 它们描述的是有多少真实的经济活动，年复一年地在一个连贯的系统中流动，并以企业可信赖的可靠性支持开票、规划与客户工作。

为什么我们在 2023 年从零重建

2023 年，我们做出了少有成熟 SaaS 公司愿意做的决定：把整个平台从零重建。

原因是结构性的。整个行业都在向 AI 作为一种产品形态迁移，但主流模式注定是错的 —— 每一家在位 SaaS 都在一个从未为推理设计过的工具之上，贴一个聊天框、一个”Ask AI”按钮、或者一个 copilot。这种做法很快就会撞上硬天花板。一个只能看到企业局部的模型 —— 这里一个项目、那里一位联系人、别处一张发票 —— 无法真正理解这家企业。它能总结一份文档，但无法运营一项业务。

过去两年关于 agentic AI 的教训现在已经毫不含糊：模型的好坏取决于它能访问的上下文，而上下文不是一个 prompt —— 它是一个系统。 在彼此孤立的 SaaS 上做检索、围绕老旧 API 的 MCP 包装、以及粘贴在单一工具表面上的 copilot，都在不断撞上同一面墙。数据是碎片化的、Schema 不一致、历史是散落的，任何 prompt 工程都无法弥补这一点。

要诚实地交付一种 AI 原生的体验，唯一的方式就是拥有数据模型、应用以及它们共享的运行时。所以我们重新开始。新的数据模型。新的基础设施。新的产品。在两年多的时间里安静地构建，把 AI 不作为附加，而作为底层结构性的前提。

TeamGrid 2 —— 一个平台、十七个原生应用

成果就是 TeamGrid 2 —— 一个 AI 原生的企业操作系统，十七个原生应用共用一份数据层：任务、项目、计划、日历、联系人、销售管线、时间记录、考勤、文件、笔记、表单、PDF 设计器、消息、邮件、计费、分析，以及一个工作流构建器。

这些不是不同产品之间的集成。它们是同一个操作系统中的应用，从第一天起就共享同一份对企业的统一模型。一个任务知道它属于哪个项目、服务于哪位客户、计入哪份合同、与哪个日历竞争资源、以及来自哪一段对话 —— 不需要任何人去手工接线。平台通过一个 App Store 可扩展，客户与合作伙伴可以在同一基础之上、而不是围绕它去构建。

这正是改变 AI 这场对话的关键。因为系统是完整的，AI 看到的也是一家完整的企业 —— 而不是一堆文档的集合。

一家公司的完整上下文，在同一个系统中

在 TeamGrid 中，每一个实体都是同一张图谱中的一部分。客户、项目、商机、任务、时间条目、发票、合同、文件、会议、消息与邮件不再是分散在不同产品中的孤立记录 —— 它们是一个可被查询的统一公司模型中的节点。

带来的实际效果是：平台可以诚实地回答任何碎片化 SaaS 栈都无法诚实回答的问题。当把未计费时间、范围蔓延以及高级人力被占用的日历负担也考虑进来时，哪些客户其实是不盈利的?管线中的哪些商机正在停滞，因为它们依赖的交付团队已经超载?哪些项目即将延期，只因为负责人被三场其他上线拖走?这些都不是 dashboard 问题 —— 它们是上下文问题，只有当项目、财务、排程、CRM 与沟通共享同一份数据模型时才能回答。

这就是底层。其上的 AI 是这一基础的结果，而不是相反。

一份 AI 真正能用的公司记忆

在统一数据层之上，坐落着一份企业级记忆 —— 一个持久化、结构化的层，捕获决策、承诺、客户历史、偏好、协作约定，以及业务此前如何处理类似情形。它不是粘在聊天窗口上的向量数据库，而是操作系统本身的一部分：每一项操作、文档、消息与结果都向一份平台可推理的记忆贡献内容。

这正是大多数老旧工具中”AI 功能”所缺失的。一个嵌在单个产品中的 copilot 可以自动补全一封邮件或总结一份文档，但它不会记住上一季度做出的定价决定、三个项目前与某位客户达成的 SLA、或某条工作流之所以存在的理由。TeamGrid 会记住 —— 因为这段历史一开始就是在系统中产生的。

由此带来的是一种会复利的 AI 体验：一家公司在 TeamGrid 上运行得越久，其记忆就越有价值，助理、Agent 以及之上的工作流也就越有能力。

AI 在核心 —— 聊天、语音与 Agent

TeamGrid 中的 AI 不是侧边栏。它直接接入平台核心 —— 以聊天、语音与自主 Agent 的形式呈现 —— 并运行在与每一个原生应用共享的同一份数据层与记忆之上。

这改变了 AI 实际能做的事。它不只是去取一份文档，而可以规划一个季度、在团队范围内重新分配工作负载、起草一份扎根于真实客户历史的提案、运行一次多步骤的销售跟进、用底层时间条目核对一笔账单争议、或在一次操作中触发牵涉到半打应用的工作流 —— 全程清楚谁参与其中、达成过哪些约定、当下有什么在推进，以及此前发生过什么。这正是整个企业软件市场正在前进的方向：从只为单一工具提供帮助的 copilot，走向能在整家企业上行动的 agentic 系统。TeamGrid 从底层开始就是为那个世界而建的。

主张

现代团队浪费时间的原因，并不是软件太简单。他们浪费时间是因为运行在十二个互不连通、却假装彼此对话的工具之上 —— 而现在，这些同样的工具又在一个本就不连贯的底座上贴 AI，在一种从一开始就不连贯的基础上叠加智能。下一代企业软件并非更聪明的单一工具。它是一个连贯的系统：一个底座、原生的应用、一份公司记忆，以及作为结构存在的 AI。

这就是我们正在把 TeamGrid 建成的样子，也是我作为Founder 与 CEO 带入其中的信念。