第 12 章

CLI 与脚本化

把 Codex 从交互式助手变成可编程引擎 —— 含 OSS 本地模型

exec · mcp-server · Python SDK · TypeScript SDK · Ollama / LM Studio

明明能自动,偏要手动?

"每次都要打开终端敲一遍,太浪费时间了。"

CI/CD 无法接入

你想在 GitHub Actions 里自动 review PR、生成 changelog、跑测试修复 —— 但 Codex 只能交互使用,无法嵌入流水线。每次 push 都只能靠人肉盯着。

批量任务低效

需要给 50 个文件加文档注释、重构 20 个 API 端点、扫描整个仓库的安全漏洞。Codex 一个一个帮你改没问题,但你得发 50 次指令。

隐私敏感任务

处理客户数据、内部机密代码、合规审查 —— 你不希望任何数据离开本地机器。但云端模型的 API 调用意味着数据要上云,这是合规红线。

本章的答案:Codex 不只是 REPL。它可以作为 CLI 工具、MCP 服务器、SDK 库,甚至连接本地 OSS 模型运行 —— 把 AI 能力编织进你的自动化流程。

开始之前

适合谁学

  • 想把 Codex 集成到 CI/CD 工作流的 DevOps 工程师
  • 希望批量处理代码任务的开发者
  • 有数据隐私需求的团队(金融、医疗、法律)
  • 想构建基于 Codex 的自动化产品的平台工程师

读完你应该能

  • 用 codex exec 编写非交互式脚本
  • 用 Python / TypeScript SDK 构建工作流
  • 把 Codex 作为 MCP Server 暴露给其他工具
  • 连接 Ollama / LM Studio 处理敏感数据
  • 诊断常见配置和权限错误

暂时不涉及

  • Codex IDE 扩展(VS Code / JetBrains)
  • 企业部署和模型代理(Responses API Proxy)
  • 模型微调与训练
前置知识:假设你已读完第 1-6 章,熟悉 Codex CLI 的使用和配置。需要 Codex CLI 已完成 codex login 认证。

codex exec 是什么?

Codex 的非交互执行模式

当你输入 codex 时,启动的是交互式 REPL(读取-求值-输出循环)。输入 codex exec 则进入一次性执行模式:

交互模式

  • 启动等待用户输入
  • 多轮对话共享上下文
  • 适合探索性任务

exec 模式

  • 接收 prompt,执行,退出
  • 可写进 shell 脚本
  • 适合自动化流水线
# 交互模式
codex
> explain this function

# exec 模式
codex exec "explain this function"
核心区别:exec 模式不会等待用户继续输入,执行完毕后进程退出并返回退出码 —— 这正是 CI/CD 工具所需要的。

prompt 参数详解

三种传入指令的方式

位置参数

codex exec "fix the login bug"

最直接。prompt 作为最后的参数传入。

stdin 管道

cat issue.txt | codex exec -

用 - 占位:prompt 从标准输入读取。适合长文本或文件内容。

混合模式

echo "上下文" | codex exec "总结以下"

prompt 参数 + stdin 同时存在时,stdin 内容作为 <stdin> 块附加到 prompt 末尾。

技巧:在脚本中推荐用 stdin 避免 shell 转义问题 —— 把 prompt 写入 heredoc 或变量再管道传入。

--json 结构化输出

让脚本能解析 Codex 的每一步

加上 --json 后,Codex 输出 JSONL(每行一个 JSON 对象)到 stdout,而不是纯文本。事件类型包括 thread.started、turn.started、turn.completed、turn.failed、item.started、item.completed、error。

codex exec --json "list all TODO comments" | while read -r line; do
  echo "$line" | jq -r '.type'
done

JSONL 事件类型

  • thread.started — 线程开始
  • turn.started — 轮次开始
  • item.started — 某个 item 开始执行
  • item.completed — item 完成(item.type 区分消息/命令/文件变更)
  • turn.completed — 轮次结束(含 usage token 统计)

实用管道

# 只提取最终回复(item.type 为 agent_message 的 item.completed)
codex exec --json "fix this" | jq -r \
  'select(.type=="item.completed" \
   and .item.type=="agent_message") \
   | .item.text'

# 或用 --output-last-message 直接写入文件(更简单)
codex exec --output-last-message result.txt "fix this"

-s 沙箱模式

控制代码能触碰什么

--sandbox(短写 -s)决定 Codex 执行中对文件系统和网络的访问权限:

read-only

codex exec -s read-only "review this PR"

只能读取文件,不能写入。适合纯审查、分析任务。

workspace-write

codex exec -s workspace-write "fix lint errors"

默认值。可在工作区目录内读写文件,但受目录边界限制。

danger-full-access

codex exec -s danger-full-access "install deps"

无任何限制。仅在沙箱隔离环境(容器)中使用。

CI/CD 推荐:在 GitHub Actions 中优先用 read-only 做审查,workspace-write 做修复。绝不在共享 runner 上用 danger-full-access。

-p profile 与 --cd

控制执行环境与行为

-p / --profile

codex exec -p fast "quick review"
codex exec -p thorough "deep audit"

选择预配置的 permission profile,控制 Codex 的"冒险倾向"。

--cd 切换工作目录

codex exec --cd ./packages/api \
  "refactor this module"

让 Codex 在指定目录下执行,避免路径问题。CI 中必用。

--full-auto

codex exec --full-auto "fix lint errors"

--sandbox workspace-write 的便捷别名,CI 中最常用。

--output-last-message

codex exec -o result.txt "summarize"

把最终回复写入文件。CI 中提取结果最简单的方式。

# 组合示例:在指定目录用快速模式审查
codex exec --cd src/ -p fast -s read-only \
  --json "review security issues"

exec 核心参数速查

参数短写说明
PROMPT—位置参数,执行指令
-—从 stdin 读取 prompt
--json—JSONL 结构化输出
--sandbox-s沙箱模式
--profile-p权限配置 profile
--cd DIR-C执行目录
--model MODEL-m指定模型
--full-auto—workspace-write 便捷别名
--output-last-message-o最终回复写入文件
--output-schema FILE—结构化输出 schema
--ephemeral—不持久化 session 文件

交互模式 vs exec 模式

维度交互模式exec 模式
启动方式codexcodex exec "prompt"
输入终端 stdin 逐行参数 / stdin / 管道
输出终端富文本渲染stdout(纯文本或 JSONL)
退出码始终 0非零表示执行失败
上下文多轮共享历史单轮(可用 thread 恢复)
沙箱首次需确认命令行直接指定
适用场景探索、调试、学习CI/CD、批量处理、脚本
选择原则:需要"等用户下一步指示"用交互模式;定义好所有输入让 Codex 跑完就走用 exec 模式。

codex mcp-server

让 Codex 成为其他工具的后端

codex mcp-server 是 CLI 独有的子命令:把 Codex 引擎作为 MCP 服务器 暴露出去。其他 MCP 客户端(自定义工具、IDE 插件、Agent 框架)可以通过 标准 stdio 管道 连接到它。

# 直接连接
codex mcp-server | your_mcp_client

# 也可以作为 MCP server 添加到 ~/.codex/config.toml
# 让其他 Codex 实例能调用它

协议

JSON-RPC 2.0 over stdio,换行分隔。兼容任何 MCP 客户端实现。

暴露工具

codex() — 发起执行请求
codex-reply() — 继续已有对话

使用场景

构建自定义 Agent 框架、在 IDE 中嵌入 Codex、编排多个 Codex 实例协作。

mcp-server 协议细节

JSON-RPC 2.0 —— 轻量、通用、可调试

codex mcp-server 使用标准 MCP 传输协议。消息格式严格遵循 JSON-RPC 2.0 规范,通过 stdio 的一行一个 JSON 进行通信。

// 客户端 → 服务器:列出可用工具
{ "jsonrpc": "2.0", "id": 1, "method": "tools/list" }

// 服务器 → 客户端:工具定义
{ "jsonrpc": "2.0", "id": 1, "result": {
  "tools": [
    { "name": "codex", "description": "Execute a Codex turn" },
    { "name": "codex-reply", "description": "Reply to an existing thread" }
  ]
}}
// 客户端 → 服务器:调用 codex 工具
{ "jsonrpc": "2.0", "id": 2, "method": "tools/call",
  "params": {
    "name": "codex",
    "arguments": { "prompt": "fix the bug", "threadId": null }
  }
}

// 服务器 → 客户端:响应
{ "jsonrpc": "2.0", "id": 2,
  "result": { "content": [{"type": "text", "text": "Fixed."}] }
}

mcp-server 暴露的工具

codex(prompt, threadId?)

发起一次新的 Codex 执行。

  • prompt(必填)— 指令文本
  • threadId(选填)— 指定已有线程则继续对话

返回:执行结果的 content items 数组。

codex-reply(threadId, prompt)

在已有线程中追加回复。

  • threadId(必填)— 目标线程 ID
  • prompt(必填)— 追加的指令

返回:线程的新一轮执行结果。

实现提示:mcp-server 的内部引擎和 codex exec 是同一个 —— 都调用 Codex 的 Rust 核心。区别只在于入口和协议形式。

mcp-server 实战演示

用 Python 连接 codex mcp-server

import json, subprocess

proc = subprocess.Popen(
    ["codex", "mcp-server"],
    stdin=subprocess.PIPE,
    stdout=subprocess.PIPE,
    text=True
)

def rpc(method, params=None):
    msg = {"jsonrpc": "2.0", "id": 1, "method": method}
    if params: msg["params"] = params
    proc.stdin.write(json.dumps(msg) + "\n")
    proc.stdin.flush()
    return json.loads(proc.stdout.readline())

# 调用 codex 工具
result = rpc("tools/call", {
    "name": "codex",
    "arguments": {"prompt": "explain recursion in 2 lines"}
})
print(result["result"]["content"])
调试技巧:可以直接在终端运行 codex mcp-server 用 Ctrl+D 结束 —— 这样能看到它处理原始 JSON-RPC 消息的过程。

Python SDK —— openai-codex

用 Python 编排 Codex 工作流

官方 Python SDK 提供同步 API,适合脚本和自动化任务。

pip install openai-codex
from openai_codex import Codex

with Codex() as codex:
    thread = codex.thread_start()
    result = thread.run(
        "Explain this repository in three bullets."
    )
    print(result.final_response)

设计原则

  • Context manager 自动管理进程生命周期
  • thread / turn 模型与 CLI 一一对应
  • 结果对象包含完整元数据

安装要求

  • Python 3.10+
  • 已安装 codex CLI
  • 已完成 codex login

Python SDK 完整示例

多轮对话 + 读取结果对象

from openai_codex import Codex

with Codex() as codex:
    # 启动线程
    thread = codex.thread_start()

    # 第一轮:让 Codex 分析代码
    r1 = thread.run(
        "Find the top 3 performance bottlenecks in src/"
    )
    print("分析结果:", r1.final_response)
    print("执行项目数:", len(r1.items))

    # 第二轮:基于第一轮结果继续追问
    r2 = thread.run(
        "Rewrite the #1 bottleneck with an optimized version"
    )
    print("修复结果:", r2.final_response)
线程复用:同一 thread 对象上的多次 run() 调用会自动累积上下文 —— 就像交互式对话一样,但以编程方式控制。

Python SDK 异步用法

asyncio 并发多个 Codex 任务

import asyncio
from openai_codex import AsyncCodex

async def main():
    async with AsyncCodex() as codex:
        thread = await codex.thread_start()

        # 并发执行多个独立任务
        results = await asyncio.gather(
            thread.run("fix parse.py"),
            thread.run("fix render.py"),
            thread.run("fix route.py"),
        )
        for r in results:
            print(r.final_response[:200])

asyncio.run(main())

为什么需要异步?

I/O 密集型任务(pipe 到 Codex 进程)不用阻塞主线程。多个 Codex 实例可以并行处理不同文件。

注意

同一线程上的并发 run() 会按顺序排队。要真正并行,需要创建多个独立线程。

Python SDK Sandbox 控制

逐 turn 细粒度权限

Python SDK 允许在 thread_start() 和 run() 级别分别设置沙箱模式:

from openai_codex import Codex, Sandbox

with Codex() as codex:
    # 线程级别:workspace-write
    thread = codex.thread_start(sandbox=Sandbox.workspace_write)

    # 第一轮:正常写操作
    thread.run("Add input validation to the form")

    # 第二轮覆盖为 read-only(只审查)
    review = thread.run(
        "Review the diff only.",
        sandbox=Sandbox.read_only  # 覆盖线程默认
    )
    print(review.final_response)

三个层级

  • Sandbox.read_only — 只读
  • Sandbox.workspace_write — 默认
  • Sandbox.full_access — 无限制

覆盖语义

run() 级别的 sandbox 只影响当前 turn 及之后。不传则继承线程默认值。

TypeScript SDK

在 Node.js 中编排 Codex

官方 TypeScript SDK 适合构建 CLI 工具、VS Code 扩展、GitHub Action。

npm install @openai/codex-sdk
import { Codex } from "@openai/codex-sdk";

const codex = new Codex();
const thread = codex.startThread();
const turn = await thread.run(
  "Diagnose the test failure and propose a fix"
);

console.log(turn.finalResponse);
console.log(turn.items);

传递认证信息

const codex = new Codex({
  baseUrl: "https://api.openai.com/v1",
  apiKey: process.env.OPENAI_API_KEY,
});

配置覆盖

const codex = new Codex({
  config: {
    sandbox_workspace_write: {
      network_access: true
    }
  }
});

TypeScript resume 与流式

恢复已有线程 + 事件监听

// 恢复已有线程
const threadId = "<thread-id>";
const thread2 = codex.resumeThread(threadId);
const result2 = await thread2.run(
  "Pick up where you left off"
);
console.log(result2.finalResponse);

SDK vs codex exec

SDK 控制的是本地 Codex 进程(通过 app-server JSON-RPC),不是直接调用 OpenAI API。认证由本地 codex login 管理,无需在 SDK 代码中传 apiKey。

何时用 SDK vs exec

  • SDK:需要 thread 管理、多轮编程对话、自定义事件处理
  • exec:简单的一次性脚本、CI 流水线

OSS 本地模型

数据不出本机的 Codex

Codex 支持连接本地运行的 Ollama 或 LM Studio 作为模型后端。所有推理在本地完成,无需 API 调用。

适用场景

  • 处理 HIPAA / GDPR / PCI 合规数据
  • 内网隔离环境(无互联网)
  • 降低 API 成本(大量自动化任务)
  • 模型行为可审计(本地可复现)

支持的提供者

  • Ollama — localhost:11434
  • LM Studio — localhost:1234

通过 oss_provider 配置项或 --oss 标志启用。

关键限制:本地模型的代码能力取决于所选模型。代码任务推荐 7B+ 参数的 instruct 模型,如 codellama、deepseek-coder、qwen2.5-coder。

OSS 配置方式

config.toml 与环境变量

在 ~/.codex/config.toml 中声明 OSS provider:

# ~/.codex/config.toml
[model_providers.my-local]
name = "My Local LLM"
base_url = "http://localhost:11434/v1"
wire_api = "chat"

# 指定 provider
model_provider = "my-local"

更简单的方式 —— 用 --oss 标志或 oss_provider 配置:

# 方式 1:命令行标志(默认 Ollama)
codex --oss "fix the build"

# 方式 2:config.toml 指定 OSS provider
# oss_provider = "lmstudio"   # 或 "ollama"

# 方式 3:自定义 provider(非标端口等)
# [model_providers.my-ollama]
# name = "My Ollama"
# base_url = "http://localhost:8080/v1"
# model_provider = "my-ollama"

OSS 模型要求

不是所有模型都适合 Codex

硬指标

  • 支持 OpenAI-compatible /v1 API
  • 至少 7B 参数(代码任务推荐 14B+)
  • 支持 system prompt
  • 支持 tool calling(function calling)

推荐模型

  • codellama:13b — Meta,代码专精
  • deepseek-coder:6.7b — 体积小能力强
  • qwen2.5-coder:7b — 阿里,中文支持好

Codex 自动行为

首次运行时,Codex 会检查模型是否已 pull。如果不存在,会自动拉取(显示进度条)。

OSS 限制与权衡

维度云端模型 (GPT)本地模型 (OSS)
代码质量SOTA,一步到位依赖模型,可能需要多轮
延迟2-10s(取决于 prompt)0.5-30s(取决于硬件)
数据隐私数据上 API数据不出本机
成本按 token 计费零 API 费用
网络需要互联网完全离线
工具支持所有 feature部分 behavior 可能退化
注意:本地模型在复杂多文件重构、精确 diff 生成等任务上可能不如 GPT-5.6 / gpt-5.6-mini。建议简单任务用 OSS,复杂任务回退到云端。

实战 1:CI 自动化

用 codex exec + --json 嵌入 GitHub Actions

在 CI 中自动 review PR、生成 changelog、检查安全漏洞:

# .github/workflows/codex-review.yml
name: Codex Code Review
on: [pull_request]

jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Setup Node (for codex CLI)
        uses: actions/setup-node@v4
        with: { node-version: "20" }
      - name: Install Codex CLI
        run: npm install -g @openai/codex
      - name: Codex Review
        env:
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
        run: |
          codex exec \
            --cd "$GITHUB_WORKSPACE" \
            -s read-only \
            --json "Review this PR for bugs, security issues, and style problems."
          echo "Review complete."
最佳实践:CI 中始终用 -s read-only 或 -s workspace-write,避免 danger-full-access。把结果输出为 JSON 便于后续步骤解析。

实战 2:批量处理文件

for loop + codex exec 批处理

给仓库中每个 Python 文件添加类型注解:

#!/bin/bash
# 批量为 Python 文件添加类型注解
for file in $(find src/ -name "*.py"); do
  echo "Processing: $file"
  codex exec \
    --cd "$(dirname $file)" \
    -s workspace-write \
    "Add type annotations to every function. Do not change logic."
  if [ $? -ne 0 ]; then
    echo "ERROR: Failed on $file" >&2
    exit 1
  fi
done
echo "All files processed."

错误处理

检查 $? 退出码 —— 非零意味着 Codex 执行失败。可记录并跳过继续。

并行化

对独立文件可用 GNU parallel 或 xargs -P 加速。注意 API 并发限额。

实战 3:Python SDK 自动化工作流

"代码审计 + 修复 + 验证"流水线

from openai_codex import Codex, Sandbox

def audit_and_fix(project_path: str):
    with Codex() as codex:
        thread = codex.thread_start(
            sandbox=Sandbox.workspace_write
        )

        # 1. 安全审计
        audit = thread.run(
            "Scan for SQL injection, XSS, "
            "and hardcoded secrets."
        )
        print(f"Found {len(audit.items)} issue items")

        # 2. 修复
        fix = thread.run(
            "Fix all HIGH severity issues. "
            "Leave MEDIUM and LOW as TODOs."
        )

        # 3. 验证(只读回顾)
        final = thread.run(
            "Re-review: are all HIGH issues resolved?",
            sandbox=Sandbox.read_only
        )
        print("Verification:", final.final_response[:200])

audit_and_fix("./myproject")

实战 4:Ollama 处理敏感任务

内部代码审查,数据零上云

# 终端 1:启动 Ollama(如果未运行)
ollama serve &
ollama pull codellama:13b-instruct

# 终端 2:运行 Codex 连接本地模型
codex --oss \
  --cd ./internal-docs/ \
  -s read-only \
  "Review this data pipeline for compliance risks."

# 或者直接用 --model 覆盖
codex exec --model codellama:13b-instruct \
  -s read-only \
  "Audit this code for PII leaks."

性能提示

13B 模型在消费级 GPU(如 RTX 3060 12GB)上可达 20-30 tokens/s。单文件审查足够用。

降级策略

如果 Ollama 输出质量不够,可用 --model gpt-5.6 回退到云端处理复杂修复。

实战 5:mcp-server + Python Agent

把 Codex 嵌入自定义 Agent 框架

#!/usr/bin/env python3
"""一个极简的 Codex-backed Agent"""
import json, subprocess, sys

class CodexAgent:
    def __init__(self):
        self.proc = subprocess.Popen(
            ["codex", "mcp-server"],
            stdin=subprocess.PIPE,
            stdout=subprocess.PIPE,
            text=True
        )
        self._id = 0

    def call(self, name, arguments):
        self._id += 1
        msg = {"jsonrpc": "2.0", "id": self._id,
               "method": "tools/call",
               "params": {"name": name,
                          "arguments": arguments}}
        self.proc.stdin.write(json.dumps(msg) + "\n")
        self.proc.stdin.flush()
        resp = json.loads(self.proc.stdout.readline())
        return resp.get("result", {})

    def run(self, task):
        return self.call("codex", {"prompt": task})

if __name__ == "__main__":
    agent = CodexAgent()
    r = agent.run(sys.argv[1])
    print(r["content"][0]["text"])
为何不直接 shell exec codex?mcp-server 保持长连接、复用引擎进程,避免每次启动开销。适合高频调用。

实战 5 续:多步 Agent 循环

持续对话直到任务完成

def run_until_done(agent, goal, max_turns=10):
    """让 Codex agent 自主迭代直到任务完成"""
    thread_id = None
    for i in range(max_turns):
        result = agent.call(
            "codex" if not thread_id else "codex-reply",
            {"prompt": goal if not thread_id
                     else "continue from previous step",
             "threadId": thread_id},
        )
        text = result["content"][0]["text"]
        thread_id = result.get("threadId", thread_id)
        print(f"[Turn {i+1}] {text[:300]}")
        if "DONE" in text or "finish" in text:
            break

if __name__ == "__main__":
    agent = CodexAgent()
    run_until_done(agent, "fix all lint issues in src/")
设计关键:每次调用返回的 threadId 必须传递给下一次 —— 这相当于在 Agent 框架中维护会话状态。

实战选择指南

场景推荐方式理由
CI review PRcodex exec --json退出码 + 结构化输出易解析
批量处理 50 文件Python SDK + AsyncCodex并发控制 + 错误恢复
敏感数据审计Ollama + codex exec数据不出本机
IDE 插件后端codex mcp-server标准 MCP 协议连接
GitHub ActionTypeScript SDK与 actions toolkit 同生态
探索/交互式codex 交互模式最自然的工作方式

常见错误(上)

exec prompt 被 shell 吃掉

# ❌ 错误:特殊字符被 shell 解析
codex exec "fix bug in src/file (urgent)!"

# ✅ 正确:用引号保护或 stdin
echo "fix bug in src/file (urgent)!" | codex exec -

exec 退出码含义误解

# ❌ 误解:$? 反映任务结果
codex exec "fix it"
if [ $? -eq 0 ]; then echo "Fixed!"; fi

# ✅ 正确:用 --json + jq 判断
codex exec --json "fix it" | jq -e \
  "select(.type==\"turn.completed\")"

CI 中缺少认证

# ❌ 报错:not authenticated

# ✅ 正确:CI 用 OPENAI_API_KEY 替代 login
env:
  OPENAI_API_KEY: \${{ secrets.OPENAI_API_KEY }}
run: codex exec "..."

常见错误(下)

Ollama 端口冲突

# ❌ 默认端口被占用
# "connection refused on :11434"

# ✅ 正确:在 config.toml 中自定义 provider
# [model_providers.my-ollama]
# base_url = "http://localhost:11435/v1"
# model_provider = "my-ollama"

Python SDK 线程未 clean up

# ❌ 进程残留
codex = Codex()
thread = codex.thread_start()
# 子进程还在跑

# ✅ 正确:用 context manager
with Codex() as codex:
    thread = codex.thread_start()
    thread.run("...")
# 退出 with 块自动清理

mcp-server 消息缺换行

# ❌ 忘记换行符
proc.stdin.write(json.dumps(msg))

# ✅ 正确:每条消息以 \n 结尾
proc.stdin.write(json.dumps(msg) + "\n")
proc.stdin.flush()

Codex 脚本化生态全景

图:Codex CLI 脚本化生态全景
一句话总结:CLI 是入口,exec 是脚本之门,SDK 是编排之手,mcp-server 是连接之桥,OSS 是隐私之盾。

全系列回顾

11 章旅程,从安装到脚本化

章节核心能力一句话记忆
01 安装环境搭建先跑起来再说
02 AGENTS.md行为配置告诉 AI 你是谁
03 Skills能力扩展给 AI 装工具包
04 Slash 命令交互增强/ 触发即时动作
05 MCP工具协议接入外部世界
06 Subagents多代理AI 调用 AI
07 Hooks事件驱动关键时刻自动出手
08 沙箱与权限命令精通理解每一行参数
09 线程管理个性化打造专属 AI 助手
10 Review 与协作经验沉淀少踩坑,多产出
11 CLI 与脚本化自动化让 AI 工作在流水线中

你的学习路径

从"会用"到"驾驭"

入门者

先掌握 codex exec + --json。写一个 GitHub Action 让它自动 review PR。感受自动化的快感。

团队开发者

用 Python SDK 构建内部工具链:批量重构、安全扫描、代码文档生成。配合 Ollama 保护数据隐私。

平台工程师

深入研究 codex mcp-server 协议,构建自定义 Agent 框架。让 IDE、CI、内部系统都能调用 Codex。

终点不是学会,而是融入:当 Codex 像 grep、git 一样自然地出现在你的命令行和脚本中,才算真正掌握。

本章总结

核心要点

  • codex exec —— 非交互执行,CI/CD 之魂
  • --json —— 结构化输出,脚本可解析
  • --sandbox —— 安全边界,权限可控
  • Python / TypeScript SDK —— 编排之手
  • codex mcp-server —— 连接之桥
  • Ollama / LM Studio —— 隐私之盾

心智模型

  • 交互模式 = 对话;exec 模式 = 命令
  • --json 把输出变成数据而非文本
  • SDK 是 exec 的编程化封装
  • mcp-server 让 Codex 可被其他工具调用
  • OSS 模型 = 能力本地化,隐私优先
推荐延伸阅读:OpenAI 官方 Codex CLI 文档、Ollama 模型库、MCP 协议规范、GitHub Actions 官方教程。
完结

CLI 与脚本化

把 Codex 从"聊天伙伴"变成"生产工具"

第 12 章 - 全系列的最后一章

致谢

你读完了全部 11 章。从安装到脚本化,从交互到自动化 —— 现在 Codex 不再只是工具,而是你工作流的一部分。

下一步

动手实践是最好的复习。选一个你日常重复的任务,用 codex exec 或 Python SDK 自动化它。你会惊讶于"原来可以这样"。