1. 从一个空输入框说起：OpenShell 到底在解决什么问题
第一次看到 "OpenShell" 这个词，很多人会下意识地把它和某个具体的命令行工具、某个终端模拟器，或者某个开源项目的安装包联系在一起。但如果你真的去翻一遍当前能查到的公开资料，会发现一个很有意思的现象：关于它的描述几乎是空白的，没有官方文档，没有 GitHub 仓库的明确指向，也没有一篇像样的技术博客把它讲清楚。这种"名字存在但内容缺失"的状态，恰恰是我想写这篇东西的起点。
我在实际工作中遇到过太多次类似的情况：一个概念被反复提及，但真正落地时，大家各说各话。有人以为 OpenShell 是一个跨平台的远程终端方案，有人觉得它是某种容器化环境下的交互入口，还有人把它当成一个"打开就能用"的通用命令行框架。这些理解都不算错，但都不完整。OpenShell 的核心价值，不在于它本身是一个多么复杂的系统，而在于它提供了一种"把分散的执行环境统一到一个可交互入口"的思路。换句话说，它解决的是"我有一堆零散的命令、脚本、工具，怎么用一个统一的壳把它们串起来"这个问题。
这篇文章适合三类人看：第一类是对命令行工具链感兴趣、想自己搭一套顺手工作流的人；第二类是在多环境（本地、容器、远程主机）之间来回切换、被各种终端窗口搞晕的人；第三类是单纯被 "OpenShell" 这个词吸引、想搞清楚它到底能干什么的人。我会从概念拆解、核心机制、实操搭建、常见坑点、进阶扩展几个角度，把这件事讲透。需要提前说明的是，由于公开资料有限，文中涉及的具体实现细节，我会基于"一个合格从业者在面对这类需求时最可能采用的合理方案"来补全，并明确标注哪些是通用实践、哪些是我的个人经验。
先给一个最朴素的定义：OpenShell 可以理解为一个"壳层抽象"——它不生产命令，它只是命令的搬运工和调度员。你手头可能有 Python 脚本、Shell 脚本、Node 工具、甚至是一些编译好的二进制程序，它们各自有自己的运行方式、参数格式、输出风格。OpenShell 要做的事情，就是给这些异构的东西套上一层统一的交互界面，让你不用记住每个工具的具体调用方式，而是通过一套相对一致的规则去触发它们。这个思路听起来简单，但真正做起来，涉及到环境隔离、参数解析、输出格式化、错误处理、会话保持等一系列问题。接下来我会一层一层拆开讲。
2. 拆解 OpenShell 的壳层抽象：它到底抽象了什么
2.1 命令入口的统一化：从"记命令"到"选动作"
大多数人使用命令行的方式是这样的：打开终端，敲一个命令，回车，看输出，再敲下一个。这个过程里，最耗心智的不是命令本身有多复杂，而是你要记住不同工具的不同调用约定。比如git用子命令，docker也用子命令，但kubectl的子命令层级更深，ffmpeg则是一堆短横线参数。当你需要在同一个任务里交替使用这些工具时，大脑要不断切换"语法模式"，这种切换成本在长时间工作后非常明显。
OpenShell 的第一个抽象层，就是把这些异构的命令入口统一成"动作"（action）。一个动作可以绑定到一个具体的命令、一段脚本、甚至是一个函数。你不需要关心底层是bash -c还是python -m，只需要知道"我要执行备份"这个动作，然后触发它。这种设计在自动化运维领域其实很常见，比如 Ansible 的 playbook、Makefile 的 target，本质上都是把命令包装成更高层的语义单元。OpenShell 的不同之处在于，它更强调"交互式"和"即时性"——你不是在写一个批量执行的脚本，而是在一个持续的会话里，随时调用这些动作。
我自己的做法是，把日常高频操作分成三类：查询类（看日志、查状态、列文件）、变更类（部署、重启、清理）、辅助类（格式化、转换、计算）。每一类下面挂若干个动作，动作名尽量用动词开头，比如check-log、deploy-app、clean-temp。这样在 OpenShell 里输入的时候，肌肉记忆会很快建立起来，比记原始命令快得多。
2.2 环境边界的模糊化：本地、容器、远程的同一张脸
第二个抽象层更有意思，也是 OpenShell 这个概念最吸引我的地方：它试图模糊执行环境的边界。传统上，你在本地终端敲命令，命令就在本地执行；你要进容器，得先docker exec；你要上远程主机，得先ssh。每换一个环境，你就换了一个"壳"。OpenShell 的思路是，把这些环境都注册成"后端"（backend），然后在前端用同一套动作去调用它们。
举个例子，你可以定义一个动作叫list-files，它默认在本地执行ls -la，但你可以加一个参数--env=container，让它自动切换到某个容器的上下文里执行。对使用者来说，动作名没变，参数格式没变，只是多了一个环境标识。这种设计在跨环境调试时特别有用。我以前排查一个线上问题时，需要在本地、测试容器、预发主机三个环境里反复执行同一组诊断命令，每次都要重新ssh或者docker exec，窗口开了一堆，最后自己都搞混了。如果有一个 OpenShell 层把这些统一起来，至少能省掉一半的窗口切换时间。
当然，这里有一个关键的技术难点：不同环境的文件系统、环境变量、权限模型都不一样。OpenShell 不可能完全屏蔽这些差异，它能做的是"尽量统一接口，但保留环境特有的配置入口"。比如本地环境可以直接读宿主机的~/.config，容器环境可能需要挂载一个配置卷，远程环境则需要通过某种通道同步配置。这些细节在实际搭建时都要考虑到，后面我会专门讲配置同步的坑。
2.3 输出流的归一化：让不同工具说同一种"普通话"
第三个抽象层是关于输出的。不同工具的输出格式千差万别：有的返回 JSON，有的返回纯文本表格，有的返回一堆带颜色的日志行。如果你要把这些输出串起来做后续处理，就得为每个工具写不同的解析逻辑。OpenShell 的野心是，在壳层做一次输出归一化，把结果统一成一种结构化格式（比如 JSON 或者带元数据的文本块），这样上层动作就可以用统一的方式消费。
这个思路在理论上很美好，但实操中要小心一个陷阱：过度归一化会丢失信息。有些工具的输出里，颜色、缩进、特殊符号本身就是信息的一部分（比如git diff的加减号、tree的树形结构）。如果你强行把它们压成 JSON，反而会破坏可读性。我的经验是，归一化只做"外层包装"，不做"内层改写"。也就是说，OpenShell 可以给输出加一层元数据（来源环境、执行时间、退出码、耗时），但原始输出内容尽量保持原样，除非用户显式要求结构化解析。这样既保留了灵活性，又提供了统一的消费入口。
2.4 会话状态的保持：别让每次执行都从零开始
最后一个抽象层是会话状态。传统的命令行里，cd到一个目录后，后续命令都在那个目录下执行；export一个变量后，后续命令都能读到。但一旦你切换到另一个环境（比如ssh到远程），这些状态就断了。OpenShell 如果要做真正的"统一壳层"，就必须解决会话状态的跨环境保持问题。
一个可行的方案是，在 OpenShell 内部维护一个"上下文栈"，记录当前的工作目录、环境变量、别名定义等。每次执行动作时，先把上下文注入到目标环境，执行完再把变更同步回来。这个机制听起来简单，但实现起来要考虑并发、冲突、持久化等问题。比如你在本地改了PATH，同时在容器里也改了PATH，合并的时候以谁为准？我的建议是，上下文分两层：全局层（所有环境共享的基础配置）和环境层（每个环境特有的配置），执行时环境层覆盖全局层，但全局层的变更会广播到所有环境。这样既能保持一致性，又能保留灵活性。
3. 为什么是"壳"而不是"框架"：设计取舍背后的逻辑
3.1 壳层的轻量性：不侵入现有工具链
市面上已经有很多"统一命令行"的方案，比如各种 CLI 框架、任务运行器、自动化平台。它们的功能通常比 OpenShell 更强大，但代价是侵入性也更强。你要用它们，往往得把现有脚本改写成它们规定的格式，或者引入一堆依赖。OpenShell 的定位不同，它更像是一个"外挂壳"，不要求你改变现有工具的使用方式，只是在外面包一层。
这种轻量性带来的最大好处是迁移成本低。你可以今天先包一个命令试试，明天再包一个，不需要一次性把所有东西都重构。我自己的习惯是，遇到一个反复要敲的长命令，就顺手在 OpenShell 里注册一个动作，日积月累，壳层越来越厚，但底层工具一个都没动。这种渐进式的建设方式，比一开始就设计一个大而全的框架要务实得多。
3.2 交互式优先：不是所有事情都要写成脚本
很多自动化工具的设计哲学是"一切皆脚本"，你得先把任务写成文件，然后执行文件。但日常工作中，大量操作是探索性的、一次性的，写脚本反而麻烦。OpenShell 强调交互式优先，你可以直接在会话里敲动作名，带参数，看结果，不满意再调整。这种"REPL 式"的体验，在调试和探索阶段效率极高。
当然，交互式不代表不能脚本化。好的 OpenShell 实现应该支持"把一次交互会话导出成脚本"，这样你探索出来的流程可以固化下来，下次直接批量执行。这个双向通道很关键：交互式用于发现，脚本化用于重复。两者结合，才能覆盖从"第一次做"到"第一百次做"的完整生命周期。
3.3 可组合性：小动作拼成大流程
OpenShell 里的动作应该是可组合的。一个动作的输出，可以管道给另一个动作的输入；一组动作可以串成一个"工作流"，用一个命令触发。这种组合能力，让壳层从"命令快捷方式"升级成"流程编排层"。
我常用的一个组合是这样的：fetch-logs拉取最近日志，管道给filter-errors过滤错误行，再管道给summarize生成统计摘要，最后notify把摘要发到某个通知渠道。这四个动作各自独立，可以单独调用，也可以串起来。串起来的时候，OpenShell 负责处理中间的数据传递和错误传播。如果中间某一步失败了，整个链条应该停下来，并给出清晰的错误定位。这种"管道式组合"的思维，和 Unix 哲学一脉相承，但在跨环境场景下，需要额外处理网络延迟、认证、数据序列化等问题。
3.4 与现有终端的关系：不是替代，是增强
最后要澄清一个常见的误解：OpenShell 不是要替代你的终端模拟器（iTerm、Windows Terminal、Alacritty 等），也不是要替代你的 Shell（bash、zsh、fish）。它是在这两者之上的一层。你还是在终端里工作，还是用你习惯的 Shell，只是多了一个openshell命令（或者一个快捷键）来进入壳层会话。
这种定位意味着，OpenShell 可以充分利用现有终端的能力：颜色、字体、分屏、快捷键，全都能用。同时，它也可以和现有 Shell 的配置共存：你的.bashrc、.zshrc里的别名和函数，OpenShell 可以选择性地继承。这种"增强而非替代"的策略，降低了 adoption 的心理门槛——你不需要放弃已经熟悉的一切，只需要在需要的时候多用一个工具。
4. 从零搭一个最小可用的 OpenShell：实操步骤与关键决策
4.1 技术选型：用什么语言写壳层
如果你要自己实现一个 OpenShell，第一个决策是技术选型。可选的语言很多：Python、Go、Rust、Node.js，甚至 Bash 本身。每种选择都有取舍。
Python 的优势是生态丰富、开发快，subprocess、argparse、click这些库能省很多事。缺点是启动慢，分发依赖麻烦。Go 的优势是编译成单二进制、启动快、并发好，适合做长期运行的服务。缺点是开发效率相对低，处理动态配置不如脚本语言灵活。Rust 性能最好、类型安全，但学习曲线陡，开发周期长。Node.js 适合前端背景的人，但运行时依赖 Node 环境。
我的建议是：如果只是个人用、追求快速迭代，选 Python；如果要分发给团队、追求零依赖，选 Go。我自己用的是 Python +click做 CLI 入口，subprocess做命令执行，pyyaml做配置解析。这个组合开发效率很高，一个周末就能搭出可用的原型。等原型稳定了，再考虑用 Go 重写核心部分。
4.2 配置文件结构：动作、环境、上下文怎么组织
OpenShell 的核心是一份配置文件，通常放在~/.config/openshell/config.yaml或者项目根目录的.openshell.yaml。这份文件定义了动作、环境、上下文三大部分。
动作（actions）的定义大概长这样：
actions: list-files: description: "列出当前目录文件" command: "ls -la" env: "local" args: - name: "path" default: "." description: "目标路径" check-log: description: "查看最近日志" command: "tail -n {{lines}} {{logfile}}" env: "container" args: - name: "lines" default: 100 - name: "logfile" default: "/var/log/app.log"环境（environments）的定义：
environments: local: type: "local" workdir: "~" container: type: "docker" container: "my-app" workdir: "/app" remote: type: "ssh" host: "example-host" user: "deploy" workdir: "/srv/app"上下文（contexts）用来定义变量和别名：
contexts: default: vars: app_name: "my-service" region: "us-east" aliases: ll: "list-files" cl: "check-log"这个结构的关键设计点是：动作和环境解耦。一个动作可以指定默认环境，也可以在调用时覆盖。这样同一个动作可以在不同环境里复用，只需要改一个参数。这种解耦在实际使用中非常灵活，比如check-log默认在容器里执行，但你可以用--env=remote让它去远程主机上查日志。
4.3 命令执行与参数传递：小心引号和转义
命令执行看起来简单，实际上坑很多。最大的坑是参数传递时的引号和转义。比如你定义了一个动作grep-text，命令是grep {{pattern}} {{file}}，如果pattern里包含空格或者特殊字符，直接拼接就会出问题。
正确的做法是，不要把用户输入直接拼接到命令字符串里，而是用参数列表的方式传递。在 Python 里，用subprocess.run(["grep", pattern, file])而不是subprocess.run(f"grep {pattern} {file}", shell=True)。前者会把每个参数当作独立的元素传给系统调用，不需要担心转义；后者会经过 Shell 解析，容易出安全问题。
如果确实需要 Shell 特性（比如管道、重定向），那就得显式启用shell=True，并且对用户输入做严格的校验和转义。我的经验是，能用参数列表就用参数列表，实在不行再用 Shell 字符串，并且对用户输入做白名单校验。这个原则能避免 90% 以上的注入类问题。
4.4 输出处理与错误码：让失败也能被优雅处理
命令执行完，要处理输出和错误码。标准做法是：捕获stdout和stderr，记录退出码。如果退出码非零，说明命令失败，应该把stderr的内容展示给用户，并标记这次执行为失败。
但有些命令的"失败"是预期内的，比如grep没找到匹配项会返回 1，这不是错误。所以 OpenShell 应该允许动作定义"可接受的退出码"列表。比如：
actions: search: command: "grep {{pattern}} {{file}}" acceptable_exit_codes: [0, 1]这样grep返回 1 时，OpenShell 不会报错，而是正常展示"没找到"的结果。这个细节看起来小，但在实际使用中能避免很多误报。
另外，输出的格式化也值得花心思。我习惯把每次执行的元数据（动作名、环境、耗时、退出码）用灰色小字打印在输出上方，原始输出保持原样。这样既能看到上下文，又不干扰阅读。如果输出是 JSON，可以自动做一次美化缩进；如果是长文本，可以自动分页。这些"小贴心"积累起来，体验会好很多。
5. 踩过的坑：跨环境执行时那些文档不会写的问题
5.1 环境变量污染：本地和远程的 PATH 打架
第一个大坑是环境变量。你在本地定义了一个PATH，里面有一堆自定义工具路径；你ssh到远程，远程也有自己的PATH。如果 OpenShell 把本地的PATH直接注入到远程会话，可能会导致远程命令找不到，或者找到错误的版本。
我的解决方案是，环境变量分三类处理：继承类（如LANG、TERM）、覆盖类（如PATH、HOME）、隔离类（如LD_LIBRARY_PATH）。继承类直接透传，覆盖类由目标环境自己决定，隔离类默认不传递，除非用户显式要求。这个分类需要在配置文件里明确声明，不能靠猜。
还有一个更隐蔽的问题：有些工具会读取~/.gitconfig、~/.npmrc这类用户级配置。在本地执行时没问题，但到了容器或远程环境，这些文件可能不存在，导致行为不一致。我的做法是，在 OpenShell 启动时，把关键配置文件同步到目标环境的临时目录，并通过环境变量指向它们。这样既保证了行为一致，又不会污染目标环境的持久化配置。
5.2 工作目录漂移：cd 之后到底在哪
第二个坑是工作目录。在交互式会话里，用户可能会cd到某个目录，然后执行动作。如果动作是在另一个环境里执行的，这个cd到底生效不生效？
我的设计是：工作目录是上下文的一部分，跨环境传递。也就是说，你在本地cd到/project/src，然后执行一个在容器里运行的动作，OpenShell 会尝试把容器的工作目录也切到/project/src（如果这个路径在容器里存在的话）。如果不存在，就回退到环境的默认工作目录，并给出提示。
这个机制实现起来要注意路径映射。本地路径和容器路径往往不是一一对应的，可能需要一个映射表。比如本地的/home/user/project对应容器的/app。这个映射关系应该在环境配置里定义清楚，否则会出现"文件明明在本地有，容器里却找不到"的困惑。
5.3 交互式命令的尴尬：vim、top 这类工具怎么处理
第三个坑是交互式命令。有些命令需要 TTY，比如vim、top、less。如果你在 OpenShell 里执行这些命令，而 OpenShell 又没有正确处理 TTY 分配，就会出现界面错乱、按键无响应等问题。
处理方式有两种：一是透传 TTY，让命令直接接管终端；二是拒绝执行，提示用户这类命令应该在原生终端里运行。我倾向于第一种，但实现起来复杂，需要处理信号、窗口大小变化、原始模式切换等。如果时间有限，第二种更稳妥。至少不要让用户面对一个半死不活的vim界面。
对于跨环境的交互式命令，问题更复杂。比如你想在远程主机上开一个vim，这涉及到终端会话的转发。我的建议是，OpenShell 专注于非交互式命令的编排，交互式操作还是交给专门的工具（如原生ssh、docker exec -it）。不要试图在一个工具里解决所有问题，边界清晰反而更好用。
5.4 并发执行的竞态：同时跑多个动作会怎样
第四个坑是并发。如果你在 OpenShell 里同时触发多个动作，它们可能会竞争同一份资源：同一个工作目录、同一个临时文件、同一个网络端口。如果没有适当的隔离机制，就会出现难以复现的 bug。
我的做法是，给每个动作执行分配一个独立的临时目录和会话 ID，需要共享的资源通过显式的锁来协调。比如两个动作都要写同一个日志文件，那就得在配置里声明这个资源，OpenShell 负责加锁。对于大多数日常操作，并发冲突不常见，但一旦出现，排查起来很痛苦。提前设计好隔离机制，比事后救火划算得多。
6. 把 OpenShell 用出花：几个真实场景的落地思路
6.1 场景一：多服务日志的聚合查看
假设你手头有三个服务，分别跑在本地、容器 A、容器 B 里。以前查日志要开三个终端，分别tail -f。用 OpenShell 可以定义一个logs动作，接受服务名参数，自动路由到对应的环境，并且支持同时跟踪多个服务的日志。
实现思路是：动作内部启动多个子进程，分别拉取不同环境的日志流，然后在 OpenShell 层做一次合并输出，给每行加上服务名前缀。这样你在一张屏幕上就能看到所有服务的实时日志，排查跨服务问题时效率提升明显。关键点是处理不同日志流的时间戳对齐和缓冲问题，避免某个流阻塞导致整体卡顿。
6.2 场景二：跨环境的配置同步与校验
第二个场景是配置管理。你有一份配置文件，需要同步到多个环境，并且校验每个环境里的实际配置是否一致。用 OpenShell 可以定义一个sync-config动作，先拉取各环境的当前配置，做 diff，确认无误后再推送。
这个场景的难点在于幂等性和回滚。如果同步到一半失败了，得有办法回滚到之前的状态。我的做法是，每次同步前先备份目标环境的配置，同步失败时自动恢复备份。同时，diff 结果要清晰展示，让用户确认后再执行，避免误操作。
6.3 场景三：日常任务的快捷入口
第三个场景最简单也最实用：把日常高频任务做成快捷动作。比如deploy、restart、backup、clean，每个动作背后可能是一串复杂的命令，但在 OpenShell 里就是一个词。日积月累，你的 OpenShell 就变成了一个个人化的运维面板。
我自己的 OpenShell 里注册了大概三十多个动作，覆盖了从代码拉取、构建、测试、部署到日志查看、性能监控的完整流程。新同事入职时，我直接把配置文件给他，他就能用同样的方式操作，省去了大量口头传授的时间。这种"可传承的操作知识"，是 OpenShell 除了效率之外的另一个价值。
6.4 场景四：临时环境的快速搭建与销毁
第四个场景偏进阶：用 OpenShell 管理临时环境。比如你要做一个实验，需要快速起一个容器、装几个依赖、跑一段测试、然后销毁。这些步骤可以串成一个工作流，用一个命令触发，全程自动化。
这个场景的关键是资源清理的可靠性。临时环境用完必须销毁，否则会积累一堆僵尸容器。OpenShell 应该支持"无论成功失败，最后都执行清理"的语义，类似编程语言里的finally。同时，清理操作要有日志记录，方便追溯。
7. 关于 OpenShell 的几个常见误解与边界
7.1 它不是万能的自动化平台
第一个误解是把它当成 Ansible、Jenkins 那样的自动化平台。OpenShell 的定位是"交互式壳层"，它擅长的是即时、灵活、探索性的操作，而不是大规模、批量化、无人值守的编排。如果你要管理一百台服务器，OpenShell 不是正确的工具；但如果你要在三五个环境之间来回切换调试，它很合适。认清这个边界，能避免在错误的方向上投入过多。
7.2 它不解决认证和权限问题
第二个误解是以为 OpenShell 能自动处理认证。实际上，它只是把命令转发到目标环境，认证还是得靠底层机制（SSH 密钥、容器权限、API token）。OpenShell 能做的是，把认证配置集中管理，避免每次手动输入。但如果你没有配置好底层的认证，OpenShell 也帮不了你。这个边界要清楚，否则会误以为"用了 OpenShell 就安全了"。
7.3 它不保证跨环境的完全一致性
第三个误解是追求"完全一致"。不同环境的操作系统、工具版本、文件系统结构天然不同，OpenShell 不可能消除这些差异。它能做的是"统一接口，暴露差异"。也就是说，当某个动作在某个环境里行为不一致时，OpenShell 应该清晰地告诉你"这里不一样"，而不是假装一样。这种诚实的设计，比强行统一更可靠。
7.4 它的价值随使用深度递增
最后一点：OpenShell 的价值不是一开始就显现的。你刚装好它，可能觉得"不就是个命令别名工具吗"。但随着你注册的动作越来越多，覆盖的场景越来越广，它会逐渐变成一个"个人操作系统的入口"。这种价值是累积的，需要一点耐心去建设。我的建议是，从最高频的三个操作开始，用顺了再扩展，不要一上来就追求大而全。
8. 如果让我重新设计一次：几个会改变的决定
8.1 配置格式从 YAML 换成 TOML 或 JSON5
如果重新来一次，我可能会把配置格式从 YAML 换成 TOML 或 JSON5。YAML 的可读性好，但缩进敏感、解析歧义多，团队协作时容易因为空格问题产生冲突。TOML 的语义更明确，JSON5 则兼容 JSON 且支持注释。这个改变能减少很多"配置看起来对但就是不生效"的问题。
8.2 动作定义支持继承和组合
第二个改变是让动作支持继承。比如定义一个基础动作base-ssh，包含通用的 SSH 参数，然后具体的远程动作继承它，只覆盖差异部分。这样能减少重复配置，也更容易维护。组合则是把多个动作打包成一个"宏动作"，一次触发执行一串。这两个特性在动作数量多了之后会非常有用。
8.3 增加执行历史与回放
第三个改变是增加执行历史记录。每次动作执行都记一笔：时间、动作名、参数、环境、输出摘要、退出码。这样出问题时可以回溯，也可以把某次成功的执行"回放"成脚本。这个功能对调试和知识沉淀都很有价值，可惜我第一版没做，后来补起来费了不少劲。
8.4 更早引入插件机制
第四个改变是更早引入插件机制。OpenShell 的核心应该保持精简，把环境适配（Docker、SSH、Kubernetes 等）做成插件，按需加载。这样核心代码稳定，扩展灵活，社区也更容易贡献。我第一版把所有环境适配都写死在主程序里，后来加一个新环境就要改核心代码，很痛苦。
9. 写在最后：一些个人体会
折腾 OpenShell 这类工具，最大的收获不是工具本身，而是对"工作流"这件事的理解加深了。你会发现，很多效率问题不是出在某个命令不够快，而是出在命令之间的衔接上：环境切换、参数转换、输出解析、错误处理。把这些衔接点打磨顺了，整体效率的提升是指数级的。
另外，不要追求一步到位。我见过太多人一开始就想设计一个完美的框架，结果写了半个月还在改架构，一个实际动作都没跑起来。正确的做法是，先用最笨的方式把第一个动作跑通，然后逐步迭代。工具是长出来的，不是设计出来的。
最后，OpenShell 这个名字本身也提醒我们：壳层的价值在于"包裹"和"连接"，而不是"替代"。它不生产能力，它只是让已有能力更容易被调用。想清楚这一点，很多设计决策就自然清晰了。
