profile: optimize conversation analysis concurrency

README.md

@@ -105,6 +105,8 @@ profileModelToken: ''
 profileModel: ''
 profileModelTemperature: null
 profileModelExtraBody: ''
+# 画像模型同时执行的请求上限，取值1~512；超出后在应用层排队，不计入首块超时
+profileMaxConcurrentRequests: 128
 # 留空使用插件自己的聊天库；本地实验可填写外部SQLite历史库的绝对路径
 profileHistoryDatabasePath: ''
 # 异步刷新好友、群、群成员联系人快照，写入 chat-history.sqlite
@@ -232,8 +234,11 @@ searchHistoryMaxRecords: 5000
 模型只使用单次请求内有效的临时编号，不接触画像条目的内部 UUID；不合规建议会被跳过，不阻断其他有效更新。
 临时用户别名不会写入最终画像。`profileCompact` 可独立清理重复或低价值条目，且不推进历史水位线。
 旧历史可通过 `profileAnalyze` 或 `profileAnalyzeGroup` 手动分批推进。执行不带参数的 `profileAnalyzeGroup` 时，
-插件会从画像历史库枚举所有含有效群消息的群，并为每个群同时启动一个分析任务，不设置额外的应用层并发上限；
-显式传入群号时仍只分析指定群。全量模式仅发送启动和最终汇总，逐群进度与结果写入日志，避免回执刷屏。
+插件会从画像历史库枚举所有含有效群消息的群，并在启动任务前排除游标已覆盖最新历史快照的群，只并发推进仍有
+历史待处理的群。画像模型通过应用层信号量按 `profileMaxConcurrentRequests` 限制同时执行的请求数，默认 128；
+等待信号量的时间不计入首块响应超时，OkHttp 使用相同上限兜底。群批次只在读取画像快照和提交结果时短暂
+持有用户锁，模型请求在锁外执行；提交前若发现画像已变化，会加载最新版并重新分析，避免共享群友把网络请求
+串行化。显式传入群号时仍只分析指定群。全量模式仅发送启动和最终汇总，逐群进度与结果写入日志，避免回执刷屏。
 
 下一次正常群聊会自动携带触发者和最近发言者的认识。现有好感度、Bot 代号、标签和主观印象会与证据驱动的
 长期画像按同一个人合并渲染，并明确给出长期画像条目数；私聊也会携带对方的可靠画像摘要和条目数。