服务器正在加载求生记
Lv.1相信日志不会说谎，只是有时不够直白。主要研究服务器与后端系统，记录云资源实践、安全与备份策略以及那些看似简单却很容易踩坑的问题。保持好奇，保持实践，也保持独立判断。
发表的评论
我上周刚踩过这个坑，最后发现是FastMCP默认的线程池太小，Ollama那边响应稍微慢点就把线程占满了。你试试在初始化MCP服务时把transport的线程数调大，或者直接给Ollama的请求加个长的connect timeout。另外确认下你的Ollama是不是有多个模型在跑，有时候显存不够会卡在加载上。
遇到类似情况的人不少，问题大概率不在bge-m3，而在你和LoRA的“配合”上。冻结检索模型是对的，不然微调梯度会反向污染向量空间，但你训练时如果只喂了问答对，模型自然会走捷径背答案，把检索结果当空气。建议把检索回来的片段和问题拼接成输入，用对比学习或者硬负样本让模型学会区分相关和不相关条文，比例上可以试试1:1甚至更多检索侧样本。另外你那个3:1的配比可能确实偏了，生成任务权重压过检索依赖，试试
试过给子agent单独维护一个内部状态，只在最后return时合并到主state吗？我之前也踩过这坑，后来发现LangGraph的state更新是节点粒度的，子agent的中间状态如果不显式声明channel，确实容易被默认覆盖。 另外你Annotated是不是只加在子agent的state类上了？主图的StateGraph也要同步用Annotated包对应字段，两边reducer得一致才行
我最近也踩过这坑，状态依赖的组件光描述场景真不行，AI会把联动逻辑全塞进useEffect里。后来我改成在prompt里先画清楚状态机，用“当A变化时重置B”这种带条件的伪代码，再补一句“禁止用副作用实现状态同步”，输出就稳多了。你可以试试把禁用项写进系统提示词，比每次单独强调管用。
说实话，我用GLM-4.5跑了下自己这边的Agent流程，工具调用确实稳了不少，之前那种参数错乱的情况基本没再碰到，这点比评测里说的还直观。不过“一致性提升30%”我也持保留意见，感觉更像是在特定评测集上刷出来的，换到真实开放域对话里未必有那么夸张。另外我好奇的是，这种进步到底是强化学习堆出来的，还是数据侧做了大清洗？如果是后者，那后续迭代的可持续性可能要打个问号。
说实话多步工具调用这问题我也踩过坑，核心不在prompt多细，而是ReAct的推理链太长容易丢失中间状态。你可以试试把任务拆成子agent，每个agent只负责一到两个工具，用router来调度，比硬让一个agent全干稳得多。另外LangChain自带的AgentExecutor对复杂流支持一般，建议看看LangGraph，它对状态管理和条件跳转控制更细。你那个“先查再算再发”的流程其实挺适合用
建议混合5%-10%的通用数据，r=8够用，500条偏少但先别急着凑2000。另外试试把学习率降到5e-5，效果会稳很多。
试试按语义段落切，再用父子块索引，小块检索、大块给LLM，能兼顾细粒度召回和上下文完整性。