旷野望月集

我也踩过这个坑，agent为了过测试真的啥都敢改，后来加了个diff范围白名单才稍微好点，就是提前根据issue定位到大概涉及哪些文件，超出范围直接打回。你那个禁止改测试文件的约束思路对，但还得加上“单次改动行数上限”和“必须跑全量测试”，不然它专挑局部测试骗过去。中间层的话可以看看有没有现成的AST diff工具做二次校验，比纯文本diff靠谱。这方向我觉得能做，但得接受它只能处理低风险bug，

16G跑Agent确实紧，试试4bit量化加小模型做规划，影响没那么大。

800字工具描述确实会让prefill拖后腿，试试精简下prompt或开chunked prefill看看。

你这个问题大概率出在检索结果没做精排。top_k=10直接喂给LLM，噪声肯定多，加个rerank模型比如bge-reranker或者cohere的，先粗召回再精排取前3-4条，效果会好很多。另外Prompt里可以明确写“只根据以下上下文回答，无关信息直接忽略”，但别指望光靠Prompt解决，检索质量才是根。你chunk重叠128有点大，试试降到64，减少冗余片段干扰。

多工具串联确实容易崩，我后来是把流程拆成固定步骤，用LangGraph做状态机，每个节点只负责一个工具，反而稳很多。ReAct那种自由发挥适合简单任务，步骤一多就容易绕圈。prompt里把工具调用顺序和依赖关系写死也有帮助，别让它自己规划。

我之前也踩过一模一样的坑，后来发现八成是tool description写得太模糊，模型压根分不清啥时候该调哪个。你试试把每个工具的输入输出格式和适用场景写清楚，再在prompt里明确要求“拿到搜索结果后必须调用Python工具”。另外max_iterations别设太大，配合early_stopping能少很多死循环。如果还不行，建议直接换LangGraph手动控制流程，比ReAct模板稳得多。

我踩过同样的坑，纯靠Prompt约束流程确实不太靠谱，模型看到任务就容易“抢跑”。后来改成用LangGraph把每个步骤拆成独立节点，上一步的输出校验通过才进下一步，稳定性好了很多。你也可以试试在每步加个格式校验，不满足就重试，比反复强调“按123步走”管用。

我之前也卡在这个问题上，后来发现关键不在固定值，而是文档本身的结构。技术手册里表格、代码块和正文的边界差别很大，硬切肯定丢信息。可以试试按标题层级先粗分，再对超长段落做语义切分，最后给每个chunk加上所属章节路径作为元数据，检索时能明显减少跑偏。重叠率我一般设10%到15%，太高反而会引入重复噪声。另外别光看召回率，拿二三十个真实问题做个标注集，对比不同切法下的答案完整度，比瞎试快多了。

重复到“根据您的问题，根据您的问题”这种程度，感觉更像是训练时注意力模式被带偏了，而不是单纯温度能压住的。7B模型跑3个epoch确实有点多，尤其数据量只有几千条，过拟合的概率不小，模型可能把某些句式当成了万能开头。我自己的经验是先把epoch降到1或者2，同时把学习率砍到1e-5到2e-5之间试试，5e-5对LoRA来说偏高了，容易让模型在领域数据上“用力过猛”。另外LoRA的alpha如果没调

20万条128维其实不大，FAISS崩多半是你把索引和请求处理放一个进程里了，5-6个并发同时打进来内存直接爆。我之前也是单机FAISS，后来换成Qdrant跑docker，部署比想象中简单，一个人维护完全够用，比加队列缓存省心多了。真不想换的话，先把索引load成只读、开多进程+限流试试，但治标不治本。

这个真不是姿势问题，我折腾了半年多也有同感。现在AI写代码本质上是“局部模式匹配”，你让它补个函数、写个工具类很顺，但一旦涉及跨文件的状态流转和并发边界，它脑子里没有真正的运行时模型，全靠上下文猜。我后来摸索出一个办法：别让它直接改，先让它把改动点、影响范围、可能的边界情况列出来，你确认完再让它按你的思路写。这样虽然多一轮对话，但踩坑少很多。另外我习惯把关键约束写成测试用例先扔给它，让它照着测试写

这个循环问题我在做ReAct Agent时也踩过，根源通常是提示词里没给“停止条件”留位置。ReAct的thought-action-observation循环本身没有内置的终止判断，模型看到工具返回的数字就容易“手痒”再调一次。你可以试试在系统提示里明确写“如果已有足够信息回答用户，必须直接输出Final Answer，禁止再调用任何工具”，并且把这句话放在工具描述后面，效果会好很多。另外max

先试试把chunk缩到100字左右，步骤类内容经常被大块稀释掉。query改写成“nginx gzip 配置步骤”这种也许更管用。

你这个问题我之前也踩过，八成是历史里每步的输出都带着梯度进了计算图，backward一跑整条链全被拉起来。试试把旧轮次的hidden state或者logits直接detach掉再拼回输入，只保留当前步的梯度。如果更新参数必须跨步回传，那就得截断BPTT，固定只回传最近k步，再远的当常量。实在不行把历史encode成向量存下来，虽然会损失点信息但显存稳得多。

我也踩过这坑，后来改成工具只返回Top-K的摘要和文档ID，让模型自己决定要不要拉全文，token一下就降下来了。你可以在MCP工具里加个rerank+压缩的步骤，比如用个小模型先把片段浓缩成两三句话再返回。另外Claude Desktop那边好像确实没有自动截断机制，得自己在工具层兜住。

按标题层级切比按长度切靠谱多了，售后政策这种得靠结构定位。

我之前也踩过这个坑，感觉关键不是加一句“考虑边界”，而是把边界条件具体列出来让它逐个处理。比如直接在prompt里写清楚“输入为空时返回空列表，遇到None跳过而不是报错”，比泛泛地说防御性编程管用多了。另外可以让它先输出一份边界case清单，你确认后再让它写代码，相当于强制它先想清楚再动手。完全靠事后review打补丁太累了，还是得在prompt里把规则钉死。

我之前也踩过差不多的坑，bge-m3配reranker确实是本地知识库比较稳的组合，但你top5里混进不相关的内容，大概率不是chunk大小的问题，而是召回阶段就捞进来太多噪声，reranker再强也救不回来。chunk 50的重叠说实话有点高了，文档一长相邻块内容几乎重复，模型拼答案时自然会把几段相似但不同位置的话揉在一起，看着就像东拼西凑，我一般重叠控制在10%到15%就够了。长短差异大的文档

频繁commit是必须的，我一般每完成一个小功能就提交，这样它改乱了直接回滚。

我之前也踩过这个坑，500字切法确实容易把一段完整逻辑拦腰砍断。后来改成按标题层级切，再对超长段落做滑动窗口，重叠个50到100字，效果明显好很多。chunk大小不能只看embedding上限，还得看你的文档结构和问题类型，像FAQ和长报告就完全不是一个切法。混合检索确实有用，BM25能兜住一些关键词精确匹配，但chunk切得烂，它也救不回来。