尧图网站建设 
在 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 execGitHub 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 使用curlWindows 使用 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/checkoutv4 - 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.逐段拆解如下事件与权限on: pull_request使工作流在 PR 打开/更新时触发permissions显式收缩为contents: read与pull-requests: read遵循最小权限原则——评审任务只需要读取仓库内容与 PR 元数据不需要写入权限。检出代码actions/checkoutv4检出代码。注意 GitHub Actions 默认的检出深度depth 1配合事件上下文可借助github.base_ref拿到基础分支名。安装代理使用官方安装脚本。评审 diff关键技巧是git diff origin/${{ github.base_ref }}...HEAD计算从基础分支到当前 HEAD 的变更再通过管道|交给interpreter exec。diff 为什么能通过管道传入从源码层面看exec 的 prompt 参数设计为当位置参数未提供或显式传入-时指令从标准输入stdin读取若 stdin 同时被管道输入且位置参数也提供了 promptstdin 内容会作为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_providermoonshotai \ -c harnesskimi-code \ -m kimi-k3 \ Summarize the risky parts of this change.参数含义-c model_providermoonshotai覆盖配置中的model_provider字段选择 Moonshot AI 作为提供者。-c以keyvalue的 TOML 风格片段工作可多次使用作用相当于命令行内联的配置层。-c harnesskimi-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 必须是合法的 JSONLJSON 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 评审意见落地的建议流程--json收集结构化事件或用--output-last-message产出 Markdown 摘要用上传/输出机制如GITHUB_OUTPUT、artifact把结果传递给后续 job由普通 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 中有完整罗列模式含义CI 适用性read-only只读沙箱禁止对文件系统的写入推荐评审、摘要、审计类任务workspace-write允许写入当前工作区仅当任务需要生成补丁、提交修改时danger-full-access完全访问权限不应用于 CI除非完全信任任务read-only沙箱保证了代理即使被诱导也无法对工作区造成破坏从而把 AI 评审限定在只读顾问的角色上。若确实需要提交更改例如自动修复并推送文档强调应保持三点纪律提示词收窄只让代理执行范围极小、目标明确的改动随后运行测试用既有测试套件验证代理产出的修改合并前启用正常评审保护依赖分支保护、PR review、required checks 等 GitHub 原生机制把关。此外还可以结合 execpolicy执行策略为 CI 环境定义更细粒度的命令白名单/黑名单参见 execpolicy.md对沙箱工作原理的完整讨论参见 sandbox.md。延伸把一次性 exec 扩展为更精细的评审管线从 exec 命令的实现结构看cli.rsinterpreter exec除默认的单次新会话外还内置了resume与review两个子命令review针对当前仓库的**未提交改动--uncommitted、指定基础分支--base branch或单个提交--commit sha**运行评审适合在 CI 中对本地工作区/指定范围直接执行内置评审逻辑参数定义见 cli.rsresume按会话 ID 恢复历史会话--last可续接最近一次记录cli.rs。对应的命令行示例见 cli-reference.mdinterpreter 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 的正确姿势可以浓缩为四句话用interpreter exec让任务一次运行、干净退出用管道喂上下文git diff ... |因为 exec 在没有位置 prompt 时会从 stdin 读取指令用--json或--output-last-message收口输出让机器可解析、人可阅读用--sandbox read-only收口权限配合最小 GitHub 权限与常规评审保护把 AI 代理放在只读顾问的安全位置。相关文档与实现可以继续在仓库中深入CLI 完整参考见 cli-reference.mdexec 入口与参数解析实现见 codex-rs/exec/src/cli.rsstdout 输出纪律说明见 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 在 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 execGitHub 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 使用curlWindows 使用 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/checkoutv4 - 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.逐段拆解如下事件与权限on: pull_request使工作流在 PR 打开/更新时触发permissions显式收缩为contents: read与pull-requests: read遵循最小权限原则——评审任务只需要读取仓库内容与 PR 元数据不需要写入权限。检出代码actions/checkoutv4检出代码。注意 GitHub Actions 默认的检出深度depth 1配合事件上下文可借助github.base_ref拿到基础分支名。安装代理使用官方安装脚本。评审 diff关键技巧是git diff origin/${{ github.base_ref }}...HEAD计算从基础分支到当前 HEAD 的变更再通过管道|交给interpreter exec。diff 为什么能通过管道传入从源码层面看exec 的 prompt 参数设计为当位置参数未提供或显式传入-时指令从标准输入stdin读取若 stdin 同时被管道输入且位置参数也提供了 promptstdin 内容会作为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_providermoonshotai \ -c harnesskimi-code \ -m kimi-k3 \ Summarize the risky parts of this change.参数含义-c model_providermoonshotai覆盖配置中的model_provider字段选择 Moonshot AI 作为提供者。-c以keyvalue的 TOML 风格片段工作可多次使用作用相当于命令行内联的配置层。-c harnesskimi-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 必须是合法的 JSONLJSON 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 评审意见落地的建议流程--json收集结构化事件或用--output-last-message产出 Markdown 摘要用上传/输出机制如GITHUB_OUTPUT、artifact把结果传递给后续 job由普通 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 中有完整罗列模式含义CI 适用性read-only只读沙箱禁止对文件系统的写入推荐评审、摘要、审计类任务workspace-write允许写入当前工作区仅当任务需要生成补丁、提交修改时danger-full-access完全访问权限不应用于 CI除非完全信任任务read-only沙箱保证了代理即使被诱导也无法对工作区造成破坏从而把 AI 评审限定在只读顾问的角色上。若确实需要提交更改例如自动修复并推送文档强调应保持三点纪律提示词收窄只让代理执行范围极小、目标明确的改动随后运行测试用既有测试套件验证代理产出的修改合并前启用正常评审保护依赖分支保护、PR review、required checks 等 GitHub 原生机制把关。此外还可以结合 execpolicy执行策略为 CI 环境定义更细粒度的命令白名单/黑名单参见 execpolicy.md对沙箱工作原理的完整讨论参见 sandbox.md。延伸把一次性 exec 扩展为更精细的评审管线从 exec 命令的实现结构看cli.rsinterpreter exec除默认的单次新会话外还内置了resume与review两个子命令review针对当前仓库的**未提交改动--uncommitted、指定基础分支--base branch或单个提交--commit sha**运行评审适合在 CI 中对本地工作区/指定范围直接执行内置评审逻辑参数定义见 cli.rsresume按会话 ID 恢复历史会话--last可续接最近一次记录cli.rs。对应的命令行示例见 cli-reference.mdinterpreter 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 的正确姿势可以浓缩为四句话用interpreter exec让任务一次运行、干净退出用管道喂上下文git diff ... |因为 exec 在没有位置 prompt 时会从 stdin 读取指令用--json或--output-last-message收口输出让机器可解析、人可阅读用--sandbox read-only收口权限配合最小 GitHub 权限与常规评审保护把 AI 代理放在只读顾问的安全位置。相关文档与实现可以继续在仓库中深入CLI 完整参考见 cli-reference.mdexec 入口与参数解析实现见 codex-rs/exec/src/cli.rsstdout 输出纪律说明见 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考