TrendR：面向研究场景的可恢复式多智能体文献综述框架

TrendR 将传统的一次性文献综述流程改造为可恢复、可追踪、可验证的控制面系统，通过显式状态机管理研究流程，解决多轮检索、分析深度不足、断点续跑等核心痛点。

在学术研究过程中，文献综述是必不可少的基础工作。然而，传统的文献综述工具往往采用"一次性生成"的薄层提示工作流：搜索、总结、起草一气呵成。这种模式存在几个明显的缺陷：

首先，流程不可恢复。一旦运行中断，往往需要从头开始重新执行，之前的工作成果难以有效继承。其次，质量控制薄弱。生成与验证通常由同一个智能体自我评估，缺乏独立的验证机制。最后，扩展性受限。松散的中件文本依赖使得流程难以在多平台间迁移和复用。

TrendR 项目正是针对这些痛点而设计的，它试图将文献综述从一次性生成为主的模式，转变为具备治理状态、产物契约、独立验证和可恢复执行的控制化研究管道。

TrendR 的核心身份是一个可恢复的文献综述 harness（框架），而非简单的写作工具。它的设计理念可以概括为四个关键转变：

传统工作流依赖松散的中间文本，而 TrendR 采用显式状态机管理研究流程。核心路径被明确定义为：INIT → DISCOVERY → ANALYSIS → GAP_CHECK → WRITING → VERIFY → DONE。每一步都可判定、可追踪、可恢复，流程不再是"写完即止"，而是按状态推进、带回跳和受控重试。

阶段衔接基于结构化文件，而非上下文猜测。典型产物包括：

• candidates.csv：候选论文池
• matrix.csv：结构化分析矩阵
• gap_report.md：覆盖缺口与回跳依据
• review.md：综述正文
• verify.json：独立验证结果
• run_state.json：机器可读运行状态

这些文件契约让流程具备可恢复、可调试、可复验的工程边界。

TrendR 将生成与验证拆分。是否完成由 verifier 判断，不由写作智能体自我宣布。验证器聚焦三类核心检查：引用一致性（citation consistency）、主张支撑（claim support）、分类连贯性（taxonomy coherence）。因此"完成"是外部判定结果，而非生成过程附带的主观结论。

系统保留 machine-readable state 与 heartbeat，可基于 run_state 与心跳信息做恢复和观测。运行时相关逻辑隔离在 adapter 层，核心状态机不与单一平台耦合，使同一控制逻辑可跨 runtime 复用。

根据项目文档披露，TrendR 当前链路的实测上限如下：

指标	实际可达上限	理论绝对上限	限制来源
Discovery 轮数	6 轮	12 轮（×resume）	状态机硬编码
单次运行时长	~5 小时	60 小时（12 次 resume）	state timeout 累积
页面访问量	600–1000 次	~2000 次	轮数 × 源数
候选论文池	650 篇	~1000 篇	去重后收敛
实际分析论文	80 篇（Depth C）	80 篇（target_papers 卡口）	CLI 配置值

当前链路存在三个关键断点：

1. 分析能力远小于收集能力：采集上限 650 篇，分析上限仅 80 篇，差距达 8 倍；score 3–4 的约 500 篇直接丢弃，缺乏二级索引。

2. Depth C 轮数冲突：cli.py 允许 --max-rounds 10，但 state_machine.py 硬编码上限为 6，导致 10 轮设计无法触达。

3. Zotero 集成尚为 Stub：references.bib 已生成但需手动导入；paper-pool.csv 跨项目索引存在但无可视化；论文"库"有了，但节点间关系网络（共引、主题聚类）尚未建立。