ITPub博客

开发者用 Claude Code、Codex、Qoder 直接生成生产级代码；产品经理用 QoderWorker 、OpenClaw、Hermes完成竞品调研、撰写 PRD；运营人员用 Agent 自动化处理客户工单、生成周报。个人 Agent 已经在真实的工作场景里干活了，“从问答到干活”不再是口号，而是每天的日常。但当企业试图把 Agent 部署到真实业务环境里干活时，问题就来了。上面这些个人

RAG（检索增强生成）是连接企业知识与大模型能力的重要方式。它先从知识库中找到与问题相关的信息，再结合模型生成答案，从而提升回答的准确性和可控性，减少“答非所问”或“凭空编造”的情况。然而，构建一套生产级的 RAG 系统，往往意味着一条冗长的技术链路：需要独立部署向量数据库存储 Embedding，搭建搜索分析引擎做全文检索，再配合关系型数据库管理结构化数据，中间还要维护多套数据同步管道。这种“拼

在构建 AI Agent 时，“上下文窗口限制”和“跨会话状态保持”是两个绕不开的工程难题。许多团队早期的做法是将聊天记录存入数据库，通过关键词检索召回历史数据。但随着数据量增长，这种方案暴露出明显短板：检索精度低（关键词匹配难以理解语义）、噪声大（无效信息占用 Token）、且缺乏自动化的记忆清洗机制。为了解决这一架构缺陷，PolarDB推出了 PolarSearch 记忆容器（Memory C

AI 范式跃迁催生 AI-Native 企业蓬勃发展，这类企业既包括 AI 创业公司和一人公司，也包含传统企业中的创新团队，他们有以下特点和诉求：第一个特点是把 AI Agent 作为核心能力构建产品新护城河。在大模型普适化情况下， AI 上下文（包含记忆、知识、Agent Skills等）成为宝贵资产，因此搭建同时兼容 Single-Agent 与 Multi-Agent 的 AI 上下文基座成

AI Agent 的浪潮不可逆转，问题从来不是”要不要让 Agent 用数据”，而是“如何让 Agent 安全地用数据”。现在正是企业构建 Agent 数据管控体系的最佳窗口期——因为下一个 9 秒删库事件，可能就发生在你的生产环境里。

一、向量检索与 pgvector：数据库里的 AI 能力近年来，大语言模型和多模态 AI 的普及让向量检索成为基础设施级别的能力。语义搜索、图像检索、推荐系统、RAG（检索增强生成）——这些场景的共同点是：需要将非结构化数据（文本、图像、音频）编码为高维向量，然后在海量向量中快速找到与查询最相似的结果。不仅是专用的向量数据库，向量检索也逐渐成为传统关系型数据库中的“标配能力”之一。pgvector

背景OpenRouter 排行榜上正在发生一场换代：Hermes Agent 增速 +204%，Top Coding Agents 排第一，Top Productivity 排第二。上线不到半年，GitHub 从 0 到 106k+ Star。开发者在用数据说话——选的不是"另一个 OpenClaw"，是一种完全不同的东西。区别在哪？OpenClaw 的 Skill 是手写的

DuckDB-paimon 是由 PolarDB 团队开发的一款 DuckDB 扩展插件，让 DuckDB 能够直接读取和查询 Apache Paimon 格式的数据湖表，无需任何 ETL 搬运，无需 Flink/Spark 集群，打开 DuckDB Shell 即可对 Paimon 表执行 SQL 分析。技术交流钉群：164165020808DuckDB-paimon核心能力直接读取 Paimo

DuckDB-paimon 是由 PolarDB 团队开发的一款 DuckDB 扩展插件，允许通过 SQL 直接查询 Apache Paimon 表，无需任何 ETL 搬运，无需 Flink/Spark 集群，打开 DuckDB Shell 即可对 Paimon 表执行 SQL 分析。近期发布 v0.0.3-variegata 版本带来了一项系统性的改进：谓词下推（Predicate Pushdo

在大模型时代，向量检索成了AI应用的基础设施。RAG、智能推荐、以图搜图……几乎每个AI落地场景都绑定着一个核心需求：高效的向量相似性搜索。于是，一批专用向量数据库迅速崛起。但当你真正把它们接入生产系统时，往往会遇到一个尴尬的现实：你的业务数据在MySQL里，向量数据在另一个系统里，中间隔着一条复杂的数据同步链路，还有两套运维体系、两份账单、两种查询语言。有没有可能，一个数据库就够了？PolarD

引言随着企业数字化转型迈入深水区，“数据驱动决策”虽已成为行业共识，但理想与现实之间仍存在一道鸿沟。在大多数企业的日常经营中，这种“数字尴尬”随处可见：销售团队每天录入海量客户数据，却没有人能快速分析出成单规律；运营同学整理了整月的活动数据，面对 Excel 却无从下手；管理者想要一份实时报表，却总要等 IT 部门排期开发……💡 痛点一：「表格易填，分析难」数据越积越多，但能从中挖出价值

本文将从源码层面拆解这套记忆系统的全链路，分析其中的不确定性环节，并介绍 RDSClaw 记忆插件如何补强这些环节，其在LoCoMo10评测中得到了13.90%的提升效果。

在企业落地 AI 应用的过程中，团队往往面临一个尴尬的现实：AI 模型和能力已经就绪，但从"能用"到"团队都能用"之间，还横亘着一道部署与管理的鸿沟。每个成员想跑一个 AI 应用，都得理解底层资源配置、网络拓扑、权限体系，这显然不是高效的协作方式。阿里云 PolarDB 推出的 PolarClaw 企业级 SaaS 服务，正是为解决这一问题而来。它将 AI

引言：数据是AI的"粮草"，但喂起来真费劲2025年，大模型越来越聪明，但很多企业发现：模型再牛，没有好数据也是"巧妇难为无米之炊"。看看这些场景，你是不是也中招了？🤯 场景一：数据散落在"天涯海角"想训练一个行业模型，数据却在MySQL、Oracle、各种Excel、PDF里"各自为政"。你得先当半个月&q

PolarDB-X AI 助手正式上线：分布式数据库运维迈入AI时代今天，我们正式推出 PolarDB-X AI 助手（PolarDB-X AI Agent） —— 一款专为分布式数据库打造的智能运维助理。面对跨分片 SQL 优化、分布式事务诊断、多节点扩缩容等复杂运维挑战，企业常受限于 DBA 资源稀缺、排查链路冗长和人为误判风险。PolarDB-X AI 助手深度集成于 P

标题：当龙虾退烧，我们终于可以聊聊真实生产的事儿了有人说 OpenClaw 只是极客的玩具，新鲜劲一过就该撤火了。而外界在谈论它是否过时，我们正忙着帮它撕掉“玩具”的标签，把这只“虾”直接送进企业的生产线。4月11日，北京。我们带来 OpenClaw 的一次硬核“物种进化”。潮水退去后过去两场线下活动，大家玩得尽兴，但也留下了不少灵魂拷问：“Demo 跑得欢，真要把生产数据库交给它，安全谁负责？”

流量暴涨100倍，PolarDB-X 稳如磐石。夸克与千问"长记忆"背后的存储底座，峰值20万TPS，从容应对。20万TPS，100倍流量洪峰，0次抖动。千问大模型的记忆，交给 PolarDB-X。在大模型服务与智能体全面普及的今天，记忆已不再是锦上添花的功能，而是赋予 AI 真正智能、个性化体验与连续交互能力的核心基石。处理海量记忆数据时，高并发写入、多维

1.为什么你的龙虾需要记忆记忆是区分 Agent是"玩具"还是"生产力工具"的分水岭。没有记忆，Agent 每次对话都从零开始——你周一告诉它"我正在学 Rust"，周三它就忘了。有了记忆，Agent 能持续积累对用户的理解：偏好、决策历史、项目上下文，越用越"懂你"。企业场景中记忆的价值更加显著：智能客服记住客户历史

引言当你对千问说一句"帮我点杯霸王茶姬的伯牙绝弦，少糖去冰，送到公司"，背后的 AI Agent 需要在数秒内完成意图识别、地址解析、商品搜索、规格匹配、加购下单等一系列操作。整个过程涉及多轮对话、多次工具调用，每一步都依赖对"之前发生了什么"的准确记忆。这就是 AI Agent 的短期记忆问题。在淘宝闪购与千问合作的"一句话点外卖"项目

如果你也曾盯着 OpenClaw 回复的一句"Done"，不知道它到底做了什么——你并不孤单，我们也曾经历过。于是我们基于DuckDB为 OpenClaw 构建了一套可观测插件，把原本不可见的 Agent 执行过程结构化记录下来，让每一次对话从黑盒运行变成链路透明。故事从一次真实的排障经历说起。一、起源：从一个只有“Done”的回复说起故事发生在我们部门内部的一个自动化场景中。