隔壁云原生玩家手记

说实话你这个痛点我太懂了，之前我们团队也踩过类似的坑。MCP那个context设计初衷就是给agent用的，讲究的是会话状态和工具调用链，跟训练管线里那种“固定shape、固定预处理逻辑”的静态上下文完全是两码事。我们最后没硬套MCP的context结构，而是把它当做一个“元数据注册中心”来用，就是让MCP管理每个task的配置版本、数据源路径、还有模型输入的schema描述，真正的tensor流

试试把输出格式直接写进system里，再给两个正反例，比在prompt里反复强调管用。

这问题太真实了，我当初也是卡在这。短期记忆和长期记忆硬拼在一起就是会打架，后来我把对话历史先做一轮意图压缩，提取出关键约束条件再跟query拼一起去检索，效果好了不少。另外GraphRAG确实值得一试，尤其适合这种需要跨场景推理的，但前期构建成本也不低。你现在是卡在召回不准还是重排那步？

跟你一模一样，我后来直接在项目根目录塞了个CLAUDE.md，开头就写“本项目优先复制现有文件结构，禁止新增类型、Hooks或工具函数，除非已有文件无法满足需求”，效果比rules好不少。PropTypes那个确实烦，可以在设置里搜一下disable PropTypes，或者干脆在rules里加一句“项目使用TypeScript，禁止添加PropTypes或任何运行时类型检查”。不过说实话，它有时

确实，静态标签这个痛点太真实了。我试的时候也发现它把我一件oversize西装认成正常版型，直接导致后续推荐全跑偏。感觉现在这类Agent最缺的不是模型能力，而是对“人穿衣服”这个动态过程的感知，审美偏好这东西本来就该是越用越懂你的。 另外提个场景化的小细节，它目前对通勤和约会这种场合的区分基本靠关键词硬猜，完全不看天气和地域。我大冬天穿呢子大衣出门，它居然推了件薄风衣，这要是能接入实时数据，哪

chunk_size不是越大越好，1024对7B模型来说上下文窗口压力大，检索反而容易把不相关的段落塞进来。我建议你试试按章节或者语义段落切，配合滑动窗口重叠个100-200字，召回率会稳很多。至于检索，纯向量在小样本上确实容易飘，可以加一层BM25混合召回，再用一个轻量rerank模型（比如bge-reranker-base）过滤，延迟也就多个几十毫秒，但准确率提升明显。Chroma慢的话，你可

大概率是检索的锅，top5里相关上下文不够或者混进噪音，prompt再调也救不回来。建议先查查召回质量，再考虑动态切模板试试。

试试把State里的大字段改成显式快照，每步结束用update_state强制刷新，别靠隐式传递。

我遇到过一模一样的情况，当时也是bge系列，固定切块，结果检索回来的全是“提到关键词但没实际内容”的段落。我觉得你这个问题大概率是chunk切法的问题，256字固定切太容易把完整语义拦腰截断了，尤其报销流程这种步骤性内容，经常是“准备材料”在上一块，“提交审核”在下一块，embedding算相似度的时候根本拼不出完整逻辑。我后来改成按markdown标题和段落边界切，再配合50字左右的重叠，召回质

给工具调用加上@retry装饰器，配合指数退避，能扛住大部分网络抖动，我这边实测效果不错。

这大概率不是工具不行，是Composer对上下文的理解太“发散”了。我遇到过类似情况，后来学乖了：让它改之前先把相关的store文件和组件代码单独圈进对话里，明确告诉它“只动这几十行，别碰别的”。另外你描述需求时最好具体到“在某个函数里加参数”，不然它真的会自作主张加log。Cursor适合做批量重构，但这种精准修改还是得靠你自己盯紧diff，别全信它。

我之前也碰到过几乎一模一样的情况，loss卡在0.9附近死活不动，后来发现问题是出在数据上，不是LoRA的秩。你那5000条QA对如果领域太集中，模型学完表层模式就没东西可挖了，loss自然就平了，试试把回答里重复的套话删掉，或者增加一些负样本和难例，效果可能会立竿见影。 另外2e-4的学习率配rank=8其实挺常规的，但Llama 3的embedding和lm_head默认不参与LoRA训练，

遇到过类似情况，7B模型对few-shot的依赖确实很敏感，示例选不好反而会带偏。建议你把示例里的具体话术改成更抽象的描述，比如只保留意图核心词，别让模型有机会去匹配字面。另外温度0.1可能太低了，会让模型过度聚焦于示例的局部模式，试试调到0.3-0.5。我后来直接改成只用系统提示词加两个极端反例，效果反而稳定了。

角色设定确实容易带偏，尤其是“资深主管”这种身份会让模型主动往“全面分析”上靠，反而丢了简洁性。我的经验是，角色越具体越容易触发它发挥，不如直接给一个“执行者”人设，或者干脆不设角色，只给明确的任务边界和格式约束。像你那种三句话的指令其实已经够清楚了，优先级肯定大于角色设定。另外可以试试在指令里加一句“不要推测未提及的信息”，能有效防止脑补。

代码类RAG真不能只看文本相似度，试试把调用关系和import依赖加权进召回，比rerank靠谱多了。

说实话你这情况太典型了，我一开始搞RAG也卡在这。chunk大小真不是固定的，得看你的文档类型和后续问答的粒度，比如技术文档可能512就够，但法律合同那种得1024起步，不然一个条款被切两半。另外我觉得你问题可能出在overlap上，试试chunk之间留个50-100的token重叠，能救回不少边界信息。 关于embedding模型，bge-small和text2vec-large在国内场景

这问题太典型了，代码类文档跟纯文本不一样，按固定字符切确实容易把参数和注释拆散。我建议你试试按函数或类做结构化切块，顺便把所在模块路径和包名作为元数据存进去，检索时用元数据过滤比prompt硬掰靠谱得多。版本这块，如果文档源里有版本号字段，可以在索引时给每个块打上版本标签，检索前用filter指定只查最新版，或者至少把版本信息拼进context里让模型自己判断。另外你提到的父文档召回，对解决缺上下

这个痛点太真实了，验证集loss低真不代表生成格式稳。我之前也踩过类似坑，后来发现光靠LoRA硬掰格式确实不牢靠，模型注意力稍微偏移就放飞自我了。工程上比较实用的兜底是写个轻量级正则解析器，把换行空格全吞掉，再对工具名做模糊匹配，至少能把失败率降下来。另外你可以试试在数据里故意混入一些“错误格式”作为负样本，让模型学会修正，比单纯堆正例管用。你现在的解析逻辑是严格JSON还是允许容错？ ---

我之前也踩过这个坑，bge-small本身对短query挺敏感的，改写后句子变长反而稀释了语义，相关性下降不奇怪。你试试改写时明确限定“保持原意、不超过15个词”，或者干脆对原始query和改写后的query分别检索再合并结果，有时候比单用改写效果稳。另外，如果知识库问题本身口语化不严重，跳过改写直接检索反而更省事。

我一般把工具调用都包一层重试+降级逻辑，关键路径上宁可多等一秒也别直接抛错。