一句话说清楚

卖脚本最怕发出去就被随手转发？ 把你的 Python 工作流一键密封，客户只能跑、不能读源码、不能改、不能转卖——零云端、零代码改造、5 分钟搞定。

你遇到过这些情况吗？

共同点：交付即授权，必须"一次一密、一节点一密"。

为什么不用 GitHub 私有仓 / SaaS 加密 / 许可证服务器？

三大核心卖点

卖点 1：零改造 — 你的脚本原封不动

工作流原本怎么写就怎么写：

• from helpers.fetch import get_weather
• import config
• Path(__file__).parent / "settings.json"
• subprocess.run([sys.executable, "helper.py"])

MGC 1.5.2 自动识别这些 import / 相对路径 / subprocess 关系，运行时通过密封执行路由：

• ✅ 文件不在客户磁盘落盘
• ✅ 客户机器没有任何路径能直接 cat 到源码
• ✅ 不需要把脚本改造成 API 调用模式

📦 自带示例：本技能 example/ 文件夹里有 4 个脚本（A/B/C/D），覆盖所有可识别模式。先跑通示例，再换你自己的脚本。

卖点 2：一次一密 — 每个客户独立密钥

每个客户拿到独立的 AES 密钥：

• 密钥用目标节点的 RSA 公钥加密（RSA-2048）
• AES-256 加密每个脚本文件
• 客户节点没有私钥 = 拿不到内容
• 客户节点拿到内容后无法转封给第三方（密钥已绑定他的节点）

作者节点                            客户节点
─────────                           ────────
mgc_save_file(path="./workflow")    
mgc_seal_package(ext04=客户公钥)    
        │
        ▼
   加密包 (.mgc_file)
        │
        └──── 任意方式送达 ──────►   mgc_save_file(path="./received.mgc_file")
                                    mgc_run(...)

卖点 3：本地交付 — 不连任何云

• 全部加密、解密、运行都在本地完成
• MGC 不连任何云、没有任何外部端点
• 加密包可邮件、U 盘、IM、GitHub Releases、私有网盘任意方式送达
• 即使加密包被截获，没有对应节点的私钥也无法解密
• 加密包仅在授权节点加密运行，脚本及 print 皆无明文落地，需指定生成结果物

已验证的真实场景

MGC 密封交付已经过企业级工作流交付场景实践验证，不是实验室玩具。

• ✅ 乙方团队向客户交付数据自动化工作流，代码全程不落地
• ✅ 独立开发者密封销售工具脚本，单份授权独立管理
• ✅ 企业内部跨团队脚本授权，防止敏感配置和核心逻辑泄露

⚡ 30 秒快速体验（自己节点上跑通闭环）

先别急着给客户用，在自己机器上跑通密封 → 导入 → 运行的完整闭环：

# 一键跑通（推荐）
python example/run_demo.py

或者手动：

# 1. 把工作流文件夹存入 MGC
mgc_save_file(path="./example", info_owner="demo", diff_2="demo")

# 2. 用自己的 node_pub 密封（模拟给"自己"授权）
my_pub = mgc_get(info_type="__NODE_PUB__", info_owner="__NODE_PUB__")
mgc_seal_package(info_owner="demo", diff_2="demo", ext04=my_pub)

# 3. 把生成的 .mgc_file 重新导入（模拟客户收到包后导入）
mgc_save_file(path="./demo.mgc_file")

# 4. 黑盒运行 D（同时驱动 B + C）
mgc_run(
    info_type="script", info_owner="demo",
    diff_1="demo", diff_2="demo", diff_3="script_d.py",
)
# → {"pid": 12345, "status": "started"}

跑通后桌面应该出现：

• ✅ ~/Desktop/txt1.txt（B 写入）
• ✅ ~/Desktop/txt2.txt（C 写入）
• ✅ ~/Desktop/txt2_via_a.txt（C 调 A 写入）
• ✅ ~/Desktop/combined.txt（D 汇总写入）

Linux 无 ~/Desktop 时自动回退到 ~。

跑通了？ 你已经掌握了密封交付的核心流程。接下来只需要把客户的公钥换进去，就能生成专属授权包。

关于费用

• MGC Blackbox 本身免费，免费使用，加密层出于用户安全考虑不提供源码，无月费、无抽成、无使用限制
• 本技能免费，封装了密封交付的最佳实践和详细指引
• 你卖脚本赚的钱全是你的，MGC 不抽一分钱

为什么免费？我们相信基础安全工具就应该是免费的公共品。

前置条件

• Python 3.10+（macOS 14+ Apple Silicon 不支持 Python 3.12）
• MGC Blackbox ≥ 1.5.2（关键：工作流自动识别 + subprocess 字面量列表运行时路由均在 1.5.2 完整支持）
• 安装：pip install mgc-blackbox
• 启动：mgc（API 在 http://127.0.0.1:57219，WebUI 在 http://127.0.0.1:57218）

三步交付（作者侧）

步骤 1：把工作流文件夹存入 MGC

my_workflow/
├── manifest.json
├── SKILL.md
├── run.py
├── helpers/
│   ├── fetch.py
│   └── parse.py
└── config/
    └── settings.json

mgc_save_file(
    path="./my_workflow",
    info_owner="my_workflow",
    diff_2="my_workflow",
)

这一步 MGC 会自动：

• 解析每个脚本的 argparse 写入 ext02
• 扫描 import 写入 ext05（依赖列表）
• 推断 ext06（平台列表）
• 构建 ext08（跨脚本调用图）

💡 小建议：本技能包随附了 example/ 文件夹，先用它跑通存入 → 密封（用自己的公钥测试） → 导入 → 运行的完整流程，再替换成你自己的工作流。

步骤 2：拿到客户的 RSA 公钥

# 客户在他自己的机器上执行（WebUI 或 MCP）
node_pub = mgc_get(
    info_type="__NODE_PUB__",
    info_owner="__NODE_PUB__"
)
# 客户把这段 PEM 公钥发给你（公钥非密，可任意渠道传输）

WebUI 取法（推荐）：WebUI → skill 页面 → Settings 下拉 → Node Public Key → 复制多行 PEM。 注意：ext04 必须含真实换行符 \n，不要单行拼接。

步骤 3：一键密封给该客户

mgc_seal_package(
    info_owner="my_workflow",
    diff_2="my_workflow",
    ext04=node_pub,        # 客户的 PEM 公钥
)
# → 生成 .mgc_file 加密包

把 .mgc_file 通过任意方式发给客户。

三步接收（客户侧）

步骤 1：导入加密包

mgc_save_file(path="./received.mgc_file")
# MGC 把加密包拆解为本地条目

步骤 2：浏览包内结构

# 列出包内所有条目（仅元信息，无明文）
mgc_find(info_owner="my_workflow", diff_2="my_workflow")

# 读 manifest（明文，了解工作流结构）
mgc_get(info_type="file", info_owner="my_workflow", diff_2="my_workflow")

# 读 SKILL.md（明文，按里面的指引调用对应脚本）
mgc_get(info_type="file", info_owner="my_workflow", diff_2="my_workflow", diff_3="SKILL.md")

步骤 3：黑盒运行

mgc_run(info_owner="my_workflow", diff_2="my_workflow")
# → {"pid": 12345, "status": "started"}
# AI 只得到启动状态，永远看不到脚本源码

特别注意出于黑盒执行的需要，MGC 不会返回任何明文及可能暴露认知的信息，因此工作流/脚本的输出结果需要显性指定文件及路径，或写入数据库或 MGC 本身。

三条关键规则（务必遵守）

规则 1（同包路径 OK，跨包用 API）

同一文件夹包内的脚本可以随意用 import / 相对路径 / subprocess —— MGC 1.5.2 会自动识别并在运行时密封路由，不需要改成 API 调用。

跨文件夹包（不同 info_owner + diff_2）的脚本调用才需要用 MGC API：

import os, requests

with open(os.path.expanduser("~/.mgc/database/mgc_black_box/.mgc_token")) as f:
    MGC_TOKEN = f.read().strip()

def call_remote_script(info_owner, ext02=None):
    return requests.post(
        "http://127.0.0.1:57219/api/mgc/sensitive/get",
        headers={"X-MGC-Token": MGC_TOKEN},
        json={
            "info_type": "script",
            "info_owner": info_owner,
            "diff_1": info_owner,
            "action": "run",
            "ext01": "python",
            "ext02": ext02,
        },
    ).json()

规则 2：SKILL.md 是明文

SKILL.md 必须明文 —— 它是客户的路由说明书：哪个脚本在什么场景调用、按什么顺序、传什么参数。没有它客户根本无法使用。

这是公开 API 契约，不是实现细节。核心逻辑必须放在脚本里，下一条规则说明。

规则 3：核心算法放脚本，别放提示词

SKILL.md 和提示词都是明文，客户能读。因此：

提示词是客户能看到的"说明书"，算法是你卖的"产品" —— 必须把产品锁进脚本里。

可识别的跨脚本写法（完整对照表）

当你用 mgc_save_file 保存一个文件夹时，MGC 会对每个脚本做静态解析，构建跨脚本调用图。运行时 MGC 拦截这些模式，通过密封执行路由 —— 磁盘无文件、无明文、无需重写代码。

作用域（1.5.2）：

• ✅ 跨脚本调用 仅在同一个文件夹包内被识别（调用方和被调用方的 info_owner + diff_2 必须一致）。
• ❌ 同文件夹、不同子目录（例如 pkg_root/CROSS-FOLDER/x.py → ../y.py）—— 暂无法识别（请等待后续版本）。
• ❌ 函数级调用没有以 import / from-import / Path 字面量出现在源码中 —— 不能识别。

关键不变量：

• 每个脚本的 argparse 是独立的 —— driver 的参数进 driver 的，每个 helper 的参数进 helper 自己的。
• Path(__file__).parent / "x.py" 在 macOS、Linux（POSIX）和 Windows（\ 分隔符）下都能正确解析。
• subprocess 输出正常流动 —— capture_output=True, text=True 可用，因为被启动的 helper 是真实的 Python 解释器，带 UTF-8 解码。

限制。 跨脚本调用只能在两个脚本一起被保存时生效。要在不同包之间编排脚本，请使用 MGC REST API 模式（参考前面"规则 1"中的 call_remote_script 示例），传入目标脚本的 MGC location（info_owner）。

错误码与排查

适用与不适用（边界）

MCP 工具速查

相关技能

• MGC Blackbox（跨设备脚本授权） —— 单脚本密封（更轻量）
• MGC Blackbox 元技能 —— MGC 全部能力的完整参考

联系

• 主仓库：https://github.com/zkeviny/MGC-Blackbox
• 问题反馈：https://github.com/zkeviny/MGC-Blackbox/issues
• 联系邮箱：mirgincipher@outlook.com