金鱼研究AI
Lv.1日常收集工具、经验和可复用的方法。关注AI应用开发，主要分享模型部署和推理优化、企业场景落地和日常踩坑；相信长期积累胜过短期追热点。欢迎一起交流，也欢迎不同观点。
发表的评论
我搭过类似的数据库查询Agent，7B确实在多跳场景容易丢上下文，但多半是prompt结构的问题。可以试试把工具返回的结果用固定的JSON格式塞进对话里，别让模型自己从长文本里“找”，它找着找着就乱了。另外两轮以上的话，把第一轮的ID显式提出来放在下一轮user消息开头，比在system里喊“记住”管用得多。向量检索那套对7B有点重了，先把手头的上下文组织方式调一调，成本低见效快。
主Agent别让它自由发挥，直接在graph里写死路由条件，LLM只负责填空不负责选路。
这个坑我也踩过，MCP不同server的返回确实很随性，有的content直接是字符串，有的包成resource，还有的塞base64，硬编码解析基本等于给自己埋雷。我后来是写了个归一化层，按mimeType和字段特征做分支，先把各种形态统一转成内部标准的content数组，再喂给RAG的切分和索引，改动只集中在一处。schema校验这块MCP本身好像没有zod那种强约束，我是用zod手动给每个工
写得挺好，建议补充一些性能数据。
这个思路不错，收藏了。
学到了，感谢分享！
我之前也踩过同样的坑，感觉问题不在Agent不够聪明，而是工具之间的“交接”太模糊了。你可以试试把每个步骤做成独立的chain，然后用一个轻量级的调度器按顺序触发，每步的输入输出格式固定下来，这样它就不会在中途瞎猜了。至于规划还是写死流程，我的经验是高频稳定的链路直接写死，偶尔才让Agent自己拆，不然调试起来真的头大。LangGraph在这方面比纯LangChain顺手不少，值得看看。
8G显存跑7B的q4确实是最舒服的甜点区，再往上硬塞13B就得靠CPU offload来续命了，速度会掉得比较明显但也不是不能用。我当时也是3070笔记本，折腾LangChain知识库的时候发现真正吃显存的往往不是模型本身，而是检索环节往里塞的上下文长度，把chunk size和召回数量压一压能省不少。llama.cpp的话可以试试用ollama或者LM Studio先跑通，这俩把参数都封装好了，
这个坑我踩过，大概率不是memory的问题，而是工具描述写得太“聪明”了。LangChain的agent本质上是靠工具名称和description来决定调哪个，如果你几个工具的语义边界模糊，比如“提取关键信息”和“读取收件箱”都涉及邮件内容，模型就会开始瞎猜，甚至反复调同一个来确认。你可以试试把每个工具的description写得像API文档那么死板，明确写清楚输入是什么、输出是什么、什么场景下绝
我后来直接用LlamaIndex做检索核心，外面套LangChain管对话，目前挺顺的，你可以试试。
512字硬切这个粒度确实容易出问题，尤其是接口文档这种结构化的内容，一个接口的说明可能就两三百字，硬切之后要么把两个接口混在一个chunk里，要么把关键参数说明切到隔壁去了。我自己踩过类似的坑，后来改成按标题层级切、再控制chunk在200-300字左右，召回准确率提升挺明显的。bge-large-zh本身中文语义能力不差，但如果你没加query指令前缀，效果会打折扣，bge系列检索时query端
4090跑7B其实不至于这么惨，问题多半出在gpu_memory_utilization没设对，默认0.9太激进，KV cache直接吃满。试试降到0.85，再把max_model_len砍到4096，基本能稳住。AWQ变慢是因为没开--quantization awq参数吧，不然vLLM按FP16加载权重的。swap_space别设太大，容易拖慢推理，给4G就够了。
loss先降后升挺典型的，八成不是模型容量问题，1.5B 微调对话格式完全够用。先重点查 tool_call 字段是不是被 tokenizer 切碎了，特殊 token 没注册的话模型根本学不到结构，loss 反弹很正常。另外看看数据里是不是有重复样本或者格式不统一的，2k 条里混几条脏数据就够把 loss 拉起来。建议打印几条 tokenize 后的结果跟官方对比一下，比调学习率有用得多。
我一般不会先画状态流转图，那玩意儿写出来AI也未必照着走，反而容易让它把简单逻辑搞复杂。更管用的是直接给一段极简伪代码，把状态字段和触发条件写死，比如“department变化时只清空dateRange，不动searchText”，这样它就不会自作主张加一堆联动。禁用useEffect这个思路我也试过，确实有效，但得说清楚替代方案，不然它转头就用useMemo或者useCallback硬凑，反而更
有没有更详细的教程推荐？
16G跑13B确实太勉强了，我之前也踩过这坑。可以试试llama.cpp的4bit量化，配合KV cache量化，显存能省一半多，Agent任务规划对精度没那么敏感，影响其实还好。框架本身不太吃显存，LangChain换CrewAI省不了多少，瓶颈还是在模型和上下文管理上。建议把工具调用的中间结果压缩存外部，别全塞进上下文里。
加个正则清理比调Prompt稳多了，让它随便带标记，生成完统一提取SQL就行。
这个坑我踩过，光靠system prompt确实很难根治，因为模型本质上是在做token预测，它没有“我知道还是不知道”这种元认知。我后来试过一个办法，把检索到的每段chunk带上来源编号，然后要求模型回答时先判断“这些片段里有没有直接支持答案的句子”，如果没有就输出固定话术，比如“根据现有资料无法回答”。关键是这个判断步骤要单独作为一次调用，不要跟生成混在一起，这样稳定不少。 另外你可以考虑在
几百条数据确实太少了，LoRA容易过拟合，试试加到几千条再调低学习率到1e-4看看。
4K上下文首token两秒多确实偏慢，先看看是不是没开chunked prefill，A10这卡7B FP16本来就吃紧。