vault backup: 2026-08-10 12:25:40
This commit is contained in:
@@ -21,10 +21,10 @@ graph TD
|
||||
end
|
||||
|
||||
subgraph K8sCluster["K8s 集群"]
|
||||
SUBNAME["Service Name: user-service"] --> EP[Endpoint: pod IPs]
|
||||
EP --> P1[Pod A: v2.3.1]
|
||||
EP --> P2[Pod B: v2.3.1]
|
||||
EP --> P3[Pod C: v2.4.0-new]
|
||||
SVC["user-service"] --> EP[Endpoint<br/>pod IPs]
|
||||
EP --> P1[Pod A<br/>v2.3.1]
|
||||
EP --> P2[Pod B<br/>v2.3.1]
|
||||
EP --> P3[Pod C<br/>v2.4.0-new]
|
||||
|
||||
DEPLOY[Deployment] -->|管理| P1
|
||||
DEPLOY -->|管理| P2
|
||||
@@ -32,27 +32,29 @@ graph TD
|
||||
|
||||
HPA[Horizontal Pod Autoscaler] -->|扩缩容指令| DEPLOY
|
||||
|
||||
sub kubeSystem["kube-system 组件"]
|
||||
APISERVER[API Server]
|
||||
ETCD[(etcd)]
|
||||
CONTROLLER[M-controller Manager]
|
||||
SCHEDULER[Scheduler]
|
||||
subgraph kubeSystem["kube-system 组件"]
|
||||
comp1[API Server]
|
||||
comp2[(etcd)]
|
||||
comp3[Controller Manager]
|
||||
comp4[Scheduler]
|
||||
end
|
||||
|
||||
P1 -->|心跳 / metrics| PROMETHEUS[Prometheus TSDB]
|
||||
P2 -->|心跳 / metrics| PROMETHEUS
|
||||
P3 -->|心跳 / metrics| PROMETHEUS
|
||||
P1 -.->Fluentd --> ES[ES / Loki]
|
||||
P2 -.->Fluentd --> ES
|
||||
P3 -.->Fluentd --> ES
|
||||
|
||||
P1 -.-> FLUENTD[Fluentd]
|
||||
P2 -.-> FLUENTD
|
||||
P3 -.-> FLUENTD
|
||||
FLUENTD --> ES_LOG[ES / Loki]
|
||||
end
|
||||
|
||||
sub GrafanaUI["可视化层"]
|
||||
subgraph GrafanaUI["可视化层"]
|
||||
GRAFANA[Grafana Dashboard] -->|查询| PROMETHEUS
|
||||
GRAFANA -->|告警规则| ALERTMANAGER[Alertmanager]
|
||||
end
|
||||
|
||||
INGRESS --> SUBNAME
|
||||
INGRESS --> SVC
|
||||
```
|
||||
|
||||
### RollingUpdate 策略详解
|
||||
|
||||
@@ -93,7 +93,39 @@ Step 4: 生成总结报告
|
||||
|
||||
**动态 Planning(Replan):** 当某一步失败或结果不符合预期时,Planner 重新规划后续步骤。例如搜索结果为空时,自动调整为「扩大搜索范围 → 使用同义词 → 切换到备选信息源」。
|
||||
|
||||
### 消息传递协议
|
||||
#### Swarm 模式 — 蜂群协作
|
||||
|
||||
Swarm 没有中心调度器。所有 Agent 只看同一个共享环境(比如一张公共白板),各自根据局部线索自主行动,互不发消息。
|
||||
|
||||
```mermaid
|
||||
graph LR
|
||||
SA["Agent A\n看线索 → 行动"] --> WB["公共环境 / 共享状态"]
|
||||
SB["Agent B\n看线索 → 行动"] --> WB
|
||||
SC["Agent C\n看线索 → 行动"] --> WB
|
||||
SD["Agent D\n看线索 → 行动"] --> WB
|
||||
WB --> Out["最终聚合"]
|
||||
```
|
||||
|
||||
**跟 Supervisor 的根本区别:**
|
||||
|
||||
| 维度 | Supervisor | Swarm(蜂群) |
|
||||
|------|-----------|--------------|
|
||||
| 通信方式 | Agent ↔ Supervisor ↔ Agent(中心化) | Agent ↔ 共享环境(去中心化) |
|
||||
| 协调者 | 有 | 无 |
|
||||
| 每个 Agent 知道全局吗 | 不知道,只知道自己的子任务 | 也不知道,只看局部线索 |
|
||||
| 结果如何汇总 | Supervisor 聚合 | 各自产出叠加即可 |
|
||||
|
||||
**类比理解:**
|
||||
|
||||
- **Supervisor** = 指挥官发号施令,士兵执行并汇报
|
||||
- **Swarm** = 一群蜜蜂围着蜂巢转,每只各自找花蜜,最后蜂蜜自然 accumulate
|
||||
|
||||
**适用场景:**头脑风暴、概念发散、大量独立验证——即"**不需要商量、答案 = 所有人想法的总和**"的场景。比如让 10 个 Agent 各出 20 个点子,再挑最好的几条。
|
||||
|
||||
> [!WARNING]
|
||||
> Swarm 的坑:① 多个 Agent 可能重复试同一个方向(浪费算力);② 缺少全局约束时,产出容易过于发散难整理;③ 某个 Agent 发现走不通也无法通知别人及时止损。
|
||||
|
||||
## 消息传递协议
|
||||
|
||||
多 Agent 之间通过结构化消息通信,推荐基于 JSON Schema 定义契约:
|
||||
|
||||
|
||||
Reference in New Issue
Block a user