从“越用越好用”的 AI Agent 说起：测试开发如何打造自己的专属智能体？

测试人
3 阅读8分钟

最近，一个名为 OpenClaw 的开源 AI Agent 框架在技术圈引发了不少讨论。很多人说它“越用越好用”，也有人吐槽“不好用”。作为一名测试开发工程师，我带着好奇读完了它的源码，发现了一个被大多数人忽略的本质——它的智能，不来自复杂的算法，而来自一堆普普通通的 .md 文件。

这听起来有点反直觉，但背后的设计思想，恰恰是当前 AI 工程化落地非常值得借鉴的思路。本文将结合测试开发的实际工作场景，拆解这套“自我进化”的机制，并给出测试开发在 AI 项目中可以扮演的角色和具体代码示例。

一、为什么你的 AI Agent 总是不如预期？

在接触 OpenClaw 之前，我也尝试过各种 AI 辅助工具，但常常遇到三个“坑”：

  1. 模型是上限，框架只是下限
    再好的 Agent 框架，如果底层模型能力不够，效果也上不去。好比给实习生再详细的手册，他也难做出资深工程师的成果。

  2. 让一个 Agent 干所有事
    很多人的用法是：一个 Agent 既写代码、又写文案、还做数据分析。结果它哪个都不精。现实中的专家都是垂直领域的，AI 也一样。

  3. 没有“培训”Agent
    开箱即用就想达到完美效果？你招一个新员工，第一天就指望他比老员工厉害？Agent 需要你带它熟悉你的工作流程、你的偏好、你们团队踩过的坑。

而 OpenClaw 给出的解决方案，用一个词总结就是：让 Agent 拥有长期记忆和自我进化的能力。这个能力的载体，就是 workspace 里的一堆 .md 文件。

二、核心机制：一堆自我进化的 Markdown 文件

OpenClaw 为每个 Agent 分配了一个独立的 workspace 目录，里面预设了 7 类核心文件：

文件作用
SOUL.md定义 Agent 的人格、语气、价值观（会随着互动自我调整）
USER.md记录用户的偏好、习惯、技术栈、时区等画像
AGENTS.md最重要的踩坑记录：犯过的错、学到的教训，永久固化
TOOLS.md环境信息：SSH 主机、设备名、路径习惯等
SKILL.md（多个）特定领域的操作手册，可自定义覆盖内置行为
memory/*.md每日对话日记，原始记忆
MEMORY.md提炼后的长期记忆，每次对话都会加载

工作流程非常简单，但威力巨大：

每次对话前 → 把这些 md 文件拼进 prompt
对话中 → Agent 执行任务，学到新东西/犯错/发现用户偏好
对话后 → Agent 把新知识写回对应的 md 文件
下次对话 → 加载更新后的文件，行为更精准

这就是一个完整的 学习 → 记忆 → 检索 → 应用 的闭环。而存储介质，全是纯文本的 Markdown。

三、对测试开发工程师的启示：我们如何利用这套机制？

在软件测试领域，重复劳动、经验沉淀、踩坑复盘是日常。这套机制可以完美对应到测试开发的实际工作中。

场景一：让 Agent 学会你的测试用例编写规范

每个团队都有自己的用例格式（前置条件、步骤、预期结果、优先级）。你可以写一个 SKILL.md：

# 测试用例生成规范

当你被要求生成测试用例时，必须遵循以下模板：

## 用例ID: TC-{模块}-{数字}
## 标题: 简洁描述测试点
## 优先级: P0/P1/P2/P3
## 前置条件: 环境、数据、权限要求
## 测试步骤:
1. 步骤一
2. 步骤二
## 预期结果:
- 结果一
- 结果二
## 实际结果: (留空)

附加要求：对于登录模块，必须包含空密码、错误密码、锁定账户等边界场景。

从此，每次让 Agent 生成新功能的用例，它都会自动按这个规范输出，不再需要你反复解释格式。

场景二：把历史缺陷变成“避坑指南”

你有一个缺陷库（Jira、TAPD 等）。可以把典型缺陷的原因和避免方法写入 AGENTS.md：

## 已知坑位 (Do Not Repeat)

1. **并发下单时库存超卖**  
   - 发生原因：未对库存操作加分布式锁  
   - 以后设计类似场景时，必须要求开发提供锁机制验证  
   - 测试用例必须包含并发压测场景

2. **移动端支付页面在 iOS 14 以下闪退**  
   - 原因：使用了不兼容的 JS API  
   - 以后所有 H5 支付页必须兼容 iOS 12+ 并加入兼容性测试

3. **定时任务在每月 31 日不执行**  
   - 原因：Cron 表达式未处理月份大小月  
   - 以后所有涉及日期的定时任务，必须覆盖月末边界值测试

Agent 在后续帮你设计测试方案时，会自动检索这些记录，避免你再次掉进同样的坑。

场景三：自动化测试脚本的智能生成与维护

你可以把团队的自动化框架（如 Pytest、Selenium、Appium）的使用规范写成 SKILL.md，然后让 Agent 根据手工用例自动生成自动化脚本框架。

更进一步，当测试脚本因 UI 变化而失效时，你可以告诉 Agent：“这个元素的定位器变了，以后遇到类似情况，优先使用 data-testid，如果没有再用 XPath。” Agent 会把这个规则写入 AGENTS.md，下次修复脚本时自动遵循。

四、测试开发在 AI 项目中的具体工作示例

很多测试同学觉得 AI 项目很“玄学”，不知道如何介入。其实测试开发在 AI 项目里可以发挥巨大的价值，不仅仅是功能测试。下面以 构建一个“智能用例生成 Agent” 为例，给出完整的测试开发工作流。

1. 需求分析与测试策略设计

  • 目标：开发一个 Agent，输入需求描述（PRD 片段），输出符合团队规范的测试用例。
  • 风险点：Agent 可能产生幻觉（编造不存在的功能）、遗漏边界场景、格式不统一。
  • 测试策略：
    • 功能测试：给定标准需求，验证输出用例的正确率和格式合规率。
    • 鲁棒性测试：输入模糊、矛盾、超长需求，观察 Agent 行为。
    • 回归测试：每次修改 Agent 的 prompt 或 md 文件后，跑一批历史用例，确保已有能力不退化。
    • 经验积累测试：验证 Agent 能否通过 AGENTS.md 记住用户的纠正。

2. 搭建测试环境与基线数据集

  • 准备 50 个历史需求文档 + 对应的人工编写的标准用例集（作为 Golden Answer）。
  • 搭建 OpenClaw 环境（或其他类似框架），创建一个专门的 test-case-agent workspace。
  • 编写初始的 SKILL.md（用例模板）和 AGENTS.md（常见遗漏点）。

3. 编写自动化测试脚本（Python + Pytest 示例）

# test_agent_case_generation.py
import pytest
from pathlib import Path
import json
from openclaw import AgentClient  # 假设的 SDK

# 加载基线数据
with open("baseline.json") as f:
    baseline = json.load(f)

agent = AgentClient(workspace="test-case-agent")

@pytest.mark.parametrize("case", baseline)
def test_case_generation(case):
    requirement = case["requirement"]
    expected_output = case["expected_cases"]
    
    response = agent.chat(f"请根据以下需求生成测试用例：\n{requirement}")
    generated_cases = response.output  # 假设返回结构化用例
    
    # 断言1：格式符合 SKILL.md 规范
    assert"## 用例ID:"in generated_cases
    assert"## 优先级:"in generated_cases
    
    # 断言2：关键场景覆盖率（使用 NLP 相似度或规则匹配）
    coverage = compute_coverage(generated_cases, expected_output)
    assert coverage >= 0.8
    
    # 断言3：不产生幻觉（需求中不存在的模块）
    hallucination = detect_hallucination(generated_cases, requirement)
    assert hallucination == []
    
def test_correction_persistence():
    """测试：纠正 Agent 一次后，它是否记住"""
    # 第一次：Agent 生成了错误的用例格式
    resp1 = agent.chat("生成登录模块用例")
    assert"错误格式特征"in resp1
    
    # 用户纠正
    agent.chat("不对，登录用例必须包含验证码场景，请记住并更新到 AGENTS.md")
    
    # 第二次：重新生成
    resp2 = agent.chat("再生成一次登录模块用例")
    assert"验证码"in resp2  # 验证记住了

4. 持续集成与效果评估

  • 将测试脚本接入 CI 流水线，每次修改 workspace 里的 md 文件后自动触发回归。
  • 定期（每周）人工抽检 Agent 输出的用例质量，更新基线数据集。
  • 记录“用户纠正次数”指标——如果 Agent 总是重复犯错，说明 AGENTS.md 的写入机制需要调优。

五、总结：测试开发在 AI 时代的新定位

OpenClaw 这套“md 文件即知识”的架构，本质上是一种轻量级、可解释、可版本控制的 Agent 记忆方案。它不依赖复杂的向量数据库，却能达到“越用越好用”的效果。

对于我们测试开发工程师来说，这意味着：

  1. 我们不再只是工具的消费者，而是 Agent 的“教练” —— 我们通过编写和审核 md 文件，把团队的经验沉淀成 AI 的长期记忆。
  2. 测试左移到了“Agent 训练阶段” —— 在 Agent 上线前，我们就可以通过注入高质量的 SKILL.md 和 AGENTS.md 来保证它的基本能力。
  3. 自动化测试的边界被扩展了 —— 我们不仅要测 Agent 的输出，还要测它的记忆系统是否可靠、纠正机制是否生效。

最后，记住两句话：

代码决定了 Agent 能做什么，md 文件决定了它做得多好。
你的 Agent 的价值，不在模型，不在框架，而在 workspace 里那堆不断生长的 Markdown 文件。

如果你也是测试开发，不妨从今天开始，为自己打造一个专属的“避坑助手” —— 用最朴素的文件，积累最宝贵的经验。

霍格沃兹测试开发学社，是一个专注软件测试、自动化测试、人工智能测试与测试开发的技术交流社区

avatar
文章
阅读
粉丝