跳转到正文
莫尔索随笔
返回

Open SWE:构建内部编码智能体的开源框架

预计 9 分钟
AI 原生开发 编辑此页

本文深度解析 Open SWE 开源框架的技术架构与生产实践,探索 Stripe、Ramp、Coinbase 等工程组织如何构建内部编码智能体,以及企业如何定制化部署适合自身业务的 AI 编码智能体。

为什么你的组织需要专属编码智能体

过去一年中,我观察到多个工程组织正在构建与其开发团队协同工作的内部编码智能体。Stripe 开发了 Minions(详见我之前的介绍文章Stripe Minions:全自动 AI 编码代理,每周完成 1300+ PRRamp 构建了 InspectCoinbase 创建了 Forge(之前叫Cloudbot)。这些系统被集成到现有工作流程中(通过 Slack、Linear 和 GitHub 访问),而非要求工程师采用新的界面。

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

然而,Kishan 在其技术评论中尖锐地指出:现成工具厂商常常暗示只需将他们的智能体接入你的系统,就能立即实现生产级成果。这种营销话术掩盖了一个残酷的现实——你的组织拥有独特的代码库结构、工程规范、安全要求和部署流程。任何外部开发的智能体,无论多么先进,都不可能开箱即用地理解这些细微差别。

这正是为什么越来越多的企业开始意识到:真正有效的编码智能体必须是从组织内部生长出来的原生解决方案

Open SWE:开源框架的技术架构

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

生产部署的模式总结

当我研究 Stripe、Ramp 和 Coinbase 如何构建他们的编码智能体时,注意到它们做出了相似的架构决策。以下是这些系统的共同点:

隔离执行环境:任务在专用的云沙盒中运行,在严格边界内拥有完整权限。这将任何错误的爆炸半径与生产系统隔离,同时允许智能体执行命令而无需为每个操作都经过批准提示。

精选工具集:根据 Kishan 的观察,他们的智能体可以访问大约 500 个工具,但这些是经过精心选择和维护的,而不是随着时间积累。工具策划似乎比工具数量更重要。

Slack 优先调用:这三个系统都将 Slack 集成为主要界面,在开发者现有的通信工作流中与他们见面,而不是要求他们切换到新的应用程序。

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

子智能体编排:复杂任务被分解并委托给专门的子智能体,每个子智能体都有隔离的上下文和专注的职责。

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

Open SWE 的核心组件详解

Open SWE 提供了类似架构模式的开源实现。以下是框架如何映射到我所观察到的内容:

1. 智能体 Harness:基于 Deep Agents 构建

Open SWE 不是 fork 现有智能体或从头开始构建,而是基于 Deep Agents 框架组合而成。这种方法类似于 Ramp 在 OpenCode 之上构建的方式。

组合提供两个优势:

  • 升级路径:当 Deep Agents 改进时(更好的上下文管理、更高效的规划、优化的 token 使用),你可以在不重建定制的情况下整合这些改进。
  • 无需 fork 即可定制:你可以将组织特定的工具、提示和工作流作为配置维护,而不是作为对核心智能体逻辑的修改。

2. 沙盒:隔离的云环境

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

Open SWE 开箱即用地支持多个沙盒提供商,你也可以实现自己的沙盒后端。

这遵循我观察到的模式:先隔离,然后在边界内授予完整权限。

3. 工具:精选,而非积累

Stripe 的核心洞察:工具的精挑细选(Curation)比工具的数量更重要。 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:优雅地捕获和处理工具错误。

这种在智能体(模型驱动)和确定性(中间件驱动)编排之间的分离可以帮助平衡可靠性与灵活性。

与内部实现的对比

以下是 Open SWE 与 Stripe、Ramp 和 Coinbase 内部系统的对比:

决策维度 (Decision)Open SWEStripe (Minions)Ramp (Inspect)Coinbase (Cloudbot)
测试床/框架 (Harness)组合式 (Composed) (基于 Deep Agents/LangGraph)分叉自 (Forked) Goose组合式 (Composed) (基于 OpenCode)从零自建 (Built from scratch)
沙箱 (Sandbox)可插拔式 (Pluggable) (支持 Modal, Daytona, Runloop 等)AWS EC2 devboxes (预热)Modal 容器 (预热)内部自研 (In-house)
工具 (Tools)约 15 个,精选约 500 个,按 Agent 精选OpenCode SDK + 扩展MCPs + 自定义 Skills
上下文 (Context)AGENTS.md + issue/thread规则文件 (Rule files) + 预水合 (pre-hydration)OpenCode 内置Linear 优先 + MCPs
编排 (Orchestration)子代理 (Subagents) + 中间件Blueprints (确定性 + Agentic)Sessions + 子会话三种模式
调用 (Invocation)Slack, Linear, GitHubSlack + 内嵌按钮Slack + Web + Chrome 扩展Slack 原生 (Slack-native)
校验 (Validation)提示词驱动 + PR 安全网三层校验 (本地 + CI + 1次重试)视觉 DOM 验证代理委员会 (Agent councils) + 自动合并

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

开始上手

Open SWE 现已可在 GitHub 获取。

  • 快速入门:涵盖 GitHub App 创建、LangSmith 设置、Linear/Slack/GitHub 触发器和生产部署。
  • 定制指南:展示如何为你的组织更换沙盒、模型、工具、触发器、系统提示和中间件。

几个工程组织已成功在生产环境中部署了内部编码智能体。Open SWE 提供了类似架构模式的开源实现,旨在针对不同代码库和工作流进行定制。虽然我仍在了解在不同环境中有效的方法,但该框架为探索这种方法的团队提供了一个起点。

参考资源


编辑此页