包含关键字 typecho 的文章

注意:需要绑卡验证。

  1. 注册创建项目
    可使用 github、谷歌账号、邮箱等方式进行注册,注册地址

注册登录后,进入下面的页面


  1. 添加服务






  2. 查看部署情况和节点




关于部署的镜像:
镜像是 fork 佬王的项目 nodejs-argo 后,自己创建固定隧道,添加自己的固定隧道后,通过 github actions 构建的镜像。佬王项目地址
固定隧道:服务重启后节点不会变
临时隧道:服务重启节点会变,需重新导入


📌 转载信息
原作者:
cainiaoxue
转载时间:
2026/1/19 18:16:45

近期米家 APP 自动化(离家 / 到家)失效问题,发现最新版本新增了如图设备选项,原有自动化没有勾选设备,所以不会触发家居设备状态变化。

需要删掉自动化的触发条件,重新添加 个人状态变化 - 离家 / 回家 - 单设备判断 - 勾选手机 / 设备 - 圈定范围 - 确定后保存自动化。


📌 转载信息
原作者:
BeeThor
转载时间:
2026/1/19 18:16:40

在这里插入代码片作者:高阔

1. 背景

这可能是全网第一篇完整讲解鸿蒙端使用CANN部署AI模型的文章, 满满干货。

社区作为用户交流、信息传递的核心载体,图片内容(如理财产品截图、投资经验分享配图、用户互动评论图片等)的展示质量直接影响用户的信息获取效率与平台信任感。从京东金融App社区的业务需求来看,当前用户上传图片普遍存在多样性失真问题:部分用户通过老旧设备拍摄的图片分辨率较低,部分用户为节省流量选择低画质压缩上传,还有部分截图类内容因原始来源清晰度不足导致信息模糊(如理财产品收益率数字、合同条款细节等),这些问题不仅降低了内容可读性,还可能因信息传递不清晰引发用户误解。

京东金融App团队已完成Real-ESRGAN-General-x4v3超分辨率模型在安卓端的部署,能够针对性提升评论区、内容详情页、个人主页等核心场景的图片清晰度,从视觉体验层面优化用户留存与互动意愿。

ESRGAN-General-x4v3模型在安卓端的部署,采用的是ONNX框架,该方案已有大量公开资料可参考,且取得显著业务成效。但鸿蒙端部署面临核心技术瓶颈:鸿蒙系统不支持ONNX框架,部署端侧AI仅能使用华为自研的CANN(Compute Architecture for Neural Networks)架构,且当前行业内缺乏基于CANN部署端侧AI的公开资料与成熟方案,全程需技术团队自主探索。接下来我会以ESRGAN-General-x4v3为例, 分享从模型转换(NPU亲和性改造)到端侧离线模型部署的全部过程。

2. 部署前期准备

2.1 离线模型转换

CANN Kit当前仅支持Caffe、TensorFlow、ONNX和MindSpore模型转换为离线模型,其他格式的模型需要开发者自行转换为CANN Kit支持的模型格式。模型转换为OM离线模型,移动端AI程序直接读取离线模型进行推理。

2.1.1 下载CANN工具

从鸿蒙开发者官网下载 DDK-tools-5.1.1.1, 解压使用Tools下的OMG工具,将ONNX、TensorFlow模型转换为OM模型。(OMG工具位于Tools下载的tools/tools\_omg下,仅可运行在64位Linux平台上。)



2.1.2 下载ESRGAN-General-x4v3模型文件

https://aihub.qualcomm.com/compute/models/real\_esrgan\_general\_x4v3下载模型的onnx文件.

注意: 下载链接中的a8a8的量化模型使用了高通的算子(亲测无法转换), CANN工具无法进行转换, 因此请下载float的量化模型。

下载后有两个文件:

•model.onnx文件 (模型结构): 包含计算图、opset版本、节点配置等,文件较小。

•model.data文件 (权重数据): 包含神经网络参数、权重等,文件较大。

现在我们需要把这种分离文件格式的模型合并成一个文件,后续的操作都使用这个。

合并文件:

请使用JoyCode写个合并脚本即可, 提示词: 请写一个脚本, 把onnx模型文件的.onnx和.data文件合并。

2.1.3 OM模型转换

1. ONNX opset 版本转换

当前使用CANN进行模型转换, 支持ONNX opset版本7\~18(最高支持到V1.13.1), 首先需要查看原始的onnx模型的opset版本是否在支持范围, 这里我们使用Netron(点击下载)可视化工具进行查看。
在这里插入图片描述



目前该模型使用的opset版本是20, 因此我们需要把该模型的opset版本转成18, 才可以用CANN转换成鸿蒙上可部署的模型。请使用JoyCode写个opset转换脚本即可, 提示词: 请写一个脚本, 把onnx模型文件的opset版本从20转换成18。



2. OM离线模型****

命令行中的参数说明请参见OMG参数,转换命令:

./tools/tools_omg/omg --model new_model_opset18.onnx --framework 5 --output ./model

转换完成后, 生成model.om的模型文件, 该模型文件就是鸿蒙上可以正常使用的模型文件

2.2 查看模型的输入/输出张量信息

部署AI模式时, 我们需要确认模型的输入张量和输出张量信息, 请使用JoyCode编写一个脚本, 确定输入输出张量信息, 提示词: 写一个脚本查看onnx模型的输入输出张量信息。

在这里插入图片描述

2.2.1 输入张量

BCHW格式, 是深度学习中常见的张量维度排列格式, 在图像处理场景中:

•B (Batch): 批次大小 - 一次处理多少个样本。

•C (Channel): 通道数 - 图像的颜色通道数。

•H (Height): 高度 - 图像的像素高度。

•W (Width): 宽度 - 图像的像素宽度。

由此可以得出结论, 该模型1个批次处理1张宽高为128*128的RGB图片(因为C是3,因此不包含R通道)。



2.2.2 输出张量

该模型1个批次输出1张宽高为512*512的RGB图片。



2.2.3 BCHW和BHWC格式的区别:

超分模型中的BCHW和BHWC是两种不同的张量存储格式,主要区别在于通道维度的位置:



BCHW格式(Batch-Channel-Height-Width)

◦维度顺序:[批次, 通道, 高度, 宽度]

◦内存布局:通道维度在空间维度之前

◦常用框架:PyTorch、TensorRT等

示例: 形状为 (1, 3, 256, 256) 的RGB图像

内存中的存储顺序: R通道的所有像素 -> G通道的所有像素 -> B通道的所有像素

tensor_bchw = torch.randn(1, 3, 256, 256)
访问第一个像素的RGB值需要跨越不同的内存区域
pixel_0_0_r = tensor_bchw[0, 0, 0, 0]  # R通道
pixel_0_0_g = tensor_bchw[0, 1, 0, 0]  # G通道  
pixel_0_0_b = tensor_bchw[0, 2, 0, 0]  # B通道

BHWC格式(Batch-Height-Width-Channel)

◦维度顺序:[批次, 高度, 宽度, 通道]

◦内存布局:通道维度在最后,像素的所有通道连续存储

◦常用框架:TensorFlow、OpenCV等

示例:形状为 (1, 256, 256, 3) 的RGB图像

内存中的存储顺序:像素(0,0)的RGB -> 像素(0,1)的RGB -> ... -> 像素(0,255)的RGB -> 像素(1,0)的RGB...

tensor_bhwc = tf.random.normal([1, 256, 256, 3])
# 访问第一个像素的RGB值在连续的内存位置
pixel_0_0_rgb = tensor_bhwc[0, 0, 0, :]  # [R, G, B]



3. 鸿蒙端部署核心步骤

3.1 创建项目

1.创建DevEco Studio项目,选择“Native C++”模板,点击“Next”。

在这里插入图片描述



2.按需填写“Project name”、“Save location”和“Module name”,选择“Compile SDK”为“5.1.0(18)”及以上版本,点击“Finish”。

在这里插入图片描述

3.2 配置项目NAPI

CANN部署只提供了C++接口, 因此需要使用NAPI, 编译HAP时,NAPI层的so需要编译依赖NDK中的libneural\_network\_core.so和libhiai\_foundation.so。



头文件引用

按需引用NNCore和CANN Kit的头文件。

#include "neural_network_runtime/neural_network_core.h"
#include "CANNKit/hiai_options.h"

编写CMakeLists.txt

CMakeLists.txt示例代码如下。

cmake_minimum_required(VERSION 3.5.0)
project(myNpmLib)

set(NATIVERENDER_ROOT_PATH ${CMAKE_CURRENT_SOURCE_DIR})

include_directories(${NATIVERENDER_ROOT_PATH}
                    ${NATIVERENDER_ROOT_PATH}/include)

include_directories(${HMOS_SDK_NATIVE}/sysroot/usr/lib)
FIND_LIBRARY(cann-lib hiai_foundation)

add_library(imagesr SHARED HIAIModelManager.cpp ImageSuperResolution.cpp)
target_link_libraries(imagesr PUBLIC libace_napi.z.so
    libhilog_ndk.z.so
    librawfile.z.so
    ${cann-lib}
    libneural_network_core.so
    )

3.3 集成模型

模型的加载、编译和推理主要是在native层实现,应用层主要作为数据传递和展示作用。模型推理之前需要对输入数据进行预处理以匹配模型的输入,同样对于模型的输出也需要做处理获取自己期望的结果

在这里插入图片描述

3.3.1 加载离线模型

为了让App运行时能够读取到模型文件和处理推理结果,需要先把离线模型和模型对应的结果标签文件预置到工程的“entry/src/main/resources/rawfile”目录中。

在这里插入图片描述



在App应用创建时加载模型:

1.native层读取模型的buffer。

const char* modelPath = "imagesr.om";
RawFile *rawFile = OH_ResourceManager_OpenRawFile(resourceMgr, modelPath);
long modelSize = OH_ResourceManager_GetRawFileSize(rawFile);
std::unique_ptr<uint8_t[]> modelData = std::make_unique<uint8_t[]>(modelSize);
int res = OH_ResourceManager_ReadRawFile(rawFile, modelData.get(), modelSize);

2.使用模型的buffer, 调用OH\_NNCompilation\_ConstructWithOfflineModelBuffer创建模型的编译实例

HiAI_Compatibility compibility = HMS_HiAICompatibility_CheckFromBuffer(modelData, modelSize);
OH_NNCompilation *compilation = OH_NNCompilation_ConstructWithOfflineModelBuffer(modelData, modelSize);

3.(可选)根据需要调用HMS\_HiAIOptions\_SetOmOptions接口,打开维测功能(如Profiling)。

const char *out_path = "/data/storage/el2/base/haps/entry/files";
HiAI_OmType omType = HIAI_OM_TYPE_PROFILING;
OH_NN_ReturnCode ret = HMS_HiAIOptions_SetOmOptions(compilation, omType, out_path);     

4.设置模型的deviceID。

size_t deviceID = 0;
const size_t *allDevicesID = nullptr;
uint32_t deviceCount = 0;
OH_NN_ReturnCode ret = OH_NNDevice_GetAllDevicesID(&allDevicesID, &deviceCount);

for (uint32_t i = 0; i < deviceCount; i++) {
    const char *name = nullptr;
    ret = OH_NNDevice_GetName(allDevicesID[i], &name);
    if (ret != OH_NN_SUCCESS || name == nullptr) {
        OH_LOG_ERROR(LOG_APP, "OH_NNDevice_GetName failed");
        return deviceID;
    }
    if (std::string(name) == "HIAI_F") {
        deviceID = allDevicesID[i];
        break;
    }
}

ret = OH_NNCompilation_SetDevice(compilation, deviceID);

5.调用OH\_NNCompilation\_Build,执行模型编译。

ret = SetModelBuildOptions(compilation);
ret = OH_NNCompilation_Build(compilation);

6.调用OH\_NNExecutor\_Construct,创建模型执行器。

executor_ = OH_NNExecutor_Construct(compilation);

7.调用OH\_NNCompilation\_Destroy,释放模型编译实例。



3.3.2 准备输入输出****Tensor

1.处理模型的输入,模型的输入为13128*128格式(BCHW) Float类型的数据, 需要把RGB 数据转成BCHW格式并进行归一化。

从图片中读取的RGB数据为BHWC,需要转换成模型可以识别的BCHW
/**
 * 把bhwc转成bchw
 */
uint8_t *rgbData = static_cast<uint8_t*>(data);
uint8_t *floatData_tmp = new uint8_t[length];
for (int c = 0; c < 3; ++c) {
    for (int h = 0; h < 128; ++h) {
        for (int w = 0; w < 128; ++w) {
            // HWC 索引: h * width * channels + w * channels +c 
            int hwc_index = h * 128 * 3 + w * 3 + c;
            // CHW 索引: C * height * width + h* width + W
            int chw_index = c * 128 * 128 + h * 128 + w;
            floatData_tmp[chw_index] = rgbData[hwc_index];
        }
    }
}
//归一化
float *floatData = new float[length];
for (size_t i = 0; i < length; ++i) {
    floatData[i] = static_cast<float>(floatData_tmp[i])/ 255.0f;
}

2.创建模型的输入和输出Tensor,并把应用层传递的数据填充到输入的Tensor中

// 准备输入张量
size_t inputCount = 0;
OH_NN_ReturnCode ret = OH_NNExecutor_GetInputCount(executor_, &inputCount);
for (size_t i = 0; i < inputCount; ++i) {
    NN_TensorDesc *tensorDesc = OH_NNExecutor_CreateInputTensorDesc(executor_, i);
    NN_Tensor *tensor = OH_NNTensor_Create(deviceID_, tensorDesc);
    if (tensor != nullptr) {
        inputTensors_.push_back(tensor);
    }
    OH_NNTensorDesc_Destroy(&tensorDesc);
}


ret = SetInputTensorData(inputTensors_, inputData);

// 准备输出张量
size_t outputCount = 0;
ret = OH_NNExecutor_GetOutputCount(executor_, &outputCount);

for (size_t i = 0; i < outputCount; i++) {
    NN_TensorDesc *tensorDesc = OH_NNExecutor_CreateOutputTensorDesc(executor_, i);
    NN_Tensor *tensor = OH_NNTensor_Create(deviceID_, tensorDesc);
    if (tensor != nullptr) {
        outputTensors_.push_back(tensor);
    }
    OH_NNTensorDesc_Destroy(&tensorDesc);
}
if (outputTensors_.size() != outputCount) {
    DestroyTensors(inputTensors_);
    DestroyTensors(outputTensors_);
    OH_LOG_ERROR(LOG_APP, "output size mismatch.");
    return OH_NN_FAILED;
}



3.3.3 进行推理

调用OH\_NNExecutor\_RunSync,完成模型的同步推理。

OH_NN_ReturnCode ret = OH_NNExecutor_RunSync(executor_, inputTensors_.data(), inputTensors_.size(),
                                                 outputTensors_.data(), outputTensors_.size());

说明

•如果不更换模型,则首次编译加载完成后可多次推理,即一次编译加载,多次推理。

•所有关于模型的操作, 均无法多线程执行。



3.3.4 获取模型输出并处理数据

1.调用OH\_NNTensor\_GetDataBuffer,获取输出的Tensor,在输出Tensor中会得到模型的输出数据。

// 获取第一个输出张量
NN_Tensor* tensor = outputTensors_[0];

// 获取张量数据缓冲区
void *tensorData = OH_NNTensor_GetDataBuffer(tensor);

// 获取张量大小
size_t size = 0;
OH_NN_ReturnCode ret = OH_NNTensor_GetSize(tensor, &size);

float *tensorDataOutput = (float*)malloc(size);
// 将tensorData的数据一次性复制到tensorDataOutput中
memcpy(tensorDataOutput, tensorData, size);



2.对Tensor输出数据进行相应的处理

把模型输出的BCHW转成BHWC, 并进行反归一化处理



//把模型输出的BCHW转成BHWC
float *outputResult = static_cast<float *>(tensorData);
float *output_tmp = new float[size/sizeof(float)];
for (int h = 0; h < 512; ++h) {
    for (int w = 0; w < 512; ++w) {
        for (int c = 0; c < 3; ++c) {
            output_tmp[h * 512 * 3 + w* 3 + c] = outputResult[c * 512 * 512 + h * 512 + w];
        }
    }
}
std::vector<float> output(size / sizeof(float), 0.0);
for (size_t i = 0; i < size / sizeof(float); ++i) {
    output[i] = output_tmp[i];
}
delete [] output_tmp;


 // 计算总的数据大小
size_t totalSize = output.size();

// 分配结果数据内存
std::unique_ptr<uint8_t[]> result_data = std::make_unique<uint8_t[]>(totalSize);

// 将float数据转换为uint8_t (反归一化)
size_t index = 0;
for (float value : result) {
    // 将float值转换为uint8_t (0-255范围)
    float scaledValue = value * 255.0f;
    scaledValue = std::max(0.0f, std::min(255.0f, scaledValue));
    result_data[index++] = static_cast<uint8_t>(scaledValue);
}

result_data 就是最终的超分数据,可以正常显示



4. 总结与技术展望

京东金融App在鸿蒙端部署Real-ESRGAN-General-x4v3超分辨率模型的完整实践过程,成功解决了ONNX模型到OM离线模型转换、BCHW与BHWC张量格式处理、以及基于CANN Kit和NAPI的完整部署链路等关键技术难题。

展望端智能的未来发展,随着芯片算力的指数级增长、模型压缩技术的突破性进展以及边缘计算架构的日趋成熟,端侧设备将从单纯的数据采集终端演进为具备强大推理能力的智能计算节点,通过实现多模态AI融合、实时个性化学习、隐私保护计算和跨设备协同等核心能力,将大语言模型、计算机视觉、语音识别等AI技术深度集成到移动设备中,构建起无需联网即可提供智能服务的自主计算生态,推动人机交互从被动响应向主动感知、预测和服务的范式转变,最终开启真正意义上的普惠人工智能时代。

作者:王元

1. 背景与痛点:存量代码的“多语言噩梦”

在前端开发中,将一个成熟的中文存量项目进行国际化多语言(i18n)改造,往往面临着以下困境:

•工作量巨大: 项目包含数百个 .vue/.js/.ts 等文件,散落着成千上万个硬编码的中文字符串。

•人工易错: 手动提取容易遗漏,且极其枯燥,极易产生 Copy/Paste 错误。

•命名困难: 为每一个中文词条想一个语义化的英文 Key(如 homePageTitle)不仅耗时,而且难以保证团队风格统一。

•维护成本高: 翻译文件(zh.ts/en.ts)的维护和代码中的替换需要同步进行,稍有不慎就会导致报错。

如果按照传统的人工查找替换方式,预计需要耗费数周的人力。为了打破这一僵局,我决定利用 JoyCode 结合我开发的 i18n-mcp 工具,打造一套自动化的国际化多语言解决方案。



2. 解决方案:JoyCode + i18n-mcp

我基于 MCP (Model Context Protocol) 开发了一个工具 i18n-mcp,通过 JoyCode 的 AI 能力来调度和执行以下三个核心步骤,实现了从“提取”到“替换”的全链路自动化。

流程图

以下是i18n-mcp的流程图(由JoyCode生成)

在这里插入图片描述

核心流程拆解

第一步:智能提取中文与去重

i18n-mcp 自动扫描所有源文件。利用正则或 AST(抽象语法树)精准识别代码中的中文字符串(包括 Template、Script 和 JSX 部分)。

•全量扫描(full-project-scan工具): 文件过多的时候,全量扫描会有问题。可以通过指定文件夹的方式,扫描该文件夹下面的文件。

•增量扫描(git-change工具):针对git变更的文件,进行扫描。精准定位变更文件,仅处理本次变更涉及的代码,大幅提升效率。

•智能去重: 对提取出的文本进行去重,确保相同的中文文案(如“确认”、“取消”)只生成一个 Key,避免冗余。

第二步:AI 辅助翻译与文件生成

•翻译缓存: 优先查询 数据存储层 中的 Translation Cache,已翻译过的文案直接复用,显著降低 Token 消耗并加速流程。

•自动化翻译: 提取的中文列表没有在缓存中或zh文件中的,被发送给 LLM,自动翻译成英文。

•语义化 Key 生成: 区别于传统 Hash 值,LLM 根据代码上下文(Context)自动生成符合语义的 Key(如将“请输入密码”生成为 pleaseInputPassword),提升代码可读性。

•文件落地: 自动在 lang 文件夹下生成标准的 zh.tsen.ts 文件。



生成示例: zh.ts: { "pleaseSelect": "请选择" } en.ts: { "pleaseSelect": "Please Select" }





第三步:一键代码替换

•变更预览 (Preview): 在实际修改前,可调用 preview-changes 工具展示即将变更的代码对比,确保修改符合预期。

•AST 节点替换: 使用 extract-and-replace 工具,将源代码中的硬编码字符串精准替换为国际化方法(如 $t('pleaseSelect'))。

•无损格式保持: 基于 AST 的替换策略能够完美保留原代码的缩进、换行和注释,修改后的代码无需二次 Lint 即可直接提交。





3. 成果与收益:从“数周”到“数小时”

通过引入 JoyCode + i18n-mcp 的实践,我在项目的国际化改造中取得了显著的成效:

📊 定量收益

维度传统人工方式JoyCode + i18n-mcp提升幅度
单页面改造耗时约 10-30 分钟< 1 分钟效率提升 90%+
词条遗漏率质量显著提升
变量命名耗时需人工构思AI 秒级生成完全自动化

💡 定性收益

1.解放生产力: 从枯燥的“搬运工”工作中解脱出来,可以专注于业务逻辑和核心功能的开发。

2.代码规范统一: AI 生成的 Key 风格高度统一(全驼峰),避免了“千人千面”的命名混乱。

3.可维护性增强: 建立了自动化的语言包管理机制,后续新增词条只需运行脚本即可。



4. i18n-mcp开发

i18n-mcp是我首次开发MCP,整体难度相对较低。对于前端部分,基于github模板进行开发,随后发布至公司NPM私服即可。

核心代码主要由JoyCode的编码功能协助完成。按照上述核心流程步骤通过问答交互的方式,引导JoyCode完成核心代码的开发工作。

整个i18n-mcp架构图如下所示(架构图亦由JoyCode生成)。

在这里插入图片描述



MCP配置如下

{
  "mcpServers": {
    "i18n-mcp": {
      "autoApprove": [],
      "disabled": true,
      "timeout": 180,
      "command": "npx",
      "type": "stdio",
      "transportType": "stdio",
      "args": [
        "-y",
        "@jd/i18n-mcp@latest"
      ],
      "env": {}
    }
  }
}

效果

配置之后,输入prompt “调用i18n-mcp的auto-i18n-process方法”

效果如下:

在这里插入图片描述

5. 总结

尽管目前 i18n-mcp 仍存在一些不足,例如在全面扫描大量文件时可能出现连接错误、翻译和替换结果不够准确等问题,仍需人工进行二次校验,但其在短时间内辅助开发的价值依然显著。在本次实践过程中,我主要通过 JoyCode 的交互式问答完成开发工作。JoyCode 不仅在代码补全方面发挥了重要作用,更凭借其强大的智能调度和自动化执行能力,成为高效处理复杂任务的核心中枢。结合 i18n-mcp 的开发,AI技术的深度赋能得以充分体现,大幅提升了开发的效率。

后续,我将持续研究 AI 在前端开发中的落地场景,充分发挥 AI 辅助开发的强大能力。通过深入探索和应用 AI 技术,进一步释放其在业务创新与效率提升方面的巨大潜力。

作者:桑伟杰

在这里插入图片描述

一、背景

当前在传统设计环节,设计师与研发之间存在大量的关于样式等视觉层的理解偏差,从而会出现大量的重复且无效的细节像素调整工作,由于项目时间紧、细节多设计走查环节会给各方角色诸多额外负担,在AI涌现后设计师尝试使用AI\_Code直接还原设计稿件,并且从传统交付静态界面设计图片转为交付可运行的实现方案,但在多数团队的认知里,AI\_Code仍停留在“氛围编程”阶段:能写出代码,但不符合框架规范,改动越多问题越多。通过不断摸索总结出一套稳定可用的 Design to Code (D2C) 解法:设计师借助 AI - IDE工具以及设计工具,通过MCP打通设计数据与研发数据,实现将设计稿直接转译为符合开发规范、可上线的前端代码,极大缩短交付周期。

D2C核心效果:设计师第一次拥有了对实现效果的“直接控制权”工程师从繁琐的像素级样式修改中解放出来团队整体迭代速度大幅提升

在这里插入图片描述

传统链路VSD2C链路

二、效果展示

案例1:PC端\_WMS6.0工艺配置

通过D2C流程从【组件生成】→【页面生成】,完成PC端工艺流程配置功能代码输出,实现了卡片拖拽、卡片状态自动变更、放置位置判断等核心功能;实现项目完整交付在测试环境中可直接运行,研发无需对前端代码进行修改,D2C代码输出总耗时0.5人/日,项目整体效率提升26%

在这里插入图片描述

WMS6.0\_Vue2.0实现效果

案例2:移动端\_PDA上架到容器

通过D2C流程链接设计数据与研发数据,【直接调用研发组件库代码】,按照代码仓库标准代码输出规范的前端页面,实现多页面跳转,逻辑判断,查询等核心功能,达到像素级还原并符合团队规范。D2C代码输出总耗时0.5人/日,项目整体效率提升50%

在这里插入图片描述

PDA\_Flutter实现效果

三、设计思维转变

D2C 并非“让设计师写代码”,而是促使设计师提升工程化思维:使设计师从传统的设计界面转向当前的设计容器,从而更好的让AI能够读懂设计数据实现D2C流程



传统设计思维 ➔ 工程化思维

传统设计思维:

步骤:1.设计全部视觉元素 ➔ 2.在页面进行元素相对位置的排布 ➔ 3.完成设计内容的产出

特点:元素之间仅包含相对关系没有结构层的动态属性,与页面实现的框架不一致

工程化思维:

步骤:1.设计组织分层关系 ➔ 2.设计分层容器布局规则 ➔ 3.设计容器所需设计元素 ➔ 4.完成设计内容的产出

特点:先有组织容器再有容器内容,组织容器具备布局规则等动态属性,更符合页面实现的框架。

四、实现路径

D2C的核心方法:D2C的核心法则是在保证幻觉与Token限制的条件下,通过稳定与可靠的方法,尽量多的将设计数据与研发数据进行链接,让AI充分理解两端数据并完成翻译

在这里插入图片描述

优劣势对比

稳定的D2C链接方法:

通过Figma MCP获取全部设计数据,包括颜色、圆角、间距、图层名称、文本信息、图片资源、代码数据、页面截图;将设计数据传递给AI-IDE工具,通过rules和Prompt控制设计数据解析标准,规定AI按照解析结果与代码数据对应,实现代码输出优势:即有设计元属性,又包含截图以及基础代码信息,AI可以更好的关联研发数据实现完美还原

并且针对不同页面构成,总结并执行不同的D2C步骤,用于还原设计内容,由于D2C的核心是链接,所以重点在于如何制造稳定链接,我们可以通过Code Connect或者让AI通过图层命名检索的方式实现稳定链接

在这里插入图片描述

D2C设计流程图

针对已有组件:

逻辑:通过调整设计组件名称与变体与研发组件名称和属性建立映射链接

步骤:提供界面截图 ➔ 工程师维护组件映射表 ➔ 设计师调整设计组件与研发组件结构一致 ➔ 还原页面内容

重点:工程师维护的组件映射表需包含组件名称及组件属性,设计师需保持设计组件与研发组件的结构相同

案例:PDADesign组件映射表

针对无组件场景:

逻辑:按照设计组件的名称与结构按照研发代码编写规则输出组件建立映射链接

步骤:设计师需采用工程化思维绘制组件 ➔ AI阅读代码仓库组件书写规范 ➔ 按照规范将设计组件输出为研发组件 ➔ 通过MCP获取设计组件并关联已经转为代码的研发组件

重点:与工程师对齐结构规范,若仓库中有Token数据再设计组件绘制时也需要保持一致



五、结语

D2C 是一次 团队角色和流程的升级,更是一场认知的跃迁:设计师不再只是交付界面,而是交付“可运行的实现方案”AI 成为设计师和工程师之间的“实时翻译器”最终实现:更快迭代、更少摩擦、更强共创。

在这条由 AI 驱动的设计到代码之路上,设计师不再是单纯的界面构建者,而是系统规则的定义者、智能逻辑的编织者。他们与 AI 一起,共同塑造一个能“理解意图、自动生成、持续学习”的设计生态。

当设计稿不再停留于视觉表达,而成为可以被机器直接理解的语言,设计师便跨越了传统的边界——从视觉思考者,走向了系统架构的参与者;从界面呈现者,走向了智能生产力的创造者。

AI 不会取代设计师,但会放大他们的思考维度,让人类的创造力从重复劳动中解放出来,去关注更本质的价值:如何让设计更智能、更高效、更具生命力。 在未来,D2C 不仅是“设计到代码”的捷径,更是“人机共创”的起点—— 让每一位设计师,都能成为 AI 时代的工程合作者,让设计真正成为推动产品智能演化的核心力量。

最近项目组做了一次安全项目,在联动讨论中,我们团队提出攻克一个一直被“模糊处理”的问题:如何在不引入复杂流量解密、不严重影响性能的前提下,更可靠地识别潜在的 C2通信行为。

其实在我看来这个问题并不新,在往常的项目中异常端口、可疑域名、频繁外联、策略命中日志等检测点都是这个问题。而这些信号单独存在时,误报率高,且很难形成可执行的处置结论。而本次讨论的关键转折点,正是在“出站 IP 本身是否具备明确恶意属性”这一角度上。

一、从“流量行为”转向“通信对象本身”的判断

在复盘既往处置案例时,阿孙提到一个共性:多数被确认为C2 的样本不是因为流量形态极其复杂,而是其通信目标本身就具备明显的基础设施风险特征,比如位于高风险国家或地区、IP 段频繁出现在僵尸网络、钓鱼、木马回连情报中、长期驻留在 VPS/云主机/异常 ASN、多项目/多情报源重复命中等

但这些信息在现有体系中是割裂的,地理信息在 IP 归属系统中,恶意标签在威胁情报平台中,而F火墙/EDR却只能看到“一个外联IP”,由此,我门讨论是否可以多采用IP离线库植入威胁情报,手动拓宽我们的“威胁情报”,提出这正是我们提出使用IP离线库和威胁情报进行融合。

二、 为什么必须引入 IP 离线库,而不是完全依赖情报 API

最初也有人提出直接调用在线威胁情报 API 即可,但在技术评估阶段,很快暴露出几个不可回避的问题:

1. 出站连接频率高,实时 API 成本与延迟不可控
在核心业务网段,单节点每天的外联 IP 数量级在百万级,实时查询并不可行。

2. 部分安全系统处于内网或半隔离环境
核心日志分析、审计系统无法直接访问外部情报接口。

3. IP 基础属性缺失会削弱判断上下文
单一“是否恶意”的结论,无法解释风险来源,例如:

1. 这是一个海外 IDC 正常业务 IP?

2. 还是位于高风险区域的小型自治系统?

3. 是否属于动态拨号或代理出口?

因此,我们的思路是先通过本地 IP 离线库快速完成“背景定性”,再用威胁情报完成“恶意定量”  。

三、 IP离线库在 C2 识别中的实际定位

在方案中,IP 离线库并不直接承担“是否 C2”的判断,而是用于回答以下关键问题:

1. 该出站 IP 的国家/地区/城市是否与业务场景匹配

2. 是否命中云厂商、数据中心、匿名网络、异常 ASN

3. 是否存在明显的跨国、跨区域跳变特征

4. 是否属于历史上极少访问、但突然频繁出现的地理位置

在我们实际部署中,使用的是IP数据云离线库,它覆盖IPv4/IPv6的本地IP 离线库,字段不仅包括国家、省市,还包含 ASN、运营商类型、IDC/住宅网络标识,方便后续识别C2通信,评估出站IP是否为已知恶意地址。
【场景:识别C2通信】评估出站IP是否为已知恶意地址,方法:IP离线库+威胁情报融合2.png

四、 威胁情报融合的方式,而非简单“命中即拦截”

第二层才是威胁情报,但这里我们刻意避免了“黑名单式”的粗暴使用方式。

具体做法是:

第一步,多源情报聚合:商业情报 + 社区情报 + 历史处置数据

第二步,情报置信度分级:区分活跃 C2、历史恶意、关联基础设施

第三步,时间衰减机制:避免因陈旧情报导致长期误判

当某个出站 IP在 IP 离线库中表现为、海外小众地区、云主机 / VPS、非业务白名单 ASN,该IP同时在威胁情报中命中已知 C2 或僵尸网络关联,被多个情报源低频标注,我们才将其提升为  “高置信度可疑 C2 通信”  ,进入阻断或人工复核流程。

五、 实际落地的处理流程拆解

在最终方案中,整体流程被拆解为清晰的四个阶段:

1. 出站连接采集
从F火墙、NDR、EDR 中统一采集目的 IP、端口、协议、频率。

2.IP 离线库快速画像

1. 地理位置

2. ASN / 网络类型

3. 是否云主机 / IDC

4. 是否偏离正常业务访问分布

3.威胁情报关联评分

1. 是否命中恶意标签

2. 情报来源数量

3. 最近活跃时间

4. 策略与响应联动

1. 自动阻断(高置信度)

2. 降权监控(中置信度)

3. 留痕审计(低置信度)

这种方式的一个明显变化是我们不再“猜测流量是不是 C2”,而是在判断“这个通信对象是否值得被当作 C2 对待”  。

项目讨论中最被认可的是①不依赖深度包检测;②不影响现有网络性能;③可解释性强,适合审计与复盘;④能在离线、内网环境稳定运行。【场景:识别C2通信】评估出站IP是否为已知恶意地址,方法:IP离线库+威胁情报融合1.png

MES制造执行系统是精益生产的重要支撑工具,它能够帮助企业实现生产过程的数字化、智能化和精细化管理,提高生产效率和质量,降低生产成本,为企业创造更大的价值。

MES制造执行系统是一种集生产计划、物料管理、工艺执行、设备控制、质量管理等功能于一体的软件系统。它通过实时监控生产过程、收集并分析生产数据,为管理层提供决策支持,同时为操作层提供指导和帮助。

image.png

制造行业在生产过程中所面临的挑战

1、无法预测生产线需求使用

随着工厂订单量的增多,在生产前,人工往往不知道或无法快速预知在一条产线中应该做哪个订单的那些工序,所需量是多少,要提前准备何种物料。

2、不能及时掌握生产情况

每天的生产数据需要人工事后填写和统计,管理层不能及时掌握订单在车间的最新生产情况。无法及时得知当前每个生产订单、每个工序的生产进度如何、哪些未按计划开始、哪些未按计划完工、特急件是哪些、良品数、不良品数分别多少等等问题。

3、没有对比,无竞争感

因为没有即时的目视指令和电子看板,现场人员没有绩效对比和竞争,没有紧迫感。不知道当前谁的效率高?谁的效率低?

4、无法及时得知当前机台产线情况

当前哪些机台产线是在工作或是停机?机台、产线有多少时间在生产,多少时间在停转和空转?利用率是多少?这些都是无法及时得知,只能通过记录得知。

5、无法及时得知致错原因

无法及时得知过去几小时之内,车间出现最多的不良品是什么原因造成的?不良率有多高等问题。

6、无法追溯源头

用户投诉产品不良时,如何立即追溯该产品的历史生产过程信息?如:是谁、在什么时间、在哪台机器上、用什么材料做的?该产品加工过程经过了哪些工序?当时的工艺参数是怎样的等问题。

MES系统对企业生产管理有哪些改进?

在精益生产的背景下,MES制造执行系统发挥着至关重要的作用,具体来说,MES制造执行系统在精益生产中的改善企业生产的五大方法:

image.png

1、全面的生产能力平衡分析

在企业生产过程中,不同的人员和设备都有着不同的生产能力,不同的产品有着不同的生产能力需求,若采用同一种生产任务分配模式,容易造成车间生产能力与完成计划所需能力之间的不协调,直接导致车间生产现场混乱,且难以合理调整各工作中心的生产分配量。

MES系统拥有最直观的图形和文字,可以为企业提供最精准的设备任务负荷分析、部门/班组任务负荷分析等数据。通过详细的数据逐级查询和分析,还能够帮助企业计划和调度人员进行生产任务的外协和均衡,并实现最优的生产计划排程。

2、高效的生产计划管理

在没有使用MES系统之前,企业生产信息的获取,只能通过人员填写的报表反馈或者电话汇报。这样,信息获取不够及时,影响企业管理层及时有效地下达管理指令,制约了管理措施的有效实施。

MES系统能够全面管理企业订单的整个生产流程,通过生产信息的采集和多维度的看板展现,让每个订单、每个零件、每道工序等实时信息,及时展现给车间管理人员,使企业各级领导更加便捷地掌握生产任务执行状况,并迅速做出生产决策,确保实现生产任务按时、按节点完成。

3、便捷的任务派工管理

生产订单的执行往往需要通过多道不同的工序来完成。未使用MES系统时,开始阶段可能对生产任务执行的进度比较了解,但一旦工序并行作业,就无法完成工单的追踪和管理了。MES系统拥有强大的任务动态调度能力,能够及时响应生产现场各种状态的变化。

在生产计划完成后,系统还能够自动生成任务派工单,并通过条码扫描向生产现场自动输送加工程序、零件图纸、工艺指导文档等,大大节约工作人员在生产现场来回奔波的时间。

4、完善的产品质量管理

制造企业把产品质量视为企业的生命,全面的质量管理保障高品质的产品。MES系统通过对原材料、生产过程以及在用户使用中的产品的整个生命周期进行数字化、网络化和动态化的管理,实现对产品质量的管控和追溯。

这样,MES系统就可以通过持续不断的改进,帮助企业完善全面的质量管理体系,进而有效控制生产成本。

5、最优的车间库存管理

库存管理是每个企业在生产过程中都不可或缺的环节。合理的库存控制,可以有效避免生产停滞,为企业建立良好的生产环境。MES系统支持原材料、成品、半成品、工具等的库存管理,所有流程通过条码扫描操作,既准确又便捷。

MES系统彻底改善了企业车间生产管理流程,实现车间管理无盲点,生产管控一体化的新模式。其最前沿的信息技术在各大制造企业间得到强烈反响,并成为支撑制造企业高速发展的内在动力。

成功实施MES系统需先完善管理基础

将MES系统导入到企业的运作体系之中,企业需要先完善管理基础,根据自身情况选择好“合身”的MES软件系统,而后采用科学的实施方法充分准备,才能促使MES正式运行、发挥效用。

要想成功实施MES,企业必须先在管理上下功夫——与MES密切相关的工作,包括车间环境、职责分工以及人员保障等方面。

1、定置,改善车间环境

定置,是指通过对生产和工作环境的分析,把生产和工作需要的物品按照工艺的需要科学地确定位置。定置管理,则是指对现场物品定置的设计、组织、实施、控制,使现场管理达到科学化、规范化、经常化的全过程。定置管理为生产者在较短的时间内用较低的成本制造出高质量产品提供良好的客观条件。通过定置管理,理顺物流,可以为MES的实施提供良好的车间环境。

2、合理分工,明确职责

“计算机能够解决一切管理问题。”——这是相当一部分企业领导在实施MES时的一个误区。事实上,许多企业面临的管理问题是不可能靠计算机来解决的,必须靠企业自身通过科学的组织、严格的规章及有效的控制来解决。计算机只能通过信息的获取与加工、一定的流程控制来支持企业管理思想的贯彻。有些企业的组织结构不合理、职能相互重叠,其结果是责任不清、相互扯皮。

这一方面妨碍了MES的顺利实施,另一方面也难以保证MES正常高效地运行。因此,在实施MES时,必须对企业的业务流程进行合理重组,去除重叠的部门职能,减少无效劳动,合理分工、明确责职。这样既可以简化MES软件的权限设置和流程控制,又能够保证信息处理的及时性,为MES的实施提供组织保证。

3、提供人员保证

MES系统实施,通常涉及到计算机人员、企业管理人员、车间现场操作人员和具体业务人员等方面。不仅涉及面广,而且各类人员的文化水平、业务能力、计算机应用水平也参差不齐。因此,为了保证MES的顺利实施,必须对相关人员进行足够的培训。对不同类型、不同层次人员的培训方式应有所不同。

实际上,在整个MES实施过程中,培训工作是贯彻始终的。不仅要在实施准备阶段进行原理培训,而且在实施准备、模拟运行与试运行、切换运行、新系统运行过程中也要进行有关培训,如软硬件产品培训、系统管理员培训和持续扩大培训等。只有通过培训让企业员工对MES软硬件产品有了一定的了解,才能够保证系统最终的顺利实施和应用。

【声明】:以上所发文章仅供大家学习参考,请不要作商业用途;MES系统的专业性很强,文中难免有错误,一旦发现,请联系我们及时更正;文中部分图片源于网络,侵删。

最后感谢图片内容的提供方:织信MES,该厂商专注企业信息化系统管理10年余,坚持传播生产管理知识,自研低代码开发底座,基于B/S架构,可帮助企业快速构建生产管理所需的各项功能,可根据客户实际作业流程和管理要求实现定制化开发,系统内置自定义开放接口OpenAPI,能够对接所有的管理信息系统,广泛应用于国内外各行各业。

为了标准化 iOS 和 Android 平台的事件工具,Uber 工程团队重新设计了其移动分析架构,解决了所有权分散、语义不一致和跨平台数据不可靠的问题,目标是简化工程工作,提高数据质量,并为骑手和司机应用的产品和数据团队提供可靠的洞察。

 

根据 Uber 工程师的说法,移动分析对于决策、功能采用和衡量用户体验至关重要。随着应用程序和团队的增长,工具变得分散。功能团队独立定义并发出事件,共享 UI 组件常常缺乏分析钩子,类似的交互在不同的团队中有不同的记录方式。其结果是,超过 40%的移动事件属于自定义或临时事件,这不仅增加了分析复杂度,还降低了聚合指标的可信度。

 

为了应对这些挑战,工程师将核心分析职责从功能级代码转移到了共享基础设施。他们与产品、设计和数据科学团队合作,定义了点击、展示和滚动等标准事件类型。这些事件基于共享模式通过代码生成,在 UI 组件层进行监控,通过集中式报告层输出,由后端服务进行数据增强,并通过 Uber 的分析管道进行消费。

Uber 移动分析系统架构(图片来源:Uber博客

 

其中一项关键决策是将分析逻辑嵌入到平台级 UI 组件中。工程师引入了分析构建器,用于管理事件生命周期、元数据附件和事件发出逻辑,使功能团队可以开展标准化的分析工作而无需编写自定义工具。他们对包含 100 个展示记录组件的示例应用做了性能测试,结果显示,CPU 使用率或帧率没有退化,这是在性能敏感设备上推广该工具的先决条件。

ImpressionAnalyticsBuilder 类事件生成的数据流图(图片来源:Uber博客

 

该平台还实现了常见的元数据收集。应用级元数据(如接送地点或餐厅 UUID)会自动记录,而事件类元数据(包括列表索引、行标识符、滚动方向和视图位置)则由 AnalyticsBuilder 捕获。界面通过 Thrift 模型实现了标准化,可以确保容器视图、按钮和滑块的日志记录保持一致。

分析元数据金字塔概览(图片来源:Uber博客

 

为了验证平台有效性,工程师通过新旧 API 对两个功能进行了 dual-emitted 分析。查询结果表明,跨平台事件量、元数据及界面是匹配的,而像滚动开始/停止计数和视图位置等语义也保持了一致。试点应用揭示了平台和记录方法的差异,并突出了列表增强的好处——将多个行事件合并为单个标准化事件,简化了查询并提高了可测试性。功能团队还采用了可见性检查机制,减少了自定义实现。

 

试点应用之后,Uber 分析团队进行了旧事件到标准化 API 的迁移,使得产品团队可以专注于他们的路线图。在需要支持的地方,他们创建了自动化脚本,扫描 iOS 和 Android 代码,评估高优先级事件,并生成适合迁移的列表。平台团队还添加了一个 linter,目的是拦截使用非标准 API 新建的点击或展示事件,防止它们进一步漂移。根据工程师的反馈,跨平台一致性得到提升,元数据和语义保持了统一,工具代码量减少,展示计数更可靠,并实现了可扩展的开箱即用 UI 交互覆盖功能。

 

展望未来,Uber 工程师正在通过组件化增强分析功能,为按钮和列表等 UI 元素分配唯一 ID,以便标准化事件命名和元数据,进一步减少开发人员的工作量。

原文链接:

https://www.infoq.com/news/2026/01/uber-mobile-analytics-platform/

二十年,是一个坐标。从 Web 2.0 的萌芽,到移动互联网的爆发,再到云原生时代的重塑,D2 技术大会伴随开发者走过了整整二十载风雨。

今天,我们站在了一个更加宏大的分水岭。AI 不再是遥远的科幻逻辑,它正以一种近乎“重构”的姿态,系统性地改写终端技术的底层范式:从代码生成的协作,到架构设计的逻辑,再到交互体验的边界。

第 20 届 D2 技术大会,年度主题定为——「AI 新」。

它既是我们的时代判断,也是我们的集体宣言。它是 AI 驱动的创新,也是终端人对技术边界追逐的热爱之新

此刻,我们正式向全球开发者、架构师、技术领袖及创新实践者发出邀请:来 D2,分享你对 AI 时代终端技术的独到见解,共同定义下一个二十年的生产力!


七大核心专场,期待你的真知灼见

我们渴望真实工程中的突破,珍视深度思考后的落地,让技术回归解决问题的初衷。

01 AI Coding:从写代码开始,重构工程本身

这是本届 D2 的主干专场。AI 正在从“辅助助手”升级为“协作伙伴”。

征集方向:

  • AI Agent 编程工具的研发与设计

侧重 Agent 型 AI 编程工具在本地与远程形态下的架构与产品设计。征集议题包括 IDE 深度集成、上下文采集与记忆管理、代码库索引检索、任务规划与工具调用、执行沙箱与权限控制、审计与回放、可观测性、成本/延迟优化与多模型策略等。重点关注可靠性与可控性:减少误改、支持规范化交付与团队协作。

  • AI-Native 开发实践

聚焦真实项目中 AI 编程的可复用方法。征集包含 Spec 驱动开发(结构化需求/验收标准/契约/测试)、AI 编程 Workflow 探索(从需求到 PR/发布的流水线)、以及团队级 AI 驱动研发实践(流程改造、提示/模板沉淀、质量门禁、效率与质量度量、失败复盘)。重点是“怎么做得稳、做得快”。

  • AI Coding 前沿研究与技术趋势

关注下一代 AI Coding 的关键技术与趋势。征集议题包括长上下文与复杂依赖、代码语义理解与程序分析结合、自动化评测与基准、对齐与安全、多智能体协作、可靠性与可解释性增强等。重点探讨研究如何走向工程落地与可验证的效果提升。

02 AI 创新体验:当交互正在被重写

终端是 AI 被感知的最前线。交互范式的巨变已经发生。

征集方向:

  • UI 范式重塑

探讨从 GUI 向 LUI 或 AUI 的代际演进。聚焦 Agent 驱动下的意图识别、动态 UI 生成及个性化界面即时构建。征集议题包括主动交互设计、多 Agent 协作下的用户反馈回路、以及如何利用 AI 简化复杂业务流的操作门槛。

  • 空间智能体验

聚焦多模态感知与空间计算的深度融合。涵盖视觉、语音、触觉在 3D/XR 环境下的集成交互,以及 AI 驱动的实时场景理解与数据可视化。重点探讨如何利用空间智能让数字世界更符合自然认知,实现高沉浸感的智能反馈。。

  • 具身交互探索

关注 AI 进入物理世界后的交互挑战,从 AI Wearables、AI PC 到机器人具身智能。探讨硬件约束下的自然语言处理、人机交互(HRI)实践及环境感知反馈。重点关注如何通过端侧智能赋予硬件产品生命力,解决真实场景下的交互痛点,探索用户真正愿意买单的终端新价值点。

03 AI 语言 & 框架:模型时代,语言与框架如何进化

当 AI 成为“默认能力”,底层技术如何适配?

征集方向:

  • 语言与编译器演进

探讨编程语言如何适配“人机共写”新常态。征集议题涵盖 LLM 友好型语法设计、智能化类型系统、AI 辅助的编译优化与静态分析等。重点研究如何通过语言特性的进化,提升 AI 生成代码的质量、安全性与复杂逻辑表达力。

  • Agent 框架重构

当 Agent 成为系统编排者,探讨传统框架的抽象层重塑。征集议题涵盖声明式意图驱动的框架设计、元数据驱动的界面自动生成、以及为 AI 重新设计的组件模型。重点关注框架如何提供更高级别的抽象,以支持多 Agent 在复杂业务逻辑中的无缝协作、状态同步与逻辑自治。

  • 智能运行时与内核

推动 AI 从工具层下沉为系统的核心能力。聚焦内置 AI 推理能力的运行时引擎、模型与容器/内核的深度集成,以及 AI 驱动的动态资源调度策略。重点探讨端云协同背景下,如何模糊开发与运行、模型与逻辑的边界,实现具备自适应、自进化能力的智能运行基座。

04 AI 智能测试:质量与效率,不再只能二选一

测试不再是滞后的环节,而是 AI 介入最深、收益最显性的战场。

征集方向:

  • 用例生成与自愈

探讨利用 LLM 实现测试全生命周期的自动化。征集议题包括基于语义理解的单元/集成测试生成、复杂业务场景下的测试数据合成,以及 UI 自动化脚本的自愈(Self-healing)机制。

  • 风险洞察与优化

聚焦利用 AI 提升质量保障的精准度与效率。征集议题涵盖基于变更分析的智能回归测试缩减、线上异常的实时检测与根因定位,以及多维度的质量风险预测模型。探讨如何利用算法在海量代码变更中快速锁定高风险区域,解决快速迭代与质量稳定性之间的核心矛盾。

  • 治理与角色演进

关注 AI 引入后测试流程与组织效能的系统性重构。核心议题包括 AI 测试工具的 ROI 分析、人机协同模式下的 QA 职责重定义,以及在规模化工程中构建“默认内置 AI”的质量防线。探讨如何通过技术赋能,打破质量与效率的零和博弈,重塑技术团队的质量文化与评价体系。

05 AI 智能生产:从工具走向生产系统

关注 AI 在真实业务落地时的“最后一公里”。

征集方向:

  • 业务深度嵌入

探讨 AI 如何从外部辅助工具进化为业务逻辑的核心。寻找在复杂业务场景中的落地架构案例,关注如何处理模型输出的不确定性以交付“确定性”结果。重点探讨 AI 对传统业务流程的深度重构,在提升用户价值的同时,确保生产系统的稳定性、安全性与商业收益。

  • 规模化生产交付

聚焦 AI 从原型验证(PoC)走向规模化交付的工程拐点。征集议题涵盖支持大规模 AI 应用的工程底座、端到端 AI 生产平台的演进、以及 FinOps 成本分析与合规治理。探讨如何构建标准化的平台能力,支撑 AI 跨团队、跨业务的高效迁移与持续稳定运行,实现技术普惠。

  • 全链路协同提效

关注覆盖需求、设计、交付及运维的 AI 全链路闭环。核心议题包括新一代人机协作下的流程重塑、领域专用 Agent 的生产环境编排,以及科学的效能度量方法。探讨如何通过技术与组织的双重演进,实现软件生产体系的跨越式提效,将 AI 潜能真正转化为规模化的实际业务产能。

06 终端技术:重构 AI 时代的性能底座

底层基础设施如何承载高算力与高响应需求?

征集方向:

  • 架构适配与演进

探讨终端架构如何重构以深度兼容 AI 能力,重点研究如何调整传统的软件拓扑结构,以支持 AI 在终端侧的无缝集成、高效编排与复杂的应用状态管理,提升端侧智能的响应实时性。

  • 运行时与性能优化

聚焦通过底层技术突破 AI 运行的性能瓶颈。征集议题涵盖面向 AI 指令集优化的编译器技术、异构算力的极致加速实践,以及轻量化端侧容器演进。探讨如何通过运行时与系统内核的深度协同,在有限的硬件资源限制下,实现极致的推理速度与能效比。

  • 端侧工程与协同

核心议题包括模型量化、蒸馏与剪枝的终端实战、端云协同推理架构,以及隐私安全约束下的端侧学习。探讨如何构建高效的端云配比方案,在保障响应速度与数据隐私的同时,实现计算成本与用户体验的帕累托最优。

07 一人公司:技术人的个体放大器

这是最具时代情绪的专场。AI 正在让“超级个体”成为可能。

征集方向:

  • 全栈生产力飞跃

探讨 AI 如何打破专业壁垒,实现“一个人就是一支团队”。分享利用 AI 协同完成从需求定义、全栈开发、交互设计到市场增长的全链路实践。

  • 商业闭环与实战

聚焦超级个体的商业化落地与可持续经营之道。征集独立开发者的 AI 实战案例,涵盖极致成本控制下的产品生存策略、AI 辅助的商业决策与自动化运营。探讨在 AI 时代,个体如何构建轻量化、高利润的商业模式,并成功应对从单兵作战到规模化营收的真实挑战。

  • 职业路径重构

探讨从“专项开发者”向“产品主理人”转型的思维重构、AI 时代的个人品牌经营,以及个体长期竞争力的构建。研究在组织边界日益模糊的未来,技术人如何利用 AI 工具集寻找更具自主性的创作路径,定义下一代极简且高效的职业范式。


顶尖出品人矩阵:为议题深度护航

本届 D2 各专场由行业资深专家领衔,他们不仅是评审者,更是议题的“合伙人”。

我们寻找的不仅是一个演讲者

更是一个在 AI 工程深水区挣扎过、思考过、最终破局的见证者

  • 隐风| 淘天集团-用户 &内容终端技术负责人

  • 云谦| 蚂蚁集团-高级前端技术专家

  • 悟石| 淘宝闪购-消费者端技术负责人

  • 渚薰| 前淘宝互动游戏专家

  • 偏右| 蚂蚁集团-支付宝体验技术前端平台负责人

  • 张磊| 字节跳动 Web Infra 技术负责人

  • 泠乐| 淘天集团-淘宝终端质量负责人

  • 茹炳晟| CCF TF 研发效能 SIG 主席 / 复旦大学 CodeWisdom 成员

  • 达峰| 蚂蚁集团-平台体验技术部负责人

  • 穆宸| AliExpress-终端技术负责人 / D2 负责人

  • 永霸| 淘天集团-交易终端技术负责人

  • 崔红保| DCloud CTO / uni-app 跨平台框架负责人

  • 秦粤| 阿里云-数据库高级前端专家

  • 梓骞 | 启智云图 CEO / Lovrabet 产品创始人

出品人寄语:“在 D2,我们致力于将前沿的 AI 实践提炼为系统化的技术范式。我们期待与你一同锚定 AI 时代的工程坐标,让每一份实战洞察都汇聚成定义未来的行业基准。”


🌟 为什么来到 D2 舞台

  1. 顶尖技术影响力:D2 是国内终端技术的风向标,线下规模 2000+,线上覆盖数十万专业开发者。

  2. 二十周年里程碑:参与第 20 届这一极具纪念意义的盛会,与业内最具创新精神的技术人同频共振。

  3. 常态化社区联动:优质内容将同步至稀土掘金、InfoQ、AI 产品榜等联合承办方平台,获得持续的行业曝光与认可。

🗓️ 议题提交指南

  • 截止时间: 2026 年 1 月 23 日(请关注官网最新动态)

  • 议题要求:内容具有前瞻性、实战性或深度思考;拒绝纯广告,强调技术细节与真实的踩坑经验

图片

扫码提交议题

二十年是一个里程碑,更是重新出发的起点。在「AI 新」的浪潮中,让我们一起,用 AI 驱动创新,用终端之心热爱创新。


*本文由极客时间企业版代发

度小满引入 Apache Doris 替换原有 Greenplum,实现整体查询效率提升 82%,与此同时,集群缩减 2/3、年省数百万的巨大效益。本文将分享度小满如何基于 Doris 从 0 到 1 构建超大规模数据分析平台,并围绕平滑迁移、异地多活容灾等方面,分享实践经验。

本文整理自度小满 Doris 数据库负责人汤斯在 Doris Summit 2025 中的演讲,并以演讲者第一视角进行叙述。

度小满金融(原百度金融)作为一家覆盖现代财富管理、支付、金融科技等多板块的科技公司,数据的分析处理对其极为重要,已经深度融入业务生命周期的每个环节,是进行风险控制、商业决策、用户体验优化及运营提效的基石。

随着业务高速发展,度小满原有基于 Greenplum 搭建的 OLAP 平台,逐渐暴露出三大痛点:

  • 规模与稳定性瓶颈:存储已接近饱和,扩容至百余台已接近硬件规模的承载上限,如果继续扩容,将面临更严重的稳定性挑战。

  • 性能与体验不佳:Greenplum SQL 查询执行速度慢,且经常出现 “计算时间远小于排队时间” 的情况,严重影响业务分析效率。

  • 缺失技术支持:当前使用的 Greenplum 6 版本技术架构已显得陈旧,并且 2024 年 Greenplum 宣布将停止开源,后续的技术支持与迭代升级将无法保障。

为了应对这些痛点,度小满金融迫切寻找更为高效、稳定且具备现代化技术架构的数据处理解决方案,以支持其未来的业务发展。

Apache Doris:高吞吐、快查询

面对日益增长的业务体量与复杂多变的分析需求,选用一个高效、可靠的数据库系统,已成为支撑业务稳健发展与快速创新的关键。Apache Doris 以其出色的性能表现与高度灵活的架构,成为众多场景下的优选方案。为深入验证其在海量数据与复杂分析场景中的能力,我们展开了一系列性能测试,关键结果如下:

  • 查询性能:在 1TB TPC-DS 标准测试集中, Apache Doris的查询速度约是 Greenplum 6 的 20-30 倍

  • 导入性能:在基于 Flink 写入的 TPS 测试中,基于单分片导入,压测最大 TPS 为:5000W/s

  • JSON 数据处理:针对新推出的 Variant JSON 数据类型,测试显示:存储 2-3 万 Key 时,其空间占用仅为普通 JSON 的 1/10 甚至更低,查询效率则提升至 10 倍以上

综上可知,Apache Doris 在写入吞吐、响应速度及存储效率上表现卓越,有力证明了其应对大规模、实时化、半结构化数据分析挑战的坚实技术基础。

基于 Apache Doris 的大规模数据分析平台

在上述详实的选型调研之后,我们决定采用 Apache Doris 替代原有 Greenplum 集群,构建超大规模数据分析平台。

为验证 Apache Doris 在真实业务场景中的表现,我们先进行了小范围试点,部署了少量 Doris 集群,并先行接入几个关键业务方。试点期间,系统在性能、稳定性和易用性方面获得高度评价。基于这一积极反馈,我们稳步扩展 Doris 集群规模,最终在效率与成本上实现大幅提升:

  • 整体效率:端到端分析任务耗时从 274 秒降至 47 秒,效率提升 82%,任务超时查杀比例从 1.3%骤降至 0.11%,降幅达 91%,彻底解决高峰期排队问题实现 0 排队,使分析师的工作不再因拥堵而中断,体验和生产力均有极大提升。

  • 集群成本:在同等资源成本下, Doris 仅以 1/3 的集群数量即可提供与 Greenplum 同等的服务能力,存储性能提升 200%。截至目前,已完成 百余台原 Greenplum 服务器的清退工作,以更少的硬件资源支撑了更高的计算与存储需求,实现年度硬件成本节约数百万元

从 0-1 数据平台建设经验

我们基于 Apache Doris 成功替换了 Greenplum,完成了从 0-1 的数据平台重构,覆盖架构设计、数据流转与业务协同的系统性工程。以下将围绕快速平滑迁移、异地多活容灾与全链路生态集成三个核心环节,展开具体实践。

01 快速迁移

为保障业务连续性与数据安全,我们开发了自动化迁移工具 SqlGlot,将大规模数据从原有 GP 集群迁移至 Doris 集群。整个过程历经半年,累计迁移 PB 级规模数据,全程业务无感知。

  • 表结构迁移:在表结构迁移阶段,团队从 GP 系统中导出表结构及相关元数据,借助 SqlGlot 工具实现字段映射与语法适配,并在此基础上完成分区构建与分桶策略设计,确保每个分桶数据量控制在 1G~3G 的合理范围内。该流程最终成功转换超过 20,000 张表,并保障了所有表的分区与分桶结构符合业务与性能要求。

  • 表数据迁移:我们通过分布式导出将 GP 数据并行迁移至 Doris 机器,并基于 Doris 官方推荐的 Stream Load 进行并发控制,以文件流式加载的方式高效导入数据至 Doris 集群。整个过程累计完成 PB 级规模数据迁移,稳定支持了 5000+ 次数据同步任务。

  • SQL 迁移:为解决因业务规模庞大、场景复杂而导致的官方工具语法支持不全的问题,我们基于 SqlGlot 并结合正则匹配能力,将 PostgreSQL SQL 高效转换为 Doris SQL。整个迁移流程包括“转换成功 → 执行成功 → 数据一致” ,累计完成约 47 万个 SQL 的转换,实现 95% 的执行成功率 与 92% 的数据一致率

02 异地双机房灾备

为保障数据安全并实现集群高可用,我们基于 Apache Doris 构建了异地双机房灾备架构,确保数据与服务具备跨机房容灾与双活能力。核心设计如下:

我们将所有 Doris 集群节点均匀部署于 A 与 B 两个异地机房,通过设置 tag.location 属性明确节点所属机房。用户账号按机房绑定,访问请求通过轮询机制自动分配,实现负载均衡(例如首次请求路由至 A 机房,第二次则路由至 B 机房)。建表时通过配置 location 参数,确保每张表在双机房各保留 2 个副本,从而达成数据异地双活与故障自动切换。

关键配置示例

  1. 设置节点机房标签

alter system modify backend ”BE1:9050" set ("tag.location" = "group_a");alter system modify backend ”BE2:9050" set ("tag.location" = "group_b");
复制代码

  1. 建表时指定双机房副本分布

CREATE TABLE ubevent (ts DATETIME, uid INT, ...) DUPLICATE KEY(ts) DISTRIBUTED BY HASH(uid) BUCKETS 10PROPERTIES ("replication_allocation" = "tag.location.group_b: 2, tag.location.group_a: 2");
复制代码

03 生态整合

为构建高效、稳定、易用的数据平台,我们还围绕 Apache Doris 进行系统性生态整合:

  • 计算引擎无缝集成:通过 Doris 官方提供的 Spark Connector 与 Flink Connector,实现了与现有 Spark、Flink 计算引擎的高效对接,保障了数据流水线稳定运行。

  • 运维体系化与自动化:集成 Prometheus、Grafana 及 Doris Manager,构建了覆盖监控、告警、管理与调优的自动化运维体系,全面提升集群稳定性与运维效率。

优化经验

为进一步提升数据平台的效率及资源利用率,在实际落地过程中,围绕集群、负载、存储等多维度总结了以下优化经验:

01 集群隔离

当前我们有多个 Doris 集群,为合理承接不同业务方的接入需求,我们主要依据业务成本与稳定性要求两大维度进行评估与路由。通常而言,稳定性越高,对应成本也越高。

新建集群时,稳定性最优,但相应成本也最高。为在成本与稳定性之间取得平衡,我们大多场景是基于 Workload Group 资源硬隔离方案,对 CPU 与内存进行资源组级别的隔离,有效减少不同业务负载间的资源竞争。若业务对稳定性的要求超出共享集群所能提供的范围,则仍需要通过新建独立集群来满足。

02 存储压力

在 Apache Doris 的落地与运维过程中,我们曾面临因业务快速增长带来的高达 80%-90% 的磁盘存储压力。针对这一问题,进行了一系列优化:

  • 控制表生命周期:部分业务或因对动态分区相关语法不熟悉,未主动采用该策略。为此,集成动态分区的参数配置,简化了开发难度,并提供统一注册入口,业务开发人员仅需选择是否开启、保留天数即可。

  • 修改压缩格式:将默认压缩算法从 LZ4 切换为 ZSTD。实测表明,存储空间平均节省约 50%,虽带来约 20%~30% 的 CPU 与内存负载上升,但整体 ROI 仍然较高。

  • 存储指标监控告警:为预防因误操作或异常行为导致的存储激增,建立了针对“人员”与“表”双维度的监控体系。环比分析业务人员数据占用趋势及单表每日增长量,可自动识别异常(如单日增长飙升至日常 10 倍),并及时触发告警及通知。

  • Hive 与 Doris 打通:在基于 Kerberos 认证的 Hive 环境中,对 Doris Hive Catalog 功能进行了二次开发,实现跨系统的直接数据访问,无需依赖 Flink 等同步工具,简化了架构并提升了数据使用效率。

03 负载均衡

为确保系统在负载高峰期的稳定运行,特别是应对异常 SQL 与大查询带来的资源压力,应对措施如下:

  • 双机房负载均衡:基于已有的异地双机房架构,通过轮询机制实现业务流量在 A 与 B 机房之间的自动分发:首个 SQL 请求路由至 A,次个请求则导向 B,以此循环,确保双机房负载均衡,避免单点资源过载。

  • SQL 参数限制:通过 enable_query_memory_overcommit = falseexec_mem_limit = 256 * 1024 * 1024 * 1024 等参数将最大占用内存限制为 256G,避免集群被打满,后续计划降至 60G。

  • Workload 资源队列动态调整:基于任务类型划分资源队列,配置 CPU 的软隔离和内存的硬隔离,并支持错峰调度。比如:例行任务通常在夜间执行,为其创建专门资源队列,数据分析等公共任务大多在白天执行,将配置更大的资源队列,随着白天/夜间需求的变化动态调整资源。此外,依据各队列负载设定并行度与并发数,控制任务排队时长。

  • 异常 SQL 拦截:实时识别与拦截异常 SQL,避免其影响 BE 节点稳定性。初期使用 Doris 内置正则规则进行拦截,但规则复杂导致 CPU 开销上升。为此,我们将拦截逻辑外移至平台层执行,以避免正则匹配及超大 JOIN 导致的 CPU 负载过高。

04 集群稳定性

随着集群规模不断扩大,保障 FE、BE 节点稳定性成为运维工作的核心挑战,为此,我们构建了以下保障体系:

  • 分层触达+全维度覆盖:根据不同指标优先级设置通知电话、短信、飞书提醒,P0 监控准确率 ≥80%;

  • 自动异常处理:为 FE 和 BE 的宕机重启设置了自动化处理方案,在识别到服务卡住时,系统会自动重启进程。此外,对于磁盘掉线,将自动下线故障盘并触发副本补齐。

我们同时采用对战分析、火焰图和日志查看等方法进行详细记录,以便后续调优。此外,编写了 SOP 手册,涵盖不同场景的应对措施,并进行了异常处理演练。

结束语

截至目前,我们已搭建 3 个基于 Doris 2.1.10 版本的线上集群,其中最大规模的集群达万 core 级别、上百 TB 内存和 PB 级磁盘。目前仍在扩容中,计划在年底前新增百余台 CN 节点和数十台 Mix 节点。未来,我们将重点关注并探索以下能力:

  • 存算分离:重点关注 Doris 3.X 版本的存储分离架构,推动落地实践。

  • 湖仓一体:全面打通数据湖与数据仓库,目前已小规模试点 Paimon;此外,针对数据外置场景,计划通过异步物化视图提升查询性能。

  • 智能物化视图探索:引入语义建模与 AI 智能分析,降低研发与业务沟通门槛,并对智能推荐与模板化方案进行探索与实践。

Agoda 近日分享了他们如何将多个独立的数据管道整合为一个基于Apache Spark的集中式平台,以消除财务数据中的不一致性的。该公司构建了一个多层质量保障框架,结合自动化校验、基于机器学习的异常检测以及与上游团队签订的数据契约(data contracts),确保用于财务报表和战略规划的财务指标准确无误,同时每天处理数百万笔预订交易。

 

这一问题源于一个典型的企业架构模式,Agoda 的数据工程、商业智能(BI)和数据分析团队各自开发了独立的财务数据管道,并使用不同的逻辑和定义。尽管这种做法在初期提供了简单性和清晰的责任边界,却导致了重复计算和全公司范围内指标不一致的问题。正如 Agoda 工程团队的Warot Jongboondee所解释的那样,这些差异“可能对 Agoda 的财务报表产生实质性的影响”。

独立的财务数据管道 (图片来源)

 

为了解决这一挑战,Agoda 推出了名为 Financial Unified Data Pipeline(FINUDP)的统一财务数据管道,作为销售、成本、收入和利润率等关键财务数据的单一事实来源(single source of truth)。该系统基于Apache Spark构建,每小时向下游团队提供更新,用于对账和财务规划。整合过程耗费了大量的精力:协调产品、财务和工程等多个利益相关方就统一的数据定义达成共识耗费了很长的时间;初始版本的运行时间长达五小时,后通过查询优化和基础设施调整,最终缩短至约 30 分钟。

财务统一数据管道(FINUDP)的架构(图片来源)

 

Agoda 的质量保障框架采用了多重防御机制。自动化校验会检查数据表中的空值、数值范围约束和数据完整性。一旦关键业务规则校验失败,管道会自动暂停,以防处理可能错误的数据。团队使用Quilliup来比对源表与目标表。与上游团队的数据契约(Data Contracts)会明确约定数据格式、内容和质量要求,任何违反契约的行为会立即触发告警。机器学习模型会持续监控数据模式,识别潜在异常。三级告警系统确保通过邮件、Slack 通知以及内部工具实现快速响应,如果数据更新延迟,系统会自动升级至 Agoda 的 7×24 小时网络运营中心(Network Operations Center,NOC)。

 

这一做法契合了行业的整体趋势。根据最新的行业调研,64%的组织将数据质量问题视为最大挑战。Gartner 指出,数据契约正成为“管理、交付和治理数据产品的一种日益流行的方式”。这类生产者与消费者之间的正式协议,明确定义了数据模式(schema)和质量标准。

 

当然,集中化也带来了明确的权衡取舍(trade-offs)包括,开发速度下降,因为任何变更现在都需要对整个管道进行测试。数据依赖,管道必须等待所有上游数据集就绪后才能启动。详尽的文档编写和广泛的干系人共识拖慢了落地进度,却建立了跨团队的信任。Jongboondee 表示,集中化“要求在每个环节都进行更紧密的协作和审慎的变更管理”。

 

目前,该系统已经实现了 95.6%的可用性,并朝着 99.5%的目标迈进。所有变更均需经过影子测试(shadow testing),也就是,在合并请求中,新旧版本的查询会并行运行,并自动比对结果。此外,还有一个与生产环境完全一致的专用 staging 环境,允许团队在正式发布前进行充分的验证。

 

FINUDP 项目表明,当企业处理大规模关键业务数据时,正逐步从零散的、事后补救式的质量检查,转向架构层面强制执行的、端到端的可靠性体系。这种体系优先保障数据的一致性与可审计性,而非单纯的开发速度,这一转变在财务数据日益支撑报表生成、机器学习模型训练和监管合规流程的今天,显得尤为关键。

 

原文链接:

How Agoda Unified Multiple Data Pipelines Into a Single Source of Truth

Cursor 推出了一种新方法,用于减少发送给大语言模型(LLM)的请求上下文的大小。这种方法名为动态上下文发现(Dynamic Context Discovery),它摒弃了以往在请求开始时就包含大量静态上下文的做法,转而让智能体(agent)按需动态检索所需信息。这种方式不仅显著减少了 token 消耗,也避免了将可能令人困惑或无关的细节混入上下文。

 

为了实现动态上下文发现,Cursor 采用了五种不同的技术。这些技术有一个共同特点,即以文件作为 LLM 工具的主要接口,使内容能够由智能体动态存储和获取,而不是一次性塞满有限的上下文窗口。

随着编码智能体能力的快速提升,文件已成为一种简单而强大的基础原语(primitive)。相比引入另一种尚无法完全适应未来需求的抽象层,使用文件是一种更安全、更务实的选择。

 

Cursor 使用的第一项技术是将大规模输出(比如,shell 命令或其他工具的输出)写入文件,确保关键信息不会因上下文截断而丢失。随后,智能体可根据需要使用tail等命令读取文件末尾的内容。

 

其次,针对上下文过长时被摘要压缩而导致信息丢失的问题,Cursor 会将完整的交互历史保存到文件中,使智能体能在后续需要时检索缺失的细节。同样,领域特定的能力被存放在文件中,智能体可通过Cursor内置的语义搜索工具动态发现相关文件。

 

对于 MCP 工具(Model Context Protocol 工具),传统做法是在请求初始阶段就加载所有 MCP 服务器提供的工具描述,而 Cursor 修改为仅传递工具名称。当任务实际需要某个工具时,智能体才会动态拉取其完整定义。这一策略大幅降低了 token 总量:

智能体现在只接收少量的静态上下文(包括工具名称列表),并在任务需要时主动查询具体工具。在一项 A/B 测试中,对于调用了 MCP 工具的运行实例,该策略平均减少了 46.9%的总 token 使用量(结果具有统计显著性,但方差较大,这取决于所安装 MCP 服务器的数量)。

此外,这种方法还带来一个额外的优势,那就是智能体可以监控每个 MCP 工具的状态。例如,比如某个 MCP 服务器需要重新认证,智能体可以及时通知用户,而不是完全忽略该问题。

 

最后,所有终端会话的输出会同步到文件系统。这使得智能体能更轻松地回答用户关于命令失败原因的问题。同时,通过将输出存入文件,智能体可使用 grep 等工具仅提取相关的信息,进一步压缩上下文规模。

 

在 X 上,用户 @glitchy 指出,虽然减少token是重要目标,但是尚不清楚这种动态机制是否会增加延迟。@NoBanksNearby 则认为,动态上下文发现“在同时运行多个MCP服务器时,对开发效率提升巨大”。@casinokrisa也对此表示赞同:

token 数量几乎减少了一半,既降低了成本,又加快了响应速度,尤其是在多服务器场景下。

 

最后,@anayatkhan09提出了可能的优化方向

下一步应该是向用户开放动态上下文策略,让我们能针对不同代码仓库调整优化的激进程度,而不是对所有工具一视同仁。

 

据 Cursor 官方表示,动态上下文发现功能将在未来几周内向所有用户开放。

原文链接:

AI-Powered Code Editor Cursor Introduces Dynamic Context Discovery to Improve Token-Efficiency

二十年,是一个坐标。从 Web 2.0 的萌芽,到移动互联网的爆发,再到云原生时代的重塑,D2 技术大会伴随开发者走过了整整二十载风雨。

今天,我们站在了一个更加宏大的分水岭。AI 不再是遥远的科幻逻辑,它正以一种近乎“重构”的姿态,系统性地改写终端技术的底层范式:从代码生成的协作,到架构设计的逻辑,再到交互体验的边界。

第 20 届 D2 技术大会,年度主题定为——「AI 新」。

它既是我们的时代判断,也是我们的集体宣言。它是 AI 驱动的创新,也是终端人对技术边界追逐的热爱之新

此刻,我们正式向全球开发者、架构师、技术领袖及创新实践者发出邀请:来 D2,分享你对 AI 时代终端技术的独到见解,共同定义下一个二十年的生产力!


七大核心专场,期待你的真知灼见

我们渴望真实工程中的突破,珍视深度思考后的落地,让技术回归解决问题的初衷。

01 AI Coding:从写代码开始,重构工程本身

这是本届 D2 的主干专场。AI 正在从“辅助助手”升级为“协作伙伴”。

征集方向:

  • AI Agent 编程工具的研发与设计

侧重 Agent 型 AI 编程工具在本地与远程形态下的架构与产品设计。征集议题包括 IDE 深度集成、上下文采集与记忆管理、代码库索引检索、任务规划与工具调用、执行沙箱与权限控制、审计与回放、可观测性、成本/延迟优化与多模型策略等。重点关注可靠性与可控性:减少误改、支持规范化交付与团队协作。

  • AI-Native 开发实践

聚焦真实项目中 AI 编程的可复用方法。征集包含 Spec 驱动开发(结构化需求/验收标准/契约/测试)、AI 编程 Workflow 探索(从需求到 PR/发布的流水线)、以及团队级 AI 驱动研发实践(流程改造、提示/模板沉淀、质量门禁、效率与质量度量、失败复盘)。重点是“怎么做得稳、做得快”。

  • AI Coding 前沿研究与技术趋势

关注下一代 AI Coding 的关键技术与趋势。征集议题包括长上下文与复杂依赖、代码语义理解与程序分析结合、自动化评测与基准、对齐与安全、多智能体协作、可靠性与可解释性增强等。重点探讨研究如何走向工程落地与可验证的效果提升。

02 AI 创新体验:当交互正在被重写

终端是 AI 被感知的最前线。交互范式的巨变已经发生。

征集方向:

  • UI 范式重塑

探讨从 GUI 向 LUI 或 AUI 的代际演进。聚焦 Agent 驱动下的意图识别、动态 UI 生成及个性化界面即时构建。征集议题包括主动交互设计、多 Agent 协作下的用户反馈回路、以及如何利用 AI 简化复杂业务流的操作门槛。

  • 空间智能体验

聚焦多模态感知与空间计算的深度融合。涵盖视觉、语音、触觉在 3D/XR 环境下的集成交互,以及 AI 驱动的实时场景理解与数据可视化。重点探讨如何利用空间智能让数字世界更符合自然认知,实现高沉浸感的智能反馈。。

  • 具身交互探索

关注 AI 进入物理世界后的交互挑战,从 AI Wearables、AI PC 到机器人具身智能。探讨硬件约束下的自然语言处理、人机交互(HRI)实践及环境感知反馈。重点关注如何通过端侧智能赋予硬件产品生命力,解决真实场景下的交互痛点,探索用户真正愿意买单的终端新价值点。

03 AI 语言 & 框架:模型时代,语言与框架如何进化

当 AI 成为“默认能力”,底层技术如何适配?

征集方向:

  • 语言与编译器演进

探讨编程语言如何适配“人机共写”新常态。征集议题涵盖 LLM 友好型语法设计、智能化类型系统、AI 辅助的编译优化与静态分析等。重点研究如何通过语言特性的进化,提升 AI 生成代码的质量、安全性与复杂逻辑表达力。

  • Agent 框架重构

当 Agent 成为系统编排者,探讨传统框架的抽象层重塑。征集议题涵盖声明式意图驱动的框架设计、元数据驱动的界面自动生成、以及为 AI 重新设计的组件模型。重点关注框架如何提供更高级别的抽象,以支持多 Agent 在复杂业务逻辑中的无缝协作、状态同步与逻辑自治。

  • 智能运行时与内核

推动 AI 从工具层下沉为系统的核心能力。聚焦内置 AI 推理能力的运行时引擎、模型与容器/内核的深度集成,以及 AI 驱动的动态资源调度策略。重点探讨端云协同背景下,如何模糊开发与运行、模型与逻辑的边界,实现具备自适应、自进化能力的智能运行基座。

04 AI 智能测试:质量与效率,不再只能二选一

测试不再是滞后的环节,而是 AI 介入最深、收益最显性的战场。

征集方向:

  • 用例生成与自愈

探讨利用 LLM 实现测试全生命周期的自动化。征集议题包括基于语义理解的单元/集成测试生成、复杂业务场景下的测试数据合成,以及 UI 自动化脚本的自愈(Self-healing)机制。

  • 风险洞察与优化

聚焦利用 AI 提升质量保障的精准度与效率。征集议题涵盖基于变更分析的智能回归测试缩减、线上异常的实时检测与根因定位,以及多维度的质量风险预测模型。探讨如何利用算法在海量代码变更中快速锁定高风险区域,解决快速迭代与质量稳定性之间的核心矛盾。

  • 治理与角色演进

关注 AI 引入后测试流程与组织效能的系统性重构。核心议题包括 AI 测试工具的 ROI 分析、人机协同模式下的 QA 职责重定义,以及在规模化工程中构建“默认内置 AI”的质量防线。探讨如何通过技术赋能,打破质量与效率的零和博弈,重塑技术团队的质量文化与评价体系。

05 AI 智能生产:从工具走向生产系统

关注 AI 在真实业务落地时的“最后一公里”。

征集方向:

  • 业务深度嵌入

探讨 AI 如何从外部辅助工具进化为业务逻辑的核心。寻找在复杂业务场景中的落地架构案例,关注如何处理模型输出的不确定性以交付“确定性”结果。重点探讨 AI 对传统业务流程的深度重构,在提升用户价值的同时,确保生产系统的稳定性、安全性与商业收益。

  • 规模化生产交付

聚焦 AI 从原型验证(PoC)走向规模化交付的工程拐点。征集议题涵盖支持大规模 AI 应用的工程底座、端到端 AI 生产平台的演进、以及 FinOps 成本分析与合规治理。探讨如何构建标准化的平台能力,支撑 AI 跨团队、跨业务的高效迁移与持续稳定运行,实现技术普惠。

  • 全链路协同提效

关注覆盖需求、设计、交付及运维的 AI 全链路闭环。核心议题包括新一代人机协作下的流程重塑、领域专用 Agent 的生产环境编排,以及科学的效能度量方法。探讨如何通过技术与组织的双重演进,实现软件生产体系的跨越式提效,将 AI 潜能真正转化为规模化的实际业务产能。

06 终端技术:重构 AI 时代的性能底座

底层基础设施如何承载高算力与高响应需求?

征集方向:

  • 架构适配与演进

探讨终端架构如何重构以深度兼容 AI 能力,重点研究如何调整传统的软件拓扑结构,以支持 AI 在终端侧的无缝集成、高效编排与复杂的应用状态管理,提升端侧智能的响应实时性。

  • 运行时与性能优化

聚焦通过底层技术突破 AI 运行的性能瓶颈。征集议题涵盖面向 AI 指令集优化的编译器技术、异构算力的极致加速实践,以及轻量化端侧容器演进。探讨如何通过运行时与系统内核的深度协同,在有限的硬件资源限制下,实现极致的推理速度与能效比。

  • 端侧工程与协同

核心议题包括模型量化、蒸馏与剪枝的终端实战、端云协同推理架构,以及隐私安全约束下的端侧学习。探讨如何构建高效的端云配比方案,在保障响应速度与数据隐私的同时,实现计算成本与用户体验的帕累托最优。

07 一人公司:技术人的个体放大器

这是最具时代情绪的专场。AI 正在让“超级个体”成为可能。

征集方向:

  • 全栈生产力飞跃

探讨 AI 如何打破专业壁垒,实现“一个人就是一支团队”。分享利用 AI 协同完成从需求定义、全栈开发、交互设计到市场增长的全链路实践。

  • 商业闭环与实战

聚焦超级个体的商业化落地与可持续经营之道。征集独立开发者的 AI 实战案例,涵盖极致成本控制下的产品生存策略、AI 辅助的商业决策与自动化运营。探讨在 AI 时代,个体如何构建轻量化、高利润的商业模式,并成功应对从单兵作战到规模化营收的真实挑战。

  • 职业路径重构

探讨从“专项开发者”向“产品主理人”转型的思维重构、AI 时代的个人品牌经营,以及个体长期竞争力的构建。研究在组织边界日益模糊的未来,技术人如何利用 AI 工具集寻找更具自主性的创作路径,定义下一代极简且高效的职业范式。


顶尖出品人矩阵:为议题深度护航

本届 D2 各专场由行业资深专家领衔,他们不仅是评审者,更是议题的“合伙人”。

我们寻找的不仅是一个演讲者

更是一个在 AI 工程深水区挣扎过、思考过、最终破局的见证者

  • 隐风| 淘天集团-用户 &内容终端技术负责人

  • 云谦| 蚂蚁集团-高级前端技术专家

  • 悟石| 淘宝闪购-消费者端技术负责人

  • 渚薰| 前淘宝互动游戏专家

  • 偏右| 蚂蚁集团-支付宝体验技术前端平台负责人

  • 张磊| 字节跳动 Web Infra 技术负责人

  • 泠乐| 淘天集团-淘宝终端质量负责人

  • 茹炳晟| CCF TF 研发效能 SIG 主席 / 复旦大学 CodeWisdom 成员

  • 达峰| 蚂蚁集团-平台体验技术部负责人

  • 穆宸| AliExpress-终端技术负责人 / D2 负责人

  • 永霸| 淘天集团-交易终端技术负责人

  • 崔红保| DCloud CTO / uni-app 跨平台框架负责人

  • 秦粤| 阿里云-数据库高级前端专家

  • 梓骞 | 启智云图 CEO / Lovrabet 产品创始人

出品人寄语:“在 D2,我们致力于将前沿的 AI 实践提炼为系统化的技术范式。我们期待与你一同锚定 AI 时代的工程坐标,让每一份实战洞察都汇聚成定义未来的行业基准。”


🌟 为什么来到 D2 舞台

  1. 顶尖技术影响力:D2 是国内终端技术的风向标,线下规模 2000+,线上覆盖数十万专业开发者。

  2. 二十周年里程碑:参与第 20 届这一极具纪念意义的盛会,与业内最具创新精神的技术人同频共振。

  3. 常态化社区联动:优质内容将同步至稀土掘金、InfoQ、AI 产品榜等联合承办方平台,获得持续的行业曝光与认可。

🗓️ 议题提交指南

  • 截止时间: 2026 年 1 月 23 日(请关注官网最新动态)

  • 议题要求:内容具有前瞻性、实战性或深度思考;拒绝纯广告,强调技术细节与真实的踩坑经验

图片

扫码提交议题

二十年是一个里程碑,更是重新出发的起点。在「AI 新」的浪潮中,让我们一起,用 AI 驱动创新,用终端之心热爱创新。


*本文由极客时间企业版代发

前言 最近n8n的漏洞挺多的,恰好看到https://xz.aliyun.com/news/91090这篇25年的Git 节点 RCE 漏洞分析,一查发现还有个CVE-2026-21877,于是来了兴趣 1. 漏洞概述 N8N 是一个开源的工作流程自动化平台。在0.121.2及以下版本中,经过认证的攻击者可能能够使用n8n服务执行恶意代码。这可能导致全面入侵,并可能影响自托管和n8n云实例。这个问题在1.121.3版本中修复了。


2. 漏洞分析
在受影响的版本中,Git节点的文件写入功能存在根本性的路径验证缺陷:

Plain Text

复制代码
const repositoryPath = this.getNodeParameter('repositoryPath', itemIndex, '') as string;

这里直接获取了用户完全控制的路径,且没有任何安全检查

Plain Text

复制代码
if (operation === 'clone') {
try {
await access(repositoryPath);
} catch (error) {
await mkdir(repositoryPath);
}
}

根据用户输入的路径创建目录,从而创建恶意目录结构,直接将我们的文件不用经过检验上传至.git/hook/目录下执行 该漏洞最精妙之处在于它与n8n早期安全加固措施的对抗。在2025年,n8n曾修复一个类似的Git节点漏洞(CVE-2025-65964),并在1.119.2版本中引入了默认禁用Git钩子执行的防护机制。 修复原理

然而,CVE-2026-21877完全绕过了这一防护。原因在于: Git钩子执行优先级:Git在执行钩子时,会优先检查仓库本地.git/hooks/目录,然后才会考虑core.hooksPath配置。直接写入.git/hooks/的脚本具有最高优先级。 配置作用域差异core.hooksPath配置通常作用于全局或系统级,但Git在仓库本地执行操作时,对.git/hooks/的检查是硬编码行为,不受该配置影响。 信任边界差异core.hooksPath机制允许重定向钩子位置,是Git的安全特性之一。但攻击者直接写入.git/hooks/,这是Git最原始的钩子机制,享有最高级别的信任。
5. 修复方案分析 5.1 官方修复(n8n 1.121.3)

在Git节点操作前新增调用,利用现有通用函数检查仓库路径,若越权则阻断,以此修复漏洞。
参考: https://github.com/Ashwesker/Ashwesker-CVE-2026-21877 https://www.venusgroup.com.cn/new_type/aqtg/20260108/29069.html
https://xz.aliyun.com/news/91090

今天看到微博上有一个热点事件, 是一个关于某公司做的一个监控员工离职倾向的软件,从截图中可以看到员工访问招聘网站的次数,还有投递的简历以及搜索的关建词等等信息,通过这些信息分析员工的离职倾向。然后我发一个微博,说了一下,我以前工作过的公司无论外国公司还是中国公司都有这样的情况,收到一些人来问我相关的情况,所以,我想还是写篇文章详细地说一下,我对这种事情的看法。

本文分成下面个部分:

  • 公司监控员工的技术手段有哪些?
  • 为什么要监控员工?
  • 外企和国企有什么不一样?
  • 我对此事的看法

目录

技术手段

下面是我经历过的几个手段:

1)通过网络嗅探的方式。也就是说,你只要上了公司的网络,你个人设备上的通讯信息就可以被人以网络抓包+分析的方式进行分析。当然,这样的手段已经不怎么好用了,因为现在的网络基本上都是HTTPS加密的,网络嗅探的方式只能知道你访问了什么IP,对于其中的数据是没有办法知道的。

2)通过使用公司提供的软硬件工具。你使用公司的电子邮箱,浏览器(或是公司的代理服务器),通讯工具(包括语音电话),手机办公应用……等来处理你的个人事宜的时候,必然会被监控。这样,你只需要不要使用公司的软件来处理自己的私事就好了。

3)通过安装一个监控程序。这个是最可怕的了,因为无论你加不加密都没用了。一般来说,你不安装这个程序,你就没有办法连上网络,包括公司内网和外网。这个监控程序,会收集你电脑或手机上能够收集的到的所有的信息,比如,你的网络信息,按键操作,录屏,软件数据……等等。

4)办公区监控。我见过的还有使用摄像头,在会议室中安装声音和视频监控设备,对整个办公区内发生所有的事情进行监控。

5)通过爬虫。通过爬虫分析员工的社交平台上的各种言论,包括招聘网站。除了公司需要分布和自己相关的舆情,同样也开始监控员工的行为和价值观等。这已经不是监控隐私信息了……

公司监控的目的

公司监控的目的最早就是为了防止自己公司内的数据和信息外泄,所以,他们害怕自己的员工访问了什么不合适的网站,或是下载了什么有恶意的软件,或是不小心发错了邮件。另外一些公司也会使用外包人员,所以,对于外部编制的人员更需要有信息泄漏防范的安全需求。当然,也害怕有一些商业间谍或是自己的员工被收买了窃取公司内部的敏感信息。尤其是对于一些本身就是做数据的公司,如我以前呆过的Thomson Reuters,这家公司主要是卖金融数据的,所以,对信息泄漏是非常注重的,其就是需要在员工的电脑上安装监控软件。

还有一些劳动密集型的工作,比如在Amazon里的仓库里工作的人,公司会监控员工的工作量,以此来评估员工的工作绩效。对于用监控软件来评估程序员的工作量,我到今天仅见过监控外包人员的,在中国,外包人员需要使用甲方的电脑进行签到和签退,以及相关的工作。除了上述的信息安全目前,还能够看到员工的工作时长的情况。

所以,一般来说,公司监控的目的主要是为了自己的信息安全,还有员工的工作量评估,一般来说,不会涉及员工的隐私

但是,随着收集的数据越来越多,有些公司发现还可以做更多的事,比如,上述的员工离职倾向的分析。还有一些公司还会收集员工在外网的数据,比如你在社交平台上的各种言论,来分析你对公司的忠诚度和你的价值观取向……我个人觉得这些已经令人不耻了。

外企与国企不同之处

我经历过的公司中,外国公司和中国公司都有监控的经历,这里说一下他们的不一样之处。最大的不一样的地方是,外国公司会让你有知情权,而中国公司则完全没有

我记得我进入Thomson Reuters 公司的时候,公司要求签署一份监控的知情的同意书,其中用中英文写的,就是说,你授权公司监控你的如下这些信息:1)上网记录,2)下载的软件,3)工作电脑,4)公司的座机电话,5)会议室和办公区的语音和视频监控……大概有两页A4纸,然后也说明了这些数据公司仅用于信息安全的风控,不用于个人隐私分析等等……并且会符合法律要求保护员工的这些数据不外泄……这些条款都经得起法律的推敲。这样的协议是需要员工签字的,并且对双方都有法律约束的。

中国的公司则不会告诉你他们会监控你哪些数据,而这些数据拿来做什么。 我记得我在某公司工作的时候,就有员工发现自己访问自己的gmail的录屏被公司收集后的愤怒……

我对此事的看法

一方面,我对于公司通过使用监控软件监控员工的行为我是能够理解的,但是,应该让员工有知情权,并和员工明确一个监控的信息和范围,包括收集的数据的用途和安全措施,以及数据多长时间销毁的协议。如果没有这个协议的话,我觉得本质上就是一种流氓行为。

另一方面,针对监控员离职的倾向来说,我实在不知道有什么意义?公司你知道了又能如何呢?你是要找员工作思想工作,还是要给员工更好的待遇,还是直接开掉?如果你对自己的企业有信心,你就不必担心员工会离开,如果你的企业有问题,你为什么不把心思花在建设自己的企业上来呢?安装这样的监控软件对于企业没有什么帮助,反而只会让你的企业的形象更low……

再仔细想想,员工有一万种方法泄漏你公司的信息,无论你怎么监控,只要他想,他总是能够找到方法的,不是么?如何让找到或是培养有职业操守的员工,如何管理自己企业的商业信息,如何建立一个更好的企业文化让员工更有归属感,成为企业的共同体,一同维护共同利益,为企业着想,这不才是公司真正应该干的事吗?!监控员工充分暴露了这样的企业没有一个好的企业文化,不懂得高级的管理,所以,只能靠监控这样的手段来管理企业了……这样的企业不去也罢了。

众所周知手机版的豆包输入法很好用,但是阿,没有电脑版~
试了一圈其他的语音工具在 windows 的场景下的适配都不是很好,影响 vibecoding

突然想起用的豆包客户端好像有语音识别功能,试试了一下。但是得自己手动点击或者按回车,文字插入还有点问题。很不方便阿,于是决定手搓一个工具,解放双手。

基于豆包语音识别的增强辅助的工具,帮助实现主流语音输入法效果。
提供两种输入模式(按着说、自由说),可查看实时语音效果,有自动纠正功能,英文支持友好,识别效果不满意支持清空重录

演示效果:
【开源】PC 端 豆包语音输入工具,Windows 豆包语音输入增强工具3
效果还是很 nice 的,现在是我的主力了;约等于 pc 端豆包语音输入法(丐版) ;这里提供给大家多一种选择。觉得不错的帮忙点个 star

项目地址:

想要使用的话要先安装豆包的客户端,同时启用两个软件。(但对于我这种豆包客户端一直挂后台的人来说就没什么区别,他的一些划词还有实时对话、翻译功能确实还挺好用。)

最后坐等官方出 PC 版。


📌 转载信息
原作者:
xiaohu31
转载时间:
2026/1/19 18:07:04

佬友们好!作为一个经常在终端里敲命令的开发者,我相信大家都设置过各种 alias 别名来提高效率。但每次都要手动编辑

.zshrc

.bashrc

,是不是觉得有点麻烦?

今天给大家分享一个我写的小工具 —— AliasGUI,一个跨平台的可视化 Shell 别名管理器!

痛点

  • 每次添加别名都要
vim ~/.zshrc

,然后找到正确位置添加

  • 手动编辑容易出错,比如等号两边加了空格
  • 同时在 macOS 和 Windows 上工作,语法还不一样(Bash vs PowerShell)
  • 别名越来越多,管理起来一团乱麻
  • 换电脑后又要重新配置一遍

AliasGUI 功能

软件截图




核心特性

功能描述
跨平台支持 macOS、Windows、Linux
可视化管理图形界面操作,无需编辑配置文件
快速搜索即时搜索已有别名
备份恢复一键备份,随时恢复,再也不怕手残删错
智能检测自动检测系统 Shell 和配置文件
安全保护只管理 AliasGUI 区块,保留你原有的配置

使用方法

  1. 添加别名:点击 + 新增 按钮,输入别名名称和命令
  2. 保存生效:点击 保存并生效 按钮
  3. 让别名生效
  • macOS/Linux:
source ~/.zshrc
  • Windows: 重新打开 PowerShell

技术栈

  • Electron - 跨平台桌面应用框架
  • React - 前端 UI 框架
  • Vite - 构建工具
  • Node.js - 后端服务

GitHub 开源

项目地址

欢迎 Star、提 Issue 和 PR!

最后

如果有任何建议或者发现 bug,欢迎在评论区告诉我,或者直接在 GitHub 上提 Issue。

感谢各位佬的阅读!


📌 转载信息
原作者:
hyojoo
转载时间:
2026/1/19 18:06:50

写这篇文章的原因主要还是因为V2EX上的这个贴子,这个贴子中说——

“对接同事的接口,他定义的所有接口都是 post 请求,理由是 https 用 post 更安全,之前习惯使用 restful api ,如果说 https 只有 post 请求是安全的话?那为啥还需要 get 、put 、delete ?我该如何反驳他。”

然后该贴中大量的回复大概有这么几种论调,1)POST挺好的,就应该这么干,沟通少,2)一把梭,早点干完早点回家,3)吵赢了又怎么样?工作而已,优雅不能当饭吃。虽然评论没有一边倒,但是也有大量的人支持。然后,我在Twitter上嘲讽了一下,用POST干一切就像看到了来你家装修工人说,“老子干活就是用钉子钉一切,什么螺丝、螺栓、卡扣、插销……通通不用,钉枪一把梭,方便,快捷,安全,干完早回家……不过,还是有一些网友觉得用POST挺好的,而且可以节约时间。所以,正好,我在《我做系统架构的原则》中的“原则五”中反对API返回码无论对错全是200的返回那,我专门写下这一篇文章,以正视听。

这篇文章主要分成下面这几个部分:

  1. 为什么要用不同的HTTP动词?
  2. Restful 进行复杂查询
  3. 几个主要问题的回应
    • POST 更安全吗?
    • 全用 POST 可以节省时间沟通少吗?
    • 早点回家的正确姿势
    • 工作而已,优雅不能当饭吃

目录

为什么要用不同的HTTP动词

编程世界通常来说有两种逻辑:“业务逻辑” 和 “控制逻辑”。

  • 业务逻辑。就是你实现业务需求的功能的代码,就是跟用户需求强相关的代码。比如,把用户提交的数据保存起来,查询用户的数据,完成一个订单交易,为用户退款……等等,这些是业务逻辑
  • 控制逻辑。就是我们用于控制程序运行的非功能性的代码。比如,用于控制程序循环的变量和条件,使用多线程或分布式的技术,使用HTTP/TCP协议,使用什么样数据库,什么样的中间件……等等,这些跟用户需求完全没关系的东西。

网络协议也是一样的,一般来说,几乎所有的主流网络协议都有两个部分,一个是协议头,一个是协议体。协议头中是协议自己要用的数据,协议体才是用户的数据。所以,协议头主要是用于协议的控制逻辑,而协议体则是业务逻辑。

HTTP的动词(或是Method)是在协议头中,所以,其主要用于控制逻辑。

下面是HTTP的动词规范,一般来说,REST API 需要开发人员严格遵循下面的标准规范(参看RFC7231 章节4.2.2 – Idempotent Methods

方法 描述 幂等
GET 用于查询操作,对应于数据库的 select 操作 ✔︎
PUT 用于所有的信息更新,对应于数据库的 update 操作 ✔︎︎
DELETE 用于更新操作,对应于数据库的 delete 操作 ✔︎︎
POST 用于新增操作,对应于数据库的 insert 操作
HEAD 用于返回一个资源对象的“元数据”,或是用于探测API是否健康 ✔︎
PATCH 用于局部信息的更新,对应于数据库的 update 操作
OPTIONS 获取API的相关的信息。 ✔︎

其中,PUT 和 PACTH 都是更新业务资源信息,如果资源对象不存在则可以新建一个,但他们两者的区别是,PUT 用于更新一个业务对象的所有完整信息,就像是我们通过表单提交所有的数据,而 PACTH 则对更为API化的数据更新操作,只需要更需要更新的字段(参看 RFC 5789 )。

当然,现实世界中,可能并不一定严格地按照数据库操作的CRUD来理解API,比如,你有一个登录的API /login 你觉得这个API应该是 GETPOSTPUT 还是 PATCH ?登录的时候用户需要输入用户名和密码,然后跟数据库里的对比(select操作)后反回一个登录的session token,然后这个token作为用户登录的状态令牌。如果按上面表格来说,应该是 select 操作进行 GET ,但是从语义上来说,登录并不是查询信息,应该是用户状态的更新或是新增操作(新增session),所以还是应该使用 POST,而 /logout 你可以使用 DELETE这里相说明一下,不要机械地通过数据库的CRUD来对应这些动词,很多时候,还是要分析一下业务语义。

另外,我们注意到,在这个表格的最后一列中加入了“是否幂等”的,API的幂等对于控制逻辑来说是一件很重要的事。所谓幂等,就是该API执行多次和执行一次的结果是完全一样的,没有副作用。

  • POST 用于新增加数据,比如,新增一个交易订单,这肯定不能是幂等的
  • DELETE 用于删除数据,一个数据删除多次和删除一次的结果是一样的,所以,是幂等的
  • PUT 用于全部数更新,所以,是幂等的。
  • PATCH用于局部更新,比如,更新某个字段 cnt = cnt+1,明显不可能是幂等操作。

幂等这个特性对于远程调用是一件非常关键的事,就是说,远程调用有很多时候会因为网络原因导致调用timeout,对于timeout的请求,我们是无法知道服务端是否已经是收到请求并执行了,此时,我们不能贸然重试请求,对于不是幂等的调用来说,这会是灾难性的。比如像转帐这样的业务逻辑,转一次和转多次结果是不一样的,如果重新的话有可能就会多转了一次。所以,这个时候,如果你的API遵从了HTTP动词的规范,那么你写起程序来就可以明白在哪些动词下可以重试,而在哪些动词下不能重试。如果你把所有的API都用POST来表达的话,就完全失控了。

除了幂等这样的控制逻辑之外,你可能还会有如下的这些控制逻辑的需求:

  • 缓存。通过CDN或是网关对API进行缓存,很显然,我们要在查询GET 操作上建议缓存。
  • 流控。你可以通过HTTP的动词进行更粒度的流控,比如:限制API的请用频率,在读操作上和写操作上应该是不一样的。
  • 路由。比如:写请求路由到写服务上,读请求路由到读服务上。
  • 权限。可以获得更细粒度的权限控制和审计。
  • 监控。因为不同的方法的API的性能都不一样,所以,可以区分做性能分析。
  • 压测。当你需要压力测试API时,如果没有动词的区分的话,我相信你的压力测试很难搞吧。
  • ……等等

也许,你会说,我的业务太简单了,没有必要搞这么复杂。OK,没有问题,但是我觉得你最差的情况下,也是需要做到“读写分离”的,就是说,至少要有两个动词,GET 表示是读操作,POST表示是写操作。

Restful 复杂查询

一般来说,对于查询类的API,主要就是要完成四种操作:排序,过滤,搜索,分页。下面是一些相关的规范。参考于两个我觉得写的最好的Restful API的规范文档,Microsoft REST API GuidelinesPaypal API Design Guidelines

  • 排序。对于结果集的排序,使用 sort 关键字,以及 {field_name}|{asc|desc},{field_name}|{asc|desc} 的相关语法。比如,某API需要返回公司的列表,并按照某些字段排序,如:GET /admin/companies?sort=rank|asc 或是 GET /admin/companies?sort=rank|asc,zip_code|desc

  • 过滤。对于结果集的过滤,使用 filter 关键字,以及 {field_name} op{value} 的语法。比如: GET /companies?category=banking&location=china 。但是,有些时候,我们需要更为灵活的表达式,我们就需要在URL上构造我们的表达式。这里需要定义六个比较操作:=<><=>=,以及三个逻辑操作:andornot。(表达式中的一些特殊字符需要做一定的转义,比如:>= 转成 ge)于是,我们就会有如下的查询表达式:GET /products?$filter=name eq 'Milk' and price lt 2.55 查找所有的价柗小于2.55的牛奶。

  • 搜索。对于相关的搜索,使用 search 关键字,以及关键词。如:GET /books/search?description=algorithm 或是直接就是全文搜索 GET /books/search?key=algorithm

  • 分页。对于结果集进行分页处理,分页必需是一个默认行为,这样不会产生大量的返回数据。


    • 使用pageper_page代表页码和每页数据量,比如:GET /books?page=3&per_page=20
    • 可选。上面提到的page方式为使用相对位置来获取数据,可能会存在两个问题:性能(大数据量)与数据偏差(高频更新)。此时可以使用绝对位置来获取数据:事先记录下当前已获取数据里最后一条数据的ID时间等信息,以此获取 “该ID之前的数据” 或 “该时刻之前的数据”。示例:GET /news?max_id=23454345&per_page=20 或 GET /news?published_before=2011-01-01T00:00:00Z&per_page=20

注意:这里需要注意一下,在理论上来说GET是可以带 body 的,但是很多程序的类库或是中间件并不支持 GET 带 body,导致你只能用 POST 来传递参数。这里的原则是:

  1. 对于简单的查询,很多参数都设计在 restful API 的路径上了,而 filter/sort/pagination 也不会带来很多的复杂,所以应该使用 GET 

  2. 对于复杂的查询来说,可能会有很复杂的查询参数,比如:ElasticSearch 上的 index/_search里的 DSL,你也应该尽可能的使用 GET,而不是POST 除非客观条件上不支持GET。ElasticSearch 的官方文档里也是这么说的。

The authors of Elasticsearch prefer using GET for a search request because they feel that it describes the action—​retrieving information—​better than the POST verb. (我们推荐使用 GET而不是 POST,因为语义更清楚)However, because GET with a request body is not universally supported, the search API also accepts POST requests (除非你的类库或是服务器不支持 GET带参数 ,你再用POST,我们两个都支持)

陈皓注:但是在 ElasticSearch 7.11 后,GET 也不支持 body 了。这是 ElasticSearch 的设计和实现不对应了。

另外,对于一些更为复杂的操作,建议通过分别调用多个API的方式来完成,虽然这样会增加网络请求的次数,但是这样的可以让后端程序和数据耦合度更小,更容易成为微服务的架构。

最后,如果你想在Rest中使用像GraphQL那样的查询语言,你可以考虑一下类似 OData 的解决方案。OData 是 Open Data Protocol 的缩写,最初由 Microsoft 于 2007 年开发。它是一种开放协议,使您能够以简单和标准的方式创建和使用可查询和可互操作的 RESTful API。

几个主要问题的回应

下面是对几个问题的直接回应,如果大家需要我回应更多的问题,可以在后面留言,我会把问题和我的回应添加到下面。

1)为什么API 要Restful,并符合规范?

Restful API算是一个HTTP的规范和标准了,你要说是最佳实践也好,总之,它是一个全世界对HTTP API的一个共识。在这个共识上,你可以无成本地享受很多的技术红利,比如:CDN,API网关,服务治理,监控……等等。这些都是可以让你大幅度降低研发成本,避免踩坑的原因。

2)为什么“过早优化”不适用于API设计?

因为API是一种契约,一旦被使用上,就很难再变更了,就算你发行新的版本的API,你还要驱动各种调用方升级他们的调用方式。所以,接口设计就像数据库模式设计一下,一旦设计好了,未来再变更就比较难了。所以,还是要好好设计。正如前面我给的几个文档——Microsoft REST API GuidelinesPaypal API Design Guidelines 或是 Google API Design Guide 都是让你好好设计API的不错的 Guidelines.

3)POST 更安全吗?

不会。

很多同学以为 GET 的请求数据在URL中,而 POST 的则不是,所以以为 POST 更安全。不是这样的,整个请求的HTTP URL PATH会全部封装在HTTP的协议头中。只要是HTTPS,就是安全的。当然,有些网关如nginx会把URL打到日志中,或是会放在浏览器的历史记录中,所以有人会说 GET 请求不安全,但是,POST 也没有好到哪里去,在 CSRF 这个最常见的安全问题上,则完全就是针对 POST 的。  安全是一件很复杂的事,无论你用哪方法或动词都会不能代表你会更安全。

另外,

  • 如果你要 防止你的 GET 上有敏感信息,应该加个密,这个跟 POST是一样的。
  • 如果你要防止 GET 会被中间人修改,你应该做一个URL签名。(通常来说, 我们都在 GET 上做签名,POST 就忘做了)
  • 如果你要防止有人发一些恶意链接来 hack 你的用户(传说中的 GET 不如 POST 安全的一个问题),你应该用 HMAC 之类的认证技术做好认证(参看 HTTP API 认证授权术)。

总之,你要明白,GETPOST 的安全问题都一样的,不要有谁比谁更安全,然后你就可以掉以轻心的这样的想法,安全都是要很严肃对待的。

4)全用 POST 可以节省时间减少沟通吗?

不但不会,反而更糟糕。

说这种话的人,我感觉是不会思考问题。

  • 其一,为API赋于不同的动词,这个几乎不需要时间。把CRUD写在不同的函数下也是一种很好的编程风格。另外现在几乎所有的开发框架都支持很快速的CRUD的开发,比如Spring Boot,写数据库的CRUD基本上就不需要写SQL语言相关的查询代码,非常之方便。
  • 其二,使用规范的方式,可以节约新加入团队人员的学习成本,而且可以大大减少跨团队的沟能成本。规范和标准其实就是在节约团队时间提升整体效率的,这个我们整个人类进行协作的基础。所以,这个世界上有很多的标准,你只要照着这个标准来,你的所生产的零件就可以适配到其它厂商的产品上。而不需要相互沟通。
  • 其三,全用POST接口一把梭,不规范不标准,使用你的这个山寨API的人就得来不断的问你,反而增加了沟通。另外,也许你开发业务功能很快了,但是你在做控制逻辑的时候,你就要返工了,从长期上来讲,你的欠下了技术债,这个债反而导致了更大的成本。
5)早点回家的正确姿势

不要以为你回家早就没事了,如果你的代码有这样那样的问题,别人看懂,或是出误用了你的代码出了问题,那么,你早回家有什么意义呢?你一样要被打扰,甚至被叫到公司来处理问题。所以,你应该做的是为了“长期的早回家”,而不是“短期的早回家”,要像长期的早回家,通常来说是这样的:

  • 把代码组织设计好,有更好的扩展性。这样在面对新需求的时候,你就可以做到少改代码,甚至不改代码。这样你才可能早回家。不然,每次需求一来,你得重新写,你怎么可能早回家?
  • 你的代码质量是不错的,有不错的文档和注释。所以,别人不会老有问题来找你,或是你下班后,叫你来处理问题。甚至任何人都可以很容易地接手你的代码,这样你才可能真正不被打扰
6)工作而已,优雅不能当饭吃

回应两点:

其一,遵循个规范而已,把“正常”叫“优雅”,可见标准有多低。这么低的标准也只能“为了吃饭而生存了”。

其二,作为一个“职业程序员”,要学会热爱和尊重自己的职业,热爱自己职业最重要的就是不要让外行人看扁这个职业,自己都不尊重这个职业,你让别人怎么尊重?尊重自己的职业,不仅仅只是能够获得让人羡慕的报酬,而更是要让自己的这个职业的更有含金量

希望大家都能尊重自己从事的这个职业,成为真正的职业化的程序员,而不是一个码农!

你的工作给你权力,而只有你的行为才会给你尊重

一、AI 正在进入“可执行时代” 在较早的企业应用阶段,AI 更多承担的是: 问答与搜索 文本总结 推荐与分类 这些场景下,AI 的输出即使存在错误,影响范围通常也局限在信息层面 但近两年,这一边界正在发生明显变化。 在大量企业实践中,AI 已被逐步接入: 工单系统与流程系统 内部数据查询接口 自动化运维与日志分析 云资源管理与平台编排能力 此时,AI 不再只是“给建议”,而是参与实际动作的触发与决策过程 一个关键问题随之出现: 当 AI 开始执行操作时,它的“权限判断”来自哪里?

二、企业级 AI 系统的常见运行模式 在安全分析中,一个常被忽略的事实是:
对话式 AI 的推理过程虽然是无状态的,但企业级系统通常会在模型之外维护会话状态、上下文与长期记忆,从而形成连续行为。
在实际部署中,AI 系统通常具备以下特征: 同一模型实例服务多个请求 依赖历史上下文进行连续推理 通过配置与策略统一约束行为 借助云算力与平台资源运行 这意味着,AI 的行为并非完全由“当前输入”决定,而是受到长期状态、配置与上下文的共同影响 在此基础上,企业级 AI 系统往往包含以下几个关键层次: 模型与系统配置层 任务编排与决策控制层(Orchestrator) 外部工具与服务接口 状态存储与知识体系 安全风险,往往并不直接来自模型本身,而是产生于这些层次之间的信任关系设计 需要思考的几个基础点如下: 第一点,大多数企业级AI系统会将上下文(短期或长期)存入内存或数据库,从而实现连续回复和状态保持。 第二点,AI所需算力庞大,目前大多数企业级部署仍依赖云服务器,这为攻击者提供了潜在的云控制面目标。 第三点,随着AI Agent的广泛应用,其往往成为多种工具与权限的集合体,赋权不当极易引入安全漏洞。 关于AI的架构部分,我主要分为了四大模块: 第一部分是AI算力模块(云资源与模型服务)。 第二部分主要是AI大脑控制(AI Orchestrator)层面。 第三部分是AI的外部工具调用。 第四部分是AI的独立数据库(状态、记忆与知识存储)。 对于大多数读者来说,即使从未接触过 AI 开发,只要使用过对话式 AI,其背后基本都遵循如下架构 简单画一下AI的架构图便于理解:

image.png

三、重新理解 AI Agent 的安全边界 从系统视角看,一个典型的 AI Agent 通常由以下要素构成: 语言模型:负责理解与推理 规则与策略:定义行为边界 状态与记忆机制:保存上下文与历史 工具与接口权限:连接外部系统 调度与决策逻辑:决定执行路径 在这个结构中,模型只是“理解引擎”,
而真正决定风险上限的,是权限、状态与决策机制的组合方式
如果这些组件之间缺乏清晰的安全边界,AI Agent 的行为就可能出现“超出设计预期”的情况。

四、风险分析一:状态与上下文的信任问题 在传统系统中,权限判断通常基于明确的身份认证与授权流程。 而在 AI 系统中,行为判断往往隐含地依赖于: 系统提示与配置 历史对话内容 状态记忆中的既有结论 如果这些信息被不当继承或混合使用,就可能导致状态信任偏移 例如,在多轮交互中,AI 可能基于先前结论延续对用户身份或角色的假设,而这一假设并不一定经过真实系统校验。 这种问题并非单点错误,而是由连续推理机制天然放大的系统性风险。 关于历史对话部分的关键风险点:

风险
本质
上下文污染
状态注入
多轮对话权限错觉
Identity 漂移
记忆跨 session
租户隔离失败
向量召回污染
AI 供应链攻击

跨租户污染的真实案例 Slack AI 2024 prompt injection & data exfiltration(PromptArmor报告,2024年8月):攻击者在公共频道注入恶意prompt,Slack AI在总结/搜索时会拉取私有频道数据,并生成可点击链接泄露给攻击者服务器。虽非严格向量库跨租户, 但展示了公共可见内容对私有检索结果的污染风险。Slack随后紧急patch。 此外,多轮对话 可能造成权限升级错觉------前提:Orchestrator 没有 硬校验,Tool 没有 权限二次确认 真实案例: ServiceNow Now Assist 2025第二序prompt injection(AppOmni报告,2025年11月):低权限用户注入恶意prompt到内容中,诱导低权限Agent招募高权限Agent执行CRUD操作、发送外部邮件(使用发起交互用户的权限)。即使开启内置prompt injection保护仍可成功。ServiceNow确认是设计行为,但更新文档警示风险。 实操危害:导致调用内部/付费工具、泄露其他用户数据、业务逻辑绕过(如客服Agent退款、解锁)。

五、风险分析二:记忆机制带来的长期影响 为了提升体验,许多 AI Agent 引入了长期记忆或向量化知识存储机制,用于: 保存历史偏好 复用上下文信息 构建内部知识库 但从安全角度看,这类机制引入了新的挑战: 不同用户或租户之间的状态是否严格隔离 记忆内容是否具备可信来源标识 是否存在长期残留的错误认知 一旦记忆系统缺乏明确边界,其影响往往具有持续性与放大效应,而非一次性问题。 从状态持久化(可能包含记忆序列化)到云资源的攻击思路 前置条件:Agent 使用 LangChain 等框架的序列化功能持久化状态(包括记忆或工具上下文),且进程持有云凭证。 真实案例:LangChain Core CVE-2025-68664(LangGrinch,2025年12月):攻击者通过 Prompt Injection 诱导 LLM 生成恶意元数据,污染序列化字段。 在该案例中,研究表明:当状态序列化与反序列化机制缺乏完整性校验时,Prompt 注入可能影响系统元数据处理流程,在特定配置下增加云凭证暴露的风险面

六、风险分析三:工具调用与权限放大效应 在实际系统中,AI Agent 通常通过工具接口完成任务,例如: 数据查询 服务调用 平台操作 出于便利性考虑,这些工具往往绑定的是服务级身份,而非用户的真实权限集合。 如果缺乏细粒度的权限约束与操作校验,可能出现以下风险模式: AI 的行为能力大于发起请求者的真实权限 工具返回结果被默认信任并参与后续决策 决策逻辑对异常输入缺乏防护机制 这些问题的本质并非传统意义上的漏洞,而是权限建模与信任传递设计不当 1.调用工具的身份权限问题 本质:Agent通常以服务账号(高权限)调用工具,而非用户权限,导致过度代理(Excessive Agency),用户可诱导执行未授权操作(OWASP LLM08)。 真实案例 攻击链:低权限用户在可读内容(如ticket描述)中注入指令 → 低权限Agent解析并招募高权限Agent → 执行写操作或外发邮件。 2.调用工具----->可触发ssrf
真实案例:
● ChatGPT Custom GPTs/Actions SSRF(2024-2025多起相关报告及研究):用户可控URL被Agent用于资源加载(如图片/网页检索),触发服务器端请求伪造,泄露云元数据服务(如Azure/AWS IMDS)和临时凭证(OpenAI已多次修复)。
3.工具返回结果反向污染Orchestrator/决策 4.调用工具----打到AI orchestrator面 真实案例: Microsoft 365 Copilot 数据外泄(2024-2025多起报告):攻击者在共享文档/邮件中注入恶意指令,Copilot检索后信任并输出敏感信息,或生成含外泄链接的响应,导致间接数据泄露。(可替换或补充Slack案例)

七、RAG 与外部知识的供应链风险 当 AI Agent 具备联网搜索或自动构建知识库能力时,其知识来源不再完全可控。 在实践中需要关注的问题包括: 知识收录的可信度与权重机制 外部内容对内部决策的长期影响 离线模式下对历史知识的持续依赖 这类风险往往不表现为即时异常,而是以潜移默化的方式影响系统行为,增加安全审计与治理难度。 供应链攻击 / RAG知识库污染 真实案例: AgentPoison (2024-2025):在RAG知识库/记忆中注入极少恶意演示,成功攻击真实Agent(自动驾驶、QA、医疗),证明知识污染可持久误导。 Slack AI 2024:公共频道污染导致私有数据泄露(间接RAG污染)。

八、防御视角下的设计原则 从系统安全角度看,AI Agent 的防御重点不应放在“限制模型能力”,而应关注以下原则: 权限判断必须来自真实系统,而非自然语言上下文 状态与记忆需按用户与租户强制隔离 工具权限遵循最小化原则 AI 的角色是“辅助决策”,而非“自动授权” 关键操作始终需要显式校验与审计 这些原则并不会降低 AI 的业务价值,但能够显著降低其对整体系统安全边界的冲击。

九、结语 当 AI Agent 被赋予执行能力后,安全边界不再只存在于接口、代码与权限系统中,而是被拆散并分布在上下文、状态、记忆与决策链路之中。 真正值得警惕的,并不是模型是否“听话”,而是系统是否在无意识中,将关键判断权交给了未经验证的推理结果。 在企业级 AI 系统中,任何一次未被显式校验的状态继承、角色假设或工具调用,最终都会转化为真实系统中的权限行为。这正是 AI Agent 安全治理必须回到系统设计本身的原因。

今天跟大家分享一个etcd的内存大量占用的问题,这是前段时间在我们开源软件Easegress中遇到的问题,问题是比较简单的,但是我还想把前因后果说一下,包括,为什么要用etcd,使用etcd的用户场景,包括etcd的一些导致内存占用比较大的设计,以及最后一些建议。希望这篇文章不仅仅只是让你看到了一个简单的内存问题,还能让你有更多的收获。当然,也欢迎您关注我们的开源软件,给我们一些鼓励。

为什么要用ETCD

先说一下为什么要用etcd。先从一个我们自己做的一个API网关 – Easegress(源码)说起。

Easegress 是我们开发并开源的一个API应用网关产品,这个API应用网关不仅仅只是像nginx那样用来做一个反向代理,这个网关可以做的事很多,比如:API编排、服务发现、弹力设计(熔断、限流、重试等)、认证鉴权(JWT,OAuth2,HMAC等)、同样支持各种Cloud Native的架构如:微服务架构,Service Mesh,Serverless/FaaS的集成,并可以用于扛高并发、灰度发布、全链路压力测试、物联网……等更为高级的企业级的解决方案。所以,为了达到这些目标,在2017年的时候,我们觉得在现有的网关如Nginx上是无法演进出来这样的软件的,必需重新写一个(后来其他人也应该跟我们的想法一样,所以,Lyft写了一个Envoy。只不过,Envoy是用C++写的,而我用了技术门槛更低的Go语言)

另外,Easegress最核心的设计主要有三个:

  • 一是无第三方依赖的自己选主组集群的能力
  • 二是像Linux管道命令行那样pipeline式的插件流式处理(支持Go/WebAssembly)
  • 三是内置一个Data Store用于集群控制和数据共享。

对于任何一个分布式系统,都需要有一个强一制性的基于Paxos/Raft的可以自动选主机制,并且需要在整个集群间同步一些关键的控制/配置和相关的共享数据,以保证整个集群的行为是统一一致的。如果没有这么一个东西的话,就没有办法玩分布式系统的。这就是为什么会有像Zookeeper/etcd这样的组件出现并流行的原因。注意,Zookeeper他们主要不是给你存数据的,而是给你组集群的。

Zookeeper是一个很流行的开源软件,也被用于各大公司的生产线,包括一些开源软件,比如:Kafka。但是,这会让其它软件有一个依赖,并且在运维上带来很大的复杂度。所以,Kafka在最新的版本也通过内置了选主的算法,而抛弃了外挂zookeeper的设计。Etcd是Go语言社区这边的主力,也是kubernetes组建集群的关键组件。Easegress在一开始(5年前)使用了gossip协议同步状态(当时想的过于超前,想做广域网的集群),但是后发现这个协议太过于复杂,而且很难调试,而广域网的API Gateway也没遇到相应的场景。所以,在3年前的时候,为了稳定性的考量,我们把其换成了内嵌版本的etcd,这个设计一直沿用到今天。

Easegress会把所有的配置信息都放到etcd里,还包括一些统计监控数据,以及一些用户的自定义数据(这样用户自己的plugin不但可以在一条pipeline内,还可以在整个集群内共享数据),这对于用户进行扩展来说是非常方便的。软件代码的扩展性一直是我们追求的首要目标,尤其是开源软件更要想方设法降低技术门槛让技术易扩展,这就是为什么Google的很多开源软件都会选使用Go语言的原因,也是为什么Go正在取代C/C++的做PaaS基础组件的原因。

背景问题

好了,在介绍完为什么要用etcd以后,我开始分享一个实际的问题了。我们有个用户在使用 Easegress 的时候,在Easegress内配置了上千条pipeline,导致 Easegress的内存飙升的非常厉害- 10+GB 以上,而且长时间还下不来。

用户报告的问题是——

在Easegress 1.4.1 上创建一个HTTP对象,1000个Pipeline,在Easegres初始化启动完成时的内存占用大概为400M,运行80分钟后2GB,运行200分钟后达到了4GB,这期间什么也没有干,对Easegress没有进行过一次请求。

一般来说,就算是API再多也不应该配置这么多的处理管道pipeline的,通常我们会使用HTTP API的前缀把一组属于一个类别的API配置在一个管道内是比较合理的,就像nginx下的location的配置,一般来说不会太多的。但是,在用户的这个场景下配置了上千个pipeline,我们也是头一次见,应该是用户想做更细粒度的控制。

经过调查后,我们发现内存使用基本全部来自etcd,我们实在没有想到,因为我们往etcd里放的数据也没有多少个key,感觉不会超过10M,但不知道为什么会占用了10GB的内存。这种时候,一般会怀疑etcd有内存泄漏,上etcd上的github上搜了一下,发现etcd在3.2和3.3的版本上都有内存泄露的问题,但都修改了,而 Easegress 使用的是3.5的最新版本,另外,一般来说内存泄漏的问题不会是这么大的,我们开始怀疑是我们哪里误用了etcd。要知道是否误用了etcd,那么只有一条路了,沉下心来,把etcd的设计好好地看一遍。

大概花了两天左右的时间看了一下etcd的设计,我发现了etcd有下面这些消耗内存的设计,老实说,还是非常昂贵的,这里分享出来,避免后面的同学再次掉坑。

首当其冲是——RaftLog。etcd用Raft Log,主要是用于帮助follower同步数据,这个log的底层实现不是文件,而是内存。所以,而且还至少要保留 5000 条最新的请求。如果key的size很大,这 5000条就会产生大量的内存开销。比如,不断更新一个 1M的key,哪怕是同一个key,这 5000 条Log就是 5000MB = 5GB 的内存开销。这个问题在etcd的issue列表中也有人提到过  issue #12548 ,不过,这个问题不了了之了。这个5000还是一个hardcode,无法改。(参看 DefaultSnapshotCatchUpEntries 相关源码

// DefaultSnapshotCatchUpEntries is the number of entries for a slow follower
// to catch-up after compacting the raft storage entries.
// We expect the follower has a millisecond level latency with the leader.
// The max throughput is around 10K. Keep a 5K entries is enough for helping
// follower to catch up.
DefaultSnapshotCatchUpEntries uint64 = 5000

另外,我们还发现,这个设计在历史上etcd的官方团队把这个默认值从10000降到了5000,我们估计etcd官方团队也意识到10000有点太耗内存了,所以,降了一半,但是又怕follwer同步不上,所以,保留了 5000条……(在这里,我个人感觉还有更好的方法,至少不用全放在内存里吧……)

另外还有下面几项也会导致etcd的内存会增加

  1. 索引。etcd的每一对 key-value 都会在内存中有一个 B-tree 索引。这个索引的开销跟key的长度有关,etcd还会保存版本。所以B-tree的内存跟key的长度以及历史版本号数量也有关系。
  2. mmap。还有,etcd 使用 mmap 这样上古的unix技术做文件映射,会把他的blotdb的内存map到虚拟内存中,所以,db-size越大,内存越大。
  3. Watcher。watch也会占用很大的内存,如果watch很多,连接数多,都会堆积内存。

(很明显,etcd这么做就是为了一个高性能的考虑)

Easegress中的问题更多的应该是Raft Log 的问题。后面三种问题我们觉得不会是用户这个问题的原因,对于索引和mmap,使用 etcd 的 compact 和 defreg (压缩和碎片整理应该可以降低内存,但用户那边不应该是这个问题的核心原因)。

针对用户的问题,大约有1000多条pipeline,因为Easegress会对每一条pipeline进行数据统计(如:M1, M5, M15, P99, P90, P50等这样的统计数据),统计信息可能会有1KB-2KB左右,但Easegress会把这1000条pipeline的统计数据合并起来写到一个key中,这1000多条的统计数据合并后会导致出现一个平均尺寸为2MB的key,而5000个in-memory的RaftLog导致etcd要消耗了10GB的内存。之前没有这么多的pipeline的场景,所以,这个内存问题没有暴露出来。

于是,我们最终的解决方案也很简单,我们修改我们的策略,不再写这么大的Value的数据了,虽然以前只写在一个key上,但是Key的值太大,现在把这个大Key值拆分成多个小的key来写,这样,实际保存的数据没有发生变化,但是RaftLog的每条数据量就小了,所以,以前是5000条 2M(10GB),现在是5000条 1K(500MB),就这样解决了这个问题。相关的PR在这里 PR#542

总结

要用好 etcd,有如下的实践

  • 避免大尺寸的key和value,一方面会通过一个内存级的 Raft Log 占大量内存,另一方面,B-tree的多版本索引也会因为这样耗内存。
  • 避免DB的尺寸太大,并通过 compact和defreg来压缩和碎片整理降低内存。
  • 避免大量的Watch Client 和 Watch数。这个开销也是比较大的。
  • 最后还有一个,就是尽可能使用新的版本,无论是go语言还是etcd,这样会少很多内存问题。比如:golang的这个跟LInux内核心相关的内存问题 —— golang 1.12的版sget的是 MADV_FREE 的内存回收机制,而在1.16的时候,改成了 MADV_DONTNEED ,这两者的差别是,FREE表示,虽然进程标记内存不要了,但是操作系统会保留之,直到需要更多的内存,而 DONTNEED 则是立马回收,你可以看到,在常驻内存RSS 上,前者虽然在golang的进程上回收了内存,但是RSS值不变,而后者会看到RSS直立马变化。Linux下对 MADV_FREE 的实现在某些情况下有一定的问题,所以,在go 1.16的时候,默认值改成了 MADV_DONTNEED 。而 etcd 3.4 是用 来1.12 编译的。

最后,欢迎大家关注我们的开源软件! https://github.com/megaease/ 

如果大家觉得有帮助,欢迎点个 star 支持一下。

Motivation

这个 project 的初衷,源于我读到的 Anthropic 的 skills 设计,对这种即插即用、可组合的范式产生了强烈兴趣,觉得在抽象层面非常优雅。由此引出了一个问题:能否像搭积木一样,通过编排 skills 来完成科研流程(好吧,我承认其实是懒癌犯了,想走捷径了,想把 codex 当成拉磨的驴 Agent 来用)?进一步来说,能否用 skills 的组合与调度,替代一部分原本依赖重型编码、耗时执行的复杂研究任务?在这一想法的驱动下,随着 skills 体系逐渐成形、效果开始显现,项目便沿着这个方向持续推进,逐步系统化地构建和打磨这套以 skills 为核心的 Pipeline。其核心理念是:将研究流程显式建模为可组合的语义单元(skills with contracts),使研究任务能够像软件工程一样实现可编排、可复用、可演化、可审计。

System Design

  1. skills 层面
    一开始我先入为主地把 skills 理解成 “函数”,但后来发现它更接近于一个自包含的执行单元,skill 描述的不是 “怎么调用”,而是 “在什么条件下、以什么方式完成一件事,并如何判断它是否完成”,这里推荐看 anthropic 的官方 Github 或者 doc。
  • What: 输入是什么,输出是什么(显式依赖)
  • How: 怎么做,有哪些边界情况(notes + procedures)
  • When done: 完成标准是什么(acceptance criteria)
  • What NOT to do: 边界约束(guardrails,比如 NO PROSE)
  1. pipeline 层面
    在设计上对 skills 做了解耦 (不想重复造轮子了,另外改原子化组成的 Pipeline 只需增删改 skills):不再为每一个研究任务编写一条固定流程,而是将研究过程拆解为一组原子化的 skills(如 retrieval、taxonomy、outline、evidence、writing、validation),再通过 UNITS.csv 显式描述它们的执行顺序与依赖关系。这样一来,不同类型的任务(survey、systematic review、tutorial)可以复用同一套 skills,仅通过不同的编排方式完成,流程本身不再与具体任务强绑定。
    整个流程被拆解成了 C0-C5 阶段,每一阶段有阶段性的产物(说多了都是泪,end2end 固然优雅,还是要保留中间产物便于回滚),会有隐式或者显示的规则 / 代码确保产物没有特别大的遗漏,在关键性节点引入确定性质量门(如 placeholder leakage、citation health、evidence binding 检查)用来兜底。
    同时这套 Pipeline 也可以高度个性化,个人比较倾向于设计 Pipeline 的时候让模型自己头脑风暴考虑怎么组合 skills,然后作为参考设计完整的 Pipeline,当然存在 garbage in garbage out 的风险,需要自己校正。

  2. 具体实现
    配合 claude code 和 codex 开启了 self-loop 的开发(工具改变生活),抽象出一堆 skills,约束 Pipeline 渐进式执行

Usage

打开 terminal 开始指挥手下,启动 codex --sandbox workspace-write --ask-for-approval never (记得要把 sandbox 里面的 network 打开)

[sandbox_workspace_write]
network_access = true

模拟 example

你:给我写一个 agent 的 latex-survey
↓ [C0-C1] 检索 800+ 篇论文 → 去重到 150+ 核心集 arxiv 会补全 meta 信息
↓ [C2] 构建 taxonomy + outline + mapping(NO PROSE)→ 停在 C2 等审批

你:C2 同意,继续

↓ [C3-C4] 构建证据底座(paper notes + evidence packs + citations)(NO PROSE)
↓ [C5] 基于 evidence 开始写作 → 质量门检查

【如果 PASS】→ output/DRAFT.md + latex/main.pdf ✓
【如果 FAIL】→ output/QUALITY_GATE.md 告诉你改哪个中间产物

你(如果 FAIL):按报告修复对应文件(如 outline/evidence_drafts.jsonl),然后说"继续"
→ 从失败 unit 恢复执行,不需要全部重跑

示例产物(v0.1,包含完整中间产物)全在 example 里面

该版本由 codex 中的 gpt-5.2-xhigh 运行约 2 小时 生成,过程中仅进行过 一次 human-in-the-loop(C2 阶段) 介入。
路径:example/e2e-agent-survey-latex-verify-****时间戳/(pipeline:pipelines/arxiv-survey-latex.pipeline.md)。
配置摘要:draft_profile: lite / evidence_mode: abstract / core_size: 220(详见 queries.md)。

Limitation

写作部分 self-loop 了 N 次,迭代思路是选取一些写的比较好的 survey,让 cc 或者 codex 学习下写作风格和结构,然后了解 workspace 中的实际产物分析和优秀 survey 的差距,把暴露出的问题和改进意见写到某个 md 里面,再根据改进意见头脑风暴,反向调整重构 skills 和 Pipeline

写作还是门艺术活,高度依赖审美和经验,现在这套流程离从 0 到 1 写出顶会级别的描述还是有不少距离的,另一方面,写作技巧可能很难被精确的量化,目前更多是通过将其转化为 “受约束的优化问题”,给出正反例,给出一些引导性句子,杜绝一些模型的写作怪癖 / 特殊表达,这样的方式虽然提升了下限,也不可避免会落入俗套,模板化。

Future work

当然最终目标还是希望同时提高上下限,fighting,也希望能够加入一些可解释性。

如果大家有好的建议,欢迎多多提出;趁着现在热情还没降下去,这个 repo 会持续更新,也欢迎点个 star 支持一下。

Reference

  1. GitHub - anthropics/skills: Public repository for Agent Skills
  2. helloagents/Codex/Skills at main · hellowind777/helloagents · GitHub
  3. GitHub - renocrypt/latex-arxiv-SKILL: A .codex SKILL for issue-driven ML/AI arXiv review papers: scaffold LaTeX + verify BibTeX citations end-to-end.
  4. https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview

Todo

  1. 加入多 cli 协作,multi-agent design
  2. 继续完善写作技巧

📌 转载信息
转载时间:
2026/1/19 18:06:18