LangChain 开源 Open SWE：内部编码 Agent 框架

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

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

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

来自生产部署的模式

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 改进时（更好的上下文管理、更高效的规划、优化的 token 使用），你可以纳入这些改进，而无需重建你的定制内容。

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

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 开箱即支持多种沙箱提供商：

• Modal
• Daytona
• Runloop
• LangSmith

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

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

关键行为：

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

3. 工具：精选，而非堆砌

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

外加内置的 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：评论@openswe任意 issue。智能体会读取完整的 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 集成逻辑。添加新的触发入口，如电子邮件、webhooks 或自定义 UI。

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

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

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

与内部实现的对比

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

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

快速开始

Open SWE 现已上线，可在GitHub。

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

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

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

多家工程组织已成功在生产环境中部署内部编码智能体。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 文档