ITPub博客

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

过去十年，RPA（Robotic Process Automation，机器人流程自动化）帮助企业把大量重复、规则明确的桌面与后台操作交给“软件机器人”执行。它擅长的是“照着脚本做”，却难以应对界面变化、非结构化数据和需要判断的环节。与此同时，以大模型为内核的 Agent（智能体）技术快速成熟，具备理解、规划、调用工具和自主决策的能力。当两者走向融合，自动化正从“流程自动化”迈向“智能自动化”。 一、先厘清：RPA 与 Agent 各自擅长什么 RPA 的核心能力： 基于固定规则执行重复性操作，如数据录入、表单填写、文件搬运、系统间对账。 通过录制或脚本编排，稳定复现既定流程。 优势在于确定性高、执行速度快、可审计。 RPA 的局限： 强依赖界面元素和固定路径，UI 一变就可能失效。 难以处理非结构化信息，如自

当大模型从“一次性问答”走向“持续协作”，记忆就成了 Agent 能否真正落地的分水岭。本文从工程视角拆解 Agent 记忆系统的三层结构——短期记忆、长期记忆与向量数据库，讨论它们各自的职责、边界与组合方式。 一、为什么 Agent 需要“记忆” 一个没有记忆的 Agent，无法记住用户上一轮说过的偏好，无法积累任务执行中的中间结论，也无法在跨会话的场景里保持连续性。 当 Agent 被用于客服、编程助手、个人助理、自动化工作流等场景时，“记住什么、记多久、怎么取回来”就变成了核心的架构问题。记忆系统要解决的不是“存不存”，而是在有限的上下文窗口和推理成本下，如何让正确的信息在正确的时刻回到模型面前。 业界通常把 Agent 记忆划分为短期记忆与长期记忆两大类，而向量数据库是长期记忆中语义检索的常见基础设施。

当机器人从“知道自己在哪”走向“理解自己要去哪、为什么去”，导航这件事正在经历一次范式迁移。SLAM 解决了几何定位与建图的基础问题，而具身智能的兴起，正在把导航推向语义空间智能的新阶段。 一、导航问题的起点：SLAM 解决了什么 在讨论具身导航之前，需要先厘清它的技术底座。 SLAM（Simultaneous Localization and Mapping，同步定位与建图）长期是移动机器人自主性的核心。它要回答的是一个相对“纯粹”的问题：机器人在一个未知环境中，如何一边估计自身位姿，一边构建环境地图。 围绕这个问题，业界形成了一些技术路径： ·激光 SLAM：以激光雷达为主要传感器，几何精度高，在结构化环境中稳定可靠。 ·视觉 SLAM：以相机为主要传感器，成本低、信息丰富，但对光照、纹理和动态场景敏感。

在模型能力日益依赖数据驱动的今天，“好数据”与“坏数据”的边界却常常模糊。本文尝试从可操作的维度出发，梳理一套AI训练数据质量评估体系，帮助团队在数据采集、清洗与迭代中建立共识。 一、为什么“好数据”难以定义 在AI项目实践中，一个反复出现的困境是：团队投入大量资源采集和标注数据，模型效果却未达预期；而有时数据量并不庞大，模型表现却出奇地好。这背后指向同一个问题——数据质量缺乏统一、可量化的评估标准。 “好”与“坏”本身是相对概念。对某个任务而言的优质数据，换一个场景可能毫无价值；对某个模型规模而言足够的数据，换一个参数量级可能远远不够。因此，讨论数据质量，必须先明确评估的语境与目标。 一个可行的思路是：不追求绝对意义上的“好数据”，而是建立一套多维度、可打分、可对比的评估框架，让数据质量从主观感受变为可讨论的

当大模型从“回答问题”走向“执行任务”，Agent 需要的不只是语义相似度，而是对实体、事件与因果链条的结构化理解。图数据库与 GraphRAG 正在成为补上这块能力短板的关键拼图。 一、为什么 Agent 需要“关系”而不只是“文本” 传统 RAG（Retrieval-Augmented Generation）的核心逻辑是：把文档切块、向量化，再按语义相似度召回若干片段拼接进上下文。这套方法在“找一段相关描述”时表现不错，但一旦任务涉及多跳推理，就会暴露短板。 典型场景包括： 多跳问答：A 公司的子公司 B 的负责人同时任职于 C 机构，这类问题需要跨多个实体跳转。 全局性总结：如“这批文档里反复出现的核心矛盾是什么”，向量召回只能拿到局部片段，难以覆盖整体结构。 Agent 任务规划：Agent 要调用工具

过去几年，人工智能的安全讨论大多发生在数字世界：模型幻觉、数据泄露、提示词注入、生成内容合规。但当 AI 被装进机械臂、移动底盘、无人机和人形机器人，开始与真实物理世界发生接触时，安全问题的性质发生了根本变化——一次错误输出不再只是“说错话”，而可能是一次碰撞、一次夹伤、一次不可逆的物理伤害。 具身智能（Embodied AI）把感知、决策与行动闭环压缩进同一个系统，对安全提出了新的挑战。本文围绕物理伤害、对抗攻击与伦理三条主线，梳理具身智能安全的核心议题与应对思路。 一、为什么具身智能的安全问题不同于传统 AI 传统 AI 系统的输出是信息，具身智能系统的输出是动作。这一差别带来三个结构性变化： 不可逆性：文本可以撤回，机械动作造成的物理损伤往往不可逆。 实时性约束：机器人必须在毫秒到秒级完成感知—决策—执行