ITPub博客

导语： 当 Agentic AI 从“会聊天”走向“会办事”，系统的瓶颈正在从模型能力转向状态、记忆与行动的一致性。数据库不再只是后台存储，而更像是智能体的“长期记忆”和“行动账本”。但这一判断需要分清场景：我们无法给出统一的量化结论，只能从架构逻辑上讨论数据库角色正在发生的变化。 一、从“无状态推理”到“有状态执行” 传统 LLM 应用大多是一次性推理：用户提问，模型生成回答，会话结束后状态基本清空。Agentic AI 则不同，它需要多步规划、调用工具、观察结果、修正计划，并在多个回合之间保持目标与上下文。 这意味着系统必须回答几个工程问题： 上一轮执行到了哪一步？ 哪些工具调用已经成功，哪些需要重试？ 中间结果如何被后续步骤引用？ 多个 Agent 或子任务之间如何共享状态？ 这些问题的本质是 状态管理

导语 当 AI 从“回答问题”走向“自主执行任务”，数据语义层的角色正在发生变化。它不再只是 BI 报表背后的指标字典，也不只是数据团队内部的口径管理工具，而正在成为 Agent 理解业务、调用数据、执行动作的基础设施。 一、为什么 Agentic AI 把语义层推到台前 传统数据分析链路中，语义层主要解决“同一个指标在不同报表里口径不一致”的问题，使用者是人。而在 Agentic AI 场景下，使用者变成了会自主规划、多步调用工具的 Agent，语义层要承担三件新任务： 可发现 ：Agent 需要知道“有哪些数据、哪些指标、哪些动作可用”，而不是靠人临时指路。 可理解 ：Agent 需要拿到带业务含义的定义、维度、粒度、约束，而不只是表名和字段名。 可安全执行 ：Agent 会真正发起查询甚至写入操作，语义层

仅有7%的受访者表示，他们已对超过70%的非结构化文件数据进行了清理、分类和预处理。另有57%的受访者表示，其准备就绪的数据占比不超过一半。而13%的受访者甚至不确定已准备就绪的数据量有多少。换言之，93%的受访者尚未达到70%的门槛。

10月17日，DeepSeek宣布DeepSeek V4.1 Flash更新至V4.1-Flash-1017版本，官方网页端、APP与API模型同步变更为新模型，随着新版本的发布，DeepSeek API还新增了对Search与Fetch接口(网页搜索与抓取接口)的支持。

导语：跨境数据流动既是企业全球化运营的基础设施，也是当前合规治理中最复杂的议题之一。本文从合规路径、技术手段与组织协同三个维度，梳理企业在跨境数据治理中需要面对的核心问题与可行思路。 一、为什么跨境数据流动治理难以"一招解决" 跨境数据流动的复杂性，来自三个层面的叠加： 规则层面 ：不同司法辖区对数据出境的态度、门槛和豁免条件差异明显，且处于持续演进中。 技术层面 ：数据一旦在系统间流转，识别、标记、拦截和审计都需要工程能力支撑，而非仅靠制度文本。 组织层面 ：数据往往由业务、法务、安全、IT 多方共同持有，责任边界模糊，容易出现"都管又都不管"。 因此，把跨境数据治理简单理解为"法务出个政策"或"安全团队加个网关"，通常难以落地。真正可行的方案，是合规、技术与组织三条线同时推进。 二、合规路径：从"能不能传"

导语：数据目录正在从“元数据台账”演化为“数据消费入口”。当企业完成数据接入与治理的初步建设后，如何让数据被找到、被理解、被信任、被使用，成为数据平台价值兑现的关键一环。本文尝试梳理数据目录从资产发现到智能推荐的建设路径，供数据平台与数据治理团队参考。 一、为什么数据目录重新变得重要 过去几年，企业数据平台的建设重心大多集中在“把数据接进来、存下来、算出来”。随着数据源数量增长、数据链路变长、参与角色变多，新的问题开始显现： 找数难 ：业务方不知道有哪些数据、数据在哪里、字段代表什么含义。 理解难 ：即使找到了表，也缺少口径说明、更新频率、责任人等上下文。 信任难 ：无法判断一份数据是否可靠、是否被广泛使用、是否存在质量问题。 协作难 ：数据需求依赖口头沟通或工单流转，缺少可沉淀的资产化表达。 数据目录正是为回

导语：很多团队都能在文档里写下RPO 和 RTO 目标，但真正发生故障时，才发现备份不可用、恢复流程没人会走、业务侧等不起。RPO/RTO 不是写在 SLA 里的数字，而是需要靠备份策略、恢复演练和工程化流程一点点兑现的承诺。本文讨论如何把这两个指标从纸面落到生产环境。 一、先厘清：RPO 和 RTO 到底约束了什么 在讨论落地之前，需要先把两个概念对齐： RPO（Recovery Point Objective，恢复点目标） ：能容忍丢失多少数据，通常用时间衡量。RPO 越小，意味着备份或复制必须越频繁、越接近实时。 RTO（Recovery Time Objective，恢复时间目标） ：从故障发生到业务恢复可用的最长时间。RTO 越小，意味着恢复流程必须越快、越自动化。 关键点在于： RPO 约束的是“数

导语：线上数据库事故往往不是“不会写 SQL”，而是变更流程缺少可验证的审核与管控。本文从风险来源、审核要点、变更流程和落地建议四个层面，讨论如何把数据库变更从“个人操作”变成“可审计的工程流程”。 一、为什么线上数据库事故反复发生 数据库变更的危险性在于：它同时具备 高影响面 和 低容错性 。一条 SQL 在测试环境执行几百毫秒，在生产环境可能因为数据量、锁竞争、索引缺失而演变为长时间阻塞，进而拖垮整个业务链路。 常见的风险来源可以归纳为几类： 无审核的直接执行 ：开发或运维人员绕过流程，直接在生产库执行 DDL/DML。 审核只看语法，不看执行计划 ：SQL 能跑通，但未评估扫描行数、是否命中索引、是否触发全表锁。 缺少回滚与备份预案 ：变更失败后无法快速恢复，只能“边救火边猜”。 权限过大 ：应用账号或人

导语：当 LLM 从“对话工具”演化为能够自主规划、调用工具、操作外部系统的智能体（Agent），安全边界也随之从“模型输出是否得体”转移到“系统行为是否可控”。本文围绕提示注入、权限失控与护栏设计三条主线，梳理自主智能体面临的核心安全风险与工程应对思路。 一、从对话到行动：风险性质的变化 传统 LLM 应用的安全关注点，主要集中在输出内容的合规性与准确性上。而自主智能体引入了新的变量： 自主规划 ：智能体可以自行拆解任务、决定执行步骤，而非严格按预设流程运行。 工具调用 ：通过 API、函数调用、浏览器操作、代码执行等方式与外部世界交互。 多轮持续执行 ：在较长的时间跨度内连续行动，单点失误可能被放大。 上下文累积 ：来自网页、文档、邮件、第三方系统的内容会进入上下文，成为决策依据。 这意味着，智能体的输入不

导语 数据治理项目最容易陷入的困境，不是没人做，而是"做了很多，却说不清有没有用"。元数据填了一堆、审批走了一轮又一轮、会议纪要攒了厚厚一摞，但业务侧依然觉得数据不可信、不好找、不敢用。问题往往出在 KPI 的设计上：它衡量的是治理动作有没有发生，而不是治理有没有产生效果。 本文讨论如何把数据治理 KPI 从"流程工作量"转向"治理成效"。 一、为什么流程型 KPI 会失效 流程型 KPI 的典型形态是：完成了多少次数据盘点、录入了多少张表的元数据、发起了多少次质量工单、开了多少次治理例会。这类指标有一个共同特点—— 它们衡量的是投入，而不是产出 。 它带来的副作用通常有三层： 指标可被"刷" ：只要持续发起动作，数字就会好看，与数据是否真的变好无关。 激励方向错位 ：团队把精力放在"完成流程"上，而不是"解决

当数据成为企业决策的「燃料」，一个更基础的问题正在被反复追问：这条数据从哪来？中间经过了谁？为什么最终是这个结果？数据血缘（Data Lineage）试图回答的，正是这些问题。 从一个常见困境说起 在数据驱动的组织里，几乎每个人都遇到过类似的场景： 报表上的一个核心指标突然下跌，业务方追问原因，数据团队却需要花上几天时间，一层层翻查 ETL 任务、SQL 脚本和上游表，才能勉强定位到问题源头； 监管或审计要求说明某个数字的计算口径，团队发现文档早已过时，只能靠「口口相传」来解释； 一次上游字段变更，悄无声息地影响了下游十几张表和多个看板，直到业务侧发现异常才被察觉。 这些困境的共同点是： 数据在流动，但流动的路径没有被记录。 数据血缘要解决的，就是让这条路径变得可见、可查、可追溯。 什么是数据血缘 依据行业通用

导语：大模型靠互联网文本喂大，具身智能却找不到属于自己的「互联网」。当机器人需要学会叠衣服、拧瓶盖、插花、装配零件时，它面对的是一个几乎没有现成数据集的世界。数据，正在成为具身智能从 Demo 走向量产的第一道门槛。 一、为什么具身智能会「缺数据」 过去几年，LLM 的爆发建立在互联网上海量文本、代码和图文对之上。这些数据天然存在、规模巨大、获取成本极低。具身智能面对的情况完全不同： 物理交互数据无法从网页爬取。 抓取一个杯子的力度、手指与物体接触的瞬间反馈、失败后如何调整姿态，这些信息只存在于真实物理世界中。 数据维度更高。 一条具身数据往往同时包含视觉、本体感受（关节角度、力矩）、触觉、动作指令、时间序列等多模态信号，采集和标注难度远高于一段文本。 任务长尾极其分散。 叠衣服、开抽屉、倒水、插线，每个任务的

导语：过去两年，向量数据库从数据库赛道里的一个小众品类，迅速变成 AI 基础设施中最受关注的方向之一。但如果只把它理解为“给 AI 用的新数据库”，其实并没有回答真正的问题——它到底解决了什么传统方案解决不了的事？本文尝试从问题出发，梳理向量数据库的价值边界。 一、先看它出现的背景：非结构化数据突然变得“可计算”了 传统数据库擅长处理的是结构化数据：数字、字符串、时间、枚举，以及它们之间的关系。查询方式也很明确——等于、大于、范围、连接、聚合。 但现实世界里增长最快的数据，恰恰不是这种形态： 文本、图片、音频、视频； 用户行为序列、日志、对话记录； 代码片段、文档段落、知识条目。 这些数据有一个共同点： 它们很难用一两个字段精确描述，也很难用“等于”来检索。 深度学习模型（尤其是 embedding 模型）带来

导语：当数据从采集、加工、流转到消费，链路越来越长、参与方越来越多，"这张表的数据从哪来、改过什么、还能不能信"往往比"数据在哪"更难回答。数据血缘与元数据管理，正是为这个问题提供答案的基础设施。本文围绕概念、价值、落地路径与常见挑战展开梳理。 一、为什么需要一张"可信数据地图" 在数据规模较小、链路较短的阶段，团队往往靠口头约定和文档就能说清数据来源。但随着数仓分层、实时链路、外部数据接入和多方协作的增多，问题会集中暴露： 找不到：同一指标存在多张相似表，不知道哪张是权威口径。 说不清：某张表的上游是谁、下游影响了哪些报表和模型，缺乏系统记录。 不敢改：字段变更前无法评估影响范围，只能靠人工排查。 信不过：数据异常时难以快速定位是源头问题还是加工环节问题。 数据血缘与元数据管理要解决的，就是把"数据资产"变成

过去十六年里，我一直为零售、银行、医疗和保险行业的企业构建数据平台。如果有一条教训不断被验证，那就是：一个优秀的AI模型与一个糟糕的模型之间的差距，通常与模型本身无关，而取决于其输入的数据。

导语：在多数线上故障复盘里，"数据库变慢"往往不是根因，而是结果。真正把系统拖垮的，常常是某一条没有被及时发现的慢 SQL。本文从故障链路、排查方法到优化建议，梳理一套可落地的数据库性能治理思路。 一、为什么一条慢 SQL 能拖垮整个系统 单看一条 SQL，它可能只是"慢了几秒"。但在真实系统里，它的破坏力会被层层放大： 连接被占满 ：慢 SQL 长时间占用数据库连接，连接池被耗尽后，新的请求拿不到连接，只能排队或直接失败。 资源被挤占 ：慢查询往往伴随大量磁盘 I/O、CPU 或内存消耗，拖慢同一实例上其他正常查询。 锁与阻塞扩散 ：涉及写操作的慢 SQL 可能长时间持有锁，导致后续事务阻塞，形成连锁等待。 上游雪崩 ：应用线程被阻塞后，线程池、网关、下游服务依次被拖累，最终表现为"整个系统不可用"。 也就是

导语：过去两年，大模型的能力边界从「生成文字」扩展到「调用工具」，而 GUI Agent 代表了下一次跃迁——不再依赖 API，而是像人一样看屏幕、移动鼠标、点击按钮。这意味着 AI 可以操作那些从未对外开放接口的软件。本文基于公开技术脉络与现有素材判断，梳理 GUI Agent 的能力逻辑、落地场景与潜在风险。 一、什么是 GUI Agent GUI Agent（图形用户界面智能体）指的是能够直接操作图形界面的 AI 系统。它的工作方式接近人类用户： 看 ：通过截图或屏幕画面理解当前界面状态 想 ：结合任务目标，判断下一步该点哪里、输入什么 做 ：输出鼠标点击、键盘输入、滚动、拖拽等操作指令 验 ：观察操作后的界面变化，决定继续、修正还是结束 与传统「API 调用型 Agent」相比，GUI Agent 最大

很多企业谈数据价值，第一反应是上平台、买工具、做看板，却很少先回答一个更基础的问题——我们到底有哪些数据？它们在哪里、归谁管、质量如何、能不能用？ 数据资产盘点不是一次性的台账整理，而是数据价值释放的前置工程。本文给出一套可落地的盘点思路，帮助团队先把家底摸清，再谈挖掘。 一、为什么“先盘点”这件事总被跳过 在数据项目里，盘点往往是最不性感的一环。它不像模型上线那样有即时反馈，也不像可视化大屏那样直观可见。于是常见的路径是：业务提出一个需求，技术团队临时找数、临时对数、临时补口径，项目交付后数据关系再次散落。 这种模式带来的问题会反复出现： 找不到 ：需要的数据不知道存在哪个系统、哪张表。 看不懂 ：字段命名混乱，缺少业务含义说明。 不敢用 ：不知道数据是否准确、是否最新、是否合规。 重复建 ：同一份数据被多个

过去一年，Agent（智能体）几乎成了大模型落地叙事里最热的关键词。与之相伴的，是一张又一张漂亮的评测榜单：任务完成率、工具调用准确率、多轮对话成功率……数字不断被刷新。但真正把 Agent 推进生产环境的人，往往会遇到一个尴尬的现实——榜单上表现优异的 Agent，一落地就容易翻车。 这不是个别现象，而是当前 Agent 评测体系的结构性困局。本文尝试拆解：跑分和落地之间，究竟隔着什么。 一、跑分测的是“能力上限”，落地考的是“稳定下限” 评测榜单通常关心的是：在给定任务上，Agent 能不能做对。 而生产环境关心的是另一件事：在成千上万次真实调用中，Agent 会不会做错，以及做错之后会发生什么。 这两者之间存在天然落差： 评测是抽样，落地是全量。 榜单上的高分往往来自有限任务集，而真实业务的长尾场景几乎无

“我们设了 CDO，但数据的事还是没人能拍板。”这句话几乎成了不少企业数据治理会议上的固定台词。首席数据官（CDO）这个头衔在过去几年被大量写进组织架构图，但头衔本身并不自动带来决策权。数据治理真正的难题，从来不是“要不要设一个 CDO”，而是“当数据标准、数据质量、数据安全、数据共享发生冲突时，到底谁说了算”。 一、先厘清：CDO 的“权”从哪里来 讨论 CDO 的决策权，需要先区分三种不同性质的权力： 所有权（Ownership）：谁对某类数据资产负最终责任。 管理权（Management）：谁负责日常的数据标准制定、质量监控、元数据维护。 裁决权（Decision Rights）：当各方对数据定义、口径、使用范围产生分歧时，谁做最终裁定。 很多企业的问题在于，把这三者混为一谈。设了 CDO，就默认他既拥有