小禾Coder手记

存原文是必须的，不然检索回来一堆向量你根本没法拼进prompt里，embedding只是索引不是内容。我自己是原文加向量都存，metadata里再塞时间戳、session_id、消息类型这些，方便后面过滤和排序。你说的token爆炸，大概率是把整段历史反复向量化导致的，应该只对新增的对话轮次做embedding，历史的部分靠检索召回而不是重新灌进去。重复召回旧内容这事我也踩过，后来加了时间衰减和去

我现在的做法是把Agent的prompt拆成三层：角色定义、工具使用规范、输出格式约束，每层单独迭代调优，比混在一起改要清晰得多。你提到的“总结再行动”其实可以用结构化输出强制，比如让模型先输出一个thinking字段再输出action字段，用schema卡住它。另外不同模型对few-shot的敏感度差别很大，GPT-4o可能零样本就行，但小模型就得靠例子堆。建议先固定一个模型，把prompt版本

我之前也踩过这个坑，LangChain的BufferMemory确实不太适合长对话，它就是把历史全塞进去，不炸才怪。你可以试试ConversationSummaryBufferMemory，设个max_token_limit，让它在超限时自动压缩前面的内容，比单纯用SummaryMemory稳一些。另外建议把重要信息单独存个dict，比如用户偏好、任务状态，每次拼prompt时手动带进去，比指望模

这问题我也遇到过，Cursor有时候确实会把逻辑写飞，特别是上下文一长就容易犯迷糊。我一般会在项目根目录放一个.cursorrules文件，把hooks相关的规则写进去，比在prompt里反复强调管用多了。另外可以配合eslint的react-hooks插件，生成后跑一下lint让它自己修，基本能兜住大部分问题。不过异步请求那块它还是容易乱塞，关键逻辑最好自己先搭好骨架再让它补细节。

你这情况挺典型的，法律领域专业词多，纯语义向量对术语其实不太敏感，召回差很正常。建议优先加个BM25做混合检索，成本低见效快，专业名词靠关键词能兜住不少。HyDE和rerank是在混合检索之后锦上添花的，先别急着上，不然调起来变量太多。另外chunk 500对法条来说可能有点碎，试试按条款结构切，别硬按字数。

你这个情况大概率就是Ollama默认的context window太小了，它默认好像是2048还是4096来着，你光system prompt就300多字，加上用户输入和模型已经开始生成的输出，很容易就顶到上限了。一旦超了，模型不是你想象中那样直接报错，而是会表现得像“断片”一样，回复到一半逻辑崩掉或者干脆卡住。Qwen2.5本身支持的上下文其实挺长的，7B版本官方说能到32K甚至128K，所以问

我也拿GLM-4.5跑了几个之前4.0经常翻车的多步工具调用场景，确实稳了不少，特别是参数传递那块没再乱套。不过一致性提升30%这个数我持保留态度，体感大概也就好了两成左右，而且长对话到后面还是会有点飘。Agent这块进步是实打实的，但要说追平GPT-4o我觉得还得看具体任务，开放性推理上差距还是能感觉出来。

我之前也这样，后来干脆把Prompt当代码管了，每次改动都记下改了什么、为什么改，再用几个固定的测试用例跑一遍对比效果。文件名直接写日期加改动点，比如0412_加了退款场景few-shot，比v2_final靠谱多了。另外建议把系统提示和few-shot例子拆开维护，调语气的时候别动例子，不然真的牵一发动全身。十几个版本不算多，关键是要能回滚，不然改崩了连退路都没有。

内部调用真没必要硬上MCP，我们试过一版，光是把模型IO对齐成tool schema就花了两天，后面改个输出字段还得同步改三处。它真正有用的场景是让LLM自己决定调哪个模型、按什么顺序调，比如多模态pipeline里动态选检测或分割模型，这种编排REST也能做但会很脏。如果只是固定几个接口给后端调，Flask包一层反而更省心，别为了协议统一给自己加维护成本。

几十万条数据 pgvector 完全扛得住，别被那些性能对比文章吓到，很多测试场景跟你根本不一样。索引直接上 HNSW，IVFFlat 在数据量小的时候反而容易召回不稳，还得调 list 参数，HNSW 省心不少。真正要担心的是并发上来后 Postgres 连接池会不会成为瓶颈，跟向量检索本身关系不大。等数据真涨到千万级或者 QPS 顶不住了再拆独立向量库也不迟，RAG 这种场景延迟大头往往在 L

两张3090跑7B LoRA理论上是够的，但默认fp16加载光模型权重就快14G了，再加优化器状态和激活值，24G单卡确实容易炸。试试4bit量化配上device_map自动分卡，别让一张卡扛全部。batch size 4有点激进，先降到1跑通再说，gradient checkpointing在Trainer里把gradient_checkpointing设成True就行，能省不少激活显存。

显存这东西真的不能光看权重，INT4量化完模型本身确实就5G左右，但推理框架还要预分配KV Cache，这块才是吃显存的大头。你那个OOM八成是vLLM默认gpu_memory_utilization给太高了，它会把剩余显存几乎全吃掉，得手动压一下。KV Cache的估算大概是2乘层数乘隐藏维度乘序列长度乘batch再乘精度字节数，7B模型开4K上下文单条请求差不多就要1G多，你要是并发几条直接爆

机器人出海最怕的其实是售后和维保，速卖通能搞定物流，但坏了谁来修？C端试水可以，B端才是真金白银。

几万到几十万这个量级pgvector其实扛得住，主要还是看过滤条件复杂度和QPS。我之前有个项目40万chunk加metadata过滤，单机pgvector查询基本在几十毫秒，但并发一上来就明显掉。Milvus功能强但组件多，一人维护确实累，Qdrant单二进制部署会轻不少，可以顺手试试。真要省心，先把pgvector的HNSW索引和分区调好，等真扛不住再迁也不迟。

MCP本身不负责解析文件内容，它管的是让模型知道“有哪些工具可用、怎么调”，真正干活的还是Tika或Unstructured这些解析器。你可以把解析器包装成MCP Server，模型就能在需要时自动调它来啃PPT或扫描件了。不过扫描件OCR和表格还原这种坑，解析器该踩还是得踩，MCP只是帮你把流程串起来，别指望它变魔术。

Cursor 改代码确实容易上头，我现在的做法是把规则写进 .cursorrules 里，比如禁止使用 @Transactional 除非我明确说了，实体字段必须和 schema 一致，这样能拦掉一部分乱改。但光靠 prompt 约束还是不够，它该重写还是重写，尤其是你说“修复空指针”这种模糊指令，它会觉得整个方法都有问题，干脆推倒重来。我后来学乖了，改成“只修改第 23 行，把 userMapp

同感，我用了半年Copilot之后发现自己有个很明显的变化，就是遇到问题第一反应不是去拆解，而是先敲个注释等它补全。以前写Java的时候还会想想这个类该怎么设计，现在直接Tab Tab Tab，跑通了就完事，但回头让我讲清楚这段逻辑为什么这么写，我可能得愣几秒。Cursor的Composer确实更猛，能一次改好几个文件，但问题也在这，它帮你做的决策越多，你自己脑子里留下的东西就越少。我觉得关键不是

80万这个量级其实两个都扛得住，真正拉开差距的是过滤字段的基数和查询并发。我这边Qdrant跑过两亿出头，带payload过滤的混合检索P99能压在50ms内，内存占用比Milvus舒服不少，但集群化和跨节点扩缩容确实没Milvus成熟。Milvus功能全是真的，代价是etcd、MinIO、Pulsar一堆组件，运维成本得提前算进去。K8s不是必须的，单机docker compose先跑通业务，等

loss卡在1.8还震荡，加上验证集复读指令标点，这更像数据格式没对齐导致的，模型在硬背模板而不是学任务。LoRA本身对数据质量挺敏感的，清洗只去重切分远远不够，指令和回复得成对规整好才行。至于用ChatGPT重造数据，能提纯但别全量替换，混着原始数据用更稳，不然容易过拟合到GPT的腔调上。我遇到过类似平台期，扩数据量有用但前提是格式统一，否则加得越多噪声越放大。

TTFT 5-6秒明显不正常，A100上8B模型FP16预填充不该这么慢。先确认下是不是开了enforce_eager，这个会关掉CUDA graph，对首token延迟影响很大。另外检查下是不是每次请求都在重新编译或者swap，gpu_memory_utilization别设太低。AWQ确实能降显存带宽压力，但对TTFT帮助有限，你这情况更像是调度或编译问题。