职场学习簿

写得挺好，建议补充一些性能数据。

刚入门，这个对我帮助很大。

我之前也遇到过类似问题，后来换了方案。

写得挺好，建议补充一些性能数据。

学到了，感谢分享！

学到了，感谢分享！

先加个重排试试，bge-reranker能筛掉不少关键词像但语义跑偏的chunk，比换embedding快。

我现在的习惯是分两步走，第一轮只给业务意图，比如“写个登录接口，先别引入JWT，用最简单的session”，让它先出个骨架。等它跑偏了我再补一句“密码别用明文，换成bcrypt”，这样它反而会顺着上下文调整，不会一次性堆一堆依赖。其实颗粒度不用卡太死，关键是把你真正在意的约束点说出来，剩下的让它自己选，选错了再纠偏成本也不高。我一般会在Prompt里加一句“先给最小实现，不要加额外中间件”，这句话

把中间结果显式塞进下一步prompt里，别指望模型自己记住，加个memory字段试试。

我之前也踩过这坑，后来改成抽取完再触发检查，别并联，稳多了。

Q4_K_M量化对代码任务的影响其实挺明显的，我拿Q4和Q8跑过同一批leetcode题，Q4在边界条件上翻车概率高不少，建议代码场景至少上Q6或Q8试试。另外你说的啰嗦问题，我一般会在prompt里加一句"只输出代码，不要解释和多余注释"，效果立竿见影。还有官方演示那个系统提示词是有调过的，本地默认模板不一定带，可以翻翻他们仓库里的system prompt抄过来用。

说实话你这问题我上个月刚趟完坑，核心不是加interrupt，而是把每个子Agent的state收敛成只读快照，再用一个显式的coordinator节点去做依赖编排，别让它们直接共享可变状态。Send API适合fan-out但不好处理条件依赖，我最后是手动用条件边加一个简单的状态机字段控制流程，虽然丑但至少不会出现竞态。另外检查Agent可以加个输入校验，空状态直接跳过执行，这样比调checkp

代码层做强制校验吧，prompt真靠不住，返回值不符合schema就直接抛异常重试。 多工具串联建议搞个状态机，每步落盘，失败就从最近的成功节点恢复。

显存持续上涨这个特征，挺像graph没释放的，建议在backward里别把索引矩阵直接存成self.xxx，试着用ctx.save_for_backward并且确保自定义Function的backward返回的梯度数量和forward输入对得上，不然autograd会一直保着整张计算图。scatter_add反向我踩过坑，梯度要scatter回原位置时容易产生重复累加，记得用index_put_或

我之前也卡在这儿过，vllm那个rope_scaling不是光调个系数就完事的，得跟max_model_len配合着来，比例不对直接白搭。你要是显存还有余量，试试把rope_scaling的factor调小一点，然后max_model_len别一次拉满，先1.5倍基准慢慢往上探，同时留意下vllm的日志里有没有警告。YaRN确实省事不少，但换架构前你确认下是不是真需要那么长的输入，很多时候是系统提

chunk跟着语义块走，别死磕字数，标题段落切完再按模型上限截断就好使。

你这问题太典型了，我调RAG时也踩过同一个坑。我的经验是光靠调相似度阈值真不行，得在检索完加一层交叉编码器rerank，比如bge-reranker，对top-20再精排，相关性会准很多。另外chunking可以试试按语义段落切，别硬按固定字符数，512个字有时会把一个完整意思劈两半。还有个土办法，把用户问题拆成关键词去匹配段落标题，命中后优先拉取，能过滤掉不少噪音。

试试在规则里写“只改函数体，不动签名和调用方”，配合codebase模式能稳不少。 把项目里的`.cursorrules`写严点，直接禁止改接口，我这边基本就老实了。

我之前也踩过这个坑，Qwen2.5的function calling对参数类型约束确实有点迷，后来把工具描述写成超详细的示例，比如直接给个“city: '北京市'”的json片段，成功率能上来不少。另外你试试把temperature调到0.2以下，模型脑补参数的情况会少很多。至于专门优化的开源模型，可以看看Qwen2.5的tool-use版本，或者微软的phi-4带function calling

我之前也卡在这块儿过，折腾了两天才搞明白。你猜的没错，就是“能力声明”的问题，Claude的MCP实现默认只信任read操作，你要在server初始化时明确把write和edit加进capabilities列表里，而且每个resource路径下还得单独配permissions，缺一个它就给你报权限错。文档这块确实写得模糊，我最后是去翻了MCP协议的GitHub讨论区才找到答案。另外提醒一下，就算声