从零开始商业修炼册

我之前也踩过这个坑，后来发现一个挺关键的转变：别把prompt当一次性指令，而是当成一个需要反复调试的接口来对待。具体做法是固定住输入变量，比如同样的schema和几条样例数据不变，只改你描述需求的那句话，然后跑个十遍二十遍看成功率。这样你至少能区分是模型在这个任务上本身就不稳，还是你的措辞确实有系统性缺陷。像正则和SQL这种有明确对错的任务，其实比开放写作好评估多了，你可以直接建个小测试集，每次

十几万条数据768维其实还好，内存大概几百兆，别急着降维，text2vec-base-chinese本身就是在768上训练的，硬降到256掉点很正常，你感觉飘大概率不是代码问题。faiss做增量更新比较麻烦，得自己维护ID映射和重建索引，后面要频繁加文档的话直接上Milvus省心很多。索引先上HNSW，参数M和efSearch调一调，召回和延迟都能兼顾。内存估算就是条数乘维度乘4字节，再留个索引本

我之前也碰到过类似的情况，后来发现是 MCP 的 stdio 传输方式下，客户端等的是 server 走完整个 JSON-RPC 往返，目录一深文件一多，光遍历目录就够呛。你可以试试在 server 启动参数里把允许访问的路径收窄，别让它递归扫整个项目。另外超时不一定在客户端，Claude Desktop 那边日志不太透明，建议先用 mcp inspector 单独跑一下 server，看单次 t

我也遇到过这情况，Sonnet确实有“过度优化”的毛病，尤其你prompt里没把边界框死的时候。我一般会在结尾加一句“只改我指出的问题，其他逻辑、命名、结构一律别动，不要拆分组件”，基本能压住它。另外提示词里最好明确说“保持现有class写法，不要转function”，不然它默认会往现代写法靠。如果项目风格统一，也可以直接贴一段现有代码当风格参考，它模仿得还挺准。

贴个数据样例再让它分步出逻辑，我试过管用，小细节基本不翻车了。

我一般直接在prompt里写“只用pandas内置方法，别定义新函数”，挺管用的，你可以试试。

我之前也踩过这个坑，后来直接换成按AST切了，用tree-sitter或Python自带的ast模块把函数和类拆出来当独立chunk，效果立竿见影。embedding那边不用大改，只是chunk的元数据里最好带上所属文件路径和依赖的import信息，检索命中后再拼回完整上下文喂给模型。你要是嫌自己写麻烦，可以看看llama_index的CodeSplitter或者chonkie这类库，省不少事。

我之前也踩过这个坑，本质上是把状态机当成了消息队列来用，两个Agent各自等对方往共享状态里写东西，但谁都没定义清楚“我这一步算完成”的边界条件。后来我改了个思路，不在节点之间共享可变的memory，而是每个Agent只产出不可变的artifact，用一个router节点决定下一步走向，这样就不存在互相覆盖状态的问题了。至于死循环，LangGraph本身有recursion limit可以兜底，但

我踩过类似的坑，法律文本里“定金”和“违约金”在embedding空间里确实挨得很近，bge-m3对这类专有名词的区分度本身就一般。你可以先试试按条款语义切，别固定300字，把“第五百八十五条”这种条号一起切进chunk里，检索时条号信息能帮上忙。另外法律领域建议直接上bge-large或者换个法条微调过的模型，比调top_k管用。rerank强烈建议加，bge-reranker跑一遍能砍掉不少“

多模态记忆锚点这个点确实戳到痛处了，我们之前做展厅机器人也是卡在这——语音和视觉的时间戳对不齐，回溯时经常张冠李戴。轻量向量库+本地缓存能撑住实时交互不奇怪，但跨天记忆的索引重建才是真考验，尤其边缘端存储一满就得做冷热分层。好奇他们有没有公开端到端延迟数据，光靠WAIC现场那几分钟演示看不出衰减曲线。

Cursor里有个设置可以调，在Settings里搜“inline suggest”，把延迟时间从默认的0调高到300-500毫秒，基本能解决你敲一半被打断的问题。MCP本身我没记错的话没有补全权重这种参数，它主要管工具调用那一层，补全行为还是看编辑器自己的配置。Claude Desktop那边更多是对话式的，跟Cursor的Tab补全不是一套逻辑，你可能把两边的行为混在一起了。

我们目前是分开两个collection，短期记忆用Redis做缓存加TTL，长期知识才写进向量库，检索时先查短期再决定要不要拉长期。短期过期后直接归档到冷存储，万一以后要回溯还能捞回来。你说的filter效果差，可能是metadata设计太粗，试试把session_id和turn_index组合起来做分层过滤？

两张4090跑7B微调，试试开gradient_checkpointing，能省不少显存。

我上周也踩了这个坑，后来发现是grpc那套依赖把protobuf锁死了。试了下用uv建个独立虚拟环境专门跑MCP，比docker轻多了，装的时候手动指定protobuf版本就行。另外建议先跑一下pipdeptree看看谁在拉旧版本，有时候不是你的主依赖在作怪。官方那个requirements里其实写了个兼容区间，但没强调冲突场景，确实容易翻车。

短期记忆这块其实不太适合纯靠向量检索，最近几轮对话直接按时间顺序拼进prompt反而更稳，向量留着做长期记忆或者跨会话召回。你说的重复问题我也踩过，可以试试检索完加一层去重或重排，比如按轮次聚簇后只保留最相关的一条，再配合最近N轮滑动窗口兜底。Pinecone里给每条记忆打上session_id和turn_index，检索时先过滤最近窗口再算相似度，冲突会少很多。

这个确实坑，我一般是在Tool层就把数据截断，只返回前N条加个总数统计，剩下的让LLM自己决定要不要翻页拉。你说的存引用ID也是个路子，类似RAG那种，把大结果丢到临时存储里，给Agent一个句柄，需要细节再按需查。MCP本身没强制规定这块，得自己在server端做瘦身。另外可以加个字段告诉LLM“还有多少条未展示”，它就知道该不该继续要了。

固定500切块确实容易把步骤拆散，试试按标题层级切，评估可以用问题集测召回率。

角色设定容易带偏，试试把“只基于文档”写进用户输入的开头，比系统提示管用。

别贪多，MCP就跟浏览器标签页一样，开多了全是内存杀手，留两三个核心的反而顺滑。 工具是拿来用的，不是拿来供的，按项目临时挂载最省心。

这问题我上周刚踩过，七八个MCP的schema全塞进system prompt里，几千个token白花花的烧，Claude思考能不卡吗。我后来只保留了三个核心工具，其他都用网关按场景动态挂载，响应速度直接翻倍。建议你查下官方文档的tool schema缓存机制，另外自己写的FastMCP服务尽量合并成单server，用子命令区分功能，别真当微服务搞。