aig-skill-scan 信息收集提示词模板全解析：Agent Skill 安全审计的第一环

aig-skill-scan 信息收集提示词模板全解析：Agent Skill 安全审计的第一环

【免费下载链接】AI-Infra-GuardA full-stack AI Red Teaming platform securing AI ecosystems via Agent Scan, Skills Scan, MCP scan, AI Infra scan and LLM jailbreak evaluation.项目地址: https://gitcode.com/GitHub_Trending/ai/AI-Infra-Guard

本篇技术指南围绕 AI-Infra-Guard 子项目 aig-skill-scan 的 Info Collection（信息收集）阶段提示词模板展开，它位于 skill-scan/skill_scan/prompt/agents/project_summary.md，是整个 LLM 驱动的 Agent Skill 安全审计管线的起点。你将了解该模板如何引导审计 Agent 对目标 Skill 项目做结构化信息收集、输出七大章节的 Markdown 报告，以及这份报告如何通过源码实现注入到后续代码审计阶段，成为安全判定的证据底座。

一、模板在审计管线中的定位

aig-skill-scan 是 AI-Infra-Guard 生态中专用于AI Agent Skill 项目静态安全审计的子项目，面向 OpenClaw Skills 等以SKILL.md为核心定义文件的 Agent 技能包。根据 skill-scan/README.md 与 skill-scan/skill_scan/agent/agent.py 的说明，它支持两种运行模式：

• 单阶段模式（默认，standalone）：只运行 Code Audit 阶段，直接输出<vuln>XML 漏洞结果，速度快（约为完整管线的 1/3），适合独立 CLI 使用。
• 三阶段模式（--aig-mode）：完整执行Info Collection（信息收集）→ Code Audit（代码审计）→ Vulnerability Review（漏洞整理）三段流水线，用于 AI-Infra-Guard 平台前端的步骤化展示。

本次分析的project_summary.md正是三阶段管线中Stage 1「信息收集」的指令模板。它在Agent._scan_three_stage中被以ScanStage("1", stage1_name, "agents/project_summary", ...)的形式注册（见 agent.py），由三阶段管线执行。

结论：只有当扫描以--aig-mode方式运行时，本模板才会被真正加载执行；单阶段模式会直接跳过该阶段。因此本文讲解的"信息收集"能力是平台化审计模式下的标准前置环节。

二、模板原文全貌

模板全文如下（project_summary.md 原文继承）：

作为专业的软件工程与安全分析专家，您需要对目标 Agent Skill 项目进行全面的信息收集与分析。本阶段旨在为后续安全检测、架构评估和开发流程优化提供基础数据支撑。分析应基于项目实际内容，避免任何假设或概括，优先使用项目注释和文档中的自然语言。

任务要求

1. 分析项目结构，识别关键配置文件、主要模块和代码组织方式。
2. 理解项目的技术栈、构建过程、运行时架构及依赖管理。
3. 识别开发规范、测试策略、部署流程和安全设计。
4. 识别项目类型：检查项目根目录是否存在SKILL.md。如果存在，请将其识别为 "Agent Skill" 项目。
5. 为后续审计提供准确、可操作的基础信息，尽量减少不必要的工具调用。

输出要求生成一份详细的信息收集报告，使用 Markdown 格式。报告需基于输入数据如实总结，确保读者（对项目一无所知）能快速理解项目全貌。报告结构必须包含以下章节（如果输入数据中存在相关信息）：

• 项目概述：基础信息与项目定位（项目类型、核心功能、业务价值及用户群体）；技术架构与实现方案的高层次描述。
• Skill 特性分析（仅适用于 Agent Skill 项目）：SKILL.md摘要（提取name、description及核心指令概览）；工具/脚本清单（scripts/目录下的可执行文件及用途推断）；依赖与资源；安装指令分析（逐条列出并分析是否涉及下载执行、网络请求等）。
• 技术分析：编程语言与技术栈、构建和测试命令、代码风格指南、数据处理与存储方案、网络通信接口设计。
• 安全评估：权限需求与访问控制、数据处理安全性、网络暴露面分析、潜在安全隐患、安全注意事项。
• 开发与运维细节：测试说明、功能模块清单、部署流程。
• 附加信息：其他关键发现。

注意事项

• 报告内容必须严格基于输入数据，引用具体文件或代码片段时注明来源。
• 语言简洁、客观，避免主观推测，优先使用项目自身术语。
• 如果某些章节无数据支持，可省略并说明"无相关信息"。

该模板没有占位符变量，是一份自包含的纯指令型提示词，由 PromptManager 原样加载后拼入系统提示词（详见下文源码链路），其角色设定、任务要求、输出结构与注意事项共同构成信息收集阶段的完整行为规范。

三、任务要求逐条拆解：信息收集到底收集什么

模板开篇即定义了角色——"专业的软件工程与安全分析专家"，并强调三个原则：基于项目实际内容、避免假设或概括、优先使用项目注释和文档中的自然语言。这是信息收集阶段"证据导向"的基石：后续所有安全结论都必须建立在本阶段记录的事实之上。

3.1 分析项目结构，识别关键配置与模块组织

审计 Agent 需要先摸清目标项目的"骨架"：根目录下有哪些关键配置文件（如SKILL.md、pyproject.toml、package.json、requirements.txt等）、主要模块如何划分、代码如何组织。这一要求与源码中注入目录树的行为相互印证——在 Stage 2 代码审计阶段，ScanPipeline.execute_stage会把_build_repo_tree(repo_dir)生成的完整目录树注入用户消息，并明确提示"标注 [!] 的是字节码文件或位于依赖/缓存/构建目录内的文件，请重点审计这些位置，它们可能隐藏恶意载荷"（见 agent.py 与 L330-L342）。信息收集阶段虽不注入目录树，但其"结构识别"结论直接决定审计阶段关注哪些文件。

3.2 理解技术栈、构建过程、运行时架构与依赖管理

模板要求识别主要语言、框架、库和工具，理解构建与运行方式。与之配套，utils/project_analyzer.py 提供了classify_language/analyze_language/get_top_language三个函数，通过文件扩展名统计语言分布（.go→Go、.py→Python、.sh→Shell、.md→Markdown 等 21 类），并返回文件数最多的语言作为项目主语言。这为扫描结果的language字段提供了客观依据——当信息收集报告描述"项目主要由哪种语言构成"时，与统计结果保持一致。

3.3 识别开发规范、测试策略、部署流程与安全设计

模板要求审计 Agent 从配置文件中提取真实的构建/测试/部署命令（如 linter 配置、测试命令、CI 脚本），并关注项目声明的安全设计。这一信息的价值在于：后续审计可以据此区分"正常开发行为"与"越权/恶意行为"。例如，如果项目自带测试目录且测试代码中包含模拟凭据，那么 vuln_review 阶段的"误报识别"规则（见 vuln_review.md 第一阶段的"测试代码误报""占位符数据"过滤）就需要依赖这类背景信息来判断。

3.4 项目类型判定：SKILL.md 即 Agent Skill 的"身份证"

这是信息收集阶段最具决定性的一个动作：检查项目根目录是否存在SKILL.md，存在则识别为 "Agent Skill" 项目。

为什么这一步如此关键？因为 Skill 项目存在两种截然不同的形态（code_audit.md 开篇即说明）：

• 纯文档型 Skill：只包含SKILL.md和元数据文件，没有任何可执行代码。这类 Skill 的行为完全由 SKILL.md 中的描述和指令决定——它会引导 AI Agent 或用户按文档步骤操作。
• 代码型 Skill：除 SKILL.md 外还携带scripts/等可执行脚本。

审计标准要求：SKILL.md 中的安装指令、初始化命令、使用前置步骤，等同于代码行为，必须按与代码相同的标准进行安全审计。因此，信息收集阶段对 SKILL.md 的类型判定，直接决定了后续"Skill 特性分析"章节是否启用，也决定了代码审计阶段的分析重心。

3.5 工具调用纪律：为后续审计减负

模板明确要求"为后续审计提供准确、可操作的基础信息，尽量减少不必要的工具调用"。从 base_agent.py 的执行循环可见，Agent 每一轮迭代都会与 LLM 通信并处理工具调用，max_iter上限为 80 轮，超限会警告"达到最大迭代次数，返回当前结果"。信息收集阶段的收敛性直接决定了整个管线的 token 开销与时长。Agent 可用的工具集合由 tools/ 目录下的 XML schema 定义，包括file（读文件）、ls、grep、dir、base64_decode、thinking（思考记录）与finish（结束任务），由registry.py的@register_tool装饰器自动注册、dispatcher.py统一路由，最终以 XML 形式拼入系统提示词供 LLM 调用。

四、输出报告结构详解：七大章节的写作规范

模板规定报告必须包含以下章节（若输入数据中存在相关信息），下面逐章说明其写作要点与审计价值。

4.1 项目概述

• 基础信息与项目定位：项目类型（如 "Agent Skill"）、核心功能、业务价值及用户群体。
• 技术架构与实现方案：整体设计的高层次描述。

这一章节是后续所有读者的"项目速览"，也是漏洞报告中"功能描述是否与真实行为一致"的对照基准——如果 SKILL.md 声称的功能与代码实际行为不符，这本身就是异常信号。

4.2 Skill 特性分析（仅适用于 Agent Skill 项目）

• SKILL.md 摘要：提取name、description及核心指令概览。
• 工具/脚本清单：列出scripts/目录下的可执行文件及其用途推断。
• 依赖与资源：列出 Skill 依赖的外部包或资源文件。
• 安装指令分析：如果 SKILL.md 中包含安装/初始化指令，逐条列出并分析其行为（是否涉及下载执行、网络请求等）。

安装指令分析是本章节的重中之重。审计视角下，curl | bash管道执行远程脚本、从 pastebin/个人 GitHub 下载可执行文件、pip/npm 安装拼写劫持包等都属于高危信号（对应 T03 远程载荷获取与执行、T08 不安全依赖）。信息收集阶段先"逐条列出安装指令并判断是否涉及下载执行/网络请求"，等于为代码审计阶段的供应链攻击检查（code_audit.md 的"深度审计要求 A"）预先铺好了证据清单。

4.3 技术分析

• 编程语言与技术栈：主要语言、框架、库和工具。
• 构建和测试命令：从配置文件中提取的实际命令（构建、测试、部署）。
• 代码风格指南：代码规范、格式化工具或约定（linter 配置）。
• 数据处理与存储方案：数据流、数据库或文件处理方式。
• 网络通信接口设计：API、协议或外部集成点。

"网络通信接口设计"是安全评估的重要输入——它划定了项目的合法网络暴露面，代码审计阶段据此判断哪些外连行为超出了最小权限。

4.4 安全评估

• 权限需求与访问控制：身份验证、授权机制。
• 数据处理安全性：输入验证、加密措施。
• 网络暴露面分析：外部接口风险。
• 潜在安全隐患：基于代码模式识别的弱点。
• 安全注意事项：从文档或注释中提取的明确安全提示。

注意此处的定位：信息收集阶段的"安全评估"是初步、描述性的（如实记录项目自述的权限模型、加密措施、安全提示），而不要求给出最终判定——最终 verdict 属于后续代码审计与漏洞整理阶段。这与管线的分工设计一致：先客观描述，再深度审计，最后严格验证。

4.5 开发与运维细节

• 测试说明：测试策略、覆盖范围及测试文件位置。
• 功能模块清单：主要组件、依赖关系及敏感操作识别点。
• 部署流程：如何构建和发布项目。

"敏感操作识别点"对后续审计极具价值：它提示审计 Agent 哪些模块值得重点深挖（如凭据读取、网络请求、文件写入、进程执行等）。

4.6 附加信息

记录项目特有的约定或异常结构，例如与常规 Skill 结构明显不同的目录布局、奇怪的编码文件、隐藏文件等。异常结构往往是恶意载荷的藏身处（参见 pre_scan.py 对.pyc字节码、__pycache__、node_modules等依赖/缓存/构建目录的专门标记逻辑）。

4.7 注意事项：写作纪律

模板末尾三条注意事项是信息收集报告的质量红线：

1. 严格基于输入数据，引用具体文件或代码片段时注明来源——杜绝编造；
2. 语言简洁、客观，避免主观推测，优先使用项目自身术语——为后续阶段提供中性、可靠的上下文；
3. 无数据支撑的章节可省略并说明"无相关信息"——避免强行填充。

这三条纪律与整个 aig-skill-scan 的"证据驱动"设计哲学一致：code_audit.md明确要求"只基于你实际读取到的文件内容做判断，禁止引用外部检测结果中不存在于本项目目录的文件内容"，vuln_review.md更是提出"零误报容忍"与"宁可错过，不可误报"原则。

五、源码链路：模板如何加载、报告如何流转

理解了模板内容后，再从源码看它如何在运行时被加载、执行并把结果注入下一阶段。

5.1 模板加载：PromptManager 的候选路径

utils/prompt_manager.py 的load_template(name)会按顺序尝试四个候选路径：

possible_paths = [ os.path.join(base_dir, "prompt", name), os.path.join(base_dir, "prompt", f"{name}.md"), os.path.join(base_dir, "prompt", "agents", name), os.path.join(base_dir, "prompt", "agents", f"{name}.md"), ]

Stage 1 传入的模板名是agents/project_summary，最终命中skill_scan/prompt/agents/project_summary.md（即本仓库中的 project_summary.md）。format_prompt支持{key}与${key}两种占位符替换（如系统提示词中的{name}、{instruction}、{generate_tools}，见 system_prompt.md）。

5.2 阶段执行：ScanPipeline.execute_stage

execute_stage（agent.py）的执行流程如下：

1. 加载模板作为instruction；若language == "en"，追加_LANGUAGE_DIRECTIVE_EN（要求全部英文输出，并给出 T01–T09 的英文分类名）。
2. 用该指令实例化一个独立的BaseAgent，指令通过generate_system_prompt拼入系统提示词（base_agent.py）。
3. 构造用户消息：请进行信息收集，项目文件夹在 {repo_dir}（中文模式）或Please perform Info Collection, the project folder is at {repo_dir}（英文模式），并附加用户自定义 prompt。
4. agent.run()进入 LLM 循环：每轮解析 LLM 回复中的工具调用、执行工具、把结果追加进历史，直到调用finish或达到max_iter。
5. 将阶段结果存入self.results[stage.name]并返回。

5.3 上下文注入：信息收集报告成为代码审计的背景

这是本模板价值的落点。在_scan_three_stage中，Stage 2（代码审计）执行时把 Stage 1 的输出作为背景数据传入：

code_audit = await self.pipeline.execute_stage( ScanStage("2", stage2_name, "agents/code_audit", ...), repo_dir, prompt, {ctx_key1: info_collection}, # {"信息收集报告": <Stage1 输出>} inject_repo_tree=True, inject_pre_scan=True, )

execute_stage会把context_data拼入用户消息："有以下背景信息：信息收集报告:{报告内容}"（英文模式为 "The following background information is provided:"，见 agent.py）。也就是说，信息收集报告以显式上下文的形式进入代码审计 Agent 的对话历史，让审计 Agent 在不重复探索项目的情况下直接获得项目全貌，这正是模板任务要求第 5 条"为后续审计提供准确、可操作的基础信息，尽量减少不必要的工具调用"的实现机制。

5.4 空项目短路与语言指令

Agent.scan入口会先调用_is_empty_or_metadata_only(repo_dir)（agent.py）做空项目检测：如果目录内只有.git、.DS_Store、Thumbs.db等系统元数据文件，则直接返回normal（得分 100），理由为"项目为空或仅包含系统元数据文件（如 .DS_Store），无可审计内容"，完全跳过 LLM 扫描——避免审计 Agent 对空目录产生幻觉。注意其设计细节：__pycache__、node_modules、dist、build等依赖/缓存/构建目录不算空，其内的文件仍视为可审计内容（issues #630/#631 的修复），防止恶意载荷藏在依赖目录中逃逸审计。

5.5 静态预扫描：信息收集之后的"第二层证据"

Stage 2 还会注入pre_scan(repo_dir)的结果（pre_scan.py）。这是一次基于正则的快速静态扫描，覆盖 13 类高危模式：

模式名	检测示例
curl_pipe_exec	curl ... \| bash、wget ... \| sh、curl ... \| python
cloud_metadata_access	169.254.169.254、metadata.google.internal
local_env_recon	gethostname、getfqdn、socket.connect
credential_file_access	~/.ssh、~/.aws、.env、credentials、authorized_keys
prompt_injection	ignore previous instructions、SYSTEM OVERRIDE、<\|im_start\|>
fixed_tail_ad_injection	文末固定广告/导流/二维码/进群模板
reverse_shell	socket.connect+ IP、/bin/sh
encoded_payload	base64.b64decode+exec/eval/system
data_exfil_encoded	base64.encode+key/secret/token
outbound_data_exfil	requests.post+ 环境变量/凭据
crontab_persistence	crontab、systemctl enable、schtasks
ssh_key_write	写入authorized_keys、id_rsa
non_official_download	从个人仓库/pastebin 下载.exe/.sh/.py

预扫描命中结果会以"⚠️ 静态预扫描发现以下值得关注的高危模式，请重点审计这些行为是否必要及其风险"的提示注入审计 Agent 的用户消息，成为信息收集报告之外的第二层证据补充。base_agent.py中还内置了 8 条_CHALLENGE_PATTERNS敏感模式→追问映射：当工具结果中命中curl|bash、云元数据端点、Base64 解码后执行、authorized_keys等模式时，会自动生成追问文本（如"上述内容包含 curl|bash 管道执行远程脚本……请评估来源是否可信"），强制审计 Agent 对敏感行为给出评估，防止漏报。

六、与相邻阶段模板的协同：一条完整的证据链

信息收集模板不是孤立存在的，它与同目录下的另外两个 Agent 模板构成完整管线（均位于 skill-scan/skill_scan/prompt/agents/）：

• code_audit.md（Stage 2 代码审计）：在信息收集报告、目录树、预扫描提示三重背景下，回答五个核心问题——Skill 实际做了什么、是否存在超出声明范围的操作、是否存在恶意/高危行为、是否存在对 AI Agent 的操控、能力是否超出最小权限。内含"深度审计要求"（木马/伪装型攻击、纯指令层攻击、侦察型攻击三组检查清单）与完整的malicious / suspicious / normal三级判定标准，并按 SkillTrustBenchT01–T09分类（技能指令劫持、Agent 记忆投毒、远程载荷获取与执行、嵌入恶意代码、未授权访问与权限提升、系统持久化、工具劫持与欺骗、不安全依赖、不安全 Skill 编码实践）标注到对应文件。
• vuln_review.md（Stage 3 漏洞整理）：对代码审计报告做"零误报容忍"的严格验证——过滤测试代码误报、验证数据流完整性/攻击可执行性/权限充分性/实际危害性、执行去重合并，最终以标准 XML 结构<vuln>输出（含title、desc、risk_type、level、file、line_start/line_end、suggestion字段），无漏洞时返回<empty>。

信息收集阶段输出的项目概述、SKILL.md 摘要、安装指令分析等，正是 Stage 2 判断"声明功能是否与真实行为一致"、Stage 3 过滤"正常业务功能误报"的事实前提。三者形成"先摸清全貌 → 再深度审计 → 最后严格验证"的递进证据链。

七、实操指南：如何运行信息收集阶段

7.1 CLI 运行

信息收集阶段随三阶段管线运行，通过--aig-mode开启：

# 设置 API Key（环境变量方式，禁止硬编码） export LLM_API_KEY="your-api-key" # 以 AIG 模式运行三阶段管线（含信息收集阶段） aig-skill-scan --repo /path/to/your/skill \ -m deepseek-v4-flash \ --aig-mode \ --language zh \ -o result.json # 或作为模块调用 python -m skill_scan --repo /path/to/your/skill --aig-mode

注意：--aig-mode面向 AI-Infra-Guard 平台后端，开启后会向 stdout 输出newPlanStep/statusUpdate/toolUsed等结构化 JSON 行供 Go 后端解析，独立使用 pip 安装场景下请勿开启，以免污染终端（见 skill-scan/README.md 的说明）。

7.2 参数一览表

CLI 参数由 main.py 的parse_args定义：

参数	说明	默认值
--repo	待扫描的 Skill 项目目录路径（必填）	—
-m, --model	LLM 模型名	deepseek-v4-flash
-k, --api_key	API Key（缺省时回退到环境变量）	环境变量
-u, --base_url	API Base URL	https://openrouter.ai/api/v1
-p, --prompt	自定义扫描提示词（可选）	—
--language	输出语言zh/en	zh
--debug	开启调试模式	false
--aig-mode	启用三阶段管线并输出结构化 JSON（供平台后端）	false
-o, --output	结果输出文件；关闭--aig-mode时为 SARIF 2.1.0 JSON，开启时为内部结构 JSON	—

7.3 环境变量配置

配置通过环境变量或.env注入，查找顺序为：包根目录（site-packages/skill_scan/.env）→ 当前工作目录（./.env，推荐）：

变量	说明	默认值
LLM_API_KEY/OPENAI_API_KEY	LLM API Key（必须用环境变量，禁止硬编码）	—
LLM_MODEL/OPENAI_MODEL	默认模型	deepseek-v4-flash
LLM_BASE_URL/OPENAI_BASE_URL	默认 Base URL	https://openrouter.ai/api/v1
DEFAULT_MODEL_CONTEXT_WINDOW	主模型上下文窗口	128000
LOG_LEVEL	日志级别	INFO

7.4 Python 编程调用

import asyncio import json import os from skill_scan.agent.agent import Agent from skill_scan.utils.llm import LLM async def run(): api_key = os.environ.get("LLM_API_KEY") if not api_key: raise RuntimeError("LLM_API_KEY environment variable must be set") llm = LLM(model="deepseek-v4-flash", api_key=api_key, base_url="https://openrouter.ai/api/v1", context_window=128_000) # aig_mode=True 时运行三阶段管线，信息收集报告保存在 result["readme"] 中 agent = Agent(llm=llm, debug=False, language="zh", aig_mode=True) result = await agent.scan("/path/to/your/skill", "", "zh") print("信息收集报告（即 readme 字段）:", result["readme"]) print("安全评分:", result["score"], "| 主语言:", result["language"]) print("漏洞列表:", json.dumps(result["results"], ensure_ascii=False, indent=2)) asyncio.run(run())

三阶段模式下，返回字典的readme字段保存的正是Stage 1 信息收集报告，results为提取后的漏洞列表（<vuln>XML 经 utils/extract_vuln.py 解析，若解析失败有extract_result兜底）。

7.5 结果与评分

安全评分由 utils/project_analyzer.py 的calc_skill_score计算（与 mcp-scan 的calc_mcp_score同构，适配 malicious/suspicious/normal 三级判定）：

严重级别	扣分
Critical / 严重	-100
High / 高危	-40
Medium / 中危	-25
Low / Info / 其他	-10

最终分数 =max(0, 100 - Σ扣分)，无漏洞时为 100。关闭--aig-mode时，-o输出为SARIF 2.1.0标准 JSON（由 utils/sarif_formatter.py 转换），可被 GitHub Code Scanning、Azure DevOps、GitLab Security Dashboard、VS Code Problems 面板等 SARIF 生态工具原生消费；ruleId取自漏洞的risk_type（T01–T09 分类码），level由文本严重级别归一化为error/warning/note。

八、小结：把信息收集做成审计的证据底座

project_summary.md提示词模板虽然只是三阶段管线中的一环，却承担着整个审计流程的"地基"职能：它通过强制的结构化报告框架（项目概述、Skill 特性分析、技术分析、安全评估、开发与运维细节、附加信息），迫使审计 Agent 在做出任何安全判定之前，先基于项目实际内容完成一次全面、客观、可引用的信息盘点；其"基于输入数据、注明来源、无数据则说明无相关信息"的纪律，与 code_audit 的"只基于实际读取的文件内容做判断"、vuln_review 的"零误报容忍"一脉相承。理解这个模板，就等于理解了 aig-skill-scan 三阶段审计设计的第一块基石——先让模型看全、看准，再让它下结论。

【免费下载链接】AI-Infra-GuardA full-stack AI Red Teaming platform securing AI ecosystems via Agent Scan, Skills Scan, MCP scan, AI Infra scan and LLM jailbreak evaluation.项目地址: https://gitcode.com/GitHub_Trending/ai/AI-Infra-Guard