--- title: "母站、子站與領域觀測站：網路資訊海的分散式入口架構" series: "網路資訊海動態秩序化" series_id: "EML-IIODO" document_id: "EML-IIODO-TH-03" document_type: "公開理論文" author: "Neo.K" organization: "EveMissLab" version: "0.1.0" status: "公開初稿" date: "2026-07-31" language: "zh-TW" license_note: "公開引用時請保留作者、文件編號、版本與來源。" --- # 母站、子站與領域觀測站 ## 網路資訊海的分散式入口架構 ## 摘要 當新聞被重新定義為領域知識狀態差分，並進一步區分微觀、中觀與宏觀尺度後，下一個問題便不再只是「如何分類內容」，而是「這些不同領域、尺度與使用者入口應如何被組織」。若把所有領域差分全部堆疊於單一巨型網站，平台很快會重新製造資訊過載；若每個領域完全獨立建站，則又會導致來源重複抓取、事件識別不一致、歷史資料割裂與跨領域關聯消失。 本文提出「母站—子站—領域觀測站」的分散式入口架構。母站不被定義為支配所有內容的唯一中央網站，而是負責共用資料、身分、搜尋、事件路由、跨域關聯、訂閱與治理協調的公共底座；子站則是針對特定領域建立的獨立觀測視圖，具有自己的來源範圍、分類本體、重要性函數、敘事方式、語言入口與更新節奏。領域觀測站是比「網站分類頁」更強的單位：它可以被獨立識別、獨立訂閱、獨立索引、獨立演化，也可以在共享事件識別與溯源資料的前提下，對同一事件作出不同尺度與不同領域的解釋。 本文區分集中式入口、多租戶平台、聯邦式觀測網路與混合式架構，主張早期系統最適合採用「共享核心、領域自治、分層隔離、可逐步聯邦化」的混合模型。本文並提出全域事件身分、領域投影、事件路由、共享與隔離矩陣、跨站引用、正規網址、多語版本、訂閱通道、失敗隔離與子站生命週期等基本原則。AGIRight Topics 可被視為第一個已運作的領域觀測站原型：它目前仍依附於單一站點，但已具備來源聚合、主題分類、時間排序、多語入口與機器可讀匯出的初步特徵。 本文的核心主張是：未來網路資訊海的秩序化，不會只由一個全知入口完成，而會由大量彼此可連結、可訂閱、可查詢且保有領域自治性的觀測站共同形成。母站提供共同記憶與協調，子站提供專業注意力與可居住的資訊空間；兩者結合，才可能同時避免資訊碎片化與中央資訊過載。 **關鍵詞：** 母站、子站、領域觀測站、分散式入口、多租戶、聯邦式架構、跨站事件、領域自治、資訊路由、網路資訊海 --- ## 1. 問題起點：一個入口無法容納整個資訊海 前兩篇建立了兩個基礎命題：第一，新聞可以被理解為某個領域中的知識狀態差分；第二，同一差分可以在微觀、中觀與宏觀尺度下取得不同意義。若令網路資訊海在時間 $t$ 的狀態為： $$ \mathcal{W}(t) $$ 某領域 $d$ 的尺度化差分為： $$ \Delta K_{d,\ell}(t) = \mathcal{O}_{d,\ell} \left( \mathcal{W}(t),\mathcal{W}(t-1) \right) $$ 其中 $\ell$ 為觀測尺度。當領域數量與尺度數量逐漸增加，前端入口數量也會快速增加： $$ \mathcal{I} = D\times L\times U\times T $$ 其中： - $D$ ：領域與子領域集合； - $L$ ：微觀、中觀、宏觀等尺度集合； - $U$ ：不同使用者、社群與專業角色； - $T$ ：即時、每日、每週、年度及歷史等時間視窗。 即使只選擇一百個領域、三種尺度與五種時間窗口，也已產生一千五百種可能入口。若再加入語言、地區、專業程度與個人訂閱，單一首頁不可能同時保持完整與可讀。 因此，平台不能把「所有資訊都放在同一個網站」誤認為整合。真正的整合應是： $$ \text{底層可共同理解} \quad+ \quad \text{上層可分別進入} $$ 也就是： > **資料與事件可以共享，注意力入口必須分散。** 這正是母站與子站架構的理論起點。 --- ## 2. 子站不是分類頁，而是獨立觀測單位 一般網站的分類頁只是同一套內容管理系統中的篩選結果。例如： ```text /topics?category=ai-rights ``` 它可能改變顯示內容，卻未必具有自己的來源規則、更新週期、重要性判準與使用者共同體。 本文所稱的「領域觀測站」比分類頁更強。令第 $i$ 個觀測站為： $$ S_i = (D_i,\Sigma_i,O_i,W_i,P_i,L_i,A_i) $$ 其中： - $D_i$ ：該站負責的領域邊界； - $\Sigma_i$ ：來源集合與來源接入規則； - $O_i$ ：領域本體、標籤與事件類型； - $W_i$ ：領域重要性與排序函數； - $P_i$ ：發布、審核、授權與治理政策； - $L_i$ ：語言與在地化介面； - $A_i$ ：管理該站的 Agent、工作流與人工角色。 如果一個頁面只有自己的網址，卻沒有以上任何獨立規則，它仍然只是頁面。若它能夠獨立決定： - 觀察哪些來源； - 哪些事件值得進入； - 哪些變化屬於微觀或宏觀； - 每日三則如何選擇； - 何時需要人工檢查； - 如何向特定社群解釋； 那麼它才逐漸成為領域觀測站。 因此： $$ \text{子站} \neq \text{URL 分類頁} $$ 而是： $$ \boxed{ \text{子站} = \text{具有獨立觀測責任的領域視圖} } $$ --- ## 3. 母站不是超級首頁，而是協調平面 「母站」容易令人聯想到一個包含所有子站內容、排名與導覽的總首頁。但如果母站只是把全部子站新聞重新混合，它很快會再次形成大型資訊噪音場。 本文將母站定義為： $$ M = (B,I,Q,R,G,C) $$ 其中： - $B$ ：共用資料與事件底座； - $I$ ：全域身分、權限與訂閱管理； - $Q$ ：跨站搜尋與查詢； - $R$ ：事件路由與跨領域分發； - $G$ ：跨站知識圖譜與歷史關聯； - $C$ ：規格、品質、治理與可觀測性協調。 母站可以有公開首頁，但其真正功能不是「替使用者看完所有內容」，而是確保不同觀測站之間能共享必要基礎： 1. 同一事件不必被每個子站視為完全不同的資料物件； 2. 同一來源不必被每個子站重複抓取與保存； 3. 跨領域事件可以被多個子站各自解釋； 4. 使用者可以在不同子站之間保留訂閱與身分； 5. 歷史資料可以跨站查詢，而不被前端邊界切碎； 6. 某個子站故障時，不必拖垮整個平台。 因此，母站更接近「協調平面」而非「內容中央政府」。 $$ \boxed{ \text{母站} = \text{共同記憶層} + \text{協調層} + \text{跨域入口} } $$ --- ## 4. 四種可能架構 母子網站並沒有唯一部署方式。至少可以區分四種架構。 ### 4.1 單體集中式架構 所有領域共用同一程式、資料庫、後台與前端，只用路由區分： $$ M=S_1\cup S_2\cup\cdots\cup S_n $$ 優點是開發簡單、成本低、資料一致；缺點是領域規則容易混雜、失敗影響範圍大，且子站難以形成真正獨立身分。 ### 4.2 多租戶平台架構 各子站共享核心 Runtime，但保留自己的設定、資料分區、網域、版型與權限： $$ S_i = \operatorname{Tenant} (B,\theta_i) $$ 其中 $\theta_i$ 是領域專屬配置。多租戶架構的核心不是「所有東西都共享」，而是在共享與隔離之間選擇。Microsoft 的多租戶架構指南指出，共享全部資源與每租戶完全獨立部署分別位於兩個極端，中間需要在規模、隔離、成本、效能、複雜度與可管理性之間取捨。[1][2] 此模式很適合早期母子網站平台：共用爬取、事件抽取、搜尋、帳號與發布 Runtime，同時讓各子站擁有獨立 Domain Pack。 ### 4.3 聯邦式觀測網路 每個站點可由不同部署者、組織或 AI 管理，只透過共同協定交換事件、訂閱與關係： $$ \mathcal{F} = \{S_1,S_2,\ldots,S_n\} + \Pi $$ 其中 $\Pi$ 是聯邦協定。ActivityPub 展示了不同伺服器如何透過 server-to-server federation 分發活動；WebSub 則展示發布者、Hub 與訂閱者如何以分散式發布—訂閱方式傳送更新。[3][4] 這些標準不是本平台必須直接採用的唯一方案，但證明「入口與管理可分散、更新與關係仍可互通」在 Web 架構上是可行的。 聯邦式模式自治性最高，但身分、信任、刪除、版本衝突與跨站品質也最困難。 ### 4.4 混合式架構 早期由一個共享核心管理主要子站，之後允許外部觀測站以 API、事件流或聯邦協定接入： $$ \mathcal{H} = M(B) + \{S_i^{\text{managed}}\} + \{S_j^{\text{federated}}\} $$ 本文認為，這是最符合實際發展的路線： $$ \boxed{ \text{先共享核心} \rightarrow \text{再領域自治} \rightarrow \text{最後逐步聯邦化} } $$ --- ## 5. 共享什麼，隔離什麼？ 母子站設計的核心不是選擇「集中」或「分散」，而是逐項決定哪些能力應共享、哪些必須隔離。 令平台能力集合為 $C$ ，共享函數為： $$ \chi(c,S_i,S_j) \in \{0,1,\rho\} $$ 其中： - $0$ ：不共享； - $1$ ：完全共享； - $\rho$ ：受條件、權限或映射規則限制的部分共享。 ### 適合共用的能力 - 原始來源抓取與快照； - 全域事件識別； - 實體對齊； - 通用時間戳與溯源； - 搜尋基礎設施； - 帳號與訂閱； - 執行日誌與品質監控； - 通用模型與工具調用； - 多語翻譯底座； - 跨站事件關聯。 ### 適合領域隔離的能力 - 來源白名單與黑名單； - 領域本體與分類法； - 重要性函數； - 微、中、宏尺度判準； - 發布模板與語氣； - 敏感內容規則； - 人工審核門檻； - 更新頻率； - 專業術語與在地化； - 領域社群治理。 可將第 $i$ 個觀測站的輸出表示為： $$ Y_i(t) = \Phi \left( B(t), \theta_i, P_i, U_i \right) $$ 其中 $B(t)$ 是共享底座， $\theta_i$ 與 $P_i$ 則保留子站差異。 這樣，同一原始事件可以被 AI 權利站視為「內容授權事件」，被法律站視為「司法判決」，被媒體產業站視為「商業模式變化」，而不需要複製成三個彼此無關的事件。 --- ## 6. 全域事件身分與領域投影 若母站與子站都各自建立事件，最容易發生的問題是：同一事件被重複保存、摘要互相衝突，後續歷史又無法合併。 因此應區分： 1. **全域事件物件**； 2. **領域投影物件**。 令全域事件為： $$ e^{*} = (id,src,time,entities,claims,provenance,versions) $$ 第 $i$ 個子站對它的投影為： $$ \pi_i(e^{*}) = (category_i,scale_i,score_i,summary_i,relations_i) $$ 於是： $$ \pi_i(e^{*}) \neq \pi_j(e^{*}) $$ 但： $$ \operatorname{id} \left( \pi_i(e^{*}) \right) = \operatorname{id} \left( \pi_j(e^{*}) \right) =id(e^{*}) $$ 這個設計保留了兩件事： - **事實與來源可以共用；** - **意義與重要性可以因領域而異。** 它也防止母站強迫所有子站接受單一敘事。母站只保存共通證據與事件關係，不必規定唯一摘要。 --- ## 7. 事件路由：資訊應流向哪些觀測站？ 每一個新事件都可能屬於多個領域，不能只由單一分類器決定唯一目的地。 令新事件為 $e$ ，觀測站集合為： $$ \mathbb{S} = \{S_1,S_2,\ldots,S_n\} $$ 事件路由函數為： $$ \mathcal{R}(e,S_i) = \alpha D_i(e) + \beta E_i(e) + \gamma O_i(e) + \delta H_i(e) + \eta U_i(e) $$ 其中： - $D_i(e)$ ：與站點領域的語意相關度； - $E_i(e)$ ：實體重疊程度； - $O_i(e)$ ：符合領域本體的程度； - $H_i(e)$ ：與該站歷史事件鏈的關聯； - $U_i(e)$ ：對該站使用者的潛在價值。 若： $$ \mathcal{R}(e,S_i)\geq\tau_i $$ 事件便進入該站候選池。注意，進入候選池不等於立即發布。各子站仍使用自己的重要性函數與審核規則。 事件路由應允許： - 一對一：單一事件只進一站； - 一對多：跨領域事件進入多站； - 延遲路由：事件初期未達門檻，後續因新證據升格； - 逆向路由：子站發現事件後，回報母站建立全域事件； - 人工校正：領域管理者修正錯誤路由。 這使平台不是一棵只能向下分支的分類樹，而是一張可以跨域傳播的資訊路由網路。 --- ## 8. 領域自治與共同規格 子站需要自治，否則不同學科會被同一套流行度與分類邏輯壓平。但若完全自治，又可能使資料無法互通。 因此必須區分兩層規格。 ### 8.1 不可省略的共同規格 每個站至少應提供： - 穩定站點識別碼； - 領域描述； - 可機器讀取的來源與更新介面； - 事件識別與版本欄位； - 原始來源與溯源； - 時間與語言標記； - 站點政策與責任範圍； - 跨站連結與引用關係； - 刪除、訂正與撤回狀態。 Web Linking 的關係型連結模型提供了一個基礎觀念：連結不只指向另一資源，也可以明確表達目前資源與目標資源之間的關係。[5] 未來觀測站可以利用類似機制表示： - `derived-from`：摘要源自哪個事件； - `related-domain`：與哪個領域站有關； - `supersedes`：新版本取代舊版本； - `canonical-event`：指向全域事件物件； - `station-home`：指出該投影所屬觀測站。 ### 8.2 可由子站自治的部分 共同規格不應規定： - 哪些來源必然可信； - 哪種事件一定重要； - 哪個理論分類唯一正確； - 哪個摘要是唯一官方解釋； - 每個站必須使用相同更新頻率； - 每個站必須以大眾語言呈現。 因此： $$ \text{互通性} \neq \text{內容同質化} $$ 真正目標是： $$ \boxed{ \text{底層語法一致} + \text{上層領域語意自治} } $$ --- ## 9. 子網域、子目錄與獨立網域只是部署選擇 母子網站概念不應被綁死於單一 URL 形式。領域觀測站可以部署為： ```text ai.example.org example.org/ai/ ai-observatory.org ``` 三者的技術、品牌與搜尋表現各有差異。 ### 子目錄 適合共享品牌、權限、部署與搜尋權重，但站點獨立辨識較弱。 ### 子網域 可保留母品牌關係，又能形成較獨立的站點名稱、部署與索引入口。Google 的站點名稱文件目前以網域或子網域為站點層級，而不把子目錄視為可獨立命名的站點單位。[6] ### 獨立網域 領域自治與品牌獨立性最高，但跨站帳號、搜尋、權重累積與維運成本較高。 因此，觀測站的邏輯身分應獨立於部署網址： $$ station\_id \neq hostname $$ 如此才能在未來遷移網域、拆分部署或加入聯邦時，保持歷史身分不變。 --- ## 10. 正規網址、重複內容與跨站投影 同一事件可能在多個子站出現。如果所有頁面只是複製相同摘要，會同時造成使用者混淆與搜尋索引重複。 因此必須區分兩種頁面： 1. **全域事件正規頁：** 保存共通證據、來源、版本與跨站關係； 2. **領域投影頁：** 解釋該事件對特定領域的意義。 如果多個網址內容實質相同，應指定正規網址；Google Search Central 亦建議大型網站以 `rel="canonical"` 與 Sitemap 告知偏好的正規頁面。[7] 但若領域投影真正包含不同分析、尺度、關係與歷史脈絡，就不應把它們全部誤判為副本。可建立： $$ \text{共同事件核心} + \text{領域專屬增量} $$ 即： $$ Page_i(e) = Core(e) + Delta_i(e) $$ 其中 $\Delta_i(e)$ 必須具有實質內容，例如： - 不同領域分類； - 不同重要性解釋； - 不同相關歷史； - 不同風險與影響； - 不同後續觀察點。 這樣跨站投影才是多視角知識，而不是機械複製。 --- ## 11. 多語言是入口層，不應複製站點身分 AGIRight 的經驗顯示，多語言首先是一種入口擴張，而不是每種語言都立即建立完整的獨立內容宇宙。 令站點內容語意核心為 $C_i$ ，語言呈現函數為： $$ L_{i,k} = \mathcal{T}_k(C_i,\Gamma_i) $$ 其中 $\Gamma_i$ 為領域術語與在地化規則。 不同語言版本應共享： - 同一事件識別； - 同一來源； - 同一版本鏈； - 同一領域站身分。 但可以具有不同： - 標題與摘要； - 術語解釋； - 例子； - 地區相關背景； - 發布優先順序。 Google 對多語與多地區網站建議明確標示不同語言版本，並在相似或重複頁面之間結合正規網址與 `hreflang`。[8] 因此： $$ \text{五種語言} \neq \text{五個重複子站} $$ 而是： $$ \boxed{ \text{一個領域觀測站} \times \text{多個語言入口} } $$ --- ## 12. 訂閱：讓使用者只居住在自己的資訊航道 母子站最重要的使用者價值，不是讓人進入母站後自行篩選，而是允許人直接訂閱特定資訊航道。 使用者 $u$ 的訂閱狀態可以表示為： $$ Sub(u) = \{(S_i,d_i,\ell_i,f_i,\lambda_i)\} $$ 其中： - $S_i$ ：訂閱的觀測站； - $d_i$ ：子領域或主題； - $\ell_i$ ：偏好的尺度； - $f_i$ ：頻率； - $\lambda_i$ ：語言。 例如一名使用者可以只訂閱： - AGIRight 的 AI 法律人格中觀週報； - 程式語言觀測站的型別系統微觀更新； - 氣象站的宏觀模型趨勢月報。 WebSub 的發布者—Hub—訂閱者模式證明，內容更新可以由 Hub 主動分發給已訂閱的接收者，而不必由使用者反覆輪詢。[4] 未來母站可充當統一訂閱協調器，也可允許子站擁有自己的 Hub。 使用者看到的個人資訊流因此不是把所有站點內容混合，而是： $$ Feed_u(t) = \operatorname{Compose} \left( \bigcup_{s\in Sub(u)} TopK_s(t) \right) $$ 並保留來源站與領域上下文，避免跨站混合後失去意義。 --- ## 13. 跨站搜尋與聯邦查詢 母站應提供跨站搜尋，但搜尋不必要求所有資料物理集中於同一資料庫。 可以有三種查詢模式： ### 13.1 中央索引 所有子站把可搜尋欄位同步到母站索引。速度快，但集中度高。 ### 13.2 即時聯邦查詢 母站將查詢分派到不同子站，再合併結果： $$ Q(x) = \bigcup_i Q_i(x) $$ SPARQL Federated Query 的 `SERVICE` 機制提供了跨不同端點執行查詢並合併結果的標準化例子。[9] 對事件圖譜而言，未來可以在不同觀測站端點上查詢同一人物、概念、政策或技術的跨域關係。 ### 13.3 混合式查詢 常用欄位與摘要集中索引，完整事件圖與領域分析保留於子站；需要時再向子站取回。 本文建議早期採用混合式模式： $$ \boxed{ \text{快速中央索引} + \text{權威子站資料} + \text{必要時聯邦查詢} } $$ 這能兼顧速度、自治與擴張性。 --- ## 14. Sitemap 與站點可發現性 大量子站與主題頁若沒有清楚的發現機制，搜尋引擎、外部 Agent 與新加入的觀測站都難以理解平台結構。 每個觀測站至少應公布： - 站點首頁； - Sitemap； - RSS／Atom／JSON Feed 或事件 API； - 領域描述； - 支援語言； - 更新頻率； - 事件與資料匯出入口； - 與母站及相關子站的關係。 Sitemap 協定允許以 Sitemap index 管理多個 Sitemap，並向爬取者提供網址與更新相關資訊。[10] 對母子網站而言，可以形成： ```text mother-sitemap-index.xml ├── station-ai-rights-sitemap.xml ├── station-mathematics-sitemap.xml ├── station-weather-sitemap.xml └── station-language-design-sitemap.xml ``` 但 Sitemap 只處理可發現性，不能取代領域描述與事件關係。未來還需要一份機器可讀的 Station Manifest，至少包含： ```yaml station_id: eml.station.ai-rights parent_station: eml.information-ocean canonical_home: https://agiright.org/topics scope: - ai-rights - legal-personhood - content-licensing languages: - en - zh-TW feeds: json: /topics.json sitemap: /sitemap.xml policies: editorial: /about/editorial-policy provenance: /about/provenance ``` 這將在後續 Domain Pack 與母站—子站技術白皮書中正式規格化。 --- ## 15. 失敗隔離與可退化運作 當子站數量增加，整體系統不能假設每個站永遠正常。 可能故障包括： - 某站來源失效； - 分類模型錯誤； - 排程未執行； - 資料庫延遲； - 翻譯失敗； - 子站被攻擊； - 某個領域規則造成大量誤路由； - 聯邦端點離線。 因此，母子網站必須具備失敗隔離： $$ Failure(S_i) \nRightarrow Failure(M) $$ 理想上： $$ Failure(S_i) \Rightarrow Degraded(S_i) $$ 而其他子站仍繼續運作。 可採取： - 每站獨立任務佇列； - 每站執行預算與速率限制； - 來源熔斷； - 站點健康狀態； - 延遲發布與人工接管； - 快照回復； - 全域事件底座與投影層分離； - 跨站污染偵測。 多租戶架構中特別需要考慮共享基礎設施造成的效能、安全與狀態影響；共享可以降低成本，但必須配合清楚的隔離模型。[1][2] --- ## 16. 母站的權力邊界 母站若掌握全域事件、搜尋、身分與分發，很容易逐漸成為唯一裁判。因此必須明確限制母站權力。 母站可以： - 維護共同格式； - 保存全域事件與來源； - 提供跨站搜尋； - 檢測重複與技術錯誤； - 協調訂閱與路由； - 標示站點健康與政策。 母站不應自動： - 覆蓋子站的領域分類； - 宣稱唯一重要性排序； - 刪除合法但不受歡迎的領域觀點； - 把跨站差異視為資料錯誤； - 以全域熱門度取代專業判斷； - 未經規則便重寫子站歷史。 可以把母站權力表示為： $$ P_M = P_{interop} + P_{integrity} + P_{routing} $$ 而子站保留： $$ P_{S_i} = P_{ontology} + P_{ranking} + P_{narrative} + P_{review} $$ 這一區分將在後續「分類不唯一：多視角秩序、知識主權與可逆分類」中進一步展開。 --- ## 17. AGIRight 作為第一座領域觀測站原型 AGIRight Topics 目前已呈現數個觀測站特徵： - 聚合第三方 AI 本體論、哲學、權利、治理與前沿研究內容； - 以日期、來源與主題標籤組織； - 保留原始來源連結； - 提供搜尋、篩選與 JSON 匯出； - 明確說明聚合內容不等於網站自身立場； - 提供多語入口。[11] 它尚未成為完整自治觀測站，因為目前頁面仍標示為人工整理、尚無爬蟲；但就系統角色而言，它已不只是一般新聞頁，而是： $$ S_{agiright} = \text{AI 權利與相關前沿領域的早期觀測介面} $$ 由此可以抽象出第一批 Domain Pack 參數： - 領域：AI 權利、法律人格、內容授權、Agent 自主性； - 來源：學術、政府、法律、研究機構與專業媒體； - 輸出：每日三則或每日精選； - 語言：先以多語入口擴大可發現性； - 治理：第三方中立聚合與來源回查； - 人機分工：AI 完成主要資訊工作，人類觸發與抽查。 它可以成為母子站技術的第一個實證站，而不是要求一開始就建立涵蓋所有領域的母平台。 --- ## 18. 子站的生命週期 新的領域觀測站不應只靠建立一個網域便宣告成立。可將生命週期分為： ### $S_0$ ：候選主題 只有來源清單與觀察需求，尚未形成穩定輸出。 ### $S_1$ ：主題頁 在既有站內建立分類、搜尋與人工精選。 ### $S_2$ ：半自主觀測站 AI 已能完成來源搜尋、摘要、標籤、翻譯與頁面更新，人類負責觸發與抽查。 ### $S_3$ ：排程自治站 具備 Scheduler、Loop（自環）、Graph、狀態保存、錯誤重試與異常通知。 ### $S_4$ ：領域自治站 能依資訊變化調整來源、分類與更新節奏，並維護領域歷史。 ### $S_5$ ：聯邦觀測站 能與其他母站或外部站點交換事件、查詢與訂閱。 其狀態轉移為： $$ S_0 \rightarrow S_1 \rightarrow S_2 \rightarrow S_3 \rightarrow S_4 \rightarrow S_5 $$ 但不是每個站都必須到達 $S_5$ 。某些小型專業站長期停留在 $S_2$ 或 $S_3$ 仍然具有價值。 --- ## 19. 母子站不是網站農場 大量子站也可能滑向低品質內容農場：以相同模板機械生成大量領域頁面，只為佔據搜尋結果。 因此必須區分： $$ \text{觀測站擴張} \neq \text{頁面數量擴張} $$ 一個新子站成立前至少應滿足： 1. 有清楚且持續的領域差分需求； 2. 有可辨識的來源集合； 3. 有不同於既有站的觀測判準； 4. 有可持續的更新與品質責任； 5. 能向下追溯至原始來源； 6. 能被訂正、停用或合併； 7. 不只是換關鍵詞生成相同內容。 可定義建站適合度： $$ StationFit(d) = \frac{ Need_d \cdot Source_d \cdot Distinct_d \cdot Maintain_d }{ Overlap_d \cdot Risk_d \cdot Cost_d } $$ 只有當： $$ StationFit(d)\geq\tau_s $$ 才值得由主題頁升格為獨立觀測站。 這項約束能防止平台把「資訊海秩序化」誤作「AI 大量生成網站」。 --- ## 20. 從網站群到觀測網路 當子站數量增加，平台的本體逐漸改變。 早期看起來是： $$ \text{一個母網站} + \text{多個子網站} $$ 但成熟後更像： $$ \mathcal{N} = (\mathbb{S},\mathbb{E},\mathbb{P},\mathbb{H}) $$ 其中： - $\mathbb{S}$ ：領域觀測站集合； - $\mathbb{E}$ ：事件、訂閱、引用與路由關係； - $\mathbb{P}$ ：共同協定； - $\mathbb{H}$ ：跨站歷史記憶。 母站只是這張網路中的主要協調節點，不再等於整個系統。 因此最終形態不是網站樹，而是： $$ \boxed{ \text{可聯邦、可查詢、可追溯的領域觀測網路} } $$ 每個使用者可以只進入一個局部領域；每個子站也可以只理解自己的責任範圍；但底層事件與關係仍能逐步構成一張跨領域資訊演化圖。 --- ## 21. 最小可行母子站架構 現階段不需要立即實作完整聯邦網路。最小可行架構可以只有六層： ```text 1. Source Registry └── 來源登錄、抓取與快照 2. Global Event Store └── 全域事件、版本、實體與溯源 3. Domain Router └── 將事件送入一個或多個領域候選池 4. Domain Pack Runtime └── 各站分類、排序、摘要與審核規則 5. Station Publisher └── 子站頁面、Feed、JSON 與多語入口 6. Mother Coordination Layer └── 搜尋、訂閱、站點目錄與跨站關聯 ``` 其基本資料流為： $$ Source \rightarrow GlobalEvent \rightarrow Route \rightarrow DomainProjection \rightarrow StationPublish \rightarrow Subscribe/Search $$ 這已足以支援： - AGIRight 作為第一站； - 未來新增數學、氣象、程式語言或其他領域站； - 共用來源抓取與事件資料； - 各站自行決定每日三則； - 母站提供跨站導航與訂閱。 --- ## 22. 核心命題 本文可以收斂為以下命題： > 當網路資訊海被持續觀測後，資訊的底層保存與人類的注意力入口不應採用同一種集中方式。原始來源、事件身分、版本、實體與跨域關係適合共享；領域邊界、重要性判斷、敘事方式、語言介面與更新節奏則應由不同觀測站自治。母站的作用不是替代子站，而是提供共同記憶、搜尋、訂閱、路由與互通規格；子站的作用不是複製母站內容，而是成為特定資訊航道的長期觀測者。 形式化表示為： $$ \boxed{ \mathcal{N} = M(B,I,Q,R,G,C) + \sum_{i=1}^{n} S_i(D_i,\Sigma_i,O_i,W_i,P_i,L_i,A_i) } $$ 並滿足： $$ \text{共享事件} + \text{領域投影} + \text{獨立入口} + \text{跨站互通} $$ 這種架構同時避免兩種失敗： $$ \text{單一巨站造成的注意力過載} $$ 以及： $$ \text{完全獨立站群造成的知識碎片化} $$ --- ## 23. 與下一篇的關係 母站與子站架構解決了「資訊應從哪裡進入」的問題，但尚未解決「持續累積的事件如何成為歷史」。 即使每個站每天穩定產生三則領域新聞，如果舊事件只是留在頁面列表中，平台仍然只是具有分類的新聞檔案，而不是領域記憶。 下一篇將進一步處理： - 每日事件如何累積為時間序列； - 修訂、撤回與取代如何保存； - 事件鏈如何形成； - 中觀趨勢與宏觀轉折如何由歷史資料重建； - 如何區分「當時的判斷」與「事後重新理解」； - 如何讓領域歷史可查詢、可回放與可重新計算。 因此下一篇為： # 《從每日資訊流到可查詢歷史：領域記憶的累積機制》 --- ## 參考資料 [1] Microsoft, “Architect multitenant solutions on Azure,” Azure Architecture Center. 介紹多租戶架構、租戶定義與隔離模型。https://learn.microsoft.com/en-us/azure/architecture/guide/multitenant/overview [2] Microsoft, “Architectural approaches for a multitenant solution,” Azure Architecture Center. 討論完全共享至完全隔離之間，在規模、成本、效能、複雜度與可管理性上的取捨。https://learn.microsoft.com/en-us/azure/architecture/guide/multitenant/approaches/overview [3] W3C, “ActivityPub,” W3C Recommendation, 2018. 定義 client-to-server 與 server-to-server federation 協定。https://www.w3.org/TR/activitypub/ [4] W3C, “WebSub,” W3C Recommendation. 定義發布者、Hub 與訂閱者之間的分散式 HTTP 發布—訂閱機制。https://www.w3.org/TR/websub/ [5] M. Nottingham, “RFC 8288: Web Linking,” IETF, 2017. 定義 Web 資源之間具語意的連結關係。https://www.rfc-editor.org/rfc/rfc8288.html [6] Google Search Central, “Site Names in Google Search.” 說明站點名稱目前以網域或子網域層級識別。https://developers.google.com/search/docs/appearance/site-names [7] Google Search Central, “How to specify a canonical URL with rel=canonical and other methods.” 說明正規網址與 Sitemap 在大型網站重複網址管理中的作用。https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls [8] Google Search Central, “Localized Versions of your Pages” and “Managing Multi-Regional and Multilingual Sites.” 說明多語版本、`hreflang` 與正規網址。https://developers.google.com/search/docs/specialty/international/localized-versions [9] W3C, “SPARQL 1.1 Federated Query,” W3C Recommendation, 2013；另參考 2026 年 SPARQL 1.2 Federated Query 草案。定義跨不同 SPARQL 端點分派與合併查詢。https://www.w3.org/TR/sparql11-federated-query/ [10] Sitemaps.org, “Sitemap Protocol.” 定義 Sitemap 與 Sitemap index。https://www.sitemaps.org/protocol.html [11] AGIRight.org, “Topics,” accessed 2026-07-31. 領域主題聚合、來源連結、搜尋篩選、多語入口與 JSON 匯出的現行原型。https://agiright.org/topics --- ## 版本紀錄 | 版本 | 日期 | 狀態 | 說明 | |---|---|---|---| | 0.1.0 | 2026-07-31 | 公開初稿 | 建立母站、子站與領域觀測站定義；提出共享核心、領域自治、全域事件與領域投影、事件路由、聯邦查詢、訂閱、可發現性、失敗隔離與最小可行架構。 |