1. 为什么“自用 Agent 的全面功能测试”不是跑个 demo 就完事？
“自用 Agent 的全面功能测试”这九个字，表面看是技术动作，实则是一道分水岭——它把真正动手做过 Agent 项目的和只在文档里划过重点的人，当场区分开。我见过太多人，在本地跑通curl -X POST http://localhost:8080/v1/chat/completions返回了{ "choices": [...] }就拍手庆祝“Agent 跑起来了”，结果上线三天，用户问一句“把上周三的会议纪要发我PDF”，系统直接返回{"error": "tool not found"}；或者批量处理 50 份合同文本时，内存暴涨到 12GB 后静默崩溃，日志里只有一行OOMKilled。这些不是边缘 case，而是自用场景下最常踩的坑。
关键词里没写，但热搜词反复出现的CLI、OpenAI 兼容、假模型、测试体系，已经暴露了核心矛盾：你不是在测一个 API，而是在测一个带状态、有工具链、会编排、能容错、还要和人长期交互的微型智能体系统。它不像 Web 服务那样请求-响应即结束，而更像一个值班的助理——你要确认它听清了指令（输入解析）、知道该找谁办事（工具路由）、能处理突发状况（错误降级）、记得住上下文（记忆管理）、不把机密信息当公开聊天记录（安全边界），甚至在断网后重连还能续上刚才说到一半的话（会话恢复）。
所以，“全面”二字，必须拆解为五个不可妥协的维度：
- 协议层兼容性：它是否真能当 OpenAI 官方 SDK 的“平替”？不是只骗过
openai.ChatCompletion.create()的调用签名，而是连 streaming 响应的 chunk 分割节奏、function_call字段的嵌套深度、tool_calls的数组索引稳定性都得对齐； - 工具链鲁棒性：你配的
search_web工具在目标网站改版后是否自动 fallback 到缓存？write_file在路径含中文或空格时是否报错？execute_python执行import pandas as pd; pd.read_csv("data.csv")时，是抛出ModuleNotFoundError还是优雅提示“请先安装 pandas”？ - 状态一致性：当用户连续发三条消息：“查天气”→“再查北京PM2.5”→“把上面两个结果对比”，Agent 是否在第三条时仍持有前两次的原始响应数据，而非只记住“天气”“PM2.5”两个关键词？
- CLI 交互真实性：
zcode cli --model llama3-70b --prompt "总结这份财报"这条命令，背后是否真实触发了模型加载、token 计数、流式输出、Ctrl+C 中断清理等全链路？还是仅仅 mock 了一个console.log("done")？ - 假模型验证价值：用
--mock-model启动时，它是否能精确模拟真实模型的延迟分布（P50=320ms, P95=1.2s）、错误率（0.8% timeout, 0.3% malformed JSON）、以及 token 限速行为（每分钟 3000 tokens）？如果假模型永远秒回且从不错，那测试就等于没做。
我去年给一个法律咨询 Agent 做验收测试，就卡在“假模型”这一环。开发团队用return {"choices": [{"message": {"content": "根据《民法典》第1024条..."}}]}硬编码响应，结果上线后发现真实 GPT-4 Turbo 在处理长条款引用时，会因 context 长度截断导致关键法条编号丢失。我们临时补了一套基于 Llama-3-8B-Instruct 的轻量级假模型，用真实 tokenizer 统计 token 分布，用time.sleep(random.gauss(0.8, 0.3))模拟延迟抖动，才暴露出编排层未做 response 截断校验的致命缺陷。这件事让我彻底明白：测试 Agent 的第一道防线，不是写多少 case，而是让假模型比真模型还像真模型。
提示：别迷信“测试覆盖率”。一个覆盖了 95% 代码行的测试套件，如果从未模拟过
tool_calls数组为空、function_call字段缺失、content为 null 这三种 OpenAI API 实际返回的合法但危险的响应结构，那它的价值约等于零。
2. 构建可落地的测试体系：从“能跑”到“敢用”的四层漏斗
市面上很多 Agent 框架的测试文档，止步于“如何启动测试服务器”和“写一个 assert response.status_code == 200”。这就像检查一辆车能不能点火，却从不测试刹车是否在雨天失灵、油箱告警后还能跑多远。真正的自用 Agent 测试体系，必须是漏斗形的四层结构——越往下，用例越少，但破坏力越强，每一层都在过滤掉上一层漏掉的风险。
2.1 协议层穿透测试：用 OpenAI 官方 SDK 当“探针”
这是最硬核、也最容易被跳过的环节。你的 Agent 必须接受 OpenAI Python SDK 的原生调用，而不是自己造一套 client。原因很简单：SDK 内部做了大量隐式处理——比如自动重试 429 错误、按max_tokens动态截断 prompt、将functions参数序列化为符合 OpenAI Schema 的 JSON Schema 格式。如果你的 Agent 只支持 curl 或 Postman 手动构造请求，那等于主动放弃了 SDK 层的兼容性保障。
实操步骤如下：
- 环境隔离：新建虚拟环境
python -m venv test-openai-sdk，仅安装openai==1.35.1（锁定版本，避免 SDK 升级引入新行为）； - 配置直连：修改 SDK 的 base_url 为你的 Agent 地址：
from openai import OpenAI client = OpenAI( base_url="http://localhost:8000/v1", # 指向你的 Agent 服务 api_key="sk-xxx", # 任意非空字符串，用于绕过 key 校验 )- 构造“压力包”用例：不测单次成功，而测 SDK 与你的 Agent 协作时的边界行为。例如：
- 发送
max_tokens=1的请求，验证 Agent 是否返回{"error": {"code": "invalid_request_error", "message": "max_tokens must be >= 10"}}而非直接 crash； - 发送
stream=True请求，用for chunk in client.chat.completions.create(...)迭代，检查是否每个 chunk 都含delta和finish_reason字段，且finish_reason在最后一个 chunk 出现； - 故意传入
functions=[{"name": "get_weather", "parameters": {}}]（空 parameters），验证 Agent 是否返回{"error": {"code": "invalid_function_parameters", ...}}而非 500 内部错误。
我曾发现某框架在处理functions参数时，会将空parameters对象错误地序列化为"parameters": "{}"，而 OpenAI SDK 期望的是"parameters": {}（JSON object，非 string）。这个 bug 在 curl 测试中完全无法暴露，因为 curl 不做参数序列化——它只管把字符串塞进 body。只有让 SDK 作为“中间人”，才能逼出这种底层协议错位。
2.2 CLI 交互链路测试：把命令行当用户来对待
CLI 不是辅助工具，而是自用 Agent 的第一用户界面。zcode cli、codex cli、hermes agent这些热词反复出现，说明开发者早已习惯用命令行快速验证想法。但多数 CLI 测试只停留在“命令能执行”，忽略了真实用户操作中的毛刺感。
必须覆盖的五大交互断点：
- 中断韧性：运行
zcode cli --model qwen2-72b --prompt "生成1000行Python代码"后，按Ctrl+C，验证进程是否干净退出（无残留子进程）、临时文件是否被清除、日志是否记录INTERRUPTED而非ERROR； - 输入容错：输入
zcode cli --prompt "hello" --model ""（空 model），是否友好提示Error: --model is required而非AttributeError: 'NoneType' object has no attribute 'split'； - 流式输出保真度：启用
--stream时，终端是否实时刷新（非整块输出），且每行以\r结尾实现覆盖式更新（如进度条）； - 环境变量优先级：当同时设置
ZCODE_MODEL=llama3-8b环境变量和--model qwen2-7b命令行参数时，是否严格遵循“命令行 > 环境变量 > 配置文件”的覆盖顺序； - 跨平台路径处理：在 Windows 上执行
zcode cli --file "C:\Users\Me\report.txt"，验证路径是否被正确解析为C:\\Users\\Me\\report.txt而非C:UsersMeport.txt（反斜杠被误当转义符）。
一个血泪教训：我们曾用argparse解析--file参数，但未对 Windows 路径做os.path.normpath()处理。结果用户反馈“在 Windows 上总提示文件不存在”，而我们在 macOS 上测试一切正常。最后发现是argparse将C:\data\input.txt中的\d解析为 ASCII 字符d（八进制转义），导致路径变成C:datainput.txt。解决方案不是加文档说明“请用正斜杠”，而是 CLI 内部自动 normalize 所有路径——这才是自用产品的底线。
2.3 工具链混沌测试：用“故意搞砸”代替“祈祷别出错”
Agent 的能力不在于它能调用多少工具，而在于它调用失败时能否兜住。所谓“混沌测试”，就是主动制造工具故障，观察 Agent 的应对策略是否合理。这不是 QA 的额外工作，而是开发阶段必须内置的防御机制。
设计三类故障注入点：
- 网络层故障：用
mitmproxy拦截search_web工具的 HTTP 请求，随机返回503 Service Unavailable或408 Request Timeout，验证 Agent 是否重试（最多 2 次）、是否降级到本地知识库、是否向用户透明告知“网络暂时不可用，已切换至缓存结果”； - 计算层故障：对
execute_python工具，注入timeout=1秒限制，然后执行while True: pass，验证是否触发超时并返回{"error": "Execution timed out after 1s"}，而非让整个 Agent 进程卡死； - 数据层故障：修改
write_file工具的权限，使其对/tmp目录只有读取权，然后尝试写入，验证是否捕获PermissionError并提示“目标目录无写入权限，请检查路径或使用 --output-dir 指定其他位置”。
关键原则：所有工具调用必须包裹在统一的ToolExecutor中，该 executor 负责日志记录、耗时统计、错误分类（网络/计算/数据/业务）、以及预设的 fallback 策略。不要在每个工具函数里写try...except，那会导致策略碎片化。我们定义了标准错误码：TOOL_NETWORK_ERROR（重试）、TOOL_EXECUTION_ERROR（降级）、TOOL_PERMISSION_ERROR（引导用户），让编排层能基于 code 做决策，而非 parse 错误 message 字符串。
2.4 长周期会话压力测试：模拟真实用户的“三天三夜”
自用 Agent 最大的挑战不是单次问答，而是持续数小时、跨越多次中断的会话。用户可能上午问“整理会议纪要”，中午关机，下午打开继续问“把纪要里的待办事项同步到飞书”，晚上又追加“用表格对比三个方案的 ROI”。这要求 Agent 具备真正的状态记忆能力，而非依赖 session cookie 这种 Web 时代的残余物。
测试方法：构建一个 72 小时的“用户行为剧本”，包含：
- 时间跳跃：在会话中插入
sleep(3600)模拟用户一小时后回来； - 上下文污染：在关键步骤间插入无关问题，如“讲个笑话”，验证 Agent 是否在后续专业问题中仍能聚焦核心上下文；
- 状态衰减：设置 memory TTL=2h，2 小时后发起新请求，验证是否自动触发
memory.compact()清理旧条目，且 compact 后的 summary 是否准确保留关键事实（如“用户公司名：XYZ Tech，行业：SaaS”）； - 跨设备同步：用不同 CLI 实例（不同 terminal tab）模拟手机端和桌面端，通过共享的
memory_id读取同一份记忆，验证add_memory和get_memory的并发一致性。
我们曾发现一个严重 bug：Agent 使用 SQLite 存储记忆，但在高并发INSERT INTO memory时未加BEGIN IMMEDIATE事务，导致两条add_memory请求同时写入，产生重复主键冲突。修复方案不是简单加锁，而是引入 WAL 模式 +PRAGMA journal_mode=WAL，并将add_memory操作原子化为单条INSERT OR REPLACE语句——因为 SQLite 的REPLACE在冲突时会先 DELETE 再 INSERT，天然保证幂等性。
注意：不要用
redis或postgres替代 SQLite 来解决这个问题。自用场景下，SQLite 的零配置、单文件、ACID 保证，是唯一合理的选择。引入外部 DB 是典型的“过度工程”，它只会增加部署复杂度，而不会提升测试价值。
3. “假模型”的终极用法：不只是 Mock，而是构建可控的仿真沙盒
“假模型”这个词在热搜里高频出现，但绝大多数人只把它当return {"content": "mock response"}的快捷方式。这是对测试资源的巨大浪费。一个合格的假模型，应该是一个可编程、可观测、可复现的仿真沙盒，它要能回答三个问题：
- 当真实模型在 1.2 秒后返回一个含语法错误的 JSON 时，假模型能否在 1.23 秒后返回一模一样的错误？
- 当真实模型因 token 超限静默截断时，假模型能否按相同规则（如保留前 2000 tokens）生成截断后的响应？
- 当真实模型在 100 次调用中出现 3 次
503错误时，假模型能否在 100 次调用中精准复现这 3 次错误的位置（第 17、42、89 次）？
3.1 基于 Token 的响应生成器：让假模型“懂语言”
OpenAI 兼容接口的核心约束是 token。真实模型的响应长度、错误率、延迟，全部由输入 prompt 的 token 数决定。因此，假模型的第一能力，是精确 tokenizer 感知。
我们采用 Hugging Face 的transformers库加载与目标模型同架构的轻量 tokenizer（如Qwen2TokenizerFast），在假模型启动时预加载：
from transformers import AutoTokenizer tokenizer = AutoTokenizer.from_pretrained("Qwen/Qwen2-0.5B-Instruct") def estimate_delay(input_text: str) -> float: tokens = tokenizer.encode(input_text, add_special_tokens=False) token_count = len(tokens) # 模拟真实 Qwen2-7B 的延迟模型：base=0.4s + 0.015s/token return max(0.4, 0.4 + 0.015 * token_count)这样，当用户发送--prompt "请用 200 字总结《三体》第一部"（约 45 tokens），假模型返回延迟0.4 + 0.015*45 ≈ 1.075s；而发送--prompt "逐章分析《三体》全三部，每章不少于 500 字"（约 1200 tokens），延迟升至0.4 + 0.015*1200 = 18.4s。这比固定延迟time.sleep(1.0)有意义得多——它能真实暴露长 prompt 下编排层的超时设置是否合理。
3.2 错误注入引擎：让失败变得可预测
假模型必须提供错误注入开关，且错误类型要覆盖真实世界高频问题：
--error-rate 0.02：2% 概率返回{"error": {"code": "rate_limit_exceeded", "message": "Too many requests"}}；--malformed-json 0.005：0.5% 概率返回{"choices": [{"message": {"content": "{invalid json}}"}}]（故意损坏 JSON）；--truncation-ratio 0.3：30% 概率按max_tokens严格截断，且在截断处插入[TRUNCATED]标记。
关键技巧：错误注入必须与 token 计数联动。例如，当--max_tokens=100且输入 prompt 占用 85 tokens 时，剩余空间仅 15 tokens。此时若启用--truncation-ratio 0.3，假模型应生成一个恰好 15 tokens 的响应，并在末尾加[TRUNCATED]。这能直接验证你的 Agent 是否实现了response.content.rstrip("[TRUNCATED]")这样的清理逻辑。
3.3 可复现的随机种子：让每一次测试都可追溯
混沌测试最大的敌人是“偶现 bug”。今天复现了，明天又消失。根源在于随机数未 seed。假模型必须支持--seed 42参数，确保：
random.gauss(0.8, 0.3)生成的延迟序列完全一致；random.choices(["success", "timeout", "error"], weights=[0.97, 0.02, 0.01])的错误位置固定；- 甚至
uuid.uuid4()也被 monkey patch 为基于 seed 的 deterministic 版本。
这样，当你在 CI 中发现测试失败，只需记录下本次运行的--seed值，就能在本地 100% 复现。我们为此专门写了DeterministicUUID类：
import random class DeterministicUUID: def __init__(self, seed): self.rng = random.Random(seed) def uuid4(self): # 生成 128 位随机数，确保与标准 uuid4 行为一致 return uuid.UUID(int=self.rng.getrandbits(128))提示：假模型的配置不应写死在代码里。我们将其抽象为
MockConfig数据类，支持从 YAML 文件加载：delay_model: "qwen2-7b" error_rate: 0.015 malformed_json_rate: 0.003 truncation_ratio: 0.25 seed: 12345这样，不同测试场景（单元测试/集成测试/压测）可加载不同配置，无需改代码。
4. CLI 工具链的深度验证：从启动到退出的全生命周期审计
CLI 是自用 Agent 的门面，也是最易被忽视的测试盲区。lm studio cli 启动模型时提示“model not found”、codex cli 没有可用的终端或文件读取工具这些热搜问题，本质都是 CLI 生命周期管理的缺失。一个健壮的 CLI，必须经受住从zcode --help到kill -9的全链路拷问。
4.1 模型加载阶段：验证“找不到模型”不是甩锅借口
model not found错误之所以高频，是因为 CLI 把模型发现逻辑写得太理想化。真实场景中，模型可能：
- 存在子目录中（
models/qwen2-7b/gguf/qwen2-7b.Q4_K_M.gguf）； - 名称含版本号（
llama3-70b-v2.Q5_K_M.gguf）； - 由多个文件组成（
model.safetensors.index.json+model-00001-of-00003.safetensors）； - 需要特定加载器（
llama.cppvstransformers）。
测试方案：构建一个“模型仓库矩阵”，包含 12 种典型模型布局，用zcode --list-models命令扫描，验证：
- 是否列出所有有效模型（不遗漏
qwen2-7b，也不误报README.md）； - 是否正确识别模型格式（
.gguf→llama.cpp，.safetensors→transformers）； - 当指定
--model qwen2-7b时，是否优先匹配qwen2-7b.Q4_K_M.gguf而非qwen2-7b-fp16.safetensors（按精度排序）。
我们发现一个经典陷阱：CLI 用glob.glob("models/**/qwen2-7b*.gguf")查找模型，但**在某些 shell 中不支持递归。解决方案是弃用 glob，改用pathlib.Path("models").rglob("qwen2-7b*.gguf")，它在 Python 3.10+ 中原生支持，且跨平台一致。
4.2 运行时资源审计：监控每一个字节的来去
CLI 进程不是黑盒。你必须知道它启动时加载了多少内存、打开了哪些文件、创建了几个线程。否则，zcode cli占用 8GB 内存却只干了 10 行代码，你根本无从排查。
强制实施三项审计：
- 内存快照：在
main()函数入口和出口，用psutil.Process().memory_info().rss记录内存占用，差值即为 CLI 自身开销。阈值设定：纯推理 CLI < 200MB，带 UI 的 < 500MB； - 文件句柄检查：用
lsof -p $PID | wc -l统计打开文件数，验证是否在--file读取后及时close()，避免Too many open files； - 线程追踪：用
threading.enumerate()列出所有活跃线程，确认无遗留后台线程（如未 join 的 watchdog thread）。
一个真实案例：某 CLI 在启用--stream时，会创建一个StreamingResponseHandler线程处理 SSE。但用户Ctrl+C后，该线程未收到 stop signal，持续运行并 hold 住 socket 连接，导致下次启动时报Address already in use。修复方案是在signal.signal(signal.SIGINT, ...)中显式调用handler.stop()，并用thread.join(timeout=2)等待其退出。
4.3 退出码语义化：让 Shell 脚本能读懂你的意图
CLI 的退出码（exit code）是它与操作系统对话的唯一语言。0表示成功，这没问题；但1到255的每一个数字，都必须有明确定义。否则，当用户写zcode cli --prompt "test" && echo "success"时，一个本该表示“模型加载失败”的1，却被脚本当作通用错误忽略，导致后续流程误执行。
我们定义了严格的退出码规范：
| 退出码 | 含义 | 触发场景 |
|---|---|---|
| 0 | 成功 | 正常完成所有任务 |
| 64 | 命令行用法错误 | zcode --unknown-flag |
| 65 | 输入数据错误 | --file nonexistent.txt |
| 66 | 无法连接到模型服务 | --host localhost:9999但服务未启动 |
| 67 | 模型加载失败 | --model qwen2-7b但文件损坏 |
| 68 | 工具执行失败 | search_web返回 503 且无 fallback |
| 70 | 用户中断 | Ctrl+C |
测试时，用zcode cli --model invalid && echo "won't print"验证是否返回 67，而非笼统的 1。这能让自动化脚本做出精准决策，比如if [ $? -eq 67 ]; then echo "请检查模型文件"; exit 1; fi。
4.4 跨平台终端适配：Windows 的\r\n不是 bug，是特性
hermes agent windows安装、node安装codex cli很慢这些热搜，直指跨平台 CLI 的痛处。Windows 终端（cmd/powershell）和 Linux/macOS（bash/zsh）在换行、颜色、键盘事件上的差异，不是“兼容性问题”，而是必须正视的平台特性。
必须验证的三大终端行为：
- 换行符处理：在 Windows 上，
print("hello\nworld")输出hello\r\nworld，而sys.stdout.write("hello\n")可能只输出hello（\n被忽略）。解决方案是始终用print()，并在pyproject.toml中设置python_requires = ">=3.8"，利用 Python 3.7+ 的 universal newlines 模式； - ANSI 颜色支持：Windows 10+ 默认支持 ANSI，但老版本需
os.system('color')启用。测试时用rich库的Console(color_system="auto")，它会自动探测并降级； - 键盘事件：
Ctrl+C在 Windows PowerShell 中有时触发KeyboardInterrupt，有时触发EOFError。统一用try...except (KeyboardInterrupt, EOFError):捕获。
我们曾为zcode cli写了一个TerminalProbe工具，运行时自动检测：
- 当前终端是否支持
CSI u（光标位置查询）； sys.stdout.isatty()是否为 True；os.name和platform.system()的组合是否为('nt', 'Windows')；- 然后动态选择
rich的Console初始化参数。这比写一堆if sys.platform == "win32"更可靠。
注意：不要试图在 Windows 上完美模拟 Linux 的
stty行为。CLI 的目标不是成为终端模拟器，而是在每个平台上，用最 native 的方式完成任务。Windows 用户不关心ls -la，他们只关心zcode --prompt "列出当前目录"能否返回清晰的中文路径列表。
5. 测试即文档：如何让测试用例成为新人上手的第一份指南
测试代码不该是藏在tests/目录里的黑盒。对于自用 Agent，测试用例本身就是最鲜活、最准确的文档。当新同事入职，让他运行pytest tests/test_cli_integration.py -v，比给他发一份 PDF 文档更有说服力——因为测试会当场告诉他：“这个命令应该这样用，否则会报这个错”。
5.1 用测试用例还原真实工作流
避免写test_addition()这种抽象用例。每个测试文件，都应对应一个真实用户场景。例如：
test_legal_contract_review.py：模拟律师审阅 NDA 合同，包含--file contract.pdf、--tool extract_clauses、--tool check_compliance三步串联；test_research_assistant.py：模拟学生写论文，包含search_web "LLM safety papers 2024"、read_pdf "paper1.pdf"、summarize "key findings"的循环；test_devops_troubleshooter.py：模拟运维查日志，包含execute_shell "kubectl logs -n prod app-01"、analyze_log "error pattern"、suggest_fix "increase memory limit"。
每个测试函数名，就是一句完整指令：
def test_review_nda_contract_with_compliance_check(): """Run zcode cli to review NDA, extract clauses, and check GDPR compliance.""" result = run_cli("--file tests/data/nda_sample.pdf --tool extract_clauses --tool check_compliance") assert "GDPR Article 32" in result.stdout assert result.exit_code == 0这样，新人grep -r "review_nda" tests/就能找到完整示例，复制粘贴即可上手。
5.2 错误用例即最佳实践说明书
test_invalid_model_name_raises_helpful_error()这种测试，其价值远超验证功能。它定义了什么是“好的错误提示”。我们规定：所有错误用例，必须包含三要素：
- 错误复现步骤：
run_cli("--model llama3-70b-nonexistent")； - 预期错误消息：
assert "Model 'llama3-70b-nonexistent' not found. Available: llama3-70b, qwen2-7b"； - 用户行动指引：
assert "Run 'zcode --list-models' to see available models." in result.stderr。
这意味着，当用户真的输错模型名，他看到的不是冰冷的KeyError，而是一句带解决方案的提示。这比写 10 页文档更能降低用户门槛。
5.3 性能基线测试：让“变慢”变得可量化
“Agent 变慢了”是最高频的抱怨，但最难以验证。性能测试必须建立基线，并让每次 CI 运行都对比。我们为关键路径设置了硬性指标：
zcode cli --prompt "hello" --model qwen2-7b：P95 延迟 ≤ 1.5s；zcode cli --file report.pdf --tool summarize（10 页 PDF）：内存峰值 ≤ 1.2GB；zcode cli --stream --prompt "generate 100 lines"：首 token 延迟 ≤ 800ms。
测试脚本benchmark_cli.py会：
- 运行 10 次目标命令，记录每次的
time.time()差值； - 计算 P95 延迟、平均内存占用（用
psutil采样）； - 与
.benchmarks/baseline_qwen2_7b.json中的上一次结果对比； - 若 P95 延迟增长 > 15%，则
pytest.fail(f"Regression: latency increased from {old} to {new}")。
这迫使每次代码提交，都必须回答一个问题：“这次改动，让 Agent 变快了，还是变慢了？” 而不是靠主观感受。
5.4 测试报告即产品健康看板
pytest --html=report.html是最低要求。我们升级为pytest --junitxml=report.xml --tb=short，并将 XML 解析为一个极简的 Markdown 看板：
## Agent 健康报告（2024-06-15） | 指标 | 当前值 | 基线 | 状态 | |------|--------|------|------| | CLI 启动成功率 | 100% | 100% | ✅ | | OpenAI SDK 兼容性 | 98.2% | 98.0% | ✅ | | 工具链错误恢复率 | 92.5% | 90.0% | ✅ | | P95 延迟（qwen2-7b） | 1.42s | 1.45s | ✅ | | 内存峰值（PDF 总结） | 1.18GB | 1.20GB | ✅ | > 📌 今日新增：`test_streaming_interrupt_resilience` 通过，证明 Ctrl+C 不再导致僵尸进程。这个看板每天自动生成，推送到团队群。它不讲原理，只说事实——这才是自用产品最需要的透明度。
我在实际操作中发现，最有效的测试不是写得最多，而是让测试用例本身成为用户手册、错误说明书、性能仪表盘和健康报告的四合一载体。当一个新功能的 PR 被提交，审查者第一眼看到的不是代码，而是tests/test_new_feature.py里那个清晰的test_user_can_do_x_with_y_and_z()函数——那一刻，他就已经理解了这个功能该做什么、不该做什么、以及做错了会怎样。这才是“全面功能测试”最终要抵达的地方：测试不再是质量的守门员，而是产品的翻译官，把技术实现，翻译成人类可理解、可验证、可信赖的行为承诺。
