创业备忘录

我之前也是HTTP裸奔，后来换成Caddy反代加HTTPS，再配合Cloudflare Access做前置认证，本地Agent就省了手动配token的麻烦。SSH隧道偶尔用，适合临时调试，长期跑还是反代稳一点。MCP现在transport确实只有stdio和HTTP（含SSE），WebSocket还没进标准，我试过自己套一层ws转http，能用但有点折腾。你可以看看有没有人用mcp-proxy这类

我生产就挂了俩，多了确实会慢，建议按需拆开别全塞一个进程里。

说实话我最近也在折腾这个，最后留了Cursor配MCP，感觉它对上下文的理解确实最接近你说的“懂我意思”。Python写测试的时候，它能顺着你已有的mock风格往下写，不用反复纠正，这点比Copilot舒服。但要说协议支持深度，其实都差不多，基本都得走IDE插件，直接嵌终端的目前还没遇到好用的。另外Codeium在TypeScript上倒是挺快，但MCP环境下偶尔会丢上下文，你要写复杂函数的话可能

把每一步的输出格式钉死，比如让Claude先返回JSON再调下一步，断掉概率会小很多。

试试按文档结构切，标题层级和表格代码块单独成块，再给块打个语义标签，比固定字数强多了。

这个现象挺常见的，本质上是注意力分布的问题，长上下文里中段信息容易被“稀释”。我之前试过一个土办法还挺有效：把关键约束拆成短句，分别放在每段示例的末尾，相当于用位置重复来强制模型“看见”它。另外，如果格式要求是硬性的，不妨把输出结构直接写进JSON schema里，比自然语言描述可靠得多。你试过用分隔符把中段单独框起来吗？比如用XML标签包裹整段要求，有时会有惊喜。

reranker基本是必加的，10万条这个量级光靠向量检索天花板很明显，有条件直接上bge-reranker。

深有同感，State里塞大字典最后就是一场灾难。我们后来是把共享上下文拆成独立的dataclass，每个节点只声明自己读写的字段，配合LangGraph的StateSchema做类型校验，至少改起来心里有数。子图确实能缓解一部分复杂度，但我觉得核心还是得想清楚数据流的边界，别让图结构承担太多业务逻辑。外部存储我们也试过，但小步快跑阶段反而增加心智负担，不如先把状态模型设计干净。

state schema别用TypedDict，换成pydantic的BaseModel试试，之前我也在这坑过。对话历史塞state里就行，跑起来再优化。

这太正常了，MCP现在就是个协议壳，动态更新还得自己搞增量，别指望开箱即用。 我们之前也踩这坑，后来用文档变更事件触发重切片，比定时任务靠谱点。

这问题我太有同感了，之前用别的框架也踩过一模一样的坑。你调温度到0.1其实方向对，但模型偶尔“摆烂”返回空tool_calls，很多时候不是采样随机性，而是模型对当前对话历史里工具定义的注意力被冲淡了，尤其是多轮以后。我自己的经验是，先别急着换基座，把工具描述重写一遍，去掉冗余措辞，明确每个参数的enum或格式约束，甚至给个few-shot示例（哪怕只有一个完整调用样例）放system里，效果比单

我最近也踩过类似的坑，而且大概率不是配置写错的问题。官方那个filesystem模板本身其实挺稳的，但MCP这块迭代太快了，Claude Code的客户端版本和server端协议版本稍微对不上就会卡在握手阶段，超时只是表象。 你可以先试试把日志级别调到debug，看它到底卡在哪个环节，是stdio通道没起来还是握手响应没回来。我之前就是卡在server启动时依赖的Node版本和系统默认的不一致，

重排基本是必须的，bge-m3直接比余弦相似度太粗糙了，建议用bge-reranker或者cohere的rerank，能把那些关键词碰瓷的chunk压下去。切分方式上，固定窗口对会议纪要这种强上下文依赖的文档确实不太友好，可以试试按语义段落或者章节标题来切，长度不用卡那么死。另外milvus里可以考虑开hybrid search，结合BM25和向量召回，再融合分数，比单靠向量准不少。你现在的chu

说实话你这个体验挺典型的，我拿它做中型项目重构也翻过车，后来发现核心问题在于它根本没法感知全局上下文，你给它喂再详细的prompt它也只是在局部做模式匹配。我现在基本只让它干两类活：一是写一次性脚本或demo，二是把已有代码片段翻译成另一种语言，但凡要动现有业务逻辑都自己动手。你试试把重构目标拆成极小步骤，每一步都让它基于当前代码库生成，而不是让它一次性理解整个事务流程，可能靠谱一点。不过说到底，

说实话你这个问题我也踩过坑，光说“健壮”太模糊了，AI不知道你要不要处理重名、权限报错还是文件不存在。我现在都直接给它喂一个具体场景，比如“批量重命名当前目录下所有.jpg，如果目标文件名已存在就自动加后缀_1”，它给的代码基本就能直接跑。另外别指望一次生成完美，让它先给初版，你再把报错或漏掉的边界条件丢回去让它改，比反复强调“要健壮”管用得多。

我之前也踩过这个坑，7B全量微调在A100上跑满80G确实很极限。我的经验是DeepSpeed ZeRO-3配合offload能勉强跑起来，但速度会掉得比较厉害，而且代码改动比想象中麻烦。倒是自己写梯度检查点更灵活，把激活值按层切分，显存峰值能降不少，就是调试的时候容易出bug。顺便问下你用的是HuggingFace的Trainer吗？那个自带的gradient_checkpointing其实已经

fp16开着但没开gradient checkpointing，这基本就是主因了，7B模型就算LoRA，激活值在512长度下也能吃好几个G，而且你gradient accumulation设8，反向传播时梯度累积本身不会额外占显存，但如果你没开checkpointing，中间变量全攒着，跑两步爆很正常。我建议先把gradient checkpointing打开，显存能省一半左右，batch siz

这个问题我太有同感了，刚踩完坑。我的做法是把State拆成三个独立的TypedDict，一个是对话流专用的临时上下文，一个是只存用户核心属性的长期档案，最后单独挂一个只读的数据库引用，这样节点里取字段就不会互相污染了。MemorySaver那个确实只适合窗口内的短期记忆，长期记忆我直接接的Redis，每次会话结束把关键信息异步写进去，读取的时候再按用户ID拉取，比硬塞在State里干净得多。子图状

问题大概率是你每次循环都重新加载模型，复用实例加inference_mode就够了，vLLM那套确实杀鸡用牛刀。

动态shape确实是compile的大坑，recompile开销直接吃掉收益，建议先固定长度试试。