OpenClaw 这个开源项目我最早是在一个自动化工作流的讨论里看到的。它做的事情说起来不复杂把 Claude、GPT、Gemini 这些不同厂商的模型接口统一封装成一套配置格式你写一次 YAML后面在脚本、Bot、工作流里都能复用。v2026.3.2 这个版本之所以值得单独写一篇是因为它把「PDF 直接扔进去就能分析」这件事做成了原生能力同时把 SecretRef 凭证引用扩展到 64 个目标还补上了 STT 语音转文本接口。对经常要处理合同、白皮书、财务报表的人来说少一步格式转换就少一层信息损失。这篇面向的是本地文档分析场景你手上有一份 PDF想让它输出结构化摘要和风险点中间不折腾转图片、不手动复制文本。我会用 TaoToken 的统一 Key 作为模型接入层把 OpenClaw 的 PDF 分析工具、SecretRef 配置、以及三步验证动作串起来。读完你应该能自己跑通「上传 PDF → 解析输出 → 核对调用日志」这条链路而不是停在「配置看起来对」的阶段。1. 本地 PDF 分析的真实痛点与 OpenClaw 的定位先说清楚问题在哪。以前要让模型分析一份 PDF常见做法无非两条路一是把 PDF 转成图片逐页喂给多模态模型二是用工具抽文本再拼成 prompt。第一条路的问题是页数一多token 消耗陡增而且表格、脚注这类版面信息在转图后容易丢第二条路的问题是抽取质量参差双栏排版、扫描件、带水印的文档经常抽出一堆乱序文本模型拿到手也读不明白。我试过用某款转换工具处理一份 40 页的技术白皮书抽出来的文本里图表标题和正文混在一起模型总结时把图注当成了结论差点闹笑话。这类坑的本质是格式转换这一步不在模型的可控范围内你没法告诉它「这一块是表格别当正文读」。OpenClaw 的定位正好卡在这个环节。它本身不是模型而是一个统一接入层把不同厂商的 chat、PDF 解析、语音转文本能力抽象成tools配置。v2026.3.2 的原生 PDF 分析工具支持 Anthropic 和 Google 两个后端意味着你可以直接把pdfPath交给工具由后端完成版面理解和内容提取再把结果交给对话模型做总结。中间不需要你手写转换脚本。适合谁用三类人比较对口。第一类是经常处理合同、报告的运营和法务支持岗需要批量提取条款和风险点第二类是做论文综述的研究者几十篇 PDF 要快速过一遍第三类是搭自动化工作流的开发者想把「收到 PDF → 出摘要」做成一条可复用的 pipeline。如果你只是偶尔让模型读一页文字那用网页版对话就够了不必上 OpenClaw。这里要区分一个概念OpenClaw 负责「怎么调」TaoToken 负责「调到哪」。前者是工具编排层后者是模型接入层提供统一的 API 地址和 Key。两者配合你不需要为每个厂商单独维护一套认证逻辑。下面的配置都会围绕这个分工展开。2. TaoToken 统一 Key 的前置准备与 SecretRef 写法在写 OpenClaw 配置之前先把 Key 这件事理清楚。TaoToken 的控制台地址是 https://taotoken.net/console API 地址统一为 https://taotoken.net/api 注意这个地址不带任何查询参数填到配置文件里就是它本身。你需要做的是在控制台创建一个 API Key然后把它交给 OpenClaw 的 SecretRef 机制管理而不是硬编码在 YAML 里。SecretRef 是 v2026.3.2 重点升级的部分支持最多 64 个凭证目标。它的价值在于把敏感信息和配置分离YAML 里只写引用名真实值从环境变量读取。这样同一份配置文件可以在开发机、测试环境、生产环境之间复制不用改一行代码。对团队协作来说每个人本地设置自己的环境变量即可配置文件可以放心进版本库。具体操作分两步。第一步在 TaoToken 控制台生成 Key建议按用途命名比如tt-doc-analysis方便后面排查调用来源。第二步把 Key 写入环境变量。Linux 或 macOS 下用 exportWindows PowerShell 下用$env:语法两者不要混用。写完之后用echo确认一下变量确实生效这一步很多人跳过结果后面报 401 还在怀疑配置格式。# Linux / macOS export TAOTOKEN_API_KEYsk-你的TaoToken密钥 echo $TAOTOKEN_API_KEY # Windows PowerShell $env:TAOTOKEN_API_KEYsk-你的TaoToken密钥 echo $env:TAOTOKEN_API_KEY环境变量就绪后在 OpenClaw 配置里用secrets段落声明引用。注意value字段写的是${env:变量名}这种形式不是直接写 Key 本身。这里有个细节变量名要和你在终端里设置的完全一致大小写敏感。我见过有人终端里写TAOTOKEN_API_KEY配置里写taotoken_api_key结果 SecretRef 解析为空报错信息又不直观排查了半天。secrets: - name: taotoken-key value: ${env:TAOTOKEN_API_KEY}如果你有多个项目共用一套 OpenClaw 配置可以声明多个 SecretRef比如taotoken-key-prod和taotoken-key-dev分别指向不同的环境变量。64 个目标的上限对绝大多数团队都够用关键是命名要有规律别到后面自己都分不清哪个引用对应哪个环境。凭证轮换时只改环境变量配置文件不动这是 SecretRef 最实际的收益。3. 可复制的 OpenClaw 配置PDF 工具与模型接入这一节给出完整可复制的配置片段路径和字段名按 OpenClaw v2026.3.2 的写法来。核心是三块secrets声明凭证引用tools定义 PDF 分析器和对话模型workflows把两者串成一条链路。Base URL、Key、Model ID 三件套在每个 tool 里都要对齐缺一个就会在调用时报错。先看 PDF 分析工具的配置。type写pdf-analyzebackend选anthropic或googlemodel填对应的模型 ID。apiKeyRef指向前面声明的taotoken-keybaseURL填 TaoToken 的 API 地址。注意这里的 baseURL 是统一入口不需要按厂商再拼路径OpenClaw 会根据type自动路由。secrets: - name: taotoken-key value: ${env:TAOTOKEN_API_KEY} tools: - name: pdf-analyzer type: pdf-analyze backend: anthropic apiKeyRef: taotoken-key baseURL: https://taotoken.net/api model: claude-3-5-sonnet-20241022 - name: doc-chat type: anthropic-chat apiKeyRef: taotoken-key baseURL: https://taotoken.net/api model: claude-3-5-sonnet-20241022然后是工作流部分。下面这段配置描述的是接收一个 PDF 路径先走pdf-analyzer提取内容并生成摘要再把摘要交给doc-chat做进一步问答。prompt字段建议写具体一点比如「列出合同中的付款条款、违约责任、终止条件并标注页码」比「总结一下」得到的输出可用性高很多。workflows: - name: pdf-insight steps: - tool: pdf-analyzer input: pdfPath: ${file.path} prompt: 提取文档的核心条款与关键数据按章节输出结构化摘要标注风险点 output: parsed - tool: doc-chat input: message: 以下是文档解析结果\n${parsed}\n\n请用三段话概括并列出三个需要人工复核的地方 output: conclusion关于 STT 的配置也顺带提一句v2026.3.2 新增了语音转文本工具type写sttprovider按支持的选项填。如果你做的是会议纪要场景可以把音频先转文本再走doc-chat总结链路和 PDF 类似。不过本篇聚焦 PDFSTT 只作为版本更新点带过配置格式如下供需要的人参考。- name: voice-to-text type: stt provider: whisper language: zh apiKeyRef: taotoken-key baseURL: https://taotoken.net/api配置写完后建议先用openclaw validate --config openclaw.yaml做一次语法校验再启动。校验能抓出字段拼写错误和引用名不匹配的问题比直接跑起来看报错省时间。启动命令是openclaw run --config openclaw.yaml如果工作流里有 Telegram 之类的 channel记得把对应的 token 也放进环境变量。4. 三步验证上传样例 PDF、核对解析输出、确认调用日志配置看起来对不等于跑得通。这一节给三个可执行的验证动作按顺序做每一步都有明确的成功判据。别跳步尤其是第一步很多人直接拿正式文档测出了问题分不清是配置问题还是文档本身的问题。第一步准备一份结构清晰的样例 PDF。建议用 5 到 10 页、带标题层级和一张表格的文档比如公开的产品说明书或技术规范。把路径填进工作流的pdfPath触发一次运行。成功判据是工作流不报错parsed输出里有章节标题和表格内容的痕迹。如果输出是空的或者只有页眉页脚说明 PDF 解析后端没正确识别版面先换一份更简单的文档排除文件本身的问题。第二步核对解析输出。把parsed的内容打印出来重点看三处标题是否按层级保留、表格数据是否成组出现、页码引用是否准确。这一步不需要模型多聪明纯粹看提取质量。如果表格被拆成散落的单元格文本可以在prompt里加一句「表格内容请以行列表形式输出」引导后端按结构组织。核对通过后再进入问答环节否则后面模型给出的结论会建立在错误的输入上。第三步确认调用日志。在 TaoToken 控制台的调用记录里应该能看到对应时间点的请求包含模型 ID、token 消耗、响应状态。成功判据是状态为 200且请求的模型 ID 和你配置里写的一致。如果日志里查不到请求说明请求根本没发出去问题在 OpenClaw 的 baseURL 或网络层如果日志里有请求但状态是 401问题在 Key 或 SecretRef 解析。这一步是区分「配置错」和「网络错」的关键别跳过。三步都通过后再拿正式文档跑。正式文档往往有扫描件、加密、复杂版式出问题的概率高但有前面三步打底你能快速定位是文档特性导致的还是链路本身的问题。验证过程中建议保留每次的parsed输出方便对比不同 prompt 下的提取差异。5. 常见报错排查401、local proxy failed、reading choices、OAuth这一节按真实报错来。下面四类是我和周围人实际遇到过的每类给出触发条件和处理方向对照着看能省不少时间。401 Unauthorized。最常见触发条件基本是 Key 无效或没被正确读取。先确认环境变量在当前 shell 里确实存在echo一下再确认 YAML 里apiKeyRef的名字和secrets里声明的name完全一致最后确认baseURL填的是https://taotoken.net/api没有多拼路径或带多余参数。三者都对还报 401就去控制台看 Key 是否被禁用或额度耗尽。local proxy failed。这个报错通常出现在请求根本没到达服务端的时候和 Key 无关。检查本机网络是否能正常访问https://taotoken.net/api用curl发一个最简单的请求测试连通性。如果 curl 通而 OpenClaw 不通看 OpenClaw 是否配置了额外的网络层设置把它清掉再试。注意不要在任何配置里引入来路不明的转发设置统一走官方 API 地址最稳。reading choices 相关报错。这类报错一般出现在响应解析阶段意思是返回结构里找不到预期的choices字段。触发条件多是type和实际后端不匹配比如把 Anthropic 类型的 tool 指向了只返回 OpenAI 格式的端点。检查type字段和model是否属于同一厂商体系pdf-analyze的backend和model也要对齐。改完重启 OpenClaw 让配置重新加载。OAuth 相关报错。如果你用的是需要 OAuth 流程的接入方式报错往往和 token 过期或回调地址不匹配有关。处理方向是重新走一遍授权流程确认回调地址和配置里写的一致。对大多数本地文档分析场景来说用 API Key 方式更直接不需要引入 OAuth 这一层能少一个故障点就少一个。排查时有个通用技巧把 OpenClaw 的日志级别调高看它实际发出的请求 URL 和请求头里的认证字段是否存在。日志里能看到 URL 拼错、认证头缺失这类低级问题比对着报错猜快得多。另外每次改完配置记得重启进程部分字段是启动时加载的热改不生效。6. 把链路固定下来从一次跑通到日常复用一次跑通只是开始真正省时间的是把这条链路固定成可复用的模板。我的做法是把openclaw.yaml拆成两部分公共的secrets和tools放一个基础文件具体的工作流按场景分文件启动时用--config叠加。这样新增一个文档分析场景时只写工作流部分模型接入和凭证引用直接复用。另一个实用技巧是给prompt建一个小库。合同类、论文类、财报类各有一套固定的提取指令跑的时候按文档类型选。指令写得越具体输出越稳定返工越少。比如合同类固定要求「列出付款节点、违约条款、终止条件各标注页码」比每次临时想 prompt 一致性高得多。调用日志也值得定期看。TaoToken 控制台的记录能告诉你哪类文档消耗 token 多、哪类响应慢据此调整prompt长度或换更合适的模型。长期做文档分析的话可以考虑 Coding Plan 这类按周期计费的方式比按次调用更适合高频场景具体在 https://taotoken.net/coding-plan 看当前方案。如果你在接入过程中卡在某一步优先查接入文档 https://taotoken.net/doc 里面的字段说明和示例比对着配置改最快。需要新建或轮换 Key 就去 https://taotoken.net/api-keys 。想先确认模型本身能不能正常响应用模型对话页面发一条测试消息排除模型侧问题后再回到 OpenClaw 排查编排层。链路跑通之后剩下的就是按你的文档类型慢慢调 prompt这部分没有捷径跑得多了自然有手感。 
长河君 · 2026/10/24 19:21:24 · 阅读 1.2k OpenClaw v2026.3.2 实测：PDF 直接扔进去就能分析，这波更新真香｜TaoToken 统一 Key 接入
OpenClaw 这个开源项目我最早是在一个自动化工作流的讨论里看到的。它做的事情说起来不复杂把 Claude、GPT、Gemini 这些不同厂商的模型接口统一封装成一套配置格式你写一次 YAML后面在脚本、Bot、工作流里都能复用。v2026.3.2 这个版本之所以值得单独写一篇是因为它把「PDF 直接扔进去就能分析」这件事做成了原生能力同时把 SecretRef 凭证引用扩展到 64 个目标还补上了 STT 语音转文本接口。对经常要处理合同、白皮书、财务报表的人来说少一步格式转换就少一层信息损失。这篇面向的是本地文档分析场景你手上有一份 PDF想让它输出结构化摘要和风险点中间不折腾转图片、不手动复制文本。我会用 TaoToken 的统一 Key 作为模型接入层把 OpenClaw 的 PDF 分析工具、SecretRef 配置、以及三步验证动作串起来。读完你应该能自己跑通「上传 PDF → 解析输出 → 核对调用日志」这条链路而不是停在「配置看起来对」的阶段。1. 本地 PDF 分析的真实痛点与 OpenClaw 的定位先说清楚问题在哪。以前要让模型分析一份 PDF常见做法无非两条路一是把 PDF 转成图片逐页喂给多模态模型二是用工具抽文本再拼成 prompt。第一条路的问题是页数一多token 消耗陡增而且表格、脚注这类版面信息在转图后容易丢第二条路的问题是抽取质量参差双栏排版、扫描件、带水印的文档经常抽出一堆乱序文本模型拿到手也读不明白。我试过用某款转换工具处理一份 40 页的技术白皮书抽出来的文本里图表标题和正文混在一起模型总结时把图注当成了结论差点闹笑话。这类坑的本质是格式转换这一步不在模型的可控范围内你没法告诉它「这一块是表格别当正文读」。OpenClaw 的定位正好卡在这个环节。它本身不是模型而是一个统一接入层把不同厂商的 chat、PDF 解析、语音转文本能力抽象成tools配置。v2026.3.2 的原生 PDF 分析工具支持 Anthropic 和 Google 两个后端意味着你可以直接把pdfPath交给工具由后端完成版面理解和内容提取再把结果交给对话模型做总结。中间不需要你手写转换脚本。适合谁用三类人比较对口。第一类是经常处理合同、报告的运营和法务支持岗需要批量提取条款和风险点第二类是做论文综述的研究者几十篇 PDF 要快速过一遍第三类是搭自动化工作流的开发者想把「收到 PDF → 出摘要」做成一条可复用的 pipeline。如果你只是偶尔让模型读一页文字那用网页版对话就够了不必上 OpenClaw。这里要区分一个概念OpenClaw 负责「怎么调」TaoToken 负责「调到哪」。前者是工具编排层后者是模型接入层提供统一的 API 地址和 Key。两者配合你不需要为每个厂商单独维护一套认证逻辑。下面的配置都会围绕这个分工展开。2. TaoToken 统一 Key 的前置准备与 SecretRef 写法在写 OpenClaw 配置之前先把 Key 这件事理清楚。TaoToken 的控制台地址是 https://taotoken.net/console API 地址统一为 https://taotoken.net/api 注意这个地址不带任何查询参数填到配置文件里就是它本身。你需要做的是在控制台创建一个 API Key然后把它交给 OpenClaw 的 SecretRef 机制管理而不是硬编码在 YAML 里。SecretRef 是 v2026.3.2 重点升级的部分支持最多 64 个凭证目标。它的价值在于把敏感信息和配置分离YAML 里只写引用名真实值从环境变量读取。这样同一份配置文件可以在开发机、测试环境、生产环境之间复制不用改一行代码。对团队协作来说每个人本地设置自己的环境变量即可配置文件可以放心进版本库。具体操作分两步。第一步在 TaoToken 控制台生成 Key建议按用途命名比如tt-doc-analysis方便后面排查调用来源。第二步把 Key 写入环境变量。Linux 或 macOS 下用 exportWindows PowerShell 下用$env:语法两者不要混用。写完之后用echo确认一下变量确实生效这一步很多人跳过结果后面报 401 还在怀疑配置格式。# Linux / macOS export TAOTOKEN_API_KEYsk-你的TaoToken密钥 echo $TAOTOKEN_API_KEY # Windows PowerShell $env:TAOTOKEN_API_KEYsk-你的TaoToken密钥 echo $env:TAOTOKEN_API_KEY环境变量就绪后在 OpenClaw 配置里用secrets段落声明引用。注意value字段写的是${env:变量名}这种形式不是直接写 Key 本身。这里有个细节变量名要和你在终端里设置的完全一致大小写敏感。我见过有人终端里写TAOTOKEN_API_KEY配置里写taotoken_api_key结果 SecretRef 解析为空报错信息又不直观排查了半天。secrets: - name: taotoken-key value: ${env:TAOTOKEN_API_KEY}如果你有多个项目共用一套 OpenClaw 配置可以声明多个 SecretRef比如taotoken-key-prod和taotoken-key-dev分别指向不同的环境变量。64 个目标的上限对绝大多数团队都够用关键是命名要有规律别到后面自己都分不清哪个引用对应哪个环境。凭证轮换时只改环境变量配置文件不动这是 SecretRef 最实际的收益。3. 可复制的 OpenClaw 配置PDF 工具与模型接入这一节给出完整可复制的配置片段路径和字段名按 OpenClaw v2026.3.2 的写法来。核心是三块secrets声明凭证引用tools定义 PDF 分析器和对话模型workflows把两者串成一条链路。Base URL、Key、Model ID 三件套在每个 tool 里都要对齐缺一个就会在调用时报错。先看 PDF 分析工具的配置。type写pdf-analyzebackend选anthropic或googlemodel填对应的模型 ID。apiKeyRef指向前面声明的taotoken-keybaseURL填 TaoToken 的 API 地址。注意这里的 baseURL 是统一入口不需要按厂商再拼路径OpenClaw 会根据type自动路由。secrets: - name: taotoken-key value: ${env:TAOTOKEN_API_KEY} tools: - name: pdf-analyzer type: pdf-analyze backend: anthropic apiKeyRef: taotoken-key baseURL: https://taotoken.net/api model: claude-3-5-sonnet-20241022 - name: doc-chat type: anthropic-chat apiKeyRef: taotoken-key baseURL: https://taotoken.net/api model: claude-3-5-sonnet-20241022然后是工作流部分。下面这段配置描述的是接收一个 PDF 路径先走pdf-analyzer提取内容并生成摘要再把摘要交给doc-chat做进一步问答。prompt字段建议写具体一点比如「列出合同中的付款条款、违约责任、终止条件并标注页码」比「总结一下」得到的输出可用性高很多。workflows: - name: pdf-insight steps: - tool: pdf-analyzer input: pdfPath: ${file.path} prompt: 提取文档的核心条款与关键数据按章节输出结构化摘要标注风险点 output: parsed - tool: doc-chat input: message: 以下是文档解析结果\n${parsed}\n\n请用三段话概括并列出三个需要人工复核的地方 output: conclusion关于 STT 的配置也顺带提一句v2026.3.2 新增了语音转文本工具type写sttprovider按支持的选项填。如果你做的是会议纪要场景可以把音频先转文本再走doc-chat总结链路和 PDF 类似。不过本篇聚焦 PDFSTT 只作为版本更新点带过配置格式如下供需要的人参考。- name: voice-to-text type: stt provider: whisper language: zh apiKeyRef: taotoken-key baseURL: https://taotoken.net/api配置写完后建议先用openclaw validate --config openclaw.yaml做一次语法校验再启动。校验能抓出字段拼写错误和引用名不匹配的问题比直接跑起来看报错省时间。启动命令是openclaw run --config openclaw.yaml如果工作流里有 Telegram 之类的 channel记得把对应的 token 也放进环境变量。4. 三步验证上传样例 PDF、核对解析输出、确认调用日志配置看起来对不等于跑得通。这一节给三个可执行的验证动作按顺序做每一步都有明确的成功判据。别跳步尤其是第一步很多人直接拿正式文档测出了问题分不清是配置问题还是文档本身的问题。第一步准备一份结构清晰的样例 PDF。建议用 5 到 10 页、带标题层级和一张表格的文档比如公开的产品说明书或技术规范。把路径填进工作流的pdfPath触发一次运行。成功判据是工作流不报错parsed输出里有章节标题和表格内容的痕迹。如果输出是空的或者只有页眉页脚说明 PDF 解析后端没正确识别版面先换一份更简单的文档排除文件本身的问题。第二步核对解析输出。把parsed的内容打印出来重点看三处标题是否按层级保留、表格数据是否成组出现、页码引用是否准确。这一步不需要模型多聪明纯粹看提取质量。如果表格被拆成散落的单元格文本可以在prompt里加一句「表格内容请以行列表形式输出」引导后端按结构组织。核对通过后再进入问答环节否则后面模型给出的结论会建立在错误的输入上。第三步确认调用日志。在 TaoToken 控制台的调用记录里应该能看到对应时间点的请求包含模型 ID、token 消耗、响应状态。成功判据是状态为 200且请求的模型 ID 和你配置里写的一致。如果日志里查不到请求说明请求根本没发出去问题在 OpenClaw 的 baseURL 或网络层如果日志里有请求但状态是 401问题在 Key 或 SecretRef 解析。这一步是区分「配置错」和「网络错」的关键别跳过。三步都通过后再拿正式文档跑。正式文档往往有扫描件、加密、复杂版式出问题的概率高但有前面三步打底你能快速定位是文档特性导致的还是链路本身的问题。验证过程中建议保留每次的parsed输出方便对比不同 prompt 下的提取差异。5. 常见报错排查401、local proxy failed、reading choices、OAuth这一节按真实报错来。下面四类是我和周围人实际遇到过的每类给出触发条件和处理方向对照着看能省不少时间。401 Unauthorized。最常见触发条件基本是 Key 无效或没被正确读取。先确认环境变量在当前 shell 里确实存在echo一下再确认 YAML 里apiKeyRef的名字和secrets里声明的name完全一致最后确认baseURL填的是https://taotoken.net/api没有多拼路径或带多余参数。三者都对还报 401就去控制台看 Key 是否被禁用或额度耗尽。local proxy failed。这个报错通常出现在请求根本没到达服务端的时候和 Key 无关。检查本机网络是否能正常访问https://taotoken.net/api用curl发一个最简单的请求测试连通性。如果 curl 通而 OpenClaw 不通看 OpenClaw 是否配置了额外的网络层设置把它清掉再试。注意不要在任何配置里引入来路不明的转发设置统一走官方 API 地址最稳。reading choices 相关报错。这类报错一般出现在响应解析阶段意思是返回结构里找不到预期的choices字段。触发条件多是type和实际后端不匹配比如把 Anthropic 类型的 tool 指向了只返回 OpenAI 格式的端点。检查type字段和model是否属于同一厂商体系pdf-analyze的backend和model也要对齐。改完重启 OpenClaw 让配置重新加载。OAuth 相关报错。如果你用的是需要 OAuth 流程的接入方式报错往往和 token 过期或回调地址不匹配有关。处理方向是重新走一遍授权流程确认回调地址和配置里写的一致。对大多数本地文档分析场景来说用 API Key 方式更直接不需要引入 OAuth 这一层能少一个故障点就少一个。排查时有个通用技巧把 OpenClaw 的日志级别调高看它实际发出的请求 URL 和请求头里的认证字段是否存在。日志里能看到 URL 拼错、认证头缺失这类低级问题比对着报错猜快得多。另外每次改完配置记得重启进程部分字段是启动时加载的热改不生效。6. 把链路固定下来从一次跑通到日常复用一次跑通只是开始真正省时间的是把这条链路固定成可复用的模板。我的做法是把openclaw.yaml拆成两部分公共的secrets和tools放一个基础文件具体的工作流按场景分文件启动时用--config叠加。这样新增一个文档分析场景时只写工作流部分模型接入和凭证引用直接复用。另一个实用技巧是给prompt建一个小库。合同类、论文类、财报类各有一套固定的提取指令跑的时候按文档类型选。指令写得越具体输出越稳定返工越少。比如合同类固定要求「列出付款节点、违约条款、终止条件各标注页码」比每次临时想 prompt 一致性高得多。调用日志也值得定期看。TaoToken 控制台的记录能告诉你哪类文档消耗 token 多、哪类响应慢据此调整prompt长度或换更合适的模型。长期做文档分析的话可以考虑 Coding Plan 这类按周期计费的方式比按次调用更适合高频场景具体在 https://taotoken.net/coding-plan 看当前方案。如果你在接入过程中卡在某一步优先查接入文档 https://taotoken.net/doc 里面的字段说明和示例比对着配置改最快。需要新建或轮换 Key 就去 https://taotoken.net/api-keys 。想先确认模型本身能不能正常响应用模型对话页面发一条测试消息排除模型侧问题后再回到 OpenClaw 排查编排层。链路跑通之后剩下的就是按你的文档类型慢慢调 prompt这部分没有捷径跑得多了自然有手感。