Open SWE 是一个用于构建组织内部异步编码代理的开源框架。开发人员可以在 Slack、Linear 或 GitHub 中提及机器人；该服务组装问题/线程上下文，创建持久云沙箱，克隆存储库，计划和编辑代码，运行命令，提交到分支并打开或更新草稿拉取请求。
它不是安装后变得安全的托管编码服务。 Open SWE 是基于 LangGraph 和 Deep Agents 构建的参考架构。操作员必须选择模型和沙箱提供程序，创建 GitHub/Slack/Linear 应用程序，保护部署、范围存储库和令牌，添加确定性验证、控制网络访问并拥有每个生成的拉取请求。
端到端架构
| 图层 | 已发布的角色 | 经营者拥有决定权 |
|---|---|---|
| 祈求 | Slack 提及、Linear 评论或 GitHub PR 评论 | 谁可以触发哪些存储库以及触发成本是多少 |
| 背景 | AGENTS.md 加上完整的问题或线程历史记录 | 哪些内容是可信的、经过编辑的或容易被提示注入的 |
| 安全带 | Deep Agents 由 LangGraph 组成 | 型号、系统提示、工具、中间件、调用限制 |
| 沙盒 | 每个任务的持久远程 Linux 环境 | 提供者、镜像、出口、生命周期、资源和数据位置 |
| 工具 | Shell、文件、HTTP、Slack、Linear、GitHub 和可选的可观察性 | 最小特权、副作用批准和秘密边界 |
| 编排 | 子代理和确定性中间件挂钩 | 并发、预算、共享状态和错误处理 |
| 发货 | 提交、推送、起草 PR 和源渠道回复 | CI、审阅者、合并策略和部署分离 |
沙盒降低了主机风险，而不是外部权威
该存储库表示，每个任务都会收到一个具有完整 shell 权限且没有确认提示的隔离云沙箱，并支持 Modal、Daytona、Runloop、E2B 和 LangSmith 沙箱。单独的沙箱限制了文件系统和进程冲突，但自述文件中的爆炸半径“完全包含”的短语不应按字面意思对待。
代理可以具有网络出口、存储库权限、包注册表访问权限和外部 API。它可能会泄露源代码、销毁模型积分、打开有害的拉取请求、滥用令牌或攻击可从沙箱访问的内部服务。沙箱提供商控制平面的妥协也可以跨越任务边界。遏制需要出口策略、短期凭证、配额、提供者隔离和独立的合并/部署门。
| 风险 | 沙盒有帮助 | 所需的同伴控制 |
|---|---|---|
| 破坏性 shell 命令 | 限制本地磁盘/进程对一次性环境的损坏 | 无需生产安装；资源/时间限制和干净的拆卸 |
| 恶意依赖 | 将任务与开发人员笔记本电脑分开 | 锁定文件、注册表白名单、扫描和限制出口 |
| GitHub 令牌滥用 | 如果令牌允许外部操作，则很少 | 代理/范围应用程序令牌仅限于存储库和分支操作 |
| 及时注射 | 可能会限制主机妥协 | 信任标签、工具策略和拒绝敏感系统 |
| 错误的代码 | 允许在隔离的运行时进行测试 | 确定性 CI、安全审查和受保护的分支 |
| 数据泄露 | 分离本地工作站数据 | 提供商/数据审查、编辑和出站目的地控制 |
问题和聊天文本是不受信任的指令
Open SWE 将完整的 Linear 问题或 Slack 线程注入到代理上下文中。这提高了任务理解能力，但创建了直接提示注入路径：外部报告者或复制的日志可以指示代理泄露秘密、获取恶意 URL 或更改不相关的代码。 AGENTS.md 更具权威性，但它也是受感染分支可以修改的存储库内容。
按来源和信任级别标记内容。系统策略、组织规则和批准的存储库配置应优先于票证描述、评论、日志、网页和代码字符串。不要让不受信任的贡献者使用可观察性或内部数据工具触发运行。当前项目明确限制授权用户可选的Datadog/LangSmith工具；保留并测试该边界。
工具管理和凭证
默认工具集包括 shell 执行、文件操作、URL 获取、任意 HTTP 请求、Linear 搜索/评论和 Slack 反应/回复。 GitHub 操作可以被代理，以便沙箱在服务器执行授权请求时看到虚拟令牌。可选的 Datadog、LangSmith 和 Corridor 工具在服务器端运行，将这些凭据保留在沙箱之外。
| 工具组 | 最低权限 | 高风险误用 |
|---|---|---|
| GitHub | 阅读代码；推送一个任务分支；打开/更新草稿 PR | 更改保护、秘密、发布或其他分支 |
| Slack/Linear | 阅读触发线程/问题并在那里回复 | 搜索机密讨论或群发消息 |
| HTTP/获取 | 尽可能将公共文档列入许可名单 | SSRF、元数据访问、渗透和恶意页面指令 |
| 可观测性 | 只读、限定范围的服务和授权用户 | 泄露日志/跟踪中嵌入的客户数据或秘密 |
| 壳牌 | 仅在资源有限的沙箱内完全控制 | 分叉炸弹、加密挖矿、网络扫描或持久性 |
| 子代理 | 与父母相同或较小的权力 | 成本、冲突和工具调用成倍增加 |
验证是最大的默认差距
自述文件将验证描述为提示驱动：指示代理在提交之前运行 linter、格式化程序和测试。指示不是强制执行。代理可以跳过昂贵的测试、误读输出、削弱测试、嘲笑行为或在超时后声称成功。该项目本身建议添加确定性 CI、视觉验证或审查门。
将接受移到模型循环之外。在新的环境中执行所需的命令并返回预期的机器可读结果之前，服务不应将任务标记为成功。客服人员不得编辑确定其自身通行证状态的工作流程，除非单独审核该工作流程更改。
| 门 | 独立证据 | 失败政策 |
|---|---|---|
| 适用范围 | 与问题白名单相比更改的路径 | 阻止 PR 更新或请求人为例外 |
| 构建/类型检查 | 新的结账命令和退出代码 | 附上日志并标记为不完整 |
| 测试 | 所需的套件以及变更测试审查 | 没有静默编辑期望的重试循环 |
| 安全性 | 依赖性、秘密和静态分析扫描器 | 检疫发现；永不自动关闭 |
| 视觉 | 在定义的路线/视口处进行屏幕截图比较 | 人类对有意义的差异的批准 |
| 可审查性 | 差异大小、摘要、风险和回滚字段 | 拆分超大或混合关注的变更 |
持久化线程需要生命周期规则
后续 Slack/Linear 消息路由到相同的确定性线程和持久沙箱。这可以保留上下文，但也可以保留受损状态、过时的分支、下载的机密和失控的进程。定义最大生命周期、空闲超时、磁盘配额和“从干净模板重新创建”路径。几周后重新打开的票证不应默默地恢复旧的未修补环境。
中间件在下一次模型调用之前注入排队消息。记录哪条消息更改了任务、是谁发送的以及范围是否扩大。如果后续请求新的存储库、外部系统或生产操作，请创建新的授权决策，而不是将其视为普通的会话上下文。
子代理：具有非线性成本的有用并行性
Deep Agents 可以生成具有自己的中间件、待办事项列表和文件操作的子代理。仅将它们用于独立的大量读取工作，例如定位测试、比较 APIs 或检查有界差异。一个分支中的多个编写者可能会覆盖假设并创建更大的、不太连贯的更改。
- 设置最大子计数、模型调用限制、代币预算和挂钟截止日期。
- 分配不重叠的文件或要求一位家长序列化编辑。
- 保持子级权限不大于父级。
- 让每个孩子返回证据和不确定性，而不仅仅是散文结论。
- 将所有子活动记入原始任务以进行成本测量。
部署和依赖项选择
Open SWE 需要的不仅仅是安装 Python 包：后端、仪表板、LangGraph/LangSmith 服务、GitHub App/OAuth、调用集成、沙箱提供程序、模型凭证和生产托管。该代码已获得麻省理工学院许可，但云沙箱、模型、可观测性和消息传递平台具有单独的定价和数据条款。
锁定 Open SWE 提交和所有依赖锁。将应用程序机密存储在托管机密系统中、轮换 Webhook 机密、验证签名并拒绝重播事件。独立的开发和生产装置。公共 Webhook 加上强大的 GitHub App 是一个有吸引力的目标。
任务选择
| 任务 | 适用性 | 原因 |
|---|---|---|
| 机械 API 迁移 | 好飞行员 | 清晰的模式、有界文件和确定性测试 |
| 添加缺少的单元测试 | 好有评论 | 有用的研究，但测试可能会编码错误的行为 |
| 依赖更新 | 有条件的 | 需要变更日志、安全性和兼容性审查 |
| 产品功能不明确 | 初始拟合不佳 | 需求和用户体验判断主导编码 |
| 身份验证重新设计 | 高风险 | 安全架构需要可靠的专业知识 |
| 生产事故 | 自主适配性较差 | 时间压力和现场权威会放大错误 |
衡量已接受的工程工作
跟踪任务接受率、审阅者分钟数、首次独立运行的 CI 通过、重新打开的缺陷、安全结果、沙箱分钟数、模型令牌和每个合并 PR 的总成本。与类似任务复杂性的人类基线进行比较。 PR 数量和更改的行数是产出量，而不是生产力。
维护一个无代理控制组和一个同步代理组。异步代理可以减少中断，同时增加审阅批次。有用的问题是，在不将隐藏的工作量转移给审阅者和平台工程师的情况下，交货时间和接受的质量是否会得到改善。
替代方案
| 选项 | 最适合 | 与 Open SWE 的权衡 |
|---|---|---|
| Open SWE | 团队构建可定制的内部异步代理平台 | 重要的集成、安全性和运营所有权 |
| Codex / Claude 代码 | 同步开发人员监督的终端工作 | 减少后台工作流程编排 |
| GitHub Copilot 编码剂 | GitHub 原生管理的问题到 PR 流程 | 较少的框架级定制和不同的托管模型 |
| 德文 | 托管自主编码工作空间 | 商业托管平台和内部控制较少 |
| OpenHands | 开源编码代理运行时和研究 | 不同的集成和编排重点 |
| CI 脚本/机器人 | 确定性迁移、格式化和更新 | 推理不太灵活，对于已知任务通常更安全、更便宜 |
常见问题
Open SWE 是托管服务吗？
它是一个开源框架。运营商部署和配置它并购买或运行所需的模型、沙箱和集成服务。
支持哪些沙箱？
当前存储库列出了 Modal、Daytona、Runloop、E2B 和 LangSmith，以及自定义路径。
是否支持 Slack、Linear 和 GitHub？
是的。这些是主要记录的调用和后续界面。
沙箱可以保证完全权限的安全吗？
不会。它隔离本地执行，但网络、存储库和外部帐户权限需要单独控制。
它会自动验证代码吗？
默认情况严重依赖代理指令来运行检查。团队应该添加确定性的外部 CI 和审查门。
它是开源的吗？
是的。当前存储库已获得 MIT 许可。
主要来源
上次审核日期为 2026 年 7 月 25 日。Open SWE 发展迅速；升级后固定已部署的修订版并重新验证集成、沙箱行为、工具和安全控制。
