2026年，软件工程的核心矛盾已经不是“模型够不够聪明”，而是“我们能不能驾驭它”。Harness Engineering的出现标志着AI辅助开发从“能用”走向“可控”。而当我们把这套工程范式引入安全领域，用它来重新审视代码审计Agent和自动化渗透Agent的设计，一些深层的可能性开始浮现。

一、什么是Harness Engineering？

2026年2月5日，HashiCorp联合创始人Mitchell Hashimoto在他的博客中首次明确使用了“Harness Engineering”这一术语。他对这一概念的定义简洁而深刻：

"It is the idea that anytime you find an agent makes a mistake, you take the time to engineer a solution such that the agent never makes that mistake again."[1]

几天后，OpenAI发布了一篇题为《Harness engineering: leveraging Codex in an agent-first world》的文章，详细报告了其内部团队在五个月内，以“零行手写代码”为硬约束，完全依赖Codex Agent构建了一个超过百万行代码的内部产品，约1500个Pull Request由三名工程师驱动，平均每人每天3.5个PR [2]。Martin Fowler网站上，Thoughtworks的Distinguished Engineer Birgitta Böckeler随后撰文评价这一实践，并指出了一个反直觉但至关重要的观点：确定性组件（Linter、结构测试、CI钩子）比LLM组件更重要，因为你不能用一个非确定性系统去守护另一个非确定性系统 [3][7]。

“Harness”一词来自马术中的驾驭装备：缰绳、马鞍、嚼子。这个比喻精准地描绘了当下的困境：AI模型是一匹力量惊人的纯血马，但没有方向感。Harness不是为了限制它的力量，而是把力量引向正确的方向。

Harness的三层架构

根据OpenAI的实践报告和社区的梳理，Harness Engineering可以分解为三个核心层次 [2][3][4]：

第一层：Context Engineering（上下文工程）。为Agent在正确的时间提供正确格式的正确信息。OpenAI的做法是将知识库沉淀到代码仓库内的结构化docs/目录中，而AGENTS.md仅作为约100行的目录页注入上下文，指向更深层次的事实来源：设计文档、架构图、执行计划、质量评级等等。核心原则是：对Agent而言，凡是不在上下文中的信息，就等于不存在。那些Slack讨论、Google Docs中的决策，如果没有沉淀到仓库里，Agent就像一个迟了三个月入职的新员工一样对此一无所知 [2]。

第二层：Architectural Constraints（架构约束）。通过确定性规则（自定义Linter、结构测试、CI验证）强制执行架构边界，而不是靠自然语言嘱咐Agent遵守规则。OpenAI在每个业务域中强制实施了严格的分层依赖：Types → Config → Repo → Service → Runtime → UI，下层不能反向依赖上层，任何违反的代码都过不了CI [2][4]。矛盾的是，约束解决方案空间反而使Agent更高效。这是因为当Agent可以生成任何东西时，它会浪费token探索死胡同；当边界清晰时，它更快地收敛到正确解。

第三层：Garbage Collection（垃圾回收）。定期运行的后台Agent扫描偏差、更新质量等级，并发起有针对性的重构Pull Request [2][3]。这是对技术债的持续偿还机制。

数据说话：Harness的量化价值

LangChain提供了一个硬核实验来证明Harness的价值。同一模型（gpt-5.2-codex）在Terminal Bench 2.0基准测试上，仅通过优化Agent运行的外部环境（验证回路、追踪系统等），排名从全球第30位跃升前5，得分从52.8%飙升至66.5%，而底层模型一个参数都没改 [4][5]。

安全研究员Can Boluk提供了另一个例证：他仅将Agent的代码编辑格式从传统patch改为自行设计的Hashline格式（一种由行号和内容哈希组成的锚点格式），Grok Code Fast 1的基准得分就从6.7%跃升至68.3% [19]。正如社区所总结的：一个格式的改变，等于十个模型升级。

二、安全视角下的Harness Engineering

理解了Harness Engineering的基本框架后，一个自然的问题浮现出来：当AI以远超人类的速度生成代码时，安全防线该如何跟上？

AI生成代码的安全隐忧

传统软件开发中，安全审查依赖人工Code Review、SAST扫描、渗透测试等手段。但当代码生产速度提高10倍时（如OpenAI报告的开发效率），这些机制面临根本性的挑战：

第一，审查瓶颈。当每位工程师每天产出3.5个PR时，传统的“审批驱动”合并策略变得不可行，因为等待审批的时间成本远超纠错成本。OpenAI的做法是将合并哲学从“审批驱动”转向“验证驱动”：全自动化测试 + Lint + 结构测试通过即自动合并，验证失败则Agent自修复后重试 [2]。

第二，信任债务（Trust Debt）。Cassie Kozyrkov提出的这一概念精准地描述了AI生成代码中的隐性风险：AI倾向于填补你指令中的空白，进行“自信的即兴发挥”，做出一堆你没要求的决定。这些决定目前看起来没问题，但在未来某个时刻会产生意料之外的成本 [6]。在安全场景下，这些未声明的假设尤其危险，因为它们很可能以安全漏洞的形式爆发。

第三，模式放大效应。Agent非常擅长模式复制。它们从代码库中学习并重复任何模式，包括不安全的模式。如果代码库中已存在不安全的编码实践（比如未经验证的用户输入直接拼接到SQL查询中），Agent会忠实地复制并放大这些不安全模式 [4]。

Harness作为安全防线的四个抓手

将Harness Engineering的Inform-Constrain-Verify-Correct框架 [7] 映射到安全领域，我们可以得到一套针对AI生成代码的安全防御体系：

• Inform（安全知识注入）：在AGENTS.md或等效配置文件中嵌入安全编码规范和项目特有的安全约束。例如，明确列出禁止使用的危险函数（如strcpy、eval、innerHTML），要求所有用户输入必须经过参数化查询处理，要求所有API端点必须实施认证和授权检查。OpenAI的实践表明，将Lint错误信息写得足够详细能让Agent在遇到错误时自我修正，而无需人工介入：不仅说“你违反了规则X”，还解释“为什么这个规则存在、正确做法是什么” [4]。
• Constrain（安全边界强制）：通过确定性工具（而非自然语言提示）实施安全边界。这包括：在CI中集成SAST工具（如CodeQL、Semgrep）作为强制性门禁，阻止含有已知漏洞模式的代码合并；通过依赖白名单限制Agent可引入的第三方库，防止供应链攻击；通过文件系统权限和网络策略限制Agent的操作范围。Böckeler的观察在安全场景下尤为关键：确定性约束比LLM层面的安全提示更可靠 [3]。
• Verify（安全验证闭环）：在Agent宣告任务完成之前，强制运行安全测试。LangChain的PreCompletionChecklistMiddleware模式 [4] 可直接用于安全验证，即在Agent试图退出时拦截，强制注入安全检查清单：SAST扫描是否通过？依赖项是否有已知CVE？敏感数据处理是否符合规范？
• Correct（安全反馈修复）：当安全扫描发现问题时，将结构化的漏洞信息（CWE编号、漏洞位置、修复建议）直接反馈给Agent，驱动其自主修复。这构成了一个安全持续改进的闭环：每一次安全修复都可以沉淀为新的Lint规则或文档约束，防止同类漏洞再次出现。

当前的局限

Böckeler对OpenAI报告指出的不足同样适用于安全场景：大量讨论了架构约束和熵管理，但功能正确性验证几乎缺席 [3][4]。在安全领域，这意味着我们擅长“约束Agent不做错事”（通过SAST、Linter、类型检查），但“验证Agent没有引入安全漏洞”，特别是逻辑漏洞，仍是一个远未解决的问题。传统SAST工具的误报率高，而逻辑漏洞（如权限绕过、业务逻辑缺陷）几乎无法通过静态规则捕获。

三、Harness Engineering加持下的代码审计Agent

如果说Harness Engineering的核心洞察是“决定结果好坏的最大变量往往不是模型有多聪明，而是模型被放在了一个什么样的环境里” [4]，那么代码审计这个高度依赖上下文理解、领域知识和系统性方法的安全工作，正是Harness Engineering有潜力大放异彩的场景之一。

现状：LLM在漏洞检测中的能力与局限

学术界已在积极探索LLM在安全漏洞检测中的应用。Santas Ciavatta等人在CMC期刊上发表的研究系统评估了多种LLM（包括CodeLlama、DeepSeek Coder、Gemini等）在源代码漏洞检测中的表现，对比了prompt persona、structured outputs、zero-shot等不同prompting策略的效果，并将LLM与传统SAST工具Find Security Bugs进行了组合对比 [8]。ICLR 2025上发表的IRIS框架提出了一种“神经-符号”方法，系统性地将LLM与静态分析结合：利用LLM推断污点规范（taint specifications）并执行上下文分析，以弥补纯静态分析工具需要人工编写规范的缺陷。IRIS在真实代码库中发现了4个此前未知的漏洞 [9]。

2026年1月，GitHub Security Lab发布了Taskflow Agent框架，将LLM用于CodeQL扫描结果的分诊。他们发现LLM在处理误报方面表现出色。那些对人工审计员“显而易见”但难以编码为正式代码模式的误报模式，恰好是LLM擅长的“模糊模式匹配”领域。通过该框架，他们快速分诊了大量Code Scanning告警，发现约30个真实漏洞 [10]。

同样在2025年底，Apiiro推出了AI-SAST产品，将AST扫描、LLM推理与其专利的Deep Code Analysis相结合：先用AST扫描进行快速确定性检测，再用专业化的AI Agent验证每个发现。这种AST+LLM的“共生”模式模拟了专家级应用安全研究人员的认知过程 [11]。

然而，ACL 2025上发表的一篇论文对LLM和LLM-based Agent在真实世界漏洞检测中的能力提出了更为审慎的评价。研究者构建了名为JITVUL的基准集，发现ReAct Agent相比纯LLM在漏洞分类上有一定改善，但分析模式在相同代码的漏洞版本和修复版本之间并不一致，因为Agent并没有建立稳定的推理链 [12]。

构想：Harness Engineering驱动的代码审计Agent

基于上述现状和Harness Engineering的核心原则，一个理想的代码审计Agent应该是这样的：

架构设计：多Agent层级协作。参考BlacksmithAI在渗透测试中的多Agent层级设计 [13]，代码审计Agent可以采用类似的Orchestrator-Specialist架构。一个编排器Agent负责任务分解和结果综合，下辖多个专业子Agent：Recon Agent负责代码库结构映射和攻击面分析，Taint Analysis Agent专注数据流追踪，Logic Audit Agent负责业务逻辑审计，Dependency Agent负责供应链安全分析。每个子Agent都有其专属的上下文和工具集，运行在HumanLayer所描述的“上下文防火墙”中，从而确保各自任务在隔离的上下文窗口中执行，中间噪声不会累积到父线程中 [5]。

Harness层的关键设计：

1. 结构化知识库：将目标项目的安全上下文沉淀为Agent可消费的结构化文档：架构图中的信任边界标注、数据流图中的敏感数据路径、历史漏洞库（标注CWE、修复方式、代码位置）等等。遵循OpenAI的做法，核心入口文件（如SECURITY_AUDIT.md）仅作为目录，指向更深层的知识源 [2]。
2. 确定性工具链集成：Agent的分析结论必须能被确定性工具验证。将CodeQL、Semgrep等SAST工具通过MCP协议暴露给Agent，使其能够主动发起扫描、解读结果、并基于结果调整分析策略。这正是IRIS所倡导的“LLM辅助静态分析”范式的工程化落地 [9]。
3. 分阶段渐进分析（Plan-Build-Verify-Fix）：借鉴LangChain的经验 [5]，审计Agent在每个分析阶段必须输出结构化的中间产物（如JSON格式的发现列表），并在进入下一阶段前通过验证检查点。这防止了Agent的典型失败模式：自信地宣称“分析完成”却跳过了关键路径。
4. 反馈驱动的精度提升：参考GitHub Security Lab的Taskflow Agent实践 [10]，当Agent遭遇误报时，将误报模式反馈回Harness，进而扩展prompt或调整活跃人格（active personality），使同类误报在后续审计中被正确标记。这正是Hashimoto所说的“anytime you find an agent makes a mistake, you take the time to engineer a solution such that the agent never makes that mistake again” [1]。
5. 上下文腐烂防御：Dex Horthy的观察表明，上下文窗口填充超过约40%后LLM的推理质量开始下降 [4]。对于需要分析大型代码库的审计Agent，这意味着必须实施增量分析策略：每次会话专注一个模块或一种漏洞类型，完成后将发现持久化到文件系统，为下一个会话提供上下文接力。这与Anthropic在长时间运行Agent中使用结构化进度文件的策略一脉相承 [4][5]。

一个完整的代码审计Agent工作流示意

将以上设计综合起来，一个Harness-Engineered代码审计Agent的工作流大致如下：

如图所示，整个工作流由顶部的Harness层统领。Harness层包含三个核心组件：安全规范与知识索引（SECURITY_AUDIT.md）、确定性工具链（CodeQL / Semgrep / CI）、历史漏洞库，以及一条贯穿始终的约束层（依赖白名单、操作权限、上下文窗口控制在40%以下）。Orchestrator Agent接收任务后，将其分解并分发至四个专业子Agent，每个子Agent在隔离的上下文窗口中独立工作。四个子Agent的发现汇聚到验证检查点，由SAST工具进行复核、CVE比对和误报过滤。验证未通过的发现会通过左侧的反馈回路返回Orchestrator，驱动Agent自主修复或调整分析策略；验证通过的发现则持久化为JSON格式的结构化审计报告，同时作为下一轮审计会话的上下文接力。

四、Harness Engineering加持下的自动化渗透Agent

如果说代码审计Agent是"白盒"视角的安全守护者，那么自动化渗透Agent就是"黑盒"视角的攻击模拟者。2026年的安全行业正处于一个拐点：Xbow的CISO Nico Waisman在RSAC 2026上指出，从漏洞被发现到被利用之间的时间窗口正在急剧缩短，攻击侧的自动化速度已经超过了防御侧的响应能力 [14]。

现状：当前的自动化渗透Agent生态

2026年初的自动化渗透测试工具已经呈现百花齐放的态势。以BlacksmithAI为代表的开源框架采用层级化多Agent架构，将渗透测试分解为侦察、扫描枚举、漏洞分析、漏洞利用、后渗透等阶段，每个阶段由专门的Agent负责 [13]。PentAGI则内置了20多种专业工具（Nmap、Metasploit、Sqlmap等），配合长期记忆系统和Web搜索集成，实现全自主的渗透测试流程 [15]。在商业领域，Xbow的自主Agent已经登上了HackerOne全球排行榜的顶部 [14]，Simbian推出了首个融合业务上下文的AI渗透测试Agent [16]。

但正如Ostorlab在其8款开源AI渗透工具的对比评测中指出的，当前的核心挑战已不再是发现孤立的漏洞，而是多阶段漏洞的链式利用和后渗透操作 [15]。这恰恰是Harness Engineering最能发挥价值的地方之一。

构想：Harness Engineering驱动的渗透Agent

一个真正成熟的自动化渗透Agent需要解决四个核心问题，而每一个都可以通过Harness Engineering的方法论得到系统性的回答：

问题一：如何维持跨阶段的攻击状态？

渗透测试是一个高度状态化的过程。侦察阶段发现的开放端口信息需要在漏洞扫描阶段被引用，发现的凭据需要在横向移动阶段被使用。当前大多数Agent在单个上下文窗口内工作良好，但跨阶段的状态传递极为脆弱。

Harness方案：采用Anthropic提出的结构化进度文件模式 [20]，在每个阶段结束时将发现持久化为结构化数据（JSON而非Markdown，因为Agent更不容易错误地编辑或覆盖结构化数据 [20]）。例如，侦察阶段的输出是一个结构化的攻击面模型，包含所有发现的服务、版本、潜在入口点；每个后续阶段的Agent在启动时读取这份状态交接文件，就像是渗透测试团队的班次交接。

问题二：如何实现智能化的漏洞链式利用？

单一漏洞往往不足以造成实质性影响。真正有价值的渗透测试在于将多个低危漏洞串联为一条高危攻击链。这需要Agent具备系统性的攻击推理能力。

Harness方案：构建一个"攻击知识图谱"作为Agent的上下文工程核心组件。图谱中编码了常见的漏洞链模式（如SSRF → 内部服务访问 → 配置文件读取 → 凭据获取 → 权限提升）、各类漏洞的前置条件和可达性关系。Agent在发现单个漏洞后，可查询图谱获取可能的链式利用路径，然后逐步验证。这与LangChain的Trace Analyzer Skill思路一致 [4]：并行启动多个分析Agent，各自从不同角度评估漏洞组合的可行性，最终由主Agent综合判断。

问题三：如何确保渗透测试的安全边界？

自动化渗透Agent的最大风险是失控，即在真实环境中误删数据、触发告警、或造成服务中断。Simbian的做法是提供完整的推理轨迹（Transparency by Design），并内置“安全模式”防止对生产环境造成破坏 [16]。

Harness方案：这是Harness中“Constrain”层的核心应用场景。具体包括：通过沙箱环境隔离所有攻击操作（Zen-AI-Pentest已采用容器化沙箱来隔离exploit验证阶段 [17]）；实施严格的操作白名单，即Agent只能执行预定义的工具命令，不能执行任意Shell命令；设置“熔断器”机制，即当Agent检测到目标系统出现异常响应（如大量500错误、服务不可达）时自动暂停并请求人工介入；所有操作完整记录到审计日志中，这不仅是合规需求，也是Agent自我反思和Harness迭代改进的数据基础。

问题四：如何在多次会话间保持攻击连贯性？

大型渗透测试可能持续数天甚至数周。Agent需要在多次会话间保持对整体攻击进展的理解。

Harness方案：建立分层的持久化状态管理。短期状态（当前正在探索的攻击路径）保存在当前会话上下文中；中期状态（已发现的漏洞、已尝试的攻击手法及其结果）保存在结构化进度文件中，每次会话结束时更新；长期状态（目标环境的整体画像、历史攻击经验）保存在向量数据库或知识图谱中。新会话启动时，Agent首先读取中期和长期状态，快速恢复攻击上下文，避免重复劳动。

一个完整的渗透Agent工作流示意

将以上设计综合起来，一个Harness-Engineered渗透Agent的工作流大致如下：

与代码审计Agent的并行分发不同，渗透Agent采用的是阶段式串行推进。这是由渗透测试本身的逻辑决定的：你必须先完成侦察才能有效扫描，必须先发现漏洞才能尝试利用。每个阶段完成后，发现被持久化到结构化进度文件（JSON）中，下一阶段的Agent启动时自动加载前序成果，实现跨阶段的状态交接。Exploit Agent被额外包裹在沙箱环境中运行，这是约束层在高风险操作上的具体体现。右侧的动态调度路径表示Orchestrator可以根据前序阶段的发现实时调整后续策略，例如侦察阶段发现了一个高价值的暴露服务，Orchestrator可以指示Scan Agent优先聚焦该服务，而非按预设顺序逐一扫描。左侧的反馈回路则将整个执行过程中的经验沉淀回Harness层，持续优化攻击知识图谱和操作规范。

五、挑战与展望

尚未解决的问题

• 逻辑漏洞的检测瓶颈。当前的Harness Engineering思路在处理“有明确规则可遵循”的安全问题（如已知CWE模式、依赖漏洞、配置错误）时效果显著。但对于逻辑漏洞，如权限绕过、竞态条件、业务流程缺陷等等，仍高度依赖模型本身的推理能力。即使是最好的Harness，也无法通过确定性规则完全覆盖这类漏洞。RSAC 2026上，XBOW展示的“安全单元测试”概念提供了一个有趣的方向：用户编写具体的测试指令（如以标准用户身份尝试访问/admin路由），Agent使用各种绕过技术专门针对该路径进行测试 [18]。但这仍需要人工定义“要测试什么”，距离全自主的逻辑漏洞发现还有距离。
• 评估与信任问题。Anthropic的研究揭示了一个深层矛盾：模型无法可靠地评估自己的工作 [21]。在安全场景下，这意味着审计Agent报告“未发现漏洞”并不能等同于“不存在漏洞”。如何建立对Agent安全分析结论的信任，是一个需要行业共同解答的开放问题。
• 攻防不对称的加剧。正如Waisman在RSAC 2026上警告的，攻击侧的AI自动化正在加速，从漏洞发现到漏洞利用的时间窗口正在急剧缩短 [14]。防御侧的Harness Engineering需要跑得更快才能保持平衡。

安全Harness的可能演进方向

• 从项目级到生态级。Böckeler提出了一个引人遐想的问题：将来团队是否可以从一组预置的Harness模板中选取，就像今天使用服务模板（Service Templates）一样 [3]？在安全领域，这意味着可能出现“安全Harness市场”：针对不同技术栈（Spring Boot + MySQL、Node.js + MongoDB、Go + gRPC）的预配置安全审计Harness，开箱即用，社区共同维护。
• Harness即安全策略。当安全规则被编码到Harness的确定性层中（Linter规则、CI门禁、架构约束），Harness本身就成为了可版本化、可审计、可共享的安全策略载体。这比传统的安全策略文档更加精确和可执行。
• 攻防对抗的Harness化。最终，安全领域可能出现一种“攻防Harness对抗”的局面：防御方不断优化审计Agent的Harness来提高漏洞检出率，而红队则优化渗透Agent的Harness来提高漏洞利用的成功率和隐蔽性。安全工程师的核心技能将从“能否发现漏洞”转向“能否设计出一个驱动Agent发现漏洞的环境”。

结语

“当Agent犯错时，正确的回应不是换一个模型，而是重新设计它运行的环境”。Harness Engineering的核心哲学在安全领域具有深刻的启示意义。无论是代码审计还是渗透测试，亦或是回到Coding，AI Agent的价值上限不取决于模型本身有多聪明，而取决于我们为它构建的工作环境有多完善。

正如OpenAI团队所总结的：最难的挑战已经从“写代码”转向了“设计环境、反馈回路和控制系统” [2]。在安全领域，这句话或许可以改写为：最难的挑战已经从“发现漏洞”转向了“设计让Agent稳定、可靠、持续发现漏洞的Harness”。

References

[1] Mitchell Hashimoto, "My AI Adoption Journey," mitchellh.com, February 5, 2026. https://mitchellh.com/writing/my-ai-adoption-journey

[2] OpenAI, "Harness engineering: leveraging Codex in an agent-first world," openai.com, February 11, 2026. https://openai.com/index/harness-engineering/

[3] Birgitta Böckeler, "Harness Engineering," martinfowler.com, February 17, 2026. https://martinfowler.com/articles/exploring-gen-ai/harness-engineering.html

[4] 知乎, "Harness Engineering 深度解读：AI Agent 时代的「缰绳与马鞍」," 2026年3月. https://zhuanlan.zhihu.com/p/2016495809307374819

[5] HumanLayer, "Skill Issue: Harness Engineering for Coding Agents," humanlayer.dev, March 2026. https://www.humanlayer.dev/blog/skill-issue-harness-engineering-for-coding-agents

[6] Cassie Kozyrkov, "Harness Engineering: How to Supervise Code You Can't Read," Medium, March 2026. https://kozyrkov.medium.com/harness-engineering-how-to-supervise-code-you-cant-read-71ebd05bfde7

[7] 知乎, "Harness Engineering 技术分享 —— 让 AI Agent 可靠、持续、自主工作的工程体系," 2026年3月. https://zhuanlan.zhihu.com/p/2012192515613279409

[8] Santas Ciavatta et al., "Integration of Large Language Models (LLMs) and Static Analysis for Improving the Efficacy of Security Vulnerability Detection in Source Code," Computers, Materials & Continua, vol. 86, no. 3, January 2026. https://www.techscience.com/cmc/v86n3/65509

[9] Ziyang Li et al., "IRIS: LLM-Assisted Static Analysis for Detecting Security Vulnerabilities," ICLR 2025. https://arxiv.org/abs/2405.17238

[10] GitHub Security Lab, "AI-supported vulnerability triage with the GitHub Security Lab Taskflow Agent," github.blog, January 20, 2026. https://github.blog/security/ai-supported-vulnerability-triage-with-the-github-security-lab-taskflow-agent/

[11] Apiiro, "Apiiro Launches AI-SAST That Detects, Validates and Fixes Code Vulnerabilities with Software Architectural Context from Code-to-Runtime," GlobeNewsWire, December 18, 2025. https://www.globenewswire.com/news-release/2025/12/18/3207774/

[12] Alperen Yildiz et al., "Benchmarking LLMs and LLM-based Agents in Practical Vulnerability Detection," ACL 2025. https://aclanthology.org/2025.acl-long.1490.pdf

[13] Help Net Security, "BlacksmithAI: Open-source AI-powered penetration testing framework," March 2, 2026. https://www.helpnetsecurity.com/2026/03/02/blacksmithai-open-source-ai-powered-penetration-testing-framework/

[14] SiliconANGLE, "Autonomous penetration testing enters chaos phase," March 25, 2026. https://siliconangle.com/2026/03/25/autonomous-penetration-testing-enters-chaos-phase-ai-rewrites-offensive-security-rsac26/

[15] Ostorlab, "8 Open-Source AI Pentest Tools for Security Teams in 2026," January 30, 2026. https://blog.ostorlab.co/8-open-source-ai-pentest-tools-2026.html

[16] Help Net Security, "Simbian AI Pentest Agent delivers continuous, context-aware penetration testing," February 19, 2026. https://www.helpnetsecurity.com/2026/02/19/simbian-ai-pentest-agent/

[17] Help Net Security, "Zen-AI-Pentest: Open-source AI-powered penetration testing framework," February 11, 2026. https://www.helpnetsecurity.com/2026/02/11/zen-ai-pentest-open-source-penetration-testing-framework/

[18] Penligent, "The 2026 Ultimate Guide to AI Penetration Testing: The Era of Agentic Red Teaming," January 2026. https://www.penligent.ai/hackinglabs/the-2026-ultimate-guide-to-ai-penetration-testing-the-era-of-agentic-red-teaming/

[19] 腾讯云开发者社区, "Harness Engineering 是什么？从上下文工程到驾驭工程," 2026年3月. https://cloud.tencent.com/developer/article/2645208

[20] "The Emerging 'Harness Engineering' Playbook," ignorance.ai, February 22, 2026. https://www.ignorance.ai/p/the-emerging-harness-engineering

[21] Epsilla, "The Third Evolution: Why Harness Engineering Replaced Prompting in 2026," epsilla.com, March 2026. https://www.epsilla.com/blogs/harness-engineering-evolution-prompt-context-autonomous-agents

注：本文由 Claude Opus 4.6 辅助撰写 ：）