在 GitHub Actions 中运行 Open Interpreter：用 `interpreter exec` 构建一次性 CI 自动化任务

在 GitHub Actions 中运行 Open Interpreter：用interpreter exec构建一次性 CI 自动化任务

【免费下载链接】openinterpreterA coding agent for open models like Kimi K3 and GLM 5.3项目地址: https://gitcode.com/GitHub_Trending/op/openinterpreter

本文面向希望把 AI 编程代理接入持续集成（CI）的开发者，讲解如何在 GitHub Actions 中借助 Open Interpreter 的interpreter exec非交互模式执行一次有边界的自动化任务（例如审查 Pull Request 的 diff、产出变更摘要与风险清单）。读完本文，你将掌握完整的工作流 YAML 写法、模型与密钥的提供者配置方法、机器可读输出（JSONL 事件 / 最终消息文件）的获取方式，以及让 CI 作业以read-only沙箱安全运行的关键实践。

Open Interpreter 是一个面向低成本开放模型（如 Kimi K3、GLM 系列）优化的编码代理，其仓库以 README.md 的方式公开了安装与 Harness 模拟能力，而interpreter exec正是面向脚本化、单次运行的入口。

适用场景：为什么在 CI 中选择interpreter exec

GitHub Actions 中的每一次运行都是临时的、隔离的、有明确退出码的一次性环境，这与交互式终端会话天然不同。interpreter exec的存在意义在于：让 Open Interpreter 以非交互（non-interactive）方式运行一次受限的自动化任务，任务结束即退出，输出可以被后续步骤消费。相关文档将interpreter exec明确定义为非交互式运行入口（见 cli-reference.md）。

典型场景包括：

• 审查 Pull Request 的 diff，找出 bug、回归与缺失的测试；
• 为变更生成面向发布经理的摘要；
• 列出变更文件并定位最高风险点；
• 对仓库执行只读审计类检查。

与交互式会话不同，exec 模式的核心约束是"有界"：一次任务、一次回答、退出码与文件化输出，恰好贴合 CI 对可预测性与可观测性的要求。

前置条件：在 runner 上安装与验证

GitHub Actions 的ubuntu-latest运行器默认不包含 Open Interpreter，需要在 workflow 中先完成安装。官方文档给出的安装命令为：

curl -fsSL https://www.openinterpreter.com/install | sh

同样的安装方式也记录在仓库根目录 README.md 中（macOS/Linux 使用curl，Windows 使用 PowerShell 的irm形式）。安装完成后即可在后续步骤中调用interpreter exec。本仓库亦保留了对应的安装脚本实现与测试，见 scripts/install/install.sh 与 scripts/install/test_install_sh.py，以及中文安装文档 install.md。

注意：本文所有命令以文档与仓库中公开的interpreter命令名为准；若在仓库源码层面（codex-rs/exec/src/cli.rs）查看，其底层 usage 仍写作codex exec，说明二者是同一套 exec 实现的不同发布形态。

基本工作流：自动化审查 Pull Request

文档给出的最简可用工作流如下，它在 PR 事件触发后安装 Open Interpreter，将目标分支与当前分支的 diff 管道式地交给代理评审：

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."

逐段拆解如下：

1. 事件与权限：on: pull_request使工作流在 PR 打开/更新时触发；permissions显式收缩为contents: read与pull-requests: read，遵循最小权限原则——评审任务只需要读取仓库内容与 PR 元数据，不需要写入权限。
2. 检出代码：actions/checkout@v4检出代码。注意 GitHub Actions 默认的检出深度（depth 1）配合事件上下文，可借助github.base_ref拿到基础分支名。
3. 安装代理：使用官方安装脚本。
4. 评审 diff：关键技巧是git diff origin/${{ github.base_ref }}...HEAD计算从基础分支到当前 HEAD 的变更，再通过管道（|）交给interpreter exec。

diff 为什么能通过管道传入

从源码层面看，exec 的 prompt 参数设计为：当位置参数未提供（或显式传入-）时，指令从标准输入（stdin）读取；若 stdin 同时被管道输入且位置参数也提供了 prompt，stdin 内容会作为<stdin>块追加进提示（见 cli.rs）。这就是"git diff ... | interpreter exec "...""这一管道写法能够工作的底层机制——diff 文本会成为代理可读的上下文。

模型与提供者设置

在 CI 中与本地一样，使用同样的提供者环境变量即可完成鉴权。以 OpenAI 为例，将 API Key 放入 GitHub Secrets，再通过env注入：

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

切换其他提供者（以 Kimi 为例）

对于其他提供者，设置对应 API Key，并通过-c传入配置覆盖（config overrides）、用-m指定模型：

- 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."

参数含义：

• -c 'model_provider="moonshotai"'：覆盖配置中的model_provider字段，选择 Moonshot AI 作为提供者。-c以key="value"的 TOML 风格片段工作，可多次使用，作用相当于命令行内联的配置层。
• -c 'harness="kimi-code"'：选择kimi-codeHarness。Open Interpreter 的核心定位之一就是复刻各提供商推荐的 agent harness 以获得低成本模型的最佳表现（见 README.md，其中kimi-code位于/harness可切换的 harness 列表内）。
• -m kimi-k3：指定模型为 Kimi K3。

关于 Kimi K3 的详细用法，可继续阅读同仓库的 kimi-k3.md。所有-c覆盖字段与model_provider的取值规则，可参考 config-reference.md 与 providers.md。

关于模型提供方支持与 Harness 的说明

Open Interpreter 专门面向 Kimi K3、GLM 5.3 等开放/低成本模型优化（见仓库 README.md 中的说明）。因此在不同提供者之间切换（-c+-m）不仅是换一个密钥，还需要匹配该提供者推荐的 harness 与模型名。接入时请以当前所选提供者的实际配置为准。

输出捕获：JSONL 事件与最终消息文件

CI 自动化通常不需要人类阅读终端彩色输出，而是需要结构化、可被后续步骤消费的结果。interpreter exec提供两种互补的输出形态，其底层实现约定了严格的 stdout 纪律（见 lib.rs）：

• 默认输出模式下，stdout 只写最终消息；
• --json模式下，stdout 必须是合法的 JSONL（JSON Lines），每行一个事件；
• 其余任何非结构化输出一律走 stderr。

机器可读：JSON 事件流

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

--json开关（源码中定义于 cli.rs，并保留experimental-json别名）让代理将运行过程以事件流形式输出。每一行都是一条 JSON 事件，覆盖会话配置、命令执行、工具调用、最终回答等类型。重定向到interpreter-events.jsonl后，可以用actions/upload-artifact归档，或由后续步骤逐行解析——例如提取final_message事件作为评审结论，再以actions/github-script等官方方式回写到 PR 评论。

人类可读：最终回答写入文件

- 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，源码见 cli.rs）把最后一条助手消息原样写入指定文件，适合生成 Markdown 摘要、评审意见等"最终成品"。若需要接入下一次运行或合并前的审阅环节，让下游步骤读取该文件即可。

作为 PR 评审意见落地的建议流程

1. --json收集结构化事件，或用--output-last-message产出 Markdown 摘要；
2. 用上传/输出机制（如GITHUB_OUTPUT、artifact）把结果传递给后续 job；
3. 由普通 GitHub Action（如发评论、建 Check Run）消费结果。

安全：让 CI 作业在受控沙箱中运行

CI 是自动触发、无人工值守的环境，安全边界必须显式声明而非依赖默认值。官方文档给出明确建议：除非工作流特意要编辑文件，否则一律以--sandbox read-only启动 CI 作业。

run: | interpreter exec --sandbox read-only \ "Review this pull request diff for bugs, regressions, and missing tests."

--sandbox（短选项-s）的可选模式在 cli-reference.md 中有完整罗列：

read-only沙箱保证了代理即使被"诱导"也无法对工作区造成破坏，从而把 AI 评审限定在"只读顾问"的角色上。若确实需要提交更改（例如自动修复并推送），文档强调应保持三点纪律：

1. 提示词收窄：只让代理执行范围极小、目标明确的改动；
2. 随后运行测试：用既有测试套件验证代理产出的修改；
3. 合并前启用正常评审保护：依赖分支保护、PR review、required checks 等 GitHub 原生机制把关。

此外，还可以结合 execpolicy（执行策略）为 CI 环境定义更细粒度的命令白名单/黑名单，参见 execpolicy.md；对沙箱工作原理的完整讨论参见 sandbox.md。

延伸：把一次性 exec 扩展为更精细的评审管线

从 exec 命令的实现结构看（cli.rs），interpreter exec除默认的"单次新会话"外还内置了resume与review两个子命令：

• review：针对当前仓库的**未提交改动（--uncommitted）、指定基础分支（--base <branch>）或单个提交（--commit <sha>）**运行评审，适合在 CI 中对本地工作区/指定范围直接执行内置评审逻辑（参数定义见 cli.rs）；
• resume：按会话 ID 恢复历史会话，--last可续接最近一次记录（cli.rs）。

对应的命令行示例（见 cli-reference.md）：

interpreter exec "fix the failing test" interpreter exec --json "summarize this repo" interpreter exec resume --last "continue" interpreter exec review --uncommitted

如果你的目标是"常规的 PR 自动评审"，也可以直接使用内置 review 能力或在动作仓库中检索现成封装（参见 auto-review.md）。

小结

把 Open Interpreter 接入 GitHub Actions 的正确姿势可以浓缩为四句话：

1. 用interpreter exec，让任务一次运行、干净退出；
2. 用管道喂上下文（git diff ... |），因为 exec 在没有位置 prompt 时会从 stdin 读取指令；
3. 用--json或--output-last-message收口输出，让机器可解析、人可阅读；
4. 用--sandbox read-only收口权限，配合最小 GitHub 权限与常规评审保护，把 AI 代理放在"只读顾问"的安全位置。

相关文档与实现可以继续在仓库中深入：CLI 完整参考见 cli-reference.md，exec 入口与参数解析实现见 codex-rs/exec/src/cli.rs，stdout 输出纪律说明见 codex-rs/exec/src/lib.rs，沙箱与执行策略参见 sandbox.md 与 execpolicy.md。

【免费下载链接】openinterpreterA coding agent for open models like Kimi K3 and GLM 5.3项目地址: https://gitcode.com/GitHub_Trending/op/openinterpreter