LangChain 开源 Open SWE：提炼 Stripe 等内部编码智能体架构范式，提供可定制生产级框架

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

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

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

生产环境部署中的模式

Stripe、Ramp 和 Coinbase 都构建了各自的内部编码智能体。Kishan Dahya 撰写了一篇精彩的文章，分析了这些编码智能体所做出的不同架构决策。我们在下文进行了总结，并深入探讨了 OpenSWE 在这些维度上的对比情况。

隔离的执行环境：任务在专用的云沙箱中运行，在严格边界内拥有完全权限。这将任何错误对生产系统的影响范围（blast radius）隔离开来，同时允许智能体执行命令而无需对每个操作进行审批提示。

精选工具集：根据 Stripe 工程团队的介绍，他们的智能体可访问约 500 个工具，但这些工具是经过精心筛选和维护的，而非随时间累积而成。工具的策展（curation）似乎比工具的数量更为重要。

以 Slack 为优先的调用方式：这三个系统都将 Slack 作为主要接口进行集成，从而在开发者现有的沟通工作流中与其对接，无需切换到新应用程序造成上下文切换开销。

启动时加载丰富上下文：这些智能体在开始工作前，会从 Linear issue、Slack 线程或 GitHub PR 中提取完整上下文，从而减少通过工具调用来发现需求所带来的开销。

子智能体编排：复杂任务会被分解并委派给专门的子智能体，每个子智能体拥有隔离的上下文和聚焦的职责。

这些架构选择已在多个生产部署中被证明是有效的，尽管组织可能需要根据自身环境和需求调整特定组件。

Open SWE 的架构

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

1. 智能体运行环境（Agent Harness）：基于 Deep Agents 构建

Open SWE 并非 fork 现有智能体或从零开始构建，而是基于 Deep Agents 框架进行组合构建。这种做法类似于 Ramp 团队如何在 Modal 上基于 OpenCode 构建 Inspect。

组合式构建带来两大优势：

升级路径：当 Deep Agents 改进时（如更好的上下文管理、更高效的规划、优化的 token 使用），你可以直接纳入这些改进，而无需重建自定义部分。

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

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 文件，它将从沙箱中读取并注入到系统提示词（system prompt）中。该文件可以编码约定、测试要求、架构决策以及团队特定的模式，确保每次智能体运行都遵循这些规范。

源上下文：完整的 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。智能体读取完整的议题上下文，以 👀 表情回应以示确认，并将结果作为评论发布回去。

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

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

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 旨在作为一个可定制的基础设施，而非最终产品。每个主要组件都是可插拔的：

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

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

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

触发器：修改 Slack、Linear 和 GitHub 的集成逻辑。添加新的触发界面，如电子邮件、webhooks 或自定义 UI。

System prompt：定制基础 prompt 以及整合 AGENTS.md 文件的逻辑。添加组织特定的指令、约束或规范。

Middleware：添加你自己的 middleware hooks，用于验证、审批门控、日志记录或安全检查。

Customization Guide 通过示例详细介绍了上述每个扩展点。

与内部实现的对比

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

核心模式是相似的。差异主要体现在实现细节、内部集成以及组织专属的工具链上——这正是将框架适配到不同环境时所预期的结果。

入门指南

Open SWE 现已在 GitHub 上线。

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

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

该框架采用 MIT 许可证。你可以 fork 它，进行自定义，并在内部部署。如果你基于它构建了有趣的项目，我们很乐意听取你的反馈。

多家工程组织已成功在生产环境中部署内部编码代理（coding agents）。Open SWE 提供了类似架构模式的开源实现，旨在针对不同代码库和工作流进行定制。尽管我们仍在探索不同场景下的最佳实践，但该框架为尝试这一方法的团队提供了一个起点。

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

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