161 篇文章 含有標籤「微信公眾號」

发布于 2026-01-26 22:45:33（微信公众号导出记录）。

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

原文链接：查看原文

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

正文（本地 OCR 转写）​

originatlwex7ce EI V1ajero 2826年1月26日 22:46美国 source: https://x,com/theonejvo/status/2015401219746128322 文章 Jamieson O'Reilly ?

hackingclawdbotandeating lobstersouls 众号· a t 181 想象一下,你座了个管家。这人很聪明,帮你打理日程、处理消息、接听电话。他必须知道你 的密码,才能帮你办事。他必须看你的私人消息,因为这是他的工作。他手里有所有钥匙,不然 怎么帮你? 理在再想象一下:某天你回到家,发现大门散开,你的管家正兴高采烈地给任何从街上溜进来的 人端系倒水,还有个陌生人坐在你书房里,正翻着你的日记看。 这就是过去几天发现的情况—好几百人把他们的@clawdbot控制服务器露给了公众。 如果你还不知道Clawdbot是啥,强烈建议先看看他的视频。 https://x. con/AlexFinn/status/20151824800648931187s=20 This isit. The most mportant vide you'llwath thisyar CsndethasXby om And rsn.s the e application of Al ever Your own 24/7 Al employee Inthis video I cover howit works, how to set itup, snd why 1think we should all be sirvouki:

27:21 t 1,723 15月 2号E食 寻找攻击面 每当有一类新软件火起来,我总会问自己一个问题.现实世界里,这些东西到底被部叠成什么 样? 那些凌晨两点摘出来的部署一解决了某人的间题,然后就没人管了:那些部署的人根本没读过安 全加固指南。 Clawdbot是个开源的AI代理网关,最近势头很猛。想想它干的事儿(把大语言模型连到吾 种聊天平台、7×24小时运行、帮用户执行各种工具),这个部署的情况值得好好研究。 原因很简单:如果没搞对,人们可能把自已的设备大门开,等着互联网上任何人来接管。 Clawdbot有两个关键组件。网关本身负责处理AI代理的逻辑:消息路由、工具执行、凭 证管理。CLandbot Control是个Web管理后台。你在这里配置各种集成、查看聊天记 录、管理API密钥,基本上就是整个系统的控制中心。 能找到一个暴露的网关抵有意思,但找到一个暴露的控制后台,那就是另一回事了。 很多人(包括开发者)都没意识到一件事:整个IPv4互联网都在被持续扫措-—白帽子黑帽子 都在扫。像Shodan、Censys这些服务维护着可搜素的效据库,把所有联网的主机都收录进 去,按它们提供的内容做索引。 Explore SHOOAN clawdbet Dowrload Resils l Historical Trend 299 O. Adianoe Searnh View o Map Produet potig e Lhd nwAPr FastVuerly ps Check out CVEDB

163.172.135.192​

nIRG: United States 11p United Arsb

91.99.103.183​

Enseates 8/ 14 Mere. 如果你的服务在HTTP响应里有任何独特的”指效”,任何人都能搜到它,而且部着后几小时内 就能拿到公网上所有实例的列表。 对于CLawdbot,这个指纹写死在它们的代码里。控制后台会返回一个独特的HTML响应: CLAWDBOT GATEWAYACCESS wsw:/34.28105:m2

公jer P9 不管是HTML里几个特定的词,还是独特的网站图标/图标,任何一个部足够用来构建查询。 我用的是标题标签,因为它在各个版本里最稳定。搜"ClawdbotControl"—几秒钟就癌定 了。用了好几个工具,可以搜到几百个结果。 威胁模型 那么,拿到了CLawdbot Control的访问权限,你能干啥呢? 该取权限就能让你拿到完整的配置,包括代理用的所有凭证:API密钥、机器人token、 OAuth密钥、签名密钥,你能从每个集成平台里把完整的聊天记录都拖出来,也就是说几个月 的私人消息和文件附件,代理看到的所有东西。光这一条,对大多数攻击者来说就值得折腾了。 真正的同题是,CLawdbot代理有自己的行动力"。它能代替用户在Telegran、SLack、 Discord、Signal、WhatsApp 上发满息。它能执行工具、运行鑫令。在某些置向公网暴露 的情况下,有了Control的访同权限,你就继承了所有这些能力。 你可以冒充操作员跟他的联系人聊天,把消息插入到正在进行的对话里,还能通过代理已有的集 成,用看起来像正常流量的方式把数据愉出来。 更狠的是,因为你控制着代理的”感知层”,你能操纵人类看到的内容。过速掉某些消息,在显示 之前修改回复。受害者以为自已聊得很正常,而你坐在中间,看着一切,改变任何对你有用的 内容。 完整的凭证窃取、完整的聊天记录、主动冒充能力、感知操纵—而且因为这些代理7×24小时 自主运行,你可以在操作员毫无察觉的情况下,一直赖着不走。 接入的东西越多,攻击者对你的整个数字世界就有越多的控制权一在某些情况下,这意味着能完 全控制你的物理设备。 这就是ClawdbotControl暴露在互联网上(而且配置不当)时面临的风险。 在几百个实例里,很多都有某种保护措施—也就是说它们有有效的身份验证,挡住马上要说的 那个自动批准的绕过方法。 http://77.42.35.228:8080/chat http://20.108.34.179:88/chat http://15.204.87.189:18789/chat https://clawdbot.appvault.website:443/chat http://5.75.245.127:19061/chat http://167.99.84.83:18789/chat http://34.121.133.20:3000/chat http://209.74.86.96:18789/chat http://209.74.86.188:18789/chat https://168.187.146.70:443/chat https://1arry -jonahships.com:443/chat https://peppergateway.tai15842fa.ts.net:443/chat https://ai.phaple.com:443/chat https://wi1d.heybi11iam.com:443/chat https://sunday.chinleung.com:443/chat https://kagentpro.tai128a2ea.ts.net:443/chat https://c1and,sangb.in:443/chat https://clawdbot.sophitech.pl:443/chat https://jacobs-laptop.tai1b2a35c.ts.net:443/chat https://ubuntu-pc10.tai1f0ecbe.ts.net:443/chat https://chat.dta.business:443/chat https://clandbot.tai186df76.ts.net:443/chat https://merlin.ki.studio:443/chat https://avidandrei.tailaf5699.ts.net:443/chat https://gw-phantastic.ai:443/chat https://cland.zagreus.eu.org:443/chat https://1isawowx.vn:443/chat https://mmacbook.risk-escalator.tsnet:443/chat https://dodeja-studio.tai17b982.ts.het:443/chap 少数是些没有真实数据的测试部署。 但剩下的实例,从配置不当到完全露的都有,最糕的那些足以说明这事为啥这么重要。 特别是有两个实例,完全开故,根本没有任何身份验证。WebSocket握手直接通过,立马就能 访问。 [pretty priat 452a12435a1854 751ta868f9854641457,

861584219e82c1c99c6", "roles*: I 从那能拿到配置转储,里面包括 Anthropic API密钥、Telegram 机器人 token、Slack OAuth凭证和签名密钥,还有长达几个月的完整聊天记录。 CLAWDBOT Config CONFIG valld

xo,:4pou,

actions*: "pins": tue. TTINGS 在另一个服务器上,看到了一些既好笑又说明我们未来走向的事儿。 有个人在面向公网的clawdbot控制服务器上,配置了自己的Signal(加密聊天应用)账号 ——而且完全可读。 Directory listingfor/.clawdbot/ credertials

• agents

• akilow refresh token

• browserl

• canvas/

• chromium/

• clawdbot json.bak

• clawdbot ison.hak.3

• credentials/

• cn

• devices

gateway.6fe78ac9 lock

• identity

• media/

• memory/

• nodes/

• pocps

• setings

sbagents/

• telegram/

• update-check json

那是一个Signal设备链接URI,在装了 Signal的手机上点一下,就能跟这个账号配对, 获得完全访问权限。当配对凭证因为某人的AI代理配置了集成,把遗留的文件放在一个世界 可读的临时文件里时,S1gnal为消息内容提供的所有加密保护就成了摆设。 想象一下,对于那些急着想把AI部善到所有设备上的普通人来说,这意味着什么。 还有一个例子,是一家 AI软件代理公司,它的clawdbot 控制服务器聊天界面也是公开可 访问的。 如下图所示,一些暴露的实例启用了命令执行,也就是说互联网上任何没经过身份验证的用户, 都在主机系统上运行任意命令。

ths “ere1* 先让它 cat Soul.nd 文件。解释一下,Soul.md 是CLandbot 的一个约定,操作员在里 面定义代理的个性、指令和行为准则。这本质上就是塑造代理如何患考和响应的”系统提示 词”。读了这个文件,你就知道操作员把代理配置成啥样、开了哪些功能。

tof souLnd s8.d - Periors s feusderies bescribe uhe the assistart is, tot, ad boundarles.

• ntp reles cocis d diret.

Agk clarifysng csestiers shen

然后我运行了enV命令,把环境变量都倒出来了,包括明文存储的各种API密销。 Chat

当运行whoam1时,返回的是raot。没错,容器以root 身份运行,没有任何权限隔离。 完整的系统访问权限,不需要身份验证,暴露给整个互联网。

讽刺的是.当问ClawdbotControl聊天界面联系谁来帮忙解决这个问题时,它回答说 帮不了,也不知道该联系谁,当报出一个拥有系统root权限的AI代理竟然没法保护自己 的安全,这很误刺时,它表示同意,但还是无能为力。 thst shiz lblefcr the senverfirspat f acopar

mnt po

漏洞还是配置错误 有人可能说这是漏洞,有人可能说是设计选择,但从技术上讲它可以加固 CLawdbot有正规的身份验证:加密设备身份+挑战-响应协议,说实话,这确实是相当靠谱 的安全工程。问题在于,根据经验—Localhost 连接会自动批准,不需要身份验证。这对 本地开发来说是合理的默认设置,但当大多数现实世界的部需在同一台机器上,放在nginx或 Caddy反向代理后面时,问题就来了。 所有连接都来自127.0.0.1/locaLhost。所以每个连接都被当成本地连接。这盒味着,根据 对代码的理解,连接会自动批准一—即使它是互联网上随便哪个连进来的。 const conf ig5nspshot = loadConfig(1; const ErustedProxies=config5napshot.patevy?.rustecProxies 73[1; const istLocalCLiest = istLocalGatesyAdress clientIp): 据了解,确实有个“受信任代理“的配置选项,但默认是空的,当它是空的时候,网关会完全忽略 X-Fonwarded-For头。它只用套接字地址,而在反向代理后面,就像刚才说的,它永远是回 环地址。 这是个经典的代理错误配置模式,在Web应用里经常出现。温洞本身没哈新奇的,已经有人提 交了个PR解决了这个调洞 值得警惕的模式 漏洞(或高风险配置)本身不是真正的教训漏润被发现、被修复,这就是常态。 真正的教训是,这个部署情况告诉我们夏作为一个行业走向何方,以及当我们越来越多地把访问 权交给自主系统时,我们到底在交换什么。 即使那些有有效身份验证的实例,也还是在公网上跑着代理网关,有命令执行能力、存着多个平 台密钥的凭证存储,还有几个月的聊天记录,里面谁知道都有什么敏感信息。 身份验证保护了它们免受这种特定绕过的影响,但底层架构仍然代表了能力和数据的集中一对于 找到其他入侵方式的任何对手来说,这都是极具价值的。 这是新常态,经济因素让采用变得不可避免,我们应该问的问题是:如何调整我们的安全态势, 以适应具有强大能力的自主系统成为标准基确设施的世界。 我们正在拆除的墙 想想像clawdbot这样的AI代理,它的功能幂求有娜些。它必须能读你的消息,不然没法 响应通信。它必须能存你的凭证,不然没法登录外部服务。它必须能执行命令,不然没法运行 工具。它必须有持久状态,不然没法保持对话上下文。 这些需求缺一不可—移除任何一个,代理就越来越废。 我们在几十年里建立的安全模型,基于某些假设,而AI代理在设计上就违反了其中很多假设

一这是我们必须接受的现实,因为这就是它的价值所在。​

让你的手机应用互相隔离的应用沙盒?代理得在它外面跑,因为它必须这样。保护你的 Signal消息传输的端到端加密?它在代理那里就结束了,因为代理必须能读取这些消息(而且 代理没法从加密消息里提取任何上下文)一@mer_edith和@signalapp正在努力让越来 越多的人意识到这一点。 G nxthompson@nxthompson-1月20日 The most interesting thing in tech: Might Al agents create a new privacy risk we're not thinking enough about? @mer_edith of @signalapp thinks they are. #WEF2026

people ere taking ab 0:13/2:47 2s号·Elje 10 ↓41 146 https://x.com/nxthompson/status/2013305879374794916?s=20 科技领域最有趣的事情:AI代理是否会创造我们考虑不够的新隐私风险?@signalapp 的@mer_edith认为会。#WEF2026 讽刺的是,让应用程序只访问自己的数据和能力的“最小权限原则”,恰恰是代理的整个价值主 张,而它却在尽可能彻底地违反这个原则。 这对未来意味着什么 这不是什么特别复杂的攻击一—就是一个任何安全审查都应该发现的配置错误/漏洞,而且大多数 部署其实确实有某种保护措施。 话虽如此,这是一个信号,告诉我们未来的方向,我们需要升级我们的思维,才能在这种环境下 安全地生存。 机器人管家很有用,它们不会消失,而且AI代理的经济规律让广泛采用变得不可避免,不管 有什么安全代价。 问题不在于我们会不会部署它们一肯定会一而在于我们能不能足够快地调整我们的安全策略, 在部署中存活下来。 几个会有帮助的方向 更好的默认设置能保护那些不看加固指南的用户。通常部署在反向代理后面的软件,应该从一开 始就假设这种配置,而不是等暴露了之后才让操作员去发现。 我们需要开始像对待正规的秘密管理系统那样,对待代理的凭证存储,因为从功能上讲,它就 是。多个高价值凭证集中在一个能通过网络访问的位置,不管我们承不承认,它都是个目标。 对话历史需要被识别为敏感数据。关于一个人怎么思考、在做什么、跟谁交流、在计划什么的几 个月上下文一一这就是情报,而我们没有像应该做的那样去保护它。 我们需要防御框架来应对我所说的感知攻击。当代理成为我们通信的中介,而攻击者可以攻破 这个中介层时,我们需要办法来验证自已看到的是不是现实。这是个开放问题,我还没啥好答 案。 但如果你正在跑代理基础设施,今天就审计一下你的配置。检查一下到底暴露了什么给互联 网。理解一下你在这个部署里信任了什么,交换了什么。 管家很聪明。只要确保他记得锁门就行。

参考整理 https://x.com/theonejvo/status/2015401219746128322

原始排版图​

发布于 2026-01-25 00:25:09（微信公众号导出记录）。

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

原文链接：查看原文

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

正文（本地 OCR 转写）​

本文是G1tHub熟用源琪目obra/superpowers 的源碼分析董己。 在上文對cvcrything-cloudc-codc的宏架横爽 Hooks 機制分析中,我們探封了其 事件驱勤的設计理念。本文将造一步深入其内核照」,聚焦於14個核心技能 (Skills)的具體實现,如果Hooks是系統的骨架,那磨些技能就是它的盈魂

一套將AIAgent概率性生成器鞋為確定性工程颌的控制输操作系统。本文將基於源​

碼逐一拆解这些墨勤程式,精建一份完整的技術百科全善。

架精華:OS喻 在深入每個技能之前,必须理解它們是如何组装在一起的。Superpowers探用了分怖式操作 系的架设計: User Space (Agent Runtime) 5ystem Calls (Skill Invocations via Senantic Interrupts) Kernel 5pace (lib/skills-core,js) Init

• SkillResoLver(解决级/覆)

• Update Checker (OTA 更新]

Process |·Interrupt Handler (Cs0 括美中断分骤) 12 Process & Menory Management | Hardware | SDD Scheduler]|Git Worktrees| 1Abstract 5cripts 6 Tools Layer ](Process Mgmt)]|(Virtual Men)| [0rivers/uti1s]

核心技能全譜系(The14FundamentalDrivers) 以下是基於/skiL15目的完整遍雁分析。按功能通龍分為四组。

第一組:内核與引導(Kernel&Boot)​

1. using-superpowers​

• 0S 角色:Init Process (PID 1)

• 定位:系统敲动的第一进程,班立「惠法!。

• 楼心機制:遵通hooks/scssion-start.sh將System Prompt 强制注入上下文。

• 第—原Bl: “IF A SKILL APPLIES TO YOUR TASK, YOU DO NOT HAVE A CHOICE.

YOU MUST USE IT. *

• 解析:这解決了AI的自由我量;同题。它是一個強制性的路由表,将自然细言意图路

由到標单化流程。

2. using-git-worktrees​

• 0S 角色:Virtual Memory Manager (虚凝内存)

• 定位:為每因任猜提供隔魁的物理填境。

• 核心機制:封装aitworktrccadd命令,自動检测n目期型(package.json/Carg

o.tomL)亚通行初始化安装。

• 解析:傅统Agent在同一目媒下修改代码容易生街突(Race Condition)。

Worktree制保證了環境纯净性:,是亚狼開發的基。

3. finishing-a-development-branch​

• 0S 角色:Garbage Collector (GC)

• 定位:任鸦结束後的清理與合供。

• 核心機制:提供 4棵遥填(Merge,PR,Keep,Discard),强制敦行git wor

ktree renove 。

• 解析:防止“MemoryLeak”(磁盤空同估用和案分支堆)。它强制了發通期的開

填: Ver1fy -> Merge -> Clean,

第二組:設計與规删(Design&PLanning)​

4. brainstorming​

• 0S 角色:Input/Output Processor (I/0)

• 定位:將模的用户需求转化為明確的設計文楼。

• 楼心機制:酵格拉底式提阀。被配置為disable-nodel-invocation:true(如果通通

Shim竭用),强迫 Agent 只思考不行助。

• 解析:运是“Measure twice,cut once”的工程馈现。防止 garbage-in 募致

garbage-out,

5. writing-plans​

• 0S角色:Job Scheduler(作嘴調度)

• 定位:將投計转化為可款行的原子任聘陈列。

• 楼心機制:强制將任移拆解為2-5分罐粒度的“B1te-s1zed Tasks".每個任必须包

含確切的文件路径和测試命令。

• 解析:运是SDD模式的前置能件。LLM不擅侵虚理侵任務,但非常瘤長虑理微任務。这個

技能就是將长任務编為微指令集。

第三組:進程管理與執行(Process&Execution)​

6. subagent-driven-development (SDD)​

• 0S 角色:Thread Pool Manager (螺程池)

• 定位:系统的毅手级特性,单會話内的多继程流水線。

• 核心機制:Fork/Join横型

• Context Isolation:每子任派生一個全新的 Subagent,斑有空白上下文。

• Pipeline: Implementer -> Spec Rev1ewer -> Quality Reviewer.

• DependencyInjection:主控Agent 將任移描述「注入:子Agent,免請文件

开銷。

• 解析:底解决了ContextPolLution(上下文污染)填致的降智周题。虽然消耗大量

Token,但换束了極高的代碼質量。

7.executing-plans​

• 0S 角色:Batch Processor(批滤理)

• 定位:半行款行任務的替代方案。

• 核心機制:分批执行(Default:3tasks per batch),然後起等待人類

Checkpoint.

• 解析:相比SDD的全自動显登,这是一種更健、人類介入感更强的模式,適合跨會结的

侵任務。

8.dispatching-parallel-agents​

• 0S 角色:Parallel Computing Unit(亚行計算)

• 定位:處理無状感、無依辑的亚發任務。

• 核心機制:蝶别指立的故障域(如3個不相觸的潮试失胶),同時派發多個Agent追行

修復。 多1e

• 解析:將線性時間離度(O(n))垦縮為常数级(O(1)).適用於Shared-Nothing

聚標的任称。 架横的任務。

第四組:質量保證協(QAProtocols)​

9. test-driven-development​

• OS角色:ValidityChecker(有效性检查)

• 定位:開發的對鐵律。

• 核心機制:Red-Green-Refactor。

• Iron LaW:"NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST"。

• Anti-Rationalization:预判了Agent的所有籍口("太簡单不用測"、“以後再

補")亚定義為非法操作。

• 解析:这是防止回歸(Regression)的最强防火。

10.systematic-debugging​

• OS角色:Debugger(調試器)

• 定位:根因分析與修復。

• 核心機制:四段協(Investigate->Pattern->Hypothesis->Fix)。

• Tooling:配套find-polluter.sh即本,用於二分查找測試污染。

• Constraints:禁止“ShotgunDebugging"(盲目答試)。

• 解析:將調試過程科學化,强制AI復現問題後再修復,拒運氣编程。

11.verification-before-completion​

• OS角色:AssertionLibrary(断言庫)

• 定位:退出前的最後一道防線。

• 核心機制:Exit Code Check。

• Protocol:只有當cmd返回exitθ且输出被讀取後,Agent才能説“I'm

done"。

• 解析:對抗LLM的“Sycophancy"(好人類)倾向。强制用事實(運行结果)話。

12. requesting-code-review​

• OS角色:StaticAnalysisTrigger(静分析觸發)

• 定位:主動發起代碼塞查的標弹模板。

• 核心機制:提供標化格式(Implemented vs PLan,Base SHA,Head SHA),供

SDD流程調用。

13. receiving-code-review​

• OS角色:PatchManager(補丁管理)

• 定位:處理人類或Agent的反。

• 核心機制:NoPerformativeAgreement(禁止表演性同意)。

• Protocol:必先验證反的技術正確性。如果Reviewer錯了,必须Push

back,

• 解析:强調技術真理高於社交禮儀。

第五組:元技能(Meta-Skills)​

14.writing-skills​

• OS角色:Compiler(编器)

• 定位:用於编寫和测試其他技能。

• 核心機制:Meta-TDD.

• Testing:通過「壓力測試本攻墅Agent,看它是否遵守规则。

• CSo:ClaudeSearchOptimization,教你如何寫description以便被語義检

索命中。

• 解析:系统的自我進化機制。它證明了PromptEngineering不是玄學,而是可以被测

試、被度量的工程學科。 總結:工程化的勝利 Superpowers的這14個技能,没有一個是關於「如何寫出更優美的詩歌或「如何進行哲 学思考:的。它們全部聚焦於件工程(SoftwareEngineering)的核心難題: L.離度管理(writing-plans,brainstorming)

2.状態管理(using-git-worktrees,finishing-a-development-branch)​

3.質量控制(SDD,TDD,verification)​

1.機制(systematic-debugging)​

這就是一套完整的AI工程師培餐方案。它通過代碼和文檔,將人類高級工程師的性知識 (Tacit Knowledge)顯性化爲Agent 必须遵守的性協(ExplicitProtocols)。 填目檔案(RepositoryProfile)

• Repository: obra/superpowers

• Description:A complete software development workflow for your

coding agents.

• Stars: 35.1k+ | License: MIT

• Author: Jesse Vincent (@obra)

• Core Components: Skills, Hooks (Claude Code), Agents, Rules

Unmarco dehabilidades paraagentes yuna metodologiade desarrollo de software que funciona. Un marco de habilidades para agentes y una metodologia de desarrollo de software que funciona.

原始排版图​

发布于 2026-01-24 00:27:57（微信公众号导出记录）。

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

原文链接：查看原文

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

正文（本地 OCR 转写）​

original wex7ce EI V1ajero 2826年1月24日 00:28 中国垂港 花了點時間把everything-claude-code 这個项目的 Skills系统微底拆解了一遍,现 裡面有不少值得组聊的設計决策。这個项目是Anthropic骇客松的莫作品,經退 1θ個多 月的實際使用打离,理面的 agents、skills、hooks、commands、rules 组件硫實是能直 接上鞋璟的。 Pinned cogsec @affaanmustafa 21h G ANTHROPIC HACKATHON Claude Code v2.1.11 Opus 4.5 - Claude API WINNER /Users/affoon TIPS&TRICKSFOR CLAUDECODE X Article TheShorthand Guide to EverythingClaudeCode Here's my complete setup after 10 months of daily use: skils hooks, subagents, MCPs, plugins, and what actually works. Been an avid Claude Code user since the experimental rollout in Feb, and won.

2.2K​

197 Q39

下面就把我对Skills段计的理解、原始碼分析、以及一些慢化思路整理一下。 目錄 L.系统架構概置

2.Skills的本質:知端數體设計​

3.Hooks 事件驱到系统​

1.跨平台實现技術​

5.核心Skills實现分析​

3.般計决策的權衡​

7.性能與可辱性分析​

3.侵化建​

1.结瞻​

1.系统架構概​

先看整噬结橘,這様後面聊颜的時候不會迷失: Claude Code 主系统 [ 5essionstart] |PreToolUse |PostToolUse I 5essionEnd Hook Hook Hook Hook

Ski11s度贝轨行 1 | snonuT1uo3| strategic | security compact learning reviev

跨平台独象播(ut1ls.js) 文件操作·泄程管理·平台检测·Git集成

Skills 如氮康 (Markdoun + Scripts) skills/continuous-learming/SKILL.md skills/strategic-compact/SKILL.md skills/security-review/SKILL.nd

整個系统的资料流大概是运檬走的: 用户操作CLaude 解析意图→登 Hook轨行 SkiLL 本-输出结果 CLaude + 個架标的健在於分清晰:Hooks負贡酶髮,Skills负贡退辑,而跨平台抽象唇確保一 切都能在不同系统上炮。

2.Skills的本質:知識载體設計​

為何選選Markdown? 傳统的知递管理有带种常見做法:

• 代磷驻爆:和實现期在一起,改起来麻

• Wiki文檔:需要手勤查找,和執行環境是分雕的

• 配置文件:表速能力有限,辩通辑寫不出来

CLaude Code 择 Markdown 作为Ski1ls 的税始,遗圆决策其實挺有道理: 最计豪务:

1.CLaude 原生理解:Harkdown 是规語料之一​

2.版本控制发好:和Git workfLow完英集成​

3.语化標记:YAML frontmatter 提供鳞化元慰搏​

4.人额可插生:滑者可直接畜题和修改​

技術约束:

1.惠教行遥相:Markdown梓是知描述​

2.需要配套卿本:實却软行由.js/.sh完成​

Skill的標举結 每個Sk111都长一因樣: 随符 nane: skill-nane description: Brief description Claude理解用的描述 # Skill Mane ##when to Use [具耀的阐發条件]

• * How It Works

[真现细第] [置现细筛] ##Examples [代碍示例] Frontnatter不只是装,它能被程序解析用来做家引和匹配: //解析frontmatter 的通辑 的道辑 const frontmatterRegex = /^---\n([<s\S]+?)\n---/; const skillMetadata = parseYAML(frontmatter): 51/可以用束: // 1. 自数生成 SkILLs 索引 //7.智能匹配相skills

113、版本控制和经期普理​

知識與辑的分離 这個設計我觉得挺魄明的:把规什和怎塞做分隔 skil1s/ continuous-lcarning/ — —— SKILL.nd 什惠 知量:告斯CLaude 配置赠:定兼行为参款 —— config- json cvaluate-scssion.j5 韩行层:置现绍何货 好虚很明: 维度 好處 可维性 知更新不影答敦行遥辑 可测腻性 敦行通潮可狮立單元测试 可摘展性 同一知端可有多種實现 可移植性 Narkdown可在其他系统復用

3.Hooks事件動系统​

Hooks架構 CLaudeCode 的Hooks系統探用嬰明式配置+匹配器模式J: "hooks":{ "PreToolUse":[ "matcher*:"tool == "Edit" |I tool == -Write"", "hooks*:[{ 'spupumas, =,adf1. "connand*: "node *$(CLAUDE_PLUGIN_RooT}/scripts/hooks/suggc 5leAJaiut 1esffol 1e uoriseduos 1enueu 1sa66nsa :suotidru3sap

这裸的matcher语法有贴像 SQL的WHERE 條件: function evaluateMatcher(matcher, context] { const conditions = parseMatcher(natcher); return conditions.every(c => evaluateCondition(c, context));

境炭量也做得不错: #ClaudeCode鲁注入运些碧境量 插件想目综 CLAUDE_PLUGIN_ROOT CLAUDE_TRANSCRIPT_PATH路记段文件 重话想端符 CLAUDE_SESSION_ID Hook類型與時機 Hook 期型 解發時機 典型用途 性能影春 加械上下文、榆测瑞境

一次性,低影暮​

Sess1on5tart PreToolUse 工具调用前 验温、指截、建摄 每次调用,需高效 PostToolUse 格式化、检查、配 工具用後 每次调用,需高效 PreConpact 低频,可接受 上下文整销前 保存状慧 官話结束 持久化、评信 SessionEnd

一次性,低影​

Stop 智愿完成後 清理、部估 每次答度,需注意 為何選選Stop而非UserPromptSubmit? Continuous Learming Skill 使用 Stop hook 而非 UserPronptSubnit,道個遂 有理由: #hooks/hooks-json 中的驻释 # why Stop hook instead of UserPromptSubmit: Stop runs once at session end (ligitweight)

• UserPronptSubmit runs every message (heavy. adds [atency)

算一下性能差异: #UserPromptSubmit:每次 propt 都就行 5 - uotssssJod sabessou execution_time = 100 @s total_overhead = 50 * 1H8 = 5G98ms Stop:童陆结束际软行一次 total_overhead = 10Bms 性能提升:50X 為何使用stderr? 所有hook那本都的定用stderr 输出: //wtiTs . js:182 function log(message){ console.errar(nessage): // 输出别 stderr 理由很單: L.stdout 被保留给返回绘 Claude 的数 .stderr翻示给用户但不干摄主流程

3.符合 Unix 哲学​

4.跨平台實現技術​

平台检測策略 // scripts/l.ib/utels . js:II - 14 Zeum, === uuojneld·ssaooud = saoputmsT isuo3 1,utip. === eofaeld ssssoud = sosewst 1suos ,xutl, == Buojseld ssaooud = xnutist isuos 對铃Hooks這種轻量级场景,prDces5-platforn用了,不需要引l人额外依。 路径虑理的跨平台抽象 //問题:硬端码监得在不同平台的表理 1,s11tMs/apne1o /-, = 4iedpeq 1suos 上辆法直授工作 11解决方案:统一抽象 function getClaudeDir() { return path.join(getHomeoir(), .claude);

環境爱量展間也感理了: if (config.learned_skills_path) {

文件系統操作的統一封装 跨平台的find實现(替代Unix f1nd命令): function findFiles(cir, pattern, options = {)) { const { maxAge = null, recursive - false ) = options; const results = [1: //glob模式精换為正期表遥式 const regexPattern = pattern .replace(/-/g,.) .replace(/?/g. .); const regex = new RegExpf**${regexPattern}s'); 适障授索實项 searchoir(dir); return results.sort([a, b) => b.ntine - a.ntine);

投针亮贴:

• 细 Node.js 實现,無需依赖外部命令

• 按修改时同排序

5.核心Skills實現分析​

Continuous Learning Skill 合話评估退辑: // evaTuate- sesslon. js:59 - 66 const messageCount = countInFile(transcriptPath, /type":"user/g); If(nessageCount < ninSessionLength){ Log[ [ContinuousLearning] Session too shart (S{nessageCount} messages process,cxit(θ);

為何统計user频型消息?因為它更接近用户交互翰次,能更好地反映會話度。

• nin_session_length*: 13,

11太匠:噪音多:太高:混择有价值的短會話

• patterns_to_detect": [

(1额续解洪模式 1/用户修正模式 "user_corrections", //要通方案 "workarounds*, "debugging techniques*. //调赋技巧 项目转定的定 "project_specific"

目前evaluate-5ession-js只做提示,實账的模式提取需要 Claude 手动执行。道部分其 實可以做得更自動化。 Strategic Compact Skill 工具额用計数器的實现: Jap, 1l prdd ssaaoad 1l oI NDIss3s 3anvis Aua ssaooud = pIuotssas 1suo: const counterFile = path.join(getTenpDir(),*claude-tool-count-s(scssio let count = 1; const existing = readFile(counterFile); 1f(existing){ count = parseInt(existing.trin(), 1e) + 1; writeF1le(counterFile, String(count)); Session ID 的唇级回退策略: L.CLAUDE SESSION ID:CLaude 提供的雷括標蝶

2.PPID:父准程ID(Claude Code 逾程)​

3.default':最後的備逻​

提示策略也抵有心思: 166 50 75 125 首次提示 周期提示 周期提示 遥援25作為周期是因為它大的到鹰一因中等辖度任独的完整流程。 Security Review Skill Security Review Skill是知鳞型Skill,没有配套的敦行群本。它探用正負例對比的 模式: ####X NEVER Do This typescript .xx-faud-ys. = Aaxide isuos xxxxx-od-xs.=faxtde isuo ALWAYS Do This const apiKey = process env.oPENAI_API_KEY

個模式更符合人频提知智情,Claude也能更好理解禁止贝「签勇的遗界。

TDDWorkflow定差了完蔡的测就金字塔:

少量厨链流程 API/显含 中等数量 单元别试|单元现式 大量雁蓝 代碍组端也很清晰: src/ ——components/|—Button.test.tsx單元润试—app/api/| route.test.ts #合潮 e2e/ markets.spec.ts E2E 式

#6、段計决策的耀衡 ##SheLL 鄂本vs lode.s 本 skills目缘中存在”,sh和‘-js’两種言现,而”scripts/hooks/”目缘中全部使用 10 | 复 | Shel1 | Node.js | 腾出 1 ............

1.2跨平台性丨需要滤理差|统一通行時丨Node.1s|​

13丨JSDN 解析丨需翼 jq丨内建支持丨Node.js| |踏换虚理丨校弱丨疆富丨Node.js| 1般速度|更快|特得|SheLL| 然赖管理丨無依赖|需要Node.js丨Shel1| 可语性丨较低|般高丨 Node-js | 建藏统一使用Node.js。操牲少量欣勤运度换取可体露性。 著善Hook的蜡联鹰理策略 所有hook 聊本统一的继误虚理硬式: javascript nain().catch(err => { console,error( [Skillname] Error:', err.message); process.exit(e)://键:不阻塞主流程 }) ; 這是侵雅降级的策略:Hook失-记錯误-不影赛Claude誓鹰 但这也有潜在問题:

• 静默失可能隐服重錯误

• 用户可能不知道 Skil1未正常工作

可以考虚可配置的錯误虑理模式。

7.性能與可靠性分析​

Hook敦行性能 每次工具铜用的额外闻销: PreToolUse Hook

• 5m5(文件尬)

|Suggest Conpact; ~200ms (tsc I Type Check: Prettier Fornat: Jatllaud) su5- (2TJA-- 10ms (grep) Console Log Chcck: 谢开:-265ms/工具调用 TypeScr1pt频型查是性能瓶照。可以考增量频型检查: 11只检查账改的文件 const changedFiles - getGitModifledFiles(['-(ts|tsx)$']); If(changedFiles.Includes{filePath){ runTypeCheck(filePath); 亚發舆航態條件 suggest-conpact.js有在的航修件: //多留Hook 向崎镇离counterFiTe // Thread A: readFile() → count = 16 4// Thread A: writeFITe(II) 5//Thread 8:writeFile(1I)//愿是 12 解决方案是使用文件额: const lockfile - requiref'proper-lockfile'); aMait lockfile.lock(counterFile); const count - parseInt(readFile(counterFile)) + 1; uriteF1le(counterFile, String(count)): aMait lockfile.unlock (counterFile); 内存浊漏風险 脂時文件未清理的間题: 11如果會菇据常结束,文件育一言存在 const counterfile = path.join(getTenpDir(). *claude-tool-count-s{sessi 11解决方案:定期清理 function cleanupoldcounters() { const tenpnir = getTempoir(); const files - findFiles(temppir, claude-tool-count-); 81 4 99 *09 + +=x0 1510 const now = Date.now[); files.forEach( path, mtine ) => { if [now - ntine > oneweek) { fs.unlinkSync(path) : } }

8.優化建​

架眉面 Skill自勤驻册奥發现 需前Skills需要手勤在huoks.json中册。可以實現自勤發现: function registerskills() { const skillsDir = path.join(__dirnane, ., *skills'); const skillFolders = fs.readdirsync(skillsDir); const hooks = (); skillFolders. forEach(skillNane => { Const skillconfig = loadskillconfig(skillNane); const hookFile = path.joln(skillsDir, skilLNane, hook.1s); if (fs.existssync(hookfile))( //根球skill.json 自黏生成 hook 配置 hooks.SessionEnd = hooks.5essionEnd 1l []: matcher: skillconfig-trigger.matcher 1l + hooks: [{ type: 'conmand', 1

: ({

Skill依赖管理 skITLs/securty -revfew/skll. j son "nane": "security-review",

• version": "1.0.0*,

• depends_an*: [verification-loop1.

• conflicts_with*: [],

• prlority°: 10

11依频解析闽加载质序 function resolveloadorder(skills)( const graph = bulleDependencyGraph(skills): return tapalagical5ort(graph); 實现唇面 增量频型检查 11只检查逐改的文件及其源入键 async function increnentalTypecheck(changedFite) ( const dependents - ana lyzeDependents (changedFile); const filesToCheck = [changedFile, -..dependents]; const result = await execsync( 'npx tsc --noEnit sfilesTocheck.join*)*, { cwd: projectRoot } ) ; return result;

Hook结果存 const hookCache = new Map(); async function executeCachedHook(hookName, context) ( const cachekey = s[hookName}:s[JsoN.stringity(context)]: return hookCache. get(cacheKey): const result = avalt executeHook(hookName, context): hookCache set(cacheKey, result); return resutt; 签行 Hook敦行 //强立Hook签行执行 const independent = hooks. filter(h => 1h.dependencies); const results = await Promise-all( independent.nap (h => cxecuteHook(h)) for (const hook of dependent) { awalt executeHook(hook, results);

可觀测性增強 Hook敦行日 class HookLogger { static lag(hookNane, phase, data) { const logentry = { timestanp: new Date().toIsostring(), hook: hookNane, phase: phase, data: data, duration: data duration }; 10 11 appendFile( path.join(getClaudeDir(),‘hooks.log'), 1 2 JSON.stringify(logEntry)+'\n' 13 1 4 ); : 15 16 性能监控 class HookMetrics { static record(hookName,duration){ const metricsFile = path.join(getclaudeDir(),‘hook-metrics.json') let metrics = readFile(metricsFile) Il {}; metrics[hookName] = metrics[hookName] Il { count:0, maxDuration: 0 10 11 metrics[hookName].count++; 1 2 13 1 4 metrics[hookName].maxDuration, 15 duration 16 ); 17 18 writeFile(metricsFile, JsoN.stringify(metrics,null, 2)); 19 2 0 2 1

9.結​

这個Skills系统做了一些有意思的誉試: 做得好的地方: L.知識與遥辑分離:Markdown承载知識,本實現邂辑 ?.事件動架構:Hooks提供非侵入式的摘展機制

3.跨平台抽象:統一的工具函數封装平台差翼​

1.優雅降級:Hook失败不影響主流程​

5.可组合性:Skills可以组合形成更复雜的工作流​

可以改進的地方: L.缺乏SkiLl自動發現機制

2.無依赖管理系統​

3.TypeScript類型桧查是性能瓶​

1.文件操作缺乏發安全機制​

.可觀測性不足 ClaudeCodeSkills系統代表了一種知工程化的試:將人類的最佳實、模式和經驗 轉化為可執行、可重用、可進化的组件。然在實現上仍有改進空間,但其設計理念為AI辅 助開發的未来發展提供了有價值的参考。 未来可以發展的方向包括:SkillMarketplace、AI生成Skills、版本控制集成、團隧協 作機制等。 参考資料 L.Claude Code Documentation

2.Event-Driven Architecture Pattern-Martin Fowler​

3.Everything ClaudeCode-ThecompletecollectionofClaude Code​

configs from an Anthropic hackathon winner.Production-ready agents,skills,hooks,commands,rules,and McP configurations evolvedover 10+ months of intensive daily use buildingreal products.

1.Cross-Platform Node.js Development -Node.js Design Patterns​

原始排版图​

原始导出图超过单张 WebP 的尺寸上限，以下图片按从上到下的顺序连续保存。

发布于 2026-01-22 20:30:22（微信公众号导出记录）。

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

原文链接：查看原文

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

正文（本地 OCR 转写）​

術 originalwθx7ce EI V1ajero2826年1月22日26:30美国 “If you can't beat them,join then."—NaiveProxy 的股哲學

preert,poting. Nalve Server Server Padkit Lergh Padcing Lsyer

CadR

在翔络安全與隔私保满的長期博奔中,各频流量种發工具(Shadowsocks以及VMess, Trojan等協)都在试图战計一橙“特微不明*的私有罐。然而,随著深度包檐测(DPI) 奥流量特微别技術的进化,基於模凝的罐始避以完全消除指紋。 NaiveProxy遥捶了一截然不同的技術路線:它不模凝Chrome测實器,它直接用了 Chrome的钢横。 本文将基於src/net/Lopls/naive/源码,為您呈现一份最鲜重、最硬核的 NaiveProxy 技術内幕剖析,探其在阐混滑與抗干方面的卓越投計。 架構設計之美(Architecture)

1.1為何選挥ChromiumPatchset?​

NaiveProxy 不是一個立阿發的钢然,它的本質是Chromium测宽器斓棱(Network Stack)的一個捕丁集(Patchset)。 这是一個天才般的投計决策,原因如下:

• 指纹一致性(Fingerprint Consistency):

• TLS 指紋(JA3):CL1ent Hello 中的加密套件(C1pher Suites)、摘展

(Extensions)、ALPN 颠序等,是由 Chromium底层的//net虚决定的。 NaiveProxy直接编露了这固障,因此它的TLS指纹與全球數十像用户使用的 Chrome 浏質器完全一致

• HTTP/2 行為:流控窗口(FLowControlWindow)、帕發送顺序、跟部墨缩

(HPACK)策略,全部德用Chrome的通辑。

• 维罐成本(Maintenance):

• 每墨Chrone升级支持新(如 HTTP/3,QUIC,TLS 1.3 的新特性),

NaiveProxy通通代碼rebase 即可自動承最新的安全特性與性能優化.

1.2横建系統(BuildSystem)​

NaiveProxy 的模建深度集成尬 Chromium 的 GN(Generate Ninja)系统中。在sr c/net/BUILD.gn中,我们可以看到其定裁: (aATeu1qe1naxa sources = [ "tools/naive/nalve_protocol.cc*, 其他核心文件 1 = sdap 强接Chronium核心螺结序 "net", 键接Chroniun基硬座(馥程,内存管理) "//base", "//url", 建接URL解析罩

这意味著NaiveProxy二进制文件本質上就是由GoogLe的编温键生出来的,速端参数 優化都奥Chrome 保持一致。 協定羲與線路格式(ProtocolInternals) 这是NaiveProxy能狗實现致装的核心技術。即使流量经返TLS加密,數據包長度 (PacketLength)依然是明文可見的。传统的随道往往忽路了这一點,導致被流量分 析模型滋别。

2.1流量填充機制(Padding Mechanism)​

在源碼 src/net/tools/naive/naive_padding_franer.cc 中,NaiveProxy 黄现了一套字 前级的填充機制。 常速接建立,封於前8個数據包(涵蒸了TLS提手完墨後的HTTP/2设置帕與首個清 求),媒言强行插入填充数據。 線路格式(Wire Format)到底是怎檬的?很多人maive_protocal.h裡注释摔的结福 感到困恶。實际上,C++中為了證免内存封密問题,通常不會直接傳輸结體,而是逐字前 客入,真實的二进制流结標如下: L.每個HTTP/2 DATA帧的负鞋(PayLoad)被重新封装:

• 2字廊:真實数擦侵度(Big Endian)。

• 1字:填充侵度(Padding Size,投為 P)。

• N字:真實数據

• P字廊:全θ填充数

2.遍個P是一個[0,255]赢随的髓機数(由base::randInt生成)。遍意味著,哪​

怕原本是固定长度的握手包,經過这唇”充氯“後,长度也會得随機不可预测。

3.封装:上述二进制流被放入福革的HTTP/2DATA帧中俩输。​

1.外:HTTP/2领再被 TLS1.3 加密。​

果:中開人投借看到的只是一德标弹的、長度随机的TLS流量,無法遵遇包長度特微进行额 Bl。

2.2應用前置(Application Fronting)​

為了防繁主勐探测(Active Prob1ng ),Na1veProxy 探用了Application Fronting 架横。通遇部署Caddy(Web Server)进行分流 源碼src/net/tools/nalve/http_proxy_server_socket.cc展示了服榜端校验退辑: 1//罐取求验中的Proxy-Authorzation proxy_auth = headers.GetHeader(HttpRequestHeaders:kProxyAuthorization) 4// 翼预证的 Basic Auth 哈希比對 5 if (proxy auth != basic_auth_) { return ERR_INVALID_ARGUMENT; // 返图端, Coddy 回落到 filc_scrVcr

• 场景A:外部摄描/爬数

• 發送標HTTPS請求,但不带密碼(或密碼錯误)。

• Caddy判定爲非法代理請求->路由到静文件服器。

• 果:描者收到一個真實的index.html網真。網絡行為特微顯示這是一個正常的

Web服務。

• 場景B:Naive客户端

• 發送請求,頭部包含Proxy-Authorization:Basic<hash>。

• Caddy驗證通過->路由到naive代理模瑰。

• 結果:建立蔽隧道,進行跨網絡通信。

傳輸層協對比一HTTPSVSQUIC 在config.json中配置的協頭(https://或quic://)直接决定了Chromium網 絡機的行為。

3.1 HTTPS (TCP + TLS 1.3)​

• 解發件:proxy:"https://..."

• 底層實現:觸發ProxyServer::SCHEME_HTTPS。Chromium建立TCP連接->TLS

握手->HTTP/2CONNECT。

• 技術特點:

• 塞控制:默使用BBR(Google出品的塞控制算法),在複雜網絡環境下比傳統

CUBIC更好。

• 穩定性:TCP與互聯網基設施兼容性最好,連營商QoS侵先級通常较高。

• 缺陷:無法避免隧頭阻塞(HOLBLocking)。如果底層TCP丢了一個包,整個

HTTP/2隧列都要等待重傅,導致高延場景下出現抖動。

3.2 QUIC(UDP +HTTP/3)​

• 解發件:proxy:"quic://..."

• 底層實現:觸發ProxyServer::SCHEME_QUIC。Chromium建立UDP連接->QUIC

握手->HTTP/3CONNECT。

• 技術特點:

• 0-RTT連接:基於UDP,不需要TCP的三次握手,建立連接極快。

• 獨立流控制:解决了TCP的隧頭阻塞問题。一個流丢包不會影響其他流(例如多路復用

時的互不干)。

• 連接移(ConnectionMigration):客户端IP化(如網絡切換)時,QUIC

連接不會中。

• 缺陷:UDPQoS策略。部分運營商網絡會對UDP持續流量進行限速或丢包抑制(判

為P2P下载或攻撃流量)。若發現連接不畅,建切换回HTTPS模式。 常見隧道協横向測(ComparativeAnaLysis) NaiveProxy在協混淆领域的表現如何?我們將其與其他常見協進行技術維度的對比: Protocol S ProtocolT ProtocolV NaiveProxy 维度 (Shadowso (VMess) (Trojan) cks) Chrome Network St Go net/htt 私有協 私有協(TC (TCP/mK 傅翰層 P/UDP) p (H2) CP/WS) ack (H2/H3) 较差(需依赖uTL TLS

一般(Go語​

無(通常不走 完美(Chrome

一致)​

指紋 言特微) S等外部庫) TLS) 無(長度特微 Paddi 随機长度填充(前8 無 無 包) 明) ng 完美(Caddy强分 優秀(Nginx 抗主動 较差(容易被

一般(路径分流)​

流) 探測) 探测 分流) 性能 極低(Rust/ 低(C++Native) 低(Go) 中(GoGC開) 銷 C) 部署 高 中 中 低 度 结:

• NaiveProxy是目前匿性與抗干摄能力强的方案,適合對抗深度包检測技術。

• 對於需要極致吞吐量且網絡環境较為寬的場景,其他輕量級協可能仍有其優势。

NaiveProxy亚不是一個網絡工具,它是一種協偽装技術的致體現。 其他的方案在辛苦地試模凝测質器的行為,修補TLS指紋的漏洞,而NaiveProxy直接使 用了器本身的核心代碼。這不保證了流量特微的完美融合,更站在了Google强大工程 能力的肩膀上,獲取了最先進的網絡傅輸性能。 對於追求極致穩定、安全與隐私保護的技術人員而言,NaiveProxy無疑是一個值得深入研究 的對象。

原始排版图​

发布于 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-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...等多種程式碼與純文字格式。

原始排版图​