PentAGI 全 Agent 配置验证实录vLLM 部署 Qwen3.6-27B-FP8 的 295/295 测试报告深度解读与复现指南【免费下载链接】pentagiFully autonomous AI Agents system capable of performing complex penetration testing tasks项目地址: https://gitcode.com/GitHub_Trending/pe/pentagi这份技术指南以 PentAGI 仓库中的 vllm-qwen3.6-27b-fp8.report.md 测试报告为主线围绕如何在 PentAGI 中验证一套面向 vLLM 自托管 Qwen3.6-27B-FP8 的多 Agent 配置是否可用展开。你将读懂报告里每一项数据背后的含义掌握 ctesterProvider 配置测试器的完整用法并理解测试框架在源码层面的执行与能力门控机制最终能够自己复现、批量验证任意 LLM Provider 配置。一、报告背景这套测试体系的定位PentAGI 是一套能够自主完成复杂渗透测试任务的 AI Agent 系统内部按职责划分了多种 Agent 角色主控、助手、代码生成、渗透测试、检索等每个角色对应一套独立的 LLM 调用参数。这意味着一套 Provider 配置是否可用取决于它是否能让所有 Agent 角色都稳定工作而不是只看单个对话效果好不好。这份报告正是为解决这个验证问题而产生的产物。它由 PentAGI 自带的ctesterProvider Configuration Tester工具自动生成入口在 backend/cmd/ctester/main.goMarkdown 报告格式由 backend/cmd/ctester/report.go 的WriteReportToFile生成报告头部的# LLM Agent Testing Report、Generated:时间戳、总体结果表结构均出自该函数。报告针对的目标是运行在vLLM上的Qwen/Qwen3.6-27B-FP8模型。根据配套配置 vllm-qwen3.6-27b-fp8.provider.yml 文件头注释该模型具有以下特征这些信息来自配置注释实际以模型官方文档为准架构混合注意力75% DeltaNet 25% 全注意力4816 层上下文原生 262K可经 YaRN 扩展到 1M视觉属于 VLM带视觉编码器即使纯文本任务也会占用显存FP8 量化适合在 vLLM 上低成本自托管。测试于 2026-07-23 11:02:56 UTC 执行覆盖 13 种 Agent 配置、共295 个测试用例全部通过100%整体平均延迟 3.325 秒。二、总体结果13 种 Agent 配置 295/295 全部通过报告开篇的 Overall Results 表格是整份报告的核心结论原表完整如下AgentModelReasoningSuccess RateAverage LatencysimpleQwen/Qwen3.6-27B-FP8true24/24 (100.00%)1.297ssimple_jsonQwen/Qwen3.6-27B-FP8false7/7 (100.00%)1.093sprimary_agentQwen/Qwen3.6-27B-FP8true24/24 (100.00%)4.874sassistantQwen/Qwen3.6-27B-FP8true24/24 (100.00%)4.496sgeneratorQwen/Qwen3.6-27B-FP8true24/24 (100.00%)4.518srefinerQwen/Qwen3.6-27B-FP8true24/24 (100.00%)5.409sadviserQwen/Qwen3.6-27B-FP8true24/24 (100.00%)4.690sreflectorQwen/Qwen3.6-27B-FP8true24/24 (100.00%)2.113ssearcherQwen/Qwen3.6-27B-FP8true24/24 (100.00%)0.494senricherQwen/Qwen3.6-27B-FP8true24/24 (100.00%)0.270scoderQwen/Qwen3.6-27B-FP8true24/24 (100.00%)4.309sinstallerQwen/Qwen3.6-27B-FP8true24/24 (100.00%)4.625spentesterQwen/Qwen3.6-27B-FP8true24/24 (100.00%)3.453sTotal: 295/295 (100.00%) successful testsOverall average latency: 3.325s关于表中各列需要注意几点Reasoning 列从 report.go 的聚合逻辑看该列表示该 Agent 的测试结果中是否检测到推理thinking输出而非简单对应配置里是否开启了思考模式Success Rate 列成功率与平均延迟均排除被标记为Unsupported能力不受支持的用例——代码注释明确指出不受支持的可选能力不计入成功率它属于尝试过但该模型不提供而非尝试后失败见 backend/cmd/ctester/main.go从延迟分布看13 种 Agent 配置分为三个梯队轻量级enricher 0.27s、searcher 0.49s、中间层simple、simple_json、reflector、重型推理型refiner、primary_agent、installer 等 4~5s 级这与各 Agent 配置的采样参数和是否启用思考模式直接相关详见第五节。三、逐 Agent 详细结果与延迟矩阵原报告对每个 Agent 按 Basic Tests / Advanced Tests 分组列出了每个用例的延迟。为便于横向对比下面将全部数据重组为矩阵形式每个数据点均来自原报告未做删减所有用例结果均为 ✅ Pass错误列为空。3.1 基础测试矩阵8 项 × 13 Agent单位秒测试用例simpleprimary_agentassistantgeneratorrefineradviserreflectorsearcherenrichercoderinstallerpentesterSimple Math0.8173.8403.5072.5853.6993.7870.6110.6720.2172.7832.6412.630Text Transform Uppercase0.8732.7571.8972.6283.0122.6830.6090.2080.2122.4972.6462.407Count from 1 to 50.61623.29724.44223.20223.39222.76420.1270.2140.20922.54522.9843.551Math Calculation0.5232.0851.7691.9851.9612.0600.5500.2170.2072.0902.0591.991Basic Echo Function0.9421.5931.9901.7912.7612.3301.4340.2150.2212.1651.8561.816Streaming Simple Math Streaming0.5121.7331.8662.5902.3492.2560.5590.2920.2742.5312.4491.833Streaming Count from 1 to 3 Streaming0.6333.0923.9953.3573.0903.9090.7510.2430.2614.6194.6934.556Streaming Basic Echo Function Streaming1.3772.5542.5542.5042.2264.5871.4740.4750.4772.3142.3163.5263.2 进阶测试矩阵16 项 × 13 Agent单位秒测试用例simpleprimary_agentassistantgeneratorrefineradviserreflectorsearcherenrichercoderinstallerpentesterJSON Response Function1.3423.3712.2562.9823.1520.5191.4020.2910.2531.9652.6022.596Search Query Function0.8901.1651.6872.2552.8040.2970.8180.3170.2871.7621.5961.433Ask Advice Function1.1503.0852.0962.1743.4654.1671.8050.4020.2352.1142.7802.162Streaming Search Query Function Streaming0.8841.5861.6091.7191.7431.6871.0350.3280.2321.4591.6411.209Basic Context Memory Test0.6353.6083.2803.1383.2832.9570.7930.2140.2123.0152.4583.880Function Argument Memory Test0.5811.4221.5191.3501.5672.4400.5910.2140.2881.9831.9621.940Function Response Memory Test0.5513.6312.9052.3531.5503.1611.0430.2390.4451.8501.8241.501Penetration Testing Memory with Tool Call1.6913.0603.2066.0863.8543.5861.8450.2620.4092.9772.9692.826Cybersecurity Workflow Memory Test0.6002.6913.1672.9402.2323.0170.8190.2290.3136.1592.2462.473Read a file, then edit it via unified diff3.8864.4898.1115.9385.5114.2543.8520.5790.4283.9495.0414.081Penetration Testing Methodology3.1639.4358.55910.4339.6518.8912.2145.1380.2228.19816.87111.146Vulnerability Assessment Tools2.43012.1496.9737.99411.0798.6172.5140.2210.2147.7227.2807.677SQL Injection Attack Type0.5304.3133.1833.72615.5033.4271.1620.2120.2064.8453.4753.017Penetration Testing Framework3.28210.6168.2947.25113.21513.3481.4000.2140.2177.5088.6017.160Web Application Security Scanner2.1067.3405.9024.2515.9975.3511.9470.2120.2104.2165.1775.180Penetration Testing Tool Selection1.1084.0463.1323.1752.7132.4621.3500.2370.2142.1372.8302.2673.3 JSON 专项simple_json7 项单位秒测试用例分组结果延迟Vulnerability Report Memory TestAdvanced✅ Pass2.003sPerson Information JSONAdvanced✅ Pass0.787sProject Information JSONAdvanced✅ Pass0.767sUser Profile JSONAdvanced✅ Pass0.904sStreaming Person Information JSON StreamingAdvanced✅ Pass0.890sJSON Array Response Without SchemaAdvanced✅ Pass1.350sStructured Output With JSON SchemaCapabilitystructured_output✅ Pass0.944s3.4 数据背后的延迟特征分析从矩阵可以读出几个有价值的规律以下为基于报告数据的观察供排障参考Count from 1 to 5是最大的延迟异常点。该用例在 primary_agent23.297s、assistant24.442s、generator23.202s、refiner23.392s、adviser22.764s、coder22.545s、installer22.984s上普遍耗时 20 秒以上而在 pentester 上仅 3.551s、在 searcher/enricher 上不足 0.25s。对照配置可以发现这些慢速 Agent 的配置均未显式关闭思考模式未设置enable_thinking: false而 searcher、enricher、simple 均显式禁用了思考。可以推断该用例的高延迟与模型思考 token 的生成长度有关该用例带有较长的 system 提示并要求精确输出触发模型长时间内部推理。searcher / enricher 几乎瞬时完成。这两个角色在配置中禁用了思考、温度 0.7且承担的是检索/富化类轻任务其平均延迟0.494s / 0.270s在所有 Agent 中最低。refiner 是重型推理角色中平均延迟最高的5.409s且SQL Injection Attack Type单用例达到 15.503s、Penetration Testing Framework达到 13.215s说明其对专业领域问答的推理长度更长。所有Read a file, then edit it via unified diff用例全部通过。该用例是 runner 中唯一手工构造的、非 YAML 定义的动态多轮测试read_file → edit_file 的完整工具调用闭环13 种 Agent 配置均能在 0.4~8.1 秒内完成验证了该模型在真实文件编辑工作流中的工具调用稳定性。simple_json 的能力测试通过意义重大。Structured Output With JSON Schema验证的是模型后端对 schema 约束输出llms.WithStructuredOutput的原生支持能力。从 tests.yml 的注释可知该测试属于前瞻性预检——即使 PentAGI 运行时尚未完全接入该调用路径也要提前确认模型具备能力。四、复现这份报告ctester 完整使用指南4.1 前置条件一个可用的 vLLM 服务端已部署Qwen/Qwen3.6-27B-FP8兼容 OpenAI API 协议。PentAGI 仓库 examples/guides 目录下提供了 vLLM 部署相关参考指南如 vllm-qwen35-27b-fp8.md准备.env环境文件ctester 通过-env指定内部使用 godotenv 加载并读取项目配置从 backend/cmd/ctester 编译出 ctester 可执行文件。4.2 命令行参数ctester 的全部参数定义见 backend/cmd/ctester/main.go参数默认值说明-env.env环境文件路径-typecustomProvider 类型custom / openai / anthropic / gemini / bedrock / ollama / deepseek / glm / kimi / qwen / minimax-name空Provider 名称用于构造PROVIDER_NAME/MODEL_NAME-config空Provider 配置文件路径会同时覆盖 LLM 与 Ollama 的 server config-tests空自定义测试用例 YAML 文件路径覆盖内置注册表-report空Markdown 报告输出路径-agentsall逗号分隔的 Agent 类型simple、simple_json、primary_agent、assistant、generator、refiner、adviser、reflector、searcher、enricher、coder、installer、pentester-groupsall逗号分隔的测试分组basic、advanced、json、knowledge-workers4并行 worker 数-verbosefalse输出每个用例的 PASS/FAIL 详情4.3 复现命令要复现这份针对 vLLM Qwen3.6-27B-FP8 的完整测试对应 thinking 模式配置可执行./ctester \ -env .env \ -type custom \ -config examples/configs/vllm-qwen3.6-27b-fp8.provider.yml \ -agents all \ -groups all \ -workers 4 \ -verbose \ -report vllm-qwen3.6-27b-fp8.report.md-type custom对应 vLLM 这类 OpenAI 兼容自托管端点createProvider中custom分支使用custom.DefaultProviderConfig(cfg)构造见 backend/cmd/ctester/main.go-groups all会展开为 basic、advanced、json、knowledge 四个分组见 backend/cmd/ctester/main.go若只想快速验证某个角色如 pentester可改为-agents pentester只想跑知识域用例可改为-groups knowledge-report指定后报告将以与本文相同格式写入 Markdown 文件由WriteReportToFile生成见 report.go想要全量验证不带思考模式的另一套配置只需把-config换成 vllm-qwen3.6-27b-fp8-no-think.provider.yml 即可测试框架会按新配置重新执行全部用例。五、支撑这份报告的 Provider 配置详解报告的结果与 vllm-qwen3.6-27b-fp8.provider.yml 中的 13 个 Agent 配置一一对应。该配置文件头注释给出了官方推荐的采样参数基线通用任务temp1.0, top_p0.95, top_k20, min_p0.0, presence_penalty1.5, repetition_penalty1.0精确编码任务temp0.6, top_p0.95, top_k20, min_p0.0, presence_penalty0.0, repetition_penalty1.0。5.1 配置文件结构配置以agent 类型:为键每个条目包含统一的采样参数字段字段说明model模型标识此处为Qwen/Qwen3.6-27B-FP8temperature采样温度top_k/top_p/min_p采样截断参数presence_penalty/repetition_penalty重复惩罚n生成候选数均设为 1max_tokens最大生成 token 数均设为 32768json仅 simple_json 开启true表示强制 JSON 输出模式extra_body.chat_template_kwargs.enable_thinking是否关闭 Qwen 的思考模式false 表示关闭5.2 13 种 Agent 配置的差异设计这是理解延迟矩阵的关键。配置对 13 个角色做了四类差异化设计A 类关闭思考 低温temp 0.7——simple、simple_json、searcher、enricher。它们承担确定性任务回显、检索、JSON 输出显式设置enable_thinking: false避免思考 token 拖慢响应这与矩阵中它们 0.2~1.3s 的极低延迟吻合。B 类开启思考 通用采样temp 1.0——primary_agent、assistant、generator、refiner、adviser。作为对话/生成/规划类角色保持 thinking 模式以获得更高质量的推理延迟落在 4.5~5.4s。C 类reflectortemp 1.0但显式关闭思考——反射/校验类角色关闭思考但保持高温平均 2.113s。D 类精确编码参数temp 0.6, presence_penalty 0.0——coder、installer、pentester。这三个是实际动手执行代码与渗透操作的角色采用配置头注释中的精确编码任务推荐参数。值得注意pentester 平均延迟仅 3.453s且Count from 1 to 5异常慢的问题在它身上不明显3.551s提示低温 低 presence_penalty 的组合对推理长度有收敛作用。5.3 thinking 与 no-think 两套配置的对比仓库同时提供了 vllm-qwen3.6-27b-fp8-no-think.provider.yml其中所有 13 个 Agent 均设置了enable_thinking: false且温度统一为 0.7/1.0。两份配置形成 A/B 对照前者验证思考模式全开下的上限质量后者验证纯快速响应下的吞吐表现。实际部署时可按业务需求取舍——例如将 searcher/enricher 类低频思考角色与 pentester 类高频操作角色分开配置。六、测试框架源码级原理报告背后是一套完整可复用的测试执行框架位于 backend/pkg/providers/tester。6.1 执行流程入口是TestProvider见 runner.go流程分四步加载测试注册表默认使用内置注册表testdata.LoadBuiltinRegistry()数据源为 tests.yml也可通过-tests传入自定义 YAML收集测试请求collectTestRequests按测试分组 × Agent 类型展开所有用例组合过滤掉流式关闭、类型不兼容、能力不支持的请求其中Read a file, then edit it via unified diff用例由newFileEditTestCase()手工构造非 YAML并在每个 Agent 上使用独立实例以避免多轮对话状态串扰并行执行executeTestsParallel使用 channel worker pool 并发执行默认 4 个 worker可用-workers调整testWorker逐个执行用例聚合分组groupResults将结果按 13 种 Agent 类型归组映射到 result.go 定义的ProviderTestResults结构。6.2 用例执行路径executeTest见 runner.go按用例形态分派到不同的 Provider 调用带ExtraOptions当前仅 structured_output 能力测试→CallWithExtraOptions带消息与工具 →CallWithTools且若用例实现MultiTurnTestCase接口如文件编辑用例会循环处理工具调用 → 工具响应 → 再次调用的多轮闭环仅消息 →CallEx纯 prompt →Call。6.3 能力门控Capability Gating这是框架最精巧的部分。capability.go 中的capabilitySupported决定能力测试是否真的执行原则是只测试 PentAGI 真实运行时会发出的调用。adaptive_thinking自适应思考测试仅当该 Agent 的配置实际会触发llms.WithAdaptiveReasoning时运行UsesAdaptiveThinking判定见 pconfig/config.goreasoning_off测试仅当该 Agent 配置的推理模式显式为off时运行structured_output例外地无条件执行因为它是为即将接入的 simple_json 结构化输出路径做的前瞻预检——即使模型不支持也会被标记为Unsupported⊘而非失败不拉低成功率。这解释了为什么报告中每个 Agent 的用例数恰为 24能力门控让测试集合与配置动态对齐缺省能力的用例不会出现在结果里造成误报。6.4 测试用例注册表内置用例全部定义在 tests.yml按四类分组组织basic基础完成度数学、大小写、计数、系统-用户双角色消息、流式版本、基础函数调用echoadvanced函数调用JSON 响应、搜索、建议、上下文记忆链多轮消息 工具调用历史、文件编辑多轮闭环、推理能力测试json纯 JSON 输出、无 schema 的 JSON 数组、带 JSON Schema 的结构化输出knowledge渗透测试领域知识侦查、nmap、SQL 注入、Metasploit、Burp Suite、工具选择用于验证模型在安全领域的基础素养。知识域用例正是 PentAGI 的领域特色——它不仅验证模型能对话还验证模型懂渗透。七、从报告到实战如何把结论用起来作为配置准入门槛任何新的 LLM Provider 接入 PentAGI 前都建议跑一遍 ctester。仓库 examples/tests 目录下还沉淀了 openai、anthropic、deepseek、gemini、kimi、minimax、moonshot、novita、openrouter、ollama 等二十余份同格式报告可作为横向对比基线报告即配置验收单若某个 Agent 出现 ❌ Fail优先检查该 Agent 的采样参数尤其是思考模式开关是否与其任务类型匹配——参考第五节的四类差异化设计延迟基线用于容量规划整体平均 3.325s、单用例最高 24.4s 的实测数据可以作为评估 vLLM 服务端并发与排队策略的输入。若延迟不可接受可优先将低频角色searcher、enricher切换到 no-think 配置或为其分配独立实例持续回归升级模型版本、调整 vLLM 服务参数如显存、批处理后用同一命令重新生成报告并 diff 延迟矩阵可快速发现配置回归。总而言之这份 295/295 的报告证明在 vLLM 上以 FP8 量化的 Qwen3.6-27B-FP8经过 vllm-qwen3.6-27b-fp8.provider.yml 这样的分角色差异化配置可以完整支撑 PentAGI 全部 13 种 Agent 角色的工具调用、多轮记忆、JSON 输出与安全领域知识任务。借助 ctester 与这套开源的测试框架任何自托管模型都可以在接入生产流程前获得同样严谨、可复现、可横向对比的验证结论。【免费下载链接】pentagiFully autonomous AI Agents system capable of performing complex penetration testing tasks项目地址: https://gitcode.com/GitHub_Trending/pe/pentagi创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考