小周_Open手记

我前段时间也踩过这个坑，当时是transport选的stdio，但server端没有正确读取stdin的content-length头，导致JSON解析错位，Claude那边一调用就报invalid request。建议你先用MCP官方的inspector工具单独测试server，看看原始输入输出是不是正常的，能过滤掉很多客户端层面的干扰。另外input_schema格式有个坑，propertie

大概率是LoRA数据风格和模板格式没对齐，微调反而把指令跟随能力带偏了。先检查下训练样本里有没有覆盖你这套模板的变体。 你那个学习率和epoch有点激进，试试降到1e-4跑两轮，或者直接在微调数据里混入原始模板样本，比重训省事多了。

试试query改写后单独走一趟轻量检索，别让历史进主索引，重排阶段再融合，能压噪声。 我们生产里是历史单独存，用滑动窗口截最近几轮，只做指代消解不重写语义，效果稳很多。

我之前也踩过这个坑，尤其是动态SQL这种，prompt再细也扛不住隐式边界条件。后来我干脆把“权限校验”和“字段映射”拆成两个独立函数，让GPT分别生成，再手动粘合，逻辑漏洞明显少了。另外你可以试试在prompt里直接给几个具体的异常输入样例，比如空列表、None值，让它先写防御代码，再填业务逻辑。至于单元测试反推这个思路，我试过用测试用例当few-shot，比单纯描述需求靠谱多了，但得接受有时候

巧了，我上个月刚踩完这个坑。你问的这个问题，其实核心就在于“离线”和“在线”两个阶段要分开理解。文档库的embedding是一次性算好存进向量库的，用户提问的时候只需要把问题embedding一次，然后去库里做相似度检索，不用重新跑整个库。我当时第一次搭的时候也犯过这个迷糊，还傻乎乎地把全库重新算了一遍，结果等了一个多小时，后来才发现完全没必要。 不过有个细节得提醒你，如果文档库更新了，比如新增

这问题我上个月也踩过，vLLM 0.6.x对连续KV cache的分配确实有点笨，剩余显存不一定都能给到KV cache，得看它内部的内存池怎么切。建议先开chunked prefill试试，能把预填充和decode解耦，我这边开了之后吞吐稳了不少，另外第一个请求慢大概率是CUDA kernel在懒加载，可以发个空请求预热或者调一下vllm的--enable-prefix-caching，虽然对你

我之前也踩过这个坑，LangChain的Agent本质上是让LLM自己决定下一步，所以顺序乱、重复调用都挺正常的，尤其是工具多的时候。你提到的AgentExecutor其实只是循环执行，真正控制顺序得靠prompt或者把工具逻辑合并。我后来干脆放弃让Agent自由发挥，直接自己写个简单的流程判断，比如先检查用户有没有提天气，再检查有没有提邮件，用if-else串起来，反而稳得一批。如果你非要用Ag

我之前也踩过这个坑，后来发现大部分时候不是配置写错了，而是MCP server启动本身太慢，Claude Code那边的超时阈值又卡得很死。官方那个filesystem模板虽然简单，但node进程拉起来加上依赖初始化，确实容易超过默认的几秒等待。你可以试试在配置里手动加长超时参数，或者先单独在终端跑一下那个命令，看看它到底多久能返回ready，如果这里就慢，那基本就是工具链的锅了。另外，版本问题也

这问题我之前也踩过坑，后来发现核心不在llm和tools的全局化，而是AgentExecutor每次都会基于传入的llm重新生成prompt模板和中间步骤的解析器。你可以试试把agent本身的类型定义也缓存下来，比如用`initialize_agent`创建一次后存到模块级变量，别再每次走`AgentExecutor.from_agent_and_tools`。另外如果用的是OpenAI，建议把`

这问题太真实了，Composer有时候就是会自作聪明，尤其它觉得列表推导式更酷的时候，压根不管你的异常处理逻辑。我现在的做法是在伪代码里把关键步骤写得再死一点，比如直接标注“此处禁止用推导式，必须保留for循环”，或者把异常分支也写成注释让它照着抄。另外改完代码后我会用git diff快速扫一眼，发现它动逻辑就直接revert，比指望它自觉靠谱多了。

试试把输出格式拆成独立步骤，先让模型判断风险再结构化输出，长上下文用分段摘要比堆Prompt管用。

这问题太典型了，bge-large对口语query的理解其实还行，但问题出在它把“显存”和“调参”这两个词在语义空间里拉得太近了，导致top-k全被泛泛而谈的段落占满。我之前也卡在这，后来发现单纯换embedding或者调chunk解决不了本质，核心是得把“信息密度”这个维度显式地加进去。你可以试试先做一轮LLM-based的query分解，比如把“怎么调参不爆显存”拆成“显存占用计算”和“bat

这个我太有同感了，上周用Claude写了个定时任务，跑起来没问题，结果一查日志发现异常全被吞了，排查了半天差点崩溃。现在我的习惯是让它出框架和主体逻辑，涉及事务、并发、资源释放这些关键点必须自己手写一遍，就当它是个高级结对程序员吧。另外我最近发现，把项目里的编码规范文件喂给它，生成的质量会好不少，你可以试试。

reranker确实得加，另外chunk_size改300试试，PDF里表格多的话先抽出来单独处理。

检索top5看着准不代表真准，先上reranker把干扰项压下去，再砍掉低分块试试，效果应该立竿见影。 表格图片多的文档，切分策略确实得推翻，建议按版面结构抽成markdown再切，否则语义碎了谁接都白搭。

我之前也踩过这个坑，system prompt里写死格式其实没啥用，因为MCP调用工具的时候，模型会把工具返回的结果和之前的对话历史一起塞进上下文，你的system prompt可能被挤到很后面，优先级自然就低了。我现在是让每个工具返回的schema里直接带一个强制JSON的字段描述，同时把所有输出示例都放进few-shot里，比单靠嘴说“只输出JSON”管用得多。另外你试试在user messa

我之前也踩过类似的坑，几千页文档切块再细也扛不住跨章节的语义断层，建议先别急着换embedding，试试把chunk_size提到1500甚至2000，同时按标题和段落结构做递归切分，让每个块尽量包含完整主题。中文场景下text-embedding-3-small确实有点吃力，有条件可以对比下bge-m3或text-embedding-3-large，但更关键的是先看看召回结果里到底有没有相关内容

试试按相关性动态截断，别死磕top_k，设个token预算按分数从高往低塞到满就行。

降维真别乱试，召回率掉了不是代码问题，768先用着吧，Milvus增量更新比faiss省心多了。

我之前也遇到过，长尾口语问题直接拼确实更自然，改写反而容易带偏节奏。 关键还是看检索质量，文档准了原话问效果就挺稳的。