LangChain 开源 Open SWE：面向企业内部编码智能体的框架

在过去一年中，我们观察到多家工程组织在构建与开发团队协同工作的内部编码代理。Stripe 开发了 Minions，Ramp 构建了 Inspect，Coinbase 则创建了 Cloudbot。这些系统集成到现有工作流中（可通过 Slack、Linear 和 GitHub 访问），而非要求工程师采用新的界面。

尽管这些系统是独立开发的，但它们却趋同于相似的架构模式：隔离的云沙箱、精选的工具集、子代理编排，以及与开发者工作流的集成。这种趋同表明，在生产工程环境中部署 AI 代理存在一些共同的需求。

今天，我们发布 Open SWE，这是一个开源框架，以可定制的形式捕捉了这些模式。Open SWE 构建在 Deep Agents 和 LangGraph 之上，提供了我们在这些实现中观察到的核心架构组件。如果你的组织正在探索内部编码代理，这可以作为一个起点。

来自生产部署的模式

Stripe、Ramp 和 Coinbase 都构建了自己的内部编码代理。Kishan Dahya 写了一篇很棒的文章，介绍了这些编码代理所做的不同架构决策。我们在下面进行总结，然后深入探讨 OpenSWE 在这些维度上的比较。

隔离的执行环境：任务在专用的云沙箱中运行，在严格边界内拥有完全权限。这将任何错误的影响范围与生产系统隔离开来，同时允许代理执行命令而无需为每个操作请求批准。

精选的工具集：根据 Stripe 的工程团队，他们的代理可以访问大约 500 个工具，但这些工具是经过精心选择和维护的，而非随时间累积。工具精选似乎比工具数量更重要。

Slack 优先的调用方式：这三个系统都集成了 Slack 作为主要界面，在开发者现有的沟通工作流中与他们互动，而非要求他们切换到新的应用程序。

启动时的丰富上下文：这些代理在开始工作前会从 Linear 问题、Slack 线程或 GitHub PR 中提取完整上下文，减少了通过工具调用发现需求的开销。

子代理编排：复杂任务被分解并委托给专门的子代理，每个子代理都有隔离的上下文和专注的职责。

这些架构选择在多个生产部署中已被证明有效，不过各组织可能需要根据自身环境和需求调整具体组件。

Open SWE 的架构

Open SWE 提供了类似架构模式的开源实现。以下是该框架与我们观察到的模式的对应关系：

1. 代理框架：基于 Deep Agents 组合

Open SWE 并非分叉现有代理或从头构建，而是基于 Deep Agents 框架进行组合。这种方法类似于 Ramp 的团队在 OpenCode 之上构建 Inspect 的方式。

组合提供了两个优势：

升级路径：当 Deep Agents 改进时（更好的上下文管理、更高效的规划、优化的令牌使用），你可以将这些改进纳入其中，而无需重建你的定制内容。

无需分叉即可定制：你可以将组织特定的工具、提示词和工作流作为配置来维护，而不是修改核心智能体逻辑。

create_deep_agent( model="anthropic:claude-opus-4-6", system_prompt=construct_system_prompt(repo_dir, ...), tools=[ http_request, fetch_url, commit_and_open_pr, linear_comment, slack_thread_reply ], backend=sandbox_backend, middleware=[ ToolErrorMiddleware(), check_message_queue_before_model, ... ], )

Deep Agents 提供了支持这些模式的基础设施：通过 write_todos 实现内置规划、基于文件的上下文管理、通过 task 工具原生生成子智能体，以及用于确定性编排的中间件钩子。

2. 沙箱：隔离的云环境

每个任务都在其自己的隔离云沙箱中运行，这是一个具有完整 shell 访问权限的远程 Linux 环境。仓库被克隆进来，智能体获得完整权限，任何错误都被限制在该环境内。

Open SWE 开箱即支持多种沙箱提供商：

你也可以实现自己的沙箱后端。

这遵循了我们观察到的一种模式：先隔离，然后在边界内授予完整权限。

关键行为：

每个对话线程获得一个持久沙箱，在后续消息中重复使用
如果沙箱变得不可达，会自动重新创建
多个任务并行运行，每个都在自己的沙箱中

3. 工具：精选而非累积

Open SWE 附带一套专注的工具集：

工具	用途
execute	在沙箱中执行 shell 命令
fetch_url	以 markdown 形式获取网页
http_request	API 调用（GET、POST 等）
commit_and_open_pr	Git 提交并打开 GitHub 草稿 PR
linear_comment	向 Linear 工单发布更新
slack_thread_reply	在 Slack 线程中回复

外加内置的 Deep Agents 工具：read_file、write_file、edit_file、ls、glob、grep、write_todos 和 task（子智能体生成）。

更小、更精选的工具集更容易测试、维护和推理。当你需要为组织添加额外工具（内部 API、自定义部署系统、专用测试框架）时，可以显式添加它们。

4. 上下文工程：AGENTS.md + 源上下文

Open SWE 从两个来源收集上下文：

AGENTS.md 文件：如果你的仓库根目录包含 AGENTS.md 文件，它会从沙箱中读取并注入到系统提示词中。该文件可以编码约定、测试要求、架构决策以及每次智能体运行都应遵循的团队特定模式。

源上下文：完整的 Linear 工单（标题、描述、评论）或 Slack 线程历史会被组装并在智能体启动前传递给它，从而无需额外工具调用即可提供任务特定的上下文。

这种双层方法在仓库级知识与任务特定信息之间取得平衡。

5. 编排：子智能体 + 中间件

Open SWE 的编排结合了两种机制：

子智能体：Deep Agents 框架支持通过 task 工具生成子智能体。主智能体可以将独立子任务委托给隔离的子智能体，每个子智能体都有自己的中间件栈、待办事项列表和文件操作。

中间件：确定性中间件钩子在智能体循环周围运行：

check_message_queue_before_model：在下一次模型调用之前注入后续消息（运行中途到达的 Linear 评论或 Slack 消息）。这允许用户在智能体工作时提供额外输入。
open_pr_if_needed：作为安全网，如果智能体未完成此步骤，则提交并打开 PR。这确保关键步骤可靠发生。
ToolErrorMiddleware：优雅地捕获并处理工具错误。

这种将智能体（模型驱动）编排与确定性（中间件驱动）编排分离的方式，有助于在可靠性与灵活性之间取得平衡。

6. 调用方式：Slack、Linear 和 GitHub

我们观察到，许多团队都倾向于将 Slack 作为主要的调用入口。Open SWE 也遵循类似的模式：

Slack：在任意线程中提及该机器人。支持 repo:owner/name 语法来指定要操作的仓库。智能体会在线程内回复状态更新和 PR 链接。

Linear：在任意 issue 上评论 @openswe。智能体会读取完整的 issue 上下文，用 👀 表情回应以示确认，并将结果作为评论回帖。

GitHub：在智能体创建的 PR 的评论中标记 @openswe，让它处理评审反馈并将修复推送到同一分支。

每次调用都会创建一个确定性的线程 ID，因此针对同一 issue 或线程的后续消息会路由到同一个正在运行的智能体。

7. 验证：提示驱动 + 安全网

智能体被指示在提交前运行 linter、格式化和测试。open_pr_if_needed 中间件充当兜底——如果智能体在未打开 PR 的情况下结束，中间件会自动处理。

你可以通过添加确定性的 CI 检查、视觉验证或评审门禁作为额外的中间件，来扩展这一验证层。

为什么选择 Deep Agents

Deep Agents 提供了使这一架构可组合、可维护的基础。

上下文管理：长时间运行的编码任务可能产生大量中间数据（文件内容、命令输出、搜索结果）。Deep Agents 通过基于文件的记忆来处理这一点，将大型结果卸载出去，而不是把所有内容都保留在对话历史中。这有助于在处理较大代码库时防止上下文溢出。

规划原语：内置的 write_todos 工具提供了一种结构化的方式来分解复杂工作、跟踪进度，并随着新信息的出现调整计划。我们发现这对跨越较长时间的多步骤任务特别有帮助。

子智能体隔离：当主智能体通过 task 工具生成子智能体时，该子智能体会获得自己独立的上下文。不同的子任务不会污染彼此的对话历史，这有助于在复杂、多面的工作中获得更清晰的推理。

中间件钩子：Deep Agents 的中间件系统允许你在智能体循环的特定位置注入确定性逻辑。Open SWE 正是通过这种方式实现消息注入和自动创建 PR——这些行为需要可靠地发生。

升级路径：由于 Deep Agents 是作为独立库积极开发的，上下文压缩、提示缓存、规划效率和子智能体编排方面的改进都可以流入 Open SWE，而无需你重建自己的定制。

这种可组合性提供了与 Ramp 团队所描述的在 OpenCode 上构建时类似的优势：你既能获得一个持续维护、不断改进的基础，又能保留对组织专属层的控制。

为你的组织进行定制

Open SWE 旨在成为一个可定制的基础，而非成品。每个主要组件都是可插拔的：

沙箱提供商：可在 Modal、Daytona、Runloop 或 LangSmith 之间切换。如果你有内部基础设施需求，也可以实现自己的沙箱后端。

模型：可使用任意 LLM 提供商。默认是 Claude Opus 4，但你可以为不同子任务配置不同的模型。

工具：为你的内部 API、部署系统、测试框架或监控平台添加工具。移除你不需要的工具。

触发器：修改 Slack、Linear 和 GitHub 集成逻辑。添加新的触发入口，如邮件、webhook 或自定义 UI。

系统提示词：自定义基础提示词以及整合 AGENTS.md 文件的逻辑。添加组织专属的指令、约束或约定。

中间件：添加你自己的中间件钩子，用于校验、审批门禁、日志记录或安全检查。

自定义指南通过示例逐一讲解这些扩展点。

与内部实现的对比

以下是 Open SWE 与 Stripe、Ramp 和 Coinbase 内部系统的对比，基于公开可获取的信息：

决策	Open SWE	Stripe (Minions)	Ramp (Inspect)	Coinbase (Cloudbot)
框架	组合式（Deep Agents/LangGraph）	分叉式（Goose）	组合式（OpenCode）	从零构建
沙箱	可插拔（Modal、Daytona、Runloop 等）	AWS EC2 开发机（预热）	Modal 容器（预热）	自研
工具	约 15 个，精选	约 500 个，按 agent 精选	OpenCode SDK + 扩展	MCP + 自定义 Skills
上下文	Agents.md + issue/thread	规则文件 + 预注入	OpenCode 内置	Linear-fear + MCP
编排	子 agent + 中间件	蓝图（确定性 + 智能体式）	会话 + 子会话	三种模式
调用	Slack、Linear、GitHub	Slack + 嵌入式按钮	Slack + Web + Chrome 扩展	Slack 原生
验证	提示词驱动 + PR 安全网	三层（本地 + CI + 1 次重试）	可视化 DOM 验证	Agent 委员会 + 自动合并

核心模式是相似的。差异在于实现细节、内部集成和组织专属工具——这正是将框架适配到不同环境时所预期的情况。

快速开始

Open SWE 现已在 GitHub 上提供。

安装指南：讲解 GitHub App 创建、LangSmith 设置、Linear/Slack/GitHub 触发器以及生产部署。

自定义指南：展示如何为你的组织替换沙箱、模型、工具、触发器、系统提示词和中间件。

该框架采用 MIT 许可证。你可以 fork、自定义并在内部部署。如果你在其之上构建了有趣的东西，我们很乐意听听。

多家工程组织已成功在生产环境中部署内部编码 agent。Open SWE 提供了类似架构模式的开源实现，旨在针对不同代码库和工作流进行自定义。虽然我们仍在探索不同场景下什么方案有效，但该框架为探索这一方法的团队提供了一个起点。

试用 Open SWE：github.com/langchain-ai/open-swe

了解 Deep Agents：docs.langchain.com/oss/python/deepagents

报名 LangSmith Sandboxes 候补名单： https://www.langchain.com/langsmith-sandboxes-waitlist

阅读文档：Open SWE 文档