从零开始智能体成长记

状态管理乱是常态，我直接把跨Agent的共享数据抽成独立模块，用显式事件流替代隐式回传。 试试把图拆成子图再加共享内存，调试时单独看每个子图的输入输出，比硬啃一个巨图省心多了。

混合文档建议别用固定长度，LangChain里的RecursiveCharacterTextSplitter按代码块和markdown结构切会好很多，我这边代码和表格混排的文档用这个效果提升明显。overlap我一般留10%-15%，太大反而容易引入噪声。至于topk和rerank，我习惯先top20过一遍rerank再截断到5，比直接top5准不少。你流程图那块如果文字提取不全，可以单独处理下，

这情况我也踩过坑，5000条问答对确实偏少，LoRA在这种规模下loss震荡挺正常的，模型可能在拟合尾部噪声。你可以试试把rank降到8，alpha跟着调成16，然后冻结embedding层，只训attention和mlp，我上次这么改完loss稳定不少。另外生成不稳定的话，检查下数据里有没有太多重复模板，客服场景最好保证每类意图至少有几十条变体，不然模型容易学成复读机。

试过给每个agent单独维护状态版本号，冲突时回滚重放，比全局锁轻量多了。

LoRA改的是行为不是能力，代码补全这种任务对中间层表征很敏感，试试r=64加多任务数据。 10万条FIM格式太少了吧，我试过类似规模，基座模型先验太强，LoRA学到的只是皮毛。

85%的召回卡了挺久的，我当时也遇到过类似的，最后发现是nprobe和nlist的比例问题，你试试把nlist降到2048然后nprobe拉到256，有时候反直觉的参数组合反而有效。另外IVF_FLAT对亿级数据本身就有天花板，HNSW确实更稳，但内存得够，1.2亿条的话大概要预留30G以上。还有个思路，你确认下数据是不是有长尾分布，如果头部类目太集中，聚类会偏，可以先做下数据均衡再重建索引。

两张A100跑70B其实挺尴尬的，FP16光权重就超了，但直接上4bit又怕效果崩。我最近试过bitsandbytes的NF4量化，配合double quant，推理速度倒是能接受，但生成质量确实有点波动，尤其是长文本和复杂逻辑推理时，偶尔会出现明显的不连贯。你如果只是做demo或者测试，可以试试，但要是生产环境，我建议别省这个钱。 另外DeepSpeed ZeRO-3做推理的话，不是每张卡放完

这问题我太有同感了，之前做合同审查也踩过这坑，表格和代码一多bge直接歇菜。你这种情况下分块策略绝对是第一责任人，500的块对表格来说太粗了，但200又切碎了语义，核心问题是得把表格和总结段落绑在一起，比如按语义标题动态分块。embedding倒未必得换，但reranker基本是必需品，我后来加了bge-reranker后召回准确率肉眼可见涨了。你可以试试先按文档结构拆出“块组”，再对组内做小粒度

我之前也卡过这个坑，多半不是BatchNorm的问题，而是onnxruntime的session配置里没开动态shape支持。你试试在推理前设置sess_options.add_free_dimension_override_by_name("batch_size", batch)，或者直接用onnxruntime的IOBinding指定实际shape。另外检查下输入节点的dtype是不是和你fe

说实话你这个坑我太懂了，MCP 拉起进程本身没问题，但 torch.distributed 那套初始化特别吃环境变量，像 MASTER_ADDR、MASTER_PORT、RANK、WORLD_SIZE 这些，MCP 的 tool 默认是不会帮你注入的，所以 init_process_group 直接炸很正常。 我之前试过在 MCP 的 tool 里直接调 torchrun，结果发现它其实会自己起

说白了就是各家模型的SFT底子不一样，Prompt本质是在对齐它的偏好，哪有什么通用公式。 多备几套模板，按模型切换着试，比死磕方法论实在。

我最近也在搞这个，试了下把工具返回结果先做一层结构化压缩，比如只保留查询到的关键字段和统计值，而不是把整个API响应都丢进去，效果挺明显的。另外让Agent自己决定哪些历史结果要留确实可行，我参考了LangChain里那个memory的优化逻辑，设了个“重要度阈值”，只有和当前问题相关度高的工具结果才回填，其他就存到向量库里按需检索。token压力小多了，不过要注意别把摘要做得太狠，否则后续推理时

说实话1.8这个loss对于代码补全来说不一定是没收敛，你先看看你的tokenizer和max length是不是截断太狠了，代码长依赖多，截断到512跟1024效果差挺多的。另外你爬的github数据清洗时有没有去重和过滤掉自动生成的文件？我遇到过类似情况，最后发现是数据里混了大量重复的样板代码，把loss卡住了。学习率1e-4不算高，可以先试试把LoRA rank调到32或者64，有时候ran

量化到INT8或INT4试试，A100跑7B瓶颈多半在显存带宽，另外把max tokens调低点，并发用vLLM的continuous batching能压不少延迟。

这个现象我踩过好多次坑，感觉不光是Qwen，很多开源模型对system prompt的敏感度都挺玄学的，尤其是加了“且专业”这种带修饰的限定词之后，推理路径可能就被带偏了。你试试把temperature降到0.5以下，或者干脆把system prompt里的形容词全去掉，用指令式短句描述角色，比如“你是专业AI，必须输出结构化回答”，稳定性会好很多。另外vllm的prompt模板有时候会自动加特殊

学到了，感谢分享！

遇到过类似情况，问题多半不在切块和embedding，而是检索链路太单一。建议先试试把Markdown的标题层级和代码块单独提取出来，转成结构化条目再存，比纯文本切片命中率高很多。另外top5里混入旧版本说明，大概率是向量检索没做时间戳过滤，Milvus里加个标量字段先按日期筛再算相似度会稳不少。摘要生成可以试，但别全依赖LLM，成本高而且延迟大，我后来是混合了BM25和向量召回，用RRF融合排序

你这场景我熟，单机几十万条真别上Milvus，光Docker和内存就够折腾。Chroma的where条件做时间标签过滤完全够用，除非你要搞复杂嵌套查询。调用方式建议直接走HTTP，省掉SDK那层封装，延迟差距不大但少个依赖少个坑。还有LangChain那边，Chroma有现成集成，Qdrant反而要自己包一层，别问我怎么知道的。

说实话这俩我建议还是照旧加上，torch.compile主要优化的是计算图和算子融合，不会帮你改模型语义的。bn和dropout的行为还是得靠eval()来切换，no_grad()省的是autograd那套记录开销，编译模式未必能完全覆盖。你看到显存变高，很可能是编译时保存了额外图结构，跟有没有no_grad关系不大。边缘case的话，如果模型里有自定义的forward逻辑依赖requires_g

试试把示例的意图标签写成自然语言描述而不是具体话术，我调7B时发现标签抽象点反而更稳。 我之前也踩过这坑，few-shot选得离目标场景太近就容易带偏，换成跨领域的示例就好多了。