写给还在为浏览器设计软件的人：Agent 不是功能，是新的客户端
最近我发现，自己使用 Vercel 和 GitHub 的方式变了。
以前，我会打开浏览器，进入控制台，找到项目，检查状态，再完成操作。现在，我越来越多地把目标直接交给 Codex：看看部署为什么失败，检查最新的变更，把代码提交上去，创建一个 PR。
事情做完了，我却可能一次都没有打开 Vercel 或 GitHub 的网页。
这让我开始怀疑，我们可能把 Agent 放错了位置。
现在大多数产品都在问同一个问题：怎样把 AI 放进我们的软件？
也许更值得问的是另一个问题：如果用户将来主要通过 Agent 使用我们的软件，我们应该把什么暴露给它？
这两个问题看起来相似，方向却完全相反。第一个把 Agent 当成产品里的一个功能。第二个把 Agent 当成一种新的客户端。
我越来越相信，后者才是更大的变化。
客户端真正做的，不只是显示页面
过去几十年，我们已经习惯了三种客户端：浏览器、手机 App 和桌面 App。
它们的形态不同，但都要求用户完成同一件事：理解软件的语言。
你需要知道功能藏在哪个页面，哪个按钮代表什么，先填哪一项，再确认哪一步。你脑子里原本只有一个目标，却必须亲手把它翻译成软件能够理解的一连串操作。
Agent 改变的不是输入框，而是翻译发生的位置。
过去，是人把意图翻译成操作。
以后，是 Agent 把意图翻译成操作。
用户说“帮我找出昨天部署失败的原因”，Agent 决定该查哪次部署、读取哪些日志、对照哪次提交，以及最后该怎样呈现结论。用户不需要先知道这些信息分别藏在哪几个产品里。
这正是客户端一直在做的工作：接收人的意图，调用系统能力，再把结果呈现回来。只不过，过去的客户端要求人适应机器的结构；Agent 开始让机器适应人的目标。
最先发生变化的，为什么是 IDE
通用 Agent 最早从 coding agent 演化出来，并不是偶然。
代码世界早就为机器准备好了。
代码是文本，文件可以搜索，操作有 CLI，修改可以 diff，结果可以测试，失败可以回滚。Git 记录了谁改了什么，测试告诉你结果是否成立，终端让复杂操作能够被精确重放。
Agent 不需要模仿一个程序员怎样移动鼠标。它可以直接进入软件开发的结构层。
于是 IDE 的职责开始变化。
没有 Agent 时，IDE 负责输入、浏览、运行、调试和修改。现在，越来越多的写入发生在 Agent 里。IDE 依然重要，但人更多地用它查看文件、理解变化、审阅 diff 和确认结果。
写入没有消失，只是迁移了。
这解释了一个看似反常的产品现象：有些 coding agent 内置的文件浏览器只能读，不能直接编辑，使用体验却没有因此崩溃。我们过去会觉得一个不能编辑的代码浏览器是不完整的。现在，它可能刚好完成了人真正需要完成的部分——看清楚。
Agent 负责行动，人负责理解和判断。
如果这个分工在软件开发中成立，它为什么只会停留在软件开发中？
浏览器不会消失，它会失去对操作的垄断
最容易反驳这个判断的方式，是指出人仍然需要界面。
确实如此。
地图不能只返回一串坐标。设计稿不能只返回节点 JSON。财务报表不能只告诉你“整体正常”。当我们需要探索、比较、建立空间感，或者在高风险动作之前确认细节时，视觉界面仍然不可替代。
但“界面仍然重要”和“界面仍然是主要操作入口”不是同一件事。
汽车有仪表盘，不代表驾驶者需要亲手控制发动机的每一个阀门。仪表盘最重要的职责，是把复杂状态变成人能够理解的证据。
浏览器未来可能越来越像这样的仪表盘。
大量日常输入和控制从 Agent 发出；浏览器负责展示状态、解释结果、处理例外，以及让用户对关键动作做最后确认。
这个分工已经开始出现在协议里。WebMCP 允许网站在保留原有人类界面的同时，把页面能力作为预定义工具暴露给 Agent。远程 MCP 更进一步：即使网页没有打开，Agent 也可以直接操作服务。
这不是“AI 帮你点击网页”。
这是同一个系统开始服务两类客户端：一类面向人的眼睛和手，另一类面向 Agent 的推理和工具调用。
工具、MCP、Skill 和 Plugin，其实在回答四个不同的问题
我经历了 Agent 连接外部世界的几轮变化。一开始，它只能调用本地工具和脚本。那时最重要的问题是：Agent 能做什么？
后来出现了 MCP。不同服务可以用同一种方式向 Agent 暴露能力。问题变成了：Agent 怎样连接这些能力？
但能连接，不代表会正确使用。
于是 Skill 开始承担另一层工作。它把工作流、经验、模板和注意事项组织起来，并在真正需要时才加载。问题变成了：Agent 应该怎样完成这类任务？
再后来，Plugin 把 Skill、MCP server、认证和可选 UI 包装成可以安装和分发的整体。它开始回答第四个问题：普通用户怎样安全地获得并信任这项能力？
所以，这条脉络真正展示的不是四个新名词，而是 Agent 成为客户端所必须补齐的四个条件：
能力、连接、经验、信任。
早期 MCP 生态最明显的短板是最后一项。很多连接依赖本地进程、环境变量和手工 token。它们适合实验，却很难成为普通人的基础设施。
现在，远程 MCP 的授权开始围绕 OAuth 2.1、资源发现、scope、资源绑定和服务端 token 校验收敛。Plugin 又把连接、权限提示、工作流和分发组织在一起。
这并不令人兴奋。认证、权限和审计很少出现在令人兴奋的演示里。
但一项技术开始认真处理无聊问题，通常意味着它正在从玩具变成基础设施。
数据支持这个趋势，也提醒我们不要跑得太快
我的日常体验很容易让我相信，所有人都已经在这样工作。数据给了一个更克制的答案。
Gallup 在 2026 年第二季度的调查中发现，52% 的美国员工已经在工作中使用 AI。但多数人仍然把它用于写作、搜索和一般性问题解决。在 AI 用户中，真正使用自动化的只有 16%。
McKinsey 在 2026 年 8 月发布的企业调查里发现，近九成受访者所在的组织已经在至少一个职能中经常使用 AI，44% 正在全企业范围扩展 AI。但在更具体的 Agent 层面，约两成组织正在规模化使用 AI Agent，coding agent 的比例也相近。大型企业明显走得更快：40% 正在至少一个职能中扩展 Agent，小型企业则是 22%。
换句话说，AI 的采用已经很广，Agent 作为日常工作入口的采用仍然更浅，而且高度不均衡。
这看起来像是对“新客户端”判断的反证。其实它更像一个常见的技术扩散顺序：人们先用新工具完成旧任务，然后才围绕新工具重新设计工作。
我们先让 AI 帮忙写一封邮件，再让它阅读文件、做研究、分析数据和画图。接下来，它才开始接入 GitHub、Vercel、Figma、Slack、数据库和内部系统，真正完成动作。
Anthropic 对 Claude 使用方式的观察已经捕捉到这个变化。一年前，大多数 session 还是用户和助手之间的对话；随着 Claude Code 和 Cowork 增长，越来越多 session 变成了长时间运行的 Agent 任务。
聊天没有突然消失。聊天正在变成行动的起点。
最适合 Agent 的系统，往往不是为 Agent 设计的
这听起来又是一个矛盾。
如果 Agent 是新的客户端，企业是不是应该赶紧做一个“Agent-native”版本？
我认为答案通常是否定的。
一个混乱的系统不会因为接上 Agent 就变得清晰。没有稳定的领域模型，没有明确的操作，没有权限边界，没有审计，也不能撤销高风险动作，Agent 只会更快地放大这些问题。
真正适合 Agent 的系统，首先应该在没有 Agent 时就能良好运行。
它的状态是明确的，操作是可组合的，权限是可约束的，错误是可解释的，结果是可验证的。Agent 不负责创造这些品质。Agent 只是通过一种新的通信方式使用它们。
这也是为什么我一直觉得 AWS 是一个好例子。
AWS 的网页控制台并不简单。但 AWS 从来没有把控制台当成唯一入口。它长期建立在 API、CLI、SDK、CloudFormation、IAM 和审计日志之上。基础设施可以用代码描述，操作可以复现，权限可以细分，调用可以追踪。
这些设计都早于今天的 Agent，却几乎完整地提供了 Agent 所需要的环境。
2026 年 5 月正式可用的 AWS MCP Server 可以让 Agent 调用 AWS API，同时继续受 IAM 约束，并通过 CloudWatch 和 CloudTrail 留下观测与审计记录。
AWS 并没有因为 Agent 获得新的云计算能力。它没有创造一个只有 Agent 才能完成的新动作。真正改变的是，Codex 或 Claude 现在可以成为使用 AWS 原有能力的客户端。
这揭示了 agent-ready 最反常识的一点：它不是在旧系统上贴一层 AI，而是把系统原本应该做好的基础工作做得足够好。
GUI 自动化是一座桥，不是终点
今天的 Agent 已经可以使用浏览器。它可以截图、识别按钮、填写表单、处理页面跳转。对于没有 API、没有 CLI、没有 MCP 的系统，这很重要。它让 Agent 能够先进入一个还没有为它准备好的世界。
但不应该把“能够操作”误认为“正确的操作方式”。
让 Agent 使用 GUI，相当于让它不断把结构化状态渲染成像素，再从像素里猜回结构化状态。每一步都增加延迟、成本和失败机会。页面稍微改版，原来的路径就可能失效。
这是不得不走的弯路，不是理想架构。
Operation as code 则保留了意图本来的形状。Agent 得到明确的操作、参数、权限和返回结果。失败可以定位，执行可以记录，动作可以重放。
GUI 自动化让 Agent 模仿人。
Operation as code 让 Agent 像机器一样工作。
这也是为什么，那些 API 完整、CLI 成熟、权限清楚、文档准确的老系统，可能比一些刚刚加上 AI 按钮的新产品更接近所谓的 Agent-native。
下一代软件会同时服务两种使用者
如果通用 Agent 真正成为一种客户端，那么好的软件最终会拥有两套互相配合的界面。
给人的界面负责展示、探索、解释、比较、确认和处理例外。
给 Agent 的界面负责提供稳定的 schema、语义化操作、明确错误、幂等写入、dry-run、撤销或补偿、最小权限、审计日志和高风险动作的人工确认。
Agent 负责接收意图、收集上下文、执行重复操作和跨系统协调。人负责看见证据、理解后果，并对重要决定承担责任。
有趣的是，在今天的 Plugin 架构里，UI 已经是可选的。一次后台状态查询可能完全不需要界面；只有当人需要检查、比较、编辑或确认时，工具才返回 UI。
这看似只是一个技术细节，却可能提前展示了界面的未来：界面不再包围每一次操作，只在人类判断真正有价值的地方出现。
用户第一次开始拥有自己的客户端
过去，一个 SaaS 产品决定用户怎样使用它。
产品设计导航、页面和流程。用户学习每个产品的语言，在不同标签页之间移动，把一个完整目标拆散在多个软件里完成。
通用 Agent 带来的是另一种权力关系。
用户开始拥有一个属于自己的客户端。它知道用户的目标、上下文和偏好，然后代表用户调用不同的服务。GitHub、Vercel、AWS、Figma 或其他产品，不再一定是用户旅程的起点。它们可能成为 Agent 背后被组合的能力。
未来，软件争夺的可能不只是首页、浏览器标签和用户停留时间。
它们还要争夺另一种位置：谁最容易被 Agent 正确发现，谁的操作定义最清楚，谁的权限模型最可信，谁的结果最容易验证，谁能在不打开网页的情况下可靠完成工作。
浏览器不会消失。IDE 也没有因为 coding agent 消失。
但它们在工作流中的位置会改变。
我们可能正在从“人操作很多软件”，走向“人操作一个通用 Agent，再由 Agent 操作很多软件”。
如果这个判断是对的，Agent 就不只是软件里的一个功能，也不只是另一个聊天窗口。
它是用户与整个软件世界之间，一种新的客户端。
资料来源
- Gallup：Organizational AI Adoption Jumps Six Points
- McKinsey：The State of AI 2026
- Anthropic Economic Index：Cadences
- Anthropic：Introducing the Model Context Protocol
- OpenAI Developers：Plugin architecture
- OpenAI Docs：Build skills
- OpenAI Docs：Site tools / WebMCP
- MCP Authorization Specification
- AWS：The AWS MCP Server is now generally available