스크립트
00:00:00大家好，你们好。今天我们要聊聊智能体网络（Agentic Web），
00:00:19具体来说就是它的含义，以及我们如何让网络做好迎接智能体的准备。先申明一点，我这份
00:00:26演示文稿是昨天制作的，可能有些过时，因为这个领域的变革速度实在太快了。
00:00:32我想我需要先做个自我介绍，方便大家了解背景。我是 MCP Apps 这一规范的
00:00:38联合创建者兼维护者。MCP Apps 是 ChatGPT Apps、
00:00:45Claude Apps、Copilot 和 GitHub 等应用背后的底层规范。大家看到的每个基于对话的应用
00:00:53都基于 MCP 委员会制定的 MCP Apps 规范。我也是 Aura 公司的
00:00:58联合创始人，我们在那里研究智能体与人类的交互。此外，我还在 Shopify 构建并主持了智能体店铺项目。因此，
00:01:06智能体网络这个主题对我来说非常亲切。如果你对 MCP Apps 还不熟悉，
00:01:12我先稍作介绍。MCP Apps 实际上是为智能体网络铺平道路的规范。MCP Apps
00:01:18作为一项规范和标准于几个月前发布，最早由 Claude 作为首个客户端提供支持，
00:01:25随后所有客户端都相继跟进。如果你使用过任何基于对话的应用，并从 MCP 服务器提取过
00:01:32可视化与交互 UI 层，那么你很可能就已经使用过 MCP Apps 了。
00:01:39MCP Apps 的妙处在于能实现多方共赢。因为只要服务器或服务商能够
00:01:48将 UI 模块发送到对话中，这些应用就能展现其品牌和特色。它们得以保留自己的 UI，
00:01:58而不必沦为单纯的数据库或纯文本信息。用户也能获得信任感和
00:02:04熟悉感。因为如果你让 ChatGPT“帮你订几间酒店”，然后看到了 Booking.com 的界面，
00:02:09你就知道这是 Booking.com，对吧？你清楚自己在和谁交互。而主机或对话平台
00:02:16则获得了通往广阔功能世界的大门。大家知道，几个月前有人曾问：为什么
00:02:22OpenAI 不干脆从零搭建一切呢？但 OpenAI 不可能亲自去跟各大酒店谈判，也不可能去服务
00:02:29那些想要在场馆中更换座位的用户。我们需要这些具体的服务。而 MCP Apps 恰好解决了
00:02:35这最后一步的交互需求。
00:02:41是的，这就是我们获得的益处。MCP Apps 解决了我们最后一步的交互，对吧？那么
00:02:51“最后一步”意味着什么呢？意思是随着智能体和模型变得越来越强大，它们能更独立地完成任务。
00:02:57但作为人类，我们依然处于链路的末端。我们仍然需要能够
00:03:05挑选酒店、查看 3D 模型或在场馆中选择座位。所有这些最后一步的
00:03:12交互，形式都可以改变。这里有一个来自……抱歉。是的，这是来自
00:03:20Claude 上关于 MCP Apps 的 PR 示例。这就是它的形态，对吧？当你将应用嵌入到对话中时，
00:03:28你能在同一个对话上下文中，体验到统一的 UI 呈现。正如你所见，
00:03:36在同一个会话中，你可以获取 Booking 的数据，可以获取 AllTrails 的数据，还可以获取
00:03:41任何你想交互的服务的数据，对吧？这一切已经在发生了。MCP Apps 已经获得了
00:03:49几乎所有对话智能体的广泛支持，除了 Gemini，不过它也即将接入。这一切正在成为现实。而
00:03:57有趣的是，它把我们引向了所谓“智能体网络”的概念。那么，什么是
00:04:05智能体网络？智能体网络并不是单纯由智能体构成的网络，也不是我们今天所熟知的 Web。它是一种演进，一种变革。它改变了
00:04:11我们看待网站和浏览器的方式。因为在此之前，我们花了
00:04:2120 年、整整二十载来打磨这种体验。这意味着如果我想推进某个项目、
00:04:29完成某项任务，或者筹划周年纪念，我就必须在浏览器中打开多个标签页，逐个浏览，
00:04:36并用不同的方式向其中的各项服务表达我的意图，对吧？这意味着如果我只是想
00:04:43策划一次周年纪念，我就得去学习谷歌的 UI、亚马逊的 UI、Booking 的 UI 以及其他
00:04:51预订平台和电商平台的 UI。做这一切仅仅是为了向这些界面传达同一个意图。每家
00:04:58公司都将这种用户流程打磨得极为完善。但我们不再需要这样做了，对吧？我们完全可以把这些
00:05:04界面拆解成最小原子。因为我根本不需要 Booking 控制面板中 99% 的功能，也不需要
00:05:12Airbnb 控制面板中 99% 的东西，更不需要 Jira 的控制面板。我只是想向
00:05:19这些服务表达意图而已。那我为什么不让我的个人助手来处理呢？如果我拥有一个个人助手，
00:05:27我只需要提取这些功能原子，由它来进行组合。它会说：“是的，我注意到你的
00:05:31周年纪念日快到了。这是来自谷歌日历的视图，显示纪念日即将到来。
00:05:36所以我可以帮你采购物品，帮你预订酒店。”现在 Claude 很了解我，它知道
00:05:43我更倾向于预订亲近大自然的酒店，对吧？所以它知道自动调出 Booking 的地图。我根本不需要
00:05:49去费心思考。而 Booking、亚马逊和谷歌也能从中获益，因为它们获得了这个无需自己开发的
00:05:56集成层。毕竟 Claude 掌握了我的上下文信息，对吧？这样 Booking 就不必
00:06:01专门开发与我日历的集成，亚马逊也不需要开发与 Booking 的集成。
00:06:06因此这是一个三赢的局面。这正是我们所追求的远景。这与
00:06:13目前的发展方向截然不同——目前的做法基本上就是打开各种不同的服务，
00:06:21仅仅为了盯着那些询问你想做什么的文本输入框。但没有人会愿意那么做。
00:06:27一年之内，绝对不会有人再去专门访问亚马逊的智能体、Etsy 的智能体或是 Expedia 的智能体。我
00:06:34不想那样。我有我自己的个人助手。我不想用你的智能体，我想用我自己的。
00:06:41明白吗？现在如果我们深入思考一下，这意味着网站作为单一事实来源（Source of Truth）的时代
00:06:49即将终结。因为为什么还需要传统的网站？为什么还要去打开标签页？为什么
00:06:55还要去阅读网站费尽心思想要传达给我的那些信息？
00:06:59对此最直接的反驳往往是：“可是我们有浏览器智能体，有计算机操作智能体（Computer Use Agents），
00:07:04有非常聪明的智能体或助手可以帮我们浏览网页。”但这逻辑上说不通。
00:07:10因为这不过是“造一匹更快跑马”的方案。为什么要让一个对人类感知局限
00:07:17一无所知（也不受其限制）的智能体，去操作那些我们花了数十年专门为人类打磨的筛选、分页、排序等 UI，
00:07:24仅仅是为了让它完成任务？因此谷歌非常看好
00:07:33光谱的另一端，也就是协同浏览（Co-browsing）和网站端技术。他们提出了一个名为
00:07:37WebMCP 的协议或标准。WebMCP 的主张是：与其让智能体对网站截图并
00:07:44试图去理解网页内容，不如直接让网站在内部暴露一些 JS 工具，
00:07:49供智能体调用。你可以在这里看到 Chrome 中 Gemini 的示例，在我浏览网页时，
00:07:55在浏览网页时替我购物或寻找优惠，这固然很棒，但也非常简单。
00:08:02如果我们将 Salesforce 的仪表盘推给 Chrome 上的 Gemini，会发生什么？我为什么会想要那样？为什么
00:08:09我要带着 Gemini 去浏览 Salesforce 的控制面板，在一个我甚至根本不想
00:08:15使用的控制面板里帮我点击按钮？这绝对不是我们想要的。而核心变革在于，
00:08:24智能助手正在成为我们进入网络世界的新入口，对吧？我们随处可见这种趋势。每一个头部实验室都希望自己的应用能成为“万能应用”（Everything App）。
00:08:31这种转变正在发生。我有些朋友把 Jira 的 MCP 连接到了自己的 IDE 上，他们就再也不去
00:08:39访问 Jira 的网站了，对吧？我母亲做任何事都会用 ChatGPT。如果她能用 ChatGPT 预约
00:08:44医生，她绝不会再去访问诊所的官方网站。此外还有极大一部分
00:08:49长尾网站将再也没有人去亲自查看，因为通过我的个人助手直接连接它们要方便得多。
00:08:54因此，传统网站将变得过时，浏览器将变得过时，而个人
00:08:59助手将成为我们连接网络世界的唯一大门。我知道这听起来像什么。听起来像个老头子
00:09:04在对天上的云彩凭空发怒（杞人忧天），对吧？我的意思是，是的，它们不会完全消失，
00:09:11但我们在如今的年轻一代身上已经看到了这种变化。我九岁的孩子会直接用 ChatGPT。当他想查东西时，他不会去
00:09:17当他想搜索东西时不会去用 Google。我之前去东欧的国家格鲁吉亚旅行，
00:09:24那里有一位大约 70 岁的老太太让我帮她拍照。在她的
00:09:28手机里，一共就只有三个应用：WhatsApp、相机和 ChatGPT。仅此而已。这种转变正在发生。许多
00:09:36非常聪明的人，比如 Sentry 的 David Cramer，在一年前曾表示：“我愿意和任何认为
00:09:44网站将在 25 年内淘汰的人下赌注。”那是发表在一年前。而就在几天前，David
00:09:49Cramer 发表了《为智能体设计》（Designing for Agents），其中提到：我们必须意识到，用户与 Sentry
00:09:54产品的交互将不再仅仅通过我们的 Web 应用程序。我们必须将 API 优先作为核心交互界面
00:10:00来进行设计。因此，一切都在转向“无头化”（Headless）。Salesforce 最近转向了无头架构，这非常
00:10:06重要，因为 Salesforce 相比竞争对手的核心优势就在于其 UX。在于它
00:10:12向用户呈现一切的方式。但它也走向了无头化。Cloudflare 转向了无头化，Sentry 也转向了无头化。
00:10:17这是 Cloudflare CEO 发的一条推文，称网络上的智能体流量已经超过了人类流量。我们
00:10:25拥有这种多层级的交互光谱：如果我的智能体是完全自主的，我就不需要这最后一步的 UI，
00:10:30对吧？如果我用 OpenClaw，只需发出指令说：“帮我整理邮件。”它处理完返回
00:10:35告诉我：“搞定了，很好。”但如果我想为蜜月预订酒店，我大概率还是需要这最后一步的
00:10:40交互。所以我们称之为“准无头网络”（Nearly Headless Web），对吧？它并非完全无头。智能体会
00:10:47以无头模式与你的网站交互，但随后它会为你拉取并呈现这些 UI 资源。
00:10:55因此，我们所熟知的用户体验（UX）正在一分为二。现在它包含了网站的智能体体验（Agent Experience），以及
00:11:02用户在使用那个操控你网站的智能体时的体验。但 90% 的体验将依赖于智能体体验，
00:11:09这意味着你的网站需要做好全方位的“智能体就绪”（Agent Ready）准备。它需要为
00:11:16你自己的智能体做好准备。如果我是 Booking，我需要让预订业务适配 Booking 的智能体；我需要
00:11:21让它适配客户的 ChatGPT 或 OpenClaw。我还需要为那些没有智能体、
00:11:28但也有些人类客户没有智能体，但仍然想浏览 Booking.com，对吧？所以网站需要
00:11:33对智能体友好。而我们发现，“智能体就绪”包含很多层面。我们听过很多关于
00:11:39AEO、SEO、GEO 以及如何被发现的讨论。但被发现只是第一步。因为一旦智能体知道了你，
00:11:47了解你，它还需要知道你是什么、如何与你交互，以及如何向你
00:11:51进行身份验证和无头支付，对吧？其实，当我们构建——这算是个趣事——但当我们
00:11:56为产品构建分析功能时，我们问 Claude Code 最好的分析服务是什么。它
00:12:02推荐了分析服务 PostHog。但我们说：不，我们更喜欢 Mixpanel。因为我们了解
00:12:07Mixpanel。我们用它十年了，知道怎么用。但 Claude Code 坚持要用
00:12:11PostHog。因为他说，PostHog 有更好的 MCP 和 API，集成效果更好。所以我们
00:12:17并没有品牌忠诚度，对吧？既然 Claude Code 推荐，我们就用了 PostHog。但这也
00:12:21引发了我们对 Mixpanel 的思考。Mixpanel 花了十年完善用户体验和开发者体验，
00:12:26仅仅因为 Claude Code 更偏好 PostHog，我们就放弃了它。这种情况随时都在发生。比如 Hermes，
00:12:31如果它在使用你的产品时需要启动无头浏览器，它会记住这一点。下一次
00:12:35它就不会再用你的产品了，对吧？所以在智能体 Web 研究实验室 Aura，
00:12:43我们开始展开研究。我们筹集了一些资金，开始研究
00:12:49Web 如何才能为智能体做好准备。我们建立了这些就绪度基准，非常有趣。
00:12:57你可以运行——这是免费的。你可以访问 Aura.ai，运行任何网站，就能根据大量协议和最佳实践
00:13:02获得评分和基准测试结果，并获得智能体反馈。智能体实际上
00:13:09会返回关于你网站的反馈。我们还有针对公司和产品
00:13:16在该基准下排名的排行榜。我们开始绘制 Web 版图，一切都很顺利。
00:13:24但我们得出了一个洞察，或者说意外发现。我们发现——这里有人听说过 LMS.txt 吗？
00:13:36LMS.txt 就像是智能体就绪的事实标准。你会觉得：如果网站发布了 LMS.txt，
00:13:42智能体就知道如何与你交互。还有 auth.md、pricing.md、X402 以及很多标准。但我们发现，在我们测试和运行的网站中，
00:13:52近 50% 都发布了 LMS.txt。然而在我们运行的智能体中，没有一个真正使用了 LMS.txt。
00:14:02实际上，几乎所有智能体都直接去了文档页面，然后是首页。而那 40% 使用了 LMS.txt 的智能体，仅仅是因为文档
00:14:12指出了有一个叫 LMS.txt 的文件需要使用。于是我们恍然大悟：
00:14:19由我们人类来为智能体定义它们需要什么，并没有太大意义。现在没人这么做了。
00:14:26就连 OpenAI 也不再发布工具的最佳实践了。因为他们发现每次发布
00:14:31最佳实践，模型就会变得更好，而这些实践也就过时了。六个月前，MCP 服务器的
00:14:36最佳实践还是编写三段式的描述，好让智能体知道如何
00:14:41与你交互。而现在三行就足够了。所以最佳实践会逐渐沉淀。我们需要智能体
00:14:47来定义它们需要什么，对吧？我们需要智能体对网站的反馈。因此我们构建了 Aura's Journey。
00:14:54Aura's Journey 非常酷，它也是免费的。你可以访问 journey.aura.ai，针对
00:15:00任何网站、任何意图运行任何智能体，查看智能体试图与该网站
00:15:08交互时的路径。例如在 atia.com 上选择 Claude Code，我们在网站上运行它。你可以实时看到
00:15:17智能体如何移动，以及它试图在网站中寻找什么。我们进行了数万次
00:15:25这样的测试，只是为了理解智能体在尝试与网站交互时，究竟在寻找什么。
00:15:30酷的地方在于，不只是运行单个测试环境，而是运行多个环境。你看
00:15:39这里有 Claude Code、Vercel 的环境 Eve，以及 ChatGPT，在同一个网站上执行相同的意图。
00:15:45这是 Claude Code，这是 Haiku，这是 Eve。看看智能体的探索轨迹有多么不同。
00:15:52这是 ChatGPT。ChatGPT 能更好地找到结果。你可以直接看到整个网站上的
00:16:01探索轨迹。我们需要理解原因。我们需要理解为什么会这样。为什么网站发布了
00:16:08auth.md 文件，但智能体却不去寻找 auth.md？它们到底在找什么？
00:16:13所以在 Aura 中，你可以针对任何业务问题。对于任何领域，你都有诸如业务
00:16:21目标或问题，你可以看到智能体采取的路径。而最有趣的
00:16:28部分在于，既然我们知道了智能体如何与网站交互，那么智能体 Web 的下一个重大里程碑
00:16:33是什么？对于听过上一场演讲的人来说，
00:16:40答案就是“发现”（Discovery），对吧？但这不是我们通常认为的那种发现。不是 SEO，不是 GEO，
00:16:45也不是 AEO。因为我们要记住，每一次技术革命都伴随着它的发现层，对吧？
00:16:52Web 革命带来了搜索，移动端带来了应用商店，社交媒体带来了 Feed 流。
00:16:59那么智能体资源的发现层是什么？MCP 的发现层是什么？
00:17:03OpenAPI.json 的发现层又是什么？我们到底在寻找什么？我是说，也许 Airbnb 有比 Booking.com 更好的 MCP，
00:17:09但 Booking.com 有比 Airbnb 更好的 API。那我们该怎么做？
00:17:16网页搜索，传统的网页搜索是不够的。因为它基于人类
00:17:22SEO 和 PageRank 算法，不够灵活。自定义注册表，比如针对单个智能体或
00:17:29对话的注册表，也是不够的。因为它们是封闭的，需要每个应用向这些
00:17:36注册表提交自己。而像 MCP 注册表这样的中央注册表同样不够，因为谁来进行
00:17:42审核策划？治理模式是什么？我们如何决定哪些资源可以进入该注册表？
00:17:48目前围绕这一点正在涌现一些新标准。比如 AI Catalog.json，这是由
00:17:53Anthropic、OpenAI、Google、MCP 和 A2A 提出的标准，规范了网站如何向智能体暴露自己。
00:18:00还有智能体资源发现标准（ARD），由所有这些公司及更多机构共同制定，
00:18:05基本上规范了发现层或目录如何向智能体暴露自己。因此我们构建了
00:18:14自己的 Aura Directory。因为我们是智能体 Web 的研究实验室，所以我们构建了它。在
00:18:18我们的 Directory 中，我们收集了扫描到的所有域名，并将它们放入一个
00:18:24智能体真正可以查询的目录中。我们暴露了 AI Catalog.json 文件，因此你可以看到
00:18:31比如以 monday.com 为例，我们可以生成这个 JSON 文件，基本上能告诉
00:18:38智能体：是的，这是 monday 的 MCP 服务器，这是 monday.com 的 API 服务器。然后
00:18:42智能体就可以直接对其进行查询，对吧？对于每个域名，你只需访问
00:18:47AI Catalog.json。我们公开了注册表，也就是目录本身。所以对于目录上的每个条目，
00:18:55我们都可以告诉智能体：比如 Vercel，这些是它的智能体资源，
00:19:02这是访问它们的方式。显然，这个目录完全符合 ARD（智能体资源
00:19:08发现）标准，因此任何智能体都可以用任何查询来请求该目录，对吧？
00:19:13这就是 Aura.directory，感兴趣的话可以去看看。这一切都是 Aura 多元宇宙的一部分，
00:19:21包括 Journey、Directory 和 Ranker。我们还得出了一些其他非常有趣的洞察。比如，
00:19:26对智能体友好与对人类无障碍是非常相似的。因为大语言模型访问你的
00:19:33网站时，就像是有视力障碍的用户。它们看不见你的网站，它们
00:19:39需要其他信号来理解如何使用你的网站。让网站对人类无障碍，
00:19:44有助于提升智能体无障碍体验，反之亦然。总结一下，这些就是 MCP 应用。这就是我
00:19:51过去几个月一直在做的事情。这是智能体 Web 的最后一块拼图。它真正拉开了
00:19:57智能体 Web 的序幕。现在智能体开始漫游 Web，它们需要不同的东西。它们需要
00:20:03不同的道路和基础设施。但我们不需要为智能体重构 Web，我们只需要
00:20:09让 Web 可被智能体访问。所以让我们确保 Web 为智能体的到来做好准备。
00:20:18非常感谢大家。
00:20:39谢谢
커뮤니티 글
아직 글이 없습니다. 이 영상에 대한 첫 번째 글을 작성해 보세요!
이 영상에 대해 글쓰기