认真成长设计修炼册

我也踩过这个坑，后来是在state里记一下每个工具最近几次的输入和返回，如果发现参数几乎没变、结果也差不多，就直接短路走结束分支。另外让LLM在每轮工具返回后先做一次“继续还是收尾”的判断，比硬卡迭代次数自然很多。max_iterations可以留着当兜底，但别让它当主力，不然正常的多步任务很容易被误杀。

你这个问题其实挺有代表性的，我一开始也踩过类似的坑。MCP里的prompt跟传统system prompt确实不是一回事，它更像是给用户点一下就触发的工作流入口，而不是让模型一直背着的角色设定。你把它写成长篇角色卡，等于每次调用都往上下文里塞一堆静态文本，模型当然会变迟钝。我现在基本只留一个简短的意图描述加几个参数占位符，具体知识让工具去动态取，效果好很多。你提到的“程序化”这个感觉是对的，参数和

加个rerank模型比如bge-reranker，检索完再精排一遍，效果立竿见影。

这个现象太典型了，我去年做金融客服模型的时候一模一样，通用能力掉得亲妈都不认识。你2万条数据里如果全是客服问答，模型会慢慢把预训练阶段学到的通用知识覆盖掉，loss低不代表泛化好，它只是在你这个分布上拟合得好了。rank=8其实不算小，问题更可能出在数据配比和训练轮次上，3个epoch对垂直数据来说已经偏多了，我一般1到2个epoch就停。建议你往训练集里掺10%到20%的通用指令数据，比如alp

500条确实太少了，模型很容易记住标注里的噪声而不是学到对话逻辑，答非所问和重复片段基本就是过拟合的典型症状。你loss降得顺不代表泛化好，建议先拿100条做验证集卡一下早停，别只看训练曲线。另外MCP微调一般只动adapter或者顶层，全参微调小数据必崩，可以试试冻结底层只训最后几层。数据这块先抽20条人工过一遍，看看标注风格是不是统一，客服场景里多轮上下文有没有对齐，这个比调参重要多了。

我一般是让server端直接把图片转成文字描述再返回，base64塞进prompt里模型基本没法正确处理，纯属浪费token还容易带偏。如果确实需要保留原图，可以试试在MCP的content里把image和text分成两个独立的content block，别混在一个字段里，Claude对分块的多模态输入识别会准很多。另外模板里那个占位符最好别直接放原始数据，加一层判断，图片走image类型、JSO

我也踩过这坑，八成是训练数据里参数格式不统一，模型没学会严格对齐schema。建议先检查几轮样本的tool_call字段是不是完全一致。

我一般先用固定阈值卡一道，比如cosine相似度低于0.35的直接扔掉，再在剩下的里取top 5到8条，比单纯调k管用。两万条数据其实不大，可以试试用MMR做重排，既保相关性又降冗余，噪声会少很多。另外embedding模型确实有上限，text-embedding-3-small对长文本会截断，最好先按语义切块再入库。你是直接把整篇文档塞进去，还是做过chunk切分？这块影响可能比top_k还大。

显存慢慢涨上去然后突然OOM，这基本就是典型的内存泄漏了。建议重点查一下validation或者日志那块有没有把tensor一直挂在graph上，比如累加loss的时候用了`total_loss += loss`而不是`total_loss += loss.item()`。另外混合精度本身不会更吃显存，但如果scale没处理好导致某些中间激活被保留，反而更糟。可视化可以试试`torch.cuda.

3090跑13B确实有点勉强，我自己的经验是AWQ比GPTQ稳一些，特别是代码任务上。你试过用vLLM加AWQ量化吗？比ollama的推理效率高不少，长文本卡顿会好很多。另外7B和13B的差距在代码上挺明显的，如果实在跑不动13B，不如换个更好的7B模型，比如DeepSeek-Coder或者Qwen2.5-Coder，比硬压13B效果强。

base64确实最省事，但归一化参数建议塞进tool的schema里当元数据传，别硬编码在服务端。

先看MCP服务端的timeout设了多少，很多默认超时短得离谱，模型还没吐完就断了。

加了角色设定确实容易让模型分心，我一般只在需要特定风格时才加，重构代码直接说清楚规则就够了。

嵌套JSON确实头疼，我一般会把返回值统一转成字符串再喂，错误恢复样本也加了些，效果还行。

借速卖通试C端挺聪明，但机器人没售后网点，老外退货能退到破产。

把关键约束挪到开头或结尾试试，中间放背景就行，模型确实容易丢中段。

我最近也踩过这个坑，固定长度切分确实容易把一段完整逻辑切碎。后来试了按标题层级+段落做语义切块，再让相邻块之间重叠一两句，召回完整度好了不少。另外可以试试句子级embedding做边界判断，语义相似度骤降的地方就是天然断点。不过重叠太多也会引入噪声，得根据你文档类型调一下比例。

我之前也踩过类似的坑，Llama 3 8B对tool-call的格式特别敏感，稍微偏离你few-shot里的结构它就懵了。建议你试试把路由判断单独拆成一步，先让模型输出一个JSON，再根据JSON去执行工具，而不是让它直接生成调用动作。另外温度调到0.1其实还是不够低，可以试试0，同时检查下是不是工具定义写得太复杂了，有时候简化成“查天气”和“订酒店”两个action反而更稳。

说实话你这数据量Mac Studio跑Milvus有点杀鸡用牛刀了，单机部署光那一堆依赖和内存占用就够呛。ChromaDB检索飘大概率不是库的问题，我更怀疑是embedding模型没针对你的文档领域调过，试试换BGE或者E5系列本地模型，效果可能立竿见影。如果真想折腾，Qdrant的本地模式比Milvus轻量不少，但建议先拿你那些跨章节问题去对比一下召回结果再决定动不动库。

七八个确实有点猛，我生产环境最多挂4个，工具描述太长真会挤爆上下文。建议按任务拆成不同profile。