企业官网建设流程全解析

我之前维护了好几个技术博客，每周都要花大半天去扒同类博客找选题、做竞品分析。后来实在扛不住，就搭了一套 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，另外两个是普通脚本。它们的分工如下：

这样设计之后，每个环节都满足三个原则：职责单一、输入输出格式固定、单点可重跑。采集失败就重跑采集，某篇文章分析结果不理想就只重跑那篇，不会牵连整批任务。这比在一个会话里反复修正要省心得多。

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 上遇到了两个很经典的报错，这里给出完整的解决思路。

第一个是安装完以后执行claude，PowerShell 提示：

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_URL：Claude 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 系列模型，流程是：

1. 在 LM Studio 里加载一个模型，开启本地服务；
2. 确认服务端口，一般界面上会直接显示；
3. 配置 Claude Code 环境变量指向http://localhost:1234，具体路径以你本地服务的协议支持为准。

这条路的优点是真的省 token，适合跑"标题分类、粗略摘要、标签提取"这类不需要太强推理的任务。缺点是本地小模型做深度文章分析时，质量比云端模型差一截，我建议只是作为辅助角色接入，比如让本地模型负责 parser 环节的关键词抽取，analyst 环节还是交给云端大模型。

另一条扩展路线是 MCP（Model 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.sh

4. 实跑一轮：从20篇博客到一份结构化报告

理论讲完了，直接看一次真实运行的结果。我当时选了某个 LLM 应用开发方向的博客站点，种子列表里手工放了 20 篇文章。整个过程大概十几分钟，具体环节的效果如下。

4.1 抓取与解析：普通脚本就够，别浪费token

这一步所有工作都是脚本完成的。采集脚本用 curl 抓 HTML，解析脚本用 BeautifulSoup 做清洗。

parse_html.py的核心逻辑大概是：

import sys from bs4 import BeautifulSoup html = open(sys.argv[1], encoding="utf-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", strip=True) # 控制输出长度，防止把无用评论区域也留给模型 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)

这个报错字面意思是连接被重置，常见于网络链路不稳定、请求体积过大或者服务端主动断开。我的排查顺序是：

1. 先重试一次。如果偶发，大概率只是网络抖动，重试一般能过；
2. 用 curl 直接测试 API 服务的连通性。以 DeepSeek 为例：

   curl https://api.deepseek.com/v1/models \ -H "Authorization: Bearer sk-your-key"

   这一步能确认目标服务本身可达，而不是 Claude Code 的问题；
3. 查看 Claude Code 调试日志。运行命令时加--debug参数，能输出请求细节，定位是哪一步断的；
4. 如果每次请求都断，考虑是单次请求内容过大导致超时，可以缩小输入文本长度，或者拆分成多个小请求。

第二类报错是配置层面的，前面提过：

api error: 400 配置错误: claude provider 缺少 base_url 配置

这个的排查更简单。先看当前生效的配置：

cat ~/.claude/settings.json

如果只有ANTHROPIC_API_KEY而没有ANTHROPIC_BASE_URL，就说明你切到第三方 provider 时没写端点地址。补上就行。用 CC Switch 的话，在界面里重新选择一次 provider 通常会帮你重写完整配置，改完记得重启终端让环境变量重新加载。

我把这几个高频报错整理成表，方便快速对照：

5.2 1M上下文不是万能的：控制在源头的token策略

Claude Code 确实支持 1M 上下文的模型模式，很多人在第一次运行博客分析时都会想"那我把 20 篇全塞进去不就行了"。我一开始也这么想，后来发现这是误区。

1M 上下文的优势是"能塞进去"，但不代表"适合做这件事"。我实测下来的感受是：

• 单次请求包含 20 篇文章时，响应时间变长，等待体验明显下降；
• 长文本推理时，越靠后的内容越容易被模型概括成套话，尤其是中间部分的细节经常丢失；
• token 费用也更高，虽然 1M 模式的主要成本是每百万 token 的价格，但无谓地把整站内容重复喂给多个环节，没什么必要。

所以我最后把 token 策略定为：

1. 每个 analyst 会话只读一篇正文加固定 Prompt，大约 4000 到 7000 token；
2. 每篇输出的 JSON 卡片控制在 600 到 1000 token；
3. 只有 reporter 阶段一次性读取 20 份 JSON 卡片，总 token 也就一两万，远小于把所有正文直接塞进去的方式。

换句话说，上下文管理不是等 token 爆了再去优化，而是从数据进入流水线的第一刻就控制在最小必要范围内。这也是 Multi-Agent 带来的连带收益——每个角色看到的上下文都是精简过的，模型反而更专注。

5.3 Windows的VM Platform提示：能绕就别硬刚

有一次我在 Windows 上执行某个涉及文件系统操作的 Claude 功能时，它弹出一行提示：

claude's 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 篇文章时的消耗大概是这样的：

而全交给 LLM 的方案，仅把 20 篇全文喂给模型做一次"通读总结"就要 12 万到 15 万 token，这还没算后续的修正和重跑。混合方案不仅便宜，质量反而更稳。

6.2 从博客分析扩展到选题监控与竞品追踪

架子搭好之后，复用很自然。我把同一条流水线扩展成三个方向的日常任务：

第一个方向是定时选题监控。用 cron 每周执行一次run_pipeline.sh，把关注的博客最新文章拉进流水线，输出一份周报。它告诉我这周哪些主题在升温，哪些方向已经写烂了，哪些还没有人碰。这是我最常用的功能。

第二个方向是竞品差距分析。把竞品的博客和我的博客同时跑一遍流水线，然后让 reporter Agent 对比两份 theme_tags 热力图，找出"对方覆盖较多而我覆盖较少"的空白主题。这个比手工逐个对比高效得多。

第三个方向是结合 MCP 做深度溯源。在前面的基础流水线上，我加了一个 fetch MCP，让分析 Agent 在遇到引用外部链接时，可以自动抓取引用页面来核实原文语义，避免模型凭印象脑补。

模型选型我也做了一套固定策略：

最后再分享一个小技巧：这套流水线第一次跑通时，我犯的唯一的"大错误"是让 analyst 一次性分析五篇博客，结果输出的 JSON 卡片像一个模子刻的，每篇的 weaknesses 几乎一样，没有区分度。后来改成每篇只让 Agent 输出一张独立的分析卡片，再由 reporter 合并成报告，质量问题立刻消失。如果你也要搭类似的 Multi-Agent 流水线，记住一个原则：越细的粒度越好重试，越短的上下文越不容易胡说。博客分析只是一个例子，同样的架子换成竞品公告监控、RSS 摘要聚合、论文批量解读都成立，关键是把角色拆清楚、把输入输出格式锁死，剩下的交给 Claude Code 去处理。