1. 项目概述这不是一份清单而是一张LLM应用开发的实战地图“awesome-llm-apps”——看到这个名字第一反应不是点开收藏而是下意识打开终端准备 clone。它早已不是GitHub上又一个冷冰冰的star收割机而是我过去两年在真实业务线里反复回溯、验证、踩坑后最常翻阅的导航索引。它不教你怎么调用OpenAI API也不讲Transformer的数学推导它干的事很实在把散落在全球开源社区里、能真正跑起来、能改、能扩、能上线的LLM应用案例按技术栈、按问题域、按成熟度像修车手册一样摊开给你看。关键词里的RAG、AI Agents、open-source不是标签是三条贯穿所有项目的主干脉络RAG解决“我知道什么”的可信知识注入问题AI Agents解决“我该做什么”的任务拆解与执行闭环问题而open-source则是所有可复现、可审计、可定制的前提。我带团队做过三个落地项目——智能合同审查助手、垂类技术文档问答系统、内部IT服务自助机器人每一个的起点都是从这个仓库里挑出一个匹配度最高的参考项目然后花3天时间把它本地跑通再根据业务数据和流程开始迭代。它适合谁不是纯理论研究者也不是只想调API玩demo的初学者而是正在被“怎么把大模型用到实际业务里”这个问题卡住的工程师、技术负责人、产品架构师。你不需要从零造轮子但必须清楚每个轮子的轴承型号、承重极限和适配胎压——而这正是这份清单存在的全部意义。2. 核心设计逻辑为什么是“应用”而非“模型”一张分层解耦的技术图谱2.1 从模型能力到业务价值的三层断层以及如何填平很多人误以为拿到一个7B参数的开源LLM就万事大吉结果部署后发现回答牛头不对马嘴、检索不到关键条款、多步任务直接崩盘。根本原因在于模型能力 ≠ 应用能力。这中间横亘着三道鸿沟第一层知识鸿沟。通用大模型的知识截止于训练数据而你的合同模板、内部SOP、最新API文档它一无所知。RAG不是简单加个向量库而是构建一套“知识保鲜机制”文档解析PDF/Word/Markdown结构化提取、语义分块不是按固定字数切而是按逻辑段落标题层级代码块边界、嵌入质量校验用query embedding与chunk embedding的余弦相似度分布图判断切块合理性、重排序Cross-Encoder对Top-K结果做精排。我在做合同审查时发现原始RAG返回的条款引用位置错乱最后定位到是PDF解析时表格识别失败改用unstructured库的partition_pdf并开启strategyhi_res才解决。第二层行为鸿沟。模型能生成文本但不能自主决策下一步该查数据库、该调用哪个API、该向用户确认模糊需求。AI Agents的核心不是“更聪明”而是“更守规矩”。典型框架如LangChain的AgentExecutor、LlamaIndex的ReActAgent本质是定义了一套工具调用协议每个工具必须有明确的description供LLM理解用途、input_schema约束输入格式、output_parser结构化返回结果。我们曾用一个天气查询Agent上线结果LLM在用户问“明天北京穿什么”时错误调用了“获取空气质量指数”工具只因description写成了“提供环境数据”太宽泛。后来改成“返回北京市明日最高/最低气温、体感温度及穿衣建议”问题消失。第三层工程鸿沟。开源项目跑得通demo不等于能进生产。这里藏着大量“非功能性需求”响应延迟RAG中向量检索LLM生成的P95必须3s、缓存策略相同query的embedding复用、检索结果缓存、降级方案向量库宕机时自动fallback到关键词检索、可观测性记录每一步token消耗、工具调用耗时、失败原因。一个叫llama-index-rag的项目本地测试流畅但压测时QPS刚过50向量库内存就爆了——根源在于它用SimpleVectorStore全量加载到内存换成Milvus或Qdrant的分布式部署才扛住。“awesome-llm-apps”的价值正在于它天然按这三层断层组织项目。你看它分类RAG目录下全是知识注入方案Agents目录聚焦任务编排Frameworks里列着LangChain、LlamaIndex、Semantic Kernel等胶水层选型对比。它不告诉你“RAG很好”而是用private-gpt告诉你怎么离线运行用ragatouille展示如何用ColBERT做高效重排用docling解决复杂PDF表格提取——每一项都直指某一层的具体痛点。2.2 开源生态的真实分工谁在造引擎谁在搭汽车谁在规划公路把“awesome-llm-apps”当菜谱看会走偏它本质是一份开源协作分工图。理解这个才能避免重复造轮子底层引擎层Infrastructure专注模型与算力。Hugging Face Transformers、vLLM、Ollama、llama.cpp属于这一层。它们解决“怎么高效加载、推理、量化模型”。比如vLLM的PagedAttention让7B模型在单卡A10G上吞吐翻3倍llama.cpp的GGUF量化让3B模型能在MacBook M2上跑起来。这些项目不直接做应用但决定了上层应用的性能天花板。中间框架层Orchestration专注连接与编排。LangChain、LlamaIndex、Semantic Kernel是典型。它们不训练模型也不存知识而是提供一套DSL领域特定语言让你用Python代码描述“先检索知识库再用结果填充prompt最后调用工具修正输出”。LangChain的Runnable抽象LlamaIndex的QueryEngine本质都是把LLM、向量库、工具、记忆模块像乐高一样插在一起。选框架不是比功能多而是看它是否匹配你的团队技能树——如果团队熟悉PydanticLangChain的BaseModel定义工具就很顺手如果更习惯函数式编程LlamaIndex的NodeParser链式调用可能更直观。上层应用层Application专注场景与交付。PrivateGPT、Docq、Flowise、Dify属于这一层。它们是开箱即用的解决方案目标是让用户“上传文档→点击部署→获得问答界面”。这类项目的价值在于验证了某个模式的可行性比如Docq证明了RAG在企业文档管理中的UI/UX范式Flowise展示了低代码编排Agent的交互逻辑。但它们往往需要深度定制才能融入现有系统——我们曾基于Dify二次开发替换了它的默认向量库为自研的混合检索关键词向量规则并接入内部SSO认证。“awesome-llm-apps”的分类恰恰映射了这个分层。它不鼓励你从引擎层开始重写vLLM而是引导你先确认业务需要什么应用形态问答Agent工作流再选匹配的框架层工具最后用引擎层项目解决性能瓶颈。这种分层思维比任何具体技术细节都重要。2.3 “Awesome”背后的残酷筛选标准为什么有些项目永远进不了清单很多人好奇一个项目凭什么被收录进awesome-llm-apps不是靠star数也不是靠作者名气而是几条硬核的“生存检验”可复现性Reproducibility必须提供完整的requirements.txt或Dockerfile且依赖版本锁定。我曾试过一个标榜“支持中文RAG”的项目clone后发现pip install -r requirements.txt直接报错因为langchain0.1.0与chromadb0.4.24存在已知兼容问题而作者在issue里回复“请自行解决”。这种项目永远不会被收录——它违背了开源协作的基本契约降低他人使用门槛。最小可行路径MVP Path必须有清晰的“5分钟上手指南”。理想状态是git clone→cd project→pip install -e .→python app.py→ 浏览器打开http://localhost:8000看到界面。PrivateGPT做得极好它用uv替代pip加速安装docker-compose.yml一键拉起PostgreSQLQdrantWeb UI甚至预置了sample-docs让你立刻体验。反例是某些学术项目README里写满论文公式却找不到一行启动命令。生产就绪信号Production Signals虽是开源但要有工程化痕迹。比如配置文件分离.env管理密钥、日志分级INFO/DEBUG/WARN、健康检查端点/healthz、指标暴露Prometheus格式。Flowise的docker-compose.prod.yml里包含Nginx反向代理、Lets Encrypt证书自动续期、Redis缓存配置这就是生产就绪的明证。活跃维护证据Maintenance Proof不是看commit频率而是看issue响应质量。一个健康的项目其issue区应该有用户提问得到详细解答、bug报告附带复现步骤和环境信息、PR被及时review并给出建设性意见。我曾给一个项目提过一个内存泄漏bug作者三天内回复“已定位将在v2.3.0修复”并附上临时patch——这种维护节奏才是“awesome”的底气。理解这些筛选标准你就明白这份清单不是技术趋势风向标而是经过千锤百炼的工程实践结晶。它过滤掉了90%的玩具项目剩下的每一个都值得你投入时间去深挖。3. 核心技术点深度拆解RAG、Agents、框架选型的实操陷阱与避坑指南3.1 RAG不是“检索生成”而是知识生命周期管理RAG常被简化为“向量检索LLM生成”但真实项目里80%的精力花在检索之前和生成之后。我把RAG流程拆解为六个不可跳过的环节并标注每个环节的致命陷阱文档摄入Ingestion陷阱PDF解析丢失表格、公式、页眉页脚Markdown中代码块被当作普通文本切分。实操用unstructured处理PDF关键参数strategyhi_res启用OCRinfer_table_structureTrue处理Markdown用markdown-it-py解析AST保留代码块节点切块时将代码块整体作为独立chunk。我们曾因忽略表格解析导致合同金额条款被拆成碎片RAG返回“”和“1,000,000”两个孤立词。语义分块Chunking陷阱固定长度切块如512字符破坏语义连贯性标题层级丢失导致上下文断裂。实操采用HierarchicalNodeParserLlamaIndex先按#、##标题分割大块再在每个大块内用SentenceSplitter按句号/分号切分最后对代码块、表格单独处理。参数设置chunk_size512, chunk_overlap128但必须配合metadata记录source_doc_id和hierarchy_level供后续重排序使用。向量化Embedding陷阱通用embedding模型如text-embedding-ada-002在专业领域表现差本地模型如bge-small-zh未针对业务术语微调。实操优先选领域适配模型。中文法律场景用bge-reranker-base做重排embedding用bge-m3支持多粒度检索技术文档用text2vec-large-chinese。本地部署时用llama-cpp-python加载GGUF格式模型比transformers快3倍显存占用低40%。向量存储Vector Store陷阱ChromaDB单机版不支持并发写入高QPS下崩溃FAISS内存暴涨无法释放。实操生产环境必选分布式向量库。QdrantRust编写内存友好Redis缓存query embedding组合Qdrant配置optimization_threshold1000自动合并小段Redis设置TTL1h缓存高频query。我们压测时Qdrant集群3节点支撑200 QPS稳定Chroma单机在50 QPS即OOM。检索与重排Retrieval Reranking陷阱单纯Top-K检索返回噪声未用重排导致相关性排序错误。实操两阶段检索第一阶段用Qdrant的hybrid search关键词向量召回Top-50第二阶段用bge-reranker-base对Top-50重排取Top-5。重排模型必须用业务数据微调——我们用1000条人工标注的“query-paragraph-relevance”样本在LoRA上微调2小时相关性提升37%。提示工程与生成Prompting Generation陷阱Prompt写成“请根据以下内容回答”导致LLM自由发挥未约束输出格式前端解析失败。实操采用ReAct风格Prompt你是一个严谨的合同审查助手。请严格按以下步骤操作 1. 分析用户问题识别关键实体如甲方、乙方、金额、日期 2. 检索知识库找到最相关的3个条款片段 3. 基于条款用JSON格式输出{risk_level: high/medium/low, explanation: 不超过50字, suggestion: 具体修改建议}。并用pydantic定义OutputSchemaLLM输出后自动校验失败则重试。提示RAG效果70%取决于数据质量而非模型。我们曾用同一套LLM仅更换知识库——旧库用OCR扫描件新库用人工校对的Markdown准确率从62%跃升至89%。别迷信模型先搞定数据。3.2 AI Agents不是“更聪明的聊天机器人”而是受控的任务执行器Agent的本质是状态机工具集记忆体。很多项目失败是因为把Agent当成“能聊会写的LLM”忽略了其核心约束状态机State MachineAgent必须有明确的状态流转。典型ReAct模式Thought→Action→Observation→Answer。每个Action必须对应一个注册的工具且Observation必须是工具执行后的结构化结果。我们曾用LangChain的SelfAskWithSearch结果LLM在Thought阶段就编造了不存在的搜索结果导致整个流程失控。后来强制要求所有Action必须是预定义工具名Observation必须是工具返回的dict否则中断流程。工具集Tool Registry工具不是越多越好而是越精准越可靠。每个工具必须满足description用动宾短语如“查询用户在CRM中的最新订单状态”而非“提供订单信息”args_schema用Pydantic BaseModel严格定义如class OrderQuery(BaseModel): user_id: str Field(..., description用户唯一标识)return_direct设为True时工具结果直接作为最终答案绕过LLM生成适用于精确查询。记忆体Memory不是简单存聊天记录而是管理对话状态。ConversationBufferMemory只存最近N轮易丢失上下文ConversationSummaryMemory用LLM压缩摘要但可能丢失关键细节。我们采用ConversationEntityMemory自动提取人名、公司名、金额等实体存入Redis每次调用前注入current_entities到prompt确保LLM始终知道“张三”是谁、“XX科技”是哪家客户。一个典型Agent故障排查表现象可能原因排查步骤Agent反复调用同一工具无进展Thought逻辑循环检查prompt中是否缺少“若多次尝试失败请换策略”约束查看max_iterations是否设为1工具调用参数错误args_schema校验失败在tool wrapper中添加print(fCalling {tool.name} with {kwargs})确认传入值类型Observation返回空或乱码工具实现未处理异常在tool函数内加try-except捕获异常并返回{error: xxx}避免LLM解析失败多轮对话后忘记初始需求Memory未持久化检查memory backendRedis/PostgreSQL连接是否正常key命名是否含session_id实操心得Agent的稳定性80%靠约束20%靠LLM。我们上线前用100个真实case做回归测试重点验证工具调用次数≤3次、最终答案含明确action verb如“已为您创建工单”、无模糊表述如“可能”“大概”。任何一项不达标就重构prompt或调整tool schema。3.3 框架选型LangChain vs LlamaIndex vs Semantic Kernel一场关于抽象层级的抉择选框架不是比功能多而是比抽象层级是否匹配你的问题复杂度。我用三个真实项目对比维度LangChainLlamaIndexSemantic Kernel核心哲学“胶水框架”连接一切灵活性极高“RAG专用框架”为检索优化开箱即用RAG“微软生态框架”深度集成Azure AI强企业级支持学习曲线陡峭需理解Runnable、Chain、AgentExecutor等抽象平缓VectorStoreIndex、QueryEngine概念直观中等需熟悉Kernel、Plugin、FunctionCall概念RAG上手速度慢需手动组装RetrieverLLMPromptTemplate快index.as_query_engine()一行启动中需配置AzureTextCompletion和MemoryAgent编排能力最强Plan-and-Execute、ReAct、Self-Refine全支持较弱主要聚焦RAGAgent需额外扩展强SequentialPlanner、StepwisePlanner成熟生产监控需自行集成OpenTelemetry内置CallbackManager支持日志/指标Azure Monitor原生集成我们的选择内部IT服务机器人复杂多工具调用技术文档问答系统纯RAG高精度客户-facing智能客服需Azure合规审计关键决策点选LangChain当你要“造车”比如需要Agent动态决定调用CRM还是ERP且每个系统API差异巨大。它的Tool抽象让你能为每个API写定制wrapperAgentExecutor的max_execution_time参数能防止单次调用超时。选LlamaIndex当你要“开高速”比如知识库是10万页技术文档要求毫秒级响应。它的HybridRetriever关键词向量SubQuestionQueryEngine自动拆解复合问题RecursiveRetriever跨文档关联组合比LangChain手写快3倍。选Semantic Kernel当你要“进国企”比如项目必须通过ISO 27001审计所有日志需存Azure Log Analytics。它的Kernel内置Telemetry模块自动上报token用量、latency、error rate无需额外开发。注意框架不是终身契约。我们第一个项目用LangChain半年后因RAG性能瓶颈将检索模块替换为LlamaIndex的VectorStoreIndex其余Agent逻辑不变——这得益于它们都遵循LLM、Retriever等标准接口。框架间互操作比绑定单一框架更重要。4. 实操全流程从clone一个项目到上线一个RAGAgent混合系统的完整路径4.1 第一步选定基准项目——以docq为例的深度剖析为什么选docq不是因为它star最多而是它完美覆盖RAGAgent混合场景且代码干净、文档扎实。它定位为“企业级文档问答”核心能力上传PDF/DOCX → 自动解析 → 构建知识库 → 支持自然语言问答 → 对复杂问题自动拆解为子问题Agent行为。代码结构解读docq/根目录下core/核心逻辑ingestion.py处理文档摄入retrieval.py封装Qdrant检索llm.py管理模型调用web/Streamlit前端app.py是入口components/里chat_ui.py实现消息流config/settings.py定义所有可配置项secrets.toml管理密钥Git忽略tests/覆盖关键路径如test_ingestion.py验证PDF解析准确性。启动前必改的三处配置config/settings.py中VECTOR_STORE_TYPE qdrant默认Chroma生产必须换docker-compose.yml中Qdrant服务增加environment: QDRANT__OPTIMIZATION_THRESHOLD: 1000.env中LLM_MODEL_NAME qwen2:7bOllama模型名EMBEDDING_MODEL_NAME bge-m3。首次运行验证# 启动服务 docker-compose up -d qdrant postgres # 安装依赖注意docq用poetry poetry install # 启动Web UI poetry run streamlit run web/app.py访问http://localhost:8501上传sample-docs/contract.pdf输入“甲方违约责任是什么”应返回精准条款。若失败立即看docker logs docq-web90%问题在QDRANT_URL未指向docker网络内地址应为http://qdrant:6333非localhost。4.2 第二步数据管道加固——让知识库从“能用”到“可信”docq默认用pymupdf解析PDF但在合同场景下表格和签名区域识别率不足。我们加固流程解析层升级替换core/ingestion.py中的_parse_pdf函数from unstructured.partition.pdf import partition_pdf def _parse_pdf(file_path: str) - List[Document]: elements partition_pdf( filenamefile_path, strategyhi_res, # 启用OCR infer_table_structureTrue, # 表格结构识别 languages[chi], # 中文 chunking_strategyby_title, # 按标题分块 ) # 过滤掉页眉页脚基于坐标 filtered_elements [e for e in elements if e.metadata.page_number and e.metadata.coordinates] return [Document(texte.text, metadatae.metadata.to_dict()) for e in filtered_elements]分块策略优化在core/retrieval.py中修改_get_nodes_from_documentsfrom llama_index.core.node_parser import HierarchicalNodeParser parser HierarchicalNodeParser.from_defaults( chunk_sizes[2048, 512, 128], # 大块→中块→小块 chunk_overlap128, include_metadataTrue, ) nodes parser.get_nodes_from_documents(documents) # 为代码块添加特殊tag for node in nodes: if in node.text: node.metadata[node_type] code_block向量库初始化脚本新增scripts/init_vector_store.py确保Qdrant collection创建时启用混合搜索from qdrant_client import QdrantClient client QdrantClient(urlhttp://qdrant:6333) client.create_collection( collection_namedocq_docs, vectors_config{ default: models.VectorParams( size1024, # bge-m3输出维度 distancemodels.Distance.COSINE ) }, # 启用全文搜索 hnsw_configmodels.HnswConfigDiff( on_diskTrue, ), # 添加payload index用于filter payload_schema{source_doc_id: models.PayloadSchemaType.KEYWORD}, )实操心得知识库质量验证不能只看单次问答。我们建立自动化验证集100个预设问题如“保密期限多久”用pytest跑回归测试统计answer_correctness人工标注标准答案和response_latencyP95 1.2s。每次代码变更必须通过此测试集才允许合并。4.3 第三步Agent能力注入——让问答系统学会“思考”docq原生只支持单轮问答。我们要让它对“对比A/B两个合同版本的付款条款差异”这类问题自动拆解为检索合同A的付款条款检索合同B的付款条款调用diff_tool计算差异生成总结。定义Diff工具在core/tools.py新增from pydantic import BaseModel, Field class DiffInput(BaseModel): text_a: str Field(..., description合同A的付款条款文本) text_b: str Field(..., description合同B的付款条款文本) def diff_tool(input: DiffInput) - dict: 比较两段文本差异返回结构化结果 # 使用difflib.SequenceMatcher from difflib import SequenceMatcher matcher SequenceMatcher(None, input.text_a, input.text_b) opcodes matcher.get_opcodes() changes [] for tag, i1, i2, j1, j2 in opcodes: if tag replace: changes.append({type: replace, a: input.text_a[i1:i2], b: input.text_b[j1:j2]}) return {changes: changes, summary: f共{len(changes)}处差异}注册工具到Agent修改web/app.py在initialize_app中from langchain.agents import Tool from core.tools import diff_tool, DiffInput tools [ Tool( namediff_contracts, funcdiff_tool, description比较两个合同付款条款的差异输入为text_a和text_b, args_schemaDiffInput, ), # 保留原有检索工具 Tool( namesearch_knowledge_base, funcretriever.query, description在知识库中检索合同条款输入为自然语言问题, ), ]设计Agent Prompt创建prompts/agent_prompt.txt你是一个专业的合同对比分析师。请严格按以下步骤操作 1. 解析用户问题识别两个合同ID如合同A、合同B 2. 用search_knowledge_base工具分别检索两个合同的付款条款 3. 将检索结果传给diff_contracts工具 4. 用JSON格式输出{contract_a_id: ..., contract_b_id: ..., differences: [...], recommendation: ...} 注意若任一合同ID未识别立即停止并询问用户。集成Agent到UI在web/components/chat_ui.py中当检测到问题含“对比”“差异”“不同”时切换为Agent模式if any(word in user_input for word in [对比, 差异, 不同]): agent initialize_agent(tools, llm, prompt_templateagent_prompt.txt) response agent.invoke({input: user_input}) st.write(response[output]) else: # 原RAG流程 response query_engine.query(user_input)注意Agent模式必须有超时保护。我们在initialize_agent中设置max_execution_time30并捕获TimeoutError返回“分析超时请简化问题”。4.4 第四步生产化部署——从Demo到SLA保障的七道关卡一个能跑通的Demo距离生产环境还有七道墙容器化加固Dockerfile中禁用root用户用USER 1001COPY指令后加RUN chown -R 1001:1001 /appHEALTHCHECK指令检查/healthz端点。配置中心化移除所有硬编码配置用pydantic-settings读取环境变量from pydantic_settings import BaseSettings class Settings(BaseSettings): QDRANT_URL: str LLM_MODEL_NAME: str EMBEDDING_MODEL_NAME: str class Config: env_file .env settings Settings()密钥安全.env文件不提交用vault或AWS Secrets Manager注入。Docker启动时docker run --env-file (aws secretsmanager get-secret-value --secret-id docq-secrets --query SecretString --output text) docq-app日志标准化用structlog替代print输出JSON日志import structlog logger structlog.get_logger() logger.info(query_processed, queryuser_input, latency_mslatency, statussuccess)监控埋点集成prometheus-client暴露指标docq_query_total{statussuccess}docq_latency_seconds{quantile0.95}qdrant_query_count灰度发布Nginx配置按请求头X-User-Group分流map $http_x_user_group $backend { beta backend-beta; default backend-stable; } upstream backend-stable { server docq-stable:8000; } upstream backend-beta { server docq-beta:8000; }灾备降级当Qdrant不可用时自动fallback到Elasticsearch关键词检索try: results qdrant_retriever.retrieve(query) except Exception as e: logger.warning(Qdrant failed, fallback to ES, errorstr(e)) results es_retriever.retrieve(query)实操心得上线前必须做混沌工程测试。我们用chaos-mesh随机kill Qdrant pod验证降级是否生效用artillery模拟500并发观察CPU/内存/延迟曲线。一次上线前测试发现ES降级时响应时间从1.2s飙升至8s立即优化ES查询DSL加入_source_includes减少网络传输。5. 常见问题与独家排查技巧那些文档里不会写的血泪教训5.1 RAG相关问题速查表问题现象根本原因排查技巧解决方案检索结果完全不相关Embedding模型与业务术语不匹配用curl直接调用embedding API输入“违约金”和“滞纳金”看向量余弦相似度是否0.8微调embedding模型用业务术语对如“违约金”↔“滞纳金”构造对比学习样本LoRA微调2小时同一问题多次检索结果不同向量库未设置consistency参数查看Qdrant collection info确认consistency是否为all在Qdrant client初始化时加consistencymodels.ReadConsistencyType.ALLPDF表格内容缺失pymupdf未启用OCR用fitz.open(pdf_path)[0].get_text()打印第一页文本看表格区域是否为空改用unstructuredstrategyhi_res或pdfplumber解析表格后转Markdown长文档检索慢向量库未优化qdrant describe collection docq_docs看segments数量若1000则需优化设置QDRANT__OPTIMIZATION_THRESHOLD1000或手动触发client.optimize(collection_name)LLM生成答案偏离检索内容Prompt未强制引用检查prompt中是否有“必须基于以下检索结果回答”字样加入约束“若检索结果为空回答‘未找到相关信息’禁止编造”5.2 Agents相关问题速查表问题现象根本原因排查技巧解决方案Agent无限循环调用同一工具Thought未更新 LLM应用开发实战地图：RAG、AI Agents与开源框架工程化指南
1. 项目概述这不是一份清单而是一张LLM应用开发的实战地图“awesome-llm-apps”——看到这个名字第一反应不是点开收藏而是下意识打开终端准备 clone。它早已不是GitHub上又一个冷冰冰的star收割机而是我过去两年在真实业务线里反复回溯、验证、踩坑后最常翻阅的导航索引。它不教你怎么调用OpenAI API也不讲Transformer的数学推导它干的事很实在把散落在全球开源社区里、能真正跑起来、能改、能扩、能上线的LLM应用案例按技术栈、按问题域、按成熟度像修车手册一样摊开给你看。关键词里的RAG、AI Agents、open-source不是标签是三条贯穿所有项目的主干脉络RAG解决“我知道什么”的可信知识注入问题AI Agents解决“我该做什么”的任务拆解与执行闭环问题而open-source则是所有可复现、可审计、可定制的前提。我带团队做过三个落地项目——智能合同审查助手、垂类技术文档问答系统、内部IT服务自助机器人每一个的起点都是从这个仓库里挑出一个匹配度最高的参考项目然后花3天时间把它本地跑通再根据业务数据和流程开始迭代。它适合谁不是纯理论研究者也不是只想调API玩demo的初学者而是正在被“怎么把大模型用到实际业务里”这个问题卡住的工程师、技术负责人、产品架构师。你不需要从零造轮子但必须清楚每个轮子的轴承型号、承重极限和适配胎压——而这正是这份清单存在的全部意义。2. 核心设计逻辑为什么是“应用”而非“模型”一张分层解耦的技术图谱2.1 从模型能力到业务价值的三层断层以及如何填平很多人误以为拿到一个7B参数的开源LLM就万事大吉结果部署后发现回答牛头不对马嘴、检索不到关键条款、多步任务直接崩盘。根本原因在于模型能力 ≠ 应用能力。这中间横亘着三道鸿沟第一层知识鸿沟。通用大模型的知识截止于训练数据而你的合同模板、内部SOP、最新API文档它一无所知。RAG不是简单加个向量库而是构建一套“知识保鲜机制”文档解析PDF/Word/Markdown结构化提取、语义分块不是按固定字数切而是按逻辑段落标题层级代码块边界、嵌入质量校验用query embedding与chunk embedding的余弦相似度分布图判断切块合理性、重排序Cross-Encoder对Top-K结果做精排。我在做合同审查时发现原始RAG返回的条款引用位置错乱最后定位到是PDF解析时表格识别失败改用unstructured库的partition_pdf并开启strategyhi_res才解决。第二层行为鸿沟。模型能生成文本但不能自主决策下一步该查数据库、该调用哪个API、该向用户确认模糊需求。AI Agents的核心不是“更聪明”而是“更守规矩”。典型框架如LangChain的AgentExecutor、LlamaIndex的ReActAgent本质是定义了一套工具调用协议每个工具必须有明确的description供LLM理解用途、input_schema约束输入格式、output_parser结构化返回结果。我们曾用一个天气查询Agent上线结果LLM在用户问“明天北京穿什么”时错误调用了“获取空气质量指数”工具只因description写成了“提供环境数据”太宽泛。后来改成“返回北京市明日最高/最低气温、体感温度及穿衣建议”问题消失。第三层工程鸿沟。开源项目跑得通demo不等于能进生产。这里藏着大量“非功能性需求”响应延迟RAG中向量检索LLM生成的P95必须3s、缓存策略相同query的embedding复用、检索结果缓存、降级方案向量库宕机时自动fallback到关键词检索、可观测性记录每一步token消耗、工具调用耗时、失败原因。一个叫llama-index-rag的项目本地测试流畅但压测时QPS刚过50向量库内存就爆了——根源在于它用SimpleVectorStore全量加载到内存换成Milvus或Qdrant的分布式部署才扛住。“awesome-llm-apps”的价值正在于它天然按这三层断层组织项目。你看它分类RAG目录下全是知识注入方案Agents目录聚焦任务编排Frameworks里列着LangChain、LlamaIndex、Semantic Kernel等胶水层选型对比。它不告诉你“RAG很好”而是用private-gpt告诉你怎么离线运行用ragatouille展示如何用ColBERT做高效重排用docling解决复杂PDF表格提取——每一项都直指某一层的具体痛点。2.2 开源生态的真实分工谁在造引擎谁在搭汽车谁在规划公路把“awesome-llm-apps”当菜谱看会走偏它本质是一份开源协作分工图。理解这个才能避免重复造轮子底层引擎层Infrastructure专注模型与算力。Hugging Face Transformers、vLLM、Ollama、llama.cpp属于这一层。它们解决“怎么高效加载、推理、量化模型”。比如vLLM的PagedAttention让7B模型在单卡A10G上吞吐翻3倍llama.cpp的GGUF量化让3B模型能在MacBook M2上跑起来。这些项目不直接做应用但决定了上层应用的性能天花板。中间框架层Orchestration专注连接与编排。LangChain、LlamaIndex、Semantic Kernel是典型。它们不训练模型也不存知识而是提供一套DSL领域特定语言让你用Python代码描述“先检索知识库再用结果填充prompt最后调用工具修正输出”。LangChain的Runnable抽象LlamaIndex的QueryEngine本质都是把LLM、向量库、工具、记忆模块像乐高一样插在一起。选框架不是比功能多而是看它是否匹配你的团队技能树——如果团队熟悉PydanticLangChain的BaseModel定义工具就很顺手如果更习惯函数式编程LlamaIndex的NodeParser链式调用可能更直观。上层应用层Application专注场景与交付。PrivateGPT、Docq、Flowise、Dify属于这一层。它们是开箱即用的解决方案目标是让用户“上传文档→点击部署→获得问答界面”。这类项目的价值在于验证了某个模式的可行性比如Docq证明了RAG在企业文档管理中的UI/UX范式Flowise展示了低代码编排Agent的交互逻辑。但它们往往需要深度定制才能融入现有系统——我们曾基于Dify二次开发替换了它的默认向量库为自研的混合检索关键词向量规则并接入内部SSO认证。“awesome-llm-apps”的分类恰恰映射了这个分层。它不鼓励你从引擎层开始重写vLLM而是引导你先确认业务需要什么应用形态问答Agent工作流再选匹配的框架层工具最后用引擎层项目解决性能瓶颈。这种分层思维比任何具体技术细节都重要。2.3 “Awesome”背后的残酷筛选标准为什么有些项目永远进不了清单很多人好奇一个项目凭什么被收录进awesome-llm-apps不是靠star数也不是靠作者名气而是几条硬核的“生存检验”可复现性Reproducibility必须提供完整的requirements.txt或Dockerfile且依赖版本锁定。我曾试过一个标榜“支持中文RAG”的项目clone后发现pip install -r requirements.txt直接报错因为langchain0.1.0与chromadb0.4.24存在已知兼容问题而作者在issue里回复“请自行解决”。这种项目永远不会被收录——它违背了开源协作的基本契约降低他人使用门槛。最小可行路径MVP Path必须有清晰的“5分钟上手指南”。理想状态是git clone→cd project→pip install -e .→python app.py→ 浏览器打开http://localhost:8000看到界面。PrivateGPT做得极好它用uv替代pip加速安装docker-compose.yml一键拉起PostgreSQLQdrantWeb UI甚至预置了sample-docs让你立刻体验。反例是某些学术项目README里写满论文公式却找不到一行启动命令。生产就绪信号Production Signals虽是开源但要有工程化痕迹。比如配置文件分离.env管理密钥、日志分级INFO/DEBUG/WARN、健康检查端点/healthz、指标暴露Prometheus格式。Flowise的docker-compose.prod.yml里包含Nginx反向代理、Lets Encrypt证书自动续期、Redis缓存配置这就是生产就绪的明证。活跃维护证据Maintenance Proof不是看commit频率而是看issue响应质量。一个健康的项目其issue区应该有用户提问得到详细解答、bug报告附带复现步骤和环境信息、PR被及时review并给出建设性意见。我曾给一个项目提过一个内存泄漏bug作者三天内回复“已定位将在v2.3.0修复”并附上临时patch——这种维护节奏才是“awesome”的底气。理解这些筛选标准你就明白这份清单不是技术趋势风向标而是经过千锤百炼的工程实践结晶。它过滤掉了90%的玩具项目剩下的每一个都值得你投入时间去深挖。3. 核心技术点深度拆解RAG、Agents、框架选型的实操陷阱与避坑指南3.1 RAG不是“检索生成”而是知识生命周期管理RAG常被简化为“向量检索LLM生成”但真实项目里80%的精力花在检索之前和生成之后。我把RAG流程拆解为六个不可跳过的环节并标注每个环节的致命陷阱文档摄入Ingestion陷阱PDF解析丢失表格、公式、页眉页脚Markdown中代码块被当作普通文本切分。实操用unstructured处理PDF关键参数strategyhi_res启用OCRinfer_table_structureTrue处理Markdown用markdown-it-py解析AST保留代码块节点切块时将代码块整体作为独立chunk。我们曾因忽略表格解析导致合同金额条款被拆成碎片RAG返回“”和“1,000,000”两个孤立词。语义分块Chunking陷阱固定长度切块如512字符破坏语义连贯性标题层级丢失导致上下文断裂。实操采用HierarchicalNodeParserLlamaIndex先按#、##标题分割大块再在每个大块内用SentenceSplitter按句号/分号切分最后对代码块、表格单独处理。参数设置chunk_size512, chunk_overlap128但必须配合metadata记录source_doc_id和hierarchy_level供后续重排序使用。向量化Embedding陷阱通用embedding模型如text-embedding-ada-002在专业领域表现差本地模型如bge-small-zh未针对业务术语微调。实操优先选领域适配模型。中文法律场景用bge-reranker-base做重排embedding用bge-m3支持多粒度检索技术文档用text2vec-large-chinese。本地部署时用llama-cpp-python加载GGUF格式模型比transformers快3倍显存占用低40%。向量存储Vector Store陷阱ChromaDB单机版不支持并发写入高QPS下崩溃FAISS内存暴涨无法释放。实操生产环境必选分布式向量库。QdrantRust编写内存友好Redis缓存query embedding组合Qdrant配置optimization_threshold1000自动合并小段Redis设置TTL1h缓存高频query。我们压测时Qdrant集群3节点支撑200 QPS稳定Chroma单机在50 QPS即OOM。检索与重排Retrieval Reranking陷阱单纯Top-K检索返回噪声未用重排导致相关性排序错误。实操两阶段检索第一阶段用Qdrant的hybrid search关键词向量召回Top-50第二阶段用bge-reranker-base对Top-50重排取Top-5。重排模型必须用业务数据微调——我们用1000条人工标注的“query-paragraph-relevance”样本在LoRA上微调2小时相关性提升37%。提示工程与生成Prompting Generation陷阱Prompt写成“请根据以下内容回答”导致LLM自由发挥未约束输出格式前端解析失败。实操采用ReAct风格Prompt你是一个严谨的合同审查助手。请严格按以下步骤操作 1. 分析用户问题识别关键实体如甲方、乙方、金额、日期 2. 检索知识库找到最相关的3个条款片段 3. 基于条款用JSON格式输出{risk_level: high/medium/low, explanation: 不超过50字, suggestion: 具体修改建议}。并用pydantic定义OutputSchemaLLM输出后自动校验失败则重试。提示RAG效果70%取决于数据质量而非模型。我们曾用同一套LLM仅更换知识库——旧库用OCR扫描件新库用人工校对的Markdown准确率从62%跃升至89%。别迷信模型先搞定数据。3.2 AI Agents不是“更聪明的聊天机器人”而是受控的任务执行器Agent的本质是状态机工具集记忆体。很多项目失败是因为把Agent当成“能聊会写的LLM”忽略了其核心约束状态机State MachineAgent必须有明确的状态流转。典型ReAct模式Thought→Action→Observation→Answer。每个Action必须对应一个注册的工具且Observation必须是工具执行后的结构化结果。我们曾用LangChain的SelfAskWithSearch结果LLM在Thought阶段就编造了不存在的搜索结果导致整个流程失控。后来强制要求所有Action必须是预定义工具名Observation必须是工具返回的dict否则中断流程。工具集Tool Registry工具不是越多越好而是越精准越可靠。每个工具必须满足description用动宾短语如“查询用户在CRM中的最新订单状态”而非“提供订单信息”args_schema用Pydantic BaseModel严格定义如class OrderQuery(BaseModel): user_id: str Field(..., description用户唯一标识)return_direct设为True时工具结果直接作为最终答案绕过LLM生成适用于精确查询。记忆体Memory不是简单存聊天记录而是管理对话状态。ConversationBufferMemory只存最近N轮易丢失上下文ConversationSummaryMemory用LLM压缩摘要但可能丢失关键细节。我们采用ConversationEntityMemory自动提取人名、公司名、金额等实体存入Redis每次调用前注入current_entities到prompt确保LLM始终知道“张三”是谁、“XX科技”是哪家客户。一个典型Agent故障排查表现象可能原因排查步骤Agent反复调用同一工具无进展Thought逻辑循环检查prompt中是否缺少“若多次尝试失败请换策略”约束查看max_iterations是否设为1工具调用参数错误args_schema校验失败在tool wrapper中添加print(fCalling {tool.name} with {kwargs})确认传入值类型Observation返回空或乱码工具实现未处理异常在tool函数内加try-except捕获异常并返回{error: xxx}避免LLM解析失败多轮对话后忘记初始需求Memory未持久化检查memory backendRedis/PostgreSQL连接是否正常key命名是否含session_id实操心得Agent的稳定性80%靠约束20%靠LLM。我们上线前用100个真实case做回归测试重点验证工具调用次数≤3次、最终答案含明确action verb如“已为您创建工单”、无模糊表述如“可能”“大概”。任何一项不达标就重构prompt或调整tool schema。3.3 框架选型LangChain vs LlamaIndex vs Semantic Kernel一场关于抽象层级的抉择选框架不是比功能多而是比抽象层级是否匹配你的问题复杂度。我用三个真实项目对比维度LangChainLlamaIndexSemantic Kernel核心哲学“胶水框架”连接一切灵活性极高“RAG专用框架”为检索优化开箱即用RAG“微软生态框架”深度集成Azure AI强企业级支持学习曲线陡峭需理解Runnable、Chain、AgentExecutor等抽象平缓VectorStoreIndex、QueryEngine概念直观中等需熟悉Kernel、Plugin、FunctionCall概念RAG上手速度慢需手动组装RetrieverLLMPromptTemplate快index.as_query_engine()一行启动中需配置AzureTextCompletion和MemoryAgent编排能力最强Plan-and-Execute、ReAct、Self-Refine全支持较弱主要聚焦RAGAgent需额外扩展强SequentialPlanner、StepwisePlanner成熟生产监控需自行集成OpenTelemetry内置CallbackManager支持日志/指标Azure Monitor原生集成我们的选择内部IT服务机器人复杂多工具调用技术文档问答系统纯RAG高精度客户-facing智能客服需Azure合规审计关键决策点选LangChain当你要“造车”比如需要Agent动态决定调用CRM还是ERP且每个系统API差异巨大。它的Tool抽象让你能为每个API写定制wrapperAgentExecutor的max_execution_time参数能防止单次调用超时。选LlamaIndex当你要“开高速”比如知识库是10万页技术文档要求毫秒级响应。它的HybridRetriever关键词向量SubQuestionQueryEngine自动拆解复合问题RecursiveRetriever跨文档关联组合比LangChain手写快3倍。选Semantic Kernel当你要“进国企”比如项目必须通过ISO 27001审计所有日志需存Azure Log Analytics。它的Kernel内置Telemetry模块自动上报token用量、latency、error rate无需额外开发。注意框架不是终身契约。我们第一个项目用LangChain半年后因RAG性能瓶颈将检索模块替换为LlamaIndex的VectorStoreIndex其余Agent逻辑不变——这得益于它们都遵循LLM、Retriever等标准接口。框架间互操作比绑定单一框架更重要。4. 实操全流程从clone一个项目到上线一个RAGAgent混合系统的完整路径4.1 第一步选定基准项目——以docq为例的深度剖析为什么选docq不是因为它star最多而是它完美覆盖RAGAgent混合场景且代码干净、文档扎实。它定位为“企业级文档问答”核心能力上传PDF/DOCX → 自动解析 → 构建知识库 → 支持自然语言问答 → 对复杂问题自动拆解为子问题Agent行为。代码结构解读docq/根目录下core/核心逻辑ingestion.py处理文档摄入retrieval.py封装Qdrant检索llm.py管理模型调用web/Streamlit前端app.py是入口components/里chat_ui.py实现消息流config/settings.py定义所有可配置项secrets.toml管理密钥Git忽略tests/覆盖关键路径如test_ingestion.py验证PDF解析准确性。启动前必改的三处配置config/settings.py中VECTOR_STORE_TYPE qdrant默认Chroma生产必须换docker-compose.yml中Qdrant服务增加environment: QDRANT__OPTIMIZATION_THRESHOLD: 1000.env中LLM_MODEL_NAME qwen2:7bOllama模型名EMBEDDING_MODEL_NAME bge-m3。首次运行验证# 启动服务 docker-compose up -d qdrant postgres # 安装依赖注意docq用poetry poetry install # 启动Web UI poetry run streamlit run web/app.py访问http://localhost:8501上传sample-docs/contract.pdf输入“甲方违约责任是什么”应返回精准条款。若失败立即看docker logs docq-web90%问题在QDRANT_URL未指向docker网络内地址应为http://qdrant:6333非localhost。4.2 第二步数据管道加固——让知识库从“能用”到“可信”docq默认用pymupdf解析PDF但在合同场景下表格和签名区域识别率不足。我们加固流程解析层升级替换core/ingestion.py中的_parse_pdf函数from unstructured.partition.pdf import partition_pdf def _parse_pdf(file_path: str) - List[Document]: elements partition_pdf( filenamefile_path, strategyhi_res, # 启用OCR infer_table_structureTrue, # 表格结构识别 languages[chi], # 中文 chunking_strategyby_title, # 按标题分块 ) # 过滤掉页眉页脚基于坐标 filtered_elements [e for e in elements if e.metadata.page_number and e.metadata.coordinates] return [Document(texte.text, metadatae.metadata.to_dict()) for e in filtered_elements]分块策略优化在core/retrieval.py中修改_get_nodes_from_documentsfrom llama_index.core.node_parser import HierarchicalNodeParser parser HierarchicalNodeParser.from_defaults( chunk_sizes[2048, 512, 128], # 大块→中块→小块 chunk_overlap128, include_metadataTrue, ) nodes parser.get_nodes_from_documents(documents) # 为代码块添加特殊tag for node in nodes: if in node.text: node.metadata[node_type] code_block向量库初始化脚本新增scripts/init_vector_store.py确保Qdrant collection创建时启用混合搜索from qdrant_client import QdrantClient client QdrantClient(urlhttp://qdrant:6333) client.create_collection( collection_namedocq_docs, vectors_config{ default: models.VectorParams( size1024, # bge-m3输出维度 distancemodels.Distance.COSINE ) }, # 启用全文搜索 hnsw_configmodels.HnswConfigDiff( on_diskTrue, ), # 添加payload index用于filter payload_schema{source_doc_id: models.PayloadSchemaType.KEYWORD}, )实操心得知识库质量验证不能只看单次问答。我们建立自动化验证集100个预设问题如“保密期限多久”用pytest跑回归测试统计answer_correctness人工标注标准答案和response_latencyP95 1.2s。每次代码变更必须通过此测试集才允许合并。4.3 第三步Agent能力注入——让问答系统学会“思考”docq原生只支持单轮问答。我们要让它对“对比A/B两个合同版本的付款条款差异”这类问题自动拆解为检索合同A的付款条款检索合同B的付款条款调用diff_tool计算差异生成总结。定义Diff工具在core/tools.py新增from pydantic import BaseModel, Field class DiffInput(BaseModel): text_a: str Field(..., description合同A的付款条款文本) text_b: str Field(..., description合同B的付款条款文本) def diff_tool(input: DiffInput) - dict: 比较两段文本差异返回结构化结果 # 使用difflib.SequenceMatcher from difflib import SequenceMatcher matcher SequenceMatcher(None, input.text_a, input.text_b) opcodes matcher.get_opcodes() changes [] for tag, i1, i2, j1, j2 in opcodes: if tag replace: changes.append({type: replace, a: input.text_a[i1:i2], b: input.text_b[j1:j2]}) return {changes: changes, summary: f共{len(changes)}处差异}注册工具到Agent修改web/app.py在initialize_app中from langchain.agents import Tool from core.tools import diff_tool, DiffInput tools [ Tool( namediff_contracts, funcdiff_tool, description比较两个合同付款条款的差异输入为text_a和text_b, args_schemaDiffInput, ), # 保留原有检索工具 Tool( namesearch_knowledge_base, funcretriever.query, description在知识库中检索合同条款输入为自然语言问题, ), ]设计Agent Prompt创建prompts/agent_prompt.txt你是一个专业的合同对比分析师。请严格按以下步骤操作 1. 解析用户问题识别两个合同ID如合同A、合同B 2. 用search_knowledge_base工具分别检索两个合同的付款条款 3. 将检索结果传给diff_contracts工具 4. 用JSON格式输出{contract_a_id: ..., contract_b_id: ..., differences: [...], recommendation: ...} 注意若任一合同ID未识别立即停止并询问用户。集成Agent到UI在web/components/chat_ui.py中当检测到问题含“对比”“差异”“不同”时切换为Agent模式if any(word in user_input for word in [对比, 差异, 不同]): agent initialize_agent(tools, llm, prompt_templateagent_prompt.txt) response agent.invoke({input: user_input}) st.write(response[output]) else: # 原RAG流程 response query_engine.query(user_input)注意Agent模式必须有超时保护。我们在initialize_agent中设置max_execution_time30并捕获TimeoutError返回“分析超时请简化问题”。4.4 第四步生产化部署——从Demo到SLA保障的七道关卡一个能跑通的Demo距离生产环境还有七道墙容器化加固Dockerfile中禁用root用户用USER 1001COPY指令后加RUN chown -R 1001:1001 /appHEALTHCHECK指令检查/healthz端点。配置中心化移除所有硬编码配置用pydantic-settings读取环境变量from pydantic_settings import BaseSettings class Settings(BaseSettings): QDRANT_URL: str LLM_MODEL_NAME: str EMBEDDING_MODEL_NAME: str class Config: env_file .env settings Settings()密钥安全.env文件不提交用vault或AWS Secrets Manager注入。Docker启动时docker run --env-file (aws secretsmanager get-secret-value --secret-id docq-secrets --query SecretString --output text) docq-app日志标准化用structlog替代print输出JSON日志import structlog logger structlog.get_logger() logger.info(query_processed, queryuser_input, latency_mslatency, statussuccess)监控埋点集成prometheus-client暴露指标docq_query_total{statussuccess}docq_latency_seconds{quantile0.95}qdrant_query_count灰度发布Nginx配置按请求头X-User-Group分流map $http_x_user_group $backend { beta backend-beta; default backend-stable; } upstream backend-stable { server docq-stable:8000; } upstream backend-beta { server docq-beta:8000; }灾备降级当Qdrant不可用时自动fallback到Elasticsearch关键词检索try: results qdrant_retriever.retrieve(query) except Exception as e: logger.warning(Qdrant failed, fallback to ES, errorstr(e)) results es_retriever.retrieve(query)实操心得上线前必须做混沌工程测试。我们用chaos-mesh随机kill Qdrant pod验证降级是否生效用artillery模拟500并发观察CPU/内存/延迟曲线。一次上线前测试发现ES降级时响应时间从1.2s飙升至8s立即优化ES查询DSL加入_source_includes减少网络传输。5. 常见问题与独家排查技巧那些文档里不会写的血泪教训5.1 RAG相关问题速查表问题现象根本原因排查技巧解决方案检索结果完全不相关Embedding模型与业务术语不匹配用curl直接调用embedding API输入“违约金”和“滞纳金”看向量余弦相似度是否0.8微调embedding模型用业务术语对如“违约金”↔“滞纳金”构造对比学习样本LoRA微调2小时同一问题多次检索结果不同向量库未设置consistency参数查看Qdrant collection info确认consistency是否为all在Qdrant client初始化时加consistencymodels.ReadConsistencyType.ALLPDF表格内容缺失pymupdf未启用OCR用fitz.open(pdf_path)[0].get_text()打印第一页文本看表格区域是否为空改用unstructuredstrategyhi_res或pdfplumber解析表格后转Markdown长文档检索慢向量库未优化qdrant describe collection docq_docs看segments数量若1000则需优化设置QDRANT__OPTIMIZATION_THRESHOLD1000或手动触发client.optimize(collection_name)LLM生成答案偏离检索内容Prompt未强制引用检查prompt中是否有“必须基于以下检索结果回答”字样加入约束“若检索结果为空回答‘未找到相关信息’禁止编造”5.2 Agents相关问题速查表问题现象根本原因排查技巧解决方案Agent无限循环调用同一工具Thought未更新