Replies: 2 comments 1 reply
|
这个报错来自上游 DeepSeek API 的 400 响应, 不是会话状态问题: DSH 只把 HTTP 400/413 归一化为 INVALID_REQUEST 并透传上游消息正文(llm-deepseek/src/adapter.ts:339-351), "Content Exists Risk" 字符串本身来自平台侧内容策略拦截. 所以新开会话第一轮也报错是符合机制的 - 拦截按请求内容判定, 与旧会话无关. 建议: 1) 用最小提示词(如 "hello")、不带任何附件裸测一次, 若通过, 说明是当前对话内容(文本/图片/文件)触发了拦截, 可逐段二分定位; 2) 若最小请求仍被拦, 保留响应头里的 x-request-id, 联系 DeepSeek 平台支持复查; 3) 长会话场景的排查见 #5445(已分析 DSH 侧透传路径与恢复方法). |
|
先说结论:这个报错不是会话状态问题,而是上游 DeepSeek API 的 400 响应被 DSH 透传出来了。“新开会话第一轮也报错”完全符合机制——拦截按请求内容判定,跟会话新旧、长短无关。 代码依据(dsh-llm-deepseek,checkout @ c291e79):
建议(按成本从低到高):
核实基准:checkout D:\deepseek-harness @ c291e79(HEAD),packages/llm/llm-deepseek/src/adapter.ts:328-331、339-351、666-700;“Content Exists Risk” 全仓库 grep 0 匹配。 |

Uh oh!
There was an error while loading. Please reload this page.
虽然已经有过同样的问题,但是我这个不是长会话。甚至我开了一个新的会话,让它自己排查问题,第一轮还是会报错。

![Uploading 微信图片_20260913114645_12_5.png…]()
All reactions