5.0
关注
AI SCORE
行业动态2026-08-01 18:30
Temporal公司AI投入翻5倍、收入倍增案例
The New Stack#企业应用#ROI分析
Editor brief · 编辑速览
企业案例：Temporal大幅增加AI支出同步实现收入翻倍，CEO坦言难以证明两者因果关系，展示AI在业务运营中的应用潜力但缺乏技术细节。
企业案例：Temporal大幅增加AI支出同步实现收入翻倍，CEO坦言难以证明两者因果关系，展示AI在业务运营中的应用潜力但缺乏技术细节。
很高兴你来到这里。每周一至周五，你都会收到 TNS 最优质的内容，助你及时掌握新闻动态，并始终保持最佳状态。
请查收确认邮件，你可以在邮件中调整偏好设置，甚至加入更多群组。
在你喜欢的社交媒体平台上关注 TNS。
在 LinkedIn 上关注 TNS。
等待第一期 TNS newsletter 期间，不妨先看看最新的精选与热门文章。
Temporal 联合创始人兼 CEO Samar Abbas 正在推动公司将 AI 工具应用到工程与业务工作流中。（图片来源：The New Stack 图片合成）
每年最后两周，Temporal 都会清空日程表。公司称这段时间为“阅读期”：不开会，只留出时间探索、学习和构建。在 2025 年假期期间，联合创始人兼 CTO Maxim Fateev 把时间花在了 coding agent 上。据公司介绍，他回来后表示，过去需要六个月完成的工作，现在不到三十天就能完成。联合创始人兼 CEO Samar Abbas 认为，正是这段假期确定了公司这一年的 AI 方针。他说，一位联合创始人带着这样的数据回来，比任何公司指令都更有说服力。
这场转变——从一位资深工程师变成一位使用 Claude Code 的资深工程师——促使 Abbas 重新调整公司的投入方向。Temporal 销售的是 durable execution，也就是一套能够抵御故障的底层基础设施，可让长时间运行的软件在崩溃和服务中断时继续存活；它的客户都是无法承受停机损失的公司。Nvidia 和 Netflix 都在使用其工作流技术。
今年 2 月，该公司完成了 3 亿美元融资，估值达到 50 亿美元，其愿景是让其他所有人都能可靠地使用 agentic AI。Abbas 在 2024 年与如今担任 CTO 的 Fateev 互换了职位，出任 Temporal CEO。他认为，公司必须先在自己身上证明这一点。他将这项计划称为“AI for Temporal”。
“我们是一家由构建者组成的公司，这意味着这件事不只关乎工程团队，”Abbas 告诉 The New Stack，“整个公司都需要重新审视业务是如何运转的，以及应该如何使用这些工具。”
Temporal 有 500 多名员工，其中 200 人是工程师，这意味着需要重新审视的工作非常多。Abbas 表示，这份责任落在每一位员工身上：审视自己的日常工作流，带着好奇心接触这些工具，并改变完成工作的方式。这项要求不是可选项，Abbas 对我说得非常直白。Temporal 不强制使用某一种产品，但确实要求员工改变工作方式。
“如果你仍然没有采用合适的工具来提升自己，那么 Temporal 就没有适合你的位置。”
“如果你仍然没有采用合适的工具来提升自己，那么 Temporal 就没有适合你的位置。”他说。要求并不是必须使用某一款特定产品，而是必须真正采用新的工作方式。
他更多从增长而非员工人数的角度来解释这件事。Abbas 表示，Temporal 投入资金是为了释放新的工作能力，而不是为了用更少的人维持同样规模的公司。他不会根据工具使用量给员工制作排行榜，因为他认为这会产生错误的激励。与此同时，这项要求其实也有悖于公司自身原有的行事风格。
Abbas 要求 Temporal 员工勇于实验，但不能变得鲁莽。他说，这种文化转变才是整个工作中更困难的那一半。
Temporal 的核心价值观之一，是 Abbas 所说的“像重力一样可靠”。在押注某套技术栈时，Temporal 一向非常保守。如今，他要求公司在不鲁莽行事的前提下转向实验，而他认为，这种文化转变才是整个工作中更困难的那一半。
Samar Abbas · 联合创始人兼 CEO
在工程侧，公司刻意不强制指定工具。Temporal 提供一线工具选项，包括 Cursor，以及主要来自 OpenAI 和 Anthropic 的 foundation model，并让工程师自行确定什么最适合自己。Abbas 表示，2025 年假期结束后，Claude Code 自然而然地成为了主流选择。
公司尚未做的一件事，是把 open weights 引入内部。Temporal 并未广泛批准将 open-weight model 用于内部场景。Abbas 表示，这些模型是否能满足公司的安全与隐私要求，仍未得到验证。目前，公司还没有正式的模型审查流程；每个新模型都由一个中央 AI 团队进行安全审查，通过后才会向全公司开放。
Abbas 将公司面临的采用难题分为两类：技术用户和其他所有人，但他对两类人提出了同样的要求。最令人意外的采用案例，恰恰发生在工程团队之外。Abbas 告诉我，Temporal 招聘团队的一位非技术成员使用 Claude Desktop 构建了自己的招聘工具，包括职位描述生成器和面试计划生成器，把原本需要数小时、信息分散的准备工作变成了一个现成的起点。
这个项目正在扩展为一个人才搜寻 Agent，它可以在 Notion 与电子表格之间拉取和推送候选人数据，并对匹配结果进行排序。人才搜寻 Agent 所使用的知识存放在 Notion 中，再通过 MCP 与公司的其他记录系统连接。对于一家拥有 500 名员工的远程公司来说，这种连接给非技术团队带来的帮助超过了任何 coding 工具：低代码用户得以访问过去无法触及的系统，整个工作流也因此迁移到了 Notion 页面中。
日常协作通过 Slack 进行。Abbas 表示，Slack 的 AI 功能已经在很大程度上取代了他过去逐个询问员工工作状态的习惯。
Abbas 笑着告诉我，目前最明确的收益根本不在工程团队。Temporal 的业务拓展代表，也就是负责研究潜在客户并起草外联消息的团队，已经成为公司里最具 AI 原生特征的群体。过去，他们需要花费数小时从十几个地方收集数据，再整理成第一版外联文案；如今，这套流程会作为由团队基于 Temporal 构建的自定义 workload 运行，只需几分钟即可完成。这正是“AI for Temporal”的理念：一个非工程团队基于公司的自有基础设施进行构建，把缓慢的手工流程变成快速流程。真正让 Abbas 兴奋的，不只是节省下来的时间，还有由此形成的反馈循环。
与其他组织一样，Temporal 也发现 AI 在改善流程的同时，会转移瓶颈。让 AI 处理一项 workload，清除最明显的限制之后，瓶颈就会跳到另一个地方。代码写得更多，审查便成了阻塞点。Abbas 已经非常熟悉这种模式，这也是他不相信那些唾手可得的成果的原因。
问题偏偏出现在 Temporal 这种可靠性公司最无法容忍的地方。代码的生产成本下降后，审查成本却上升了。“AI slop 是真实存在的问题，”Abbas 说。他认为，AI 将粗制滥造内容的生产成本降得太低，以至于 reviewer 正被这些内容淹没。
对于关键基础设施，标准并没有改变：每一行代码在提交之前仍然必须由人阅读。这意味着新的限制因素变成了 reviewer，而不再是作者。其他工程负责人也感受到了这种挤压。Temporal 的解决办法是改变文化。只要能看出作者自己都没有先读过提交的内容，就可以立刻将工作退回；公司已经让这种做法变得可以接受。垃圾内容也不只存在于代码里。Abbas 见过未经审查、由 AI 生成的竞争对手分析被放进幻灯片，也见过同样粗制滥造的内容直接出现在网站上。
AI 账单同样增长迅速。Abbas 表示，今年的 AI 成本大约增长了五倍，其中大部分增量来自 coding agent。Temporal 将每个供应商的费用统一汇总到 Vantage 中，设置严格的支出上限；财务与工程团队每两周会针对异常使用者开会，根据具体使用模式逐一决定应当提高还是降低谁的额度。但公司不会把这些数据变成排行榜。
“许多公司都制作了 token 消耗量 dashboard。我们不太认同这种做法，因为它会引发一场竞赛，让我觉得自己必须成为 token 消耗量最高的人。”
“许多公司都制作了 token 消耗量 dashboard，”Abbas 说，“我们不太认同这种做法，因为它会引发一场竞赛，让我觉得自己必须成为 token 消耗量最高的人。”他说，Temporal 会保留使用数据，但不会将其作为员工排行榜公开，也不会将其与绩效评估挂钩。
Abbas 回忆起自己之前所在的一家公司曾出现过一个失控的工作流，在 AWS 上产生了 400 万美元的计算支出。Temporal 的应对方式源自一项名为“fly together”的价值观：给员工一笔预算，要求他们像花自己的钱一样使用它，同时用额度限制阻止失控情况，而不是通过羞辱员工来解决问题。
对于确实实施了自动化的地方，公司会像构建软件一样构建自动化。过去，Temporal 的安全团队会将漏洞登记为 ticket，然后等待工程师放下功能开发工作、优先处理漏洞，这导致两个团队之间不断产生摩擦。如今，团队将整个生命周期作为一个构建在 Temporal 自身之上的长时间运行 durable workflow 来执行，并把这个内部工具称为 Deputy：发现漏洞、生成修复方案、创建 PR、合并、运行 CI，然后部署上线。安全团队的职责也从提交问题，转变为协助交付修复。
这些内部实践同样构成了 Temporal 的商业论据。Temporal 多年来一直致力于解决的问题——让长时间运行的工作跨越故障继续存活——如今正是许多构建生产级 Agent 的团队所面临的问题。
“这些 Agent 正变得运行时间更长、更加异步，也更加关键，”Abbas 说，“这恰恰就是我们一直尝试通过 durable execution 解决的问题领域。”
他将 Temporal 的核心描述为一个开放的 foundation model：不依赖特定模型、语言或云平台，并提供可由公司自行运行的开源 server。在 Temporal 内部，这一理念已经形成了具体产品。Abbas 表示，公司基于 Temporal 构建了一个内部平台，非技术员工可以在 Claude Desktop 中描述一个应用，并通过一次点击完成部署。
guardrail、identity、安全机制以及 MCP 连接都已预先接好，而 Temporal 自己的 model router 则确保公司不会依赖任何单一供应商。公司还在今年 5 月的 Replay 大会上向客户阐述了同样的主张，并在会上推出 serverless worker、durable streaming，以及其他面向 Agent workload 的功能。
尽管速度显著提升，Abbas 却非常坦率地表示，他无法证明这些投入是值得的。他说，在团队规模不变的情况下，工程部门交付功能的速度提高了 20% 至 30%；自年初以来，公司的营收大约翻了一番。不过，他也谨慎地补充道，自己并未证明两者之间存在任何直接关联。
“关键不在于更快地交付功能，而在于交付客户真正关心的价值。”
他对那些看似整齐漂亮的生产力数字持怀疑态度，例如 PR 数量和代码行数——人们往往试图用这些指标证明相关支出是合理的。他还认为，过去那套创始人行动手册正是问题的一部分。投资人曾给他的建议是：在产品上进行第一性原理思考，同时聘请优秀的负责人，按照标准方式管理财务、招聘和 go-to-market。但他说，在 AI 时代，这套逻辑恰恰反了。过去所有人都会照着行动手册复制的职能，如今反而最值得从头重新设计。
于是，只剩下那个他想要却尚未得到的数字。“关键不在于更快地交付功能，而在于交付客户真正关心的价值，”Abbas 说。而他至今仍未看到任何指标，能够将公司的 AI 使用情况与这一结果直接关联起来。
Temporal 知道这些工具花了多少钱，也知道它们让公司变得更快。但它仍然无法证明，客户是否能够消化这些产出。目前来看，这就是尚未有任何 Agent 能够清除的瓶颈。