Open SWE 协作层GitHub 深度集成与人在回路HITL设计Open SWE 不是一个孤立的系统它的真正力量来自于与现有开发工作流的深度整合。从 GitHub Issue 触发任务到自动创建 Pull Request从计划审批到执行干预——「人在回路」Human-in-the-Loop设计让 AI 既能自动执行又能保持人类控制。本文将深入解析 Open SWE 的协作层设计。一、GitHub 工作流深度集成1.1 整体架构Open SWE 与 GitHub 的集成不是简单的 API 调用而是一套完整的工作流自动化┌─────────────────────────────────────────────────────────────────┐ │ GitHub 集成工作流 │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌───────┐ │ │ │ Issue │────▶│ Label │────▶│ Webhook │────▶│ Open │ │ │ Created │ │ Added │ │Triggered│ │ SWE │ │ └─────────┘ └─────────┘ └─────────┘ └───┬───┘ │ │ │ │ │ ▼ │ │ ┌──────────────────────────────────────────────────────────┐ │ │ │ Open SWE 处理流程 │ │ │ │ 1. 分析 Issue 内容 │ │ │ │ 2. 研究代码库 │ │ │ │ 3. 生成执行计划 │ │ │ │ 4. 执行代码修改 │ │ │ │ 5. 运行测试验证 │ │ │ │ 6. 代码审查 │ │ │ └──────────────────────────┬───────────────────────────────┘ │ │ │ │ │ ▼ │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌───────┐ │ │ │ PR │◀────│ Review │◀────│ Build │◀────│ Tests │ │ │ Created│ │ Request │ │ Passed │ │ Passed│ │ └─────────┘ └─────────┘ └─────────┘ └───────┘ │ │ │ └─────────────────────────────────────────────────────────────────┘1.2 触发方式详解Open SWE 支持多种任务触发方式方式一GitHub Issue 标签触发这是最常用的触发方式。当 Issue 被添加特定标签时自动触发任务Step 1: 用户创建 Issue │ ▼ Step 2: 用户添加标签 open-swe-auto │ ▼ Step 3: GitHub Webhook 通知 Open SWE │ ▼ Step 4: Open SWE 开始处理配置步骤在 GitHub 仓库设置 Webhook配置标签过滤规则添加open-swe-auto标签到 Issue# GitHub Webhook 配置webhook:url:https://your-openswe-server.com/webhook/githubevents:-issues-issue_commentsecret:your-webhook-secret方式二专用 UI 委派除了 Issue 标签还可以使用专用 UI 界面委派任务┌────────────────────────────────────────────────────┐ │ Open SWE 任务提交界面 │ ├────────────────────────────────────────────────────┤ │ │ │ 仓库选择: [ dropdown ] │ │ │ │ 任务描述: │ │ ┌────────────────────────────────────────────┐ │ │ │ 为 users service 添加 CRUD 接口的完整测试 │ │ │ │ - 使用 pytest │ │ │ │ - 覆盖率达到 80% │ │ │ └────────────────────────────────────────────┘ │ │ │ │ 选项: │ │ ☑ 自动创建 PR │ │ ☑ 失败时发送通知 │ │ ☐ 需要人工审批计划 │ │ │ │ [ 提交任务 ] │ │ │ └────────────────────────────────────────────────────┘方式三API 调用企业可以将 Open SWE 集成到内部系统importrequests# 通过 API 触发任务responserequests.post(https://api.open-swe.com/tasks,headers{Authorization:Bearer YOUR_API_KEY,Content-Type:application/json},json{repository:org/repo-name,description:修复登录模块的 XSS 漏洞,branch:fix/login-xss,options:{auto_approve:False,notify_on_complete:True}})print(f任务创建成功:{response.json()[task_id]})1.3 状态同步机制Open SWE 会实时同步任务状态到 GitHub Issue┌─────────────────────────────────────────────────────────┐ │ Issue 状态更新示例 │ ├─────────────────────────────────────────────────────────┤ │ │ │ Issue 标题: [open-swe-auto] 添加用户认证模块测试 │ │ │ │ ─────────────────────────────────────────────────── │ │ │ │ **Open SWE 任务状态** │ │ │ │ - 状态: 进行中 │ │ - 进度: 65% (3/5 步骤完成) │ │ │ │ **当前步骤**: 运行测试 │ │ - 已修改: 3 个文件 │ │ - 测试结果: 15 passed, 2 failed │ │ │ │ ─────────────────────────────────────────────────── │ │ │ │ 评论 (5) │ │ │ └─────────────────────────────────────────────────────────┘状态更新包括任务阶段分析中/计划中/执行中/审查中/完成当前进度百分比已修改的文件列表测试结果错误信息如有1.4 Pull Request 自动创建任务完成后Open SWE 自动创建 PR┌─────────────────────────────────────────────────────────┐ │ PR 创建流程 │ ├─────────────────────────────────────────────────────────┤ │ │ │ 1. 代码提交到独立分支 │ │ - 分支名: open-swe-{task_id} │ │ - 提交信息: Open SWE: {修改摘要} │ │ │ │ 2. 创建 Pull Request │ │ - 标题: [Open SWE] {Issue 标题} │ │ - 描述: 包含修改内容、测试结果、验证说明 │ │ - 关联: 自动关联原始 Issue │ │ │ │ 3. PR 描述模板 │ │ ┌────────────────────────────────────────────┐ │ │ │ ## Summary │ │ │ │ Open SWE 自动完成了以下修改... │ │ │ │ │ │ │ │ ## Changes │ │ │ │ - file1.py: 添加新功能 │ │ │ │ - test_file1.py: 添加测试 │ │ │ │ │ │ │ │ ## Test Results │ │ │ │ ✅ All 45 tests passed │ │ │ │ │ │ │ │ ## Verification │ │ │ │ 已在沙箱环境验证构建成功 │ │ │ └────────────────────────────────────────────┘ │ │ │ └─────────────────────────────────────────────────────────┘二、人在回路HITL设计2.1 HITL 的核心理念「人在回路」Human-in-the-Loop是一种将人类智慧融入 AI 执行过程的设计范式。Open SWE 的 HITL 设计基于以下原则人类始终保持最终控制权AI 负责执行人类负责决策最小化必要介入最大化自动化2.2 三种 HITL 模式Open SWE 提供了三种不同级别的人工介入模式┌─────────────────────────────────────────────────────────────┐ │ HITL 模式光谱 │ ├─────────────────────────────────────────────────────────────┤ │ │ │ 全自动 ◀────────────────────────────────────────▶ 全人工 │ │ │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ │ 模式 1 │ │ 模式 2 │ │ 模式 3 │ │ 模式 4 │ │ │ │ 完全自动 │ │ 计划审批 │ │ 执行干预 │ │ 双重文本 │ │ │ └─────────┘ └─────────┘ └─────────┘ └─────────┘ │ │ │ │ 介入程度: 低 ────────────────────────────────── 高 │ │ │ └─────────────────────────────────────────────────────────────┘模式一完全自动适用于低风险、可快速验证的任务简单的测试生成文档更新代码格式调整task:description:更新所有函数的 docstring 格式hitl_mode:none# 完全自动模式二计划审批这是最常用的模式。AI 生成计划人类审批后再执行┌─────────────────────────────────────────────────────────────┐ │ 计划审批流程 │ ├─────────────────────────────────────────────────────────────┤ │ │ │ 1. Planner 生成计划 │ │ ┌────────────────────────────────────────────┐ │ │ │ 计划: │ │ │ │ 1. 修改 src/auth.py - 添加 login 函数 │ │ │ │ 2. 修改 src/auth.py - 添加 logout 函数 │ │ │ │ 3. 创建 tests/test_auth.py - 添加测试 │ │ │ │ │ │ │ │ 风险评估: 低 │ │ │ │ 预计时间: 5 分钟 │ │ │ └────────────────────────────────────────────┘ │ │ ↓ │ │ 2. 暂停等待人类审批 │ │ ┌────────────────────────────────────────────┐ │ │ │ [接受] [编辑计划] [拒绝] │ │ │ └────────────────────────────────────────────┘ │ │ ↓ │ │ 3. 人类决策 │ │ - 接受: 执行计划 │ │ - 编辑: 修改后执行 │ │ - 拒绝: 终止任务 │ │ │ └─────────────────────────────────────────────────────────────┘审批界面设计┌─────────────────────────────────────────────────────────┐ │ 计划审批界面 │ ├─────────────────────────────────────────────────────────┤ │ │ │ 任务: 为用户模块添加单元测试 │ │ │ │ ─────────────────────────────────────────────────── │ │ │ │ 执行计划: │ │ │ │ [1] 修改 tests/test_user.py │ │ - 添加 test_create_user 函数测试 │ │ - 添加 test_get_user 函数测试 │ │ - 添加 test_update_user 函数测试 │ │ │ │ [2] 修改 src/models/user.py │ │ - 为 User 模型添加 validate 方法 │ │ │ │ ─────────────────────────────────────────────────── │ │ │ │ 风险评估: 低风险 │ │ 修改文件: 2 个 │ │ 预计完成时间: ~3 分钟 │ │ │ │ ─────────────────────────────────────────────────── │ │ │ │ [ 接受执行 ] [ 编辑计划 ] [ 拒绝 ] │ │ │ └─────────────────────────────────────────────────────────┘模式三执行干预允许在任务执行过程中随时干预┌─────────────────────────────────────────────────────────────┐ │ 执行干预能力 │ ├─────────────────────────────────────────────────────────────┤ │ │ │ Agent 正在执行... │ │ ↓ │ │ ┌────────────────────────────────────────────────────┐ │ │ │ 当前: 修改 src/api/users.py │ │ │ │ 进度: 2/5 步骤完成 │ │ │ │ 已修改: 3 个文件 │ │ │ └────────────────────────────────────────────────────┘ │ │ ↓ │ │ 人类可以干预: │ │ ┌────────────────────────────────────────────────────┐ │ │ │ 选项 1: 修改指令 │ │ │ │ - 补充额外要求: 同时更新 API 文档 │ │ │ │ │ │ │ │ 选项 2: 提供上下文 │ │ │ │ - 参考: users_v2.py 的实现方式 │ │ │ │ │ │ │ │ 选项 3: 中断任务 │ │ │ │ - 停止执行保留当前修改 │ │ │ │ │ │ │ │ 选项 4: 解释 │ │ │ │ - 要求 Agent 解释当前行为 │ │ │ └────────────────────────────────────────────────────┘ │ │ │ └─────────────────────────────────────────────────────────────┘这种模式的典型应用场景发现遗漏执行中发现需要额外修改的文件方向调整根据执行结果调整后续策略问题诊断要求 Agent 解释为什么这样实现模式四双重文本Dual Texting这是 Open SWE 独有的特性。当 Agent 正在工作时你可以发送新的请求┌─────────────────────────────────────────────────────────────┐ │ 双重文本机制 │ ├─────────────────────────────────────────────────────────────┤ │ │ │ 时间线: │ │ │ │ T0: 提交任务 A 重构 payment 模块 │ │ ↓ │ │ T1: Agent 正在执行中... │ │ ↓ │ │ T2: 用户发送任务 B 更新文档 ←── 新请求 │ │ ↓ │ │ T3: Agent 并行处理 A 和 B │ │ ↓ │ │ T4: 两个任务都完成 │ │ │ │ ─────────────────────────────────────────────────── │ │ │ │ 对比传统助手: │ │ ┌──────────────────┬─────────────────────────────────┐ │ │ │ 传统 AI 助手 │ Open SWE │ │ │ ├──────────────────┼─────────────────────────────────┤ │ │ │ 阻塞式响应 │ 并行处理 │ │ │ │ 无法多任务 │ 支持多任务队列 │ │ │ │ 单次交互 │ 持续交互 │ │ │ └──────────────────┴─────────────────────────────────┘ │ │ │ └─────────────────────────────────────────────────────────────┘2.3 安全边界设计Daytona 隔离沙箱Open SWE 使用 Daytona 作为安全沙箱确保 Agent 操作不会危害宿主系统# Daytona 沙箱安全配置sandbox:# 隔离级别isolation:filesystem:isolated# 独立文件系统network:restricted# 受限网络process:sandboxed# 沙箱进程# 允许的命令白名单allowed_commands:-git-npm-pip-python-node-pytest-make# 禁止的操作forbidden_operations:-rm -rf /-curl | sh-wget | sh-fork bomb-external IP connection# 资源限制limits:cpu:4 coresmemory:8GBdisk:20GBtimeout:1 hour命令安全验证v2 版本引入了validateCommandSafety函数// 安全验证流程asyncfunctionexecuteCommand(command:string):PromiseCommandResult{// 1. 安全检查constisSafeawaitvalidateCommandSafety(command);if(!isSafe){thrownewSecurityError(Command blocked by safety check);}// 2. 在沙箱中执行constresultawaitsandbox.execute(command);// 3. 结果审计awaitauditLog.log({command,result,timestamp:newDate()});returnresult;}// 验证规则constsafetyRules[// 禁止删除系统目录{pattern:/rm\s-rf\s\//,action:block},// 禁止远程脚本执行{pattern:/(\wget|curl)\s.*\|\s*sh/,action:block},// 警告修改系统配置{pattern:/sudo\s.*/,action:warn},// 警告网络操作{pattern:/nc\s|netcat/,action:warn},];三、协作场景实践3.1 典型工作流示例场景修复生产环境 Bug步骤 1: 用户创建 Issue 标题: [BUG] 支付回调处理失败 标签: open-swe-auto, bug ↓ 步骤 2: Open SWE 接收任务分析代码 分析支付回调相关代码... 找到 3 个相关文件 发现问题: 缺少异常处理 ↓ 步骤 3: 生成计划 计划: [1] 修改 src/payment/callback.py - 添加 try-catch [2] 修改 src/payment/callback.py - 添加日志 [3] 创建 tests/test_callback.py - 添加测试 ↓ (等待审批) 步骤 4: 开发者审批计划 - 接受计划 ↓ 步骤 5: 执行修改 - 正在修改... - 测试通过: 12/12 ↓ 步骤 6: 自动创建 PR - PR #245: [BUG] 支付回调异常处理 - CI 通过 - 等待人工 Code Review3.2 团队协作模式┌─────────────────────────────────────────────────────────────┐ │ 团队协作模式 │ ├─────────────────────────────────────────────────────────────┤ │ │ │ 开发者 A 开发者 B 开发者 C │ │ │ │ │ │ │ ▼ ▼ ▼ │ │ Issue #1 Issue #2 Issue #3 │ │ │ │ │ │ │ └────────────────┼────────────────┘ │ │ ▼ │ │ Open SWE 处理队列 │ │ (并行处理 3 个任务) │ │ │ │ │ ▼ │ │ PR #245, #246, #247 │ │ │ │ │ ▼ │ │ 人工 Code Review │ │ │ │ │ ▼ │ │ 合并 │ │ │ └─────────────────────────────────────────────────────────────┘四、总结Open SWE 的协作层设计体现了几个核心理念深度 GitHub 集成从 Issue 触发到 PR 创建自动化整个流程灵活的 HITL 模式从完全自动到完全人工覆盖不同场景安全性优先沙箱隔离 命令验证确保系统安全可观测性状态实时同步问题可追踪这种设计让 Open SWE 既能发挥 AI 自动化的效率又能保持人类开发者的控制和监督。在接下来的文章中我们将探讨 Open SWE 的扩展层——如何自定义工具集成和 DSL 扩展。参考来源GitHub Webhook 文档Daytona 沙箱文档Open SWE 官方博客LangChain Human-in-the-Loop 最佳实践