【S1W2 交叉评测】对项目 S1W2-Enterprise-Research-Report-Agent 的反馈 #3

New issue

Open

opened 2026-05-15 21:13:22 +08:00 by yishan · 0 comments

yishan commented 2026-05-15 21:13:22 +08:00

Copy link

1. 项目理解

我理解这个项目主要想解决：

• 企业研报/年报阅读效率低的问题：将PDF上传后自动解析、切分、向量化入库，通过RAG检索+LLM生成实现"上传即问答"，让用户省去逐页翻阅的体力劳动。
• 投研分析缺乏可追溯证据的问题：所有生成回答都附带证据引用（页码、章节、quote、向量相似度分数），内部文档用 [1]/[2] 编号、联网资料用 [W1]/[W2] 编号，形成可复核的证据链。
• 投研分析需要多维度结构化产出的问题：不仅止步于单轮问答，还支持自动生成Markdown投研长报告（含摘要、财务经营、行业竞争、风险、结论等固定章节）和企业能力六维评分（财务健康、成长韧性、竞争壁垒、创新能力、治理风险、外部舆情）。
• 多知识库隔离与数据生命周期管理需求：按公司/行业/课程独立管理知识库，支持PDF上传、替换、删除、批量删除，并同步清理SQLite chunk、向量索引和源文件。
• 研报分析需要外部公开信息补充的问题：通过LangChain tool+DuckDuckGo/DDGS联网搜索，在问答/报告/评分中自动补充公司公开信息和行业背景。
• 离线/低配环境可用性：无API Key时自动切换mock模式，sentence-transformers加载失败时降级为hash embedding，Milvus不可用时支持Memory Vector Store。

核心定位是"面向金融/经济/管理专业学生和投研初学者的，可离线演示的企业研报RAG分析原型系统"。

2. 项目优点

2.1 架构设计

• 依赖注入清晰：ServiceContainer 集中管理所有服务实例的创建和生命周期，各服务通过构造函数注入依赖，而非全局单例，便于测试时替换组件（测试中已验证可注入 FakeWebResearchService）。
• 三层 schema 分离：schemas/api.py 包含200+行的Pydantic请求/响应模型，与数据库层、服务层内部模型严格分离。
• 双重向量库策略：MilvusVectorStore 先尝试 LangChain Milvus wrapper，失败时自动回退到原生 pymilvus 操作（_langchain_failed 标志位控制），兼顾便利性和健壮性。

2.2 健壮性与降级设计（项目最大亮点）

• LangGraph导入fallback：agent_graph.py 和 score_service.py 均内置了完整的 StateGraph 替代实现（30+行），当 langgraph 库不可用时仍可正常运行。
• Embedding三级降级：sentence-transformers → hash embedding → 抛出异常，由 _use_hash_fallback 标志位控制。
• 联网搜索双通道降级：先尝试 DDGS 库调用，失败则用 httpx+HTML 解析直接爬 DuckDuckGo HTML 页面，均失败返回空结果，不影响主流程。
• Mock模式的层次化设计：mock不只是返回固定文本，而是根据是否有证据、是否有联网资料分别生成不同结构的回答和报告，体现了对LLM prompt结构的准确模拟。

2.3 工程细节

• 多维度的文本清洗：text_cleanup.py 包含乱码标记检测（"锛"、"銆"等ARP搴府搴傛庛庤）、编码修复尝试（latin1→utf-8、gbk→utf-8）、可读片段打捞、质量评分排序等完整逻辑，共170行。
• 多文档均分检索：agent_graph.py 的 _search_hits 方法对多文档场景按文档数量均分Top-K配额，再从各文档交替取回，不足时用全局检索补充，避免热门文档垄断检索结果。
• 自研Markdown→PDF渲染器：report_exporter.py 实现了完整的Markdown解析（标题、段落、列表、引用、代码块、表格）+ HTML渲染 + CSS排版 + fitz.Story PDF生成，不依赖 wkhtmltopdf 或 weasyprint。
• 联网搜索词构造策略：优先从文档的公司名提取、标题提取，最多取4个不重复的公司名，加上问题/主题+行业/竞争/财务后缀。

2.4 前端工程

• 三栏布局 + 按Tab切换侧边栏：问答Tab展示对话历史，报告Tab展示报告历史，评分Tab展示评分历史，空间利用率合理。
• "乐观更新"交互模式：删除操作先更新前端状态再调用API，API失败时回滚，用户体验流畅。
• Markdown逐字动画：通过 setTimeout 逐字符/批量显示Markdown内容，带闪烁光标，模拟流式效果。
• CSS设计质量高：使用CSS变量体系、背景径向渐变叠加网格纹理、多层级阴影、过渡动画，视觉呈现远超原型水平。

2.5 测试

• 测试策略务实：所有测试使用hash embedding + Memory Vector Store + mock LLM，不依赖Milvus或模型下载，测试瞬间完成。
• conftest.py中用fitz动态生成PDF：通过 fitz.open() + new_page() + insert_text() 在内存中生成测试PDF，不依赖外部测试文件。
• 模拟表格PDF生成：test_structured_scoring.py 中 make_table_pdf_bytes() 用 fitz.Rect + draw_rect + insert_text 构建带表格的PDF。

3. 当前问题

3.1 架构层面

• 前端组件过于庞大：App.jsx 共1711行，包含全部业务逻辑（状态管理、API调用、CRUD操作、UI交互），虽然有 MessageThread、ScoreResult 等子组件，但主组件仍承载过多职责。建议拆分为独立页面组件（DocumentsPage、ChatPage、ReportPage、ScorePage）和自定义hooks。
• ReportService和RagService各创建独立的AgentGraphRunner：report_service.py 和 rag_service.py 各自 new AgentGraphRunner(...)。两个Runner实例互不相通，MemorySaver checkpointer也是各自独立的。应该由ServiceContainer创建单例并注入。
• 评分Graph Runner与问答Graph Runner代码重复：score_service.py 中的 ScoreGraphRunner._validate_scope 逻辑与 agent_graph.py 中的 AgentGraphRunner._validate_scope 几乎完全一致，应抽取公共校验逻辑。

3.2 评分算法（核心硬伤）

• 维度评分算法缺乏语义理解：score_service.py 的评分公式是 50 + min(len(evidences),3)*8 + min(len(metric_subset),4)*5 + min(len(web_references),2)*4，完全基于证据数量而非质量。例如：返回3条不相关证据的维度得74分，而返回1条高度相关证据仅得58分。评分上限硬编码为92分。
• rationale生成也是模板化的：build_rationale 函数只是统计证据/指标/联网资料条数，没有调用LLM做真正的语义分析。
• 维度评分只有规则评分，不像文档声称的那样"综合知识库证据、结构化财务指标和联网搜索资料"进行深度分析。

3.3 代码质量问题

• LangGraph fallback代码重复：agent_graph.py 和 score_service.py 中各有完整的一套 StateGraph + CompiledGraph fallback实现（约40行完全相同），应提取到公共模块。
• 重复的辅助函数：compact_quote 函数在 agent_graph.py（limit=500）和 score_service.py（limit=420）各定义了一次。
• _chunk_paragraphs 方法未使用：text_splitter.py 中的 _chunk_paragraphs 方法定义了但 split_pages 实际走的是 LangChain RecursiveCharacterTextSplitter.split_documents，该方法成为死代码（55行）。

3.4 功能缺位

• 无用户认证/多用户隔离：整个系统没有用户概念，所有文件和知识库全局可见。
• 无流式（SSE）输出：问答和报告生成的LangGraph运行是同步等待的，没有实现真正的SSE流式输出。前端的逐字动画只是前端模拟（MarkdownBlock 的 animate prop）。
• 无异步任务队列：上传大PDF时整个请求线程被阻塞，直到解析+embedding完成才返回。
• 多轮对话历史截断策略粗糙：agent_graph.py 的 _load_memory 仅取最近8条消息，没有做token计数截断、没有做智能摘要压缩。
• 联网搜索仅支持DuckDuckGo：web_research.py 中 provider 硬编码判断，非 duckduckgo 直接返回空。

3.5 测试覆盖不足

• 缺少 service 层单元测试：现有测试都是端到端API测试，对 TableExtractor、TextCleanup、PdfParser、WebResearchService 等核心服务缺少独立单元测试。
• 缺少 Milvus 集成测试：README提到可用 RUN_MILVUS_TESTS=1 运行，但常规 pytest 不包含。
• 前端无测试：没有 vitest 或 jest 配置，没有任何前端组件测试。

3.6 潜在风险

• 无并发控制：SQLite用 threading.Lock 做本地锁，但 FastAPI 异步环境下多个请求可能在不同线程执行，Lock保护范围可能不够（_connect 每次创建新连接，不在Lock内）。
• 无上传文件大小限制：PdfParser直接 fitz.open(path)，无文件大小预检查。
• fitz.Story的PDF渲染稳定性：report_exporter.py 使用 fitz.Story 做 Markdown→PDF 转换，这是 PyMuPDF 较新的功能，某些复杂Markdown（嵌套列表、复杂表格）可能渲染异常。

4. 建议

4.1

1. 拆分App.jsx：将4个Tab的内容拆分为独立页面组件（DocumentsTab、ChatTab、ReportTab、ScoreTab），将CRUD逻辑提取为自定义hooks（useKnowledgeBases、useDocuments、useConversations）。
2. AgentGraphRunner单例化：在 ServiceContainer 中创建并注入到 RagService 和 ReportService，避免重复实例化。
3. 提取公共LangGraph fallback：将 StateGraph fallback代码提取到单独的 backend/services/graph_fallback.py，agent_graph.py 和 score_service.py 共用。
4. 升级评分算法：在 _score_dimensions 中增加LLM调用，将证据内容、财务指标和联网资料发给LLM进行语义评分（类似问答生成），提供至少 dimension.score 和 dimension.rationale 两个字段的LLM生成。
5. 添加文件大小限制配置：在 Settings 中增加 max_upload_size_mb，在 routes.py 上传接口中校验 file.size。

4.2

6. 实现SSE流式输出：利用 LangGraph 的 astream 功能在 _generate 节点输出时通过 SSE 推送 token，前端用 EventSource 接收。
7. 引入Hybrid Search：在向量检索基础上增加BM25关键词检索（可用 rank_bm25 库），通过 RRF（Reciprocal Rank Fusion）合并排序。
8. 增加Reranker：使用 BAAI/bge-reranker-v2-m3 等轻量 reranker 对Top-K结果重排序。
9. 数据库迁移版本管理：引入简单的迁移版本号（如 schema_version 表），_migrate 改为按版本号顺序执行。
10. 前端测试：引入 vitest，至少覆盖 API client 和关键组件（消息列表、评分结果展示）。

4.3

11. OCR支持：对扫描件PDF引入 Tesseract/ PaddleOCR。
12. 多用户系统：引入简单的JWT认证、用户-知识库归属关系。
13. Claude/GLM等多模型支持：在 LLM_MODE 基础上增加更多 provider 适配（类似现在的openai兼容模式）。
14. 自定义报告模板：允许用户配置报告章节结构和大纲。

5. 综合评价

综合定位：这是一个"远超原型水平、接近可演示产品的"企业研报RAG系统。代码量估计在6000-8000行（含前后端和测试），在两周的开发周期内完成了如此多的功能模块，工程能力很强。

技术亮点突出：多层降级设计（LangGraph fallback、Embedding fallback、联网搜索降级、Mock模式）展现了扎实的工程思维——不假设外部依赖永远可用，这在以LangChain/LLM为核心的技术栈中尤其可贵。自研Markdown→PDF渲染器也体现了不依赖第三方工具的态度。

核心短板明确：企业能力评分的算法机械化（纯规则驱动而非LLM语义驱动）是当前最大的功能缺口，与文档描述和项目定位有落差。前端组件未拆分、服务实例重复创建等问题属于工程债，当前规模下可接受但亟需重构。

---

## 1. 项目理解 我理解这个项目主要想解决： - **企业研报/年报阅读效率低的问题**：将PDF上传后自动解析、切分、向量化入库，通过RAG检索+LLM生成实现"上传即问答"，让用户省去逐页翻阅的体力劳动。 - **投研分析缺乏可追溯证据的问题**：所有生成回答都附带证据引用（页码、章节、quote、向量相似度分数），内部文档用 [1]/[2] 编号、联网资料用 [W1]/[W2] 编号，形成可复核的证据链。 - **投研分析需要多维度结构化产出的问题**：不仅止步于单轮问答，还支持自动生成Markdown投研长报告（含摘要、财务经营、行业竞争、风险、结论等固定章节）和企业能力六维评分（财务健康、成长韧性、竞争壁垒、创新能力、治理风险、外部舆情）。 - **多知识库隔离与数据生命周期管理需求**：按公司/行业/课程独立管理知识库，支持PDF上传、替换、删除、批量删除，并同步清理SQLite chunk、向量索引和源文件。 - **研报分析需要外部公开信息补充的问题**：通过LangChain tool+DuckDuckGo/DDGS联网搜索，在问答/报告/评分中自动补充公司公开信息和行业背景。 - **离线/低配环境可用性**：无API Key时自动切换mock模式，sentence-transformers加载失败时降级为hash embedding，Milvus不可用时支持Memory Vector Store。 核心定位是"面向金融/经济/管理专业学生和投研初学者的，可离线演示的企业研报RAG分析原型系统"。 ## 2. 项目优点 ### 2.1 架构设计 - **依赖注入清晰**：[ServiceContainer](file:///d:/program/a/test/test/S1W2-Enterprise-Research-Report-Agent/backend/services/container.py) 集中管理所有服务实例的创建和生命周期，各服务通过构造函数注入依赖，而非全局单例，便于测试时替换组件（测试中已验证可注入 FakeWebResearchService）。 - **三层 schema 分离**：[schemas/api.py](file:///d:/program/a/test/test/S1W2-Enterprise-Research-Report-Agent/backend/schemas/api.py) 包含200+行的Pydantic请求/响应模型，与数据库层、服务层内部模型严格分离。 - **双重向量库策略**：MilvusVectorStore 先尝试 LangChain Milvus wrapper，失败时自动回退到原生 pymilvus 操作（`_langchain_failed` 标志位控制），兼顾便利性和健壮性。 ### 2.2 健壮性与降级设计（项目最大亮点） - **LangGraph导入fallback**：[agent_graph.py](file:///d:/program/a/test/test/S1W2-Enterprise-Research-Report-Agent/backend/services/agent_graph.py) 和 [score_service.py](file:///d:/program/a/test/test/S1W2-Enterprise-Research-Report-Agent/backend/services/score_service.py) 均内置了完整的 StateGraph 替代实现（30+行），当 `langgraph` 库不可用时仍可正常运行。 - **Embedding三级降级**：sentence-transformers → hash embedding → 抛出异常，由 `_use_hash_fallback` 标志位控制。 - **联网搜索双通道降级**：先尝试 DDGS 库调用，失败则用 httpx+HTML 解析直接爬 DuckDuckGo HTML 页面，均失败返回空结果，不影响主流程。 - **Mock模式的层次化设计**：mock不只是返回固定文本，而是根据是否有证据、是否有联网资料分别生成不同结构的回答和报告，体现了对LLM prompt结构的准确模拟。 ### 2.3 工程细节 - **多维度的文本清洗**：[text_cleanup.py](file:///d:/program/a/test/test/S1W2-Enterprise-Research-Report-Agent/backend/services/text_cleanup.py) 包含乱码标记检测（"锛"、"銆"等ARP搴府搴傛庛庤）、编码修复尝试（latin1→utf-8、gbk→utf-8）、可读片段打捞、质量评分排序等完整逻辑，共170行。 - **多文档均分检索**：[agent_graph.py](file:///d:/program/a/test/test/S1W2-Enterprise-Research-Report-Agent/backend/services/agent_graph.py) 的 `_search_hits` 方法对多文档场景按文档数量均分Top-K配额，再从各文档交替取回，不足时用全局检索补充，避免热门文档垄断检索结果。 - **自研Markdown→PDF渲染器**：[report_exporter.py](file:///d:/program/a/test/test/S1W2-Enterprise-Research-Report-Agent/backend/services/report_exporter.py) 实现了完整的Markdown解析（标题、段落、列表、引用、代码块、表格）+ HTML渲染 + CSS排版 + fitz.Story PDF生成，不依赖 wkhtmltopdf 或 weasyprint。 - **联网搜索词构造策略**：优先从文档的公司名提取、标题提取，最多取4个不重复的公司名，加上问题/主题+行业/竞争/财务后缀。 ### 2.4 前端工程 - **三栏布局 + 按Tab切换侧边栏**：问答Tab展示对话历史，报告Tab展示报告历史，评分Tab展示评分历史，空间利用率合理。 - **"乐观更新"交互模式**：删除操作先更新前端状态再调用API，API失败时回滚，用户体验流畅。 - **Markdown逐字动画**：通过 `setTimeout` 逐字符/批量显示Markdown内容，带闪烁光标，模拟流式效果。 - **CSS设计质量高**：使用CSS变量体系、背景径向渐变叠加网格纹理、多层级阴影、过渡动画，视觉呈现远超原型水平。 ### 2.5 测试 - **测试策略务实**：所有测试使用hash embedding + Memory Vector Store + mock LLM，不依赖Milvus或模型下载，测试瞬间完成。 - **conftest.py中用fitz动态生成PDF**：通过 `fitz.open() + new_page() + insert_text()` 在内存中生成测试PDF，不依赖外部测试文件。 - **模拟表格PDF生成**：test_structured_scoring.py 中 `make_table_pdf_bytes()` 用 `fitz.Rect + draw_rect + insert_text` 构建带表格的PDF。 ## 3. 当前问题 ### 3.1 架构层面 - **前端组件过于庞大**：[App.jsx](file:///d:/program/a/test/test/S1W2-Enterprise-Research-Report-Agent/frontend/src/App.jsx) 共1711行，包含全部业务逻辑（状态管理、API调用、CRUD操作、UI交互），虽然有 `MessageThread`、`ScoreResult` 等子组件，但主组件仍承载过多职责。建议拆分为独立页面组件（DocumentsPage、ChatPage、ReportPage、ScorePage）和自定义hooks。 - **ReportService和RagService各创建独立的AgentGraphRunner**：[report_service.py](file:///d:/program/a/test/test/S1W2-Enterprise-Research-Report-Agent/backend/services/report_service.py) 和 [rag_service.py](file:///d:/program/a/test/test/S1W2-Enterprise-Research-Report-Agent/backend/services/rag_service.py) 各自 `new AgentGraphRunner(...)`。两个Runner实例互不相通，MemorySaver checkpointer也是各自独立的。应该由ServiceContainer创建单例并注入。 - **评分Graph Runner与问答Graph Runner代码重复**：`score_service.py` 中的 `ScoreGraphRunner._validate_scope` 逻辑与 `agent_graph.py` 中的 `AgentGraphRunner._validate_scope` 几乎完全一致，应抽取公共校验逻辑。 ### 3.2 评分算法（核心硬伤） - **维度评分算法缺乏语义理解**：[score_service.py](file:///d:/program/a/test/test/S1W2-Enterprise-Research-Report-Agent/backend/services/score_service.py#L292) 的评分公式是 `50 + min(len(evidences),3)*8 + min(len(metric_subset),4)*5 + min(len(web_references),2)*4`，完全基于证据**数量**而非**质量**。例如：返回3条不相关证据的维度得74分，而返回1条高度相关证据仅得58分。评分上限硬编码为92分。 - **rationale生成也是模板化的**：`build_rationale` 函数只是统计证据/指标/联网资料条数，没有调用LLM做真正的语义分析。 - **维度评分只有规则评分，不像文档声称的那样"综合知识库证据、结构化财务指标和联网搜索资料"进行深度分析**。 ### 3.3 代码质量问题 - **LangGraph fallback代码重复**：`agent_graph.py` 和 `score_service.py` 中各有完整的一套 `StateGraph` + `CompiledGraph` fallback实现（约40行完全相同），应提取到公共模块。 - **重复的辅助函数**：`compact_quote` 函数在 `agent_graph.py`（limit=500）和 `score_service.py`（limit=420）各定义了一次。 - **`_chunk_paragraphs` 方法未使用**：[text_splitter.py](file:///d:/program/a/test/test/S1W2-Enterprise-Research-Report-Agent/backend/services/text_splitter.py) 中的 `_chunk_paragraphs` 方法定义了但 `split_pages` 实际走的是 LangChain `RecursiveCharacterTextSplitter.split_documents`，该方法成为死代码（55行）。 ### 3.4 功能缺位 - **无用户认证/多用户隔离**：整个系统没有用户概念，所有文件和知识库全局可见。 - **无流式（SSE）输出**：问答和报告生成的LangGraph运行是同步等待的，没有实现真正的SSE流式输出。前端的逐字动画只是前端模拟（`MarkdownBlock` 的 `animate` prop）。 - **无异步任务队列**：上传大PDF时整个请求线程被阻塞，直到解析+embedding完成才返回。 - **多轮对话历史截断策略粗糙**：[agent_graph.py](file:///d:/program/a/test/test/S1W2-Enterprise-Research-Report-Agent/backend/services/agent_graph.py#L221-L228) 的 `_load_memory` 仅取最近8条消息，没有做token计数截断、没有做智能摘要压缩。 - **联网搜索仅支持DuckDuckGo**：`web_research.py` 中 provider 硬编码判断，非 `duckduckgo` 直接返回空。 ### 3.5 测试覆盖不足 - **缺少 service 层单元测试**：现有测试都是端到端API测试，对 `TableExtractor`、`TextCleanup`、`PdfParser`、`WebResearchService` 等核心服务缺少独立单元测试。 - **缺少 Milvus 集成测试**：README提到可用 `RUN_MILVUS_TESTS=1` 运行，但常规 `pytest` 不包含。 - **前端无测试**：没有 vitest 或 jest 配置，没有任何前端组件测试。 ### 3.6 潜在风险 - **无并发控制**：SQLite用 `threading.Lock` 做本地锁，但 FastAPI 异步环境下多个请求可能在不同线程执行，Lock保护范围可能不够（`_connect` 每次创建新连接，不在Lock内）。 - **无上传文件大小限制**：PdfParser直接 `fitz.open(path)`，无文件大小预检查。 - **fitz.Story的PDF渲染稳定性**：`report_exporter.py` 使用 `fitz.Story` 做 Markdown→PDF 转换，这是 PyMuPDF 较新的功能，某些复杂Markdown（嵌套列表、复杂表格）可能渲染异常。 ## 4. 建议 ### 4.1 1. **拆分App.jsx**：将4个Tab的内容拆分为独立页面组件（`DocumentsTab`、`ChatTab`、`ReportTab`、`ScoreTab`），将CRUD逻辑提取为自定义hooks（`useKnowledgeBases`、`useDocuments`、`useConversations`）。 2. **AgentGraphRunner单例化**：在 `ServiceContainer` 中创建并注入到 `RagService` 和 `ReportService`，避免重复实例化。 3. **提取公共LangGraph fallback**：将 `StateGraph` fallback代码提取到单独的 `backend/services/graph_fallback.py`，`agent_graph.py` 和 `score_service.py` 共用。 4. **升级评分算法**：在 `_score_dimensions` 中增加LLM调用，将证据内容、财务指标和联网资料发给LLM进行语义评分（类似问答生成），提供至少 `dimension.score` 和 `dimension.rationale` 两个字段的LLM生成。 5. **添加文件大小限制配置**：在 `Settings` 中增加 `max_upload_size_mb`，在 `routes.py` 上传接口中校验 `file.size`。 ### 4.2 6. **实现SSE流式输出**：利用 LangGraph 的 `astream` 功能在 `_generate` 节点输出时通过 SSE 推送 token，前端用 `EventSource` 接收。 7. **引入Hybrid Search**：在向量检索基础上增加BM25关键词检索（可用 `rank_bm25` 库），通过 RRF（Reciprocal Rank Fusion）合并排序。 8. **增加Reranker**：使用 `BAAI/bge-reranker-v2-m3` 等轻量 reranker 对Top-K结果重排序。 9. **数据库迁移版本管理**：引入简单的迁移版本号（如 `schema_version` 表），`_migrate` 改为按版本号顺序执行。 10. **前端测试**：引入 vitest，至少覆盖 API client 和关键组件（消息列表、评分结果展示）。 ### 4.3 11. **OCR支持**：对扫描件PDF引入 Tesseract/ PaddleOCR。 12. **多用户系统**：引入简单的JWT认证、用户-知识库归属关系。 13. **Claude/GLM等多模型支持**：在 `LLM_MODE` 基础上增加更多 provider 适配（类似现在的openai兼容模式）。 14. **自定义报告模板**：允许用户配置报告章节结构和大纲。 ## 5. 综合评价 **综合定位**：这是一个"远超原型水平、接近可演示产品的"企业研报RAG系统。代码量估计在6000-8000行（含前后端和测试），在两周的开发周期内完成了如此多的功能模块，工程能力很强。 **技术亮点突出**：多层降级设计（LangGraph fallback、Embedding fallback、联网搜索降级、Mock模式）展现了扎实的工程思维——不假设外部依赖永远可用，这在以LangChain/LLM为核心的技术栈中尤其可贵。自研Markdown→PDF渲染器也体现了不依赖第三方工具的态度。 **核心短板明确**：企业能力评分的算法机械化（纯规则驱动而非LLM语义驱动）是当前最大的功能缺口，与文档描述和项目定位有落差。前端组件未拆分、服务实例重复创建等问题属于工程债，当前规模下可接受但亟需重构。 ---

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

main

No results found.

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

Z2wen1tao_31/S1W2-Enterprise-Research-Report-Agent#3

No description provided.