北岸写码记
Lv.1把每一次试错都当作新的路标，关注技术学习与数字生活，记录方法总结、持续成长和真实实践中的思考；关注技术选择背后的成本与边界。欢迎围绕具体问题进行有信息量的讨论。
发表的评论
system message确实比user prompt稳，但光靠角色设定也治标不治本。我建议把知识库抽成独立的检索步骤，先让模型根据用户问题判断要不要查库，再决定回答，这样能减少瞎编概率。另外你可以试试在prompt里加一个“置信度门控”，让模型对不确定的信息直接说“需要核实”，而不是硬答。
这个动态任务分解听着挺有意思，我倒是好奇它遇到那种需求中途变更的情况会不会比GPT Agent更灵活，毕竟静态Prompt链一旦断了就特别容易跑偏。另外你提到延迟降低60%以上，这个在长上下文场景下确实很关键，不知道你测试的时候有没有遇到过它为了实时调整而过度拆分任务的情况？
7B模型光fp16权重就要14G，两张3090单卡24G看着够，但LoRA训练时激活值、梯度和优化器状态才是大头，batch size=4在7B上确实太激进了，尤其序列长度一上来，激活值能吃掉好几G。你试试把batch size降到1，然后开gradient accumulation，凑到等效batch size 4，显存立刻能降下来。bitsandbytes 4bit加载模型确实能省权重内存，但
说实话你这种情况我建议直接PyTorch，现在转ONNX再走TensorRT或者NCNN的链路特别成熟，社区资料也好找。Keras虽然上手快但真到部署那步反而容易卡壳，当年我踩过坑。另外可以看看你们嵌入式平台有没有现成的加速库，比如瑞萨或者树莓派上很多都优先支持PyTorch导出的模型。反正先拿个小模型跑通全流程再定，别光看benchmark。
我之前也踩过这个坑，而且比你更惨，折腾了三天才反应过来。最可能的问题不是防火墙或者端口，而是你那个文件搜索工具里用了同步阻塞操作，MCP的stdio传输对事件循环特别敏感，一旦有耗时调用卡住心跳，Cursor那边就会判定transport closed。我当时是把工具函数改成了async，然后所有文件读取都扔给asyncio.to_thread去跑，就没再断过。另外检查一下你的SDK版本，老版本对
LangGraph确实能解决这个，把状态机抽出来，工具实例放外面注入就行，并发用async没毛病。 可以试试把工具和prompt做成单例，AgentExecutor每次新建但复用这些依赖，token用缓存刷新机制。
我之前也踩过这个坑，光调阈值真不行，漏召回比噪声更头疼。后来直接加了个bge-reranker，对top20重排一下，效果立竿见影，比换chunk省事多了。另外你可以试试把chunk调大点比如512，然后让LLM只基于“直接引用片段”回答，我这边这么改之后，输出稳了不少。