1. 项目概述Paperclip 不是回形针而是一个被严重误读的 AI 工具链枢纽“Paperclip”这个词一出来很多人第一反应是办公桌上那个弯弯扭扭的金属小物件——回形针。但在这个技术语境里它完全不是物理世界里的文具而是当前 AI 工具链生态中一个真实存在、正在被快速迭代、却极少被系统性梳理的轻量级协作层协议。它既不是 Node.js 框架也不是 React 组件库更不是 OpenClaw 或 Claude 的子模块它是夹在它们之间、负责“粘合”与“转译”的隐形胶水。我第一次在 GitHub 上看到paperclip-ai/paperclip这个仓库时也以为是某个玩具项目直到花三天时间跑通它的本地 demo才意识到它解决的是一个极其具体又极其普遍的痛点——当你的前端用 React 渲染 UI后端用 Node.js 提供服务AI 能力来自 Claude 或本地部署的 OpenClaw三者各自运转良好却在数据格式、调用方式、错误处理、上下文传递上频繁‘掉链子’时Paperclip 就是那个帮你把螺丝拧紧的人。它的核心价值不在于炫技或重构而在于“最小干预下的最大兼容”。比如你用 React 写了一个文件上传组件用户拖进一个 PDF你想立刻调用 OpenClaw 做结构化解析再把结果喂给 Claude 做摘要生成——传统做法是你得手写三段胶水代码一段把 React 的 File 对象转成 Node.js 可读的 Buffer一段把 Buffer 传给 OpenClaw 的 /parse 接口并处理 multipart/form-data 边界一段再把 OpenClaw 返回的 JSON 结构按 Claude API 要求的 message 数组格式重包装。而 Paperclip 的设计思路很朴素它定义了一套极简的、基于 JSON Schema 的中间契约Contract要求所有参与方——无论是 React 前端、Node.js 后端还是 OpenClaw 或 Claude 的适配器——都只跟这个契约对话。React 只需按契约发{type: document, content: base64}Node.js 只需按契约收并转发OpenClaw 和 Claude 的适配器则各自实现“契约 → 本体 API”的翻译逻辑。整个链路里没有一方需要知道对方的技术栈也没有一行跨域代理或 CORS 配置需要你手动敲。这解释了为什么它会高频出现在“node.js 安装教程”“react 面经”“openclaw ubuntu 安装教程”这些看似不相关的热搜词里——因为真正用起来的人不是在学 Paperclip 本身而是在解决“怎么让刚装好的 Node.js 18.20.4 LTS 和刚搭好的 React 18 Vite 项目能稳稳地把请求甩给本地跑起来的 OpenClaw再把结果喂给 Claude Code 插件”这个现实问题。它不教你怎么写 React Hooks但它决定了你写的useMutation最终能不能拿到一个结构清晰的data.summary而不是一堆undefined它不讲 Node.js 的 event loop但它决定了你express路由里写的res.json()是返回成功响应还是因 MIME 类型错位被前端静默吞掉。所以这篇内容不是 Paperclip 的官方文档复述而是我过去四个月在三个真实客户项目里——一个法律合同分析 SaaS、一个教育机构的课件智能生成后台、一个硬件公司的设备日志诊断工具——踩坑、调试、重构后沉淀下来的实操手册。它不假设你已经会部署 OpenClaw也不预设你熟悉 Claude 的 streaming response 解析它从“你刚下载完 node-v18.20.4-linux-x64.tar.xz解压完 PATH 也配好了现在想让 React 页面点个按钮就调用本地 AI”这个最原始的起点开始。2. 整体架构设计与选型逻辑为什么是 Paperclip而不是自己造轮子2.1 核心矛盾AI 工具链的“三明治困境”我们先直面一个事实当前主流的 AI 应用开发并非单点突破而是典型的“三明治架构”——前端React是用户触达层后端Node.js是业务逻辑与调度层AI 引擎Claude/OpenClaw是能力供给层。这三层各自进化速度极不均衡React 生态每季度就有新 Hook 模式涌现Node.js LTS 版本半年一更而 OpenClaw 从 v0.3 到 v0.5 的 API 兼容性断层Claude 的/v1/chat/completions接口在 streaming 模式下对delta.content字段的空值处理规则都可能在一次 minor 版本更新里悄然改变。这种异步演进导致的直接后果就是“胶水代码”爆炸式增长。我在第二个客户项目里统计过一个支持 PDF 解析摘要问答的 5 个页面功能光是前后端之间为适配不同 AI 服务而写的类型转换、错误码映射、重试逻辑就占了全部后端代码的 37%。更糟的是这部分代码几乎无法复用——今天适配 OpenClaw 的parse_result结构明天换 Claude 就得全重写今天 React 用useState管理 loading 状态明天换成useReducer胶水层就得跟着改状态更新逻辑。Paperclip 的设计哲学正是针对这个“三明治困境”提出的外科手术式解法它不试图统一技术栈那不现实也不强行规定数据模型那太僵化而是引入一个轻量级、可插拔的“契约层”Contract Layer。这个层不运行在任何具体进程里它是一组 JSON Schema 文件 一套约定俗成的 HTTP 头部规范 一个极简的运行时校验器。你可以把它理解成“API 的宪法”——React 开发者只需承诺“我的上传接口一定返回符合document-upload.v1.jsonSchema 的 JSON”Node.js 开发者只需承诺“我的路由/api/ai/process一定接收符合ai-request.v1.json的 POST body”OpenClaw 的运维人员只需确保其/parse接口输出满足openclaw-parse-result.v1.json。至于中间怎么传、用什么序列化、要不要 gzipPaperclip 一概不管它只在关键节点做两件事校验输入是否合法封装输出是否合规。这种设计天然规避了传统 BFFBackend for Frontend模式的臃肿——BFF 往往要写大量路由转发、字段重命名、错误码转换而 Paperclip 的校验器Validator和封装器Wrapper加起来不到 200 行 TypeScript且可独立部署为一个 sidecar 进程不侵入主业务逻辑。2.2 为什么不是 GraphQL为什么不是 gRPC为什么不是自研协议这个问题我被问过至少 17 次每次都在客户现场白板上画图解释。简单说GraphQL 太重gRPC 太底层自研协议太危险。GraphQL 的问题在于“过度设计”。它要求前端精确声明所需字段这对 AI 场景是灾难性的。比如你调用 Claude 做摘要前端不可能预知返回的summary字段里会不会嵌套一个key_points数组更不可能提前声明key_points[].confidence_score是否存在。GraphQL 的强类型 schema 在 AI 的不确定性输出面前反而成了枷锁。Paperclip 的契约是“宽松验证”它允许additionalProperties: true只要核心字段如type,content,status存在且类型正确其余字段一律透传。这符合 AI 输出的天然混沌性。gRPC 的问题在于“基础设施门槛”。它依赖 Protocol Buffers 编译、HTTP/2 支持、TLS 配置在客户现场——尤其是那些还在用 CentOS 7.9、内核 3.10、连systemd都没升级的老旧服务器上——部署 gRPC 服务光是 OpenSSL 版本兼容性就能耗掉两天。而 Paperclip 完全基于 HTTP/1.1 JSONcurl -X POST http://localhost:3000/api/paperclip/process -H Content-Type: application/json -d {type:text,content:hello}这条命令在任何有 curl 的机器上都能跑通。它的最低运行环境就是 Node.js 16连 npm 都不是必须的——你可以用npx paperclip-validatorlatest --schema document-upload.v1.json --input ./test.json直接校验。自研协议的问题在于“生态真空”。我见过太多团队雄心勃勃设计自己的“AI 通信协议”结果半年后发现前端团队没人愿意写配套的 React Hook后端团队拒绝维护双协议旧 REST 新自研AI 团队的 OpenClaw 适配器根本没人接手。Paperclip 的聪明之处在于它不做协议只做“协议解释器”。它不发明新动词如POST /ai/v2/execute而是复用现有 HTTP 动词和路径只在请求体和响应体里强制注入契约元数据如contract: ai-request.v1。这意味着你现有的 Express 路由app.post(/api/ai/process, ...)不用改只需在 handler 里加一行const validated await paperclip.validate(req.body, ai-request.v1);你现有的 Reactfetch(/api/ai/process)也不用动只需在.then(res res.json())后加一行const result paperclip.unwrap(response, ai-response.v1);。零学习成本零架构改造这是它能在掘金、知乎、V2EX 上被自发传播的根本原因——它解决的是“最后一公里”的落地痛而不是“第一公里”的理论美。2.3 Paperclip 与 OpenClaw/Claude 的真实关系不是替代而是“翻译官”这里必须划清一个关键界限Paperclip 既不是 OpenClaw 的替代品也不是 Claude 的客户端 SDK。它的定位是“AI 服务的通用适配器抽象层”。对 OpenClaw 而言Paperclip 是一个“标准化入口”。OpenClaw 本身提供/parse解析、/extract抽取、/classify分类等多个独立 endpoint每个 endpoint 的输入格式如/parse要multipart/form-data/extract要application/json、输出结构/parse返回pages[]/extract返回entities[]都不一致。Paperclip 的openclaw-adapter模块做的就是把统一的ai-request.v1契约请求根据operation字段如operation: parse自动路由到对应 OpenClaw endpoint并完成格式转换。比如契约里{type: document, content: base64...}适配器会把它解码成二进制流用form-data包装再 POST 给 OpenClaw收到 OpenClaw 的原始响应后再提取pages[0].text塞进契约规定的result.text字段里返回。整个过程业务代码只跟契约打交道完全不知道 OpenClaw 的细节。对 Claude 而言Paperclip 是一个“流式响应的缓冲器”。Claude 的/v1/chat/completions接口支持stream: true返回的是text/event-stream每个 chunk 是data: {delta: {content: a}}。但 React 前端的fetchAPI 天然不支持流式解析传统做法是用ReadableStreamTextDecoder手动拼接极易出错。Paperclip 的claude-adapter内置了一个轻量级流处理器它接收 Claude 的 raw stream逐 chunk 解析delta.content累积成完整字符串当检测到finish_reason: stop时触发一次完整的ai-response.v1响应事件。前端用useEffect监听这个事件就能像处理普通 JSON 一样拿到最终结果无需关心底层流机制。更重要的是这个处理器还内置了超时熔断默认 60s、token 用量统计从usage.prompt_tokens提取、错误归一化把 Claude 的429 Too Many Requests统一转为契约里的status: rate_limited——这些都是你在axios.post(https://api.anthropic.com/v1/messages, ...)里永远得不到的开箱即用能力。提示Paperclip 的适配器Adapter不是黑盒。它的源码全部开源且每个适配器都遵循同一套模板inputMapper契约 → 本体 API、outputMapper本体 API → 契约、errorMapper本体错误 → 契约错误。这意味着如果你要用 DeepSeek 替代 Claude只需复制claude-adapter目录改写三个 mapper 函数5 分钟就能产出deepseek-adapter。这才是它对抗“AI 服务碎片化”的真正武器——不是绑定某一家而是提供一套可复用的适配范式。3. 核心细节解析与实操要点从零搭建一个 Paperclip 可用链路3.1 环境准备Node.js 18.20.4 LTS React 18.2.0 的最小可行组合别被网上铺天盖地的“node.js 22.12 安装教程”带偏。Paperclip 的官方推荐运行环境是 Node.js 18.20.4 LTS截至 2024 年 10 月的最新长期支持版原因很实在LTS 版本的 ABIApplication Binary Interface稳定与绝大多数原生模块如sharp图片处理、sqlite3数据库兼容性最好且企业级部署中接受度最高。我亲眼见过客户在生产环境升级到 Node.js 20 后OpenClaw 的libpdfium依赖因 ABI 不匹配直接崩溃回滚花了 6 小时。所以严格按以下步骤操作下载与安装 Node.js 18.20.4访问 https://nodejs.org/dist/v18.20.4/ 注意不是官网首页而是明确指定版本的 dist 目录根据你的系统选择Linux x64:node-v18.20.4-linux-x64.tar.xzmacOS Intel:node-v18.20.4-darwin-x64.tar.gzWindows x64:node-v18.20.4-x64.msi注意不要用nvm或fnm自动安装因为它们可能拉取到非 LTS 的 18.x 版本如 18.19.0而 Paperclip 的paperclip-validator依赖zod3.22.4该版本在 Node.js 18.19.0 下有已知的BigInt序列化 bug。手动下载确保版本绝对精准。解压与配置 PATH# Linux/macOS 示例 tar -xf node-v18.20.4-linux-x64.tar.xz sudo mv node-v18.20.4-linux-x64 /opt/nodejs-18.20.4 echo export PATH/opt/nodejs-18.20.4/bin:$PATH ~/.bashrc source ~/.bashrc node -v # 应输出 v18.20.4 npm -v # 应输出 9.9.2随 Node.js 18.20.4 自带创建 React 项目Vite 驱动Paperclip 的前端集成强烈推荐 Vite 而非 Create React AppCRA因为 Vite 的 HMR热模块替换对paperclip/reactHook 的响应更灵敏且构建产物体积小 40%。执行npm create vitelatest my-paperclip-app -- --template react cd my-paperclip-app npm install # 安装 Paperclip React 客户端 npm install paperclip/react # 启动开发服务器 npm run dev此时访问http://localhost:5173你应该看到标准的 Vite React 欢迎页。关键一步打开src/main.jsx确认React.StrictMode包裹存在因为paperclip/react的usePaperclipMutationHook 依赖 Strict Mode 的双渲染机制来确保状态一致性。3.2 Paperclip 核心契约Contract的定义与校验逻辑Paperclip 的灵魂是它的契约Contract。它不是一个抽象概念而是一个具体的 JSON Schema 文件存放在项目根目录的contracts/文件夹下。我们以最常用的ai-request.v1.json为例拆解其设计意图{ $schema: https://json-schema.org/draft/2020-12/schema, $id: https://paperclip.ai/schemas/ai-request.v1.json, title: AI Request Contract v1, description: A standardized request format for AI operations., type: object, required: [type, content, operation], properties: { type: { type: string, enum: [text, document, image, audio], description: The primary data type being processed. }, content: { oneOf: [ {type: string, description: Base64 encoded content for binary types.}, {type: string, description: Plain text for text type.} ] }, operation: { type: string, enum: [summarize, extract, classify, generate], description: The AI operation to perform. }, metadata: { type: object, properties: { user_id: {type: string}, session_id: {type: string} }, additionalProperties: false, description: Optional context metadata, strictly typed. } }, additionalProperties: true, description: Additional fields are allowed but ignored by core validators. }这个 Schema 看似简单但每一行都经过实战打磨required: [type, content, operation]这三个字段是契约的“铁三角”缺一不可。type决定后续如何解码content文本直接JSON.parse文档需atoboperation决定路由到哪个 AI 服务。我曾在一个项目里因前端漏传operation导致后端switch (req.body.operation)默认分支返回 500而 Paperclip 的校验器会在validate()阶段就抛出ValidationError: Missing required property operation把错误拦截在入口避免无效请求打到 AI 服务上浪费 token。content的oneOf设计这是 Paperclip 处理“多态数据”的精髓。它不强制content必须是 string 或必须是 base64而是根据type的值动态约束。当type: text时content就是纯文本当type: document时content就是 base64 字符串。校验器会自动识别type值并应用对应的子 Schema。这种设计让同一个契约能优雅支撑多种输入而不用为每种类型定义单独的契约文件。metadata的additionalProperties: false这是一个安全边界。它允许你传user_id和session_id这类关键上下文但禁止传password、api_key等敏感字段——因为additionalProperties: false会严格拒绝任何未在properties中声明的字段。这比在业务代码里手动delete req.body.password更可靠是契约层的安全兜底。校验逻辑的实操代码Node.js 后端// src/middleware/paperclipValidator.js import { z } from zod; import { fileURLToPath } from url; import { readFileSync } from fs; // 动态加载契约 Schema const contractDir fileURLToPath(new URL(../contracts/, import.meta.url)); const aiRequestSchema JSON.parse( readFileSync(${contractDir}/ai-request.v1.json, utf8) ); // 使用 Zod 将 JSON Schema 转为可执行校验器 const AiRequestValidator z.object({ type: z.enum([text, document, image, audio]), content: z.string(), operation: z.enum([summarize, extract, classify, generate]), metadata: z.object({ user_id: z.string().optional(), session_id: z.string().optional() }).optional() }).strict(); // .strict() 对应 JSON Schema 的 additionalProperties: false export async function validateAiRequest(req, res, next) { try { // Paperclip 要求请求头包含契约标识 const contractVersion req.headers[x-paperclip-contract]; if (!contractVersion || !contractVersion.startsWith(ai-request.)) { throw new Error(Missing or invalid X-Paperclip-Contract header); } // 执行校验 const validated AiRequestValidator.parse(req.body); // 将校验后的干净数据挂载到 req 对象供后续 handler 使用 req.paperclip { validated }; next(); } catch (error) { // 统一错误格式符合 Paperclip 契约 res.status(400).json({ status: invalid_request, error: error.message, timestamp: new Date().toISOString() }); } }实操心得校验器一定要放在 Express 的app.use()全局中间件之后但在具体路由app.post(/api/ai/process, ...)之前。我踩过的坑是把它放在路由 handler 里导致每个请求都要重新readFileSync加载 Schema 文件QPS 降了 30%。正确的做法是启动时一次性加载并缓存AiRequestValidator实例。3.3 OpenClaw 本地一键部署与 Paperclip 适配器接入OpenClaw 的 Ubuntu 安装教程网上很多但大多忽略了一个致命细节它依赖的libpoppler版本必须 22.02而 Ubuntu 20.04 默认的libpoppler-glib8是 20.02直接apt install poppler-utils会导致 PDF 解析失败报错Error: Unknown operator BI。以下是经过 3 台不同配置 Ubuntu 服务器验证的可靠流程安装依赖与编译环境sudo apt update sudo apt install -y build-essential cmake libcairo2-dev libglib2.0-dev libjpeg-dev libpng-dev libtiff-dev libwebp-dev # 升级 libpoppler 到 22.02 sudo apt install -y software-properties-common sudo add-apt-repository ppa:ubuntu-toolchain-r/test sudo apt update sudo apt install -y libpoppler-glib-dev22.02.0-0ubuntu0.20.04.1下载并编译 OpenClaw官方推荐源码编译deb 包常有 ABI 问题git clone https://github.com/openclaw/openclaw.git cd openclaw git checkout v0.5.1 # 使用已验证稳定的版本 mkdir build cd build cmake .. -DCMAKE_BUILD_TYPERelease make -j$(nproc) sudo make install # 验证安装 openclaw --version # 应输出 0.5.1启动 OpenClaw 服务# 创建配置文件 cat /etc/openclaw/config.yaml EOF server: host: 0.0.0.0 port: 8080 cors: [*] storage: type: memory EOF # 启动后台运行 nohup openclaw --config /etc/openclaw/config.yaml /var/log/openclaw.log 21 # 检查端口 ss -tuln | grep :8080接入 Paperclip AdapterPaperclip 官方提供了paperclip/openclaw-adapter但要注意它默认连接http://localhost:8080而 OpenClaw 的/parse接口要求multipart/form-data。Adapter 的核心代码如下简化版// src/adapters/openclaw.js import axios from axios; export class OpenClawAdapter { constructor(baseURL http://localhost:8080) { this.client axios.create({ baseURL }); } async parseDocument(base64Content) { // Step 1: 将 base64 解码为 Buffer const buffer Buffer.from(base64Content, base64); // Step 2: 构建 multipart/form-data const formData new FormData(); formData.append(file, new Blob([buffer]), document.pdf); // Step 3: 调用 OpenClaw /parse const response await this.client.post(/parse, formData, { headers: { ...formData.getHeaders(), // 自动设置 Content-Type 和 boundary Accept: application/json } }); // Step 4: 映射到 Paperclip 契约 return { type: document, content: response.data.pages?.[0]?.text || , metadata: { page_count: response.data.pages?.length || 0, parsed_at: new Date().toISOString() } }; } }在你的 Express 路由中使用import { OpenClawAdapter } from ./adapters/openclaw.js; const openclaw new OpenClawAdapter(); app.post(/api/ai/process, validateAiRequest, async (req, res) { try { const { type, content, operation } req.paperclip.validated; let result; if (operation parse type document) { result await openclaw.parseDocument(content); } else { throw new Error(Unsupported operation ${operation} for type ${type}); } // Paperclip 要求响应必须符合 ai-response.v1.json 契约 res.json({ status: success, result, timestamp: new Date().toISOString() }); } catch (error) { res.status(500).json({ status: ai_error, error: error.message, timestamp: new Date().toISOString() }); } });注意事项OpenClaw 的/parse接口对 PDF 大小有限制默认 10MB如果用户上传超大文件Paperclip 的校验器应在validateAiRequest中提前检查content.lengthbase64 字符串长度 * 0.75 ≈ 原始字节数并在status: invalid_request中返回max_size_exceeded错误避免请求打到 OpenClaw 后被其 413 错误中断导致前端无法区分是网络问题还是文件太大。4. 实操过程与核心环节实现从 React 前端发起一次完整的 AI 请求4.1 React 前端集成paperclip/reactHook 的深度用法paperclip/react不是一个简单的fetch封装它是一个专为 AI 流式场景设计的状态管理 Hook。它的核心是usePaperclipMutation它内部集成了请求生命周期管理、错误重试、加载状态、以及最重要的——流式响应的增量更新。我们以一个“上传 PDF → 解析 → 显示摘要”的完整流程为例// src/components/PdfAnalyzer.jsx import { useState, useRef, useCallback } from react; import { usePaperclipMutation } from paperclip/react; export default function PdfAnalyzer() { const [file, setFile] useState(null); const [summary, setSummary] useState(); const [isProcessing, setIsProcessing] useState(false); const fileInputRef useRef(null); // 配置 Paperclip Mutation const { mutate, isPending, error, reset } usePaperclipMutation({ // 指向后端 Paperclip 路由 url: /api/ai/process, // 契约版本必须与后端校验器一致 contract: ai-request.v1, // 成功回调当后端返回 status: success 时触发 onSuccess: (data) { // data.result 是符合契约的干净对象 setSummary(data.result.content); setIsProcessing(false); }, // 错误回调统一处理所有错误 onError: (err) { console.error(Paperclip request failed:, err); alert(AI processing failed: ${err.response?.data?.error || err.message}); setIsProcessing(false); }, // 配置重试AI 服务不稳定重试 2 次 retry: 2, // 重试延迟指数退避第一次 1s第二次 2s retryDelay: (attemptIndex) Math.pow(2, attemptIndex) * 1000 }); const handleFileChange useCallback((e) { const selectedFile e.target.files[0]; if (selectedFile selectedFile.type application/pdf) { setFile(selectedFile); // 重置状态 setSummary(); reset(); } else { alert(Please select a valid PDF file.); } }, [reset]); const handleSubmit useCallback(async () { if (!file) return; setIsProcessing(true); // 读取文件为 base64 const reader new FileReader(); reader.onload () { const base64Content reader.result.split(,)[1]; // 去掉 data:...;base64, 前缀 // 构造符合契约的请求体 const payload { type: document, content: base64Content, operation: summarize, // 注意这里调用的是 summarize但后端 adapter 会路由到 OpenClaw parse Claude generate metadata: { user_id: current-user-id, session_id: session- Date.now() } }; // 发起 Paperclip 请求 mutate(payload); }; reader.readAsDataURL(file); }, [file, mutate]); return ( div classNamepdf-analyzer input typefile ref{fileInputRef} onChange{handleFileChange} acceptapplication/pdf style{{ display: none }} / button onClick{() fileInputRef.current.click()} Select PDF /button button onClick{handleSubmit} disabled{!file || isProcessing} {isProcessing ? Processing... : Generate Summary} /button {summary ( div classNamesummary-output h3Summary:/h3 p{summary}/p /div )} /div ); }这段代码的关键点在于mutate(payload)的调用时机和 payload 结构mutate不是立即发送请求它是一个“触发函数”只有在handleSubmit被调用时才执行。这让你可以灵活控制何时发起请求比如加个确认弹窗而不是在组件挂载时就自动请求。payload必须 100% 符合契约type、content、operation一个都不能少且content必须是 base64 字符串reader.result.split(,)[1]是标准解法。如果content是File对象或ArrayBufferPaperclip 的校验器会直接报错Expected string, received object。onSuccess回调的data是契约化的纯净数据data.result.content就是最终的摘要文本不需要你再JSON.parse或data.result.data.summary这样层层钻取。这就是契约带来的确定性。4.2 后端 Node.js 服务Express 路由与 Paperclip 中间件的协同一个健壮的 Paperclip 后端绝不仅仅是app.post(/api/ai/process, ...)这一行。它需要分层处理校验层 → 调度层 → 适配层 → 错误归一层。以下是经过生产环境验证的完整 Express 路由结构// src/server.js import express from express; import { validateAiRequest } from ./middleware/paperclipValidator.js; import { OpenClawAdapter } from ./adapters/openclaw.js; import { ClaudeAdapter } from ./adapters/claude.js; const app express(); const PORT process.env.PORT || 3000; // 全局中间件 app.use(express.json({ limit: 10mb })); // 支持大 JSON app.use(express.urlencoded({ extended: true, limit: 10mb })); // 支持表单 app.use((req, res, next) { // Paperclip 要求所有响应必须有 Content-Type res.setHeader(Content-Type, application/json; charsetutf-8); next(); }); // 初始化适配器实例 const openclaw new OpenClawAdapter(http://localhost:8080); const claude new ClaudeAdapter(process.env.CLAUDE_API_KEY); // Paperclip 主路由 app.post(/api/ai/process, validateAiRequest, async (req, res