宿主协议不一样。ing Claude's current work───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

──简短结论───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
                                                                                                                                                                                                                                               E:\originzip\xiaohongshu-writer─是─本地 OpenClaw 插件形态，不是─桌面客户端 bundle/workspace 形态。─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
  所以在本地 OpenClaw 里，它只要能加载插件和技能就能跑；但在客户端里，宿主需要的不只是技能目录，还需要一套可打包、可注入上下文、可隔离运行态、可稳定调度的工作区协议。                                                                       
  ---
  为什么本地能跑，客户端不行

  1. 源项目是“插件”，不是“workspace automation project”

  你这个源项目的形态很明确：

  - E:\originzip\xiaohongshu-writer\package.json:4 用的是 openclaw.extensions
  - E:\originzip\xiaohongshu-writer\openclaw.plugin.json:1 开始是插件描述
  - E:\originzip\xiaohongshu-writer\openclaw.plugin.json:4-9 直接列 skills

  也就是说，它的假设是：

  - 宿主会按 插件机制 加载
  - 宿主认识 openclaw.plugin.json
  - 宿主会把 index.js 扩展跑起来
  - skills 按插件规则注册

  而工作区版 xhs 已经变成了另一套协议：

  - D:\qjclaw\workspace\xhs\project.json:4 projectType: "automation-project"
  - D:\qjclaw\workspace\xhs\project.json:7-18 workspaceAutomation.script: "workspace_entry.py"
  - D:\qjclaw\workspace\xhs\project.json:82-89 boundSkillIds、workspaceEntryEnabled

  客户端要的不是“有几个 skills 就行”，而是“这是一个我能托管的 automation project”。

  ---
  2. 客户端需要一个统一入口，不是直接猜怎么跑脚本

  源项目的脚本是 CLI 风格的：

  - E:\originzip\xiaohongshu-writer\scripts\run.py:1-11 就是在定义命令行入口
  - E:\originzip\xiaohongshu-writer\scripts\run.py:27-35 直接本地改 sys.path 并导入脚本模块
  - E:\originzip\xiaohongshu-writer\scripts\run.py:134-137 还直接把 debug_search.jpg 写当前目录

  这类脚本的前提是：

  - 你知道从哪个命令启动
  - 你知道传什么参数
  - 你知道当前工作目录是什么
  - 你知道输出文件落哪

  桌面客户端不能靠“猜”这些事情，所以工作区版才会加：

  - D:\qjclaw\workspace\xhs\workspace_entry.py:28-37 统一入口与运行脚本位置
  - D:\qjclaw\workspace\xhs\project.json:7-18 明确告诉客户端入口脚本和参数模板

  也就是说，客户端不是不能执行 scripts/run.py，而是它需要一个稳定入口层来把自然语言请求转换成可执行脚本调用。

  ---
  3. 客户端需要上下文注入，源项目没有这层协议

  工作区版 workspace_entry.py 明显承担了宿主桥接职责：

  - D:\qjclaw\workspace\xhs\workspace_entry.py:28 QJC_WORKSPACE_EVENT
  - D:\qjclaw\workspace\xhs\workspace_entry.py:77-103 load_project_identity() / render_context_prelude()
  - D:\qjclaw\workspace\xhs\workspace_entry.py:116-126 load_project_attachments()

  这说明客户端运行时不只是“执行脚本”，还要处理：

  - 当前项目身份
  - 当前 prompt 上下文
  - 用户附件
  - 宿主和项目之间的事件通信

  本地 OpenClaw 插件模式里，这些能力可能是宿主内部直接提供的，或者根本不需要 project workspace 这层包装。
  但桌面客户端 bundle 里，如果没有这层桥接，skills/scripts 并不知道：

  - 当前用户是在让它“生成笔记”还是“直接发布”
  - 当前会话带了哪些附件
  - 当前项目应该把上下文隔离到哪里

  ---
  4. 客户端必须做运行态隔离，源项目默认是“本地目录式”

  工作区版 xhs 明确把运行态收口到 memory/：

  - D:\qjclaw\workspace\xhs\workspace_entry.py:29-34
    - MEMORY_ROOT
    - RUNS_ROOT
    - GENERATED_ROOT
    - PROFILE_ROOT

  还统一注入环境变量：

  - D:\qjclaw\workspace\xhs\workspace_entry.py:129-137
    - XHS_MEMORY_ROOT
    - XHS_PROFILE_DIR
    - XHS_ENV_PATH

  而源项目脚本更像默认直接在项目目录跑：

  - E:\originzip\xiaohongshu-writer\scripts\run.py:134-137 当前目录写 debug_search.jpg

  这在“本地手动跑项目”时问题不大，但在桌面客户端里会有几个问题：

  1. bundle 可能解压到临时目录
  2. 客户端需要每个项目状态隔离
  3. 浏览器 profile / 生成文件 / 缓存文件不能乱落
  4. Windows 下路径、权限、清理策略更敏感

  所以不是“多做了很多没必要的改动”，而是客户端要把一个原本“开发者自己跑的 repo”，变成“宿主可控的项目单元”。

  ---
  5. 源项目里的插件声明本身就不适合直接打包搬进客户端

  这个点很关键：

  - E:\originzip\xiaohongshu-writer\openclaw.plugin.json:4-9 里的 skills 路径是绝对路径
  指向 C:\Users\15153476162\.openclaw\workspace\projects\xiaohongshu-writer\skills\...

  这说明原项目默认假设：

  - 它运行在某个固定的本地 OpenClaw 目录结构下
  - 宿主知道这个目录布局
  - 这个用户路径存在

  但客户端 bundle 不能依赖用户机器上有这套固定目录，更不能依赖某个绝对路径。
  所以工作区版才改成相对项目根的协议化入口。

  ---
  6. 客户端不仅要“能跑”，还要“能识别能力”

  工作区版 project.json 还声明了：

  - D:\qjclaw\workspace\xhs\project.json:44-80 defaultEntry / entries
  - D:\qjclaw\workspace\xhs\project.json:47-59 intentAliases / capabilities

  这对客户端很重要，因为客户端要知道：

  - 用户说“写一篇小红书”时该路由到哪个项目
  - 这个项目支持什么能力
  - 默认入口是什么

  而本地插件模式里，skills 可能只是注册后由 OpenClaw 自己管理；桌面客户端如果只“扫目录”，它不知道该怎么做稳定路由和展示。

  ---
  所以“为什么不能直接跑”

  因为客户端要解决的是这 4 件事，而源项目只覆盖了其中一部分：

  1. 项目识别
  源项目：插件识别
  客户端：workspace/automation project 识别
  2. 入口调度
  源项目：人手动/插件机制启动
  客户端：统一入口、统一参数、统一路由
  3. 上下文与附件
  源项目：弱约束或宿主内置
  客户端：显式协议注入
  4. 运行态治理
  源项目：本地 repo 风格
  客户端：隔离、可打包、可迁移、可清理

  ---
  你可以把它理解成

  E:\originzip\xiaohongshu-writer 更像：

  ▎ “一个能在本地 OpenClaw 环境里被插件机制加载的项目”

  而 D:\qjclaw\workspace\xhs 更像：

  ▎ “一个能被桌面客户端当成独立工作区项目稳定托管的项目”

  两者不是业务代码能不能跑的问题，主要是宿主集成层不一致。

  ---
  哪些改动其实就是在补这个“宿主集成层”

  最核心就是这几类：

  - 插件形态 → workspace project 形态
    - package.json/openclaw.plugin.json → project.json
  - 无统一入口 → 有统一入口
    - workspace_entry.py
  - 脚本直跑 → 宿主桥接后再跑脚本
    - prompt / attachment / event / env 注入
  - 项目根目录落盘 → memory 隔离目录
    - MEMORY_ROOT / RUNS_ROOT / PROFILE_ROOT


