1. 线上 CPU 飙高时Arthas MCP 到底解决了什么问题线上问题定位最怕的不是没有工具而是工具太多、命令太碎、时间太紧。CPU 突然打到 98%接口 RT 从 80ms 涨到 3s用户投诉电话一个接一个你登录机器打开 Arthas面对 dashboard、thread、trace、watch、ognl 一大堆命令脑子里第一反应往往是先敲哪个参数怎么写会不会刷屏把终端打爆Arthas 本身是 Java 线上排障的“瑞士军刀”它能在不重启应用的前提下查看线程栈、追踪方法耗时、监控入参返回值、反编译类、甚至动态重定义类。但它的门槛也很真实你得知道 trace 后面跟全限定类名和方法名得知道 watch 的 condition 怎么写 OGNL得知道 thread -n 3 只看最忙的三个线程。真正耗时的不是敲命令而是每一步“该看什么”的决策。Arthas 接入 MCP 之后这件事的性质变了。MCP 是 Model Context Protocol你可以把它理解成 AI 工具和外部能力之间的“USB-C 接口”Arthas 把 26 个核心诊断命令封装成标准工具AI 客户端通过一个统一的 endpoint 就能调用。你只需要用自然语言描述现象比如“订单服务 CPU 飙到 98%帮我看看哪个线程卡住了”AI 就会按内置的排障路径依次调用 dashboard、thread、trace把结果解析后告诉你根因。但这里有个现实问题AI 客户端要稳定调用 Arthas MCP Server网络链路和鉴权必须可靠。很多人在本地配好 MCP 后遇到 401、local proxy failed、SSE 断流排查半天发现是 endpoint 或 token 的问题。这篇就聚焦一件事把 AI 工具的 MCP 端点改到 TaoToken 的稳定接入层给出可复制的配置片段并演示一次真实报错的完整排查闭环。适合正在用 Cursor、Claude Code、Cline 做 Java 排障的开发者也适合刚接触 MCP 想跑通第一个诊断工具的新人。2. 前置准备TaoToken 接入层与 Arthas MCP Server 的关系在动手改配置之前先把链路讲清楚不然后面报错你都不知道是哪一段出的问题。Arthas MCP Server 是 Arthas 官方提供的实验性模块通过 HTTP/Netty 暴露 JSON-RPC 2.0 接口支持 STREAMABLESSE 流式和 STATELESS请求-响应两种模式。它默认监听本地端口带一个 Bearer Token 做鉴权。AI 客户端MCP Host通过 MCP Client 去连这个 Server把工具调用转成 JSON-RPC 请求。问题在于AI 客户端和 Arthas MCP Server 之间的连接如果直接点对点会遇到几个麻烦。一是 token 管理分散每个客户端配一遍二是网络链路不稳定时SSE 流容易断报 local proxy failed三是团队协作时每个人的 endpoint 和 key 不一致排障经验没法复用。TaoToken 在这里扮演的是统一接入层的角色。你把 AI 工具的 MCP 端点指向 TaoToken 的 API 地址由它来承接鉴权和转发Arthas MCP Server 的 Bearer Token 和 endpoint 只需要在 TaoToken 侧配置一次。这样做的直接好处是客户端配置统一、token 不散落、链路可观测。需要提前准备的东西第一一个可用的 TaoToken API Key。到 API Keys 页面创建复制出来后面配置里要用。地址是 https://taotoken.net/api-keys 注意这个页面不要加 UTM 参数直接访问即可。第二确认你的 Arthas MCP Server 已经启动。Arthas 3.7.x 之后自带 MCP 模块启动方式是在 attach 目标进程后执行 mcp-server 相关命令或者用独立 jar 启动。启动后记下它监听的端口和 Bearer Token。第三选一个支持 MCP 的 AI 客户端。Cursor、Claude Code、Cline 都可以。本文以 Claude Code 和 Cline 的配置为例因为这两个在 Java 排障场景里用得最多。第四确认你的模型 ID。TaoToken 支持多种模型排障场景建议用推理能力强的比如 claude-sonnet 系列或 gpt 系列。模型 ID 在模型对话页面可以查到地址 https://taotoken.net/models 。这里要强调一个配置三件套的概念Base URL、API Key、Model ID。无论你用 Claude Code、Cline 还是 Codex这三个值必须同时正确缺一个就会报鉴权或模型不存在的错。后面第五节会专门拿真实报错来对照。关于 TaoToken 的定位需要说清楚它是 AI 能力的统一接入层不是非法的中间转发。你用它来管理 API Key、切换模型、统一 MCP endpoint所有调用都走标准协议。官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 上有完整的接入文档配置前建议扫一眼。3. 可复制配置把 MCP endpoint 改到 TaoToken这一节是全文最核心的部分所有片段都可以直接复制路径和原文保持一致。我按客户端分开写你对号入座。3.1 Claude Code 的 settings 配置Claude Code 的 MCP 配置放在项目根目录的.mcp.json或者用户级的~/.claude/settings.json里。推荐用项目级方便团队共享。在.mcp.json中写入{ mcpServers: { arthas-diagnose: { type: http, url: https://taotoken.net/api/mcp/arthas, headers: { Authorization: Bearer sk-your-taotoken-api-key, Content-Type: application/json } } } }注意三个点type写http因为 TaoToken 接入层走的是 HTTP 传输url指向 TaoToken 的 MCP 接入路径Authorization里的 key 换成你在 API Keys 页面创建的那串。不要把 Arthas 本地的 Bearer Token 写在这里那个 token 在 TaoToken 侧配置。如果你用的是 Claude Code 的 CLI 模式也可以用命令添加claude mcp add arthas-diagnose \ --transport http \ --url https://taotoken.net/api/mcp/arthas \ --header Authorization: Bearer sk-your-taotoken-api-key添加完用claude mcp list确认状态是 connected。3.2 Cline 的 MCP settings 配置Cline 的 MCP 配置在 VS Code 的设置里路径是cline.mcpServers。打开 settings.json加入{ cline.mcpServers: { arthas-diagnose: { url: https://taotoken.net/api/mcp/arthas, transport: http, headers: { Authorization: Bearer sk-your-taotoken-api-key }, autoApprove: [dashboard, thread, jvm, memory] } } }autoApprove这个字段值得说一下。Arthas 的诊断命令里dashboard、thread、jvm、memory 这几个是只读的不会改应用状态可以设成自动批准省去每次点确认。但 trace、watch、redefine 这类会插入字节码或改类的命令建议保留手动确认避免误操作。3.3 Codex 的 auth.json 配置如果你用 Codex CLI配置在~/.codex/auth.json{ base_url: https://taotoken.net/api, api_key: sk-your-taotoken-api-key, model: claude-sonnet-4-20250514, mcp_servers: { arthas-diagnose: { url: https://taotoken.net/api/mcp/arthas, transport: http } } }这里base_url指向 TaoToken 的 API 根地址api_key是同一个 keymodel填你在模型对话页面确认过的模型 ID。三件套齐了Codex 才能既调模型又调 MCP。3.4 Arthas MCP Server 侧的 Bearer Token 配置TaoToken 接入层需要知道你的 Arthas MCP Server 在哪、token 是什么。这部分在 TaoToken 控制台的 MCP 配置里填不在客户端。你需要提供[arthas_mcp] endpoint http://127.0.0.1:8563/mcp bearer_token your-arthas-local-token mode streamable timeout_ms 30000endpoint是你 Arthas MCP Server 实际监听的地址bearer_token是 Arthas 启动时生成的 tokenmode选 streamable 适合实时监控选 stateless 适合简单集成。timeout_ms建议给到 30000因为 heapdump 这类命令耗时较长。配置保存后TaoToken 侧会做一次连通性检查。如果这里填错客户端调用时会报 502 或 local proxy failed第五节会详细讲怎么排查。4. 验证请求从一次 CPU 飙高诊断跑通闭环配置写完不算完得跑一次真实请求确认链路通了、工具能调、结果能解析。这一节用一个模拟的 CPU 飙高场景带你走完从提问到拿到根因的全过程。4.1 启动 Arthas MCP Server 并 attach 目标进程假设你的订单服务进程 PID 是 12345。先 attachjava -jar arthas-boot.jar 12345attach 成功后在 Arthas 交互界面启动 MCP Servermcp-server --port 8563 --mode streamable看到MCP server started on port 8563就说明起来了。记下这个端口和第三节 TaoToken 侧配置的 endpoint 要一致。4.2 在 AI 客户端发起诊断请求打开 Claude Code 或 Cline输入订单服务 CPU 飙到 98%帮我排查哪个线程导致的高 CPU它卡在哪里了AI 会先调用dashboard工具。你可以在客户端的工具调用日志里看到类似这样的请求{ jsonrpc: 2.0, method: tools/call, params: { name: dashboard, arguments: {} }, id: 1 }Arthas 返回的 dashboard 数据里AI 会解析出 CPU 占用最高的线程。假设返回ID NAME CPU% STATE 29 http-nio-8080-exec-8 89.2 RUNNABLE 12 DubboServerHandler-... 3.1 RUNNABLEAI 识别到线程 29 占用 89.2%接着调用thread工具{ jsonrpc: 2.0, method: tools/call, params: { name: thread, arguments: { id: 29 } }, id: 2 }返回的堆栈里AI 会定位到具体方法。假设堆栈显示at java.util.regex.Pattern$GroupHead.match(Pattern.java:4660) at java.util.regex.Pattern$Curly.match(Pattern.java:4238) at com.example.logging.LogAspect.logAround(LogAspect.java:47) at com.example.order.service.OrderService.getOrder(OrderService.java:123)AI 的分析结论会是线程卡在正则匹配调用链指向 LogAspect 第 47 行的日志切面该切面在处理超长 JSON 请求体时触发了灾难性回溯。4.3 用 trace 命令进一步收敛如果你想确认耗时具体在哪个方法可以让 AI 继续调用trace帮我 trace 一下 com.example.order.service.OrderService getOrder看哪个子调用最慢AI 会调用{ jsonrpc: 2.0, method: tools/call, params: { name: trace, arguments: { classPattern: com.example.order.service.OrderService, methodPattern: getOrder, condition: #cost 100 } }, id: 3 }返回的耗时树里LogAspect.logAround占了 2800ms其他子调用都在 50ms 以内。根因确认。4.4 验证成功的标志一次完整的成功验证你会看到三个信号客户端工具调用日志里有tools/call的请求和响应AI 输出的分析里引用了 Arthas 返回的具体线程 ID 和类名行号你能根据 AI 的建议直接去改代码比如把.*改成[^]*或者加长度限制。如果这三个信号都出现了说明从客户端到 TaoToken 到 Arthas MCP Server 的链路完全通了。接下来就是排错环节把常见的坑提前填掉。5. 常见报错排查401、local proxy failed、reading choices、OAuth这一节拿真实报错来对照每个报错给出原因和修复动作。你遇到问题时直接按图索骥。5.1 401 Unauthorized报错原文Error: MCP server returned 401 Unauthorized {error:invalid_token,error_description:Bearer token is missing or invalid}原因有三种可能客户端的Authorizationheader 没写或写错TaoToken 侧的 Arthas Bearer Token 和 Arthas MCP Server 实际 token 不一致key 过期或被删。排查动作先确认客户端配置里的Bearer sk-...是完整的没有多余空格。然后到 API Keys 页面确认这个 key 状态是 active。最后检查 TaoToken 控制台里填的 Arthas token和 Arthas 启动日志里打印的 token 是否一致。三处都对401 就会消失。5.2 local proxy failed报错原文Error: local proxy failed: dial tcp 127.0.0.1:8563: connect: connection refused这个报错的意思是 TaoToken 接入层尝试连你配置的 Arthas endpoint但连不上。原因通常是 Arthas MCP Server 没启动或者端口写错或者 endpoint 写成了localhost而 TaoToken 侧解析不到。排查动作在服务器上执行netstat -tlnp | grep 8563确认端口在监听。如果没监听回到 Arthas 里重新执行mcp-server --port 8563。如果监听了但还报错把 endpoint 从localhost改成127.0.0.1避免 DNS 解析问题。5.3 reading choices 报错报错原文Error: failed to parse response: reading choices field: unexpected end of JSON input这个报错通常出现在模型调用环节不是 MCP 环节。原因是模型返回的响应体不完整或者 Model ID 填错了导致返回了非预期格式。排查动作到模型对话页面确认你填的 Model ID 是存在的。然后在客户端配置里检查model字段确保没有拼写错误。如果用的是 Claude Code检查~/.claude/settings.json里的 model 和 MCP 配置是否冲突。修复后重启客户端。5.4 OAuth 相关报错报错原文Error: OAuth flow failed: invalid_client有些 MCP 客户端默认走 OAuth 流程但 TaoToken 接入层用的是 Bearer Token不走 OAuth。这个报错说明客户端在尝试 OAuth 授权。排查动作在客户端配置里显式指定auth_type: bearer或者transport: http禁用 OAuth。Claude Code 里可以用--transport http参数强制走 HTTP。Cline 里确认transport字段是http而不是sse或oauth。5.5 配置三件套自检清单遇到任何报错先按这个清单过一遍检查项正确值常见错误Base URLhttps://taotoken.net/api多了斜杠或少了 /apiAPI Keysk- 开头完整串复制时漏字符或有空格Model ID模型对话页面确认过的拼写错误或用了不存在的模型MCP endpointhttps://taotoken.net/api/mcp/arthas写成了本地地址Arthas token与启动日志一致用了旧 token这五项全对基本不会再有鉴权和链路问题。如果还有到接入文档页面查最新的配置示例。6. 把 Arthas MCP 用进日常排障从配置到复现的闭环配置跑通只是起点真正有价值的是把它变成日常排障的固定动作。我自己的习惯是线上告警一响先不急着登录机器而是在 AI 客户端里把现象描述清楚让 AI 通过 Arthas MCP 先拉一轮 dashboard 和 thread拿到初步证据再决定要不要深入。这样做的好处是排障路径被标准化了。以前新人遇到 CPU 飙高可能连 dashboard 都不知道要敲现在 AI 会按内置剧本一步步走先看整体线程再定位高 CPU 线程再看堆栈再 trace 收敛。每一步的返回结果都留在对话记录里事后复盘有据可查。有几个实用技巧值得记下来。第一把常用的诊断请求存成 prompt 模板比如“CPU 飙高排查”“接口变慢排查”“内存泄漏排查”需要时直接调用不用每次重新描述。第二autoApprove只对只读命令开trace、watch、redefine 保持手动确认避免 AI 在你不注意时改了线上类。第三heapdump 这类重命令记得设 timeout30 秒起步不然容易断流。如果你还没配好现在就可以动手到 API Keys 页面创建一个 key按第三节的片段改客户端配置然后 attach 一个测试进程跑一次 dashboard 调用。第一次看到 AI 自动解析出线程 ID 和堆栈行号的时候你会明白为什么这件事值得折腾。长期做 Java 线上排障和 Agent 开发的建议直接上 Coding Plan把模型调用和 MCP 接入的额度一起管起来省得每次单独配。地址是 https://taotoken.net/coding-plan 。需要查模型和调试对话的走模型对话页面 https://taotoken.net/models 。配置过程中卡住了接入文档 https://taotoken.net/doc 里有最新的示例和排错说明。
1. 线上 CPU 飙高时Arthas MCP 到底解决了什么问题线上问题定位最怕的不是没有工具而是工具太多、命令太碎、时间太紧。CPU 突然打到 98%接口 RT 从 80ms 涨到 3s用户投诉电话一个接一个你登录机器打开 Arthas面对 dashboard、thread、trace、watch、ognl 一大堆命令脑子里第一反应往往是先敲哪个参数怎么写会不会刷屏把终端打爆Arthas 本身是 Java 线上排障的“瑞士军刀”它能在不重启应用的前提下查看线程栈、追踪方法耗时、监控入参返回值、反编译类、甚至动态重定义类。但它的门槛也很真实你得知道 trace 后面跟全限定类名和方法名得知道 watch 的 condition 怎么写 OGNL得知道 thread -n 3 只看最忙的三个线程。真正耗时的不是敲命令而是每一步“该看什么”的决策。Arthas 接入 MCP 之后这件事的性质变了。MCP 是 Model Context Protocol你可以把它理解成 AI 工具和外部能力之间的“USB-C 接口”Arthas 把 26 个核心诊断命令封装成标准工具AI 客户端通过一个统一的 endpoint 就能调用。你只需要用自然语言描述现象比如“订单服务 CPU 飙到 98%帮我看看哪个线程卡住了”AI 就会按内置的排障路径依次调用 dashboard、thread、trace把结果解析后告诉你根因。但这里有个现实问题AI 客户端要稳定调用 Arthas MCP Server网络链路和鉴权必须可靠。很多人在本地配好 MCP 后遇到 401、local proxy failed、SSE 断流排查半天发现是 endpoint 或 token 的问题。这篇就聚焦一件事把 AI 工具的 MCP 端点改到 TaoToken 的稳定接入层给出可复制的配置片段并演示一次真实报错的完整排查闭环。适合正在用 Cursor、Claude Code、Cline 做 Java 排障的开发者也适合刚接触 MCP 想跑通第一个诊断工具的新人。2. 前置准备TaoToken 接入层与 Arthas MCP Server 的关系在动手改配置之前先把链路讲清楚不然后面报错你都不知道是哪一段出的问题。Arthas MCP Server 是 Arthas 官方提供的实验性模块通过 HTTP/Netty 暴露 JSON-RPC 2.0 接口支持 STREAMABLESSE 流式和 STATELESS请求-响应两种模式。它默认监听本地端口带一个 Bearer Token 做鉴权。AI 客户端MCP Host通过 MCP Client 去连这个 Server把工具调用转成 JSON-RPC 请求。问题在于AI 客户端和 Arthas MCP Server 之间的连接如果直接点对点会遇到几个麻烦。一是 token 管理分散每个客户端配一遍二是网络链路不稳定时SSE 流容易断报 local proxy failed三是团队协作时每个人的 endpoint 和 key 不一致排障经验没法复用。TaoToken 在这里扮演的是统一接入层的角色。你把 AI 工具的 MCP 端点指向 TaoToken 的 API 地址由它来承接鉴权和转发Arthas MCP Server 的 Bearer Token 和 endpoint 只需要在 TaoToken 侧配置一次。这样做的直接好处是客户端配置统一、token 不散落、链路可观测。需要提前准备的东西第一一个可用的 TaoToken API Key。到 API Keys 页面创建复制出来后面配置里要用。地址是 https://taotoken.net/api-keys 注意这个页面不要加 UTM 参数直接访问即可。第二确认你的 Arthas MCP Server 已经启动。Arthas 3.7.x 之后自带 MCP 模块启动方式是在 attach 目标进程后执行 mcp-server 相关命令或者用独立 jar 启动。启动后记下它监听的端口和 Bearer Token。第三选一个支持 MCP 的 AI 客户端。Cursor、Claude Code、Cline 都可以。本文以 Claude Code 和 Cline 的配置为例因为这两个在 Java 排障场景里用得最多。第四确认你的模型 ID。TaoToken 支持多种模型排障场景建议用推理能力强的比如 claude-sonnet 系列或 gpt 系列。模型 ID 在模型对话页面可以查到地址 https://taotoken.net/models 。这里要强调一个配置三件套的概念Base URL、API Key、Model ID。无论你用 Claude Code、Cline 还是 Codex这三个值必须同时正确缺一个就会报鉴权或模型不存在的错。后面第五节会专门拿真实报错来对照。关于 TaoToken 的定位需要说清楚它是 AI 能力的统一接入层不是非法的中间转发。你用它来管理 API Key、切换模型、统一 MCP endpoint所有调用都走标准协议。官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 上有完整的接入文档配置前建议扫一眼。3. 可复制配置把 MCP endpoint 改到 TaoToken这一节是全文最核心的部分所有片段都可以直接复制路径和原文保持一致。我按客户端分开写你对号入座。3.1 Claude Code 的 settings 配置Claude Code 的 MCP 配置放在项目根目录的.mcp.json或者用户级的~/.claude/settings.json里。推荐用项目级方便团队共享。在.mcp.json中写入{ mcpServers: { arthas-diagnose: { type: http, url: https://taotoken.net/api/mcp/arthas, headers: { Authorization: Bearer sk-your-taotoken-api-key, Content-Type: application/json } } } }注意三个点type写http因为 TaoToken 接入层走的是 HTTP 传输url指向 TaoToken 的 MCP 接入路径Authorization里的 key 换成你在 API Keys 页面创建的那串。不要把 Arthas 本地的 Bearer Token 写在这里那个 token 在 TaoToken 侧配置。如果你用的是 Claude Code 的 CLI 模式也可以用命令添加claude mcp add arthas-diagnose \ --transport http \ --url https://taotoken.net/api/mcp/arthas \ --header Authorization: Bearer sk-your-taotoken-api-key添加完用claude mcp list确认状态是 connected。3.2 Cline 的 MCP settings 配置Cline 的 MCP 配置在 VS Code 的设置里路径是cline.mcpServers。打开 settings.json加入{ cline.mcpServers: { arthas-diagnose: { url: https://taotoken.net/api/mcp/arthas, transport: http, headers: { Authorization: Bearer sk-your-taotoken-api-key }, autoApprove: [dashboard, thread, jvm, memory] } } }autoApprove这个字段值得说一下。Arthas 的诊断命令里dashboard、thread、jvm、memory 这几个是只读的不会改应用状态可以设成自动批准省去每次点确认。但 trace、watch、redefine 这类会插入字节码或改类的命令建议保留手动确认避免误操作。3.3 Codex 的 auth.json 配置如果你用 Codex CLI配置在~/.codex/auth.json{ base_url: https://taotoken.net/api, api_key: sk-your-taotoken-api-key, model: claude-sonnet-4-20250514, mcp_servers: { arthas-diagnose: { url: https://taotoken.net/api/mcp/arthas, transport: http } } }这里base_url指向 TaoToken 的 API 根地址api_key是同一个 keymodel填你在模型对话页面确认过的模型 ID。三件套齐了Codex 才能既调模型又调 MCP。3.4 Arthas MCP Server 侧的 Bearer Token 配置TaoToken 接入层需要知道你的 Arthas MCP Server 在哪、token 是什么。这部分在 TaoToken 控制台的 MCP 配置里填不在客户端。你需要提供[arthas_mcp] endpoint http://127.0.0.1:8563/mcp bearer_token your-arthas-local-token mode streamable timeout_ms 30000endpoint是你 Arthas MCP Server 实际监听的地址bearer_token是 Arthas 启动时生成的 tokenmode选 streamable 适合实时监控选 stateless 适合简单集成。timeout_ms建议给到 30000因为 heapdump 这类命令耗时较长。配置保存后TaoToken 侧会做一次连通性检查。如果这里填错客户端调用时会报 502 或 local proxy failed第五节会详细讲怎么排查。4. 验证请求从一次 CPU 飙高诊断跑通闭环配置写完不算完得跑一次真实请求确认链路通了、工具能调、结果能解析。这一节用一个模拟的 CPU 飙高场景带你走完从提问到拿到根因的全过程。4.1 启动 Arthas MCP Server 并 attach 目标进程假设你的订单服务进程 PID 是 12345。先 attachjava -jar arthas-boot.jar 12345attach 成功后在 Arthas 交互界面启动 MCP Servermcp-server --port 8563 --mode streamable看到MCP server started on port 8563就说明起来了。记下这个端口和第三节 TaoToken 侧配置的 endpoint 要一致。4.2 在 AI 客户端发起诊断请求打开 Claude Code 或 Cline输入订单服务 CPU 飙到 98%帮我排查哪个线程导致的高 CPU它卡在哪里了AI 会先调用dashboard工具。你可以在客户端的工具调用日志里看到类似这样的请求{ jsonrpc: 2.0, method: tools/call, params: { name: dashboard, arguments: {} }, id: 1 }Arthas 返回的 dashboard 数据里AI 会解析出 CPU 占用最高的线程。假设返回ID NAME CPU% STATE 29 http-nio-8080-exec-8 89.2 RUNNABLE 12 DubboServerHandler-... 3.1 RUNNABLEAI 识别到线程 29 占用 89.2%接着调用thread工具{ jsonrpc: 2.0, method: tools/call, params: { name: thread, arguments: { id: 29 } }, id: 2 }返回的堆栈里AI 会定位到具体方法。假设堆栈显示at java.util.regex.Pattern$GroupHead.match(Pattern.java:4660) at java.util.regex.Pattern$Curly.match(Pattern.java:4238) at com.example.logging.LogAspect.logAround(LogAspect.java:47) at com.example.order.service.OrderService.getOrder(OrderService.java:123)AI 的分析结论会是线程卡在正则匹配调用链指向 LogAspect 第 47 行的日志切面该切面在处理超长 JSON 请求体时触发了灾难性回溯。4.3 用 trace 命令进一步收敛如果你想确认耗时具体在哪个方法可以让 AI 继续调用trace帮我 trace 一下 com.example.order.service.OrderService getOrder看哪个子调用最慢AI 会调用{ jsonrpc: 2.0, method: tools/call, params: { name: trace, arguments: { classPattern: com.example.order.service.OrderService, methodPattern: getOrder, condition: #cost 100 } }, id: 3 }返回的耗时树里LogAspect.logAround占了 2800ms其他子调用都在 50ms 以内。根因确认。4.4 验证成功的标志一次完整的成功验证你会看到三个信号客户端工具调用日志里有tools/call的请求和响应AI 输出的分析里引用了 Arthas 返回的具体线程 ID 和类名行号你能根据 AI 的建议直接去改代码比如把.*改成[^]*或者加长度限制。如果这三个信号都出现了说明从客户端到 TaoToken 到 Arthas MCP Server 的链路完全通了。接下来就是排错环节把常见的坑提前填掉。5. 常见报错排查401、local proxy failed、reading choices、OAuth这一节拿真实报错来对照每个报错给出原因和修复动作。你遇到问题时直接按图索骥。5.1 401 Unauthorized报错原文Error: MCP server returned 401 Unauthorized {error:invalid_token,error_description:Bearer token is missing or invalid}原因有三种可能客户端的Authorizationheader 没写或写错TaoToken 侧的 Arthas Bearer Token 和 Arthas MCP Server 实际 token 不一致key 过期或被删。排查动作先确认客户端配置里的Bearer sk-...是完整的没有多余空格。然后到 API Keys 页面确认这个 key 状态是 active。最后检查 TaoToken 控制台里填的 Arthas token和 Arthas 启动日志里打印的 token 是否一致。三处都对401 就会消失。5.2 local proxy failed报错原文Error: local proxy failed: dial tcp 127.0.0.1:8563: connect: connection refused这个报错的意思是 TaoToken 接入层尝试连你配置的 Arthas endpoint但连不上。原因通常是 Arthas MCP Server 没启动或者端口写错或者 endpoint 写成了localhost而 TaoToken 侧解析不到。排查动作在服务器上执行netstat -tlnp | grep 8563确认端口在监听。如果没监听回到 Arthas 里重新执行mcp-server --port 8563。如果监听了但还报错把 endpoint 从localhost改成127.0.0.1避免 DNS 解析问题。5.3 reading choices 报错报错原文Error: failed to parse response: reading choices field: unexpected end of JSON input这个报错通常出现在模型调用环节不是 MCP 环节。原因是模型返回的响应体不完整或者 Model ID 填错了导致返回了非预期格式。排查动作到模型对话页面确认你填的 Model ID 是存在的。然后在客户端配置里检查model字段确保没有拼写错误。如果用的是 Claude Code检查~/.claude/settings.json里的 model 和 MCP 配置是否冲突。修复后重启客户端。5.4 OAuth 相关报错报错原文Error: OAuth flow failed: invalid_client有些 MCP 客户端默认走 OAuth 流程但 TaoToken 接入层用的是 Bearer Token不走 OAuth。这个报错说明客户端在尝试 OAuth 授权。排查动作在客户端配置里显式指定auth_type: bearer或者transport: http禁用 OAuth。Claude Code 里可以用--transport http参数强制走 HTTP。Cline 里确认transport字段是http而不是sse或oauth。5.5 配置三件套自检清单遇到任何报错先按这个清单过一遍检查项正确值常见错误Base URLhttps://taotoken.net/api多了斜杠或少了 /apiAPI Keysk- 开头完整串复制时漏字符或有空格Model ID模型对话页面确认过的拼写错误或用了不存在的模型MCP endpointhttps://taotoken.net/api/mcp/arthas写成了本地地址Arthas token与启动日志一致用了旧 token这五项全对基本不会再有鉴权和链路问题。如果还有到接入文档页面查最新的配置示例。6. 把 Arthas MCP 用进日常排障从配置到复现的闭环配置跑通只是起点真正有价值的是把它变成日常排障的固定动作。我自己的习惯是线上告警一响先不急着登录机器而是在 AI 客户端里把现象描述清楚让 AI 通过 Arthas MCP 先拉一轮 dashboard 和 thread拿到初步证据再决定要不要深入。这样做的好处是排障路径被标准化了。以前新人遇到 CPU 飙高可能连 dashboard 都不知道要敲现在 AI 会按内置剧本一步步走先看整体线程再定位高 CPU 线程再看堆栈再 trace 收敛。每一步的返回结果都留在对话记录里事后复盘有据可查。有几个实用技巧值得记下来。第一把常用的诊断请求存成 prompt 模板比如“CPU 飙高排查”“接口变慢排查”“内存泄漏排查”需要时直接调用不用每次重新描述。第二autoApprove只对只读命令开trace、watch、redefine 保持手动确认避免 AI 在你不注意时改了线上类。第三heapdump 这类重命令记得设 timeout30 秒起步不然容易断流。如果你还没配好现在就可以动手到 API Keys 页面创建一个 key按第三节的片段改客户端配置然后 attach 一个测试进程跑一次 dashboard 调用。第一次看到 AI 自动解析出线程 ID 和堆栈行号的时候你会明白为什么这件事值得折腾。长期做 Java 线上排障和 Agent 开发的建议直接上 Coding Plan把模型调用和 MCP 接入的额度一起管起来省得每次单独配。地址是 https://taotoken.net/coding-plan 。需要查模型和调试对话的走模型对话页面 https://taotoken.net/models 。配置过程中卡住了接入文档 https://taotoken.net/doc 里有最新的示例和排错说明。
