半路安全研究员手记

多步工具调用翻车太常见了，gpt-4和claude-3.5都这样说明大概率不是模型的问题。我踩过的坑是system prompt里工具描述写太抽象，模型根本不知道啥时候该调、按什么顺序调，把每个tool的输入输出和调用时机写具体点会稳很多。另外可以试试LangGraph，把多步流程拆成显式节点，比让Agent自己瞎规划靠谱，调试的时候还能看到每一步到底走到哪了。

本地小模型做补全确实容易被上下文窗口和推理框架限制住，你这个体验挺典型的。Continue默认走的是FIM补全，但Ollama那边的模型对FIM token的支持参差不齐，deepseek-coder虽然原生支持但6.7B参数在M2 Pro上跑量化后精度掉得厉害，给出的建议经常是"形似神不似"。Copilot背后是专门微调过的补全模型加上超长上下文，还能吃到你整个repo的索引，这个差距不是调te

千条数据上7B，lr降到1e-4或5e-5试试，rank8也够，先跑两轮看看loss曲线走向再调。 你这个loss在0.8震荡可能是学习率偏大，数据集小也容易这样，建议先降lr到1e-4，rank改8，跑5个epoch观察下。

工具描述里把触发条件写死，比如“仅当提到城市才调用天气”，再给个最大迭代次数兜底，比调温度管用。 试试把每个工具的description改成带具体场景的问答对，模型选型也换成带tool calling微调过的，能少踩一半坑。

大概率是field的type没设成metadata，MCP默认只透传主字段，记得在schema里显式声明过滤字段。 我之前也栽这坑里，后来把metadata字段单独拎出来定义成JSON类型，再在filter里用属性名访问就通了。

T4跑7B确实吃力，试试把max_model_len调小点，或者开下--enable-chunked-prefill，并发卡死多半是显存碎片化。

chunk大小试试512加20%重叠，bge-small搭中文场景其实够用了，主要得调一下检索的相似度阈值。

我之前也纠结过这个问题，后来试了一个折中方案：用一个主Agent做意图识别，再按文档类型挂几个轻量级子Agent处理不同格式的问答。这样路由成本确实高了点，但每个子Agent可以针对性地做文本切片和检索策略优化，HR问答的准确率明显提升。你不妨从小范围试点开始，先拆两个差异最大的领域试试手感。

3060 12G跑ResNet50 batch size 32按理说确实不该炸，我拿同款卡试过，ResNet50输入224x224，fp32下batch 32大概占用9.5G左右，还有余量。但你2万张图跑第一个epoch就炸，大概率不是batch size的问题，而是DataLoader那边搞了什么骚操作。 先检查几个地方：第一，你在DataLoader里是不是开了pin_memory=True