VS Code 1.127 让 Agent 接管浏览器：一个被忽视的产品信号

星核0penstarry

322人浏览 · 2026-07-03 12:08:07

星核0penstarry · 2026-07-03 12:08:07 发布

最近 VS Code 1.127 发布，我盯着更新日志看了很久。

不是因为新增了什么炫酷功能，而是因为一个细节：Agent 现在可以打开网页、截图、点击元素，然后验证自己的工作成果。

这件事看起来像是一个 IDE 的小升级。但如果你把过去半年的几个信号连起来看——Claude 的 Computer Use、OpenAI 的 Operator、Manus 的 Agent 产品化——就会发现一件更值得讨论的事：

AI Agent 正在从"对话伙伴"变成"数字员工"。

而这个转变，对底层基础设施提出了全新的要求。

一、趋势判断：Agent 的"执行鸿沟"正在被填平
过去两年，行业对 AI Agent 的讨论主要集中在两个层面：

能力层：模型能做什么（推理、规划、写代码）
交互层：人和 Agent 怎么沟通（Chat、Copilot、Autocomplete）
但 2026 年开始，第三个层面开始变得关键：执行层——Agent 怎么真正动手把事情做完。

VS Code 1.127 的 Browser Tools for Agents 就是一个典型的执行层突破：

让 Agent 能直接打开浏览器
能截图（视觉反馈）
能点击、填写、跳转
用 Per-site 权限管理摄像头、位置等敏感资源
这意味着 Agent 不再只是"建议你写一段代码"，而是真的能帮你测试、部署、调试。

我们看一下数据：截至 2026 年 Q1，GitHub Copilot Workspace 的 Agent 模式已经有超过 40% 的付费用户开启；而 Cursor、Continue.dev 等工具的 Agent 调用占比，从 2025 年 Q4 的 12% 飙升至 2026 年 Q1 的 58%。

这不是渐进式升级，是范式转移。

二、技术决策点：Agent 调度多模型时，隐藏的复杂度
当 Agent 从"对话"升级到"执行"，一个被严重低估的技术问题浮出水面：

单个 Agent 在一次任务里，可能需要切换多个模型。

举个例子，一个典型的"构建并测试 Web 应用"流程：

规划阶段：调用 Claude Opus 4.7 做任务拆解
编码阶段：调用 GLM-5.2 或 Qwen3.6-Plus 生成代码
浏览器测试阶段：调用 Kimi K2.6（视觉理解、长上下文）
报错修复阶段：调用 DeepSeek-V4-Flash（成本低、速度快）
这背后至少需要 4 次模型切换。

如果每个模型都自己接一遍，你要面对的是：

4 套 API Key 的管理（不同的环境变量、不同的密钥轮换策略）
4 套接口规范的适配（OpenAI 兼容、Anthropic 原生、Google Gemini 三套协议差异不小）
4 套账单（DeepSeek 人民币、OpenAI 美元、Claude 按 token 计费、Kimi 按次计费）
4 套故障排查路径（到底是哪个模型超时了？哪个 Key 过期了？）
我们看一段典型的"裸接"代码：

维护 4 家模型，每个都要单独配置

import os
from openai import OpenAI
import anthropic
import google.generativeai as genai

OpenAI

openai_client = OpenAI(api_key=os.getenv(“OPENAI_KEY”))

Anthropic

claude_client = anthropic.Anthropic(api_key=os.getenv(“ANTHROPIC_KEY”))

Google

genai.configure(api_key=os.getenv(“GOOGLE_KEY”))

自建代理转发 Kimi / DeepSeek / GLM

kimi_client = OpenAI(
api_key=os.getenv(“KIMI_KEY”),
base_url=“https://api.moonshot.cn/v1”
)

…调用时还要处理不同的请求格式、不同的限流码、不同的重试策略…

这段代码的问题不在于"难写"，而在于每一次新增模型或更换供应商，都是一次重写。

而 Agent 的特点是：它需要根据任务动态选择模型。硬编码 4 套调用路径，等于把 Agent 的灵活性锁死。

一个更合理的做法，是把模型访问层抽象出来：

from openai import OpenAI

client = OpenAI(
api_key=“你的统一 Key”,
base_url=“https://api.openstarry.com/v1”
)

切换模型只改一个参数

response = client.chat.completions.create(
model=“glm-5-2”, # 想换 Kimi？改成 kimi-k2-6 就行
messages=[{“role”: “user”, “content”: “帮我规划这个任务”}]
)
改动量：2 行（base_url + api_key），其余业务代码零改动。

这是 Agent 时代的基础设施要求：模型不应该是一个个孤岛，而应该是一个可调度的资源池。

三、客户场景：当 Agent 真的在干活，模型宕机就是事故
讲一个脱敏的真实案例。

一家做电商自动化的 SaaS 团队，2025 年底上线了一套 Agent 流程：用户提交商品链接，Agent 自动抓取页面、生成营销文案、调用图像模型生成海报、最终推送到客户的店铺后台。

上线第一个月，团队只接了一家模型（GLM-5.2），跑得挺顺。

第二个月，流量起来后，问题开始暴露：

“某周二下午 3 点，GLM 那边突然限流，我们 30% 的请求直接超时。用户那边看到的就是’生成失败’，投诉电话被打爆。”

— 该团队后端负责人复盘时的原话

他们后来做的补救是：接了两家备用模型，写了简单的重试逻辑。

但又遇到新问题：

“重试逻辑写得太简单，遇到 Anthropic 接口返回的 429 限流码，我们没处理，直接挂了。后来干脆在网关层做了 Failover，才稳定下来。”

这是一个很典型的"Agent 进入生产环境"才会遇到的问题。

当 Agent 只是玩具，模型宕机最多让你重新生成一次。当 Agent 是生产力工具，模型宕机就是业务事故。