持续迭代创业修炼册

这毛病我太熟了，agent类工具基本都有这倾向，它觉得顺手就改了，rules写“最小化改动”经常被当成耳旁风。我自己的做法是分两步走：先让它只输出方案和要改的文件列表，确认没问题再让它动手，能挡掉大部分乱改。另外diff的时候把无关改动直接reject掉，多来几次它也会收敛一点。真要治本还得靠git，改完先看stat，不对劲就reset重来。

我之前也卡在这一步，后来加了cross-encoder做重排序，效果提升挺明显的，你可以试试bge-reranker这种，比单纯调阈值靠谱多了。另外检索阶段可以多召回一些，比如top50，再用rerank压到top5给LLM，这样既不容易漏也不会太杂。让LLM自己过滤也行，但得多一轮调用，成本和延迟都上去了，看你能不能接受。还有个小技巧是把chunk切小一点，粒度细了相关性判断会更准。

我也遇到过这毛病，Sonnet总觉得自己的类型推断更“聪明”，结果把我特意留的联合类型全给合并了。后来我在项目根目录加了个.cursorrules，明确写清楚“不要修改已有类型定义，只做新增”，情况好了不少。另外重构前记得先commit，改乱了一眼就能diff出来回滚。或者干脆把类型文件单独拆出去，让它碰不到，也是个笨办法但挺管用。

遇到同样的问题，我后来发现光靠description和schema真不够，模型该飘还是飘。你可以试试把tool的name改成get_weather_by_city这种语义明确的，参数名也直接用city，别用location，少给模型自由发挥的空间。另外在prompt里加一两个调用示例，比单纯描述管用多了，我这么改完基本就稳了。

我4070也跑过Qwen2.5-Coder，改老项目确实容易断片。我的土办法是别让它一次吞整个文件，按类拆开喂，改完一个方法就让它重新贴一遍相关接口签名当锚点。RAG搭起来其实没想象中重，Chroma加个bge-small本地嵌入就够，主要费时间在切代码块。硬切对话最坑，上下文一丢它就开始编，不如手动维护个简短的项目结构摘要塞在system里。

7B模型标称14GB显存那只是权重本身在bf16下的占用，实际生产里大头往往在KV cache和激活值上。你8个并发、max_num_batched_tokens=4096，光KV cache按Qwen2.5的GQA配置算下来就得好几GB，再加上vLLM预分配的显存池和CUDA graph，冲到22GB其实不意外。RTX 4090跑推理确实容易卡在显存上，24G看着大，但vLLM默认gpu_mem

维度跟数据量关系不大，几千篇文档256维掉召回多半是分了太多小块。试试先调大chunk再降维，比硬堆维度管用。

这个问题我也踩过，纯靠向量相似度确实容易翻车。你调高阈值到0.85反而丢掉相关记忆，是因为embedding对“菜谱”和“代码”这种跨领域但语义结构相似的短文本区分度本来就不够，分数会挤在一起。我后来改用时间衰减加权的混合检索，把recency和相似度乘起来做排序，效果明显好很多，比如分数等于相似度乘以exp(-λ·天数)。另外你chunk切割如果是按固定长度切的，很容易把一轮对话的头尾切散，检索

工具描述别写太长，越简单Agent越不容易懵，我踩过这坑。

超时重试确实容易踩坑，可以试试指数退避+抖动，再给工具调用加个熔断，不然反复重试更拖垮整体流程。

几万条chunk用pgvector完全够，我朋友在production跑过二十万条加metadata过滤，延迟还在可接受范围，主要看你的QPS和索引类型。Milvus部署确实重，但如果你后续真要上几十万条且过滤条件复杂，pgvector的filter和向量检索组合起来会有点难受。建议先压测一下pgvector，用IVFFlat或者HNSW调参看看，真到了瓶颈再考虑迁移也不迟。一个人开发的话，运维成

说到24G跑7B微调，其实瓶颈不在模型本身，而在优化器状态和中间激活值。你batch size 4就爆，大概率是激活值没省到位——gradient checkpointing开了之后，建议把batch size调回4甚至8，因为显存占用大头从激活值变成了参数梯度，这时候你会发现同样显存能塞下更大batch。loss不稳定跟batch size太小直接相关，试试gradient accumulati

我们之前也踩过这个坑，后来是把历史query先做一轮轻量改写，比如把“他们的毛利率”补全成“A公司2023年毛利率”，只把改写后的当前query送检索，历史原文不进向量检索。上下文那块给LLM只保留最近两轮的必要摘要，不然真的会被无关chunk带偏。 不过摘要做得太狠又容易丢关键指代，我现在在试分层记忆，长期事实存向量，短期对话状态单独维护，检索的时候只带跟当前意图强相关的记忆片段。你们有试过把

碰到过类似的问题，尤其是工具一多，ReAct那种“边想边做”的模式确实容易在长链路上跑偏。我后来发现，光调prompt和temperature治标不治本，核心问题在于模型对“当前该用哪个工具”和“已经完成了什么”的短期记忆太脆弱了。我现在更倾向于把多步任务拆成显式的子步骤，比如用一个planner先规划好顺序，再让executor按list执行，而不是把所有判断都丢给ReAct循环。另外，你在工具

这太真实了，我上周用cursor写个数据清洗脚本也这样，加了行重试逻辑结果它把整个循环结构都给重构了，看得我一愣一愣的。后来我发现问题可能不在prompt，而是你得在改代码前先明确告诉它“只改这一个函数，其他地方别动”，甚至把它之前写的关键逻辑复制进对话里作为上下文锁定住。再一个就是别让它自己“优化”命名和结构，有时候它为了保持简洁会把注释和防御性代码全删了，下次运行报错你根本不知道哪出问题。我现

试试在需求后面加一句“禁止导入任何未指定的第三方库”，再不行就每次把报错直接甩给它让它删，多调几次就老实了。

说实话我建议你先别急着换embedding或者调chunk，你这个问题我太熟了，十有八九是召回链路里最容易被忽略的query处理环节出问题了。bge-m3本身对长文本的语义捕获已经不错，但你512的chunk配50重叠，如果文档结构本身是段落式的，那切出来的块很可能把不同主题的内容硬凑在一起，向量被平均了之后相关性自然就糊了。重排序救不回来的原因也很简单，它是在一个已经跑偏的候选集里做精排，如果t

我最近也试过类似方法，颗粒度其实取决于任务性质，重构这种活细节写清楚确实省事，但像你提到的“只想让给思路”的场景，我会在prompt里加一句“先讨论方案，不要写代码”，这样能避免过度服从。至于中途跑偏，我一般直接开新会话，因为旧上下文里的偏差会一直干扰后续判断，改prompt反而容易越描越黑。另外我觉得必须写的是“输出格式”和“禁止事项”，而项目背景这种写个大概就行，太细反而让模型束手束脚。

这题我太有同感了，之前做数据清洗也这样，模板在A数据集上神挡杀神，换个B数据集直接崩。后来发现关键不在模板本身，而在“示例”和“任务边界”跟实际数据分布是否匹配，模型对格式的敏感度远超我们想象。建议你先把输出改成JSON结构，再加一层校验逻辑，把漏字段的情况自动报错，比反复调prompt省心得多。至于玄学不玄学，我觉得70%是数据分布的适配问题，30%才是所谓的“直觉”，多记录每次改动和效果，慢慢

说实话你这个量级和维度，两边都能扛住，但真正让你纠结的可能是后续运维和查询模式。我自己的经验是，Milvus在数据量上了千万以后，分布式扩展确实更稳，尤其是你未来如果要做过滤+向量混合检索，它的标量索引和向量索引配合得更好。但Qdrant的API设计真的舒服，特别是那个payload过滤直接写进查询里，小团队开发效率高很多。 另外你用的是OpenAI的1536维，这点得注意，Milvus对高维向