去年作爲嘉賓參加了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？這種信任不應該是出於盲目（比如“大公司一定會讓人放心地使用我的數據的”），而是出於充分的技術保證。