工作交给了AI，为什么还得不断解释和确认？
即使把每周重复的工作交给AI，如果负责人仍要持续解释上下文并重新核对结果，那么只是执行者变了，运营方式并没有改变。提示词越长、自动化越多，也越难找出异常究竟发生在哪里。
Basis、Clay 和 Exa 分别用不同方式解决了这个问题。它们将顺序稳定的工作做成可复用技能，把持续变化的上下文留在按账户划分的工作区，并为产生外部结果的执行加入测试和人工审核。三家公司共同沉淀为运营资产的不是对话脚本，而是工作的状态和完成证据。
Basis把入职说明变成了“可完成的流程”
Basis减少的不只是向新员工传递信息的时间。它把由人演示一次的流程转化为公司专用技能，其中包含触发条件、执行步骤、所需工具和完成条件。新员工第一天会获得 Codex 和入职技能；代理在讲解公司的核心概念时，也会推进计算机集成设置。OpenAI 于2026年9月发布的案例中，Basis表示首日入职培训时间已从2小时降至30分钟。
不过，这个数字只是 Basis 报告的单一案例。样本量、测量周期、设置错误率和 HR 审核时间均未公开，因此并不意味着每家公司都能节省75%的时间。值得借鉴的不是数字，而是将说明与实际状态变化相连的设计。
文档和执行流程的结束点不同。
“设置必需的协作工具”这样的文档，读完并理解后就结束了。执行流程则需要完成证据和异常处理，例如：“确认已批准的服务列表 → 使用公司邮箱登录 → 记录必需频道的加入状态 → 若出现账户冲突或额外权限请求则停止”。
异常也不会消失。在 Basis 的案例中，出现重复问题和新异常时，HR 会更新技能；遇到复杂问题时则由人介入。 Basis 还说明，在其会计代理中，会计师会参与关键决策点并审核完成结果。由此可见，这家公司的运营原则与其说是无人化，不如说更接近将重复执行与专家判断分离。
Clay创造的不是摘要，而是第二天依然存在的状态
对于交易信息这类每天都在变化的工作，仅靠固定流程并不够。Clay将分散在 CRM、电子邮件、Slack、通话和演示材料中的交易上下文汇集到按账户划分的工作区。专职子代理每晚审核原始资料并更新账户文件夹，协调代理则在早晨筛选优先行动，例如回答客户问题或确认采购委员会中的空缺。Clay披露，节省的是过去每晚整理收件箱的大约1小时。
关键在于，昨天的结论会成为今天的输入。Clay 的 Account Agents 产品页面也描述了一种结构：代理根据此前的接触、交易、通话和结论，从允许的行动中选择下一步，并将结论和推理重新记录到账户中。CRM 和数据仓库记录被设计为需要经过人工批准。 不过，仅凭公开资料无法确认，这一商业产品与 OpenAI 案例中提到的 Clay 内部系统是否是完全相同的实现。
Exa没有止步于发现，而是连接到经过测试的PR
对于影响代码和外部合作伙伴的工作，验证路径与产出成果同样重要。Exa 的 Codex 工作流会监控开发生态中的集成机会，收集相关上下文，然后创建 PR 并运行测试。它还会准备每周更新，以及在需要时准备初步公告草稿，但实际部署前会由人审核。投资哪些机会、向外部合作伙伴承诺什么，也由团队决定。
Exa 还提供 Code Search，该产品会索引 GitHub 仓库、文档和 Stack Overflow，将自然语言查询连接到真实代码示例。 不过，公开案例并未说明该产品被直接用于内部集成工作流。因此，与其断言 Code Search 是 Exa 案例的技术基础，不如将其视为公司处理代码探索问题的另一款独立产品，这样更准确。
| 工作的性质 | 接近的案例 | 应保留的运营资产 | 由人决策的节点 |
|---|---|---|---|
| 顺序和正常结束状态稳定 | Basis | 包含触发条件、步骤、工具和完成条件的技能 | 新异常和复杂问题 |
| 客户和账户上下文持续变化 | Clay | 累积原始资料和结论的持久工作区 | 核实依据后对客户采取的行动 |
| 产生PR、发送或部署等外部结果 | Exa | 测试结果和可审核的产出 | 优先级、对外承诺和部署批准 |
执行前完成的首个试点设计清单
公开资料没有给出安装或运行 Basis 公司专用入职技能的路径。因此，以下流程并非某个特定产品的使用方法，而是一份与负责人共同确认是否已准备好运行试点的设计清单。OpenAI建议的起点同样是先确定负责人、基线、KPI 和护栏，然后明确触发条件与权限、完成证据以及移交给人工的停止点。
- 选择一项有当前执行记录的工作。你应能用一句话说明其正常完成状态。还要记录当前处理时间、异常、人工介入次数和审核时间，作为基线。
- 选择符合工作状态的结构。若顺序稳定，使用可复用技能；若信息持续变化，使用持久工作区；若会产生外部结果，则归类为带测试和审核的受限执行。
- 用具体句子写明触发条件和允许范围。例如：“入职日期和公司邮箱确认后开始。只读取已批准的账户列表并确认设置状态。发现权限授予请求、账户冲突或列表外服务时停止。”
- 先确定完成证据和人工停止点。如果是新员工账户设置，负责人必须能通过每项必需服务的登录确认记录等原始资料进行核实；如果是代码变更，则应核实测试结果和变更内容。请将对外发送、数据修改、部署和权限授予单独列为需批准的事项。
- 执行前确认负责人和使用环境。在一张表中写明产品名称和支持的方案、安装或访问路径、登录和认证负责人、要连接的系统、授予的最小权限、工作输入位置，以及结果和审计记录的查看位置。如果其中任一项尚未确定，就还没有进入执行阶段。若选择 GitHub 的 codex-action，应将 PR 正文、提交消息、仓库指令文件和图像也视为不可信输入，并选择最窄的文件和网络权限。
- 制定将异常反馈到下一版本的规则。将试点中出现的失败记录为缺少条件、上下文不足、权限错误或审核规则问题之一，并确定由谁修改技能、工作区或测试，以及由谁进行复审。
试点执行准备就绪的标准
必须全部确定：业务负责人、当前基线、要使用的产品和访问路径、认证和连接负责人、输入位置、最小权限、完成证据的核查位置以及批准主体。只要有一项缺失，就不要猜测执行命令；应先查阅该产品的官方安装和认证文档，再制定单独的执行流程。
成功标准不是输出量。
2026年6月，企业客户的 Codex 和 ChatGPT 合计输出令牌中，Codex占64%；按月度 AI 使用量计算，排名前10%的企业每位活跃用户产生的输出令牌是中间区间企业的8.3倍。但 OpenAI 也明确指出，令牌数量是不完善的业务价值代理指标。 启动实际试点后，应将适合该工作的指标——已完成工作、周期时间、质量、异常、审核负担、成本和风险——与事先记录的基线进行比较。
技能的共享和管理方式也需要针对每个产品进行确认。ChatGPT 的技能可包含指令、示例和代码，以便复用和共享；Enterprise 和 Edu 管理员可按角色管理相关权限。 不过，官方帮助文档也说明，其他产品的可用性、安装、同步和治理方式可能不同。不能假定这些管理界面和权限会以相同方式适用于 Codex。
从三个案例中应复制的是边界，而不是数字
Basis 的30分钟和 Clay 的每天1小时展示了可能性，但并不是公开了样本和比较方法的受控实验结果。 我们团队首先要确认的并非只有“速度提高了多少”，而是代理执行到哪里、将什么保留为状态，以及人在哪个节点承担责任。
为稳定流程附加完成条件，为变化的工作附加持续的上下文，为产生外部影响的执行附加测试和批准关卡。此外，还必须确定要使用的产品和访问路径、权限以及输入和结果位置，才能进入真正的试点。当这些边界清晰后，AI自动化便能摆脱个人的长提示词，成为下一个人也可以重复和改进的运营工作流。
如果想进一步深入了解
How AI-native companies turn workflows into operating capability — 一份基础资料，可同时了解 Basis、Clay、Exa 的工作流，以及编写代理职位描述的标准。 openai.com
Account Agents by Clay | AI agents for every account — 可从产品层面了解按账户记忆、允许的行动、人工批准和可观测性功能如何相连。 clay.com
Enterprise signals: What frontier firms are doing differently — 可结合企业 AI 使用量数据，了解令牌为何是不完善的业务价值代理指标。 openai.com
codex-action security guidance — 具体说明基于 GitHub 的代理应如何处理不可信输入和最小权限。 github.com
