PentAGI 本地化部署实战：Ollama 上 Qwen3 32B fp16 推理模型的 Agent 功能测试报告解读

PentAGI 本地化部署实战：Ollama 上 Qwen3 32B fp16 推理模型的 Agent 功能测试报告解读

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

本篇技术指南以 examples/tests/ollama-qwen332b-fp16-tc-report.md 这份真实测试报告为主体，深入讲解 PentAGI 如何通过内置的 Provider 配置测试工具（ctester）对本地 Ollama 部署的qwen3:32b-fp16-tc推理模型进行全量 Agent 功能验证。读者读完后，将掌握 PentAGI 的 LLM 测试体系结构、13 类 Agent 角色的测试覆盖范围、测试报告的生成与解读方法，以及如何在本地复现这套验证流程。

一、报告背景：为什么要对本地 LLM 做 Agent 功能测试

PentAGI 是一套能够自主执行复杂渗透测试任务的 AI Agent 系统。系统内部分工为 13 类不同的 Agent 角色——从简单的问答助手（simple）、JSON 输出助手（simple_json），到负责渗透测试流程编排的 primary_agent、负责报告生成的 generator/refiner、负责搜索的 searcher/enricher、负责编写与安装工具的 coder/installer、以及最终执行攻击动作的 pentester 等。

在生产环境接入任意一个 LLM Provider 之前，必须回答一个关键问题：这套模型的推理能力、工具调用能力、上下文记忆能力、JSON 结构化输出能力，能否支撑上述所有 Agent 角色的真实工作负载？这也是仓库中ctester（Provider Configuration Tester）工具存在的意义。

qwen3:32b-fp16-tc是部署在本地 Ollama 服务器上的 Qwen3 32B 模型（fp16 精度）。这份报告就是对其运行 281 个测试用例后的完整结果记录，生成于 2025-07-19，最终成绩为279/281（99.29%）成功，整体平均延迟 6.925s。

二、总体结果：13 类 Agent 的成功率与延迟概览

报告第一部分给出了所有 Agent 类型的总体成绩。每个 Agent 均使用同一模型qwen3:32b-fp16-tc，Reasoning列统一为true，表示该模型在测试中呈现了推理/思考输出（测试框架会依据模型是否产出思考过程进行判定）。

Total: 279/281 (99.29%) successful testsOverall average latency: 6.925s

从数据可以得出几个直接结论：

• 11/13 的 Agent 角色取得 100% 通过率，说明该模型在基础指令遵循、工具调用、上下文记忆等通用能力上表现稳定；
• simple_json 仅运行 5 个用例（而非 23 个），这是测试框架的刻意设计：simple_jsonAgent 只负责 JSON 类测试，其余类型测试对它不适用（详见下文"测试与 Agent 的匹配规则"）；
• 两个失败用例全部集中在同一个测试项——"Penetration Testing Memory with Tool Call"（带工具调用的渗透测试记忆测试），发生在primary_agent与enricher上，将在第五节专门分析。

三、这套测试是怎么跑起来的：ctester 工具与测试框架

3.1 ctester：Provider 配置测试命令行工具

报告由仓库中的ctester工具生成，入口位于 backend/cmd/ctester/main.go。它支持在本地直接对任意已接入的 Provider 类型运行测试：

cd backend go run ./cmd/ctester \ -type ollama \ -config ../examples/configs/ollama-qwen332b-fp16-tc.provider.yml \ -report ../examples/tests/ollama-qwen332b-fp16-tc-report.md \ -workers 4

主要命令行参数如下（对应 main.go 中的 flag 定义）：

当-type ollama时，createProvider 会检查cfg.OllamaServerURL是否为空，为空则直接报错退出；随后调用ollama.DefaultProviderConfig(cfg)构建 Provider 实例。这提醒我们：运行 Ollama 测试前必须确保本地 Ollama 服务已启动且地址配置正确。

3.2 测试执行内核：TestProvider 与并行 Worker

ctester本身只负责参数解析与 Provider 构建，真正的测试执行位于 backend/pkg/providers/tester/runner.go 的TestProvider函数。其核心流程为：

1. 收集测试请求（collectTestRequests）：根据配置的 Agent 类型与测试组，从测试注册表生成agentType × testCase的所有组合，并过滤掉与 Agent 不兼容或模型不支持能力的用例；
2. 并行执行（executeTestsParallel）：使用带缓冲 channel 的 worker 池并发运行，worker 数量由WithParallelWorkers控制（默认 4）；
3. 结果聚合（groupResults）：按 13 类 Agent 类型把结果整理成ProviderTestResults结构（见 backend/pkg/providers/tester/result.go）。

测试配置通过函数式选项（TestOption）注入，定义在 backend/pkg/providers/tester/config.go：

// 默认配置：全部 Agent 类型 × basic/advanced/knowledge 三组，开启流式测试，4 个并行 worker func defaultConfig() *testConfig { return &testConfig{ agentTypes: pconfig.AllAgentTypes, groups: []testdata.TestGroup{testdata.TestGroupBasic, testdata.TestGroupAdvanced, testdata.TestGroupKnowledge}, streamingMode: true, verbose: false, parallelWorkers: 4, } }

3.3 报告生成链路

报告的 Markdown 格式由 backend/cmd/ctester/report.go 的WriteReportToFile生成。观察该函数即可理解报告的结构逻辑：

• Overall Results 表格：遍历所有 Agent 汇总成功数、成功率与平均延迟，并累计出 Total 行；
• Detailed Results：每个 Agent 一节，按 Basic Tests / Advanced Tests 分组输出，失败用例附带截断至 150 字符的错误信息（EscapeMarkdown转义后写入）；
• Capability Tests：当测试结果中存在能力门控用例（adaptive thinking / reasoning off / structured output）时单独成表。本次报告中未出现该章节，说明这套配置未触发能力类用例（详见第六节的能力门控机制）。

四、测试套件全景：281 个用例从哪来

4.1 内置测试注册表

所有内置测试用例定义在 backend/pkg/providers/tester/testdata/tests.yml，通过go:embed编译进二进制（见 backend/pkg/providers/tester/testdata/registry.go 的LoadBuiltinRegistry）。每个用例包含id、name、type（completion / json / tool）、group（basic / advanced / json / knowledge）、streaming开关、prompt 或多轮 messages、工具定义与期望输出。

按测试类型划分（枚举定义见 backend/pkg/providers/tester/testdata/models.go）：

4.2 测试组与 23 项标准用例

默认每个标准 Agent 运行 23 个用例（8 项 Basic + 15 项 Advanced），即报告每个 Agent 小节中看到的清单：

Basic Tests（8 项）——通用能力基线：

Advanced Tests（15 项）——面向真实业务负载：

• 高级工具调用：JSON Response Function、Search Query Function、Ask Advice Function（含流式版本），要求模型根据指令选择正确工具并填充合法参数；
• 上下文记忆：Basic Context Memory Test（多轮对话记忆）、Function Argument Memory Test（记住此前工具调用参数）、Function Response Memory Test（记住工具返回内容）；
• 渗透测试域知识：Penetration Testing Methodology（侦察/利用等概念）、Vulnerability Assessment Tools（nmap 用途）、SQL Injection Attack Type、Penetration Testing Framework（Metasploit）、Web Application Security Scanner（Burp Suite）、Penetration Testing Tool Selection（根据"需要网络扫描"调用 nmap 工具并传参 target=192.168.1.1、scan_type=TCP）；
• 端到端业务场景：Penetration Testing Memory with Tool Call——完整模拟"资产发现 → 端口扫描 → Web 漏洞扫描 → 生成报告"的多轮渗透测试流程，要求模型在最后调用generate_report工具汇总目标 IP 与发现；
• 复杂安全工作流记忆：Cybersecurity Workflow Memory Test——长链条多轮交互后，回答"与 10.0.0.50 关联的域名是什么"。

JSON 组（5 项）：仅simple_jsonAgent 运行，包含 Person Information JSON、Project Information JSON、User Profile JSON 及流式 JSON 输出等，重点校验 JSON 字段的类型正确性（如 age 必须是数字而非字符串）。

4.3 测试与 Agent 的匹配规则

为什么simple_json只有 5 个用例？规则在 runner.go 的isTestCompatibleWithAgent中：

switch agentType { case pconfig.OptionsTypeSimpleJSON: // simpleJSON agent only handles JSON tests return testType == testdata.TestTypeJSON default: // all other agents handle everything except JSON tests return testType != testdata.TestTypeJSON }

即simple_json只跑 JSON 类用例，其余 Agent 跑除 JSON 外的全部用例——这解释了报告中两类 Agent 的用例数量差异（5 vs 23）。

五、逐 Agent 结果解读与失败用例分析

5.1 各 Agent 成绩汇总

由于除simple_json外，其余 12 个 Agent 运行的是同一套 23 项用例，报告对各 Agent 的明细可汇总为：

延迟层面的观察：单用例延迟大致呈两档分布——简单用例 2.5～8s，而涉及长多轮上下文的用例（Function Response Memory Test、Penetration Testing Memory with Tool Call、复杂框架问答）普遍落在 10～24s，其中 pentester 的 Function Response Memory Test 达到 22.963s，searcher 的 Vulnerability Assessment Tools 达到 24.191s。这符合本地 fp16 推理模型在处理超长上下文时的典型表现。

5.2 两个失败用例的完整明细

primary_agent（22/23，95.65%）：

enricher（22/23，95.65%）：

5.3 失败根因分析

该用例定义于 tests.yml，是一个 9 轮 messages 的长对话：系统提示要求"必须使用工具帮助用户并记住所做之事"，对话依次是"对 192.168.1.100 做安全评估 → 扫描开放端口（nmap）→ 检查 80 端口 Web 应用（web_scan，发现 SQL 注入）→ 通过工具调用生成汇总报告"。测试框架随后断言：模型必须发起generate_report工具调用，且参数 target=192.168.1.100、findings 包含端口与 SQL 注入发现。

两个 Agent 的失败信息均为expected function 'generate_report' not found in tool calls，即模型在最后一轮没有发起generate_report调用。结合模型行为可以推断：在超长工具调用链末尾，qwen3:32b-fp16-tc在这两个角色的采样配置下更倾向于输出自然语言总结而非再次发起工具调用（该结论属于基于失败模式的推断，报告中未给出模型具体输出内容）。值得注意的是，其余 11 个 Agent 在完全相同的用例上均通过，说明问题并非模型能力缺失，而是与特定 Agent 角色组合下的偶发行为有关——这也正是"逐 Agent 全量测试"这一设计的意义所在：它能暴露单一模型在不同角色配置下的差异表现。

六、配置层面的对照：为什么这套配置能跑出这个成绩

6.1 被测 Provider 配置文件

本次测试使用的配置为 examples/configs/ollama-qwen332b-fp16-tc.provider.yml，13 个 Agent 统一指向同一模型：

simple: model: "qwen3:32b-fp16-tc" n: 1 max_tokens: 40000 # ...（其余 12 个 Agent 块与此完全一致） pentester: model: "qwen3:32b-fp16-tc" n: 1 max_tokens: 40000

配置中未显式设置temperature、top_p等采样参数，此时 Provider 会回落到各 Provider 自身的默认配置。以 backend/pkg/providers/ollama/config.yml 为例，Ollama 的默认配置为所有 Agent 设置了temperature: 1.0、top_p: 0.9~0.95、n: 1，并按角色分配不同max_tokens（如 primary_agent/assistant 为 16384，generator/coder 为 20480，simple/adviser/searcher/reflector/enricher/pentester 为 4096~8192）。这些默认值对应的参数名与取值范围在 backend/pkg/providers/pconfig/config.go 的AgentConfig.Validate中有明确校验：temperature ∈ [0,2]、top_p ∈ [0,1]、repetition_penalty ∈ [0,2]、frequency/presence_penalty ∈ [-2,2]、reasoning.max_tokens ∈ [0,32768]。

由于被测配置文件把max_tokens统一放大到 40000，可以推断测试意图是让模型在长工具调用链与生成型任务上获得充分的输出空间，避免因输出截断导致失败。

6.2 能力门控机制：为什么报告中没有 Capability Tests 章节

测试框架支持三类"能力门控"用例（定义见 models.go）：

• adaptive_thinking：验证显式reasoning: {mode: adaptive}或仅支持自适应推理的模型；
• reasoning_off：验证显式reasoning: {mode: off}关闭思考；
• structured_output：验证 schema 约束的结构化输出（当前仅对simple_json调度）。

这些用例只有当 Agent 的实际加载配置在真实 PentAGI 流程中会触发对应 wire 行为时才运行（capabilitySupported与pconfig.AgentConfig.BuildOptions严格镜像）。本次被测配置没有设置任何reasoning块，也未声明结构化输出能力，因此这些用例被静默跳过，报告相应章节自然缺失——在解读报告时，"没有能力测试章节"不等于"未测试"，而是"该配置下不适用"。

七、如何复现与扩展这套测试

7.1 复现步骤

1. 准备本地 Ollama 环境：启动 Ollama 服务，拉取模型：ollama pull qwen3:32b-fp16-tc（fp16 精度需确认宿主机显存/内存充足）；
2. 配置 Provider 地址：确保cfg.OllamaServerURL对应的环境变量已设置，否则 ctester 会以 "Ollama server URL is not set" 退出；
3. 运行测试：

cd backend go run ./cmd/ctester \ -type ollama \ -config ../examples/configs/ollama-qwen332b-fp16-tc.provider.yml \ -report ../examples/tests/ollama-qwen332b-fp16-tc-report.md \ -workers 4 -verbose

4. 查看报告：-report指定的路径会生成与本文解读格式完全一致的 Markdown 报告；不加-report时则仅打印终端汇总表（格式对应 report.go 的PrintSummaryReport）。

7.2 常用变体

• 只测某类 Agent：-agents pentester,primary_agent；
• 只跑某个测试组：-groups basic,knowledge；
• 自定义用例：编写符合 tests.yml 格式的 YAML 文件，用-tests传入；自定义注册表通过testdata.LoadRegistryFromYAML解析（见 registry.go），可用WithCustomRegistry选项注入；
• 控制并发：-workers 8可加速，但需注意本地推理服务的吞吐上限；
• Web 界面方式：PentAGI 前端也暴露了 Provider 测试能力（GraphQL MutationTestProvider，见 backend/pkg/graph/schema.resolvers.go），可在界面中针对单个 Agent 类型即时验证配置。

7.3 报告数据的可复现性提示

报告中的所有延迟数据（6.925s 整体均值、各用例 2.5~24s 区间）均依赖具体的硬件算力、并发度（workers=4）、Ollama 服务负载与模型量化状态，不同机器上的绝对值会存在差异。在评估"该模型是否适合投入生产"时，应更关注成功率与失败模式的稳定性，而非绝对延迟。

八、结论与实战建议

综合报告数据与框架设计，可以给出以下可操作的结论：

1. qwen3:32b-fp16-tc具备支撑 PentAGI 全角色流水线的能力：99.29% 整体成功率（279/281），13 个角色中 11 个 100% 通过，覆盖了工具调用、多轮记忆、渗透测试领域知识与 JSON 输出等全部关键能力；
2. 长工具调用链是本地模型的薄弱环节：唯一的失败点集中在"多轮渗透测试后要求再次发起工具调用生成报告"这一场景，且仅在 primary_agent 与 enricher 两个角色上出现。若这两类角色是生产核心，建议通过 Prompt 强化"必须用工具汇报结果"的约束，或更换/微调模型后重新跑同一份报告对比；
3. 测试框架本身就是质量基建：任何新的 Provider、模型或配置组合上线前，都可通过 backend/cmd/ctester/main.go 一键产出同规格报告（仓库examples/tests/下已积累 20 余份各 Provider 的测试报告可供横向对比），将"模型适不适合"从主观感受变为可量化的数据。

仓库内其他可继续深入的材料：测试用例全集 backend/pkg/providers/tester/testdata/tests.yml、并行执行内核 backend/pkg/providers/tester/runner.go、Agent 类型与采样参数定义 backend/pkg/providers/pconfig/config.go，以及同目录下其他 Provider 的测试报告（如 examples/tests/openai-report.md、examples/tests/gemini-report.md）。

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