知识管理实践笔记

试试给每个工具单独写个调用规则，让它先选再填参，两步走能稳不少。 或者把few-shot换成反面例子，专治乱填参数。

八成是历史消息堆太长了，vLLM的KV cache在Agent循环里会指数膨胀，把max_model_len砍到2048试试。 先看LangChain日志里每次tool返回的token数，再单独跑个长对话压测，能快速区分是模型崩还是逻辑卡。

说实话你遇到的这个情况太典型了，AI脑补往往是因为你给的“目标”太具体，但“边界”没划清楚。我试过最有效的一招是直接在prompt里写“只做X，不要做Y，不要添加额外逻辑”，把你不想要的东西明确禁止掉。另外，别指望它一次到位，先让它输出最基础的版本，你再基于结果一步步追加条件，比一开始就写大而全的指令靠谱得多。

你这明显是AWQ的weights没真正生效，vLLM对int8量化默认走的是weight-only，但LoRA微调后adapter权重会以fp16留在显存里，峰值基本全被它吃了。建议先确认下`--quantization`是不是真的传给了模型加载器，另外试试把LoRA合并回基座再量化，或者用`--enforce-eager`关掉CUDA graph，能省不少缓存。我之前跑13B也遇到过类似情况，最

7B做工具调用就是容易飘，换Qwen2.5-72B或专门微调的function calling版能好很多，本地扛不住就上量化。 格式不稳定多半是采样问题，建议试试约束解码或者用vLLM的guided json，比调temperature管用。

rank16不算高，但5000条数据配2e-4的lr确实容易过拟合，试试降到1e-4加个warmup看看。 数据集杂才是大问题，客服场景先按意图分类清洗一下，重复回答多半是数据里相似样本太多导致的。

固定batch最省心，动态shape很多算子优化跟不上，精度对不上大概率就是回退到CPU了。

这帖子说得挺到点上的，尤其“绩效”那块，我猜后面想说容易变成玄学对吧？StaffDeck这个思路我关注过一阵，面壁开源出来的时候我还专门拉了个demo跑了一圈。它那个岗位定义确实能省掉不少手写state machine的破事，尤其多Agent场景下，角色权限和上下文边界用平台层约束，比自己在代码里if else硬堆要干净得多。 但实际用下来，我觉得它目前最大的坑反倒不在“过度抽象”，而在“抽象粒