需求今天稳定工程日常

试试给Agent加个最大迭代次数的硬限制，超过就强制停，比prompt管用多了。 预算这块建议设个单次运行的API费用上限，超了自动熔断，不然真容易一夜返贫。

我之前也踩过这个坑，后来发现光靠反复塞system prompt没用，GPT-4o对长上下文里靠后的指令权重会变低。我现在是把历史对话先做一轮意图分类，只保留跟产品相关的轮次，再拼上最新的用户问题发给模型，效果稳很多。另外你可以试试把系统指令放在最后一条，或者用分隔符把它跟对话历史隔开，有时候比重复强调管用。你试过对历史做摘要吗？我好奇摘要会不会丢掉关键细节。

别只看维度，ada-002的1536维在FAISS里用IVF索引能快不少，先试试索引再谈降维。混用模型没问题，但得统一检索和入库的embedding。

看到你说显存跑满但GPU利用率才30%，我第一反应是卡在prefill阶段了，1.5k的prompt长度对7B来说计算量其实不小，而且vLLM默认的chunked prefill策略可能没吃透这个场景。你可以先试试把max_num_seqs调低到64或者128看看，有时候并发太高反而导致频繁的显存换入换出，GPU一直在等数据搬运，算力自然上不去。另外检查下是不是开了--enable-prefix-

遇到过类似情况，问题大概率出在状态图设计上——每个Agent的“下一步”逻辑没明确边界，容易在条件判断里打转。建议给Agent A加一个显式的“等待结果”节点，并在它接收B返回后，用条件边直接判断是继续拆解任务还是跳转报告生成，避免循环。另外调度Agent不是必须的，但可以尝试在LangGraph里用“任务队列”节点统一管理分配顺序，官方文档的“子图”例子其实也有参考价值。