1. 从单机 Demo 到生产企业级 Agent 为什么总在落地时翻车很多团队做 Agent 的路径都差不多本地跑通一个能查天气、能读文件的 Demo觉得效果不错然后信心满满地往生产环境推结果一上量就崩。崩的地方往往不是模型能力而是工程结构。我把这类翻车总结成四个典型症状。第一是工具乱接 ERP 写一套 Adapter接 CRM 再写一套接数据库又一套代码像烟囱一样往上堆新增一个工具就要改 Agent 主流程。第二是调度乱一个 Agent 串行干完搜索、分析、写作、通知中间任何一步失败整个任务重来上下文窗口还容易被中间数据撑爆。第三是选错工具工具数量一多全塞进 Prompt 里模型被无关描述干扰Token 成本飙升选错概率也直线上升。第四是记性差每次对话都从零开始用户反复解释背景系统无法积累经验。这四个问题对应的工程解法正好是 OpenClaw 架构里的四块拼图MCP 接入解决工具标准化多 Agent 调度解决复杂任务拆解Tool Router 解决工具精准召回Memory 架构解决跨会话经验积累。这篇不是概念科普我会把每一块的可复制配置、调度策略、路由规则都写出来你可以跟着一步步搭起来。先说清楚适合谁看如果你已经能跑通单个 Agent 的调用想把它推到团队或生产环境用这篇就是给你写的。如果你还在纠结选哪个模型那可以先跳过等有了 Demo 再回来。OpenClaw 在这里扮演的是 Agent Runtime 的角色它本身不绑定某个具体模型而是通过统一的协议层去接工具、调度任务、管理记忆。你可以把它理解成一个Agent 操作系统模型是 CPUMCP 是外设接口Tool Router 是中断控制器Memory 是内存和硬盘。这个类比后面会反复用到。2. TaoToken 前置给 OpenClaw 配一个稳定的模型接入层在搭 OpenClaw 之前得先解决模型调用的问题。OpenClaw 的 Orchestrator、Worker、Tool Router 的精排环节、Memory 的摘要压缩全都要调 LLM。如果每个环节都直连不同厂商的 APIKey 管理、限流、计费会非常乱。我的做法是统一走一个兼容 OpenAI 协议的接入层TaoToken 就是干这个的。它的 API 地址是https://taotoken.net/api兼容 OpenAI 的/v1/chat/completions格式所以 OpenClaw 里所有需要调模型的地方只要把 Base URL 指过去就行。官网在https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content注册后在控制台生成 Key。这里有个关键点OpenClaw 的多个模块可能要用不同能力的模型。比如 Orchestrator 的任务拆解需要强推理用大模型Tool Router 的 L2 精排只需要从 20 个候选里选 5 个用小模型就够省钱又快Memory 的摘要压缩也是小模型更合适。TaoToken 的好处是同一个 Key 可以调不同模型你只要在配置里改 Model ID 就行。我实测下来把模型接入层统一之后后面调 Tool Router 和 Memory 的成本能降不少因为你可以放心地给每个环节配最合适的模型而不是为了省事全用一个大模型。具体操作登录控制台进 API Keys 页面创建一个 Key复制出来。然后记下你要用的 Model ID比如做任务拆解可以用claude-sonnet-4-5这类做精排和摘要可以用更轻量的。这些 Model ID 在模型对话页面能看到也可以直接调/v1/models接口拉列表。注意Key 不要硬编码在代码里用环境变量或者配置文件管理。OpenClaw 的配置里我会用${TAOTOKEN_API_KEY}这种占位符启动时从环境变量注入。如果你还没生成 Key先去控制台建一个后面所有配置都要用到。接入文档在https://taotoken.net/doc里面有完整的接口说明和示例。3. 可复制配置MCP 接入、多 Agent 调度与 Tool Router 的落地片段这一节是全文的核心我把 OpenClaw 里三块最关键的配置都写出来你可以直接复制改。3.1 MCP Server 配置让工具以标准协议接入MCP 的核心思想是工具方按协议暴露能力Agent 按协议调用。OpenClaw 里 MCP 的配置通常放在config/mcp_servers.json结构如下{ mcpServers: { filesystem: { command: npx, args: [-y, modelcontextprotocol/server-filesystem, /data/workspace], env: {} }, internal_erp: { url: http://mcp-gateway.internal:8080/sse, headers: { Authorization: Bearer ${MCP_GATEWAY_TOKEN} }, timeout: 30000 }, database: { command: python, args: [-m, mcp_server_mysql], env: { MYSQL_DSN: ${MYSQL_DSN} } } } }这里有个企业级的关键决策内部系统的 MCP Server 一定要独立部署不能让 Agent 直连。上面internal_erp走的是mcp-gateway.internal这个网关网关这一层做鉴权、审计、限流。Agent 是有主观判断的组件你无法完全预测它会怎么调工具中间隔一层网关安全风险能降一个量级。启动阶段OpenClaw 的 ToolRegistry 会向每个 MCP Server 拉取工具清单并缓存。你可以用这条命令验证 MCP Server 是否正常curl -N http://mcp-gateway.internal:8080/sse \ -H Authorization: Bearer $MCP_GATEWAY_TOKEN正常的话会返回 SSE 流里面包含tools/list的响应。如果连不上先查网关端口和 Token。3.2 多 Agent 调度配置Orchestrator Worker DAGOpenClaw 的调度配置放在config/agents.yaml。核心是把任务拆解成 DAG而不是靠 Prompt 隐式描述依赖关系。orchestrator: model: claude-sonnet-4-5 base_url: https://taotoken.net/api api_key: ${TAOTOKEN_API_KEY} max_workers: 5 task_timeout: 120 workers: - name: search_agent model: claude-haiku-4-5 base_url: https://taotoken.net/api api_key: ${TAOTOKEN_API_KEY} tools: [web_search, fetch_url] stateless: true - name: write_agent model: claude-sonnet-4-5 base_url: https://taotoken.net/api api_key: ${TAOTOKEN_API_KEY} tools: [write_file, format_markdown] stateless: true - name: review_agent model: claude-haiku-4-5 base_url: https://taotoken.net/api api_key: ${TAOTOKEN_API_KEY} tools: [read_file, spell_check] stateless: true dag: nodes: - id: A agent: search_agent task: 搜索竞品动态 - id: B agent: search_agent task: 收集历史数据 depends_on: [A] - id: C agent: search_agent task: 数据分析 depends_on: [A] - id: D agent: write_agent task: 生成报告 depends_on: [B, C] - id: E agent: review_agent task: 校对报告 depends_on: [D]注意stateless: true这是多 Agent 设计的第一条铁律Worker 要无状态化每次调用传入完整上下文不依赖本地状态方便水平扩展和重试。B 和 C 都依赖 A可以并行D 必须等 B 和 C 都完成。Orchestrator 的核心能力就是识别这个结构并驱动正确的执行顺序。3.3 Tool Router 配置两层路由规则Tool Router 的配置放在config/tool_router.yaml采用粗筛 精排两层策略tool_router: l1_recall: method: embedding embedding_model: text-embedding-3-small base_url: https://taotoken.net/api api_key: ${TAOTOKEN_API_KEY} top_k: 20 vector_store: redis redis_url: ${REDIS_URL} l2_rerank: method: llm model: claude-haiku-4-5 base_url: https://taotoken.net/api api_key: ${TAOTOKEN_API_KEY} top_k: 5 prompt_template: | 从以下候选工具中选出与任务最相关的 5 个并给出选择理由。 任务{task} 候选工具{candidates} 输出 JSON 格式{selected: [...], reason: ...} fallback: when_tools_lt: 10 strategy: full_injectionL1 用 Embedding 做语义召回快速粗筛出 20 个候选成本极低。L2 用 LLM 从 20 个里精排选 5 个候选少所以成本也低但准确率提升明显。当工具总数小于 10 时直接全量注入没必要走路由。这里有个被严重低估的细节工具描述的质量直接决定路由准确率。对比一下# 差的描述 query_order: description: 查询订单信息 # 好的描述 query_order_status: description: | 根据订单号查询订单的当前状态包括支付状态、物流状态和预计到达时间。 适用场景用户询问我的订单到哪了、订单有没有发货等。 不适用于修改订单、取消订单、申请退款。好的描述包含功能说明 适用场景 不适用场景。写不适用场景尤为重要它帮模型在多个相似工具中做出准确区分。3.4 Memory 架构配置Memory 的四层配置放在config/memory.yamlmemory: working: store: redis redis_url: ${REDIS_URL} window_size: 6 compress_threshold: 10 episodic: store: vector_db vector_db_url: ${VECTOR_DB_URL} embedding_model: text-embedding-3-small base_url: https://taotoken.net/api api_key: ${TAOTOKEN_API_KEY} top_k: 5 async_write: true semantic: store: vector_db vector_db_url: ${VECTOR_DB_URL} embedding_model: text-embedding-3-small base_url: https://taotoken.net/api api_key: ${TAOTOKEN_API_KEY}async_write: true是关键。Memory 写入不应该阻塞用户响应Episodic Memory 的写入需要压缩摘要一次 LLM 调用 向量化 存库可能几百毫秒放同步链路会直接拉高延迟。4. 验证请求本地启动与调用验证的具体动作配置写完得验证整条链路能跑通。我按启动顺序一步步来。4.1 启动 OpenClaw 并检查 MCP 工具发现先确保环境变量都注入好了export TAOTOKEN_API_KEY你的Key export MCP_GATEWAY_TOKEN你的网关Token export REDIS_URLredis://localhost:6379 export VECTOR_DB_URLhttp://localhost:6333然后启动 OpenClawopenclaw start --config ./config启动日志里应该能看到 ToolRegistry 拉取工具清单的记录[INFO] ToolRegistry: discovering tools from 3 MCP servers... [INFO] ToolRegistry: filesystem - 5 tools registered [INFO] ToolRegistry: internal_erp - 12 tools registered [INFO] ToolRegistry: database - 8 tools registered [INFO] ToolRegistry: total 25 tools cached如果某个 Server 没注册上日志会报MCP connection failed先查那个 Server 的地址和 Token。4.2 验证模型接入层单独测一下 TaoToken 的接入是否正常curl https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: claude-haiku-4-5, messages: [{role: user, content: 回复 OK}], max_tokens: 10 }正常返回里choices[0].message.content应该是OK之类。如果报 401检查 Key如果报 model not found检查 Model ID 拼写。4.3 验证 Tool Router 召回单独测路由看给定任务能不能召回对的工具openclaw tool-router test \ --task 查询订单 12345 的物流状态 \ --top-k 5期望输出类似[L1] recalled 20 candidates in 12ms [L2] reranked to 5 in 340ms selected: - query_order_status (score: 0.94) - query_logistics (score: 0.87) - ... reason: 任务涉及订单状态和物流查询优先选择订单和物流相关工具如果召回的工具不对八成是工具描述写得太模糊回去改描述。4.4 验证多 Agent 调度跑一个完整的 DAG 任务openclaw run \ --task 分析竞品动态生成市场报告 \ --dag ./config/agents.yaml日志里应该能看到 DAG 的执行顺序[Orchestrator] task decomposed into 5 nodes [Orchestrator] executing node A (search_agent) [Orchestrator] node A done, triggering B and C in parallel [Orchestrator] node B done [Orchestrator] node C done, triggering D [Orchestrator] node D done, triggering E [Orchestrator] node E done, task completeB 和 C 并行执行是重点如果看到它们是串行的检查depends_on配置。4.5 验证 Memory 写入任务完成后查一下 Episodic Memory 有没有异步写入openclaw memory query \ --type episodic \ --query 竞品分析报告 \ --top-k 3应该能召回刚才那个任务的 Episode包含任务描述、解决方案摘要、用到的工具、是否成功。如果查不到检查async_write是否开启以及向量库连接是否正常。5. 本篇常见错排查401、local proxy failed、reading choices、OAuth搭的过程中我踩过不少坑这里按真实报错对照排查。401 Unauthorized最常见。先确认TAOTOKEN_API_KEY环境变量有没有正确注入echo $TAOTOKEN_API_KEY看是不是空。如果 Key 没问题检查请求头格式必须是Authorization: Bearer keyBearer 后面有个空格。还有一种情况是 Key 复制时带了换行或空格重新复制一次。local proxy failed / connection refused这个通常出现在 MCP Server 走本地网关时。检查网关进程有没有起来端口对不对。如果是 Docker 环境注意localhost在容器里指向容器本身要用宿主机的实际 IP 或 Docker 网络别名。我试过在容器里配http://localhost:8080结果一直连不上改成服务名http://mcp-gateway:8080就好了。reading choices of undefined这个报错说明 API 返回的结构不对代码在解析response.choices[0]时挂了。原因通常是 Base URL 配错了比如漏了/v1或者把https://taotoken.net/api写成了https://taotoken.net。正确的完整路径是https://taotoken.net/api/v1/chat/completions。另外检查一下返回体如果是错误响应里面是error字段而不是choices。OAuth / authentication failed如果 MCP Server 配了 OAuth 鉴权Token 过期会报这个。重新走一遍授权流程拿新 Token。如果是 Claude Code 这类工具接入注意它的配置文件和 OpenClaw 是分开的别改错文件。Tool Router 召回不准不是报错但很常见。九成是工具描述问题。回去检查描述里有没有写清适用场景和不适用场景。另外 L1 的top_k如果设太小可能把对的工具筛掉了先调到 20 试试。DAG 执行顺序不对检查depends_on有没有写全。如果 B 和 C 本该并行却串行了看max_workers是不是设成了 1。如果 D 在 B、C 之前就跑了说明依赖没建对。Memory 查不到历史先确认async_write开了然后看向量库有没有数据。异步写入有延迟任务完成后等几秒再查。如果向量库连不上检查VECTOR_DB_URL。CC Switch / Cline MCP / Codex auth.json 三件套如果你用这些工具接 OpenClaw配置里必须写全三样——Base URLhttps://taotoken.net/api、Key你的 TaoToken Key、Model ID具体模型名。少任何一个都会报错。Codex 的auth.json里字段名和 OpenClaw 不一样注意对照文档。6. 从能跑到好用下一步该做什么架构搭起来只是第一步真正决定 Agent 好不好用的是细节。我最后给几个实操建议。工具描述要当成产品文案来写。每次 Tool Router 召回不准先别怀疑模型回去看描述。把适用场景和不适用场景写清楚召回准确率能提升一大截。这是投入产出比最高的一件事。Worker 的粒度控制在一个人、一件事。太细了调度开销大太粗了失去并发优势。一个 Worker 只干一件明确的事输入输出都是结构化的这样重试和扩展都方便。Memory 的异步写入一定要做。同步写会直接拉高响应延迟用户能感知到。把压缩、向量化、存库都放到异步队列里用户拿到结果就走后台慢慢写。失败要可重试。每个 Worker 的结果都记录Orchestrator 支持对失败节点单独重跑而不是整个任务重来。这在长链路任务里能省大量时间和 Token。模型分层用。Orchestrator 用强模型Tool Router 精排和 Memory 摘要用轻量模型。TaoToken 同一个 Key 能调不同模型配置里改 Model ID 就行成本能降不少。最后别一上来就追求全自动。先把 MCP 接入和单 Agent 跑通再加多 Agent 调度最后上 Tool Router 和 Memory。每一步都验证通过再往下走出问题也好定位。架构是长出来的不是一次设计出来的。