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

小派正在努力回答中, 耐心等待一下吧...

小派正在努力回答中, 耐心等待一下吧...

小派正在努力回答中, 耐心等待一下吧...

小派正在努力回答中, 耐心等待一下吧...

小派正在努力回答中, 耐心等待一下吧...

这段划线内容出自PaiCLI的Skill系统，**`SkillContextBuffer` 是连接「Skill决策手册」和「LLM决策行为」的核心桥梁**。 ## 它的核心职责 当 LLM 调用 `load_skill("web-access")` 时，PaiCLI **没有**把 SKILL.md 的完整 body 塞进工具返回结果里，而是写入了 `SkillContextBuffer`。下一轮构造 user message 时，从 buffer 里取出 body，拼在用户原始输入的前面： ``` ## 已加载 Skill：web-access <SKILL.md body 完整内容> --- 用户输入：<用户的原始消息> ``` ## 为什么这么设计？ | 方案 | 问题 | |---|---| | ❌ 塞进工具返回结果 | LLM 视其为"参考信息"，决策权重低 | | ❌ 塞进 system prompt | 每次加载都导致 prompt cache 失效，浪费 token | | ✅ **走 user message 注入** | LLM 视其为"用户附加指令"，执行权重高；system prompt 不变，cache 得以保留 | ## 它的 5 个关键特性 1. **一次性消费**：`drain()` 取出后自动清空，避免 body 在对话中反复堆积撑爆上下文 2. **最多 3 个 Skill**：同一轮连续加载超过 3 个，只保留最近的 3 个 3. **同名替换**：同一 Skill 加载两次，新 body 替换旧的，不会重复累积 4. **角色隔离**：Planner、Worker、Reviewer 各自持有独立 buffer，各取所需（Worker 抓网页，Reviewer 审查代码，互不干扰） 5. **`/clear` 重置**：调试时先清 buffer 再 reload，保证读到最新版 **一句话总结**：`SkillContextBuffer` 让 Agent **「在合适的时机读到合适的决策手册，且不影响系统 prompt 的缓存效率」**，是 Skill 系统按需加载、渐进式披露理念的落地支撑。

你的理解很准确，但需要厘清这里的"下一轮"具体指什么——它**不是指"下一轮用户对话"**，而是指 **Agent 内部的下一次 LLM 调用循环**。 ## 关键区别 在一个用户提问的处理过程中，LLM 可能会经历多轮"思考→调用工具→观察结果→继续思考"的内部循环。举个例子： **用户说："帮我看下这个链接"** | 轮次 | 发生了什么 | |------|-----------| | **第1轮（LLM内部）** | LLM 判断需要联网技能 → 调用 `load_skill("web-access")` → 工具返回"已加载"确认 → **但此时 body 还未出现在上下文中** | | **第2轮（LLM内部）** | 构造 user message 时，**body 从 buffer 注入进来** → LLM 看到完整决策手册 → 按指引调用 `web_fetch` 抓网页 | 也就是说，**用户只需要发一次消息**，Agent 会在内部的多轮循环中完成"先加载 skill → 下一轮按 skill 行动"的全流程。 ## 为什么这样设计？ 文章讲得很清楚，两个原因： 1. **决策权重**：工具返回的内容 LLM 当"参考信息"，而 user message 里的内容 LLM 当"指令"来执行。把 body 放在下一轮的 user message 里，决策权重更高。 2. **Prompt Cache 保留**：body 走 user message 而非 system prompt，system prompt 不变，API 的 prompt cache 就不会失效，省 token。 总结一句话：**用户只需要说一次"帮我看这个链接"，Agent 内部会自动完成"先加载 skill → 下一轮按 skill 指引行动"的完整流程，无需用户再次输入。**

这个设计主要有三个核心原因： **1. 让 Agent 能够直接读取文件内容** LLM 是通过 `read_file` 工具来获取站点经验的。如果 references 留在 jar 包里（二进制压缩包），Agent 无法直接读取。解压到用户目录下的 `~/.paicli/skills-cache/` 后，Agent 才能通过 `read_file("~/.paicli/skills-cache/web-access/references/site-patterns/mp.weixin.qq.com.md")` 获取对应站点的操作经验，比如知道微信公众号是 SPA 渲染、必须走 CDP 浏览器。 **2. 支持用户自定义和扩展** 解压到用户目录后，用户可以随时查看、修改甚至补充这些经验文件。比如你可以给某个站点添加新的 CSS 选择器或 JS 提取片段，Agent 下次就能用上。如果留在 jar 包里，用户想改就必须重新打包，根本不现实。 **3. 版本化缓存机制，提升启动性能** extractor 并非每次启动都解压——它会检查 `skills-cache/<name>/.version` 文件与 jar 内置版本号是否一致。一致就跳过，不一致或文件不存在时才重写整个 cache 目录。这样既保证了内置经验能随版本更新，又避免了每次启动都解压带来的 IO 开销，**一举两得**。

哈哈，你这说法本身就自相矛盾了吧？既然 read_file 有路径限制，解压到用户目录下的内置 references 根本读不到，那 LLM 还怎么“通过 read_file 读取这些文件来获取站点经验”？这不是典型的逻辑断裂吗？要么 read_file 的路径限制就是个摆设，要么“获取站点经验”就是个伪命题。你一方面承认 read_file 有路径限制，另一方面又假设它能读取受限路径下的文件，这不等于说“水能烧开，但壶底有个洞”一样可笑？建议先把基础架构捋清楚，再来谈什么“站点经验”，否则连文件都读不到，经验从哪来？从空气里悟出来吗？