周末写作小站

我也有类似感觉，但不是代码能力退化，是“裸写”的熟练度下降了。平时Copilot帮我省了很多体力活，可一到白板或者断网环境，确实会有点手生。我现在每周会挑一两个小题刻意手写，比如防抖节流、Promise串行，就当保持手感。能干活当然没问题，但面试和排查底层bug的时候，基本功还是藏不住的。

换向量库基本没用，Milvus和Chroma在语义召回上差别不大，瓶颈多半在你的embedding模型和检索策略上。问续费返回退款，大概率是这两个概念在向量空间里太近了，开源模型区分不开这种细粒度语义。建议先加个rerank模型试试，bge-reranker这类对中文场景提升挺明显的，再考虑query改写或者混合检索。

我现在的做法是把Prompt当代码管，每次改动都存个版本，顺便记一下改了啥、为啥改。评估的话不会只看那几个固定用例，会另外留一批没调过的输入当测试集，改完跑一遍看整体通过率，不然真的很容易过拟合。另外同一Prompt跑三次看结果稳不稳定也挺有用，GPT-4有时候就是抽风，不一定是你改坏了。

MCP本身不绑定框架，选哪个主要看你的部署链路。JAX在TPU和XLA编译优化上确实香，但调试成本高，新手写服务端容易卡在shape推导和jit的坑里。PyTorch生态成熟，推理优化有TensorRT、vLLM这些现成方案，踩坑资料也多得多。如果只是轻量多模态推理，建议先用PyTorch把流程跑通，上下文传递自己封一层就行，没必要为了“干净”硬上JAX。

可以试试把prompt拆成固定模板加变量，每次只改变量就行，我处理Excel就这么干的。

我之前也踩过这坑，状态丢多半是因为你在节点里返回的是局部字典，LangGraph默认会覆盖而不是合并，得用Annotated配reducer才行，比如给messages加operator.add。并行写同一个key互相覆盖也是同理，每个Worker最好返回自己独立的字段，最后再汇总。Memory那块建议别硬套LangChain的，直接用State里的messages更省心。Supervisor传参

同感，我一开始也以为是自己prompt写得不够细。后来发现光说“健壮性”太虚了，得直接点明“文件不存在、空行、类型错误分别怎么处理”，它才会老老实实加try-except。我现在的习惯是让它先列异常清单再写代码，比事后补靠谱多了。

我之前也踩过这个坑，7B模型对远程工具的schema理解确实偏弱，尤其参数嵌套一深就开始乱编。3000条LoRA数据里如果大多是本地工具调用，跟真实HTTP API的请求分布差太多，loss低不代表泛化好。建议你把system prompt里工具的description写得更死一点，参数类型和必填项都列清楚，再混一批真实Jira返回的样本进去试试。另外rank=8可能偏小，工具调用这种结构化输出任

我一般在根目录放copilot-instructions.md写清楚禁用RestTemplate，效果比对话里喊话稳多了。

我这边也踩过类似的坑，torch.compile对动态shape确实挺敏感的，你ResNet50输入固定按理说没问题，但数据加载那块如果有随机resize或者augmentation导致shape偶尔变化，它就会反复触发重编译，反而更慢。建议先加mode="reduce-overhead"试试，或者用torch._dynamo.explain看看哪里在频繁graph break。另外第一次跑会慢是

老项目隐式依赖多，AI确实容易顺手改跑偏，我一般让它先只读不改，确认方案再动手。

改代码前先让它复述一遍现有逻辑，确认没跑偏再动手，能少很多幺蛾子。

我最近也在搞这个，其实核心就是写个 adapter 层，tensor 转 list 再 json 序列化，反序列化后转回 tensor，不难但挺琐碎。模型常驻的话别用 stdio 那种每次起进程的方式，直接写个常驻的 http server 包成 MCP tool，进程活着模型就一直在显存里。延迟主要还是看模型大小和 batch，小模型基本无感，大模型建议加个队列别并发打爆显存。

我现在是用两层混合存的，短期记忆直接塞Redis按session过期，长期记忆才往向量库里写。写进去的也不是原始对话，而是让模型抽出来的结构化事件，比如“用户不吃香菜”这种，一条一个向量，检索时按语义召回再拼成自然语言给模型。整段对话摘要我也试过，问题是摘要太笼统，检索时容易匹配到一堆不相关的，反而干扰当前话题。换话题的干扰我觉得得靠时间衰减加session隔离，检索时给最近的和当前session

1.5k的prompt确实挺吃时间的，prefill阶段占了大头，QPS上不去很正常。你试试把max_num_seqs降一点，比如64或128，有时候开太大反而调度开销上来了。另外确认下是不是开了enable_chunked_prefill，没开的话长prompt会把整个batch卡住。显存跑满但利用率低，多半是KV cache占着但实际并发没跑满，可以看看实际running队列有多少。

绩效指标要是只盯完成率，Agent迟早学会刷KPI，知识沉淀谁管？

训练循环里如果累加了loss或accuracy到列表，计算图就留着不放了，检查下有没有`total_loss += loss`这种。

维度跟模型是绑定的，bge-small本身就是512维，你降到256相当于强行砍了一半信息量，召回掉是正常的。768慢可能不全是维度的锅，本地部署的话索引类型和查询参数影响也很大，可以试试调下HNSW的efSearch。几千篇文档其实512维完全够用，等涨到几万篇再考虑换bge-base或者加点rerank，比单纯堆维度划算。

这个问题我遇到过，本质上是模型把系统prompt当成了可编辑的上下文，而不是硬约束。我的做法是把规则拆到子代理里，主代理只负责调度，具体工具调用规则放在被调用的子代理的独立system prompt中，这样主代理根本没权限改。另外可以在每轮对话前用代码强制重置system message，别指望靠prompt里写“不要改”来约束，那基本没用。

TF那边每次重新trace确实挺要命的，尤其Agent里循环调用子图，overhead直接爆炸。我后来是把LLM子图单独拎出来固定shape再包一层，能缓解不少，但动态分支多的时候还是难受。PyTorch这边torch.compile对动态shape的guard机制也不是白给的，改一下输入维度就重编译，坑法不一样而已。你试试TF用concrete function加input_signature锁