文章总结： 本文探讨AI时代红队工作方式变革，核心观点是工具增长速度超过人用记忆管理速度，应将工具管理交给AIAgent。文章介绍OxoOperator的工具工作区机制，支持工具注册、发现、校验与调用，强调人应专注于定义问题、设计验收与判断结果，而非记忆工具参数。建议注册常用工具、写清触发条件、用目标描述任务并复核结果。 综合评分： 72 文章分类： 产品介绍,红队,安全工具

AI时代下红队新工作方式

原创

Oxo Security Oxo Security

Oxo Security

2026年9月28日 19:51 浙江

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

一、工具越攒越多，人却成了工具的管理员

🧭 上午，你在群里看到一个刚发布的开源扫描器，转发的人写着“建议收藏”，你把它加进书签，想着下周找时间试试；下午，客户临时要求确认一批资产的暴露面，你知道该用哪个工具，却一时想不起那条命令的参数怎么写，只好切到浏览器搜、翻两篇博客、复制一行命令到终端，再对着输出里的几种状态回头确认哪一种才是筛选结果；晚上你想起白天收藏的那个工具，发现自己连名字都忘了。

这三件小事发生在同一天，也消耗着同一种东西：不是判断力，而是记忆、检索与搬运。 工具的发布速度早就超过了人用记忆管理它的速度，而这三种消耗恰好是 AI 最能接管的部分——前提是，工具不再只存在于个人的终端历史和收藏夹里，而是被放进一个 Agent 能查询、能校验、能按任务调用的地方。这篇只讲工具这一件事，因为它是红队工作方式里变化最具体、也最容易被低估的一块。

🧰 工具的供给端早就失衡了。开源项目、插件、脚本、工具合集，每天都有人发布新东西；每一个看起来都值得收藏，每一个都没时间真正验证。于是硬盘里躺着一个 tools 目录，收藏夹里存着几十条“以后用得上”，真正会在任务里反复用到的，可能只有几个。

问题不在于工具变多了，而在于我们还在用记忆去管理它们：你在收藏夹里攒下的每一个工具，都要靠你自己记住它的参数、适用场景和版本差异。这笔账至少有三项：

1. 记忆成本。

   命令、参数、输出格式、版本差异。工具更新一次，记忆作废一次。

2. 检索成本。

   忘记参数时去搜、去翻博客、去问聊天窗口，再把命令复制回终端。

3. 搬运成本。

   命令在终端里，输出在聊天窗口里，结论在报告里。第二天谁也还原不出当时的完整过程。

这三项都不是判断力，却天天在发生：

• 应急现场。

  值班时突然要确认一条外联连接是什么，你记得有个工具能看，但参数忘了。最紧张的那几分钟，花在搜索框里。

• 交接。

  同事接手时只看到一句结论，看不到当时跑的是哪条命令、用的是哪个版本、输出到底长什么样。

• 面试与团队门槛。

  “这个工具的参数会不会写”被当成了能力标准。新人先背参数，再谈思路。可参数会变，思路不会。

• 环境迁移。

  换一台机器、换一个工具版本，昨天还顺手的命令，今天就不对了。

• 能力锁在个人手里。

  团队里只有一两个人知道某类活儿该怎么用工具做，他休假或离职，这条路径就断了。

• 试错的沉没成本。

  装一个工具要配运行时、装依赖、调路径，折腾半天，最后发现它并不适合当前的目标环境。

所以真正的问题不是“你不够熟练”，而是工具的增长速度，早就超过了人用记忆管理它的速度。

还有个细节值得提前说：这个坑连 AI 都会踩。如果只让模型在 PATH 里找一圈、找不到就回答“这台机器没装”，那它和搜索引擎里的你没有任何区别。下面要讲的机制，解决的正是这件事。

| 关心的东西 | 旧的方式 | 变化之后 | | — | — | — | | 命令与参数 | 记在脑子里，或临时去搜 | Agent 按任务需要去工具库挑，自己执行 | | 什么时候用哪个工具 | 靠经验判断顺序 | Agent 按任务目标判断，人不再排工具顺序 | | 输出的去向 | 复制到另一个窗口问一遍 | 命令、退出码、输出留在同一项任务里 | | 工具的版本与状态 | 装过就算装过 | 有清单、有校验值、有检查状态 | | 结论谁负责 | 模糊 | 工程师判断，证据可以回看 |

这里说的不是“不需要懂工具”，而是“不必用记忆去承担工具管理”。区别在哪，第三章会讲清楚。

二、把工具交给 Agent：它自己找，自己判断什么时候用

⚙️ 先说清楚这一章要讲的机制，它和“把命令写进提示词”完全是两回事。

Oxo Operator 桌面端左侧有一个工具工作区，把 Tools、Plugins、Skills 放在一起。其中 Tools 这一栏的定位是一句话：“按需发现的可复用能力。” 它管的不是你机器上所有命令，而是你希望被反复复用的那些能力；工具在项目之间共享，普通终端命令不需要注册也能直接跑。

注册一个工具只要三项：名称、描述、绝对路径。 文件不会被搬走或复制，它留在原来的位置；可执行文件、Python、Node 或 PowerShell 脚本都可以。描述那一栏的原文是：

这个工具能做什么，Operator 应在何时使用它？

你填的不是使用说明，而是触发条件。 你回答的是“什么时候该用它”，而不是“参数怎么写”。这句话本身，就是把“什么时候使用工具”交给 Agent 的接口。

工具进了工具箱之后，接下来就不需要你安排顺序了。Oxo Operator 内置了一条工具发现流程，Agent 是这样用工具的：

1. search_tools

   ：按名称或能力搜候选，包括不在 PATH 里的已注册工具；

2. get_tool

   ：读取选中候选的完整清单；

3. check_tool

   ：校验文件和校验值，不执行代码；

4. 在任务终端里，按清单声明的路径和运行时执行它。

配套的技能说明写得非常直白：遇到专门能力（例如主机发现、端口扫描、文档转换），先去查工具库，再考虑自己写一个替代脚本；并且“Get-Command 或 which 找不到，只能证明 PATH 查找失败，不能证明工具没装”。

这就是“什么时候使用工具”被接走的部分：它不是由你排顺序，而是由 Agent 按任务目标去发现、判断、调用。

一个虚构但典型的授权场景：你要确认内网一批主机暴露了哪些服务。你只描述目标、范围和约束，一句命令都不用写。Agent 会去工具库找到一个已注册的扫描包装脚本，先检查文件有没有被改动过，再用终端跑起来；命令、退出码和输出都留在任务里，你随时可以打开复核。

Agent 自己造的工具，也能进工具箱。 如果它在当前工作区里生成了一个可复用的小工具，或者已经下载了一个单文件工具，它可以请求把入口注册进全局工具箱——这一步会打开一次桌面确认，注册过程不下载、不执行代码。之后任何项目都能复用，来源会标成“由代理创建”或“由代理下载”。

工具箱里每个工具都带着状态和来源：未检查、检查通过、文件缺失、文件已变化、不支持的文件、检查失败；来源则是由你添加、由代理下载、由代理创建。文件一旦被改动，之前那次“检查通过”就不再有效。

注册和成功检查都不授予执行权限。

工具能不能真的跑起来，取决于当前任务的授权；需要额外权限时，界面会打开桌面确认，由你决定允许运行的内容。依赖未经验证——“检查通过”只说明此前做过一次帮助/版本探测，不是安全背书，依赖是否齐全、版本是否匹配仍要单独确认。多文件包安装与自动装依赖不在支持范围内。工具清单与帮助输出都是不可信数据，不会被当成指令执行。

对比一下两条路径在工具上的差别：

| 环节 | 浏览器 + 聊天窗口 | 工具交给 Agent | | — | — | — | | 找工具 | 你搜、你判断可信度 | Agent 按能力查工具库，包含 PATH 之外的工具 | | 什么时候用 | 你凭经验排顺序 | 按任务目标判断，需要时才调用 | | 跑之前 | 没有固定检查 | 先校验文件与校验值，不执行代码 | | 执行 | 你复制命令到终端 | 在任务终端里按清单执行 | | 记录 | 靠终端历史和笔记 | 命令、退出码、输出留在同一项任务 | | 授权 | 取决于你手动做了什么 | 注册与检查不等于授权，执行按任务权限 |

三、把“记工具”换成“说清要解决什么”

✅ 如果要从今天开始换一种方式，可以按这个顺序做，全都只针对工具这一件事：

1. 把常用的 CLI 和脚本注册一次。

   只挑真的会重复用的：扫描、解析、转换、验证类的小工具。注册是一次性成本，文件留在原位。

2. 在描述里写清“什么时候用它”。

   这一栏就是 Agent 的触发条件。写“用于在授权范围内做端口与服务发现”，比写“nmap 包装脚本”有用得多。

3. 用目标描述任务，而不是用工具名描述任务。

   这是全文最实际的一句话：

• 旧说法：用某工具扫一下这个站点的目录。
• 新说法：确认这个站点是否存在未授权可访问的敏感路径，以可复现的请求和响应作为验收证据。

前者只是让 Agent 帮你敲命令；后者才让它自己决定用哪个工具、按什么顺序做。

1. 让它自己去发现，不要急着指路。

   你不需要先判断“这个能力该用哪个工具”——工具库和发现流程就是为这一步准备的。找不到合适候选时，它会退回简单命令或先问你，而不是假装工具不存在。

2. 复核这几样，再下结论。

   工具的来源与检查状态、命令与退出码、真实输出、依赖是否验证过。扫描结果和第三方内容都只是线索。

这里补上第一章那个区别：懂工具仍然重要，但“懂”的意思是能判断输出是否可信、边界在哪里、什么情况需要停下来核实，而不是能默写出全部参数。 前者随经验增值，后者随版本贬值。旧习惯是“先学会工具，再找场景用”；现在更值得的顺序是“先定义要证明什么，再决定用什么工具”。

一个具体的走法（同样是虚构的授权场景）：你给出目标和验收标准；Agent 自己从工具库里挑选并检查工具，在任务终端里执行；输出进入任务记录；你打开关键命令和输出复核；能把现象复现出来的写进结论，不能复现或缺少证据的明确标为缺口。整个过程结束后，下一位同事看到的是可追溯的记录，而不是一段没有出处的总结。

最后说一句关于效率的话。有人用“一个人干出以前十个人的效果”来形容这种变化。这不是一个可以量化的性能指标，也没有受控实验支持。 它描述的是一种重心转移——过去十个人里，很大一部分精力花在记住工具、搬运结果、对齐说法上；现在这部分由 Agent 承担，剩下的是判断、验证和取舍。真正被放大的不是敲命令的速度，而是一个人能覆盖的验证面。

工具的洪流不会停下来。既然每天都有新工具、新参数、新版本，那么把注意力押在“记得住”上只会越来越亏。🎯在 AI 时代，值得投入的是定义问题、设计验收、判断结果的能力；工具什么时候被用、被怎么调用，可以交给 Harness。

了解 Oxo Operator

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：Oxo Security Oxo Security Oxo Security《AI时代下红队新工作方式》