发布于 2026-01-05 23:06:35（微信公众号导出记录）。

本文来自公众号后台的“导出文章内容”功能。博客正文由导出长图进行本地 OCR 转写，并保留原始排版图用于逐段核对。

原文链接：查看原文

OCR 转写有效文字约 2636 字；代码、流程图和版式以文末原始排版图为准。

正文（本地 OCR 转写）​

2025年網际網路状熊與趣勢的報告總結一(基於Cloudflare 資料) originalwθx7ce EI V1ajero 2826年1月5日 23:06 美国 流量與速線流量增景:朝膝铜路流量峰值在2025年期間增長了19% 视觉化分析:透透希爵伯特曲線图,可以直毂地以/28唇级量绑来分析全球IPv4位址的流 量来源分怖。 行動装置:10S装置真献了所有流量中的35%。 传输定:HTTP/3定的探用率持續提升,目前估流量的21% 安全與加密後量子加密(PQ):為了防未来量子電腦的解密攻墅,髓著寶器预设支 援,後量子加密技術的使用量正迅速增长。 由機器人买AI爬登機器人霸主:GoogLeBot是生最高流量的單一經输盘概器人,且 搜毒引擎爬遗整體是流量最大的楼器人類别。 AI爬嘉管理:前一蔓大频域中已有数千個频站透過robots.txt管理AI爬喜,而模型 凯辣:是遗些AI機器人最常见的限取目的。 的任移類别。 熟門模型:@cf/neta/1lama-3-Bb-instruct是目前workers AI上显受迎的模型 開發與市璟生開發語言:Go语言是關API用户端時最然門的通提 市场主源:Google與Chronme分别颗居全球最熟門搜导引擎與测宽器的市场主導地位。 际翔路流量增長翔际路流量峰值增長了19% sInk

網际路服務全球十大热門解際網路服務 Geinsi 已成为 CaIGFT 的主是果街手 - 互E nTik2载·5p

• 老Fa

的名了的 Rurk Sanice #2 Facebsek Acpie

• 4

9 ANS TaTox 3 Mra20 #13

的公可名等·也有一整意想不则的满面托,·愁 Ank sniee Cise Anrhnpic Pegielty CasErA Wisdserf A t7 Quelle 0rok / 0 DMgiek 025年·生成式A 精质保持 保使显据期情 Cisude - Pd 已成耳CGFT阶在更提甲影于-在社般在量活 公可名事,也有一是意想不的的满自托一愁

9.46.81​

Facaboek

K/Tw

#13 Rasddt 组列 Cisude Parpisxity 和 Oea 已级为ChPT的平要装争财于·在社肆情 hae Faco-lgnT12徒ach表x甲台:图在平 Cierlo b

• .84.8

31Y/ux #2 NA 租电话 Twit1 43 44Fsu ETEH Disey Fls #5 Frine Mdes 47 Vinee PlsTV FascTV

• 0 H60/Ms

公司台字,有一业意想不阶的满面于一抽 ovnt 生0G.8I 82ES 代883 B8C a4 NM Foe Mew1 #5

• 7

Dcogia New1 Newtiresk #3 a10tiaresofvea Copr; b 号 1

o Lb #30 AiExprm

价·6e在225年1名 L式.A

ratagam E TaTck 29 - Snp 公司名了·也有一些患原不的周密,·绿

F1 Do.T Xbex LM

±96.8I FeyPe

出时 Goxgle Pay 4130X

生85A

yts

• 10

希留伯特曲線具有獨特的祝覺特性,可用於查察细路的IPv4位址空間。 Cloudflare Radar 使用者可以查看图家/地區或自發系統级的網路流量。同 時,我仍使用希伯特曲線,来全面揭示整個IPV4翻际翻路的流量来源。下面的视 觉化圈瞬示了2025年1月1日至12月2日期前往Cloudflare的 流量,其中IP位址以/20级量德。这意味著在最高缩放架下,每個单元格表示 来自4,096個IPv4位址的流量。

後量子(PQ)指一系列旨在保證加密資料免受「先疑取、後解密攻擎的加密技 術。这些攻的攻擎者能摄取亚储存当前資料,以便將来使用足约先遍的量子電腦进 行解密。Cloudflare研究圆除自2017年以来一直致力於後量子密碼學的研究, 定期發布於後量子網际路發展现的最新进展。2022年18月,我们在期路上 预設敬用後量子金協,但需要测質器也支援謢才能狗使用。髓著测置器预設 用到該功能的支援,我們翻察到其使用量迅透增長。 山

搜导引擎網路爬强是產生最高流量的經验證機器人類别

robots.txt中找到的AI爬最3,879個在前10,000個域中發現的 robots.txt 案

完金月的:/

爬行推萝比率

AI機器人和爬器流量 强是人和期备在202年一是耐受先贴因月它界负梦地明大量人是求不的查最的很查-零错周之界,因内点日

erviajens 依爬取目的劃分的AI機器人流量訓是最常見的爬取目的

Workers AI模型和任務热門程度@cf/meta/Llama-3-8b-instruct Workers AI上最熟門的模型

文字生是Workers AI上最熟P的任務

i0S 奥Android 35% 的流量来自i0S 装置

HTTP 版本21%的流量使用 HTTP/3

以下是示了在2725年程图C:在业用湖求业量中HTT后中况

细站技術主要網站上最热門的技術

API用户端語言熟門度Go是最熟門的运择

.NET 搜寻引擎市場份额Google是全球最熱門的搜寻引擎 用 Cloudflare為数百客户保蘸與加速纲站及應用程式·因此·在衡量搜等引肇市場份额资料方面具有蜀特的優势·我们的方法使 用Referer棵源来嘴别向客户站和鹰用程式傅送流量的搜引擎·搜募引擎市場份额资料以整體量滤形式呈现:以及按装置類 额建结 型和作案系统细分。 如需胞解其他详细資料·請参Cloudflare Radar上的每季搜罪引推兹鞋告。 全球的强募引擎市增份额分件情况 Gogle: 89.5%Bing: 3.1%其他: 2.8%Yandexc 2%Baindu: 1.4%DuckDuckGo: 1.2% Android 00% 桌上型電盾 MacOSX 行動装置 Windows i0s

7月 器市場份额Chrome是全球最熱門的器 共用 Cloudflare為数百客户保露與加速润站及應用程式·因此,在衡量剂意器市場份额方面具有强特的侵势。我们的方法使用 UserAgent和Client-HintsHTTP桥颈中的资訊,来别發出内容請求的测览器以及開略的作莱系统·测竟器市場份额資料以整 独量總形式呈現·以及按装置频型和作案系统细分 如需解更多祥细资料,請参Cloudflare Radar上的每季渤算器市堤份额報告 全球的测置器市場份额分怖情况 %'z 1u Sunwes %C's xpa %9司 %2 a5p3 %s ejes %Z9 :wuo Android 桌上型電器 Sosew 行勤装置 SMopum ios

原始排版图​

发布于 2025-12-27 19:27:08（微信公众号导出记录）。

本文来自公众号后台的“导出文章内容”功能。博客正文由导出长图进行本地 OCR 转写，并保留原始排版图用于逐段核对。

原文链接：查看原文

OCR 转写有效文字约 2179 字；代码、流程图和版式以文末原始排版图为准。

正文（本地 OCR 转写）​

魔墟、弹孔與金塔:老三日深度歷史拼圆 original wex7ce EI V1ajero 2825年12月27日 19:27 中国香港

Primer dia ] 回

(English/ Espan 時間 中文 ol) Wattay Int.Airpo rt 10: u5nn 00 Aeropuerto Intern acional wattay Wat Ong Teu 翁得寺 12: uCsuc 供奉全城最大青铜佛(10)。古代 Templo Wat Ong Te 30 官員宣誓效忠處。 U 因彭寺 Wat Inpeng 5 13: 位於得寺旁。特色爲正面精细的 00 3 Templo Wat Inpeng 玻璃馬脊克拼贴。 Presidential Pala 國家主席府 ce 13: (黛外截)前皇宫,法式布雜兿術 30 Palacio Presidenc 風格。 ial Wat Si Saket 西沙格寺 a#guc 13: 1828年荧城库存古寺。退廊佛像寶 Templo 45 Wat Si Sak nn 石眼珠被挖去,留有空洞。 et Haw Phra Kaew 玉佛寺 14: 原供奉玉佛(现存曼谷)。法式修復 Templo Haw Phra K 30 3 建察,宗教要術博物, aew That Dam 黑塔 15: 00 14世纪佛塔,金箱被遥最軍刮走後 Estupa Negra 30 (Tha 裸需黑色碑石。 (wea 1 MAG Visitor Centr MAG筋客中心 e 16: uMAG (若闻放)展示来爆弹蔡(UX0)清 00 Centro de Visitan 理通程。 tes MAG 凯旋門 Patuxai 16: 30 使用美援機场水泥建造。建罐登顶 Arco de Triunfo 俯瞰中轴線。 (Patuxai) Chao Anouvong Par 昭阿努王公园 k 17: 龈看日落。铜像手指向泰圆,具政 30 Parque Chao Anouv 治墨史离意。 ong

α]

(English/ Esp 時間 中文 anol) Departure 08: 30 Salida Friendship Brid 老泰友馆大橘 ge 09:

第一座跨调公河大槽。截看遗境​

15 a3-a 1 Puente de la Am 口岸奥泰图對岸。 istad 香昆寺(佛像公圆) Buddha Park 10 : mcuCaug 1958年建。水泥雕塑群,含可攀 Parque de Buda 00 爬的「地猫天堂塔及巨型队 (Xieng Khuan) 佛。 Lao Disabled Wo 隆疾女性發展中心 11: 展示布工。支持UXO受害者 Centro de Mujer 30 及疾女性。 Discapacitad es as Visitor COPE Ce COPE防客中心 ntre 14: uCOPE 展示集束炸弹模型及羲肢。含纪 00 Centro de Visit 錄片,了解秘密敢手。 antes COPE Wat Si Muang 西孟寺 15: Cegeuc 香火最旺。供奉「城市之柱」, Templo Wat Si M 6uen 見温综祈福低式。 塔考寺 Wat That Khao 16: CLEULNRNUC Wat That Templo Wat That 15 位於西孟寺旁。特色為户外大型 Khao 白色卧佛。 Wat Sok Pa Luan Wat Sok Pa Luan 瓦索帕墨寺 ceupuguc g cu 6 16: 叢林寺廓,森林派僧侣修行地。 45 C Templo Sok Wat 瑞境凿醇。 環境幽静。 Pa Luang

Tercer dia rx+ https 8/ EV charging x# Hotels BI Gas 口 O Nong Btusk 0 tesln 3 Lao Textile M HONTONG tiane, Laos Lao People/s Army Airport, XHGC+952 ha That Lux BAN NAKHAM mlns ITECC Ma EL qnog ejA 56 min

20.9 km​

Detals 口 New Continue your tip, tap the notification on your phone to get directions

(English / Espan 時間 中文 Clgm ol) Pha That Luang 塔墨 09: Estupa Dorad CciuLnam Gran 國家象徽。金色大佛塔,含赛 00 (Pha That Luan a 塔提王像。 g) History Army Muse 軍隧歷史博物館 um 10: QCeu ULguC 00 户外美軍機残骸;室内巴特 Museo de Historia U 寮洞穴指部還原。 del Ejército Kaysone Museum 凯山·豐威漢紀念館 gumau 11: 15 Museo 紀念現代建國领袖。宏大的社 Kaysone Pho mvihane 會主義風格建筑。 National Muse Lao 老國家博物館(新館) um 13 : 涵蓋史前化石至現代歷史。位 30 220 Museo Nacional 於凱山馆對面。 Laos Lao Museu Textile 老纺博物館 m 15: 私人博物館,傅統木屋,展示 00 C Museo deL Textil 古董織物。 aos 瓦泰艾寺 Wat Tay Yai 16: 位於機場大门旁步行距離。17 Templo Wat Tay Ya 40 世紀古寺,登機前最後停留 i 點。 Int.Airpo Wattay rt ucg 17 : 15 M AeropuertoIntern acional Wattay

• 1CNY~3,000-3,500LAK

原始排版图​

发布于 2025-12-25 21:21:16（微信公众号导出记录）。

本文来自公众号后台的“导出文章内容”功能。博客正文由导出长图进行本地 OCR 转写，并保留原始排版图用于逐段核对。

原文链接：查看原文

OCR 转写有效文字约 5812 字；代码、流程图和版式以文末原始排版图为准。

正文（本地 OCR 转写）​

Google用源A2UI:代理動介面(Agent-Driven Interfaces)的新標弹 originalwθx7ce EI V1ajero2825年12月25日 21:21 日本

生成式 AI在生成文字、医像和程式码方面的表现已蛭相蓄出色。而現在,Google靓為是时 候 AI 用龄生成上下文相鼠的介面(Contextually Relevant Interfaces)了。 GoogleA2UI图除近期正式公开了A2UI專案,旨在與爾發者社群就这種早期段的格式和 置作进行協作。A2UI的設計初表是為了解決来自代理(Agents)的互通性、跨平台、生成式 或基於模板的UI回癌所面整的特定挑载。 透遇A2UI,代理可以生成显適合常前封错情境的介面,將其送到前端匯用程式。Google 圈除表示,他们已在内部多個座品中概建亚使用A2UI,现在希望透通源興社群互勤,以完善 规箱、增加更多传输方式,亚摘展更多的客户端渣染器(Renderers)和整合支援。 A2UI是一低源专案,包含一種針封“可更新、由代理生成的UI进行侵化的格式,以及一 组初始染器。它允許代理生成或填充變富的使用者介面,使其能在不同的主糖愿用程式中额 示,亚由各UI 框架(如Lit、Angular 或FLutter,未来將支援更多)进行渣染。渣 染器支援一组通用元件和/或客户端宣告的自定羲元件,亚將這些元件组合成布局。 值得注意的是,客户端捷有泣染權,董可以將其無缝整合到其品牌的UX中。無输是调器代 理(Orchestrator agents)遗是遗端A2A子代理,都可以生成 UI怖局,这些怖局将作 為訊息安全地傅透,而不是作為可熟行的程式码。 以下是AZUI温染卡片的范例,展示了該技術可以實现的各箱UI组合。 0887 o ferna Qiree Bovd 29

811.8​

Deig1 Suls Prs

21.4 72 63​

核心問题:代理需要學會講UI語言 想像一因旨在助使用者预訂餐廖座位的AI代理。如果是文字的互動,遇程可能相靠笨排 且元侵:

• 使用者:(打字)“汀一银2人的桌子。“

• 代理:“好的,哪一天?”

• 使用者:(打字)“明天。

• 代理:“什鹰時间?“

• 使用者:(打字)“大概晚上7點。“

• 代理:“那時我們没有空位,遇有其他時間吗?“

• 代理:“我行在5:00、5:30、6:00、B:38、9:00、9:38和10:69有空位,这些时

問對您合適竭?” 这種體验既缓慢又低效。更好的融是代理快速生成、或使用一個包含日期远標器、時同造挥 器和提交按钮的單表单。透過A2UI,大型語言模型(LLM)可以小工具目中组合出定装 的UI,為常下的確切任提供图形化、美截且易於使用的介面。 例如,關者可以使用A2UI来组合预訂UI,取代上述基龄文字的来回聊天。下圆展示了餐 愿预訂A2UI表示的一種渲染效果。由於A2UI的設計赋予了前端主械愿用程式對楼式的大 控制權,因此视登呈现上遭有許多其他可能性。 Book a Table at Han Dynasty

Fstyfbe //m 5 e90 口

技術挑:跨越信任界的渲染 業界正进入多代理網格(Multi-agent mesh)的時代。来自Google 的代理正在舆来自 Cisco、IBM、SAP 和 Salesforce 等不同組缴的代理進行对話,以作解决任務。 也是为何 Google 影合多方创建了代理對代理(Agent-to-Agent,A2A)定益将其捐 赠给Linux基金曾的原因:旨在使代理即使在不共享記憶、工具或上下文的情况下也能进行 作。 然向,这福去中心化架橘整生了一信使用者介面整题。 如果代理存在於鹰用程式内部,它可以直接操作视图(例如DOM)。但在多代理世界中,敦 行工作的代理通常是遗握的一它們在後台通行、位於不同的何服器上,基至隔於不同的组。它 们不能直接解碰使用者的UI:它們必须透退發送訊息来满通。 谈歷史上看,渣染来自运端、不受信任来源的 UI 通常意味著發送HTML或JavaScript 亚 鹤其沙盒化(Sandboxing)在ifranc中。這種方法不懂笨重,祝景上往往不速育(以匹 配愿用程式的原生楼式),亚且引入了图鳞安全遗界的福雜性, Google围除意端到,開發者需受一種方式来傅输UI,使其像敏據一样安全,但像程式碍一楼 具有表現力. 解决方案:将UI规視為訊息序列 A2UI提供了一種棵继格式,可以作為结机化输出即時生成,或者用作模板亚填充数值。生成此 回愿的代理可能是遗A2A代理,或者是使用者正在互助的调器,JSON负载(PayLoad) 可以适退A2A、AGUI以及潜在的其他傅输方式获送到客户端。 客户端癌用程式随後使用其自己的原生UI元件进行染。這意味著客户端保留對槎式和安全 性的完全控制椭,有助於確保代理的输出始终感景像是唐用程式的原生内容。 在以下能例中,使用者上傅了一弧照片,一個遗端代理使用Gemini模型来理解它,亚為圆额 客户的特定需求装作了一個定装表单:

01:38 Envision Your Dream Landscape

而在另一個例子中,代理决定回塞一回包含互動式医表的自定元件,以及一图包含Google 地图的自定养元件: RIZZCharts

08 :

核心設計哲學:安全、可更新且解耦 A2UI的設計圍鳞著機固键原别:

• 安全至上(Securityfirst):敦行由LLM生成的任意程式碼存在重大的安全凤隙。

A2UI探用宣告式资料格式,而非可敦行的程式碼。客户端匯用程式维護一個受信任、预先 批准的 UI元件目錄(例如Card、Button、TextFieLd),代理只能求渲染該目 中的元件,这有效降低了UI注人和其他漏润的风傲。

• LLM友善且可增量更新(LLH-friendly and increnentally updateable):UI

被表示為带有ID参照的扁平元件列表,這键岭LLM增量生成,允許渐进式流染和馨鹰式 的使用者锂验,代理可以根據到話进展中的新使用者请求,有效地划UI进行增量更改。

• 框架無酮且可撼(Framework-agnostic and portable):A2UI 筹 UI结横买

UI實作分開。代理發送的是元件樹及其期账資料模型的描述。客户端應用程式负青将這些 抽象描述映射到其原生小工具-渝是Web Components、Flutter 小工具、React 元 件、SwiftUI視图還是其他框架。来自代理的同一個A2UIJSON负载可以在標建於不同 框架之上的多他不同客户端上清染。 TheEnd-to-End DataFlow Ciar: Seret e

1. 35E Cineeition D9U7R 3toan​

9uraoeipdee hedta d(dtaollt.

1.tngrkodeing​

Ciaet-GicaRasdeig eplictsigral prrverts afashc atormded

5.Ur t​

6. serdictlar’(/a N​

cantructsa'eriktla'pyload. .ts perne A2 Et. vrajero 導實代理式UI(AgenticUI)生態系統 代理式UI的领域正在迅遗發展,各種工具唇出不窟。Google匿账韶为A2UI 不是现有框架 的替代品,而是一理享門的定,旨在解决互通性、跨平台、生成式或基於模板的回惠运一特定 同题。 為了鼠助润發者選环正班的工具,Google整理了以下生慧系统地置:

1.横建主機應用程式UI​

如果您正在椭建一個全接愿用程式(即使用者互動的「主提;UI),除了標建實原介面外,還可 能利用框架(如 AG UI、Vercel AI SDK、GenUI SDK for Flutter,後者底唇已使用 AZUI)来虚理状同步、聊天配和輸入虚理等“管道:工作。

• A2UI的定位:AZUI是互铺的。如果使用AGUI速接主機匯用程式,它可以將A2UI

用作数撼格式,来染来自其不控制的外部代理(以及主機代理)的回愿。这提供了雨全其 美的方案:一他墨富、有状感的主概愿用程式,同時能安全地渣染来自外部代理的内容。

• 奥A2A结合:可直接透過A2A定發送到客户端前端

• 奥AGUI结合:AGUI 提供了支架,可轻疑横建和部置支援A2UI的鹰用程式。

• 其他德输:REST等其他传输方式在技術上可行,但官方暂未提供直接支援。

2.UI作為「资源:(MCPApps)​

模型上下文協定(MCP)最近推出了 MCP Apps,运是一图整合了 MCP-UI 和 OpenAI工作 的新標准,旨在使何服器能翔提供互勤式介面。这種方法將UI視為一種资源(透過 i://URI 存取),通常在沙盒化的iframe中渲染预建 HTML 内容。

• A2UI的區别:AZUI 探用「原生優先:的方法,與MCPAPpS的資源獲取模型截然不

同,A2UI代理發送的是原生元件的蓝图,而非不透明的HTML负载,这允許UI完美 承主械愿用程式的様式和無障碳功能。在多代理系统中,器可以輕整理解醒量藏的 AZUI息内容,實现更流幅的協作。

3.特定平台生系統(OpenAIChatKit)​

像ChatKit运機的工具提供了高应整合、優化的验,專門用於在OpenAI生服系统内部署 代理。

• A2UI的區别:A2UI專為希望跨Web、FLutter 和原生移勤端碍建自已代理介面的

者设計,或用於需要跨越信任遗界通訊的企堂细格(如A2A)。AZUI客户端捷有更多 样式控制權,这整然牲了代理的部分控制,但损来了关主機惠用程式更高的视景一致 性。 黄際應用案例舆合作影伴 A2UI开發初期就具Google内部及外部的多個图隙合作,旨在解決现實世界的同题。以下 是频他期键的合作案例: AG UI/ CopilotKit Google強调了生感系作的重要性。AG UI/CopilotKit墨球與Google 合作硅保 了首日相容性(day-zero compatibility)。 代理-使用者互勤定(AG-UI)通接了代理微端和代理前端...AG-UI完全支援 A2UI规箱,用於代理勤慧生成的豐富宣告式生成UI。我们很高典能提供AG-UI和 AZUI 之的首日相客性。 -Ata1 Barkai,CopitotKit 和 AG UI 魁始人 Opal:疆動實验性AI迷你愿用程式 Opal是一图接使用者用自然語言椭建AI迷你癌用程式的平台。Google的Opal黑原是 A2UI的核心员戴者,亚将其用股快速原型設計及整合到核心标建流程中。0pal中的A2UI 旗使用者能橘建具有勐题、生成式UI的感用。 『A2UI是我們工作的基。它給了我們靈活性,镶AI以新颖的方式動使用者體驗, 而不受固定前端的限制。」-DimitriGlazkov,Opal團隧首席工程師 GeminiEnterprise:企業代理的自定羲UI GeminiEnterprise正在整合A2UI,以允許企業代理在其主機鹰用程式中渲染豐富的互動 式UI,資料输入表單到塞批儀表板,加速工作流程自動化。 Flutter:多平台生成式UI FLutter及其GenUISDK利用A2UI作為遠端伺服器端代理與應用程式之間的UI宣告 格式,助開發者生成符合品牌指南的動態UI。 『A2UI非常適合FLutter的GenUISDK,因為它確保每個平台上的每位使用者都能 獲得高質量的原生感覺體驗。」-VijayMenon,Dart工程總 AIPoweredGoogle:標灌化代理式UI 随著Google全面探用AI,A2UI為内部團隧提供了一種標化方式,AI代理交換使用 者介面。這使得内部構建的代理能輕在外部公開(如在GeminiEnterprise中)。 如何開始:試用A2UI 對於想要深入了解的開發者,最佳方式是親自操作。 首先,可以访問a2ui.org阅請快速入門指南和文件。接著,可以前往GitHub專案中 的samples資料夹,营試客户端UI和後台例代理(例如餐搜导器)。 以下是動餐搜导器例的步骤: git clone https://github.com/google/A2uI.git export GEMINI_API_KEY="your_gemini_api_key" 4#通行餐廊搜导器A2A代理 5 cd A2uI/samples/agent/adk/restaurant_finder 6uv run. 8#運行使用A2UIlit渲染器库的Lit客户端 9 cd A2UI/samples/client/lit/shell npm install 10r 11 npm run dev

此外,也可以透過試用GenUISDKforFLutter来體驗A2UI,或者使用CopilotKit 提供的公開 A2UIWidgetBuilder。 支援的整合 目前該專案已摊有多個關鍵整合,Google也表示未来希望支援更多整合,亚歡迎社群獻。 Communication Client libraries Agent frameworks Agent UI toolkits protocols Web Components CopilotKit (AG UI) Any agent with A2A via the A2A Extension A2A Extension Open AI ChatKit Flutter ADK Plugin (soon) AG UI Iintegration Anguar Vercel AI SDK UI REST uag React Websocket LangGraph ShadCN Crew AI MCP SswitUI AG2 Jetpack Compose Claude Agent SDK Microsoft Agent Framework AWS Strands Agent

展望未来 這是A2UI的第一個公開里程碑。目前的格式版本為V0.8,經過了多輪實戴测試,但仍有演 進空間。目前已提供FLutter、WebComponents 和AnguLar 的早期客户端库。 随著專案开源(Apache2授權),GoogleA2UI團隧邀請生態系統共同参與:

• 完善和演進格式。

• 将A2UI連接到更多客户端库。

• 橘建更强大的工具和演示。

有興趣的開發者可以查看其公開路線圖,了解專案的未来方向。 本文内容基於GoogleDevelopersBlog官方公告整理。

原始排版图​

日期：2025 年 12 月 15 日 來源：Google A2UI 團隊 編譯/整理：[w0x7ce]

生成式 AI 在生成文字、圖像和程式碼方面的表現已經相當出色。而現在，Google 認為是時候讓 AI 用於生成**上下文相關的介面（Contextually Relevant Interfaces）**了。

Google A2UI 團隊近期正式公開了 A2UI 專案，旨在與開發者社群就這種早期階段的格式和實作進行協作。A2UI 的設計初衷是為了解決來自代理（Agents）的互通性、跨平台、生成式或基於模板的 UI 回應所面臨的特定挑戰。

透過 A2UI，代理可以生成最適合當前對話情境的介面，並將其發送到前端應用程式。Google 團隊表示，他們已在內部多個產品中構建並使用 A2UI，現在希望透過開源與社群互動，以完善規範、增加更多傳輸方式，並擴展更多的客戶端渲染器（Renderers）和整合支援。

A2UI 是一個開源專案，包含一種針對「可更新、由代理生成的 UI」進行優化的格式，以及一組初始渲染器。它允許代理生成或填充豐富的使用者介面，使其能在不同的主機應用程式中顯示，並由各種 UI 框架（如 Lit、Angular 或 Flutter，未來將支援更多）進行渲染。渲染器支援一組通用元件和/或客戶端宣告的自定義元件，並將這些元件組合成佈局。

值得注意的是，客戶端擁有渲染權，並可以將其無縫整合到其品牌的 UX 中。無論是協調器代理（Orchestrator agents）還是遠端 A2A 子代理，都可以生成 UI 佈局，這些佈局將作為訊息安全地傳遞，而不是作為可執行的程式碼。

以下是 A2UI 渲染卡片的範例，展示了該技術可以實現的各種 UI 組合。

发布于 2025-12-10 23:38:59（微信公众号导出记录）。

本文来自公众号后台的“导出文章内容”功能。博客正文由导出长图进行本地 OCR 转写，并保留原始排版图用于逐段核对。

原文链接：查看原文

OCR 转写有效文字约 2631 字；代码、流程图和版式以文末原始排版图为准。

正文（本地 OCR 转写）​

数位音訊的權衡:取样率與位元率

在数位音讯系统(DigitalAudio Systen)的聚設计與工程實践中,**取样率(Sample Rate)與位元率(Bitrate,又橘碼率)**是雨因最基碰常被混淆的参敏。初学者往往存在

一種综性患维的运患一超为取槎率越高,最缺的楼案體精必然越大。然而,在现代有損音訊缩碼​

(如Opus、AAC、MP3)的架標下,这種知存在蹦著的偏差。 SAMPLE RATEVS.BITRATE THEENGINEERINGBALANCE DIG/TAL AUDIO ARCHITECTURE SAMPLERATE (TME SLICES)

MATCHED! BITRATE

本文将资讯理(Information Theory)讯號虚理(SignalProcessing)的角度, 到析道雨個必數的物理意裁、敏學厕係,亚推尊在不同频宽限制下,如何計算亚還摆最佳的「取 様率舆位元率组合。

第一部分:物理定羲的本買差巽​

要理解雨者的關係,首先必须將原始訊取,與“號傅輸编码:两固腊段解耦。

1.取率(f。):時間的離散化解析度​

取率定差了系统捕捉整音讯號的時間精度;。根香晨-亲蜜斯特取檬定理(Nyquist- ShannonSamplingTheorem).取模率决定了系統能痫記錄的最高音訊频率(fmaz)。 f。 fnax =

• 8kHz取樓率:對愿4kHz频宽(傅辨電話音質,人聲频错被截断)。

• 16kHz取樓率:到愿8kHz频宽(宽频語音Wideband,人聲清晰度标华)。

,44.1kHz取樓率:對磨22.05kHz频真(振蓝人耳魏景限,CD音置)。 输:取槎率决定了音訊的频错實度(Bandwidth),即驾音的「频率上限:,

2.位元率(BR):資訊的傅输通量​

位元率定裁了编码器在单位時司内输出的瓷料量大小,在有损墅销演算法中,位元率是工程師人 為設定的「容器大小, Data Size = BR × t 结:位元率决定了音訊的存恤精和傅輸频實估用。

第二部分:墅縮比與資訊密度的計算​

在原始PCM(PulseCodeModulation,膳衢编碼整)蘑段,取様率硫實直接决定了體 稿。但在通编碼器(如0pus)坚缩後,體福控制權完全交接给了位元率。

1.原始PCM流量計算​

假設音訊格式為罩聲道(Mono)、16-bit位元深度(BitDepth): PCMgR = f, × BitDepth × Channels 对16kHz 取楼率: PCMgr = 16, 000 × 16 × 1 = 256, 000 bps ≈ 256 kbps

2.缩後的流量計算​

若编码器目標位元率設定為16 kbps,则此時的驱瘤比(Compression Ratio,CR) 為: 256 kbps CR = 16 : 1 關键推瞻:一旦编码器的目標位元率(BRtargr)被镇定(例如镇定在16kbps),無输翰入 源是16kHz 還是48kHz,输出的樓案體是完全相同的。

第三部分:取檬率舆位元率的最佳匹配策略​

既然翰出證精固定,為什廖不能是使用最高的取檬率(如48kHz)来得最好的音置? 这性引l入一因雨键指标:每兹位元数(BitsPer Hertz)或单位取様資鼠量。 如果位元率极低(容器很小),强行使用高取率(装入的資料量很大),编碼器為不得不丢 大量细的以维持资料流医定,增致医量的量化離訊(QuantizationNoise)和频普缺失, 遗種现象榻為「位元圆乏,(Bit Starvation)。 匹配計算模型 為了保退音質,我們需要確保每一帕(Frane)音讯分配到足钩的位元数来摇述波形。 場景A:低位元率傅输(BLE/IoT)

• 目楼位元率:8kbps-16 kbps

• 計算對比:

■方案1(蜡模):使用44.1kHz取槿率,位元率16kbps. 16000 Bits per Sample = ≈ 0.36 bits 44100 解析:每個取楼贴只有9.36惩位元来描述,细節完全丢失,驾音出现服重的“金属 音,和模期感)。

• 方案2(正確):使用16kHz 取檬率,位元率16kbps.

Bits per Sample = = 1.0 bit 16000 解析:每個取楼黏有1個位元,整然不多,但足以建橘清晰的語音输廓。 場景B:標華語音通讯(VoIP/對講機)

• 目楼位元率:24kbps-32kbps

• 推藏取樓率:16kHz[W1deband)

• 理由:32kbps下配合16kHz,每取様贴可得2bits的資訊量,能完美遗原人整

的厚度和清晰度,且没有餘的高频进讯 场景C:高傅真音操(Streaming/Hi-Fi)

• 目楼位元率:>96kbps

• 推藏取樓率:44.1kHz或48kHz

理由:當管道足宽(位元率足高)時,才有能力去承载高取樣率带来的20kHz高 資訊(如樂器的泛音、空氣感)。

第四部分:工程選型参考表​

在實際嵌入式開發(EmbeddedSystem)或串流媒體架構中,應遵循以下「位元率-取樣率」 匹配梯,以實現**品質/體比(Quality-to-SizeRatio)**的最大化。 目標位元率 推薦取檬 音訊類型定 (Bitrat 物理原因分析 率(fs) 羲 e) 窄語音 位元率極低,必须削减高频資訊(放案4k 8kHz (Narrowba 以上频率),集中位元描述基語音基频,防 2 kbps nd) 止破音。 黄金平衡點 宽語音 16 kbps - 。0pus在此區間效率最高。16k取樣率刚 16 kHz (Wideban 好覆蓋人聲泛音,且16kbps足以支撑無損 (p 感的编碼。 如果是純語音,維持16kHz可獲得極高訊噪 32 kbps- 超宽(Su 16 kHz / 比(SNR);如果有背景音樂需求,提升至3 per-WB) 32 kHz 2kHZ。 96 kbps - 全带(Fu 位元率充裕,可以開始追求20kHz的高频 128 kbps /48kHz 細節。 llband) 48 kHz / 發燒級(Au 320 kbps+ 遗際效應退减,追求極致的波形還原度。 96 kHz diophile) 總結 在数位音訊工程中,位元率(碼率)决定了檔案的大小,而取檬率决定了在給定大小下,我們是 遥選「更宽的频率響應圍,遗是「更精的波形描述」。 對於16kbps這類低位元率應用(如蓝牙BLE傳輸),盲目追求高取樣率(如44.1k)不 仅不會减小體,反而會因為「位元乏」導致音質劣化。因此,16kHz取檬率搭配16kbps 位元率,是基於資訊理與心理聲學計算出的、針對語音傳輸的最佳工程解。

原始排版图​

发布于 2025-11-22 23:07:52（微信公众号导出记录）。

本文来自公众号后台的“导出文章内容”功能。博客正文由导出长图进行本地 OCR 转写，并保留原始排版图用于逐段核对。

原文链接：查看原文

OCR 转写有效文字约 5971 字；代码、流程图和版式以文末原始排版图为准。

正文（本地 OCR 转写）​

original wex7ce EI V1ajero 2025年11月22日 23:08 中国香港 这是一份根摊官方文件整理的Gemini3完整开發指南,本指南涵蒸了模型介绍、核心新功能 (如思考層级、思维签章)、Python/Node.js/REST API的完整調用箱例,以及遵移與最 佳實晚。 Genini 3是Google目前显强大的模型系列,專為进腐推理、代理工作流程[Agentic Workflows)和褪離的多模感任移而設計。

1.模型概舆定價​

Genin13目前提供雨個主要预質版模型。 输入俱格(每百 输出俱格(每百 知撒截止 模型ID(model) 通用場景 Token) 高Token) 12(<=200k) 2(<=200k) gemini-3-pro-p 2025年 推理、编 review 碼、多模舰分析 1月 4 (>280k) 18 (>208k) gemini-3-pro-i 2025年 图像生成奥编 $0.134/張 $2(文字输入) mage-preview 租、文字科图像 1月 (图片输出) 基本规格:

• Context Window(服窗口):109萬Token(输入)/64kToken(输出)。

• API版本:建使用VlaLpha或vlbeta以携取显新参数支援

2.核心新功能解​

Genini3引l入了三图厢键的新参数,这與善版模型(如Gemini1.5/2.5)有很大不同。 A.思考層级(thinking_level) 控制模型在回愿前的推理深度:。注意:請勿奥蓄版thinking_budget混用。

• ow:速度快、成本低。遗合篇单指令、聊天或高春吐量度用。

• high(预段):深度推理。模型會花更多時“思考:以產出高品置结果。

B.媒體解析度(media_resolution) 控制输入医片或影片的虐理精组度。运窄影署Token用量與磁别细前的能力。

• medla_resolution_Low:適合—般影片助作罐剧。

• medla_resolution_nediun:適合一般文件理解(PDF)。

• media_resolution_high:適合密集文字(OCR)或需要滋别片微小细即的场景。

• Token 用量:图片显高1120 tokens(High),影片每帕最亮 286tokens。

C.温度(temperature) 量要建:保持预設值1.0。Gemini3的推理能力已针封预设值優化,降低运度(例如设 为0.1)可能會導致模型陷入退图或推理能力下降。 D.思維签章(thoughtSignature) 遍是一個加密的字申,代表模型的内部思考透程。

• 用途:在多输到活、函式呼叫(FunctionCalLing)或像端辑中维持上下文。

• 规则:你必须将徙API收到的thoughtSignature原封不勤地在下一次請求中儒回给

模型,否则會报錯(HTTP 4BG)或幕致智力下降。

• SDK 自動虚理:如果使用官方 Python/Noce.js SDK 排癌 Chat History,SDK

會自動虚理。RESTAPI需手肋虚理。

3.基確文字生成與推理例​

以下展示如何調用Gemini3逾行程式碼分析或推理任務。 Python (google-genai SDK) Teu5 1uodut #166 uo fron google.genai inport types client = genai.Cllent (api_key=YoUR _API_KEY) response - client.nodels.generate_content( ',mataud-od-c-Tuusb,=lapou contents="找出温段 C++程式码中的RaceCandition:[在此贴上程式码]", config=types.Generatecontentconfig( 段定思考雁级(预股為high) thinking_level="high, 保持湿度码1.0 temperature=1.0

print (response.text) JavaScript / Node.js (@google/genai SDK) inport { GoogleGenAI } fron *egoogle/genai°; const ai = neM GoogleGenAI{{ apiKey: "YOuR API KEY- }); async function run(} { const response = await ai.models.generateContent({ conteats:“解耀量子病的源理。就曾霞是五小孩一檬。。 }:u thinkingLevel:“low,//需單任務使用lov以额省感本 }, }1; console.log(response.text); run () ; REST API (cURL) curl "https://generativelanguage-googleapis.con/vlbeta/models/genin1-3 ,uos/uotne3T1dde :ad-1uauo. H- X P05T\

• d

"contents*:[{ “parts":【(“text":“适段Python 代码有什磨谱在的資安风险?"}] }1, "generationconfig": { "thinkingLevel": "HIGH"

4.多模態:圆片理解與解析度控制​

使用media_resolution来控制如何端取图片。 Python fron google inport genai fron google.genal Inport types inport base64

假超你有 inage_data (bytes) 顾取图片通辑 response = client.nodels.generate_content( nodel="genini-3-pro-preview*, contents=[ types.Content( parts=[ types.Part{text=值摄片的票金额是多少?), types. Part( Inline_data=types Blob( mime_type="inage/jpeg*, data=base64.b64decode(YOUR_BA5E64_STRING), ), 段定高解析度以造行精殖OCR nedia_resolution-{"level*: *nedia_resolution_high"

1se , text) REST API curl "https://gencrativelanguage-googlcapis.con/vlalpha/modcls/gcnini- 1,uos /uotet1dde :ad1-uaqu0, H-

• X POST \

).p 1:,s1ua100 "parts#: [ {“tcxt”:“描述这强国片的细”}, { "inlineData": { "nincType": "inage/ipeg", "data*: "BASE64_ENCODED_IMAGE_STRING* }。 "nediaRcsolution':{ "level': "media_resolution_high"

5.结構化输出(JSONMode)與工具使用​

Gen1n1 3 支援透遥 Schena 定羲格的 JSoN 输出,亚结合 Google Search 工具。 Python (Pydantic 整合) fron google 1mport gena1 from pydantic inport BaseNodel, Field fron typing inport List 定兼输出的资料结情 class MatchResult(BeseModel): winner: str = Fleld(description="者名辑") scorers:List[str]= Field(description==得分球具名单*) client = genai.Client (api_key=YoUR API KEY) response = client.nodels.generate_content( nodel="genini-3-pro-preview, contents="强导最新的欧洲杯法薇结果。“, conf1g={ 款用Google搜导工具 "toals*: [{"google_search: 0}], 播定赖出格式J50N整定Schema "response _nime_type': application/json, "response_json_schema*: MatchResult.nodel_json_schema(),

睡频益臀换结果 result = MatchResult.model_val.idate_son(response. text) print (result) JavaScript (Zod 整合) Teuab/abooa, wo { Ivuagoboo ] lodut inport {z } fron *zod"; iszuayos-us[-ui-paz, uo ruauosuosoipoz ] rradu const a1 = new GoogleGenAI{f apiKey: "YouR_API_KEY- }): const matchschena - z.object({ score: z.string(), async function run(){ const responsc = await ai.models.gencratecontent({ ',naTAeud-oud-E-Tutuab, :lapou config:{ tools: [< googlesearch: {} }1. responseMineType: "application/jsun", responseJsonschema : zodToJson5chcma (natchschena), }, }1; console. Log(response.text) ; run () ;

6.圆像生成(Gemini 3Image)​

使用gemini-3-pro-image-previev模型。支援原生4K、生成文字(如招牌、国表),亚 可适過GoogleSearch確保生成内容符合事贰(例如:即時天氯圈)。 CURRENTWEATHERINTOKYO,JAPAN WEDNESDAY,NOVEMBER19,2025-8:49PMJST 19, 2025 - 8:49 PMJST

CURRENTLY:CLEAR 46°F 8C FEELS LIKE 8°C FEELS LIKE 46°F PRECIPITATIONCHANCE:10% HUMIDITY:66% WIND:CALM 3-DAYFORECAST FRIDAY (NOV 21) ( TOMORROW(NOV20) 13°C/55F High: 14°C/57°F High: 17°C/63°F 4°C/39°F 5°C/41°F 6°C/43°F Low: Chance of Rain:10% 公hceRa Chance of Rain:20% Python例 from google.genai import types client = genai.Client (api_key="YoUR_API_KEY") response = client.models.generate_content( contents="生成一张目前束京天氣的祝觉化資訊国表,包含温度數握。" config=types.GenerateContentConfig( 使用搜导工具取真實数據 tools=[{"google_search": {}}], image_config=types.ImageConfig( aspect_ratio="16:9", 13 image_size="4K"#原生4K支援

1. 4​

.5 16 )) #存圆片 for part in response.candidates[θ].content.parts: if part.inline_data: import base64 2 1 img_data = base64.b64decode(part.inline_data.data) with open("tokyo_weather.png", "wb") as f: f.write (img_data)

7.進:手動處理思維章(ThoughtSignature)​

注意:如果你使用RESTAPI或自定義的對話管理,你必须手動傅退thoughtSignatur e。 流程説明: L.Request1:使用者發送提示。

2.Response 1:模型回傅text以及thoughtSignature(通常在candidate 的内​

容中)。

3.Request2:使用者發送新提示,必须在contents的歷史訊息中包含上一次模型回傅​

的thoughtSignature。 退移提示:如果你要將蓄模型(如Gemini1.5)的歷史記錄逻移到Gemini3,由於蓄模型 没有章,你可以使用以下占位符来续過验證: "thoughtsignature":"context_engineeri ng_is_the_way_to_go"

8.移指南與最佳實(MigrationGuide)​

Gemini1.5或2.5升级時請注意: L.簡化提示(Prompt Simplification): 技巧。

• Gemini3已經會自動進行深度推理。過度指導反而會降低效果。

• 做法:直接下達清晰、簡漯的指令。

2.重置温度:​

調低温度。

3.PDF 奥OCR:​

• Gemini3的PDF處理预設解析度可能與蓄版不同。如果發現讀取文件效果不佳,請

顯式投定media_resolution:“media_resolution_high"。

• 注意:這會增加Token消耗。

1.語氣調整:​

• Gemini3预設倾向於簡潔、直接的回答。如果你需要它變得「健谈或「親切」,請

在SystemInstruction或Prompt中明確要求(例如:「請以親切且健的語氣 回覆:)。 (FAQ) 常見問题

• 有免費?API目前没有免費層,但在GoogleAIStudio中試用是免費的。

• 支援BatchAPI?支援,可用於大量非即時處理以節省成本。

• 支援ContextCaching?支援,當输入Token超過2,048時可用快取。

這份指南涵菱了開始使用Gemini3所需的關鍵知識。建先 thinking_level="hig h"開始體验其推理能力,再根據需求調整至Low優化成本。

原始排版图​

发布于 2025-11-07 21:32:45（微信公众号导出记录）。

本文来自公众号后台的“导出文章内容”功能。博客正文由导出长图进行本地 OCR 转写，并保留原始排版图用于逐段核对。

原文链接：查看原文

OCR 转写有效文字约 4535 字；代码、流程图和版式以文末原始排版图为准。

正文（本地 OCR 转写）​

original wex7ce EI V1ajero 2825年11月7日 21:32 中国垂港 搞RAG(機索增强生成)很麻。 NOSr File Search in Sf Gemini API PDF Python

Gemin1 API 现在直接内建楼案搜辱工具:(F1le Search Tool),把整食索流程全包 了。者不用再烦棉鳍存、切现(chunking)、生成嵌入[embeddings)或助注入 上下文。要心做盈品就好。 遗是一個全托管(fully managed)的RAG系统,直接整合在API狸。目標是 Gemin1 回癌的内容更弹础、更相廊,亚且可验證。

File Searsh in Geminr-API

核心侵势:RAG流程全自動化 適图工具商化了整低開發工作流程。

• 整合验:樓需存、最佳切魂策略、嵌入生成,到最後把核索到的上下文勤慧注人提示

(prompts),全部自動處理。它就在现有的 gcncratccontcnt API 内谨作,激入非常

• 强力向量搜导:背後是Google最新的GeminiEmbedding模型。它使用向量提辱来

理解用户查韵的“語意和“上下文」,而不堡堡是比刿關键字。

• 内建引用功能:模型的回答會自動包含引用(c1tat1ons)。清楚標示哪些答案是你上

傳的概些文件中提取的,化了事實验调的步骤。

• 支援多種格式:可以用来建立知游虚的檔案格式很多元,包括PDF、DOCX、TXT、JSON,

以及多常見的程式括言增案(例如.py,.js..cpp等)。 谨作原理:語意搜导 File Search使用的技術稀為語意搜辱(semanticsearch)。 與傳统的關键字搜寻不同,語意搜导能理解查询背後的意差!。 通作流程大致如下:

1.索引(Indexing):當增案被匯人時,系统會自将其轉换爲為「嵌入」​

(embeddings)的数值表示,這些嵌入捕捉了文字的語意。接著,嵌入被存在一但專門 的檔案搜导資料(FileSearchStore)中。

2.查询(Querying):常用户提出問题時,这個同题本身也舍被聘换成一低嵌入。​

3.比(Retrieval):系统他在这调资料重中執行报辱,找出买“同题嵌人;最相似、最​

相默的「文件區瑰依入」。

1.生成(Generation):这些相的文件显块雷被作上下文(context),速同原始司题​

一起提供给Gemini模型,模型窗基龄些「根擦:来生成显终答案。​

如何使用:建立到查詢

1.管理 FileSearchStore​

Filescarchstore是储存文件嵌入的容馨。 重點:透遇F1le API上傳的原始窄在 48小時後被目除,但疆入到Filesearchstor 中的资料(嵌入)是永久存的,直到手勤刑除。 可以建立多個stores 来组截文件。 fron google inport genai 1nport time client = genai.client() #1. 建立一留 store (可遇 display mame) filc_scarch_storc = client.file_search_stores.crcate[ config={'display_name': 'my-docunent-store }

122.列出所有的 stores​

for store in client.file search stores.list(): print(store) #3.取得特定的store ny_store = client.file_search_stores get(nane=filc_search_store.nane) client,file_scarch_stores,delete(nane=file_search_store,nane, config={

2.上傳匯入檔案​

有雨種主要方式: 方法一:直接上傳匯入(量推)使用upLcad_to_file_search_storeAPI-次完成。 得超 store 已级建立 store_name = file_search_store.nane 上傅益重人案,提供一個dispLay_nane 鲁在引用中额示 operation = client. flle_search_stores.upload_to_f1le_search_store( file='path/to/your/document-,pdf*, f1le_search_store_name=store_nane, config={ display_nane':‘my-unique-doc-name-pdf",#这需名都會题示在引用中

等待操作完应 while not operation.done: print("指案虚理中...") time sleep(5) operation = cllent operations.get(operation) rat1on) print["橙累素引完成。") 方法二:先上傳權案,再手助匯入如果你需要先建立F1Le物件,可以分开操作。 #1.先用 Files API上傅榴案 sanple_file = client,files,upload( flle='path/to/sanple.txt', config={'nane':'unique file name for citation'} 网标, 适 name 鲁 #2. 理立 store file_search_store = client.file_search_stores.create[ {auois-Jauno-Au, :aweuAedstp.-buos

3. 将已上何的 f1le 人 store​

operation = client file_search_stores.inport_file[ file_search_store_namc=file_scarch_store.nane, flle_nare=sanple_file.name 用上—S的 f1lc mame 等特操作完证 while not operation.done: time,sleep(5) operation = client.operations get(operation)

3.查詢模型​

在generateContent 呼叫中,将FileSearch常作 tool傅速。 針数期才上停的文件提罚 response = client.nodels .generate_content( nodel="genini-2.5flash*, # 或 gomini-2.5-pro contents=***Can you tell ne about Robert 6raves"" config=types GenerateContentConfigf tools=[ types.Tool( file_search=types.File5earch( filc_scarch_store_nanes=[filc_search_store.nane]

print (response.text) 取得引用来源 grounding = response cand1dates[0] grounding_netadata sources = {c.retrieved_context.title for c in grounding·grounding_chun print[*引用来源:',*sources) 進控制

1.自訂切魂(Chunking)​

预設會自勤切境,但可以自訂策略。例如,設定每個區增的最大token数和重叠token 数。 operation = client.file_search_stores.upload_to_file_search_store(

• 4x*!/na/o1/4ed,==1!

config={ ',1x1'oop-paxunus, :,aueu Aendstp, 'chunking_config′: { ):.btfuos aseds"orum, nax_tokens_per_chunk:2ee,每钢区博最多 200 tokens 'nax_overlap_takens': 28 区埃間重叠28tokens

2.中資料(Metadata)與遇​

可以在匿入樓案時加入自訂的key-value 中继資料。 厘人路加人metadata op = cllent.file_search_stores.inport_file( file_search_store_name=file_search_store.nane, file_name=sanple_file,name, custom_metadata=[ {"key": author", "string_value": "Robert Graves"}. {"key": year", “numeric_value": 1934) ( 在查詢時,就可以使用netadata_filter来只报导符合特定修件的文件。 查腐时使用metadata_filter response = client.nodels.generate_content ( nodel-"genini-z.5-flash, contents="*Tell me about the book 'I, Claudius'""", config=types GenerateContentConfig( J=51001 types. Too1( file_search=types.FileSearch( filc_search_store_namcs=[filc_search_store.nane], TJeaA any saneug luagou,-louine, = Janit eiepeiau

print (response.text)

計囊、限制奥支援 創新的計囊模式 计意方式是這次的亮點,目是接間者能以低成本展。

• 付囊项目:只有在首次需引增案;蓝建立嵌入时才收费。

• 费率:$0.15/ 186萬tokens(以gemini-cmbcdding-301為例)。

• 免费项目:

• 案存(Storage)

• 查均時勤慧生成嵌入(Query tineembeddings)

• 常规計费:

• 检索到的文件 tokens 童被视為一般的“上下文 tokens:(context tokens)针

费。 服務限制

• 單檔大小上限:100MB

• 每個專案的Store数量:10

• 專案總存大小(依層級):

• Free: 1 GB

• T1er 1: 10 GB

• Tier 2:100 GB

• Tier 3:1 TB

1FileSearchStore限制在20GB以下,以確保最佳检索延。

• 官方建:每個

支援模型與格式

• 支援模型:

gemini-2.5-pro

• 支援檔案類型(部分):

• Application:PDF,DoCX,XLSX,PPTX

• TeXt:TXT,JSON,MD,HTML,CSV,PY,JS,JAVA,CPP,C,TS,PHP,

RB,GO,SWIFT,KOTLIN...等多種程式碼與純文字格式。

原始排版图​

发布于 2025-11-01 21:02:18（微信公众号导出记录）。

本文来自公众号后台的“导出文章内容”功能。博客正文由导出长图进行本地 OCR 转写，并保留原始排版图用于逐段核对。

原文链接：查看原文

OCR 转写有效文字约 5346 字；代码、流程图和版式以文末原始排版图为准。

正文（本地 OCR 转写）​

图1水泥制造是一个非常复杂的过程,熟料生产阶段排放约 95%的CO 水泥生产全周期过程中的能税和持政细分 原料提悠和研磨 热料生产 水泥生产1

云 明转客 东石肠破碎机选输生料康 水洗车间 冷年器 物流: 预分解沪2 惠计 ~100 ~285 1153,895 ~5 ~40 ~3,150 ~ 160 兆焦耳/吨 ~480 ~320 ~50 cO, ~10 ~5 ~20 诚烧 化石 过程 热料 CO排 N/A N/A 1% 占比 McKinsey 得说被的入电为行业 &Company 图2需求下降和CCS对1.5度路径中的CO2减排贡献最大 2020-2050年中国水泥行业二乘化碳持放量同比须测

二最化碳挣放量!​

下作代热持量

百万吨C02​

2030年CO 减排贡献

• 14%

• 27%

465 1% ~3% ~4% 9% 47%

2020 2224

1.基维增批数字基十老下品上的计算​

McKinsey &Company 图3某头部水泥企业的CO2捕集工艺和价值链 塔项 95-99%(体枚) 冷邮 烧气体 气体C02 CO2 压缩 热交换解吸器 减收略 002液 加热 免系统 CO2浓度为15-20 滚溶液稀溶液 %的客炉燃烧气 CO2条护焊 ? 工业系 食品票 工业CO2 情塔 干冰生产原料 食品级CO2+ CO2封存及进输系统 电子、激光、医共等 正在积粗开发技术,提 升CO2捕集率的可行性 提升描集率在被求上是可行的,但效益大佳会限制目 前10%左右销集率的通 MeKinsey &Company 图4 化学原理 柠法发上科法 方 碳泰护过程通过从最终静敬处获取CO,遇水后 全成CO,(哦酸益)、将其注入泥凝土逐累后, CO与钙(Ca21)反应,在混凝土内生成国体石 东石

Ca CaCO + CO3 (务) (图体石 (碳酸盐) 从大型污染源的烯由 中政集度二氧化碳, 灰石) 通过化学反应将其特 化为更坚国的绿色泥 数土块 &: Company

在深入研究年度日磨,之前,我们必须先理解水泥作為一種商品的四大揭特性。它们是所有 分析的基石:

1.端的“短腿;丽性(運输半径小)​

• 特性:水泥是一種“重(重量大)、廉(值低):的商品。运激致其隆路通输成本高,

超過一定距雕(通常是158-288公里),通貢就會超返水泥本身的俱值。

• 分析通:这决定了水泥是一個無法全國流通的商品。不存在「東泥西送,或“南泥北速

(鞋:沿海沿江的水路谨输稍好,但仍受限)。因此,水泥行業天然具有强的區域断 性、您在分析時,不能只看“全圆均情:,而必须题注海螺水泥所在的“核心市场:(如華 東、苹南)的區城性供塞和價格。

2.供端的政策市(峰生產)​

• 特性:正如您所注意到的「冬季錯峰生產。遗是水泥行業最核心的利润定器。

• 分析通:水泥行業的產能是體重透剩的。如果没有政策干预,所有庭商(尤其是高成本的

小底)害為了生存而进行毁流性的「格载;,導致全行掌病损。 ■冬季鳍峰(北方):以「保:(供暖重治污)為名,强制北方15省市停產4因月。這 避免了在最淡季(冰深期)的虚存爆色。

• 夏季踏峰(南方):以「行業自律;為名,在南方的高温梅雨季:(淡季)调停

错峰生產:是人為装造的供给短缺,是這因行案在需求下滑逻期中(如2022- 结输: 2025年)依茜能继持利理的最重要防線。

3.需求的“雙引擎:依赖(房地座+基建)​

• 特性:水泥106%用於建氧,它没有金融蜀性(不能像贡金一楼继存),也没有消叠属性

(不能用於眼造汽車或手機)。

• 分析通辑:這使得水泥的需求端度单,其命通完全职於南大引华:

1.房地座:估比最高(約30-48%),尤其是「新陶工面决定了需求的基本盛。​

2.基键建設:占比次之(的36%),是政府的“逆退期携顾:工具。​

• 结输:分析海螺水泥的需求面,就是在分析中网的宏鼠经滑政蛋,它是一個純粹的宏觀證清

(特别是固定资產投资)的『代理据标股.

4.成本的“单一命門(煤炭)​

• 特性:水泥的生產成本中,助力煤估了封大显(的48%至6B%)。

• 分析通:运使得分析其利湘警得非常施單。

• 公式:毛利哪水泥售價·煤炭成本(及其他).

结输:在「错峰生產:稳住“售價:的同時,「煤炭俱格:的波動是决定海螺水泥利测 的最大数,煤债下跌,海螺利泄就舍暴增:煤债上涨,利湿就被服重侵 水泥行業全年(1-12月)關键事件與数據监控日

第一季度(Q1):冬歇期、政策定調、预期博弈​

一月(January):数真空,政策预熟​

• 圆内(Donestic):

• 【监控量贴】:靓察各省提出的「本年GDP增長目棵:和“固定资產投資目:。运是

【监控票贴】: 到3月全属目標的“前瞻指引,市场管據此「预熟;全年的基建预期。

• 【深度解耀】:运项政策的表震原因是跟保。北方准入燃煤「供瑶季:,空氯污染醛

重,水泥作為高耗能、高污染行案,被强制停塞以保衡蓝天:、其深唇經游邀G翰是爱 相的「供给侧改革:。它强制行在全年最淡季(冰冻期無法施工)停止供给,證免了 存爆食和照性備格,實臂上福定了龍显企誉(如海螺)的利理,将体统的底抓重:警 成了「休餐生息季」。

• 供给:“冬掌错造生產;醛格執行期,北方15省市水泥基本虚於全面停產状照,

• 需求:全年最低黏,北方因醛寒冰深無法地工:全国睦绩为春前假期做掌,工地大规

模停工。

• 政策:各省市的地方雨會,睦續召限。

• 國聚(International):

• 宏觀:市場洁化上一年12月美圆聊窖(FOMC)的最终表服,為新一年的全球利率和

资本流勤定。美圈我布12月非展就菊数据(NFP)。

• 行嘴:波的海乾散货指数(BDI)反映年初的全球實易活罐度,影馨水泥熟料(如

有)的进出口谨输成本。

二月(February):春前長假,對淡季​

• 國内(Donestic):

• 【深度解】:這是行堂信心的“晴南表:。經商在春前前围背的情格,如果整挺或

上涨,锐明他們(和水泥府)非常看好間春後(3月)的「小阳春:行情。

• 供给:指编错峰停產。

• 需求:全年组對冰贴、春前侵假(通常在1-2月之)導致全圆工地基本虚於停工

• 数據:本月無重要宏觀數據發布。(注:统計局通常在3月将1-2月的数據合供發布,以

平滑春假期的巨大摆动。)

• 照键觀察:「冬储俱格。

• 國际(International):

• 宏截:美国發布1月的通照數據(CPI)。該数據将主得市場封聊华曾3月息音端的预

期

三月(March):全年大戴,政策定調(「金三:關)​

• 圆内(Domestic):

• 【监控重贴】:注《政府工作报告》中的核心数字和措。

• 政策:【全年最關键事件】全固“雨會:(人大和政協會)在北京召。

• 供输:3月15日左右,北方「冬季铺鲜生座:正式结束,水泥庵阳始黏火復座,供給闻

始恢覆。

• 需求:“金三银四:旺季的第一個月。天氯回暖,前後工地全面工。

1.GDP增長目标:决定了经滨的油门踪多深。高日楼意味著强刺激,利好所有通期行​

業

2.财政赤字率&新增專项额度:(基建需求的弹藻;)运两旧数字直接决定了中​

央和地方政府「本年」有多少可以投向基醛設施建設。

3.對房地慶的定辑:(地需求的「风向:)描群是防风隙、去庫存:還足“促​

展、保交楼」,决定了房地產行誉的政策疑默度。

• 國际(International):

• 宏觀:聯萃會(FOMC)曝息會,通常含验布更新的经酒预测和點阵国:,對全球利

率走向具有重大指引意裁。

第二季度(Q2):旺季验證,数據與现實的首次碰撞​

四月(April):旺季验疆(「银四)​

• 圈内(Domestic):

• 【监控量贴】:房地產新醋工面精、基建投资增速、(避辑:適是對「两會:政策承諾

的第一次「月考:。市場急於知道雨言操的綫(專项慎)是否已真正落地形成“實 物工作量J。)

• 需求:全年第一個施工高峰期,即「金三银四:的验證期。

• 数據:【酮键数據】4月中旬,圆家统計局發布1-3月(Q1)的完整經清数據。

• 政策:中央政治局曹(通常在4月底)。(遥蜗:這是Q1的「季度结窗:,分析一

重度经滨形势,部署二季度工作。如果Q1数不佳,市場宝關始预期政策「微调;。)

• 國(International):

• 宏觀:IMF(國际货帮基金組)和世界銀行春季會端,發布最新的《世界经清展

望》,影馨全球刺经滴增長的信心。

五月(May):旺季延续,察成色​

• 圆内(Donestic):

• 需求:施工旺季延绩,但腊始為南方的梅雨和北方的酷熟做弹儒。

• 数據:5月中句公布4月数。如果「银四:数擦(4月数摊)不及预期,市場宝到全年

需求调向悲敏。

• 供给:水泥廠漏负荷生座,供结谨到全年峰值。

• 国(International):

• 行業:關注海螺等企業在一带一路沿線圆家(如印尼、扁兹别克)的動,这代表

其海外增量。

六月(June):旺季淡,“夏鳞:前奏​

• 内(Domestic):

• 【深度解耀】:这不是像「冬錯:那样的强制保政策,而是行業自律;。避辑

是:由於高温(工地停工)和雨(無法施工)尊致需求断崖式下跌,如果水泥继續 生產,存將立刻爆满,引發毁滋性的「借格載。因此,由行案宝或缩跟企業(如海 螺)亲额,调大家在淡季主勤停產检修(30-40天不等),以定價格、保住利

• 需求:傅统旺季结束。南方进入「梅南重:,北方册始高温,均不利於户外施工。

• 供给:“夏学錯峰生產:始。

• 國际(International):

• 行業:除勤力煤债格(如纽卡斯需煤债)进入淡季。(逾辑:煤炭占水泥成本的

40%-68,煤俱走直接決定海螺等企業的嘲成本和毛利率。)

第三季度(Q3):傅统淡季,政策「微的關键窗口​

七月(JuLy):高温多雨,韬對淡季​

• 圆内(Domestic)):

• 【监控重贴】:(下半年的「方向整」)这是總结上半年经酒,部署下半年工作的盲

遂,如果上半年經湾数據遗不及预期,这是出台“下半年强力刺激;政策的最重要窗口, 直接决定Q3和Q4的需求。

• 需求:全年第二個需求冰贴、全国性的高温、暴雨、除显天氢集中燥

• 供给:复季继證生產;全面敦行,行業遥入债损量蹈;的休零;陪段。

• 政策:【厕政策】中央政治局會(通常在7月底)。

• 國(International):

• 宏飘:美圆公布Q2的GDP数,影署全球封锂清衰退或覆差的判。

八月(August):淡季延续,财報验​

• 圆内(Donestic):

• 【监控重贴】:必须深财整,南注:1.毛利/嘲成本(反映成本控制能力);

2.海外業務占比(是否成為新增侵极):3.廖收幅款(看下游(房企)的回款键康​

度)。

• 需求:仍在溪季,但下游始為金九裂十;的旺季需费。

• 数據:【公司财報】上市水泥企業(海螺、金隅、冀束等)集中發布半年度告(中

般)。 報)。

• 供给:贾错:延镇。

• 供給:「夏錯」延續。

• 國際(International):

• 宏觀:克逊霍爾(JacksonHole)全球央行年會。聯准會主席通常會在此释放關於

貨币政策的長期(轉向)訊號。

九月(September):金九殷勤,预期升温​

• 國内(Domestic):

• 需求:「金九銀十」。全年第二個施工旺季開始,天氣轉凉。

• 供:水泥廠在「夏錯」後復產,供給增加以應對旺季。

• 政策:市場開始密切關注和猜测即將到来的Q4「冬季錯峰生產的政策力度。

• 國際(International):

■宏觀:聯准會(FOMC)息會。

• 第四季度(Q4):供給為王,衡刺舆定

十月(October):「銀十」旺季,「冬文件發布​

• 國内(Domestic):

■【控重點】:(Q4行情的「發令檐」)這份文件将明確北方「2+26」城市及周遗省 市的水泥行業峰生產時間表(例如:11月15日至次年3月15日)。文件的「措属 程度」(如「不搞一刀切」還是「格執行」)是Q4股價最大的供給侧催化劑。

• 需求:國度長假後(10月8日),進入旺季最高峰。

• 政策:【供給端最關键文件】工信部、生態環境部通常在10月底正式發布《XX-XX年

秋冬季大氣污染综合治理攻坚方案》。

• 國際(International):

• 行業:國隙動力煤價格進入冬季旺季。(邂辑:北半球取暖季導致煤價上涨,這將决定

海螺Q4及來年的主要生產成本。)

十一月(November):供給為王,「北停南程​

• 國内(Domestic):

• 供給:「冬季峰生產;正式開始(通常在11月15日)。北方水泥廠大规模停案,供給

端急劇收缩。

• 需求:呈現「南北分化」:北方(東北、華北)因上凍,施工基本停止;但南方(華

束、南)進入天氣最好的「超工期」,是全年的最後衡刺。

• 市場結果:供給收縮+南方需求旺盛,歷史上11月是水泥價格最容易(在旺季基

上)再次跳涨的月份。

• 國際(International):

• 宏觀:G20峰會等地緣政治事件,影響全球貿易情。

十二月(December):政策定調,為来年怖局​

• 國内(Domestic):

■【深度解释】:(來年經濟的「總網领」)這是决定下一年所有經濟政策的「總 领」,是内最高級别的經濟會。它為來年3月「雨會」的《政府工作報告》定下基 調。金融市場會逐字分析公報中關於「财政力度」、「貨累」和「房地產新模式」的 措,它决定了市場對来年Q1的全部预期。

• 政策:【全年最關键(之二)】中央經濟工作會(CEWC)召開。

• 需求:北方全停;南方進入起工末期。(關鍵觀察:基建填目會在年底「突擎花」,

以用完當年预算,這對水泥需求有短期提振。)

• 國際(International):

• 宏觀:聯准會(FOMC)最後一次息會,為全年收官,亚給出對来年的初步指引。

• 行業:西方進入聖-新年長假,全球貿易活動放缓。

原始排版图​

发布于 2025-10-20 00:06:10（微信公众号导出记录）。

本文来自公众号后台的“导出文章内容”功能。博客正文由导出长图进行本地 OCR 转写，并保留原始排版图用于逐段核对。

原文链接：查看原文

OCR 转写有效文字约 898 字；代码、流程图和版式以文末原始排版图为准。

正文（本地 OCR 转写）​

2分钟 = Listen Later En el silencio del alma quieta, No hay cadenas que aten el ser. El viento pasa, susurra secretos, Pero el corazon ya no quiere temer. Si el alma nada busca,nada anhela, Con viento o sin él,todo es libertad. Fluye el rio sin prisa ni meta, Libre soy, en la paz de la eternidad. Las nubes bailan en cielos abiertos, Sin aferrarse a un destino fugaz. El eco del mundo se pierde en el aire, Y en mi interior,hallo el vasto espacio. Si el alma nada busca, nada anhela, Con viento o sin él,todo es libertad. Fluye el rio sin prisa ni meta, Libre soy, en la paz de la eternidad. Deja ir las sombras, las dudas que atan, Respira profundo,siente el vacio pleno. No hay tormenta que rompa este vuelo, En la nada,encuentro el todo sereno. Si el alma nada busca, nada anhela, Con viento o sin él,todo es libertad. Fluye el rio sin prisa ni meta, Libre soy... libre soy... en la paz de la eternidad. 美国2025年10月20日00:06

原始排版图​

发布于 2025-10-14 23:50:24（微信公众号导出记录）。

本文来自公众号后台的“导出文章内容”功能。博客正文由导出长图进行本地 OCR 转写，并保留原始排版图用于逐段核对。

原文链接：查看原文

OCR 转写有效文字约 3822 字；代码、流程图和版式以文末原始排版图为准。

正文（本地 OCR 转写）​

RTL8812EU性能最佳化:5GHzU-NII频於高通量、低延数 據路應用 originalwθ×7ce EI V1ajero 2025年10月14日 23:50 新如坡

1.5GHz频譜结横解析與基碰物理量​

5 GHz (8o2.11a/h/n/ac/ax/be) (e) Fs ndex Frequency United United 004 Gb. Fo range 160 40 80 IN-n (MHx) ZHZH bend(s) DFSTPC DFS/TPC 140 138 57005690-5710 X [nsts I] U-NII- .142 144 0229-01/5 5720 2C3 57305735 Unknoumt 57455735-5755 149 5755-5775 5765 E-IN-n 155 SAD 157 5775-5795 fes (Ww 02) .159 5795-5815 9095 Yes 163 5815-5835 166 5825 SAD 5635-5655 UHNI-3/4 159 5645 171 (26 mW) Indoons 173 555-5875 5855 No

• IN-n

5686 177 No Frequeney US FCC h E 160 United United 80 IN-n Australia range 20 MHz (ZHW) MHz (MHaz) (s)pun https://en.wikipedia.org/wiki/List_of_wLAN_channels 5GHz频语或非逼额的單一频段,而是被制分為数個具储摄立法规的U-NII波段。封此频游分 段的精随超知,是所有後續性能侵化工作的基碟。 表1:U-NII波段分與频道對康 波段代號 频率能圆(GHz) 可用20MHz频道 U-NII-1 36, 40, 44, 48

5.150 - 5.258​

52, 56, 60, 64 U-NII-2A

5.250 - 5.358​

5.470 - 5.725​

U-NII-2C 100 至 144 149, 153, 157, 161, 165 U-NII-3

5.725 - 5.858​

所有性能分析與法规限制,均圆绝一项核心物理量:等效全向辐射功率(EIRP。 Equivalent Isotropic Radiated Power).EIRP 代表天線系統宽幅射至项中的 總能量,此為监管機的核心题注重點。其計算公式為: EIRPsBm = Prxs + GAenas ICaltg 其中,Pr為品片组的傅導功率,GArtean為天線的被勤增益,LCale為傅翰線与速接 器的損耗。法规限制的是EIRP,而非覃纯的传功率。

2.各U-NII波段之法规框架奥性能權衡​

每因波段的法规特性,决定了其在不同鹰用場景下的逸用性舆性能潜力。

2.1U-NII-1:低功率、低干摄频段​

• 核心法规:EIRP受限龄低功率通作,通常上限爲200nW(23dBm)。

• 性能影:

• 正面:無需“動慰频率選捶:(DFS)模制此特性硫保了频道可即時欲用,根本上

排除了因外部需達信赋解發而谱致的键路中断,是维持低延遥通信的基。

• 正面:由於功率限制,此频段的背景射频噪登基底(Noise Floor)通常酸低,有助

於在短距魅内實现高信噪比(SNR)的定翘路。

• 负面:格的EIRP上限,物理定律上限制了其信號传播距罐,故不滤用於速距離康

用。

• 鹰用定值:遍用於系统基率测試、實验室瑞境校率,以及在想定性僵先於距的短程部警

中。

2.2 U-NII-2A&U-NII-2C:DFS 限制频段​

• 核心法规:强制要求實施DFS協,以值测亚规进现有的侵先级服務(如機场都卜勒天氧

雷速 TDWR)。

• 性能影馨:

• 负面(决定性):DFS判高性能数球键路施加了南项不可容忍的限制。其一,频道

可用性检查(CAC),要求設催在放用频道前必须进行長達60秒的静默监随。其二,在 投监控(In-Service Monitoring),要求設借在慎润到密谨服衡信號後,必须在 10秒内撤離接频道,且在30分罐的禁止远期内不得返回。

• 负面:此機制端致键路存在一但不可预测的、由外部因素發的、長调期的中暨周险。

封於要求持绩速接的愿用而言,此围险是不可接受的。

• 應用定位:任何以不断、低延近為核心需求的座用,均鹰在系统震微庭规證此频段。

2.3U-NII-3:高性能康用频段​

• 核心法规:為高功率無線愿用而設計,允許(點對多點系统)高谨1W(30dBm)的

EIRP,

• 性能影窖:

• 正面:30dBm的EIRP為實現高功率奥速距雕提供了充足的凝路预算(Link

Budget)。相教於23dBn,7dB的功率提升盒味著理输传输距魁可增加一倍以上。

• 正面:免除DF5要求,硫保了频道的和时可用性與翘路的定性,是實现低延逻與高

可靠性的先决修件。

• 潜在挑瑕:此频段的侵越特性吸引了大量未授權設備,可能增致较高的频游舜挤度。因

此,部香前的频错分析(Spectrum Analys1s)成為必要步骤。

• 愿用定位:道是唯一能跨同時满足遗距雕、高通量典低延避需求的渠段。所有後绩的性能侵

化策略均鹰圍此频段展明。

3.RTL8812EU之精密配置與性能調校​

在U-NII-3频段的基碟上,必须系统、物理磨及射频前端進行精確配置。

3.1系统眉级配置​

1.骚勤程式:必须探用支援监模式(Mon1tor Mode)與辅注人(FrameInjection)​

功能的第三方源疆動程式。棵的OEM醒動程式無法提供必要的底震控制能力。

2.监管(ReguLatory Domain):主提操作系统(如Linux)的氟级监管域必须被正础​

設定。透通iwreg set 命令董配合crda(Central Regulatory Domain Agent)服務,可以告知内核解除剪U-NII-3 频段及其 3θdBm 功率上喂的封额。此为 放晶片组全部潜能的雨键前置作堂。

3.2物理(PHY)参数優化​

1.频道频宽(Channel Bonding):​

• 20MHz:接收震敏座显高,键路显摄健。適用岭排载限距,但會限制幢值吞吐量。

• 40MHz:透遇据南個相期的20NHz频道(一個主频道,一個次频道),使理给数

速率加倍。道定高频置與健路穗定性之尚的最佳折衷點。

• 88MHz:理输速率再次倍增,但會引入約3dB的接收霍敏度衰减,亚顯著增加受带内

干摄的楼率。催適用龄 SNR桓高(>25dB)的近距魅爆景。

2.調與编碼方案(MCS)风保罐酬隔(Guard Interval,GI):​

• MCS:MCS 索引直接唐了调陪数(BPSK,QPSK,16-QAM,64-QAM,256-

QAM)與编碼率、高MCS提供更高香吐量,但要求更高的SNR,对於追求稳定性的 继路,鹰蒙用自勤MCS,益手動设定一固定的中低诺MCS(如MCS2-4,封癌16- QAM)。以確保罐路在信赋衰减時的韧性,避免因NCS劇烈跳募致的延运抖助,

• GuardInterval(GI):保間隔是用於到抗多路径延运据展的機制。短保間隔

(ShortGI)可提升約18%的香吐量,但對多路径干摄更敏感。在运距雕或非视距 更敏感。任速距離或非視距 (NLOS)環境中,應使用長保護間隔(LongGI)以確保数據解碼的正確性,降低封包 錯误率(PER)。

3.3EIRP功率预算與天線系統​

實現遠距離傅输的核心在於優化EIRP,而非單纯最大化傅導功率。将RTL8812EU的功率放 大器(PA)推向和點會導致嚴重的非線性失真(如频譜再生),反而惡化信號品質。 最佳化策略應為: L.將RTL8812EU的傅導功率設定在其線性工作區間内的一個適中值(如17-20dBm)。

2.將系統設計的重點轉移至天線系統。探用高增益的定向天線(如增益為10-13dBi的平板​

天線),可將射能量高度集中。其狭窄的波束宽度(Beamwidth)在提升目標方向信號 强度的同時,也降低了來自其他方向的干接,而大地改善了接收端的SNR。此策略要求 精確的天線對。

4.結:標准化操作協​

為RTL8812EU系統中獲取可预測的、最佳化的性能,應遵循以下標化操作協: L.频段限定:系统操作應格限定於U-NII-3频段(5.725-5.850GHz)。

2.部署前勘測:必须利用频譜分析工具對作業環境進行描,選選U-NII-3段内背景噪聲​

最低的類道。

3.系統初始化:確保主機系統已载入功能完整的動程式,已正確配置管域以用高功率​

模式。

1.物理層配置:​

• 基配置:4OMHz道宽度,固定的中MCS,長保護間隔。

• 距離優先:20MHz道宽度,固定的低MCS,長保護間隔。

• 通量優先(近距):80MHz道寬度,固定的高MCS,短保護間隔(需驗證

SNR)。

5.射類前端:探用高品質的定向天線系統作為提升路预算的主要手段。所有配置必须確保最​

終的EIRP不超過30dBm的法规上限。 U-NII-3因其在美國法规下的優越性而成為首選,但在其他地區,需要根據當地法规 寻找對應的、允許高功率且無需DFS的「黄金频段」。 例如:

• 美國:FCC(FederalCommunications Commission)

• 歐洲:ETSI(European Telecommunications StandardsInstitute)

• 日本:MIc(Ministry of InternalAffairs andCommunications)

• 中國:MIIT(Ministry ofIndustry andInformation Technology)

原始排版图​