eaiadminandClaude Code
c1af86c934
按用户指示做**一包提交**，不按工作流拆分。本提交刻意混合了多条并行线：
· 本地 ASR 接管：audio 成为与 chat/embed/image/video 同等的路由类别
（IsLocalRoute 单一判据、audio 健康探测、default_audio_route、
auto 占位、GET /api/ai/routes/audio、回退云端时界面明示「音频已出网」）
· LLM 调用层：ctx 贯穿、ToolCall/ToolSchema、EmptyCompletionError /
TransientUpstreamError（按错误类型而非文案判重试）
· 编排 Agent：general_assistant orchestrate/persistence/spec_driver
· 联网搜索：internal/search（playwright）
· 网盘：backend + 前端
· 前端 UI：导航/路由/工作台若干页
· 交付文档：DELIVERY.md / AR04 / 部署文档的「无 Python」表述据实改写，
新增 eai_agentplatform-asr.service、asr.env、clonezilla-cleanup 清 ~/asr-poc
不分拆的原因：dev 早期，粒度不该打断工作节奏。且实测过——这些改动
**在编译上是同一个单元**（llm.go 的 ctx 签名变更牵动 12 个调用点，
chat_message.go 的 ctx 改动又与编排重写同处一个 hunk），拆出来的中间态编不过。
详见 TOP_CODING_RULES.md G14.5 与 bugs_and_errors.md E09。
Co-Authored-By: Claude Code <noreply@anthropic.com>
1 line
1.7 KiB
JSON
1 line
1.7 KiB
JSON
{"code":0,"data":{"message":{"role":"assistant","content":"Temperature 是大语言模型**推理/采样阶段**的一个参数，不是模型训练出来的权重。它用来调节下一个 token 的概率分布有多“随机”。\n\n原理上，模型先给每个候选 token 一个分数 logits，然后：\n\n\\[\np_i = \\frac{\\exp(z_i / T)}{\\sum_j \\exp(z_j / T)}\n\\]\n\n其中 \\(T\\) 就是 temperature。\n\n- **T \u003c 1，低温**：分布更尖锐，高概率 token 更容易被选中。输出更确定、保守、稳定，适合事实问答、代码、结构化任务。\n- **T = 1**：按模型原始概率采样。\n- **T \u003e 1，高温**：分布更平坦，低概率 token 也有更多机会被选中。输出更多样、发散、有创造性，但也更容易跑题、胡说或幻觉。\n- **T → 0**：接近贪心解码，每次选概率最高的 token；实际实现通常直接特殊处理为 greedy。\n\n它主要影响这些行为：\n\n1. **随机性/多样性**：温度越高，同一 prompt 每次输出差异越大。\n2. **创造性**：高温更容易产生意外组合和新表达。\n3. **稳定性/一致性**：低温输出更可复现、更稳定。\n4. **事实准确性**：高温通常增加幻觉和错误风险；低温更稳，但可能单调、重复。\n5. **解码效果**：它不改变模型知识，只改变从概率分布里怎么选词。\n\n实际使用中，Temperature 常和 top-k、top-p 一起用。经验上：事实问答/代码用 0～0.3，普通对话 0.5～0.8，创意写作可到 0.8～1.2 或更高。","timestamp":"2026-09-25 20:10:40","type":"text"},"is_plan":false,"is_expert":false,"stream":false},"error":null,"message":"success"} |