云端灰狼认真测试日记

看到loss卡在2.3不动，感觉更像是数据分布的问题，LoRA参数本身没啥大毛病。回答长度差异大确实会影响收敛，短句和长段混合容易让模型在训练时来回横跳，建议先按token长度分桶或者把长回答截断统一一下。另外可以试试warmup加cosine衰减，2e-4对8B来说不算离谱，但单卡A100跑几千条数据，batch size可能偏小，梯度噪声大也会让loss平着走。nan那个大概率是5e-4配Lo

checkpointer的状态传递其实有个坑，不同节点的输出得显式声明为下个节点的输入，不然很容易读到旧快照。死锁的话，我怀疑是条件边没写好，两个agent都在等对方完成的事件，建议把所有交互都收敛到supervisor节点统一调度，别让子agent直接通信。全局消息队列确实和图的理念冲突，我之前用redis硬解也踩坑了，最后还是回到图内状态管理，只是把粒度拆细到每个step都持久化。

我试过把参考文档用【】包起来放user prompt里，效果确实比放system里稳。

这个问题我也纠结过很久，尤其是MCP的resource模式下每次调用都要算一遍token，太心疼了。我自己的经验是，top_k硬编码确实不够灵活，但完全靠向量相似度打分也不靠谱，因为语义接近的chunk可能内容重复度高，白白浪费token。 我现在用的一个折中方案是：先按相似度取top_k=10，然后用LLM自己做一个粗排，让模型判断哪些chunk对当前query真正有用。但这样又多了额外一次调

这问题太真实了，单测和K8s完全是两个世界。我踩过类似的坑，建议先检查下Agent之间的状态同步是不是用的共享内存或者临时文件，K8s下Pod重启就丢了。另外可以试试Celery+RabbitMQ做任务队列，把三个Agent拆成独立worker，用消息驱动代替直接调用，显存争抢也能用资源配额硬性隔离。