企业用 Codex，难点不在“会写提示词”：三家公司把 Agent 变成了日常流程

企业用 Codex，难点不在“会写提示词”：三家公司把 Agent 变成了日常流程

OpenAI 在 9 月 1 日公开了 Basis、Clay 和 Exa Labs 的三个企业 Agent 案例：新员工入职、销售账户管理、开发者生态集成。它们没有给出一套万能“智能体平台架构”，反而把 Agent 放进非常具体的工作里。Basis 把两小时入职流程缩短到约 30 分钟；Clay 让账户子 Agent 夜间整理分散信息；Exa 让 Codex 从发现集成机会一直做到创建 PR、运行测试并准备周报。

可复用工作流从明确的“完成”开始

Basis 的入职 Agent 有清楚的触发点、步骤、工具和结束条件。HR 先示范流程，再把它包装成公司专属 skill；碰到例外，就在下一批员工到来前更新。这里最关键的资产是可版本化的工作说明。若流程依赖某位同事临场解释，Agent 只会把不稳定做法执行得更快。

适合第一批自动化的工作通常具备几个特征：重复发生，输入范围可控，结果能验收，出错后可以恢复。入职集成、依赖升级、测试补齐、资料归档都比“替我经营这个客户”更容易定义完成。团队可以先记录人工流程中的真实分支，再写触发条件、必需输入、允许工具、输出位置和停止点。模型名称应排在这些字段之后，因为换模型无法弥补模糊的工作边界。

OpenAI 的文章提到，Basis 把 Codex 直接发给新员工。这种做法只有在权限同步到位时才安全。账号创建、仓库访问、内部文档与第三方系统授权应由身份系统决定，skill 不能自行扩大权限。新员工离职或转岗后，Agent 能访问的资源也要随角色撤销。企业真正复用的是受控流程，不是把管理员权限藏进一段提示词。

持续上下文需要来源、更新频率和责任人

Clay 为每个客户账户建立持久工作区和专属子 Agent，夜间从 CRM、邮件、Slack、通话和演示材料中更新信息，早上再由协调 Agent 给出优先动作。这个结构解决的是上下文会变旧的问题。一次性把全部资料塞进长提示词，既昂贵又难追踪；按账户存放证据，并按固定频率更新，更容易查出某条建议依据了哪封邮件。

数据权限不能因为“给 Agent 用”而放宽。销售、客服和研发看到的账户字段不同，跨系统同步时仍应继承原有访问控制。模型网关记录谁通过哪个 Agent 调用了哪种模型，业务工具则记录读取和写入对象；两边日志用统一任务 ID 关联，出现误操作时才能回放。对于涉及报价、合同或外部承诺的建议，可以再用独立模型审阅矛盾和缺失证据，但最终决定仍由明确的业务负责人承担。

从发现机会到创建 PR，中间必须有测试和停靠点

Exa 的流程最接近许多人想象中的 Codex 企业应用：Agent 监控潜在集成机会，收集上下文，创建拉取请求，运行测试并准备对外文案。它没有自动发布。人决定哪些机会值得投入、公司可以作出什么承诺，测试和评审把 Agent 的工作暴露在合并之前。这些停靠点让自动化可以延伸，却不把关系管理和发布责任一起交出去。

工程团队应把权限按阶段拆开：发现阶段只读公开仓库和内部需求，实施阶段写入隔离分支，验证阶段调用受限 CI，合并与对外发布继续要求人工批准。失败后允许重试几次、何时换模型、何时停止，也要写进工作流。否则一个坚持执行的 Agent 可能重复触发昂贵测试，或者为了通过检查不断扩大改动范围。

这些案例对“国内订阅 Codex”一类选择还有一个提醒：入口只是开始。固定订阅适合人与 Agent 高频协作，API 更适合定时任务和批处理；统一模型网关可以让同一工作流比较 Codex、Claude、GLM 等模型，同时保留成本、延迟和错误记录。AnyAIS 的 [模型聚合入口](/) 能承担模型切换这一层，但企业仍要自己定义数据来源、工具权限、验收和责任人。工作流留下可验证结果并能在下一次运行中改进，才算日常能力。

来源：[OpenAI：AI 原生公司如何把工作流变成运营能力](https://openai.com/index/ai-native-company-workflows/)