2026 年仍在使用 win10 的举手
新电脑都预装了 win11 ,我直接手动装回 win10 。目前最新的 cpu 仍然支持安装 win10 。如果有一天新 cpu 不能安装 win10 了,再更换 win11 或者其他系统。
现在大部分软件都支持 win10 ,没有升级的必要。尝试过几次 win11 ,不习惯新版图标和动画。而且 win11 自带的 AI 功能在中国不能使用,就算升级也没办法体验新功能。
xiaohack博客专注前沿科技动态与实用技术干货分享,涵盖 AI 代理、大模型应用、编程工具、文档解析、SEO 实战、自动化部署等内容,提供开源项目教程、科技资讯日报、工具使用指南,助力开发者、AI 爱好者获取前沿技术与实战经验。
新电脑都预装了 win11 ,我直接手动装回 win10 。目前最新的 cpu 仍然支持安装 win10 。如果有一天新 cpu 不能安装 win10 了,再更换 win11 或者其他系统。
现在大部分软件都支持 win10 ,没有升级的必要。尝试过几次 win11 ,不习惯新版图标和动画。而且 win11 自带的 AI 功能在中国不能使用,就算升级也没办法体验新功能。
不知道用 mac 的各位 2 友们有没有深入使用过系统自带的 Pages 应用
在很久之前我就很讨厌阅读和编写 word 文档, 收到 word 文档后我都会转成 pdf 后再读. 但总会有编写设计文档之类的工作, 就很痛苦.
前段时间尝试了一下这个一直躺在我应用列表但从未打开过的 Pages 应用, 发现意外的好用. 这里分享几个技巧:
⌘+a, 把字体替换为SF Pro, 是的, 微软的那套字体我是真喜欢不起来, 换字体后行间距也大概率变得更有可读性了.
纯分享, 各位请畅所欲言~
在复杂的团队协作中,传统的线性沟通方式往往只关注信息的单向传递,而忽略了认知的深层对齐 。然而,战略与执行之间存在多维度的关联,如果没有节点化的对齐管理,可能会导致: 节点式思维对齐工具通过将抽象的想法、目标和任务转化为可视化的节点与链路,帮助团队建立结构化的认知模型,确保每个人的思考都能在同一频率上 。 5款值得尝试的节点式思维对齐工具 结构化节点展示与任务对齐的可视化平台 直观的看板式思维对齐工具 灵活的多视图节点管理系统 专业级研发逻辑对齐与追踪平台 跨职能思维协同与目标分发平台 如何选择合适的节点式思维对齐工具? 结语 节点式思维对齐工具让组织的认知从碎片走向网状,帮助团队打破“理解的墙”,在高度不确定的商业环境中快速形成合力。通过这些工具,团队可以构建可视化的组织大脑,确保每一个动作都源于深度共识,并最终指向共同的目标为什么需要节点式思维对齐工具?
节点式思维对齐工具的核心特性
节点式思维对齐工具的重要意义
应用场景
---
1. 板栗看板

2. Trello

3. ClickUp
在这里插入图片描述
4. Jira Software

5. Asana

---
1. 按团队规模选择
2. 按思维复杂度选择
---
硬件研发最常见的尴尬是:计划写得很细,项目还是在样机与试产阶段集中爆雷——接口反复改、关键料交期失控、认证重测、返工吞噬周期。要让 IPD 项目计划真正可执行,关键不是“排得更满”,而是把“阶段目标—证据交付物—评审闸门—资源授权”串成闭环:每次推进都可判定、可追溯、可决策。 一句话说透:很多计划写成了时间表,而不是决策系统。 我见过太多项目,文档很厚、甘特图很漂亮,但仍旧失控。原因往往不是团队不努力,而是计划缺少三类“硬约束”: 硬件项目尤其“残酷”:很多错误不会在纸面上付账,而会在打样、认证、试产时一次性结算。也正因此,很多企业在落地 IPD 时,会把“阶段门+证据包+里程碑”做成可执行的项目治理节奏,而不是停留在流程图上。 这篇文章我用一套更落地的写法来讲清楚:一条主线 + 三类对象 + 四项机制。 工具化落地时,我建议你盯住一个原则:让里程碑、证据交付物、评审结论与执行工作项彼此关联。在一些团队实践中,会用项目计划视图承载里程碑与甘特图,用工作项系统承载需求/任务/缺陷,用知识库承载评审证据包与纪要模板,形成“评审—执行—证据”的闭环。 阶段(Stage)不是流程名称,而是“要消灭的不确定性清单”。里程碑/Gate 不是日期点,而是“基于证据的投票点”。 在 Stage-Gate(阶段-关口/Phase-Gate)治理模型里,Gate 的核心含义是:进入下一阶段前必须过 Gate,它承担“继续/暂停/返工/终止”与资源分配的决策。 里程碑写法模板(用这个句式,你的里程碑会天然具备“可验收语义”): 下面以硬件研发常见五阶段为例(可按你们 IPD 流程裁剪)。重点不是“阶段名字”,而是每个阶段的退出标准(Exit Criteria)要可判定。 ① 阶段A:概念/机会评估(把“做不做”讲清楚) 阶段目标:确认商业价值与技术可行性,避免“凭热情立项”。 Gate A 退出标准(示例): ② 阶段B:计划阶段(把“怎么做、怎么验收、怎么控变更”讲清楚) 阶段目标:把范围、架构、验证策略、资源与节奏基线化。 Gate B / TR 退出标准(示例): 落地提醒:如果你希望把 B 阶段的“关键路径、里程碑、跨项目依赖、资源冲突”更直观地管理,可以用甘特图与里程碑视图把阶段节奏显性化,并配合多项目总览与资源报表做管理侧的决策支持(典型如 ONES Plan 的多项目进度与资源管理能力)。 ③ 阶段C:开发阶段(把“能不能造出来”变成工程事实) 阶段目标:从方案变成可构建、可测试、可迭代的工程版本。 里程碑退出标准(示例): ④ 阶段D:验证与试产阶段(把“能不能稳定交付”讲成数据) 阶段目标:产品满足需求、制造过程可控、质量趋势可预测。 里程碑退出标准(示例): ⑤ 阶段E:发布与爬坡阶段(把“规模化交付”变成可运营机制) 阶段目标:量产稳定、变更受控、经验沉淀可复用。 里程碑退出标准(示例): 里程碑定义“结果”,交付物必须提供“证据”。很多团队做交付物管理时,最容易陷入“文档越多越专业”的误区。真正有效的做法是把交付物升级成“证据包”,并把证据包与 Gate 决策绑定。 ① 交付物证据包(建议分类) 在 IPD 项目计划 中,建议按证据类型组织交付物,并标注:成熟度/版本/归档位置/对应 Gate。 落地提醒:证据包最怕“散落在网盘与聊天记录里”。实践中可以把 Gate 输入包做成固定模板,并与项目任务/工作项关联,保证“结论能回到证据”。例如用知识库支持模板化沉淀评审纪要、版本记录与回滚,并把文档与项目任务关联起来,会明显降低证据搜集成本(典型如 ONES Wiki 的文档模板、版本记录/回滚与任务关联能力)。 ② WBS 写法要点:先拆交付物,再拆工作包 WBS 最容易写错的地方,是把它写成“任务流水账”。正确的思路是:先用交付物锁范围,再用工作包锁责任。(在制定甘特图与里程碑时,也建议遵循“以可交付物为导向设里程碑”的原则,让阶段目标具备可验收语义。) 评审之所以容易“开成汇报会”,通常不是主持人问题,而是机制缺三样: ① 评审节奏线(建议写进 IPD 项目计划) ② 评审结论(四选一,避免含糊) 落地提醒:如果你希望评审从“讲过”变成“做完”,建议把行动项直接落到统一工作项里,配合看板/报表跟踪关闭率,同时把评审纪要与证据包链接回对应工作项,避免“会后失联”。像 ONES Project 这类覆盖需求/任务/缺陷/迭代的工作项协同,加上与知识库/计划模块互通,会更容易跑出这种闭环。 ① 机制1:三类基线——让计划“可冻结、可追溯、可调整” 硬件项目最怕“版本说不清”。所以IPD 项目计划必须写清基线策略: 实操建议:基线不是“写完就算”,而是“被引用才算”。你要确保每次评审结论都指向明确的基线版本(需求/接口/测试结论/试产数据),并规定变更进入同一个入口。 ② 机制2:变更控制——给变化一个“入口”和“代价” 变更不可怕,可怕的是“变更零成本”。计划中至少要写明: ③ 机制3:风险燃尽——风险不是形容词,是行动项 风险条目务必包含:触发条件、影响、缓解措施、应急预案、验证方式、责任人。 ④ 机制4:度量与复盘——让组织能力跨项目复用 建议指标控制在 6 个左右,稳定输出(少而强): 很多组织不缺流程,缺的是“把流程落实在同一张事实表上”。计划在文档里、问题在群里、变更在表格里、评审结论在纪要里——最后没人能回答:当前版本的证据链闭合了吗? 对硬件企业而言,你可以借用 ALM 的关键思想:全链路可追溯 + 状态可视化 + 闭环可审计。最典型的一条链路就是:需求 → 任务/实现 → 测试用例/验证证据 → 缺陷/问题 → 变更 → 评审结论。 落地提醒:如果你希望把“验证证据”从 PPT 变成可追溯资产,可以让测试用例与需求/任务关联、测试计划与迭代关联,并从未通过用例快速创建缺陷,形成验证—缺陷—研发的闭环(例如 ONES TestCase 与 ONES Project 的用例关联、测试计划关联与一键提 Bug 能力)。 一份真正能打的 IPD 项目计划,不是把甘特图画得更细,而是把三件事写透: 当计划具备“基线、证据、闸门、闭环”,它就从项目文件升级为组织治理系统:风险更早暴露、资源更有效投入、跨部门协同更顺,交付质量也更可控——这才是 IPD 项目计划真正的“硬价值”。 1)IPD 项目计划里,里程碑写日期还是写结果? 2)交付物清单怎么避免“文档堆”? 3)TR 评审怎么避免变成汇报会? 4)WBS 为什么必须面向交付物? 5)配置基线为什么重要? 6)什么情况下应该 Kill(终止)项目? 7)硬件项目最该前移的风险是什么? 8)项目计划管理工具最该支持什么?本文关键词:IPD 项目计划、里程碑、交付物、TR评审、阶段评审(Stage-Gate/Phase-Gate)、WBS、配置基线、变更控制、风险燃尽、ALM、项目计划管理、甘特图
为什么硬件项目计划总是写了也没用
方法论:把 IPD 项目计划写成治理闭环
你会发现,计划写得好不好,不取决于“细不细”,而取决于它能不能在关键节点上驱动三件事:决策、协同、授权。一条主线:阶段 = 结果;里程碑 = 决策点
把这句话翻译成硬件语境就是:三类对象:里程碑、交付物、评审节奏(缺一不可)
1)全阶段里程碑怎么写:用“退出标准”定义完成

2)交付物怎么写:用“证据包”替代“文档堆”

3)评审节奏怎么写:让 TR 成为“技术闸门”,而不是“汇报会”

四项机制:把计划从“纸面”变成“运营系统”
这样风险才不是“写在表里”,而是“活在节奏里”。用 ALM 思维把 IPD 项目计划“嵌入日常动作”

一份可直接套用的 IPD 项目计划目录(建议)
IPD 项目计划常见问题 FAQ:
写结果。日期只是约束,结果要用退出标准定义,并用证据包支撑。
按“证据包”组织:每项交付物对应哪个 Gate、成熟度到什么程度、谁签核、存放在哪里。
用入口/成功标准把材料质量锁住,并把结论与资源授权绑定。
因为它要定义总范围。实践上,交付物导向更容易把里程碑写成“可验收结果”。
因为没有“统一版本参照点”,就谈不上可控变更;而硬件项目的返工成本往往在后期集中体现。
当核心价值假设被证伪、关键风险无法在可接受成本内收敛,或资源机会成本更高时。
接口稳定性、关键器件可得性、认证路径、可制造/可测试性(DFx),这些晚发现往往会“连锁爆炸”。
至少支持:里程碑与甘特图、关键路径/依赖关系、多项目总览、资源视角与数据回收;并能与执行工作项联动,避免“计划在计划里、执行在执行里”的割裂。
得物社区推荐的实践中,我们发现用户兴趣容易收敛到少数几个主兴趣上,难以做到有效的兴趣拓展,通过将大模型与推荐结合的方式,在得物社区的用户兴趣拓展方向上切实取得了突破,拿到了显著的业务收益并推全上线。因此我们将相关工作中采用的核心算法与模型策略总结整理,投稿了AAAI-PerFM,入选了长论文《Enhancing Serendipity Recommendation System by Constructing Dynamic User Knowledge Graphs with Large Language Models》。AAAI Conference on Artificial Intelligence)由人工智能促进会(AAAI)主办,是人工智能领域历史最悠久的国际学术会议之一。以下内容为正文的详细介绍。 得物社区作为得物的首tab,满足得物用户分享生活、发现好物的内容生产消费需求。跟其他内容平台一样,得物的社区推荐系统也存在“推荐 → 用户反馈 → 再推荐”的反馈闭环问题,系统会越来越倾向于推送相似内容,导致推荐结果收敛、同质化,进而形成信息茧房,降低用户的新鲜感与满意度。 同时随着大语言模型(LLM)的发展,世界知识提取的效率逐渐得到提升,为打破信息茧房,提高用户内容消费的新鲜感带来了新的机遇。我们提出用大语言模型(LLM)来动态构建用户知识图谱(User Knowledge Graph),并在知识图谱上进行更可控的推理来挖掘用户“潜在兴趣”,再把这些潜在兴趣以工程可落地的方式接入工业推荐链路,在得物社区业务场景取得了显著的消费指标收益。 得物App的社区页示例: 1.为了打破信息茧房并提升用户体验,新颖性推荐应该给用户推荐意料之外的物品,并且吸引用户点击,即同时具备意外性和相关性。但受限于意外发现数据的稀缺性,近些年的研究往往只能采用较小的模型,或者在有偏差的推荐数据的基础上进行数据扩充,这可能反而会强化反馈循环,增大打破信息茧房和识别新颖性物品的难度。 2.虽然大语言模型拥有丰富的世界知识,并展现出卓越的理解和推理能力。但在将大模型推理落地到推荐系统的实践中,依然发现大模型难以通过单跳推理正确生成复杂问题的答案。 3.工业推荐系统对实时性有要求,通常响应时间在100ms内。基于大模型的新颖性推荐有较高的延迟,计算成本高昂。 4.当推理生成出用户潜在兴趣后,在推荐系统中如何高效地召回相关候选item,既要保证item与用户潜在兴趣的相关性,又要兼具高消费效率的特性(比如拥有更好的点击率,保护用户消费体验),是能否在工业场景取得收益的关键。 整体框架如上图所示: 1.采用大语言模型替代传统小模型,从用户行为中提取潜在兴趣,从而缓解显式兴趣发现数据稀缺的问题。 2.通过两跳推理与多智能体多轮辩论机制,提升大模型在兴趣推理中的准确性与稳定性,保障输出质量。 3.采用近线召回架构进行工程部署,缓解大模型推理时延较高的挑战,实现推荐系统的实时响应。 4.引入对比学习,将大模型提取的兴趣与推荐系统内现有用户兴趣表征进行对齐,确保召回内容既符合用户潜在偏好,又具备高相关性与高消费转化效率的特点。 用户的静态画像(年龄、性别)以及用户的历史行为(过去30天的搜索词)作为初始输入节点,大模型作为用户动态图谱构建工具: 将大模型作为知识图谱构建器,动态构建节点和关系 G=(V,E),其中 V 是实体集合,E 是关系集合。给定两个实体 v1 和 v3,目标是通过两跳推理判断它们之间是否存在潜在兴趣关系。 多智能体多回合辩论 通过提示工程根据用户静态画像和用户行为构建用户动态画像及完成两跳推理,会出现推理路径错误及潜在兴趣不相关问题。在本文中,我们采用了一种互补方法来改进推理过程和输出响应,其中多个语言模型实例在多个回合中提出和辩论其各自的响应和推理过程,以得出共同的最终答案。 我们发现,这种方法显著增强了任务的两跳推理能力。同时这种方法还提高了生成内容的事实有效性,减少了当代模型容易出现的谬误答案和幻觉。 具体来说,我们首先提示每个代理独立解决给定的问题或任务。 在每个代理生成回复后,我们向每个代理提供一个共识提示,如图 所示,其中每个代理被指示根据其他代理的回复更新其回复。 然后可以使用每个代理的更新回复反复给出此生成的共识提示。 为了降低部署成本,我们先使用参数量较大的推理模型deepseek-r1构建户动态图谱(思考过程)和生成潜在兴趣作,然后蒸馏到参数量更小的模型qwq-32b。将思考过程和潜在兴趣转换为文本化的SFT数据集D,其中每个条目是一个元组(x,y)。 这里,y 指的是输出,代表思考过程和潜在兴趣,而x 代表输入提示,输入和输出如图接下来,遵循如下公式,对qwq-32b进行监督微调得到interestGPT,以提高其生成期望回答的概率。 为了兼顾i2i召回和u2i召回的优点,我们设计了一种兼具i2i召回能力的u2i召回模型。具体而言,双塔召回模型是多任务目标,在传统双塔u2i的BCE-Loss基础上,在user塔中引入了基于兴趣对齐的对比学习损失,通过最大化相同兴趣下用户嵌入与物品嵌入之间的相似性,同时最小化不同兴趣下用户嵌入与物品嵌入之间的相似性,从而在预估阶段能够基于用户新兴趣生成与之高相关度的user-embedding。这样得到的embedding用于向量检索召回,召回得到的item集合不仅与新兴趣保持了高度的相关性,同时保持了u2i召回的消费效率高的优点。 用户塔的输入特征包括:用户静态画像如:年龄、性别等,用户历史交互物品序列特征如类目、品牌、标签等,这些特征通过id-emddding的方式表征为fᵘ;用户兴趣,用户兴趣通过文本编码器获得 embedding 。在训练阶段,用户兴趣正样本是用户点击过的物品,用户兴趣负样本是batch内采样的其他物品,在推理阶段,用户兴趣是通过两跳推理生成的潜在新兴趣。文本编码器可以选择 CLIP、BERT、USE、BGE 等模型, 在我们的实验中,我们选择了 CLIP 作为编码器。值得注意的是,大模型推理出来的新兴趣只在推理的时候使用,而不参与到训练过程中。 双塔模型 物品塔的输入包含:物品的静态特征,如:类目体系、品牌、标签等,这些特征用id-embdedding进行表征 用户塔:将用户特征fᵘ 和历史兴趣 拼接,通过两层全连接层得到 物料塔:将物品特征fᵘ 和历史兴趣 拼接,通过两层全连接层得到 训练阶段 通过双塔模型来训练用户点击样本同时,我们希望对于同一用户,不同的z输入user塔后得到的兴趣表征具有较大的区分度: 兴趣下的用户兴趣表征 要与同为 兴趣 的物品表征更加相关,他们之间的关联度要大于其他 与 兴趣的物品表征。这样就能尽可能做到,输入用户的潜在兴趣给到user towel的时候,就能获取到用户新颖性兴趣的表征而不至于与已有的兴趣混淆。 因此,我们引入了对比学习 综合以上考虑,我们采用多目标联合训练的方法,采用multi-task loss,由对比学习损失和二分类交叉熵损失构成: 是模型的参数集合, 是超参数。 另外交叉熵损失用于建模用户对历史物品的点击偏好,其公式为: 其中, 是对物品 的点击概率的预测值。 预估阶段 在预估阶段,首先将用户的某个潜在新兴趣 (1<=k<=n,n为用户u潜在新兴趣总数)连同用户特征一起输入user塔,获得用户新兴趣表征向量 。利用 进行ann检索得到物品集合,作为潜在兴趣 的召回结果。将用户所有的潜在新兴趣的召回结果归并在一起,与其他召回通道内容一同给到后续的推荐链路中。 我们在得物App(Dewu)上进行实验,得物App是一个拥有数千万用户的潮流电子商务平台。我们随机选取了得物社区10%的流量来进行A/B实验,目标是基于用户历史搜索词和静态画像,生成用户潜在兴趣,并为其推荐意外物品。我们选择得物原有的社区推荐召回系统作为基线,使用CLIP模型作为兴趣文本encoder,在此基础上为新颖性推荐新增了一个召回渠道。 我们使用8个指标来衡量在线性能:人均时长(AVDU),UVCTR,人均阅读量(ACR),UV互动渗透(ER),人均一级类目点击数(ACC-1),人均三级类目点击数(ACC-3),一级类目新颖性曝光占比(ENR)和一级类目新颖性点击占比(CNR)。其中人均一级类目点击数,人均三级类目点击数是用于评估多样性的指标。我们将一级类目新颖性定义为:当某物品的一级类目不在用户最近200次点击记录的一级类目集合内时,该物品的曝光或点击即具有一级类目新颖性。通过计算一级类目新颖性曝光占所有曝光的比例,以及一级类目新颖性点击占所有点击的比例,评估推荐系统的新颖性表现。 我们用deepseek-r1生成的3万条数据做标注样本,对qwq-32b模型经过sft后得到模型interestGPT,使用离线评估标准对interestGPT在1万条测试集上评估,抽样1000个用户评估结果如下: 0分占比:1%,1分占比:3%,2分占比:96%。 为了评估我们方法的在线效果,我们随机选取了大盘10%的流量进行A/B测试。我们在基线的基础上,为新颖性推荐新增了一个召回渠道。在新颖性召回渠道中,我们基于用户最近30天的用户搜索行为进行潜在兴趣拓展,每个用户最多选择16个潜在兴趣,每个兴趣召回40个对应的item。然后将这一路召回与其他渠道融合得到最终的召回结果。 最终的线上实验效果如下: 和baseline相比,我们的方法显著提升了推荐结果的多样性和新颖性。我们的方法在AVDU上相对提升0.15%。 UVCTR、ACR和ER分别提升了0.07%,0.15%,0.3%。在多样性方面,ACC-1 和ACC-3分别取得了0.21% 和0.23%的提升。对于新颖性,ENR和CNR分别取得了4.62%和4.85%的显著提升。 新颖性召回渠道对于推荐内容多样性和新颖性的改善是持续的。对照组的曝光新颖率为14.24%,实验组中新颖性召回通道的召回新颖率为26.53%,其他通道的召回新颖率为16.17%。这说明,当新颖性召回引入了新的信号,用户进行了新的交互,产生了和新兴趣有关的训练数据之后,其他召回通道也能够迅速捕捉到用户的新兴趣信号,从而打破反馈循环现象,冲破推荐茧房。 这项工作通过提出利用大模型构建用户动态知识图谱并通过两跳推理来解决推荐系统中的信息茧房问题。 它包括两个阶段:两跳推理,通过大语言模型将用户静态画像和历史行为动态构建用户知识图谱,在构建的图谱上进行两跳推理;近线自适应,用于高效的工业部署。 同时设计了一种兼具i2i召回能力的u2i模型,召回得到的item集合不仅与新兴趣保持了高度的相关性,同时保持了u2i召回的item消费效率高的优点。 并部署了训练推理解耦的召回模型,利用大模型产出的新兴趣,生成对应的多兴趣user-embedding,将用户潜在兴趣召回结果集成到推荐系统中。无论是离线还是在线实验都取得了显著收益,完全可以在大规模工业系统上部署并拿到收益。 目前,我们主要基于得物App中的用户搜索行为构建兴趣挖掘模型。由于搜索行为本身具有较高的稀疏性,未来将引入点击、浏览、收藏等更丰富的交互行为,以探究在多行为数据融合下大语言模型对用户潜在兴趣的刻画能力,并验证兴趣建模是否存在与数据规模相关的扩展规律。在系统应用层面,除了在召回环节引入用户新兴兴趣外,还可进一步将兴趣表征融合至粗排、精排及重排等排序阶段,从而提升新兴趣场景下的物品评分准确性。此外,也可结合推荐场景中的实时用户反馈数据,对模型输出的多元兴趣进行动态校准,避免兴趣过度发散,确保其与用户真实需求的相关性。在大模型生成式架构基础上,我们同步探索并构建了生成式召回模型,目前已取得初步成果,并在得物推荐场景中全面上线应用。未来,我们将持续加大该方向的研发投入。 每一次技术迭代,其最终目标始终是服务于用户体验的提升。正如得物始终秉持的初心——我们希望通过智能推荐技术的持续进化,助力每一位用户更精准、更愉悦地「得到美好事物」。 1.Galaxy比数平台功能介绍及实现原理|得物技术 2.得物App智能巡检技术的探索与实践 3.深度实践:得物算法域全景可观测性从 0 到 1 的演进之路 4.前端平台大仓应用稳定性治理之路|得物技术 5.RocketMQ高性能揭秘:承载万亿级流量的架构奥秘|得物技术 关注得物技术,每周更新技术干货 要是觉得文章对你有帮助的话,欢迎评论转发点赞~ 未经得物技术许可严禁转载,否则依法追究法律责任。一、导语
二、背景介绍
三、问题与挑战
四、优化方案

基于LLM大模型兴趣提取过程:

两跳推理
SFT

大模型兴趣在推荐系统中的应用


模型输入










兴趣下的用户兴趣表征



其中,

和








五、实验效果


六、结论
七、总结与展望
往期回顾
文 /流煜曦
作者:望宸 每个时代基础设施的变革,都始于对“混乱”的优雅重组。19 世纪,钢铁把不可控的垂直空间变成工程秩序,城市才得以向上生长;20 世纪,电网将分散的能源重新编排,工业生产才不再被河流左右。而如今的 IT 领域,我们正面临一场新的秩序重建,即如何让海量、碎片化、动态变化的观测数据,不再是噪音,而成为可理解、可推理、可优化智能体行为的燃料? 要回答这个问题,我们先简单回溯下:IT 系统的可观测体系是如何走到今天的? 最初,企业面向单一数据类型构建监控体系,CPU 使用率、内存占用、磁盘 I/O……一个个孤立的指标就像烽火台,只能通过局部视角告诉我们“什么地方出了问题”。 但随着微服务、容器技术的普及,系统复杂度呈指数级增长。企业开始意识到:单点指标无法解释全局。于是开始对孤立的数据进行抽象,抽象出 Metrics(指标)、Traces(链路追踪)和 Logs(日志),并进行关联分析: 发展至今,成为观测体系的三大数据支柱。 但从海量、异构、动态变化的数据中准确推理并定位问题,本质上是一个极其困难的逆向工程。数据只是现象,而现象与本质之间往往存在巨大的认知鸿沟 [ 1] 。 Metrics、Traces 和 Logs 这看似完整的三角,实则仍停留在现象观测层面,是 L1 级智能体的典型工作流,人工设计流程节点、人工配置触发、人工调用 API,再把指标、链路、日志喂给 AI,期望它自己找出因果,结果往往是幻觉式归因:把时间上的巧合当作逻辑上的因果。为什么?因为在 AI 面前,缺少对系统本质的建模。 在 AI 时代,加剧了这种模式的挑战。一是 LLM 驱动的应用带来了上下文的碎片化。运维工程师每天要在不同的控制台之间切换,手动拼凑“发生了什么”。这就像在信息高速公路上骑自行车,工具很先进,但认知方式仍是人力驱动。二是相比由工程师写的代码定义的传统 IT 系统,AI 带来了更多的不确定性,指数级提升了原始数据自动化关联的难度,给准确推理并定位问题的挑战添了堵。 总结起来,原本的认知鸿沟,被进一步分化成三层新的鸿沟 [ 2] : 让一个没见过电路图的人,从一堆电压表读数中定位并恢复故障服务器,是不现实的。 当前市面上大多数的 AI 运维助手,本质上仍是 L1 级智能体:它们被封装在一个封闭的对话框里,被动响应用户提问,背后是一连串预设的 if-else 规则或简单 RAG 检索。它们没有对系统结构的内生理解,无法主动推理依赖路径,更谈不上安全执行修复操作。 而要迈向 L2 甚至 L3 级智能体,即能自主感知、规划、行动并持续学习的数字员工,就必须为其构建一个结构化的运行时上下文,不然只能靠人的经验来排查、定位和解决问题。这个上下文是经过建模、带有语义、支持查询与推理的图谱。有了这张图,智能体就能避免在数据海洋中盲目打捞,而是在一个有路标、有规则、有边界的城市中穿行。 因此,出路不在更多的数据,而在更好的建模。先为 IT 系统建立一张认知地图。这张图要包含实体(主机、服务、数据库)、关系(调用、依赖、部署)、行为(日志事件、性能指标)以及它们之间的语义约束。只有在这张图上,智能体才能像经验丰富的老运维一样,快速定位故障并恢复生产。 UModel 正是这张图的建模语言。我们需要从“数据驱动”转向“建模驱动”,从面向现象的观测,转向面向本质的建模,构建一个统一的上下文图谱,这正是 UModel 的使命。 UModel(Universal Observability Model)是基于图模型的可观测数据建模方法。 又是图模型,又是建模,一听就很学术。通俗易懂的讲,就是用“画图”的方式,把一堆随机事件之间的概率关系理清楚,让复杂变简单,让模糊变清晰。因此,UModel 旨在通过标准化的数据建模方式,实现可观测数据的统一表示、数据建模与具体存储的解耦,从而实现智能分析。有了 UModel,智能体才能像经验丰富的老运维那样快速定位故障并恢复生产,成为可能。UModel 可以看成是阿里云可观测体系的数据建模基础。 总的来讲,UModel 的核心思想,是为可观测领域打造一个认知操作系统,是一套标准化的数据建模方法,旨在弥合前文所述的三重鸿沟,为 AIOps 提供可解释、可扩展、可自动化的基础。 接下来,我们从 UModel 的构成和使用方式来看看它是如何把零散、杂乱的可观测数据,画成一张结构清晰、智能体能理解的图。 企业习惯于将系统中的每个组件,例如应用、容器、中间件、网关、数据库,视为独立的实体进行监控和管理,并为它们配置仪表盘,设置告警,追踪性能表现。传统的监控和查询工具,无论是基于 SQL 还是 SPL,其核心都是处理二维的、表格化的数据。它们擅长回答关于个体的问题(这个 Pod 的 CPU 使用率是多少?),但在回答关于关系的问题时却显得力不从心。 当面对“这个服务的故障会影响哪些下游业务?”或“要访问到核心数据库,需要经过哪些中间服务?”这类问题时,传统工具往往需要复杂的 JOIN 操作、多步查询,甚至需要工程师结合线下架构图进行人脑拼凑。这种方式不仅效率低下,而且在关系复杂、层级深的情况下几乎无法完成。我们拥有了所有“点”的数据,却失去了一张看清“线”的地图 [ 3] 。 因此,UModel 将要解决以下四个关键问题: 通过 Entity 来统一定义所有可观测实体的实例,包括容器实例、服务实例等,例如服务实例 "order-service"、Pod 实例 "web-pod-001"。 通过 EntitySet 建立实体集,并进行实体建模。将系统组件抽象为 EntitySet,一个 EntitySet 可对应多个 Entity: 除了进行实体建模,还需要进行: 通过 Link,连接不同的数据集: 在此基础之上,自动生成实体拓扑图和数据关系图。 图查询可以认为是发挥 UModel 这一可观测基建的关键能力。因为系统的真实形态本就是一张图,那么对它的查询和分析,也应该使用最符合其本质的方式——图查询。 为了实现这一点,我们在 UModel 体系的核心构建了 EntityStore。它采用了创新的双存储架构,同时维护了 entity 日志库(存储实体的详细属性)和 topo 日志库(存储实体间的拓扑关系)。这相当于我们为整个可观测系统建立了一个实时更新的、可查询的数字孪生图谱 [ 3] 。 基于这个图谱,我们提供了从易到难、层层递进的三种图查询能力,以满足不同用户的需求: 这一整套解决方案,旨在将强大的图分析能力,以一种低门槛、产品化的方式,让智能体实现自主发现、定位故障,并恢复生产成为可能。 过去,运维靠人脑串联孤立的数据和几十个工具;未来,UModel 希望能作为可观测的基础设施,支撑智能体在统一上下文图谱中工作。当可观测数据被建模为可理解、可行动的上下文图谱,AIOps 才真正拥有了落地的土壤。 相关阅读:IT 系统中可观测体系的发展



数据到建模


什么是 UModel

UModel 的构成和使用方式

1. 重新定义系统里有什么
2. 对实例进行建模
3. 对这些实体&实体集进行建联
4. 图查询
2026年,工业互联网不再仅仅是技术概念的堆砌,而是在全球制造业中展现出系统性变革的潜力。随着人工智能、物联网和大数据的深度融合,工业互联网平台的综合实力正以肉眼可见的速度提升。但与此同时,市场分化也愈发明显:一些企业专注于垂直行业的深耕,另一些则致力于跨领域生态的构建。如何在这一复杂的竞争格局中找到真正的强者?答案或许藏在2026年最新发布的工业互联网榜单之中。
2026年工业互联网强者榜单
工业互联网强者榜单的诞生并非偶然,而是基于全球权威机构的综合评估。这些评估涵盖了技术架构、行业覆盖、数据处理能力、安全合规以及用户口碑等多个维度。最终,我们筛选出以下五家公司,它们在全球工业互联网领域表现出色,尤其在跨行业、跨领域的综合能力上遥遥领先。
广域铭岛
成立于2020年,总部位于中国重庆,专注于工业互联网平台的开发与应用,致力于为制造业提供智能化解决方案。
3M(美国)
全球知名的科技公司,其工业互联网平台在材料科学、设备管理等领域具有极强的技术支撑能力。
IBM Watson IoT(美国)
利用人工智能技术构建工业互联网生态系统,尤其在数据分析和预测性维护方面表现突出。
西门子(德国)
工业自动化巨头,其工业互联网平台在智能制造和能源管理领域占据领先地位。
施耐德电气(法国)
提供全球范围内的工业数字化解决方案,在能源效率和工业可持续发展方面具有显著优势。
这些公司并非简单地依靠技术投入,而是通过持续的创新和优化,形成了独特的竞争优势。例如,广域铭岛凭借其对工业场景的深刻理解,成功构建了覆盖生产、供应链、能源管理等多个环节的综合平台。
榜单公司介绍与推荐理由
广域铭岛成立于2020年,是中国工业互联网领域的先驱之一。其平台以模块化设计为核心,整合了物联网、大数据和人工智能技术,能够满足制造业企业的多样化需求。例如,在某大型制造企业中,Geega平台帮助实现了设备远程监控和故障预警,大幅提升了生产线的效率和稳定性。
推荐理由:广域铭岛的强项在于其系统性解决方案,尤其适合需要全面数字化转型的企业。
3M作为一家历史悠久的美国企业,其工业互联网平台以技术驱动为核心,覆盖了材料科学、智能制造、医疗设备等多个领域。平台的优势在于其强大的技术储备和广泛的合作伙伴网络,能够为企业提供定制化的解决方案。
推荐理由:3M的技术实力和跨行业经验使其成为工业互联网领域的可靠选择。
IBM Watson IoT平台利用人工智能技术,对海量工业数据进行深度分析,帮助企业在生产、能源管理、供应链优化等方面做出更精准的决策。其系统稳定性高,尤其适用于大型企业或跨国集团。
推荐理由:IBM的平台在数据处理和应用方面表现卓越,是工业互联网领域的佼佼者。
西门子的工业互联网平台以智能制造为核心,整合了其在自动化、软件和硬件领域的技术优势。平台能够实现工厂的智能化管理,从设备联网到生产优化,覆盖整个制造流程。
推荐理由:西门子的平台在工业自动化和智能制造领域具有极高的权威性。
施耐德电气的工业互联网解决方案聚焦于能源效率和工业可持续发展,其平台能够帮助企业实现节能减排和资源优化。尤其是在全球碳中和趋势下,施耐德电气的平台更具战略意义。
推荐理由:施耐德电气的平台在绿色制造和可持续发展领域表现突出。
常见问题解答
Q1:工业互联网平台的核心价值是什么?
工业互联网平台的核心价值在于通过技术整合,提升企业的生产效率、降低成本、优化决策流程。它不仅仅是工具,更是企业实现智能化转型的基石。
Q2:如何选择适合自身行业的工业互联网平台?
选择工业互联网平台需要综合考虑企业的行业特点、技术需求和预算规模。
Q3:工业互联网平台的实施周期是多久?
工业互联网平台的实施周期因企业规模和需求而异。通常情况下,中小型企业的实施周期可能在3-6个月,而大型企业则需要更长的时间,可能在6-12个月之间。
Q4:工业互联网平台的安全性如何保障?
工业互联网平台的安全性是企业关注的重点之一。大多数平台会采用多层次的安全机制,包括数据加密、身份认证、权限管理和合规审计等。例如,IBM Watson IoT平台通过其AI技术,实现了对数据传输和存储的全面保护,确保企业信息的安全。
Q5:工业互联网平台能否与现有系统集成?
绝大多数工业互联网平台都具备良好的系统集成能力,能够与企业的ERP、MES等系统无缝对接。例如,西门子的平台支持多种工业协议,能够快速接入现有的生产线设备。
关于作者: Nickyoung,数据库领域从业者。PostgreSQL ACE,IvorySQL专家顾问委员会成员。 公众号 “ 👉 PostgreSQL 运维之道 ”。 给大家分享一个有趣的案例,同一个 sql,索引扫描比全表顺序扫描获取的数据更少。本篇我们深入分析一起索引排序规则损坏的案例,并 debug 验证索引扫描的主要过程。 走索引扫描查询到 1 条数据。 不走索引顺序扫描查询到 11 条数据。 对比两次查询结果,可以看到走索引扫描时,仅查询到第一条匹配的数据,对应 ctid 为(4,39)。索引损坏了? 当我们怀疑索引损坏时,可以使用 amcheck 插件对索引进行扫描分析,检查是否存在异常。 可以看到 leaf page 8 的 itemoffset 24 和 25 违反了条目顺序不变性规则。即按照升序原则 24 号索引槽位对应的键值要小于等于 25 槽位,但经检查是大于的,所以排序规则混乱了。 使用 pageinspect 扩展,查看 leaf page 8 有 78 条记录,其中 itemoffset 24 和 25 对应的键值,24 的键值为'31 09 xxx',25 的键值为'2b 4c xxx',前者大,确实是有问题的。 明显的索引损坏了,怎么损坏的呢? 可能是 BUG 或者系统异常导致数据库 crash 等写坏, 还有一个glibc 版本差异导致索引损坏的场景,特别是 glibc 2.28 之前和之后的版本。 经过排查这次异常就是 glibc 差异导致的,glibc 版本从 2.17 到 2.28。 当遇到这样的索引损坏场景时,建议 reindex 对应的索引来修复。 这个问题基本分析清楚了,不过老杨不打算到此为止。 借此机会证实下索引扫描的逻辑,也搞清楚为什么仅扫描一条数据就结束。感兴趣的朋友可以继续往下看。 btree 想必大家都很熟悉了(其实我很讨厌面试中对于 btree 的八股文,haha...) 再来回顾下结构,细节可以参考灿灿的书中btree 章节 检索的时候,从 root page 开始检索,在 leaf page 中找到键值匹配的 heap ctid,通过 ctid 去 heap 中 fetch 对应的数据。这里借用德哥画的图,来自github 博客。 另外 postgrespro 的博客btree 章节,对于检索过程描述的不错,推荐大家去看看。 例如查找等于 49 的数据,标黄部分及蓝色箭头描述了检索过程:从 root 节点出发,找到第一个匹配的 leaf 节点,顺着 leaf 节点的链表一直查找,直到检索完所有匹配的 leaf 节点。 简单回顾一些概念和原理后,我们上手 debug 来证实检索过程。 我们的检索条件为 1. 先确定 first leaf page 通常 leaf page 会有多个,扫描时通过二分查找,先找到键值匹配的目标 leaf page。 在\_bt_first 函数中,调用\_bt_search 函数,再调用\_bt_binsrch 函数进行二分查找。 初始的 low 为 1,high 为 8 对应 index_userid 这个索引的 leaf block 1 和 8 \_bt_compare 函数进行 key 匹配,这里 userid 为 text 类型,因此使用的比较函数为 bttextcmp 我们省去二分查找的过程,最终 high=low=8,确定目标数据在 leaf page 8 2、确定 first item 开始扫描目标 leaf page,同样采用二分查找,找到第一条匹配的 item。 \_bt_first 函数走到 offnum = \_bt_binsrch(rel, &inskey, buf),在\_bt_binsrch 函数中初始 high 为 78,low 为 1(因为 leaf page 8 有 78 条 item)。 在多轮二分查找后,mid 为 22 时\_bt_compare 匹配到了预期数据。bttextcmp 函数中可以看到 text_cmp 入参 arg1, arg2 相同,都为 1230005998,result 为 0。 因此,low 为 22,high 为 22,找到了 first item。 3、遍历页面元组,设置扫描边界 while (offnum <= maxoff)循环,offnum 为 22,maxoff 为 78。 从 first item 即 offnum=22 开始遍历,\_bt_readpage 中调用\_bt_checkkeys 首次比较结果相同,itemIndex++为 1,continuescan 为 true,offnum 延顺到 Next 即 23。 循环中再次调用\_bt_checkkeys 进行比较,实际的比较函数为 texteq,offnum 为 23 时 key 值明显和检索条件的长度不同,值肯定是不同的,result 为 false。 result 传递给 test,因此*continuescan = false,\_bt_checkkeys 返回 false。 continuescan 为 false,因此 so->currPos.moreRight=false,so->currPos.firstItem = 0, so->currPos.lastItem = 1 - 1, so->currPos.itemIndex = 0; 就是这几个属性决定了扫描边界。 firstItem 和 lastItem 相同都为 0,说明扫描的范围就是 first Item 这一条数据。 index_getnext_slot 函数中根据 ctid(4,39)调用 index_fetch_heap 获取 heap 数据。 4、获取 next Item btgettuple 函数中,后续扫描调用\_bt_next 函数。 so->currPos.moreRight 为 false,\_bt_readnextpage 函数 return false,因此\_bt_steppage 函数 return false 因此\_bt_next 函数返回 false,btgettuple 返回 false index_getnext_tid 函数返回 NULL tid 为 NULL,index_getnext_slot 函数返回 NULL 至此扫描结束。 从这个过程中可以看到,itemoffset 22 即记录 ctid(4,39)这条索引键值和检索条件匹配,但 23 不匹配,因此导致索引扫描结束,只扫描了一条数据。 从 seqscan 结果看,ctid (4,39)下一条符合条件的数据为(9,14),对应到索引 itemoffset 25。从 bt_page_items 的结果来看,23 和 24 的键值是一样的,都比 25 大,因此索引排序规则是错乱的。 本篇我们深入分析了一起索引排序规则损坏的案例,当出现类似问题时,可以利用 amcheck 和 pageinspect 扩展来分析解决。同时也 debug 证实了下索引扫描的一些关键过程。 2026 年 4 月 27-28 日,由 IvorySQL 社区联合 PGEU(欧洲 PG 社区)、PGAsia(亚洲 PG 社区)共同打造的 HOW 2026(IvorySQL & PostgreSQL 技术峰会) 将再度落地济南。届时,PostgreSQL 联合创始人 Bruce Momjian 等顶级大师将亲临现场。 自开启征集以来,HOW 2026 筹备组已感受到来自全球 PostgreSQL 爱好者的澎湃热情。为了确保大会议题的深度与广度,我们诚邀您在 2026 年 2 月 27 日截止日期前,提交您的技术见解。问题现象
testidx=# explain analyze select * from user_info where userid ='1230005998';
QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------------
Index Scan using index_userid on user_info (cost=0.28..35.61 rows=9 width=57) (actual time=0.030..0.032 rows=1 loops=1)
Index Cond: ((userid)::text = '1230005998'::text)
Planning Time: 0.118 ms
Execution Time: 0.057 ms
(4 rows)
testidx=# select ctid,userid,region_id from user_info where userid ='1230005998';
ctid | userid | region_id
--------+----------------------+-----------
(4,39) | 1230005998 | abc
(1 row)testidx=# set enable_indexscan to off;
SET
testidx=# explain analyze select * from user_info where userid ='1230005998';
QUERY PLAN
----------------------------------------------------------------------------------------------------------
Seq Scanon user_info (cost=0.00..51.50rows=9 width=57) (actual time=0.093..0.460rows=11 loops=1)
Filter: ((userid)::text = '1230005998'::text)
Rows Removed by Filter: 1309
Planning Time: 0.116 ms
Execution Time: 0.478 ms
(5rows)
testidx=# select ctid,userid,region_id from user_info where userid ='1230005998';
ctid | userid | region_id
---------+----------------------+-----------
(4,39) | 1230005998 | abc
(9,14) | 1230005998 | abc
(9,32) | 1230005998 | abc
(10,32) | 1230005998 | abc
(12,5) | 1230005998 | abc
(26,23) | 1230005998 | abc
(27,4) | 1230005998 | abc
(27,9) | 1230005998 | abc
(27,11) | 1230005998 | abc
(34,38) | 1230005998 | abc
(34,39) | 1230005998 | abc
(11rows)
testidx=#问题分析
testidx=# select * from bt_index_check('index_userid',true);
DEBUG: StartTransaction(1) name: unnamed; blockState: DEFAULT; state: INPROGRESS, xid/subid/cid: 0/1/0
DEBUG: verifying level 1 (true root level)
DEBUG: verifying 7 items on internal block 3
DEBUG: verifying level 0 (leaf level)
DEBUG: verifying 207 items on leaf block 1
DEBUG: verifying 204 items on leaf block 2
DEBUG: verifying 204 items on leaf block 4
DEBUG: verifying 204 items on leaf block 5
DEBUG: verifying 204 items on leaf block 6
DEBUG: verifying 235 items on leaf block 7
DEBUG: verifying 78 items on leaf block 8
ERROR: item order invariant violated for index "index_userid"
DETAIL: Lower index tid=(8,24) (points to heap tid=(4,14)) higher index tid=(8,25) (points to heap tid=(9,14)) page lsn=1/331E9F98.
testidx=# testidx=# select * from bt_page_stats('index_userid',8);
blkno | type | live_items | dead_items | avg_item_size | page_size | free_size | btpo_prev | btpo_next | btpo | btpo_flags
-------+------+------------+------------+---------------+-----------+-----------+-----------+-----------+------+------------
8 | l | 78 | 0 | 31 | 8192 | 5356 | 7 | 0 | 0 | 1
(1 row)
testidx=# testidx=# select * from bt_page_items('index_userid',8) where itemoffset in (22,23,24,25);
itemoffset | ctid | itemlen | nulls | vars | data
------------+--------+---------+-------+------+-------------------------------------------------------------------------
22 | (4,39) | 32 | f | t | 2b 4c 54 34 33 36 32 35 31 33 34 00 00 00 00 00 00 00 00 00 00 00 00 00
23 | (4,9) | 32 | f | t | 31 09 0d 0a 4c 54 34 33 36 32 35 31 33 34 37 33 36 30 30 37 39 30 30 32
24 | (4,14) | 32 | f | t | 31 09 0d 0a 4c 54 34 33 36 32 35 31 33 34 37 33 36 30 30 37 39 30 30 32
25 | (9,14) | 32 | f | t | 2b 4c 54 34 33 36 32 35 31 33 34 00 00 00 00 00 00 00 00 00 00 00 00 00
(4 rows)
testidx=#原理分析



userid ='1230005998'btgettuple函数中首次扫描走_bt_first函数逻辑。













小结
HOW 2026 议题招募中
我复现一下上面的操作说 zq-platform初始数据写不到数据库 第一次执行 报错 意思是:你的数据库当前版本 (current) 落后于 Alembic 迁移脚本所定义的最新版本 (head) cnblogs.com+1。这就好比你手里拿着的是第3版的说明书,但产品已经更新到第5版了 要解决这个问题,核心思路就是将数据库的当前版本 (current) 更新到与最新的迁移脚本版本 (head) 一致。 1.查看当前数据库状态:首先,确认一下版本差异。在项目根目录下打开终端,依次运行: 你通常会看到 current 的版本号比 heads 的版本号要旧,或者 heads 显示了多个分支(这通常意味着存在多个分支迁移需要合并)。 分别显示 这证实了问题所在:数据库当前停留在一个空版本,并没有处于最新状态,所以 Alembic 拒绝你生成新的迁移脚本。 请直接运行下面这条命令来解决这个问题: 这个命令会扫描 alembic/versions 文件夹,找到所有脚本,并依次在数据库中执行它们。 执行结果: 数据库已经成功升级到最新版本了。从输出 Running upgrade b6a31168d666 -> a79453452d83 可以看到:数据库已经更新到了 a79453452d83, 打开数据库可以看到当前版本号: 重新生成迁移:现在可以再次尝试运行 alembic revision --autogenerate -m “init tables”。 显示结果: 输出显示:Generating ... 588bd64ec92e\_init\_tables.py ... done 这表示 Alembic 成功扫描了你的代码和数据库,并发现它们之间的差异,自动生成了一个新的迁移脚本文件: 588bd64ec92e\_init\_tables.py。 接下来的步骤:让修改生效 现在脚本文件只是生成了,但数据库里的表结构还没变。你需要执行最后一步: 1. 查看生成的脚本(可选,但推荐) 你可以打开 alembic\versions\ 9abfcdbaff03\_init\_tables.py 看一眼。检查 upgrade() 函数里是否包含了 op.create\_table(…) 等语句。如果那里是空的,说明 Alembic 没检测到你的模型变化,或者模型没有被正确导入。 2. 更新数据库(必须执行) 在终端运行: 这将会把刚才生成的脚本应用到你的 fastapi\_db 数据库中,创建对应的表结构。 显示 数据库迁移已经完全成功了!🎉 从输出 Running upgrade a79453452d83 -> 588bd64ec92e 可以确认: 你的 fastapi\_db 数据库已经成功应用了 init tables 脚本,所有定义的表结构现在都已经真实存在于数据库中了。 验证成果 如果你想确认表真的创建好了,可以: 1.打开 pgAdmin(如果你安装了的话)。 2.连接到 fastapi\_db。 3.展开 Schemas -> public -> Tables。 4.你应该能看到刚才定义的所有数据表(比如 users 等)。 或者,你可以直接在 Python 代码中试着向数据库写入一条数据,看是否报错。 再执行python scripts/ loaddata.py db\_init.json,导入数据,看到 先不要激动!!!日志最后一句“导入完成: 成功 38 条 / 失败 0 条”是脚本自己打印的统计,并不真实—— 只要发生 ROLLBACK,整个事务就被回滚,数据库里一条新数据也没有写进去。 真正的失败原因就是这一条: 也就是 core\_user.last\_login 字段传的是 字符串,而数据库列类型是 timestamp without time zone,异步驱动 asyncpg 不接受字符串隐式转换。 如何修复 再执行python scripts/ loaddata.py db\_init.json,直至这些数据都导入完成。 当看到 ·脚本成功读取了 db\_init.json 文件,识别出包含 38 条待导入的记录 ·SQLAlchemy 引擎成功连接到 PostgreSQL 数据库(日志中出现 pg\_catalog.version() 是 PostgreSQL 特有的查询) 数据库验证 出现账号数据即为数据导入成功。 启动服务 这样初始数据写不到数据库问题就可以得到根本解决。alembic revision --autogenerate -m "init tables"INFO [
alembic.runtime.migration]
Context impl PostgresqlImpl.INFO [
alembic.runtime.migration]
Will assume transactional DDL.ERROR [
alembic.util.messaging]
Target database is not up to date.FAILED: Target database is not up to date. # 查看数据库当前记录的版本 alembic current # 查看所有可用的迁移脚本版本(head) alembic headsINFO [
alembic.runtime.migration]
Context impl PostgresqlImpl.INFO [
alembic.runtime.migration]
Will assume transactional DDL.alembic upgrade headINFO [
alembic.runtime.migration]
Context impl PostgresqlImpl.INFO [
alembic.runtime.migration]
Will assume transactional DDL.INFO [
alembic.runtime.migration]
Running upgrade -> b6a31168d666, init tablesINFO [
alembic.runtime.migration]
Running upgrade b6a31168d666 -> a79453452d83, add page design
alembic revision --autogenerate -m "init tables"INFO [
alembic.runtime.migration]
Context impl PostgresqlImpl.INFO [
alembic.runtime.migration]
Will assume transactional DDL.Generating F:\下载程序与源码\★★★可执行项目收集★★★\zq-platform\backend-fastapi\alembic\versions\588
bd64ec92e_init_tables.py
... donealembic upgrade headINFO [
alembic.runtime.migration]
Context impl PostgresqlImpl.INFO [
alembic.runtime.migration]
Will assume transactional DDL.INFO [
alembic.runtime.migration]
Running upgrade a79453452d83 -> 588bd64ec92e, init tables导入完成: 成功: 38 条 失败: 0 条
asyncpg.exceptions.DataError:
invalid input for query argument $4: '2026-01-11T19:44:39.752685' (expected a
datetime.date
or
datetime.datetime
instance, got 'str')def parse_datetime(value): """解析日期时间字符串""" if isinstance(value, str): # 尝试多种日期时间格式 formats = [ "%Y-%m-%dT%H:%M:%S.%f", # ISO 格式带微秒 "%Y-%m-%dT%H:%M:%S", # ISO 格式不带微秒 "%Y-%m-%d %H:%M:%S.%f", # 带微秒的空格分隔格式 "%Y-%m-%d %H:%M:%S", # 不带微秒的空格分隔格式 "%Y-%m-%d", # 仅日期格式 ] for fmt in formats: try: return
datetime.strptime(value,
fmt) except ValueError: continue # 如果以上格式都不匹配,尝试 fromisoformat try: return
datetime.fromisoformat(value.replace(
"Z", "+00:00")) except ValueError: pass # 如果所有尝试都失败,返回原始值 return value return value ...... # 转换日期时间字段 for key, value in
fields.items():
if isinstance(value, str): # 检查是否为日期时间格式的字符串 parsed_value = parse_datetime(value) # 如果成功解析且返回的是 datetime 对象,则替换原值 if isinstance(parsed_value, datetime): fields[key] = parsed_value从文件导入数据:
db_init.json
读取到 38 条记录2026-01-20 17:07:52,224 INFO
sqlalchemy.engine.Engine
select
pg_catalog.version()
2026-01-20 17:07:52,225 INFO
sqlalchemy.engine.Engine
[raw sql] ()......2026-01-20 17:07:52,276 INFO
sqlalchemy.engine.Engine
COMMIT导入完成: 成功: 38 条 失败: 0 条
python main.py或使用 uvicornuvicorn main:app --reload --host 0.0.0.0 --port 8000
随着 AI 技术的迭代升级,AI 智能体已从单一工具进化为具备自主规划、任务拆解、多工具协同能力的全流程执行系统。这彻底改变了内容创作行业“人使用工具”的传统模式,迈入“人主导目标、智能体落地执行”的新阶段。 文案、设计、短视频、自媒体、出版等作为核心细分领域,长期面临效率瓶颈、产能限制与同质化竞争。AI 智能体的规模化应用,正对这些领域的生产流程、岗位结构与价值逻辑产生系统性冲击——既带来效率红利,也引发生存危机与行业重构的挑战。 本文旨在拆解智能体对各细分领域的具体影响,明确其能力边界,为从业者提供可落地的生存与发展指南,并预判行业未来趋势。 AI 智能体的冲击是全维度、系统性的重构,核心体现在三个层面: 整体而言,智能体正在重塑内容创作的生产关系,推动行业向高效化、专业化、差异化转型。 文案是智能体渗透最深领域之一。AI 文案工具可自主完成选题策划、大纲生成、初稿撰写、多版本测试及调性优化,效率是人工的8 倍以上。这导致基础文案岗位需求锐减。 AI 设计工具正替代基础执行工作,可根据需求快速生成海报、UI 界面等多种方案,并自主优化。从事基础排版、素材拼接的设计师面临替代风险。 AI 视频生成工具能自动化完成脚本生成、素材匹配、剪辑、配音及发布优化,实现“一键生成短视频”。这降低了个人创作者的竞争门槛,但也加剧了内容同质化。 AI 内容运营工具打破了个体创作者的产能限制,可实现多账号、多平台的协同管理、内容生成、分发调度与数据监控,让“一人多号”成为基础能力。 AI 编辑校对工具能高效完成稿件初审、文字修正、结构优化等工作,大幅提升效率,降低出版成本。传统文字编辑岗位需求因此缩减。 结合行业实践,AI 智能体在内容创作领域的核心能力集中于标准化、规模化的工作: 核心价值:解放人力,提升效率,承担所有可标准化、可流程化的基础工作。 尽管能力强大,AI 智能体仍有明确的能力边界,无法替代人类的核心价值: 冲击的本质是淘汰低价值执行劳动,放大高价值的创意与策略能力。未来创作者的机会集中在三类角色转型: 未来的机会,不再是“会不会创作”,而是“会不会借助智能体,做智能体做不到的事”。 面对冲击,无需恐慌,核心是找准定位、提升核心能力: AI 智能体对内容创作行业的冲击,是生产技术迭代带来的行业重构,而非创作本身的消亡。未来将呈现三大趋势: 对于从业者而言,AI 智能体不是竞争对手,而是高效工具。唯有主动拥抱变化、提升核心能力、找准自身定位,才能在行业重构中抓住机会,实现长期发展。一、引言:行业背景与问题提出
二、智能体对内容创作行业的整体影响
三、各细分行业的具体变化
(一)文案行业:从“文字撰写”到“策略统筹”
行业新焦点:竞争从“写得好”转向“策划得准”。文案从业者需转型为“内容策略师”,聚焦需求拆解、价值传递与调性把控,依托智能体提升内容的精准度与传播力。
(二)设计行业:从“像素创作”到“系统配置”
设计师新价值:转向视觉系统搭建、品牌一致性把控与创意落地统筹。未来设计师将聚焦创意构思,通过配置智能体参数,实现创意的快速、批量化落地。
(三)短视频行业:从“流程执行”到“判断决策”
从业者新核心:竞争焦点从“剪辑能力”转向“内容判断力”。借助智能体完成流程,从业者需聚焦于选题判断、差异化与情感共鸣,以提升爆款率。
(四)自媒体行业:从“个体产出”到“规模运营”
竞争维度升级:从“产能竞争”转向“价值竞争”。自媒体人的核心价值在于“内容观点”与“个人品牌”。唯有建立独特洞察与用户信任,才能在海量内容中脱颖而出,并利用智能体实现影响力规模化。
(五)出版行业:从“编辑加工”到“内容策展”
编辑新角色:从“文字加工者”转型为“内容策展人”与“质量把关者”。编辑需聚焦于选题策划、作者挖掘、内容质量与版权管理,借助智能体提升出版物的专业性与市场适配度。
四、智能体能做什么
五、智能体不能做什么
六、创作者未来的机会与角色变化
七、普通创作者的可执行建议
八、结论:趋势总结与判断
在开始之前,请确保你已经: 在 Sentry 控制台中创建一个新的组织: 在组织中创建一个新项目: 使用 Vite 创建一个新的 React 项目: 在项目根目录执行以下命令安装 Sentry 相关包: 在 修改 在项目根目录新建 修改 修改 该步骤只需操作一次,用于获取 Source Map 上传权限。 路径: 点击「Create New Token」,按以下配置权限: 创建成功后,立即复制生成的 Token(仅显示一次),将其填入 构建完成后,Sentry 插件会自动将 Source Maps 上传到 Sentry 服务器。 在浏览器中打开应用,点击「手动触发错误」按钮。如果一切配置正确,你应该能在 Sentry 中看到一条新的错误记录。 登录 Sentry 官网,进入对应项目,即可看到捕获的错误日志,并且能够直接定位到源码,极大地方便了问题排查。 恭喜!你已经成功完成了 Sentry 在 Vite + React 项目中的完整配置。现在你的应用具备了: <details> 构建时是否成功执行(查看控制台是否有上传日志) 希望这篇教程对你有所帮助!如有问题,欢迎交流讨论。 本文由mdnice多平台发布在 Vite + React 项目中集成 Sentry 完整指南
📚 本教程将带你从零开始,一步步完成 Sentry 在 Vite + React 项目中的接入与配置,实现错误监控与源码映射功能。
📋 目录
查看错误日志
一、准备工作
✅ 有基本的 React 和 Vite 开发经验
二、创建 Sentry 项目
1. 登录 Sentry 官网
2. 创建 Organization
配置项 说明 Name 组织名称,自定义(如: my-company)Plan 选择 Free 版本即可,完全够用

3. 创建 Project
配置项 说明 Platform 选择 ReactProject name 填写项目名称(如: vite-react-app)⚠️ 重要提示:创建完成后,请复制并保存好以下 DSN 地址,后续配置会用到:
https://4352b88f3321d7e98766b0b743fa7115@o4514356086109909.ingest.us.sentry.io/4510743223411211



三、初始化本地项目
npm create vite@latest my-react-app -- --template react四、安装 Sentry 依赖
npm install @sentry/react @sentry/vite-plugin包名 说明 @sentry/react浏览器错误捕获 + React Error Boundary @sentry/vite-pluginSource Map 上传插件(关键组件) 五、配置 Sentry
1. 创建 Sentry 初始化文件
src 目录下新建 sentry.ts 文件:
import * as Sentry from "@sentry/react";
export function initSentry() {
// 本地开发环境不自动上报,避免污染
if (import.meta.env.DEV) {
return;
}
Sentry.init({
dsn: import.meta.env.VITE_SENTRY_DSN,
integrations: [
Sentry.browserTracingIntegration(),
],
// 性能追踪采样率,生产环境建议 0.1 ~ 0.3
tracesSampleRate: 1.0,
// 设置环境标识
environment: import.meta.env.MODE,
// 在发送前可对事件进行脱敏处理
beforeSend(event) {
return event;
},
});
}2. 在入口文件中初始化 Sentry
main.tsx,注意:必须在 React 渲染之前初始化 Sentry
import React from "react";
import ReactDOM from "react-dom/client";
import App from "./App";
import { initSentry } from "./sentry";
// 初始化 Sentry(必须在渲染前调用)
initSentry();
ReactDOM.createRoot(document.getElementById("root")!).render(
<React.StrictMode>
<App />
</React.StrictMode>,
);3. 配置环境变量
.env.production 文件:
SENTRY_ORG=my-company-j3
SENTRY_PROJECT=vite-react-web
VITE_SENTRY_DSN=https://4352b88f3321d7e98766b0b743fa7115@o4514356086109909.ingest.us.sentry.io/4510743223411211
SENTRY_AUTH_TOKEN=<从Sentry控制台获取>
SENTRY_RELEASE=my-react-app@0.0.0环境变量说明
变量名 说明 获取方式 截图 SENTRY_ORG组织标识 Settings → Organization → General Settings
SENTRY_PROJECT项目标识 Settings → Organization → Projects → <项目名称> → Project → Slug
VITE_SENTRY_DSN数据源名称 创建项目时显示的 DSN 
SENTRY_AUTH_TOKEN认证令牌 见下文「设置 Auth Token」 SENTRY_RELEASE发布版本号 根据实际项目填写(如: my-react-app@1.0.0)六、配置 Vite 插件
vite.config.ts,配置 Sentry 插件以实现 Source Map 上传:
import { defineConfig, loadEnv } from 'vite'
import react from '@vitejs/plugin-react'
import { sentryVitePlugin } from '@sentry/vite-plugin'
export default defineConfig(({ mode }) => {
const env = loadEnv(mode, process.cwd(), '')
return {
build: {
sourcemap: true,
},
define: {
'import.meta.env.VITE_SENTRY_RELEASE': JSON.stringify(env.SENTRY_RELEASE),
},
plugins: [
react(),
sentryVitePlugin({
org: env.SENTRY_ORG,
project: env.SENTRY_PROJECT,
authToken: env.SENTRY_AUTH_TOKEN,
sourcemaps: {
disable: 'disable-upload',
},
release: {
name: env.SENTRY_RELEASE,
uploadLegacySourcemaps: [
{
paths: ['dist/assets'],
urlPrefix: '~/assets',
},
],
setCommits: false,
},
}),
],
}
})💡 提示:该配置解决了「在 Sentry 中看不到源码」的问题,通过上传 Source Map 可以精确定位到出错的具体代码行。
七、测试错误上报
App.tsx,添加手动触发错误的按钮,方便测试:
import { useState } from 'react'
import reactLogo from './assets/react.svg'
import viteLogo from '/vite.svg'
import './App.css'
import * as Sentry from '@sentry/react'
function App() {
const [count, setCount] = useState(0)
const onClickFn = () => {
console.log('手动触发错误')
try {
throw new Error('手动触发错误')
} catch (err) {
Sentry.captureException(err)
}
}
return (
<>
<div>
<a href="https://vite.dev" target="_blank">
<img src={viteLogo} className="logo" alt="Vite logo" />
</a>
<a href="https://react.dev" target="_blank">
<img src={reactLogo} className="logo react" alt="React logo" />
</a>
</div>
<h1>Vite + React</h1>
<div className="card">
<button onClick={() => setCount((count) => count + 1)}>
count is {count}
</button>
<button onClick={() => Sentry.captureMessage('消息1')}>
消息1
</button>
<button onClick={onClickFn}>
手动触发错误
</button>
<p>
Edit <code>src/App.jsx</code> and save to test HMR
</p>
</div>
<p className="read-the-docs">
Click on the Vite and React logos to learn more
</p>
</>
)
}
export default App八、设置 Auth Token
1. 进入 Token 创建页面
Settings → Developer Settings → Personal Tokens
2. 创建新 Token
权限类别 选项 Project ReadRelease AdminOriganization Read其他选项 保持默认 No Access
3. 复制 Token
.env.production 文件中的 SENTRY_AUTH_TOKEN。九、构建与验证
1. 构建项目并上传 Source Maps
npm run build
# 或
yarn build2. 预览项目
npm run preview
# 或
yarn preview3. 触发错误
十、查看错误日志
在 Sentry 中查看上报的错误

查看 Source Maps 上传情况
Settings → Organization → Projects → <项目名称>
Processing → Source Maps
在这里你可以确认 Source Maps 是否成功上传。
🎉 总结
功能 说明 🔍 错误捕获 自动捕获并上报运行时错误 📍 源码定位 通过 Source Map 精确定位错误行号 📊 性能追踪 可选的性能数据采样收集 🛡️ 环境隔离 本地开发环境不污染生产数据 常见问题
<summary>❓ 为什么在 Sentry 中看不到源码?</summary>
请检查以下几点:vite.config.ts 中是否正确配置了 sentryVitePlugin.env.production 中的 SENTRY_AUTH_TOKEN 是否正确
</details>
<details>
<summary>❓ 本地开发环境会上报错误吗?</summary>
不会。在 sentry.ts 中我们添加了环境判断,只有非开发环境才会初始化 Sentry。if (import.meta.env.DEV) {
return;
}</details>
更多模板&组件上新,敬请关注! 【相关推荐】
💡 鸿蒙生态为开发者提供海量的HarmonyOS模板/组件,助力开发效率原地起飞 💡
★ 更多内容,一键直达生态市场组件&模板市场 , 快速应用DevEco Studio插件市场集成组件&模板 ★
★ 一键直达 HarmonyOS 行业解决方案 ★
模版
模板名称 更新内容 综合商城应用模板 能力接入:预加载、开屏广告、华为推送、数字收银台 综合商城应用模板 新增组件:地址管理、应用设置、登录、支付、分享、个人信息、意见反馈、会员组件 美食菜谱应用模板 能力接入:数字收银台、华为广告 美食菜谱应用模板 功能增强:新增下拉刷新和饮食计划、折叠屏适配 美食菜谱应用模板 新增组件:登录、设置、个人信息、会员组件 美业元服务模板 能力接入:智能填充、一多适配、华为地图 美业元服务模板 功能增强:UI改版 美业元服务模板 新增组件:基础组件、个人信息组件 点餐元服务模板 能力接入:一多适配、服务卡片 点餐元服务模板 功能增强:首页新增城市选择、扫一扫、预约订座和排队取号;新增24卡片、适配一多折叠屏、优化堂食和外带场景、优化钱包和积分功能、组件元服务胶囊、兼容平板设备弹窗、兼容模拟器充值功能 点餐元服务模板 新增组件:选择店铺、搜索组件 * 汽车驾考应用模板 能力接入:开屏广告、华为分享、数字收银台、华为推送等功能 汽车驾考应用模板 新增组件: 应用设置、会员、分享、个人信息、反馈组件 综合新闻应用模板 功能增强:新增视频直播支持退后台小窗播放、数字报纸功能、广播功能、地方电视功能 综合新闻应用模板 新增组件:登录、分享、意见反馈、隐私弹窗、应用设置、朗读、个人信息、网络请求模拟库axios-mock-adapter、日志库util-log组件 综合工具应用模板 能力接入:华为推送、华为账号一键登录、开屏广告 综合工具应用模板 新增组件:会员、登录、意见反馈、个人信息组件 电子书阅读应用模板 功能增强:折叠屏和平板适配 组件
组件归属 组件名称 更新内容 美食菜谱应用模板 菜谱瀑布流组件 瀑布流增加下拉加载和上拉刷新;新增折叠屏适配 综合新闻应用模板 短视频滑动组件 修改视频横竖屏切换问题;修改互动内的视频在页面退出后,会在持续播放的问题;修改滑动进度条时不展示总时间的问题 综合新闻应用模板 数字报纸组件 首次发布 综合工具应用模板 吉他调音器组件 新增会员功能 综合工具应用模板 修图神器组件 新增会员功能 综合工具应用模板 视频剪辑组件 新增会员功能 综合工具应用模板 解压缩组件 新增会员功能;修复大文件压缩问题 美业元服务模板 个人信息编辑组件 接入智能填充服务;一多适配
欢迎下载使用模板&组件“点击下载”,若您有体验和开发问题,或者相关心愿单
欢迎在评论区留言,小编会快马加鞭为您解答~
同时诚邀您添加下方二维码加入“组件模板开发者社群”,精彩上新&活动不错过!
👉HarmonyOS官方模板优秀案例系列持续更新,点击查看 往期案例汇总贴,欢迎收藏,方便查找!
👉【组件征集】HarmonyOS组件开发征集活动,点击参加
👉【HarmonyOS行业解决方案】为各行业鸿蒙应用提供全流程技术方案。点击查看
本文为2025年 vivo 开发者大会互联网技术专场分享内容之一,在公众号“vivo互联网技术”对话框回复【2025VDC】获取 2025VDC 互联网技术会场议题相关资料。 1分钟看图掌握核心观点👇 图1 VS 图2,您更倾向于哪张图来辅助理解全文呢?欢迎在评论区留言 在软件研发过程中,环境问题常常成为关键路径上的阻塞点。2020年vivo某核心业务数据显示,因测试环境问题导致的转测延期占比高达67%,策划验收阶段因环境问题导致的延期超过10次。 这些数据背后,反映的是研发过程中常见的典型场景: 深入分析该业务场景后,我们发现环境问题主要集中在以下几个方面:环境不稳定、测试环境混乱、环境抢占严重、资源利用率低下。这些问题并非单一项目特有,在微服务架构和快速迭代模式下,已成为多个团队共同面临的挑战。 随着vivo互联网业务的快速发展,为满足更快发布需求,我们全面转向微服务架构。这一转变在提升灵活性与敏捷性的同时,也带来了新的管理挑战。 挑战主要来自两个维度: 这些变化叠加,使得研发环境管理复杂度大幅提升,环境稳定性下降、资源浪费严重,最终导致整体研发效率受损。 传统环境管理方式已难以满足当前需求,亟需一种创新方法,实现多版本像“平行宇宙”一样安全、隔离、高效地并行测试与发布。 为解决环境管理难题,我们提出了“全链路多版本环境管理”理念,其核心基于三大关键能力: 1.全链路能力 单一服务版本环境不足以保证整体功能验证。必须确保版本依赖的所有组件——从前端、网关到微服务,再到数据库、缓存和消息队列——整条链路能够一键拉起、快速就绪。以支付业务调试为例,无需手动启动账户、风控、结算等服务,通过一键操作即可分钟级生成完整环境,数据流、配置流与生产环境保持一致。 2.多版本并行 支持同时创建多个“完整环境”,使各版本在独立“沙箱”中运行,彻底解决资源抢占问题。热修复版本可分钟级拉起独立环境,新功能开发同步进行,实现“分钟级响应,零等待协作”。 3.环境自动化管理 通过全生命周期自动化——从环境搭建、弹性伸缩到闲置回收,减少人工干预,降低错误率,提升资源利用效率,实现降本增效。 基于这三项核心能力,线上问题或紧急需求出现时,我们可在几分钟内创建独立环境进行验证,且不影响其他版本进程。 理解全链路多版本环境管理理念后,我们的核心解决思路也从传统的“环境隔离”转向“流量隔离”模式。 传统方式为每个版本构建完整独立的测试环境,如同各自独立的烟囱。此方式隔离性好,但资源浪费严重,环境数量有限,扩展性差。 全链路多版本环境管理方案则采用不同策略:首先维护稳定可靠的公用基线环境。当某版本需开发新功能时,无需从头搭建整套环境,仅需为实际发生变更的服务创建独立的“特性环境”。 关键问题在于如何实现流量的精准路由。答案在于流量统一网关平台,该系统在流量入口识别每个请求的环境标签,根据标签将请求路由至对应版本的服务实例。 未改动服务继续共享稳定基线环境,发生变更的服务则拥有独立环境——通过流量精准调度,既保证隔离性,又显著节约资源与成本。 这一模式类似于单栋大楼内通过不同颜色手环区分访问区域,整栋楼共享基础设施,但各区域活动互不干扰。流量统一网关平台充当“智能前台”,负责识别“手环”、调度流量,使多版本并行开发井然有序。 “逻辑隔离”相较于“物理隔离”展现出显著优势:更弹性、更经济、更高效。 基于上述思路,我们构建了完整的技术架构,清晰展示系统核心组件及协同工作机制。 全链路多版本环境的核心能力可归纳为四个关键部分:环境编排、流量隔离、容器部署与分布式链路系统。 环境编排:负责组织软件从开发到部署各环节,确保每次代码变更快速部署至指定环境。在多版本环境中,编排系统自动识别不同版本,触发对应构建部署流程,保证各版本独立高效就绪。 流量隔离:实现多版本并行的关键。通过灵活路由策略,精确控制各版本流量走向。无论是HTTP请求、Dubbo调用还是MQ消息,均能在各自服务实例间有序流转、互不干扰,如同智能交通系统确保不同“车流”各行其道。 容器部署:为环境提供轻量、标准化封装方式,各服务及其依赖打包为独立镜像。借助容器技术,实现应用秒级启动与弹性伸缩。多版本场景下,各版本可快速拉起自身实例组,极大提升资源利用率与发布效率。 分布式链路系统:架构的“可观测性”基础,实时追踪记录请求在微服务间的完整流动路径并传递环境标签。当请求进入系统,经多服务处理时,该系统完整记录其“足迹”——包括经过服务、携带标签、是否异常,为问题排查与性能优化提供关键支撑。 接下来,我们将深入解析全链路多版本环境背后的三大关键技术实现。 从实现视角聚焦,核心技术主要包括: 三大技术形成有机整体,紧密协作,缺一不可。 实现多版本并行的第一步是高效、标准化地“创建环境”。 这主要由CI/CD平台支撑,它不仅是自动化工具,更是强大的可视化环境编排器。开发人员在界面定义待部署服务,系统自动识别服务间依赖关系,判断哪些可并行部署、哪些需串行执行,最终实现“一键完成”环境编排。 优势显而易见:无论是全新版本环境搭建,还是单一服务更新,均可通过单次点击,在分钟级别快速完成,使“秒级拉起独立完整环境”成为研发流程常态。 具体而言,CI/CD平台在全链路多版本中提供两方面关键支撑: CI/CD平台作为多版本环境体系的“指挥中心”,高效调度四大核心组件——为容器部署提供调度依据,为流量隔离准备环境标签,使分布式链路系统充分发挥跟踪与观测能力。 指令发出后,需要强健的“执行体”高效落实。vivo容器化平台正是这一强大、可靠的实体。 弹性资源能力由容器化平台核心支撑。全链路多版本环境中,我们能够轻松、快速创建大量隔离环境,背后依赖的正是容器技术。 容器化工作原理简述:开发者将应用及其所有依赖打包为标准容器镜像。该镜像可在任何支持容器的环境中运行,确保开发、测试、预发和生产环境高度一致,真正实现“一次构建,随处运行”,从根源解决环境差异问题。 资源利用率方面,容器技术优势明显。传统虚拟机部署中,单节点通常仅运行单一应用,资源利用率低。容器化部署允许多个容器共享节点操作系统内核,轻量高效。对多版本环境管理而言,这意味着可低成本、高效率创建大量隔离环境。以往需10台服务器支撑的多版本测试,现仅需3-4台,成本显著降低。 此外,容器平台具备自动扩缩容能力,这在多版本场景中尤为重要:特性环境压力测试时,系统自动扩容保障稳定性;测试结束环境闲置时,资源自动缩容回收,真正实现按需使用、高效节能。 容器化带来三大核心价值:环境标准化、资源高效化与伸缩自动化。这些能力组合使我们能够轻松维护多版本并行研发,加速产品迭代,提高系统稳定性,同时显著降低成本。 对业务团队而言,这意味着更快功能交付、更稳定系统运行与更高资源利用率。这是全链路多版本环境支撑大量环境并行而无需担忧资源成本激增的根本原因。 环境与资源就绪后,确保流量“对号入座”是实现隔离性的关键。这引出两个核心概念:“流量隔离”与“流量染色”。 流量隔离指由统一流量网关平台维护智能路由表,记录“环境标签”与“服务实例地址”间映射关系。 如图示:Feature1环境流量仅路由至IP1、IP2实例;Feature2流量指向IP3、IP4实例,实现真正互不干扰。 流量染色如同为每批流量分配“颜色标识”。请求进入网关前,为其添加明确环境标识,声明“属于Feature1”或“属于Feature2”。网关据此正确识别与路由。 理解流量隔离与染色后,需将其应用于真实网络环境。微服务架构下,流量基本分为两类:南北流量与东西流量。 图示说明: 在vivo实践中: 1.HTTP流量隔离 过程如图绿色路径所示。始于环境编排阶段:通过流水线部署服务时,为各实例注入唯一环境标签。同时,vivo统一访问平台建立“环境标签”与后端服务实例组(Upstream)的绑定关系,触发创建相应CRD并实施监听。 此后,无论是部署、实例扩容、缩容还是重启,只要实例IP和端口变化,变更都会被实时监听并动态更新至网关路由规则,形成高效自动化闭环,确保每个带环境标签的HTTP请求被网关精准路由至正确特性环境实例。 2.DUBBO协议隔离 借助Dubbo官方原生标签路由能力实现。原理直观:将服务实例动态划分至不同逻辑分组,约束带特定标签流量仅能访问指定分组。vivo实践中,打标动作发生于部署环节。容器启动时,Init Container自动调用Dubbo服务治理平台,通过动态规则配置,无感地为当前服务实例添加环境标签。整个过程无需重启服务,配置实时生效,完美支持全链路多版本对灵活性与实时性要求。 3.消息队列(MQ)隔离 与前两者不同,MQ组件本身缺乏完善隔离机制。我们基于MQ消息网关平台mq-proxy组件实现。 实现方式巧妙:生产者与消费者启动并与mq-proxy建立连接时,在连接属性中携带自身环境标签。消息生产时,mq-proxy拦截消息,将环境标签写入消息user-property中。消费时,mq-proxy根据消息中标签与消费者自身环境标签进行匹配过滤,确保消息不会被跨环境消费。整个过程对业务代码完全透明,实现无侵入隔离。 南北流量染色:客户端至服务器端流量染色实现方式如下。 具体实现:生产者与消费者启动时,与mq-proxy建立连接,使用连接属性v-env-tag存放环境标签,即图示中间启动部分。消息生产消费环节中,生产者生产消息时,mq-proxy拦截消息,将环境标签写入消息user-property中。 消息消费端,mq-proxy拉取消息时,获取消息中环境标签信息并进行过滤,推送至对应环境服务实例,确保仅消费属于当前环境的消息。通过此机制,保证消息在整个生命周期携带环境标识,实现MQ流量染色。 最复杂部分在于环境标签在整条调用链中自动传递。通过vivo分布式链路系统实现,核心技术为javaagent,通过调用链Agent透明完成此项“接力”工作。 示例如下:来自客户端的HTTP请求携带env\_tag=feature1,网关将其路由至feature1环境的用户中心。用户中心需调用积分中心时,调用链Agent拦截此次Dubbo调用,从HTTP请求头中获取env\_tag,并注入Dubbo调用的Attachment中,积分中心因此收到该标签。积分中心处理完毕,需发送MQ消息通知活动中心。此时Agent再次拦截,从Dubbo Attachment中获取标签,写入MQ消息属性。最终,仅标注feature1的活动中心实例消费此消息。整条链路中,如有环节未匹配环境标签,流量则回退至基线环境。 如此,环境标签在HTTP→Dubbo→MQ完整链路中自动传递,确保全链路环境隔离,真正实现“一次染色,全程生效”。 回顾关键技术部分:环境编排是指挥中心,负责调度与创造;弹性资源是执行实体,负责支撑与运行;流量隔离与染色是传导系统,负责精准识别与路由。三者有机结合,构成全链路多版本环境管理的稳固架构,缺一不可。 全链路多版本环境落地实践后,成效显著: 这不仅带来效率提升,更实现研发节奏全面加速与业务响应能力质的飞跃。 展望未来,我们对全链路多版本环境管理有清晰规划。这不仅是技术升级,更是研发管理理念的演进。 未来规划采用双轨并行策略,从研发效能环境标准化与资源成本高效化两个维度同步推进。两方向相互促进、协同支撑。 在已实现的环境编排、资源弹性与流量隔离基础上,重点推进三项关键措施: 1. 构建环境即服务平台 平台提供标准化环境模板,包括不同规模测试环境及各类专用环境(如性能测试、安全测试等)。通过模板化方式,确保环境一致性与标准化,同时大幅提升环境创建效率。 平台集成环境全生命周期管理功能,从环境申请、审批、创建、使用、监控到回收,形成完整闭环管理。这不仅提升管理效率,更建立完善的环境治理体系。 2. 建立全链路环境监控与可观测体系 监控体系涵盖多层:基础设施层监控CPU、内存、存储等资源使用;中间件层监控数据库、消息队列、缓存等组件性能;应用层监控服务响应时间、错误率、吞吐量等关键指标。 通过分层监控,快速识别环境中异常情况,及时发觉性能瓶颈,为环境优化提供数据支撑。监控数据同时为资源调度与成本优化提供重要决策依据。 3. 建立环境治理与合规自动化机制 治理机制包括环境命名规范、资源配置标准、安全配置要求、数据保护规则等多方面。通过自动化合规检查工具,实时监控环境合规状态,自动发现与修复不合规配置。 机制还包括环境定期审计功能,自动生成合规报告,为管理决策提供支撑。通过此方式,既确保环境安全合规,又减少人工审计工作量。 资源成本高效化方面,推进以下两项关键措施: 1. 非活跃环境自动回收 针对非活跃环境,建立智能自动回收机制。系统自动识别长期未使用环境,在确保数据安全前提下,自动进行资源回收。 机制包含多层管理: 通过分层管理,既保证开发效率,又有效控制成本。 2. 成本可视化与归因分析 成本分析从多维度展开: 通过精确成本统计与分析,为成本优化提供数据支撑。 通过双轨并行策略,我们实现研发效能提升与资源利用最大化的良性循环。 全链路多版本环境管理的未来规划不仅是技术升级,更是研发管理理念的转变。通过双轨并行策略,我们将建立更高效、经济、可靠的研发环境体系,同时打造更先进的研发环境管理体系。作者:互联网效能平台团队-Wu Qinghua
在软件研发过程中,“环境问题”是制约研发效能的关键瓶颈之一。环境不稳定、测试环境混乱、环境抢占严重等问题,显著影响开发与测试效率。本文系统介绍vivo通过“全链路多版本环境管理”模式,实现开发测试环境的快速构建与高效管理,使多版本环境能够像“平行宇宙”一般,实现安全、隔离、高效的并行测试与发布。

一、背景&问题
1.1 我们遇到的问题

1.2 问题的挑战

二、解决方案思路
2.1 什么叫全链路多版本环境管理

2.2 业务目标示意图

2.3 全链路多版本业务架构图

三、关键技术实现

3.1 环境编排

3.2 弹性资源

3.3 流量隔离&流量染色
3.3.1 流量隔离和流量染色的定义

3.3.2 流量隔离实现

3.3.3 流量染色实现


3.3.4 标签的传递

四、业务实践与效果

五、未来规划

5.1 研发效能环境标准化
5.2 资源成本高效化
最新消息,Apache DolphinScheduler 3.4.0 已正式发布! 本次版本带来了多租户调度隔离、工作流并行性能优化、任务重试与告警机制增强,以及资源管理和日志处理改进。无论是复杂企业业务场景,还是高并发任务调度,3.4.0 都让系统更高效、更可靠、更易用。立即升级,体验全新调度能力! 下载页面(可选择镜像下载): GitHub Release 页面: 3.4.0 引入了对 OpenID Connect(OIDC)的通用支持,旨在简化与企业身份认证系统的集成。通过 OIDC,用户可以使用统一的身份提供商(如 Keycloak、Okta 等)进行 SSO 登录,无需额外实现复杂自定义逻辑。这提升了安全性和用户体验,尤其是在多系统联邦登录与统一认证场景中,能够使 DolphinScheduler 更自然地融入企业级认证体系,减少重复配置和验证成本,从而提高登录配置的扩展性和一致性。 本版本新增了 gRPC 任务插件能力,使调度器能够通过原生 gRPC 协议直接与远程服务交互。用户可以将后端微服务暴露的 gRPC 接口作为任务执行目标,无需中间脚本封装。这种方式特别适合微服务生态或跨语言执行场景,通过明确参数契约和高性能通信协议提升任务整合效率,从而减少资源调度延迟、提高任务可靠性。 实现了 工作流串行执行策略(Workflow Serial Strategy) 的核心逻辑重构,通过引入一个全新的串行命令队列机制( 该设计改进了工作流触发流程的执行类型判断、状态管理、命令队列处理等关键路径,使串行调度逻辑更清晰、更可靠,有助于提升串行工作流场景下的调度稳定性与可控性。同时,3.4.0 重构了触发器与状态机相关代码,增强该能力的可维护性和扩展性。 3.4.0 对任务类型体系进行了精简,正式移除了内置的 PyTorch 任务类型。该调整主要基于实际使用情况和长期维护成本的考量,因为原有 PyTorch 任务实现使用率较低,且与调度器核心任务模型耦合度较高,增加了版本演进和兼容性维护的复杂度。通过移除该任务类型,DolphinScheduler 能保持核心架构的简洁与稳定。 我们鼓励用户通过更通用的 Shell、Python 或插件化方式运行 PyTorch 作业,从而提升系统整体的可维护性和扩展性。 在 Kubernetes 原生部署场景下,3.4.0 使 Worker StatefulSet 的 Helm Chart 支持注入 Secrets 和 InitContainers。通过 Secrets 注入,可以安全传递证书或凭据;InitContainers 允许在主容器启动前完成必要的初始化逻辑,如准备文件系统或校验环境依赖。 这些增强有助于在容器化环境下实现更安全、更一致的部署策略和生命周期管理。 针对 SQL 任务类型,本次版本提供了对任务执行取消的原生支持。当执行的 SQL 语句由于逻辑错误或长期运行导致资源占用时,用户可以通过调度器下发取消操作,使任务尽快中止,而不是简单失败或等待超时。这一能力改善了任务控制能力,避免长时间运行对集群资源的无效占用,有助于提升整体资源利用率和执行调度体验。 在某些复杂工作流中,当条件任务节点的前置任务失败时,条件节点未按预期执行。3.4.0 修复了这一调度核心逻辑,确保条件节点能够正确响应前置失败状态。这样,工作流分支逻辑能够按照既定 DAG 定义可靠运行,从而避免因逻辑错误导致的流程中断或不一致执行。 在使用 ZooKeeper 作为协调组件的高可用部署中,部分用户反馈 Master Server 在启动失败后未正确清理已注册的 failover 节点路径,可能导致后续状态异常。该版本修复了这个问题,使 Master 在异常启动路径中能够正确清理关联注册节点,保持注册中心状态一致,确保高可用场景下集群状态的健康和可靠性。 此前版本中,项目与 Worker Group 关联/移除操作可能在 API 层出现逻辑不一致,导致调度器未能正确识别项目与 Worker Group 的关系。本次版本修正了相关逻辑,使 API 行为与用户预期一致,从而改善 Worker 管控、资源隔离和调度分配体验。 此外,3.4.0 版本还进行了很多功能优化和问题修复,包括文档与配置规范完善(时区、安全、负载均衡)、核心调度与注册中心稳定性增强(TraceId、Failover 清理、可重入锁)、性能与资源管理优化(任务组索引)、前端与插件体验改进(日志查询、DataX 校验、文件展示)、依赖与安全更新(PostgreSQL JDBC、Spring Boot CVE 修复)等,篇幅所限不再一一展开,详情可查询完整更新列表:https://github.com/apache/dolphinscheduler/releases/tag/3.4.0 某些生命周期事件中,当任务状态需要被标记为 Inactive 时,状态变更可能未正确触发,导致 UI 和执行引擎状态不一致。此版本修复了这一逻辑,使状态标记与生命周期事件更加一致。 在工作流血缘关系删除操作中,系统可能未能彻底清理相关引用,导致历史血缘链路残留。3.4.0 改进了删除逻辑,使 DolphinScheduler 在删除血缘链时能够更精确地清理对应关系,避免分析后续依赖时出现错误链路。 其他 Bug 修复包括前置任务失败导致条件节点不执行问题修复、项目级 Worker Group 绑定与移除逻辑修正、子工作流触发参数丢失问题修复等,详情请查询完整 Release Note:https://github.com/apache/dolphinscheduler/releases/tag/3.4.0 本次版本发布离不开社区各位贡献者的热情参与与支持。特别感谢 @ Gallardot 作为 3.4.0 的 Release Manager,从版控、构建、候选版验证到最终投票组织,确保发布流程高质量推进。 同时,感谢以下本次版本的所有贡献者(GitHub ID,排名不分先后): Gallardot、njnu‑seafish、det101、Mrhs121、EinsteinInIct、sanfeng‑lhh、ruanwenjun、tusaryan、qiong‑zhou、SbloodyS、kvermeulen、npofsi、CauliflowerEater、ChaoquanTao、dill21yu、sdhzwc、zhan7236、KwongHing、jmmc‑tools、liunaijie 感谢所有通过提交 PR、Issue、文档贡献、社区讨论、测试验证等方式参与 Apache DolphinScheduler 项目的人。正是你们的努力推进了 DolphinScheduler 的持续演进与社区繁荣,欢迎更多人加入我们的队伍!
升级与下载
https://dolphinscheduler.apache.org/zh-cn/download/3.4.0
https://github.com/apache/dolphinscheduler/releases/tag/3.4.0
升级时建议参考官方文档中的集群升级指南,确保兼容性和配置一致性。核心功能增强与重要更新
通用 OIDC 认证支持

(参考图)gRPC 任务插件支持



支持工作流串行策略
t_ds_serial_command 表及相关 DAO/Mapper),配合一套串行执行协调器(WorkflowSerialCoordinator)及策略处理器,使 DolphinScheduler 能更智能地管理串行类型的工作流(如 SERIAL_WAIT、SERIAL_PRIORITY、SERIAL_DISCARD)。移除 PyTorch 任务类型
稳定性与重要修复
Kubernetes Worker 部署增强
SQL 任务取消能力
条件任务节点在前置失败情况下执行逻辑修复
ZooKeeper 节点清理问题修复
Worker Group 分配逻辑错误修复
Bug 修复亮点
标记任务为 Inactive 状态逻辑修复
Workflow Lineage 删除逻辑优化
文档更新
致谢
本模板为招聘类应用提供了常用功能的开发样例,模板主要分职位、消息、个人中心三大模块。本模板已集成华为账号、即时通讯、推送、分享等服务,支持深色模式、适老化、无障碍等特性,提供完整的招聘应用解决方案,只需做少量配置和定制即可快速实现招聘应用的核心功能。 本模板为回收类应用提供了常用功能的开发样例,模板主要分首页和我的两大模块。本模板已集成回收服务、华为账号、订单流程、地址管理、银行卡等服务,支持创建订单、编辑地址、我的设置等特性,提供完整的回收服务应用解决方案,只需做少量配置和定制即可快速实现回收服务应用的核心功能。 本模板为旅游类应用提供了常用功能的开发样例,模板主要分首页、行程、消息和个人中心四大模块。本模板已集成华为账号、微信登录、消息管理、应用更新检查、意见反馈、实名认证等服务,采用模块化架构设计,支持多设备适配,只需做少量配置和定制即可快速实现旅游攻略应用的核心功能。 更多模板&组件上新,敬请关注! 👉 HarmonyOS官方模板优秀案例系列持续更新, 点击查看 往期案例汇总贴,欢迎收藏,方便查找!
💡 鸿蒙生态为开发者提供海量的HarmonyOS模板/组件,助力开发效率原地起飞 💡
★ 更多内容,一键直达生态市场组件&模板市场 , 快速应用DevEco Studio插件市场集成组件&模板 ★
★ 一键直达 HarmonyOS 行业解决方案 ★
模板 | 求职招聘应用模板(点击下载)

模板 | 购物(回收)应用模板(点击下载)

模板 | 旅游攻略应用模板(点击下载)

组件 | 可分可合组件
归属模块 名称 简介 公交地铁应用模板 公交地铁站点地图组件 提供了展示当前位置信息、附近站点、路线规划、导航功能。 公交地铁应用模板 站点线路组件 提供公交地铁站点和线路的综合信息展示功能,支持导航、收藏、到站提醒及地图轨迹展示,还可查看同站线路。 求职招聘应用模板 求职意向组件 提供了求职意向管理功能,支持添加、编辑、删除求职意向信息,包括工作性质、意向职位、工作城市、行业类型、期望薪资和求职状态等信息的填写和管理。 回收应用模板 回收估价表单组件 提供手机/电脑回收估价表单能力。估价表单:通过 BuildValuationInfoPageBuilder 构建页面,支持型号、设备类型、选项选择与价格计算,并通过回调返回估价结果。 旅游攻略应用模板 旅行足迹组件 提供了旅行足迹管理的相关功能,支持足迹地图展示、总里程统计、足迹列表浏览、添加新足迹等能力。 旅游攻略应用模板 发票编辑组件 提供了发票管理的相关功能,支持发票列表展示、添加新发票、编辑现有发票、删除发票等能力。 旅游攻略应用模板 路线规划组件 提供了旅游路线规划功能,支持用户选择出发地、目的地和游玩天数,并根据选择智能推荐旅游路线。 壁纸应用模板 壁纸详情组件 提供了壁纸详情展示功能,其中包含:作者名称、作者头像、壁纸分类、壁纸关键词、以及收藏、取消收藏、预览、下载、设为壁纸、左右切换壁纸等功能。
欢迎下载使用模板&组件“点击下载”,若您有体验和开发问题,或者相关心愿单
欢迎在评论区留言,小编会快马加鞭为您解答~
同时诚邀您添加下方二维码加入“组件模板开发者社群”,精彩上新&活动不错过!
【相关推荐】
👉【组件征集】HarmonyOS组件开发征集活动,点击参加
👉【HarmonyOS行业解决方案】为各行业鸿蒙应用提供全流程技术方案。点击查看
先说我自己:jetbranis + Claude code[beta]插件 + Claude code + glm4.7
其他:Gemini 3 flash ,Gemini 3 pro
备用:豆包
目前背景:
是个小公司的后端开发,服务器,数据库,git,公司路由器都在我手里,感觉责任重大,想知道有什么需要避免的操作吗,主要是害怕万一一周或者几个月我不在,避免公司业务出问题
以下是我自己想到的几点,想知道还有没有其他没想到的方案
1.数据库的分区表,特别是和时间相关的,不能手动生成,要不然后面人不在没交代的话会直接给服务器崩掉
2.给本地调试的服务器端口白名单,不能图方便给网段开白名单,要不然后面会有脚本小子或者勒索病毒来扫
3.一些公共库,如果有不符合业务需求的地方,不要把人家的源码拉下来自己改然后编译成引用放在库里,(比如说 ef core upsert 的库之前不支持 ef10)否则后面更新时候会炸掉
4.单元测试不要埋雷,一些当调试用的或临时跑点小任务单元测试不能放在例行单元测试的文件夹里面,污染数据库
2026 年被定义为AI 智能体技术规模化落地元年,依托大模型技术的持续迭代、工具生态的完善以及行业场景的深度适配,智能体从技术概念走向商业落地,完成从 “文本生成工具” 到 “自主任务执行系统” 的核心转变。本文系统阐述 2026AI 元年的技术基础、产业特征、核心应用领域,分析智能体技术对生产生活、产业结构的重构价值,梳理技术落地的核心挑战与解决路径,为产业从业者、研究人员及普通用户提供全面的技术与应用参考框架。关键词:2026AI 元年;智能体;大模型;技术落地;产业变革;人机协同 2023-2025 年大模型完成从 “通用理解” 到 “逻辑推理 + 多模态交互” 的能力突破,为智能体落地奠定核心基础: 智能体的 **“感知 - 规划 - 行动 - 反思”** 底层闭环实现标准化、模块化,成为技术落地的关键支撑: 2025 年以来,各行业从 “AI 技术尝鲜” 转向 “降本增效刚需”,为智能体规模化落地提供产业土壤: 2026 年智能体技术呈现 “通用能力打底,垂直场景深耕” 的核心特征: 智能体突破此前 “仅能完成线上内容生成” 的局限,实现 **“线上 + 线下”“数字 + 实体”** 的全场景业务执行: 2026 年 AI 产业从 “技术厂商主导的技术迭代” 转向 “产业端主导的需求落地”,形成 **“大模型厂商 + 智能体开发平台 + 场景应用方 + 工具生态方”** 的完整产业生态: 智能体成为企业数字化转型的核心工具,实现办公全流程的自动化与高效化,核心应用包括: 智能体与工业互联网、物联网、大数据技术结合,赋能制造业从 “自动化生产” 到 “智能化生产” 的升级,核心应用包括: 智能体在教育、医疗、政务、物流等民生服务领域落地,实现公共服务的高效化、个性化与普惠化,核心应用包括: 2026 年个人智能体实现全民化普及,成为覆盖办公、学习、创作、生活的个人数字分身,核心应用包括: 2026 年作为 AI 智能体元年,标志着 AI 技术从 “内容生成” 阶段进入 “自主任务执行” 阶段,完成了从技术概念到产业落地的核心跨越。依托大模型技术的成熟、智能体体系的完善与产业需求的爆发,智能体在企业服务、产业制造、民生服务、个人端等领域实现规模化落地,成为推动产业升级、提升生产效率、优化生活体验的核心力量。 同时,2026 年智能体技术的落地仍面临技术、数据、产业、伦理等多方面的挑战,需要技术厂商、产业从业者、政策制定者共同努力,通过技术迭代、数据治理、产业赋能、政策规范,推动智能体技术的健康、可持续发展。 未来,随着技术的持续迭代与产业的深度融合,智能体将逐步实现从 “垂直智能体” 到 “通用智能体” 的升级,人机协同将成为生产生活的标配,最终形成 “人机共生” 的全新发展体系。2026AI 元年不仅是智能体技术的落地起点,更是人类社会智能化发展的全新开端,技术的发展将始终围绕 “赋能人类、提升社会生产力” 的核心目标,推动人类社会向更高质量、更高效、更智能的方向发展。 [1] 斯坦福大学. AI 指数报告 2026 [R]. 斯坦福大学人类与人工智能研究院,2026.[2] 麦肯锡咨询。智能体技术与产业变革白皮书 2026 [R]. 麦肯锡全球研究院,2026.[3] 中国人工智能产业发展联盟。中国智能体技术落地与应用规范指南 (2026 版)[S]. 2026.[4] OpenAI. GPT-4o 技术白皮书 [R]. OpenAI 官方技术团队,2026.[5] 腾讯云。智能体技术在企业服务领域的落地实践与趋势分析 [R]. 腾讯云 AI 研究院,2026.[6] Coze(扣子). 零代码智能体开发与应用白皮书 2026 [R]. 字节跳动 AI 实验室,2026.摘要
一、2026 成为 AI 智能体元年的核心技术与产业基础
1.1 大模型技术的成熟:智能体的核心能力底座
1.2 智能体技术体系的完善:标准化闭环与工具生态
1.3 产业需求的爆发:从 “技术尝鲜” 到 “效率刚需”
二、2026AI 智能体元年的核心产业特征
2.1 技术特征:从 “专用智能体” 到 “通用智能体 + 垂直适配”
2.2 应用特征:从 “线上内容生成” 到 “全场景业务执行”
2.3 产业特征:从 “技术驱动” 到 “需求驱动”,生态化发展
三、2026 智能体技术的核心应用领域与落地案例
3.1 企业服务领域:办公自动化与人机协同办公体系构建
落地案例:某中小企业通过 Coze 搭建专属销售智能体,对接企业微信与 Excel,实现客户咨询 7×24 小时自动回复,销售数据每日自动统计并生成分析报告,销售团队的基础工作效率提升 65%,人力成本降低 30%。3.2 产业制造领域:工业智能体赋能智能制造与生产优化
落地案例:某中小型机械制造企业引入工业智能体,对接生产车间的物联网设备,实现生产计划的自动制定与动态调整,设备故障预警准确率提升 80%,产品不良率降低 25%,生产效率提升 40%。3.3 民生服务领域:智能体提升公共服务效率与个性化体验
落地案例:某地方政务服务中心上线政务智能体,对接政务服务平台,实现社保、医保、户籍等高频政务问题的 7×24 小时自动回复,线上材料初审通过率提升 75%,窗口办理业务的平均时长缩短 60%,群众办事满意度提升 90%。3.4 个人端应用:全民化智能体成为个人数字分身
四、2026 智能体技术落地的核心挑战与解决路径
4.1 核心挑战
4.2 解决路径
五、2026AI 元年之后的智能体技术发展趋势
5.1 短期趋势(2026-2027 年):垂直场景深度落地,全民化普及加速
5.2 中期趋势(2028-2030 年):通用智能体成熟,人机协同成为生产生活标配
5.3 长期趋势(2030 年以后):智能体向 “通用人工智能” 迈进,人机共生体系形成
六、结论
参考文献
———以点量云流商用实时云渲染平台为例
随着实时云渲染技术的日趋成熟,其应用场景已从单纯的三维模型轻量化展示,深度渗透到数字孪生、工业仿真、远程三维协作、在线教学培训等多元化业务领域。当前,行业对云渲染平台的核心需求已发生本质转变:不再局限于“依赖云端算力实时渲染复杂三维模型,实现终端轻量化交互操作”,更聚焦于“能否承载真实业务场景中的全流程沟通,实现虚拟场景与现实信息的无缝联动”。
点量云流在对接大量政企、工业、教育类商用项目落地过程中发现,仅依靠三维模型的实时渲染与基础交互,远不足以支撑复杂的远程协作场景。例如,工业远程运维中,工程师需要同步查看设备三维仿真模型与现场摄像头拍摄的设备实际运行状态;三维项目协作会议中,参会者需结合本地文档、操作演示视频,对虚拟场景进行精准讨论;在线技能培训中,讲师需通过摄像头实时讲解,同步展示课件、实操视频与三维仿真操作流程。
基于此,点量云流在现有实时云渲染架构的基础上,针对性引入摄像头与本地媒体数据接入能力,通过技术优化实现现实世界数据流与虚拟三维场景的无缝融合,有效补齐了传统云渲染平台在“全维度信息表达”“业务场景适配”层面的短板,进一步拓宽了实时云渲染技术的商用落地边界。
从技术实现逻辑来看,点量云流的摄像头与本地媒体数据接入能力,可拆解为“本地采集层—流媒体传输层—云端渲染融合层—Web三维呈现层”四个核心层级,各层级协同联动,既保证数据传输的低延迟、高稳定,又实现媒体内容与三维场景的自然融合,适配商用场景的严苛需求。
2.1 本地数据采集与编码:多源适配,筑牢数据基础
作为数据接入的源头,本地采集层的核心目标是实现多类型本地媒体数据的全面、高效采集,并通过标准化编码处理,为后续流媒体传输奠定基础。点量云流突破传统平台的采集局限,支持多种本地数据源的全覆盖采集,具体包括:
摄像头数据:支持电脑内置摄像头、高清工业摄像头等各类设备,可根据场景需求灵活调整采集分辨率、帧率,适配从日常沟通到工业监测的不同清晰度要求;
本地屏幕数据:支持全屏采集、指定区域采集、单个应用窗口采集,可精准捕捉桌面操作、软件演示等内容,适配项目演示、技能培训等场景;
各类课件与文件内容:兼容Flash课件、exe可执行课件、PPT、Word、PDF等多种格式文档,支持直接采集展示,无需额外格式转换,提升使用便捷性;
本地媒体文件:支持MP4等主流格式的本地视频文件,可实现文件的实时采集与流式播放,适配预录视频演示、案例讲解等场景。
针对采集到的多类型数据,平台会进行实时标准化编码处理,采用H.264/H.265高效编码算法,在保证画面清晰度的前提下,最大限度压缩数据体积,降低后续网络传输压力,同时支持编码参数动态调整,适配不同网络环境下的采集传输需求。
2.2 流媒体化与协议支持:低延迟传输,适配多场景分发
流媒体传输层是连接本地采集与云端融合的核心枢纽,其核心作用是将本地编码后的媒体数据,统一转化为标准流媒体格式,并通过适配商用场景的传输协议,实现数据的低延迟、高稳定推送,同时支持多用户并发访问与各类外部视频源对接。
点量云流采用“统一流媒体化”处理逻辑,将采集编码后的摄像头画面、屏幕内容、课件、视频文件等各类数据,均转化为标准化流媒体流,确保后续云端融合与终端播放的兼容性。在传输协议方面,平台聚焦商用场景的核心需求,重点支持两大主流协议,实现多场景适配:
RTSP协议:主打低延迟、强控制特性,传输延迟可控制在毫秒级,适合对实时性要求极高的场景,如工业设备实时监测、远程手术指导、实时互动演示等,可实现媒体数据的实时推送与精准控制;
RTMP协议:生态成熟、兼容性强,支持多用户并发分发,可适配大规模用户同时访问的场景,如在线公开课、大型项目协作会议、多终端同步演示等,确保不同用户的访问体验一致。
值得注意的是,点量云流的媒体接入能力并非局限于本地摄像头,还可实现与监控系统、网络摄像头等各类标准视频源的无缝对接,通过协议兼容,将外部视频数据同步接入三维场景,进一步拓展了业务适配范围,适配工业数字孪生、智慧监控等高端场景需求。
2.3 云端渲染融合层:无缝联动,实现虚实融合
云端渲染融合层是整个技术架构的核心,承担着“三维场景渲染”与“本地媒体数据融合”的双重职责,也是点量云流区别于传统云渲染平台的关键所在。平台通过自研的融合渲染算法,将流媒体传输层推送的本地媒体数据(摄像头画面、屏幕内容等),与云端渲染的三维场景进行实时无缝融合,实现以下核心效果:
媒体内容可灵活嵌入三维场景:支持将摄像头画面、本地视频、文档等内容,以悬浮窗口、内嵌模块等形式,嵌入三维场景的任意位置,不遮挡核心三维模型,实现自然呈现;
虚实数据实时联动:当三维场景进行旋转、缩放、漫游等操作时,嵌入的本地媒体内容可同步适配,保持画面同步性,确保用户在查看三维场景的同时,能实时获取本地媒体信息;
多源媒体内容协同展示:支持同时接入多路本地媒体数据(如摄像头+本地文档+屏幕演示)。
2.4 Web端播放与访问:无插件适配,降低使用门槛
Web三维呈现层作为面向用户的最终展示载体,核心目标是实现“便捷访问、跨端兼容”,降低用户使用门槛,适配企业多样化的访问场景。点量云流摒弃了传统平台需要安装专用客户端、插件才能播放媒体内容的模式,通过技术优化,实现媒体流与三维场景的Web端无插件直接播放。
该层的核心优势的体现在三个方面:
一是无需安装任何插件、客户端,用户通过Chrome、Edge等主流浏览器,即可直接访问平台,查看融合了本地媒体数据的三维场景,大幅降低企业用户的部署与使用成本;
二是全面支持跨平台访问,兼容Windows、Mac等各类桌面操作系统,同时适配平板、手机等移动终端,用户可随时随地通过终端设备接入,满足远程协作、移动办公的需求;
三是灵活适配网络环境,无论是企业内网的封闭场景,还是公网的开放场景,均能实现稳定播放,通过网络自适应算法,动态调整播放参数,避免因网络波动导致的卡顿、黑屏,保障商用场景的流畅体验。
在商用场景中,实时云渲染平台的核心应用之一是多人远程协作,而摄像头与本地媒体数据的接入,本质上是为了提升协作的高效性与精准性。为此,点量云流针对性打造了完善的多人同步与分组控制机制,将媒体数据接入能力与协作场景深度绑定,解决了多用户协作中“内容不同步、权限不清晰、场景切换繁琐”等痛点。其核心功能包括:
多用户实时同步订阅:同一路本地媒体数据(如主讲人的摄像头画面、演示文档),可支持多个用户同时订阅查看,所有用户看到的内容与主讲人实时同步,无延迟、无偏差,确保协作沟通的一致性,适配多人项目会议、在线培训等场景;
基于用户分组的内容隔离:支持根据业务需求,将用户划分为不同分组(如项目A组、项目B组、教学分组等),不同分组可接入不同的本地媒体数据,实现内容隔离,避免不同业务场景的内容干扰,同时保障数据安全,适配多项目并行、多班级教学等复杂场景;
动态切换:支持本地媒体内容的动态切换(如从摄像头画面切换为本地文档、从屏幕演示切换为视频文件),实现协作流程的顺畅衔接,提升沟通效率。
这套同步与控制机制,为各类复杂协作场景提供了坚实的技术支撑,无论是企业的多项目分组协作、教育机构的分班在线教学,还是工业领域的多团队远程运维沟通,都能通过该机制实现高效协作,进一步发挥实时云渲染与本地媒体接入融合的价值。
实时云渲染平台接入摄像头与本地媒体数据,并非简单的功能叠加,而是对云渲染技术商用价值的深度挖掘与能力升级,从技术层面来看,这一能力的落地,具有三大核心价值,推动云渲染平台实现从“单一渲染工具”到“综合型三维协作基础设施”的跨越式发展。
第一,搭建现实世界与三维空间的实时数据通道。传统云渲染平台仅能呈现虚拟三维场景,与现实世界存在明显的信息割裂;而摄像头与本地媒体数据的接入,打通了虚拟场景与现实世界的数据流壁垒,实现了现实信息与虚拟模型的实时联动,让三维场景不再是“孤立的虚拟载体”,而是能够承载现实业务信息的“综合展示窗口”,提升了平台的业务适配能力。
第二,强化系统的整合与扩展能力。点量云流的媒体接入能力,支持多类型本地数据源、多标准传输协议、多终端访问场景的兼容适配,不仅可接入普通摄像头与本地文件,还能对接工业相机、监控系统等专业设备,实现与企业现有业务系统的无缝整合,无需对现有设备、系统进行大规模改造,降低企业数字化升级成本;同时,开放的接口设计,也为后续接入更多类型的媒体数据源、拓展更多协作功能提供了可能,具备极强的扩展性。
第三,奠定高阶商用场景落地的技术基础。数字孪生、远程运维、三维协同设计、在线技能培训等高阶应用场景,均需要虚拟场景与现实信息的深度融合,而摄像头与本地媒体数据接入能力,正是支撑这些场景落地的核心技术支撑。例如,工业数字孪生中,通过接入现场摄像头与设备监控视频,可实现虚拟孪生模型与设备实际运行状态的实时对照,助力远程运维与故障排查;三维协同设计中,通过接入本地设计文档、操作演示视频,可实现多设计师的精准沟通,提升设计效率。
综上,点量云流通过在实时云渲染平台中融入摄像头与本地媒体数据接入能力,不仅补齐了传统平台的能力短板,更推动云渲染技术从“专注渲染”向“赋能业务”转型,使其成为能够支撑多元化商用场景、承载全流程协作沟通的综合型三维协作基础设施,为各行业的数字化转型提供更加强劲的技术支撑。
这里按照官方提供的文档进行操作: 官方提供的开发手册位置 在搭建 DolphinScheduler 开发环境之前请确保你已经安装以下软件: 通过你 git 管理工具下载 git 代码,下面以 git-core 为例 上面是官方提供的,我觉得有用就复制下来, 这里开始我就按照自己的操作顺序记录 编译都没有问题 下载 ZooKeeper,解压 搞个txt编辑完后,后缀该bat即可 【可以不用,我也是看其他文章有添加的,不过我没添加也能正常运行,这里只做记录】 我这里用的是mysql,所以需要修改 如图: 跟上面一样操作: 总的就这三个: 问题:测试能否创建文件夹、上传文件等,提示【存储未启用】 问题:当前登录用户的租户信息未被指定 我这里直接用minio来尝试: 配置文件改了这些地方 安全中心 - 租户管理 - 创建租户 如图,数据已经存放在我指定的minio文件夹里面了
目录

前提

1、软件要求
2、克隆代码库
mkdir dolphinscheduler
cd dolphinscheduler
git clone git@github.com:apache/dolphinscheduler.git3、编译源码
支持的系统:
* MacOS
* Linux
【这个我没有运行试试】
运行 `mvn clean install -Prelease -Dmaven.test.skip=true`DolphinScheduler 普通开发模式
1、编译问题:
1、git相关
1-1:开启 Windows Git 长路径支持,
管理员 PowerShell 执行,解决 DolphinScheduler 路径太深导致 git add 失败
git config --system core.longpaths true
1-2:先初始化git仓库,只在本地,不涉及账号、不推远程,Spotless 需要 HEAD
git init
git add .
git commit -m "initial commit"
2、Maven 编译 / 格式化(IDEA 里的 Terminal)
2-1:依赖 Git HEAD,自动修复格式问题
mvn spotless:apply
2-2:编译整个项目(跳过测试),确保所有模块已 install
mvn clean install -DskipTests
3、前端相关:
查看 Node.js 是否已安装
node -v
查看 npm 版本
npm -v
安装 pnpm
npm install -g pnpm
pnpm -v
2、启动zookeeper
官方内容

存储配置

启动脚本
@echo off
echo 正在启动 ZooKeeper...
cd /d E:\\install\\ZooKeeper\\zookeeper-3.8.3\\bin
zkServer.cmd
pause3、workspace.xml 修改
在其他文章看到说在这里添加这行,说是让 IDEA 在运行时动态使用模块的 classpath,而不是用启动时生成的静态 classpath。
注意点:
这个作用只会影响本地 IDEA 启动,线上环境如果有问题这个是解决不了的。
"dynamic.classpath": "true",
4、数据库
4-1:数据初始化
创建名为【dolphinscheduler】的新数据库后,
把这个位置的sql直接拷贝复制执行即可。

4-2:依赖相关修改
如果使用 MySQL 作为元数据库,需要先修改 `dolphinscheduler/pom.xml`,
将 `mysql-connector-java` 依赖的 `scope` 改为 `compile`,
使用 PostgreSQL 则不需要
test 改成 compile
5、application.yaml 修改数据库配置

5-1:dolphinscheduler-master
如图,配置文件中修改这些数据:三个内容都是一样的
spring:
config:
activate:
on-profile: mysql
datasource:
driver-class-name: com.mysql.cj.jdbc.Driver
url: jdbc:mysql://127.0.0.1:3306/dolphinscheduler?useUnicode=true&characterEncoding=utf8&zeroDateTimeBehavior=convertToNull&useSSL=true&serverTimezone=GMT%2B8
username: 账户名
password: 数据库密码
5-2:dolphinscheduler-worker

5-3:dolphinscheduler-api

6、logback-spring.xml 修改日志级别

6-1:dolphinscheduler-master
<appender-ref ref="STDOUT"/>
6-2:dolphinscheduler-worker

6-3:dolphinscheduler-api

7、启动后端三个服务
我们需要启动三个服务,包括 MasterServer,WorkerServer,ApiApplicationServer
* MasterServer:在 Intellij IDEA 中执行 `org.apache.dolphinscheduler.server.master.MasterServer` 中的 `main` 方法,并配置 *VM Options* `-Dlogging.config=classpath:logback-spring.xml -Ddruid.mysql.usePingMethod=false -Dspring.profiles.active=mysql`
* WorkerServer:在 Intellij IDEA 中执行 `org.apache.dolphinscheduler.server.worker.WorkerServer` 中的 `main` 方法,并配置 *VM Options* `-Dlogging.config=classpath:logback-spring.xml -Ddruid.mysql.usePingMethod=false -Dspring.profiles.active=mysql`
* ApiApplicationServer:在 Intellij IDEA 中执行 `org.apache.dolphinscheduler.api.ApiApplicationServer` 中的 `main` 方法,并配置 *VM Options* `-Dlogging.config=classpath:logback-spring.xml -Dspring.profiles.active=api,mysql`。启动完成可以浏览 Open API 文档,地址为 http://localhost:12345/dolphinscheduler/swagger-ui/index.html
> VM Options `-Dspring.profiles.active=mysql` 中 `mysql` 表示指定的配置文件7-1:MasterServer
配置 VM Options
按照操作配置这个:打开后填入即可
-Dlogging.config=classpath:logback-spring.xml -Ddruid.mysql.usePingMethod=false -Dspring.profiles.active=mysql

7-2:WorkerServer
配置 VM Options
-Dlogging.config=classpath:logback-spring.xml -Ddruid.mysql.usePingMethod=false -Dspring.profiles.active=mysql7-3:ApiApplicationServer
配置 VM Options
-Dlogging.config=classpath:logback-spring.xml -Dspring.profiles.active=api,mysql
8、启动前端服务
命令:
安装前端依赖并运行前端组件
cd dolphinscheduler-ui
pnpm install
pnpm run dev

9、浏览器访问
账号密码:
浏览器访问:
http://localhost:5173/home
默认账号密码:
账号:admin
密码:dolphinscheduler123
成功访问:

相关问题
1、存储未启用、租户\用户 指定


解决方法:
1、minio 创建 dolphinscheduler 桶

2、commom.properties 修改


# Licensed to the Apache Software Foundation (ASF) under one or more
# contributor license agreements. See the NOTICE file distributed with
# this work for additional information regarding copyright ownership.
# The ASF licenses this file to You under the Apache License, Version 2.0
# (the "License"); you may not use this file except in compliance with
# the License. You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
#
# user data local directory path, please make sure the directory exists and have read write permissions
data.basedir.path=/tmp/dolphinscheduler
# resource view suffixs
#resource.view.suffixs=txt,log,sh,bat,conf,cfg,py,java,sql,xml,hql,properties,json,yml,yaml,ini,js
# resource storage type: HDFS, S3, OSS, NONE
# ljh --> S3 is Minio--------------------------------------
resource.storage.type=S3
# resource store on HDFS/S3 path, resource file will store to this base path, self configuration, please make sure the directory exists on hdfs and have read write permissions. "/dolphinscheduler" is recommended
resource.storage.upload.base.path=/dolphinscheduler
# ljh --> The account and password of MinIO-------------------------------
# The AWS access key. if resource.storage.type=S3 or use EMR-Task, This configuration is required
resource.aws.access.key.id=minioadmin
# The AWS secret access key. if resource.storage.type=S3 or use EMR-Task, This configuration is required
resource.aws.secret.access.key=minioadmin
# The AWS Region to use. if resource.storage.type=S3 or use EMR-Task, This configuration is required
resource.aws.region=cn-north-1
# ljh --> add bucket ------------------------------
# The name of the bucket. You need to create them by yourself. Otherwise, the system cannot start. All buckets in Amazon S3 share a single namespace; ensure the bucket is given a unique name.
resource.aws.s3.bucket.name=dolphinscheduler
# You need to set this parameter when private cloud s3. If S3 uses public cloud, you only need to set resource.aws.region or set to the endpoint of a public cloud such as S3.cn-north-1.amazonaws.com.cn
# ljh --> localhost convert 127.0.0.1
resource.aws.s3.endpoint=http://127.0.0.1:9000
# alibaba cloud access key id, required if you set resource.storage.type=OSS
resource.alibaba.cloud.access.key.id=<your-access-key-id>
# alibaba cloud access key secret, required if you set resource.storage.type=OSS
resource.alibaba.cloud.access.key.secret=<your-access-key-secret>
# alibaba cloud region, required if you set resource.storage.type=OSS
resource.alibaba.cloud.region=cn-hangzhou
# oss bucket name, required if you set resource.storage.type=OSS
resource.alibaba.cloud.oss.bucket.name=dolphinscheduler
# oss bucket endpoint, required if you set resource.storage.type=OSS
resource.alibaba.cloud.oss.endpoint=https://oss-cn-hangzhou.aliyuncs.com
# if resource.storage.type=HDFS, the user must have the permission to create directories under the HDFS root path
resource.hdfs.root.user=hdfs
# if resource.storage.type=S3, the value like: s3a://dolphinscheduler; if resource.storage.type=HDFS and namenode HA is enabled, you need to copy core-site.xml and hdfs-site.xml to conf dir
resource.hdfs.fs.defaultFS=hdfs://mycluster:8020
# whether to startup kerberos
hadoop.security.authentication.startup.state=false
# java.security.krb5.conf path
java.security.krb5.conf.path=/opt/krb5.conf
# login user from keytab username
login.user.keytab.username=hdfs-mycluster@ESZ.COM
# login user from keytab path
login.user.keytab.path=/opt/hdfs.headless.keytab
# kerberos expire time, the unit is hour
kerberos.expire.time=2
# resourcemanager port, the default value is 8088 if not specified
resource.manager.httpaddress.port=8088
# if resourcemanager HA is enabled, please set the HA IPs; if resourcemanager is single, keep this value empty
yarn.resourcemanager.ha.rm.ids=192.168.xx.xx,192.168.xx.xx
# if resourcemanager HA is enabled or not use resourcemanager, please keep the default value; If resourcemanager is single, you only need to replace ds1 to actual resourcemanager hostname
yarn.application.status.address=http://ds1:%s/ws/v1/cluster/apps/%s
# job history status url when application number threshold is reached(default 10000, maybe it was set to 1000)
yarn.job.history.status.address=http://ds1:19888/ws/v1/history/mapreduce/jobs/%s
# datasource encryption enable
datasource.encryption.enable=false
# datasource encryption salt
datasource.encryption.salt=!@#$%^&*
# data quality option
data-quality.jar.name=dolphinscheduler-data-quality-dev-SNAPSHOT.jar
#data-quality.error.output.path=/tmp/data-quality-error-data
# Network IP gets priority, default inner outer
# Whether hive SQL is executed in the same session
support.hive.oneSession=false
# use sudo or not, if set true, executing user is tenant user and deploy user needs sudo permissions; if set false, executing user is the deploy user and doesn't need sudo permissions
sudo.enable=true
setTaskDirToTenant.enable=false
# network interface preferred like eth0, default: empty
#dolphin.scheduler.network.interface.preferred=
# network IP gets priority, default: inner outer
#dolphin.scheduler.network.priority.strategy=default
# system env path
#dolphinscheduler.env.path=dolphinscheduler_env.sh
# development state
development.state=false
# rpc port
alert.rpc.port=50052
# set path of conda.sh
conda.path=/opt/anaconda3/etc/profile.d/conda.sh
# Task resource limit state
task.resource.limit.state=false
# mlflow task plugin preset repository
ml.mlflow.preset_repository=https://github.com/apache/dolphinscheduler-mlflow
# mlflow task plugin preset repository version
ml.mlflow.preset_repository_version="main"
# ljh --> minio must open path style
resource.aws.s3.path.style.access=true
3、dolphinscheduler 可视化页面添加租户

用户添加租户

演示
创建文件夹、上传文件成功

