web-access Skill上线：PaiCLI 的联网能力拉到满中满

这是一个非常敏锐且核心的架构问题。这里你理解上有一点点小偏差：**你不需要等用户发送下一个“新对话”才能用上 Skill**。 这里的“下一轮”，指的是 **同一个用户问题下，Agent 内部 ReAct循环的下一轮工具调用步骤**。它的实际运行流程是这样的： 1. **第1步（用户提问）**：你发送指令（如“帮我抓取某个网页”），这是外层的输入。 2. **第2步（Agent思考并加载）**：Agent检索到 Skill索引，决定调用 `load_skill("web-access")`工具。 3. **第3步（系统处理）**：PaiCLI 把 Skill 内容注入到 `SkillContextBuffer`，但**不**直接塞在本次工具返回的结果中。 4. **第4步（ReAct下一轮注入）**：Agent拿到工具返回的确认信息后，继续思考。在构造这一步的上下文时，系统会把 Buffer里的 Skill body拼接到 User Message 中发给 Agent。 5. **第5步（Agent执行）**：此时 Agent 已经完全掌握 Skill，它会立刻在当前问题下调用 `web_fetch` 或浏览器去完成任务。 **为什么不在当前轮次直接返回在 Tool Response 里？** 这是基于大模型机制的高级设计，主要有两个原因： 1. **决策权重更高**：Tool返回的内容在 LLM眼里是“参考事实”，容易被忽略或降权；但拼在 User Message里的内容，LLM 会将其视为“用户附加的指令”，执行贯彻的意愿和权重会高得多。 2. **保住 Prompt Cache（降本提速）**：如果把 Skill 内容动态塞进 System Prompt，会导致 API原本缓存好的几千个 Token 全部作废。通过固定 System Prompt 不变，只在 User Message 里按需注入，能完美保留 Prompt Cache，大幅降低成本和延迟。 总结来说，Skill 的加载和生效完全发生在**你发一次指令后的 Agent 内部多步推理中**。你不需要多发一次消息，只需等上几秒钟，Agent 就能自己加载并运用 Skill 解决问题。