三家大厂各造编码智能体，最后却撞出同一套架构

Stripe 做了 Minions，Ramp 做了 Inspect，Coinbase 做了 Cloudbot。三家公司各干各的，没有商量，最后却长出了几乎一样的骨架。

LangChain 把这套骨架开源了，名字叫 Open SWE。它不是一个新发明的架构，而是把已经在大厂生产环境里跑通的模式，整理成一份可复制的模板。

这件事值得拆开看：为什么独立开发的系统会收敛到同一套设计？这套设计里哪些是硬需求，哪些只是巧合？

三套系统，五个共同点

Stripe、Ramp、Coinbase 的编码智能体都接进了开发者已有的工作流——Slack、Linear、GitHub，而不是要求工程师换一个新界面。这是第一个共同点：不改变人的习惯，让智能体来适应人。

第二个是隔离执行环境。任务跑在专用的云端沙箱里，沙箱内部给足权限，边界之外严格隔离。这样既能让智能体放手执行命令、不用每步都等审批，又能把出错的影响范围挡在生产系统之外。

第三个是精选工具集。Stripe 工程团队的说法是，他们的智能体大约能用到 500 个工具，但这些工具是被精心挑选和维护的，不是日积月累堆上去的。工具的质量比数量更重要。

第四个是启动时带足上下文。智能体开工前会先把 Linear 议题、Slack 讨论串或 GitHub PR 的完整信息拉进来，减少靠工具调用一点点摸索需求的消耗。

第五个是子智能体编排。复杂任务会被拆开，交给专门的子智能体，每个子智能体有独立的上下文和明确的职责。

正方：收敛说明这是刚需

三家公司在互不知情的情况下走到同一个架构，这个事实本身就是论据。如果只是某一家团队的偏好，不会出现这种重合。

支持这个判断的证据是：这些选择已经在多个生产部署里被验证有效。隔离沙箱解决了安全与效率的矛盾，精选工具解决了维护成本，Slack 优先解决了采纳阻力，启动上下文解决了需求发现，子智能体解决了复杂任务分解。每一条都对应一个真实存在的工程痛点。

LangChain 的做法是把这个共识固化成框架。Open SWE 构建在 Deep Agents 和 LangGraph 之上，提供的是核心架构组件，而不是一个成品。如果你的组织正在探索内部编码智能体，它可以当起点。

反方：收敛也可能只是约束相同

另一种解释是，这些系统面对的外部条件本来就一样——都要接 Slack，都要连 GitHub，都要在云上跑沙箱，都要控制权限边界。条件相同，解法自然趋同，未必说明这套架构就是最优解。

这个反驳有它的道理。素材本身也留了口子：这些架构选择在多个生产部署中被证明有效，但组织很可能需要根据自身环境和需求调整具体组件。也就是说，共同点归共同点，落地时该改还得改。

还有一个细节值得注意：Open SWE 没有选择 fork 一个现成的智能体，也没有从零开始写，而是组合在 Deep Agents 框架之上。Ramp 团队构建 Inspect 时，用的也是类似思路——搭在 OpenCode 上面。

组合而非重写，图的是什么

组合带来两个好处。

一是升级路径。当 Deep Agents 本身变好——上下文管理更强、规划更高效、token 使用更优化——你可以直接吸收这些改进，不用推倒自己的定制部分重建。

二是定制不用 fork。组织特有的工具、提示词和工作流，可以作为配置维护，而不是去改核心智能体逻辑。

代码层面，Open SWE 的入口是一个 create_deep_agent 调用，传入模型、系统提示词、工具列表、沙箱后端和中间件。工具列表里能看到 http_request、fetch_url、commit_and_open_pr、linear_comment、slack_thread_reply 这些名字，基本对应了前面说的那套工作流集成。

Deep Agents 提供的基础设施包括：通过 write_todos 做内置规划、基于文件的上下文管理、通过 task 工具原生派生子智能体，以及用于确定性编排的中间件钩子。

沙箱、工具、上下文，三块怎么落地

每个任务跑在自己的隔离云沙箱里，那是一个远程 Linux 环境，有完整的 shell 访问权限。仓库被克隆进去，智能体拿到全部权限，错误被限制在这个环境内。Open SWE 开箱支持多种沙箱提供商，也可以自己实现沙箱后端。这套做法遵循的逻辑是：先隔离，再在边界内给足权限。

工具集方面，Open SWE 自带一套精简工具，再加上 Deep Agents 的内置工具：read_file、write_file、edit_file、ls、glob、grep、write_todos，以及用于派生子智能体的 task。更小、更精选的工具集更容易测试、维护和推理。需要额外工具时——内部 API、自定义部署系统、专用测试框架——显式加进去就行。

上下文来自两层。一层是仓库根目录的 AGENTS.md 文件，它从沙箱里被读取并注入系统提示词，可以承载约定、测试要求、架构决策和团队特有的模式，每次智能体运行都会遵循。另一层是任务上下文：完整的 Linear 议题（标题、描述、评论）或 Slack 讨论串历史，在智能体启动前就组装好传进去，省掉额外的工具调用。两层配合，兼顾仓库级知识和任务级信息。

编排则结合了两种机制：子智能体负责把独立子任务分派出去，每个子智能体有自己的中间件栈、待办列表和文件操作；中间件负责确定性的调度控制。

这份模板该怎么用

Open SWE 的定位很清楚：它捕捉的是已经存在的模式，提供一个可定制的开源实现。它不是告诉你必须这么做，而是告诉你别人已经这么做了，而且不止一家。

对正在考虑内部编码智能体的团队来说，价值在于省掉从零摸索架构的时间。但前面那个反方观点同样成立——共同点来自共同约束，你的约束如果不同，架构就该不同。把它当起点，别当答案。