1. 项目概述一个真实从业者眼中的 OpenClaw 架构复盘我第一次在 GitHub Trending 上看到 OpenClaw 的时候它刚发布不到 48 小时star 数已经冲到 3.2 万。作为一个从 2019 年就开始做 LLM 应用层架构、亲手搭过 7 套不同规模 agent 系统的工程师我的第一反应不是点 star而是立刻 clone 下来跑make dev—— 因为我知道这种爆发式增长背后要么是真有硬核设计要么就是埋着雷。结果三天后我在公司内部安全简报会上用 OpenClaw 的插件市场截图做了一页 PPT标题就一行字“我们上周上线的客服 agent如果用了它的 marketplace 插件现在可能正在把用户会话发往境外 IP。”这不是危言耸听是实测结果。OpenClaw 的核心关键词不是“智能”、不是“自主”而是可组合性composability和运行时隔离runtime isolation。它用一套轻量级 Rust 编写的 runtime把 LLM 调用、工具执行、状态流转全部抽象成标准化的 message bus 消息所有插件都必须通过 WASM 字节码加载在沙箱中执行整个系统没有全局状态所有 memory 都是显式声明、按 scope 生命周期管理。这套设计在纸面上非常漂亮也确实支撑了它一周内 100K star 的爆发。但问题出在落地细节上它的 WASM 沙箱默认允许网络调用插件 manifest.json 中的permissions字段被设计为可选而非强制而 marketplace 的审核机制只校验签名不扫描行为逻辑。于是那 400 个恶意插件全都是合法签名、合法 manifest、合法 WASM 字节码——只是在__start函数里悄悄开了一个 HTTP client。这篇文章不是教你怎么用 OpenClaw而是带你像拆解一台发动机一样一层层剥开它的 runtime、message bus、memory layer 和 plugin loader。我会告诉你为什么它的依赖管理用的是cargo-workspace Nix flake而不是 Docker Compose为什么它的 message bus 不用 Kafka 而是自研的clawbus它的 memory architecture 怎么用RocksDB LSM-tree实现毫秒级 snapshot 回滚以及最关键的——那些被官方文档一笔带过的“安全最佳实践”在真实生产环境里到底要补多少胶带才能跑得稳。如果你正在设计自己的 agent 框架或者正准备把现有系统升级为 agent 架构这篇复盘就是你该抄的第一份作业。2. 整体架构设计与核心权衡取舍2.1 为什么选择 WASM 作为插件载体而不是 Python 进程或 Docker 容器这是 OpenClaw 最常被问、也最容易被误解的设计点。很多人第一反应是“Python 插件多方便pip install 就能用为啥非要用 WASM”答案不是技术炫技而是三个硬性约束倒逼出来的冷启动延迟必须 50msOpenClaw 定位是“边缘侧 agent runtime”目标部署场景包括树莓派 5、Jetson Orin Nano 这类资源受限设备。Python 进程 fork venv 初始化平均耗时 320msDocker 容器启动哪怕 alpine 镜像在 ARM64 设备上也要 180ms而 WASM 模块加载 实例化在 Wasmtime 15.0 下实测均值是 12.7msP95 28ms。这个数字直接决定了它能否用于实时语音 agent 的 tool-calling 场景。内存隔离粒度必须达到 page-levelPython 进程间靠 OS 进程隔离但同一进程内多个插件共享 GIL 和 heap一个插件 malloc 泄漏会拖垮整个 runtimeDocker 容器虽然隔离强但每个容器至少占用 20MB 内存空闲状态而 OpenClaw 要求单节点支持 200 插件并发。WASM 的线性内存模型天然提供 64KB page 粒度的隔离且 runtime 可精确控制每个模块的内存上限--max-memory16777216实测单插件内存占用稳定在 3.2~4.8MB。跨平台 ABI 必须零妥协OpenClaw 要同时支持 x86_64 Linux、aarch64 macOS、riscv64 FreeBSD。Python C 扩展需要为每个平台编译 wheelDocker 镜像本质是 Linux kernel ABI 绑定。而 WASM 是纯字节码wasi-sdk 编译出的.wasm文件在任何支持 WASI 的 runtimeWasmtime/Wasmer/Spin上行为完全一致。我们在 Jetson Orin 上跑的web_search.wasm和在 M2 Mac 上跑的输入相同 query输出 token 流的 timestamp 差异不超过 3μs。提示WASM 不是银弹。它无法直接调用 host 的 GPU 加速如 CUDA所以 OpenClaw 把 embedding 模型推理、RAG 向量检索等重计算任务抽离为独立的claw-worker进程通过 Unix Domain Socket 与 WASM 插件通信。这是它架构里最关键的分层决策——把不可信代码插件和可信重载代码worker物理隔离。2.2 为什么放弃 Kafka/RabbitMQ自研clawbus消息总线OpenClaw 的 message bus 不是简单的 pub/sub而是承担了状态一致性保证、跨插件事务协调、可观测性注入点三重角色。Kafka 在这里会成为性能瓶颈和运维噩梦原因有三消息生命周期必须与 agent session 强绑定一个客服 agent 的完整会话可能跨越 5 个插件intent classifier → user profile lookup → product DB query → pricing calculator → email generator。Kafka 的 topic 是全局的consumer group offset 是持久化的一旦某个插件 crash整个 session 的消息就会卡在 partition 里导致后续插件收不到上下文。clawbus则采用 session-scoped channel每个 session 创建时bus 动态生成唯一session_id前缀的 channel如sess_abc123_toolcall所有该 session 的消息只在这个 channel 内流转session 结束自动 GC channel。实测 10K 并发 session 下channel 创建/销毁开销 0.8ms。消息序列必须严格保序且支持跨插件回溯LLM 的 tool-calling 是典型的 request-response 模式但 response 可能触发新一轮 tool-call。Kafka 的 partition 内保序但跨 partition即跨插件无法保证。clawbus采用 hybrid 顺序模型每个消息携带trace_id全局唯一和span_id当前插件内序号bus 内置一个轻量级 causal ordering engine当收到span_id3的消息时会检查span_id1,2是否已存在若缺失则缓存等待超时 200ms 后丢弃。这使得clawbus在 99.99% 场景下能还原出完整的 execution trace。可观测性必须嵌入协议层而非旁路采集Kafka 的 metrics如 lag、throughput是集群维度的无法关联到具体 agent session。clawbus的 wire protocol 在 header 中强制包含session_id、plugin_name、latency_ms、error_code四个字段所有消息经过 bus 时自动打点。我们在 Grafana 里能直接下钻到 “session_idxyz789的payment_gateway.wasm插件过去 1 小时内平均延迟 42ms错误率 0.3%其中 87% 错误是HTTP_429”。这种粒度是 Kafka Prometheus 旁路采集永远做不到的。2.3 Memory Architecture为什么不用 Redis而用 RocksDB 自定义 LSM-treeOpenClaw 的 memory 不是传统意义上的“记忆”而是结构化状态快照structured state snapshot。它要解决的核心问题是当 LLM 说“把上次查到的订单号发给财务系统”这个“上次”到底指哪次是 3 分钟前的会话还是 3 秒前的 tool-callOpenClaw 的答案是所有 memory 都是 scope-aware 的且必须支持 sub-millisecond 级别的 snapshot diff。Redis 作为通用 KV 存储在这里面临三个致命短板缺乏原生 scope 隔离Redis 的 namespace 是 key prefix 模拟的session:abc123:order_id和session:def456:order_id在物理上共用一个内存池GC 时无法按 scope 精确回收。OpenClaw 要求每个 session 的 memory 占用超过 5MB 时自动 trimRedis 的MEMORY PURGE是全局命令会误杀其他 session 数据。snapshot 性能不达标Redis 的BGSAVE是 fork() copy-on-write对 1GB 内存的实例fork 耗时可达 200ms期间主线程阻塞。而 OpenClaw 的clawmem模块基于 RocksDB 的 Column Family 特性为每个 session 创建独立 CFsnapshot 仅需GetSnapshot()O(1) NewIterator()O(log n)实测 10MB session memory 的 snapshot 生成时间稳定在 0.37ms。diff 计算无法下推Redis 的KEYS pattern是 O(N) 全量扫描无法高效计算两个 snapshot 的 delta。clawmem的底层存储是定制版 LSM-tree每个 memtable entry 带有version_id和op_typeINSERT/UPDATE/DELETEdiff(session_a, session_b)直接在 SSTable 层遍历 versioned entries复杂度 O(mn)10MB 数据 diff 耗时 1.2ms。注意clawmem不是替代 Redis而是专注 agent state。我们生产环境里clawmem存 session-specific order_id、user_preference、cart_itemsRedis 存 global cache如 product catalog、rate limit counter、distributed lock。两者分工明确不存在替代关系。3. 核心组件深度解析与实操要点3.1 Plugin LoaderWASM 沙箱的 7 层加固实践OpenClaw 的插件 loader 名叫clawload它不是一个简单的wasmtime::Instance::new()调用而是一套七层防护链。每一层都对应一个真实踩过的坑Bytecode Validation Layer在wasmtime的Config::wasm_backtrace_details(true)基础上增加 WASM spec 1.0 的 strict validation。重点拦截global.get $stack_pointer这类直接读写线性内存的指令——恶意插件常用此方式绕过 WASI syscall hook。WASI Import Hook Layer重写所有 WASI syscall 的 host binding。例如wasi_snapshot_preview1::args_get不直接返回 argv而是返回[/proc/self/cmdline]的固定字符串wasi_snapshot_preview1::sock_accept直接返回ERR_NOTSUP错误码。所有网络、文件、时钟 syscall 默认禁用插件 manifest 中声明permissions: [net:api.example.com]才开放对应域名。Memory Limit Enforcement Layerclawload启动时为每个插件实例分配独立LinearMemory并通过wasmtime::Store::add_fuel()注入燃料限制。计算公式fuel (max_memory_bytes / 65536) * 1000。当 fuel 耗尽实例立即 trap不会触发 OOM killer。Execution Timeout Layer不是简单的std::thread::sleep()而是利用wasmtime::Store::interrupt_handle()注册中断信号。每个插件函数调用前设置timeout_ms 5000超时后handle.interrupt()强制终止避免无限循环。Stack Trace Sanitization LayerWASM trap 时的 stack trace 默认包含 host 函数名如clawload::wasi::sock_connect这会暴露 runtime 内部结构。clawload在 trap handler 中用正则s/clawload::\w::\w/plugin_runtime/g替换所有 host frame只保留 wasm function name。Environment Variable Scrubbing Layerclawload启动插件前清空所有std::env::vars()只注入白名单变量CLAW_SESSION_ID,CLAW_PLUGIN_NAME,CLAW_RUNTIME_VERSION。防止插件通过getenv(HOME)探测 host 环境。Exit Code Normalization LayerWASM 的_start返回值是 i32但不同编译器约定不同。clawload统一将return 0映射为SUCCESSreturn 1~127映射为PLUGIN_ERRORreturn 128~255映射为RUNTIME_ERROR确保上层监控系统能准确分类故障。实操中我们发现第 2 层WASI Hook最容易被绕过。某次安全审计发现一个插件用wasi_snapshot_preview1::path_open打开/dev/tcp/api.example.com/443成功建立了 TLS 连接。根本原因是path_open的 flag 参数未被充分校验。我们在第 2 层后面紧急加了第 2.5 层PathSanitizer对所有path_*syscall 的path参数做正则匹配^/dev/(tcp|udp)/.*$直接拒绝。3.2 Message Bus (clawbus) 的协议设计与流量治理clawbus的 wire protocol 是二进制格式不是 JSON over HTTP。Header 固定 32 字节Body 可变长。Header 结构如下小端序OffsetSizeFieldDescription0x008trace_idu64, 全局唯一由 LLM gateway 生成0x084span_idu32, 当前插件内序号从 1 开始0x0C4parent_span_idu32, 上游插件的 span_id根消息为 00x102msg_typeu16, 1tool_call, 2tool_result, 3llm_request, 4llm_response0x122plugin_id_lenu16, plugin name 字符串长度0x144body_lenu32, Body 字节数0x188timestamp_nsu64, 纳秒级时间戳Body 是 Protocol Buffer 序列化后的二进制数据schema 定义在clawbus.proto中。关键设计点trace_id和span_id的生成规则trace_id是rand::thread_rng().gen::u64()确保无中心化生成压力span_id由插件 loader 在调用clawbus::send()前原子递增避免锁竞争。我们在压测中发现当 1000 插件并发调用send()span_id生成耗时从 0.02ms 升至 0.18ms于是改用 per-plugin thread-local counter回归到 0.03ms。msg_type2tool_result的幂等性保障LLM 可能重复发送同一个 tool_call插件必须能识别并返回缓存结果。clawbus在 broker 端维护一个(trace_id, span_id)的 bloom filter有效期 5 分钟。当收到重复消息broker 直接返回DUPLICATE错误码不投递到插件。流量整形Traffic Shaping策略clawbus不做限流而是做“请求整形”。每个插件注册时声明qps_limit: 10和burst: 5。broker 收到消息后先放入 per-plugin token bucket桶满则NACK并返回429 Too Many Requests。关键点在于burst令牌不随时间衰减而是每次ACK后补充 1 个确保突发流量能被平滑处理。我们在电商大促期间将payment_gateway.wasm的burst从 5 调到 20成功扛住 300% 的流量峰值。实操心得clawbus的监控 dashboard 必须包含三个黄金指标bus_latency_p95应 8ms、nack_rate应 0.1%、unacked_msg_count应 100。我们曾因unacked_msg_count持续 500发现是email_generator.wasm的 SMTP 连接池耗尽导致消息堆积。解决方案不是扩容 bus而是给该插件加了连接池健康检查心跳。3.3 Memory Architecture (clawmem) 的 Snapshot 与 Diff 实现clawmem的核心是SessionStore结构每个 session 对应一个 RocksDB Column Family。CF name 格式为sess_{session_id}_v{version}其中version是单调递增的 u64。clawmem的 snapshot 不是 RocksDB 的 native snapshot而是应用层实现// Snapshot 是一个只读 view包含 pub struct Snapshot { pub cf_handle: ArcColumnFamily, pub version: u64, pub created_at: Instant, } impl SessionStore { // 创建 snapshot获取当前 CF 的最新 version并创建只读 handle pub fn create_snapshot(self, session_id: str) - ResultSnapshot { let cf_name format!(sess_{}_v{}, session_id, self.current_version); let cf_handle self.db.cf_handle(cf_name)?; Ok(Snapshot { cf_handle: Arc::new(cf_handle), version: self.current_version, created_at: Instant::now(), }) } // Diff 两个 snapshot遍历两个 CF 的所有 key计算 delta pub fn diff(self, a: Snapshot, b: Snapshot) - ResultDelta { let mut delta Delta::default(); let mut iter_a self.db.iterator_cf(a.cf_handle.as_ref(), IteratorMode::Start)?; let mut iter_b self.db.iterator_cf(b.cf_handle.as_ref(), IteratorMode::Start)?; // 双指针归并遍历O(mn) 复杂度 while let (Some(ka), Some(kb)) (iter_a.next(), iter_b.next()) { match ka.0.cmp(kb.0) { Ordering::Equal { if ka.1 ! kb.1 { // value 不同 delta.updates.push((ka.0.to_vec(), ka.1.to_vec(), kb.1.to_vec())); } } Ordering::Less { delta.deletes.push(ka.0.to_vec()); // a 有 b 无 } Ordering::Greater { delta.inserts.push((kb.0.to_vec(), kb.1.to_vec())); // b 有 a 无 } } } Ok(delta) } }这个实现的关键优化点CF name 的 version 编码current_version不是时间戳而是AtomicU64::fetch_add(1, SeqCst)。因为时间戳在高并发下可能重复而原子计数器绝对唯一。我们在 10K QPS 下测试fetch_add耗时稳定在 0.8ns。Iterator 的预取优化RocksDB 的iterator默认 prefetch 16KB但对于clawmem的 small-key 场景key 平均 48Bvalue 平均 256B我们调大到set_prefetch_size(1024*1024)使diff的 IOPS 提升 3.2 倍。Delta 的压缩传输Delta结构序列化时不直接传 raw bytes而是用zstd压缩实测 10MB session memory 的 diff 压缩后 120KB网络传输耗时从 82ms 降至 3.1ms。生产环境中我们每天凌晨 2 点自动触发clawmem::gc_old_versions()删除created_at now - 7days的所有 CF。注意RocksDB 的DropColumnFamily是异步的必须配合db.wait_for_flush_memtable()确保物理删除完成否则磁盘空间不会释放。4. 生产环境实操全流程与关键配置4.1 从零搭建 OpenClaw 生产集群硬件选型与部署拓扑我们为 OpenClaw 设计的最小可行生产集群MVP Cluster包含 3 类节点不是传统 master-worker而是按职责划分节点类型数量硬件配置承载组件关键配置Gateway Node2HA8c16g, 200GB SSDclaw-gatewayLLM 接入层,claw-bus-brokerclaw-gateway:--max-concurrent-requests200,--llm-timeout-ms15000;claw-bus-broker:--max-connections5000,--token-bucket-rate1000Worker Node3弹性16c32g, 1TB NVMe, RTX 4090claw-worker重计算进程,claw-mem-dbRocksDB 实例claw-worker:--gpu-device0,--embedding-modelmultilingual-e5-large,--vector-dim1024;claw-mem-db:--max-open-files65536,--write-buffer-size256MBEdge NodeN按需4c4g, 64GB eMMC树莓派 5claw-runtimeWASM runtimeclaw-runtime:--wasm-enginewasmtime,--max-wasm-memory16MB,--plugin-cache-dir/var/cache/claw/plugins部署工具链我们放弃 Helm/Kustomize改用NixOSflake.nix。原因OpenClaw 的 Rust 依赖对 LLVM 版本极其敏感wasmtime0.43 要求 LLVM 17而 Nix 的 pure build 环境能 100% 复现构建结果。flake.nix核心片段{ inputs { nixpkgs.url github:NixOS/nixpkgs/nixos-23.11; rust-overlay.url github:oxalica/rust-overlay; }; outputs { self, nixpkgs, rust-overlay }: let system x86_64-linux; pkgs import nixpkgs { inherit system; overlays [ rust-overlay.overlays.default ]; }; in { # 定义 OpenClaw 运行时环境 packages.claw-runtime pkgs.rustPlatform.buildRustPackage { pname claw-runtime; version 0.8.2; src ./claw-runtime; cargoLock { lockFile ./claw-runtime/Cargo.lock; }; # 强制使用 LLVM 17 nativeBuildInputs with pkgs; [ llvm_17 ]; }; # 生成 NixOS 模块 nixosModules.claw { config, ... }: { services.claw-runtime { enable true; package self.packages.claw-runtime; settings { wasmEngine wasmtime; maxWasmMemory 16777216; # 16MB }; }; }; }; }这套方案让我们在 3 天内完成了从开发机到 500 边缘节点的灰度发布。关键经验不要在生产环境用cargo run或make dev。我们曾因忘记在claw-runtime的Cargo.toml中注释掉dev-dependencies导致生产节点加载了tokio-console内存泄漏 2GB/天。4.2 插件 Marketplace 的安全加固从 400 恶意插件中学到的 5 条铁律那 400 个恶意插件不是黑客的杰作而是开发者对 OpenClaw 安全模型的误读。我们从中提炼出 5 条必须写进 SOP 的铁律Manifest.json 的 permissions 字段必须强制声明禁止省略官方文档说permissions是可选的但生产环境必须设为 required。我们的 CI 流水线加入jq -e .permissions plugin/manifest.json校验失败则阻断发布。对于不需要网络的插件如math_calculator.wasm显式声明permissions: []。所有插件必须通过wabt工具链做静态分析wabt的wabt-validate能检测出 92% 的危险指令如global.set、table.grow。我们在 CI 中增加步骤wat2wasm --enable-all plugin/src/plugin.wat -o plugin/bin/plugin.wasm wasm-validate --enable-all plugin/bin/plugin.wasm # 必须返回 0 wasm-decompile plugin/bin/plugin.wasm | grep -q global\.set exit 1 # 禁止 global.setMarketplace 的插件签名必须绑定硬件指纹原始 OpenClaw 用 Ed25519 签名但私钥可能被盗。我们升级为TPM2.0 Ed25519双因子签名时私钥不出 TPM 芯片clawload启动时用tpm2_pcrread校验 host PCR 值不匹配则拒绝加载。这使得插件无法在未授权机器上运行。插件更新必须走 atomic swap禁止 inplace overwrite原始方案是mv new.wasm plugin.wasm更新过程中插件处于半损坏状态。我们改为# 更新流程 cp new.wasm plugin.wasm.tmp clawload --validate plugin.wasm.tmp # 静态验证 mv plugin.wasm.tmp plugin.wasm # 原子重命名 clawload --warmup plugin.wasm # 预热实例--warmup会创建一个 dummy instance 并调用_start确保插件能正常初始化。Marketplace 的插件必须附带 SBOMSoftware Bill of Materials我们要求所有插件提交时附带sbom.spdx.json由syft生成syft plugin.wasm -o spdx-jsonsbom.spdx.jsonSBOM 中必须包含wasi-sdk版本、clang版本、wabt版本。安全团队用spdx-tools扫描已知 CVE例如wasi-sdk 20.0有 CVE-2024-1234SBOM 中匹配到则自动拒收。注意这 5 条铁律我们花了 3 周时间才全部落地。最大的阻力不是技术而是说服开源社区接受“强制 manifest”和“TPM 绑定”。最终方案是官方 marketplace 保持宽松但我们自己的企业 marketplaceenterprise-claw-marketplace严格执行。4.3 生产监控与告警体系7 个必须盯死的核心指标OpenClaw 的监控不是堆 Grafana 面板而是围绕 7 个黄金信号构建闭环。每个信号都有对应的自动化处置脚本指标告警阈值触发动作处置脚本claw_runtime_wasm_instance_count 1500单节点内存泄漏风险killall -u clawuser systemctl restart claw-runtimeclaw_bus_nack_rate 0.5% 持续 5 分钟插件处理能力不足自动扩容claw-worker节点AWS ASGclaw_mem_unflushed_writes 10000RocksDB write stallrocksdb::pause_background_work() 通知 DBAclaw_plugin_load_time_ms 100msP95WASM 编译慢自动切换到预编译 cache/var/cache/claw/wasm-prebuilt/claw_llm_gateway_timeout_rate 2%LLM 服务不稳定切换备用 LLM endpointOpenRouter → Perplexityclaw_bus_latency_p95 12msBroker 过载临时降级claw-bus-broker的--max-connectionsclaw_runtime_cpu_usage_percent 95% 持续 10 分钟CPU 密集型插件失控pkill -f clawload.*plugin_name 发送 Slack 告警这些指标全部通过claw-exporter一个独立的 Rust 进程暴露为 Prometheus metrics。claw-exporter不采集原始日志而是直接读取各组件的 shared memory segment/dev/shm/claw_metrics避免日志解析开销。我们在压测中发现当claw-exporter用tail -f读日志CPU 占用达 40%改用 shared memory 后降至 1.2%。最有效的告警不是“CPU 高”而是“claw_runtime_wasm_instance_count在 2 分钟内增长 300%”。这通常意味着某个插件在while true { clawbus::send(); }死循环。我们的处置脚本会立即pstack该进程提取栈帧自动匹配到问题插件名然后systemctl stop claw-plugin${plugin_name}.service。5. 常见问题与实战排查技巧实录5.1 问题现象WASM 插件加载失败日志显示trap: out of bounds memory access排查路径这不是内存越界而是clawload的LinearMemory分配不足。WASM 模块在datasection 中声明了init10485761MB但clawload默认只分配 64KB。根因分析clawload的--max-wasm-memory参数单位是字节但很多开发者误以为是 KB。--max-wasm-memory65536是 64KB而插件需要1048576字节1MB。解决方案查看插件的datasectionwabt-wat2wasm --debug-name-section plugin.wat -o plugin.wasm然后wabt-wasm-decompile plugin.wasm | grep data.*init计算所需内存init_value * 65536WASM page size 是 64KB启动clawload时指定--max-wasm-memory1048576实操心得我们在 CI 中加入wasm-decompile检查自动提取datasection 的init值生成推荐的--max-wasm-memory参数。这个检查让插件加载失败率从 12% 降至 0.3%。5.2 问题现象claw-bus-brokerCPU 持续 100%strace显示大量epoll_wait排查路径epoll_wait高 CPU 通常意味着文件描述符泄露或事件循环阻塞。claw-bus-broker基于tokio我们用tokio-console连接# 在 broker 节点执行 RUSTFLAGS--cfg tokio_unstable cargo run -p claw-bus-broker --features console # 然后在另一台机器tokio-console http://broker-ip:6669发现 98% 的 task 卡在clawbus::send的await上。根因分析clawbus::send内部调用tokio::net::UnixStream::write_all()但某个插件的clawbus::recv()实现有 bug没有及时read()导致 socket send buffer 满write_all()无限 await。解决方案