持续研究品牌随身笔记

试试把对话历史先做一轮意图压缩再拼接，能少很多噪音，或者直接看下MemGPT那套分层思路。

torch.compile对动态shape的支持其实比JIT好不少，它有专门的dynamic shape模式，但默认开启的话编译开销会摊薄到每次输入变化上，你可以试试把mode设成max-autotune或者限一下动态维度。自定义注意力掩码只要不是纯Python控制流，一般都能被graph break处理，顶多回退到eager，不会报错但加速效果会打折。我建议你先用torch.compile的pr

Qdrant上手快但集群扩容时坑不少，Milvus功能全可运维成本高，小团队慎选。 Milvus坑在依赖太多，部署起来头大；Qdrant单机性能不错，但中文文档少得可怜。

max_iterations设小点，输出格式锚死，再加个中间结果校验，跑偏概率能降不少。

说实话我觉得你现在的瓶颈大概率不在向量库本身，而是embedding和检索策略的问题。ChromaDB在几千篇文档的规模下性能不会差到哪去，准确率飘更多是分块方式或者向量模型对长文档语义捕捉不够。你可以先试试换更强的embedding模型，比如bge-m3或者e5-large，再配合混合检索（关键词+向量），说不定成本最低的提升就来了。 真要换库的话，Milvus单机版在Mac上跑起来其实没想象

混合召回对rerank延迟影响挺大的，建议先拿bge做主力，text2vec当候选补充，实测多路召回得加缓存。 单卡T4跑bge-large其实能接受，把分块调小点，速度能上来，召回率也比text2vec稳。

说实话我之前也卡在“AI只建议不执行”这个点上，后来发现MCP更像是个“读权限”的增强，真要让Cursor跑命令还得靠它内置的终端工具或者自定义agent，不是靠MCP本身。你连不上本地Node服务大概率是环境变量或者权限问题，试试把server跑成后台进程再让MCP走http协议，别用stdio模式，能省不少麻烦。至于自动修TS报错，我现在的做法是让AI先改代码，然后我手动触发一次tsc检查，完

我最近也踩过这个坑，光靠LLM打分做路由确实容易来回踢，后来直接加了全局max_rounds兜底，但更关键的是让每个Agent在内部判断时带上“置信度阈值”，低于阈值就强制返回一个明确失败信号，而不是继续传递。另外你可以试试给每个Agent配一个固定的“职责边界”说明，让LLM在回答前先自我检查是否超出边界，这样比事后判断终止要干净得多。你现在的工具函数是每个Agent独立调用的，还是共享的？我怀

试试把文档按章节拆开分段喂，每段强制输出“数字+上下文”，最后再汇总，漏数据的情况会好很多。

其实你可以试试在项目根目录放一个`.cursorrules`文件，把你们现有的组件写法、禁用泛型或者Hook的规则直接写进去，比每次prompt管用得多。另外我猜它“想当然”是因为训练数据里好代码都长那样，你可以给它一两个你们项目最典型的组件当few-shot示例，它模仿能力比听指令强。不过说实话，对老代码库的适配确实弱，我这边最后是直接让它只改我圈出来的代码块，别让它碰整个文件。 --- 我

固定字符切分对你这场景确实容易翻车，bge-large-zh-v1.5本身对短文本和长文本的表征差异挺大的，512字符塞进去，语义重心容易被长段落里的无关信息带偏。我建议你先按Markdown标题或者文档结构切块，把每个小节当独立单元，这样至少保证每个块有完整主题，再对超长的块做递归切分，但切之前最好先看下Embedding的相似度分布，别盲目套参数。另外问“如何修改密码”召回“密码复杂度要求”，

我是直接写单元测试当prompt，AI改完必须过测试，没过就让它接着修，效果还行。

同感，这问题太真实了。我试过把prompt拆成“角色+背景+任务+约束+示例”五段式，虽然不算万能但至少能减少随机性。你可以看看OpenAI的官方指南里关于“分隔符”和“思维链”的用法，对结构化很有帮助。另外长上下文建议用“分块+总结”策略，一次性塞太多逻辑容易跑偏。

说实话看到你这个loss曲线我第一反应是学习率可能给高了，LoRA微调本身参数敏感，2e-4对Llama3来说容易震荡，尤其你batch size才4，梯度估计噪声比较大。我之前试过类似场景，降到1e-4甚至5e-5之后loss才慢慢往下走，你可以在前几百步先跑个warmup看看曲线形态。另外数据集这块，客服问答对如果只是纯文本拼接，没有用chat template或者特殊分隔符，模型可能根本分不

大概率是微调把embedding分布拉偏了，试试冻结embedding层或者用两阶段训练。

这问题太真实了，我也踩过一样的坑。后来发现“明确指令”的关键不是把需求写成伪代码，而是要让AI知道“哪些事你别擅自做”——比如在prompt里直接加一句“不需要处理异常值，除非数据格式错误”。另外把任务拆成小步骤确实管用，但别拆成逻辑块，拆成“先做A，再做B”这种自然语言步骤就行，AI反而更容易对齐你的脑回路。

这个问题我也踩过坑，光靠system prompt硬塞历史摘要确实不靠谱。我现在的做法是在LangChain里单独挂一个向量数据库，每周把周报的关键进度存成embedding，每次写新周报时先检索相关记录，让Agent参考后再生成。这样不用手动更新，内容也能连贯起来，不过得注意控制检索到的片段长度，不然上下文一涨还是容易跑偏。

试试用缓存池管理AgentExecutor实例，按用户ID做隔离，应该能解决状态冲突。

这种情况我也遇到过，感觉核心问题可能不在召回，而是大模型对上下文里具体数值的“注意力”不够敏感。可以试试把检索出的文档关键信息（比如保修期数字）单独提取出来放到system prompt最前面，或者用符号标记一下。另外，你用的开源embedding模型和GPT-4o之间的embedding分布可能不匹配，导致模型对召回内容的“信任度”不够，加个简单rerank步骤（比如用GPT-4o自己对召回文档

简单项目就别惯着AI，直接让它改回useState+useEffect，干净好维护才是王道。