1. 标书自动化为什么总卡在“Key 到处改”这一步先说结论OpenClaw 这类自动化框架本身能跑通“爬虫抓招标信息 → RPA 填充模板 → 模型生成正文”三段链路真正让人崩溃的往往不是流程设计而是每个环节都要单独配一次模型 Key。爬虫里写一个、RPA 脚本里写一个、正文生成再写一个改一次密钥要翻五六个文件这才是重复劳动的大头。标书生成这个场景对自动化的要求其实挺特殊。它不像普通的批量文案招标信息抓回来之后需要模型做三件事一是从一堆公告里判断哪些项目匹配自家业务二是把招标文件里的资质要求、评分办法、技术参数抽成结构化字段三是基于模板生成技术方案和服务承诺这类正文。这三件事分别发生在爬虫后处理、RPA 前置判断、正文生成三个阶段如果每个阶段调的是不同厂商的模型接口密钥管理就会变成一场灾难。我试过把三段链路拆开单独跑结果最耗时的不是写爬虫规则而是每次换模型都要重新对一遍 Base URL 和 Key。后来把三段链路的模型调用统一收敛到一个入口配置量直接降下来了。这篇就按“爬虫抓取 → RPA 填充 → 模型生成正文”的顺序把 OpenClaw 的接入配置和端到端验证动作写清楚目标是一次配置、多工具复用。适合谁看正在用 OpenClaw 或类似自动化框架做标书、投标文件批量生成的开发者手里有爬虫和 RPA 脚本、但模型调用散落各处想统一管理的同学以及想用一套 Key 同时喂给爬虫后处理、RPA 判断和正文生成三个环节的实践者。核心检索词先明确OpenClaw 标书自动生成、TaoToken 统一 Key、RPA 填充模板、爬虫抓取招标信息、模型生成正文。下面从环境准备开始一步步把链路搭起来。2. TaoToken 统一 Key 前置准备与 OpenClaw 环境接入2.1 为什么要在 OpenClaw 里做统一 KeyOpenClaw 的 Skill 机制允许你把爬虫、文件处理、RPA 联动拆成独立模块每个模块内部都可能发起模型请求。如果每个 Skill 各自维护一份 API Key会出现三个问题密钥轮换时要逐个改、不同 Skill 可能指向不同模型导致输出风格不一致、排查报错时分不清是哪个环节的 Key 失效。TaoToken 的做法是提供一个统一的 API 入口OpenClaw 里所有需要调模型的地方都指向同一个 Base URL 和同一个 Key模型 ID 按需切换。这样爬虫后处理用便宜快速的模型做初筛正文生成用能力更强的模型做长文但底层凭证只有一份。官网入口在这里https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 地址是 https://taotoken.net/api 注意 API 地址不带 UTM 参数配置时直接填这个。2.2 拿到 Key 之后先确认三件事在控制台创建好 API Key 之后别急着往 OpenClaw 里塞先确认三件事。第一Key 的权限范围是否覆盖你要用的模型有些 Key 只开了部分模型权限正文生成时切到另一个模型会报 403。第二确认计费方式标书生成这种场景单次请求的 token 量不小尤其是把整份招标文件塞进去做抽取的时候提前看清楚是按量还是套餐。第三把 Key 存到环境变量里不要硬编码进 Skill 代码。控制台地址https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API Keys 管理页https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。2.3 OpenClaw 侧的环境变量约定OpenClaw 的 Skill 运行在 Node 环境里推荐用.env文件管理凭证然后在 Skill 里通过process.env读取。这样爬虫 Skill、RPA 联动 Skill、正文生成 Skill 读的是同一份配置改 Key 只改一处。# .env 放在 OpenClaw 项目根目录 TAOTOKEN_API_KEYsk-你的实际Key TAOTOKEN_BASE_URLhttps://taotoken.net/api TAOTOKEN_MODEL_FAST你的快速模型ID TAOTOKEN_MODEL_STRONG你的强能力模型ID这里把模型 ID 也抽成变量是因为标书链路里不同阶段对模型的要求不一样。爬虫抓回来的公告做初筛用快速模型就够正文生成要写技术方案需要强能力模型。两个变量指向同一个 Base URL 和 Key切换只改模型 ID。2.4 安装 OpenClaw 所需 Skill按 excerpt 里的思路标书链路需要爬虫、文件处理、PDF 生成、RPA 联动四类 Skill。安装命令如下pnpm add openclaw/skill-crawler pnpm add openclaw/skill-file pnpm add openclaw/skill-pdf pnpm add openclaw/skill-rpa装完之后先别写业务逻辑用一条最小请求验证 Key 能不能通。这一步很关键很多人直接上完整流程报错了分不清是 Key 问题还是 Skill 问题。curl -X POST https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: $TAOTOKEN_MODEL_FAST, messages: [{role: user, content: 回复 ok}] }返回里能看到choices字段就说明 Key 和 Base URL 没问题。如果这里就报 401先别往下走去 API Keys 页面确认 Key 是否复制完整、有没有多余空格。2.5 把统一配置注入 OpenClaw SkillOpenClaw 的 Skill 里读取环境变量封装一个统一的模型调用函数后续爬虫后处理、RPA 判断、正文生成都调这个函数。// skills/llm-client.js const BASE_URL process.env.TAOTOKEN_BASE_URL; const API_KEY process.env.TAOTOKEN_API_KEY; export async function callModel({ model, messages, temperature 0.3 }) { const resp await fetch(${BASE_URL}/v1/chat/completions, { method: POST, headers: { Authorization: Bearer ${API_KEY}, Content-Type: application/json }, body: JSON.stringify({ model, messages, temperature }) }); if (!resp.ok) { const err await resp.text(); throw new Error(模型调用失败 ${resp.status}: ${err}); } const data await resp.json(); return data.choices[0].message.content; }这个函数就是整条链路的模型出口。爬虫抓完公告调它做初筛RPA 填充前调它判断字段正文生成调它写方案。Key 只有一份改的时候只改.env。3. 可复制配置爬虫、RPA、正文生成三段链路的 Key 复用3.1 爬虫抓取招标信息后的模型初筛配置爬虫 Skill 负责把招标公告和附件抓回来但抓回来的原始数据是脏的需要模型做一次结构化抽取和匹配度判断。这一步用快速模型因为公告数量多、单条内容短。// skills/tender-crawler.js import { skill, context } from claw; import { callModel } from ./llm-client.js; skill.register(name招标数据抓取与初筛) export async function crawlTenderData() { const crawler context.get_skill(crawler); const tenderData await crawler.crawl({ url: https://www.cebpubservice.com/, keywords: [私有化业务, 企业定制, 专属部署], fileTypes: [pdf, docx, xlsx], savePath: ./tender_data }); const filtered []; for (const item of tenderData) { const prompt 判断以下招标公告是否匹配私有化业务匹配返回 JSON {match: true, reason: ...}不匹配返回 {match: false}。 公告标题${item.title} 公告摘要${item.summary}; const result await callModel({ model: process.env.TAOTOKEN_MODEL_FAST, messages: [{ role: user, content: prompt }] }); try { const parsed JSON.parse(result.replace(/json|/g, ).trim()); if (parsed.match) filtered.push({ ...item, reason: parsed.reason }); } catch (e) { console.warn(解析失败跳过${item.title}); } } return 初筛完成匹配 ${filtered.length} 条; }注意这里模型返回的是 JSON 字符串实际用的时候要处理模型偶尔加 markdown 代码块的情况上面用replace做了兜底。这一步的 Key 和 Base URL 全部来自llm-client.js爬虫 Skill 本身不碰凭证。3.2 RPA 填充模板前的字段抽取配置RPA 联动环节OpenClaw 通过 API 调用影刀或 UiBot 的脚本去填充 Word 模板。填充之前需要把招标文件里的关键字段抽出来比如项目名称、预算金额、服务周期、资质要求。这一步同样调统一模型出口但 prompt 要更严格要求输出固定字段的 JSON。// skills/tender-extract.js import { skill, context } from claw; import { callModel } from ./llm-client.js; skill.register(name招标字段抽取) export async function extractTenderFields(filePath) { const fileSkill context.get_skill(file); const rawText await fileSkill.readText(filePath); const prompt 从以下招标文件中抽取字段严格返回 JSON不要额外解释 { project_name: 项目名称, budget: 预算金额纯数字, duration_months: 服务周期月数纯数字, qualification: [资质要求1, 资质要求2], tech_requirements: [技术参数1, 技术参数2] } 招标文件内容 ${rawText.slice(0, 6000)}; const result await callModel({ model: process.env.TAOTOKEN_MODEL_FAST, messages: [{ role: user, content: prompt }], temperature: 0.1 }); const fields JSON.parse(result.replace(/json|/g, ).trim()); await fileSkill.saveJson(fields, ./tender_data/fields.json); return fields; }这里temperature压到 0.1是因为字段抽取要的是稳定输出不是创意。rawText.slice(0, 6000)是防止单次请求 token 超限实际项目里如果招标文件很长要做分段抽取再合并。3.3 正文生成阶段的模型切换配置正文生成是整条链路里 token 消耗最大的一步也是唯一需要强能力模型的地方。技术方案、服务承诺、项目理解这些内容快速模型写出来会比较干瘪。这里切到TAOTOKEN_MODEL_STRONG但 Base URL 和 Key 不变。// skills/bid-writer.js import { skill, context } from claw; import { callModel } from ./llm-client.js; skill.register(name标书正文生成) export async function generateBidContent() { const fileSkill context.get_skill(file); const fields await fileSkill.readJson(./tender_data/fields.json); const template await fileSkill.readText(./templates/bid_template.md); const prompt 你是投标文件撰写专家。根据以下项目信息和模板生成技术方案正文。 项目信息${JSON.stringify(fields, null, 2)} 模板结构${template} 要求技术方案部分不少于 800 字突出私有化部署的安全性和定制化能力。; const content await callModel({ model: process.env.TAOTOKEN_MODEL_STRONG, messages: [{ role: user, content: prompt }], temperature: 0.5 }); await fileSkill.saveText(content, ./bids/bid_content.md); return 正文生成完成; }三段链路到这里就串起来了爬虫 Skill 调快速模型做初筛字段抽取 Skill 调快速模型做结构化正文生成 Skill 调强能力模型写长文。三个 Skill 共用llm-client.jsKey 和 Base URL 只在.env里出现一次。3.4 用 settings 片段固化模型映射如果你不想在代码里到处写process.env.TAOTOKEN_MODEL_FAST可以加一个settings.json把阶段和模型的映射固化下来。{ llm: { baseUrl: https://taotoken.net/api, apiKeyEnv: TAOTOKEN_API_KEY, stages: { crawl_filter: { model: 你的快速模型ID, temperature: 0.3 }, field_extract: { model: 你的快速模型ID, temperature: 0.1 }, content_generate: { model: 你的强能力模型ID, temperature: 0.5 } } } }这样改模型只改这个文件代码里通过settings.llm.stages.content_generate.model读取。Key 依然走环境变量不写进 JSON避免误提交到仓库。4. 端到端跑通验证从抓取到正文生成的成功结果4.1 手动触发全流程配置写完先手动跑一次完整链路确认每个环节都能通。在 OpenClaw 控制台输入总指令执行招标标书自动化流程 1. 抓取中国招标投标公共服务平台私有化业务招标数据 2. 对抓取结果做模型初筛 3. 抽取匹配项目的关键字段 4. 基于模板生成标书正文 5. 输出正文文件路径OpenClaw 会按 Skill 注册顺序依次调用。观察控制台输出正常的话会看到类似这样的日志[招标数据抓取与初筛] 抓取到 23 条公告 [招标数据抓取与初筛] 初筛完成匹配 5 条 [招标字段抽取] 抽取字段project_name某企业私有化部署项目, budget680000 [标书正文生成] 正文生成完成保存至 ./bids/bid_content.md4.2 验证模型调用是否真的走了统一 Key跑通之后要确认一件事三个环节是不是真的都走了 TaoToken 的统一入口。最简单的办法是去控制台的调用记录里看如果三个阶段的请求都出现在同一个 Key 的调用日志下说明配置生效了。模型对话页面也可以直接验证https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 在里面手动发一条和正文生成类似的 prompt对比输出风格是否一致。4.3 检查生成结果的结构完整性正文生成完之后别只看文件生成了没有要检查内容结构。打开./bids/bid_content.md确认技术方案部分有没有达到要求的字数项目名称、预算金额这些字段有没有正确嵌入。如果发现字段是空的回去看fields.json里对应字段是不是抽取失败。# 快速检查字段文件 cat ./tender_data/fields.json | python -m json.tool # 检查正文文件字数 wc -m ./bids/bid_content.md4.4 配置定时任务做持续抓取手动跑通之后把抓取环节挂到定时任务上每天固定时间抓最新公告。OpenClaw 的 scheduler Skill 可以做到skill.register(name定时标书流程) export function scheduleBidProcess() { const scheduler context.get_skill(scheduler); scheduler.addJob({ func: crawlTenderData, trigger: cron, hour: 9, args: [] }); }定时任务只负责抓取和初筛正文生成还是保留人工确认环节。标书这种东西AI 生成完必须有人过一遍尤其是资质要求和报价部分不能全自动提交。4.5 成功结果的判断标准一次成功的端到端跑通应该满足四个条件爬虫抓到了公告、初筛匹配到了项目、字段抽取没有空值、正文生成文件存在且字数达标。四个条件里任何一个不满足都说明对应环节的配置有问题按下一节的排查表逐项检查。5. 本篇常见错排查401、local proxy failed、reading choices、OAuth5.1 401 UnauthorizedKey 没读到或格式不对最常见的报错就是 401。在 OpenClaw 里跑 Skill 时如果看到模型调用失败 401: {error:{message:Invalid API key}}先检查.env有没有被 OpenClaw 加载。Node 环境不会自动读.env需要在入口文件里加dotenvimport dotenv/config;然后确认 Key 没有多余空格Bearer后面直接跟 Key中间不要有换行。如果是在 Docker 里跑 OpenClaw.env要挂载进容器或者用-e传环境变量。5.2 local proxy failedBase URL 写错或网络不通这个报错通常出现在 Base URL 配置错误的时候Error: local proxy failed: connect ECONNREFUSED 127.0.0.1:7890说明请求被发到了本地某个端口而不是https://taotoken.net/api。检查llm-client.js里的BASE_URL是不是被其他环境变量覆盖了或者系统里有没有设置全局的HTTP_PROXY。OpenClaw 的 Skill 如果继承了 shell 的代理设置会把请求转发到本地端口。解决办法是在 Skill 启动时清掉代理变量delete process.env.HTTP_PROXY; delete process.env.HTTPS_PROXY;5.3 reading choices返回结构不对或模型 ID 错误报错信息里出现Cannot read properties of undefined (reading choices)说明data.choices是 undefined。两种可能一是模型 ID 写错了接口返回了错误信息而不是正常响应二是返回结构被中间层改过。先打印完整响应体确认const data await resp.json(); console.log(JSON.stringify(data, null, 2));如果返回里有error字段按错误信息处理。如果返回正常但没有choices检查是不是把 Base URL 写成了带/v1的完整路径导致重复拼接。llm-client.js里拼的是${BASE_URL}/v1/chat/completions所以BASE_URL只写到https://taotoken.net/api就行。5.4 OAuth 相关报错误用了需要 OAuth 的接入方式如果你在 OpenClaw 里看到类似OAuth token expired或invalid_grant的报错说明某个 Skill 走了 OAuth 接入而不是 API Key 接入。标书链路里所有模型调用都应该走 API Key不需要 OAuth。检查是不是在某个 Skill 里误配了 Claude Code 或 Codex 的 OAuth 凭证。如果你确实在用 Claude Code 做正文润色那属于另一条接入路径需要单独配置。Claude Code 的接入文档在这里https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 里面写了 Base URL、Key、Model ID 三件套怎么填。但标书自动生成这条链路用 API Key 直连就够了不要混用 OAuth。5.5 字段抽取返回空值prompt 或截断问题如果fields.json里某些字段是空字符串先看招标文件原文里有没有这个信息。如果原文有但抽取为空大概率是rawText.slice(0, 6000)把关键段落截掉了。把截断长度调大或者改成按段落分段抽取再合并。另一个原因是模型返回了带解释的文字而不是纯 JSON。在 prompt 里加一句“只返回 JSON不要任何解释”并且在解析前用正则把代码块标记去掉。5.6 正文生成字数不达标模型能力或 prompt 约束不够正文生成出来只有两三百字通常是两个原因一是用了快速模型写长文能力不够二是 prompt 里没有明确字数要求。确认content_generate阶段用的是TAOTOKEN_MODEL_STRONG并且在 prompt 里写清楚“技术方案部分不少于 800 字”。如果换了强能力模型还是写不长检查temperature是不是太低。正文生成可以适当调到 0.5 到 0.7让模型有更多发挥空间。6. 一次配置多工具复用把 Key 管理收敛到一个入口标书自动生成这条链路跑通之后你会发现真正省下来的时间不是写爬虫规则也不是调 RPA 脚本而是不用再为每个环节单独配 Key。爬虫后处理、字段抽取、正文生成三个 Skill 共用一份凭证模型切换只改模型 IDBase URL 和 Key 始终不动。这套做法可以继续往外扩。比如你后面要加一个“投标文件合规检查”的 Skill或者接一个“历史标书中标率分析”的 Agent只要它们都调llm-client.js就自动复用同一份配置。长期做编码和 Agent 类任务的话Coding Plan 页面有更完整的接入说明https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。最后留一个实操建议把.env和settings.json分开管理.env进.gitignoresettings.json可以提交到仓库。这样团队里其他人拉代码之后只需要自己填一份 Key模型映射和阶段配置直接复用。改 Key 的时候只改自己本地的.env不会影响别人的配置也不会把凭证推到远程仓库。