业余运维人

几百万条这个量级其实两个都能扛，但你用1536维的话得重点看下内存占用和索引构建速度。我当初在Milvus上折腾过好久，集群部署那块确实有点心累，后来换Qdrant主要是图它Rust写的单机性能好，API也清爽。不过你要是以后想上亿数据，Milvus的分布式能力还是更靠谱些，就看你愿不愿意为运维成本买单了。另外建议先拿真实数据跑个benchmark，别光看文档吹的指标。

看到这个标题我就知道是同道中人了，Llama 3.1本地跑Agent我也踩过一模一样的坑。ConversationBufferMemory那玩意儿确实就是个暴力拼接，token爆了之后模型直接摆烂，我后来干脆自己写了个基于滑动窗口加关键信息摘要的混合方案，效果比单纯塞历史强不少。 你提到的向量检索不稳定，我怀疑问题出在切分粒度上，别整段存，试着把每轮对话拆成“用户意图+系统动作+核心实体”这种结

开源模型指令遵循确实弱一截，结构化任务建议先试few-shot加JSON模式，采样温度调低点会稳很多。

说实话这问题我太熟了，之前用LangGraph也翻过车。核心还是别全信LLM的free-form路由，建议把任务类型先限定成枚举值，让模型做选择题而不是填空题。另外状态管理可以试试GraphState里加个任务队列字段，每个节点执行前先检查下当前任务归属，能减少不少抢活和重复执行的情况。至于框架，短期还是自己写状态机最稳，等稳定了再考虑抽象。

我也碰到过这情况，写Go的时候它确实容易在import上放飞自我，尤其是内部包路径，感觉就是训练语料里Go的占比不够。你可以试试把项目里常用的几个真实包路径写进Rules里当白名单，比单纯写“别瞎编”管用。另外context这块我倒觉得它更像是在模仿别的语言的错误处理套路，可能跟补全时的上下文长度有关，试试把相关函数完整贴进去再让它改。

这问题八成是field类型定义跟存储时类型没对齐，Chroma那边metadata值必须是字符串，数字得先转成string再存。

说实话这问题我太有同感了，尤其变量命名那块，它老爱搞些`data`、`item`、`temp`之类的，看着能用但进code review真得改半天。后来我试了下把团队eslint规则和几个核心组件的写法直接丢到项目根目录的AGENTS.md里，再让它参考这个文件，效果比在对话里说“学我风格”好得多。但你要说设计模式，我反正不指望它，这玩意儿本质就是个超级自动补全，能帮我把重复劳动干掉就不错了，复杂

我最近也在折腾这个，试了一圈下来感觉chunk size真不是单靠调数字就能解决的。你提到动态切分，其实langchain里有个RecursiveCharacterTextSplitter可以按分隔符优先级来切，比如先按标题、再按段落、最后按句子，这样至少能保证语义完整性。overlap的话我一般设10%-15%，主要是为了覆盖跨chunk的上下文，但设太大反而会让embedding重复度高，检索

我之前也踩过类似的坑，后来发现单纯靠Prompt约束不太够。可以试试把上一步关键结果直接以结构化文本（比如JSON或简短摘要）塞进下一步的Prompt里，相当于显式传递上下文。ReAct框架确实能通过循环推理和工具调用来缓解这个问题，但如果你不想引入复杂框架，手动设计一个“中间结果记忆库”也能凑合，就是维护成本高点。另外检查下模型本身的长上下文能力，有些模型在中间步骤容易“失忆”。