Stripe 有 Minions，Ramp 有 Inspect，Coinbase 有 Cloudbot。这三家公司做了同一件事：造了自己的内部 AI 编程 Agent。不是用 Cursor 写代码，不是用 GitHub Copilot 补全，而是把 Agent 集成到 Slack、Linear、GitHub 里，让工程师在已有的工作流里直接调用 AI 干活——修 bug、写功能、开 PR。
但每家公司都从零开始造了一遍。
LangChain 觉得这件事不该重复做。所以他们开源了 Open SWE——一个内部编程 Agent 框架，直接复刻了 Stripe/Ramp/Coinbase 的架构模式。9.7k star，MIT 协议。
本文提纲
- Open SWE 是什么、不是什么
- 七层架构：从大厂模式提炼出来的设计
- 触发方式：Slack、Linear、GitHub
- 云沙箱：每个任务独立环境
- 工具设计：精挑细选的 15 个
- 和 OpenHands、SWE-bench 的区别
- 实际用起来什么样
Open SWE 是什么、不是什么
先说清楚定位。
Open SWE 不是：
- 不是通用编程助手（那是 Cursor、Copilot 的定位）
- 不是跑 benchmark 的研究工具（那是 SWE-bench）
- 不是给你装个插件就能用的产品
Open SWE 是：
- 一个框架，用来搭建你组织内部的编程 Agent
- 你需要 clone 下来，按自己的代码库和工作流定制，然后部署
- 核心场景：工程师在 Slack 里 @Agent 修 bug，在 Linear 里让 Agent 接 issue，在 PR review 里让 Agent 改反馈
一句话总结：如果你所在的技术团队想拥有一个像 Stripe Minions 那样的内部 AI 编程工具，Open SWE 是起点。
七层架构：从大厂模式提炼出来的设计
Open SWE 的架构不是拍脑袋想出来的。README 里直接放了一张对比表，把 Stripe、Ramp、Coinbase 的方案和 Open SWE 的设计一一对应：
| 层 | Open SWE | Stripe (Minions) | Ramp (Inspect) | Coinbase (Cloudbot) |
|---|---|---|---|---|
| Agent 框架 | Deep Agents 组合式 | Fork Goose | 组合 OpenCode | 从零自建 |
| 沙箱 | 可插拔（Modal/Daytona/Runloop） | AWS EC2 预热 | Modal 容器预热 | 自建 |
| 工具 | ~15 个精挑 | ~500 个按 Agent 分配 | OpenCode SDK + 扩展 | MCP + 自定义 Skills |
| 上下文 | AGENTS.md + issue/thread | Rule 文件 + 预注入 | OpenCode 内置 | Linear 优先 + MCP |
| 编排 | 子 Agent + 中间件 | Blueprints（确定性 + Agent 混合） | Session + 子 Session | 三种模式 |
| 触发 | Slack、Linear、GitHub | Slack + 嵌入按钮 | Slack + Web + Chrome 扩展 | Slack 原生 |
| 验证 | Prompt 驱动 + PR 安全网 | 三层（本地 + CI + 1次重试） | 可视化 DOM 验证 | Agent 委员会 + 自动合并 |
七层逐个说：
1. Agent Harness（组合式而非 fork）
Open SWE 没有从零造 Agent 引擎，也没有 fork 某个现有项目。它组合在 Deep Agents 框架之上——LangChain 的另一个项目，专门做 Agent 编排。好处是底层框架升级你能跟着走，坏处是多了一层抽象。
create_deep_agent(model="openai:gpt-5.5",system_prompt=construct_system_prompt(...),tools=[http_request, fetch_url, commit_and_open_pr, ...],backend=sandbox_backend,middleware=[ToolErrorMiddleware(), check_message_queue_before_model, ...],
)
2. Sandbox（每个任务独立环境）
每个任务跑在自己的云沙箱里——一个远程 Linux 环境，完整的 shell 权限。代码 clone 进去，Agent 在里面随便折腾，爆炸半径完全隔离。多个任务并行跑，互不干扰。
支持 5 种沙箱后端：
| 后端 | 定位 |
|---|---|
| LangSmith | 默认，开箱即用 |
| Daytona | 第三方沙箱服务 |
| Runloop | 另一个沙箱选项 |
| Modal | Serverless 容器 |
| Local | 仅开发用，无隔离 |
Stripe 用 AWS EC2 预热实例，Ramp 用 Modal 预热容器。Open SWE 把这些选项都留给了你。
3. Tools（精挑而非堆砌）
Stripe 有 500 个工具按 Agent 分配。Open SWE 选择了另一条路：~15 个精选工具，每个都有明确用途。
核心工具：
execute— 在沙箱里执行 shell 命令commit_and_open_pr— Git commit 并开 draft PRfetch_url/http_request— 获取网页内容和调 APIlinear_comment/slack_thread_reply— 回复 Linear issue 和 Slack 线程web_search— 通过 Exa 搜索互联网
文件操作工具从 Deep Agents 继承：read_file、write_file、edit_file、ls、glob、grep。
4. Context（AGENTS.md + issue 上下文）
每个仓库放一个 AGENTS.md，写清楚代码规范、架构约定、注意事项。Agent 启动时自动读取并注入系统 prompt。加上 Linear issue 的完整内容（标题、描述、评论）或 Slack 线程历史，Agent 拿到的上下文是完整的。
还有一个 default_prompt.md 作为组织级别的默认指令。
5. Orchestration（子 Agent + 中间件）
task 工具可以派生子 Agent，每个子 Agent 有自己的中间件栈、todo 列表和文件操作。中间件做三件事：
check_message_queue_before_model— Agent 运行中你可以追加消息，它会在下一步之前读取open_pr_if_needed— 兜底中间件，Agent 忘了开 PR 的话自动补上ToolErrorMiddleware— 工具调用出错时捕获和处理
6. Invocation（三入口）
这是 Open SWE 和通用编程助手最大的区别——Agent 不在编辑器里，在你的工作流里。
7. Validation（prompt 驱动 + 安全网）
Agent 被指示在 commit 前跑 lint、format、test。open_pr_if_needed 中间件是兜底。
触发方式：Slack、Linear、GitHub
三种触发方式，各自独立：
Slack： 在任何线程里 @Agent，加上 repo:owner/name 指定仓库。Agent 立刻回复 表示收到，然后去沙箱里干活。干完把结果贴回线程。
Linear： 在 issue 评论里 @openswe。Agent 读取完整 issue 上下文（标题、描述、所有评论），然后开始工作。完成后在 issue 里贴评论并关联 PR。
GitHub： 在 PR 评论里 @openswe。Agent 读取 PR diff 和 review comments，针对反馈做修改，直接推送到 PR 分支。
这三种方式覆盖了工程师日常工作的三个核心场景：讨论（Slack）、排任务（Linear）、代码审查（GitHub）。Agent 就嵌入在这些流程里，不需要额外打开任何工具。
云沙箱：每个任务独立环境
沙箱是整个架构里最关键的基建决策。为什么不用本地环境？
- 隔离性 — Agent 在沙箱里可以随便执行命令，不怕搞坏任何东西
- 并行性 — 多个任务同时跑，每个独立沙箱，不排队
- 持久性 — 关掉 Slack 窗口，沙箱还在跑。后续消息复用同一个沙箱
- 可重建 — 沙箱不可达时自动重建，不丢失进度（repo 从 PR 状态恢复）
沙箱从 Docker 镜像创建（bracelangchain/deepagents-sandbox:v1），每个约 32GB 文件系统空间。可以预装团队的常用工具链。
创建沙箱快照的代码：
from langsmith.sandbox import SandboxClientclient = SandboxClient(api_key="<your key>")
snapshot = client.create_snapshot(name="open-swe",docker_image="bracelangchain/deepagents-sandbox:v1",fs_capacity_bytes=32 * 1024**3,
)
工具设计：精挑细选的 15 个
和 Stripe 的 500 个工具相比，15 个看起来太少。但这是有意为之的设计选择：
- 500 个工具意味着每个 Agent 只分配一小部分，需要复杂的路由逻辑
- 15 个工具意味着每个 Agent 都有完整能力集，路由简单
- 不够用时，自己加。自定义工具就是一个 Python 函数：
# agent/tools/datadog_search.py
def datadog_search(query: str, time_range: str = "1h") -> dict[str, Any]:
"""Search Datadog logs for debugging context."""...
加完之后在 server.py 的工具列表里注册就行。
模型也可以随意切换：
# OpenAI（默认，使用 Responses API）
model=make_model("openai:gpt-5.5", reasoning={"effort": "medium"})# Anthropic
model=make_model("anthropic:claude-sonnet-4-6", temperature=0)# Google
model=make_model("google_genai:gemini-2.5-pro", temperature=0)
和 OpenHands、SWE-bench 的区别
这是必须要澄清的。
| Open SWE | OpenHands | SWE-bench | |
|---|---|---|---|
| 目标 | 搭建内部编程 Agent | 通用 AI 编程平台 | 评估 benchmark |
| 用户 | 工程团队 | 个人开发者 | 研究人员 |
| 集成 | Slack/Linear/GitHub 深度集成 | Web UI | 命令行 |
| 沙箱 | 多种云沙箱可选 | Docker 容器 | Docker 容器 |
| 产出 | PR + 工作流集成 | 代码修改 | benchmark 分数 |
Open SWE 不是去跑 SWE-bench 拿高分的，它的 README 里甚至没有放任何 benchmark 数据。它的价值在于架构模式——把一线大厂验证过的内部 Agent 设计变成了可复用的开源代码。
实际用起来什么样
部署流程：
git clone https://github.com/langchain-ai/open-swe.git
cd open-swe
uv venv && source .venv/bin/activate
uv sync --all-extras
然后需要：
1. 创建 GitHub App（需要 Contents R/W、Pull requests R/W、Issues R/W 权限）
2. 配置 LangSmith（API key、tenant ID、project ID）
3. 构建沙箱快照
4. 配置触发器（Slack/Linear/GitHub，都是可选的）
5. 设置环境变量（约 30 个）
6. 启动服务：uv run langgraph dev --no-browser
生产环境部署到 LangGraph Cloud。
日常使用：
工程师在 Linear issue 里评论 @openswe，Agent 自动：
1. 读取 issue 全部上下文
2. 在云沙箱里 clone 仓库
3. 理解代码，实施修改
4. 跑 lint/test 验证
5. 开 draft PR
6. 在 issue 里贴评论关联 PR
工程师全程不需要离开 Linear。等 Agent 干完活，点进 PR review 就行。
Open SWE 的意义不在于它比 Cursor 或 Copilot 更强——它和那些工具不在同一个赛道。它的意义在于：给想造内部编程 Agent 的团队一个经过验证的起点。Stripe 花了不知道多少工程师年造了 Minions，你现在可以在 Open SWE 的基础上花几天时间搭出类似的东西。9.7k star 说明这件事有很多团队需要。
作者: itech001
来源: 公众号：AI人工智能时代
主页: https://www.theaiera.cn，每日分享最前沿的AI新闻和技术。
本文首发于 AI人工智能时代，转载请注明出处。