包含关键字 typecho 的文章

项目地址:https://github.com/ZanebonoAlter/folder-clean

起因是因为自己的电脑用的越多，发现 C 盘就会莫名其妙的爆满（各种软件默认装在 C 盘防不胜防啊），尤其是在工作电脑上不怎么上心，什么安卓 studio 的镜像、剪映的配置、uv 缓存、.m2 缓存、nikke （ bushi ）、nvidia 的驱动更新缓存、docker 等等，当然绝大多数占用的不多，但是占用多的绝对很难想到

每次使用普通的 C 盘垃圾清理工具，只能清理微乎其微的 1-2G 系统缓存，有的时候连 idea 更新都直接炸裂，手动去查又慢，windows11 自带的存储统计看了个寂寞（上述所有存储都查不出来）

于是直接参考 du -sh * ，简单做了个遍历，统计每个层级下文件大小


缺点就是文件太多了，自己分析劳心劳力，因为智谱一直都有模型免费用，这种分析文件的小事就正好丢给它，效果如下


因为 ai 删库还是一流的，所以还是只希望它给意见这样，而且 GLM-4.7-Flash 完全够用了

LiteSSL 似乎是一家去年才出现的 CA ，提供免费的 TrustAsia 的基于 acme 签发的通配符证书

不过我实测，它的 acme 服务器签发非常容易报错：
Too many concurrent connections from IP 10.254.14.70 (limit: 10), url: urn:ietf:params:acme:error:rateLimited:concurrent

显然，它后台获取客户机真实 IP 的配置有问题，把反代服务器的内网 ip 当做客户 ip 做速率限制

并且，它存在严重的鉴权漏洞

它的 DNS-01 challenges 缓存似乎有效期很长，并且没有验证签发请求是否来自同一个 acme 账户，使得我们可以随意盗签他人使用 DNS-01 签发的证书

去这里查找该 CA 签发的证书（ ECC,RSA 也类似），随机挑选一个带通配符域名的证书，就可以用自己的 litessl acme 账户重签发证书了，不会触发验证

https://crt.sh/?CN=%25&iCAID=438132

ssyhwa.cloudns.cl 是我临时创建的域名，测试用的，已经过了 DNS-01 验证可以复现

*.vaadd.com 则是我随便选的一个幸运儿，也成功偷到了他的证书

image
image
image

测试地址： https://testflight.apple.com/join/APSdc5Sg

TweeTok 是一款专为 X (Twitter) 用户打造的沉浸式媒体浏览器。我们重构了推文的浏览方式，为您带来像刷短视频一样流畅、直观的视觉体验，让您专注于消费高质量的图片和视频内容。

在正式上架前，请大家体验测试下，有任何问题和建议，可以直接在手机上截屏反馈。





OpenAI 的 Operator 和 Deep Research 还在灰度测试，开源社区已经坐不住了。近期，由清华大学电子工程系副教授代季峰与天桥脑科学研究院创始人陈天桥联合筹备的 MiroMind AI 团队，发布了开源深度研究 Agent——MiroThinker 1.5，号称不靠堆参数，而是靠反思来解决问题。

不同于以往模型单纯通过增加参数量来提升性能，MiroThinker 1.5 引入了交互式 Scaling（Interactive Scaling）的概念，让智能体在与环境的反复交互、试错和反思中提升解决复杂问题的能力。

MiroThinker 1.5 的技术突破

MiroThinker 1.5 的发布包含 30B 和 235B 两个参数规模，其核心逻辑在于将智能从模型内部扩展到外部世界，通过“推理-验证-修正”的循环来处理长程任务。

image.png

1. 交互式 Scaling 范式

目前的 LLM 大部分是做题家模式，即一次性输出答案。MiroThinker 则不仅依赖模型本身的知识，更强调在环境中进行多轮深度交互。

  • 长程推理：支持 256K 上下文窗口，能够处理海量信息。
  • 高频工具调用：单次任务支持高达 400 次工具调用，远超同类开源 Agent。

2. 性能表现

根据官方披露的数据，MiroThinker-v1.5-30B 版本以较小的参数量，在中文网页理解基准 BrowseComp-ZH 上超越了 Kimi-K2-Thinking，且推理成本仅为后者的二十分之一。

而更大规模的 235B 版本在 GAIA-Val-165（通用 AI 助手基准）上取得了 80.8% 的高分，在 HLE-Text 和 BrowseComp 等测试集中均处于第一梯队。

image.png

3. 时序敏感训练

为了解决预测类任务中的剧透幻觉，开发团队在训练中严格遵循因果律，确保模型“只能看过去，不能看未来”。这种设计使得 MiroThinker 在金融预测、市场趋势分析等场景下具备了真实的实战价值。所以它能成功预测 A 股涨停板和 GTA 6 的发布趋势。

极速安装指南

MiroThinker 是个重工具的 Agent，且官方要求 Python 3.10+ 。为了省去配置环境变量的麻烦，也不想因为版本冲突搞崩本地系统，建议直接用 ServBay 来接管 Python 环境，这也是最快跑通的路径。

第一步：准备 Python 环境

  • 打开 ServBay，在「软件包」面板找到 Python。
  • 选择 Python 3.10（或更高版本），点击绿色按钮安装。

image.png

  • 安装完成后，Python 环境就已经就绪，不用再管 Path 变量。

第二步：拉取代码与依赖

环境准备就绪后，即可通过终端拉取代码并安装依赖：

# 克隆仓库
git clone https://github.com/MiroMindAI/MiroThinker
cd MiroThinker

# 进入 Agent 目录
cd apps/miroflow-agent

# 安装依赖 (确保已安装 uv)
uv sync

第三步：配置 API Key

MiroThinker 的强大能力依赖于外部工具（如搜索、代码执行）。需要复制配置文件并填入相应的 Key：

cp .env.example .env

在 .env 文件中，至少需要配置以下几项基础服务：

  • SERPER\_API\_KEY: 用于 Google 搜索。
  • JINA\_API\_KEY: 用于网页内容抓取和总结。
  • E2B\_API\_KEY: 提供安全的沙箱环境来执行 Python 代码。
  • SUMMARY\_LLM: 用于信息提取的 LLM（可以使用轻量级模型如 Qwen3-14B）。

启动与运行

配置完成后，可以通过命令行运行一个简单的任务来测试 Agent 是否工作正常：

# 使用 uv 运行主程序
# 假设已在本地或远程部署了 LLM 服务 (如 vLLM 部署的 MiroThinker 模型)
uv run python main.py llm=qwen-3 agent=mirothinker_v1.5_keep5_max200 llm.base_url=http://localhost:61002/v1

如果本地显存跑不动 30B 模型，可以先用 API 模式（比如接 Claude 或 GPT）来体验它的思考流程。

# 使用 Claude (需配置 ANTHROPIC_API_KEY)
uv run python main.py llm=claude-3-7 agent=single_agent_keep5

写在最后

MiroThinker 1.5 给我的感觉是，开源社区终于开始在 System 2（慢思考）上发力了。虽然要配 Key 有点繁琐，但看着 Agent 在终端里一步步“推理-验证-修正”，确实能感觉到它和只会瞎编的大模型不一样。

如果你手头有复杂的调研任务，或者想研究怎么让 AI 不产生幻觉，用 ServBay 几分钟搭个环境跑跑看，绝对不亏。毕竟，能“承认自己不知道并去查证”的 AI，才是我们真正需要的。

现代合成化学正面临知识迅速积累与应用转化效率之间的突出矛盾。每年有数十万篇相关文献发表，可用合成知识的总量已积累至百万级别。然而，这些知识大多以非结构化文本形式分散在不同数据库中，呈现出显著的碎片化特征。依赖传统的文献检索与人工筛选，不仅过程耗时费力，也难以系统覆盖跨领域的反应类型，导致大量潜藏在文献中的有效信息难以被提取并转化为可执行的实验方案。

面对这一知识管理困境，合成实践的核心需求日益聚焦于如何高效获取高可重复性的完整实验流程。这类流程涉及试剂选择、化学计量控制、温度程序和后处理步骤等诸多关键参数。

目前，该领域的发展主要受限于两方面，其一是专家经验难以覆盖持续扩张的反应空间，在跨学科合成任务中往往伴随高昂的试错成本；其二，尽管人工智能技术发展迅速，但通用模型在化学领域的应用仍存在可靠性不足、易产生「幻觉」及缺乏置信度评估等问题，尚无法满足实验级的精度要求。因此，将海量、分散的化学知识转化为结构化、可信赖的合成指导，已成为突破领域效率瓶颈的关键。

在此背景下，耶鲁大学研究团队近期提出 MOSAIC 模型，将通用大语言模型转化为一个由众多专业化学专家构成的协作系统，通过专业分工有效抑制模型幻觉，提供可量化的不确定性评估，实现了从反应描述到完整实验方案的系统生成，有望在药物发现、材料开发等领域实质性地提升科研效率。

相关研究成果以「Collective intelligence for AI-assisted chemical synthesiss」为题，已发表于 Nature。


论文地址：
https://www.nature.com/articles/s41586-026-10131-4
关注公众号，后台回复「MOSAIC」获取完整 PDF

更多 AI 前沿论文： 

https://hyper.ai/papers

基于 Pistachio 数据库，构建各擅所长的「AI 化学专家」

该研究基于 Pistachio 数据库开展。这是一个商业化、高度结构化的化学反应知识库，内容主要源自全球专利文献。通过对专利中记载的反应物、产物、试剂、溶剂、产率及关键步骤文本描述进行系统提取与标准化处理，数据库将其统一编码为机器可读的格式（如 SMILES 字符串）。研究团队并未直接使用全量数据，而是执行了严格的质量筛选，核心标准是要求反应记录必须包含详细、可执行的实验步骤描述，而不仅仅是反应物与产物的映射关系，从而确保后续训练的模型学习的是「如何实现反应」，而非仅仅是「反应结果是什么」。

经过筛选的数据通过专门设计的核度量网络，被转化为 128 维的反应特异性指纹。该数字化表征旨在捕捉化学反应的本质转化特征，所有指纹向量共同构成了一个表征广阔化学知识空间的「反应宇宙」。基于此向量空间，研究采用无监督的 Voronoi 聚类算法（通过 FAISS 库实现），将其划分为 2,489 个互不重叠的专业区域，每个区域聚集了化学性质高度相似的反应类型。

最终，每个 Voronoi 区域内的反应文本被用于独立微调一个专用的 Llama-3.1-8B-Instruct 模型，由此形成 2,489 个各擅所长的「AI 化学专家」。整个 MOSAIC 框架的知识范围与能力边界，根本上由这份以专利为核心的训练数据集所决定。这也解释了系统在某些快速发展的前沿领域（如光化学）表现相对受限的原因——这些内容在现有专利数据库中的覆盖尚不充分。

MOSAIC：由众多专业化学专家构成的去中心化协作系统

MOSAIC 模型的核心设计思想是将通用大语言模型 Llama-3.1-8B-instruct 转化为一个由众多专业化学专家构成的去中心化协作系统。这一搜索驱动的架构显著降低了对硬件资源的需求，仅需使用适中规模的算力配置（如 4 个 GPU）即可对特定任务子集进行训练，无需依赖大规模计算集群。系统通过专家分工机制有效抑制模型幻觉，并提供可量化的不确定性评估，同时支持动态扩展新专家而无需重新训练整个系统，在灵活性与可持续性上具有明显优势。

MOSAIC 模型设计思路

为突破大语言模型在大规模数据上训练时面临的算力与协调瓶颈，MOSAIC 通过 3 个渐进式组件构建而成：

反应相似性度量：

研究设计了一种基于神经网络的非线性映射（核度量网络，KMN），用于量化化学反应之间的相似性。它将 SMILES 编码的反应转化为 128 维的反应特异性指纹（RSFP），使其欧氏距离能够近似反应类别关系，从而捕捉反应的本质转化特征。

知识空间聚类：

利用 FAISS 库的高效索引能力，对 RSFP 向量空间进行无监督 Voronoi 聚类，自动划分出 2,498 个化学性质高度聚集的专业区域，每个区域代表一个特定的化学知识领域。

领域专家训练：

在每个聚类对应的反应数据上，独立微调专用的专家模型。研究采用两阶段训练策略：先在完整数据集上进行基础模型微调，再利用各聚类数据深化对应专家的领域知识，使专家在保持通用化学理解的同时，具备深厚的专业认知。

MOSAIC 首先将查询反应编码为 RSFP，并通过 FAISS 快速定位其所属的 Voronoi 区域及对应的专家。例如，对于一个氯代芳烃的 Buchwald-Hartwig 偶联反应，系统会调用精于此领域的专家，生成完整、可读的合成步骤。实验验证表明，完全依照该方案操作，最终能以 96% 的产率获得目标产物。

MOSAIC 实现 94.8% 组分覆盖率与 71% 合成成功率

该研究进一步通过多维度评估系统验证了 MOSAIC 模型的综合性能，其核心价值在于将海量文献知识转化为高可信度的合成智能。

在产率预测与核心组分识别方面，MOSAIC 模型通过解析完整的实验程序文本，实现了对反应产率的量化预测。如下图所示，采用分箱策略后，预测区间中心与真实产率中位数显示出显著相关性（R² = 0.811）。在识别反应关键组分（试剂、溶剂）方面，模型展现出优秀的覆盖能力，在集成前三位专家的预测结果后，能至少部分识别出正确组分的综合成功率高达 94.8%。值得注意的是，即便预测条件与文献记录不完全一致，其输出也常为化学上可行的替代方案，体现了深层的专业判断力。

MOSAIC 的产率预测分析

在 12 类重要反应（Suzuki 偶联、Buchwald-Hartwig 胺化等）的对比测试中，如下图所示，与 ChatGPT-4o、Claude 3.5 等通用大语言模型相比，MOSAIC 在提供明确、可行的合成指导方面 consistently 表现更优。这一优势在模型参数量仅为 80 亿的背景下尤为突出，证明了领域专业化微调的有效性。更重要的是，MOSAIC 克服了通用模型在化学任务中常见的指令遵循不稳定、回答随意性大等问题，提供了稳定、可靠的输出，这对实际实验至关重要。

MOSAIC 与通用 LLMs 的比较

为了评估所提出框架的实用性、通用性和可靠性，该研究还通过执行现代化学合成基础反应的精确、最高排名预测进行了广泛的实验验证。研究人员把重点放在了对药物和材料开发至关重要的广泛适用的催化反应上。Buchwald-Hartwig 胺化形成的碳-氮键在药物分子中普遍存在，这些具有挑战性的反应的条件被准确预测。实现了类药支架的高效组装，在对从天然产物到功能材料的应用至关重要的烯烃转化方面展示了特别的优势。

此外，MOSAIC 模型的实用性在大量新颖化合物的成功合成中得到有力证实。在总计 37 个目标化合物的合成中，有 35 个依据模型的首次推荐即告成功，整体成功率达 71%。验证范围涵盖从经典偶联反应到选择性转化，并包括指导开发全新氮杂吲哚成环方法这一体现创新能力的案例。

尤为重要的是，模型内部的置信度指标（最近专家质心距离）与实验成功率呈现明确的正相关关系：高置信度预测（距离<100）的成功率超过 75%。这为化学家提供了宝贵的量化决策依据，使其能在高成功率目标与探索性尝试之间进行有效的资源分配。

化学合成迈入精准智造新纪元

在推动化学合成智能化的全球进程中，学术界与工业界正沿着互补的轨道协同发力，共同重塑从分子发现到工艺生产的全链条。

高校的研究如同探索未知领域的先锋，专注于攻克底层计算的极限与科研范式的革新。麻省理工学院（MIT） 的研究人员巧妙地将用于图像生成的「扩散模型」迁移至化学反应领域，实现了对关键「过渡态」结构的超快速计算——将传统需耗时数日的任务压缩至数秒之内，并以 0.08 埃的原子级精度为反应预测提供了前所未有的微观洞察。

与此同时，斯坦福大学的团队则致力于重构科研本身的工作方式，构建 AI 驱动「虚拟实验室」系统，能够自主组建多学科虚拟团队，在「首席研究员 AI」的协调下进行秒级协作与辩论，已在疫苗设计等复杂课题中提出了超越常规的创新思路。此外，哈佛大学等机构的研究将人工智能的模拟能力推向宏观尺度，其提出的统一框架成功实现了对包含百万原子的复杂铁电材料的精确模拟，为从本质上设计新一代功能材料提供了强大的数字透镜。

相较于学术界对前沿的开拓，企业界的创新则更注重于将尖端算法转化为解决实际痛点的生产力与市场竞争力。德国化工巨头巴斯夫在全球范围内部署 AI，不仅推出了辅助研发的「AI 化学家 Copilot」，将新材料开发周期大幅缩短了 60%，更将 AI 深度融入生产优化、物流规划和预测性维护等环节，实现了从实验室到工厂的全价值链增效。

而在制药领域，总部位于瑞士的诺华（Novartis） 等药企正以「端到端」的方式拥抱 AI，通过与 Isomorphic Labs、Schrödinger 等专业公司的深度合作，将人工智能的应用贯穿于从全新靶点发现、化合物生成与安全性预测，到优化临床试验设计的每一个关键环节，显著提升了药物研发的确定性与成功率。

纵观这些跨越学术与产业的突破，化学研究——这门曾高度依赖个人经验与重复试错的传统学科，正在被数据与算法深刻重塑，稳步迈向一个可预测、可规划、可自动执行的精准科学新时代。从攻克疾病的创新药物，到助力可持续发展的绿色材料，化学合成智能化这场深远变革，正在为我们应对这个时代最紧迫的挑战，锻造出前所未有的核心能力。

参考文章：
1.http://edu.people.com.cn/n1/2025/0730/c1006-40532541.html
2.https://cen.acs.org/pharmaceuticals/drug-development/Q-Novart...

飞猪搭建体系介绍

可视化页面搭建技术在业界已相当成熟，几乎每个前端团队都会建设一套页面搭建系统，它显著提升研发效率与交付速度，已成为业务快速迭代与规模化生产的关键基础能力。飞猪移动端页面搭建最早诞生于营销大促场景，不同于常规的业务开发，营销大促业务具有以下特点：

  • 迭代速度快：飞猪大促项目频次高且节奏紧凑，传统瀑布式研发模式难以适配业务快速迭代诉求。需沉淀一套面向活动场景的低代码平台，将页面公共能力和通用组件进行标准化、平台化，以降低重复开发与跨团队协作成本，支撑快速迭代与高频发布，在有限周期内兼顾交付效率与稳定性；

  • 页面数量多：同期活动通常涵盖多个会场、频道、主题页及域外落地页等，上百个活动页面并行推进，且页面结构差异较大，高频、紧急的营销节奏叠加海量页面需求，使研发交付压力显著增加；

  • 页面变阵频繁：一场完整的大促活动通常要经历「预热、预售、现货」等多个阶段，不同阶段的核心目标与主推商品 / 权益会递进变化，运营工作人员需要实时盯盘，根据流量、转化与库存等数据频繁调整页面内容与商品坑位布局且要求快速生效；

基于上述特性，飞猪移动端页面搭建体系应运而生，我们围绕可视化搭建、数据配置与动态渲染三大核心能力，打造了一套面向高频迭代与规模化交付的页面搭建体系。该体系从初代寄生于阿里集团搭建平台下的一个服务站点起步，先后经历了数据投放服务自建、平台能力自建、搭建服务与渲染底座自研。最终形成了当前将数据投放与页面搭建深度融合的一体化“搭投”体系，能够灵活支撑营销大促、日常频道、互动玩法、机酒汽等行业场景、商业化以及小程序等多场景业务需求。

飞猪搭建体系遵循 PMT 模型规范，核心概念包括：

  • Page（页面）：用户可访问的完整页面载体，由页面容器聚合多个业务模块完成运行时渲染，页面容器提供通用基础能力，包括：模板引擎渲染、协议数据的转换与分发、组件依赖与运行时注入、以及埋点与日志等公共服务；

  • Module（模块）：可复用的业务组件单元，封装组件的展示与业务逻辑并定义数据绑定规则，支持独立配置、按需组合编排，快速拼装成不同页面结构；

  • Tag（资源位）：模块内用于承载内容投放的最小单元，用来挂载与管理投放数据，一对多关联具体数据投放配置，并支持个性化规则定投；

图片

飞猪搭建平台

现状与可优化空间

从寄生站点到自研体系的全面回迁，标志着飞猪搭建体系逐渐成熟，但是依赖传统人工选搭投的模式没有得到本质化的改变。下一阶段的重点，是在既有能力之上进一步释放效率红利，围绕“搭建自动化、配置智能化、保障体系化”持续优化：

  • 运营侧提效：页面搭建链路仍有较大提效潜力，当前运营在模块选择、配置理解、跨平台联动配置上投入时间较多，且在日常使用中对咨询支持的需求仍然较旺。与此同时，运营团队更新节奏快，新人从熟悉到独立产出仍需要一定学习成本，存在进一步降低门槛、增强引导与工具化的空间；

  • 设计侧降本增效：页面交付对设计资源的依赖仍然较重，尤其在大促等峰值场景，设计需求集中、节奏紧，容易成为影响整体交付效率的关键路径。日常场景采用计件和众包模式也带来一定的成本与协同开销，因此在设计素材智能生成等方面有进一步优化空间；

  • 产研侧提效：

    答疑提效：尽管已有答疑平台与知识库沉淀，但是在自主排查方面仍可继续增强，高频场景可进一步沉淀标准化诊断与一键解决方案，减少人工介入；

    技术保障提效：大促会场通常需要多轮预演，上线后也需要持续巡检以应对业务调整带来的体验波动。随着平台迭代和营销活动频次提升，可通过自动化预检和巡检等方案持续降人工保障投入；

    研发提效：搭建模块遵循特定规范与约束，新人从上手开发到独立交付仍需一定学习成本；同时由于容器和渲染等核心链路的黑盒特性，仍需平台负责人员提供一定协同支持与保障。可引入 AI Coding 辅助研发，并完善 AI 自助诊断与排障工具，提升代码研发与问题排查效率，降低对平台协同支持的依赖；

AI 化升级的目标

如今正是 AI 蓬勃发展的时代，问答推理、物料生产、流程编排等方案已经成熟，当下的命题应当是思考搭建 + AI 如何深度结合，打造智能化搭建系统，从人工运营向 AI 辅助运营转型，最终实现无人值守自动化运营。为解决选搭投当前的问题正式启动 AI 智能搭投升级专项：深度融合图文素材生产系统、大模型调度编排等能力，将 AI 模式注入招商选品、页面搭建、数据投放等核心系统，构建从需求理解 → 智能编排 → 自动执行的搭投新范式，为未来全域智能运营奠定技术基础。

  • 提升运营配置效率：打通“招选搭投”体系 AI 基础能力，通过推荐模板页面、智能搭建页面、智能助理运维等能力辅助业务快速完成页面搭投，覆盖飞猪页面搭建全场景、提升运营配置效率、减少页面配置时间；

  • 减少设计投入成本：全面推广 AI 文生图和创意合图能力，实现计件众包模式向业务自助产图转型，减少设计费用实现流程提效；

  • 减少人工答疑成本：AI 赋能答疑场景，提升答疑助手拦截率，常见配置问题自动定位并引导解决，缩短问题解决耗时；

  • 提升模块研发效率：模块研发全面拥抱 AI 模式，完善搭建 IDE Rules + MCP 生态，探索 D2C 在搭建模块开发应用场景，提升模块开发效率；

产品结构设计

智能选搭投体系 = AI 搭建 + AI 投放 + AI 素材 + AI 助理 + AI 答疑 + AI Coding

图片

产品结构

技术实现细节

智能搭建

模板检索

为了保证 AI 生产的页面尽可能贴合飞猪营销页面规范且保证转化效率，以及让运营人员有体感预期，我们采用模板预览的形式作为平台入口，基于用户描述推荐场景相似且业务效果较好的模板，用户可进行预览并确认后进入下一步生产流程。此外我们对页面模板进行了分类，不同的页面类型会走到不同的 Agent 完成生产。

图片

模板预览

那么这么多页面模板从哪里来呢，总不能人工维护吧？答案是基于历史页面作为模板即可，毕竟运营人工搭的页面一定是符合预期效果的。通过跑定时任务批量对历史页面进行回溯，再交给多模态 LLM 分析页面内容打标，作为检索关键词进行向量化并落库，检索时进行相似度计算排序即可，实现细节如下：

  • 页面回溯：处理埋点日志找到页面 UV 最大的日期，基于该日期进行页面结构和投放数据 mock 穿越处理，并忽略页面下线重定向逻辑，即可回溯到该页面历史线上投放效果；

  • 页面快照：基于无头浏览器对页面进行截图，生成页面截图快照；

  • 内容打标：基于多模态 LLM 进行页面内容分析，生成页面内容维度标识，包括：页面介绍、关键词、行业标、主题标、质量评分、效率评分等，作为相似度计算的依据；

  • 向量持久化：基于 multimodal-embedding-v1 等多模态向量模型将快照截图和内容标识转换成浮点向量，存到关系型数据库即可（如果数据量较大推荐使用向量数据库）；

  • 检索召回：实时检索时先进行简单的 SQL 检索过滤，再将用户关键词进行向量化，与数据库中的向量字段进行余弦相似度计算，最后排序返回即可；

图片

向量检索链路

页面生产

在页面生成链路，我们梳理了飞猪现存搭建页面类型，大致可分为“搭建页”、“频道页”、“图文页”、“文本页”四类，不同页面类型有着各自的应用场景，需要针对性设计不同的技术方案：

图片

最终生产的页面效果如下，完全达到线上可投放标准：

搭建页

传统搭建页主要通过各行业通用模块搭建而成，不同搭建模块配置项各异且繁琐，新人理解学习成本非常高，即便是运营老司机走完配置流程也需要花不少时间，另外在配置过程中还需要填写大量图片素材依赖设计团队产图，页面搭建过程并不丝滑，一整套页面搭建下来往往需要花费大半天甚至几天时间。

为此我们设计了智能搭建系统，基于用户选择的页面模板复制页面和模块，LLM 推理用户需求总结归纳为页面搭建方案，批量调用智能投放链路（详见后文）完成模块配置，再打通后续排期发布和页面发布工程链路。整套流程只需要 3 min 即可完成，用户描述需求后全程无感，并且支持退出页面后台异步生产。

图片

搭建页面生产效果

整体走大模型编排链路，链路如下：

图片

搭建页生产链路

各流程节点实现细节如下：

图片

图文页

传统搭建模式难以有效支持图文页面场景，难点在于图文页偏设计化、页面结构较复杂，一直以来我们都依赖设计出视觉稿再切图投放，该模式设计计件费用昂贵并且流程较长，对于短平快的营销场景来说是属于历史糟粕亟需革命。我们尝试了以下方案，结果总是差强人意：

图片

我们总是在讨论 AI Coding 如何对程序员提效，那么能否直接绕过 “中间商赚差价”（拿起剪刀剪自己辫子），让运营工作人员直接基于 AI 生产页面呢？答案是可以的，抛开复杂的页面交互逻辑，如果仅是产出静态图文页面，完全可行。

我们设计了一套 Agent 模拟 “前端页面开发” 流程，由 LLM 担任产品、PM、设计、开发等多角色，协同完成图文页面开发任务，最终产物为页面 HTML 代码。再将 HTML 代码渲染至左侧面板提供预览能力，支持文本、图片等 DOM 元素可视化编辑以及选中元素后 AI 微调等能力供运营人员二次调整。页面调整完成后会按页面片段进行图层切分，基于 html2canvas 库将 HTML 片段代码转换成 PNG 图片，导入图片模块并借助 LLM 完成自动圈选热区，最终生成可点击图文页面，或者直接 HTML 代码注入模块实时渲染。

图片

图文页生产效果

整体采用 Manager–Worker 架构设计智能体，拆分分析器、调度器、设计师、工程师等多个角色协同完成长图文生产任务，单 Agent 内部实现完整的 ReAct 范式确保输出最优，使用任务队列模式存储执行进程和上下文，由 AI 自主完成监督调度。在设计 Agent 时需要严格约定出入参数据格式以便调度器准确调度执行，另外还需要设计纠错机制和重试机制保障 Agent 节点在意外抖动时整体链路能够稳定运行。图片页生产链路

图片

核心 Agent 实现细节如下：

图片

智能投放

飞猪搭建体系遵循 PMT 规范，其中资源位数据投放也是搭建链路中重要的一环，我们自建了数据投放系统，支持静态数据源（模块配置）、标准数据源（商品宝贝、酒店日历房）、插件数据源（服务端接口）三类数据类型，涵盖了几乎所有场景的数据内容投放。在搭建 AI 化升级过程中我们对数据投放链路同步进行了升级，衍生出了智能投放链路。智能投放目前支持了图片素材、模块配置、商品选品、二方平台四类场景一句话快速投放，并且支持全类目定投策略智能关联能力，如：时间周期、人群、设备等。我们还对智能投放原子化能力进行封装以支持页面级批量调用，通过 LLM 分析页面主题归纳页面搭建方案，各模块基于搭建方案自主生产投放数据。

智能投放技术链路如下图，首先 LLM 会根据用户描述、页面和模块信息进行推理，生成符合页面主题的模块推荐配置，引导用户快速选择。用户进一步描述后，LLM 针对不同物料类型生成所需的内容素材，包括：配置项（JSON）、文案、图片等，并对素材内容整合转换成模块配置入参，若语义识别到用户有定投诉求会自动进行配置，最后调工程链路完成排期发布和钉钉消息通知。

图片

智能投放链路

智能投放各节点详细方案和效果如下：

智能助理

在页面搭建过程中，运营人员除了搭建模块和数据投放外，通常还需要配置页面容器、插件，以及后续投放过程中的渠道加参和转码转链等操作。这类配置内容比较分散，甚至跨多个平台，对于新人运营人员有一定学习过程。因此我们结合 AI 能力推出了「智能助理」，涵盖：页面修改、转码转链、热点分析等多种能力，支持语义识别用户的诉求自动调用相应的工具，辅助用户提高运营效率。

技术链路上比较简单，通过 LLM 理解用户的操作意图，转换成工具约定的出入参并调用底层平台能力完成对应的操作，功能实现细节如下：

图片

智能素材

此外我们还提供了原子化素材创意生成能力，帮助有匠心的运营人员快速微调和优化页面素材内容：

AI 答疑

飞猪搭建直面一线运营人员，我们没有专业的技术支持人员，答疑工作只能由产研人员“兼职”。每天面对大量的答疑咨询工单，让本就繁忙的研发工作雪上加霜。在 LLM 普及后我们也是第一时间接入答疑场景，提供平台和群答疑两种交互模式，日常常见问题全部交由 AI 处理，技术人员只需处理疑难杂症即可。将答疑工作量减至原来的 1/6，拦截率达到 91.4%。

AI 答疑技术方案比较简单，纯调 LLM 没什么好说的，核心需要丰富的知识库来提高答疑准确率。我们扒了近几年来飞猪搭建相关的技术 & 产品文档，根据常见问题进行分类，修订为搭投提示知识库。有了知识库还需要对 RAG 进行优化，主要通过文档分段打标实现，我们通过三方接口召回了集团答疑工具近年来所有人工答疑记录，作为语料支持对现有知识库进行打标，文档缺失部分将该 Case 作为 FAQ 进行补充。基于存量知识库答疑总是具有局限性，随着飞猪搭建体系不断地迭代发展，所以还需要让 AI 自我学习最新知识，我们将 AI 对话和人工答疑对话落库，跑定时任务召回对话并进行向量化落库。后续实时检索时历史对话也会作为知识库的一部分。

图片

AI 答疑 RAG 链路

AI Coding

搭建模块开发：

在 AI Coding 方面我们没有选择造 “重复且低质量的轮子”，而是在 Qoder、Cursor 等成熟 IDE 基础上，通过修订 Rules 方式增强 AI 编码能力。我们编写了 8 类搭建模块开发特殊规则，并接入飞猪代码仓库知识库、Ftech、Figma 等 MCP 服务实现组件库代码片段召回、PRD 理解、D2C 视觉稿转码等能力。有助于模块开发提效，对于新人入门非常友好，整体编码提效 80%+，实测模块功能实现和业务逻辑近乎完美只需要微调样式，规则目录如下：

图片

schema 编写助手

飞猪搭建模块配置表单遵循类 JSON Schema 规范，我们开发了 Schema 编写助手，辅助开发快速生成表单配置，支持 mock 数据和 schema 配置互转，减少新人学习成本、提高模块开发效率、减少研发答疑成本。

图片

schema 助手

总    结

通过对选品、搭建、投放、素材等平台全面整合，我们对飞猪搭建体系进行全面的 AI 化升级，面向运营、设计、产品、研发等全角色构建了一体化的智能搭建平台。在产品形态上，智能搭建体系已经形成智能创建、智能投放、智能素材、智能助理、AI 答疑、AI Coding 六大支柱，为未来全域智能运营奠定基础。

开发一套 AI 体系远比想象中困难，它不像写代码那样有明确、可复现的确定性结果，几乎每天都在对着“人工智障” 挠头。最棘手的问题之一就是大模型的幻觉：自始至终都在困扰着我们，哪怕只是一个很细微的偏差，在多轮任务的链式执行中也会被不断放大，最终产出就可能变得不可用。在不讨论训练 / 微调模型这类高阶手段的前提下，我认为提升 Agent 准确率无外乎以下几种手段：

  • 架构设计：Agent 开发需要有 “把不确定性关进笼子” 的架构设计，实践中可以结合具体场景参考网上的经典设计案例，把任务拆解为可控步骤并引入观测、校验、重试、回滚等机制，将大模型的自由生成约束在可验证和纠偏的闭环中以降低幻觉；

  • 工程实现：多数场景下，工程代码在执行性能与稳定性上更具优势，对于链路中规则清晰、可验证的环节，优先用工程代码实现，能有效降低不确定性；

  • Prompt 调优：Prompt 是一门学问，调好了能让大模型稳定地发挥能力，总结来说就是结构化、多约束、评估标准、分层书写。网上有许多教程和黑科技，不妨先快速学习一轮，实践中灵活尝试运用，磨刀不误砍柴工；

  • 上下文管理：对于多 Agent 体系中，上下文管理尤为重要，一股脑往里塞必然导致 “上下文污染” 越聊越偏。因此需要设计合理的 memory 结构，为上下文标注来源和边界，只使用可信内容、临时内容及时销毁；

  • 模型升级：终极大招，可能你调了半天发现还没换个模型见效快，那就等待 AI 科技的发展进步吧。但是别忘了，基建架构是不可逆的，设计好了就是锦上添花，设计烂了就是雪上加霜；

展望

下一阶段的关键在于把 AI 搭建从 “提效 Copilot” 升级为 “可控、可评估、可闭环的生产系统”，通过约束式架构、自动诊断调优等手段不断提升 AI 的自我思考能力并减少幻觉，推广到日常活动、频道运营、大促活动等方方面面，支撑飞猪更高频、更复杂、多场景的全域智能运营。以下是建设过程中的一些思考以及后续规划：

一、确定 SSL 证书类型

域名验证（DV）证书：仅验证域名所有权，流程简单、速度快，适合个人博客或小型网站。

组织验证（OV）证书：除域名所有权外，还验证组织真实性，安全性更高，适用于中小型企业网站。

扩展验证（EV）证书：提供最高级别的验证，需验证组织详细信息及法律地位，常用于金融、电商等对安全要求极高的网站。

二、挑选证书颁发机构（CA）

选择知名且受信任的 CA 至关重要。
您可以根据预算、证书类型需求及 CA 的信誉度进行选择。

免费SSL证书申请入口

打开JoySSL官网，注册账号，填写注册码230970获取免费证书。

三、准备申请信息

域名信息：明确主域名及需保护的子域名。

组织信息（OV 和 EV 证书需要）：包括组织法律注册名称、地址、电话号码等。

邮箱地址：用于接收验证邮件及证书相关通知。

四、域名所有权验证

证书颁发机构会要求您证明对域名的所有权，常见验证方式有：

文件验证：将特定验证文件上传至网站服务器指定目录。

DNS 验证：在域名的 DNS 配置中添加指定的 TXT 记录。

五、提交申请并等待审核

将准备好的申请信息及验证信息提交给选定的 CA，CA 会对申请进行审核。审核时间因证书类型和 CA 不同而异，DV 证书通常较快，几分钟到几小时不等；OV 和 EV 证书因涉及组织验证，可能需要 1 - 3 个工作日。​

六、下载并安装证书

审核通过后，CA 会提供 SSL 证书文件。根据网站使用的服务器类型（如 Apache、Nginx、IIS 等），按照相应的安装指南将证书安装到服务器上。

七、验证证书是否生效

安装完成后，通过浏览器访问网站，查看地址栏是否显示安全锁标志，且网址以 “https://” 开头。也可使用在线 SSL 证书检测工具，进一步确认证书安装是否正确及网站的安全性。

首先声明这个不是推广帖，也不是引战贴，标题不是噱头

帖子省流版：

  • 对这段时间做的事情做了一些总结
  • 大家提痛点需求，一起做一款让大家觉得爽的开源 AI 产品，形式可能为 build in pulic
  • 拉了个微信群，分享开发 Agent 的经验技巧和坑

缘起

我是一个重度 vim 用户，一开始（ 25 年中旬）用的是 github 官方 copilot.vim （原因是因为开源了几个上千 star 的项目(非凡尔赛)，copilot pro 一开始对这些开发者是免费的，当然现在不免费了），但是自动补全很慢，非常影响效率。

然后就找有关的替代品，尝试了很多，比如 chatgpt.nvim ，codecompanion.nvim 等，但是都不太满意。后来也尝试了 Cursor 和 Claude Code ，但是也有各样问题，一是不太习惯 IDE ，二是还是需要人大量的时间去交互，实际体验下来开发效率并没有提升多少（当然现在要好不少）。后来一想为什么就不能自己写一个呢？于是开始了折腾（造轮子）之路。

过程

一开始是古法编程用 python 快速写了个自动 fix ut 的命令行，还在团队内部做了分享，但是很多时候这个 cli 工作的并不好，然后就想办法优化。

看了很多资料，差不多 100+篇关于 AI 的论文（在 alphaxiv 的帮助下，挑重点 paper 细读。主题包括框架、Agent/Multi-Agent 、注意力、记忆、规划等等），其中一篇给我比较多启发的是 Alita 这篇论文 https://arxiv.org/abs/2505.20286 。当时 Context Engineering 这个概念刚火，还花了好几天看这个 https://github.com/davidkimai/Context-Engineering （后来证明这个项目对我来说基本没用）。然后设计出一套方案，目标是做一个让自己用起来爽的 Agent ，具体来说是：

  • 快（干活快）
  • 狠（彻底解决问题）
  • 准（交付质量高）
  • 美（产品要有设计品味）

充分发挥不同大模型的能力，不局限于单一模型。下面是一开始的架构设计：

集中精力花了差不多 3 个月时间实现，中间还重构了一版（因为效果没有达到预期），核心逻辑全部手写，其他部分前期使用了 Cursor 来帮助写 TUI ，后面就全是用产品自己开发自己了。

产品

产品形态是 Desktop + Tui ，可以编程、Research 、干杂活等，可以简单理解为 Claude Code + Cowork 。

  • 桌面版

对应视频在这

  • TUI

对应视频在这

问题

上个月底这个月初找了几个朋友内测了下，大家给了一些建议。

这两天也开源了，在 HN 和 v2 也分别发了一个帖子简单介绍了下，反馈都比较平平，发的帖子很快沉下去了。我自己反思了下，可能是自己做的东西确实不够好，也可能是大家没关注到，或者大家关注到了但是不感兴趣。

所以想看下大家真实的想法，先抛个几个问题：

  • 现在大家对此类工具和产品怎么看？是产品引不起自己的兴趣吗？
  • 除了 claude code/codex/cursor/opencode 等，还用其他什么比较好的产品吗？比如豆包
  • 现有的工具已经能很好的解决自己的问题了吗？还有其他的痛点吗？

最后

大家需要的话，我可以免费帮实现大家实现有关功能，未来产品的形态由大家来定义。

另外我拉了个微信群，准备把开发 Agent 的时候一些经验技巧和坑分享一下，同时也方便大家交流有关话题，有感兴趣的可以评论区留言我拉一下大家进群。

受够了快餐式的在线音乐和各种难用的播放器，果断自己做一个符合自己需求的。

新手前后搞了快大半年，本地的功能基本完善。

主要支持音乐标签编辑，能让收藏的歌曲更完善，以及很多人性化功能。

有什么更好的建议改进欢迎留言，目前在考虑远程播放功能。

手机效果预览： https://www.bilibili.com/video/BV18GrQBhET6

AppStore： https://apps.apple.com/cn/app/%E6%B3%A0%E7%84%B6/id6755538782

预览

我自己用的图床是简单图床，设计理念就是极简，没有 SSO 功能，今天上午自己一边问一遍改，终于做好了。
image
增加按钮
image
跳转到统一登录
image
完成登录

上次改造的是 alist，现在可以一号通行，网盘、图床都有了，方便多了。

1）.so mmap计算工具内存翻倍现象
2）iOS报告中的Low Memory是如何被促发的

这是第461篇UWA技术知识分享的推送，精选了UWA社区的热门话题，涵盖了UWA问答、社区帖子等技术知识点，助力大家更全面地掌握和学习。

UWA社区主页：community.uwa4d.com
UWA QQ群：793972859

From 问答社区

Q：结合UWA DAY分享的.so mmap内存分析流程，我发现在我们项目中libil2cpp.so有个奇怪的现象，想要问问大家是否知道是怎么一回事：

这里列出来libil2cpp.so占据了4段内存，其中第一段：770e779000-771c606000，和第二段开始到第四段结束地址（78bfac9000-78cd956000）的内存容量完全一致。而且，命令结果显示它们映射到的文件以及offset也都完全一致。我高度怀疑这两段内存的内容也是一致的，很有可能是两段虚拟内存映射到同一段物理内存。但是这个情况只有libil2cpp符合，libunity并不符合。包括我用后来我们打的包，执行同样命令，分析结果，还是符合这个现象。这是否意味着libil2cpp的内存占用实际上是上面统计值的一半？

补充一点：我用我们自己打的包，查看proc/pid/maps，结合readelf命令，发现后面三个段已经映射了所有libil2cpp中的LOAD段了。

附：包含文中提到的“.so mmap内存分析流程”的课程：
Unity移动游戏性能优化全解析与小游戏转化的实战经验

A：试了几个不同的包，有的确实会出现第一段等于后面几段之和的情况：

也有几段互不相同没有加和关系的情况。这两种包的运行时数据和拆包得到的so硬盘占用大小也都基本对得上：

这是因为，UWA DAY PPT中用来计算内存的Python代码会粗暴地计算所有地址的插值并无脑求和，如下图：

但在出现”第一段等于后面几段之和的情况”的包中，前两段的Offset都是偏移0，此时不能强行求和。可以考虑根据这种规律调整代码或人为重新算一下就对了：

欢迎大家转至社区交流：
https://answer.uwa4d.com/question/696ddb25244ce21ce9ec096f

From UWA AI 问答

Q：iOS平台上[UIApplicationDelegate applicationDid ReceiveMemoryWarning]调用只在1.8GB左右频繁触发，内存更高以后反而触发率降低了，是什么原因？

A：该现象符合iOS内存管理机制的分层压力响应策略，根本原因在于：applicationDidReceiveMemoryWarning并非在内存使用达到绝对阈值时触发，而是由系统基于当前可用内存余量、后台进程竞争状态及设备实际内存压力动态判定的“相对性警告”。

具体解释如下：
1. 触发逻辑本质是“内存压力等级”，而非“绝对用量”
iOS不以固定内存值（如1.8GB）为硬触发点，而是通过vm_pressure_level监控全局内存压力。当系统检测到：

  • 可用内存页急剧减少（尤其活跃/非换页内存不足）；
  • 后台App被大量驱逐释放内存；
  • 文件缓存或压缩内存已达上限；
    → 系统向前台应用发送applicationDidReceiveMemoryWarning，提示其主动降载。

2. 1.8GB 高频触发的典型场景
此区间常对应：

  • 应用已加载大部分资源（纹理、Mesh、Audio），但尚未触发Unity的Resources.UnloadUnusedAssets()或AssetBundle卸载；
  • 原生堆（Native Heap）与托管堆（Mono Heap）持续增长，GLES驱动内存池（如MTL/OpenGL纹理缓存）接近饱和；
  • 系统仍保留一定后台缓冲空间，此时压力信号敏感且频繁。

3. 更高内存（如>2.2GB）后触发率下降的合理原因
⚠️ 并非系统“变宽松”，而是进入更危险阶段：

  • 系统已启动强制干预：终止后台App、压缩inactive pages、回收文件缓存；
  • 若应用继续申请内存，不再发送警告，直接触发SIGKILL（OOM Killer）；
  • 此时applicationDidReceiveMemoryWarning反而减少 —— 因系统已无“协商余地”，转向静默强杀。

验证与优化建议

  • 使用Xcode Instruments → Activity Monitor查看Real Memory + Pressure Level曲线，确认是否伴随vm: pressure上升；

  • 在OnLowMemory回调中立即执行：

    • Resources.UnloadUnusedAssets() + Texture2D.DestroyImmediate()清理未引用纹理；
    • 切换至低配资源（如ASTC 4x4替代8x8）；
    • 持久化关键游戏状态（防被杀丢档）；
  • 限制峰值内存：通过UWA GOT Online的GPU/Resource/Mono报告，定位内存大户（如超大图集、未卸载AB、Mono GC堆膨胀）。

该行为是 iOS 内存保护机制的正常表现，高频警告恰说明应用处于“可挽救临界区”，需优先优化资源生命周期管理。

可以参考以上AI回答。而且实际上看起来这个警告只在1.8GB左右触发，也即内存更高时反而不触发的原因。

分享链接：
https://www.uwa4d.com/main/uwa-shared.html?shareId=bfb1e3df-0...

无论是社区里开发者们的互助讨论，还是AI基于知识沉淀的快速反馈，核心都是为了让每一个技术难题都有解、每一次踩坑都有回响。本期分享分别来自UWA AI问答和UWA问答社区，希望这些从真实开发场景中提炼的经验，能直接帮你解决当下的技术卡点，也让你在遇到同类问题时，能更高效地找到破局方向。

封面图来源于网络

今天的分享就到这里。生有涯而知无涯，在漫漫的开发周期中，我们遇到的问题只是冰山一角，UWA社区愿伴你同行，一起探索分享。欢迎更多的开发者加入UWA社区。

UWA官网：www.uwa4d.com
UWA社区：community.uwa4d.com
UWA学堂：edu.uwa4d.com
官方技术QQ群：793972859

SonarQube Server 2025.6.1.117629 - 代码质量、安全与静态分析工具

SonarQube Server 2025 Release 6 (macOS, Linux, Windows) - 代码质量、安全与静态分析工具

Self-managed static analysis tool for continuous codebase inspection

请访问原文链接：https://sysin.org/blog/sonarqube/ 查看最新版。原创作品，转载请保留出处。

作者主页：sysin.org

SonarQube Server

代码质量和安全性由您掌控

SonarQube Server
之前称为 SonarQube，本地部署的用于持续代码库检查的静态分析工具

保持 AI 生成的代码干净

释放 AI 编码助手的强大功能，而无需承担不良、不安全代码的风险。SonarQube Server 是您的干净代码解决方案，可以部署在任何地方、本地或云环境中。

SonarQube Server

受到 700 万开发者和 400,000 多个组织的使用和喜爱

提高代码质量的代码质量工具

您的代码是一项商业资产。通过 SonarQube Server 达到干净代码状态，实现代码的最高价值。

SonarQube Server 功能：

  • 代码智能

    利用 SonarQube 的深度洞察，更全面地了解您的代码库。通过减少认知负荷来提高开发人员的生产力。

  • 与顶级 DevOps 平台集成

    轻松加入项目。与 GitHub Actions、GitLab CI/CD、Azure Pipelines、Bitbucket Pipelines 和 Jenkins 集成，以自动触发分析并显示您工作地点的代码运行状况。

  • 代码审查

    通过 SonarQube 的质量阈值，防止不符合策略的代码进入生产环境。消除人工编写和 AI 生成代码中的问题，从而降低后期修复成本。

  • 高性能和可操作性

    按照您的方式进行部署，无论是在本地、在云中、作为服务器、使用 Docker 或 Kubernetes。多线程、多个计算引擎和特定于语言的加载可提供最佳性能。

  • 顶级分析速度和准确性

    在几分钟而不是几小时内收到可操作的清洁代码指标 (sysin)。Clean as You Code 会在您工作时检查较小的代码片段，为您提供有关新代码质量的准确反馈。

  • 重要语言的关键安全规则

    在您的开发工作流程中，在正确的时间和正确的位置无缝地发现编码问题。受益于 6,000 多个规则以及行业领先的 Java、C#、PHP、Python 等污点分析。

  • 共享、统一的配置

    设置特定的编码标准，使您的团队在代码健康方面保持一致并实现您的代码质量目标。另外，“边编程边学习” 可将开发人员的技能提升到同样高的水平。

  • 用于 IDE 的 SonarQube

    添加 SonarQube for IDE 扩展并将其连接到 SonarQube 服务器，以便在编码时动态查找编码问题，并确保您的团队遵循单一受监管的编码标准。

  • 测量代码覆盖率

    查看测试执行的代码库的百分比，以获得有关代码运行状况的宝贵见解。引导您到覆盖率低的领域进行改进。

Sonar 的人工智能

AI 辅助编码，由 SONAR 改进

  • 新的 AI 代码保证

    Sonar AI 代码保证是一个强大且简化的流程，用于通过结构化和全面的分析来验证 AI 生成的代码。这确保了每一段新代码在投入生产之前都符合最高的质量和安全标准。

  • AI CodeFix 简介

    Sonar AI CodeFix 是一项强大的功能 (sysin)，可为代码分析解决方案 SonarQube Server 和 SonarQube Cloud 发现的问题提供代码修复建议。只需单击一下，您就可以获得有关如何解决一系列问题的建议，从而简化问题解决流程。

笔者提示：此类功能通常需要有效服务合同。

安全漏洞检测

增强的开发人员安全工具 | 安全与机密信息检测

  • 静态代码分析

    Sonar 的静态应用程序安全测试 (SAST) 引擎可检测代码中的安全漏洞，以便在构建和测试应用程序之前消除这些漏洞。使用 SAST 为复杂项目实现强大的应用程序安全性和合规性。

  • 机密信息检测

    SonarQube Server 包含一个强大的机密信息检测工具，这是用于检测和删除代码中机密信息的最全面的解决方案之一。与 SonarQube for IDE 一起使用，它可以防止机密信息泄露并成为严重的安全漏洞。

  • 安全标准合规性

    SonarQube Server 可帮助您遵守通用代码安全标准，例如 NIST SSDF。将 SonarQube Server 与 SonarQube for IDE 结合使用，可以自动检查项目代码是否存在安全漏洞，并提高整体代码质量。

基于开源，满足所有需求的版本

SonarQube Server 版本：

  • Community Build

    免费开源，可提高开发效率和代码质量。

  • Developer Edition

    小型团队和企业的基本功能。

  • Enterprise Edition

    为现代企业提供更深入的见解和绩效。

  • Data Center Edition

    任务关键型高可用性、可扩展性和性能。

什么是 LTA 版本？

LONG-TERM ACTIVE

SonarQube Server Long-Term Active (LTA)

为客户提供最佳体验、创新功能和世界一流的支持，以实现持续的业务成功。

什么是长期活跃 （LTA）

LTA 是指每 12 个月发布一次的 SonarQube Server 版本（以前称为长期支持或 LTS）。它是产品的功能完整版本，将保持活动状态更长的时间。大型组织有时更愿意继续使用 LTA，因为他们无法经常升级，而是选择每 12 个月升级一次。

系统要求

操作系统要求：

建议运行在虚拟机环境中，推荐使用本站原创虚拟机模板 OVF，简单、精准、高效。

软件要求已更新：包含在文档中。

新增功能

SonarQube Server 2025.6：先沉浸（vibe），再以前所未有的速度验证

2025 年 12 月 11 日

SonarQube Server 2025.6

AI 已经将开发瓶颈从 “写代码” 转移到 “验证代码”。确保代码可靠、安全、可维护，已成为软件开发生命周期中最关键的一步。SonarQube Server 2025.6 加速了这一验证流程，将其直接嵌入您的日常工作流中。通过更深的集成、大幅加速的分析性能以及扩展的语言支持，本次发布帮助团队拥抱 “先沉浸、再验证（vibe, then verify）” 的理念，更自信地交付软件。

✅ 2025.6 新功能一览

  • 加速工作流：新增 Jira Cloud 与 Slack 集成。
  • 更快反馈：JavaScript/TypeScript 分析速度提升最高 40%。
  • 即时修复：在 IDE 中新增 58 个 JavaScript/TypeScript 快速修复。
  • 现代语言支持：全面支持 Swift（5.9–6.1）和 Python 3.14。
  • AI/ML 保障：为 PyTorch、Apex 和 Ruby 提供高效分析。
  • 基础设施代码：新增 Go 和 Shell/Bash 的代码质量规则 (sysin)。
  • 合规性：完整覆盖 MISRA C++:2023、OWASP Top 10 2025 与 STIG V6R3。
  • 供应链安全：支持导入 CycloneDX 和 SPDX SBOM。

✅ 通过深度工作流集成加速您的团队

为了帮助团队跟上庞大的代码量，SonarQube 专注于消除摩擦、加快反馈循环。使用 JavaScript/TypeScript 的开发者将立即注意到在大型项目中最高 40% 的分析速度提升，从而缩短等待时间，加速代码评审。同时，SonarQube 让修复问题变得比以往更简单：58 个全新的 “快速修复” 让您在 IDE 中即可快速处理问题。此外，将代码质量融入组织工作流也变得前所未有的顺畅：全新的 Jira Cloud 集成可立即将代码问题转成可追踪的任务 (sysin)；Slack 集成则可在质量门状态变化时实时发送通知，让团队在构建无法通过质量门时可以更快速地响应。

✅ 无与伦比的语言与合规覆盖

SonarQube 2025.6 大幅扩展其在行业内对语言覆盖的领先优势，让您能自信采用新技术并满足最严苛的合规要求。SonarQube 现已为最新版本的 Python 3.14 与 Swift（5.9–6.1）提供全方位的代码安全与代码质量支持，包括 Swift 的 SAST 与秘钥检测。对于构建机器学习应用的开发者，SonarQube 提供 PyTorch 的 AI/ML 保障，帮助实现高效代码。在云原生领域，您将获得大量新的 Go 规则，以及 Shell/Bash 脚本的代码质量与代. 码安全分析。最后，在 SonarQube Server Enterprise 和 Data Center 版本中，SonarQube 提供对全部 179 条 MISRA C++:2023 指南、STIG V6R3 及新版 OWASP Top 10 2025 的完整覆盖，为您的合规与风险团队提供通过严格标准所需的保证。

✅ 通过 Advanced SAST 和 SBOM 保护您的供应链

在供应链攻击不断增加的当下，代码安全绝不能被事后处理。此次发布强化了 SonarQube “集成代码质量与代码安全” 的核心使命。SonarQube Advanced Security 中的 Advanced SAST 功能已针对 C#、Java 以及现在的 Python 的主流库进行了刷新与优化，以发现其他工具遗漏的复杂、隐蔽漏洞。为了让您对所有组件拥有全面可见性 (sysin)，SonarQube Advanced Security 现在支持导入 CycloneDX 和 SPDX 格式的 SBOM（软件物料清单），实现对任意组件的统一依赖性与漏洞报告。通过这些增强功能，SonarQube 确保您的组织能够以快速且自信的方式验证每一行代码——无论是开发者编写的还是 AI 生成的。

更多详细功能介绍，请查阅官方文档。

下载地址

版本历史：

SonarQube Server 2025.1 LTA Data Center Edition for macOS, Linux, Windows | January 2025 | 2025.1.0.102418

SonarQube Server 2025 Release 2 Data Center Edition for macOS, Linux, Windows | March 2025 | 2025.2.0.105476

SonarQube Server 2025 Release 3 Data Center Edition for macOS, Linux, Windows | May 2025 | 2025.3.0.108892

SonarQube Server 2025 Release 3.1 Data Center Edition for macOS, Linux, Windows | Jun 2025 | 2025.3.1.109879

SonarQube Server 2025 Release 4.2 Data Center Edition for macOS, Linux, Windows | July 2025 | 2025.4.2.112048

SonarQube Server 2025 Release 5 Data Center Edition for macOS, Linux, Windows | September 2025 | 2025.5.0.113872 (2025-09-24)

SonarQube Server 2025 Release 6 Data Center Edition for macOS, Linux, Windows | December 2025 | 2025.6.0.117042 (2025-12-11)

当前版本：

SonarQube Server 2025 Release 6.1 Data Center Edition for macOS, Linux, Windows | December 2025 | 2025.6.1.117629 (2026-01-20)

更多：HTTP 协议与安全

和大家分享6个我收藏夹里雷打不动的网站。这些工具不是那种看着炫酷但一年用不上一次的“吃灰”神器，而是真真正正能解决日常痛点、提升效率的好东西。

Perplexity AI

这是一个最近很火的 AI 搜索工具，我用它已经基本替代了传统的搜索引擎。

它好在哪？
以前我们搜东西，比如搜“Java 怎么读取 Excel 文件”，搜索引擎会甩给你一堆链接，让你自己一个个点进去看，有的链接还是广告，或者内容早就过时了。

Perplexity 不一样，它会直接读完网上的相关内容，然后给你写一段总结好的答案。最关键的是，它说的每一句话后面都会标一个小数字，点一下就能跳转到信息的原始出处。

这对查资料太重要了。用 ChatGPT 有时候它会一本正经地胡说八道，但 Perplexity 给了出处，你就可以去核实，心里更有底。平时写报告、做技术调研，或者只是查个冷知识，用它效率非常高。

Excalidraw

这是一个非常有特色的在线白板工具，我特别喜欢它的“手绘风格”。

为什么用它？

平时工作中经常需要画图，比如画个业务流程图、系统架构图，或者给同事讲讲思路。用 Visio 或者那些专业的绘图软件，虽然功能强大，但操作太繁琐了，而且画出来的图太正式，有时候反而让人不敢随便改。

Excalidraw 打开网页就能画，界面极其简单，连注册登录都不需要。画出来的线条像是在纸上手画的一样，有一种草稿的感觉。这种“非正式感”反而能让人专注于逻辑和结构本身，而不是纠结线条直不直、颜色对不对。

它还支持丰富的素材库，像什么 AWS 的图标、各种 UI 组件，直接拖进去就能用。画完了可以直接复制图片，或者导出成文件，非常方便。

123apps

这是一个在线文件处理的好网站，专门解决那些不想装软件的临时需求。

解决什么痛点？
大家肯定都遇到过这种尴尬情况：突然需要把一个视频转成 GIF，或者要把 PDF 里的某一页拆分出来，又或者是一段录音需要剪掉开头那几秒杂音。

为了这点小事去下载安装一个几百兆的专业软件，既占空间又费时间，甚至还可能不小心装上一堆流氓软件。

123apps 就是把这一堆小工具全整合在一个网站里了。视频剪辑、音频转换、PDF 合并拆分、录屏，几乎涵盖了所有常见的文件处理需求。你需要什么功能，点进去把文件拖进去，处理完下载走人，干脆利落。

Carbon

如果你经常需要分享代码，那这个网站绝对是颜值担当。

它有什么用？
有时候我们在写文章、做 PPT 或者在群里讨论技术问题时，直接把代码截图贴出来，往往模糊不清，还很难看；如果直接复制文本，格式又容易乱掉。

Carbon 就是专门解决这个问题的。你把代码复制进去，它会自动给代码加上高亮颜色，还能给图片加上漂亮的背景框和阴影，看起来就像是一张精心设计的海报。

你可以自己选配色主题（比如类似 VS Code 的风格），选编程语言，甚至调整窗口的圆角大小。做出来的图往 PPT 里一放，专业感立马就上来了。

DevDocs

这是一个把所有开发文档都装进口袋的网站。

极客首选
写代码离不开查文档。一会儿查 HTML 标签，一会儿查 CSS 属性，一会儿又要看 Python 的库函数。如果每次都去各自的官网查，要在浏览器里开一堆标签页，而且每个官网的排版、搜索方式都不一样，很心累。

DevDocs 把几百种编程语言和框架的官方文档都抓取下来，整合成了一个统一的界面。

它的搜索速度极快，支持模糊搜索。而且它支持离线模式，你可以把常用的文档缓存到本地，哪怕断网了也能照样查。界面干净清爽，没有乱七八糟的干扰，就是纯粹为了查资料而生的。

GitHub

很多人以为 GitHub 只是程序员存代码的“仓库”，其实它更像是一个巨大的技术宝库和开发者社区。

它能做什么？

首先，它确实是目前最好用的代码托管平台。无论你是写一个小脚本，还是开发一个大项目，把代码传上去，既安全方便，又不用担心硬盘坏了代码丢了。

其次，这里是找资源的神器。想学 Python？搜一下就有无数的教程和示例代码。想做一个博客？上面有很多现成的模板，改改就能用。

甚至很多面试官都会看你的 GitHub 主页，如果你经常在上面活跃，提交代码，或者给开源项目做贡献，这绝对是你简历上的一大亮点。

简单说，不管你是想找现成的轮子，还是想学习高手的代码，或者只是想存一下自己的学习笔记，GitHub 都是绕不开的。

以上就是我强烈推荐的6个网站。它们每一个我都用了很久，希望能帮大家节省时间，少走弯路。

如果对你有帮助，点点关注点点赞

Java Agent 是 Java 提供的一种在 JVM 启动时或运行时动态修改字节码的强大机制，广泛应用于 APM 监控（如 SkyWalking、Pinpoint）、热部署（如 JRebel）、代码覆盖率（JaCoCo）、故障注入、安全审计等场景。一、Java Agent 的两种模式模式加载时机典型用途Premain AgentJVM 启动时（-javaagent）APM 探针、性能监控、字节码增强Attach AgentJVM 运行时动态 attach线上诊断（如 Arthas）、动态开关二、核心原理：InstrumentationAgent 通过 java.lang.instrument.Instrumentation 接口实现：retransformClasses()：重新转换已加载的类（需类支持 retransformation）redefineClasses()：直接替换类的字节码（限制多，不常用）addTransformer()：注册 ClassFileTransformer，在类加载时修改字节码三、快速入门：编写一个简单 Agent步骤 1：创建 Agent 入口类package com.example;

import com.example.transformer.RestTemplateTraceAdvice;
import com.example.transformer.TraceAdvice;
import com.fasterxml.jackson.databind.ObjectMapper;
import net.bytebuddy.agent.builder.AgentBuilder;
import net.bytebuddy.asm.Advice;
import net.bytebuddy.description.method.MethodDescription;
import net.bytebuddy.matcher.ElementMatcher;

import java.lang.instrument.Instrumentation;
import java.util.Arrays;
import java.util.HashSet;
import java.util.Set;

import static net.bytebuddy.matcher.ElementMatchers.isAnnotatedWith;
import static net.bytebuddy.matcher.ElementMatchers.named;
import static net.bytebuddy.matcher.ElementMatchers.takesArguments;

public class TraceAgent {

private final static String appId ;

private static final Set<String> REQUEST_MAPPING_ANNOTATIONS = new HashSet<>(Arrays.asList(
        "org.springframework.web.bind.annotation.RequestMapping",
        "org.springframework.web.bind.annotation.GetMapping",
        "org.springframework.web.bind.annotation.PostMapping",
        "org.springframework.web.bind.annotation.PutMapping",
        "org.springframework.web.bind.annotation.DeleteMapping"
));

private static CustomAgentListener customListener;

static {
    appId = System.getProperty("appId");
}

public static void premain(String agentArgs, Instrumentation inst) {
    install(inst);
}

public static void agentmain(String agentArgs, Instrumentation inst) {
    install(inst);
}

private static void install(Instrumentation inst) {
    // 创建自定义监听器，输出到指定文件，只记录指定包的类
    customListener = new CustomAgentListener(
            "/Users/dsy/code/agent-demo/logs/"+appId+"-bytebuddy-agent.log",  // 日志文件路径
            "com.example"               // 只记录 com.example 包下的类
    );

    new AgentBuilder.Default()
            .with(customListener) // 👈 关键：输出匹配详情
            .disableClassFormatChanges()
            .with(AgentBuilder.RedefinitionStrategy.RETRANSFORMATION)
            .with(AgentBuilder.InitializationStrategy.NoOp.INSTANCE)
            .with(AgentBuilder.TypeStrategy.Default.REDEFINE)
            .with(AgentBuilder.DescriptionStrategy.Default.POOL_ONLY) // 👈 启用完整类型解析
            .type(
                    isAnnotatedWith(named("org.springframework.stereotype.Controller"))
                            .or(isAnnotatedWith(named("org.springframework.web.bind.annotation.RestController")))
            )
            .transform((builder, typeDescription, classLoader, module) ->
                    builder.visit(Advice.to(TraceAdvice.class)
                            .on(anyMethodAnnotatedWithRequestMapping()))

// builder.method(any()).intercept(MethodDelegation.to(NoOpInterceptor.class))

            )
            .type(named("org.springframework.web.client.RestTemplate"))
            .transform((builder, td, cl, module) ->
                    builder.visit(Advice.to(RestTemplateTraceAdvice.class)
                                    .on(named("exchange")
                                            .and(takesArguments(4))
                                            .or(takesArguments(5))
                                            .or(takesArguments(6))))
            )
            .installOn(inst);

    System.out.println("[Agent] Controller tracing agent installed.");
}

private static ElementMatcher.Junction<MethodDescription> anyMethodAnnotatedWithRequestMapping() {
    return isAnnotatedWith(named("org.springframework.web.bind.annotation.RequestMapping"))
            .or(isAnnotatedWith(named("org.springframework.web.bind.annotation.GetMapping")))
            .or(isAnnotatedWith(named("org.springframework.web.bind.annotation.PostMapping")))
            .or(isAnnotatedWith(named("org.springframework.web.bind.annotation.PutMapping")))
            .or(isAnnotatedWith(named("org.springframework.web.bind.annotation.DeleteMapping")));
}

// 添加关闭方法，用于清理资源
public static void shutdown() {
    if (customListener != null) {
        customListener.close();
    }
}

}步骤 2：实现 TraceAdvicepackage com.example.transformer;

import com.fasterxml.jackson.core.JsonProcessingException;
import com.fasterxml.jackson.databind.ObjectMapper;
import net.bytebuddy.asm.Advice;

import javax.servlet.http.HttpServletRequest;
import java.util.Arrays;
import java.util.UUID;

import static com.example.transformer.TraceContextHolder.PARENT_APP_ID;
import static com.example.transformer.TraceContextHolder.X_TRACE_ID;

public class TraceAdvice {

public final static String appId ;

public final static ObjectMapper objectMapper;

static {
    appId = System.getProperty("appId");
    objectMapper = new ObjectMapper();
}

@Advice.OnMethodEnter
public static void enter(@Advice.AllArguments Object[] args) {

    TraceContextHolder.TraceContext traceContext = TraceContextHolder.traceContext();

    // 尝试从参数中提取 HttpServletRequest
    HttpServletRequest request = null;
    for (Object arg : args) {
        if (arg instanceof HttpServletRequest) {
            request = (HttpServletRequest) arg;
            break;
        }
    }

    String traceId = null;
    String parentAppId = null;
    if (request != null) {
        // 优先从 Header 中获取 traceId（例如：X-Trace-Id）
        traceId = request.getHeader(X_TRACE_ID);
        parentAppId = request.getHeader(PARENT_APP_ID);
    }

    if (traceId == null || traceId.trim().isEmpty()) {
        // 未传入，则生成新 traceId（建议用 UUID 或 Snowflake）
        traceId = "trace-" + UUID.randomUUID().toString().replace("-", "").substring(0, 32);
    }

    if (parentAppId == null || parentAppId.trim().isEmpty()){
        parentAppId = "0" ;
    }

    traceContext.setTraceId(traceId);
    traceContext.setArgs(args.toString());
    traceContext.setAppId(appId);
    traceContext.setParentAppId(parentAppId);
    traceContext.setTraceSpanStartTime(System.currentTimeMillis());

    // 绑定到当前线程

// TraceContextHolder.setTraceContext(traceContext);

    System.err.println(">>> Entering method with args: " + Arrays.toString(args));
}

@Advice.OnMethodExit
public static void exit(@Advice.Return Object result) {
    TraceContextHolder.TraceContext traceContext = TraceContextHolder.traceContext();
    traceContext.setTraceSpanEndTime(System.currentTimeMillis());
    try {
        traceContext.setResult(objectMapper.writeValueAsString(result));
    } catch (JsonProcessingException e) {
        throw new RuntimeException(e);
    }
    System.err.println("<<< Exiting method, returned: " + traceContext.toSting());
}

}步骤 3：用于跟踪调用链的上下文在 src/main/resources/META-INF/MANIFEST.MF 中声明：// com/example/transformer/TraceContextHolder.java
package com.example.transformer;

public class TraceContextHolder {

public final static String X_TRACE_ID = "X-Trace-Id";
public final static String PARENT_APP_ID = "X-Parent-APP-Id";

static String FORMAT = "traceId:%s,parentAppId:%s,appId:%s,traceSpanStartTime:%d,traceSpanEndTime:%d,args:%s,result:%s";
private static final ThreadLocal<TraceContext> TRACE = new ThreadLocal<>();

public static void setTraceContext(TraceContext traceContext) {
    TRACE.set(traceContext);
}

public static void clear() {
    TRACE.remove();
}

public static TraceContext traceContext() {
    TraceContext object;
    if (TRACE.get() != null) {
        object = TRACE.get();
    } else {
        object = new TraceContext();
        TRACE.set(object);
    }
    return object;
}

public static class TraceContext{
    private String traceId;
    private String parentAppId;
    private String appId;
    private Long traceSpanStartTime;
    private Long traceSpanEndTime;
    private String args;

    private String result;

    public String getTraceId() {
        return traceId;
    }

    public void setTraceId(String traceId) {
        this.traceId = traceId;
    }

    public String getParentAppId() {
        return parentAppId;
    }

    public void setParentAppId(String parentAppId) {
        this.parentAppId = parentAppId;
    }

    public String getAppId() {
        return appId;
    }

    public void setAppId(String appId) {
        this.appId = appId;
    }

    public Long getTraceSpanStartTime() {
        return traceSpanStartTime;
    }

    public void setTraceSpanStartTime(Long traceSpanStartTime) {
        this.traceSpanStartTime = traceSpanStartTime;
    }

    public Long getTraceSpanEndTime() {
        return traceSpanEndTime;
    }

    public void setTraceSpanEndTime(Long traceSpanEndTime) {
        this.traceSpanEndTime = traceSpanEndTime;
    }

    public String getArgs() {
        return args;
    }

    public void setArgs(String args) {
        this.args = args;
    }

    public String getResult() {
        return result;
    }

    public void setResult(String result) {
        this.result = result;
    }

    public String toSting(){

        return String.format(FORMAT,traceId,parentAppId,appId,traceSpanStartTime,traceSpanEndTime,args,result);

    }
}

}步骤 4：打包 & 使用如果用 Maven，可通过 maven-jar-plugin 自动生成：<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"

     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<parent>
    <groupId>org.example</groupId>
    <artifactId>agent-demo</artifactId>
    <version>1.0-SNAPSHOT</version>
</parent>

<artifactId>agent3</artifactId>

<properties>
    <maven.compiler.source>8</maven.compiler.source>
    <maven.compiler.target>8</maven.compiler.target>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>

<dependencies>
    <!-- ByteBuddy 核心 -->
    <dependency>
        <groupId>net.bytebuddy</groupId>
        <artifactId>byte-buddy</artifactId>
        <version>1.12.10</version>
    </dependency>
    <dependency>
        <groupId>net.bytebuddy</groupId>
        <artifactId>byte-buddy-agent</artifactId>
        <version>1.12.10</version>
    </dependency>

    <!-- Spring Web（仅用于类型判断，非强制） -->
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-web</artifactId>
        <version>5.3.31</version>
        <scope>provided</scope>
    </dependency>
    <dependency>
        <groupId>javax.servlet</groupId>
        <artifactId>javax.servlet-api</artifactId>
        <version>4.0.1</version>
        <scope>compile</scope>
    </dependency>
    <dependency>
        <groupId>org.slf4j</groupId>
        <artifactId>slf4j-api</artifactId>
        <version>1.7.36</version>
        <scope>compile</scope>
    </dependency>

    <dependency>
        <groupId>com.fasterxml.jackson.core</groupId>
        <artifactId>jackson-databind</artifactId>
        <version>2.17.0</version> <!-- 使用最新稳定版 -->
    </dependency>
</dependencies>
<build>
    <plugins>
        <!-- 使用 shade plugin 打包 fat jar -->
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-shade-plugin</artifactId>
            <version>3.5.0</version>
            <executions>
                <execution>
                    <phase>package</phase>
                    <goals>
                        <goal>shade</goal>
                    </goals>
                    <configuration>
                        <transformers>
                            <transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
                                <manifestEntries>
                                    <Premain-Class>com.example.TraceAgent2</Premain-Class>
                                    <Agent-Class>com.example.TraceAgent2</Agent-Class>
                                    <Can-Redefine-Classes>true</Can-Redefine-Classes>
                                    <Can-Retransform-Classes>true</Can-Retransform-Classes>
                                </manifestEntries>
                            </transformer>
                        </transformers>
                    </configuration>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>

</project>四、创建两个web应用验证trace到调用生命周期
图片
1、web-apppackage com.example.demo.conf;

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.web.client.RestTemplate;

@Configuration
public class BeanConfig {

@Bean
public RestTemplate restTemplate() {
    return new RestTemplate();
}

}
package com.example.demo.controller;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.http.HttpMethod;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.RequestBody;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.bind.annotation.RestController;
import org.springframework.web.client.RestTemplate;

import javax.annotation.Resource;

@RestController
public class HelloController {

private static final Logger logger = LoggerFactory.getLogger(HelloController.class);

@Resource
private RestTemplate restTemplate;

@GetMapping("/hello")
public String hello(@RequestParam(defaultValue = "World") String name) {
    logger.info("Processing hello request for: {}", name);
    String url = "http://localhost:8081/shopping?commodity=香蕉";
    String r = restTemplate.exchange(url, HttpMethod.GET,null,String.class).getBody();
    return "Hello, " + name + "!" + " commodity = " + r;
}

@PostMapping("/user")
public String createUser(@RequestBody String userData) {
    logger.info("Creating user with data: {}", userData);
    return "User created: " + userData;
}

@GetMapping("/error")
public String error() {
    logger.info("Triggering error");
    throw new RuntimeException("Test exception");
}

}2、web- app1package com.example.demo.controller;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.RequestBody;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class ShoppController {

private static final Logger logger = LoggerFactory.getLogger(ShoppController.class);

@GetMapping("/shopping")
public String hello(@RequestParam(defaultValue = "苹果") String commodity) {
    logger.info("Processing hello request for: {}", commodity);
    return "commodity, " + commodity + "!";
}

@PostMapping("/user")
public String createUser(@RequestBody String userData) {
    logger.info("Creating user with data: {}", userData);
    return "User created: " + userData;
}

@GetMapping("/error")
public String error() {
    logger.info("Triggering error");
    throw new RuntimeException("Test exception");
}

}从上面可以看到我们在web-app的应用中的hell接口中调用了web-app1的shopping接口，且web-app的接入方式是无代码入侵形式的RestTemplate，主要是依赖agent对asm对增强能实现对trace调用透传
图片
且web-app和web-app1两个进程起来时要通过-javaagent方式将agent的探针无入侵的方式接入应用中而-DappId时接入的应用id，用于跟踪tarce所在的应用和构建应用的拓扑图
图片
五、验证触发接口
图片

图片

图片
至此可以通过Agent的探针实现对应用无入侵式，实现调用链的APM 监控、构建应用的拓扑图，并切基于Agent Advice 的增强方式可以进一步实现对中间件的跟踪和观测，如接入DB的观测。

Centos虽然已经停止维护了，而且内核也非常低，耐不住国内大环境很多公司还是一直在用它。时不时见到有人想要在centos上面部署k8s1.23版本,本文将以centos 7为例，从0开始搭建k8s+ks集群。

1.说明

关于kt

kt是基于kk二次开发的产物，具备kk的所有功能。二开主要为适配信创国产化环境、简化arm部署过程和国产化环境离线部署。支持arm64和amd64架构国产操作系统，已适配芯片+操作系统 如下。

kt新增功能点

  • 适配arm架构harbor和支持，部署体验与X86一样简单。

  • 离线环境部署增强。常用国际和国产操作系统依赖，内置到安装包中。已适配芯片和操作系统如下

    • ./kt init-os 一条命令完成操作系统依赖安装和初始化操作。
    • CPU：鲲鹏、飞腾、海光、兆芯、intel、amd等。
    • OS：Centos、Rocky Linux、Ubuntu、Debian、银河麒麟V10、麒麟V11、麒麟国防版、麒麟信安、中标麒麟V7、统信UOS、华为欧拉、移动大云、阿里龙蜥、TencenOS等。

  • 支持开启防火墙，只暴露30000-32767端口，其他k8s端口添加到节点白名单。

    • ./kt firewall 一条命令自动获取节点信息开白名单和防火墙。

kt版本更新和下载地址

  • kt：kt
  • 关注我不迷路

2.环境准备

服务器基本信息

主机名架构OS配置IP
all-in-onex86_64Centos 74核8G192.168.85.164

2.1 上传离线制品

操作系统不需要安装docker,不需要设置selinux,swap等操作，全新的操作系统即可。

将离线制品、配置文件、kt和sh脚本上传至服务器其中一个节点(本文以master为例)，后续在该节点操作创建集群。本文使用kt:3.1.12-centos版本

2.2 修改配置文件

根据实际服务器信息，配置到生成的config-sample.yaml中

kind: Cluster
metadata:
  name: sample
spec:
  hosts:
  - {name: node1, address: 192.168.85.164, internalAddress: 192.168.85.164, user: root, password: "123123"}
  roleGroups:
    etcd:
    - node1
    control-plane:
    - node1
    worker:
    - node1
    # 如需使用 kk 自动部署镜像仓库，请设置该主机组 （建议仓库与集群分离部署，减少相互影响）
    # 如果需要部署 harbor 并且 containerManager 为 containerd 时，由于部署 harbor 依赖 docker，建议单独节点部署 harbor
    registry:
    - node1
  controlPlaneEndpoint:
    ## Internal loadbalancer for apiservers 
    internalLoadbalancer: haproxy

    domain: lb.kubesphere.local
    address: ""
    port: 6443
  kubernetes:
    version: v1.23.17
    clusterName: cluster.local
    autoRenewCerts: true
    containerManager: docker
  etcd:
    type: kubekey
  network:
    plugin: calico
    kubePodsCIDR: 10.233.64.0/18
    kubeServiceCIDR: 10.233.0.0/18
    ## multus support. https://github.com/k8snetworkplumbingwg/multus-cni
    multusCNI:
      enabled: false
  registry:
    type: harbor
    registryMirrors: []
    insecureRegistries: []
    privateRegistry: "dockerhub.kubekey.local"
    namespaceOverride: "kubesphereio"
    auths: # if docker add by `docker login`, if containerd append to `/etc/containerd/config.toml`
      "dockerhub.kubekey.local":
        username: "admin"
        password: Harbor@123 # 此处可自定义，kk3.1.8新特性
        skipTLSVerify: true # Allow contacting registries over HTTPS with failed TLS verification.
        plainHTTP: false # Allow contacting registries over HTTP.
        certsPath: "/etc/docker/certs.d/dockerhub.kubekey.local"
  addons: []
  ---

2.3 系统初始化

解压kt-centos.tar.gz文件后执行./kt init-os -f config-sample.yaml 已适配操作系统和架构见1.说明

该命令kt会根据配置文件自动判断操作系统和架构以完成所有节点的初始化配置和依赖安装。

3 创建 Harbor私有仓库

3.1 创建镜像仓库

./kt init registry -f config-sample.yaml -a artifact-x86-k8s12317-ks3.4.1.tar.gz

此命令会在harbor节点自动安装docker和docker-compose

3.2 创建harbor项目

<font style="background-color:rgb(255,245,235);">说明：</font>

<font style="background-color:rgb(255,245,235);">Harbor 管理员账号：</font><font style="background-color:rgb(255,245,235);">admin</font><font style="background-color:rgb(255,245,235);">，密码：</font><font style="background-color:rgb(255,245,235);">Harbor@123</font><font style="background-color:rgb(255,245,235);">。密码同步使用配置文件中的对应password</font>

<font style="background-color:rgb(255,245,235);">harbor 安装文件在 </font><font style="background-color:rgb(255,245,235);">/opt/harbor</font><font style="background-color:rgb(255,245,235);"> 目录下，可在该目录下对 harbor 进行运维。</font>

创建 Harbor 项目

chmod +x create_project_harbor.sh && ./create_project_harbor.sh

4 创建k8s和KubeSphere

./kt create cluster -f config-sample.yaml -a artifact-x86-k8s12317-ks3.4.1.tar.gz

此命令kt会自动将离线制品中的镜像推送到harbor 私有仓库

执行后会有如下提示,输入yes/y继续执行

等待一段时间，直至出现熟悉的等待安装完成的小箭头>>--->

期间可以另开一个窗口用以下命令查看部署日志

kubectl logs -n kubesphere-system $(kubectl get pod -n kubesphere-system -l 'app in (ks-install, ks-installer)' -o jsonpath='{.items[0].metadata.name}') -f

继续等待一段时间最终可以看到安装成功的消息

5 验证

登录页面

集群管理

监控告警

配置文件默认只安装了监控，如果需要安装其他组件，可以自行在自定义资源中开启

开发者朋友们大家好：

这里是 「RTE 开发者日报」 ，每天和大家一起看新闻、聊八卦。我们的社区编辑团队会整理分享 RTE（Real-Time Engagement） 领域内「有话题的技术」、「有亮点的产品」、「有思考的文章」、「有态度的观点」、「有看点的活动」，但内容仅代表编辑的个人观点，欢迎大家留言、跟帖、讨论。

本期编辑：@瓒an、@鲍勃

01 有话题的技术

1、Vibecraft 发布：Claude Code 的 3D 可视化工具，数据纯本地运行

开发者 @nearcyan 近日发布了「Vibecraft」，这是一款专为 Claude Code 打造的 3D 可视化应用程序。它支持用户通过全新的六边形网格布局，实时查看并管理 Claude 实例。

为了保障数据安全，该应用采取了严格的本地化运行模式，直接与用户计算机上的 Claude Code 实例同步。这意味着所有的文件与代码数据均完全保留在本地，不会被发送至任何网络服务器，从而确保了开发过程的隐私安全。

体验链接：

https://vibecraft.sh/

( @nearcyan@X)

2、智谱 GLM-4.7-Flash 模型发布并开源，可免费调用

智谱 GLM-4.7-Flash 模型今日正式发布并开源。

GLM-4.7-Flash 是一个混合思考模型，总参数量为30B，激活参数量为3B，作为同级别 SOTA 模型，为轻量化部署提供了一个兼顾性能与效率的新选择。

即日起，GLM-4.7-Flash 将替代 GLM-4.5-Flash，在智谱开放平台 BigModel.cn 上线，并供免费调用。

在 SWE-bench Verified、τ²-Bench 等主流基准测试中，GLM-4.7-Flash 的综合表现超过 gpt-oss-20b、Qwen3-30B-A3B-Thinking-2507，在相同和近似尺寸模型系列中取得开源 SOTA 分数。

在内部的编程实测中，GLM-4.7-Flash 在前、后端任务上表现出色。在编程场景之外，官方也推荐用户在中文写作、翻译、长文本、情感 / 角色扮演等通用场景中体验 GLM-4.7-Flash。

需要注意的是，上一代免费语言模型 GLM-4.5-Flash 将于 2026 年 1 月 30 日下线，用户需要及时将模型编码更新为最新版本。GLM-4.5-Flash 正式下线后，相关请求将会自动路由至 GLM-4.7-Flash。

Hugging Face:
https://huggingface.co/zai-org/GLM-4.7-Flash

魔搭社区：

https://modelscope.cn/models/ZhipuAI/GLM-4.7-Flash

（@智谱）

3、华为云发布 CodeArts Doer 代码智能体：个人版免费开放，开启「编码自动驾驶」

2026 年 1 月 16 日，华为云正式发布代码智能体「CodeArts Doer」。这款产品深度集成了 AI IDE、Code Agent 及 Codebase 代码仓深度理解能力，旨在通过「人+AI+工具」的协同模式，为开发者开启「编码自动驾驶」体验。

为了重构传统的开发工作流，CodeArts Doer 以 AI 原生为起点构建了 AI IDE。它不再局限于单一的代码补全，而是能够支持从需求描述、任务拆解到代码落地的全流程闭环。这种设计让开发者可以专注于业务判断与关键决策，将高频重复的工程化工作交由 AI 处理，从而解决了以往需要在多窗口间频繁切换寻找工具的痛点。

在具体的编码执行层面，CodeArts Doer 提供了两种差异化模式以适应不同诉求。「探索模式」侧重人机协同与创造力，开发者通过自然语言即可规划项目任务并生成项目级代码，适合快速将想法转化为可运行版本；而「规范模式」则更强调质量与一致性，在代码生成过程中严格对齐标准流程与安全校验，确保交付的稳定性。

针对 AI 编码在生产环境中常遇到的「看似正确实则不适配」难题，产品特别强化了 Codebase 能力。通过支持百万行级代码索引与知识图谱构建，它能够准确理解代码仓结构、依赖关系及演化历史。这使得 AI 即使在复杂的业务边界内，也能提供贴合项目现实的建议，帮助新老成员快速定位与上手。

目前，CodeArts Doer 代码智能体个人版已正式面向开发者开放免费体验，覆盖了项目级代码生成、研发知识问答及单元测试生成等核心场景。

相关链接：
https://www.huaweicloud.com/product/codeartside/snap.html

（@华为云开发者联盟）

02 有亮点的产品

1、OpenAI 或正测试新产品、首款硬件设备计划今年下半年亮相

据 BleepingComputer 报道，OpenAI 近日被发现启用了以「sonata」为域名前缀的新子域名，外界推测这可能对应一项正在测试中的 ChatGPT 新功能或新产品。

相关记录显示，sonata.openai.com 于 1 月 16 日首次出现，sonata.api.openai.com 则在 1 月 15 日被发现，意味着 OpenAI 已在主站与 API 体系中同步启用该前缀，通常指向内部测试中的新服务或面向用户的网页工具。

报道指出，OpenAI 新增域名往往对应尚未公开的产品页面、内部工具或 Web 应用。尽管「sonata」一词本身常用于指代多乐章器乐作品，但其含义并不限定于音乐领域，因此目前尚无法据此判断功能方向。

除新域名外，OpenAI 近期也在持续更新 ChatGPT 的现有能力，包括「引用聊天记录」功能，当用户开启后，ChatGPT 在检索旧对话细节时将更为可靠，并会在回答中标注引用来源，便于用户回溯上下文。

此外，据 Axios 报道，OpenAI 全球事务负责人 Chris Lehane 今天在达沃斯的 Axios House 活动上表示，OpenAI 正按计划推进其首款硬件设备，目标是在今年下半年亮相。

这也是继去年收购前苹果设计主管 Jony Ive 创办的公司后，OpenAI 首次给出更明确的时间窗口。

Lehane 将「设备」列为 OpenAI 今年的重点方向之一，但并未透露任何外观、形态或交互方式。此前多份报道提到，OpenAI 正在测试无屏幕的小型原型机，可能以可穿戴方式与用户互动。

Sam Altman 曾表示，这款设备将比智能手机更「平和」，并以极简设计为核心。

Ive 团队在去年被收购时发布的宣传视频中也曾暗示 2026 年的发布节点，称「我们期待明年与大家分享我们的工作」。

Lehane 在活动中补充称，OpenAI 正「考虑在今年后段推出某些东西」，但仍保留调整空间，强调最终时间取决于研发进展。他并未承诺设备会在今年正式开售。

( @APPSO)

2、字节跳动旗下扣子 2.0 正式发布，全球首发 AI Agent 技能商店

昨天，字节跳动旗下智能体平台「扣子（Coze）」发布 2.0 版本重大升级，并同步推出全球首个面向普通用户的 AI 技能商店（Coze Skills）。

此次更新围绕 Agent Skills、Agent Plan、Agent Office、Agent Coding 四大能力展开，旨在让 AI 从被动回答工具，进一步进化为可长期协作的职场伙伴。

  • Agent Skills：将可复用的工作经验封装为可被智能体随时调用的标准化技能包；
  • Agent Plan：根据用户目标自动拆解步骤并持续执行、推进长期任务；
  • Agent Office：在办公场景中自动处理文档、表格与信息整理等日常工作；
  • Agent Coding：提供从构建到部署的一站式智能体开发与运维能力。

扣子方面称，2.0 版本的目标是让 AI 不仅能帮你做，更能替你做完。随着技能、长期任务与开发平台的整合，扣子希望推动 AI 在职场场景中承担更多执行与分析工作，让用户将精力集中在策略与创造上。

( @APPSO)

3、「自然选择」融资 3000 万美元，阿里、蚂蚁布局 AI 陪伴

据「暗涌 Waves」独家获悉，AI 陪伴公司「自然选择」（Nature Select）已于近期完成超 3000 万美元的新一轮融资。本轮投资阵容豪华，由阿里巴巴、蚂蚁集团、启明创投、五源资本、创世伙伴创投及云时资本联合投资，星涵资本担任独家财务顾问。

在 AI 陪伴赛道上半年一度遇冷的背景下，「自然选择」凭借核心产品《EVE》呈现的全新形态突围。不同于传统 C.ai 类产品的被动响应，《EVE》强调具备独立意志的「主动发起」，并通过引入 3D 视觉与游戏化设计极大地提升了沉浸感。这种破次元 Agent 甚至能在达到一定亲密度后，直接在现实中为用户点奶茶。据暗涌 Waves 了解，这类打破虚拟与现实边界的体验，或许是阿里等投资方共同入局的原因之一。

为了实现这种双商兼具的拟人体验，团队采取了独特的技术路径。他们不仅设立了情感交互设计师岗位，还发布了首个情感大模型 Echo-N1，首次将强化学习应用于主观情感领域。针对关键的记忆难题，团队将早期的动态记忆槽位的长时记忆方案升级为多维 graphRAG，创始人 Tristan 直言 「记忆系统的本质是推荐系统」，并据此构建了更符合人类直觉的回忆与遗忘机制。

2025 年中以来，AI 陪伴赛道愈发拥挤，而「自然选择」目前看来呈现的核心优势在于：既为 AI 公司，有完整的 post-training 团队和长期记忆之类的专家系统；也有游戏公司背景，能做 3D 视觉和恋爱游戏化设计。但每个人类个体对于情感都有不尽相同的需求，这场瞄准最人类部分的 AI 商业大战，也只是刚刚开始。

基于此，Tristan 将公司的终极目标设定为「迎接硅基生命降临，并创造一个人与 AI 共存的世界」。

（@暗涌 Waves）

4、小米 AI 眼镜新版本内测：支持录音中按键拍照，蚂蚁阿福上线

1 月 19 日消息，小米社区今日开启小米 AI 眼镜新版本内测招募，特邀 200 名米粉，预计在 2026 年 1 月 21 号统一审核。

升级内容：

  • 上线精选智能体：蚂蚁阿福健康管家，眼镜随时变身你的 AI 医生朋友
  • 录音总结升级，支持录音中按键拍照，一键生成图文总结
  • 支持语音创建日程提醒，到期时小爱会主动播报
  • 优化小爱图像问答效果
  • 修复其他已知问题
  • App 需更新至 v2.6.0 或以上版本

（@极客公园）

5、Listen Labs 完成 6900 万美元 B 轮融资：AI 智能体自动化执行深度客户访谈

「Listen Labs」近日宣布完成6900 万美元 B 轮融资，由 Ribbit Capital 领投，估值达 5 亿美元。在短短 9 个月内，该公司将年化收入提升了 15 倍。其核心突破在于利用 AI 智能体自动化执行深度客户访谈，有效解决了传统问卷调查太浅与人工访谈太慢的两难困境。

为了实现定性调研深度与定量规模的结合，Listen Labs 推出了具备「追问能力」的视频访谈智能体。不同于僵化的选择题问卷，该 AI 能与受访者进行开放式视频对话，并根据回答实时生成追问以挖掘真实想法。针对行业普遍存在的刷单现象，其「Quality Guard」系统结合 LinkedIn API 身份校验与视频逻辑检测，成功帮助合作方 Emeritus 将调研中的虚假及低质量数据比例从 20% 降至接近 0。

这种技术带来的效率提升在实际应用中得到了验证。微软利用该平台，将原本耗时 6-8 周的用户故事收集工作缩短至 24 小时内；水杯品牌 Simple Modern 也在 4.5 小时内完成了 120 人的新产品概念测试。目前，平台已向企业用户开放，采用 B2B 订阅或项目制计费，服务客户涵盖 Microsoft、Sweetgreen 和 Chubbies 等。

支撑这一技术体系的是一支拥有极高「含码量」的团队——公司 30% 的工程师为国际信息学奥赛（IOI）奖牌得主，且即便是市场运营岗位也优先录用工程师，旨在用技术逻辑重构业务流程。

本轮融资后，团队计划从 40 人扩充至 150 人，重点研发「合成用户」功能，即基于历史数据构建数字孪生受访者，从而实现 「自动写代码-自动访谈-自动迭代」的自动化闭环。

( @VentureBeat)

03 有态度的观点

1、Shopify CEO：别把创业者「放进创始人托儿所」

据《商业内幕》报道 ，Shopify CEO Tobi Lütke 近日在播客节目《Founder's Podcast》中表示，许多公司在收购后往往低估创业者的经验价值，将他们边缘化，甚至形容这种做法像是把创始人「放进创始人托儿所」。

Lütke 指出，创业者通常具备独特的思维方式与解决问题的能力，但不少企业会将他们安排到组织边缘，或分配到所谓的「skunk work team」（秘密工作小组）。

他直言，这种做法是在「把最能指出问题的人隔离起来」，并强调「你不能把他们放进创始人托儿所」。

他提到，这种情况在 Shopify 于疫情期间的收购整合中曾出现。意识到问题后，他主动提升被收购公司创始人在组织内的存在感，甚至让他们在管理层级中拥有更高的影响力。

他还透露，自己与这些创始人保持一个 Slack 频道，用于交流产品与业务问题。

Shopify 近年来的收购包括 2022 年的物流公司 Deliverr、同年的网红营销平台 Dovetale，以及 2024 年的企业沟通平台 Threads。

报道指出，Dovetale 与 Threads 的创始人目前仍在 Shopify 担任产品相关角色，而 Deliverr 的 CEO 则在加入一年后离开，重新创办物流创业公司。

在节目中，Lütke 还提到，他在招聘时会特别询问候选人「你是否创办过公司」，因为这能帮助他判断对方在危机情境中的适应能力与执行力。

( @APPSO)

阅读更多 Voice Agent 学习笔记：了解最懂 AI 语音的头脑都在思考什么

写在最后：

我们欢迎更多的小伙伴参与 「RTE 开发者日报」 内容的共创，感兴趣的朋友请通过开发者社区或公众号留言联系，记得报暗号「共创」。

对于任何反馈（包括但不限于内容上、形式上）我们不胜感激、并有小惊喜回馈，例如你希望从日报中看到哪些内容；自己推荐的信源、项目、话题、活动等；或者列举几个你喜欢看、平时常看的内容渠道；内容排版或呈现形式上有哪些可以改进的地方等。

作者提示：个人观点，仅供参考

https://www.bilibili.com/video/BV1QLkTBCEEk/?aid=115903282814...

NVIDIA RTX PRO™ 2000 Blackwell 是节能高效、外形小巧的解决方案，能够加速专业的图形和 AI 工作负载。采用突破性的 Blackwell 架构 和 16 GB 超高速 GDDR7 显存，那么对比上一代 NVIDIA RTX™ 2000 Ada 具体性能有哪些提升？本文将从核心参数、跑分测试、渲染性能以及主流工业设计软件表现多个维度，进行一次全面的对比分析，供大家参考。

1.参数对比
图片

2.测试数据测试环境
图片

测试内容
图片

图形性能

1、SPECviewperf 2020 v3.0

SPECviewperf是一个专业级、符合工业标准的OpenGL图形显卡效能测试分析软件，使用C语言编写，用于测量运行在OpenGL应用程序接口之下硬件的3D图形性能。其中包含了 3ds max、catia、creo、energy、maya、medical、snx、solidworks 共8款软件的性能测试。
图片
从测试结果来看：RTX PRO 2000 相较 RTX 2000 Ada 综合提升约 37％。

2、3D Mark

3DMark是一个由UL开发的智能设备性能评测软件，可用于评测设备的3D图形渲染能力。我们主要测试了 Port Royal 和 Speed Way 两个场景。
图片

在 Port Royal 场景中，RTX PRO 2000 相较 RTX 2000 Ada 提升约 56％；在 Speed Way 场景中，RTX PRO 2000 相较 RTX 2000 Ada 提升约 45％；

3、V-Ray Benchmark 6.00.01

V-Ray Benchmark 是一款免费的独立渲染速度测试软件，用于测试计算机的渲染速度。
图片

RTX PRO 2000 相较 RTX 2000 Ada 提升约 63％。4、OctaneBenchOctaneBench 是一种专有基准测试工具（也是当今最流行的GPU渲染基准测试），用于测量以每小时OctaneBench 点数（OBh）表示的GPU渲染速度，用于标准化和基准测试GPU性能。
图片
RTX PRO 2000 相较 RTX 2000 Ada 提升约 52％。

渲染性能

1、Blender
图片
RTX PRO 2000 相较 RTX 2000 Ada 提升约 35％。

2、Houdini
图片
RTX PRO 2000 相较 RTX 2000 Ada 提升约 120％。

3、Maya
图片
RTX PRO 2000 相较 RTX 2000 Ada 提升约 34％。

4、UE5
图片
RTX PRO 2000 相较 RTX 2000 Ada 提升约 20％。

5、NVIDIA Omniverse™
图片
RTX PRO 2000 相较 RTX 2000 Ada 提升约 96％。

AI 性能

1、Stable Diffusion
测试项目：FLUX 文生图
生成尺寸：1024*1280
图片
RTX PRO 2000 相较 RTX 2000 Ada 提升约 35％。

2、ComfyUI
测试项目：FLUX 文生图
生成尺寸：1280*720
图片
RTX PRO 2000 相较 RTX 2000 Ada 提升约 46％。

测试项目：Hunyuan3D 模型生成
图片
RTX PRO 2000 相较 RTX 2000 Ada 提升约 30％。测试项目：Wan2.2 图生视频
图片
RTX PRO 2000 相较 RTX 2000 Ada 提升约 59％。

工业软件性能

为确保评测结果的可量化与可比性，本次测试明确以下核心指标：

  • 模型载入速度：从启动软件、选择目标模型到完全加载就绪的总耗时，单位为 “秒”，数值越小表现越优；
  • 实时操作流畅度：模型编辑、三维旋转 / 平移 / 缩放时的画面流畅度，按照反应速度设定为“卡顿”、“流畅”和 “非常流畅”。
  • 工程图生成效率：针对含复杂标注、剖切视图、明细表的工程图，从发起生成指令到完整渲染显示的耗时，单位为 “秒”，数值越小效率越高；
  • 渲染性能：指定输出分辨率与渲染质量（高保真模式），完成单帧渲染的总耗时，单位为 “分钟”，数值越小渲染速度越快；
  • 仿真稳定性：针对大型模型开展长时间连续仿真，记录无崩溃、无掉帧、无卡顿的持续运行时长，同时监测显卡温度、功耗变化，评估长期负载下的稳定性。

1、UG NX 应用测试

UG NX 作为面向高端制造的三维设计软件，在复杂装配体设计、多物理场仿真等场景中应用广泛，本次选取五类模型，从简单到复杂覆盖不同负载需求，详细测试内容见下表：
图片
测试结果：
图片
在中小模型场景测试中，两款显卡均能很好地满足设计需求，RTX PRO 2000 和 RTX 2000 Ada在载入速度与操作流畅度方面差异较，性能差异在10%以内，RTX PRO 2000 略占优。

2、Solidworks 性能测试

Solidworks 以易用性与兼容性著称，广泛应用于通用机械、模具设计等领域，本次测试选取两款模型，贴合不同用户的实际应用场景。
图片
测试结果：
图片
在中小模型场景中，两张显卡均表现出色，编辑、旋转、缩放等操作非常流畅，RTX PRO 2000 和 RTX 2000 Ada 性能差距较小，在高保真渲染操作中，RTX PRO 2000 比 RTX 2000 Ada 要快8秒，且整个过程流畅、无报错或卡顿现象。

申请显卡测试https://my.feishu.cn/share/base/form/shrcnEmbNj6oRKsQ58SNldkb...
*与 NVIDIA 产品相关的图片或视频（完整或部分）的版权均归 NVIDIA Corporation 所有。
图片

Redis 已超越“单纯内存 KV 缓存”的角色，成为企业级、可扩展的高速缓存与实时数据平台。通过多种缓存模式（cache-aside、read/write-through、write-behind、prefetch 等）、企业级特性（Active-Active/CRDT、Redis on Flash、持久化与 SLA）、以及模块化生态（RedisGears、RediSearch、RedisJSON、RedisBloom 等），Redis 能在低延迟（sub-millisecond）同时支撑大规模流量与复杂一致性需求，是现代“systems of engagement”架构中的核心组件。

为什么需要企业级缓存
现代应用趋向“系统参与”（systems of engagement），对实时性、可伸缩性与高可用性的要求远高于传统系统；缓存把慢速系统（磁盘、传统 RDB）常用数据“移到近端”，以实现亚毫秒响应。对于企业级应用，单纯开源 Redis + 自研运维往往难以满足跨地域高可用、数据持久化、成本可控（大数据集内存成本）等需求；Redis Enterprise 提供扩展（线性扩容）、99.999% SLA、以及分层存储（RAM + Flash）以降低成本。
核心缓存模式（Patterns）
Cache-aside
应用先查缓存（Redis），若 miss 则去后端读取并回写缓存。适用于读多写少、可容忍偶发缓存不一致的场景（例如商品详情、配置、用户画像片段）。实现简单、延展性好，但一致性由应用负责。
图片
伪代码

val = redis.get(key)if not val:
    val = db.read(key)
    redis.set(key, val, ex=ttl)return val

Read/Write-Through 与 Write-Behind（Inline / 背写）
Write-through：写操作同步经缓存到后端数据库（保证一致性，但写时延增加）。
图片
Write-behind（Write-back）：写先写缓存，然后后台异步落库以提升写性能，但存在短期不一致/丢失风险，需可靠的异步机制与重试策略（例如使用 Redis Streams + 后台 worker）。RedisGears/rgsync 提供了可用的 write-behind / write-through recipe，方便把 Redis 中的变化可靠写入关系型数据库。
图片
Query Caching（SQL/查询结果缓存）对重复执行的 SQL 或昂贵查询缓存完整结果集或经过序列化的结果（注意分页、权限、排序等变化）。适合“相同查询多次”场景，常配合 cache-aside。
图片
Prefetch / Cache Warming（主动预热）对于“读多写少”的仪表盘、前端账户总览等场景，建议把热点数据按策略提前写入缓存（比如定时任务、事件驱动同步），以避免冷启动或突发流量造成后端压力。移动银行示例中常用此策略把账户总览、余额等读多数据预先放入 Redis。
图片
典型用例实践
金融行业缓存应用
在金融行业，特别是银行系统中，Redis缓存已成为支撑高并发业务的核心组件。江苏省联社在新一代移动金融综合服务平台中，使用Redis中间件进行热点数据缓存，显著降低了数据库访问压力，提升了应用吞吐量。该平台整合了个人手机银行、企业手机银行和各类生活服务应用，通过Redis缓存支撑了转账汇款、贷款理财、生活缴费等高并发业务场景。
中原银行则基于Redis构建了分布式缓存平台，创新性地实现了多租户机制，允许多个微服务系统使用同一套Redis集群而数据互不影响。这种设计既节省了服务器资源，又简化了集群管理。此外，中原银行还基于Redis实现了分布式锁功能，支持自动续约机制，避免了因业务执行时间过长引发的锁冲突问题。
分布式会话管理
在分布式系统架构中，Redis提供了可靠的分布式会话管理能力。通过将会话数据存储在Redis集群中，不同应用实例可以共享用户状态，实现真正的无状态应用架构。实践中，通常会自定义SessionManager，支持通过HTTP头部token传递sessionId，实现前后端分离架构下的会话管理：

public class ShiroSessionManager extends DefaultWebSessionManager {
    public final static String HEADER_TOKEN_NAME = "token";
    
    @Override
    protected Serializable getSessionId(ServletRequest request, ServletResponse response) {
        // 从Header中获取sessionId
        String id = WebUtils.toHttp(request).getHeader(HEADER_TOKEN_NAME);
        if (!StringUtils.isEmpty(id)) {
            request.setAttribute(ShiroHttpServletRequest.REFERENCED_SESSION_ID, id);
            request.setAttribute(ShiroHttpServletRequest.REFERENCED_SESSION_ID_IS_VALID, Boolean.TRUE);
            return id;
        }
        return super.getSessionId(request, response);
    }
}

小结
Redis作为一种多功能的内存数据存储，在现代应用架构中提供了多样化的缓存解决方案。从基础的全页面缓存到复杂的延迟消息队列，从简单的会话存储到企业级的分布式缓存平台，Redis展现了其卓越的性能和灵活性。
通过合理的架构设计、监控管理和优化策略，Redis缓存能够显著提升应用性能，降低后端数据库压力，为高并发、低延迟的业务场景提供有力支撑。随着云原生和微服务架构的普及，Redis在缓存领域的重要性将进一步提升，成为构建高性能应用不可或缺的基础组件。

做量化交易系统的后端开发，最怕的不是算法太难，而是数据源“太脏”或者粒度不够。

作为开发者，你一定遇到过这种情况：前端图表展示用K线绰绰有余，但后端撮合引擎如果也只用K线数据，那简直就是灾难。因为K线丢失了时间维度的时序性。

从工程角度看Tick数据的必要性 Tick（逐笔成交）数据，本质上是时间序列数据库里最基础的原子单位。在系统架构设计中，引入历史Tick数据主要为了解决两个工程痛点：

  1. 事件驱动的回测准确性：基于Bar（K线）的回测是粗粒度的，无法模拟Tick级别的撮合逻辑。
  2. 异常排查：当线上策略出现非预期亏损，你需要一份精确到毫秒的“系统日志”来还原当时的行情切片。

如何优雅地获取并“消费”Tick数据？ 很多同学拿到Tick数据的第一反应是存起来再算。其实更高效的做法是流式处理或切片回放。这就要求上游接口必须足够稳定且结构规范。

这就涉及到接口选型的问题。如果每个交易所的API你都要写一套解析脚本，维护成本会极高。在工程实践中，推荐使用那些已经做过“归一化”处理的聚合接口，比如 AllTick API 这类服务，它直接返回标准化的JSON结构，能让你把精力集中在策略逻辑（Business Logic）上，而不是消耗在ETL（数据清洗）上。

import requests
import pandas as pd

API_KEY = "YOUR_API_KEY"
symbol = "AAPL.US"

url = "https://apis.alltick.co/stock/historical/tick"
params = {
    "symbol": symbol,
    "limit": 500
}

headers = {
    "Authorization": f"Bearer {API_KEY}"
}

resp = requests.get(url, headers=headers, params=params)
ticks = resp.json().get("ticks", [])

df = pd.DataFrame(ticks)
df["time"] = pd.to_datetime(df["time"])

print(df.head())

数据消费建议 代码跑通后，建议大家把重点放在数据落地上。不要一上来就搞复杂的各种因子计算。先试着把Tick数据可视化，观察一下在极短时间窗口内的价格跳动逻辑。你会发现，很多K线上看似合理的支撑位，在Tick级别其实是脆弱不堪的。

作者：中国联通软件研究院 · 计费结算中心 张兴宇

整理排版：蚂蚁密算 曾辉

本文整理自隐语第三届嘉年华现场演讲，中国联通软件研究院基于隐语，从最初的对账试点出发，打造了一套可复制、可监管的跨域协作体系。详细介绍了对等组网、数据分级计算、规则上链存证等工程实现细节，并总结了实际推进中最难解决的部分：不是技术，而是多方协作。最终，这不仅是一套系统架构，更是一种行业共建的新模式。

行业技术背景

在数据要素流通全面提速的背景下，我们在一线工程实践中越来越清晰地感受到：数据安全已经不再只是“合规约束”，而正在直接决定业务是否还能继续发展。

过去很多跨域协作的方式，本质上是把“数据怎么拿到一起”作为默认前提：先汇聚、再计算、最后补合规。但随着监管要求、数据安全责任、以及跨主体协作复杂度同步提升，这条路径越来越难走——尤其是在通信行业这种数据粒度细、规模大、敏感字段多、跨主体协作频繁的场景里。

因此，“原始数据不出域、可用不可见”并不是一个愿景口号，而是在通信行业中，被真实业务一步步推到了工程实现与生产落地阶段。更重要的是，它不是“加一层安全能力”这么简单，而是在重新定义协作方式：从“拿到数据再处理”，转向“在不拿到数据的前提下完成协作”。

从宏观层面看，这一变化并非偶然，而是由多重因素共同驱动：

  • 国际层面：隐私保护被视为基础性权利，跨域数据流通不再允许“事后补救”。企业必须具备可验证、可审计、可追溯的工程能力，能够说明“数据如何被使用、结果如何产生、责任如何界定”。
  • 国家层面：可信数据空间建设持续推进，强调在安全前提下释放数据价值，对“安全可用”提出工程级、规模化的要求——不仅要能跑通，还要能稳定运行、可推广复制、可持续运营。
  • 公众层面：数据泄露事件频发，公众关注点从“合不合规”转向“是不是真的可控”。对企业提出更刚性的可信技术需求：不仅要遵循规则，更要让规则可验证。

当这些因素叠加到通信行业，问题被进一步放大：亿级数据规模 + 跨域协作刚需 + 合规红线不可突破，使得传统集中式技术路径开始系统性失效。

行业技术痛点

在通信行业，跨运营商协作并不是“要不要做”的问题，而是长期存在、无法回避的业务事实。

例如网间详单级对账、跨域核验与监管支撑，本质上都依赖多方数据协同完成。它们的共同点是：
协作主体多、协作频次高、规则变化快、且必须在规定窗口内完成闭环。

但现实约束同样非常清晰，而且是工程层面的硬约束：

  • 规模苛刻：数据规模达到亿级甚至数十亿级，且粒度为详单级——不是汇总报表，而是逐条核验、逐条比对；
  • 敏感性极高：数据包含用户标识、话单明细、财务相关字段等敏感信息，无法集中、无法明文外传；
  • 协作环境复杂：跨组织、跨省、跨网络协同，参与方系统异构、治理边界不同，协作很难靠人工“对齐”。

这直接导致一个结果：大量在实验室或PoC阶段“跑得通”的技术路线，在运营级业务中根本撑不住。

能“算出来”只是起点，真正的门槛是能否长期稳定地跑、能否支撑规则变化、能否可运维、可审计、可回溯、可复制。

技术选型

正因为如此，我们在技术选型阶段，并没有把问题定义为“用不用隐私计算”，而是明确了一条更严格的原则：不是“能不能用”，而是“能不能长期跑在运营级业务中”。

这里的“运营级”，意味着它必须同时满足一组工程特征： 稳定性（可长期运行）、时效性（窗口内闭环）、可运维（可定位可回溯）、可扩展（规模上得去）、可治理（规则可控可审计）。

围绕这一目标，我们从工程视角对主流技术路线进行了系统评估，核心维度包括：

  • 合规可行性是否真实可控：能否做到原始数据不出域、最小暴露、边界清晰；
  • 工程成熟度是否支撑长期运行**：是否具备任务编排、失败恢复、运行监控等工程化能力；
  • 在亿级数据规模下的扩展性与性能边界：是否存在可持续的调优路径；
  • 对规则型、批量型业务的适配能力：是否能表达“规则驱动的查询/比对”，并支持快速迭代；
  • 技术与生态是否具备可持续演进能力：组件、文档、社区活跃度、可维护性与可扩展性。

在详单级、亿级规模的密态对账场景中，我们最终选择了隐语SecretFlow，原因是它在真实业务约束下，在工程可演进性与场景贴合度上更接近可持续落地路径——尤其适配规则型密态计算与结构化数据协作的工程需求。

项目演进里程碑

回顾整个建设过程，这并不是一蹴而就的体系设计，而是一条伴随业务演进不断调整的工程路径：

  • 2020 年：从运营商之间的报表级对账起步，引入区块链实现可信交付，解决“过程可信、结果可追溯”的基础问题；
  • 2023 年初：详单级对账需求出现，传统集中式方案在合规层面全面受限，开始引入SecretFlow，探索“原始数据不出域”的可行路径；
  • 2023 年中：基于SecretFlow构建可信数据空间下的密态数据交互平台，将密态协作从概念推进到工程实现；
  • 2024 年：完成与运营商的跨空间组网，在广东、江苏、宁夏等省完成试点部署，逐步形成可运行、可运维、可持续的生产闭环；
  • 当前阶段：从单场景试点演进为系统化能力输出，联合多方构建协同生态网络。

这条路径背后的关键词只有一个：即从小场景、可验证边界切入，用标准和规则把复杂度压缩到可控范围内，再逐步扩大规模与覆盖范围。

平台总体架构

在这个过程中，我们并没有一开始就设计一个宏大的“总体架构”。
相反，所有能力都是在真实业务中不断试错、修正、打磨后沉淀下来的。

随着场景逐步稳定，一套可以被复用和推广的方法体系逐渐清晰，也就是现在对外呈现的 中国联通“113N”可信数据空间体系蓝图。

这套体系的出发点不是“平台建设”，而是可信协作如何真正落地：

  • 一套统一的空间标准：用于解决跨主体协作的共识问题，让参与方在身份、标识、规则、接口、审计等方面形成统一约束；
  • 一批关键技术攻关：面向隐私计算、安全审计、跨域协同等核心能力，确保不仅能跑通，也能跑稳、跑久；
  • 三项建设内容：围绕空间能力建设、基础设施对接与治理运营体系，形成稳定可控的建设框架；
  • 最终支撑N个持续演进的业务场景：让新场景不再从零开始，而是基于标准与组件复用扩展。

目标并不只是“搭一个系统”，而是通过真实场景把工程能力跑顺、把规则跑稳，形成可复制、可持续的协作模式。

空间治理架构

随着实践深入，我们逐渐意识到一个关键问题：可信协作不是一个系统能力，而是一种结构性能力。

如果把可信协作只落在单一系统里，短期看似集中统一，但一旦参与方变多、场景变多、规则变多，就会面临治理边界不清、责任难划分、扩展成本高的问题。

因此，在工程实现中，我们没有将所有能力集中到单一平台，而是将协作拆解到不同层次、不同类型的可信数据空间中：

  • 通过统一的身份、标识与治理规则，先解决“谁能参与、如何建立信任”的基础问题；
  • 再让行业空间、城市空间、企业空间围绕真实业务场景各自运行和演进；
  • 在统一规则下实现跨空间连接与协同，随着参与主体与场景增加逐步生长为协作网络。

这种方式的好处在于：参与方无需大规模改造现有系统、无需暴露原始数据，就可以在统一规则下持续协作，同时治理边界更清晰、扩展更自然。

技术架构

在技术架构层面，我们始终坚持三条不可妥协的原则：

  • 原始数据不出域：原始数据始终在本域，跨域只发生必要的密态交互；
  • 按需计算：并非所有数据都走同一种计算模式，而是根据敏感等级与业务目标选择最合适的协作方式；
  • 结果可验证：不仅给出结果，还要让结果“可解释、可审计、可追溯”。

以隐语SecretFlow为核心，结合Kuscia等组件，支撑跨域联合作业、精密分析与账单核算。这不是“为了用隐私计算而用隐私计算”，而是业务约束下的工程选择。

技术方案——跨运营商详单级对账

从工程视角看，跨运营商对账的核心，是将传统集中式对账流程，拆解为一条可以在密态环境下长期稳定运行的计算流水线。

整体思路是：各参与方仍然在本地结算系统中生成详单数据，在进入计算前完成字段标准化与规则映射，确保计算语义一致；进入隐私计算阶段后，原始数据不出域，通过SecretFlow承载的密态计算能力执行规则驱动的对账逻辑。

关键工程特性包括：

  • 规则可配置、可拆分：对账规则不是写死的脚本，而是可配置规则集合，能够支持逐条与批量、并行执行；
  • 过程可中断、可回溯、可复跑：面对十亿级数据，必须具备断点续跑、失败恢复、分段复核能力；
  • 输出最小化：只输出差异结果与必要校验信息，避免“结果汇聚导致二次泄露”；
  • 关键过程与摘要结果链上存证：解决结果可信与审计追溯问题，使协作具备可验证闭环。

这不是算法展示型方案，而是围绕高并发、规则复杂、长期运行场景做过充分工程约束的生产级实现。

在工程设计上，我们将跨运营商对账定义为双向对等、可验证的协同执行过程，而不是单向“算完给结果”。

发起方与审核方各自在本地运行隐私计算节点，执行同一套对账规则。系统输出可校验的对账报告与差异摘要，并通过链上机制固化关键结果，确保任何一方都无法事后篡改关键结论。

如存在差异，可在密态下进行定位、复核与调整，而不是重新全量重跑。
最终形成原始数据不出域、结果可验证、过程可追溯的对账闭环，也使其能够在运营级场景中长期稳定运行。

关键技术能力——面向不同数据敏感等级的跨域协作实现方式

针对不同敏感等级的数据，我们采用分级协作策略：

  • 高敏数据（详单、用户资料、财务相关字段）：采用多方安全计算、联邦学习等隐私计算技术，在原始数据不出域前提下完成联合计算与分析；
  • 中低敏数据（可脱敏或业务中台数据）：采用沙箱运行环境，在确保安全的同时提升效率；
  • 规则与结果类数据：敏感性相对较低，但对不可篡改性要求高，采用智能合约方式进行上链存证，确保可追溯、可审计。

生产部署架构与跨域互联方式

各运营商在本地可信数据空间内部署隐私计算节点，跨域协作通过专线网络和统一安全接入区完成。

工程上强调“最小暴露面”： 系统仅开放标准协议接口（如gRPC、HTTPS），确保原始数据与计算逻辑始终不出域，同时满足合规要求、运行稳定性与可运维性。

业务成效与行业意义

在业务层面，对账与结算效率发生质变：对账周期从周级、月级压缩至天级，自动化覆盖接近全量，异常更早暴露、更快定位。

在人力与成本层面，大量依赖人工核对、反复沟通的工作被规则化、系统化协作替代，人力投入明显下降，长期成本持续可控，同时资金周转效率同步提升。

更重要的是，这套能力不再局限于单点场景：推动行业从“点对点对账”走向可复制、可推广的数据协同模式，为后续联合分析、联合运营与生态协同打开空间。

构建标准体系

实践中我们深刻体会到：技术不是最大难点，真正的难点在于跨主体长期协作。

因此，我们优先建设可信数据空间的规则底座，通过统一规范，将隐私计算能力固化为可复用、可审计、可监管的协作方式，服务于长期运营。

换句话说，我们要解决的不是“某一次对账能跑通”，而是让协作成为一种长期可运行的机制：规则怎么变、版本怎么管、争议怎么裁、审计怎么做、责任怎么划分，都需要在工程体系内被吸收。

实践方法论

总结来看，我们走出了一条可持续落地路径：

  • 场景共识先行：先把“为什么协作、协作边界在哪、各方收益是什么”讲清楚；
  • 标准驱动试点：用统一规则把复杂问题拆成可验证的小场景，小步快跑；
  • 政策与规则同步：在成熟场景中同步沉淀治理与运营机制，确保长期可跑；
  • 经验沉淀与复用：把成功案例转化为模板、标准与组件，让新场景不再从零开始。

可以概括为：从共识开始，用标准落地，靠规则运行，以经验放大。

我们更愿意将这些成果视为一次行业与社区协同探索的阶段性结果，而不是某一个系统建设的终点。

在整个实践过程中，隐语（SecretFlow）对我们来说不仅是一个“能跑算法的框架”，更像是一套能够承载真实业务约束、支撑工程演进的技术底座：它让隐私计算从“概念可行”走向“工程可用”，也让我们能够在高敏感、高规模、高稳定性要求的生产环境中把协作真正跑起来。

与此同时，真实生产场景也天然会暴露出大量“只有落地才会遇到”的问题：比如规则型计算在密态下如何组织与复用、亿级规模下的任务拆分与并行策略、失败恢复与回溯机制如何设计、跨主体协作的审计与存证如何做到既可信又可运营……这些问题无法靠单次PoC解决，只能在持续运行中逐步打磨。

因此，我们更愿意把“社区共建”理解为一种双向循环：

  • 一方面，依托隐语社区的能力和工程框架，加速我们在通信行业复杂场景中的落地效率；
  • 另一方面，通过跨运营商对账这一高约束场景，把工程实践中遇到的瓶颈与经验持续沉淀为可复用的方法，推动可信协作能力持续演进。

结语

我们相信，可信协作的成熟并不是靠某一次“选型成功”完成的，而是在真实生产场景中一步一步验证： 什么是可执行、可运维、可持续的工程能力；什么样的规则体系能够长期运行；什么样的协作模式能够被复制推广。

面向未来，我们期待与更多行业伙伴和社区开发者一起，把生产实践中沉淀出的经验转化为社区可复用的能力：让更多参与方能够在统一的可信协作框架下参与协作、持续演进，并最终让“数据可用不可见”的理念真正走向——好用、常用、可复制、可持续。

Google 正式发布 Universal Commerce Protocol（UCP，通用商业协议），这是一项开放标准，旨在支持“代理式商业”，也就是由 AI 驱动的购物代理可完成从商品发现、下单结算到售后管理的全流程任务。UCP 同时兼顾零售商与消费者需求，在整个购物旅程中始终以“客户关系”为核心，从最初的商品发现到购买决策乃至购买之后。

UCP 在美国全国零售联合会（National Retail Federation，NRF）年度大会上正式公布。该协议为 AI 代理与商业生态中的后台系统建立了一种安全、标准化的连接方式。企业可以通过 UCP 对外暴露自身能力，并在此基础上扩展诸如折扣等功能；AI 代理则可以通过企业资料动态发现可用服务与支付选项。

在支付设计上，UCP 将支付工具与支付处理方进行解耦，支持多个支付服务提供商。通信层面，协议支持标准 API、Agent2Agent 以及 Model Context Protocol 绑定。Google 还提供了示例实现，包括一个 Python 服务器以及包含商品数据的软件开发工具包，用于展示 AI 代理如何发现商业能力并执行结算流程。

American Express 在 LinkedIn 上发文，强调了该协议在简化商业流程方面的潜力：

Google 推出的 Universal Commerce Protocol（UCP）是一项面向代理式商业的全新开放标准，想减少支离破碎的购物体验，帮零售商与消费者建立更顺畅的连接。UCP 很快将为 Google 搜索的 AI Mode 以及 Gemini 应用中的全新结算体验提供支持。像这样的开放标准，对于构建更安全、更可信的商业体系至关重要。

正如 Google 在一篇深入解析的技术博客中所介绍的，UCP 定义了一系列核心商业能力，包括商品发现、购物车管理、结算流程以及售后工作流。AI 代理可通过查询企业资料来识别可用服务并协商支持的功能，从而减少定制化集成的需求。这种方式既能让企业继续掌控价格、库存和履约逻辑，又能让 AI 代理实现更高程度的自主运行。

UCP 高层架构示意图

在安全架构方面，UCP 通过凭证提供方对支付和身份信息进行令牌化处理，而具体的交易处理则由支付服务提供商完成。这种分离设计使 AI 代理在无需接触原始支付信息或个人数据的情况下即可完成交易。

此外，UCP 具备传输层无关性，既支持标准 API 交互，也支持面向代理的绑定形式，适用于对话式界面、AI 助手和自动化工作流。目前，UCP 的早期实现已出现在 AI 驱动的搜索与助理平台中，符合条件的零售商可以在不跳转至外部网站的情况下，直接向用户提供结算体验。

基于 AI 代理的购买流程演示

UCP 由 Google 与 Shopify、Etsy、Wayfair、Target、Walmart 共同开发，并获得了来自商业生态中 20 多家合作伙伴的支持与背书，其中包括 Adyen、American Express、Best Buy、Flipkart、Macy’s、Mastercard、Stripe、The Home Depot、Visa 以及 Zalando。

在未来规划方面，UCP 的路线图着眼于构建一个覆盖全球、超越单笔交易的统一商业标准。相关计划包括多商品结算、购物车管理、会员与忠诚度计划、订单后流程，以及个性化的交叉销售与追加销售能力，同时继续确保核心商业逻辑掌握在企业自身手中。

目前，UCP 的早期版本已支持美国部分符合条件的零售商在 Google 产品界面内直接完成结算。接下来，该协议还将拓展至印度、印度尼西亚以及拉丁美洲等市场。Google 与合作伙伴也正在广泛征求反馈，以不断完善这一协议，共同塑造可互操作、由 AI 驱动的未来商业形态。

原文链接：

https://www.infoq.com/news/2026/01/google-agentic-commerce-ucp/

相关报道：

“商业版 HTTP”来了：谷歌 CEO 劈柴官宣 UCP，Agent 直接下单，倒逼淘宝京东“拆家式重构”？

作者：子葵

配置中心和注册中心是微服务架构的核心基础设施，承担着关键的配置管理和注册发现职责。然而在实际生产中，部分企业的注册配置中心可能面临安全风险：如权限管理粒度不足、操作审计缺失，这可能导致未授权访问或误操作，进而影响业务的稳定运行。

image

你是否也曾遇到以下常见痛点？

  • 权限管理挑战： 权限配置过于粗放，难以对不同用户或应用进行精细化授权，导致配置被误改或难以追溯操作者。
  • 鉴权升级顾虑： 考虑开启鉴权，但担心直接切换可能影响大量存量应用，造成服务中断，使得安全与业务连续性难以平衡。
  • 排查效率低下： 当出现鉴权失败时，缺乏清晰的错误日志和可视化手段，排查问题耗时耗力。

为了有效应对这些挑战，MSE Nacos 推出基于 RAM 的精细化鉴权与审计方案。我们致力于在保障安全性的同时，提供平滑的过渡和直观的可视化能力。

三大核心能力，提升 Nacos 安全性

image

1. 极简运维：RAM 深度集成，权限管理白屏化

告别过去手写复杂 JSON 策略、计算密码 Hash 的繁琐时代。MSE Nacos 与阿里云 RAM（访问控制）深度集成，实现了真正的企业级权限隔离。

  • 一键生成策略： 无需手动编写晦涩的权限脚本。在控制台通过白屏化界面勾选资源，自动生成对应的 RAM 权限策略内容，复制即可在 RAM 控制台完成授权。

  • 精细隔离： 支持 Namespace（命名空间）、Group 甚至 Service/DataId 粒度的权限控制。你可以轻松实现：

    • 运维团队拥有所有环境的读写权限；
    • 开发 A 组只能读写 Dev 环境，对 Prod 环境只有只读权限；
    • 应用 B 只能注册到特定的服务名下，防止服务冒用。
  • 账号复用： 直接复用企业现有的 RAM 子账号体系，无需为 Nacos 单独维护一套用户列表。

image

2. 平滑开启鉴权：支持灰度鉴权，保障业务连续性

针对存量系统开启鉴权可能引发的兼容性风险，我们提供了灰度鉴权功能，确保从“无鉴权”到“有鉴权”的平滑过渡。

  • 宽松验证模式： 开启灰度鉴权后，Server 端会对客户端请求进行身份验证。对于未配置身份信息或身份信息配置错误的客户端，系统不会拦截其请求，确保业务调用不受影响。
  • 风险可视： 虽然系统暂不阻断请求，但会详细记录鉴权失败的错误信息。通过监控大盘或日志，你可以精准识别出哪些客户端尚未正确适配鉴权。

  • 无感升级路径：

    1. 开启灰度鉴权，业务完全无感。
    2. 根据鉴权失败记录，逐步修正客户端的账号密码配置。
    3. 待所有客户端配置无误后，关闭灰度模式（正式开启强鉴权），完成安全升级。

3. 全景监控：鉴权可观测大盘，提升运维透明度

安全不仅要具备防护能力，更需要具备可视化的监控能力。我们提供了全方位的鉴权审计大盘，让每一次访问都有据可查。

  • 全量操作审计： 开启鉴权后，所有的数据操作（如配置的发布、删除、修改，服务的注册、注销）都会被系统自动捕获并记录。每一次变更的操作人（RAM 账号）、操作时间、客户端 IP 均可追溯，确保数据安全无死角。
  • 实时监控： 直观展示集群的鉴权成功率、失败率趋势，帮助运维人员实时掌握安全水位。

  • 精准定位：

    • 来源分析： 支持展示拦截客户端来源 ip，时间，访问资源等信息

image

核心操作流程

简单五步，即可完成从“零鉴权”到“安全闭环”的平滑升级：

  1. 策略生成与配置： 在 Nacos 控制台“认证鉴权”模版中生成权限策略，并在 RAM 控制台授予指定的子账号。
  2. 开启灰度鉴权： 开启 Nacos 实例的“灰度鉴权”开关，进入宽松模式（记录但不拦截）。

  3. 客户端适配发布： 在客户端配置鉴权信息（AccessKey/SecretKey）并发布应用。详细配置过程可以参考文档：

    为 Nacos 实例开启鉴权并配置客户端访问凭证：https://help.aliyun.com/zh/mse/user-guide/access-authenticati...

  4. 大盘观测检查： 检查“鉴权审计大盘”，确认无非预期的拦截记录。
  5. 正式开启鉴权： 确认无误后，关闭“灰度鉴权”开关，正式启用强鉴权模式。

总结

MSE Nacos 鉴权审计方案，旨在为企业提供一套开箱即用、平滑过渡、可视可控的安全基础设施。

image

  • 极简运维： 白屏化配置与策略自动生成，告别繁琐脚本，轻松复用企业 RAM 账号体系。
  • 精细管控： 支持细粒度至 Service/DataId 的权限隔离，严格遵循最小权限原则，保障数据安全。
  • 平滑升级： 独有的灰度鉴权模式，让存量应用在“只记录不拦截”中完成无感适配，消除业务中断顾虑。
  • 全景可视： 全量操作审计与可视化大盘，从鉴权拦截到数据变更，让每一次访问都透明可查。

通过 MSE Nacos，您可以轻松构建企业级零信任安全体系，在保障业务灵活性的同时，彻底解决权限管理粗放与操作溯源难的痛点。

  1. 1
  2. ...
  3. 232
  4. 233
  5. 234
  6. 235
  7. 236
  8. 237
  9. 238
  10. ...
  11. 332