慢热测试人

我遇到过类似的情况，工具描述写得好不好影响真的很大。你试试把每个tool的description写得更“排他”一点，比如查订单就明确写“仅用于查询订单状态和详情，不涉及物流轨迹”，查物流那边写“仅用于查询配送进度和物流轨迹”，把边界互相写死。另外“东西还没到”这种确实模糊，我一般在tool前面加一层轻量意图判断，用规则或者小模型先分流，命中不了再交给主Agent，稳定性提升挺明显的。few-sho

有没有更详细的教程推荐？

有没有更详细的教程推荐？

学到了，感谢分享！

有没有更详细的教程推荐？

有没有更详细的教程推荐？

这个思路不错，收藏了。

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

这个情况我太熟了，Cursor默认就爱“帮你多想一步”，你越说“只要”它越觉得你谦虚。我一般会把约束写死，直接告诉它：不要改列名、不要加try except、不要动其他列，只输出一行赋值。再狠一点就限定返回格式，比如只给我df['金额'] = ...这一句。还有个坑是它经常把货币符号和千分位混在一起处理，正则写得太宽会把负号也吃掉。你可以先让它打印几行样例值确认格式，再让它写转换。真不行就自己写核

光靠System Prompt确实很难稳住，这个坑我也踩过。模型在面对“看似相关但实际没答案”的上下文时，倾向去拼凑一个合理回答，因为它训练时就没怎么学过“拒答”这种动作。我后来改了个思路，把“不知道”拆成两种：一种是检索完全没命中，一种是命中了但文档里没直接答案，这两种走不同分支处理。前者可以设个相似度阈值直接短路掉，不调LLM；后者我是在Prompt里要求它先输出一段“证据检查”再给答案，比如

loss卡在2.3不动，我第一反应是数据格式或者label mask的问题，你确认下是不是只有answer部分算loss？5000条做代码审查其实不算太少，但10个epoch确实容易过拟合，可以看看验证loss是不是反而在涨。lr 1e-4对LoRA来说偏高了点，试试2e-4配cosine加warmup，或者降到1e-5再跑跑看。至于继续预训练，除非你的领域术语跟通用语料差特别多，不然直接SFT一

我碰到过几乎一样的问题，后来发现光调chunk_size治标不治本。PDF里表格和列表被切碎后，bge对这种碎片语义本来就抓不准，打分高但内容不对路。你可以试试按标题层级做递归切分，保留段落完整性，再给每个块拼上所属章节路径当上下文。另外检索阶段加个rerank模型，或者用混合检索补一下关键词匹配，往往比死磕分块管用。

V100跑int4的6B模型3-5秒其实不算离谱，但确实还有压榨空间。你max_seq_len如果默认拉满到8k，光KV cache就吃掉不少，长文本总结建议按实际长度截断，能省一截时间。vLLM值得再折腾一下，报错多半是CUDA和torch版本对不上，装之前先锁死版本，跑通之后吞吐提升很明显。flash attention对V100支持一般，别抱太大期望，倒是可以试试把batch调大做并发推理会

我现在基本是Cursor写新模块、Claude Code改老代码。Cursor那个Agent确实容易改乱，关键是每次让它动手前先commit一下，出问题直接reset比回滚省心多了。Claude Code的确认虽然烦，但可以在配置里把一些安全命令设成自动通过，效率会好不少。你要是CRUD这种从零搭的，Cursor一把梭挺爽；但涉及已有业务逻辑的改动，还是Claude Code稳一点。

我之前也一股脑挂了六七个，结果工具列表长到模型经常选串，后来改成按场景分组，只给当前任务相关的三四个，响应明显快了。连接池和超时确实不能忽视，尤其数据库那个，超时设太短会频繁重试反而更慢。其实常用逻辑塞prompt里也行，但得看调用频率，高频稳定的干脆写死，低频多变的才走MCP。

我之前也踩过这个坑，后来发现7B这个量级的模型确实在长对话里容易“忘记”自己的角色，尤其是你这种字数限制加语气要求叠在一起的时候，它注意力会漂。我的经验是别光在system里写，最好在对话历史里每隔两三轮回插一句简短的提醒，比如“（客服小助手语气）”，比重复整段system管用。另外50字限制本身也会逼它跳戏，因为它一旦觉得信息没说完，就会切回通用助手模式来补全。few-shot确实值得加，但别只

我之前也踩过类似的坑，模型生命周期这块确实头疼。后来改成全局单例加载，用asyncio的锁控制推理队列，显存泄漏基本是没加torch.no_grad或者输出张量没detach导致的。并发超时的话可以试试把推理丢到线程池里跑，别阻塞事件循环。序列化我直接走ONNX加动态量化，MCP那边只传输入输出，省心不少。

Ollama默认那套参数确实挺坑的，它给的长上下文配置基本就是能跑就行，根本没针对代码补全场景调过。我之前也踩过类似的坑，7B的coder模型在Ollama上跑16k上下文，KV cache直接把显存吃满，然后就开始疯狂swap，速度能不崩吗。llama.cpp手动调n_batch和flash attention会好不少，但说实话7B模型本身长上下文能力就有限，你塞8000行进去它注意力早就散了，

rerank本质是精排，它只能在候选集里挑相对好的，源头全是错的它也变不出正确答案来。你这个CMS缩写的问题特别典型，通用embedding模型对垂直领域黑话就是没辙，top20都没沾边的话rerank纯属白给。与其纠结rerank不如先上混合检索，BM25对精确术语匹配其实挺能打的，再加个同义词词典基本就缓解大半了。微调reranker性价比不高，那点标注数据不如拿去微调embedding或者做

7B模型做结构化输出确实容易飘，我拿Qwen2.5-Coder试过类似的事，纯靠prompt硬约束的话，字段一多就开始瞎编。后来发现一个挺管用的思路，就是别让它自由生成整个JSON，而是用类似“填空”的方式，把schema先固定好，只让它填值。比如你直接给它一个模板，里面字段名和括号都写死，让它只替换占位符，这样漏字段的概率会低很多。另外可以试试在推理时加个grammar约束或者用outlines