本次将改造为原生Function Calling调用，是原智能体项目的核心架构升级，核心价值总结：彻底解决传统Prompt方案的格式解析、决策精准性两大痛点；代码解耦、扩展性极强，支持多工具无缝扩展，适配未来业务迭代；贴合大模型生态标准，模型切换/工具扩展零成本；无缝兼容原项目链路，零侵入改造，生产可直接落地；工具调用成功率、决策精准率大幅提升，智能体问答体验质的飞跃。

Redis作为高性能缓存，用于减轻数据库压力，其数据最终来源于数据库，但由于两者是独立的存储系统，且存在“缓存操作”与“数据库操作”的先后顺序、网络延迟、并发读写、节点故障等问题，导致数据一致性被破坏，核心原因主要有以下4点：操作顺序不合理：缓存与数据库的更新/删除操作没有遵循统一的顺序（如先更缓存再更数据库、先删缓存再更数据库），导致并发场景下出现数据偏差。并发读写冲突：多个线程同时进行读写操作

目标：完全移除 ZooKeeper 依赖；优势：简化架构、提升元数据一致性、更快启动；状态：自 Kafka 3.3 起KRaft 成为默认模式；迁移建议新项目：直接使用 KRaft；老项目：谨慎评估迁移成本，可长期运行 ZK 模式。核心模型：Topic（逻辑）→ Partition（物理）→ Leader/Follower（高可用）；可靠性基石acks=all+ 多副本 + 手动提交 offset

*** 文档分片实体类（与ES索引字段严格映射）* 对应ES中存储的「文本分片+元数据」结构/** 文本分片内容字段（对应ES的content字段，BM25检索目标） */ private String content;/** 原始文档ID（非分片ID，用于检索结果溯源） */ private String docId;/** 文件类型（如txt/word/pdf/excel，可选） */ pri

针对超大文本（如100MB以上纯文本文件），传统“一次性加载全部文本到内存再分片”的方式易导致内存溢出、方法卡死等问题。因此采用：逐批次读取文本到缓冲区，按需生成分片，全程不加载完整文本到内存，大幅降低内存占用。

ZooKeeper：Kafka 集群的“配置中心 + 协调中心”。Broker 注册：依靠 ZK 临时节点实现存活检测。Controller 选举：争抢 ZK临时节点实现。分区主从：Leader 提供读写，Follower 同步，ISR 保证高可用。Leader 选举：由 Controller 从 ISR 中选出，结果存入 ZK。ZK 作用边界：只管集群协调，不管消息收发。

封装Excel单元格原始数据+完整元数据，用于解析结果暂存与数据流转/*** Excel单元格数据实体* 存储单个单元格的内容+全量元数据，支持检索溯源/** 工作表名称（如：Sheet1、用户信息表） */ private String sheetName;/** 行号（从1开始，与Excel视觉行号一致） */ private Integer rowNum;/** 列号（从1开始，与Excel

关键点说明脑裂本质网络分区 + 共识机制失效 → 多主节点旧版防护依赖手动配置法定人数新版防护基于 Raft 思想的协调层，自动多数派选举 + 任期机制核心原则主候选节点数为奇数确保多数派唯一终极建议使用 ES 7.0+，遵循官方部署规范，避免手动干预共识逻辑结论：Elasticsearch 7.0+ 通过引入现代化的集群协调机制，从根本上解决了脑裂问题，大幅提升了系统的可靠性与易用性。生产环境应

分词器 = 把一段文本，切分成一个个“关键词”的工具。ES 底层是 Lucene，所有文本搜索，都依赖分词，分词的质量直接决定搜索效果。倒排索引 = 关键词 → 文档ID 的映射关系，是 ES 能实现“秒级搜索海量数据”的核心原理，也是搜索引擎的基础。简单来说，倒排索引不存储“文档包含哪些内容”，而是存储“每个关键词出现在哪些文档中”，通过关键词快速定位文档，而非遍历所有文档。

【代码】Kafka ZooKeeper 模式 vs KRaft 模式对比。