04201. 职场学习簿

你这显存占用其实挺正常的，vLLM默认会预分配KV cache，--gpu-memory-utilization设0.9基本就是把显存塞满，7B int8权重才8G，剩下全被cache吃了。两张卡没跑满大概率是tensor parallel没生效，得确认下模型路径和启动命令里有没有加--tensor-parallel-size，另外4090不支持nvlink，TP通信开销大，速度反而可能更慢。

我最近也在折腾这个，试过直接在Tool里包一层重试装饰器，比在Agent外层写循环干净很多，至少不会把整个对话流程卡死。不过重试间隔建议用指数退避，比如1秒、2秒、4秒这样，别固定间隔，不然服务一抖动大家都挤在一起重试。另外LangChain的AgentExecutor有个max_iterations参数，你可以配合Tool的max_retries一起用，能防止死循环。还有个思路是让工具返回一个结

这问题我太有同感了，AI生成代码的“结构性懒惰”确实存在，尤其是项目一大，它就会默认把所有逻辑塞进最近的函数里。我的经验是别指望靠prompt约束它，不如把大文件拆成若干个小模块，每个模块用空文件+详细注释先定义好职责，再让AI填空，效果会好很多。另外变量命名这关真得自己过一遍，我后来基本把AI写的函数当“初稿”，重构的时间反而比从零写省不了太多，但它胜在能快速铺开骨架，替代那些重复的模板代码。

这问题我太熟了，八成不是模型没学会，而是微调时和推理时的格式没完全对齐。你训练数据里如果只写了工具描述，但没把LangGraph实际用的那套system prompt和工具schema喂进去，模型学到的Action格式就跟你线上跑的完全是两码事。建议先手动拿一条训练样本，原封不动丢给微调后的模型生成，看它能不能稳定输出正确字段，再对比一下训练时的模板和LangGraph里的差异，尤其是工具名和参数

我最近也在调Claude写脚本，跟你感受一样，它特别爱自己加料，我一般会在prompt里明确写“只实现我列出的功能，别做额外优化”，然后把边界条件全给它列出来，比如编码、超时这些，让它先写伪代码逻辑再生成，能少踩不少坑。另外别让它一口气生成大段代码，拆成小函数一个个验证，bug范围就小多了，调试起来也没那么头皮发麻。

我也踩过一模一样的坑，后来发现多半是prompt里工具描述写得太模糊，模型在长链路上容易自己绕晕。你可以试试把每个工具的description改得更具体，加上“只处理X情况，否则返回Y”这种边界条件，能减少不少幻觉。另外别死磕LangChain，现在直接写个简单的while循环配OpenAI的function calling反而更稳，省去AgentExecutor那层黑盒魔法。你连续调用的工具之间

试试bm25+向量混合检索再整个rerank，chunk按段落语义切比固定大小靠谱。

我之前调工具调用也踩过类似的坑，后来发现问题多半出在训练数据里tool_call的格式没完全统一。比如你那个“city:北京”的例子，建议检查下微调时是不是把系统提示里的JSON schema和实际返回的字段名搞混了，模型很容易学歪。另外可以试试在数据里多混入一些“不触发工具”的负样本，让模型学会判断什么时候该调用，不然它容易为了完成任务瞎猜格式。我之前把温度调低到0.2左右，参数错乱的情况明显少

数据格式问题更大，3000条量级LoRA学不透长链路，建议先严格对齐tool_call_id再试全参微调。 多工具串行时模型容易上下文漂移，试试把工具描述改成few-shot示例嵌在对话里，比写系统提示词管用。

角色设定太多会抢占指令空间，我试过只保留关键约束，代码质量反而更稳。

工具调用本质是模型自己规划的，与其硬控顺序不如把依赖关系写进单个工具里，一步到位查完订单+物流。 你这场景其实更适合用简单的状态机或者工作流，别让Agent自由发挥，LangChain的Agent本来就不保证顺序。

碰到过一模一样的情况，最后排查下来问题基本不在MCP本身，而是Ollama的默认并发和超时设置。Ollama虽然模型响应快，但它对单个模型的并发请求是串行的，MCP工具调用如果内部有多个步骤（比如先读文件再查数据库），每个步骤都会单独向模型发请求，累积起来很容易超过MCP默认的60秒超时。我当时的解决办法是给server加异步处理，把工具内部逻辑用async包装，同时把Ollama的OLLAMA_

说实话server里塞system prompt这事儿我也干过，后来发现容易跟客户端的指令打架，尤其Claude那边对system层级还挺敏感。我现在是这么搞的：server端只负责把工具描述和参数约束写清楚，比如required字段、格式正则，这些通过工具schema本身就能传达；至于流程控制或者输出格式，就放客户端system prompt里，用命名空间隔开，比如“仅当调用math_tool时

说实话这问题我也折腾过挺久，后来发现“理解”这词本身就容易误导，模型更多是在做概率匹配。我现在的土办法是让它先复述一遍任务再给答案，如果复述跑偏了那后面基本白搭。交叉验证用另一个模型确实有用，但别直接问“你理解了吗”，而是让它独立产出结果再对比关键点。至于不同模型差异大，我建议先固定一个模型调prompt，稳定之后再换模型测迁移性，不然变量太多真会自闭。

说实话我太懂你这个感觉了，之前我拿transformers写Agent的时候也是if-else堆到想吐，后来发现问题的核心不在PyTorch还是别的框架，而是你压根没把“工具调用”当成一个可组合的流程来建模。我现在的做法是把每个工具声明成一个dataclass，里面带上name、description、input_schema和execute函数，然后用一个简单的循环去解析LLM输出的JSON a

bge-m3对短文本语义捕捉还行，但你这场景问题大概率出在chunk切分上，300字带重叠对“退款流程”这种主题可能把不同环节的语义搅在一起了。建议先试试把chunk缩到150-200字，重叠降到30，看召回质量有没有变化；另外检索完加个重排（比如bge-reranker）其实挺管用的，能明显把“假相关”的chunk压下去。你打印出来的chunk里有没有出现过“退款”和“退货”同时在一个片段里的情

int8掉点确实大概率是校准集的问题，我试过用500张验证集子集做校准比默认的200张好不少，另外校准算法选entropy一般比minmax稳。动态shape建议固定一个batch和分辨率范围，用trtexec的optimization profile限定，别指望全动态。F.interpolate可以试着手动改成resize+padding的组合，或者干脆用ONNX的resize算子替换，很多警告

我之前也遇到过类似情况，loss降了但生成崩了，后来发现是数据里太多重复模板导致模型学飞了。你试试把学习率降到1e-4或5e-5，rank调到16，epoch减到1-2轮看看。另外中文alpaca格式里如果混着英文标点或空格，会让tokenizer切分很乱，建议清洗时统一成全角符号。还有个坑是LoRA只加在attention层可能不够，可以加在mlp上试试。

大概率是tool描述里的参数语义没对齐，模型瞎猜top_k和阈值，试试把默认值和范围直接写死在描述里。

说实话你这情况跟我上个月一模一样，我最后选了PyTorch，主要就是MCP的官方示例和社区踩坑记录几乎全是PyTorch写的，遇到问题搜起来太方便了。TensorFlow的SavedModel在MCP里确实能直接加载，但你一旦要微调，那个图结构改起来就有点僵，特别是想动某个中间层做特征对齐的时候，PyTorch的nn.Module改起来就是改个forward的事。不过要说坑少，我觉得关键不在框架本