在 GitHub Actions 中使用 interpreter exec：为 Open Interpreter 构建 CI 代码审查自动化

Open Interpreter 提供了以非交互方式运行受限自动化任务的 interpreter exec 命令。本文面向希望把 AI 代码审查、变更摘要等一次性任务接入 CI 的工程团队，说明如何在 GitHub Actions 工作流中完成安装、模型提供方配置、沙箱安全策略选择，以及如何以 JSON 事件或纯文本文件形式消费 Agent 的输出。读完本文后，你将能够搭建一个在 pull request 上自动运行、使用可审计沙箱且可被下游任务解析的 Open Interpreter 自动化步骤。

背景：exec 与交互式会话的分工

Open Interpreter（docs/github-action.md）把「在 CI 中跑一次有边界（bounded）的自动化任务」作为一等使用场景，并为此提供了 interpreter exec。与日常在终端中输入 i 或 interpreter 启动的交互式会话不同，exec 只运行一次非交互会话：给定一段指令（prompt），Agent 自主执行，会话结束即退出。它的适用面包括 PR diff 审查、风险摘要、测试补齐检查等可以独立完成、无需人工中途介入的任务。

从源码看，该命令对应一个独立的 exec CLI。在 codex-rs/exec/src/cli.rs 中，Cli 结构以「无参数位置提示词」为核心输入（prompt: Option<String>），并以子命令形式支持 resume（恢复历史会话）与 review（对当前仓库做代码审查）两种进阶用法。注意：该仓库是 Rust 版 Open Interpreter（README 明确说明它是基于 Codex 的 Rust 重写），因此这些命令名与参数在文档与源码中保持一致。

基础工作流：在 pull request 上自动审查 diff

原文档给出的最小可运行工作流如下，它把「Install Open Interpreter」与「Review the patch」两步串起来：

name: Open Interpreter Review

on:
  pull_request:

jobs:
  review:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: read
    steps:
      - uses: actions/checkout@v4

      - name: Install Open Interpreter
        run: curl -fsSL https://www.openinterpreter.com/install | sh

      - name: Review the patch
        env:
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
        run: |
          git diff origin/${{ github.base_ref }}...HEAD |
            interpreter exec --sandbox read-only \
              "Review this pull request diff for bugs, regressions, and missing tests."

几个值得注意的设计点：

• 权限最小化：job 只申请 contents: read 与 pull-requests: read，整个流程只读，不向仓库写任何内容，符合默认安全姿态。
• 安装方式：macOS 与 Linux 均通过官方安装脚本 curl -fsSL https://www.openinterpreter.com/install | sh 安装（README 的 Installation 一节使用同一命令）。Windows 则对应 irm .../install.ps1 | iex，但 CI 中 ubuntu-latest 无需关心。
• diff 通过 stdin 传入：git diff origin/<base_ref>...HEAD 的输出被管道给 interpreter exec。这正是 exec 的输入约定：当位置参数 PROMPT 给出指令、同时 stdin 被管道注入内容时，stdin 会作为 <stdin> 块追加给模型（见 codex-rs/exec/src/cli.rs 对 PROMPT 参数语义的说明）。因此模型的审查既有指令，又有真实的补丁全文。
• 沙箱兜底：--sandbox read-only 保证 Agent 只能读文件，即便提示词诱导其改动文件也无法落地。

模型提供方配置：环境变量 + 配置覆盖

exec 复用你本地使用的提供方环境变量，最通用的做法是在 step 上声明 env，把 API Key 绑定到 GitHub Actions 的 Secrets：

env:
  OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}

Secrets 在仓库 Settings → Secrets and variables → Actions 中预先创建，Key 名与模型提供方要求的环境变量名保持一致即可。

切换提供方则通常需要做两件事：设置该提供方的 API Key 环境变量，以及通过 -c（--config）覆盖相关配置。原文档以 Kimi 为例给出完整写法：

- name: Run with Kimi
  env:
    MOONSHOT_API_KEY: ${{ secrets.MOONSHOT_API_KEY }}
  run: |
    interpreter exec \
      -c 'model_provider="moonshotai"' \
      -c 'harness="kimi-code"' \
      -m kimi-k3 \
      "Summarize the risky parts of this change."

这条命令展示了三层配置手段的组合：

• -m kimi-k3：-m/--model 是共享 CLI 选项，直接选择模型（源码见 codex-rs/utils/cli/src/shared_options.rs）。Kimi K3 是当前项目重点支持的开放权重模型，README 顶部即标注「Kimi K3 is here」，仓库内还有 docs/kimi-k3.md 与 docs/zh/kimi-k3.md 提供专项接入指引。
• -c 'model_provider="moonshotai"'：-c/--config 以 key="value" 形式注入配置覆盖（见 codex-rs/utils/cli/src/config_override.rs，注释示例中即有 -c 'sandbox_permissions=[...]' 这类用法），这里把模型提供方指定为 Moonshot AI。
• -c 'harness="kimi-code"'：harness 决定以何种「智能体外壳」驱动模型。README 的 Harness Emulation 一节列出 native、claude-code、zcode、kimi-code、qwen-code、deepseek-tui、swe-agent 等可用 harness，本项目通过重实现 Kimi Code 的 Rust harness 来最大化 K3 性能。

类似地，DeepSeek、Z.AI/GLM 等提供方也有对应文档：docs/deepseek.md、docs/zai-glm.md。完整的 exec 参数行为可对照 docs/cli-reference.md。

消费输出：JSON 事件或最终摘要

CI 中 interpreter exec 的输出有两种可编程消费方式，恰好对应 exec CLI 里的两个全局参数（定义见 codex-rs/exec/src/cli.rs）。

JSONL 事件流（机器可读）

- name: Produce review events
  run: |
    interpreter exec --json \
      "List the files changed and the highest-risk issue." \
      > interpreter-events.jsonl

--json（旧别名 --experimental-json）让所有事件以 JSONL 形式打到 stdout，便于后续 step 用 jq、Python 或自研解析器消费。仓库里对这类输出的行为有测试覆盖，例如 codex-rs/exec/src/event_processor_with_jsonl_output_tests.rs 直接命名为 event_processor_with_jsonl_output_tests，其中还有「失败轮次不会覆盖 output-last-message 输出文件」的断言，说明 JSON 事件与最终消息文件是两条独立输出通道。

常见消费方式是在同一 job 内追加步骤：先用 actions/upload-artifact 把 interpreter-events.jsonl 归档，或直接在后续 step 中解析并作为后续逻辑（例如标注「高风险」的 label）的输入。

最终消息落盘（人类可读）

- name: Write summary
  run: |
    interpreter exec \
      --output-last-message interpreter-summary.md \
      "Summarize the current diff for a release manager."

--output-last-message FILE（短选项 -o FILE）把会话的最后一轮助手消息写入指定文件。对需要「把审查结论贴回 PR 评论」或作为发布材料附件的场景，这是最直接的方式——你拿到的是一份干净的 Markdown 摘要，而非完整事件流。

其他值得在 CI 中组合的参数

结合 codex-rs/exec/src/cli.rs 中 exec 参数的语义，以下选项常用于加固或约束 CI 任务：

参数	作用	CI 建议
--sandbox read-only（-s）	选择沙箱策略，见下文安全小节	默认必带
--json	事件以 JSONL 输出到 stdout	需要机器解析时
-o/--output-last-message FILE	最终消息写入文件	需要摘要文本时
--output-schema FILE	以 JSON Schema 约束模型最终输出形状	下游强类型解析时
--ephemeral	不把会话文件持久化到磁盘	一次性审查场景省 IO
--skip-git-repo-check	允许在非 Git 仓库目录运行	通常不需要（CI 已 checkout）
--ignore-user-config / --ignore-rules	跳过用户级 config.toml / 跳过用户与项目的 execpolicy .rules	希望 CI 环境纯净可考虑

安全：CI 中 Agent 的默认姿态

原文档给出一条简洁的安全原则：除非工作流明确需要改动文件，否则一律以 --sandbox read-only 启动 CI 作业。

这在 exec 的共享 CLI 选项中有直接对应。查看 codex-rs/utils/cli/src/shared_options.rs：--sandbox（-s）用于「选择模型生成 shell 命令时的沙箱策略」，而共享沙箱参数的统一类型由 codex-rs/utils/cli/src/sandbox_mode_cli_arg.rs 提供。同一处还定义了 --dangerously-bypass-approvals-and-sandbox（注释明确标注「EXTREMELY DANGEROUS」，仅适合外部已做沙箱隔离的环境），以及走 workspace-write 沙箱的自动审查选项——这些高风险开关不应出现在面向 PR 的公开 CI 中。

如果某个任务确实需要 Agent 提交改动（例如自动修复后开新 commit），原文档建议守住三条底线：

1. 收窄提示词：把任务限定在具体的文件与动作，不给出「尽量完善」这类开放指令；
2. 事后跑测试：在提交前用 CI 的既有测试 job 验证 Agent 改动的正确性；
3. 保留评审保护：合并前维持常规的 GitHub review 保护（branch protection、required reviews 等），让 AI 改动与人工提交走同一道审批关卡。

进阶组合：把审查结论回写到 PR

当你要把上面的能力串成完整闭环时，可以参考以下思路（该组合示例基于本文各片段拼接，供理解各参数如何协作）：

jobs:
  review:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write   # 需要写 PR 评论时放开
    steps:
      - uses: actions/checkout@v4
      - name: Install Open Interpreter
        run: curl -fsSL https://www.openinterpreter.com/install | sh

      - name: Run review
        id: review
        env:
          MOONSHOT_API_KEY: ${{ secrets.MOONSHOT_API_KEY }}
        run: |
          git diff origin/${{ github.base_ref }}...HEAD > /tmp/diff.txt
          interpreter exec --sandbox read-only \
            -c 'model_provider="moonshotai"' \
            -c 'harness="kimi-code"' \
            -m kimi-k3 \
            -o interpreter-summary.md \
            "Review the diff in /tmp/diff.txt; list the top 3 risks."
          echo "summary=$(cat interpreter-summary.md)" >> "$GITHUB_OUTPUT"

      - name: Post comment
        uses: actions/github-script@v7
        with:
          script: |
            github.rest.issues.createComment({
              issue_number: context.issue.number,
              owner: context.repo.owner,
              repo: context.repo.repo,
              body: process.env.SUMMARY
            })
        env:
          SUMMARY: ${{ steps.review.outputs.summary }}

注意两点边界：把 diff 写入 /tmp 并让 Agent 按路径读取，避免超长 stdin 覆盖 prompt；写 PR 评论需显式放开 pull-requests: write，与只读审查 job 的最小权限形成对比。

小结

interpreter exec 是 Open Interpreter 在自动化场景下的统一入口：--sandbox read-only 提供默认安全边界，环境变量加 -c 覆盖实现对不同模型提供方（OpenAI、Kimi/Moonshot、DeepSeek、Z.AI/GLM 等）的无缝切换，--json 与 --output-last-message 分别满足机器解析与摘要落盘两类下游需求。基于 docs/github-action.md 给出的骨架，你可以快速搭建 PR 审查、变更风险摘要等流水线；更深入的行为细节可继续阅读 docs/cli-reference.md、docs/sandbox.md 与 docs/zh/github-action.md（中文版）。