概述

OpenAI 在 2026 年 9 月 1 日发布了题为《How AI-native companies turn workflows into operating capability》的文章，探讨了 AI 原生企业如何借助 Agent 将日常业务流程转化为可持续的运营能力。文章以 Basis、Clay 和 Exa Labs 三家初创公司为案例，展示了 AI Agent 在员工入职、客户管理和开发者生态建设中的实际应用，并提炼出企业领导者可借鉴的方法论。

文章同时引用了 OpenAI 的 Enterprise Signals 报告数据：前沿企业（AI 使用率前 10%）平均每个活跃用户生成的输出 token 数已达到典型企业的 8.3 倍（2026 年 1 月这一数字为 2.6 倍）。这一差距的拉大表明：领先企业不再将 AI 作为辅助工具，而是将其深度嵌入运营闭环——连接公司上下文与工具、委派实质性的工作，并让成功的工作流可复制、可迭代。

关键技术点

1. 从“演示”到“可复用技能”的入职自动化（Basis）

Basis 是一家为会计公司构建 AI Agent 的公司。其员工入职流程从原本的两个小时压缩至 30 分钟。关键路径如下：

  • 新员工第一天即可获得 Codex 访问权限和一个 公司定制的 onboarding skill（一套可复用的工作流指令与资源）。
  • Codex 负责欢迎介绍、讲解公司核心概念，并在后台直接操作用户的计算机完成各类集成配置。
  • HR 可随时根据常见问题或异常情况更新该 skill，其作用于下一次入职批次。

该案例的核心在于：Basis 团队将一次性的人工操作演示，转化为了一个带有明确触发条件、已知步骤、所需工具和“完成”定义的标准化 Agent 技能。流程不再依赖个人经验，同时保留人工介入处理例外情况的窗口。

2. 为分散信息提供持久化工作空间（Clay）

Clay 为市场团队构建“自学习收入引擎”，其面临的核心销售痛点是：客户关键上下文散落在 CRM、邮件、Slack、通话记录、演示文稿、短信以及内部协同中。

Clay 的 GTM 工程师采用了一种新方案：为每个客户账户建立一个持久化工作区和专属子代理（subagent）。流程设计如下：

  • 子代理每晚自动审查一手信息源，更新对应客户的交易文件夹。
  • 次日清晨，一个协调 Agent 汇总所有客户的最新动态，生成优先级行动清单：回答待澄清的客户问题、补齐采购委员会的信息缺口、或提供客户重新参与的理由。
  • 每条建议都附带可追溯的证据线索，销售人员在采取行动前可直接核验原始信息。

根据 Clay 的反馈，这一工作流每晚为销售人员节省了约一小时的收件箱处理时间。其可扩展性在于：共享上下文机制可继续延伸到客户经理、BDR、解决方案工程师等角色，受控于既有的账户权限体系。

3. 从“信号”到“可测试成果”的执行闭环（Exa Labs）

Exa Labs 为 AI Agent 构建网络搜索基础设施，其目标是让搜索 API 实现“无处不在”（Exa everywhere）。此前的生态拓展需要开发者关系团队在各类仓库和社区中人工监控、识别集成机会并跨系统协作。

Exa 将这条路径定义为 Codex 的标准化工作流：

  • 监控与收集：自动识别高优先级集成机会（依据明确优先级规则），从 Slack、Notion 等源获取上下文。
  • 执行与验证：创建 pull request、运行测试、生成每周更新。
  • 人工复核：必要时起草下一步行动（如发布公告），但所有对外内容必须经团队审核。

Agent 将机会从“信号”推进到“经过测试的产物”，减少了研究、工程、沟通之间的交接损耗。但关键决策权仍在人类手中：哪些机会值得投入、做出何种承诺、外部关系如何维护等，均由人负责。测试结果与人工审查点也确保 Agent 的工作在交付前可视化，并据此持续调整工作流边界。

对数据科学或 AI Agent 落地的意义

这三个案例共同体现了 Enterprise Signals 报告的趋势：企业 AI 正从辅助性回答转向可执行的自主行为。对数据科学团队和 AI 工程团队而言，其启示是结构化的：

  1. 流程即产品：Agent 落地的核心并非模型能力比拼，而是将隐性业务流程显性化——定义触发条件、完成标准、工具权限与人工介入点。数据科学团队可参考这一思路，将已有的数据管道、特征工程和分析报告流程标准化为 Agent 可执行的 Skill。
  2. 上下文的持久性设计：Clay 的案例表明，Agent 在复杂场景下需要持续写入和读取“动态上下文”，而非单轮问答。这需要数据基础设施支撑，包括可信的信息源接入、定期的刷新机制与权限隔离。
  3. 测量体系需重构：OpenAI 建议同时跟踪“深度”（完成任务数、连接上下文/工具数、异常次数、人工审查负载）与“价值”（周期时间、质量、成本、收入、风险），两者相辅相成。仅看 token 消耗量无法反映运营效果。
  4. 人机分工的动态演化：文章指出“分工在使用中越来越清晰，责任随着工作流证明自己而扩展”。这意味着 Agent 的权限和职责范围需要与工件质量绑定，而非一次性固化。

我的技术点评

这篇文章带来一个值得注意的视角：AI 原生企业（或广义上的前沿企业）的优势并非源于某次突击部署，而是来自对“执行型 Agent”的系统性工程化。

我认为其中最关键的一环，是把工作流当作代码库来经营。在 Basis 的架构中，“onboarding skill” 本质上是一个可版本控制的业务流程对象，由 HR 持续维护、迭代，新员工首次入场即可获得“官方”工作路径。这种模式将 Agent 的“软技能”沉淀为组织的“硬资产”，同时也为异常反馈（exception）提供了回流入口。类比软件工程中的 CI/CD，这三家公司的 Agent 流程都具备“可观察、可回滚、可由人触发复核”的特性，这正是大规模部署 Agent 时避免失控的前提。

另一个值得关注的设计决定是：三家公司都没有追求全流程自动化，而是在关键节点强制加入人类判断——Exa 的对外发布必须人工审核，Clay 的行动优先级列表可由销售自行验证并否决。这既是对风险和责任的务实妥协，也是一种良好的人机信任构建策略。信任不是口头承诺，而是来源于“建议 + 可核验证据 + 有限行动范围”的组合设计。

当然，原文也诚实指出，这些案例来自特定领域的初创公司——其规模化能力（数十人团队的复杂度）与企业级场景仍有距离。原文未说明诸如技能编写成本、Agent 维护开销的具体数字。对于大型企业而言，权限治理、跨部门决策权分配和风险兜底等问题，将比这些案例中体现的“由少数人垂直推动”的路径复杂得多。

对于数据科学团队而言，这篇文章更像是一份架构速写，而非工程手册。它的价值在于提醒我们，Agent 项目的前瞻性指标不应止步于“模型能否答对”，而应聚焦于“模型组件的操作闭环能否持续产出可被业务信任的成果”。

原文链接

How AI-native companies turn workflows into operating capability