42 lines
1.9 KiB
Markdown
42 lines
1.9 KiB
Markdown
|
# Hermes 后台智能体架构总览
|
|||
|
|
|
|||
|
|
## 1. 定位与愿景
|
|||
|
|
Hermes 是 X-Financial 系统中的**后台自动巡检与数据洞察中枢**。与处理实时对话的 UserAgent 不同，Hermes 专注于异步、长周期、大批量的任务，核心价值在于提供事前的**深度风险挖掘**和定期的**业财洞察报告**。
|
|||
|
|
|
|||
|
|
## 2. 系统拓扑图
|
|||
|
|
```mermaid
|
|||
|
|
graph TD
|
|||
|
|
subgraph 调度层
|
|||
|
|
A[Cron Scheduler] -->|定时触发| B[Task Queue]
|
|||
|
|
end
|
|||
|
|
|
|||
|
|
subgraph Hermes Agent 层
|
|||
|
|
B -->|消费任务| C(Hermes Worker)
|
|||
|
|
C --> D[Task Skills Router]
|
|||
|
|
D --> E{RiskScanner Skill}
|
|||
|
|
D --> F{ExpenseReport Skill}
|
|||
|
|
D --> G{KnowledgeCheck Skill}
|
|||
|
|
end
|
|||
|
|
|
|||
|
|
subgraph X-Financial 核心服务
|
|||
|
|
E <--> H[(Expense DB)]
|
|||
|
|
F <--> H
|
|||
|
|
G <--> I[(LightRAG Graph/Vector)]
|
|||
|
|
C <--> J[LLM Gateway / OpenAI]
|
|||
|
|
C --> K[Notification Service / 企业微信]
|
|||
|
|
end
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
## 3. 核心设计原则
|
|||
|
|
1. **防抖与限流**：后台全量扫表时，必须分片执行，防止对主数据库造成 I/O 拥堵。
|
|||
|
|
2. **幂等性保障**：每一个扫描任务和报告生成任务都应该具备唯一幂等键，避免因进程重启导致的重复发信或重复扣减信用分。
|
|||
|
|
3. **隔离性**：Hermes 的进程应与对外提供 API 服务的 Web Server 物理/逻辑隔离，大模型限流策略（Token Rate Limit）应配置相互独立的账单通道。
|
|||
|
|
|
|||
|
|
## 4. 核心执行链路（示例：夜间风控巡检）
|
|||
|
|
1. 凌晨 02:00，Cron 触发 `trigger_risk_scan` 任务。
|
|||
|
|
2. Worker 拉取状态为 `draft` 和 `submitted` 且 `risk_scanned=False` 的单据。
|
|||
|
|
3. 将近三个月的相关人员单据聚类，构建 Context。
|
|||
|
|
4. 调用大模型，寻找“拆单”、“合谋”、“时间/地点异常”等隐蔽风险。
|
|||
|
|
5. 将发现的风险写入 `hermes_risk_report` 表，并标记对应单据。
|
|||
|
|
6. 任务结束，更新执行日志，等待早晨财务主管查阅。
|