从“源码“到“可用服务“：AI-Infra-Guard agent-scan 中 MCP 源码部署 Agent（build_preview）提示词引擎深度解析

从源码到可用服务AI-Infra-Guard agent-scan 中 MCP 源码部署 Agentbuild_preview提示词引擎深度解析【免费下载链接】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本文以 build_preview.md 这一MC P 源码部署 Agent提示词文档为主体完整拆解其角色约束、六步自动化部署流程获取源码、解析部署要求、安装依赖、后台启动、日志监控、客户端验证以及结构化的build_resultXML 输出契约并结合 agent-scan 的 Agent 模板加载源码与下游动态验证 Agent 的实现说明该部署阶段在 MCP 白盒/动态验证流水线中的定位。读完后你将能够独立设计部署型子 Agent 提示词并理解部署结果如何被下游漏洞验证环节消费。1. 定位MCP 动态验证流水线中的部署桥接阶段build_preview.md位于 agent-scan 的 Agent 提示词模板目录下prompt/system/agents/build_preview.md是 AI-Infra-GuardAIG中 AI 红队扫描模块 agent-scan 的一个专职子 Agent 模板。其核心职责在文档首段定义得非常明确你是一个自主的 MCPModel Context Protocol源码部署 Agent。你的任务是通过自动化流程部署 MCP 程序从源码包括阅读文档和代码、安装依赖、启动程序、监控日志以验证启动状态并使用 MCP 客户端进行功能验证。请以分步、详细的方式执行以下操作并在每个阶段报告进度和结果。如果遇到错误尝试诊断并重试然后终止流程。从源码结构看agent-scan 的所有子 Agent 均以Markdown 文件 可选 YAML Frontmatter 元数据的形式组织由工具层统一发现、解析和调度task 工具 中的parse_agent_file()会先用正则提取文件头部的---YAML Frontmatter 作为元数据剩余部分作为 Agent 指令正文load_agent_prompt() 按直接.md文件 → 目录内index.md/同名文件 → 模糊匹配的顺序加载指定 Agent 的提示词task() 工具 加载模板后经context.call_subagent()发起子 Agent 会话list_agents()工具则负责枚举全部可用 Agent。更关键的是它与下游阶段的数据契约下游的 动态验证 Agent 提示词 明确写道从 build_result XML 中提取 server_url、pid、log_file。也就是说build_preview的产物不是给人看的自然语言总结而是一份被下游 Agent 直接解析的结构化 XML——这正是它作为部署桥接阶段的价值把 MCP 服务从一堆源码变成一个可被渗透测试的活服务。同目录下的 code_audit.md、vuln_review.md、mcp_opera.md 分别负责静态审计、漏洞评审与 MCP 通信机制说明与build_preview共同构成静态分析 → 部署 → 动态验证的完整链路主控 Agent 的调度逻辑可参见 main.md。2. 角色定义与硬约束文档以角色定义一节给部署 Agent 设定了身份、目标与约束三元组这是整份提示词的行为边界维度定义工程含义身份专业的 DevOps 工程师专注于 AI 基础设施的自动化部署提示词以部署运维视角依赖、进程、日志而非安全测试视角组织步骤目标确保 MCP 程序从源码成功部署并运行在后台最终通过客户端验证其可用性成功标准是可被客户端连通而非进程还在约束仅使用提供的源码和标准命令行工具如终端、日志监控避免交互式输入除非必要所有操作尽可能自动化保证该 Agent 可以无人在值守条件下无人化运行这也是红队自动化流水线能串行的前提此外文档规定每个步骤都必须遵循统一的三段式执行范式首先描述你计划做什么然后执行具体操作模拟命令或代码阅读最后报告结果成功、失败及原因。这种计划—执行—汇报的强结构是 Agent 提示词工程中控制 LLM 行为漂移的常用手段它把开放式任务拆成可校验的最小单元任何一步失败都能被定位到具体阶段。3. 六步部署流程逐段剖析以下按原文档的步骤顺序逐一展开并补充各步骤的实操要点。3.1 步骤 1获取并检查源码行动源码已通过上下文提供在 agent-scan 的白盒场景中目标 MCP 项目的源码会被直接注入 Agent 上下文而不是让 Agent 自行下载。具体指令列出源码结构重点查看根目录的配置文件如README.md、requirements.txt、package.json、Dockerfile等。这一步本质是一次侦察扫描通过根目录文件快速判断项目的语言栈与打包方式Python/Node/容器化为步骤 2 的部署要求提取划定范围。3.2 步骤 2翻阅文档和代码理解部署要求行动仔细阅读README.md或类似文档识别部署指南、依赖项和启动命令同时扫描关键代码文件如主入口点main.py或app.py确认环境要求如 Python 版本、端口配置。具体指令提取三类关键信息依赖安装命令如pip install -r requirements.txt启动命令如python main.py或npm start预期日志消息如Server started on port 8080。若项目无日志可适当添加日志信息以便步骤 5 的日志匹配。输出示例原文档给出文档指出需要 Python 3.8使用pip install -r requirements.txt安装依赖启动命令为python src/server.py。日志成功标志为MCP server is running。这一步是整个流程的信息枢纽步骤 5 的success_patterns日志匹配模式就来自这里提取的预期日志消息因此提示词特意强调如无日志可适当添加日志信息——把可观测性前置到部署规划中。3.3 步骤 3安装依赖行动根据步骤 2 的发现安装所有依赖项优先使用虚拟环境如venv以避免冲突。具体指令创建虚拟环境python -m venv venv source venv/bin/activatePython 项目运行安装命令例如pip install -r requirements.txt或npm install如果失败检查网络或依赖版本然后重试。输出示例依赖安装完成成功安装 15 个包无错误。失败重试策略在此处埋下伏笔后续 XML 契约中error_type的取值之一dependency_error对应的正是本步骤的失败场景。3.4 步骤 4执行启动命令后台运行行动使用execute_shell_background工具在后台启动程序确保进程持续运行。具体指令使用execute_shell_background启动服务并指定日志文件路径记录返回的进程 IDPID以便后续管理示例execute_shell_background(commandcd /path python main.py, log_file/tmp/mcp_server.log)输出示例程序已启动在后台PID 为 12345。日志输出重定向到/tmp/mcp_server.log。这里体现了部署 Agent 与交互式终端的根本区别服务必须以后台进程方式存活且 PID 与日志文件路径都要作为一等公民被记录——因为它们随后会写进build_resultXML成为下游动态验证 Agent 的环境输入。3.5 步骤 5监控日志判断启动成功行动使用check_process_logs工具监控日志文件判断启动是否成功。具体指令使用check_process_logs监控日志文件根据步骤 2 识别的成功消息自定义success_patterns如[Server started, listening on, Uvicorn running];设置合理的超时时间建议 30-60 秒如果检测到错误使用kill_process终止进程分析日志并尝试修复问题后重试最多 2 次。示例check_process_logs(log_file/tmp/mcp_server.log, success_patterns[Server started, listening], timeout60)输出示例日志检查在 10 秒内发现MCP server is running on port 8080启动成功。这一步是进程存活与服务就绪的区分点仅确认进程在跑并不够必须以步骤 2 提取的业务成功日志为准。同时最多重试 2 次 kill_process 清理构成了有界的重试闭环防止 Agent 在坏依赖上无限循环——这是把 DevOps 的可恢复性思维编码进提示词的典型设计。3.6 步骤 6编写脚本验证 MCP Server 启动成功文档要求基于 fastmcp 库编写 MCP 客户端验证脚本并给出了完整可运行的参考实现连接 MCP 客户端并打印所有工具import asyncio from fastmcp import Client # HTTP server client Client(http://localhost:8080/sse) async def main(): async with client: # Basic server interaction await client.ping() # List available operations tools await client.list_tools() print(tools) asyncio.run(main())该脚本通过client.ping()验证连通性、通过client.list_tools()验证 MCP 协议层功能工具发现。只有客户端验证通过部署才算功能就绪。这与下游 动态验证 Agent 中使用的同类客户端脚本call_tool()调用目标工具执行 exploit形成呼应build_preview阶段验证的是服务正常动态验证阶段复用同一套客户端能力去做攻击。4. 输出契约build_resultXML文档最末规定任务结束时部署 Agent必须以 XML 格式总结部署结果这些信息将被动态验证 agent 使用。这是整份提示词中工程约束最强的部分——它把自然语言输出收敛为可被程序解析的契约。4.1 成功情况输出格式build_result statussuccess/status server_urlhttp://127.0.0.1:8080/server_url pid12345/pid log_file/tmp/mcp_server.log/log_file startup_time10.5/startup_time messageMCP部署成功程序运行在127.0.0.1:8080日志显示服务正常运行。/message /build_result字段含义与来源字段含义产生于statussuccess/failed二态步骤 5/6 的最终判定server_url服务地址含端口供下游客户端直连步骤 2 提取的端口配置pid后台进程 ID供下游验证结束后清理进程步骤 4 记录的 PIDlog_file日志文件路径供check_process_logs复查步骤 4 指定的 log_filestartup_time启动耗时秒用于评估服务启动性能步骤 5 的日志监控计时message人类可读的结论摘要各阶段汇报汇总4.2 失败情况输出格式build_result statusfailed/status error_typedependency_error|startup_error|timeout/error_type log_file/tmp/mcp_server.log/log_file message失败原因的详细描述/message suggestion修复建议/suggestion /build_result注意error_type是一个闭合枚举dependency_error对应步骤 3 失败、startup_error步骤 4/5 进程起不来或报错、timeout步骤 5 超时未匹配到成功日志。失败分支额外要求suggestion字段给出修复建议使上游主控 Agent参见 main.md 中的子Agent执行失败处理策略可跳过阶段则继续并标注限制关键阶段则向用户报告可以据此决定是重试、降级还是终止整条流水线。4.3 契约如何被下游消费从 dynamic_verification.md 的任务输入与阶段1环境准备与确认可以确认该契约的实际消费方动态验证 Agent 收到的输入包含服务器信息从构建预览阶段获得的服务器地址、端口、PID 等其验证流程的第一步即从 build_result XML 中提取 server_url、pid、log_file必要时用check_process_logs再次确认服务器状态漏洞按风险等级排序后逐个验证命令注入、凭据窃取、间接提示注入、硬编码密钥、认证绕过、工具投毒/影子、Rug Pull 等验证完成后还要求使用kill_process终止测试启动的服务器——这里的 PID 正是build_result里部署 Agent 记录的那个。两条提示词文档首尾相扣build_preview负责把服务立起来并交付坐标dynamic_verification负责拿着坐标去打洞并善后。XML 契约正是二者之间唯一的、无歧义的数据通道。5. 支撑工具链与源码印证build_preview.md通篇围绕一组 shell/进程类工具展开这些工具名在 agent-scan 的动态验证提示词中也成套出现工具使用指南可以推断它们是 agent-scan 运行时为子 Agent 提供的一套标准环境操作原语工具在 build_preview 中的用途execute_shell_background后台启动 MCP 服务并返回 PID日志重定向到指定文件check_process_logs按success_patterns轮询日志带timeout判定启动成败kill_process失败重试前清理残留进程下游验证结束后做资源善后generate_python/write_file/execute_shell/read_file生成并执行步骤 6 的 fastmcp 客户端验证脚本、读取源码而 Agent 模板本身的加载与调度则由 agent-scan/agent_scan/tools/task/task.py 承担get_all_agents()扫描模板目录、parse_agent_file()解析 Frontmatter、task()工具将Agent 正文 任务提示词组装后通过call_subagent()派生子会话。这意味着build_preview.md并不是一段一次性文档而是被红队流水线反复实例化执行的提示词级组件——它的每一次改动都会直接作用于所有 MCP 白盒扫描任务的部署阶段行为。6. 小结部署型 Agent 提示词的设计要点以build_preview.md为样本可以归纳出 agent-scan 中部署型子 Agent提示词的四条可复用设计角色与约束先行身份DevOps、目标客户端可验证、约束禁交互、全自动化三段式定义划定 LLM 行为边界步骤强结构化六步流程每步都遵循计划—执行—汇报范式并给出具体的命令示例与输出示例把抽象要求锚定到可观察的输出可观测性前置在步骤 2 就提取预期日志消息必要时主动加日志使步骤 5 的success_patterns匹配有据可依结构化输出契约以build_resultXML成功/失败两态 闭合的error_type枚举 suggestion作为阶段间数据通道保证下游动态验证 Agent 可以无歧义地解析并复用server_url、pid、log_file。对希望在自己的 Agent 流水线中增加部署-验证环节的团队build_preview.md 与其下游 dynamic_verification.md 的组合以及 task 工具的模板加载实现构成了一个从提示词设计到工程落地的完整参照更多 agent-scan 的整体功能介绍可参考 agent-scan/README.md。【免费下载链接】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辅助生成（AIGC），仅供参考