8 月 29 日，Unstructured Data Meetup 再次来到上海。这个从 2024 年开始举办的技术社区活动，一直围绕非结构化数据展开，但今年现场讨论的问题已经明显发生了变化。过去谈非结构化数据，核心问题往往是如何在海量数据里更快、更准地完成检索。到了今天，向量搜索已经很少作为一个孤立的问题出现，开发者需要处理的是一整套更复杂的数据问题：在线检索和离线计算如何共存，知识如何持续更新，Agent 如何寻找合适的工具和经验，历史交互又如何沉淀成可以跨任务复用的长期记忆。Zilliz 从 Milvus 3.0 的架构变化出发，讨论向量数据库为什么开始走向 LakeBase；东方财富回顾了从图片搜索、Hybrid Search、知识库到 Agent 的多年实践；CelHive 将问题推进到 Agent Harness，讨论一次成功任务如何沉淀为 Skill 和 Agent；EverMind 则进一步拆解长期记忆系统，以及 Memory 如何从某个 Agent 的附属功能，变成独立的数据基础设施。01 Zilliz：从 Vector Database 到 LakeBase，Milvus 3.0 在解决什么问题？
Zilliz 开源社区负责人李成龙带来的主题是《Beyond Vector Search：Milvus 3.0 的 LakeBase 架构演进》。今年 8 月发布的 Milvus 3.0，是继 2021 年 Milvus 2.0 之后时隔五年的大版本更新。这次升级更值得关注的是 Milvus 对自身定位的调整：从一个以 Vector Database 为核心的系统，进一步走向以非结构化数据和语义计算为中心的 Vector LakeBase。这种变化首先来自数据规模和 workload 的变化。AI 应用持续产生文本、图片、视频、音频等非结构化数据，而这些数据真正进入生产以后，不仅要完成 Embedding 和在线搜索，还要承担数据清洗、去重、聚类、模型升级、Schema 演进和批量计算。传统向量数据库擅长的是高并发、低延迟的在线 Top-K 检索，但当数据进入十亿、百亿向量甚至更大规模以后，将所有数据完整搬入数据库、持续维护高性能在线索引，成本会越来越高。与此同时，真实业务中的搜索也不再只是“找最相似的 K 条数据”，而是开始同时依赖关键词、标量过滤、排序、聚合以及多向量检索。Milvus 3.0 对 Lake 能力的扩展，正是为了覆盖过去不属于传统向量数据库主战场的 workload。通过 External Collection 等能力，已经以 Parquet、Lance 等格式存在于对象存储中的数据，可以在尽量不移动原始数据的情况下被映射进 Milvus 的查询体系。对于几十 TB、数百 TB 甚至更大规模的数据，这一能力升级尤为重要。Snapshot 则解决了另一类典型问题。在一个持续写入的在线系统中，数据可能同时面临聚类、去重、Embedding 重算等离线任务。如果两类 workload 直接作用在同一份不断变化的数据上，不仅结果难以保持一致，也容易相互争抢资源。通过创建 point-in-time Snapshot，可以固定某个时刻的数据视图，在在线 Serving 不停止的情况下，让批处理基于稳定的数据版本继续运行。对于 Embedding 模型升级，这个升级意味着当企业需要从旧模型切换到新的 Embedding 模型时，可以基于稳定快照重新生成向量，并通过新字段、别名或表切换逐步完成迁移，而不是把整个在线系统停下来重建。与 Lake 一侧同步扩展的，还有 Base 本身的查询能力。Milvus 3.0 加入或强化了 Search / Query Order By、Query Aggregation、Search Aggregation、StructArray、EmbeddingList 等功能。这里反映出的趋势是，向量正在从数据库里的“特殊对象”，逐渐变成复杂查询中的一种基础数据类型。以 StructArray 为例，过去一篇文档被切成多个 Chunk 后，每个 Chunk 往往都需要重复存储作者、时间、来源等 Metadata；现在可以让一个实体内部保存多个向量元素，共享文档级元数据，同时继续支持元素级和文档级搜索。这不仅减少了重复存储，也更适合多向量模型和 late interaction 一类检索方式。长期来看，Lake 和 Base 两侧 workload 的融合已经非常明显。一端是需要数千 QPS 和稳定低延迟的推荐、知识检索、个人记忆，另一端是训练语料去重、自动驾驶 Corner Case 挖掘等数据规模大、运行频率低但计算量非常高的任务。它们过去往往分别落在在线数据库和离线数据平台，而 Milvus 3.0 所谓 LakeBase 的核心方向，就是尝试让 Continuous Serving 与 Continuous Improving 落在更加统一的数据基础设施上。02 东方财富：从图片检索、Hybrid Search 到 Agent 的六年实践
相比从数据库架构出发讨论未来，东方财富 AI 研发工程师张松的分享更像是一条真实业务推动下的技术演进路径。东方财富从 2020 年开始将 Milvus 应用于社区图片搜索，此后逐步扩展到综合搜索、知识库和 Agent。回头看这几年的变化，可以清晰看到向量检索从一个局部能力，逐渐变成企业 AI 数据底座的一部分。最早的问题来自图片。对于拥有大量用户内容的金融社区来说，图片一旦被裁剪、压缩或重新传播，MD5 等文件特征就会变化，无法有效识别相似内容；图片中的文字和人物信息也无法依靠普通文本搜索直接参与检索。东方财富因此逐步建立了图片 Embedding、OCR 倒排索引和人脸 Embedding 三路检索能力，让相似图片、图片文字和人物线索进入一套统一的召回流程。这个阶段的向量数据库仍然主要解决一个明确的搜索问题，但它验证了语义特征可以把传统检索无法利用的信息纳入搜索系统。后来，随着资讯、研报、公告、文章、图片和表格数据不断增加，搜索问题开始变得更加复杂。传统倒排索引擅长精确关键词匹配，但用户的查询表达和文档用词并不总是一致，单纯靠关键词很难覆盖语义相关内容。东方财富因此逐步引入向量召回，并将其与倒排索引、条件过滤和重排结合，形成 Hybrid Search。其中倒排负责找得准，向量负责找得广，过滤负责保证业务边界.随着搜索本身开始变成一条完整的数据和决策链路。上游需要统一清洗和解析资讯、研报、公告、图片、表格等多种数据格式，并通过 Chunk、Embedding 和 Metadata 定义最小检索单元；用户查询进入系统后，又要经过 Query Rewrite、实体识别、意图识别、向量生成、多路召回、融合、去重、Rerank，以及时效和业务权重等处理。真正决定搜索质量的，已经不只是某一种索引，而是整条链路是否能够持续评估和迭代。企业知识库让这一点更加明显。PDF、PPT、Word、Excel、HTML、表格和图片需要经过统一解析，标题、段落、表格、图片与原始文档之间的对应关系需要尽可能完整地保留下来，再进一步构建段落级、表格级甚至行级索引。这样做的目标不只是召回内容，还要让最终答案能够追溯到原始来源。东方财富目前已经构建了数亿级向量规模的数据底座，并通过不同数据集和冷热分层等方式，为搜索、知识库和其他 AI 应用持续提供检索能力。而到了 Agent 阶段，检索能力开始进入更广泛的运行环节。长期记忆需要从历史数据中找到相关事实、用户偏好和执行经验；Skill 和 Tool 选择需要从能力库中召回候选；知识和上下文需要根据当前步骤动态注入；类似任务的历史轨迹和反馈，也可以成为下一次规划的重要参考。向量检索因此不再只是 RAG 中的一条召回链路，而成为连接知识、Memory、Skills 与上下文的通用能力。03 CelHive：如何让 Agent 的一次成功，变成可复用的企业能力？
CelHive 核心成员 Daniel 的分享把问题从“如何找到信息”进一步推进到了“如何复用经验”。对于企业 Agent 来说，完成一次任务只是最基本的要求。真正具有长期价值的系统，不应该每次都从零开始理解需求、尝试工具和摸索流程，而应该能够把已经验证有效的工作方式沉淀下来，在下一次类似任务中继续使用。Daniel 将这种机制称为“智能复利”。这里的复利并不是模型在后台自动训练、变得越来越聪明，而是每一次 Agent 执行以后，都留下一些下一次可以被检索、验证和复用的资产。一次成功任务里真正有价值的信息，除了最终交付物，还包括用户最初的目标和限制、系统做过哪些判断、调用了什么工具和 Skill、哪些路线失败过、用户修正了哪些地方，以及最终哪套流程被确认有效。这也是为什么在 CelHive 的 Agent Harness 里，Thread 和 Branch 不只是聊天记录。原始对话中包含大量临时讨论、试错、错误调用甚至敏感信息，如果将整段历史直接作为“经验”保存，不仅噪声很大，也很难稳定复用。系统需要从成功的执行路径中提取更高价值的信息，形成一个 Source Snapshot，再以此生成 Skill 或 Agent。Skill 更偏向一个可以重复执行的工作方法，需要明确输入、步骤、工具边界、输出要求和异常处理；Agent 则进一步带有职责、权限和可访问资源，描述“谁能够在什么边界内完成这类任务”。这一步非常接近软件工程里的“编译”：经验不是被原样复制，而是被转化为更稳定、约束更清晰的可执行能力。也正因为如此，企业里的 Agent 自进化不可能完全脱离治理。一个由模型自动生成的 Skill，即使看起来效果不错，也不能直接进入生产。它需要经过 Draft、验证、确认和注册，再由 Runtime 根据版本、权限、状态和策略决定是否允许调用。能力可以持续生成，但信任边界不能跟着模型一起自动漂移。随着系统中 Agent、Skill、Memory 和运行证据不断积累，一个新的基础问题随之出现：如何从越来越多的能力中找到当前真正应该使用的那一个？这与普通语义搜索并不相同。例如错误码、产品名和版本号需要精确匹配，某个 Skill 可能只允许特定团队或项目使用，旧版本即使语义上最相似，也可能已经被撤销。候选能力不仅要经过向量和关键词召回，还需要根据 Metadata、权限、版本状态、历史效果和新鲜度继续过滤和重排。因此，Milvus 在 CelHive 中承担的是 Memory、Capability 和历史运行证据的一层统一检索底座。它负责把庞大的搜索空间缩小到一组候选，真正能否执行，则继续交给 Registry 和 Runtime 判断。整套机制最后形成一个闭环：任务执行产生经验，经验被编译为能力，能力通过检索再次进入新任务，在实际运行中继续接受反馈和验证。从这个角度看，所谓 Agent 的“智能复利”，本质上不是让每个模型调用都更加复杂，而是让组织已经付出过的探索成本不再一次次浪费。04 EverMind：当 Memory 独立于 Agent，长期记忆系统该如何构建？
EverMind 开发者生态艾略特最后把讨论推进到了 Memory。在他看来，Context 是当前做饭时已经放到操作台上的食材，解决的是这一轮任务“现在能看到什么”；Memory 则是整个冰箱和背后的管理规则，除了存什么，还需要知道东西在哪里、什么时候放进去、是否已经发生变化，以及什么时候应该再次取出来。这一区分对于 Agent 很重要，因为很多所谓长期记忆，本质上仍然是在不断扩大 Context Window，或者简单把聊天历史重新塞给模型。真正的 Memory 系统面对的是另外一组问题：哪些信息值得跨 Session 保存？新的事实出现后，是新增一条还是更新旧记录？哪些记忆属于用户，哪些属于 Agent，哪些是某一次具体事件产生的 Episodic Memory？不同设备和不同 Agent 之间是否应该共享？随着历史不断增长，系统又如何只召回与当前任务真正相关的部分？EverOS 的一个核心思路，是把“记忆本身”和“记忆索引”拆开。Markdown 等人类可读格式用于保存可以被用户检查和修改的事实，SQLite 等组件负责管理状态，向量索引则承担快速检索。这里有一个很重要的原则：即使向量索引丢失，原始 Memory 也应该仍然存在。Embedding 模型、向量数据库和检索算法都可能随着时间变化，但一个用户已经积累多年的长期记忆，不应该因为底层索引升级而失去可迁移性。这也使 Memory 与前面 Milvus 3.0 中提到的数据演进问题形成了呼应。当 Embedding 模型改变时，真正需要重新生成的是索引表示，而不是用户事实本身。如果 Memory 从一开始就是一个独立的数据层，那么模型升级、索引替换和不同 Agent 之间的切换，都可以围绕同一份长期数据继续进行，而不是重新从聊天记录里“找回自己”。当长期记忆从单机、单用户扩展到多设备、多 Agent 和企业平台之后，Milvus 这样的向量数据库开始体现更大的价值。一个小型个人 Memory 系统可能只需要本地向量索引，但平台级系统需要面对持续写入、租户隔离、权限过滤、越来越大的数据规模以及稳定的检索延迟。此时 Memory Retrieval 也不应该只是一条纯向量 Top-K，而更接近 Filter、Recall、Rerank：先根据用户、租户、项目和记忆类型限制搜索范围，再用语义和关键词找到候选，最后结合当前任务重新排序。EverMind 目前围绕这一思路发展 EverOS、EverMe、Raven 等不同项目，其中 Raven 进一步把 Memory 与 Deep Research、Agent Harness 等能力结合起来。比具体产品更值得关注的，是背后对 Memory 角色的重新定义：长期记忆不一定应该从属于某一个 Agent。当用户在 Codex、Claude Code、其他 Agent 甚至不同设备之间持续切换时，如果 Memory 仍然绑定在某一个应用里，每换一次工具都意味着重新建立上下文。相反，一旦 Memory 变成独立层，Agent 就从“记忆的所有者”变成了“记忆的使用者”。 