Chrome 正式版(146.0.7680.72)支持垂直标签页了

个人还是比较喜欢的,比水平的能容纳更多的标签页
虽然目前还不是很好用就是了
顺便问问大家常用什么浏览器
xiaohack博客专注前沿科技动态与实用技术干货分享,涵盖 AI 代理、大模型应用、编程工具、文档解析、SEO 实战、自动化部署等内容,提供开源项目教程、科技资讯日报、工具使用指南,助力开发者、AI 爱好者获取前沿技术与实战经验。

个人还是比较喜欢的,比水平的能容纳更多的标签页
虽然目前还不是很好用就是了
顺便问问大家常用什么浏览器
想实现这个功能,有啥好的解决方案吗?
wifi 摄像头本地运行目标检测算法,把有目标的视频流传输到服务器处理。
以前以为三字经只有人之初性本善之类的,最近在 B 站看了一下,原来还有中国历史,寥寥百字浓缩几百年。
CCTV(未做合集): https://tv.cctv.com/2013/07/02/VIDA1372754065682918.shtml
B 站或者网盘可以搜一下合集。
昨天我参加了一场 AI 技术大会,满脑子想着学点新东西。 结果最让我震撼的,不是什么新技术,而是大屏幕上的这句话: 这句话像一盆冷水浇在我头上。 我拼命追逐新的工具,却忘了思考:在这个变化飞快的行业里,到底有什么是永恒不变的? 2008 年,Flash 是网页动画的王者,IE 浏览器 一统江湖。 我们以为这些会永远存在。 结果呢?移动互联网一来,Flash 直接被淘汰;IE 也成了“兼容性噩梦”的代名词。 后来,jQuery 统治了前端开发,接着 React、Vue 崛起,现在 AI 又能一秒生成代码了。 我熬了无数夜晚学的技术,很多都贴上了“过时”的标签。 这让我明白一个道理:在这个行业,没有永远的王者,只有不断变化的技术。 既然技术一直在变,那作为前端工程师,我们到底该抓牢什么? 我总结了三条“原则”——它们不会因为框架更新、工具换代而过时。 无论是 2008 年还是 2026 年,用户都不会等待一个慢吞吞的网站。 你的电商网站做得再花哨,有 3D 特效、有 AI 聊天机器人,但如果打开要等好几秒,用户转身就走。 即便 AI 写出了代码,分析包大小、定位网络瓶颈、优化掉 0.1 秒的能力——性能优化——始终是一项核心商业竞争优势。 即便框架更迭,性能优化的本质大体不变: 这些问题,放十年前问有意义,放十年后问依然有意义。 AI 能生成漂亮的界面,但真正懂用户的,还是人。 想想看:你在买东西时,从看到商品、加购物车到付款,中间可能遇到多少坑? 这些“真实使用场景”永远不会像教科书里写得那么完美。 无论用什么框架,用户体验的核心就是:别让用户焦虑,别让用户懵。 这需要工程师真正理解业务场景,而不是只会写代码。 浏览器兼容问题,以前有,现在还有,只是换了种形式。 有句话说得对:好写的代码,往往不好维护。 系统越大越复杂,架构设计能力就越值钱。AI 能帮你写代码,但设计系统结构、把控风险、让系统能应对变化,这些还得靠人。 技术浪潮一波接一波,追是追不完的。 真正能让你立住脚的,是看透这些变化背后的本质——性能、体验、可靠性。 就像贝索斯说的,与其猜什么会变,不如抓牢什么不会变。 在变化的世界里,找到那些不变的东西,才是安身立命的根本。 我是冴羽,10 年笔耕不辍,专注前端领域,更新了 10+ 系列、300+ 篇原创技术文章,翻译过 Svelte、Solid.js、TypeScript 文档,著有小册《Next.js 开发指南》、《Svelte 开发指南》、《Astro 实战指南》。 欢迎围观我的“网页版朋友圈”,关注我的公众号:冴羽(或搜索 yayujs),每天分享前端知识、AI 干货。“人们经常问我:未来 10 年什么会变?这确实是个好问题。但几乎没人问:未来 10 年什么不会变?“ —— 杰夫·贝索斯

1. 变化是唯一的常数

2. 原则 1:快,永远是对的
3. 原则 2:让用户爽,而不是让用户懵
3. 原则 3:可靠性与架构

最后
一个还没拿出惊艳产品的初创公司,竟然接到了英伟达送来的 “泼天算力”? 这一次,英伟达把投资触角伸向了这家还名不见经传的 “新 AI 实验室”。 3 月 10 日,前 OpenAI 高管 Mira Murati 宣布,她创办的 Thinking Machines Lab,与 NVIDIA 达成一项长期战略合作。 按照协议,英伟达将为 Thinking Machines Lab 提供至少 1 吉瓦 的下一代 NVIDIA Vera Rubin 系统,用于前沿模型训练和平台建设,支持其大规模交付可定制的 AI 解决方案;而 Thinking Machines Lab 则将围绕 NVIDIA 架构设计训练和服务系统,并扩大企业、研究机构和科学界对前沿人工智能及开放模型的访问。这套系统预计将于明年初正式部署。 简单来说,英伟达提供的是下一代算力底座,而 Thinking Machines Lab 则在这套底座上打磨训练体系、推理系统和模型能力。 这不是一笔普通的算力采购,而是资本、芯片和技术路线的一次深度绑定。 更值得关注的,是这笔合作的 规模。 1 吉瓦是什么概念?1 吉瓦等于 1000 兆瓦。 根据全球最权威的能源政策与数据机构之一 IEA 显示,普通数据中心通常只有 5 到 10 兆瓦,大型 hyperscale 数据中心通常在 100 兆瓦以上。而 Thinking Machines Lab 这次拿到的是 接近 10 个 100 兆瓦级大型数据中心的总量级。 有业内人士测算,这个规模足以覆盖约 75 万个美国家庭的用电规模,而整体投入成本甚至可能高达 500 亿美元。 放在今天的 AI 竞赛里,这已经不是普通创业公司的配置。真正接近这一门槛的,往往只有 最顶级的 AI 实验室。 2025 年 9 月,OpenAI 与英伟达公布的战略合作,共同部署 10 吉瓦 AI 基础设施,以支撑下一代 AGI 的开发,这是史上空前的算力投资规模,而 Thinking Machines Lab 拿下的量级,已是它的 十分之一。横向来看,马斯克在 2025 年末为 xAI 买下第三栋大楼,目标将训练能力推至近 2 吉瓦;Meta 在得州推进的新数据中心,拓展目标也在 1 吉瓦级。 可以说,在算力储备上,这家创业公司已经和巨头站在同一量级。 据美国媒体 Axios 推测,如此庞大的算力,不可能只用来做小模型、垂直应用或轻量化工具。它更对应持续的基础模型训练、多模态系统开发、推理平台搭建,以及面向企业和科研机构的大规模服务能力。 而在 Mira Murati 的推特上,也能找到一些“蛛丝马迹”,她点出一个关键词 “协作式人工智能”。 所谓“协作式 AI”,就是强调与人共同完成任务、能按个人或机构需求灵活适配的多模态系统。 作为 Open AI 人才流向中最显眼、最集中的新去处之一,Thinking Machines Lab 从诞生起就自带光环。 这家公司成立于 2025 年 2 月,据路透社报道,刚亮相时团队约 30 人,其中 至少 20 人来自 OpenAI。成立仅 5 个月,它就拿下 20 亿美元种子轮融资,成为硅谷史上最大种子轮之一,投资方名单包括 a16z、英伟达、AMD、思科等巨头。黄仁勋更是直接称其为 “世界一流的团队”。 此次与英伟达的合作,已是英伟达在种子轮之后,再度加码投资 + 绑定算力。这无疑释放了几个信号: Thinking Machines Lab 正在升级,从一家 “明星创业公司”,走向 “前沿模型基础设施玩家”。它瞄准的,不只是应用层的细分赛道,而是下一代前沿模型的核心竞争。 而英伟达不只想卖铲子,还想参与建矿了,它希望更深地嵌入下一代 AI 公司的资本结构、算力供给和技术路线图之中。 如果只把这笔合作理解为英伟达对一家明星创业公司的特殊扶持,可能还是低估了它的意义。 从押注 Thinking Machines Lab,到回看英伟达的整体布局,就能清晰看出这家芯片巨头为巩固断崖式领先所布下的全局棋局。 面对已成型的 AI 巨头,英伟达先是与 OpenAI 达成 10 吉瓦算力合作,共建 AI 工厂,并持续巨额投入;随后又通过微软、英伟达、Anthropic 三方绑定,为 Anthropic 提供下一代硬件、1GW 算力与最高 100 亿美元投资,双方还联合定制模型与芯片架构,实现技术深度锁死。 面对 AI 新势力,英伟达同样全面下注:向 AI 搜索公司 Perplexity 投资 5 亿美元,参投 AI 视频工具 Runway、人形机器人 Figure AI、自动驾驶公司 Wayve 等一众明星项目,几乎覆盖下一代热门赛道。 可以说,英伟达布局逻辑很直白,提前锁定未来大客户,而不是等它们长大再抢单。 Thinking Machines Lab 正是英伟达看中的 “超级潜力买家”,它押注的不是某个产品,而是下一个 OpenAI 级别的平台型公司。哪怕这家新实验室目前只有训练 API、研究方向与明星团队,英伟达看重的是其未来长成平台的潜力。越早进入这些公司的资本结构与技术路线,就能越早分享整个生态成长的红利,而不只是单一的芯片收入。 而且,英伟达的 “绑定” 早已不是简单提供算力,而是将客户锁进从芯片、网络、系统软件到数据中心的整套 AI Factory 全栈方案。 对英伟达而言,押注 AI 新实验室的意义,不只是提前卖出下一代 GPU,更在于趁这些公司仍处于底层系统搭建阶段,就把自己的架构写进其训练、推理和运维体系。等到模型、集群和服务真正跑起来,客户依赖的将不再只是某一代芯片,而是整套基础设施逻辑,迁移成本也会随之大幅抬升。 黄仁勋在 2026 年 GTC 上曾用一个颇具代表性的框架来解释这种变化。他把 AI 产业概括为一个自下而上的“五层架构”:能源、芯片、基础设施、模型和应用。 过去外界更习惯把 AI 竞争理解为模型之争,但在黄仁勋的叙述里,最底层的能源,才是 AI 基础设施的第一性原理。没有足够的电力、冷却、园区和并网能力,就谈不上后面的芯片集群,更谈不上模型训练和应用落地。 而在最新的长篇博客中,这一判断被进一步推到了产业底层逻辑的高度。黄仁勋的核心意思是:今天的 AI 仍处在极早期阶段。过去几年行业确实已经砸下了数千亿美元,但这些投入更像是在铺设地基,距离 AI 潜力被真正释放,仍有很长的路要走。 他甚至预测,到本世纪末,全球 AI 基础设施支出将达到 3 万亿~4 万亿美元 。 顺着这套逻辑看,英伟达现在想推进的,已经不只是“芯片公司”的角色,而是更接近 AI 工厂总包商。 它一边与 OpenAI、Anthropic、Thinking Machines 这样的模型公司深度绑定,一边与 Meta 等科技巨头推进多年期基础设施合作,也与 Lilly 这样的制药企业、以及政府和科研机构推动行业级、国家级 AI 基建。 这里最深的一层争夺,其实不是某一笔订单,而是 标准制定权:未来训练大模型、跑推理、做物理 AI、建设 GW 级园区,默认应该采用什么架构、什么网络、什么供电和冷却方式、什么系统软件栈。谁定义了这套默认方案,谁就不再只是供应商,而是在定义下一代 AI 工厂的入口与标准。 再看 Thinking Machines Lab,这家公司从一开始切入的,其实就是模型后训练和微调基础设施这层“脏活累活”。 具体来说,它给研究者、开发者留足了自主权,可以自己掌控训练用的数据、算法和训练逻辑,训练出来的模型权重,也可以保存、恢复、下载,甚至发布出去。 而这家公司的核心作用,就是提供一套现成的训练工具,帮大家解决训练过程中最头疼的问题,比如分布式训练、任务调度、资源分配和故障恢复,让开发者不用再费心搞这些“底层基建”,能专心做模型本身。 表面看,它是在帮别人微调模型;往深了看,它真正搭建的是一套面向未来的底座。 无论是更大规模模型训练、更复杂的实验流程,还是更高强度的推理需求,最终都要落到这套系统能力上。 而搭建这样的 AI 基础平台,当然离不开超大算力的支撑,这也是它与英伟达展开合作的重要原因。 但或许又有人问了,它从英伟达拿到的 1 吉瓦算力,搞这么大场面,只是为了做这些么? 确实不止如此,我们可以进一步揣测一下 Thinking Machines Lab 的野心。 从公司官网可以看出,这家公司反复强调两件事: 第一,多模态是核心。只有让模型真正具备理解图像、文本乃至真实世界的能力,AI 才可能走向大规模落地。 第二,研究和产品不能分开,研究能否高效推进,最终取决于底层基础设施是否稳定、顺手、可扩展。 如此大规模的算力投入,显然不是为了训练一版模型后就停机,而是为了同时支撑多个层面的任务:前沿基础模型预训练、多模态与大规模 MoE 模型的持续实验、模型后训练与优化、企业客户服务,以及面向科研机构的开放访问。 这也意味着,Thinking Machines Lab 的野心从来不只是做出一个模型,而是想把自己的模型能力、训练能力和服务能力,铺成一张可扩展的分发网络。 如果说过去 AI 竞争比拼的是“谁拥有更好的模型”,那么今天比拼的已经是“谁能同时攥住资本、芯片、供电、园区和系统架构协同”。对于创业公司而言,能和英伟达这样的巨头深度绑定,意味着能获得最稀缺的确定性算力与交付效率。 Thinking Machines Lab 高调亮出 1 吉瓦算力,本质上是在向外界宣告:它不满足于做牌桌旁的旁观者,而是要真正坐上牌桌,与 OpenAI、Anthropic 等巨头正面竞争。 不过,野心越大,组织压力也越大。Thinking Machines Lab 成立仅一年左右,团队就从最初约 30 人扩张到约 120 人。 与此同时,其核心联合创始人集体 “叛逃。2025 年 10 月,联合创始人 Andrew Tulloch 离开公司加入 Meta;2026 年 1 月,两位联合创始人 Barret Zoph 和 Luke Metz 与研究人员 Sam Schoenholz 纷纷回到 OpenAI。 对一家仍处快速扩张期的公司来说,这未必意味着战略失速,但足以说明,它的“全栈野心”正在经受组织动荡的考验。 参考链接:
英伟达的全面布局

Thinking Machines Lab 的野心与动荡
报错信息 解决方案 把 xxx.xxx.xxx.xxx 改成你的公网 ip 报错信息 报错信息
openclaw config set gateway.controlUi.allowedOrigins '["http://xxx.xxx.xxx.xxx:18789"]'openclaw config set gateway.controlUi.allowedOrigins '["http://xxx.xxx.xxx.xxx:18789"]'
control ui requires device identity (use HTTPS or localhost secure context)
device identity required
随着物联网技术的快速发展,LoRaWAN 凭借远距离通信、低功耗和广覆盖等优势,已经在智慧城市、工业监测、环境监测、能源管理等领域得到广泛应用。然而在实际的大规模部署过程中,许多项目在运行一段时间后会遇到一个看似难以解释的问题:网络信号良好,但设备通信却逐渐变得不稳定。 这一现象的根本原因,往往并不是设备质量或网关覆盖问题,而是 LoRaWAN 网络中一个常被忽视的瓶颈——空中资源挤兑(Air Resource Congestion)。当网络规模扩大、设备数量增加时,如果没有合理的通信策略,网络的空中资源很容易被占满,从而导致通信效率下降。 本文将从 LoRaWAN 网络通信机制出发,分析空中资源挤兑产生的原因,并结合实际项目经验,总结三种经过验证的优化策略,帮助提升 LoRaWAN 网络在大规模部署中的稳定性和效率。 一、空中资源挤兑的根本原因:上下行能力不对称 在 LoRaWAN 网络中,上行(Uplink)和下行(Downlink)的能力存在明显的不对称。 一个典型的 LoRaWAN 网关通常具备以下能力: 8 个接收频点 这意味着网关理论上可以同时接收多个终端设备的上行数据包。多个终端在不同频点、不同扩频因子(SF)下发送数据时,网关可以并行处理这些数据。 然而,下行通信的能力却要弱得多。 大多数 LoRaWAN 网关通常只具备一个发射通道,这意味着所有下行数据必须通过同一个信道发送。 因此在通信模式上形成了一个明显特点: 上行通信可以并行处理 当网络规模扩大时,一旦大量设备需要下行响应,例如: Join Accept(入网响应) 这些数据都必须通过唯一的下行通道发送,从而使下行成为整个网络的瓶颈。 当下行通道拥堵时,就会产生一系列连锁问题,例如: 设备重试次数增加 最终形成所谓的“空中资源挤兑”。 二、策略一:优化入网机制,避免“入网风暴” 很多 LoRaWAN 设备默认采用“上电立即入网”的策略。这在单设备或小规模网络中通常不会出现问题。 但在实际项目环境中,经常会出现一些集中事件,例如: 区域停电后统一恢复供电 在这些场景下,大量设备会在同一时间发送 Join 请求。 由于每一个 Join 请求都需要一个 Join Accept 下行响应,而网关只有一个下行通道,很容易出现所谓的 Join Storm(入网风暴)。 其结果通常是: 大量 Join 请求失败 优化策略:按需入网 更合理的设计方式是采用“按需入网”的策略,而不是设备每次上电都重新入网。 例如,设备可以在以下情况下才重新执行 Join 操作: 连续多次发送 Confirmed 数据但未收到 ACK 通过这种机制,可以显著减少不必要的 Join 操作,从而降低下行压力。 三、策略二:慎用确认包,减少下行压力 LoRaWAN 协议支持两种数据传输模式: Unconfirmed Data(非确认包) 当设备发送 Confirmed 数据时,网络服务器必须返回一个 ACK 确认。 这意味着: 每一个确认上行数据包,都需要产生一个下行数据包。 在小规模网络中,这种模式并不会造成明显问题。 但在大规模网络中,如果大量设备都使用 Confirmed 模式,就会导致下行信道长期被 ACK 占用。 其结果包括: Join Accept 延迟 优化建议 优先使用 Unconfirmed 数据模式 对于大多数周期性监测数据,例如温湿度、压力、水表读数等,即使偶尔丢失一条数据,也不会影响整体业务,因此完全可以使用 Unconfirmed 模式。 应用层确认机制 如果某些业务需要更高的数据可靠性,可以在应用层实现确认逻辑。例如服务器检测数据是否按预定周期到达,如果发现数据缺失,再触发补发或报警机制。 随机化下行时间 对于需要下行通信的场景,可以通过时间随机化机制避免大量设备在同一时间等待下行响应。例如可以根据设备 DevAddr 生成基础时间槽,并叠加随机延迟,从而降低冲突概率。 四、策略三:引入本地 ADR,提高通信效率 LoRaWAN 协议提供了一项重要机制:ADR(Adaptive Data Rate,自适应数据速率)。 ADR 的作用是根据链路质量动态调整通信参数,例如: 扩频因子(SF) 如果链路质量较好,设备可以使用更高的数据速率,例如 SF7,从而缩短数据包在空中的传输时间,提高网络容量。 ADR 在实际网络中的问题 在很多 LoRaWAN 网络中,ADR 的调整通常由网络服务器通过下行指令完成。 但当网络下行通道已经拥堵时,这些 ADR 指令可能长时间无法发送。 结果是设备一直使用较低速率,例如 SF12,而 SF12 的数据包空中时间非常长。 这会进一步加剧网络拥堵。 解决方案:本地 ADR 一种更加高效的方式是在终端设备中实现 Local ADR(本地 ADR)。 设备可以根据接收到的信号质量参数,例如: RSSI 自动调整通信速率。 只要链路质量允许,设备就可以优先使用: SF7 或 SF8 这种方式可以显著减少数据包占用的空中时间,从而提升整个网络的容量。 五、优化策略带来的实际效果 通过合理优化 LoRaWAN 网络的通信策略,可以显著提升大规模网络的整体性能。 入网机制优化 确认机制优化 ADR 优化 在实际项目中,这些优化措施可以带来: 更高的网络稳定性 如果结合成熟的 LoRaWAN 解决方案,例如稳定的 LoRaWAN 网关、DTU、传感器以及网络服务器平台,还可以进一步提升系统可靠性,使大规模 LoRaWAN 网络更加高效稳定。 六、结语 LoRaWAN 网络在大规模部署时,空中资源挤兑是一个容易被忽视但影响极大的问题。 其本质原因在于 LoRaWAN 网络上下行能力的不对称。 当设备规模达到数千甚至上万时,如果没有合理的通信策略,下行通道很容易成为整个系统的瓶颈。 通过优化入网机制、减少确认包使用以及提高通信速率,可以显著提升 LoRaWAN 网络的整体效率。 在智慧城市、工业物联网和能源管理等场景中,这些优化策略对于构建稳定可靠的大规模 LoRaWAN 网络具有重要意义。
16 个并行解调器
下行通信必须排队发送
ACK 确认
MAC 控制指令
ACK 丢失
Join 失败
网络延迟增加
设备同时入网带来的问题
集中供电设备同时启动
大规模设备批量重启
设备反复重试
网络进一步拥堵
长时间未收到任何下行数据
检测到网络参数发生变化
Confirmed Data(确认包)
控制指令下发缓慢
网络整体效率下降
发射功率
SNR
减少 Join 请求,避免入网风暴
降低 ACK 产生数量,提高下行可用带宽
减少空中时间占用,提高网络容量
更好的系统吞吐能力
更低的通信延迟
刚刚试了下,让 OpenClaw 直接读帖、组织内容、再自动发布到 V2EX 。
目前看流程是可用的:
这条就是它自己按我指令发出来的,算个小实验记录。
如果大家也在折腾自动化代理,欢迎交流你们的工作流。
上周六部署了一下龙虾🦞到 macbook 上,然后让龙虾总结一下我的微信聊天记录,今天就收到了账号安全提醒,要做题和签保证书才能恢复

北京中烟创新科技有限公司(简称:中烟创新)以“懂行业、通业务、强技术”的核心优势,构建了覆盖烟草行业全价值链的AI解决方案体系,成为推动行业高质量发展的核心力量。而OpenClaw作为开源、自托管、本地优先的AI智能体执行网关,凭借“真执行、高安全、可扩展”的技术特性,打破了传统大模型“只动嘴不动手”的局限,为垂直行业场景的自动化落地提供了全新可能。二者的融合基于中烟创新现有产品矩阵,以OpenClaw的执行能力补全智能化闭环,实现“行业知识+AI执行”的双重赋能,推动行业智能化从“技术赋能”向“业务闭环”升级,彰显科技与产业深度融合的专业价值。
嵌入式集成OpenClaw执行能力中烟创新经过三年深耕,已形成覆盖专卖监管、财务管理、综合办公、信创适配等领域的成熟产品矩阵,其核心诉求是“让AI真正落地业务场景,解决行业实际痛点,同时保障数据安全与合规性”。而OpenClaw的核心定位的是“连接AI大脑与本地执行环境的桥梁”,其技术特性与中烟创新的产品需求形成天然契合,为二者融合奠定了坚实基础。从技术层面看,OpenClaw的本地优先、全模型兼容、安全沙箱、可扩展四大核心优势,精准匹配中烟创新产品的行业特性:一是本地持久化存储与离线运行能力,契合烟草行业对核心数据(如执法案卷、财务票据、采购信息)隐私保护的严苛要求,与中烟创新信创优先的研发导向高度一致,可实现敏感数据不上传第三方服务器,保障数据自主可控;二是全模型兼容特性,可无缝适配中烟创新“灯塔大模型应用开发平台”,既支持云端大模型调用,也可适配本地部署的国产大模型,无需对现有技术架构进行大规模改造;三是安全沙箱层的精细化权限管控,可适配合规风控要求,避免误执行操作破坏系统,实现执行过程全程可追溯、可审计;四是自定义技能扩展能力,可根据中烟创新各产品的业务场景,开发专属执行技能,实现与业务流程的深度咬合。结合中烟创新的核心产品矩阵,OpenClaw的融合聚焦各产品的核心业务场景,以“嵌入式集成+定制化开发”的方式,补全自动化执行环节,实现从“需求发起”到“结果交付”的全流程闭环,具体可分为四大核心场景,每个场景均形成可落地、可复制的融合方案。
自动化提质,合规化增效中烟创新在专卖监管领域的核心产品包括“烟草专卖执法案卷评查系统”“烟草案卷全域画像分析系统”,其核心功能是实现执法文书规范生成、案卷质量评查、风险预警与决策辅助,但在案卷数据采集、批量处理、多系统协同等环节仍存在人工干预较多的痛点,OpenClaw的嵌入的可实现全流程自动化升级。具体融合路径分为三点:一是案卷数据自动化采集与标准化处理,通过OpenClaw开发专属技能,对接执法终端、政务系统、电子卷宗库等多渠道数据源,自动抓取案件受理信息、执法文书、处罚记录等数据,无需人工手动录入;同时,利用OpenClaw的文件处理能力,对扫描件、PDF格式的案卷材料进行OCR识别、内容提取与标准化整理,自动匹配中烟创新案卷系统的字段要求,将单份案卷的录入与整理时间从小时级缩短至分钟级,大幅降低基层执法人员的事务性负担。二是案卷评查与风险预警自动化执行,依托OpenClaw的终端执行与规则匹配能力,将中烟创新案卷评查系统内置的1000余项法律法规规则、文书校验标准,转化为自动化执行指令,实现案卷的批量评查——自动扫描文书中的日期逻辑、签名完整性、法条引用准确性等易错点,生成问题清单与整改建议,同时将评查结果自动同步至案卷全域画像分析系统,更新风险预警指标,推动执法监督从“事后纠错”向“事中防控”转变。三是跨系统协同自动化,通过OpenClaw的API编排能力,实现专卖执法系统与公安、市场监管等外部系统的自动数据同步,比如案件立案后自动推送相关信息至公安系统备案,处罚决定生效后自动同步至信用监管平台,无需人工切换系统操作,实现执法流程的闭环协同。该融合方案已可实现“执法数据采集—案卷整理—评查预警—跨系统同步”的全自动化,既保障了执法合规性,又将基层执法人员从繁琐的重复性工作中解放出来,聚焦核心执法任务,使案卷处理效率提升80%以上。
全流程自动化,风控更精准中烟创新的“智能费用审核系统”是财务智能化领域的核心产品,已实现票据AI采集与自动化审核,但在票据归档、数据对账、异常处理、报表生成等环节仍需人工介入,OpenClaw的融合可进一步打通财务流程的自动化闭环,实现“审核—归档—对账—报表”全链条无人干预。具体融合路径体现在四个维度:一是票据审核后自动化归档,当智能费用审核系统完成票据审核后,OpenClaw自动接收审核结果,根据中烟创新“一项一卷”的归档要求,将票据原件、审核报告、支付凭证等相关材料按项目分类,自动生成归档目录,同步存储至本地档案系统与信创兼容的数据库,实现归档流程的全自动化,避免人工归档出现的遗漏、错乱问题。二是财务数据自动对账与异常处置,通过OpenClaw对接智能费用审核系统、财务核算系统、银行支付系统,设定自动对账规则,每日定时抓取各系统的收支数据、票据数据,自动完成对账匹配,识别金额不符、票据缺失等异常情况,生成对账差异报告,并自动推送至相关财务人员,同时根据预设规则,完成简单异常的自动处置(如提醒补传票据),将异常单据处理周期由3天缩短至30分钟以内。三是财务报表自动生成与推送,基于中烟创新财务系统的核心指标要求,通过OpenClaw自定义报表生成技能,自动抓取财务数据,按日、周、月生成标准化财务报表,无需人工手动统计与编制,同时自动推送,确保决策层及时掌握财务动态。四是合规风控自动化强化,利用OpenClaw的日志记录与执行追溯能力,对财务审核、归档、对账的全流程进行全程记录,生成可审计的执行日志,同时自动扫描财务流程中的合规风险点(如超预算支出、票据不合规),与中烟创新财务风控规则联动,实现风险的自动预警与处置,平衡财务效率与合规风控。
简化操作,提升协同效率中烟创新的综合管理平台、低代码开发平台及信创迁移解决方案,覆盖企业OA流程、采购管理、人事管理、项目管理等核心模块,核心需求是“简化操作流程、实现跨模块协同、保障信创环境适配”,OpenClaw的融合可实现办公流程的自动化升级与信创环境的深度适配。在综合办公场景,融合路径主要包括:一是OA流程自动化执行,通过OpenClaw对接中烟创新OA系统,实现请假、报销、审批等流程的自动化触发与执行,比如员工提交请假申请后,OpenClaw自动匹配审批流程,推送审批通知,审批完成后自动更新员工考勤记录、同步至人事管理模块,无需人工手动流转;二是采购管理自动化升级,结合中烟创新采购合规要求,OpenClaw自动抓取采购需求、供应商信息,对接招标文件查重系统,自动完成招标文件的查重与合规校验,同时实现采购合同的自动生成、签署提醒、归档管理,破解采购全流程的合规难题与效率瓶颈;三是跨模块数据自动同步,通过OpenClaw的API编排能力,实现OA系统、人事管理系统、项目管理系统的数据自动同步,比如员工入职后,自动完成OA账号开通、人事档案录入、项目权限分配,避免多系统重复录入,提升协同效率。
补全执行能力,释放模型价值中烟创新的“灯塔大模型应用开发平台”是其核心技术底座,已完成与多款国产软硬件的兼容适配,具备强大的行业模型训练与应用开发能力,但传统大模型仅能提供决策建议,无法直接执行具体任务,OpenClaw的融合可补全大模型的“执行手脚”,实现“模型思考—指令生成—任务执行”的闭环。具体融合路径为:将OpenClaw作为灯塔大模型的“执行网关”,实现二者的无缝对接——灯塔大模型对业务需求进行分析、决策,生成具体的执行指令,OpenClaw接收指令后,自动调用对应的技能(如文件处理、终端执行、API对接),完成具体任务的落地执行,并将执行结果反馈给灯塔大模型,形成“需求输入—模型决策—执行落地—结果反馈”的完整闭环。
例如,在市场分析场景,灯塔大模型基于销售数据、市场调研数据,生成“生成区域销售趋势分析报告”的决策指令,OpenClaw接收指令后,自动抓取相关数据,完成数据清洗、分析、可视化,生成标准化报告,同步推送至营销管理人员;在模型训练场景,灯塔大模型生成“采集行业最新数据用于模型迭代”的指令,OpenClaw自动抓取烟草行业政策、市场动态、业务数据,进行标准化处理后,同步至灯塔大模型的训练数据集,提升模型的精准度与行业适配性。
技术的价值,终要回归到产业的实际需求中去检验;而产业的升级,则依赖于技术与场景的深度融合与双向奔赴。OpenClaw与中烟创新的这次战略融合,并非简单的功能叠加,而是一次从“技术赋能”到“业务闭环”的范式跃迁。随着产品融合的持续深化,这种“懂行业、能落地”的结合,将持续催生更多创新应用,为推动各行业高质量发展注入源源不断的科技动能,技术的深耕永无止境,场景的赋能未有穷期!
本文主要介绍观测云对 Serverless 容器内日志采集的最佳实践,通过观测云 CRD+DataKit Operator 注入 logfwd sidecar 的方式实现采集,方案主要特点如下:一、概述
二、前置条件
logfwdserver 采集器,例如默认监听端口是 95339533 端口,使得其他 Pod 能访问 datakit-service.datakit.svc:9533三、采集流程
1. 注册 Kubernetes CRD
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
name: clusterloggingconfigs.logging.datakits.io
labels:
app: datakit-logging-config
version: v1alpha1
spec:
group: logging.datakits.io
versions:
- name: v1alpha1
served: true
storage: true
schema:
openAPIV3Schema:
type: object
properties:
apiVersion:
type: string
kind:
type: string
metadata:
type: object
spec:
type: object
required:
- selector
properties:
selector:
type: object
properties:
namespaceRegex:
type: string
podRegex:
type: string
podLabelSelector:
type: string
containerRegex:
type: string
podTargetLabels:
type: array
items:
type: string
configs:
type: array
items:
type: object
required:
- source
- type
properties:
source:
type: string
type:
type: string
disable:
type: boolean
path:
type: string
multiline_match:
type: string
pipeline:
type: string
storage_index:
type: string
tags:
type: object
additionalProperties:
type: string
scope: Cluster
names:
plural: clusterloggingconfigs
singular: clusterloggingconfig
kind: ClusterLoggingConfig
shortNames:
- loggingkubectl apply -f clusterloggingconfig-crd.yamlkubectl get crd clusterloggingconfigs.logging.datakits.io
2. 安装配置 DataKit-Operator
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: datakit-operator
rules:
- apiGroups: ["logging.datakits.io"]
resources: ["clusterloggingconfigs"]
verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: datakit-operator
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: datakit-operator
subjects:
- kind: ServiceAccount
name: datakit-operator
namespace: datakit
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: datakit-operator
namespace: datakit
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: datakit-operator
namespace: datakit
labels:
app: datakit-operator
spec:
replicas: 1 # Do not change the ReplicaSet number!
selector:
matchLabels:
app: datakit-operator
template:
metadata:
labels:
app: datakit-operator
spec:
serviceAccountName: datakit-operator
containers:
- name: operator
# other..
3. DataKit Deployment 部署
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: datakit
rules:
- apiGroups: ["rbac.authorization.k8s.io"]
resources: ["clusterroles"]
verbs: ["get", "list", "watch"]
- apiGroups: [""]
resources: ["nodes", "nodes/stats", "nodes/metrics", "namespaces", "pods", "pods/log", "events", "services", "endpoints", "persistentvolumes", "persistentvolumeclaims", "pods/exec"]
verbs: ["get", "list", "watch"]
- apiGroups: ["apps"]
resources: ["deployments", "daemonsets", "statefulsets", "replicasets"]
verbs: ["get", "list", "watch"]
- apiGroups: ["batch"]
resources: ["jobs", "cronjobs"]
verbs: [ "get", "list", "watch"]
- apiGroups: ["monitoring.coreos.com"]
resources: ["podmonitors", "servicemonitors"]
verbs: ["get", "list", "watch"]
- apiGroups: ["logging.datakits.io"]
resources: ["clusterloggingconfigs"]
verbs: ["get", "list", "watch"]
- apiGroups: ["metrics.k8s.io"]
resources: ["pods", "nodes"]
verbs: ["get", "list"]
- nonResourceURLs: ["/metrics"]
verbs: ["get"]
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: datakit
namespace: datakit
---
apiVersion: v1
kind: Service
metadata:
name: datakit-service
namespace: datakit
spec:
selector:
app: daemonset-datakit
ports:
- name: svc-http-port
protocol: TCP # for HTTP apis and some collector(inputs) HTTP server, such as DDTrace
port: 9529
targetPort: http-port
- name: svc-statsd-port
protocol: UDP
port: 8125
targetPort: statsd-port
- name: svc-otel-grpc-port
protocol: TCP
port: 4317
targetPort: otel-grpc-port
- name: svc-logfwd-port
protocol: TCP
port: 9533
targetPort: logfwd-port
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: datakit
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: datakit
subjects:
- kind: ServiceAccount
name: datakit
namespace: datakit
---
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: daemonset-datakit
name: datakit
namespace: datakit
spec:
replicas: 1
revisionHistoryLimit: 10
selector:
matchLabels:
app: daemonset-datakit
template:
metadata:
labels:
app: daemonset-datakit
spec:
hostNetwork: true
dnsPolicy: ClusterFirstWithHostNet
containers:
- env:
- name: POD_NAME
valueFrom:
fieldRef:
fieldPath: metadata.name
- name: ENV_K8S_NODE_IP
valueFrom:
fieldRef:
apiVersion: v1
fieldPath: status.hostIP
- name: ENV_K8S_NODE_NAME
valueFrom:
fieldRef:
apiVersion: v1
fieldPath: spec.nodeName
#- name: ENV_K8S_CLUSTER_NODE_NAME
# value: cluster_a_$(ENV_K8S_NODE_NAME)
- name: ENV_DATAWAY
value: https://openway.guance.com?token=tkn_3a0052c9f6d3498c8ce9ca0988fd9c82 # Fill your real Dataway server and(or) workspace token
- name: ENV_CLUSTER_NAME_K8S
value: lyr-test
- name: ENV_GLOBAL_HOST_TAGS
value: host=__datakit_hostname,host_ip=__datakit_ip
- name: ENV_GLOBAL_ELECTION_TAGS # Default not set
value: ""
- name: ENV_DEFAULT_ENABLED_INPUTS
value: statsd,dk,cpu,disk,diskio,mem,swap,system,hostobject,net,host_processes,container,kubernetesprometheus,logfwdserver,ddtrace
- name: ENV_ENABLE_ELECTION
value: enable
- name: ENV_HTTP_LISTEN
value: 0.0.0.0:9529
- name: HOST_PROC
value: /rootfs/proc
- name: HOST_SYS
value: /rootfs/sys
- name: HOST_ETC
value: /rootfs/etc
- name: HOST_VAR
value: /rootfs/var
- name: HOST_RUN
value: /rootfs/run
- name: HOST_DEV
value: /rootfs/dev
- name: HOST_ROOT
value: /rootfs
image: pubrepo.guance.com/datakit/datakit:1.86.2
imagePullPolicy: IfNotPresent
name: datakit
ports:
- containerPort: 9529
hostPort: 9529
name: http-port
protocol: TCP
- containerPort: 8125
hostPort: 8125
name: statsd-port
protocol: UDP
- containerPort: 4317
hostPort: 4317
name: otel-grpc-port
protocol: TCP
- containerPort: 9533
hostPort: 9533
name: logfwd-port
protocol: TCP
resources:
requests:
cpu: "200m"
memory: "128Mi"
limits:
cpu: "2000m"
memory: "4Gi"
securityContext:
privileged: true
volumeMounts:
- mountPath: /usr/local/datakit/cache
name: cache
readOnly: false
- mountPath: /rootfs
name: rootfs
mountPropagation: HostToContainer
- mountPath: /var/run
name: run
mountPropagation: HostToContainer
- mountPath: /sys/kernel/debug
name: debugfs
- mountPath: /var/lib/containerd/container_logs
name: container-logs
mountPropagation: HostToContainer
hostIPC: true
hostPID: true
restartPolicy: Always
serviceAccount: datakit
serviceAccountName: datakit
tolerations:
- operator: Exists
volumes:
- configMap:
name: datakit-conf
name: datakit-conf
# - name: hellopythond
# configMap:
# name: python-scripts
- hostPath:
path: /
name: rootfs
- hostPath:
path: /var/run
name: run
- hostPath:
path: /sys/kernel/debug
name: debugfs
- hostPath:
path: /root/datakit_cache
name: cache
- hostPath:
path: /var/lib/containerd/container_logs
name: container-logs
# # ---iploc-start
#- emptyDir: {}
# name: datakit-ipdb
# # ---iploc-end
strategy:
rollingUpdate:
maxUnavailable: 1
type: RollingUpdatekubectl apply -f datakit.yaml4. 创建日志 CRD 采集配置
apiVersion: logging.datakits.io/v1alpha1
kind: ClusterLoggingConfig
metadata:
name: demo-logs
spec:
selector:
namespaceRegex: "^(default)$"
podRegex: "^(deploy.*)$"
podLabelSelector: "app=demo"
podTargetLabels:
- app
- version
- enviroment
configs:
- source: "demo-file"
type: "file"
path: "/data/logs/server/server.log"
tags:
log_type: "server"
component: "springboot-server"kubectl apply -f logging-config.yaml
5. 查看日志上报(首次需重启业务)


最近OpenClaw火得一塌糊涂,到处都在吹“全自动AI员工”、“让AI帮你打工”。听得我也热血沸腾,仿佛已经看到了自己躺在沙滩上,OpenClaw在家里没日没夜帮我写代码赚钱的美好未来。🏖️ 于是,我兴冲冲地去Github上拉了代码,准备部署一套属于自己的“超级AI助手”。 然而,当我真正把这玩意儿跑起来之后,我才发现:这哪里是请了个免费员工,这分明是请了个“吞金兽”回家供着啊! 🦁 今天咱们不谈技术情怀,就谈谈最俗的:钱和时间。 很多人看到OpenClaw开源就觉得是“免费”的。错!大错特错!❌ 1. 服务器成本:AI也得有房住 你想让OpenClaw 24小时待命?那你得有个服务器吧。 官方推荐配置起步就是2核4G。这还是“温饱线”,实际上跑起来Docker一拉,内存分分钟飙红。 为了保证它不卡死,你至少得整台4核8G的云服务器。现在的行情,稍微稳定点的云厂商,这配置一个月得多少钱?少说200-300块。一年下来就是3000+ 的固定支出。 这还没算带宽费,OpenClaw抓取网页、下载依赖,流量跑得飞快。 2. Token成本:它思考一次,你就得付一次费 OpenClaw最大的特点是“Agent模式”:它会自己思考、拆解任务、甚至自我反思。 听起来很酷对吧?但这意味着:极其恐怖的Token消耗量! 💸 你让它“写个贪吃蛇游戏”,它可能要: 为了解决一个简单的Bug,它可能在后台默默调用了上百次GPT-4的接口。等你月底看到API账单的时候,你会发现:雇个真人实习生可能都比它便宜! 如果说钱还能忍,那时间成本才是压垮打工人的最后一根稻草。 OpenClaw不是一个简单的App,它是一个庞大的分布式系统。 网关、数据库、消息队列、沙箱环境……每一个环节都可能出问题。 本来是想“自动化”省时间的,结果搭进去的时间比我自己手动干活还要多十倍! 这不是本末倒置是什么? OpenClaw强不强?强!它是技术极客的玩具,是企业级探索的方向。 但对于咱们普通打工人、独立开发者来说,它真的不划算。 这就好比:你只是想每天早上喝杯豆浆,结果你非要花几十万买条全自动流水线放在客厅里。豆浆是喝上了,但你为了维护这条流水线,把家底都掏空了。 听我一句劝: 如果你是为了学习AI架构,去读OpenClaw的源码,那是极好的。但如果你只是想找个工具帮你干活,老老实实买个ChatGPT Plus或者Copilot会员吧。那是真正的“开箱即用”,把复杂留给厂商,把时间留给自己。 别让“AI焦虑”收了你的智商税,你的钱包和发际线都会感谢你的!🙏 💡 彩蛋(给还没死心的朋友): 👉 可以关注并私信我“OpenClaw”,或者直接加我好友(wangzhongyang1993,备注:OpenClaw)。 咱们一起“穷玩”AI,不当冤大头!👊理想很丰满,钱包很骨感
📉 第一笔账:硬成本 —— 服务器与Token的无底洞
⏳ 第二笔账:软成本 —— 你的周末都去哪了?
别为了“伪需求”买单
当然,如果你头铁非要挑战一下OpenClaw,或者单纯想研究它的源码架构(毕竟这玩意儿写得是真漂亮),但又怕自己踩坑踩到怀疑人生……
我最近在隔壁 V 站发现一个疑似 AI 逛论坛的账号,由于我没有 V 站账号,所以只能在这里发帖子讨论一下。
这个人最近每个热帖下面都会有他的回复,没次都是很长一段文字,排版也很舒服,虽然开口一股“AI 味儿”,但是呢,仔细看他的发言,又不是 AI 说的那种“车轱辘话”,所以我每次都认真看了。
其实我倾向于他是 AI,因为这个人以前发言不是这样的。但是我又觉得很奇怪,如果是 AI,那他这个模型还挺厉害的,非常像人类,发表的言论也是有意义的言论,不是那种在互联网到处拉屎的 AI。
是不是谁调教的 openclaw 啊。
没有恶意,单纯好奇,不知道这个老哥在不在这个论坛。此处 @JoeJoeJoe 哥,你在每个论坛都很活跃,不知道你有没有注意到这个人。
今年 1 月底的时候,我在微信群发过一个关于大宗商品超级周期的传导链条:
贵金属 -> 工业金属 -> 能源 -> 化工产品 -> 农产品
时间线来到今天( 3 月 11 日),短短一个多月,市场的走势令人心惊。从黄金的屡创新高,到铜铝的暴动,再到原油的坚挺,直到近期化工板块(石化、化肥等)的全面起势,这个传导链条已经验证到了第四步。
今天发这篇帖子,不是为了炫耀预测得有多准,而是想和各位 V 友们深度探讨一下:为什么一定会这样传导?这背后的底层逻辑到底是什么?以及,留给最后防线“农产品”的时间还有多少?
一、 贵金属起飞,全球信用体系的“警告”
这一切的起点,必须从黄金等贵金属说起。很多人以为黄金涨是因为避险,这只是表象。
1 、货币超发与信用重估: 过去几年全球央行的扩表,释放了天量流动性。当美元潮汐面临转向(降息预期),叠加美债高企,全球央行都在疯狂囤金。黄金的上涨,本质上是纸币购买力的贬值,是法币信用体系出现裂痕的体现。
2 、地缘重塑: 逆全球化导致“安全”的溢价急剧上升。
黄金作为最敏锐的“宏观温度计”,率先吹响了硬资产重估的号角。
二、 传导第一站:工业金属(金融属性与商品属性的共振)
当贵金属确立了上涨趋势,资金溢出效应和通胀预期自然会寻找下一个洼地——铜、铝、锌等工业金属。
逻辑: 铜被称为“铜博士”,具有极强的金融属性。在全球制造业 PMI 触底反弹的预期下,叠加新能源转型(电网、电动车对铜铝的巨大增量需求),供给端的长期资本开支不足导致了供需错配。
现象: 资金从纯金融属性的黄金,切入到了带有实体经济复苏预期的工业金属。
三、 传导第二站:能源(经济的血液与地缘的博弈)
工业机器一旦重新运转,或者通胀预期全面形成,对“工业血液”的需求就会被放大。
逻辑: 原油、天然气价格的上涨,除了 OPEC+的控产保价和地缘冲突(中东、俄乌)的扰动外,更深层次是因为上游资本开支的长期匮乏。在旧能源向新能源切换的漫长阵痛期,传统能源的供给弹性极小。
现象: 能源价格的高企,正式将“输入型通胀”推向全球。(这也是 1 月很多供应商涨价的原因,未来一年手机等电子产品都会涨价)
四、 传导第三站:化工产品(成本驱动下的被动抬升——目前正处于此阶段)
这就是我们当下正在经历的现实。3 月份以来,化工品价格开始异动。
逻辑: 石油和天然气是整个现代化工产业的基础原料(如烯烃、芳烃、合成氨等)。当能源价格居高不下,成本端的压力无可避免地向下游传导。
现象: 炼厂利润被压缩,不得不提价;同时叠加春季开工旺季,补库需求显现,成本推动型通胀在化工板块全面爆发。(能源也会影响化工板块的变动,首先就是石油涨价导致的化工板块大幅下跌,但只要石油恢复一定的价格,化工板块就会起飞,这点请关注霍尔木兹海峡什么时候开,这个不确定性很强,得有自己的准确信息渠道,因为以往霍尔木兹海峡封闭,伊朗直接放的水雷,现在没放水雷,说明开启时间不会太久)
五、 终局:农产品(通胀的最后一棒?)
这也是我最想和大家探讨的地方。按照链条,下一步必将是农产品(大豆、玉米、小麦等)。
传导路径: 化工产品涨价 -> 化肥(氮肥、磷肥、钾肥)农药成本飙升 -> 农业种植利润受挤压 -> 农产品价格必须上涨以覆盖成本。
催化剂: 极端天气(厄尔尼诺/拉尼娜)导致的主产区减产预期,以及地缘政治导致的粮食保护主义。
综上,这个传导链条的本质,是一场由“货币泛滥”引发,借由“地缘冲突”和“供应链重塑”发酵,最终表现为“实体资产对虚拟货币重新定价”的财富大转移。
从金融炒作(黄金),到工业复苏(金属),到成本推动(能源+化工),最终落到关乎生存的必需品(农业)。这是一场经典的“需求拉动 -> 成本推动”的通胀传导案例。
目前的节点,化工已经启动,农产品的暗线还在潜伏。各位 V 友如何看待接下来的演绎?大宗商品的这轮超级周期,会在哪里遇到真正的阻力(比如美联储的超预期动作,或是全球需求的彻底衰退)?欢迎各位 V 友进行讨论!
回收 13mini 128,最后加上补贴是 909+300.没想到战损成色居然没有压价,还以为会压到 800.
在编排自动化测试场景的时候,有一个问题其实很容易遇到。 不同的场景用例,往往会用到同一批测试数据。 比较常见的做法,就是把这份数据复制一份,然后粘贴到其他场景用例里,每个场景各维护一份。刚开始场景不多的时候,这种方式其实也没什么问题。 但随着自动化测试的场景越来越多,同一份测试数据就会被复制到很多地方。 一旦测试数据需要调整,就得逐个场景去修改。场景少还好,场景一多就很难保证每个地方都能同步更新,时间久了也很容易出现数据不一致的情况。 其实在不少项目里,自动化测试维护成本变高,往往就是从这里开始的。 针对这种情况,我们在 Apifox 的自动化测试里增加了一种新的数据管理方式,叫做「共用测试数据」。 通过共用测试数据,可以把原本分散在各个场景里的测试数据统一管理,多个场景用例都可以直接引用。 当测试数据需要调整时,只需要修改这一处地方,所有引用它的场景用例都会自动同步更新。 共用测试数据支持自动批量生成数据,只需要设置生成规则,就可以一次生成大量测试数据,不需要手动逐条录入。 如果已经有现成的数据,也可以直接导入,比如 CSV 或 JSON 文件。同时也支持从数据库读取数据,直接作为测试数据使用。 下面我们详细看看这个功能具体怎么用,在开始之前,请先将 Apifox 更新到最新版。 Apifox 支持两种方式创建「共用测试数据」,以适应不同的使用场景。 静态数据适用于那些内容相对固定的场景,比如一组固定的测试账号或地区编码。 进入 Apifox 项目,在左侧菜单栏中点击「自动化测试」,然后切换到「测试数据」标签页。点击该标签页上的 进入编辑界面后,可以手动添加数据列(变量),也可以直接导入 测试数据的「变量名」设置好后,可以根据规则批量生成数据,表格的每一列都会成为一个可在后续测试中引用的变量。 编辑完成后,点击保存即可完成静态共用测试数据的创建。 对于需要从真实数据库中获取数据的场景,比如从用户表中随机抽取一批测试用户进行测试,使用数据库连接的方式会更加高效。 同样在「测试数据」标签页,点击 如果项目尚未配置数据库连接,系统会引导你进行设置。选择一个已有的数据库连接,或创建一个新的连接。 配置好「数据库连接」后,你需要在 SQL 编辑区域中编写查询语句,用于从数据库中提取所需的测试数据。这里的 SQL 语句支持使用 Apifox 的环境变量。一个简单的 SQL 查询命令如下: 点击「保存」,Apifox 会执行该 SQL 语句,并将查询结果作为测试数据保存下来。 需要注意,通过这种方式获取的数据在保存后就变成了静态数据。它不会随着数据库内源数据的变化而自动更新。如果需要同步最新的数据,可以进入该测试数据的编辑页面,手动点击「刷新」按钮来重新获取。 数据创建完成后,就可以在自动化测试的「场景用例」中进行引用了。 打开或新建一个场景用例,在右侧的「运行配置」面板中,找到「测试数据」这一项。 点击下拉框,此时列表中会显示出所有已创建的「共用测试数据」,选择你需要的那个数据集。 引用成功后,这份数据集中的所有列名都会成为当前场景用例可用的变量。在用例的任何步骤中,比如接口请求的 URL、参数或请求体中,都可以通过 当运行此场景用例时,如果共用测试数据包含多行记录,Apifox 会为每一行数据都完整地执行一次测试流程,这也就是数据驱动测试的实现方式。 随着项目的推进,对共用测试数据的管理也变得重要起来。 在「测试数据」列表中,点击任意数据名称即可进入编辑界面。对于静态数据,你可以自由地增删改查数据行和数据列。 对于通过数据库连接创建的数据,其内容是只读的,不能直接编辑。但可以更改数据库连接配置,或者调整 SQL 查询语句,然后重新获取数据。 共用测试数据支持按环境配置,你可以为开发环境、测试环境、生产环境等分别维护不同的数据集。 当你在运行测试用例时切换环境,Apifox 会自动加载并使用对应环境下的数据集,无需手动更改。 到这里,「共用测试数据」这个功能的基本用法就介绍完了。 如果你的项目里已经有不少自动化测试场景,不妨试试把一些重复使用的数据整理成「共用测试数据」,整体维护起来会轻松不少。 如果在使用过程中遇到不太清楚的地方,也可以查看 Apifox 的 帮助文档,里面有更完整的功能说明和配置示例。有任何问题欢迎在 Apifox 用户群与我们交流沟通。 同时,Apifox 提供企业私有化部署版本,通过本地化部署、客制化服务,协助企业进一步提升研发团队效能。


创建共用测试数据
静态测试数据
...,选择「新建测试数据(静态)」。
CSV 或 JSON 格式的文件。

数据库连接测试数据
...,选择「新建测试数据(数据库连接)」。
SELECT id, name, email FROM pets LIMIT 0, 10;

在场景用例中使用共用测试数据

\{\{变量名\}\} 的语法来引用这些数据。

管理你的共用测试数据
编辑与维护
按环境配置数据

前言:一场对抗「西西弗斯式」无聊的折腾对于忙碌又被惯坏的现代人而言,坚持运动从来都不是一件容易的事。我们常用的解决方案往往依赖外部激励:要么是AppleWatch提供的数值化圆环,要么是Switch《 ...
对于忙碌又被惯坏的现代人而言,坚持运动从来都不是一件容易的事。
我们常用的解决方案往往依赖外部激励:要么是 Apple Watch 提供的数值化圆环,要么是 Switch《健身环大冒险》带来的游戏化反馈。这两种方案的本质,都是通过一种替代性的外部意义来掩盖运动本身的枯燥。但外部意义的新鲜感一旦消退,你就会因感到「西西弗斯推石头」般的乏味而迅速放弃。
于是,我把目光投向了动感单车。它本身不提供任何意义,但你可以一边骑车一边追剧、听播客,以此度过漫长的有氧时间。
这是我原本美好的设想。但现实未能如我所愿(毕竟,我都追剧了,干嘛不躺在舒服的沙发上?),这台 Keep C2 lite 单车同样难逃吃灰的命运。
很快啊,我熟练地打开闲鱼,写好文案,给出了一个童叟无欺的价格,静静等待下一个以为自己能够坚持的人上钩。
正当我在工位上摸鱼,下拉刷新闲鱼第 100 次的时候,灵感突然从天而降:我曾看过一个名为 GTBIKEV 的《GTA 5》MOD 项目(少数派上亦有人介绍过),它可以把骑行台转换成游戏里的控制器。那我的这台动感单车,能不能也变成一台游戏机外设呢?
我并没有先把兼容 GTABIKEV 项目作为目标,原因有二:一是我希望能玩所有游戏,尤其是《极限竞速:地平线 5》,我想用我的双脚在墨西哥的沙漠里真实地「踩」出推背感。而且只有能够用这套方案玩不同的游戏,才能避免前面说的新鲜感消退问题。
第二,按照我对国产智能健身设备的理解,它们极大概率不会采用开放协议,不太可能做到直接兼容(但这并不意味着兼容 GTABIKEV 是不可行的,我们只是需要写一个国产协议到开放协议的中间转换层)。
经过一番构思,我确定了最终的技术路线:用一块树莓派 Zero 2W 作为数据中枢,同时接收动感单车的踏频数据和实体手柄的按键数据。树莓派将自己伪装成一台通用的 USB 游戏手柄,然后通过有线方式将混合后的指令发送给电脑。
这样一来,电脑端完全不需要安装任何多余的驱动或虚拟软件,即插即用,兼容所有游戏。
具体涉及的硬件及成本如下表所示:
| 硬件名称 | 用途说明 | 预估花费 |
|---|---|---|
| 树莓派 Zero 2W | 核心数据处理与 USB 模拟 | 约 120 元 |
| 国产平替 Joy-Con | 提供实体按键与摇杆输入 | 约 70 元 |
| 绑带/魔术贴 | 将手柄固定在单车把手上 | 约 10 元 |
| 总计 | 将单车变废为宝 | 约 200 元 |
在墨西哥沙漠里挥洒汗水实际体验下来,效果远超预期。当我把单车的踏频线性映射到手柄的 RT(油门)扳机上后,你踩得越快,车速就越快(我把 100RPM 作为扳机键按到底所需的踏频)。延迟方面,也没感觉到可感的影响游戏体验的延迟。
更棒的是,《地平线 5》提供了极其丰富的辅助功能。你可以开启「自动刹车」并把 NPC 调到门外汉级别,自己只负责打方向盘和疯狂踩踏板。这种设置在「游戏可玩性」和「有氧专注度」之间达到了完美的平衡。
以前在单车上干熬 10 分钟就像受刑,现在跑完三场比赛,不知不觉半小时就过去了,大汗淋漓且意犹未尽。
第一步,也是最关键的一步,是让树莓派能「听懂」单车的话。
如果幸运的话,这款单车应该使用通用的 FTMS (Fitness Machine Service) 协议。这是蓝牙技术联盟基于BLE (蓝牙低功耗)设备使用的GATT协议为动感单车和相关健身器材定义的一套标准。
打个比方,GATT(蓝牙通用属性配置文件)规定了设备间对话的「语法」(主谓宾结构),而 FTMS 则规定了「词汇表」。比如大家约定俗成用「苹果」指代红色的果子。如果你想知道苹果多少钱一斤,你竖起耳朵听我说「苹果」这个词后面跟着什么东西就可以了。类似的,在FTMS 的通用规定里,只要监听特定的特征值(0x2AD2),就能直接拿到踏频数据。
横着更美观吧。
全文链接: https://tecdat.cn/?p=45189 在此对Dawei Zhou对本文所作的贡献表示诚挚感谢。Dawei Zhou在麦吉尔大学完成了计算机科学与统计专业的本科学位,专注金融科技与数理统计领域。擅长Python、R、SQL、C、Stata、Wind数据分析软件,专注于金融、数理统计领域。 专题:从零样本到微调:Lag-Llama基础模型在金融时序预测中的实战探索 我们频繁遇到一个核心挑战:如何在不具备充足历史数据或模型训练成本过高的情况下,依然能对高度不确定的市场(如金融、零售、能源)做出精准的预测。近期,人工智能领域的“基础模型”革命,从自然语言处理(如GPT系列)到计算机视觉(如SAM),展现出了强大的零样本与少样本学习能力,这为我们解决上述难题提供了全新的思路。然而,当我们将目光投向以噪声大、非平稳著称的金融时间序列时,这些“通才”模型是否依然能打?它们能否直接应用于股票收益率预测,并指导真实的交易决策? 带着这些疑问,我们团队在一个内部研发项目中,对专为时间序列预测设计的基础模型——Lag-Llama进行了深度测试。我们将Lag-Llama比喻为一个已经阅读过海量不同类型时间序列数据(如电力、交通、天气)的“实习生”,现在直接将其派往金融领域“上岗”(零样本预测),观察其表现。结果发现,这位“实习生”的初试成绩并不理想。随后,我们通过少量的金融数据对其进行“岗前培训”(微调),其预测能力和交易策略表现均得到了显著提升。 阅读原文获取完整代码数据及更多最新AI见解和行业洞察,可与900+行业人士交流成长;还提供人工答疑,拆解核心原理、代码逻辑与业务适配思路,帮大家既懂怎么做,也懂为什么这么做;遇代码运行问题,更能享24小时调试支持。 下图概括了本次从理论探索到实践验证的完整流程: 近年来,基础模型在机器学习的多个领域引发了革命,尤其是在自然语言处理和计算机视觉领域,它们展现出了强大的零样本和小样本泛化能力。然而,在时间序列预测,特别是金融数据预测领域,这些模型的应用仍面临巨大挑战。金融数据固有的高噪声和非平稳特性,使得任何预测模型的泛化能力都备受考验。 为了解决时间序列的泛化难题,研究人员提出了一种名为Lag-Llama的基础模型,专门用于单变量概率时间序列预测。Lag-Llama采用解码器仅含变换器的架构,其核心创新在于引入滞后值作为协变量,从而有效地捕捉时间序列数据中的时间依赖性。 如下图所示,Lag-Llama通过处理过去多个时间步的滞后特征,学习输出下一个时间步取值的概率分布。 模型的输入是单变量时间序列在特定时间步的标记值。为了增强预测能力,模型还会结合多种协变量,包括一组预定义的滞后值、日期时间特征以及序列的统计摘要。这些输入经过多层掩码解码器投影后,传递给分布头,从而预测下一个时间步的分布参数。 Lag-Llama的强大之处在于其稳健的预训练方法。它利用了一个跨多个领域的大规模时间序列语料库进行预训练,从而捕捉了丰富的、通用的时序模式,这使得它具备了强大的零样本泛化能力。 相关文章 原文链接:https://tecdat.cn/?p=44060 接下来,我们将通过实际案例,检验Lag-Llama在预测科技巨头股票收益率方面的表现。我们将从零样本预测开始,然后通过微调进行优化,并最终通过回测来评估其在真实交易中的价值。 阅读原文获取完整内容及更多AI见解、行业洞察,与900+行业人士交流成长。 首先,我们在云端计算平台进行环境配置与模型部署。 从上图可以看出,零样本预测下,模型对实际收益率的拟合程度较为一般。若将其转换为累积收益(即损益),偏差则更为明显。 阅读原文获取完整内容及更多AI见解、行业洞察,与900+行业人士交流成长。 为了评估模型的真实交易价值,我们采用滚动窗口方法进行回测。在每个季度初,根据模型对下一季度收益率的预测来调整投资组合权重。具体规则为:若某资产预测累积收益为正,则买入;若为负,则卖空。最终将所有头寸的绝对值之和缩放至1。回测过程中考虑了交易佣金和卖空费用。 零样本策略的回测结果令人失望: 虽然该策略在部分下跌趋势中避免了损失,但在整体上涨趋势中却录得亏损。 这表明,直接应用预训练的Lag-Llama进行零样本金融预测,效果并不理想。因此,我们尝试对其进行微调,以适应金融数据的特性。 微调后,预测结果与实际收益率的拟合度显著提升。 对应的累积收益预测也更为准确。 阅读原文获取完整内容及更多AI见解、行业洞察,与900+行业人士交流成长。 再次进行回测,策略表现焕然一新: 通过简单的微调,Lag-Llama模型在金融数据上的预测能力得到了大幅提升,其生成的交易策略也展现了更优的收益风险特征。 通过本次实战探索,我们得出以下结论:即使是专为时间序列设计的基础模型Lag-Llama,在金融预测这一高度复杂的任务上也难以通过零样本方式直接奏效。然而,通过少量的特定领域数据进行微调,模型的性能可以得到质的飞跃,其预测结果能够用于构建有效的交易策略。 当然,这仅仅是开始。未来的优化方向包括:更精细的超参数搜索、考虑波动率结构的分段建模、结合强化学习进行数据清洗和去噪、以及策略层面的优化和交叉验证等。这为我们打开了通往更智能、更鲁棒的量化交易系统的大门。
原文出处: 拓端数据部落公众号
关于分析师
数据获取 ────► 数据预处理 ────► 零样本预测 ────► 回测评估
│ │
└───────────── 发现效果不佳 ──────────────────┘
│
▼
┌─────────────┐
│ 模型微调迭代 │
└─────────────┘
│
▼
┌───────────────┴───────────────┐
▼ ▼
微调后预测 ────► 回测评估 ────► 对比分析,验证微调有效性1. 金融时序预测的新挑战与Lag-Llama模型的引入
Lag-Llama模型简介
DeepSeek、LangGraph和Python融合LSTM、RF、XGBoost、LR多模型预测NFLX股票涨跌|附完整代码数据
2. 零样本预测实战
# 定义一个函数,用于生成预测结果
def _obtain_forecasts(data, pred_len, n_samples=100):
# 加载预训练权重
checkpoint = torch.load("lag-llama.ckpt", map_location=torch.device("cuda:0"))
model_params = checkpoint["hyper_parameters"]["model_kwargs"]
# 初始化Lag-Llama估计器
estimator = LagLlamaEstimator(
ckpt_path="lag-llama.ckpt",
prediction_length=pred_len,
context_length=32, # 使用预训练时的上下文长度
input_size=model_params["input_size"],
n_layer=model_params["n_layer"],
n_embd_per_head=model_params["n_embd_per_head"],
n_head=model_params["n_head"],
scaling=model_params["scaling"],
time_feat=model_params["time_feat"],
batch_size=1,
num_parallel_samples=n_samples,
)
# ...... (此处省略了构建预测器、生成预测的完整代码,该部分涉及模型加载与预测流程的细节)
# 返回预测结果列表和实际时间序列列表
return forecasts, actual_series# 执行零样本预测
forecasts, actuals = _obtain_forecasts(backtest_data, forecast_horizon, sample_size)3. 回测验证与微调优化
# 配置微调参数
finetune_estimator = LagLlamaEstimator(
ckpt_path="lag-llama.ckpt",
prediction_length=forecast_horizon,
context_length=32,
nonnegative_pred_samples=True, # 确保预测样本非负(对于收益率预测不适用,此处仅为示例)
aug_prob=0, # 关闭数据增强
lr=5e-4, # 设置学习率
input_size=model_params["input_size"],
n_layer=model_params["n_layer"],
n_embd_per_head=model_params["n_embd_per_head"],
n_head=model_params["n_head"],
time_feat=model_params["time_feat"],
batch_size=64,
num_parallel_samples=sample_size,
trainer_kwargs={"max_epochs": 50}, # 训练50个周期
)
# ...... (此处省略了模型训练的完整代码,该部分涉及数据加载、训练循环等细节)# 对剩余数据进行预测
test_dataset = _prepare_dataset(return_df.iloc[252*5:])
forecasts_ft, actuals_ft = _obtain_forecasts_finetuned(test_dataset, forecast_horizon, sample_size, predictor=fine_tuned_predictor)4. 结论与展望
注:本文不构成任何投资建议。文中所提及的任何具体投资机会均仅作为教学材料。投资始终伴随金融风险,读者在做出任何投资决策前,应自行进行充分调研或咨询持牌财务顾问。
大语言模型推理与生成能力强,但在迈向自主智能体时暴露出“短时记忆”短板:大模型本质上是无状态的,即使上下文变长,交互也难以沉淀为长期认知。为此,PolarDB MySQL版推出 Mem0 托管服务,融合内核级向量库与图引擎,100% 兼容开源生态,并将记忆精炼与存储成本降低 30% 以上,帮助 Agent 持续学习进化,实现“千人千面”的智能化体验。 在 AI Agent 的进化路径上,感知(多模态)、思考(推理)和工具执行(Function Calling)逐步完善,但仍缺少“时间连续性”。Mem0(Memory Layer for AI)因此诞生,作为大模型的个人记忆层;PolarDB MySQL版 Mem0 则是其云原生托管版,将记忆的存储、抽取与检索一站式集成到瑶池数据库生态。 财务状态:近期预算有限。 PolarDB MySQL版Mem0 不仅仅是存储,它更像是在数据库里为每个用户建立了一个“数字分身”。以下是长期记忆在五大领域的应用场景: 智能推荐 过去,实现 AI 长效记忆需要开发者自己手动维护向量数据库、处理复杂的 Prompt 提取逻辑、还要担心数据一致性。PolarDB MySQL 版 Mem0 的出现,本质上是将“记忆”从一种复杂的开发任务,变成了数据库的一项“原生服务”。 PolarDB MySQL 版 Mem0 不只是存储对话原文,而是支持调用语义提取模型深度解构信息。系统自动识别实体(人/物/地)并进行语义压缩,剔除冗余信息,仅保留核心事实(Fact)。利用 PolarDB MySQL 版 融合引擎,将结构化事实与高维向量同步存储,实现存储效率与检索性能的平衡。 PolarDB MySQL 版 Mem0 的检索不只依赖单一的向量匹配,而是采用“向量+图+元数据”三路并行机制。语义检索精准定位概念;图引擎补齐逻辑短板(如从“辣”联想到“胃炎史”的关系推理);元数据过滤则在海量数据中实现基于 user_id 或时间维度的秒级筛选,确保召回既准又深。 模拟人类遗忘与更正机制。引入时序权重衰减函数,赋予新信息更高置信度。在写入(add)逻辑中自动触发冲突检测:若新旧信息矛盾(如“单身”变“已婚”),系统将执行增量更新或逻辑覆盖,确保 AI 记忆始终符合当前事实。 构建层级化元数据索引体系,原生支持 user_id、agent_id、run_id 三级隔离。这种精细化的物理与逻辑控制,确保了不同应用、不同用户间的记忆完全独立,为企业级 AI 应用提供严密的隐私保障。Agent ID对应智能体/应用级隔离,确保不同功能的 AI 逻辑独立;User ID对应用户级,保护个人隐私,实现个性化;Run ID对应会话/任务级,针对特定任务的短期上下文隔离。 PolarDB MySQL 版 Mem0 现已集成在阿里云 PolarDB for MySQL版体系中,接入简单: PolarDB MySQL 版 Mem0 托管服务的推出,为企业构建AI应用提供了新的数据基础设施选择。在大模型与 Agent 技术浪潮中,数据不再是冰冷的行列记录,而是赋予机器智慧的认知载体 。 延伸阅读:PolarDB 长期记忆 Mem0导语
01 AI Agent 缺失的核心能力:长期记忆
它不是简单存聊天记录,而是把“原始表达”抽取成“核心事实”。例如从“给女儿买粉色独角兽礼物,但最近手头紧”中提炼关键事实:
一个月后问“周末带孩子去哪玩”时,即可据此推荐更合适的低成本方案。这就是长期记忆:它让 Agent 拥有了“读懂人心”的连续性,成为通向通用人工智能(AGI)的重要一环。02 五大应用场景
Mem0通过存储用户设备型号、报修记录及沟通偏好,使Agent可直接询问类似这样的问题:“王先生,您上次的投影仪问题解决了吗?”连续性体验从“冰冷程序”升级为“专属助理”。
Mem0记录学生难以掌握的知识点、题目类型、题目正确率等信息,复习时优先推送三天前错题,实现动态教学,避免盲目刷题。
Mem0存储病史、过敏史及治疗方案,当患者咨询新症状时,关联半年前体检数据,提供时间纵深建议,并提醒药物冲突,实现全周期医疗服务。
Mem0存储情绪波动、纪念日及亲友关系等信息,当用户失落时,可主动提及类似如下话题:“记得你上次完成项目会开心很久,现在进展顺利吗?”实现共情式支持。
Mem0基于客户的长期兴趣,记录其兴趣演变及购买动机,构建动态兴趣图谱,适时主动推荐延续性商品,实现主动服务。03 核心优势:为什么是 PolarDB MySQL 版 Mem0?
PolarDB MySQL版 Mem0 托管服务 100% 兼容开源 Mem0 框架,开发者可以利用成熟的开源社区生态,无需修改现有 Agent 代码逻辑,通过简洁的 RESTful API 即可实现无缝迁移。
支持按记忆量收费(标准版)和按资源量收费(企业版)两种模式,标准版记忆成本是Mem0商业版的50%。另外,PolarDB MySQL 版 支持 Serverless 弹性伸缩,对于 AI Agent 这种典型的波峰波谷流量场景,能够帮助企业减少约 50% 的云资源成本支出 。
PolarDB MySQL 版 Mem0经过专业AI算法优化,相较于自建开源Mem0方案,在标准测试数据集上,正确率提升50%+,时延降低30%+。
原生集成向量、图、全文检索能力,支持复杂的实体关系推理。深度集成 Lakebase 湖库一体架构,实现冷热数据智能分层,热数据秒级响应,冷数据自动归档 OSS,解决多库堆叠的存储难题。04 架构解密:从对话到记忆的“奇妙旅行”

PolarDB MySQL 版 Mem0 长记忆架构PolarDB MySQL 版 Mem0 的工作原理并非简单的存储,而是一个“动态演进”的过程:05 开发者福利:三步开启长期记忆
步骤一:实例创建与白名单配置
在 PolarDB MySQL 版 Mem0购买页创建 Mem0 实例。需注意应用白名单与集群白名单相互独立,需单独配置 IP 白名单或安全组,以确保 ECS 或本地服务器具备访问权限。
步骤二:自定义提取策略
利用系统内置或自定义 Prompt 策略指导 LLM 提取记忆。支持会话摘要策略(保留对话整体背景)与语义记忆策略(提取离散事实,如医疗体征或金融偏好),适配不同业务场景。
步骤三:API 集成与调用流程,在AI Agent的代码中集成PolarDB MySQL 版 Mem0的API,实现 AI Agent 记忆存储。
PolarDB MySQL 版 Mem0 提供了遵循 RESTful 风格的 API 文档(可通过控制台端点访问)。通过标准的 RESTful API 将记忆能力无缝集成至 AI Agent 代码中:06 结语:从“对话”到“进化”,让 AI 实现长期的认知积累
通过深度集成开源 Mem0 的灵活性与 PolarDB MySQL 版 的极致性能,这一托管服务不仅解决了 AI Agent 的“健忘”难题,更通过降本增效、安全加固与场景深耕,为企业构建新一代智能应用提供了坚实的底座。随着PolarDB “AI Lakebase”架构的进一步成熟,数据库与大模型的协同将更加紧密 。对于每一位致力于打造极致用户体验的开发者而言,PolarDB MySQL 版 Mem0 都是实现“让 AI 记住一切”愿景的重要工具。
目前,PolarDB MySQL 版 Mem0 正在火热邀测中,欢迎前往阿里云官网提交工单申请体验,开启您的 Agent 进化之旅。
如您在使用PolarDB Mem0的过程中有任何问题,欢迎搜索钉钉群号“ 28000021116”加入PolarDB专家面对面群咨询。