建议加大或可自定义重试次数

[zhongjianhua163]

无人值守 跑长任务的时候，遇到网络波动或接口故障，重试了两次，总共才几秒钟，还没来得及恢复，任务就停止了。
建议加大或可自定义重试次数，每次重试间隔递增，内置一个间隔上限即可。

#668

[chaohui2]

~/.dsh/settings.yaml
加上retryPolicy参数就好了。
ui-onboarding:
welcomeNoticeVersion: 2026-08-13.1
llm-deepseek:
baseURL: xxxxxxxxxx
retryPolicy:
mode: normal
maxRetries: 10
retryableCodes: [EMPTY_RESPONSE, RATE_LIMIT, SERVER, TIMEOUT, TRANSPORT]
backoff:
initialDelayMs: 1000
maxDelayMs: 30000
jitterRatio: 0.2
agent-default-model:
provider: deepseek-official
model: deepseek-v4-flash
reasoningEffort: high

[zhongjianhua163]

谢谢！！不知道哪里有这个配置文件的详细说明？？

[chaohui2]

哈哈哈第一行就是文件名，你可以让ai帮你改

[weijiafu14]

给这个建议补一组已量过的现状，能让"往哪加配置"更具体：

传输层（pi-ai retryProviderRequest，故障注入实测、代码未修改）已经有你要的所有旋钮和行为：重试次数 maxRetries 可调、间隔指数递增、有间隔上限且上限可调（maxRetryDelayMs）、429 的 Retry-After 会被尊重（等出来的恢复我们实测过）、连接级错误（read tcp reset 族）也会重试恢复。逐案判决：retry-experiment-results.json / transport-classify-results.json。

所以你撞到的"重试两次几秒就放弃"，缺的不是机制而是配置面没露出来：路由的包装层用了自己的保守常数、没把上面这些参数开放给用户。这正是该在这贴里向官方要的东西——把 maxRetries/maxRetryDelayMs 暴露成 provider 配置（无人值守场景调大即可），比新造一套重试逻辑省得多。系统性的分层讨论见 #3852（429 恢复跨层缺陷链的 RFC），你这个诉求是那条链里"配置面"的一环。