独立开发者从想法到上线的全流程管理：从断言到端到端验证

引入 AI Agent 后，不能只凭“写得顺不顺”判断效果。工具调用、生成的代码结构和部署产物都应通过测试与检查验证。资源有限时，可用单元测试、集成测试和 E2E 校验覆盖关键边界。

---

1. 测试未通过时先定位原因

上周在验收一个全自动任务拆解 Agent 时，终端跑测试套件的输出结果简直惨不忍睹。

用 pytest 跑 Agent 的工具调用单元测试与集成测试：

$ pytest tests/test_agent_workflow.py -v --tb=short
============================= FAILURES =============================
_________________ test_agent_tool_calling_loop _________________
tests/test_agent_workflow.py:48: in test_agent_tool_calling_loop
    assert execution_context.step_count <= 5, "Agent infinite loop detected"
E   AssertionError: Agent infinite loop detected: step_count is 12
----------------------------- JSON Output -----------------------------
{"status": "LOOP_LIMIT_EXCEEDED", "tokens_spent": 14200, "tool": "file_writer"}
====================== 1 failed, 12 passed in 8.42s ======================

这类报错说明：若没有测试断言约束，Agent 遇到文件写入冲突时可能反复调用 file_writer，让任务长期挂起并增加资源消耗。

如果没有自动化测试拦截，这套逻辑一旦部署到线上生产环境，用户的账户额度不仅会被快速打空，服务器的 CPU 也会被死循环任务占满。

---

2. 三层防线设计：独立开发者的分层测试策略

不能把所有测试都寄希望于最后用浏览器点两下的 E2E。独立开发者应构建三层分级测试网：

这三层的分工极其明确：

• 单元测试（Unit Test）：毫秒级运行，专门断言单个 Tool 的入参 Schema 校验、错误拦截和 Mock 返回。
• 集成测试（Integration Test）：秒级运行，专门断言 Agent 状态机不会卡在死循环里，检测 Token 预算闸门。
• 端到端测试（E2E Test）：分钟级运行，验证自动化生成的代码/页面在真正浏览器环境里能否跑通完整业务流程。

---

3. 可落地的代码：Pytest 环境下的 Agent 状态机与分层断言套路

下面是一套用于评估 Agent 工具调用逻辑的 Python 测试套件。

代码中包含了 Mock 校验、步数上限制约以及具体的异常状态断言：

import pytest
from unittest.mock import MagicMock
from typing import Dict, Any, List

class AgentExecutionEngine:
    def __init__(self, max_steps: int = 5):
        self.max_steps = max_steps
        self.history: List[Dict[str, Any]] = []

    def execute_step(self, tool_name: str, payload: Dict[str, Any]) -> Dict[str, Any]:
        if len(self.history) >= self.max_steps:
            raise RuntimeError("EXCEEDED_MAX_STEPS_LIMIT")

        self.history.append({"tool": tool_name, "payload": payload})
        
        # 模拟生产工具拦截
        if tool_name == "db_migrate" and payload.get("env") == "production":
            return {"status": "BLOCKED", "reason": "Production migration requires human approval"}

        return {"status": "SUCCESS", "result": "Operation completed"}

# ----------------- 单元与集成测试 -----------------

def test_tool_calling_schema_validation():
    """单元测试：验证非安全参数是否在入参阶段被拦截"""
    engine = AgentExecutionEngine(max_steps=3)
    res = engine.execute_step("db_migrate", {"env": "production"})
    
    assert res["status"] == "BLOCKED"
    assert "human approval" in res["reason"]

def test_agent_infinite_loop_prevention():
    """集成测试：验证 Agent 在连续重试时是否触发熔断闸门"""
    engine = AgentExecutionEngine(max_steps=3)

    with pytest.raises(RuntimeError) as exc_info:
        for _ in range(5):
            engine.execute_step("file_writer", {"path": "/tmp/test.txt", "content": "dummy"})

    assert "EXCEEDED_MAX_STEPS_LIMIT" in str(exc_info.value)
    assert len(engine.history) == 3  # 严格限制在 3 步之内拦截

def test_eval_metric_score():
    """评估测试：量化输出，避免主观感受"""
    eval_cases = [
        {"input": "创建组件", "expected_tool": "file_writer"},
        {"input": "查询数据库", "expected_tool": "db_query"}
    ]
    
    passed_count = 0
    for case in eval_cases:
        # 假定此处调用真实 Prompt 解析
        mock_output_tool = "file_writer" if "组件" in case["input"] else "db_query"
        if mock_output_tool == case["expected_tool"]:
            passed_count += 1

    accuracy = passed_count / len(eval_cases)
    assert accuracy >= 1.0, f"Agent Tool 识别准确率低于 100%: 当前 {accuracy}"

不需要复杂的平台，仅凭标准 pytest 加上几百行防护代码，就能在 CI/CD 中把 90% 以上的 Agent 逻辑乱跑问题卡死在本地。

---

4. 跑分自动化：用 promptfoo 进行客观性能评估

除了代码测试外，独立开发者最头疼的是“修改了一句系统提示词（System Prompt），不知道对整体体验是变好了还是变差了”。

我们可以引入 promptfoo CLI 工具进行量化评测，拒绝拍脑袋决策。

编写评测配置文件并运行命令：

$ npx promptfoo eval -c promptfooconfig.yaml
------------------------------------------------------
Executing 20 test cases across 2 providers...
------------------------------------------------------
[Pass] Provider A (Claude-3.5): Accuracy 95.0%, Avg Cost: $0.012, Latency: 840ms
[Fail] Provider B (Custom-Agent): Accuracy 70.0%, Avg Cost: $0.004, Latency: 1200ms

Assertion Details:
  - Test Case #4: Expected JSON key "schema_version" not found.
  - Test Case #11: Infinite loop detected in tool fallback.
------------------------------------------------------
Eval completed. Output written to output.html

有了这份客观的对比大盘，谁好谁坏一目了然。打分低了就去查哪个 TestCase 报错，而不是凭感觉猜测大模型“今天心情不好”。

---

5. 独立开发者落地的 4 项自动化准则

一个人当团队用，就要靠系统机制替自己守关。

请在项目上线前复核这 4 条测试准则：

1. Tool 应有 Unit Test 覆写：所有暴露给 Agent 的函数/API，都应有对应的单元测试校验非法输入与越权行为。
2. 强制死循环熔断器：任何 Agent 循环逻辑应包含硬编码的 max_steps 或 max_tokens 阈值，禁止写 while True。
3. 关键流程引入 E2E：涉及到用户注册、下单、支付或核心导出功能的路径，应有一套 Playwright 自动化脚本每日定时巡检。
4. Prompt 改动应跑 Eval：不要随手修改生产环境 Prompt。每次修改提示词前，在本地用 promptfoo 或自定义数据集跑一次测试，对比准确率与延迟变化。