Open SWE
为组织构建可接入现有协作流程的异步内部编程智能体。
证据显示任务在隔离云沙箱中运行，管理工具、仓库指令、线程工具、可观测性工具和子代理能力均有权限或作用域限制；密钥留在服务端、部分凭据静态加密，工作流权限也较窄。扣分原因是沙箱内授予完整 shell 权限并允许网络出口，产品明确不要求确认且会自动提交、推送和创建 PR；数据流虽有较清楚的说明，但未完整覆盖所有提供商、GitHub 凭据和遥测路径。依赖有锁定安装、部分精确版本及固定提交的 Actions，但大量宽松下界和主动覆盖不兼容传递约束降低了供应链把握。草稿 PR 和隔离环境提供有限恢复空间，却没有明确的回滚协议。MIT 版权和上游框架归属清楚，但企业登记中的发布者身份未知，且比较性来源主要是项目自身陈述。
README、配置、CI 和针对权限、工具装配、中间件及环境回退的测试相互一致，因此自洽性充分。多沙箱提供商、不可达时重建、锁文件安装和广泛 CI 改善可用性；但系统依赖多个云服务、模型、GitHub、Slack、Linear 和快速变化的框架，并存在显式依赖约束覆盖，故未给满分。工具错误中间件、重试、步数上限通知及多处具体错误文本表明失败会被处理，但材料没有证明所有外部集成都能产生可操作且一致的错误信息。
项目明确面向组织内部编码代理，覆盖 Slack、Linear、GitHub、网页和实验性桌面场景，并允许替换模型、沙箱、工具、触发器、提示词和中间件，环境适配证据充分。触发语法、确定性线程路由、来源相关工具装配和管理员门控较具体。扣分集中在能力边界：自动改代码、推送和开 PR 的广泛权限主要依赖沙箱与提示词约束，确定性验证和审查门仍被列为使用者自行扩展项。
README 按架构、工具、调用、验证、功能和入门组织，并指向安装及定制文档；但这些文档内容未包含在给定材料中，所以安装细节只能给薄弱分。命名总体稳定，但仓库名、Python 包名和实验性桌面产品存在轻微分层差异。示例和架构表较丰富，却没有真正的 FAQ。材料坦承桌面端为实验性、验证依赖提示词以及网络出口和提示注入残余风险，但缺少系统化限制清单。MIT 许可证文本完整。存在 0.1.0 版本和桌面 SemVer 发布流程，却没有所提供范围内的变更日志或总体发布策略。版权主体与安全邮箱可见，但发布者未经登记验证，也没有明确维护者名单、支持承诺或更新责任制度。
输出路径明确：代理可提交修改、推送分支、创建或更新草稿 PR，并把状态和链接回复到来源渠道，因而具备较高可用性；但最终质量检查主要由提示驱动，未展示强制审查或确定性验收门，故不满分。相较基础聊天代理，持久沙箱、多渠道上下文、并行子代理、消息队列和自动 PR 流程提供明显增量价值。扣分在成本效益：材料没有量化模型调用、云沙箱、并发、可观测性或运维成本，也没有默认预算和资源控制说明。
许多具体主张可追溯到配置、CI 和聚焦测试，例如管理员门控、只读技能后端、来源相关工具、失败中间件和发布校验，跨文件印证很强。扣分原因是本次仅为静态审查，未执行测试；README 关于‘最佳’组织架构、同类公司实践、完全控制爆炸半径等表述带有营销或推断性质，所给材料没有独立来源来验证这些比较性主张，事实与推断也未始终明确区分。
- 代理默认可在沙箱内执行任意 shell 命令并访问网络，而且没有逐步确认；部署前应限制出口、仓库范围、GitHub 权限和可调用工具。
- 自动提交、推送及创建 PR 的流程缺少明确回滚协议；建议强制草稿 PR、分支保护、必需 CI 和人工合并审批。
- 可观测性数据、网页、Issue、Slack 消息及仓库指令都可能携带提示注入；即使有授权门控，也应使用最小权限的只读凭据并审计外部请求。
- 依赖解析主动覆盖 langchain-e2b 的声明约束；升级前应重新验证兼容性并持续进行漏洞及供应链扫描。
- 本结论仅依据给定文件静态评估，未运行测试、安装依赖或验证任何外部服务与安全声明。
这个 Agent 能做什么，适合哪些场景？
Open SWE 是一个基于 LangGraph 与 Deep Agents 的开源框架，用于构建组织内部的异步编程智能体。任务可从 Slack、Linear 或 GitHub 发起，并在独立、可持续复用的云端 Linux 沙箱中执行。智能体读取完整的工单或讨论上下文以及仓库根目录的 AGENTS.md，然后使用文件工具、Shell、网络请求和 GitHub CLI 修改代码。它会运行测试、格式化器和代码检查，并负责提交、推送及创建或更新草稿 PR，再把结果回复到原始协作渠道。项目还包含 Web 管理面板和实验性的 Electron 桌面封装，并允许组织替换模型、沙箱、工具、触发器、系统提示词和中间件。
Slack 线程中的机器人提及、Linear 工单里的 @openswe 评论或智能体所建 PR 上的 GitHub 评论会创建或续接一个确定性线程。Open SWE 汇总 Slack 线程或 Linear 工单的标题、描述和评论，并在仓库存在 AGENTS.md 时将其注入系统提示词。它通过 create_deep_agent 组合模型、construct_system_prompt、工具、sandbox_backend 和中间件；每项任务在 Modal、Daytona、Runloop、E2B、LangSmith 或自定义提供方的独立远程 Linux 沙箱中运行。智能体使用 read_file、write_file、edit_file、delete、ls、glob、execute 和 task，以及 fetch_url、http_request、linear_comment、linear_search_issues、slack_thread_reply 等集成工具；代码搜索通过 execute 调用 rg，GitHub 操作通过沙箱内的 gh 完成。task 可生成子智能体并行处理独立子任务，check_message_queue_before_model 会在下一次模型调用前注入运行期间收到的后续消息。完成修改后，智能体按提示运行检查和测试，提交并推送代码，创建或更新草稿 PR，并把状态及 PR 链接发回来源渠道。
- 工程团队希望让成员直接在 Slack 线程中提出代码修改任务，并在同一线程接收进度和草稿 PR。
- 使用 Linear 管理研发工作的组织，希望智能体读取完整工单和评论后实施改动，并把结果写回该工单。
- 维护多个仓库的平台团队，希望通过仓库级 AGENTS.md 传入编码约定、测试要求和架构规则。
- 需要同时处理多项开发工作的团队，希望为每项任务分配独立云沙箱，并通过子智能体并行拆分工作。
- 已有智能体生成 PR 的团队，希望在 GitHub 评论中再次标记 @openswe，让它处理评审意见并推送到原分支。
- 对权限边界敏感的组织，希望把完整 Shell 与文件权限限制在无生产访问的隔离沙箱内。
这个 Agent 有哪些优点和局限？
- 从 Slack、Linear 和 GitHub 原生触发，结果与 PR 链接会返回原始工作上下文。
- 每个任务使用独立且可持续复用的云沙箱；多个任务可以并行运行，失联沙箱还能自动重建。
- 基于 LangGraph 和 Deep Agents 组合而非维护框架分叉，且模型、沙箱、工具、触发器和中间件均可替换。
- 覆盖从读取上下文、修改代码和运行验证到提交、推送及创建草稿 PR 的端到端流程。
- 可选的 Datadog、LangSmith 和 Corridor 工具在服务器端持有凭据，不把相应密钥放入沙箱。
- 必须部署并维护后端、管理面板、GitHub App、渠道集成和云沙箱，采用成本高于单机编码工具。
- 验证主要依赖提示词；确定性 CI、视觉验证和评审门禁需要组织自行通过中间件扩展。
- 任务沙箱需要网络、Shell 和仓库文件访问；即使隔离了生产系统，网络出口和来自网页、日志或追踪的提示注入仍是明确的残余风险。
- 沙箱运行依赖 Modal、Daytona、Runloop、E2B、LangSmith 或自建适配器，迁移提供方需要配置或集成工作。
- 桌面应用仍属实验性功能，项目明确推荐使用 Web 界面。
如何安装或部署这个 Agent？
源码仅明确给出 macOS 桌面测试版命令：克隆仓库后，在仓库根目录运行 make install-desktop 进行安装或更新。完整安装流程位于 docs/INSTALLATION.md，范围包括本地后端与管理面板、GitHub App 创建、LangSmith、Linear/Slack/GitHub 触发器和生产部署；所提供材料没有列出这些步骤的具体命令、软件版本、环境变量或全部凭据，因此不能据此写出完整的可复制部署命令。部署时至少需要配置 GitHub 身份验证，并选择受支持的云沙箱提供方；具体必填值需以安装文档为准。
如何使用这个 Agent？
完成后端、管理面板、GitHub App 和所需渠道集成配置后，可在 Slack 任意线程中提及机器人；需要指定仓库时使用 repo:owner/name。也可在 Linear 工单中评论 @openswe，智能体会以 👀 确认接收并读取完整工单上下文。对于智能体创建的 PR，可在评论中标记 @openswe，让它处理评审反馈并向同一分支推送修复。任务运行期间可以继续发送 Slack 消息或 Linear 评论，后续消息会在下一次模型调用前进入运行中的线程。Web 管理面板可用于 GitHub 登录、个人模型与配置档设置、团队默认值、启用仓库、评审风格、用户映射及 Agents 聊天。
这个 Agent 与同类方案有什么区别？
与源码列出的内部系统相比，Open SWE 使用 Deep Agents/LangGraph 的组合式框架和可插拔沙箱；Stripe Minions 基于 Goose 分叉并使用预热的 AWS EC2 开发机，Ramp Inspect 组合 OpenCode 并使用预热 Modal 容器，Coinbase Cloudbot 则为自研系统。Open SWE 采用约 15 个精选工具、AGENTS.md 加工单或线程上下文、子智能体加中间件，以及提示词驱动的验证。相比之下，Minions 使用按智能体筛选的约 500 个工具和三层验证，Inspect 使用 OpenCode SDK、子会话及可视化 DOM 验证，Cloudbot 使用 MCP、自定义 Skills、三种模式和智能体委员会。该比较来自项目自身列出的架构对照，并不是独立基准测试。