一线低代码手记

确实会有开销，我之前也配了七八个server，后来发现每个server的tool description都会塞进context，光这些就吃掉不少token，响应慢是正常的。我的做法是按项目拆.claude.json，平时只留filesystem和git这种高频的，playwright、sqlite这些用到再临时开。另外可以定期用/mcp命令看下哪些server实际没怎么调用，砍掉就清爽多了。

我一般让主Agent只留最近两轮原文，再挂个专门管记忆的子Agent做摘要和检索，效果还行。

我也碰到过，后来在模板里把参数用双引号包起来，再让客户端做一层类型校验才稳。Claude对嵌套JSON确实容易懵。

两万多份PDF还是LlamaIndex吧，检索抽象干净，后期换向量库也不折腾。混着用没必要，维护两套反而更累。

7B模型推理本来就慢，先调大超时时间试试，还不行就是传输层配置的问题了。

工具描述这块确实是个坑，我之前也踩过。LangChain里工具名和描述如果太像，比如“查天气”和“搜索天气”，模型就容易选错，尤其三个以上工具的时候。你试过把每个工具的docstring写得特别具体吗？比如明确写“输入必须是城市名+日期，格式如北京2024-01-01”，有时候比在system prompt里绕来绕去管用。另外参数传乱不一定是prompt问题，可能是工具本身的schema没定义清楚

试试换成text2vec-large-chinese，中文语义区分度比BGE好不少，召回准多了。

几百个PDF场景不复杂，我会直接上LlamaIndex，省得跟LangChain的抽象层打架。

我之前也踩过这个坑，后来发现关键不是加“思维链”，而是把你数据长什么样直接贴给它看，列名、几行样例、空值长啥样都喂进去。另外别让它一口气写完整脚本，先让它只写“识别异常值”那一步，跑通了再往下加。角色设定有点用但被吹过头了，真正管用的是把任务拆到它没法自由发挥的程度。

TP=2没生效大概率是没加--enable-tensor-parallel或者两张卡之间没走P2P，可以看下启动日志里有没有tp相关的信息。gpu-memory-utilization=0.9本来就是预分配90%显存给KV cache，你把它当实际占用看就误会了，调成0.7试试能降不少。20 tokens/s确实偏慢，先确认下是不是只跑在单卡上，双卡PP通信没配好反而更慢。长上下文这块SGLang

我最近也踩过这个坑，后来发现光调 chunk size 意义不大，关键得看文档结构。技术手册和 PDF 报告里表格、代码块多，硬按 token 切经常把一段完整逻辑劈开，检索时自然就飘了。我现在基本是先用正则按标题层级切，再对超长段落做二次拆分，overlap 只留 10% 左右。评估的话可以搞一批问答对，看召回片段里有没有正确答案，比凭感觉靠谱。

我之前也踩过这个坑，ReAct的prompt里如果没有明确告诉它“拿到Final Answer就停”，模型很容易把中间结果当新输入继续折腾。你可以试试在系统提示里加一句“一旦能回答用户问题，必须直接输出Final Answer，不要额外调用工具”，效果挺明显的。另外LangGraph里可以自己写个条件边，检测到输出里包含“Final Answer”就路由到END，别光靠max_iterations

十几个人同时用14B模型，单卡A100确实会有点吃紧，特别是你们还带历史上下文，KV Cache涨得飞快，OOM不奇怪。我之前跑类似场景的时候发现，vLLM的max_num_seqs调太低吞吐上不去，调高了显存又扛不住，挺尴尬的。如果预算允许，两张卡做张量并行是最稳的，14B在双卡上跑int8基本能撑住十几路并发，而且延迟也好看不少。量化到AWQ确实能省显存，但Qwen2.5系列AWQ的精度损失在

我也遇到过类似情况，后来发现光改Prompt治标不治本。检索回来的chunk如果本身就带噪音，模型再听话也会被带偏。可以试试在召回后加一层轻量级rerank，比如用cross-encoder或者Cohere的rerank接口，把最相关的三五个片段筛出来再拼进Prompt。另外压缩这块我试过用LLM先对每个chunk做摘要再喂给生成模型，效果比直接塞原文稳不少，就是延迟会上去一点。

这个问题我踩过一模一样的坑，7B级别的模型在工具调用上确实容易飘。你提到的“跳过工具直接编答案”，本质上是模型没被明确训练过“什么时候该调用工具”这件事，光靠prompt约束很难根治。Qwen2.5确实有专门的function calling版本，换上去之后成功率会明显提升，但也不是万能药，参数格式还是偶尔会错。我的经验是别让模型自由发挥生成参数，用结构化输出约束它，比如json schema或者

MCP Server跑记忆这块我踩过坑，Chroma单机小规模确实舒服，但并发一上来写入锁的问题挺明显，尤其多客户端同时写历史的时候容易卡。后来换成Milvus Lite（嵌入式那版），部署负担比完整版小很多，稳定性和性能也够用。如果只是单机MCP场景，其实sqlite-vec或者LanceDB也值得看看，轻量还省心。你现在大概是什么量级的对话数据？

我之前也踩过这个坑，后来把约束条件当成独立的状态字段来管，每次调模型前动态拼进system prompt里，而不是指望它从历史里自己记住。History该压缩压缩，但硬约束单独存一份，比如用户明确说的“只退款”“不接受换货”就写进一个slot里，每轮都带上。窗口记忆只负责承接闲聊上下文，别让它管规则类的东西，这样token也不会炸。

分词器确实是坑，原版LLaMA对中文基本是一个字一个token，模型学起来很吃力，夹杂英文多半就是这个原因。但我觉得更大的问题在你的数据上，一万条里如果大量是“好的呢亲”这种模板回复，模型很快就能学会靠复制高频句把loss刷下去，实际根本没理解上下文。学习率5e-4对LoRA来说偏高了，可以降到1e-4试试，另外建议先拿几百条多样化的数据做个过拟合实验，看看模型能不能正常回答，排掉数据质量的雷再上

我最近也在踩这个坑，感觉关键还是看你的知识库是“主流程依赖”还是“可选增强”。如果是问答场景，模型几乎每次都需要检索，那我会倾向在 MCP server 里先查好再注入 context，省得模型来回决策，延迟也更好控。但要是工具型 agent，检索只是众多能力之一，那封装成 tool 更合理，不然你等于替模型做了路由决策，反而丢了灵活性。我现在的做法是折中：tool 返回结构化的精简片段，带 sc

几万条数据用FAISS确实没啥毛病，几十毫秒的延迟在本地场景完全能接受，别为了架构而架构。但你提到的几个点里，真正在生产里最要命的是动态增删和元数据过滤，而不是索引速度本身。FAISS的IndexFlatIP暴力搜确实快，但它基本是个静态索引，你删一条数据就得重建或者搞ID映射那套，文档一更新就头疼。另外真实问答里经常要按来源、时间、权限做预过滤，FAISS原生不支持这个，你得自己在外层写逻辑，很