OpenAI 2年前埋的暗线，被开发者挖出来玩出花了

2023年11月，OpenAI在开发者大会上随手扔了个叫MCP（模型上下文协议）的东西，当时没人当回事。18个月后，这个"浏览器遥控器"让一批开发者把LinkedIn发帖、Medium发文、SORA视频生成全搬进了命令行——不是用Selenium，不是用Puppeteer，是用一个叫Playwright MCP的工具。

一个协议，把AI从"聊天框"拽进了"操作台"

MCP的本质很简单：给AI一个标准接口，让它能调用外部工具。但Playwright MCP玩得更野——它直接让AI接管浏览器。不是模拟点击，是真正意义上的"看屏幕、点按钮、填表单"。

作者自己的用法很说明问题：LinkedIn定时发帖、Medium自动发布、SORA视频生成，全部串成一条命令行流水线。以前需要写几百行Selenium脚本的事，现在变成给AI发一段自然语言指令。

这背后是浏览器自动化的一次范式转移。Selenium和Puppeteer的问题是：你得告诉它"点哪个坐标""等几秒"。Playwright MCP的做法是：告诉AI"我要发一篇关于AI工具的文章"，让它自己去找发布按钮。

从"写脚本"到"下指令"，中间隔了一个协议

传统浏览器自动化的痛点，做过的人都知道。页面改版，选择器失效；异步加载，定时器猜不准；验证码弹出，整条流水线卡死。作者提到自己"automate"这些任务，但没展开说细节——恰恰说明这套方案的卖点是"省掉细节"。

Playwright本身已经是微软开源的明星项目，比Puppeteer晚出生但架构更干净。MCP协议的出现，给它补上了最后一块拼图：一个AI能理解的"遥控器说明书"。

协议的设计很产品经理思维。不规定AI怎么做决策，只规定"你能调用哪些功能""返回什么格式"。浏览器操作被抽象成工具函数：goto、click、fill、screenshot。AI自己决定调用顺序，就像人类用户自己决定先登录还是先搜索。

作者没提具体代码，但从"command line"这个关键词能推断：整套工作流可以被crontab或者GitHub Actions调度。早上8点，AI自动打开LinkedIn，读一遍草稿，配图，发布，关浏览器。全程无人值守。

为什么是现在？三个条件刚凑齐

这套玩法2023年玩不转。第一，GPT-4级别的视觉理解能力刚成熟，能看懂网页截图里的按钮和输入框。第二，浏览器本身的调试协议（Chrome DevTools Protocol）已经足够稳定，Playwright才能封装出可靠的底层。第三，MCP协议标准化了"AI调用工具"的通信格式，不用每家大厂重复造轮子。

作者的选择很有代表性：LinkedIn、Medium、SORA，三个场景对应三种典型的浏览器自动化需求。社交媒体发布是"定时+重复"，内容平台是"富文本编辑+状态监控"，视频生成是"长任务等待+结果下载"。

这三个场景以前都需要专门的API或者爬虫方案。LinkedIn的API权限收紧多年，Medium的官方API早半死不活，SORA更是没有公开接口。Playwright MCP的解法很粗暴：没有API，就让AI像真人一样用网页版。

这种"无头浏览器+视觉理解"的组合，正在吃掉一批传统RPA（机器人流程自动化）的市场。作者没提成本，但按OpenAI的定价，一次网页操作的成本大概在几分钱到几毛钱之间——比雇个实习生便宜，比写维护脚本省事。

暗线变明牌：开发者已经开始卷场景了

MCP协议开源后，GitHub上冒出一堆类似项目。有的专门做GitHub操作，有的盯上了Figma，还有人让AI自动跑测试用例。作者提到的"Playwright MCP"只是其中一个实现，但选Playwright做底层很精明——微软背书、TypeScript原生、社区活跃。

更值得玩味的是"AI agents"这个词在原文里的出现。不是"脚本"，不是"工具"，是"代理"。这意味着AI有目标、有规划、能纠错。浏览器只是它的手和眼，决策层在模型那边。

作者没说的部分是：这套方案失败时会怎样？页面改版导致AI找不到按钮，是报错退出还是截图问人类？长任务执行到一半浏览器崩溃，怎么断点续传？这些才是生产环境真正的坑。

但"from the command line"这个细节泄露了答案——能进命令行，就能接日志系统、接监控告警、接人工审核队列。作者显然已经跑通了闭环，只是没写进这篇指南里。

2023年11月那个被忽视的发布会，正在以这种方式兑现它的野心。MCP协议设计之初就说了：要让AI像调用函数一样调用整个世界。浏览器只是第一个被攻克的堡垒。

现在的问题是：当你的竞争对手已经让AI 7×24小时自动运营社交媒体、自动发布内容、自动跟进线索，你准备什么时候开始把这条暗线接进自己的工作流？