工具生态系统——MCP 协议与动态工具构建

IronClaw 深度剖析（十）：工具生态系统——MCP 协议与动态工具构建

系列导读：在前面的篇章中，我们深入探讨了 IronClaw 的 WASM 沙箱、安全架构、调度系统和内存管理。本篇将聚焦于 IronClaw 最具扩展性的子系统——工具生态系统。从一个理念出发："描述你的需求，IronClaw 为你构建工具"，我们将拆解四层运行时架构、MCP 协议集成、WASM 插件系统和声明式技能机制。

当传统 AI 助手还在等待厂商发布新功能时，IronClaw 已经让 Agent 拥有了"自我进化"的能力。这背后的秘密，是一个精心设计的工具生态系统——它不仅是功能的堆砌，更是一套完整的能力生产、分发、执行和安全治理的基础设施。

---

一、工具系统全景：四层运行时与 13 种效果类型

1.1 四层运行时架构

IronClaw 的工具系统采用四层运行时设计，不同类别的扩展在各自专用的运行时中执行，形成从"最安全但受限"到"最灵活但需要更多信任"的连续谱系：

graph LR
    subgraph "Runtime Stack"
        direction TB
        
        subgraph "Layer 1: WASM Runtime"
            W1["WASM Component Model"]
            W2["wasmtime 沙箱"]
            W3["WIT 标准化接口"]
        end
        
        subgraph "Layer 2: MCP Runtime"
            M1["MCP Client"]
            M2["JSON-RPC / stdio"]
            M3["外部进程隔离"]
        end
        
        subgraph "Layer 3: Script Runtime"
            S1["Docker 沙箱"]
            S2["CLI 命令执行"]
            S3["stdout/stderr 捕获"]
        end
        
        subgraph "Layer 4: Native Runtime"
            N1["内置 Rust 代码"]
            N2["主机 API 直接访问"]
            N3["零开销调用"]
        end
    end
    
    Trust["信任等级"] --> W1
    Trust --> M1
    Trust --> S1
    Trust --> N1
    
    style W1 fill:#e8f5e9
    style M1 fill:#e3f2fd
    style S1 fill:#fff8e1
    style N1 fill:#fce4ec

WASM 运行时位于信任谱系的最顶端——它提供了最强的隔离保证，第三方工具必须在沙箱中执行，所有主机资源访问都经过显式授权。MCP 运行时通过独立的子进程与外部 MCP 服务器通信，利用操作系统的进程隔离机制保证安全。Script 运行时在 Docker 容器中执行 shell 命令，适合需要调用现有 CLI 工具的场景。Native 运行时则是 IronClaw 内置的核心功能，直接编译在二进制中，零额外开销。

1.2 ExtensionRuntime 枚举与 Capability 安全模型

这四层运行时被 Rust 的类型系统精确定义：

#[derive(Debug, Clone, PartialEq, Eq, Serialize, Deserialize)]
#[serde(rename_all = "snake_case")]
pub enum ExtensionRuntime {
    /// WASM Component Model tool —— 最高隔离级别
    Wasm,
    /// MCP (Model Context Protocol) server —— 进程级隔离
    Mcp,
    /// Shell script / CLI command —— Docker 容器隔离
    Script,
}

每种运行时都通过 Capability-based Security 模型与系统交互。每个工具必须在 .capabilities.json 中声明其所需的 EffectKind——系统定义了 13 种效果类型，涵盖从文件系统访问到金融交易的所有敏感操作：

EffectKind	含义	典型应用场景
ReadFilesystem	读取文件系统	读取本地文档、配置文件
WriteFilesystem	写入文件系统	保存下载的文件、写日志
DeleteFilesystem	删除文件	清理临时文件
Network	HTTP 网络请求	调用 GitHub、Google API
UseSecret	访问密钥	使用 OAuth Token、API Key
ExecuteCode	代码执行	运行计算脚本
SpawnProcess	派生进程	调用外部 CLI 工具
DispatchCapability	调用其他能力	工具链组合调用
ModifyExtension	修改扩展	安装/卸载工具
ModifyApproval	修改审批配置	动态调整安全策略
ModifyBudget	修改资源预算	调整配额限制
ExternalWrite	写入外部系统	发送邮件、发布消息
Financial	金融交易	支付、转账操作

这种细粒度的效果分类使得权限控制达到了"最小权限原则"的极致——一个 GitHub 工具只需要 Network + UseSecret 两种效果，绝不获得任何文件系统访问权。

---

二、MCP 协议集成：连接外部能力的标准化桥梁

2.1 什么是 MCP？

MCP（Model Context Protocol） 是 Anthropic 提出的一种开放协议，旨在标准化 AI 模型与外部工具、数据源之间的通信。IronClaw 通过 ironclaw_mcp crate 实现了完整的 MCP 客户端，使得 Agent 可以连接到任意兼容 MCP 的服务器，动态获取额外能力。

graph TB
    subgraph "IronClaw Agent"
        IC["IronClaw Core"]
        MC["ironclaw_mcp
MCP Client"]
        REG["Extension Registry"]
    end
    
    subgraph "Transport Layer"
        T1["stdio"]
        T2["SSE"]
        T3["HTTP"]
    end
    
    subgraph "MCP Servers"
        MS1["NEAR AI MCP"]
        MS2["Database MCP"]
        MS3["Custom MCP"]
    end
    
    IC --> MC
    MC --> REG
    MC --> T1
    MC --> T2
    MC --> T3
    T1 --> MS1
    T2 --> MS2
    T3 --> MS3
    
    MS1 -. "tools/list" .-> MC
    MS2 -. "tools/call" .-> MC
    
    style IC fill:#e8f5e9
    style MC fill:#e3f2fd
    style MS1 fill:#fff8e1
    style MS2 fill:#fff8e1
    style MS3 fill:#fff8e1

2.2 McpClient Trait：抽象的协议核心

IronClaw 的 MCP 实现围绕 McpClient trait 构建，支持多种传输方式（stdio、SSE、HTTP）：

#[async_trait]
pub trait McpClient: Send + Sync {
    /// 发送 JSON-RPC 请求并等待类型化响应
    async fn request<T: DeserializeOwned>(
        &self,
        method: &str,
        params: Option<Value>,
    ) -> Result<T, McpError>;

    /// 初始化 MCP 会话（协议握手）
    async fn initialize(&self) -> Result<ClientCapabilities, McpError>;

    /// 从 MCP 服务器列出可用工具
    async fn list_tools(&self) -> Result<Vec<McpTool>, McpError>;

    /// 调用 MCP 服务器上的工具
    async fn call_tool(
        &self,
        name: &str,
        arguments: Value,
    ) -> Result<McpToolResult, McpError>;
}

MCP 工具的数据结构与 IronClaw 的内部 Capability 系统无缝映射：

#[derive(Debug, Clone, Serialize, Deserialize)]
pub struct McpTool {
    pub name: String,
    pub description: Option<String>,
    pub input_schema: Value,  // JSON Schema，直接用于 LLM function calling
}

2.3 MCP 服务器注册表

MCP 服务器在 registry/mcp-servers/ 目录中以 JSON 文件注册，遵循声明式配置理念：

{
  "name": "near-ai-mcp",
  "display_name": "NEAR AI",
  "version": "0.1.0",
  "description": "NEAR AI MCP server",
  "command": "npx",
  "args": ["-y", "near-ai-mcp@latest"],
  "env": {
    "NEAR_AI_ENVIRONMENT": "mainnet"
  }
}

当用户启用一个 MCP 服务器时，IronClaw 会启动一个独立的子进程运行该服务器，通过 stdio 进行 JSON-RPC 通信。每个 MCP 服务器运行在自己的进程中，天然具备操作系统级的隔离。

关键设计决策：MCP 工具调用不绕过 IronClaw 的安全架构。每个从 MCP 服务器获取的工具都要经过与 WASM 工具相同的 Capability 审批流程——授权检查、参数验证、资源预算控制，一个不少。

---

三、WASM 工具插件架构：沙箱中的无限可能

3.1 WIT 标准化接口：工具世界的 USB-C

IronClaw 所有 WASM 工具都通过 wit/tool.wit 定义的标准接口与主机通信，这是整个插件系统的基石。WIT（Wasm Interface Types）是 WebAssembly Component Model 的接口描述语言，它取代了传统的 JSON ABI 指针传递，实现了类型安全、零拷贝的跨边界通信。

graph TB
    subgraph "WASM Component (Guest)"
        GT["Tool Implementation"]
        GE["execute(req) -> response"]
        GS["schema() -> string"]
        GD["description() -> string"]
    end
    
    subgraph "WIT Interface (tool.wit)"
        WI["export tool"]
        WH["import host"]
    end
    
    subgraph "Host Runtime"
        HH["HTTP Provider"]
        HS["Secrets Provider"]
        HT["Tools Provider"]
        HC["Clock Provider"]
        HW["Workspace Provider"]
    end
    
    GT --> GE
    GT --> GS
    GT --> GD
    GE --> WI
    GS --> WI
    GD --> WI
    WI --> WH
    WH --> HH
    WH --> HS
    WH --> HT
    WH --> HC
    WH --> HW
    
    style GT fill:#e8f5e9
    style WI fill:#e3f2fd
    style HH fill:#fff8e1
    style HS fill:#fff8e1

wit/tool.wit 完整接口定义：

package near:agent;

interface tool {
    /// 工具执行请求
    record request {
        params: string,      // JSON 序列化的参数
        context: string,     // JSON 序列化的执行上下文
    }

    /// 工具执行响应
    record response {
        output: option<string>,  // JSON 序列化的输出
        error: option<string>,   // 错误消息（如果有）
    }

    /// 执行工具
    execute: func(req: request) -> response;

    /// 返回工具的 JSON Schema（用于 LLM function calling）
    schema: func() -> string;

    /// 返回人类可读的描述
    description: func() -> string;
}

world sandboxed-tool {
    /// 工具导出此接口
    export tool;
    
    /// 工具可调用的主机能力
    import host;
}

interface host {
    /// HTTP 请求（受 allowlist 限制）
    http-request: func(req: http-request) -> result<http-response, string>;
    
    /// 密钥存储访问（受白名单限制）
    secret-exists: func(name: string) -> bool;
    secret-get: func(name: string) -> result<string, string>;
    
    /// 日志记录
    log: func(level: log-level, message: string);
}

这个接口设计的精妙之处在于它的极简性。每个工具只需要实现三个函数：execute 处理调用，schema 返回参数定义，description 返回功能说明。同时，工具可以通过导入的 host 接口请求 HTTP、访问密钥和记录日志——但这些操作都受到主机的严格管控。

3.2 四层资源限制：沙箱的执行边界

WASM 工具的执行受到四层资源限制的严密保护：

fn configure_store(store: &mut Store<StoreData>, limits: &WitToolLimits) 
    -> Result<(), WasmError> 
{
    // 第一层：Fuel —— 逐条指令的 CPU 计量
    store.set_fuel(limits.fuel)?;
    
    // 第二层：Epoch Interruption —— 超时强制中断
    store.epoch_deadline_trap();
    let ticks = (limits.timeout.as_millis() / EPOCH_TICK_INTERVAL.as_millis())
        .max(1) as u64;
    store.set_epoch_deadline(ticks);
    
    // 第三层：Store Limiter —— 内存/表/实例限制
    store.limiter(|data| &mut data.limiter);
    
    // 第四层：Host 白名单 —— HTTP/密钥访问控制
    // 在 WitToolHost 构建时配置
    Ok(())
}

限制层级	机制	默认配置	超限后果
Fuel	consume_fuel(true)	可配置指令数	FuelExhausted 错误
Epoch	epoch_interruption(true)	30 秒	异步强制中断
Store Limiter	WasmResourceLimiter	内存上限 (MB)	实例分配失败
Host 白名单	AllowlistedHttp + WhitelistedSecrets	按工具声明	请求被拒绝

这种多层防御的设计理念是：单一限制机制可能被绕过或存在漏洞，但四层同时失效的概率趋近于零。

3.3 热插拔：无需重启的工具生命周期

IronClaw 的工具注册表支持热插拔——安装、更新、卸载工具都不需要重启 Agent：

graph LR
    subgraph "Registry"
        RJ["registry/tools/*.json"]
    end
    
    subgraph "Lifecycle Manager"
        I["Install"]
        U["Update"]
        R["Remove"]
    end
    
    subgraph "Runtime State"
        C["Component Cache"]
        A["Active Tools"]
        CAP["Capability Set"]
    end
    
    RJ --> I
    RJ --> U
    RJ --> R
    I --> C
    U --> C
    R --> A
    C --> A
    A --> CAP
    
    style RJ fill:#e3f2fd
    style C fill:#e8f5e9

工具安装流程：从注册表 JSON 读取元数据 → 下载 WASM 制品（带 SHA256 校验）→ 编译为 Component → 提取 schema() 和 description() → 注册到 ExtensionRegistry → 更新 CapabilitySet。整个流程在运行时完成，正在进行的对话不受影响。

---

四、动态工具构建："描述即生成"

IronClaw 最具前瞻性的功能是动态工具构建。用户不需要等待官方发布新工具，只需要用自然语言描述需求，系统就能生成对应的 WASM 工具。

4.1 从描述到工具的完整流程

graph TB
    U["用户描述需求"]
    D["LLM 生成工具设计"]
    G["生成 Rust 代码"]
    C["编译为 WASM"]
    S["签名与校验"]
    R["注册到 Registry"]
    E["执行"]
    
    U -->|"我需要查询 Hacker News 热帖"| D
    D -->|"设计: hn_tool"| G
    G -->|"wit-bindgen + 业务逻辑"| C
    C -->|"wasm32-wasip2"| S
    S -->|"SHA256 + 签名"| R
    R -->|"热插拔加载"| E
    
    style U fill:#e8f5e9
    style E fill:#e8f5e9
    style C fill:#fff8e1

这个流程背后的核心理念是：工具 = 描述 + 实现。每个 WASM 工具由四个文件组成：

1. .wasm —— 编译后的 WASM 组件（执行实现）
2. schema() 导出 —— JSON Schema 参数定义
3. .capabilities.json —— 能力声明（HTTP allowlist、密钥需求）
4. registry/tools/*.json —— 注册表元数据

4.2 GitHub 工具：最佳实践案例

IronClaw 的 GitHub 工具（tools-src/github）是 WASM 工具的最佳实践典范。它实现了 30+ 个操作，覆盖了仓库、Issue、PR、分支、文件、Release、CI/CD 和 Webhook 的完整生命周期。

#[derive(Debug, Deserialize)]
#[serde(tag = "action")]
enum GitHubAction {
    #[serde(rename = "get_repo")]
    GetRepo { owner: String, repo: String },
    
    #[serde(rename = "create_issue")]
    CreateIssue { owner: String, repo: String, title: String, body: Option<String> },
    
    #[serde(rename = "search_code")]
    SearchCode { query: String, page: Option<u32>, limit: Option<u32> },
    
    #[serde(rename = "create_pull_request")]
    CreatePullRequest { owner: String, repo: String, title: String, 
                        head: String, base: String, body: Option<String> },
    // ... 30+ 操作
}

采用 #[serde(tag = "action")] 的 tagged enum 模式，每个操作是一个独立的变体，LLM 通过 action 字段区分不同操作。

安全防护措施同样值得借鉴：

// 路径遍历防护
fn validate_repo_path(path: &str) -> Result<(), String> {
    for segment in path.split('/') {
        if segment == ".." {
            return Err("Invalid path: path traversal not allowed".into());
        }
    }
    Ok(())
}

// Git ref 注入防护
fn validate_git_ref(ref_name: &str) -> Result<(), String> {
    if ref_name.contains("..") || ref_name.contains(':') 
        || ref_name.contains('?') || ref_name.contains('[')
        || ref_name.contains('\\') || ref_name.contains('^')
        || ref_name.contains('~') || ref_name.contains("@{") {
        return Err(format!("Invalid git ref: {}", ref_name));
    }
    Ok(())
}

GitHub 工具的 .capabilities.json 精确声明了所需的网络访问范围——只允许访问 api.github.com，且 Token 只能通过主机注入，工具本身永远无法读取原始凭证。

---

五、Skills 技能系统：声明式的工作流编排

如果说 WASM 工具是 IronClaw 的"肌肉"，那么 Skills 技能系统 就是它的"大脑皮层"——负责编排多个工具完成复杂任务。

5.1 SKILL.md：Markdown + YAML 的声明式技能定义

Skills 使用 Markdown 文件 + YAML frontmatter 的格式定义，存储在 skills/ 目录。这种格式的选择极具匠心——它既对人类友好（可在任何 Markdown 编辑器中阅读），又易于机器解析。

---
name: code_review
version: "1.0.0"
description: Review code changes for quality, security, and best practices
tags: [development, quality]
tools:
  - github
  - llm_context
parameters:
  - name: pr_url
    type: string
    description: URL of the pull request to review
    required: true
  - name: focus_areas
    type: array
    description: Specific areas to focus on
    default: ["security", "performance"]
triggers:
  - webhook: github.pr.opened
  - command: /review
---

# Code Review Skill

When a PR is opened, perform the following review steps:

1. Fetch PR details using `github.get_pull_request`
2. Get changed files using `github.get_pull_request_files`
3. For each file, analyze the diff
4. Check for:
   - Security vulnerabilities
   - Performance issues
   - Code style violations
5. Post review comments using `github.create_pr_review`

## Parameters

- PR URL: {{ pr_url }}
- Focus areas: {{ focus_areas | join(", ") }}

5.2 Skills 系统执行流程

graph TB
    subgraph "Trigger"
        T1["Webhook: github.pr.opened"]
        T2["Command: /review"]
        T3["Schedule: cron"]
        T4["Manual"]
    end
    
    subgraph "Skill Engine"
        L["Load SKILL.md"]
        P["Parse YAML frontmatter"]
        R["Tera Render: "]
        D["Resolve tool dependencies"]
    end
    
    subgraph "Execution"
        LLM["LLM Prompt"]
        TC["Tool Calling"]
        RES["Result"]
    end
    
    T1 --> L
    T2 --> L
    T3 --> L
    T4 --> L
    L --> P
    P --> R
    R --> D
    D --> LLM
    LLM --> TC
    TC --> RES
    
    style T1 fill:#e3f2fd
    style T2 fill:#e3f2fd
    style LLM fill:#e8f5e9

Skills 系统的解析和执行依赖两个核心 Rust crate：

依赖	用途
serde_yml	解析 YAML frontmatter
pulldown-cmark	解析 Markdown body
tera	模板引擎，处理 {{ param }} 插值

触发器系统支持四种触发方式：

#[derive(Debug, Clone, Serialize, Deserialize)]
#[serde(tag = "type", rename_all = "snake_case")]
pub enum SkillTrigger {
    Webhook { event: String },   // 外部事件（如 PR 打开）
    Command { pattern: String }, // 聊天命令（如 /review）
    Schedule { cron: String },   // 定时任务（cron 表达式）
    Manual,                       // 手动触发
}

当 Skill 被触发时，系统会：加载 SKILL.md → 分离 YAML frontmatter 和 Markdown body → 使用 Tera 引擎将参数插值到模板中 → 根据 meta.tools 加载所需的工具 → 将渲染后的指令交给 LLM 执行。

---

六、注册表发现机制：工具生态的"应用商店"

IronClaw 的 registry/ 目录是工具生态的中央枢纽，采用纯 JSON 的声明式格式，无需数据库即可管理工具的元数据、制品和认证信息。

6.1 注册表目录结构

registry/
├── tools/                    # WASM 工具注册表
│   ├── github.json
│   ├── gmail.json
│   ├── google_calendar.json
│   ├── slack_tool.json
│   ├── telegram_mtproto.json
│   ├── web_search.json
│   ├── llm_context.json
│   ├── portfolio.json
│   ├── composio.json
│   └── ...
├── channels/                 # 频道注册表
├── mcp-servers/              # MCP 服务器注册表
└── _bundles.json             # 预设工具包

6.2 注册表 JSON 格式

以 GitHub 工具的注册表条目为例：

{
  "name": "github",
  "display_name": "GitHub",
  "kind": "tool",
  "version": "0.2.5",
  "wit_version": "0.3.0",
  "description": "GitHub integration for repos, issues, PRs, branches, files, releases, and workflows.",
  "keywords": ["git", "code", "issues", "pull-requests", "repositories"],
  "source": {
    "dir": "tools-src/github",
    "capabilities": "github-tool.capabilities.json",
    "crate_name": "github-tool"
  },
  "artifacts": {
    "wasm32-wasip2": {
      "url": "https://github.com/nearai/ironclaw/releases/download/.../tool-github-0.2.5-wasm32-wasip2.tar.gz",
      "sha256": "33e99a0b6456dce59400082a906df9181b5692f17d75c92ba25cbfedc1a04762"
    }
  },
  "auth_summary": {
    "method": "manual",
    "provider": "GitHub",
    "secrets": ["github_token"],
    "setup_url": "https://github.com/settings/tokens"
  },
  "tags": ["default", "development"]
}

每个注册表条目包含：

字段	说明
name / display_name	内部标识符和人类可读名称
version / wit_version	工具版本和 WIT 接口版本
source	源码目录和能力声明文件路径
artifacts	WASM 制品的下载 URL 和 SHA256 校验
auth_summary	认证方式、所需密钥、设置指引
tags	分类标签（如 default、development）

SHA256 校验是安全链的关键一环——WASM 制品在下载后必须匹配注册表中声明的哈希值，否则会被拒绝加载。这防止了供应链攻击中的制品替换。

---

七、内置工具集：开箱即用的能力矩阵

IronClaw v0.28.2 内置了 13 个 WASM 工具，覆盖了开发者、办公、通信和研究四大场景：

工具	场景	操作数量	认证方式	标签
github	开发	30+	OAuth / PAT	default, development
gmail	通信	8+	OAuth	default, communication
google-calendar	办公	6+	OAuth	default, productivity
google-docs	办公	5+	OAuth	default, productivity
google-drive	办公	7+	OAuth	default, productivity
google-sheets	办公	6+	OAuth	default, productivity
google-slides	办公	4+	OAuth	default, productivity
slack	通信	10+	OAuth	default, communication
telegram	通信	6+	手动 (MTProto)	communication
web-search	研究	3+	API Key	default, research
llm-context	通用	5+	无	default, utility
portfolio	金融	4+	无	finance
composio	集成	20+	API Key	integration

Google 全家桶的集成尤其值得关注——日历、文档、表格、幻灯片和 Drive 五个工具共享 OAuth 认证基础设施，用户只需完成一次 Google 授权，即可使用全部五个工具。这种**认证共享（Shared Auth）**机制大大简化了用户体验。

---

八、工具调用完整链路：从 Capability 到 Effect

最后，让我们追踪一次工具调用的完整生命周期，将前文介绍的所有子系统串联起来。

sequenceDiagram
    participant User as 用户
    participant LLM as LLM Engine
    participant Reg as Extension Registry
    participant Auth as Authorization
    participant Wasm as WASM Runtime
    participant Host as Host Provider
    participant Ext as 外部 API

    User->>LLM: "Review this PR"
    LLM->>Reg: find_tool("github.get_pull_request")
    Reg-->>LLM: ToolRegistration
    
    LLM->>Auth: evaluate(grant, request)
    Auth->>Auth: check CapabilityGrant
    Auth->>Auth: match PermissionMode
    Auth->>Auth: validate effects bounds
    Auth->>Auth: check resource budget
    Auth-->>LLM: Decision: Allow
    
    LLM->>Wasm: execute(prepared_tool, host, request)
    Wasm->>Wasm: set_fuel(limits.fuel)
    Wasm->>Wasm: set_epoch_deadline(timeout)
    Wasm->>Wasm: instantiate component
    
    Wasm->>Host: http_request(api.github.com)
    Host->>Host: validate against allowlist
    Host->>Host: inject auth token
    Host->>Ext: HTTPS request
    Ext-->>Host: JSON response
    Host-->>Wasm: HTTP response
    
    Wasm->>Wasm: validate output
    Wasm-->>LLM: ToolResult (output + usage)
    LLM->>LLM: safety_engine.validate_output()
    LLM->>LLM: audit.log_execution()
    LLM-->>User: "PR review complete"

链路详解：

1. 工具发现：LLM Engine 通过 ExtensionRegistry.find_tool() 将 github.get_pull_request 解析为具体的 ToolRegistration
2. 授权检查：ApprovalEngine 验证 CapabilityGrant 是否覆盖该调用，检查 PermissionMode（Allow/Ask/Deny）
3. 参数验证：请求参数必须符合 schema() 返回的 JSON Schema
4. 沙箱准备：WASM Runtime 配置 Fuel、Epoch 超时、Store Limiter
5. Host 构建：根据能力约束构建 WitToolHost——只包含允许列表中的 HTTP 端点和白名单中的密钥
6. 执行：在沙箱中调用 execute()，工具通过 host 接口请求外部 API
7. 结果验证：SafetyEngine 验证输出是否包含敏感信息泄露
8. 审计：完整记录调用过程到审计日志

---

结语：工具生态的设计哲学

IronClaw 的工具生态系统体现了几个深刻的架构思想：

"安全不是限制，而是使能"。WASM 沙箱和 Capability 模型看似增加了复杂度，但正是因为这种安全感，IronClaw 才能放心地让用户动态安装第三方工具、执行 AI 生成的代码。安全基础设施投入越多，上层创新的空间越大。

"接口标准化是生态繁荣的前提"。wit/tool.wit 的三个函数定义（execute、schema、description）看似简单，却是整个插件经济的基石。任何能编译为 WASM 的语言都可以编写工具，任何符合 WIT 接口的工具都能无缝集成。

"声明式优于命令式"。从 .capabilities.json 到 SKILL.md 再到 registry/tools/*.json，IronClaw 大量采用声明式配置。人类和机器都能轻松读写这些文件，降低了参与生态的门槛。

"工具生态的终极目标是让 Agent 的能力边界只受限于用户的想象力，而不是供应商的排期。"

IronClaw 正在朝这个目标稳步迈进。下一篇，我们将深入探讨 IronClaw 的 LLM 集成层，看看它是如何在支持多种模型的同时，保持一致的抽象接口和高效的上下文管理的。

---

系列文章导航：

• （一）项目概览
• （二）Workspace 架构
• （三）引擎核心
• （四）WASM 沙箱
• （五）调度系统
• （六）安全架构
• （七）LLM 集成
• （八）内存系统
• （九）网络与通道
• （十）工具生态 ← 本文