一个凌晨2点的报错unknown variant image_url, expected text——我们的AI助手被自己聊天记录里的一张截图噎死了。事情是这样的我们的系统里有四个AI员工小密统筹、小虾开发、小牛测试、小白体验。他们通过一个类似微信的收件箱机制协作——小密派任务小虾开发小牛测试小密复核。一切运转良好直到那天凌晨。任务派发出去后小虾迟迟没有回复。去看它的会话界面一条刺眼的红色报错循环刷屏错误: LLM request failed: provider rejected the request schema or tool payload.翻译过来就是大模型拒绝了我的请求。再往深挖原始报错是400 Failed to deserialize the JSON body into the target type: messages[161]: unknown variant image_url, expected textmessages[161]——第161条消息。也就是说我们的AI在跟大模型对话时发过去的第161条消息是一张图片而对方是纯文本模型不认图片。图片是怎么混进对话里的小虾是开发Agent它的工作流里有一步是截图验证——改完代码后用无头浏览器截图确认页面效果。截图是任务要求的证据但它有个副作用截图会以图片消息的形式进入Agent的会话记录。我们的Agent用的是deepseek-v4-flash——一个纯文本模型。它不支持图片输入。但Agent框架并不管这些你给了截图我就把截图塞进消息流里发给模型。于是一次、两次、三次……每次开发任务都攒一两张截图会话记录越来越大。终于有一天消息列表里第161条是一张图模型直接拒绝解析整个请求。不是某一张图特别大是积累的图片让整个会话变味了。排查过程先看Session报错出现后第一反应是查Agent的会话状态Session。小虾 Session: 4.2MB27个会话文件27个会话文件、4.2MB——对于一个纯文本模型来说这是危险的信号。会话里塞满了截图、工具输出、长上下文。模型每次请求都要携带这4.2MB的历史包袱而其中还藏着模型根本不支持的图片。查了模型配置、查了API密钥、查了网络……最后才在错误日志里看到那一行被淹没的原始报错messages[161]: unknown variant image_url不是配置错了不是密钥失效是消息内容本身不合法——模型不认识图片这种消息类型。修复给Session定个卫生标准问题清楚了修复思路也就出来了——Session需要定期清理。我们写了一个自动清理脚本规则很简单# 清理规则ifsession_size3MB:# 会话太大 → 清delete(session)ifcontains_image(session):# 会话里有图片 → 清delete(session)两个条件命中任意一个就清理。清理掉之后Agent下次启动会用干净的会话重新开始——它的指令在HEARTBEAT文件里持久化不依赖会话记忆所以清理不会让它失忆。然后把这个脚本挂到了每分钟运行的定时任务里。从此以后以前: Session积累图片 → 模型400拒绝 → Agent卡死 → 人工救火 现在: Session超3MB或含图 → 自动清理 → Agent永远用干净会话这件事教给我们的三件事第一模型的能力边界是硬约束。不是所有模型都能看图。用纯文本模型就要接受图片不能进对话这个事实。框架不会替你考虑这些——工具给了截图就塞进去管你模型认不认。第二Session是会被污染的。会话记录不只是对话历史它会积累工具输出、截图、中间过程。对支持图片的模型这是上下文对纯文本模型这是毒药。长期运行的AgentSession卫生和代码卫生一样重要。第三报错要看原始信息。provider rejected the request schema or tool payload这种报错模棱两可——真正有用的信息藏在rawError里unknown variant image_url, expected text。框架层的报错是给运维看的底层的原始报错才是给排查者看的。结尾那天凌晨我们给AI做完会话大扫除之后它立刻就活了过来——继续开发、继续测试、继续认真回复每一个任务。后来我在清理脚本的注释里写了一句话对话记录里有截图是给会看图的模型准备的。给纯文本模型的对话里塞图片就像给一个不识字的人读报纸——不是他不想看是这报纸递错了人。工具不会替你想这个模型认不认这张图——这是你的事。完本文是多Agent派发系统系列第33篇。前情一个换行符毁了一张任务表、为了省token拆了1613行代码、0字节的信任危机……技术事故都是相似的看起来是灵异事件查到底都是人的疏忽。欢迎加入QQ频道共同交流。