去年作为嘉宾参加了W3C中国举办的首次WebEvolve活动，此后也持续关注该系列活动。最近/上周远程厅了一下WebEvolve 2025年度大会，整体确实以学到东西为主，不管是技术本身、各人各组织的理念、还是他们的展望和反思，都让我觉得顶着时差参与不算亏。

不过参加过程中也会有一些自己的想法，进行了简单记录，现在将其中想法最多的几个进行整理，外加后一周参与的《This is for Everyone》发售活动的感想及回顾，共同写成这篇文章。自然，能被即时捕捉到的想法，大部分都是比较强烈的思维，尤其是异议的部分。由于是reaction性质的快速记录，也没花太多时间整理，用词可能不太严谨，各位海涵。总之，技术性讨论，绝非对人。

其中绝大部分图均来自各位嘉宾的演讲稿（相当多是我的截图），而演讲稿现在都已在大会活动页面中提供访问链接，故而我就放心将这些图放在文章中了。相关内容版权归属相应演讲嘉宾。

趣事：AppleID从平板登录

第一天最开始有一个很好玩的事情，就是在嘉宾做演讲时，经常、反复跳出“您的Apple账户在另一台设备登录”的提示窗口，而且嘉宾每次都点了允许。我既不理解为什么反复，也不理解为什么会出现。只能说，很符合我对苹果的感受。

主题：高性能Web方案

这里我本来以为能看到一个具体的技术案例，但其实是在讲一些构想或者经验教训之类的东西。我对其关于性能、关于Web（在这个话题上）大体需要演进的方向其实是挺赞同的。

但里边的论述过程让我觉得不太严谨，我觉得很多地方用了错误的论据和论证。从一个研究者的角度看，其中部分乃至不少都是为了结论寻找原因。当然，我也明白，工业开发可能的确不需要特别严谨的推理，而且历史证明了技术演进和接纳经常都不讲道理。所以这里更多是记录我的看法，重申一下：对事不对人。

P2

这页本身没有问题，但演讲者在这里（可能是下意识的）耍了个花招，说Web等价于左侧的方式，而移动端等价于右侧的方式。这时候再看，那就是某种虚空造牌了。

左侧仅仅考虑了最典型最基础的Web技术，也就是Web 1.0时代的模式。而事实上，从Web 2.0开始，近现代Web经常都是某种Web App，本身在“当前站点”内的导航或访问都不再是重新加载页面。换句话说，Web本身就支持右侧的模式，在这里并没有明显的缺陷——还记得页游么，一个完整的大型游戏，跑在你的浏览器里？至于开发者使用什么模式，那是开发者可以自己选择的；而如果开发者不愿意使用这种模式，我们却把问题怪罪到“Web允许开发者不用”上，这就有点不要脸了。

好人就得让人拿枪指着？.png

我个人觉得正确的缺陷是：

1. Web没有定义可以“识别”哪些站点应该用“同一个App”加载的能力，并从缓存加载；
2. Web没有统一（强制）Web App的互操作方式（比如交互、导航模式），使得Web App的互操作性比传统Web低很多。

但其实如果仔细考虑一下问题一，现实中并没有这种需求：移动端当前的App模式本质上就是“同一个系统使用同一个App”，但“不同系统使用不同App”，不存在“不同系统使用相同App”的情况。也就是说，这本质上还是一个Web 2.0时代的模式，并没有任何Web 2.0不能实现的部分。

这里最重要的改进可能仅仅是需要提供“安装”一个Web App的方式——但其实这就仅仅是访问它一下。

FirefoxOS对此有很多话要说。Android浏览器也都可以为页面创建启动按钮，也有很多话要说。

所以本质上，只有问题二才是问题。但这个问题又恰恰是演讲者，乃至大部分企业开发者（尤其是平台性企业）不去考虑的问题。

P3

这个页面的总结我比较认同，但也有些比较迷的地方。最典型的就是，什么叫“小程序框架承担了大量工作”？

演讲者说这意味着不需要每次加载大量JS，省了带宽。

但前一页中演讲者明明表扬了需要预先加载大量数据/代码的App模式呀？

所以到底一个程序需要大还是需要不大呢？

而“小程序”本身就是Web方言，需要体量小的话，限制到基础语言特性的网页也一样啊？

当然，小程序的确有一个Web不具有的优势：宿主App上（比如微信）可以内置小程序通用的JS或类似框架性代码，不需要在访问时才加载。

但这其实不是什么太大的问题，因为对Web来说，只需要浏览器调整一下，允许在启动或安装时自动加载相关JS代码就好了。

PWA有话要说。

而我也好奇什么又叫“小程序可以直接原生开发”？

演讲者没说（或者我没听到），但我猜这里是想说前面那种“battery included”的性质。但从另一个角度来说，这同时意味着符合这个特点的小程序不能加载第三方库，其实开发复杂度是上升了的。而且这也涉及到跨平台问题（见后面提问部分）。

P4

这页我大部分都挺同意的，不过这其实主要是关于JS的。我对JS也颇有微词；从工程角度，我个人也更喜欢编译型语言。我十分认同要大力发展WASM，解决JS不想解决的很多问题。

另外，那个“可控性”部分，“审批平台接受”这事，其实是默认了Web 2.0的模式。在下一代互联网中，我们完全可以想像以动态信誉为基础的更好的模式，而不是受限于某个“审批平台”——谁也别装外宾，平台本身的中立性就是个问题，谁还不知道各个平台对举报删贴有不同的立场倾向性呀，“审批App”也同理。

P5

其实我个人认知中，这三种其实是没太大区别的。第2种就是第1种加上模板；第3种就是第2种使用编程语言直书的表示，而非通用抽象表示。

所以我觉得这里的结论是有问题的——它和Web与否没有关系。

举一些反例吧：Qt或类似的框架长期使用XML书写UI，而不是第3种，它们算什么，算是谁的优势算谁的劣势？后来Qt等又引入QtQuick之类的技术，类似第3种，它算是什么类别？而React (function component)其实是使用第3种模式，它又算是Web的还是算是非Web的？

P6

不对，这不是“小程序”，而是任意普通意义上的“程序”/App，或者说“客户端”。

重点在于，它和“小”无关。前文说小程序的优势的时候明确提到了小程序要“小”，但这里又不考虑这件事了。

P7

这个对比就有点荒诞了，很多条目在我看来其实挺迷惑且自相矛盾的。

比如开发成本这点，在我看来就是随口宣传小程序的宣传文稿，而非理性讨论。一边说切换过来开发成本低，一边又说和现有Web差别不大，那到底比Web简单在哪？如果差别不大，为什么不直接用Web？

另外，前面说Web性能不好，所以不如Native App。但这里又承认MiniApp性能不好，那么……为什么这些部分不用Web？

P9

这个页面（以及前一个批判JS的页面）的内容我挺同意的。当初我参加Increasing Rust's Reach 2018的时候第一次知道WASM，当时就觉得这个东西应该尽快发展，我很期待它的普及。貌似现在WASM已经发展得很不错了，比如去年在GOSIM 2024北京大会](https://china2024.gosim.org/index.html)的时候见到了有人的报告是关于用WASM（WasmEdge）做的LLM运行时。

在这里，虽然演讲者没考虑，但语义化的标签还可以带来Accessibility上的优势，我觉得挺好的。

但这里就有个吊诡的问题了：演讲者说这些是小程序方案的优势，但现实中小程序们的标签定义本身挺乱的，而Accessibility却又一团糟，所以这和小程序究竟有多少关系呢？或者也可以反过来问：小程序究竟是真的考虑了这些好处呢，还是只是现在拿着这些理论好处来挽尊呢？

倒不如说，需要的是重新梳理一下HTML的标签，考虑是否需要引入更高层的标签视图；高层标签是被直接传输的，作为Web标准的一部分，且高层标签向低层的转换是通过component完成/声明的；原本的HTML标签可能作为低层表示存在，交给浏览器渲染。

其实很多现代JS框架已经是这种思路了，甚至说这其实就是Native开发时的思路，只不过这里提出了一些标准化方式。

当然，这个做法毋庸置疑会引入许多问题，尤其是如何尽可能保证互操作性——Web是以标准化的HTML、CSS渲染为基础的，这样做到跨平台通用，但这个提议则几乎彻底抛起这些，转而进行高层语义声明，那么渲染通用性怎么做？

这也许才是Web渲染标准演进的更合理探索方向，而不是强调小程序的先见之明云云进而全盘吸收。小程序可没有考虑过这些问题。

其余页面

我对其余页面整体赞同——当然，有一部分内容我不够了解，这也是没办法的事。不过对其中个别内容有不同意见，但都属于细节问题，而且我也相信演讲者并非要求要100%不打折扣地按这个提议走。

提问——小程序不统一

在本场最后的提问环节中，有一位参与者提出的问题我觉得很有意思也很重要：

我们是内容作者。使用Web、MiniApp、或者所提出的WASM+WASI方式，我们来实现任何东西都没问题，都可以去做。但问题在运行态上，也就是说，我为抖音开发的，没办法在微信运行，反过来也一样。你们前面的演讲似乎都没有讨论这点。

这个问题其实很关键，甚至我认为它正是前面这些讨论中的死穴：为什么每个App需要自己的一套东西（比如MiniApp）？

有没有可能，其实问题的本质不在于“有没有/能不能有一个统一的方案”，而是“每个App不想要一个统一的方案”？

有没有可能，在小程序之前，这种东西的源头叫微信公众号，它本质上就是个HTML方言，有简单格式化，但没有高级CSS没有JS？而微信公众号不直接使用Web的理由是……？

Web性能不够？Web没法达成展示文章这个简单功能？Web没法展示图片？Web文章没法评论？

显然都不是。

而这显然不是我一个人的看法。前后均有演讲者也尝试讨论了这个问题，其理念和我不谋而合。

为什么小程序在中国出现且大规模使用，而美国等国至今不多

随后一位演讲者对这个小程序的情况进行了更细致的探讨（见演讲稿的头三页）。先是提出问题以及自己的假设，然后比较了中外（尤其是美）的互联网生态，以此证明自己的假设。

简单来说，演讲者的看法是这样的： 美国由于移动互联网生态由两大巨头把控，且各自对自己的系统生态有极大的决定权，故而他们没有必要做小程序；而且其上没有其他类似大小的平台，所以也没有其他人有必要去做。 而中国则由于生态更碎片化（各家深度定制版Android系统各自互不兼容/乱七八糟的API调整和bug），且有几个互相竞争的互联网（而非硬件生态）巨头，故而它们从技术方便和现实利益角度都有动力去在软件上向垄断发展，搞平台上的平台，也就是小程序。

这个讨论虽然也有自身问题，但就严谨性而言是更高的：要先有假设，然后去完整对比双方的状况，以此来检验自己的假设。前一位演讲者缺少了这个过程，只是在不断的下断言。虽然相当大部分断言没错，但我还是会有一定抵触，且会让我下意识地更想抓紧找他的问题，故而可以看到我前面有大量想（yi）法（jian）。

综合来说，我觉得该演讲者的看法是比较有道理的，而且可以完美回答我前面在“提问——小程序不统一”小节抛出的那些问题：你们都说小程序如何如何为了开发者为了用户好，但你们为什么各自又弄互不兼容的生态，导致对开发者和用户都更不好呢？

很简单，互联网圈地罢了。

我们还可以用另一个事实来增进这个论断的可信度。这两天我注意到了W3C有一个小程序工作组，试图标准化小程序的技术设计（API之类）。而我打开看了一下参与者，嗯，国内的为主，尤其是华为和百度，也有几个阿里的，而腾讯、字节则是一个人都没有。

而我们的常识知道，微信小程序是小程序中的绝对霸主，不论是从历史还是从现实来看都是如此；而貌似抖音小程序也在快速发展。这两家完全没有意愿参与标准化工作，恰恰说明他们其实并不在意标准化。

不要说什么“他们可能不知道”。前一个演讲者本人就是腾讯的。

Agent和Web

第二天的活动是以Agent为主题的。各位嘉宾的演讲都讨论了前沿技术，也分享了他们各自（以及各自公司）对相关话题的构想和工作，信息量还是很足的。作为Agent话题，这些演讲都是合格的。

但是有一个问题：Web在他们看来是什么？

排除开场报告以及AI智能体协议社区组联合主席的相关演讲，在其他几乎所有人那里，要么干脆没有Web，要么Web只是一个数据源，是一个类似电脑操作系统、手机操作系统或者手机app的一个存在。

他们几乎没有考虑过一个可能性：Agentic Web。

这和前面我说小程序那里的状况以及问题其实是一脉相承的——他们有技术，但他们的技术方案不是为了服务大众或者开发者。

Agentic Web其实是一个很早就被提出的理念了，在上一波AI浪潮时代的就已经被提出了。其中部分理念受限于时代技术所限，在现代可能有更好的解决方案，但它打了个相当完善的基底：什么是agent，agent之间有什么关系（交互），交互时要考虑哪些问题，Web资源可以怎么被agent使用，agent和用户之间是什么关系。这些问题全部都有现成的讨论——虽然并非最终解决方案，但经验教训有很多，可以让新的从业者/开发者少走不少弯路。

然而大部分演讲人似乎并不知道这些东西的存在，而他们的报告从范畴上来说，只讨论了前两个话题，偶尔涉及了第三第四项，几乎没有涉及第五项。

这就造成了，我本来以为可以听到许多现代Agentic Web的讨论，尤其是如何依托现代AI（尤其是LLM）来调整过去的仅仅依靠形式化方法展开的Agentic Web，进而改善agent交互、Web资源使用、用户信息管理和使用等话题；然而，除了使用agent去操作app以外，我几乎没有听到什么这方面的话题。

挺令人遗憾的。

交互方式的变化

第二天有位演讲者提到了这么一句话：（交互方式）从CLI到GUI到LLM自然语言对话。

我知道这是2022年末ChatGPT出来后，许多人乃至大佬宣扬的一个理念，甚至有些人认为自然语言对话这会是最终形态。

脑机接口：？

但我不太同意这个理论。

错误的地方在于，它认为“自然语言对话”传输信息效率比图像更高。但大家都知道有个词叫“一图胜千言”。

更不要说当描述动作时，自然语言就更难以胜任了——想想多少行业仍然在施行师徒制，不是因为权力关系，而是因为许多操作必须这样教授才行。

我认为更正确的说法是：LLM增强的 用户需求为中心的 GUI。

这是什么意思？

意思是现有的GUI不够好用，包含很多乱七八糟信息，但用户在大多数时候用不上它们，尤其是越功能强大、越专业的软件相关情况越严重。这个说法也可以扩展到Web上，也就是一个网站有很多网页，跳转来来去去，但用户需要的内容却不易被找到。

而LLM可以整理相关信息，仅提供和用户当前需求最相关的功能。

当然，LLM存在形式以及功能呈现形式可以有多种选择，比如Copilot模式或LLM生成GUI模式。

但无论哪个，都无法彻底取代GUI，而是对GUI的补强。

注意，这里说的是LLM，而不是“AI”。如果考虑“AI”，那么自然语言这件事本身就有点视野太狭窄了。讨论AI的话，随着能力边界扩展，交互模式将会有各种不同的变体。Agent将是最终的目标，这点我完全同意，但Agent又有多种交互和运作的可能性，目前都是在探索。

Web AI

本地+云端

这个演讲是我这两天厅的中国人做的演讲中，罕见的真正考虑了“用户”的。他讨论了端侧模型和云端模型各自的优劣，且是从用户角度而非从企业业务角度，然后在这里总结道“端侧够用就用端侧，端侧不够用就用云端”。

这本来是个理所当然的事情，但其他人的演讲几乎没有考虑过这件事；而且一些演讲者的大部分篇幅中默认了一件事情：有唯一的一个东西它叫做“AI”，且这个东西可以不打折扣地做功能中的任何事。

然而这其实是一种很离谱的假设，就好像说有唯一的一个存在它叫“人类”，且这个唯一的“人类”既可以100米跑进10分钟，又可以进行各种语言的实时交流，还可以发展出相对论，且可以不需要debug地编写操作系统；它既身高1.8米以上，又体重七斤六两。

标准的意义

这张图其实展现了这个演讲者思路和其他人的不同。其他人也考虑架构，也考虑未来，但却没有考虑过开放生态。的确，这也很好理解，毕竟他们很多人都是在互联网大厂工作，大厂在当前这个时代就是平台经济的受惠者，自然会自觉或不自觉地倾向于加强平台——而平台本就是排外的，自然不可能想要开放生态，而是想要封闭生态。

另外也有一些实际上的问题：一些人擅长设计架构，但不擅长设计协议。架构需要考虑的是怎么拆分功能，怎么组合功能，在哪增加新功能；而协议需要考虑的是怎么调用功能，怎么进行交互，怎么确保可靠。很多时候，开发者对交互的考虑只是“够用就行”，或者“满足我的功能就行”，自然没有考虑协议的动力。

This is for Everyone

在这次WebEvolve活动的4天后，Web的发明者Tim Berners-Lee在牛津进行了他的新书（可以理解为是关于Web的回忆录）的发布活动。这本书的标题叫《This is for Everyone》，直译为“这是给所有人的”，或者稍微文雅一点“献给所有人”。这是他一直以来对Web的期许，也是他在2012伦敦奥运会开幕式时说的话。

虽然Tim本人可能并不知道，但在我看来这个发布活动其实是对WebEvolve中许多话题的某种回声，它让我在日常研究之外，重新以更全面的角度审视了Web，以及WebEvolve 2025中听到的许多观点，并促使我决定写这篇博文，将这些想法传达出来，尤其是传达到中文场景中。

两个问题，回答，及我的所想

牛津最近天气都不是很好，活动当天也下了不小的雨，但大部分人都早早到场，下两层全部坐满，我到的时候只能坐在第三层了。而活动本身是以采访的形式进行的，主持人（James Harding）问了许多有意思的问题，其中有好几个都让我印象十分深刻，但其中两个和本篇的话题尤其相关。

问题其一——Web和数据

第一个问题是这样的：

James问:在CERN公布Web的初版代码的时候，明确写了软件可随意复制、分发、使用。这是你明确向CERN要求的么？
Tim答：是的。不过当时并不是出于理想什么的，而是因为我当时让很多同事都把自己的数据放在Web服务上了，要是他们访问自己的数据还需要付费，这事既不公平又不实际。

可以听出来，Tim其实是自谦了的，毕竟他完全可以设定为要求付费，而送同事们一人一份免费的即可。在此之外，这个回答从小处其实反映了Tim本人后续的许多理念的源头：因为是你的数据，所以我不应该向你收费（来访问、使用它）。

这一点，在当今这个时代其实已经很稀缺了。的确，许多软件都是免费的，但这里有一个很关键的区别：免费使用软件，而不是免费且随意访问、使用你的数据。你使用数据的能力严格严密地受限于软件所提供的功能，且通过EULA（最终用户许可协议）确立为法律授权的限制。

如果你还是想不明白这个区别，就想像一下，如果你不想使用QQ、微信、微博了，你怎么把自己过去的所有聊天、发言记录全部带走，在其他地方访问？是不是要看软件的脸色，如果它提供这个功能了，你就可以按它提供的功能导出成某个格式，而如果它没有提供，你就没办法了？ 有些更高级点的用户或许知道有第三方工具可以做这些事，但请你想一想，为什么这些第三方工具在持续的被厂商打压（举报或起诉），而且厂商屡屡成功？

想来，这也就是为什么Tim后来提出了Social Linked Data（SoLiD），目标是让用户可以把自己的数据全部握在自己手中，以此来改变Web 2.0以来的许多问题。

本博客也有文章说过Solid及相关话题。感兴趣的读者可以阅读《论Web3.0和Web3》、《Solid——简介与体验》等文章。

而这两天的活动中，我并没有听到什么让用户掌握更大数据相关权利的报告——不是说你要提这个词，而是你的设计你的技术可以增进它。大部分报告虽然是纯粹的技术讨论，但它们架构所反映的则是背后的数据权利关系考量。很不幸，绝大部分都是沿着目前的平台经济一路狂奔。

正好，这里也再引述一段访谈中的对话，讨论到了所谓技术中立性：

James问：你是什么时候第一次意识到，万维网走向了一个和你所期待所不同的方向？ Tim答：2016年，美国大选和英国脱欧（太多的假新闻和煽动）。 James跟着说道：这仅仅是Aaron Swartz后没几年……（省略对话）……那你现在怎么看待西海岸所信奉的技术中立理念？ Tim答：我最开始是相信这点的，但我后来发现不是这样。当你提供社交性的网络时，人们是会跟随链接（跟随易得的信息）的，这是心理学导致的事情。你需要把技术和心理同时纳入考量，去构建东西，去构建更好的东西（to build things in good ways）。

如果你没听说过Aaron Swartz这个名字，那么你至少应当知道他死于2013年，他也被称为“互联网之子”，并有以此为名的传记电影讲述他的故事，且在豆瓣有9.1分。

问题其二——AI开发者和权力

第二个问题是前后多个问答组成的：

James问：你觉得AI会比人更强大么？
Tim答：我觉得会的，早晚有一天会的。
James问：我本来想听到另一个回答的（笑）……那你怎么看待开发这些算法或大模型的开发者？
Tim答：他们手上有巨大的权力/能量（power），也需要做恰当的事。
James问：（也就是说）现在没有人能压在你（他们）的肩头，来约束你（他们）……？
Tim答：的确如此，所以你需要（知道去）尊重其他人。

我觉得这两天听到的报告里，许多人虽然在用AI这个词，但他们其实没有仔细考虑过AI是什么，或者说“他们所说的AI是什么”。仔细捋一捋的话，很多人的报告中其实同时认为“LLM就是AI”，“AI还需要别的核心技术”，“有一个唯一的全能东西叫AI”，以及“AI不是全能的”。然而，这四个东西其实是不可共存的，如果你相信其中一部分，逻辑上你就不能相信另一部分。

而同时，在这些报告中，不少人或公司并不怎么考虑用户利益，并不尊重用户。他们可能会一边说着为了你好，一边又实际上做对你不利的事情。做这些事情可能是出于商业利益考虑，也可能仅仅是因为这不是考虑项。

这其实恰恰符合了Tim所担心的事：我们的AI开发者手上有权力，但自己不知道自己在做什么，而且也不知道去尊重他人。这的确让人挺脊背发凉的。

不过幸好，我暂时还不相信目前的AI发展思路可以搞出超越人类的智能（而不是“工具”），所以倒也没有那么担忧。我担忧的更多在平台经济等问题上——虽然也挺令人烦躁的，但至少不是末日。

Attention vs Intention

虽然我还没有找到足够时间来看书，但我看到在《This is for Everyone》的末尾几章，Tim讲到了Attention Economy（注意力经济）和Intention Economy（意图经济），求索一种思维范式的转变。

我相信，相当多数开发者都知道目前的互联网经济模式（尤其是移动互联网）是Attention Economy，而且他们也在不断的为此添砖加瓦——虽说大部分人并不是故意如此，而是因为工作就是如此。很多人不喜欢这个模式，但又不知道应该怎么跳出，并提供更好的模式。

Intention Economy就是一种解决方法，而且我也认为它是一个很好的模式。

简而言之，Attention Economy（AE）的核心是抓住用户的注意力，提供的服务的目的是让用户不断分配更多注意力以及时间在上面，也就是培养成瘾性。抓注意力的方法各个服务各显神通，但显然，由于人类生物和心理特性，我们都知道什么类型的东西会更抓人眼球。

而Intention Economy（IE）的核心则是了解用户意图，提供的服务的目的是更好地领会用户的目标意图，更好地达成目的。它和AE最大的区别在于，它不渴求用户的时间，不追求用户将更多时间分配到它上面。很自然地，用户会选择能更快达成自己目标的IE服务，而不是更让自己花时间在上面的IE服务，以便可以将精力投入下一个目标中——哪怕仅仅是看下一个电视剧。

AE和IE有不少地方是相似的，比如都需要更全面地了解用户偏好，都需要能对可能功能进行预测。但AE不在乎用户在本服务之外的需求，比如短视频服务就只在意让用户多看一会，而不会在意用户是否需要做其他事情（比如吃饭）。而IE则不然，为了给用户最好的建议，IE需要知道用户生活的方方面面，比如今天是否需要上班、学习，几点需要开会，什么时候要通勤等。

知晓这些信息其实是很侵入式的，以目前的互联网生态自然会导致很多人的反感（当然，由于人类的正态分布性，自然也有大量的人完全不在乎）。数据泄漏、数据被挪用等都是我们日常会觉得有问题的事情，但在目前的平台经济下又是无法解决的——数据都在平台上，我们作为用户没有控制和选择权。那么，为了转换到IE，我们自然也需要与之相匹配的数据架构，让用户能更放心地存放全部数据，更放心地让某些IE服务使用它们。

有些读者可能已经意识到了，IE和agent其实十分切合，因为agent的本质就是要做两类事：1.替用户去了解信息，必要时进行交互；2.帮用户整理信息，以及给用户提出建议。这就是IE服务最需要的功能。但这两天关于agent的讨论中，考虑这个话题的寥寥无几。

这是Tim的Solid这一类生态的切入点，也是我认为这两天WebEvolve最缺乏的讨论内容：在下一个时代的Web中，我们需要什么样的数据架构，以便让用户可以更便捷且更信任地使用agent？这种信任不应该是出于盲目（比如“大公司一定会让人放心地使用我的数据的”），而是出于充分的技术保证。