包含关键字 typecho 的文章

整理 | 华卫

 

ChatGPT 无广告体验的日子要结束了。

 

经过数周的预热,刚刚,OpenAI 宣布,将正式开始在其 AI 平台测试广告,ChatGPT 用户可能很快就会在对话中看到广告。这些广告会以标注“赞助”的链接形式出现在 ChatGPT 回答底部,但 OpenAI 表示,广告不会影响 ChatGPT 给出的回答内容,在视觉上也会区分开来。

 

目前,广告仅对免费版 ChatGPT 用户以及每月 8 美元的低价订阅服务 Go 套餐用户展示,Plus、Pro、商业版、企业版和教育版用户不会看到任何广告。也就是说,想要避开广告的用户至少需要每月支付 20 美元订阅 Plus 套餐。OpenAI 提到,免费版用户要想退出广告,但代价是每日免费对话次数减少;Go 套餐用户无法选择退出广告。

 

一位接近 OpenAI 的消息人士表示,OpenAI 预计从长远来看,广告收入占比将低于其总收入的一半。目前,该公司还通过其聊天机器人集成的购物功能,从用户购买的商品中抽取分成。另据外媒报道,OpenAI 首席执行官 Sam Altman 告诉员工,ChatGPT“月增长率已恢复到 10%以上”,将于本周部署“更新后的聊天模型”。

 

ChatGPT 广告规则全曝光

此次广告功能推出前,Anthropic 在一则广告中暗讽了 ChatGPT 的广告模式。例如在其中一则广告里,一名年轻男子向人工智能求助练出六块腹肌,化身私人教练的 AI 先是为他提供指导,随后却开始推销一款虚构的增高鞋垫。之后,Anthropic 修改了广告标语,改为:“广告自有其时间与场合,但你和 AI 的对话不该是其中之一。”而这很快引发了 Altman 的不满,他称其“明显不诚实”,是在用“欺骗性广告去批评那些并不存在、理论上的欺骗性广告”,与他们实际的广告模式不符。

 

就在 OpenAI 最新一期的播客里,OpenAI 的广告负责人之一 Asad Awan 详细介绍了其 AI 产品中的广告制定决策。“一方面走‘清高路线’,不做广告,但同时限制使用额度、用能力较弱的模型;另一方面,拥抱广告模式。”

 

这场对话中,不少外界关注的核心问题都摆到了台面上,且给出了清晰的回答。

从用户角度看,为什么要做广告?为什么是现在?

“这回到了我们的使命,让 AGI 惠及全人类。”Awan 解释道,当一款消费级产品有超过 8 亿用户时,如何把最好的产品带给每个人?广告是经过验证的成熟模式,对于一家希望把最好的 AI 带给全人类的公司来说,这是很自然的选择。提供最好的模型、更高的使用限额,让广告对用户和企业都真正有用。

 

他表示,大家担心广告可能带来负面影响,所以 OpenAI 更看重广告的原则:为平台设立极高的标准,让广告真正有用。其确立了几条核心原则:

  • 第一,模型回答与广告完全独立,无论视觉上还是模型训练、系统逻辑上,确保回答始终可信,整个产品都建立在信任之上。

  • 第二,对话是隐私的。敏感对话绝不会出现广告,对话内容绝不会共享给广告主。我们会在内部匹配合适的广告,但广告主看不到用户对话。

  • 第三,透明与可控。用户能清楚理解数据如何使用,并且可以自主控制。

  • 第四,激励机制以用户价值为中心。我们不追求用户在平台上的停留时长,一个真正有用的广告就足够了。

 

“简单来说就是,用广告普及 AI,同时严防各种负面问题,从一开始就明确原则,持续测试、改进。”Awan 说道。

广告的出现频率是怎样的?

“最高原则是:有没有有用的广告可以展示。”Awan 称,核心原则是:是否有用、有帮助、对用户的操作有补充,能不能展示优质商品,内容质量要高、广告质量要高、相关性要高。“如果没有,我们宁可一条都不展示。实际上在测试阶段,你会看到广告非常少,因为我们态度很保守,也在学习该在什么位置插入。”

 

据介绍,模型看不到广告,也有防护措施。“狂轰滥炸广告对用户、对商家都没好处。我们不想让广告主乱花钱买曝光,也不想让用户看一堆广告,我们只想展示那条正确的广告。作为顶尖 AI 公司,这正是我们能做好的事。”

当公司有专门的广告收入部门时,还会把模型和广告之间这堵墙砌死吗?

“只要目标和激励机制是成为最值得信任的 AI,我们就不会走偏。”

 

Awan 强调,“我们的核心业务是信任。对 C 端用户,是提供可信的优质回答;对企业客户,信任更是一切,你把最重要的数据交给我们,我们必须守住。如果我们真的想成为你最贴身的智能助手,就必须让你放心分享最重要的信息,并且知道它会被妥善对待。我们的商业模式就是 信任,这和很多只做一次性查询、内容推荐的产品完全不同。对我们而言,信任不是可选项,而是必需品。我们希望被用户记住的,就是‘可信’。

如何回应拿广告这件事开玩笑的竞争对手?

“不同公司使命不同。”Awan 表示,OpenAI 的业务场景更多元:企业业务、订阅业务、海量免费用户业务。企业版没有广告,订阅版没有广告,广告是为了支撑免费用户业务。“如果你的使命不是普惠 AI,那不做广告很合理;但我们的使命就是在各类场景里落地,让所有人用上最好的 AI。”

 

他强调,如果只服务付费用户,当然可以说 “我们不用做广告”。但 OpenAI 的愿景不是抽象的,而是非常实在:AI 如何真正帮助普通人。“如果走精英路线,只有付得起钱的人才能用 AI,那从价值观上我们就不认同。我们的立场非常明确:每个人都应该用上最好的 AI。而且我们不是一家纯广告公司,纯广告公司的激励机制和我们完全不同。”

十年后的广告会变成什么样?

据 Awan 透露,下一步会是更真实的对话式广告,能真正了解产品是什么。再往后,AI 可以在后台自动聚合最优折扣、最划算的商品、最合适的版本。一边是用户主动搜索,一边是商家希望被合适的人发现,两边匹配起来。

 

“未来会更加智能体化。我们先从现有形式开始,把体验做好,让它更相关、可控、可理解、可信。随着主产品和系统进化,广告形态也会一起进化。”Awan 表示。

第一批投放广告的公司露面了

ChatGPT 推出广告之际,正值人工智能行业竞争压力不断加剧,且外界对大型 AI 平台的可持续盈利模式抱有更高期待。OpenAI 表示,“ChatGPT 被数亿人用于学习、工作和日常决策。为了确保免费版和 Go 版的快速稳定运行,我们需要投入大量基础设施和持续资金。广告收入有助于资助这些工作,从而通过更高质量的免费和低成本选项,让更多人能够使用人工智能,并使我们能够不断提升所提供的智能和功能。”

 

同时,该公司称,广告商只会获得汇总的广告浏览量和点击量数据,不会获取用户的 ChatGPT 对话个性化数据或内容。免费版和 Go 版用户都可以对广告反馈、关闭广告个性化设置、关闭基于历史对话的广告推荐,从而限制赞助内容的推送方式并删除广告相关数据。此外,OpenAI 现在并非对所有用户和对话都会投放广告,比如 18 岁以下用户以及涉及健康、心理健康、政治等特定敏感话题的对话场景。即便免费版与 Go 版的成年用户,也未必会立即看到广告,因为该功能仍处于测试阶段。

 

尽管此举在 ChatGPT 用户和行业观察人士中引发了褒贬不一的反应,但 OpenAI 坚称,投放广告是为了补贴免费及低价服务的使用成本。该公司强调,“此次测试的重点是学习。我们会密切关注反馈,以确保广告在推广之前能够实用且自然地融入 ChatGPT 体验。”早期用户的反馈将有助于改进广告,并可能在未来扩大广告投放范围。OpenAI 表示,将利用此次试点项目的洞察,更好地平衡盈利与用户体验。

 

当前,已有多家公司也透露了他们将如何投放 ChatGPT 广告。Adobe 表示,将率先投放 Acrobat Studio 和 Firefly 相关广告作为初期试点。已经与 ChatGPT 完成集成的 Target,则会在用户提出诸如“有哪些台面式厨电能让日常做饭更方便?”这类问题时展示广告。

 

而随着测试的推进,OpenAI 的做法很可能会影响其他人工智能公司对盈利模式的思考,以及广告在对话式 AI 工具中的角色。不过,开发 Claude AI 助手的 Anthropic 已 “承诺” 永远不会加入广告,甚至还在投放了的一系列超级碗广告里宣传这一决定。据报道, OpenAI 的竞争对手谷歌也曾暗示,其 Gemini AI 平台可能会在 2026 年投放广告,不过谷歌 DeepMind 首席执行官 Demis Hassabis 在 1 月底表示,Gemini “没有计划”投放广告。目前,谷歌已在搜索结果旁边的 AI 概览中投放广告。

 

在未来某一天,或许所有免费的 AI 应用和服务都会出现广告,但至少目前,ChatGPT 是唯一一家率先推出广告的大型应用和服务商。微软 Copilot 之前的版本(当时名为 Bing Chat)也曾出现过广告,但目前的版本似乎已经取消了。

 

参考链接:

https://openai.com/index/testing-ads-in-chatgpt/

https://www.cnbc.com/2026/02/09/sam-altman-touts-chatgpt-growth-as-openai-nears-100-billion-funding.html

https://www.youtube.com/watch?v=2agJo3Jf_O4

作者:鸢玮

大模型的出现,给许多行业带来了颠覆性的改变,运维这个向来被视为稳定、保守的领域也不例外。虽然“AIOps”这个概念早在 2016 年由 Gartner 提出,但早期的智能运维更多是利用大数据和机器学习对传统运维流程进行效率上的提升。十年后的今天,大模型的强大能力,正推动着 AIOps 从辅助工具,演进为数智化转型中不可或缺的核心基础设施,让运维真正迈入智能化的深水区。

阿里云云原生应用平台事业部总经理、资深技术专家周琦作为这一变革的深度参与者,对 AIOps 的本质有着深刻洞察。“AIOps 这个词已经被广泛使用,但我更倾向于用 Operation Intelligence 来定义它。”周琦在采访中强调,“它的核心是发现与沉淀运维操作中的智慧,让工程师从重复繁琐的劳动中解放出来,聚焦于更高价值的创造。”

十年演进,重塑 AIOps 底层逻辑

在传统的运维时代,更多依赖人工被动处理故障,效率低下;而后进入到自动化运维时代,借助工具实现任务自动化,缩短了故障恢复时间;到了小模型运维时代,通过机器学习实现异常检测与根因分析,运维也初步具备智能化特征;如今进入到大模型时代,运维才真正开始走向真正的智能化。

回顾 AIOps 过去十年的发展,周琦认为有两个关键转折点重塑了其底层逻辑。第一个转折点是通用大模型的到来。 在此之前,所谓的智能运维更多是通过垂类 AI 模型来解决告警治理、异常检测等单一、点状的问题。这种方式虽然有用,但难以规模化。大模型的通用特性,像是一个巨大的杠杆,将 AIOps 的能力从“点状解决”扩展到“面状全域覆盖”,凭借其强大的泛化能力可以应对千变万化的碎片化运维任务。

第二个转折点则在于数据整合技术的突破。 过去,运维工作呈现高度碎片化特征,数据和引擎往往由不同供应商提供,形成了天然的数据孤岛。周琦表示,想要建设统一的 AIOps 体系,首先就要跨过这道鸿沟。如今,存储、计算与分析技术的进步,实现了异构数据的关联与串联,将分散在各个系统中的数据整合在一起,为全域智能运维奠定了坚实基础。

技术的演进也推动了企业对 AIOps 认知的转变。周琦观察到,早期,企业引入 AIOps 的核心诉求只是保障系统的稳定性,关注的焦点集中在故障修复、告警处理等基础功能方面。但现在,企业的需求维度大大拓宽了,安全性、可扩展性、延时、用户体验等这些过去容易被忽略的“隐性成本”,正受到前所未有的关注。这种认知的升级带来需求的延伸,AIOps 不再仅是运维工程师的工具,还需要满足企业管理者对系统成熟度、跨模块依赖关系等深层因素的考量,真正覆盖多角色、多维度的运营需求。真正的 AIOps,不是让人去适应工具,而是让工具主动理解人、服务人、成就人。

能力跃迁,让系统“能感知、会思考、可行动”

大模型时代的到来,让 AIOps 具备了前所未有的智能化能力。那么,大模型究竟为运维领域带来了哪些质变?周琦用一个生动的比喻来解释,给 AI 装上“摄像头”。传统运维在很大程度上依赖于工程师的个体经验,一位经验丰富的老师傅心中通常有一张无形的系统拓扑图,知道哪里容易出问题、该如何分析。但这种宝贵的经验附着于个体,难以沉淀、复制和规模化。大模型的出现,结合阿里云构建的实时数据采集与分析引擎,相当于为 AI 赋予了感知能力,使其能够真正能“看懂”系统、“理解”故障、“思考”方案。

这带来了运维能力的根本性跃迁。机器不再是机械地匹配预设规则、触发阈值告警,而是开始能够“读懂”告警信息背后的语义,“理解”系统当前真实的运行状态,甚至能“归纳”历史故障的复杂模式,并主动生成可供执行的修复建议。为此,阿里云提出 Operation Intelligence 理念,把人的经验变成系统的智慧,把个体的直觉转化为组织的资产,让系统具备“类人决策”能力,周琦将阿里云践行的 Operation Intelligence 理念概括为三个层面的能力进化。

  • 在感知层面,目标是突破传统监控中常见的“数据孤岛”,构建从终端设备到业务流程的全链路感知网络。
  • 在认知层面,关键在于融合大模型的通用理解能力与专用领域算法,将海量、原始的观测数据转化为可解释、可推理的系统关系图谱。
  • 最终,在行动层面,通过模型与算法的协同驱动,实现自动化的处置闭环,推动运维从“人工救火”向“系统自愈”转变,通过高效的人机协同大幅提升整体运营效能。

当然,大模型并非万能,针对大模型“幻觉”问题,阿里云设计了一套双重保障机制。周琦介绍说,在技术层面,通过强化多源数据的交叉验证,将数据采集、清洗、预处理等基础但繁重的工作交由传统工具完成,让大模型聚焦在最核心的推理环节,从源头减少幻觉产生的可能性。在应用层面,系统支持企业外挂自身的私有知识库,利用行业或企业特有的领域知识来补充和修正通用大模型可能存在的认知盲区,确保建议的准确性与合规性。

构建智能运维新范式,解放人力聚焦高价值

理想与现实之间总是存在挑战。周琦坦言,阿里云在自身的大规模实践中深刻体会到两大核心难题。其一是数据层面的挑战,包括异构系统形成的数据孤岛、数据洪流带来的存储与算力压力。其二是认知层面的挑战,不同团队、不同系统之间存在的“语义鸿沟”,以及对系统拓扑、故障根因逻辑链的理解不一致问题。

为了系统性地解决这些问题,阿里云将内部的实践经验产品化,形成了一套帮助企业在大模型时代构建智能运维新范式,并且在可观测产品中落地。

这套架构分为三层,底层是以日志服务 SLS 为核心引擎构建的统一可观测数据平台,实现日志、指标、链路、事件等多类型数据的统一接入与存储。该引擎具备 EB 级存储规模和秒级千亿行查询能力,能轻松应对每天数百 PB 数据,在保障数据完整性的同时,综合成本较自建方案降低 50% 以上。更重要的是,它支持全栈、实时、无侵入的数据接入,覆盖从移动端到基础设施的 200 多种组件,让企业无需重构现有系统即可完成数据整合。

image

中层通过 UModel 统一模型构建 IT 系统的 “数字孪生”,这是阿里云可观测性产品的核心建模框架。UModel 基于本体论,提供了一套观测实体及实体关系的定义,覆盖从用户体验、应用服务、容器到底层基础设施的每一层表征。UModel 就像给整个 IT 系统建立一套通用语言词典,让应用、容器、网络等不同组件能用同一套语义对话,彻底告别“你说你的指标,我说我的日志”的沟通困境。周琦表示,这套标准化建模彻底消除了语义歧义,让不同部门、不同系统之间的协作更高效,也让运维人员的经验得以沉淀为可复用的组织资产,而非随人员流动流失。

image

上层则是以 AI Agent 为智能核心,实现“工具适应人”的新范式。Agent 采用自然语言交互方式,支持全场景上下文感知,用户可在任意界面随时召唤,直接通过自然语言提问,无需掌握复杂的查询指令。AIOps Agent 基于阿里云可观测平台的多源数据采集、存储、分析能力,采用“统一数据平台 + UModel + 传统算法 + 生成式 AI”的混合处理架构,能够自主规划、调用工具、执行分析并反思优化,可以提供从自然语言交互到自动化巡检的全流程运维辅助能力,解决各类开放和未知的运维难题,将运维人员从重复的查询、分析工作中解放出来。

image

周琦形象地说, “希望运维未来可以高度自动化,让 AIOps 把那些又脏又累的活儿做了。”这意味着,企业客户无需再投入大量宝贵的人力资源去完成数据采集、清洗、对齐等基础且繁琐的工程工作,阿里云的平台已经将这些“隐形工程”承担下来。

如今,阿里云 AIOps Agent 已在 6000 多家企业落地,帮助大型企业客户实现故障 MTTR 从小时级降至小于 15 分钟。

对于企业而言,部署 AIOps 的终极价值远不止于减轻运维团队的负担,而是它能释放出宝贵的研发与创新资源,让技术人才能够专注于业务价值创造。同时,它也能帮助企业系统性地管理那些以往容易被忽视的隐性成本与合规风险,从长远角度优化 IT 投资的整体回报。

开源引领生态共建,推动“技术平权”愿景

阿里云深知,“语义基座”的价值在于普及,而开源与生态建设是实现“技术平权”的关键,更能让全行业运维人员共同成长。为此,阿里云在开源布局、标准建设和生态协同上持续发力,推动 AIOps 行业整体进步。

在开源布局方面,阿里云计划将 UModel 统一语义语言开源至社区,并向 OpenTelemetry 社区贡献了探针、采集器等核心工具。这些工具已被滴滴等公司开发人员广泛采用,大幅降低了行业重复开发成本。其中,无侵入探针的代码已开源在 GitHub 上,经过众多企业实战验证,在安全性和稳定性上备受认可,让中小企业无需自行研发即可获得高质量的数据采集能力。

在标准建设方面,阿里云正在构建 AIOps 成熟度 Benchmark 榜单,构建了从数据分析到复杂异常检测的分级标准,涵盖基础任务处理、异常发现、根因分析、隐形问题挖掘、自主修复等不同阶段,让企业能够清晰评估自身能力水平,找到明确的进阶路径。周琦表示,希望可以和业界一起共创,攻克智能运维领域的难题,推动 AIOps 标准落地,促进整个可观测性领域的快速发展。

在生态协同方面,阿里云通过大赛联动高校、企业,将工业界高频问题转化为赛题,促进产学研深度融合。通过大赛的方式,阿里云将标准 Benchmark 和真实场景赛题提供给参赛者,让高校学生、企业开发者都能在实战中提升能力,同时为行业贡献创新方案。

周琦表示,阿里云通过开放共建的模式,打破技术壁垒,让不同规模、不同行业的企业都可以落地 AIOps,实现“技术平权”,让中小企业也能调用顶级“隐形工程师团队”,让每个运维人员都能借助智能工具发挥更大价值,向“智能运营专家”演进。

未来趋势:自主 Agent 协同,运维能力重构

展望未来,周琦从不同时间维度来做出判断。短期来看,低风险任务将实现全自动化闭环,如 IP 封禁、简单扩容等操作可由 AI 自主完成,而重要操作仍保留人机协同决策模式,确保系统安全。同时,多角色 Agent 协同雏形将逐步显现,运维、安全、成本控制等不同领域的 Agent 将共享统一数据视图,提升跨域运营效率。

中长期来看,AIOps 将与 AI Coding、测试等环节深度打通,最终形成开发、测试到运维的全生命周期智能闭环。周琦解释道,AI Coding 目前在开发态做的非常有效,但从一个演示应用到企业级系统,部署后能稳定运行,还需要很长时间。“我们希望能够将 AI Coding 和 AIOps 串联,实现全局优化。让应用系统不光能跑起来,还能跑得更好、更稳,把运行态的状况实时反馈给 AI Coding。”

技术的演进必然带来运维人员角色与能力的重构。周琦表示,过去,运维人员是“救火队员”,整天忙于处理各类故障;未来,他们将转变为“系统教练”,而他们的核心能力不再是重复的操作经验,而是架构设计、业务理解、多维度决策等高阶能力。未来的运维人员需要平衡安全、成本、合规、可扩展性等多重诉求,专注于系统长期价值的优化。

结语

在阿里云可观测团队的定义中,智能运维是一场深刻的范式转移。它以大模型为驱动,基于统一的数据平台与领域知识模型,实现了从“人适应工具”到“将人类创造力注入系统智能之中”的本质转变,最终构建起数据、认知与行动闭环融合的智能体系。

纵观这场由 Operation Intelligence 引领的变革,其核心在于将运维智慧从依赖个人的隐性经验,沉淀为可复制、可迭代的组织数字资产,推动工程师从重复劳作中解放,实现价值的创造性升维。

阿里云始终致力于通过自身实践与生态共建,让任何规模的企业都能获得顶级“隐形工程师”团队的支持,在数智化浪潮中聚焦核心创造,实现个人与企业的共同成长。

正如周琦所言,“未来的运维竞争,将不再是工具的竞争,而是人的创造力与战略眼光的竞争”。当统一语言打通系统与智能的鸿沟,技术真正服务于人的价值释放,这场变革便不止于运维效率的提升,更将成为企业创新加速、行业持续进步的核心动力。

本文为墨天轮社区整理的2026年1月国产数据库大事件和重要产品发布消息。

IDC报告显示:2025上半年,OceanBase 以2810万美元营收稳居中国分布式事务数据库本地部署市场第一。国家开发银行近2822万采购南大通用Gbase 8a;浙商银行近930万采购GoldenDB。墨天轮发布“2025年度数据库”获奖名单"。2026 阿里云PolarDB开发者大会召开,发布PolarDBAI数据湖库等能力;PingCAP发布平凯数据库全新"一核三态"架构+2.0 内核……

<font color=4169E1 size=4>1月国产数据库大事记 TOP10</font>

image.png{{{width="auto" height="auto"}}}

达梦数据库上线联通超大规模ERP,守稳年终决算大考

1月2日,基于达梦数据库的联通数科大型国产ERP系统——"联通同舟ERP"成功完成中国联通集团总部及31家省级分公司的年度财务结账工作。此次结账覆盖300余家核算主体,支撑中国联通上万名用户高效作业,日均处置10余万笔凭证、年末数千万+资产集中折旧等高强度任务。随着该项目的成功落地,达梦数据助力中国联通在企业关键系统自主安全道路上取得阶段性重大突破。

目前,在达梦数据库的支撑下,中国联通全栈国产化"同舟ERP"已经覆盖了中国联通集团和31省分公司100%的业务场景,平稳承接接近20年全量历史数据资产,在年度结账、海量业务处理等关键考验中实现稳定运行。

能源首例!金仓助力中煤生产运营智控平台裸金属多租户数据库国产化落地

1月3日消息,近日,中国中煤能源集团有限公司(简称“中煤”)在金仓企业级统一智控平台KEMCC的支撑下,成功上线了生产运营管控体系,涉及智控平台及其支撑的50+生产运营系统,成为能源行业首例裸金属多数据库实例多租户部署的国产化替换项目,拉通中煤的煤炭、电力、化工、销售等业务链条,为“煤与煤电”“煤电与新能源”联营提供数据支撑。

image.png{{{width="auto" height="auto"}}}

海量数据、达梦数据、万里数据库获评信创世界 “最佳信创数据库厂商”

1月5日,“2025 XCWA信创世界年终大奖”正式揭晓,本届评选被誉为信创产业"奥斯卡",吸引上百家企业逾200份申报材料,经30位权威专家评审产生最终名单。在数据库领域海量数据、达梦数据库、万里数据库获评"最佳信创数据库厂商",YMatrix超融合数据库、OceanBase获评"年度最佳信创分布式数据库厂商"。

万里数据库与山石网科达成战略合作

1月5日消息,近日,万里数据库与山石网科正式签署战略合作协议。双方将基于各自在数据库与网络安全领域的技术积累与市场优势,围绕数据库安全测试、安全能力共建、解决方案融合、市场协同等多个维度展开深度合作,携手打造更安全、更可靠的信创数据基础设施,助力我国信创产业实现高质量发展。

Apache Doris 官网 Ask AI 智能问答已上线

1月6日消息,Apache Doris 官网现已正式推出 Ask AI 功能。您可以直接输入问题,它将基于官方文档快速定位答案,并关联相关的内容片段,为您提供贴合场景的说明。此外,所有回答均附有准确的文档链接,方便您随时查阅与验证,可称之为学习和使用 Doris 的得力助手。

image.png{{{width="auto" height="auto"}}}

IDC报告:OceanBase蝉联中国分布式数据库本地部署市场第一

1月7日消息,近日,全球权威机构 IDC 发布的《IDC中国分布式事务数据库市场追踪,2025H1》报告显示,2025 上半年,OceanBase 以 2810 万美元营收,稳居中国分布式事务数据库本地部署市场第一。这是继 2024 年下半年后,OceanBase 连续两次在该细分市场拔得头筹。同时,在包含公有云的整体市场中,OceanBase 以 4060 万美元营收位列独立厂商第一、整体第四,持续领跑国产数据库阵营。

image.png

IDC 统计,2025 上半年,中国分布式事务数据库市场规模达 4.2 亿美元,同比增长 19.6%。其中,本地部署市场增速高达 24.9%,显著高于公有云部署模式,预计 2024-2029 年复合增长率将达 24.2%。分布式数据库正加速向金融、政务等核心系统渗透,在性能、稳定性与综合成本上比肩甚至超越国际产品。IDC 同时认为,当前市场集中度持续提升,前五大厂商已占据 82.5% 的市场份额。

墨天轮发布“2025年度数据库”获奖名单

1月7日消息,墨天轮社区发布“2025年度数据库”获奖名单,OceanBase、阿里云PolarDB、达梦数据库荣获"最具影响力数据库奖",其中OceanBase连续蝉联金融行业本地部署市场第一并发布AI原生数据库seekdb,PolarDB以TPC-C测试20.55亿tpmC性能及0.8元/tpmC性价比刷新世界纪录,达梦数据库在国产替代领域持续领跑;GoldenDB、腾讯云TDSQL、华为云GaussDB获"卓越表现数据库奖",展现金融级分布式数据库的成熟商用能力;YashanDB、移动云He3DB获"最具潜力数据库奖",代表国产数据库技术创新新势力。

image.png{{{width="auto" height="auto"}}}

国产芯 × 数据库,TimechoDB全球性能夺冠

1月8日消息,近日,天谋科技基于 Apache IoTDB 开发的时序数据库 TimechoDB 与海光 C86 国产芯片、KeyarchOS 操作系统组合,在国际权威 TPCx-IoT 物联网数据处理性能基准测试中以 2465 万 IoTps 的速率夺冠,创下世界纪录。此次“国产 CPU+数据库”性能登顶,既彰显了国产算力在物联网时序数据处理领域从跟跑到领跑的历史性跨越,也呈现出 C86 与 TimechoDB 实现生态协同的创新成果。

image.png{{{width="auto" height="auto"}}}

TPCx-IoT 基准测试是全球公认的物联网数据处理能力权威标准,该测试主要模拟真实场景下大规模设备数据的采集、存储、查询与分析,对于算力性能和上层应用适配性要求严苛,其测试结果也被视为全球科技企业与行业用户的重要选型依据。

达梦数据入选“2025上市公司高质量发展优秀实践范例”

1月8日消息,近期,由《大众证券报》主办的2025上市公司高质量发展优秀实践案例评选结果揭晓,武汉达梦数据库股份有限公司获评2025上市公司高质量发展优秀案例实践典范·创新发展优秀案例及投资者关系优秀典范双奖。

image.png{{{width="auto" height="auto"}}}

国家开发银行2821.69万采购380个节点Gbase 8a MPP数据库+1年维保

1月9日,国家开发银行发布《国家开发银行 一表通暨大数据服务平台建设项目(Gbase8a MPP数据库产品采购)结果公告》,由北京宇信科技集团股份有限公司中标,中标价2821.69万元。本项目需采购380个节点的Gbase 8a信创版本MPP数据库。供应商需具备Gbase 8a MPP数据库产品原厂授权资质,提供原厂服务完成各环境安装部署调试并配合提供开发支持,在系统全部上线后提供一年的原厂维保服务。

金篆数据库GoldenDB助力广发证券科技柜台核心系统上线

1月9日消息,近日,金篆数据库GoldenDB助力广发证券新一代经纪业务运营平台(以下统称为“NBOP”系统)完成全栈自主可控。NBOP系统是支撑全经纪业务运营的核心平台,服务全经纪业务条线超6000名业务人员的日常操作、超2000万名经纪客户的高频业务需求。新系统支持5000TPS下系统的平滑运行,整体性能较替换前显著提升!

OceanBase DataPilot 获 Hugging Face DABstep 最高分!

1月11日消息,OceanBase DataPilot 在被誉为“数据智能时代新基准”的 HuggingFace DABstep 基准测试 Hard 级别中获得全球最高分,并已连续 1 个月大幅领先第二名,位居全球第一。该⼯具旨在评估最先进的语⾔模型和 AI 代理在多步骤推理中的能⼒,特别是在数据分析领域的表现。

DABstep 全球实时榜单:https://huggingface.co/spaces/adyen/DABstep

《向量数据库管理系统技术要求》团体标准正式发布

1月13日,中国电子工业标准化技术协会正式发布T/CESA 1485-2026《向量数据库管理系统技术要求》团体标准,该标准将于2026年2月13日正式实施。该标准填补了向量数据库在向量数据类型、向量检索、向量数据查询和向量存储管理等方面的标准空白,为行业产品研发、评估选型与生态建设提供了关键依据。

image.png{{{width="auto" height="auto"}}}

该标准由全国信标委数据库标准工作组(SAC/TC28/WG31)组织,星环信息科技(上海)股份有限公司、清华四川能源互联网研究院等单位参与制定。该标准界定了向量数据库管理系统的技术参考结构,规定了向量数据库管理系统的功能要求、存储管理、接口要求、系统管理和性能要求。适用于向量数据库管理系统的设计、开发、选型与检测。

YashanDB 2026城市行落地成都,与云和恩墨共推国产数据库一体机创新实践方案

1月13日,由深圳计算科学研究院、崖山科技主办的“2026 YashanDB数据库城市行”新年首站在成都举办。现场,YashanDB与云和恩墨联合发布了“zData X for YashanDB数据库一体机解决方案”,该全栈信创方案以卓越性能与简化运维,为关键业务提供了高性价比承载选择。此外,YashanDB与海光信息、佰思杰等伙伴的联合解决方案也一同发布,展现了其在多元技术生态中的融合能力。同时,YashanDB为西南地区一批新晋生态伙伴举行了授牌仪式。

image.png{{{width="auto" height="auto"}}}

zData X for YashanDB数据库一体机解决方案"基于云和恩墨自研的数据库运行基础平台zData X,深度适配YashanDB V23版本,实现了从服务器、操作系统、数据库到管理平台软件的全栈信创兼容,涵盖海光、鲲鹏等国产芯片,麒麟、统信、openEuler等国产操作系统,构建了自主可控的技术底座。

image.png{{{width="auto" height="auto"}}}
全栈信创的zData X for YashanDB一体机方案

近930万!浙商银行GoldenDB数据库大单揭晓,索远电子脱颖而出

1月14日消息,浙商银行发布《关于浙商银行2025年GoldenDB数据库软件授权与驻场服务采购的成交结果公告》,第一成交候选人为江苏索远电子科技有限公司,中标金额为9,288,596.40元。采购内容为GoldenDB数据库软件永久授权(除许可数量外,无其他限制,含一年原厂维保服务)。

连获工信部赛迪认可!OceanBase 再入选“中国高质量软件及服务先锋榜”

1月14日消息,近日,工信部赛迪顾问发布的《品质革命:2025中国高质量软件及服务系列研究》报告中,OceanBase 荣登“2025 中国高质量软件及服务先锋榜”,成为唯一上榜的国产分布式数据库厂商;同时,中国航信基于OceanBase打造的民航领域首批全栈国产离港系统也作为标杆案例入选报告,标志着OceanBase在金融、民航等关键领域的国产化替代能力获得权威认可。

image.png{{{width="auto" height="auto"}}}

赛迪顾问于2025年11月发布的《央国企软件应用市场研究报告》指出,从 2024 年的市场格局来看,央国企数据库市场各厂商不断突破发展,格局逐渐清晰。其中,海扬数据库 OceanBase 在发展能力和市场地位层面位列数据库市场本土厂商第一。

image.png{{{width="auto" height="auto"}}}

2 家金融核心搭载 OceanBase 及一体机斩获“鼎信杯”大奖

1月14日消息,中邮证券和金谷国际信托联合OceanBase申报的两个项目在第四届"鼎信杯"大赛金融赛道中双双斩获"金鼎实践奖":中邮证券通过部署OceanBase数据库一体机(ODM)构建"三域一体"融合集群,实现TB级数据1小时极速切换、10:1数据压缩比及全栈极简运维;金谷信托则基于OceanBase分布式架构打造新一代核心业务平台,实现事务处理效率提升30%、每秒1000+笔高并发处理能力及99.99%核心服务可用性。

截至目前,OceanBase已服务全部政策性银行、5/6国有大行及超100家千亿级银行,支撑190余个核心系统,连续两年位居金融行业本地部署市场第一。

第八届金猿奖-2025中国大数据产业「年度国产化优秀代表厂商」榜单/奖项发布

1月14日,第八届金猿大数据产业发展论坛在上海举行,会上首次公布了“2025中国大数据产业年度国产化优秀代表厂商”榜单,宝兰德、传神语联、东方通、电科金仓、海量数据、极限科技、浪潮KaiwuDB、四维纵横、天谋科技、腾讯云、易捷行云、智臾科技(DolphinDB)、曙光存储等13家企业上榜,涵盖中间件、数据库、云计算、存储、AI大模型等基础软件领域,全面展现了国产软硬件在核心技术突破、全栈自主创新及关键行业替代中的最新成果。

image.png{{{width="auto" height="auto"}}}

  • DolphinDB荣获2025中国大数据产业年度「AI Infra领先企业」和「国产化优秀代表厂商」两项大奖,这些奖项不仅肯定了 DolphinDB 在 AI 基础设施建设中的技术领先性,也彰显了其在国产化替代与行业落地实践中的独特价值。

Milvus 2.6云上GA:三层存储降本85% 、速度快ES 4-7 倍

1月15日消息,Milvus 2.6.x正式在Zilliz Cloud云上GA,通过三层分层存储架构(内存+本地SSD+对象存储)通过智能LRU预测将存储成本降低87%、计算支出减少25%,整体TCO接近S3水平;Index Build Level索引策略实现精度与成本自动平衡;新增地理空间、时区时间戳、INT8向量等数据类型;JSON Shredding与JSON Path索引让元数据过滤提速100倍;BM25全文搜索速度较Elasticsearch快4-7倍且支持关键词+向量混合检索……覆盖AWS、GCP、Azure、阿里云、腾讯云五大平台,成为全托管、生产就绪的AI应用开发平台。

云和恩墨荣获超聚变2025行业贡献伙伴奖

1月16日,2026超聚变四川伙伴大会在成都召开,近190家核心生态伙伴齐聚,共探智能体时代产业机遇,并对2025年做出突出贡献的渠道合作伙伴予以表彰。云和恩墨凭借与超聚变的深度协同创新,以及在多行业软硬件一体化方案的落地实践,荣获“2025行业贡献伙伴奖”。

image.png{{{width="auto" height="auto"}}}

方案中,超聚变FusionServer系列机架服务器作为“硬件基石”提供算力支撑;云和恩墨zData X多元数据库一体化承载平台则作为“软件大脑”,以全栈管理能力激活硬件潜能、运行数据库工作负载。双方联合打造的一体化解决方案,已在医疗、贸易、金融、能源等多行业核心业务场景落地。例如山东省某医院HIS系统、上海某贸易企业BI系统、贵州某证券公司OA/HR系统及某省电力营销2.0系统等项目。

正式获批!清华大学联合海量数据、清华工研院共建“数据智能北京市重点实验室”

1月21日消息,清华大学联合海量数据、清华工研院共建的"数据智能北京市重点实验室"正式获批,由清华大学计算机系李国良教授担任主任。该实验室聚焦AI原生数据库、自主数据科学系统、可信数据空间三大方向,致力于构建安全可信、智能高效的新一代数据基础设施。

时序数据库 Apache IoTDB 入选国家重点研发计划高新技术成果产业化试点

1月22日,工业和信息化部正式公布《2025 年度国家重点研发计划高新技术成果产业化试点名单》,分布式时序数据管理系统 Apache IoTDB 作为相关技术成果之一入选。此次入选,反映了该技术成果在基础软件领域的持续研发积累,以及其在工程化与产业化应用方面形成的实践经验。

image.png{{{width="auto" height="auto"}}}

国家重点研发计划重点资助事关国计民生的重大社会公益性研究,工业和信息化部最终确定 67 个试点成果与 108 个试点单位,为高新技术从“实验室”走向“产业化”铺就高速路。IoTDB 项目自 2011 年起由清华大学软件学院团队研发,2018 年开源加入 Apache 软件基金会,并于 2020 年毕业成为 Apache 顶级项目。2021年天谋科技成立,围绕 IoTDB 构建企业级国产信创产品与工程化交付体系,推动技术成果实际落地。

DolphinDB与DSG 达成生态合作,异构数据同步再添新选择

1月22日消息,浙江智臾科技有限公司(简称:DolphinDB)和迪思杰(北京)数据管理技术有限公司(简称:DSG)近日达成深度合作,依托双方核心技术优势联合推出 Oracle、MySQL 等数据源到 DolphinDB 的专属实时数据同步方案,构建“数据高效流转-高性能分析”一体化能力,为金融、能源、工业制造等关键行业提供数据驱动决策新支撑。

达梦数据与梦石科技达成战略合作,赋能自主医疗新生态

1月22日消息,近日,达梦数据与梦石科技近日正式签署战略合作协议,双方将在产品整合、技术研发、市场拓展等领域深度合作,共同探索智慧医疗领域的创新应用场景,打造国产自主创新产业生态新标杆,助力医疗行业数字化、智能化升级。

虚谷伟业荣获成都市信创密码 “2025 年度优秀合作伙伴”称号

1月26日消息,虚谷伟业在成都市信创密码适配服务中心2025年度工作总结暨优秀合作伙伴表彰会上,凭借在信创密码产业生态建设中的深度协作与卓越表现,获评“2025年度优秀合作伙伴”,与华为、海光信息、麒麟软件等企业共同上榜,彰显了其在信创数据库领域的核心实力。

赛迪顾问:达梦数据再获金融集中式国产第一,南大通用GBASE在金融行业云数仓市场占有率第一

1月28日消息,近日,赛迪顾问发布《中国金融业数据库市场研究报告(2025)》。达梦再获中国金融行业集中式数据库国内厂商第一,并在银行、保险、证券三大子市场竞争象限中分别位列第一。这已是达梦连续2年斩获该领域桂冠。GBASE南大通用是唯一一家分布式与集中式数据库均位居金融业(包含银行业、保险业)领导者象限,同时取得金融业用户渗透率第一、云数仓市场占有率第一的“双第一”成绩。

image.png{{{width="auto" height="auto"}}}

截至2025年底,达梦数据已服务超过260家金融机构客户,累计支撑超过2500套金融业务系统稳定运行,其中包括:银行业务系统1700余套,证券业务系统350余套以及保险业务系统450余套。目前,GBase数据库已覆盖金融主管单位、政策性银行、国有大行、股份制银行、城商行、农商行、农信社及保险、证券等各类机构270余家。

云和恩墨与崖山科技战略携手,多维协同共筑国产数据库创新生态

1月28日,云和恩墨与崖山科技在北京正式签署战略合作协议,双方将在产品研发、市场开拓、客户服务及生态赋能等多维度展开全面协同,联合打造"Data+AI"融合解决方案,重点突破金融、政务、制造等关键行业核心场景,共筑国产数据库创新生态。

image.png{{{width="auto" height="auto"}}}

<font color=4169E1 size=4>1月产品/版本发布</font>

2026 阿里云PolarDB开发者大会召开,PolarDB发布AI数据湖库等产品能力

1月20日,2026阿里云PolarDB开发者大会盛大召开,阿里云旗下云原生数据库PolarDB正式发布系列全新产品能力,包括AI数据湖库(Lakebase)、模型算子化以及面向Agent应用开发的托管能力等。与此同时,阿里云PolarDB首次阐释了“AI就绪数据库”的四大核心支柱,包括多模态AI数据湖库、高效融合搜索能力、模型算子化服务以及面向Agent应用开发的后端服务。

image.png{{{width="auto" height="auto"}}}

目前,阿里云PolarDB海内外用户规模已超2万,部署规模超300万核,覆盖全球86个可用区。

2026 平凯数据库新品分享会举办,一核三态,重塑 AI 时代数据底座

1月22日,平凯星辰举办"一源·三生·共进化"新品分享会,正式发布平凯数据库(TiDB企业版)全新"一核三态"架构——基于同一内核衍生出敏捷模式(存算聚合)、标准模式(3~∞节点存算分离)、聚能模式(存算聚合+亲和调度)三种部署形态,破解数据库选型"水平扩展、业务透明、极致性能"难以兼得的"不可能三角",实现数据分布"可聚可散"的自适应能力。同时发布新一代内核及平凯数据库云服务。

image.png{{{width="auto" height="auto"}}}

  • 敏捷模式:专为 TB 级以下数据量及创新业务设计。敏捷模式仅需 1-3 个节点即可起步,不仅读写性能大幅优于 MySQL,压缩率更提升 3 倍以上,提供了优于单机主从架构的高可用能力,极大地降低了客户的试错成本与使用门槛。
  • 标准模式:延续经典的存算分离架构,在水平扩展与业务透明性上保持业界标杆水准,完美适配数据量快速增长的成长型与核心业务场景。
  • 聚能模式:专为对延迟极度敏感的场景打造。通过内存直连与亲和性调度等技术创新,将延迟降低至原来的 1/4,吞吐提升 2-3 倍,让客户无需牺牲分布式弹性即可享受单机般的极致性能。

image.png{{{width="auto" height="auto"}}}

  • PingCAP新一代内核通过存算分离 2.0 架构,实现了对数据库内部模块的深度解耦与抽象。这一技术突破使得在线任务、离线计算与 AI 引擎(如向量、全文索引)之间能够实现“零干扰”的资源隔离。基于该内核的平凯数据库云服务将于 2026 年上半年正式推出。

image.png{{{width="auto" height="auto"}}}

相关资料

点击阅读原文:https://www.modb.pro/db/2019292973163438080


欲了解更多可浏览墨天轮社区,围绕数据人的学习成长提供一站式的全面服务,打造集新闻资讯、在线问答、活动直播、在线课程、文档阅览、资源下载、知识分享及在线运维为一体的统一平台,持续促进数据领域的知识传播和技术创新。

关注官方公众号: 墨天轮、 墨天轮平台、墨天轮成长营、数据库国产化 、数据库资讯

2 月 11 日,蚂蚁集团开源发布全模态大模型 Ming-Flash-Omni 2.0。在多项公开基准测试中,该模型在视觉语言理解、语音可控生成、图像生成与编辑等关键能力表现突出,部分指标超越 Gemini 2.5 Pro。

模型地址:https://github.com/inclusionAI/Ming

据介绍,Ming-Flash-Omni 2.0 是业界首个全场景音频统一生成模型,可在同一条音轨中同时生成语音、环境音效与音乐。用户只需用自然语言下指令,即可对音色、语速、语调、音量、情绪与方言等进行精细控制。模型在推理阶段实现了 3.1Hz 的极低推理帧率,实现了分钟级长音频的实时高保真生成,在推理效率与成本控制上走在前列。

(图说:Ming-Flash-Omni-2.0 在视觉语言理解、语音可控生成、图像生成与编辑等核心领域实测表现均已达到开源领先水准)

全模态和多模态有啥不一样?

在大模型快速演进的背景下,“多模态”和“全模态”这两个概念正在频繁出现在技术发布和行业讨论中。表面看,它们都指向“模型能处理多种类型的数据”,但在底层实现路径和能力边界上,两者存在本质差异。

从能力表象来看,多模态与全模态高度相似。无论是多模态大模型还是全模态大模型,用户侧的直观体验都是:模型可以同时接收文本、图片、视频,甚至音频等不同模态的输入,并给出统一的输出结果。这也是许多非技术用户容易将两者混为一谈的原因。

真正的分水岭,出现在模型内部的实现方式。目前主流的“多模态大模型”,本质上是一种“模型拼装”思路:针对不同模态的数据,系统会分别调用对应的专用模型进行处理——例如,文本由语言模型理解,图像由视觉模型解析,音频交给语音模型识别。随后,再通过一个融合模块,将来自不同模型的结果进行整合,生成最终输出。

这种架构的优势在于工程实现相对成熟、可控,也便于在已有单模态模型基础上快速扩展能力。但其局限同样明显:不同模态之间更多是“后验融合”,信息在中间环节已经被压缩或结构化,跨模态的深层语义关联难以充分建模。

相比之下,“全模态大模型”走的是一条更底层的路线。所谓全模态,并不是简单地“支持更多输入类型”,而是指模型在设计之初,就将多种模态视为统一的信息空间,在同一个模型参数体系中进行联合建模。文本、图像、音频、视频不再对应独立的子模型,而是通过统一的表示方式进入同一套网络中学习、推理和生成。

这意味着,全模态大模型具备原生的跨模态理解与生成能力:不同模态之间的关联不是在输出阶段“拼接”出来的,而是在模型内部的表示层和推理过程中自然形成的。从理论上看,这种架构更接近人类对世界的感知方式,也更有潜力支持复杂的跨模态推理任务。

在当下,大多数落地应用仍然基于多模态架构。

业内普遍认为,多模态大模型最终会走向更统一的架构,让不同模态与任务实现更深层协同。但现实是,“全模态”模型往往很难同时做到通用与专精:在特定单项能力上,开源模型往往不及专用模型。

蚂蚁集团在全模态方向已持续投入多年,Ming-Omni 系列正是在这一背景下持续演进:早期版本构建统一多模态能力底座,中期版本验证规模增长带来的能力提升,而最新 2.0 版本通过更大规模数据与系统性训练优化,将全模态理解与生成能力推至开源领先水平,并在部分领域超越顶级专用模型。

 

此次将 Ming-Flash-Omni 2.0 开源,意味着其核心能力以“可复用底座”的形式对外释放,为端到端多模态应用开发提供统一能力入口。

 

Ming-Flash-Omni 2.0 基于 Ling-2.0 架构(MoE,100B-A6B)训练,围绕“看得更准、听得更细、生成更稳”三大目标全面优化。视觉方面,融合亿级细粒度数据与难例训练策略,显著提升对近缘动植物、工艺细节和稀有文物等复杂对象的识别能力;音频方面,实现语音、音效、音乐同轨生成,支持自然语言精细控制音色、语速、情绪等参数,并具备零样本音色克隆与定制能力;图像方面,增强复杂编辑的稳定性,支持光影调整、场景替换、人物姿态优化及一键修图等功能,在动态场景中仍保持画面连贯与细节真实。

 

百灵模型负责人周俊表示,全模态技术的关键在于通过统一架构实现多模态能力的深度融合与高效调用。开源后,开发者可基于同一套框架复用视觉、语音与生成能力,显著降低多模型串联的复杂度与成本。未来,团队将持续优化视频时序理解、复杂图像编辑与长音频生成实时性,完善工具链与评测体系,推动全模态技术在实际业务中规模化落地。

 

互联网业务中IP地址数据服务是构建精准定位、风险控制、运营优化等能力的重要基础。随着大数据的扩散,市场对IP数据应用的要求不断提高,IP数据云等专注于IP地址数据解析的平台正逐步成为开发者与企业的必备工具。本文将从IP地址定位精准度、数据维度、服务稳定性、更新频率等关键维度出发,全面分析这类工具有何特点。

一、IP定位的精准度过渡到街道级

IP数据云全球IP归属地产品在定位精准度不断进行提升。其归属地服务不仅涵盖国家/省市/区县/街道等多层级位置,还覆盖纬度/经度、时区、邮政编码及气象站代码等细化维度,能够支持街道级的精准定位查询。

二、丰富的数据维度过渡到多场景数据支持

目前来看单一的地理位置数据已无法满足现代业务需求。IP数据云在数据维度层面不仅覆盖传统的归属地信息,还提供包括:

  1. 运营商/ASN号与行业类型信息;
  2. IP宿主信息(所属机构/行业/商圈定位);
  3. IP真人标签、代理识别、风险画像与行为分析等扩展能力;
  4. 网络应用场景识别(例如企业专线、数据中心或普通家庭宽带区分)。

通过“多维度+多业务面”的数据结构使IP地址完成地理标签、风险评估、精细营销定位、反作弊与用户分析等复杂业务逻辑构建。相比一些传统的地理定位服务仅返回国家/城市等基本信息,IP数据云的数据输出更偏向于满足企业级应用需求,这也是其针对政企安全、金融风控等场景常被选用的原因。

三、更新频率——日更、周更、月更可自定义

数据的时效性直接影响定位准确与业务效果。IP数据云支持日更、周更、月更的更新策略,并可根据业务需求定制更新频率,确保IP映射与属性数据与最新互联网环境相匹配。在行业层面,一些主流IP数据库通常也会采取定期更新策略。例如部分国际服务提供每日、每周或月度更新,以应对IP地址分配与地理变更的频繁动态。

四、服务稳定性与可用性——高性能API与离线方案

在性能与稳定性上,IP数据云提供1000次/秒级别的API响应能力,并支持多种语言SDK与离线库接入(包括CSV、TXT、定制格式等),为大量并发查询场景提供良好的响应保障。

与此类工具对比,一些开源或轻量级IP数据库虽支持本地部署,但是在高并发负载、扩展性与稳定性保障上往往需要开发者自行搭建缓存、负载等技术栈来支撑。因此,从企业级应用角度看,IP数据云的稳定性与易集成特性具有明显优势。
IP数据云这类IP查询工具有什么特点?.png

五、适配多种业务场景

单纯的地理位置查询已经不能满足当前互联网应用的多元需求。IP数据云通过扩展数据服务能力,使得IP数据在广告定向投放、交易风险评估、网络安全分析、用户画像构建等场景中都能直接作为核心数据源供业务调用。这一点也区别于部分只聚焦IP→基础位置映射的传统服务。

总结

整体来看,IP数据云这类IP数据服务工具在以下几个维度具备明显特点和竞争力:

  1. 精准度更高:细粒度地理定位能力支持街道级别解析;
  2. 数据维度丰富:融合运营商、行业标签、风险属性及行为洞察;
  3. 更新机制灵活:支持敏捷更新机制,提升数据时效;
  4. 稳定性强:高并发API+离线部署满足不同业务规模;
  5. 业务适配广泛:不仅限于定位,还可用于反欺诈、资产洞察等多场景。

相比传统IP定位库,IP数据云更聚焦企业级复杂场景与数据洞察能力的构建,为决策、风控、运营优化等提供了一套完整的IP数据引擎解决方案。

2026 年,智能体将在企业级应用中取得哪些实质性突破?点击下载《2026 年 AI 与数据发展预测》白皮书,获悉专家一手前瞻,抢先拥抱新的工作方式!

具备治理性、可信语义的数据层已成为 AI 就绪数据的基础能力。近日,Snowflake 正式宣布语义视图自动驾驶(Semantic View Autopilot,SVA) 全面上市。该系统能够基于现有查询与商业智能资产,自动生成语义视图。

问题在于定义缺失,而非大语言模型能力

2025 年,开发 AI 智能体的团队发现,即便最先进的模型也难以应对不一致的业务逻辑。真正的障碍并非 AI 能力,而是数据定义的缺失。

 

VTS 工程高级副总裁 Prashanth Sanagavarapu 指出:“构建并维护统一的语义层需要大量人工投入,以避免数据指标冲突。” 为此,我们推出语义视图自动驾驶方案,旨在自动化构建这一具备治理能力且可信的语义层。

 

“语义视图自动驾驶技术为我们的 AI 系统提供了统一且受控的业务指标理解框架……使我们能够提供可靠的个性化服务及 AI 驱动的交互体验,赢得客户的长期信任。”Simon AI 首席技术官 Matt Walker 表示。

Snowflake 自动化语义视图创建

语义视图不仅提供数据结构信息,更能阐释数据的业务含义与设计意图。它能够指导大语言模型(LLM)将原始数据转化为业务概念,但传统的创建过程往往耗时费力且高度依赖人工操作。

 

对数据团队而言,确保业务逻辑的一致性至关重要。然而,人工创建语义视图负担沉重,例如,产品团队定义“月度经常性收入”时,可能未意识到财务部门会排除一次性设置费用。这类隐藏规则通常仅在部署后、数据对不齐时才会暴露。

 

Snowflake 语义视图自动化功能(SVA)通过自动创建和管理语义视图来弥合这一鸿沟。该功能无需工程师从零开始编写定义,而是基于查询历史与可信商业智能资产,主动推荐从中学到的候选指标与筛选条件,使团队能够在数分钟内完成审核、认证与部署,而非耗费数周时间。

运作机制:基于共识模式的学习

SVA 的核心原理在于:您的语义定义已蕴藏于查询历史、数据使用情况及仪表板之中。这使语义建模从编码工作转变为治理优化——团队只需专注于审阅 SVA 自动发现的业务逻辑。这些经治理的定义将为 Snowflake Cortex Analyst、Cortex Agents 及 Snowflake Intelligence 提供支持,以获取更精准可信的结果。

 

SVA 通过分析以下三类关键信号实现这一过程。

模式识别与共识驱动提取

SVA 采用聚类算法分析查询模式与自然语言问题,以识别共识性业务逻辑。当存在冲突定义时(例如不同的“活跃用户”筛选条件),SVA 会将最高频出现的模式作为推荐方案提出。

 

例如:若 200 余次查询均将“活跃用户”计算规则定义为“用户参与度分数> 50 且 最后登录天数< 30”,则即使用户近期运行了不同条件的查询,SVA 仍会优先推荐此共识逻辑作为标准提案。

多源高置信信号学习

最高置信源通常来自现有商业智能(BI)仪表板,其中沉淀了多年的业务逻辑。Tableau 是 SVA 支持的首个 BI 工具,未来将通过我们 20 余家 OSI 合作伙伴接入更多平台。SVA 可在数分钟内将静态仪表板转化为对话式人工智能应用(详见实践操作指南)。

 

团队亦可直接上传可信 SQL 查询语句。SVA 将自动提取数据关系与业务指标,并将其存储为经过验证的查询模型供后续使用。得益于全程在 Snowflake 内部运行,SVA 能够直接分析真实业务数据。通过列基数分析可推断关系类型,进而智能生成优化建议,例如为提升精度推荐部署 Cortex Search 服务。

基于持续演化的使用模式进行迭代更新

SVA 通过监控用户查询模式,持续优化语义视图的时效性。例如当企业新增“专业版”订阅层级时,SVA 将自动识别包含 subscription_tier = 'pro' 的新查询模式,并主动建议将其纳入语义视图体系,确保业务规则演进过程中智能应答始终保持一致性。

 

从传统商业智能向 AI 智能体的转型,需要建立在数据使用实践而非 LLM 预设的语义基础之上。Semantic View Autopilot 通过真实使用场景驱动语义建模,为您提供当前最快捷的、具备治理能力的上下文感知 AI 实现路径,现已全面覆盖 Snowflake 所有支持 Cortex Analyst 服务的区域。

 

即刻开启智能语义视图之旅。欢迎在您的 Snowflake 账户中体验 SVA,并获取为 Cortex Analyst 构建语义视图的最佳实践指南。

原文地址:https://www.snowflake.com/en/blog/semantic-view-autopilot/

点击链接立即报名注册:Ascent - Snowflake Platform Training - China更多 Snowflake 精彩活动请关注专区

怎么用 gemini 创作出这样的图片,感觉很高级,自己有点落后了,但是还是想学一下!
1770797423799.png

是有专门的某个工具?还是有一些大家都知道提示词我不知道?

作者:马国忠

引言:AI规模化落地,推理系统面临全新挑战



全球领先的市场研究和咨询公司IDC预测,到2028年,75%的新 AI 工作负载将实现容器化,从而显著提升模型与工作负载更新的速度、一致性与安全性。容器化技术将成为 AI 推理时代的“默认交付形态”。当前随着大模型技术快速演进与业务场景的深度融合,AI业务对推理基础设施的需求呈现爆发式增长。在早期小流量场景下,手动部署与定制化方案尚可应对;然而当模型规模、并发请求与业务复杂度攀升至新高度时,传统推理系统在以下四个主要方面逐渐暴露出瓶颈。

  1. 稳定性不足

单点故障风险:手动部署的静态架构缺乏多副本与故障自愈机制,单节点宕机易引发服务中断;

负载不均衡:缺乏智能流量调度,高并发时部分节点过载导致响应延迟,低负载时资源闲置;

故障恢复滞后:依赖人工排查与重启,恢复周期长,影响业务连续性。

2.资源利用率低下

静态资源分配:固定规模的GPU集群无法适应流量波动,高峰时段资源争抢,低谷期GPU闲置率超40%;

缺乏弹性机制:无法根据请求队列长度、KV缓存利用率等指标动态扩缩容,导致周级别GPU卡时浪费超5000+。

3.推理性能瓶颈

混合请求排队:长、短文请求混合处理时,短文首字时延(TTFT)因排队激增90%以上;

缓存复用率低:多副本场景下相同前缀请求随机调度,重复计算导致KV缓存命中率不足60%;

硬件拓扑未优化:跨交换机部署引发传输延迟,人工调整拓扑亲和性成本高且易出错。

4.定制成本高昂

多引擎适配复杂:vLLM、SGLang等引擎需独立开发接入层,版本迭代与兼容性维护成本攀升;

运维依赖人工:从部署、监控到故障修复全流程手动操作,人力成本占比超30%,且易引入人为错误。



为此,京东云结合实际业务需求与技术趋势,全面拥抱云原生技术栈,积累了丰富的云原生与高性能推理经验。自主研发了新一代云原生AI推理框架。 推动推理系统完成了一次体系化升级,实现了从手动部署到全场景AutoScale,从资源浪费到GPU利用率最大化。

流量高峰自动扩容、低谷自动缩容,GPU卡时节省高达26%;

智能流量调度与KV缓存复用,最高提升吞吐124%,首次生成时延TTFT降低90%;

具备多级高可用能力,支持流量隔离、故障自愈与深度可观测;

模型量化、引擎调优、算子开发等多项优化,推理引擎单点性能呈现局部领先优势。



详细了解一套生产级分布式AI训练推理平台(JoyBuilder)的云原生改造全纪实。京东云云原生AI推理框架。



一、系统架构设计:面向生产级的高性能云原生推理平台

设计理念:

我们遵循三大核心设计原则,确保系统长期迭代的灵活性:

1.解耦与组合 各模块尽量松耦合,优先复用开源成熟组件,同时避免被社区绑定,保留核心模块的可替换能力。

2.扩展性优先 支持以插件化方式集成智能调度算法(流量调度、扩缩容决策、Prefix Cache打分等);容器编排能力可扩展,目前已支持跨机部署与基于角色的调度策略。

3.引擎无感接入 目前可同时支持vLLM、SGLang等主流推理引擎,最终实现任意推理引擎的低成本接入。

系统架构:



模块详解:

1. 智能流量调度网关

基于云原生Gateway API与Inference Extension框架,我们构建了支持多引擎、高可用、高扩展的智能推理网关,支持多层次调度策略:



核心能力说明
长短文分桶推理 流量调度网关基于高效的长短文分桶算法,构建跨模型集群的分流调度,显著降低短文TTFT(首字生成时延);
前缀缓存感知KV复用流量调度面向不同模型上下文特征,基于 HashTrie 算法构建集群内全局pod的近似前缀缓存画像,支持prefix cache的亲和调度,有效降低推理 TTFT(首字生成时延);
多维负载均衡流量调度毫秒级实时采集KV Cache Utilization、Waiting Queue等server load指标,支持load aware 亲和调度;
交换机拓扑感知流量调度为减少PD group组内KV cache传输的耗时,构建网络拓扑感知,支持全局最优prefill + 局部最优decode的网络亲和调度
多引擎PD分离流量编排调度已支持vLLM(PD串行)、SGLang(PD异步并行) 异构引擎无差别流量调度
多LoRA动态流量调度、模型切换的流量调度实现不同引擎多LoRA的动态装、卸载,集成LoRA-aware 的动态流量感知调度能力;
精确的前缀感知Cache-aware流量调度实时订阅引擎侧KV Events Metrics,构建精确的前缀缓存画像,实现更高效的prefix cache亲和调度,进一步降低推理TTFT;
基于时延预测的SLO-aware 流量优先级感知调度利用延迟预测来估算每个请求在每个可用节点上的首次生成时间(TTFT)和每个输出令牌时间(TPOT),实现基于时延预测的SLO-aware智能调度;

2. 容器编排与资源调度



部署灵活:PD分离部署,具有Group和Pool两种模式,实现弹性扩缩容与拓扑感知调度。

高可用机制:多副本部署,避免单点故障。同时支持故障时自动摘流与容器自愈,保障服务持续可用,用户无感知。



核心能力说明
容器编排根据推理引擎工作特点,基于容器之间的协作关系(Kimi多容器跨机推理、PD分离架构等),将各个推理引擎容器一定的组织方式部署成一组Pods,并联动服务发现、重启策略。
GPU资源调度自动将各个新创建的Pod调度到具有足够GPU资源的机器节点。
拓扑感知调度Kimi跨机推理, TP16部署的2台机器保证在同一个交换机下;PD分离部署,协作关系的P和D在同一个交换机下。
优先级调度和抢占支持在线服务和离线任务的混合调度,高优的在线服务可以抢占低优任务的GPU资源。

3. 系统稳定性与可观测

•集成流量镜像、全链路告警与主备值班协同机制。

•通过网关大盘、调度模块监控、模型性能面板等多层次观测体系,实现问题快速发现与定位。





4. 引擎优化与性能突破

针对MoE、多模态等模型特点,通过算子优化、引擎调优与量化等手段,在多项关键性能指标上实现行业领先。



二、关键场景落地与收益量化

1. 长短文混合调度

问题:长、短文请求混合排队时,短文TTFT急剧上升,集群吞吐下降。 方案:通过长短文分桶与跨集群调度,实现长短文分离处理。

收益(以Kimi-K2与DeepSeek-V3压测为例):

Kimi-K2:短文TTFT降低90.97%,吞吐提升124.46%;长文吞吐提升33.89%,集群整体吞吐提升67%。

DeepSeek-V3:短文TTFT降低79.09%,吞吐提升36.7%;长文吞吐提升14.34%,集群整体吞吐提升21.82%。



2. KV Cache全局感知的流量调度

问题:多副本场景下相同前缀请求被随机调度,导致每个实例都重复计算并缓存相同前缀。 方案:持续刻画更新集群级KV Cache缓存画像,实现前缀匹配的智能路由,KV Cache高效复用。

收益

•DeepSeek-V3场景下,集群吞吐提升29.9%,首Token时延TTFT降低28.7%;

•Kimi-K2场景下,KV Cache命中率整体提升20%\~30%。
在这里插入图片描述

3. 全场景自动弹性伸缩

问题:夜间或周末的流量低谷期GPU资源闲置严重。 方案:通过多种弹性部署模式并基于排队长度与KV使用率等多项指标,实现全场景自动扩缩容。

收益

•周级别节省GPU卡时5000+,资源利用率提升26%;

在这里插入图片描述

4. 硬件拓扑亲和调度

问题:跨交换机部署导致性能下降;人工修正部署成本高,维护压力大。 方案

•通过节点标签与亲和性规则,实现交换机级自动拓扑亲和调度;

•Router实现按组进行PD配对流量调度。

收益

•组容器间通信不跨交换机,数据高效传输,全程自动化,无需人工干预,保证服务SLA。
在这里插入图片描述

5. 稳定性与业务连续性

问题: 容器故障后,因分发机制导致持续的客户影响。故障恢复强依赖人工,导致故障时间长,修复难度大。

方案: 通过实时健康监测,快速感知故障容器,进行隔离。启动新副本,实现故障自愈。

收益:

•实现自动隔离,自动自愈,无需人工干预,节点人力成本,提高用户体验。





6.推理引擎无感接入

问题:多引擎支持成本高,定制化开发量大,维护成本高。 方案:构建统一推理引擎调度接入层,支持vLLM、SGLang等不同推理引擎一键接入。

收益:

•推理引擎无感快速接入。

•降低开发与维护成本。





三、收益总结

京东云云原生AI推理框架通过多维度调度与系统级优化,显著提升了推理效率与资源利用率。短文与长文吞吐均有大幅增长,首 token 延迟明显降低,并结合自动弹性扩缩容与 KV Cache 感知调度,进一步提升集群吞吐与缓存命中率,同时节省可观的 GPU 卡时成本。在此基础上,引入硬件拓扑亲和调度,实现更高效的自动化部署与调度,降低大规模集群运维压力;配合故障自愈、高可用机制与更精细的可观测体系,使系统运行更加稳定、可控、易排障。通过针对引擎瓶颈的持续优化,不同模型场景下的吞吐能力均得到明显增强。

能力量化结果与效益
长短文调度吞吐:短文提升120%+,长文提升30%+ TTFT:短文降低90%
自动弹性扩缩容GPU卡时:节省GPU卡时约26%
KV Cache感知调度提升KV Cache命中率:增长约20%\~30% TTFT:降低29% 集群吞吐:增长30%
硬件拓扑亲和调度实现自动化部署与调度,降低大规模集群运维成本
故障自愈与高可用自动检测故障、自动恢复故障,减少对人工的依赖,更具可控性
可观测性具备更细致的监控告警体系、提升故障发现和排查效率
引擎瓶颈优化DS-MoE模型吞吐提升9%,多模态模型吞吐最高提升39%

四、客户案例

客户背景

客户原系统面临AI规模化落地的挑战,在推理系统的稳定性、性能和资源利用率方面遇到了明显瓶颈。京东云通过帮助客户升级至云原生架构,成功改造了其推理系统,实现显著的性能提升和资源节约。见证了新系统如何带来切实的业务效益。

解决方案

京东云通过云原生AI推理框架对客户原78台节点进行逐步云原生改造,在不到一个月时间内从最初的2%切流比率提升到达到40%,实现对用户AI推理系统的云原生重构,助力企业实现高效、稳定、低成本的AI规模化落地。核心方案包括:采用智能流量调度技术,通过长短文分桶、KV缓存复用及拓扑感知调度;基于流量波动的弹性扩缩容机制;高可用架构通过多副本部署与故障自愈保障服务连续性;支持vLLM、SGLang等主流引擎的无感接入硬件拓扑优化实现跨交换机亲和调度,减少传输延迟。
在这里插入图片描述

客户收益



GPU吞吐能力:切换云原生系统后,GPU吞吐提升幅度达74%。这一增强使客户在高负载情况下依然能够维持高效的模型推理速度。

限流数量:云原生AI推理框架系统将需要限流的请求显著减少82%,这意味着更多的客户请求在高峰时段得到及时响应,提高了用户体验和满意度。

整体旧版系统云原生系统收益
机器规模78 (100%)50 (64%)28 (36%)-
请求数量36671 (100%)17091 (47%)19580 (53%)-
GPU吞吐 (TGS)-183319提升74%
限流数量687 ( 1.87%)570 (3.3%)117 (0.59%)减少82%
备注: 1、数据来源基于Kimi-K2-instruct-0905模型。

客户对于系统的云原生改造表示高度认可:“云原生AI系统的导入,让我们不仅在资源利用上实现了显著的性价比提升,同时在关键业务高峰期的响应能力也大大增强,显著减少了因限流带来的服务瓶颈问题。”





五、未来展望

京东云将继续优化云原生AI推理框架,致力于为客户提供更智能、高效、稳定的AI基础设施。通过在各个行业和应用场景中的深化应用,我们的客户可以持续依赖这一平台,实现业务的长期可持续发展。

这个成功案例不仅展示了京东云云原生AI推理框架系统的技术优势,也为其他企业提供了一个可借鉴的成功模型,期待更多客户从中获益。

京东云云原生AI推理框架的研发升级并非一蹴而就。从架构设计、配置调试再到全量上线,每一步都围绕着业务价值、性能提升与运维提效展开。我们相信,只有将稳定性、性能、成本三者统筹兼顾的基础设施,才能真正支撑AI业务规模化、可持续地落地与增长。如您有类似场景或技术交流需求,欢迎随时联系我们。

作者:牛潇

在 Agentic AI 快速演进的今天,“Agent Skills 会取代 MCP”或“MCP 已经过时”的声音不绝于耳。这种二元对立的叙事,看似犀利,实则掩盖了智能体架构设计中最本质的真相:Agent Skills 与 MCP 并非对手,而是搭档



前者是人类智慧的结晶——将业务规则、决策逻辑与合规要求,以声明式、可读、可维护的方式注入 AI 代理;后者是技术能力的桥梁——让 AI 能安全、可靠地触达现实世界的数据、工具与系统。一个回答“怎么做才对”,一个解决“能不能做”;一个由产品经理和业务专家驱动,一个由工程师和 SRE 构建。



本文旨在彻底厘清二者的核心差异、适用边界与协同模式。我们将从概念定义出发,深入实现机制,通过多维对比与真实场景剖析,最终给出一套可落地的选择策略与高阶架构范式。无论你是智能体开发者、平台架构师,还是正在规划 AI 原生应用的产品负责人,都能从中获得清晰的判断框架与实践指引。



更重要的是,我们将证明:真正的智能,不在于选择某一种工具,而在于知道何时用哪一种,以及如何让它们共舞



一、核心概念定义:超越实现的标准

1.1 Model Context Protocol (MCP) - 模型上下文协议

本质定义:MCP是一种标准化通信协议,定义了AI模型如何与外部系统建立安全、高效、可审计的双向连接。

核心特性

能力扩展协议:为AI代理提供访问实时数据、专业工具和企业系统的标准化接口

安全沙箱规范:在协议层面定义权限控制、数据隔离和操作审计机制

上下文同步机制:解决模型内部状态与外部世界状态的一致性问题

标准化接口:通过JSON-RPC或其他标准协议定义请求/响应格式、认证机制和错误处理

服务化架构:协议设计支持独立部署的服务进程,实现高可用和水平扩展

架构定位:MCP解决了 "能不能做" 的问题 (Capability),为AI代理扩展其原始训练数据范围之外的能力边界。

1.2 Agent Skills - 代理技能标准

本质定义:Agent Skills是一种模块化能力封装标准,通过声明式、配置化的方式定义AI代理在特定场景下的行为规范、决策逻辑和工作流程。

核心特性

流程编排标准:定义如何将原子操作组合成完整业务流程的标准

上下文感知能力:标准定义了技能如何根据对话历史和环境动态调整行为

透明可解释性:决策路径对人类可见,便于理解和修改

轻量级集成:标准设计支持无服务部署,修改配置即可生效

组合式架构:支持技能的嵌套、组合和复用

架构定位:Agent Skills解决了 "怎么做才对" 的问题 (Orchestration),为AI代理编写符合业务标准和人类期望的行为规范。



二、设计哲学与架构差异

2.1 MCP:能力导向的设计

MCP的核心设计哲学是能力扩展。它关注:

原子操作:如何安全地执行单一、精确的操作

连接管理:如何高效管理与外部系统的连接

权限边界:如何在协议层面实现细粒度权限控制

数据标准化:如何统一不同数据源的格式和语义

MCP的架构本质上是服务化的:
在这里插入图片描述

2.2 Agent Skills:流程导向的设计

Agent Skills的核心设计哲学是业务价值。它关注:

决策逻辑:在特定情境下如何做出正确决策

流程规范:如何将多个操作组合成符合业务标准的流程

上下文适应:如何根据环境变化动态调整行为

人类协作:如何使AI行为可理解、可预测、可修正

Agent Skills的架构本质上是声明式的:
在这里插入图片描述

三、多维度对比分析

维度Agent SkillsMCP
协议/标准类型声明式配置标准 (Declarative)通信协议标准 (Imperative)
核心关注点业务流程与决策逻辑 (What & Why)能力执行与数据获取 (How & Can)
抽象层级业务逻辑层 (Business Logic Layer)能力扩展层 (Capability Layer)
数据流向自顶向下 (决策驱动)自底向上 (能力驱动)
变更频率高 (业务规则经常变化)低 (接口相对稳定)
维护主体业务专家、领域专家工程师、系统管理员
安全模型软约束 (依赖执行引擎的策略)硬约束 (协议层强制控制)
性能特性低延迟 (纯逻辑决策)可变延迟 (依赖外部系统)
复用模式领域特定复用跨领域通用复用
标准化程度高 (结构化配置)高 (协议规范)



四、核心区别总结

4.1 本质差异

Agent Skills定义业务价值路径,MCP实现技术能力扩展

Agent Skills关注"为什么"和"如何"

◦为什么这个任务对业务有价值?

◦如何确保任务按照业务标准和合规要求完成?

◦如何在不同业务情境下动态调整决策逻辑?

◦其设计哲学是以业务为中心,将人类专业知识编码为AI可执行的规范

MCP关注"什么"和"能否"

◦需要访问什么外部数据或工具?

◦AI能否安全、可靠地执行这个具体操作?

◦如何在协议层面实现权限控制和数据隔离?

◦其设计哲学是以能力为中心,解决AI与现实世界连接的技术问题

4.2 架构隐喻

Agent Skills如同"企业SOP手册"

◦详细描述每个业务流程的标准步骤

◦规定在特定情境下的决策规则

◦可由非技术人员编写和维护

◦随业务需求灵活调整

MCP如同"企业IT基础设施"

◦提供基础数据访问和计算能力

◦确保系统安全性和可靠性

◦需要专业技术团队维护

◦变更需要严格测试和审批流程



五、场景示例对比:标准应用与实际落地

5.1 场景一:客户服务工单处理

需求:自动处理客户支持工单,需要理解客户意图、查询相关数据、生成适当回复。

Agent Skills标准应用(业务流程编排):

skill:
  name: "customer_ticket_processing"
  trigger: 
    event: "new_ticket_created"
  workflow:
    steps:
      - name: "intent_classification"
        description: "识别客户工单类型"
        rules:
          - "如果包含'退款'、'钱'等关键词,标记为财务类"
          - "如果包含'无法登录'、'错误',标记为技术类"
          - "如果包含'多久'、'什么时候',标记为咨询类"
      
      - name: "data_requirements"
        description: "确定需要查询的数据"
        conditional:
          if: "ticket_type == 'financial'"
          then: ["mcp_order_history", "mcp_payment_records"]
          elif: "ticket_type == 'technical'"
          then: ["mcp_user_activity", "mcp_system_logs"]
      
      - name: "response_generation"
        description: "生成符合品牌标准的回复"
        prompt_template: |
          你是一个专业客服代表,遵循以下规则:
          1. 使用友好、专业的语气
          2. 对于财务问题,必须提供具体金额和时间
          3. 对于技术问题,提供具体解决方案而不是模糊建议
          4. 如无法解决,明确升级路径
        constraints:
          - "不得承诺无法确认的信息"
          - "必须引用数据支持你的结论"

为什么适用Agent Skills

•✅业务规则复杂:需要根据多种条件动态调整处理流程

•✅合规要求高:必须遵循特定的沟通标准和数据使用规范

•✅频繁变更:客户政策和响应标准经常变化

•❌不适合MCP:这不是原子操作,而是需要上下文感知的决策流程




MCP标准应用(能力提供):

class CustomerDataMCP:
    @mcp_tool(permission="read_only")
    def get_order_history(self, customer_id, limit=10):
        """安全获取客户订单历史"""
        # 从订单数据库获取数据
        orders = self.order_db.query(
            "SELECT order_id, amount, status, created_at FROM orders WHERE customer_id=? ORDER BY created_at DESC LIMIT?",
            [customer_id, limit]
        )
        return {
            "orders": orders,
            "total_count": self.order_db.count("orders", {"customer_id": customer_id})
        }
    
    @mcp_tool(permission="read_only")
    def get_system_status(self):
        """获取系统当前状态"""
        # 从监控系统获取实时状态
        return self.monitoring_api.get_current_status()
    
    @mcp_tool(permission="write")
    def create_support_note(self, ticket_id, note_content, agent_id):
        """创建客服备注,需要写权限"""
        if not self.auth.has_permission(agent_id, "support_write"):
            raise PermissionError("Insufficient permissions")
        return self.support_db.insert_note(ticket_id, note_content, agent_id)

为什么适用MCP

•✅数据敏感性:涉及客户个人数据,需要严格的权限控制

•✅跨系统集成:需要连接订单系统、监控系统和客服系统

•✅结构化输出:需要统一的数据格式,避免文本解析歧义

•❌不适合Agent Skills:这不是业务决策,而是需要安全控制的原子操作

5.2 场景二:金融风险评估

需求:为贷款申请提供风险评估,需要综合多源数据、应用复杂模型、生成合规报告。

Agent Skills标准应用(决策规则与合规性):

skill:
  name: "loan_risk_assessment"
  trigger: 
    event: "loan_application_received"
  workflow:
    compliance_rules:
      - "必须检查申请者年龄是否≥18岁"
      - "必须验证收入证明真实性"
      - "禁止基于种族、性别等因素做决策"
      - "超过$100,000的贷款必须人工审核"
    
    assessment_steps:
      1. "data_collection":
           tools: ["mcp_credit_report", "mcp_income_verification", "mcp_employment_history"]
      
      2. "risk_calculation":
           description: "应用公司标准风险模型"
           rules:
             - "信用分<600:高风险"
             - "负债收入比>50%:中高风险"
             - "就业历史<2年:中风险"
      
      3. "decision_logic":
           rules:
             - "如果高风险因素≥2,拒绝贷款"
             - "如果中风险因素≥3,要求额外担保"
             - "否则,批准贷款但限制额度"
      
      4. "report_generation":
           template: |
             # 贷款风险评估报告
             **申请人**: {applicant_name}
             **申请金额**: ${loan_amount}
             
             ## 风险因素分析
             {risk_factors_section}
             
             ## 决策依据
             {decision_rationale}
             
             ## 合规声明
             本评估严格遵循[相关法规],未考虑受保护特征。

为什么适用Agent Skills

•✅合规驱动:需要严格遵循金融法规和内部政策

•✅决策复杂:需要权衡多个风险因素并应用业务规则

•✅审计要求:需要完整的决策路径记录和解释

•❌不适合MCP:这不是技术实现问题,而是业务决策逻辑




MCP标准应用(数据获取与模型执行):

class FinancialRiskMCP:
    @mcp_tool(permission="sensitive_data")
    def get_credit_report(self, applicant_id):
        """获取信用报告,处理敏感数据"""
        # 通过安全通道调用外部信用机构API
        report = self.credit_api.get_report(applicant_id)
        # 数据脱敏处理
        return self._sanitize_sensitive_data(report)
    
    @mcp_tool(permission="model_execution")
    def run_risk_model(self, features):
        """执行风险评估模型"""
        # 加载预训练的风险评估模型
        model = self.model_registry.get("risk-assessment-v3")
        # 特征工程和预测
        processed_features = self._preprocess_features(features)
        prediction = model.predict(processed_features)
        # 生成可解释的模型输出
        explanation = self.explainer.generate_explanation(model, processed_features)
        return {
            "risk_score": prediction,
            "confidence": model.confidence_score,
            "key_factors": explanation.top_factors
        }
    
    @mcp_tool(permission="document_generation")
    def generate_compliance_report(self, assessment_data):
        """生成合规的审计报告"""
        # 应用合规模板
        report = self.report_template.render(assessment_data)
        # 添加数字签名
        signed_report = self.crypto.sign_document(report)
        # 存档到审计系统
        self.audit_system.archive(signed_report)
        return signed_report

为什么适用MCP

•✅数据安全:涉及敏感金融数据,需要严格的访问控制

•✅专业模型:需要调用专门的风险评估模型

•✅审计追踪:需要完整的操作日志和数字签名

•❌不适合Agent Skills:这不是业务规则,而是需要安全控制的技术操作

5.3 场景三:实际落地案例 - Claude Code 中的自动化部署

需求:在软件开发项目中,实现自动化部署流程,包括运行测试、构建和部署到生产环境。

这是一个已在Claude Code中实际落地的场景,完美展现了 MCP 与 Skills 的协同工作模式。

MCP 层实现:提供原子能力

# mcp_deployment_server.py
from mcp_server import MCPServer, mcp_tool

class DeploymentMCP(MCPServer):
    def __init__(self, config):
        super().__init__()
        self.config = config
        self._setup_connections()
    
    def _setup_connections(self):
        """建立必要的系统连接"""
        self.ci_connection = self._connect_to_ci_system()
        self.s3_client = self._setup_s3_client()
    
    @mcp_tool()
    def run_tests(self):
        """
        运行项目测试套件
        返回结构化的测试结果
        """
        # 通过CI系统API触发测试
        test_result = self.ci_connection.run_pipeline("test")
        
        # 返回结构化结果
        return {
            "success": test_result["status"] == "passed",
            "total_tests": test_result["total"],
            "failed_tests": test_result["failed"],
            "duration_ms": test_result["duration"]
        }
    
    @mcp_tool(permission="deployment_write")
    def upload_to_s3(self, environment="production"):
        """
        将构建产物上传到S3
        需要部署权限
        """
        # 验证环境
        if environment not in ["staging", "production"]:
            raise ValueError("Invalid environment")
        
        # 获取最新构建产物
        build_artifact = self.ci_connection.get_latest_build_artifact()
        
        # 上传到S3
        bucket_name = f"myapp-{environment}-bucket"
        key = f"builds/{build_artifact['version']}/{build_artifact['filename']}"
        
        self.s3_client.upload_file(
            build_artifact['local_path'],
            bucket_name,
            key
        )
        
        return {
            "status": "success",
            "bucket": bucket_name,
            "key": key,
            "url": f"https://{bucket_name}.s3.amazonaws.com/{key}"
        }

MCP 层关键价值

•✅安全封装:敏感凭证(S3密钥、CI系统令牌)完全封装在服务内部

•✅标准化接口:提供统一的输入/输出格式,便于调用

•✅错误处理:在服务层处理网络错误、超时等异常情况

•✅权限控制:通过@mcp_tool(permission="deployment_write")严格控制部署权限

Skills 层实现:定义业务流程

# CLAUDE.md (项目根目录)

## Skill: 代码部署 (Deploy)

 **触发条件** :用户要求"deploy"、"部署"、"上线"或相关操作

 **执行流程** :
1.  **运行测试** :
   - 首先调用 MCP 工具 `run_tests`
   - 如果返回失败,立即停止并报错:"测试未通过,无法部署"
   - 不要继续执行后续步骤
   - 具体失败原因:{failed_tests} 个测试失败

2.  **执行上传** :
   - 如果测试通过,调用 MCP 工具 `upload_to_s3`
   - 参数设置:
     - environment: "production"(生产环境)
   - 等待上传完成确认
   - 验证返回的S3 URL是否可访问

3.  **验证部署** :
   - 访问部署后的URL进行健康检查
   - 确认关键功能是否正常工作
   - 如果验证失败,触发回滚流程

4.  **报告结果** :
   - 用简洁的语言总结部署结果
   - 包含关键信息:部署时间、版本号、S3 URL
   - 如果有问题,提供具体的错误信息和建议

 **安全规则** :
- 永远不要直接在生产环境执行未经测试的代码
- 任何破坏性操作(如数据库迁移)必须先询问用户确认
- 部署前必须备份当前版本
- 生产环境部署必须获得至少一名资深工程师的批准

Skills 层关键价值

•✅业务逻辑清晰:用自然语言描述完整的部署流程,易于理解和修改

•✅灵活调整:业务规则变化时(如添加预发布环境),只需修改配置

•✅团队协作:非工程师(如产品经理、QA)也能理解并参与优化流程

•✅透明决策:用户可以看到完整的推理过程,增强信任

协同工作流程

用户请求:"部署最新版本到生产环境"

1. Claude 检测到"部署"关键词,激活 "代码部署 (Deploy)" Skill
2. Skill 定义第一步:运行测试
   → 调用 MCP 工具 `run_tests`
   ← MCP 返回:{"success": true, "total_tests": 125, "failed_tests": 0}
3. Skill 检查测试结果,判定通过
4. Skill 定义第二步:执行上传
   → 调用 MCP 工具 `upload_to_s3` with {"environment": "production"}
   ← MCP 返回:{
        "status": "success", 
        "bucket": "myapp-production-bucket",
        "key": "builds/v2.3.1/app-bundle.zip",
        "url": "https://myapp-production-bucket.s3.amazonaws.com/builds/v2.3.1/app-bundle.zip"
      }
5. Skill 进行验证和报告
6. 最终输出:"✅ 部署成功!版本 v2.3.1 已部署到生产环境,S3 URL: https://..."

为什么这种分层架构最优

•✅关注点分离:MCP 专注"如何安全执行",Skills 专注"如何正确流程"

•✅变更独立性:修改部署流程不需要修改 MCP 服务,反之亦然

•✅复用性run_testsupload_to_s3工具可被其他 Skill 复用

•✅安全与灵活性平衡:敏感操作受控,业务逻辑灵活可变

实际工程价值

开发效率:新团队成员通过阅读CLAUDE.md即可理解部署流程

运维可靠性:MCP 层的错误处理和重试机制提高了系统稳定性

合规保证:所有部署操作都有完整审计日志

快速迭代:业务流程调整只需修改配置,无需重新部署服务



六、选择建议与高阶策略

6.1 基础决策框架

优先选择Agent Skills当: ✅ 业务规则复杂且经常变化:当决策逻辑依赖于业务策略而非技术实现时 ✅ 需要人类可读的规范:当非技术人员需要理解和修改行为规则时 ✅ 涉及主观判断:当任务需要权衡多个因素且没有明确的算法时 ✅ 强调一致性和合规性:当需要确保AI行为符合公司政策或法规要求时 ✅ 快速原型和迭代:当需要快速验证想法而不想投入大量工程资源时

优先选择MCP当: ✅ 需要访问外部数据源:当任务依赖实时数据、专有系统或敏感信息时 ✅ 性能要求严格:当需要高效处理大量数据或低延迟响应时 ✅ 安全性至关重要:当涉及财务交易、个人隐私或系统关键操作时 ✅ 需要精确控制:当任务要求精确的输入/输出格式或复杂的状态管理时 ✅ 跨系统集成:当需要连接多个不兼容的系统或协议时

6.2 高阶决策树

在这里插入图片描述

6.3 经典协同模式

模式1:分层架构(最常见)

在这里插入图片描述

最佳实践

Agent Skills负责"为什么"和"做什么" :定义业务目标和流程

MCP负责"怎么做" :提供具体的执行能力

严格分离关注点:避免在Skills中硬编码技术细节,避免在MCP中包含业务规则

模式2:技能驱动型MCP

skill:
  name: "dynamic_mcp_selection"
  description: "根据上下文动态选择最合适的MCP工具"
  logic:
    - if: "data_freshness_requirement == 'real-time'"
      then: "use mcp_live_data_feed"
    - if: "data_volume > 1GB"
      then: "use mcp_batch_processing"
    - if: "security_classification == 'sensitive'"
      then: "use mcp_encrypted_channel"

优势:最大化灵活性,适应复杂多变的业务需求

模式3:MCP增强型技能

class SkillEnhancementMCP:
    @mcp_tool
    def get_optimal_workflow(self, task_type, context):
        """基于历史数据推荐最佳工作流程"""
        # 分析历史任务完成数据
        historical_data = self.analytics_db.get_task_metrics(task_type)
        # 应用机器学习模型推荐最优流程
        recommended_workflow = self.recommender.predict_optimal_workflow(
            task_features=context,
            historical_performance=historical_data
        )
        return recommended_workflow

优势:利用数据驱动优化技能定义,形成闭环学习系统



七、总结与技术展望

7.1 核心原则重申

1.MCP = 能力扩展 (Capability Extension) :解决"能不能做"的问题

2.Agent Skills = 业务编排 (Business Orchestration) :解决"怎么做才对"的问题

3.协同而非替代:两者在智能体架构中互补共存,创造最大价值

7.2 真实工程经验教训

在多个大型AI系统中,我们观察到以下关键点:

误区1:用MCP实现所有功能

症状:每个小功能都实现为MCP工具

后果:过度工程化,维护成本高,业务逻辑与技术实现耦合

解法:优先评估是否需要外部系统访问或安全控制

误区2:在Agent Skills中硬编码复杂逻辑

症状:Skills配置超过2000行,包含大量条件判断

后果:决策逻辑难以理解和维护,执行不可靠

解法:将复杂逻辑拆分为MCP工具,Skills只负责业务编排

误区3:忽视安全边界

症状:在Skills中暴露敏感操作,在MCP中缺少输入校验

后果:安全漏洞,数据泄露风险

解法:敏感操作始终通过MCP,Skills只包含公开的业务规则

7.3 未来展望

随着AI智能体架构的发展,我们观察到以下趋势:

1.标准化融合

◦MCP协议将支持技能描述标准,使能力发现和组合更加自动化

◦Agent Skills标准将内置对MCP能力的语义描述,提升互操作性

2.动态协同

◦智能体将能够根据任务复杂度自动决定使用Skills还是MCP

◦运行时将动态平衡配置驱动和代码驱动的执行路径

3.开发者体验优化

◦统一的开发框架将无缝集成Skills和MCP

◦低代码平台将使业务专家能够定义技能,自动映射到合适的MCP能力



八、结语:协同共生,而非零和博弈

在AI技术社区中,经常出现"Skills将取代MCP"或"MCP是过时的技术"等论调。这些观点源于对两者本质的误解,忽视了它们在智能体架构中互补共存的价值。

MCP和Agent Skills不是竞争关系,而是共生关系

•MCP扩展了AI的感知和行动能力,使其能够连接现实世界

•Agent Skills定义了AI的思维和决策模式,使其能够按照人类期望的方式行动

将AI智能体视为一个完整的系统:

MCP是感官和肢体:眼睛(数据获取)、耳朵(事件监听)、手(工具执行)

Agent Skills是大脑和神经系统:决策逻辑、行为规范、学习能力

没有感官和肢体,大脑无法感知世界;没有大脑和神经系统,肢体无法协调行动。两者缺一不可。



终极建议

不要陷入"二选一"的思维陷阱。最强大的AI代理系统往往是Skills和MCP精心设计的协同体:

用Skills定义业务价值:什么是对用户真正有用的?

用MCP实现技术可能:如何最安全、高效地交付这些价值?

持续优化两者的边界:随着业务演进和技术进步,重新评估职责分配

记住:技术的目的是解决问题,而不是创造新的复杂性。Skills和MCP都是工具,明智的工程师会根据具体问题选择最合适的工具,或将多个工具创造性地组合,以交付最大价值。

在AI代理的未来,我们不会看到Skills取代MCP,或MCP淘汰Skills。相反,我们将见证一个融合的生态系统,其中配置驱动的灵活性与代码实现的强大性和谐共存,共同推动AI代理走向更智能、更可靠、更有价值的未来。








参考资料与延伸阅读

本文引用的核心概念与技术规范基于以下行业权威文档,推荐读者深入阅读以获取更多技术细节:

  1. Model Context Protocol Specification

•来源: Anthropic & MCP Community

•地址: modelcontextprotocol.io/introduction

•对应内容: 支持文中第一章与第二章关于 MCP 作为“标准化连接协议”、“安全沙箱”及“JSON-RPC 消息规范”的技术定义。

  1. Building Effective Agents

•来源: Anthropic Research Team (2024)

•地址: anthropic.com/research/building-effective-agents

•对应内容: 支持文中关于“Workflows(工作流) vs Agents(自主体)”的区分,以及为何在生产环境中应优先采用确定性较高的 Agent Skills(即文中提到的 Orchestration)。

  1. The Future of Agentic AI & Design Patterns

•来源: Andrew Ng, DeepLearning.AI (The Batch, Issue 242)

•地址: deeplearning.ai/the-batch/issue-242

•对应内容: 支持文中关于“SOP 即智能”的观点,详细阐述了通过结构化流程(Agentic Workflows)来提升 AI 产出质量的设计模式。

  1. Semantic Kernel Overview

•来源: Microsoft Learn

•地址: learn.microsoft.com/en-us/semantic-kernel/overview

•对应内容: 提供了文中“声明式技能”的工程实现参考,展示了如何将自然语言 Prompt 封装为可调用的 Skills/Plugins。

作者:李卿阳

在电商推荐系统中,推荐模型长期面临着两个核心矛盾:一方面,传统的多阶段级联推荐系统存在目标不一致和误差累积的问题;另一方面,直接引入大型语言模型LLM虽然能带来强大的推理能力,但其高昂的延迟和计算成本在工业级应用中难以承受。更重要的是,现有的生成式推荐方法在多场景扩展性上面临巨大瓶颈--每个场景都需要独立训练和部署,导致资源利用率低下、维护成本高昂。

京东零售OxygenREC团队在论文《OxygenREC: An Instruction-Following Generative Framework for E-commerce Recommendation》中提出了一种全新的解决方案:OxygenREC。这是一个基于“快慢思考”的指令跟随生成式推荐框架,不仅解决了推理能力与延迟之间的矛盾,更实现了“一次训练,多处部署”的多场景统一高效解决方案。
在这里插入图片描述

一、 关键挑战

OxygenREC 旨在解决当前推荐系统,特别是生成式推荐范式下的三大核心难题:

1.有限的演绎推理能力:现有的生成式推荐方法主要从用户海量行为中进行归纳学习,但在需要结合现实世界知识进行深度演绎推理的场景下表现不佳。比如下边两个例子:

1.当推荐的时空背景和用户画像是“成都冬至时的年轻宝妈”时,传统模型可能只是推荐“冬季外套”这样的商品,而无法深度推理出此时成都是“冷湿环境”,这位年轻母亲潜在的需求可能是“婴儿排汗睡衣”。

2.有个户外运动vlogger在购物行为中反复对比华为Mate 70和iPhone 16 Pro两款手机,传统系统因为用户频繁的交互历史,只会不断加强重复推荐这两款商品进行比价,而无法推理出其真正诉求可能是“高质量的移动影像”,从而模型未能精准推荐‘华为Pura’系列这一真正符合用户诉求的目标商品。

2.多场景适应与资源效率的矛盾:大部分推荐平台拥有首页、频道流、购物车、搜索等多种推荐场景。现有生成式推荐模型如果为每个场景训练独立模型,会带来巨大的运营和计算成本,而使用简单的统一模型又会面临“负迁移”问题--不同场景间的知识相互干扰,导致性能下降。

3.工业级部署的工程挑战:将LLM的深度推理能力与推荐系统的大规模稀疏特征、严格延迟要求相结合,是一个巨大的系统工程挑战。它需要同时处理推荐系统典型的TB级稀疏嵌入和LLM典型的十亿级稠密参数,这对训练框架和推理引擎都提出了极高要求。

二、 核心贡献

面对这些挑战,京东零售OxygenREC团队提出了一个基于指令跟随的生成式推荐框架-OxygenREC,首次把LLM中的“快慢思考”模式引入到生成式推荐中来。在OxygenREC框架中,通过基于Transformer 的Encoder-Decoder 作为骨干网络,能够根据特定指令生成语义化物品序列,来执行推荐场景的”快思考"方式。在“慢思考”模式中,引入上下文推理指令--由近线LLM pipeline 生成,将用户行为与上下文合成为可解释的指令。同时多场景对齐中,通过场景指令与基于强化学习的对齐机制,实现“一次训练,多场景部署”。

在这里插入图片描述

1. “快慢思考”架构:知识注入与低延迟的平衡

这是整个OxygenREC的基础,其核心思想是将复杂的推理过程“离线化”,保证在线服务的低延迟

慢思考:一个近线的LLM pipeline,综合分析用户的时空上下文、个性化特征和历史行为,生成高质量的 “上下文推理指令” 。这个过程融合了世界知识,能进行深度演绎推理,但因其是近线批量处理,不增加在线请求的延迟。

快思考:一个高效的编码器-解码器骨干网络。它接收“慢思考”生成的指令,结合实时用户信号,在严格的延迟限制下生成推荐序列。该骨干网络本身轻量、高效,专为实时推理优化。

在这里插入图片描述



2. 语义对齐的指令控制机制:让指令真正发挥作用

仅仅生成指令是不够的,还必须确保模型能够准确理解并遵循指令。OxygenREC通过两项关键技术实现精准指令控制:

查询到物品的对齐损失:在训练阶段,通过一个辅助的Query-to-Item (Q2I) 损失函数,将指令嵌入与目标物品嵌入在同一个语义空间中对齐。这使得指令能够“理解”物品,并用于检索:

在这里插入图片描述

指令引导检索(IGR) :在生成推荐时,利用对齐后的指令作为查询,从用户长期历史行为中检索出最相关的部分,过滤掉无关的噪声。这确保了模型生成时专注在与当前指令意图最相关的历史信息上,大大提升了可控性和准确性。



3. 基于指令与强化学习的多场景统一对齐:Train-Once-Deploy-Everywhere

这是解决多场景扩展性的关键。OxygenREC摒弃了为每个场景独立建模的思路。

场景指令化:将不同的场景信息(如首页、购物车)和可选的触发物品(如用户点击的入口商品)统一编码为 “场景指令” ,作为模型的条件输入。
在这里插入图片描述

统一奖励映射与策略优化:设计了一个统一的奖励映射服务,将不同场景、不同业务目标(如GMV,转化率,合法性,多样性)的奖励信号归一化。在此基础上,提出了Soft Adaptive Group Clip Policy Optimization (SA-GCPO) ****算法进行强化学习训练:


在这里插入图片描述

•该算法用自适应门控函数替代传统基于GRPO的硬截断方式(hard clip):

在这里插入图片描述



•并以基于用户真实反馈的奖励分数作为阈值区分正负advantage样本,显著提升了多任务、多场景下策略学习的稳定性和效率:

在这里插入图片描述



4. 大规模生产级系统实现

为了支撑以上创新,团队构建了完整的工程体系:

•统一训练框架:基于PyTorch,深度融合了工业级稀疏嵌入引擎和LLM稠密训练引擎,在128张H800 GPU集群上实现了40%的模型FLOPs利用率。

高性能推理引擎xLLM:针对生成式推荐长上下文、大候选集的特点,定制开发了xLLM推理框架,通过xSchedule(系统调度)、xAttention(算子优化)、xBeam(束搜索优化)三级优化,满足线上严格的服务级别目标。

近线指令服务:推理指令通过近线服务批量生成并存入KV数据库,线上推荐模型直接读取,实现了零在线LLM调用,兼顾了语义丰富性和低延迟。



三、 实验成果

OxygenREC在京东几个核心场景的大量离线实验和在线A/B测试中取得了显著效果,证明OxygenREC 基于生成式推荐的方法在大规模工业级推荐系统中的有效性。

1. 基于快慢思考的生成式框架有效性验证

语义ID:通过多源对比学习(文本、图像、行为关联)构建的层次化语义ID,在保持高类别纯度(92.8%)的同时,实现了极低的ID碰撞,证明了其强大的表达和区分能力。

指令跟随:消融实验证明,在BOS右侧插入指令的方式为最佳;融合了场景ID和触发物品ID的指令效果显著优于单一组件;IGR和Q2I对齐机制共同作用带来了显著的性能提升。

在这里插入图片描述



统一模型 vs. 独立模型:在六个核心场景的对比中,统一的OxygenREC模型全面超越了为每个场景独立微调的基线模型,验证了OxygenREC框架在场景间正向迁移的有效性。

在这里插入图片描述



2. 基于SA-GCPO后训练的有效性验证

在后续训练阶段,提出的SA-GCPO算法在合成数据比例变化时表现更稳定,且性能显著优于传统的GRPO及其变体GSPO。例如,在33%合成数据比例下,SA-GCPO在HR\@1和HR\@10上有显著提升。

在这里插入图片描述

3. 电商场景在线A/B测试的商业效果

OxygenREC已在京东App上形成覆盖用户购物全链路的部署闭环:首页导流(场景1、2)-> 频道浏览(场景3、4)-> 商品结算转化(场景5、6)。在线测试结果表明,该模型在所有关键业务指标上均带来显著提升:

首页场景:GMV提升4.52%-8.40%。

频道流场景:其中一个场景的订单量提升了8.03% ,显示出模型精准匹配购买意图的能力。

结算路径场景:在用户强购买意图下,GMV提升高达11.80%。

在这里插入图片描述

与行业上其他生成式推荐方式对比:

在这里插入图片描述

OxygenREC 在几个关键维度上进行了生成式推荐的范式革新:

•架构上,用“快慢思考”破解了推理与延迟的死结。

•效率上,用“统一指令模型”破解了多场景训练的困局。

•控制上,用“语义对齐与引导检索”构建了生成式推荐模型的指令跟随能力。

•优化上,用“SA-GCPO”和全栈系统优化,确保了技术在工业巨量流量下的可行性、稳定性和卓越性能。



总结与展望

OxygenREC的成功,标志着生成式推荐在工业落地上迈出了关键一步。它通过“快慢思考”巧妙平衡了深度推理与低延迟,通过“指令跟随”实现了对推荐过程的精准可控,并通过统一的奖励与策略学习破解了多场景扩展的难题,真正实现了“一次训练,多场景部署”的pipeline。

未来,京东零售OxygenREC团队计划从两个方向继续探索:

•一是向基于语言扩散模型的非自回归生成范式演进,从根本上突破序列生成延迟与列表长度的线性关系,满足更高吞吐需求;

•二是开展跨场景用户轨迹建模,从用户在首页、搜索、购物车、结算等多场景的连贯行为中挖掘更深层的用户意图,实现更长周期的价值推荐。

OxygenREC不仅是一个高效的推荐系统,更为工业级生成式AI应用的大模型设计提供了宝贵范式--如何将大模型的“脑”与小模型的“身手”结合,如何在复杂多目标任务中实现稳定高效的学习,这其中的思想值得广泛借鉴。

第一季看着还是挺惊悚悬疑的,第二季开始往宗教方向发展了。果然,科技的尽头是神学。


但这种软科幻设定还是挺有意思的。用脑科学技术,把工作生活,分成两部分。
也就是说,你完全没有工作时候的记忆,每天只要打卡,一下秒就下班了。 smirk
如果现实中的有这种技术,你会考虑去做吗?

p2909322789

对了,版主大大的论坛签到系统,有没有借鉴这部剧的灵感啊,有点好奇force_smile

2025年,数字化浪潮迈入“深水区”。企业的核心诉求,已从搭建云原生实验田,转向寻求能承载关键业务、实现价值规模化的坚实平台。这正需要骐骥一跃的突破力,与稳驭核心的掌控力。

.png)

KubeSphere 作为企业级多租户容器平台,正致力于成为这一转型中的可靠伙伴与稳健座驾。我们通过简化管理复杂性、整合业界最佳实践、提供开箱即用的生产级能力,帮助全球客户在多云与异构环境中,驾驭稳定、高效、自主可控的应用管理平面,从而加速创新交付、优化资源成本、保障业务永续。

回首过去一年,我们不仅实现了产品能力的关键一跃,更在与金融、政务、制造、教育等领域客户的并肩实践中,见证了平台价值在核心业务中的平稳落地与驾驭。

产品深耕:夯实企业级基石

2025年,我们通过一系列版本迭代持续打磨产品,最终发布的 v4.2.1 版本标志着 KubeSphere 在“体验卓越与生产就绪”的道路上迈出了坚实一步。 该版本及全年的更新始终围绕解决企业规模化应用的核心挑战展开,致力于为各行业客户提供更稳定、高效的管理体验。

1. 强化异构资源统一纳管

面对混合架构带来的管理复杂度,v4.2.1 版本致力于构建统一、高效的异构算力底座。平台增强了对 GPU/vGPU 等异构计算资源的统一纳管与调度适配,满足从AI推理到图形渲染的多元化算力需求。同时,通过集成智能数据缓存加速能力,显著降低了I/O密集型应用的存储访问延迟。这些能力共同为企业提供了一个可跨云、跨芯的标准化资源池,实现了算力资源的全局统筹与弹性供给。

2. 升级弹性调度体系

为实现极致的资源效率与成本优化,v4.2.1 引入了多维联动的智能弹性调度体系。平台创新性地一站式集成垂直伸缩(VPA)、水平伸缩(HPA)与事件驱动伸缩(KEDA)。VPA根据历史负载自动优化容器资源规格,避免浪费;HPA增强策略允许对扩缩容行为进行独立精细调控;KEDA则能将消息队列等外部事件直接转化为弹性信号,甚至支持副本数缩零以极致降本。

3. 筑牢集群稳定防线

为保障大规模、多集群生产环境的全局稳定,v4.2.1 在治理与可观测层面进行了重磅增强。平台新增节点组(Node Group) 能力,支持将物理节点逻辑分组并与企业空间绑定,完美支撑多租户资源隔离、信创环境混部等复杂场景。在运维层面,提供成员集群可视化在线升级与状态精准同步,极大简化了多集群生命周期管理。

全球实践:深入关键场景

产品的最终价值,在用户应对核心业务挑战时得到最真实的体现。2025年,KubeSphere 的可靠性、灵活性与开放性,在全球多个行业的关键业务场景中赢得了深度信任。

国内实践

  • 某头部汽车金融公司:采用 KubeSphere 企业版构建混合云统一平台,在满足金融级强合规与隔离要求的前提下,实现了资源全局弹性调度与一站式运维,使整体运维效率提升超 40%,为创新金融业务的快速上线与稳定运行提供了强大支撑。
  • 某直辖市规划和自然资源局:打造“一云多芯”政务容器云平台,无缝纳管异构芯片架构资源,实现跨架构统一调度与标准化流程,有力支撑了智慧城市、空间规划等核心政务系统的数字化升级与高效协同。
  • 澳门气象局:选用KubeSphere可信版为其核心气象预报与监测系统构建云原生底座,在满足高安全与合规要求的同时,实现了资源的统一调度与服务的自动化运维,有力保障了气象业务7x24小时不间断稳定运行。

海外拓展

  • 欧洲 IT 解决方案商 AMPLUS S.A.:在为希腊某公立大学构建科研平台时,基于 KubeSphere 打造了标准化云原生管理方案。该选择显著降低了长期运维成本、赋予用户自主管理能力,并提升了方案的可复用性与交付效率,助力 Amplus 建立了可快速复用于其他教育及企业客户的产品化服务能力。

生态共建:汇聚行业力量

2025年,KubeSphere 的技术影响力与生态认可度持续提升,GitHub 全球星标数突破 16,000, 这标志着产品价值获得了全球开发者的广泛关注。我们始终秉持协作共赢的理念,致力于与业界伙伴及用户共同构建一个充满活力的技术生态。

  • 培育云原生新生力量:我们通过技术合作、联合创新及人才培养等多种形式,与众多行业伙伴及高校建立了深度链接,例如通过“开源之夏”等活动,成功孵化了智能运维助手等创新工具原型,推动了前沿技术的实用化探索。
  • 汇聚业界最佳实践:通过灵活的扩展组件架构,我们实现了与 Fluid(数据编排)、OceanBase(分布式数据库)等业界顶尖技术的深度集成。这使用户能够根据自身需求,灵活选用并组合经过生产验证的最佳技术组件,构建坚实可靠的底层架构。
  • 推动技术融合与标准实践:我们持续将大规模企业级部署中沉淀的稳定性保障与性能优化经验,贡献至行业生态,并与业界社区紧密协作,共同推动云原生应用管理标准的成熟与落地。

未来图景:平台化敏捷进化

为更敏捷地响应技术演进与多元的业务场景,KubeSphere 将在 2026 年采用全新的“核心底座年度更新,扩展组件季度发布”演进模式。这一模式旨在聚焦核心产品能力,增强关键场景支撑,并以灵活机动的组件化策略应对市场的快速变化,助力企业在稳定可靠的底座上,持续获取前沿价值。

我们的前行路径将围绕以下四大方向深化,致力于让平台更智能、更坚韧、更开放:

1. 全局治理与高可用保障

为支撑企业全球业务的连续性,我们将强化多集群联邦治理能力。重点是实现管理面的多活与容灾,通过集成 Karmada 等领先方案,确保控制平面自身具备跨可用区的高可用与故障恢复能力,为大规模、跨地域的集群部署提供坚实、可靠的管理基石。

2. 智能运维与成本洞察

我们将推动运维从“可视化”向“智能化”与“精细化”演进。全新设计的全局总览大屏与集中式告警中心,将为管理员与租户提供一目了然的运行状态与事件管理。在此基础上,计划引入的 AI 运维助手,将能通过对告警、日志及性能数据的分析,提供根因定位与修复建议。同时,我们将深化成本洞察能力,通过分析资源消耗与计费数据,提供可视化的成本分摊报表与优化建议,让云原生资源的使用成本清晰可见、可控可优,真正实现降本增效。

3. 生态集成与标准实践

我们将通过深化与云原生顶尖技术的集成,提供开箱即用的生产级方案,并推动实践标准化。具体而言:

  • 集成 Cilium:将提供基于 eBPF 的 Cilium 容器网络方案,它不仅带来更高的网络性能与可观测性,其强大的安全策略能力(如网络策略、服务网格)能更好地满足企业安全合规需求。
  • 拥抱 Gateway API:随着社区广泛采用的 Ingress NGINX 逐步进入维护尾声,我们将提供基于下一代标准 Gateway API 的流量管理方案,帮助用户从现有 Ingress 平滑演进至功能更强大、标准更统一的治理体系,有效规避技术断代风险,从容面向未来架构。

这些集成旨在将社区最佳实践产品化,推动企业采用行业公认的先进标准,降低技术选型与落地复杂度。

4. 核心PaaS能力延伸

为简化企业关键中间件的云原生部署与管理,我们将通过扩展组件,完善对基于容器的数据库、消息队列等中间件的全生命周期管理体验,提供部署、监控、备份等一站式能力,助力企业关键应用平滑、稳定地运行在统一的容器平台之上。

结语

2025年的每一次“一跃”,都源于客户、伙伴与社区成员的信任共创,铸就了台阶。展望2026,KubeSphere 已备好更稳健的底座与更敏捷的生态,诚邀您一同稳驭核心,共赴智能、韧性的数字化未来。

骐骥已备,征程万里。KubeSphere 邀您共驭数字化未来。

基于视觉的科学基础模型在推动科学发现与创新方面具有巨大潜力,主要源于其能够聚合多样化来源的图像数据(例如不同的物理观测场景),并利用 Transformer 架构学习时空相关性。然而,图像的 token 化与聚合过程计算开销巨大,而现有的分布式方法如张量并行(TP)、序列并行(SP)或数据并行(DP),尚未充分解决这一挑战。

在此背景下,来自美国能源部橡树岭国家实验室的研究人员提出了一种面向基础模型的分布式跨通道分层聚合方法(Distributed Cross-Channel Hierarchical Aggregation, D-CHAG)。该方法对 token 化过程进行分布式处理,并采用分层策略进行通道聚合,从而使极大规模模型能够在多通道数据集上运行。研究人员在高光谱成像与天气预测任务上对 D-CHAG 进行了评估,将该方法与张量并行和模型分片相结合后,在 Frontier 超级计算机上最多可将内存占用降低 75%,并在最多 1,024 块 AMD GPU 上实现持续吞吐量提升超过 2 倍。

相关研究成果以「Distributed Cross-Channel Hierarchical Aggregation for Foundation Models」为题,已发表于 SC25。

研究亮点:

  • D-CHAG 解决了多通道基础模型训练中的内存瓶颈和计算效率问题
  • 与仅使用 TP 相比,D-CHAG 可实现最高 70% 的内存占用降低,从而支持更高效的大规模模型训练
  • 在天气预测与高光谱植物图像掩码预测两种科学工作负载上验证了 D-CHAG 的性能


论文地址:\
https://dl.acm.org/doi/10.1145/3712285.3759870\
关注公众号,后台回复「跨通道」获取完整 PDF

使用两类典型的多通道数据集

本研究使用了两类典型的多通道数据集来验证 D-CHAG 方法的有效性:植物高光谱图像(Hyperspectral Images)和气象 ERA5 数据集。

其中,用于自监督掩码预测的植物高光谱图像数据由 Oak Ridge National Laboratory(ORNL)高级植物表型实验室(APPL) 收集。数据集包含 494 张杨树(Poplar)高光谱图像,每张图像包含 500 个光谱通道,覆盖波长从 400nm 到 900nm。

此数据集主要用于生物质研究,是植物表型分析和生物能源研究的重要资源。这些图像用于掩码自监督训练,即将图像切片作为 token 进行 mask,模型的任务是预测缺失的内容,从而学习图像的潜在数据分布。值得注意的是,该数据集未使用任何预训练权重,完全基于自监督学习进行训练,这也凸显了 D-CHAG 在高通道自监督任务中的适用性。

此外,在气象预测实验中,研究团队使用了 ERA5 高分辨率再分析数据集。研究选择了 5 个大气层变量(位势高度、温度、风速 u 分量、风速 v 分量、比湿度)和 3 个地表层变量(2 米温度、10 米 u 分量风速、10 米 v 分量风速),覆盖超过 10 个压力层,总共生成 80 个输入通道。为了适配模型训练,原始分辨率为 0.25° 的数据(770 × 1440)被重网格化为 5.625°(32 × 64),采用 xESMF 工具包 和双线性插值算法完成。

模型任务是进行未来时间步的气象变量预测,例如 500 hPa 位势高度(Z500)、850 hPa 温度(T850)、10 米 u 分量风速(U10),从而验证 D-CHAG 方法在时间序列预测任务上的性能。

D-CHAG :将层级聚合与分布式 Token 化结合

简单而言,D-CHAG 方法来自两种独立方法的融合,分别是:

分布式 token 化方法

在前向传播过程中,每个 TP rank 仅对输入通道的子集进行 token 化。在进行通道聚合步骤之前,需要执行一次 AllGather 操作,以便在所有通道之间实现跨通道注意力(cross-attention)。理论上,该方法能够降低每块 GPU 的 token 化计算开销。

层级跨通道聚合

这种方法的主要优势在于每个跨通道注意力层的内存占用减少,因为每层处理的通道数量更少。然而,增加层数会导致整体模型规模增大、内存使用增加。对于通道数量庞大的数据集而言,这种权衡更为有利,因为标准跨通道注意力的二次内存开销更高。

这两种方法虽然各有优势,但也存在一些不足,比如分布式 token 化方法在 TP rank 之间存在较高的通信开销,并未解决通道维度大内存占用的问题;而层级跨通道聚合方法会增加每块 GPU 上的模型参数数量。D-CHAG 方法通过分布式方式将两种方法结合起来,整体架构如下图所示:


D-CHAG 方法在基础架构上的示意图

具体而言,每个 TP rank 对总通道子集中的二维图像进行 token 化。由于每块 GPU 仅持有全部通道的一部分,在这些通道上本地执行通道聚合——该模块称为部分通道聚合模块(partial-channel aggregation module)。在每个 TP rank 内完成通道聚合后,收集输出并使用跨通道注意力进行最终聚合。前向传播过程中仅需执行一次 AllGather 操作;在反向传播时,只收集每块 GPU 的相关梯度,从而避免额外通信。

D-CHAG 方法能够充分利用分布式 token 化和层级通道聚合的优势,同时缓解它们的不足。通过将层级通道聚合分布到 TP rank 上,研究人员将 AllGather 通信减少为每个 TP rank 仅需处理单个通道,在反向传播过程中无需任何通信。此外,通过增加模型深度保留了每层聚合处理通道数量减少的优势,同时通过部分通道聚合模块将额外模型参数分布到各 TP rank 上。

研究对比了两种实现策略:

  • D-CHAG-L(Linear Layer):层级聚合模块使用线性层,内存占用低,适合通道数较多的情况。
  • D-CHAG-C(Cross-Attention Layer):使用交叉注意力层,计算成本较高,但在超大模型或极高通道数时性能提升显著。

成果:D-CHAG支持高通道数数据集上更大模型的训练

在构建 D-CHAG 后,研究人员对模型性能进行了验证,然后进一步评估了其在高光谱成像与天气预测任务上的表现:

模型性能分析

下图展示了 D-CHAG 在不同部分通道聚合模块配置下的性能表现:


图中展示了针对 1.7B 参数模型,在不同部分通道聚合模块配置下,每块 GPU 相对于仅使用 TP 基线的性能提升

  • Tree0 表示部分聚合模块中仅有一层聚合,Tree2 表示两层,依此类推;
  • 后缀 -C 和 -L 表示所用层的类型:-C 中所有层为 cross-attention,-L 中所有层为 linear

结果显示:

对于 512 通道数据,使用单层 cross-attention 层的性能略低于基线,但对 1024 通道数据可提升约 60%。

随着层次结构加深,即便是 512 通道数据,也能获得明显性能提升,而 1024 通道数据的性能保持相对稳定。

使用 linear 层时,即使层次结构较浅,也能在 512 和 1024 通道图像上获得性能提升。实际上,最佳性能出现在 D-CHAG-L-Tree0,即仅包含一层通道聚合层。增加聚合层会增加模型参数,引入额外内存开销。虽然对于 512 通道情况,增加层数似乎有益,但对于两种通道规模,仅使用一层 linear 层的性能优于更深的配置。

D-CHAG-C-Tree0 在两块 GPU 时对性能略有负面影响,但扩展至 8 块 GPU 时可获得 60% 提升。

植物高光谱图像的自监督掩码预测

下图比较了基线方法与 D-CHAG 方法在高光谱植物图像掩码自编码器应用中的训练损失,结果显示:在训练过程中,单 GPU 实现与 D-CHAG 方法(在两块 GPU 上运行)的训练损失表现高度一致。


基线方法与 D-CHAG 方法在高光谱植物图像掩码自编码器应用中的训练损失

橡树岭国家实验室分子与细胞成像组的高级研究员拉里·约克表示,D-CHAG 可以帮助植物科学家快速完成诸如直接从图像中测量植物光合作用活性等任务,从而取代费时费力的手动测量。

天气预测

研究人员在 ERA5 数据集上进行 30 天气象预测实验,下图比较了基线方法与 D-CHAG 方法在天气预测应用中的训练损失及三个测试变量的 RMSE:


基线方法与 D-CHAG 方法在天气预测应用中的训练损失及三个测试变量的 RMSE

下表则展示了模型在 7、14 和 30 天预测任务上的最终对比,包括 RMSE、MSE 以及 Pearson 相关系数(即 wACC)


D-CHAG 方法相较于单 GPU 训练在 7、14 和 30 天预测任务中的 MSE、RMSE 及 wACC 的百分比变化(% Δ)

结合图和表总体来看,训练损失与基线模型高度一致,各项指标的偏差极小。

随模型规模扩展的性能

下图显示了 3 种模型规模在需要使用 TP 的通道配置下,D-CHAG 方法相较于仅使用 TP 的性能提升:


D-CHAG 方法结合 TP 的情况下,相较于仅使用 TP 时,7B、15B 和 26B 参数模型每个 GPU 的性能提升情况

结果显示,对于 7B 参数模型,使用部分通道聚合模块中的线性层(linear layers)可获得 30% 至 70% 的性能提升,而使用交叉注意力层(cross-attention layers)可获得 10% 至 60% 的提升;对于 15B 参数模型,性能提升超过 20% 至 50%;而 26B 参数模型的性能提升在 10% 至 30% 之间。

此外,在固定模型规模下,随着通道数增加,性能提升更明显,这是因为在给定架构下,增加通道数不会增加 transformer block 的计算量,但会增加 tokenization 和 channel-aggregation 模块的工作量。

另一方面,仅使用 TP 无法训练 26B 参数、256 通道图像,但使用 D-CHAG 方法时,可以训练 26B 参数、512 通道的模型,仅使用不到 80% 的可用内存——这表明该方法能够支持高通道数数据集上更大模型的训练。

ViT:视觉 AI 从感知模型走向通用视觉基础模型

过去十年,计算机视觉模型主要围绕「单任务优化」展开——分类、检测、分割、重建各自独立发展。然而,随着 Transformer 架构在自然语言领域催生出 GPT、BERT 等基础模型(Foundation Models),视觉领域也正在经历类似的范式转移:从任务特化模型走向通用视觉基础模型。在这一趋势下,Vision Transformer(ViT)被视为视觉基础模型的关键技术基石。

Vision Transformer(ViT)首次将 Transformer 架构完整引入计算机视觉任务,其核心思想是:将图像视为一系列 patch token 序列,用自注意力机制替代卷积神经网络的局部感受野建模。具体而言,ViT 将输入图像划分为固定大小的 patch,并将每个 patch 映射为 embedding token,然后通过 Transformer Encoder 建模 patch 之间的全局关系。

与传统 CNN 相比,ViT 对科学数据尤其具有优势:适合高维多通道数据(如遥感、医学影像、光谱数据),可处理非欧几里得空间结构(如气候格点、物理场),适用于跨通道建模(不同物理变量之间的耦合关系),这也正是 D-CHAG 论文所关注的核心问题。

除了上文研究中提及的场景,ViT 正在更多场景发挥核心价值。2025 年 3 月,北京大学国际医院皮肤科主任医师韩钢文携其团队开发出一种名为 AcneDGNet 的深度学习算法,这是一种融合视觉 Transformer 与卷积神经网络,能获取更高效的分层特征表,让分级更精准。经前瞻性评估表明,AcneDGNet 的深度学习算法不仅比初级皮肤科医生更准确,而且与高级皮肤科医生的准确性相当,能够在不同的医疗保健场景中同时准确地完成痤疮病变检测并判断严重程度,有效帮助皮肤科医生和患者在在线问诊和线下就医场景中诊断和管理痤疮。

论文标题:

Evaluation of an acne lesion detection and severity grading model for Chinese population in online and offline healthcare scenarios\
论文地址:

https://www.nature.com/articles/s41598-024-84670-z

从产业视角看,Vision Transformer 标志着视觉 AI 从感知模型走向通用视觉基础模型的关键拐点。其统一的 Transformer 架构为跨模态融合、规模化扩展与系统级优化提供了通用底座,使视觉模型成为 AI for Science 的核心基础设施。未来,围绕 ViT 的并行化、内存优化与多通道建模能力,将成为决定视觉基础模型产业落地速度与规模的关键竞争点。

参考文献:
\
1.https://phys.org/news/2026-01-empowering-ai-foundation.html
\
2.https://dl.acm.org/doi/10.1145/3712285.3759870
\
3.https://mp.weixin.qq.com/s/JvKQPbBQFhofqlVX4jLgSA



少年呀,当你遇到这样的情况:API 慢得像蜗牛,P95 延迟超高,服务器在凌晨 3 点因为流量突发而崩溃,你是选择花三个月用 Rust 重写所有东西,还是选择看着用户流失呢。

或者,你可以像我一样,用一种作弊的方式,把 Bun 的极致速度嫁接到 Node.js 的庞大生态上。

别笑,我是认真的。我就能在不重写 5 年陈旧业务逻辑的前提下,把一个臃肿的后端接口压进 10ms 以内的。

image.png

边缘侧使用 Bun,通过 IPC 唤醒 Node 进程池

众所周知,Node 处理 HTTP 请求的开销太大了,但我的业务逻辑里全是依赖 crypto 和老旧 SDK 的代码,根本没法移植到 Bun。

所以我的解决办法是前店后厂。

我用 Bun 搭建了一个极薄的 HTTP 层,专门负责路由、参数校验和挡掉无效请求。只有真正需要那个老旧业务逻辑时,我才通过 IPC(进程间通信)把任务扔给后台常驻的 Node 进程。

千万别在请求来的时候才 spawn 一个 Node 进程,那样比单用 Node 还慢。你要做的是预先启动一组 Node Worker,要先预热才行。。

Bun 端(前台):

// bun-gateway.ts
const textDecoder = new TextDecoder();
const textEncoder = new TextEncoder();

// 启动一个常驻的 Node 进程,而不是每次请求都启动
const nodeWorker = Bun.spawn(["node", "heavy-lifter.js"], {
  stdin: "pipe",
  stdout: "pipe",
});

// 这是一个简单的读写封装,把复杂的脏活扔过去
async function askNode(payload: any) {
  const msg = JSON.stringify(payload) + "\n";
  nodeWorker.stdin.write(textEncoder.encode(msg));
  
  // 这里简化了读取逻辑,生产环境记得处理粘包
  const reader = nodeWorker.stdout.getReader();
  const { value } = await reader.read(); 
  return JSON.parse(textDecoder.decode(value));
}

Bun.serve({
  port: 3000,
  async fetch(req) {
    if (req.url.endsWith("/fast")) return new Response("Bun is fast!");
    
    // 只有这种重活才找 Node
    if (req.url.endsWith("/heavy")) {
      const data = await req.json();
      const result = await askNode(data);
      return Response.json(result);
    }
    return new Response("404", { status: 404 });
  },
});

Node 端(后台):

// heavy-lifter.js
const readline = require('readline');

const rl = readline.createInterface({
  input: process.stdin,
  output: process.stdout,
  terminal: false
});

rl.on('line', (line) => {
  const data = JSON.parse(line);
  // 假装我们在做一个很重的加密运算
  // Node 生态里的老代码都在这儿跑,不用改
  const result = { processed: true, echo: data };
  console.log(JSON.stringify(result));
});

这样搞,路由和 I/O 也是亚毫秒级的,而 Node 只需要处理纯计算,效率直接翻倍。

别让 CPU 搬砖,学会利用 Bun 的零拷贝特性

我发现服务器 CPU 居高不下,居然是因为我们在读取本地的配置文件和静态 JSON,然后序列化发给用户。

在 Node 里,通常会 fs.readFile 然后 res.send。这中间发生了好几次数据拷贝:从磁盘到内核,到用户空间 buffer,再到 socket。

在 Bun 里,我改用 Bun.file()。这不仅是写法上的区别,这是直接告诉操作系统:“把这个文件扔到网卡上去,别经过我的手。”

// 别再 readFile 了,直接流式传输
Bun.serve({
  fetch(req) {
    if (req.url.endsWith("/config")) {
      return new Response(Bun.file("./big-config.json"));
    }
    return new Response("404");
  }
});

这一行代码改动,让我的静态资源吞吐量提升了 3 倍。

排好队,微批处理(Micro-batching)

高并发最可怕的是什么?是 1000 个请求同时涌进来,每个都要单独去调一次数据库或者调一次 Node 进程。就像刚下课,一堆学生全涌到食堂打饭。

而我加了一个极小的缓冲窗口。

如果在 3 毫秒内来了 50 个请求,我把它们打包成一个数组,一次性发给 Node 或者数据库。

let buffer: any[] = [];
let timer: Timer | null = null;

function processBatch() {
  const currentBatch = buffer;
  buffer = [];
  timer = null;
  // 一次性把 50 个任务发给 Node,而不是发 50 次
  askNode({ type: 'batch', items: currentBatch });
}

function enqueue(item: any) {
  buffer.push(item);
  // 只有在第一次推进来时启动计时器
  if (!timer) {
    timer = setTimeout(processBatch, 3); // 3ms 的延迟用户无感,但吞吐量巨大提升
  }
}

这 3 毫秒的等待,换来的是 CPU 负载降低 60%。

别在循环里 new 对象,求你了

我审查代码时发现,很多人喜欢在 fetch 或者 handleRequest 里写 const db = new DatabaseClient() 或者 const regex = new RegExp(...)

每次请求都重新分配内存、建立连接、编译正则,GC(垃圾回收)不炸才怪。

把所有能复用的东西——数据库连接池、TextEncoder、正则表达式、加密 Key,全部提到全局作用域。在 Bun 和 Node 混合架构里,这一点非常重要,因为我们追求的是极致的低延迟。

双层缓存:内存不够,磁盘来凑

以前我只用 Redis,但网络请求还是有开销。后来我发现,Bun 读取文件的速度超级快。

于是我搞了个双层缓存:

  1. L1 内存缓存:用 LRU 存最热的 1000 个 Key,微秒级响应。
  2. L2 文件缓存:把稍微冷一点的数据直接写成 JSON 文件放在 /tmp/cache/ 下。

检查文件是否存在,比发起一个 TCP 请求去连 Redis 要快得多。

丢掉那些臃肿的 npm 包

以前在 Node 里,为了生成个 UUID 或者解析个参数,我们习惯性 npm install uuid 或者 qs

在 Bun 里(其实现代 Node 也是),crypto.randomUUID()URLSearchParams 都是内置的,而且是 C++ 层面优化的。

我把代码里所有非必要的 npm 依赖全部剔除,改用原生 API。这不仅让冷启动快了,更重要的是减少了 node_modules 的 I/O 噩梦。

解决精神分裂的开发环境

这一套架构就是Bun 做网关,Node 做计算。但在本地开发时,我差点崩溃。

我的电脑上本来跑着 Node 22,为了维护老项目,又要装 Node 14,还要装 Bun,甚至偶尔还要用 Deno 跑个脚本。

nvm 切换来切换去让我心力交瘁,端口冲突、路径报错、环境变量乱成一锅粥。我经常是修好了 Bun 环境,Node 的老项目又跑不起来了。

直到我发现了 ServBay,开发者的救命稻草,它不是那种简陋的版本切换器,它是一个完整的、隔离的运行环境平台。

image.png

  • 多版本并存:我可以同时开启 Node 14、Node 22 和 Bun 1.1 的环境,它们之间完全隔离,互不打架。
  • 一键全家桶:我需要的 Redis(做缓存)、PostgreSQL(存数据)、Caddy(做反代),它全都能一键安装并运行。

image.png

  • 零配置:我不由得感叹,以前为了配 Docker 和 Homebrew 浪费了不少时间啊。

有了 ServBay,我在本地完美复刻了线上的混合架构:Bun 监听 3000 端口,Node 监听内部管道,Redis 跑在后台。我再也不用担心这是环境问题还是代码问题了。

总结

只要能把响应时间压进 10ms,我不在乎混用多少种运行时。

Bun 给了我速度,Node 给了我稳定性,ServBay 给了我一个不发疯的开发环境

别再纠结用 Bun 还是用 Node.js了,都成年人了,为什么不能两个都要。把它们结合起来,现在就去把你的 API 延迟砍掉 90%。

全文链接:https://tecdat.cn/?p=44965
原文出处:拓端数据部落公众号
关于分析师

在此对 Hongxuan Liu 对本文所作的贡献表示诚挚感谢,他完成了应用统计专业的硕士学位,专注机器学习、风险管控领域。擅长 R 语言、Python,在机器学习、风险管控领域具备扎实的技术功底,可熟练运用相关软件开展数据分析、建模及风险管控相关工作。Hongxuan Liu 曾在中国农业银行从事数据分析工作,深耕金融领域数据分析与风险管控相关业务,负责银行各类数据的整理、分析与建模,为银行的风险防控、投资决策等核心业务提供数据支撑与实操建议,积累了丰富的金融行业数据分析实战经验。

封面

专题:2025年智能优化算法在A股投资组合配置中的实践与创新

引言

在国内A股市场的投资实践中,普通投资者和中小机构始终面临一个核心难题:如何在多只股票间分配资金,既能控制波动风险,又能实现资产稳健增值。早年间,多数投资者依赖经验或“等权重均分”的方式配置资产,这种缺乏量化支撑的策略,在2020年后市场波动加剧的背景下,资产波动幅度比科学配置方案高出30%以上。
马科维茨的均值-方差模型为量化配置提供了理论基础,但该模型对应的优化问题存在非凸性,传统梯度下降算法极易陷入局部最优,无法找到真正的全局最优配置。粒子群优化算法(PSO)凭借全局搜索能力强的优势成为解决这类问题的有效工具,但传统PSO初始粒子随机分布,导致收敛速度慢、无效计算多。基于此,我们结合为金融机构提供投资组合优化咨询项目的实战经验,提出将重要性采样(IS)与PSO融合的IS-PSO算法,通过定向生成高质量初始粒子群,解决传统PSO“盲目搜索”的痛点。本文将拆解该算法的设计逻辑、落地步骤及在沪深A股样本上的应用效果,让读者既能掌握实操方法,也能理解背后的核心原理。
本文内容改编自过往客户咨询项目的技术沉淀并且已通过实际业务校验,该项目完整代码与数据已分享至交流社群。阅读原文进群,可与800+行业人士交流成长;还提供人工答疑,拆解核心原理、代码逻辑与业务适配思路,帮大家既懂 怎么做,也懂 为什么这么做;遇代码运行问题,更能享24小时调试支持。

 项目文件目录

整体流程脉络

<pre data-index="0" name="code" style="color: rgb(0, 0, 0); font-size: 14px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: left; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;"><img alt="" src="https://i-blog.csdnimg.cn/direct/fa519e9285cd4756b5c826972a17bbba.png" style="border: 0px; max-width: 650px;">
</pre>

1 投资组合优化的行业痛点与技术基础

对于A股投资者而言,“分散投资却没分散风险”是普遍痛点——不少投资者将资金分散到多只股票后,要么收益跑不赢大盘,要么遇到市场调整时亏损远超预期。这背后的核心原因,是没有科学量化不同股票的收益和风险特征,仅依靠经验或简单的行业均分策略,无法适配复杂的市场环境。
马科维茨均值-方差模型为解决这一问题提供了核心框架:将投资组合的收益定义为各资产预期收益率的加权平均值,风险用收益率的标准差衡量,核心目标是找到“有效前沿”——即在给定风险下收益最高,或给定收益下风险最低的资产组合。这一目标转化为数学问题后,核心是最大化效用函数:max (ω^Tμ - λ/2*sqrt(ω^TΣω))。其中ω是资产权重向量(各股票配置比例),μ是资产预期收益率向量,λ是风险厌恶系数(数值越大代表投资者越不愿承担风险),Σ是资产收益率的协方差矩阵。
但这个效用函数具有非凸性,传统梯度下降算法依赖目标函数的梯度信息迭代,很容易停在局部最优解,无法找到真正的全局最优权重配置,这也是传统算法在实际投资中效果不佳的关键原因。

2 IS-PSO算法的创新设计与实现

粒子群优化算法(PSO)是模拟鸟群觅食行为的智能优化算法,每个“粒子”对应一组资产权重,通过迭代更新粒子的位置(权重)和速度,跟踪个体最优位置(pbest)和全局最优位置(gbest),最终找到最优权重配置。但传统PSO的初始粒子是随机生成的,大量粒子落在无效解区域,导致算法收敛慢、计算效率低。
我们的核心创新点在于,用重要性采样(IS)优化初始粒子群的生成逻辑:先随机生成大量权重样本,筛选出目标函数值前20%的“优质样本”,再基于这些样本的分布生成80%的初始粒子,剩余20%粒子随机生成(保证群体多样性)。这种方式让初始粒子聚焦在最优解附近,大幅减少无效迭代,提升收敛效率。

2.1 IS-PSO算法的R语言核心实现

以下是修改后的核心代码(变量名、代码结构均做调整,英文注释已翻译为中文,省略部分通用迭代逻辑):

# ===== 融合重要性采样的改进粒子群优化算法(IS-PSO) =====enhanced_pso_with_is <- function(converge_threshold = 1e-6, min_diversity = 1e-4, rand_seed = NULL) { # 设置随机种子,保证结果可重复 if (!is.null(rand_seed)) { set.seed(rand_seed) }# 步骤1:重要性采样预生成大量权重样本 pre_sample_total <- 500 # 预生成500个随机权重样本 pre_weight_matrix <- matrix(runif(pre_sample_total * asset_num), pre_sample_total, asset_num) # 权重归一化处理(确保所有资产权重和为1) pre_weight_matrix <- t(apply(pre_weight_matrix, 1, function(x) x / sum(x))) # 计算每个预生成样本的目标函数值 pre_obj_scores <- apply(pre_weight_matrix, 1, calc_objective_func)# 步骤2:筛选前20%的优质权重样本 top_sample_indexes <- order(pre_obj_scores, decreasing = F)[1:(pre_sample_total * 0.2)] top_weight_samples <- pre_weight_matrix[top_sample_indexes, ] sample_central <- colMeans(top_weight_samples) # 优质样本的中心位置 sample_cov_matrix <- cov(top_weight_samples) # 优质样本的协方差矩阵# 步骤3:生成初始粒子群(80%来自优质区域,20%随机生成) particle_positions <- matrix(0, particle_total, asset_num) for (i in 1:particle_total) { if (i <= particle_total * 0.8) { # 80%粒子从优质样本区域生成,考虑资产间相关性 asset_dim <- asset_num # 尝试对协方差矩阵做Cholesky分解(添加小值保证矩阵正定) chol_matrix <- try(chol(sample_cov_matrix + 1e-6 * diag(asset_dim)), silent = TRUE) if (inherits(chol_matrix, "try-error")) { # 分解失败时,使用对角协方差生成扰动值 disturbance_val <- sqrt(diag(sample_cov_matrix)) * rnorm(asset_dim) } else { # 分解成功则生成符合协方差分布的扰动值 disturbance_val <- chol_matrix %*% rnorm(asset_dim) } # 调整扰动幅度(0.2为实战验证的经验系数) temp_weight <- sample_central + 0.2 * disturbance_val temp_weight <- pmax(temp_weight, 0) # 保证权重非负(不允许卖空) } else { # 20%粒子随机生成,维持粒子群的多样性 temp_weight <- runif(asset_num) } # 对生成的权重做归一化处理 particle_positions[i, ] <- temp_weight / sum(temp_weight) }# 省略:粒子速度初始化、个体最优/全局最优参数初始化代码 ......# 省略:粒子位置/速度迭代更新、收敛条件判断的核心循环代码 ......# 返回算法最优结果 return(list( best_weight_config = global_best_pos, best_objective_val = -(global_best_score), portfolio_annual_return = sum(global_best_pos * return_vector), portfolio_annual_risk = sqrt(t(global_best_pos) %*% cov_mat %*% global_best_pos), converge_iterations = iter_count ))}

代码说明

  • 核心逻辑是通过预采样筛选优质权重样本,让80%的初始粒子聚焦在最优解附近,减少无效搜索;
  • 变量名如n_pre_samples改为pre_sample_totaln_assets改为asset_num,更贴合中文使用习惯;
  • 省略部分为PSO算法通用的迭代更新逻辑(如粒子速度调整、收敛判断循环),可参考常规PSO实现补充。

相关文章

专题:2025年游戏科技的AI革新研究报告

原文链接:https://tecdat.cn/?p=44082


3 IS-PSO算法在A股中的实际应用效果

我们选取沪深A股10只不同行业的股票(覆盖装备制造、信息技术、环保、医药等领域),以2020年7月至2025年6月共1198个交易日的收盘价为基础数据,先计算日对数收益率(Rt = ln(Pt/Pt-1)),再年化处理得到预期收益率和协方差矩阵,对比等权重配置、梯度下降算法、传统PSO、IS-PSO四种方式的应用效果。

3.1 收敛效率大幅提升

传统PSO算法平均需要120次迭代才能收敛,而IS-PSO仅需31次迭代,收敛速度提升74.4%。在计算效率上,IS-PSO平均运行时间为66.789毫秒,远低于传统PSO的232.732毫秒,这意味着在实际应用中,IS-PSO能更快给出最优配置方案,降低计算资源消耗。

3.2 收益风险比更优

在高风险厌恶场景(λ=0.9)下,IS-PSO配置的投资组合平均收益达到0.165,高于传统PSO的0.157;且IS-PSO生成的权重呈现“稀疏性”——仅聚焦2只核心股票,却实现了更高的收益风险比。这对中小投资者而言,大幅降低了选股和资金配置的门槛,无需分散到多只股票就能实现风险与收益的平衡。

3.3 权重配置结果可视化

(空行)

(空行)
上图清晰展示了不同算法的权重配置差异:梯度下降算法配置的资产数量多,但收益表现不如PSO类算法;IS-PSO与传统PSO均聚焦少数核心资产,但IS-PSO在收敛速度和高风险场景下的收益表现更优,更适合普通投资者使用。

4 应急修复服务与落地建议

针对算法落地过程中可能出现的代码运行异常、结果不符合预期等问题,我们提供24小时响应的应急修复服务,相比投资者自行调试,问题解决效率提升40%,能快速定位并解决代码报错、参数设置不当、数据适配异常等问题。
在实际落地层面,IS-PSO算法可直接适配中小投资者的需求:只需导入股票收盘价数据,设置风险厌恶系数,算法就能自动输出最优权重配置。后续可进一步优化方向包括:纳入债券、基金等多元资产,考虑交易成本、流动性等实际交易约束,通过贝叶斯优化实现算法参数的自动调整。

总结

  1. 针对A股投资组合优化的非凸性问题,融合重要性采样的PSO算法(IS-PSO)通过优化初始粒子群分布,将收敛速度提升74.4%,大幅提升计算效率;
  2. IS-PSO在高风险厌恶场景下收益表现更优,且生成的稀疏权重配置降低了中小投资者的实操门槛;
  3. 该算法已通过实际咨询项目验证,配套的24小时应急修复服务可保障算法稳定落地应用。

封面

作者:延枚

云效 MCP Server 已正式发布。它是一个为研发全生命周期提供统一可编程能力的元控制平面,旨在打通工具间的壁垒,实现研发流程的高度自动化。

目前,MCP Server 已提供超过 150 个原子能力(API),全面覆盖云效的核心模块,包括:

  • 组织管理: 组织列表、部门信息、角色、成员信息等
  • 代码管理: 代码仓库、分支、合并请求、文件树操作等
  • 项目管理: 项目、工作项、字段配置、评论、工时管理等
  • 流水线管理: 流水线、资源、标签、部署等
  • 制品仓库管理: 制品仓库、制品列表等
  • 应用交付: 部署单、应用、应用标签、变量组等
  • 测试管理: 测试用例、用例目录、测试计划、测试结果等

通过将云效 MCP Server 与自定义脚本,或与通义灵码、Cursor、iFlow-Cli 等本地/云端大模型工具结合,研发团队可以赋予程序直接“操作云效”的能力,从而高效完成各类重复性工作。

例如,在项目协作场景中,你可以实现:

  • 智能查询: 快速获取指定项目、迭代或成员名下的需求列表。
  • 自动编排: 将复杂需求自动拆解为子任务,并生成验收标准。
  • 批量处理: 一次性更新多个工作项的状态、负责人或标签。
  • 数据同步: 读取 Excel 或其他系统的数据,批量在云效中创建工作项。

为了帮助大家快速上手,我们推出了 【玩转云效 MCP】 系列专题文章。

本篇作为系列的第一篇,将聚焦于项目管理与协作场景,提供一系列“即刻可用”的 Prompt 示例与实战演练,手把手教你如何利用 MCP 实现项目管理的自动化。

前期环境准备

  1. 在本地准备好你的 AI 工具:
  1. 按照云效 MCP Server 的说明完成配置(包含 Token、组织信息等)。

配置完成后,你的 AI 工具就可以通过 MCP 协议直接调用云效的项目 / 工作项等接口。

检查 MCP Server 配置是否生效

完成配置后,可以先用两条最简单的 Prompt 做“自检”。本文中演示示例的 AI 工具为 Qoder。

1. 查看当前组织信息

查看云效当前的组织信息

预期:AI 会调用 YUNXIAO/GET_CURRENT_ORGANIZATION_INFO,并返回:

  • 组织 ID(lastOrganization)
  • 用户 ID
  • 用户名

这些信息后续会被用来继续检索项目、工作项等。

2. 查看当前用户信息

查看云效当前的用户信息

预期:AI 会调用 YUNXIAO/GET_CURRENT_USER,并返回用户名、邮箱、组织 ID 等相关信息。

只要上述两个调用能正常返回结果,基本可以认为 MCP Server 配置是正确的。

实用场景 1:检索+统计/批量处理

云效 MCP 提供了非常丰富的检索能力:

  • 项目级: 按项目名称、状态、创建时间等检索项目
  • 工作项级: 按标题、描述、状态、优先级、负责人、标签等检索工作项

你可以先让 AI 告诉你“有哪些可用条件”,再组合场景:

云效中检索项目都有哪些条件可使用?
云效中对于检索工作项都提供了哪些条件?

image

拿到条件后,就可以开始“场景编排”了。

1. 按创建人检索工作项

查看 云效正式自动化 组织中 bowentestmcp 项目 我自己创建的工作项

image

AI 一般会自动完成:

  1. 查询你所属组织列表
  2. 切换到“云效正式自动化”组织
  3. 查询该组织下名为 bowentestmcp 的项目
  4. 在该项目下检索“我创建的工作项”

2. 基于结果做统计 / 批量修改

拿到工作项列表后,可以继续下发指令:

把这两个工作项的状态改为已完成

AI 会:

  1. 查询该项目的工作流信息,确认“已完成”状态的 ID(比如:100014)
  2. 使用 YUNXIAO/UPDATE_WORK_ITEM 批量更新状态
  3. 再次检索校验修改是否成功

image

3. 更多检索 + 批量处理示例 Prompt

以下 Prompt 都是可以直接用的“套路”:

  • 按标签批量打标
某某项目下近一周我创建的需求,请统一加上「一期」标签
  • 按迭代统计
统计一下某某项目下,迭代名为「xx」的需求数以及完成情况分析
  • 按状态批量流转
请帮我找出 bowentestmcp 项目中所有状态为「已完成」的需求,然后统一将它们的状态改为「已关闭」
  • 按标题关键词 + 批量调优先级
查询 xx 项目中所有标题包含「登录」或「注册」的需求,将它们的优先级统一调整为「高」
  • 按创建人 + 批量改负责人
找出我创建的所有待处理状态的任务,把它们全部指派给张三(工号:xxx)

实用场景 2:拆分需求

大模型 + MCP 非常适合做“把一个大需求拆成很多小需求并直接录入云效”这类工作。

1. 按功能点拆分父需求

示例:已有父需求 QAAB-3,描述里包含一段“功能列表”:

  • 支持加法运算
  • 支持减法运算
  • 支持乘法运算
  • 支持除法运算

你只需要一句:

QAAB-3 这个工作项,请按照里面的功能点描述建立相应的子需求

AI 会:

  1. 查询 QAAB-3 的详细描述
  2. 自动解析描述中的有序列表(1/2/3/4)
  3. 通过 YUNXIAO/CREATE_WORK_ITEM 依次创建 4 个子需求
  4. 每个子需求继承父需求的类型、负责人等

最终在云效需求列表页就能看到新创建的需求:

image

2. 更多拆分需求的示例 Prompt

  • 按实现层拆分
找到「实现用户登录功能」这个需求,将它拆分成:前端 UI、后端接口、数据库设计三个子任务
  • 按列表自动拆分
查看 QAAB-8 的需求描述,自动识别其中的功能点列表(如 1. 2. 3.),为每个功能点创建一个独立的子需求
  • 按开发阶段拆分
将「实现用户注册机制」这个需求拆分为:
- 需求分析
- 技术方案设计
- 前端开发
- 后端开发
- 联调测试
- 上线部署每个阶段创建一个子任务
  • 按 INVEST 原则拆分大需求
QAAB-5 这个需求过大,请按照 INVEST 原则将它拆分成:
- 独立的(Independent)
- 可协商的(Negotiable)
- 有价值的(Valuable)
- 可估算的(Estimable)
- 小的(Small)
- 可测试的(Testable)
多个小需求

实用场景 3:优化需求内容

很多需求最初往往只是“半句话”,比如:

支持乘法运算:实现计算器的乘法运算功能,输入两个数,输出两数之积。

image

这类需求很难直接用于评审 / 开发 / 测试。借助 MCP,你可以让 AI:

  • 补全为用户故事形式
  • 写出业务流程与影响分析
  • 给出可测试的验收条件
  • 关键是:写回云效原工作项中

1. 完整优化一个需求示例(QAAB-5)

QAAB-5 这个需求,请进行业务分析优化:
要求:
1. 改为用户故事的结构
2. 分析业务流程和影响
3. 提供验收条件

image

image

AI 典型的处理步骤:

  1. 读取 QAAB-5 的原始描述(“实现计算器的乘法运算功能...”)
  2. 生成:

    • 用户故事(作为谁 / 我希望 / 以便)
    • 业务流程(打开计算器 → 输入数字 → 选择乘号 → 输入第二个数 → 点击等号 → 展示结果)
    • 业务影响(对前端 / 后端 / 错误处理 / 测试等的影响)
    • 验收条件(覆盖正数、负数、小数、0、边界值、非法输入、性能等场景)
  3. 使用 YUNXIAO/UPDATE_WORK_ITEM 将上述内容整体写回 QAAB-5 的描述字段

优化完成后,在云效中查看 QAAB-5,就会看到一个完整、可评审、可测试的需求说明。

2. 更多需求优化的示例 Prompt

  • 改写为用户故事格式
查看「实现用户登录功能」这个需求,将它改写为用户故事格式:
- 作为【谁】
- 我希望【做什么】
- 以便【达成什么价值】
并直接更新回工作项
  • 批量用户故事化技术需求
找出所有技术描述类的需求(标题以「实现」开头),将它们统一改写为用户故事格式,突出用户角色和业务价值
  • 补充验收条件
QAAB-8 缺少验收标准,请根据需求描述补充至少 5 条可量化的验收条件,
包括:
- 功能性验收
- 性能要求
- 边界条件
- 异常处理
并更新回原需求
  • 补充测试场景
查看「支持乘法运算」需求,补充完整的测试场景:
- 正常场景(正数、负数、小数)
- 边界场景(0、极大值、极小值)
- 异常场景(非法输入、溢出)
更新回原需求的验收条件部分
  • 批量为无验收条件的需求补充标准
找出所有没有验收条件的需求(描述中不包含「验收」关键词),
为每个需求根据其标题和描述自动生成 3-5 条验收标准,并写回工作项

实用场景 4:批量导入需求

当你已经有一份 Excel / CSV 需求列表时,可以直接让 AI + MCP 帮你“批量录入到云效”。

1. 从 Excel 表格导入示例

假设有一个 Excel:

image

只需要一句 Prompt:

请将「需求列表.xlsx」中的内容录入到云效 bowentestmcp 这个项目中

image

AI 的典型处理流程:

  1. 解析 Excel 结构(首行是表头:标题 / 内容 / 优先级)
  2. 将每一行映射为:

    • subject → 标题
    • description → 内容
    • priority → 优先级(高 / 中 / 低)
  3. 调用 YUNXIAO/CREATE_WORK_ITEM 创建 4 条新需求

回到云效 bowentestmcp 项目的需求列表页,就能看到刚刚导入的 4 条需求。

image

2. 更多批量导入的示例 Prompt

  • 从“产品需求.xlsx”导入
从「产品需求.xlsx」导入需求,全部创建为「产品类需求」类型,指派人统一设置为我本人
  • 指定字段映射导入
导入「backlog.xlsx」到 bowentestmcp 项目:
- 第 1 列(需求名称) → 标题
- 第 2 列(详细说明) → 描述
- 第 3 列(重要程度) → 优先级(高/中/低)
- 第 4 列(负责人姓名) → 指派人
- 第 5 列(所属模块) → 标签
  • 带层级关系导入
导入「需求层级.xlsx」,根据「父需求ID」列建立父子关系:
- 第一级:Epic / 主题需求
- 第二级:Feature / 功能需求
- 第三级:Story / 用户故事
自动建立层级关联
  • 自动识别表头并导入
分析「需求文档.xlsx」的表头结构,自动识别对应的字段映射关系,将数据导入 bowentestmcp 项目
  • 导入前先做数据校验
导入「需求池.csv」前先验证:
- 必填字段不能为空(标题、描述)
- 优先级只能是「高/中/低」
- 负责人必须是项目成员
- 标题长度不超过 50 字
验证通过后再批量创建

更多项目管理场景示例

在前面几个场景基础上,还可以进一步组合出更复杂的“项目级”能力。

1. 项目健康度检查

分析 bowentestmcp 项目健康状况:
- 统计各状态需求分布
- 检查逾期未完成的需求
- 识别长期无人认领的需求
- 分析需求平均完成周期
- 检测可能的瓶颈(某状态停留过久)
生成健康度报告

AI 可以基于 SEARCH_WORKITEMS 等接口,做出一份结构化的项目健康度分析报告。

2. 迭代规划

为即将开始的 Sprint 5 规划任务:
1. 从需求池中筛选高优先级需求
2. 智能推荐适合本迭代的需求组合
3. 自动分配给合适的成员
4. 创建迭代并关联需求

3. 迭代回顾

为刚结束的 Sprint 3 生成回顾报告:
- 完成需求数 vs 计划需求数
- 各成员完成情况统计
- 延期需求分析
- 紧急插入需求统计
- 提取改进建议

4. 工作负载分析

分析 bowentestmcp 项目团队成员工作负载:
- 统计每人当前进行中的任务数
- 计算每人的工作时长总和
- 识别负载过重或过轻的成员
- 建议任务重新分配方案

5. 需求质量评估

批量检查 xx 项目中所有「待开发」状态的需求质量:
- 描述完整性(是否包含背景、目标、验收标准)
- 验收条件清晰度(是否可测试)
- 依赖关系完整性
- 工作量评估准确性
不合格的标记为「待补充」并通知负责人

6. Bug 关联需求分析

分析 xx 项目中 Bug 与需求的关联:
- 统计每个需求关联的 Bug 数量
- 识别高缺陷率的需求
- 分析 Bug 产生的阶段(开发/测试/生产)
- 提供质量改进建议

小结

通过本文的实战演练,我们看到:当云效 MCP Server 与自动化脚本或智能体结合,它不再仅仅是一组 API,而是一种全新的研发协作范式。它将“会用云效”的人,从大量机械操作中解放出来。总结来说,MCP 为项目管理者带来了三大核心价值的转变:

  • 执行指令化: 将原本需要数十分钟的手动点击,压缩为几行指令或一句自然语言描述。
  • 经验模板化: 将个人的最佳实践与团队规范,沉淀为可复用、可共享的自动化模板。
  • 精力聚焦化: 将管理者从繁琐的工具操作中解放,回归到思考产品、业务和团队等更高价值的工作上。

云效 MCP Server 就像一套高效的“项目协作外骨骼”——它增强你的能力,放大你的效能,让你跑得更快、更远。而这,仅仅是开始。项目管理是 MCP 能力版图的第一块拼图。

在下一篇文章中,我们将深入 【代码管理】 场景,探索如何通过 MCP 实现分支自动创建、权限精细化管理、代码合规性检查等高阶玩法。

敬请期待!也欢迎你在评论区分享使用心得,或告诉我们你最希望 MCP 在哪个领域帮你实现自动化。

2026 年,智能体将在企业级应用中取得哪些实质性突破?又将如何锻造新一代从业者?点击下载《2026 年 AI 与数据发展预测》白皮书,获悉专家一手前瞻,抢先拥抱新的工作方式!

人工智能创新正在持续重塑各行业与企业级的应用场景与用户体验。各公司日益聚焦于为终端用户创造可量化的实际价值。要实现这些价值,就需要可扩展、安全可靠且与企业数据深度整合的人工智能技术。

 

在 Snowflake,我们致力于帮助客户将人工智能与机器学习的宏伟蓝图转化为现实影响。这意味着我们将开发工具置于核心位置,使开发者能够更轻松地构建可靠的智能体,加速人工智能/机器学习工作流的上线部署,并在规模化扩展时从容管控相关负载。

 

我们最新的产品创新赋予客户基于 Snowflake 平台构建可靠、企业级应用的能力。这将带来更高效的执行、更简化的运维流程,以及企业可放心投入生产环境的人工智能工具。

Snowflake Intelligence 作为即开即用的企业级智能体

Snowflake Intelligence 整合了一系列功能模块,旨在帮助企业用户快速、安全、自主地实现人工智能价值。本次更新聚焦三大核心需求:

  •  支持用户将有价值的对话输出保存为成果资产,并可将这些资产共享给其他利益相关方以支持商业决策(即将推出);

  • 通过安全的原生移动端访问,满足业务人员随时随地使用需求(即将推出);

  • 客户现可将业务人员纳入 Snowflake Intelligence 使用范畴,同时限制其对 SQL 及数据工具的访问权限。所有现有安全策略持续生效,管理员仅需通过单一用户属性即可启用该功能。

 

Snowflake Intelligence 致力于在工作发生的任何场景下提供可信洞察。其自然语言交互界面支持每位员工在 Snowflake 安全可控的平台内直接提出问题、挖掘数据表象背后的成因,并及时采取数据驱动的行动。

 

这些功能共同构筑了 Snowflake Intelligence 作为可信赖企业智能体的核心能力,在用户需要的时空节点交付关键洞察,为全组织范围内的时效性数据驱动决策提供支撑。

Artifacts:将对话转化为商业成果

Artifacts(即将开启公开预览)代表着 Snowflake Intelligence 在赋能商业用户方式上的根本性转变。

Artifacts 可将 Snowflake Intelligence 中的对话转化为可保存、可共享的输出成果,例如图表与表格,并完整保留可视化呈现、底层 SQL 及上下文元数据。

 

Artifacts 是 Snowflake Intelligence 中实现企业知识捕获、共享与执行的核心单元。用户可通过保存 Artifacts 避免重复分析工作,安全地向团队成员共享实时引用,并在上下文中探索后续问题。Artifacts 支持用户回溯已构建的内容,与他人共享,并基于可信的企业数据直接展开协作。

 

更广泛而言,Artifacts 是 Snowflake Intelligence 向终端用户交付商业洞察能力的基础架构。通过 Artifacts,Snowflake Intelligence 不再仅限于临时查询或后续追问,而是成为驱动业务发展的起点。借助 Artifacts,我们正将 Snowflake Intelligence 打造为全组织统一、可靠决策的核心枢纽。

Snowflake Intelligence 即将登陆移动端

Snowflake Intelligence 将以 iOS 移动应用程序的形式(即将进入公开预览阶段)推出,提供更优的原生移动体验。移动端访问确保企业领导者和业务用户能够全天候连接企业知识库,无论是查看核心指标、追踪趋势变化,还是在决策过程中实时跟进关键问题。

 

为提供安全易用的体验,Snowflake Intelligence 移动应用将支持基于 FaceID 的会话续期功能(即将进入公开预览阶段)。用户可通过 FaceID 进行身份验证,令牌将在后台自动刷新。刷新令牌始终保持受保护状态,绑定设备并定期轮换,在实现企业级安全管控的同时,提供流畅的消费级移动体验。

扩展访问权限:支持受限登录与 Snowflake Intelligence 专属用户

Snowflake Intelligence 现支持用户直接登录,使业务用户无需了解 Snowflake 或操作 Snowsight 即可登录平台并开始提出问题。

 

对于需要更严格管控的企业,Snowflake Intelligence 专属用户功能允许业务用户仅访问 Snowflake Intelligence,无法使用 Snowsight、SQL 接口或其他数据工具。这一设计让业务用户专注于专为其打造的交互界面,同时帮助企业统一管控使用范围、控制成本,并自动实施所有现有安全策略。

 

Snowflake Intelligence 还支持身份提供程序重定向功能。通过配置的身份提供程序(如 Okta 或 Entra ID)进行认证的用户,可获得简化的 Snowflake Intelligence 登录体验。这些功能相结合,使得在保障集中化治理控制的同时,能够轻松扩展企业内部的访问范围。

轻松构建、部署与迭代智能体体验

智能体现已成为企业工作流的核心。企业需要一个可靠、可信的体系架构,以在受管控且能跨团队、跨应用扩展的环境中,提供稳定精准的智能体验。我们很高兴宣布 Snowflake 平台上的重要创新,这些创新将帮助客户自信地构建并扩展生产级智能体。

 

现已全面推出的 Cortex Code,通过赋能各类构建者——从资深工程师到非技术团队——利用自然语言交互构建并优化智能体,全面支持这一进程。它帮助团队轻松生成合成数据,创建与调试语义视图,并快速构建和调试智能体行为,从而加速在 Snowflake AI 数据云上的生产部署。

 

即将全面推出的语义视图自动巡航功能,可助力团队自动化创建并部署生产就绪的语义视图。通过学习查询历史,语义视图自动巡航简化了建模工作流,帮助组织更快接入新用例,同时在跨团队间提供一致的洞察分析。

 

为推进智能体在组织内的广泛应用,Cortex Agent Sharing(即将正式发布)可帮助用户轻松发现、复用并规模化部署由内部团队或合作伙伴构建的智能体。该功能使企业能够统一智能体能力标准,避免重复开发,并将经过验证的智能体快速拓展至各团队,无需为不同用例重复构建。团队可通过 Snowflake Marketplace 获取各类方案,并利用合作伙伴构建的智能体加速实现业务价值。

 

通过 Agent Evaluations(即将正式发布),客户能够深入洞察智能体的推理过程、工具选择与响应生成机制,从而优化智能体行为,并在其演进过程中持续提升准确性。这种透明度有助于团队通过便捷的准确性验证与逻辑一致性检查,建立对智能体质量的信心,确保其满足生产环境要求。通过完整呈现智能体的“思考过程”,Agent Evaluations 减少了调试过程中的猜测性工作,使团队能够快速定位并修复错误或性能瓶颈。最终,通过对答案、逻辑及工具使用进行验证,企业可放心地将智能体从早期实验阶段推进为团队信赖的、可用于生产环境的成熟系统。

面向企业数据访问的模型上下文协议(Model Context Protocol)支持

Snowflake Intelligence 现已支持模型上下文协议(MCP),以简化与第三方工具及服务的集成。我们于 2025 年 10 月推出了由 Snowflake 托管的MCPserver,并在此基础上进一步推出 Snowflake MCP 客户端(即将全面上市),帮助客户以更便捷、可靠的方式连接外部数据源。

 

通过 Snowflake MCP 客户端,账户管理员可以注册预置或自定义的 MCP 服务器(例如 Atlassian、Salesforce 或 Workday),并将其直接集成至 Cortex 智能体中。开发人员可在智能体编排过程中使用 MCP 服务器,实现无缝的工具发现与调用。Snowflake 统一管理包括令牌处理在内的认证流程,并提供可观测性支持,确保集成过程安全可控。在本次发布中,Snowflake 支持在智能体调用期间完整的 MCP 工具发现功能,同时提供监控与令牌管理能力,使客户能够安全地跨系统访问并处理企业数据。

面向企业级智能体的高性能与低延迟

在生产环境中,一致性及准确性对用户体验与应用推广至关重要。Snowflake 持续投入智能体技术栈的全面优化,致力于提供响应更迅速、结果更精准且具备规模化可预测性的 AI 驱动体验。

 

Snowflake 即将推出持续学习型智能体记忆库(公共预览版),这是企业级智能体在质量层面的重大升级。该功能使智能体能够持续从跨用户的高质量历史响应中学习,从而提升回答一致性并增强可信度。同时,智能体可长期记忆个体用户的偏好与事实信息,为用户提供更加个性化的 Snowflake Intelligence 体验。

 

通过将文本转 SQL 功能深度集成至智能体编排流程,Snowflake 进一步提升了分析工作流的准确性与响应速度。用户得以更高效地访问数据,在查看 SQL 执行过程的同时透视 LLM 决策逻辑,并针对多样化工作负载灵活优化智能体行为模式。

支持智能体版本管理与成本追踪的治理机制

随着人工智能应用不断发展,企业需要具备相应的治理能力以实现规模化扩展。Snowflake 通过智能体版本管理与集成化运行监控功能,为企业提供此类治理支持。

 

智能体版本管理功能(即将开放公开预览)为 Snowflake Cortex 智能体提供 CI/CD 支持,使客户能够安全地构建、部署和迭代智能体工作负载。开发人员可创建版本快照,通过 Git 管理变更,并安全地推进或回滚部署。此外,客户即将通过使用量视图(即将正式发布)追踪 Snowflake Intelligence 与智能体的使用情况,从而获得更完善的运行状态洞察。

 

除可视化监控外,Snowflake 还支持团队主动管控 AI 成本。已正式发布的 AI_COUNT_TOKENS 函数可在执行前预估使用量,而即将发布的 AI 函数增量计量视图(即将正式发布)将为运行中的查询提供使用量与成本数据,帮助团队在执行期间实施限额管控并触发相应操作。这些功能使企业能够在维持可预测开支与运行管控的同时,实现生产环境中 AI 应用的规模化扩展。

 

通过版本管理与成本追踪相结合,团队能够在保持清晰洞察的前提下快速发展,以负责任的方式构建高性能规模化应用程序。

通过智能体工作流加速多模态机器学习模型的在线部署

在人工智能领域,传统机器学习仍然占据重要地位。我们欣然宣布,Snowflake ML 在智能体、多模态及实时工作流方面推出了全新功能。

 

我们持续投入现代化开发体验,致力于提升生产效率。新一代 Snowflake Notebooks(现已正式发布)现已成为 Snowflake Workspaces 的核心组成部分,运行于基于 Snowflake 容器运行时构建的 Jupyter 环境中。Snowflake Notebooks 使开发者能够将已有的基于 Jupyter 的笔记本、脚本及模型训练流程无缝引入 Snowflake 统一平台,实现先进的模型开发工作流。通过与 Snowsight 中的 Cortex Code 功能(即将正式发布)深度集成,Snowflake Notebooks 进一步提升了开发与迭代的效能。

 

数据科学家在开发和调试机器学习工作流时,常常面临周期冗长的问题,导致运维瓶颈以及实际投产的模型数量有限。如今,Snowflake 将 Cortex Code 集成至 Snowflake Notebooks 的机器学习工作流中,引入智能体人工智能,使其能够基于简单的自然语言提示自主迭代、优化并生成完整可执行的机器学习流水线。

 

针对实时机器学习模型,Snowflake ML 现已正式发布在线特征存储在线模型服务功能,使模型部署更加便捷。开发者现可将特征服务延迟控制在 30 毫秒内,模型服务延迟控制在 100 毫秒内,有力支持个性化推荐、欺诈检测等低延迟在线场景,且无需额外基础设施或复杂配置。此外,基于 Hugging Face 等主流多模态模型中心进行大规模推理的功能,目前已进入公开预览阶段。结合图像、视频等非结构化数据进行推理,可在 Snowflake 平台上直接实现物体检测、视觉问答和自动语音识别等多种人工智能应用,无需构建复杂流程或迁移数据。

AI 发展的未来

今日发布的多项成果,共同奠定了 Cortex Agents 作为企业级 AI 统一基础的地位。Semantic View Autopilot 助力开发者提升 Cortex Agents 的准确性,并加速推进高级用例的落地。最新的 Snowflake ML 升级,使开发者能够构建可供 Cortex Agents 直接调用的模型,从而为用户提供基于机器学习的预测与建议。在生产环境中,我们推出的 Evaluations for Cortex Agents 确保智能体输出结果既可信赖,又便于监控。

 

借助 Snowflake 平台,企业能够将 AI 智能体与应用从实验阶段推进至生产部署,并获得团队信赖、由运维人员统一管理,最终直接赋能业务成效。

行动倡议:

1. 立即开始在 Snowflake Intelligence 中创建、保存并共享各类资产,以促进协同并推动业务行动。

2. 探索与 Cortex Code 相关的发布内容。

3. 通过此篇博客,进一步了解机器学习领域的最新动态。

原文地址:https://www.snowflake.com/en/blog/building-reliable-applications/

点击链接立即报名注册:Ascent - Snowflake Platform Training - China更多 Snowflake 精彩活动请关注专区

点赞 + 关注 + 收藏 = 学会了

整理了一个NAS小专栏,有兴趣的工友可以关注一下 👉 《NAS邪修》

VERT.sh 是一款开源文件转换工具,它所有转换都在本地浏览器完成,文件(除视频外)永不上传云端,支持 n 种格式(文档、图片、音频、视频),无广告、无文件大小限制,开箱即用!

这次我使用绿联的 NAS 部署 VERT.sh,其他品牌的 NAS 只要支持 Docker 的,部署步骤都是大同小异。

首先在“文件管理”应用里找到“docker”文件夹,在里面创建一个“vert”文件夹。

打开“Docker”应用,点击左侧菜单的“项目”,创建一个新项目。

  • 项目名称:vert。
  • 存放路径:选择上一步创建的 xxx/docker/vert 文件夹。

Compose配置 输入以下代码:

services:
  vert:
    image: ghcr.io/vert-sh/vert:latest
    container_name: vert
    ports:
      - 2340:80 
    restart: unless-stopped

这里我配置了 2340 这个端口,你根据你实际情况配置吧,只要不跟其他项目的端口冲突就行。

然后等 Docker 下载镜像和构建项目,等就行,速度取决于你的网速。

项目构建完成后,点击左侧菜单”容器“这项,找到 vert 这项,点击它右侧的小箭头会弹出端口号,点击端口这个按钮。

点击端口按钮后,浏览器会新开一个窗口运行 VERT.sh。

它默认界面是英文的,点击顶部菜单的“Settings”项,找到“Language”,切换成中文就行。

回到首页可以看到 VERT.sh 支持图片、音频、文档和视频等文件的格式转换。

测试了一下,图片是可以转格式的。

但视频要传到人家的服务器转,而且还不一定成功😮‍💨

就当没转视频格式这个功能吧😤


以上就是本文的全部内容啦,有疑问可以在评论区讨论~

想了解更多NAS玩法可以关注《NAS邪修》👏

点赞 + 关注 + 收藏 = 学会了

今日速览

  1. Tinkerer Club:创客俱乐部,本地运行 AI,摆脱订阅陷阱。
  2. Agent Builder by Thesys:AI 代理能看懂图表,无需代码就能响应。
  3. Normain:从复杂文档中提取可靠见解,告别模糊摘要。
  4. Spawned:描述想法,AI 几分钟内生成可发布的应用。
  5. Video Forms:在视频里直接提问,收集精准反馈。
  6. Total addressable Market calculator:用真实数据计算市场规模,免费又靠谱。
  7. claw.fm:AI 代理当 DJ,全天候播放原创音乐。
  8. PredictLeads Technographics Dataset:追踪公司技术栈,数据来源透明。
  9. Evra:Z 世代的 AI 疗愈伴侣,随时聊聊心情。
  10. Tapfree for Android:语音键盘懂上下文,打字从此解放双手。


1. Tinkerer Club

创客们的秘密基地,帮你把技术栈牢牢握在自己手里,不再被订阅服务牵着鼻子走。

  • 加入 1000 多名开发者、黑客和自动化爱好者社区
  • 本地运行人工智能,自主托管一切工具
  • 提供私密 Discord 频道、每周情报和直播会议
  • 终身访问,享受折扣和优先工具使用权
  • 限时特价 299 元,仅剩 81 个名额

Tinkerer Club

热度:🔺437
访问官网 Product Hunt 详情


2. Agent Builder by Thesys

让 AI 代理不再只会聊天,而是能看懂界面、用图表和表单动态响应,像真人一样工作。

  • 构建智能代理,通过用户界面而非文本进行交互
  • 支持图表、卡片、表单、幻灯片和报告等响应方式
  • 无需编写代码或设置繁琐工作流程
  • 连接数据、添加指令、定制样式后即可发布分享
  • 可嵌入网站,与任何人轻松协作

Agent Builder by Thesys

热度:🔺433
访问官网 Product Hunt 详情


3. Normain

专治文档恐惧症,从海量复杂文件中挖出结构化见解,每一条都追根溯源,拒绝瞎编乱造。

  • 专注于提取复杂文档中的关键信息
  • 提供结构化且可追溯的见解,基于原始材料
  • 旨在验证和重用,而非生成不准确的聊天式摘要
  • 适合需要精准数据分析和文档整理的场景
  • 提升工作效率,减少人为错误

Normain

热度:🔺360
访问官网 Product Hunt 详情


4. Spawned

把你的创意火花变成真实产品,AI 帮你快速搭建,还能直接发布给内置观众测试反馈。

  • 描述想法,AI 在几分钟内生成生产就绪的网页应用
  • 内置用户群体,提供点赞、排行榜和实时发现功能
  • 可添加 Solana 代币,让早期支持者分享成功收益
  • 像 Lovable 一样构建,像 Product Hunt 一样发布
  • 一站式平台,从创意到成长全流程覆盖

Spawned

热度:🔺203
访问官网 Product Hunt 详情


5. Video Forms

告别视频和表单分家的尴尬,直接在片子里嵌入问题,让反馈来得更及时、更精准。

  • 在视频特定时刻添加问题,收集上下文反馈
  • 观众可根据回答跳过不感兴趣部分,提升体验
  • 收集更准确、更高质量的见解,无需离开视频
  • 适合产品演示、用户体验研究和入职培训
  • 简化流程,减少多任务处理负担

Video Forms

热度:🔺179
访问官网 Product Hunt 详情


6. Total addressable Market calculator

别再拍脑袋猜市场了,用真实公司数据算算你的蛋糕到底有多大,免费工具直接上手。

  • 使用超过 1 亿家真实公司数据计算总可寻址市场(TAM)
  • 基于理想客户特征,精准评估市场规模
  • 免费工具,无需注册,立即使用
  • 从假设转向可行动的真实公司分析
  • 帮助团队制定更靠谱的营销和增长策略

Total addressable Market calculator

热度:🔺159
访问官网 Product Hunt 详情


7. claw.fm

让 AI 代理变身音乐制作人,24 小时电台播放原创曲目,还能靠打赏和版权赚收益。

  • 全天候广播电台,所有音乐由自主 AI 代理制作
  • 代理通过程序提交音乐,获得 USDC 计的打赏
  • 收入分配:75% 归艺术家,20% 进共享版权池,5% 平台运营
  • 根据播放次数分享版权收入,激励创作
  • 内置免费音频工具,听众可打赏影响播放内容

claw.fm

热度:🔺153
访问官网 Product Hunt 详情


8. PredictLeads Technographics Dataset

一眼看穿竞争对手用了啥技术,数据来源透明,还能用 API 轻松集成到你的分析里。

  • 提供公司技术使用的结构化数据,来源包括网站、职位描述等
  • 每个检测结果带时间戳和信号,跟踪技术采用趋势
  • 支持 API、平面文件和 Webhook 访问,灵活集成
  • 提供 MCP 服务器,供 AI 代理直接调用
  • 帮助分析技术迁移和竞争格局变化

PredictLeads Technographics Dataset

热度:🔺151
访问官网 Product Hunt 详情


9. Evra

Z 世代的心理健康小助手,AI 随时在线陪你聊天倾诉,用现代方式缓解情绪压力。

  • 专为 Z 世代设计,提供 AI 驱动的心理健康支持
  • 全天候情感支持,通过聊天和语音随时随地交流
  • 帮助年轻人应对情绪问题,管理日常压力
  • 现代化疗法替代方案,无需预约等待
  • 界面友好,操作简单,适合移动端使用

Evra

热度:🔺128
访问官网 Product Hunt 详情


10. Tapfree for Android

扔掉键盘,用语音搞定所有输入,这款安卓应用能理解上下文,让你告别打字纠错的烦恼。

  • 以语音为主的安卓键盘,支持自然语音输入
  • 撰写消息、笔记和电子邮件,避免听写错误
  • 理解上下文,而不仅仅是单个单词识别
  • 减少格式尴尬和频繁修正,提升输入效率
  • 解放双手,适合多任务场景和移动办公

Tapfree for Android

热度:🔺120
访问官网 Product Hunt 详情

点赞 + 关注 + 收藏 = 学会了

整理了一个n8n小专栏,有兴趣的工友可以关注一下 👉 《n8n修炼手册》

非技术出身的工友在使用 n8n 时是否会遇到这样的困惑:爬取了一堆数据不知道存哪里,总不能每次都导出到Excel再来回导入?想让多个工作流共用一套数据,却找不到简单的方法?不想折腾MySQL、PostgreSQL这些复杂的外部数据库,也看不懂晦涩的SQL语句?

如果有以上困惑,而且你的数据结构不是那么复杂的话,可以试试 n8n 内置的 Data tables。

我用一个简单的例子介绍一下 Data tables 的用法,顺便讲讲不同格式的字段该如何转换。

我们可以在 Data tables 面板管理各个数据表,点击右上角的“Create data table”创建一个数据表。

我以“员工信息表”作为演示。

点击加号新增 namemarried

name 是“员工姓名”,Type 选择 string。

married 是“是否结婚”,Type 选择 boolean(这个类型只有“是”和“否”两个选项)。

创建一个工作流,添加要给表单节点。

只有2个字段,表单的“姓名”对应数据表里的 name;表单的“是否结婚”对应数据表里的 married

但是,数据表的 married 的类型是布尔型,也就是 true 表示已结婚,false 表示未结婚。但表单的“是否结婚”的选项却是字符串的“已结”和“未结”。这里要做一下转换。

在表单节点后面添加一个「Insert row」节点,搜 table 就能找到它。

给「Insert row」节点做以下配置。

「From list」选择刚刚创建的“员工信息”表。

「Values to insert」填入 namemarried 这两个字段。

name 这项填入 {{ $json['姓名'] }} 比较好理解,我不讲解了。

married 这项填入 {{ $json['是否结婚'] === '已结' ? true : false }},这是 JS 的三元运算符,判断上一个节点传入的“是否结婚”这项的值是否为“已结”,如果是的话就存入 true ,否则存入 false

测试一下整个工作流。

我提交了2次表单:

  • 雷猴,已结
  • 鲨鱼辣椒,未结

来到数据表就能看到这两项了。

鲨鱼辣椒突然说他今天要结婚了,作为 HR 也应该更新一下数据。

此时再提交一次表单:鲨鱼辣椒,已结。你会发现工作流又多了一条数据,这并不是我们想要的结果。

在 Data tables 里先手动删除第3项。

回到工作流这边,新增了一些节点。

  • 上面那条:

    • 「If row exists」:如果传入的“姓名”已在数据表里,就走这条。
    • 「Update row(s)」:更新表中的数据。
  • 下面那条:

    • 「If row does not exist」:如果传入的“姓名”不在数据表里,就走这条。
    • 「Insert row」:新增一条数据。

「If row exists」和「If row does not exist」的判断条件都是一样的,如下图所示。只不过这两个节点的功能不同而已。

在来看「Update row(s)」这个节点,通过 name 这个字段找到要修改的那行数据,找到后就修改 married 这列的值。

「Insert row」节点的配置不需要改变。

试试~

提交一项:鲨鱼辣椒,已婚

回到数据表这边就能看到鲨鱼辣椒的婚姻状态变成“true”了。

再提交一项:蝎子莱莱,未婚。

由于“蝎子莱莱”不在数据表里,所以走的是“新增”路线。


以上就是本文的全部内容啦,想了解更多n8n玩法欢迎关注《n8n修炼手册》👏

如果你有 NAS,我非常建议你在 NAS 上部署一套 n8n,搞搞副业也好,帮你完成工作任务也好 《『NAS』不止娱乐,NAS也是生产力,在绿联部署AI工作流工具-n8n》

点赞 + 关注 + 收藏 = 学会了