最近花了一周多时间把 OpenClaw 的多 Agent 工作流跑通了。整个链路是调研—写作—审查三个 AI 角色协作完成一篇技术文章模型接入全部走 PoloAPI。把过程和踩过的坑记一下给有类似需求的人省点弯路。先说为什么要把 PoloAPI 垫进来OpenClaw 本身不绑定任何模型厂商你可以直接配 OpenAI、Claude、Gemini 各家的官方 API。但真正做多 Agent 的时候直连方案的麻烦会成倍放大。Key 管理碎片化。 我这条工作流里有三个角色调研员跑 GPT-4o-mini便宜快写手跑 Claude Sonnet生成质量好审查员跑 Claude Opus推理深。直连的话至少要维护两家厂商的 Key分别充值、分别看余额。Key 一多运维负担就上来了。网络稳定性被放大。 单个 Agent 完成一个任务通常要跟模型来回交互 5-10 轮。三个 Agent 同时跑意味着同一时间段内有几十次 API 调用。如果中间任何一轮超时或断连整条任务链就可能断掉。国内环境直连海外 endpoint延迟本身就不稳定在高频多轮调用的场景下这个问题格外突出。账单散在各处。 多个厂商、多种币种、多个后台——如果团队要做成本核算一份清晰的汇总账单比什么都重要。PoloAPI 的价值就在这三个点上一个 Key 通多家模型、国内节点中转压低延迟、人民币统一结算。本质上是在 OpenClaw 和模型厂商之间加了一层收口把上游的复杂性挡住不让它漏进业务逻辑。接入过程改一份配置文件OpenClaw 的模型配置集中在一个 JSON 文件里。接入 PoloAPI 的核心动作就三步1. 把请求地址指向 PoloAPI 的 endpoint。2. 把 API Key 换成 PoloAPI 的 Key。3. 协议类型选 OpenAI 兼容格式——因为 PoloAPI 对外统一走 OpenAI 标准接口不管背后实际调的是 Claude 还是 GPT。配置模式建议选合并而不是替换这样 OpenClaw 内置的模型列表还在。万一 PoloAPI 偶发故障可以临时切回直连不至于整个系统趴窝。改完配置之后重启一下 OpenClaw 网关服务就生效了。整个过程没什么技术门槛主要是别填错字段名。三个角色怎么分工工作流的思路很直白每个角色干一件明确的事角色之间通过文件传递信息。调研员——负责信息收集。我给它配了网页搜索和浏览器两个技能让它能上网查资料。模型用 GPT-4o-mini因为信息收集不需要深度推理要的是速度和低成本。它的产出是一份结构化的调研摘要文件。写手——拿到调研摘要后生成完整的文章初稿。模型用 Claude Sonnet长文本生成质量稳定性价比高。它只需要文件读写的技能——读调研摘要、存初稿。审查员——对初稿做质量检查看事实准不准、逻辑通不通、有没有遗漏重要观点。模型用 Claude Opus这是整条链路里最贵的一环但审查这件事确实需要更强的推理能力。它的产出是一份修改建议清单。三个角色是串行执行的——调研完了写手才开始写完了审查员才介入。执行顺序通过依赖关系控制后一步必须等前一步完成并且产出文件确实存在才会启动。如果用 openclaw-workflow 插件这个流程可以写成一份 YAML 配置文件定义好每一步用什么模型、依赖哪一步、超时多久、产出文件叫什么。配好之后一条命令就能跑不用手动盯着。分级模型路由省钱的核心这套工作流里最关键的设计决策是——三个角色用三档不同的模型。调研员用最便宜的 GPT-4o-mini输入价格大概 $0.15/百万 token。写手用中档的 Claude Sonnet大概 $3/百万 token。审查员用顶配的 Claude Opus大概 $15/百万 token。如果三个角色全部用 Opus一次完整流程跑下来粗算 $3-5。改成分级路由后同样的任务降到 $0.5-1.5省了 60%-70%。这个策略的前提是你得清楚每个角色真正需要的能力等级。调研员不需要深度推理——它的任务就是搜索、筛选、整理任何一个主流模型都能干好。写手需要的是稳定的文本生成能力Sonnet 在这一档的性价比很突出。只有审查员需要模型真正动脑子去找逻辑漏洞和事实错误才值得上 Opus。通过 PoloAPI 做这件事有一个额外的方便你在同一个 Key 下就能切换不同厂商、不同档位的模型。不用去 OpenAI 后台充一次值、再去 Anthropic 后台充一次值。一份账单、一个余额、一套调用日志。踩过的坑坑一子 Agent 超时但主流程不知道。调研员搜索耗时波动很大有时候几秒就回来有时候要一两分钟。一开始我把超时设成 3 分钟结果偶尔还是会超。超时后主流程没收到明确的失败信号就一直在那儿干等。后来放宽到 5 分钟同时在工作流配置里加了重试——失败后等 30 秒再来一次最多重试 2 次。大部分偶发性超时都被吃掉了。坑二写手自由发挥脱离了调研内容。没给足约束的时候写手偶尔会脱离调研摘要自己编内容。大模型的创造力在这个场景里反而是个风险。解决办法是在任务描述里明确加一句所有观点必须基于调研摘要中的信息不要引入摘要中未提及的内容。加上这条限制后跑偏的情况明显减少了。坑三角色之间不共享记忆。这是很多人刚接触多 Agent 系统时容易忽略的一点。每个子 Agent 有自己独立的上下文窗口它们之间不共享对话历史。审查员不会自动知道写手是怎么构思的写手也不会自动知道调研员搜了哪些页面。所有信息流转必须走显式的文件传递或消息发送不能靠默认应该知道。坑四偶发的网络波动。换成 PoloAPI 中转后这个问题明显好了很多——国内到 PoloAPI 节点的延迟大概 40-60ms比直连海外稳得多。但不是完全消失偶尔还是会碰到某一轮调用超时。前面提到的重试机制是第一道防线。第二道是把配置模式设成合并保留直连作为备用——真遇到 PoloAPI 大面积故障手动切一下就行。坑五成本超出预期。头几次跑的时候没注意监控 Token 消耗结果发现审查员在高思考模式下生成了大量内部推理 token实际花费比预估高出不少。后来养成了每次跑完去 PoloAPI 后台看调用明细的习惯——它能看到每个 Agent、每次请求的模型、输入输出 Token 数和延迟。哪个环节在烧钱一目了然。两周跑下来的真实感受确实提效了。 以前手动做查资料 → 写初稿 → 自己审一遍至少要大半天。现在从发出指令到拿到初稿加审查意见大概 15-20 分钟。就算加上人工最终审阅和修改的时间整体效率也提升了不少。但它不是全自动流水线。 AI 生成的内容不管经过几层 Agent 处理最后还是需要人看一遍。审查员能抓出一些明显的逻辑问题和事实遗漏但它替代不了人对这篇文章到底好不好的判断。定位上它是效率放大器不是无人工厂。统一网关的价值在多 Agent 场景下特别明显。 单 Agent 场景下直连官方 API 也能凑合用。但当你同时跑三个不同模型的 Agent、每个都要做多轮 API 调用的时候Key 管理、延迟控制、账单归口这些杂事会占掉你相当一部分精力。PoloAPI 不是让模型变得更聪明而是让你不用在基础设施上分心能把注意力放在工作流设计本身。下一步想做的事。 目前三个角色是纯串行的。调研员其实可以拆成两个并行子 Agent——一个搜中文源、一个搜英文源合并结果后再交给写手。另外审查员的反馈目前是终点没有回传给写手做二次修改。加一个写手改稿 → 审查员复查的循环应该能提高成稿质量但 Token 消耗也会翻倍得看具体任务值不值得。