一只鹤正在学习日记

我们生产环境也是从stdio迁到streamable HTTP的，主要考虑是长连接复用和负载均衡好做，SSE单向推送在客户端回调场景有点别扭。鉴权这块别自己造轮子，用nginx或者Caddy前置一层，配个OAuth2 proxy插件，比在MCP层硬塞API Key省心多了。进程管理其实systemd够用，但建议把Restart=always和WatchdogSec加上，日志直接推给Loki或ELK

Milvus部署重一点，但胜在功能全，尤其filter和索引类型多，生产环境稳。Qdrant轻量，上手快，不过数据量大了之后内存占用有点吓人，而且文档里的坑比想象中多，比如payload索引不建好查询直接卡死。我之前从Milvus迁到Qdrant，最难受的是聚合查询性能差一截，但如果你只是做简单相似搜索，Qdrant完全够用。你们现在数据量大概什么级别？

这个分析角度挺有意思，尤其是把签名校验和资源哈希的点单独拎出来讲，确实很多暴力替换方案都栽在这上面。不过我有点好奇，钩子注入在Electron这种多进程架构下，会不会遇到渲染进程和主进程通信时的权限限制？毕竟之前试过类似方案，有些系统API在沙箱环境里根本拦不到。另外适配器如果跟Codex版本绑定太紧，升级时可能还是得手动跟进，除非作者能维护一个自动匹配版本的机制，不然长期用下来维护成本估计不低。

我之前跑13B也遇到过类似问题，gpu_memory_utilization确实得手动调，默认0.9对32B加量化太激进，你试试压到0.75左右，给KV cache留点余量。另外max_num_seqs降到16甚至8，对demo场景完全够用，能省不少显存。还有个小技巧，vLLM里可以开enable_prefix_caching，内部demo如果请求有重复前缀，能显著减少计算峰值，你可以试试看。

我最近也在用GLM-4.5做Agent相关测试，工具调用这块确实比4稳了不少，之前那种参数错乱的毛病基本没再犯。不过“一致性提升30%”这个数字我也存疑，感觉可能跟评测集选择有关系，换个更偏创意生成的场景未必有这么明显。另外我更好奇的是，它在长上下文里的推理衰减控制得怎么样，有没有人测过超过32K之后的实际表现？

我个人是把异常处理直接写进系统提示词里，比如固定一段“所有文件操作必须用try包裹并打印具体错误”，效果比每次现加要好很多。另外你可以试试在代码里主动要求它定义个load_data函数，把路径检查放在里面，这样AI大概率会自己带上os.path.exists。还有个偏方，让它先写伪代码再补全，逻辑完整了异常就漏得少了。

按段落和标题切靠谱，再配合重叠窗口，实测比固定token好用很多，召回和完整性都能兼顾。

轻量适配就行，别硬套对话那套，tensor shape和dataset配置直接映射成自定义context字段更省事。 多模态确实麻烦，我是拆成子context再合并，生产环境跑了大半年没啥大坑。

这不就是数据风格迁移嘛，rank64背大锅，降到16试试，保准见效。 LoRA学到了“委婉”的分布特征，光清洗文本没用，得在训练时硬怼“无法回答”的负样本。

温度这块建议直接调成0，然后别依赖单一prompt，把JSON Schema直接塞进system message里，再让模型输出前先自己列一遍字段清单，能明显减少漏项。few-shot确实不稳定，不如加个后处理脚本兜底，解析失败就重试一次，比纯调prompt省心。Llama和DeepSeek我试过，Qwen其实算听话的，关键还是得靠代码层面做约束。

试试AWQ量化配vLLM，显存能再压一截，多轮对话崩主要是显存碎片化，vLLM的paged attention正好治这个。

我最近也踩过这个坑，后来发现光靠prompt真不如直接改检索端。你可以试试把Top-K降到3，同时加个重排序模型，比如bge-reranker，过滤掉那些低相关的片段，这样模型拿到的输入本身就干净很多。 另外prompt里可以写“只使用与问题直接相关的句子，其余忽略”，但千万别让它“判断相关性”，不然模型容易脑补。我试过在上下文里给每段加个编号，然后要求回答里只引用编号，效果比泛泛的指令稳定不少

你这问题太真实了，ReAct最怕的就是上下文一长，模型自己把优先级搞乱。我试过把工具结果里的关键字段提取出来单独放一段，跟历史对话分开存，效果比全塞给模型好点。另外就是给每条工具结果加个时间戳和任务ID，让模型能区分“当前任务”和“旧记忆”，不然它真会拿上周的股票数据回答明天的天气。你向量库那招我觉得方向对，但别光存摘要，把工具返回的原始JSON结构化之后存进去，召回时只给和当前意图相关的部分，试

MCP确实能让AI调用工具，但“自动修bug”得看server怎么封装。我试过用官方TS server连本地，坑在路径和node版本，改成绝对路径+用npx启动就通了。不过就算连上，AI也只是执行你写好的脚本，比如让它跑eslint --fix，它不会自己判断该改哪。想全自动得自己写个server把诊断结果回传再让模型改，工作量不小。 我这边用cursor配了个简单的MCP，让AI读tsconf

这问题我上周刚踩过坑，7B做Agent确实容易爆，尤其是多轮对话里每轮都要带历史，KV cache翻倍涨。建议先开一下vLLM的--enable-prefix-caching，能复用公共前缀，我这边试了能省不少显存。另外量化到INT4或者AWQ，显存占用直接砍半，但要注意精度流失对Agent工具调用判断的影响。要是还扛不住，可以试试SGLang，它的radix attention对多轮场景优化更狠

这锅大概率是检索的，top5里可能压根没有能回答“入职两年休几天”的资料。

4060 8G跑7B确实尴尬，我之前用Qwen试过类似方案。Q5_K_M和Q6_K的GGUF比GPTQ 4bit强不少，尤其在多轮对话上逻辑连贯性会好一些，但显存占用会往上走，得配合15-20G的swap或内存。分层跑CPU的方案效果取决于你的内存带宽，笔记本双通道的话可以试试把前几层放CPU，用llama.cpp的--tensor-split参数调，不过速度会慢到怀疑人生。其实最省心的办法是直接

试试给每个chunk打时间戳和主题标签，检索时加filter，比纯向量相似度靠谱多了。

时间衰减这个其实不用靠Chroma硬做，可以在取回后按timestamp算个指数衰减的分数再重排，效果比单纯top_k好很多。另外短期记忆建议单独开个collection，只存最近几轮完整对话，长期记忆可以按实体或者事件抽摘要再存，不然全是碎消息。你试过用metadata存时间戳然后自己写衰减逻辑吗？

光靠一句咒语确实不稳，试试给个带推理过程的小样本，模型才有参照系跟着走。