长期关注效率案例库

我最近也遇到过类似问题，光靠System Prompt确实管不住，Agent上下文一长就容易“发挥”。后来我试了下，把回答路径拆成几个明确步骤，比如先判断意图再匹配对应话术，比纯文字限制靠谱得多。另外可以试试在Prompt里加“如果用户没问，就回复不知道或引导回原题”，这种负面约束比正面要求有效。决策树倒也不必，但给Agent一个“任务完成即停止”的终止条件，会好很多。

说实话MCP这块儿我折腾了快两周才跑通，你那个连不上Node服务的问题大概率是环境变量没配对，server地址写成localhost但没起服务。我自己用Claude Desktop配了个本地文件操作server，确实能让它直接改代码，但修bug这事儿真别抱太高期待，它更像是能精准执行你给的命令，比如跑个eslint --fix，前提是你把工作流拆得足够细。自动跑测试目前更多是能触发，但判断结果对不

这问题太真实了，我上次写个自动重构的Agent也差点翻车，账单直接飙了三位数。你可以在每次调用工具前加个状态检查，比如比较文件哈希或者记录上次修改时间，没变化就直接跳出循环。另外把“退出条件”写进代码逻辑里，别全指望prompt，比如设置最大迭代次数或者让Agent必须输出“完成”才能终止，这样比纯文字约束靠谱得多。

我觉得你大概率是踩到MCP工具结果回传的截断机制了，跟微调本身关系不大。MCP服务器那边对工具返回内容通常有个隐形的token预算，它不会把完整历史全塞给模型，而是按最近几轮加最新工具结果来截，所以多轮之后模型自然就“失忆”了。你调max_tokens只是改生成上限，管不到输入侧的裁剪逻辑，context_window如果没设置成足够大且没开滑动窗口，同样白搭。我之前接别的工具服务器也遇到过，后来

模板放前端最大的坑不是token计算，而是你永远不知道用户用devtools改了什么，到时候排查线上问题直接想骂人。建议后端保留唯一可信版本，前端预览走接口拿渲染后的文本，别让JS碰原始模板。另外few-shot和上下文拼接这种动态部分本来就不该让前端感知，你把它拆成“模板定义”和“渲染引擎”两个模块，前端只拿最终prompt，权限和审计都好做。至于实时预览，FastAPI挂个websocket推