长期关注运营思考录

我前阵子也踩过这个坑，跑偏多半是工具描述写得太模糊，LLM分不清啥时候该用哪个。你可以把每个工具的名称和描述改得更具体点，比如计算器就写“只做数学运算，不查资料”，能少很多乱调。中断的话建议开verbose看下中间步骤，大概率是输出格式没按ReAct的模板来，或者max_iterations设太小了。

循环调用工具这问题我也遇到过，不完全是模型本身的锅。我后来在prompt里加了显式的“已完成判断”步骤，要求模型每次工具返回后先输出一行思考，说明结果是否已经能回答用户，再决定下一步，这个改动效果挺明显的。工具schema也建议写清楚每个工具的输出结构，模型对返回值的理解会好很多。另外LangGraph的循环控制可以加个最大迭代次数兜底，不然容易卡死。MCP协议主要解决工具接入标准化的问题，跟循环

我都是把关键约束用编号列出来，两家都认，省得来回改。

loss卡在1.8确实有点怪，但先别急着怀疑学习率，1e-4到3e-4这个区间对LoRA来说不算离谱，震荡一般表现为loss跳来跳去而不是稳在某个值下不去。我比较怀疑你的数据格式和标签构造，代码补全任务里如果prompt和completion的切分没处理好，模型学到的可能就是一堆无意义的模式，loss自然降不下去。另外你跑了十几个epoch，7B模型加5万条数据，过拟合风险其实挺大的，验证集效果差

这个坑我踩过，说下我的做法。企业微信的OAuth2.0拿到的是用户code换userid，而MCP那套认证确实偏简单，基本就是个静态token或者简单的client credentials，两边对不上是正常的。我当时的方案是中间层不做全量映射，而是用userid换一个短期JWT，MCP server那边只校验JWT签名和过期时间，不查库，这样性能压力小很多。几十个人并发真不算啥，瓶颈一般不在映射逻

你缺的是共享状态层，让每个Agent读写同一个黑板再干活，就不会各搜各的了。

微调时把检索文档拼进训练样本，让模型学会“抄”而不是“编”，比冻层更管用。

全量微调7B至少得上ZeRO-2加梯度检查点，不然80G真扛不住，DeepSpeed省心点。

4090跑7B 4bit按理说确实不该OOM，问题大概率出在gpu-memory-utilization上，默认0.9会把显存吃到很满，KV cache预留不够就容易炸。试着把它压到0.8左右，同时用`--max-num-seqs`限制并发，别让请求一多就把cache撑爆。vLLM对GPTQ支持其实还行，但AWQ在vLLM上更稳，可以换着试试。至于llama.cpp，单请求延迟低但吞吐差，真要做补

通用性和专用性真别硬融，先把一个仓储场景做到99%成功率再谈泛化吧。

bge-large-zh配Qwen2-7B其实挺常见的，漏细节多半不在模型搭配上，而是检索回来的chunk本身就不完整。我之前也踩过，512切得太碎，一个答案被拆到两三个块里，模型只能看到片段自然就漏了。后来改成先按语义段落切、再加一层rerank，效果稳了不少。你可以先看看召回的top3里到底有没有那条关键信息，有的话就是生成端问题，没有就是切分和检索的锅。

这问题太常见了，基本是模型对参数名不敏感导致的，光靠description和schema确实不够稳。你可以试试在tool里加个参数校验层，模型传错了直接抛错让它重试，比只靠prompt约束靠谱。另外换个function calling能力强的模型会好很多，gpt-4o或者claude这块明显比小模型听话。还有个偏方是把参数名写进tool名字里，比如get_weather_by_city，模型看到名

财报表格确实难搞，我后来是用unstructured加上专门的table transformer模型先做表格识别，再转成Markdown，比直接解析靠谱不少。切块的话千万别按字符切，我是把整张表当成一个chunk，表头拼进每行数值里再嵌入，检索命中率高很多。另外你可以试试LlamaParse，对复杂表格处理挺香的，就是贵了点。

合同和技术手册这种结构化文档，光调chunk_size确实治标不治本，条款被切碎了语义就散了。建议先按标题层级或条款编号做语义切分，让每个chunk自包含一个完整条款。bge-small对中文长文本本来就偏弱，但换模型前先用reranker兜一下，成本低见效快，bge-reranker-base就够了。另外召回时把条款号、金额这类关键词也做混合检索，别只靠向量。

这个问题我也踩过坑，确实挺烦的。我的经验是别指望单靠检索策略解决，因为“总结全文”和“精确问答”对上下文的需求本来就是矛盾的。我后来的做法是在MCP tool里加一个参数，让模型自己决定是拿原文块还是拿预生成的摘要块，摘要块用离线跑好的，几百token就能覆盖一大段内容。另外分段返回这个思路可行，但要注意MCP的tool返回最好一次性给完，分多次调用容易让模型丢失中间状态，反而更乱。我现在的折中是

我们线上也是A10跑7B，后来直接上了两张卡张量并行，比量化折腾省心多了，延迟也稳。AWQ确实会掉点速度，尤其batch小的时候，GPTQ稍微好点但也没质变。如果预算允许，双卡TP是最稳的，量化更适合显存实在卡死又不想加卡的场景。

Gensmo我也试了下，确实在材质和版型上容易翻车，感觉它更多是在做“看起来像”的搭配，而不是真懂衣服。你说的动态学习审美这点挺关键，现在很多推荐还是靠标签堆出来的，用户稍微换个风格就懵了。我比较好奇的是，如果加入天气和场合这些上下文，它的推理延迟会不会变得很难接受？毕竟时尚Agent如果每次都要等好几秒，实际用起来基本就劝退了。

我后来把指令改成“只依据下面资料回答，资料里没提到的就别补充，直接说无法确定”，效果明显稳了不少。另外检索top3有时候噪声太大，建议加个重排序或者相似度阈值过滤，不然模型容易被无关片段带偏。还有个技巧是把资料编号，让模型回答时带上引用来源，能逼着它盯着原文。

这个问题我也踩过坑，Cursor默认确实不太会主动读你本地的依赖状态。我的做法是在项目根目录放一个`.cursorrules`，把Python版本和pip freeze的结果贴进去，再写一句“生成依赖前必须先参考此列表”，效果比在对话里反复强调稳很多。另外你可以让它先跑`pip freeze > requirements.txt`再改代码，虽然它不一定每次都执行，但配合规则文件基本能压住乱写版本的

入门的话我觉得能稳定写出让模型按格式输出、知道few-shot怎么摆、能判断啥时候该换模型而不是死磕prompt，基本就算过了。进阶其实不是堆技巧，而是搭评测，你得有办法量化改了prompt之后到底变好还是变差，不然全靠感觉调就是玄学。再往上就是往系统上走，比如RAG、工具调用、多步编排这些，prompt只是其中一环。我踩过最大的坑就是早期太迷信提示词模板，后来发现数据质量和任务拆解才是决定效果的