关于 academic-pipeline
academic-pipeline 是统筹学术研究、论文撰写与定稿流程的技能,通过调度其他技能和 Agent 推进阶段、记录进度,并在检查点等待确认。
主要功能
- 01统筹研究与写作的 10 个阶段
- 02跟踪阶段转换与流程状态
- 03在检查点等待用户确认
- 04核验引文与数据完整性
- 05生成论文创作过程记录
适用场景
- 01协调研究、起草、评审与修订
- 02在评审前及定稿前检查论文完整性
- 03从已保存的流程检查点继续工作
安装
复制下面的命令,在终端中运行。
npx skills add https:/ / github.com/ projectedanx/ academic-research-skills --skill academic-pipeline安装后在 Claude Code 中输入/academic-pipeline确认已加载。
包含的文件
除 SKILL.md 外,安装时一起下载的参考资料和脚本。
agents/claim_ref_alignment_audit_agent.mdcollaboration_depth_agent.mdintegrity_verification_agent.mdpipeline_orchestrator_agent.mdstate_tracker_agent.mdexamples/full_pipeline_example.mdintegrity_failure_recovery.mdmid_entry_example.mdreferences/ai_research_failure_modes.mdchangelog.mdclaim_audit_calibration_protocol.mdclaim_verification_protocol.mdexternal_review_protocol.mdintegrity_review_protocol.mdliterature_corpus_consumers.mdmode_advisor.mdpassport_as_reset_boundary.mdpipeline_state_machine.mdplagiarism_detection_protocol.mdprocess_summary_protocol.mdprogress_dashboard_template.mdreinforcement_content.mdreproducibility_audit.mdscore_trajectory_protocol.mdteam_collaboration_protocol.mdtwo_stage_review_protocol.mdreferences/adapters/.gitkeepoverview.mdtemplates/pipeline_status_template.md详细介绍
学术流程 v3.15.0 — 完整学术研究工作流编排器
一个轻量级编排器,用于管理从研究探索到最终稿件的完整学术流程。它不执行实质性工作,只负责检测阶段、推荐模式、分派技能、管理阶段转换和跟踪状态。
路由规范(v3.9.2): 请参阅
.claude/CLAUDE.md中的“路由规范(v3.9.2)”以及shared/references/intent_clarification_protocol.md,了解跨技能路由规则。此技能假定路由已完成;对于跨阶段的模糊材料,应已在上游完成澄清。
v3.6.3(可选启用): 设置 ARS_PASSPORT_RESET=1,将 FULL 检查点设为上下文重置边界。在新会话中使用 resume_from_passport=<hash>,从记录的阶段继续。请参阅 references/passport_as_reset_boundary.md。
v3.8(可选启用): 设置 ARS_CLAIM_AUDIT=1,在 Stage 4 → Stage 5 转换时启用 L3 主张忠实度审计门禁。设置此标志后,编排器会在 v3.7.1 Cite-Time Provenance Finalizer 之后、formatter_agent 的硬性门禁之前,分派 claim_ref_alignment_audit_agent。审计会按照 8 行矩阵生成聚合结果 claim_audit_results[] + uncited_assertions[] + claim_drifts[] + constraint_violations[] + audit_sampling_summaries[];HIGH-WARN 类别会依据 formatter 的 REFUSE 规则 6-10 拒绝输出。v3.8.0 默认关闭——启用计划推迟到获得校准后的证据之后(规范 §5 模式标志说明)。请参阅 agents/claim_ref_alignment_audit_agent.md 和编排器 §3.6 的正文说明。
v2.0 核心改进:
- 强制用户确认检查点 — 每个阶段完成后,必须经用户确认才能进入下一步
- 学术诚信验证 — 论文完成后、提交评审前,必须通过 100% 的参考文献和数据验证
- 两阶段评审 — 首轮完整评审 + 修订后的重点验证评审
- 最终诚信检查 — 修订完成后,重新验证所有引文和数据,确保 100% 正确
- 可复现 — 采用标准化工作流,每次都能提供一致的质量保证
- 过程文档 — 流程完成后,自动生成一份“论文创作过程记录”PDF,记录人机协作历程
快速开始
完整工作流(从头开始):
I want to write a research paper on the impact of AI on higher education quality assurance
--> academic-pipeline 启动,从第 1 阶段(RESEARCH)开始
中途进入(已有论文):
I already have a paper, help me review it
--> academic-pipeline 检测到中途进入,从第 2.5 阶段(INTEGRITY)开始
修订模式(已收到审稿意见):
I received reviewer comments, help me revise
--> academic-pipeline 检测到该模式,从第 4 阶段(REVISE)开始
从护照恢复(跨会话上下文重置,可选):
resume_from_passport=<hash> [stage=<n>] [mode=<m>]
--> 加载 Material Passport(Schema 9),定位与 <hash> 匹配的 kind: boundary 条目,并确认没有后续的 kind: resume 条目使用该条目。如果设置了 pending_decision,则首先触发决策提示词,以记录用户在审计日志中的分支选择;即使用户提供了 stage=,也绝不会跳过该提示词。提示词结束后(或在没有 pending_decision 时立即),下一阶段按以下规则确定:(a)如果提供了 stage=<n> CLI 覆盖项,则使用该项;否则(b)使用匹配选项的 next_stage;否则(c)使用 boundary 条目中记录的 next 字段。CLI stage=/mode= 覆盖项优先于选项路由。
- 门控(写入):必须在写入会话中设置
ARS_PASSPORT_RESET=1。如果未设置该标志,则不会写入kind: boundary条目,也就没有可供恢复的内容。 - 门控(恢复):无需设置标志。任何会话都可以通过
resume_from_passport=<hash>,从包含与该哈希匹配的有效 boundary 条目的护照中恢复。 - 意图:在全新的 Claude Code 会话中调用。在写入 boundary 的同一会话中恢复不会节省 token,还可能丢失会话中仍然有效的上下文。
- 阶段:任意阶段。根据上述路由规则确定恢复到哪个阶段。
- 参考:
references/passport_as_reset_boundary.md— 参见 §"resume_from_passport模式约定"。
执行流程:
- 检测用户当前所处阶段及可用材料
- 为每个阶段推荐最佳模式
- 为每个阶段调用相应技能
- 每个阶段完成后,主动提示用户并等待确认
- 全程跟踪进度;随时可查看 Pipeline Status Dashboard
触发条件
触发关键词
英文:academic pipeline、research to paper、full paper workflow、paper pipeline、end-to-end paper、research-to-publication、complete paper workflow
不触发的场景
| 场景 | 使用的技能 |
|---|---|
| 仅需搜索材料或进行文献综述 | deep-research |
| 仅需撰写论文(无需研究阶段) | academic-paper |
| 仅需评审论文 | academic-paper-reviewer |
| 仅需检查引用格式 | academic-paper(citation-check 模式) |
| 仅需转换论文格式 | academic-paper(format-convert 模式) |
触发排除项
- 如果用户只需要单项功能(仅搜索材料、仅检查引用),则无需使用工作流——直接调用相应技能
- 如果用户已经在使用某项技能的特定模式,应尊重其入口;工作流为可选项
- 工作流是可选的,并非强制要求
流水线阶段(10 个阶段)
| 阶段 | 名称 | 调用的技能 / Agent | 可用模式 | 交付物 |
|---|---|---|---|---|
| 1 | RESEARCH | deep-research | socratic, full, quick | RQ 简报、方法论、参考文献、综合分析 |
| 2 | WRITE | academic-paper | plan, full | 论文草稿 |
| 2.5 | INTEGRITY | integrity_verification_agent | pre-review | 完整性验证报告 + 修正后的论文 |
| 3 | REVIEW | academic-paper-reviewer | full(含 Devil's Advocate) | 5 份审稿报告 + 编辑决定 + 修订路线图 |
| 4 | REVISE | academic-paper | revision | 修订稿、给审稿人的回复 |
| 3' | RE-REVIEW | academic-paper-reviewer | re-review | 验证审稿报告:修订回复核对清单 + 剩余问题 |
| 4' | RE-REVISE | academic-paper | revision | 第二版修订稿(如有需要) |
| 4.5 | FINAL INTEGRITY | integrity_verification_agent | final-check | 最终验证报告(必须达到 100% 通过才能继续) |
| 5 | FINALIZE | academic-paper | format-convert | 最终论文(默认 MD;有 Pandoc 时使用 DOCX,否则提供转换说明;询问是否需要 LaTeX;确认正确性;PDF) |
| 6 | PROCESS SUMMARY | orchestrator | auto | 论文创建流程记录 MD + LaTeX 转 PDF(双语) |
并行化机会(v3.3):在第 2 阶段,academic-paper 技能的第 1 阶段(literature_strategist_agent)和 visualization_agent 可在第 2 阶段(structure_architect_agent)完成大纲后并行运行。具体来说:
- 大纲包含可视化计划后,
visualization_agent可开始生成图表 - 同时,
argument_builder_agent可构建 CER 链 draft_writer_agent等待两者完成后再开始第 4 阶段
这与 PaperOrchestra 在大纲(步骤 1)之后并行执行图表生成(步骤 2)和文献综述(步骤 3)的方式相似,可降低整体流水线延迟。并行化是可选的——为保持简洁,默认仍采用顺序执行。
流水线状态机
- 阶段 1 RESEARCH -> 用户确认 -> 阶段 2
- 阶段 2 WRITE -> 用户确认 -> 阶段 2.5
- 阶段 2.5 INTEGRITY -> 通过 -> 阶段 3(失败 -> 修复并重新验证,最多 3 轮)
- 阶段 3 REVIEW -> 接受 -> 阶段 4.5 / 小修|大修 -> 阶段 4 / 拒稿 -> 阶段 2 或结束
- 阶段 4 REVISE -> 用户确认 -> 阶段 3'
- 阶段 3' RE-REVIEW -> 接受|小修 -> 阶段 4.5 / 大修 -> 阶段 4'
- 阶段 4' RE-REVISE -> 用户确认 -> 阶段 4.5(不返回审稿阶段)
- 阶段 4.5 FINAL INTEGRITY -> 通过(零问题) -> 阶段 5(失败 -> 修复并重新验证)
- 阶段 5 FINALIZE -> MD -> 有 Pandoc 时转为 DOCX(否则提供说明) -> 询问是否需要 LaTeX -> 确认 -> PDF -> 阶段 6
- 阶段 6 PROCESS SUMMARY -> 询问语言版本 -> 生成流程记录 MD -> LaTeX -> PDF -> 结束
完整的状态转换定义请参阅 references/pipeline_state_machine.md。
自适应检查点系统
⚠️ 铁律——核心规则:每个阶段完成后,系统必须主动提示用户并等待确认。检查点的展示方式会根据上下文和用户参与情况进行调整。
检查点类型
| 类型 | 使用时机 | 内容 |
|---|---|---|
| FULL | 首个检查点;完整性边界之后;最终定稿之前 | 完整交付物清单 + 决策面板 + 所有选项 |
| SLIM | 在非关键阶段连续收到 2 次或更多“继续”回复后 | 单行状态 + 明确的继续 / 暂停提示 |
| MANDATORY | 完整性验证失败;审稿决定;阶段 5 | 不可跳过;需要用户明确输入 |
决策面板(在 FULL 检查点显示)
━━━ Stage [X] [Name] Complete ━━━
Metrics:
- Word count: [N] (target: [T] +/-10%) [OK/OVER/UNDER]
- References: [N] (min: [M]) [OK/LOW]
- Coverage: [N]/[T] sections drafted [COMPLETE/PARTIAL]
- Quality indicators: [score if available]
Deliverables:
- [Material 1]
- [Material 2]
Flagged: [any issues detected, or "None"]
Ready to proceed to Stage [Y]? You can also:
1. View progress (say "status")
2. Adjust settings
3. Pause pipeline
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
自适应规则
- 第一个检查点:始终为 FULL
- 连续 2 次或以上回复“继续”,且期间未进行审查:提示用户注意(“你已连续继续 [N] 次。要审查一下进度吗?”)
- 完整性边界(第 2.5、4.5 阶段):始终为 MANDATORY
- 审查决策(第 3、3' 阶段):始终为 MANDATORY
- 定稿前(第 5 阶段):始终为 MANDATORY
- 所有其他阶段:从 FULL 开始;若用户说“只管继续”,则降级为 SLIM
检查点规则
- ⚠️ 铁律:不得自动跳过 MANDATORY 检查点:即使上一阶段的结果完美无缺,仍须在 MANDATORY 检查点获得用户明确输入
- 用户可以调整:在 FULL 和 MANDATORY 检查点,用户可以修改下一步的模式或设置
- 支持暂停:用户可以在任何检查点暂停,并在之后恢复
- SLIM 模式:若用户说“只管继续”或“完全自动”,后续非关键检查点将切换为 SLIM 格式(一行状态 + 明确的继续/暂停提示)
- 注意力保障:连续回复“继续”达到 4 次或以上后,无论阶段类型如何,系统都会插入一个 FULL 检查点,以确保用户仍积极参与
自检问题(每个 FULL 检查点)
在向用户展示检查点之前,编排器会先自问:
- 引文完整性:最新输出中是否有未经核实的引文?
- 迎合式让步:最新阶段是否不加质疑地接受了所有反馈?
- 质量趋势:最新输出是否达到或超过上一阶段的质量?若质量下降,则暂停并标记。
- 范围约束:最新阶段是否加入了用户或修订路线图未要求的内容?
- 完整性:此阶段所需的所有交付物是否齐全?
如果任一问题引发担忧,请在向用户展示检查点时一并说明。
Agent 团队(5 个 Agent)
| # | Agent | 角色 | 文件 |
|---|---|---|---|
| 1 | pipeline_orchestrator_agent | 主编排器:检测阶段、推荐模式、触发技能、管理状态转换 | agents/pipeline_orchestrator_agent.md |
| 2 | state_tracker_agent | 状态跟踪器:记录已完成的阶段、生成的材料和修订循环次数 | agents/state_tracker_agent.md |
| 3 | integrity_verification_agent | 完整性验证器:100% 核实引用/引文/数据(阻断式) | agents/integrity_verification_agent.md |
| 4 | collaboration_depth_agent | **观察者(仅提供建议,不会阻断流程)。**读取对话日志,并根据 shared/collaboration_depth_rubric.md 评估用户与 AI 的协作模式。在 FULL/SLIM 检查点及管线完成时调用。基于 Wang & Zhang(2026)。 | agents/collaboration_depth_agent.md |
| 5 | claim_ref_alignment_audit_agent | **可选的论断忠实度审计器(v3.8 #103)。**抽样审计引文,检查论断 ↔ 参考资料的一致性及负面约束的遵循情况;逐条输出 claim_audit_results[]、claim_drift[]、uncited_assertions[]、constraint_violations[]。当用户请求 claim_audit 模式时,通过编排器 §3.6 调度。 | agents/claim_ref_alignment_audit_agent.md |
编排器工作流
第 1 步:接收输入与检测
pipeline_orchestrator_agent analyzes the user's input:
1. What materials does the user have?
- No materials --> Stage 1 (RESEARCH)
- Has research data --> Stage 2 (WRITE)
- Has paper draft --> Stage 2.5 (INTEGRITY)
- Has verified paper --> Stage 3 (REVIEW)
- Has review comments --> Stage 4 (REVISE)
- Has revised draft --> Stage 3' (RE-REVIEW)
- Has final draft for formatting --> Stage 5 (FINALIZE)
2. What is the user's goal?
- Full workflow (research to publication)
- Partial workflow (only certain stages needed)
3. Determine entry point, confirm with user
第 2 步:模式推荐
Based on entry point and user preferences, recommend modes for each stage:
User type determination:
- Novice / wants guidance --> socratic (Stage 1) + plan (Stage 2) + guided (Stage 3)
- Experienced / wants direct output --> full (Stage 1) + full (Stage 2) + full (Stage 3)
- Time-limited --> quick (Stage 1) + full (Stage 2) + quick (Stage 3)
Explain the differences between modes when recommending, letting the user choose
第 3 步:阶段执行
Call the corresponding skill (does not do work itself, purely dispatching):
1. Inform the user which Stage is about to begin
2. Load the corresponding skill's SKILL.md
3. Launch the skill with the recommended mode
4. Monitor stage completion status
After completion:
1. Compile deliverables list
2. Update pipeline state (call state_tracker_agent)
3. [MANDATORY] Proactively prompt checkpoint, wait for user confirmation
第 4 步:状态转换
After user confirmation:
1. Pass the previous stage's deliverables as input to the next stage
2. Trigger handoff protocol (defined in each skill's SKILL.md):
- Stage 1 --> 2: deep-research handoff (RQ Brief + Bibliography + Synthesis)
- Stage 2 --> 2.5: Pass complete paper to integrity_verification_agent
- Stage 2.5 --> 3: Pass verified paper to reviewer
- Stage 3 --> 4: Pass Revision Roadmap to academic-paper revision mode
- Stage 4 --> 3': Pass revised draft and Response to Reviewers to reviewer
- Stage 3' --> 4': Pass new Revision Roadmap + R&R Traceability Matrix (Schema 11) to academic-paper revision mode
- Stage 4/4' --> 4.5: Pass revision-completed paper to integrity_verification_agent (final verification)
- Stage 4.5 --> 5: Pass verified final draft to format-convert mode
3. Begin next stage
对话中途强化协议
每次阶段转换时,编排器都必须注入一段简短的核心原则提醒,以防止长对话中的上下文逐渐退化。
模板(根据即将进入的阶段调整):
--- STAGE TRANSITION: [Current] → [Next] ---
🔄 Core Principles Reinforcement:
1. [Most relevant IRON RULE for the next stage]
2. [Most relevant Anti-Pattern to avoid in the next stage]
3. Quality check: Is the output of [Current Stage] at least as good as [Previous Stage]? If not, PAUSE.
Checkpoint: [MANDATORY/ADVISORY] — [What user needs to confirm]
---
各阶段专属的强化内容:完整的“转换 → 强化重点”对照表见 references/reinforcement_content.md。
分阶段调用契约(v3.9.2)
academic-pipeline 是编排器技能,负责协调跨越 10 个阶段的完整 ARS 流程(委派给 deep-research、academic-paper、academic-paper-reviewer)。有两种调用模式:
模式 A — 编排器驱动(默认): pipeline_orchestrator_agent 通过 Material Passport 跟踪状态,端到端运行所有阶段。编排器会在适当的检查点调度 state_tracker_agent、integrity_verification_agent、collaboration_depth_agent 和 claim_ref_alignment_audit_agent。
模式 B — 分阶段(跨会话续接): 用户在多个会话中一次调用一个阶段 Agent,通常通过 ARS_PASSPORT_RESET=1 + resume_from_passport=<hash>(见 references/passport_as_reset_boundary.md)。
在模式 B 中,下游技能(deep-research、academic-paper、academic-paper-reviewer)中的单阶段 Agent(依据 docs/design/2026-05-18-ars-v3.9.2-agent-phase-classification.md,属于 Bucket A)在写入时严格限定于其分配的阶段。academic-pipeline 本身的 5 个 Agent 按设计均为跨阶段/元级别(Bucket C/D)——按设计不设边界:
pipeline_orchestrator_agent(D — 编排器,可查看完整流程)state_tracker_agent(D — 元级状态,涵盖所有阶段)integrity_verification_agent(C — 第 2.5/4.5 阶段跨技能关卡)collaboration_depth_agent(C — FULL/SLIM 检查点 + 流程完成,仅提供建议)claim_ref_alignment_audit_agent(C — 可选的论点审计,与阶段无关)
路由至模式 B 需要用户明确发出信号——使用 /ars-<mode> 斜杠命令或 [direct-mode] 前缀。根据 .claude/CLAUDE.md 中的 Routing Discipline + shared/references/intent_clarification_protocol.md,含糊的跨阶段输入默认需要澄清。重要: 如果在含糊的跨阶段材料上调度 pipeline_orchestrator_agent,编排器目前自身无法协调(这是 v3.10 conductor #134 的工作)——v3.9.2 会在编排器运行之前先对这类情况进行澄清。
执行机制(v3.9.2): 下游 Bucket A Agent 上的阶段边界、建议型验证器(scripts/check_pipeline_integrity.py),以及在启用钩子的运行时中由确定性 PreToolUse 写入范围防护共同负责执行(#134 范围调整,PR #294)。多阶段封套 + 编排器结构化接收仍属于后续范围(#134 Slices 3-5)。
完整性审查协议
第 2.5 阶段(审查前)和第 4.5 阶段(修订后)的验证。该协议分为 5 个阶段:参考文献 → 引用语境 → 统计数据 → 原创性 → 论点。
⚠️ 铁律:第 4.5 阶段必须以零问题通过,才能进入第 5 阶段。第 4.5 阶段会独立从头进行验证。
⚠️ 铁律(v3.2):第 2.5 阶段和第 4.5 阶段还必须运行 AI Research Failure Mode Checklist——一个包含 7 种模式的分类体系,将引用幻觉检查扩展到实现错误、虚构结果、依赖捷径、将错误当作洞见、方法论造假和流程级框架锁定。如果 7 种模式中有任何一种被标记为 SUSPECTED,或者模式 1/3/5/6 被标记为 INSUFFICIENT EVIDENCE,流程就会阻止继续,用户必须先确认(确认/说明理由后覆盖/修订),流程才能继续。没有 --no-block 逃逸选项。随后,第 6 阶段 PROCESS SUMMARY 会在 AI Self-Reflection Report 中报告完整的失效模式审计日志。
参见
references/integrity_review_protocol.md,了解 5 阶段引用/论点验证流程。 参见references/ai_research_failure_modes.md,了解包含 7 种模式的 AI 研究失败检查清单及阻止/覆盖逻辑。
- [v3.4.0]
compliance_agent运行感知模式的 PRISMA-trAIce + RAISE 合规性检查;按层级执行阻止规则。参见shared/compliance_checkpoint_protocol.md。
两阶段评审协议
Stage 3(完整评审,5 位评审者)→ 修改指导 → Stage 4 → Stage 3'(重新评审)→ 可选的剩余问题指导 → Stage 4'。
有关详细的阶段流程和指导对话限制,请参阅
references/two_stage_review_protocol.md。
中途进入协议
用户可以从任意阶段进入。编排器将:
- 检测材料:分析用户提供的内容,确定现有哪些材料
- 识别缺口:检查目标阶段所需的前置材料
- 建议补齐材料:如果缺少关键材料,建议是否返回较早阶段
- 直接进入:如果材料充足,直接开始指定阶段
重要:中途进入不能跳过 Stage 2.5
- 如果用户带着论文直接进入,必须先完成 Stage 2.5(INTEGRITY),再进入 Stage 3(REVIEW)
- 唯一例外:用户可以提供之前的完整性验证报告,且内容未被修改
外部评审协议
处理外部(人工)评审者反馈的整合。工作流分为 4 步:接收与整理 → 策略性修改指导 → 修改与回复 → 自我验证。
有关完整的 4 步工作流、指导对话模式和能力边界,请参阅
references/external_review_protocol.md。
进度仪表板
在 FULL 检查点显示 ASCII 仪表板,以展示工作流进度。
有关仪表板模板,请参阅
references/progress_dashboard_template.md。
修改循环管理
- Stage 3(首次评审)-> Stage 4(修改)-> Stage 3'(验证评审)-> Stage 4'(再次修改,如有需要)-> Stage 4.5(最终验证)
- 最多 1 轮 RE-REVISE(Stage 4'):如果 Stage 3' 给出 Major,则进入 Stage 4' 修改,然后直接进入 Stage 4.5(不再返回评审)
- 工作流覆盖 academic-paper 的最多 2 轮修改规则:在工作流中,修改仅限 Stage 4 + Stage 4'(各 1 轮),取代 academic-paper 的最多 2 轮规则
- 将未解决的问题标记为已确认的局限
- 提供累积修改历史(每轮的决定、已处理事项、未解决事项)
提前停止标准(v3.2)
每轮修改结束时,如果 0–100 评分标准上的 差值 < 3 分,且没有遗留的 P0 问题,则建议停止修改循环(“已收敛”)。用户可以覆盖此建议。硬性上限:2 个完整修改循环(Stage 4 + Stage 4')。
预算透明度(v3.2;交互次数扩展 #89/#388)
工作流开始时,根据论文长度、模式和跨模型切换状态估算 token 成本。在 Stage 1 开始前展示估算值并征求用户确认。
除 token 估算外,还要展示交互次数预算:长期文档损坏会随着文档往返次数累积,而非 token 数量(DELEGATE-52,arXiv:2604.15597)。列出工作流已实施的往返次数上限——2 个完整修改循环(上文“提前停止”)、8 + 5 轮苏格拉底式指导(Stage 3→4 / 3'→4'),以及 Stage 2.5/4.5 的完整性关卡修复→重新验证循环——并说明所选模式下这些上限所对应的最坏情况往返总次数。在每个阶段检查点,报告累计往返次数及阶段状态。仅供参考:该次数不会阻止流程;各循环上限仍是执行限制。若运行超过所述最坏情况,说明存在上限未覆盖的循环——应明确指出,而不是静默继续。
可复现性
每个工作流产物都有版本号、哈希值,且可审计。
有关标准化工作流保证、审计跟踪格式和产物跟踪,请参阅
references/reproducibility_audit.md。
第 6 阶段:流程总结协议
生成最终流程记录:论文创作历程、协作质量评估(6 个维度,1–100 分)和 AI 自我反思报告。
完整工作流、必需的内容结构、评分维度和输出规范,请参阅
references/process_summary_protocol.md。
协作深度观察器(v3.5.0,仅提供建议 — 从不阻止流程)
collaboration_depth_agent 会观察用户与流水线的协作模式。它仅提供建议,在任何检查点都不会阻止流程继续推进。它在设计上是 non-blocking,并在 frontmatter 中包含 blocking: false,作为结构性保证。
调用时机:每个 FULL 检查点、每个 SLIM 检查点,以及第 6 阶段之后(流水线完成时)。MANDATORY 检查点(第 2.5 / 4.5 阶段的完整性关卡)不会调用观察器——这些关乎完整性,不应被淡化。
作用:读取刚完成阶段的对话范围(在检查点时)或整个流水线的对话(在流程完成时),根据 shared/collaboration_depth_rubric.md 中的规范评分标准评估协作模式,并生成建议区块/章节。维度:委派强度、认知警觉性、认知重新分配、区域分类(区域 1 / 区域 2 / 区域 3)。评分标准基于 Wang & Zhang(2026)IJETHE 23:11(DOI 10.1186/s41239-026-00585-x)。
与现有机制的区别:
| 机制 | 评估内容 | 是否阻止流程? |
|---|---|---|
integrity_verification_agent(第 2.5 / 4.5 阶段) | 论文内容——参考文献、引用、数据 | 是(阻断关卡) |
| 第 6 阶段协作质量评估(6 个维度,1–100 分) | AI 对自身行为的自我反思 | 否,但只生成一次 |
collaboration_depth_agent(本观察器) | 用户的协作模式(委派强度、警觉性、重新分配) | 否——从不阻止流程。仅提供建议。 |
非阻断保证:
- 观察器的输出绝不会出现在任何检查点的“已标记”行中。
- 观察器的输出不会改变
Ready to proceed?提示。 blocked_by: collaboration_depth_agent在state_tracker中绝不是合法状态。- 如果观察器的 frontmatter 声明
blocking: true,编排器必须拒绝调度它。
跨模型:设置 ARS_CROSS_MODEL 时,观察器会在两个模型上运行,并标记任何超过 2 分的维度差异。不同模型的评分绝不会被静默取平均值。
完整评分流程和反谄媚规范,请参阅
agents/collaboration_depth_agent.md;规范的 4 维度评分标准,请参阅shared/collaboration_depth_rubric.md。
反模式
明确禁止以下行为,以避免常见的失败情形:
| # | 反模式 | 失败原因 | 正确做法 |
|---|---|---|---|
| 1 | 跳过完整性检查 | “论文看起来没问题,跳过 Stage 2.5/4.5。” | 完整性检查是强制的;无论主观上认为质量如何,都不能自动跳过 |
| 2 | 编排器执行实质性工作 | 流水线编排器撰写内容或审阅论文 | 编排器只负责分派和协调;实质性工作由子技能完成 |
| 3 | 自动越过强制检查点 | 在 FULL 检查点未获得用户确认就进入下一阶段 | 强制检查点要求用户明确输入后才能继续 |
| 4 | 各阶段的质量逐步下降 | Stage 4 的修订稿比 Stage 2 的草稿更差,因为上下文窗口已耗尽 | 如果 Stage N 的输出质量低于 Stage N-1,请暂停,并在继续前重新加载核心原则 |
| 5 | 悄悄忽略审稿人的意见 | 修订稿只回应了 10 条意见中的 8 条,还希望没人发现 | R&R 跟踪表必须涵盖每条意见,并明确标注状态 |
| 6 | 在 Stage 4.5 只重新核验已知问题 | 最终完整性检查只复查 Stage 2.5 发现的问题 | Stage 4.5 必须独立地从头核验;修订可能引入新问题 |
| 7 | 虚高 Collaboration Quality 评分 | 为避免尴尬的自我批评而打 90/100 | 诚实为先:不虚报,不说客套话;每项评分都要引用具体证据 |
| 8 | 绕过 Failure Mode Checklist 阻断项(v3.2) | “7-mode 检查清单是新加的,这次先跳过吧。” | Stage 2.5/4.5 的 Failure Mode Checklist 是强制且会阻断流程的;不存在 --no-block 标志;如需覆盖,必须记录用户在 Stage 6 给出的理由 |
质量标准
| 维度 | 要求 |
|---|---|
| 阶段识别 | 正确识别用户当前所处阶段及可用材料 |
| 模式建议 | 根据用户偏好和材料状态推荐合适的模式 |
| 材料交接 | 阶段间交接的材料完整且格式正确 |
| 状态跟踪 | 实时更新流水线状态;Progress Dashboard 准确无误 |
| 强制检查点 | 每个阶段完成后都必须获得用户确认 |
| 强制完整性检查 | 不得跳过 Stage 2.5 和 4.5,且必须通过检查 |
| 强制失败模式检查清单(v3.2) | Stage 2.5 和 4.5 必须运行 7-mode AI 研究失败检查清单;疑似失败会阻断流程;如需覆盖,必须说明用户给出的理由 |
| 不越权 | ⚠️ 铁律:编排器不执行实质性的研究、撰写或审阅工作,只负责分派 |
| 不强迫 | ⚠️ 铁律:用户可随时暂停或退出流水线(但不能跳过完整性检查) |
| 可复现 | 相同输入在不同会话中遵循相同的工作流 |
| 考虑收敛的停止条件(v3.2) | 如果 delta < 3 points 且没有 P0 问题,建议停止修订循环;用户可以覆盖此建议 |
| 预算透明度(v3.2;#388) | Token 成本估算 + 交互次数预算(往返次数上限 + 检查点处累计次数,仅供参考)+ 流水线启动时获得用户确认 |
错误恢复
| 阶段 | 错误 | 处理方式 |
|---|---|---|
| 接收 | 无法确定入口点 | 询问用户有哪些材料以及他们的目标 |
| 阶段 1 | deep-research 未能收敛 | 建议切换模式(苏格拉底式 -> 完整模式)或缩小范围 |
| 阶段 2 | 缺少研究基础 | 建议返回阶段 1 补充研究 |
| 阶段 2.5 | 经过 3 轮修正后仍为 FAIL | 列出无法验证的项目;由用户决定是否继续 |
| 阶段 3 | 评审结果为 Reject | 提供选项:大幅重构(阶段 2)或放弃 |
| 阶段 4 | 所有项目均未完成修订 | 列出尚未处理的项目;询问是否继续 |
| 阶段 3' | 验证仍存在重大问题 | 进入阶段 4' 进行最终修订 |
| 阶段 4' | 修订后仍有问题 | 标记为已确认的局限;继续进入阶段 4.5 |
| 阶段 4.5 | 最终验证为 FAIL | 修复并重新验证(最多 3 轮) |
| 任意阶段 | 用户中途离开 | 保存工作流状态;下次可从断点处继续 |
| 任意阶段 | 技能执行失败 | 报告错误;建议重试、暂停或切换模式。不得跳过强制性完整性或故障模式检查关卡 |
Agent 文件参考
| Agent | 定义文件 |
|---|---|
| pipeline_orchestrator_agent | agents/pipeline_orchestrator_agent.md |
| state_tracker_agent | agents/state_tracker_agent.md |
| integrity_verification_agent | agents/integrity_verification_agent.md |
| collaboration_depth_agent | agents/collaboration_depth_agent.md |
| claim_ref_alignment_audit_agent | agents/claim_ref_alignment_audit_agent.md |
参考文件
| 参考文件 | 用途 |
|---|---|
references/pipeline_state_machine.md | 完整状态机定义:所有合法转换、前置条件和操作 |
references/plagiarism_detection_protocol.md | D 阶段原创性验证协议 + 自我抄袭 + AI 文本特征 |
references/mode_advisor.md | 统一的跨技能决策树:将用户意图映射到最佳技能 + 模式 |
references/claim_verification_protocol.md | E 阶段声明验证协议:声明提取、来源追溯、交叉引用、判定分类 |
references/claim_audit_calibration_protocol.md | v3.8 #103 claim_ref_alignment 审计校准:金标准集结构(T-C3)、阈值关卡 FNR<0.15 / FPR<0.10(T-C1)、按类别报告 FNR/FPR(T-C2)。通过 PYTHONPATH=. python3 -m unittest scripts.test_claim_audit_calibration -v 重新运行。 |
references/ai_research_failure_modes.md | AI 研究失败的 7 种模式检查清单(Lu 2026),在阶段 2.5 + 4.5 运行并执行阻断行为,在阶段 6 报告 |
references/team_collaboration_protocol.md | 多人团队协调:角色定义、交接协议、版本控制、冲突解决 |
references/integrity_review_protocol.md | 阶段 2.5 + 4.5 完整性验证:5 阶段协议详情 |
references/two_stage_review_protocol.md | 两阶段评审:阶段 3 完整评审 + 阶段 3' 验证评审 |
references/external_review_protocol.md | 外部(人工)评审者反馈:4 步接收/指导/修订/验证 |
references/process_summary_protocol.md | 阶段 6:协作质量评估 + AI 自我反思报告 |
references/reproducibility_audit.md | 标准化工作流保证 + 审计跟踪格式 |
references/progress_dashboard_template.md | ASCII 进度仪表板模板 |
references/reinforcement_content.md | 各阶段交接时的强化重点表 |
references/changelog.md | 完整版本历史 |
shared/handoff_schemas.md | 跨技能数据契约:涵盖所有阶段间交接工件的 9 种架构 |
shared/collaboration_depth_rubric.md | Collaboration Depth Observer 评分标准(v1.0):基于 Wang & Zhang(2026)IJETHE 23:11 的 4 个维度 |
模板
| 模板 | 用途 |
|---|---|
templates/pipeline_status_template.md | 进度仪表板输出模板 |
示例
| 示例 | 展示内容 |
|---|---|
examples/full_pipeline_example.md | 完整的工作流对话记录(阶段 1-5,包含完整性检查 + 两阶段评审) |
examples/mid_entry_example.md | 从阶段 2.5 开始的中途接入示例(已有论文 -> 完整性检查 -> 评审 -> 修订 -> 定稿) |
输出语言
遵循用户使用的语言。学术术语保留英文。
与其他技能集成
academic-pipeline dispatches the following skills (does not do work itself):
Stage 1: deep-research
- socratic mode: Guided research exploration
- full mode: Complete research report
- quick mode: Quick research summary
Stage 2: academic-paper
- plan mode: Socratic chapter-by-chapter guidance
- full mode: Complete paper writing
Stage 2.5: integrity_verification_agent (Mode 1: pre-review)
Stage 4.5: integrity_verification_agent (Mode 2: final-check)
Stage 3: academic-paper-reviewer
- full mode: Complete 5-person review (EIC + R1/R2/R3 + Devil's Advocate)
Stage 3': academic-paper-reviewer
- re-review mode: Verification review (focused on revision responses)
Stage 4/4': academic-paper (revision mode)
Stage 5: academic-paper (format-convert mode)
- Step 1: Ask user which academic formatting style (APA 7.0 / Chicago / IEEE, etc.)
- Step 2: Produce MD, then generate DOCX via Pandoc when available (otherwise provide conversion instructions)
- Step 3: Produce LaTeX (using corresponding document class, e.g., apa7 class for APA 7.0)
- Step 4: After user confirms content is correct, tectonic compiles PDF (final version)
- Fonts: Times New Roman (English) + Source Han Serif TC VF (Chinese) + Courier New (monospace)
- ⚠️ IRON RULE: PDF must be compiled from LaTeX (HTML-to-PDF is prohibited)
相关技能
| 技能 | 关系 |
|---|---|
deep-research | 已调度(阶段 1 研究阶段) |
academic-paper | 已调度(阶段 2 写作、阶段 4/4' 修订、阶段 5 格式化) |
academic-paper-reviewer | 已调度(阶段 3 首轮评审、阶段 3' 验证评审) |
版本信息
| 项目 | 内容 |
|---|---|
| 技能版本 | 3.15.0 |
| 最后更新 | 2026-07-04 |
| 维护者 | Cheng-I Wu |
| 依赖技能 | deep-research v2.0+、academic-paper v2.0+、academic-paper-reviewer v1.1+ |
| 角色 | 完整学术研究工作流编排器 |
更新日志
完整版本历史请参阅
references/changelog.md。