WebMCP能否让AI完全接管编程工作

一、问题被重新提出：AI离“完全接管编程”还有多远

“AI 能不能100%正式接管所有编程工作？”这个问题每隔一段时间就会被重新讨论。每当模型能力提升、上下文窗口扩大、工具调用变得更稳定，就会有人判断编程工作即将被彻底自动化。

但从工程角度看，编程并不只是“生成代码”。它至少包括需求澄清、架构设计、编码实现、测试验证、部署运维、问题排查与持续迭代。即使模型在代码生成上表现很强，真正困难的往往是“让AI可靠地操作真实环境”。浏览器作为最常见的前端运行环境，一直是智能体落地的关键场景。

过去，AI 操作网页通常依赖 DOM 解析、可访问性树或连续截图，再配合启发式规则猜测可点击元素。这种方式不仅慢，而且脆弱。页面一旦由大量脚本动态渲染，DOM 结构频繁变化，AI 就容易在错误的位置执行错误操作。

因此，一个更值得关注的问题不是“模型能不能写代码”，而是“网页本身是否愿意、并且能够向AI提供稳定、明确、可调用的操作接口”。如果这个能力补上，AI与浏览器的交互将从“猜测”变成“调用”，很多低效环节会被压缩。

二、页面为AI提供“结构化操作入口”是核心变化

传统的智能体操作浏览器，流程大致如下：

1. 获取页面源码或截图；
2. 从中识别目标元素；
3. 推断可执行动作；
4. 触发点击、输入、滚动、提交等事件；
5. 再次读取页面状态，判断动作是否成功。

这个链路的问题在于每一步都可能产生误差。尤其是当页面由大量 JavaScript 动态渲染时，初始 HTML 中并不包含最终可见的内容，AI需要等待、轮询、截图、比对，消耗大量 token 和时间。

新的思路则更加直接：由页面自身声明它能够被AI执行的操作。页面开发者可以在脚本中注册能力，例如“添加待办事项”“提交表单”“切换主题”“获取当前列表”，每个能力都带名称、描述、参数模式和执行函数。

这样，AI 不需要理解页面布局，不需要猜测按钮位置，只需要读取可用能力列表，按照参数模式调用即可。页面的内部实现细节被封装起来，AI 面对的是一个类似 API 的结构化界面。

这种变化类似从“通过键盘鼠标操作图形界面”转向“直接调用服务接口”。前者灵活但不可靠，后者稳定但需要提前设计。对于高频业务操作，提前设计显然是值得的。

三、该机制如何工作：一次注册，持续调用

虽然当前相关能力仍处于早期阶段，但通用模式已经比较清晰。页面可以在脚本中注册工具，指定工具的名称、说明、输入结构和执行逻辑。

一个简化但完整的示意如下：

await document.modelContext.registerTool({
  name: "add_todo",
  description: "在当前页面的待办事项列表中添加一个新项目。",
  inputSchema: {
    type: "object",
    properties: {
      text: {
        type: "string",
        description: "待办事项的条目内容"
      }
    },
    required: ["text"]
  },
  execute: async ({ text }) => {
    addTodoToPage(text);
    return {
      success: true,
      message: `已经添加待办事项：${text}`
    };
  }
});

这个示例说明了几个关键点。

第一，工具名称是明确的。AI 可以通过名称快速识别功能，而不需要从按钮文案、图标或 DOM 属性中推断。

第二，描述是面向AI的。好的描述能显著提高模型选择工具的正确率，相当于给模型提供了一组清晰的操作文档。

第三，输入模式是结构化的。AI 必须传入符合 schema 的参数，这减少了非法输入和误操作。

第四，执行结果是可反馈的。网页在完成动作后返回成功状态与消息，AI 可以据此判断下一步动作，而不是继续截图比对。

四、相比传统方式的优势：确定性、成本与可维护性

这种机制的最大优势是确定性。在传统方式下，同一个操作可能因为页面加载顺序、异步渲染、弹窗出现、A/B 测试布局不同而失败。而结构化的工具注册方式将操作语义从页面表现中解耦出来，AI 调用的是语义，而不是视觉位置。

第二个优势是成本。截图与整页 DOM 读取都需要大量 token，尤其是长页面或复杂应用。结构化工具调用则只需要很少的参数和返回值，上下文更干净，决策速度更快。

第三个优势是可维护性。前端开发者可以为关键业务流程主动暴露工具，并根据业务变化更新 schema 和说明。AI 不需要重新学习页面结构，只要工具契约保持稳定，调用逻辑就不需要改变。

第四个优势是安全边界更清晰。页面可以提供部分可控操作，而不是允许AI自由点击所有按钮。这样，某些危险操作可以被排除在工具列表之外，降低误操作风险。

五、为什么还不能说“100%接管所有编程工作”

尽管结构化工具调用显著提升了AI操作网页的能力，但它不能直接等同于“接管全部编程工作”。

首先，这种能力依赖页面开发者主动注册工具。如果页面没有提供任何工具，AI仍然需要回到DOM解析、截图、猜测的老路。也就是说，它的普及程度取决于生态演化，而不是模型单方面的能力。

其次，注册什么工具、暴露多少能力，本身就是一个设计问题。这需要开发者理解业务场景、预判AI可能需要的操作，并维护接口契约。换句话说，开发工作并没有消失，而是转移到了“为AI设计可调用接口”上。

第三，复杂任务通常涉及跨页面、跨系统、跨权限的流程。例如，AI需要在多个页面间切换、登录、处理验证、处理异常分支。单页工具解决不了这些问题，需要配合状态管理、权限控制、流程编排和审计机制。

第四，编程工作中大量内容发生在浏览器之外。后端服务、数据库设计、算法优化、性能调优、安全加固、需求沟通等，并不会因为前端工具调用变得简单。AI 在这些领域的能力边界仍然存在。

因此，更准确的判断是：当页面能够稳定暴露结构化操作接口时，AI 操作前端环境的可靠性会大幅提升，一部分重复性、规则明确的浏览器任务可以被高度自动化。但这距离“100%正式接管所有编程工作”还有明显距离。

六、对开发者的实际影响：新技能而不是失业信号

对前端开发者而言，这类变化更像是一种新技能要求，而不是简单的替代。

过去，前端开发者主要关注用户如何与页面交互。现在，还需要考虑智能体如何与页面交互。两者并不冲突。用户需要按钮、表单、动画和反馈，智能体则需要工具名称、参数模式、描述和执行结果。

一个设计良好的页面，可以同时为两者提供友好界面。用户看到的是图形界面，AI 看到的是结构化工具。前端开发者的价值在于设计出清晰、稳定、安全的工具契约，并确保业务逻辑正确执行。

如果团队中还没有人关注这类能力，那么现在可以开始了解其基本概念。即使当前浏览器支持度有限，早期理解其设计思想，也有助于后续在业务系统中提前规划。

七、结语：编程工作会被重新组织，而不是瞬间消失

回到最初的问题：AI 能否100%正式接管所有编程工作？

答案仍然是否定的。一个更准确的描述是，AI 正在改变编程工作的组织方式。它让某些环节从手工操作变成接口调用，让某些重复劳动从人工执行变成自动执行，但也产生了新的工作内容，例如设计工具契约、维护页面能力、管理系统权限、审计智能体行为。

真正值得关注的不是“能否100%接管”，而是“当关键交互从猜测变为调用后，开发流程会如何重构”。对于开发者来说，理解这种变化，并在合适场景中主动应用，远比焦虑被替代更有价值。