企业官网建设流程全解析

1. ABAP 开发者用 Claude Code 接 MCP 时，为什么总卡在 401 和 local proxy failed

如果你正在用 Claude Code 配合 ADT MCP Server 做 ABAP 开发，大概率遇到过这个场景：MCP server 本身能启动，abap_lists_destinations也能返回 DEV 系统的 destination，但一旦让 Claude Code 去调用模型做工具编排，就报401 Unauthorized或者local proxy failed。这不是 ABAP 侧的问题，也不是 ADT MCP Server 的 bug，而是模型调用通道和 MCP 工具通道被混在了一条链路上。

先把链路拆清楚。Claude Code 作为 MCP host，它做两件事：一是通过 stdio 或 HTTP 连接本地 MCP server，让 server 暴露abap_creation-create_object、abap_activate_objects、abap_run_atc这些 tools；二是把 tools/list 的结果和用户意图发给背后的 LLM，让模型决定调哪个 tool、传什么参数。第一条链路走的是本机进程通信，第二条链路走的是模型 API。很多人配置时只改了 MCP server 的 endpoint，忘了 Claude Code 自己还有一个独立的模型 endpoint 和鉴权字段，结果 MCP 工具能列出来，模型请求却打到了错误的地址，于是 401 和 local proxy failed 就出现了。

local proxy failed这个报错尤其有迷惑性。它通常出现在 Claude Code 尝试通过本地代理转发模型请求、但代理目标不可达或鉴权失败的时候。你以为是 MCP server 挂了，其实 MCP server 好好的，是模型通道的 Base URL 指向了一个本地不存在的代理端口，或者指向了一个需要特定 Key 但没配的服务。ABAP 开发者习惯在 ADT 里配 destination，对 HTTP 代理和 API Key 这套东西相对陌生，所以这类错误在 ABAP + Claude Code 的组合里特别高频。

这篇要解决的就是这条分离链路：MCP server 继续负责 ADT 工具调用，模型调用通道单独指向 TaoToken，两边各配各的，互不干扰。下面给出 MCP server 配置片段、Claude Code 侧 endpoint 与鉴权字段的可复制改法，最后用一次 ABAP 类读取请求验证工具调用是否真正贯通。适合正在做 RAP、CDS、ATC 相关开发、想把 Claude Code 接进 ABAP 工具链的开发者。

2. 前置准备：TaoToken 在 ABAP MCP 链路里扮演什么角色

在动手改配置之前，先把 TaoToken 在这条链路里的位置说清楚，不然后面配的时候容易又混回去。TaoToken 在这里承担的是模型调用通道，也就是 Claude Code 背后那个 LLM 的 API 入口。它不碰 ADT，不碰 ABAP backend，也不替代 MCP server。MCP server 依然通过 ADT 连你的 DEV 系统，TaoToken 只负责让 Claude Code 能稳定地拿到模型响应。

为什么要把模型通道单独拎出来指向 TaoToken？因为 Claude Code 默认的模型 endpoint 在某些网络环境下不稳定，或者需要额外的鉴权配置，而 ABAP 开发场景里我们更希望模型通道是一个可控、可切换、Key 管理清晰的入口。TaoToken 提供的就是这样一个入口：一个 Base URL，一个 API Key，加上你要用的 Model ID，三件套配好，Claude Code 的模型请求就走这条通道，和 MCP 工具通道彻底解耦。

你需要准备的东西不多。第一是 TaoToken 的 API Key，在控制台的 API Keys 页面创建，地址是 https://taotoken.net/api-keys 。第二是确认你要用的 Model ID，Claude Code 场景下通常选 Claude 系列模型，具体可用的模型列表可以在模型对话页面确认 https://taotoken.net/models 。第三是本地 ADT MCP Server 已经能正常启动，abap_lists_destinations能返回你 DEV 系统的 destination，这一步是 ABAP 侧的前置，和 TaoToken 无关，但必须确认，否则后面验证时会分不清是模型通道的问题还是 ADT 通道的问题。

这里有个容易踩的坑：有人把 TaoToken 的 Base URL 直接填进了 MCP server 的配置里，以为这样 MCP 工具调用也会走 TaoToken。这是错的。MCP server 连的是 ADT endpoint，不是模型 API。TaoToken 的 Base URL 只应该出现在 Claude Code 的模型配置里。两边配置字段名很像，都是 Base URL + Key，但语义完全不同，填错位置就是 401 的常见来源。

另外提醒一点，TaoToken 的 API 地址是 https://taotoken.net/api ，这个地址不加任何查询参数，直接作为 Base URL 使用。控制台、文档、模型列表这些页面地址是给人看的，不要填进配置。配置里只认 API 地址。

3. 可复制配置：MCP server 片段与 Claude Code endpoint 改法

这一节是核心，给出可以直接复制的配置。分两部分：MCP server 侧保持不动，Claude Code 侧改模型通道。先看 MCP server 的配置，以常见的mcp.json或 Claude Code 的 MCP 配置为例，ABAP ADT MCP Server 通常这样配：

{ "mcpServers": { "abap-adt": { "command": "npx", "args": [ "-y", "@sap/adt-mcp-server" ], "env": { "ADT_DESTINATION": "DEV_100", "ADT_BASE_URL": "https://your-abap-dev-host:44300", "ADT_CLIENT": "100", "ADT_USER": "your_abap_user", "ADT_PASSWORD": "your_abap_password" } } } }

这段配置里没有任何模型相关的字段，它只负责让 MCP server 连上 ABAP DEV 系统。ADT_DESTINATION是你在 ADT 里配好的 destination 名称，ADT_BASE_URL是 ABAP 系统的 ADT 入口，端口通常是 44300 或 8000，取决于你的系统配置。这部分配好后，Claude Code 应该能列出abap_lists_destinations、abap_creation-get_all_creatable_objects这些 tools。

接下来是 Claude Code 侧的模型通道配置。Claude Code 的模型配置通常在~/.claude/settings.json或项目级的.claude/settings.json里，关键是env段里的三个字段：

{ "env": { "ANTHROPIC_BASE_URL": "https://taotoken.net/api", "ANTHROPIC_AUTH_TOKEN": "sk-your-taotoken-api-key", "ANTHROPIC_MODEL": "claude-sonnet-4-20250514" } }

这三个字段就是三件套：Base URL 指向 TaoToken 的 API 地址，AUTH_TOKEN 填你在 TaoToken 控制台创建的 API Key，MODEL 填你要用的 Model ID。注意ANTHROPIC_BASE_URL后面不要加/v1或其他路径，TaoToken 的 API 地址就是https://taotoken.net/api，路径由客户端自己拼接。ANTHROPIC_AUTH_TOKEN的 Key 以sk-开头，从控制台复制时注意不要带多余空格。

如果你用的是 Claude Code 的 CLI 启动方式，也可以通过环境变量临时覆盖：

export ANTHROPIC_BASE_URL="https://taotoken.net/api" export ANTHROPIC_AUTH_TOKEN="sk-your-taotoken-api-key" export ANTHROPIC_MODEL="claude-sonnet-4-20250514" claude

这样启动的 Claude Code 会用 TaoToken 作为模型通道，同时读取项目里的 MCP 配置连接 ABAP ADT MCP Server。两条链路各走各的，MCP 工具调用不经过 TaoToken，模型请求不经过 ADT。

如果你同时用 Cline 或 CC Switch 这类工具管理多个 MCP server，配置逻辑是一样的：MCP server 段只写 ADT 相关字段，模型段只写 TaoToken 三件套。CC Switch 里切换的是模型通道，不是 MCP server。Cline 的 MCP 配置里如果出现baseUrl字段，要确认它指的是 MCP server 的地址还是模型 API 的地址，这两个不能混。

配好之后，建议先单独验证模型通道，再验证 MCP 工具通道，最后验证两者协同。单独验证模型通道可以用模型对话页面发一条消息，确认 Key 和 Model ID 有效。单独验证 MCP 工具通道可以在 Claude Code 里让它列出可用 tools，确认abap_*系列工具都出现了。两者都通过后，再让它执行一个需要模型决策 + 工具调用的任务，比如读取一个 ABAP 类的源码。

4. 验证请求：用一次 ABAP 类读取确认工具调用贯通

配置改完后，怎么确认工具调用真的贯通了？最直接的方式是让 Claude Code 执行一次 ABAP 类读取请求。这个请求需要模型理解意图、选择合适的 tool、传对参数、拿到 ADT 返回的结果，整条链路任何一环断了都会暴露出来。

在 Claude Code 里输入类似这样的指令：

帮我读取 ABAP 类 ZCL_MCP_DEMO_RUNNER 的源码，并告诉我它实现了哪个接口。

如果链路正常，Claude Code 会先调用abap_creation-get_object_type_details或类似的工具确认类对象类型，然后调用读取类源码的工具，拿到源码后由模型分析并回答。你会在 Claude Code 的输出里看到 tool invocation 的记录，包括调用了哪个 tool、传了什么参数、返回了什么结果。

一个正常的工具调用记录大概长这样：

Tool: abap_get_object_source Arguments: { "objectType": "CLAS", "objectName": "ZCL_MCP_DEMO_RUNNER" } Result: { "source": "CLASS zcl_mcp_demo_runner DEFINITION ...", "status": "success" }

如果这一步成功，说明 MCP 工具通道通了，模型通道也通了，两者协同正常。如果失败，根据报错类型判断是哪条链路的问题：报401通常是模型通道的 Key 或 Base URL 有问题；报local proxy failed通常是模型通道指向了一个不可达的本地代理；报 ADT 相关的错误（比如 destination not found、authorization failed）则是 MCP 工具通道或 ABAP 侧的问题。

再进一步，可以验证一个需要多步工具调用的场景，比如让 Claude Code 读取一个 CDS View 并检查它的 association：

读取 CDS View ZC_MCP_DEMO 的定义，列出它所有的 association 和对应的 target view。

这个任务需要模型先调用工具获取 CDS 源码，再解析源码里的 association 定义。如果模型能正确列出 association，说明工具返回的结构化数据被模型正确理解了，整条链路不仅通了，而且可用。

验证通过后，你可以继续测试更复杂的场景，比如让 Claude Code 创建一个 ABAP 类、跑一次 ATC、或者读取一个 transport request 的 diff。每增加一个工具类型，就多验证一条能力路径。建议按风险从低到高逐步开放：先只读工具（读取源码、查询 destination、获取 service metadata），再写工具（创建对象、激活对象），最后是执行类工具（跑 ATC、跑 ABAP Unit、执行 quick fix）。

5. 本篇常见错排查：401、local proxy failed、reading choices、OAuth

配置过程中最常见的几类报错，这里逐一对照排查。每类报错都对应链路里一个具体的断点，找到断点就好修。

401 Unauthorized。这个报错几乎总是模型通道的问题。检查三件事：ANTHROPIC_AUTH_TOKEN是否填了正确的 TaoToken API Key，Key 是否以sk-开头，是否有多余空格或换行；ANTHROPIC_BASE_URL是否是https://taotoken.net/api，有没有误加/v1或其他路径；ANTHROPIC_MODEL是否是 TaoToken 支持的 Model ID。如果三个都对还报 401，去 TaoToken 控制台确认 Key 是否被禁用或额度是否用完。注意 401 不会来自 MCP 工具通道，ADT 的鉴权失败报的是 403 或 ADT 特定的错误码。

local proxy failed。这个报错说明 Claude Code 尝试通过一个本地代理转发模型请求，但代理目标不可达。常见原因是ANTHROPIC_BASE_URL被设成了http://localhost:xxxx这样的本地地址，但本地并没有对应的代理服务在跑。解决办法是把 Base URL 改回https://taotoken.net/api，让请求直接走 TaoToken，不经过本地代理。如果你确实需要本地代理，要确认代理进程在跑、端口对、转发目标正确。ABAP 开发者容易在 ADT 里配了 HTTP 代理后，把这个代理地址也填进 Claude Code 的 Base URL，这是错的，两者不是一回事。

reading choices 相关报错。这类报错通常出现在模型返回的响应格式不符合预期时，比如返回了空 choices 数组，或者 choices 里的结构不对。根因往往是模型通道返回了非标准响应，可能是 Base URL 指向了一个不兼容 OpenAI 格式的端点，或者 Model ID 填错了导致服务端返回了错误结构。确认 Base URL 是 TaoToken 的 API 地址，Model ID 是有效的 Claude 系列模型。如果用的是第三方兼容层，要确认它支持 Anthropic 的消息格式。

OAuth 相关报错。Claude Code 某些版本会尝试用 OAuth 流程鉴权，如果你用的是 API Key 方式，可能会看到 OAuth token 相关的错误。解决办法是确认配置里用的是ANTHROPIC_AUTH_TOKEN而不是 OAuth 相关的字段，并且没有残留的 OAuth 配置文件干扰。如果之前登录过 Claude 官方账号，清理一下~/.claude下的缓存文件，避免旧凭证覆盖新配置。

ADT 侧报错。如果报错信息里出现 destination、package、transport、authorization 这些词，问题在 MCP 工具通道或 ABAP 侧，不在模型通道。检查ADT_DESTINATION是否和 ADT 里配的一致，ADT_USER是否有对应 package 的权限，ADT_CLIENT是否正确。这类报错和 TaoToken 无关，不要往模型通道上找原因。

排查时的一个实用技巧：把模型通道和工具通道分开测。先用模型对话页面单独测模型通道，确认 Key 和 Model 有效；再在 Claude Code 里让它列 tools，确认 MCP 工具通道通；最后跑一个需要两者协同的任务。这样任何报错都能快速定位到是哪条链路的问题。

6. 把 Claude Code 接进 ABAP 工具链的下一步

配置跑通之后，你可以开始把更多 ABAP 开发动作接进这条链路。建议从只读工具开始扩展，比如用abap_business_services-fetch_service_information读取 OData service 的 metadata，用abap_transport-unifiedDifference查看 transport 的 diff，用abap_atc_get_result获取 ATC 检查结果。这些工具不修改系统状态，风险低，适合先熟悉工具调用的节奏。

等你对工具调用和审批流程熟悉后，再引入会修改系统的工具，比如abap_creation-create_object、abap_activate_objects、abap_run_atc。这些工具在共享 DEV 系统上执行时，建议保留人工确认环节，尤其是创建对象和激活对象这类操作。MCP 协议本身支持 human in the loop，Claude Code 也会在调用工具前展示即将执行的动作，利用好这个机制。

长期做 ABAP 开发的话，可以考虑用 Coding Plan 来管理模型调用额度，地址是 https://taotoken.net/coding-plan 。它适合需要频繁调用模型做代码分析、工具编排的场景，比按次调用更划算。如果你的团队还在评估阶段，先用模型对话页面测试效果，确认链路稳定后再上 Coding Plan。

接入文档在 https://taotoken.net/doc ，里面有各客户端的详细配置说明，包括 Claude Code、Cline、CC Switch 等。遇到配置问题时先查文档，大部分常见错误都有对应说明。API Keys 管理在 https://taotoken.net/api-keys ，Key 的创建、禁用、额度查看都在这里。

最后提醒一点：MCP 工具通道和模型通道分离这个架构，不只适用于 ABAP 场景。任何需要本地工具调用 + 远程模型推理的组合，都可以用同样的思路配置。ABAP 的特殊之处在于 ADT 工具链本身比较重，destination、package、transport 这些概念增加了配置的复杂度，但只要把两条链路分开看，问题就清晰了。