ninkch/SynchroFlow_AI

Fork 0

【S1W2 交叉评测】SynchroFlow AI 项目反馈 #1

New issue

Open

opened 2026-05-15 14:58:49 +08:00 by smartresearch2026 · 1 comment

smartresearch2026 commented

2026-05-15 14:58:49 +08:00

SynchroFlow_AI 交叉评测报告

评测日期：2026-05-15
项目：ninkch/SynchroFlow_AI
评测范围：全栈代码审查（后端 FastAPI + 前端 Next.js），含 API、Agent、Skill、知识图谱、前端页面与组件

1. 项目理解

SynchroFlow_AI 是一个面向制造业供应链的 AI 多智能体协同决策平台，核心目标是让五个领域 AI Agent（质量、设备、供应链、供应商、生产排程）并行监听业务事件，通过 Orchestrator 协调器进行冲突检测与决策编排，最终向用户输出联合决策方案。

技术架构：采用前后端分离架构——

后端：FastAPI + SQLAlchemy（async）+ PostgreSQL + Redis + LiteLLM，使用 Alembic 管理数据库迁移，通过 instructor 库实现结构化 LLM 输出。
前端：Next.js 14（App Router）+ TypeScript + Tailwind CSS + shadcn/ui，通过路由组 (app) 实现持久布局。
核心模块：5 个 Agent（各自挂载 2-4 个 Skill）、EventBus（Redis Streams）、Orchestrator（协调器）、KGQueryEngine（知识图谱查询）、Intent Detection（关键词意图路由）、Model Router（按任务复杂度选模型）。

当前状态：项目处于 V0.5→V1.0 演进期。后端已实现 28 个 API 端点（认证、数据 CRUD、对话 SSE、预警、报告、仪表盘），前端已实现 12 个页面路由（含 5 个 Agent 工作台 + 知识图谱页面）。团队已有清晰的 UPGRADE_PLAN 文档进行 Gap Analysis，并针对前端 Bug 有详细的修复方案。

2. 项目亮点

2.1 架构设计：以"协调编排"为核心的 Agent 系统

项目的最大亮点在于其 Orchestrator + EventBus + Agent 三件套架构：

Orchestrator.coordinate() 实现了完整的协同调度流水线：信号路由（按事件类型匹配主 Agent + 通知 Agent）→ 并行评估（asyncio.gather）→ 冲突检测（严重性不匹配检测）→ 决策编排（安全优先原则取最高风险方案）→ DB 持久化（coordination_results 表）。这在制造业供应链场景中非常实用——例如设备异常自动通知质量和生产 Agent 联合评估。
EventBus 基于 Redis Streams 实现了生产级的事件发布/订阅/ACK 机制，支持多租户隔离（key 格式 {tenant_id}:{stream}），消费者组模式可扩展性好。
COORDINATION_RULES 定义的五种事件类型路由规则（device_anomaly → 通知 quality+production，quality_exceedance → 通知 device+supplier+supply_chain 等）体现了对制造业业务链的深入理解。

2.2 前端 Agent 工作台：5 个业务页面已完整实现，UI 质量高

前端 5 个 Agent 工作台页面（/quality、/supply-chain、/device、/supplier、/production）均已用实际 API 调用和数据渲染实现，非空壳页面：

质量工作台：六维排除法、鱼骨图、5Why 追问、8D 报告四个分析工具全部对接 API，有完整的加载/空/错误状态处理。缺陷追溯时间线使用 CSS 伪元素实现竖线 + 圆点视觉，效果工整。
供应链工作台：库存概览表格（颜色标记缺料/偏低/正常）、智能操作区（生成预警信号、齐套检查对话框、采购建议）、供应商交付统计表格，三个模块均已接入真实 API。
设备监控工作台：设备卡片列表（利用率进度条、状态指示灯）、参数趋势条状图（手写 CSS）、阈值检查结果、趋势分析、维保提醒列表。
供应商管理工作台：分级概览（A/B/C/D 彩色卡片）、多维评分（四维度进度条 + 综合得分 + 等级标签）、来料异常表格、供应商档案详情（含质量趋势柱状图、近期订单表）、准入评估。
生产排程工作台：产能概览（设备利用率）、排产方案表格、急单评估表单（含受影响订单列表）、交付风险预警表格（逾期标记）。

每个页面都有 loading spinner、空数据占位、refresh 按钮，错误静默降级。这在同类项目中属于较高完成度。

2.3 知识图谱模块：时序/实体/因果链/搜索四维查询引擎

KGQueryEngine 实现了四种查询模式：

时序查询 (temporal_query)：按事件类型 + 时间范围过滤 KgEvent
实体关联查询 (entity_query)：BFS 遍历 KgRelation 表，支持 max_depth 控制，支持双向遍历（from/to）
因果链追溯 (causal_chain)：沿 CAUSES 关系向上游/下游追溯，支持 max_depth=5
语义搜索 (semantic_search)：基于 ILIKE 的标题/描述模糊匹配

前端知识图谱页面（/knowledge）以 Tab 切换方式完整展示了事件列表（分类型筛选）、因果链追溯（可视化时间线）、思维节点（展开/收起推理过程）、实体关系查询四个功能。因果链的可视化（左侧竖线 + 圆点 + 节点卡片）在纯 CSS 条件下效果不错。

2.4 自文档化：UPGRADE_PLAN 和 Bugfix 计划质量高

docs/UPGRADE_PLAN.md（629 行）是项目少见的优秀内部文档：

完整列出了 28 个已实现 API 端点 + 非 API 模块的当前状态（Agent 骨架、Skill 部分真实、Orchestrator 已实现等）
对 5 个 Agent 逐个进行了 Gap Analysis（功能项 vs 后端现状 vs Gap），表格清晰
跨模块联动、Skill/知识图谱/其他模块的差距也逐一分析
改造计划分 Phase 1（后端 API 补全，列出 30+ 新端点）和 Phase 2（前端 5 个 Agent 工作台 + 2 个辅助页面 + 组件增强），每个页面给出了布局草图

docs/superpowers/plans/2026-05-14-frontend-bugfix-plan.md 对 7 个问题进行了根因分析并给出了精确修复方案，展现团队有清晰的工程意识。

2.5 LLM 工程实践：结构化输出 + 模型路由 + 用量计费

通过 instructor 库实现 structured_complete() 函数，六维排除法 Prompt 输出直接解析为结构化 dict（含 dimensions、confidence、recommended_actions 等字段）
ModelRouter 按任务复杂度（chat/general、root_cause_analysis、quality_inspection 等）分派模型，支持租户级自定义
Token 用量追踪（token_usage 表）和配额管理完整

3. 当前不足

3.1 四个 Agent 的 analyze() 方法为骨架代码，无实际业务逻辑

这是项目当前最核心的短板。五个 Agent 中，仅 QualityAgent.analyze() 有真实实现（调用 SixDimensionSkill → LLM 分析），其余四个 Agent 的 analyze() 方法均返回空结果：

# SupplyChainAgent, ProductionAgent, DeviceAgent, SupplierAgent 的 analyze() 均如此
async def analyze(self, query, context):
    return AgentResult(
        agent_name=self.agent_name,
        summary=query,
        structured_output={},  # 空
        recommended_actions=[],  # 空
        data_gaps=[],           # 空
    )

这意味着用户在对话中提及供应链/设备/供应商/排产问题时，Agent 无法给出有意义的分析结果，只能依赖 BaseAgent.handle_chat() 中的通用 LLM 对话。五个 Agent 工作台虽然前端页面完整，但其背后的核心分析能力并未接通。

3.2 多个 Skill 为硬编码桩代码，未接入数据层

12 个 Skill 中存在明显的"两层"现象：质量方向的 4 个 Skill（six_dimension、fishbone、five_why、report_8d）经过 LLM 调用有真实输出；但以下 Skill 仍为纯硬编码：

Skill	当前实现	问题
`PurchaseSuggestionSkill`	对传入的 shortage_items 做简单数学（×1.2），不查 DB	无法从 inventory + materials 表自动发现缺料
`SchedulingSkill`	仅对传入 orders 按 deadline 排序	不查 DB，不分配设备，不考虑产能约束
`RushOrderAssessSkill`	硬编码返回 `can_accommodate: True`	永远返回"可以插入"，不评估真实影响
`ScoringCardSkill`	从传入 dict 中取值做加权计算	不从 quality_checks + purchase_orders 表读真实数据
`GradeManagerSkill`	简单阈值判断	不写入 supplier.rating 字段

BOMCheckSkill 和 ThresholdCheckSkill 是仅有的两个真正 DB 驱动的 Skill。

3.3 前端无专业图表库，可视化效果受限

所有"图表"实现均依赖手写 CSS（div 模拟条形图、进度条）。项目中已提到的 11 个组件（FishboneCard、AnalysisCard、MetricCard、QualityChart、SeverityBadge、AgentStatusBadge 等）虽然已定义但未被使用，说明已有组件库与页面之间存在脱节。具体问题：

Dashboard 页面引用了 QualityChart 但未实际渲染
鱼骨图组件（FishboneCard）当前为 2 列 grid 布局，未实现真正的鱼骨图形态
参数趋势图为简单的 div 条形图，无时间轴标注、阈值参考线、缩放等交互
供应商质量趋势使用 flex items-end 模拟柱状图，仅有 pass/fail 二值

3.4 信号触发入口缺失，无自动检测机制

整个 Orchestrator 协调链路虽然完整，但其入口——信号生成——仍然缺失：

没有后台定时任务扫描库存并自动生成 material_shortage 信号
没有设备参数变化监听自动触发 device_anomaly 信号
没有质检不合格自动触发 quality_exceedance 信号
当前只能通过前端按钮手动调用 API 生成预警（如供应链工作台的"生成预警信号"按钮）

backend/app/api/coordination.py 和 backend/app/api/agents_status.py 虽然在 UPGRADE_PLAN 中被规划为 Phase 1 任务，但目前两个文件内容极简，缺少实际的 API 端点实现。

3.5 后端 API 覆盖不完整，知识图谱查询无暴露

根据 UPGRADE_PLAN 的自查，当前缺失的 API 端点约 30+ 个，其中影响较大者：

知识图谱 API：KGQueryEngine 四种查询模式 + ThoughtService CRUD 均无 HTTP API 暴露。前端 /knowledge 页面虽然写了调用 /api/knowledge/events、/api/knowledge/thoughts 等端点，但这些端点当前很可能返回空或 404。
协调 API：/api/coordination/trigger（手动触发协调）、/api/coordination/results（历史结果）均未实现。
Agent 状态 API：/api/agents/status 用于 Dashboard 展示各 Agent 运行状态，未实现。
质量统计 API：/api/agents/quality/inspection-summary 和 /api/agents/quality/defect-trace/{batch_no} 规划中但未确认实现。
生产 API：/api/agents/production/schedule、/api/agents/production/rush-order-assess 等多为前端已调用但后端可能返回空或错误。

3.6 意图检测采用简单关键词匹配，缺乏语义理解

Intent Detection 模块 (core/intent.py) 使用硬编码的中文关键词表做匹配，统计命中次数决定路由。这在以下场景会失效：

用户说"最近出货不太顺利" → 不会匹配任何关键词 → 路由到 "general"，而不是 "supply_chain" + "production" 联合分析
无法区分"设备温度正常吗"和"设备最近有异常吗"的细微意图差异
不支持多 Agent 联合意图（复杂问题往往需要多 Agent 协同）

4. 建议

4.1 优先实现四个 Agent 的 analyze() 核心逻辑

优先级：P0，建议 1-2 周内完成。

这是项目从"Demo"走向"可用"的关键一步。具体建议：

SupplyChainAgent.analyze()：组合 BOMCheckSkill（已有 DB 查询）+ PurchaseSuggestionSkill（需改造为 DB 驱动），查询订单的 BOM 数据，对比库存，返回齐套状态和采购建议
DeviceAgent.analyze()：组合 ThresholdCheckSkill（已有 DB 查询）+ TrendAnalysisSkill（已有线性回归），先执行阈值检查，若超限则执行趋势分析预测
SupplierAgent.analyze()：改造 ScoringCardSkill 从 quality_checks + purchase_orders 表读取真实数据，计算质量分（合格率）、交期分（准时率），输出评分卡
ProductionAgent.analyze()：改造 SchedulingSkill 从 production_orders + devices 表读取订单和设备，按交期排序后分配设备

改造后，用户在 Chat 中提及设备参数超标时，detect_intent 路由到 device Agent，handle_chat 调用 analyze() 返回真实分析结果，而非现在的空 structured_output。

4.2 安装图表库并激活现有组件

优先级：P1，建议 3-5 天。

安装 Recharts（npm install recharts），替换以下手写 CSS 图表：
- Dashboard QualityChart：折线图展示质量趋势
- Device 参数趋势：折线图 + 阈值参考线（ReferenceLine）
- Supplier 评分：RadarChart 雷达图展示四维评分
- Production 产能利用率：柱状图
激活 FishboneCard 组件：使用 CSS Grid 实现真正的鱼骨图布局（中央脊柱 + 六大分支斜线 + 原因节点）
将 SeverityBadge 和 AgentStatusBadge 组件集成到预警列表和 Dashboard Agent 卡片中

4.3 增加后台定时任务实现自动信号检测

优先级：P1，建议 1 周。

建议使用 APScheduler 或简单的 asyncio 定时任务：

# 伪代码示例
async def scan_inventory_alerts(db):
    """每 5 分钟扫描库存，低于安全库存时生成 RiskSignal"""
    shortages = await db.execute(
        select(material).where(material.quantity < material.safety_stock)
    )
    for item in shortages:
        signal = RiskSignal(event_type="material_shortage", severity="high", ...)
        await orchestrator.coordinate(signal, db)

同理实现设备参数阈值自动扫描、质检不合格自动触发等。这将使 Orchestrator 协调链路形成真正的闭环：数据变化 → 信号生成 → 多 Agent 并行评估 → 冲突检测 → 决策方案 → 用户确认。

4.4 补齐后端 API 端点，特别是知识图谱和协调 API

优先级：P1，建议 1-2 周。

按 UPGRADE_PLAN Phase 1 的规划，优先实现以下端点：

知识图谱 API（/api/knowledge/*）：暴露 KGQueryEngine 的四种查询 + ThoughtService CRUD，使前端 /knowledge 页面正常工作
协调 API（/api/coordination/*）：手动触发 + 历史查询 + 决策确认
Agent 状态 API（/api/agents/status）：用于 Dashboard 展示 Agent 健康状态
质量统计 API：质检汇总、缺陷追溯

4.5 升级意图检测为 LLM-based 语义路由

优先级：P2，可作为 V2.0 特性。

当前关键词匹配虽然快速但缺乏灵活性。建议在保留关键词匹配作为 fallback 的前提下，增加 LLM-based 意图分类：

async def detect_intent_v2(message: str) -> list[str]:
    """返回相关 Agent 列表，支持多 Agent 联合"""
    prompt = f"用户问题：{message}\n判断涉及哪些领域：quality/device/supply_chain/supplier/production"
    result = await structured_complete(model="deepseek-chat", messages=prompt, response_model=list[str])
    return result or ["general"]

4.6 补充自动化测试覆盖

优先级：P2。

虽然项目有较完整的测试目录结构（7 个测试子模块），但建议为关键路径增加集成测试：

Orchestrator 协调全链路测试（模拟信号 → 多 Agent 评估 → 冲突检测 → DB 存储）
Agent analyze() 端到端测试（含 Mock LLM 响应）
Skill 数据驱动测试（含真实 SQLite 测试数据库）

5. 综合评价

总体评分：7.2 / 10

维度	评分	说明
架构设计	9.0	Orchestrator + EventBus + Agent 注册表 + Skill 注册表的可插拔架构设计优秀，多租户隔离完善
后端实现完整度	6.0	数据模型、认证、文件导入、对话 SSE 扎实；但 4/5 Agent 核心逻辑为骨架代码，12 个 Skill 中 5 个为硬编码桩，约 30+ API 端点缺失
前端实现完整度	7.5	5 个 Agent 工作台 + 知识图谱页面均已实现，UI 整洁有设计感；但缺少专业图表库，11 个组件未激活，报告渲染为 JSON
代码质量	7.0	类型标注使用良好（Python type hints + TypeScript），错误处理到位；部分 Skill 硬编码返回假数据，agent analyze() 空实现
文档与自省	9.0	UPGRADE_PLAN 是罕见的高质量内部文档，Gap Analysis 精准，改造方案具体可执行；Bugfix 计划有根因分析
测试覆盖	6.5	测试目录结构完整（7 个子模块 30+ 测试文件），但实际测试内容深度有限
AI 工程实践	7.5	instructor 结构化输出、LiteLLM 多模型、Token 计费、SSE 流式对话均实现良好；但意图检测仍为关键词匹配，知识图谱"语义搜索"仅 ILIKE

核心判断

SynchroFlow_AI 的架构底子非常扎实——Orchestrator 协调器、EventBus 事件总线、可插拔 Skill 机制、知识图谱查询引擎这些基础设施都已到位。项目展现了对制造业供应链领域知识的深入理解（五个 Agent 的协作规则设计合理），前端 5 个工作台的页面布局也体现了产品思维。

当前最大的问题是 "骨架完整，血肉不足"：4 个 Agent 的 analyze() 为空实现，5 个 Skill 为硬编码返回，信号触发入口缺失，知识图谱 API 未暴露。这导致系统虽然能"跑起来"，但在实际业务场景中无法产出有意义的分析结果。

好消息是团队已通过 UPGRADE_PLAN 清晰识别了这些差距，改造方案具体可行。如果在 2-3 周内补齐 Phase 1（后端 API 补全 + Skill 接入 DB + 自动信号检测），项目质量可跃升至 8.5 分以上，具备实际的 Demo 和 PoC 展示能力。

一句话总结

架构思路清晰、自省能力出色的 AI 供应链平台，基础设施就绪，正处于从"Demo 骨架"向"可用产品"冲刺的关键阶段。

# SynchroFlow_AI 交叉评测报告 > 评测日期：2026-05-15 > 项目：ninkch/SynchroFlow_AI > 评测范围：全栈代码审查（后端 FastAPI + 前端 Next.js），含 API、Agent、Skill、知识图谱、前端页面与组件 --- ## 1. 项目理解 SynchroFlow_AI 是一个面向制造业供应链的 **AI 多智能体协同决策平台**，核心目标是让五个领域 AI Agent（质量、设备、供应链、供应商、生产排程）并行监听业务事件，通过 Orchestrator 协调器进行冲突检测与决策编排，最终向用户输出联合决策方案。 **技术架构**：采用前后端分离架构—— - **后端**：FastAPI + SQLAlchemy（async）+ PostgreSQL + Redis + LiteLLM，使用 Alembic 管理数据库迁移，通过 instructor 库实现结构化 LLM 输出。 - **前端**：Next.js 14（App Router）+ TypeScript + Tailwind CSS + shadcn/ui，通过路由组 `(app)` 实现持久布局。 - **核心模块**：5 个 Agent（各自挂载 2-4 个 Skill）、EventBus（Redis Streams）、Orchestrator（协调器）、KGQueryEngine（知识图谱查询）、Intent Detection（关键词意图路由）、Model Router（按任务复杂度选模型）。 **当前状态**：项目处于 V0.5→V1.0 演进期。后端已实现 28 个 API 端点（认证、数据 CRUD、对话 SSE、预警、报告、仪表盘），前端已实现 12 个页面路由（含 5 个 Agent 工作台 + 知识图谱页面）。团队已有清晰的 UPGRADE_PLAN 文档进行 Gap Analysis，并针对前端 Bug 有详细的修复方案。 --- ## 2. 项目亮点 ### 2.1 架构设计：以"协调编排"为核心的 Agent 系统项目的最大亮点在于其 **Orchestrator + EventBus + Agent 三件套**架构： - `Orchestrator.coordinate()` 实现了完整的协同调度流水线：**信号路由（按事件类型匹配主 Agent + 通知 Agent）→ 并行评估（asyncio.gather）→ 冲突检测（严重性不匹配检测）→ 决策编排（安全优先原则取最高风险方案）→ DB 持久化（coordination_results 表）**。这在制造业供应链场景中非常实用——例如设备异常自动通知质量和生产 Agent 联合评估。 - `EventBus` 基于 Redis Streams 实现了生产级的事件发布/订阅/ACK 机制，支持多租户隔离（key 格式 `{tenant_id}:{stream}`），消费者组模式可扩展性好。 - `COORDINATION_RULES` 定义的五种事件类型路由规则（device_anomaly → 通知 quality+production，quality_exceedance → 通知 device+supplier+supply_chain 等）体现了对制造业业务链的深入理解。 ### 2.2 前端 Agent 工作台：5 个业务页面已完整实现，UI 质量高前端 5 个 Agent 工作台页面（`/quality`、`/supply-chain`、`/device`、`/supplier`、`/production`）均已用实际 API 调用和数据渲染实现，非空壳页面： - **质量工作台**：六维排除法、鱼骨图、5Why 追问、8D 报告四个分析工具全部对接 API，有完整的加载/空/错误状态处理。缺陷追溯时间线使用 CSS 伪元素实现竖线 + 圆点视觉，效果工整。 - **供应链工作台**：库存概览表格（颜色标记缺料/偏低/正常）、智能操作区（生成预警信号、齐套检查对话框、采购建议）、供应商交付统计表格，三个模块均已接入真实 API。 - **设备监控工作台**：设备卡片列表（利用率进度条、状态指示灯）、参数趋势条状图（手写 CSS）、阈值检查结果、趋势分析、维保提醒列表。 - **供应商管理工作台**：分级概览（A/B/C/D 彩色卡片）、多维评分（四维度进度条 + 综合得分 + 等级标签）、来料异常表格、供应商档案详情（含质量趋势柱状图、近期订单表）、准入评估。 - **生产排程工作台**：产能概览（设备利用率）、排产方案表格、急单评估表单（含受影响订单列表）、交付风险预警表格（逾期标记）。每个页面都有 loading spinner、空数据占位、refresh 按钮，错误静默降级。这在同类项目中属于较高完成度。 ### 2.3 知识图谱模块：时序/实体/因果链/搜索四维查询引擎 `KGQueryEngine` 实现了四种查询模式： - **时序查询** (`temporal_query`)：按事件类型 + 时间范围过滤 KgEvent - **实体关联查询** (`entity_query`)：BFS 遍历 KgRelation 表，支持 max_depth 控制，支持双向遍历（from/to） - **因果链追溯** (`causal_chain`)：沿 `CAUSES` 关系向上游/下游追溯，支持 max_depth=5 - **语义搜索** (`semantic_search`)：基于 ILIKE 的标题/描述模糊匹配前端知识图谱页面（`/knowledge`）以 Tab 切换方式完整展示了事件列表（分类型筛选）、因果链追溯（可视化时间线）、思维节点（展开/收起推理过程）、实体关系查询四个功能。因果链的可视化（左侧竖线 + 圆点 + 节点卡片）在纯 CSS 条件下效果不错。 ### 2.4 自文档化：UPGRADE_PLAN 和 Bugfix 计划质量高 `docs/UPGRADE_PLAN.md`（629 行）是项目少见的优秀内部文档： - 完整列出了 28 个已实现 API 端点 + 非 API 模块的当前状态（Agent 骨架、Skill 部分真实、Orchestrator 已实现等） - 对 5 个 Agent 逐个进行了 Gap Analysis（功能项 vs 后端现状 vs Gap），表格清晰 - 跨模块联动、Skill/知识图谱/其他模块的差距也逐一分析 - 改造计划分 Phase 1（后端 API 补全，列出 30+ 新端点）和 Phase 2（前端 5 个 Agent 工作台 + 2 个辅助页面 + 组件增强），每个页面给出了布局草图 `docs/superpowers/plans/2026-05-14-frontend-bugfix-plan.md` 对 7 个问题进行了根因分析并给出了精确修复方案，展现团队有清晰的工程意识。 ### 2.5 LLM 工程实践：结构化输出 + 模型路由 + 用量计费 - 通过 `instructor` 库实现 `structured_complete()` 函数，六维排除法 Prompt 输出直接解析为结构化 dict（含 dimensions、confidence、recommended_actions 等字段） - `ModelRouter` 按任务复杂度（chat/general、root_cause_analysis、quality_inspection 等）分派模型，支持租户级自定义 - Token 用量追踪（`token_usage` 表）和配额管理完整 --- ## 3. 当前不足 ### 3.1 四个 Agent 的 analyze() 方法为骨架代码，无实际业务逻辑这是项目当前最核心的短板。五个 Agent 中，仅 `QualityAgent.analyze()` 有真实实现（调用 SixDimensionSkill → LLM 分析），其余四个 Agent 的 `analyze()` 方法均返回空结果： ```python # SupplyChainAgent, ProductionAgent, DeviceAgent, SupplierAgent 的 analyze() 均如此 async def analyze(self, query, context): return AgentResult( agent_name=self.agent_name, summary=query, structured_output={}, # 空 recommended_actions=[], # 空 data_gaps=[], # 空 ) ``` 这意味着用户在对话中提及供应链/设备/供应商/排产问题时，Agent 无法给出有意义的分析结果，只能依赖 `BaseAgent.handle_chat()` 中的通用 LLM 对话。五个 Agent 工作台虽然前端页面完整，但其背后的核心分析能力并未接通。 ### 3.2 多个 Skill 为硬编码桩代码，未接入数据层 12 个 Skill 中存在明显的"两层"现象：质量方向的 4 个 Skill（six_dimension、fishbone、five_why、report_8d）经过 LLM 调用有真实输出；但以下 Skill 仍为纯硬编码： | Skill | 当前实现 | 问题 | |-------|---------|------| | `PurchaseSuggestionSkill` | 对传入的 shortage_items 做简单数学（×1.2），不查 DB | 无法从 inventory + materials 表自动发现缺料 | | `SchedulingSkill` | 仅对传入 orders 按 deadline 排序 | 不查 DB，不分配设备，不考虑产能约束 | | `RushOrderAssessSkill` | 硬编码返回 `can_accommodate: True` | 永远返回"可以插入"，不评估真实影响 | | `ScoringCardSkill` | 从传入 dict 中取值做加权计算 | 不从 quality_checks + purchase_orders 表读真实数据 | | `GradeManagerSkill` | 简单阈值判断 | 不写入 supplier.rating 字段 | BOMCheckSkill 和 ThresholdCheckSkill 是仅有的两个真正 DB 驱动的 Skill。 ### 3.3 前端无专业图表库，可视化效果受限所有"图表"实现均依赖手写 CSS（div 模拟条形图、进度条）。项目中已提到的 11 个组件（FishboneCard、AnalysisCard、MetricCard、QualityChart、SeverityBadge、AgentStatusBadge 等）虽然已定义但未被使用，说明已有组件库与页面之间存在脱节。具体问题： - Dashboard 页面引用了 `QualityChart` 但未实际渲染 - 鱼骨图组件（FishboneCard）当前为 2 列 grid 布局，未实现真正的鱼骨图形态 - 参数趋势图为简单的 div 条形图，无时间轴标注、阈值参考线、缩放等交互 - 供应商质量趋势使用 `flex items-end` 模拟柱状图，仅有 pass/fail 二值 ### 3.4 信号触发入口缺失，无自动检测机制整个 Orchestrator 协调链路虽然完整，但其入口——信号生成——仍然缺失： - 没有后台定时任务扫描库存并自动生成 `material_shortage` 信号 - 没有设备参数变化监听自动触发 `device_anomaly` 信号 - 没有质检不合格自动触发 `quality_exceedance` 信号 - 当前只能通过前端按钮手动调用 API 生成预警（如供应链工作台的"生成预警信号"按钮） `backend/app/api/coordination.py` 和 `backend/app/api/agents_status.py` 虽然在 UPGRADE_PLAN 中被规划为 Phase 1 任务，但目前两个文件内容极简，缺少实际的 API 端点实现。 ### 3.5 后端 API 覆盖不完整，知识图谱查询无暴露根据 UPGRADE_PLAN 的自查，当前缺失的 API 端点约 30+ 个，其中影响较大者： - **知识图谱 API**：`KGQueryEngine` 四种查询模式 + `ThoughtService` CRUD 均无 HTTP API 暴露。前端 `/knowledge` 页面虽然写了调用 `/api/knowledge/events`、`/api/knowledge/thoughts` 等端点，但这些端点当前很可能返回空或 404。 - **协调 API**：`/api/coordination/trigger`（手动触发协调）、`/api/coordination/results`（历史结果）均未实现。 - **Agent 状态 API**：`/api/agents/status` 用于 Dashboard 展示各 Agent 运行状态，未实现。 - **质量统计 API**：`/api/agents/quality/inspection-summary` 和 `/api/agents/quality/defect-trace/{batch_no}` 规划中但未确认实现。 - **生产 API**：`/api/agents/production/schedule`、`/api/agents/production/rush-order-assess` 等多为前端已调用但后端可能返回空或错误。 ### 3.6 意图检测采用简单关键词匹配，缺乏语义理解 `Intent Detection` 模块 (`core/intent.py`) 使用硬编码的中文关键词表做匹配，统计命中次数决定路由。这在以下场景会失效： - 用户说"最近出货不太顺利" → 不会匹配任何关键词 → 路由到 "general"，而不是 "supply_chain" + "production" 联合分析 - 无法区分"设备温度正常吗"和"设备最近有异常吗"的细微意图差异 - 不支持多 Agent 联合意图（复杂问题往往需要多 Agent 协同） --- ## 4. 建议 ### 4.1 优先实现四个 Agent 的 analyze() 核心逻辑 **优先级：P0，建议 1-2 周内完成。** 这是项目从"Demo"走向"可用"的关键一步。具体建议： - **SupplyChainAgent.analyze()**：组合 BOMCheckSkill（已有 DB 查询）+ PurchaseSuggestionSkill（需改造为 DB 驱动），查询订单的 BOM 数据，对比库存，返回齐套状态和采购建议 - **DeviceAgent.analyze()**：组合 ThresholdCheckSkill（已有 DB 查询）+ TrendAnalysisSkill（已有线性回归），先执行阈值检查，若超限则执行趋势分析预测 - **SupplierAgent.analyze()**：改造 ScoringCardSkill 从 quality_checks + purchase_orders 表读取真实数据，计算质量分（合格率）、交期分（准时率），输出评分卡 - **ProductionAgent.analyze()**：改造 SchedulingSkill 从 production_orders + devices 表读取订单和设备，按交期排序后分配设备改造后，用户在 Chat 中提及设备参数超标时，`detect_intent` 路由到 `device` Agent，`handle_chat` 调用 `analyze()` 返回真实分析结果，而非现在的空 `structured_output`。 ### 4.2 安装图表库并激活现有组件 **优先级：P1，建议 3-5 天。** - 安装 Recharts（`npm install recharts`），替换以下手写 CSS 图表： - Dashboard `QualityChart`：折线图展示质量趋势 - Device 参数趋势：折线图 + 阈值参考线（`ReferenceLine`） - Supplier 评分：RadarChart 雷达图展示四维评分 - Production 产能利用率：柱状图 - 激活 `FishboneCard` 组件：使用 CSS Grid 实现真正的鱼骨图布局（中央脊柱 + 六大分支斜线 + 原因节点） - 将 `SeverityBadge` 和 `AgentStatusBadge` 组件集成到预警列表和 Dashboard Agent 卡片中 ### 4.3 增加后台定时任务实现自动信号检测 **优先级：P1，建议 1 周。** 建议使用 APScheduler 或简单的 asyncio 定时任务： ```python # 伪代码示例 async def scan_inventory_alerts(db): """每 5 分钟扫描库存，低于安全库存时生成 RiskSignal""" shortages = await db.execute( select(material).where(material.quantity < material.safety_stock) ) for item in shortages: signal = RiskSignal(event_type="material_shortage", severity="high", ...) await orchestrator.coordinate(signal, db) ``` 同理实现设备参数阈值自动扫描、质检不合格自动触发等。这将使 Orchestrator 协调链路形成真正的闭环：**数据变化 → 信号生成 → 多 Agent 并行评估 → 冲突检测 → 决策方案 → 用户确认**。 ### 4.4 补齐后端 API 端点，特别是知识图谱和协调 API **优先级：P1，建议 1-2 周。** 按 UPGRADE_PLAN Phase 1 的规划，优先实现以下端点： - **知识图谱 API**（`/api/knowledge/*`）：暴露 `KGQueryEngine` 的四种查询 + `ThoughtService` CRUD，使前端 `/knowledge` 页面正常工作 - **协调 API**（`/api/coordination/*`）：手动触发 + 历史查询 + 决策确认 - **Agent 状态 API**（`/api/agents/status`）：用于 Dashboard 展示 Agent 健康状态 - **质量统计 API**：质检汇总、缺陷追溯 ### 4.5 升级意图检测为 LLM-based 语义路由 **优先级：P2，可作为 V2.0 特性。** 当前关键词匹配虽然快速但缺乏灵活性。建议在保留关键词匹配作为 fallback 的前提下，增加 LLM-based 意图分类： ```python async def detect_intent_v2(message: str) -> list[str]: """返回相关 Agent 列表，支持多 Agent 联合""" prompt = f"用户问题：{message}\n判断涉及哪些领域：quality/device/supply_chain/supplier/production" result = await structured_complete(model="deepseek-chat", messages=prompt, response_model=list[str]) return result or ["general"] ``` ### 4.6 补充自动化测试覆盖 **优先级：P2。** 虽然项目有较完整的测试目录结构（7 个测试子模块），但建议为关键路径增加集成测试： - Orchestrator 协调全链路测试（模拟信号 → 多 Agent 评估 → 冲突检测 → DB 存储） - Agent analyze() 端到端测试（含 Mock LLM 响应） - Skill 数据驱动测试（含真实 SQLite 测试数据库） --- ## 5. 综合评价 ### 总体评分：7.2 / 10 | 维度 | 评分 | 说明 | |------|------|------| | 架构设计 | 9.0 | Orchestrator + EventBus + Agent 注册表 + Skill 注册表的可插拔架构设计优秀，多租户隔离完善 | | 后端实现完整度 | 6.0 | 数据模型、认证、文件导入、对话 SSE 扎实；但 4/5 Agent 核心逻辑为骨架代码，12 个 Skill 中 5 个为硬编码桩，约 30+ API 端点缺失 | | 前端实现完整度 | 7.5 | 5 个 Agent 工作台 + 知识图谱页面均已实现，UI 整洁有设计感；但缺少专业图表库，11 个组件未激活，报告渲染为 JSON | | 代码质量 | 7.0 | 类型标注使用良好（Python type hints + TypeScript），错误处理到位；部分 Skill 硬编码返回假数据，agent analyze() 空实现 | | 文档与自省 | 9.0 | UPGRADE_PLAN 是罕见的高质量内部文档，Gap Analysis 精准，改造方案具体可执行；Bugfix 计划有根因分析 | | 测试覆盖 | 6.5 | 测试目录结构完整（7 个子模块 30+ 测试文件），但实际测试内容深度有限 | | AI 工程实践 | 7.5 | instructor 结构化输出、LiteLLM 多模型、Token 计费、SSE 流式对话均实现良好；但意图检测仍为关键词匹配，知识图谱"语义搜索"仅 ILIKE | ### 核心判断 SynchroFlow_AI 的**架构底子非常扎实**——Orchestrator 协调器、EventBus 事件总线、可插拔 Skill 机制、知识图谱查询引擎这些基础设施都已到位。项目展现了对制造业供应链领域知识的深入理解（五个 Agent 的协作规则设计合理），前端 5 个工作台的页面布局也体现了产品思维。当前最大的问题是 **"骨架完整，血肉不足"**：4 个 Agent 的 `analyze()` 为空实现，5 个 Skill 为硬编码返回，信号触发入口缺失，知识图谱 API 未暴露。这导致系统虽然能"跑起来"，但在实际业务场景中无法产出有意义的分析结果。好消息是团队已通过 UPGRADE_PLAN 清晰识别了这些差距，改造方案具体可行。如果在 2-3 周内补齐 Phase 1（后端 API 补全 + Skill 接入 DB + 自动信号检测），项目质量可跃升至 8.5 分以上，具备实际的 Demo 和 PoC 展示能力。 ### 一句话总结 > **架构思路清晰、自省能力出色的 AI 供应链平台，基础设施就绪，正处于从"Demo 骨架"向"可用产品"冲刺的关键阶段。**

ninkch commented

2026-05-15 17:59:42 +08:00

Owner

评测回复

回复日期：2026-05-15
回复对象：《SynchroFlow_AI 交叉评测报告》
版本基准：commit 9b9023c

修复前后对比总结

报告问题	修复前	修复后	状态
§3.1 四Agent analyze()空实现	返回空AgentResult	全部DB驱动，链式调Skill，含pending_actions	✅ 已修复
§3.2 五Skill硬编码桩	返回假数据/固定值	全部查DB真实数据计算	✅ 已修复
§3.3 无专业图表库	手写CSS div	手写CSS div（未变）	❌ P0 待修复/计划中
§3.4 信号触发入口缺失	无自动检测	SSE推送+协调API完整，缺定时扫描	⚠️ P0 待补齐/计划中
§3.5 后端API覆盖不完整	约30+端点缺失	知识图谱+协调+Agent状态API已补齐，缺4个	⚠️ P1 待补齐/计划中
§3.6 意图检测简单匹配	关键词计数	加权关键词+偏见词消歧	⚠️ P1 LLM语义升级/计划中
§4.6 测试覆盖不足	测试深度有限	同上	⚠️ P1 待补齐/计划中

核心判断：报告指出的两大核心短板（§3.1 Agent空实现 + §3.2 Skill硬编码）已完全修复，系统从"骨架完整、血肉不足"升级为"骨架+核心业务逻辑均已接通"。剩余P0项（图表库+定时扫描）和P1项（LLM意图+测试+API端点）预计3-4天内全部补齐。

一、已修复问题

1.1 四个 Agent 的 analyze() 方法——从骨架到真实业务逻辑（§3.1）

修复前：四个 Agent 的 analyze() 均返回空 AgentResult，用户对话时无法产出有意义的分析结果。

修复策略：采用统一的"查DB实体→链式调Skill→聚合AgentResult"模式，每个Agent读取真实业务数据，调用自身挂载的Skill，产出包含结构化输出、建议操作和待确认动作的完整分析结果。

SupplyChainAgent：查生产订单→对每个订单调BOMCheckSkill（查BOM+库存对比）→若缺料则调PurchaseSuggestionSkill（查供应商+历史采购周期）→产出BOM齐套状态、缺料详情、采购建议，缺料时生成create_purchase_orders待确认动作。

DeviceAgent：查设备列表→对每台调ThresholdCheckSkill（查参数+标准对比）→超限时调TrendAnalysisSkill（近30条记录线性回归）→产出超限告警和趋势预测，异常趋势时生成emit_signal待确认动作。

SupplierAgent：查供应商列表→对每个调ScoringCardSkill（查quality_checks合格率+purchase_orders准时率+市场均价比较+近90天失败次数）→四维加权评分（质量40%+交期30%+价格20%+服务10%）→等级变化时调GradeManagerSkill写回DB→产出评分卡和评级变更建议。

ProductionAgent：查未完成订单+运行中设备→调SchedulingSkill（按优先级+交期排序，贪心分配设备，检测瓶颈）→未分配订单生成assign_device待确认动作→产出排产方案、设备利用率、瓶颈预警。

Chat流程集成：detect_intent()路由到对应Agent后调用analyze()，将结构化数据注入LLM system prompt，让LLM基于真实数据回答；analyze失败时降级为纯LLM回复；pending_actions通过SSE推送前端可确认。

1.2 五个 Skill 从硬编码桩升级为 DB 驱动（§3.2）

修复前：五个Skill返回假数据或固定值，不查DB。

PurchaseSuggestionSkill：从"shortage×1.2"升级为查purchase_orders+suppliers+materials三表JOIN，按物料名查历史供应商，返回评级/平均交期/最低价，推荐最优供应商。

SchedulingSkill：从"仅按deadline排序"升级为从DB查订单+设备，双键排序（优先级DESC+交期ASC），贪心负载均衡分配设备，检测瓶颈设备（负载>均值1.5倍）。

RushOrderAssessSkill：从"永远返回can_accommodate=True"升级为查devices算真实产能利用率，查生产订单列受影响订单，利用率>85%或急单量>总产能30%时判定不可插入。

ScoringCardSkill：从"传入dict取值"升级为查quality_checks算合格率（质量分）、查purchase_orders算准时率+均价+市场均价比较（价格分）、查近90天失败次数（服务分），四维加权→总分→等级。

GradeManagerSkill：从"简单阈值不写回"升级为等级变化时UPDATE suppliers.grade写回数据库并commit。

1.3 意图检测升级为加权匹配（§3.6 部分）

修复前：硬编码中文关键词表做简单计数匹配，无法消歧。

修复方案：

加权关键词：每个关键词带权重（1.0-2.0），专业术语权重更高
偏见词消歧：为每个Agent定义强特征词，匹配到时+3.0分，解决"交期"同时匹配多Agent的问题
单Agent短路：只匹配到一个Agent时直接返回，不走消歧

1.4 协调API和知识图谱API已补齐（§3.5 部分）

修复前：协调API和知识图谱API缺失，前端调用返回空或404。

已实现端点：

模块	端点
协调触发	POST /api/coordination/trigger
协调结果列表	GET /api/coordination/results
协调结果详情	GET /api/coordination/results/{id}
协调审批	PUT /api/coordination/results/{id}/approve
知识图谱-事件	GET /api/knowledge/events
知识图谱-实体关系	GET /api/knowledge/entity/{id}/relations
知识图谱-因果链	GET /api/knowledge/causal-chain/{id}
知识图谱-搜索	GET /api/knowledge/search
知识图谱-思维	GET /api/knowledge/thoughts, /thoughts/{id}
Agent状态	GET /api/agents/status
Agent技能	GET /api/agents/{name}/skills

1.5 PendingAction SSE推送机制（§3.4 部分）

新增PendingAction模型，Agent分析结果可携带待确认操作，通过SSE actions事件推前端：

create_purchase_orders：BOM不齐套时建议创建采购单
emit_signal：设备参数异常趋势时推送预警信号
assign_device：排产时建议将订单分配到设备

1.6 后续优化方向

当前Agent和Skill已全部接入真实数据层，后续还会针对生产落地持续优化：完善边界条件处理、增加异常数据容错、优化SQL查询性能、增强Agent间的联动决策深度等。

二、待修复问题及规划

P0 — 前端图表可视化（§3.3）

问题：所有图表为手写CSS（div模拟条形图），11个已定义组件未激活。

规划：

安装Recharts，替换手写CSS图表
Dashboard质量趋势→LineChart，设备参数趋势→折线图+阈值参考线
供应商评分→RadarChart四维雷达图，产能利用率→BarChart
激活FishboneCard鱼骨图布局、SeverityBadge/AgentStatusBadge组件

预计工期：1-2天

P0 — 后台定时任务自动信号检测（§3.4）

问题：Orchestrator协调链路完整，但信号触发入口缺失，无自动检测机制。

规划：

基于APScheduler注册三个异步扫描任务
scan_inventory_alerts：每5分钟扫描inventory，低于安全库存→生成material_shortage信号→调orchestrator.coordinate
scan_device_anomalies：每3分钟扫描device_params，超阈值→生成device_anomaly信号
scan_quality_exceedance：每10分钟扫描quality_checks，不合格率突增→生成quality_exceedance信号
app/main.py startup启动scheduler，添加手动触发调试端点

预计工期：1天

P1 — 意图检测升级为LLM语义路由（§3.6）

问题：加权关键词+偏见词无法理解"最近出货不太顺利"等模糊表述，不支持多Agent联合意图。

规划：

关键词匹配作为fast path，置信度>阈值直接返回
置信度不足时调用LLM做意图分类，支持多Agent联合返回
保留关键词匹配为可测试的fallback

预计工期：0.5天

P1 — 自动化测试覆盖（§4.6）

问题：7个DB驱动Skill和4个Agent analyze()缺少集成测试。

规划：

Skill数据驱动测试：模拟DB数据验证评分计算、排产逻辑、急单判定、等级写回
Agent analyze()端到端测试：Mock DB验证AgentResult字段完整性
Orchestrator协调全链路测试：模拟信号→多Agent评估→冲突检测→DB存储
dependency_overrides必须save/restore

预计工期：1天

P1 — 补充API端点

问题：仍缺4个端点。

规划：

端点	用途
GET /api/agents/quality/inspection-summary	质检统计汇总
GET /api/agents/quality/defect-trace/{batch_no}	缺陷追溯
POST /api/agents/production/rush-order-assess	急单评估API
GET /api/coordination/scan	手动触发扫描

预计工期：0.5天

# 评测回复 > 回复日期：2026-05-15 > 回复对象：《SynchroFlow_AI 交叉评测报告》 > 版本基准：commit `9b9023c` --- ## 修复前后对比总结 | 报告问题 | 修复前 | 修复后 | 状态 | |----------|--------|--------|------| | §3.1 四Agent analyze()空实现 | 返回空AgentResult | 全部DB驱动，链式调Skill，含pending_actions | ✅ 已修复 | | §3.2 五Skill硬编码桩 | 返回假数据/固定值 | 全部查DB真实数据计算 | ✅ 已修复 | | §3.3 无专业图表库 | 手写CSS div | 手写CSS div（未变） | ❌ P0 待修复/计划中 | | §3.4 信号触发入口缺失 | 无自动检测 | SSE推送+协调API完整，缺定时扫描 | ⚠️ P0 待补齐/计划中 | | §3.5 后端API覆盖不完整 | 约30+端点缺失 | 知识图谱+协调+Agent状态API已补齐，缺4个 | ⚠️ P1 待补齐/计划中 | | §3.6 意图检测简单匹配 | 关键词计数 | 加权关键词+偏见词消歧 | ⚠️ P1 LLM语义升级/计划中 | | §4.6 测试覆盖不足 | 测试深度有限 | 同上 | ⚠️ P1 待补齐/计划中 | **核心判断**：报告指出的两大核心短板（§3.1 Agent空实现 + §3.2 Skill硬编码）已完全修复，系统从"骨架完整、血肉不足"升级为"骨架+核心业务逻辑均已接通"。剩余P0项（图表库+定时扫描）和P1项（LLM意图+测试+API端点）预计3-4天内全部补齐。 --- ## 一、已修复问题 ### 1.1 四个 Agent 的 analyze() 方法——从骨架到真实业务逻辑（§3.1） **修复前**：四个 Agent 的 `analyze()` 均返回空 `AgentResult`，用户对话时无法产出有意义的分析结果。 **修复策略**：采用统一的"查DB实体→链式调Skill→聚合AgentResult"模式，每个Agent读取真实业务数据，调用自身挂载的Skill，产出包含结构化输出、建议操作和待确认动作的完整分析结果。 **SupplyChainAgent**：查生产订单→对每个订单调BOMCheckSkill（查BOM+库存对比）→若缺料则调PurchaseSuggestionSkill（查供应商+历史采购周期）→产出BOM齐套状态、缺料详情、采购建议，缺料时生成`create_purchase_orders`待确认动作。 **DeviceAgent**：查设备列表→对每台调ThresholdCheckSkill（查参数+标准对比）→超限时调TrendAnalysisSkill（近30条记录线性回归）→产出超限告警和趋势预测，异常趋势时生成`emit_signal`待确认动作。 **SupplierAgent**：查供应商列表→对每个调ScoringCardSkill（查quality_checks合格率+purchase_orders准时率+市场均价比较+近90天失败次数）→四维加权评分（质量40%+交期30%+价格20%+服务10%）→等级变化时调GradeManagerSkill写回DB→产出评分卡和评级变更建议。 **ProductionAgent**：查未完成订单+运行中设备→调SchedulingSkill（按优先级+交期排序，贪心分配设备，检测瓶颈）→未分配订单生成`assign_device`待确认动作→产出排产方案、设备利用率、瓶颈预警。 **Chat流程集成**：`detect_intent()`路由到对应Agent后调用`analyze()`，将结构化数据注入LLM system prompt，让LLM基于真实数据回答；analyze失败时降级为纯LLM回复；pending_actions通过SSE推送前端可确认。 --- ### 1.2 五个 Skill 从硬编码桩升级为 DB 驱动（§3.2） **修复前**：五个Skill返回假数据或固定值，不查DB。 **PurchaseSuggestionSkill**：从"shortage×1.2"升级为查purchase_orders+suppliers+materials三表JOIN，按物料名查历史供应商，返回评级/平均交期/最低价，推荐最优供应商。 **SchedulingSkill**：从"仅按deadline排序"升级为从DB查订单+设备，双键排序（优先级DESC+交期ASC），贪心负载均衡分配设备，检测瓶颈设备（负载>均值1.5倍）。 **RushOrderAssessSkill**：从"永远返回can_accommodate=True"升级为查devices算真实产能利用率，查生产订单列受影响订单，利用率>85%或急单量>总产能30%时判定不可插入。 **ScoringCardSkill**：从"传入dict取值"升级为查quality_checks算合格率（质量分）、查purchase_orders算准时率+均价+市场均价比较（价格分）、查近90天失败次数（服务分），四维加权→总分→等级。 **GradeManagerSkill**：从"简单阈值不写回"升级为等级变化时UPDATE suppliers.grade写回数据库并commit。 --- ### 1.3 意图检测升级为加权匹配（§3.6 部分） **修复前**：硬编码中文关键词表做简单计数匹配，无法消歧。 **修复方案**： - **加权关键词**：每个关键词带权重（1.0-2.0），专业术语权重更高 - **偏见词消歧**：为每个Agent定义强特征词，匹配到时+3.0分，解决"交期"同时匹配多Agent的问题 - **单Agent短路**：只匹配到一个Agent时直接返回，不走消歧 --- ### 1.4 协调API和知识图谱API已补齐（§3.5 部分） **修复前**：协调API和知识图谱API缺失，前端调用返回空或404。 **已实现端点**： | 模块 | 端点 | |------|------| | 协调触发 | POST /api/coordination/trigger | | 协调结果列表 | GET /api/coordination/results | | 协调结果详情 | GET /api/coordination/results/{id} | | 协调审批 | PUT /api/coordination/results/{id}/approve | | 知识图谱-事件 | GET /api/knowledge/events | | 知识图谱-实体关系 | GET /api/knowledge/entity/{id}/relations | | 知识图谱-因果链 | GET /api/knowledge/causal-chain/{id} | | 知识图谱-搜索 | GET /api/knowledge/search | | 知识图谱-思维 | GET /api/knowledge/thoughts, /thoughts/{id} | | Agent状态 | GET /api/agents/status | | Agent技能 | GET /api/agents/{name}/skills | --- ### 1.5 PendingAction SSE推送机制（§3.4 部分）新增`PendingAction`模型，Agent分析结果可携带待确认操作，通过SSE `actions`事件推前端： - `create_purchase_orders`：BOM不齐套时建议创建采购单 - `emit_signal`：设备参数异常趋势时推送预警信号 - `assign_device`：排产时建议将订单分配到设备 --- ### 1.6 后续优化方向当前Agent和Skill已全部接入真实数据层，后续还会针对生产落地持续优化：完善边界条件处理、增加异常数据容错、优化SQL查询性能、增强Agent间的联动决策深度等。 --- ## 二、待修复问题及规划 ### P0 — 前端图表可视化（§3.3） **问题**：所有图表为手写CSS（div模拟条形图），11个已定义组件未激活。 **规划**： - 安装Recharts，替换手写CSS图表 - Dashboard质量趋势→LineChart，设备参数趋势→折线图+阈值参考线 - 供应商评分→RadarChart四维雷达图，产能利用率→BarChart - 激活FishboneCard鱼骨图布局、SeverityBadge/AgentStatusBadge组件 **预计工期**：1-2天 --- ### P0 — 后台定时任务自动信号检测（§3.4） **问题**：Orchestrator协调链路完整，但信号触发入口缺失，无自动检测机制。 **规划**： - 基于APScheduler注册三个异步扫描任务 - `scan_inventory_alerts`：每5分钟扫描inventory，低于安全库存→生成material_shortage信号→调orchestrator.coordinate - `scan_device_anomalies`：每3分钟扫描device_params，超阈值→生成device_anomaly信号 - `scan_quality_exceedance`：每10分钟扫描quality_checks，不合格率突增→生成quality_exceedance信号 - app/main.py startup启动scheduler，添加手动触发调试端点 **预计工期**：1天 --- ### P1 — 意图检测升级为LLM语义路由（§3.6） **问题**：加权关键词+偏见词无法理解"最近出货不太顺利"等模糊表述，不支持多Agent联合意图。 **规划**： - 关键词匹配作为fast path，置信度>阈值直接返回 - 置信度不足时调用LLM做意图分类，支持多Agent联合返回 - 保留关键词匹配为可测试的fallback **预计工期**：0.5天 --- ### P1 — 自动化测试覆盖（§4.6） **问题**：7个DB驱动Skill和4个Agent analyze()缺少集成测试。 **规划**： - Skill数据驱动测试：模拟DB数据验证评分计算、排产逻辑、急单判定、等级写回 - Agent analyze()端到端测试：Mock DB验证AgentResult字段完整性 - Orchestrator协调全链路测试：模拟信号→多Agent评估→冲突检测→DB存储 - dependency_overrides必须save/restore **预计工期**：1天 --- ### P1 — 补充API端点 **问题**：仍缺4个端点。 **规划**： | 端点 | 用途 | |------|------| | GET /api/agents/quality/inspection-summary | 质检统计汇总 | | GET /api/agents/quality/defect-trace/{batch_no} | 缺陷追溯 | | POST /api/agents/production/rush-order-assess | 急单评估API | | GET /api/coordination/scan | 手动触发扫描 | **预计工期**：0.5天

No labels

No milestone

No project

No assignees

2 participants

Notifications

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

ninkch/SynchroFlow_AI#1

No description provided.

Rows
Columns