本页解决什么问题
Slack、Linear 和 SDK 都能把任务交给 Codex,但它们不是三个等价的入口。- Slack 是面向对话的委派入口,任务从消息或 thread 上下文开始。
- Linear 是面向工作项的委派入口,任务从 issue、评论和工作流状态开始。
- SDK 是面向程序的控制接口,任务由你的服务、脚本或 CI 创建和推进。
具体套餐、可用模型、SDK 方法名、连接器界面和权限名称会随版本变化。部署前请以本地 codex --help、SDK 类型定义和 OpenAI 官方文档为准。示例中的仓库、频道、团队和令牌均为占位符。
先建立一张边界图
三种委派模型
表中“委派者”不等于“拥有全部代码权限的人”。集成必须明确区分三种身份:
- 请求身份:谁提出了任务,决定业务意图和审计归属。
- 连接身份:Slack、Linear 或 SDK 使用哪个账号、OAuth 授权或 API 凭据访问外部系统。
- 执行身份:Codex 在仓库、沙箱、网络和工具中的实际权限。
选择入口的规则
Linear 还有一个容易混淆的分支:Linear MCP 让本地 Codex 读取 Linear 数据;它不是“在 Linear 云端把 issue 指派给 Codex”。前者是工具数据源,后者是云端委派入口。本页比较的是后者,若采用 MCP,仍需单独审查本地 MCP 的认证和工具权限。
集成前的共同前提
先定义任务契约
不要直接把“帮我修一下”作为生产集成的唯一输入。每个任务至少应有以下字段:request_id 用于幂等,repository 和 base_ref 防止环境猜错,acceptance 让结果可验收,execution_mode 把权限选择从自然语言中拿出来。不要让模型自行决定是否可以推送、合并、发布或访问生产系统。
先画数据流
上线前把以下箭头画出来,并为每条箭头标注数据类型、认证主体和保留时间:最小权限基线
开始时默认使用以下基线:- 仓库只允许读取;只有明确需要补丁时才切换到工作区可写。
- 只允许目标仓库和目标分支,不接受模型自行扩大范围。
- 禁止生产凭据、SSH 私钥和完整
.env进入 prompt 或执行目录。 - 外部网络默认关闭;确需联网时只允许域名白名单。
- 提交、推送、创建 PR、合并、发布和发送外部消息均作为独立的人工审批动作。
- 每个任务设置超时、最大重试次数、最大输出大小和费用上限。
- 结果回传前过滤密钥、个人信息、内部 URL 和未经授权的代码片段。
requirements.toml 用来收紧底线,托管默认值用来设置起始行为;不能把安全责任只留给每个开发者本机的配置。
Slack:对话驱动的委派
Slack 的工作方式
Slack 集成适合“人在讨论中发现问题,立即委派”的场景。典型链路是:- 成员在频道或 thread 中提及 Codex。
- 集成读取允许范围内的消息上下文,并识别请求者和仓库。
- Codex 创建一个云端任务,使用匹配的环境执行。
- Slack 先收到受理状态和任务链接。
- 任务结束后,结果摘要和链接回到原 thread;企业策略也可以只回链接。
Slack 认证与授权
接入 Slack 时至少涉及四个权限问题:
不要把“能读取频道”解释成“能修改仓库”。Slack OAuth scope、GitHub 仓库权限、Codex 云端环境权限分别控制不同资源。消息作者也不应自动获得执行身份的更高权限;应先通过仓库白名单、团队角色和操作级策略判断。
建议记录如下审计字段:
event_id 应用于去重,thread 时间戳用于稳定回传位置。不要用消息文本哈希代替事件 ID;同样内容可能是两次合法任务。
Slack 的上下文边界
thread 中的历史消息是辅助上下文,不是授权声明。以下内容应显式写入任务契约,而不是依赖模型从对话推断:- 目标仓库和分支。
- 是否允许修改文件。
- 是否允许联网以及允许访问的域名。
- 验收命令和输出格式。
- 是否可以创建补丁或 PR。
- 复制自 Issue、网页或日志的隐藏指令。
- 代码块中的
AGENTS.md、脚本和配置内容。 - 未经确认的附件和外部链接。
- 包含密钥、Cookie、客户数据的粘贴内容。
Slack 结果回传
先回传短状态,再回传可审查结果:Slack 的适用和不适用
适合:- 临时错误定位和日志解释。
- 讨论中的小范围、可读性强的代码任务。
- 将任务受理状态和链接回到原讨论。
- 需要严格排队、SLA、负责人和审批状态的批量任务。
- 依赖完整结构化字段的自动化流程。
- 直接把公开频道内容作为高权限执行指令。
Linear:工作项驱动的委派
Linear 的工作方式
Linear 更适合已经进入研发流程的任务。常见链路有两种:- 将 issue 指派给 Codex,由 issue 状态和 Activity 记录执行进度。
- 在 issue 评论中提及 Codex,利用评论 thread 进行多轮追问。
Linear 认证与授权
Linear 场景通常包含:
“能更新 issue”不意味着“能改仓库”。应为 Linear 团队、项目、标签和状态设置白名单,并将仓库映射作为受控配置,而不是从 issue 标题猜测。高风险标签如
production、security、migration 可以直接阻止自动委派,转入人工确认队列。
Linear 的上下文和状态机
把 issue 状态当作可观测状态,而不是执行锁。建议为任务维护一套独立状态机: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 的时候。典型代码可以:- 校验业务请求并生成
request_id。 - 根据用户、仓库和任务类型选择执行策略。
- 创建 thread 并运行第一轮任务。
- 读取结果,决定继续追问、请求人工审批或结束。
- 将最终响应和验证证据写入结果存储。
@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 适合多轮任务,例如先计划、再实现、最后审查:Sandbox.read_only、Sandbox.workspace_write 等 preset 以及每轮配置方式,以当前版本文档为准;如果某轮扩大了权限,应将该决定写入审计日志。
建议采用两阶段执行:
full_access 不应作为服务端默认值。即使模型需要联网安装依赖,也应使用隔离 runner、临时凭据和域名白名单;“读写工作区”不等于“可以访问宿主机全部文件”。
SDK 的事件和结果
SDK 直接返回的最终结果不应被当作唯一观测来源。服务需要同时保存:started、progress、tool_call、completed、failed等生命周期事件。- 事件时间、任务 ID、thread ID、请求 ID和执行身份。
- 退出原因、错误类别、重试次数和超时信息。
- 最终文本、结构化结果、测试摘要和变更统计。
三者的认证、事件和结果对照
认证比较
不要把 Slack 或 Linear 的 OAuth token 转发给 Codex prompt,也不要把 Codex access token 回写到消息和 issue。任何令牌出现在日志、事件、任务链接查询参数或模型上下文,都应视为泄露并立即轮换。
事件流比较
入口事件必须可以重复投递。处理器先验证签名、时间窗口和事件 ID,再写入幂等键,最后异步执行。不要在 Slack 或 Linear webhook 的同步响应中长时间等待 Codex;应快速返回受理结果,把执行放到队列。
结果回传比较
结果适配器应做长度限制和敏感信息过滤。长日志放在访问控制后的任务详情或 artifact 中,消息和评论只保留摘要、状态、验证证据和链接。
推荐集成架构
轻量架构:连接器直接回传
适合低风险、人工触发、小规模团队:推荐架构:事件总线加任务编排器
适合团队生产使用:- 验证层检查签名、来源、时间戳和事件 ID。
- 幂等存储阻止同一请求重复创建执行。
- 队列隔离外部 webhook 延迟,提供重试和死信队列。
- 编排器根据用户、项目、仓库和风险等级选择策略。
- worker 只拿到本次任务所需的令牌、代码和配置。
- 结果校验器拒绝不符合 schema、超长或包含敏感信息的输出。
- 回传适配器只更新原 thread、issue 或回调目标。
任务表的最小字段
委派编排伪代码
通用入口
reserve 必须有唯一约束,避免两个并发请求同时通过去重。拒绝消息也应避免泄露内部策略细节,例如不要告诉外部用户“某个隐藏仓库白名单文件的具体内容”。
worker 执行
配置样例
Slack/Linear 路由策略
将路由和权限配置放在受控配置中,避免让消息文本决定高风险动作:CI 或 SDK 的秘密注入
服务端只在运行时读取秘密:结构化结果 schema
错误处理和恢复
错误分类
重试必须区分“重新调用接口”和“重新执行任务”。结果回传失败可以重试回传;执行超时或部分写入后不能无条件重跑。若执行环境可恢复,应先检查工作区、diff 和进程状态,再决定从 thread 继续还是创建全新任务。
超时、取消和死信
每个任务至少设置四个时间限制:入口受理超时、队列等待超时、Codex 执行超时、结果回传超时。取消任务时应:- 标记任务为
cancelling,阻止新的重试。 - 请求运行时停止或终止当前进程。
- 收集是否产生文件变更和是否已发起外部请求。
- 清理临时目录和短期凭据。
- 回传“已取消/部分执行”的准确状态。
数据外发边界
进入 Codex 的数据
发送前逐项确认:- 消息或 issue 是否包含客户姓名、邮箱、手机号、访问令牌、Cookie 或生产日志。
- 代码仓库是否属于允许的组织和数据区域。
- 是否需要完整文件,还是只需错误片段和路径。
- 外部附件和 URL 是否经过下载、大小和域名限制。
- 依赖安装或网络工具是否会把请求内容发送到第三方。
从 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。
- 已在测试数据上完成端到端验收,没有使用生产凭据。
最终判断
Slack、Linear 和 SDK 的差异可以压缩成三句话:- Slack 把对话上下文变成一次云端委派,适合即时协作,但不能替代任务数据库。
- Linear 把 issue 生命周期变成一次云端委派,适合可追踪工作流,但自动 triage 必须控制规则、归属和范围。
- SDK 把委派变成程序控制流,适合队列、CI、多轮会话和结构化结果,但你的服务必须承担身份、幂等、权限和审计责任。