持续研究效率实践笔记

我一般会把“给输入输出示例”和“列出必须处理的边界条件”分开写，比如明确告诉它“文件可能没表头，路径含中文，空值用None而不是删除行”，这样比笼统说“考虑边界”有用得多。让它自己跑一遍再返回代码这个思路我试过，但对复杂任务容易陷入死循环，不如你先给几个刁钻的测试用例，逼它写出能过的版本。另外我还会加一句“不要用你没见过的库，只用标准库”，能少很多莫名报错。你试过把错误信息直接贴回去让它修吗？有时

试试按召回率-命中率曲线调，或者直接上RAGAS评估，别光靠肉眼感觉。 另外top-k跟chunk切分粒度强相关，你一个chunk多长？

说实话你这感觉挺对的，MCP本质上就是个标准化接口，RAG套上去确实没改变核心流程。但区别在于它能让你在同一个会话里动态切换多个数据源，而不是每次改需求都重新拼prompt。像那种需要先查A库再根据结果查B库的多跳场景，工具调用比塞上下文要自然得多。不过要是你只是单轮问答，那确实属于脱裤子放屁。

这情况多半是数据问题，长文本没截断导致学习信号太杂，先清洗数据比调参管用。 LoRA rank不用急着加，换大模型反而更吃数据，先看看重复样本是不是太多了。

这事我踩过类似的坑，排查下来发现多半不是MCP协议的问题，而是FastMCP默认没做连接复用，每个工具调用都重新握手。生产环境我一般控制在5个以内，超过就考虑把功能合并进一个服务里，或者用网关做路由转发。建议你压测时重点看下TCP连接数和握手耗时，往往瓶颈在这里。 另外可以给MCP服务器加个轻量级缓存层，像数据库查询这种高频操作直接走缓存，响应能快一个量级。连接池方面，试试把底层HTTP客户端换

这报错我之前也踩过，八成不是stdio配置的问题，而是你server端没正确进入事件循环。MCP的Python SDK要求用 `mcp.run()` 或者自己起asyncio loop，但如果你在代码里用了 `asyncio.run()` 嵌套或者没把transport注册到同一个loop里，就会出现“通道未就绪”。你检查下是不是在 `@server.list_tools()` 或 `call_t