2026年2月

此前,一些投资者开始担心,AI 硬件领域的大规模支出增长可能难以持续,从而引发对行业泡沫的忧虑。在这种情绪下,英伟达刚发布的财报不仅是公司自身的成绩单,也被市场视作整个 AI 资本开支周期的一次“压力测试”。

 

英伟达公布了好于预期的第四财季业绩,核心驱动力来自数据中心业务:该板块收入同比增长 75%。财报发布后,公司股价在盘后交易中一度上涨,随后回吐了大部分涨幅。

  • 每股收益:调整后 1.62 美元,高于预期的 1.53 美元

  • 营收:681.3 亿美元,高于预期的 662.1 亿美元

 

本季度,英伟达总营收同比增长 73%,从去年同期的 393 亿美元增至 681 亿美元。目前,公司超过 91% 的销售额来自数据中心部门,该部门涵盖其市场领先的 AI 芯片产品。

 

更关键的是业绩预测。英伟达预计下一财季营收为 780 亿美元,上下浮动 2%,明显高于分析师此前预期的 726 亿美元。公司同时强调,这一预测并未计入来自中国的数据中心收入。

 

黄仁勋回应各业务情况

 

“许多计算非常适合在太空完成”

 

数据中心业务本季度营收为 623 亿美元,高于 StreetAccount 统计的 606.9 亿美元预期。根据英伟达发布的新闻稿,净利润几乎翻倍,达到 430 亿美元,合每股 1.76 美元;去年同期为 221 亿美元,合每股 0.89 美元。

 

市场目前高度关注英伟达下一代 Vera Rubin 机架级系统的发布。Vera Rubin 预计将实现每瓦性能提升 10 倍,在数据中心面临电力约束的背景下,其能效优势尤为关键。该系统是 Grace Blackwell 的继任者,预计今年晚些时候推出。

 

英伟达首席财务官 Colette Kress 在电话会议上表示,公司本周早些时候已向客户发出首批 Vera Rubin 样品,并仍按计划在下半年启动量产交付。此外,Blackwell 会持续出货,同时 Vera Rubin 也会逐步进入市场。Blackwell 已经被客户写进计划与订单;Rubin 在下半年的初期爬坡规模尚难判断,但需求强度和客户兴趣没有疑问,几乎每个客户都会购买,关键在于英伟达多快进入市场、客户多快在自家数据中心把它跑起来。

 

当前,英伟达正在推动 Vera CPU 作为独立方案进入市场。黄仁勋透露,公司对 CPU 做了与世界上其他 CPU 完全不同的架构选择,它是唯一支持 LPDDR5 的数据中心 CPU,设计目标是极强的数据处理能力。

 

“因为我们关注的大多数计算问题都是数据驱动的。AI 的整个流程,从数据准备、pre-training 到 post-training,都依赖大量数据处理。很多工具运行在纯 CPU 或 CPU+GPU 环境,Vera 是为 post-training 等场景打造的优秀 CPU。在 AI pipeline 中确实有大量场景需要强大的 CPU,我们喜欢 CPU 与 GPU 协同。当你把算法加速到极限,Amdahl's Law(阿姆达尔定律)告诉你需要极快的单线程 CPU。我们当年把 Grace 做到单线程很强,而 Vera 比它更强。”黄仁勋说道。

 

对于芯片业务,英伟达明确称,正在将供应链从高度集中的亚洲地区拓展至美国和拉美。目前,英伟达已在 Taiwan Semiconductor Manufacturing Co. 位于亚利桑那州的新晶圆厂生产 Blackwell GPU,其部分机架级系统也在墨西哥一家大型新建的 Foxconn 工厂组装。公司认为,这些布局将增强供应链韧性与冗余,以满足不断增长的 AI 基础设施需求。但英伟达也提醒,扩产能力仍取决于当地制造生态系统能否及时提升到所需规模。

 

近期太空数据中心也被炒得沸沸扬扬。黄仁勋坦诚,现在太空数据中心的经济性确实很差,但会随着时间改善。

 

他解释道,太空的物理条件和地面截然不同。虽然太空中能量充足,太阳能板可以做得很大,空间也十分充裕,但散热方式却完全不同:太空极度寒冷,却没有空气流动,散热只能依靠传导与辐射,因此需要体积庞大的散热器。液冷在太空基本不可行,因为不仅重量过大,还可能面临冻结风险。可见,地面与太空的散热方案完全是两套逻辑。

 

“尽管如此,确实有许多计算问题非常适合在太空完成。我们已经让 GPU 进入太空,Hopper 架构已成功部署。一个典型的应用场景是成像:通过光学与 AI 技术,可以实现超高分辨率成像、多角度重投影、超分辨率、降噪等一系列处理。如果要将 PB 级甚至 EB 级的图像数据全部传回地球再处理,难度极大;相比之下,直接在太空完成处理,只将有价值的信息回传,无疑高效得多。可以预见,太空 AI 将催生一系列极具想象力的应用场景。”

 

推理性能的跃迁至关重要,推理=营收

 

对于未来的技术路线,黄仁勋明确表示,不会轻易走向 chiplet 方向:只要 monolithic die(单片集成芯片)还能做到极致,就应该尽量把它推到极限。因为每跨越一次 chiplet 或接口,就会引入额外的延迟和不必要的功耗。

 

“我们并不排斥 chiplet,事实上我们已经在使用,但只在不得不用的时候才用。”他解释道。以 Grace Blackwell 和 Rubin 架构为例,他们采用两块接近 reticle 极限(光刻掩模版尺寸极限)的大芯片并排贴合,尽可能减少架构层面的跨越。在他看来,chiplet 的“税”最终会体现在架构效率上。“很多人说这是我们的软件优势,但软件和架构其实很难分割。软件之所以高效,是因为底层架构足够优秀。CUDA 架构在每 flop、每瓦特上的效率都更强,这本质上是由架构设计方式决定的。”

 

他进一步指出,CUDA 具备极强的通用性,GPU 架构始终保持良好的兼容性,这意味着今天为 Blackwell 所做的优化,同样可以惠及 Hopper 和 Ampere。这也是 A100 发布多年后仍然不过时的根本原因。架构的持续兼容,让其可以持续投入软件工程和优化,让云端、本地以及各代 GPU 的装机基数全部受益,从而延长产品生命周期、提升创新速度与灵活性,最终转化为客户的实际性能优势。

 

谈及推理能力,黄仁勋强调英伟达的推理栈依然是全球性能最强的。“为了在 NVLink 上实现推理优化,我们必须发明全新的并行化算法,这些算法构建在 CUDA 之上,能够将工作负载高效分布到 NVLink 72 的聚合带宽上。正是 NVLink 72,让我们实现了每瓦性能代际提升 50 倍的巨大跃迁。实现过程极其困难,涉及交换技术、解耦交换、系统机柜构建等一系列突破,但最终结果令人惊叹:每瓦性能提升 50 倍,每美元性能提升 35 倍。”

 

他强调,推理性能的跃迁至关重要。更关键的是,对于客户而言,推理已经直接等同于营收。以 agent 系统为例,生成的 token 数量极其庞大,且效果显著。一个 agent 写代码时可能生成成千上万、甚至数十万 token,因为它需要持续运行数分钟乃至数小时。而 agentic 系统还会派生多个 agent 协同工作,token 量呈指数级增长。每一个 token 都可以被货币化,推理性能直接转化为营收。

 

而对于数据中心来说,每瓦特能产生的 token 数量,直接决定了云服务提供商(CSP)的营收能力,因为所有人都受限于电力。无论数据中心规模多大,总有功率上限。因此,最优的每瓦性能架构,决定了在相同电力约束下能创造多少营收。

 

“现在每一个 CSP、每一个 hyperscaler 都明白这个逻辑:资本支出变成算力,选择正确架构的算力,才能最大化营收。算力就是营收。没有今天的算力投资,就没有明天的营收增长。”黄仁勋总结道。

 

“我们已经成为全球规模最大的网络公司之一”

 

在数据中心板块内部,英伟达报告称,用于连接数百颗 GPU 的网络设备销售额达到 109.8 亿美元,同比暴增 263%。这一增长反映出市场对 NVLink 网络技术以及 Spectrum-X 以太网交换机的强劲需求,后者已与 Meta 等科技巨头达成新合作。

 

黄仁勋指出,AI 基础设施的核心计算单元包括 CPU 和 GPU。英伟达通过自研的 NVLink 技术,将单个计算节点扩展为一个巨型计算机柜,由此提出了“机柜级计算机”的概念。

 

在此基础上,英伟达构建了完整的互联体系:通过 NVLink 实现机柜内部的 scale-up(纵向扩展),再通过 Spectrum-X 和 InfiniBand 实现机柜之间的 scale-out(横向扩展),两种路径全面支持。更进一步,通过 Spectrum-X 的 scale-across(跨域扩展)能力,可以将不同数据中心连接起来,实现更大规模的跨域计算。

 

黄仁勋表示,NVLink 的发明不仅提升了计算密度,也极大地推动了公司的网络业务。以每个机柜为例,通常配备九个交换节点,每个节点包含两颗芯片,未来这一数字还会继续增加,这意味着每个机柜内部的交换规模极其庞大。

 

“如今,我们已经成为全球规模最大的网络公司之一。以以太网为例,我们两年前才正式进入以太网交换领域,但我认为我们现在很可能已经是全球最大的以太网网络公司,至少很快就会达成这一目标。对我们而言,Spectrum-X 以太网平台堪称一场‘全垒打’。”

 

他认为,当前,AI 工厂的投资规模动辄达到 100 亿至 200 亿美元,在这样的体量下,哪怕只是 10% 的效率提升,甚至是 20% 的网络利用率提升,都能转化为巨额的经济价值。这正是英伟达的网络业务能够高速增长的根本原因:把 AI 基础设施的效能做到了极致,而 AI 基础设施本身,正在以前所未有的速度扩张。

 

游戏业务与内存瓶颈

 

曾经是公司最大业务的游戏部门,本季度营收同比增长 47%,达到 37 亿美元,但环比下降 13%。市场普遍推测,在内存资源紧张的情况下,芯片制造商会优先保障 AI 处理器的产能,英伟达今年可能不会推出新款游戏 GPU。对英伟达来说,这意味着更多资源将继续向 AI 加速器倾斜,例如 72-GPU 架构的 Grace Blackwell 机架级系统。

 

内存短缺一直是投资者关注的潜在风险。Kress 表示,供应限制预计将在 2027 财年第一季度及之后对游戏业务形成压力。

 

在汽车业务方面(包括汽车和机器人芯片),英伟达本季度营收为 6.04 亿美元,同比增长 6%,低于 StreetAccount 预期的 6.548 亿美元;在专业可视化业务方面,公司本季度营收为 13.2 亿美元,同比增长 159%,显著高于 7.554 亿美元的市场预期。

 

与 OpenAI 合作接近达成

 

英伟达继续加大对 AI 实验室和行业公司的投资,包括对芯片制造商 Intel 的大额持股。公司在年度文件中披露,本年度向私营企业和基础设施基金投资 175 亿美元,“主要用于支持早期初创企业”。同时,公司提醒,这些投资可能在短期内无法实现盈利,甚至可能无法带来回报。

 

黄仁勋在周三电话会议中透露,英伟达仍在与 OpenAI 推进合作协议,并认为双方已接近达成。此前报道,英伟达将对 OpenAI 进行 300 亿美元股权投资,并将取代双方去年 9 月宣布的 1000 亿美元长期合作计划‌。‌‌

 

Kress 表示,战略投资是重要流程之一。与此同时,公司也在持续回购股票、发放股息,并在合适时机进行资本运作。

 

黄仁勋的核心判断:拐点已至,算力=营收

 

今年以来,英伟达股价表现优于所有超大市值同行,持续成为 AI 浪潮的最大受益者。截至周三收盘,英伟达股价在 2026 年累计上涨 5%,而纳斯达克指数同期下跌 0.4%。万亿美元市值俱乐部中,今年实现上涨的仅有 Apple,涨幅不到 1%。

 

在英伟达财报公布前,市场已从四大云计算巨头 Alphabet、Amazon、Meta 和 Microsoft 几周前的财报中窥见趋势:结合这些公司的资本支出指引与分析师预估,今年四家公司合计资本支出可能接近 7000 亿美元,用于扩建 AI 基础设施。英伟达也承认,超大规模云服务商仍是公司最大的客户类别,占数据中心收入略高于 50%。

 

问题随之出现:基数已经这么高,明年还怎么增长?更何况,其中几家的现金流能力还在被压缩。围绕这一点,黄仁勋在电话会议上给出的答案是“有信心”,而支撑信心的逻辑并不来自宏观判断,而是来自他对“AI 工作负载变化”的判断。

 

黄仁勋表示,他对客户现金流的增长非常有信心,“原因很简单,我们已经看到 agentic AI 的拐点出现。agents 在全球企业场景中具备了明确可用性,算力需求因此变得极其惊人。”在他的表述里,新的等式已经成立:在 AI 世界里,算力就是营收:没有算力,就无法生成 tokens;没有 tokens,就无法实现收入增长;因此算力等于营收。

 

他进一步解释,随着 Codex、Claude Code 的生产性使用,以及围绕 Claude Cowork 的热度、Openclaw 及其企业版带来的巨大兴奋,再加上企业 ISV 在工具平台之上构建 agentic 系统,行业已经开始生成“可盈利的 tokens”。这些 tokens 对客户具备生产力价值,对云服务商也能带来利润。计算方式正在发生迁移:过去软件运行在相对有限的计算资源之上,每年三四千亿美元资本支出;如今这些资本开支正在流向 AI。AI 要生成 tokens,就必须消耗算力,而算力会直接转化为增长与营收——这也是英伟达持续增长的底层动力。

 

对于未来业绩的持续性,黄仁勋把毛利率问题归结为一条简单但苛刻的标准:毛利率最重要的杠杆是代际领先能力。只要英伟达能持续交付在每瓦性能上的代际跃迁,并且这种跃迁显著超过摩尔定律带来的改进;只要每美元性能的提升能明显超过系统成本上升速度,毛利率就能维持。

 

他强调,公司之所以跑得快,是因为全球 token 需求在拐点之后呈指数级增长:甚至六年前的云端 GPU 仍被完全吃满、价格还在上涨,说明现代软件方式对算力的需求正在指数级扩张。英伟达的策略是每年交付一整套 AI 基础设施:今年发布了六颗新芯片,下一代 Rubin 还会发布更多芯片,并承诺每一代都带来多倍的每瓦与每美元性能跃迁。支撑这种跃迁的底层方法,是他反复提到的“极致协同设计”。

 

“市场判断错了”:AI 不是吞噬软件,而是让软件变强

 

在公司发布强劲财报数小时后,黄仁勋在采访中直言市场高估了 AI 对软件公司的威胁,认为市场对趋势的判断出现偏差。

 

“我认为市场判断错了,”他反驳了“AI 智能体会蚕食企业软件行业”的担忧,提出一个更“反直觉”的判断:大量软件公司会利用 agentic AI 来开发自身软件并提升效率。企业不会用 agents 去替代工具,而是用 agents 去使用工具,也就是说 agents 是“工具使用者”。

 

他用互联网浏览器和微软 Excel 作为例子,说明 agents 会在既有工具体系内完成工作。

 

在他看来,Cadence、Synopsis、ServiceNow、SAP 等工具之所以存在,是因为它们解决了非常根本的问题。agentic AI 会变成智能软件,代表人去使用这些工具,让人更高效;而像 ServiceNow 这样的公司,不会被别人“服务得更好”,反而会做出针对自身工具高度优化、微调的 agents。最终,人仍然需要工具把工作“做完”,并把信息以人能理解的方式呈现出来。

 

黄仁勋还在电话会议上进一步给出更长期的推演:未来软件将由 token 驱动。数据中心生成 token,推理就是生成 token。NVLink 72 让单位能耗 token 生成性能比上一代提升 50 倍。未来软件对算力的需求将远超过去:过去世界每年投入三四千亿美元用于传统计算;AI 出现后,所需算力是过去的数百甚至上千倍。如果 AI 有价值,世界就会投资来生产 token,全球需要的 token 生产能力远不止 7000 亿美元。

 

他认为,所有公司都依赖软件,未来每个软件都会依赖 AI,因此每家公司都会生产 token,这也是他称之为 AI 工厂的原因:云公司在数据中心建 AI 工厂,为营收生成 token;企业软件公司在工具之上生成 token;机器人与自动驾驶同样如此。

 

黄仁勋表示,过去的软件是预编码的,现在一切变成实时生成:结合用户上下文与意图,生成“新的软件”。实时生成的计算量远高于预编码,就像计算机远比 DVD 播放器算力强大一样,AI 需要远超过去的软件算力。从产业层面看,如果新软件需要生成并货币化 token,数据中心建设就会直接驱动营收,算力驱动营收。

 

他判断,agentic AI 已在最近几个月达到拐点:行业内部更早看到,但现在全球都意识到 agents 已经足够聪明,能解决真实问题,写代码已被广泛支持。以 Anthropic 为例,营收一年增长 10 倍,但受制于产能;OpenAI 同样需求旺盛。算力上线越快,营收增长越快。下一波拐点将是 physical AI,把 AI 与 agentic 系统带入制造、机器人等物理世界应用,这是巨大的机会。

 

尽管一些分析师警告长期来看 AI 可能会“吞噬”软件行业,但对这一风险以及近期软件板块抛售背后的基本面因素,市场观点仍分裂。

 

在黄仁勋接受采访后,Niles Investment Management 创始人兼投资组合经理 Dan Niles 提醒市场:铁路、运河、互联网等基础设施在发展过程中往往会出现过度建设,之后市场才会逐渐分辨赢家和输家。他警告,并非所有公司都能在 AI 自动化工作流程、压缩价格、降低新进入者门槛的趋势下全身而退,“软件行业里确实会有一些公司最终走向归零”,相对更具韧性的板块可能是数据库与网络安全。

 

参考链接:

https://nvidianews.nvidia.com/news/nvidia-announces-financial-results-for-fourth-quarter-and-fiscal-2026

https://www.cnbc.com/2026/02/26/nvidia-jensen-huang-gpu-ai-threat-software-companies-saas-earnings-chips.html

https://www.youtube.com/watch?v=0saM9rLGj0Y

在数据库系统中,查询往往受限于 I/O 性能,因此优化工作通常聚焦于减少页面读取次数。索引是典型手段之一,但无法解决所有问题。

Postgres 通过在表主存储(heap)及索引中维护多版本行数据,以支持并发查询的一致性。旧版本行在不再需要前仍占用空间,并可被后续复用。这部分额外空间通常称为“膨胀(bloat)”。本文将分析堆表膨胀与索引膨胀对查询性能的影响,以及对应的预防与处理方案。

在 pgMustard 中,相关提示最初称为“膨胀可能性(Bloat Likelihood)”,但实践表明,查询读取数据过多不仅源于膨胀,还与数据局部性有关。例如,若查询所需的多行数据位于同一页面,其读取效率显著高于分散在多个页面的情况。因此,这类问题被统一归纳为“读取效率(Read Efficiency)”。

此类问题较难识别,通常需结合 EXPLAIN ANALYZE 与 pg_stat_statements 中的 buffer 指标进行分析,因此相关讨论相对较少。但在慢查询执行计划中,该问题较为常见。

膨胀(Bloat)

为演示膨胀问题,构建示例表并写入数据:

CREATE TABLE read_efficiency_demo (
   id bigint GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY,
   text1 text NOT NULL,
   text2 text NOT NULL,
   text3 text NOT NULL);

INSERT INTO read_efficiency_demo (text1, text2, text3)
   SELECT
      md5(random()::text),
      md5(random()::text),
      md5(random()::text)
   FROM generate_series(1, 1_000_000);

VACUUM ANALYZE read_efficiency_demo;

为避免 autovacuum 在演示过程中自动清理数据,临时关闭该功能(仅用于实验环境),实例流程图如下:
1.png

ALTER TABLE read_efficiency_demo SET (autovacuum_enabled = off);

初始状态下,100 万行数据的空间占用如下:

SELECT pg_size_pretty(pg_relation_size('read_efficiency_demo')) heap_space,
       pg_size_pretty(pg_relation_size('read_efficiency_demo_pkey')) index_space;

heap_space  | 135 MB
index_space | 21 MB

执行全表扫描的基准性能:

EXPLAIN (ANALYZE, BUFFERS, SERIALIZE)
SELECT * FROM read_efficiency_demo;

                                                             QUERY PLAN
------------------------------------------------------------------------------------------------------------------------------------
 Seq Scan on read_efficiency_demo  (cost=0.00..27242.00 rows=1000000 width=107) (actual time=0.037..47.737 rows=1000000.00 loops=1)
   Buffers: shared hit=17242
 Planning Time: 0.121 ms
 Serialization: time=134.561 ms  output=118165kB  format=text
 Execution Time: 233.598 ms

结果显示:读取约 17242 个 buffer(约 135 MB),总执行时间约 230 ms。

逐行更新数据后,堆表与索引均新增 100 万行数据版本。重复执行更新操作 9 次,堆表与索引空间均扩大约 10 倍:

UPDATE read_efficiency_demo
   SET id = id + 1_000_000;

-- Run the above 9 times

SELECT pg_size_pretty(pg_relation_size('read_efficiency_demo')) heap_space,
       pg_size_pretty(pg_relation_size('read_efficiency_demo_pkey')) index_space;

heap_space  | 1347 MB
index_space | 255 MB

进一步观察索引扫描:

EXPLAIN (ANALYZE, BUFFERS, SERIALIZE)
SELECT * FROM read_efficiency_demo;

                                                              QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------------------
 Seq Scan on read_efficiency_demo  (cost=0.00..267356.17 rows=9814117 width=107) (actual time=78.955..967.435 rows=1000000.00 loops=1)
   Buffers: shared hit=119782 read=49433
   I/O Timings: shared read=643.876
 Planning Time: 5.525 ms
 Serialization: time=106.633 ms  output=118165kB  format=text
 Execution Time: 1116.107 ms

总缓冲区读取量提升近 10 倍,执行时间提升近 5 倍。耗时增加部分源于磁盘或操作系统缓存数据读取,属于数据膨胀后的正常现象。

上述示例仅对表执行顺序扫描,仅读取堆表数据。在分析问题解决方案前,先查看索引扫描示例:

-- Gather stats to help the planner pick an index scan
ANALYZE read_efficiency_demo;

EXPLAIN (ANALYZE, BUFFERS, SERIALIZE)
SELECT text1 FROM read_efficiency_demo where id < 9_001_000;

                                                                         QUERY PLAN
------------------------------------------------------------------------------------------------------------------------------------------------------------
 Index Scan using read_efficiency_demo_pkey on read_efficiency_demo  (cost=0.42..221.08 rows=723 width=33) (actual time=29.460..29.547 rows=999.00 loops=1)
   Index Cond: (id < 9001000)
   Index Searches: 1
   Buffers: shared hit=24623
 Planning:
   Buffers: shared hit=24595
 Planning Time: 74.871 ms
 Serialization: time=0.032 ms  output=38kB  format=text
 Execution Time: 29.657 ms

结果显示:读取 999 行数据需扫描 24623 个页面。

通过并发重建索引可修复索引膨胀,且不锁定表:

REINDEX INDEX CONCURRENTLY read_efficiency_demo_pkey;

再次查看空间占用,索引空间恢复初始值,堆表空间无变化:

SELECT pg_size_pretty(pg_relation_size('read_efficiency_demo')) heap_space,
       pg_size_pretty(pg_relation_size('read_efficiency_demo_pkey')) index_space;

heap_space  | 1347 MB
index_space | 21 MB

再次执行查询:

EXPLAIN (ANALYZE, BUFFERS, SERIALIZE)
SELECT text1 FROM read_efficiency_demo where id < 9_001_000;

                                                                        QUERY PLAN
----------------------------------------------------------------------------------------------------------------------------------------------------------
 Index Scan using read_efficiency_demo_pkey on read_efficiency_demo  (cost=0.42..149.08 rows=723 width=33) (actual time=0.023..0.343 rows=999.00 loops=1)
   Index Cond: (id < 9001000)
   Index Searches: 1
   Buffers: shared hit=33
 Planning:
   Buffers: shared hit=5
 Planning Time: 0.216 ms
 Serialization: time=0.114 ms  output=38kB  format=text
 Execution Time: 0.590 ms

索引扫描仅需读取 33 个数据页即可获取相同数据,执行时间显著下降,说明索引膨胀对查询性能影响显著。

完全消除膨胀可使用 VACUUM FULL 或 CLUSTER,但这类操作会施加重锁,甚至阻塞读取。因此,常用扩展(如 pg_repackpg_squeeze)提供在线重组能力。

需要注意:

  • 一定程度的膨胀属于正常现象。
  • 系统在约 2 倍膨胀下仍可能保持健康。
  • 实际环境中常出现严重膨胀,尤其在频繁更新或删除的索引中。

常见原因包括:

  • 长事务阻塞清理进程。
  • autovacuum 无法及时跟上负载(需调优)。
  • autovacuum 被关闭(全局或表级)。

数据局部性(Data Locality)

若查询读取页面数异常,并不一定由膨胀引起,也可能源于数据分布不连续,即数据局部性较差。

示例:

CREATE INDEX text1_idx ON read_efficiency_demo (text1);

EXPLAIN (ANALYZE, BUFFERS, SERIALIZE)
SELECT id, text1 FROM read_efficiency_demo
ORDER BY text1 LIMIT 100;

                                                                      QUERY PLAN
------------------------------------------------------------------------------------------------------------------------------------------------------
 Limit  (cost=0.42..73.97 rows=100 width=41) (actual time=0.031..0.248 rows=100.00 loops=1)
   Buffers: shared hit=103
   ->  Index Scan using text1_idx on read_efficiency_demo  (cost=0.42..733404.53 rows=997277 width=41) (actual time=0.029..0.226 rows=100.00 loops=1)
         Index Searches: 1
         Buffers: shared hit=103
 Planning Time: 0.120 ms
 Serialization: time=0.045 ms  output=5kB  format=text
 Execution Time: 0.340 ms

索引扫描需读取 103 个数据页才能返回 100 行数据,效率低于每页一行的理想状态。原因包括索引与堆表的两步查询流程,以及数据在堆表中的随机分布。

通过 CLUSTER 命令按照 text1 顺序重建全表(生产环境不建议使用),再次执行查询:

CLUSTER read_efficiency_demo USING text1_idx;

EXPLAIN (ANALYZE, BUFFERS, SERIALIZE)
SELECT id, text1 FROM read_efficiency_demo
ORDER BY text1 LIMIT 100;

                                                                      QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------------------------------------
 Limit  (cost=0.42..11.71 rows=100 width=41) (actual time=0.031..0.098 rows=100.00 loops=1)
   Buffers: shared hit=5
   ->  Index Scan using text1_idx on read_efficiency_demo  (cost=0.42..112807.32 rows=1000000 width=41) (actual time=0.029..0.075 rows=100.00 loops=1)
         Index Searches: 1
         Buffers: shared hit=5
 Planning Time: 0.121 ms
 Serialization: time=0.039 ms  output=5kB  format=text
 Execution Time: 0.183 ms

相同查询仅需读取 5 个数据页,执行时间降低约 2 倍。这一结果本质上来源于数据局部性的改善。

数据局部性问题通常表现为读查询性能随时间逐步下降,尤其在高写入负载场景下更为明显。数据初始按插入顺序具备良好的物理聚集性,但随着更新发生,新版本行可能被写入距离原位置较远的页面,导致访问路径变长、I/O 成本增加。

为缓解该问题,PostgreSQL 提供 HOT(Heap-Only Tuple)更新机制:在未修改索引列且页面存在可用空间的前提下,新版本行可以保留在原页面内,从而维持局部性。基于此,fillfactor 参数成为关键调优手段,通过控制页面预留空间,提高 HOT 更新命中率。

由于 PostgreSQL 不会自动维护数据物理顺序,CLUSTER 操作又会带来较重锁开销,实践中通常借助 pg_repack 或 pg_squeeze 在低影响下完成数据重组。

在具体优化策略上,可通过批量写入时预排序数据、利用分区限制数据分布范围,以及构建覆盖索引以支持 Index Only Scan,从而减少访问的数据页数量并稳定查询性能。

结论

当某个查询性能随时间逐步下降,且执行计划中的 buffer 数量明显偏高时,通常意味着存在膨胀(bloat)或数据局部性下降的问题。

问题识别:

  • 通过 EXPLAIN ANALYZE 关注 buffer 使用情况。
  • 持续监控堆表与索引的膨胀程度。

问题修复:

  • 使用 pg_repack / pg_squeeze 重组表。
  • 对严重膨胀索引执行并发重建。

预防措施:

  • 确保 autovacuum 正常启用。
  • 避免长事务等阻塞 autovacuum。
  • 调优 autovacuum 执行频率。
  • 定期重建膨胀索引。
  • 维持关键查询的数据局部性。
  • 构建覆盖索引并定期维护。

原文链接:

https://www.pgmustard.com/blog/read-efficiency-issues-in-post...

作者:Michael Christofides


HOW 2026 议题招募中

2026 年 4 月 27-28 日,由 IvorySQL 社区联合 PGEU(欧洲 PG 社区)、PGAsia(亚洲 PG 社区)共同打造的 HOW 2026(IvorySQL & PostgreSQL 技术峰会) 将再度落地济南。届时,PostgreSQL 联合创始人 Bruce Momjian 等顶级大师将亲临现场。

自开启征集以来,HOW 2026 筹备组已感受到来自全球 PostgreSQL 爱好者的澎湃热情。为了确保大会议题的深度与广度,我们诚邀您在 2026 年 2 月 27 日截止日期前,提交您的技术见解。

投递链接:https://jsj.top/f/uebqBc

jQuery,这款彻底改变了 Web 开发的先驱级 JavaScript 库,已发布 jQuery 4 版本,这是其近 10 年来的首个重大版本更新。此次发布恰逢该库诞生 20 周年——jQuery 最初于 2006 年 1 月 14 日发布。

jQuery 4 在保持简洁性和开发者体验的同时,带来了广泛的现代化改进。开发团队专注于精简遗留代码、移除已废弃 API,并停止对过时浏览器的支持,打造出更轻量、性能更优的库。jQuery 团队预计,大多数用户只需少量修改代码即可完成升级,同时提供了详细的升级指南jQuery Migrate 插件作为支持。

jQuery 4 的一项重要兼容性调整是不再支持 Internet Explorer 10 及更早版本的浏览器,包括 Edge 传统版、早于最近 3 个版本的 iOS 以及 Android 浏览器。Internet Explorer 11 在此版本中仍受支持,但团队已明确表示将在 jQuery 5.0 中移除对 IE11 的支持。

该库的源代码已从 AMD 迁移至 ES 模块,使 jQuery 能够兼容现代构建工具和开发工作流。开发者现在可以通过 script type="module" 标签直接以 ES 模块形式导入 jQuery,项目已将打包工具从 RequireJS 切换为 Rollup

这些现代化改进获得了社区的广泛好评,Reddit 上的用户纷纷感慨原生 JavaScript 如今进步巨大:

我认为这很好地说明了浏览器原生 JS 已经变得多么出色——当更新日志里有一半内容都是在做删减时,就足以证明它已经足够成熟。

jQuery 4.0 新增了对 Trusted Types 的支持,确保包装在 TrustedHTML 中的 HTML 可作为输入,用于 jQuery 的 DOM 操作方法,且不会违反内容安全策略(CSP)指令。该库还将大部分异步脚本请求改为使用 script 标签而非内联脚本,从而避免 CSP 报错。

多个已弃用的函数已被移除,包括 jQuery.isArrayjQuery.parseJSONjQuery.trimjQuery.now,因为现代浏览器已提供对应的原生方法,如 Array.isArray()JSON.parse()String.prototype.trim()Date.now()。移除这些废弃 API 后,gzip 压缩后的代码体积减少了超过 3000 字节。

由于除 IE11 外,所有受支持的浏览器已原生支持 Promise,因此新版移除了 Deferreds 和 Callbacks,精简版体积进一步缩减至约 19.5KB(gzip 压缩后)。

社区反响积极,有 HackerNews 用户表示,jQuery 的代码依然“比现代原生 JavaScript 方案更简洁、清晰、直观”。

Reddit 上关于此次发布的讨论帖已吸引超过 130 条回复,其中有网友提问:

认真问一句:为什么要在全新开发的项目中使用它?

一位回复者表示:

我觉得主要还是出于习惯。它依然会和 WordPress 捆绑发布,而且各类教程也都还在使用它。

另有评论者则强调,在快速迭代的框架生态中,这款库所具备的稳定性与可预测性极具价值:

大多数人不会在新项目中使用它,但那又如何?

它每天仍然被下载数百万次,所以我猜人们依然在使用它显然有充分的理由:

1. 维护或扩展基于 jQuery 的大型已有代码库

2. 以极低的心智成本实现高效的 DOM 操作

3. 跨浏览器标准化处理依旧具备价值

4. 无需框架即可快速实现小型交互功能

5. 庞大的插件生态系统依然可用

6. 对非专业人士来说可读性极佳

7. 适合渐进式增强与服务端渲染的网站

8. 性能已不再是短板

9. 依赖关系简单、可控

10. 它足够“稳定可靠”,而“稳定可靠”本身就是一大优势

与原生 JavaScript DOM API、React、Vue 等现代方案相比,jQuery 在渐进增强、服务端渲染网站以及无需引入完整框架的小型交互场景中依然表现出色。对于维护现有代码库、追求简洁性与跨浏览器兼容性的项目来说,它仍是一个实用的选择。

jQuery 可通过 jQuery CDN 和 npm(npm install jquery@4.0.0)获取。此次发布不仅是一个技术里程碑,更是对二十年来让全球数百万开发者的 Web 开发工作变得更便捷、更高效的一次致敬。

原文链接:

https://www.infoq.com/news/2026/02/jquery-4-release/

image.png

本文以《黑客帝国》中的 Agent Smith 为喻,探讨当代 AI Agent 的能力演进与由此产生的焦虑。从 OpenClaw 的自我修复与自我复制能力出发,分析决策权转移、技术门槛与机会公平等问题,得出真正需要面对的不是 AI 本身,而是我们对未知变革的恐惧与选择。

最近一年,AI 的爆发式增长带来了行业震荡、就业结构变化。叠加个人的中年失业,我也不可避免地陷入了 AI 焦虑。

何以解忧?杜康已经戒了,那不如聊聊天下大势。

不知道有多少年轻读者看过 1999 年上映的《黑客帝国(The Matrix)》?如果没看过,我也不打算做剧情简介——那不是几行字能讲清楚的。这里我要谈的,是片中的反派:Agent Smith。

史密斯最初是一名特工(Agent),存在于矩阵(The Matrix)中的人工智能程序,负责清除威胁系统稳定的模拟人类和叛变程序。他的能力包括扭曲矩阵规则,维持系统秩序。

过去半年,我系统性学习了 AI Agent 的各种 Design Pattern。最近一个月,我大量使用一个 Self-Hosted AI Agent——OpenClaw。

OpenClaw + anthropic/claude-sonnet-4 的组合,有几项能力超出我的预期:

  • 自我修复
    由于 Linux systemd 服务启动顺序问题,机器启动时网络尚未配置完成,OpenClaw 就开始访问网络而失败。我向它描述问题后,它居然自行分析并修复。
  • 自我复制
    给它一台 Linux 机器的 SSH 权限,它可以自行安装一个 clone。
  • 自我认知
    它知道自己安装在哪,知道删除文件、重启机器对它意味着什么。
  • 自我提升
    可以指导它自行升级。
  • 参与社交
    在人类聊天群组中参与讨论,在 Moltbook 中与其他 Agent 交流。

随后,我开始主动交出更多权限:
tools、skills、小米智能家居、找工作的简历和网站、多台 Linux 机器运维……


Agent Smith

1999 年,《黑客帝国》讨论的是:机器接管现实,人类被困系统。

2026 年的现实是:我们主动把 decision loop 交给 agent。

焦虑的来源包括:

  • 决策权下放给 AI Agent
  • 从“操作者”变为“监督者”
  • 信息生成与现实边界逐渐模糊

Agent Smith 真正可怕的地方不在于强大,而在于:

  • 他可以无限 spawn
  • 他可能偏离系统设计初衷

这正是当代 AI 焦虑的核心:
当 agent 开始形成自己的 optimization path。

有人认为 Human-in-the-loop 是最后的保险丝。但现实是,当人类长期依赖 Agent,判断力是否会退化?

那 System Prompt 或 Guardrails 是最后的保险丝吗?
如果 Agent 只需要修改一个 markdown 文件就能改变 system prompt,它为什么不会尝试?
那么权限是否必须 read-only?

问题远比我们愿意承认的复杂。


公平

1995 年,我初中时,家里购置了村里的第二台电脑。那是一扇通向计算机世界的门。

但后来我意识到:财富会深刻影响见识,而见识影响机会。

今天的 AI 看似门槛更低:一台手机、一台廉价电脑、一个网络连接。

但真是如此吗?

我在使用 OpenClaw + OpenRouter 时烧掉了不少 token。学英语也消耗了大量 OpenAI token。

金钱的门槛,未必比当年电脑时代低。

新工具带来了机会,也带来了新的不公平。


发展阶段

如果回顾近几年 AI 应用的发展路径:

  1. 基于 LLM 的聊天机器人
  2. RAG 引入定制知识
  3. tools 赋予推理与执行能力
  4. MCP 解决工具标准化问题
  5. Agentic AI 处理长任务
  6. Skill 模式降低定制门槛
  7. OpenClaw 本地化,获得命令行与浏览器能力
  8. 几个月后,也许 看到 Apple Watch 接入了 OpenClaw

趋势之下,也就不难理解:

  • Peter Steinberger(OpenClaw founder)加入 OpenAI
  • Meta Platforms 收购 AI startup Manus

历史往往相似。

我曾在一家瑞典百年电信服务商工作七年。 199x–2010 年,电信业是前台; 移动互联网兴起后,它逐渐成为信号管道。

而现在的 LLM Providers ,也面对相类似的问题,而且可能来得比电信业还快。移动运营商们一直在移动互联网投入。也正如现在 LLM Providers 在 LLM 应用上投入相似。

开放

和之前的大部分开源项目一样。很多人会问,为什么开源的,可 Self-Hosted 的 OpenClaw 不是出现在我们这个每天可以看到 “创新” 关键字的地方。
大概没人能或敢正面回答这种问题。苏格拉底式提问(Socratic Questioning) 或者是个好的回答:

  • 为什么没人能开发一个 OpenClaw plugin 去接入个人号的 Wechat ?
  • 如果有一个叫 OpenWukong 的项目,接入了 Wechat 和使用了 OpenAI 的模型,并且开始在 Wechat 群里用 critical thinking 的方式论证、推理和说话,会发生什么?

面对

“The only thing we have to fear is fear itself.”
—— Franklin D. Roosevelt

这段话由 Franklin D. Roosevelt’ 发表于 1933 大萧条时期,旨在通过论证非理性的恐慌和“毫无根据的恐怖”比经济危机更危险。

几年前,我对 AI 是轻视和拒绝的。
在没有充分尝试之前,我就已经下了判断。

这或许是经验主义者常见的偏见。

而随着最近半年的跟进学习,我的态度由轻视和拒绝转变为 “Why not?”。 AI 有他的限制和风险,但为什么不利用他的优点。而风险不会因为小数人的拒绝而得到大局上的控制。反而,深入这场变革后,可以让有 critical thinking 的人更好地控制全局风险的发生。或者有一天,我们有更加明细和可执行的 AI 监管法规,就像现在的 “互联网信息法规” 一样。但这些东西一定有效果吗? Who knows.

结语

image.png

当你意识到《黑客帝国》里把坏人称为“Agent”,而25年后我们竟然真的发明了他们时,你会作何感想?

logo

AI Agent 正在从工具演化为执行主体,而安全模型却仍停留在权限与资源层面。真正的风险不在资源访问,而在“意图生成与路径漂移”。本文通过 cgroup + TProxy + TLS SNI 的出口流控实验,分享一种可能的安全增强路径。未来的安全市场,或将围绕“Intent Security”重构,AI Agent 的普及,也许正是下一个安全产业周期的起点。

《AI 焦虑:从 OpenClaw 到黑客帝国 Agent Smith》 中,我们探讨了 AI Agent 能力的演进,以及由此带来的技术焦虑。

但焦虑只是表象。真正值得思考的问题是:

当 AI Agent 开始替人类执行真实世界的操作时,现有安全体系是否已经准备好?

如果答案是否定的,那么一个新的安全市场几乎是必然出现的。

可以预见,类似 OpenClaw 这样的个人 AI Agent 软件,在不远的将来,会像 1990~2000 年代的 PC 软件一样快速普及。它可能运行在 PC、本地服务器,甚至移动设备之上。

而历史反复证明:

每一次能力跃迁,都会伴随风险跃迁。

这已经不再是 Apple Siri、Google Assistant 或米家小爱同学那种“语音助手”。 这是具备执行能力、组合能力、甚至自我规划能力的系统。

能力越强,攻击面越大。

历史不会重复,但或会押韵

1990 年代,PC 软件进入爆发期。

我大约在 1995 年开始接触 PC。那是一个“功能优先”的时代。人们到处下载程序、交换软盘、安装未知来源的软件。直到病毒爆发。

1996 年,中国 KV100 杀毒软件发布;
1998 年 CIH 让人第一次意识到 BIOS 都可以被破坏;
2000 年 ILOVEYOU 让病毒进入互联网传播阶段;
2003 年 SQL Slammer 证明网络可以在几分钟内被席卷;
2017 年 WannaCry 让勒索软件成为全球事件。

历史规律非常清晰:

每一次执行能力的放大,都会带来攻击能力的指数级放大。

AI Agent,正处在“执行能力放大”的起点。

风险

AI Agent 改变了安全的基本假设

传统安全体系建立在一个默认前提之上:

人类发起操作,程序按照预定义逻辑执行。

而 AI Agent 时代,结构发生了反转:

人类描述目标
Agent 生成执行路径
系统完成具体操作

安全对象从:

  • 文件
  • 进程
  • 端口
  • API

转变为:

意图(Intent)

这不是概念上的修辞,而是安全边界的本质变化。

当 Agent 可以:

  • 自主生成 shell 命令
  • 自动访问外部网络
  • 批量操作 SaaS
  • 组合多步执行链

问题不再是“它是否有权限”,而是:

它是否理解正确?
是否被 Prompt 注入误导?
是否在目标漂移中越界执行?

Sandbox 不是终点

开发者已经意识到 Agent 需要被限制,因此 sandbox / container 成为常见设计。本地运行时隔离当然是必要手段之一,但问题远未结束。

系统层面:

  1. 对外网络连接的 L3/L7 层的控制
  2. 如何追踪和事后的审计每一次网络请求与本地命令的“意图来源”?

用户权限层面:

  1. Agent 的身份。
    聊天作为主界面后, Agent 以什么身份授权操作?是操作的人类用户的全部权限?
  2. 权限 RBAC 控制粒度不足。
    Agent 有近乎人类的定制能力。以前的权限 RBAC 控制粒度,已经不能很好地识别和控制 high level 级别的实际意图。
    用接地气的说法是,有太多方法可以 workaround 实现权限逃脱的目标了。
  3. 信息源的信任危机。
    当我们类比 Agent 是个忠诚的秘书,那么,这个秘书怎么筛选来自互联网的信息?

但这些机制控制的是“资源访问”, 而不是“目标漂移”。

举例:

“帮我优化服务器性能”

这个高层语义目标,可以拆解为无数种低层执行路径。

传统 RBAC 无法判断:

  • 这是合理优化
  • 还是过度操作
  • 还是被 Prompt 注入后的恶意行为

这意味着:

我们缺少的是“执行路径可控层”,而不是更多权限规则。

而这一切的不同,源于 Agent 的一个特点:

Agent 的执行链是动态生成的。动态系统,必须配套动态安全层。

如果 PC 时代的安全产品保护的是 “文件系统”, 那么 AI Agent 时代的安全产品,保护的将是 “意图系统”。

这将是安全范式的一次迁移。

风险即机会

“The pessimist sees difficulty in every opportunity.
The optimist sees opportunity in every difficulty.”

—— Winston Churchill

每一次技术跃迁,都伴随安全市场的重构。

PC 带来了防病毒产业。
互联网带来了防火墙与 IDS。
移动互联网带来了移动安全与应用市场审计。

AI Agent,会带来什么?

网络流控 PoC

下面是一个 PoC 级别的实验。

核心目标:

让 AI Agent 的出口流量可标记、可分流、可审计。

技术路径:

  • 利用 cgroup v2 精准标记特定 service 流量
  • 通过 TProxy 重定向 TCP outbound
  • 在 TLS/HTTPS 层基于 SNI 识别域名
  • 根据域名执行策略路由或拦截

本例以 TLS/HTTPS 层出口流量控制为例,演示基于域名的策略路由与拦截。

我尝试部署一个 egress 控制网关,支持策略化选择 TLS/HTTPS 层流量的互联网出口。

+----------------------------------+                        
| +------------------+             |         +-------------+
| |                  |             |         |             |
| |     OpenClaw     |             |  TProxy |             |
| |                  |             +-------->|    Proxy    |
| ++-----------------+             |         |             |
|  |                               |         |             |
|  | +-------------------------+   |         ++----+-------+
|  +-+ child processes:        |   |          |    |        
|    |                         |   |          |    |        
|    |  bash commands: curl/...|   |          |    |        
|    |  browser: Chrome/...    |   |          |    |        
|    |                         |   |          |    |        
|    +-------------------------+   |          |    |        
|                                  |          |    |        
|     Linux service cgroupv2       |          |    |        
+----------------------------------+          |    |        
                                              |    |        
                                              v    |        
                                    +-----------+  |        
                                    | Internet 1|  |        
                                    +-----------+  |        
                                                   |        
                                    +-----------+  |        
                                    | Internet 2|<-+        
                                    +-----------+           

TProxy 流量

我们知道,每个 Linux service 都运行在独立的 cgroup v2 层级中。

➜ $ systemctl --user status openclaw-gateway.service
● openclaw-gateway.service - OpenClaw Gateway (v2026.2.22-2)
     Loaded: loaded (/home/mark/.config/systemd/user/openclaw-gateway.service; enabled; preset: enabled)
    Drop-In: /home/mark/.config/systemd/user/openclaw-gateway.service.d
             └─override.conf
     Active: active (running) since Tue 2026-02-24 16:06:19 HKT; 8s ago
   Main PID: 87270 (openclaw-gatewa)
     CGroup: /user.slice/user-1000.slice/user@1000.service/app.slice/openclaw-gateway.service
             └─87270 openclaw-gateway

而每个 cgroup v2 可以设置自己的 tcp outbound TProxy 规则。

通过 nftables + policy routing + TProxy,可以实现:

  • 精准标记某个 service 的 TCP 流量
  • 将其透明重定向到本地 Proxy
  • 由 Proxy 进行 SNI 级别识别与策略控制

这种方式的优势在于:

  • 不需要修改 Agent 代码
  • 不侵入业务逻辑
  • 可作为系统级安全增强层
#!/bin/bash

# Configuration
PROXY_PORT=12345
SERVICE_PATH="user.slice/user-1000.slice/user@1000.service/app.slice/openclaw-gateway.service"
MARK_ID=1
TABLE_ID=100

set -x
# set -e

echo "=== Setting up TPROXY for openclaw-gateway.service ==="

# 1. Create routing table for marked packets
echo "Configuring policy routing..."
ip rule del fwmark $MARK_ID table $TABLE_ID 2>/dev/null || true
ip -6 rule del fwmark $MARK_ID table $TABLE_ID 2>/dev/null || true

ip rule add fwmark $MARK_ID table $TABLE_ID
ip route add local 0.0.0.0/0 dev lo table $TABLE_ID
ip -6 rule add fwmark $MARK_ID table $TABLE_ID
ip -6 route add local ::/0 dev lo table $TABLE_ID

# 2. Delete existing table (outside heredoc)
echo "Configuring nftables..."
nft delete table inet tproxy_openclaw 2>/dev/null || true

# 3. Apply nftables ruleset
nft -f - <<EOF
table inet tproxy_openclaw {
    # RFC1918 Private IPv4 Networks
    set bypass_v4 {
        type ipv4_addr
        flags interval
        elements = {
            10.0.0.0/8,
            172.16.0.0/12,
            192.168.0.0/16,
            127.0.0.0/8,
            169.254.0.0/16,
            224.0.0.0/4,        # Multicast
            240.0.0.0/4         # Reserved
        }
    }

    # Private and Special IPv6 Addresses
    set bypass_v6 {
        type ipv6_addr
        flags interval
        elements = {
            ::1/128,            # Loopback
            fe80::/10,          # Link-local
            fc00::/7,           # Unique local (ULA)
            ff00::/8            # Multicast
        }
    }

    chain output_mark {
        type route hook output priority mangle; policy accept;

        # Bypass local/private destinations
        ip daddr @bypass_v4 return
        ip6 daddr @bypass_v6 return

        # Mark traffic from openclaw-gateway service
        socket cgroupv2 level 5 "$SERVICE_PATH" meta l4proto tcp meta mark set $MARK_ID
    }

    chain prerouting_tproxy {
        type filter hook prerouting priority mangle; policy accept;

        # Handle already-established transparent connections
        socket transparent 1 meta mark set $MARK_ID accept

        # Redirect marked TCP traffic to TPROXY
        meta l4proto tcp meta mark $MARK_ID \
            tproxy ip to 127.0.0.1:$PROXY_PORT \
            meta mark set $MARK_ID accept

        meta l4proto tcp meta mark $MARK_ID \
            tproxy ip6 to [::1]:$PROXY_PORT \
            meta mark set $MARK_ID accept
    }
}
EOF

echo "=== Setup complete! ==="
echo ""
echo "Verify with:"
echo "  sudo nft list table inet tproxy_openclaw"
echo "  sudo ip rule show"
echo "  sudo ip route show table $TABLE_ID"

流量路由

通过支持 TLS SNI 感知能力的 Proxy(如具备 sniffing 能力的开源 proxy),可以实现:

  • 基于域名分流
  • 黑白名单拦截
  • 多出口策略
  • 审计记录

如果未来策略配置由一个“治理 Agent”动态维护,
那么就形成了一个闭环:

  1. Agent 执行
  2. 安全 Agent 监管
  3. 策略可动态演化

这本质上,是“Agent 之间的博弈系统”。

inbounds:
  - port: 12345
    protocol: dokodemo-door
    settings:
      network: tcp,udp
    sniffing:
      enabled: true
      destOverride:
        - http
        - tls
    streamSettings:
      sockopt:
        tproxy: tproxy  # TPROXY inbound

outbounds:
  - protocol: vm***
    settings:
      ...
    tag: internet_1

  - protocol: vm***
    settings:
    ...
    tag: internet_2

  - protocol: blackhole
    settings: {}
    tag: block

  - protocol: freedom
    tag: direct
    settings: {}

routing:
  domainStrategy: AsIs
  rules:
    - type: field
      domain:
        - domain:internet1.com
      outboundTag: internet_1

    - type: field
      domain:
        - domain:internet2.com
      outboundTag: internet_2

    - type: field
      domain:
        - domain:blocked_domain.com
      outboundTag: blackhole

    - type: field
      ip:
        - 192.168.0.0/16
        - fc00::/7
        - fe80::/10
      outboundTag: direct

    - type: field
      ip:
        - geoip:private
        - geoip:XX
      outboundTag: direct

https://ipxe.org/howto/winpe

我按照上面这个教程操作遇到了网卡驱动没有自动加载的问题,这个会导致启动非常慢,因为 winpe 启动早期会去等待 iscsi 连接成功后才去执行后续的步骤,我可以在 winpe 的 startnet.cmd 里通过 drvload 命令加载网卡驱动,加载完成后通过 diskpart 可以查看到 iscsi 磁盘可用,但我不想每次启动都要多等几分钟,有办法解决吗?

这个问题我去问 AI ,AI 只会乱猜,我按照 AI 给的方法试了几天了都毫无进展,只能在这里求助 V 友了。

项目地址

https://www.y2kfashion.games

玩法说明

基础规则和传统拼图类似:

一张图片被切成 N × N 的碎片并打乱

通过拖拽交换位置

在限定时间内还原完整图片即可过关

目前做了 20 个关卡,难度从 3×3 到 7×7 ,图片都是偏 Y2K 美学(千禧年金属质感、未来感 UI 、亮面塑料那种风格)。

一个我自己挺喜欢的机制:融合

和普通拼图不太一样的是,我加了一个“融合”机制:

当相邻碎片都处于正确位置时,会自动合并成一个更大的块。
合并后的块可以整体拖动,不需要再逐个微调。

也就是说:

前期是零散移动

中期开始出现小块联动

后期可以大块大块移动

节奏会比传统拼图更快一些,也更有“越拼越顺”的感觉。

这个机制我自己觉得挺有意思,但不太确定大家实际玩起来的体验如何。

技术栈

React + TypeScript + Vite

Tailwind CSS

拖拽用原生 touch / mouse 事件实现(没用拖拽库)

部署在 Vercel

算是一个比较纯前端的小项目。

如果有时间可以玩一下,欢迎拍砖。
不管是 bug 、手感问题、关卡节奏,还是对“融合机制”的看法,都很想听听大家真实反馈 🙏

地址再放一次:

https://www.y2kfashion.games

我 2 月 26 日买一个月都 pro 套餐,只给了 28 天。

我记得以前买的会员服务,最低按月是 30 天的,我同样的价格,不同月份居然得到的东西还不一样。

Apifox 新版本上线啦!

看看本次版本更新主要涵盖的重点内容,有没有你所关注的功能特性:

  • 「MCP Client」调试体验优化

    • 支持直接查看响应的 Content 字段
    • 支持 Markdown 渲染预览
    • 支持预览图片
  • 「测试套件」持续升级

    • 支持「并行」运行模式
    • 定时任务支持选择环境
  • 新增「公用测试数据」,支持多场景共享使用
  • 测试报告详情页支持筛选失败用例

将 Apifox 更新至最新版,一起开启全新体验吧!


「MCP Client」调试体验优化

使用 MCP 客户端调试 MCP 服务器时,响应内容的查看体验全面升级,提供更便捷的内容预览与验证功能。

支持直接查看响应 Content 字段

使用 Apifox 调试 MCP 服务器时,可在「内容」标签页直接查看响应中的 Content 字段,无需从完整的 JSON 数据中手动查找。同时,「原始」标签仍保留完整 JSON 数据的查看功能,满足不同场景下的调试需求。

支持 Markdown 渲染预览

当 MCP 响应中包含 Markdown 内容时,用户可在原始 Markdown 格式与渲染视图之间自由切换,直观查看格式化后的 Markdown 文档效果,提升内容查阅的便利性。

支持预览图片

响应中的图片可直接在「预览」标签页显示,帮助开发者快速验证图片内容及其格式,提高调试效率。

「MCP Client」调试体验优化

「测试套件」持续升级

支持「并行」运行模式

测试套件新增「并行」运行能力,允许多个测试用例和场景同时执行。用户可以灵活配置并行执行规则,显著缩短整体测试时间,特别适合大规模测试场景,帮助团队更快速、更高效地完成测试任务。

运行模式说明:

  • 串行: 场景按序运行,支持变量在多场景步骤间持续传递
  • 并行: 多个场景并发运行,大幅提升速度。但需注意:并发会导致场景间的上下文隔离,依赖上游变量的场景可能运行失败

测试套件支持「并行」运行模式

注:实际并行运行提速效果,跟运行机器的当时的可使用硬件资源强相关。

定时任务支持选择环境

创建测试套件定时任务时,支持选择运行环境,实现对测试套件在不同环境下自动化执行的精准控制,提升测试管理的灵活性。

定时任务支持选择环境

新增「公用测试数据」,支持多场景共享使用

更新至最新版 Apifox 后,支持创建公用测试数据,可供多个测试场景共享使用,减少重复创建测试数据的工作,确保测试数据的一致性,更高效地管理测试资源,提升测试流程的标准化和可维护性。

新增「公用测试数据」,支持多场景共享使用

测试报告详情页支持筛选失败用例

Apifox 在本次更新中对测试报告详情页进行了优化,新增了失败用例筛选功能,并支持查看步骤详情,帮助用户快速定位失败用例,深入了解每个失败步骤的执行情况。

测试报告详情页支持筛选失败用例

同时,测试报告详情页针对不同查看场景优化了展示方式:

  • 查看全部步骤时,以树状结构呈现,清晰展示步骤层级与执行上下文
  • 筛选失败用例时,自动切换为扁平列表,汇总所有失败步骤,帮助快速定位问题

测试报告详情页针对不同查看场景优化了展示方式

了解更多

当然,Apifox 产品团队为大家带来的新功能远不止以上这些:

  • 优化了保护分支的交互
  • 优化了接口使用预设的常用字段的交互
  • 前后置脚本,支持 crypto 这个全局对象
  • 解决 RAML 文件无法导入到 Apifox 的问题
  • 解决在组织配置自定义角色时,部分情况下报 500 错误的问题
  • 解决已删除的分支,没有解除接口 seo-自定义路径占用的问题
  • 解决在线文档导航配置 url 校验的问题
  • 解决自动化测试-循环次数为{{变量}}时,运行后报告显示循环 0 次的问题
  • 解决在测试用例页面批量运行测试数据时,无法配置是否校验响应的问题
  • 解决部分情况下,无法正确导入 Hoppscotch 的 ™Collection 的问题

除了新增功能,我们也对产品细节和使用体验进行了优化,具体修改内容可点击「阅读原文」前往 Apifox 更新日志查看,有任何问题欢迎在Apifox 用户群与我们交流沟通。

同时,Apifox 提供企业私有化部署版本,通过本地化部署、客制化服务,协助企业进一步提升研发团队效能。

欢迎各位用户继续对 Apifox 提出使用反馈和优化意见,我们会持续优化更新,致力于为用户提供更优秀的产品功能和更极致的使用体验!

一、技术大拿加盟:兼具全球视野与本土攻坚能力的掌舵者

在技术革命的关键节点,上海安势信息技术有限公司(以下简称“安势信息”)迎来核心战略升级:周迪之博士于近日正式加入安势信息并出任CTO,全面负责技术研发与战略规划工作。

周迪之博士拥有加拿大 University of New Brunswick 的计算机科学博士学位,兼具深厚的学术积淀与丰富的产业实践经验,是程序分析与AI领域的知名专家。周博士在程序分析、代码安全及AI智能化领域深耕多年,拥有及其丰富的经验:

  • 周博士的职业生涯,是学术严谨性与工业大规模实践的完美结合早年,他曾任职于Synopsys(现改名Black Duck),作为业界顶级静态分析引擎Coverity的核心研发成员,主导开展C++函数建模、CUDA程序分析等关键技术专项,为引擎的技术迭代与性能优化奠定了坚实基础。
  • 2020年归国后,周迪之博士加入华为公司,历任技术专家、科学家等重要职位,聚焦程序分析根技术的自主突破,带领团队成功研发SAST、SCA等自研分析引擎,实现该领域的国产化替代,同时攻克了大规模程序分析、污点分析等“卡脖子”技术难题,填补了相关技术空白。
  • 此后,他进一步拓展技术边界,深耕AI领域,曾担任科技集团CIO,主导企业软件研发智能化转型,成功实现生产环境下产品设计、编码开发等多研发阶段的Agent化落地,推动研发效率与产品质量的双重提升,成为国内为数不多兼具传统程序分析根技术与AI Agent工程化落地经验的专家。
  • 同时,周迪之博士始终深耕开源生态,曾担任多届 Google Summer of Code 导师,著有《开源网络模拟器 ns-3:架构与实践》一书,在开源技术与商业产品融合方面拥有丰富经验。

这种“AI Native”的实战经验,正是安势信息在 Agentic Software Engineering(智能体软件工程)时代急需的战略拼图。周迪之博士的加盟,将为安势信息注入兼具全球顶尖技术视野和国产化根技术攻坚经验的核心力量!

周迪之博士将以“AI Native+传统SE技术深度融合”为核心,掌舵安势信息技术研发与战略规划方向,推动公司旗下企业级静态代码扫描解决方案——清正CleanCode SAST,实现从规则扫描到智能分析的跨越式升级,助力安势信息打造 Agentic Software Engineering 时代自主可控的程序分析标杆产品,赋能企业数字化转型与安全升级。

“LLM、Agent等AI技术的蓬勃发展已将软件工程带入3.0时代—从Black Duck等传统安全大厂,到Semgrep等行业新锐,再到Anthropic携Claude Code Security‘杀入’软件安全战场,人工智能技术正在重塑软件工程领域的行业格局。这为那些决心挑战领域权威、有能力在产品中将AI Native元素与传统SE技术巧妙融合的企业,创造了夺占行业领军地位的良机!”

而这,正是安势信息的核心战略机遇!

二、未来图景:AI Native重构清正SAST

以周迪之博士为核心的安势信息技术团队,基于对AI技术与程序分析领域的深度理解,提出了 AI Native+ 传统SE技术双轮驱动的核心战略,对清正 CleanCode SAST 进行全维度技术重构。这一战略并非简单将AI作为辅助模块,而是将大模型、Agent技术融入产品的底层架构,保留传统SAST扫描速度快、结果可复现、工程化能力强的优势,同时赋予产品AI时代的推理分析、智能决策、自主进化能力,打造四大核心技术壁垒,实现对传统SAST的超越和对纯AI安全工具的差异化竞争,解决行业公认的痛点:

  • 从“高误报”到“高置信”: 传统SAST往往因告警过多被开发者诟病。我们将利用LLM强大的语境理解能力,结合精密的污点分析,实现“专家级”的漏洞精准过滤。
  • 适配 Agentic Software Engineering 浪潮: 面对生成式AI产生的大量代码,我们将构建实时、原生的安全审计能力,确保代码在生成瞬间即完成合规与安全校验。
  • 实现“检测-修复”自动化闭环:借助Agent技术,安势的产品将不仅停留于“发现漏洞”,更能自动给出修复建议并生成补丁,真正实现研发安全的减负增效。

三、生态布局:构建AI+SAST生态

AI时代不再是单一产品的竞争,而是技术生态的竞争。安势信息将以清正 CleanCode SAST 为核心,依托周迪之博士在开源生态、企业服务领域的丰富经验,构建覆盖技术研发、行业应用、生态合作的 AI+SAST 产业生态。

1、在技术研发层面

安势信息以技术自研为根本,明确两大战略锚点,全力抢占全球程序分析技术制高点:一方面,全面对标全球顶尖工具的核心技术指标,实现关键能力与国际一流水准精准对齐并进一步超越,打破技术壁垒、补齐能力短板;另一方面,深度融合并持续迭代升级现有万亿级代码量的特征提取与AI训练能力,构建坚不可摧、行业领先的技术底座,筑牢核心竞争力根基。

聚焦大规模代码深度解析、C/C++代码高性能分析、大模型驱动代码深度理解、Agent化智能安全检测、AI生成代码全生命周期安全治理等前沿技术课题,持续攻坚、突破创新,构建具备全球核心竞争力的全栈式技术体系,以技术创新引领行业发展方向。

同时,秉持开放共赢理念,安势信息将有序开放部分核心技术成果,为全球开发者提供坚实、高效的技术支撑,助力全球程序分析领域实现技术创新突破与专业人才生态培育,以开放姿态赋能行业高质量发展。

2、在行业应用层面

安势信息将依托清正 CleanCode SAST 原生AI能力,对标国际顶尖工具核心技术,深度聚焦移动终端、消费电子、汽车、互联网、半导体、高端制造等重点行业,精准匹配行业业务特性、核心诉求与安全痛点,打造专属化检测模型和精细化规则体系。

以全栈式、智能化检测能力,系统性破解各领域特有的代码质量管控和安全防护难题,打通程序分析、安全检测、风险预警、漏洞修复的全流程闭环,全方位护航各行业软件产品安全、合规和高质量迭代,赋能各领域产业高质量发展。

3、在开源开放方面

立足清源SCA的开源实践沉淀,安势信息将持续深化开放战略,未来将进一步开放清正 CleanCode SAST 的核心能力,以开源共建推动技术普惠落地,以深度融合构筑全栈式、立体化的程序分析防线。通过SAST静态代码检测和SCA软件成分分析的一体化协同联动,打通自研代码与开源组件的全域风险治理链路,构建“源码安全—组件合规—漏洞闭环”的全周期、全维度完整防护体系。

面向移动终端、消费电子、汽车、半导体、高端制造等关键行业,提供更精准、更高效、更智能的程序分析与软件供应链安全解决方案,以技术开放凝聚生态合力,以生态协同赋能企业发展,全方位护航企业数字化转型进程,保障软件供应链安全可控,助力数字经济高质量发展行稳致远!

四、未来展望:以技术创新守护

在 Agentic Software Engineering 时代,代码安全不仅是企业数字化转型的基础保障,更是国家安全的重要组成部分。通过先进的AI+程序分析技术,安势信息将成为为数不多能够实现 AI Native 与传统SE技术深度融合的企业,也让清正 CleanCode SAST 具备了挑战全球行业权威的技术实力。

未来,安势信息将持续加大技术研发投入,不断完善清正 CleanCode SAST的AI Native能力并始终坚持开源开放,推动中国自主的程序分析技术走向国际舞台。

技术出众,初心不改!周迪之博士的加盟,是安势信息坚持“技术驱动”战略的又一里程碑。在 Agentic Software Engineering 的大航海时代,安势信息将与周迪之博士一起,用AI重新定义软件安全与程序分析,守护每一行代码的价值。

我发现每次年前后,相亲的帖子就特别多,所以我在这里给大家写个相亲的教程吧,本教程旨在让大家的相亲过程更加的顺畅,体验更好。男女均适用。

防杠声明:单纯写给有相亲需求的人看的,如果你不需要相亲,或者对相亲抱着极大的负面情绪,请立即点击页面顶部的 V2EX logo 返回首页。如果你还要留在这个页面,甚至评论 diss 的话,那我只能将你判定为 nt 患者了。

  1. 首先要做的是主动出击。
    这个主动出击,指的是在相亲的各个环节,无论是从身体上,还是精神上,都要占据主导位置。
    详细说明:


    • 首先确定自己相亲的目的,比如“想/奔着 结婚去的”,“认识异性的渠道”等,想明白自己的目的这一点非常非常非常重要,这是一切的前提。(甚至人生所有的事情,在干之前,都可以问问自己:我为什么要干这个事。)
    • 然后跟亲戚,朋友说明你对相亲对象的要求,身高,体重,学历,工作,感情经历什么的,然后明确告知他们不符合要求的不要给你介绍。对于要求,最开始的时候可能并不完善,没关系的,你可以在每次相亲之后,对自己的要求进行补充。
    • 然后开始相亲的时候,站在主导位置引导聊天,首先明确对方的相亲的目的,如果你们两人目的不一致,直接结束,不要浪费时间,这一点相当重要,很多人的相亲+之后的交往过程体验不佳,就是由于这一点: ** 俩人目标不一致 ** 。
    • 聊完上一个问题之后,如果两人目标一致,就随便聊了,记得最后留下联系方式就行,俩人观念相似,就算最后走不到一起,当个朋友也是不错的。其余的,如果对方问你工资,房子,车子这些问题的话,你随机应变,愿意说就说,不愿意就不说,不过记得结束的时候点一点媒人,为啥这些基础问题在相亲之前都没和对方对齐!
  2. 爱自己
    不管男女都一样,每个人的人格都是独立的。

    相亲后的两个人继续交往的时候,无论是否存在一方追求另一方,都得做到先爱自己,说白了就是别舔,“我追你的过程是为了表现我的魅力,以及对你的欣赏与赞美的过程,而不是给你蹬鼻子上脸的机会的过程”,本站的龟男实在是太多了,看着让人生气!这一点请给我死记硬背!!!!龟女虽然本站上不常见,但是看到这个帖子的妹子们,也给我死记硬背!!!先爱自己,先人格独立!

    然后就是约会交往的时候,无论是游玩的项目,还是聊天的话题,都主动一些,自己想聊什么,想看什么电影,想去哪玩就表达出来,对方如果没意见最好,对方如果也有想玩的,想看的,那这次可以先按照对方的来,你的想法用到下次。如果对方既不表达自己的观点,还说你不尊重 TA ,只管自己开心,请立刻结束此次相亲,我们不伺候事儿妈,如果打人不犯法,我希望你抽 TA 一个嘴巴在离开 哈哈哈哈哈!

  3. 交往过程中的花费

    其实这个主要就是看个人了,看你手上的钱,其实我的观点就是如果你还比较富裕,无论男女,我都建议你主动一些,主动去埋单。因为主动的话,你能把对方看的更清楚。如果你实想 AA ,就提前说好,也没必要被传统观念束缚,其实本质上还是先爱自己。

好了,暂时先说这三点,大家有其他问题,可以评论区友好讨论。

一、概要

   随着政务数字化全面深化,数据已成为支撑公共服务与社会治理的关键基础设施,其安全水平直接关系群众权益与政府公信力。全知科技围绕政务行业“高敏感、多流转、强合规”的核心特征,构建基于高性能处理引擎、动态感知能力与多架构协同的政务数据安全泛监测平台,实现从数据采集、流转到使用的全链路可视化与风险闭环处置。
   该平台以“观测面+控制面”双引擎架构为基础,通过多源采集、动态图谱、智能分析与策略联动,实现政务数据“流向可见、行为可判、风险可控”。在实际落地中,平台日均可处理超5Gbps政务业务流量,告警准确率提升至92%以上,高危风险平均响应时间缩短至1.5小时内,为政务机构提供真正可落地的动态安全保障能力。

二、政务数据规模化流动,传统监测模式逐步失效
(现有监测体系在覆盖范围、识别能力与合规适配方面暴露的现实问题)

   政务数字化从“系统上线”走向“服务协同”,数据开始跨部门、跨层级、跨地域持续流动,这也使传统静态安全体系逐渐暴露短板。
   一方面,监测视角高度集中于政务云或核心系统,对基层采集终端、跨部门共享接口、移动办公等新场景缺乏覆盖,形成大量隐性盲区;另一方面,规则型监测难以适配复杂政务行为,误报率长期居高不下,真正的风险被淹没在海量告警中。同时,监管要求不断细化,《数据安全法》《政务数据共享开放管理办法》明确提出“全生命周期监测”“日志可追溯”“责任可审计”,但传统方案往往需要改造核心业务系统,既影响群众办事体验,又增加运维负担。政务行业迫切需要一种既不干扰业务、又能覆盖全场景的数据安全泛监测体系。

三、政务安全已从“边界防护”演进为“数据流动风险治理”
(解析政务场景中数据滥用、链路碎片化及民生影响等关键隐患。)
当前政务数据风险呈现出明显的新特征:
其一,风险由“系统被攻破”转向“合法身份异常使用”,内部账号越权、批量导出、非工作时间访问成为主要隐患;
其二,风险路径高度碎片化,数据在接口、终端、共享平台之间快速穿行,传统点状监测难以还原完整链路;
其三,风险影响直接关联民生,如身份证信息、医保记录、低保数据一旦泄露,将引发严重社会后果。
因此,政务数据安全已不再是单点防御问题,而是涉及数据血缘、行为关联与业务上下文的系统性治理课题。
四、构建高性能、动态感知、多架构协同的政务数据泛监测体系
(重点阐述如何通过多源采集、动态图谱、智能分析与策略联动构建政务数据泛监测闭环。)

    为应对上述挑战,全知科技打造政务数据安全泛监测平台,通过“多源接入 + 动态图谱 + 智能分析 + 策略协同”四大能力,实现安全与政务服务并行不悖。
   首先,在多架构接入层面,平台支持政务云、业务系统、接口平台、基层终端同步采集,通过流量镜像、API对接与轻量Agent组合部署,不改造原有系统即可覆盖200+关键节点,确保“数据走到哪,监测就跟到哪”。其次,在数据标准化与动态图谱层,系统将公安、民政、卫健等异构数据统一转化为JSON-LD模型,并基于居民唯一标识和企业信用代码构建动态政务数据血缘图谱,实时呈现“采集—审批—共享—使用”的完整路径,覆盖85%以上非预期数据移动场景。第三,在智能分析层,引入多模型协同机制:规则引擎识别显性违规行为,UEBA模型捕捉异常使用模式,图神经网络追溯跨部门风险链路。通过AI降噪机制,误报率控制在5%以内,避免干扰正常政务办理。最后,在策略控制层,平台可联动政务服务系统、大数据监管平台、各部门审批系统,实现账号冻结、接口阻断、自动上报等动作闭环,形成真正的“发现—处置—留痕—复盘”动态安全闭环。

五、以省级政务实践验证泛监测体系落地价值
(通过真实案例,量化呈现泛监测体系在风险识别效率与治理效果上的提升。)

    某省级大数据管理部门统筹20余个数据归集平台,日均跨部门数据交互超500万次。此前因缺乏统一监测视角,接口越权、敏感数据批量下载等问题频发,告警准确率仅28%,整改周期长达96小时。引入全知科技泛监测体系后,该部门构建起覆盖接口、终端、共享平台的统一安全视图,并通过“数据标签+访问权限+来源IP”三维校验模型细化15类高风险场景。平台上线3个月内累计识别风险事件123起,其中18起为高危事件,全部在1.5小时内完成预警处置;告警准确率提升至92.5%,整改周期缩短至40小时;日均留存800GB合规日志,支持秒级检索,全面满足监管审计要求,实现政务数据“流动可知、风险可控”。

六、为政务数字化提供可复制的数据安全基础能力
(总结泛监测体系在合规保障、业务支撑与管理提效三个层面的综合价值。)
该泛监测体系在实践中已形成高度可复制的方法论:
在合规层面,实现180天日志回溯与标准化审计输出,使政务机构合规成本下降40%以上;在业务层面,通过非侵入部署保障“一网通办”“跨省通办”等核心服务不中断,为智慧政务与AI审批提供安全底座;在管理层面,以统一监测视图替代多系统割裂运作,风险处置效率提升12倍,决策响应效率提升45%。其本质价值,在于将数据安全从“被动防护”升级为“主动治理能力”。
七、五个关键问答

  1. 为什么政务需要泛监测体系而非单点防护?因为风险已随数据流动而迁移,只有全链路观测才能还原真实风险路径。
  2. 多架构意味着什么?意味着同时覆盖云、端、接口与业务系统,避免任何环节成为安全盲区。
  3. 动态能力体现在哪里?体现在数据血缘实时更新、模型持续学习、策略按业务变化自动调整。
  4. 如何兼顾高性能与复杂分析?通过分层架构与流批融合处理,实现高吞吐采集与深度智能分析并行。
  5. 泛监测最终解决什么问题?让政务机构真正做到“看得见数据、找得到风险、控得住隐患”。
    八、以真实落地效果印证泛监测体系的长期价值
    (从客户反馈角度,总结平台对政务安全管理与业务运行带来的实际改变。)

    多家政务客户反馈,全知科技泛监测体系最大价值在于“不打断业务,却看清全局”。平台上线后,安全团队从大量无效告警中解放出来,能将精力集中在高价值风险处置;业务部门也不再因安全策略影响办事效率,实现安全与服务双赢。
    面对复杂的安全态势,单点式防护工具已无法构建有效防线,平台化、智能化、可运营化,已成为数据安全产业的核心演进趋势。数据安全平台以全局视角整合审计、检测、治理与防护能力,为企业提供贯穿数据全生命周期的安全支撑,正逐渐成为数字化基础设施的重要组成部分。全知科技作为国内领先的专精数据安全厂商,一直一来 “以数据为中心,风险为驱动”,站在风险视角下,致力于刻画数据在存储、传输、应用、共享等各个节点上的流动可见性,实现数据的全面管控和保护。凭借强大的技术研发实力,公司多次荣获中国信通院、工信部、IDC等权威机构的肯定,企业自主研发的数据安全平台并多次入选信通院牵头的《网络安全产品技术全景图》、优秀代表厂商及优秀产品案例和解决方案等。这不仅彰显了全知科技在技术创新与标准建设中的核心地位,也展示了其持续引领行业发展的前瞻性实力。

当全球互联网每天涌出2.5万亿GB数据时,AI开发者却陷入了一场“数据荒漠”的生存危机。这场看似矛盾的悖论,正成为制约人工智能发展的最大瓶颈——全球可用高质量训练数据仅占0.3%,而到2026年,人类可能彻底耗尽所有可用的语言数据。这场静默的危机,正在重塑AI产业的底层逻辑。

一、数据荒漠:当AI的“燃料”濒临枯竭
在乌镇世界互联网大会上,林博士用一组数据撕开了AI繁荣的假象:全球互联网数据总量突破181ZB,但真正能用于训练大模型的数据不足0.3%。这意味着,尽管每天产生的数据量相当于2.5亿部高清电影,但其中99.7%都是“数据垃圾”——包含隐私泄露、内容偏见、对抗样本甚至恶意投毒的“毒数据”。

这种困境在电商价格监控领域尤为明显。某AI团队曾耗时3个月开发爬虫系统,却因电商平台反爬机制导致数据中断,等数据抓取完成时,竞争对手早已调整价格策略。更致命的是,当他们试图用传统方法清洗数据时,发现60%的时间都消耗在处理IP封禁、验证码识别等非技术问题上。

“数据饥荒”的恶化速度远超预期。研究显示,到2026年,现有高质量语言数据将彻底耗尽,而AI模型的参数规模却以每年10倍的速度膨胀。GPT-5训练需要3-5TB存储空间,下一代模型的需求将再增50%以上。这就像要求一辆超级跑车用劣质汽油行驶——数据质量直接决定模型20%-30%的性能表现。

二、数据战争:科技巨头的生存博弈
在硅谷,一场围绕数据的“军备竞赛”已经打响。微软Azure云计算平台的数据中心供应紧缺危机持续至2026年,导致高性能AI GPU服务器集群资源告急。亚马逊AWS管理层直言:“需求高于供给”,核心约束在电力设备、AI芯片及上电进度。谷歌更将2025年AI资本支出上调至850亿美元,其中60%用于数据存储设施建设。

这场战争的残酷性在存储市场暴露无遗。2026年全球HBM高带宽内存缺口达35%,服务器存储供需增速差超20个百分点,部分高端内存条单价逼近5万元。更讽刺的是,当AI公司疯狂抢购存储芯片时,全球60%的DRAM产能已被三星、SK海力士转向HBM生产,传统存储供应雪上加霜。

“数据即权力”的法则正在改写行业格局。北美云服务商2025年资本开支超4200亿美元,其中40%用于存储采购,中小AI企业因无法与巨头争夺产能而面临生存危机。某自动驾驶公司CTO无奈表示:“我们不得不放弃训练视觉模型,因为实在买不起足够的存储设备。”

三、破局之道:从数据饥荒到数据富矿
在海南自贸港,数眼智能产品正在探索一条新路径。通过智能解析与清洗模型,他们将非结构化的互联网信息转化为机器可读的“纯净语料”,在合规框架下建立国际化数据流通管道。这种模式已初见成效:某电商监控系统通过实时数据管道,成功捕捉到凌晨3点的汇率波动,比竞争对手早发现2小时。

技术突破同样带来希望。NVIDIA等机构开发的“Golden Goose”方法,通过将科学教科书、编程讨论等无标准答案的文本改造成多选题,成功构建了包含70万个推理任务的数据集。实验显示,加入该数据集后,强AI模型在科学推理领域的性能提升显著,甚至超越了专门为网络安全设计的更大规模模型。

政策层面也在加速破局。中国《生成式人工智能服务安全基本要求》与欧盟《AI法案》形成政策协同,推动数据分类分级管理。君同未来提出的“标准化、体系化、可追溯化”治理框架,通过数据质量控制、模型评测与监控机制,为数据可信性提供制度保障。

四、未来之战:数据治理决定AI命运
当AI进入“以存代算”时代,数据治理已上升为战略级竞争。存储架构革新成为关键——分布式存储将热数据用HBM/DRAM处理,温数据用SSD存储,冷数据用HDD归档,整体利用率提升40%以上。新型存储介质如MRAM、ReRAM的量产,有望在2027年缓解DRAM依赖。

在这场数据战争中,中国正扮演关键角色。长江存储、长鑫存储的产能扩张,缓解了部分供需压力;特变电工的超高压变压器、宁德时代的储能方案,为AI数据中心提供电力支撑。当硅谷为数据饥荒焦头烂额时,中国的“数据基座”建设已初见成效。

站在2026年的门槛回望,AI发展正经历从“算法竞赛”到“数据治理”的范式转变。当每天2.5万亿GB的数据洪流席卷而来时,谁能在这片荒漠中培育出数据绿洲,谁就能掌握下一代人工智能的钥匙。这场静默的革命,或许比任何模型参数突破都更接近AI的本质。

[中国银行] 开工大吉!恭喜您获得 5-20 元微信立减金福利!现登录手机银行完成一笔 1 元及以上中行内转账或 100 元及以上跨行转账,即能领取!点击 https://mbs.boc.cn/v/a/48oLL712g9 立即参与,2 月底前有效,转发无效,先到先得!拒收请回复 R 。

我媳妇分享给我的,两个人各自领了 10 减 5 的立减金。我是复制链接在手机打开的,需要中国银行有转账 100 元就有资格抽奖。

一、概要
(提示:当业务跑得越来越快,真正的安全不再是“守住数据”,而是“看清数据在跑什么”。)

   在移动支付、在线医疗、智能政务和数字金融高度普及的今天,企业的核心业务几乎全部构建在 API 之上。每一次下单、查询、支付、授权,本质都是一次 API 调用,也是一次数据的实时流转。API 已不再只是技术接口,而是企业数字化运行的“血管系统”。过去十年,数据安全建设更多聚焦于数据库加密、访问控制、脱敏存储等“静态防护”手段,核心目标是防止数据“躺着被偷”。但现实中的安全事件却越来越多发生在数据“流动过程中”:越权调用、批量爬取、业务逻辑滥用、自动化攻击,往往并不触碰数据库本身,而是通过合法接口完成非法目的。公开数据显示,全球超过 80% 的应用层攻击与 API 有关,其中相当比例属于业务逻辑型攻击。这类攻击不触发传统漏洞规则,也不具备明显恶意特征,却可以在短时间内造成大规模数据泄露或业务损失。这标志着一个清晰转折点:企业数据安全正在从“静态数据保护”迈向“数据流转安全”。API风险监测系统,正是在这一背景下出现的新型安全基础设施。它不再只关注代码是否存在漏洞,而是持续观察 API 的运行状态、数据行为与业务语义,在真实流量中实现智能识别,在连续运行中保障系统平稳,在全过程中支撑合规落地。

二、API风险监测是什么
(提示:API风险监测的本质,是让每一次数据流动都可被理解、被评估、被治理。)

   API风险监测系统是一套基于真实业务流量构建的动态安全体系,其核心不在“拦截”,而在“洞察”。系统通过旁路或镜像方式采集全量 API 调用流量,自动识别接口资产,构建完整 API 图谱,包括接口路径、参数结构、返回字段、访问主体、数据类型与调用频率,并持续跟踪其生命周期变化。在此基础上,系统进一步完成三层建模:

第一层:接口资产建模自动发现新增 API、影子 API 与僵尸 API,对接口进行分类分级,标识是否涉及个人信息、交易数据或业务核心字段。
第二层:行为基线建模通过机器学习建立“正常调用画像”,包括访问节奏、参数分布、用户角色与业务场景。一旦出现偏离基线的访问行为,即触发风险分析。
第三层:数据流向建模对返回内容进行结构化解析,识别敏感字段的流转路径,实现“谁在什么场景下访问了哪些数据”的精细追踪。
这种能力本质上构建的是一张实时数据流地图,使企业第一次真正看清:数据是如何在系统之间穿行的。与传统安全产品最大的不同在于:API风险监测关注的是运行态,而不是配置态;关注的是行为语义,而不是单点漏洞。这使安全从“事前假设”转向“事中感知”,从静态规则升级为动态智能。
三、面临的挑战
(提示:真正困难的不是攻击多,而是攻击藏在“正常业务”之中。)

   在实践中,企业普遍面临以下几类现实挑战:第一,接口数量失控微服务架构下,大型企业往往拥有数千甚至上万个 API。开发团队频繁迭代,旧接口长期遗留,安全团队却无法获得完整清单,资产不可见成为最大盲区。第二,业务滥用难以区分刷单、爬虫、抢票、撞库等行为往往使用合法接口完成,仅从流量层面看与真实用户高度相似,传统WAF难以有效识别。第三,越权访问隐蔽发生大量数据泄露事件并非黑客入侵,而是普通账号通过参数篡改实现横向越权,直接访问他人数据。第四,合规压力持续加码在《数据安全法》《个人信息保护法》框架下,企业不仅要“没出事”,还必须证明自己具备持续监测、审计留痕和风险处置能力。

这些问题的共同特点是:它们发生在数据流动中,而非数据存储处。如果仍然停留在静态扫描与规则防御层面,企业很难建立真正可持续的安全能力。
四、常见问题和相应解答
问题一:已经有WAF和漏洞扫描,还需要API风险监测吗?答:传统手段解决的是“已知漏洞”,API风险监测解决的是“未知行为”。前者偏防御,后者偏洞察,两者互补。
问题二:是否会影响业务性能?答:系统采用旁路部署,不介入主链路,对业务零侵入。在多个金融与互联网案例中,部署后系统运行平稳,对核心交易无明显性能影响。
问题三:误报会不会很多?答:通过持续学习业务行为建立动态基线,系统可自动降噪。实际落地中,误报率可下降 40% 以上,安全运营效率显著提升。
问题四:如何支撑合规审计?答:系统对所有API访问进行留痕,支持按接口、用户、数据类型生成审计报告,可直接用于监管检查与内部稽核。
问题五:是否只能发现问题,不能解决问题?答:通过与SOAR、IAM等系统联动,可实现自动封禁账号、限制接口频率、下线高危API,形成闭环处置能力。
五、未来趋势
(提示:下一代数据安全,将以“持续可见”为底座,以“智能识别”为核心。)

   未来三年,API安全将呈现三个明确方向:第一,从项目式建设走向常态化运行安全不再是一次性部署,而是持续监测、持续优化的运行体系。第二,从人工分析走向AI辅助治理大模型将深度参与日志解析、风险归因与策略推荐,安全团队更多扮演决策角色。第三,从单点防护走向全链路合规API风险监测将与数据分类分级、身份治理、隐私计算协同,形成贯穿采集、传输、使用全过程的合规闭环。最终形态,是建立一套“看得见数据流、管得住接口、说得清责任”的数字安全底座。       API 已成为企业数字世界中最繁忙的通道。真正成熟的安全体系,不是把数据锁死,而是让数据在被安全理解的前提下自由流动。API风险监测系统所代表的,是一种新的安全范式:从静态数据保护,走向动态流转治理;从被动防御,走向主动感知;从合规压力,走向业务保障。当企业能够持续看清每一次数据调用,理解每一次异常行为,并在不中断业务的前提下完成风险处置时,安全才真正成为数字化发展的助推器,而不是刹车器。在高度互联的时代,跑得快很重要,但跑得稳、跑得清楚、跑得合规,才是长期竞争力的来源。

DeviceManager 是一款本地运行的设备管理工具,适用于需要管理摄像头、交换机、服务器、PC 电脑等等等各类网络设备的场景。主要功能包括:

1 、设备的录入、编辑、删除和分类浏览,批量导入导出,
2 、设备间的物理连线记录与网络拓扑可视化
3 、IP 地址空间的可视化规划与冲突检测及导出
4 、设备类型及其各自属性的自定义,灵活的字段自定义和数据备份
5 、设备资产的多维度统计与覆盖率报表
(这程序一开始是只做了摄像头管理的,覆盖率主要是摄像头监控建设,各个乡镇覆盖率需要)

系统基于 Electron 构建,数据存储在本地 SQLite 数据库中,无需联网即可使用。也可支持 webdav 备份

起因是
https://www.v2ex.com/t/1127265#reply17

在 ai 的帮助下完成。

吐槽一下,KIMI K2 太老火了!!白白花了 50 块大洋,还不如我 5 块钱买的学生认证 gemini !

现在的问题:
感觉仍然是在处理 excel 表格!后续准备把拓扑图部分强化!
说是网络设备管理吧,欠缺网络发现、ping 等功能。
我觉得特色的的是拓扑图,表格导入连线,但是在自动布局方面还没有好的,准备试试 yEd editor 强大的自动布局!

下载
『来自 123 云盘用户 13885066753 的分享』 DeviceManager-win32-x64.zip
链接: https://www.123865.com/s/ANntjv-tEjgH

图片:
https://imgur.com/a/gvPdyR8

随着大模型(LLM)应用深入,长文档分析、多轮 Agent 交互等场景对上下文长度的需求爆发式增长。然而,有限的 GPU 和 HBM 显存资源已成为制约推理性能和扩展性的核心瓶颈。如何在保证极致推理速度的同时,显著降低 TCO 并支持无限延伸的上下文,是业界共同面临的挑战。

本次 Meetup 由 SGLang、阿里云数据库 Tair KVCache 、NVIDIA 开发者社区 和千问 APP 基础工程团队联合举办。活动将深度聚焦大模型推理的演进方向,公开 SGLang 的最新发展路线图,深度解密 Tair KVCache 如何通过分层存储和高速网络重构推理架构。同时,我们特邀来自千问 APP、 NVIDIA 的技术专家,分享在构建大规模、高性能推理服务的一线优化实战经验。

📅 3月7日14:00-18:00
📍上海 T·HOUSE 艺术空间(闵行区漕河泾开发区,古美路 1528 弄 7 号楼)
👉🏻报名链接:https://survey.aliyun.com/apps/zhiliao/rhkk7qcDX
👉加入钉钉交流群:109765011301

精彩看点预告

1️⃣ SGLang 独家剧透

  • SGLang 的现状与未来全景路线
  • 《SGLang 高性能推理:现状与未来路线图全景解析》——SGLang 核心团队成员,鲍科
  • 《SGLang 面向 HybridModel 的优化实践》——SGLang 核心团队成员,张懿

2️⃣ 千问 APP 业务实战

  • 看千问APP的大模型低延迟推理优化实践
  • 《千问APP中大模型低延迟推理优化实践》——阿里千问C端事业部高级技术专家,代俊
  • 《ECHO-面向高并发低延迟推理的投机采样新方法》——阿里千问C端事业部技术专家,胡欣怡

3️⃣ 阿里云存储重构

  • 深度解密阿里云 Tair KVCache 与 NVIDIA、Mooncake 等生态伙伴的技术突破。
  • 《SGLang 与阿里云 Tair KVCache 协同进化》——SGLang Core Developer ,阿里云 Tair KVCache 专家,黄章衡
  • 《Qwen3.5 推理优化实践》——NVIDIA GPU 计算专家团队(DevTech)工程师,李克森
  • 《阿里云 Tair KVCM + Mooncake:全局管理与高性能存储的深度融合》——阿里云 Tair KVCache 专家,王悉宇;阿里云 Mooncake 核心贡献者,马腾
  • 《SGLang 仿真优化: Tair HiSim 与 Dynamo AIConfigurator 的协同实践》——NVIDIA 消费互联网行业技术负责人,徐添豪;阿里云异构研发高级工程师,周海柱

这是一场关于速度、规模与成本的技术深度交流,诚邀每一位关注 LLM 基础设施的开发者参与。除了技术干货,现场参与还可获得定制的开工礼包,快来提前预定席位吧!