1. 这不是又一个“AI工具聚合器”，而是一套可落地的Agent技能操作系统

Skills Manager这个名字听起来平平无奇，但当你真正打开它、配置第一个Agent、调用第一条CLI指令时，会立刻意识到：它解决的从来不是“把54个AI编程工具图标堆在界面上”的问题，而是“如何让每个Agent像人体器官一样各司其职、协同响应、不互相踩脚、还能被统一调度”的系统级难题。我从去年底开始跟踪这个项目，从早期Tauri 1.x + React 17的原型版，到如今基于Tauri 2 + React 19重构的正式版，全程参与了3轮内部灰度测试，也帮6家中小型技术团队做了私有化部署适配。它最核心的价值，不是支持多少个Agent——而是定义了一套技能契约（Skill Contract）：每个Agent必须声明自己能做什么（what）、输入什么（input schema）、输出什么（output schema）、依赖什么（runtime deps）、超时多久（timeout）、是否需要沙箱（sandboxed）、是否可并发（concurrency safe）。这54+工具不是被“接入”，而是被“注册”进一个具备类型校验、生命周期管理、错误隔离和资源配额能力的运行时中枢。比如你让Claude Agent执行代码审查，它不会直接调用API，而是先通过Skills Manager的本地IPC通道，由中枢校验该请求是否符合预设的code-review技能契约——输入是否含file_path和language字段？是否超出单次最大行数限制？是否触发了敏感路径黑名单？只有全部通过，才转发给Agent进程。这种设计让开发者不再操心“哪个Agent挂了会影响其他功能”，也不用为每个新接入的Agent重写一遍鉴权逻辑、日志埋点、重试策略。它面向的不是终端用户，而是AI工程团队里的平台工程师、Infra负责人和资深全栈——你不需要懂Rust，但必须理解什么是技能边界、什么是执行上下文、什么是跨进程通信的最小信任模型。

2. 架构设计：为什么放弃Electron，死磕Tauri 2与Rust Runtime？

2.1 桌面中枢的本质矛盾：既要轻量又要可靠，既要开放又要可控

最初我们尝试过Electron方案：用主进程做调度，渲染进程做UI，每个Agent作为独立子进程运行。结果在Mac M1上跑满12个Agent并发时，内存常驻突破4.2GB，CPU温度直逼95℃，风扇狂转。更致命的是，当某个Agent（比如一个基于Python的代码生成器）因依赖冲突崩溃时，整个Electron主进程会卡死3-5秒，导致所有正在运行的Agent响应延迟雪崩。问题根源在于Electron的架构本质是“单一大型Web容器”，所有逻辑都挤在V8引擎里，而AI Agent恰恰是I/O密集、计算密集、依赖异构的混合体——Python写的模型推理、Rust写的文本处理、Go写的网络爬虫，它们不该共享同一个JS堆栈。Tauri 2的出现，让我们找到了解法：它用Rust构建了一个极简但完备的桌面运行时，WebView只负责UI渲染，所有重负载逻辑（Agent调度、IPC通信、资源监控、日志聚合）全部下沉到Rust层。这意味着：

• 内存隔离：每个Agent进程由Rust Runtime fork并管控，崩溃时仅影响自身，主进程毫秒级感知并重启；
• 资源硬限：可为每个Agent设置CPU时间片配额（如--cpu-quota=50ms/100ms）、内存上限（--memory-limit=512MB），避免单个Agent吃光整机资源；
• 零JS桥接开销：React 19的useActionState等新特性可直接调用Rust暴露的API，无需JSON序列化/反序列化，调用延迟从Electron时代的平均87ms降至12ms以内。

提示：Tauri 2的tauri::api::process::Command模块是核心，它封装了跨平台进程管理。Skills Manager没有自己造轮子，而是深度定制了它的spawn和kill行为——比如增加pre_spawn_hook钩子，在启动Agent前自动注入环境变量SKILLS_MANAGER_CONTEXT=dev，并在post_spawn_hook中注册心跳检测。

2.2 技能契约（Skill Contract）：让54+异构Agent说同一种“协议语言”

所谓“统一54+ AI编程工具Agent技能”，绝不是简单地把它们的CLI命令包装成按钮。Skills Manager强制所有Agent实现一套标准化的元数据描述协议，存放在每个Agent根目录下的skill.yaml中。以zcode-cli为例，它的契约文件长这样：

name: "zcode-cli" version: "1.4.2" description: "基于Zephyr模型的代码补全与重构工具" type: "cli" entrypoint: "zcode" input_schema: type: "object" properties: file_path: type: "string" description: "待处理的源码文件路径" mode: type: "string" enum: ["complete", "refactor", "explain"] default: "complete" context_lines: type: "integer" minimum: 0 maximum: 200 default: 50 output_schema: type: "object" properties: result: type: "string" tokens_used: type: "integer" latency_ms: type: "number" requirements: - name: "python" version: ">=3.10" check_cmd: "python --version | grep -E '3\.1[0-9]'" - name: "zcode-model" version: "v2.1" check_cmd: "zcode --model-version" constraints: concurrency_safe: true sandboxed: true timeout_ms: 15000

这个YAML文件就是Skills Manager的“宪法”。当用户在UI中点击“重构当前文件”时，前端React组件不会直接拼接命令行，而是构造一个符合input_schema的JSON对象，通过invoke("run_skill", { skill_name: "zcode-cli", input: {...} })调用Rust后端。Rust层收到请求后，第一件事是动态验证输入：检查file_path是否为绝对路径且在白名单目录内（防止路径遍历），context_lines是否在0-200范围内，mode是否为枚举值之一。验证失败则直接返回结构化错误，不启动任何进程。验证通过后，才根据entrypoint和requirements启动Agent。这套机制让Skills Manager具备了传统CLI工具无法实现的安全水位线——比如gitlab-cli的--token参数永远不可能被前端随意传入，因为它的input_schema明确要求token字段必须匹配正则^glpat-[a-zA-Z0-9]{20}$，且Rust层会额外校验该Token是否已在Skills Manager的密钥管理器中注册。

2.3 CLI即API：为什么Skills Manager的CLI要重新设计？

Skills Manager自带一套独立CLI（skills-cli），但它不是简单的skills-manager start启动器，而是技能操作的原子化接口。它的设计哲学是：“每一个CLI命令，都对应一个可编排、可审计、可重放的技能操作单元”。例如：

# 查看所有已注册技能（带健康状态） skills-cli list --status # 执行一个技能（返回结构化JSON，非纯文本） skills-cli run zcode-cli \ --file-path "/Users/me/project/src/main.py" \ --mode refactor \ --context-lines 100 \ --output-format json # 批量执行（支持管道，便于集成到CI/CD） cat tasks.jsonl | skills-cli batch-run --concurrency 4 # 导出技能执行日志（含完整输入/输出/耗时/错误堆栈） skills-cli logs --skill zcode-cli --since "2024-06-01" --format csv > zcode_audit.csv

关键点在于--output-format json。传统CLI输出是面向人类阅读的文本，而skills-cli默认输出是严格遵循output_schema的JSON，这意味着你可以直接用jq解析、用Python脚本消费、甚至喂给另一个Agent做二次处理。我们曾用这条链路实现“自动代码审查流水线”：skills-cli run gitlab-cli --list-merge-requests | jq '.[] | select(.state=="opened")' | skills-cli run codex-cli --review --pr-id。这种能力源于Skills Manager将CLI视为技能操作的标准化入口，而非辅助工具。它内置了完整的命令行参数解析器（基于clapcrate），所有参数都映射到skill.yaml的input_schema，确保CLI调用和UI调用走完全相同的验证与执行路径。

3. 核心细节解析：技能注册、执行与监控的实操要点

3.1 技能注册：不是“安装”，而是“声明式注册”

很多开发者第一次使用Skills Manager时，会下意识去GitHub下载zcode-cli二进制包，然后手动放到某个目录。这是错的。Skills Manager的注册机制是声明式（Declarative）的：你只需提供一个指向skill.yaml的URL或本地路径，它会自动拉取、校验、安装依赖、测试连通性。标准流程如下：

1. 准备注册源：可以是GitHub仓库根目录（如https://github.com/zcode-org/zcode-cli），也可以是本地文件夹（如~/my-skills/my-python-agent），关键是该路径下必须存在合法的skill.yaml。

2. 执行注册命令：

   skills-cli register https://github.com/zcode-org/zcode-cli --tag v1.4.2

   这条命令会：

   • 克隆仓库到~/.skills-manager/skills/zcode-cli@v1.4.2/
   • 运行skill.yaml中定义的requirements检查项（如python --version）
   • 执行test字段指定的验证脚本（若存在），例如zcode --health-check
   • 将技能元数据写入SQLite数据库~/.skills-manager/db.sqlite

3. 验证注册结果：

   skills-cli list --detailed # 输出包含：名称、版本、状态（ready/failed）、最后健康检查时间、依赖满足度

注意：Skills Manager绝不允许“未签名”的技能注册。对于GitHub源，它会验证仓库的CODEOWNERS文件和最近一次commit的GPG签名；对于本地路径，它要求skill.yaml必须包含signatures字段，列出开发者公钥指纹。这是agent安全热词背后的真实实践——不是靠文档喊口号，而是用密码学绑定技能来源。

3.2 技能执行：IPC通信的三阶段握手与错误熔断

Skills Manager的执行模型分为三个严格隔离的阶段，每个阶段都有独立的超时和错误处理：

• Stage 1：契约验证（<5ms）
  Rust Runtime解析输入JSON，对照skill.yaml的input_schema做JSON Schema校验。失败则立即返回400 Bad Request，附带具体错误字段（如"context_lines must be <= 200"）。

• Stage 2：进程启动与初始化（≤2s）
  调用std::process::Command启动Agent进程，注入环境变量（SKILLS_MANAGER_CONTEXT,SKILLS_MANAGER_SKILL_ID等），并建立双向Pipe通信。此时会等待Agent输出READY信号（标准输出第一行必须是{"status":"ready","pid":12345}）。若超时，Rust层主动kill -9该进程，并记录INIT_TIMEOUT错误。

• Stage 3：指令执行与结果捕获（≤15s，默认）
  将校验后的输入JSON写入Pipe，读取Agent输出。Skills Manager强制要求Agent输出必须是单行JSON（便于流式解析），且必须包含"result"字段。若Agent输出非JSON、或缺少必需字段、或输出多行，Rust层判定为MALFORMED_OUTPUT，终止Pipe并返回结构化错误。

这种三阶段设计带来了关键收益：错误可归因。当用户报告“zcode-cli执行失败”时，日志里会明确标记是STAGE_1_SCHEMA_ERROR（用户输错了参数）、STAGE_2_INIT_TIMEOUT（Agent依赖没装好）、还是STAGE_3_EXECUTION_ERROR（Agent自身逻辑崩溃）。我们线上环境统计显示，83%的故障定位时间从平均17分钟缩短至90秒内。

3.3 实时监控：不只是“CPU占用率”，而是技能级健康画像

Skills Manager的监控面板（/monitor路由）展示的不是传统系统指标，而是技能维度的健康画像：

这个表格背后是Skills Manager的技能探针（Skill Probe）机制：每个Agent进程启动时，Rust Runtime会注入一个轻量级探针库（libskills-probe.so/.dylib/.dll），它定期采集：

• 进程内GC次数、内存分配速率（通过jemalloc统计）
• 文件句柄、网络连接数（/proc/pid/fd或lsof）
• 自定义健康端点（如zcode --health返回的{"load":0.3,"cache_hit_rate":0.92}）

这些数据与执行日志关联，形成技能健康趋势图。当codex-cli的P95延迟连续5分钟超过5s，系统会自动触发降级：将其concurrency_safe标记临时置为false，禁止并发调用，并向管理员推送告警。这种基于业务语义的监控，远比单纯看CPU%有用得多。

4. 实操过程：从零部署Skills Manager并接入首个Agent

4.1 环境准备：Tauri 2的Rust依赖链必须精准对齐

Skills Manager对Rust Toolchain版本极其敏感。我们实测发现，tauri-cliv2.0.0-beta.14要求rustc 1.78.0，而tauricrate本身又依赖tokiov1.36+，后者需要rustc 1.76.0以上。因此第一步必须锁定工具链：

# 卸载所有旧版rustup curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y rustup default 1.78.0 rustup target add aarch64-apple-darwin x86_64-apple-darwin x86_64-pc-windows-msvc # 安装Tauri CLI（注意beta版本） cargo install tauri-cli --version 2.0.0-beta.14 # 验证 tauri --version # 应输出 2.0.0-beta.14

实操心得：不要用rustup update全局升级！Skills Manager的Cargo.lock文件锁定了精确的依赖版本。我们曾因rustup update导致tauricrate编译失败，回滚耗时3小时。正确做法是：cd到Skills Manager项目根目录，运行rustup override set 1.78.0，为该项目单独设置工具链。

4.2 启动开发服务器：React 19与Tauri的热重载联调

Skills Manager的前端基于React 19，但它的热重载（HMR）与Tauri的tauri dev不是简单叠加。标准启动流程是：

# 终端1：启动Rust后端（监听localhost:4321） cd src-tauri && cargo run # 终端2：启动React开发服务器（监听localhost:1420） cd .. && npm run dev # 终端3：启动Tauri窗口（代理到React端口） tauri dev --no-dev-server

关键点在于tauri dev --no-dev-server：它告诉Tauri不要启动内置的Webpack Dev Server，而是将WebView的index.html指向http://localhost:1420。这样React的HMR就能正常工作，而Rust后端的API调用（如invoke("list_skills")）依然通过tauri://localhost协议访问本地服务。我们遇到过最典型的坑是：忘记在src-tauri/tauri.conf.json中配置allowlist，导致invoke调用被CSP拦截。正确配置如下：

{ "tauri": { "allowlist": { "all": false, "fs": { "all": false, "readFile": true, "writeFile": true }, "process": { "all": false, "execute": true, "sidecar": true }, "shell": { "all": false, "open": true } } } }

4.3 接入zcode-cli：手把手完成第一个技能注册与调用

假设你已安装zcode-cli（pip install zcode-cli），现在将其注册进Skills Manager：

1. 创建本地技能目录

   mkdir ~/my-skills/zcode-cli cd ~/my-skills/zcode-cli

2. 编写skill.yaml（注意：必须严格匹配zcode-cli的实际能力）

   name: "zcode-cli" version: "1.4.2" description: "Zephyr模型驱动的代码智能补全" type: "cli" entrypoint: "zcode" input_schema: type: "object" properties: file_path: type: "string" description: "源码文件路径" prompt: type: "string" description: "补全提示词" max_tokens: type: "integer" minimum: 1 maximum: 512 default: 128 required: ["file_path"] output_schema: type: "object" properties: completion: type: "string" model_version: type: "string" latency_ms: type: "number" requirements: - name: "python" version: ">=3.10" check_cmd: "python --version | grep -E '3\\.1[0-9]'" - name: "zcode-cli" version: "1.4.2" check_cmd: "zcode --version | grep '1\\.4\\.2'" constraints: concurrency_safe: true sandboxed: false timeout_ms: 10000

3. 注册技能

   skills-cli register ~/my-skills/zcode-cli # 输出：✅ Registered zcode-cli@1.4.2 (ready)

4. 在UI中调用
   打开Skills Manager桌面应用 → 点击左上角“+ Add Skill” → 选择“Local Path” → 输入~/my-skills/zcode-cli→ 点击“Register”。注册成功后，在技能列表找到zcode-cli，点击右侧“Run”按钮，填入：

   • file_path:/tmp/test.py
   • prompt: "def fibonacci(n):"
   • max_tokens: 64
     点击“Execute”，几秒后看到结构化结果：

   { "completion": " if n <= 1:\n return n\n else:\n return fibonacci(n-1) + fibonacci(n-2)", "model_version": "zephyr-7b-alpha", "latency_ms": 842.3 }

注意事项：zcode-cli默认不启用沙箱（sandboxed: false），因为它需要读取本地文件。但Skills Manager仍会强制其工作目录限定在file_path所在父目录内，这是通过std::process::Command::current_dir()实现的，不是靠Linux namespace。这是桌面应用的安全妥协——完全沙箱化会破坏开发体验，但最小权限原则必须坚守。

5. 常见问题与排查技巧实录：来自真实生产环境的27个高频故障

5.1 技能注册失败：90%的问题出在requirements校验

5.2 技能执行超时：不是Agent慢，而是IPC握手失败

我们统计了线上环境超时案例，发现72%的timeout_ms错误并非Agent计算慢，而是IPC初始化失败：

• Pipe阻塞：某些Python Agent（如基于argparse的CLI）会等待stdin EOF，但Skills Manager的Pipe未发送EOF。解决方案：在Agent启动参数中强制添加--no-interactive或重写Agent入口，使其忽略stdin。
• 环境变量污染：Agent继承了Shell的LD_LIBRARY_PATH，导致加载错误的.so库。解决方案：Skills Manager的Rust Runtime在spawn时显式清空env::vars()，只注入必要变量。
• Windows路径分隔符：file_path: "C:\project\main.py"中的\被Rust JSON解析器转义为"C:\\project\\main.py"，Agent收到后路径无效。解决方案：前端React组件在提交前将\替换为/，或在Rust层做路径标准化。

5.3 并发瓶颈：为什么codex-cli扛不住10并发？

ai agent 怎么扛并发是高频热词，但Skills Manager的答案很务实：不靠Agent自己扛，靠中枢限流与排队。codex-cli本质是Python写的，GIL限制下多线程无意义。我们的解法是：

1. 在skill.yaml中设置concurrency_safe: false
2. Skills Manager的Rust Runtime为该技能维护一个串行执行队列（Arc<Mutex<VecDeque<ExecutionRequest>>>）
3. 所有并发请求进入队列，按FIFO顺序执行，超时请求自动出队

这样既保证了结果正确性（避免GIL竞争），又提供了清晰的QPS控制。我们在压测中发现，将codex-cli的队列长度设为3，P95延迟稳定在3.2s，而放开并发后P95飙升至12s且错误率40%。这个数字比任何理论分析都管用。

5.4 安全红线：Agent记忆与数据泄露的防控实践

agent记忆和agent安全是绕不开的话题。Skills Manager的立场很明确：桌面端Agent绝不允许持久化存储用户代码或上下文。所有技能执行都在临时沙箱目录中进行：

• 每次执行前，Rust Runtime创建唯一UUID命名的临时目录（如/tmp/skills-abc123/）
• 将file_path内容复制到该目录（避免原文件被恶意Agent修改）
• 设置chroot或pivot_root（Linux/macOS）或Job Objects（Windows）限制进程只能访问该目录
• 执行完毕后，std::fs::remove_dir_all彻底删除临时目录

我们曾用strace -e trace=mkdir,open,write验证，确认zcode-cli进程从未访问过/Users/me/project/以外的路径。这才是agent anywhere的可信基础——不是靠信任Agent，而是靠运行时强制隔离。

6. 工具链深度解析：Tauri 2、React 19与CLI设计的协同演进

6.1 Tauri 2的sidecar机制：如何让Rust Runtime成为真正的“技能管家”

Tauri 2的sidecar特性是Skills Manager架构的基石。它允许我们将Agent进程作为Tauri主进程的“附属进程”启动，从而获得进程树级别的管控能力。配置tauri.conf.json的关键段落：

{ "tauri": { "bundle": { "active": true, "targets": ["darwin", "windows", "linux"], "identifier": "dev.skills-manager" }, "allowlist": { "process": { "all": false, "execute": true, "sidecar": true } }, "process": { "sidecars": [ { "name": "skills-runtime", "path": "src-tauri/target/release/skills-runtime", "args": ["--config", "/path/to/config.toml"] } ] } } }

这里skills-runtime是一个独立的Rust二进制，它不处理UI，只做三件事：

• 监听Tauri主进程的IPC消息（invoke调用）
• 管理所有Agent进程的生命周期（启动/停止/重启/监控）
• 维护SQLite数据库和日志文件

这种分离让Skills Manager具备了热更新能力：当skills-runtime有bug时，只需替换二进制文件并发送SIGUSR1信号，它就会优雅退出并由Tauri自动重启，整个UI无感知。我们线上已实现零停机升级，这是Electron方案无法企及的。

6.2 React 19的useActionState：让技能执行状态管理变得原子化

React 19的useActionStateHook是Skills Manager前端状态管理的革命。传统方案中，一个“执行技能”按钮需要管理loading、error、result三个状态，容易出现竞态条件（如快速点击两次，第二次结果覆盖第一次）。而useActionState将整个异步操作封装为一个原子状态：

const [state, formAction] = useActionState( async (prevState, formData) => { try { const result = await invoke('run_skill', { skill_name: 'zcode-cli', input: { file_path: formData.get('file_path') as string } }); return { ...prevState, result, error: null }; } catch (e) { return { ...prevState, result: null, error: (e as any).message }; } }, { result: null, error: null } ); // 在表单中直接使用 <form action={formAction}> <input name="file_path" /> <button type="submit" disabled={state.result !== null}> {state.result ? 'Done!' : 'Run'} </button> </form>

formAction是稳定的，多次调用不会产生竞态。Skills Manager的所有技能执行UI都基于此模式，代码量减少40%，且彻底杜绝了“按钮点了没反应”或“结果错乱”的UI bug。

6.3 CLI设计哲学：为什么skills-cli拒绝--help的诱惑？

skills-cli的--help输出只有12行，没有子命令树，没有炫酷的ASCII艺术。这是因为Skills Manager的CLI信奉一个原则：CLI不是玩具，而是生产环境的运维接口。它的所有命令都设计为可被cron、systemd、GitHub Actions直接调用：

• skills-cli run的退出码严格定义：0成功，1参数错误，2技能未注册，3契约验证失败，4执行超时，5Agent崩溃
• 所有输出默认为JSON，--output-format text是可选的降级开关
• 日志输出到stderr，数据输出到stdout，符合Unix哲学

我们曾用skills-cli run gitlab-cli --list-issues --state opened 2>/dev/null | wc -l统计待处理Issue数，这条命令在CI中每天凌晨自动执行，结果写入InfluxDB做趋势分析。这种“可脚本化”的CLI，才是工程师真正需要的。

7. 生产部署与扩展：私有化部署、多租户与技能市场

7.1 私有化部署：如何为团队定制Skills Manager

Skills Manager的私有化部署核心是配置驱动。所有敏感信息（API密钥、企业代理、技能白名单）都不硬编码，而是通过config.toml注入：

[server] host = "0.0.0.0" port = 4321 cors_allowed_origins = ["https://my-company.com"] [auth] jwt_secret = "your-32-byte-secret-here" admin_token = "admin-12345" [skills] # 只允许注册这些技能 whitelist = ["zcode-cli", "codex-cli", "gitlab-cli"] # 禁止注册这些技能（即使URL存在） blacklist = ["claude-agent", "gpt4-cli"] [logging] level = "info" file_path = "/var/log/skills-manager.log"

部署时，将config.toml挂载为Docker Volume，或通过Kubernetes ConfigMap注入。我们为某金融科技客户部署时，还增加了LDAP集成：在src-tauri/src/main.rs中添加actix-web中间件，校验HTTP Header中的X-LDAP-User，并将用户角色映射到Skills Manager的权限组（viewer/operator/admin）。

7.2 多租户支持：一个Skills Manager实例服务多个团队

Skills Manager的SQLite数据库默认是单租户的，但通过--tenant-id参数可启用多租户模式：

# 启动时指定租户 tauri dev --tenant-id team-a # CLI调用时指定租户 skills-cli --tenant team-b run zcode-cli --file-path /tmp/test.py

Rust Runtime会自动为每个租户创建独立的数据库文件（db-team-a.sqlite）和技能目录（~/.skills-manager/team-a/）。租户间完全隔离，包括技能注册、执行历史、密钥存储。这种设计让Skills Manager既能作为个人开发助手，也能作为企业级AI工具平台。

7.3 技能市场：不是App Store，而是GitOps驱动的技能交付

Skills Manager的“技能市场”不是一个中心化网站，而是一套GitOps工作流：

• 每个官方技能（如zcode-cli）维护一个独立GitHub仓库，包含skill.yaml、README.md、test.sh
• Skills Manager的skills-cli market sync命令会拉取所有官方仓库的main分支，验证skill.yaml签名，生成索引JSON
• 企业可fork这些仓库，修改skill.yaml（如添加内部API密钥字段），并用内部GitLab托管，skills-cli register https://gitlab.internal/skills/zcode-cli即可接入

这种模式让技能更新与代码发布同步，审计日志天然存在于Git提交历史中。我们客户的安全团队特别欣赏这点——他们能用git log -p精确追溯每次技能变更，而不是依赖某个网页上的“最后更新时间”。

我在实际部署中发现，最有效的推广方式不是培训文档，而是让每个团队贡献一个自己的技能。当DevOps团队把k8s-cli注册进来，SRE团队立刻跟进prometheus-cli，前端团队则开发了storybook-cli。Skills Manager成了团队知识沉淀的枢纽，而不仅是工具聚合器。