MCP

凌晨两点，我的 Agent 又停了。

不是模型挂了，不是网络断了，不是 Token 用完了。是 Browser MCP 的 WebSocket 连接断了，而那个该死的 Chrome 扩展弹窗里，「Connect」按钮正安静地等着有人去点一下。

我在跑 --watch 模式——Agent 监控一个内部系统，页面一变就自动抓取数据、做分析、写报告。整条链路全自动，唯独 Browser MCP 的连接需要手动点。每次断连，我就得从床上爬起来，点开 Chrome 工具栏那个小图标，点一下 Connect。

在 Agent 操作浏览器的九条路线 里，我把 Browser MCP 归到「真实浏览器 + 扩展 + CDP + MCP」那一类，给了它四颗星的企业推荐度。但那篇文章没写的是： 它有一个致命的手动断点，而这个断点在自动化场景下足以毁掉整条链路。

这篇文章记录我怎么用 Vision 大模型 + macOS 原生自动化，把这个断点彻底消灭。不是 Demo，是从 v1.0 迭代到 v1.4.2、踩了六个坑之后的生产方案。

值得一提的是：整个项目的所有代码——从第一行 screencapture 调用到最后的 LaunchAgent plist——都是 Opus 4.8 写的。我做的事情是描述需求、测试、报错、再描述。这个过程本身就是一个有趣的发现：当你把「我需要一个能自动点击 Chrome 扩展按钮的脚本」这种模糊需求扔给一个足够强的模型，它给出的第一版方案往往方向正确但细节全错——而每一处「错」的背后，都藏着一个 macOS 平台特有的坑。

上个月一个团队来找我，说他们要做企业内部的 AI Agent，需要操作浏览器。

第一个问题就是：「用 Playwright 还是 Browser Use？」

我说这个问题本身就问错了。就像你问「盖楼用钢筋还是混凝土」——答案是都用，但用在不同的层。

Browser Automation 在 AI Agent 语境下，已经不是一道单选题。它是一张技术地图，九个梯队，各有适用场景。而真正在生产环境里跑通的企业 Agent，几乎都是 分层架构——API 优先，结构化浏览器控制居中，Vision 兜底。

接着 销售流程 AI 化系列 的汽配分销商案例讲。

上一篇讲的是理念：解决方案对象、拜访质检、履约 SOP 编译。这一篇讲落地：FDE 到客户现场，怎么用基础设施在一天内把这些理念变成可运行的 Agent。

老周（售前）和小林（FDE）一起到了汽配客户现场。客户有 200 家门店，销售团队 30 人，每天处理 50+ 客户咨询、20+ 报价单、10+ 合同审批。

问题是：销售流程全靠人肉，信息散落在微信、Excel、邮件里，老周那份 80 页 PPT 签完单就死了。

上周五晚上，我在公司用 Claude Code 调了一个小时的部署脚本，Agent 帮我定位了问题、改了三个文件、跑通了测试。周六早上我打开家里的笔记本，想继续收尾——打开终端，Claude Code 启动，干干净净，什么都不记得。

我得重新描述问题、重新贴日志、重新解释上下文。那种感觉，就像你跟一个同事讨论了一下午方案，第二天他失忆了。

这不是某个工具的 bug。这是当前所有 AI Agent 的共同困境：Agent 的记忆被钉死在了设备上。

很多团队对 Agent 的理解还停留在"LLM + Prompt + 几个工具调用"。这种理解能跑通 Demo，但一旦进入企业级场景——多任务并行、多系统集成、多角色协作、安全审计——就会发现：Agent 系统的核心挑战不是让 LLM 更聪明，而是构建一个可扩展、可治理、可审计的运行时架构。

Agent 系统本质上在解决五个问题：用户要做什么（Agent）、谁来执行（Sub-Agent）、如何执行（Skill）、从哪里获取数据（MCP）、执行过程的状态存在哪里（Workspace）。这五个问题对应了系统的五个核心层次。

本文将这套架构完整展开。

当我们谈论AI应用开发时，经常会听到API、MCP（Model Context Protocol）和Skills这三个词。它们看起来都是让程序之间"对话"的方式，但究竟有什么不同？让我用一个简单的餐厅比喻来解释。

想象你要解决"吃饭"这个问题，有三种不同的方式可以选择。每种方式代表了不同的技术范式，适用于不同的场景。