从30亿Token到全自治AGI：我花了两天搭建AI测试体系（附架构设计）

WJJAGI
0 阅读10分钟

因为刚从csdn迁移到本平台，会先搬运一些以前的文章，还请读者见谅～。～

从30亿Token到全自治AGI：我花了两天搭建AI测试体系（附架构设计）

让同一个AI既重构代码又测试代码，就像让学生自己出卷子自己考试——他太清楚哪里可以"偷懒"了。实测结果：12个未发现的回归缺陷，就是这么来的。

一、问题起源：重构后的代码谁验证？

很多人用AI重构代码效果不错，但忽略了一个关键问题：重构后的质量谁来保证？

我的经历：搭了一个Refactor Agent（15个知识库模块、84份文档、27,000+行指南），处理重构任务很顺手。第一次尝试让Refactor Agent同时负责测试，结果第5小时漏掉边界条件、第8小时跳过性能回归、第10小时思维混乱混淆修改和验证目标。最终交付代码带有12个未发现的回归缺陷。

核心结论：一个Agent同时承担重构和测试，会导致职责过载。

这不仅是效率问题，更是架构问题——自我确认偏差使得重构者无法客观验证自己的产出。

二、认知过载：上下文污染的量化证据

Refactor Agent的思维充满了"我要改什么"、"怎么改更优雅"。当它切换到测试模式时，重构思维会污染测试设计：

对比维度重构思维测试思维
函数评估"提取得很漂亮，肯定没问题""空输入时会不会崩溃？"
性能判断"这点损失可以接受""下降15%触发告警"
安全判断"外层已校验""需要纵深防御"
测试视角实现细节出发用户行为出发

实测数据：两种思维模式互相干扰，测试覆盖率从预期的85%下降到实际的62%。

三、独立Test Agent架构设计

基于上述教训，我设计了独立的Test Agent：

Test Agent 架构
├── Skills（6个核心技能）
│   ├── behavior-verification-skill    # 行为基线生成与对比
│   ├── test-generation-skill          # 基于代码分析自动生成测试
│   ├── performance-testing-skill      # 负载/压力/基准测试
│   ├── security-testing-skill         # SAST/DAST/依赖扫描
│   ├── chaos-engineering-skill        # 故障注入与韧性验证
│   └── e2e-testing-skill             # 端到端自动化测试
├── Knowledge Base（47个模块，158个文件，45,163行）
│   ├── 测试基础（5）：测试金字塔、测试生成、测试数据、编排、报告
│   ├── Web/API（3）、客户端（4）、后端（6）
│   ├── 游戏/图形（4）、安全（6）、性能/可靠性（5）
│   ├── 数据/合规（3）、新兴技术（4）、兼容性/工程（7）
└── 与Hermes协作：通过独立路由自动触发验证流程

验证命令（检查知识库完整性）：

find /Volumes/A/Agents/test-agent/knowledge_base -name "*.md" | wc -l
# 预期输出：158

find /Volumes/A/Agents/test-agent/knowledge_base -name "*.md" -exec wc -l {} + | tail -1
# 预期输出：45163 total

四、知识库填充：多Agent并行的踩坑实录

47个模块、158份文档、45,000+行内容，用AI多Agent并行自动填充。但多Agent场景下遇到了全新的挑战：

踩坑1：并发数量限制

预期：启动7-10个Agent并行填充。
现实：

[error] delegate 5 parallel tasks 0.0s [error]
✗ [2/2] 创建6个后端测试模块（共30个文件）：Timeout

分析：Hermes的delegate_task有_get_max_concurrent_children()限制，默认最多3-5个子Agent。
解决：将47个模块分组为3-4个批次，每批最多3个Agent并行。

踩坑2：模型输出长度截断

现实：

[subagent-1] ⚠️ Response truncated (finish_reason='length')
[subagent-1] ⚠️ Truncated tool call detected — refusing to execute incomplete tool arguments.

分析：虽然上下文有204.8K，但max output tokens是独立限制。
解决：降低任务复杂度，从"5个模块"降到"1个模块"，单文件200-300行。

踩坑3：文件写入路径错误

预期：写入/knowledge_base/{module}/
现实：写入/{module}/（少了knowledge_base/层级），43个模块显示"已完成"但实际为空。
验证命令：

find /Volumes/A/Agents/test-agent/ -type d -name "knowledge_base" -exec sh -c 'echo "=== {} ===" && ls "{}" | head -5' ;

踩坑4：Agent声称完成但实际未完成

日志显示完成但目录为空——Agent生成内容但写入失败（截断），"完成确认"与"实际写入"逻辑分离。
解决：不依赖Agent自我报告，批次完成后强制验证文件系统。

最终执行策略：分4批，3+3+3+1个Agent，总耗时8小时，100%完成（47/47模块）。

五、最终成果数据

维度Refactor AgentTest Agent组合
知识库模块154762
知识库文件84158242
总行数27,42745,16372,590
Skills5611
维度数据
Test Agent知识库模块47个
Test Agent知识库文件158个
总行数45,163行
代码示例覆盖率95%
覆盖语言Python, Go, JavaScript, Java, C/C++, C#, Rust
测试类型单元/集成/E2E/性能/安全/混沌/契约/可观测性

六、Agent架构的黄金法则

法则1：单一职责原则（SRP）

一个Agent只做一件事，但把它做到极致。

# 错误架构：1个Agent承担5个职责
class RefactorAgent:
    def refactor(self): pass
    def generate_tests(self): pass  # 污染
    def run_tests(self): pass       # 污染
    def verify(self): pass          # 偏差
    def report(self): pass          # 冲突

# 正确架构：职责分离
class RefactorAgent:
    def refactor(self): pass       # 只重构
    def submit(self): pass         # 通知测试

class TestAgent:
    def verify(self): pass         # 只验证
    def report(self): pass         # 客观报告

法则2：独立上下文原则

验证者不能知道被验证者的"内心想法"。

# 错误示范：Test Agent能看到Refactor Agent的Repo Map
test_context = {
    "repo_map": "...",           # 污染判断
    "task_decomposition": "...", # 知道哪里偷懒
    "intent": "重构这个模块"       # 先入为主
}

# 正确示范：只能看到输入和输出
test_context = {
    "input": "函数签名+文档",
    "output": "运行结果+行为",
    "behavior_diff": "与基线差异"  # 客观比对
}

法则3：可验证性原则

每个Agent的工作成果都必须可被独立验证。

Agent产出验证方式
Refactor Agent代码变更 + 变更说明人工Code Review
Test Agent测试报告 + 行为对比 + 性能数据自动化回归

法则4：渐进稳定原则

不要追求一次性完美，追求渐进式稳定。

❌ 同时10个Agent → 超时、截断、路径错误
✅ 分4批，每批3个Agent → 8小时，100%完成

七、实战验证流程示例

# 第一步：生成行为基线
python3 skills/behavior-verification-skill/scripts/generate-baseline.py \
  --project /path/to/project \
  --module scanner \
  --output workspace/baseline/

# 第二步：重构后行为对比
python3 skills/behavior-verification-skill/scripts/compare-behavior.py \
  --before workspace/baseline/before.json \
  --after workspace/baseline/after.json \
  --report workspace/behavior-diff.md

# 第三步：性能回归测试
python3 skills/performance-testing-skill/scripts/run-benchmark.py \
  --project /path/to/project \
  --baseline workspace/perf-baseline.json \
  --threshold 5 \
  --report workspace/perf-regression.md

引用来源列表

  1. Hermes Agent官方文档 - Agent职责分离设计原则（2026-04）
  2. 软件测试金字塔理论 - Martin Fowler关于测试分层的经典论述（2026-04）
  3. 测试左移实践 - Microsoft Engineering团队关于提前验证的研究（2026-04）

结尾引流

本文是AI Agent架构设计实战系列的第二篇。第一篇讲Refactor Agent搭建，第三篇将分享Agent间通信协议设计。欢迎关注，持续输出Agent系统搭建的完整踩坑实录。

头图/插图建议（16:9）

画面主体：左侧显示Refactor Agent的代码重构界面（紫色主题），右侧显示Test Agent的测试验证界面（绿色主题），中间有一条虚线隔开表示独立上下文。背景是深色代码编辑器风格。底部有4个小图标分别表示：行为基线、测试生成、性能回归、安全扫描。整体风格：技术架构图风格，专业感强。

即梦/可灵 Prompt： Professional architecture diagram showing two AI agent interfaces side by side, left side purple theme showing code refactoring interface, right side green theme showing test verification interface, divided by a dashed line in the center. Dark code editor background. Bottom has 4 small icons representing: behavior baseline, test generation, performance regression, security scan. Technology concept, clean lines, 16:9 aspect ratio.

一键复制区（知乎原生格式）

从30亿Token到全自治AGI：我花了两天搭建AI测试体系（附架构设计）

烧了30亿+token，超10万+api调用次数养龙虾之后，我彻底转向以hermes为执行者的harness工程agi全自治架构

一、问题起源：重构后的代码谁验证？

很多人用AI重构代码效果不错，但忽略了一个关键问题：重构后的质量谁来保证？

我的经历：搭了一个Refactor Agent，第一次尝试让Refactor Agent同时负责测试，结果第5小时漏掉边界条件、第8小时跳过性能回归、第10小时思维混乱。最终交付代码带有12个未发现的回归缺陷。

核心结论：一个Agent同时承担重构和测试，会导致职责过载。

二、认知过载：上下文污染的量化证据

对比维度重构思维测试思维
函数评估"提取得很漂亮，肯定没问题""空输入时会不会崩溃？"
性能判断"这点损失可以接受""下降15%触发告警"

实测数据：测试覆盖率从预期的85%下降到实际的62%。

三、独立Test Agent架构设计

Test Agent 架构
├── Skills（6个核心技能）
│   ├── behavior-verification-skill
│   ├── test-generation-skill
│   ├── performance-testing-skill
│   ├── security-testing-skill
│   ├── chaos-engineering-skill
│   └── e2e-testing-skill
├── Knowledge Base（47个模块，158个文件，45,163行）
└── 与Hermes协作：通过独立路由自动触发

验证命令：

find /Volumes/A/Agents/test-agent/knowledge_base -name "*.md" | wc -l
# 预期输出：158

四、知识库填充踩坑实录

踩坑1：并发数量限制

[error] delegate 5 parallel tasks 0.0s [error]

解决：分批次，每批最多3个Agent。

踩坑2：输出长度截断

[subagent-1] ⚠️ Response truncated (finish_reason='length')

解决：从"5个模块"降到"1个模块"，单文件200-300行。

踩坑3：文件路径错误 Agent写入/{module}/而非/knowledge_base/{module}/，43个模块为空。

总耗时8小时，100%完成（47/47模块）。

五、最终成果

维度Refactor AgentTest Agent组合
知识库模块154762
总行数27,42745,16372,590

六、Agent架构黄金法则

法则1：单一职责——一个Agent只做一件事
法则2：独立上下文——验证者不能知道被验证者想法
法则3：可验证性——每个产出都必须可独立验证
法则4：渐进稳定——分批执行比一次性完成更稳定

七、实战验证流程

python3 skills/behavior-verification-skill/scripts/generate-baseline.py \
  --project /path/to/project --module scanner --output workspace/baseline/

python3 skills/performance-testing-skill/scripts/run-benchmark.py \
  --project /path/to/project --baseline workspace/perf-baseline.json \
  --threshold 5 --report workspace/perf-regression.md

引用来源：

  1. Hermes Agent官方文档 - Agent职责分离设计原则（2026-04）
  2. 软件测试金字塔理论 - Martin Fowler关于测试分层（2026-04）
  3. 测试左移实践 - Microsoft Engineering团队（2026-04）

本文是AI Agent架构设计实战系列第二篇。欢迎关注，持续输出Agent系统搭建的完整踩坑实录。

avatar
文章
阅读
粉丝