包含关键字 typecho 的文章

一、智能体的形态

我问大家一个问题,什么是 AI 的产品形态?

大模型只是底层的处理引擎,你总是需要一个应用层产品,对接用户的需求。这种 AI 的应用层,就称为"智能体"(agent)。

那么,问题就变成了,"智能体"应该是什么样?

早期的智能体只是对话应用(上图),后面加入了推理,可以思考复杂问题。

后来,向专业领域发展,演变出编程智能体(coding agent)、图像智能体、视频智能体等等,或者接入 MCP,获得外部应用操作能力,比如生成 Office 文件、操作浏览器。

这些形态基本已经成熟了,很多公司开始探索,下一阶段的智能体会是什么形态?

我最近在用 MiniMax 刚发布的 AI native Workspace(AI 原生工作台),欣喜地觉得,这可能就是答案。

二、Cowork 和 Skill

这个新产品,同时加入了 Anthropic 公司最近提出的两个新概念:Cowork 和 Skill。

所谓 Cowork,简单说,就是一个"计算机操作助手"。它本质是编程智能体的图形界面版,让不懂编程的用户,用自然语言说出需求,再通过 AI 生成底层代码并执行,自动操作本地计算机完成任务。

而 Skill 就更简单了,它是一篇预设的提示词,相当于"使用手册",向 AI 详细描述如何完成某一种特定任务。可以这样理解,每一个 Skill 就是一个专家,让 AI 拥有特定领域的技能。

这两个东西,一个是操作助手,一个是专家模式。前者用 AI 来操作计算机,后者让 AI 具备专门技能。

它们结合起来会怎样?

MiniMax AI native Workspace 就是这样一个产品,探索性地将 Cowork 和 Skill 结合在一起,同时具备两种能力,完全是一种全新的产品形态。

它的桌面端(desktop)提供 Cowork 能力,专家模式(experts)则提供 Skill 能力。

三、桌面端操作助手

下面,我来展示,它跟传统智能体的差异在哪里。

它的桌面客户端定位就是"AI 原生工作台",具备以下能力。

  • 直接访问本地文件:能够读写,以及自动上传或下载文件。
  • 自动化工作流程:能够分解任务,运行 Web 自动化。
  • 交付专业成果:运行结束后可以生成高质量的交付产物,比如 Excel 电子表格、PowerPoint 幻灯片、格式化文档。
  • 长时间运行任务:对于复杂任务,可以长时间运行,不受对话超时或上下文限制的影响。

注意,由于它可以操作计算机,并跟互联网通信,执行之前,一定要指定目录,防止读写不该操作的目录,而且要有备份,防止原始文件被删改。

首先,前往官网下载桌面客户端,Windows/Mac 版本均有,新注册用户目前可以免费试用3天。

安装后运行,直接进入任务界面,就是一个传统的对话框。

这时指定运行目录,就进入"工作台"模式,可以对该目录进行操作。软件会跳出一个警告,提示风险。

这时,就可以让它执行各种任务了。比如,我让它整理各种电子服务的发票 PDF 文件,然后生成一个汇总的 Excel 文档。

这时,它会在当前目录里面,自动安装一个 Python 虚拟环境,然后生成 Python 脚本并执行。

很快就生成好了 Excel 文件。

以此类推,各种文件整理的事情,都能交给它,比如整理照片、文件重命名等等。

它还能进行网页自动化,比如自动浏览某个网页,并提取信息、总结内容。

四、专家系统

上面展示了它的工作台功能,可以担当"数字员工",下面再来看看它的"专家系统"。

所谓"专家系统",就是注入特定的提示词文件,扩展智能体的技能,相当于深度的知识和能力注入。用户还可以上传私有知识库。

大家可以打开它的网页端,点击左边栏的"探索专家"。

系统内置了一些"预设专家",可以直接使用。

我选了一个系统提供的"Icon 制作器",就是制作 Logo 的技能,看看好不好用。

我要求制作一个"熊猫吃冰淇淋"的 Logo,系统提示要选择一种设计风格。

最后生成了两个文件(坐姿和站姿)供选择,效果还不错。

五、创建新技能

除了预设的专家,系统也允许你创建"我的专家",也就是某种自定义技能。

你需要输入能力描述和指令,还可以添加对应的 MCP、SubAgent、环境变量、Supabase 数据库等等。

我直接把 Anthropic 公司提供的 Skill 文件输入,看看效果。

我选了 frontend-design(前端设计)技能,输入以后就可以在"我的专家"分页上看到。

注意,系统目前只支持输入技能描述文件,还不支持上传静态资源文件(asset),希望后面可以加上。

选中这个专家以后,我要求生成一个算法可视化页面。

"生成一个排序算法可视化网站,列出常见排序算法的可视化动画。选中某个算法后,会展示该算法的动画效果。"

生成过程大概十分钟左右,就得到了结果。系统生成了十种排序算法的动画,并直接部署上线。

我后来又调整了一下动画配色,大家可以去这个网站看看效果,还是很酷的。

六、总结

AI native Workspace 将 AI 智能体引入了本地计算机,可以进行自动化操作,同时加入技能接口,允许注入外部知识和能力。并且,所有操作都可以通过自然语言对话完成,对用户的要求低。

这一下子打开了 AI 智能体的想象空间,它所能完成的任务,将不再受限于模型的能力,而只受限于我们的想象力。

我认为,这个产品代表了下一阶段 AI 智能体的发展方向,将开启很多全新的可能性,等待我们去探索。

(完)

基于 YOLOv8 的多犬种(60种常见犬类)智能识别系统项目 [目标检测完整源码]

—— 面向 60 类常见犬种的目标检测与可视化应用落地


在这里插入图片描述

一、背景与问题:为什么“犬种识别”值得工程化?

在宠物经济高速发展的今天,犬类已经从“家庭陪伴动物”逐步演变为需要精细化管理与智能化服务的对象。在实际场景中,犬种信息直接影响:

  • 饲养与行为管理策略
  • 疫苗接种与健康风险评估
  • 宠物交易、领养与救助流程
  • 城市宠物管理与公共安全

然而,现实中对犬种的识别依然高度依赖人工经验,不仅主观性强,而且在混血犬、幼犬、复杂光照条件下误判率较高。

问题的本质在于:

如何构建一个既具备高识别精度,又真正“可落地使用”的犬种识别系统?

本项目正是围绕这一问题,给出了一套完整可复现的工程级解决方案
在这里插入图片描述

源码下载与效果演示

哔哩哔哩视频下方观看:
https://www.bilibili.com/video/BV1wB8MzsE9P/

在这里插入图片描述

包含:

📦完整项目源码

📦 预训练模型权重

🗂️ 数据集地址(含标注脚本


二、系统整体架构设计

该项目并非单一模型 Demo,而是一个从数据、训练到部署的完整闭环系统,整体架构如下:

┌────────────┐
│  数据集层  │  犬类图像 + YOLO 标注
└─────┬──────┘
      ↓
┌────────────┐
│  模型训练  │  YOLOv8 Detection
└─────┬──────┘
      ↓
┌────────────┐
│  推理服务  │  图片 / 视频 / 摄像头
└─────┬──────┘
      ↓
┌────────────┐
│  GUI 应用  │  PyQt5 桌面端
└────────────┘

核心目标只有一个:
让“深度学习模型”真正变成“普通用户能用的软件”。
在这里插入图片描述
在这里插入图片描述


三、模型选型:为什么是 YOLOv8?

在多类别实时检测任务中,YOLO 系列一直是工程实践的主流方案。本项目最终选择 YOLOv8,主要基于以下考虑:

3.1 架构层面的优势

  • Anchor-Free 设计
    减少超参数依赖,收敛更稳定
  • Task-Aligned Assigner
    分类与定位目标一致性更强
  • 更轻量的 Backbone 与 Neck
    在保证精度的同时提升推理速度

3.2 工程友好性

  • 原生支持 PyTorch / ONNX
  • Ultralytics 提供统一 CLI 与 Python API
  • 训练、验证、推理接口高度一致

这使得模型不仅“好训”,而且非常适合与 GUI、业务系统结合


四、犬种数据集构建与标注规范

4.1 数据规模与类别

本系统覆盖 60 种常见犬类,包括但不限于:

  • 柯基、哈士奇、柴犬
  • 金毛、拉布拉多、贵宾犬
  • 德牧、边牧、博美等

每个类别均包含多姿态、多背景、多尺度样本,尽量贴近真实使用场景。


4.2 数据组织结构(YOLO 标准)

dataset/
├── images/
│   ├── train/
│   └── val/
├── labels/
│   ├── train/
│   └── val/

标签文件采用 YOLO 标准格式:

<class_id> <x_center> <y_center> <width> <height>

所有坐标均为 相对比例值,确保模型在不同分辨率下具备一致性。


在这里插入图片描述

五、模型训练流程详解

5.1 训练配置示例

yolo detect train \
  data=dog.yaml \
  model=yolov8n.pt \
  epochs=100 \
  batch=16 \
  imgsz=640

关键训练策略包括:

  • 合理的 batch size 控制显存占用
  • 数据增强(翻转、尺度变换、颜色扰动)
  • 早期收敛阶段重点关注 box_loss 与 cls_loss

在这里插入图片描述

5.2 训练过程监控

YOLOv8 在 runs/detect/train/ 目录中自动生成:

  • 损失函数变化曲线
  • mAP@0.5 / mAP@0.5:0.95
  • 混淆矩阵(类别间区分能力)

在实际实验中,多数犬种在 mAP@0.5 指标上稳定超过 90%,具备实际应用价值。


六、多模态推理能力设计

本系统支持多种输入形式,统一由同一推理接口处理。

6.1 单张图片与批量图片

  • 支持文件与文件夹级别输入
  • 自动生成标注结果图
  • 适合数据复查与分析场景

6.2 视频与实时摄像头

  • 基于 OpenCV 逐帧推理
  • 支持实时显示检测结果
  • 可选保存输出视频文件

这一能力使系统能够直接应用于:

  • 宠物门店实时监控
  • 救助站视频巡检
  • 展示型 AI 应用演示

在这里插入图片描述

七、PyQt5 图形界面设计要点

为了降低使用门槛,项目引入 PyQt5 构建完整桌面应用。

7.1 界面功能划分

  • 输入控制区:选择图片 / 视频 / 摄像头
  • 结果展示区:实时显示检测画面
  • 日志与状态区:输出模型运行信息

7.2 工程价值

  • 无需命令行操作
  • 非算法人员也可直接使用
  • 适合作为课程设计、毕业设计、项目演示系统

八、推理代码核心示例

from ultralytics import YOLO

model = YOLO("best.pt")
results = model("test.jpg", conf=0.25, save=True)

for box in results[0].boxes:
    cls_id = int(box.cls)
    score = float(box.conf)

推理结果中可直接获取:

  • 类别 ID
  • 置信度
  • 边框坐标

便于后续对接业务逻辑或二次开发。


在这里插入图片描述

九、项目工程化与“开箱即用”

本项目已完成完整工程封装,具备以下特点:

  • 已训练完成的权重文件
  • 完整源码与数据集
  • 一键启动 GUI 程序
  • 提供训练与部署说明

运行检测仅需:

python main.py

无需重新训练,即可体验完整系统功能。


十、可扩展性与二次开发方向

该项目并不局限于犬种识别,其工程框架可直接扩展为:

  • 🐱 猫咪品种识别
  • 🐦 鸟类 / 野生动物监测
  • 🐄 畜牧养殖视觉分析
  • 🏙️ 智慧城市动物管理系统

本质上,这是一个可复用的 YOLOv8 + GUI 工程模板。


总结:一个真正“能用”的目标检测项目应该是什么样?

相比单纯展示模型精度,本项目更关注:

  • 是否具备完整工程链路
  • 是否方便非算法人员使用
  • 是否具备二次开发潜力

通过 YOLOv8 与 PyQt5 的深度结合,该系统成功实现了从算法到应用的跨越。

🚀 如果你正在寻找一个具备训练、检测、部署一体化能力的目标检测项目实践,这套基于 YOLOv8 的多犬种识别系统,值得你深入研究与复用。

项目介绍

图片
图片
本系统是一个基于深度学习的卫星遥感图像智能识别平台,旨在为用户提供高效、准确的遥感图像分类服务。系统采用Flask轻量级Web框架构建后端服务,集成ResNet50深度卷积神经网络模型,实现了对卫星遥感图像的自动化识别与分类。系统支持识别七大类地物类型,包括草地、农田、工业区、河流湖泊、森林、居民区和停车场,能够满足土地利用监测、城市规划、环境评估等多种应用场景的需求。

图片

图片

关键技术栈:resnet50算法
ResNet50(Residual Network 50层)是深度学习领域中具有里程碑意义的卷积神经网络架构,由何恺明等学者于2015年提出。该网络的核心创新在于引入了残差学习(Residual Learning)机制,通过跳跃连接(Skip Connection)解决深层网络训练中的梯度消失和梯度爆炸问题,使得网络深度可以突破传统限制,达到甚至超过100层。ResNet50网络包含49个卷积层和1个全连接层,采用了5个阶段的残差块设计,每个阶段包含不同数量的残差单元,通过堆叠这些残差块构建深度网络结构。

图片
图片
系统功能模块图

图片
图片
演示视频 and 完整代码 and 安装
地址:https://www.yuque.com/ziwu/qkqzd2/kma4wpp387ifg6ci

因为平板没在手中,又想大屏玩金铲铲,手头只有 mac,于是网上查询教程,发现站内还没有教程,于是打算结合多个查询到的教程还有踩到的坑汇总到一起,帮助佬友们在 mac 上畅玩金铲铲(包含开启语音功能)

如有侵权,请联系删除

  1. 下载并安装 playcover nightly 版本
    Download - PlayCover 选择 nightly 版本(重要)
  2. 下载砸壳金铲铲之战(这个就不用多教了吧~
  3. 打开 playcover,如果无法打开,进入设置 - 隐私与安全性,点允许打开
  4. 打开后导入金铲铲的 ipa 包,如果碰见下图情况,执行这个命令 mkdir ~/Library/Containers/io.playcover.PlayCover/Applications,同时将下载下来的 ipa 包改名为 jkchess, 再次安装就可以了
  5. 在 playcover 中打开设置,勾选图片中的选项,然后进入杂项,把应用程序类型改成 games

  6. 先进入游戏,登陆后退出,然后运行这行代码来持续监听金铲铲的语音申请
    EXECUTABLE=~/Library/Containers/io.playcover.PlayCover/Applications/com.tencent.jkchess.app/jkchess && python3 -c "import sys; f=open(sys.argv[1],'rb+'); d=f.read(); i=d.find(b'\x7F\x0A\x00\x71\x93\x02\x88\x1A\xE0\x03\x13\xAA'); f.seek(i+8) if i!=-1 else exit(1); f.write(b'\x20\x00\x80\xD2'); f.close()" $EXECUTABLE && codesign -fs- $EXECUTABLE --deep --preserve-metadata=entitlements
    代码需要 python 环境,但是只要装过 brew,这个代码可以直接运行
  7. 执行成功后重新进入游戏,点击麦克风图标(会有一两次无法点击,不用管,多点两次),这时候会出现允许麦克风权限的提示,点允许,设置的麦克风权限中就有金铲铲了

  8. 现在就可以跟朋友一起开麦爽快开黑了

📌 转载信息
原作者:
ninuan
转载时间:
2026/1/22 21:09:21

序幕:从“百科全书”到“实时搭档”

大家发现了吗?我们现在使用 AI 的方式,本质上还是在查阅一本超级百科全书

无论是在 ChatGPT 还是 Claude 的对话框里,我们总是重复着:提问、等待、阅读文字、复制粘贴。这种交流永远被困在一个小小的“聊天框”里,就像你雇佣了一个超级天才助手,但他被关在隔壁的小黑屋里,只能通过门缝给你“递纸条”。你在这头对着复杂的业务界面抓耳挠腮,他在那头空有一身才华却看不见你的屏幕。

这种“隔靴操痒”的交互方式,是时候结束了。

想象一下,如果 AI 不仅仅是那个能言善辩的聊天机器人,而是一个能实时看懂你的操作、感知你的困惑、并直接帮你操作界面的“数字化合伙人”?当你拖动地图,他立刻补全路径;当你填表卡壳,他直接变出最合适的选项。他不再躲在对话框后面,而是直接走进你的工作流,伸手接过了那把名为“UI”的钥匙。这就是 AG-UI(Agent-User Interaction Protocol) 正在发起的革命:让 AI 走出聊天框,让界面随心而动。


第一部分:什么是 AG-UI?

用最简单的话说,AG-UI 是 AI 智能体(Agent)和用户界面(UI)之间的“通用翻译官”

在 AG-UI 出现之前,如果你想把 AI 接入 App,程序员需要费劲地把 AI 的文字输出手动“翻译”成网页上的按钮。而且,市面上有无数种 AI 框架,又有无数种前端终端,要把它们两两连接,工作量巨大。

AG-UI 的出现,就像是在 AI 大脑与屏幕之间修通了一条标准化的“高速公路”: 它不管后端用的是什么模型,前端用的是什么设备,只要接上这根管道,AI 就能从一个后台的“思考者”,变成前台的“协作者”。

知识点:AG-UI vs A2UI
这里有两个概念容易混淆。A2UI(Google 出品) 像是 UI 的“建筑图纸”,定义了界面长什么样;而 AG-UI 则是“物流快递”,负责把这张图纸实时、安全地送到你的屏幕上。

第二部分:AG-UI 在智能体协议栈中的角色

要理解 AG-UI 的威力,我们需要看它在整个 AI 智能体生态(Agent Protocol Stack)中的位置。它与其他两大主流协议相辅相成,共同构成了 AI 时代的底层架构:

  • MCP (Model Context Protocol) —— 赋能工具: 负责连接 AI 与各种工具(Tools)或数据库。它让 Agent 拥有了“手”,可以去查资料、调 API。
  • A2A (Agent-to-Agent) —— 协同合作: 负责不同 Agent 之间的通信。它让 Agent 拥有了“对讲机”,可以呼唤其他 AI 协作。
  • AG-UI —— 触达用户: 这是最关键的一环。 它负责将 Agent 的能力引入到面向用户的应用程序中。它让 Agent 拥有了“窗口”,直接与人类在 UI 界面上共事。

流程简述: Agent 通过 MCP 调用工具获取数据,通过 A2A 协同其他专家 AI,最后通过 AG-UI 将处理结果直接转化成你屏幕上的交互组件。


第三部分:颠覆性的三宗“最”

  1. 最懂你:生成式 UI (Generative UI)。 以前的软件是程序员提前写死的。有了 AG-UI,AI 可以根据对话内容,现场为你“造”软件。而且这过程非常丝滑——组件会随着 AI 的思考过程实时在屏幕上“生长”出来。
  2. 最默契:共享状态 (Shared State)。 这就是“双向同步”的超能力。你在界面上拉动滑块增加了参数,AI 的“大脑”会立刻感知到这个动作并同步做出反馈。你们共享同一个“上下文”,就像并肩作战的战友。
  3. 最安全:人在回路 (Human in the Loop)。 AG-UI 允许 AI 在关键时刻弹出一个确认界面。AI 没法乱写代码,它只能发送数据指令去调用你预设好的“安全积木”

第四部分:生态现状——工具已在手

虽然协议发布时间不长,但它的生态爆发速度惊人:

  • 全明星后端支持: LangGraph、CrewAI、Microsoft Autogen 等主流框架均已接入。
  • 前端大厂入局: 除了 React 方案,Google 的 Flutter 团队已经推出了 GenUI SDK。这意味着“设计即基础设施”的时代已经开启。
  • 快速体验: 如果你想现在尝试,只需一行命令:npx create-ag-ui-app

第五部分:核心洞察——“设计”正在变成基础设施

作为开发者,我感受到这场革命最震撼的地方在于:前端的工作方式将彻底重构。

  1. 从“盖房子”到“造积木”: 以后前端不再负责拼装最终页面(那是 AI 的事),而是负责设计足够原子、具备强语义化的“组件积木”。
  2. 框架的“降维打击”: 当 Flutter 等框架官方定义的“标准组件”已经足够美观且具备完美的 AI 语义时,企业将不再需要雇佣设计师去重新发明轮子。“设计”将从一项昂贵的业务成本,变成框架自带的基础设施。

结语:拥抱流动的未来

2026 年是 AI 智能体爆发的元年。界面的脸孔将不再死板,它会随你的需求而流动。UI 不再是挡在你和功能之间的那层“膜”,而是变成了一种随用随取的资源。

未来的应用不是由菜单定义的,而是由你的意图定义的。

别再纠结 CSS 的像素偏移了,去研究 AI 如何理解你的业务意图吧。这场革命,正在你运行 npx create-ag-ui-app 的那一刻开始。

本文由mdnice多平台发布

分享一个开源项目:BumbleCore

佬友们大家好!

这是我加入 L 站第一次发帖子 hhhh,很开心很激动。发帖的目的是想给大家分享一个开源项目。

我是 25 届毕业生,毕业后在一家大模型公司任算法工程师一职。

在工作之余我自己写了这个项目 → BumbleCore

什么是 BumbleCore?

BumbleCore 是一个大模型训练框架,完整支持 Pretrain → SFT → DPO 三阶段训练流程。

它的底层基于 DeepSpeed 构建,但没有使用 Hugging Face Trainer 等高级封装接口。从数据加载、预处理、训练循环、损失计算,到模型推理,全部都是手动实现的。

特别之处:内置 BumbleBee 模型架构

项目里还实现了一个名为 BumbleBee 的模型架构,设计上参考了 Qwen 的源码。你可以直接用它进行完整的三阶段训练。

它的最大优势是:你可以自由初始化任意参数规模的模型

  • 想做小实验?配个 0.5B 的模型就行。
  • 想跑大规模训练?也能轻松扩展到几十 B。
  • 如果你有算法创新的想法,比如修改注意力机制、加新模块等,这个架构就是一个非常干净、灵活的模板。


为什么要做这样一个 “手搓” 框架?

我的初衷很简单:给想深入学习大模型训练的人,提供一个清晰、透明、可读的代码范本

在这个项目里,你可以直观地看到:

  • 输入数据的具体格式(Pretrain / SFT / DPO 各阶段都支持)
  • 损失函数是怎么一步步计算的
  • 推理时 top-ptemperatureKV Cache 等参数如何工作
  • 分布式训练中 DeepSpeed 的集成细节(ZeRO、混合精度、梯度累积等)

这其实就是我自己学习大模型技术的过程总结。项目的使用方式也尽量贴近主流开源框架(比如 LLaMA-Factory),所以你不需要从零适应,但又能真正 “看到背后发生了什么”。


我的学习理念

在学习过程中,我个人不太喜欢 Trainer 那种高度封装的接口,更倾向于灵活、可控的手动实现。这也是为什么在已有那么多优秀开源框架的情况下,我还是决定自己写一个。当然生产环境另说哈哈。

这可能也跟我自己的学习习惯有关:

如果给我一周时间学一项新技术,我会花一天用 AI 把功能跑通,剩下的六天,全部用来搞懂 “为什么这样实现”。

BumbleCore 就是基于这种理念打造的 —— 不止让你会用,更要让你真正理解
你不用再去啃晦涩难懂的 Trainer 源码,而是可以直接阅读这个项目里每一行清晰、注释充分的代码,掌握微调背后的每一个细节。


前端展示 & 推理体验

项目还包含一个简单的 Web 前端界面(BumbleChat),方便你本地测试模型效果:

训练好的模型支持 OpenAI 兼容 API,也可以通过命令行或 Web 界面进行交互式聊天。


最后

如果这个项目对你有帮助,或者你觉得它对社区有价值,欢迎点个 Star

非常欢迎佬友提 Issue、PR,一起把它做得更好!


📌 转载信息
转载时间:
2026/1/22 21:08:47

从上次的油猴脚本说起:

这次抄了一下 ChatGPT 页面的样式,准备整合到导出脚本中,佬友可以期待下

独立预览:my-app


📌 转载信息
原作者:
touch
转载时间:
2026/1/22 21:08:30

周五了,利用摸鱼时间为 2Libra 打造了新的油猴脚本 - 2Libra Plus。

✨ 主要功能

1. 通知中心增强

  • 未读消息高亮:自动检测通知列表中的未读条目,并在左侧添加醒目的橙色竖线标记,帮助你快速定位未处理的通知。
  • 自动已读(可选):支持进入通知页后自动将当前页消息标记为已读,减少重复点击操作(默认开启,可在设置中关闭)。

screencapture

2. 主题列表增强

  • 回复时间颜色渐变:根据你上次在首页查看时间,将最新回复显示得更醒目,较久之前的回复颜色更浅,帮助你一眼区分「最近更新」和「很久没动」的帖子。为了避免频繁刷新带来的视觉抖动,「上次查看时间」在 5 分钟内不会更新;最新回复会使用 --color-primary 颜色展示,更加醒目。

screencapture

3. 个性化设置

  • 提供可视化的设置面板,可随时开启或关闭特定功能,按需定制你的使用体验。

!. 还会有更多功能...

⬇️ 安装方法

相关链接

建议反馈

大家如有需要的功能,尽管提,觉得有用我会考虑加进去。

金仓数据库中包含各种数据库对象,常见的KingBase对象有:数据库、模式、表、索引、视图、存储过程、存储函数和触发器等等。这里将介绍金仓数据库中常见的数据库对象以及如何使用它们。视频讲解如下:
https://www.bilibili.com/video/BV1RQz3B9ERT/?aid=115930646454...

一、 数据库与模式

数据库本身也是一个KingBase的数据库对象。数据库对象中包含其他所有的数据库对象,如:模式、表、视图、索引等等。使用命令create database可以创建一个新的数据库,下面展示了该命令的格式:

CREATE DATABASE name
     [ WITH ] [ OWNER [=] user_name ]
           [ TEMPLATE [=] template ]
           [ ENCODING [=] encoding ]
           [ LC_COLLATE [=] lc_collate ]
           [ LC_CTYPE [=] lc_ctype ]
           [ TABLESPACE [=] tablespace_name ]
           [ ALLOW_CONNECTIONS [=] allowconn ]
           [ CONNECTION LIMIT [=] connlimit ]
           [ IS_TEMPLATE [=] istemplate ]

一个数据库包含一个或多个模式(Schema),模式中又包含了表、函数及操作符等数据库对象。创建新数据库时,KingBase会自动创建名为public的模式。使用命令create schema可以创建一个新的模式,下面展示了该命令的格式:

CREATE SCHEMA schema_name [ AUTHORIZATION role_specification ] [ schema_element [ ... ] ]
CREATE SCHEMA AUTHORIZATION role_specification [ schema_element [ ... ] ]
CREATE SCHEMA IF NOT EXISTS schema_name [ AUTHORIZATION role_specification ]
CREATE SCHEMA IF NOT EXISTS AUTHORIZATION role_specification

其中 role_specification 可以是:

    user_name
  | CURRENT_USER
  | SESSION_USER

在了解到数据库与模式的概念后,下面通过具体的操作来演示如何创建和使用它们。
(1)创建一个新的数据库dbtest。

scott=# create database dbtest;

(2)查看已存在的数据库列表。

scott=# \l

# 输出的信息如下:
                                        数据库列表
   名称    | 拥有者 | 字元编码 |  校对规则   |    Ctype    | ICU 排序 |     存取权限      
-----------+--------+----------+-------------+-------------+----------+-------------------
 dbtest    | system | UTF8     | zh_CN.UTF-8 | zh_CN.UTF-8 |          | 
 kingbase  | system | UTF8     | zh_CN.UTF-8 | zh_CN.UTF-8 |          | 
 scott     | system | UTF8     | zh_CN.UTF-8 | zh_CN.UTF-8 |          | 
 security  | system | UTF8     | zh_CN.UTF-8 | zh_CN.UTF-8 |          | 
 template0 | system | UTF8     | zh_CN.UTF-8 | zh_CN.UTF-8 |          | =c/system        +
           |        |          |             |             |          | system=CTc/system
 template1 | system | UTF8     | zh_CN.UTF-8 | zh_CN.UTF-8 |          | =c/system        +
           |        |          |             |             |          | system=CTc/system
 test      | system | UTF8     | zh_CN.UTF-8 | zh_CN.UTF-8 |          | 
(7 行记录)

(3)切换到数据库dbtest。

scott=# \c dbtest 
您现在以用户名"system"连接到数据库"dbtest"。

(4)查看数据库dbtest中的模式。

dbtest=# \dn

# 输出的信息如下:
       架构模式列表
       名称       | 拥有者 
------------------+--------
 anon             | system
 dbms_job         | system
 dbms_scheduler   | system
 dbms_sql         | system
 kdb_schedule     | system
 perf             | system
 public           | system
 src_restrict     | system
 sys_hm           | system
 sysaudit         | system
 sysmac           | system
 wmsys            | system
 xlog_record_read | system
(13 行记录)

# 这里的public的模式是创建数据库对象的默认模式。

(5)创建一个新的模式。

dbtest=# create schema firstschema;

(6)重新查看数据库dbtest中的模式。

dbtest=# \dn

# 输出的信息如下:
       架构模式列表
       名称       | 拥有者 
------------------+--------
 anon             | system
 dbms_job         | system
 dbms_scheduler   | system
 dbms_sql         | system
 firstschema      | system
 kdb_schedule     | system
 perf             | system
 public           | system
 src_restrict     | system
 sys_hm           | system
 sysaudit         | system
 sysmac           | system
 wmsys            | system
 xlog_record_read | system
(14 行记录)

二、 创建与管理表

表是一种非常重要的数据库对象。金仓数据库的数据都是存储在表中。KingBase的表是一种二维结构,由行和列组成。表有列组成,列有列的数据类型。下面通过具体的步骤来演示如何操作金仓数据库的表。这些操作包括创建表、查看表、修改表和删除表。

(1)创建一张新的表test2.

dbtest=# create table test2(id int,name varchar(32),age int);

# 由于创建表时没有指定模式的名称,因此表将创建在public模式下。
# 如果要在指定的模式下创建表,可以使用下面的语句:
dbtest=# create table firstschema.test2(id int,name varchar(32),age int);

(2)查看表的结构。

dbtest=# \d test2

# 输出的信息如下:
                    数据表 "public.test2"
 栏位 |            类型            | 校对规则 | 可空的 | 预设 
------+----------------------------+----------+--------+------
 id   | integer                    |          |        | 
 name | character varying(32 char) |          |        | 
 age  | integer                    |          |        | 

(3)在表中增加一个字段。

dbtest=# alter table test2 add gender varchar(1) default 'M';

# 这里增加了一个gender字段用于表示性别,默认是“M”。

(4)重新查看表的结构。

dbtest=# \d test2

# 输出的信息如下:
                         数据表 "public.test2"
  栏位  |            类型            | 校对规则 | 可空的 |     预设     
--------+----------------------------+----------+--------+--------------
 id     | integer                    |          |        | 
 name   | character varying(32 char) |          |        | 
 age    | integer                    |          |        | 
 gender | character varying(1 char)  |          |        | 'M'::varchar

(5)修改表将gender字段的长度改为10个字符。

dbtest=# alter table test2 alter gender type varchar(10);

(6)删除gender字段。

dbtest=# alter table test2 drop column gender;

(7)删除表test2。

dbtest=# drop table test2;

三、 在查询时使用索引

数据库查询是数据库的主要功能之一,最基本的查询算法是顺序查找(linear search)时间复杂度为O(n),显然在数据量很大时效率很低。优化的查找算法如二分查找(binary search)、二叉树查找(binary tree search)等,虽然查找效率提高了。但是各自对检索的数据都有要求:二分查找要求被检索数据有序,而二叉树查找只能应用于二叉查找树上,但是数据本身的组织结构不可能完全满足各种数据结构。所以在数据之外,数据库系统还维护着满足特定查找算法的数据结构。这些数据结构以某种方式指向数据,这样就可以在这些数据结构上实现高级查找算法。这种数据结构就是索引。金仓数据库官方对索引的定义为:索引(Index)是帮助KingBase高效获取数据的数据结构。索引是一种数据结构。金仓数据库默认的索引类型是B树索引。下图是一颗简单的B树,可见它与二叉树最大的区别是它允许一个节点有多于2个的元素,每个节点都包含key和数据,查找时可以使用二分的方式快速搜索数据。

image.png

在了解到了KingBase索引的基本知识以后,下面将通过具体的步骤演示来说明如何在KingBase中创建索引,并且在查询语句中使用它。
(1)查看scott数据库中部门表dept和员工表emp上的索引信息。

scott=# select index_name,index_type,table_name,status
        from user_indexes where table_name in ('DEPT','EMP');
        
# 输出的信息如下:
 index_name | index_type | table_name | status 
------------+------------+------------+--------
 DEPT_PKEY  | BTREE      | DEPT       | VALID
 EMP_PKEY   | BTREE      | EMP        | VALID
(2 行记录)

# user_indexes是一个视图,可以通过它获取某个用户创建的索引信息。

(2)使用create index命令在员工表emp的薪水sal字段上创建完全索引。

scott=# create index index_full on emp using btree(sal);

# 完全索引会基于该字段上的所有值创建索引。
# 同时,在创建索引的时候会进行锁表的操作,可以使用 CIC (create index concurrently),
# 但创建索引的时间相对较长。例如:
scott=# create index concurrently index1 on emp using btree(sal);

(3)下面的语句将在员工表上创建一个部分索引。

scott=# create index index_part on emp using btree(sal) where sal<3000;

# 部分索引是对于表的部分数据创建索引。
# 如果发现表的某一部分数据查询次数较多时,可以考虑在这部分数据上创建一个部分索引。
# 部分索引相较于完全索引,查询的性能将得到提高,并且部分索引文件所占的空间也会小于全索引。

(4)在员工表emp的员工姓名ename上创建表达式索引。

scott=# create index index_exp on emp(lower(ename));

# 对于表达式索引的维护代价比较高,因为在每一行插入或更新时需要重新计算相应表达式的值,
# 但是针对于表达式索引在查询时的效率更高,因为表达式的值会直接存储在索引中。

(5)使用explain语句查看SQL查询时的执行计划。

scott=# explain select * from emp where lower(ename) like 'king';

# 输出的信息如下:
                     QUERY PLAN                     
----------------------------------------------------
 Seq Scan on emp  (cost=0.00..1.21 rows=1 width=42)
   Filter: (lower((ename)::text) ~~ 'king'::text)
(2 行记录)

# 从输出的执行计划可以看出,此时并没有使用到表达式索引。
# 这是由于KingBase并不能强制使用特定的索引,或者完全阻止KingBase进行Seq Scan的顺序扫描。
# 但可以通过将参数enable_seqscan设置为 off的方式让KingBase尽可能避免执行某些扫描类型,
# 但这样的方式多用于开发和调试中。

(6)禁止金仓数据库使用顺序扫描。

scott=# set enable_seqscan = off;

(7)重新使用explain语句查看SQL查询时的执行计划。

scott=# explain select * from emp where lower(ename) like 'king';

# 输出的信息如下:
                              QUERY PLAN                              
----------------------------------------------------------------------
 Index Scan using index_exp on emp  (cost=0.14..8.16 rows=1 width=42)
   Index Cond: (lower((ename)::text) = 'king'::text)
   Filter: (lower((ename)::text) ~~ 'king'::text)
(3 行记录)

四、 使用视图简化查询语句

当SQL的查询语句比较复杂并且需要反复执行,如果每次都重新书写该SQL语句显然不是很方便。因此金仓数据库数据库提供了视图用于简化复杂的SQL语句。视图(View)是一种虚表,其本身并不包含数据。它将作为一个select语句保存在数据字典中的。视图依赖的表叫做基表。通过视图可以展现基表的部分数据;视图数据来自定义视图的查询中使用的基表。在金仓数据库中创建视图的基本语法格式如下:

CREATE [ OR REPLACE ] [ TEMP | TEMPORARY ] [ RECURSIVE ] [ FORCE ] VIEW name [ ( column_name [, ...] ) ]
    [ WITH ( view_option_name [= view_option_value] [, ... ] ) ]
    [ BEQUEATH { CURRENT_USER | DEFINER } ]
    AS query
    [ WITH { [ CASCADED | LOCAL ] CHECK OPTION } | READ ONLY ]

在了解的视图的作用后,下面通过具体的步骤来演示如何使用视图。
(1)基于员工表emp创建视图。

scott=# create or replace view view1
as
select * from emp where deptno=10;

# 视图也可以基于多表进行创建,例如:
scott=# create or replace view view2
as
select emp.ename,emp.sal,dept.dname
from emp,dept
where emp.deptno=dept.deptno;

(2)查看视图view2的结构。

scott=# \d view2

# 输出的信息如下:
                      视图 "public.view2"
 栏位  |            类型            | 校对规则 | 可空的 | 预设 
-------+----------------------------+----------+--------+------
 ename | character varying(10 char) |          |        | 
 sal   | integer                    |          |        | 
 dname | character varying(10 char) |          |        | 

(3)从视图中查询数据。

scott=# select * from view2;

# 输出的信息如下:
 ename  | sal  |   dname    
--------+------+------------
 MILLER | 1300 | ACCOUNTING
 CLARK  | 2450 | ACCOUNTING
 KING   | 5000 | ACCOUNTING
 SCOTT  | 3000 | RESEARCH
 JONES  | 2975 | RESEARCH
 SMITH  |  800 | RESEARCH
 ADAMS  | 1100 | RESEARCH
 FORD   | 3000 | RESEARCH
 WARD   | 1250 | SALES
 TURNER | 1500 | SALES
 ALLEN  | 1600 | SALES
 BLAKE  | 2850 | SALES
 MARTIN | 1250 | SALES
 JAMES  |  950 | SALES
(14 行记录)

(4)通过视图执行DML操作,例如:给10号部门员工涨100块钱工资。

scott=# update view1 set sal=sal+100;

# 并不是所有的视图都可以执行DML操作。在视图定义时含义以下内容,视图则不能执行DML操作:
# 1.  查询子句中包含distinct和组函数
# 2.  查询语句中包含group by子句和order by子句
# 3.  查询语句中包含union 、union all等集合运算符
# 4.  where子句中包含相关子查询
# 5.  from子句中包含多个表
# 6.  如果视图中有计算列,则不能执行update操作
# 7.  如果基表中有某个具有非空约束的列未出现在视图定义中,则不能做insert操作

(5)创建视图时使用WITH CHECK OPTION约束 。

scott=# create or replace view view3
as
select * from emp where sal<1000
with check option;

# WITH CHECK OPTION表示对视图所做的DML操作,不能违反视图的WHERE条件的限制。

(6)在view3上执行update操作。

scott=# update view3 set sal=2000;

# 此时将出现下面的错误信息:
# ERROR:  新行违反了视图"view3"的检查选项
# DETAIL:  失败, 行包含(7369, SMITH, CLERK, 7902, 1980/12/17, 2000, null, 20).

这两年企业上移动ERP,很多时候不是“想升级”,而是被现实推着走:人在外面跑业务,单据在电脑里卡着;仓库要扫码盘点,结果还在纸上写;老板想看数据,最后只能等人导表。

所以移动ERP系统这件事,本质上比的不是功能堆得多不多,而是谁能把高频动作放到手机上跑通。

本文排行榜怎么排的

1、我用的标准很直白,按“能不能真的用起来”来排:

2、移动端是否能覆盖审批、开单、库存、对账等高频动作

3、产品与厂商信息是否能在官网/官方应用商店核验

4、是否有清晰的定位:更适合哪类企业、哪类业务模式

5、落地成本是否可控:上线路径清晰,推广阻力别太大

一、移动ERP系统排行榜 TOP 5

1、支道

支道更像“把业务系统当积木搭”的路线,不是那种固定菜单的传统ERP。

它最打动人的点是:业务流程变了,系统也能跟着你改,不用每次都等开发排期。

支道更适合哪类企业?一句话概括就是:流程不太标准、变化很快、跨部门协同靠人盯的团队。你不用一上来就“全上ERP”,更现实的做法是先跑通1-2条关键流程,然后逐步扩。

支道常见落地方式可以按这种节奏走:

(1)先做移动端待办与审批,把“卡在路上”的事打通

(2)再把业务填报和单据录入搬到手机上,现场就能闭环

(3)最后用报表与看板把数据收口,减少重复统计

如果你最痛的是“Excel满天飞、版本对不上、事情靠催”,支道的思路通常更贴近现实:先把流程固化,再谈精细化管理。

2、金蝶

金蝶移动端的卖点写得很实在,官网直接列出一串高频动作:扫码开单、蓝牙打印、出入库、盘点调拨、库存分析等。

如果你是“手机要能开单、仓库要能快速做动作”,金蝶这类路线通常更稳。

适合场景也很清晰:

(1)业务员:手机下单、跟进客户、交易管理

(2)仓库:出入库、盘点、调拨

(3)管理者:业绩、库存、经营数据随时看

3、用友

用友在移动端的主张也很明确:一个App管理所有应用系统,一键访问业务系统单据,移动快捷审批,实时处理业务。

你们系统多、待办多、审批多,用友这类“统一入口”的价值就会更明显。

更适合的企业画像:

(1)组织层级较多,跨部门流程复杂

(2)需要把多个系统的待办统一到手机端处理

(3)希望移动端是入口,而不是“另一个孤岛”

4、鼎捷

鼎捷在制造业中小企业的定位很明确,它在“掌上易助”页面直接写:易助小程序,全面满足ERP用户移动化需求,并说明易助是面向中小微企业、涵盖制造全流程的ERP。

小程序入口的好处很现实:推广阻力小,一线人员更愿意用。

如果你是机械、五金、汽配、电子加工这类行业,鼎捷官方也明确写到易助ERP适用这些制造业场景,并涵盖财务、进销存、生产等管理范畴。

5、网上管家婆

网上管家婆移动端讲的是“手机开单、扫码出入库、欠款对账、数据看板”这种中小企业最常用的动作。手机开单、查询欠款、一键生成对账单并发送链接或二维码对账,扫码出入库与多方式盘点。

如果你是商贸批零、电商网店,想要的是上手快、动作快,这类产品往往更省事。

二、5款产品对比表

三、最快的选型方法

1、你们移动端最常干的三件事是什么

(1)审批、开单、盘点

(2)对账、收款、查库存

(3)项目回填、工单处理

2、你们流程到底变不变

(1)经常变:优先看支道这种可配置能力强的路线

(2)基本不变:优先看标准化更成熟的套件

3、你们现有系统多不多

(1)多系统并存:用友这类统一入口更省心

(2)就一套进销存:金蝶、网上管家婆这类会更快落地

四、结语

移动ERP系统排行榜看一眼就好,真正决定成败的是:手机端能不能把你们最痛的那条流程跑通。如果你希望先把协同和流程跑顺、再逐步扩模块,支道放在第一位是合理的选择。

Sulaiman Ghori 在一期播客中,用了一个多小时详细讲述了他在 xAI 的经历。他说,在那里“从来没有人对我说不”,每个人都被充分信任去做正确的事;只要是好想法,当天就能落地、当天就能得到反馈。他还提到,马斯克愿意被证明是错的,只要你能拿出实验数据。

 

他也坦言,在上一家公司,很多事情也许他一个人能做得更快;但在 xAI,整体反而更快,因为几乎没有官僚流程。这些话,听起来都是对公司的认同和马斯克的赞扬,实际上他还说自己是马斯克粉丝。

 

然后,播客发出来后第 3 天,他被解雇了。

 

外界猜测是因为他说了太多敏感信息。节目中,他透露了利用闲置特斯拉汽车驱动的人类模拟器 AI 代理的计划、还有马斯克如何快速构建 Colossus 超级集群、xAI 在模型策略上的核心决策,曝光了公司内部部署测试的 AI 虚拟员工等,还有 xAI 也被完全曝光。他坦率地谈到了激进的时间表、马斯克亲自参与的 Cyber​​truck 奖金计划、内部文化和运营方式以及一些非公开的策略,这些言论引发了外界的强烈反响。

经历被玩梗:如何在 1 小时内毁掉你的一生,对应了最近 x 的爆文“如何在 1 小时内修复你的一生”

 

Sulaiman 自 2019 年起持续创业。在德国上大学一个月后退学,为了实现童年创办航天公司的梦想,在自家后院亲手制造过一台液体燃料火箭发动机。创业失败后,他进入 xAI。对于他的经历,有网友表示,“这位兄弟跑去上播客,没拿到明确授权,就顺手把一堆内部敏感信息抖出来,这就是纯纯的新手行为。可以说,这是职业生涯级别的大忌。任何一家严肃的公司都会立刻把你原地开除,更别说是像马斯克这样的人。”

 

我们翻译并整理了他这期“超级爆料”的播客对话,并在不改变原意基础上进行了删减,以飨读者。

 

在 xAI,事情永远是“昨天就该完成”

 

主持人:今天我很高兴能和 Sulaiman Ghori 坐下来聊聊,他是 xAI 的一名工程师。我从 2023 年马斯克刚开始搞 xAI 的时候就一直很关注这家公司,感觉它可能是史上增长最快的公司之一。你能不能跟大家讲讲,现在 xAI 到底在发生什么?

 

Sulaiman:说实话,我们几乎没有所谓的 deadline,永远都是“昨天就该完成”。基本没有什么人为障碍。马斯克一直强调要“追根溯源”,找到最底层、最根本的东西,不管是物理层面的还是其他的。我们通常会非常快地深入到那个层面,能多快就多快。

 

这在软件行业其实挺有意思的,因为你平时不太会把硬件这件事放在心上,但我们确实花了很多精力去考虑这些。而且严格来说,我们现在也不完全算是一家纯软件公司了,毕竟基础设施的建设占了很大一部分。

 

主持人:对,现在明显是被硬件限制住的。

 

Sulaiman:没错。硬件可能是我们最大的优势之一,因为在部署能力上,几乎没有其他公司能接近我们。不过,软件方面的人才密度也高得惊人,我从来没在任何地方见过这样的团队。

 

主持人:我觉得马斯克有一点特别厉害:他很擅长提前判断未来几个月、甚至几年后会出现什么瓶颈,然后从那个未来的瓶颈反推,确保自己现在就站在一个很好的位置上。这种思维方式在日常工作中是怎么影响普通工程师、AI 开发者的?

 

Sulaiman:通常我们一旦要快速启动一个新项目,不管是我们还是他自己,都会先定一个指标。这个指标一般都非常核心,要么直接关系到财务回报,要么关系到硬件层面的产出,有时候两者都有。之后,所有事情都会围绕着这个指标来推进。而且我们不太接受那种“这事本来就不可能”的说法,就算真有极限,那也必须是一个扎根在最底层的、本质性的限制,而不是人为的。

 

软件行业里,尤其是过去十年做 Web 开发的人,往往会默认、接受很多所谓的限制,比如速度、延迟之类的。但实际上这些限制很多都是假的。技术栈里有大量没必要的开销和“蠢东西”,如果你能把这些清掉,很多系统都能直接提升 2 到 8 倍,至少是那些相对比较新的东西。当然,也有些老东西确实不好动。

 

主持人:你最近一次真正感受到“传统认知被彻底打碎”的经历是什么?

 

Sulaiman:最近一次就是我们在 Macrohood 上做模型迭代。我们同时在做几种全新的架构,而且是并行推进的。现在我们几乎每天都会出新版本,有时候一天不止一次,有些甚至是从预训练阶段就开始重新来。这在业内其实非常少见。

 

这背后有几个原因:第一,我们有一支非常强的超算团队,他们解决了很多训练过程中常见的障碍。即便我们的硬件环境变化很大,但通常一个机架搭好后,一天之内就能开始训练,有时候甚至几个小时就可以。

 

主持人:这真的很不正常,一般不是都要好几天吗?

 

Sulaiman:甚至好几周。过去十年里,大多数人都是把这些事情抽象掉,交给 Amazon、Google 去管,他们给你多少算力你就用多少。但在 AI 时代,这种方式是行不通的。要么你死掉,要么你自己把这些东西建出来。

 

入职初体验:没人管,做模型和产品默认资源到位

 

主持人:当初为什么加入 xAI,以及前几周入职体验怎样?

 

Sulaiman:我当时刚搬到湾区,在做自己的创业项目。那段时间,xAI 的联合创始人之一 Greg Yang 主动联系了我。他真的很会招人。

 

我一开始收到邮件的时候还以为是垃圾邮件,因为那时候我经常收到那种“嘿,想聊聊吗”“我很欣赏你做的事情”之类的邮件。正准备删掉的时候,看到发件人的域名是 xAI,我一下反应过来:等等,这不是那帮人吗?当时他们大概成立了八个月左右,我就答应先聊聊。我们聊了好几次,我本来还想再试试别的机会,但后来发现时机不太对。

 

那个项目最后也没做下去,原因很明显:用一百万美元是不可能把 Macrohard 这种东西做出来的,但想法本身是对的。接下来六七个月,我基本是在烧钱,做各种航天相关的小项目,还试过一个“空气空间”相关的概念,后来也发现大概率行不通,但至少试过了。于是,我又给 Greg 发邮件,说能不能再聊聊。他直接回我:要不要明天面试?我说“好”。

 

面试还算顺利,我周一就搬家,直接入职了。第一天真的没人管我,就给了我一台电脑和工牌。我当时想:那现在怎么办?我去找 Greg,说我连团队都没有,也没人告诉我该干嘛。他当初招我进来,更多是因为他认可我之前做的事情,也觉得和 Macrohard 的长期方向相关,但那时候 Macrohood 甚至还算不上一个正式项目。

 

后来正好 Ask Grok 要启动,做和 X 的集成,他们问我能不能帮忙,我说当然可以。第一周我基本就是和另外一个人一起干活。但我很快意识到,在 xAI,你坐在工位上,甚至站起来一看,就能指着某个东西说:哦,这是那个人做的。这种感觉非常酷。而且我连固定工位都没有,就坐在当天没来的人桌子旁。

 

主持人:那时候公司里人其实也不多吧?

 

Sulaiman:对,大概也就几百人,工程团队一百来号人。基础设施团队具体多少人我也说不太清,因为有些人是从其他团队慢慢转到我们正式编制里的。但整体规模确实比其他实验室小个数量级。当时我们刚做完 Grok 3。

 

主持人:真的很酷。我特别喜欢的一点是,xAI 从成立到现在的速度实在太夸张了。我记得马斯克一开始还说,不确定在别人已经领先好几年的情况下能不能成功。结果你们第一个 Colossus 数据中心 122 天就建完了,这在行业里几乎是不可想象的。这种速度塑造了一种怎样的文化?

 

Sulaiman:他让我们在做模型和产品的时候,可以默认资源是到位的。事实也确实如此,我们并没有被资源严重卡住。

 

当然,我们还是会把资源用到极限,但那是因为同时在推进二三十个、甚至更多事情。有大量训练任务并行跑着,通常是由少数几个人在推动。这也是为什么我们在模型和产品迭代上能这么快。而且这种速度让我们可以更长期地去思考。比如 Grok 4、Grok 5,其实在我加入之前、甚至 Grok 3 落地之前,规模和预期就已经设计好了。

 

主持人:也就是说,至少提前一年在规划?

 

Sulaiman:对,而且你能感觉到,这些预期大概率是能实现的,因为团队整体非常可靠。这就极大地解放了你的思维,让你不用老是纠结“我会不会做不到”。举个例子,我们之前假设的最低延迟,其实比真正需要的高了大概三倍,而基础设施的建设让我们可以做到这一点。

 

主持人:这是什么意思?

 

Sulaiman:我们在做的一种新架构,如果没有足够高的实验频率,基本是不可能推进的,因为它完全不建立在现有研究基础之上。你需要全新的预训练体系,也需要新的数据集。这本身并不完全受制于硬件资源,虽然也有一些因素,比如 Tesla 计算平台的问题。这个其实已经是公开的了。

 

我们现在在想一件事:如果我们用 Macrohard 去做“人类模拟器”,那要怎么部署?如果要部署一百万个“人类模拟器”,就需要一百万台计算机,这怎么可能?

 

结果两天后答案就出现了:Tesla 车载计算机。它的资本效率非常高,我们可以在上面跑模型,甚至跑一个完整的人类工作环境,成本比在 AWS、Oracle 的虚拟机上,甚至直接买 Nvidia 硬件都要低得多。这让我们可以假设:我们能以更快的速度、在更大的规模上部署。所以我们也相应调整了预期。

 

主持人:也就是说,你们基本上可以直接利用汽车网络?

 

Sulaiman:所以这其实是一种潜在的解决方案。简单来说,我们想要一百万个虚拟人(VMs)。仅在北美,就已经有大约 400 万辆特斯拉汽车。假设其中有三分之二,或者哪怕一半,已经配备了 Hardware 4。而且在 78% 到 80% 的时间里,这些车基本都是停在那里,要么闲置、要么在充电。那我们完全可以付费,让车主把车的算力时间“租”给我们。车本身已经有网络、有散热、有电力。我们可以直接在车上运行一个“人类模拟器”,也就是 Digital Optimus。这样一来,车主的租赁费用能被覆盖,我们这边则得到一个可以投入工作的完整人类模拟器。整个过程几乎不需要额外的基础设施建设,基本就是一个纯软件层面的方案。

 

主持人:对,这个资产本来就放在那里,你们只是把它用起来了,太厉害了。那从宏观层面看,这种“人类模拟器”规模化到几百万个,它的目的是什么?

 

Sulaiman:其实核心概念非常简单。Optimus 就是把人类能做的任何物理任务,让机器人自动完成,成本更低,而且可以 24×7 全天候运行。

 

我们现在做的,是把这个逻辑复制到“数字世界”。凡是人类需要通过键盘、鼠标、看屏幕、做决策来完成的数字化工作,我们都可以直接去模拟人类的操作过程。完全不需要软件方做任何适配,也不需要改系统。只要现在有一个岗位是人类在用电脑做的,我们理论上都可以直接部署。

 

主持人:挺有意思的。那具体会怎么推进、怎么落地呢?

 

Sulaiman:我们还没公开详细的落地计划,整体来说会是先慢后快。对我们来说在于,要么基础设施已经建好了,要么我们可以直接用特斯拉的网络,或者自己扩数据中心、测试算力。实际上,从一千个“人类模拟器”扩展到一百万个,差别对我们来说并没有想象中那么大,这反而不是最难的部分。

 

马斯克一个电话“救火”,个人“生死自负”

 

主持人:马斯克最擅长的一件事,就是在公司里不断“救火”,哪里有问题就冲到哪里把问题解决掉。你有没有见过那种,本来是个大问题,但被他非常快地解决掉的情况?

 

Sulaiman:有,最典型的就是基础设施建设,这是最大的一个。模型这边也有过一些小波折,但整体还算顺利。在模型侧,因为涉及很多非常底层、非常具体的算子,每一代 ASIC、CPU 都是为特定操作优化的,当我们引入新硬件,比如从 Nvidia 或其他厂商拿到新产品时,往往不是所有东西都能直接跑起来。

 

去年年初有几次内部会议,他听到这些问题之后直接打了一个电话,第二天软件团队就给我们交付了补丁。我们几乎是并肩作战,直到问题解决,然后就能很快在新硬件上跑模型或训练任务,否则这种来回沟通可能要拖上好几周。

 

所以很多这种“卡点”,真的就是一个电话就解决了。要么是我们主动提出来,要么他自己会问。经常在会议快结束、或者讨论暂时停顿的时候,他会突然来一句:“我能怎么帮忙?怎么能把这件事再加快一点?”然后就有人把问题抛出来。

 

主持人:我知道你们在并行做很多不同的产品,这在一定程度上是必须的。但在大多数组织里,同时推进多个目标,其实很难保持专注。你们是怎么做到多线并行还能高效执行的?

 

Sulaiman:说实话,很多时候,是在全员会议或者大家私下聊天时,我们才真正搞清楚每个人在做什么、各个项目进展到哪一步。

 

比如,我们当时做语音模型和语音部署,其实很多极低延迟的端到端能力早就已经在系统里了,从数据包发到客户端那一整套链路都准备好了。后来只是把正确的开关打开、解决一些冲突,延迟就直接降了两三倍。

 

这种情况非常常见:在软件或硬件某个角落里,存在一个“很蠢”的问题,而恰好已经有人想好了方案。你可能是在翻代码库的时候发现,或者随口问一句,有人就会说:“哦,这个 XYZ 已经搞定了,你去找他就行。”基本不需要花太多时间对齐、同步、请示。提出一个想法,反馈要么是“这想法不行”,要么是“那为什么还没做完?”然后你就直接去做,事情就这么推进了。

 

主持人:在马斯克的公司里,好像你只要主动要责任,就得“生死自负”。事情做成了就担负更多责任,做不成可能就出局。你的体验是这样吗?

 

Sulaiman:是的,基本就是这样。我参与过很多不同的项目,大多只是因为有人找我帮忙,我就一直帮下去。结果到最后,我就成了某个模块、甚至一大块系统的负责人。

 

对所有人来说都是这样。如果你在某个领域有经验,或者能非常快地推进事情,几天之内,这个组件就归你负责了。从“正式流程”上看其实挺混乱的。我在 HR 系统里可能还是挂在 voice 和 iOS 名下,安全系统甚至还以为我在做 X 的集成,从来没人更新这些信息。

 

主持人:也就是说,你进公司时并没有一个非常清晰的工作方向,就是先开始干活,然后不断在不同项目之间流动,谁需要你你就去哪?

 

Sulaiman:差不多是这样,会有很多重叠和流动。入职之后,我通常同时参与两三个项目,哪个最紧急、或者我能帮上最多忙,就会占用我大部分时间。然后项目之间会像瀑布一样自然切换。

 

主持人:那从入职到现在,你大概都做过哪些项目?

 

Sulaiman:一开始我做的是 Ask Grok 以及相关集成,也和后端团队一起处理过可靠性和扩展性问题,当时系统规模增长得很快;之后我独立承担了桌面端套件的开发,把它做到内部可用的完整状;接着又被拉去帮做 Imagine 的发布,以及 iOS 相关工作。说真的,iOS 团队小得离谱,和用户规模完全不匹配,你绝对猜不到有多少人。

 

主持人:五个?

 

Sulaiman:三个。当时推出时,我正好是第三个。但大家都非常强。这是我第一次感觉到,自己必须拼命跑才能跟上整体的节奏和人才密度。

 

主持人:那你第一次真正感觉到“自己被充分使用”的时刻是什么?

 

Sulaiman:肯定是 Imagine 的那次发布。我们基本是 24 小时一个迭代周期:晚上收到反馈,当晚就改;第二天早上再看新一轮反馈,接着马上修 bug、加大家想要的新功能。模型这边有新变化,我们也立刻跟进。整个节奏非常快,那可能是我连续每天都在办公室待着时间最长的一段时期。

 

主持人:那段时间持续了多久?

 

Sulaiman:大概两三个月。那段时间几乎没有周末,但我反而挺开心的,也算验证了自己能扛住这种强度。之后我就被调去做 Macrohard 产品了,当时那边只有另一个人,一开始就我们俩。我从项目启动一直做到现在。

 

疯狂推进度,马斯克直接送 Cybertruck

 

主持人:关于 Colossus 的建设,我不知道你了解多少。早期 xAI 团队为了把 Colossus 跑起来,在供电、算力、各种基础条件上都做了很多“疯狂”的事。到现在,其实还是到处是瓶颈,总觉得还需要更多芯片、更多 GPU、更快的速度。你当时的感受是什么?

 

Sulaiman:这一路上有太多“战争故事”,也下过不少赌注。

 

主持人:挑几个讲讲吧。

 

Sulaiman:好。我记得 Tyler 当时和马斯克打了个赌。我们在上新机柜的时候,具体是哪一代 GPU 我都忘了。马斯克说,“如果你能在 24 小时内用这些 CPU 跑起来一次训练,我今晚就送你一辆 Cybertruck。”结果那天晚上我们真的把训练跑起来了。

 

主持人:他拿到了吗?

 

Sulaiman:拿到了。现在从我们午餐的窗户望去就能看到那辆车,马斯克人挺酷的。

 

说到供电,其实我们必须和市政、电力公司还有州一级的电力机构高度协同。因为当他们那边负载飙升时,我们就得立刻切断公共电网,全部切到自备电源上——大概是八十台,甚至可能更多,用卡车拉来的移动发电机。

 

整个切换过程必须无缝完成,不能影响任何正在跑的训练任务。你要知道,那些训练极其不稳定,GPU 和硬件的功耗可以在毫秒级别上下波动,动辄就是几兆瓦。这件事本身就非常夸张。

 

主持人:那是不是也是为什么你们会把巨型电池组直接放在数据中心旁边?这样负载上下波动就能更快响应?

 

Sulaiman:对。没有电池的话,很难这么快地调整负载,发电机毕竟是物理设备,你是在让一个真实旋转的东西加速或减速,它天然就有时间延迟,电池的反应速度要快得多。从物理层面看,整个链路是:本地电容、数据大厅侧的电容、电池、发电机,最后才是公共电网。当然,这套架构我们现在可能也在不断调整,尤其是散热这块,反应速度必须非常快。

 

主持人:你还有没有那种“本来不可能,但最后居然成了”的故事?

 

Sulaiman:有。比如我们这块地的租约,从法律意义上讲其实是临时的。这样做是为了最快通过审批、尽快开工。我猜以后会转成永久的,但现在确实是短期租约。对数据中心来说,这是目前能把事情推进得最快的方式。

 

主持人:他们是怎么允许这种操作的?

 

Sulaiman:算是一种地方和州政府层面的特殊豁免。你只是“临时”改造这块土地,类似嘉年华那种用途。

 

主持人:所以 xAI 本质上就是个要来的“嘉年华”?

 

Sulaiman:差不多就是这个意思(笑)。但正因为这样,事情推进得特别快。内部规划加建设,全程不到一个月就搞定了。

 

主持人:规模接下来肯定会继续疯狂扩张。马斯克 也说过,能源会是最大的瓶颈,其次才是芯片。在这种很难预测未来一到两年项目和资源需求的情况下,你们是怎么做规划的?

 

Sulaiman:我们会尽量从“杠杆率最高的目标”倒推。先想清楚:在某个时间点之前,我们最值得做的事情是什么。比如,如果我们想在某个日期前做到一千万甚至一亿美元收入,那从经济和系统设计角度,最有效的事情是什么?然后再倒推:需要什么软件、什么物理基础设施,最后一步步拆解。所以我们几乎不会从“硬件需求”开始,那通常是最后才考虑的。

 

主持人:那是不是也有一套类似 SpaceX 的“让事情发生”的算法?

 

Sulaiman:你是说那种“先删掉,再加回来”的逻辑?那确实一直都在用。我们经常先把某个东西砍掉,等确认必须要的时候再加回来。

 

主持人:你最近一次这么干是什么时候?

 

Sulaiman:今天(指录制当天)。Macrohard 上部署大量变化极快的物理硬件,让测试变得很难,所以我们尽量减少下游的“特殊情况”。比如,我们要让三十年前的老显示器到最新的 5K Apple 显示器,全都跑在同一套技术栈上,结果发现并不是所有系统在任何时候都能愉快地配合。比如视频编码器,在某些层级上就得反复调。

 

我之前不知道,后来才发现,有些编码器对“最大像素数”是有硬上限的。所以我们一开始删掉了多编码器的特殊分支,后来在 5K 分辨率上撞墙了,又不得不把这个特殊逻辑加回来。

 

“优秀的人太多了,反而变得很难判断”

 

主持人:在你看来,xAI 本身有哪些特别值得讲的地方?

 

Sulaiman:首先是人,这里的角色非常多样;其次是我们的招聘方式也挺“怪”的。有些我原本觉得很蠢的做法,结果发现居然行得通,那我们就直接试。比如搞 hackathon,如果能从五百个人里挑出五个顶级选手,这件事就非常划算。他们未来给公司带来的预期价值,远远高于这次活动的成本。

 

我们前几天还算了一笔账,现在主仓库里,每一次 commit 的“价值”大概是 250 万美元。我今天提交了五次。

 

主持人:那你今天直接加了差不多一千两百万美元?

 

Sulaiman:轻轻松松的一天(笑)。确实不错,杠杆效应非常强。你用更少的努力和时间就能做更多事,因为身边的人和内部工具都很棒。还有我的老板。

 

主持人:那什么样的人会想来这里工作?我听你描述,感觉第一天来的人就已经准备好周末、熬夜、全天候投入了。

 

Sulaiman:大家刚来的时候都非常兴奋,非常有热情。

 

主持人:使命感驱动?

 

Sulaiman:是的,但野心的类型不一样。有些人想往管理层走,看有多少人向自己汇报;也有人想“拥有”一大块技术栈。比如现在,我们在重构核心生产 API,基本上是一个人+20 个 Agent 在做,而且做得非常好。你完全可以独立拥有代码库中的很大部分。

 

主持人:有点像 X 被收购之后那样,人很少,但每个人负责的范围巨大。

 

Sulaiman:没错。

 

主持人:除了 hackathon,你们在招聘上还有什么不太常规的做法?

 

Sulaiman:我们在 Macrohard 上推得非常猛。有两、三周的时间,我每周面试 20 多个人。有的只聊十五分钟,有的就是一整小时的技术面。优秀的人太多了,反而变得很难判断。

 

主持人:那你怎么判断?

 

Sulaiman:我有一道自己解决过的、非常具体的问题,是几年前在创业时遇到的一个计算机视觉问题。我会给候选人半小时去实现解决方案。

 

这个问题本身其实很简单,但“简单得很有欺骗性”,大多数人都会想复杂。我特别看重一点:你能否不过度思考,给出一个朴素但有效的方案。因为我们的系统要跑在跨三、四十年的各种硬件、操作系统上,如果不保持简单,下周代码量就能膨胀到一千万行。

 

主持人:你还会看重哪些杠杆能力?

 

Sulaiman:我喜欢会质疑需求、也会质疑我的人。这个方法我从 Chester Ford 那里学来的。

他在招聘时,常常会故意在题目里塞一个错误的需求、不可能的条件,期待候选人指出来。如果对方没发现,他就不招。我现在也这么干,效果非常好。

 

主持人:你们的节奏真的快到离谱。你自己也在做很多不同的事情,面对新任务时,怎么最快上手?

 

Sulaiman:要看具体是什么。如果是代码多,那就老老实实读代码,反复跳转定义,很快就能摸清楚。很多时候,实现代码比想象的要少。只有在高度活跃开发的模块里,才会同时存在二十个版本,你根本不知道哪个是主线,这时候就只能去问人。

 

让我惊喜的是,这里的人都非常开放、友好。我原本以为大家会很聪明、也很傲慢,但事实是:大家都很聪明,而且非常乐于帮忙。

 

我们不怎么写文档,因为写文档的速度跟不上开发速度(笑)。现在我们也在尝试用 AI 自动生成文档。好处是,我们有几乎无限的算力和很聪明的 AI,可以大胆试各种“蠢办法”。在别的创业公司,这可能要烧掉几十万、上百万美元,但我们几乎是零成本。结果就是:实验更多、失败更多,但成功也更多。

 

马斯克极限压缩时间,“办法总会有的”

 

主持人:在实验这件事上,你们是怎么最大化“尝试次数”的?

 

Sulaiman:通常都会有时间限制。我们经常在模型侧同时跑两、三个实验。有时候不是因为时间紧,而是因为两周后某个前置条件才会就绪:可能是硬件,也可能是数据。但今天你必须上线一个东西,那就先跑几种方案,看哪个今天就能交付、能产生收入或客户效果,两周后条件成熟了再切换。这种做法在 Macrohard 里是常态。

 

主持人:你有没有遇到过这种情况:按理说一个项目的周期应该拉得很长,但你们却压缩后提前了好几周甚至几个月完成?这种事经常发生吗?

 

Sulaiman:每次都是这样,无论是跟马斯克的会议,还是内部讨论,只要有人强力推动一件事,或者有外部的人——哪怕他并不对这件事负责——提出了新的需求、要求你把某件事做出来。我们一开始都会觉得,这个时间要求太离谱了。通常会花两分钟想一想、抱怨几句,然后剩下的时间就全部用来想:怎么在这个时间内把事情做完。

 

说到底,对完成时间的预估,永远建立在一堆假设之上。一旦时间被压到原来的二分之一、甚至十分之一,你就会回头看这些假设并问自己:这些假设对时间的影响到底有多大?然后你要么把它们砍掉,要么调整掉。这样一来,时间线立刻就能快一倍。你多做几次这样的优化,基本上任何要求都能满足。当然,最终还是会撞上物理极限,但一开始的时候,你离那个极限其实远得很。

 

主持人:我知道像完全自动驾驶、SpaceX 的火箭也是类似的情况。马斯克给的时间线通常都比实际要长得多,所谓的 “马斯克时间” 可能只有真实周期的四分之一或者一半。但正因为一开始把时间线定得这么激进,事情反而真的快了好几倍。xAI 这边是不是也差不多?虽然现在更多是软件,但哪怕在数据中心这类硬件侧,感觉进展也快得离谱,而且基本都落在他最初说的那个时间范围内。

 

Sulaiman:我觉得他自己也在不断校准他的时间判断。毕竟现在马斯克已经在大规模部署各种各样的硬件了,所以他的估算明显比以前准很多。而且他更新时间线的频率也更高了,有时候甚至每天都在变。他会跟我们不断沟通,根据不同的参数来调整进度。

 

有些变化甚至是他那边直接带来的,尤其是在基础设施层面。比如某个交易提前敲定了,或者某批设备可以提前排进生产,那就可能直接省下一个月、两个月,甚至更多,具体要看部署的情况。软件这边其实也是一样。

 

他一直说的一句话是:你完全可以试着用一个月去做一件原本要一年才能做完的事,最后你可能两个月就搞定了,但那也已经快得多了。

 

主持人:我记得在 SpaceX 的早期,有一种内部共识:马斯克说每拖延一天,就相当于损失一千万美元的收入。我不知道在 xAI 是什么感觉,你心里会不会也有一种直觉:如果今天没有再 push 一点、没有把事情往前拱一步,就等于损失了多少本可以创造的价值?

 

Sulaiman:有的。至少在 Macrohard 这个项目上,我们确实有一些非常明确的收入目标。具体数字我不能说,但在我脑子里,只要一件事被延迟或者被加速,我几乎立刻就能算出来:我们刚刚是多赚了多少钱,或者少赚了多少钱。

 

主持人:这也太夸张了。

 

Sulaiman:是的,数字会非常大。一方面是因为预期回报本身就极高,另一方面是时间线实在太短了。所以哪怕只是几天的变化,按比例来看,对收入的影响都已经非常可观了。

 

主持人:马斯克一直以“快速下重注”闻名。有没有那种在一次会议里,就做出了投入巨大资本、时间或者承诺的决定?

 

Sulaiman:有一个非常典型的决定,就是在 Macrohard 上,我们选择了一条路线:模型的速度至少要比人类快 1.5 倍,而现在看起来,实际速度远远不止如此。

 

在其他实验室,类似“人类模拟器”的尝试,更多是走“更强推理能力、更大的模型”这条路。但我们当时的这个决定,几乎是完全走在了和所有人相反的方向上。之后我们做的几乎所有事情,基本都是这个决定的下游结果。虽然不能说百分之百,但它影响了绝大多数事情,而且这个决定是在非常早期就定下来的。

 

这在某种程度上也是一种共识,尤其是类比完全自动驾驶就很容易理解。没有人会等电脑花十分钟去做一件自己五分钟就能做完的事。但如果电脑十秒就能搞定,那我愿意为此付出任何价格。这其实是个非常直观的判断。

 

正常情况下,我们这些工程师可能会站出来反对,有二十个理由说明事情不能这么做。但当一个决定已经被拍板了,你只能从结果倒推路径,办法总会有的。

 

没有 AI 研究员, 就是工程师

 

主持人:我记得马斯克之前说过一次,好像是在 YC 的活动上,他和 Gary Tan 做问答。Gary 提到 AI 研究员这件事,结果马斯克说不存在什么 AI 研究员了,现在全都是 AI 工程师。

 

Sulaiman:对,我们跟他开过一次关于招聘的会,也有人提到过类似的话题,比如岗位描述之类的。然后他大概讲了十分钟,核心就一句话:工程师,就是工程师,别的都不重要。只要是好工程师,本质上是个会解决问题的人就行。不管你以前是做哪一块的,用过什么架构、做过哪种基础设施,这些都不重要。

 

主持人:为什么“工程师”这么重要?

 

Sulaiman:因为这样边界就被拉得很宽。意味着我们可以从很多不同背景的人里招人,现实中也确实是这样。AI 领域可能还不算特别明显,但 SpaceX 有很多这样的故事:有人来自你完全想不到的背景,按传统眼光根本不可能进来,但最后却在工程上做成了非常大的事情。所以定义宽一点,就等于给这些人留了一条路,也能帮助我们整体跑得更快。

 

“没人指挥你干这个、干那个”

 

主持人:那对你个人来说,在那工作最有意思的地方是什么?

 

Sulaiman:没人管我。真的,没人指挥你干这个、干那个。如果我有个好想法,通常当天就能自己动手把它做出来,然后拿去展示。看看合不合理,跑个评估,或者直接给客户看,给马斯克看,给相关的人看,一般当天就能知道这个方向对不对。

 

没有冗长的讨论,也不用等各种流程和官僚审批,我特别喜欢这一点。说实话,我从非常小的创业公司来更大的公司,本以为会牺牲一些自由度。我加入时公司 100 人,是我之前公司的 10 倍。但对马斯克的公司来说算小的,确实感觉很小的公司,没有什么繁文缛节。

 

主持人:你进去之前,有没有什么特别大的预期,结果后来发现完全不是那么回事的?

 

Sulaiman:我原来以为会更“自上而下”一些,结果发现有一些,但不多。管理层级非常少,基本就三层:最底下是 IC,中间是联合创始人和一些新晋的经理,再往上就是马斯克,没有了。

 

现在每个经理下面的人都很多,事情反而很少是自上而下推动的。通常是我们自己先想出解决方案,跟经理对一下,马斯克点头,就直接干了。有反馈就再调整。整体比我想象中要“自下而上”得多。

 

主持人:感觉就是在刻意设计一种状态,让所有人都在做东西,管理者更少,真正的“建造者”更多。

 

Sulaiman:对。我刚加入的时候,几乎所有经理都还在写代码。现在有些人下面管着上百号人,写得少了一点,但总体上,大家还是工程师。

 

我记得第一周,有天吃晚饭,一个人坐我旁边。我就随口问他在哪个团队。他说他是做销售的,主要负责企业客户。我当时还想,“哦,原来是销售。”结果,他接着跟我讲他最近在训练的模型。

 

没错,销售也是工程师。销售团队全是工程师,几乎每个人都是工程师。那会儿公司里,可能真正不算工程师的人不到八个。即便如此,大家也都是在为同一台“机器”做贡献。

 

主持人:所以是不是更像这样:一个工程师负责一个项目,可以直接面对客户,理解他们的问题,然后快速实现解决方案?

 

Sulaiman:是的,而且层级越少,信息损失就越小。本质上是信息压缩的问题。语言本身就是有损的。如果信息要从客户脑子里变成语言,再进销售脑子,再变成语言、再到经理、再到工程师,每过一层,就像传话游戏一样丢一大截。如果你能尽量减少层级,那就只剩下一次压缩:客户直接告诉你他们要什么、体验是什么,然后工程师直接去解决。

 

主持人:有没有什么你以前在别的公司从没见过,但 xAI 在做的事情,能让事情推进得特别快?

 

Sulaiman:最让我意外的是团队之间、职责之间的“模糊性”。这在其他大公司,甚至规模差不多的公司里,都很少见。

 

比如我要修虚拟机基础设施的一个问题,我就直接修,修完给负责那块的人看一眼,对方说 OK,马上合并、上线。几乎没有那种严格的边界,大家基本都可以改任何东西。当然,危险的操作还是有检查的,但总体上,公司是信任你的,默认你会把事情做对。这种感觉真的很不一样。

 

主持人:我记得之前马斯克在搞 DOGE 的时候,删掉了一些防控措施然后又很快加回来了。在这种高速试错的过程中,有没有什么东西被删掉、又重新做回来的?

 

Sulaiman:几乎没有那种不可逆的破坏。我想不起来有什么东西是真的被永久性毁掉的。但像你说的,删掉、移除某个东西,然后有人说“我需要这个”,这种情况非常常见。可能一个小时后就回滚了。

 

也有那种情况,一个项目做了好几个月,依赖某块基础设施,结果等你真要上线的时候,那块基础设施已经被重构过三次了。那就再适配一次,继续往前走。

 

主持人:你觉得工程团队人这么少是件好事吗?

 

Sulaiman:绝对是。人越多,反而越慢。一个人能做完的事,两个人来做,往往要花两倍时间,这在任何规模下都成立。尤其是现在,你已经不需要像以前那样写那么多代码了,更多是在做决策、做架构设计。每个人都可以是架构师,不需要那么多“手”,一个大脑能做的事情多得多。

 

主持人:你之前自己也尝试过创业,做过很多不同的项目。是什么让你决定来这里?使命感也好,文化也好,哪一点真正打动了你?

 

Sulaiman:说实话,我一直是马斯克的粉丝。小时候第一次看到猎鹰火箭回收着陆,那种震撼真的忘不了。我后来还专门跑去看了 星舰的第五次发射,那次是第一次成功“接住”,真的值回票价,是我这辈子见过最酷的事情。所以只要能参与任何跟这些事情沾点边的东西,对我来说就已经非常有吸引力了。

 

主持人:那你当初为什么选择这家公司,而不是 SpaceX 或特斯拉?

 

Sulaiman:主要还是因为我骨子里就是个创业者吧。xAI 是这几家公司里规模最小、也最新的一家。我当时的一个判断,就是在这种体量的公司里,个人能产生的杠杆和改变会最大,事实也基本验证了这一点。因为从比例上看,你在公司里的“占比”更大。不是说其他公司不酷、或者个人不重要,而是这种比例带来的影响力不一样。

 

主持人:也就是说,对决策产生影响的可能性要大得多。

 

Sulaiman:甚至不只是决策,而是从想法到落地、到看到结果,速度都非常快。我之前以为很多事情自己单干会更快,比如自己做某个功能、跑某个实验。但现实是,在 xAI 反而更快,因为已经有现成的基础设施和团队,很多我本来要手动完成的步骤,他们早就做过了,而且基本没人会对你说“不”。

 

内部 AI 虚拟员工

 

主持人:你之前提到,公司里不同人、不同事情之间的边界其实挺模糊的。那你能不能随时去找其他同事帮忙?

 

Sulaiman:经常啊。基本就是走到别人桌前,直接说:“我有个问题。你现在在做什么?我能不能帮你一点?你能不能帮我这个?”大家都在同一栋楼里,这种事非常自然。

 

挺有意思的是,我们后来在公司内部测试“虚拟员工”(human emulator),有时候甚至没提前告诉大家,所以就会出现这种情况:有个真人员工在干活,突然有人找他说“你能不能帮我做这个”,虚拟员工就回:“行啊,来我工位吧。”结果那人真的走过去,发现什么都没有。

 

好几次我收到消息说:“组织架构里这个人向你汇报,他今天是不是没来?”但其实他是个 AI,是虚拟员工。

 

不过整体来说,大家默认都是在同一栋楼、随时能联系到的。所以互相求助这件事非常频繁。我可以找别人帮忙,别人也经常来找我。

 

主持人:那在这些过程中,最容易“翻车”或者最让你意外的点是什么?

 

Sulaiman:主要发生在“人类行为模拟”这块,尤其是和客户一起做的时候。我们会尽量全面地理解客户的工作内容:先聊天、访谈,让他们讲,或者写下来他们是怎么做这份工作的。再过一周,我们回头看虚拟员工犯的错误,发现它总是在某些特定场景出问题。

 

这时候我们就去观察真人是怎么做的,结果发现真实流程里其实有二、三十个步骤,对方之前完全没提。我们一问,他们就说:“哦对,这一步我们是这么做的,刚才忘了说,不好意思。”这种情况太常见了。

 

很多事情在人脑里是默认存在的,全靠“自动驾驶模式”在跑。就像你开车开了一小时,完全不记得自己刚才是怎么开的。人类对任何重复性的工作都是这样,而我们想解决的正是这些问题:把人类现在反复做、其实根本不需要人来做的“蠢活”,全部替掉。

 

主持人:那你是怎么决定“先解决哪一类问题”的?除了开车以外,人类还有哪些事情是天天在做、但其实没必要继续做的?

 

Sulaiman:只要是电脑上的重复性工作,基本都在这个范围内。比如客服就是一个特别典型的场景:不断接收各种格式、各种内容的用户输入,然后把它们转化成一个标准化的处理流程。这样人类就可以去做更有创造性、更需要大脑的事情。

和编程领域发生的变化几乎是完全平行的:以前你要把同样的实现写二十遍,现在你用三句话描述一下,它就帮你搞定了,这是一次巨大的“压缩”。我们做的,其实就是把这种“压缩”,应用到所有数字化工作流上。

 

主持人:在公司内部推这些“虚拟员工”的时候,除了“人不存在但被叫去工位”这种情况,还有什么让你觉得意外的吗?

 

Sulaiman:意外的一点是,它的泛化能力比我们预期的强很多。有很多测试案例,模型根本没针对这个任务训练过,但表现却非常完美,远远超出我们的预期。因此,可以很确定地说,泛化效果真的比想象中好,而且我们现在还处在非常早期的阶段,之后只会越来越强。

 

这点其实和完全自动驾驶很像:有些场景并不在训练数据里,但车就是能正确应对。这本质上是一个“权重效率”的问题。

 

马斯克给反馈,要么宏观、要么细节

 

主持人:你参加过几次和马斯克的会议?那种会议一般是什么样的?

 

Sulaiman:说实话都挺简单的,而且我运气不错,大多数都进行得很顺利。

 

主持人:在 SpaceX 这种地方,成本和零部件细节特别重要。但在你们这里,他给反馈时会不会不太一样?比如不会去抠每个流程的细节?

 

Sulaiman:他的反馈通常要么非常宏观,要么非常微观,很少停在中间。

 

宏观层面上,可能是产品方向、客户判断,比如“只专注这个细分市场”“这件事完全不要做”。微观层面,尤其是算力效率、延迟这些问题,他往往会给出非常具体的建议,比如“试试这个方案”。而且他是愿意被证明错的,但前提是要有证据,必须做实验、看结果,而不是靠观点对喷。有些实验的结果甚至会出乎所有人的意料,然后我们就顺着那个方向继续走。

 

主持人:所以你们后来选择小模型,而不是一味堆大模型。

 

Sulaiman:对,小模型在算力效率上的选择,带来了很多改进。有些是直接的,有些是间接的。最直观的当然是响应更快。但更重要的是,特斯拉在自动驾驶上也发现了同样的事:模型小了,迭代速度就快得多。

 

不仅模型对环境反应更快,部署新版本的速度也快了。以前可能四周一次,现在一周一次。这又反过来影响了实验方式:为什么我们能同时跑二十个实验,其实就是源于这个早期决策。

 

主持人:那一开始的设想,是不是想直接上大模型?

 

Sulaiman:算是吧。我们确实想比所有人都快,但后来发现,“快”这件事的效果,被放大了很多倍。

 

“war room”真实存在

 

主持人:维基百科一直被诟病有偏见,马斯克也很关注构建一个“更接近真实”的替代体系。那你们怎么看待清理互联网来找到真相这件事?

 

Sulaiman:这是个极其困难的问题,因为互联网本身往往并不是所谓的“事实真相”。我们能做的,是尽可能往“底层原理”去钻,但这本身也很难。比如你问“宪法在物理意义上的底层原理是什么”,这其实很难有人真正给出一个严谨的答案。

 

但思路是类似的:尽量往下挖,再从那里往上构建。问题是真正这样写、这样做的资料并不多。比较接近的一个例子,是 James Burke 的《Connections》系列,他会把看似完全不相关的概念,通过物理和发明串联起来,非常有意思。我们想做的,其实是类似的事情,只不过这条路还很新。

 

主持人:你们是怎么找到更好的数据的?

 

Sulaiman:数据并不是决定结果的唯一因素。

 

主持人:我有时候会在 X 上看到有人贴出 Grok 的输出,说“这明显不对”,然后马斯克直接回复说“我们会修”,接着可能过了十二个小时、一天,他又说“好了,已经修好了”。这种事情发生时,内部一般是怎么运作的?

 

Sulaiman:通常是他把哪里出问题了直接指给我们看,然后当时还醒着的人就会马上拉一个线程开始解决问题,一般先是个人处理,如果需要就再拉几个人。之后我们会做一次复盘,把到底哪里出了问题、以后怎么避免都讲清楚。原则上,犯一次错是可以接受的,但同样的错误犯第二次就很严重了。

 

主持人:在 SpaceX 的历史里,包括特斯拉,其实有过很多这种“冲刺时刻”。比如马斯克半夜突然出现,发一封全公司邮件,说大家都来公司干活。你们也有这种情况吗?

 

Sulaiman:这种更多发生在做大模型的时候。就 Macrohard 这个项目来说,我们已经在“作战室”里连续干了四个月了,基本一直就是这种状态。

 

主持人:你们门口是不是还真挂着一块牌子写着“war room”?

 

Sulaiman:是的,真的。最早那个作战室后来扩张了,我们就把东西全搬走了。有一次马斯克走进作战室,发现里面空无一人,就问“人呢?怎么回事?”然后他又走到我们现在待的地方,其实就是健身房,我们把健身器材全清掉,把人都塞进来了——然后他就在那儿开始一连串追问到底发生了什么。

 

主持人:在那种很多事情被打乱又被迅速推进的夜晚,或者经历那种大规模冲刺时,是什么感觉?

 

Sulaiman:我最近正好看到 xAI 的一位联合创始人 Igor 发的一条内容。他人特别好,我也很喜欢跟他一起工作。他以前在 StarCraft AI 工作,大概十年前吧,是我高中时尝试复现过的最酷的机器学习项目之一,难得要命,所以后来能和他一起共事真的挺神奇的。

 

他说的一句话我特别有共鸣:有些时间里,感觉只过去了几天;但有些夜晚里,仿佛发生了几个月的事情。那天晚上就是这样。说“几个月”可能有点夸张,技术结果我们本来也可能几周内做到,但一晚上把它搞出来,冲击感非常大,而且真的熬了一个通宵。

 

主持人:有没有那种情况,大家连续五天、甚至一整周都没怎么离开过办公室?

 

Sulaiman:有的。模型冲刺的时候,经常会有很多人直接在公司过夜。

 

主持人:之前提到你们有五、六个睡眠舱,大家轮着用?

 

Sulaiman:对,有睡眠舱,现在还有一些上下铺,条件差点,但至少能睡。后来帐篷那张照片传出来后,很多人都发给我。我只能说确实有帐篷,但我从没见过一次搭那么多。反正……确实挺极端的。

 

成长经历:从小不服权威

 

主持人:我知道你小时候做过很多不同的项目,好像还做过指尖陀螺。可能是在你房间里搞的?这种折腾、动手的心态,对你现在的工作影响大吗?

 

Sulaiman:影响挺大的。我很小就开始学编程,大概十一岁的时候,我爸给我买了一本书。我一开始觉得还行,但真正开始喜欢是在我意识到它能赚钱之后。我在网上认识了一些人,他们给游戏写脚本、外挂,然后卖一点钱。对我来说,能在网上赚到几百美元已经是天大的事了。

 

主持人:第一次有人给你钱,那种感觉真的很奇怪。

 

Sulaiman:太疯狂了。我还记得当时得让我爸帮我弄一个 PayPal 的托管账户之类的,然后钱真的打进来了。对我来说,那简直是世界上最酷的事情。我干了几个月,攒了点钱,当时我对 3D 打印特别着迷,RepRap 那套体系正火。

 

那其实就是一群大学生搞的项目,目标是造一台能打印出自己大部分零件的机器,所以才叫 RepRap。他们在不同大学里搞了一些实验室,从一台打印机开始,让它打印下一台的零件,一步步扩展。当然,这里面问题很多,他们也一直在解决,但那确实推动了后来的 3D 打印浪潮。我当时特别痴迷,就照着他们的零件清单,在阿里巴巴上把东西全买齐了。

 

主持人:然后呢?

 

Sulaiman:一个月后东西到齐了,我一晚上把它装起来,但过程其实挺惨的。我在拆电源的铜线,那是个非常不靠谱的电源,结果真的着火了。铜线全散开,有一根直接扎进我拇指里,大概有五厘米深。

 

主持人:去医院了吗?

 

Sulaiman:没有。那是个上学的夜晚,已经凌晨了。我十三岁,动手能力也不行,在卫生间用镊子折腾了一个小时也没拔出来,最后我干脆把露在外面的剪掉了。接下来几周,它一点点往外长,我每天早上再剪一点。现在想想还挺离谱的。

 

不过打印机最后还是装好了。那时候正好赶上指尖陀螺爆火。我从中国买了一千个滑板轴承,在自己卧室里搞了个小工厂。晚上每隔两个小时起来一次清理打印平台,重新打印一批陀螺。白天上学前,我在车库里装轴承、喷漆、晾干,然后跑去其他学校的公交站,把货卖给“分销商”,其实就是别的学校的学生。他们白天卖,我放学后收钱,线上也卖、发货。

 

生意做了两个月,最后被叫停了。官方理由是,学校餐饮公司有独家销售权,不能在校园里卖东西。但我觉得,他们主要是不爽我一边分散大家注意力,一边还赚钱。这事让我学到了一种“健康的不服从权威”。

 

主持人:这种对权威保持距离,好像一直贯穿你的经历。你提到你不太信任机构,这种态度是怎么形成的?在你的人生里具体体现在哪?

 

Sulaiman:我从很小就知道,我想要的是一种不寻常的结果,而走一条常规路径,基本不可能得到。于是我本能地抗拒一切“惯例”,而机构的本质就是维护惯例。我觉得,几乎所有真正有创造力、有意思的成果,都是来自自由的人。至少在我看到的世界里是这样。所以,忠于这一点,对我来说才是正确的选择。

 

主持人:我很喜欢 John Carlson 的一个观点:所有东西都这么难造、难实现。看看周围,世界就是充满人们的激情项目。

 

Sulaiman:对,完全就是个奇迹。每一样东西背后都有故事,比你想象的要多得多。我记得以前读过 YKK 拉链的故事。你会发现,全世界真正做得好的拉链厂商就两、三家。拉链看起来很便宜,但机械结构其实挺复杂的。之所以能这么便宜、这么可靠,是因为有极少数公司、甚至可以说是极少数人,花了几十年把这件事做到极致。

 

这几乎适用于所有东西。任何特别具体、又能大规模生产的东西,背后通常只有几家公司、甚至几个人在做。就像有时候你会听说,德国某个不起眼的小公司一停产,大众汽车整条产线都得停。疫情期间这种事就更明显了。

 

主持人:在我们见面之前,你还做了一个液体燃料火箭发动机,我记得很小一个,你说是临时起意,二十四小时内点火的?

 

Sulaiman:整个项目其实前后做了大概四周。一开始我就是买了一堆教材,研究火箭发动机的设计原理。和软件完全不一样,软件你可以上 GitHub 看别人的代码,但火箭没有现成文件。你得搞清楚材料特性、化学性质、怎么加工、参数怎么定,推力怎么估算,怎么避免超压。还有喷注器的设计,这个特别难,大概占了一半时间。

 

主持人:这是最难的部分吗?

 

Sulaiman:是的,喷注器最难,也是最后问题最大的地方。我花了三、四周时间,找中国工厂加急做了很多零件。那时候正好感恩节,我准备飞回东海岸看家人。我当时想,要么今晚把它装好、点火,要么就拖两周,然后我决定不能拖,就现在干。我早上灌了很多咖啡,一整天都在干活,搭测试架、装发动机,当晚就点火了。当然,为了能当晚完成,做了不少妥协。

 

主持人:我真的觉得特别好笑,你当时离它其实就几步远?

 

Sulaiman:对。我其实设计了远程点火,但问题是,用来给板载计算机供电的电源还没到,只能用笔记本通过 USB 供电。而我最长的 USB 线只有一米多,所以我只能站在旁边点火。我心里估计,大概有三成概率它会炸,或者喷得到处都是火。

 

视频里其实能看到,我的外套着火了。因为喷注器设计不好,产生了很多超压,没完全燃烧的乙醇直接喷出来,溅到我身上就点着了。那件烧焦的外套现在还留着,当纪念品了。

 

参考链接:

https://www.youtube.com/watch?v=8jN60eJr4Ps&t=41s

作者:肖振威

背景

随着云端业务规模的持续扩大,AI 训练数据、实时日志与多媒体资料等数据量呈现指数级增长,云存储因此逐渐成为主流选择,同时也带来了 I/O 请求量的快速上升。在共享式的多租户架构中,多个租户共同使用底层存储资源,高并发访问极易引发 I/O 资源争抢与性能瓶颈。此外,混合云与多云部署日益普及,数据在多个云环境之间频繁流动,而不同云服务商在存储策略与监控机制上的不一致,使得 I/O 类故障的定位与追溯变得更加复杂。为提升此类问题的处理效率,阿里云云监控 2.0 结合 SysOM 智能诊断功能围绕常见的 I/O 异常场景,构建了一套覆盖“异常检测—根因分析—修复建议”全链路的 I/O 一键诊断功能。

业务痛点解析

痛点一:用户难以准确判断 IO 异常类型

大多数用户对 IO 问题的具体类型缺乏清晰认知,例如往往搞不清当前是 IO 延迟升高、IO 吞吐被打满,还是其它类型的异常,导致很难主动选用对应的排障工具和方法,只能依靠运维专家介入排查,整体诊断效率偏低,人力投入也随之增加。IO 一键诊断聚焦 IO 延时偏高、流量异常、iowait 居高不下等高频场景,自动捕捉 IO 子系统的异常特征,帮助用户快速完成问题类型的判定。

痛点二:异常发生瞬间难以“抓现场”,取证不充分

传统监控系统通常只采集操作系统层面的通用 IO 指标,比如 await、util、tps、bps 等,并以指标突变作为告警条件。然而,当指标被检测到异常时,真实问题往往已经发生甚至结束,此时再想获取更细致的采样和上下文信息,往往为时已晚,关键线索已经流失,难以形成完整的诊断证据链。要做到有效定位,就必须尽可能在异常刚出现或仍在持续时就触发针对性采集,因此,快速识别并及时行动,是获取最佳诊断数据的关键。

痛点三:指标体系割裂,监控数据与诊断结论之间缺乏直连

现有监控往往仅提供一组相互独立的指标,彼此缺乏联动,也没有与具体 IO 故障类型建立直观映射。以 util(磁盘繁忙度)偏高为例,实际分析时还需参考 await 等多项指标,并结合设备的理论 iops、bps 上限进行综合判断。即便勉强推断出问题类型,接下来仍离不开对各种诊断工具的经验性操作,包括如何按照指标数值选择合适的采样区间、参数配置等。IO 一键诊断的设计目标,就是将这一串复杂的关联分析与工具选型过程封装在系统内部,对用户直接呈现整理好的诊断报告和结论。

解决方案

架构介绍

在阿里云云监控 2.0 中,SysOM 管控模块原本就支持对 IO 延迟异常、IO 量异常以及 iowait 高等问题开展诊断。不过,大部分客户并不希望在业务环境上长时间运行高频诊断程序,以免对生产带来干扰。因此,IO 一键诊断采用了“监控先行、按需抓取”的架构:在用户指定的诊断时间段内,系统定期读取 IO 监控指标,用于异常识别与问题圈定,一旦满足条件,再触发具体的子诊断工具进行深度分析并输出报告,构成一个从发现到定位的闭环流程。

考虑到不同业务类型对 IO 行为和性能阈值的容忍度不尽相同,如果强行规定统一的固定阈值,势必会导致误报大量增加或严重漏报。因此,IO 一键诊断引入“动态阈值”机制进行异常识别,其总体处理链路可以概括为:

image

  • 指标采集: 定期从系统中抓取关键 IO 指标,如 await、util、tps、iops、qu-size、iowait 等。
  • 异常检测: 当采集到的指标突破动态阈值,就将其标记为潜在异常。动态阈值的计算方法是整个检测环节的核心,后文会展开说明。
  • 自动诊断触发: 依据异常的指标类型与特征,自动选择合适的诊断工具,并设置触发频率限制,避免频繁调用。
  • 结果处理与展示: 对诊断输出进行归纳和可视化呈现,为用户提供导致问题的根本原因以及可执行的优化建议。

实现原理

指标采集机制

当用户在控制台启动 IO 一键诊断后,系统会按配置好的时间间隔(cycle 毫秒)循环读取 iowait、iops、bps、qusize、await、util 等一系列 IO 指标,并在每个周期对最新采集的数据做异常检测判断。

动态阈值计算

为了能在秒级甚至更细粒度下捕获 IO 突发、短时抖动等异常,必须将各类单一 IO 指标联动起来,从整体上刻画 IO 子系统的“正常波动区间”。动态阈值就是用来界定这一“正常区间”和“异常尖峰”的边界。其计算过程主要分为三层:基础阈值、补偿阈值和最小静态阈值。

基础阈值:刻画整体波动幅度

从时间序列的角度看,IO 指标在大多数时刻处于平稳运行状态,曲线起伏较小;当出现异常负载或者突发流量时,曲线会突然出现明显偏离均值的峰值。因此,首要任务是利用基础阈值,找出这些显著高于日常波动的“尖峰”。

实现策略是:使用一个滑动时间窗口持续观察数据点,在每个窗口中计算所有点相对于窗口平均值的“最大偏离量”,把这个偏离量记为该窗口的“瞬时波动值”;随后对连续多个窗口的“瞬时波动值”求平均,形成动态更新的“基础阈值”。随着新数据不断进入,该阈值也会自适应地调整,始终反映 IO 指标近期的真实波动特征。

image

补偿阈值:削弱基础阈值快速下降带来的误报

基础阈值曲线(如示意图中的黄色线条)虽然能够反映指标的总体波动情况,但在系统处于稳定期时,IO 指标通常只在很窄的一段区间内轻微波动,此时基础阈值可能随波动减弱而快速下降,容易让一些微小的正常抖动被误判为异常。因此,需要额外引入一个“补偿阈值”,叠加在基础阈值之上,对其下降速度进行一定缓冲,从而抑制误报。

image

具体逻辑是:当系统监测到基础阈值在一段时间内持续走低,可以认为当前进入了相对“安静”的常态阶段。此时先过滤明显噪声点,再在剩余的稳定数据里计算一个“常稳态补偿值”,以刻画这类稳定状态下的细小波动。补偿值尚未收敛前,先用当前窗口内出现过的最大基础阈值暂时代替,并在每个新窗口开始时重新计算。一旦基础阈值停止下降或开始回升,就意味着系统波动模式发生了变化,此时补偿机制会被重置,重新进入更宏观的观察期。

image

最小阈值:兜底的静态门槛

最小静态阈值可以理解为预先设定的“绝对下限”,是业务方能接受的最低告警基线。最终用于判定异常的阈值,是“最小静态阈值”和“动态调整阈值(基础阈值 + 补偿值)”之间的较大者。只有当指标既超过了日常波动的正常范围,又突破了业务底线时,才真正被视为异常事件。

此外,如果指标本身已经明显高于“最小静态阈值”,则无需再额外叠加常态补偿值,此时仅以基础阈值作为判断依据即可,将分析重点聚焦在更显著的异常波动上。

image

异常识别策略

在运行时,一旦采集到的某项 IO 指标值高于其对应的动态阈值,即可认为存在异常风险。虽然不同指标(如 iowait、util、iops 等)的判定逻辑略有差异,但整体遵从以下共通规则:

  • 确定告警基线: 为每一类指标定义一条“警戒线”,其数值为“最小静态阈值”和“动态阈值”中的最大值,既考虑业务底线,也考虑历史波动范围。
  • 决定是否触发诊断: 当监控值超过警戒线,同时满足一定的监测条件(如持续时间、触发次数等),就可以启动对应的诊断流程。
  • 持续更新模型: 随着新数据不断加入,动态阈值会被持续修正,使其适配当前环境的正常波动模式,而非依赖一次性的静态配置。

智能诊断与频率控制

当系统确认存在 IO 异常后,一键诊断模块会自动调用相应的分析工具,抓取关键现场信息并进行自动化处理,帮助用户快速锁定问题。为避免过于频繁的诊断操作影响业务,系统通过以下两个参数对诊断频率进行约束:

  • 诊断冷静期(triggerInterval): 规定两次诊断之间必须间隔的最短时间,用来避免在短时间内重复对同一类异常进行频繁扫描。
  • 异常累积阈值(reportInterval): 设置触发诊断所需的异常累积条件。当该值为 0 时,只要异常满足冷静期结束的条件,就立即启动诊断;当该值为非 0 时,则需要在冷静期之后、限定时间窗口内出现一定次数的异常事件,才会真正触发。

根因分析

在完成现场数据采集之后,面对复杂多样的系统信息,如何从中筛选出与当前问题强相关的线索,是传统人工分析的难点。IO 一键诊断在工具层面内置了一套自动分析逻辑,能从采集结果中提炼结论,并以结构化信息的形式反馈给用户,包括但不限于:

  • IO Burst 场景: 分析在异常时间段内各进程对 IO 的贡献度,在报告中标明最“耗 IO”的进程。对于写 buffer IO 而由内核 kworker 线程负责刷脏的情况,也能追溯到最初发起写入的用户进程。
  • IO 延迟异常: 统计并展示异常区间内 IO 延迟的整体分布情况,标记延迟最高的路径(如对应的设备或文件/目录),帮助快速找到性能瓶颈所在。
  • iowait 异常偏高: 记录和展示导致 iowait 偏高的关键进程,以及引发大量等待的具体原因(例如磁盘被占满、脏页刷写过慢等)。

案例分析

iowait 高

在某些场景下,业务反馈系统整体响应慢,通过监控发现 iowait 指标异常升高。借助 IO 一键诊断,可以直接定位到哪一个或哪些进程在大量等待磁盘 IO,以及每个进程累计等待的时间长度,并进一步分析等待背后的原因。

在示例案例中,诊断结果显示:业务写入量过大导致 IO 压力偏高,系统中脏页堆积,最终使业务进程 task_server 长时间阻塞在 IO 等待上。针对这种情况,报告建议谨慎下调 dirty_ratio、dirty_bytes 等内核参数,以减少一次性刷脏量,降低磁盘压力,从而缓解 iowait 过高问题。

image

IO延迟高

另一类常见问题是写 IO 的延迟持续走高。某用户通过基础监控发现写入延迟异常后,通过 IO 一键诊断进行进一步排查。

image

诊断报告指出,在问题发生期间,DiskBlockWrite 进程是主要的 IO 负载来源,并且耗时主要集中在刷脏阶段,也就是说核心瓶颈在于磁盘将缓存数据落盘的过程。依据这一结论,系统给出两类优化建议:一是调整业务逻辑,减少短时间内大量 buffer IO 的写入;二是通过适当调整 dirty_ratio、dirty_background_ratio 等参数,控制脏页生成和回写的节奏,从系统层面降低写 IO 延迟。

image

相关链接:

[1] IO 一键诊断

https://help.aliyun.com/zh/cms/cloudmonitor-2-0/io-key-diagnosis

[2] 云监控-ECS 洞察-SysOM 系统诊断

https://cmsnext.console.aliyun.com/next/region/cn-shanghai/wo...

[3] 操作系统控制台实例纳管

https://help.aliyun.com/zh/alinux/user-guide/system-management

本月可观测热文回顾

文章一览:

构建数据资产“导航地图”:详解 UModel 数据发现与全链路分析能力

基于 UModel 高效构建可观测场景统一实体搜索引擎

揭开 Java 容器“消失的内存”之谜:云监控 2.0 SysOM 诊断实践

打通可观测性的“任督二脉”:实体与关系的终极融合

一行代码实现智能异常检测:UModel PaaS API 架构设计与最佳实践

一文带你玩转 WebSocket 全链路可观测

Android 崩溃监控实战:一次完整的生产环境崩溃排查全流程

已上线!云监控 2.0 面向实体的全链路日志审计与风险溯源

阿里云操作系统控制台一招解决网络丢包

加入我们,一起定义「Data x AI」的未来

iOS 崩溃排查不再靠猜!这份分层捕获指南请收好

跨云日志统一:对象存储数据导入 SLS 的智能之路

拒绝查询超时:一次真实高并发场景下的 SLS 物化视图调优实战

阿里云可观测联合 Datadog 发布 OpenTelemetry Go 自动插桩工具

功能快报

image

点击此处,了解更多产品详情。

2libra 没有自带的图片上传功能,昨天看到 一个帖子 后突然来了灵感,
把之前做的 v2ex 脚本中的图片上传功能抽离出来,做了一个通用的图片上传脚本。

主要功能

  • 支持在所有网站使用。(需要配置 match 规则)
  • 对 2libra, v2ex, nodeseek, deepflood, greasyfork.org 做了适配,显示“插入图片”按钮。其他网站可以自己添加规则。
  • 保存图片上传记录,可以重复利用上传过的图片。
  • 目前支持上传到 Imgur,后续会支持更多图床。
  • 可以批量上传,支持粘贴、拖拽、文件选择收集图片。

2025-10-22-21-23-13
2025-10-22-21-09-33

🔗 安装链接

项目地址: https://github.com/utags/userscripts

目前 是第一个也是唯一一个 2libra 的油猴脚本

本文由TinyPro贡献者王晨光同学原创。

一、背景:让 TinyPro 真正“走到掌心里”

TinyPro 是一套基于 TinyVue 打造的前后端分离后台管理系统,支持菜单配置、国际化、多页签、权限管理等丰富特性。
TinyPro 在桌面端具备良好的体验和模块化架构,但随着移动办公、平板展示等场景增多,移动端体验的短板逐渐显现:

  • 页面缩放不均衡,布局出现溢出或错位;
  • 模态框在小屏上遮挡内容;
  • 图表和表格在横屏与竖屏间切换时无法自适应;
  • 操作区过于密集,不符合触控习惯。

为此启动了 TinyPro 移动端适配项目,目标是在不破坏现有结构的前提下,实现“一次开发,跨端流畅”的体验。

二、技术选型与总体架构

本次移动端适配要求在复杂的中后台系统中实现「一次开发,多端自适应」,既要保证样式灵活,又要维持可维护性和构建性能。

在技术选型阶段,综合评估了三种常见方案:

方案优点缺点
纯 CSS 媒体查询简单直接、依赖少样式分散、逻辑重复、维护困难
TailwindCSS 响应式类社区成熟、类名直观、生态完善样式表体积大、断点固定、不够灵活
UnoCSS 原子化方案按需生成、性能极轻、断点与变体完全可定制需要自行配置规范与规则体系

最终选择了 UnoCSS + Less 的混合架构

  • UnoCSS:负责通用布局、间距、排版等高频样式,原子化写法提升开发效率;
  • Less 媒体查询:用于模态框、导航栏等复杂场景的精细控制;
  • 统一断点配置:集中管理屏幕尺寸分级,保持视觉一致性;
  • 自定义变体(max-<bp>:支持“桌面端优先”策略,通过 max-width 实现移动端自适应,样式逻辑更直观。

UnoCSS:轻量、灵活、即时生成

UnoCSS 是一个 按需生成的原子化 CSS 引擎,最大的特点是 零冗余与高度可定制
不同于 TailwindCSS 的预编译方式,UnoCSS 会在构建阶段根据实际使用的类名即时生成样式规则,从而显著提升构建性能与灵活性.

在配置中通过 presetMini()presetAttributify() 组合使用,使开发者既可以写:

<div class="p-4 text-center bg-gray-100 max-md:p-2"></div>

也可以使用属性化语法:

<div p="4" text="center" bg="gray-100" max-md:p="2"></div>

presetMini 提供轻量原子类体系,presetAttributify 则允许以声明式方式书写样式,更直观、组件化友好。

断点配置与响应式策略

TinyPro 的适配核心之一,是在 uno.config.ts 中建立统一的断点体系,并通过自定义 max-<bp> 前缀实现“桌面端优先”的响应式策略。

const breakpoints = {
  sm: '641px',     // 手机(小屏)
  md: '769px',     // 平板竖屏
  lg: '1025px',    // 平板横屏 / 小型笔电
  xl: '1367px',    // 常规笔电
  '2xl': '1441px', // 高清笔电
  '3xl': '1921px', // 桌面大屏
}

并通过自定义 variants 扩展 max-<bp> 前缀:

variants: [
    (matcher) => {
      const match = matcher.match(/^max-([a-z0-9]+):/)
      if (match) {
        const bp = match[1]
        const value = breakpoints[bp]
        if (!value) return
        return {
          matcher: matcher.replace(`max-${bp}:`, ''),
          parent: `@media (max-width: ${value})`,
        }
      }
    },
  ]

让开发者能自然地书写:

<div class="w-1/2 max-md:w-full"></div>

含义:

默认宽度为 50%,在宽度小于 769px 的设备上改为 100%。

TinyPro 采用「桌面端优先(max-width)」的布局策略:默认以桌面端布局为基础,在移动设备上再进行针对性优化。相比常见的「移动端优先(min-width)」方式,这种做法更符合中后台系统的特性,同时让 UnoCSS 的断点逻辑更直观,并确保主屏体验的稳定性。

三、样式与编码策略

  • 优先级

    • 简单场景:使用 UnoCSS 原子类。
    • 复杂样式:使用 Less 媒体查询。
  • 布局与滚动

    • 首页及核心业务模块完成适配,小屏模式下侧边栏默认收起、导航栏折叠,确保主要内容可见。
    • 页面主要容器避免横向滚动,必要时在小屏下开启局部横向滚动。
    • 表格与大区块在不同断点下自动调整宽度、栅格与间距,小屏下支持横向滚动;分页与密度支持响应式控制。

    布局与滚动.gif

  • 图表自适应

    • 图表组件接入 resize 监听,在侧边栏展开/收起、窗口缩放、语言切换等场景下保持自适应。
    • 小屏下使用 vw 宽度与较小字号,保证图表展示效果与可读性。

    图表自适应.gif

  • 表单与模态框

    • 接入 useResponsiveSize(),控制弹窗在小屏下铺满显示,大屏保持固定宽度。
    • 表单项在不同断点下动态调整排布与间距,优化触控体验。

    表单与模态框.gif

  • 导航与交互

    • 小屏下隐藏导航栏非关键元素,操作聚合到"折叠菜单"。
    • 移动端默认收起侧边菜单栏,提升主要内容展示区域。

    导航与交互.gif

  • 性能优化

    • responsive.ts 中对 resize 事件处理增加节流机制,避免窗口缩放等场景下的频繁无效渲染。

四、常用代码片段

  1. 基于栅格系统 + 响应式断点工具类,通过为 tiny-row 和 tiny-col 添加不同屏幕宽度下的样式规则,实现自适应布局:
<tiny-layout>
    <tiny-row class="flex justify-center max-md:flex-wrap">
        <tiny-col class="w-1/4 max-md:w-1/2 max-sm:w-full max-md:mb-4">···</tiny-col>
        ···
        <tiny-col class="w-1/4 max-md:w-1/2 max-sm:w-full max-md:mb-4">···</tiny-col>
    </tiny-row>
</tiny-layout>
<div class="theme-line flex max-sm:grid max-sm:grid-cols-4 max-sm:gap-2">
  <div···
  </div>
</div>
  1. 基于 响应式工具类 + 自定义响应式 Hook,解决(1)对话框宽度自适应;(2)表格尺寸和密度自适应;(3)逻辑层响应式控制
<template>
  <section class="p-4 sm:p-6 lg:p-8 max-sm:text-center">
    <tiny-dialog :width="modalSize">...</tiny-dialog>
  </section>
</template>

<script setup lang="ts">
import { useResponsiveSize } from '@/hooks/responsive'
const { modalSize } = useResponsiveSize() // 小屏 100%,大屏 768px
</script>
<template>
  <div class="container">
    <tiny-grid ref="grid" :fetch-data="fetchDataOption" :pager="pagerConfig" :size="gridSize" :auto-resize="true" align="center">
      ···
    </tiny-grid>
  </div>
</template>

<script setup lang="ts">
import { useResponsiveSize } from '@/hooks/responsive'
const { gridSize } = useResponsiveSize() // 小屏为mini grid,大屏为medium grid
</script>
  1. 通过 useResponsive 获取屏幕断点状态 sm/md/lg,如:在模板中结合 v-if="!lg" 控制分隔线的渲染,从而实现了小屏下纵向菜单才显示分隔线的效果
<template>
  <ul class="right-side" :class="{ open: menuOpen }">
    <!-- 小屏下才显示分隔线 -->
    <li v-if="!lg">
      <div class="divider"></div>
    </li>
    ···
  </ul>
</template>

<script lang="ts" setup>
import { useResponsive } from '@/hooks/responsive'
const { lg } = useResponsive()
</script>

五、结语

通过本次移动端适配, TinyPro 实现了“从桌面到掌心”的统一体验:
开发者可以继续沿用熟悉的组件体系与布局方式,同时享受 UnoCSS 带来的原子化灵活性与性能优势。在不改变核心架构的前提下,TinyPro 变得更轻盈、更顺滑,也更符合移动时代的使用场景。

关于OpenTiny

欢迎加入 OpenTiny 开源社区。添加微信小助手:opentiny-official 一起参与交流前端技术~
OpenTiny 官网:https://opentiny.design
OpenTiny 代码仓库:https://github.com/opentiny
TinyPro源码:https://github.com/opentiny/tiny-pro

欢迎进入代码仓库 Star🌟TinyPro、TinyEngine、TinyVue、TinyNG、TinyCLI、TinyEditor
如果你也想要共建,可以进入代码仓库,找到 good first issue标签,一起参与开源贡献\~

阿里云函数计算 AgentRun 全新发布后,我们整理了“探秘 AgentRun”系列文章,本系列将梳理企业落地Agent 常见难题,给出具体解法,助力 Agentic AI 快速走进生产级环境。欢迎加入“函数计算 AgentRun 客户群”与我们交流,钉钉群号:134570017218。

AI Agent 时代的沙箱需求

从 Copilot 到 Agent:执行能力的质变

在生成式 AI 的早期阶段,应用主要以“Copilot”形式存在,AI 仅作为辅助生成建议。然而,随着 AutoGPT、BabyAGI 以及 OpenAI Code Interpreter(现为 Advanced Data Analysis)的出现,AI 开始扮演“Agent”的角色。Agent 被赋予了目标,并能自主规划步骤、使用工具来达成目标。

这种质变的核心在于代码执行(Code Execution)。为了回答“分析这层楼的销售数据并绘制趋势图”这样的请求,LLM 不再只是生成一段 Python 代码文本,而是需要在一个真实的 Python 环境中运行这段代码,并获取绘图结果。同样,为了“帮我预订一张去东京的机票”,Agent 可能需要在一个无头浏览器(Headless Browser)中模拟用户点击。

不可信代码的安全隐患

当 LLM 生成代码并执行时,这段代码在本质上是不可信的(Untrusted)。如果直接在应用服务器或用户的本地设备上运行,将面临灾难性的安全风险:

  • 系统破坏:AI 生成的代码可能无意或恶意地包含 rm -rf / 等破坏性指令,或者修改关键系统配置文件。
  • 数据泄露:代码可能尝试读取环境变量中的 API Key,或者扫描内网数据库,将敏感数据发送到外部服务器。
  • 资源耗尽:死循环或内存泄漏代码可能导致宿主机崩溃,影响其他租户的服务。
  • 网络攻击:恶意 Prompt 注入(Prompt Injection)可能诱导 AI 将执行环境作为跳板(Jump Box),对内部网络发起 DDoS 攻击或端口扫描。

Agent 场景面临的独特挑战

除了基础的安全性,AI Agent 的交互特性还给沙箱环境带来了前所未有的工程挑战,这也是传统沙箱(如简单的 Docker 容器或虚拟机)难以应对的:

  • 状态保持:与传统的“请求-响应”模式不同,Agent 往往需要进行多轮对话。上一轮定义的变量(如 df = load_data())需要在下一轮(df.plot())中继续可用。这就要求沙箱环境必须具备上下文记忆能力,而非每次请求都重置环境。
  • 极速启动:用户无法忍受每次交互都等待数秒甚至数十秒的虚拟机启动时间。为了保证流畅的对话体验(Time to First Token),沙箱必须具备毫秒级的冷启动能力。
  • 环境依赖多样性:不同的 Agent 任务可能需要完全不同的依赖库(如 Pandas、Scipy 用于数据分析,Puppeteer 用于网页操作)。沙箱需要支持灵活的自定义镜像或动态依赖加载,同时不能影响启动速度。
  • 资源成本控制:Agent 的调用往往具有稀疏性和突发性(例如一天只用几次,但一次用很久)。长期运行独占的虚拟机(VM)成本高昂且资源利用率低,而传统的 FaaS 虽然便宜但往往缺乏状态保持能力。如何在低成本和高性能之间找到平衡点,是一个巨大的挑战。
    因此,构建一个沙箱(Sandbox)——一个与宿主机、内网以及其他用户数据严格隔离,同时具备高性能、低成本、有状态的封闭执行环境——成为了 AI Agent 沙箱落地的前提条件。

AgentRun Sandbox:专为 Agent 设计的工程化方案

为了解决上述挑战,我们推出了 AgentRun Sandbox。这是一个以高代码为核心,开放生态、灵活组装的一站式 Agentic AI 基础设施平台。

AgentRun 并非从零构建传统的虚拟机集群,而是基于阿里云函数计算(FC)这一强大的 Serverless 底座构建。通过充分利用 Serverless 的按需付费、极致弹性以及免运维(NoOps) 特性,AgentRun 解决了一直困扰沙箱领域的成本与效率难题,并在此基础上通过工程化封装,提供了面向 Agent 场景的专业能力。

为什么选择函数计算作为 Sandbox Infra

在构建 Agent 沙箱时,我们坚定地选择了函数计算(FC)作为底层基础设施,这主要基于以下核心优势的考量:

  • 强安全隔离: 沙箱的核心诉求是安全。函数计算底层采用神龙裸金属与 RunD 安全容器技术,每个执行环境都运行在独立的 MicroVM 中。这种基于虚拟化技术的内核级隔离,相比传统的 Docker 容器隔离具有更高的安全性,能有效防止恶意代码逃逸,为不可信代码执行提供了坚实屏障。
  • 极致弹性与冷启动优化: Agent 的调用往往具有突发性。函数计算具备毫秒级的弹性伸缩能力,结合 RunD 技术对启动速度的极致优化,使得沙箱能够在数秒甚至毫秒内完成创建和启动。这不仅满足了高并发场景下的需求,也保证了 Agent 交互的流畅性,避免了传统虚拟机启动慢带来的延迟感。
  • 成本效益:自建虚拟机集群通常需要为峰值流量预留资源,导致低谷期资源浪费。函数计算采用按需付费(Pay-as-you-go)模式,且 AgentRun 利用了 FC 的空闲自动回收机制,真正做到了“有请求才计费”。对于稀疏调用的 Agent 场景,这种模式能显著降低基础设施成本。
  • 免运维: 基于 Serverless 架构,开发者无需关心底层服务器的操作系统补丁、网络配置及集群维护。AgentRun 团队可以将精力集中在沙箱的核心逻辑与业务体验上,而非底层基础设施的繁琐运维。
  • 会话能力:函数计算围绕 AI Agent Sandbox 场景推出了会话亲和、隔离以及管理能力。在一次会话生命周期内,相同会话的请求均会被亲和路由到同一个实例中,并独占该实例,保证了会话交互的连续性、上下文完整性以及多租安全性,同时提供完整的管理接口来主动对会话生命周期进行控制,降低了开发门槛。

AgentRun 的核心运行机制

传统的 Serverless 通常是无状态的,难以满足 Code Interpreter 这类需要上下文保持的场景。AgentRun 借助函数计算的会话产品能力,在无状态的计算底座上构建了有状态、会话级的沙箱体验。

1. 沙箱请求亲和

AgentRun 允许开发者显式地创建一个具有生命周期的执行环境,解决了传统 Serverless“用完即走”导致的上下文丢失问题。

  • 会话亲和:AgentRun 依赖函数计算会话亲和机制。当开发者创建沙箱后,AgentRun 会维护一个唯一的 SessionID。后续所有携带该 ID 的请求,都会被精准路由到同一个底层的计算实例。这意味着用户在第一步定义的 df = pd.read_csv(...) 对象,在第二步 df.plot() 时依然存在于内存中,完美复刻本地开发体验。
  • MCP 协议原生支持:针对模型上下文协议(Model Context Protocol, MCP),AgentRun 提供了 MCP SSE 及 MCP Streamable HTTP 会话亲和支持。AgentRun 可以直接作为 MCP 网关,让 LLM 与外部工具的交互更加顺滑。

2. 多层次安全隔离

在多租户 SaaS 平台中,安全性是 AgentRun 的基石。

  • 计算隔离:AgentRun 利用底层基础设施的神龙裸金属与 RunD 安全容器技术,确保每个沙箱实例在内核级别进行隔离。通过强制将会话并发度设置为 1,AgentRun 保证租户 A 的进程空间、内存数据与租户 B 物理分离,防止容器逃逸。
  • 网络隔离:网络隔离完全由用户控制。用户可以根据安全需求灵活配置,选择开启或关闭沙箱的公网访问权限,或者将沙箱接入指定的 VPC 网络环境,从而在满足业务连通性的同时,防止恶意代码对内网发起攻击。

3. 灵活的生命周期控制

AgentRun 通过函数计算的会话能力,接管了底层计算资源的生命周期,为上层应用提供精细化管理:

  • 自动闲置回收(Idle Timeout):为了通过 Serverless 架构降低成本,AgentRun 支持设置空闲超时(例如 5 分钟)。如果 Agent 在这段时间内没有新指令,底层实例会自动销毁并停止计费,完美适配 AI 交互“突发性强、稀疏度高”的特点。
  • 状态暂停与恢复(即将上线):针对长时间的任务间歇,AgentRun 能够将沙箱的内存与磁盘状态快照保存,在用户回归时通过快照快速恢复现场,既节省成本又保留了上下文。

4. 会话粒度存储隔离(即将上线)

代码执行需要隔离,数据存储更需要隔离。AgentRun 创新性地规划了会话粒度存储粘性。

  • 动态绑定:AgentRun 允许用户为每个沙箱环境中动态分配一个存储挂载点的专属子目录。
  • 逻辑沙箱:通过底层的挂载技术,沙箱内部只能看到属于自己的 /workspace,物理上无法访问其他租户的文件(如 ../../tenant-b/secret.txt),从文件系统层面根除了数据交叉风险。

AgentRun 开箱即用的沙箱能力

AgentRun 不仅提供了底层隔离环境,还预置了经过工程化调优的标准化模版,让开发者开箱即用:

  • Code Interpreter(代码解释器):预装 Python/Node.js/Java 等环境,支持文件上传下载、数据分析、图表绘制及命令行操作。
  • Browser User(浏览器沙箱):提供基于 CDP over WebSocket 协议的浏览器环境,兼容 Puppeteer / Playwright,让 Agent 能够安全地访问互联网进行网页操作。
  • All In One:集成了代码解释器与浏览器环境的全能型沙箱,满足复杂 Agent 任务需求。
    这些模版镜像具备高度的灵活性,AgentRun 未来将开放镜像定义,允许用户基于标准镜像定制私有依赖库或安全策略。

AgentRun 沙箱架构详解
image.png

AgentRun 网关

这是 AgentRun 的门户,负责接收来自 AI Agent(如 LangChain 应用、ChatGPT Plugin)的 HTTP 请求,除了标准的身份验证、鉴权以及协议转换(如将 HTTP 转为 WebSocket)之外,其核心能力便是沙箱管理以及沙箱请求路由的功能,它屏蔽了底层 Serverless 基础设施的复杂性,实现了如下能力:

  • 沙箱管理:管理沙箱资源,维护业务层沙箱 ID 与底层计算资源 SessionID 的映射关系
  • 状态维护:监控沙箱的活跃状态,基于沙箱超时配置以及底层资源情况及时对状态进行更新
  • 资源调度:根据用户指定的计算规格(CPU、Memory),向底层申请相应的资源。

函数计算沙箱环境

主要由函数计算作为底层算力来承载沙箱的运行。AgentRun 利用函数计算提供的极致弹性能力,实现在分钟内启动成三万个独立的沙箱环境,每个环境都运行在独立的 MicroVM 中,搭配自研开箱即用的沙箱镜像模版,在功能以及性能上为用户提供了双重保障。

典型工作流:从指令到结果

以“用户让 Agent 根据上传的 Excel 文件绘制图表”为例,AgentRun 的工作流程如下。

阶段一:模板创建

  1. 用户请求:Agent 接收到用户指令后,由 LLM 决策使用 Python 来实现该需求。
  2. Agent 工具调用:AI Agent 会向 AgentRun 网关发送 Code Interpreter 沙箱模板的创建请求。
  3. 模板创建:AgentRun 网关会调用函数计算接口创建一个 Code 沙箱模板函数,镜像配置为前文提到的自研 Code Interpreter 沙箱模板,该函数需要同时配置会话亲和以及会话隔离。

阶段二:沙箱创建

  1. Agent 工具调用:模板创建完成后,Agent 继续进行沙箱创建,创建时传入已有的模板 ID,标识沙箱实例运行时的配置和镜像
  2. 沙箱创建:AgentRun 收到沙箱创建请求后,会调用 FC 的 CreateSession 接口来创建一个沙箱实例,该沙箱会有一个合适的闲置超时时间,最长可存活 24h
  3. 创建完成:AgentRun 会保存 FC 返回的会话 ID,并生成沙箱业务 ID 与之对应,最终将沙箱业务 ID 返回给用户

阶段三:任务执行

  1. 上传文件:Agent 通过 Code Interpreter 的文件上传接口,将 Excel 文件上传。若想将该文件持久化,可以在创建沙箱时配置持久化存储 NAS,将其挂到沙箱中,并将文件上传到 NAS 挂载的目录上。
  2. 绘制图表:Agent 生成代码 import pandas as pd; df = pd.read_excel('data.xlsx'),并调用 Code Interpreter 的 run_code 接口执行代码。
  3. 会话亲和:Agent 所有发往 Code Interpreter 的请求中,都必须带上对应的沙箱 ID 才能保证请求都路由到同一个沙箱实例。
  4. 内存驻留:代码执行完毕,变量 df 驻留在内存中.
  5. 二次代码执行:Agent 根据数据列名生成绘图代码 df.plot()。再次发送代码运行请求
  6. 上下文复用:请求再次到达同一实例,直接使用内存中的 df 对象进行绘图,生成图片文件。
  7. 结果回传:图片被写入 NAS,下载链接返回给 Agent。

阶段四:资源销毁

  1. 空闲检测:Agent 完成任务,不再发送请求。
  2. 自动回收:达到 SessionIdleTimeout(如 5 分钟)后,函数计算会自动销毁该沙箱实例,此时除了持久化到 NAS 上的数据,其余环境相关数据均被销毁。
  3. 文件回收:如果 NAS 上的文件是会话隔离的,当用户会话结束后,NAS 上文件需要进行主动或者定时自动清除。

工作时序图

image.png

AgentRun 的核心设计原则

AgentRun 的工程化实践遵循以下五大核心原则,这构成了其安全、高效、可扩展的基石:

原则一:配置即代码

AgentRun 将沙箱环境定义(环境变量、资源规格、健康检查等)封装为标准化模版。这种设计实现了沙箱配置的版本化管理,使得 Agent 环境可以像代码一样进行复制和回滚。

原则二:会话即沙箱

AgentRun 将“会话”作为沙箱的唯一实体。通过 SessionID 绑定底层的计算实例与上下文状态,实现了真正的按需分配与状态保持。沙箱的创建与销毁完全独立于底层物理设施,对用户透明。

原则三:生命周期可编程

AgentRun 不仅提供创建(Create)和删除(Delete)接口,还引入了“暂停”、“恢复”和“自动超时”机制。这种可编程性让上层应用能根据业务价值最大化资源利用率,实现成本与性能的最优平衡。

原则四:网络接入标准化

AgentRun 抹平了底层网络的差异,提供标准化的 HTTP/WebSocket 接口,并支持 Server-Sent Events(SSE)。无论底层如何升级,上层 Agent 沙箱始终通过标准的 Header 或 Cookie 携带 SessionID 进行交互,降低了集成复杂度。

原则五:存储隔离细粒度化(即将上线)

AgentRun 不仅支持模版粒度的文件系统共享,同时也能够配置沙箱粒度目录级动态挂载。每个沙箱单独挂载一个目录,从根源上杜绝了多租户环境下的数据越权访问风险。

总结与展望

AgentRun Sandbox 是 Serverless 技术在 AI Agent 领域的最佳工程化实践。

通过将阿里云函数计算(FC)在 RunD 安全虚拟化(解决隔离与启动速度)、会话亲和性(解决状态保持)以及 动态 NAS 挂载(解决数据隔离)等方面的底层技术创新,封装为面向业务的 AgentRun 平台,我们成功降低了企业构建 AI Agent 的门槛。

对于构建下一代智能体应用的企业而言,选择 AgentRun Sandbox 不仅是选择了一个沙箱工具,更是选择了一套兼顾安全性、用户体验与商业效率的弹性基础设施。未来,AgentRun Sandbox 将继续在启动延迟优化、状态秒级快照恢复以及更多样化的存储支持上深耕,致力于成为 AI Agent 时代最佳的沙箱基座。

立即体验函数计算 AgentRun

函数计算 AgentRun 的无代码到高代码演进能力,现已开放体验:

查看更多产品详情https://www.aliyun.com/product/fc/agentrun

1.快速创建:访问控制台(https://functionai.console.aliyun.com/cn-hangzhou/agent/explore),60秒创建你的第一个 Agent

2.深度定制:当需要更复杂功能时,一键转换为高代码
3.持续演进:利用函数计算 AgentRun 的基础设施能力,持续优化你的 Agent

从想法到上线,从原型到生产,函数计算 AgentRun 始终是你最好的伙伴。欢迎加入“函数计算 AgentRun 客户群”,钉钉群号:134570017218。

快速了解函数计算 AgentRun

一句话介绍:函数计算 AgentRun 是一个以高代码为核心的一站式 Agentic AI 基础设施平台。秉持生态开放和灵活组装的理念,为企业级 Agent 应用提供从开发、部署到运维的全生命周期管理。

image.png

函数计算 AgentRun 架构图

AgentRun 运行时基于阿里云函数计算 FC 构建,继承了 Serverless 计算极致弹性、按量付费、零运维的核心优势。通过深度集成 AgentScope、LangChain、RAGFlow、Mem0 等主流开源生态。函数计算 AgentRun 将 Serverless 的极致弹性、零运维和按量付费的特性与 AI 原生应用场景深度融合,助力企业实现成本与效率的极致优化,平均 TCO 降低 60%

让开发者只需专注于 Agent 的业务逻辑创新,无需关心底层基础设施,让 Agentic AI 真正进入企业生产环境。

作者:江昱

阿里云函数计算 AgentRun 全新发布后,我们整理了“探秘 AgentRun”系列文章,本系列将梳理企业落地 Agent 常见难题,给出具体解法,助力 Agentic AI 快速走进生产级环境。欢迎加入“函数计算 AgentRun 客户群”与我们交流,钉钉群号: 134570017218

当你已经用 LangChain、AgentScope、LangGraph 等框架开发了 Agent 应用,如何让它们享受函数计算 AgentRun 提供的 Serverless 运行时、企业级 Sandbox、模型高可用、全链路可观测等能力?好消息是,你几乎不需要改动现有代码,只需要简单的适配就可以迁移到函数计算 AgentRun。

这篇文章将通过真实的代码示例,展示如何将不同框架的 Agent 应用部署到函数计算 AgentRun 上,以及如何充分利用函数计算 AgentRun 的各种能力。

为什么要部署到函数计算 AgentRun?

在讨论具体的集成方案前,让我们先明确一个问题:如果你的 Agent 应用已经在本地或自建服务器上运行良好,为什么还要迁移到函数计算 AgentRun?

答案很简单:从开发环境到生产环境,有一道巨大的鸿沟。  本地运行只需要考虑功能实现,但生产环境需要考虑性能、稳定性、成本、安全、可观测等一系列问题。函数计算 AgentRun 提供的不是又一个 Agent 框架,而是让你的 Agent 能够以企业级标准运行的完整基础设施。

具体来说,部署到函数计算 AgentRun 后,你能获得:零运维的 Serverless 运行时(自动扩缩容、按量付费),企业级的 Sandbox 环境(高性能、安全隔离),模型高可用保障(自动熔断、多模型 Fallback),全链路可观测(完整的 Trace、成本归因),以及统一的工具和 MCP 管理。

image

快速上手:5 分钟部署你的第一个 LangChain Agent

让我们从最流行的 LangChain 框架开始,通过一个完整的例子展示如何将 LangChain Agent 部署到函数计算 AgentRun。

第一步:安装 Serverless Devs

函数计算 AgentRun 使用 Serverless Devs 作为部署工具。如果你有 Node.js 环境,一行命令即可安装:

npm i -g @serverless-devs/s

第二步:创建项目

使用脚手架快速创建项目(注意:需要 Python 3.10 及以上版本):

# 初始化模板
s init agentrun-quick-start-langchain
# 进入代码目录
cd agentrun-quick-start-langchain/code
# 初始化虚拟环境并安装依赖
uv venv && uv pip install -r requirements.txt

第三步:配置认证信息

通过环境变量(建议使用 .env 文件)配置你的 AgentRun 访问凭证:

export AGENTRUN_ACCESS_KEY_ID="your-access-key-id"
export AGENTRUN_ACCESS_KEY_SECRET="your-access-key-secret"
export AGENTRUN_ACCOUNT_ID="your-account-id"
export AGENTRUN_REGION="cn-hangzhou"

第四步:理解集成方式

这是最关键的部分。打开生成的代码,你会看到集成非常简单:

from agentrun.integration.langchain import model, sandbox_toolset
from agentrun.server import AgentRunServer
# 使用 AgentRun 的模型(自动享受高可用、熔断等能力)
llm = model("<your-model-name>")
# 使用 AgentRun 的 Sandbox 工具
tools = sandbox_toolset(
    template_name="<your-sandbox-name>",
    template_type=TemplateType.CODE_INTERPRETER,
    sandbox_idle_timeout_seconds=300,
)
# 创建 LangChain Agent(和原来的代码完全一样)
agent = create_agent(
    model=llm,
    tools=tools,
    system_prompt="你是一个智能助手"
)
# 定义调用函数
def invoke_agent(request):
    result = agent.invoke({"messages": request.messages})
    return result["messages"][-1].content
# 启动 HTTP Server(提供 OpenAI 兼容的 API)
AgentRunServer(invoke_agent=invoke_agent).start()

核心要点:

  • model() 函数返回的是 LangChain 可以直接使用的模型对象
  • sandbox_toolset() 返回的是 LangChain Tools 列表
  • 你的 Agent 创建代码完全不需要改动
  • AgentRunServer 自动处理 HTTP 请求,提供标准的 OpenAI API

第五步:本地测试

启动服务后,可以通过 HTTP 请求测试:

curl 127.0.0.1:9000/v1/chat/completions \
  -X POST \
  -H "content-type: application/json" \
  -d '{"messages": [{"role": "user", "content": "通过代码查询现在是几点?"}], "stream":true}'

第六步:部署到生产环境

项目中已经包含了 s.yaml 配置文件。你只需要修改其中的 role 字段为你的阿里云角色:

role: acs:ram::{您的阿里云主账号 ID}:role/{您的阿里云角色名称}

配置部署密钥:

s config add
# 按照引导输入 Access Key ID 和 Secret,记住密钥对名称(如 agentrun-deploy)

执行部署:

s deploy -a agentrun-deploy

部署完成后,你会得到一个 HTTPS URL,就可以在生产环境调用你的 Agent 了。

不同框架的集成案例

函数计算 AgentRun 不仅支持 LangChain,还深度集成了主流的 Agent 开发框架。所有框架都遵循同样的理念:通过简单的适配层,让你的代码无缝迁移到函数计算 AgentRun,享受企业级能力。

LangGraph:工作流编排

LangGraph 是 LangChain 团队推出的工作流编排框架,适合构建复杂的多步骤 Agent。集成方式和 LangChain 类似:

from agentrun.integration.langgraph import model, tools
from langgraph.graph import StateGraph, MessagesState
from langgraph.prebuilt import ToolNode
# 使用 AgentRun 的模型和工具
llm = model("<your-model-name>").to_langgraph()
agent_tools = tools()
# 构建 LangGraph 工作流(和原来的代码一样)
def call_model(state: MessagesState):
    messages = state["messages"]
    response = llm.invoke(messages)
    return {"messages": [response]}
workflow = StateGraph(MessagesState)
workflow.add_node("agent", call_model)
workflow.add_node("tools", ToolNode(agent_tools))
workflow.set_entry_point("agent")
# 定义条件边...
app = workflow.compile()
# 调用
result = app.invoke({"messages": [HumanMessage(content="查询上海天气")]})

LangGraph 的优势是可以精确控制 Agent 的执行流程,比如条件分支、循环、并行执行等。部署到函数计算 AgentRun 后,这些复杂的工作流都能自动享受弹性伸缩和可观测能力。

AgentScope:多智能体协作

AgentScope 是阿里达摩院开源的多智能体框架,特别适合构建多 Agent 协作场景。集成方式:

from agentrun.integration.agentscope import model, tools
from agentscope.agent import ReActAgent
from agentscope.tool import Toolkit
# 使用 AgentRun 的模型和工具
llm = model("<your-model-name>").to_agentscope()
agent_tools = tools()
# 注册工具到 Toolkit
toolkit = Toolkit()
for tool in agent_tools:
    toolkit.register_tool_function(tool)
# 创建 Agent(和原来的代码一样)
agent = ReActAgent(
    name="assistant",
    sys_prompt="你是一个智能助手",
    model=llm,
    toolkit=toolkit,
)
# 调用
result = await agent.reply(Msg(name="user", content="查询上海天气", role="user"))

AgentScope 的优势是对多 Agent 系统的原生支持,包括 Agent 之间的通信、协调、记忆共享等。部署到函数计算 AgentRun 后,每个 Agent 都在独立的隔离环境中运行,确保安全性。

PydanticAI:类型安全的 Agent 框架

PydanticAI 是一个新兴框架,强调类型安全和结构化输出。集成方式:

from agentrun.integration.pydantic_ai import model, tools
from pydantic_ai import Agent
# 使用 AgentRun 的模型和工具
llm = model("<your-model-name>").to_pydantic_ai()
agent_tools = tools()
# 创建 Agent
agent = Agent(
    llm,
    instructions="Be concise, reply with one sentence.",
    tools=agent_tools,
)
# 同步调用
result = agent.run_sync("上海的天气如何?")
# 异步调用
result = await agent.run("上海的天气如何?")

PydanticAI 的优势是强类型和结构化输出,特别适合需要严格数据验证的企业场景。

充分利用函数计算 AgentRun 的核心能力

将 Agent 部署到函数计算 AgentRun 后,你不仅获得了 Serverless 运行环境,还可以深度利用平台提供的各种企业级能力。

模型高可用:告别单点故障(搭配 AI 网关)

部署到函数计算 AgentRun 后,你的 Agent 自动享受模型高可用能力。当你配置的主模型出现故障、限流或超时时,系统会自动切换到备用模型,整个过程对你的代码完全透明。
在函数计算 AgentRun 控制台配置模型时可以和 AI 网关进行联动,可以设置:主模型(如 GPT-4),备用模型列表(如 Claude-3、Qwen-Max),熔断策略(错误率阈值、超时时间),负载均衡策略(轮询、权重、最少连接)。
你的代码完全不需要改动,只需要在创建模型时使用函数计算 AgentRun 的模型名称,所有的容错、切换、负载均衡都由平台自动处理。

企业级 Sandbox:安全执行代码

函数计算 AgentRun 提供的 Sandbox 不是简单的代码执行环境,而是企业级的安全隔离沙箱。每个 Sandbox 实例都是独立隔离的,支持多种执行类型:

Code Interpreter 支持 Python、Node.js、Java、Bash 等语言,可以执行数据分析、文件处理等任务。Browser Tool 提供浏览器自动化能力,支持网页爬取、表单填写、截图等操作。All In One 集成了代码解释器和浏览器工具,提供更丰富的交互能力。

使用时,通过 sandbox_toolset() 函数就可以获取相应的工具集合,这些工具会自动转换为你使用的框架所需的格式。

工具和 MCP:标准化集成

函数计算 AgentRun 提供统一的工具管理和 MCP(Model Context Protocol)机制。你可以从工具市场选择现成的工具,也可以自定义工具并发布到市场。

更强大的是 MCP 的 Hook 机制。通过前置 Hook,可以在工具调用前自动注入用户凭证、记录请求日志、校验参数合法性。通过后置 Hook,可以对结果进行转换、记录审计日志、处理异常情况。这些通用逻辑不需要在每个工具中重复实现,大大提升了开发效率。

全链路可观测:不再是黑盒

这是函数计算 AgentRun 最强大的能力之一。你的代码不需要做任何改动,平台会自动记录 Agent 的完整执行链路

在可观测平台上,你可以看到:Agent 接收到用户请求的时间和内容,调用了哪个模型、使用了多少 Token、花费了多少钱,调用了哪些工具、每个工具的执行时间和结果,访问了哪些知识库、检索了多少数据,每个环节的耗时分布,完整的调用链 Trace。

这些能力都是平台自动提供的,通过探针注入实现,无论是高代码还是低代码创建的 Agent,都自动享受这些可观测能力。

记忆和知识库:数据不出域

函数计算 AgentRun 深度集成了 RAGFlow、Mem0 等开源项目,提供灵活的记忆和知识库管理。你可以选择一键托管模式,由平台统一管理部署运维,享受 Serverless 的弹性和按量付费优势。也可以选择绑定模式,将 Agent 连接到已经部署在企业 VPC 或 IDC 内的实例,数据完全不出企业内网

这种灵活性让你可以根据数据的敏感级别选择不同的策略:核心业务数据私有化部署,一般数据托管上云,在安全性和便利性之间找到最佳平衡。

立即体验函数计算 AgentRun

函数计算 AgentRun 的无代码到高代码演进能力,现已开放体验:

  1. 快速创建: 访问控制台( https://functionai.console.aliyun.com/cn-hangzhou/agent/explore ),60 秒创建你的第一个 Agent
  2. 深度定制: 当需要更复杂功能时,一键转换为高代码
  3. 持续演进: 利用函数计算 AgentRun 的基础设施能力,持续优化你的 Agent

从想法到上线,从原型到生产,函数计算 AgentRun 始终是你最好的伙伴。欢迎加入“函数计算 AgentRun 客户群”,钉钉群号:134570017218。

快速了解函数计算 AgentRun:

一句话介绍:函数计算 AgentRun 是一个以高代码为核心的一站式 Agentic AI 基础设施平台。秉持生态开放和灵活组装的理念,为企业级 Agent 应用提供从开发、部署到运维的全生命周期管理。

image

函数计算 AgentRun 架构图

AgentRun 运行时基于阿里云函数计算 FC 构建,继承了 Serverless 计算极致弹性、按量付费、零运维的核心优势。通过深度集成 AgentScope、LangChain、RAGFlow、Mem0 等主流开源生态。函数计算 AgentRun 将 Serverless 的极致弹性、零运维和按量付费的特性与 AI 原生应用场景深度融合,助力企业实现成本与效率的极致优化,平均 TCO 降低 60% 。 

开发者只需专注于 Agent 的业务逻辑创新,无需关心底层基础设施, 让 Agentic AI 真正进入企业生产环境。

本次更新主要是体验优化上,列一下更新内容:

代码高亮方案换为 ShiKi

新方案体验有问题希望可以及时反馈我做修正,旧方案比较老旧了所以用了新的。

介绍页内容变化

经验值与金币值的常量现在实时了,另外可以输入站内表情以及自动优化中英文空格。

评论列表性能优化

之前楼层数多了,尤其是楼中楼多的情况下,输入会出现卡顿,新版做了优化看体验是否更好一些。

浏览优化

现在滚动时在左侧上方会出现返回按钮,方便回到上一页。

输入优化

现在评论的编辑框增加了@当前楼层的所有人以及@所有人。目前@所有人只取当前评论列表的所有用户名,后续再看是否查询全部。

金币消耗变动

♥️与 👍 现在的消耗增加,让这两个表情的分量更加重一些,且获得会被系统扣除掉 10%。同时金币打赏的最低额度设置为 100 金币,最高 500 金币,各位现在不那么容易慷慨解囊了。

既然有用户慷慨的发现有些操作不消耗金币,我就勉强加入了:

  • 编辑评论、帖子、附言均需要消耗金币;
  • 新增附言需要消耗金币。

消息提醒优化

现在长连接通知收到后,会在浏览器的标题上显示未读计数。

还有不少优化

不列了,比较琐碎。sobbing

一、概述

近期,天穹沙箱团队在追踪银狐家族的攻击活动时,发现其最新样本采用了高度复杂且极具迷惑性的攻击链。该攻击链通过多阶段反调试检测、伪装合法软件安装、内存反射加载等技术,并结合隐蔽的进程注入与DLL侧载(DLL Side-Loading)等手段,以规避安全检测,实现持久驻留于受害者主机。

二、样本信息

  • 样本名: Rar0092_v3.53.278_2xdcey.exe
  • SHA1:50715a3abd66e17654255b7881b035d006dce605
  • 文件类型:EXE
  • 文件大小:127.03 MB
  • 家族归属:银狐家族
  • 报告链接:天穹沙箱分析报告

三、样本分析

该样本具备高度隐蔽性,在执行过程中反复侦测运行环境,其执行逻辑具有明显的多层次、复杂化特征。天穹智能化沙箱系统凭借其全链路行为深度建模与动态分析能力,成功完整捕获并解析了该样本从初始释放、伪装执行、多阶段内存加载到最终持久化与 C2 通信的全过程。系统不仅精准识别了其反调试、环境探测、权限提升等规避行为,还完整提取了各阶段解密后的恶意载荷。以下结合沙箱动态分析结果细致分析样本的恶意行径。

图1 攻击流程

1、反调试检测

首先,样本运行后先检测自身是否处于调试状态,通过检查 PEB->BeingDebugged 字段识别当前是否被用户态调试器附加调试。
接着,调用 NtQuerySystemInformation(SystemBasicInformation) 接口获取当前系统基本信息,检测 CPU 核心数量是否满足 >= 3 核,以及物理内存大小是否满足 >= 3G,样本依据上述硬件配置判断是否处于沙箱分析环境。

图2 反调试检测

当以上检测要求通过后,样本开启真正的恶意能力释放。为保护自身核心代码和逻辑不被轻易窥探,外部函数调用均通过手动查找 LDR 链表获取模块基址,再解析 PE 头获取函数地址,增加函数调用的隐蔽性。
这类多层环境感知检查被深度内嵌在代码执行流的关键节点上,形成贯穿始终的对抗屏障,阻碍安全人员的动态调试和静态分析。

2、伪装安装程序

环境检测通过后,样本再度检查自身是否具有管理员权限,权限满足后会在 C:\\ProgramData 目录下创建随机字符串的目录,并释放多个文件:

app.exe._ (MD5:f041793908111b5395226bc9ed5e6698)
README.md (MD5:daa5414f94d8f43925efffd79979cf75)
View.dat (MD5:c2db56df94b92d6370c87303d1506f54)
Web.dat (MD5:937ab7f863261a046ba3dd46df7cb270)
åº ç ¨å® .exe (MD5:34f435f15a846ae677f88ea412c074d1)
View.conf (MD5:85fac9d703132b9a28beb11d8ec3d181)
alt text
图3 创建目录释放文件

其中 åº ç ¨å® .exe (MD5:34f435f15a846ae677f88ea412c074d1) 为腾讯应用宝的可信安装程序,其余文件为样本后续阶段运行的加密 payload。
为掩盖程序真实意图,样本在释放恶意文件后,调用 WdcRunTaskAsInteractiveUser 接口运行腾讯应用宝安装程序,制造正常操作的假象,欺骗用户。随后,样本隐蔽地拉起 app.exe 进程,进入下一阶段的恶意操作。

图4 伪装程序

3、Payload 加载与执行

第一阶段: View.dat 文件 payload 为 raw 数据,样本通过 VirtualAlloc 分配内存,将 payload 解密后写入内存,并调用 CreateThread 函数创建线程执行该段 payload。
解密后的 payload 是一段具备内存反射加载 PE 文件功能的 shellcode,会加载 raw 数据中夹带的 DLL 文件,并调用其入口函数 DllEntryPoint 进入下一阶段逻辑。

图5 加载 payload

第二阶段: 内存加载的 DLL 文件注册服务并运行 svchost.exe 进程,并注入其他两个文件中包含的 payload (app.exe._ 和 View.dat)

图6 注入 payload

值得说明的是,在本阶段执行注入操作时样本会判断运行环境,高版本 Windows 系统将使用 PoolParty (泳池派对) 注入技术。
注入的恶意代码会在用户目录下释放两个文件:WebViewHelper.exe 和 libcef.dll,其中 WebViewHelper.exe 为具备合法签名的白文件,被用来加载黑文件 libcef.dll,达到混淆视听的目的。

图7 释放文件

svchost.exe 进程通过自启动服务方式运行重命名之后的 WebViewHelper 进程,进入下一阶段逻辑。

第三阶段: WebViewHelper 进程加载的恶意 DLL 文件 (libcef.dll) 会进行一系列的环境检测,包括判断运行环境、所属 session 以及管理员权限等,检测通过后与 C2 服务器建立通信。

图8 环境检测
图9 网络通信
图10 样本攻击链

整个攻击链逻辑错综复杂,层层递进,分析难度极大。同时,攻击者通过伪装合法安装程序、利用白文件加载黑文件等方式混淆视听,进一步干扰了用户和安全人员的判断。

四、IOC

恶意文件(MD5)

481577b35e4d09510c49d78f5c3fa98c    Rar0092_v3.53.278_2xdcey.exe
0c0d6806bb8caf68d4dfa5208db52a17    app.exe
f041793908111b5395226bc9ed5e6698    app.exe._
daa5414f94d8f43925efffd79979cf75    README.md
c2db56df94b92d6370c87303d1506f54    View.dat
937ab7f863261a046ba3dd46df7cb270    Web.dat
34f435f15a846ae677f88ea412c074d1    åº ç ¨å® .exe
85fac9d703132b9a28beb11d8ec3d181    View.conf
c154442ddf6363b6ac5822e47028d672    WebViewHelper.exe
74be16979710d4c4e7c6647856088456    libcef.dll

恶意IOC

192.238.201.32[:]30009              C2 地址

报告链接

分析报告:天穹沙箱分析报告

五、检出规则

天穹沙箱已针对该银狐变种样本编写如下YARA规则,供用户参考使用:

rule Trojan_SilverFox
{
    meta:
        description = "银狐变种的检测"
        date = "2026-01-04"
    strings:
        $seq1 = { 81 E2 FF 00 00 00 03 C2 25 FF 00 00 00 2B C2 88 04 24 48 63 44 24 04 48 8B 4C 24 20 8A 04 01 88 44 24 01 0F B6 04 24 48 63 4C 24 04 48 8B 54 24 20 4C 8B 44 24 20 41 8A 04 00 88 04 0A 0F B6 04 24 48 8B 4C 24 20 8A 54 24 01 88 14 01 }

        $seq2 = { 81 E2 FF 00 00 00 03 C2 25 FF 00 00 00 2B C2 48 8B 4C 24 20 88 81 01 01 00 00 48 8B 44 24 20 0F B6 80 00 01 00 00 48 8B 4C 24 20 8A 04 01 88 04 24 48 8B 44 24 20 0F B6 80 01 01 00 00 48 8B 4C 24 20 0F B6 89 00 01 00 00 48 8B 54 24 20 4C 8B 44 24 20 41 8A 04 00 88 04 0A 48 8B 44 24 20 0F B6 80 01 01 00 00 48 8B 4C 24 20 8A 14 24 88 14 01 48 8B 44 24 20 0F B6 80 00 01 00 00 48 8B 4C 24 20 0F B6 04 01 48 8B 4C 24 20 0F B6 89 01 01 00 00 48 8B 54 24 20 0F B6 0C 0A 33 C1 }

    condition:
        all of them
}

六、技术支持与反馈

星图实验室深耕沙箱分析技术多年,致力于让沙箱更好用、更智能。做地表最强的动态分析沙箱,为每个样本分析人员提供便捷易用的分析工具,始终是我们追求的目标。各位同学在使用过程中有任何问题,欢迎联系我们。

小T导读:京能集团在储能安全管理平台中采用 TDengine TSDB 作为底层时序数据库。依托 TDengine 企业版的零代码数据写入平台,来自全国 28 家电化学储能电站的数据能够按照统一编码规则高效接入 TDengine 时序数据库中,实现了稳定、高性能的数据采集与管理。在此基础上,借助 TDengine TSDB Flink Connector,系统可快速、稳定地从数据库中读取海量数据,开展实时分析与智能处理,充分释放数据的潜在价值。本文将结合该项目的实践过程,为大家带来深入分享与参考。

项目背景

京能集团储能安全管理平台共接入全国 28 家电化学储能电站,累计测点达 270 万个,由四个平台公司分别负责数据传输与汇聚。系统需要支撑大规模的数据统计分析、事件报警与安全预警,对底层数据库的性能与稳定性提出了极高要求。

鉴于电化学储能项目采集点数量庞大(270 万点)、锂电池热失控的超前预警技术复杂等因素,传统关系型数据库已无法满足高并发写入与海量数据存储的需求。由于这些数据具备时间序列写入、格式固定、写入量巨大等典型特征,我们最终选择采用时序数据库作为系统核心数据底座。

应用实际落地

在充分调研国内多款时序数据库产品后,我们发现,从国内目前的实际情况分析,TDengine TSDB 已成为众多企业在海量数据高速存储、处理与调用场景中的首选方案。基于其成熟的技术体系与稳定的性能表现,我们最终选定 TDengine TSDB 作为平台的底层时序数据库,并结合 Kafka 与 Flink 构建了完整的数据流处理体系,实现了数据的高效传输与实时计算,顺利达成项目预期目标。以下是架构简图:

TDengine TSDB 支持多种写入方式

  1. SQL 语言写入 :https://docs.taosdata.com/basic/insert/
  2. 无模式写入:https://docs.taosdata.com/develop/schemaless/
  3. 参数绑定方式:https://docs.taosdata.com/develop/stmt/
  4. 企业版的零代码数据写入— taosExplorer 数据接入功能:https://docs.taosdata.com/advanced/data-in/

项目中涉及多个 Kafka 集群、数十个需要接入的 topic。我们重点采用了 TDengine 企业版的零代码数据写入能力,实现了从 Kafka 到 TDengine TSDB 的高效对接。该功能支持灵活配置类似 ETL 的复杂自定义选项,极大简化了数据接入流程和时间,而且数据接入性能完全达到了项目要求。

为了保证数据的合理性,我们出台了《京能集团电化学储能电站安全管理平台和储能电站设备标识编码规则》,通过标准的 kks 编码在 taosX 对 Kafka 数据进行了有效过滤和清理,最终写入 TDengine TSDB。kks 部分编码实例如下:

下图为数据过滤、转换等规则设置:

此外,taosX 数据接入还支持多节点高可用配置。只需在多台 taosX 上部署相同的 Kafka 数据接入任务,并设置相同的 groupId,即可自动实现任务高可用,确保数据接入的连续性与稳定性。

同时,TDengine 还提供完善的 taosX 任务监控机制,可直接通过 Grafana 一键配置,快速生成可视化监控图表:

超级表 + 子表的使用

TDengine TSDB 结合“一个数据采集点一张表”的设计理念,引入了具有创新性的“超级表”机制,从根本上解决了大规模时序数据结构不统一、聚合困难、运维复杂等问题。每个采集点的数据独立存储,天然具备写入无锁、数据顺序追加、块状连续存储等优势。这种设计方式不仅提升了写入与查询性能,还带来了极高的数据压缩效率。

TDengine TSDB 支持对超级表标签进行动态的添加、修改与删除操作,满足设备属性变更、系统扩展等业务需求。

计算、分析处理

在 Flink 计算平台上,我们借助 TDengine TSDB 企业版提供的 Flink 连接器——TDengine TSDB Flink Connector(https://docs.taosdata.com/advanced/data-publisher/Flink/),实现了与 TDengine TSDB 的无缝集成。该连接器可高效、稳定地从 TDengine TSDB 中读取海量时序数据,并在此基础上进行全面、深入的分析处理,充分挖掘数据的潜在价值,极大地提升数据处理的效率和质量。

Flink CDC 主要用于提供数据订阅功能,能实时监控 TDengine TSDB 数据库的数据变化,并将这些变更以数据流形式传输到 Flink 中进行处理,同时确保数据的一致性和完整性。

落地效果

  1. 数据接入便利性:目前我们已接入 20 多个 kafka 数据,后期还会继续增加。得益于 TDengine 企业版零代码数据接入能力,新增任务仅需复制并做少量参数调整即可完成,操作简便高效,整体接入过程较传统方式节省约 90% 的时间成本
  2. 数据查询性能高:开启数据库缓存功能后,能够实时获取每个设备点位最新值,毫秒级别即可返回结果
  3. 数据存储成本低:TDengine TSDB 具备出色的数据压缩能力,其二级压缩技术将数据视作无差别的二进制块进行再次压缩。与一级压缩相比,二级压缩的侧重点在于消除数据块之间的信息冗余。目前我们提供的服务器存储远远满足我们项目规划的 5 年数据存储,存储成本估算节省至少 60-70%
  4. 实时订阅:通过 TDengine 提供的 Flink CDC 实时订阅功能,能方便、高效的进行分析、告警等处理,给我们后期分析带来了极大的便利性。

后期规划

目前,我们正在对京能集团储能安全管理平台已经接入的 28 场站数据进行分析和优化,提高数据采集的可靠性和鲁棒性。未来我们会针对 TDengine TSDB 新版本和新功能进行持续跟踪,进一步开发 TDengine TSDB 的内在潜力和各种有效的功能。

近期我们关注到 TDengine 发布了新产品 TDengine IDMP,通过经典的树状层次结构组织传感器、设备采集的数据,建立数据目录,对数据提供情境化、标准化的处理,并提供实时分析、可视化等功能,接下来我们会进一步了解此产品在我们业务中的使用可能。

关于京能集团

北京能源集团有限责任公司是北京市人民政府出资设立的国有独资公司,肩负着保障首都北京能源安全可靠供应的重任。京能集团成立于 2004 年,由原北京国际电力开发投资公司和原北京市综合投资公司合并而成,2011 年、2014 年先后又与北京市热力集团有限责任公司、北京京煤集团有限责任公司实施合并重组,实现了产业链条融合互补。经过多年的资源整合,集团由单一能源产业发展为热力、电力、煤炭、健康文旅等多业态产业格局。2024 年在中国企业 500 强排名第 247 位,中国服务企业 500 强排名第 87 位。

作者:张海增