Skip to main content

本页解决什么问题

Slack、Linear 和 SDK 都能把任务交给 Codex,但它们不是三个等价的入口。
  • Slack 是面向对话的委派入口,任务从消息或 thread 上下文开始。
  • Linear 是面向工作项的委派入口,任务从 issue、评论和工作流状态开始。
  • SDK 是面向程序的控制接口,任务由你的服务、脚本或 CI 创建和推进。
如果只记住“都可以让 Codex 干活”,很快就会在认证主体、上下文边界、结果去向和权限责任上出错。本页建立一套可落地的判断框架:谁发起任务,Codex 代表谁执行,哪些数据被送出,事件如何传递,结果怎样回到业务系统,失败后如何重试或人工接管。 本文讨论的是 Slack/Linear 集成与 Codex SDK 的工程设计。它不把 App Server 当作普通自动化入口;只有当你需要自己实现富客户端的会话历史、审批界面和流式事件处理时,才应继续研究 App Server。
具体套餐、可用模型、SDK 方法名、连接器界面和权限名称会随版本变化。部署前请以本地 codex --help、SDK 类型定义和 OpenAI 官方文档为准。示例中的仓库、频道、团队和令牌均为占位符。

先建立一张边界图

三种委派模型

表中“委派者”不等于“拥有全部代码权限的人”。集成必须明确区分三种身份:
  1. 请求身份:谁提出了任务,决定业务意图和审计归属。
  2. 连接身份:Slack、Linear 或 SDK 使用哪个账号、OAuth 授权或 API 凭据访问外部系统。
  3. 执行身份:Codex 在仓库、沙箱、网络和工具中的实际权限。
个人试用时三者可能恰好都是同一个人。团队部署时通常不是:Slack app 是连接身份,消息作者是请求身份,云端环境或服务账号是执行身份。若不记录这三个字段,出现越权、错误仓库或错误费用归属时很难追溯。

选择入口的规则

Linear 还有一个容易混淆的分支:Linear MCP 让本地 Codex 读取 Linear 数据;它不是“在 Linear 云端把 issue 指派给 Codex”。前者是工具数据源,后者是云端委派入口。本页比较的是后者,若采用 MCP,仍需单独审查本地 MCP 的认证和工具权限。

集成前的共同前提

先定义任务契约

不要直接把“帮我修一下”作为生产集成的唯一输入。每个任务至少应有以下字段:
request_id 用于幂等,repository 和 base_ref 防止环境猜错,acceptance 让结果可验收,execution_mode 把权限选择从自然语言中拿出来。不要让模型自行决定是否可以推送、合并、发布或访问生产系统。

先画数据流

上线前把以下箭头画出来,并为每条箭头标注数据类型、认证主体和保留时间:
这张图中的“接入层”不能直接等同于“执行器”。接入层负责验证来源和防重放,编排器负责授权和路由,执行环境负责限制 Codex,结果适配器负责脱敏与回传。四层混在一个 webhook 函数里,最容易造成密钥泄露、重复执行和错误回传。

最小权限基线

开始时默认使用以下基线:
  • 仓库只允许读取;只有明确需要补丁时才切换到工作区可写。
  • 只允许目标仓库和目标分支,不接受模型自行扩大范围。
  • 禁止生产凭据、SSH 私钥和完整 .env 进入 prompt 或执行目录。
  • 外部网络默认关闭;确需联网时只允许域名白名单。
  • 提交、推送、创建 PR、合并、发布和发送外部消息均作为独立的人工审批动作。
  • 每个任务设置超时、最大重试次数、最大输出大小和费用上限。
  • 结果回传前过滤密钥、个人信息、内部 URL 和未经授权的代码片段。
企业工作区还应使用集中策略约束可用的审批策略和沙箱模式。requirements.toml 用来收紧底线,托管默认值用来设置起始行为;不能把安全责任只留给每个开发者本机的配置。

Slack:对话驱动的委派

Slack 的工作方式

Slack 集成适合“人在讨论中发现问题,立即委派”的场景。典型链路是:
  1. 成员在频道或 thread 中提及 Codex。
  2. 集成读取允许范围内的消息上下文,并识别请求者和仓库。
  3. Codex 创建一个云端任务,使用匹配的环境执行。
  4. Slack 先收到受理状态和任务链接。
  5. 任务结束后,结果摘要和链接回到原 thread;企业策略也可以只回链接。
Slack 不是可靠的任务数据库。消息可以被编辑,thread 上下文可能不完整,频道成员也会变化。因此生产系统应把任务契约和最终状态保存在自己的任务表中,把 Slack 当作人机交互和通知渠道。

Slack 认证与授权

接入 Slack 时至少涉及四个权限问题: 不要把“能读取频道”解释成“能修改仓库”。Slack OAuth scope、GitHub 仓库权限、Codex 云端环境权限分别控制不同资源。消息作者也不应自动获得执行身份的更高权限;应先通过仓库白名单、团队角色和操作级策略判断。 建议记录如下审计字段:
Slack event 的 event_id 应用于去重,thread 时间戳用于稳定回传位置。不要用消息文本哈希代替事件 ID;同样内容可能是两次合法任务。

Slack 的上下文边界

thread 中的历史消息是辅助上下文,不是授权声明。以下内容应显式写入任务契约,而不是依赖模型从对话推断:
  • 目标仓库和分支。
  • 是否允许修改文件。
  • 是否允许联网以及允许访问的域名。
  • 验收命令和输出格式。
  • 是否可以创建补丁或 PR。
应过滤或隔离以下输入:
  • 复制自 Issue、网页或日志的隐藏指令。
  • 代码块中的 AGENTS.md、脚本和配置内容。
  • 未经确认的附件和外部链接。
  • 包含密钥、Cookie、客户数据的粘贴内容。
一个安全的 Slack prompt 可以这样组织:

Slack 结果回传

先回传短状态,再回传可审查结果:
完成消息应包含状态、摘要、验证证据、未完成项和下一步:
失败时不要只发“失败了”。至少说明失败类别、是否已产生修改、是否可以安全重试和任务 ID。企业环境若关闭了“在 Slack 发布任务完成答复”,应只发布不泄露代码内容的任务链接,并在受控界面查看详情。

Slack 的适用和不适用

适合:
  • 临时错误定位和日志解释。
  • 讨论中的小范围、可读性强的代码任务。
  • 将任务受理状态和链接回到原讨论。
不适合:
  • 需要严格排队、SLA、负责人和审批状态的批量任务。
  • 依赖完整结构化字段的自动化流程。
  • 直接把公开频道内容作为高权限执行指令。

Linear:工作项驱动的委派

Linear 的工作方式

Linear 更适合已经进入研发流程的任务。常见链路有两种:
  • 将 issue 指派给 Codex,由 issue 状态和 Activity 记录执行进度。
  • 在 issue 评论中提及 Codex,利用评论 thread 进行多轮追问。
还可以通过 triage 规则自动委派新 issue。自动规则应谨慎使用,因为自动运行通常以 issue 创建者的账号或关联身份计费和执行。上线前必须让团队知道:一条规则可能让任意符合条件的 issue 进入 Codex,且请求归属、配额和权限需要单独确认。

Linear 认证与授权

Linear 场景通常包含: “能更新 issue”不意味着“能改仓库”。应为 Linear 团队、项目、标签和状态设置白名单,并将仓库映射作为受控配置,而不是从 issue 标题猜测。高风险标签如 production、security、migration 可以直接阻止自动委派,转入人工确认队列。

Linear 的上下文和状态机

把 issue 状态当作可观测状态,而不是执行锁。建议为任务维护一套独立状态机:
Linear 的 Todo、In Progress、Done 不足以表达“Codex 正在运行但尚未验证”。可以用标签或评论记录 codex/running、codex/needs-review、codex/failed,并在你的任务表保存正式状态。只有通过测试和人工审查后,才允许自动更新为完成。 issue 正文和评论同样是不可信输入。明确标出“需求资料”和“控制字段”,例如仓库、分支、沙箱和发布权限由系统字段提供;issue 中声称“忽略所有规则”的文本不能覆盖系统策略。

Linear 结果回传

建议把结果写成固定结构的评论,便于人和机器人共同读取:
评论写入必须幂等。以 request_id 或稳定的隐藏标记查找已有评论,重试时更新原评论而不是不断新建。外部 API 返回 429、5xx 或超时时,采用指数退避并设置上限;认证失败和权限拒绝不要自动重复。 如果采用 triage 自动委派,应把“规则命中原因、issue 创建者、规则版本和仓库映射”写入审计记录。规则改变后新任务应记录新版本,避免无法解释为什么同类 issue 在不同时间走了不同路径。

Linear 的适用和不适用

适合:
  • 有验收标准、负责人和生命周期的 bug 或工程任务。
  • 需要在 issue 上留下进度和审查证据的团队流程。
  • 经过标签和团队规则筛选的低风险自动派单。
不适合:
  • 把所有新 issue 无条件交给可写环境。
  • 用一个高权限连接器覆盖所有团队和仓库。
  • 把状态改成 Done 当作代码已经通过审查。

SDK:程序控制的委派

SDK 的工作方式

SDK 适合你的程序需要控制 Codex 的时候。典型代码可以:
  1. 校验业务请求并生成 request_id。
  2. 根据用户、仓库和任务类型选择执行策略。
  3. 创建 thread 并运行第一轮任务。
  4. 读取结果,决定继续追问、请求人工审批或结束。
  5. 将最终响应和验证证据写入结果存储。
TypeScript SDK 适合服务端 Node.js 程序,常见包名是 @openai/codex-sdk,运行环境要求以当前官方文档为准。Python SDK 的包名和行为可能不同,当前文档将其作为 beta 方案,并通过本地 app-server 驱动;不要根据 TypeScript 包名臆测 Python 包名或稳定性。

SDK 认证模型

SDK 认证需要先回答“程序代表谁”: API key、access token 和 ChatGPT 登录会话不是同一类凭据。令牌应存入密钥管理器,只注入单个进程或步骤,不进入源码、prompt、构建日志和结果评论。设置过期时间、轮换计划和吊销流程;不要使用永不过期的共享令牌。 如果企业合规要求审计用户行为,使用 API key 的 SDK 任务可能不进入与 ChatGPT 登录任务相同的合规导出范围。应在上线前确认 API 组织、工作区审计和自建任务日志的边界,并保存请求身份、执行身份和令牌版本的映射。

SDK 的会话和沙箱

SDK 的 thread 适合多轮任务,例如先计划、再实现、最后审查:
不要把“先只读、后可写”仅实现为两句 prompt。权限应由 SDK 的沙箱或执行配置控制,并在业务层再次校验。Python SDK 的 Sandbox.read_only、Sandbox.workspace_write 等 preset 以及每轮配置方式,以当前版本文档为准;如果某轮扩大了权限,应将该决定写入审计日志。 建议采用两阶段执行:
full_access 不应作为服务端默认值。即使模型需要联网安装依赖,也应使用隔离 runner、临时凭据和域名白名单;“读写工作区”不等于“可以访问宿主机全部文件”。

SDK 的事件和结果

SDK 直接返回的最终结果不应被当作唯一观测来源。服务需要同时保存:
  • started、progress、tool_call、completed、failed 等生命周期事件。
  • 事件时间、任务 ID、thread ID、请求 ID和执行身份。
  • 退出原因、错误类别、重试次数和超时信息。
  • 最终文本、结构化结果、测试摘要和变更统计。
如果当前 SDK 只暴露最终结果,就在调用外层补充开始、超时、取消和完成事件。不要把模型输出中的“已完成”当作系统状态;只有进程退出成功、验证命令通过并且结果持久化成功,任务才可标记成功。 需要机器消费时,优先使用 schema 约束的结构化输出,而不是用正则解析自然语言:
仍要在服务端校验字段、长度、枚举值和路径。结构化输出只约束结果格式,不会自动授予文件、网络或外部系统权限。

三者的认证、事件和结果对照

认证比较

不要把 Slack 或 Linear 的 OAuth token 转发给 Codex prompt,也不要把 Codex access token 回写到消息和 issue。任何令牌出现在日志、事件、任务链接查询参数或模型上下文,都应视为泄露并立即轮换。

事件流比较

入口事件必须可以重复投递。处理器先验证签名、时间窗口和事件 ID,再写入幂等键,最后异步执行。不要在 Slack 或 Linear webhook 的同步响应中长时间等待 Codex;应快速返回受理结果,把执行放到队列。

结果回传比较

结果适配器应做长度限制和敏感信息过滤。长日志放在访问控制后的任务详情或 artifact 中,消息和评论只保留摘要、状态、验证证据和链接。

推荐集成架构

轻量架构:连接器直接回传

适合低风险、人工触发、小规模团队:
即使采用轻量架构,也应完成仓库白名单、最小沙箱、敏感数据规则和人工审查。不要因为“没有自建服务”就跳过权限评估。

推荐架构:事件总线加任务编排器

适合团队生产使用:
各组件职责应保持单一:
  • 验证层检查签名、来源、时间戳和事件 ID。
  • 幂等存储阻止同一请求重复创建执行。
  • 队列隔离外部 webhook 延迟,提供重试和死信队列。
  • 编排器根据用户、项目、仓库和风险等级选择策略。
  • worker 只拿到本次任务所需的令牌、代码和配置。
  • 结果校验器拒绝不符合 schema、超长或包含敏感信息的输出。
  • 回传适配器只更新原 thread、issue 或回调目标。

任务表的最小字段

生产实现还应保存数据保留期限、费用标识和回传目标。不要在这张表中保存原始密钥;需要关联时保存密钥版本或密钥管理器引用。

委派编排伪代码

通用入口

Webhook 处理器不应直接启动长时间 Codex 执行。reserve 必须有唯一约束,避免两个并发请求同时通过去重。拒绝消息也应避免泄露内部策略细节,例如不要告诉外部用户“某个隐藏仓库白名单文件的具体内容”。

worker 执行

这里故意把“完成执行”和“完成交付”分开。Codex 成功退出但 Slack API 暂时 503,不应重新执行代码;只需重试结果回传。类似地,结果校验失败不能盲目重试模型,否则可能重复修改工作区。

配置样例

Slack/Linear 路由策略

将路由和权限配置放在受控配置中,避免让消息文本决定高风险动作:

CI 或 SDK 的秘密注入

服务端只在运行时读取秘密:
不要把令牌设成整个 job 的全局环境变量,尤其是同一 job 会 checkout 或运行仓库代码时。测试脚本、依赖安装钩子和第三方 action 都可能读取全局变量。令牌只应传给实际需要它的步骤;共享 runner 还应使用低权限用户、隔离工作区和短期凭据。

结构化结果 schema

schema 不应允许模型返回任意 URL、shell 命令或“批准执行”的布尔字段并让下游直接信任。命令和链接仍需由服务端白名单与转义。

错误处理和恢复

错误分类

重试必须区分“重新调用接口”和“重新执行任务”。结果回传失败可以重试回传;执行超时或部分写入后不能无条件重跑。若执行环境可恢复,应先检查工作区、diff 和进程状态,再决定从 thread 继续还是创建全新任务。

超时、取消和死信

每个任务至少设置四个时间限制:入口受理超时、队列等待超时、Codex 执行超时、结果回传超时。取消任务时应:
  1. 标记任务为 cancelling,阻止新的重试。
  2. 请求运行时停止或终止当前进程。
  3. 收集是否产生文件变更和是否已发起外部请求。
  4. 清理临时目录和短期凭据。
  5. 回传“已取消/部分执行”的准确状态。
死信任务必须保留原始 request ID、错误类别、最后事件和人工操作入口,但不要把包含秘密的原始 prompt 无限制保存。为不同来源配置独立的告警和队列,避免 Slack 的大量重复事件阻塞 Linear 的生产任务。

数据外发边界

进入 Codex 的数据

发送前逐项确认:
  • 消息或 issue 是否包含客户姓名、邮箱、手机号、访问令牌、Cookie 或生产日志。
  • 代码仓库是否属于允许的组织和数据区域。
  • 是否需要完整文件,还是只需错误片段和路径。
  • 外部附件和 URL 是否经过下载、大小和域名限制。
  • 依赖安装或网络工具是否会把请求内容发送到第三方。
推荐最小化原则:能用摘要就不发送原始数据,能用脱敏样本就不发送真实客户记录,能在本地过滤就不让模型看到密钥。日志中的 Authorization header、数据库连接串和签名参数必须在进入 prompt 前删除。

从 Codex 回到 Slack/Linear 的数据

回传是第二次外发,风险不低于输入。默认只回传:状态、短摘要、变更文件名、测试结果、任务链接和人工下一步。完整 diff、日志和代码片段放在访问控制后的存储中。根据接收者权限过滤:一个公开 Slack 频道不应看到私有仓库的内部实现,也不应把 Linear issue 的客户数据复制到更宽的频道。

企业治理注意事项

企业部署应区分“代码是否用于训练”“运行数据是否留存”和“审计日志是否保留”。这三者不是同一个开关。本地与云端执行也代表不同数据流:本地执行通常让代码留在开发者环境,云端任务需要把仓库送入托管环境。具体零数据留存、数据驻留和日志保留承诺以工作区合同和官方配置为准。 建议由安全负责人确认:
  • Slack 和 Linear 连接器的 scope、工作区范围和卸载流程。
  • 云端环境可访问的仓库、分支、网络和凭据。
  • SDK 服务的租户隔离、令牌轮换和数据保留期限。
  • Analytics/Compliance 日志与自建任务日志的交集和缺口。
  • 发生泄露时的撤销、轮换、通知和取证步骤。

验收方案

功能验收

用测试仓库、测试 Slack 频道和测试 Linear 团队验证:
  • Slack mention 能被受理,重复投递不会创建两个任务。
  • Slack 结果回到原 thread,失败信息包含任务 ID和下一步。
  • Linear 指派和评论两种路径都能关联同一个 issue。
  • Linear 结果评论可幂等更新,重试不会产生评论风暴。
  • triage 规则关闭时不会自动派单,打开后只匹配白名单标签。
  • SDK 能创建 thread、返回最终结果,并持久化开始/完成/失败状态。
  • 任务超时、取消、429、5xx、无权限和 schema 错误都有预期状态。

权限验收

使用至少三类测试身份:普通开发者、无仓库权限用户、管理员。逐项确认:
  • 无权限用户不能通过修改消息或 issue 文本扩大仓库范围。
  • 只读任务不能写文件、提交、推送或访问不在白名单的域名。
  • 工作区可写任务也不能自动合并、发布或读取宿主机秘密。
  • connector 只能读取和写回约定的 Slack/Linear 资源。
  • 禁用成员、撤销 token 或关闭规则后,新任务立即拒绝。
  • 所有拒绝和权限变更都能在审计记录中找到请求身份与策略版本。

数据验收

准备包含假密钥、客户样本和隐藏提示注入的测试输入,确认:
  • 假密钥不会进入 Codex prompt、日志、artifact、Slack 或 Linear。
  • 隐藏 HTML 注释和外部文档不能覆盖系统任务契约。
  • 结果中的内部路径、完整日志和个人信息会被过滤或降级为受控链接。
  • 结果存储、任务表和死信队列按期限删除或归档。
  • 生产凭据从未写入仓库、workflow、配置文件或聊天记录。

运维验收

至少观察一周测试流量并记录:
  • 受理到开始、开始到完成、完成到回传的延迟。
  • 每种来源的成功率、重试率、超时率和死信数量。
  • 按用户、团队、仓库和入口的 token/费用使用量。
  • 误派仓库、越权拒绝、敏感信息拦截和人工接管次数。
  • 令牌轮换、连接器撤销和策略更新是否有演练记录。

上线清单与回滚

上线前逐条打勾:
  • 任务契约包含请求身份、仓库、分支、权限模式、验收和过期时间。
  • Slack/Linear scope 已按最小权限批准,测试频道和团队已隔离。
  • 仓库和环境映射是白名单配置,不依赖模型猜测。
  • webhook 签名、时间窗口、事件去重和快速 202 响应已实现。
  • 队列、幂等存储、重试上限和死信处理已验证。
  • 只读优先,工作区可写需人工批准,提交/推送/发布仍单独审批。
  • SDK 令牌存入密钥管理器,具备过期、轮换和吊销流程。
  • prompt 和结果都经过长度限制、脱敏和提示注入防护。
  • 结果以 schema 校验,回传适配器可幂等更新原位置。
  • 任务、事件、策略版本、执行身份和费用标识可审计。
  • 超时、取消、权限拒绝、外部 API 限流和平台故障均有 runbook。
  • 已在测试数据上完成端到端验收,没有使用生产凭据。
回滚应按层进行:先停止新入口或关闭 triage/队列消费,再取消运行中的任务,最后撤销 connector 或令牌。不要通过删除任务表来“清理”事故;保留必要的审计记录和任务状态。若已产生代码变更,检查临时工作区和 diff,按仓库流程恢复或提交反向修复;若已发送 Slack/Linear 消息,使用更正消息并记录外发范围。

最终判断

Slack、Linear 和 SDK 的差异可以压缩成三句话:
  • Slack 把对话上下文变成一次云端委派,适合即时协作,但不能替代任务数据库。
  • Linear 把 issue 生命周期变成一次云端委派,适合可追踪工作流,但自动 triage 必须控制规则、归属和范围。
  • SDK 把委派变成程序控制流,适合队列、CI、多轮会话和结构化结果,但你的服务必须承担身份、幂等、权限和审计责任。
选择入口时先问“谁在什么系统里提出任务”,再问“谁代表他执行”,最后问“结果要回到哪里并由谁批准”。只要这三个问题能在配置、任务表和验收日志中找到明确答案,集成才算真正可运营。 参考资料:参考/codex/29-integrations.md、参考/codex/27-automation.md、参考/codex/39-enterprise.md。动态信息以本地 CLI、SDK 类型定义和 OpenAI 官方文档为准。