PentAGI vllm-mixed 混合模型测试报告解读：Qwen3.6-27B-FP8 与 DeepSeek-V4-Flash 的 295 项 Agent 配置验证

PentAGI vllm-mixed 混合模型测试报告解读：Qwen3.6-27B-FP8 与 DeepSeek-V4-Flash 的 295 项 Agent 配置验证

【免费下载链接】pentagiFully autonomous AI Agents system capable of performing complex penetration testing tasks项目地址: https://gitcode.com/GitHub_Trending/pe/pentagi

本文基于 PentAGI 仓库中的 vllm-mixed.report.md 测试报告，系统解读一次针对"混合模型部署"（vLLM 托管的 Qwen/Qwen3.6-27B-FP8 与 DeepSeek-V4-Flash 同时为不同 Agent 角色服务）的完整 LLM 配置验证过程。通过这份报告，你将掌握 PentAGI 的 13 个 Agent 角色如何被分配到不同模型、ctester 配置测试工具如何用 295 项用例逐项验证推理、函数调用、记忆与 JSON 输出能力，以及如何在自建 vLLM 环境中复现并评估自己的 Provider 配置。

报告背景：什么是 vllm-mixed，为什么要做混合模型测试

PentAGI 是一个全自主渗透测试 Agent 系统，内部由多个承担不同职责的 LLM Agent 角色协同工作。不同角色的工作负载差异巨大：有的角色（如simple）只做快速响应，有的角色（如primary_agent、refiner）需要深度推理与长链路决策。因此，在自建推理基础设施时，一个常见且经济的做法是"混合部署"——把对速度敏感的角色交给低延迟的非推理模型，把对推理质量敏感的角色交给更强的推理模型。

vllm-mixed.report.md记录的就是这样一种混合配置下的全量验证结果：

• Qwen/Qwen3.6-27B-FP8（通过 vLLM 部署）：承担 8 个角色——simple、simple_json、reflector、searcher、enricher、coder、installer、pentester，单次请求平均延迟约 0.23～0.24 秒；
• DeepSeek-V4-Flash：承担 5 个推理密集型角色——primary_agent、assistant、generator、refiner、adviser，单次请求平均延迟约 1.25～1.67 秒。

报告生成时间为 2026-07-23，最终结论为295/295（100%）全部通过，整体平均延迟 0.748 秒。这份报告的生成工具，是仓库 backend/cmd/ctester 中的 PentAGI Provider Configuration Tester（ctester），它会按真实 PentAGI 运行时的调用路径，逐一验证某个 Provider 配置下的每个 Agent 角色是否可用。

总体结果：295 项测试全部通过

以下是报告Overall Results部分的完整数据：

Total: 295/295 (100.00%) successful testsOverall average latency: 0.748s

几个值得注意的观察点：

1. 成功率 100% 是"可用性"结论，不是"质量"结论：这份报告回答的问题是"这套 Provider 配置在 PentAGI 的真实调用路径下能否稳定工作"，而不是"哪个模型能力更强"。报告所有用例全部通过，说明该混合配置达到了投产就绪（production readiness）状态。
2. 延迟差约 6～7 倍：Qwen 组平均 0.23s 级，DeepSeek 组平均 1.25～1.67s。simple_json只跑 7 项（因为该角色只处理 JSON 类型测试，见下文），平均 0.224s，是全报告最低。
3. Reasoning 标记：报告中除simple、simple_json外，其余角色均标记true。该标记来自测试执行过程中的 reasoning 状态（对应 ctester/main.go 中convertToAgentResults对TestResult.Reasoning的聚合逻辑，结构定义见 tester/testdata/result.go 的Reasoning字段）。需要说明的是，这份报告对应的实际混合配置与仓库 vllm-qwen3.6-27b-fp8.provider.yml 示例并不完全一致（示例中reflector、searcher、enricher通过enable_thinking: false关闭思考，而报告中这三个角色仍标记true），因此应以报告记录的实际配置为准。

测试用例体系：ctester 验证的到底是什么

在深入逐 Agent 数据之前，先理解这套测试的构成。测试用例全部定义在 backend/pkg/providers/tester/testdata/tests.yml，由 registry.go 中的LoadBuiltinRegistry通过go:embed内嵌加载，并按GetTestSuite(group)组织成测试套件。

测试分组（Group），对应 ctester 的--groups参数：

• basic：基础补全与流式补全测试（如数学计算、文本转换）；
• advanced：函数调用、上下文记忆、安全知识、文件编辑等进阶测试；
• json：JSON 模式输出与结构化输出测试；
• knowledge：渗透测试与网络安全领域知识问答测试。

测试类型（Type），决定用例如何执行（见 runner.go 的executeTest分发逻辑）：

• completion：纯文本补全，走provider.Call/CallEx；
• json：要求输出合法 JSON 并校验字段类型，走CallEx或CallWithExtraOptions（结构化输出）；
• tool：函数调用测试，要求模型按预期调用指定工具及参数，走CallWithTools。

能力门控（Capability）：adaptive_thinking、reasoning_off、structured_output三类能力测试不会盲目运行，而是由 capability.go 的capabilitySupported依据该 Agent 的实际加载配置（models.yml + Provider YAML）决定是否执行——只有当 PentAGI 运行时（pconfig.AgentConfig.BuildOptions、UsesAdaptiveThinking）真的会为该 Agent 触发对应行为时，测试才被收集。这样避免了"测了一个生产环境永远不会发出的请求"的伪结论。

此外，advanced组还包含一个由 Go 代码动态构建的多轮测试fileEditTestCase（见 runner.go 中collectTestRequests的注释）：它模拟"读取文件 → 通过 unified diff 编辑文件"的真实工具交换，每轮由测试自身回答工具结果并请求下一轮，是唯一无法用固定消息列表表达的用例。

详细结果（一）：Qwen/Qwen3.6-27B-FP8 快速组

该组 8 个角色共享同一模型，延迟均在 0.2～0.47s 区间。以下为报告记录的完整逐项延迟数据（单位：秒，全部 ✅ Pass）。

Basic Tests（8 项）：

Advanced Tests（16 项）：

Summary: 各角色均 24/24（100%）；simple平均延迟 0.244s、reflector0.243s、searcher0.238s、enricher0.231s、coder0.233s、installer0.238s、pentester0.239s。

观察要点：

• 最重的用例是"文件读取 + unified diff 编辑"（0.406～0.468s），它是唯一涉及多轮工具交互的用例，符合fileEditTestCase的设计预期；
• 记忆类测试（多轮上下文保持）对 Qwen 3.6 非常轻：Basic Context Memory Test在大部分角色上仅 0.2s 左右，但installer、pentester上出现了 0.417～0.429s 的峰值，说明模型对该 prompt 的长上下文处理存在一定波动；
• 安全知识问答（knowledge组）几乎全部稳定在 0.21s 左右，说明该模型对渗透测试领域知识检索的响应路径稳定。

simple_json：纯 JSON 角色（7/7）

simple_json是唯一只执行 JSON 类测试的角色。按照 runner.go 中isTestCompatibleWithAgent的规则，simple_json只接收TestTypeJSON用例。报告记录：

Advanced Tests：

Capability Tests：

Summary: 7/7（100%），平均延迟 0.224s。

其中structured_output是一项特殊的前瞻性能力测试（见 tests.yml 中该用例的注释）：它通过llms.WithStructuredOutput验证模型/后端是否具备schema 约束解码能力，即使 PentAGI 的AgentConfig.BuildOptions尚未正式接入该能力。测试 prompt 明确禁止 markdown 代码围栏，因为部分弱合规后端只会把 schema 当软提示；如果模型在明确禁止后仍包裹 ```json 围栏，则会被判定为真正的验证失败——意味着该配置尚不适合生产中的 schema 约束输出。该用例通过，说明 Qwen3.6-27B-FP8 后端已具备结构化输出就绪能力。

详细结果（二）：DeepSeek-V4-Flash 推理组

该组 5 个角色承担 PentAGI 中最需要推理的任务，延迟整体落在 0.2～3.9s 区间，波动明显大于 Qwen 组。以下为报告记录的完整逐项数据（单位：秒，全部 ✅ Pass）。

Basic Tests（8 项）：

Advanced Tests（16 项）：

Summary: 各角色均 24/24（100%）；primary_agent平均 1.671s、assistant1.627s、generator1.526s、refiner1.381s、adviser1.255s。

观察要点：

• 推理模型的"思考税"明显：连Simple Math这类基础用例也要 0.7～1.2s，这是 DeepSeek-V4-Flash 推理过程的固有开销，也解释了为何混合架构要把非推理角色交给 Qwen；
• 两个最重的用例：Vulnerability Assessment Tools（2.540～3.942s）与Read a file, then edit it via unified diff（3.727～3.804s），均接近 4 秒，属于该模型下耗时敏感的操作，在实际渗透流程中应纳入延迟预算；
• 存在明显"捷径"响应：refiner、adviser的部分知识问答（如Penetration Testing Methodology0.221s、SQL Injection Attack Type0.212～0.221s）和adviser的流式用例（0.208～0.249s）出现了接近 Qwen 级别的超低延迟，说明模型对这类确定性知识在部分轮次直接给出了短回答而省略推理；Cybersecurity Workflow Memory Test在refiner/adviser上也出现 0.239～0.241s 的异常低值，与同组其他角色 1.2～1.4s 形成鲜明对比；
• 波动是推理模型的常态：同一用例在不同角色间可差 10 倍以上（如SQL Injection Attack Type从 0.212s 到 1.488s），这与 prompt 措辞、模型当时的推理路径有关，不构成功能性问题——所有用例最终都通过。

为什么需要"混合"：从报告数据看角色分工合理性

将两组的延迟对比与 PentAGI 的角色职责结合起来看，这份混合配置的合理性就很清晰：

• primary_agent（主控 Agent）与assistant（协作者）：负责任务规划、决策与长链路推理，使用 DeepSeek-V4-Flash 获得更强的推理能力，代价是 1.6s 级延迟；
• generator、refiner、adviser：分别负责生成、精炼与建议，同样需要推理质量，使用 DeepSeek-V4-Flash；
• searcher、enricher、reflector：搜索、上下文增强、反思类角色，Qwen 3.6 的 0.23s 级延迟让高频调用路径保持敏捷；
• coder、installer、pentester：代码执行、环境安装与渗透执行角色，测试全部通过说明 Qwen3.6-27B-FP8 的 tool calling 与安全领域知识足以支撑实际执行任务。

ctester 工具原理：一次测试是如何跑起来的

这份报告由 backend/cmd/ctester 生成，核心调用链如下：

1. 参数解析（main.go）：-env（环境文件）、-type（Provider 类型，如 custom/openai/anthropic/gemini/bedrock/ollama/deepseek/glm/kimi/qwen/minimax）、-name（Provider 名称）、-config（Provider 配置文件路径）、-tests（自定义测试 YAML）、-report（报告输出路径）、-agents（逗号分隔的 Agent 类型）、-groups（逗号分隔的测试组）、-workers（并发 Worker 数，默认 4）、-verbose（详细输出）。
2. 加载测试注册表：tester.TestProvider（runner.go）优先使用-tests指定的自定义注册表，否则通过testdata.LoadBuiltinRegistry加载内嵌的tests.yml。
3. 收集请求：collectTestRequests按组遍历用例，跳过被streaming开关禁用的流式用例、与被测 Agent 类型不兼容的用例（isTestCompatibleWithAgent，simple_json只收 JSON 用例）、以及能力门控不满足的用例（capabilitySupported）。
4. 并行执行：executeTestsParallel使用带缓冲 channel 的 worker 池（-workers控制并发度），每个 worker 通过executeTest执行用例，并按用例形态分发到Call/CallEx/CallWithTools/CallWithExtraOptions；多轮用例（fileEditTestCase）在成功拿到首轮工具响应后循环推进，直到HandleToolResponse返回 false。
5. 聚合与产出：groupResults按 13 个 Agent 类型归组（结构见 tester/result.go），再由 main.go 中的convertToAgentResults汇总为 Basic/Advanced/Capability 三类子表，统计成功率、平均延迟与 Reasoning 标记（不支持的可选能力会被Unsupported标记并从成功率与平均延迟中剔除，见 main.go 与 testdata/result.go），最后通过PrintSummaryReport打印控制台报告、WriteReportToFile写出 Markdown 文件——本报告即该流程的产物。

如何复现并验证自己的混合配置

1. 准备模型端点：在一个（或两个）vLLM 实例上部署Qwen/Qwen3.6-27B-FP8，并确保 DeepSeek-V4-Flash 端点可达。仓库提供了 Qwen3.6 的完整采样参数参考，见 examples/configs/vllm-qwen3.6-27b-fp8.provider.yml：该文件为每个 Agent 角色独立配置了model、temperature、top_k、top_p、min_p、presence_penalty、repetition_penalty、n、max_tokens及可选的extra_body.chat_template_kwargs.enable_thinking，混合配置只需在对应 Agent 段落将model指向不同端点并调整采样参数即可。文件头部还给出了 Qwen 官方的推荐采样区间：通用任务temp=1.0, top_p=0.95, top_k=20，精确编码temp=0.6, top_p=0.95（coder、installer、pentester段即采用此配置）。
2. 运行 ctester：在 backend 目录下执行，例如：

go run ./cmd/ctester \ -type custom \ -config examples/configs/vllm-qwen3.6-27b-fp8.provider.yml \ -agents all \ -groups all \ -workers 4 \ -report vllm-mixed.report.md \ -verbose

3. 局部验证：可用-agents primary_agent,assistant只验证推理组，或用-groups json只验证 JSON/结构化输出能力；-tests支持传入自定义 YAML 扩充用例；-verbose会打印每个用例的逐条 PASS/FAIL 与延迟日志（对应 runner.go 中testWorker的日志输出）。
4. 结果判定：报告中的Unsupported与失败是两类信号——前者表示模型主动拒绝某可选能力（如结构化输出不支持），配置本身无误；后者才是需要排查的真实故障。

结论

vllm-mixed.report.md展示了一个经过完整验证的 PentAGI 混合推理架构参考：以 0.23s 级低延迟的 Qwen3.6-27B-FP8 承担 8 个高频/执行类角色，以 1.2～1.7s 级的 DeepSeek-V4-Flash 承担 5 个推理密集型角色，全部 295 项能力验证 100% 通过。报告同时展示了 PentAGI 的 ctester 工具"只测生产真实路径"的设计原则——通过类型兼容过滤、能力门控、多轮工具模拟与结构化输出前瞻验证，让一份报告既能回答"配置能否工作"，也能回答"部署后每个角色会有多快"。

【免费下载链接】pentagiFully autonomous AI Agents system capable of performing complex penetration testing tasks项目地址: https://gitcode.com/GitHub_Trending/pe/pentagi