性能与稳定性踩坑：几个我实际遇到的坑和绕法

用了几个月，攒了一些坑。都是实际发生过的，列出来供参考。 坑一：长时间运行后内存持续上涨。原因是工具在会话里不断累积上下文和中间结果，不做回收。表现为跑几个小时后响应变慢，最后卡死。应对方法是把长任务拆成若干短会话，处理完一个阶段就重开一个；另外定期重启客户端。 坑二：大文件读取导致上下文爆炸。有一次让 agent 读一个几兆的日志，直接把上下文撑满，后续对话全部退化。应对方法是先做预处理，用命令截取关键片段再喂进去。日志分析的正确姿势是先筛选再给模型，而不是把整个文件丢进去。 坑三：并发写冲突。两个并行任务改了同一个配置文件，后写的把前面的改没了。排查花了很久，因为表现是"某次改动莫名其妙丢了"。应对方法是用独立的 git worktree 给每条并行线，物理隔离比逻辑约定可靠。 坑四：缓存失效导致成本飙升。有一次代码量没变、任务没变，账单涨了三倍。排查发现是项目说明文件里被人加了一行时间戳，导致每次请求的前缀都不同，缓存全部失效。这个坑很隐蔽，因为我之前提过但也提醒一下：前缀里不要放任何动态内容。 坑五：网络抖动导致的半完成状态。任务执行到一半网络断了，本地留下了改了一半的文件，重试时状态混乱。应对方法是关键操作要幂等，并且能检测上次的中断点。 坑六：预览与实际环境不一致。可视化预览里一切正常，上线后发现字体不对、布局错位。原因是预览环境和真实浏览器的差异。应对方法是关键页面一定要在目标浏览器里实测，别把预览当验收。 共通的应对思路就三条：拆小任务、固定前缀、物理隔离。这三条能解决绝大部分稳定性问题。