大模型基础架构设计Agent1. ReAct 模式推理行动循环想一步做一步配合 Agent 工作流Thought → Action → Observation循环。2. Function Calling工具调用能力LLM 自己决定调什么工具工具描述 参数 Schema。3. 记忆系统Memory大模型历史对话每次历史对话进表超过10条总结摘要MQ 异步靠大模型能力大量对话查最近5条携带以前的总结摘要数据库设计对话ID关联高并发场景需要根据用户ID分库分表高并发读写分离根据用户ID存入 Redis对话ID切换需要重新往 Redis 写历史对话或者只是清除 Redis 内容等用户提问了再重新写入 RedisRedis 存的是加工后的产物摘要 最近消息每次从 Redis 里查长期记忆每次对话结束后Agent 自动总结关键信息写入记忆文件下次启动时召回相关片段注入上下文Skill 文档调用某个 Skill 会把 Skill 加入记忆4. 规划能力Planning先计划再执行Plan-then-Executeprivateasyncthink(mode:planner|validator|reflector,input:any):Promiseany{constprompts{planner:你是一个规划专家。将任务拆解成可执行的步骤。,validator:你是一个计划审核专家。检查计划是否合理。,reflector:你是一个反思专家。分析执行结果找出改进点。};returnawaitthis.model.invoke([newSystemMessage(prompts[mode]),newHumanMessage(JSON.stringify(input))]);}5. 自我反思Self-Reflection错了能自己改评估 → 反思 → 重试。执行完后加一个 Agent 或者工具让它去验证结果对不对之后反思有问题重新改重新反思没问题直接回答结果。6. 多 Agent 协作分工协作Orchestrator Specialist单个 Agent 不能加太多的 Tools 和 Skill。Tool 和 Skill 太多大部分工具跟当前问题完全无关但 LLM 不知道哪些无关它要逐个考虑。这就导致了选错工具用了不相干的工具多调用调了不必要的工具反应慢思考时间变长幻觉自己编了个工具名创建多个 Agent主 Agent 分配给那些 Agent 继续执行。可以使用 MQ主 Agent 运行之后查看是否发送给 MQ其他 Agent 获取 MQ 的消息自行判断是否处理 MQ 中的消息。各个 Agent有依赖 → 串行等待无依赖 → 并行执行获取到全部回答让 LLM 整合不确定 → 先并行再根据结果决策7. 安全与对齐知道什么不能做前置约束 后置校验权限控制不能让 Agent 乱操作例如删库。8. 选举策略策略1多数投票法Majority Voting原理多个 Agent 给出答案选出现次数最多的那个。策略2加权评分法Weighted Scoring原理从多个维度给每个提案打分加权求和后选最高分。策略3擂台赛Tournament Style原理两两 PK胜者晋级直到选出冠军。策略4专家评审法Expert Review原理由一个或多个专门的评审 Agent对所有提案进行评分。策略5贝叶斯融合Bayesian Fusion原理基于历史表现给每个 Agent 分配可信度权重加权融合结果。9. 沙箱OpenClaw使用 Docker能配置是否开启沙箱Cursor / Trae原生机制 自研编排10. 意图分类器路由规则或者 Embedding 小模型分类选择那些 Tools。11. 多 Agent因为每个 Agent 最好不要超过 10-15 个 Tools工具调用过多需要分 Agent。多 Agent 能串联和并联。生产环境并联串联结合使用JS 用Promise.allJava 用CompletableFuture。多 Agent 之间结构化通信context.setData/getData。结构化通信对比直接把第一个 Agent 的文本传递给下一个 Agent 的优势准确性更高不会解析错上一个 Agent 如果返回对话方式有变化后边的 Agent 可能解析出错减少大模型的 Token 消耗只传关键字大对话节约 Token下游 Agent 不需要重复理解一次解析多处应用不然上一个 Agent 返回大量文本后边的 Agent 每次都全部解析可以精确控制传递的内容信息隔离安全性更好关注当前 Agent 需要关注的信息结构化传递的核心优势是准确性和效率数据不会被误解Token 消耗更低下游 Agent 不需要重复解析。自然语言传递的优势是灵活性和简单性能处理意外信息实现更简单。生产环境中建议混合使用关键数据用结构化传递确保准确上下文和创意内容用自然语言保持灵活性。12. Agent 的错误恢复与重试Agent 的错误恢复与重试的核心就三点① 用指数退避 抖动来控制重试节奏避免雪崩② 根据错误类型选择不同的策略超时重试、限流等待、格式错误直接抛③ 重试耗尽后要有降级方案缓存、备选 Agent、默认值不能让整个流程因为一个 Agent 失败而终止13. Agent 超时控制CompletableFuture设置超时时间超时失败。14. Agent 日志 监控15. Agent 热更新 动态注册使用 Nacos 自动注册服务配合数据库新增一个 Agent表里加条数据。主 Agent 服务每次查找 Agent 都去表里查有哪些 AgentAgent 作用是什么。16.流式输出SSE知识库数据库表设计Chunks 分片chunks文本 向量JSON数据主库查询的最终数据源 ✅ 必须chunks_vec向量BLOB加速向量余弦距离计算 ❌ 可选装 sqlite-vec 才有chunks_fts文本 FTS5 索引加速 BM25 关键词匹配 ❌ 可选FTS5 通常内置三张表协同工作混合搜索时向量搜索走chunks_vec关键词搜索走chunks_fts最后从chunks取 text 返回结果。Agent 告诉模型有知识库。查询使用混合搜索向量 0.7 BM25 0.3历史对话根据时间权重衰减。OpenClaw使用 SQLite 扩展存储的向量信息使用 JS 做余弦相似度之后去库里对比。chunkMarkdown400 tokens/块80 重叠类去做分片。chunks 表字段chunks(idTEXTPRIMARYKEY,pathTEXTNOTNULL,-- 来源文件路径sourceTEXTNOTNULL,-- 来源类型memory / sessionsstart_lineINTEGERNOTNULL,end_lineINTEGERNOTNULL,hashTEXTNOTNULL,modelTEXTNOTNULL,textTEXTNOTNULL,-- 分片内容embeddingTEXTNOTNULL,updated_atINTEGERNOTNULL);id 和 hash 都是 SHA256 算出来的。hash chunk 文本内容的 SHA256。文本不变hash 就不变。会话要存储到 chunkssource memory。RAG 检索流程用户问题 ↓ 检索模块从知识库中找到 Top-K 相关片段 ↓ 拼接问题 检索到的知识 → Prompt ↓ 生成模块大模型基于给定资料回答在 RAG检索增强生成系统中分片Chunking是决定检索质量和生成效果的最关键环节之一。分片策略直接决定了向量数据库中存储单元的语义完整性和上下文丰富度。以下是 2026 年主流的7 种知识库分片方法按从简单到复杂、从规则驱动到智能驱动的顺序详解1. 固定长度分片Fixed-Size Chunking最基础的暴力切分方法按预设的字符数或Token 数如 512 tokens一刀切通常配合Overlap重叠如 50 tokens防止边界语义断裂。优点速度极快实现简单行为可预测适合日志、邮件等无结构文本。缺点极易切断句子或段落导致语义不完整Embedding 表达力差。场景快速原型验证、大规模杂乱语料预处理。2. 递归字符分割Recursive Character Splitting目前LangChain/LlamaIndex 等框架的默认策略也是生产环境的通用基线。它定义了分隔符优先级层次优先按结构分割超限再降级优先按\n\n段落切再按\n换行切再按.句子切最后按空格或字符兜底切优点在保持语义边界段落/句子和控制块大小之间取得了最佳平衡。场景80% 的混合格式长文档、通用知识库。3. 文档结构感知分片Structure-Aware Splitting针对Markdown、HTML、PDF、Word等带格式的文档解析其层级结构标题#、列表、表格、代码块进行切分。实现识别H1/H2/H3标题边界将标题 下属内容作为一个 Chunks表格/代码块作为独立单元不切断。优点保留文档逻辑结构检索时可带回层级元数据如来自第三章第二节极大提升精准度。场景技术文档、API 手册、政策法规、带目录的报告。4. 语义分片Semantic Chunking不再依赖长度或标点而是利用Embedding 模型计算相邻句子/段落的向量相似度。当相似度骤降话题转换时切分。流程句子级 Embedding → 计算余弦相似度 → 设定阈值Breakpoint Percentile→ 相似度低处切分。优点块内主题高度聚焦语义连贯性最好。缺点计算成本高需大量 Embedding 调用块大小不均可能产生过碎片段50 tokens导致 LLM 上下文不足。场景长篇叙事、散文、研究报告、法律合同主题切换频繁。文本 ↓ Embedding 模型 ↓ 向量如 1024 维 ↓ 存向量库 / 查向量库5. 父子分片 / 层次化分片Parent-Child / Hierarchical Chunking一种双层索引架构解决检索要小精准但生成要大完整上下文的矛盾子块Child小如 128 tokens用于向量化存储和检索保证 Embedding 聚焦提高召回精度。父块Parent大如 1024 tokens检索命中子块后回溯找到对应的父块完整内容传给 LLM 生成。优点兼顾检索精度与生成质量避免小切片上下文缺失。场景企业级复杂知识库、技术手册、需完整引用的合同。6. Agentic 分片Agentic Chunking2026 年兴起的前沿范式利用LLM Agent代替规则或简单相似度来决定边界。Agent 会阅读文本理解用户可能怎么问从而主动规划出最利于检索的块例如把格式说明、“操作步骤”、时效说明拆成不同块而非按篇幅切。优点分片质量天花板接近人类认知能处理跨段落逻辑和复杂结构表格/代码/例外条款。缺点索引成本极高每文档需 LLM 调用速度慢。场景高价值法律/医疗文档、复杂企业级政策库通常配合缓存使用。7. 延迟分片与上下文检索Late Chunking Contextual RetrievalLate Chunking传统是先切再 Embedding它是先对整篇文档用长上下文模型 Embedding然后在向量空间对 token 表示进行均值池化切分。确保每个块的向量都继承了全文语境解决代词指代不明问题。Contextual RetrievalAnthropic索引时让 LLM 为每个块生成一句上下文摘要如这是关于 XX 政策的退货条款拼接到原文再 Embedding大幅降低检索歧义。场景高精度问答、指代复杂的长文档、与 Reranker 配合使用。8. 代码感知分片AST-Based / Code-Aware针对代码库的特殊分片基于抽象语法树AST解析按函数、类、方法边界切分绝不切断函数体或注释对。场景代码检索、API 文档、技术仓库 RAG。选型决策矩阵2026 实践建议策略语义完整性成本/速度推荐场景递归分割⭐⭐⭐⭐低/快通用首选基线未知文档类型先用它结构感知⭐⭐⭐⭐低/快Markdown/PDF/HTML 结构化文档父子分片⭐⭐⭐⭐⭐中/中生产级高精度问答需完整上下文语义分片⭐⭐⭐⭐⭐高/慢纯文本、主题频繁切换的长篇论述Agentic⭐⭐⭐⭐⭐极高/极慢高价值复杂文档法律/医疗/金融Late/Contextual⭐⭐⭐⭐⭐高/中指代复杂、需消歧义的检索任务核心经验不要对所有文档用一种策略。生产系统通常做路由分发——根据文件类型.md走结构感知.py走 AST.pdf走递归重叠调用不同分片器。文档版本管理老文档和新文档上传时先选分类做重名加版本处理并且设置老版本为非活跃。如果没有重名靠大模型能力去对比有没有相似性。之后用户手动确定新上传的文档是否要覆盖或者是其他文档的升级版本老版本设置为非活跃。查询只查活跃版本。示例流程首次上传 “2024年退货政策_v1.docx”→ 系统创建文档家族RETURN_POLICY→ 创建版本v1再次上传 “2025年退货政策_最终版.docx”→ 用户选择归属RETURN_POLICY或系统自动匹配→ 系统创建版本v2→ 标记 v1 为 deprecated→ 删除 v1 的向量数据检索时→ 只查 status ‘active’ 的版本→ 不管文件名是什么只认家族 ID以上即为完整的格式整理版。