我之前维护了好几个技术博客每周都要花大半天去扒同类博客找选题、做竞品分析。后来实在扛不住就搭了一套 Multi-Agent 的 Claude Code 分析流水线专门用来批量拆解博客文章。这篇文章把这个项目的完整思路、配置流程和排坑记录写出来包括角色怎么拆、Prompt 怎么写、怎么用十几行脚本串起来以及我在 Windows 上踩过的那些 Cloude Code 安装配置问题。适合想用 Claude Code 做批量内容分析、博客监控、竞品追踪的读者参考。1. 为什么我坚持用Multi-Agent拆解博客分析先说结论在尝试用 Claude Code 做博客分析的第一周我就发现把二十篇博客一次性丢给一个会话总结的思路是错的。无论是文章内容理解还是最终报告的可用性都远不如我把任务拆成多个专职 Agent 之后的效果。这个转变不是因为我喜欢折腾架构而是被实际翻车逼出来的。1.1 一次性丢给Claude整站文章的三个翻车点我先描述一下典型场景你想分析某个技术博客最近一个月发的 15 篇文章于是把每篇的正文复制出来拼成一个很长的文本丢给 Claude让它总结这份材料输出选题洞察和写作框架建议。我试过这种方案三次里至少有两次会出现以下问题第一上下文稀释导致前松后紧。15 篇文章正文差不多有 8 到 10 万个 token即使 Claude Code 支持长上下文模式模型对早期文章的细节记忆也会明显变差。我得到的总结里最后 5 篇文章的点评详细、引用准确而最开始的 5 篇基本只剩下标题级别的复述我甚至需要回头对照原文才能确认它没有记错。第二角色混在一起输出忽heavy忽轻。在同一个会话里模型既要承担抓取和筛选的工作又要做深度分析还要当报告编辑。当 Prompt 里同时出现忽略导航栏广告判断这篇是否值得参考用小编语气撰写总结时模型很容易把不同角色的要求混着执行结果就是既不像编辑写的报告也不像分析文档。第三单篇失败传染全批次。有一次因为目标站点反爬其中一篇抓回来的 HTML 是空的模型没有识别出这页没抓到内容反而直接把空页当作该博客已删除此文章写进了总结里导致整个报告里那一条完全失真。因为从头到尾只有一个会话我没法只重跑那一篇。这三件事让我确定博客分析这个任务必须拆。1.2 多Agent的本质把个人分析变成一条编辑部流水线Multi-Agent 拆解的思路说白了就是把一个人从头干到尾变成一个编辑部协作生产。你可以把它想象成一个小型编辑部一个外勤记者负责把原始材料搬回来对应采集 Agent一个初审编辑负责把材料清理干净、去掉噪音对应解析 Agent一个资深编辑负责逐篇审稿、写评语对应分析 Agent最后主编把所有点评汇总成一份完整的选题报告对应汇总 Agent。我的项目里实际上只有两个 Agent 真正调用了 Claude Code另外两个是普通脚本。它们的分工如下Agent角色职责输入输出是否使用LLMcrawler 采集Agent从种子URL提取所有文章链接过滤非文章页种子URL列表文章URL清单否curl加正则parser 解析Agent清洗HTML去掉导航、广告、脚本提取正文HTML源码干净正文纯文本否BeautifulSoupanalyst 分析Agent对单篇文章做深度结构化评估单篇正文加固定Prompt结构化JSON分析卡片是Claude Codereporter 汇总Agent合并所有分析卡片输出最终报告多份JSON卡片Markdown报告是Claude Code这样设计之后每个环节都满足三个原则职责单一、输入输出格式固定、单点可重跑。采集失败就重跑采集某篇文章分析结果不理想就只重跑那篇不会牵连整批任务。这比在一个会话里反复修正要省心得多。2. Claude Code环境准备Windows下坑最集中的环节讲工作流之前先讲环境。因为很多人在环境这步就卡住了根本没机会进入正题。我一开始是在 Windows 上直接搭的结果遇到的问题比写工作流本身还多。2.1 安装、PATH与native binary第一道坎怎么过Claude Code 最标准的安装方式是通过 npm 全局安装前提是你已经有 Node.js 18 以上版本。命令很简单npm install -g anthropic-ai/claude-code装完之后验证版本claude --version但我在 Windows 上遇到了两个很经典的报错这里给出完整的解决思路。第一个是安装完以后执行claudePowerShell 提示claude : 无法将“claude”项识别为 cmdlet、函数、脚本文件或可运行程序的名称。这句话的本质是npm 全局安装目录不在当前用户的 PATH 环境变量里。解决方法是先查 npm 全局目录到底在哪npm prefix -g比如输出是C:\Users\你的用户名\AppData\Roaming\npm那就把这个目录加进系统环境变量 PATH然后重新打开终端。这一步完成后claude --version就能正常输出了。第二个报错比较隐蔽出现在卸载重装时error: claude native binary not installed. either postinstall did not run按字面理解就是安装包里的 postinstall 脚本没执行成功通常是因为安装过程中被杀毒软件拦截或者网络波动导致后续脚本没拉下来。解决方法不复杂强制重装npm uninstall -g anthropic-ai/claude-code npm install -g anthropic-ai/claude-code如果重装一次还不行可以加--force参数试试npm install -g anthropic-ai/claude-code --force装完之后建议在 VS Code 里也验证一下因为很多人的实际使用场景是编辑器内打开 Claude Code 面板。VS Code 里报找不到 claude 命令时记得检查 VS Code 的集成终端有没有继承系统 PATH有时候重启 VS Code 才能生效。2.2 切换第三方模型CC Switch与base_url配置逻辑大多数人不会只用 Claude 官方账号而是会把 Claude Code 接到 DeepSeek、通义千问、GLM 等模型上。这里最方便的方案是用 CC Switch 这类开源配置切换工具它本质上做的事情就是替你修改 Claude Code 的配置文件把请求转发到兼容 Anthropic 协议的目标端点。我最初自己手改配置时犯过一个很典型的错误——只填了 API Key没填 base_url然后 Claude Code 报了这样一个错api error: 400 配置错误: claude provider 缺少 base_url 配置这个报错的原因很直白Claude Code 客户端不知道该把请求发到哪个地址。它默认会去找 Anthropic 官方地址但当你通过 CC Switch 切换了 provider就必须把目标地址写清楚。手动配置时我建议直接在~/.claude/settings.json里加环境变量效果最直观{ env: { ANTHROPIC_BASE_URL: https://api.deepseek.com/v1, ANTHROPIC_API_KEY: sk-your-key-here } }我顺带解释一下为什么是这两个变量ANTHROPIC_BASE_URLClaude Code 所有请求的基础地址切换第三方模型时这里改成目标服务的 Anthropic 兼容端点ANTHROPIC_API_KEY目标服务给你签发的密钥注意它不是 Anthropic 官方密钥而是你选择的第三方服务密钥。用 CC Switch 的好处是不用手动改 JSON图形界面里选一个 provider 它就会自动生成对应配置。但你要理解它背后改的就是这些字段不然遇到切了但没生效的情况会一头雾水。这里有个经验如果你切换第三方模型后普通对话正常但一执行复杂任务就报错优先检查该服务是否完整支持 Anthropic 协议里的工具调用格式。博客分析场景里我让所有 Agent 尽量输出纯文本 JSON 而不是强依赖工具调用就是为了兼容性更稳。2.3 本地模型与MCP给分析流水线加免费外挂如果你预算有限或者有些分析任务要求数据不出本机可以考虑本地模型路线。LM Studio、Ollama 这类工具可以把模型跑在本地然后暴露一个本地 HTTP 端口例如http://localhost:1234再在 Claude Code 配置里把ANTHROPIC_BASE_URL指过去。我当时用 LM Studio 跑过 Qwen 系列模型流程是在 LM Studio 里加载一个模型开启本地服务确认服务端口一般界面上会直接显示配置 Claude Code 环境变量指向http://localhost:1234具体路径以你本地服务的协议支持为准。这条路的优点是真的省 token适合跑标题分类、粗略摘要、标签提取这类不需要太强推理的任务。缺点是本地小模型做深度文章分析时质量比云端模型差一截我建议只是作为辅助角色接入比如让本地模型负责 parser 环节的关键词抽取analyst 环节还是交给云端大模型。另一条扩展路线是 MCPModel Context Protocol。在 Claude Code 里可以用类似这样的配置引入外部能力{ mcpServers: { fetch: { command: npx, args: [-y, mcp-server-fetch] } } }配好之后Claude Code 就能在会话里实时抓取指定 URL 的内容。我在博客分析流水线里用 MCP 主要做一件事当分析 Agent 发现某篇文章引用了外部资料时让它直接通过 fetch 抓取引用链接确认原意而不是猜。对内容分析项目来说这比事后手动核对要省事得多。3. 博客分析工作流的角色拆分与Prompt设计环境准备好之后最核心的部分就是角色怎么拆、Prompt 怎么写。这一步做得好不好直接决定输出的报告能不能用。3.1 四个Agent加一个调度器我在 1.2 里已经画了角色分工表这里补充实际工作时的粒度选择。四个 Agent 的粒度是我试过之后定下来的有人可能觉得四个太少有人觉得太多我的判断标准是每个 Agent 的输入输出是否可以被固定格式描述。采集和解析两个 Agent 用脚本实现不需要 LLM。因为它们面对的是格式相对固定的 HTML 页面用脚本更快、更便宜、更稳定。而分析和汇总这两个环节必须用 Claude Code因为它们需要对内容做语义判断。这中间还有一个隐藏角色——调度器。它不是 LLM Agent而是一个 bash 或 Python 脚本负责按顺序调用各个 Agent、保存中间结果、处理失败重试。这个角色极其重要因为 Multi-Agent 系统里最怕的不是单个 Agent 质量差而是 Agent 之间的数据断链。没有调度器统一管理输入输出文件四个 Agent 很容易各说各话。我在项目里的目录结构长这样blog-analyzer/ ├── prompts/ │ ├── analyst.md │ └── reporter.md ├── raw/ # 采集回来的HTML ├── clean/ # 解析后的纯文本 ├── analyses/ # 单篇JSON分析卡片 ├── parse_html.py # 解析脚本 └── run_pipeline.sh # 调度脚本3.2 Prompt设计让每个Agent只输出可拼接的JSON分析 Agent 的 Prompt 是我迭代最多的地方。我总结出的核心原则有三条。第一格式锁死。不要让 Agent 自由发挥输出结构否则汇总 Agent 合并时会疯掉。我给 analyst 的 Prompt 里明确要求只输出 JSON 对象不要任何额外文字。第二评分维度给锚点。直接让模型写评价容易写空话但给它 0 到 10 分的量化维度它会更倾向于给出可比较的结果。第三要求给证据。任何评价都要对应原文的具体段落或例子不允许只贴形容词。下面是我实际在prompts/analyst.md里使用的 Prompt 模板你是一名资深技术编辑专长是评估技术博客的选题质量和写作结构。 请阅读下面这篇博客正文并严格输出一个JSON对象不要输出任何额外文字。 JSON结构必须如下 { title: 文章标题, theme_tags: [领域标签, 技术标签], target_audience: 目标读者, core_argument: 不超过80字的核心论点, writing_structure: [开头方式, 正文逻辑, 结尾方式], extractable_tips: [可以直接拿走的技巧或观点], quality_score: { clarity: 0, depth: 0, originality: 0, actionability: 0 }, weaknesses: [明显的不足], reader_gain: 读者读完能得到什么 } 要求 - quality_score 的四个维度均为0-10的整数必须有具体得分。 - extractable_tips 必须是你认为读者看完就能用的信息不要写泛泛的结论。 - weaknesses 如果认为没有明显不足写 [] 正文如下 {ARTICLE_TEXT}{ARTICLE_TEXT}是运行时替换成单篇正文的占位符。把所有分析任务统一成这个格式后我遇到的 JSON 解析错误少了很多而且每一篇的点评标准也一致了。这对后面做横向比较极其重要。3.3 用bash编排十几行脚本把四个Agent串起来调度脚本是整个流水线的骨架。我直接用 bash 写逻辑很直白#!/usr/bin/env bash # 1. 读取种子文章URL列表逐篇处理 while read -r url; do # 文件名从URL中提取 fname$(echo $url | md5sum | cut -d -f1) # 2. 采集把页面抓回来 curl -L --max-time 30 -s $url -o raw/$fname.html # 3. 解析用Python脚本把HTML清洗成纯文本 python3 parse_html.py raw/$fname.html clean/$fname.txt # 4. 分析调用Claude Code单轮执行当前Prompt里读入正文再输出JSON PROMPT$(cat prompts/analyst.md) { cat clean/$fname.txt | sed s/{ARTICLE_TEXT}/$(cat clean/$fname.txt)/ ; } | \ claude -p $PROMPT analyses/$fname.json \ || echo $url errors.log done seed_urls.txt # 5. 汇总让Claude Code把所有JSON卡片合并成报告 cat analyses/*.json | \ claude -p 你是一名博客主编请把下列JSON分析卡片合并成一份包含主题热度排行、单篇点评、写作框架借鉴和选题建议的Markdown报告。 \ report.md有两点提醒claude -p是 Claude Code 的非交互单轮执行模式适合脚本调用。单轮跑完就退出不会挂在会话里。上面的示例为了清晰做了一些简化。实际生产里我会在解析环节加一个正文长度检查——如果清洗出来的文本少于 200 字说明很可能是反爬页面或链接失效直接跳过不要浪费一次 Claude 调用。这个脚本是整个系统的调度器它把四个 Agent 串成了一条只需要一条命令就能跑的流水线bash run_pipeline.sh4. 实跑一轮从20篇博客到一份结构化报告理论讲完了直接看一次真实运行的结果。我当时选了某个 LLM 应用开发方向的博客站点种子列表里手工放了 20 篇文章。整个过程大概十几分钟具体环节的效果如下。4.1 抓取与解析普通脚本就够别浪费token这一步所有工作都是脚本完成的。采集脚本用 curl 抓 HTML解析脚本用 BeautifulSoup 做清洗。parse_html.py的核心逻辑大概是import sys from bs4 import BeautifulSoup html open(sys.argv[1], encodingutf-8).read() soup BeautifulSoup(html, html.parser) # 去掉脚本、样式、导航、页脚等非正文区域 for tag in soup([script, style, nav, footer, aside]): tag.decompose() # 优先取article标签取不到就用body article soup.find(article) or soup.body text article.get_text(\n, stripTrue) # 控制输出长度防止把无用评论区域也留给模型 print(text[:12000])跑完 20 篇后clean/目录下每篇文章都是干净的纯文本平均长度在 6000 到 10000 字之间。这一步肉眼可见地过滤掉了大量重复的导航文案和广告为后面节省了不少 token。4.2 分析卡片长什么样一份字段解读下面是 analyst Agent 对其中一篇文章输出的 JSON 卡片示例简化字段{ title: 用向量数据库重新设计推荐系统的召回层, theme_tags: [向量数据库, 推荐系统, 召回策略], target_audience: 有推荐系统基础、想优化召回效果的工程师, core_argument: 把向量召回与传统协同过滤结合可以在保持精度的同时显著提升召回多样性, writing_structure: [ 从线上推荐指标落差问题引入, 逐一对比三种召回方案, 给出工程落地时的数据流示例, 结尾展望混合召回趋势 ], extractable_tips: [ 向量召回适合首先用物品embedding不要一开始就上多路融合, 正负样本比例对向量召回效果影响极大 ], quality_score: { clarity: 8, depth: 7, originality: 8, actionability: 9 }, weaknesses: [没有给出召回效果随数据规模变化的曲线], reader_gain: 读者可以照着他的数据流设计直接搭建第一版混合召回 }这份卡片最大的价值是把我感觉这篇不错变成了这篇在清晰度、深度、原创性、可操作性上分别是什么水平好在哪、缺在哪。当我手里有 20 份这样的卡片时横向比较就有了客观依据。4.3 汇总报告的使用价值选题与竞品差距分析reporter Agent 拿到 20 份 JSON 卡片后输出一份 Markdown 报告。报告里最有价值的部分有四个主题热度排行把卡片里的 theme_tags 聚合统计出现频次就能看出这个博客近期重点在写什么方向高可操作性文章清单extractable_tips 数量多且 quality_score.actionability 偏高的文章说明读者能直接拿走的东西多共性弱点如果多篇卡片都出现没有实验数据或缺少代码示例这类 weaknesses说明这是该博客的固定短板选题空白综合热度排行和整站覆盖范围可以反推那些同类博客都在写你还没碰过的主题。我那次跑出来的一个典型结论是该博客 20 篇文章里向量检索相关占了 6 篇但其中 4 篇都停留在概念对比层面缺少完整代码仓库。这个发现直接变成我后来写向量召回工业级落地系列的选题依据。这就是用工具分析博客的真正意义不是替你看文章而是替你把看过的东西量化成选题决策依据。5. 踩坑实录连接、上下文、Windows权限三类问题跑通流程之后剩下的时间几乎都花在排错上。我把最常遇到的三类问题整理成一条完整的排查链路方便你直接对着抄。5.1 ECONNRESET与400 base_url的完整排查链路我遇到的第一类网络层报错长这样claude api error: connection dropped (econnreset)这个报错字面意思是连接被重置常见于网络链路不稳定、请求体积过大或者服务端主动断开。我的排查顺序是先重试一次。如果偶发大概率只是网络抖动重试一般能过用 curl 直接测试 API 服务的连通性。以 DeepSeek 为例curl https://api.deepseek.com/v1/models \ -H Authorization: Bearer sk-your-key这一步能确认目标服务本身可达而不是 Claude Code 的问题查看 Claude Code 调试日志。运行命令时加--debug参数能输出请求细节定位是哪一步断的如果每次请求都断考虑是单次请求内容过大导致超时可以缩小输入文本长度或者拆分成多个小请求。第二类报错是配置层面的前面提过api error: 400 配置错误: claude provider 缺少 base_url 配置这个的排查更简单。先看当前生效的配置cat ~/.claude/settings.json如果只有ANTHROPIC_API_KEY而没有ANTHROPIC_BASE_URL就说明你切到第三方 provider 时没写端点地址。补上就行。用 CC Switch 的话在界面里重新选择一次 provider 通常会帮你重写完整配置改完记得重启终端让环境变量重新加载。我把这几个高频报错整理成表方便快速对照报错根因排查动作解决方式无法将claude识别为cmdletnpm全局目录不在PATHnpm prefix -g把目录加入PATH并重启终端native binary not installed安装后postinstall未执行检查安装日志强制重装Claude Codeconnection dropped (econnreset)网络链路断开或请求超时curl测试端到端连通性加--debug看日志重试、裁剪单次输入、降级到更小模型400缺少base_urlprovider配置只写了key没写URL查看settings.json补ANTHROPIC_BASE_URL或用CC Switch重选requires VM platformWindows虚拟化功能未启用检查WSL/VM状态启用VirtualMachinePlatform或改用WSL5.2 1M上下文不是万能的控制在源头的token策略Claude Code 确实支持 1M 上下文的模型模式很多人在第一次运行博客分析时都会想那我把 20 篇全塞进去不就行了。我一开始也这么想后来发现这是误区。1M 上下文的优势是能塞进去但不代表适合做这件事。我实测下来的感受是单次请求包含 20 篇文章时响应时间变长等待体验明显下降长文本推理时越靠后的内容越容易被模型概括成套话尤其是中间部分的细节经常丢失token 费用也更高虽然 1M 模式的主要成本是每百万 token 的价格但无谓地把整站内容重复喂给多个环节没什么必要。所以我最后把 token 策略定为每个 analyst 会话只读一篇正文加固定 Prompt大约 4000 到 7000 token每篇输出的 JSON 卡片控制在 600 到 1000 token只有 reporter 阶段一次性读取 20 份 JSON 卡片总 token 也就一两万远小于把所有正文直接塞进去的方式。换句话说上下文管理不是等 token 爆了再去优化而是从数据进入流水线的第一刻就控制在最小必要范围内。这也是 Multi-Agent 带来的连带收益——每个角色看到的上下文都是精简过的模型反而更专注。5.3 Windows的VM Platform提示能绕就别硬刚有一次我在 Windows 上执行某个涉及文件系统操作的 Claude 功能时它弹出一行提示claudes workspace requires the virtual machine platform on windows. enable这行提示的意思是Claude Code 的某些本地沙箱/工作区能力依赖 Windows 的虚拟机平台功能当前系统没启用。如果你只是做博客分析、文本处理这其实不是必选项。我当时的处理方案是两条路并行方案一在管理员 PowerShell 里启用 Windows 虚拟机平台然后重启电脑dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart方案二因为那台机器涉及到其它环境限制我干脆把整个流水线搬进 WSL2 的 Ubuntu 环境里跑。WSL2 本身就会启用完整的虚拟机平台Claude Code 在里面运行不会再触发 VM Platform 提示而且 bash 脚本调度也更顺手。我的建议是如果你平时在 Windows 上主要做文本分析类任务而且没有管理员权限优先考虑直接在 WSL2 里跑流水线绕开这个提示是最省事的。如果你确实需要在 Windows 原生环境里使用 Claude Code 的沙箱能力再去启用虚拟机平台即可。6. 减负与扩展让流水线自己跑起来项目跑通之后我做了一个重要的调整尽量降低对 Claude 的依赖把更多体力活留给普通脚本。这个减法做完整个系统的成本下降了一个量级。6.1 把体力活从LLM手里拿走成本直接降下来我第一版方案里连提关键词、提取标签都让 Claude 做后来发现完全没必要。一个很典型的地方是文章正文清洗。最初我试图写 Prompt 让 Claude Code 直接读 HTML 并输出正文但一次调用要处理几万 token 的杂讯既贵又慢。改成 BeautifulSoup 之后同样的活几乎零成本而且速度是毫秒级。还需要模型做的只剩下理解语义和生成评价两件事。我的成本控制经验可以总结成一条原则能脚本化的体力活不要上模型模型只做判断和生成。按这个原则我实际跑 20 篇文章时的消耗大概是这样的环节实现方式token消耗采集20个页面curl0解析20篇文章BeautifulSoup0分析20篇文章Claude Code单轮调用每篇约4000-7000 token汇总成报告Claude Code单轮调用约10000-20000 token总计混合方案约10万token上下而全交给 LLM 的方案仅把 20 篇全文喂给模型做一次通读总结就要 12 万到 15 万 token这还没算后续的修正和重跑。混合方案不仅便宜质量反而更稳。6.2 从博客分析扩展到选题监控与竞品追踪架子搭好之后复用很自然。我把同一条流水线扩展成三个方向的日常任务第一个方向是定时选题监控。用 cron 每周执行一次run_pipeline.sh把关注的博客最新文章拉进流水线输出一份周报。它告诉我这周哪些主题在升温哪些方向已经写烂了哪些还没有人碰。这是我最常用的功能。第二个方向是竞品差距分析。把竞品的博客和我的博客同时跑一遍流水线然后让 reporter Agent 对比两份 theme_tags 热力图找出对方覆盖较多而我覆盖较少的空白主题。这个比手工逐个对比高效得多。第三个方向是结合 MCP 做深度溯源。在前面的基础流水线上我加了一个 fetch MCP让分析 Agent 在遇到引用外部链接时可以自动抓取引用页面来核实原文语义避免模型凭印象脑补。模型选型我也做了一套固定策略环节推荐模型理由单篇深度分析Claude 长上下文模式判断力强结构化输出稳定多卡片汇总任意可用模型只是合并文本性价比优先标题分类与标签抽取本地小模型Qwen等免费、快、不涉及隐私最后再分享一个小技巧这套流水线第一次跑通时我犯的唯一的大错误是让 analyst 一次性分析五篇博客结果输出的 JSON 卡片像一个模子刻的每篇的 weaknesses 几乎一样没有区分度。后来改成每篇只让 Agent 输出一张独立的分析卡片再由 reporter 合并成报告质量问题立刻消失。如果你也要搭类似的 Multi-Agent 流水线记住一个原则越细的粒度越好重试越短的上下文越不容易胡说。博客分析只是一个例子同样的架子换成竞品公告监控、RSS 摘要聚合、论文批量解读都成立关键是把角色拆清楚、把输入输出格式锁死剩下的交给 Claude Code 去处理。