湖生万物：面向Agent的全模态数据平台实践与选型

云栖2026 现场，比往年多了不少 Agent 的展板和 Demo，但我在展区里真正关注的，反而是一些不太上镜的东西——数据管道、检索接口、湖仓引擎、记忆存储。逛了一圈下来，和做 Agent 应用的朋友聊得越多，越觉得"湖生万物，助力 AI —— 面向 Agent 的全模态数据平台"这个主题不是一个宣传口号，而是把当前 Agent 落地最硬的一块短板摆到了台面上：模型能力已经跑在了前面，数据和知识供给却常常拖后腿。

这篇文章不打算复述大会议程，而是想聊聊我从云栖2026 现场带回来的判断：Agent 为什么突然需要"全模态数据平台"？这样的平台到底要怎么搭？以及在真实项目里落地时最容易翻车的几个细节。如果你正在做 Agent 应用、RAG 系统、数据中台，或者只是好奇"AI 的数据基础设施长什么样"，这篇文章应该能给你一些可以直接拿去用的思路。

1. 云栖2026现场的"数据焦虑"：Agent 饿着肚子跑不动的老问题

1.1 模型能力不是瓶颈，数据喂养才是

今年会场里，各家的 Agent 都在演示复杂的推理链路：让它做竞品分析，它能自己拆解任务、调用工具、生成报告；让它处理工单，它能自动分类、回复、流转。表面上看，大家比拼的是模型参数、推理框架、提示词工程，但私下聊到生产环境时，所有人都在问同一个问题：数据从哪来？质量怎么保证？更新频率能不能跟上？

我印象很深的一幕是，某厂商在公开 Demo 里展示一个工具调用型 Agent，让它查询最新的优惠活动给用户推荐。头两次调用都很顺畅，第三次突然答非所问。工作人员调试了半天，原因很简单：活动数据在数据仓库里是有了，但 Agent 检索的接口读的还是几小时前的旧索引，新活动根本没进去。这个场景在展会上一闪而过，却是很多 Agent 项目的日常。模型本身并不笨，问题出在它"看不见"最新、最全、格式最合适的数据。

这也是为什么我在标题里用了"数据焦虑"这个词。过去几年大家拼的是算法，现在算法差距被迅速拉平，真正决定一个 Agent 能不能在生产环境里稳定跑起来的，是背后的数据供给体系。模型是你请来的大厨，数据平台则是后厨——后厨出菜慢、食材不新鲜，再好的大厨也做不出好菜。

1.2 "湖生万物"到底在讲什么

"湖生万物"这四个字，细看其实很有意思。它明显是从 Lakehouse（湖仓一体）这个概念延伸出来的，但表述上比技术词汇更接近生态：湖里养的不仅是结构化表格，而是几乎一切形态的数据——文本、图片、音视频、日志、接口返回、传感器时序、甚至 Agent 自己的交互轨迹。这些数据落进湖里之后，不是躺在那里吃灰，而是能生长出各种各样的 AI 应用：给 Agent 当知识库、当记忆存储、当工具返回结果的暂存区、当训练集的原料仓。

我理解"湖生万物"至少对应了三个层面的含义：第一是沉淀，原始数据以很低门槛进湖，不要求一开始就建好模型；第二是加工，湖仓引擎能提供事务、更新、增量处理能力，让数据可以持续被清洗和标注；第三是供给，通过统一目录和 API 把数据以 Agent 能理解的方式暴露出去。现在的数据平台如果还停留在"给人看的报表工具"，那它和 Agent 之间一定有一条巨大的鸿沟。而全模态数据平台要做的，就是把这条鸿沟填平。

2. 从多模态到全模态：Agent 的数据胃口为什么变了

2.1 全模态不只是多了一种数据类型

"多模态"这个词大家已经很熟悉了，一般指文本、图片、音频、视频这几种常见媒体类型。但"全模态"不是简单的加法，它强调的是更接近业务原始状态的所有数据形态。在我的实践里，至少包括这些：结构化业务表、非结构化文档、音视频转写片段、图片和扫描件、代码仓库的 commit 与 diff、系统日志和调用链 Trace、物联网传感器时序数据、3D 点云、基因序列、CAD 图纸等等。

关键差异不只是"种类更多"，而是两个容易被忽视的点：原始性和机器可读性。传统数仓会把数据层层加工成宽表，方便人类用 BI 工具看；全模态数据平台则尽量保留原始副本，同时为每种模态建立适合机器消费的索引和描述。举个例子，一个质检场景里的 Agent，可能需要同时读取产品图片、传感器曲线和维修日志。如果你是先把所有数据压成一张结构化宽表再给 Agent，那就把大量信息丢了；正确的做法是原始数据在湖里保留，平台提供多路索引，让 Agent 按需去取不同模态的片段。

2.2 Agent 消费数据的三类模式

要做到"面向 Agent"，先得想清楚 Agent 到底怎么用数据。我从实践中总结出三类模式，三种模式对平台的要求完全不一样。

第一种是检索式消费。Agent 在回答一个具体问题前，先去知识库里检索相关资料，再结合上下文生成答案。这类消费要求平台有比较强的索引能力，关键词搜索、向量召回、知识图谱关联都要支持。而且实时性很重要：如果企业政策半小时前刚更新，Agent 还拿着昨天的版本回答，用户立刻就会失去信任。

第二种是记忆式消费。Agent 和自己的用户之间会有多轮对话，还会跨会话记住用户的偏好和已经确认过的事实。这里数据平台不只要存储聊天记录，还要能把"短期上下文"沉淀成"长期事实"。我会在第四章专门展开讲这个，因为不少团队把聊天记录直接当记忆用，效果非常差。

第三种是工具式消费。Agent 调用内部 API、数据库或外部服务时，返回的是 JSON、文件、状态码这类半结构化数据。平台需要把这些瞬时数据捕获下来，打上时间戳和关联 ID，再决定是暂存、归档还是回收到湖里。没有这类机制，Agent 每次工具调用的结果都会变成"用过即丢"的黑洞，既没法复盘，也没法变成新的训练语料。

三类模式对平台的要求合在一起，基本上就是一个"全模态数据平台"的产品需求文档：能存各种格式，能建各种索引，能管生命周期，能跟 Agent 的运行框架之间做双向接口。这也是为什么我觉得传统数据仓库和单纯的对象存储，都没法在 Agent 时代独立扛起供给全责。

3. 湖生万物：Lakehouse 底座如何承载全模态数据

3.1 数据架构演进：从仓库、湖到"全模态湖仓"

要做面向 Agent 的全模态数据平台，底座还是绕不开湖仓架构。简单回顾一下演进过程就能明白为什么。传统数据仓库擅长存储和计算结构化数据，强一致、好治理，但对非结构化数据基本无能为力，而且存储成本不低。数据湖用对象存储解决了"什么都往里扔"的问题，成本低、格式自由，可早期版本在事务性、更新、删除上很弱，慢慢就暴露了"数据沼泽"的毛病。湖仓一体（Lakehouse）把数仓的事务能力和数据湖的灵活存储结合起来，才有了今天的局面。

到了 Agent 时代，湖仓底座面临的考验又升级了。Agent 需要的数据不只是表格，而是文档片段、图片块、音视频切片、日志序列。这些数据同样需要事务保证、增量更新、权限控制。如果还是像老数据湖那样"put 一个文件进来就不管了"，Agent 根本没法信任这些数据。因此我在落地时会把"全模态湖仓"理解为：以对象存储为底座、以开放表格式（比如 Apache Iceberg 或 Delta Lake）提供事务能力、以统一 Catalog 组织元数据，对上再叠加索引和语义层。这样既保住了大数据生态的扩展性，又能把治理能力延伸给 AI 应用。

3.2 关键选型：存储格式、索引与语义层

全模态湖仓里最基础的一层是存储格式。结构化数据我建议用列式格式，比如 Parquet 或 ORC，查询效率和压缩比都更好；原始文件和媒体文件继续放在对象存储里，做冷热分层，热数据用高频访问的存储类型，冷数据转到归档档位，成本能差好几倍。音频和视频这类大文件，则要在存储之外额外维护一个转写和抽帧索引，把它们变成"可以被检索的片段"。

元数据层要统一，否则一定会出现"数据在里面但找不到"的问题。一个内部共建的 Catalog 至少得管三样东西：表或文件集合的位置，字段和语义描述，数据的分区与版本。在这之上，我强烈建议加一个语义层。这是"面向 Agent"和"面向人"最大的区别：Agent 需要的是机器可读的接口描述，比如"这张表代表客户，主键是 customer_id，状态字段有这些枚举值，创建时间在 update_time"。把这些描述暴露给 Agent，它才知道该用什么参数去查、怎么理解返回结果。不少项目把 Agent 直接接到一张巨大的明细表上，Agent 根本不知道该选哪些列，效果自然一塌糊涂。

索引设计上，全模态平台的检索请求往往是混合的：先根据关键词和元数据过滤，再做向量相似度召回，最后按业务规则排序。所以平台上需要同时存在倒排索引、向量索引，以及数据目录里的标签索引。这三类索引不是互相替代，而是要在一个统一检索 API 下面被编排起来。我见过一些团队把所有希望寄托在向量数据库上，忽略了关键词和元数据的组合过滤，结果召回精度惨不忍睹，其实问题出在索引结构单一。

3.3 "湖生万物"的工程内涵

为什么说"湖"能"生万物"？不完全是比喻，它背后有工程机制。湖仓架构最大的特点之一就是 schema-on-read：数据进来时不强制建模型，等要用的时候随时定义读取结构。这对全模态数据特别友好。你永远无法在第一天就预知 Agent 明天会拿这些数据做什么，所以先沉淀、后加工就是最稳妥的姿势。

另外，开放表格式提供的时间旅行（time travel）能力，让"湖生万物"有了更现实的意义。Agent 在不同时间点提出问题，应该拿到对应时间点的数据快照，而不是被后续更新污染。比如复盘"上个月为什么这个 SKU 退货率变高"，Agent 就应该读取上个月底的数据状态，而不是今天的表。很多 Agent 应用忽略了这一点，拿着最新表回答历史问题，在数据分析场景里就会闹笑话。湖仓的时间旅行机制，恰好能把这个能力以很低的成本提供给上层应用。

4. 面向 Agent 的数据供给链路：检索、记忆、评估与回流

4.1 RAG 检索在平台层怎么做才对

先说说最常用也最容易做糙的 RAG。很多项目把文档丢进一个向量库就开始联调，结果回答质量忽高忽低。平台化的 RAG 至少要考虑三个设计点。

第一是切分策略。固定 512 字切一刀是省事，但语义会被切断。我实践中更推荐混合粒度：一个知识条目同时保留"小段"和"整篇"两个版本的索引，作为全局标准，检索时优先用小段保证精确召回，没有结果或需要背景时才回退到整篇。这样既照顾了精度，又不会丢失上下文。

第二是元数据过滤。不要把所有文本塞进同一个向量空间里。每个 chunk 在入索引库时，要带上来源、时间、部门、文档类型、权限标签等元数据。Agent 发起检索时先根据场景过滤这些元数据，再在缩小后的集合里做向量召会。这不仅能提升精度，也是后面做权限控制的前提——先过滤，再召会，才能保证 Agent 只能看到它有权限看的内容。

第三是增量更新。企业内部数据实时性要求高的场景很多，比如价格调整、策略公告、库存变更。平台层要做一条增量管道，从源系统捕获变更，把更新后的内容切分、向量化、写回索引库，整个链路尽量控制在分钟级。那个展会上 Demo 翻车的本质原因就是只做了全量同步，没做增量。全量同步适合晚间批处理，白天靠它支持 Agent 是肯定不行的。

4.2 记忆系统：不要把聊天记录直接当记忆

Agent 的记忆系统是个很容易被低估的工程问题。我看到不少团队的早期实现就是"把对话记录存起来，再在上下文中拼进去"。这种做法的问题很多：原始对话噪声大、事实会随时间变化、重要信息淹没在客套话里。真正的记忆系统应该分层管理，我一般分为四层。

短期上下文是当前会话里的对话和状态，存 Redis 或类似的高性能存储，TTL 设置在会话结束加一小段时间即可。情景记忆是用户和 Agent 之间发生过的完整事件摘要，比如"上周用户反馈过订单 12345 缺货"，由平台定时从原始对话里抽取摘要。语义记忆是沉淀下来的稳定事实，像"用户偏好晚间配送""公司发票抬头是 XX"，这类信息建议建成结构化的实体属性和关系，而不是纯文本。程序化记忆更特殊，它记的是 Agent 应该怎么做事，比如"处理退货时先校验订单状态"，本质上是一些工作流配置。

平台要给记忆系统提供统一的读写 API，而且一定要设计遗忘机制。Agent 记忆越堆越多，迟早会互相矛盾或者过时。比较现实的方案是给每条记忆打上置信度、来源、时间戳，周期性让模型做一次"记忆巩固"：把重复的合并、把冲突的消解、把过期的归档。下面是一个简化示例，大概能说明记忆存储该长什么样：

CREATE TABLE agent_memories ( memory_id VARCHAR(64) PRIMARY KEY, agent_id VARCHAR(64) NOT NULL, user_id VARCHAR(64) NOT NULL, memory_type ENUM('session', 'episodic', 'semantic', 'procedural') NOT NULL, content JSON NOT NULL, confidence FLOAT NOT NULL DEFAULT 0.5, source_ref VARCHAR(256) NOT NULL, valid_from TIMESTAMP NOT NULL, valid_to TIMESTAMP, created_at TIMESTAMP NOT NULL, updated_at TIMESTAMP NOT NULL ); CREATE INDEX idx_memories_user_type ON agent_memories(user_id, memory_type); CREATE INDEX idx_memories_updated ON agent_memories(updated_at);

这里最关键的是 source_ref 字段。每条记忆必须能溯源到原始数据片段，Agent 引用记忆时，平台才能判断它讲的是事实还是编造。有了这一列，很多矛盾都能在回溯时快速定位。

4.3 数据回流：Agent 的输出变成新的语料

全模态数据平台和前几代数据架构的一个明显区别，是必须把回流当成一等公民。Agent 本身就是数据生产源，它每跑完一次任务，留下的日志、中间结果、工具调用轨迹、人类反馈，都是下一轮迭代的宝贵语料。我见过不少团队把 Agent 上线的终点定义为"功能跑通"，结果模型和知识库一直停在原地，越用越吃力。

回流管道的设计其实不复杂，核心是先把 Agent 运行时产生的数据完整接住，再分层清洗。我项目里用过的简化结构大致是这样：Agent 执行时通过统一的日志接口把轨迹发送到消息队列，另一个消费程序再把它写入湖仓的 raw 区。接着跑清洗任务，把用户问题、Agent 回答、工具返回结果、用户是否采纳这些字段抽出来，命中错误或低评分的样本单独打标。最后再对这些高质量样本做向量化、索引更新，作为后续微调或评测的候选集。

def process_agent_log(raw: dict) -> dict: return { "trace_id": raw["trace_id"], "user_query": raw["user_query"], "agent_reply": raw.get("agent_reply", ""), "tool_calls": raw.get("tool_calls", []), "final_answer": raw.get("final_answer", ""), "feedback": raw.get("feedback", 0), "occurred_at": raw["occurred_at"], }

回流不是"存个日志"就完了，真正的闭环要落在应用上：这批数据下一步要么进入离线评测集，要么进入 RAG 的知识库更新队列，要么成为模型微调样本。如果回流之后永远是苦等人工处理，那这个闭环就是摆设。

4.4 评估集与数据质量门禁

判断全模态数据平台好不好用，不能靠感觉。我始终坚持一个原则：每个改动都要有评测集来对照。对 Agent 场景来说，至少要有三类评测数据。第一类是从生产日志里采样出的真实用户问题，尽量覆盖高频场景和长尾场景；第二类是带有标准答案的事实性问答，用来检查 Agent 有没有忠实于资料，有没有一本正经胡说八道；第三类是工具调用类用例，比如"帮我把昨天订单导出来"，这类要看 Agent 能否正确选择工具、传对参数、处理返回结果。

评测集建好之后，每次检索链路改动都要重新跑一遍，并把关键指标卡进 CI。常见指标包括召回率、生成答案的事实一致性、工具调用成功率、端到端耗时。这个门禁一开始会很简陋，但越早建越划算。全模态数据平台涉及的组件太多，如果每一层都靠人工验收，链路一长几乎不可能稳定推进。先把评测集建好，等于给整条数据供给链路装了一副方向盘。

5. 选型与落地：我实践过的全模态数据平台技术组合

5.1 一套可参考的组合

下面是我在实际项目里比较常用的一套组合，不是为了追新，而是把稳定、生态和可控性摆在前面。这里只列类型和不具名的引擎代表，具体选型还要结合团队运维能力。

这套组合的核心思路是"湖仓为实，索引为派生"。向量库或者专门的检索引擎都不是事实源，只是从湖仓加工出来的一个投影。这样即使投影坏了、索引删了，原始数据还在湖里，随时可以重刷。如果反过来把向量库当唯一存储，一旦数据清洗逻辑变化，想重建都没有退路。

5.2 为什么这么选：取舍与理由

做选型决策时，最忌讳的是被新工具带着走。我见过有团队为了"全模态"这个口号，同时引进了好几个专业存储系统，比如一个存文档、一个存图片特征、一个存图数据，结果语义目录没做，Agent 根本不知道去哪查，链路反而更脆弱。我的原则是尽量少引入独立系统，所有能放进湖仓的内容先进湖仓，索引全部基于湖仓数据派生。

计算引擎方面，建议优先选团队熟悉的。全模态数据平台的瓶颈通常不在单次计算的性能，而在于链路复杂度和迭代速度。如果团队对 Spark 更熟，就用 Spark 做批处理；如果流处理需求强，再引入 Flink 补充实时计算，避免一开始就把批和流拆成两套人力都跟不上的体系。

API 层一定要自研或者定制得非常贴合自己的 Agent 框架。面向人的查询是"输入关键词出结果"，面向 Agent 的查询是"输入意图和约束条件，平台返回材料并附带出处和可信度"——这是两种交互。现成的 BI 系统很难直接改造成后者。我们内部把统一 API 的响应格式设计成固定的证据结构：答案片段、来源引用、采集时间、权限级别。Agent 拿到这些东西之后，才能在下游做引用和判断。凡是给出这个结构的接口，评测时整体表现都会明显好不少。

5.3 分阶段落地路线

大平台不是一天建成的，我建议按照"打通最小闭环"的思路推进，周期控制在六周以内。

第一阶段先把一条主链路建起来：从源系统接入数据到湖仓，跑通切片、向量化、注册进语义目录，再封装一个最朴素的检索 API 给 Agent。这一阶段的目标不是追求效果，而是验证数据链路能通、API 能稳定返回、Agent 能正确调用。第二阶段再加入实时增量管道和混合索引，把新鲜度问题解决掉，让 Agent 拿到的数据不再是几小时前的旧数据。第三阶段做记忆系统的读写接口，同时开始积累评测集。这是工作量最分散的一段，需要 Agent 开发和数据平台两边对齐数据结构。第四阶段补数据回流，把线上交互日志清理成可用语料，并定期把数据质量门禁跑起来。

每个阶段结束都要有明确交付物。比如第一阶段交"检索 API 文档 + 50 条可跑通用例"；第二阶段交"增量同步时延监控 + 知识库覆盖率报告"。不要试图一次交付一个完美的全模态平台，那只会让项目陷入长期没有反馈的黑洞。

6. 落地时最容易翻车的五个细节

6.1 语义一致性：同一个"用户"在不同系统里长得不一样

全模态数据平台接了多路数据之后，第一个坑就是实体对齐。同一个客户，在 CRM 里叫"张三"，订单系统里 customer_id 是 10086，日志里可能只有手机号。如果平台不建立统一的实体 ID 映射，Agent 做检索时就会张冠李戴，它可能把 A 用户的订单历史当成了 B 用户的。这种错误比"找不到资料"危害更大，因为 Agent 会一本正经地把错误事实交给用户。

解决办法是在接入层做实体解析：为每个主要业务实体维护一张统一 ID 映射表，把不同系统的主键关联到同一个全局实体。语义层暴露给 Agent 时，只使用全局实体的维度，底层具体是什么系统、什么 ID 则不暴露给 Agent 上下文。这样平台内部可以保持灵活，Agent 看到的世界是干净一致。

6.2 小文件爆炸与分区治理

全模态数据接入，小文件问题是躲不掉的。音视频切片、聊天快照、日志 JSON、工具调用返回值，都是高频产出的小体量对象。如果每条都单独写成一个文件，湖仓引擎扫描的时候会慢到令人崩溃。我见过一个现场，一张表几十 TB，实际数据没多少，但几百万个小文件把查询引擎彻底拖死。

治理手段主要有两个方向。一是分区策略要和查询模式对齐，按时间分区，经常一起查询的数据尽量落在同一个分区或连续分区里。二是定期做文件合并（compaction），把几小时内的增量小文件合并成目标大小适中的文件，比如 128MB 到 256MB 之间。流处理场景还要注意控制写入并发度，别让多个任务同时往一个分区写文件，否则合并速度赶不上产出速度，小文件问题就永远清不完。

6.3 权限与合规：Agent 比人更难管

权限控制在人类时代已经够头疼，到了 Agent 时代会放大数倍。人类用户至少还有判断力，知道敏感信息不能乱说；Agent 却会老老实实把能查到的内容都用上，权限边界必须由平台层严格把控。我在语义层里给每个数据和索引条目都绑定了权限标签，Agent 发起任何查询时，系统先根据会话主体和场景算出可见数据范围，再做检索。注意顺序，一定是先过滤权限、再执行检索，而不是检索完再过滤，否则会有数据泄露窗口。

审计能力也要升级。传统审计是为了回答"谁在什么时候查了什么表"，Agent 时代要回答"哪个 Agent、在哪个会话、出于什么意图、用了哪些数据、最后给用户输出了什么"。每一条检索命中都要能串成一条可追踪的链路。生产环境里，审计日志要保留一段时间，方便回溯和复盘。这套能力不便宜，但这是 Agent 规模上量之后绕不开的投入。

6.4 全模态数据质量评测：你不测，Agent 就会给你"一本正经"的错

很多团队在 RAG 阶段还不重视评测，接上 Agent 之后就出问题：数据平台里明明有资料，Agent 却总是给不出正确答案，或者更糟——给了错误的答案还很自信。这类问题的根源多半不在模型，而在检索质量。要么召回的相关资料不够，要么召回了一堆无关内容干扰生成。不建评测集，你永远分不清坏结果是模型的问题还是数据供给的问题。

我项目里用过一个简单的评测脚本思路：准备一批带正确答案的问题集，对每个问题做检索并计算两个分数——检索结果中有没有包含正确答案所在片段，以及最终答案和标准答案的事实一致性。后者可以用抽取式核对，也可以交给强模型打分。评测不用一开始做得很复杂，先能区分"改动前后谁更好"就够了。关键是隔三差五跑一遍，让数据平台的变化可感知、可量化。

def evaluate_retrieval(question: str, ground_truth_chunk: str, hits: list[str]) -> dict: hit = any(ground_truth_chunk in content for content in hits) return {"hit": hit, "recall@k": 1.0 if hit else 0.0}

6.5 成本失控：检索一次就扫描全湖

最后一个坑是成本。全模态数据平台存储面积大、索引种类多，如果检索链路设计得不好，每一次 Agent 调用都可能触发一次昂贵的全湖扫描。最常见的情况是向量检索没有分区裁剪，向量库对全量数据做暴力计算，费用随着数据量线性往上飙。另一个常见情况是每次请求都重新拉一遍大文档，把网卡和模型上下文窗口都榨干。

控制成本从三个地方入手：一是在检索入口做查询改写和意图识别，能把范围缩到某个实体、某个时间段、某个业务域，就绝不全局搜；二是热点数据缓存，高频问题和常用知识片段放缓存层，命中率上去之后成本降幅非常明显；三是冷热分层，几周前的日志和低频历史文档转到低成本的冷存储，只在特殊请求时才触发解冻。有一个简单的经验：优化检索成本之前，先看日志里重复问题占比，很多团队会发现 30% 以上的查询是重复的，这部分只要做缓存，整体成本就能下降一大截。

7. 写在最后：把数据平台当产品做，而不是当管道做

云栖2026 转完一圈，我的感受是：Agent 的竞争已经悄悄从模型层的算力竞赛，转移到了数据供给层的系统性竞争。谁能让 Agent 又快又准地拿到全模态、新鲜、可信、可溯源的数据，谁就能把模型能力真正变成业务价值。

如果你正在规划类似的全模态数据平台，我建议先想清楚一件事：这个平台既是给研发团队用的基础设施，也是给 Agent"用"的产品。既然是产品，就要设计清晰的接口、可观测的指标、能反馈的闭环。每个数据条目最好从进入湖里的那一刻起就带上三个标签：来源、时间、权限。这三个标签在后面的检索、记忆、回流的全过程中，能帮你解决掉大部分疑难问题。

最后再分享一个实际体会：不要一上来就追求"全模态大而全"，从一条最高频的业务链路开始，把数据接入、索引、检索、反馈的闭环跑通，比搭一个庞大却没人用的数据底座有用得多。湖再大，也得先让一棵树活下来，才谈得上生万物。