1. 销售场景为什么需要多 Agent 协作做 ToB 销售的朋友大概率都遇到过这种局面市场部丢过来一份 800 行的线索表销售挨个查官网、翻聊天记录、判断意向一天下来真正能跟进的没几个好不容易聊上的客户跟进记录散落在微信、飞书、CRM 三个地方下次沟通前得花半小时回忆上次聊到哪到了出方案阶段又要重新翻需求、拼卖点、套模板一份方案磨两三天。单 Agent 的做法通常是给一个大模型塞一堆提示词让它同时干提取、判断、写话术、出方案。实测下来问题很明显任务一多上下文就串味线索提取的字段跑到方案里去了一个环节报错整条链路挂掉没法单独重试更麻烦的是没法给不同环节配不同的模型和参数线索提取要稳、话术生成要活一个模型很难两头兼顾。OpenClaw 的思路是把销售链路拆成线索挖掘、客户跟进、方案生成三条独立链路每条链路下面再挂专职 Agent通过编排引擎共享上下文、按优先级调度、失败单独重试。这篇就按工程化落地的角度把可复制的 Agent 编排配置骨架、settings.json 关键字段、以及从线索到跟进的状态流转验证动作讲清楚你可以在自己的环境里跑通端到端流程。适合已经了解 OpenClaw 基础概念、想把它真正用到销售业务里的开发者和销售运营同学。2. TaoToken 前置给多 Agent 提供稳定的模型出口多 Agent 协作对模型调用的要求比单 Agent 高得多。三条链路并发跑线索挖掘 Agent 可能在批量处理 50 条线索跟进 Agent 同时在整理会议纪要方案 Agent 在生成文档如果模型出口不稳定整条流水线就会卡在某个环节。我这边用的是 TaoToken 作为统一模型出口它兼容 OpenAI 风格的接口OpenClaw 的模型适配器可以直接对接不用改 Agent 内部逻辑。官网在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 地址是 https://taotoken.net/api 注意 API 地址不带 UTM 参数配置的时候别写错。具体操作上先去控制台创建 API Key地址是 https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 创建完把 Key 复制出来后面填到 settings.json 里。如果你对模型能力还没把握可以先用模型对话页面 https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodelsutm_campaignrewrite 试几条销售场景的提示词看看提取和生成效果再决定用哪个模型。这里要提醒一句多 Agent 场景下建议给不同链路配不同的模型。线索挖掘和跟进记录整理这类结构化提取任务用稳定、便宜的模型就够方案生成和话术包装这类需要语言表达的任务再上能力更强的模型。TaoToken 的好处是同一个 Key 可以调不同模型切换成本低。3. 可复制的 Agent 编排配置骨架3.1 目录结构先把工程目录搭起来后面所有配置都往这个骨架里填openclaw-sales/ ├── settings.json # 全局配置模型、Key、并发 ├── agents/ │ ├── lead_agent.yaml # 线索挖掘 Agent │ ├── follow_agent.yaml # 客户跟进 Agent │ └── proposal_agent.yaml# 方案生成 Agent ├── skills/ │ ├── lead_extract.md # 线索提取提示词 │ ├── follow_track.md # 跟进整理提示词 │ └── proposal_gen.md # 方案生成提示词 ├── data/ │ ├── leads.csv # 原始线索 │ └── records/ # 沟通记录 └── output/ ├── leads_tracked.csv # 线索跟进表 └── follow_list.csv # 客户跟进清单3.2 settings.json 关键字段这是整篇最核心的配置多 Agent 能不能协同起来全看这里{ llm: { provider: openai-compatible, base_url: https://taotoken.net/api, api_key: sk-你的TaoToken密钥, default_model: gpt-4o-mini, timeout: 60, max_retries: 3 }, orchestrator: { max_concurrency: 4, task_queue: priority, context_sharing: true, fail_fast: false }, agents: { lead_agent: { model: gpt-4o-mini, temperature: 0.3, max_tokens: 2048 }, follow_agent: { model: gpt-4o-mini, temperature: 0.4, max_tokens: 3072 }, proposal_agent: { model: gpt-4o, temperature: 0.6, max_tokens: 4096 } }, state: { store: sqlite, path: ./data/state.db, checkpoint_interval: 10 } }几个字段值得单独说。context_sharing打开后线索 Agent 提取的客户信息会自动进入共享上下文跟进 Agent 不用重新读一遍原始文件。fail_fast设成 false意思是某条线索处理失败不影响其他线索失败任务进重试队列。task_queue用 priority高意向线索会被优先调度。checkpoint_interval是每处理 10 条落一次盘中途挂了不用从头再来。3.3 线索挖掘 Agent 配置name: lead_agent description: 从原始线索中提取客户信息并判断意向 skill: skills/lead_extract.md input: - data/leads.csv output: - output/leads_tracked.csv fields: - customer_name - industry - contact - title - demand - intent_level - priority - next_action对应的skills/lead_extract.md提示词骨架你是销售线索分析助手。基于输入的线索数据逐条完成 1. 提取客户名称、行业、联系人、职位、需求线索 2. 判断意向等级高/中/低并给出一句判断依据 3. 按意向等级分配优先级 P0/P1/P2 4. 为每条线索生成一句首次触达话术 输出严格按 CSV 表头customer_name,industry,contact,title,demand,intent_level,intent_reason,priority,first_touch 不要输出解释性文字只输出 CSV 行。3.4 客户跟进 Agent 配置name: follow_agent description: 整理沟通记录并判断销售阶段 skill: skills/follow_track.md input: - data/records/ - output/leads_tracked.csv output: - output/follow_list.csv fields: - customer_name - stage - stage_reason - concerns - objections - next_step - next_date跟进 Agent 的关键是状态流转。销售阶段建议固定成五个枚举值初步接触、需求分析、方案评估、商务谈判、成交。Agent 只能在这五个值里选避免模型自由发挥导致下游统计口径混乱。3.5 方案生成 Agent 配置name: proposal_agent description: 基于客户需求生成方案框架与汇报话术 skill: skills/proposal_gen.md input: - output/follow_list.csv - data/product.md output: - output/proposal_{customer_name}.md fields: - core_demand - solution_framework - value_match - talk_track4. 验证请求与状态流转配置写完不能直接上生产得先验证链路通不通。分三步走。4.1 验证模型出口先确认 TaoToken 的 Key 能正常调用curl https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer sk-你的密钥 \ -H Content-Type: application/json \ -d { model: gpt-4o-mini, messages: [{role: user, content: 回复 OK}] }返回里能看到choices字段就说明出口正常。如果报 401检查 Key 有没有复制全报 404检查 base_url 是不是写成了带路径的形式。4.2 验证单 Agent 执行拿 5 条测试线索跑线索挖掘 Agentclaw run lead_agent --input data/leads.csv --limit 5跑完看output/leads_tracked.csv重点检查三件事字段有没有缺列、意向等级是不是只出现高/中/低、优先级是不是只出现 P0/P1/P2。如果模型输出了「较高」「P0-P1」这种模糊值说明提示词里的枚举约束不够硬回去把可选值用引号包起来再强调一遍。4.3 验证状态流转这是多 Agent 协作最容易出问题的地方。线索 Agent 输出的customer_name必须和跟进 Agent 读取的键完全一致否则共享上下文对不上。验证方法claw run follow_agent --input output/leads_tracked.csv --dry-run--dry-run只做匹配不调模型输出里会列出每条线索匹配到的沟通记录。如果出现unmatched的客户名八成是线索表里写了「智慧制造有限公司」而沟通记录里写的是「智慧制造」需要加一层名称归一化或者在 settings.json 里打开context_sharing的 fuzzy_match 选项。状态流转验证通过的标准是线索表里的每条 P0 客户都能在跟进清单里找到对应的阶段记录且阶段值在五个枚举值之内。5. 本篇常见错排查报错一context key not found: customer_name线索 Agent 和跟进 Agent 的字段名不一致。检查两个 yaml 里的fields列表客户名统一用customer_name别一个写name一个写customer。报错二rate limit exceeded并发设太高了。settings.json 里max_concurrency从 4 降到 2或者给 orchestrator 加retry_backoff: 2失败后指数退避重试。报错三方案生成 Agent 输出里混进了线索提取的字段context_sharing打开后所有 Agent 共享上下文方案 Agent 可能读到不该读的字段。解决办法是在 proposal_agent.yaml 里显式声明context_filter只允许读取core_demand和product两类键。报错四CSV 输出中文乱码OpenClaw 默认按 UTF-8 写文件但 Excel 打开会乱码。在 settings.json 的 output 段加encoding: utf-8-sig或者用iconv转一下。报错五跟进阶段判断来回跳同一个客户两次运行给出了不同阶段。这是 temperature 太高导致的跟进 Agent 的 temperature 压到 0.2 以下并在提示词里要求「阶段只能前进不能后退除非有明确证据」。6. 把链路跑成日常三条链路单独跑通只是第一步真正省时间的是把它们串成一条命令。在项目根目录建一个run_all.sh#!/bin/bash set -e claw run lead_agent --input data/leads.csv claw run follow_agent --input output/leads_tracked.csv claw run proposal_agent --input output/follow_list.csv --top 5 echo 链路完成输出在 output/ 目录--top 5表示只给优先级最高的 5 个客户生成方案避免一次性生成几十份没人看。每天早上跑一次销售上班直接看output/follow_list.csv就知道今天该跟谁、聊什么、带什么方案。如果团队里有人长期跑编码类任务或者要接 Agent 做自动化可以看下 Coding Plan https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 按量计费比单次调用划算。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 里面有多 Agent 并发调用的示例配置字段和这篇的 settings.json 能对上。最后说个踩过的坑别一上来就把全量线索丢进去跑。先用 20 条跑一周把提示词里的枚举值、字段名、阶段定义磨稳定了再放量。多 Agent 协作的稳定性不取决于模型多强取决于字段约定有多死。