feat(newChorme)
This commit is contained in:
smart
+33
-24
@@ -1,33 +1,42 @@
|
||||
# 模拟展示 4：团队落地清单
|
||||
# 任务流程说明：工具箱之外，还要操作手册
|
||||
|
||||
<div class="grid grid-cols-2 gap-8 mt-8">
|
||||
<div class="mt-8">
|
||||
|
||||
```mermaid {scale: 0.72}
|
||||
flowchart LR
|
||||
A[用户目标] --> B[识别任务类型]
|
||||
B --> C[读取流程说明]
|
||||
C --> D[打开必要页面]
|
||||
D --> E[调用工具]
|
||||
E --> F[关键动作交给用户确认]
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
<div class="grid grid-cols-2 gap-6 mt-7">
|
||||
|
||||
<div class="card-blue">
|
||||
<div class="font-semibold mb-2">WebMCP</div>
|
||||
<div class="text-sm op-70">解决“有哪些工具可以调用”。</div>
|
||||
</div>
|
||||
|
||||
<div class="card-green">
|
||||
<div class="font-semibold mb-3">本周可做</div>
|
||||
<div class="space-y-2 text-sm">
|
||||
|
||||
- 建一个 Chrome 更新跟踪文档
|
||||
- 选 1 个 DevTools 工作流做内部演示
|
||||
- 为 1 个新能力写最小 demo
|
||||
- 标注生产可用与仅实验的边界
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="card-red">
|
||||
<div class="font-semibold mb-3">不要直接做</div>
|
||||
<div class="space-y-2 text-sm">
|
||||
|
||||
- 只因 Chrome 支持就上线
|
||||
- 忽略 Safari / Firefox 用户
|
||||
- 把实验能力写进核心链路
|
||||
- 跳过权限与隐私评估
|
||||
|
||||
</div>
|
||||
<div class="font-semibold mb-2">任务流程说明</div>
|
||||
<div class="text-sm op-70">解决“复杂任务应该按什么流程走”。</div>
|
||||
</div>
|
||||
|
||||
</div>
|
||||
|
||||
<!--
|
||||
这一页把分享从“知道了”落到“接下来做什么”。建议最后留一个简单清单，让团队每月复盘一次 Chrome 更新，并把值得试验的能力进入工程 backlog。
|
||||
这一页讲任务流程说明。这里我会先特别说明：这不是 WebMCP 同级的官方浏览器概念，也不是一个标准 API 名称。它更像我们在应用实践里需要补上的流程层能力。
|
||||
|
||||
WebMCP 解决的是“有哪些工具可以调用”。但真实任务往往不是一个工具就能完成。比如用户说：“帮我申请价保。”这句话背后可能包含很多步骤：先去订单页查订单，确认订单是否符合规则，拿到订单号，再跳到价保页，填写申请信息，最后还要停下来让用户确认提交。
|
||||
|
||||
如果只给 Agent 一堆工具，它仍然可能不知道流程顺序。它可能先调了不该先调的工具，也可能过早提交，或者漏掉关键确认步骤。所以在应用实践里，我们通常还需要一层流程说明，可以叫 recipe、runbook、task flow，或者就叫操作手册。它的作用是告诉 Agent：遇到这类用户目标时，应该按什么顺序推进，每一步调用什么能力，哪一步必须停下来交给用户确认。
|
||||
|
||||
所以可以用一句话总结：WebMCP 是工具箱，任务流程说明是操作手册。工具箱让 Agent 有能力做事，操作手册让 Agent 知道怎样安全、稳定、按业务规则完成一件事。
|
||||
|
||||
这也是为什么未来前端不只要写 UI 组件，还要沉淀任务语义、页面能力和流程规则。我们写的不是随便贴给模型看的提示词，而是应用自身的可操作结构。这个结构越清晰，Agent 越不需要猜，风险也越容易被控制。
|
||||
|
||||
到这里，Agent 交互这条线就讲完了。接下来我们把视角拉宽，看 Chrome 这次还有哪些和开发工具、用户体验相关的新方向。
|
||||
-->
|
||||
|
||||
@@ -1,32 +1,52 @@
|
||||
# 模拟展示 2：DevTools 排查链路
|
||||
# WebMCP 的两种接入方式
|
||||
|
||||
<div class="mt-8">
|
||||
<div class="grid grid-cols-2 gap-6 mt-7">
|
||||
|
||||
```mermaid {scale: 0.82}
|
||||
flowchart LR
|
||||
A[用户反馈卡顿] --> B[Performance 录制]
|
||||
B --> C[定位长任务]
|
||||
C --> D[Network 查资源瀑布]
|
||||
D --> E[Coverage 查无效代码]
|
||||
E --> F[形成优化清单]
|
||||
<div class="card-blue">
|
||||
<div class="font-semibold mb-3">声明式：增强表单语义</div>
|
||||
|
||||
```html
|
||||
<form tool-description="提交酒店筛选条件">
|
||||
<input
|
||||
name="city"
|
||||
tool-parameter-description="目的地城市" />
|
||||
</form>
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
<div class="grid grid-cols-2 gap-6 mt-8">
|
||||
|
||||
<div class="card">
|
||||
<div class="font-semibold mb-2">演示素材</div>
|
||||
<div class="text-sm text-gray-400">准备一个加载慢、交互卡顿、资源偏大的页面作为示例。</div>
|
||||
<div class="text-xs op-65 mt-3">适合已有 HTML 表单和渐进增强。</div>
|
||||
</div>
|
||||
|
||||
<div class="card-green">
|
||||
<div class="font-semibold mb-2">观众收获</div>
|
||||
<div class="text-sm text-gray-400">把 DevTools 从“会打开”变成“按链路定位问题”。</div>
|
||||
<div class="font-semibold mb-3">命令式：注册业务工具</div>
|
||||
|
||||
```ts
|
||||
document.modelContext.registerTool({
|
||||
name: 'create_order_menu',
|
||||
description: '创建订单管理菜单',
|
||||
inputSchema,
|
||||
execute: createOrderMenu,
|
||||
})
|
||||
```
|
||||
|
||||
<div class="text-xs op-65 mt-3">适合复杂业务动作和后台系统。</div>
|
||||
</div>
|
||||
|
||||
</div>
|
||||
|
||||
<div class="mt-7 card-amber text-sm">
|
||||
WebMCP 仍属于实验性方向，实际接入要做能力检测、渐进增强和人工确认。
|
||||
</div>
|
||||
|
||||
<!--
|
||||
这一页用于现场演示细节。建议讲一个真实或模拟页面，从 Performance 开始抓主线程问题，再用 Network 和 Coverage 找资源问题，最后输出可执行的优化清单。
|
||||
这一页讲 WebMCP 怎么接入。
|
||||
|
||||
从公开资料和演示里可以看到，WebMCP 的接入大体可以分成两个方向。第一种是声明式接入，也就是在已有 HTML 表单上补充工具描述和参数描述。这样 Agent 不只是看到一个 input，而是知道这个 input 对应什么业务含义。例如这个字段不是普通文本框，而是“目的地城市”；这个表单不是普通表单，而是“提交酒店筛选条件”。
|
||||
|
||||
第二种是命令式接入，也就是通过 JavaScript 注册工具。工具里会包含 name、description、input schema 和 execute 函数。Agent 根据用户意图选择工具，传入结构化参数，然后页面执行我们已经定义好的业务逻辑。对复杂应用来说，这个方式更像是把现有业务函数安全地暴露给 Agent。
|
||||
|
||||
对高级前端来说，这个区别很关键。声明式方式适合增强已有表单，成本低，和语义化 HTML 的方向一致；命令式方式适合后台系统、复杂流程、跨页面业务，因为它可以复用已有的 service、store、接口封装和权限判断。也就是说，我们不一定要重写一套 AI 专用逻辑，而是把原有能力以更清晰的 schema 暴露出来。
|
||||
|
||||
但这里一定要提醒大家：WebMCP 仍然是实验性和快速演进中的方向，不能把它当成所有浏览器都稳定支持的能力。真正落地时，第一要做 feature detection，也就是先判断环境是否支持；第二要做渐进增强，不支持时仍然回到正常 UI 流程；第三，高风险动作必须有人类确认，不能让 Agent 自动越过权限、审计和确认边界。
|
||||
|
||||
讲到这里，我们已经有工具了。但真实任务往往不是一个工具就能完成，所以下一页要补一个实践层问题：复杂任务需要流程说明。
|
||||
-->
|
||||
|
||||
+27
-17
@@ -1,38 +1,48 @@
|
||||
# 模拟展示 3：Web 平台能力评估卡
|
||||
# WebMCP：网页给 Agent 的工具说明书
|
||||
|
||||
<div class="grid grid-cols-2 gap-8 mt-8">
|
||||
|
||||
<div class="card-blue">
|
||||
<div class="font-semibold mb-3">能力示例</div>
|
||||
<div class="font-semibold mb-3">一个工具通常描述什么？</div>
|
||||
<div class="space-y-2 text-sm">
|
||||
|
||||
- CSS 新布局与交互能力
|
||||
- View Transitions
|
||||
- File System / Clipboard / Share APIs
|
||||
- PWA 安装与离线体验
|
||||
- 本地 AI 与浏览器内置能力探索
|
||||
- 名字：工具叫什么
|
||||
- 描述：什么时候应该调用
|
||||
- 参数：需要哪些输入
|
||||
- 执行：调用后做什么业务逻辑
|
||||
- 返回：成功、失败和结果信息
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="card">
|
||||
<div class="font-semibold mb-3">评估维度</div>
|
||||
<div class="space-y-2 text-sm text-gray-300">
|
||||
<div class="card-green">
|
||||
<div class="font-semibold mb-3">它改变了什么？</div>
|
||||
<div class="space-y-2 text-sm">
|
||||
|
||||
- 用户价值：解决什么真实问题？
|
||||
- 兼容性：Chrome-only 还是跨浏览器？
|
||||
- 降级方案：不可用时如何处理？
|
||||
- 风险：权限、隐私、性能、安全
|
||||
- UI 改版不等于能力失效
|
||||
- Agent 不再猜按钮位置
|
||||
- 业务边界由开发者定义
|
||||
- 权限、确认、审计可以前置设计
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
</div>
|
||||
|
||||
<div class="mt-8 card-amber text-sm">
|
||||
推荐输出格式：能力名称 / Chrome 支持状态 / 业务场景 / Demo 链接 / 风险 / 下一步。
|
||||
<div class="mt-8 text-2xl font-bold">
|
||||
从“AI 操作页面”升级为“页面向 AI 暴露能力”。
|
||||
</div>
|
||||
|
||||
<!--
|
||||
这里可以把每个新 API 都变成一张评估卡。不要只问“能不能用”，而是问“能解决什么问题、什么时候可上线、不能用时怎么降级”。
|
||||
这一页解释 WebMCP 的核心概念。
|
||||
|
||||
最简单的理解方式是：WebMCP 是网页给 AI Agent 的工具说明书。过去网页把最终渲染出来的 UI 给用户看，Agent 如果要操作，只能从这个 UI 反推背后的意图。WebMCP 的方向则是反过来：网页主动告诉 Agent，我有哪些可调用能力，每个能力叫什么，适合什么时候用，需要什么参数，执行后会返回什么结果。
|
||||
|
||||
举几个例子会更好理解。一个电商页面可以暴露 add_to_cart 工具，参数是商品 ID、尺码和数量；一个后台系统可以暴露 create_menu 工具，参数是菜单名称、父级菜单、路由和权限标识；一个文档应用可以暴露 summarize_selection 工具，参数是当前选区和摘要长度。Agent 不需要猜按钮在哪里，它只需要判断用户意图和哪个工具匹配。
|
||||
|
||||
这对前端开发者很重要。因为以前我们经常担心 AI 乱点页面：点错按钮、误删数据、跳过校验。但如果能力是我们主动暴露出去的，业务边界就能回到开发者手里。哪些动作可以给 Agent 调，哪些动作必须用户确认，哪些动作需要审计，哪些工具只在特定页面或特定权限下出现，这些都可以在设计阶段明确。
|
||||
|
||||
所以 WebMCP 不是“让 AI 更会点按钮”。它真正代表的是一个更大的变化：网页从 UI 自动化，走向能力自动化。Agent 不再只是模仿人点页面，而是通过结构化工具参与业务流程。
|
||||
|
||||
下一页我们看它大概怎么接入：一种偏声明式，一种偏命令式。
|
||||
-->
|
||||
|
||||
+38
-33
@@ -1,44 +1,49 @@
|
||||
# 模拟展示 1：快速扫一版 Chrome 更新
|
||||
# 同一个任务，三种完成方式
|
||||
|
||||
<div class="grid grid-cols-3 gap-5 mt-8">
|
||||
<div class="grid grid-cols-3 gap-5 mt-7">
|
||||
|
||||
<div class="card-blue">
|
||||
<div class="font-semibold mb-3">信息源</div>
|
||||
<div class="space-y-2 text-sm">
|
||||
|
||||
- Chrome Developers Blog
|
||||
- ChromeStatus
|
||||
- DevTools Release Notes
|
||||
- MDN Baseline
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="card-green">
|
||||
<div class="font-semibold mb-3">筛选标准</div>
|
||||
<div class="space-y-2 text-sm">
|
||||
|
||||
- 是否默认启用
|
||||
- 是否跨浏览器可用
|
||||
- 是否影响现有代码
|
||||
- 是否带来明显产品收益
|
||||
|
||||
</div>
|
||||
<div class="card">
|
||||
<div class="text-sm font-semibold text-blue-500 mb-2">方式 1</div>
|
||||
<div class="text-xl font-bold mb-2">看截图</div>
|
||||
<div class="text-sm op-70">逐屏识别、逐步点击、逐项填表。</div>
|
||||
<div class="mt-5 text-3xl font-bold">分钟级</div>
|
||||
<div class="text-xs op-60 mt-1">案例中 token 可到几十万级</div>
|
||||
</div>
|
||||
|
||||
<div class="card-amber">
|
||||
<div class="font-semibold mb-3">输出物</div>
|
||||
<div class="space-y-2 text-sm">
|
||||
|
||||
- 3 个可试验能力
|
||||
- 2 个需要关注的变更
|
||||
- 1 个团队落地建议
|
||||
|
||||
</div>
|
||||
<div class="text-sm font-semibold text-amber-500 mb-2">方式 2</div>
|
||||
<div class="text-xl font-bold mb-2">读结构</div>
|
||||
<div class="text-sm op-70">读取 DOM / 可访问性树，再定位控件。</div>
|
||||
<div class="mt-5 text-3xl font-bold">更快但脆</div>
|
||||
<div class="text-xs op-60 mt-1">复杂交互下仍可能点错或漏选</div>
|
||||
</div>
|
||||
|
||||
<div class="card-green">
|
||||
<div class="text-sm font-semibold text-emerald-500 mb-2">方式 3</div>
|
||||
<div class="text-xl font-bold mb-2">调工具</div>
|
||||
<div class="text-sm op-70">调用页面暴露的业务工具。</div>
|
||||
<div class="mt-5 text-3xl font-bold">秒级</div>
|
||||
<div class="text-xs op-60 mt-1">案例中约 30-40 秒、约 1.7 万 token</div>
|
||||
</div>
|
||||
|
||||
</div>
|
||||
|
||||
<div class="mt-7 card-blue text-sm">
|
||||
案例任务：后台系统内完成“创建订单管理模块”，包括词条、菜单、角色权限绑定。数据来自仓库原始实战材料，作为特定案例结果，不代表所有场景通用值。
|
||||
</div>
|
||||
|
||||
<!--
|
||||
这一页可以模拟现场打开 release notes。重点不是最新版本号，而是演示方法：先看默认启用与兼容性，再看是否影响我们现有业务，最后只挑少数真正需要行动的条目。
|
||||
这一页用一个具体任务，把刚才三类方案的差异讲得更直观一些。
|
||||
|
||||
我们假设有一个后台管理系统，任务是创建一个“订单管理模块”。听起来很简单，但拆开看其实有好几步：先创建词条，再创建菜单，再把菜单绑定到角色权限里。对熟悉系统的人来说，这可能就是几分钟的常规操作；但对 AI 来说，这里面包含多个页面、多个表单、树形结构、权限勾选、搜索和确认动作。
|
||||
|
||||
如果用视觉识别，AI 需要一屏一屏截图。它要先看到菜单在哪里，再判断哪个是新增按钮，再识别表单字段，再填值，再点提交。这个过程有点像让一个人隔着截图远程操作电脑，能做，但非常绕。仓库里的实战材料里，这类方案可以完成任务，但过程是分钟级，token 消耗可以到几十万级。
|
||||
|
||||
如果用 DOM 或可访问性树识别，它会更快一点，因为它不只是看图，而是读结构。但这并不等于稳定。复杂组件里有很多状态，页面结构也会随着权限和交互变化。实战材料里就提到过，结构识别方案在复杂菜单和权限操作里，仍然可能点错、漏选，甚至把不该删的东西删掉。
|
||||
|
||||
如果用 WebMCP 思路，页面直接暴露“创建词条”“创建菜单”“绑定角色权限”这些工具。AI 不需要知道按钮在左边还是右边，不需要知道菜单有没有展开，它只需要根据用户目标选择正确的工具，传入参数，然后拿到执行结果。实战材料里，同类任务可以压到几十秒，token 也会明显下降。
|
||||
|
||||
这里我要特别说明一下：页面上的数字不是行业通用基准，也不是说所有场景都会有完全相同的提升。它只是一个具体案例。但它说明了一个趋势：越复杂、越业务化、越高风险的系统，越不应该让 AI 在界面里猜；我们越应该把能力封装好，让 Agent 调用明确的能力。
|
||||
|
||||
接下来，我们就进入核心概念：WebMCP 到底是什么。
|
||||
-->
|
||||
|
||||
Reference in New Issue
Block a user