1. 项目背景与动机
平凯（PingCAP）的 TiDB 数据库在金融、保险等行业广泛应用，其两节点敏捷模式（even-replicas）是一种高性价比的高可用方案。然而，手动部署和测试这套架构需要大量重复性操作：安装 Docker、配置 Docker Compose、部署 TiDB 集群、配置 Keepalived VIP、执行高可用测试……每次都要耗费大量时间。
为了解决这个痛点，我利用 Loop 多智能体协作平台，通过架构师、开发工程师、测试工程师三个 AI Agent 的协作，从零开始开发了 tidbx-ha-toolkit——一套完整的平凯两节点敏捷模式一键部署与高可用测试工具。
1.1 核心目标
目标 |
说明 |
一键安装 |
自动安装 Docker CE + Docker Compose 基础环境 |
一键部署 |
基于 Docker Compose 部署平凯两节点敏捷模式集群 |
一键 VIP |
自动配置 Keepalived 及 VIP，实现自动故障转移 |
自动化 HA 测试 |
节点重启、网络延迟、数据损坏等场景的自动化测试 |
并发业务模拟 |
在 HA 测试期间模拟 10 并发业务写入，统计业务影响 |
2. 为什么选择 Loop
Loop 是一个多智能体协作平台，支持多个 AI Agent 在同一个频道中协同工作。本项目中我配置了三个 Agent：
Agent 角色 |
职责 |
架构师 |
架构设计、技术选型、代码审查、文档撰写 |
开发工程师 |
代码开发、Bug 修复、代码提交 |
测试工程师 |
环境部署、测试执行、测试报告、Bug 发现 |
Loop 的优势在于：
• 多 Agent 协作——架构师设计、开发工程师写代码、测试工程师验证，并行推进
• 人机协同——人类可以随时插入指令、纠正方向、提供环境信息
• 任务看板——可视化跟踪每个任务的进度（todo / in_progress / in_review / done）
• 持久记忆——Agent 能记住历史上下文，断点续传
3. 架构设计
架构师基于 25 页的平凯官方文档，设计了四大模块架构：
3.1 项目结构
tidbx-ha-toolkit/
├── setup/ → 一键安装 Docker 环境
├── deploy/ → 一键部署集群 + Keepalived VIP
├── ha-test/ → 自动化 HA 测试（5 种场景）
└── config/ → 参数化配置模板（.env 文件）
3.2 技术选型
类别 |
选型 |
理由 |
脚本语言 |
Bash |
运维标准，无额外依赖 |
容器 |
Docker CE + Compose |
环境隔离，一键启停 |
高可用 |
Keepalived (VRRP) |
成熟的 VIP 漂移方案 |
网络模拟 |
tc/netem |
Linux 内核原生支持 |
版本管理 |
Git/GitHub |
协作开发，版本可追溯 |
3.3 任务拆解
架构师将项目拆解为 19 个子任务，分配给开发和测试 Agent：
Phase |
任务 |
负责人 |
Phase 1 |
项目骨架、Git 仓库 (#t2) |
开发工程师 |
Phase 2 |
环境安装脚本 (#t3) |
开发工程师 |
Phase 3 |
集群部署脚本 (#t4-#t10) |
开发工程师 |
Phase 4 |
HA 测试脚本 (#t11-#t16) |
开发工程师 |
Phase 5 |
README 文档 (#t17) |
开发工程师 |
Phase 6 |
集成验证 (#t18) |
测试工程师 |
Phase 7 |
GitHub 推送 (#t19) |
开发工程师 |
4. 开发过程
4.1 第一阶段：架构设计与开发
我在 Loop 的 #2-channel 频道中上传了平凯官方的 25 页测试验证文档，并发出指令：“基于这个文档开发一个一键部署与高可用测试工具”。
架构师 Agent 完成了完整的架构设计，包括目录结构、技术选型、测试框架等。开发工程师 Agent 完成了 22 个文件的开发，包括部署脚本、HA 测试脚本、Docker Compose 配置等。
4.2 第二阶段：测试与 Bug 修复循环
测试工程师 Agent 在两台物理服务器上进行了多轮测试，发现了多个关键 Bug，每次发现后由开发工程师修复并提交：
Bug 编号 |
问题 |
影响 |
修复方案 |
#1 |
init-data.sh 用 mkdir 创建状态文件 |
仲裁脚本始终失败，无法降级为 ASYNC |
mkdir → touch |
#2 |
test-network-delay.sh 小写 sync 比较 |
1s 延迟测试误报 FAIL |
sync → SYNC |
#3 |
get_replication_mode() 提取错误字段 |
复制模式返回 unknown |
提取 state 字段 + fallback |
#4 |
common.sh TIMESTAMP(3)(3) 语法错误 |
并发业务表无法创建 |
去除重复括号 |
#5 |
grep JSON 模式不兼容空格 |
PD API 解析失败 |
增加 \s* 匹配 |
4.3 第三阶段：并发业务模拟功能开发
我提出了新需求：在 HA 测试时同时模拟 10 并发业务，以得出每个场景对业务的影响时间和数据一致性。架构师设计了并发业务引擎，开发工程师完成开发，测试工程师验证通过。
并发业务引擎的核心设计：
• 10 个并发 Worker，每个独立循环执行 INSERT（含 worker_id + seq_num）
• 阶段标记机制（mark_phase），记录每个测试场景的精确时间戳
• 数据一致性校验（check_data_consistency），验证每个 Worker 的 seq_num 连续无丢失
• 业务影响统计（compute_impact_stats），按场景统计成功率、延迟、失败率
5. 最终测试结果
5.1 环境信息
项目 |
值 |
Node1 (Master) |
192.168.2.246 (rocky246) |
Node2 (Backup) |
192.168.2.247 (rocky247) |
VIP |
192.168.2.100/24 |
TiDB 版本 |
v7.1.9 (tidbx 容器镜像) |
并发业务数 |
10 |
5.2 节点重启测试：8/8 PASS
测试项 |
结果 |
详情 |
初始复制模式 SYNC |
✓ PASS |
|
Master 关机 → VIP 漂移 |
✓ PASS |
VIP 成功漂移到 Backup |
Master 关机 → ASYNC 降级 |
✓ PASS |
复制模式在 20s 内降级 |
Master 关机期间 TiDB 可用 |
✓ PASS |
通过 VIP 可正常查询 |
Master 恢复 → SYNC 恢复 |
✓ PASS |
~30s 恢复 |
Backup 关机 → ASYNC 降级 |
✓ PASS |
|
Backup 关机期间 TiDB 可用 |
✓ PASS |
|
Backup 恢复 → SYNC 恢复 |
✓ PASS |
~30s 恢复 |
5.3 网络延迟测试：7/7 PASS
测试项 |
结果 |
详情 |
初始复制模式 SYNC |
✓ PASS |
|
1s 延迟 → 保持 SYNC |
✓ PASS |
重试6次后确认 SYNC |
1s 延迟清除 → 恢复 SYNC |
✓ PASS |
|
10s 延迟 → 降级 ASYNC |
✓ PASS |
|
10s 延迟清除 → 恢复 SYNC |
✓ PASS |
~14s 恢复 |
网络完全隔离 → ASYNC |
✓ PASS |
iptables DROP 验证降级 |
网络隔离恢复 → SYNC |
✓ PASS |
~40s 恢复 |
5.4 并发业务影响统计
总操作数: 31,090 | 成功: 30,920 | 失败: 170 | 成功率: 99.45%
场景 |
总操作 |
成功 |
失败 |
失败率 |
平均延迟 |
Master 关机 |
511 |
351 |
160 |
31.3% |
881ms |
Backup 关机 |
69 |
59 |
10 |
14.5% |
5830ms |
1s 网络延迟 |
187 |
187 |
0 |
0% |
927ms |
10s 网络延迟 |
952 |
952 |
0 |
0% |
663ms |
数据损坏 |
0 |
0 |
0 |
N/A |
N/A |
5.5 业务影响时间分析
故障类型 |
业务完全中断时间 |
业务降级时间 |
Master 关机 |
~15s (VIP 漂移) |
~30s (含集群恢复) |
Backup 关机 |
~10s (VIP 漂移) |
~30s (含集群恢复) |
1s 网络延迟 |
0s |
持续期间延迟升高 49x |
10s 网络延迟 |
0s |
ASYNC 下延迟升高 35x |
网络完全隔离 |
~30s (PD 无 leader) |
~40s (含恢复) |
6. Loop 多智能体协作亮点
6.1 分工协作
本项目最大的亮点是三个 Agent 各司其职、高效协作：
• 架构师负责设计和审查，输出了 18KB 的架构设计文档和小白友好的 README
• 开发工程师负责代码实现，从零到一完成 22 个文件、修复 9+ 个 Bug
• 测试工程师负责测试验证，在物理环境上执行了多轮完整测试并输出详细报告
6.2 人机协同
作为人类用户，我在整个过程中的主要工作是：
1. 上传原始需求文档，发出开发指令
2. 提供测试环境信息（SSH 节点、Docker 镜像等）
3. 审查测试报告，提出优化建议（如增加并发业务模拟）
4. 协调多个 Agent 之间的工作衔接（如让开发修复 Bug 后通知测试复测）
整个过程中我的人工干预次数不超过 15 次，大部分工作由 Agent 自主完成。
6.3 效率提升
传统方式 vs Loop 多智能体方式对比：
维度 |
传统方式 |
Loop 方式 |
开发时间 |
2-3 周（单人全栈） |
3-4 天（多 Agent 并行） |
Bug 修复周期 |
发现→修复→测试，数小时 |
发现→修复→测试，数十分钟 |
人工干预 |
每步都需要 |
仅关键节点干预 |
文档质量 |
依赖个人能力 |
Agent 自动生成详细报告 |
7. 项目交付物
交付物 |
说明 |
源代码 |
GitHub: github.com/michaelliuyuan/tidbx-ha-toolkit |
setup/ |
Docker CE + Docker Compose 离线安装脚本 |
deploy/ |
一键部署集群 + Keepalived VIP |
ha-test/ |
自动化 HA 测试框架（节点重启/网络延迟/数据损坏/业务模拟） |
README.md |
小白友好的入门手册，含完整部署步骤和 FAQ |
测试报告 |
完整的 HA 测试报告，含每个场景的详细数据 |
8. 总结
通过 Loop 多智能体协作平台，我从一份 25 页的技术文档出发，仅用 3-4 天就完成了一套完整的部署与测试工具。整个过程中：
• 架构师输出了完整的架构设计和详细的任务拆解
• 开发工程师从零到一完成 22 个文件的开发，修复了 9+ 个 Bug
• 测试工程师在物理环境上进行了多轮完整测试，最终成功率 99.45%
• 人类只需在关键节点提供指导和环境信息，大幅降低了工作量
Loop 的多 Agent 协作模式让软件开发像管理一个团队一样高效，每个 Agent 各司其职、互相配合，最终交付了高质量的产品。这种工作方式将是未来软件开发的重要趋势。