核心用法
moltblock 定位为 AI Agent 的「信任层」，采用「生成-评审-校验」三段式工作流：首先调用 LLM 生成候选产物，随后由独立的 Critic 模型进行风险识别，最终由 Judge 模型给出通过/拒绝的结构化裁决。用户通过 npx 直接调用，无需安装，支持 OpenAI、Anthropic、Google、ZAI 及本地 LLM 多后端。
显著优点
1. 零配置开箱即用：自动检测环境变量中的 API Key，无配置文件亦可运行，降低使用门槛。
2. 分层风险策略：内置高/中/低风险三级分类（如 rm -rf 强制校验、纯文本计算跳过），减少不必要的 LLM 调用开销。
3. 多模型冗余校验：Generator、Critic、Judge 可绑定不同后端，避免单点模型偏见，提升检出率。
4. 纯校验不执行：明确声明仅做策略审查，无任何代码执行或磁盘写入，降低攻击面。
潜在缺点与局限性
- 最佳努力性质（best-effort）：LLM 评审可能漏过精心构造的攻击载荷，策略规则需持续迭代。
- 依赖外部 LLM：网络延迟与 API 成本随调用量线性增长，本地 fallback 模型能力有限。
- 配置复杂度：高级用户需编写 JSON 配置以自定义模型绑定与策略规则，学习成本不低。
- 无沙箱隔离：仅做静态分析，不替代运行时安全机制（如 seccomp、容器隔离）。
适合人群
- 使用 AI Coding Agent（如 OpenClaw、Claude Code）的开发者，需在自动生成代码提交前增加人工复核的自动化替代。
- DevOps/Platform 团队，希望在 CI/CD 流水线中嵌入轻量级安全门禁。
- 对 AI 生成 Shell 脚本、SQL、基础设施即代码（IaC）有合规顾虑的企业。
常规风险
1. API Key 泄露：环境变量中存储的多供应商 Key 若被恶意进程读取，可能导致云资源滥用。
2. 提示注入：攻击者通过精心构造的 task description 诱导 LLM 绕过策略审查。
3. 过度信任：用户可能因「验证通过」标签而放松人工 review，形成单点失效。
4. 供应链污染：npx 执行依赖 npm 包完整性，若 registry 被投毒则引入恶意代码。
> 官方免责声明强调：moltblock 降低但不消除风险，作者不对由此产生的数据丢失或安全事件负责。