作者：王博涵 小步外勤产品总监，外勤管理数字化专家

在外勤人员占比较高的企业中，管理难点往往并不在于制度本身，而在于执行过程是否真实可控。

员工每天在外奔波，管理层却很难持续判断行程是否合理，现场是否到位，费用是否按实际发生。

过去数年里，定位打卡曾一度成为外勤管理的常用手段。但随着业务规模扩大，这种以点位记录为主的方式，很难支撑过程管理。定位无法连成轨迹，停留无法量化，外勤行为仍然处在不可验证的状态。

故而近几年越来，越多的企业开始将人员定位管理系统引入到外勤管理体系中，用更连续、更真实的数据，支撑人效管理和费用管控。

从实际应用情况来看，目前人员定位管理系统主要呈现出三种不同的发展方向。

当前人员定位管理系统的三种常见形态

第一类 偏基础的定位考勤系统

这一类系统多是从行政考勤延伸而来的，常见于通用办公平台中。其主要功能便是记录上下班位置，配合简单的地理围栏，解决是否到岗的问题。

这类系统在人员规模较小、外勤占比不高的企业中有一定的实用价值。但在实际外勤场景中，它们往往只能记录零散的定位点，无法形成完整轨迹，也无法判断员工在客户现场的真实停留情况。

同时，防作弊能力相对有限，对虚拟定位、位置修改等行为缺乏有效识别手段。

因此，这类产品更适合作为基础考勤工具，而不是完整意义上的人员定位管理系统。

第二类 面向业务过程的人员定位管理系统

随着外勤管理要求的不断提高，越来越多企业开始关注过程真实性和执行质量。而这正是管控型人员定位管理系统的核心价值所在。

这一类系统不再只是关注员工有没有到达，而是重点解决几个关键问题：是否真实到场，是否按要求完成拜访或巡检动作，路线是否合理，费用是否真实发生。

围绕这些真实的管理需求，人员定位管理系统也在不断演进，从单一记录位置，逐步走向对过程真实性和执行质量的管理：

• 在定位层面：通过低功耗持续定位，还原员工全天的外勤轨迹，形成清晰的时间线。系统会自动分析每个点位的停留时长，帮助管理者识别异常拜访和形式化执行。
• 在防作弊层面：通过对手机运行状态和定位行为的综合判断，识别虚拟定位、模拟轨迹、异常失联等情况，并形成异常记录，避免外勤过程成为管理盲区。
• 在取证层面：现场拍照会自动生成包含时间、地点、人员信息的水印内容，便于后台快速核验，减少人工反复确认的成本。
• 在费用管理方面：基于真实轨迹自动核算里程，为油补和差旅报销提供可靠依据，减少人为填报带来的误差和风险。

这一类人员定位管理系统，已经成为快消巡店、医药代表拜访、物业巡检、自备车销售等场景中的主流选择。

第三类 面向安全场景的增强型定位系统

在部分高风险行业，人员定位管理的核心目标并不在于效率，而在于安全。

这类系统通常结合室内高精度定位、传感设备或卫星通信技术，实现更高精度的人员定位和状态监测。例如在矿井、化工园区、电力施工等场景中，用于实时掌握人员位置，并在发生异常时及时预警。

由于其建设成本和部署复杂度较高，这类系统通常只适用于特定行业，并不适合大多数日常外勤管理场景。

如何判断人员定位管理系统是否真正适合企业

在选型过程中，企业很容易被各种功能描述吸引，但真正决定系统价值的，往往是其是否贴合实际管理逻辑：

首先是定位数据是否连续可信，只有能够还原完整轨迹，定位数据才具备管理意义。

其次看系统是否围绕真实业务流程设计，是否支持巡店、巡检、拜访等标准动作的顺序执行，是否能够通过定位约束避免走形式。

然后看费用数据是否基于真实行为产生，如果里程和补贴仍然依赖人工填写，那么人员定位管理系统的价值就会大打折扣。

最后还要看系统是否具备长期落地能力，外勤管理不是一次性全部上线，而是需要持续优化制度和流程的，这对服务能力提出了更高要求。

人员定位管理系统选型建议

从实际使用情况来看，不同企业的需求差异明显：

• 如果企业主要解决考勤问题，外勤比例较低，基础定位功能即可满足需求。
• 如果企业希望提升外勤执行力，确保过程真实，同时优化人效和费用结构，那么以过程管理为核心的人员定位管理系统，如小步外勤更为合适。
• 如果企业处于高危或特殊作业环境，应优先考虑以安全为目标的深度定位方案。

最后，需要清楚的是人员定位管理系统的价值，从来不只是记录位置本身，而在于通过真实数据，让外勤管理从经验判断走向客观决策。

——覆盖芯片制造、封装测试、智能仓储与供应链协同的一体化智造平-台

在半导体国产化加速与高端电子制造升级的双重驱动下，电子制造企业（涵盖晶圆厂Fab与封测厂OSAT）正面临前所未有的挑战：工艺复杂度指数级上升、客户追溯要求严苛至单颗芯片、物料成本占比超60%、设备停机1分钟损失数万元。传统ERP+WMS+通用MES的割裂架构已难以为继。

万界星空电子制造行业专属MES系统——深度融合芯片制造（前道）、电子封装测试（后道）、智能仓储与供应链执行的全栈式解决方案，真正实现从“硅片进厂”到“芯片出货”的端到端闭环管控。

一、行业痛点：为何通用系统失效？
芯片制造（Fab） 工艺步骤超千道，Lot路径动态分裂；设备Recipe毫秒级同步；缺陷根因分析依赖跨工序数据

电子封装（OSAT） 多芯片异构集成（SiP/Chiplet）；金线/塑封料温湿度敏感；汽车电子需满足AEC-Q100追溯

供应链与仓储 关键物料（光刻胶、金线）保质期短；洁净室库位管理复杂；投料错配=整批报废

共性需求 全链路追溯（Wafer→Die→Package→终端产品）、EHS合规、OEE提升、零缺陷交付

普通MES仅关注“报工”，而电子制造需要的是以物料流、信息流、控制流三流合一的智能执行中枢。

二、系统整体架构：前道+后道+仓储一体化

见图

三、电子行业MES核心功能体系

✅ 1. 芯片制造（Fab）全流程管控

• Lot/Wafer级追踪：支持Split/Merge操作，记录每片晶圆上千道工序历史；
• Recipe与设备闭环：下发工艺配-方至设备，实时监控腔室参数，异常自动Hold Lot；
• 缺陷智能分析：集成AOI/E-beam数据，自动关联工艺步骤与设备，生成Yield根因报告；
• 洁净室EHS监控：粒子数、压差、特气泄漏实时告警，保障Fab安全运行。

✅ 2. 电子封装测试（OSAT）高精度执行

• 先进封装支持：管理Fan-Out、2.5D/3D、SiP等工艺，绑定RDL、TSV、Microbump数据；
• 全流程防错：贴片扫码校验Die与基板匹配，回流焊曲线自动比对，X-ray未检禁止流转；
• 测试数据闭环：ATE（CP/FT）结果自动归集，不良品关联失效模式，驱动FA分析；
• 汽车电子合规：一键生成PPAP文件包，满足IATF 16949与AEC-Q100要求。

✅ 3. 采购与供应商协同（MES驱动）

• 智能物料需求：基于MPS与BOM，自动计算光刻胶、金线、靶材等关键物料净需求；
• 供应商门户：共享交付计划、质量标准、包装规范，支持ASN电子化；
• 来料质量预控：COA（分析证书）预加载，IQC结果自动比对，超标物料冻结。

✅ 4. 智能投料与物料防错

• Fab投料校验：启动Lot前，校验光刻胶有效期、靶材使用次数、特气余量；
• OSAT投料拦截：Die Bin码、基板烘烤状态、湿度卡不合格 → 设备联锁停机；
• FIFO与效期管控：化学品按开封时间强制先进先出，超期自动锁定。

✅ 5. 精细化出入库与仓储管理

• 智能库位分配：

  • 恒温区（光刻胶）、氮气柜（金线）、防静电架（FOUP）自动匹配；
• AMHS/AGV协同：MES下发配送任务，自动送物料至机台口；
• 库存实时可视：展示在库量、库龄、洁净室水位，预警呆滞与缺料风险；
• 退料与危废管理：不良品隔离、废酸废溶剂登记，满足EHS审计。

✅ 6. 全链路追溯与合规

• 正向追踪：某片晶圆 → 切割Die → 封装成品 → 终端手机型号；
• 反向溯源：客户投诉 → 精准定位至光刻层、刻蚀机台、贴片时间、测试Bin；
• 电子批记录（EBR）：自动生成不可篡改档案，支持FDA 21 CFR Part 11、ISO 9001。

✅ 7. 设备物联与智能排产

• 千台设备接入：通过SECS/GEM、OPC UA对接中微、北方华创、ASM等设备；
• OEE自动分析：精准统计时间开动率、性能率、良品率；
• 柔性排程：Fab按腔室可用性调度，OSAT考虑模具准备与交期，支持插单模拟。

四、实施价值
产品良率（Yield） ↑ 2–5%（缺陷根因快速定位）

设备综合效率（OEE） ↑ 10–15%（减少非计划停机）

物料错用事故 ↓ 90%（投料防错拦截）

库存周转率 ↑ 20%（智能FIFO+呆滞预警）

追溯响应速度 从“天级” → “分钟级”

客户飞检通过率 100%（电子批记录完整合规）

**在“中国芯”崛起的时代，
制造的竞争力不再仅靠设备，而在于数据驱动的协同力、过程受控的稳定性与快速响应的柔性力。**
电子行业MES——不止于执行，更赋能中国电子制造迈向自主、高效、可靠的新纪元。

📞 立即预约，获取《电子制造行业数字化转型MES解决方案》+ 行业免费Demo演示！

近日，在中国信通院组织开展的 2026 上半年批次“可信数据库”测试中，涛思数据 TDengine IDMP 成为截至目前唯一一家全项完成“基于 AI 大模型的时序数据管理平台”基础能力检验的产品。

经中国信通院测试验证，TDengine IDMP 符合《基于 AI 大模型的时序数据管理平台技术要求》标准的全部能力要求，覆盖 AI 时序数据应用、时序数据建模与组织、情景化与标准化、实时分析、事件管理、安全与扩展性等关键能力方向。这也标志着 TDengine IDMP 在 AI 大模型与时序数据深度融合的工业数据平台领域，已达到国内技术先进水平。

《基于 AI 大模型的时序数据管理平台技术要求》标准简介

为规范基于AI大模型的时序数据管理平台技术和能力，指导提升AI大模型在时序数据领域的管理、建设应用，促进相关技术创新发展，完善行业协同生态，中国信通院依托CCSA TC601开展《基于AI大模型的时序数据管理平台技术要求》标准编制工作，围绕AI时序数据应用、时序模型管理、时序数据建模和组织、时序数据情景化、时序数据标准化、时序数据预处理、时序数据可视化、时序数据实时分析、事件管理、时序数据服务、平台管理、兼容性和扩展性、安全性等维度进行规范，为相关产品的应用落地提供了可供参考的技术规范。

TDengine IDMP：AI 原生工业数据管理平台的四大核心优势

作为时序数据库领域的长期实践者，涛思数据的 TDengine TSDB 已在工业、物联网等场景中广泛应用，覆盖智能制造、能源、电网、石油石化、汽车、矿山、新能源、制药、IT 基础设施等众多行业。

随着 AI 技术与工业互联网、物联网的深度融合，企业对数据平台的要求正在从“能存、能查”，升级为“能理解、能推理、能主动给出决策线索”。

在这一背景下，涛思数据于 2025 年 7 月正式发布 TDengine IDMP（AI 原生的工业数据管理平台），与 TDengine TSDB 协同演进，从底层架构重构工业数据平台能力，打通数据采集、汇聚、存储、分析、实时计算、可视化、事件管理与智能洞察的全链路，帮助企业以极高的性能、极低的成本和极简的体验，全面释放数据价值。

TDengine IDMP 具备以下四大核心优势：

• 无问智推，数据自己说话：无需主动提问，基于采集的数据，TDengine IDMP 能够利用 LLM，自动感知应用场景，自动生成场景特有的的指标、可视化面板、报表和实时数据分析。无需业务知识的多年积累，无需主动查询，核心洞察主动推送。
• 智能问数，实时分析零等待：除 AI 主动推送的面板、分析之外，用户还可以用自然语言主动提问与数据相关的任何问题。无需数据分析师、IT 工程师的帮助，AI 基于采集的数据实时给予答案，即可形成行动方案。从提问到决策，分钟级闭环。
• 工业数据全栈解决方案：与 TDengine 时序数据库一起，为工业数据管理提供从数据采集、清洗、情景化、标准化，到存储、查询、实时分析、预测、异常检测，再到可视化、事件管理等全栈的解决方案。架构极简，运维轻量化。
• 开放的企业级应用：支持单点登录、基于角色的权限控制、数据模型版本管理，提供数据备份、异地容灾与实时分发能力，支持虚机与容器化部署，兼容 Windows 与 Linux，可与 MES、ERP、AI 等企业应用系统无缝集成。

唯一完测，赋能百业，智驱未来

作为截至目前唯一一家全项通过中国信通院基于 AI 大模型的时序数据管理平台基础能力检验的产品，TDengine IDMP 在推出不足半年内，已在能源、化工、智能制造、交通、食品等多个行业实现落地应用，客户覆盖海内外市场。

此次全项完测，不仅是对 TDengine IDMP 技术体系完整性与成熟度的权威验证，也体现了涛思数据在 AI 与时序数据融合方向上的长期投入与工程实践能力，标志着 TDengine IDMP 在这一领域的成熟度已达到国内领先水平。

面向未来，涛思数据将持续提升平台的开放性、实时性与智能化水平，推动 AI 真正参与工业数据消费与决策过程，为企业数字化与智能化转型提供更加可靠、可持续的技术底座。

一、数据中心巡检之“困”

数据中心与智算中心作为数字基础设施的核心，其稳定运行依赖高频次、高精度的日常巡检。在以人力为主的运维模式下，巡检工作正面临系统性瓶颈。

当前的巡检模式，已逐渐无法满足现代数据中心日益提升的巡检需求。AI时代下，以智能巡检机器人为代表的自动化方案，正逐步成为行业的新选择。

二、从轨道到全地形：数据中心巡检机器人的演进之路

数据中心包含动力、暖通、机房等多个系统，空间结构天然存在梯坎、门槛、斜坡等复杂地形，对巡检载体的通过性提出持续挑战。

近年来，四足等全地形机器人在其他领域被广泛应用，但在数据中心狭窄通道、防静电地板等环境中面临实用性障碍，尚未有效落地。

真正适合数据中心的巡检载体，必须在通过性、效率与可靠性之间取得平衡——这为轮足机器人的出现提供了明确方向。

三、轮足机器人：数据中心巡检中通过性、效率与可靠性的平衡之选

在智能巡检载体的形态探索中，轮足式机器人，逐渐被视为数据中心场景的一种理性选择。它融合轮式底盘的高效、低噪与长续航优势，同时具备跨越台阶、斜坡等非平整地形的能力。

稳定上楼梯

轻松过门槛

相比纯轮式机器人受限于地面条件，履带或四足方案又普遍存在噪音大、速度慢、维护复杂等问题。轮足构型在通过性、作业效率与长期运行可靠性之间实现了有效平衡，可在不改造建筑结构的前提下，适应多楼层、多房间的复杂布局，满足数据中心对稳定和连续作业的要求，真正推动巡检范围从单机房走向全站覆盖。

四、云智慧 Cloudwise X1：专为数据中心打造的轮足巡检机器人

云智慧Cloudwise X1 并非通用轮足平台的简单移植，而是云智慧针对数据中心多地形环境（楼梯、斜坡、窄道、门槛等）深度定制的轮足巡检机器人。

其轮足底盘具备20cm越障与30°爬坡能力，可自主上下电梯、穿越台阶与狭窄通道，轻松应对跨楼层复杂场景。

在运营超过5年的混合架构机房中，云智慧Cloudwise X1 轮足巡检机器人无需改造地面或加装导轨，即可实现全站无死角覆盖，巡检范围从单一机房扩展至动力、暖通、IT机房及消防等多个区域。

在移动能力之外，云智慧Cloudwise X1  轮足巡检机器人的作业体系全面面向数据中心需求构建：

* 7×24小时自主作业

依托边缘计算单元与激光雷达SLAM系统，云智慧Cloudwise X1  轮足巡检机器人能在高噪音、弱光环境中实时建图、动态避障，定位精度达毫米级，夜间巡检全自动执行，运维人员无需值夜班。

• 多模态AI感知融合

可见光、红外热成像、声纹与气体传感器数据，智慧Cloudwise X1  轮足巡检机器人 内置17项自研AI算法，支持110+巡检项。例如，在配电柜区域，可通过温差分析提前预警“虚接”隐患，早期故障发现率提升50%。

• 端云协同

所有巡检数据由端侧自主采集，自动附加时间戳与空间坐标，加密上传至一体化运维平台。面对审计时，可一键调取任意设备的历史完整证据链，告别纸质打勾表的主观争议。

基于全地形覆盖能力与多模态智能感知，云智慧Cloudwise X1 轮足巡检机器人的工程潜力，转化为一套面向数据中心、可落地且可验证的智能巡检方案。

五、跨楼层全自动巡检，重塑数据中心运维范式

轮足机器人的价值，不在于形态本身，在于它能否真正解决数据中心的巡检难题。云智慧Cloudwise X1 轮足巡检机器人的实践表明：只有深度理解数据中心场景，并将通过性与多模态感知能力有效结合，智能巡检才能逐步从概念走向实际应用。

云智慧Cloudwise X1 轮足巡检机器人已在大型数据中心完成部署验证，稳定支撑跨楼层、多系统的常态化巡检任务。

未来，云智慧持续致力于为数据中心提供可靠性保障服务，AI赋能提升产品创新力，为金融、政企及云服务商等行业提供更安全、高效、可落地的智能巡检解决方案。

同时，作为专注于AI 基础设施智能运维的服务商，云智慧助力客户构建智能电力、AI算力与服务、AI 智能体的全栈安全和可靠性保障体系。

致力于保障AI基础设施规模化、连续性、稳定运行，通过监测、预警、快速响应、自动化运维与合规治理，帮助客户实现更高可用性、更低风险与更优运营成本。

详询热线：400-666-1332

[大模型实战 04] 从玩具到生产：基于 ChromaDB 打造工程级 RAG 系统

核心摘要 (TL;DR)

• 痛点：大模型不知道最新的新闻，也不知道企业的私有文档（如员工手册）。
• 方案：RAG (检索增强生成)。就像“开卷考试”，先去翻书找答案，再回答问题。
• 工具链：LlamaIndex (框架) + BGE (嵌入模型) + ChromaDB (向量数据库) + Qwen2.5 (推理模型)。
• 实战：在 Kaggle 上从零搭建一个能回答“企业内部机密”的 AI 助手。

前言

各位友人们，大家好，这里是阿尔。在上一节中，我们大概知道了大模型的构成，safetensor格式的大模型的文件组成，transformers库的基本使用。我们已经能够使用大模型去做一些简单对话应用了，它可以是上知天文，下知地理，中间还能知道人情冷暖。但是，我们需要加一个限定词，在训练数据截止日期前的。因为训练一次需要耗费很多的计算资源，时间和人力，当我们想让它知道一些新知识的时候，比如让它知道现在美国的总统是拜登还是特朗普，我们可以在对话中告诉他，这没问题，但是如果我们想让它知道更多，比如我的私人日记?比如我刚写的那篇博客？比如公司的员工手册, 比如自己产品的使用说明书？

这类私有数据，是大模型企业应用的痛点，毕竟大模型是基于在互联网上公开数据训练的。重新把这部分资料加进去，再训练一下模型？也不是不行，但是有点没有性价比，这时候就引出了大模型落地应用的核心技术-> RAG (Retrieval-Augmented Generation，检索增强生成)。

1. RAG（检索增强生成）

1.1 什么是RAG?

考试的时候，如果考到不会的知识，不知道各位友人们会不会头疼，如果这时候，允许我们翻书，现去书里找，我们也很有可能找得到对应的答案，哪怕我们可能完全没学过。这就是RAG的大致思路：不让模型凭空回忆，而是先给它找资料。

RAG，检索增强生成,字面上讲，就是 拿到考题->然后去翻书，通过目录之类的索引，快速翻到（检索）相关的内容->再根据这些内容（增强了的内容），回答出问题（生成回答）。

对比简单地把东西一股脑全部跟大模型说一遍，我们能清楚得发现，我们只用了检索到的那一部分内容，并没有让整本书大模型的脑子将占用, 这就是RAG的效率体现。

1.2 RAG的步骤

RAG技术的思路很简单，但是实现并非只是一个单一的技术能实现的，它有一套流水线（流水线）。 把这头"大象"放进冰箱，总共需要两步：准备好数据和让模型拿到数据。

第一个阶段：数据准备(Indexing) -> 把书装进书包

在大模型能够翻书之前，咱们得先把我们想给它看的书整理好，放进书包里。

1. 加载 (Load)：咱们的资料可能是各种各样的格式，一般大模型是不认识这么些格式的，所以我们就需要把 PDF、Word、网页等各种格式的文件读进来，统一提取出纯文本。
2. 切分 (Chunking)：大模型一次吃不下整本书,就和我们一眼看不完整本《三国演义》一样，它有上下文长度限制。我们需要把长文本切成一个个小的片段 (Chunks)，比如每 500 个字切一段。

3. 向量化 (Embedding)：这是最关键的一步！

   • 计算机无法直接比较“苹果”和“iphone”是不是相关的。
   • 我们需要用一个专门的模型（Embedding Model），把每一段文字变成一串数字向量（比如 [0.1, -0.5, 0.8, ...]）,是不是有点耳熟，对这和大模型训练的Embedding是一个思路，但是我们一般会使用特制的嵌入模型来做这个专业的事情。
   • 在这个数学空间里，语义相近的词，距离就越近, 这样我们就能知道，这本书中的所有向量，哪些是和我们的问题相关的了。
4. 存储 (Storage)：把这些向量和对应的文字，存入向量数据库 (Vector DB) 中。
   

第二个阶段：应用数据给大模型生成（Retrieval & Generation）-> 开卷答题

拿到书了之后，我们想要翻书，就得找到和问题有关系的内容，然后再将这些内容和我们自己的常识结合起来，对提出的问题进行答题。

1. 问题向量化(Embedding)：要想知道用户的提问（例如“火星基地吃什么？”）和内容的相关性，我们就需要像对准备的数据一样，用同一个 Embedding 模型将问题变成向量。

2. 检索 (Retrieval)：拿着这个“问题向量”，去向量数据库里搜, 去找到关系性高的内容。

   • 系统会计算：“哪个文档片段的向量，和问题向量的距离最近？”
   • 找出最相似的前 3-5 个片段 (Top-k)。

3. 增强 (Augmentation)：把这 3-5 个片段拼在一起，和用户的问题组合成一个超级长的 Prompt。

   • Prompt 模板示例：

     你是一个助手。请根据以下参考资料回答问题。
     参考资料：[片段1]... [片段2]...
     用户问题：火星基地吃什么？

4. 生成 (Generation)：把这个 Prompt 喂给大模型（LLM）。大模型阅读资料，总结并生成最终答案。
   

2. RAG技术选型

好了，理论我们已经懂了，现在我们撸起袖子，准备来实操一下子吧。我们打算从零开始快速搭建一个工程级的RAG系统: 私有API助手, 在我直接告诉各位友人们我们要用到的工具前，我觉得也有必要大概让各位友人们知道还有哪些别的选择，我们为什么选择了这几个。

2.1 框架: LlamaIndex vs. LangChain

• LangChain：万能胶水，适合做复杂的 Agent（智能体），但写 RAG 代码比较啰嗦，抽象层级太碎，我们后面写智能体的时候（如果有精力做智能体的教程的话）再来使用它。
• LlamaIndex：数据专家。专门为 RAG 也就是“索引和检索”而生。接口极度简洁，且对数据清洗（Ingestion）的处理更专业。
• 结论：我们做RAG，直接先上LlamaIndex, 快速地实现效果。
  

2.2 嵌入模型 (Embedding)：BGE vs. OpenAI

• OpenAI (text-embedding-3)：效果好，但要钱，且数据要传给 OpenAI（隐私风险）。
• BAAI/bge-small-zh-v1.5：国货之光。中文效果霸榜，体积极小（几百 MB），完全可以在 Kaggle 本地跑。
• 结论：为了免费和隐私，首选 BGE-Small。
• PS: 如果是英文资料的话，建议换成 BAAI/bge-small-en-v1.5 或者 OpenAI 的 text-embedding-3-small
  

2.3 向量数据库：Chroma vs. Milvus vs. Pinecone

• Pinecone：纯云端 SaaS，不可本地部署，对 Kaggle 不友好。
• Milvus：性能强悍，适合十亿级数据，需要 Docker 部署，适合数据量大的时候使用，但是对于咱们的这个项目来说，太重了。
• ChromaDB：轻量级王者。可以像 SQLite 一样以“本地文件”形式存在，也可以部署成服务器。
• 结论：中小型项目，首选 ChromaDB。
  

3. 上手实操

项目背景：假设我们是一家名叫 "DeepStar" 的初创公司，我们有一套内部绝密的 API 文档，新来的实习生总是问重复的问题。我们要用 RAG 让他自己查。

3.1 环境配置 (Kaggle)

启动 Kaggle Notebook，确保 Internet: On，Accelerator: GPU T4 x2。

# 1. 更新transformers及其相关库
!pip install -U transformers peft accelerate bitsandbytes sentence-transformers

# 2. 安装 LlamaIndex 核心及相关插件
!pip install llama-index-core llama-index-llms-huggingface llama-index-embeddings-huggingface

# 3. 安装 ChromaDB 向量库支持
!pip install llama-index-vector-stores-chroma chromadb

下载依赖库可能会需要一点时间，之后我看看能不能在kaggle上用uv去做包管理。

3.2 造数据：模拟企业内部文档

我们创建两份文档：一份是核心接口定义，一份是错误码说明。

import os

data_path = "/kaggle/working/data"
# 创建数据目录
os.makedirs(data_path, exist_ok=True)

# 文档 1: 核心 API 定义
api_doc = """
[机密] DeepStar 核心交易接口 v2.0
1. 创建订单 API: POST /api/v2/order/create
   - 必填参数: 'user_id' (String), 'amount' (Decimal), 'token' (X-Auth-Token)
   - 特殊逻辑: 如果 amount > 10000, 必须额外传递 'audit_code' (审计码)。
   - 频率限制: 单用户每秒最多 5 次调用。
2. 查询余额 API: GET /api/v2/balance
   - 缓存策略: 默认缓存 5 秒。传递 'no-cache=true' 可强制刷新。
"""

# 文档 2: 错误码字典
error_doc = """
[机密] DeepStar 全局错误码字典
- E1001: 签名验证失败。请检查 X-Auth-Token 是否过期。
- E2009: 余额不足。注意：冻结金额不计入可用余额。
- E5003: 审计风控拦截。大额交易未通过自动审计，请联系人工客服。
"""

with open(f"{/data_path}/api_specs.txt", "w") as f:
    f.write(api_doc)
with open(f"/{data_path}/error_codes.txt", "w") as f:
    f.write(error_doc)

print("[Success] 企业文档库已就绪！")

3.3 初始化大脑与眼睛 (Settings)

提前根据自己的情况来配置待会儿用的词嵌入模型和推理模型。

embedding_model ="BAAI/bge-small-zh-v1.5"
llm = "Qwen/Qwen2.5-7B-Instruct"
# 在本地服务器，可以用modelscope下载下来, 把路径配置在这儿

利用 Settings 全局配置，将默认的 OpenAI 替换为本地模型。

import torch
from llama_index.core import Settings
from llama_index.llms.huggingface import HuggingFaceLLM
from llama_index.embeddings.huggingface import HuggingFaceEmbedding

# 1. 设置 Embedding (眼睛)
# 使用 BGE-Small，显存占用极低，检索中文效果极佳
print("正在加载 Embedding 模型...")

Settings.embed_model = HuggingFaceEmbedding(
    model_name=embedding_model
)

# 2. 设置 LLM (大脑)
# 使用 Qwen2.5-7B-Instruct
print("正在加载 LLM 模型...")
Settings.llm = HuggingFaceLLM(
    model_name=llm,
    tokenizer_name=llm,
    context_window=30000,
    max_new_tokens=512,
    generate_kwargs={"temperature": 0.1, "do_sample": True}, # 技术文档要求严谨，温度调低
    device_map="auto",
    model_kwargs={"dtype": torch.float16, "trust_remote_code": True}
)
print("[Success] 模型加载完毕！")

3.4 核心组件：ChromaDB 持久化流水线

这是本篇最关键的代码。我们要实现：如果本地已经有数据库，就直接读；如果没有，才去解析文档。

import chromadb
from llama_index.core import VectorStoreIndex, SimpleDirectoryReader, StorageContext
from llama_index.vector_stores.chroma import ChromaVectorStore

# 定义持久化路径
CHROMA_DB_PATH = "/kaggle/working/chroma_db"
COLLECTION_NAME = "deepstar_docs"

# 1. 初始化 Chroma 客户端 (PersistentClient 实现了写硬盘功能)
db_client = chromadb.PersistentClient(path=CHROMA_DB_PATH)

# 2. 创建或获取集合 (Collection)
chroma_collection = db_client.get_or_create_collection(COLLECTION_NAME)

# 3. 将 Chroma 对接给 LlamaIndex
vector_store = ChromaVectorStore(chroma_collection=chroma_collection)
storage_context = StorageContext.from_defaults(vector_store=vector_store)

# 4. 智能加载逻辑 (幂等性设计)
if chroma_collection.count() == 0:
    print("[Info] 数据库为空，开始初始化...")
    # 读取 data 目录下的所有文件
    documents = SimpleDirectoryReader("./data").load_data()
    # 建立索引并自动存入 Chroma (Ingestion)
    index = VectorStoreIndex.from_documents(
        documents, storage_context=storage_context
    )
    print("[Success] 数据写入完成！")
else:
    print(f"[Info] 发现 {chroma_collection.count()} 条存量数据，直接加载...")
    # 直接从 Vector Store 加载，无需重新计算 Embedding
    index = VectorStoreIndex.from_vector_store(
        vector_store, storage_context=storage_context
    )
    print("[Success] 索引加载完成！")

3.5 验收测试：复杂逻辑问答

现在，我们模拟实习生提问。注意，这个问题需要结合两个文档（接口定义 + 错误码）以及逻辑推理才能回答。

# 创建查询引擎
query_engine = index.as_query_engine(similarity_top_k=3)

# 实习生的提问
questions = [
    "创建订单时，如果你只有 100 块钱，能传 amount=20000 吗？为什么？",
    "我收到了 E5003 错误，这是什么意思？该怎么办？"
]

print("======== 开始 RAG 问答测试 ========")

for q in questions:
    print(f"\n[Question] {q}")
    response = query_engine.query(q)
    print(f"[Answer]\n{str(response)}")

    # 打印引用源 (Debug 必备，看看它参考了哪个文件)
    source_file = response.source_nodes[0].metadata.get('file_name')
    print(f"[Source]: {source_file}")

答复如下

4. 进阶技巧：如何管理你的数据库？

既然用了 ChromaDB，我们就可以像查 SQL 一样查它。这在 Debug 时非常有用。

# 偷看数据库里的前 2 条记录
data = chroma_collection.peek(limit=2)

print("\n[Debug] 数据库抽查:")
for i, doc in enumerate(data['documents']):
    print(f"--- 片段 {i} ---")
    print(f"内容: {doc[:50]}...") # 只打印前50个字
    print(f"来源: {data['metadatas'][i]}")

5. 完整代码

完整代码可以点击kaggle笔记获取

5. 常见问题 (Q&A)

Q: 为什么不直接把所有文档都塞进 Prompt 里 (Long Context)？
A: 虽然现在很多模型支持长文本（比如 128k），但直接塞文档有三个问题：

1. 太贵：Token 是要钱的（如果用商业 API）。
2. 太慢：上下文越长，推理越慢。
3. 记不住：大模型有“长上下文迷失 (Lost in the Middle)”现象，塞太多反而会忽略中间的关键细节。RAG 相当于先做了一次筛选，只给模型看最有用的，效果反而更好。

Q: LlamaIndex 和 LangChain 我该学哪个？
A:

• 做 RAG/知识库：首选 LlamaIndex，它对数据索引、切分、向量化做了极其深度的优化，接口更简洁。
• 做 Agent/工具调用：首选 LangChain，它的生态和工具链更丰富。
• 结论：咱们这个项目专注于“找资料”，所以 LlamaIndex 是最佳选择。

Q: ChromaDB 的数据存在哪里了？
A: 在上面代码中，我们通过 PersistentClient 指定了路径 /kaggle/working/chroma_db。
它就像 SQLite 一样，数据就存在这个文件夹里的 .sqlite3 和 .bin 文件中。咱们可以把这个文件夹拷贝到任何电脑上，无需重新向量化就能直接使用。

本文作者： Algieba
本文链接： https://blog.algieba12.cn/llm04-rag-llamaindex-chromadb/
版权声明： 本博客所有文章除特别声明外，均采用 BY-NC-SA 许可协议。转载请注明出处！

别卷 Prompt 了！它只是你 AI 员工的“开机键”

进入 2026 年，Skills 的爆火和 Clawdbot（OpenClaw）的横空出世，传递了一个清晰的信号：当 Agent 从酷炫的演示走向支撑业务的生产系统时，单纯依靠优化提示词（Prompt）的“艺术”，已无法满足企业对可靠性、执行力与持续进化能力的刚性需求。

这并不是说 Prompt 不再重要，而是它的角色发生了根本性转变。它从一个需要被无限雕琢、承载所有逻辑的“总指挥”，演变为一个触发器。它的新任务是：准确理解人类指令，然后高效地唤醒后方一套庞大且专业的能力系统。就像手机的开机键，按一下就可以打开各种应用功能的入口。

这个能力系统，正是现代 AI 工程的核心——一个为 Agent 打造的“可控思维”架构。

它由三个相互协作的引擎构成：

• 记忆引擎（Memory）：确保 Agent 有“记性”，能够记住用户偏好和交互历史。这意味着它能记住重要的对话历史和你的要求，做事有头有尾，不用你每次都从头交代。
• 知识引擎（RAG）：确保 Agent 有“实时的知识库”，能够从海量、动态的企业数据中精准检索信息，保证它给出的信息永远准确、最新，不会凭空乱造。
• 技能引擎（Skills）：确保 Agent 有“手脚”，能够将复杂的业务操作（如数据查询、报告生成、系统调用）封装为可被随时调用的标准化模块，从“能说”走向“会做”。

Prompt、Memory、RAG、Skills 共同构成了一个能独立干活、不出错、有记性的 AI 员工，当它要完成的任务越复杂、越关键，后三者的系统化工程价值就越发凸显，Prompt 也因此必须从舞台中央退下。作为使用者，我们不再只是和模型对话的“提问者”，而是为 Agent 设计和组装能力模块的“架构师”，思考重点也从“怎么问得好”，全面转向“怎么让 AI 干得好”。

理解这种从孤立提示到系统工程的范式迁移，是我们今天话题的起点。

下面，就让我们聆听来自 1 月 31 日 OceanBase 社区嘉年华的圆桌讨论，看顶尖的实践者们如何具体拆解这些核心组件的演进与融合。

从 Prompt 到 Skills，RAG 还行不行

主持人：张海立，LangChain Ambassador、OceanBase Ambassador，up主“沧海九粟”

对话嘉宾：

• 张颖峰，RAGFlow CEO
• 余金隆，FastGPT 负责人
• 古思为，Co-founder of Nowledge Labs
• 吉剑南，OceanBase AI 平台与应用负责人

议题一：2026 年 RAG 生态何去何从？

张海立：从去年末到今年年初，AI 领域热点频发。除了近期备受关注的 Clawdbot（OpenClaw），Skills 成为另一个重要话题。我在进行 Skills 相关实践时发现，许多 Skills 与本地文件系统紧密相关，但都离不开 RAG 体系对外部数据的召回，这对 Agent 发挥更大作用至关重要。LangChain 在构建 Agent 生态时，RAG 也是核心体验之一。想请教各位老师：在当前大环境下，您认为 2026 年 RAG 生态将如何发展？请结合各自产品进行简要介绍。

张颖峰：先说个笑话，2025 年被称为 Agent 元年，当时有朋友问我们要不要（从 RAGFlow）改名为 AgentFlow。而今年是 Agent 落地元年，我们内部也讨论要不要改名为 ContextFlow。实际上我们永远不会改名，因为我们认为“R”是核心点，单纯的 RAG 确实不足以服务 Agent，但“R”是服务 Agent 数据层的核心点。

当前 Agent 需要的是上下文（Context），它来自三方面数据：企业内部数据、工具数据以及对话过程中生成的数据。Skills 偏向工具层面，但比工具更高一层，还包含了规划（Plan）能力。Skills 本身也需要搜索——当企业内部有 1000 个 MCP 时，如何调用对应的 Tools 和 Skills 同样需要检索能力。因此 RAG 永远不会消失。

我们的布局是从 RAG 引擎向上层引擎演进。技术本身未变，但内涵发生变化：数据从简单的企业内部数据，扩展到 Agent 过程中的上下文数据。我们判断，未来所有 Agent 都是 Coding Agent，包括对工具的调用也将变成代码生成（Code Generation），需要 RTC（Run-Time Code）在沙箱中执行，访问各类 Tools 和 Skills，最终通过文件系统返回结果。这也是我们向上下文引擎方向演进的核心计划。

余金隆：我赞同颖峰老师关于 Code Generation 解决所有问题的观点，这也是我们团队的认知。无论是做 RAG 引擎还是 Workflow 引擎，都在向代码生成靠拢。

RAGFlow 不想改名，我们有点想改名字。因为近几年我们发现，做 Agent 本质是把数据使用起来，所以我们的平台主要解决数据连接层问题。过去数据分布在数据库、文档等各种结构中，现在通过大量连接器实现不同数据的连接。Skills 出现后，以前需要写代码和 Webhook 连接的数据层，现在可以通过 Skills 实现。这对国内交付场景特别有价值——国内系统数据格式不统一、缺乏标准，交付同学以前需要写大量适配代码，现在通过 Skills 将数据标准化连接到平台。

今年我们主要做两件事：一是完善连接层，二是优化 RAG 的 Retrieval 层。Retrieval 效果很大程度上取决于召回过程，不同场景的召回流程差异很大。过去需要通过 Workflow 形式搭建积木、进行意图识别分类、编写不同提示词适配不同场景，链路复杂。现在我们探索通过 Skills 这种偏语义化的方式生成代码，类似 Test-to-Code 的思路，但生成的是 SDK 代码来构建整个 Retrieval 流程，这是一个很有意思的探索方向。

古思为：关于 2026 年 RAG 相关变化，可以看到在 Coding Agent 中对代码的检索已从纯 Embedding 转向 AST（抽象语法树）、Agentic FS Graph 或 AST Graph 等方案。包括 PageIndex 项目，以及我们公司在 Haicon 2024 发布的实验性项目 OpenKL，尝试用类文件系统方法处理 Memory 和 RAG Docs。

另一个趋势是 RAGFlow 等通用内容引擎同时处理文档和 Memory。我们已发布的第一个产品是面向 C 端的 Memory 桌面 APP Knowledge MAM，动机是帮助用户在不同工具间无缝切换工作流。例如在 ChatGPT 完成 Deep Research 后，无需重新解释即可继续在 Cursor 中工作；或者当 Agent 帮助发帖子进入热榜后，可以切换到另一个 Agent 继续任务，同时保留所有交互历史和偏好设置。

吉剑南：OceanBase 面向 AI 的能力——seekdb、PowerRAG 与 PowerMem 均已开源。我们团队除了做向量数据库和 AI 应用基础设施外，也在探索面向数据库的 AI 应用，比如面向开发者工具的 Text-to-SQL 和数据库智能运维。

关于 2026 年趋势，我认可颖峰老师说的 RAG 不会消失，它和Skills、MCP处于不同维度。即使未来 Skills 和 MCP 越来越多，最终仍需通过 RAG 或某种方式召回，不能将所有 Skills 都喂给模型。

但我有不同观点：当前 RAG 仍集中在知识库领域，通过搭建 Chatbot 做问答，而问答更像玩具而非生产应用。真正的生产应用应将 RAG 融入日常工作，如销售根据集团材料为客户生成定制化 PPT或“一指禅”。未来 RAG 会结合应用反馈，反向影响数据如何切分、如何做更精细化的 Embedding，而非仅仅前置处理。

议题二：AI系统中的多路检索与数据源管理

张海立：感谢各位的分享，Skills 给我们带来了更多机会，能创建更多 Agent 和 RAG 应用。同时有一个概念非常重要：我们常说的 RAG 里的“R”，到底指什么？它指的是 Retrieval，是一个 “检索过程”。Retrieval 的 source可以是文件系统，可以是数据库，可以是 Web，甚至多种来源并存。

引申出第二个问题：随着 Skills 和 RAG 体系的发展，未来多路检索会越来越常见，RAG 不会消失，它将长期存在于 Agent 体系中。这样一来，数据源头的管理就变得更加重要。最简单的是把数据直接塞进软件系统，但更常见的情况可能是：越来越多的数据会落在数据库中。在这种情况下，当数据库的多路检索能力得到极大增强之后，做 RAG 应更多依赖数据库，还是在数据入库层面通过一些技巧将复杂的事情交给基础设施？

吉剑南：必然入库是最大影响，这也是 OceanBase 提出混合搜索（Hybrid Search）概念的核心。如果完全以非结构化数据或切片方式进入系统，召回效率顶天就是向量化的近似能力。去年所有 RAG 产品都在强调从非结构化数据中提取结构化数据，存为 JSON 等半结构化形式，用于前置过滤或与结构化数据一起做混合搜索。

为什么要这样做？本质上是语义理解包含两个层面：一是你问的是模糊问题，但脑子里想的是确定性答案；二是问题模糊，答案也模糊，希望召回所有相关点。大部分实践场景属于第一种。

在文档预处理时，结构化提取非常重要。例如从医疗文档或简历中提取结构化字段，召回时先对结构化数据做精确匹配，再对字段内的非结构化内容做向量检索。半结构化数据解决范围和准确性问题，向量检索解决语义理解问题。通过混合搜索模式，入库时做文档理解提取结构化数据，召回时统一检索，效率会大幅提升。数据库也应在接下来一年面向这个方向发展，我们看到 Chroma 等国外开源数据库已在往这个方向演进。

古思为：我们比较早做 Graph RAG，可能是第一个探索的团队。张老师分享的新架构与我们上一家公司做的 FusionGraph 很像。核心思想是：要让复杂 RAG 系统表现好，索引结构既要贴近知识本质，又要把特定场景的领域知识元信息投射到 Retrieve、Index、Transform 各环节做优化。

通用方法是知识后加工时做 Entity Graph 或 Semantic Graph，同时在做 IDP（Intelligent Document Processing）和 Parsing 时，对多层 folder 和复杂章节的长文档要识别 layout，涉及多模态时考虑是否转换模态。要做好这些并能演进，不要过度领域化 pipeline，而是按基本原理拆分，确保各组件能力跟上。

Database 是重要基础设施，比如 RAGFlow 的 Graph 和 Tree 结构能否原生保留、高效检索；要做 Dynamic Agents Retrieve，模型能否自然利用复杂多层结构。数据库的高性能、索引召回率和内置 Hybrid RRF 都很重要，决定系统下限。

余金隆：在交付过程中，数据源解析是基础且重要，但更重要的是召回（Retrieval）层。即使使用最简单的原始向量，只要检索词和检索语句构建得好，也能得到很好效果，只是效率较差。我们在此基础上扩展了语义化加标量方式。

但标量遇到较大问题：它不固定，用户自己也不知道需要什么标量。我们今年研究的方向是标量的动态扩展，包括用户自身扩展和模型自生成。例如给模型一些 Skills，或用户编写场景来生成场景下的标量存入数据库。当然这会引发多租户系统中成千上万标量的高效索引问题，以及渐进式生成问题——很难在预处理时生成所有标量，很多需要在检索时评估并渐进补全。在Retrieval阶段，多标量关联查询的生成方式也借鉴了 Text-to-SQL 的思路。我们希望找到通用存储方式覆盖 80% 场景，目前看语义化加标量检索加动态标量可以覆盖很多场景，所以我们没有用图，因为图是以复杂方式解决复杂问题，而 AI 时代可能有更简单的方式处理复杂问题。

张颖峰：我们现在是数据库使用者，但曾经也是数据库开发者。从纯技术角度，我非常喜欢“一边推理一边搜索”的技术方向，我称之为 Attention Engine，我认为它也是一种 RAG。DeepSeek 近期已大体实现类似方式，因显存限制不得不用内存，在推理时通过内存索引搜索内容，从外置记忆变为内置记忆。但从商业角度这条路行不通，要求检索与模型延迟极低，必须在同一交换机后，意味着只能卖一体机。因此我们仅作为调研方向。

从业务视角看，我们最早做 Infra 、做数据库时发现离业务太远，后来做 RAG 流量较大，促使我们重新思考 Data+AI 落地生态。我们的观点是：过去数据库是底座，上面写应用做增删改查；现在应用是 Agent，底座是以 RAG 为基础的组件，数据库在底层支撑 RAG 中间件。Data+AI 建设不能 AI 和 Data 各干各的，接口有时不清晰，因为中间层用 Python 实现，其好处是适应多变需求，召回策略可随时调整，不过 Python 带来的效率问题也让人头疼。AI 时代的数据底座让 Infra 人员直接触达业务，通道变短。因此中间层需要一个 Python 层适应业务多样化，一旦发现好的方式就迅速下沉到数据库解决效率问题。

我们在 2024 年底就鼓吹跨模态，但至今未落地，因为 Infra 到模型都未准备好。跨模态需要多向量搜索（Tensor Search），用多向量表示图片或文本，语义更准确、排序更准，但数据会膨胀两三个数量级，这是灾难。这需要模型、算法、Infra 共同解决挑战。因此我们需要端到端的、以 RAG 为中间层的体系，这其实就是 Agent 的数据库。

议题三：Memory 与 RAG 到底有何区别？

张海立：我非常认同颖峰老师提到的“端到端”。作为 LangChain 社区大使，我们主要做应用层框架，今年非常想做的一件事情是：和各个厂商比如 OceanBase seekdb一起提供真正的端到端解决方案，服务企业和个人用户，帮助他们快速构建生产级 Agent。

简单总结一下几位老师的理解：当我们面向用户提供检索能力时，会在中间层、应用层、数据库层进行多层协同优化，共性问题会逐步下沉到数据库解决。以我的个人体验为例：在最初布道时，我会给大家讲很多 RAG 的流程和算法，但从去年底开始，我更多会建议“你直接用这个数据库就好了”，因为它已经帮我们解决了很多多路检索的问题。这种 “沉淀” 是应用方和数据库厂商不断联合实践的结果。

下一个问题也与此有关：我们经常被问到Memory 和 RAG到底有什么区别？从 Memory 召回和从数据库召回有何区别？近期 Clawdbot（OpenClaw）从文件系统读取，到支持 PowerMem 直接接入进行更有效的内存管理。想请教剑南老师，这里做了什么特别工作？以及各位如何理解 Memory 与 RAG 的关系？

吉剑南：Memory 是为让大模型更像人而引入的。如果查询的都是客观事实且不存在人与人之间的理解，RAG 已能解决问题。但问题在于每个人对客观事实的理解和描述不同，加上人有记忆曲线，希望记住昨天强调的内容——这些内容虽非客观事实，但是主观认可。

例如每个人都有一个叫“老王”的朋友，随着时间推移这个“老王”可能已变化，但在记忆中一直叫“老王”，这时 RAG 搞不定，但 Memory 能搞定，因它会更新对“老王”的认知。“老王”是一个知识吗？并不是，因此，Memory 的核心是个性化和千人千面。

无论是 RAG 还是 Memory，整体是搭建一整套解决方案面向 Agent 为业务带来价值，不应区分该用 RAG 还是 Memory，而应思考如何组合好共同为业务赋能。

古思为：我们目前做 Memory，之前做 Graph RAG。Memory 有广义和狭义之分，狭义指 Agent 或 LLM 需要检索的更外部的 Memory，它确实是特殊的 RAG，特殊在几个方面：

• 原始数据是持续的 message thread。
• 知识需求是时序性的（temporal），包含两个时间维度：信息创建时间、事件/事实时间。
• 时序性存在一个问题，遗忘（forget）是 feature 而非 bug，需结合时间、访问频率和正反馈影响 Retrieval。
• 条目层面有 category 和不同类型，取决于 Memory 目的，可能需要schema 区分 ephemeral（瞬时）和 permanent（永久）。
• 不同结构间需要 transform 关系，可在 Retrieve 或写入过程触发 event，或周期性处理（类似大脑做梦处理记忆）。
• 多租户和 sessional scoping。

如果做细会发现与典型 RAG 差别很大，但二者又有很大 overlap。RAG Engine 可以处理 Memory，Memory Engine Service 项目也会处理文档，界限会变得模糊。

余金隆：我理解 Memory 算是广义 RAG 的一种，无非也是数据 I/O、Pipeline 处理、特殊数据结构，比较偏个性化。

从产品角度看，Memory 目前 C 端个性化场景用得较多。在任务流中，用户提 Memory 的还不多。在技术实践中，Mem0 有工具调用的 Memory 用于长 Agent 任务，但看其架构有点像 Context Engine，与 Memory 又不太一样。所以感觉 Memory 还是 RAG 的一种特殊 Pipeline 形式，没有太大区别，可能实时性比 RAG 更高。

张颖峰：单从技术角度而言，Memory 与 RAG 确实没有本质区别，都是 Retrieval。但重要的是 Memory 如何发挥作用，这是在快速变化的。

我在分享 Context Engine 时提到三类数据：企业内部数据、Tools 数据、Agent 使用过程中生成的数据。但它们存储在两个地方：RAG 专有区域和 Memory 专有区域。可见所有大模型生成的内容都要存到 Memory，包括 Skills 的元数据（Skills 本身数据存文件系统）。

怎么存、什么时候存、什么时候取，这些设计点很难决策。例如生成 Plan 是否存入 Memory？作为 Plan Cache 有价值，但如果 Human-in-the-loop 干预修改了 Plan，应如何存储？以后如何根据 Memory 数据抽取内部 MCP Tools 的 Skills？这些都是新问题。

从 Infra 角度，RAG 和 Memory 没区别；但从使用者角度，Memory 是重要的基础设施，解锁了大量场景。因此 Memory 项目很多（如 Mem0、MemU），但对 Memory 区域的定义（数据库该有哪些表）尚未完全一致，反映 Agent 到底需要什么样的 Memory 还在进化中。不过整个 Agent 体系需要哪些组件，已进入收敛期，就是 Context。

议题四：Skills 开发实践与推荐

张海立：各位老师都在做 Workflow、数据库或融合方案，是否开发了自己的 Skills 帮助用户更好地使用产品？如有请推荐，如无请设想会开发什么样的 Skills 服务开发者？

张颖峰：抱歉我目前没有特别好的推荐。我比较关注如何针对大量内部 MCP Tools 生成对应 Skills，这需要一个专门的 Agent 平台来实现。我的观点是：未来 Agent 平台可能没有统一标准，所有都是 Coding Agent，但特定 Agent（如低代码、无代码、Workflow）可能因良好交互而便于生成 Skills。

余金隆：我们内部 Skills 用得很多，运营和 SEO、GM 等场景一大把。产研团队用得不算多，主要是代码开发和 Review。交付团队用得特别多：面向用户时遇到各种问题，排查系统后沉淀为 Skills，辅助交付和运维。因此，内部有句玩笑话“交付同学比研发同学更懂系统”，他们做了二十多个 Skills，涵盖工作流搭建、问题排查、RAG 优化等。总体感觉 Skills 更像自然语言工作流，虽更抽象，但目前大部分还是偏自然语言的 Workflow。对非开发人员在生产流程上比较友好。

古思为：我们维护基于 Skills 的插件，在 Skills 发布第二天就推出了 Cloud Code 插件支持。早期没有 Skills 时，我们只能基于 MCP，让插件调用 MCP 的 Custom Command 触发操作，用 Hook 实现功能。

后来发现 MCP 规范了工具调用，但有两个地方不如 Skills：

1.MCP 有 Prompt 抽象，实现为斜杠命令可主动调用类似 Workflow 的东西，但并非所有 Client 都实现，我们要做很多额外工作。Skills 天然支持主动说和自动做。

2.Skills 的打包方式让不同工具间组合更灵活。我们内部将 Skills 从 MCP 换成 CLI 后变化很大。例如让 Agent 做 Memory 复杂更新查询时，MCP 需要多轮次，即使 interleave 也不够好。但 CLI 可以动态组合 Linux Shell Pipeline，在一个 turn 里精确完成复杂操作，且内部 CLI/Script 可以 self-contain，打包给用户后自然享受复杂能力。

调试经验方面，Skills 比较通用，容易用不同平台测试。我们发现一个有意思的案例：Skills 对应的工具有很多具体选择，如何调优模糊的问题？我们的做法是用最聪明的 Agent 做 honest 的复杂 long run 评估，像跟客户聊天一样告诉我们如何改进。有时需要更端到端看细节，不得不自己server model，在 template 解析过程中用小模型发现工具复杂类型定义的问题，虽然其他模型能克服，但会影响 performance。

吉剑南：OceanBase 内部沉淀了很多 Skills。Skills 本质是最佳实践，告诉大模型最佳实践是什么，而最佳实践无非两类：一是提升工作效率的工程类（如 Cursor 的 rules），二是业务类 Skills。

Skills 也可以用在 RAG 上，RAG 效率和准确性今天跟两个因素相关：相似度和 Top K。但大家有没有想过，召回前 Top K 和相似度有时不能完全指定，需要反复调，知识库又在更新。如果针对不同的业务实现写不同的 Skills，例如当需要某类数据时，希望相似度设到什么位置、Top K 设到什么位置，根据召回结果动态调整，这就变成了一个 Skills。这是 RAG 搞不定的，需要根据具体召回内容判断，是 RAG 的最佳实践。

之前大家可能想是否把 RAG 数据放 Skills 里就不用召回了，而我觉得 Skills 是对 RAG 的增强。关于 OceanBase 的 Skills，我们是有准备的，包括 seekdb 的研发人员今天也在现场，未来应该会有更多相关的 Skills 开放出来。

张海立：非常感谢各位老师精彩分享。简单总结：RAG 还“行”！只要理解 RAG 的 R 是 Retrieval，有 Memory、传统数据库等多种数据来源，随着各位老师所在厂商的努力，多路检索能力、应用层提升、流程算法优化都在推进。相信 2026 年RAG会有更大发展。

Agent 可控思维的工程实现：从分散工具到一体化基座

本次圆桌讨论，为我们清晰地勾勒出 2026 年 AI 工程化的演进路径。专家们的共识指向一个明确的结论：构建可靠、可用的 Agent ，其核心不再是追求某个单一组件的极致，而在于如何系统性地整合记忆（Memory）、检索（RAG）与技能（Skills），形成一个协同的“可控思维”体系。

综合专家观点，这一体系的发展呈现出三大趋势。

01 RAG 不会消失，反而会变得更加基础与核心

它的内涵正在从狭义的文档问答，扩展为 Agent 对所有上下文数据的 Retrieval 能力——无论是企业内部文档、数据库中的业务数据，还是工具（Tools）与技能（Skills）的元数据，都需要被高效检索与调用。

未来的 RAG 将深度融入工作流（Workflow），根据应用反馈动态优化，并与混合搜索（Hybrid Search）等技术结合，实现更精准的“语义理解+精确过滤”。

02 Memory 与 RAG 边界模糊，融合为数据层

从技术基础设施（Infra）视角看，Memory 与 RAG 的本质都是数据的存储与召回。

二者的区别更多在于数据特性和使用场景：Memory 更侧重于个性化的、时序性的对话与状态记忆；RAG更侧重于客观的、相对静态的知识存储。但在服务 Agent 时，它们共同构成了支撑“上下文（Context）”的数据层。一个优秀的底层平台，应能一体化地管理这两种数据范式。

03 工程复杂度下沉，呼唤一体化数据基座

当应用层通过 Skills 和灵活编排满足业务多变需求时，通用的、性能瓶颈性的复杂度会自然下沉到底层基础设施。无论是多路检索、混合搜索，还是海量 Skills 元数据的管理，都对底层数据平台的能力提出了更高要求。

专家们指出，未来的理想路径是依赖一个强大的数据基座，它能原生支持向量检索、关系查询与结构化记忆，从而让开发者从繁琐的多系统集成工作中解放出来，更专注于 Agent 本身的业务逻辑。

因此，构建“可控思维”的终极路径，在于选择或打造一个能够统一承载 Agent 记忆、知识与状态的数据基座。这样的基座，正如专家们在讨论中多次暗示的，能够将 Memory 的个性化记录、RAG 的海量知识检索、以及支撑 Skills 运行的业务数据，融于一个简洁、高效、一致的系统中。它让 Agent 的“思维”过程变得可管理、可观测、可优化。

最终，Prompt、RAG、Skills、Memory 这些活跃于应用层的概念，都将在这样稳固的基座之上，更好地各司其职、协同工作，共同将 Agent 从“聪明的对话者”转变为“可靠的业务执行者”。这标志着 AI 应用开发正式进入系统工程时代，而坚实的数据基础设施，是这一切得以实现的基石。

Flink SQL 是 Apache Flink 的核心模块之一，它让开发者可以使用标准的 SQL 语法来编写流处理和批处理作业。对于不想深究 Java/Scala 复杂 API 的“小白”来说，Flink SQL 是进入实时计算领域的最佳敲门砖。

本文将基于 Flink 1.20.1 版本，手把手教你在 WSL2 (Ubuntu) 环境下搭建环境，并运行你的第一个 Flink SQL 任务。

一、为什么选择 Flink SQL？

1. 低门槛：会写 SQL 就能开发实时任务。
2. 统一性：批流一体，同一套 SQL 既可以跑历史数据（批），也可以跑实时数据（流）。
3. 生态丰富：内置了大量的 Connector（连接器），轻松连接 Kafka、MySQL、Hive 等主流组件。

(图：Flink SQL 架构示意图，展示 SQL 解析、优化到执行的过程)

二、环境准备 (WSL2 Ubuntu)

本教程演示环境为 Windows 下的 WSL2 (Ubuntu 20.04/22.04)，这是目前 Windows 用户体验 Linux 开发环境的最佳姿势。
参考以前些的文章从零开始学Flink：揭开实时计算的神秘面纱，搭建好 Flink 环境。

三、体验 Flink SQL Client

Flink 提供了一个交互式的命令行工具：SQL Client。它允许你直接在终端编写和提交 SQL 任务。

1. 启动 SQL Client

如果没有启动Flink集群,则先启动flink集群:

./bin/start-cluster.sh

,然后在 Flink 目录下执行：

./bin/sql-client.sh

你将看到那只著名的松鼠 LOGO：

(图：SQL Client 启动欢迎界面)

2. Hello World：数据生成与打印

我们不依赖任何外部组件（如 Kafka），直接使用 Flink 内置的 datagen 连接器生成模拟数据，并用 print 连接器打印结果。

第一步：创建源表 (Source Table)

复制以下 SQL 到 SQL Client 中执行：

CREATE TABLE source_table (
    id INT,
    name STRING,
    ts TIMESTAMP(3),
    WATERMARK FOR ts AS ts - INTERVAL '5' SECOND
) WITH (
    'connector' = 'datagen',       -- 使用数据生成器
    'rows-per-second' = '1',       -- 每秒生成1条数据
    'fields.id.kind' = 'sequence', -- id 字段为序列
    'fields.id.start' = '1',       -- id 从1开始
    'fields.id.end' = '100'        -- id 到100结束
);

执行后显示 [INFO] Execute statement succeed.。

第二步：创建结果表 (Sink Table)

CREATE TABLE print_table (
    id INT,
    name STRING,
    ts TIMESTAMP(3)
) WITH (
    'connector' = 'print'          -- 使用控制台打印连接器
);

第三步：提交任务

将源表的数据插入到结果表：

INSERT INTO print_table SELECT * FROM source_table;

此时，SQL Client 会提交一个异步任务到集群。你会看到类似 Job ID 的输出。

3. 查看运行结果

由于我们使用的是 print 连接器，在 Standalone 模式下，输出会打印到 TaskManager 的日志文件中。

打开一个新的 WSL2 终端窗口，进入 Flink 目录查看日志：

# 进入 log 目录
cd log

# 查看最新的 .out 文件 (文件名包含 taskexecutor)
tail -f flink-*-taskexecutor-*.out

你应该能看到屏幕上不断跳动的数据流：

(图：终端 tail -f 命令看到的实时数据输出)

四、常用命令速查

在 SQL Client 中，你可以使用以下命令：

• HELP: 查看帮助。
• SHOW TABLES: 查看当前创建的表。
• SHOW JOBS: 查看运行中的作业。
• DESCRIBE table_name: 查看表结构。
• QUIT: 退出 SQL Client。

五、总结

恭喜你！你已经成功运行了人生中第一个 Flink SQL 任务。

通过本文，我们完成了：

1. WSL2 下 Java 和 Flink 1.20.1 的安装。
2. 启动了 Flink 本地集群。
3. 使用 SQL Client 创建了 Source 和 Sink 表，并跑通了数据流。

下一篇，我们将深入讲解 Flink SQL 中的窗口（Window）操作，看看如何处理“过去5分钟的订单总额”这类经典需求。

参考资料：

• Flink 官方文档
• 原文来自

后台系统（如ERP、OA、CRM，）作为企业内部系统，具有需求明确、变化频繁、逻辑复杂度适中的特点，而后台管理系统的开发效率和响应速度直接影响到运营效率，更甚者可能影响到业务竞争力。

传统开发模式面临成本高、周期长、维护难等挑战。

本文从背景分析、设计方案、核心模块及核心功能三个维度，系统阐述低代码平台如何从根本上提升运营后台开发效率，为企业数据化转型提供新路径。

一、背景分析

传统运营开发模式的核心痛点：

1、重复造轮子，创新成本高昂

运营后台70%功能是增删改查，简单的列表查询配置业务，占比30%，相同功能在不同项目中反复开发，不仅浪费资源，更导致技术债务累积。

2、响应速度滞后

简单的列表查询配置业务，从需求提出到最终上线，传统开发需求经历需求评审、技术设计、编码实现、测试验证、部署上线等多个环节，平均耗时3-5天。

二、设计方案

以贴合自身业务需求、落地开发提效为核心导向，前期充分调研业内主流低代码平台，深度分析各平台的功能优势，不盲从”全功能“标杆，而是以自身开发需求、业务场景、技术栈特性为标尺，构建低代码平台。

平衡功能与易用性，拒绝过度开发，针对平台基础能力与通用组件，采用“基础配置+业务轻封装”的设计思路。基础项保留灵活的原生配置能力；同时结合运营后台业务的通用场景，对高频使用的功能、组件进行简单封装，既保留配置灵活性，又能适配业务实际。平台整体架构设计如下：

应用层模块介绍

业务中心模块：接收页面管理模块同步的已发布页面，展示用户有权限的业务页面。

权限模块管理：管理系统权限、页面权限、用户。

数据源管理模块：

数据源管理：对接数据库、API接口，支持数据源的新增、编辑、停用等；

元数据配置：可视化配置数据库字段信息，定义字段类型（文本/数值/日期）、显示别名等。

页面管理模块

页面创建：提供空白画布、预制组件，支持拖拽式组件布局（文本、表格、筛选器等）。

组件配置：配置基础属性、数据源、事件交互等。

预览并保存：生成预览结果；保存即发布。

四大模块共同构建了平台的基础能力矩阵，但从业务落地的优先级来看，页面管理模块是驱动整个平台运转的核心引擎 —— 运营人员的所有配置操作都围绕它展开，其他模块也都是为它提供数据、权限、业务关联的支撑。

基于此，我们将从整体框架下沉到核心模块及核心功能。

三、核心模块及核心功能

01、核心模块——页面管理模块

页面管理模块分三大核心：引擎、物料服务、数据源。

三个核心的职责

引擎（蓝色模块）：是页面构建的 “操作中枢”，负责页面的可视化编辑与最终输出。它提供了页面拖拽布局、页面编排、组件树管理、组件属性配置等功能（运营人员通过这些操作完成页面的样式与逻辑配置），最终通过 “渲染、出码” 能力，将配置好的内容转化为可访问的页面。

物料服务（绿色模块）：是页面的 “组件资源库”，负责组件的生产、管理与规范。它提供标准化的组件（如按钮、表格、图表），并通过 “物料规范” 保证组件的统一性；同时支持组件的版本管理，确保不同页面使用的组件版本一致。

数据源（黄色模块）：是页面的 “数据支撑”，负责提供页面所需的业务数据。它对接企业的数据库、API 等数据来源，为页面中的组件（如数据表格、报表）提供数据绑定的基础。

三个核心的协同流程

物料服务与引擎联动：物料服务将标准化组件（按物料规范）同步到引擎的 “组件树” 中，供引擎的页面编辑功能调用。

数据源与引擎联动：数据源提供数据元信息，供引擎在 “属性配置” 环节将组件与具体业务数据绑定。

引擎整合输出：引擎通过 “拖拽布局、页面编排” 整合物料组件与数据源，最终通过 “渲染、出码” 生成可访问的页面（图下方的最终产物）。

核心功能

页面管理模块，通过具体能力支撑业务快速开发落地，核心功能主要包含：可视化页面开发、自定义组件、发布、出码。

可视化页面开发：可视化页面开发是低代码的核心优势。开发者通过拖拽组件绘制页面布局和配置组件与数据源绑定，整合物料组件与数据源，无需编写大量前端代码，快速实现项目落地。下面以实例介绍可视化页面开发过程。

实例：开发项目阶段信息维护页面

页面需求：展示页面名称“项目阶段信息维护，展示数据表格，包含id、项目阶段名称、操作三列，表格按照 id 正序排列，列表项支持编辑和删除两种操作，支持弹窗新增数据，并且需要校验阶段名称必填。

页面开发流程：

重点介绍拖拽组件绘制页面布局和配置组件与数据源绑定。

页面绘制区块介绍：

图源：织信低代码

在组件库中，选择合适的组件，拖拽到编辑器画布中；

对画布中的组件，进行组件配置，例如组件基础属性、数据源、交互事件、样式等。

针对实例需求：

标题：使用Title组件

新增按钮和列表：使用高级表格组件

配置组件与数据源绑定

列表：配置数据列，配置列标题、数据类型、数据字段、对齐方式等。

新增按钮：配置操作栏，配置名称、按钮样式、是否禁用、是否隐藏、点击事件等；其中点击事件绑定用户在左侧源码面板中创建的组件事件。

新增弹窗：配置弹窗标题、弹窗按钮、弹窗中表单、表单项校验是否必填项等。

最终页面结果：在上面的实例中，我们使用的是平台标准化组件，拖拽组件搭建页面布局，配置组件属性实现交互逻辑，将开发时间从天压缩到小时，显著提升开发效率。

功能二

自定义组件

组件库是整个平台的核心基石与价值载体，它直接决定了平台的开发效率、功能上限、交付质量和用户体验，是低代码模式能够实现 “少写代码、快速交付” 的核心支撑。

自定义组件让平台能够满足个性化的业务需求，突破标准化组件的功能局限。下面以实例介绍自定义组件开发过程。

实例：自定义组件table，实现表格展示支持多场景

背景介绍：标准化表格组件，不满足运营对列表展示要求，存在展示局限性：

仅支持基础文本展示，无法满足运营后台多样化内容展示需求，例如图片、超链接、音频、视频等

原始数据可读性差，例如：操作时间展示时间戳，状态展示0、1等

解决思路：

归纳运营后台常见列展示需求，覆盖多类型内容形式，

增加表格列属性配置，不同类型搭配不同配置项，

支持拓展，实现跨列数据源展示等。

开发实现：遵守物料协议和引擎规则标准化开发，确保组件能无缝融入平台的页面编辑与渲染体系；

类型汇总：

基础类：文字，直接展示列绑定数据，无需其他配置项

时间类：时间，将时间戳转换为YYYY-MM-DD HH:mm:ss 格式，无需其他配置项

媒体类：

图片，配置图片路径、替代文本

音频，配置音频资源

视频，配置视频资源

链接类：超链接，配置跳转地址、链接文案

拓展类：HTML自定义片段，配置渲染函数，满足个性化需求

部署发布：

组件物料独立打包发布

修改平台依赖包配置

平台重新构建发布

平台共实现自定义组件10+个，包括表格组件、统计图组件、菜单组件、布局组件等，满足运营后台个性化业务需求，丰富组件库生态，实现根据业务需求持续新增、优化组件，保障平台能力与企业业务发展同频，降低技术架构的迭代成本。

功能三

发布

平台采用保存即发布模式，页面配置完成后，直接同步至平台数据库，无需编写代码、单独测试与复杂的环境部署，可通过平台生成的专属链接直接访问使用，部分轻量需求甚至能实现小时级配置、即时上线，大幅简化开发流程，省去传统模式中编码、部署等核心耗时环节，将简单需求的交付周期从天级压缩至小时级，大幅提升业务需求的响应与落地效率。

功能四

出码

平台深度基于 Vue Render 渲染机制构建，支持通过可视化拖拽、属性配置完成页面 / 组件的可视化绘制后，一键导出基于 Vue2.js 框架 + ElementUI 组件库的标准 Vue 单文件组件（.vue）源代码。导出的代码完全遵循 Vue2 语法规范与 ElementUI 组件调用逻辑，保留完整的组件结构（template/script/style）、属性配置、事件绑定及逻辑关联，无黑盒封装，可直接在 Vue2 项目中复用、二次开发或部署运行，实现 “可视化搭建” 与 “原生代码” 的无缝衔接。

出码优势：摆脱平台绑定，掌握开发自主权

获取完整的源代码，能基于导出的文件进行独立部署、运维和迭代，让系统开发不再依赖低代码平台本身。

兼顾高效开发与深度定制，平衡效率与灵活：前期依托低代码可视化拖拽快速完成项目主体搭建，大幅缩短开发周期；针对高复杂度、高个性化的业务需求，可导出源文件通过纯代码进行深度定制优化，既用低代码省时间，又用原生代码满足极致化需求，实现“高效搭建 + 深度定制”的双重效果。

二次开发的灵活性：跨项目、跨技术栈开发时，源文件能被复用、拆解，提升整体开发资源利用率。

跨项目、跨技术栈开发时，源文件能被复用、拆解，提升整体开发资源利用率。

结论

总而言之，织信低代码平台以可视化配置、快速部署、低门槛上手的核心优势，契合当下对数字化开发 “快、准、省” 的需求。它不仅是一款开发工具，更是企业数字化转型的专属解决方案，用技术简化开发，用效率赋能业务，这正是低代码平台的核心价值所在。

点量团队在与用户交流的过程中发现，有不少用户对摩尔线程显卡的实际图形负载能力存在疑问。为解答这一疑问，点量团队将Linux系统下摩尔线程S80显卡，和Windows系统下的RTX 3060显卡做了个对比，测试了WebGL和UE两个场景，以实际数据评估其性能表现。

• 测评环境1：Windows系统、RTX3060、点量云流实时云渲染windows版
• 测评环境2：Linux系统、摩尔线程S80、点量云流实时云渲染Linux版
• 测评3D应用：WebGL和UE两种引擎

测试之前，在云推流过程中统一了分辨率为1920x1080，帧率为60FPS，并且同时设置开三路。得到以下测试结论：

一、WebGL引擎测试

以ThreeJS官方的某个示例做测试，结果如下：
1、Windows下3060：显卡利用率，平均在21%。

2、Linux下摩尔线程S80：显卡利用率在20%左右，和3060相差不大。

由此可见，摩尔线程S80在WebGL模式下几乎等同于3060显卡。

二、UE引擎测试

以某个游戏UE场景做云推流测试，结果如下。若以Unity场景做测试，测试结果类似，这里不再展开。
1、Windows下3060：可以跑244.55fps，显卡利用率75%。

2、Linux下摩尔线程S80：只能跑20多FPS，显卡利用率97%。

我们判断，由于UE默认使用的Vulkan RHI, 猜测是摩尔线程驱动针对Vulkan优化不足的缘故。随后，我们继续测试了S80在Windows下的效果，用相同的UE程序（默认Windows下是使用DirectX），只能到30多帧，因此可能也不只是对Vulkan优化的问题。对比3060的话，UE是可以跑到240多帧，这方面的差异还是比较明显。

另外，测试还发现，S80在Windows下的WebGL效果也不如Linux下的表现，Windows下开三个WebGL就掉帧了，GPU利用率100%。

以上效果说明，S80在Linux下的WebGL效果还是不错的，能跟3060达到类似性能效果。但在UE程序、Windows系统等一些效果上还是差距比较明显。

特别说明：本次所有测试均为在特定测试环境（包括但不限于特定机型、驱动版本、系统设置）中完成的结果。不同软硬件配置、测试方法或环境变量均可能导致数据差异，本文内容仅作为客观事实记录与经验分享，不作为官方性能指标或决策依据，请读者结合多方信息进行综合判断。

通过本次测试，明确了摩尔线程在云渲染负载中的性能表现，并验证了摩尔线程在相关场景下的实际承载能力。点量云流系统的兼容适配能力并不局限于单一系统或硬件，且已在多系统、多配置场景中实现全面支持，真正做到了“一次适配，处处运行”，为不同技术架构下的用户提供统一、可靠的高性能云流服务。

在金融科技（FinTech）开发中，Real-time Data Fetching 是最基础也是最核心的模块。最近在重构我的交易系统，特地把数据接入层剥离出来做一个技术分享。

背景与问题 传统的Web开发中，我们习惯用REST API处理请求。但在金融交易场景下，HTTP协议存在明显的短板：

1. Header开销大：高频请求下，流量浪费严重。
2. 被动获取：无法做到服务器端的主动推送（Server Push）。
3. 并发限制：容易触流控（Rate Limit）。

对于美股这种Tick级别的数据量，WebSocket是唯一的正解。

技术实现路径 我的需求很简单：订阅AAPL、TSLA等热门标的的实时Tick，并存入Redis做清洗。在对比了多家数据提供商后，为了兼容性和稳定性，我选择了AllTick作为上游数据源，配合Python的websocket-client库进行开发。

代码架构 整个模块采用异步回调的方式处理数据，确保主线程不阻塞。以下是最小可行性产品（MVP）的代码实现：

import websocket
import json

# WebSocket连接地址（替换为实际API接口）
url = "wss://api.alltick.co/realtime/stock"

# 请求体，订阅的股票代码和API密钥
message = {
    "api_key": "your_api_key_here",  # 你的API密钥
    "symbol": "AAPL"  # 订阅Apple的实时行情
}

def on_message(ws, message):
    data = json.loads(message)
    print(f"实时获取的数据：{data}")

def on_error(ws, error):
    print(f"发生错误：{error}")

def on_close(ws, close_status_code, close_msg):
    print("WebSocket连接已关闭")

def on_open(ws):
    ws.send(json.dumps(message))

# 创建WebSocket应用并启动
ws = websocket.WebSocketApp(url,
                            on_message=on_message,
                            on_error=on_error,
                            on_close=on_close)
ws.on_open = on_open

# 保持连接并接收数据
ws.run_forever()

技术细节注意事项 在实际部署中，还需要考虑断线重连（Reconnection）和心跳检测（Heartbeat）。上述代码展示了最基础的订阅逻辑。通过on_message回调，我们可以直接解析JSON数据包。

经测试，这种方式比传统的while True: requests.get()循环，延迟降低了至少两个数量级。对于开发者来说，掌握WebSocket在金融数据处理中的应用，是一项必备技能。