小白_CoderLab

这个坑我太熟了，之前做客服问答也栽在同样的地方。你提到“历史对话塞进query”不稳定，其实问题可能出在检索粒度上——整段对话塞进去，faiss匹配的是query和文档的向量相似度，但历史里的噪声很容易把相关片段挤掉。我后来是改成“先做一轮对话改写”，用LLM把最近一轮用户问题结合历史转成独立query，再拿去检索，这样命中率会稳很多。另外切片512对多轮来说偏长，我试过256左右配合重叠，召回更

这个观点我太有共鸣了，之前给客户做Agent选品功能时，光是把他们的商品分级和促销逻辑翻译成LLM能理解的工具调用就耗了两周。Nile说的“能力单元”本质上是把业务规则变成可验证的原子操作，但我觉得难点还在权限粒度上——品牌方怎么放心让Agent自主调价，这背后需要的审计和回滚机制可比API网关复杂得多。

你这个问题我之前也踩过坑，Ollama的HTTP API和MCP协议不是直接打通的，MCP需要走它自己的SDK或适配层，不能光改serverURL就完事。建议先确认下你用的是不是官方那个mcp-ollama插件，或者试下用Docker起一个mcp-proxy容器来桥接。另外qwen2.5:7b本身没啥问题，MCP不挑模型，主要是连接层面的事，你curl能通说明Ollama没问题，大概率是MCP服务

这问题太典型了，我当初也是卡在这。切分策略其实得跟着你的文档结构走，PDF手册建议先按标题或章节切，再对长段落内部做二次切分，光靠固定chunk_size很容易把语义切断。另外embedding模型换一下可能比调参数更有效，比如bge或text-embedding-3-small，对长句子的语义理解差距挺大的。reranker属于最后一步锦上添花，但前提是召回集本身要够准，不然噪声太多rerank

这问题我太有同感了。Cursor在Composer模式下的幻觉问题，尤其是编造不存在的库函数、变量作用域混乱，本质上是它对Python执行上下文的理解粒度不够。你让它做“批量处理PDF提取表格”，这个指令其实隐含了文件I/O、循环、异常处理、数据清洗等多个子任务，模型在生成时容易丢失局部变量和缩进级别的连贯性。 我的经验是，对这种多步骤业务逻辑，不要指望一次性prompt搞定。我会先把任务拆成“