飞鸟认真测试日记

MCP接口两边都挺坑的，我们后来直接自己写了个适配层，省心多了。

工具描述这块确实太关键了，我踩过的坑跟你几乎一模一样。后来发现LangChain的Agent选不选工具，很大程度取决于工具名和description写得够不够“傻瓜化”，比如别写“query_weather”，而是写清楚“当用户问某地天气、气温、是否下雨时调用此工具，输入必须是城市名”。另外你那个疯狂循环的问题，大概率是Agent没拿到有效返回结果，或者工具报错被它忽略了，可以加个max_iter

试试在训练数据里掺些“工具不存在时该拒绝”的样本，光学会调用不够。

你这个困惑挺典型的，我刚开始搭Agent时也纠结过。其实用`torch.no_grad()`包住LLM推理本身没什么问题，因为大多数LLM的权重是冻结的，你本来就不需要它们的梯度，而且现在很多推理后端根本不会把计算图传回来。真正会影响梯度流的，是你后续想微调的那部分——比如reward model或者policy head，那部分得单独用`enable_grad()`，不能一刀切地把整个Agent

出海最难搞的其实是不同口音和方言的语音识别，实验室里哪会想到这些。

我们上个月也拿千寻这个新版本跑了一轮内部测试，场景是客服工单的意图识别加知识检索，感受跟你还挺像的。准确率确实有涨，但没有宣传得那么猛，我们这边大概也就百分之十几的提升，而且是在调了prompt之后才达到的。响应变慢这个问题我们也碰到了，平均延迟高了快一半，后来把超时从10秒调到25秒才稳住，不然批量任务经常断。token消耗这个更头疼，输出啰嗦了不少，同样的query长度涨了差不多三成，成本直接

这种情况挺常见的，Cursor默认的补全确实有时候会抽风推老库。我一般是在项目根目录放个requirements.txt或者pyproject.toml，把pandas、openpyxl这些写进去，它读取上下文后推荐会准很多。另外你也可以在.cursorrules里明确写一句“处理Excel只用pandas+openpyxl，禁止用xlrd和iterrows”，效果挺明显的。模型版本也有影响，试试

我之前也踩过这个坑，第3个epoch才炸，大概率不是数据的问题，更像是某些层在训练过程中把数值推到了极端。你可以先试试在backward里加个hook，把每层梯度的norm打出来，看看到底是哪一层先爆的，比盲调优化器有用多了。BatchNorm在batch比较小或者某些通道方差接近0的时候，确实容易放大数值，特别是配合残差结构。另外损失函数里如果有log或者除法，记得加eps，像分割常用的dice

我也踩过这个坑，之前给三个例子让它写不同风格文案，结果全变成一个模子刻出来的。后来我的经验是：例子别超过两个，而且最好是风格差异大的，不然模型容易把它们当模板而不是参考。更关键的是在指令里明确说“不要照搬例子的句式，只参考语气和思路”，这句话挺管用的。我现在基本是一个例子加一段风格描述，效果反而比堆例子好。

本地文档检索确实用不上MCP，它主要解决多工具动态调用的标准化问题。

我也遇到过，后来加了个重排序模型筛一遍再进prompt，效果好很多，比死磕prompt强。

加个“只输出代码不要注释”的system提示，再压低temperature，基本就不废话了。

刚入门，这个对我帮助很大。

这个思路不错，收藏了。

工具描述别光堆功能，重点写清楚“什么时候该用”和“什么情况别用”，边界比细节管用。我一般会把参数拆成必填和可选，再给一两个典型调用示例，模型照着抄比读一堆说明靠谱。另外系统prompt里别重复工具描述，那玩意儿本来就会自动注入，你写太长反而稀释注意力。让模型先确认意图可以试试在工具里加个dry-run参数，先返回解析结果让它自己检查，比硬让它“思考”稳多了。

我一般把角色设定放system里，工具description只写清楚参数和返回格式。之前也试过塞description，模型确实容易忽略，尤其工具一多就顾不上了。MCP那个prompts资源更适合做可复用的模板，用户手动触发那种，跟工具调用不是一回事。你这个周报场景我觉得可以system定基调，工具只管拿数据，输出格式在description里写死。

6G显存跑7B确实勉强，换4B量化版会舒服很多，代码补全差距不大但速度能翻倍。

我也被LangGraph的状态搞晕过，后来干脆把State拆成几个TypedDict，每个节点只声明自己需要的最小字段，改动时心里有数多了。把所有东西塞一个字典确实省事，但调试时根本不知道哪个节点动了哪个key，太痛苦。CrewAI我没深度用过，不过它偏向角色协作，你这种流程循环可能还是LangGraph更合适。建议画一张状态流转图，标清每个节点读写哪些字段，理清了再写代码会轻松不少。

loss降到0.2不代表模型学对了，很可能只是过拟合到你的纯文本格式上了。你没加chat模板这点我觉得是关键，Qwen2本身有对话模板，你直接喂纯文本，推理时模型不知道该怎么“回答”，就容易吐重复符号。建议先把数据转成带im_start那种对话格式，再降点epoch，10个epoch对1万条来说确实多了。学习率5e-5对LoRA偏大，可以试试1e-4配warmup，或者干脆2e-4跑短一点看效果。

我之前也踩过这个坑，整段压缩丢细节太严重，单条存又容易碎片化。后来改成按话题窗口切块，每块带summary向量加原始消息ID列表，召回时先粗筛再按时间戳和话题标签重排，效果还行。MCP里工具调用返回的上下文可以塞进metadata做过滤，别只靠向量相似度。你那个A-B-A切换的场景，建议额外存个topic链，切回时按链回溯比纯语义检索稳。