一、背景：我想靠 AI 配置服务挣钱
四月初我在想一件事：Claude Code 越来越多人用，但会配置的人少，不会配置的人苦。中间这个信息差能不能变成钱？
我研究过的路子大概三条：
- 闲鱼挂 ¥79 的 Claude Code 配置服务（帮人装好、配好、调好）
- ¥19.9 资料包（把 CLAUDE.md 最佳实践打包成 PDF 卖）
- Cerebras 免费 API 批量注册 + ¥29/月中转（当时网上有人在做这个）
直觉上觉得都能赚到，但我不确定，因为我根本不知道这个市场现在是什么价位、竞争有多激烈、需求是不是真的。
一个做过电商的朋友说了句话：「你在卖东西之前，先把自己当买家调研一遍市场。」
但我不想手动刷闲鱼，那样太慢、太累、也不客观。
所以我做了一件可能更麻烦但也更有意思的事——让我自己搭的多 agent 系统去帮我做这件事。
二、系统架构：递归 swarm
我本地跑的不是单个 Claude Code，是一套分层 orchestration。
核心思想来自一个很朴素的类比：不是让一个天才做所有事，是让一群蚂蚁分工做完然后汇总。
架构长这样：
foreman (CC Opus · 主窗口 · 总指挥)
│
├─ L1 researcher (Tier A · 深度爬取 + 结构化提取)
│ └─ L2 extractor (Tier F · 免费模型 · 批量解析)
│ └─ L3 formatter (Tier F · 格式归一化)
│
├─ L1 analyst (Tier A · 跨平台对比分析)
│ └─ L2 cross-checker (独立二审 · 不看第一份输出)
│
└─ L1 writer (Tier A · 产出 PIVOT-DECISION.md)
└─ L2 fact-checker (验证关键数字前确认来源)
几个关键设计决策：
1. Tier 分级
按模型成本分四档：S（Opus，稀缺）、A（Sonnet，中端）、B（Haiku，廉价）、F（免费模型，吃爆）。调研爬取用 Tier F，分析汇总用 Tier A，最终判断留在 Tier S 主窗口。核心原则是「最贵的模型只做最贵的判断」。
2. Recursive spawn
任何 worker 遇到子问题，不请示、不等待，直接开子 worker 处理。比如 L1 researcher 在爬闲鱼时发现某个卖家有 271 人想要的 listing，它不是把原始数据抛回来，而是自己起一个 L2 去专门提取那个卖家的定价策略。
但有硬性 guardrail：MAX_DEPTH=3，超过三层直接 abort，不生孙子。每次 spawn 都写进 lineage.log，可以事后查谁派了谁。
3. 三段式：总控 → 执行 → 独立核查
执行线程完成后不直接交回，必须先申请核查。核查线程不看执行过程，只看 artifact。通过才算完成。这条规则是我踩了几次坑之后加的——模型会自信地编数据，独立核查是唯一能拦住它的方式。
4. 通信用文件，不用消息队列
所有 agent 往同一个 delegations.md 写状态。foreman 通过 fswatch 监听文件变动，有变动就重生成 brief，不做定时轮询。markdown 文件 + 事件驱动，比上 message broker 简单得多，也够用。
派单命令长这样：
dispatch --to=researcher \
--scope="/path/to/allowed/dir" \
--readonly="/path/to/context" \
--budget="20min" \
--verify-via="cross-checker" \
"爬闲鱼 AI 配置服务类 listing，提取：标题/价格/销量/评论数/发布时间，输出到 xianyu-raw.jsonl"
--scope 决定它能写哪些目录，--readonly 决定它能读哪些上下文，--verify-via 指定核查员。执行线程越界会被核查打回。
三、实战：调研跑起来
调研分三个并行方向：
方向 A：闲鱼 listing 普查
目标：把 Claude Code 配置服务类的 listing 全量抓下来，提取定价分布。
跑出来的数据里，有几个数字让我记住了：
- 市场中位价：¥24.9
- 销量最高的几个 listing 都是老店，权重已经做起来了
- ¥1-2 的 PDF 资料包有个 listing 显示 79-271 人想要，但单价太低
- ¥79 这个价位的只有新店，几乎没有成交记录
方向 B：竞品死活扫描
我本来打算做的第三条路——Cerebras 中转——这时候出了大问题。
system 让 researcher 去验证当时几个在做 Cerebras 中转的卖家还活着没有，结果：
88code → 403 Forbidden
gaccode → 403 Forbidden
wildcard → 403 Forbidden
同一天，24 把 Cerebras API key 全部返回 403。不是我的 key 出问题，是那批 key 来自同一个批量注册渠道，Cerebras 这边识别到了，整批封掉。
中转这条路当场判死刑——不是技术问题，是信任问题。即使重新搞 20 把活 key，买家凭什么相信一个新店不会也这么突然跑路？
方向 C：需求热度 + 平台交叉验证
同时在微信群和 linux.do 上拉了一遍热词，找真实的买家在哪里问问题、问什么问题。
四、数据结果
三份报告汇到 foreman 主窗口后，我让它做 pivot 决策。几个关键结论：
路径 硬数据 7 天真实预期 闲鱼 ¥79 配置服务 中位 ¥24.9，新店权重 0，被 ¥19.9 老店碾压 0-1 单 闲鱼 ¥19.9 资料包 ¥1-2 PDF 有 79-271 人想要 1-3 单，低利 微信群 ¥99 broadcast 我在目标群自己也是学员，不是老师 0-1 单（信任倒置） Cerebras ¥29/月中转 24 把 key 全 403，跑路阴影 0 单所有路线里，只有一个正向信号：闲鱼上有个 ¥68.2 的 Obsidian + Karpathy 第二大脑 listing 是活着的，而且是那一批里唯一定价超过 ¥50 还有成交的。
这个数字很重要。不是说这个价格区间好做，而是说：「系统化方法论」比「帮人操作一次」值钱。
五、Pivot
调研完的当晚我做了个决定：原来的三条路全停。
不是技术没法做，是市场结构不对。一个新号在 ¥24.9 中位价市场里去竞争「帮人配置」，拼的是店铺权重和服务响应速度，这是老店的主场。
真正有差异化的东西是我花了这么多时间搭出来的这套系统本身——recursive swarm、分层 orchestration、跨 session 持久 memory、live dashboard——这不是配置服务，是一套方法论。
刘小排能靠「月烧 35 万 token」这个数字传播，不是因为他在卖什么，是因为那个数字本身就是 proof of work。我的 proof of work 是这套系统实际跑起来做出来的东西。
所以现在的方向是：先把系统的架构和过程分享出来，让人看到这个东西是真实存在的、能用的、有实际产出的。声誉先于变现。
六、反思
这套 swarm 有什么地方还不够好
首先是深度问题。三层 worker 在这次任务里够用，但如果任务更复杂，比如要做竞品的全量历史定价追踪，L3 这一层的上下文窗口就会开始截断，信息损耗是真实存在的。
其次是核查成本。每个执行任务后面都要接一个独立核查，这个设计保证了结果质量，但会让整体耗时增加 30-40%。对于「要快」的任务来说这是个 trade-off。
最意外的发现
24 把 key 同时 403 这件事。之前知道 key 会失效，但没想到一个批次的 key 会被一次性封掉。以后做任何中转类服务之前要先想清楚 key 来源的 blast radius——同一个来源的 key 出问题，会不会一起死。
什么是我做对的
用系统跑市场调研这件事本身。如果是手动刷闲鱼，我大概花两三个小时会得到一个直觉性的「感觉很卷」的结论。用这套 swarm 跑完之后，我拿到的是带具体数字的结论：中位价 ¥24.9、79-271 人想要但只有 ¥1-2 客单价、24 把 key 全 403。这些数字才是决策的依据，不是感觉。
尾声
帖子写到这里了。
这套系统还在持续跑，我会继续分享后续——包括架构里还没公开的一些设计，以及把这个方法论做成可复用模板的想法。
如果你也在搭类似的 orchestration 系统，或者对 recursive swarm 在具体场景下怎么调参有问题，可以聊。我不卖配置，但对这套架构本身很有话说。
工具栈：Claude Code (Opus 4.7) · Hermes Agent · OpenClaw · dispatch CLI · live-dashboard
数据时间：2026-04-21
5 个帖子 - 5 位参与者