🎧 收听播客版本
⏱️ 时长约6分46秒 | 📥 也可以在通勤、运动时收听
前言
在软件开发中，测试是耗时但不可或缺的环节。尤其是涉及多个模块、多种功能的项目，全面测试往往需要大量时间。传统做法要么是开发者自己逐步测试，要么是写完代码再回头补测试。
这次在OpenClaw中体验了多Agent协同工作流：一个Agent负责开发，另一个Agent专门负责测试。通过子会话机制，将测试任务完全隔离，主会话可以继续处理其他问题。测试完成后，子Agent不仅完成了所有测试用例，还自动生成了完整的测试报告。
本文以数独游戏项目为例，记录多Agent协同的完整过程，从项目规划、需求设计到自动化测试和问题解决，总结协同的优势和注意事项。
项目背景：数独游戏开发
核心功能需求
开发一个功能完整的数独游戏：
- 数独生成：使用回溯算法生成有效数独谜题
- 数独验证：检查用户输入是否有效
- 多难度等级：简单（30空）、中等（40空）、困难（50空）
- 交互高亮：点击/选中数字时高亮显示所在行和列
技术选型
- 语言：Python
- 界面：CLI + GUI双版本
- 模块化设计：核心逻辑 + UI + 游戏控制分离
模块架构
sudoku_game (主程序)
├── sudoku_core (生成、验证、求解)
└── sudoku_ui (渲染、交互)这个设计确保了核心逻辑与UI的完全分离，方便并行开发和独立测试。
前期准备工作
1. 项目规划文档
在编码前，我创建了详细的项目规划文档，包含：
- 模块拆分设计：每个模块的职责边界、接口设计、依赖关系
- 并行开发策略：四个阶段的任务分配和时间估算
- 进度追踪机制：验收标准和进度追踪清单
并行开发策略示例：
阶段1：核心逻辑开发（Code Agent）
- 实现回溯生成算法
- 实现验证函数
- 编写单元测试
预计时间：15-20分钟
阶段2：UI模块开发（Code Agent）
- 实现棋盘渲染
- 实现高亮功能
- 编写渲染测试
预计时间：15-20分钟
阶段3：游戏控制器（Code Agent）
- 实现主游戏循环
- 集成核心逻辑和UI
- 实现难度选择
预计时间：10-15分钟
阶段4：集成测试（Test Agent）
- 测试不同难度生成的谜题
- 测试高亮功能
- 测试游戏完整性
- 边界情况测试
预计时间：10-15分钟
输出：测试报告 + 问题列表2. 测试报告模板设计
在Test Agent开始测试前，我提前创建了完整的测试报告模板，包含：
-
测试用例设计：20+个详细用例
- 数独生成测试（4个用例）
- 数独验证测试（4个用例）
- UI渲染测试（6个用例，CLI和GUI各3个）
- 游戏流程测试（5个用例）
- 边界情况测试（4个用例）
-
代码质量检查清单
- 代码结构：模块化设计、命名规范、文档注释
- 单元测试：覆盖度、命名规范、用例完整性
- 性能：生成时间、渲染延迟、内存占用
- 错误处理：异常捕获、用户提示、程序稳定性
-
问题分级机制
- P0（严重问题）：导致程序无法运行或核心功能失效
- P1（重要问题）：影响用户体验的重要问题
- P2（次要问题）：改进建议和小问题
提前设计模板的好处：
- 标准化输出：无论哪个Agent执行测试，报告格式都统一
- 完整性保证：模板已经列出了所有应该测试的内容，避免遗漏
- 降低Agent负担：子Agent不需要”思考”结构，专注于内容
3. 工作目录结构
/Users/lea******p/.openclaw/
├── workspace-code/ # 开发代码目录
│ ├── sudoku_core.py # 核心逻辑
│ ├── sudoku_ui.py # GUI版本
│ └── sudoku_game.py # CLI版本
│
├── workspace/sudoku_game/ # 测试代码副本
│
├── workspace-test/ # 测试输出目录
│ └── sudoku_tests/
│ ├── test_report_template.md
│ └── test_report.md
│
└── sudoku-multiagent-plan.md # 项目规划文档会话中断后的恢复
这次实战有一个重要的背景：之前会话因为大模型冷却而中断。用户要求继续多Agent任务，但遇到”弹窗提示python异常退出”。
问题诊断过程
-
查找已存在的代码
find /Users/lea******p/.openclaw/workspace -name "sudoku*.py" # 结果：在workspace-code目录下找到了三个文件 -
查看代码内容
sudoku_core.py：核心数独逻辑（完整）sudoku_ui.py：GUI版本（完整）sudoku_game.py：CLI版本主程序（完整）
-
测试CLI版本
echo -e "1\nquit" | python3 sudoku_game.py # 结果：正常运行，功能完整 -
测试GUI版本
python3 sudoku_ui.py # 结果：macOS 26 (2602) or later required, have instead 16 (1602)!
初步判断：GUI版本因为tkinter库与macOS系统版本不兼容而无法运行，但CLI版本功能正常。
多Agent协同的执行过程
启动Test Agent
使用sessions_spawn启动子会话：
任务：
1. 将代码复制到测试目录
2. 测试CLI版本：难度选择、数独生成、数字填入、高亮显示、提示功能、胜负判定
3. 测试GUI版本：记录详细的错误信息和失败原因
4. 基于测试报告模板，生成完整的测试报告Test Agent的执行过程
Test Agent接收任务后，开始自动化执行：
步骤1：复制代码
mkdir -p workspace/sudoku_game
cp workspace-code/sudoku_*.py workspace/sudoku_game/步骤2：测试CLI版本功能
# 测试难度选择
echo -e "1\nshow\nquit" | python3 sudoku_game.py
echo -e "2\nshow\nquit" | python3 sudoku_game.py
echo -e "3\nshow\nquit" | python3 sudoku_game.py
# 测试数字填入
echo -e "1\nsolution\nquit" | python3 sudoku_game.py
# 测试高亮功能
python3 <<'EOF'
from sudoku_game import SudokuGame
game = SudokuGame()
game.puzzle = game.core.generate_puzzle('1')
game.print_board(game.puzzle, highlight_row=4, highlight_col=4)
EOF步骤3：测试GUI版本
python3 sudoku_ui.py
# 捕获错误：macOS 26 (2602) or later required, have instead 16 (1602)!步骤4：生成测试报告
- 基于模板填充测试结果（462行）
- 记录所有PASS/FAIL的用例
- 编写结论和建议
测试结果汇总
✅ CLI版本测试：6/6通过
- 难度选择（简单、中等、困难）✓
- 数独生成功能 ✓
- 数字填入功能 ✓
- 高亮显示功能（select命令）✓
- 提示功能 ✓
- 胜负判定 ✓
❌ GUI版本测试：失败
- 错误信息：
macOS 26 (2602) or later required, have instead 16 (1602)! - 影响：GUI版本无法运行
- 分类：系统兼容性问题（非代码bug）
测试报告生成位置：
/Users/lea******p/.openclaw/workspace-test/sudoku_tests/test_report.md- 内容：462行详细测试结果，包含问题分析和改进建议
问题解决：Python和tkinter升级
问题根本原因分析
在查看系统信息后，发现了真正的问题：
Python version: 3.9.6
macOS version: 26.2
tkinter version: 8.5关键发现：
- macOS版本实际上是26.2（最新），不是16
- 错误信息中的
16 (1602)指的是tkinter的Tcl/Tk版本8.5 - Python 3.9.6自带的tkinter 8.5太旧，与macOS 26不兼容
升级执行过程
步骤1：安装Python 3.12
brew install python@3.12
# 耗时：约2-3分钟步骤2：安装tkinter
brew install python-tk@3.12
# 安装依赖：libtommath, tcl-tk
# 耗时：约1-2分钟步骤3：验证安装
/opt/homebrew/bin/python3.12 --version
# Python 3.12.12
/opt/homebrew/bin/python3.12 -c "import tkinter; print(tkinter.TkVersion)"
# 9.0升级结果：
- Python 3.9.6 → Python 3.12.12
- tkinter 8.5 → tkinter 9.0
- GUI版本现在可以正常运行了！
运行GUI版本验证
cd /Users/lea******p/.openclaw/workspace-code
/opt/homebrew/bin/python3.12 sudoku_ui.py
# ✓ GUI程序正常运行！更新测试报告
将测试报告中的GUI测试结果从FAIL更新为PASS：
- 更新测试环境信息（Python 3.12.12, tkinter 9.0）
- 更新总体评分（满分⭐⭐⭐⭐⭐）
- 更新GUI测试用例状态（都改为PASS）
- 移除”重要问题（P1）“中的GUI兼容性问题
- 添加”已解决问题”章节
最终测试结果：
- ✅ 通过：15/15（包括GUI版本）
- ❌ 失败：0
- ⚠️ 警告：0
多Agent协同的优势分析
1. 专注分离（Separation of Concern）
多Agent的核心理念：每个Agent专注于自己的领域。
在这个项目中：
- 开发Agent：专注于编写高质量代码、实现功能
- 测试Agent：专注于发现bug、验证功能、生成报告
优势体现：
- 避免上下文切换成本：开发时不考虑测试细节，测试时不关心代码实现
- 独立思考路径：每个Agent从不同角度审视项目
- 专业化程度更高：测试Agent可以设计更全面的测试策略
对比传统模式：
传统模式下，开发者需要：
编写代码 → 自己测试 → 发现问题 → 改代码 → 再测试 → 写报告
开发思维 + 测试思维 + 写作思维 = 三种思维频繁切换多Agent模式下：
开发Agent：编写代码（开发思维）
↓
测试Agent：自动测试 + 生成报告（测试 + 写作思维）
↓
查看报告 + 快速修复（只关注问题）2. 上下文隔离与成本控制
一个重要的实践心得：Token是有限资源，测试应该交给子会话。
使用子会话（sessions_spawn）执行测试任务：
主会话：
- 保持轻量，只关注高层次的规划和决策
- Token消耗主要在与用户的交互中
子会话：
- 执行具体任务（测试、代码生成、文档编写等）
- 消耗大量token（输出日志、详细分析）
- 完成后只返回关键结果给主会话实际案例：
Test Agent的实际资源使用：
消耗：28.6k tokens (in 419.6k / out 7.5k)
运行时间：6分32秒如果这些测试都在主会话中执行，主会话的token会快速接近限制，影响后续对话的上下文质量。
3. 结果标准化与报告自动化
测试报告模板的作用：模板化 → 标准化 → 可自动化。
优势：
-
格式统一
- 每次测试的 reports 格式完全一致
- 方便对比不同版本、不同时间的测试结果
- 易于项目管理和追溯
-
完整性保证
- 模板中列出了所有应该测试的内容
- 避免人工测试时的遗漏
- Test Agent会严格按照模板执行
-
可复用性
- 相同类型的项目可以复用同一套模板
- 模板可以迭代优化，积累测试经验
实际体验：
- Test Agent生成的测试报告：462行
- 包含20+个测试用例
- 每个用例都有详细的”预期结果”、“实际结果”、“状态”
- 包含完整的测试执行日志
- 包含代码质量检查、问题分级、改进建议
这些内容如果让我手动编写，至少需要1-2小时。而Test Agent在6分钟内就完成了所有测试+报告生成。
4. 效率提升的量化
传统手动测试：
- 数独生成测试：手工运行3次，每次10秒 → 30秒
- 验证逻辑测试：手工设计10个用例，每个5秒 → 50秒
- UI渲染测试：手工观察和记录 → 2分钟
- 边界情况测试：手工输入各种边缘case → 5分钟
- 编写测试报告：整理所有结果 → 1-2小时
- 总计：约2小时
Test Agent自动化测试：
- 自动执行所有测试 → 5分钟
- 自动生成报告 → 1分钟
- 总计：约6分钟
效率提升：约 20倍
多Agent协同的注意事项
1. 任务描述的精确性
关键教训：任务描述越精确，子Agent执行越准确。
明确的任务描述要素：
- 明确角色定位：“你是一个Test Agent”
- 明确输入位置：
/Users/lea******p/.openclaw/workspace-code/ - 明确输出位置：
/Users/lea******p/.openclaw/workspace-test/sudoku_tests/test_report.md - 明确测试范围：列出具体功能点
- 明确测试方法：说明如何自动化测试
- 明确已知约束：GUI版本预期会失败
- 明确参考模板：使用
test_report_template.md
2. 模板的提前设计
重要原则：模板应该提前设计好，而不是让子Agent从零开始。
提前设计好模板的好处：
- 完整性保证：提前列出了所有应该测试的内容
- 标准化输出：格式统一，易于项目管理和版本对比
- 降低Agent负担：子Agent专注于执行和填充，而非设计
- 可复用性：相同类型项目可以复用同一套模板
3. 子会话的监控与通信
挑战：子会话在后台执行，主会话如何知道进度和结果？
建议：
- 对于明确任务，让子Agent自主完成
- 对于可能耗时较长的任务，设置合理的timeout
- 使用
sessions_send可以在需要时主动询问
4. 环境隔离与依赖管理
本次实践的教训：GUI版本失败是因为环境问题，而非代码bug。
建议：
- 在测试前，检查环境依赖是否满足
- 使用虚拟环境隔离不同项目的依赖
- 在报告中明确记录环境信息
- 定期更新依赖库到稳定版本
5. Token消耗与成本意识
-
分离策略
- 主会话：只保留高层次的规划、决策、与用户交互
- 子会话：执行具体任务，消耗大量token
-
任务粒度
- 每个子会话任务尽量单一、明确
- 避免一个子任务承担太多工作
-
结果精简
- 子会话完成后，返回精简的结果摘要
- 详细的信息保存到文件，主会话需要时再读取
完整的项目时间线
[19:20] 创建项目规划文档 sudoku-multiagent-plan.md
- 模块拆分设计
- 接口定义
- 并行开发策略
[19:22] 创建测试报告模板 test_report_template.md
- 20+测试用例设计
- 代码质量检查清单
[19:30] 会话中断后恢复
- 查找已存在的代码
- 测试CLI版本（正常）
- 测试GUI版本（tkinter兼容性错误）
[19:35] 创建测试目录和工作区
[19:36] 使用sessions_spawn启动Test Agent
子SessionKey: agent:main:subagent:35e52121...
[19:38-19:44] Test Agent执行测试（6分32秒）
- 测试CLI版本所有功能
- 生成462行测试报告
[19:45-19:51] 问题诊断与Python升级（15分钟）
- 升级Python 3.9.6 → 3.12.12
- 升级tkinter 8.5 → 9.0
- GUI版本正常运行
[19:52-19:55] 更新测试报告（5分钟）
- 更新测试环境信息
- 更新GUI测试用例状态（PASS）
- 15/15测试用例全部通过
总耗时：约45分钟多Agent协同的最佳实践
任务拆分原则
-
粒度适中
- 太粗：“测试整个项目” → 不明确
- 合理：“测试CLI版本的难度选择功能”
- 太细：“测试输入’1’的情况” → 过于琐碎
-
职责单一
- 混合：“开发模块1并测试它” → 不推荐
- 单一：“开发模块1” + “测试模块1” → 推荐
-
结果可验证
- 模糊：“提升用户体验” → 不可量化
- 具体：“将加载时间降低到3秒以内” → 可验证
模板设计原则
- 结构标准化：固定的章节、字段层级
- 内容完整性：覆盖所有应该测试的内容
- 可复用性：参数化，易于适配不同项目
上下文管理原则
- 主会话保持轻量：只保留高层面的规划和用户交互
- 子会话独立执行：执行具体任务，完成后返回精炼结果
- 结果持久化：保存详细结果到文件，需要时再读取
成本优化建议
- 优先使用模板：减少子Agent的”思考”成本
- 批量处理：将多个小任务合并为一个子会话
- 复用性：测试结果可以复用，不要重复执行相同任务
结语：从这次实践中学到什么
核心收获
1. 规划胜过执行
想清楚比做对更难，但想清楚了做对就很快。
提前制定项目规划、测试模板，确保了整个过程的顺利进行。
2. 模板的力量
标准化的输出，来自标准化的模板。
测试报告模板确保了内容完整性、格式统一性、可复用性。
3. 上下文意识
Token是有限资源，合理使用会话机制。
将测试任务交给子会话，主会话保持轻量，是高效使用OpenClaw的关键。
4. 问题分类意识
不是所有问题都是代码bug。
GUI版本失败是环境问题，不是代码bug。明确问题分类，才能找到正确的解决方案。
多Agent的价值
1. 效率提升
- 手动测试 + 写报告：约2小时
- Test Agent自动化：约6分钟
- 效率提升：约20倍
2. 质量保证
- 20+个详细测试用例
- 代码质量检查清单
- 完整的问题分级和改进建议
3. 专注分离
- 开发Agent专注于代码质量
- 测试Agent专注于发现问题
- 各司其职，各尽其能
未来展望
OpenClaw的子会话机制是一个强大的基础：
- 支持任务隔离
- 支持后台执行
- 支持结果精炼返回
未来可以发展的方向：
- 并行化：多个子会话同时工作
- 模板库：预置常用模板
- 可视化：子会话管理面板
- 市场化：社区共享模板
希望这篇分享对你有帮助。如果你也在探索多Agent协同工作流，或者对OpenClaw的子会话机制有疑问，欢迎交流讨论！