最近大半年我身边做安全的同事几乎都在琢磨同一件事AI Agent到底能不能真正帮上忙以及它干完活之后留下来的东西到底是属于平台的、属于提示词的还是属于自己团队的可沉淀资产。先说结论能但前提是别把Agent当成“一个更聪明的问答机器人”而是把它当成“一个需要装配技能的执行体”。你想让它稳定地做告警研判、做情报抽取、做配置核查就得为它开发专门的Skill技能。而这些Skill一旦被工程化地整理、测试、版本化管理就不再是几条飘在对话框里的提示词而是真正意义上的可复用数字资产。这篇文章不聊概念直接从网安人的视角出发讲讲我在实际开发Agent Skill过程中的完整思路、踩过的坑、以及如何把技能沉淀成资产的具体步骤。不管你是在做SOC自动化、威胁情报处理还是想给团队搭建安全知识库这篇内容都能给你一条可以直接落地的路径。1. 先想清楚Agent Skill到底是不是一件“正经资产”很多安全从业者第一次接触AI Agent时习惯性动作是打开对话框把一段告警日志粘进去然后问“这个是不是恶意”。这么玩两天就会发现结果忽好忽坏换个模型、换个表达方式结论就飘了。问题的根源在于你没有给Agent一套可复用的“职业能力”只是在临时雇佣一个什么都会一点但不精的实习生。1.1 网安人为什么突然都在关注Skill因为过去的自动化套路碰到天花板了。传统的安全编排与自动化响应SOAR擅长的是“定了规则就执行”比如固定IP封禁、固定格式的工单派发但遇到需要综合判断的活儿比如“这条Webshell请求到底是真实攻击还是WAF误报”规则写深了维护成本爆炸写浅了误报率让人崩溃。AI Agent的引入恰恰是为了补上“判断”这一环而判断能力必须高度场景化这种场景化的能力封装就是Skill。Skill在主流Agent体系里通常被定义为“Agent可调用的专业化能力模块”它比普通提示词更结构化包含明确的能力描述、输入输出契约、可执行的工具函数、以及判断逻辑。对网安人来说这其实很像过去在SOAR里写剧本Playbook只不过以前的每一步都是写死的if-then现在变成了“Agent理解目标后用Skill提供的方法去执行”灵活度上了一个台阶。1.2 拆解“可复用数字资产”这个目标的边界既然要谈资产就不能停留在“我写了几个好用的提示词”这个层面。一份真正能称得上数字资产的Skill至少要满足四个条件可交付不是记在某个人脑子里的经验而是有完整文档、代码、配置的文件集合换一个人拿过去就能用。可评测有明确的测试集和评估指标能说清楚它对哪些样本表现好、哪些不行。可维护有版本号、变更记录、模块化结构出问题时能定位到是哪个环节退化。可移植不完全绑定某一个Agent平台或某一个模型核心逻辑能以某种形式迁移到其他环境。这四个条件听起来像是软件工程的标准但实际做下来你会发现它们对Skill同样成立甚至更关键。因为提示词和模型推理天然带有不确定性如果没有评测和版本管理你根本不知道哪天改了一句措辞整个技能的行为就变了。这比改坏一段普通代码更隐蔽、更危险。1.3 哪些安全能力适合优先做成Skill不是所有安全任务都适合马上Skill化。我自己筛选时的标准很简单高频、边界清楚、输出可验证、知识密集而且目前靠人工做很费时间。按这个标准我列了一个对照表适合优先Skill化暂不建议Skill化告警降噪与研判辅助复杂恶意样本逆向分析威胁情报结构化抽取IOC、战术技术过程需要物理接触/私有协议破解的任务日志异常模式识别需多部门线下协调的事件响应安全基线配置核查没有明确“标准答案”的战略决策钓鱼邮件特征分析对时效性要求极高、秒级响应的任务为什么攻击取证这类复杂任务暂时不建议因为逆向分析高度依赖上下文递进推理而且样本往往带有强对抗性Agent在前几步判断失误后很难自我纠正至少目前的模型水平还撑不住全自动。反过来看告警研判它虽然也需要经验但证据类型相对固定IP、URL、UA、时间序列、威胁情报命中输出结论可被人快速验证特别适合让Agent用Skill辅助决策。2. 从0到1开发一个真正能用的研判Skill理论说完了我们直接动手。我拿“告警研判辅助”这个场景当例子因为它最典型几乎每个安全团队都有需求而且开发周期短两天就能出最小版本。2.1 给场景画一条“不做什么”的边界动手写任何代码之前先把边界划出来。我当时给自己定的范围是只负责对单个告警做初步研判输出恶意性评估、关键证据和处置建议不负责自动封禁、不负责跨告警关联分析、不负责与工单系统交互。边界画死的意义在于Agent不会被你无意识地推向一个超出能力圈的领域而你也更容易设计评测集。比如“只做Web类告警”那么输入就应该限定为Web访问日志和WAF/IDS告警处理流程围绕请求方法、URL路径、响应码、UA、来源IP、命中规则这几类字段展开。一旦告警类型变成主机入侵、数据外传Skill应该明确拒绝或提示切换技能而不是硬着头皮给一个不靠谱的结论。2.2 把输入输出固化成“契约”而不是靠感觉这是我和很多初学者最大的分水岭。多数人让Agent分析告警就是在提示词里写“请判断这条日志是否恶意”然后看它自由发挥。真正工程化的做法是先定义结构化输入输出让Skill变成一个严格签名的函数。一个简化版的输入契约长这样{ alert_id: WAF-20250311-001, rule_name: SQLi_error_based, severity: high, timestamp: 2025-03-11T14:22:3108:00, src_ip: 203.0.113.66, dst_ip: 198.51.100.10, request: { method: POST, url: /api/query, body_sample: id1 AND extractvalue(1,concat(0x7e,user()))-- -, user_agent: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1) }, response_status: 500 }对应地输出契约也必须是结构化的{ verdict: malicious, confidence: 0.87, evidence_chain: [ {type: rule, content: SQLi报错注入规则命中}, {type: payload, content: 检测到extractvalue函数与报错注入特征}, {type: threat_intel, content: 来源IP在过去24小时命中3次恶意扫描}, {type: context, content: 目标接口存在历史SQL注入漏洞记录} ], suggested_action: 建议对该IP执行临时封禁并通知业务方排查数据泄露, needs_human_review: true }有了这套契约Agent的自由度就被限制在“如何从输入推导出结构化的输出”上而不是连输出格式都每次不一样。后面做评测、做跨平台迁移、做结果入库都依赖这一步。这一步做得越扎实Skill的生命力越长。2.3 把研判经验拆成多条可执行的证据线安全专家的研判经验往往是“一眼就觉得不对劲”但Agent学不会这种直觉。你需要把自己脑子里看似感性的判断拆解成Agent可以按步骤执行的证据线。我把告警研判拆成了四条线第一规则线。看命中了哪条检测规则规则本身带什么语义是SQL注入、XSS、命令执行还是路径穿越。这条线是最直接的起点但很多规则误报率不低不能只靠它下结论。第二载荷特征线。对请求体、URL、响应体做模式提取。比如检测常见的注入关键字、编码绕过、二进制后缀上传、敏感路径访问特征。注意这里不要只做简单的字符串匹配因为攻击者经常换编码、做混淆最好能利用少量规则引擎或者“让Agent先做标准化解码再看特征”的方式。第三威胁情报线。查询来源IP、目标域名、文件哈希是否命中已知情报以及该IP与内部资产的历史交互频率。这个环节通常需要调用外部API所以Skill需要绑定一个“威胁情报查询函数”而不是让Agent凭空想象。第四条业务上下文线。这条最容易被忽略但也最关键。同样的SQL注入报错出现在内网测试系统和出现在核心交易接口上紧急程度完全不同。Agent在Skill里应该被赋予一部分资产信息比如接口是否核心资产、是否存在历史漏洞记录、系统属于测试环境还是生产环境。四线并行之后Skill内部的推理才不是“一句话拍板”而是有依据的多步分析。2.4 从“会聊天”到“会交活”输出校验与兜底策略让Agent输出结构化结果只是第一步更关键的是要让输出结果可以被程序校验。我开发的每个Skill都会挂一层“输出校验器”它做的事情很简单检查输出字段是否齐全、verdict是否在枚举值里、confidence是否在0-1区间、evidence_chain里引用的IP/URL是否符合格式。这一步看着基础但它能拦下最危险的幻觉问题。曾经有次我在测试一个开源情报抽取Skill它信誓旦旦地输出一个恶意文件哈希结果我拿正则一查那串字符根本不满足SHA256的格式要求是模型自己编的。这种事情在安全场景下绝对不能容忍因为一旦伪造的IOC进入检测流程要么漏报、要么误封。另外还有一个兜底策略当Skill整体置信度低于一定阈值我常用0.6或者多个证据线互相矛盾时必须明确返回“无法研判”的结论并转人工。你要在Skill层面就承认AI能力有限而不是让它硬着头皮给答案。网安人最怕的不是模型说“不知道”而是模型自信地给出一个错答案。2.5 最小可用版本的实现路径这里我用一个非常精简的目录结构来展示一个Skill可以怎么组织alert_triage_skill/ ├── skill.md # 技能说明文档 ├── prompt.md # 引导模型推理的主提示词 ├── schemas/ │ ├── input_schema.json # 输入契约 │ └── output_schema.json # 输出契约 ├── tools/ │ ├── intel_lookup.py # 威胁情报查询函数 │ ├── payload_check.py # 载荷特征提取函数 │ └── context_loader.py # 资产上下文加载函数 ├── tests/ │ ├── cases.json # 评测样本 │ └── evaluator.py # 评测脚本 ├── CHANGELOG.md └── version.txt实现的顺序我建议是先写输入输出契约再写评测样本然后写提示词和工具函数最后把整个流程串起来。我当时犯过顺序错误先写了提示词再去补契约结果反复改框架浪费了将近一天时间。先定契约还有个好处设计阶段就会有意识地思考“结果好不好衡量”而不会把大把精力花在对话体验上。提示词部分不需要长篇大论关键是引导模型按四条证据线的顺序走并且严格按JSON输出我把这部分做得像给新员工的SOP一样清楚你是一名安全运营中心的告警研判专家。收到告警后严格按以下流程处理第一步提取请求中的标准化特征第二步检查载荷中是否存在攻击模式第三步调用情报工具查询来源IP和资产信息第四步基于所有证据输出结构化JSON。禁止跳过任何一步。3. 把Skill当成软件工程产品来维护很多人做到上面那一步就收了但我想说如果到此为止你拥有的只是一次性脚本不是数字资产。真正的资产化是从“能跑”到“敢长期用”的过程。3.1 用“评测集”代替“感觉好用”“这两天测下来效果不错”这种评价在工程上毫无意义。我的做法是为每个Skill建立一套评测样本集里面包含典型恶意样本、容易误报的正常业务样本、攻击者故意混淆变种、以及边界情形比如缺字段、畸形协议。评测集的最初来源可以是历史工单里经过确认的告警数据把敏感信息做脱敏处理后保存成本地文件。每条样本都需要标注“预期结论”和“关键证据点”这个标注过程本身也是对团队安全经验的整理。我看到很多团队在这步偷懒理由是标注太花时间。但换个角度想这其实就是把有经验的人脑子里的例子搬到了工程里。这套评测集一旦积累到几百条它的价值甚至超过Skill的提示词本身因为它才是判断这个技能“有没有退化”的唯一依据。3.2 把正确率拆细别只看“判得对不对”在评测Skill时我会把指标拆成四个维度分别统计评测维度说明及格参考结论正确率verdict与预期是否一致90%以上证据引用准确率输出里引用的IP/payload是否真实存在有没有编造100%格式符合率输出能否一次通过Schema校验95%以上关键漏报率恶意样本被判为正常或低风险的比例低于2%这里要特别强调“证据引用准确率”和“关键漏报率”。幻觉对于安全Impact太大宁可少给一条情报也不能给一条假的。而关键漏报是安全运营不能承受的底线如果评测集里那条明确的恶意识别不了整个Skill就不该上线。每次改完提示词或工具函数我都会把全部评测集重新跑一遍只有四个指标同时达标才允许晋升版本号。3.3 版本和迭代流程学会说“不兼容变更”任何上线过的Skill都会随着场景变化而调整这个过程必须有版本管理。我的习惯是采用语义化版本主版本号代表契约变更、次版本号代表功能增强、修订号代表问题修复和Prompt微调。变更记录CHANGELOG里必须写清楚这次改了什么、为什么改、评测集上四项指标各涨跌了多少。很多人觉得记录是负担但真到出问题时能帮你快速定位“是不是某次改动导致判决标准放宽”的就是这份记录。我有一次就是靠它发现因为想提高恶意告警召回率而放宽了载荷特征门槛结果误报率翻了一倍新版本回滚后一切恢复正常。还有一个值得注意的经验尽量做到“只允许在评测集上通过后修改版本”不要边改边上线。我在早期几次实践中经常在群里和同事讨论时顺手改一句提示词就发出去结果行为漂移了都没察觉。后来我们定了一条规矩任何改动先上评测集再进预发环境最后才能对接到运营流程里。3.4 文档也是资产让Skill可以被“交接”安全团队的岗流动性其实不低一个Skill如果只有原作者能维护那它就不是资产而是个人依赖。为此我在Skill目录里强制放一份skill.md内容包括适用场景与不适用场景、输入输出字段说明、依赖的外部接口与密钥管理方式、运行环境要求、已知限制以及维护责任人。有一次团队里一位负责写威胁情报抽取的同事转岗接手的人靠着skill.md和评测集差不多两天就接手了后续迭代不用从头去猜之前的思路。这件事让我更确信文档不是写给别人看的表面功夫而是让资产脱离个人而存在的关键。4. 跨平台复用与数字资产运营Skill做得再专业如果只能在一个固定的Agent平台里跑资产价值还是有限。理想状态是一个Skill的核心判断逻辑能在不同环境之间迁移你的积累跟着你走而不是被平台绑架。4.1 Skill的通用内核与平台差异隔离不同的Agent框架对“技能”的封装方式不完全一样有的叫Tool、有的叫Action、有的叫Plugin对提示词格式、工具注册方式和上下文管理也有各自的偏好。如果你一上来就按某个平台提供的接口深度定制那后续想迁移基本等于推翻重写。我的做法是在设计Skill时做一层分层底层是“领域能力层”包括那些工具函数情报查询、载荷检测、资产信息读取它们不依赖任何特定模型或Agent框架用普通的Python库写成独立函数即可。上层是“适配层”只负责把当前平台传来的输入转换成内部结构化格式并把内部计算结果转成平台需要的回复格式。这样当你要从A平台迁移到B平台时只需要改上层适配底层全都不用动。实际做下来迁移一个成熟Skill的时间可以压缩到半天到一天。4.2 把Skill的“内核”下沉为独立服务更进一步的做法是把Skill运行所需的服务封装成独立API。比如告警研判Skill里用到的“载荷特征提取”和“情报查询”完全可以做成两个独立服务任何Agent只要通过HTTP调用就能复用。这时候Skill本身变成了一个“编排层”它负责调用服务、组织证据、生成结论。这样做的额外好处是即使未来某个Agent平台整个换掉你的领域判断能力仍然以服务形态保留着。而且不依赖模型平台的服务还能独立测试、独立监控性能算是一次投入、长期受益。缺点是初期工程量稍微大一点但比起每年换一个Agent平台导致所有自动化推倒重来这笔投入绝对划算。4.3 从个人资产到团队资产的跨越个人积累Skill的过程相对自由想怎么迭代都行但一旦涉及团队协作就需要建立统一的评价和发布机制。我们团队现在的流程是开发者将Skill提交到内部仓库同时附上评测集和说明文档由同行评审确认评估指标达标再发布到团队的Agent服务中使用后定期跑回归测试。跨过“个人到团队”这步Skill的可复用价值才真正放大。后来我们也把几个成熟Skill直接用于新员工培训让新人在评测集上试跑、对比自己和Agent的结论差距这比看十页培训文档都管用。新人的独特视角反过来又帮我们发现评测集盲区形成正向循环。4.4 Skill资产的“生命周期管理”资产不是越堆越好Skill也是如此。一个启用了大半年的技能可能因为业务系统改造、攻击手法变化而逐渐失效。所以我养成了定期检视的习惯每月看一次评测集上的表现每条告警反馈都会被记录积累到一定数量就触发一次全面回归。如果连续几个周期表现持续下降且无法通过迭代改善就果断下架避免一个过时Skill继续消耗计算资源和信任度。把下架机制纳入迭代流程是很多团队忽略的环节。数字资产的健康程度不在于新增了多少而在于存量资产是否有持续的生命力。5. 走得稳的几个细节与常见问题最后分享几个具体到日常操作的经验都是跳过坑之后才总结出来的。5.1 Prompt漂移是最隐蔽的敌人模型会更新、提示词会调整、评测集会被改动任何一个变化都可能让Skill的行为发生微妙偏移。比如模型升级后同样一句“只返回JSON”的约束输出里可能就开始夹带问候语。我的对策是双保险一是输出Schema强校验加上重试逻辑格式不对就重新生成二是在每个核心版本发布时固定记录当时使用的模型版本和参数一旦模型升级导致指标下降可以快速定位原因。5.2 警惕幻觉污染证据链这是我认为网安场景中最重要的一点。Agent在证据不足时习惯“脑补”内容轻则编造一条从未命中过的规则重则伪造一个恶意IP。规避手段有三层第一层是在Skill的工具函数里植入严格的数据格式校验第二层是要求所有关键证据都必须来自工具函数的返回值而不是模型记忆第三层是在输出契约里增加“证据来源类型”字段强制标注该证据来自规则命中、外部查询还是上下文文件。每一条证据都可以追溯幻觉就无处遁形。5.3 上下文窗口与成本控制告警日志往往很长但Skill真正需要关注的字段有限。我的做法是先让工具函数做“字段裁剪”只把与决策相关的信息放进上下文而不是把整条原始请求体全量塞给模型。例如对于Web日志只保留URL、UA、状态码、关键请求头把大段响应体丢给单独的特征提取函数处理最后把特征标签传给模型。这样做既降低token消耗也减少干扰信息对判断的负面影响。按我目前的业务量估算一个研判请求大约消耗不到两千token成本完全在可接受范围内。控制上下文的关键原则是“让模型做判断不让模型读全文”。5.4 权限最小化Agent不应该有“手”最后一条是安全的底线。我开发的所有SkillAgent都只有“分析并给出建议”的权力不直接对接封禁、删除、修改等操作接口。即使未来要做自动化处置也必须在Skill之外再加一道人工确认闸门。有一次我在实验环境里给Agent接了封禁权限模拟测试时发现它因为一次误判把内网一台正常监控服务器的IP封了幸好只是测试环境。这件事给我的教训很深Agent的可靠性永远不可能达到100%那么就不应该在技能层面赋予它危及业务的执行能力。哪怕整个Skill被玩得很溜权限也永远要退到人工兜底之后。在开发Agent Skill这件事上我最大的体会是技术含量并不在模型提示词的巧妙程度而在于你能不能把安全判断力拆解成可执行、可评测、可复用的工程模块。这不是一条简单路但走通之后你手里沉淀下来的每一块技能都在持续给你和你的团队创造价值。先挑一个高频、边界清楚的小任务做起来跑通之后你会发现这条路比想象中更远也更值。
最近大半年我身边做安全的同事几乎都在琢磨同一件事AI Agent到底能不能真正帮上忙以及它干完活之后留下来的东西到底是属于平台的、属于提示词的还是属于自己团队的可沉淀资产。先说结论能但前提是别把Agent当成“一个更聪明的问答机器人”而是把它当成“一个需要装配技能的执行体”。你想让它稳定地做告警研判、做情报抽取、做配置核查就得为它开发专门的Skill技能。而这些Skill一旦被工程化地整理、测试、版本化管理就不再是几条飘在对话框里的提示词而是真正意义上的可复用数字资产。这篇文章不聊概念直接从网安人的视角出发讲讲我在实际开发Agent Skill过程中的完整思路、踩过的坑、以及如何把技能沉淀成资产的具体步骤。不管你是在做SOC自动化、威胁情报处理还是想给团队搭建安全知识库这篇内容都能给你一条可以直接落地的路径。1. 先想清楚Agent Skill到底是不是一件“正经资产”很多安全从业者第一次接触AI Agent时习惯性动作是打开对话框把一段告警日志粘进去然后问“这个是不是恶意”。这么玩两天就会发现结果忽好忽坏换个模型、换个表达方式结论就飘了。问题的根源在于你没有给Agent一套可复用的“职业能力”只是在临时雇佣一个什么都会一点但不精的实习生。1.1 网安人为什么突然都在关注Skill因为过去的自动化套路碰到天花板了。传统的安全编排与自动化响应SOAR擅长的是“定了规则就执行”比如固定IP封禁、固定格式的工单派发但遇到需要综合判断的活儿比如“这条Webshell请求到底是真实攻击还是WAF误报”规则写深了维护成本爆炸写浅了误报率让人崩溃。AI Agent的引入恰恰是为了补上“判断”这一环而判断能力必须高度场景化这种场景化的能力封装就是Skill。Skill在主流Agent体系里通常被定义为“Agent可调用的专业化能力模块”它比普通提示词更结构化包含明确的能力描述、输入输出契约、可执行的工具函数、以及判断逻辑。对网安人来说这其实很像过去在SOAR里写剧本Playbook只不过以前的每一步都是写死的if-then现在变成了“Agent理解目标后用Skill提供的方法去执行”灵活度上了一个台阶。1.2 拆解“可复用数字资产”这个目标的边界既然要谈资产就不能停留在“我写了几个好用的提示词”这个层面。一份真正能称得上数字资产的Skill至少要满足四个条件可交付不是记在某个人脑子里的经验而是有完整文档、代码、配置的文件集合换一个人拿过去就能用。可评测有明确的测试集和评估指标能说清楚它对哪些样本表现好、哪些不行。可维护有版本号、变更记录、模块化结构出问题时能定位到是哪个环节退化。可移植不完全绑定某一个Agent平台或某一个模型核心逻辑能以某种形式迁移到其他环境。这四个条件听起来像是软件工程的标准但实际做下来你会发现它们对Skill同样成立甚至更关键。因为提示词和模型推理天然带有不确定性如果没有评测和版本管理你根本不知道哪天改了一句措辞整个技能的行为就变了。这比改坏一段普通代码更隐蔽、更危险。1.3 哪些安全能力适合优先做成Skill不是所有安全任务都适合马上Skill化。我自己筛选时的标准很简单高频、边界清楚、输出可验证、知识密集而且目前靠人工做很费时间。按这个标准我列了一个对照表适合优先Skill化暂不建议Skill化告警降噪与研判辅助复杂恶意样本逆向分析威胁情报结构化抽取IOC、战术技术过程需要物理接触/私有协议破解的任务日志异常模式识别需多部门线下协调的事件响应安全基线配置核查没有明确“标准答案”的战略决策钓鱼邮件特征分析对时效性要求极高、秒级响应的任务为什么攻击取证这类复杂任务暂时不建议因为逆向分析高度依赖上下文递进推理而且样本往往带有强对抗性Agent在前几步判断失误后很难自我纠正至少目前的模型水平还撑不住全自动。反过来看告警研判它虽然也需要经验但证据类型相对固定IP、URL、UA、时间序列、威胁情报命中输出结论可被人快速验证特别适合让Agent用Skill辅助决策。2. 从0到1开发一个真正能用的研判Skill理论说完了我们直接动手。我拿“告警研判辅助”这个场景当例子因为它最典型几乎每个安全团队都有需求而且开发周期短两天就能出最小版本。2.1 给场景画一条“不做什么”的边界动手写任何代码之前先把边界划出来。我当时给自己定的范围是只负责对单个告警做初步研判输出恶意性评估、关键证据和处置建议不负责自动封禁、不负责跨告警关联分析、不负责与工单系统交互。边界画死的意义在于Agent不会被你无意识地推向一个超出能力圈的领域而你也更容易设计评测集。比如“只做Web类告警”那么输入就应该限定为Web访问日志和WAF/IDS告警处理流程围绕请求方法、URL路径、响应码、UA、来源IP、命中规则这几类字段展开。一旦告警类型变成主机入侵、数据外传Skill应该明确拒绝或提示切换技能而不是硬着头皮给一个不靠谱的结论。2.2 把输入输出固化成“契约”而不是靠感觉这是我和很多初学者最大的分水岭。多数人让Agent分析告警就是在提示词里写“请判断这条日志是否恶意”然后看它自由发挥。真正工程化的做法是先定义结构化输入输出让Skill变成一个严格签名的函数。一个简化版的输入契约长这样{ alert_id: WAF-20250311-001, rule_name: SQLi_error_based, severity: high, timestamp: 2025-03-11T14:22:3108:00, src_ip: 203.0.113.66, dst_ip: 198.51.100.10, request: { method: POST, url: /api/query, body_sample: id1 AND extractvalue(1,concat(0x7e,user()))-- -, user_agent: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1) }, response_status: 500 }对应地输出契约也必须是结构化的{ verdict: malicious, confidence: 0.87, evidence_chain: [ {type: rule, content: SQLi报错注入规则命中}, {type: payload, content: 检测到extractvalue函数与报错注入特征}, {type: threat_intel, content: 来源IP在过去24小时命中3次恶意扫描}, {type: context, content: 目标接口存在历史SQL注入漏洞记录} ], suggested_action: 建议对该IP执行临时封禁并通知业务方排查数据泄露, needs_human_review: true }有了这套契约Agent的自由度就被限制在“如何从输入推导出结构化的输出”上而不是连输出格式都每次不一样。后面做评测、做跨平台迁移、做结果入库都依赖这一步。这一步做得越扎实Skill的生命力越长。2.3 把研判经验拆成多条可执行的证据线安全专家的研判经验往往是“一眼就觉得不对劲”但Agent学不会这种直觉。你需要把自己脑子里看似感性的判断拆解成Agent可以按步骤执行的证据线。我把告警研判拆成了四条线第一规则线。看命中了哪条检测规则规则本身带什么语义是SQL注入、XSS、命令执行还是路径穿越。这条线是最直接的起点但很多规则误报率不低不能只靠它下结论。第二载荷特征线。对请求体、URL、响应体做模式提取。比如检测常见的注入关键字、编码绕过、二进制后缀上传、敏感路径访问特征。注意这里不要只做简单的字符串匹配因为攻击者经常换编码、做混淆最好能利用少量规则引擎或者“让Agent先做标准化解码再看特征”的方式。第三威胁情报线。查询来源IP、目标域名、文件哈希是否命中已知情报以及该IP与内部资产的历史交互频率。这个环节通常需要调用外部API所以Skill需要绑定一个“威胁情报查询函数”而不是让Agent凭空想象。第四条业务上下文线。这条最容易被忽略但也最关键。同样的SQL注入报错出现在内网测试系统和出现在核心交易接口上紧急程度完全不同。Agent在Skill里应该被赋予一部分资产信息比如接口是否核心资产、是否存在历史漏洞记录、系统属于测试环境还是生产环境。四线并行之后Skill内部的推理才不是“一句话拍板”而是有依据的多步分析。2.4 从“会聊天”到“会交活”输出校验与兜底策略让Agent输出结构化结果只是第一步更关键的是要让输出结果可以被程序校验。我开发的每个Skill都会挂一层“输出校验器”它做的事情很简单检查输出字段是否齐全、verdict是否在枚举值里、confidence是否在0-1区间、evidence_chain里引用的IP/URL是否符合格式。这一步看着基础但它能拦下最危险的幻觉问题。曾经有次我在测试一个开源情报抽取Skill它信誓旦旦地输出一个恶意文件哈希结果我拿正则一查那串字符根本不满足SHA256的格式要求是模型自己编的。这种事情在安全场景下绝对不能容忍因为一旦伪造的IOC进入检测流程要么漏报、要么误封。另外还有一个兜底策略当Skill整体置信度低于一定阈值我常用0.6或者多个证据线互相矛盾时必须明确返回“无法研判”的结论并转人工。你要在Skill层面就承认AI能力有限而不是让它硬着头皮给答案。网安人最怕的不是模型说“不知道”而是模型自信地给出一个错答案。2.5 最小可用版本的实现路径这里我用一个非常精简的目录结构来展示一个Skill可以怎么组织alert_triage_skill/ ├── skill.md # 技能说明文档 ├── prompt.md # 引导模型推理的主提示词 ├── schemas/ │ ├── input_schema.json # 输入契约 │ └── output_schema.json # 输出契约 ├── tools/ │ ├── intel_lookup.py # 威胁情报查询函数 │ ├── payload_check.py # 载荷特征提取函数 │ └── context_loader.py # 资产上下文加载函数 ├── tests/ │ ├── cases.json # 评测样本 │ └── evaluator.py # 评测脚本 ├── CHANGELOG.md └── version.txt实现的顺序我建议是先写输入输出契约再写评测样本然后写提示词和工具函数最后把整个流程串起来。我当时犯过顺序错误先写了提示词再去补契约结果反复改框架浪费了将近一天时间。先定契约还有个好处设计阶段就会有意识地思考“结果好不好衡量”而不会把大把精力花在对话体验上。提示词部分不需要长篇大论关键是引导模型按四条证据线的顺序走并且严格按JSON输出我把这部分做得像给新员工的SOP一样清楚你是一名安全运营中心的告警研判专家。收到告警后严格按以下流程处理第一步提取请求中的标准化特征第二步检查载荷中是否存在攻击模式第三步调用情报工具查询来源IP和资产信息第四步基于所有证据输出结构化JSON。禁止跳过任何一步。3. 把Skill当成软件工程产品来维护很多人做到上面那一步就收了但我想说如果到此为止你拥有的只是一次性脚本不是数字资产。真正的资产化是从“能跑”到“敢长期用”的过程。3.1 用“评测集”代替“感觉好用”“这两天测下来效果不错”这种评价在工程上毫无意义。我的做法是为每个Skill建立一套评测样本集里面包含典型恶意样本、容易误报的正常业务样本、攻击者故意混淆变种、以及边界情形比如缺字段、畸形协议。评测集的最初来源可以是历史工单里经过确认的告警数据把敏感信息做脱敏处理后保存成本地文件。每条样本都需要标注“预期结论”和“关键证据点”这个标注过程本身也是对团队安全经验的整理。我看到很多团队在这步偷懒理由是标注太花时间。但换个角度想这其实就是把有经验的人脑子里的例子搬到了工程里。这套评测集一旦积累到几百条它的价值甚至超过Skill的提示词本身因为它才是判断这个技能“有没有退化”的唯一依据。3.2 把正确率拆细别只看“判得对不对”在评测Skill时我会把指标拆成四个维度分别统计评测维度说明及格参考结论正确率verdict与预期是否一致90%以上证据引用准确率输出里引用的IP/payload是否真实存在有没有编造100%格式符合率输出能否一次通过Schema校验95%以上关键漏报率恶意样本被判为正常或低风险的比例低于2%这里要特别强调“证据引用准确率”和“关键漏报率”。幻觉对于安全Impact太大宁可少给一条情报也不能给一条假的。而关键漏报是安全运营不能承受的底线如果评测集里那条明确的恶意识别不了整个Skill就不该上线。每次改完提示词或工具函数我都会把全部评测集重新跑一遍只有四个指标同时达标才允许晋升版本号。3.3 版本和迭代流程学会说“不兼容变更”任何上线过的Skill都会随着场景变化而调整这个过程必须有版本管理。我的习惯是采用语义化版本主版本号代表契约变更、次版本号代表功能增强、修订号代表问题修复和Prompt微调。变更记录CHANGELOG里必须写清楚这次改了什么、为什么改、评测集上四项指标各涨跌了多少。很多人觉得记录是负担但真到出问题时能帮你快速定位“是不是某次改动导致判决标准放宽”的就是这份记录。我有一次就是靠它发现因为想提高恶意告警召回率而放宽了载荷特征门槛结果误报率翻了一倍新版本回滚后一切恢复正常。还有一个值得注意的经验尽量做到“只允许在评测集上通过后修改版本”不要边改边上线。我在早期几次实践中经常在群里和同事讨论时顺手改一句提示词就发出去结果行为漂移了都没察觉。后来我们定了一条规矩任何改动先上评测集再进预发环境最后才能对接到运营流程里。3.4 文档也是资产让Skill可以被“交接”安全团队的岗流动性其实不低一个Skill如果只有原作者能维护那它就不是资产而是个人依赖。为此我在Skill目录里强制放一份skill.md内容包括适用场景与不适用场景、输入输出字段说明、依赖的外部接口与密钥管理方式、运行环境要求、已知限制以及维护责任人。有一次团队里一位负责写威胁情报抽取的同事转岗接手的人靠着skill.md和评测集差不多两天就接手了后续迭代不用从头去猜之前的思路。这件事让我更确信文档不是写给别人看的表面功夫而是让资产脱离个人而存在的关键。4. 跨平台复用与数字资产运营Skill做得再专业如果只能在一个固定的Agent平台里跑资产价值还是有限。理想状态是一个Skill的核心判断逻辑能在不同环境之间迁移你的积累跟着你走而不是被平台绑架。4.1 Skill的通用内核与平台差异隔离不同的Agent框架对“技能”的封装方式不完全一样有的叫Tool、有的叫Action、有的叫Plugin对提示词格式、工具注册方式和上下文管理也有各自的偏好。如果你一上来就按某个平台提供的接口深度定制那后续想迁移基本等于推翻重写。我的做法是在设计Skill时做一层分层底层是“领域能力层”包括那些工具函数情报查询、载荷检测、资产信息读取它们不依赖任何特定模型或Agent框架用普通的Python库写成独立函数即可。上层是“适配层”只负责把当前平台传来的输入转换成内部结构化格式并把内部计算结果转成平台需要的回复格式。这样当你要从A平台迁移到B平台时只需要改上层适配底层全都不用动。实际做下来迁移一个成熟Skill的时间可以压缩到半天到一天。4.2 把Skill的“内核”下沉为独立服务更进一步的做法是把Skill运行所需的服务封装成独立API。比如告警研判Skill里用到的“载荷特征提取”和“情报查询”完全可以做成两个独立服务任何Agent只要通过HTTP调用就能复用。这时候Skill本身变成了一个“编排层”它负责调用服务、组织证据、生成结论。这样做的额外好处是即使未来某个Agent平台整个换掉你的领域判断能力仍然以服务形态保留着。而且不依赖模型平台的服务还能独立测试、独立监控性能算是一次投入、长期受益。缺点是初期工程量稍微大一点但比起每年换一个Agent平台导致所有自动化推倒重来这笔投入绝对划算。4.3 从个人资产到团队资产的跨越个人积累Skill的过程相对自由想怎么迭代都行但一旦涉及团队协作就需要建立统一的评价和发布机制。我们团队现在的流程是开发者将Skill提交到内部仓库同时附上评测集和说明文档由同行评审确认评估指标达标再发布到团队的Agent服务中使用后定期跑回归测试。跨过“个人到团队”这步Skill的可复用价值才真正放大。后来我们也把几个成熟Skill直接用于新员工培训让新人在评测集上试跑、对比自己和Agent的结论差距这比看十页培训文档都管用。新人的独特视角反过来又帮我们发现评测集盲区形成正向循环。4.4 Skill资产的“生命周期管理”资产不是越堆越好Skill也是如此。一个启用了大半年的技能可能因为业务系统改造、攻击手法变化而逐渐失效。所以我养成了定期检视的习惯每月看一次评测集上的表现每条告警反馈都会被记录积累到一定数量就触发一次全面回归。如果连续几个周期表现持续下降且无法通过迭代改善就果断下架避免一个过时Skill继续消耗计算资源和信任度。把下架机制纳入迭代流程是很多团队忽略的环节。数字资产的健康程度不在于新增了多少而在于存量资产是否有持续的生命力。5. 走得稳的几个细节与常见问题最后分享几个具体到日常操作的经验都是跳过坑之后才总结出来的。5.1 Prompt漂移是最隐蔽的敌人模型会更新、提示词会调整、评测集会被改动任何一个变化都可能让Skill的行为发生微妙偏移。比如模型升级后同样一句“只返回JSON”的约束输出里可能就开始夹带问候语。我的对策是双保险一是输出Schema强校验加上重试逻辑格式不对就重新生成二是在每个核心版本发布时固定记录当时使用的模型版本和参数一旦模型升级导致指标下降可以快速定位原因。5.2 警惕幻觉污染证据链这是我认为网安场景中最重要的一点。Agent在证据不足时习惯“脑补”内容轻则编造一条从未命中过的规则重则伪造一个恶意IP。规避手段有三层第一层是在Skill的工具函数里植入严格的数据格式校验第二层是要求所有关键证据都必须来自工具函数的返回值而不是模型记忆第三层是在输出契约里增加“证据来源类型”字段强制标注该证据来自规则命中、外部查询还是上下文文件。每一条证据都可以追溯幻觉就无处遁形。5.3 上下文窗口与成本控制告警日志往往很长但Skill真正需要关注的字段有限。我的做法是先让工具函数做“字段裁剪”只把与决策相关的信息放进上下文而不是把整条原始请求体全量塞给模型。例如对于Web日志只保留URL、UA、状态码、关键请求头把大段响应体丢给单独的特征提取函数处理最后把特征标签传给模型。这样做既降低token消耗也减少干扰信息对判断的负面影响。按我目前的业务量估算一个研判请求大约消耗不到两千token成本完全在可接受范围内。控制上下文的关键原则是“让模型做判断不让模型读全文”。5.4 权限最小化Agent不应该有“手”最后一条是安全的底线。我开发的所有SkillAgent都只有“分析并给出建议”的权力不直接对接封禁、删除、修改等操作接口。即使未来要做自动化处置也必须在Skill之外再加一道人工确认闸门。有一次我在实验环境里给Agent接了封禁权限模拟测试时发现它因为一次误判把内网一台正常监控服务器的IP封了幸好只是测试环境。这件事给我的教训很深Agent的可靠性永远不可能达到100%那么就不应该在技能层面赋予它危及业务的执行能力。哪怕整个Skill被玩得很溜权限也永远要退到人工兜底之后。在开发Agent Skill这件事上我最大的体会是技术含量并不在模型提示词的巧妙程度而在于你能不能把安全判断力拆解成可执行、可评测、可复用的工程模块。这不是一条简单路但走通之后你手里沉淀下来的每一块技能都在持续给你和你的团队创造价值。先挑一个高频、边界清楚的小任务做起来跑通之后你会发现这条路比想象中更远也更值。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
