Open SWE：内部编程智能体开源框架

过去一年，我们看到不少工程团队都在构建内部编程智能体，让 AI 辅助开发工作。Stripe 开发了 Minions，Ramp 打造了 Inspect，Coinbase 则推出了 Cloudbot。这些系统都直接集成到现有工作流里——通过 Slack、Linear 和 GitHub 就能调用，工程师不用切换界面。

虽然各自独立开发，但这些系统在架构上却高度相似：隔离的云沙箱、精选的工具集、子智能体编排，以及与开发工作流的深度集成。这种趋同说明，在生产环境中部署 AI 智能体确实存在一些共性需求。

今天，我们正式发布 Open SWE，一个开源框架。它把这些经过验证的模式封装起来，提供了一套可定制的核心架构组件。Open SWE 基于 Deep Agents 和 LangGraph 构建。如果你的团队也在探索内部编程智能体，它可以作为一个不错的起点。

生产部署中的架构模式

Kishan Dahya 在一篇推文中详细分析了 Stripe、Ramp 和 Coinbase 的智能体架构决策。我们总结如下，并看看 Open SWE 是如何在这些维度上对齐的。

隔离执行环境：任务在专用的云沙箱中运行，沙箱内部拥有完整权限，但外部有严格边界。这样既能隔离错误影响，避免波及生产系统，又能让智能体无需每次操作都等待人工批准。

精选工具集：根据 Stripe 工程团队的分享，他们的智能体大约有 500 个工具可用，但这些工具都是精心挑选和维护的，并非随意堆砌。工具的质量比数量更重要。

Slack 优先调用：三个系统都把 Slack 作为主要接口，直接在开发者现有的沟通工具里触发智能体，省去了切换应用的麻烦。

启动时获取丰富上下文：智能体在开始工作前，会从 Linear 工单、Slack 线程或 GitHub PR 中拉取完整上下文，减少了通过工具调用去发现需求的开销。

子智能体编排：复杂任务会被分解并委托给专门的子智能体处理，每个子智能体拥有独立的上下文和明确的职责。

这些架构选择在多个生产部署中都被证明是有效的，当然，不同团队可能还需要根据自身环境和需求进行微调。

Open SWE 的架构设计

Open SWE 用开源的方式实现了类似的架构模式。下面我们看看框架是如何映射这些观察的。

1. 智能体执行框架（Harness）：基于 Deep Agents 组合

Open SWE 没有 fork 现有智能体或从头构建，而是选择在 Deep Agents 框架上进行组合。这种做法和 Ramp 团队基于 OpenCode 构建 Inspect 的思路类似。

组合架构有两个好处：

升级路径：当 Deep Agents 本身改进时（比如更好的上下文管理、更高效的规划、更优的 token 使用），你可以直接集成这些改进，无需重写自己的定制部分。

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

code

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 工具原生支持子智能体生成，以及用于确定性编排的中间件（Middleware）钩子。

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. 编排（Orchestration）：子智能体 + 中间件

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 通过基于文件的记忆来处理这些，将大块结果卸载存储，而不是全部保留在对话历史中。这有助于在处理大型代码库时防止上下文窗口（Context Window）溢出。

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

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

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

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

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

Open SWE 的设计初衷是作为可定制的基础框架，而非成品。所有核心组件都支持热插拔：

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

模型：支持任何 LLM 提供商。默认用 Claude Opus 4，但你可以为不同子任务配置不同模型。

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

触发器：修改 Slack、Linear 和 GitHub 的集成逻辑。新增邮件、webhook 或自定义 UI 等触发方式。

系统提示词：定制基础提示词，调整 AGENTS.md 文件的整合逻辑。加入组织特有的指令、约束或规范。

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

定制指南详细介绍了每个扩展点，并附有示例。

与内部实现对比

根据 Stripe、Ramp 和 Coinbase 的公开信息，Open SWE 与这些公司的内部系统对比如下：

决策项	Open SWE	Stripe (Minions)	Ramp (Inspect)	Coinbase (Cloudbot)
执行框架（Harness）	组合式（Deep Agents/LangGraph）	分叉式（Goose）	组合式（OpenCode）	从头构建
沙盒	可插拔（Modal、Daytona、Runloop 等）	AWS EC2 开发盒（预热）	Modal 容器（预热）	自研
工具	~15 个，精选	~500 个，按智能体（Agent）精选	OpenCode SDK + 扩展	MCPs + 自定义 Skills
上下文	AGENTS.md + 问题/线程	规则文件 + 预加载	OpenCode 内置	Linear 优先 + MCPs
编排（Orchestration）	子智能体（Subagents）+ 中间件	蓝图（确定性 + 智能体）	会话 + 子会话	三种模式
调用方式	Slack、Linear、GitHub	Slack + 嵌入式按钮	Slack + 网页 + Chrome 扩展	Slack 原生
验证	提示词驱动 + PR 安全网	三层（本地 + CI + 1 次重试）	可视化 DOM 验证	智能体委员会 + 自动合并

核心模式大同小异。差异主要体现在实现细节、内部集成和特定组织的工具上——这恰恰是框架适配不同环境时的正常现象。

开始使用

Open SWE 已在 GitHub 开源。

安装指南：手把手教你创建 GitHub App、设置 LangSmith、配置 Linear/Slack/GitHub 触发器，以及生产部署。

定制指南：演示如何为你的组织更换沙盒、模型、工具、触发器、系统提示词和中间件。

框架采用 MIT 许可证。你可以 fork 它、定制它，并在内部部署。如果你基于它构建了有趣的东西，我们很乐意听听你的故事。

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