尧图网站建设 
InnoCore AI 功能全景解析基于 HelloAgent 的多智能体科研助手特性与实战指南【免费下载链接】hello-agents 《从零开始构建智能体》——从零开始的智能体原理与实践教程项目地址: https://gitcode.com/datawhalechina/hello-agents导读InnoCore AI研创·智核是构建于 HelloAgent 多智能体框架之上的一套智能科研创新助手以四大分工明确的智能体Hunter/Miner/Coach/Validator协同完成论文搜索、深度分析、写作辅助与引用校验的科研全流程。本文以该项目官方《功能清单》FEATURES.md为骨架逐项对照 agents/ 与 api/routes/ 下的真实源码带读者理解每一项功能在代码层的实现方式、可配置参数与调用入口最终掌握双工作模式、七大 API 端点组以及本地部署与验证的完整方法。一、项目定位与功能总览1.1 功能清单的整体结构FEATURES.md 从六个维度组织项目能力维度覆盖内容工作模式单独模式、协调模式完整工作流智能体功能Hunter 论文搜索、Miner 论文分析、Validator 引用校验、Coach 写作助手工作流功能完整工作流、简化工作流搜索分析前端功能响应式界面、模式切换、拖拽上传、Markdown 渲染、一键复制API 端点论文、分析、写作、引用、工作流五大类共 7 个 POST 端点测试与文档README、USAGE_GUIDE、FEATURES、WORKFLOW_GUIDE 四类文档1.2 四大智能体的协作分工从 agents/controller.py 可以看到控制器AgentController在初始化时统一实例化了四个智能体构成系统的智能体编排层self.agents { hunter: HunterAgent(), miner: MinerAgent(), coach: CoachAgent(), validator: ValidatorAgent() }每个智能体都继承自 agents/base.py 的BaseAgent抽象类具备统一的max_steps最大步骤数默认 5、timeout超时秒数默认 300、state状态机idle/running/completed/error、history对话历史与工具注册表tools。这意味着四个智能体在调用 LLM 思考think、注册并执行工具add_tool/call_tool、校验必填输入validate_input三件事上行为一致差异只体现在各自封装的领域工具上。二、双工作模式单独模式与协调模式2.1 单独模式Individual Mode单独模式下每个智能体独立对外服务适合单一任务与精细控制。系统为每种任务都提供了直接的 REST 端点前端对应独立的操作卡片。FEATURES 中列出的单独模式能力包括独立使用每个智能体、灵活控制每个步骤、适合单一任务。以论文分析为例单独模式下可直接调用POST /api/v1/analysis/analyze传入paper_url与analysis_type由 analysis.py 单点执行全程不涉及其他智能体。2.2 协调模式Coordinated Mode⭐协调模式通过 AgentController 的_execute_full_workflow方法实现完整工作流编排将四个智能体串联为一条流水线Stage 1 论文抓取调用HunterAgent.run()输入keywords、max_papers默认 10、sources默认[arxiv]Stage 2 论文分析遍历已下载论文逐篇调用MinerAgent.run()生成分析报告Stage 3 引用校验可选通过validate_citations开关控制逐篇调用ValidatorAgent.run()生成 BibTeX/APA 引用Stage 4 报告整合将各阶段结果汇总到workflow_result输出stages、final_papers、analysis_reports。协调模式的核心支撑是任务管理机制。从 controller.py 可以看到控制器内置了active_tasks/task_history活动任务与历史任务字典task_queue异步优先队列asyncio.Queue配合start_task_processor()消费semaphore信号量并发控制上限取config.concurrent_agents默认 4event_callbackstask_started/task_completed/task_failed/agent_status_changed四类事件回调。任务生命周期由TaskStatus枚举完整覆盖PENDING → RUNNING → COMPLETED / FAILED / CANCELLED任何异常都会写入task[error]并触发task_failed事件即 FEATURES 中步骤状态跟踪 错误处理的代码实现。三、Hunter论文搜索智能体3.1 核心能力清单FEATURES 声明的 Hunter 能力为ArXiv 实时搜索、关键词搜索、结果数量控制、论文信息提取。对应 agents/hunter.py 注册的四个工具工具名底层方法说明search_arxiv_search_arxiv按关键词搜索 ArXivsearch_ieee_search_ieee按关键词搜索 IEEE需配置 API keydownload_pdf_download_pdf下载 PDF 到downloads/papers/extract_metadata_extract_metadata提取论文元数据3.2 运行参数与检索逻辑HunterAgent.run()的输入参数见 hunter.py参数默认值含义keywords必填关键词列表使用all:kw拼接为OR查询max_papers20最大返回论文数sources[arxiv, ieee]检索数据源days_back1回溯天数时间过滤ArXiv 检索使用http://export.arxiv.org/api/query端点hunter.py通过aiohttp异步请求并以feedparser解析 Atom 响应随后依次执行三层后处理去重_deduplicate_papers对论文标题取 MD5 哈希集合判重hunter.py相关性筛选_filter_papers标题命中关键词记 2 分、摘要命中记 1 分score 1才保留并按分数降序hunter.py下载入库_download_and_save_paper下载 PDF、计算 SHA-256 内容哈希并通过db_manager.create_paper写入数据库hunter.py。每条论文记录提取的字段包括id、title、authors、abstract、published、pdf_url、doi、categories——这正是论文信息提取能力的实现。3.3 IEEE 数据源的前提条件IEEE 检索需要ieee_base_url与ieee_api_key配置hunter.py若config.external_apis.ieee_base_url为空会记录IEEE API 配置缺失跳过 IEEE 搜索并直接返回空结果。API 层的实际搜索路径则默认只走 ArXiv见下文 5.1 节因此 FEATURES 中ArXiv 实时搜索是无条件可用能力而 IEEE 属于需自行配置扩展项。四、Miner论文分析智能体4.1 核心能力清单FEATURES 声明 Miner 支持ArXiv URL 分析、PDF 文件上传、PDF 自动解析、4 种分析类型摘要/创新点/对比/综合。其工具注册见 agents/miner.py工具名说明parse_pdf解析 PDF 文件search_memory搜索记忆库向量检索compare_papers对比论文generate_report生成分析报告4.2 分析流水线六步MinerAgent.run()以paper_id为必填字段miner.py内部按固定流水线执行解析 PDF 内容_parse_paper_content有本地文件时提取结构化内容否则退化为仅使用标题摘要的metadata_only模式检索相关历史论文_find_related_papers通过vector_store_manager.hybrid_search做向量 关键词混合检索top_k10同时支持include_l1预置库与include_l2用户私有库两层知识库对比分析_perform_comparison_analysis将当前论文与相似度最高的前 5 篇历史论文构造成对比 Prompt要求 LLM 从方法创新性、实验设计、与现有工作区别、研究空白四个角度以 JSON 返回结果解析失败时降级为_parse_text_comparison文本解析生成分析报告_create_analysis_report要求 LLM 按 Summary / Innovation / Limitation / Future Ideas 四段结构输出 JSON解析失败时回退到_generate_default_report保存报告_save_analysis_report调用db_manager.create_analysis_report持久化更新向量库_update_vector_store将论文内容标题摘要章节文本写入 L2 用户库供后续语义检索使用。4.3 四种分析类型的 Prompt 差异在 API 层analysis.py四种分析类型对应四套独立的中文 Prompt均基于标题作者摘要论文内容截取前 8000 字符构造摘要分析summary要求输出研究背景动机、主要方法、核心贡献、实验结果、研究意义创新点分析innovation要求输出技术创新、方法论创新、理论贡献、与现有工作区别、潜在应用价值对比分析comparison要求输出与传统方法对比、优劣势、适用场景、性能提升、局限性综合分析comprehensive要求覆盖背景意义、方法详解、创新点、实验验证、优缺点、未来方向、应用价值七个方面。4.4 输入格式识别Miner 支持三类输入analysis.pyArXiv URL如https://arxiv.org/abs/2511.16672ArXiv ID如2511.16672正则^(\d{4}\.\d{4,5})v?\d*$兜底本地 PDF上传解析后自动填充/uploads/路径。针对本地 PDF系统会先调用 utils/pdf_parser.py 解析出标题、作者、摘要与全文含页数、字数统计再用完整内容驱动 LLM 分析并对超过 8000 字符的全文做截断以规避 token 上限。五、Validator引用校验智能体5.1 核心能力清单FEATURES 声明 Validator 支持DOI 自动验证、ArXiv ID 识别、AI 辅助解析、4 种引用格式BibTeX/APA/IEEE/MLA。智能体层的工具注册见 agents/validator.pygenerate_bibtex、generate_apa、generate_ieee、verify_metadata、crossref_lookup、scholar_lookup六个工具。5.2 三级验证流水线引用校验端点POST /api/v1/citations/validatecitations.py按优先级执行三级验证ArXiv 识别正则(?:arxiv\.org/abs/|arXiv:)(\d\.\d)提取 ArXiv ID调用arxiv.Search(id_list[id])拉取真实元数据DOI 验证正则10\.\d{4,9}/[-._;()/:A-Z0-9]提取 DOI通过httpx请求https://api.crossref.org/works/{doi}10 秒超时核验标题、作者、年份、期刊、卷期页码AI 辅助解析前两级都失败时将引用原文交给 LLM要求以纯 JSON 提取 title/authors/year/journal/volume/issue/pages/doi/arxiv_id 等字段并对模型输出做代码块 JSON 或裸 JSON 的二次提取兜底。5.3 四种引用格式生成验证通过后citations.py 根据format参数默认bibtex生成四种格式作者数超过 3 人统一缩写为前3作者 et al.BibTeXarticle{key{year}, title{...}, author{...}, journal{...}, year{...}}ArXiv 论文追加eprint与archivePrefix{arXiv}DOI 论文追加doi字段APA作者 (年份). 标题. *期刊*卷(期), 页码. arXiv:xxx或https://doi.org/xxxIEEE[1] 作者, 标题, *期刊*, vol. 卷, no. 期, pp. 页码, 年份, doi: xxx.MLA作者. 标题. *期刊*, vol. 卷, no. 期, 年份, pp. 页码.智能体层validator.py还实现了更完整的格式逻辑包括 BibTeX 条目类型自动判定有journal→article、有booktitle→inproceedings、有publisher→book、否则→misc、作者姓名 First Last → Last, First 转换以及 IEEE 的作者首字母缩写规则。5.4 元数据差异校验与缓存智能体层的_verify_paper_metadatavalidator.py支持多数据源CrossRef Google Scholar/SerpApi交叉比对产出discrepancies标题/作者/年份差异列表含 Jaccard 相似度、suggested_corrections修正建议标题相似度 0.8 或年份、作者字段直接采用参考数据与statusverified / discrepancies_found / unverified / error。校验状态会以% [Verified]、% [Discrepancies Found]、% [Unverified]注释标记拼接到引用文本末尾并可通过db_manager.cache_reference按 DOI 缓存已验证的 BibTeX 结果。六、Coach写作助手智能体6.1 核心能力清单FEATURES 声明 Coach 支持文本改进、学术润色、风格转换、语法检查。智能体层工具见 agents/coach.pyexplain_concept、polish_text、mimic_style、get_user_style、suggest_improvements。6.2 四种任务类型CoachAgent.run()要求user_id、task_type、content三个必填字段coach.py按task_type分发任务类型处理函数核心逻辑explain_handle_explain_task结合用户研究背景输出通俗解释、例子类比、领域重要性、应用场景polish_handle_polish_task读取用户写作风格偏好 向量库风格参考论文产出润色文本、修改说明、风格建议mimic_handle_mimic_task基于target_style与参考论文默认取用户评分最高的 3 篇进行风格重写suggest_handle_suggest_task结合用户写作历史给出整体评价、改进建议、语法问题、结构优化建议这些任务都以 JSON 输出约定驱动 LLMjson.loads失败时均有结构化的默认回退结果保证接口在任何情况下都能返回可解析数据。6.3 API 层写作端点POST /api/v1/writing/coachwriting.py是 FEATURES 中列出的写作端点请求模型WritingCoachRequest包含text必填、style默认formal可传 academic 等、task默认polish可选polish/translate/explain/expand、context。四类任务分别对应四套中文 Prompt润色要求保持学术严谨性与表达清晰度翻译要求转为地道英文学术表达解释要求通俗化并给出例子扩写要求补充背景、理论支持与方法论细节。注意未配置OPENAI_API_KEY时该端点返回 503。七、工作流 API一键科研流水线7.1 完整工作流POST /api/v1/workflow/completeworkflow.py 将四个智能体编排为四步流水线请求模型字段如下字段默认值说明keywords必填研究关键词analysis_typesummary分析类型summary/innovation/comparison/comprehensivecitation_formatbibtex引用格式bibtex/apa/ieee/mlawriting_task可选写作任务improve/polish/translate传入才执行第 4 步limit5搜索论文数量执行细节步骤 1Hunter调用论文搜索函数未找到论文时返回 404步骤 2Miner仅分析前 3 篇论文单篇失败只记warning并继续不中断工作流步骤 3Validator为前 3 篇论文构造引用文本并校验生成指定格式步骤 4Coach可选自动拼装 Markdown 综述报告含搜索结果、前 3 篇分析、参考文献再交给 Coach 按writing_task加工。每一步的执行结果都写入results[steps]最终返回statusrunning/completed/failed、steps与summary论文总数、分析数、引用数、关键词——这就是 FEATURES 中结果整合展示 步骤状态跟踪的 API 落地。7.2 简化工作流POST /api/v1/workflow/search-and-analyzeworkflow.py 实现搜索 分析两步快速流程先按keywords与limit搜索论文再对第一篇论文执行指定analysis_type分析适合快速验证研究主题的价值。八、部署、验证与 API 快速上手8.1 本地运行FEATURES 与 USAGE_GUIDE.md 一致启动方式为python run.pyrun.py 会将项目根目录加入sys.path随后以uvicorn启动api.main:app监听0.0.0.0:8000并开启热重载。启动后可访问主页http://localhost:8000返回 frontend/index.htmlAPI 文档http://localhost:8000/docs健康检查http://localhost:8000/health8.2 启动时的容错设计从 api/main.py 的lifespan生命周期可以看到系统启动时依次初始化数据库、向量存储与智能体控制器三者均为尽力而为任何组件初始化失败仅打印 warning并以无数据库 / 无向量存储模式继续运行从而保证在没有 PostgreSQL、Qdrant 的环境下核心搜索与写作功能仍可用。8.3 环境变量配置模型与外部服务通过.env文件配置加载逻辑见 core/config.py# AI 模型配置 OPENAI_API_KEYyour_api_key OPENAI_BASE_URLhttps://api.openai.com/v1 OPENAI_MODELgpt-3.5-turbo # 也可用 LLM_MODEL # 外部 API可选 CROSSREF_API_KEY... GOOGLE_SCHOLAR_API_KEY... SERPAPI_KEY... # 其他 DEBUGfalse LOG_LEVELINFOLLM 层通过 core/llm_adapter.py 的get_llm_adapter()统一注入各智能体与 API 路由。FEATURES 技术栈中提到的 ModelScope 也映射为 config.py 中LLMProvider枚举的modelscope/dashscope/ollama等选项——即支持 OpenAI 协议兼容模型的灵活切换。8.4 API 调用示例结合 USAGE_GUIDE.md 与路由源码几个最常用的调用# 1. 搜索论文真实 ArXiv API curl -X POST http://localhost:8000/api/v1/papers/search \ -H Content-Type: application/json \ -d {keywords: machine learning, source: arxiv, limit: 10} # 2. 分析论文ArXiv URL / 本地 PDF 均可 curl -X POST http://localhost:8000/api/v1/analysis/analyze \ -H Content-Type: application/json \ -d {paper_url: https://arxiv.org/abs/2301.00001, analysis_type: summary} # 3. 写作助手需配置 OPENAI_API_KEY curl -X POST http://localhost:8000/api/v1/writing/coach \ -H Content-Type: application/json \ -d {text: Your text here, style: academic, task: improve} # 4. 引用校验ArXiv / DOI / AI 三级验证 curl -X POST http://localhost:8000/api/v1/citations/validate \ -H Content-Type: application/json \ -d {citation: Your citation here, format: bibtex} # 5. 一键完整工作流 curl -X POST http://localhost:8000/api/v1/workflow/complete \ -H Content-Type: application/json \ -d {keywords: deep learning, limit: 5, analysis_type: summary, citation_format: bibtex, writing_task: improve}8.5 系统验证按 USAGE_GUIDE.md 说明可运行python verify_system.py验证各功能模块启动后通过/health端点即可查看四个智能体的实时状态get_agent_status返回各智能体的 name/state/history 计数/工具数/超时配置及队列负载。九、性能指标、使用场景与演进路线9.1 性能指标解读FEATURES 给出了响应时间与准确性两类指标结合源码可以理解这些数据的来源指标数值来源说明论文搜索~5 秒ArXiv API 网络往返 去重筛选论文分析~20 秒LLM 推理为主单次ainvoke引用校验~3 秒ArXiv/Crossref 外部 API 请求写作助手~15 秒LLM 生成 向量库风格检索完整工作流~70 秒搜索 分析 3 篇 引用 报告串行累加简化工作流~25 秒搜索 分析 1 篇注以上为项目文档中标注的经验值实际耗时取决于网络状况、所选模型与论文规模仅供选型参考。9.2 典型使用场景适合单独模式分析单篇论文、校验单条引用、润色特定段落、快速测试某个智能体的功能边界适合协调模式文献综述、研究调研、论文写作准备、需要批量产出的研究流程。9.3 演进路线FEATURES 的未来计划明确分为三块功能增强工作流模板、自定义工作流、工作流历史、批量 PDF 处理、性能优化并发处理、结果缓存、长文本优化与用户体验进度条、实时更新、结果导出、多语言支持。其中并发处理与结果缓存在架构上已有雏形——控制器自带concurrent_agents信号量与Semaphore并发控制controller.pyValidator 已实现按 DOI 缓存 BibTeX 的cache_referencevalidator.py后续增强可在此基础上扩展。十、前端界面系统前端由 frontend/index.html 提供与 frontend/app.js、frontend/static/style.css 配合实现 FEATURES 中列出的前端能力响应式设计、单独/协调双模式切换、工作流卡片、参数配置面板、PDF 拖拽上传、实时加载状态、错误提示、成功反馈、Markdown 渲染、代码高亮与一键复制。以下界面截图展示了双模式切换下的主界面与核心功能卡片延伸阅读若希望深入本项目可继续阅读仓库内以下文件功能清单FEATURES.md使用指南USAGE_GUIDE.md项目说明与架构图README.md快速上手QUICKSTART.md模型接入说明docs/MODEL_GUIDE.md核心源码agents/base.py、agents/controller.py、core/config.py、api/main.py【免费下载链接】hello-agents 《从零开始构建智能体》——从零开始的智能体原理与实践教程项目地址: https://gitcode.com/datawhalechina/hello-agents创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 InnoCore AI 功能全景解析：基于 HelloAgent 的多智能体科研助手特性与实战指南
InnoCore AI 功能全景解析基于 HelloAgent 的多智能体科研助手特性与实战指南【免费下载链接】hello-agents 《从零开始构建智能体》——从零开始的智能体原理与实践教程项目地址: https://gitcode.com/datawhalechina/hello-agents导读InnoCore AI研创·智核是构建于 HelloAgent 多智能体框架之上的一套智能科研创新助手以四大分工明确的智能体Hunter/Miner/Coach/Validator协同完成论文搜索、深度分析、写作辅助与引用校验的科研全流程。本文以该项目官方《功能清单》FEATURES.md为骨架逐项对照 agents/ 与 api/routes/ 下的真实源码带读者理解每一项功能在代码层的实现方式、可配置参数与调用入口最终掌握双工作模式、七大 API 端点组以及本地部署与验证的完整方法。一、项目定位与功能总览1.1 功能清单的整体结构FEATURES.md 从六个维度组织项目能力维度覆盖内容工作模式单独模式、协调模式完整工作流智能体功能Hunter 论文搜索、Miner 论文分析、Validator 引用校验、Coach 写作助手工作流功能完整工作流、简化工作流搜索分析前端功能响应式界面、模式切换、拖拽上传、Markdown 渲染、一键复制API 端点论文、分析、写作、引用、工作流五大类共 7 个 POST 端点测试与文档README、USAGE_GUIDE、FEATURES、WORKFLOW_GUIDE 四类文档1.2 四大智能体的协作分工从 agents/controller.py 可以看到控制器AgentController在初始化时统一实例化了四个智能体构成系统的智能体编排层self.agents { hunter: HunterAgent(), miner: MinerAgent(), coach: CoachAgent(), validator: ValidatorAgent() }每个智能体都继承自 agents/base.py 的BaseAgent抽象类具备统一的max_steps最大步骤数默认 5、timeout超时秒数默认 300、state状态机idle/running/completed/error、history对话历史与工具注册表tools。这意味着四个智能体在调用 LLM 思考think、注册并执行工具add_tool/call_tool、校验必填输入validate_input三件事上行为一致差异只体现在各自封装的领域工具上。二、双工作模式单独模式与协调模式2.1 单独模式Individual Mode单独模式下每个智能体独立对外服务适合单一任务与精细控制。系统为每种任务都提供了直接的 REST 端点前端对应独立的操作卡片。FEATURES 中列出的单独模式能力包括独立使用每个智能体、灵活控制每个步骤、适合单一任务。以论文分析为例单独模式下可直接调用POST /api/v1/analysis/analyze传入paper_url与analysis_type由 analysis.py 单点执行全程不涉及其他智能体。2.2 协调模式Coordinated Mode⭐协调模式通过 AgentController 的_execute_full_workflow方法实现完整工作流编排将四个智能体串联为一条流水线Stage 1 论文抓取调用HunterAgent.run()输入keywords、max_papers默认 10、sources默认[arxiv]Stage 2 论文分析遍历已下载论文逐篇调用MinerAgent.run()生成分析报告Stage 3 引用校验可选通过validate_citations开关控制逐篇调用ValidatorAgent.run()生成 BibTeX/APA 引用Stage 4 报告整合将各阶段结果汇总到workflow_result输出stages、final_papers、analysis_reports。协调模式的核心支撑是任务管理机制。从 controller.py 可以看到控制器内置了active_tasks/task_history活动任务与历史任务字典task_queue异步优先队列asyncio.Queue配合start_task_processor()消费semaphore信号量并发控制上限取config.concurrent_agents默认 4event_callbackstask_started/task_completed/task_failed/agent_status_changed四类事件回调。任务生命周期由TaskStatus枚举完整覆盖PENDING → RUNNING → COMPLETED / FAILED / CANCELLED任何异常都会写入task[error]并触发task_failed事件即 FEATURES 中步骤状态跟踪 错误处理的代码实现。三、Hunter论文搜索智能体3.1 核心能力清单FEATURES 声明的 Hunter 能力为ArXiv 实时搜索、关键词搜索、结果数量控制、论文信息提取。对应 agents/hunter.py 注册的四个工具工具名底层方法说明search_arxiv_search_arxiv按关键词搜索 ArXivsearch_ieee_search_ieee按关键词搜索 IEEE需配置 API keydownload_pdf_download_pdf下载 PDF 到downloads/papers/extract_metadata_extract_metadata提取论文元数据3.2 运行参数与检索逻辑HunterAgent.run()的输入参数见 hunter.py参数默认值含义keywords必填关键词列表使用all:kw拼接为OR查询max_papers20最大返回论文数sources[arxiv, ieee]检索数据源days_back1回溯天数时间过滤ArXiv 检索使用http://export.arxiv.org/api/query端点hunter.py通过aiohttp异步请求并以feedparser解析 Atom 响应随后依次执行三层后处理去重_deduplicate_papers对论文标题取 MD5 哈希集合判重hunter.py相关性筛选_filter_papers标题命中关键词记 2 分、摘要命中记 1 分score 1才保留并按分数降序hunter.py下载入库_download_and_save_paper下载 PDF、计算 SHA-256 内容哈希并通过db_manager.create_paper写入数据库hunter.py。每条论文记录提取的字段包括id、title、authors、abstract、published、pdf_url、doi、categories——这正是论文信息提取能力的实现。3.3 IEEE 数据源的前提条件IEEE 检索需要ieee_base_url与ieee_api_key配置hunter.py若config.external_apis.ieee_base_url为空会记录IEEE API 配置缺失跳过 IEEE 搜索并直接返回空结果。API 层的实际搜索路径则默认只走 ArXiv见下文 5.1 节因此 FEATURES 中ArXiv 实时搜索是无条件可用能力而 IEEE 属于需自行配置扩展项。四、Miner论文分析智能体4.1 核心能力清单FEATURES 声明 Miner 支持ArXiv URL 分析、PDF 文件上传、PDF 自动解析、4 种分析类型摘要/创新点/对比/综合。其工具注册见 agents/miner.py工具名说明parse_pdf解析 PDF 文件search_memory搜索记忆库向量检索compare_papers对比论文generate_report生成分析报告4.2 分析流水线六步MinerAgent.run()以paper_id为必填字段miner.py内部按固定流水线执行解析 PDF 内容_parse_paper_content有本地文件时提取结构化内容否则退化为仅使用标题摘要的metadata_only模式检索相关历史论文_find_related_papers通过vector_store_manager.hybrid_search做向量 关键词混合检索top_k10同时支持include_l1预置库与include_l2用户私有库两层知识库对比分析_perform_comparison_analysis将当前论文与相似度最高的前 5 篇历史论文构造成对比 Prompt要求 LLM 从方法创新性、实验设计、与现有工作区别、研究空白四个角度以 JSON 返回结果解析失败时降级为_parse_text_comparison文本解析生成分析报告_create_analysis_report要求 LLM 按 Summary / Innovation / Limitation / Future Ideas 四段结构输出 JSON解析失败时回退到_generate_default_report保存报告_save_analysis_report调用db_manager.create_analysis_report持久化更新向量库_update_vector_store将论文内容标题摘要章节文本写入 L2 用户库供后续语义检索使用。4.3 四种分析类型的 Prompt 差异在 API 层analysis.py四种分析类型对应四套独立的中文 Prompt均基于标题作者摘要论文内容截取前 8000 字符构造摘要分析summary要求输出研究背景动机、主要方法、核心贡献、实验结果、研究意义创新点分析innovation要求输出技术创新、方法论创新、理论贡献、与现有工作区别、潜在应用价值对比分析comparison要求输出与传统方法对比、优劣势、适用场景、性能提升、局限性综合分析comprehensive要求覆盖背景意义、方法详解、创新点、实验验证、优缺点、未来方向、应用价值七个方面。4.4 输入格式识别Miner 支持三类输入analysis.pyArXiv URL如https://arxiv.org/abs/2511.16672ArXiv ID如2511.16672正则^(\d{4}\.\d{4,5})v?\d*$兜底本地 PDF上传解析后自动填充/uploads/路径。针对本地 PDF系统会先调用 utils/pdf_parser.py 解析出标题、作者、摘要与全文含页数、字数统计再用完整内容驱动 LLM 分析并对超过 8000 字符的全文做截断以规避 token 上限。五、Validator引用校验智能体5.1 核心能力清单FEATURES 声明 Validator 支持DOI 自动验证、ArXiv ID 识别、AI 辅助解析、4 种引用格式BibTeX/APA/IEEE/MLA。智能体层的工具注册见 agents/validator.pygenerate_bibtex、generate_apa、generate_ieee、verify_metadata、crossref_lookup、scholar_lookup六个工具。5.2 三级验证流水线引用校验端点POST /api/v1/citations/validatecitations.py按优先级执行三级验证ArXiv 识别正则(?:arxiv\.org/abs/|arXiv:)(\d\.\d)提取 ArXiv ID调用arxiv.Search(id_list[id])拉取真实元数据DOI 验证正则10\.\d{4,9}/[-._;()/:A-Z0-9]提取 DOI通过httpx请求https://api.crossref.org/works/{doi}10 秒超时核验标题、作者、年份、期刊、卷期页码AI 辅助解析前两级都失败时将引用原文交给 LLM要求以纯 JSON 提取 title/authors/year/journal/volume/issue/pages/doi/arxiv_id 等字段并对模型输出做代码块 JSON 或裸 JSON 的二次提取兜底。5.3 四种引用格式生成验证通过后citations.py 根据format参数默认bibtex生成四种格式作者数超过 3 人统一缩写为前3作者 et al.BibTeXarticle{key{year}, title{...}, author{...}, journal{...}, year{...}}ArXiv 论文追加eprint与archivePrefix{arXiv}DOI 论文追加doi字段APA作者 (年份). 标题. *期刊*卷(期), 页码. arXiv:xxx或https://doi.org/xxxIEEE[1] 作者, 标题, *期刊*, vol. 卷, no. 期, pp. 页码, 年份, doi: xxx.MLA作者. 标题. *期刊*, vol. 卷, no. 期, 年份, pp. 页码.智能体层validator.py还实现了更完整的格式逻辑包括 BibTeX 条目类型自动判定有journal→article、有booktitle→inproceedings、有publisher→book、否则→misc、作者姓名 First Last → Last, First 转换以及 IEEE 的作者首字母缩写规则。5.4 元数据差异校验与缓存智能体层的_verify_paper_metadatavalidator.py支持多数据源CrossRef Google Scholar/SerpApi交叉比对产出discrepancies标题/作者/年份差异列表含 Jaccard 相似度、suggested_corrections修正建议标题相似度 0.8 或年份、作者字段直接采用参考数据与statusverified / discrepancies_found / unverified / error。校验状态会以% [Verified]、% [Discrepancies Found]、% [Unverified]注释标记拼接到引用文本末尾并可通过db_manager.cache_reference按 DOI 缓存已验证的 BibTeX 结果。六、Coach写作助手智能体6.1 核心能力清单FEATURES 声明 Coach 支持文本改进、学术润色、风格转换、语法检查。智能体层工具见 agents/coach.pyexplain_concept、polish_text、mimic_style、get_user_style、suggest_improvements。6.2 四种任务类型CoachAgent.run()要求user_id、task_type、content三个必填字段coach.py按task_type分发任务类型处理函数核心逻辑explain_handle_explain_task结合用户研究背景输出通俗解释、例子类比、领域重要性、应用场景polish_handle_polish_task读取用户写作风格偏好 向量库风格参考论文产出润色文本、修改说明、风格建议mimic_handle_mimic_task基于target_style与参考论文默认取用户评分最高的 3 篇进行风格重写suggest_handle_suggest_task结合用户写作历史给出整体评价、改进建议、语法问题、结构优化建议这些任务都以 JSON 输出约定驱动 LLMjson.loads失败时均有结构化的默认回退结果保证接口在任何情况下都能返回可解析数据。6.3 API 层写作端点POST /api/v1/writing/coachwriting.py是 FEATURES 中列出的写作端点请求模型WritingCoachRequest包含text必填、style默认formal可传 academic 等、task默认polish可选polish/translate/explain/expand、context。四类任务分别对应四套中文 Prompt润色要求保持学术严谨性与表达清晰度翻译要求转为地道英文学术表达解释要求通俗化并给出例子扩写要求补充背景、理论支持与方法论细节。注意未配置OPENAI_API_KEY时该端点返回 503。七、工作流 API一键科研流水线7.1 完整工作流POST /api/v1/workflow/completeworkflow.py 将四个智能体编排为四步流水线请求模型字段如下字段默认值说明keywords必填研究关键词analysis_typesummary分析类型summary/innovation/comparison/comprehensivecitation_formatbibtex引用格式bibtex/apa/ieee/mlawriting_task可选写作任务improve/polish/translate传入才执行第 4 步limit5搜索论文数量执行细节步骤 1Hunter调用论文搜索函数未找到论文时返回 404步骤 2Miner仅分析前 3 篇论文单篇失败只记warning并继续不中断工作流步骤 3Validator为前 3 篇论文构造引用文本并校验生成指定格式步骤 4Coach可选自动拼装 Markdown 综述报告含搜索结果、前 3 篇分析、参考文献再交给 Coach 按writing_task加工。每一步的执行结果都写入results[steps]最终返回statusrunning/completed/failed、steps与summary论文总数、分析数、引用数、关键词——这就是 FEATURES 中结果整合展示 步骤状态跟踪的 API 落地。7.2 简化工作流POST /api/v1/workflow/search-and-analyzeworkflow.py 实现搜索 分析两步快速流程先按keywords与limit搜索论文再对第一篇论文执行指定analysis_type分析适合快速验证研究主题的价值。八、部署、验证与 API 快速上手8.1 本地运行FEATURES 与 USAGE_GUIDE.md 一致启动方式为python run.pyrun.py 会将项目根目录加入sys.path随后以uvicorn启动api.main:app监听0.0.0.0:8000并开启热重载。启动后可访问主页http://localhost:8000返回 frontend/index.htmlAPI 文档http://localhost:8000/docs健康检查http://localhost:8000/health8.2 启动时的容错设计从 api/main.py 的lifespan生命周期可以看到系统启动时依次初始化数据库、向量存储与智能体控制器三者均为尽力而为任何组件初始化失败仅打印 warning并以无数据库 / 无向量存储模式继续运行从而保证在没有 PostgreSQL、Qdrant 的环境下核心搜索与写作功能仍可用。8.3 环境变量配置模型与外部服务通过.env文件配置加载逻辑见 core/config.py# AI 模型配置 OPENAI_API_KEYyour_api_key OPENAI_BASE_URLhttps://api.openai.com/v1 OPENAI_MODELgpt-3.5-turbo # 也可用 LLM_MODEL # 外部 API可选 CROSSREF_API_KEY... GOOGLE_SCHOLAR_API_KEY... SERPAPI_KEY... # 其他 DEBUGfalse LOG_LEVELINFOLLM 层通过 core/llm_adapter.py 的get_llm_adapter()统一注入各智能体与 API 路由。FEATURES 技术栈中提到的 ModelScope 也映射为 config.py 中LLMProvider枚举的modelscope/dashscope/ollama等选项——即支持 OpenAI 协议兼容模型的灵活切换。8.4 API 调用示例结合 USAGE_GUIDE.md 与路由源码几个最常用的调用# 1. 搜索论文真实 ArXiv API curl -X POST http://localhost:8000/api/v1/papers/search \ -H Content-Type: application/json \ -d {keywords: machine learning, source: arxiv, limit: 10} # 2. 分析论文ArXiv URL / 本地 PDF 均可 curl -X POST http://localhost:8000/api/v1/analysis/analyze \ -H Content-Type: application/json \ -d {paper_url: https://arxiv.org/abs/2301.00001, analysis_type: summary} # 3. 写作助手需配置 OPENAI_API_KEY curl -X POST http://localhost:8000/api/v1/writing/coach \ -H Content-Type: application/json \ -d {text: Your text here, style: academic, task: improve} # 4. 引用校验ArXiv / DOI / AI 三级验证 curl -X POST http://localhost:8000/api/v1/citations/validate \ -H Content-Type: application/json \ -d {citation: Your citation here, format: bibtex} # 5. 一键完整工作流 curl -X POST http://localhost:8000/api/v1/workflow/complete \ -H Content-Type: application/json \ -d {keywords: deep learning, limit: 5, analysis_type: summary, citation_format: bibtex, writing_task: improve}8.5 系统验证按 USAGE_GUIDE.md 说明可运行python verify_system.py验证各功能模块启动后通过/health端点即可查看四个智能体的实时状态get_agent_status返回各智能体的 name/state/history 计数/工具数/超时配置及队列负载。九、性能指标、使用场景与演进路线9.1 性能指标解读FEATURES 给出了响应时间与准确性两类指标结合源码可以理解这些数据的来源指标数值来源说明论文搜索~5 秒ArXiv API 网络往返 去重筛选论文分析~20 秒LLM 推理为主单次ainvoke引用校验~3 秒ArXiv/Crossref 外部 API 请求写作助手~15 秒LLM 生成 向量库风格检索完整工作流~70 秒搜索 分析 3 篇 引用 报告串行累加简化工作流~25 秒搜索 分析 1 篇注以上为项目文档中标注的经验值实际耗时取决于网络状况、所选模型与论文规模仅供选型参考。9.2 典型使用场景适合单独模式分析单篇论文、校验单条引用、润色特定段落、快速测试某个智能体的功能边界适合协调模式文献综述、研究调研、论文写作准备、需要批量产出的研究流程。9.3 演进路线FEATURES 的未来计划明确分为三块功能增强工作流模板、自定义工作流、工作流历史、批量 PDF 处理、性能优化并发处理、结果缓存、长文本优化与用户体验进度条、实时更新、结果导出、多语言支持。其中并发处理与结果缓存在架构上已有雏形——控制器自带concurrent_agents信号量与Semaphore并发控制controller.pyValidator 已实现按 DOI 缓存 BibTeX 的cache_referencevalidator.py后续增强可在此基础上扩展。十、前端界面系统前端由 frontend/index.html 提供与 frontend/app.js、frontend/static/style.css 配合实现 FEATURES 中列出的前端能力响应式设计、单独/协调双模式切换、工作流卡片、参数配置面板、PDF 拖拽上传、实时加载状态、错误提示、成功反馈、Markdown 渲染、代码高亮与一键复制。以下界面截图展示了双模式切换下的主界面与核心功能卡片延伸阅读若希望深入本项目可继续阅读仓库内以下文件功能清单FEATURES.md使用指南USAGE_GUIDE.md项目说明与架构图README.md快速上手QUICKSTART.md模型接入说明docs/MODEL_GUIDE.md核心源码agents/base.py、agents/controller.py、core/config.py、api/main.py【免费下载链接】hello-agents 《从零开始构建智能体》——从零开始的智能体原理与实践教程项目地址: https://gitcode.com/datawhalechina/hello-agents创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考