1. 从零认识 OpenShell：它到底解决什么问题

第一次听到 OpenShell 这个名字，很多人会下意识以为它又是一个新的命令行工具或者某种终端美化方案。实际上，OpenShell 的定位要更底层、也更有意思——它是一套面向智能体（Agent）运行时的安全执行框架，核心目标是把大模型驱动的自动化操作，关进一个可控、可审计、可回滚的“沙箱笼子”里。

我接触 OpenShell 的契机，是团队在做一套自动化运维助手。当时最大的痛点不是模型不够聪明，而是它太“敢”了：你让它清理日志，它可能顺手把配置目录也删了；你让它跑个脚本，它可能直接在生产环境执行高危命令。模型本身没有恶意，但它对边界的理解是模糊的。OpenShell 要解决的，正是这个“能力很强但边界不清”的问题。

用一句话概括：OpenShell 给智能体提供了一个受约束的执行环境，让它可以放心地读写文件、执行命令、调用工具，同时所有动作都在策略管控和审计记录之下。它适合三类人：一是正在做 Agent 产品的开发者，二是需要让 AI 参与运维或数据处理但担心安全风险的工程师，三是对智能体运行时机制感兴趣、想自己搭一套可控执行环境的技术爱好者。

这篇文章我会从设计思路、核心机制、实操落地、问题排查几个角度，把 OpenShell 拆开讲透。不是官方文档的复述，而是我自己踩过坑、调过参数、改过策略之后的经验总结。无论你是刚听说这个概念，还是已经准备上手，应该都能从中找到能直接用的东西。

2. OpenShell 的整体设计与思路拆解

2.1 为什么智能体需要一个“壳”

要理解 OpenShell 的设计，得先理解智能体执行和传统程序执行的根本差异。传统程序的行为是确定的：你写rm -rf /tmp/cache，它就只删这个目录。但智能体的行为是生成式的——它根据上下文实时决定下一步做什么，这意味着它的行为空间几乎是无限的。

这种无限性带来两个问题。第一是安全边界问题：模型可能生成超出预期的操作，比如访问敏感路径、发起网络请求、修改系统配置。第二是可追溯问题：当一次自动化任务出了事故，你很难说清楚到底是哪一步、哪个决策导致了问题，因为整个执行链路是模型动态生成的。

OpenShell 的思路很直接：既然无法预测模型要做什么，那就不预测，而是约束。它把智能体的执行环境抽象成一个“壳”，壳内是模型可以自由发挥的空间，壳的边界由策略定义。模型在壳内怎么折腾都行，但一旦触碰边界，就会被拦截或记录。

这里有个关键认知：OpenShell 不是要限制模型的能力，而是要给它一个“可承受失败”的环境。就像给小孩一个铺了软垫的房间，他可以随便跑跳，但不会摔到外面去。

2.2 核心架构的三个层次

OpenShell 的架构可以拆成三层来理解，我用一个实际场景来串：假设你让智能体“把项目里所有.log文件压缩归档”。

第一层是执行层（Execution Layer）。这是智能体真正干活的地方，它提供文件系统访问、命令执行、工具调用等基础能力。但注意，这一层提供的不是真实的系统资源，而是虚拟化后的视图。智能体看到的/workspace可能映射到宿主机的某个临时目录，它以为自己在操作根目录，实际上被限制在沙箱内。

第二层是策略层（Policy Layer）。这是 OpenShell 的核心。策略定义了“什么能做、什么不能做、什么需要审批”。比如你可以配置：允许读取/workspace下所有文件，允许写入/workspace/output，禁止访问/etc，禁止执行curl类命令。策略的粒度可以细到单个命令、单个路径、单个工具。

第三层是审计层（Audit Layer）。所有执行动作都会被记录：谁发起的、什么时间、执行了什么、结果如何、是否被策略拦截。这一层解决的是“事后能查”的问题。我实测下来，审计日志的详细程度直接决定了排查效率，后面会专门讲怎么配置。

这三层的组合，让 OpenShell 既给了智能体足够的自由度，又保证了整个系统的可控性。用一句话说就是：放开手让它做，但每一步都留痕、都有边界。

2.3 和其他方案的对比：为什么不用容器或虚拟机

很多人第一反应是：这不就是 Docker 干的事吗？用容器隔离不就行了？

我一开始也这么想，但实际用下来发现两者定位不同。容器解决的是进程级隔离，它把整个运行环境打包，但容器内的进程仍然拥有完整的系统调用能力。智能体在容器里执行rm -rf /，容器确实会挂，但容器内的数据也没了。而且容器的策略控制通常比较粗，你要精细到“允许读这个文件但禁止写那个文件”，配置起来很别扭。

OpenShell 的差异在于它是为智能体行为模型设计的。它理解“工具调用”这个概念，知道智能体的一次操作可能包含多个步骤，可以在步骤级别做策略判断。比如一个“部署应用”的工具调用，OpenShell 可以拆解成“拉取代码→构建→推送→重启服务”几个子步骤，对每个子步骤单独设策略。这种粒度是容器很难做到的。

另一个对比对象是直接用一个受限的系统用户来跑。这个方案简单，但问题是权限模型太粗糙，而且没有审计能力。出了事你只能看到系统日志里一堆命令，根本分不清哪些是智能体干的、哪些是人干的。

所以 OpenShell 的定位很清晰：它不是替代容器，而是在容器或系统之上，再加一层面向智能体行为的策略与审计。实际部署中，我通常会把 OpenShell 跑在容器里，形成“容器隔离 + OpenShell 策略”的双层防护。

2.4 设计取舍：性能与安全的平衡

任何安全框架都要面对一个现实问题：加的限制越多，性能损耗越大。OpenShell 在这方面做了几个我认为很聪明的取舍。

第一，策略判断走内存缓存。策略文件在启动时加载到内存，每次执行动作时在内存中匹配，不走磁盘 IO。我实测下来，单次策略判断的耗时在微秒级，对整体执行时间的影响可以忽略。

第二，审计日志异步写入。如果每个动作都同步写日志，高频操作场景下会成为瓶颈。OpenShell 采用异步队列，执行动作先返回结果，日志后台落盘。代价是极端情况下可能丢最后几条日志，但换来了执行效率。如果你的场景对日志完整性要求极高，可以配置同步模式，但要做好性能下降的准备。

第三，策略匹配用前缀树。路径和命令的匹配不是简单的字符串比较，而是构建了前缀树结构。这意味着即使你配置了几千条策略规则，匹配速度也不会明显下降。这个设计在规则多的场景下优势很明显。

这些取舍背后的逻辑是一致的：安全框架不能成为性能瓶颈，否则用户会想办法绕过它。一个又安全又快的方案，才会被真正用起来。

3. 核心机制解析与实操要点

3.1 策略配置：从“全放开”到“最小权限”

策略是 OpenShell 的灵魂，但也是最容易配错的地方。我见过太多人一开始图省事，直接配了个“允许所有操作”，结果等于没开 OpenShell。正确的做法是从最小权限开始，按需放开。

策略文件通常是一个结构化的配置，我用一个简化示例来说明核心字段：

policies: - name: workspace_read action: allow resource: file path: /workspace/** operations: [read, list] - name: workspace_write action: allow resource: file path: /workspace/output/** operations: [write, create] - name: system_protect action: deny resource: file path: /etc/** operations: [read, write, delete] - name: command_restrict action: deny resource: command pattern: ["curl", "wget", "ssh", "nc"]

这个配置的逻辑是：工作区可读，输出目录可写，系统目录禁止访问，网络类命令禁止执行。注意deny规则的优先级通常高于allow，这是安全设计的基本原则——白名单放开，黑名单兜底。

实操中有几个细节值得注意。第一，路径匹配的**和*含义不同，**匹配多级目录，*只匹配单级，配错了会导致策略失效。第二，命令匹配建议用精确匹配而非模糊匹配，否则curl被禁了，模型可能用/usr/bin/curl绕过。第三，策略要定期审查，随着业务变化，有些放开可能已经不需要了。

我的经验是：策略配置完成后，一定要用一组“边界测试用例”验证。比如故意让智能体尝试访问/etc/passwd、执行rm -rf、发起网络请求，确认都被正确拦截。这一步不能省。

3.2 沙箱执行：文件系统与命令的虚拟化

OpenShell 的沙箱执行机制，核心是视图隔离。智能体看到的文件系统，不是真实的文件系统，而是一个经过映射的视图。

具体来说，OpenShell 会为每个会话创建一个工作目录，通常叫workspace或sandbox。这个目录下的内容可以是空的，也可以从某个模板目录复制过来。智能体在这个目录下的所有操作，都被限制在这个范围内。它以为自己在操作/，实际上所有路径都被重定向到了工作目录。

命令执行也是类似的逻辑。OpenShell 维护一个允许执行的命令列表，每个命令可以配置参数约束。比如允许ls但限制只能列工作目录，允许python但限制只能执行指定脚本。当智能体请求执行一个命令时，OpenShell 先做策略判断，通过后才在受控环境中执行。

这里有个容易踩的坑：环境变量泄露。如果沙箱环境继承了宿主机的环境变量，智能体可能通过env命令拿到敏感信息。正确的做法是在沙箱启动时清理环境变量，只保留必要的几个。我一般会显式设置PATH、HOME、LANG这几个，其他全部清空。

另一个坑是符号链接逃逸。如果工作目录里有一个指向外部的符号链接，智能体可能通过它访问到沙箱外的文件。OpenShell 默认会解析符号链接并检查目标路径是否在允许范围内，但这个行为依赖配置。建议在策略中显式禁止创建符号链接，或者开启严格模式。

3.3 审计日志：怎么记、记什么、怎么用

审计日志是 OpenShell 最被低估的功能。很多人配好策略就不管日志了，等到出问题才想起来查，结果发现日志没开或者记的不够细。

日志应该记什么？我的建议是至少包含这几个字段：时间戳、会话 ID、动作类型、目标资源、执行结果、策略判定、耗时。其中“策略判定”字段特别重要，它记录了这次动作是被允许还是被拒绝，以及命中了哪条策略。排查问题时，这个字段能直接告诉你“为什么这个操作没执行”。

日志的存储格式，我推荐用结构化格式（如 JSON Lines），每行一条记录。这样方便后续用工具分析，比如统计被拦截的操作类型分布、找出高频访问的路径等。纯文本日志虽然人眼看着舒服，但机器处理起来麻烦。

日志的用途不只是事后排查。我实际用下来，有几个场景特别有价值。第一是策略优化：通过分析被拦截的操作，你能发现哪些策略配得太严、哪些配得太松。第二是行为分析：观察智能体的操作模式，能发现它的“习惯”，比如总是先读配置再执行，这有助于优化提示词。第三是成本核算：如果智能体的操作涉及外部资源调用，日志能帮你算清楚每个任务的实际开销。

一个实用技巧：给日志加一个“会话标签”字段，把同一次任务的所有操作关联起来。这样查问题时，你能看到完整的执行链路，而不是一堆散落的记录。

3.4 工具调用的策略控制

智能体的能力很大程度上来自工具调用。OpenShell 对工具调用的控制，比文件系统和命令更细一层，因为它能理解工具的语义。

举个例子，假设你给智能体配了一个“发送邮件”的工具。在 OpenShell 里，你可以配置：允许调用这个工具，但限制收件人必须在某个白名单内，限制邮件内容不能包含特定关键词，限制每小时最多发送 10 封。这些约束是在工具层面实现的，比在命令层面拦截要精准得多。

工具调用的策略配置，核心是参数校验。每个工具定义自己的参数 schema，OpenShell 在调用前校验参数是否符合约束。比如一个“查询数据库”的工具，可以限制查询语句只能是 SELECT，禁止 DELETE 和 UPDATE。这种校验在工具实现层做，比在模型层做可靠得多，因为模型可能被诱导生成恶意参数。

实操中要注意的是工具的组合风险。单个工具看起来都安全，但组合起来可能产生风险。比如“读取文件”和“发送网络请求”两个工具单独看都没问题，但组合起来就可能造成数据外泄。OpenShell 支持配置“组合策略”，检测连续动作的模式。这个功能配置起来稍复杂，但对高安全场景很有必要。

4. 完整实操：从零搭建一个受控执行环境

4.1 环境准备与依赖安装

假设我们要搭建一个环境，让智能体能够处理一批数据文件：读取输入目录的 CSV，做清洗转换，输出到结果目录。整个过程不允许访问网络，不允许执行系统命令。

首先是环境准备。OpenShell 通常以库的形式集成到你的应用中，也可以作为独立服务运行。我倾向于独立服务模式，因为这样策略和审计是集中管理的，多个智能体可以共享同一套配置。

安装过程不复杂，核心是确保运行时依赖齐全。需要注意的是版本兼容性——OpenShell 的策略引擎对配置格式有版本要求，不同版本之间可能有语法差异。我建议锁定一个稳定版本，不要盲目追新。

# 以 Python 环境为例，安装核心包 pip install openshell-core openshell-policy # 验证安装 openshell --version

安装完成后，第一件事是初始化配置目录。OpenShell 默认会读取~/.openshell/下的配置，但生产环境建议显式指定配置路径，避免混淆。

openshell init --config-dir /opt/openshell/config

这个命令会生成默认的策略文件、审计配置和沙箱模板。默认配置通常是“全拒绝”模式，这是安全的起点，你需要根据自己的需求逐步放开。

4.2 策略文件的编写与验证

接下来编写策略文件。针对我们的数据处理场景，策略应该包含：允许读取输入目录、允许写入输出目录、禁止网络访问、禁止系统命令。

version: "1.0" default_action: deny policies: - name: input_read action: allow resource: file path: /workspace/input/** operations: [read, list, stat] - name: output_write action: allow resource: file path: /workspace/output/** operations: [write, create, delete] - name: temp_workspace action: allow resource: file path: /workspace/tmp/** operations: [read, write, create, delete] - name: no_network action: deny resource: network pattern: ["*"] - name: no_system_command action: deny resource: command pattern: ["*"]

注意default_action: deny这一行，它定义了兜底行为：任何没有被显式允许的操作，一律拒绝。这是最小权限原则的体现。

策略写完后，必须验证。OpenShell 提供了策略校验命令：

openshell policy validate --config /opt/openshell/config/policy.yaml

这个命令会检查语法错误、规则冲突、路径格式等问题。我强烈建议把这一步加入 CI 流程，每次策略变更都自动校验，避免带病上线。

验证通过后，可以用测试模式跑一组用例：

openshell policy test --config /opt/openshell/config/policy.yaml --case test_cases.yaml

测试用例文件里定义了一系列“操作 + 预期结果”的组合，比如“读取 /workspace/input/data.csv 应该被允许”、“读取 /etc/passwd 应该被拒绝”。这一步能帮你发现策略配置的逻辑漏洞。

4.3 沙箱环境的初始化与挂载

策略配好后，下一步是初始化沙箱环境。沙箱的本质是一个目录，加上一套映射规则。

openshell sandbox create \ --name data_processor \ --workspace /var/openshell/sandboxes/data_processor \ --template /opt/openshell/templates/data_processing

这个命令创建了一个名为data_processor的沙箱，工作目录在/var/openshell/sandboxes/data_processor，初始内容从模板目录复制。模板目录里可以放一些基础文件，比如示例数据、工具脚本等。

沙箱创建后，需要把实际的数据目录挂载进去。OpenShell 支持只读挂载和读写挂载两种模式。输入目录用只读挂载，输出目录用读写挂载：

openshell sandbox mount data_processor \ --source /data/input \ --target /workspace/input \ --mode ro openshell sandbox mount data_processor \ --source /data/output \ --target /workspace/output \ --mode rw

只读挂载的意义在于：即使智能体尝试修改输入数据，也会被文件系统层面拒绝，这是策略之外的又一层保护。

挂载配置有个细节：路径映射要避免重叠。如果/workspace/input和/workspace/input/sub分别挂载了不同的源，行为可能不符合预期。建议挂载点之间保持清晰的层级关系。

4.4 启动执行与会话管理

环境准备好后，就可以启动智能体执行了。OpenShell 的会话管理机制，让每次执行都是独立的，互不干扰。

openshell session start \ --sandbox data_processor \ --policy /opt/openshell/config/policy.yaml \ --audit /var/log/openshell/audit.jsonl \ --task "process_csv"

这个命令启动一个会话，绑定沙箱、策略和审计日志。--task参数是任务标识，会记录在审计日志里，方便后续按任务查询。

会话启动后，智能体的所有操作都通过 OpenShell 的 API 进行。以文件读取为例：

from openshell import Session session = Session.connect("data_processor") # 读取文件，这个操作会经过策略判断 content = session.file.read("/workspace/input/data.csv") # 写入文件 session.file.write("/workspace/output/result.csv", processed_content) # 尝试执行命令，会被策略拦截 try: session.command.run("ls -la") except PolicyDeniedError as e: print(f"操作被拒绝: {e.policy_name}")

注意最后那个命令执行，因为策略里禁止了所有系统命令，所以会抛出PolicyDeniedError，并且异常里包含了命中的策略名称。这个设计很贴心，排查问题时能直接定位到是哪条策略拦截的。

会话结束后，记得清理：

openshell session stop data_processor

清理会释放沙箱资源，但审计日志会保留。如果沙箱里有需要保留的输出，确保已经挂载到持久化目录。

4.5 审计日志的查询与分析

执行完成后，审计日志就是你的“黑匣子”。OpenShell 提供了查询工具，也支持直接分析原始日志。

# 查询某个会话的所有操作 openshell audit query --session data_processor --format table # 查询被拒绝的操作 openshell audit query --session data_processor --result denied # 导出为 JSON 做进一步分析 openshell audit export --session data_processor --output audit_export.json

表格形式的输出适合快速浏览，JSON 导出适合做统计分析。我通常会用脚本统计几个指标：总操作数、被拒绝操作数、各类型操作的分布、耗时最长的操作。这些指标能反映智能体的行为特征和策略的有效性。

如果发现某个操作被频繁拒绝，可能有两种情况：一是策略配得太严，影响了正常任务；二是智能体在尝试越界，需要调整提示词或工具配置。两种情况都需要处理，不能放任。

5. 常见问题与排查技巧实录

5.1 策略不生效：为什么我的规则被绕过了

这是最常见的问题，表现是明明配了拒绝规则，但操作还是执行了。排查思路按优先级排列：

第一，检查规则顺序。OpenShell 的策略匹配通常遵循“首次匹配”或“最具体匹配”原则。如果你的允许规则写在拒绝规则前面，且匹配范围更宽，就可能覆盖拒绝规则。建议把拒绝规则放在前面，或者使用显式的优先级字段。

第二，检查路径格式。路径匹配对格式敏感。/workspace/input和/workspace/input/可能被当作不同路径。**和*的差异也容易搞混。建议用策略校验工具检查，它会提示可能的格式问题。

第三，检查符号链接。如果允许的目录里有一个指向外部的符号链接，智能体可能通过它访问到未授权区域。开启严格模式可以解决，但会带来性能开销。

第四，检查默认动作。如果default_action配成了allow，那么所有未匹配的操作都会被允许。这个配置错误很隐蔽，因为大部分操作看起来都“正常”，直到出现越界才暴露。

5.2 性能问题：执行变慢了怎么办

加了 OpenShell 之后，如果发现执行明显变慢，可以从几个方向排查。

先看策略数量。虽然前缀树匹配很快，但如果规则数量达到数万条，匹配时间还是会累积。建议定期清理无用规则，合并相似规则。

再看审计日志模式。同步写入日志会显著拖慢执行，尤其是高频操作场景。检查配置里是否误开了同步模式，如果是，改成异步。

然后看沙箱文件系统。如果沙箱目录挂载在网络存储上，文件操作延迟会很高。建议沙箱工作目录用本地 SSD，只有需要持久化的输出才挂载到网络存储。

最后看策略判断的缓存。OpenShell 对相同的“资源+操作”组合有缓存机制，但如果每次操作的路径都不同（比如带时间戳的文件名），缓存命中率会很低。这种情况下可以考虑用通配符策略减少规则数量。

5.3 审计日志丢失或不完整

日志丢失通常有几个原因。一是异步写入模式下，进程异常退出导致队列中的日志没落盘。解决方法是配置定期 flush，或者对关键操作开启同步写入。二是日志轮转配置不当，旧日志被覆盖。检查轮转策略，确保保留时间满足审计要求。三是磁盘满了，这个最容易被忽略，建议加磁盘监控。

日志不完整则可能是字段配置问题。OpenShell 允许自定义日志字段，如果某个字段没配，日志里就不会有。排查时先确认日志格式配置，再看是不是某些操作类型没有触发日志记录。

5.4 智能体行为异常：总是尝试越界操作

如果审计日志显示智能体频繁尝试被拒绝的操作，说明它的行为模式和策略不匹配。可能的原因和对策：

我遇到过一个典型案例：智能体总是尝试用curl下载依赖。排查发现是提示词里写了“如果需要可以下载”，虽然加了“但通常不需要”，模型还是倾向于尝试。后来把提示词改成“环境已离线，所有依赖已预装”，问题就解决了。这说明提示词和策略要协同设计，不能各管各的。

5.5 沙箱逃逸的防范要点

虽然 OpenShell 的设计目标是防止逃逸，但配置不当仍可能留下缺口。几个关键防范点：

• 禁止创建符号链接：在策略里显式禁止symlink操作，或者开启严格模式自动解析。
• 限制/proc和/sys访问：这些虚拟文件系统可能泄露系统信息，默认应该禁止。
• 清理环境变量：沙箱启动时清空继承的环境变量，只保留必要的。
• 限制文件描述符继承：确保沙箱进程不继承宿主进程的打开文件。
• 定期更新：OpenShell 本身也会有安全更新，保持版本更新。

一个实用的检查方法：在沙箱里跑一个“逃逸测试脚本”，尝试各种常见的逃逸手法，看是否都被拦截。这个脚本可以加入 CI，每次配置变更后自动跑一遍。

6. 进阶技巧与个人经验分享

6.1 策略的版本管理与灰度发布

策略文件是代码，应该纳入版本管理。我通常会把策略放在 Git 仓库里，每次变更都走 PR 流程，至少一个人 review。这样做的价值在出问题时特别明显：你能快速定位是哪次变更引入了问题，也能一键回滚。

灰度发布策略也很重要。新策略不要一次性全量上线，先在一个沙箱里跑一段时间，观察审计日志，确认没有误拦截再推广。OpenShell 支持按沙箱绑定不同策略，这让灰度变得很容易。

6.2 用审计数据反哺策略优化

审计日志不只是排查工具，更是优化依据。我习惯每周看一次审计报告，关注几个指标：拒绝率、高频拒绝操作、策略命中分布。如果某个策略的拒绝率异常高，要么是策略太严，要么是智能体行为有问题，都值得深挖。

有个反直觉的发现：适度的拒绝其实是好事。如果拒绝率为零，说明策略可能太松，没有起到约束作用。健康的拒绝率通常在 1% 到 5% 之间，说明策略在有效工作，但又不影响正常任务。

6.3 多智能体场景下的策略隔离

当多个智能体共享一套 OpenShell 环境时，策略隔离就很重要。不同智能体的职责不同，权限也应该不同。比如数据处理智能体不需要网络权限，而监控智能体可能需要读取系统指标。

OpenShell 支持按会话绑定不同策略，实现权限隔离。配置时注意策略的继承关系：可以定义一个基础策略包含通用规则，然后各智能体在此基础上叠加自己的特定规则。这样既保证了通用安全要求，又给了灵活性。

6.4 和现有工具链的集成

OpenShell 不是孤立的，它需要和现有的开发、运维工具链集成。几个常见的集成点：

• CI/CD：策略校验和逃逸测试加入流水线，每次变更自动验证。
• 监控告警：审计日志接入监控系统，拒绝率异常时告警。
• 日志分析：审计日志导入日志平台，做长期趋势分析。
• 权限管理：策略变更走统一的权限审批流程。

集成的核心原则是不要让 OpenShell 成为信息孤岛。它的策略和日志应该融入现有的工程体系，而不是另起一套。

6.5 我踩过的三个坑

最后分享三个我实际踩过的坑，希望能帮你省点时间。

第一个坑是策略写太细。一开始我试图为每个操作都写一条策略，结果规则文件几千行，维护成本极高，而且经常出现规则冲突。后来改成“粗粒度策略 + 工具层校验”的组合，策略只管大方向，细节约束在工具实现里做。这样策略文件精简到几十条，可维护性大幅提升。

第二个坑是忽略审计日志的性能影响。有段时间发现执行变慢，排查半天才发现是审计日志同步写入导致的。改成异步后性能恢复，但代价是极端情况下可能丢日志。后来我做了折中：普通操作异步写，敏感操作同步写。这个配置在 OpenShell 里可以通过策略字段控制。

第三个坑是沙箱模板没清理。沙箱模板目录里放了一些测试文件，结果每次创建沙箱都会复制进去，智能体有时候会误操作这些文件。后来养成了习惯：模板目录只放必要的初始文件，测试数据通过挂载引入，不放进模板。

这套东西用下来，最大的体会是：OpenShell 的价值不在于它限制了什么，而在于它让智能体的行为变得可预期、可追溯。有了这层保障，你才敢让智能体去碰真实的数据和系统。如果你也在做智能体相关的项目，建议尽早把这层框架搭起来，越早搭成本越低。