客服小李接到一张工单：客户要求退款，订单状态显示“已发货”，但物流信息三天没更新。工单系统里有一条备注“客服曾承诺今天解决”，知识库里有一份退款政策PDF，最新版本是三个月前发布的。小李需要核对订单状态、确认物流异常、判断是否符合退款条件、判断是否超出金额阈值、判断客服承诺是否构成例外——然后再去请示主管。

这不是一个复杂的流程，但把同样的事情交给 Codex 执行时，问题就来了。SOP 里写了“酌情处理”，什么算酌情？订单数据在订单系统，物流信息在物流系统，客服备注在工单系统，三个系统的订单号格式还不一样，如何用同一个业务 ID 对齐？MCP 连上了工具，但谁来决定 Codex 能读什么、不能写什么？流程没有版本号、没有负责人、没有异常路由——Codex 读到一半卡住了，不知道该找谁。

一份可供员工阅读的 SOP，还不足以成为 Codex 可重复执行的业务流程。真正缺失的，是一份可验证的执行清单。

01 先把 SOP 改写成可执行的任务合同

要让 Codex 执行 SOP，需要先把这份文档改写成一份“任务合同”——它不追求自然语言的行文流畅，而是要明确回答以下问题：

• 这份 SOP 的版本号是什么？由谁负责维护？
• 什么条件会触发这个流程？（例如“客户发起退款工单”）
• 允许读取哪些输入？（工单 ID、订单号、客户 ID）
• 每一步要做什么？判断规则是什么？
• 有哪些例外情况？需要哪些证据才能做判断？
• 最终输出什么格式的建议？
• 什么情况下必须停下来等人工介入？
• 谁来审批？审批层级如何划分？
• 需要记录哪些审计字段？生效日期和复核周期是什么？

以一条简化版退款 SOP 为例，改写成任务合同后大致长这样：

• SOP 编号：REFUND-2026-001，版本 v2.3
• 触发条件：客户通过工单提出退款请求
• 允许输入：工单 ID、客户 ID、订单号
• 判断规则：订单状态为“已发货”且物流异常时，可发起退款审核；金额超过 5000 元需二级审批
• 所需证据：订单截图、物流轨迹、客服沟通记录
• 例外处理：客服曾作出承诺的，需标注并提交主管复核
• 停止条件：证据缺失、规则冲突、金额超限
• 审批人：客服主管（5000 元以下）/ 运营负责人（5000 元以上）

这份任务合同明确了输入、规则、证据、例外、输出和审批点。Codex 读到的不是“酌情处理”，而是可逐条核验的判断条件。

02 Codex、MCP、Skill 和业务系统分别负责什么

有了任务合同，还需要搞清楚四层分工。

• 业务系统是正式数据源。工单系统存工单，订单系统存订单，知识库存政策——所有正式记录保留在原处，Codex 不替代任何系统。
• MCP 是连接与工具控制层。Model Context Protocol 是一个开放协议，用于将 AI 客户端连接到外部工具和数据。MCP 负责以受控方式读取工单、订单和政策条款，也可以调用工具，但必须在权限范围内。Codex CLI、ChatGPT 桌面应用和 IDE 扩展都支持 MCP 服务器，并共享同一份 MCP 配置。
• Codex 负责读取授权上下文、按规则核验、识别证据缺口和生成待审建议。Codex 通过沙箱和审批策略控制能做什么、什么时候必须停下来问人。
• Skill 在流程验证后封装稳定步骤与资源。Skill 是可复用工作流，把指令、模板、示例和参考资源打包在一起，让 Codex 在相关任务出现时按同样流程执行。Skills 在需要重复执行、依赖组织特定上下文或团队标准时尤其有价值。

四层分工清晰之后，才谈得上让 Codex 跑流程。

03 跑通“读取—检查—建议—审批”

以客服退款场景为例，八步走完整个流程：

• 业务负责人确认 SOP 版本和期望输出。选定一条已改写为任务合同的退款 SOP，明确本次只读、不写回。
• MCP 以只读权限获取数据。MCP 连接工单系统读取工单详情和客服备注，连接订单系统读取订单状态和金额，连接知识库读取当前有效退款政策。
• Codex 区分事实、缺失和待核实。Codex 识别出：订单状态“已发货”、物流“三天未更新”、客服备注“承诺今天解决”为已确认事实；物流异常原因未记录为缺失证据。
• Codex 逐条匹配 SOP 规则。SOP 规则：已发货+物流异常→可发起退款审核；金额超 5000→二级审批。Codex 匹配后判断该工单符合审核条件，金额在阈值内。
• 生成建议和风险等级。Codex 输出建议：“建议发起退款审核，需补充物流异常原因”；风险等级标注为“中”。
• 按审批矩阵路由。建议自动路由至客服主管待审批列表。
• 人工审批后执行。客服主管复核建议、确认证据后批准，在原工单系统中完成退款操作。Codex 不自动退款。
• 保存执行轨迹。每次执行保留追踪编号、数据来源、SOP 版本、模型产物、人工修改和审批结果。

全程 Codex 只读、只建议、不执行——写回和退款由原业务系统或授权人员完成。

04 在哪些地方必须停下来交给人

以下六种情况，Codex 必须停下来交给人：

• 缺证据：规则要求“物流异常原因”，但系统里没有记录。
• 规则冲突：SOP 说“已发货不可退款”，例外规则说“物流异常可审核”，两条规则同时匹配。
• 高金额：超过 SOP 设定的金额阈值，需二级审批。
• 客户承诺：客服曾作出超出 SOP 范围的承诺，需主管判断是否构成例外。
• 系统写回：任何修改订单、关闭工单、向客户发送承诺的动作，首版均禁止。
• 工具返回不可信内容：外部文档和工具返回的内容视为不可信输入，Codex 不能据此自行扩大权限。

Codex 的设计本身就包含了审批策略，用于控制何时必须停下来询问。破坏性工具调用在有破坏性标注时始终需要审批。第一版保持只读，高风险动作由人工审批——这是底线。

05 怎么验收企业第一条 SOP Agent

验收不是直接上线自动执行，而是用历史案例做离线测试。

准备一组历史工单样本：正常流程、异常流程、缺证据案例、规则冲突案例。用同一份 SOP 任务合同让 Codex 逐条处理，对照人工处理结果检查：

• 字段覆盖率：Codex 是否读到了所有必需字段
• 证据可追溯率：每条判断是否可追溯到具体数据来源
• 例外路由正确性：例外是否被正确识别并路由至对应审批人
• 人工修改率：多少建议被人工修改——修改率过高说明规则需要调整
• 权限违规次数：是否尝试读取或调用未授权内容
• 失败恢复情况：遇到停止条件时是否正确停下来

验收指标由企业按风险等级确定阈值，正文不预设达标数字。测试通过后，先小范围试点，再决定是否扩大数据接入和自动化范围。

06 知行奇点可以提供什么?

知行奇点围绕企业现有 SOP、角色、数据、系统和权限开展 AI 需求诊断，把规则整理为可验证任务，设计 MCP 接入范围、人工审批点和试点验收标准。

企业可先从一条高频、低风险流程开始验证，再决定是否扩大数据接入和自动化范围。

扫码添加企业微信，和我们聊聊你的企业AI需求。