xiaohack博客专注前沿科技动态与实用技术干货分享，涵盖 AI 代理、大模型应用、编程工具、文档解析、SEO 实战、自动化部署等内容，提供开源项目教程、科技资讯日报、工具使用指南，助力开发者、AI 爱好者获取前沿技术与实战经验。
作者：林润骑(太业) 在多云战略日益普及的今天，企业往往需要在不同云平台部署业务系统，同时又希望将可观测数据统一采集到单一平台进行分析和管理。然而，跨云数据传输的高昂成本成为了企业实施统一可观测性战略的主要障碍。 我们发现，CloudFront 等 CDN 产品的出站流量价格更低，随用量增加还享有阶梯折扣。通过将 CDN 作为数据传输的“跳板”，可以大幅降低跨云传输成本。 基于这一发现，阿里云可观测团队设计了 LoongCollector + CDN 的跨云低成本采集方案： 本方案可将跨云数据传输成本显著降低，让企业以更低的代价实现统一可观测平台的愿景。 日志服务 SLS 对外提供公网域名，用户可以直接通过公网将数据发送到 SLS，且 SLS 不收取入站流量费用。 痛点 SLS 传输加速利用全球分布的云机房，将全球各地用户对日志服务的访问，经过智能路由解析至就近的接入点，使用优化后的网络及协议极大地提升访问速度。 痛点 双重成本：除了源云平台的出站流量费用之外，还需要承担 DCDN 的加速费用，整体成本进一步增加。 ▍方案三：跨云专线打通 通过云服务提供商的专线服务（如 AWS Direct Connect、阿里云高速通道等）建立跨云专用网络连接。 痛点 EC2 每月有 100GB 的出站免费额度，但是 CloudFront 的出站和公网访问源站的价格要比 EC2 的价格更低。更重要的是，CDN 产品通常提供分级定价和批量折扣，随着使用量增加，单位成本会进一步降低。通过 CDN 的加速链路，将 SLS 服务设置成源站的方式，我们可以复用 CDN 的转发链路，实现以下优势： CloudFront 区域数据传输到源站的价格： CloudFront 请求次数价格（每月前 100 万次免费）： EC2 出公网价格： 以美国地域为例：10TB 的数据，通过 CloudFront 传输，成本比 EC2 直接公网传输可以节约 70%。 本方案以 CloudFront 为例，整体的采集方案如图所示： AWS EC2（LoongCollector） a. 从本地/应用采集日志或数据 b. 按 SLS 写入协议组包（HTTP POST） c. 将数据发送到目标 SLS CloudFront a. 接收 LoongCollector 的请求（HTTP/HTTPS） b. 按行为规则转发到源站（此处源站为阿里云 SLS 的写入端） SLS（阿里云日志服务） SLS ConfigServer（管控端） A. 管控链路（Control Plane）——直连公网 特点：请求量小、数据量小、对带宽不敏感。 典型动作包括： 选择直连公网的原因： B. 数据链路（Data Plane）——通过 CloudFront 转发到 SLS 特点：持续写入、对稳定性/连通性敏感，可能存在跨境网络波动。 这里以采集数据到 SLS 上海地域的 Project 为例。 注意事项: 行为配置 注意事项: CloudFront 的域名验证 直接 Curl CloudFront 域名，如果有如下返回，则说明已配置成功。 关键配置说明： 使用 HTTPS 协议发送数据 关键配置说明： LoongCollector 资源参数配置 LoongCollector 是部署在 EC2 或者节点上，因此需要预估单机采集的日志的原始数据量，调整资源参数，具体可以参考帮助文档：https://help.aliyun.com/zh/sls/select-a-network-type PS：LoongCollector 进行数据发送的时候，默认采用 LZ4 进行压缩，针对日志数据，可以有 5 ～ 10 倍的压缩效果。 测试场景： 可以看到在同地域场景下，CloudFront 的访问质量跟直接公网访问基本持平，HTTP 的访问延迟还是略低一些。 本文介绍的跨云低成本可观测数据实时采集方案，通过 CDN + LoongCollector 的组合，实现了： LoongCollector 作为新一代统一可观测 Agent，将持续致力于为用户提供高性能、低成本、易使用的跨云数据采集解决方案，助力企业构建统一的可观测平台。 参考资料： [1] LoongCollector 官方文档 https://github.com/alibaba/loongcollector [2] AWS CloudFront 官方文档 https://docs.aws.amazon.com/cloudfront/ [3] 阿里云 SLS 官方文档背景
现有方案 & 痛点
方案一：纯公网
方案二：纯公网 + SLS 加速域名
跨云低成本采集方案
整体方案
架构概览
链路分层：管控链路 & 数据链路
CloudFront 详细配置
源配置
{"Error":{"Code":"OLSInvalidMethod","Message":"The script name is invalid : /","RequestId":"XXX"}}
LoongCollector 详细配置
使用 HTTP 协议发送数据
# /usr/local/ilogtail/ilogtail_config.json
{
"primary_region" : "cn-shanghai",
"config_servers" :
[
"https://logtail.cn-shanghai.log.aliyuncs.com"
],
"data_servers" :
[
{
"region" : "cn-shanghai",
"disable_subdomain" : true,
"endpoint_list": [
"http://xxx.cloudfront.net"
]
}
],
...
}# /usr/local/ilogtail/ilogtail_config.json
{
"primary_region" : "cn-shanghai",
"config_servers" :
[
"https://logtail.cn-shanghai.log.aliyuncs.com"
],
"data_servers" :
[
{
"region" : "cn-shanghai",
"disable_subdomain" : true,
"endpoint_list": [
"https://xxx.cloudfront.net"
]
}
],
"enable_host_ip_replace": false,
...
}
网络质量测试结果
限制说明
总结与展望
方案总结
昨天新开通的账号，今天早上起来一看，已经用了$33.04 。
而且大头竟然是 claude-4.6-opus-high ！
这就奇了怪了，昨天开通账号的时候，觉得 4.6-opus 太贵，直接在模型列表中把这个模型关了。所以我无论如何也不可能用到这个模型。
设置里 Agent review 也是关闭的。
最神奇的是：昨天这个时间我还在群里聊天，压根没碰 cursor 。（裂开）
作为现象级的开源 AI Agent 项目，OpenClaw 凭借强大的自主执行能力，正迅速成为能够操作文件、调用系统命令、控制浏览器的“数字员工”。同时，这种能力也带来了一系列的安全风险。例如本地敏感信息外发，执行破坏性高危操作或被远程控制，引发数据泄露、系统损毁、业务中断等严重问题。
针对这些问题，火山引擎重磅推出三层纵深安全防护方案，助力企业构建“安全可控”的数字员工。
平台安全
打造“免疫级”底层环境
火山引擎为通过 ECS 和 Agentkit 部署的 OpenClaw 提供基础安全保障方案，从访问控制、指令过滤、执行环境、安全准入四个维度，构建相应的底层防御能力。
AI助手安全
打造安全可控的“数字员工”
火山引擎全新发布 AI Assistant Security ，在 OpenClaw 等 AI 助手类智能体的交互环节（如调用大模型、Skills 及工具等），提供针对高危操作、敏感信息泄露、提示词注入等风险的防护和管控。
// 三大典型场景，感受安全价值
个人隐私的脱敏和保护：识别身份证号、手机号等敏感信息，严控敏感数据出域，确保个人隐私不被泄露。
高危操作的拦截：在调用工具和技能前，识别如“资金转账、敏感数据外发、文件恶意删除”等高危操作，实现默认阻断或降级为人工确认，避免模糊指令带来不可逆的损失。
提示词攻击的防护：当 AI 数字员工联网访问到恶意网页，其中暗藏的恶意提示词导致 AI 数字员工被远程控制并带来不可控的后果，AI Assistant Security 会提前识别异常并给出安全提示，确保 AI 只执行用户的真实意图。
// 快速上手，限时免费试用
目前，火山引擎 AI Assistant Security for OpenClaw 的安全防护方案，面向所有用户开启限时免费试用。
👉 火山引擎客户
👉 非火山引擎客户
通过简单的命令自动完成安装。
npm i -g @omni-shield/openclaw-cli
omni-shield-openclaw
供应链安全
让Skills安全调用
Skills 作为 OpenClaw 的“手”，通过封装特定能力供 OpenClaw 调用以完成复杂任务。然而，随着 Skills 的权限过大及恶意 Skills 的涌现，导致账户凭证外泄、执行木马病毒等安全事件频发。
针对此痛点，火山引擎智能体安全管理平台的扫描功能全面升级，支持对 MCP/Skills 的深度扫描。用户可以自行上传任意 Skills 文件，平台提供预置的扫描规则可对上传的 Skills 进行深度扫描，并输出详细的风险详情，实现了覆盖事前检测、定期巡检、事中拦截的全生命周期安全防护：
（预置扫描规则、上传Skills文件、Skills风险详情）
// 使用教程
目前，火山引擎智能体安全管理平台私有化版本已上线扫描方案，面向所有用户开启限时免费试用。同时，公有云版本将在2月底对外上线，届时欢迎大家体验。
在私有化版本中，对接 OpenClaw 和智能体安全管理平台对 Skills 进行安全扫描，具体操作步骤如下：
安全是 AI 真正成为生产力的底线。火山引擎通过三层纵深安全防护方案，助力开发者在享受 AI 效率的同时，无需担心隐私外泄与操作风险。现在，上火山引擎一键安全防护，让你的 AI 助手安全上岗。
随着道路交通量的不断增加，交通事故的发生频率也呈现上升趋势。事故发生后，快速、准确地评估车辆受损情况，对于保险理赔、道路安全分析、交通事故责任判定以及事故风险预警具有重要意义。传统人工评估方法存在效率低、主观性强、覆盖面有限等问题，难以满足现代智能交通系统对数据实时性和精确性的需求。 为此，本数据集专注于交通事故车辆受损情况的识别与分级，面向目标检测与图像分类任务，构建了覆盖多种道路环境与事故类型的高质量图像数据集，可为事故严重程度评估、车辆损伤等级判定及相关智能系统提供可靠的数据支撑。 数据集说明 一、数据集简介 交通事故车辆受损情况数据集面向道路交通事故智能分析与车辆损伤等级判定等应用场景构建，适用于目标检测、图像分类及事故严重程度评估等计算机视觉任务。 数据集共包含 1000+ 张真实场景车辆图像，图像来源覆盖多种道路环境与事故形态，能够较好反映车辆在不同事故等级下的受损特征差异。通过对车辆受损程度进行分级标注，可用于训练与评估基于 YOLO 等深度学习模型的事故识别与风险评估能力。 二、数据集配置 数据集共划分 5 个事故等级类别，类别编号与含义如下： Class ID 类别名称 说明 覆盖完整事故严重程度梯度 真实道路场景，泛化能力强 结构规范，可直接用于 YOLO 本数据集共包含 1000+ 张真实道路交通事故车辆图像，图像来源广泛，涵盖城市道路、高速公路、乡村道路等不同场景，同时覆盖轻微剐蹭到车辆完全报废的全事故等级梯度。每张图像均附带 目标边界框标注与事故等级分类信息，结构规范，可直接用于深度学习模型训练。 随着城市交通网络的不断扩张和机动车保有量的快速增加，道路交通事故的发生频率呈现上升趋势。事故发生后，快速、准确地评估车辆受损情况，对于保险理赔、事故责任判定、道路安全管理以及交通事故预警具有重要意义。传统的人工评估方式不仅效率低、耗时长，而且受主观因素影响较大，难以满足现代智能交通系统对实时性和精确性的需求。近年来，随着计算机视觉和深度学习技术的发展，通过图像识别与目标检测实现事故车辆损伤自动识别和等级评估成为可能，这不仅能够提升事故处理效率，还可以为智能交通系统提供数据驱动的决策支持。针对这一需求，本数据集专注于交通事故车辆受损情况的识别与分级，收集了涵盖多种道路环境和事故类型的1000+真实车辆图像，覆盖从轻微剐蹭到车辆完全报废的全事故等级梯度。每张图像均配有规范的目标边界框标注和事故等级分类信息，可直接应用于YOLO系列、Faster R-CNN、SSD、DETR等目标检测模型训练与评估，也适用于图像分类、事故严重程度分析及风险评估等多种计算机视觉任务。该数据集不仅具有科研价值，可支持事故识别算法研究、模型优化及复杂场景下的鲁棒性分析，也具有工程实用性，为智能交通事故分析系统、车辆损伤等级判定和道路安全管理提供了可靠的数据基础，为推动交通安全智能化管理和事故处理自动化提供了有力支撑。 可直接训练与评估： 本数据集针对交通事故车辆受损情况进行了精心收集、整理与标注，旨在为智能交通事故分析、车辆损伤等级判定及相关深度学习研究提供高质量数据支持。无论是科研教学、毕业设计，还是工程应用开发，该数据集均可为模型训练与性能评估提供可靠基础，为提升道路交通事故处理效率与安全管理智能化水平提供有力支撑。 总体来看，本交通事故车辆受损情况数据集是一份高度工程化且科研价值兼具的数据资源，覆盖从无事故到车辆完全报废的完整事故等级梯度，充分反映了车辆在不同事故条件下的受损特征差异。数据集包含 1000+ 张真实道路场景图像，涵盖城市道路、高速公路及乡村道路等多样化环境，同时覆盖轻微剐蹭、结构性损伤、严重破坏等多种事故类型，具有较强的泛化能力。所有图像均经过标准化标注，提供目标边界框和事故等级信息，可直接适配YOLO系列、Faster R-CNN、SSD、DETR等主流目标检测模型，显著降低模型训练与实验准备成本。从科研角度看，该数据集可用于多等级事故识别、多类别目标检测、小样本学习及模型鲁棒性分析，支持算法创新与性能优化；从工程应用角度看，它能够为智能交通事故分析系统、车辆损伤等级判定、自动理赔辅助、道路风险统计及应急调度等提供可靠的数据支撑。整体而言，该数据集不仅适用于教学实验、毕业设计及科研论文研究，也为智能交通与事故管理系统的研发与部署提供了坚实的数据基础，是推进交通安全智能化管理的重要资源，为提升事故处理效率、减少交通风险、保障道路安全提供了切实可行的技术支撑。发现交通事故的车辆受损情况数据集（1000+张图片已划分、已标注）| AI训练适用于目标检测任务
一、项目背景
数据集下载
链接:https://pan.baidu.com/s/1zYLg1EOwHB-HTBlxQr4w7A?pwd=yhmd
提取码:yhmd
交通事故车辆受损情况数据集
0 无事故 车辆未发生碰撞或明显损伤
1 轻微事故 轻微剐蹭或小面积损伤，不影响行驶
2 中等事故 明显变形或结构性损伤，影响车辆性能
3 严重事故 车辆主体结构严重破坏，存在较大安全隐患
4 车辆完全报废 车辆严重损毁、翻覆或燃烧，无法修复
适合教学、科研与工程落地项目二、数据集概述
📂 数据目录结构
三、数据集类别说明
Class ID 类别名称 说明 0 无事故 车辆未发生碰撞或明显损伤 1 轻微事故 轻微剐蹭或小面积损伤，不影响行驶 2 中等事故 明显变形或结构性损伤，影响车辆性能 3 严重事故 车辆主体结构严重破坏，存在较大安全隐患 4 车辆完全报废 车辆严重损毁、翻覆或燃烧，无法修复 特点说明
四、数据标注与训练适配
五、适用场景
🚗 智能交通事故分析
🛣 城市道路与高速公路安全管理
🤖 教学科研与模型验证
六、数据集优势
七、结语
大家好我是老卫，又到了老卫拆书的时间了。本期我将2026年鸿蒙生态的几本好书分享给大家。 由清华大学出版社出版。 该书也获得过计算机类畅销新书奖。 由北京大学出版社出版。 华为OpenHarmony首席架构师力荐教材：本书通过68个实战示例+4个大型综合性案例+大量即用型优质代码，手把手教你快速掌握核心技术！ 由北京大学出版社出版。 由清华大学出版社出版。 从零基础到项目实战，掌握HarmonyOS6新特性，资深华为开发者专家带你飞。该书以HarmonyOS 6版本为核心，从基础知识到实战案例，引领读者逐步探索“纯血鸿蒙”原生开发的奥秘。 由北京大学出版社出版。 如果说之前介绍的那几本都是相对比较基础的鸿蒙的入门教程，那么这本《鸿蒙架构师修炼之道》就是面向高端的架构师培养手册。学习本书，可以掌握专家级架构师的思维方式与工作方法。 更多好书分享见我主页。1. 鸿蒙HarmonyOS应用开发入门
一线架构师教你彻底掌握HarmonyOS应用开发。量范例与项目，阅读本书，读者能够学以致用，掌握开发实际应用程序的技能。本书基础与示例相结合，按照边讲边练的思路组织内容。
2. 鸿蒙HarmonyOS应用开发从入门到精通（第2版）
3. 仓颉编程从入门到实践
该书是华为官方自研仓颉语言权威指南！本书系统梳理仓颉编程语言的核心特性与设计哲学，是开发者快速上手、深入理解这一面向全场景未来语言的推荐手册。
4. 鸿蒙之光HarmonyOS 6应用开发入门
5. 鸿蒙架构师修炼之道
随着智慧城市与智能交通系统（ITS）的快速发展，城市道路的精细化管理成为基础设施建设中的关键课题。井盖缺失、井盖开启、路面坑洞、无标识减速带等问题，不仅影响道路通行质量，还可能引发交通事故。 在自动驾驶、智能巡检车、无人机道路巡检等应用场景中，对道路设施及安全隐患进行实时目标检测与识别，已成为核心技术模块之一。 然而，当前公开可用的道路隐患类数据集相对较少，且类别单一、标注不规范或缺乏完整的数据划分。因此，本数据集围绕城市道路设施与安全隐患目标检测构建，具备： 为科研与工程应用提供高质量数据支持。 数据集说明 本数据集专注于城市道路设施及道路安全隐患的目标检测任务，涵盖常见的井盖、道路坑洞及减速带等设施类型。数据集共包含 约13,000张高质量图像，按训练、验证和测试集划分如下： 训练集（train/images）：用于模型训练 验证集（valid/images）：用于模型调参与验证 测试集（test/images）：用于模型性能评估 数据集包含 5个类别： 井盖（Manhole） 打开的井盖（Open Manhole） 坑洞（Pothole） 减速带（Speed Bump） 无标识减速带（Unmarked Bump） 所有图像均标注了目标的边界框信息，可直接用于目标检测模型（如YOLO系列、Faster R-CNN等）训练与评估。数据集可用于城市道路设施检测、道路安全巡检、智能交通系统及自动驾驶环境感知等研究与应用，为提升城市道路安全和交通管理智能化提供数据支持。 本数据集共包含 约13,000张高质量图像，覆盖多种城市道路场景（白天、阴天、不同角度、不同距离等），具有较强的泛化能力。 （已完成标准划分，可直接用于训练） 随着智慧城市建设和智能交通系统的不断推进，城市道路的安全与管理问题日益受到重视。道路设施的完好与安全隐患的及时发现，直接关系到交通顺畅、行车安全以及市民的生活质量。在实际道路环境中，井盖缺失或开启、路面坑洞、减速带未标识等情况仍时有发生，这些问题不仅影响道路通行效率，还可能导致交通事故，造成严重的社会和经济损失。传统的人工巡检方式存在效率低、成本高、覆盖面有限等不足，迫切需要结合人工智能技术，通过计算机视觉手段实现对道路设施与安全隐患的自动识别与检测。针对这一需求，本数据集围绕城市道路设施及安全隐患目标检测任务构建，收集并整理了约13,000张高质量图像，覆盖井盖、开启井盖、坑洞、减速带及无标识减速带五类关键目标，同时提供标准化的边界框标注和训练、验证、测试集划分，可直接用于主流目标检测模型的训练与评估。该数据集不仅具备科研价值，可支持目标检测算法研究、模型优化及复杂环境下的鲁棒性分析，也具有工程实用性，为智慧城市道路巡检系统、自动驾驶环境感知以及智能交通管理提供了可靠的数据支撑与实验基础。通过这一数据集，研究者和开发者能够更高效地探索道路安全隐患检测技术，加速人工智能在交通安全领域的应用落地。 本数据集共包含 5个目标类别： 示例格式： 可直接适配： 13000张图像，满足中小规模检测任务训练需求。 特别是： 属于高风险类别，具有现实部署意义。 增强模型泛化能力。 训练 / 验证 / 测试集已分离，可直接实验对比。 如果使用YOLO系列模型，推荐： 如你正在做YOLO单类别或多类别实验，本数据集可直接扩展训练场景。 在合理训练参数下，常见YOLO系列模型可获得： 城市道路安全隐患检测是智慧城市建设的重要一环。本数据集围绕真实道路场景构建，兼具工程实用性与科研价值。 无论你是： 本数据集都能为你提供完整、规范、可直接训练的高质量数据支持。 如果需要完整数据集、训练配置文件及部署说明，可进一步交流。 综上所述，本城市道路设施及道路安全隐患目标检测数据集围绕实际工程场景构建，兼顾数据规模、类别实用性与标注规范性，具备较强的训练价值与落地意义。数据集覆盖井盖、开启井盖、坑洞、减速带及无标识减速带五类关键目标，不仅包含常规道路设施，还特别强调高风险安全隐患类别，使其在智慧城市管理、道路巡检系统、智能交通系统以及自动驾驶环境感知等方向具备更高的应用价值。约13,000张图像经过清洗、筛选与标准化标注，并完成训练集、验证集、测试集的合理划分，能够直接适配YOLO系列、Faster R-CNN、SSD等主流目标检测框架，显著降低实验准备成本，提高建模效率。从研究角度看，该数据集能够支持小目标检测优化、多类别不均衡问题研究、复杂光照环境鲁棒性分析等技术探索；从工程角度看，可用于道路风险识别、隐患预警统计及智能巡检系统部署测试。整体而言，该数据集不仅适合教学实验与毕业设计使用，也能够作为实际项目原型开发与算法验证的数据基础，为提升城市道路安全管理智能化水平提供可靠的数据支撑与实验环境。城市道路设施及道路安全隐患数据集（13000张图片已划分、已标注）| AI训练适用于目标检测任务
一、项目背景
数据集下载
链接:https://pan.baidu.com/s/1zYLg1EOwHB-HTBlxQr4w7A?pwd=yhmd
提取码:yhmd
道路设施目标检测数据集介绍二、数据集概述
📂 数据目录结构
dataset/
├── train/
│ ├── images/
│ └── labels/
├── valid/
│ ├── images/
│ └── labels/
├── test/
│ ├── images/
│ └── labels/train/images：训练集图像valid/images：验证集图像test/images：测试集图像labels：对应YOLO格式标注文件
三、数据集类别说明
类别名称 英文名称 说明 井盖 Manhole 正常关闭状态井盖 打开的井盖 Open Manhole 存在安全隐患 坑洞 Pothole 路面破损 减速带 Speed Bump 标准减速带 无标识减速带 Unmarked Bump 无明显警示标识 类别特点
四、标注说明
class_id x_center y_center width height五、数据集优势
1️⃣ 数据量充足
2️⃣ 类别设计具有工程价值
3️⃣ 场景多样性
4️⃣ 已完成标准划分
六、适用场景
🚗 自动驾驶环境感知
🛣 城市道路巡检系统
🚦 智能交通系统（ITS）
🤖 深度学习目标检测教学与实战
七、训练建议
八、实验效果预期
九、结语
这批是小规模制作，更多是一次形态上的实验。
-----------------------
既然发帖了，也做个小活动：
从本帖发布起 24 小时内，
在评论区留下邮箱的朋友中，随机抽 1 位。
送一张 AI 录音卡，包邮到家。
24 小时后我会在帖子里公布结果（只公布邮箱前缀）。
-----------------------
如果你对这种“实体 + AI 工具”的方式有看法，无论是吐槽还是建议，都欢迎直接说。
做产品久了，会越来越在意“形式是否真的有意义”，
也想听听 V2EX 的真实反馈。
最近自己折腾了一个小工具网站: https://www.toolkit.ren
今天发出来跟大家分享一下，也恳请各位大佬多多指点，不吝赐教
做这个站的初衷，就是平时不管是开发写代码、日常办公，还是偶尔处理点小需求，总要找各种零散的小工具，还担心数据安全问题，索性就自己动手了，根据自己实际需求攒了这个小工具站，目前网站每天还在不断的优化中，后续还会添加一些新的资源和文章
目前站里都是我自己平时用得上的功能，覆盖了开发、办公、日常常用的一些小工具，界面做的很简洁，打开就能直接用，不用注册登录，所有数据都在浏览器本地进行，数据安全
现在功能还在慢慢迭代更新，各位大佬不管是哪里用着不顺手、功能有 bug ，还是有想要的工具没加上，都欢迎大家直接提，我都会认真看、认真改~
再次感谢各位大佬多多斧正！
在 AI 原生开发时代，模型能力快速增长，但系统风险也呈非线性膨胀。如何在释放 AI 生产力的同时保持核心资产安全、控制复杂度，是每个工程团队必须面对的关键问题。本文提出“棒棒糖模型 + 螺旋演化”的分层安全架构，将人的操作、Guard 约束、测试计划与 AI 能力层级有机结合： 棒棒糖模型：核心资产是糖头，人的操作路径是棒身，贯穿系统各层，形成可控连接；AI 能力和外部工具是一层层糖衣，其能力释放受棒身约束。 螺旋演化：随着版本迭代和功能扩展，规则密度、测试覆盖率和异常处理能力沿螺旋递增，实现系统随时间动态可控。 这种设计不仅提供静态安全边界，也兼顾系统长期演化风险，确保 AI 能力在复杂环境中被安全、可验证地释放。本文将详细介绍 L0–L6 分层架构、Guard Layer 模块化、单人模式落地实践，以及动态自愈与监控机制，提供可落地的 AI 安全工程方案参考。 在 AI 原生开发时代，模型能力迅速增强，但系统风险呈非线性上升。传统架构往往将 AI 置于系统核心，而忽视以下问题： 核心资产边界 权限收敛机制 运行期行为漂移 成本失控路径 当 Agent 或模型出现异常时，损失可能具有放大性与不可逆性。本方案基于 TPDD（Test Plan Driven Development） 方法论，结合： 能力暴露（Capability Exposure） 禁止空间（Forbidden Zone） Failure Thinking Zero Trust 思维 将 AI 系统安全抽象为分层圆 + 动态防御闭环，以在释放 AI 生产力的同时收敛失控风险。 空间原则 越靠内层 → 资产价值越高 → 约束必须越强 越靠外层 → 不确定性越大 → 护栏必须越厚 控制权原则 系统核心是数据、权限与控制权 模型属于高风险计算外设，而非信任根 模型视角补充（静态 × 动态） 洋葱模型（Onion Model）：刻画任一时刻的信任边界与权限分层（空间视角） Nautilus Spiral 模型：刻画系统随时间的复杂度、测试密度与约束增长（时间视角） 二者关系： 横截面安全边界 → 洋葱模型 生命周期演化 → 螺旋模型 该组合可同时解决： 静态安全收敛 动态复杂度膨胀 AI 系统长期演化风险 目标：绝对保护区（Blast Radius Zero Zone） 典型资产：公司数据库、用户隐私、商业机密、源代码仓库、内部高敏知识库、密钥 / Token / 凭证 约束原则： ❌ 默认 AI 不可直接访问 ❌ 默认 Agent 不可持久触达 ❌ 严禁长生命周期凭证 ✅ 仅允许 JIT（Just-in-Time）短时授权 ✅ 全链路审计可追溯 落地措施： API Gateway + RBAC + ABAC 组合授权 KMS + 短期凭证轮换 行为基线异常检测 访问风险评分（risk scoring） 自动权限回收 目标：管理和约束人为操作风险 涉及角色：开发、QA、BA/PM、运维、数据分析、Prompt 编写者 主要风险： Prompt Injection、误操作、权限滥用 社工攻击、敏感数据误粘贴 长上下文污染 工程化约束： 权限校验 + 全审计 高危操作双人确认 隔离执行环境 输入脱敏与 DLP Prompt 风险评分 主动攻击演练与异常注入 说明：人的操作从最外层一直贯穿到最内层，就像 棒棒糖模型的棒身。 目标：将系统从“能跑”变为“可控” Guard 架构： Entry Guards（入口收敛） Runtime Guards（运行时持续约束） Shadow Guards（旁路监控） 模块职责： Contract Guard：schema 校验、工具调用白名单、权限契约检查 → 防止能力误用 Invariant Guard：系统永真条件（不删除文件、不外发敏感数据、不越权访问） → 异常报警 Test Guard（TPDD 核心）：边界测试、Failure 注入、对抗样本、回归测试、行为快照 Token / Cost Guard：context、steps、tool calls、成本限制 → 超额熔断策略、动态阈值与负载感知 落地措施： 自动化脚本执行 TPDD 测试计划并记录行为快照 异常行为触发内圈熔断、报警和自动回滚 多 Agent 调度系统联动实时限流 红队验证和主动攻击演练 目标：能力释放层，风险最高 包含：LLM、Agent、Skills/Tools、RAG、多步规划、自动代码生成 工程认知： 外圈不应被完全信任 假设可能犯错、被注入、产生幻觉、越界尝试、非线性成本 落地措施： AI 执行必须经过 Guard Layer 审核 每次生成操作附带行为日志和审计记录 异常或超阈值行为自动熔断 动态阈值随负载和业务峰值调整 职责：统一管理 AI 与人工生成代码 自动化回归测试与静态分析 动态安全测试与代码审核 依赖分析与冲突检测 多 Agent 并行生成调度与隔离 生成代码附带行为快照和版本追踪 系统级裁决层，三阶段验证： 生成前（静态风险预判） 生成中（运行监控） 生成后（功能 / 性能 / 安全验证） 职责： 功能安全验证、性能压测、异常检测 红队演练、非线性攻击模拟 发布阻断权归该层 目标：维持系统收敛能力 Incident Learning Loop：事故归因、策略回放、Guard 规则调优 Policy Auto-Tuning：动态调整阈值、限流、授权窗口 Self-Healing Flow：会话隔离、权限收缩、Agent 降级、沙盒重启、状态回滚 Guard 健康监控：持续监测漏检率、延迟、旁路风险 人在 AI 安全架构中，不仅是使用者，更是安全闭环的中枢轴，贯穿 输入 → 约束 → 执行 → 验证 → 自愈： L0 核心资产层：临时访问、JIT 授权、审计触发 L1 人员操作层：Prompt 编写、运维操作、敏感数据处理 L2 测试与约束层：执行 Contract / Invariant Guard、TPDD 测试计划 L3 AI 能力外圈：Agent / LLM 调用的审计、行为评分、异常触发 L4 代码生成层：生成代码回顾、版本追踪、多 Agent 隔离 L5 验证层：功能/性能/安全验证、红队演练、异常阻断 L6 自愈与韧性层：异常触发回滚、会话隔离、Agent 降级 可视化比喻： 棒头（Candy Head）：核心资产，保护最严格 棒身（Candy Stick）：人的操作路径，贯穿各层，形成受控连接 糖衣（Candy Coating）：AI 能力和外部工具，能力释放受棒身控制 动态演化（螺旋/TPDD）：沿棒身逐步增加规则密度、测试覆盖率和异常处理能力，实现系统随时间持续安全可控 通过这一设计，人的操作持续校准 Guard、TPDD 测试和异常监控，使 AI 能力在复杂系统中安全释放，同时保持核心资产的高度保护。 同心圆模型刻画任意时刻的静态信任边界与权限层级，明确“当前可以访问什么、不能访问什么”，棒棒糖模型加入了人类可以介入的视角。 AI 系统随版本迭代、功能扩展而成长，代码量、复杂度和行为多样性逐步外扩，仅依赖静态洋葱无法完整描述长期演化风险。 螺旋模型要点： 螺旋对应版本沉积，每圈螺旋代表一次版本迭代 外圈规模更大、复杂度更高，但结构与内圈一致 动态规则与测试密度递增，Guard 规则、Failure 注入、监控指标随版本增长 TPDD 测试计划自动联动，覆盖率提升、异常注入增强 指标化落地： 测试密度（tests / KLOC）随版本递增 Guard 覆盖率逐步细化、自动化执行 行为异常率实时监控、阈值动态调整 Token / Cost 消耗斜率、风险评分动态计算 静态 + 动态结合： 同心圆：回答“当前边界在哪里” Nautilus Spiral：回答“随时间边界如何膨胀、规则如何增强” 通过结合，两者确保系统长期安全可控。 Human / User ↓ L2 Entry Guards（Contract / Invariant / Token / Cost） ↓ Agent / Model (L3) ↕ 多轮受控交互 L2 Runtime Guards（Contract / Invariant / Cost） ↓ Code Generation Layer (L4) ↓ Verification Mesh (L5) ↓ Core Assets (L0, JIT 授权) ↓ L6 Resilience Loop 禁止路径： User → Agent → DB Agent → 高权限 Tool（无审计） AI → 长生命周期凭证 关键工程语义： Guard 双阶段：Entry + Runtime → 防止“一次放行，全程裸奔” 执行流受控，Agent 持续接受约束与异常监控 Verification 分布三阶段 → 目标尽早失败 Core Assets 默认不可达，临时授权、自动过期、全链路审计 核心目标： 单人或小团队环境，实现可控、安全闭环 阻止越界操作、实时监控异常、自动回滚、沙盒隔离、精细化成本/Token 管理 改进措施： 沙盒化执行：完全隔离、会话隔离、JIT Token、自动回滚、状态快照 自动化 Contract / Invariant Guard：契约检查 + Invariant 监控 + 规则自动升级 行为异常评分与阈值触发：异常评分、滑动窗口、自适应阈值 Token / Cost 精细化管理：按操作类型、上下文动态调整、超阈值自动熔断 简化自愈机制：会话隔离、沙盒重启、权限收缩、状态回滚 渐进式开发与定期 Review：每日/每周复盘 TPDD 测试计划、日志和 Guard 效能 核心架构： Human / User ↓ L2 Entry Guards ↓ Agent / Model 执行层（沙盒 + 异常评分 + Token/Cost 精细化） ↓ L4 Code Generation Layer（自动回滚 + 多 Agent 隔离） ↓ L5 Verification Mesh（静态/动态/功能/性能验证） ↓ Core Assets / L0（JIT 授权 + 全链路审计） ↓ L6 Resilience & Self-Healing 横截面：洋葱 → 当前边界 人的操作：棒棒糖 → 贯穿层级 纵向演化：螺旋 → 动态复杂度和规则增长 总结三者关系：静态 + 操作 + 动态 → 安全闭环 核心资产永远在内圈，模型能力在外圈受控释放 Guard Layer 模块化、动态化、可反馈，是系统安全核心 单人模式仍可落地，但依赖最小可行安全套件 能力暴露 + 禁止空间 + Failure Thinking 架构落地，为 AI 工程提供可控、可验证、可维护的实践方法 动态量化阈值、负载感知、红队演练是改进后的关键增强点 Text polished by GPT; images generated by AI. 1 引言
核心原则
2 分层同心圆架构（由内向外）
🔴 L0 核心资产层（Core Assets）【最内圈】
🟠 L1 人员操作层（Human Operators）
🟡 L2 测试与约束层（TPDD Guard Layer）⭐ 核心护城河
🔵 L3 AI 能力外圈（Agent / Model Layer）
🟣 L4 代码生成层（AI + 人工生成代码）
⚫ L5 验证层（Verification Mesh）
🧠 L6 自愈与韧性层（Resilience & Self-Healing Layer）
3 人的角色：贯穿全局的操作轴（棒棒糖模型）
4 Nautilus Spiral 演化视角（动态复杂度增强）
5 安全执行流推荐路径（受控闭环）
6 OPC / 单人模式小型团队改进方案
7 整合三者
总结
JDK 26，自JDK 25以来的第一个非长期支持（LTS）版本，已经达到了其二号候选版本，正如甲骨文公司 Java 平台组首席架构师Mark Reinhold所宣布的那样。主干源代码库在 2025 年 12 月初被分支到 JDK稳定化代码库（Rampdown 阶段 1），它定义了 JDK 26 的特性集。关键缺陷，如回归或严重的功能问题，可能会被解决，但必须通过修复请求流程获得批准。根据发布计划，JDK 26 将于 2026 年 3 月 17 日正式发布。 最终的 10 个新特性集，以 JEP 的形式，可以分为五（5）类：核心 Java 库、热点、Java 语言规范、安全库和客户端库。 其中五个（5）个新特性被归类为核心 Java 库： JEP 517：面向HTTP Client API的HTTP/3（HTTP/3 for the HTTP Client API） JEP 526：延迟常量（Lazy Constants，第二轮预览) JEP 529：向量API（Vector API，第十一轮孵化） 其中两个（2）个新特性被归类为 HotSpot： JEP 516：适用于任何GC的Ahead-of-Time对象缓存（Ahead-of-Time Object Caching with Any GC） JEP 522：G1 GC：通过减少同步提高吞吐量（G1 GC: Improve Throughput by Reducing Synchronization） 其中有一个（1）个新特性被归类为 Java 语言规范： 其中有一个（1）个新特性被归类为安全库： 最后，有一个（1）个新特性被归类为客户端库： 我们研究了其中的一些新特性，和它们所属主要 Java 项目——Amber、Loom、Panama、Valhalla和Leyden，这些项目旨在孵化一系列组件，最终通过精心策划的合并到 JDK 中。 JEP 530，模式、instanceof和switch中的原始类型（Primitive Types in Patterns, instanceof, and switch，第四轮预览），提出了第四次预览，此前三次预览分别在 JDK 25 至 JDK 23 中交付。本次包括两项变更：增强无条件精确性的定义；以及在 switch 结构中应用更严格的支配性检查。 JEP 525，结构化并发（Structured Concurrency，第六轮预览），在 JDK 19 至 JDK 25 中交付的五轮预览之后，提出了第六轮预览。这个功能通过引入结构化并发的概念来简化并发编程，将“在不同线程中运行的一组相关任务视为一个工作单元，从而简化错误处理和取消，提高可靠性，并增强可观测性。”唯一的重大变更是向 JEP 529，向量API（Vector API，第十一轮孵化），在 JDK 16 至 JDK 25 中交付的十轮孵化之后，提出了第十一轮孵化，自 JDK 25 以来没有实质性的实现变更。这个功能引入了一个 API，用于“表达在支持的 CPU 架构上可靠地在运行时编译为最佳向量指令的向量计算，从而实现优于等效标量计算的性能。”向量 API 将继续孵化，直到项目Valhalla的必要功能作为预览功能可用。届时，向量 API 团队将调整向量 API 及其实现以使用它们，并将向量 API 从孵化阶段提升到预览阶段。 JEP 524，加密对象PEM编码（PEM Encodings of Cryptographic Objects，第二轮预览），在 JDK 25 中交付的第一轮预览，即 JEP 470，加密对象的PEM编码（预览）之后，提出了第二轮预览。变更包括：将 JEP 522，G1 GC：通过减少同步提高吞吐量（G1 GC: Improve Throughput by Reducing Synchronization），提议减少 G1 垃圾收集器的开销，以改善应用程序线程和 GC 线程之间的同步。 JEP 516，适用于任何GC的Ahead-of-Time对象缓存（Ahead-of-Time Object Caching with Any GC），提议增强 JEP 483，任何 GC 的提前类加载和链接，该功能在 JDK 24 中交付，以改善启动和预热时间，使其可以与任何垃圾收集器一起使用，包括低延迟的 Z 垃圾收集器（ZGC）。 计划于 2026 年 9 月发布 GA 版本，目前JDK 27只针对一(1)个 JEP。但是，根据大量的 JEP 候选和草稿，特别是那些已经提交的或增量预览版，我们可以推测哪些 JEP 有可能包含在 JDK 27 中。 JEP 401，值类和对象（Value Classes and Objects，预览版），在Valhalla项目的支持下，提议通过值对象增强语言，这些值对象定义为：只包含 final 字段；没有身份；并且仅由它们各自字段的值来区分。 JEP 草案 8376595，延迟常量（Lazy Constants，第三次预览），在 JDK 26 和 JDK 25 即将发布的两轮预览之后，提出了第三轮预览，并包含两项变更：从 JEP 草案 8329758，使用ZGC实现更快的启动和预热（aster Startup and Warmup with ZGC），提议增强 Z 垃圾收集器，以更有效地根据应用程序的需求分配内存。通过创建一个小型的初始堆来减少操作系统的开销，可以最小化启动时间。 请注意，草案 JEP 可能会随时更改。我们预计甲骨文公司将很快开始针对 JDK 27 的目标，增加额外的 JEP。 原文链接：Amber 项目
Loom 项目
StructuredTaskScope.Joiner接口添加了onTimeout()方法，允许该接口的实现在超时后返回结果。Panama 项目
安全库
PEMRecord类重命名为PEM；以及增强PEMEncoder和PEMDecoder类以支持KeyPair和PKCS8EncodedKeySpec类的加密和解密。HotSpot
JDK 27
LazyConstant接口中移除isInitialized()和orElse()方法，因为它们与此功能的设计目标不一致；以及一个新的工厂方法ofLazy()，它可以为所有三种 Java 集合类型创建稳定的、预定义的元素，即：List、Set和Map。
中了 10 次金币池了
在企业数字化转型进程中，CRM（客户关系管理）已成为打通获客-销售-供应链全链路的核心枢纽。不同厂商基于技术底座、生态资源与行业定位，在各业务模块的能力表现差异显著。本文选取10款主流CRM产品，从获客、销售、订单管理、发货/物流跟踪、统计分析、上下游协同六大核心维度展开深度对比，为企业选型提供专业参考。 获客是CRM的前端入口，核心差异体现在渠道整合能力、数据精准度、成本可追溯性三个维度： 销售模块是CRM的核心，差异体现在跟单模型灵活性、流程自动化、客户洞察深度： 该模块核心差异在于订单类型覆盖、原生功能完整性、供应链协同效率： 统计分析的核心是数据维度广度、AI驱动能力、可视化程度： 上下游协同的核心是伙伴管理深度、数据共享效率、流程自动化： 综上，CRM系统的选型需紧密匹配企业的业务规模、核心场景与长期数字化战略：大型企业可优先考虑全域管控能力突出的Oracle CX或高性价比全链路覆盖的超兔一体云；中小团队可聚焦轻量化工具快速启动；垂直场景（如私域、B2B项目销售）则需锚定生态专属或行业适配型产品。通过精准匹配CRM核心能力与业务需求，可有效实现获客效率提升、销售流程闭环、供应链协同提效，为企业数字化转型筑牢核心底座。一、核心能力总览对比表
品牌 获客核心能力 销售核心能力 订单核心能力 发货/物流跟踪核心能力 统计分析核心能力 上下游协同核心能力 超兔一体云 多渠道集客（线上+线下），线索智能化处理，活动成本核算 精细化客户管理，多跟单模型适配，360°跟单视图 多订单类型支持，全流程执行管控 原生发货单+物流跟踪，扫码签收，供应链协同 多引擎数据分析，可视化展示，ROI与转化率评估 OpenCRM平台，上游供应商全流程协作，下游客户全链路互动 Oracle CX 跨渠道营销自动化，CDP整合多源数据，AI驱动精准触达 销售云全流程打通，CPQ简化报价，区域配额管理 与SCM/ERP深度集成，全订单生命周期跟踪 原生SCM集成，运输路线监控，交付预测 AI实时预测，360°客户视图，营销ROI、销售绩效多维度分析 PRM伙伴管理，SCM协同供应链计划，适合制造/高科技行业深度协同 Pipedrive 多渠道线索收集，需依赖外部工具扩展获客渠道 可视化销售漏斗，AI销售建议，中小团队轻量化管理 基础订单记录，需集成第三方系统 无原生功能，需外部集成 实时销售报告，团队绩效监控，收入预测 侧重内部销售，上下游协同能力弱 Nimble 社媒数据整合，客户兴趣图谱，精准社媒获客 AI工作流优化，内部团队协作，销售流程深度不足 无原生订单功能，需外部系统补充 无原生功能，需外部集成 客户行为微观洞察，智能留存提醒，分析维度较窄 侧重内部销营协同，供应链上下游支持不足 红圈CRM 统一客户库，自定义营销活动，效果分析 商机全生命周期管理，漏斗预测，红圈通APP协同 订单关联客户，CRM+支持合同全生命周期管理 无明确原生功能 自定义报表，行业经营监控指标，多维度数据统计 CRM+支持供应商/采购管理，覆盖供应链需求端客户 钉钉CRM 市场活动规划，统一客户信息管理，开源字节CRM强化线索管理 销售漏斗跟踪，开源字节CRM支持通话质检、日报输出 集成合同订单，开源字节CRM支持库存核算、往来对账 开源字节CRM支持订单发货跟踪、库存变更记录 客户趋势分析，开源字节CRM实时数据仪表盘 钉钉生态支持外部协作，开源字节CRM财务协同对接上下游 Zoho CRM 多渠道线索捕获，自动打分分配 可视化销售漏斗，自定义销售流程，自动化跟进提醒 基础订单管理，需Inventory扩展模块强化 需Inventory模块实现物流跟踪 内置报表/BI工具，多维度销售、转化率分析 侧重内部管理，供应链协同需第三方集成 腾讯企点CRM 腾讯生态公私域联动，智能活码拉新，CDP全域用户画像 企微会话分析，私域社群营销自动化，销售过程可视化 基础订单记录，需集成电商/ERP系统 无原生功能，需外部集成 CDP全域分析，FA融合分析辅助决策 强私域客户运营，供应商/经销商管理能力有限 神州云动CloudCC 内置MA营销自动化，多渠道线索管理与活动追踪 全流程销售管理，适配复杂项目型销售，智能业绩预测 对接ERP同步订单，部分版本支持物流状态查询 可对接ERP实现物流跟踪 自定义报表/BI，深度分析销售效能、客户价值 伙伴管理模块，支持经销商/渠道商协同，适合B2B企业 EC CRM 多渠道线索自动抓取，智能分配 销售漏斗管理，通话录音AI质检，销售过程合规化 基础订单记录，需API对接第三方系统 无原生功能，需外部集成 销售数据仪表盘，实时团队绩效与转化监控 侧重内部销售管理，上下游协同能力弱 二、分模块深度对比
1. 获客能力：渠道覆盖与智能化程度
获客渠道能力脑图（Mermaid）
mindmap
root((获客渠道能力对比))
全渠道智能化
超兔一体云
线上：百度/巨量/官网/微信/小程序
线下：地推/会销专属码
智能：查重/成本核算/自动提醒
Oracle CX
跨渠道：邮件/社交/广告
数据：CDP多源整合
AI：精准触达/策略优化
腾讯生态专属
腾讯企点CRM
微信/企微公私域联动
智能活码拉新
CDP全域画像
社媒专属
Nimble
LinkedIn/Twitter社媒整合
客户兴趣图谱
钉钉生态专属
钉钉CRM
钉钉生态活动管理
开源字节CRM线索管控
轻量化基础
Pipedrive
邮件/表单收集
需外部工具扩展
EC CRM
电话/微信/广告抓取
智能分配2. 销售能力：跟单模型与场景适配
超兔一体云小单快单跟单流程时序图（Mermaid）
sequenceDiagram
participant 销售
participant 超兔系统
participant 客户
销售->>超兔系统: 创建客户（自动查重+工商信息补全）
超兔系统->>销售: 分配三一客跟单任务（定人/定时/定动作）
销售->>客户: 按节点首次触达
客户->>销售: 反馈初步需求
销售->>超兔系统: 记录跟进动作，更新客池状态
超兔系统->>销售: 自动生成日报，触发下节点提醒
销售->>客户: 二次跟进，确认需求细节
客户->>销售: 同意下单
销售->>超兔系统: 转化为订单，同步客户生命周期状态3. 订单与发货/物流跟踪：流程闭环能力
4. 统计分析：数据洞察与决策支持
5. 上下游协同：供应链链路打通
三、品牌能力雷达图评分（满分10分）
品牌 获客 销售 订单 发货/物流 统计分析 上下游协同 超兔一体云 9 9 9 8 9 9 Oracle CX 10 10 9 9 10 10 Pipedrive 6 8 5 4 7 5 Nimble 7 6 4 3 6 4 红圈CRM 7 8 7 5 8 7 钉钉CRM 7 7 8 7 7 8 Zoho CRM 8 8 7 6 8 6 腾讯企点CRM 9 8 6 5 8 6 神州云动CloudCC 8 9 8 7 9 9 EC CRM 8 8 6 5 7 5 四、选型建议
作者：vivo 互联网前端团队- Fang Liangliang 多地区销量持续增长、业务运营诉求与日俱增，悟空作为一站式h5搭建平台，需要先发完成多地区化能力改造，基于复用、提效的思路，探索多地区系统方案，实现多地区一体化运作。 1分钟看图掌握核心观点👇 图 1 VS 图 2，您更倾向于哪张图来辅助理解全文呢？欢迎在评论区留言 悟空系统多地区化共线改造，用一套代码、一套架构实现多地区部署，后续的增量功能一次开发，全量复用，已有机房实现100%复用，新增机房节约90%开发成本； 开发者开发组件的方式不需要做任何改变，公共npm依赖包无需迁移，开发者低成本完成组件迁移； 本文将深度解析悟空系统多地区共线改造的架构设计，从页面多语言、站点的编译、npm私服、开发者等环节进行解析，让读者能够有所收获。 开发之前，我们进行了整体的梳理，涉及的范围如下图所示： 业务分层图 从用户层、服务层、调度层进行拆解，可以进一步分析出需要实施的要点，如图所示： 整体功能点梳理图 进行整体的分析之后，我们可以从平台侧开始一层层的进行拆解，从用户能直观看到的web层，到用户感知比较弱的编译服务层，再到私服和底层库的处理上，核心主要分为三个模块进行改造：平台改造、编译服务、npm私服\&底层库。 这部分介绍平台web侧的改造，主要分为三个方向：中英文改造、平台登录改造、国家码存储改造。 平台中英文国际化改造 背景 ：平台本身是用的vue进行开发，所以这里我们采用Vue.js + vue-i18n的国际化解决方案，支持中文(zh)和英文(en)双语切换。 我们来看一段核心代码示例： 使用vue-i18n有以下几点优势： 平台登录改造 悟空平台会存在多个机房场景，如何使用同一个域名做为入口，简化多地区登录场景链路。 我们设计了一个多地区统一域名入口，进入之后运营可以根据需求切换不同地区，不需要在单独保存各个地区的独立链接，登录链路也会整合到入口域名，整体链路如下图所示： 代码示例如下： 通过上述的方案，我们将机房的匹配集成在系统内部进行，减少用户感知，降低用户使用成本，这样可以做到统一域名入口，运营不需要本地记录多个地址，同时平台还提供便捷的地区切换能力，极大的提升跨地区运营的便利程度。 国家码存储方案 用户选择国家之后，悟空需要存储当前地区的地区码、语言码、时区信息，并且对应地区的站点语言和生效时间都要和地区时区匹配，而平台本身除了新开tab需要携带地区信息外还有开发者组件、iframe嵌套需要获取地区信息的场景，针对这些场景，悟空平台采用三层级的国家码存储策略： ① 新开tab时，地区信息通过URL参数携带 ② Vuex Store存储，地区信息在应用状态中持久化存储，开发者可以在组件内通过store读取国家码信息。 ③ LocalStorage缓存，用户地区选择持久化到本地存储，适用于iframe嵌套场景。 如果父子iframe是同源策略可以直接读取LocalStorage，如果非同源策略可以通过postMessage获取地区信息。 三级存储有以下几点优势： 介绍完平台web侧的改造内容后，接下来会详细介绍悟空系统编译服务多地区化改造方案。该方案通过统一的配置管理、多机房部署策略、差异化构建流程等技术手段，实现了01地区、02地区、03地区 的全面支持。 整体架构设计 整体架构图 该架构图展示了悟空互动平台多地区改造的整体设计思路： 核心技术方案 整体方案设计完毕之后，我们接下来一层层解析每个环节的改造。 ① 统一环境配置管理 通过对context.ts文件进行改造，实现不同机房部署的统一入口处理。 通过上述代码，我们可以发现环境配置读取从只有一级的环境区分改造为机房信息+环境的二级目录结构，这样修改后服务启动时，代码内部通过env方法可以获取当前机房信息下对应环境的全部配置信息，方便全局调用。 核心特性： 统一配置入口改造完毕之后，接下来我们介绍下入口文件往下一层去查询每个机房各个环境具体配置信息的改造。 配置文件信息按地区和环境进行分层管理改造后，整体目录结构如下所示： 通过上述目录结构可以看出，不同机房的配置信息一目了然，相互独立，方便维护和定位问题，后续新增机房信息时，只需要按照当前规则添加即可，不需要额外关心内部业务逻辑。 整体流程分为以下四个步骤： ② ZooKeeper服务发现与调度改造 由于测试环境和预发环境都部署在01和02机房，通过模拟的方式支持01、02地区，而线上环境才是真正的物理隔离机房，因此在ZooKeeper服务发现中需要特殊处理（01、02为示例地区信息）： 核心调度逻辑改造如下： 通过上述代码，我们可以发现服务注册和发现都需要按照机房信息+环境信息作改造，这样可以有效避免测试环境和预发环境，站点编译时调度的机房出现异常，线上环境由于物理机房隔离，服务注册和发现可以不做调整。 介绍完环境隔离策略后，接下来我们介绍下不同环境的zk配置信息的改造。 测试环境（模拟多地区）： 预发环境（模拟多地区）： 生产环境（真实隔离机房）： 通过上述两个地方改造，服务发现分组策略如下所示： ③ 多机房构建策略 编译服务在生成站点时，还会对每个站点的主js文件做dll拆包处理，将公共依赖打包成独立的dll基座文件，降低页面的主资源体积，提升加载速度，那么针对多地区改造场景，我们会做哪些处理呢？ 针对不同地区我们需要使用不同的API包，实现差异化的DLL构建： 01地区DLL配置： 02、03地区DLL配置： 在基座dll文件构建时，由于多地区的登录、分享、埋点合规等存在较大差异，我们对多地区场景做了单独的底层库封装，dll文件生成需要根据不同地区分别构建并输出到不同目录。 修改dll配置文件时，同时也需要在 package.json 中配置不同地区的构建命令（01、02由于保密，均为地区示例信息）： 通过上述指令的改造，我们可以很清晰的看到不同地区的dll构建指令都根据region信息做了区分，方便后续的机房扩充和维护。 ④ Webpack多机房配置改造 这里主要介绍webpack打包时如何实现不同地区的dll动态引入，以及将国家码等信息编译到站点内。 不同地区的dll文件构建完毕之后，我们需要在 webpack.pkg.config.js 中实现基于地区的动态DLL引用： 通过上述示例代码，我们需要将不同机房构建dll文件时生成的manifest.json进行不同动态引入改造，避免站点运行时，相同依赖通过chunkid进行匹配时，出现错乱导致页面异常。 通过编译服务能够拿到平台web用户在哪个地区编译发布的站点，但是这些信息如何编译到用户可访问的每个站点里呢？ 我们通过wk_siteInfo将地区信息注入到前端： 通过修改webpack.config.js，将站点的地区信息、时区、语言码等信息注入到wk_siteInfo，然后通过htmlWebpackPlugin将打包后的地区码信息注入到html中，这样就能实现页面对地区信息读取。 ⑤多地区部署流程 构建流程图 该流程图详细展示了多地区构建部署的完整流程： 环境变量配置： 编译服务改造技术亮点 ① 统一入口设计 ② 差异化API包管理 ③ 服务发现机制 ④ 智能构建策略 ⑤ 前端代码隔离 通过上述的整套共线方案设计，后续新增国家机房时，新增地区只需配置相应环境文件，无需修改核心代码，配置结构清晰，各地区配置完全隔离，节约90%重复建设成本，提升了系统的灵活性和可扩展性。 通过统一的技术架构和清晰的配置管理，成功实现了"一套代码，多地部署"的目标，为悟空互动平台的多地区化业务发展提供了坚实的技术保障。 介绍完编译服务后，接下来介绍私服的代理策略和公共底层库的外销化改造。 npm私服 悟空除了服务业务运营，还有开发者部分，基于目前开发者整体的开发习惯，我们需要做到开发者零感知，实现02地区npm包的部署。 基于此我们有以下三点目标： 为了实现上述目标，我们做了一套完整的02地区私服方案设计，具体如下图所示： 开发者开发组件上传，维持01机房npm私服开发上传习惯，无需新增02机房源，npm物料仍然托管在01npm私服。 同时在02机房建设代理npm私服，通过ip白名单与悟空通信，私服本身通过verdaccioss服务配置代理： 通过02机房代理私服的方式，既能减少了悟空开发需要额外多维护02机房源，同时也降低了开发者组件包维护成本，实现本地不需要新增任何npm源，即可实现02机房包的开发上线流程。 底层库外销改造 wk-api是悟空平台封装的底层npm库，为了实现多机房场景下，业务组件多地区场景请求接口域名不变，我们通过fetch统一拦截器+header国家码信息，直接将业务组件的请求转发到不同国家的接口服务。 具体实现代码如下： 统一拦截器策略有以下优点： 悟空系统的整体改造从上到下可以分为用户能直观看到的平台改造，然后到用户感知不到的编译服务改造，最后是开发者也无需感知的外销私服部署，从前期梳理到后续一个个模块的拆解，出方案，进行开发落地，最终实现了以下目标：
一、目标
二、整体方案设计
三、模块拆解
3.1 平台改造
// i18n.js 核心配置
// 语言包配置，方便扩展
const messages = {
zh: { ...zh, ...zhLocale }, // 中文语言包 + Element UI中文
en: { ...en, ...enLocale } // 英文语言包 + Element UI英文
}
// 基于域名的地区检测 // 不同地区自动读取对应语言包
const domainConfigMap = new Map([
['****.vivo.com.cn', { region: '01', local: 'zh' }], // 01地区 读取zhLocale语言包
['****.vivo.com', { region: '02', local: 'en'}], // 示例：02地区 读取enLocale语言包
['in-****.vivo.com', { region: '03', local: 'en' }] // 示例：03地区 读取enLocale语言包
])
getUucLogin (key, region) => {
...
const locationUrl = getLocationUrl(region, env) // 回跳的链接根据地区信息来区分
return `${originMap[region][env]}/#/login?orgfrom=${locationUrl}/project${key}` // uuc登录地址融合地区信息和环境信息
}// 项目跳转时携带地区参数
goList(projectId) {
const params = { projectId: projectId }
const wkCountryInfo = Utils.tools.getCountryInfoParams() // 获取地区参数
const query = {...params, ...wkCountryInfo} // 合并参数
this.$router.push({ path: '/main', query: query })
}
// 例如 getCountryInfoParams 返回格式：{ loc: 'AA', lan: 'th_AA', tz: 'REGION/aa' }// Store中的地区信息存储
state: {
siteConfig: {
wkCountryInfo: {
loc: 'AA', // 地区信息
lan: 'th_AA', // 语言码
tz: 'REGION/aa' // 时区
}
}
}
// 获取Store中的地区信息
const storeCountryInfo = store.getters['edit/snapInfo'].wkCountryInfo || store.getters['interactive/snapInfo'].wkCountryInfo// 地区切换时的存储逻辑
changeRegion(value) {
const item = this.headerRegion.list.find(v => v.countryCode === value)
const wkCountryInfo = {
loc: item.countryCode, // 如：'AA', 'BB', 'CC'
lan: item.languageCode, // 如：'th_AA', 'en_BB', 'zh_CC'
tz: item.timezone// 如：'REGION/aa', 'REGION/bb'
}
localStorage.setItem('__wk_platform_region_info_', JSON.stringify(wkCountryInfo))
}3.2 编译服务改造
// 示例代码
// server/src/app/extend/context.ts
get env(): Ienv {
return env[process.env.REGION || 'AA'][(this as any).app.config.env]
}
// 目录结构：
server/src/app/util/env/
├── index.ts # 配置入口
├── 01 # 01地区配置
│ ├── index.ts
│ ├── local.ts
│ ├── test.ts
│ ├── prod.ts
│ └── ...
├── 02 # 02地区配置
│ ├── index.ts
│ ├── test.ts
│ ├── prod.ts
│ └── ...
└── 03 # 03地区配置
├── index.ts
├── test.ts
├── prod.ts
└── ...
// server/src/app.js
const isTestOrPreEnv = process.env.EGG_SERVER_ENV.includes('test') || process.env.EGG_SERVER_ENV.includes('pre');
// 添加机房信息
let group = isTestOrPreEnv ? `${process.env.REGION || 'AA'}-${process.env.EGG_SERVER_ENV}`: process.env.EGG_SERVER_ENV
const serviceClient = new BeehiveService({
zkhost: ctx.env.zkHost,
pong: true,
services: {
siteService: ctx.service.site,
dspService: ctx.service.genDsp
},
config: c.Config(c.group(group), c.maxTimeout(3 * 60 * 1000))
})// 所有地区测试环境都使用同一个ZK集群
zkHost: 'zookeeper-*****.vivo.xyz:2183'
// 但通过group区分：01-test, 02-test, 03-test// 所有地区预发环境使用同一个ZK集群
zkHost: 'common-zk-****.vivo.lan:2181'
// 通过group区分：01-prev, 02-prev, 03-prev// 机房1（示例名称）
zkHost: 'common-*****-zk.vivo.lan:2181'
// 机房2（示例名称）
zkHost: 'in-common-*****-zk.vivo.lan:2181'
// 机房3（示例名称）
zkHost: 'app.*****.zk.prd.****.vivo.lan:2181'// webpack.dll.config.js
const vendors = [
....
'@vivo/wk-api', // 01地区专用API
'vue-lazyload',
]
module.exports = {
output: {
path: path.join(__dirname, './dll'), // 输出到dll目录
filename: '[name].[hash].js',
},
// ...
}// webpack.dll.02.config.js //webpack.dll.03.config.js
const vendors = [
....
'@vivo/asia-wk-api', // 02、03地区专用API
'vue-lazyload',
]
module.exports = {
output: {
path: path.join(__dirname, './dll-02'), // 输出到dll-02目录或者dll-03
filename: '[name].[hash].js',
},
// ...
}//代码示例
{
"scripts": {
// DLL构建
"dll": "npx webpack --config webpack.dll.config.js",
"dll:01": "npx webpack --config webpack.dll.01.config.js",
"dll:02": "npx webpack --config webpack.dll.02.config.js",
// 服务启动
"start_test_01": "EGG_SERVER_ENV=test REGION=01 yarn dock_start",
"start_prev_01": "EGG_SERVER_ENV=prev REGION=01 yarn dock_start",
"start_prod_01": "EGG_SERVER_ENV=prod_wk REGION=01 yarn dock_start",
"start_test_02": "EGG_SERVER_ENV=test REGION=02 yarn dock_start",
"start_prev_02": "EGG_SERVER_ENV=prev REGION=02 yarn dock_start",
"start_prod_02": "EGG_SERVER_ENV=prod_wk REGION=02 yarn dock_start"
}
}// 代码示例
// webpack.pkg.config.js
const dllReferencePlugin = config.plugins.find(plugin => {
const name = plugin.constructor.name
if (['DllReferencePlugin'].includes(name)) {
returntrue
}
})
if (dllReferencePlugin && dllReferencePlugin.options) {
dllReferencePlugin.options.context = pageTempPath
// 动态dll文件引用改造，根据wukong.region：01,02,03 来设置manifest路径
const DLL_DIR = wukong.region === '02' ? 'dll-02' :
wukong.region === '03' ? 'dll-03' : 'dll'
dllReferencePlugin.options.manifest = require(`./${DLL_DIR}/manifest.json`)
....
}// webpack.pkg.config.js
const site_option = {
host: ip.address(),
port: 8080,
stPath: '****',
loginPath: '****',
wk_siteInfo: {
siteId,
....
wkCountryInfo, // 地区信息、时区、语言码信息
region, // 地区信息
},
...wukong
}
// 完成地区信息的注入
// index.html
<script>
// 示例代码 ：window.wk_siteInfo = JSON.stringify(htmlWebpackPlugin.options.wk_siteInfo)
</script>
3.3 npm私服\&底层库
uplinks:
zhan-npm:
url: http://****.vivo.lan:8080
packages:
'**':
...
# allow all known users to publish packages
# (anyone can register by default, remember?)
# if package is not available locally, proxy requests to 'npmjs' registry
proxy: zhan-npm
// 请求拦截器 - 动态URL路由
axios.interceptors.request.use(config => {
const { region } = app;
// 根据region动态获取prodUrl
if (region === '01') {
config.baseURL = 'https://****.vivo.com.cn';
} elseif (region === '02'||region === '03') {
config.baseURL = 'https://****.vivo.com';
}
// 请求头注入
if (wkCountryInfo.loc; wkCountryInfo.lan; wkCountryInfo.tz) {
code = `loc=${wkCountryInfo.loc};lan=${wkCountryInfo.lan};tz=${wkCountryInfo.tz}`;
loc = wkCountryInfo.loc;
}
config.headers = Object.assign(config.headers, {
'X-I8n-Code': code,
'X-Wukong-Loc': loc
});
return config;
});四、总结
低代码一度是企业软件行业最火爆的概念之一。不管是国内还是国外，低代码都是行业领头羊的标配。比如，国外的Microsoft Corporation、Oracle、Salesforce，国内的金蝶、用友、北森等。 但随着各种AI大模型的问世，低代码的消息似乎很少再听到了。 前几天，有个创业者后台私信我：老师，现在AI都能写代码了，你说低代码这个赛道还有前途吗？会不会过两年就变成一堆没人要的电子垃圾？ 这个问题问得挺扎心的。特别是作为一名业内人士，我表示很慌！ 不过正好，我最近在研究一家深圳的公司，叫织信，他们家就是做低代码出身的。公司叫基石协作。今天借着他们家的情况，聊聊我的看法。 一、低代码到底是个什么东西？ 很多人对低代码有误解，觉得低代码就是“拖拖拉拉，拼拼凑凑”，做个简单的表单、搞个审批流，仅此而已。你要是这么理解，那确实，AI来了，这玩意儿第一个被淘汰。 但真正的低代码，没那么简单。 织信的创始人跟我说过一句话，我印象很深：“低代码本质上不是拖拽，是企业应对变化的战略能力。” 什么意思？ 你看啊，任何一个企业，只要活过三年，一定会遇到一个问题：现有的软件不好用了。业务变了，流程改了，但软件改不动。 不改吧，业务跑不顺。改吧，找原厂报价，动辄几十万，排期半年后。 自己招人开发，一个高级工程师月薪两三万，招三个，干一年，成本怎么也得一百万左右。最后终于等到系统做好，但是业务需求已经发生改变，这个速度实在跟不上脚步了。 这就是企业的真实困境。 而低代码解决的就是这个问题。 低代码开发模式让企业能用相对低的成本，快速响应业务的变化，能给企业提供一套“可生长的数字底座”。 二、低代码的真正门槛：不是技术，是钱 但是，做低代码有个巨大的坑：太烧钱了。 有多烧钱呢？ 据我所知，国内几家头部SaaS公司在低代码平台上的投入，都是以“亿”为单位的。北森的纪伟国甚至说过一句话：为了做PaaS，北森差点掉进坑里爬不出来。 织信也不例外。 他们从2018年开始做低代码，一做就是8年。前两年几乎没有任何市场声音，就是埋头写代码、搭架构。创始人跟我说，那几年最难的时候，团队每天都在问自己：我们是在做一件正确的事，还是在往坑里跳？ 为什么要这么死磕？ 因为低代码这东西，没有捷径。你要让企业能“低代码”开发，首先你自己得把那些复杂的底层逻辑都用代码写好。权限模型、数据模型、流程引擎、API网关……每一个模块都得从零搭起来。这不是“低代码”，这是“高投入”。 那为什么还要做？ 两个原因。 第一，全代码开发的成本，企业扛不住。一个中型企业，一年IT预算就几百万，全用来养开发团队都不够，更别说应对业务变化了。 第二，用全代码写的功能，系统一升级就容易崩。原因在于你今天写个插件，明天原厂系统升级，插件就废了。而低代码配置出来的功能，天然和核心系统解耦，兼容性好得多。 所以，低代码产品赌的就是：企业需要的不是更便宜的代码，而是更敏捷的业务。 三、AI来了，低代码慌不慌？ 回到开头那个问题：AI都能写代码了，低代码会不会被淘汰？ 说实话，这个问题确实问到了点子上。 你想啊，以前为什么需要低代码？因为写代码贵、写代码慢、写代码的人不好招。现在AI来了，写代码的成本正在断崖式下跌。一个初中生，用Cursor，可能一天就能写出一套小程序。 那低代码的价值在哪？ 织信的团队给了我一个很有意思的视角：“以前是人用软件，以后是AI用软件。” 你仔细想想，AI怎么用软件？ 今天AI写代码，本质上还是在模仿人的操作——识别界面、点击按钮、输入内容。但软件是为人类设计的，按钮是给人点的，菜单是给人看的。AI用这套东西，就像让你用筷子喝汤，能喝，但别扭。 未来的软件，应该是为AI设计的。 什么意思？ 就是软件不再只有“人机界面”，还要有“机机界面”。AI可以直接调用软件的能力，不需要通过界面。 这时候，低代码的价值就出来了。 因为低代码平台天然是结构化的。你在低代码平台里建一个“客户表”，系统知道这是“客户”；你设一个“合同金额”字段，系统知道这是“金额”。所有的数据、流程、权限，都有清晰的语义。 这套结构化的东西，恰恰是AI能理解的。 很多低代码缠上现在就在做一件事：把他们的低代码平台，从一个“面向人类的开发工具”，进化成一个“面向AI的操作系统”。 他们提供语义能力——AI可以直接问“上个月签了多少合同”，系统知道“合同”是什么，“签”是什么意思。 他们提供图谱能力——AI能看懂业务流程的全貌，知道从“线索”到“商机”到“合同”是怎么流转的。 他们提供接口能力——AI可以直接调用系统能力，帮你创建一个项目、发起一个审批、生成一份报表。 你看，这不是低代码被AI干掉，而是低代码成了AI的“操作手册”。 四、最后的话 简单再总结一下这个问题：AI能写代码了，低代码会不会变成一堆垃圾？ 我的答案是：会，也不会。 那些只会做“拖拉拽”的低代码，一定会被淘汰。因为当代码本身变得廉价，“不用写代码”这个优势就不存在了。 但那些能帮助企业构建“结构化数字能力”、能成为“AI操作系统”的低代码，不仅不会被淘汰，反而会成为企业数字化的核心底座。 就像低代码正在做的——他们不是在和AI竞争，而是在为AI铺路。 最后说一句：任何技术都有生命周期，但企业应对变化的需求，永远不会消失。 只要这个需求在，低代码就有存在的价值。只是，它需要进化。 而进化的方向，不是和AI比写代码，而是让AI更懂业务。 这才是真正的“低代码”。
在 LoRaWAN 项目部署过程中，如何快速完成传感器数据解析与物模型构建，是影响交付效率的关键因素。ThinkLink 物模型引擎全面兼容 TTN 与 ChirpStack 的 Decoder 解码机制，可直接复用厂商提供的解码脚本，显著缩短部署周期。本文以 星纵智能 的 EM300-SLD 水浸传感器为例，详细说明如何在 ThinkLink 上完成物模型配置。 EM300-SLD 官方解码脚本地址： https://github.com/Milesight-IoT/SensorDecoders/blob/main/em-series/em300-sld/em300-sld-decoder.js ThinkLink 支持 ChirpStack / TTN 标准解码格式，无需改写函数框架，仅需确认输出字段名称。 进入 ThinkLink 平台 → 模型管理 → 新建模型： 此时平台已具备解析原始 Payload 的能力。 ⚠ 关键注意：字段“标识符”必须与 Decoder 返回字段完全一致。 建议添加字段： 完成字段配置后保存。 进入设备管理页面： 设备再次上报数据后即可实时展示结构化数据。 ThinkLink 支持在 Decoder 基础上进行二次开发： 通过“解析 + 计算 + 建模”一体化能力，实现更智能的数据建模方式。 ThinkLink（TKL）结合 EdgeBus（EB）边缘能力，可实现： 该模式尤其适用于传统有线传感器升级 LoRaWAN 场景。 如需设备对接支持，欢迎联系门思科技。 ThinkLink 体验地址一、步骤一：获取官方 Decoder 代码
二、步骤二：创建 ThinkLink 物模型
三、步骤三：配置实时数据字段
四、步骤四：绑定物模型到设备
五、进阶应用：数据增强与逻辑扩展
六、TKL + EB 组合方案：LoRaWAN 存量改造新模式
免费提供对接服务，仅需提供样品及说明文档即可启动流程。
https://thinklink.manthink.cn
V 友们好，我是 Most.Box 的独立开发者。
作为一个喜欢瞎折腾的程序员，我一直有个执念：我们的数据到底属于谁？
Notion 体验很好，但数据在别人的服务器上；网盘空间很大，但动不动就和谐文件。如果不掌握数据的所有权，在这个数字时代，我们其实是在“裸奔”。
很多懂 Web3 的朋友会说，用 IPFS 啊，用去中心化存储啊。但现实是，让普通人去保管 12 个英文单词组成的“助记词”太反人类了。丢了助记词，资产全无；被盗了，神仙难救。
于是，为了对抗遗忘，为了守护记忆与隐私，我利用业余时间开发了 Most.Box。你可以把它当作一个永不丢失、绝对私密、抗审查的个人知识库。
🛠 它是怎么解决上述痛点的？
💬 写在最后
我始终相信“代码即武器”。在这个充满不确定性的世界里，我们要用技术武装自己，把数据的控制权从巨头手中拿回来。
目前项目的前端已经完全开源 (MIT 协议)，没有任何黑盒操作。
刚刚开发完成，肯定还有很多 Bug 和粗糙的地方。诚挚邀请 V 站的各位大佬体验、捉虫、吐槽。如果有感兴趣参与开源贡献的，也极其欢迎！
从 2025 年初开始，大模型领域进入了新一轮加速发展阶段。随着大模型在企业内部系统和生产环境中的落地，大模型推理逐渐演化为一类重要的基础设施能力。在这一背景下，围绕大模型推理访问、资源管理与安全控制的 AI 网关（AI Gateway） 受到了业界的广泛关注（参见参考资料 [1] [3] [5]）。 由于 AI 网关仍处于快速演进阶段，不同厂商和社区对其定位与边界的理解并不完全一致。本文尝试基于当前较为主流的工程实践，对大模型推理场景中的工作机制 以及 AI 网关的角色、作用和分类方式 进行系统性说明。 在说明 AI 网关之前，有必要先明确大模型推理场景的基本工作机制。 图1 大模型推理场景的工作机制 站在“智能体（Agent）”的视角，一个典型的大模型推理场景可以抽象为以下几类交互关系（见图1）： 在接口层面，OpenAI API [6]的接口语义正在逐步成为事实上的接口参考标准（de facto standard），但在底层推理系统和企业内部场景中，仍然存在大量非 OpenAI 协议的实现方式。与此同时，MCP（Model Context Protocol）[7]等协议更多用于工具能力描述和上下文编排，其底层调用仍然依赖 HTTP、gRPC 或内部 RPC 等通信机制。对于智能体之间的协作，也正在出现 A2A（Agent to Agent）[8]等新型协议尝试。 图2 大模型推理场景中的网关 在上述推理场景中，随着调用链条变长、资源成本上升以及安全风险增加，单纯依靠传统 API 网关已难以满足需求。围绕大模型推理，业界逐步形成了三类不同侧重点的“网关型能力”[2]（参见图2）： 需要说明的是，上述分类主要是从功能和职责视角对大模型推理场景中的网关能力进行拆分。在实际工程实现中，这些能力可能由同一个网关系统统一承载，也可能以插件、子模块或独立组件的形式存在，其具体形态取决于系统规模、组织复杂度以及对稳定性和演进性的要求。 本文后续将重点讨论 推理网关 与 AI 网关。智能体网关由于仍处于快速演进阶段，这里不做展开，感兴趣的读者可参考资料 11。 推理网关并不直接执行模型推理，其核心职责是： 可以将推理网关理解为 连接推理客户端与底层推理实例的重要控制节点。 图3 推理网关的工作场景 如 图3 所示，在一个 Kubernetes 集群中，通常会部署多种不同规格或不同模型的推理资源（例如 Qwen-72B、DeepSeek-32B 等）。每一种模型资源对应一个推理池（Inference Pool），而一个推理池中则包含多个推理实例。 推理网关的核心工作包括： 与传统基于 CPU 的服务实例相比，基于 GPU 的推理实例在调度层面存在显著差异： 因此，在推理实例选择上，简单的轮询或最小连接策略往往难以取得理想效果，需要结合实例负载、缓存状态、排队情况等多维信息进行调度。 目前，业界已经出现多种实现方案（参见 [4] [9] [10]）。其中，Gateway API Inference Extension [4]作为 Kubernetes 社区的官方项目，引入了 EPP（EndPoint Picker）[9]作为独立的调度组件（见 图 3）。EPP 负责感知推理实例状态，并向推理网关返回合适的目标实例。 上述对比主要针对典型 Web 服务负载与大模型推理负载的差异进行说明，实际生产环境中仍需结合具体模型特性和业务请求模式进行设计。 AI 网关最重要的职责是 对 LLM 资源消费进行统一控制。 图4 传统服务网关的工作场景 在传统服务网关场景中（见 图 4），不同业务通常对应各自独立的服务资源，网关的主要任务是完成路由和基础治理。而在大模型推理场景中，由于推理资源成本高昂，不同业务往往需要共享同一组推理资源池（见 图 5）。 图5 AI网关的工作场景 在这种模式下，AI 网关需要承担以下职责： 对入向提示词和出向模型结果进行内容安全检测，也是 AI 网关的重要能力之一。 在工程实践中，通常会将内容安全检测系统独立部署（参见 图 5），由 AI 网关通过远程调用的方式进行集成。这种模式具有以下优势： 在实际落地过程中，往往需要结合同步检测、异步审计以及分级处置策略，在安全性与端到端延迟之间取得平衡。 为LLM的调用提供统一入口，是 AI 网关的另一项关键价值。 在单LLM资源池场景下（见图6），AI 网关与推理网关往往可以合并部署，由同一组件同时完成资源消费控制和实例级调度。 图6 AI网关的工作场景（单LLM资源池） 而在多LLM资源池场景下（见图7），AI网关和推理网关会分离部署。对于LLM的消费者来说，只需要发送请求到AI网关，而不需要关心LLM资源池的具体物理位置。AI网关会基于预置的调度比例、LLM资源池的忙闲状态、访问速度、成本等信息，将请求发往合适的LLM资源池。 在该场景下，AI 网关实际上承担了跨推理池、跨模型、甚至跨地域和跨云环境的二级调度角色，用于在成本、性能和可用性之间进行全局权衡。 图7 AI网关的工作场景（多LLM资源池） 本文围绕大模型推理场景，对 AI 网关的产生背景、核心作用以及3种AI网关职责（推理网关、AI网关、智能体网关）之间的关系进行了系统性说明。 总体来看，AI 网关并不是一个单一形态的产品，而是一组围绕大模型推理逐步演进的关键能力集合。在成本控制、安全合规、访问质量和系统演进性等方面，AI 网关都将发挥越来越重要的作用。 随着大模型推理基础设施的持续发展，可以预见，AI 网关将在未来几年内成为企业级 AI 系统架构中的关键组成部分。 章淼，博士，1994年进入清华大学计算机科学与技术系学习，2004年获得博士学位，2004年至2006年在清华大学留校任教，在清华期间曾参与中国第一代核心路由器的研制工作。2012年起在百度工作超过十年，聚焦云网络基础架构的研发工作，是BFE开源项目的发起人。在百度期间积极推动软件工程能力提升，曾担任百度代码规范委员会主席，2021年10月被授予百度代码规范委员会荣誉主席。2022年出版《代码的艺术：用工程思维驱动软件开发》。2023年4月起担任瑛菲网络CEO，聚焦研发面向云和大模型场景的现代化流量管理平台。
引言
1. 大模型的推理场景
2. 大模型推理场景中的网关
3. 推理网关(Inference Gateway)
推理网关的定位
推理网关的工作场景
GPU 推理调度的复杂性
4. AI网关(AI Gateway)
AI 网关的核心职责
安全与合规控制
统一入口与多资源池调度
5. 总结
参考资料
作者简介
