19-gaps — 第一轮缺口补采 + 新沙箱实例核查

← 返回主报告：Kimi Agent（云端沙箱）技术报告 ｜ GitHub 原文

合规与风险声明：本报告为安全研究与互操作学习目的的逆向分析，全程只读采集，未对目标系统做任何修改；文中所有密钥、token、账号级标识（chat_id / project_id / tenant_id 等）均已脱敏；沙箱内发现的默认弱口令（VNC/SSH）属平台侧配置，仅作安全发现披露，请勿用于访问任何不属于自己的系统。docx/pdf/xlsx/kimi-slides 等引擎二进制为 Moonshot 专有许可（禁再分发/逆向），本文仅作行为级描述。报告基于单次分析窗口（约 50 分钟生命周期），软件版本与技能库存随镜像更新可能变化。

采集时间：2026-08-18；采集方式：HTTP 只读 http://127.0.0.1:18080/<沙箱绝对路径>（本轮 SSH 12222 不可用）。 采集条件警示：与第一轮末尾相同，采集进行到约 70% 时沙箱侧 frpc 再次掉线（18080 connection refused，本机 frps 进程仍在），此后隧道呈”数十秒级短暂恢复窗口”的抖动状态。中断前已完成任务①②③④的全部主体内容与任务⑤的抽样；_meta.json 全量总数普查在隧道恢复窗口内补跑完成（结果见 §5.3）。

1. 启动链原文：/init、stage0、rc.init、s6-rc.d 服务脚本（任务①）

1.1 /init —— 上游原版，零 Kimi 定制

/init 全文 1012 字节，与 s6-overlay 3.1.6.2 上游发布版逐字节同构（ shebang #!/bin/sh -e、自举 PATH（/bin、/usr/bin、/command）、等待 fd3 的 Docker readiness 通知、最后 exec s6-overlay-suexec … /package/admin/s6-overlay-3.1.6.2/libexec/stage0）。没有任何 Kimi 定制行——第一轮 01-system §3.1 基于标准行为的推测被原文证实。

1.2 stage0（/package/admin/s6-overlay-3.1.6.2/libexec/stage0，2073 字节）

同样是上游原版：解析 S6_LOGGING_SCRIPT/S6_KEEP_ENV/S6_LOGGING/S6_CATCHALL_USER/S6_KILL_GRACETIME/S6_SYNC_DISKS 等运行时控制变量，调 s6-linux-init-maker -NC -D top -c /run/s6/basedir … 生成 stage1，再处理环境分发与信号代理。结论：整个 s6 引导层没有任何 Moonshot 补丁，定制全部在”服务定义层”（s6-rc.d 的 run 脚本）而非 init 层。

1.3 rc.init（/run/s6/basedir/scripts/rc.init，2335 字节）—— 第一轮标注”未抓到原文”，本轮补齐

第一轮 01-system §6 的未竟事项。原文为上游标准 stage2 脚本，关键行：

s6-rc-compile -v"$cv" /run/s6/db "$etc/s6-overlay/s6-rc.d" /package/admin/s6-overlay-3.1.6.2/etc/s6-rc/sources
s6-rc-init -c /run/s6/db /run/service
…
s6-rc -v$v -u -t "$timeout" -- change "$top"   # $top = bundle "user"（s6-overlay 默认目标）

即：服务数据库由 /etc/s6-overlay/s6-rc.d（镜像内服务源定义）+ s6-overlay 自带 sources 编译而成，随后把 user bundle 拉起。S6_BEHAVIOUR_IF_STAGE2_FAILS、S6_STAGE2_HOOK、S6_CMD_WAIT_FOR_SERVICES_MAXTIME（默认 5000ms）等扩展点均存在但沙箱未注入 hook。配套 rc.shutdown（133 字节）仅 exec s6-rc -v$v -bda change。

1.4 服务定义：/etc/s6-overlay/s6-rc.d 全量原文

源目录 9 个条目；运行时编译结果 /run/s6-rc/servicedirs/ 实证为 7 个真实服务 + s6rc-fdholder/s6rc-oneshot-runner（s6-rc 内部件）。user 是 bundle（contents.d = browser-guard、envd、kasmvnc、kernel-server、portal、socat、sshd）；user2 是空 bundle（contents.d 目录为空——与第一轮”user2 bundle 为空”一致）；sshd 是 longrun，run 仅一行 exec /usr/sbin/sshd -D -e。

六个关键服务 run 脚本全文已采，要点与新增证据：

服务run 脚本要点本轮新增/确认
browser-guards6-svwait -u /run/service/kasmvnc 等显示就绪 → s6-setuidgid kimi python3 /app/browser_guard.py --wait-display --display :99 --timeout 60 --monitor确认第一轮 05-browser 的描述；硬编码 DISPLAY=:99、HOME=/home/kimi
envd中文注释明写”AGS 不是 firecracker 环境，没有 MMDS…-isnotfc 让 envd 跳过一切 MMDS 行为”；带候选路径回退（/usr/local/bin→/usr/bin→PATH），找不到则 sleep infinity 降级确认第一轮 04-gateway；优雅降级模式（缺二进制不 crash 容器）值得注意
kasmvnc仅 exec /bin/bash /root/setup_kasmvnc.sh实际安装逻辑在镜像内 /root/setup_kasmvnc.sh（本轮未采，隧道已断）
kernel-serverWORKDIR=${KERNEL_SERVER_WORKDIR:-/mnt/agents}，s6-setuidgid kimi python3 /app/kernel_server.py --host 0.0.0.0 --port 8888确认第一轮 02-runtime；workdir 即 drive9 挂载点，故模型写的文件直接落项目工作区
portal见下方全文级摘录本轮最高价值新证据
socatexecline 单行：python3 /opt/moonbox-project-template/bin/project-cdp-proxy.py确认第一轮 04-gateway 的”socat 不跑 socat，实为 CDP 代理”

portal/run 全文要点（新证据）：

# Go portal overlay service (bind-token STS contract). Boots with an EMPTY
# mount manifest and -http-bind (:8080): kimiwarden delivers the identity at
# claim time — POST /api/v1/bind_token (warden-signed HS256 JWT that portal
# exchanges for scoped STS via kimiapi PortalService), then POST /api/v1/bind
# with the overlay manifest (skills/plugins/auth/vault). drive9 keeps the
# writable workspace at /mnt/agents; the reception preset init_script symlinks
# /app/.user/skills etc. into this mount when the overlay is enabled.
  • 启动开关双通道：KIMI_PROJECT_PORTAL_CAPABILITY_ENABLED=true（新契约）或遗留 KIMI_PROJECT_PORTAL_OVERLAY=1，两者皆无则 exec sleep infinity 空转。
  • 默认 env=dev（KIMI_PROJECT_PORTAL_CAPABILITY_ENV 未注入时）：注释写明内置默认网关 dev=https://kimi.kimi.team/apiv2、prod=https://kimi-api-sandbox.msh.team/apiv2；生产沙箱里由 kimiwarden 注入 -env prod（第一轮 ps 实证）。
  • 支持 KIMI_CANARY 灰度参数（-canary）。
  • *“Static K_OSS_ credentials are retired (the new portal fails closed on them)” —— 静态 OSS 凭证已废弃，portal 对旧凭证失败关闭**；授权完全走 claim 时 bind-token → STS 交换。这佐证了第一轮”两阶段生命周期、凭证延迟绑定”的核心结论。
  • 挂载点默认 /mnt/portal-overlay，可被 KIMI_PROJECT_PORTAL_CAPABILITY_MOUNT 覆盖。

1.5 对第一轮的修正/确认（启动链部分）

  • 确认：01-system §3.1 引导链结论全部与原文一致；/init、stage0、rc.init 均为上游原版。
  • 补齐：rc.init、rc.shutdown、stage0 原文入档（第一轮 §6 未竟事项勾销）。
  • 新发现：portal/run 注释是第一手的设计自述（bind-token STS 契约、K_OSS_* 废弃并 fails-closed、dev/prod 双网关地址、灰度开关），比第一轮从 ps 反推的信息更完整。

2. backend-building-swarm 完整补采（任务②）

第一轮 09-skills-d §5 标注”目录清单未采”。本轮补齐。

2.1 完整文件清单

backend-building-swarm/
├── .gitignore
├── SKILL.md                      （约 350 行，全文已采）
├── docs/
│   ├── Authentication.md         242 行
│   ├── Database.md               381 行
│   ├── Development-Guide.md      260 行
│   ├── Post-Init-Wiring.md        38 行
│   ├── Project-Structure.md      147 行
│   └── tRPC.md                   161 行
└── scripts/
    ├── .prepare-template.sh        7 行（镜像构建期 npm install）
    ├── init.sh                   674 行（核心 graft 脚本，全文已读）
    ├── lib/                      9 个 Node 补丁器：
    │   ├── merge-package-json.mjs / merge-schema.mjs / merge-tsconfig.mjs
    │   ├── patch-boot-auth.mjs / patch-env-ts.mjs / patch-router-auth.mjs / patch-vite-config.mjs
    │   └── wire-app-tsx.mjs / wire-main-tsx.mjs
    └── template/                 base/ + db/ + auth/ 三层模板树 + node_modules/（预构建，大小未采）+ package.json + package-lock.json

2.2 SKILL.md 输入输出契约与工作流程

  • 定位：swarm 体系”制品层”后端件，嫁接 tRPC 11 + Drizzle ORM + Hono + MySQL + Kimi OAuth 到既有 webapp-building-swarm 前端上；显式声明依赖 swarm-workspace 的双层文件系统契约且不重复陈述（技能间引用关系：swarm-workspace/SKILL.md 是单一事实源）。
  • 输入：PROJECT_PATH（默认 /mnt/agents/output/app，swarm 流程中必须指向主代理的 $HOME/app-backend worktree）、APP_TITLE、--features db,auth（默认 auth）或 --template（互斥）。
  • 输出：就地修改 worktree（新增 api/、contracts/、可选 db/），写 .env（gitignored），在当前分支 commit；不建 worktree、不 merge（编排者职责）。
  • 双执行路径：--features 走完整嫁接（拷文件 + 9 个 mjs 补丁器改 vite/tsconfig/package.json/schema/router/boot/env + portal 开户 + 自动接线 main.tsx/App.tsx）；--template 面向全栈模板（zip 已铺好文件），只做 portal 开户 + 写 .env + npm install。由 .backend-features.json manifest 自动识别。
  • .env 传递设计的完整闭环（SKILL.md + init.sh 注释互证）：init.sh 写的 .env 是 gitignored，不随 merge 走，所以嫁接必须由主代理亲自跑（子代理沙箱里的 .env 会随沙箱销毁而 stranded）；跑完手工 cp $HOME/app-backend/.env /mnt/agents/output/app/.env 暂存进共享仓（gitignore 内），之后 setup-local.sh 的 ENV_SRC 默认从那里复制进每个新 worktree——用”git 不管的文件 + 显式复制管道”解决密钥跨 ephemeral 沙箱传递。

2.3 init.sh（674 行）逻辑详解

  1. 错误陷阱即用户沟通：trap … ERR 的报错文案是”abort the current task and let the user provide feedback to Kimi”——脚本把 LLM 当操作员，失败时引导 agent 向用户求助而非盲目重试。
  2. 参数/特性解析：--features 经 resolve_features() 做依赖闭包（auth 自动含 db）+ 去重 + 未知特性硬报错。
  3. 幂等门禁：.backend-features.json（version/features/app_id/initialized_at）为权威状态；首次运行装 base，重入只装 delta（NEW_FEATURES 差集），delta 为空直接 exit 0。无 manifest 但存在 api/ 的”遗产项目”会被探测（检查 db/schema.ts、drizzle.config.ts、api/kimi/）并回溯补写 manifest——迁移路径都想好了。
  4. git 安全：safe.directory 自动加白；用 -e 而非 -d 探测 .git（兼容 worktree 的 .git 文件）；有未提交改动先自动 wip: save changes 提交，绝不丢用户代码。
  5. 文件铺设纪律：safe_copy()（目标存在即跳过并记录到 SKIPPED_FILES 汇总报告）用于用户可扩展文件（schema.ts、seed.ts、connection.ts、drizzle.config.ts）；graft 自有的 auth UI（Login.tsx、useAuth.ts、AuthLayout*）用 cp 权威覆盖（注释：这是唯一事实源）；NotFound.tsx 用 cp -n 让位（共享领土）。三种拷贝语义对应三种所有权——非常精细的”哪些文件归框架、哪些归用户”模型。
  6. portal 开户：POST ${PORTAL_URL:-http://localhost:8080/api/v1/apps} body {"name":标题,"features":[...]}，期望返回 {app_id, app_secret, credentials:{KEY:value}}；有非 JSON 响应防护（502/proxy 错误页会先把 node 解析炸成 SyntaxError，脚本显式预检 JSON 合法性再给可读报错）。凭据写成 .env（APP_ID/APP_SECRET + 派生 VITE_APP_ID/VITE_KIMI_AUTH_URL + portal 下发的 feature 凭据如 DATABASE_URL/KIMI_AUTH_URL/KIMI_OPEN_URL）。
  7. 依赖安装：首跑/template 模式先把 template/node_modules（预构建）整树 cp -r 覆盖，再 npm install --prefer-offline 增量对齐——冷启动零下载的同一手法（与 webapp-building-swarm 一致）。
  8. 自动接线：wire-main-tsx.mjs 把 TRPCProvider 包进 <BrowserRouter> 内层（顺序写死：StrictMode→BrowserRouter→TRPCProvider→App）；auth 时 wire-app-tsx.mjs 加 /login 和 * 路由；失败降级为 WIRING_TODO 清单 + 指向 docs/Post-Init-Wiring.md（38 行人工兜底文档）。
  9. commit 语义化收尾：三种 commit message 区分 provision/graft/add-features；结尾打印分支名并提醒”Swarm: the main agent merges this branch”。

2.4 docs/ 六篇要点

  • Project-Structure.md：目录树 + 三个 import alias 纪律（@/=src 仅前端、@contracts/ 双向、@db/ 仅 api——@/db/schema 是错的）。
  • Authentication.md：OAuth 2.0 授权码流 + JWT session（1 年）+ 首登 upsert 自动开户（无注册流程，注册 CTA 一律指向 LOGIN_PATH）；Login.tsx 全文内嵌并声明”禁止自写登录页”；admin 由 OWNER_UNION_ID（portal 返回的 creator_user_id）首登匹配授予；三级 procedure（publicQuery/authedQuery/adminQuery）。
  • Database.md：Drizzle + mysql2，getDb() 懒连接；MySQL 无 .returning() 用 .$returningId()；禁裸 SQL。
  • tRPC.md：按 feature 分 router 注册进 api/router.ts；Zod input 校验强制；superjson 序列化（Date↔string 坑，$inferSelect 对齐）。
  • Development-Guide.md：schema→queries→router→页面 的端到端加特性范例。
  • Post-Init-Wiring.md：自动接线失败时的两步手工兜底。

2.5 工程质量亮点与坑

亮点：三态拷贝所有权模型；manifest 门禁 + 遗产探测；把”为什么主代理必须亲自跑 graft”写成注释（.env gitignored 的因果链）；门户非 JSON 防护；WIRING_TODO 降级而非失败。 坑/耦合：portal :8080、Kimi OAuth、MySQL、superjson、mshtools-website_version_manager 全是平台耦合点；docs/ 与 template/ 之间有知识重复（SKILL.md 的 Common Mistakes 与 docs 部分重叠，维护双份）；技术栈完全锁死（React19/Vite7/tRPC11/Drizzle/MySQL），离开 Kimi 平台等于重写模板树。

3. 两个”后半段未采”长技能补齐（任务③）

第一轮 09-skills-d §5 标注的两个：trading-strategy-backtest（L120 之后）与 xlsx/SKILL.md（L130 之后）。本轮均已全文补齐。

3.1 trading-strategy-backtest L120–543（全文 543 行）

后半段是纯执行纪律与输出契约，信息密度最高的新增内容：

  • On-Demand Loading 表：13 个 reference 文件逐一标注加载时机与强制性——pitfalls/pandas.md 和 common_pitfalls.md 是强制读，dashboard_template.html 则明令禁止读（”2000+ 行 CSS/JS 是给浏览器的，代码只需 open+replace”）——对上下文预算的精细管控。
  • 策略回测 vs 事件研究的一阶分流表：事件研究无资金概念、默认无费率（否则平均收益失真）、指标是事件级（均值/中位数/胜率/最好最坏事件）而禁止报 Sharpe/年化/最大回撤。
  • 硬规则细化：signal_time <= order_time <= fill_time 的不等式判据；脚本头契约（文件顶部必须声明 SIGNAL_TIMING/EXECUTION_TIMING/EXECUTION_NOTE）；enter_when_flat assert 模板原文；lot 级 helper 完整签名参考（buy_lot/close_lots_fifo/close_lot/compute_lot_equity + aggregate 路径三个函数）——调用者只看签名表，出错或扩展才读源码。
  • Warmup vs 评估窗：数据加载起点 = 评估起点 − max（指标窗口）×1.5（MA120→前 180 天）；warmup bar 可更新指标/计数器等纯历史状态但禁止产生交易/权益记录/pending 信号；export_results(start,end) 切片重算指标防 warmup 污染。
  • Self-Check 四步强制（不可跳过）：① 可操作性（.py 存在、cwd 可跑、三个产物文件存在）→ ② common_pitfalls 清单逐行 → ③ 常识校验 + 对抗评审（报警阈值表：Sharpe>3 / 年化>50% / 胜率>70% / 回撤=0 / 年交易<3 或 >252 都要找根因；对抗评审要求”假设代码里恰好有一个 bug”逐行四问；找不到也必须列出至少 3 个排查过并排除的疑点，否则重做）→ ④ 部署后 dashboard 自检（渲染完整性/内容合规/性能 >5MB 或 >5000 点必须降采样）。
  • 输出契约：三文件 <prefix>_equity.csv|_trades.csv|_summary.json（字段表精确到 meta/summary 的每个 key）；dashboard 三条 UI 铁律（一切 HTML 必须经 render_dashboard() + dashboard_template.html，手写导航页=无效产出）；最终回复 A/B/C 三段强制（实现细节/局限与偏差/结果解读），禁止罗列交付文件名，语言锁跟随用户 query。
  • 数据源纪律：行情优先 mshtools datasource；选股/宇宙优先 mshtools 内 ifind，禁止用沪深 300/500 当全市场代理。

3.2 xlsx L130–992（全文 992 行）

  • Xlsx CLI 六命令全契约（./scripts/Xlsx，C#/OpenXML 实现）：recheck（公式错误+零值单元格+隐式数组公式检测——LibreOffice 能算但 MS Excel 显示 #N/A 的 MATCH(TRUE(),range>0,0) 模式，给出 SUMPRODUCT 替代）、reference-check（越界引用/表头混入/聚合范围≤2 格/列内孤立公式四类模式异常）、inspect（结构→JSON）、pivot（唯一合法的透视表途径，自动配图，monochrome/finance 两主题）、chart-verify（空图表 exit 1）、validate（OpenXML Office2013 schema + 不兼容函数 + .rels 路径校验，不过=禁交付，且不许修只许重新生成）。
  • 逐 sheet 校验循环（违反=级联失败）：Plan→Create→Save→recheck+reference-check→0 错误才许做下一个 sheet；全部完成后 validate 终验。
  • 公式保真禁区表：FILTER/UNIQUE/SORT/XLOOKUP/LET/LAMBDA/SEQUENCE/RANDARRAY/ARRAYFORMULA/QUERY/IMPORTRANGE 等 12 个 Excel 365/2021+ 或 Google Sheets 专属函数全部禁用（兼容 Excel 2019 下限），每个给了传统替代。
  • Pivot 顺序铁律：openpyxl 建全部 sheet → pivot 命令收尾 → validate → 交付；openpyxl 再碰 pivot 产物=损坏 pivotCache。
  • 样式系统：隐藏网格线强制、B2 起始、双风格（Minimalist Monochrome 默认：黑白灰+唯一蓝色 accent；Professional Finance 财务用，含地区涨跌色约定表：中国红涨绿跌/国际绿涨红跌）、金融字体色规则（蓝=输入/黑=公式/绿=跨表引用/红=外部引用）、条件格式主动使用表（DataBar/ColorScale/IconSet 触发条件）、封面页强制（标题/关键指标/Sheet 索引/透视表刷新提示）。
  • 图表纪律：触发词（visual/chart/图）即必须产出真实嵌入图表，chart-verify 失败”没有任何借口”；禁止”数据 sheet + 让用户自己插入图表”。
  • 外部数据溯源：必须 Source Name|Source URL 两列或独立 Sources sheet，禁 HYPERLINK 函数。

4. 新沙箱实例差异核查（任务④）

核查项第一轮（旧实例）本轮（新实例）判定
/app/.agents/skills 数量269269（目录列表 href 计数，无 ../ 干扰项）一致
技能名称集合269 个（sections 06–09 四批清单）名称集合 diff：第一轮表格可提取的 254 个名字全部命中；表面差值 17 个逐一核对均为提取伪差（第一轮表格的”A / B-cn”合并写法如 retro-tech-illustration / -cn、或 prose 覆盖的 kimi-*/musepool 等在 REPORT 他章有记录）零实差
_meta.json 抽查kubectl/browse/edge-tts 等有同路径同内容（kubectl publishedAt=1769247843962 与第一轮记录一致）一致
/app/.user/skills6 个用户技能同名同 6 个：engineering-ppt-converter、lecture-notes-digitizer、openclaw-selfhost-ops、stem-exercise-solver、translation-review-coach、vocab-table-filler（frontmatter 抽查一致）一致
/root/.kimi/agent-gw.jsonkimi_chat_id=1a014098-*---*****15cb，api_key 前缀 sk-kimi-8OQEd910完全相同的 chat_id 与 key 前缀；整文件 sha256=983fd57b943c26bdad77a7b770d923221c1996d9e124b4bee6fa342f57dfb743（存档备比对）一致

结论：

  1. 技能库是镜像固定的，不是会话动态下发——新旧实例 269 个技能名称集合零差异，_meta.json 的 publishedAt 时间戳都与第一轮相同。动态层只有 portal overlay（.user/skills 按账号、.agents/plugins 按配置），与第一轮 11-user-layer 的三层模型吻合。
  2. agent-gw.json 不变说明这是同一 chat 重新 claim 了新沙箱（第一轮 03-storage §4 的”工作区可被不同 chat 复用/重新绑定”机制的反向实证：同一 chat 绑新沙箱时凭证原样重放），api_key 是长期凭证而非每次会话轮换。
  3. 新实例 /run/s6-rc/servicedirs/ 只含 7 基础服务 + s6-rc 内部件——drive9-fuse/watchdog 的确不进 s6-rc 编译库，而是 claim 后直接注入扫描目录（与第一轮 01-system 生命周期描述一致）。

5. _meta.json：ClawHub 元数据 schema（任务⑤）

5.1 Schema 确认（5 个全文样本）

格式为 4 字段 JSON，无嵌套：

{
  "ownerId": "kn79ajadezq44ydpssrcdgbytn7ztm19",   // Convex 风格文档 ID（kn7… 前缀），技能作者/上架者
  "slug": "kubectl",                                // 市场内的唯一标识
  "version": "1.0.0",                               // 市场上架版本（语义化）
  "publishedAt": 1769247843962                      // ms 时间戳（2026-01-24）
}

样本：kubectl（1.0.0）、browse（2.0.2，ownerId 指向 browserbase）、edge-tts（2.0.0）、imap-smtp-email（0.0.9）、email-manager（见下）。

5.2 关键发现：目录名与市场 slug 解耦

email-manager/_meta.json 的 slug 是 imap-smtp-email（ownerId、version、publishedAt 与 imap-smtp-email 完全相同）——即 email-manager 目录是 imap-smtp-email 技能的改名再分发克隆，_meta.json 原样保留。这与第一轮观察到的”cn-finance-data 原名 tushare-finance、chart-gen 原名 chart-image”互证：Kimi 导入流水线会重命名目录但不动市场元数据，_meta.json.slug 是追溯技能真实来源的最可靠字段（比目录名可靠）。 另外 edge-tts 目录除 _meta.json 外还有 skill-info.json、DISTRIBUTION.md、install.sh——市场分发包的去包痕迹未清理。

5.3 总数普查

最终结果：269 个技能目录中 31 个带 _meta.json——与第一轮报告的数字精确一致，再次坐实技能库镜像固定。

带 _meta.json 的 31 个技能完整名单（括号内为已知来源线索）：

adhd-assistant、adhd-daily-planner、browse（browserbase）、chart-gen、chart-image、cn-finance-data（原 tushare-finance）、code-mentor、competitive-seo-intel、competitor-analysis、edge-tts、email-manager（slug=imap-smtp-email 的克隆）、email-to-calendar、fast-browser-use、gitlab-cli-guide、gitlab-cli-skills、imap-smtp-email、iso-27001-evidence-collection、k8s-cluster-ops、kubectl、playwright-scraper-skill（Simon Chan）、programming-tutor、r2-upload、rust-browser-pilot、seo-content-writer、seo-copywriting-guide、smart-web-scraper、speech-synthesis（原 edge-tts 的本地化版）、sun-path、sunlight-analysis、whatsapp-integration（Membrane）、xhs-note-creator。

特征：31 个 ≈ 技能库的 11.5%，几乎全部带第三方作者/市场来源痕迹，即”ClawHub/社区导入”子集；其余 238 个为 Kimi 一方自研或 Anthropic 生态搬运（无市场元数据）。

采集过程备注（防误读）：本普查先后有两轮后台 watcher 补跑曾得出”0 个”的错误结论并一度写入本节，根因是 shell 变量拼接 bug（$d_meta.json 被解析为未定义变量 d_meta 而非 ${d}_meta.json，导致 269 次探测全部打到 skills/.json 返回 404）叠加隧道抖动，均已作废；上表数字来自隧道稳定期的前台一次性普查，并以 kubectl 等 5 个样本的正反双向复核确认。

6. 第一轮结论修正/确认清单（汇总）

确认（证据加强）：

  1. 01-system §3.1 引导链：/init、stage0、rc.init 原文均为 s6-overlay 3.1.6.2 上游原版，零定制——推测升级为实证。
  2. 01-system 生命周期：”boot 空壳池 + claim 时注入”——portal/run 注释（EMPTY manifest 启动、bind_token STS、K_OSS_* 废弃 fails-closed）提供了第一手设计自述。
  3. 04-gateway “socat 实为 CDP 代理”、”envd -isnotfc 定制补丁”、05-browser “browser-guard 等 kasmvnc 就绪”——全部有 run 脚本原文坐实。
  4. 11-user-layer 三层模型：新实例技能集/用户技能/凭证三重一致，镜像固定 vs portal 动态的分界成立。
  5. 09-skills-d §2.4/§2.5 对 backend graft 的转述（Phase 4.5、.env 暂存机制）与 init.sh/SKILL.md 原文一致。

修正/补充：

  1. 09-skills-d §5 全部未竟事项勾销：trading-strategy-backtest 与 xlsx 全文补齐；backend-building-swarm 清单与全文补齐；_meta.json 全量普查完成（31 个，与第一轮一致，见 §5.3）。
  2. 01-system §6 “rc.init 未抓到”——已补，且内容与”标准行为推测”无出入。
  3. 细节修正：portal 默认 env 是 dev（kimi.kimi.team），生产靠 kimiwarden 注入 -env prod；第一轮只记录了 prod 进程态，未提 dev 默认值与 KIMI_CANARY 灰度参数。
  4. 新发现：_meta.json.slug 与目录名解耦（email-manager→imap-smtp-email），追溯来源应以 slug 为准。
  5. 新发现：backend-building-swarm 的 .backend-features.json manifest + 遗产项目探测 + 三态拷贝所有权模型，第一轮只提到了”目录清单缺失”，其幂等/增量设计深度超出当时估计。

7. 移植评估表（本轮涉及组件）

组件对 Hermes 价值对 Kimi Code 价值移植工作量硬依赖
portal/run 的 bind-token STS 模式（空 manifest 启动 + claim 时绑定）高：Hermes 多沙箱场景可直接借鉴”凭证延迟绑定 + fails-closed”中（Kimi Code 本地 CLI 无沙箱池，但插件按会话下发可参考）需重写（Go 服务 + 控制面配合）kimiwarden、PortalService、kimiapi 全闭源
s6-overlay 服务编排层（run 脚本模式：with-contenv/s6-setuidgid/s6-svwait/降级 sleep infinity）中：若 Hermes 沙箱要多服务编排，这套脚本范式即拷即用低（本地单进程为主）纯拷贝（脚本）s6-overlay 套件（开源）
backend-building-swarm 的 init.sh graft 机制（manifest 门禁/三态拷贝/补丁器/自动接线降级）高：任何”向现有项目注入模板代码”的 Hermes 技能都可复刻其幂等+所有权模型中：可改造为 kimi-code 的项目脚手架技能需重写（模板树是 Kimi 栈；机制可抽）portal :8080 开户 API、Kimi OAuth、MySQL；机制本身无依赖
swarm 体系的 .env 跨 worktree 传递设计（gitignore 边界 + 显式复制管道）高：多代理协作的密钥传递通用解低纯拷贝（思路）无
trading-strategy-backtest 后半段（Self-Check 四步/对抗评审/输出契约/dashboard 铁律）高：最完整的”防 LLM 量化回测翻车”prompt 工程样本， Hermes 数据分析类技能可直接引用中：可拆成独立的”回测纪律”技能需适配（mshtools/ifind 数据源调用换成自己的；accounting.py/render_dashboard.py 是文件资产可直接拷）mshtools 部署链路（dashboard deploy）；核心逻辑零依赖
xlsx 后半段（Xlsx CLI 六命令/逐 sheet 校验/禁区函数表/双风格系统）中：校验纪律与禁区表可直接借鉴；CLI 本身是二进制资产中：Kimi Code 若接 Excel 任务，禁区函数表+逐 sheet 校验是现成的质量门需适配（Xlsx CLI 是预编译 C#/OpenXML 二进制，xlsx/scripts/Xlsx 需从镜像提取；纯 prompt 部分可拷）Xlsx 二进制（闭源编译产物）；openpyxl/pandas
.backend-features.json manifest 模式中：Hermes 任何增量脚手架都可借鉴低纯拷贝（思路）无

8. 密钥与凭证记录（脱敏）

位置内容用途处置
/root/.kimi/agent-gw.jsonapi_key=sk-kimi-8OQEd910…（64 位后缀，仅记前缀）、kimi_chat_id=1a014098-****-…agent 回云端（agent-gw.kimi.com/coding）主凭证 + 会话身份已脱敏；整文件 sha256=983fd57b… 存档备比对
portal/run 注释dev/prod 网关地址（kimi.kimi.team/apiv2、kimi-api-sandbox.msh.team/apiv2）PortalService STS 交换端点公开端点，仅记录
init.sh 运行产物 .envAPP_ID/APP_SECRET/DATABASE_URL/KIMI_AUTH_URL 等由 portal 开户动态下发到各项目本轮未读到任何实际 .env 文件（worktree 内产物，采集时无活动项目）