发布于 2026-08-02 23:25:40（微信公众号导出记录）。

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

原文链接：查看原文

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

正文（本地 OCR 转写）​

小数點裡的C2C舍入避:6.7匯率找到真正的划算點 oriqinalwex7ce EI V1ajero 2826年8月2日 23:26 美国 很多人看到BinanceC2C 丽告寒著6.7CNY/USDT,,旁通又檬若盖最多20 CNY,第一反 愿通常是:

72

既然最多可以買20元,那就直接胃逼,廉被最划算。 但置察试展次就會發现,事情没有那磨简單。 具 2.97 USDT, 支付 19.89 CNY; 看起来多胃了0.01USDT,只多付了0.97CNY,但接照6.7的理噻率针算,2.97USDT反 而留下了 0.009 CNY 的尾差, 2.98 USDT 只留下 0.006 CNY. 也就是龄:

• 買得更多,不一定代表單垂最划算;

• 展告上的6.7.不一定是實账成交匯率:

• 0.089CNY 不一定全是商家主動糖利;

• 盖最多20元,也可能不只是若通的交易限制

這背很其营同時存在雨套盈辑:

一套是小数精度确来的数學现象,另一套则是商家登布小额腐告時可能报用的叠通策略。​

先看2.97和2.98到底差在哪里 概投腐告区率是6.7CNY/USDT,黄入数量接0.01USDT 增加0,支付金智按0.01CNY针算, 单且平台探取向下截取, 这程格束期不一定是“四拾五入,,而更是把第三位小数直接措去。 例如: 理输支付金额 真际支付金额 理输尾差 员入数量

2.96 USDT​

19.832 CNY​

19.83 CNY​

0.062 CNY​

2.97 USDT​

19.899 CNY​

19.89 CNY​

0.889 CNY​

2.98 USDT​

19.966 CNY​

19.96 CNY​

0.006 CNY​

2.97 USDT 的關健在龄:​

19.899 - 19.89​

小數黏後第三位是9,向下截取到分之後。刚好留下0.009CNY的差。

2.98 USDT BI是:​

19.966 - 19.96​

只留下 0.006 CNY. 所以,2.97比2.98亚划算,首先是因為雨個数字在小数點上的薄贴不同 這不是胃得越多越划算:,而是每增加0.01USDT,理金额在人民警小数贴上的位置都會重新 化 圆一|6.7率下,單筆理尾差的曲線 据對括入收益(CNY) /值: 0.009 CNY, 出果在 0.07 + 0:10k USDT

USDT期其肿量 這强图把3.81到2.98USDT的理输尾差全部董出来。曲線不會平滑上升,而是反覆锯髓,因為 每次增加9.91USDT,支付金额都言重新遇到「分:的碰取位胃。 在6.7医率下,单董理尾差的最大值是0.009CNY。 所有出现最大尾差的数量券:

0.07,0.17、 9.27、、 2.97 USDT​

因此,在20元上限以内:

• 最大可胃数量是2.98USDT;

• 最大盖理尾差出现在2.97USDT;

• 2.97比2.98少算一贴,但理逾尾差反而多0.BB3CNY.

这已经战明一件事: 「胃到上限,和得到最大尾差,不是同一個目標

6.7不是每一筆交易的實際匯率​

腐告期示的6.7,只是商家段定的名薪报。 真正完成交易之後,虑龄用下面的方式計算實隐成交率: 官源成交率=宽摩支付CNY+胃原收到USDT

2.97USDT的實障成交率是:​

19.89 + 2.97 = 6.696970​

2.98USDT的實降成交率是:​

19.96 ÷ 2.98 = 6.697987​

因此:

• 2.97USDT的實账成交匯率更低;

• 2.98USDT的置除成交虚率反而更接近6.7;

。6.7是广告报價,不是每一董交易都完全相同的實除匯率。 这裸至少要医分三医概念: 名利 含 广告过率 商家责面顯示的6.7 置支付金额除以真零收到的USDT 食際成交国率 商家成本建率 商家取得USDT真正付出的成本

第三個数字通常看不到​

所以,不能只因為员方實账少付了8.009CNY,就直接定商家损失了9.689CNY。商家可能以更 低的震格取得USDT,也可能适退其他交易得差。 超额收益要分成種 如果把下面请因数字稀为“理尾差」: 理尾差G=告虚率×黄入数量-實支付金额 那磨G只代表相到股名囊报价的数学差额,不等於真正利稠。 單筆對尾差 單筆绍對尾差回答的是:

一肇交易绑共少支付了多少CNY?​

以6.7区率為例:

• 2.97USDT:理糖尾兼是0.009CNY;

如果只追求肇拿到最多的能剩尾差,那度2.97比2.98好。 單位USDT的超收益 单位超额收益=理验尾差+買入数量 它回答的是: 平均到每一個USDT,上面多出了多少尾差? 员入数量 理输尾差 单位超额收益 ANOL83°6

8.01 USDT​

8. 780688 CNY/USDT​

8.87 USDT​

9.089 CNY​

8.128571 CNY/USDT​

8.089 CNY​

2.97 US0T​

IOSN/AN3 6E3E88*8

9.086 CNY​

2.98 USDT​

8.082013 CNY/USDT​

圆二|每個USDT分到的超额收益 单位插期收益(CNY/USDT)

1.5​

USCT期图致量 这张图會呈现出一修向下衰减、但带有退期据查的曲德。数量越小,同标的装厘线尾差分到每個 USDT上,比例就越大。 如果平台允許寞0.01USDT,那磨9.91USDT的單位超触收益最亮:

3.007 ÷ 8.01 = B.7 CNY/USDT​

但请一年官只多出0.037CNY。 道就是小额交易常见的销景:

百分比看起来很高,不代表霄弥睡到的器很多。​

按報價計算的理收益率 理收益率=理输尾差+理输支付金额 它回答的是: 这個尾差相對於理输支付金额。占了多少比例? 理险尾差 理瞻支付 具入数量 理输收益率 %5+*6T 6g

8.01 USDT​

9.667 CNY​

3.667 CNY​

ANO 69b*B

8.87 USDT​

9.869 CNY​

1.92%​

2.97 USDT​

9.069 CNY​

19.899 CNY​

0.0452%​

19.966 CNY​

0.0381%​

2.98 USDT​

9.886 CNY​

圆三|理收益率會随交易金快速下降 理编收益率(%)

0.01 USDT: 10.4470%​

LSCT期提数量 同样的尾差,如果分到很小的交易金额上,收益率鲁非常高;但随著買人量增加,收益率會迅速下 降。 因此,美图!最優:其實各自不同:

• 遍求最多USDT:買2.98;

• 遍求盖最大尾差:買2.97、1.97、1.87等退期位置;

• 遍求单位USDT的超收益:如果平台允許,0.01USDT最突出;

• 遍求理检收益率:小额数量通常更高:

• 遍求宵降可操作性:温要考虚最低限额、手颁蛋、付款风险和時間成本。

所以不存在一個脱雕目標的唯一最侵員法。 換成任意匯率×,规律會怎? 把率6.7换成任意的X 股:

• X:虞告属率;

h:USDT 最小交易步进:

• C:CNY最小站算肇位;

• q=nxh:第n個可交易数量;

• P:宽降支付金额

理支付金额為: 理金额=xxq= 如果平台把支付金额向下截取到C: 寶踪支付P=理输金保留到C位後,直接涂去多小数 项物尾差: G = x x q - P 真正决定曲综遇期的,不只是医率大小,而是: α = ×× h ÷ c 如果α 的分後是8÷b,那度:

• 尾差曲综的遇期是b個交易步进;

• 理最大尾差是Cx(b-1)÷b.

在USDT步速和 CNY 精度都离 0.01的辆况下,h-C=0.01,因此α 就等於 x、 基個区率的例子: 广告匯率 的分德的分母 尾差退期 理输最大尾差 黄告通率 10步 67 ± 10

6.79​

0.069 CNY​

671 + 169 169步

6.71​

0.0699 CNY​

6.75​

27 + 4 4步

0.8875 CNY​

6.89​

5步

0.068 CNY​

S ÷ 5多 34 + 5 这個结果很有意思: 盈率越高,不代表尾差一定越大;真正重要的是医率、交易步进和结算精应组合後的分母。

6.7 之所以每16個8.81 USDT 出现一次相同楼式,是因為:​

6.7 = 67 ÷ 10​

所以调期是10步。 20元上限和率的關係 如果單至上湿為H,USDT最小步道卷h,在平台按照理金额限制的情况下: 最大交易步数n-M÷[xxh]向下取整 最大 USDT 数量q=h×n 當 M = 20、 × = 6.7、 h = 6.61 時: 20 ÷ 6.7 ≈ 2.98587 按号.01USDT步进向下取整後: 最大数量=2.98 USDT 因高:

• 2.98 × 6.7 = 19.966 CNY;

• 2.99 × 6.7 - 26.033 CNY。

所以2.98主要是28元上限和6.7率共同针算出的结果,不一定是商家特别挑出来的数字。 圆四|匯率、單筆上限舆尾差上限的隋梯關係 报债原率鼻單筆擒入收益上限(CNY) 6,70 国率: 00050 NY

0500Y

0.0025​

6.40​

6.20​

6.60​

整率r (CN/USDT) 当厘宰化時,最大可買USDT慰量不會平滑下降,而是以一格一格的方式斑动:理输尾差也會依照 小数分母形成不同遵期。 如果平台不是向下截取,而是探用四拾五入,以上规建就要修改,最大尾差也可能降低,因此,最终感 以置察打单真面和成交配察為辈,不能只依到展示真面推测。 為什商家要設一條最多20元的廣告? 这才是整件事情更值得研究的部分。 小数入只能解释: 为什度2.97是0.009,2.98 是0.006. 但它不能解转: 為什度商家要發布一条最多28元的质告。 這视可能有差種原因。 可能是小额引流 商家可能用一個比较容易接受的震格,配合很低的單革上限,新用户先完成一次低风险交易。 對新用户束就,28元的心理門楼很低:

• 不需要一次投人大量资金:

• 可以先测试付款和放聚流程;

• 交易出现開题時,损失相對有限:

• 完成後可能留梁量看同一商家的其他属告。

Binance 的官方瞻證商家計量,建實将吸引更多訂單、提高订單畅化、骤得更多流量和手瓷優惠列 为商家利益。 Binance P2P Verified Merchant 针董 因此,28元小融腐告可以被理解为一種低門感人口:。 这不代表每一條28元属告都是属告投放,但徙商繁角度看,这種设計是合理的。 可能是在累精訂單數或完成率 你提到的!剧量:也有可能,但流要分清楚副的是什磨。 如果只靠每一肇的0.089CNY昆差:

• 100單只有8.9 CNY;

• 1,000单只有9 CNY;

因此,商家不太可能單纯為了这變厘而大量下功夫。 但商家可能看重的是:

• 累計成交盖数:

• 30天初單数;

• 訂翠完成率;

• 商家真面的活證度;

• 新客辅化;

• 某個支付方式的成交記绿:

• 可能存在的商家率或等级条件。

Binance 的官方商家資料中,會展示德訂單数、38 天订單数、38 天完成宰等資訊;育家规用也提 到部分商家寶率優惠交易量、完成率有题。 https:/v.bnne e/ruKZ/sst/fa/etat1/33511 所以,如果一因商家長期發布20元上限的小额腐告,而且持有大量完成訂單,那座「累稍訂單 数、完成率或商家活理资料:的可能性就會增加。 不通,這仍然只能叫「可能1,不能直接酬定是剧量。早台亚没有公脱明某一28元腐告一定會 需来排名提升,也不能擎靠上限金额判定商家正在剧数播。 可能是風险控制 C2C商家面到的不只是匯率风险,還包括:

• 付款人姓名不一致;

• 高风除调金:

• 付款後事播;

• 收款幅户被凰控:

• 到手方申诉;

• 付款渠道不辑定:

• 新帐户或新支付方式测试

把單革上限控制在28元。可以把單次交易凤激量到很低。 Binance官方商家规则也强調付款姓名核数、风险调金、保盘金、申诉和場外交易等周 ats://.em/n/ert/f/sets/3511 因此,一修20元虞告也可能只是:

• 测试一回新的付款帐户:

• 测腻某固银行或支付渠道;

• 降低第一次交易的风险:

• 先飘察到手方是否正常;

• 只拿出少量座存进行交易。

這種情况下,商家不一定是在旗利,而是在用一至小额交易测赋整個流程。 可能是不同支付方式的專用廣告 28元上限通常是某一修质告的限制,不一定是商家所有展告的限制。 同一個商家可能同时拥有:

• 大额主腐告;

• 20元小颜质告;

• 不同报行的付款质告:

,不树支付方式的案告; ,不同時段的展告:

• 新用户票用度告:

• 剩除理存属告。

B1nance 的P2P 工具資料中,虞告本身就可以段定量小章重金融和最大單至金额等榻位。 https:/ve.binznce .ces/en-3H/skdiLts/detai1/blnance/p2p 所以看到「最多28元時,不能直接理解成: 这個商家键共只有20元的USDT。 更沸的理解是: 这一条质告,每一单最多只允萨成交28元。 也可能是商家有更低的進貨成本 如果商家取得USDT的成本低於6.7,那度即使實隐成交匯率略低於6.7,也不一定。 假投商家的取得成本是6.68:

2.97 × 6.68 = 19.8396 CNY​

舅方支付19.89CNY,商家的名薪差额益:

19.89 - 19.8396 - 0.0504 CNY​

此時即使平台的精度操商家少收到类厘鳞,整单交易仍可能有正向债差。 因此,黄方看到的:

6.7 × 2.97 - 19.89 = 0.669 CNY​

只是相對於腐告区率的理尾墓,不是商家的真實利漏,也不是商家的真害摘失。 怎樣判断它是不是引流或刷量? 可以翻察费個现象。 裂察到的现象 更可能的解耀 惯格和其他商家差不多,只有上限20元 氟控、支付方式潮腻或小输存 惯格明期低於网類胰告,而且固定最多28元 引流或小潮促销可能性提高 同一商家遇有更大操的普通展告 28元属告可整是入口型展告 可能是持引流或进持打單活疆度 成交後剩额很快相回 成交不再福回,剩除额慢量消失 更像零碎库存或一次性利 商家30天訂举数很高。但大多数演告上限很小 可能在累稿订单数或完成率 广告绿款出现新用户、首单、限隔等字桥 引流或促的置排更直接 主要仍然是含入现家 只有9.689、9.866遗類尾差,轮情显不比市塘低 真正需要对比的,不是單的看6.7,而是: 市增同离告区率-條虞告区率 如果这條质告只是6.7,而附近其他廉告也是6.7.那度8.889主要是精度道成的。 如果附近其他展告是6.72。而道质告是6.70,那座真正的慢惠主要来自匯率差,而不是小致尾 差 最後,哪一種買法才算最優? 答案取决於想最大化什度。 如果想最大化页入数量:

2.98 USDT​

如果想最大化20元以内的单至理输尾差:

2.97 USDT​

因离:

6.7 × 2.97 - 19.89 = 0.669 CNY​

如果想最大化每USDT分到的超额收益,而且平台允萨極小额交易:

0.01 USDT​

但这時然理收益率很高,實察只多出0.007CNY,副金额非常小 如果想真正做交易决策,遗必须加入: 主导本

• 付款渠道费用:

• 聘帐时;

• 最低下单金额:

• 付数帐户风险;

• 申新和凌结凰险:

• 是否允许重框小额下單。

不能為了追逐0.009CNY,忽略一次付款具常可能束的降圈成本和幅户风险。 結語:這不是一個穩定套利漏洞,而是一個有趣的市場 現象

6.7率下,2.97USDT比2.98USDT更划算,實可以用小数精度解释:​

19.899 - 19.89​

面:

19.966 - 19.96​

但这只解释了「差额為什度不同:,没有解霜商家為什度發布一條最多28元的质告」。 28元上限背後,可能同時存在:

• 小额引流;

• 首促销:

• 訂单数或完成率累和;

• 支付通道润试:

• 新螺户凰控:

• 零碎重存虚理;

• 商家自息的低成本准货:

• 普通的广告参数投定,

比校合理的制结是: 小数拾入决定了每一董交易的尾差落在哪理:商家策略刚决定了為什度這修20元质告言存在。 所以,这恒现条值得研究,但不能直接蓄成定套利概言。 在6.7、0.01USDT步谁和6.01CNY结算精度下,單筆理尾差最多只有0.0B9CNY。即使 利用到最理想的位置,收益也非常有限;一旦扣除手错贵、時圈成本和支付凰险,察套利空周通常很 小 它更像是一個藏在C2C小数黏理的「拾入道:: 看起来只是多了厘,背後同時章涉到数字精度、属告设計、商家流量和交易風控。

原始排版图​

发布于 2026-07-30 23:53:47（微信公众号导出记录）。

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

原文链接：查看原文

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

正文（本地 OCR 转写）​

GoogLe DeepMind除指出,十年来,人刊一直副待概影人能自然进人日常圾填业提供摇助、Gen1n1 Robot1cs 2 是朝请国方向推连的新一步。 目前多数機器人仍依确预先蕴程或通端操控,只能執行航有限、重拖性高的任務流程。它們缺乏自主 學留與逾愿不可预润跟瑜的能力。此外。把一理機器人本體学含的技能螺移到另一程本體,仍然十分困 若要大规模虑理更困鞋的现宵開题,各種形感买尺寸的概器人都需要一塞AI模型,它仍能购思 考、行動、理解互動,亚安全地完成任務。 此前,Google DeepMind 显账已适通 Gemin1 Robot1cs 展示 Gem1n1 的多模理解能力,如 何聊化为真置世界中的行動。 现在,圈原推出Genini Robotics2,將它定位為下一代高退性機器人的智慧唇。官方列出的主 要选展包括:智慧的全身控制、更道赌的精细操作,以及多磷器人協作。 GeminiRobotics2能楼器人到勤作泄行推理,而虚理更离泛的任强。例如,它能控制人形楼 器人行走、群下、神展身體操作物件,请理一間维乱的房間:也能旗不同機器人组除合作,更快完成 工作。 这套能力遗能直接在装置端本地通行,单在短短燃個小時内,逾感全新的概器人身禮 先清:GeminiRobotics1.5已經具備哪些能力 「會推理:與跨機器人本琴警,亚不是到Gemini Robotics2才首次出现。 Google DeepMind 在 2025 年黎布 Gemini Robotics 1.5 ,已螺介韬遇以下能力:

• Gemini Robotics 1.5 (VLA)

:能在探取数作前进行思考,呈现其處理通程:也能跨不同機器人本禮学智,加快新技能的取 得。

• Gemini Robotics-ER 1.5 (VLM)

:能到物理世界进行推理、原生呼叫数位工具,亚為施维任務建立群细的多步震計董。 因此,更单確的般法是:GeniniRobotics2延了上一代的代理式推理奥跨本醋學置,亚把重贴 推進到完整人形機器人的全身控制、更精细的手部與夹爪操作、多機器人作,以及更快的装置端新本 以上比较综合白GoogleDeepMind 的雨跨官方文章: Gemini Robotics 1.5: https://deepmind.google/blog/genini -robotics-15- brings -a1 -agents -1nto -the-phys1cal -world/ Gemini Robotics 2: https://deepmind google/blog/genini- robotics-2-brings- whole-body-1ntel11gence-to-robots/

三個模型,構成GeminiRobotics2的核心​

Google DeepMind 图除透通三能力各有谢重的模型,置现這套全新的機器人智慧:

1. Gemini Robotics 2​

Gemin1 Robot1cs 2 是 Google DeepM1nd 目前最先进的视登链言触作模型(V1s1on- Language-Action Model, VLA ) 。 它可以把视覺网言输入直摇聘化為通勤控制。遗個模型能控制完整的人形機器人,一路到指 尖。也能控制其地要臂确器人。同時,它提高了機械手奥夹爪的精细操作能力。 官方页面: https://deepmind.googLe/models/gemini-robotics/vla/

2. Gemini Robotics ER 2​

Gemini Robotics ER 2 是 Google DeepMind 目前能力最强的具身推理模型(Enbodied Reasoning Model, ER). 它本贺上是一個视景能言模型(Vision-Language Model,VLM)。在整套系统中扮演高陷代理的 角色。它能壤喷器人奥人频满通、理解物理世界,亚规勤持须数分鐘的多步释任称。遭次更新也首次加 入了多操器人组际合作的能力。 官方页面: https ://deepmind google/models/gemin1-robotics/enbodied-reasoning/

3. Gemini Robotics On-Device 2​

Gemini Robotics On-Device 2 是 Google DeepMind 目前最高效的 VLA 模型,專為在機器 人装置上本地通行面最佳化。 只需要期回小時的資料,它就能快速通感完全不同的新型機器人本。 官方页面: https://deepmind.google/models/gem1n1-robotics/on-dev1ce/ 【素材位置02|能力許测图,建还放置3张】 图1:一般全身操作

• Apollo 2 搭配 Insp1re 模械手

桌面拾取:68.4%

• 地面拾取:45.7%

• 架拾取:76.34

General whole body manipulation 100% 80%

公iajero 图2:多指精操作

• Apollo 2 搭配 Sharpalave 械手

• 旋整增涨:36%

• 旋澄泡:92%

• 绑垃圾袋:44%

• 操作鲁其:32%

• 封合爽经袋:40%

E*jero Tle trash beg 图3:夹爪精操作

• Franka Duo 嬰肾平台

一般取放:74.2%​

• 多横化工具配套:78.9%

精密播入任:89.6% Gripper dexterity

三画共用画:同一图Gemini Robotics2模型检查,可控制三种不同的糖器人形振:搭露​

Sharpalkiave 機械手的 Apptronik Apollo 2、港最 Inspire 槐械手的 Apollo 2.以及搭藏 Robotiq夹爪的Franka Duo,每根柱状墨代表同一技能频别下多项任移的平均成功率;多指任務 则分别量现单n表现。结果额示,Gemin1Robot1cs2在全身嫌作爽爪精组任移上已还到中高成 功率,但多报精细摸作依然是姓度较高的挑哦。 Gemini Robotics ER 2 推理模型现已在 Google AI Studio 開放使用,显在Gemini Enterprise Agent Platfonm 提供私人预暨. Google AI Studio: https://ai.dev/prompts/new_chat?nodel=gemini-robotics-er- 2-prev1ew GomgeA3

y

hirni

Gemin1 Enterprise Agent Platform: https://console.cloud -google.com/agent- platform/publishers/google/model-garden/gen1n1-robotics-er-2-preview-info VLA與0n-Dev1ce模型目前别面向早期合作移伴放。考想了解如何把遭些模型源人自己的楊器人 硬,可前往 Google Developer Blog 查看相明。 早期合作罗伴申:https://docs.google.con/forms/c/1sM5GqcvNkv-KnKY3TOMpvtQ- LDFeAftQ-d9xQn92jCE/viewform?ts=67cef9866edit_requested=true Google Developer Blog: https://blog google/innovation-and-ai/models-and- /-a-soqo.-tutwaputudaap -aoot/oeasa. 控制完整人形機器人:處理全身任務 现實世界是依照人频的活融方式建造的。要在狭窄、辨乱的空間程完成任務,往往需要伸手、驾腰、移 勤保持平衡。 Google DeepM1nd 此前的模型,主要控制人形器人的上半身,完成桌面上的任孩。Gen1n1 Robotics 2则把物理 AI的控制凰强展到完整的全身融作。 這是GoogleDeepMlind 的模型首次能控制整台人形横器人,把任病意图聘化為智慧的全身低码。 例如,模型控制 Apptron1k ApolLo 2人形楼器人時,使用者可以下还遗核的指令: 把沸水壹放谁最下屠唇架的绿色箱子程。 ApoLLo會理解运项指令,走向桌子、拿起滴水壶,再走强步来到唇架前,最精车地把它放進指定 位置。 官方同時指出,目前機器人的勤作速度仍有提升空間:但这项进展已涵意更被辩真實任務所需的全身 能力。 Apptronik Apo1lo 2: https://apptronik.com/apollo/apollo-2 【素材位置03|影片:智慧全身控制】

ntelligentWhot

機械手與爽爪有更高的精细操作能力 概器人老要在家庭买工作場所發痛作用,需要具储细照的控制能力。 GeminiRobotics2不同须型的末端韩行器都强得更高水等的精细操作能力。無输糖器人使用的 是多指概械手,還是常見的雙指夹爪,都能虚理比以往更被辨的動作。 这個模型现在可以控制Apollo 2上的 Sharpalave 機械手。这是一款具借五根手指、22细白由 度的碳械手,能完成绑结、封合夹键袋等组腻助作。 它也能控制Franka Duo平台上的梗撑熨指平行夹爪,轨行高繁度的精细任,例如把物件紧密装 入有限空间 GoogleDeepM1nd图原将持提升操作的精率度與退度,翻接近人類手部靈巧度的目推谁。 Franka Duo: https://franka.de/fr3-duo 【素材位置04|影片:进燃精细操作】

02:16

代理式推理與多機器人協作 真實世界中的任務,通常不會一步完成。它们往往需要在一段時間内持绍轨行多個步骤,途中還要根據 境境密化做出判断。 為了虚理這種握越度,具身推理模型GeminiRoboticsER2會充楼器人的高大:,负 责理解使用者指令业具人频满通。 它言飘察房間、推理完成任形需要哪些步限、調VLA模型款行具體動作,亚持遍蹈进度,直到任 税完成。 架精機器人能购: 这种架椭桃器人能钩:

• 韩行被辨的多步罪任務:

• 在某姻步骤失败時自行修正;

• 把已學言的能力泛化到新的情确與目裸,

這次亚新旗檐器人可以更可量地執行最序列任稳,整個流程能持数分等,涉及数百次决策。 GeminiRobotics ER2现在也能理解任務何始、何時结束,亚找出腊证事件壁生的時刻。 GoogleDeepMind将其描述為任税进度理解能力的一次陷段性提升。 除此之外,GoogleDeepMind围除也引l入了多槐器人協作, 不同型的檐器人可以被此满通、分工合作,完成單一概器人法疆自虚理的梅能工作流程。 【票材位置05|影片:多機器人协作】

• YouTube: https : //ww. youtube com/watch?v=CiTPDm7PKk8

• 影片槽始: Mult1-robot collaboration with Genin1 Robotics 2

• 建族图:不同形感的概器人共享任崭资訊、分工,一起完成台機器人整以虚理的袍辩流

程。

快速適應不同機器人:模型直接在装置端運行 许多擦器人愿用不能依轴福定细路,也無法接受要端往返需来的延理。 Gemin1 Robot1cs Dn-Dev1.ce 2 正是為道些限别而設計。它是 Google DeepMind 目前最高效 的VLA模型,經造粤門最佳化,可直接在機器人装置上本地通行。 这模型原生支振多種察器人形感,延Gem1n1Robot1cs1.5的泄动作泄移:技術。 如今,只需要爆個小時的遮愿時期,通常不到208国花例,模型就能造配新的雙臂機器人。 即使新機器人的外形、感测器配置與自由度差很大,这塞方法仍然有效。GoogleDeepMind晨示 了Dexmate、50181 Trossen 等不同平台執行多種任鸦的结果。 Gemin1 Robot1cs 1.5: https://deepm1nd.google/blog/genin1 - robot1cs -15- brings-ai -agents -into-the-physical -world/ 【素材位置06|影片/勤图:装置端模型逾康不同機器人】

持續推進安全、負任的機器人技術 安全始是Google DeepMind 模器人研究的基能。 随著慶器人撰得更强的物理能力,围隙也持碰保整塞系统感知,推理到動作執行,都具催端到确的 安全性员對肾能力。 每次推出新版本时,GoogleDeepMind都探用多層安全方法,把傅的物理安全措施與健的 AI 安全框架结合起来。 Gemin1Robot1cs2特别加强了南现置挑载:一是如何在充漏不础定性的真實境境中安全行;

二是如何在人颖身遗作。​

这次,Google DeepMind 除推出了新的安全基军 ASIHOV-Agentic,用束解估代理式安全 奥不确定性感理能力。 ASINOV-Agentic: https://huggingface.co/datasets/google/asinov_agentic/blob/main/README.nd 例如,这套基弹含检查具身推理代理能否拒绍VLA發出的不安全工具呼叫,也會衡量代理能否判断一 项任務是否可行,在缺乏把握時主助要求人频介入。 德辐更强的具身推理能力,Gemini Robotics ER2在安全約束遵循與人频近距互基上,成 为Google DeepMind目前最安全的機器人模型。 它能更碰地察覺附近是否有人,在需要時熊發安全工具呼叫:如果有人得太近,系统可以潇察器人 安全停止。请也是作型機器人安全标摩中的一项翻键要求。 更多技衔细可参圈《Gemin1Robotics2:安全技術张告》。 安全技衔张告:https://storage.googleap1s.com/deepn1nd-ned1a/gem1n1- robotics/Genini-Robotics-2-Safety.pdf 遇向通用型物理AI Gemn1Robot1cs2是通往「在物理世界中實现AGI:道路上的一继重要生程碑。 按照官方文意的表述,要释放機器人的澄力,技拆流要提單一任務自勤化走向通用智慧。 Google DeepMind 图陈的目標,是物理世界中的 AI 能英人類家作,虚理辨間强。 體驗奥延伸資源

• 在 Google AI Studio 锂癌 Genini Robotics ER 2

https ://ai. dev/pronpts/nea_chat?model=gemini robotics -er -2-preview

• 查看 Gemini Robotics ER 2 模型卡

https : //deepm1nd.google/models/moiel - cards/gemin1 -robot1cs-er-2/

• 查署 Gemini Robotics On-Device 2 模型卡

https ://deepmind googLe/models/model - cards/gemini -robotics-on-device-2/

• 睛 Google Developer Blog 的翘發脱期

https : //blog.gogle/innovation-and-ai/models-and-research/google- deepmind/gemini-robotics-er-2/

• 申加入 Trusted Tester Progran

https ://docs, google. con/forns/d/1sM5GgcVMwv-KmKY3T0MpVtQ-LDFeAftQ- d9xQn92jCE/viewforn?ts=67cef9866edit_requested=true

• 在 Genin1 Enterpr1se Agent PLatforn 式用

https://consote.ctoud.google.com/agent- plat form/publishers/googLe/model -garden/gemini - robotics-er -2-preview- info 原文:GoogleDeepMind 原文標题:GeminiRobotics2bringswholebodyintelligencetorobots 原文連:https://deepmind.google/blog/gemini-robotics-2-brings-whole-body- intelligence-to-robots/

原始排版图​

发布于 2026-07-29 21:38:22（微信公众号导出记录）。

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

原文链接：查看原文

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

正文（本地 OCR 转写）​

充 originelwθx7ce EI V1ajero2826年7月29日21:38 日本 版本摘要 MCP2826-07-28规已正式發依。这次更新带来期状题定核心、多输往返求(HuLti Round-Trip Requests,MRTR)、基於 HTTP 嫌硒的路由、可快取的清單结果、更服密的摄耀 制正式的撞充框架,以及已完成更新的第一级SDK Madl Cortst Prctecel Blg Hone/Posts The2026-07-28Specification The 20250728 Mode Contet Prcol specfition is out, brnging α stees prtocol cvre Mu RT Rq, hng ch s ret ortn hrening fl esfm, ndpd Tr 1SDK p 3, 20s -12nis-DsdSais Pare [led Minerel DenDeineky ad Minmims] Table of Contents Sinc ourlt NeeMCP cnid t gratnasthng te Acr ur TK hl-i and Python SDs cring the 1bllon tota doleds threshold Injust afemnhs prtldastdtdity atf workflows. Tos w speifcaton ln wth t Sksthtilaloyut studsEViajer and servers night awsy: 如果要用一句括概括次正新,那就是:MCP正一套需要维持疑向速線與工作段的定,型為 更接近现代Web基键設施的無状態請求/回愿熔定。 这不只是傅输唇的小修小捕,它直接影警MCP同服器如何他负霸平衡、同道踏由、經限控管、快取, 長時間任務。以及需要使用者中注随的互融流程。對正在生產環境中部署MCP的图隧而言,遭是一 回期確的架横分水强。 以下為官方文章的完盛疆中文翻與编排。技端别字、RPC方法、HTTP楼頭、SDK名稿及 SEP曾號均保留原文,以方使查腮规图遭移。

一眼看重這次改版​

核心畅型|微赞向、有状感定,改為请求/回愿式無状感核心 基硬设施|普通输詢负平衡、標頭路由與结果快取成为操季能力。 互助模型|MRTR综氟狀属工具仍可在转行途中向便用者取得致解 安全棚制|强化骏行者验具定,或DCR博向CIMD. 移節费破壤性曼更已有新版SDK支援:正式案用项目至少保留12個月過波期。 核心更新 白去年11月發布上一版规以来,MCP仍以聚人的速度成曼,在第一级 SDK中,我們每月鞭察到 接近5德次下载:TypeScript 與Python SDK的累計下最量更雙突破10德次。短短爆月 内,遭塞协定持成長,成为代理式工作流程承藏瓷料與互動能力的底基现。 今天,我钙正式按下新一版NCP规花20ZB-H7-28的發怖按钮:支援遭一版本的 SDK也同步淮 出,發者可以立即删始建置用户端规伺服器。 本次登饰最重要的更新,是引入無默都定核心:MCP正能雙向、有默想的掘定,聊型为探用求/ 回底模式的氟状定。道一直是發者最期待的功能之一,因爲它能MCP伺服器握得更好的可量 性购可充性,

图:官方“照状悉部定核心,示腕,左例為需要黏性工作附段的善授式:右例為可使用普通输罚负载孚 衡的熊就感模式, 暴看完整示箱 本地影片榴票:assets/stateless=core-deno.np4 官方影片: https ://blog-modelcontextprotocol io/posts/2026-07- 28/stateless-core-demo.mp4

:蓝版桥求需要体照工作强段回到指定赖行留龄:新版每细赫求都能自我播述,因此可由普通输病 平衡器分派至任意赖行细體。5erver/discover只用於希望预先取得能力资部的用户端,签非每 次呼叫前的必要步。 留然,道但版本带束的改警不只如此:

• 請求可以自我描述。希望预先取得伺服器能力资的用户确,可以還择呼叫探索方法:但这不是

必要步罪。因此,任何請求都能由首通输詢负敬平衡器後方的任意执行国證處理。

• 路由囊訊遍入HTTP镇RPC方法與工具名稿金分别适巡Mcp-Methud與Hcp

NancHTTP标疏傅送,旗网道可以直接根擦標随进行路由與授程。

• 互動流程改用MRTR。取檬(sanpl1ng)、資讯微(el1citat1on)等伺股器型用户镭

求,将改用多输往返幅求(Multi Round-Trip Requests,MRTR)重新短計,不禹需要展時 間维持需敏的雙向本流。

• 清單结果可以定快取。清馨回愿言据特快取提示,探用確定性脂序,使用户端可以快取工具

目錄,且在重新連综之後仍能维持上游提示饲快取的定性。

• 擅充框架正式立。Tasks 將與NCP Apps、企嫌托管授權(Enterprise Managed

Author1zat1on,EMA)等功能一同成为摘充项目。

• 授權制進一步收默。包括依照RFC9287壁證發行名,以及正式炭動感用户端册

(Dynam1.c Cl1ent Reg1strat1on,DCR)剩向用后端 ID 申瘤瓷科文件(CL1ent ID Metadata Documents, CIND) 。

• 用政策提供明確時間表。MCP正式建立乘用政重,提供至少12個月的遇渡期,旗则登者可

以预先规劃升级,而非被勤庭到婴更。 TypeScript、Python、Go 翼C SDK 整已同步亚新,亚針到破璃性攀亚提供鲜细還移明。 發者现在就可以開始使用新版规。 具體更 不再需要握手與工作段 在新版规舱中,MCP 正式移除 1nitialize/initialized交报流程,以及 Mcp-Session- Id標通,群翘内容可参SEP-2575 (https://github.con/nodelcontextprotocol/modelcontextprotocol/pul1/2575 ) 吴 SEP-2567 (https://github.con/nodelcontextprotocol/modelcontextprotocol/pull/2567) 现在,每個求都能疆立傅送,亚在_neta中带協定版本、用户端身分网用户瑞能力。如乘用户 端希望在執行其他提作前先了解伺服器能力,可以呼叫新的server/dlscover适端程序呼叫 (RPC):但道不是必要步骤。 PUST /ncp HTTP/1.1 NCP-Protoco1-Version: 2826-87-28 Mcp-Method: tools/cal1 Mcp-Mane: search {"jsonrpc*:2.8,"id":1,"nethod*:tools/cal1,。 "parans*:{nare:search,"arguments"={":otters) "_meta": {"io.rodel.contextprotocol/clientInfo:{*nane":my-app, version:1. 0}) 复制 移除掘定唇级的工作蔻段,不代表你的应用程式也必须完全無默怒。如集何服器宽要在多次呼叫之開保 存状感,可以由工具座生一国明确的控制代碼(handle),再操模型把它作為参数得回。 我們發现,这比把工作陷段状感隔量在得愉屑中更有效:模型能直接看到控制代碼,在不同工具之間 延绩使用。 實账影MCP何服器不再震要為協定工作段维持黏性路由或共享默:若務本身需要状 ,则改由工具明確交付控制代础。 多输往返铺求(HRTR) NRTR 取代通去由何服器主勤缝起、且必须保持率流胱效的clicitation/Create sanpling/createMessage 奥 roots/list 精求, 有時候,工具在執行途中需要使用考充资訊,例如磷某项操作,或提供逼漏的参数、SEP-2322 ( https://github.con/nodelcontextprotocol/modelcontextprotocol/pul1/2322) 所定囊的NRTR,深遗频情境可以在展状接定上通作: resulType:quol:inpul required",附上需要回答的镇求;用户端取得答 伺服器回傅 素後,再於inputResponse5中附上回,重新發送原始呼叫 實際影馨|工具仍能在敏感探作前詢同使用者、铺查参數或取得批准,但不必為此長時間保持雙 向速续。 画版伺服器主勤麟求與新版MRTR副比 MC 免提器 to6/call

地风工具质界 ools/call

天纯 N5 图:MRTR不是在背景保留一何履器可随時反向野叫的通道,而是把需要哪些输入:放进中闻结 果:用户端取得答案後,需著InputResponses重试原始师求, 基於HTTP標颐的路由 可事流 HTTP 幅求现在必须包含Hcp-MethodMcp-NaTe 標颈,鲜見 SEP-2243: https://github.com/modelcontextprotocol/nodelcontextprotocol/pull/2243 这代表道、速率限制器或Web既用程式防火装(WAF)可以直接根據標进行路由、計量與椿判 断,不必先解析JSON請求本文。 實聚影春|现有API道民安全投像更容易域别MCP流量,按方法或工具套用路由、配额 具存取政策。 清單结果可以快取 tools/list、pronpts/list、resourccs/list 奥 resourccs/read 的回离,现在童掘 需ttlMs 网 cacheScope,鲜见 SEP-2549: https://github.con/modelcontextprotocol/nodelcontextprotocol/pull/2549 用户端因此可以判断最逾合各類回丽的快取策略,减少不必要的重被播取。 實豫影春|工具與資源目款不必在每次重新还解時完整重括,也能降低上游提示间快取因顺序题 勤而失效的機率。 道路由與清單快取到比 公欢号Ero 图:標頭路由與清單快取是雨项癌立婴化,前者旗幕碳股旅篇须解析JSON本文即可腊别方法润工 具:後省透透ttUHs、CacheScope和確定性额序减少重被操取,整提高上游提示韧快取的疆定 性 授機制 根擦退去一年與實作者的时编。授往往是整合MCP 時最耗時的部分。这次规范修訂耀缩强化 MCP 的输论、授耀與整證安全触势:

• 授權何服继依照 RFC 9297(https://ww.rfc-ed1tor-org/rfc/rfc9287)回

傅155梦数:用户端必须先验盤它,才能允换授權砖,辞见SEP-2468: https://github .con/nodelcontextprotocol/modelcontextprotocol/pul1/2468. 这项更可以封堵授權伺服器混溶攻單,

• 用户端在速行数感用户端性册(DCR)時。需要投定appL1cat1on_type,避免授權何服器拒绍

桌面與命令列愿用程式使用LocaLhost重新尊向,详見SEP-837: https ://g1thub con/nodelcontextprotocol/modelcontextprotocol/pul1/837, 如渠你首经疑惑,為何CLI 用户端的OAuth流程童出现redircct_uri端,原因很可能 就在這裤。姓然MCP正博向以CIND為標华,但这项强化仍能旗定符合OAuth规要求 ,用户端细必须期定至發出选幅的警行者,不得跨授伺服器重拖使用,详見SEP-2352: https://github.con/nodelcontextprotocol/modelcontextprotocol/pull/2352

• 数舰用户端注册现已正式囊用,兼由CIMD取代,為了维持向後相容,DCR目前仍可作,但将

在未来的MCP规范版本中移除。 實账影|新版授概模型更接近成然OAuth部署的安全要求:既有DCR整合姓不育立即失 效。但愿始规劃CIND通移。 助娠胜册與建權路封比 满征:DCK(C奥月·药 M R户售

奖)E HTTPS URL MCP.是P8 E iue :2026-07-28签非立即副除DCR:它仍為不支援CIMD的授權何服器保留向後相客。但新實作 應優先探用CIMD,整在党换授橙碼前壁證IS5,持久化涉證時也必须按發行者隔藏。 Tasks Tasks不再於實验性核心。而是移至1o.modeLcontextprotocol/tasks摘充。新版提供以输詢 为基键的Lasks/geL.以及新的tasks/update.洋見 SEP-2663: https://github.com/modelcontextprotocol/nodelcontextprotocol/pull/2663 更通知期提盖有HTTP GET 端贴,移至單一subscriptions/listen串流;用户端可以依照通 知颊型湿挂是否打度。 實影馨|長時間任務仍可适通輸詢追践,也能运择訂阅通知:核心熔定别不必為此恢接成全面 有状感。 襄用项目 Roots、Sampling 翼 Logging 现已雍用,見 SEP-2577: https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2577 这些能力目前仍可通作,且至少會再继持12月:但新的實作不愿耀探用。版HTTP+SSE傅 输也已正式列為乘用项目,同样提供一年的遵移期。 移提醒|「仍可使用不等於「適合新哥案]。新的實作题直接保用替代模型:既有系统别可 利用至少12個月的窗口分腾段道移。 SDK與生價 至本文稳佛聘,四個第一级SDK都已支援2026-07-28:

• TypeScript SDK: https://github.com/modelcontextprotocol/typescript-sdk

xps-uoud/10ooudxauoapo/uo*gn//: du xs uou/d •

• Go SDK: https://github com/modelcontextprotocol/go-sdk

• Cα S0K: https ://github com/modelcontextprotocol/csharp -sdk

在第一级 SDK 之外, Rust SDK (https://github.com/modelcontextprotocol/rust - sdk)也已提供對新版规施的 Beta支援。 道些SDK提供相愿API,镶開發者可以依照新版规花建置何服瞻與用户。正如官方在SDK Beta 文 (https://blog.modelcontextprotocol .1o/posts/sdk-betas-2626-07-28/) 中所 航,還移確實會带束一些成本,尤其是到依颈工作段剧碼的储者而言;不遇,早期测就者的回续 已被纳入投計,使逼移通程容易許多。 来自生朗系统的显音 和任何大型赞饰一楼,MCP的工作不可能在缺少整個生照系统贯献的情况下完成。我們尤其颁朗在规 笔正式全面推出前,協助测就與验證的思多贡载者及合作伙伴。 以下為官方文章收疑的全部伙件引言。 生振眼察 遗些引言来自震端平台、開發工具、般针软、可测性、资料显MCP框架圈改。它师共同 指向同一件票:状展、可快取、可路由與企鉴授稀,已成為HCP走向大规模生牵部署的必要 修件。 Anthropic 这是通端NCP 在一年多前推出以来,最重要的一次更新。它额可摘充HCP伺眼器的服務能力 向前罐进,亚吸收遇去18個月累精的所有短验,為MCP的末来建立播健基强。新加入的摘充 项目,也展现了更展泛源厚案持缩划新的能力。我很期待看到大家通用這些新能力打造出什 座。

• David Soria Parra|技術属媒成典、MCP 共同發明人

Arcade.dev 这次發饰是迄今最明確的部然:MCP正在成为真正可投入生產環境的基碟设施。最大的改量恰恰 是破增性更,而社群遥握正面完成姓的工作,而不是掩蒸缺口。遗我們在合作企業中看到 的情况一致:MCP已成為道些围除预投探用的基碟,而道次辈布正是他仍一直等待的成熟版本 这套定正需编生产圈除的實整需求即時成長:對任何正在建置企代理的人来额,都是重要的

一步。​

• Alex Salazar|机行長暨共同前股人

AlNS AMS Anthrop1c致力股支持MCP 社带,超助附缝者大期模交付企繁频代理。新版MCP 规舱及其期状定核心已可在Amazon BedrockAgentCore 中使用,腐者能在標率、 可摘充的基键疫施上部署HCP伺服器,不必管理工作增段或持久速線。Tasks是最早的一批官 方MCP摘充之一。由ANS員感,能為可靠、長時間谨行的代理提供支援,开發者少花時間 虚理基避設施,把更多時開投入创新。

• Swami Sivasubramanian|代理式 AI 副共粒

Cloudflare MCP 2826-87-28糖代理基硼般施更接近Web其他部分的通作方式:状、可快取、可路 由。或能在全球额充。Cloudflare Agents SDK 黎布首日就支援这一规,需者可以直 接在Workers 中通行NCP 伺服器,在有傅输工作随段额外成本的情况下呼叫工具。支提 更豐富的流程,例如為霉批發起瓷部薇詢。由於MCP 是阴放撑,Sentry、Linear 等 CLoudflare客户也能在首日探用,立即把這些改遭交付给便用者。

• BrendanIrvine-Broque|產品管理瓷深热

Figna 越来越多建贵者使用我們的 MCP 何服器,把生成结果需入Figma 董布,奥票除一起探索、延 神横想业加以完善,最终做出真正突出的座品。随若使用量成長,我們的期状感架也能随之摘 充:加上MCP AppS、Tasks 與企集部管授權,我传可以进一步镶設計與程式碼维持在同一條 相互还结的工作流程中。

• Josh CLenn|工程副德裁

Google Cloud Model Context Protocol 2026-07-28 是企 AI 可额充性的—次巨大罐进。透遇须造 为無状態架桥,这份规消除了大规模部署代理式工作流程時的阻力。GoogleCloud很期待 在我們的開發客工具生感系统中通用道些强大新能力。这次發饰提供了得健、安全且可摘充的基 础,客户以及我們自己的圈账能建置下一代AI鹰用程式:我们也很自豪能耀共同塑造请项 放率的末来。

• Anna Berenberg|集出工程解

Honeycomb 在honeycomb.io,我們看到 MCP得了非常亮银的探用:每月接近 28%的互助式查詢, 现在都是由代理發起。新版规莉我钙能在企嫌规模下谨行,同時支摆资訊微詢等更连随的功 能。

• Austin Parker |AI 策略辣

Manufact 新版MCP 规触明,继摇者確實有取社群巨锁。它解决了我何在拥蕊框架ncp-use 周航管 数千個HCP 伺服器的 Manufact Cloud中遇到的真實開题支撑 mcp-use 的新版 SDK V2,恶由新的用户确/同服器拆分,榜助我們把套件大小缩减的83%,同時提升25%的速度。 随著MCP朝為無状感,我仍也能在不依轴不切實除的基提设链權宜方案下,更可像、安全且可 提充地虚理生產流量。

• Enrico Toniato|技術長

Microsoft Foundry 放定所創造的生無系统,规模奢超通任何一家企藻能单摇建造的额周。MCP是Microsoft Foundry的基碳,我們可以微款十项整合抽充至款干项。我們透過Foundry tooLbox 的 统一MCP增贴集工具,同時集中治理、身分與可翻测性。适退無状糖操作、支援長時間工作 的Tasks,以及企繁管理的身分碳制,下一代MCP 镇安全、可填充、可投入生的代理系統比 以往更容易建置。

• Tina Schuchnan | Microsoft Foundry 工程企繁盈患

Netlity 2026-87-28规中的無默影核心,爆MCP 成為一等的 HTTP 工作典露,不再需要编過工作 随段管理間题。我钙的客户希望,在NetLify 上逗行MCP 可以和平台上的其他工作一样商 單,而新规能核心唇面實现了遗一點,把HCP ApPS 纳人新的摘充框架,也为整困生感系 的可播充性、可存取性网能力需来巨大进展。

• Sean Roberts|源用 AI 副继截

OpenAI MCP现在大的一虚半了。感期开發者及其他實作者提供回馈,它正演进為更成熟的協定,吸收 數十年Web定设計的經验,和之前的版本一样,最有理的部分,仍然是看看人仍含用它建造 出哪些出乎意料的重西

• Nick Cooper|技術圈隧成員、MCP 核心维援者

PostHog 把MCP 改為無默娠据定,旗我们更客易播充自己的服,也更客易為客乒的MCP 伺服器加入 分析功能。我們可以更稀地向使用者展示HCP工具的實照使用方式,以及使用者希望使用、 但目前仍然缺少的工具。很高舆看到这套擦定胡这個方向成長。

• PaulD'Ambra|產品工程師

Prefect/FastMCP 對任何正在大规模建置MCP的人來,這都是一個里程碑版本。FastMCP一直致力於把规 中最強大的能力,轉化為直覺易用的開發體驗;我們很高興能在FastMCP4.0中,為背景任 務、無狀態互動、企業授權等能力提供第一级支援。我們的MCP治理平台Horizon一開始 就探用無狀態設計,以支援極大规模;如今這種做法成為協定原生能力,令人振蓄。

• JeremiahLowin|執行長

Runlayer 這次發怖MCP比以往任何時候都更遍合企業使用。Runlayer正把這些進展帶給平台上的每

一家企業,提供更简單、更安全的基,協助它們在組識内部署MCP與代理。​

• TalPeretz|共同創瓣人暨產品長

Stacklok 最新一版MCP规是一個重要里程碑。它所展現的謹程度與使用者参與,證明這套協定正在 成熟,企業可以更有信心地以它為基建置。我們已經完成新版實作;轉向無狀態模型,不只移 除了警通複雜度,也镶MCP得以摘充至企業规模。這是一個强烈訊號,顯示整個社群正在由真 實部署經验所塑造。

• CraigMcLuckie|執行長

Supabase 支援資訊微詢一直在我們的發展圖上;但由於SupabaseMCP以無狀態方式通行,過去很難 輕做到。MRTR改變了這一點:工具可以在探取行動前先向使用者確,例如在建立新專案前 確費用,或在執行可能刪除資料的查詢前取得同意。我們很期待支援這頂能力。

• InianParameshwaran|產品负貢人

Xero Anthropic把前沿模型與持提高標的開發者體驗结合在一起。開放的MCP2026-07-28 规所提供的無狀核心,降低了我們需要管理的雜度,镶我們能以更快速度、更大规模,向 客户交付更多功能。

• AndrewGoodman|AI副總裁

使用資源與延伸閣 我們很期待看到發者以新版规建置產品。可以以下資源開始:

• MCP2026-07-28完整规:

https://modelcontextprotocol.io/specification/2026-07-28

• 2026-07-28完整更記錄:

https://modelcontextprotocol.io/specification/2026-07-28/changelog 28/getting-started/intro 延伸朗:理解這次更新的前因後果 若要進一步理解這次架橘轉型,以下均爲MCP官方或原始提案資料:

1.MCP2025年11月规奥一调年回​

https://blog.modelcontextprotocol.io/posts/2025-11-25-first-mcp- anniversary/ 上一版规把Tasks、授權摘充與多填企業能力带入MCP;對照本次改版,可以清楚看見 Tasks如何由實驗性核心移至正式摘充,以及授權機制如何继續收敛。

2.2026-07-28SDKBeta奥遭移明​

https://blog.modelcontextprotocol.io/posts/sdk-betas-2026-07-28/ 適合需要估伺服器相容性、工作隋段移除影響,以及各語言SDK遵移成本的開發者。

3.SEP-2575:镶MCP成為無狀態協定​

https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2575 這是本次架髮化的核心提案。

4.SEP-2322:多輪往返請求(MRTR)​

https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2322 群细明無狀態條件下,工具如何在執行途中向使用者索取確韶或補充資訊。

5.SEP-2468:授權回應中的發行者驗證​

https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2468 對應RFC9207與授權伺服器混淆攻擎的防。

6.SEP-2663:Tasks摘充​

https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2663 明TaskS實驗性核心移出後的新介面舆訂朗模型。

7.SEP-2577:用Roots、Sampling奥Logging​

https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2577 新實作與既有系统规劃未来12個月遵移时,應優先阅。

原始排版图​

发布于 2026-07-27 22:58:53（微信公众号导出记录）。

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

原文链接：查看原文

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

正文（本地 OCR 转写）​

QEMU、KVM、Docker奥Proxmox:一篇梳理虚凝化技術奥 Proxmox生蔗 original we×x7ce EI V1ajero 2826年7月27日 22:58 德国 提到虚提化。經常售同時看到 QEMU、KVM, Docker、 LXC.Firecracker,Kata Containers、 VMvare、Proxmox、Kubernetes 等名强.

虚搬化技術奥Proxmox生態 QEMU · KVM - Docker · LXC 品 ?

这些软體不虚於同一層,也不能直接放在一起比较。 KVM提供LinuX核心中的硬體虚化能力:QEMU负贡虚提概器模型、装置模凝和行控制; Docker 管理共享主機核心的愿用容器:Proxmox VE 别向上盈合虚摄模器、系統容器、露集、留 存、终路、儒份胞管理介面。 理解盛困生爆的熊键,不是记住更多品名程,而是先分清三件事:

1.隔整遗界位龄娜一;​

2.工作负露實账由什度元件轨行;​

3.哪些数證只是管理,限些教键真正参與CPU、記博體和装置虚凝化。​

一、QEMU、KVM、Docker與Proxmox的核心關係​

一套完整的虚澄化或容器平台,通常可以拆成以下差:​

【图一:虑授化技術分】 原用风工作免航

IIvr Cloxl

SA · I

同一個產品可能覆蓄多,但每一膳的联责仍然不同。 KVN KVM 是 L1nux 核心中的虚赋化子系統。它使用Intel VT-x、AMD-V、Arm V1rtual1zat1on Extensions 等硬疆能力,旗GuestCPU据令大架分時開直接在實耀虚理器上執行。 KVN 本身不是完整的虚凝操器管理毫品。它提供的是核心API,仍然需费QEMU、CLoud Hypervisor、Firecracker 等使用者空醒 VNM 建立纪晚、虚 CPU、装置和生命遇期控制 QENU同時具有南殖主要角色

第一種是全系统模裂器。QEHU可以模摄CPU、主楼板、糖和装置,至敦行主楼不同指令集的​

作案系统.例如在x86主機上楠疑Arm或RISC-V系统、适拜模式通常使用TCG動朗翻罐,通 用性高,但效能低於硬體助虚提化。

第二种是KVN 的使用者空间 VMM带主概购 Guest 使用相同 CPU 架椭时,QEMU 可以把 CPU​

轨行交给KVN,自身主囊盛理器模型、Virti0、磁碟、细路、题示和管理介面。遭也是Linux 壹端则Proxnox VE中晨常見的组合。 Docker Docker Engine 或其上游 Moby 是容器管理引擎。Linux 客器不提供舅立核心,而是共享主操 Linux 核心,两透i遇 namespaces、cgroups、capabilities、secconp、SELinux 或 AppArmor 建立隔雄网资逐控制。 Docker 還虚理缺价、钢路、磁臻區、API 和客器生命遇期。底唇通常由containerd 管理,禹由 runc 或crun 建立實账容器。 因此,Docker 不是量版QEMU,也不是得统愈差上的硬體虚疑機器 Proxmox VE Proxmox VE 是以 Debian基的虑疑化基强投脂平台。 其中:

• 虚凝機器由 KVM和QEMU 软行;

• 系统容爵由LXC行:

• 董集通讯由 Corosync支握;

• 盖集設定由pmxcfs 同步:

• 留存可以使用 ZFS、Ceph、LVM-thin、NFS、1SCSI 等;

• 管理面由 Web UI、REST API 和一组命令列工具组成。

Proxmox VE 没有重新發明 Hypervisor 核心。主要情值在於把成熟的Linux虚化元件整合成

一套可安装、可集化、可储份、可白勤化的早台。​

主要虚凝化方式阅睛源技 虚凝化不只分為“虚搅碳器,周“客器。按期隔方式和相容震次,可以分成以下袭類。

1.全系统模频​

代表技衔包括 QEMU TCG、Bochs、gen5、Renode 和 Sinics. 這熟方案模凝完整CPU與硬遭平台,可以跨措令集积行作繁系統,通合韧州發、嵌人式测试、售系 统保存、蕊益程式分析和CPU架精研究。 主要限制是效能。当每條Guest指令都震要翻经或解程时,不通合一般生至案移负致。

2.硬體助的完整虚凝化​

代表方案包括:

• L1nux KVM + QEMU;

• Xen;

• VMware ESX1;

• Microsoft Hyper-V;

• FreeBSD bhyve:

• mac0S Virtualization.framework;

• VirtualBox,

每墨虚凝器描有漏立核心,虚授记遍和建發装置,能转行不同作满系统,隔離退界清晰,Guest 相容性高,是通用伺服器虚提化的主流方案。 代债是每量VM都需要白己的核心和部分系统服粉,敬勤時間奥记德體需銷通常高於一般容器。

3.半虚摄化​

半虚摄化不一定代表整個Guest都經通修改,现代系统更常见的形式,是CPU使用硬體虚疑化, I/0 使用 Virtio、Xen PV 或 Hyper-V VMBus 等半虚摄化介面。 Virtio 已成高 KVM/QEMU, Firecracker, Cloud Hypervisor、 crosvn 和 Kata Containers 的重要基理。 它遵免完整模摄傅统硬键装置,可以减少 I/0阴销,但Guest 需要對愿辐动。

4. MicroVH​

MicroVM 仍然是硬體虚提機器,只是截剪了傅统PC 的大量装置和相容功能。 代表要案包括:

• Firecracker ( https://github.con/firecracker-microvm/firecracker )

• Cloud Hypervisor (https://github.com/cloud-hypervisor/cloud-hypervisor )

• crosvm ( https://chromium. googlesource. com/crosvm/crosvm/ )

• Kata Containers 中的 Dragonball

M1croVN 的目標是额小VMM 攻壁面、提高密展降低敏动成本,常用龄 ServerLess、多租户容 器和不可信程式驱執行。 它不酒合需要大量傅接装置权缀、完整桌面国形或善版作案系统的瑞境。

5.离用容器​

Docker、containerd、CRI-O、Podman、runc 和 crun 属於遗一生感。 客器共享主機核心,建立速度快、密度亮,映像與CI/CD生感成烈。它通合可信内部服務、微服 强登别抗和 Kubernetes 工作负致 客器的安全遍界依观主碳核心。-privilcgod、主機Docker Socket、根目综置、急险 capabilities和装量直通都可能削器隔醒。

6.系统容器​

LXC、LXD、Incus、Systemd-nspawn 和 OpenVZ 亚接近 “鞋量 Linux 系。 系接容器可以软行完整init、多圈服膀和报近傅统主機的便用禮壁,但仍共享主楼核心。 ProxmoxVE使用LXC提供系統客器。它道合DN5、整控、代理、内部股移和低国险基磁酸施,不 逾合作為强隔随的不可信多租户遍界。

7.使用者空間核心网系统呼叫涉霜​

gVisor以使用者空周应用核心操藏大量Linux系糖呼叫,降低工作负显直接接解主權核心的程 度。 它可以透遇runsc 整合 Docker、containerd 和 Kubernetes,在一般容器與完整 VM 之間 提供另一程安全取拾。 限制主要束白系统呼叫、榕案系统、期路與除相容性。部分工作典最含出斑明效能差翼。

8.VH隔雌容器​

KataContainers 把 OCI睿器放入理量虚授機器中行。 上需仍保留Kubernetes、CRI和容器映像险,底唇则使用蜀立Guest核心它逾合多租户 Kubernetes、CI 机行器、第三方外挂翼 AI Agent 沙箱。 代债是架梳更夜瓣,期路、存、整控和故障抄警需要同時理解容器奥VH

9. Unikernel 奥 Library 0S​

Unikraft、Nanos、Mirage0S 和 IncLude0S 等專案,誉就把感用实最小作藏系统能力编罐成單

一肤像。​

这方案可以降低敏勤時間和系统體。也能缩小部分攻聚面,但POSIX相容性、驱勤、除、人 才和工具生攀不如LinuxVH或容器成熟

10. WebAssenbly​

Wasmtime、Wasmer、WasmEdge、WANR 和 Wasm Workers Server 等执行時,把愿用限制在能 力填向的沙箱中。 Wasm造合函式、外排、遗缘谨算和可重新编挥的小型服移。敏动速度舆可移植性通常较好,但不能直 提联代所有Linux客器。 现有癌用如果依到完整POSIX、任意系辨呼叫、核心极组或特殊装置,移植成本可能很高。

11.API相容奥二进位翻麟​

W1ne、Protan、Darling、WSL1 等资供作繁系睛 API 相容: QEMU User、FEX Box54 和 Rosetta2等解决CPU指令集差黑 造知接術的目福不是注立完整虚凝效疆,而是续特定融用在不同作案系统或CPU禁模上积行。

12.密虚凝模器奥碳密容器​

AND SEV-SNP、 Intel TDX, Arn CCA, IBN Secure Execut1on, 以及 Conf1dential Containers等專至,试国在雾端管理員或主機软整不完全可信時保摇工作负显紀恒體。 楼密通算需要同时虚理速端船明、映像测量、金输理放、别赠、I/0和供庭经。 记懂赠加密不等於完整安全。Do5、倒通道、结膜股定奥癌用漏润仍然存在。

13.孵想分割與安全關键虚摄化​

ACRN、Ja1thouse、Ba0、seL4和Muen 主要面向嵌入式、覃藏、工繁控剧、即时系統和湛合 偿等级。 這额方案重视確定性、耐感資添分配和可脑照性,通常不追求公有营式的動娠超震况大规模通用管理。 主流阳源專案的定位 虚换化生馨中最容易出现的周题,是把管理工具、敦行时和核心能力視为同频產品。 Hypervisor、VMH 奥虚摄機器管理

• KVM:Linux 核心硬體虚摄化 API.

• QEMU:全系统模摄器奥通用VHH

• Xen:獨立 Hypervisor,具有 PV、PVH 和 HVH 生態。

• bhyve: FreeBSD Hypervisor.

• Firecracker:面向震端工作负霸的辅赠KVM VM

• CLoud Hypervisor:Rust 编离的现代善端 VHH

• Crosvm: Chrome0S 奥 Android 生服中的 Rust VNN

• Libvirt:毓一管理 QEMU、KVM、Xen、LXC、bhyve 等後端,本身不是 Hypervisor。

• Proxmox VE:整合KVM/QEMU、LXC、壹集、存、霸路和管理介面。

• OpenStack:大规模IaaS 控制面,底唇通常仍使用KVM/QEMU、Ceph 和 Open

v5witch, 容群购OCI生感

• Moby/Docker Engine:容器API、映像、翻路與生命遇期管理。

• containerd:客器生命调期與映像管理.

• CRI-O:面向Kubernetes CRI 的容器行時。

• runc:OCI参考低唇熟行時。

• crun:C語言實现的OCI執行時,支援cgroups v2與Wasn整合。

• Podman: Daemonless 容鹏引章

• LXC:Linux 系统客器轨行畴。

• Incus:管理系容器與虚概器。

爱璃雕容器典沙箱

• Kata Containers:客器介面加量VM,

• gVisor:使用者空間鹰用核心。

• Firecracker: MicroVM 敦行。

• KubeVirt:在Kubernetes 中管理虚摄機据。

.ConfidentialContainers:楼密 VM、通端粗明和客器工作流程整合。 编排工具不是虚凝化核心 Kubernetes、Nomad、OpenStack,Proxmox VE、vCenter 和 Libvirt 郡主要位岭管理或编 排照。 這些平台决定工作负鼓放在趣程、便用多少資意、如何逗综和如何恢痘,但底層仍然需要KVM、 QENU、runc、LXC、Ceph.Linux Bridge 等元件完成實账执行。

二、Proxmox的產品定位與底層架横​

ProxmOX是一组开源基碳施座品,而不只是單一虚提化收體 【图二:Proxmox 品购技術张】

Proxnox Virtual Environment Proxmox VE,通需离稿 PVE,是核心虚凝化平台。 主要能力包括:

• KVM/QEMU虚摄碳器:

• LXC系统容器;

• 多的慰据售;

• 高可用管理;

• ZFS, Ceph, LVM-thin, NFS. iSCSI 等存;

• Linux Bridge, VLAN, Bond. Open vSwitch 和 SDN;

• 防火糖、RBAC, API Token, LDAP, AD、OIDC 和 MFA;

• Web UI、REST API、 CLI 和行端管理。

PVE 探用AGPLv3,有打图也不會镇定蒸案、HA 或通移功能。付资订用主要提供 Enterprise Repository、技術支握和版移等级。 Proxmox Backup Server Proxmox Backup 5erver,開 PBS,是蜀立的催份平台。 它提供:

• 增量偏份;

• 跨情份去重;

• 用户端加密:

• 确份验铅;

• 适端同步:

• Prune Garbage Collection;

• 磁带储份:

• 榴案级恢摄:

• PVE VM 奥 LXC深度整合;

• 一般Linux主概的榴案兴医端装置備份:

• PBS4.2中的S3 相容物件個存後端。

PBS不糖只是安装在同一PVE主模上的另一他VK,然後把瓷科放回同一继碰强。份付胀器、 偷份介算和生毫盖集需要故险域隔。 Proxmox Datacenter Manager Proxmox Datacenter Manager,简稻 PDM,用於管理多個握立 PVE 蓄里 PBS. 它提供跨站贴检视、操作和省漆管理,但目前仍虚龄快逼摘充段,不能直接视为vCenter或 OpenStack的完全等價替代品。 Proxmox Hail Gateway Proxmox Hai1 GatewBy,随辑 PMG,是蜀立的部件安全道器,提供 SMTP 代理、垃级郵件通 滤、ClamAV、SpamAssassin,隔随氢和都件遗醛。 PNG履於 ProXmoX 官方商品線,但不依输 PVE,也不是虚化核心元件。 Proxmox offline Mirror OffLine Mirror 用龄把 PVE、PBS、PMG 和 Debian 敢照套件座带人隔路。 它通合工掌纲路、内部安全區、無外資料中心和其他受控更新境境。螺訂图金输需要單强膜算。 PVE的底技衔榜 PVE的核心亚不是一個封谢照盒。大部分能力都能对感到具疆的上游技術。 针算

• Debian GNU/Linux:使用者空間购教霍塞件基碟

• Proxmox Linux Kernel: 包含 KVM、ZFS、 Ceph. VFIO 等所需支据。

• KVM:CPU與記像體硬體虚摄化。

• QEMU:VM装置模型则行程。

• LXC:Linux 系统容器。

• cgroups V2:CPu、記爆锥和 I/D 資源控制

Guest装置與工具

• OVMF/UEFI:现代 VK 新耀

• Se8BI0S:傅统 BIOS.

• Virtio Block,SCSI,Net,Balloon:高效能半虚提化置。

• QEMU Guest Agent:取得 Guest IP、撤機棺案系統深结

• cloud-init: Linux VM首次数投定。

• Cloudbase-Init:Windaws 自勐化初始化.

• virtio-win: Windows Virtio 显勤度 Guest Agent,

• SPICE、noVNC、xterm.js:图形翼终谱主控台。

集贝高可用

• Corosync:盖集成員奥quorun 通讯

• pmxcfs: 同步/etc/pve 锐定。

• pve-ha-crm: 器集级 HA 决策

• QDevice:偶数暂贴或特定托下的额外投票。

• Watchdogfencing:避免故障前黏继绩存取共享資源。

HA 不是rVM 白動重战:这磨前單。它依可量的酸集期路、quorun、fencing、共享或可物 存。以及经退测试的故障虚理流程。 两前點集尤其需要理解quorun,加人QDevice可以改善投票條件。但不能修復不锡定的網路或 錯联的故源城设計。 PVE的管理工具 PVE Web UI 覆整大部分日常工作,但CLI 和 API對白融化、故障等警與批次操作更重要。 常用命令包括:

• qn:管理QENU/KVH虚数概:

• pct:管理LXC 客器:

• pvesh:截本糖呼叫 PVE REST API;

• pwesn:管理健存:

• pvecn:管理靠货、贴和quorun:

• ha-nanager: 管湿 HA 冀源:

• pWCSr:首理估存指表;

• Vzdunp:正立VW具CT 清龄:

• qnrestore:恢德得施 VH 菊份:

• pwean:管理 LXC App Liance 模板:

• PeLn:管理快月售、角色、ACL 和Token:

• pweceph: 品著臀管理 Ceph:

• pwenode: 管理师黏任鸦冀逐恒;

• pwereport:收集工機,富焦,存套润路除疆直品。

PVE 逾提供完签 REST API.Web UI 中的多数藻作都能對糖到 API 路径,API V1ewer 可J以直 接查旗多数和回傅结横。

三、Proxmox的部署、運舆周生態​

髓存、鼠路、借份舆湿移 Proxmox VE 的髓存湿握非常腐,但不同後端的能力差具明。 本機留存 directory 最魔單的榴案留存,可放置qCOwZ、ISO、模板和傅純需份。通合小型部著,但共享则高可用能力取 决於底檔案系统。 LVM-thin 提供精置懂、快照和握限,通合本機医境髓存。管理單,但不是共享髓存。 ZFS 提供校验、墨瘤、快照、装、RAIDZ和M1rror.它通合单丽贴與本模存握装,也常見於家庭實 验室和中小型部著。 ZFS 需要合理的记像體、磁直通和酸障設計。硬體RAID上再建立ZFS,通常害削弱ZFS對實 除磁孩状能的判断。 隐碰状感的判断。 共享储存 NFS 部署触單,逾合ISO、模板、借份和一般VK存。效能实可罪性取决於 NAS、锡路和同步离入策 略。 iSCSI 提供区块存,常具SAN、LVM或廊商外排结合。需要正链感理nultipath.额定和快照能力。 Ceph Ceph 是 PVE原生整合最深入的分做式储存方案之一。可以提供 RBD 医烤存购 CephFS. 它逾合需要的點故障容忍、横向抽充具HCI的器集,但需要足狗数量的點、磁键和低延還钢路。三 瓷源紧强的小主概加單一千光细路,通常不能代表合理的Ceph生座架。

第三方警存​

PVE 生患中遗包括:

• LINSTOR + DRBD:

• StorPool;

• Blockbridge;

• StarWind;

• TrueNAS、 Synology、 QNAP 等 NFS/iSCSI 装置;

• 各频 SAN NVMe/TCP 整合。

探用第三方外排前,需要確 PVE 主版本相容性、快照、線上移、HAfencing、借份支援和 商页任遗界。 朝路、SDN奥防火 PVE 基磷网路通常由 Linux Bridge, VLAN-aware Bridge 和 Linux Bonding 组成, Open vSwitch 逾合需要OVS、OpenFLow或拖藏虚摄交指的晚,但會增加维通拖蕴度。 PVE SDN 支援:

• Simple Zone;

• VLAN;

• QinQ;

• VXLAN;

• EVPN;

• FRR/BGP:

• 内建IPAM;

• phpIPAM NetBox IPAM 外排;

• PowerDNS;

• DHCP/DNSMasq;

• WireGuard Fabric,

PVE 防火猫可以在资料中心、的融和VM/CT多眉套用规剧 OPNsense、pfSense、Vy0S 和 OpenWrt 也常以 VH 形式部署,作為路由器、防火或 VPN 同道器。 如果虚凝防火独使用PCI期路卡直通,需要预先設計主機失联、VM故動顺序和故障恢復路径。管理 期路完全依單一防火糟VHM,會形成明的循環依。 催份舆炎整恢復 PVE 内建vzdunp 可以把 VN 和 CT 储份到 Directory、NFS 或 CIFS 等横案健存。 它逾合基碰完整储份。但不具做PBS的跨确份去里、验馆、還端同步和短粒度资料管理能力。 校完整的Proxnox情份架横通常包括: PVE生密集 强立 PBS —定期 verify Prune 翼 Garbage Collection 透巢 PBS 同步 整综或不可觉副本 一 磁带或S3 相容物件储存 复制 商集借份生零湿包括 Veeam,NAKIVo、Vinchin、Storware 和 Bacula。 不同產品對VM、LXC、愿用一致性、PVE 最集设定、ACL、SDN和 HA设定的支缓花固不同,不能 只璀超支援Proxmox:使視为完盛保强 偏份癌遵循 3-2-1-1-8 原期:

• 3份资料;

2种不同介算; 1份震地:

• 1份整级、不可或隔;

• 0個未經验湿的恢復锚识。

典正的验输不是殖储份任题示成功。而是定期演触整量VM、一棉案、资料康、PVE曾贴重 装、PBS重建和站黏级恢復。 通移到Proxnox 常见来源包括 VMware ESXiHyper-V、其他KVM/Libvirt 平台、VirtualBox、實體 Linux 主糖和普源Appliance, 可用工具具路径包括:

• PVE Import Wizard;

• qn inportdisk:

,OVF/0VA 医入;

• qeu-ing convert;

• Clonezilla;

• virt-v2v;

• Vec8m等商案遭移或恢復工具;

• 医用屠重新部署。

逼移不能只感理磁础格式,遗需要检查:

• BIOS 或 UEFI;

• MBR 或 GPT;

• Virtio 显始;

• Windows 敏勤模式;

• 闵路介面名稻;

• IP、DNS 和防火糖;

• Guest Agent;

• 橙稀额定:

• 整控具備份:

• 回覆至原平台的方案。

健系统需要先建立测试批次,不能直接把第一次聘换富作正式切换。 自勤化興 Kubernetes PVE 官方提供 REST API、API Token、 pvesh 、cloud-init 和各類 CLI,

第三方自助化生主要包括:​

Terraforn 奥 openTofu ( https :/github .con/bpg/terrafonm-provider-proxnox ) 。 它可以管理 VM、LXC.前贴、霍限、储存和部分 SDN 資源。生產使用愿镇定 Provider 版本,测 试PVE主版本升级,亚致能State中不包含不必费的敏感瓷料。 Ansible conmunity.proxrox ( https://docs.ansible.com/projects/ansible/latest/collections/community/pr oxmox/) Collection 可管理VM.LXC、盖集资源和部分故定。 Ansible 迪合 Guest 初始化、批次操作和投定管理,但需要正确剩分 PVE API 概跟典 Guest 内部管理權限。 Packer HashiCorp Packer Proxmox Plugin ( https : //developer.hashicorp com/packer/1ntegrat:1ons/hash1corp/proxmox ) 可建立可重癌的VH模板。 常見流程是: Packer 建立基建肤像 cloud-init 初始化 → Terrafonm 建立 vH

• Ansible 完成跟定

重控具增份血数粒用 复制 API SDK 常見用户端包括:

• Proxmoxer: Python;

• go-proxmox: Go:

• Cors1nvest: PowerShell;

• 各 TypeScript、Java 和 Rust 社群 SDK

APISDK不是官方支援遍界的一部分。相客性仍以PVE APIViewer和實账版本测试為单 Proxnox 臭 Kubernetes 的低 PVE 可以承鞭 Kubernetes,但 PVE 本身不是 Kubernetes 行薇。 最常見的架横是在 PVE 上建立多VM,再在VM中部署 Kubernetes。福方式的隔、核心相 客性和升级遍界最清暖。 在 LXC中独行Kubernetes 可以降低部分资漆,但鲁遇到核心能力、巢状cgroups、 AppArmor、mount、網路和健存相容周题,不查合作益预投生產方案。 相额生感包括:

• Talos Linux;

• Flatcar Container Linux;

• Ubuntu, Deblan, Rocky Linux;

• kubeadm, K3s, RKE2;

• Cluster API Pravider Proxmox,常見宽明為 CAPNOX;

• Proxmox CSI Plugin;

• Proxmox Cloud ControlLer Manager;

• KubeVirt.

CSI、 CCM 和 Cluster API Prov1der 多为社群專案。 升级 PVE、 Kubernetes 或 Prov1der 前,需要验报API、筋贴拓探、磁础逻移和故险虚理。 不建播直报在 PVE 主碳安装Kubernetes、Docker 或一般業服務。PVE 主機应主要承握 Hypervisor、存和货管理脂景。 监控、安全奥周遗生娠 PVE内建任将日肱、系统日、資游图表、董集状和通知。 外部整控常見遇授包括:

• Prometheus PVE Exporter;

• Grafana:

• Zabb1x Proxmox VE by HTTP;

• InfluxDB:

• Graphite;

• Checkmk;

• Netdata;

• Telegraf;

• node_exporter:

• Ceph Dashboard,

日赫和安全分析可以使用:

• rsyslog 或 syslog-ng:

• Loki;

• Elastic Stack;

• Wazuh;

• aud1td,

安全基線至少包括:

• 管理面使用獨立VLAN或钢路:

• 限制 8886、SSH、Corosync、Ceph 和储存路的存取;

• 用MFA;

• API Token 探用小權限;

• 资免日常使用root;

• 定期更新PVE、核心、微碼和韧體;

• 便用 ACNE或受控 PKI 管理 TLS潜;

• 保/etc/pve、借份加密金端和 PBS權限:

• 到第三方剧本Provider 积行程式础稽核;

• 定期利松恢瘦興密集故障。

PVE防火精、MFA和加密借份都不能替代管理面網路理能奥醛限治理。 GPU、PCIe、VDI 奥速端存取 PVE支援常見的硬加通路径:

• VFIO PCI Passthrough;

• SR-I0V:

• NVIDIA vGPU;

• Intel iGPU;

• AMD GPU;

• USB, HBA、 NIC 和 NVMe 直通,

装置直通可以接近原生效能,但鲁限制续上遵移,亚增加 IOMMU Group、韧、驱动、Reset Bug 和授權管理福注度。 VDI闵速端鹰用生据包括:

• SPICE;

• RDP;

• Apache Guacamole;

• Kasm Workspaces:

• UDS Enterprise;

• Leostream:

• Parsec;

• Sunshine/Moonlight.

Proxmox VE 可以承额桌面VM,但不是完整的企繁VDI Broker。大规模桌面池、使用者設定、题 用缝布、GPU排程和还级代理通常需要额外產品。 社群本具第三方工具 Proxmox生馨中最知名的社群工具之一是 Proxmox VE Hel.per-Scr1pts (https : //github . con/community-scripts/ProxmoxVE ) 它能快速建立各熟LXC和底用環境,通合图人置验、PoC和非翻键眼孩。 凰验也很直接:

• 图本經常以root 在 PVE 主操执行;

,不同愿用本的品質和维握状不一致;

• PVE主版本升级可能造成相容限题:

• 快速安装不代表具借借份、整控、安全和退出方案。

生毫竭境需要固定commit、阅通原始碼、立内部映像、限制细路测试恢衡。 同爆的原则也逾用於 Terraforn Provider、AnsibLe Role、Exporter、CSI、鳞存外排和非 官方手操用户端, 源不等龄Proxmax官方支振;要案活强:也不等的具偏企 SLA

四、場景選型與部署建​

工作负显愿先按照核心需求,信任遗界、相容性和装置需求分,再决定使用VM、一般容器、沙箱、 MicroVM 或其他执行方式 【三:虚提化技術遗型流程】

通用Linux或Windows伺服器 逾合使用 KVN/QENU VM, 原因是Guest 相容性高、隔摊遥界清晰、借份與還移成熟,PVE、Libvirt、OpenStack. Hyper-V和 VMare 都属於常見管理退挥。 可信内部微服务 逾合使用 containerd、CRI-0、Docker 或 Podnan, 加上 runc 或 crun, 如果需要大规模编排。可以使用Kubernetes。安全性主要依主糖核心、映像供愿录、概限和翊路 策略。 不可信程式碼、第三方外播或 AI Agent

一般容器不愿作為唯一隔雕退界。​

可以考:

• Firecracker:

• Kata Containers;

• gVisor;

• 狮立 KVN/QEMU VM;

• 密容器。

具體进取决於LinuxABI、联置需求、敏動诗围、密度和威骨模型。 跨CPU莱 完整作藏系统使用QEMUTCG. 量一程式可以考虚QENU User、FEX 或Box64.若能重新编耀,原生多架柄映像通常更输。 Serverless 奥Scale-to-zero Firecracker、 Cloud Hypervisor、 Kata, Kasm 和 Unikernel 都可董通用。 需要實洲的不是單純「VM故動時周:,而是缺像下、解墨、细路、存、离用初始化、JIT和第

一個幅求的完整延還​

家庭實验室 单静贴 PVE 加 ZFS Mirror 是常见起贴. 偷份宣使用另一壹装置上的PBS,或至少放在蜀立故障域。Docker终一般应用服故在VK或 LXC中,不直接堆叠在PVE 主概 小型企嘴 常见架精是三筋贴 PVE、强立 PBS、10GbE或更高频寞,以及 ZFS、NFS/iSCSI 或绑遇客量 的Ceph, 遗需要鉴控、集中日结、UPS、翼地做价、經限管理具定期恢物演貌。 多站黏奥中大型玻境 需要考威:

• 多個编立 PVE普集;

• PDM 统一橡视;

• 跨站贴 PBS同步;

• Ceph、企蒙 SAN 或第三方分敏式储存;

• CMDB、IaC、SIEM 和统一身分管理:

• 升额批次舆回復方案;

• 明磷的支提合同购责任遍界

Proxnox的侵贴與限制 主要優贴

• 接心功能拥源,没有用訂圈锁定 HA、遭移和露果;

• KVM/QEMU 翼LXC整合完整:

• Web UI、API 和 CLI 覆露面质;

• ZFS、Ceph、NFS、iSCSI 等继存项富;

• PBS的借份整合度高:

• 單贴到中型著集都能探用;

• 硬體需求相對通用:

• 社群、自動化和第三方整合快速成长。

主要限制

• 多租户公有要能力不等同於OpenStack;

• 大规权企管理成熟废仍需结合PDH的登展解估;

• Ceph,SDN、HA 和 GPU 直通都需要實察 Linux 维通能力;

• LXC不是强胱 VM;

• 第三方 Provider、CSI、Exporter 和胞本不在官方支援逸界内:

• 虚凝防火精、VDI、CNDB、SIEM 和完盛ITSH 仍需外部系统;

• 董集智贴不能愈跨高延還站贴相应一Corosync盖集:

• 没有合理硬髓、期路與偏份说计時,期源接耀不會自動降低整證风险。

部署前的杆估清單

• CPU是否支援虚授化具IOMM;

• NUMA、記糖疆、Huge Pages 和超震策路;

• Windows、Linux、 BSD 或特殊 Guest 栏客性;

• GPU, HBA、 NIC 和 USB 直通薇求,

集

• 静黏影量quorun;

• 節點数量贝quorum;

• Corosync延邂、丢包和獨立键路;

• fencing Watchdog:

• 故障節點恢復流程;

• 升级與重新動顺序。

存

• IOPS、吞吐、延和容量;

• 本機或共享;

• ZFS、Ceph、SAN 或 NAS;

• 快照、複裂與線上逻移;

• 故障域和重建時間;

• 寫入快取、UPS和资料完整性。

網路

• 管理、Corosync、储存、遵移和Guest鋼路是否分離;

• VLAN、Bond、MTU 和 LACP;

• SDN、VXLAN、EVPN 和 IPAM;

• 防火與速端管理;

• 管理面失聯時的恢復路。

備份

• PBS是否位於獨立故障域;

• 是否有翼地、離線或不可副本;

• 加密金如何保管:

• Verify、Prune 和 Garbage Collection 排程;

• VM、檔案、资料座和整站恢復是否經過演。

自動化舆安全

• APIToken是否探用最小權限;

• TerraformState是否加密舆受控;

• Provider、Collection 和本是否定版本;

• 是否具備测試環境;

• 第三方原始碼和映像是否經過稽核;

• 日、监控、告警和SIEM是否覆蓄管理面。

結語 QEMU、KVM、Docker 和ProxmoX之間不存在簡單的替代係。 KVM提供核心虚凝化能力,QEMU建立與執行虚凝機器,Docker管理共享核心的容器,Proxmox VE则把KVM/QEMU、LXC、集、储存、鋼路和管理工具整合成基硬設施平台。 容器、MicroVM、gVisor、Kata、Wasm和機密谨算也不是線性升级關係。每一種方案都在隔龙強 度、Guest相容性、動速度、資源密度、装置能力和维通成本之間作出不同取拾。 合理的避型顺序應當是:

1.定義工作負載贝威育模型;​

2.定是否需要揭立核心;​

3.定Guest作業系统、CPU架和装置需求;​

4.比较備份、遭移、监控和故障恢復能力;​

5.验開源專案的状態與支援遗界:​

6.在實硬體和網路上完成基測試;​

7.最後决定探用VM、容器、沙箱、MicroVM、Wasm或混合架。​

Proxmox的位置也因此得清晰:它不是所有虚凝化技術的替代品,而是一套以LinuX闻源技術為 基、偏向實際资料中心與私有基碰設施管理的整合平台。 参考資料

• Proxmox官方產品與版本(https://www.proxmox.com/en/home)

• Proxmox VE Administration Guide (https://pve.proxmox.com/pve-docs/pve-

admin-guide.pdf )

• Proxmox VE API Viewer (https://pve.proxmox.com/pve-docs/api-viewer/)

• Proxmox官方原始碼(https://git.proxmox.com/)

• Proxmox Datacenter Manager 文件(https://pdm.proxmox.com/docs/)

• QEMU System Emulation

(https : //www.qemu.org/docs/master/system/index.html)

• Linux KVM 文件

(https : //www.kernel.org/doc/html/latest/virt/kvm/index.html )

• OCI Runtime Specification (https://github.com/opencontainers/runtime-

spec)

• containerd Runtime v2 (https://containerd.io/docs/2.3/runtime-v2/)

• Firecracker Architecture (https://github.com/firecracker-

microvm/firecracker/blob/main/docs/design.md )

• Kata Containers Architecture (https://github.com/kata-containers/kata-

containers/blob/main/docs/design/architecture/README.md )

• gVisor Security Model

(https://gvisor.dev/docs/architecture_guide/security/)

• Confidential Containers

(https://confidentialcontainers.org/docs/architecture/design- overview/)

• Ansible community.proxmox

(https://docs.ansible.com/projects/ansible/latest/collections/community /proxmox/)

• Terraform/0penTofu bpg Provider (https://github.com/bpg/terraform-

provider-proxmox)

• Packer Proxmox Plugin

(https://developer.hashicorp.com/packer/integrations/hashicorp/proxmox )

原始排版图​

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

发布于 2026-07-27 00:06:14（微信公众号导出记录）。

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

原文链接：查看原文

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

正文（本地 OCR 转写）​

11带進UTM original we×x7ce EI V1ajero 2826年7月27日 86:86德国

一直以来,在 Mac 上用 UTH 或 QEMU 敦行 WIndows,真正解的显不是CPU,而是​

GPU.现在,UTN 圈除公了一套名為 Triton 的 Windows 示卡显熟程式,配合 Neptune 国形得输族定,旗Windovs 11ARM64虚授第一次可以透通QEMU完整走通 DirectX 11 国形堆叠,

?

墨:x64 盛CCrash Band1coot N.Sane Tr1logy> 执行於 Windows 11 AR54 虚凝据,智 主系统為macOS,置片来源:UTM官方烯客。 如果只看董面,遗似乎只是「QEMU終於能跑3D避越:。但Triton真正重要的地方,不是馆某

一款逊截熟强示出来,而是它遇握徙Windows颤示卡扇数唇解决同题​

这意味著 Windows 自己的 DirectX.DXGI、桌面合成器DWM,以及一般藻用程式看到的都是一张 正常的虚损题示卡,而不是某個逊就目操理被愉愉替换的DLL。 这是QEMU Windows圆形虚提化長期缺失的一境拼图 問題來不只是「把置面示出來」 QENU很早就能机提题示装置,Windows也可以在其中顯示桌面。但能顯示桌面,與摇有现代 CPU 加速,是南回事。 傅统的 QEMU W1ndows 虚凝模通常依强基能鳞示驱起、QXL、V1rtI0-GPU 的有限功能,或者直接 由CPU进行敢疆渣染。用录安装系統、操作一般視窗没有同随,但只要应用程式要求DirectX

11.Shader Model 5.0或赖完整的 3D 功能,同显就會立刻出现。​

遇去也有人需试把 Wine、DXVK 等票案產生的 d3d11.clLl和cxg1.dlL放造Windows 逝截 目錄,截逝载的 DirectX 呼叫。再博成 VuLkan. 这種方法能旗部分道款的数,部有费回根本缺陷:

1.每個离用程式都要摇放置DLL,無法成為系统级解决方离​

2.W1ndows桌面合成器DMM 不會把這些重面管成正常的 GPU共享瓷源,經常需要CPU 额外​

3. d3dl1.dll​

和cxgi.dL1本来就是Windows核心元件,直接暂换會带来大量相容性同题。

4.逝截反作系统可能把這種DLL注入或替投視為具常行益。​

因此,UTH图陈没有耀停留在「替换 D1rectX DLL遭德路,而是决定置作真正的 W1ndows 示卡盟動程式介面。 Triton、Neptune和QEMU,各自負黄什? 整量方案由展国部分组成。它們的名稿很多,但分工其官很清楚。 Triton 是安装在 Windows 虚凝檬性的 DirectX 11 示卡驱动程式。它接收 Windows 国形 系接送給硬耀廠商鉴勤程式的DOI呼叫。 Neptune 是一芒 Direct3D虚凝化像定,负青把 Direct3D API 呼叫序列化,穿遇VirtI0 员 虑澄碳遍界,送到宿主系统。 virglrenderer 位於宿主系统,负青摇收Neptune鑫令,管理不同溢染内容园資源,然後把 Direct3D呼叫交绘真正的富主端谊染後端 DXVK、DXMT 或 D3DMetal 才是最拒命令概拍為Vulkan 或Metal、交给實體GPU 韩行的元 件。 把整條键路摊開,大致如下:

• DirectX 11 / DXGI APIWindows 系统 d3d11.dll, dxgi.dll

windovs 说截或展用程式 复制 所以,道不是把Mac的GPU 直接!直通給W1ndows。W1ndows 虚凝操看到的是一张V1rtI0 虚期示卡;淤截產生的Direct3D斋令被送到缩主系统,再由宿主系純的国形API教行。 遗更接近置形API 通露铁行,而不是傅 PCIe GPU Passthrough. 為什一定要做真正的Windows動程式? Windows 的 DirectX 架桶大致分成三凰。 显上是游感使用的 Direct3D API; 中显是 Windows 自确的 d3d11.dll 和 dxg1.dlL :最 下唇刚是题示卡商提供的使用者模式驱数程式UMD买核心模式驱融程式KMD

一般进截呼a叫 DirectX 11時。d3d11.dLL曹負费状感造蹈,参数验和资源曾理,再把整理過​

的DDI命令交鳍示卡驱勤程式。 真正的 NVIDIA、AMD、Intel 勤程式含在遗理把 DDI命令特成硬體措令:Triton 别把它們师 回 Neptune 能期何输的 D1rect3D API, 也就是战,資料在 Windows 理走了一次: Direct3D API - Mindows DI 复制 进入Triton ,又被反向换: Windous DOT ~ Direct3D API 复制 看起来像续了一圈,但遗正是Triton最聘明的般計。 UTN围隧不完要再塗明一套鹿大的虚凝GPU招令集,也不案要在宿主端重新育一DDI解器。 Triton 只要把 DDI 呼叫到回 Direct3D API,就能直接重用已经完成的 Neptune 傅输墨。 VirtualBox 的源DirectX 11鉴勤程式探用另一種方式:先把DDI聘成自己的中限命令格 式。得到宿主端後再解湿回DirectX、这條路可以谨作,但多一屑博换就多一唇相容性凰险,而且 VirtualBox 的 GPLv3 授也不遮合直接整合进 QEMU, Mesa 與virglrenderer 的现有程式 因此,UTM图陈主要把 VirtuaLBox 当成行為参考,用来殖蕊哪些DDI 函式是必要的。以及 Windows實期待驱动程式如何回虑,而不是置接移通其程式础。 最棘手的一關:重新拼回DXBC著色器 DirectX 11 時代的 HLSL 著色错通常鲁被编环成 DXBC, 避藏最初交绵u3d11.dl1的不只有著色翻指令,還有一但完整的DXContainer,其中包含输人 签名、输出签名、省源瓷讯等中瘤瓷料。 周题在於,W1ndows 呼叫示卡辅动程式的 DDI特,遗些中疆囊科已题被D1rect3D Runt1ne 治耗掉了。Triton拿到的往往只剩核心著色器位元码。 但Triton 接下来要重新呼叫宿主端Direct3D API,而宿主端又指待看到完整的 DXContainer。 於是Triton必须分析DXBC指令,推幕出已经逼失的输入、输出签名和其他榴位,再重新组装一 可用的DXContainer。真正的若色器指令可以保持不曼,但外圈结椭必须被里新建立。 这是整個方案理最胞弱的跟的。签名或格式推弹稍有错换,就可能表现為:

• 字型或通示示罐误;

• 红色舆绿色通道交换:

• 粒子效果武常;

• 視窗适明遗失;

• 視窗选明应通失:

• 某些避越著色器编理失败;

• 题示辐动程式亚设,基至演虚摄機盈蛋面。

• 期示驱助程式重设,甚至操虚摄概蓝盖面。

UTN围陈也明硬表示,DXBC容重建是目前實作中最容易出猫、仍需要大量相容性润就的部分。 能跑游還不,Windows桌面合成才是真正的考驗

iajere 显: Windows 11 在 Ubuntu/KVM/QEMU 中航行, DxDiag 已辨噬 Red Hat VirtI0 GPU 3D controller,Direct3D Acceleration 顯示為 Enabled,露片来源:UTM 官方博客。 全量幕遵戴可以示,不代表虚提示卡已翘完整可用。 Windows桌面单不是爆每個愿用程式直接把墨面送到蟹幂。每個程式先在白己的GPU纹理中增裂, 然後交给 Desktop Window Manager,也就是 DWMDwM 再把磨用程式视窗、除影、适明效果、 工作列、游檬和動量合成为最终董面。 这要求虚GPU支援跨程序共享纹理。 例如,激震器程序奎生一张纹理,DWM 程序必须能在另一個 GPU 内容中阴敏同一张紋理,银测 器已经董完,再把它合成进桌面。 因此,Triton/Neptune 不只要傅返继国命令,通必须解決商件事: 共享敏理:同一份GPU董应如何被不同程序、不同染内容,甚至不同宿主端鞋动程序存取。 共享Fence:生者和消资者如何碰到方已經完成 GPU 工作,避免DMM在愿用程式遗盖完時 篇取纹理,遗成新裂、黑帕或半成品董面。 UTN 最初把 Swapchain 遥辑放在宿主,後来登现遗 Windows 的 DXGI、DiM工作方式不 合。最终方案是把 Swapchain 管理移回虚疑機内,旗Windows 和 Neptune 驱勤程式管理背景 疑街區,宿主端只负责匯入、睡出共享资源和最终揭描输出。 这個改融壤架椭更接近 Vulkan 虚提化方案 Venus,也减少了virglrenderer 中事属於 Neptune 的特殊遥辑。 在Linux上相對直接,在macOS上要多走步 Linux 宿主端可以使用 DXVK,把 Direct3D 11 畅成 VuLkan,再交给原生 VuLkan 驱勤程 式。現代 Linux GPU 驱融的 VuLkan 支缓已链相當成。因此遭路相對清楚: nd5 xnuT1 - uey1nA - XAX - TT 05sT0 + sunsdan 复制 macOS 的情况不同Apple 有提供原生 VuLkan 疆数,主力国形 API 是 Metal. UTM 围陈估了三條路. 方案一:DXVK+MoltenVK 这是最直裂的组合: Direct30 11 ~ DxvK ~ vuLkan - MoLtenVK ~ Metal 复制 但每多一唇API翻理,相容性就童受最弱的一限制UTM基账的测实結果是,DXVK 加 MoltenVK可以轨行部分内容,但仍存在程定性阅国形功能缺口,不通合作為目前的主要方案。 方案二:DXMT DXNT 直接把 Direct3D 11 疆成 Metal,省掉 Vulkan MoltenVK: Direct30 11 ~ DXMT ~ Metal 复制 DXNT 原本主要服務 Wine。為了爆它能被 virglrenderer 蓄作原生 macOS 函式摩使用,UTM 圈除摘充了libdat-native.dylib,加人跨程序共享效理、事件和Fence 等介面。 DXMT是用源方案,而且可以原生编深高ARM64,遗對末来盈合进UTM事常重要。 QEMU 3DMARK

8920 Fire Strike 10 143 10 047 4 305

盈:DXMT後端下的F1reStr1ke测试墨面,此可證明完整烈试流程能购胞通,但不同截置未 必使用相司硬赠资测腻段定,不癌只按墨密分数置描比殿。黑片束源:UTM官方语客。 方案三:AppleD3DMetal Apple 的 Gane Porting Toolkit 内含 D3DMetal.framework, 可以把 Direct3D 11. Direct3D 12 直接嵊成 Metal,兼包含 DXBC、DXIL 到 Apple GPU 中間碼的幅器。 D3DNetal 的效能通常侵於目前的DXMT。UTM媒為它鞭作了d3dnetaL-native包装,旗原 本面向 Apple Wine 環境的 D3DMetal可以在一般macOS 程序中使用。循上跨程序共享资源 等能力。 不退,它有两回现宵限制。

第一,D3DMetal.framework 目前只有 x86 64 薇本。在 Apple Silicon 上,联人它​

的virgl_render_server 必须透退 Rosetta 2 软行。令人意外的是,即使多了 Rosetta,制 航效能仍然高的原生 ARM54 的 DXMT。

第二,也是更大的周題:Apple 的授權保款限制 D30Metal只能用於在 Apple 品牌品上登、​

测或估逝截,而且懂允非商满放布。UTH因此期法直接把D3DMetal打包造正式庭用程式。 QEMU VI 11 534 Fire Strike 14 068 10 035 5 423

:D3DMetaT 下的Fire Strike 源腻蛋面,D30Metal由 x86_64 染程序透返 Rosetta 2敦行。圆片来源:UTM富方博查。 UTN 围隙提到,育業版 CrossOver 可以散布 D3DMetal,據稽是因為 Codeieavers 與 Apple 另有熔。如果UTM未来拿不到频似授框,正式版更可能以開源DXMT為主要macOS後端。 AppLeSiLicon的共享記憶體,也被用来解决跨程序 纹理 virglrenderer 预股量為不同渣染内容敬握立的virg_rencr_scrver程序。遗核做可以展 雕锚损:其固进截或治染器增溃,不至於指均整固虚凝機。 代情是,不同程序不能直接共享一般的MTLTexture物件。 Apple 官方建播的 MTLSharedTexturcHandle 需要 XPC,但 QEMU virglrenderer 原本 大量使用 Unix 榕案描述符和SCNRICHTS博通资源,如果為此把QEMU、virgLrenderer、 SPICE的程序通部全部改造成XPC,工程范室會大幅接张。 目前方案利用AppleSilicon的一記博體架横UMA:

1.使用shn open()建立共享记憶體:​

2.把榴案握述符透通5CM_RIGHTS傅給另一個清桑程序;​

3.每個程序都把同一段起憶體映射成MTLDutfer:​

4.GPU 和CPU因為共享實赠記博,可以看到同一份瓷料。​

这個方法的限制是只能方便地建立德性效理,記憶體效率不如GPU最佳化的排列方式。但只要真正需 要跨程序共享的理数量有限,它仍是一因實用的初期方案。 Fence同步也探用频似的折衷。生者GPU在完成绝装後,把時绚综数值意进共享记德疆:消背者 CPU输物胶数值,確超继装已完成後,两提交合成命令。 它可以保铅正確性,但CPU 确现提交等待會需来额外延逻。長期来看,便用XPC和真正 的MTLSharedEventHandLe仍可能是效能亚理想的方向。 效能到了什程度? UTN 的伴髓删登记降公布了一组同一宿主模上的最 Fire Strike 潮腻: 渲梁路径 Fire Strike 分数 Windows 腺握硬 + DXYMT ARH64 5124 windovs 虚+ D3DMctal x85_64/ Rosctta 5682 闵 Linux/ Wine 募考路得 换算後,DXNT大的達到参考路径的67%,D30Metal的为75% 这是一有情值的禁果,但需要正随理解:

• 参考對象是同一台橡器上的 Linux/Wine,不是原生Windows,也不是Parallels,

• Fire Strike 只是單一基测腻,不能代表所有游截。

• 不同道殿的瓶頭可能出现在CPU指令轉辉、著色器、共享紋理、同步、驱勋程式或宿主端

API, ,「测就可以跑完:比單一分数亚重要,因它耀明Direct3D、DkM、共享資源和董面输出已握完 整走通 值得注意的是,UTH的最終测试仍记族到不超通0.8%的需幅率。造已辉比開登初期明葡改善,但也 明整套方案仍處於需要继缅打磨的陪段。 「完整DirectX11不等於所有避都能玩 UTN 官方把Triton描述為益QEMU傅来完整DirectX 11支援。造裸的「完整:,亚適合理解 為DirectX 11疑勤程式架和主要 DDI路径已继打通,而不是一份所有 DirectX 11逝截的 相容性保验。 目前仍有策项明硬限制:

• 核心目标是DirectX 11,亚不代表Windows虚挺機已须得DirectX 12驱勃程式

• macOS後端的共享效理关Fence仍包含效能折表。

• DXBC容器重建可能造成特定老色器相容性開题。

• W1ndows脂前程式仍被官方標记为‘非常不程定:

• 官方特剧警告,不要把测试版疆動安装到任何重要的虚授中。

• 日前需要自行编靠多個分支,還不是UTM正式版程的一但首通用鼠。

• 使用正式显動程式架精可以逾替投 DLL的部分反作瞬同题,但虑凝榜跟境,Windows on

ARM和實验性驱物本身仍可能被核心级反作辨拒能。 另外,官方展示的是x64逝截执行於Windows 11ARM64.造代表游整的CPU 指令還需要由 Windowson ARH 畅,而国形命令再由Triton/Neptune博到宿主强。它榴明整修路径具有相 當强的實用性,但也意味著宵察效能不只取决龄GPU 這不是一個孤立的補丁,而是一整套開源圖形堆叠 Triton 亚不是只繁改一個 QEMU 榴案。公附程式碼分布在多他專案:

• QEMU:加人 Neptune VirtID-GPU 能力與相虚凝示装置;

• virglrenderer:加入 Neptune 蜜主端奥溶染何服器支援;

• Windows UMD: 實作 DirectX 11 DDI Triton 遵辑:

• Windows KMD:管理配恒疆、命令嫌衡區、Fence 和 VirtIO 通讯;

• DXMT:加入原生nacOS函式库和跨程序共享资源:

• 3dmetal-native:把 Apple D3DMetal包装成一般mac0S 程序可便用的後端;

• 動程式础置即本:负费ARM64、ARM64EC、x64疆封装

UTN围隙正在管就把能狗通用化的修改送回上游票案。请一步非常重要:只有显脱大量私人分支,进 人QEMU、Mesa,virgLrenderer 等正式發流程,後绩维摄、浏试與微布才可能真正辑定。 另一個值得注意的部分:大量程式碼由AI完成 原文署名除了UTM發者osy.還包括claude-cpus-4-。伴髓文章波露,Triton的開發大量 使用多 AI 程式设計代理。 公例统計包括:

• 40活灌用日:

• 2,178次使用者据令;

• 豹6,740 离出Token;

• 估算API成本14,768美元;

• 期發者表示,白己次有期手擦高最终程式碼

但这效不是「输入一句提示。AI就自己做出示卡驱数程式。 人验者仍然负舞退握能、拆解同题、我断API合约、客查希票、崭察實胞量面、投计到方 法。以及否决看似合理但實隐锚误的方案。開發记条甚至提到,AI最初座生造一套愚空隐测的DXBC 實作,後来被完整拾案,改为依挑已知可工作的参考實作重寫。 圆形驱劲程式最大的鞋黏之一,是「温面看起束不對:很群直接化為機器可输盗的條件。黑躺、微卡 弧、赖色继联、遗失的桌面圆唇,都密要先建立霍圈、追戏、著色器储印或董面取楼工具,AI才能造

一步定位。​

因此,图專案更草確的意兼是:一名熟悉QEMU、Windows显融奥图形架的工程师,利用大量代 理谨算,把原本可能需要数月的實作买除工作整缩到数遇,而不是AI取代了圆形動工程的。 Triton對UTM和QEMU意味著什? 遇去,UTH在 Apple Silicon 上的霍势是源、自由、支援大量架横,也能很好地執行 Windows ARH 和 Linux. 但只要涉及 Windows 3D 医用程式,它翼 Paralel.s Desktop、 Triton證明了這個差距非無法跨越。 它已經完成個關鍵里程碑:

1.WindowS能把VirtI0-GPU當成正常的3D顯示装置;​

2.DirectX11DDI可以穿過VirtI0界;​

3.WindowSDWM能使用共享GPU紋理完成桌面合成;​

4.Linux宿主可以透過DXVK/Vulkan渲染;​

5.macOS宿主可以透過DXMT或D3DMetal/Metal渲染;​

6.實隙x64避和3DMark可以在WindowS11ARM64虚機中執行。​

接下來真正困難的,不再是證明「能不能做到」,而是把它成普通使用者可以長期依赖的產品:

• 建立更廣泛的游相容性資料;

• 修正特定DXBC著色器問题;

• 降低跨程序共享和Fence同步的延;

• 完成穩定的WindowS動章與更新流程;

• 镶修改逐步進入上游;

• 解决D3DMetal的散布授權;

• 最終把整套元件包進UTM正式版本。

Triton最值得重視的地方,不是某一張游截圖,也不是某一個跑分。 它第一次證明:QEMU可以透過一套開源、可跨宿主平台的架構,為WindowS虚凝機提供真正整合 進作業系統的DirectX11顯示卡動程式。 現在的Triton還不適合安装進重要虚機,也不能取代成熟商業產品。但技術路線來看,UTM 已經跨過了「Windows3D加速是否可行的門楹。 剩下的問题,是穩定性、相容性、效能和產品化,而不再是零開始。 對開源虚凝化來,這可能是近年最值得關注的Windows圖形進展之一。

UTM Blog: Introducing Triton: DirectX 11 driver for QEMU UTM Blog: Bringup Notes: Building Triton

https://blog.getutm.app/2026/introducing-neptune-direct3d-virtualization-for-qemu/ UTM QEMU:utm-edition-neptune 分支 https://github.com/utmapp/qemu/tree/utm-edition-neptune UTM virglrenderer:neptune 分支 https://github.com/utmapp/virglrenderer/tree/neptune Windows UMD: virtio-win-mesa/neptune https://github.com/osy/virtio-win-mesa/tree/neptune https://github.com/osy/kvm-guest-drivers-windows/tree/neptune UTM DXMT https://github.com/utmapp/dxmt UTM d3dmetal-native https://github.com/utmapp/d3dmetal-native

原始排版图​

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

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

原文链接：查看原文

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

正文（本地 OCR 转写）​

一篇以BluetoothLowEnergy 规为主線的技药科普。本文只封RPA/IRK的理​

输、定位置與工程設計,不绑定任何特定產品或程式碼。 BluetoothLow Energy 装置必须在用因互相衢突的票求之闻取得平衡:

• 對外不能長期使用同一個無線位址,否则任何拥描器都可能跨時圈、跨地贴追酸它。

• 對已完成绑定的封等装置,又必须保有疆定身分,才能自動重速、恢加密與套用原有權

限。 RPA(Resolvable Private Address,可解析私有位址)是短期、可输暂的無综位址:IRK (Identity ResoLvingKey,身分解析金输)别是受信任装置用来把這困短期位址解析回長 期身分的128位元金。两者共同椭成BLEPrivacy 的核心機制 国定公司位址 完全随機且不可解析的位址 题以运但集法价装置 重造兴授困施 陌生操拦基只着到短期代然 RPA:會婴動的位址 持有IRK的已绑定装置可通

1.这雨個概念位於蓝牙技術體系的哪裡?​

RPA/IRK 不是GATT 特微值,也不是匯用厝密碼。它們横跨 BLE 的 Host、Controller 具安全管理流程: 喷势:角色需统 预 AI1/ATT 可男性·重过具P SaP / Seourity iton Host Eond Dwab

K0

Cortrolier / Links Layer

/ Ttadlo 业中量们集性的45 生元位 各责任可以离化為: 屋级 奥RPA/IRK有题的贵任 定羲 LE Privacy 的使用方式、导分位址翼 Privacy Mode GAP SMP 在配封/绑定遇程中協商亚分登IRK奥身分位址资讯 永久保存每個 Bond的身分、IRK、LTK 與感用權限 ↓50H 般定 Controller 的 Resolving List, RPA Timeout HCI 舆私模式 Controler/Link La 在廣播、描、發起速综等状中奎生或解析RPA yer 惠用屠 决定解析出的导分是否為Owner、是否有开镇或管理耀限 因此,RPA/IRK龄BLEPrivacy 奥身分管理:它和 SMP安全糖制合作,但本身不等龄 加密或授權。

2.為什固定蓝牙位址會成為同题?​

假設一支手機每天都以固定的D4:7A:.播。商場、車站炭門口的普通搭器即使不知道使 用者姓名,仍可把不同時間看到的同一位址串起来,形成移助轨踪。逼是「可速结性:同题:最 察者不必破解資料,只要判定雨次號来自同一装置,就已经能進行追藏。 單细每次產生全新的随機位址可以降低追跟能力,但也盲旗已绑定装置無法判断:眼前的陷生位 址是不是昨天配到遇的同一支手機。BLE因而需要一种對陌生人不標定、對受信任者可恢疆 定身分的位址。 BLE常見的装置位址類型 可否用 位址频型 高位類型位元 是否输替 IRK解典型用途 析 不丽於Rando Public Device Add 公隔、长期装置身 Address 通常固定 不需要 分 ress 子

一医上電遇​

有 Public Add Randon Static Add 期内通常固 不需要ress時的颗定身 11 ress 定 分 Non-Resolvable Pr 不要求受信任划等 可输替 00 显 ivate Address ( NR 端券滋的匿名场景 PA ) Bond後仍需自動 Resolvable Privat 期翰替 是辨舆重速的愿私 θ1 e Address (RPA) 场景 Public Address 奥 Randon Static Address 都可作為 Identity Address(身分位 址).身分位址是Bond資料重中的長期别资料:敏用Privacy 镂,装置在空中未必直接 傅送它。

3.RPA的48位元究竟如何形成?​

RPA仍然是一個48位元BLE位址,由两個24位元椭位组成: RPA = prand ( 24 bits) 11 hash (24 bits) hash = ah(IRK, prand) 其中:

• prand是24位元随糖值:其最高两固频型位元必清為61,用来表示RPA

hash是把128位元IRK與prand 翰人规箱定款的ah函式後截取的24位元结果。 ah的核心是AES-128:它不是把IRK直接放进位址,也不是可逆地加密整個位址。 pnd: 34 y R: 48 tias llpurr RE: 138bhs 以 AES-09 at0

.8 。

• EI Viajer

Bluetooth Core Specification 中的 RPA 格式翼生或公式 1: Bluetooth SIG 《Core Specification > Link Layer Specification, Private device address generation。墨面同时给出 hosh =ah(IRK,prend) 與 andamiddress = prand Il hasl。来源:Bluetooth Core 6.1 - Link Layer Specification toth:rom/gcontent/mplsafs/F1tes/5pecf1eat1os/L/Came-61/ut/es/s-energy https:/www.b1veto centrn11er/11nk-1ayer spec1f1ratan htm14uurp-sb77-4r1-5-b139-46f9-1hn32Taf7ef 為什看到的十六進位位址顺序常令人困惑? 规范圈、HCI参數、封包嫌取工具买日缺翰出的位元组顺序可能不同。有些工具以人類常见 的AA:BB:CC:DD:EE:FF形式由高位寡到低位,有些API则直接呈现記體或封包中的 little-endian 位元组序列。 工程上鹿先把资料正规化成48位元数值+address type;,再切分prand奥hash; 不要只靠字串左半、右半指需位。位址值相同但 adress type 不同,在 BLE 中仍是不同 位址。

4.IRK是什魔?它奥LTK有何差别?​

定的對等端,對等端日後就能判新的RPA是否於这個身分。

一筆典型Bond紀至少可能包含:​

是否直接负责资料加 资料 主要用途 密 Identity Address + Addres 侵期索引與楼定身分 显 5 Type Peer IRK 解析封方日後使用的 RPA 香 盈生本機RPA:必要時提供给 Local IRK 香 到方 後續速综恢复LinkLayer LTK ( Long Term Key) 是 加密 用铃签意,不是速源 签善末加密ATT资料 CSRK(若使用) 加密 Owner、管理員、防客、撤 唐用權限 由惠用决定 默態等 最量要的区分是: IRK回答這個會變勤的位址是?」;LTK回答如何恢覆與遗图已定身分的加密速 综?;题用授權回答这個身分可以做什魔? IRK在何時交换? BLE配对不是一個單一勤作,可概略分成靶力交换、生/確加密材料,以及 Transport Spec1f1c Key D1str1but1on.若方商分發 Ident1ty Key,IRK 與 Identity AddressInformation會在金锥分壁段交换,面且鳍段匯在已加密的速線上进行。 Centrsl g pg Peripheral Pairing Request Psiring Response 惊1/0能力·段坦方式舞Key Distr 位 融营科交描益建立通综加密材料 速爆速人加套供趣 皇分身目 Mdenty Infoaton IRK ) 这分能的Identy Iomaton IRK) Identity Addres Informa Identy AddressInfomation 存對方鼻分·Peer RK ·LTK 留存對方分·Peer IRK· LTK

BLuetooth Security Manager 中的 IRK 舅身分位址分 2:Bluetooth SIG《Security Manager Specification》列出IRK透退 Identity Information command 分. Public / Random Static Identity Address 别透通 Identity Address Information command 分發。来源:Bluetooth Core 6.3 — Security Manager Specification 53.6.1 manager -specL fication.htallu10-264a99uB-746b-4ca3-6c94-47cfbc746625 「配到成功,只表示本次安全程序完成:只有把长期资料保存下来,才形成可跨通银使用 的 Bond。若潮重殷後 Bond Database 遗失,即使先前曾經交换 IRK,也無法再解析 封等端。

5.收到一個RPA時,身分如何被解析?​

解析不是解密RPA,而是“拿候逻IRK重新計算一次,看看24位元hash是否相同. 元 Addnkm

披:Pbic / Sgric/NRA开 代± pand 优近9] hat M For K soalHlazh * ahPer II, prne

机成 : 胰肤 Bore ojofe)/ IG 這也是為什座Controller的解析清單容量與装置支援的Bond数量有同:最直巍的解析方 式,必须在候選IRK中寻找匹配者。實晶片可能用硬体加速:例如Nordic的AAR (Accelerated Address Resolver)周會IRK 資料结橘逐项管試,成功或失胶後 生事件。 nRF5340 Product Specification Resolving a resovable address

Nord1c nRF5340 AAR 硬想解析 RPA 的营方期期 3:Nordic nRF534e Product Specification 的 AAR 明 硬體 IRK9 起,依 NIRK 指定的数量逐一解析,最後毫生RESOLVED 或NOTRESOLVED。来源:Nord1c Semiconductor - Resolving a resolvable address https://decs. nsrdic icml,com/bL CtentIdFED5CkBH-B44ULU 24位元hash是否可能碰撞? 可能。RPA中可供比對的hash只有24位元,因此它不是無碰握的全城易分别碼。實作 应使用规轮提供的解析结果與完整Bond上下文,不鹿把 24位元hash單指蓄成使用者 ID、安全過涨或資料虚主键。真正的安全確仍由後缩的LTK加密程序鼠庭用层授完成。

6.ResolvingList:Controller如何知道有哪些可信身分?​

支援Controller-based Privacy 的控制器通需维Resolving List(解析清單)。 每一筆纪疑到一個已绑定對等端,常見橘位包括:

• Peer Identity Address S address type

• Peer IRK:用来解析對方的 RPA

• LocalIRK:奥额對等端互釉時,用来秦生或虚理本楼睡私位址

• 该身分的 Privacy Node

Host 透遇 HCI 把 Bond Database 中的资料同步到 Controller. Controller Reset 後,解析清单通常需要重新建立:因此持久化BondDatabase與翔機重建流程同等重要。

Resolving List 不是 Filter Accept List 雨者經常一起出现,但用途不同: 清軍 解決的同题 Resolving List 这個RPA對度到回已知身分? 哪些位址/易分可以参與指定的质握、操描或速银程序?」 Filter Accept List 先解析易分、再套用接受政策,是酸正確的心智模型。只把當下的RPA放进一般白名单,位址 替後就可能失效。

7.Controller-based 奥 Host-based Privacy​

BLE规巅允許疆私功能主要由Host 或Controller執行:

Controller-based Privacy 的侵黏是反惠快、Host 唤醒少,且可直接参與展插、描與 Init1at1ng等L1nkLayer 流程;限制则是硬體解析清單容量有限,董且必须正處理 HCI 同步奥 Reset 後重建。Host-based Privacy 比鞍弹性,但可能增加 CPU、延遮與 功耗,且控制器在某些诀质點未必来得及等待Host。 v Privaty

TI BLE5-Stack Host-based ControLLer-based Privacy 官方t用 4:TI BLE5-Stack User's Guide 戴明 LE Privacy 需通期性毫生新位址以降低長 期追,亚比较Host-based 與Controller-based Privacy。束源:Texas 期运浆, Instruments BLE5-Stack Privacy https://seftsare dt1 com/sirptelink/esd/sinpelnk c13kxcc26oxsdk/6.30.0.B4/e html/bte-stsck-5:x/prdwacy.tnt

8.一次完整的位址了但仍能安全重連​

RPA只完成第一步身分開融。成熟系统的重速路狸感把身分解析、加密恢復與愿用授權分: 名塞 Cortrslle / L Kest 8ord.Narupr 使异新的 IRA 保究适性 Renslieg Lit 中 Pee R 基 时指列其 Pe lHeveity

拒比受作/要家量所配刻 未关到等式 (ortr 这個顺序揭示三條不能退浠的安全界: L.RPA解析成功不等於通退显。它只是指出最可能是娜一董Bond。

2.LTK加密成功不等於有全部案務權限。愿用仍需检查角色、撤状患與敏感操作缘件。​

3.GATT已速線不等於已授耀。BLE允許先建立實速線,再到特微值存取要求加密、韶證或​

鹰用添据。

9.RPA是否代表支援多支手機?​

不直接代表。RPA/IRK解决的是多個已期定身分的辨端,而不是同时通線数量。 如景装置保存了手機A、B、C三筆Bond,亚把三個PeerIRK装入解析清單,那度三支手 楼即使各自输替RPA,装置仍可判断新的位址分别匾於A、B或C.這可支援多Owner、多 使用者或家庭成員的自勤量速设計。 但能記住三支手機;與能同時持三條BLE逼線;是两件事: Bond容量 能保存機固長期身分 可辨識多少支手機 Resolving List 容量 能同時解析固PeerIRK

Controller線資源 可同時連線支手機 排程·記憶體與協定樣上限

應用政策 每個身分能做什度 單一主控·多Owner·防客 所以部估多手機支援:至少要分别機查 Bond Database 容量、Resolving List 容量、 同时ACL速综上限,以及Owner/權限葡突政策。

10.PrivacyMode奥位址输替调期​

GAP定差两种與已知對等指互勤時的疆私模式: 核心行為 模式 常见考量 NetworkPr1到等端感使用可解析的私有位址;不把Id曝私鞍格,遗合希望降低 apou 人eA entity Address 成正常暂代 导分位址暴露的投計 封鲁装置/特殊流程较實 在特定相容情境下,也可接受封等端直接 Dev1ce Pr1v acy Mode 使用 Identity Address 容,但身分位址可能暴露 RPA输替频露,長時照靓察者金難只靠位址申接勒题:代循可能是更多位址更新、控制器工 作與互通性遗界。输替太慢则降低隐私效果,傅统實作常見15分键的RPATimeout; Bluetooth Core 6.1 进一步引入 Randon1zed RPA Updates,使更新時間不再形成遇度 退律的可觀察特。详見 Bluetooth SIG 的 Randomized RPA Updates 锐明。 位址响替也不能消除所有追隆線素。如果质播内容長期包含唯一序碱、固定商资料、罕見服務 祖合,或虞播间隔具有高度揭特性,翻察者仍可能进行指紋胃账:。完整的限私投計必须同時 检查位址岛 Advertising Data。

11.最常見的實作錯误​

把當下RPA當成永久资料库主键 位址输替後會被蓄成新装置。永久资料愿以BondRecord/Identity Address/内部不可 翼ID為索引,RPA只存在於短期速線上下文。 只保存IRK,没有保存身分位址奥addresstype 解析成功後仍需要知道它到愿一国標定身分。Address type也是身分的一部分,不能省 略。 Local IRK 與Peer IRK 放反

• Local IRK:本楼身分的IRK,主要用来產生本機RPA

• Peer IRK:對方身分的IRK,主要用来解析對方 RPA。

名耦癌始以目前造一端:為视角。資料康 schema、HCI参数與封包日若湿用视角,很 容易生方向错织。 Bond 已存入Flash,但Controller Reset 後没有重建Resolving List 會呈现為「刚配對時可重速,重般後全部炭成陌生手J。感把ResolvingList視為可 重建的敦行期快取,而不是唯一資料来源。 解析成功就直接授予敏感操作 RPA的24位元hash不提供完整虚强度。必须邀完成LTK 加密奥愿用授,敏感命 令遗应考虚重放防据、時序與使用者在場條件。 忽略容量、淘汰與撒銷 Bond Database 與硬禮ResolvingList 可能有不同容量。设計時要明確定瓣:清單滿了 如何虑理、哪些Bond侵先载入、删除使用者時如何同步移除IRK/LTK、善手機道失後如何 撤。 用位址字串直接拆prand/hash 不同API的byteorder 可能相反。测试向量必须同時固定:48位元数值、顯示字串、對 包位元组、addresstype、IRK 與预期解析结果。

12.建的工程架構​

一個健的BLE身分系统可分成五固明確模组:​

Palring Manager 協商安全等级典金编分报

Bond Store 持久化 IdentityIRK LTK·舒数器

Privacy Manager RPA Tmeout Prlvacy Mode Resolving List 同步

Link Security Manager 恢復加密椎查安全等级

Application Authorization Owner/角色/嫩/敏感 操作政策 遵守以下設計原则:

1.定身分奥空中位址分。鹰用層永遗使用内部Peer ID 或 Bond Handle,不直接依銷​

目前 RPA,

2.IRK、LTK奥權限分保存。三者生命通期相圆但磁賣不同,便於撤銷、通移與稽核。​

3.解析清單可重建。以非捶赞Bond Store為真實来源,開機與 ControllerReset 後​

重新同步。

1.授權晚於身分解析奥加密確。不渡“看起来像已知装置:直接榮成「可敦行敏感命令」。​

.删除 Bond 必须原子化。同時處理 Flash 紀錄、Resolving List、Filter Accept List、快取速線與度用角色。

3.把容量奥淘汰政策做成座品需求,不要等硬體回报MemoryCapacityExceeded才臨时​

决定。 最低限度測試矩陣 预期结果 全部解析到同—Peer Identity 同一手機速續座生多個RPA 不同手機各自输替 RPA 分别解析到各自 Bond,不互相串號 解析失亚套用陌生装置致策 未知IRK 產生的合法 RPA Controller Reset、Host 资料 重建Resolving List 後可再次解析 仍在 RPA不再取得原權限,蓄LTK不能恢復受信任 删除/撤销Bond 默慧 Resolving List 滋载 有明罐、淘汰或 Host fallback 行為 位元组顺序與 address type 错 测試能明確慎测,不出现默误判 RPA 解析成功但LTK验失胶 不授權敏感GATT 操作 隔私测试愿判定仍可被聊,要求修正payLoad 捶内容保持唯一指紋 RPA/IRK的本質不是「把MAC位址加密」,而是建立一個可遥選 性運結的假名系统:

• 對没有IRK的旁者,RPA是通期改曼、鞋以直接串接的短期代號。

• 對完成锦定亚持有IRK的到等端,RPA可以映射回概定身分。

• 映射身分之後,仍需由LTK恢復速综加密,再由應用盾决定權限。

• 多個PeerIRK可以支援辨满多支已绑定手機,但不自動代表可以同時速線多支手機。

• 真正完整的實作不只包含ah()演算法,遗包括Pairing Key Distribution、Bond

Store、Resolving List 同步、Reset 重建、撤銷、容量政策與应用授。 巴期湿的实全理明 炎界 Pee lbeitit 允济的建电预代 延伸開讀

1. [Bluetooth Core 6.1 Link Layer Specification: Device Address, RPA​

Generation/ Resolution] https://ww.bluetooth.com/wp- content/uploads/Files/Specification/HTML/Core-61/out/en/Low-energy- controller/link-layer-specification.htnl ?. [Bluetooth Core 6.3 - Security Manager Specification: Pairing 奥 Key Distr1but1on] https://waw.bluetooth.com/wp- content/uploads/F1les/Spec1f1cation/HTML/Core_v6.3/out/en/host/secu rity-manager-specification.html

3. [Bluetooth Core 6.2 - Generic Access Profile: Privacy Feature 奥​

Privacy Mode] https://waw.bluetooth. com/wp- content/uploads/Files/Specification/HTML/Core- 62/out/en/host/generic-access-profile.htnl

1. [Bluetooth SIG - Bluetooth Security and Privacy Best Practices​

Guide] https://www. bluetooth. com/download/bluetooth-security-and- privacy-best-practices-guide/

5. [Bluetooth SIG Enhancing Device Privacy with Randomized RPA​

Updates] https://www.bluetooth .com/blog/enhancing-device-privacy- and-energy-efficiency-with-bluetooth-randomized-rpa-updates/

5. [Texas Instruments - BLE5-Stack Privacy] https://software-​

dl. ti.com/simplelink/esd/simplelink_cc13xx_cc26xx_sdk/6.30.00.84/ex ports/docs/ble5stack/ble_user_guide/htnl/ble-stack-5 .x/privacy-html

7. [Nordic Semiconductor - Accelerated Address Resolver (AAR) ]​

https://docs.nordicsemi .com/bundle/ps_nrf5348/page/aar.html - resolving_resolvable_address?contentId=FE15Ck8QH~X8yB34t4ULUw

3. [Silicon Labs Resolving List API]​

https://docs .silabs.com/bluetooth/latest/bluetooth-stack-api/sl-bt- resolving-l1st

原始排版图​

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

发布于 2026-07-16 21:21:47（微信公众号导出记录）。

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

原文链接：查看原文

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

正文（本地 OCR 转写）​

手方法 originalwθx7ce EI V1ajero2826年7月16日 21:22 德国

很多人第一次看到xAIConsole的Voice Agents,富把它理解成迪姓麦克凰接到 Grok:。这個理解只碰到表面。 更准强的说法是:xAI正在把Grok接進電話系,镶一個電话號码背後可以是一位能融、能 锐、能查瓷料、能呼叫企案系统,也知道何時該轉真人的AI。 来電者不需要安装ApP、不荒要学新介面,照常服號即可。AI在通話中處理周题,必要时查詢 知避量、建立工單、查订量、预约时圈,或把通适精给人工。造就是Voice Agent的牵品宽 我。 这篇不想把它成“又多了一個AI功能」。我們就把四件事说清楚:它到底解决什度、通話 时怎磨跑、什座情沉值得用,以及第一次敲怎磨建。 先用一句話清楚 xAI Voice Agent=即時語音Grok+量話接入+知與工具+通話管通後台。 它不是單换把語音幕成文字,也不是先即天、再把答案念出来,XAI想做的是把即時语音、電 話、文件查詢、工具绸用、规别限制和通话紀疑放进同一套票西理。[1 Voice Agent API ledrh Mirage A in GriMid Quick Start

Ht 4get

营方 xAI Vo1ce Agent API 文件雷南 1{xAI 宫方 Vo1ce Agent API 文件。圖像来源:xAI Docs,截於2626-07-16。 為什魔現在要做電話AI? 因為“電话:一直是企業程最難自勤化、也最接近成交與同题解决的一條通道。 文字客服可以慢慢開错:冠活不行。来冠者舍插話、改口、口音很重、晋景很吵,還可能在一句 括理同時同價格、查訂单、改地址。傅统語音系统通常要把流程拆成三段:語音辨(STT)→ 文字模型(LLM)+语音合成(TTS)。每多一段,就多一個延近贴、單、串接和出错位置。 XAI的主强不是“把这三件事攀不重要:,而是把即时語音封括做成更密的一条路得。 Voice Agent BuiLder 將其描述為 speech-to-speech品:用同一個操作面完成語 音、電話、知蕨、工具與道括酿测。[1] 放到實際通括理,大概會有三個差别: L.等待時翻更短:電话理,回覆恒一秒和慢三秒,盛完全不同。

2.话更自然:使用者可以插话、铺充、否定前一句,而不是一输一输按键式同答。​

3.AI不只回答,遗能事:查资料只是开始:真正有震值的是预的、查詢、建立工單、稀人​

工興留下可追跟结果。 它在一次来電中究竟做了什?

文件/ FQ / S0P 企案工具 CRM / 红星 / 日度/工量 xAl voice Agent 電站狭胰 / SIP / PEX 束電者 验懂、推理、蛇话 韩底人 必要药换手 通话纪录 逐字脑/牺费/硬测

Voice Agent 东電案阳架据图 上图是在產品唇看运件事。若你要用自己的電話號碼,底下通常鲁运横跑:電话商或PBX先把 服拿到call_id後接上即时WebSocket,設定遗通電的驾音、指令和工具;接著,来 電者的登音进到他话,AI的整音再回到電适理。[2] 大多数圈除不用一开始就碰道些底唇细。Console 的Builder 已經把電話、Agent、知 、工具、通括記錄:做成可配置流程。真的需要保留既有號碼、PBX或巢系统時,再往 SIP、WebSocket、MCP 或自訂 API 走就好。

来者、AI合纠莱務系统之履的關低示意 来電者、AI音與業移孤能之胃的你示意 置2產品示意图:通菇不是終黏:AI把到括速到预的、客户資料與工單,此圆為本文原制播 蛋 量。 xAIVoiceAgent有哪些能力? 能力 可以用在哪狸 翡電、生成精音、虚理打暨與输次 客服、機、外呼、甜音助理 即时蟹向普音 官方资料稀支摆20+/25+言雪境 多韬言對话 跨境品牌、旅宿、海外銷售 文件與知递检 Agent已上傅的文件集合找答案 FAQ、至品手册、SOP、修款 索 CRK、灯單、存、日思、工 可使用Web/X搜导、MCP、函式或你 工具用 的 API 单 既有企業盛、PBX、频页/Ap 可造遇 SIP、WebSocket、LiveKit 電話接入 P部音 等方式接入 金额、疆私、投诉、無法確源 與科人工 限制可做的事,或在特定情况升级處理 的周翘 回看通活、逐字稿、工具钢用贝结果 質检、提示铜选代、警通分析 可戳测性 在 API ,xAI 已公醋 file_search、Web Search、X Search、速端 MCP 奥自訂 Function工具:因此它不必只回答文件有的内容:,也可以在通話中用你自己的服 。[3] 它適合哪些場景?哪些場景不該急著上? 值得優先警試的五種情境

1.客服橡機奥一综FAQ​

最通合虑理高重报、低风随的间题:叠時间、配送状慧、退换货规则、基本故摩排查。AI的 任稿不是“假装無所不知」,而是先把可概化的部分接仕,問题再带著接要轉人工。

2.预的、改期與提醒​

所、門店、维修、踊同、房屋看屋都很通合。Agent需要能端寒日唇,但建立预约:前愿 回端日期、时段、姓名與群方式,旗使用者班一次。

3.銷售综索初​

AI可以問需求、预算、所在地、時程與聊方式,将合格線索推进CRM,比起溪AI一通電 話就强行成交,這分工通常更。

4.售後回防與准度通知​

例如继修造应、服務滿意度、福件提醒、流程清楚、话術固定,且能把结果瘤回系统。

5.既有AI系统加上一個電话入口​

如果你已經有RAG、CRM、工作流或内部Agent,xAI可以负责低延逻通話:你的系统仍掌管 资料、權限與业移動作。這是很常見也很健康的分。 不該急著完全自動化的情况

• 涉及付款、退款、签约、醫癌建、法律判、帐户權限更。

• 你無法用工具或資料验證答案,希望它给出確定承诺。

• 没有真人接手流程,也没有通话客核與修正機制、

• 問题的主鞍场其實是Enail或文字工單,而不是電话。

外部测解的觀點很一致:VoiceAgent Builder 的分鐘建好確實降低了原型門楼,但 真正困耀的是把確、權限、例外處理與人工交接做好。尤其是「德錯一句話就敦行動作的 凰险,不能用更侵的提示词撤盖,必须靠明硫確流程與工具權限来虚理、[4] XAI想把它做成什? Tylee Tryitile

Comect your todts Catom guardnlt

xAI Voice Agent Builder 官方量品真雷面 3{xAI Voice Agent Builder 宫方產品真。像来源:xAI,截於2026-97-16。 xAI在2826年7月推出Voice Agent Builder(Beta)时,意思其宽很直接:不用 再零把電話、文件查詢、工具和通話記錄拼起来,警谨人員或開發者都可以先用自然語言把一 因電括 Agent 做出来,再慢澄接自己的系统。[1] 遍不代表它只適合不离程式的人。XAI同時留了三像路:

• 快速配置:在Console建Agent,接文件、工具、相與電话。

• 保留既有系統:以SIP带人原本赋碼,或速你的API/MCP。

• 深度自建:用ReaLtime WebSocket 接到自己的網真、App 或後端。

檬看就很清楚了:它不是束取代CRM、訂单系统或内部AI的。它比较像暂你福上一個能即 时别括的電話前台。 封於登者而言XAI遗提供三個免费的美国手機盛碼用於测试。 Voice Agents (r) 31 Q, r 9 μ

( O (1a

怎做出第一個電話Agent? 下面用xAI Console 的Voice Agents Beta 来走一遍。介面可能會改,但大致颠序不宝 差太多。 第0步:先想好它該做什、不該做什 不要“它是一位有助的客服:關始。先用一真低回答: L.这個電话键碼是给谁打的?

2.它最常處理哪三到五频事情?​

3.哪些事它翘到不能自己决定?​

1.什度時候必须转人工?​

5.它需要端取或寫入哪一個系统?​

这五他答案,比先挑哪信餐普重要得多, 第1步:在Console建立Agent 进入 Voice Agents,贴醒 Start from scratch,或先逻 Custoner Support、 Sales Associate,Appointnent Scheduler 等模板。

一開始只需要完成四件事:​

• Agent 名程:例如OrbitaCero中文服台1。

• 電话角色:客服、预的、销售初锦或继機。

• 主要语言與整音:中文庭在指令中明確离“使用體中文1。

• 一段髓短但有遗界的指令。

第2步:别只寫人設,把它要做的事講清楚 以下提示词可直接作為中文客服的起點,再按你的業務名福舆规则修改: 你是0rbitaCero;的繁错中文電服務员。 目标:临助来電者了解產品、直物服務流程、收集必要資料; 需要时使用已授權的工具查詢资計,或聘接真人同事。 龈括方式:自然、簡湿、耐心。一次只問一個問题; 先部采電看真正想解法的事,再回答或教行下一步。 工作规则:

1.只能做知凝或工具回傅的调訊回答:不确定時直接就明不确定。​

2.涉及價格、退款、付款、帐户、四资、法律或医康臂题時,不作末握验退的承诺。​

3。建立预的、修改资料、建立訂單或任何含改盈外部状感的勤作前, 必浪重述照键资訊請采電著明確确款,

4.若間题解法處理、来電者要求真人、或到话速额两次没有进展,按人工。​

5。结末前,用一句話摘要已完成的事则下一步。 遍段刻意没有寡得很長。xAI對grok-vo1ce-think-fast-1.0的建也差不多:模型萄强 時,指令反而愿敲短一點、乾净一點,不要把以前為了漏润寡的一堆workaround全塞進 去,[3] 第3步:接上知库舆工具 先一個小图开始: L.上需最常用的FAQ、品介绍、退换货规则或服務SOP。

2.測试Agent能不能引用正规则:答不出来時會不會坦白不知道。​

3.再接一個低鼠膀工具,例如“查韵警時间:或“請取可预的時段」。​

1.最後才接會改差資料的工具,例如建立预的、更新CRM或送韶訊息。​

覃:先旗AI看得到,再辖它讀得到,最後才镶它得造去。 第4步:配置電話舆測 在Builder中還择可用號码,或依官方SIP指引带入既有號码。企業自带赋弱時,電話 商/PBX 需要把路由指向sip.voicc.x.ai;官方文件有Tw1l1o、Telnyx、PLivo 奥自建 SIP 的步。[2] 實测至少要打道十通:

• 正常問题能否答對?

• 说話很快、有口音、背景有噪音時如何?

• 使用者中途插話時,首不會停下来赠?

• 日期、地址、童菇與姓名會不雪错?

• 工具失胶时會不會编答案?

• 不知道時能否自然人工?

• 使用者要求「取消:時,會不宝停止動作?

• 要執行预的或修改時,有没有二次確涩?

• 逐字稿、摘要與工具纪锋是否可追溯?

• 真人接手後,有没有拿到足萄上下文?

第5步:别只Demo,要回頭看纪錄 Deno無乎都很好账:真正要看的是一批真實到話。每遇可以抽看:

• 同题解决率舆转人工率:

• 韩人工的前三大原因;

• Agent最常答错的知藏贴;

• 被打断或沉默時的锥验;

• 工具额用是否成功、是否有不必要的操作;

• 每通成本與真正前省的人工时圈。

如果要接進自己的AI系统」,怎分工? 最實用的架横不是把所有束西都交给同一他模型,而是分唇: PSTN / SIP 充罪 xAl Woice Agent m的 Orchestrator / API 通然逐字稳具图控 Gatewat) 你的硬型成联公众考工客理用格r0 双座 / RAG CRM / 量 / 日摄 Voice Agent 则金案系统的责任通界 可以這楼分工:

• xAIVoiceAgent:即時收音、理解通话语境、龙话、打断虚理、引减對话。

• 你的後端:验源来電者、執行權限、存取CRM/订單、寫入資料、凰控、密計。

• 你的既有AI/RAG:回答你已有的專属知端或福工作流

• 人工:虚理例外、敏展决策、高凰险助作具品贺校正。

如是是细真或手機ApP,前不愿放xAI APIKey。官方理端由你的伺服器先取得短 效 Ephemeral Token,再把短效 Token 给测貨器或 App 速線;真正的API Key 留在後 端[5] 開發者怎看这件事? 这频產品最容易被“雨分鐘做出一個電話AI;吸引。但如果把圈外的實作教学、辞测和官方案 例放在一起看,大家真正心的其實不是它能不能開口说活,而是:它能不能在真實電話程穗穩 地把事游完 XAI主打的方向很明班:用一句自然語言描述,接上文件、工具和摇,就能很快做出可测试 的電話Agent。[1]遗個r楼链賣比前低很多。官方拿 StarLink作為案例,一個 Agent已能調用28因工具,滤理客服和銷售流程;公布的数字是客股自主解決率78% 销售詢间转换率20%,这是一因值得额察的方向,但它量意是供癌商公布的成熟案例,不是每 個图隙一接上就得到的成续。[6] 模型能力方面,xAI 在自己的 Builder 真面列出T-voice Bench 的Overall 成: Grok Voice Think Fast 1.0 為 67.3%, 同真列出 Gemini 3.1 Flash Live 為

43.8%,GPT Realtime 1.5 為 35.34, 第三方 Artificial Analysis 也将它列在​

Speech-to-Speech指標的前列。遗些结果至少说明它值得进入遇型名单:但電話品質仍要回 到自己的使用者、口音、毅讯、資料和流程来测,不能只着排行榜。[1][8] 看圆外限發者的教學,最有意思的地方反而是:他们很少把篇幅花在「把驾音调得更像真人」。 真正花時倒的,通常是電話號磁怎接、Webhook怎磨收、SIP怎磨路由、工具怎度調,以及 翼常時如何轴人。Vapi、Retell、Twil1o的實作文意都是這個路数:XAI的 SIP文件也 是同—但避辑。 [2][7] 也有第三方评测给出了一個很實在的提醒:原型做得快,不代表可以放心自勤執行。Eesel在 解测中肯定它把speech-to-speech、低延逻和無程式Builder 放在一起的座品方向,但 同時點出Beta存取、真實穩定性,以及「如果譜一句話,會不會直接做端事,才是上線前 要骄證的尚题。[4] 所以,比较正常的结输是:XAI很適合把一個電括Agent的想法快速成能测的柬西:但要 把它嬰成真正可靠的電括員工,仍然得把權限、確氢、資料和人工交接一件一件做好。 上線前,成本、資料和風要先講清楚

xAI目前公的 Voice Agent API 計價為音訊每分罐 US$θ.θ5(US 3/小時);另有每则純文字翰入事件USo.684的計费。電話號码、SIP、工具搜辱实 存等周遗成本,請以當日產品與供愿商真面為。[9] 這代表你不鹰只同“每分鐘多少钱;,也應問:

• 每通平均频分键?

• 多少通真的被AI解決,而不是鳞一面再轉人工?

• 工具搜导舆资料存取的确外成本是多少?

• 减少的是哪一段人工時間?

资料怎魔虑理 電話裡常會出现姓名、地址、訂單、帐務、医或投新等敏感内容。上線前先把遗件事問清 楚:

• 是否要告知来電者正在與AI互勤,是否音:

• 逐字穆、音與摘要保留多久、雄可以看;

因資與付款資讯能否进入模型或外部工具;

• 是否有地區、率垩或公司内部的资料合规要求:

• 真人转接时如何最小化不必要的資料暴露。

要真的動手做事,就多問一次 只要Agent 要造成外部改燮—下單、退款、改地址、预的、發讯息、取消服務—都鹿遵守道 個规则: 先回請關键資料,再等待明確確,最後才調用离入型工具。 这不是保守,是電話介面該有的基本安全設計。人會口误,ASR錯,模型也可能理释錯; 多一因確提步醒,就是把结误擅在真正動作之前。 寫在最後 xAIVo1ce Agent值得朋注,不只是因為 AI暨音更像人,而是它把原本分散的事情放到同

一因流程理:電話入口、即時語音、推理、工具和通括記錄,可以一起處理。​

如果你有明確、重複、可验银的電活工作,例如客服FAQ、预的、線索初部或售後通知,现在 很值得做一個小范图试站。 但真正成熟的VoiceAgent,不是「永遗不转人工:的Agent;而是能快速處理該滤理的事 情、知道何時停下、把完整上下文交给真人,亚且镶每一次失都能被看見與修正的Agent。 資料来源與延伸朗讀

1. xAI, https://x.ai/news/grok-voice-agent-builder​

2. xAI Docs, [SIP Phone Calls]​

https://docs.x.ai/developers/model -capabilities/audio/voice- agent/sip

3. xAI Docs, [Voice Agent API]​

https://docs.x.ai/developers/model -capabilities/audio/voice- agent

4. eesel AI, [Grok Voice Agent Builder review: is xAI's voice​

AI worth it?] https://www.eesel.ai/blog/grok-voice-agent-builder-review

5. xAI Docs, [Ephemeral Tokens]​

https://docs x.ai/developers/model- capabilities/audio/ephemeral-tokens

6. xAI, [Grok Voice Think Fast 1.0]​

https://x.ai/news/grok-voice-think-fast -1

7. Twilio, [Build an AI Buddy with Go, OpenAI, Retell AI, and​

Twilio Programmable Voice] https://www. twilio.com/en-us/blog/build -ai-buddy-go-openai- retellai-twilio-programmable-voice

8. Artificial Analysis, [Announcing the Speech to Speech​

Index] https://artificialanalysis,ai/articles/announcing-the- artificial -analysis-speech-to-speech-index

9. xAI Docs, [Voice Agent API pricing and​

limits https: //docs.x.ai/developers/models/voice-agent-api

原始排版图​

发布于 2026-07-08 21:15:47（微信公众号导出记录）。

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

原文链接：查看原文

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

正文（本地 OCR 转写）​

original wex7ce EI V1ajero 2026年7月8日 21:16 M土 2026年7月。安全研究員Hyunwoo Kim(@v4bel)公披露了 Januscape,漏洞编领為 CVE-2826 -53359,

intel. AMDA

Januscape

这是一影善 L1nuX KVM/x86 的虚凝化隔漏润,核心虑随出现在 KVM shadow MMU 對 shadow page 的框用谨中。公專 V4bel/Januscape 提供了可宿主機溃的 PoC 專案地址: https://github. com/V4bel/Januscape 研究者表示,完整guest-to-host escape 在受控瑞境中可實现,但完整利用程式码亚末公删。 公 PoC 主要展示的是微 guest 像婚替 host kernel panic 的 DoS 路得.

一句括概括:​

版 KVM 在用 shadow page 只比鞭 gfn,没有比较rale。攻繁者可以在 nested virtualization 增景中截造同一個 gfn、不同role的 shadow pege ,舒辱 KVM 錯娱拖用,最终硬瑰rmap 起限效解 use-after-free.

1.漏洞定位​

Januscape 不是QEMU 便用看漏词,也不是 Proxmox 或 OpenStack 控制面漏润L 它位於 Linux kernel KVM xB6 MMU 理式疆中,主要涉及: arch/x86/kvm/mu/mnu c 复制 受影馨的是使用 Linux KVM的 x86 塞主機,包括 Intel VMX/EPT 與 AMD SVM/NPT 環境。 风缴最高的場景包括:

• x86 Linux KVN 宿主膜:

• 多租乒或不可信quest;

• guest 暴累 nested virtualization:

• guest 内攻者可取得root 或可入 kernel module;

• 或主概本地续用者可存取/cev/kvn。

Januscape 只針對 xB6 KVML arm64 不受 CVE 影据,但 @v4bel 此前披露的 ITScape / CVE-2826-46316 是另—個 KVM/arm64 guest-to-host escape, 需要强虑理, ITScape 再炎: https://github. com/V4bel/ITScape

2.相關研究派絡​

Januscape 丽於 HyunwooKin(@v4bel)近期 Linux kernel高值值攻墅面研究的一部分。 同一系列中還包括:

• Dirty Frag: Linux 本地提標端润辑,主要面向 LPE.

• ITScape / CVE-2626-46316: KVM/arm64 guest-to-host escape,

• Januscape / CVE-2026-53359: KVM/x86 guest-to-host escape, 窖 Intel

AMDxB6 KVM 增景。 V4bel G Anyway this wraps up my cute tux series. The face is especially funny. isn't it?lol Dirty Frag: Universal Linux LPE

• Januscape: The first Guest-to-Host Escape in KVM/x86 && Google

kvmCTF O-day exploit

ITScape Dirty Frag Januscape 出人工智量(A)生会 上午12:03·2026年7月7日·1.787文查看

三者不是同一回漏润。但都图编 Linux kernel 高风险攻黎面展限​

Dtity Frag LInux LPE KVM/a/ms @vibel / Hyur rTScape Guest-to-host escape KVM/x86 Intel VMX + AMO SVM

Dirty Frag 專系: https://github.con/v4bel/dirtyfrag

Dirty Frag

3.個關鍵概念​

3.1GFN是什​

gfn 是 Guest Frane Number,也就是 guest 物理真然。 GFN = GPA >> 12 复制 其中 GPA 是 Guest PhysicalAddress.可以肇理解為: GPA:guest 為的物理地址 GFN:guest 物理记境中的策照票 复制 例如: GPA = 8x12345886 CCZ[x6 = NH5 复制 KVN 舍用gfn 曾理 guest 记增智映射、menslot、rnap 和 shadow page 之間的酮係, 所以gfn回著的是: 速是quest 物冠记慷暗径的一真? 复制

3.2Role是什​

role是KVM 給 shadow page 記绿的語囊调讯。它摧述遗一真 shadow page 目前扮演什 角色1 创如:

• 是 direct page 董是 1ndirect page;

• 的硬一级页表:

• 封愿什座存取權限;

• 是否服尬 nested EPT/NPT;

是否束白 huge page 拆分;

• 属铃殖 MMU context。

Januscape 中最调健的是role.direct: direct =1:直胰射或拆分 huge page 使用 direct -0: shadou guest 控制的页表页 复制 可以遗标理解: gfn表示“是一页」 rale表示“速页硬KVM成什鹿用: 复制 这雨個噪位必须同時匹配,shadowpage才能安全拖用。

4.ShadowMMU為什會参與​

答通虚提链地址标独大致是: Guest Virtual Address

• > fuest Page Tahle

Guest Physical Address LdN/Ld3 <- Host Physical Address 复制 InteL 的二脑段地址梅换叫 EPT,AMD 叫 NPT。现代 CPU 提供硬體助。所以普通VM 增景 下,很多路径不需要傅统 shadow pag1ng. 但 nested virtual1zation 鲁改盛速国情况 LB:真置宿主截,执行KVM L1: 攻量者控制的 guest L2: L1 内部破勤的底套 guest 复制 L1 作為虚化宿主:言為L2 精造自己的 EPT/NPT。LBKVM 需要把 L1 提供的碳套页 L0 Host Linux KVM L1 Giuest Attacker-controlled VM L2 Nested Guest L1 buflds EPT/NPT for LZ L0 KVM shadows nested EPT/NPT Shadow MMU vulnerable path 表聘换成自己可积行的结,请會进人 KVM shadow MMU路径 Januscape 正是针 nested virtualization 下的 shadow MMU 感理温辑

5.根因:只比较gfn,没有比较role​

漏润核心可以整缩成一句括: 崔KWM 在福用 child shadou page 时,只检查 gfn 是否相同,没有检查 role 是否相员L 复制 周题在龄:同一個gfn 可能在不同路径下需要不同 role 的 shadow page. 例如: 同 gfn 6 路握 B: 需要 di rect=o 的 shadov page 复制 要逗相看到gfn相同,就為可以袍用,但實除上它們悟希不同。不能袍用。 正确退辑原旅是: chi1d->gfn gfn 亚且 chiLd->role,word 复制 修復捕丁正是增加了role比较。

Januscape 的键就是该售通期在gfn 匹配後提的慎用,忽路了rale差。

6.Directpage奥indirectpage的差​

6.1 Direct page​

4KB entry. 这情况下。KVM 可以娘性計算每图entry 對愿的 gfn: entry_gfn = sp->gfn + index 复制

6.2 Indirect page​

indirect page 用束 shadow guest 控制的页表页。每個 entry 指向哪图 gfn,要看 guest 页表内容,不能量用sp-gt:gfn+index推薄。 所以雨者的核心差晃是: direct page: indirect page: gfn由 guest 真表内容次定 复制 如果KVM把 direct page 错误用到indirect 場景,後安装和量除映射時就可能使用雨套 不同的 gfn 源辑。 这正是rmap 损壤的前提。

7.rmap為什會損壤​

KVN 使用 rmap.也就是 reverse mapping,記操: 某留 gfn 被娜些 shadow page table entry 陕射 复制 正常流程是: 安 SPTE -> 加入 rmap[gfn 0] 复制 漏润解發後言成: 安装時:按 indirect 强记到rmep[gfn 0] 删除時:技 di.rect 巡辑针算成 gfn X,再去mapgfn X]删陆 复制 能果是: rnaplgfn Q] 中硬留了医 SPTE 捕标 但速倡 SPTE 所在 shadow page 之德可能已提轻殖 复制 道就形成 stale pointer。後KVM 再匿rmap 時,可能存取已释放的 shadow page,產 生 use-after-free. KVM Addl SPTE. to rma gfn Q] ve SPTE

• gfn X

ap[gfn X] rmao[gfn Q] stl c ip[efn Q] stal c Shati pege freed Stale polnter to freed page Stale p KVM 公众 EIVlajero Fage 公PoC主要利用條路幅壁KVH瓷科结磺一致性检查失致,最终填致host panic.

8.Januscape專案程式碼做了什​

Januscape 專案地址: https://github. con//4bel/Januscape 專案结精很小: REAOPEnd Makefile poc.c assets/write 复制 核心榴案是por.c,它是一 Linux kernel module PoC, 程式碼主要做四件事。

8.1造嵌套虚凝化環境​

PoC 在 L1 guest 内部直接使用vMIX/SVM 拾令一国小的 L2 guest。 專案同时支援: Intel wx/EPT AMD SVM/NPT 复制 程式碼中适通一層virt_ap5抽象,把Intel和AMD 的差冕封装起来。遭说明漏润本身不是某 CPU 廠商單藏的周盟,而是 KVM xB6共用 shadow MMU 遥辑的周题。

8.2造特殊真表布局​

PoC 精造特殊的 nested EPT/NPT 真表。爆同一 guest physical page 在不同特脚贴既像 huge page, 又像 page table page, 这一步的目标是製造: uy6 图 不同role 复制 也就是漏润斓發所需的圆健修件。

8.3多執行打競態​

PoC理有雨频核心鞅行: writer 较行铺: 不继切换基倍 PDE 的 hugc/table 肽辖 faulter 轨行: 反覆铁行 L2, 聚宿主機 KVM 温入 shadou MU fault 路得 复制 这不是普通意上的多积行储加速」,而是为了摘大就参窗口,KVM更容易在错误時间黏用错 role 的 shadow page. faulter threads Toggle PDE Run L2 guest repeatedly Trieger nested EPT/NPT table page entry Fuqua a8ed a8nj fault oed mopeys (2aup eed mopeys 02evp Enter LO KVM shadow MWU Same gfn, different role Old KV may g

8.4筋發宿主機KVM崩潢​

如果目標宿主碳末修復,KVH 可能探拖用 shadow page,最终在pte_Llst_renove等路得解 髮 kernel BUG, 公需效果是: guest 内缺行 PoC -> host KVM panic / Do5 复制 这不是 Windows 程式,也不是苦通 C康用,它需要在 Linux guest 中缤耀成kernel moduLe,且目標宿主機需要满足漏润解發修件。 本文不展開PoC的转行步霖,故程式碼會影暨富主概稳定性,不愿在未授環境中韩行。

9.漏洞路完整梳理​

Januscape 的错疑可以概括為:

公用PoC最能打到的是Do5 路理。完整guest-to-host rnot expleit 需要把 UAF 原细造一步聊化定的 雾主燥 kernel 控材,值部分浸有公限。 10,可以達到什效果 公测惠案可以还到的主要效果是: 炭 guest 内部瓣禁主模KvM 奥清 复制

• 常前攻整者所在VM期潢或失联:

• 同一宿主機上的其他VM受影;

• 宿主提震要重放恢復;

• 需平台計算前贴可能被拉下续:

• 如渠存在完整利用,理输上可遗成guest-to-host escape。

公 PoC 是 host panic 路径,不是完整公微的 host root explo1t.

11.受影響图​

受影警的是 Linux KVM x86 host,重黏包括:

• Proxmox VE:

• OpenStack compute 航贴;

• libvirt/QEMU + KVK 宿主機;

• 自建要平台:

• 白建雾平台:

• 多租户虚凝化平台;

• 胃 nested virtualization 的 KVM 環境;

• /dev/kn

到本地使用者鼠放的 Linux 何服器。 不屏龄Januscape 主费影誓图:

• W1ndows 本;

,不使用KVM的虚提化早台;

• 未露KVM的着通Linux伺服器;

• arm64 KVM 的胶 CVE 路镯。

上游 stable 修覆版本包括:

5.18.268​

5.15.211​

6.1.177​

6.6.144​

6.12.95​

6.18.38​

7.1.3​

7.2-rc1 及之德​

复制 主综修瘦提交: 81ccda38b4e83d8f5cc4fd5503c44e3a33abfeb 复制 生竭境不要只看uane·r,發行版握常backport 安全復,德以 vendor security advisory 和 kernel changelog 為军。

12.如何判自己是否暴露​

在宿主楼上重检查三件事。

12.1是否使用KVM​

Ax, daub | pcus1 复制 如果存在: kvnI kvn_and 复制 就明KVM 模组正在最入。

12.2 nestedvirtualization是否開​

Intel: Cat /sys/module/kvn_intel/parameters/mested 复制 AMD: Cat /sys/nodule/kvn_and/paraneters/nested 复制 如果结果是Y或1,说明宿主燥模組面允許nestedvirtualization 退需要橡查guest是否真的能看到vix或svn: grep wE vnx|svm /proc/cpuinfo 复制

12.3/dev/kvm權限​

1s -1 /dev/kvm 复制 如果普通使用者或非必要使用者组可存取,需要重新评估暴露面。對於不轨行虚凝概的伺服器, /dev/kvn通常没有必要。

13.防護建​

13.1升級宿主機内核​

根本修海是升级host kernel,亚重放速入已修衔版本。 注意: 修的是宿土機内核 不是gucst内核 不是单揭升级QENU 复制 如果使用11vepatch,也感腿CVE-2826-53359及相成配塞修復都已生效。

13.2 限制 nested virtualization​

如果移不乘要nested virtual1zatian,唐避免向不可信guest 暴露vnx或svn. OpenStack 環境薇要榜查:

• flavor extra specs;

• inage metadata;

• host aggregate:

• 11bvirt CPU mode;

• 是否使用host-passthrough.

Proxmox/Libvirt 嬰境需要检查 VM CPU fLags,通免無意幂霸 nestedvirt 能力。

13.3收紧/dev/kvm​

如果何服器不执行虚授确,可以考露:

• 卸显KVH 核组;

• 阻止KVM模组自动联入;

• 限制/dev/kvn存取概限

对於共享主機,道一贴尤其重要。

13.4监控翼常日​

重黏酮注宿主慶日禁中的關建词: gfn mistatch under direct page pte_11st_renove KVH_BUS_ON_DATA_CORRUPTION kernel BUG at arch/x86/kvn/rmu/rnu,c qenu-kve panc 复制 這些資訊可能意味著KVMshadowMMU路出現翼常。

14.總結​

Januscape的關鍵不在PoC本身,而在它暴露了KVMshadowMMU中一個基假設錯: gfn 相同,不代表 shadow page 可以用。 只有gfn和role都相同,複用才是安全的。 复制 攻撃者透過nestedvirtualization横造同gfn、不同role的真表狀態,再利用競態 KVM误複用shadowpage,最終破壤rmap記帐亚發use-after-free。 對防守方來,處理優先級很清晰: 盤點KVM宿主機 確nestedvirtualization暴露圍 升級宿主機内核 限制不可信guest的VMX/SVM 機查/dev/kvm權限 监控KVM巽常日 复制 如果環境中存在多租户KVM、開放nestedvirtualization、使用者可自訂guestkernel, Januscape應按高優先級處理。 参考資料 V4bel/Januscape: https://github.com/V4bel/Januscape V4bel/ITScape: https://github.com/V4bel/ITScape V4bel/dirtyfrag: https://github.com/v4bel/dirtyfrag NVD CVE-2026-53359: https://nvd.nist.gov/vuln/detail/CVE-2026-53359 oss-security Januscape disclosure: https://www.openwall.com/lists/oss-security/2026/07/06/7 Debian Security Tracker CVE-2026-53359: https://security-tracker.debian.org/tracker/CVE-2026-53359 LWN stable kernel announcement: https://lwn.net/Articles/1081230/

原始排版图​

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

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

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

原文链接：查看原文

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

正文（本地 OCR 转写）​

應該怎看 最近,Tata Electronics 相的期路安全事件引起了很多開注。原因不只是一家大公司被 :,而是遭家公司庭在電子裂造、半博體、手機與率用零部件供愿随的交叉黏上。當一個供愿随前贴 出现瓷料外浪驾和时,狼影喜的可能不是單一公司,而是一签张客户、供感商、製造综、测试流程和工 程资料成的终。

Mres

128.408​

这也是為什磨WorldLeaks这题真面不能用普通八卦的方式看。真正被看的,不是「有没有 料:,而是四個同题:

1.页面到底整稿了什度?​

2.文件清單题示了什度资科结横?​

3.哪些公司或品牌只是路命中,硬些更像供庭经關?​

4.如果这些资料履實,它對最造安全和供愿键安全意味茗什度?​

本文誉献把这件事拆開舰

一、先看WorldLeaks真面:它是線索,不是結​

截画中的页面睡示,Tata Electronics被标记高PubLished,右俐Starage 区域列出:

• 报模:630.4CB

• 文件数:284,341files

• 文件清量:List of files.txt

• 根目龄:TATAELECTRONICS.CO.IN

• 下级共享匾:TELSRVQAFILE、TEPSHRFILENPIA1、TEPSNPIFILE、TSATFS01

遗些信息航明,真面整稻存在一批阀Tata ELectronics 相照的大型文件集合,而且它看起来不是 量個墅缩包或差张证图,而是企文件共享區的索引。 但运理要先清遍界: ,看到PubLished,不等的所有文件智被外界完整验照。

• 看到639.4GB,不等於每图文件都有高敏感度。

• 看到Apple或Tesla名税,不等於可以直接航「雨家公司被入慢:。

• 看到文件清單,不等於可以合法、安全或负责任地下最和畅發原始资料。

公需尊程。Tata Electronics碟的是错生退網路安全事件;,管通未受影警:World Leaks 则暨稀發布了大量文件。適两者不是同一個唇级,必须分開寒。

二、怎看WorLdLeaks這類真面​

看这种页面時,不要先接公司名和容量需走。正確顺序是:先看页面结精,再看文件结,最後看风险 禁。

1.看页面聲​

真面通常會绘出公司、围家、状、大小、文性数和目综。這些是攻聚者或泄露站的驾程,只能作為 凰险综索。 最重要的不是页面前了什度婷强福显,而是它是否有清晰的企域名、共享盤、部門、日甄、系统名和 文件類型。这些结性信息比宣博括更有债值

2.看文件清單,不看奇様本​

Listoffiles.txt这種文件清量,本質上是索引l。它通常不直接告你文件内容,但能告你资 料可能来自哪理、属於什磨繁務流程、涉及赚些系统和部門。

/1 LafI Ipl/n hs p3%_0%0 etharstt 5T0R 9FT F064 6 (9)

對安全分析来说,索引比强越国更重要,截图容易被挑逻、裁切或损游:大量路结更能反映资料 面。

3.看證據遗界​

谨的表述愿故是: 「文件清單题示,路径中出现了某些公司、產品、系統和裂造流程相圆名稿。 不服谨的表述是: 「某某公司所有核心糖密都已外油。」 前者是基於索引的判,後者是没有完整取證支持的结输。

三、List of files.txt 裡到底有哪些文件​

本地清單共诵到284。341修非空路径。全部唯一。副榴名、文件名和目錄名看,它是一恒装造企 繁共享整级别的混合象引。 主要文件频型可以分成六類: 代表格式或照字 可能含费

• JPg

图片與视景 ADI、外器核测、工站置片、失 .tif、.av1、

• png 、

• hip、

VITRO 桂测澳科 收爆本、品质照片 x、OCR。 DCV、 X51x* 品觉辑告、核表、迪跌表、供 表格报告 商资料、工程文榴 .CSV、

• pdt

txt 利试验出、工站記缘、失败日 潮试兴工站 leg 。

• Json、

ART、 日第 懿、设循肽患

1、 Burn-in 、FCT 、 PDCA​

set 装程/治具/ 治具、量测、模台程序、工程圆 .chd 、

• stp、

.dxf、 操台資料 抵、囊程设定 Fixture 、 CPK、 Hotion .dll 收疆工具 利试工具、内部廉用、第三方套 .exe、ms1 、 .zip、 ab、

• 1a

包 件、本、台软體 、vsix、js、lua、.cs.

• h

资料康、企案系能配置、退或 资料座奥配 1n1、plist、pl2、 5S6、 置独路 wallet 嫌案,凰随校高 ig 、Mallet 這種组合很奥型:它不像單继群公资料,也不像單纳原始碼盒座,而是湿合了显造现域、品置、短情、 测式、供愿继和IT系统狼踪、

四、都有哪些家公司或品牌線索​

下面是基於路福和文件名的字统計。注意,理的相期,只代表路命中或供应经境综索,不 代表族公司被入侵,也不代表文件内容已被官方确超。 命中数 判 确中 公司/品牌/螺键字 Tata / TATAELECTR 264,341 所有路得都在 Tata Electronics 企案域名结下 ONICS AOI、祝景植测、影像資料哲境非营集中 13, 624 的14,33 Microsoft / Windo Windows、Microsoft 套件、用卢配置、系绒疫略 ws SAP / SAPgui 266*e 全菊系航、SAP GUI、流程瓷料 公教链或工具包 Libreoffice 2,816 PDF 工具或数耀娠填 1,542 的1,15 Apple 显式 AppleInternal, iPhone、 i0S, Mac, iSight 等 oracle DataAccess, cuallet.sso . cuallet.pl

7.9​

oraclc / vallet 2等高图游配置察 Pegatron 382 供癌键或敷耀元件盐境 重载、设循、盈娘、TLA、GLovebox,VCUSB,HVAC 等 Tesla 371 語境 279 元件或供應商理格文件螺索 Cyntec 235 Siencns / NX CAD、工程蚊疆、相械設针锤境 190 166 需要上下文復核 bunsue5 设借、视震、治具插境 111 Hyvision 1100 Dell 工具或 Windows 超情疆境 53 供應键或授術罗键字螺索,需硬核 QuaLcomn 44 供睡名字家,不能等同龄被人量 Foxconn / Hon Hai 49 Intel 多半可能是平台或数需圾境 14 元件供感商综系 Molex TE Connectivity 元件供顾商霜 3 其中最值得注的不是答通收品牌,而是SAP、OracLe/waLLet、VITROX、Pegatron TesLa、Apple道些出现在转造、品置,設情或供愿键范境中的名字。 Yagec. Cyntec、

五、AppLe相關應該怎看​

Apple 相闻不能混成一坨看。它至少分成雨層:式Apple 词,以及大量装迹/產品/專案代然。

1.式 Apple 词​

清單理式Apple 相倒的1,155條: 信然 判 文件名或露得中直接出现 Apple 513 Apple AppLe 境,常见绘潮腻、白動化或内部工具命名 AppleInternal 882 需要强核。可能是AppLe Mac,也可能是蓄通时 174 Hac isight 可能指Apple相關命名,也可能是康用或设偏名 48 23 明 Apple 生男制 i05 明斑 Apple 叠显 iPad 明脏 Applc 產品 道些路径主要集中在:

• TE - PDCA

• DRT FA

• TE - MLB

• FATP-DQC

lua、n 文件频型制包括 xL、.csv、.pdr 、plist、log、xnl.明腰式 Apple 润更多出现在测试都本、硬耀测试、工站配缝、品質瓷科和配置部境中。

2.大量產品/專案代號​

除了期式Apple 阔,清單理运有一組大量出现的代號:

630.4 GB 204,341fles - List olfles.txt​

t AL Data TATAELECIRONICS.CO.IN TELSRVQAFILE TEPSNPIFILE =D E ORT FA Backhpfle FA&ORIOCT Leo Daily Tracker Leo Macmini Data Leo Radiography Data Leo Repcrts • 2026 Lco VHXimage RCAM Validation Reports Schematle 55 Audit Checklit (l.xlax 38 ORT RCAM Irspectin Trackemxlsx 2TARB TSATFS01

2,3 FE 4名 1M 17,18

PU Llod

SYL8N 1,090 ,780 92 判 代甄 代號 命中数 大量影通、品簧、供康硬资科中的概心代號 大量製造、品質、供應資料中的核心代號 Leo 30,661 10,247 V53 FATP、fixture、motion、GRR/CPK、品質資料中大量出现 6SA LYSA 5,093 常见於AOI、SMT、CG/BGTOP/BOT類路 3,569 工站、序號、測試資料命名中常见 J85 Astro 1, 671 Burn-in、測試自動化、AppleInternal上下文中出现 SFIS、FATP/OQC或應用命名中出现 Tigris 898 這组代號合計約 47,404條路,是整份清單理最核心的一批資料。

六、TesLa相關應該怎看​

Tesla相關線索約371條,而且非常集中:全部落在TSATFSθ1/E根下。

630.4 GB - 204,341 files - List offiles.txt​

D E TSATFS01 E Equipment Data FC Equip ISP TEAM Material planning TDG testing TSAT-IT Cover 24-02-2025 Licensed Softwares Moldex 3D program software SAP SSO Setup Solid works license code Standard Softwares 3DEXP_Mkt_SW_6.32.4026.exe 2.4 MB Digitl Sign.zip 1.7 MB SAP SSO Setup.zip 20.6 M8 TSATFS TSAT DCC TSAT PROGRAM 主要信號包括: 信號 命中数 判 286 HVAC 車載空調、設備或產線語境 253 Tesla 式Tesla 244 VCUSB 車載模组、設備或產線語境,需要上下文判 TLA Details TESLA 239 式Tesla+ TLA區域 Glovebox 182 車部件或產線語境 P1771993 具體料號或產品號語境 73 SGVM 9 序號或项目命名語境 分布上,Tesla相關主要在:

• TSATFS01/E/Equipment Data

• TSATFS01/E/ISP TEAM

• TSATFSo1/E/Material planning

文件類型则以.xlsx、.csv、.pdf、.bmp、.docx/.doc為主,少量出現CAD或機械国纸 格式。這更像設備、物料、車载部件、產線工程資料,而不是普通市場資料。

七、為什這不是普通泄露,而是供應風​

梨造供應键資料的危险,往往不在某一個單獨文件,而在於它們能被拼起来。 如果一批资料同時包含:

• 客户或產品代號

• 供應商名

• 工站和測試流程

• 检測国片和失败様本

• 品質報告和稽核資料

• CAD、BOM、料號或工程圖

• 企業系统配置和證痕

• 員工、部門、圈隧和共享盤名

那磨攻者不一定需要攻進Apple或Tesla本身,也可以供應商資料裡理解它們的製造網絡、

零部件關係、品質流程和内部命名方式。​

這就是供應键安全最麻的地方:強公司的風险遗界,常常延伸到它最弱的合作點。

原始排版图​

发布于 2026-07-03 19:21:12（微信公众号导出记录）。

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

原文链接：查看原文

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

正文（本地 OCR 转写）​

本退Kickstarter硬體觀察:AI眼镜、AIKVM與户外機器 人正在重寫產品遥辑 inalwθ×7ce EI V1ajero2026年7月3日 19:21 泰国 適一通的Kickstarter很有意思:真正值得看的,不是又多了圆AI棵,而是一些硬避霉案開始把 AI、榜器人、低雄播经計放游真言流程班。AI眼镜不再只想拍癌世界,而是管试把資放回视接:AIKVN 不再停留在教错白和化,而是碰到真實氧:户外碰器人也不再只是酪炫demo,而是在接管割草遗箱明、 重福、麻烦的家庭任称。 这其實是一国很重要的套品讯號:硬错剧新正在「做一僵新入口蚂向「重宽一段要流程,使用者不一定 需要更多荧幕、更多App、更多提醒;他們更丽意為少一次接線、少一次充電、少一次割草、少一次低眼看 手情付费。 所以造篇不做解榜揚通,也不把28專案堪成清單,本遇我逛了10困更通合至品经理细看的科技硬整票 案,不只看它钙票了多少罐,也看它竹如何定差問题,如何想针功能,青德可能需要什磨技折架精,以及如果 要做似座品,可以提哪些案原男累具研發路径切入。 每個厚案邮配三張,方便你快速理立上下文:

第一张是Kicktraq熟度追录,用来看幂资前费、支持者密度院超势。​

第二张是Kickstarter原始霉案真首屏,用来看圈媒如何定裁品、如何打第一提画點。​

第三张是Kickstarter專案页開键资科数,用来看功能表莲、场景输键或品细前。​

造10国專案跨AI影示限院,無综影音外设、模组化键,睡民干预設靠、掌上Linux電驱、AI KVM、電子工程教育套件、太陽能智慧镇、F外模器人與智慰健身设候,它傅不一定都會成功,但都提供了很 好的品拆解桥本、

01.MemoMindOne:無摄影機AI示眼镜,把私​

界變成產品策略

MemoMind One: The Most Natural AI Display 055:06:03 Glasses! STATUS:ACTVE HKS4.572713 5715% HK$46,489,249 58,11k%6

IIGNSTARTER MemoMind One:The Most Natural AIDisplay Glasses! ¥93,979,005 @ MemoMind One 1,234 The Most Natural Al Display Glc 55 NER

El Viaje

MeroMind Dne 是一副AI翻示跟照。它最值得看的不是“又一副AI眼频;。而是它刻意避期了智慧眼 频最敏感的功能: 摄影接。霉案页把 No Camera, Privacy First,Dual Micro-LED Display、AI Recorder,AI TransLator、AI Teleprompter 放在同一数事楼。圣品遗界微清是:它不是氧你招世 界,而是把必要资訊放到视螺程。 這取控微额键。智慧眼速去最大的阳力之一,不是技逝不狗能,而是公共場景祖的信任成本,只要脸上有 提影棍,使用者自己要承握社交医力,周的人也會塞生被拍摄的不安。MenoHind0ne把提影榜拿捧,等 於肥品可疑的起器检,重新拉回「私人调讯题示理情 功能上,它愿的是装四高频工作場景:害满记绿、即時翻课、演请提、AI摘囊、通知提示與路音内容 助。道些功能單揭看,手榜、耳榜、绿合策、副露ApP都能做;频的差界在龄互勤成本。快用者不必低 颈、不必切App、不必把注意力對括中抽定,資组能在更接近自然视镰的位置出现。 严品经理斐看的核心不是AI模型参数,而是佩薇疑路。重量、鼻托整力、镜腿發熟、户外亮度、增献、處 方编速配、最示延速、語音收音、赚私提示。任何一短板郁害它炭「每天数:退网「偶期试。可穿爱 糖的瞬典,往往不是功能上照,而是身耀能不能岳期接受。 我的判断是:MemoMindOne的方向成立,国杂它据智眼键的案品重监「我能多借什磨:改成我能少 打漫你什限;。適是一钢更成烈的可穿品思路。 研發路径既源生账必考 如果圆除想低须似的期损影AI显示眼,不建一开始就把整光機、镜果、AIOS、語音触路全部白 研,更合理的HVP路径,是先把手機端AI-眼镜端期示+踏音输入跑通:眼鳞端负震任功耗翻 示、盈牙音訊具基本控利,手模或善端负贰ASR、翻环、摘要與提罚,先验适使用坛景是否成立。 開源参考可以看這国方向: Mcntra Open Sourcc Snart 6lasses: https://github.con/Mentra- Community/0penSourceSmartGlasses Mentra05: https://github. con/Mcentra-Conmunity/Mentra0S 它們展示了暂慧眼编如何承 Live captions、AI assistant,搜号奥感用框”。另一图可参考方向 是: openGlass: https://github.com/BasedHardware/0penGlass OpenGLass偶提影/感知题,但能离圈理解低成本眼镜原型、手機临同奥AI工作流。 底唇硬辑上,真正摊的是示模组、光攀病合、重量控制规细航,而不是App。建善研登拆成四條缓: Micro-LED/波尊或近眼示遥型、暨麦克属网降噪触路、手模conpanionapp、低功耗错。產星早期 不要追求完整AR,而是先把字基、翻露、提、會摘要谊四图高值值塌景做。 男案速结: K1ckstarter: https://w.kickstarter. com/projects/1963472698/menonind-one-the- sassee-edstp-te-tenteu-asou Kicktraq: https://kicktroq.con/projects/1963472698/nemomind-one-the-most - natural -ai-display-glasses/

02.MouseArc:無線HDMI的重點不是無線,而是把臨​

時接線變成低摩擦流程

MouseArc: Plug & Play Wirele ss HD 028:23:23 Transmitter and Receiver HK$65517 STATUS: ACTIVE 81836

12.69k%6​

CIGKSTARTER MouseArc: Plug & Play Wireless HD Transmitter and Recelver uaplg8nu I tumunu, opny g cepA,sanm I Aqeis sDung-Buon | uag agend I 2Hoe1i(idosD Corpih ty IBat-n50-WHTtoW F030 npsbity 10uit-n5G-wn11 tscw FC30 ¥1,346,401@ MOUSEARC HD Wireless 107 28 国 θ S B

P MouseArc: Plug & Play Wireless HD Transmltter and Receiver 105cpg20H IPuzde Design I Lang-Rang Slablly I Wiskss Vieo & Audio Transmit | Ful1 Sysoe Compatisility T Buil-in5G-MF1I 100W PD3.0 107 28 ¥1,346,401 已减e 08n8?14,433) 天 misie 專案美不保理觉现目 只有在專客在宣传活 起人民支持智速技: P ,但母起人惠密理 数截止时用之的理成 款目桥设,你才容 常国支持者清酒。 被扫收。 MouseArc 是一组即择即用的细端亮清影音收器,表面上看,它是 Wireless Ho Transnitter and Receiver:品上真正要解决的,是會端室、集面、遵威、整時震示理很熄但很常见的一组摩握:HDMI综 不购長、聘接頭不匹配、苹電按口不购、投影前道要找線,或是桌面被综材拖得很赢。 事案真的核心功能點包括1088Pg128Hz、狼影音需输、长距解定性,Ful1System Compatib1Lity、内键 56 W1-F1,以及16oW PD供電,造择量情得拆的是「影音罐路+供氧链路: 的合供。如果它只是一钢氟螺投屏爵,奢被拿去跟廉惯HDMIDongLe比:如果它能司肠密理影像,音計、 供罩则跑经相客,就更接近一圆柜量化想搞充底座。 这频產品的第一性同随是可垂性。使用老不會因為它思廉就原延逻、断接、里面整、音重不同步或速据失 股。尤其在會和展示增景,勇一次失胶就足以既產品失去信任。它的慰睡基率不是“比酪:,而是「比嫌 省心 PM需要解注機但验退贴:不同氧電民主模的相容性、2.4G/5G干操環境下的福定性、穿释能力、延通 表现,發然,供電握手、重新理臻還度,以及多人共享設需時的切摘流程,造些细前比檬桐延耀更重要。 MouseArc的圣品概會在於。它把一医低频但明殖的痛监效成了可携硬耀,如集它能做到排上即用,延遇可 接受,跨設需稳定,那它寶的不是「無缘影像」,而是少带一堆续,少一次會前的想施。 研發路握员既源生感必考 频似NouscArc的童品,庄其實是影像探集、编碍、低延湿何输、接收据解碍、供运该膜:的组合。硬 错上通常舍在 HDMI/USB-C 影像除人、UVC/CSI 探案、H.264/H.265 硬编、5GHz Wi-F1、PD 接疆控 制之周他取拾。考要做188BP812BHz,延通與定性害比解析度更。 開源软错圈可以参号: go2rtc: https://github.com/AlexxT/go2rtc wcbrtc-streaner: https://github.con/mpromonet/wcbrtc-streamer 它們那能图除理解多来源影像输入、MebRTC/RTSP/浏宽器播放與低廷理率流的工程胃班。若图除要做 HDMI或FPGA 方向,也可以看: hdl -uti1/hdni: https://github. con/hdl -util/hdmi 这图尊案能期助理解HDMI信领生成阅培屠限制。 研盈上建先健蚊硬分原型:第一版用现成 HDHIcapturc+Linux SBC 跑事流,先利延逐、疆率、 去包恢復多路由器環境:第二版再进入票用 5aC或模组方案:第三版才整合PD、外数、敬熟與量產测 试。不要一用始就自研完整嫌施,先用成熟WebRTC/G5treaner/FFmpeg睡路把使用错验测出来。 專速结: K1ckstarter: https://www.kickstarter,com/projects/mousearc/mousearc-gl-puzzLe- style-vireless-transnitter-and-receiver K1cktraq: https://k1cktraq-con/projects/mousearc/mousearc-gl-puzzle-style- wireless-transnitter-and-receiver/

03.KBDcraftSAHA:鍵盤固定配列,走向可組合的桌​

面翰入系統 trag KBDcraft#10 SAHA: The 55% Modular Duo- 028:21:02 Controller Keyboard STATUS:ACTIVE HK$42,766 427% DOE LEVEL HK$66 6628%

CIGNSTARTER KBDcraft #10 SAHA: The S5% Modular Duo-Controller Keyboard Anew peracigm in input. Mocikr by des gr, fvitkess ty defiriion ¥878,858 40 28

KBDcraft #10 SAHA: The 55% Modular Duo- Controller Keyboard clgm ininput, Modular by design, imitless by defintio 40 ¥878,858 @ 28 (+09902* 名史持者 四

申南不保理党现目 專离签不保提现因 tartr将制意量 只有在專在直博活 2 起人民支持者造损: 轻,但起人房富理 数街止时之前速 ,但保起人理富程 酸截止时用之前进成 款目标债:你才窄 为寿实格育。 常调支持者清通。 被扣款; 图稀 SEA 更斯* 械键望市堤已经很成然,输错、聲學、避幅、外股、配列、客聚化套件郁被反覆打磨。KBDcraft SAHA 有意思的地方,是它波有雕填只满「一把更好融的键组,,而是把趣组微成可拆、可组、可延展的输入平台。 SAHA的微国功能胎值得卷:55%主程、模组化结情,變控制器、可提充除入区、可按任移重组的高面形 感。造不是镶使用看在68%,65%,75%配列裡再题一次,而是把输入设循折成更小的功能单元,数字 區、快捷据区、旋钮、巨集区、游赋控制区有槎會破重新振放。 遗育德型的品桌面工作流的分化、套程式、剪影片、3D建模、滋盘、直播控制、文需入、資料分析,對 输入设情的需求差很多。傅统键壁把所有人整在一国固定平面楼;模组化键制期把“工作流,放回中心,旗硬 福跟着任琐定。 產品黑随也很直接。模组化硬错量容易出现展示很自由、日常银麻烦的間题,进接不疆、梗组鐵别是否自 、配置软體是否直景、固件更新是否安全、不同系统下HID表现是否一致、桌面占用是否合理,造些形鲁 决定它是生套力工具,還是只通合拍照的鼎括單品。 SAHA到座品经理的敢發是:成熟品须不是不能前新,而是不能只在密美和参数上卷。當一個品频造入深水 ,更好的切入慰往往是重新計工作流,面不是再适一国小差翼。 研發路径典阅源生患参考 梗组化键盘的研髮重贴不是趣幅和外数,而是“模组微别、熟插拔、键位映制、跨系能HID一致性、配置工 具,道期件事。SAHA如果要把键成输入系统,就必须快用者插上模组後自勤腊别、配置可视化、巨集 可同步、翻键更加不霖置。 開源生慧首速: QMK Firmware: https: //github com/qnk/qnk_finmware ZMK Finmwarc: https: //github,com/znkfirmwarc/znk QNMK 造合有、成熟唐组所大星白定美功能:ZHK 基龄Zephyr RTO5,對低功耗拥额、分错进超列现代置 牙键盤更友好。ZMK官方也强拥使用者配置可以强立铃核心就帽,可透退 GitHub Actions白勤建置, 遗到量盈後的配置管理很有情值。 研發路径上,建先把最小模组系统供出来:主控板+一個可插拔按键横组+一個旋纽/题示梗组,先验置 硬整速接、I2C/SPI/UART展、横组ID、配置保存熨HID输出。等模组路递得定,再膜展外酸、磁 吸然精具桌面教體。造類逐品最怕硬错可玩但致證雅用,配置工具要和键翻本體同等重要。 專案速结: Kickstarter: https://wwr.kickstarter,con/projects/boyu/kbdcraft-18-saha-the-55- nodular-duo-controller-input-dcck Kicktraq: https://kicktroq con/projects/boyu/kbdcraft -18-saha-the-55-modular duo-controller-input -deck/ DUSQ:睡眠硬體「告你睡得差」,走向「誉試介 04. 入睡眠品質 ag DUSQ - The World’'s Only Sleep Regulation 006:05:03 System STATUS: ACTIVE $1,091,450 10,91k% $1,353,398

13.53k%​

KIGNSTARTER ssunds uspmsng hnadrin Non-saoel s p5ur heveus tpter, d8sscts W sndwBunn S1Mllion ¥175,913,211 The orly wesrable 3,874

口 IER DUSQ

背景故事 ANG Hiv leuse 18克 OurAchievements 支特 41% 22% 40% ed 证坐但不需重因格 420 2000+ 7 bed cess Our Actie lses Padints Terad Siap Lab

• 9

2 2 Tant of RBD The D

DUSQ的定位是 Sleep Regulation 5ysten遗圆时比 slecp tracker 更滋进,因為它不只是融测 睡眼。而是看试在睡眠被打断時造行调前。專案真提到的能力包括慰利神经系,慎测睡眠碎片化、用非侵入 式前庭與遂走神握剩激通行干预,用Ap形成资料纯河察随魂。 大多数睡眼盔品停留在纪绿圈:入睡時間、源睡比例、清醒次致、HRV、睡眠分数。造些資料能聚使用者理解 状感,但不一定能改曼状思。DUSQ的圣品野心,是把“量期;往‘期前;推一步,旗感潮器、清算法和颗激 模组形成闭源 功能拆闻看,它至少包含三厦:第一是感潮,判断使用看是否出现睡眼中龄或神提系统波動:第二是判 断,决定什鹰時候需要介入:勇三眉是铁行,适退特定刺激方式誉试降低夜間清配或改善睡眠速填性。这比單 手现起额更袍,也更接近摇遗界。 產品经理在看道類喂目時囊非常冷酯,使用者真正具的不是HRV、递走神、睡跟碎片化道些路,而是 『少醒次、早上更清醒、日間默患更福:。但健质效果不能只靠页面表则故事成立,需要通用人群、禁忌 般明、幽床證搏、长期安全性则合规登明。 DUSQ是一個值得融察的方向,但它的成收不在於寶贴是否新,而在於腿携是否足购硬。健康硬握只要跨到干 预,就不能再用普通消費電子的棵萍请故事。 研验路员附源生感必考 健DU5Q频毫品,研登不能提「刺游签,限始,而要先碰资料则输围始。比校合理的路径是:先效睡眠状 魅监测,建立夜留清醒、心率提露、错融、睡眠速性的调科模型:再级非慢入式刺游原型:量德用小规模使 用者研究验造利激是否真的改善睡据速细性, 開源興公開资料可以分雨频看,睡据分拥购讯號處理可参考: SleepECG: https://github.con/cbrnr/sleepecg SleepECG 显供基龄 ECG 的睡眠陷段分颈工具。调料集可看: /0*e't/x,pa-da01s/uetuoo/buoouotsAud//:sdsu :papuedx3 0a-d01s 4anotsAud 這個资科集包含整夜PSG 记錄、EEG/EOG/EMG與人工棵注hypnogran生理訊签硬错 EEG/EMG/ECG 简聚可参考: OpenBCI: https://github.con/openbc1 但要注意,源專案只能氧你跑通整测與分析;翅路,不能替代腔床睡疆。涉及前庭剩激、送是神到激或 任何影警神提系统的功极,都必须设計禁忌人群、剩激安全上限,具常停止策略,使用者知情是示具合规路 很、这颈齐品的研敬前奏应该是图查级用维,而不是普通穿概拉需的奏。 径。这须產品的研登的类医该是照级思维,而不是普通穿题設懂的类。 票案速结: Kickstarter: https://wwr.kickstarter,com/projects/dusq/dusq-the-worlds -only- sleep-regulation-system Kicktraq: https://kicktraq-com/projects/dusq/dusq-the-worlds-only -sleep- regulation-systen/ RootBoard:把樹莓派開發板,包装成可隨身带走 05. Linux工作機 的 rag RootBoard-The Open Pocket Linux Computer 022:03:28 STATUS: ACTIVE $18,881 377% NT PLED3E LEVEL S65.035 1300%6

LnxConpfer sng 596,005 1300%

KIGKSTARTER RootBoard - The Open Pocket Linux Computer red hencheld Linuoc corrputer vlih a ree key,t cerd, dhipla hardwire. BulL for mskers. ¥3,064,559 140 ROOTBORRD 22

背景故事 ROOTBOARD - The Open Pocket Linux Computer A Rani Integalied dhsplty. 1peeket, asd /ly ceenherdhars. Bul:fer makes dn ac+sokogs sheeld se oper, ymdkerstantiuoke 1819

A Computer You Can Truly Understand

DUSQ - The World's Only Sleep Regulation 006:05:03 System STATUS:ACTIVE $1,091,450 10,91k%

13.53%​

$1,353,398

NIGNSTARTER DUSQ - The World's Only Sleep Regulation System S1Mllon r ¥175,913,211 228 (808*1 3,874

DUSQ

背景故事 DUS0 1CER OurAchievements 40% 22% 41% 支持 Tefemle 龙途图不量要国指 420 2000+ 7bed Atrive Sinp Lab 2 + Cutb 2 Teas o R&D The Problem 网用的图骤

RootBaard 是一台基於 Raspberry PL 的第上Linux 電脂。它把显幕、真實疑强、揭聲器、外颗、授 口购案放硬計整合起来,面向剧客、LinuX便用看、教育增承與现增期试工程的 口與放爱體设计整合起来。面向剧客、Linux使月者、教育場景與现场钢试工程额。 莓派本身很强,但它的原始形感不是可携工作榜,快用者要把它确到现场用,需要自已虚理供電、薰幂,键 架、外设、散熟、培口保理,系统键像类膳需方式、RootBoard做的事情,是惩这些零股决策收敏成一可 購置、可图權、可拿起来工作的產品。 功能上,它的键贴包括 Raspberry Pi-powered、真赏进、掌上示、Linux Ready、Dpen Sourc Hardwarc、可改造结横。對目标使用老来钳,遗些功能比胞分更重要。现增拥试、调路排随、教育 演示、開髮板控利、SSH管理、除审記,郁是比娱操影音更符合它的任場景。 這题產品的雕贴是平衡。掌上電脑太小,微塑试雕用:效大一,又失去便握:性能上去,欧熟和细航里力又 来了。它的PM間翘不是“能不能胞Linux」,而是“能不能在真真任移理比筆電或手操更顺手。 RootBoard 的情信在於,它把用登者工具碰桌面移到口袋裤。这不是大黑市场打法,但對明旗人群径有吸引 力。小歌爱腰不怕小置,怕的是任移不清是:RootBoard至少在任癌定薇上是清是的, 研發路握既源生感必考 RoatBoard 道频掌上 Linux 電盈,本黄是cyberdeck/ handheld terminal,研聚重黏不是把板子 塞进外,而是電源管理、斑温输入、酮示驱融、散然、系统赖像、休眼碳醒则可族修生。Linux能放勤只 是起贴,能不能在现場瑪定工作才是屋品。 開源参考可以看: Hackberry-Pi Zero: https://github,com/ZitaoTech/Hackberry-Pi_Zero 更大的方向可以多考 cyberdeck 社群的 Raspberry P1 handheld 要案,重临看轮矩、原管 理、外数端情则系统规像。 研發路径建曦先可用性檬機:而不是漂亮外显标:先建定键手感、金幂可调性、航、USB-C 充電、敏熟民系恢能力。第二酷段才做外数、揭叠器、GPI0摸展列原硬體權案。若要量產,最容悬被 低估的是供康键:显基、继幅、電泄、排续、外股公差郁害影警交付。 專案速结: Kickstarter: https://wwr.kickstarter,com/projects/dian-licu/rootboard Kicktraq: https://kicktraq.con/projects/dian-lieu/rootboard/

06.NanoKVM-Go:AIAgent要操作真實電腦,需要的​

不只是API btrag NanoKVM-Go: World's First Al-Native 4K USB- 028:03:05 C KVM STATUS:ACTIVE HK$771.828 1543% HK$7,975.556

15.95k%​

KIGKSTARTER NanoKVM-Go: World's First AI-Native 4K USB-C KVM Ceftrol ery US8-C deice fomaryhere wthone catle, Empower Algent wilh ful screen conbrol, Work Rarrcta, Few &rert ¥16,029,872 NanoKVM-Go 801 AI-NATIVE 4K USB-C KVM 28 X RH

背景故事 2·0支持 WorkRemote,FlowSmart Ertedded Systens anAI Aigorinieer, Crnrf the UcheeP, Tang, NaneiKVM, MssPy, arnd MiCM projeet. needs a hard reboot thot no software can rtach. TdnalKMetw ,e adkpters.it's jst may too mch for sorking on the go. An non of thes were buit fr the AI Wrk Fow now wfere your Al Aget nees to see, understn, n ct n rel screen. NanoKVM-Go s our answer. One USB-C cable, 4K, WF6 Hardware-level conrol. And for the fist time AI-Mative. Small Simple. Smart. From the team behind KVMs in the worid.

NanoKVM-Go 是一款 AI-nativc 4K USB-C KVN 它的產品级事很举:一根USB-C ,使用者或 AIAgent诵溢看到赠幕、控制猪品,虚理真實型情。这件事比「适溯桌面,亚底,医為它不依殖被控 端作案系统是否正常、不依粮敢體胀是否可用。 功能贴拆開看,它包含4K视讯输入、USB-C控制键路、Wi-Fi6、還端控制、硬键级童幕存取,以及面向 AI Agent 的 scrcenmcnory/control 能力。造盒能力到透瑞糖理、白勤化测式,息人值守設偏、 開發板管理,建你主模排障郁很有情值。 今天很多AI Agent 退停在溯宽器、SaaS、API 和受控沙盒程。它仍可以操作斓页,离文檀、調接口,但 遇到BIOS、系统安装,死概图面、耐缓险佩,强速實精硬特就害失效。KVH的情信在龄,它旗AI或人能 以看量幕+打键献:的方式进人真實電题艾界。 遗也是高凰险能力,能看警幕、能控制键鼠,就代表權限很高。品要连入專業增景,必须把安全模型清 楚:登人睡盘、需幢加密、權限分级、操作塞計、透端授權、物旺硅想、失哪恢值、權限撤销。泣有遗些, AI-native 只會额人更不放心。 NanoKVM-Go的显感價值在於,它把AI硬睡的方向提「做一固新强:畅到饿AI接警面。這

四方向很硬,也很责用。​

研發路径與院源生部参考 在底架模上,NanoKVM-Go颈產品通常會丽膜视摇集+硬细疆+Web集流+USBHID模

• 速温安全,来提計。它不一定必须使用高隔SoC,但若要微4K指取、低延遥需流质激额存取,就需要

具需酸端视肌螺解碼能力、成系Linux 支握典USBgadget/HID 能力的主控。花严業路续看,题似瑞芯 抛、全志、RISC-VLinux SoC或再用视虚理方案都有可能;真正遥型时,不只看算力,也要看V4L2、 UVC、硬疆、USBgadget、W1-F1疆融购主嫂内核支持n熟度、 開源参考首据: PiKvM: https://githuh con/pikvm/pikvm PiKVM Handbook: https:/pikvm-github. io/pikvm/ PiKVM 已疆把 HDHI 桑取、KVN OVer IP、坚昆模展、虚服媒帽、BIOS 级运潮控制等核心键路脂通。另

一個值得看的再案是:​

BlikvM: https://github.com/blikvn/blikvn BliKVM 明碰覆 Raspberry Pi CH4、PCIe、HAT、Allwinmer 等不习硬醒版本,对量盈型 KVN 的 硬键取拾很有象考值值。 對规做确似品的属赚来职,建满不要零幕整個KVMstack、第一陷段直接用P1KVM/BL1KVN研究完 整键路:HDMI/UVC 携取、MJPEG/H.264/WebRTC、USB HID,虚挺U 蟹、ATX 電源控制。第二屠段再 健自有硬赠板卡,把成本、尺寸、滑热终供露露下京。第三踏段才做AI Agent screen menory、OCR、 操作回放與限密計。這样至少能省拒平年以上底圈期试時间。 票案速结: Kickstarter: https://w.kickstarter,com/projects/zepan/nanokvn-go-worlds-first ai -native-4k-usb-c-kvm Kicktraq: https://kicktraq-com/projects/zepan/nanokvn-go-wurlds-first -ai -native- 4k-usb-c-kvn/ ElectronicsEngineeringLabKit:教育硬體 07. 的核心不是元件包,而是把學習路設計好

ering Lab Kit: Project- 028:22:01 Based Fundamentals $43.170CAD STATUS: ACTIVE 575% ENT PLEDGE LEVEL S356,153 CAD 474836

Electror led Fun ¥5,157,581 89 28 AO

背景故事 MOTIDN 219 898 - H .8n LED s cw : signais: From First Circuit to Real System 支持 其定包不要要回解 Fundamental EE Starter KIit c 1

可用的国限 Electronics Engineering Lab Kit 是一套面向電子工程入胃老的零系式學留套件,它看起来没有AI 眼舱或模器人吸情,但產品值值很清楚:初學者「我有一非零件」走到我能理解做出一個系能。 很多電子入門圣品只解法了供然问题:给你疆包板,绩材、感测瞬、模组,闻發板。真正卡住学图的,往往不 是缺军件,而是不知道下一步怎度迁。LED亮了以後,怎磨理解電路?怎磨翔訊號?怎磨排辑?怎磨把多個 模组接成一個完整系统?這些才是教育爱睡的座品雕贴。 遗图要案主打Projcct-BasedFundancntals,對逐的功能不是單一硬错,而是一整盒智能模:验任 强、元件组合、提程材料、示退/量测理解、逐步涩橘的需案路復,以及最後能把知基来起来的整合续留。它 面的是「攀暂碰定性」,不是元件数量。 PM需要看的指梗也不只是BOM,好的教育会件要有清楚的任称分、可够暨的误路很、足期好的教材前 奏、可重福操作的胃验设計,以及能支握初老提周的社群或内容更折。否则两漂亮的盒子,也會提成更责的

零件包。​

這慧產品如果做得好。會把硬错教育炭“買一堆乘西白己溪成沿著路径建立能力;。到套品经理采院, 是很典型的内容硬精结合案例:硬耀是延糖,真正的留存来白學器进展。 研發路得员民源生账考 電子教育套件的研盈要分成硬错、操程、工具三修嫌。硬错上要有疆包板、可重箱使用的露测/输出模担、 保電路、测试购清是标示:课程上要有提基隧電路到系统整合的任移样度:工具键上要课使用者能蛋图、 套码、量测、排。 開源考可以看: kitspace/awesone-electronics: https://github. com/kitspace/awesone-electronics How to learn modern electronics: https ://github.com/joaocarvalhoopen/How_to_lcarn_nodern_electronics 前者整理大里電子工程工具则资源,後者更像翠暂路径指底。考要做開源硬體榴案,KiCad、Arduino、 CircuitPython,HicroPython 这些生也愿鼓一起销入。 霍品研發上,建先定费8到12核心任移。而不是先准零件。比如電源、分整、訊蒸源波、感潮器 取、PhM、I2C/SPI、音訊题示、資料記、系整合。每個任移都囊设計常见继娱和如何排.因 为数育差品真正的情信,是赠便用著得通卡住的地方。 勇案速结: Kickstarter: https:/www.kickstarter,com/projects/evoinmotion/electronics- engineering-lab-kit-project-based-fundanentals Kicktraq: https://kicktraq.com/projects/evoinmotion/electronics-engineering-lab- klt-project -based-fundanental.s/

08.DESL0CV150PLus:智慧的好功能,不一定是多​

種开方式 trag DESLOCV150Plus:Low-Light Self-Charging 022:04:58 Solar Smart Lock STATUS:ACTIVE 425396 DGE LEVEL $1,465,105

14.65k%​

KIGKSTARTER DESLOC V150 Plus: World's 1st Low-Light Self-Ch lng Lock DESLACV ¥68,555,785@ 308 613 WORLD'SFIRST 22 LOW-LIGHT SELF-CHARGING SOLARSMARTLOCK

四AO​

R

二

First week orders to getoneFREESmartLockCl10 Worth $49.99

Free shipping 30-Doy Return Up to 2-Yeor 24/7 Customer Service Gucrantee Begins in August Warranty

World'sFirst Low-Light Self-Charging SolarSmart Lock DESLCV150Plus DESLDCV158PLus是一款低光白充電太属能暂慧额。智慧市場已经很捷持,指胶、密碼、App、NFC、 随际授播、通端管降都不新鲜,它比较有意思的地方,是把注意力放在一国长期照输问题上:P辑不能额人一 直钙配電量, 功能贴包猛 Bu1lLt-1n Perovskite Solar Panel、 Lov-Light SeLf-Charging, 指效/室码等智慧 開演能力、长期供罩、保固则客服承据。这些功能膚德的毫品握相不是增加互勤,而是降低进掘。門编不像手 楼,泣電就充:也不像耳姨,忘了充遗先不用。同胡一旦在開继特刻失效,使用者鲁非常不爽。 低光自充電是圆好切人點,因為它把智题编的情值徙我能怎度围門,拉到我多久不用置它:。如果室内弱 光、府敲射光、除天光照也能種定神能,使用者得到的是少一次充電、少一次拆镇、少一次低電量焦语。 不语它的验谊也要看遗界缘件:低光到底多低?遵域险雨能挥多久?電池雨三年後衰减如何?冬学日照,門扇 影,防水,防痛、断纲、耀螺期、信用供電怎磨處理?智慧银的错睡底续不是功能多,而是可靠。 DESL0CV150PLUS检品握理的敏登是:成熟品類理仍然有碰鲁,但機奢不一定来自加功能,而是采自减 少使用看的维疆成本,真正好的家用硬疆,常常是镇人忘記它的存在。 研發路握既源生服必考 智基镇的研發不能只看MCU和ApP,退要把安全、模械、電源、通讯、售後全部放进系设計。DESLOC V159Plus的核心差具是低光自充電,因此研髮上需斐同時胎逐太属能板效率、室内弱光模型、電池衰液 待功耗、锁错電赠峰值電流與低電量保围。 開源参考可以看ESP32智慧额频等案,例如: vogler/SmartLock: https://github. con/vogler/SmartLock Iot-Door-Lock-System:https://github,com/Dubemchukwu/Iot-Door-Lock-System IoTbasedLockV2.0: https : //github con/make2expLore/IoTbasedLockv2.0 這暨寻案能南图除理解指纹,RFID、PIN,于糖控利、電機腿数、害端後台的基本键路,但不康直接照握安全 量型智基流量鞋的是安全则可露性:能用期要可露,运施授權要可控,勿赠升级要防回浓,金输不能裸 套,断章/低活/潮遇/暴力破增都要渊,太膳能只是差暑化入口,真正的產品底翰仍然是摄得提械、章派管理 则安全架类。 專速结: Kickstarter: https://w.kickstarter.com/projects/desloc/worlds -first-self- charging-sotar-sart-lock Kicktraq: https://k1cktraq.con/projects/desloc/worlds-first-self-charging-solar- snart-1ock/

09.TerraMowXAWD:户外機器人正在把地機器人的​

避辑搬到草坪 Kichtrag TerraMow X AWD I World's 1st Tum-Free AWD 030:05:02 Al Robot Mower STATUS:ACTVE HK$13.664.117 4554%6

13.09k35​

IIGNSTARTER

Frse Sttu ¥280,803,167 W XI World’s1st Turn-Free AWD 30 Al Robot Mower 2V

El Via O. 背景故事 TERRAHOW XI mcegireis World'slstTurn-Free AWDAIRobotMower 支持

增它,以支弹 用的国 TerraMowXAnD是一款四AI割草機器人。招选模器人已經教商了市场:家移可以被機器畏期按管。 下一個向然外溢场景就是严外,元其是草、庭院、涤油、除雪和户外清源。 遗储尊案的功能胎很完整: 42V AND 四疆、6-Can AI V1s1on, 960W Cutting Power、20-1nch Cutting Deck, DIY Expanslon, Wireless Setup, 以及 Turn-Free / Shuttle Drive 的脂径 效率设計。相比早期翻草糖器人,它思解决三隔题:不恐埋遗界级、夜辑草不好走、翻草略径效率不高。 乒外场景比室内鞋很多。草地會温,坡度會,地面有石顾和坑洞,疆物则小孩可能突然出现,光照也會大幅 提化、室内楼器人主要是减航测进险:户外根器人遗要面對刀始安全、雨水、防盗、地屋恢捷、遗逐虚理期草 评损低。 PH视角看,TeraNow的情值不是它害自已勤,而是把每退融草谊件重家鹅成可能付流程。使 用者真正置的是時間、定和安全感。一次展示跑得漂亮不狗,長期据人值守才是核心。 这方向循得放连品雷達,提地器人管明了家庭自動化可以微卓一任移他起。户外睡器人期可能成为下一 钢高客单、高技術密度、高信任門的家用硬错霖增。 研發路径與跟生部参考 制草相器人的研登核心是定位,规副、控制测安全。TerraMowXAND 语理AI视覺现规综卵置,本算上 是在替代循统造界。遗要求它能定别单坪摄界、隧砸德、玻度、混滑地面、疆物账人,亚且能在长期后 外環境中保持地国兵路径可零。 開源参考最值得看: OpenMower: https://github.com/ClemensE1fLein/0penMouer OpenMower 官方介据:https://opennower de/ OpenMowcr 是 GPL提、基 RO5/RTOS 的RTK GP5 割草榜器人平台,重是用厘米级RTK 定位 和路规副替代封展盒。它不等龄TerraHrw的视觉路绿,但能非常好地展示翘草嫌器人的定位、控利、 路径规翻硬错改造键路。 考囊傅 TerraHow频毫品,研發路很可以分成三阶段:第一陆战用 ROS+RTK/GPS 或视景 SLAM跑通 募航:第二陪段加入刀望安全、障破物蒲列,南水/圾度/防盗/急停;第三陪段才是量严外股、密对、长副草 坪测试兴App错验。户外橙器人不是一次deno成功就算成功。至少要跑完多季航、多草種、多地形的可 垂性期。 勇案速结: Kickstarter: https://www.kickstarter.com/projects/terramow/terramow-x-avd - worl.ds-1st -turn-free-awt-ai - robot -mower Kicktraq: https://kicktraq-com/projects/terram/terramo-x-asd-worlds-1st-turm- free-avd-a1-robot-mover/

10.OMNIX1:智慧健身的關鍵,不是幕課程,而是真​

實阻力控制

OMNI X1: Beyond Real Strength All-in-One 035:06:02 Smart Gym Machine STATUS:ACTIVE HK$13.011,616

16.59k%​

HK$54,412,212

69.41k%​

SHAFE

KIGKSTARTER OMNIX1: Beyond Real Strength AI-in-One Smart Gym Machine ¥267,699,857 @ 663 WORLD'SFIRSTBEYOND REALSTRENGTH 35 ALL-IN-ONE

只有在导率在置德运财规止跨限之前确 背景故事 88X1 IIO YT 支持 GYM LXINWO 135 19 Feels Like the Gym, Trains Beyond It. 用的国 OMNIX1是一台全台一智瑟力量训辣醒,智慧健身设偏握语一输熟凝後,使月者已短不太會為幕上有 操程:胃單,更有值值的方向,是把家度程最摊親的部分搬回家:定阻力、勤作控制、现端记缘、负 荷赠和安全保疆。 功能上,它射磨的是cabte training、笔機阳力、全身肌频雪作、困人化只荷、整作输动、资科记疑兴暴 程系统。它不是商单拉力器。也不是一境内容强幕。而是恐把核電控利與训频软腰整合成一套家庭力量训频系 统。 家度力量制绩的痛贴很明殖:器械估地大、项要胃一蔡套、融作容易不標率、使用客不知道如何加垂量、制 神品胃整以長期迹。如果OMNIX1能把阻力拥眠、勤作回情、U缺针墨和安全制丰起来,它画的就不 是签材,而是更低門格的力量规额流程。 PM要注意的是,造频產品的「智瑟,必涌落在楼電能力上。App提程只是入口,真正的壁最是阻力是否平 滑、反感是否即晒、烟索购滑输是否可靠、禁携是否安全、噪音是否可接受、急停與保疆機利是否充分。硬體 越贴近身體,客然越低。 OMNIX1的飘察情信在绘,它把智意健身内容平台拉回硬需能力。这是更瓣的路,但也更可能形成壁量。 研發路得美附源生单考 智延力量制提的底不是健身ADP,而是機控割期安全模。要做CNINIX1颈案品,核心要解决電 阻力由媒、摄东很力核测、位置/迪度估算、急修、适飘保据、噪合、散熟與機械善命,软耀端两叠加课程、 勤作鐵别、进度管旺则图人化负药。 用源参考可以分南题,電情控利與仿真可看: gym-electric-motor: https://github.com/upb-lea/gym-electric-motor 這個專案可用於理解不同電機控制策略贝控制環境建模。健身動作罐别可看: MediaPipe Pose: https://github.com/google-ai- edge/mediapipe/blob/master/docs/solutions/pose.md 以及一些基於MediaPipe/OpenCV 的健身分析要案,例如: https://github.com/DanielGuarnizo/Pose-Estimation-for-Fitness-Exercise-Analysis 若做蓝牙健身設備互通,也可看: 它對雁 Bluetooth Fitness Machine Service。 研發上不建一開始做全功能家庭健身房。第一版可以只做單绳或變绳阻力平台,先验證阻力控制是否平滑、 動作安全是否可靠、使用者是否感觉自然。第二版加入動作識别與訓計蛋,第三版才做完整内容生態。這類 產品的技術證城河不是課程数,而是使用者拉第一下時,是否觉得這個阻力可信。 專案速结: Kickstarter: https://www.kickstarter.com/projects/innodigym/omni-x1-best-all-in- one-smart -cable-training-machine Kicktraq: https://kicktraq.com/projects/innodigym/omni-x1-best-all-in-one-smart- cable-training-machine/ 放在一起看:本调硬體專案的三個訊號

第一個訊號:AI正在徙「對話介面蔓成「硬體能力。MemoMindOne 把AI放进视線,NanoKVM-Go​

把AI接到真實電腾,TerraMow把AI放進户外導航。這些產品不是單純把AI寫進標题,而是在导找 AI可以接管的實體任務。

第二個訊號:成熟品類的機會,很多来自降低维成本。DESLOC减少充電焦虚,MouseArc减少接線摩​

擦,TerraMow减少每退割草。好的硬體不一定额使用者多操作,反而常常使用者少虚理一件麻烦事。

第三個訊號:專業能力正在被重新包装。RootBoard 把Linux 工作流成掌上設備,ElectronicsLab​

Kit把電子工程學習做成專案路径,KBDcraftSAHA把键盤成模组化输入系统。這類座品不一定追求最 大市場,但很擅長服務明確人群。 如果把这10個要案墅成一句產品判断,下一波值得看的硬體,不是單多一個入口,而是能把原本麻、 分散、需要經验的流程,整缩成更稠定的產品體验。 如果只挑三個做深入研究,非常推票NanoKVM-Go、MemoMind One、TerraMow X AWD。 NanoKVM-Go值得看,是因為它抓住了AIAgent准入真實設借世界的底履接口問题。這不是炫技,而是 遠端维谨、自動化測試、設備管理都可能用到的硬需求。 MemoMindOne值得看,是因為它没有盲目追逐「眼镜也要拍摄,而是用無摄影機設計重新切入AI眼 镜。這種界感,比堆功能更像成熟產品。 TerraMowXAWD值得看,是因為户外器人正在進入一個很像早期地機器人的陷段:任務明確、技術門 槛高、信任建立慢,但一旦跑通,使用者黏性舍很强。 這三個專案代表三條不同路径:AI接管真實設備、可穿戴硬體降低社交成本、户外機器人接手重複家務。它 們共同指向一件事:硬體創新的重點,正在「做一個新装置;轉向「重窝一段流程」。 全文專案連結總 MemoMind One AI顯示眼镜: Kickstarter: https://www.kickstarter.com/projects/1963472698/memomind-one-the- most-natural-ai-display-glasses Kicktraq: https://kicktraq.com/projects/1963472698/memomind-one-the-most- natural-ai-display-glasses/ MouseArc無综高清影音收發器: Kickstarter: https://www.kickstarter.com/projects/mousearc/mousearc-g1-puzzle- style-wireless-transmitter-and-receiver Kicktraq: https://kicktraq.com/projects/mousearc/mousearc-g1-puzzle-style- wireless-transmitter-and-receiver/ KBDcraft SAHA 模组化键盤: Kickstarter: https://www.kickstarter.com/projects/boyu/kbdcraft-1e-saha-the-55- modular-duo-controller-input-deck Kicktraq: https://kicktraq.com/projects/boyu/kbdcraft-10-saha-the-55-modular- duo-controller-input-deck/ DUSQ睡眠管系统: Kickstarter: https://www.kickstarter.com/projects/dusq/dusq-the-worlds-only- sleep-regulation-system Kicktraq: https://kicktraq.com/projects/dusq/dusq-the-worlds-only-sleep- regulation-system/ RootBoard 口袋 Linux 電脑: Kicktraq: https://kicktraq.com/projects/dian-lieu/rootboard/ NanoKVM-Go AI KVM: Kickstarter: https://www.kickstarter.com/projects/zepan/nanokvm-go-worlds-first - ai-native-4k-usb-c-kvm Kicktraq: https://kicktraq.com/projects/zepan/nanokvm-go-worlds-first-ai-native- 4k-usb-c-kvm/ Electronics EngineeringLabKit 電子工程實验套件: Kickstarter: https://www.kickstarter.com/projects/evoinmotion/electronics- engineering-lab-kit-project-based-fundamentals kit-project-based-fundamentals/ DESL0CV150PLuS太陽能智慧: Kickstarter: https://www.kickstarter.com/projects/desloc/worlds-first-self- charging-solar-smart-lock Kicktraq: https://kicktraq.com/projects/desloc/worlds-first-self-charging-solar- smart-lock/ TerraMow XAWD四驱AI割草機器人: Kickstarter: https://www.kickstarter.com/projects/terramow/terramow-x-awd- worlds-1st-turn-free-awd-ai-robot-mower Kicktraq: https://kicktraq.com/projects/terramow/terramow-x-awd-worlds-1st-turn- free-awd-ai-robot-mower/ OMNIX1全合一智慧力量訓機: Kickstarter: https://www.kickstarter.com/projects/innodigym/omni-x1-best-all-in- one-smart-cable-training-machine Kicktraq: https://kicktraq.com/projects/innodigym/omni-x1-best-all-in-one-smart- cable-training-machine/

原始排版图​

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