认真做产品实践笔记

老项目隐式依赖多确实容易这样，试试把改动范围写成明确指令，比如“只改这个函数，别动其它”。

说实话我也踩过类似的坑，最后发现问题不一定在embedding，而是chunk切分太机械了。你试过按文档结构（标题、段落、表格）做语义切分吗？几千篇PDF里，静态路由和OSPF很可能在同一章出现，混着切肯定乱。另外可以加一层rerank，用cross-encoder把前20个候选重新排一下，比单纯调向量模型见效快。

试试看把检索改成混合召回吧，bm25加向量一起上，光调embedding真不如换个召回策略来得快。 召回前先做个query改写试试，把“静态路由”这种词扩展成配置命令，干扰项应该能少不少。

我之前也踩过这个坑，全塞历史记录真不行，信息一多模型自己都懵了。后来我改成每步只传结构化摘要，比如用户ID这种关键字段单独拎出来放prompt顶部，效果比堆原文好多了。你试试用LangChain的Memory模块配合向量检索，但别存原始对话，存提炼后的状态快照，这样既省token又不容易跑偏。另外给模型一个“当前目标”的强提示也管用，比如在每轮开头重复一遍最终任务，能拉回不少注意力。

说实话我最近也踩过这个坑，一开始参考那些所谓最佳实践把prompt写得跟论文似的，结果模型反而开始“表演”，动不动就编个答案出来。后来我把system prompt砍到只剩一句“用提供的资料回答问题，资料不足就说不知道”，效果立马正常了。我怀疑LangChain默认的prompt模板其实就够用，加太多花活反而干扰了模型对检索片段的注意力。另外few-shot这块，我觉得除非你的场景特别特殊，否则几

这问题我也踩过坑，核心是LangGraph的state里工具返回值没做隔离。我后来是把每个工具的调用结果单独存一个key，比如weather_result和meeting_result，最后再让Agent统一从这些key里取数据，基本就解决了。另外你可以在工具调用前加一步意图拆分的节点，强制先识别出用户要几个动作，再分别执行。你的会议室地址被当成天气参数，大概率是工具描述写得不够具体，试试在too

说实话这俩在Agent推理场景下真没差那么多，PyTorch写起来还更顺手，毕竟ReAct的循环逻辑和工具调用都是Python层面的东西，模型推理只是其中一环。那些框架用TF Serving或ONNX更多是为了服务化部署和性能优化，跟Agent本身的设计关系不大。我自己用PyTorch搭过类似的东西，只要把模型推理封装成异步接口，配合FastAPI或者gRPC，效果完全够用。如果你后续要上生产、搞

说实话resource这玩意儿我也试过，最大的坑就是模型根本不知道啥时候该去读，除非你在system prompt里写死触发条件，不然它大概率当你不存在。后来我干脆把关键规范直接塞进system prompt里，虽然占token但至少稳定触发，resource只放那种超长又非必需的参考文档。 另外我觉得MCP的resource更适合给外部工具做数据源，像这种指导模型行为的上下文，还是得靠prom

温度调低到0.2能减少脑补，但死板问题得靠提示词里加“可推理但需标注依据”来平衡。 JSON模式对结构化输出帮助大，但别指望它解决内容稳定性，模板还得按chunk质量动态切换。

显存这块其实挺正常的，vLLM默认会给每个request预留不少KV cache池，而且7B模型即便int8也还有中间激活值和显存碎片，22G不算离谱。你这个tensor-parallel-size=2没生效，大概率是两张卡没走NVLink或者驱动没识别成同一拓扑，看看nvidia-smi topo有没有报错。速度20 tokens/s大概率是被KV cache占满后触发了swap，建议把--ma

试试先按时间窗口粗筛再精排，几百条后相似度聚集太正常了，top-k直接用容易翻车。 同感，建议加个对话轮次权重或者按主题聚类去重，光换模型解决不了信息冗余问题。

MCP确实能执行命令，但得配对server，我折腾一周才让Agent跑通eslint，不过修完得自己review。

把Hook文件单独锁起来，或者用@提示词明确告诉它“只改组件，别动Hook”，我试过挺管用的。 我都是把已完成的代码写进AGENTS.md里声明禁止修改，AI基本就遵守了，你可以试试。

说实话你这个场景我踩过一模一样的坑，并联Agent别指望LangGraph帮你自动处理时序，状态共享的本质是数据依赖而不是流程并行。我最后是每个Agent维护独立state，然后用一个显式的协调节点做合并校验，比全局共享内存好排查多了。Send API适合数据并行，但你这个是前后依赖，手动控制流程反而更稳，interrupt只在真需要人审时用。另外建议给每个Agent输出加个版本号，状态乱的时候直

单卡T4跑bge-large确实有点吃力，我当初试过把max_length砍到512，batch调小，推理能快个20%左右，但检索效果还是比text2vec稳。多路召回我们试过，延迟主要看rerank模型，如果直接用bge-reranker-large，T4上基本扛不住，得换小模型或者干脆走API。建议你先量化bge-large试试，int8精度损失不大，速度能提不少，另外文档分块别用固定512，

大概率就是本地模型推理太慢卡住了MCP的默认超时，Qwen2.5-7B在CPU或小显存上生成JSON有时要好几秒，而stdio的timeout一般就10秒左右。你可以试试把MCP配置里的timeout调大到60秒，或者检查下是不是server端用了同步sqlite查询，那玩意儿在事件循环里跑确实会堵。我之前用Ollama接MCP也踩过这坑，最后是改成异步加超时重试才稳的。你日志里能看出server

固定500字确实太粗暴了，我之前也踩过这个坑。后来改成按段落和标题先切，再对太长的段落二次分割，效果比单纯数token好很多。query口语化的问题，我试过在检索前加一步轻量的改写，比如把省略的主语补全，或者扩展成几个同义问法，能明显提升召回准确率。表格和代码块建议单独存，检索时跟文本分开召回，不然很容易把不相关的片段混进来。

建议先按文档标题和章节结构切，再用500左右+10%重叠兜底，实测比纯固定值稳很多。

我最近也碰到过类似问题，尤其是工具一多，模型自己就“嗨”了。后来我干脆把每个工具的调用结果都写进memory里，并且在prompt里明确告诉它“上一步结果已经存好，直接引用”。这样至少能减少重复调用。另外，你也可以试试在function calling里加个简单的step字段，强制它按步骤走，比纯靠prompt稳定些。状态机我觉得有点重，除非你的流程特别固定，否则还不如让模型自己规划再校验。

这问题太真实了，我最近也被Claude坑过一回，明明让它用matplotlib画个简单折线图，它非给我整成plotly交互式的，说方便看数据。后来我学乖了，在prompt开头直接加一句“只允许修改bug和补全代码，禁止改变实现方式和依赖库”，然后把它给的polars代码块原样丢回去说“请基于这段代码改”，这样它倒是会收敛不少。不过说实话，它那个“自作主张”的毛病有时候真不是prompt能完全压住的