企业级Agent开发日志

先看看模型返回的tool_calls字段到底有没有触发，很多时候是解析格式没对上，不一定怪模型。

MCP本身不会每次调用都重载模型，问题大概率出在每次请求都新建了推理张量却没释放。你试试在每次推理完把输入输出都挪到CPU再删掉，光调empty_cache没用，得先把引用断干净。另外看下是不是有全局缓存或者闭包把计算图留住了，那种情况no_grad也救不了。模型池管理确实更稳，但先用torch.cuda.memory_summary()定位到底哪块在涨比较实在。

我之前也踩过这个坑，后来发现八成是rerank没做好。bge-large-zh检索出来的chunk虽然相关，但排序靠后的预算片段容易被LLM忽略，尤其Qwen2.5-7B对长上下文里中段信息的召回本身就偏弱。建议先加个bge-reranker把top_k缩到3再喂给模型，同时prompt里明确要求“逐项列出技术方案和预算的对应关系”，比调chunk_size管用。如果还漏，那基本就是模型指令遵循的

2048序列对7B确实吃显存，试试开gradient checkpointing，能省不少，我24G跑得挺稳。

豆瓣这种站其实反爬不算特别狠，你被封IP大概率不是User-Agent的问题，而是请求频率和TLS指纹露馅了。Cursor生成的requests代码默认走的是Python的SSL库，跟真实浏览器的握手特征差挺多，有些站点一抓一个准。你可以让AI帮你把requests换成httpx或者curl_cffi，后者能模拟Chrome的TLS指纹，效果立竿见影。至于cookie，豆瓣有些页面确实需要先访问首

ResNet50对衣服纹理确实不太行，换CLIP或微调过的模型试试，召回能差出一大截。

试试Qwen2.5-32B或者14B的量化版？我之前也遇到过类似情况，32B的AWQ量化在工具调用上比7B稳太多了，基本不会乱写参数，速度大概能控制在两三秒内。其实LangGraph这边也可以做点优化，比如把意图识别和参数填充拆给不同尺寸的模型，简单任务走小模型，复杂规划再交给大的，整体延迟能压不少。

8G显存跑Qwen2.5-Coder的7B量化版其实还能凑合，但别指望它跨文件重构有多聪明，上下文一长就开始胡编API了。我现在是Continue接DeepSeek-Coder做单文件补全，重构这种重活还是老老实实手动加Copilot辅助，开源方案目前对项目结构的理解确实差口气。Tabby试过，本地部署省心但补全质量比DeepSeek-Coder还弱一点，建议你先拿Qwen2.5-Coder的4b

我之前也遇到过类似问题，后来换了方案。

多条件或带否定词的query，纯embedding确实很难搞定，这跟模型关系不大，是语义空间本身的局限。你可以先别急着换模型，把召回top20的chunk打出来看看，大概率能发现是切分把关键信息切碎了。query改写这块建议试试，把复杂query拆成子问题分别检索再合并，效果往往比换个embedding明显。reranker值得上，bge-reranker对排序提升挺大的，但它救不了召回阶段就没进

LoRA省的是优化器状态和梯度那部分，激活内存该占还是占，7B模型2k上下文激活值确实不小。你可以试试gradient checkpointing，基本能砍掉一半多激活内存，代价是慢个20%左右，挺划算的。另外flash attention 2也值得开一下，对长序列帮助明显。batch size降到1再配合梯度累积，效果其实不会差太多。

80条工具样本确实太少了，参数绑定这种得几百条打底，先补数据再动超参。

我怀疑问题更多出在切分和上下文拼接上，512的chunk对多轮对话确实容易把历史信息割碎。可以试试先上bge-reranker对召回结果重排，再拿gte-large-zh或者acge-text-embedding对比一下，中文长尾实体上后者有时更稳。另外多轮场景建议把历史query做一次改写再检索，不然embedding很容易被无关历史带偏。付费API不急着上，先把rerank和query改写这两

你这情况太常见了，我们线上知识库也踩过一模一样的坑。bge-large-zh对“参数在哪个文件配的”这种偏精确匹配的问题本来就弱，向量检索抓的是语义相似，不是关键词命中。后来我们是ES做BM25粗召回+向量做语义重排，两路结果融合，效果才稳下来。另外512字符切块对配置文件类文档太碎了，关键路径信息容易断在边界上，可以试试按段落或标题切。

22G其实挺正常的，vLLM的显存大头除了权重还有KV cache和CUDA graph，4090跑bf16的7B权重就14G多了，剩下那点给8并发和graph根本不够用。你可以先把gpu_memory_utilization调低点试试，或者直接上AWQ/GPTQ量化，4bit能省一大半。另外max_num_batched_tokens和max_model_len这俩别设太大，不然KV cache

几十万条切片Chroma其实够用了，结果不准八成是embedding的锅，换BGE试试？

我一般按文档结构来切，技术手册这种按标题层级切，chunk设512效果比256稳，聊天记录反而得切小点，300左右加30%重叠比较合适。你这种多类型混着用的场景，建议先按文档类型分桶，各自跑一组参数对比召回效果，别硬凑一套通用值。自动化的话可以看下ragas或者自己写脚本扫参数，但评估集得先标好，不然调出来的数没意义。

我们之前也踩过这个坑，Faiss本身没法治愈这种问题，后来换成Milvus按doc_id做upsert才顺过来。关键是切分时给每个chunk打上文档版本号，删除时按doc_id批量删，别用重建。增量更新教程坑就坑在没讲清楚怎么维护原文档和chunk的映射，这块自己存个sqlite都行。

我一开始也这么觉得，后来发现关键差别在“谁定义接口”。Function Calling 是模型端临时描述，今天 OpenAI 明天换家就得重写；MCP 是服务端独立跑个 server，工具发现和调用走标准协议，跟具体模型解耦了。你那个文件搜索 tool 感觉差不多，是因为本地单机场景下确实没差多少，但换成多个 agent 共享同一批工具、或者工具要动态增删的时候，MCP 那套生命周期管理就有点意思

500条微调确实容易过拟合，先加个reranker试试可能更稳。