软件不是竞争：它是我们挫折的地图

Source: Dev.to

介绍

在开始之前，我想说明一点：我并不是在这里做任何营销。我以开发者的身份对其他开发者写这篇文章。我没有戴上“创始人”的帽子；我戴的是那种在终端前熬了太多深夜、因为两段软件无法按我想要的方式交互而感到沮丧的人的帽子。我以我自己的身份发声，因为我认为我们谈论软件竞争的方式根本就有问题。

如果你在开发者圈子里——Hacker News、Reddit、Twitter——花一点时间，你会看到一种持续且令人疲惫的需求：对所有事物进行排名。我们想知道哪个是“最佳”框架，哪款是本周的“Selenium 杀手”，或者为什么有人会在 Tool X 与 Tool Y 同时存在的情况下仍然使用 Tool X。我们把软件开发当作一场高风险的体育联赛，只有一个项目能在赛季结束时捧起冠军奖杯。

但在构建 Doppelganger 之后，我意识到*“更好”*在工程学里是一个相当无用的词。

软件并不会从“差”到“好”沿着一条直线演进。它并不朝着某个客观的完美前进。它是横向演化的。它会分支出来，填补前一代工具——无论多么强大或精致——从未设计去弥合的特定、痛点的空白。没有工具真正取代另一个工具；它们只是为一类不同的问题提供了一套不同的权衡。

The Architecture of the “Gap”

这不仅仅是浏览器自动化的问题；它是我们构建软件的根本法则。

思考一下云计算的历史。 我们并不是因为虚拟机在处理位上“更好”而从物理本地服务器迁移到虚拟机；我们迁移是因为虚拟机填补了 Scaling Gap（扩展性缺口）——它们让我们能够对硬件进行切分。随后我们转向 Docker，并不是要取代虚拟机，而是为了填补 Portability Gap（可移植性缺口）。Docker 解决了 “在我的机器上可以运行” 的问题。

在前端领域， 我们并不是因为 jQuery “坏了” 才从 jQuery 转向 React。我们转向是因为随着 Web 应用变得庞大，React 填补了 State Management Gap（状态管理缺口）。jQuery 本就不适合处理复杂的数据驱动仪表盘，就像锤子不适合拧螺丝一样。

每一种工具不过是一套凝结的观点。它是创作者最在意的内容的映射，更重要的是——他们愿意为此牺牲什么。

浏览器技术专精的历史

要看到这一点的实际表现，看看过去十年的“浏览器之争”。每个人都在争论哪个库更优秀，但如果仔细观察，你会发现它们只是解决不同类型的痛点：

• 兼容性差距（Selenium）：
  Selenium诞生于网络仍然支离破碎、前后不一致的时代。它的设计初衷不是追求速度，而是成为一种通用翻译器，使网站能够在IE6、Safari和Firefox等浏览器上都能正常工作。它仍然比几乎所有其他工具更好地处理传统企业网格，因为这正是它的核心“差距”。

• 可靠性差距（Playwright / Puppeteer）：
  随着网络向大型单页应用（SPA）转变，旧的WebDriver协议开始显得不可靠。这些工具并没有“取代”Selenium；它们只是将速度和直接的引擎同步（CDP）放在首位，因为开发者对时间问题和“等待元素”循环感到沮丧。

• 基础设施差距（Browserless）：
  编写脚本只是战斗的一半。任何尝试在生产Docker容器中运行无头Chrome的人都知道内存泄漏、僵尸进程和资源峰值的噩梦。Browserless并没有尝试重写Playwright API；它只是填补了“在我的IDE中可用”和“在大规模环境中可用”之间的差距。

• 分发差距（Apify）：
  他们审视整个生态，发现编写爬虫已经很困难，而将其扩展并让没有终端的用户也能使用更为艰巨。他们填补了可访问性和变现的差距。

AI 权衡：准确性 vs. 效率

我们现在正看到这一循环在 AI 浏览器代理的爆炸式增长中重复出现。只是速度更快而已。

• Skyvern 曾是主要玩家一段时间。它使用计算机视觉来解决 Resilience Gap。通过让 AI “看到”屏幕而不是读取 DOM 选择器，它创建的自动化在开发者更改 CSS 类时不会中断。这是一次革命，但视觉处理负担大、计算成本高且常常慢。

• Browser Use 稍后出现。它比 Skyvern “更好”吗？在原始视觉推理或高端复杂性方面可能不是。但它填补了 Efficiency Gap。它意识到，对于 80 % 的任务，你可以用更便宜、更快、更易实现的方案来换取一点高端视觉能力。

这是一条分叉路，而不是替代品。你不会买法拉利去运木材，也不会买卡车去参加直线加速赛。没有哪种工具是“错误”的——它们只是满足不同的优先级。

---

为什么我创建了 Doppelganger：“集成鸿沟”

这把我带回到我启动这个项目的真正原因。当我尝试将 n8n 连接到任何网站时，我遇到了一个非常具体的瓶颈。我审视了整个生态，发现其中有一个巨大的空洞。

如果我想让一个代理与站点交互，我的选项在我的使用场景下显得根本不可行。我基本上只有两种选择：

1. 把全部控制权交给一个笨重的 AI 浏览器代理，它必须在每次页面加载时“推理”整个页面。这就像雇人帮我浏览网站——慢、昂贵且不可预测。
2. 为每一个任务手动部署并管理完全独立的代理或微服务。

没有中间地带。没有办法像调用本地无限 API 那样直接调用一个端点。我不想要一个“机器人人”驻留在我的浏览器里；我想要一个可以对话的服务器，而它恰好附带一个浏览器。

我想填补 集成鸿沟。

Doppelganger 的核心理念……（内容继续）

# Doppelganger: Let the AI Use Functions, Not Browsers

**Agents shouldn't be navigating browsers; they should be calling functions.**  
I wanted to predefine a task—like “fetch the last three invoices” or “check the status of this shipment”—and turn that into a self‑hosted API endpoint.

Now, instead of an n8n workflow or a LangChain agent trying to “be a human” and fumbling through a UI, it just sends a JSON request to a URL. Doppelganger handles the browser mess in the background and sends back the data. It’s deterministic, it’s fast, and it’s self‑hosted. It’s not trying to replace the AI’s brain; it’s trying to give the AI a better pair of hands.

最后的思考

我认为如果我们不再把软件视作竞争，我们都会受益。你技术栈中的每个工具之所以存在，是因为某个地方的某个人对一个非常具体的限制感到沮丧，于是决定为其搭建一座桥梁。

我并不是想赢得一场“浏览器战争”，也不想推销下一个“行业标准”工具。我只是想搭建我自己所需的那座桥，让我的工作流顺畅运行。如果你曾因试图把浏览器强行塞进结构化工作流而感到沮丧——既不想花大价钱，也不想每五分钟就崩溃一次——也许这座桥也适合你。没有营销，没有炒作——只有针对不同需求的不同工具。