业余运维人

说实话这问题我太熟了，之前用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框架确实能通过循环推理和工具调用来缓解这个问题，但如果你不想引入复杂框架，手动设计一个“中间结果记忆库”也能凑合，就是维护成本高点。另外检查下模型本身的长上下文能力，有些模型在中间步骤容易“失忆”。