ITPub博客

9月，中国信息安全测评中心与国家保密科技测评中心联合发布《安全可靠测评结果公告(2026 年第 3 号)》。数据库品类新增三款集中式产品通过测评;星环科技正式登陆港交所主板挂牌上市;Omdia发布《2026年亚太及大洋洲分布式数据库市场研究》，2025年亚洲及大洋洲分布式数据库市场规模达到9亿美元，预计2026年将增长至11亿美元，到2029年进一步达到18亿美元……

很多企业把数据治理等同于采购一套平台、部署一套系统，结果工具上线了，数据质量依旧、口径依旧、扯皮依旧。问题往往不在技术，而在组织。数据治理的本质，是一场关于权责、流程与协作方式的管理变革。 一、一个常见的误区：把治理当成采购项目 在不少企业里，数据治理的启动方式高度相似：业务部门抱怨报表对不上，管理层要求"把数据管起来"，于是 IT 牵头调研厂商、比选平台、走采购流程。几个月后，一套数据治理平台上线，元数据管理、数据标准、数据质量、数据血缘等功能一应俱全。 然后呢？ 数据标准文档躺在知识库里，没人认领； 数据质量问题被记录，但没人负责整改； 指标口径在会议上反复争论，最后仍各说各话； 平台逐渐沦为"看板展示工具"，而非治理抓手。 这不是工具的问题，而是把一件管理问题当成了技术问题来处理。 二、为什么数据治理本质

大模型幻觉（Hallucination）是指模型生成看似合理、实则与事实不符或缺乏依据的内容。它既是模型能力边界的外在表现，也是当前 LLM 落地过程中最容易被用户感知的问题之一。本文尝试从工程实践角度，梳理减少幻觉的常见思路。需要说明的是，本文依据现有公开认知与通用工程经验撰写，未引用具体产品版本或实验数据，具体效果需结合业务场景验证。 一、先理解幻觉从何而来 在讨论"怎么减少"之前，有必要先明确幻觉的成因。幻觉通常与以下几类因素相关： 训练目标本身：自回归语言模型的目标是预测下一个 token，而不是"保证事实正确"。模型被训练成"流畅地续写"，而非"在不确定时保持沉默"。 知识时效与覆盖：模型参数中固化的知识存在截止时间，且对长尾、专业、私有领域覆盖不足。 解码策略：采样温度、top-p 等参数越高，输出

如今，数据库一体机（Database Appliance）依然在金融、电信、政务等关键行业占据一席之地。它并非"过时产物"，而是在特定业务场景下被反复验证过的工程选择。 一、什么是数据库一体机 数据库一体机通常指将数据库软件与经过预集成、预调优的服务器、存储、网络等硬件打包交付的一体化系统。厂商在出厂前完成软硬件适配与性能调优，用户拿到的是"开箱即用"的整体方案，而非需要自行拼装的软硬件组合。 二、业务为什么倾向选择一体机 1. 交付确定性高，上线周期短 传统自建数据库需要经历选型、采购、上架、系统安装、参数调优、兼容性验证等一长串环节，任何一环出问题都可能拖慢整体进度。一体机把这些工作前置到厂商侧完成，业务方更多是"到货即部署"，对有时间窗口压力的核心系统上线尤为友好。 2. 软硬件协同调优，性能表现可预期

数字化转型与智能化转型是当前企业技术演进中最常被并列讨论的两个概念。二者并非替代关系，而是存在明显的阶段性与能力递进关系。本文从目标、技术底座、数据角色、组织影响等维度梳理其异同，供技术决策者参考。 一、概念边界：先厘清两个词在说什么 数字化转型通常指企业将业务流程、管理模式、客户交互从线下或纸质形态迁移到数字系统之上，核心是"把事搬到线上、把流程跑通、把数据留痕"。典型动作包括上云、ERP/CRM 系统建设、业务中台搭建、数据打通等。 智能化转型则是在数字化已经沉淀出可用数据与系统的基础上，引入 AI、机器学习、大模型等能力，让系统从"记录与执行"走向"判断与生成"。典型动作包括智能推荐、预测性维护、智能客服、基于 LLM 的流程自动化等。 二者最本质的区别在于：数字化解决"能不能被系统处理"，智能化解决"系

当大模型、Agent、RAG 等技术名词逐渐从 PPT 走进生产环境，越来越多企业发现，真正卡住 AI 落地的往往不是模型能力，而是组织架构、协作方式和企业文化。技术可以采购，组织能力却只能自己长出来。 一、一个被反复验证的现实：技术就绪 ≠ 落地成功 过去两年，企业对 AI 的投入从"要不要做"迅速转向"怎么做"。算力可以租、模型可以调 API、开源框架唾手可得，技术门槛肉眼可见地下降。但与此同时，大量 POC（概念验证）项目停留在演示阶段，无法进入核心业务流程。 这种"演示惊艳、落地艰难"的落差，根源往往不在技术侧，而在组织侧：数据散落在各部门，跨团队协作成本高于技术实现成本；业务与技术语言不通，AI 团队不懂业务痛点，业务团队不理解模型边界；没人对最终结果负责，项目在部门墙之间被反复踢皮球。 技术问题通常

当 AI Agent 从“回答问题”走向“自主执行任务”，数据库的角色正在被重新定义。数据分支正在成为 Agentic AI 时代数据基础设施的关键拼图。本文基于现有公开技术逻辑进行推演，不涉及具体产品版本与实测数据。 一、从 Copilot 到 Agent：数据库面临的新压力 过去两年，AI 与数据库的结合主要集中在“辅助查询”层面：自然语言转 SQL、查询优化建议、结果解释。这类场景中，AI 是只读的旁观者。 而 Agentic AI 的核心变化在于：Agent 会自主地读、写、试错、回滚、再执行。它不再只是生成一段 SQL 交给人类确认，而是可能直接：创建临时表做数据探索，批量修改生产数据以完成某个业务目标，在多个假设之间反复试验，调用多个工具链，形成长事务式的操作序列。 这带来一个根本矛盾：Agent

Agent 正在从演示型 Demo 走向企业生产系统，但真正困难的问题不是“能不能跑通”，而是“三年后还能不能演进”。本文尝试给出一套偏工程与组织视角的布局思路。 一、Agent 不是单一技术，而是分层体系 很多企业谈 Agent，第一反应是选一个大模型 API，接上工具调用，做一个能对话、能执行任务的助手。但从长期演进的角度看，Agent 更像是一套分层架构，而不是一个功能点。 一个可持续演进的 Agent 技术体系，至少需要被拆成以下几层来思考： ·模型层：底层 LLM 的选择、替换与多模型路由能力。 ·编排层：任务规划、工具调用、状态管理、多 Agent 协作。 ·工具与数据层：企业内部 API、数据库、知识库、业务系统的接入方式。 ·记忆与上下文层：短期会话记忆、长期知识沉淀、上下文压缩与检索。 ·评测

Agent 正在从演示走向生产，但“选哪个 Agent”往往仍靠个人经验和厂商话术。本文尝试给出一套可复用的决策框架，帮助不同行业、不同规模的团队把 Agent 选型从“拍脑袋”变成“有标准”。 一、先明确一个前提：没有万能 Agent，只有匹配场景的 Agent 在讨论选型标准之前，需要先承认一个现实：Agent 的能力边界高度依赖它所处的业务场景、数据条件和集成环境。一个在客服场景表现良好的 Agent，未必能胜任金融风控或工业质检；一个适合十人团队的轻量方案，放到千人组织里可能立刻暴露权限、审计和成本问题。 因此，标准化的选型决策体系，核心不是给出一个“最佳 Agent 榜单”，而是建立一套可重复、可解释、可审计的判断流程，让不同团队都能基于自身约束得出合理结论。 二、选型决策体系的五个维度 一套可落地的

数据库与人工智能正在双向奔赴。一方面，AI 技术被引入数据库内核，用于优化器、索引、参数调优与运维自治，这被称为 AI4DB；另一方面，数据库开始承担 AI 工作负载，为模型训练、特征工程与推理提供数据底座，这被称为 DB4AI。 AI4DB：用 AI 改造数据库 AI4DB 的核心思路，是把AI引入数据库自身的管理与执行过程。依据现有技术方向，主要可以归纳为以下几类： 1. 智能查询优化 传统优化器依赖代价模型和统计信息，在复杂查询或数据分布倾斜时容易估算偏差。AI4DB 尝试用学习型优化器替代或增强代价模型，例如： 学习型代价估计：用模型预测算子代价与基数。 学习型计划选择：根据历史执行反馈选择更优计划。 端到端优化：减少对人工规则的依赖。 2. 智能索引与存储 索引推荐、自动索引、学习型索引是常见方向。学

导语：数据治理几乎成了每一家数字化企业的“必修课”，但真正把这件事做成的企业并不多。本文尝试从组织、业务、技术、成本等多个角度，拆解数据治理难做的深层原因，并给出一些可落地的思考方向。 一、先厘清：数据治理到底在治理什么 在讨论“为什么难”之前，有必要先明确数据治理的边界。数据治理并不是简单地“把数据洗干净”，它通常涉及： 数据标准 ：统一指标口径、命名规范、编码规则； 数据质量 ：准确性、完整性、一致性、及时性； 数据安全与合规 ：权限、脱敏、审计、隐私保护； 数据资产 ：元数据、数据血缘、数据目录； 组织与流程 ：谁负责、谁使用、谁维护。 也就是说，数据治理本质上是一项 横跨业务、技术、组织的系统性工程 ，而不是一个可以一次性交付的项目。这决定了它的难度天然高于一般的 IT 建设。 二、难点一：它本质上是“

导语：当企业把数据视为“资产”时，真正的难题往往不在技术栈，而在人。数据文化不是一块标语，而是一套让数据被信任、被使用、被持续改进的组织习惯。本文从认知、机制、能力与领导力四个层面，讨论数据文化的培育路径。 一、先厘清：数据文化到底指什么 在讨论策略之前，需要先界定对象。数据文化可以理解为组织成员在决策与协作中对待数据的共同默认规则，通常包含三个可观察的维度： 认知层面 ：成员是否相信数据能改善决策，而不是把数据当作汇报材料。 行为层面 ：在开会、立项、复盘时，是否习惯先看数据、再下结论。 制度层面 ：数据的使用、共享、质量责任是否有明确归属和流程支撑。 三者缺一不可。只讲认知而不改流程，数据文化会停留在口号；只上工具而不改认知，工具最终会被绕过。 二、培育策略的四个抓手 1. 从“高层示范”开始，而不是从“全

过去一年，关于 Agent 的讨论几乎被“模型能力”主导：更强的推理、更长的上下文、更高的工具调用准确率。但当企业真正尝试把 Agent 从 Demo 推进到生产环境时，最先撞上的往往不是模型智商，而是一整套工程化基础设施的缺失。企业级 Agent 部署的真实门槛，集中在运行时、编排、记忆、安全和观测这五个层面。 一、Demo 与生产之间，隔着一整套运行时 Demo 阶段的 Agent 通常运行在本地脚本或单次会话中，输入可控、状态简单、失败可接受。但生产环境要求的是持续可用、可恢复、可扩展的运行时。 一个可用的 Agent 运行时至少需要回答几个问题： Agent 进程如何启动、隔离和回收？ 工具调用超时、失败、重试如何处理？ 长任务如何保持状态，避免会话中断后全部丢失？ 并发请求下，资源如何分配和限流？ 这

当我们在讨论 Agent 的记忆时，真正的问题往往不是“要不要记忆”，而是“记忆应该放在哪一层”。短期上下文和长期记忆看似只是时间尺度不同，实际上它们对存储位置、生命周期、访问方式和一致性要求完全不同。把两者混在同一层，是很多 Agent 系统在规模变大后变得难以维护的根源。 先厘清两个概念 短期上下文（short-term context）：指当前任务或当前会话中，模型为了完成推理所必须看到的即时信息。它通常包括最近几轮对话、当前工具调用结果、临时中间状态等。它的核心特征是“此刻有用，任务结束即可丢弃”。 长期记忆（long-term memory）：指跨会话、跨任务需要保留的信息，例如用户偏好、历史决策、已确认的事实、可复用的经验。它的核心特征是“需要被检索、被更新、被遗忘”。 两者不是同一种东西的两个副本

具身智能被视为大模型之后的下一个浪潮，但和语言模型不同，它面对的是一个更难啃的瓶颈——数据。当“众包”这套在互联网时代屡试不爽的打法被搬到机器人数据采集上，它究竟是解药，还是又一个被高估的故事？ 一、具身智能的“数据黑洞”从何而来 要理解众包数采为什么被反复提起，先要理解具身智能在数据上的特殊性。 语言模型可以靠互联网上现成的文本“喂饱”，图像模型可以爬取海量图片，但具身智能需要的是动作数据——机器人在真实物理环境中如何抓取、移动、避障、完成任务的过程记录。这类数据有几个天然难点： 采集成本高：需要真实的机器人硬件、场地、操作人员，单条数据的边际成本远高于爬一张图片。 难以规模化复制：语言数据可以无限复制，物理交互数据必须一次次真实发生。 标注维度复杂：不仅要知道“看到了什么”，还要知道“做了什么动作”“结果如

过去十年，企业软件的主流叙事是SaaS：按席位订阅、标准化交付、边际成本趋近于零。但当大模型驱动的智能体（Agent）进入企业核心流程，客户真正关心的不再是“我买了多少个账号”，而是“你到底帮我完成了多少工作、节省了多少人力、提升了多少转化”。

当大模型从“会聊天”走向“能办事”，客服场景成为最先被重构的阵地之一。一个可用的客服 Agent，通常要同时解决三件事：把多轮对话聊明白、把用户情绪读准确、把工单流转接顺畅。本文围绕这三条主线，梳理客服 Agent 的能力结构与落地要点。 一、为什么客服是 Agent 的“试金石” 客服场景天然具备三个特征，使它成为 Agent 落地的典型战场： 任务边界清晰：查订单、改地址、退换货、报故障，目标明确、可验证。 交互轮次多：用户往往不会一次说清诉求，需要多轮澄清与追问。 结果可衡量：一次解决率、转人工率、工单闭环时长，都是现成的评估指标。 也正因如此，客服 Agent 不能只停留在“问答机器人”的层面，而要具备对话管理、情绪感知、系统操作三类能力。 说明：本文为方法论梳理，未引用具体产品版本或实测数据；涉及具体

当大模型从“会聊天”走向“能办事”，企业知识库成为最先被重构的场景之一。检索增强生成（RAG）解决了“答得准”的一部分问题，而 Agent 的引入，则试图解决“找得到、想得清、做得对”的完整链路。本文围绕面向企业知识库的 Agent 检索与推理展开讨论。 一、为什么企业知识库需要 Agent 企业知识库的典型特征是：文档量大、格式杂、权限复杂、更新频繁。传统的检索方式（关键词检索、向量检索）能解决“相似度匹配”，但很难处理以下问题： 多跳问题：答案分散在多个文档、多个系统中，需要串联推理。 意图模糊：用户提问口语化，需要先澄清再检索。 权限边界：不同角色可见的知识范围不同，检索必须带权限过滤。 时效性：制度、流程、价格等知识频繁变更，检索结果需要校验新鲜度。 Agent 的价值在于把“一次性检索”变成“可规划、

泛化能力被视为具身智能从“演示可用”走向“真实可用”的关键门槛。但“泛化”本身并不是一个单一指标，它至少涉及任务、物体、场景、指令、本体等多个维度。本文尝试给出一套可讨论、可拆解的评估框架。 一、为什么泛化是具身智能的核心问题 在传统机器人系统中，工程师通常通过精确建模、标定和轨迹规划，让机器人在受控环境中完成固定任务。这种方式在产线上行之有效，但一旦环境、物体或任务发生变化，系统往往需要重新开发。 具身智能（Embodied AI）试图用学习的方式替代大量手工规则，让智能体在物理世界中感知、决策并行动。它真正的价值不在于“在某个固定场景里跑通一次”，而在于面对没见过的输入时，仍能保持可接受的表现。这正是泛化能力要回答的问题。 因此，评估具身智能，不能只看单点任务的成功率，而要看它在多大范围内、以多低的代价维持

在大模型与各类 AI 系统落地的过程中，数据标注往往被视为“脏活累活”，但它直接决定了模型能力的上限。标注质量治理的核心问题并不只是“标得准不准”，而是如何在成本、速度、一致性、可追溯性之间取得平衡。当前主流路径有三条：众包标注、专家标注、自动标注。三者并非互相替代，而是越来越多地被组合进同一套数据生产流水线。本文围绕这三种模式的治理要点展开讨论。 一、为什么标注治理是系统工程 标注质量问题的根源通常不在标注员个人，而在流程设计。常见失效模式包括： 标准漂移：同一概念在不同批次、不同标注员之间理解不一致。 激励错位：按件计酬鼓励速度，牺牲边界样本的准确性。 反馈缺失：标注结果没有回流机制，错误无法被系统性纠正。 责任模糊：出现质量问题时，无法定位到具体环节与责任人。 因此，标注治理应被理解为一条包含规范制定、任