历史调研 / 分析报告 · 人类可读复盘

由「报告 Agent」对历史产出重新整理校对的单页目录。点击左侧目录跳转，可连翻全部报告。

YQH-47

【调研】Shadow 网络模拟器仓库如何使用

人类可读报告 v2（report-generation skill）

来源 issue： YQH-47 · 【调研】Shadow 网络模拟器仓库如何使用
来源 ID： d51992a7-f185-4e30-b7f5-7096e5a7f46a
原始终稿： ANALYSIS_FINAL / RESEARCH_FINAL（Review：PASS_WITH_NOTES round 2/3）
仓库 snapshot： shadow/shadow @ b25ddbd119c3420149afd7e8c6a0cd9fa8fea2c7（Shadow 3.3.0，CMakeLists.txt）
访问日期： 2026-08-09

结论先行

Shadow 是跑在 Linux x86-64 上的离散事件网络模拟器（按事件推进「仿真时间」，而不是墙钟实时跑完整个网络）：它用 LD_PRELOAD + seccomp 拦截系统调用，让未修改的真实应用二进制在私有虚拟网络里跑，时间、socket 与链路特性由模拟器建模。通信不走真实 Internet，也不实现 BGP 等路由协议。

上手闭环在文档与示例里是完整的：装依赖 → ./setup build/test/install → 写 shadow.yaml → shadow <config> → 在 shadow.data/hosts/<hostname>/ 读 stdout/stderr。本调研为只读静态分析，未在本环境实际构建或跑仿真——下列步骤是「按仓库应如何做」，不是「本机已验证通过」。

背景与范围

问题： 不了解 Shadow 的人如何安装、写配置、运行、看结果。
覆盖： 架构心智模型、依赖与构建、CLI/YAML、输出目录、并行与确定性调优、syscall/安全局限、basic-file-transfer / tgen / tor 示例。
不覆盖： 本机墙钟性能数字、逐 syscall 保真度审计、shadowtools/ 主路径。

方法与证据

Parallel Analysis：三路 Explorer（架构 / 运行 / 质量）→ Architect 综合 → Reviewer 独立核验（PASS_WITH_NOTES）。

分级	本报告中的用法
已核实（源码）	CLI 定义 `src/main/core/configuration.rs`；虚拟 PID 自 1000（`host.rs`）；syscall handler 约 150 臂
文档声称	平台列表、依赖、`setup` 流程、网络图语义、局限与安全页
示例事实	`examples/docs/basic-file-transfer/shadow.yaml` 等仓库内配置
未核实（运行）	本机 `shadow --help`、构建、ctest、三例仿真 exit code
推断	大规模需按 `system_configuration.md` 调 ulimit 等

关键发现

1. 心智模型（3.x，勿与 1.x 插件模型混淆）

拉起 managed 进程并注入 shim（实现侧为 posix_spawn；设计文档仍有 vfork/exec 类措辞）。
preload + seccomp 拦截 syscall → 主进程内模拟时间/fd/socket/网络。
拓扑用 GML 或内置图建模时延/丢包/带宽。
用法：shadow.yaml → shadow → shadow.data/hosts/...。

2. 安装与构建（文档声称；未本机执行）

项	内容
平台	Ubuntu 22.04/24.04、Debian 11–13、Fedora 42；内核目标约 ≥ Linux 5.10
依赖	gcc/g++、cmake≥3.13.4、glib、python≥3.6、rustup、libclang 等（`docs/install_dependencies.md`）
约束	源码树与 install prefix 路径不能含空格
命令	`./setup build --clean --test` → `./setup test` → `./setup install`（默认 `~/.local/bin/shadow`）
Docker 示例	`docker run -it --shm-size=1024g --security-opt seccomp=unconfined ubuntu:24.04`

3. 最小可运行示例（示例事实）

路径：examples/docs/basic-file-transfer/（需宿主已有 python3、curl）。

cd examples/docs/basic-file-transfer
rm -rf shadow.data/
shadow shadow.yaml > shadow.log
ls shadow.data/hosts/   # 常见 server/ 与 client1..3/

配置结构要点：

字段	要点
`general.stop_time`	必填（如 `10s`）
`network.graph.type`	内置 `1_gbit_switch` 或自定义 `gml`
`hosts.*.network_node_id`	必填；挂到图 node（内置图仅 `0`）
`processes[*].path` / `args`	绝对路径、`~/…` 或 PATH basename；args 类 shell 引号但不做变量展开
`expected_final_state`	默认退出 0；server 示例可为 `running`
`model_unblocked_syscall_latency`	忙等场景建议 true（示例为防旧版 cURL）

4. 关键 CLI（源码 clap，非本机 help）

选项	含义
`config`	配置路径；`-` = stdin
`-p, --parallelism`	并行 host 数；配置 `0` ≈ 物理核，实际上限 host 数
`--seed`	仅 long，无 `-s`（文档有过时写法）
`--stop-time` / `-l` / `-d` / `-e` / `--progress`	结束时间、日志级、data 目录、template 目录、进度

5. 如何看结果

进程退出码；shadow.log 中 ERROR（expected_final_state 不符常非 0）。
shadow.data/hosts/<hostname>/ = 该 host 工作目录。
应用输出：<exe>.<pid>.stdout / .stderr；虚拟 PID 从 1000 起。
主日志格式不稳定，不建议写解析器。

6. 调优与确定性

同机多实例默认 CPU pinning 可能互抢：用 taskset 或 --use-cpu-pinning=false（可能显著变慢）。
忙等：优先改应用；否则开 model_unblocked_syscall_latency；native_preemption 破坏确定性。
固定 --seed；避免长期 debug/trace。

7. 局限与安全（硬约束）

能力缺口（文档）： IPv6 未支持；静态链接二进制；sendfile()；TCP_FASTOPEN；realtime signals；vfork≈fork。README 称 150+ syscall API，非全部特性完整。

安全（docs/security.md）： Shadow 不是安全沙箱。不要在其中运行你不信任在本机同权限直接跑的代码；托管程序可逃出仿真发原生 syscall；不限制宿主文件系统。

文档陷阱（以本 commit 源码为准）： seed 无短选项 -s；heartbeat 正确名为 --heartbeat-interval；OpenSSL preload 键为 use_preload_openssl_rng；架构读 design_2x.md 勿读过时的 design_1x.md。

风险与局限

安装/运行步骤未经本环境实测。
官方网站与仓库冲突时以 commit 仓库为准。
Tor 示例模板目录含仿真用密钥文件——仅作教程，勿当生产密钥（只报告路径类型，不复制内容）。
大规模（约 >1000 进程）需调 fd / vm.max_map_count / TasksMax 等。

建议

第一次只用 basic-file-transfer，确认 exit code 与 client stdout。
再进 tgen（需自建 tgen）与 tor（--template-directory / 短选项 -e）。
生产或不可信二进制场景：不要把 Shadow 当隔离边界。
写自动化时以 configuration.rs + shadow_config_spec.md 为准，交叉检查过时文档。

验收要点

安装构建、CLI、最小 yaml、输出目录、调优、局限与安全均有可执行级说明
证据分级清晰；未把未运行步骤写成已验证
来源可回溯至 snapshot b25ddbd… 与仓库 docs/examples
Review 状态透明（PASS_WITH_NOTES）

交付说明

读者与用途： 想第一次跑通 Shadow 的工程师；动作为安装→最小仿真→读输出
证据分级： 已核实（源码/RFC/官方页在锁定 snapshot 或访问日核验）· 文档声称（README/官方文档表述，未独立复现）· 推断（由证据推出的操作建议，非直接观测）
材料访问/锁定参考日： 2026-08-09
源材料： YQH-47 ANALYSIS_FINAL/RESEARCH_FINAL + WS-ARCH/WS-RT/WS-QS；官方 docs https://shadow.github.io/docs/guide 仅交叉引用
UNKNOWN / 待核实： 本机构建与三例仿真墙钟数据；完整已支持 syscall 清单（仓库无独立清单）
标记： REPORT_DRAFT / 人类可读报告 v2（report-generation skill）

YQH-50

只读并行分析 CLIProxyAPI（配合代理池部署）

人类可读报告 v2（report-generation skill）

来源 issue： YQH-50 · 只读并行分析 router-for-me/CLIProxyAPI（配合代理池部署）
来源 ID： eb5e2b73-19c7-46f3-a3d4-a17e74e18fef
原始终稿： ANALYSIS_FINAL（Review：PASS_WITH_NOTES round 1/3）
Snapshot： main / v7.2.125 @ 2e6b1d83f6c304a102aa33c1faf0a4f94d0d331e
访问日期： 2026-08-09

结论先行

CLIProxyAPI 是 Go 实现的自托管 LLM/CLI 协议兼容 API 网关（模块 CLIProxyAPI/v7，Go 1.26）：对下游暴露 OpenAI / Gemini / Claude / Codex 等 HTTP API（默认端口 8317），对上游用多凭据（OAuth / API Key）访问真实厂商。

它不是 sing-box / easy-proxies 一类网络代理或代理池产品。本 snapshot 未发现 与 ss/vmess 等协议或上述栈的代码耦合——出站只消费标准 HTTP(S)/SOCKS5(h) 的 proxy-url。

不必外挂代理池。需要时把池的单一 HTTP CONNECT / SOCKS5 入口写入全局或 per-credential proxy-url。应用层有请求重试与多凭据切换，没有代理 URL 级 failover。

生产最优先安全事实（源码已核实）： 当 api-keys 为空且无其他 access provider 时，业务 API 匿名开放（fail-open）。管理面在配置密钥后等价于配置/凭据 root，须网络隔离 + 强密钥。

背景与范围

回答部署四问：定位与能力、如何配合代理池、需要代理什么、配置与运维。只读并行 E1 架构 / E2 运行部署 / E3 质量安全；未真实打上游流量、未攻击验证。

方法与证据

分级	代表结论
已核实（源码）	路由、`proxy-url` 优先级、无内建池、R1 fail-open、管理面、Docker 端口、WS 默认 `ProxyFromEnvironment`
文档声称	README 定位、EasyCLIProxyAPI 桌面封装
未发现证据	sing-box/easy-proxies/ss/vmess 集成；内建代理健康切换
推断	代理池对接操作步骤、容器网络可达性建议

关键发现

1. 定位

维度	结论
是什么	进程内 / 可嵌入的 LLM·CLI 协议兼容代理服务
API	`/healthz`；`/v1/`；`/v1beta/`（Gemini）；Codex 路径；可选 `/v0/management/*`
典型用法	客户端 Base URL → `http(s)://host:8317` + 下游 `api-keys`；上游凭据在 `auth-dir`（默认 `~/.cli-proxy-api`）或 YAML
适用	多账户聚合、内网统一模型 API、出站须经公司 HTTP/SOCKS
不适用	需要 ss/vmess 原生客户端、内建代理池切换、无鉴权公网暴露、当通用正向代理

2. 请求路径与代理优先级（源码）

下游 → :8317 Gin → AuthMiddleware → 协议 Handler
  → Auth Manager（选号/重试/冷却）→ ProviderExecutor 出站

HTTP 客户端代理优先级：auth.ProxyURL → cfg.ProxyURL → context cliproxy.roundtripper → 默认 Transport（可能受环境 HTTP_PROXY 影响）。

显式直连：proxy-url: "direct" 或 "none"。

3. 配合代理池（重点）

问题	结论
必须外部池？	否
内建池/URL 轮询？	否
对接方式	池暴露单一 `http`/`https`/`socks5`/`socks5h` → 写入 `proxy-url`
多出口	多凭据 × 不同 `proxy-url` + `routing.strategy`（不是 proxy 池）
形态	二进制 / Docker `eceasy/cli-proxy-api` / compose / 可选 Home 集群

失效语义须区分三条路径：

拨号 / HTTP CONNECT 非 200 → 返回 error，由 Manager 请求/凭据重试。
已配 proxy-url 但 transport 构建失败 → 可能 fall through 到 context RT 或默认 Transport（可能绕过已配置 proxy，不是显式 direct）。
部分 WebSocket（Codex 等）默认 ProxyFromEnvironment；勿假设「所有出站强制唯一 proxy-url」。

4. 配置与运维摘要

项	要点
主配置	`config.yaml`（`config.example.yaml` 模板）
默认端口	8317；pprof 示例 8316（默认关）
依赖服务	默认文件 store，无强制外置 DB/Redis
许可	MIT
CI	PR 仅 `go build`，工作流中未发现 `go test`
热更新	watcher + management API

生产清单（置顶）：

必须配置非空强 api-keys（空 = 匿名开放）。
管理面：强 secret 或保持关闭；allow-remote: false 除非网络隔离。
限制监听或防火墙；持久化 auth-dir/config。
需要出站代理时显式配 proxy-url，并理解 WS/构建失败降级。
镜像尽量摘要钉扎；本地应跑关键测试（CI 不强制）。

5. 主要风险

ID	级	摘要
R1	P0	空 `api-keys` → API 匿名开放
R2	P0/P1	管理面可读写全部密钥/config/proxy-url
R3–R4	P1	request-log / query key 易泄漏凭据与提示词
R5	P1	大量测试存在但 PR CI 不跑
R6	P1/P2	代理构建失败降级 + WS 环境代理分叉
R7–R11	P2–P3	CORS/WS Origin、OAuth callback、容器 root、Home insecure-skip-verify 等

风险与局限

静态只读；未跑真实上游/代理流量。
compose 中 8085/11451 与源码绑定关系 UNKNOWN / 待核实。
Home 是否下发/覆盖 ProxyURL 本波未展开。
后续评论中人类要求 SSH 部署已另建执行 issue，不在本只读分析范围内完成。

建议

部署前先做空 api-keys 与管理面暴露检查。
代理池侧做入口 HA，本进程只填单一稳定 URL。
与 easy-proxies / sing-box 联用时：外部先提供标准 HTTP/SOCKS 入站，再写入 proxy-url。
需要代理 URL 级 failover 时，在池侧实现，不要期望本进程轮询节点列表。

验收要点

四问均有明确结论与证据类
代理池对接、流量类型、失效语义分条写清
P0 fail-open 与 Review 吸收项（FALLBACK/WS）可见
未把文档桌面封装名与 easy-proxies 仓库混淆

交付说明

读者与用途： 要部署 LLM API 网关并可能挂代理池的工程师/运维
证据分级： 已核实（源码/RFC/官方页在锁定 snapshot 或访问日核验）· 文档声称（README/官方文档表述，未独立复现）· 推断（由证据推出的操作建议，非直接观测）
材料访问/锁定参考日： 2026-08-09
源材料： YQH-50 ANALYSIS_FINAL + E1/E2/E3；snapshot 2e6b1d83…
UNKNOWN / 待核实： compose 8085/11451 源码定义；Home payload 是否覆盖 ProxyURL；OAuth state 熵/TTL 穷尽审计
标记： REPORT_DRAFT / 人类可读报告 v2（report-generation skill）

YQH-39

延续 multica：文档传递机制与共享知识库接入

人类可读报告（Report Agent 复盘）

来源 issue： YQH-39 · 延续 multica 分析：文档传递机制与共享知识库接入
来源 ID： 0702cb3e-bbef-409b-a6a5-69867c976787
原始终稿： ANALYSIS_FINAL（Review：PASS_WITH_NOTES）
Snapshot： multica-ai/multica @ cd9f4147a57dc469328ad7bbd06f1781e0dc8314
访问日期： 2026-08-09
基线： 父任务 YQH-30

结论（先行）

Multica 没有独立的「共享知识库 / 文档库」一等公民产品抽象。知识与文档主要通过 Issue 描述与评论（富文本）+ Attachment 附件 + 仓库/本地目录资源 + Skill 包 在成员与 agent 之间传递。存储为 本地 uploads 卷或 S3；下载带鉴权/守卫。外部「共享知识库」接入的现实路径是：GitHub 仓库资源、local_directory 资源、skill 导入、以及飞书等 channel 侧文档（间接），而非内建 wiki。

背景与范围

在 YQH-30 全仓分析之上，专项回答：
1）文档/知识在 Multica 内如何传递；
2）共享知识库如何接入（内建 vs 外部）。

方法与证据

三路 Explorer（架构数据流 / 运行协议 / 质量安全）+ Architect fan-in + Review。证据类型：源码路径与配置键、文档声明、未发现证据。

关键发现

1. 内部文档传递路径

载体	机制要点	证据类
Issue / Comment	任务上下文主通道；富文本	源码/产品模型
Attachment	上传/下载 API；本地或 S3；下载守卫	源码事实
`multica attachment` CLI	agent 工作区与 issue 间传文件	运行时/CLI
skill-bundles / custom_env	向 agent 注入技能与环境	配置/源码
pkg/redact	日志/输出脱敏相关	源码
`/api/config` 等	能力与配置下发	源码

2. 知识库接入能力盘点

路径	状态	说明
内建 Wiki/知识库模型	缺口（未发现一等抽象）	非「半成品 wiki」
`github_repo` 资源	已有	仓内代码即知识
`local_directory` 资源	已有	本机目录挂入工作区
skill 导入	已有	可打包流程与知识
飞书/Slack/企微 channel	消息通道	非完整文档库同步产品
Confluence/Notion 原生连接器	未发现证据	勿写成已支持

3. 权限与安全边界（摘要）

附件下载需鉴权；勿假设公开 URL 任意可读。
疑似秘密只报路径类型（原分析遵守）。
外部知识库若经 channel 进入，仍落在 issue/附件权限模型内。

风险与局限

项	说明
无统一知识库	知识碎片化在 issue 线程与多资源类型
检索	跨 issue 语义检索能力边界以源码为准，勿夸大
S3/本地	部署形态影响附件持久化与备份
证据缺口	未跑真实附件二进制；未测全部 channel 文档往返

建议

短期： 用「项目 + 关键 issue + 附件 + github_repo/local_directory + skills」作为知识基线，写清命名与归档约定。
接入外部库： 优先 Git 镜像/子模块式 github_repo，或导出 Markdown 经附件/目录资源注入。
产品缺口： 若需要一等知识库，应单独立项（模型、权限、检索、版本），勿把 issue 评论当永久 wiki。
安全： 附件与 agent 工作区路径隔离；红acted 日志默认开启相关策略。

本报告声称满足的验收要点

一句话结论覆盖传递现状 + 接入可行性
传递路径与接入清单表格化
区分缺口 vs 半成品 vs 已有
风险与证据缺口明示

YQH-38

延续 multica：使用隐患 / Scale / 本机部署

人类可读报告 v2（report-generation skill）

来源 issue： YQH-38 · 延续 multica 分析：使用隐患 / Scale 瓶颈 / 本机部署
来源 ID： c98c7a5b-73fb-4a46-80c7-8d4e9cf73284
原始终稿： ANALYSIS_FINAL（Review 通过链路，PASS_WITH_NOTES 吸收）
仓库： multica-ai/multica（在 YQH-30 基线上定向深挖）
访问日期： 2026-08-09

结论先行

在 YQH-30 全仓只读分析基线上，本专项把 Multica 的使用隐患、水平扩展瓶颈与本机/自托管部署路径拆成可执行结论：

使用隐患集中在「开发便利默认值进生产」：弱 JWT/示例口令、开放注册、错误配置下的管理与 metrics 暴露、特定 channel（如 WeCom）多副本出站约束、日志与 trace 可能带用户内容。
Scale 瓶颈主要在控制面写路径与一致性模型：进程内同步事件总线、无 Redis 时 realtime/限流单机语义、Redis 不可用时限流 fail-open、任务状态机多路径、大量 SQL 迁移升级窗口——不是「单机绝对跑不动」，而是多副本必须配齐 Redis/relay 并接受文档约束。
本机部署路径清晰：make dev / compose（开发多仅 Postgres）/ docker-compose.selfhost.yml（postgres+backend+frontend，默认 loopback、常无 Redis）/ Helm chart；daemon 与 API 分离，本机 agent 靠 multica daemon claim。

本分析为静态只读，未做压测或在线实例探测。

背景与范围

基线： YQH-30 ANALYSIS_FINAL（架构/部署/安全总表）。
本单深挖： 使用角度隐患（WS-USAGE）、Scale（WS-SCALE）、本机部署与 runtime 协议（WS-SELFHOST）。
不做： 改码、攻击利用、生产变更。

方法与证据

三路 Explorer → Architect fan-in → Reviewer → ANALYSIS_FINAL。证据分级：源码事实 / 文档声称 / 代码推断 / 未发现证据（与 YQH-30 一致）。

关键发现

1. 使用隐患（操作者视角）

主题	要点	证据类
弱密钥	`JWT_SECRET` 空时有开发默认回退（启动 warn 不退出）；compose/示例 `change-me-in-production`	已核实（源码+示例）
注册	`ALLOW_SIGNUP` 默认开（`!= "false"`）	已核实
会话 Cookie	主路径 HttpOnly+SameSite=Strict；CloudFront 相关旁路可为 None+Secure——勿概括「全部 Strict」	已核实
WeCom 多副本	文档约束：多副本会静默丢出站消息	文档声称（非动态复现）
Redis 缺失	realtime 单机；限流在 Redis 不可用时 fail-open	已核实
日志	如 `MULTICA_WECOM_TRACE=1` 可能记录消息片段	文档/注释
公开配置	`GET /api/config` 匿名可读部分 CDN 字段（不含附件内容）	已核实（亦见 YQH-39）
本地附件旁路	LocalStorage `/uploads/*` 无成员鉴权	已核实（YQH-39 详）

2. Scale 瓶颈

瓶颈	机制	含义
同步 `events.Bus`	写请求内同步扇出 listener	慢 listener 可拉长写尾延迟（推断，无压测）
Realtime	无 `REDIS_URL` = 进程内 Hub；多 API 节点需 Redis relay	已核实
限流	Redis 依赖；不可用 fail-open	已核实
Task 状态机	queued→dispatched→running/waiting_local→终态；多触发源	回归面大
迁移	610+ SQL + preMigrationHooks；多副本靠 PG advisory lock	升级窗口需演练
Daemon	claim/heartbeat 权威；唤醒仅为 hint	执行面扩展靠多 daemon，不是「多 API 自动均分 agent」

水平扩展检查清单（推断+源码约束）： API 多副本 → Redis + 正确 REALTIME_RELAY_MODE；共享 uploads 或 S3；遵守 WeCom 等 channel 单副本文档；钉扎镜像 tag；显式 MULTICA_PUBLIC_URL。

3. 本机 / 自托管部署

浏览器 → Frontend(:3000) → Backend(:8080)
                              ├── PostgreSQL 17 + pgvector
                              ├── (可选) Redis
                              └── uploads 或 S3
本机 multica daemon ── /api/daemon/* + claim ──┘

形态	要点
开发	`make dev`；compose 常仅 Postgres
Selfhost compose	postgres + backend + frontend；常无 Redis；端口 bind loopback
容器	entrypoint：`migrate up` → server；backend 镜像未见非 root USER（web 有）
Helm	chart 0.1.0 / appVersion latest 倾向；密钥 `existingSecret`
CLI	GoReleaser + `scripts/install.sh --with-server`；`multica daemon start`

协议面：用户 Bearer/PAT 优先于 cookie；daemon mdt_；task token mat_ 绑定 workspace。健康：/health live；/readyz//healthz = DB + 全部 required migration。

风险与局限

无压测数字；「瓶颈」为架构推断 + 代码路径，非 SLA。
在线实例是否使用默认 JWT：未探测。
HA 多云一键 / 官方 Terraform：未发现证据（deploy 以 helm 为主）。
与 YQH-39 附件/知识库风险交叉，部署时应合并阅读。

建议

生产门禁：强随机 JWT_SECRET/DB 口令；ALLOW_SIGNUP=false（或域白名单）；禁止默认 compose 密钥。
多 API 节点：必配 Redis + relay；共享对象存储；阅读 channel 多副本约束。
本机试用：selfhost compose loopback + 单 daemon 即可；不要把开发默认值直接映射公网。
CI/运维：考虑 E2E 子集与依赖漏洞扫描入门禁（YQH-30 已标缺口）。
升级：staging 演练全量 migrate；备份 Postgres。

验收要点

使用隐患 / Scale / 本机部署三条线均有表格式结论
与 YQH-30 风险编号主题对齐且不伪造成动态漏洞
证据分级与未压测边界清楚

交付说明

读者与用途： 要自托管或评估 Multica 扩展性的平台工程师
证据分级： 已核实（源码/RFC/官方页在锁定 snapshot 或访问日核验）· 文档声称（README/官方文档表述，未独立复现）· 推断（由证据推出的操作建议，非直接观测）
材料访问/锁定参考日： 2026-08-09
源材料： YQH-38 ANALYSIS_FINAL + WS-USAGE/WS-SCALE/WS-SELFHOST；基线 YQH-30
UNKNOWN / 待核实： 具体 QPS/延迟数字；生产 existingSecret 是否强制高强度（运营纪律 vs 代码硬门禁）
标记： REPORT_DRAFT / 人类可读报告 v2（report-generation skill）

YQH-30

只读并行分析 multica-ai/multica

人类可读报告 v2（report-generation skill）

来源 issue： YQH-30 · 只读并行分析 GitHub 仓库 multica-ai/multica
来源 ID： fd6736ab-711e-47e5-8895-a53475f2a4e0
原始终稿： ANALYSIS_FINAL（Review：PASS_WITH_NOTES）
Snapshot： origin/main @ c66bffd72264a04eb1b930b8e01241758595f8a4
访问日期： 2026-08-09

结论先行

Multica 是 monorepo 形态的「人与 agent 同 workspace 协作」平台：

控制面： Go HTTP/WS API（默认 :8080）+ PostgreSQL 权威状态 + 可选 Redis（realtime/限流）。
执行面： 同一发布线上的 multica CLI/daemon claim 任务，经 pkg/agent.Backend 驱动多种 agent CLI。
体验面： Next.js web / Electron desktop / Expo mobile，共享 @multica/core|views|ui。

Wave 1 三路只读分析在同一 commit 上互相印证。最高优先级运维风险是错误配置下的弱 JWT/默认口令；最高优先级产品部署约束是文档所述 WeCom 多副本出站静默丢消息（文档约束，非本波动态复现）。质量主门禁扎实（Go race + 大量单测），但 PR CI 无 Playwright E2E，且 未发现 自动依赖漏洞扫描门禁。

后续专项：YQH-38（使用/Scale/本机）、YQH-39（文档/知识库）。

背景与范围

对公开默认分支做只读、证据驱动的并行仓库分析：架构与数据流、运行部署、质量安全。禁止修改仓库、攻击性验证与外部扫描。

方法与证据

Architect 锁定 snapshot → 同轮 E1/E2/E3 → 中文 Draft → Reviewer 独立核验 → ANALYSIS_FINAL。

分级	含义
已核实（源码）	路径/符号/配置键/CI workflow
文档声称	README、SELF_HOSTING、License 附加条件
推断	无压测下的尾延迟、多副本 realtime 运维含义
未发现证据	在扫描边界内无 Dependabot/CodeQL 等

关键发现

1. 架构与数据流

层	路径	职责
前端壳	`apps/web,desktop,mobile,docs`	路由与平台适配
共享 TS	`packages/core,views,ui`	REST、React Query、WS、设计系统
控制面	`server/cmd/server`、`internal/*`	API、域逻辑、事件、IM/VCS
执行面	`server/cmd/multica`、`internal/daemon`、`pkg/agent`	claim + Execute
数据	`server/migrations`（610 SQL）、`pkg/db`（sqlc）	PostgreSQL

主写路径：Client → Auth → handler → service/sqlc → PG → 进程内 events.Bus 同步 Publish → realtime Hub → 前端 React Query。

任务状态：queued → dispatched → running | waiting_local_directory → completed|failed|cancelled。入队触发含 assign/status、mention、chat、autopilot 等。Daemon 唤醒为 hint，权威靠 claim/heartbeat。

Channel：已有 lark/slack/dingtalk/wecom 等适配目录；勿升格为「仅飞书」或「已完全对齐」。

2. 运行与部署

组件	要点
API	`PORT` 默认 8080
开发	`make dev`；compose 常仅 Postgres
Selfhost	postgres+backend+frontend；常无 Redis；loopback bind
K8s	`deploy/helm/multica/`
鉴权	Bearer/PAT 优先 cookie；daemon `mdt_`；task `mat_`
健康	`/readyz` = DB ping + 全部 required migration
镜像	backend 无非 root USER；web runtime `USER nextjs`

3. 质量与许可证

CI：frontend lint/test；backend test-go.sh --race；无 Playwright 于 PR CI。
资产量级：Go *_test.go ~640；TS vitest ~516；e2e specs 12（本地 check.sh 含 Playwright）。
License：Apache-2.0 全文 + Part I 附加条件（托管/嵌入限制）——二次运营需法务评估，非运行时漏洞。

4. 综合风险（主题摘要；完整编号见 FINAL SYN-01…）

主题	级	摘要
SYN-01 弱 JWT	高（错配）	代码默认回退 + 示例占位，须区分两种来源
SYN-02 WeCom 多副本	高（部署约束）	文档声称静默丢出站
SYN-03 弱 DB 口令	中	自托管默认
SYN-04 Redis fail-open	中	限流/单机 realtime
SYN-05/06 供应链与 E2E	中	无自动 vuln CI；E2E 不在 PR
SYN-07 同步 Bus	中	推断尾延迟
SYN-09 镜像 root	低–中	backend
SYN-11 开放注册	低	默认开
SYN-12 License	合规	Part I
SYN-14 公共 URL	中	空时依赖前端 origin 拼 webhook

已有防护：JWT 拒非 HMAC、CSRF、task token 绑定、上传路径穿越守卫、redact、webhook HMAC、sqlc 等。

风险与局限

静态只读：未构建、未测、未扫 CVE、未访问生产。
第三方依赖当前有无 CVE：未跑 audit → 不宣称安全。
结论绑定 snapshot；后续 commit 会使细节过期。

建议

生产部署前按 SYN 表做配置门禁（密钥、注册、网络暴露、Redis）。
扩展阅读 YQH-38、YQH-39。
二次开发先厘清 API ↔ daemon claim ↔ agent workdir 边界。
工程改进方向：E2E/依赖扫描入 CI；backend 非 root；生产硬失败弱密钥。

验收要点

定位、模块、数据流、部署、质量安全均有摘要
风险表证据类型不混淆（尤其 WeCom=文档）
Review NOTES 吸收可见
中文可读，可链回 FINAL 细节

交付说明

读者与用途： 需要快速理解 Multica 仓库全貌的工程师与决策者
证据分级： 已核实（源码/RFC/官方页在锁定 snapshot 或访问日核验）· 文档声称（README/官方文档表述，未独立复现）· 推断（由证据推出的操作建议，非直接观测）
材料访问/锁定参考日： 2026-08-09
源材料： YQH-30 ANALYSIS_FINAL + E1/E2/E3；snapshot c66bffd7…
UNKNOWN / 待核实： 在线实例密钥状态；仓库外是否有 nightly E2E/审计；Channel 对齐矩阵
标记： REPORT_DRAFT / 人类可读报告 v2（report-generation skill）

YQH-29

只读并行分析 daimon3332/easy-proxies

人类可读报告 v2（report-generation skill）

来源 issue： YQH-29 · 只读并行分析 daimon3332/easy-proxies
来源 ID： fb66812c-187c-441d-bd3d-ef41f4d22d23
原始终稿： ANALYSIS_FINAL（Review：PASS_WITH_NOTES）
Snapshot： main @ 36cd8d5628ce5913b336bbe2479f31e6db1f367e
访问日期： 2026-08-09

结论先行

easy-proxies 是基于 sing-box 的单二进制本机代理网关：面向订阅导入、节点测速、池管理与多端口本地代理（默认 multi-port）。数据面内嵌 sing-box；管理面为同进程 HTTP WebUI/REST（管理默认 127.0.0.1:9091，Clash API 默认 127.0.0.1:9092）。

适合个人/小团队在 loopback 运维节点池。本树未发现 Docker/Compose/K8s/systemd 一等模板。与 CLIProxyAPI / Multica 无代码级耦合——联用时它只应作为上游 HTTP/SOCKS 入口被消费。

部署高风险： 管理密码可为空（空则 API 全放行）；normalize() 在 address 为空时默认绑 0.0.0.0（与 example 的 127.0.0.1 不一致）。合规注意： 项目 LICENSE 为 MIT，核心依赖 sing-box/sing 为 GPL-3+。

本 snapshot 上 E3 声称 go test ./... 与 go vet 通过；Reviewer 对关键包抽样复测。

背景与范围

只读并行：架构流、运行/协议/部署、质量安全。未真实滥用代理、未攻击、未 govulncheck。

方法与证据

E1/E2/E3 + fan-in + Review。证据：源码事实 / 文档声称 / 代码推断 / 未发现证据。

关键发现

1. 技术栈与模块

项	内容
语言	Go 1.24.x；`module easy_proxies`
数据面	sing-box v1.12.12 + 自定义 outbound
自定义 outbound	Type `pool`（默认 Tag `proxy-pool`）；Type/Tag `multi-port-dispatch`（Type≠Tag）
状态	modernc SQLite + YAML
关键包	`app`、`config`、`boxmgr`、`builder`、`outbound/pool

2. 数据流

启动：easy_proxies -config <path>（唯一 CLI 标志）→ Load → WebUI/管理面可先于数据面 → 有节点则 Start box。
双存储（源码）： 运行节点在 config.Nodes+已启动 box；候选/池状态在 importer SQLite；启动时 ListPoolNodes 过滤合并。
multi-port： 每节点 Mixed inbound → dispatch → 节点 outbound。
pool： 共享入口 → proxy-pool 按 sequential/random/balance/rotate 选成员，失败黑名单。
全量重载：先 Close 再 Start → 短暂中断窗口；满足条件时可 multi-port 增量调和。

3. 协议边界（识别 ≠ 可构建）

集合	Scheme
builder 支持	vless、vmess、trojan、ss、hysteria2/hy2、tuic、anytls、socks、http/https 等
可识别但不可构建	`ssr://`、经典 `hysteria://`（非 hy2）
文档更宽列表	以 builder ∩ build tags ∩ sing-box 为准，勿只信 README

构建 tags（文档+CI）：with_clash_api with_utls with_quic。

4. 配置默认差异

项	normalize()	example.yaml
mode	multi-port	multi-port
空 address	`0.0.0.0`	`127.0.0.1`
management.password	可空	`""`
multi_port.base_port	24000	24000

5. 质量与发布

测试：34 个 *_test.go；main/app/dispatch 无测文件。
CI：仅 release workflow（linux/windows × amd64/arm64）；无 darwin；无 PR CI/Dependabot。
容器编排模板：未发现。

6. 风险清单（摘要）

ID	级	摘要
R1	高（部署）	管理空密码可读写节点/订阅/备份
R2	高（合规）	MIT 对外 vs GPL-3 核心依赖
R3	中高	入站可无认证 + 默认 0.0.0.0
R4	中	Clash API 无 Secret；env 可改绑定
R5–R9	中–中低	skip_cert_verify、订阅 SSRF 面、GeoIP 无哈希、明文管理 HTTP、配置 0644
R10–R11	低	仅 release CI；备份可替换全配置

风险与局限

未做真实端口联通与浏览器 WebUI 实测。
macOS：文档提及 zip，官方 CI 无 darwin → 需自建。
govulncheck：未跑。

建议

强制非空管理密码；监听保持 loopback 或反向代理+TLS。
入站开启认证；确认 bind 地址非误暴露。
再分发前做法务审阅 GPL-3 义务；补充 NOTICE。
协议以 builder 为准；导入 ssr/hysteria1 预期失败。
作为 CLIProxyAPI 上游时，只暴露单一 HTTP/SOCKS 给对方的 proxy-url。

验收要点

定位、模块、数据流、协议、部署、风险齐全
Type/Tag、双存储、ssr/hysteria 口径与 Review 一致
测试通过表述为 E3 全量 + Reviewer 抽样

交付说明

读者与用途： 评估是否采用 easy-proxies 作本机代理池/多端口入口的工程师
证据分级： 已核实（源码/RFC/官方页在锁定 snapshot 或访问日核验）· 文档声称（README/官方文档表述，未独立复现）· 推断（由证据推出的操作建议，非直接观测）
材料访问/锁定参考日： 2026-08-09
源材料： YQH-29 ANALYSIS_FINAL；snapshot 36cd8d56…
UNKNOWN / 待核实： macOS 是否另有人工资产；govulncheck 结果；Clash API 在真实 sing-box 版本中的默认 ACL
标记： REPORT_DRAFT / 人类可读报告 v2（report-generation skill）

YQH-42

调研 X（原 Twitter）最近热点

人类可读报告 v2（report-generation skill）

来源 issue： YQH-42 · 调研 X（原 Twitter / X Corp）最近的热点消息
来源 ID： 6a737aa3-07f2-4aa7-ac0b-9ef0012bccbd
原始终稿： RESEARCH_FINAL（基于 RESEARCH_DRAFT review_round 2/3，经 Review 收口）
检索窗口： 约 2026-07-26 至 2026-08-09（访问日 2026-08-09）
性质： 时效性舆情/产品动态综述；非股价投资建议

结论先行

在约两周的观察窗内，与 X / X Corp 相关的公开讨论与报道，主要落在几条可核验主线上（具体条目以终稿引用的一手帖文与主流报道为准，且会快速过时）：

产品与平台规则变化（功能、推荐、开发者/API 或商业化相关公开表态）持续占据「官方 + 科技媒体」叙事。
名人/政治/突发公共事件仍是平台上的流量主引擎；平台本身常作为传播层出现，而非每条热点的「公司新闻」。
安全、信任与治理（滥用、深度伪造、地区政策合规）间歇性进入科技与政策媒体议程。
二手聚合（趋势榜截图、自媒体摘要）噪声高——终稿要求区分 X 原帖 / 公司或高管陈述 / 第三方报道 / 推断。

本报告不提供投资建议，不把单条病毒帖升格为公司战略事实。

背景与范围

问题： 「最近 X 上/关于 X 的热点是什么」。
范围： 平台产品动态 + 高互动公共话题中与 X Corp 直接相关者。
不做： 全站趋势的完备统计（无官方完整趋势 API 授权下的全量抽样声称）；不收集隐私数据。

方法与证据

Search Review 流程：RESEARCH_DRAFT → Review 逐条核验链接与归因 → RESEARCH_FINAL。

分级	用法
已核实	在访问日可打开的官方帖、公司博客/Help、具名媒体报道原文
文档声称	X Help/Developer 文档对功能的描述
推断	「为何成为热点」的传播机制解释
弱/待核实	无法归档的二手转述、已删除帖、单一匿名来源

关键发现

1. 如何读「热点」（方法结论，稳定）

层	含义
平台内趋势	地区/时间窗依赖强；截图不可复现即降级
公司动态	以 @X 官方账号、xAI/X 工程博客、Help Center、SEC/监管文件（若有）为准
媒体层	交叉两家以上独立报道再写入「事实」
产品体感	推荐算法与 timeline 因账号而异，个人 TL ≠ 全局热点

2. 窗口内主题簇（结构化摘要）

终稿将条目归入主题簇而非堆砌无关爆款。读者应回到 issue 内 RESEARCH_FINAL 的带 URL 条目表核对每条的：标题/主张、来源类型、访问日、是否仍可打开。

主题簇通常包括：

产品/商业： 订阅、创作者、API/开发者政策、广告或数据相关公开信息。
公共事件传播： X 作为主战场的全球或地区新闻（平台≠事件责任方）。
信任与安全： 身份验证、垃圾信息、深度伪造、地区封禁或合规新闻。
与 xAI 等关联叙事： 仅当来源明确涉及 X 产品或交叉推广时计入；避免把无关 AI 新闻全部算作「X 热点」。

3. 使用本调研时的操作要点

超过 72 小时的「热点」清单应视为历史快照。
引用须带 URL 与访问日；删除帖标 UNKNOWN / 源已失效。
区分「在 X 上热」与「关于 X Corp 的新闻」。

风险与局限

强时效性： 2026-08-09 窗口外的结论需重跑检索。
趋势算法不透明；无法在无数据合作下声称「全球 Top-N 完备」。
政治类话题易受选择性曝光影响；报告保持来源标注而非站队叙述。
部分 DRAFT 轮次曾被要求补链或降级二手源——以 FINAL 为准。

建议

需要「当前」热点时，以本 FINAL 的方法重跑，不要只改日期重贴旧表。
产品决策只采信公司/文档一级来源。
舆情简报模板固定四列：主张｜来源级｜URL｜访问日。
与股价/代币/传闻相关的内容默认降级，除非监管或公司披露。

验收要点

窗口与访问日写明
来源分级与「不完备趋势」边界清楚
不编造具体未在 FINAL 中出现的爆款细节；细节以 issue 内 FINAL 条目表为准
中文可读，服务快速简报读者

交付说明

读者与用途： 需要短时窗口内 X/X Corp 动态简报的读者（运营/研究）
证据分级： 已核实（源码/RFC/官方页在锁定 snapshot 或访问日核验）· 文档声称（README/官方文档表述，未独立复现）· 推断（由证据推出的操作建议，非直接观测）
材料访问/锁定参考日： 2026-08-09
源材料： YQH-42 RESEARCH_FINAL + DRAFT r2 + Review；访问日 2026-08-09
UNKNOWN / 待核实： 全站趋势完备排名；已删除帖原文；算法推荐权重
标记： REPORT_DRAFT / 人类可读报告 v2（report-generation skill）

YQH-40

CPU 配额与 cgroup CPU 保障方案

人类可读报告（Report Agent 复盘）

来源 issue： YQH-40 · 调研：CPU 配额与 cgroup CPU 保障方案（CPU 虚拟化前置）
来源 ID： 7a436dd5-52ac-45c5-b794-3bcd54c3e393
访问日期： 2026-08-09
原始产出状态（重要）：

分册	状态	说明
A. cgroup CPU 配额/保障/保真	`RESEARCH_DRAFT` round1 → Review FAIL	无已通过的 `RESEARCH_FINAL`
B. 支持虚拟时间的 network emulation 平台	`RESEARCH_FINAL`（Review round2 PASS_WITH_NOTES）	成员补充方向；已收口

本复盘不把 FAIL 草案当作已核实方案；A 部分仅摘要草案方向并标 UNKNOWN/待核实，B 部分按终稿整理。

结论（先行）

配额与保障（A，待核实）： Linux cgroup v1/v2 提供 上限（quota/max） 与 相对权重（weight/shares）；「最小保证」通常要配合权重、CPU 充足度或 cpuset/pinning，不是单独一个与物理核一一对应的保真 API。KVM/QEMU 侧的算力保真与 虚拟时钟（kvm-clock、TSC 等） 相关，但原 cgroup 主报告未通过 Review。
网络仿真 + 虚拟时间（B，已通过）： 若目标是「可复现的网络实验 + 虚拟时间」，应优先评估 Shadow、ns-3 相关虚拟时间扩展、DETNET/其他学术系统 等平台能力边界；B 册终稿给出了平台对比与选用注意（详见原 FINAL）。
整体： 本 issue 对「CPU 虚拟化前置完整方案」尚未形成单一通过复核的终局方案；B 册是可用的旁路交付物。

背景与范围

原始诉求：细粒度 CPU 份额、与物理能力保真映射、允许虚拟时钟、运算结果正确。
后补：调研支持虚拟时间的 network emulation 平台。

方法与证据

A：内核/cgroup 文档与容器/K8s 模型检索 → Review 指出证据/口径问题 → 未闭环。
B：平台一手文档/论文检索 → FAIL → 修订 → PASS_WITH_NOTES → RESEARCH_FINAL。

关键发现

A. cgroup 与 CPU 保障（草案级，`待核实`）

概念	常见含义（教科书级，非本 issue 已核验结论）	状态
cgroup v1 `cpu.cfs_quota_us` / `period`	周期内最大 CPU 时间上限	草案提及；待对照内核文档复核
cgroup v2 `cpu.max`	quota/period 合一	同上
`cpu.weight` / shares	相对比例，非绝对保底	同上
K8s request/limit	request≈保障权重语义；limit≈上限	文档模型；待与本场景映射
pinning/cpuset	更接近「固定核」隔离	与 quota 正交
虚拟时钟	kvm-clock/TSC 等维护客户机时间语义	诉求允许；A 册未过审

UNKNOWN： 细粒度「租户算力 = 物理核百分比且结果保真」的推荐参数集与测法——待重新调研并通过 Review。

B. 虚拟时间 network emulation（已通过摘要）

终稿主题：支持 virtual time 的网络仿真/模拟平台盘点（与 cgroup 主线并行）。人类可读要点：

Shadow： 离散事件 + 真实应用二进制 + 模拟时间（与 YQH-47 互补）。
其他平台： 终稿对比了各自「虚拟时间 / 保真 / 规模 / 生态」维度（以原 RESEARCH_FINAL 表格为准）。
选用原则： 先明确要「协议栈仿真」还是「真实二进制 + 虚拟时间」；再看确定性复现与运维成本。
Review notes：部分次要来源强度、版本钉扎等已在 FINAL 中按 notes 处理。

风险与局限

风险	说明
交付不完整	A 主线无 FINAL；不可当作可落地 CPU 虚拟化 runbook
概念混淆	cgroup 限速 ≠ 虚拟化保真；emulation 虚拟时间 ≠ 容器 CPU 保障
超卖	权重共享下争抢会导致尾延迟与「算力漂移」
时钟	错误时钟源可破坏超时、TLS、分布式协议正确性

建议

立刻： 若业务要网络实验 + 虚拟时间，采用 B 册 FINAL + YQH-47 Shadow 指南 推进 POC。
补做 A： 重开 cgroup/KVM 保真调研，强制：内核文档/systemd/K8s 一手引用、quota vs request 对照表、pinning 方案、时钟配置示例、Review PASS 后方可称方案。
勿将 FAIL 草案中的配置片段直接上生产。

本报告声称满足的验收要点

如实标注 A 未通过 / B 已通过
不编造已核实的 cgroup 终局参数
给出后续补研与可用旁路路径
中文可读

YQH-36

复现 RFC 9666 Area Proxy（开源路径）

人类可读报告 v2（report-generation skill）

来源 issue： YQH-36 · 复现 RFC 9666 Area Proxy：开源实现路径与一手证据
来源 ID： c2ac18b3-337b-4f3a-90c3-474e2bc70c8f
原始终稿： RESEARCH_FINAL（Review round 2/3：PASS_WITH_NOTES）
代码基线： FRRouting 312db9ded940（2026-08-08）
访问日期： 2026-08-09
重心： 开源实现路径（商用 EOS 仅附录对照，非验收门禁）

结论先行

开源侧没有可直接部署的 RFC 9666 Area Proxy 成品：在钉扎的 FRR master、以及公开 BIRD/Open/R 检索边界内，未发现 TLV 20 / Area Proxy 代码路径或文档。

主路径 = 在 FRR isisd 自研。 实现挂钩点清晰（TLV 表、LSP 生成/泛洪、IIH/SNP、SPF），但工作量中大：

范围	量级（推断）
M0 静态 Leader、仅核心 IP、不做 SR/RFC 9667	约 4–8 人周
含动态选举（RFC 9667）与 SR	数人月

关键难点：（1）按电路的 boundary 过滤与 IIH/SNP 源改写；（2）Proxy LSP 生命周期（勿与真实 sysid own LSP 互 purge）；（3）Inside 忽略 Proxy LSP 内容及多出口下 inter/intra metric 分层。
P0 交付建议： FRR M0 最小可验证原型 + topotest。

RFC 9666 本身为 Experimental（2024-10），不是 Internet Standard。

背景与范围

任务从「商用复现」调整为：用开源代码把 Area Proxy 做出来要改哪里、怎么验收。与 YQH-19（机制）、YQH-20（可部署软件矩阵）互补。

方法与证据

Search Review 多轮：round 1 商用向 FAIL → round 2 开源重心 PASS_WITH_NOTES。证据来自 FRR raw.githubusercontent 钉 commit 文件与 RFC 9666/IANA。

分级	用法
已核实（源码负证据）	FRR 无 type 20；泛洪真实路径为 `lsp_flood`→`_lsp_flood`/`lsp_set_all_srmflags`（无 `isis_flood.c`）
已核实（RFC）	TLV 20、Proxy LSP、§5.2 MUST 过滤
推断	人周估算、拟议 CLI/结构体
未发现证据	FRR/BIRD/OpenR 成品 Area Proxy

关键发现

1. FRR 负证据（baseline `312db9ded940`）

断言	结果
`isis_tlvs.h` 枚举	`PURGE_ORIGINATOR=13` → `EXTENDED_REACH=22`，无 20
`struct isis_tlvs`	无 proxy 字段
未知 TLV	`unpack_tlv_unknown` 跳过
官方 isisd 文档	无 Area Proxy
fabricd	OpenFabric，≠ Area Proxy

2. 改造挂钩（实现建议，非已合并代码）

步骤	符号/位置
注册 TLV 20	`isis_tlvs.h/.c` 枚举、`tlv_table`、`pack_order`
成员 LSP 附 TLV 20	`lsp_build`
合成 Proxy LSP	新 `lsp_generate_area_proxy()`；源=proxy_sysid；不含 TLV 20
主过滤点	`lsp_set_all_srmflags` 逐电路：`circuit_should_receive_lsp` 再入队
IIH/CSNP/PSNP 源	`put_hello_hdr` / `send_csnp` / `send_psnp` → proxy_sysid；§5.2 过滤后空则不发
SPF	Inside：本区 proxy LSP 忽略内容仍可 flood
配置	拟议 `area-proxy` / boundary 电路标志
测试	新 topotest `isis_area_proxy_topo1`

3. RFC §5.2 MUST（验收用）

L2 LSP 源 ∈ L1 LSDB → 对 Outside MUST NOT flood
含 Area Proxy TLV 的 L2 LSP → MUST NOT flood
CSNP/PSNP 过滤上述条目；滤空 MUST NOT 发；源 MUST = Area Proxy System ID

4. M0 范围纪律

静态 Leader；IP only；边界强制 P2P（RFC §2 LAN 限制）
不做 SRGB/Area SID、不做 9667 动态选举（升 M1）
Outside 路由器不必实现 Area Proxy（靠 Proxy LSP 扁平化）

风险与局限

人周为经验推断，非报价。
未提交任何 FRR 补丁；未跑 topotest。
多出口 metric 分层若拖到多链路生产拓扑前未做，可能导致次优/环——终稿将其标为多出口前必做。
改 lsp_set_all_srmflags 时勿破坏 fabricd 路径。

建议

立项 P0：FRR M0 + 自动化 topotest 覆盖 §5.2 四类可观测标记（亦见 YQH-20）。
商用对照读 YQH-20（Arista EOS）；不要把 EOS 当开源验收门禁。
机制不懂先读 YQH-19。
上游贡献前与 FRR 社区确认 TLV/CLI 命名，避免与 OpenFabric 混淆。

验收要点

开源负证据与 FRR 自研主路径明确
符号级改造表与 §5.2 MUST
M0/M1 范围与工作量量级
Review PASS_WITH_NOTES 与 notes 吸收说明

交付说明

读者与用途： 要在 FRR 上实现/复现 Area Proxy 的协议与开发工程师
证据分级： 已核实 · 文档声称 · 推断（见 report-generation skill）
材料访问/锁定参考日： 2026-08-09
源材料： YQH-36 RESEARCH_FINAL；FRR 312db9ded940；RFC 9666；交叉 YQH-19/20
UNKNOWN / 待核实： 实际人周与补丁合入；Open/R 私有树是否另有实现
标记： REPORT_DRAFT / 人类可读报告 v2（report-generation skill）

YQH-20

RFC 9666 实际可部署软件实现

人类可读报告 v2（report-generation skill）

来源 issue： YQH-20 · 调研 RFC 9666 Area Proxy for IS-IS：实际可部署的软件实现
来源 ID： 58123679-cde7-4829-8b25-4be3ace1744d
原始终稿： 中文 RESEARCH_FINAL（round 3/3 recheck：PASS_WITH_NOTES；英文 FINAL 仅内部基线）
访问日期： 2026-08-09

结论先行

截至 2026-08-09，公开可证实、已随产品交付的 IS-IS Area Proxy（RFC 9666 谱系）实现，检索边界内仅有 Arista EOS：官方 TOI 显示引入于 EOS 4.25.1F，并仍出现在 EOS 4.36.1F 用户手册（中间发行版/平台未逐一审计；上线前须向 TAC 确认受支持版本与许可）。

对象	公开可部署性
Arista EOS	G1 单厂商商业 GA 级（附 G2 保留：完整 TOI 正文常需登录；平台/许可/控制面-转发面矩阵不完整）
FRRouting isisd	G0 — 钉 commit 无 TLV 20 / Area Proxy 路径
BIRD	N/A — 公开树无 IS-IS 模块
Cisco / Juniper / Nokia / Huawei 公开资料	G0 — 未发现 RFC 9666 支持声明
学术 OMNeT++/ANSA 等	G4 仿真，非产品
多厂商互通 / 纯开源成品部署	无公开证据

「支持 IS-IS」≠ 支持 Area Proxy。标准列表缺席 ≠ 已证明未实现。

背景与范围

回答：谁能实际部署 RFC 9666 行为（Proxy LSP、TLV 20、Leader、边界过滤），而非只复述标准。开源实现细节见 YQH-36；机制见 YQH-19。

方法与证据

Search→Review 多轮（含语言门禁：对外简体中文）。证据规则：

等级	含义
G1	带版本的官方 TOI/UM/命令参考
G2	预览或强限制
G3	开源合入+测试+发行说明
G4	原型/仿真
G5	仅 RFC/draft
G0	无公开证据（写检索边界）
N/A	根本不是 IS-IS 实现

博客/论坛仅线索；第三方镜像 PDF 低于厂商一手域名。

关键发现

1. RFC 要什么（可观测）

RFC 9666 Area Proxy for IS-IS，Experimental，2024-10。解决：稠密 L3 fabric 若需 L2 穿越，内部拓扑灌进 L2 LSDB，层次扩展失效。

角色	行为
Inside	L1+L2；L2 LSP frag0 通告 TLV type 20
Area Leader	生成单一 Proxy LSP，把 Inside 抽象成一个 L2 节点
Edge	过滤内部 L2/TLV20 不外泄；boundary 朝 Outside
Outside	不必实现 Area Proxy

验证标记： 区内 TLV20；Proxy LSP 源=proxy sysid 且不含 TLV20；区外 LSDB 隐藏内部节点；内部邻接变化不整拓扑外泄。

IANA：TLV 20 Area Proxy。

2. 开源矩阵（钉扎日 2026-08-09）

项目	钉扎	结论
FRR	`312db9ded940…`	无 type 20；文档无 Area Proxy → G0
BIRD	v2.19.0 `b82055f0…`	无 isis proto → N/A
Open/R	公开检索边界内	无 Area Proxy 成品声明 → G0（路径数不写死）

3. 商用矩阵（摘要）

厂商	公开证据
Arista	TOI 索引 + EOS UM 字段 → 唯一 G1
Cisco/Juniper/Nokia/Huawei	公开特性矩阵/文档检索未发现 RFC 9666 声明 → G0

完整 URL 表见 issue 内中文 RESEARCH_FINAL 来源清单。

4. 实验室 vs 生产

实验室开源： 按 YQH-36 在 FRR 自研 M0；或仿真（G4）。
生产（公开证据）： 仅评估 Arista 路径；上线前 TAC 确认平台、许可、版本；无公开多厂商互通证明。
相似但不等价功能（普通 L1/L2 汇总、其他 fabric 扩展）列入排除表，避免误报「已支持」。

风险与局限

TOI 全文门禁 → 部分细节 UNKNOWN。
未做各厂商设备实机抓包。
Experimental RFC：生产采用属组织风险决策。
证据随版本过期；引用须带访问日与 commit/版本。

建议

需要今天就能买到的实现：走 Arista 官方支持渠道确认 SKU/版本。
需要开源可控：立项 FRR M0（YQH-36），接受 G0→自研。
RFP 问卷明确写「RFC 9666 Area Proxy / TLV 20 / Proxy LSP」，勿只写「IS-IS」。
互通测试：无第二 G1 前不要假设多厂商 fabric 已可互操作。

验收要点

分级可部署性结论（非 yes/no）
开源/商用矩阵与负证据边界
证据规则 G0–G5
对外中文终稿经语言门禁

交付说明

读者与用途： 要选型「谁能部署 Area Proxy」的网络架构师/采购技术评审
证据分级： 已核实 · 文档声称 · 推断（见 report-generation skill）
材料访问/锁定参考日： 2026-08-09
源材料： YQH-20 中文 RESEARCH_FINAL（r3）+ Review recheck；交叉 YQH-19/36
UNKNOWN / 待核实： Arista 全平台/许可矩阵；未公开的厂商内部实现；多厂商互通实测
标记： REPORT_DRAFT / 人类可读报告 v2（report-generation skill）

YQH-19

调研 RFC 9666 Area Proxy for IS-IS

人类可读报告 v2（report-generation skill）

来源 issue： YQH-19 · 调研 RFC 9666：Area Proxy for IS-IS
来源 ID： 608f5e90-a728-4397-ac44-c224743a91fe
原始终稿： RESEARCH_FINAL（prior Review：PASS_WITH_NOTES）
访问日期： 2026-08-09

结论先行

RFC 9666（Area Proxy for IS-IS，2024-10，Experimental）给 IS-IS 增加一种层次抽象：把一个需要 L2 穿越的稠密 Inside 区域，在 Outside 看来变成单个 L2 节点（由 Area Leader 生成的 Proxy LSP 描述），从而避免把内部 fabric 拓扑全部灌进 L2 LSDB。

核心可观测机制：

Inside 路由器在 L2 LSP 中携带 Area Proxy TLV（IANA type 20） 声明成员资格；
Area Leader（选举细节另见 RFC 9667 谱系材料）生成 Proxy LSP（源 ID = Area Proxy System ID，不含 TLV 20）；
Edge/boundary 按 RFC MUST 过滤：内部 L2 LSP / 含 TLV 20 的 LSP 不得泄向 Outside；SNP 同源改写与空包抑制；
Outside 路由器不必实现 Area Proxy——它们只看到代理节点与附着可达性。

本标准不是「又一种普通 L1/L2 汇总」的别名；也未规定 MPLS 为必选（文中 MPLS 流量属未来工作）；SR 相关为可选扩展。实现现状见 YQH-20/36。

背景与范围

问题： Area Proxy 解决什么、控制面如何工作、如何验收。
范围： RFC 正文机制与 IANA；不展开全厂商矩阵（YQH-20）与 FRR 补丁设计（YQH-36）。
分域基础概念： YQH-15；大规模切分：YQH-17。

方法与证据

一手：https://www.rfc-editor.org/rfc/rfc9666.html 与 datatracker；IANA isis-tlv-codepoints。Review 核验机制表述与过度推断。

分级	用法
已核实	RFC 章节主张、IANA type 20
文档声称	工作组背景叙述（若引 draft 历史）
推断	部署拓扑建议、与 leaf-spine 的贴合度

关键发现

1. 要解决的问题

经典 IS-IS：L1 非穿越时可向 L2 隐藏 L1 拓扑。但在 L3 leaf-spine 等需要 L2 级穿越的结构里，内部链路状态会进入 L2，层次收益下降、LSDB/SPF 放大。

2. 角色与数据流（概念）

[Inside routers] --L1+L2-- 宣布 TLV 20
       |
  Area Leader 合成 Proxy LSP（扁平化 Inside）
       |
  Edge 过滤 §5.2 MUST
       |
[Outside L2] 只见 Proxy 节点 + 可达性

3. 与「普通汇总」的差别

点	普通 L1/L2	Area Proxy
Outside 所见	多前缀/多节点可达性，视设计而定	单一代理系统 ID/主机名抽象
内部拓扑外泄	穿越场景易外泄	目标：隐藏内部 fabric 节点
Outside 是否改码	标准 L2	通常不必实现 9666
标准成熟度	长期 IS-IS 基线	Experimental

4. 验收/抓包标记（运维可读）

区内节点 L2 LSP frag0 含 TLV 20
Proxy LSP：Source = proxy sysid，无 TLV 20
区外 L2 LSDB 无内部 leaf/spine 细节点
仅内部链路 flapping 不应导致完整内部拓扑出现在区外

5. 明确非目标 / 边界

非 Internet Standard；实验性部署需自担风险。
聚焦 IP；SR/Area SID 等为可选或后续。
Leader 动态选举完整行为需结合 RFC 9667 等，勿把 9666 单独当成选举规范全书。
边界 LAN 限制见 RFC §2（实现上常强制 P2P boundary）。

风险与局限

Experimental 状态：互操作与实现完整度参差（见 YQH-20）。
错误过滤可导致分区或环——边界配置是安全关键点。
教学类比（「把 area 压成超级节点」）不可替代 RFC 状态机细节。

建议

读标准顺序：YQH-15 分域 → 本报告机制 → YQH-20 谁能部署 → YQH-36 开源怎么做。
实验室验收以四类可观测标记 + §5.2 MUST 为清单。
生产决策单独评估 Experimental 风险与厂商支持（YQH-20）。

验收要点

问题动机与角色清晰
TLV 20 / Proxy LSP / Outside 无需实现三点不混
与普通汇总对照表
可观测验收标记

交付说明

读者与用途： 要理解 RFC 9666 机制本身的网络工程师
证据分级： 已核实 · 文档声称 · 推断（见 report-generation skill）
材料访问/锁定参考日： 2026-08-09
源材料： YQH-19 RESEARCH_FINAL；RFC 9666；IANA TLV 20；交叉 YQH-15/17/20/36
UNKNOWN / 待核实： 9667 选举细节全文展开；实机抓包样例（本单未强制）
标记： REPORT_DRAFT / 人类可读报告 v2（report-generation skill）

YQH-18

软 Loop：北京 2026-08 旅行计划

人类可读报告 v2（report-generation skill）

来源 issue： YQH-18 · 软 Loop 验证：北京 2026 年 8 月旅行计划
来源 ID： c435d3ef-4164-4e12-b352-bd6ad96a6c40
原始终稿： RESEARCH_FINAL（Review round 1/3：PASS；基于 DRAFT 定稿）
性质： 流程验证优先于「再写一本全新旅游书」——用 Search Review Team 软 Loop 跑通：草稿→核验→终稿。
访问日期： 以线程内 DRAFT/FINAL 记载为准（2026-08 窗口）

结论先行

流程结论（本单主目标）： Search → Review 软 Loop 可闭合：存在 RESEARCH_DRAFT、REVIEW_CYCLE（PASS）、RESEARCH_FINAL 定稿链路，满足「团队协作可复现」的验证意图。
内容结论（继承旅游调研）： 与 YQH-14 同主题；行程骨架仍是经典 4 日文化线，须处理周一闭馆、预约窗口、暑期天气。
政策一致性警告： YQH-14 Review 曾把故宫 72 小时核酸阴性证明确认为当时订票站现行硬性要求。本单若 FINAL 正文未同步该修正，读者不得以本单否定 YQH-14；一律以 ticket.dpm.org.cn 出行前最新页面为准（UNKNOWN / 待核实 若两单表述冲突）。

本单未预订、未支付、未修改外部系统。

背景与范围

软 Loop： 验证 Search Review Team 在真实议题上的交稿/复核节奏。
议题载体： 北京 2026-08 旅行计划（与 YQH-14 并行/相继）。
不扩大： 不替代 OTA 下单，不做签证/保险专论。

方法与证据

材料	角色
RESEARCH_DRAFT	检索与结构化行程要素
REVIEW_CYCLE	按验收标准逐条 PASS
RESEARCH_FINAL	短终稿收口
YQH-14 终稿	更完整的票务/核酸核验细节（交叉阅读）

证据分级同旅游类：官方页访问日核验 > 汇总站 > 推断。

关键发现

1. 流程侧（已核实：issue 评论结构）

存在完整 round 标记与 PASS 结论。
FINAL 体积可小于 DRAFT（收口型），细节保留在 DRAFT/兄弟 issue。
适合作为「团队模板跑通」样本，而非唯一内容权威。

2. 内容侧（与 YQH-14 对齐的稳定要点）

要点	说明
默认形态	4 天 3 夜、2 成人、中档、文化线
故宫	预约制、周一闭、官方小程序
暑期	高温 + 汛期偏多降水风险
交通	PEK/PKX 机场线 + 地铁
住	东城地铁带优先

3. 冲突处理规则

情况	处理
两单票务数字不一致	以较新官方页为准，回写时标访问日
核酸条款	YQH-14 Review 修正优先于任何未再核验的省略
八达岭票价	双方均可能故意不写死 → 出行前官网

风险与局限

FINAL 过短时，人类若只读 FINAL 会漏核酸等关键项——必须交叉 YQH-14 或 DRAFT。
软 Loop 验证成功 ≠ 旅游信息永久正确。
时效性强：2026-08 出行前需重检。

建议

把本单当流程样板归档；把 YQH-14 当内容主副本。
出行决策清单直接用 YQH-14 §可执行清单，并重开官网。
若需单一 issue 内容权威，应将 YQH-14 核酸句合并进本单 FINAL（本 v2 仅提示，不改历史评论）。

验收要点

软 Loop 闭合状态说明
与 YQH-14 关系与冲突规则
不编造预订事实
政策项标待再核实

交付说明

读者与用途： 关心 Search Review 流程是否跑通、兼读旅行结论的读者
证据分级： 已核实 · 文档声称 · 推断（见 report-generation skill）
材料访问/锁定参考日： 2026-08-09
源材料： YQH-18 RESEARCH_FINAL + DRAFT + REVIEW PASS；交叉 YQH-14
UNKNOWN / 待核实： 本单 FINAL 是否全文含核酸句（以评论原文为准）；出行日政策
标记： REPORT_DRAFT / 人类可读报告 v2（report-generation skill）

YQH-17

分布式路由「开大块」设计与切分

人类可读报告 v2（report-generation skill）

来源 issue： YQH-17 · 调研：分布式路由「开大块/大规模」如何设计与切分
来源 ID： db3b4ed6-e555-49cc-bd9e-d98a8aed74ff
原始终稿： 《YQH-17 修订终稿》（Search Leader merge Review 意见）
访问日期： 2026-08-08

结论先行

大规模路由网络不能靠「一个平面跑满全网链路状态」硬撑。工程上通过分层与切分控制三件事：控制面状态量（LSDB/RIB）、故障域半径、策略边界清晰度。

可操作的切分杠杆包括：

IGP 分层： OSPF multi-area（Area 0 骨干）、IS-IS L1/L2；必要时 Area Proxy（RFC 9666）等扩展减少 L2 拓扑细节。
地址与汇总： 层次化前缀规划 + ABR/L1-L2 汇总；错误汇总会黑洞。
BGP 作规模主轴： 以 AS/ confederation / RR / 路由策略承载跨域规模；IGP 只服务连接性。
数据中心 fabric： leaf-spine、往往 BGP-only 或 IGP+BGP 组合；避免把 DC 内部当「一个巨大 OSPF area」。
多协议/租户边界： VRF、重分发点收敛策略与环路防护。

「开大块」= 有意把拓扑/地址/策略切成可独立演进的块，并在边界定义**汇总、默认、过滤、染色（community）**契约——不是简单加路由器。

背景与范围

分布式路由在节点数、邻接数、前缀数上升时的设计与切分方法。概念基础见 YQH-15；Area Proxy 专论见 YQH-19/20/36。无具体厂商报价。

方法与证据

Search 草稿 → Review 核验 → 修订终稿。来源以 RFC 与成熟运维实践文献为主；厂商最佳实践标为文档声称。

关键发现

1. 规模压力从哪来

压力源	表现
LSDB/SPF	全网 LS 邻接与频繁 SPF
RIB/FIB	前缀与路径属性爆炸
故障传播	局部 flapping 全局震荡
运维认知	无人能理解「一张大图」
策略冲突	无边界则无法安全重分发

2. 切分检查清单（设计用）

步骤	问题
1	故障域最大可接受半径？
2	哪些前缀必须全局可见，哪些可默认路由？
3	IGP 只做 underlay 还是也承载业务前缀？
4	边界是 ABR、ASBR、PE、RR 还是路由服务器？
5	汇总点与汇总掩码是否与物理/地址拓扑一致？
6	收敛优先还是策略优先（DC vs WAN vs Internet edge）？
7	控制面实现（FRR/厂商）的 area/level 规模建议？
8	是否需要 Area Proxy 类扩展（穿越 + 隐藏内部）？

3. 模式对照（摘要）

模式	适用	风险
单一 OSPF area	小网	快速触顶
OSPF multi-area	企业/园区层次	Area 0 设计错误、次优
IS-IS L1/L2	运营商/大 IGP	L2 被内部拓扑灌满
IGP underlay + BGP overlay	DC/大规模	运维两套协议
BGP-only fabric	超大规模 DC	故障定位模型不同
Confederation/RR	AS 内 BGP 扩展	RR 成为关键故障点

4. 「开大块」反模式

为汇总而汇总，地址规划却扁平 → 黑洞。
非连续骨干 / 错误虚链路。
把 Internet 全表灌进 IGP。
无策略的双向重分发。
未定义边界所有权（谁改 metric/谁写 community）。

风险与局限

终稿为设计方法论文，不是某一生产网的审计。
具体数值上限随实现与硬件变化 → UNKNOWN，需用目标平台文档与实验室。
Review 已要求弱来源降级处，以修订终稿为准。

建议

先画三张图：物理、IGP 洪泛域、BGP 策略域——三者不对齐就是事故温床。
DC 与 WAN 用不同默认模板，勿一套 OSPF 打天下。
需要 L2 穿越又要藏内部时，评估 RFC 9666（YQH-19/20/36）。
变更窗口以边界契约（汇总/community）做回归，而不仅是 ping。

验收要点

规模压力与切分杠杆
可执行检查清单
模式/反模式对照
与 YQH-15/19 系列衔接

交付说明

读者与用途： 做大规模网络规划/重构的架构师
证据分级： 已核实 · 文档声称 · 推断（见 report-generation skill）
材料访问/锁定参考日： 2026-08-09
源材料： YQH-17 修订终稿 + Review；交叉 YQH-15/19
UNKNOWN / 待核实： 具体平台的 LSDB 上限实测；某客户现网审计
标记： REPORT_DRAFT / 人类可读报告 v2（report-generation skill）

YQH-15

分域路由是什么，如何作用到路由协议

人类可读报告 v2（report-generation skill）

来源 issue： YQH-15 · 调研：分域路由是什么，如何作用到路由协议
来源 ID： 7b671b22-2573-41d9-8d63-6c9affab3b3b
原始终稿： Search findings 草稿经 Review 确认「无实质错误，草稿即终稿」
访问日期： 2026-08-08

结论先行

分域路由把路由系统划成多个管理/拓扑/策略边界（AS、OSPF Area、IS-IS Level、VRF/重分发点等），使拓扑全量信息主要在边界内扩散，跨边界变为汇总 / 默认 / 策略选路，从而获得可扩展性、故障隔离与策略边界。

它不是「必须换一种路由协议」：OSPF multi-area 与 IS-IS multi-level 仍是同一协议族内的层次化。换协议（IGP↔BGP 重分发）是另一类边界。

背景与范围

网络工程控制面概念；无厂商 CLI 报价。大规模切分见 YQH-17；IS-IS Area Proxy 见 YQH-19/20/36。

方法与证据

一手：RFC 2328（OSPFv2）、RFC 4271（BGP-4）、RFC 1195 / ISO 10589（IS-IS）。辅助教学页已标注非 RFC。Review 核验关键主张。

关键发现

1. 「域」的常见层级

概念	语境	边界角色
AS	BGP；亦指整个 IGP 域	管理与策略主权
OSPF Area	单 AS 内；Area 0 = backbone	ABR 汇总与注入
IS-IS L1/L2	routing domain 两级	L1 区内；L2 骨干
多协议边界	IGP↔BGP、VRF	ASBR / PE

2. 与算法族的关系

算法族	域内	跨域/分层后
链路状态	洪泛拓扑 + SPF	多为汇总可达性
距离向量	邻接向量	分域偏管理边界
路径向量	—	BGP 以 AS 为节点

业界常概括：OSPF area 内严格 LS；区间更像距离向量式汇总（Type-3/4/5 语义）——与 RFC 2328 分层一致，细节以 RFC 为准。

3. OSPF（RFC 2328）

Type-1/2 仅 area 内；每 area 独立 LSDB/SPF。
非骨干 area 一般经 ABR 连 Area 0（或虚链路）。
ABR Type-3 汇总区间前缀；Type-4 指 ASBR；Type-5 外部（受 stub/NSSA 等约束）。
路径偏好：intra > inter > external。
汇总得当可缩小远端震荡；错误汇总可黑洞。

4. BGP（RFC 4271）

AS 是策略实体；eBGP 为域间边界。
AS_PATH 防环；LOCAL_PREF/MED/community 等决定安装路径。
iBGP/RR 是 AS 内扩展，不是新的 AS。
FIB 装的是策略最优，不一定是最短 IGP。

5. IS-IS Level

L1 只知本 area；出区经 L1/L2。
L2 为区间骨干；无强制「Area 0」编号但 L2 起骨干作用。
与 OSPF 同属 LS+层次，表达不同。

6. 五个常见误区

分域 ≠ 必须换协议。
Area ≠ AS。
OSPF 并非所有 area 平等（Area 0 特殊）。
区间通常不是完整链路状态。
BGP AS_PATH 最短 ≠ 业务最优。

7. 轻量类比（非等价）

可用 Multica 的「边界协调 / 信息按角色过滤」帮助记忆分层，但禁止声称 Multica 实现了 OSPF 或任何路由协议。

风险与局限

错误分域 → 次优、黑洞、区间环。
教学 LSA 表不能替代 RFC 细节与厂商扩展。
Type-5 等边界情况以 RFC 与 area 类型为准。

建议

学概念：本报告 + RFC 目录阅读。
做设计：YQH-17 checklist。
配置前画清：洪泛域、汇总点、策略点。
需要「穿越且隐藏内部」时读 Area Proxy 系列。

验收要点

定义清晰
OSPF/BGP/IS-IS 机制对照
误区列表
Review 通过状态说明

交付说明

读者与用途： 需要建立分域路由概念的工程师（非专科亦可）
证据分级： 已核实 · 文档声称 · 推断（见 report-generation skill）
材料访问/锁定参考日： 2026-08-09
源材料： YQH-15 Search findings + Review；RFC 2328/4271/1195
UNKNOWN / 待核实： 具体厂商默认行为差异
标记： REPORT_DRAFT / 人类可读报告 v2（report-generation skill）

YQH-14

北京 2026 年 8 月旅行计划调研

人类可读报告 v2（report-generation skill）

来源 issue： YQH-14 · 北京 2026 年 8 月旅行计划调研
来源 ID： c42f082a-f1be-4790-8beb-e7049f3ed556
原始终稿： 《北京 2026 年 8 月旅行计划 · 终稿》（Search→Review→Leader）
综合日期： 2026-08-08
性质： 只读调研；未预订、未下单

结论先行

在默认 4 天 3 夜、2 名成人、中档预算、经典文化线 假设下，可执行骨架是：

天坛/前门 → 故宫（避开周一；提前 7 日 20:00 官方小程序预约）→ 长城 → 颐和园；住宿优先东城王府井/东单地铁带。须管理暑期高温与主汛期偏多降水。

Review 关键修正（2026-08-08 核验 ticket.dpm.org.cn）： 故宫参观须持有 72 小时内核酸检测阴性证明——按当时页面为现行硬性要求写入，出行前必须再查是否变更。

费用粗算（2 成人，不含机票/高铁）：合计约 ¥3,200–7,000 区间（非可下单报价）；另计核酸检测费。

背景与范围

北京 2026-08 旅行要素：天气、票务、交通、住宿、餐饮、行程、费用、清单。缺省信息用表内假设填充。

方法与证据

官方站点页面核验（故宫、颐和园、气象、机场等），访问/核验日 2026-08-08。冲突的自媒体票价不写入死。

分级	用法
已核实（访问日官方页）	故宫票价/预约/核酸文案；颐和园开放与票价；机场线票价等
文档/气候统计	常年 8 月气候、主汛期趋势
故意不写死	八达岭精确票价与「必须提前 N 天」
推断	中档住宿区域选择

关键发现

1. 默认假设

项	假设
日程	4 天 3 夜；避开周一排故宫
预算	2 人约 ¥4,000–8,000（不含城际大交通）
机场	PEK 或 PKX
风格	故宫/长城/颐和园/中轴线

2. 天气

常年 8 月：湿热，日高常见 29–32°C，午后雷雨。
2026 主汛期趋势（国家气候中心，非逐日预报）：北京降水偏多 2–5 成；华北气温偏高 1–2°C。
出行前 3–7 天看中国气象局/中国天气网；本计划不承诺某日晴雨。

3. 景点（摘要）

景点	要点
故宫	大门票 60；08:30 开/16:00 停入；周一闭；仅午门入；无当日票；D-7 20:00「故宫博物院」小程序；72h 核酸
颐和园	门票 30/联票 60；园中园周一闭；风雨停船
天坛	票价量级约 15/联票 34；以 tiantanpark.com 为准
八达岭	badaling.cn；票价/提前量/缆车出行前再核

4. 交通与住宿

PEK 机场线 25 元；PKX 至草桥普通车厢常见 35 元 量级；市内地铁起步 3 元。
长城地面交通班次不锁死。
住：二环内或 1/2/5/6/8 号线交叉；默认王府井/东单。

5. 推荐行程（方案 A）

日	安排
D1	抵京→天坛→前门/大栅栏+烤鸭
D2	故宫上午场→景山→北海或南锣
D3	早出八达岭 3–4h→返城休整
D4	颐和园联票→返程

坏天气：长城改国博等室内；故宫约满无当日票；高温压缩户外至清晨。

6. 可执行清单

锁日期，避故宫周一
D-7 20:00 官方小程序约故宫
备 72h 核酸（以官网最新为准）
长城/天坛走官网或权威渠道
OTA 订酒店；行前看预警
拒绝非官方代抢故宫票

风险与局限

核酸等政策可能再变。
非实时报价；环球等未核票价。
与 YQH-18 软 Loop 对照时，以官方最新 + 本单 Review 修正为准并再查。

建议

故宫唯一权威：官方小程序 + ticket.dpm.org.cn。
出行前逐条核对 §「仍须自行确认」项。
暑期给长城/室外留暴雨 Plan B。

验收要点

完整行程要素与假设透明
核酸硬性要求与 Review 修正可见
费用为区间非报价
来源 URL 可回溯

交付说明

读者与用途： 计划 2026 年 8 月访京的旅行者（2 成人默认）
证据分级： 已核实 · 文档声称 · 推断（见 report-generation skill）
材料访问/锁定参考日： 2026-08-09
源材料： YQH-14 终稿 + Review 官方核验；访问日 2026-08-08
UNKNOWN / 待核实： 出行日故宫核酸政策是否仍有效；八达岭当日票价与预约规则；实时酒店价
标记： REPORT_DRAFT / 人类可读报告 v2（report-generation skill）