xiaohack博客专注前沿科技动态与实用技术干货分享，涵盖 AI 代理、大模型应用、编程工具、文档解析、SEO 实战、自动化部署等内容，提供开源项目教程、科技资讯日报、工具使用指南，助力开发者、AI 爱好者获取前沿技术与实战经验。
目前一键注册的用户头像存的是第三方 Google 或 Github 的头像 url，这会导致正常访问无法直接显示出 Google 的头像，所以做了一个迁移计划，在今天的合适实际会执行自动迁移，若迁移的头像出现问题可及时和我反馈，迁移前我会记录原头像 url 避免出现错误无法回退。
另外一些优化更新：
各位更新有问题可及时反馈
今天，我们正式开源了 LingBot-Depth 空间感知模型。 不同于数字世界，具身智能的落地高度依赖物理空间信息，空间智能是其在现实场景落地应用的核心关键，而视觉维度下支撑空间智能的重要桥梁正是距离与尺度（Metric Depth）。基于这一核心需求，空间感知模型 LingBot-Depth 应运而生。 LingBot-Depth 是一种面向真实场景的深度补全模型，依托奥比中光 Gemini 330 系列双目 3D 相机进行 RGB-Depth 数据采集与效果验证，并基于深度引擎芯片直出的深度数据进行训练与优化，旨在将不完整且受噪声干扰的深度传感器数据转化为高质量、具备真实尺度的三维测量结果，提升环境深度感知与三维空间理解能力，为机器人、自动驾驶汽车等智能终端赋予更精准、更可靠的三维视觉。 实验结果表明，本模型在深度精度与像素覆盖率两项核心指标上均超越业界顶级工业级深度相机。在 NYUv2、ETH3D 等多个基准测试中，LingBot-Depth 在深度补全、单目深度估计及双目匹配任务上均达到当前最优水平，并在无需显式时序建模的情况下保持视频级时间一致性。LingBot-Depth 模型也已通过奥比中光深度视觉实验室的专业认证，在精度、稳定性及复杂场景适应性方面均达到行业领先水平。 下游任务验证进一步表明，模型能够在 RGB 与深度两种模态之间学习到对齐的潜在空间表征，从而实现对透明及反光物体的稳定机器人抓取。 在涵盖家庭、办公环境、健身房及户外场景的上千万张图像数据上完成训练后，当深度相机传回的数据出现缺失或异常时，LingBot-Depth 模型已能够融合彩色图像（RGB）中的纹理、轮廓及环境上下文信息，对缺失区域进行推断与补全，输出更完整、致密、边缘更清晰的三维深度图。 精准且稳定的相机深度感知 LingBot-Depth 在传统深度传感器易失效的复杂场景中，仍可输出具备真实尺度的高精度深度结果，包括透明物体、玻璃表面以及高反光材质等极具挑战性的环境。不同于依赖硬件改进的方案，本模型从视觉理解层面弥补传感器缺陷，实现对真实三维结构的可靠恢复。 除单帧精度优势外，LingBot-Depth 还表现出优异的时间一致性。在无需显式时序建模的情况下，模型即可为视频输入生成稳定、连贯的深度序列，有效避免闪烁与结构跳变问题，为机器人操作、AR/VR 以及动态场景感知等应用提供可靠的连续空间理解能力。 卓越的 3D 和 4D 环境感知能力 更加准确的结构化室内场景建图，并有效提升相机位姿与运动轨迹估计的精度； 面向机器人学习的可靠 4D 点跟踪能力，在统一的真实尺度空间中同时刻画静态场景几何结构与动态物体运动。这使得系统能够在复杂真实环境中建立一致、连续且可用于决策与交互的空间理解表征。 灵巧抓取操作适用于透明与反光物体 LingBot-Depth 展现出与现有硬件设备的良好适配性。在不更换更高成本传感器的情况下，模型可提升可靠性并降低系统部署门槛。LingBot-Depth 模型依托奥比中光 Gemini330 系列双目 3D 相机进行效果测试，结果显示：面对透明玻璃、高反射镜面、强逆光以及复杂曲面等极具挑战性的光学场景，搭载 LingBot-Depth 后输出的深度图变得平滑、完整，且物体的轮廓边缘非常锐利，效果优于业内领先 3D 视觉公司 Stereolabs 推出的 ZED Stereo Depth 深度相机。 这意味着在不更换传感器硬件的前提下，LingBot-Depth 可显著提升消费级深度相机对高难物体的处理效果，降低机器人因深度缺失与噪声引发的抓取失败与碰撞风险。在具身智能、自动驾驶等领域都有一定应用价值，能够极大程度提升具身操作的精准度。 目前，我们已与奥比中光达成战略合作伙伴关系，将基于 LingBot-Depth 模型推出新一代深度相机，依托 Gemini 330 系列相机提供的芯片级 3D 数据，进一步通过技术协同、生态共建，为机器人处理各行各业极端场景、走向真正落地提供强大的技术支撑。 LingBot-Depth 已成功实现模型轻量化与端侧部署，具备在边缘计算设备上高效运行的能力。未来，我们期待通过开源开放与生态合作，和广大合作伙伴一起加速具身智能在家庭、工业、物流等复杂场景的大规模应用落地。 目前我们的模型、代码、技术报告已全部开源，欢迎大家访问我们的开源仓库。 后续我们还将开源 300 万对精心标注的 RGB-深度数据，包括 200 万对实拍 RGB-D 样本，和 100 万对渲染样本，推动空间感知技术的开源生态建设和技术创新。 LingBot-Depth 的开源标志着我们在空间智能领域迈出的第一步。本周，我们还将陆续为大家带来我们在具身智能领域智能基座方向的更多成果，我们期待与全球开发者、研究者、产业伙伴一起，共同探索具身智能的上限。
注解：在最具挑战的稀疏深度补全任务中，LingBot-Depth 性能整体优于现有多种主流模型。（图中数值越低代表性能越好。）01技术架构：创新的掩码深度建模范式
在家庭和工业环境中，玻璃器皿、镜面、不锈钢设备等透明和反光物体物体十分常见，但却是机器空间感知的难点。传统深度相机受制于光学物理特性，在面对透明或高反光材质时，往往无法接收有效回波。针对这一行业共性难题，我们研发了“掩码深度建模”（Masked Depth Modeling，MDM）技术。训练过程中，我们使用海量 RGB–深度图像对，但刻意遮挡其中一部分深度区域，让模型仅根据 RGB 图像去预测缺失的深度值。随着训练进行，模型逐渐学会建立“外观—几何”之间的对应关系，也就是从“物体看起来像什么”推断“它大概有多远”。02 核心亮点
LingBot-Depth 为下游空间感知任务提供了坚实而通用的基础能力。通过将含噪且不完整的传感器深度优化为干净、稠密且具备真实尺度的三维测量结果，模型显著提升了多种高层视觉任务的稳定性与精度。具体而言，LingBot-Depth 支持：
通过在统一潜在空间中联合对齐 RGB 外观信息与深度几何结构，LingBot-Depth 使机器人在以往难以处理的复杂场景中实现稳定可靠的操作能力。基于模型优化后的高质量深度结果及跨模态对齐特征，我们进一步训练了一种基于扩散模型的抓取位姿生成策略，在透明杯、反光金属容器等具有挑战性的物体上取得了较高的抓取成功率。在真实机器人测试中，在透明储物盒等传统传感器难以处理的场景中，LingBot-Depth 通过生成合理的深度估计，成功实现了 50% 的抓握率，突破了技术瓶颈。
点击查看视频03 从实验室到落地应用：显著提升消费级深度相机对高难物体的处理效果
!上传中...
注解：搭载 LingBot-Depth 后，奥比中光 Gemini 330 系列在透明及反光场景下深度图的完整性和边缘清晰度明显提升
注解：奥比中光 Gemini 330 系列相机搭载 LingBot-Depth 后输出的深度图效果优于业界领先的 ZED 深度相机Website：
https://technology.robbyant.com/lingbot-depth
Model：
https://huggingface.co/robbyant/lingbot-depth
Code：
https://github.com/Robbyant/lingbot-depth
Tech Report：
https://github.com/Robbyant/lingbot-depth/blob/main/tech-report.pdf
生成式 AI 的投资回报远超预期？Snowflake 调研全球 1900 位企业与 IT 专业人士后发现平均 ROI 高达 41%！点击下载完整报告 AI Copilot 和自主智能体的崛起正在重新定义开发者的意义。在 BUILD 2025 的一场重磅主题分享中，Vercel CEO 和 Next.js 的创始人 Guillermo Rauch 深入探讨了 AI 如何改变开发者的体验。AI 将我们的角色从编写代码转变为有意图地引导智能系统。在这个未来中，AI 原生工具将大大提升开发者的生产力、创造力和规模。 Guillermo Rauch 从自身经历出发，系统性地拆解了 AI 浪潮下，开发范式正在发生的结构性变化。这并非一场关于工具或技巧的演示，而是一份面向当代开发者的生存指南：当技术能力不再稀缺，什么才是决定长期价值的核心能力？他的判断很明确，我们正经历一场从“页面”走向“Agent”的转型，其深度与影响，堪比第一代互联网的诞生。 Rauch 回顾了 Vercel 的起点。2014 年，当开发者仍需在路由、编译器、集群和部署细节中反复挣扎时，真正能高效构建和交付产品的，只有少数拥有内部基础设施的大公司。 Vercel 以及 Next.js 的诞生，本质上是一次“能力下放”，让原本只属于头部公司的开发效率，成为更广泛开发者的默认能力。 而今天，类似的分化正在 AI 领域重演。 他指出，支撑第一代 Web 的云基础设施，本质上是“为页面而生”的：优化加载速度、依赖 CDN、围绕一次性请求与响应展开。但在 Agent 驱动的应用形态中，这套逻辑开始失效。新的应用形态不再以页面为中心，而是以持续运行、长时间“思考”、多步骤编排的智能体为核心。 因此，云的目标也随之发生变化： 算力不再只追求“更快返回”，而是要支持更长时间、更复杂的推理； 基础设施不再围绕页面分发，而是围绕“token 流动”和智能调用； 搜索和触达不再依赖排名，而是通过 Agent 主动嵌入到用户的工作场景中。 在这一意义上，他将新的基础设施形态称为“面向 Agent 的云”。 与基础设施变化同步发生的，是用户界面的根本转型。 传统的软件界面是确定性的：开发者可以精确控制每一个像素，预期用户将看到什么、点击什么、进入哪条路径。但在 AI 时代，界面正在变成生成式和自适应的，按需生成、随上下文变化，并高度个性化。 Rauch 特别强调，这并不意味着前端或用户体验的重要性下降，恰恰相反，体验比以往任何时候都更重要。变化的只是如何构建体验：从事先设计好所有界面，转向在需要时即时生成最合适的呈现方式。 他以 Snowflake 与 Vercel 的生成式 UI Agent（V0）的集成为例：复杂的数据分析结果，可以在对话中即时生成可视化界面，让非技术用户也能理解。这背后的趋势，是行业从“代码优先”逐步迈向“代码后置”，代码不再是价值本身，而是服务于结果的一种中间形态。 如果说基础设施和界面的变化，重塑了怎么构建，那么更深层的变化在于——谁可以参与构建。 Rauch 认为，软件开发正在从一项高度专业化的技能，转变为一种普遍能力。过去，门槛在于语法、工具链、基础设施；而现在，门槛正在转移到一个新的维度：意图是否清晰。 在 AI 的帮助下，表达能力本身成为新的基础素养。会不会写代码，正在被能否准确表达你想要什么所取代。他将这种变化视为 JavaScript 普惠化的升级版：如果说框架和平台曾让大量前端开发者成为云工程师，那么 AI 则让更多非技术背景的人，第一次具备了构建软件的能力。 在这种背景下，个人技能的价值排序正在被重写。Rauch 提出了一个残酷但现实的判断：不要过度依附于某一项具体技能。正如心算曾经是优势，但最终被机器超越，编程技能也正在进入类似阶段。 真正重要的，是他所说的“元技能”。 在 AI 可以生成无限方案的时代，开发者真正需要承担的角色，不是代码执行者，而是判断者与交付者。 Rauch 将“交付（Shipping）”视为当代开发者最关键的元能力。它不等同于写代码，而是一种端到端的综合能力：从问题判断、产品设计、实现方式，到测试、迭代、讲清楚价值，并持续提高标准。 在他看来，AI 不只是提升效率的工具，更应该服务于质量。他反复强调一个立场：更快地生成代码，不应成为降低交付标准的借口。相反，真正的竞争力在于，同时提高生产力与质量。 围绕这一判断，他给出了具体的实践方向：将 Agent 用于客服、风控、内容生成、数据分析等场景，让系统承担重复性工作，把人的时间留给真正影响产品和业务走向的决策。随着系统从“被接受、被修改、被拒绝”的反馈中不断学习，质量门槛本身也会随时间抬升。 最终，他将 Agent 的意义概括为一句话：消除创意与现实之间的壁垒。 在这场分享的结尾，Rauch 并未给出下一步该学什么工具的清单，而是抛出了一个更本质的问题：当工具已经就位、模型已经成熟，你真正要思考的，是你准备交付什么样的产品、什么样的价值。 AI 时代的开发者体验，不再只是写更少的代码，而是能否以更高的标准，把想法真正带到现实世界中。从“页面的云”到“Agent 的云”
界面没有消失，只是变成了生成式
当谁能写代码不再重要
交付，正在成为最核心的元能力
在鸿蒙应用的开发过程中，状态管理一直是我们绕不开的话题。如果你是从 API 9 或 API 10 一路走来的老兵，一定经历过被 @Observed 和 @ObjectLink 支配的恐惧。那时候，我们想要监听一个嵌套在对象深处的属性变化，简直就是一场噩梦。 假设你有一个 在 HarmonyOS 6 (API 20) 中，ArkUI 团队终于为我们带来了状态管理的 V2 版本，其中 @ObservedV2 和 @Trace 的出现，彻底粉碎了嵌套对象监听的痛点，让我们终于可以像写原生 JS 一样自然地操作数据了。 在深入 V2 之前，我们有必要回顾一下 V1 版本状态管理的局限性，这样你才能深刻体会到新特性的甜头。在 V1 中，状态管理的粒度通常停留在 对象引用 级别。这意味着，框架只关心这个对象是不是原来那个对象，或者这个对象的一级属性有没有变。一旦数据结构变得立体，比如数组里套对象，对象里又套对象，框架的感知能力就会断崖式下跌。 为了让 UI 响应深层数据的变化，我们过去不得不构建一种 洋葱式 的组件结构。父组件持有 这导致了一个后果：哪怕是一个简单的表单页，可能都需要拆分成七八个细碎的自定义组件。这不仅增加了代码的复杂度，还让组件之间的通信变得异常繁琐。而如果我们偷懒不拆组件，就只能通过 HarmonyOS 6 引入的 @ObservedV2 和 @Trace，采用了全新的代理（Proxy）机制，将监听的粒度精确到了 属性 级别。这就像是给每一个需要关注的数据字段都安装了一个微型的传感器，无论它被嵌套得有多深，只要数值发生变化，传感器就会立即向 UI 发送更新信号。 使用这套新机制非常直观。首先，我们需要用 @ObservedV2 类装饰器来标记一个类，告诉框架：这个类产生的实例是需要被深度观察的。接着，对于类中那些会影响 UI 显示的核心属性，我们给它们加上 @Trace 装饰器。 注意，这里有一个巨大的思维转变。我们不再需要把所有属性都变成状态，只有那些真正和界面绑定、变化时需要触发重绘的属性，才需要加 @Trace。这种按需监听的设计，从根源上减少了不必要的渲染消耗。 我们可以看看下面这段定义代码，它展示了如何构建一个可深度监听的数据模型. 在上面的代码中，不管是 当你在组件中直接执行 除了对象嵌套，数组操作也是 V1 版本的一大痛点。以前我们必须使用 ArkUI 提供的特定数组方法，或者把数组项封装成 当你将一个数组标记为 这种 数组结构变化 与 元素内部变化 的双重监听能力，让列表类数据的处理变得异常丝滑。我们不再需要为了更新列表里的一行文字而被迫刷新整个列表数据。 虽然 V2 极其强大，但在使用时也有一些规则需要遵守。首先，@ObservedV2 只能装饰 在使用中我们要养成 精细化控制 的习惯。不要习惯性地给类里的所有属性都加上 @Trace，只给那些 UI 真正用到的属性加。比如一个用于内部逻辑计算的临时 ID 或者缓存数据，就不应该加 @Trace，这样可以减轻框架的代理负担。此外，V2 的状态追踪是基于实例的，如果你直接替换了整个对象实例，那么新实例必须也是由 @ObservedV2 装饰的类创建的，否则监听链条就会断裂。 下面是一个完整的实战案例，模拟了一个“智能家居控制面板”的场景。在这个场景中，我们有一个家庭对象，里面包含多个房间，每个房间又有独立的设备。通过 V2 的深度监听，我们可以直接在父组件修改最深层的设备状态，观察 UI 是如何丝滑响应的。 从 V1 到 V2，鸿蒙的状态管理机制完成了一次从 粗放 到 精准 的进化。@ObservedV2 和 @Trace 的组合，让我们彻底摆脱了为了做数据监听而扭曲组件结构的尴尬境地。 现在，我们可以按照最符合业务逻辑的方式去设计数据模型，无论嵌套多少层，无论数据结构多么复杂，ArkUI 都能像手术刀一样精准地定位到变化点并更新视图。这对于构建大型、复杂交互的鸿蒙应用来说，是必须要掌握的核心能力。前言
User 对象，里面包含一个 Address 对象，当你试图修改 user.address.city 时，你会发现界面纹丝不动。为了解决这个问题，我们被迫把 Address 拆分成一个独立的子组件，或者暴力地重新赋值整个 Address 对象来触发更新。这种为了技术限制而通过增加组件层级来妥协的做法，不仅让代码变得臃肿，更带来了不必要的性能开销。
一、 告别 V1 时代的“洋葱式”更新
User，子组件持有 Address，孙子组件持有 Street。每一层都必须严格使用 @ObjectLink 进行传递。this.user.address = new Address(...) 这种“换血”的方式来强制刷新，这无疑是在用大炮打蚊子，性能损耗极大。二、 @ObservedV2 与 @Trace 的精准打击
// 定义一个深层嵌套的设置类
@ObservedV2
class Settings {
@Trace theme: string = 'Light';
@Trace fontSize: number = 14;
constructor(theme: string, fontSize: number) {
this.theme = theme;
this.fontSize = fontSize;
}
}
// 定义用户类，嵌套了 Settings 类
@ObservedV2
class User {
@Trace name: string;
@Trace age: number;
// 嵌套的复杂对象，只要 Settings 类被正确装饰，这里无需特殊处理
@Trace settings: Settings;
constructor(name: string, age: number, settings: Settings) {
this.name = name;
this.age = age;
this.settings = settings;
}
}User 还是嵌套在内部的 Settings，都被标记为了 V2 的观察对象。this.user.settings.theme = 'Dark' 时，ArkUI 能够精准地捕获到这个深层属性的变化，并只更新依赖了 theme 属性的那一部分 UI，而不会导致整个 User 卡片甚至整个页面的重绘。三、 数组与集合的深度监听
@ObjectLink 组件才能监听到增删改查。而在 V2 中，@Trace 同样适用于数组属性。@Trace 后，框架会自动代理这个数组的 push、pop、splice 等变更方法。更令人兴奋的是，如果数组中的元素本身也是 @ObservedV2 装饰过的对象实例，那么修改数组中某一个元素的属性（例如 this.users[0].name = 'New Name'），也能直接触发 UI 更新。四、 最佳实践与注意事项
class，不能用于接口或简单对象。其次，V2 的状态变量通常配合 @Local（组件内部状态）或 @Param（组件参数）在 UI 组件中使用，这替代了 V1 中的 @State 和 @Prop。import { promptAction } from '@kit.ArkUI';
// =========================================================
// 1. 数据模型定义
// =========================================================
@ObservedV2
class SmartDevice {
@Trace name: string;
@Trace isOn: boolean;
@Trace powerConsumption: number;
constructor(name: string, isOn: boolean, power: number) {
this.name = name;
this.isOn = isOn;
this.powerConsumption = power;
}
}
@ObservedV2
class Room {
@Trace name: string;
@Trace devices: SmartDevice[] = [];
constructor(name: string, devices: SmartDevice[]) {
this.name = name;
this.devices = devices;
}
}
@ObservedV2
class SmartHome {
@Trace familyName: string;
@Trace rooms: Room[] = [];
constructor(familyName: string) {
this.familyName = familyName;
}
}
// =========================================================
// 2. 主界面组件
// =========================================================
@Entry
@ComponentV2
struct DeepObservationPage {
@Local myHome: SmartHome = new SmartHome('鸿蒙未来家');
aboutToAppear(): void {
const livingRoom = new Room('客厅', [
new SmartDevice('主灯', true, 50),
new SmartDevice('空调', false, 1200),
new SmartDevice('电视', false, 200)
]);
const bedroom = new Room('主卧', [
new SmartDevice('床头灯', false, 10),
new SmartDevice('空气净化器', true, 45)
]);
this.myHome.rooms.push(livingRoom, bedroom);
}
build() {
Column() {
// 1. 顶部标题
Text(`${this.myHome.familyName} 控制中心`)
.fontSize(24)
.fontWeight(FontWeight.Bold)
.margin({ top: 40, bottom: 20 })
// 2. 设备列表区域
List({ space: 16 }) {
ForEach(this.myHome.rooms, (room: Room) => {
ListItem() {
Column() {
Text(room.name)
.fontSize(18)
.fontWeight(FontWeight.Bold)
.width('100%')
.padding({ left: 12, bottom: 12, top: 4 })
.border({ width: { bottom: 1 }, color: '#F0F0F0' })
ForEach(room.devices, (device: SmartDevice) => {
Row() {
Column() {
Text(device.name)
.fontSize(16)
.fontWeight(FontWeight.Medium)
.fontColor('#333')
Text(`能耗: ${device.powerConsumption}W`)
.fontSize(12)
.fontColor('#999')
.margin({ top: 4 })
}
.alignItems(HorizontalAlign.Start)
// 开关控制
Toggle({ type: ToggleType.Switch, isOn: device.isOn })
.onChange((value: boolean) => {
// V2 深度监听核心：直接修改属性，UI 自动刷新
device.isOn = value;
})
}
.width('100%')
.justifyContent(FlexAlign.SpaceBetween)
.padding(12)
.backgroundColor(device.isOn ? '#F0F9FF' : '#FFFFFF')
.borderRadius(8)
.animation({ duration: 300 })
})
}
.padding(12)
.backgroundColor(Color.White)
.borderRadius(16)
.shadow({ radius: 8, color: '#0D000000', offsetY: 2 })
}
})
}
.layoutWeight(1)
.padding({ left: 16, right: 16 })
.scrollBar(BarState.Off)
// 3. 底部按钮
Button('一键关闭所有设备')
.width('90%')
.height(48)
.backgroundColor('#FF4040')
.shadow({ radius: 10, color: '#4DFF4040', offsetY: 5 })
.margin({ bottom: 20, top: 10 })
.onClick(() => {
let turnOffCount = 0;
this.myHome.rooms.forEach(room => {
room.devices.forEach(device => {
if (device.isOn) {
device.isOn = false;
turnOffCount++;
}
});
});
promptAction.showToast({
message: turnOffCount > 0 ? `已关闭 ${turnOffCount} 个设备` : '所有设备已关闭'
});
})
}
.width('100%')
.height('100%')
.backgroundColor('#F1F3F5')
}
}
五、 总结
在构建金融交易系统时，我们常说“天下武功，唯快不破”。但在外汇交易的实战开发中，很多开发者往往卡在了第一步：如何优雅且高效地获取实时数据？ 前阵子我在优化一个即时汇率换算模块，目标是同时监听 USD/JPY 和 EUR/USD 的波动。需求很明确：低延迟、低资源占用、高稳定性。 传统的 requests.get() 轮询方案在这里是行不通的。每一次 HTTP 请求都要经历三次握手、传输、断开，这种开销对于高频变化的行情数据来说是巨大的浪费。而且，你很难控制轮询的频率——太快了服务器当你是 DDoS，太慢了又捕捉不到瞬间的插针行情。 解决这个问题的标准答案就是 WebSocket。它允许建立一次连接后保持双向通信，服务器有新价格直接推送到客户端。我在对比了几个 API 文档后，选择了 AllTick API 作为演示对象，主要是看重它在断线重连和数据包结构的简洁性上做得比较符合开发直觉。 首先，摒弃复杂的框架，回归最基础的 websocket-client。 接下来的核心代码涉及三个回调函数：on_open（建立连接时订阅）、on_message（接收数据）、on_error（错误处理）。 当你订阅了多个货币对时，数据流的压力会变大。 在处理这些并发数据时，我的经验是：千万不要在 on_message 里做耗时的计算逻辑。先把数据塞进队列（Queue）或者存下来，计算逻辑另起线程处理，否则会阻塞心跳，导致连接断开。 从 HTTP 转向 WebSocket，本质上是思维方式从“主动查询”到“事件驱动”的转变。如果你手头也有类似的监控需求，不妨试试上面的代码。你会发现，当数据流实时涌入控制台的那一刻，整个系统的“手感”完全不同了。pip install websocket-client requestsimport websocket
import json
def on_message(ws, message):
data = json.loads(message)
print(f"{data['symbol']} | {data['price']} | {data['time']}")
def on_open(ws):
subscribe_msg = {
"action": "subscribe",
"symbols": ["EURUSD", "USDJPY"]
}
ws.send(json.dumps(subscribe_msg))
ws = websocket.WebSocketApp(
"wss://api.alltick.co/forex/realtime",
on_open=on_open,
on_message=on_message
)
ws.run_forever()import csv
from datetime import datetime
def save_tick(data):
with open("forex_tick.csv", "a", newline="") as f:
writer = csv.writer(f)
writer.writerow([
datetime.now(),
data["symbol"],
data["price"]
])
subscribe_msg = {
"action": "subscribe",
"symbols": ["EURUSD", "USDJPY", "GBPUSD", "AUDUSD"]
}
本文介绍我对 Clawdbot / Moltbot AI 个人助手的尝鲜使用。有蹭热度嫌疑，喜干货者慎入 :) 最近大热的 Clawdbot(现改名为 Moltbot) 是一个人 AI 助手，主打个人 Self-Hosted 的 ai agent。可运行在您自己的设备上的 AI 助手。不管你在哪里，均可以通过国际上常用的 IM 聊天平台（WhatsApp/Telegram/Matrix 等等，但不包括 WeChat）通过聊天与 ai agent 进行互动。 如果你硬要我说点非市场炒作的人话，不要老打鸡血天天震撼和炸裂，回归朴素码农实用主义的话。那么问题的核心是：这所谓的 “新” 玩意，和之前的支持本地部署的，做点 hack 也可以互联网访问的 lobehub / librechat 甚至更久远的 open-webui 这类已经支持 MCP 工具 的 LLM chat UI 有什么区别？ 说实话，在我短短数小时的安装和使用时间里，我只能告诉大家一些基本概念和功能上的不同，也因了解时间有限，说得不对请纠正： 看完这些，你大概会联想起 Manus 或 OpenManus 。 网上已经非常多安装手把手教程了。所以我不打算写教程了，这里只说说我使用的一些配置： 综合考虑到网络环境的难和付款的便利，我选择了 openrouter 以及 配置文档： 配置示例： 注意，直接用 CN 的 source ip 是访问不了 openrouter 的 claude-sonnet-4.5 的，会 http status 403 : 是有点贵，不过先试试再找平替吧。 这里只是简单试用一下 AI 助手对工具的智能调用能力。还不错。不过 UI 设计还是有待改进的。很工程师风的界面用户体验。不过这界面叫 Dashboard ，这个风格也说得过去吧。 计划后面试试接入适合国情的 Matrix IM ，看看效果。例如，我收到 Prometheus 报警 Homelab 问题时，可以让 Moltbot 自动分析原因和自动修复。也可以接入语音 TTS/STT ，甚至图像识别等等。有进度也会分享分享。再见。Just another chatbot ?
安装
anthropic/claude-sonnet-4.5 模型 。https://docs.molt.bot/providers/openrouter
{
env: { OPENROUTER_API_KEY: "sk-or-..." },
agents: {
defaults: {
model: { primary: "openrouter/anthropic/claude-sonnet-4.5" }
}
}
} This model is not available in your region简单试用
计划
2026 年 1 月，在操作智能领域权威评测体系 OSWorld 发布的最新榜单中，九章云极 DataCanvas 凭借在 Alaya NeW Cloud 强化学习平台上训练的 DART-GUI-7B 模型，以卓越的智能操控表现，一举夺得 OSWorld 7B 赛道冠军！ Alaya NeW Cloud 是由九章云极打造的以强化学习（ Reinforcement Learning, RL ）为核心能力的智算云平台，该平台通过将强化学习能力深度融入底层基础设施，重构了智能计算的架构与逻辑，旨在为企业和开发者提供“可用、好用、经济”的算力资源。 Alaya NeW Cloud 打造前沿强化学习云平台，平台原生支持一键式 Agentic RL 开发环境启动 、分布式极核 Agentic RL 训练，性能上实现训推分离与全流程加速，生态上预置多种主流 Agent 仿真环境，高效支撑强化学习技术的快速落地与创新突破，精准解决 AI 技术应用中的效率和成本等核心问题。目前，九章云极已在全球布局多个聚焦于加速计算优化的 AIDC 智算中心，持续赋能 AI 技术的高效应用与行业规模化落地。 DataCanvas Alaya NeW Cloud 什么是 OSWorld？ OSWorld 是目前 AI 领域衡量 “智能体（ Agent ）跨软件操作电脑” 能力最顶尖的基准测试，它模拟真实的操作系统环境，要求 AI 像人类一样通过视觉观察屏幕，并精准操控浏览器、Excel 、VS Code 等各类桌面应用来完成跨平台的复杂任务，被 OpenAI 、Anthropic 、字节跳动 Seed 、月之暗面、智谱等顶尖 AI 团队广泛采用，更是检验 AI 能否从“只会聊天”进化为“高效数字员工”的硬核试金石。 为什么 OSWorld 对 7B 模型几乎是“地狱难度”？ 真实生态：任务在 VS Code 、LibreOffice 等真实软件中运行，环境信息密度远超结构化数据 闭环操控：需要连续理解截图、规划路径和进行键鼠操作，考验长程推理能力 零容错率：限时 30 步，操作需步步为营，失败不可逆转 数据稀疏：基础成功率不足 1/4，即使是大模型也面临严峻挑战 复杂的跨软件协作与精细的坐标控制，使得参数规模有限的 7B 模型在“理解”与“执行”之间难以调和，长期处于“不可用”状态。 九章云极并未通过简单扩大模型规模取胜，而是选择了系统级的算法创新。提出了 DART（ Decoupled Agentic Reinforcement Training ），首次将 GUI 智能体的强化学习训练流程彻底解耦为四个异步模块： 三项关键突破 推演级轨迹调度（ Rollout-Level Scheduling ）： 以“单条轨迹”作为调度最小单位； 每个 rollout 完成后立即释放环境并启动下一个任务； 环境利用率提升从 12.2% 达到 67.7%，提升幅度高达 5.5 倍。 动态模型服务池（ Dynamic Model Serving Pool ）： 采用 GPU 推演的集中化管理，支持多模型版本的热加载； 避免了传统“一卡一环境”的资源浪费； GPU 推演利用率提升 1.6 倍； GPU 资源的并发弹性扩展能力。 训练与推理异步执行（ Asynchronous Execution of Training and Inference ）： 训练与推演实现异步解耦； 避免模型更新导致服务阻塞。 针对 GUI 强化学习中的“成功少、噪声多”核心难题，DART 设计了覆盖任务、轨迹、步骤和 Token 的四层筛选机制： 这一机制使得 7B 模型，在最大 30 步内，即可稳定的实现 OSWorld 中的任务要求。 九章云极经过强化学习训练的 7B 模型之所以能实现突破，关键在于采用了“场景适配、精度优化、算力协同”的三维技术方案，在控制参数量的同时，最大化提升操作智能性能： 场景化指令对齐技术：基于百万级真实操作场景数据训练，构建细分领域的指令库，优化模型对办公自动化、数据处理等高频场景的语义理解能力，精准捕捉模糊指令背后的核心需求，使指令理解准确率较通用模型提升 23 %，并减少无效操作； 混合精度推理优化：借鉴智算硬件优化经验，对模型不同模块进行精度分层处理。核心推理模块保留 FP16 精度以确保准确性，非核心模块量化至 INT8 精度。这一调度方式实现推理效率提升 1.8 倍，资源占用率降低 40 %； 软硬件协同调度机制：依托自研的智算技术栈优势，深度协同模型推理与算力资源，动态调整算力分配策略以应对负载波动，避免资源闲置。同时使用专用推理加速引擎优化 GUI 元素识别与动作规划的计算链路，进一步降低轻量化模型的推理延迟。 在最大步长仅有 30 步的情况下，DART-GUI-7B 在多种任务类型上表现出显著优势，包括： 浏览器类（ Chrome ）； 图像/设计类（ GIMP ）； 邮件客户端类（ Thunderbird ）； 代码/ IDE 类（ VS Code ）； 操作系统交互类（ OS ）。 亮点：GIMP 类任务的正确率高达 80.77 %，且在办公套件（ Impress、Writer、Calc ）、媒体播放类（ VLC ）以及多应用协同等任务中，其能力也有显著提升。 九章云极还进行了真实场景的验证。在 DataCanvas Alaya NeW 平台上，DART-GUI-7B 成功地通过键鼠操作完成文档查找、导航到指定页面及查找官网联系方式等场景任务，其成功率超过 90 %。 目前，AI 大模型正加速从“技术验证”向“产业落地”转变。通用人工智能作为连接数字世界与物理操作的重要工具，在办公自动化、智能运维和工业控制等领域展现出广阔的应用前景。然而，模型部署成本高、轻量化模型性能不足及数据出域安全等问题，仍然是产业规模化的关键瓶颈。 九章云极的 7B GUI 模型突破为行业提供了“低成本、高性能”的通用人工智能解决方案，有望推动通用人工智能在中小企业及长尾场景的普及。九章云极：Alaya NeW Cloud 强化学习平台
核心技术解读：轻量化模型的 GUI 智能体突破
核心技术路径：九章云极三大创新赋能轻量化突破
1. 核心方法：解耦式 GUI 智能体强化学习框架
2. 数据策略：四层自适应筛选，放大稀疏成功信号
3. 多维优化：以轻量化参数对冲复杂场景，重塑性能边界
实验结果：全类型任务下性能优势显著
产业价值与未来展望
Vibe Coding 的进化速度，可能还是超乎了我们的想象。 今天，我们在测试 Kimi K2.5 的网页生成功能时，旁边的前端开发同事还以为是真实的网页场景，低声问我：“你这是在写代码吗，还是在摸鱼打游戏？” 直到我说出这是 AI 生成的，而且是只用了几句话就做出来的效果，这让她大为惊讶。 该网页长这样，现在如果不明说的话，确实已经难辨“真假”。 Kimi K2.5 在今天刚刚上新，它没有把重点放在“单项能力突破”上，而是试图把视觉理解、代码生成、交互设计，以及多 Agent 协作，都压进了同一个模型里，一口气提供了四种使用模式。 在笔者看来，其中最有意思的，当属 Agent 集群模式——这也是在国内 AI 上第一次出现的功能，它可以让原本耗时数天的工作，现在仅需十几分钟就能做完，简直是指数级的提效。 比如，要做 100 家公司的市场调研，它能指挥一群不同行业背景的“分析师”分头行动，十几分钟出结果，而不是几个星期；面对 300 页的复杂翻译项目，它能动员一个“语言学专家”团队，快速、准确地完成交付。 四种模式具体如下。不同需求的用户，从随手一问，到需要并行推进的复杂任务，都能找到明确的入口： 快速模式，提供最快的响应体验。 思考模式，可以用来解答复杂问题。 Agent 模式，擅长深度研究、PPT、Excel、Word、PDF 和网页生成等任务——目前 K2.5 已经开始掌握 Office 套件的核心技能，其协助办公的能力不容小觑。 重磅全新模式：Agent 集群模式，适合需要并行处理的复杂任务 另外，新编程产品 Kimi Code不仅能直接在终端里运行，还能无缝集成到 VSCode、Cursor、Zed 这些 IDE 里，支持直接输入图片和视频。 月之暗面 CEO 杨植麟，这次亲自为新模型发布录制了视频。 看起来很强是一回事，那用起来是不是另一回事？以下是各种实操案例，InfoQ 也上手测了几组。 为了测试 Kimi K2.5 的视觉理解能力和 Vibe Coding 水平，我们首先直接甩出一张产品页面截图，再配上几句文字描述，看看它能不能自己看懂、自己理解，顺手还能复刻出一个像模像样的产品页面。 比如让 K2.5 做个一个最近很火的心灵疗愈类项目，给的 Prompt 如下： 模仿情绪疗愈类产品，生成一个情绪记录类 APP，适合年轻人释放情绪，让人一眼觉这里允许脆弱的地方。 可以说，这个 Prompt 提示不多，要求不少，对模型视觉理解能力、逻辑思维、产品思维以及设计审美能力都是考验。 从结果看，K2.5 对“情绪”这个概念本身是有一定理解和思考的。它生成的是一个以沉浸体验为核心的情绪页面，而不是常规的情绪记录工具。 视觉上，明显没走浅色卡片流那条老路，而是用了低对比背景、连续画面和节奏型动效（类似呼吸或旋涡），交互重点放在“停留”和“进入状态”上。 在功能组织上，输入、反馈和过渡是连在一起的：用户不是“点一个按钮开始记录”，而是被自然引导进入输入状态——这种设计说明它在生成时已经考虑了状态流转，而不是只输出一个静态页面。 接下来，我们不再给任何视觉参考，只输入文字提示，让 K2.5 独立完成整个网页设计。 我们给的 Prompt 很简单： 做一个类似 4399 的小游戏平台，要有完整的游戏分类频道； 但视觉审美要大厂级、高端网游风，整体要酷炫、有冲击力，并且可交互。 结果 Kimi K2.5 没让人失望。 它给出的页面并不是“看起来像网页”的静态效果，而是已经具备明确产品结构的原型。相比以往很多生成结果只停留在大色块 + 随机模块的拼接，它能正确理解“小游戏平台”这一产品类型，在首页层面同时给出清晰的分类入口、内容推荐区和主视觉焦点。 视觉风格上，它没有沿用早期生成工具常见的“低饱和扁平模板”，而是接近成熟网游官网或内容平台的布局逻辑，这一点与一些真实产品如大型游戏平台的信息层级更为接近。 更关键的是，这种效果并非通过多轮细化 Prompt 得到，而是在一次相对抽象的指令下完成，说明模型已经开始具备从“需求描述”直接映射到“产品级页面结构”的能力，而不只是做样式渲染。 类似的例子还有不少。下面这些网页，都是 K2.5 在图像生成工具的辅助下，仅凭一条 Prompt直接生成的完整原型。 除了做整个页面，我们还单独测评了一下 K2.5 对动效的理解能力。 左侧是我们输入的一段小视频，右侧是它生成的效果。结果 K2.5 几乎是完整复刻，拖动鼠标，图片会随之产生位移变化，逻辑和节奏都对得上，动效也足够丝滑。 也就是说，K2.5 并不是在“画动效”，而是真的理解了交互在时间维度上的设计意图。 对开发和设计而言，这意味着动效不再从一堆参数和曲线开始，而是可以先把想法直接跑成一个可交互的原型，用几分钟看清值不值得投入工程成本。 至于 K2.5 的 Agent 集群模式，最直观的能力就是：把时间尺度直接拉短了。过去需要“按天算”的复杂任务，现在往往 十几分钟就能跑完一整轮。 来看一个实测例子。 一次性向 Kimi 的 Agent 集群投喂了 40 篇论文，主题横跨心理学与 AI。任务是，在此基础上产出一份系统性的研究综述。 Kimi 的处理流程大致分成了三步：第一步，完整通读。主 agent 多次调用工具，按顺序把 40 篇论文逐篇过了一遍，确保所有关键信息都被纳入同一上下文，而不是零散记忆。 第二步，并行写作。在理解整体结构后，Kimi 自动派生出多个子 agent——可以理解为它的“分身”，分别负责不同章节的撰写，各自并行推进。 第三步，统一收敛。主 agent 最后回到台前，负责校对、取舍和整合，把各个子 agent 的成果汇总成一份长达几十页的专业 PDF 级综述。 整个过程里中，几乎看不到人工干预。 我们先后测评了一整天，总体感受很明确： Kimi K2.5 在自己擅长的多个方向上，已经跑得相当顺了。比如网页设计生成、动效理解、多 Agent 协作等场景，完成度和稳定性都比较成熟；不过也有短板，比如在 3D 建模这类强几何约束的任务上，表现还欠佳。 当这些能力被一项项跑出来之后，更现实的问题也浮现出来：如果这些复杂推理真的要被当成日常能力反复调用，底层的计算方式还能不能长期扛得住？ 月之暗面给出的一个解法，是 Kimi Linear，而 Kimi Linear 中的一个核心创新点，是一个新的实验性架构：KDA（Kimi Delta Attention），一种线性注意力模块的相关思路。 杨植麟此前在 Reddit 上的 AMA（Ask Me Anything）等公开交流中已经透露，下一代 K3 模型，可能会使用月之暗面的这个新架构 KDA。 要讲清楚 KDA 的优势，我们还得先从 Transformer 架构说起。 本质上，Transformer 的注意力机制是全连接的：每个 token 都要和上下文里的其他 token 打一次交道。结果，输入一长，计算量就按平方增长（O(N²)）；生成新 token 时，还要不断回查之前的 KV Cache。 当上下文一拉长，显存压力迅速飙升，尤其是在 128K 以上的场景里，几乎是“显卡先崩，钱包随后”。 ——而且模型越强，这个问题就越明显。 也正因为如此，过去几年里，线性注意力一直是业内反复被拿出来讨论的一条路：把注意力计算从 O(N²) 压到 O(N)，让模型跑得更快、也更省。 但现实是，早期不少线性注意力方案确实快了，却很难兼顾记忆能力：信息留不住，推理质量也跟着打折。 而 KDA 核心思想可以概括为一句话：不再每次都“全量算一遍注意力”，而是每次只计算“状态 + 增量（Delta）更新”。 这里的 Delta（增量） 是关键。它在数学上保证了稳定性，即使是在百万级 token 序列中，梯度也不会爆炸或消失。这也让 Kimi Linear 能在超长上下文中跑得稳。 在保持模型能力的同时，还可以显著降低长上下文和连续推理的计算成本——思路有点像 MoE 架构。 在测试 Kimi K2.5 的视觉理解能力时，我们索性出了一道“狠题”。 ——甩过去一段动画，让它先吃透画风和叙事方式，再换个主题，重写一支动画脚本。说实话，这活儿对专业动画师都不轻松，我们还特意把 “Agent 集群”模式打开了。 结果最有意思的不是生成内容本身，而是页面最底下那行小字： “这个任务 Kimi 自己就能完成，不需要 Agent 集群。部分额度已退回。” 体验传送门：https://www.kimi.com/
Kimi K2.5 实测
几分钟搓出前端网页，能修改细节、还能有声音
以前要干好几天的活，十几分钟就能搞定
##当 Transformer 开始吃力，K3 可能用上原创架构 KDA
##One more thing
AI 手纹看相，之前奇伴识图里面一个模块，没想到玩的人这么多，之前有段时间模型不支持下线，最近重构重新上线了，大家可以尝尝鲜
你有没有发现，
很多人都会在不经意间看看自己的手。
过去想看手相，
要么找师傅，要么翻书，对着示意图研究半天，
最后往往还是一头雾水。
直到最近，我尝试了一种新的方式：
用 AI ，看手纹。
整个过程，其实非常简单：
系统就会自动识别手掌轮廓、纹路走向、深浅与分布情况。
不需要你懂手相，
也不需要手动标注任何线条。
AI 自己能看懂。
喜欢尝鲜的可以玩玩
入侵排查：简单理解是针对权限维持技术的排查。
权限维持技术：攻击者入侵系统（Getshell）后，为了防止失去权限而通过持久化配置项保持权限的手段，包括注册表、计划任务、后面恶意账户等等。
1、收集系统主机的版本，右键此电脑->属性或者win+R->输入winver
会看到操作系统的版本，为什么要收集系统版本呢？因为根据版本就可以找到这个版本下的漏洞，如权限提升漏洞，可以根据提权漏洞的特点进行排查，如特点的日志等。
2、收集操作系统的其他信息，win+R->输入msinfo32
其中重点关注环境变量，另一种查看环境变量的方法是打开命令行输入set
3、关注环境变量的原因：环境变量劫持：我们都知道，命令行执行一条命令其实是执行一个.exe文件，而如果执行的.exe文件对应的命令不在当前目录，就会出现一种优先级，就是操作系统会找环境变量中指定的.exe文件，然后执行，而如果既不在目录，又不在环境变量中，就会提示不是内部命令。这样一来，想象一个场景，如果内部人员告诉你，自己执行ipconfig命令时，没有正常输出内容或者有安全设备提示有恶意外连等等时，你想拿正常的ipconfig.exe程序进行恶意文件分析，但是没有任何问题，就该注意是否有环境变量劫持了。这里简单做个实验，在环境变量中配置木马文件，
执行文件，并未出现正常内容，
并且C2中成功上线，
这里仅仅是简单的举例，这个例子很容易被发现异常，更隐蔽的做法是，也可以通过将正常的文件路径和木马路径绑在一起，效果就是正常程序和木马都运行了，那我们就可能在这一块儿很难发现恶意程序了。
4、网络连接信息收集，主要的命令netstat -ano、ipconfig /all、netstat -rn等等
这里重点关注分析状态为ESTABLISHED的IP地址，也可以借助威胁分析平台。netstat -rn是网络的路由信息
5、进程排查，主要方法是命令tasklist /v，可以看到进程的列表，
也可以在任务管理器->详细信息查看正在运行的进程
还有命令wmic process get * /value，格式化输出
这里比较重要的是CommandLine，它显示的是执行这个程序时所输入的完整命令，比如这个
为什么需要关注这个呢？我们知道，在C2工具生成有效载荷时，会有PowerShell Command，
执行成功后上线，
在通过wmic process get * /value查看，就能发现恶意进程。
这里也可以用条件表达式，直接过滤获取想看的可疑进程。
1、恶意用户：使用命令net user可以进行查看用户等等操作，这是添加了一个用户
我们也可以将用户进行隐藏，就是在用户后面加一个$符号，我们发现使用net user查询后并没有发现这个用户的信息，就是被隐藏了
但是这种方法对应其它命令和图形化注销时都能看到，因此这种隐藏用户还是比较鸡肋的。所以一些攻击者就会创建一些特定情况下存在的克隆账户，比如在域环境中存在hrbtgt用户，可能反而不会引起运维人员的关注。
2、排查：命令wmic useraccount get * /value，这个会显示所有用户的详细信息，包括刚刚创建的隐藏用户
另外通过注册表也可以看到用户，包括前面 提到的克隆账户其实就是把注册表中的信息进行调换，但是其实上面这条命令已经可以解决很多问题了。
1、注册表下的RUN子键和RUNONCE（只运行一次）子键开机启动项：
这里的启动项是通过管理员账户进行修改，但是在任意用户用户登录时运行，换句话说就是任意用户触发登录时都会运行，举个例子，重启电脑，进行登录，看会不会有cmd.exe运行
cmd.exe自启动
上面是其中一个目录，在注册表中还有一个其他目录也存在这个子键
那么区别显而易见了，就是前者是所以用户登录时触发，后者是只有当前用户登录时触发。另外，需要说明的是前者在前面说到了，只有管理员权限才能修改写入，普通用户只能修改后面的目录的内容。
2、services.msc服务文件：服务文件比较特殊的一点是它不需要用户登录，那么也就意味着它的可利用性更强，但是，创建服务文件的启动项必须是管理员权限才能创建的，同时当攻击者获取到权限时也会获取到system的权限。
这里配合C2做个示范，在C2工具中，有专门针对服务的程序，正常运行时运行不了，只能配合服务运行
这个命令就是进行服务启动项的命令（sc create 服务名称 binpath= "自启动的程序" start="auto" obj="服务运行时的权限"）
就出现这个服务了，可以看到这个服务是没有描述的，除此之外，为了更加隐蔽，攻击者可能会添加其他字段来让这个服务更加隐蔽，这里讲排查，就不深入了
接下来进行服务启动
C2上线，并且权限很高，是system权限
另外重启一下看效果，这里重启就不需要登录，重启后上线
而且未登录
3、gpedit.msc本地组策略启动项：
点开启动->添加->添加恶意程序
这个依旧不需要登录，就可以上线C2
4、计划任务：命令schtasks
创建计划任务可以用命令schtasks /create /tn "计划任务名称" /tr "计划任务的所在位置" /sc minute /mo 1，表示一分钟执行一次
另外，计划任务图形化界面也可以操作
1、这个有很多，比如说火绒、D盾、windows安全基线核查加固助手
1、如果知道恶意程序的名称，可以直接去注册表搜索，持久化的东西大多数都可以用注册表搜出来，比如前面的服务文件、本地组策略文件和计划任务等等
2、那么如何找到恶意程序的名称呢？比较重要的一点就是确定时间线，我们可以在文件资源管理器中，指定日期或日期范围进行搜索
另外也可以用everything工具进行搜索，这个工具也有特定的语法可以筛选和过滤
对应入侵排查而言，这些仅仅可以解决一下基础的持久化的问题，而还有很多高端的不常见的甚至从未出现过的持久化手段需要更多的深入了解和学习的。
发版时间：v3.9.1 | 2026-01-28 JeecgBoot 平台提供了一套完善的AI应用管理系统模块，是一套类似 JeecgBoot低代码平台，可以应用在任何J2EE项目的开发中，支持信创国产化。尤其适合SAAS项目、企业信息管理系统（MIS）、内部办公系统（OA）、企业资源计划系统（ERP）、客户关系管理系统（CRM）、AI知识库等，其半智能手工Merge的开发方式，可以显著提高开发效率70%以上，极大降低开发成本。 又是一个全栈式 AI 开发平台，快速帮助企业构建和部署个性化的 AI 应用。 信创兼容说明 微服务方式快速启动 AI流程编排 MCP和工具管理 AI知识库（支持各种文档格式，尤其markdown适配很好） AI工具箱 AI聊天助手 AI写文章 Online AI建表 欢迎吐槽，欢迎star~项目介绍
JeecgBoot是一款集成AI应用的，基于BPM流程的低代码平台，旨在帮助开发者快速实现低代码开发和构建、部署个性化的 AI 应用。 前后端分离架构Ant Design&Vue3，SpringBoot，SpringCloud，Mybatis，Shiro，强大的代码生成器让前后端代码一键生成，无需写任何代码！ 成套AI大模型功能: AI模型、AI应用、知识库、AI流程编排、AI对话等； 引领AI低代码开发模式， 帮助Java项目解决80%的重复工作，让开发更多关注业务，提高效率，同时又不失灵活性！
源码下载
升级日志
本次升级对 AI 平台进行了全面增强，升级 LangChain4j 至 1.9.1，引入推理模型、多会话与流式调用能力；千问模型支持参数调整与联网搜索，新增 AI 绘画、文生图、图生图和海报生成等多模态能力；AI 应用升级为智能体，支持记忆、变量、插件、流程与 MCP；流程能力新增变量、循环、SQL、定时、知识库写入等节点；AI 聊天支持文件上传、Chat2BI 生成图表。并推出 AI 工具箱，覆盖 AI 海报、AI 简历、AI 写作、AI 生图等场景；
AI 平台升级日志
核心升级
大模型与多模态
AI 应用
AI 流程
AI 聊天与 BI
Chat2BI（AI生成图表）
AI工具箱
新增应用场景案例
平台功能升级
Online功能升级
Issues修复
技术交流
快速启动项目
AI应用平台介绍
Dify的AIGC应用开发平台+知识库问答，是一款基于LLM大语言模型AI应用平台和 RAG 的知识库问答系统。 其直观的界面结合了 AI 流程编排、RAG 管道、知识库管理、模型管理、对接向量库、实时运行可观察等，让您可以快速从原型到生产，拥有AI服务能力。 详细专题介绍，请点击查看适用项目
为什么选择 JeecgBoot?
开源界"小普元"超越传统商业平台。引领低代码开发模式(OnlineCoding-> 代码生成器 -> 手工MERGE)，低代码开发同时又支持灵活编码， 可以帮助解决Java项目70%的重复工作，让开发更多关注业务。既能快速提高开发效率，节省成本，同时又不失灵活性。
技术架构：
前端
Node 20+ 版本以上、pnpm 要求9+ 版本以上后端
ChatGPT DeepSeek切换微服务架构图
微服务解决方案
Jeecg Boot 产品功能蓝图
系统功能架构图
开源版功能清单
├─AI应用平台
│ ├─AI模型管理
│ ├─AI应用管理
│ ├─AI知识库
│ ├─AI流程编排
│ ├─AI聊天助手(支持图片、文件)
│ ├─AI聊天助手支持嵌入第三方、支持移动端
│ ├─MCP插件管理
│ ├─提示词管理
│ ├─AI应用门户（汇总各种AI应用场景）
│ ├─支持各种常见模型ChatGPT和DeepSeek、ollama等
├─工具箱
│ ├─OCR识别
│ ├─AI 海报
│ ├─AI 写作
│ ├─AI 简历
├─AI辅助功能
│ ├─AI建表（Online表单）
│ ├─AI生成报表（Online报表）
│ ├─AI生成大屏
├─系统管理
│ ├─用户管理
│ ├─角色管理
│ ├─菜单管理
│ ├─权限设置（支持按钮权限、数据权限）
│ ├─表单权限（控制字段禁用、隐藏）
│ ├─部门管理
│ ├─我的部门（二级管理员）
│ └─字典管理
│ └─分类字典
│ └─系统公告
│ └─职务管理
│ └─通讯录
│ ├─多数据源管理
│ └─多租户管理（租户管理、租户角色、我的租户）
├─Online在线开发(低代码)
│ ├─Online在线表单
│ ├─Online代码生成器
│ ├─Online在线报表
│ ├─仪表盘设计器
│ ├─系统编码规则
│ ├─系统校验规则
├─积木报表设计器
│ ├─打印设计器
│ ├─数据报表设计
│ ├─图形报表设计（支持echart）
├─消息中心
│ ├─消息管理
│ ├─模板管理
├─代码生成器(低代码)
│ ├─代码生成器功能（一键生成前后端代码，生成后无需修改直接用，绝对是后端开发福音）
│ ├─代码生成器模板（提供4套模板，分别支持单表和一对多模型，不同风格选择）
│ ├─代码生成器模板（生成代码，自带excel导入导出）
│ ├─查询过滤器（查询逻辑无需编码，系统根据页面配置自动生成）
│ ├─高级查询器（弹窗自动组合查询条件）
│ ├─Excel导入导出工具集成（支持单表，一对多 导入导出）
│ ├─平台移动自适应支持
│ ├─提供新版uniapp3的代码生成器模板
├─系统监控
│ ├─基于AK和SK认证鉴权OpenAPI功能
│ ├─Gateway路由网关
│ ├─性能扫描监控
│ │ ├─监控 Redis
│ │ ├─Tomcat
│ │ ├─jvm
│ │ ├─服务器信息
│ │ ├─请求追踪
│ │ ├─磁盘监控
│ ├─定时任务
│ ├─系统日志
│ ├─消息中心（支持短信、邮件、微信推送等等）
│ ├─数据日志（记录数据快照，可对比快照，查看数据变更情况）
│ ├─系统通知
│ ├─SQL监控
│ ├─swagger-ui(在线接口文档)
│─报表示例
│ ├─曲线图
│ └─饼状图
│ └─柱状图
│ └─折线图
│ └─面积图
│ └─雷达图
│ └─仪表图
│ └─进度条
│ └─排名列表
│ └─等等
│─大屏模板
│ ├─作战指挥中心大屏
│ └─物流服务中心大屏
│─常用示例
│ ├─自定义组件
│ ├─对象存储(对接阿里云)
│ ├─JVXETable示例（各种复杂ERP布局示例）
│ ├─单表模型例子
│ └─一对多模型例子
│ └─打印例子
│ └─一对多TAB例子
│ └─内嵌table例子
│ └─常用选择组件
│ └─异步树table
│ └─接口模拟测试
│ └─表格合计示例
│ └─异步树列表示例
│ └─一对多JEditable
│ └─JEditable组件示例
│ └─图片拖拽排序
│ └─图片翻页
│ └─图片预览
│ └─PDF预览
│ └─分屏功能
│─封装通用组件
│ ├─行编辑表格JEditableTable
│ └─省略显示组件
│ └─时间控件
│ └─高级查询
│ └─用户选择组件
│ └─报表组件封装
│ └─字典组件
│ └─下拉多选组件
│ └─选人组件
│ └─选部门组件
│ └─通过部门选人组件
│ └─封装曲线、柱状图、饼状图、折线图等等报表的组件（经过封装，使用简单）
│ └─在线code编辑器
│ └─上传文件组件
│ └─验证码组件
│ └─树列表组件
│ └─表单禁用组件
│ └─等等
│─更多页面模板
│ ├─各种高级表单
│ ├─各种列表效果
│ └─结果页面
│ └─异常页面
│ └─个人页面
├─高级功能
│ ├─提供单点登录CAS集成方案
│ ├─提供APP发布方案
│ ├─集成Websocket消息通知机制
│ ├─支持electron桌面应用打包(支持windows、linux、macOS三大平台)
│ ├─docker容器支持
│ ├─提供移动APP框架及源码（Uniapp3版本）支持H5、小程序、APP、鸿蒙Next
│ ├─提供移动APP低代码设计(Online表单、仪表盘)
系统效果预览
AI模型与应用管理
PC端
在线聊天&通知
Online开发(在线配置表单和报表)
图表示例
积木BI大屏
APP效果
PAD端
在线接口文档
积木报表
近期，我们围绕离线开发产品进行了一系列功能新增与优化，旨在为用户提供更智能、更高效的开发体验 。本次更新重点引入了离线AI“代码续写”功能，显著提升辅助编程效率；同时支持中英文自由切换，满足国际化业务需求 。在架构层面，新增了Doris SQL多计算引擎切换及业务流程跨工作流编排能力 。此外，我们还优化了Restful源端配置、实现了Python日志实时打印并强化了权限管控，全面赋能企业构建稳健的数据基座 。 在数据开发场景中引入AI辅助编程能力，可根据用户已输入的代码片段，智能预测并生成后续代码内容，提升开发效率。 为满足客户海外业务统一管理需求，产品界面新增中文/英文版本切换功能，完成国际化适配。 为提升业务数据管理效能，部分用户选择构建双集群环境，分别用于数据仓库建设与应用数据存储。在实际开发过程中，任务需根据具体的业务场景分发至相应集群执行。为此，离线数据开发相关功能已全面适配多集群架构，其支持范围涵盖以下内容： 针对跨工作流的任务依赖与全链路管理需求，系统引入“业务流程”单元。它打破了传统单一链路的局限，从业务维度整合多工作流任务，实现跨流编排、依赖管理与统一调度。 核心功能包括： ①任务整合与业务视图将分散在多个工作流中的相关任务统一纳入同一业务流程管理。自动形成可视化的业务链路视图，清晰展示任务间的业务逻辑关系。 ②跨流程依赖配置支持任务之间、任务与业务流程之间的灵活依赖配置。可实现跨工作流、跨流程的依赖管理，满足复杂业务链路调度需求。 ③调度与运行能力流程下的任务可独立配置调度策略，无需配置根节点即可直接提交。最终以“流程下的单个任务”为调度运行维度，实现灵活高效的执行控制。 ④补数据能力支持流程内任务的统一或独立补数操作，确保业务链路数据一致性。 新增对GaussDB 9.1计算引擎的支持，涵盖周期任务、语法提示、数据同步等功能；数据同步任务在源端和目标端均可选择GaussDB 9.1作为读写数据源。 当数据同步任务的目标端为inceptor时，支持一键自动创建目标表结构。 数据同步任务的源端与目标端均支持选择Kafka 2.x作为数据源，便于从Kafka进行周期性数据抽取。 优化表数据预览的权限逻辑，用户必须同时具备“表管理-查看”权限以及在数据地图中已申请获得的DQL权限，方可查看数据，确保权限边界清晰。 新增「数据地图外表权限管控」配置功能。该功能在兼容历史客户使用习惯的基础上，提供更严格的数据安全防护。用户可根据实际场景选择是否限制对未纳入数据地图表的操作权限，从而有效防止越权访问和潜在数据风险。 在控制台Spark集群内新增DataLake的hudi配置项后，SparkSQL任务支持对 Hudi 表执行完整的 DDL、DML、DQL 操作，用户可像操作 Hive 表一样直接进行 查询、创建、修改与写入，实现统一的 SQL 使用体验 新增对DMDB for Oracle计算引擎的支持，涵盖周期任务、整库同步、数据同步、手动任务、临时查询、语法提示、表查询、函数管理、存储过程、依赖推荐、任务上下游参数、代码模板、按项目或个人粒度绑定数据库账号、执行计划、数据导入等功能模块。 离线数据同步任务、Spark任务、PySpark任务、Spark SQL任务及Hive SQL任务全面适配AWS S3存储底座。 Spark3.5支持更多特性包括自适应执行、向量化优化，对Paimon湖仓有更好支持。为提升平台性能与兼容性，满足客户在离线计算场景中对SparkSQL的最新特性需求，平台计算引擎SparkSQL3.5进行适配 功能如下： 计算引擎支持对接SparkSQL3.5版本，支持创建任务、周期运行、补数据等操作；SparkSQL3.5支持对Paimon 1.2进行操作，包括DDL、DML、DQL语法 在构建相应连接jar包后，HiveSQL任务支持对Paimon表执行完整的DDL、DML、DQL操作。 系统可根据资产平台表血缘关系自动解析生成任务依赖。当用户手动配置的依赖存在多配或少配时，在提交任务时会进行弹窗提示，降低因依赖配置错误导致的运行时故障风险。 为满足交易类业务对小时级调度链路时效性的高要求，优化依赖匹配规则：支持“优先寻找同小时的上游实例”；若无同小时实例，则自动回退至最近时间的实例。新增“基于默认依赖周期的偏移”和“优先寻找同小时的上游实例”两种依赖方式选项。 适用于 3 类时间间隔场景（参考下方实例依赖图）： 任务A与任务B间隔一致： 同小时匹配：B 11:30 → A 11:50；回退匹配：B 10:30 → A 前一天 14:50 任务A间隔小于任务B： 同小时匹配：B 15:30 → A 14:50；回退匹配：B 20:30 → A 16:50 任务A间隔大于任务B： 同小时匹配：B 10:50 → A 10:30；回退匹配：B 12:50 → A 10:30 在数据同步任务配置Restful数据源时，增加Path路径填写项，用户可直接在任务内填写完整URL，简化多接口配置流程。 任务脚本执行完成后，在日志中明确展示SQL运行的影响行数：对DML语句（如INSERT、UPDATE、DELETE），日志中返回实际影响的行数；对DDL语句（如 TRUNCATE、DROP、ALTER、CREATE），日志中统一返回 -1 优化Python任务执行机制，支持在任务运行过程中于页面实时打印输出日志和错误信息，改变此前需等待任务结束后才查看日志的状况。 在告警规则中新增该触发方式，当任务超过计划时间一定阈值仍未开始运行时，系统自动触发告警，便于及时发现调度阻塞。 新增为补数据任务和手动任务配置“最大并行实例数”默认值的能力，防止因误操作触发大量实例导致集群资源耗尽。 将操作设置中的众多配置项按“数据同步”、“SQL任务”、“调度”、“通用”四大模块进行重新分类展示，提升查找和配置效率。 针对本地上传大文件时页面卡顿、崩溃的问题，重构代码逻辑，采用分片上传技术，并将单个文件大小上限设置为500MB，提升上传稳定性和用户体验。 对Sql Parser进行RPC改造，显著提高解析服务的稳定性，减少因解析导致的IO飙高、进程异常及服务不可用情况。 优化数据同步任务中Redis的写入逻辑，在单并发场景下，写入3000万条数据的耗时从超过15分钟缩短至2分钟以内，极大提升了同步效率。 为解决多子产品中生命周期配置不一致可能导致数据误清理的问题，统一通过业务中心SDK维护表生命周期。系统自动判断表是否存在并执行插入或更新操作，确保配置一致性。 合并进入“数据开发”页面时对函数目录的重复接口调用，整合为一次性请求，解决因函数过多导致的页面加载缓慢问题。 减少页面打开时的不必要接口请求，优化请求数量，提升页面响应速度。 实现资产中心配置的Hive、Doris数据源脱敏规则在离线开发平台内同步生效，用户无需在两个产品内重复配置。 优化AI知识库的数据同步流程，支持配置多线程并行同步，显著缩短同步耗时，改善生产环境同步体验。一、功能新增
1.重点新增内容
1.1.离线AI功能新增「代码续写」功能
1.2.离线开发平台支持中英文切换
1.3.Doris SQL任务支持多计算引擎切换
1.4.新增业务流程类型，支持跨工作流任务编排
1.5.计算引擎与数据同步支持GaussDB 9.1
1.6.inceptor数据同步支持一键生成目标表
1.7.数据同步向导模式支持Kafka 2.x
1.8.数据地图DQL权限校验强化
1.9.Hive表权限管控功能
1.10.SparkSQL 3.2支持读写Hudi 0.15.0
2.其他新增内容
全面支持Doris 3.x作为计算引擎，覆盖周期任务、整库同步、数据同步、手动任务、临时查询、语法提示、表查询、函数管理、依赖推荐、任务上下游参数、代码模板、账号绑定、执行计划等功能。二、功能优化
1.重点功能优化说明
1.1.任务依赖配错提示功能
1.2.同小时任务依赖逻辑优化
1.3.同步任务Restful源端配置优化
1.4.脚本日志展示SQL影响行数
1.5.Python on Agent日志实时打印
1.6.告警规则新增“未按计划时间运行”触发条件
1.7.支持配置任务实例默认并发数
1.8.操作设置页面布局调整
2.其他功能优化
本次版本 新增函数对象转换能力，扩展了达梦等多数据库迁移适配范围，并提升了批量转换的处理效率，进一步降低企业级数据库迁移的复杂度与成本。 函数对象可随存储过程的迁移任务一键同步转换。该能力的加入，让 SQLShift[1] 从一款“存储过程迁移工具”升级为“核心业务逻辑对象全量迁移工具”。随之也带来三重提升： 降低迁移风险与人工成本 避免 函数对象 需人工逐个改写与反复校验，大幅减少因语法差异、返回值不一致引发的运行期错误。 提升非表对象整体迁移效率 函数对象与存储过程 可在同一时间中完成迁移与校验，缩短整体迁移周期。 避免 函数对象 缺失导致上层存储过程等对象无法编译或运行的问题，有效降低迁移后集中调试与返工压力，提升割接与上线的稳定性。 <iframe src="//player.bilibili.com/player.html?isOutside=true&aid=115970207123078&bvid=BV1Gg6LBAEf3&cid=35655845383&p=1" scrolling="no" border="0" frameborder="no" framespacing="0" allowfullscreen="true"></iframe> 本次升级，SQLShift 扩展了多项数据库迁移组合。 新增 Oracle / OceanBase → 达梦 降低了迁移至达梦数据库的复杂度和人工成本，帮助企业快速完成数据库替换或国产化改造。 新增 PostgreSQL → OceanBase（Oracle 模式） 减少了跨数据库迁移中的人工调整工作量，加快了从 PostgreSQL 向 OceanBase 的迁移进程。 批量处理能力提升 支持同时上传多个 SQL 文件进行转换，提升大规模迁移场景下的处理效率。 👉 点击领取 你的转换额度，立即体验 SQLShift 智能化迁移带来的飞跃效率！ 🧩 SQL 方言再多，转换也能一步到位，SQLShift 为你搞定！
一、核心特性
支持函数对象迁移
新增数据库迁移组合
二、其他更新
免费试用限时开放！
已经在虚拟机部署好Apache DolphinScheduler了，想尝试下在Flink新建一个Flink节点，然后用Flink消费Kafka数据。 Apache DolphinScheduler用的是单机部署，具体操作可以参考官方文档：DolphinScheduler | 文档中心(https://dolphinscheduler.apache.org/zh-cn/docs/3.3.2/guide/in...). 1、编辑环境变量： 增加Flink的路径 2、使环境变量生效： 因为用的是虚拟机，为了让外面的主机能够访问到虚拟机的网络，需要修改下配置文件 查看dolphinscheduler-daemon.sh文件： 修改dolphinscheduler_env.sh文件，新增JAVA、Flink路径： 启动应用，包括Zookeeper、Kafka、Flink以及Apache DolphinScheduler。 测试Flink、Apache DolphinScheduler是否能访问成功。 用Flink消费Kafka数据，然后打包上传到Apache DolphinScheduler，启动Flink任务： pom.xml FlinkKafkaConsumerExample.java 在Apache DolphinScheduler的任务实例看启动日志： 在虚拟机启动生产者，输出字符串，然后可以在Flink查看输出Kafka生产的消息： 原文链接：https://blog.csdn.net/Analyze_ing/article/details/156940553
配置好Flink的环境变量
sudo vim ~/.bashrc
#使环境变量生效
source ~/.bashrc
#查看环境变量
echo $Flink_HOME修改Kafka、Flink以及DolphinScheduler的配置文件
broker.id=0
listeners=PLAINTEXT://0.0.0.0:9092
#192.168.146.132修改成虚拟机ip
advertised.listeners=PLAINTEXT://192.168.146.132:9092
jobmanager.rpc.address: 0.0.0.0
jobmanager.bind-host: 0.0.0.0
jobmanager.cpu.cores: 1
jobmanager.memory.process.size: 1600m
taskmanager.bind-host: 0.0.0.0
taskmanager.host: 0.0.0.0
taskmanager.memory.process.size: 2048m
taskmanager.cpu.cores: 1
dolphinscheduler-daemon.sh可以看出，配置环境变量用的是bin/env文件夹下的dolphinscheduler_env.sh。
#修改成自己的JAVA、Flink路径
export JAVA_HOME=/data/jdk-11.0.29
export Flink_HOME=/data/Flink-1.18.1
关闭防火墙，启动应用
#关闭防火墙
sudo systemctl stop firewalld
# 在 Flink 根目录下，执行以下命令启动 Flink 集群
bin/start-cluster.sh
# 启动 ZooKeeper
bin/zookeeper-server-start.sh config/zookeeper.properties &
# 启动 Kafka 服务器
bin/Kafka-server-start.sh config/server.properties &
#创建 Kafka 主题
bin/Kafka-topics.sh --create --topic test --bootstrap-server localhost:9092 --partitions 1 --replication-factor 1
#使用命令行生产者发送消息
bin/Kafka-console-producer.sh --topic test --bootstrap-server localhost:9092
#消费
bin/Kafka-console-consumer.sh --topic test --from-beginning --bootstrap-server localhost:9092
# 启动 Standalone Server 服务
bash ./bin/dolphinscheduler-daemon.sh start standalone-server测试
编写样例
<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>
<groupId>com.example</groupId>
<artifactId>Flink-Kafka-demo</artifactId>
<version>1.0-SNAPSHOT</version>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<maven.compiler.source>1.8</maven.compiler.source>
<maven.compiler.target>1.8</maven.compiler.target>
<Flink.version>1.18.1</Flink.version>
<scala.binary.version>2.12</scala.binary.version>
<Kafka.version>3.6.0</Kafka.version>
</properties>
<dependencies>
<!-- Flink核心依赖 -->
<dependency>
<groupId>org.apache.Flink</groupId>
<artifactId>Flink-java</artifactId>
<version>${Flink.version}</version>
</dependency>
<dependency>
<groupId>org.apache.Flink</groupId>
<artifactId>Flink-streaming-java</artifactId>
<version>${Flink.version}</version>
</dependency>
<dependency>
<groupId>org.apache.Flink</groupId>
<artifactId>Flink-clients</artifactId>
<version>${Flink.version}</version>
</dependency>
<!-- 连接器基础依赖 -->
<dependency>
<groupId>org.apache.Flink</groupId>
<artifactId>Flink-connector-base</artifactId>
<version>${Flink.version}</version>
</dependency>
<!-- Kafka连接器（关键修改点） -->
<dependency>
<groupId>org.apache.Flink</groupId>
<artifactId>Flink-connector-Kafka</artifactId>
<version>3.1.0-1.18</version>
</dependency>
<dependency>
<groupId>org.apache.Kafka</groupId>
<artifactId>Kafka-clients</artifactId>
<version>${Kafka.version}</version>
</dependency>
<!-- 日志依赖 -->
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-simple</artifactId>
<version>1.7.36</version>
<scope>runtime</scope>
</dependency>
</dependencies>
<repositories>
<repository>
<id>aliyun</id>
<url>https://maven.aliyun.com/repository/public</url>
<releases>
<enabled>true</enabled>
</releases>
<snapshots>
<enabled>false</enabled>
</snapshots>
</repository>
<repository>
<id>apache-releases</id>
<url>https://repository.apache.org/content/repositories/releases/</url>
</repository>
</repositories>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.8.1</version>
<configuration>
<source>${maven.compiler.source}</source>
<target>${maven.compiler.target}</target>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>3.2.4</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
<configuration>
<artifactSet>
<excludes>
<exclude>org.apache.Flink:force-shading</exclude>
<exclude>com.google.code.findbugs:jsr305</exclude>
<exclude>org.slf4j:*</exclude>
</excludes>
</artifactSet>
<filters>
<filter>
<artifact>*:*</artifact>
<excludes>
<exclude>META-INF/*.SF</exclude>
<exclude>META-INF/*.DSA</exclude>
<exclude>META-INF/*.RSA</exclude>
</excludes>
</filter>
</filters>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>import org.apache.Flink.api.common.functions.FlatMapFunction;
import org.apache.Flink.api.java.tuple.Tuple2;
import org.apache.Flink.api.java.utils.ParameterTool;
import org.apache.Flink.streaming.api.environment.StreamExecutionEnvironment;
import org.apache.Flink.streaming.api.datastream.DataStream;
import org.apache.Flink.streaming.api.functions.ProcessFunction;
import org.apache.Flink.streaming.api.functions.sink.RichSinkFunction;
import org.apache.Flink.util.Collector;
import org.apache.Flink.streaming.connectors.Kafka.FlinkKafkaConsumer;
import org.apache.Flink.api.common.serialization.SimpleStringSchema;
import org.apache.Kafka.clients.consumer.ConsumerConfig;
import org.apache.Kafka.common.serialization.StringDeserializer;
import java.util.Properties;
import java.util.concurrent.CompletableFuture;
public class FlinkKafkaConsumerExample {
private static volatile int messageCount = 0;
private static volatile boolean shouldStop = false;
public static void main(String[] args) throws Exception {
// 设置执行环境
final StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
// Kafka 配置
Properties properties = new Properties();
properties.setProperty(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG, "192.168.146.132:9092"); // Kafka broker 地址
properties.setProperty(ConsumerConfig.GROUP_ID_CONFIG, "test-group"); // 消费者组
properties.setProperty(ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class.getName());
properties.setProperty(ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class.getName());
// 创建 Kafka 消费者
FlinkKafkaConsumer<String> KafkaConsumer = new FlinkKafkaConsumer<>("test", new SimpleStringSchema(), properties);
KafkaConsumer.setStartFromEarliest(); // 从最早的消息开始消费
DataStream<String> stream = env.addSource(KafkaConsumer);
// 处理数据：分词和计数
DataStream<Tuple2<String, Integer>> counts = stream
.flatMap(new Tokenizer())
.keyBy(value -> value.f0)
.sum(1);
counts.addSink(new RichSinkFunction<Tuple2<String, Integer>>() {
@Override
public void invoke(Tuple2<String, Integer> value, Context context) {
System.out.println(value);
messageCount++;
// 检查是否达到停止条件
if (messageCount >= 2 && !shouldStop) {
System.out.println("Processed 2 messages, stopping job.");
shouldStop = true; // 设置标志位，表示应该停止
}
}
});
// 执行作业并获取 JobClient
CompletableFuture<Void> future = CompletableFuture.runAsync(() -> {
try {
// 启动作业并获取 JobClient
org.apache.Flink.core.execution.JobClient jobClient = env.executeAsync("Flink Kafka WordCount");
System.out.println("Job ID: " + jobClient.getJobID());
// 监测条件并取消作业
while (!shouldStop) {
Thread.sleep(100); // 每100毫秒检查一次
}
// 达到停止条件时取消作业
if (shouldStop) {
System.out.println("Cancelling the job...");
jobClient.cancel().get(); // 取消作业
}
} catch (Exception e) {
e.printStackTrace();
}
});
// 在主线程中等待作业结束
future.join(); // 等待作业完成
}
// Tokenizer 类用于将输入字符串转化为单词
public static final class Tokenizer implements FlatMapFunction<String, Tuple2<String, Integer>> {
@Override
public void flatMap(String value, Collector<Tuple2<String, Integer>> out) {
String[] tokens = value.toLowerCase().split("\\W+");
for (String token : tokens) {
if (token.length() > 0) {
out.collect(new Tuple2<>(token, 1));
}
}
}
}
}
作为一名长期深耕于外包公司的前端工程师，我大部分的项目都是使用 Vue2；此前学习的 Vue3 与 React，却始终没有机会在实际项目中落地实践。为了避免陷入颓废、被行业淘汰的困境，我计划着手搭建个人后台管理项目，全程记录使用 Next.js 的搭建流程，同时结合官方文档与 AI 工具，一步步完成项目落地，既巩固技术，也给自己的成长留下印记。 我这边开发环境选的是 我现在用的 可以使用 因为项目是使用 这边我使用的 安装时，你将看到以下提示 使用 查看 启动项目，测试是否运行成功： 项目正常启动后，在浏览器中访问 若页面能正常显示，且控制台不报任何异常，则项目创建启动成功。 App Router 是 如果你想快速体验多路由，还可以创建： 至此，我们完成了项目的初始化和代码重构工作，包括： 下一篇文章里，我们来重点对 做好这些配置，能帮项目规避语法错误、提前揪出类型问题，避免后续写业务时踩坑；还能提升代码可读性和可维护性，贴合 我也是个跟着文档和AI交流一步步摸索的菜鸟，如果你对本文讲的项目初始化、路由这些内容有疑问，或者实操时踩了坑，欢迎在评论区留言。咱们一起交流避坑. 本文由mdnice多平台发布前言
0 开发环境及依赖版本
开发环境
Node.js + pnpm组合。版本管理工具用的是 Volta，它最方便的地方就是能给不同项目配置不同的Node版本，不用来回切换麻烦。
具体用法很简单，常用命令贴在这：# 将 Node.js 安装为默认版本，安装最新的 LTS（长期支持）版本的 Node.js。
volta install node
# 安装特定版本
volta install node@16
volta install node@16.14.2
# 特定的 Node.js 版本固定到您的项目
volta pin node@16.14.2pnpm 的话，直接用 npm install -g pnpm 命令安装就行。Node.js和 pnpm都是最新版本，做技术嘛，就得追着最新的来，后续用到的其他技术栈也会保持最新，同时兼顾好兼容性，避免出现版本不匹配的问题。node -v、pnpm -v 查看版本号。
Next 官方脚手架创建项目，默认给你配置好了最新的、可兼容的版本，其他的依赖直接上新版！咱使用的版本号如下：依赖 版本 描述 next 16.1.5 Next.js 框架 react 19.2.3 React 核心 react-dom 19.2.3 React DOM 渲染 typescript ^5 静态类型检查 eslint ^9 代码检查 eslint-config-next 16.1.5 Next.js ESLint 规则 tailwindcss ^4 原子化 CSS 框架 @tailwindcss/postcss ^4 Tailwind CSS 编译 1. 初始化项目
1.1 创建项目
Next.js 官方推荐的 create-next-appnpx create-next-app@latest? What is your project named? » my-app # 项目名称
? Would you like to use the recommended Next.js defaults? » - Use arrow-keys. Return to submit. # 推荐的Next.js默认值吗，
> Yes, use recommended defaults - TypeScript, ESLint, Tailwind CSS, App Router # 是的，使用推荐的默认值-TypeScript、ESLint、Tailwind CSS、App Router
No, reuse previous settings # 否，重复使用以前的设置
No, customize settings # 否，自定义设置，我选这个
? Would you like to use TypeScript? » No / Yes # 你想使用TypeScript吗？ Yes
? Which linter would you like to use? » - Use arrow-keys. Return to submit.# 你想选择哪种代码检查工具
> ESLint # 选择主流
Biome
None
? Would you like to use React Compiler? # 您想使用React编译器吗？
» No / Yes # Yes
? Would you like to use Tailwind CSS? # 您想使用Tailwind CSS 吗
» No / Yes # Yes
? Would you like your code inside a `src/` directory? # 你想把代码放在`src/`目录中吗
» No / Yes # Yes
? Would you like to use App Router? (recommended) 您想使用App Router吗？
» No / Yes # Yes
? Would you like to customize the import alias (`@/*` by default)? # 是否要自定义导入别名（默认为“@/*”）
» No / Yes # No1.2 安装依赖
VScode 打开前面创建的项目 my-app,打开终端，输入 pnpm install 安装项目所需依赖。
1.3 启动项目
package.json 配置文件{
...
"scripts": {
"dev": "next dev", // 启动开发环境服务器
"build": "next build", // 为生产环境构建 / 打包项目
"start": "next start", // 启动生产环境服务器
"lint": "eslint" // 运行代码检查工具
},
...
} pnpm devhttp://localhost:3000/
2. 调整项目结构
2.1 项目文件 / 文件夹作用全解析
my-app/
├─ .next/ # Next.js 开发 / 打包时自动生成的临时缓存目录
├─ node_modules # 项目所有第三方依赖包的存放目录
├─ public/ # 静态资源（图片、favicon）
├─ src/
│ ├─ app/ # App Router 的核心路由目录
│ │ ├─ layout.tsx
│ │ ├─ page.tsx
│ ├─ components/ # 可复用组件（尽量小、可组合）
│ ├─ hooks/ # 自定义 hooks（useAuth, useToast）
│ ├─ lib/ # 数据客户端、工具函数（prisma client, supabase client）
│ ├─ styles/ # globals, tailwind css entry
│ ├─ types/ # 全局类型声明
│ └─ utils/ # 小工具
├─ .env.local # 本地环境变量（不要提交）
├─ next.config.js # Next.js 项目的全局配置文件
├─ postcss.config.js # PostCSS 工具的配置文件
├─ eslint.config.mjs # ESLint 代码检查工具的配置文件
├─ tsconfig.json # TypeScript 配置文件
├─ package.json # 项目核心配置文件
└─ README.md # 项目核心配置文件2.2 创建测试页面
文件系统路由，即「文件 / 文件夹的路径 = 页面的 URL 路径」。我们来创建一个 /test 测试页面：src/app 目录下，新建一个名为 test 的文件夹。page.tsx 的文件（这是 App Router 中 “页面文件” 的固定命名）。page.tsx 中写入测试代码：// src/app/test/page.tsx
export default function TestPage() {
return (
<div style={{ padding: '2rem' }}>
<h1>这是一个测试页面</h1>
<p>访问路径：/test</p>
</div>
);
}
2.3 配置更多路由
src/app/page.tsx 就是默认的首页（访问路径 /），可以修改这个文件来定制首页内容。src/app/blog/[id]/page.tsx，就能实现动态路由 /blog/123（[id] 是动态参数）。src/app/layout.tsx 是全局布局文件，所有页面都会继承这个布局（比如导航栏、页脚可以写在这里，不用每个页面重复写）。END
ESLint + TypeScript 进行配置 —— 主要是 .eslint.config.mjs 和 tsconfig.json 这两个核心文件，了解每个配置项的含义和作用。Next.js 16 + TS 5.x 的适配需求。
编者按： 如果你正在为边缘计算、本地部署或资源受限场景寻找高效的语言模型解决方案，你是否曾困惑：在众多小型语言模型（SLM）中，哪一个才是微调的最佳起点？是否真的存在“小而强”的模型，能在微调后媲美甚至超越规模大数十倍的教师模型？ 近期，distil labs 团队进行了一项严谨的基准研究，或许能为你提供数据驱动的答案。他们在 8 类任务（涵盖分类、信息抽取、开卷与闭卷问答）上，对 12 个主流小型模型（包括 Qwen3、Llama、Gemma、Granite、SmolLM 等系列）进行了统一微调与评估，并对比了其与 120B 参数教师模型（GPT-OSS-120B）的性能差异。 作者 | Distil Labs 编译 | 岳扬 经过微调的小型语言模型（SLM）可以胜过规模大得多的模型：微调后的 Qwen3-4B 在 8 项基准测试中的 7 项上表现能够超越或战平 GPT-OSS-120B（一个比它模型规模大 30 倍的教师模型），剩下的一项差距也不到 3 个百分点。在 SQuAD 2.0 数据集上，微调后的学生模型甚至比教师模型高出 19 分。这意味着你只需极低的成本，就能在自己的硬件上实现前沿模型级别的准确率。 微调后性能最佳的模型：Qwen3 系列模型在微调后始终表现最强，其中 4B 版本整体表现最优。如果你的目标是在特定任务上获得最高准确率，Qwen3-4B 就是你的首选。 最具可微调性（🐟-ble）（微调收益最大）：小型模型从微调中获得的提升远超大型模型。 如果你受限于使用非常小的模型（1B–3B），也不必担心 —— 它们能从微调中获益最多，能够大幅缩小与更大模型之间的性能差距。 如果你正在构建需要在设备端、本地或边缘侧运行的 AI 应用，你很可能问过自己：我该微调哪个小型语言模型（SLM）？目前 SLM 领域选择众多（Qwen、Llama、Gemma、Granite、SmolLM），每个系列都提供多种模型规模的版本。选错基础模型可能意味着有数周时间在浪费计算资源，或者得到的模型始终无法达到生产质量要求。 我们进行了一项系统的基准测试，用数据来回答这个问题。借助 distil labs 平台，我们在 8 个不同的任务上（分类、信息抽取、开卷问答、闭卷问答）微调了 12 个模型，然后将它们的性能相互比较，并与用于生成合成训练数据的教师大模型进行对比。 本文回答了四个实际问题： 我们评估了以下模型： 针对每个模型，我们测量了： 我们的 8 项基准测试涵盖分类（TREC、Banking77、Ecommerce、Mental Health）、文档理解（docs）以及问答任务（HotpotQA、Roman Empire QA、SQuAD 2.0）。 为了实现公平测量，我们分别计算了每个模型在各个基准测试上的排名，然后计算所有任务上的平均排名，并以 95% 置信区间作为误差棒（error bars）绘制在图中。平均排名越低，表示整体性能越好。 冠军：Qwen3-4B-Instruct-2507（平均排名：2.25） Qwen3 系列占据了排行榜前列，其中 Qwen3-4B-Instruct-2507 摘得桂冠。值得注意的是，这款 4B 模型的表现甚至超过了更大的 Qwen3-8B，这表明在蒸馏任务中，Qwen3 的较新版本（2025 年 7 月 25 日更新的版本）比之前的 8B SLM 效果更好。 核心结论：如果你希望获得效果最好的微调模型，并且拥有支持约 4B 参数规模模型微调的 GPU 显存，那么 Qwen3-4B-Instruct-2507 是你的首选。 冠军: Llama-3.2-1B-Instruct（平均排名：3.44） 这里我们测量的是可微调性（tunability） —— 即从基础性能到微调后性能的提升幅度（finetuned_score - base_score）。一个高度可微调的模型初始表现可能较弱，但经过微调后提升显著。 有趣的是，可微调性排名与模型大小的排序正好相反。像 Llama-3.2-1B 和 Qwen3-0.6B 这样的小型模型，从微调中获得的提升最大。而规模最大的模型（如 Qwen3-8B、granite-3.3-8b）在可微调性排名中接近垫底 —— 这并非因为它们表现差，而是因为它们起点相对较高，进步空间相对有限。 核心结论：如果你受限于使用极小的模型（<2B 参数），不必灰心。这些模型从微调中获益最大，并且能够显著缩小与更大模型之间的性能差距。 冠军: Qwen3-8B (平均排名: 1.75) 在未经任何微调的情况下，哪个模型开箱即用的表现最好？ 正如预期，基础性能与模型大小呈正相关。8B 模型占据了榜首位置，其中 Qwen3-8B 在所有基准测试中都展现出非常稳定的性能（标准差最低）。 核心结论：如果你需要在不进行微调的情况下在零样本/小样本场景下也获得较优的性能，大模型仍是你的最佳选择。但请记住 —— 经过微调后，这种优势会减弱。 是的。Qwen3-4B-Instruct-2507 在 8 项基准测试中的 7 项上达到或超越了教师模型。 经过微调的 4B 学生模型在 6 项基准测试上超越了 120B+ 参数的教师模型，在 1 项（HotpotQA）上持平，仅在 1 项（Banking77）上略微落后（差距在误差范围内）。提升最显著的是 SQuAD 2.0 闭卷问答任务，学生模型比教师模型高出 19 个百分点 —— 这充分证明，微调比单纯依赖提示词（prompting）能更有效地将领域知识注入模型。 核心结论：一个经过适当微调的 4B 参数模型，可以媲美甚至超越规模达其 30 倍的模型。这意味着推理成本可降低约 30 倍，并且能够完全在本地部署运行。 基于我们的基准测试结果，以下是选择基础模型的建议： 本次基准测试只是一个起点，我们正在积极努力让这些结果更加可靠： 每个模型都在使用我们蒸馏流程生成的合成数据进行微调（有关数据合成过程的详细信息，请参见《Small Expert Agents from 10 Examples》[1]）。针对每个基准测试，我们使用教师模型（GPTOss-120B）生成了 10,000 条训练样本。 微调采用 distil labs 的默认配置[2]：训练 4 个 epoch，学习率 5e-5，使用线性学习率调度器，以及 rank 为 64 的 LoRA。 所有模型均使用完全相同的超参数进行训练。评估在训练和合成数据生成过程中均未接触过的预留测试集上进行。 并非所有小型模型的性能都差不多，但经过微调后，它们之间的差距会大幅缩小。我们的基准测试表明，Qwen3-4B-Instruct-2507 在整体微调性能上表现最佳，不仅能媲美 120B+ 参数的教师模型，还能在单块消费级 GPU 上部署运行。在资源极度受限的环境中，像 Llama-3.2-1B 这样的小模型展现出卓越的可微调性，能够大幅缩小与大模型的性能差距。 核心结论：微调比基础模型的选择更重要。一个经过良好微调的 1B 模型，可以胜过仅靠提示词（prompting）驱动的 8B 模型。 END 本期互动内容 🍻 ❓你在微调小型语言模型时，最看重的是“开箱即用的强基础能力”，还是“微调后巨大的提升空间”？为什么？ 文中链接 [1]https://www.distillabs.ai/blog/small-expert-agents-from-10-ex... [2]https://docs.distillabs.ai/how-to/input-preparation/config 原文链接： https://www.distillabs.ai/blog/we-benchmarked-12-small-langua...01 TL;DR
02 引言
03 实验方法
04 问题一：哪个模型在微调后效果最好？
05 问题二：哪个模型最具可微调性？（即微调后提升最大）
06 问题三：哪个模型的基础性能最强？（即未经微调前）
07 问题四：我们表现最好的学生模型，真的能媲美教师模型吗？
08 实用建议
09 后续我们将进行的工作
10 训练细节
11 结论
2026 年 1 月中旬，瓦罗尼斯实验室的研究人员发现了这款工具包，Stanley 的出现，也印证了浏览器恶意软件商业化的趋势正不断加剧。1 月 12 日，一名化名为Стэнли的卖家首次发布该工具包的广告，还附带演示视频，展示其针对币安、美国加密货币交易所等加密货币平台的攻击效果。1 月 21 日，瓦罗尼斯已将该恶意攻击活动上报谷歌及该扩展的托管服务商；次日，相关命令与控制（C2）基础设施被下线，但这款恶意扩展程序仍在 Chrome 应用商店中正常可用。
该扩展程序一旦安装，会每 10 秒向其命令与控制基础设施发送一次心跳请求，且并非通过随机生成的标识，而是将受害者的 IP 地址作为唯一识别符。这一设计让攻击者能跨会话追踪用户、开展地域定向攻击，还可选择性触发攻击行为。卖家演示视频中的管理面板显示，攻击者可针对单个受害者配置URL 劫持规则，指定需要拦截的正规网站，以及替换展示的钓鱼页面。
该工具包的核心攻击手段，是在正规网站页面上叠加一个由攻击者控制的全屏 iframe 框架，加载钓鱼内容。关键在于，受害者浏览器的地址栏会始终显示正确的域名（如币安官网binance.com），但用户的所有操作实际都在钓鱼页面上完成。Stanley 还支持调用Chrome 原生推送通知功能，攻击者可通过该渠道发送诱导信息，相比普通网页弹窗，这类通知更具迷惑性。同时，该工具包还配备备用域名轮换机制，即便主命令与控制服务器被下线，恶意程序仍能正常运行。
