专用Agent开发实战：从零构建安全审查智能体

最近一年，身边做 AI 应用的技术人几乎都在聊同一个词：Agent。但一个很尴尬的现实是，大多数 Agent 项目并没有真正跑进生产环境，而是停在 demo 阶段。原因往往不是模型不够聪明，而是很多 Agent 在“通用”和“专用”之间一直没有做出选择，最后变成了一个什么都能聊、什么都办不彻底的聊天框。

这也是我关注 Blitz Agent 的原因。这个项目的自我定位非常鲜明：Your specialized agent，你的专用智能体。官网是 blitzagent.studio。在 Agent 产品铺天盖地的当下，这个定位其实很有信息量——它没有去追“通用智能体”这个概念，而是把“专用”作为核心卖点。顺着这个思路，你会发现最近一年大量有落地价值的 Agent 项目，本质上都不是因为模型能力本身多强，而是因为任务边界足够窄、工具链路足够清晰、输出格式足够稳定。

这篇文章想通过 Blitz Agent 这个引子，把“专用 Agent”这件事讲透。我会先拆解 Agent 的核心概念，搞清楚专用 Agent 与通用 Agent 的区别；然后给出从零实现一个专用 Agent 的完整代码示例；接着聊 Agent 框架、Harness、Skill、MCP 这些让人容易混淆的工程概念；最后补充环境准备、运行验证、排查思路和生产环境最佳实践。读完你应该能判断一个 Agent 项目适不适合自己的场景，也能照着本文跑通一个最小可用示例。

1. 这篇文章真正要解决的问题

先聊清楚一个问题：为什么那么多 Agent 项目最终没有价值？

很多开发者的第一版 Agent 是这样做的：接一个大模型 API，写一段系统提示词，然后把几十个工具函数全部塞进去。结果是什么？推理变慢、工具乱调用、上下文很快被撑爆，输出格式也经常不稳定。这里真正的坑在于：Agent 的能力并不等于“模型 + 工具”的简单加法，还需要明确的职责边界、调度策略和工程护栏。

通用 Agent 听起来很美好，但在实际业务里几乎不可用。因为业务系统的输入空间是无限的，一个没有边界的 Agent 会在无限输入空间里表现得越来越不可控。相反，专用 Agent 的价值是把输入空间压缩到有限范围，然后在这个范围内追求高准确率和高完成度。

我们来看一个例子。假设你希望做一个“代码安全审查 Agent”，如果这个 Agent 什么都能聊，用户就可能问它项目排期、团队管理、技术选型，这些都不是它的职责。一旦它试图回答这些问题，就可能给出错误甚至有害的信息。而专用 Agent 的设计思路是：只处理代码安全审查，超出范围直接拒绝；只调用与扫描相关的工具；只输出固定结构的审查报告。

Blitz Agent 这类项目之所以值得关注，是因为它刚好踩在这个趋势上。从“专用 Agent”的定位出发，它要解决的问题是：如何让非深度研究者也能快速搭建、配置、运行一个边界清晰的 Agent。对开发者来说，这意味着你不需要从零实现模型调度、工具注册、上下文管理等底层逻辑，而可以把精力集中在“这个 Agent 到底要完成什么任务”上。

如果你属于以下三类读者，这篇文章很适合你：

• 正在学习 Agent 开发，但对“专用”和“通用”没有清晰概念的人。
• 已经能调用大模型 API，但写出来的 Agent 不稳定、不可控、容易出错的开发者。
• 关注 Agent 平台类产品，想评估 Blitz Agent 这类工具是否值得尝试的技术决策者。

2. Agent 核心技术概念：通用 Agent 与专用 Agent 的区别

2.1 什么是 Agent

在 AI 领域，Agent 可以理解为“能够感知环境、做出决策、执行动作的智能体”。落到大模型应用里，一个标准的 Agent 通常包含五个组成部分：

• 大模型（LLM）：理解和推理能力的基础。
• 规划（Planning）：把复杂任务拆解成可执行步骤。
• 工具（Tools）：通过函数调用、API 或外部服务与环境交互。
• 记忆（Memory）：记录当前对话上下文或长期业务信息。
• 执行（Execution）：实际调用工具并处理返回结果。

这个结构可以用一个简单的循环来概括：Agent 接收用户的请求，大模型判断需要调用哪些工具，调用工具拿到结果后，把结果返回给模型继续推理，直到完成最终回答。这个循环在工程上经常被叫做 Agent Loop。

2.2 与普通 Chatbot 的区别

普通聊天机器人是“问一句、答一句”的单轮模式，模型不主动选择工具，也不会尝试完成多步骤任务。Agent 则不同，它有权决定在什么时候调用什么工具，并且能根据工具返回结果调整下一步动作。

比如用户说：“帮我查看 /app/demo 目录的依赖风险，并检查最近提交记录。”普通 Chatbot 只会根据训练知识回答一个大概，而 Agent 会触发一次安全扫描，获取扫描结果与提交记录后，再基于这些真实数据生成最终结论。

2.3 通用 Agent 与专用 Agent

通用 Agent 的目标是像全能助手一样处理任意问题，专用 Agent 则只针对一个明确的业务领域。

专用 Agent 不是能力更弱的 Agent，而是边界更明确的 Agent。它的效率来自两个地方：一是模型不用在无关任务上浪费推理和上下文空间；二是你可以针对它的输出做严格校验，建立自动化测试，从而保证质量。

2.4 一个容易踩的误区

很多人以为专用 Agent 就是把系统提示词写长一点、写详细一点。但实际上，提示词只是第一道防线。如果环境不安全、工具可以任意调用、上下文可以被任意注入，那么再严格的提示词也可能在复杂场景里失效。

真正的专用化应该体现在四个层面：

• 提示词层面：明确职责范围和拒绝策略。
• 工具层面：只暴露最小必要工具，实施白名单。
• 数据层面：限制输入来源与敏感数据访问。
• 输出层面：定义结构化格式，做合法性校验。

一个真正可靠的专用 Agent，是在这些层面都做了约束的。这也是 Blitz Agent 这类平台的价值入口：把“专用 Agent”的工程约束产品化，让开发者不需要每次都自己重复搭建。

3. Blitz Agent 的定位与信息拆解

从项目标题“Blitz Agent Your specialized agent”和官网域名 blitzagent.studio 来看，这是一个围绕“专用 Agent”概念打造的产品。Blitz 在英文里有“闪电战”或“快速行动”的含义，加上 specialized agent 这个词组，比较合理的判断是：这个产品希望让开发者可以快速构建、配置和运行自己的专用智能体。

这类产品在 Agent 工程领域有一个明确的需求背景：大多数团队并不需要一个从底层模型开始搞的全新框架，而是需要一套能覆盖“模型调度、工具注册、上下文管理、请求日志、安全策略”的现成服务。开发者只需要配置一个 Agent 模板，描述清楚它的职责、给它挂上工具、设置好模型参数，就能对外提供稳定的 Agent 能力。

当然，Blitz Agent 具体支持哪些功能、是否开源、支持哪些模型，需要查看官网最新信息。本文在这里不做推测。我更想强调的是：从产品逻辑上看，它选择“专用 Agent”作为切入点，是一个非常务实的选择。因为 Agent 产品最容易被用户感知到的价值，不是“它什么都能聊”，而是“它在某个具体任务上做得又快又稳”。

这里也顺带解释一下 Agent 领域经常出现的其他定位词：“通用助手型 Agent”负责处理日常对话和多领域问题，适合内部知识问答、客服前置等场景；“专用任务型 Agent”则聚焦代码审查、数据提取、报表生成、运维告警处理等一类任务。你要是去观察现在真正被企业用起来的 Agent，绝大多数都属于后者。

所以，如果你打算在自己的项目里落地 Agent，第一条建议就是：先定义一个足够具体的任务。比如“把用户上传的 PDF 发票信息抽取成结构化 JSON”，而不是“做一智能助手”。任务边界越窄，工程质量越容易控制。

4. 环境准备与前置条件

在开始写代码之前，先准备好运行环境。本文的示例基于 Python 和大模型 API，不依赖任何特定 Agent 框架。

4.1 基础环境

• 操作系统：Windows 10/11、macOS、主流 Linux 发行版都可以。
• Python 版本：建议 3.10 及以上。
• 大模型 API Key：以 OpenAI 兼容接口为例，你可以在环境变量中配置 API Key。
• 编辑器：VS Code、PyCharm 或者任意命令行工具皆可。

4.2 安装依赖

本文示例只用到 OpenAI 官方 Python SDK，以及 Python 自带的 json 模块，不需要安装额外重型依赖。

pip install openai

如果你使用的模型接口与 OpenAI 格式兼容，也可以通过 base_url 配置自定义的 API 服务地址。

4.3 配置环境变量

为了避免在代码中硬编码密钥，推荐通过环境变量配置 API Key。

export OPENAI_API_KEY="sk-你的密钥"

Windows PowerShell 下可以执行：

$env:OPENAI_API_KEY = "sk-你的密钥"

如果你使用的是类似 vLLM、Ollama、或者国内大模型厂商提供的 OpenAI 兼容接口，可以把 base_url 指向对应服务的地址。下面的代码示例统一使用 OpenAI SDK，你可以根据实际情况替换模型名称和 base_url。版本与模型名称以你实际可用的为准，本文重点演示专用 Agent 的开发思路。

5. 完整示例与代码实现：从零构建一个专用 Agent

很多人对“如何开发 Agent”的第一反应是找框架。其实在没有框架的情况下，你也可以用几百行代码写透 Agent 的运行机制。下面我从三个层面演示：提示词约束、工具注册、完整 Agent 循环。最后再给出一个 YAML 配置模板，方便你把它拆解成可维护的配置文件。

5.1 示例一：用系统提示词约束一个专用 Agent

这一步的目标是让模型知道自己是“专用 Agent”，并且明确什么该做、什么不该做。

# 文件路径：examples/agent_basic.py from openai import OpenAI client = OpenAI() SYSTEM_PROMPT = """你是一个代码安全审查 Agent。 你的职责范围： - 只处理与代码质量、安全漏洞、性能风险相关的内容 - 只回答与代码审查有关的问题 - 不做需求分析、项目管理、技术选型等非代码审查任务 如果用户提出的问题超出上述范围，请直接回答： "该问题不属于代码安全审查 Agent 的处理范围。" """ def review_code(code_snippet: str) -> str: response = client.chat.completions.create( model="gpt-4o-mini", messages=[ {"role": "system", "content": SYSTEM_PROMPT}, {"role": "user", "content": f"请审查下面这段代码：\n{code_snippet}"} ], temperature=0.2, ) return response.choices[0].message.content if __name__ == "__main__": demo_code = """ def get_user(name): import sqlite3 conn = sqlite3.connect("users.db") cur = conn.cursor() sql = "SELECT * FROM users WHERE name = '" + name + "'" cur.execute(sql) return cur.fetchall() """ print(review_code(demo_code))

这段代码的关键在于 SYSTEM_PROMPT 不是简单夸自己“我是助手”，而是写明了职责范围和拒绝策略。专用 Agent 的边界，有一半是从这里来的。运行它，你会看到模型给出与 SQL 注入风险相关的审查意见，而如果你问它“这个项目的排期怎么安排”，它会拒绝回答。

5.2 示例二：给 Agent 注册工具并触发调用

光有提示词约束还不够。专用 Agent 要真正完成任务，必须能调用外部工具。这里使用 OpenAI 的 Function Calling 机制，把工具注册给模型。

# 文件路径：examples/agent_with_tool.py import json from openai import OpenAI client = OpenAI() def scan_dependencies(project_path: str) -> dict: """模拟扫描项目依赖安全风险""" # 真实项目中，这里会调用安全扫描服务或本地命令 return { "project": project_path, "risk": "medium", "vulnerabilities": 3, "detail": ["requests<=2.25.1 has CVE-2023-32681", "flask<=2.1.3 has known advisory"] } tools = [ { "type": "function", "function": { "name": "scan_dependencies", "description": "扫描项目依赖安全风险，返回风险等级和漏洞列表", "parameters": { "type": "object", "properties": { "project_path": { "type": "string", "description": "要扫描的项目路径" } }, "required": ["project_path"] } } } ] response = client.chat.completions.create( model="gpt-4o-mini", messages=[ {"role": "system", "content": "你是代码安全审查 Agent，只负责安全扫描和漏洞分析。"}, {"role": "user", "content": "请扫描 /app/demo 目录的依赖风险，并告诉我结果。"} ], tools=tools, tool_choice="auto", ) message = response.choices[0].message print("助手回复内容：", message.content) print("是否请求调用工具：", message.tool_calls)

在这个示例里，模型识别到用户请求需要扫描依赖，于是返回一个 tool_calls 请求，而不是直接输出文本。真正执行扫描函数的动作，需要我们自己在代码里完成。这就是“模型负责决策，程序负责执行”的 Agent 分工。

5.3 示例三：完整实现一个最小 Agent 循环

下面这段代码会手动实现 Agent 的完整循环：模型请求 → 检测工具调用 → 执行工具 → 把结果交回模型 → 继续，直到模型输出最终答案。

# 文件路径：examples/minimal_agent_loop.py import json from openai import OpenAI client = OpenAI() def scan_dependencies(project_path: str) -> dict: return {"project": project_path, "risk": "low", "vulnerabilities": 0} def get_recent_commits(repo_path: str, limit: int = 10) -> list: return [ {"commit": "a1b2c3", "message": "fix: 修复登录接口越权问题"}, {"commit": "d4e5f6", "message": "feat: 新增导出功能"} ] TOOLS = { "scan_dependencies": scan_dependencies, "get_recent_commits": get_recent_commits, } TOOL_SCHEMAS = [ { "type": "function", "function": { "name": "scan_dependencies", "description": "扫描项目依赖安全风险", "parameters": { "type": "object", "properties": { "project_path": {"type": "string", "description": "项目路径"} }, "required": ["project_path"] } } }, { "type": "function", "function": { "name": "get_recent_commits", "description": "获取仓库最近提交记录", "parameters": { "type": "object", "properties": { "repo_path": {"type": "string", "description": "仓库路径"}, "limit": {"type": "integer", "description": "返回条数"} }, "required": ["repo_path"] } } } ] def run_agent(user_input: str) -> str: messages = [ {"role": "system", "content": "你是仓库安全审计 Agent。需要工具时，先调用工具，再基于工具结果回答。"}, {"role": "user", "content": user_input} ] while True: response = client.chat.completions.create( model="gpt-4o-mini", messages=messages, tools=TOOL_SCHEMAS, ) choice = response.choices[0] content = choice.message.content or "" tool_calls = choice.message.tool_calls messages.append({ "role": "assistant", "content": content, "tool_calls": tool_calls }) if not tool_calls: return content for tool_call in tool_calls: fn = TOOLS[tool_call.function.name] args = json.loads(tool_call.function.arguments) result = fn(**args) messages.append({ "role": "tool", "tool_call_id": tool_call.id, "content": json.dumps(result, ensure_ascii=False) }) if __name__ == "__main__": result = run_agent("请扫描 /app/demo 的依赖风险，并查看最近 5 条提交记录。") print(result)

这个循环就是 Agent 框架最常见的最小模型。无论你以后用 LangChain、AutoGen 还是 Blitz Agent，底层跑的核心逻辑基本都是这样：模型决定调用哪些工具 → 工具执行 → 结果回去 → 模型继续推理。

这个示例里最容易踩的坑有两个。第一个是 messages 列表里必须正确维护 tool_call_id 与 tool 结果的对应关系，否则 API 会报错。第二个是没有限制循环次数，如果模型陷入无限工具调用，会产生不可控的成本。实际项目中一定要设置最大迭代上限，比如 5 轮或 10 轮。

5.4 示例四：把 Agent 配置拆成 YAML 模板

代码写多了之后，你会发现不同专用 Agent 之间的差异，其实是“配置”的差异，而不是“循环逻辑”的差异。所以更工程化的方式是维护一个 Agent 配置模板。

# 文件路径：configs/code-安全审查-agent.yaml agent: name: code-security-reviewer display_name: 代码安全审查专用智能体 description: 只负责代码安全分析与依赖漏洞扫描 model: name: gpt-4o-mini temperature: 0.2 max_tokens: 2000 system_prompt: | 你是一个代码安全审查 Agent，只处理代码安全相关任务。 输出必须包含风险等级、问题位置、原因说明、修复建议。 与代码安全无关的问题，直接拒绝。 tools: - scan_dependencies - get_recent_commits behavior: max_iterations: 5 refuse_out_of_scope: true require_tool_for_scan: true output: format: markdown required_fields: - severity - location - description - suggestion

这个模板本身不绑定任何特定框架。你可以把它理解为一种“Agent 需求说明书”。平台类产品通常会把这类配置变成 Web 表单或可视化配置页面，这正是 Blitz Agent 这类产品降低开发门槛的方式之一：不需要写循环代码，只需要描述清楚这个 Agent 做什么、不做什么、用什么工具、输出什么格式。

6. 框架、Harness 与编排：Agent 工程化的三个关键词

随着 Agent 开发越来越复杂，业界逐渐沉淀出一套术语，很多初学者会被这些词绕晕。这里做一个集中梳理。

6.1 Harness 和 Agent 的区别

Harness 可以翻译为“套件”或“运行时容器”，它负责托管 Agent 的运行环境。Agent 是决策主体，而 Harness 是提供运行基础能力的框架层。

在开源 Agent 框架里，Agent Loop 往往就是由 Harness 管理的。比如 Hugging Face 的 Agents 系列工具中，Harness 会处理工具调用、步骤记录、最终回答生成等逻辑。相比之下，Agent 本身更像一个“策略实体”，它决定下一步做什么，而 Harness 决定怎么稳定地执行这些决策。

类比一下：Agent 像是司机，负责判断路线和操作方向盘；Harness 像是汽车底盘和发动机，保证车辆能正常行驶、换挡、刹车。没有 Harness，Agent 再聪明也跑不起来。

6.2 Skill 和 MCP 的区别

Skill 在 Agent 语境下通常指“一组针对特定任务的提示词、工具和调用流程”。例如“项目依赖扫描 Skill”包含扫描工具的参数定义、执行步骤、结果解析逻辑等。

MCP（Model Context Protocol）则是工具与服务间的标准化通信协议。它解决的是“工具如何以统一方式接入 Agent”的问题。Skill 更像“怎么做”，MCP 更像“如何连”。

可以这样理解：Skill 是菜谱，规定了一道菜的做法和用料；MCP 是厨师和食材供应商之间的标准订单接口，解决了“如何稳定地拿到原材料”的问题。你在规划 Agent 项目时，应该先定义 Skill，再决定用哪种协议或格式接入工具。

6.3 多 Agent 协作

复杂的业务场景往往需要多个专用 Agent 协作。比如一个“告警处理 Agent”在发现线上异常后，可以调用“指标分析 Agent”拉取监控数据，再交给“知识库 Agent”检索历史处理方案。

但多 Agent 协作有一个明显的代价：它们共享的上下文越多，信息互相污染的概率越大，调试也越困难。更稳妥的做法是保持每个 Agent 的信息隔离，通过明确的消息队列或任务接口传递结果，而不是让所有 Agent 共享一个巨大的上下文窗口。

所以我在实际项目中更推荐“少而精”的 Agent 策略：能用单个专用 Agent 解决的，不要拆成多个；必须拆分的，每个 Agent 的任务边界要尽可能正交，尽量减少信息往返次数。

7. 运行结果与效果验证

写完代码之后，需要验证它是否真的按预期工作。

7.1 运行示例一

cd examples python agent_basic.py

预期输出是一段代码安全审查结果。成功的关键判断标准有两个：

• 模型识别出代码中的 SQL 注入风险。
• 模型没有擅自回答与代码审查无关的内容。

如果输出偏离了这个范围，优先检查 SYSTEM_PROMPT 是否足够明确，或者模型温度是否过高。

7.2 运行示例三

python minimal_agent_loop.py

预期输出会包含依赖扫描结果和最近提交记录。你需要观察日志中是否出现了工具调用记录，以及最终答案是否结合了工具返回的真实数据。

判断标准：

• 调用次数没有超出预设上限。
• 工具调用参数正确传递。
• 最终答案没有出现自相矛盾的编造内容。
• 模型没有在得到工具结果后仍然凭空发挥。

如果失败，第一步应该看 API 返回的原始请求和响应，确认 tool_call_id、参数解析等环节是否正常。

8. 常见问题与排查思路

下面整理了几个 Agent 开发过程中常见的问题，方便你直接对照排查。

排查问题的时候，一条比较实用的经验是先把 Prompt 和工具调用历史完整记录下来。Agent 的 bug 往往不是“模型错了”，而是“模型在某一轮中拿到了错误的信息”。通过查看完整对话记录，很容易定位到是哪一步出了问题。

9. 工程化最佳实践与总结建议

9.1 最小权限原则

Agent 能调用的工具越少，出事故的可能性就越小。给 Agent 一个“删除数据库”的能力，和给它一个“查询今天订单数量”的能力，风险完全不是一个量级。每一次工具接入前，都要问自己：这个 Agent 真的需要这个工具吗？如果不需要，就不要注册。

9.2 安全边界

Agent 运行过程中会接触用户输入、工具结果和系统提示词。需要注意几个风险点：用户输入可能包含恶意指令，需要设置输入长度上限和内容过滤；工具执行结果可能包含敏感数据，要对返回结果做脱敏；系统提示词与用户输入之间要有清晰的分隔，避免用户通过输入绕过 Agent 的职责边界。

9.3 记忆管理

短期记忆用于保存当前对话的工具调用结果，长期记忆用于保存业务知识或用户画像。但记忆写入和读取都要谨慎。不要让大段原始日志进入长期记忆，更不要让不相关的对话内容污染另一个 Agent 的记忆。

9.4 可观测性

生产环境里，Agent 的每一步动作都值得记录：模型请求、工具调用、参数、返回结果、耗时、成本。一个 Agent 出问题时，如果没有日志，排查会非常痛苦。日志的价值不只是排错，它还能帮助你评估 Agent 的任务完成率，判断哪些场景经常触发误调用。

9.5 回滚与灰度发布

Agent 依赖大模型，升级模型版本或修改提示词都可能导致行为突变。所以要通过版本管理来管理提示词和工具配置。上线新能力前，先在测试环境用固定案例集做回归测试，再按比例灰度。不要在生产环境直接替换核心提示词。

9.6 关于成本控制

专用 Agent 的成本主要在模型调用量上。每多一次工具调用，就多一轮模型请求。优化方向有三个：减少工具调用轮次，合并相关查询；把复杂工具结果先做摘要再交给模型；在低风险场景使用更快更便宜的模型。成本问题应该在架构设计阶段就考虑，而不是账单出来之后才补救。

9.7 回到 Blitz Agent

这篇文章从 Blitz Agent 的“专用 Agent”定位切入，实际上是想表达一个判断：Agent 开发的下半场，赢家不会是“什么都能干”的通用助手，而是那些在特定任务上快、稳、准的专用智能体。无论你最终选择自己写代码，还是使用 Blitz Agent 这类平台，核心思路是一致的——先定义清楚任务边界，再选择工具，再设计验证方式。

如果你想真正掌握 Agent 开发，建议按照本文的示例手动实现一遍最小 Agent 循环。不要急着引入重型框架，先理解模型、工具和上下文之间的交互关系。等你对 Agent 的运行机制有了手感，再去对比不同的框架和平台，你会发现它们本质上都是“专用 Agent 工程约束”的不同实现。到那个时候，你评估一个工具是否适合你，就只剩下一个问题：它能不能帮你把专业任务的执行成本降下来。