文章总结： 本文记录作者利用AgentHarness理念，通过OpenClaw平台在飞书群构建6个虚拟SOC角色实现协同安全分析的实践。核心解决飞书机器人无法互相触发、模型不调用工具等协作挑战，采用脚本桥接方案实现自动化事件处理流程，但指出模型工具调用问题仍未根本修复。 综合评分： 75 文章分类： 安全运营,实战经验,AI安全,解决方案,安全建设

天下无贼Ⅲ：用 Agent Harness 构建虚拟 SOC，一个人的安全运营中心

原创

DIMU DIMU

AI简化安全

2026年3月27日 01:42 广东

「天下无贼」系列：探索 AI 智能体在网络安全领域的真实落地实践。

天下无贼1 · 天下无贼2 · 天下无贼3（本文）

从一个问题开始

如果你只有一个人，能不能有一支安全运营团队？

笔者用 Agent Harness 的理念，在飞书群里建起了一支 6 个角色的虚拟 SOC 团队。这篇文章记录整个过程——包括最终效果，也包括一路踩过的坑，和截止目前还没解决的问题。

一、什么是 Agent Harness？

今年 1 月，Philipp Schmid 写了一篇文章，把「Agent Harness」这个概念说得很清楚：

Agent Harness 是包裹在 AI 模型外面的基础设施层，负责管理长时任务、保持可靠性、提供工具和能力调度。

他用了一个类比：

| | | — | | |

| 组件 | 类比 | | — | — | | 模型 | CPU（提供推理能力） | | 上下文窗口 | RAM（有限的工作内存） | | Agent Harness | 操作系统 （调度、工具、生命周期管理） | | Agent | 应用程序（跑在 OS 上的具体任务） |

换句话说：模型是大脑，Harness 是身体+操作系统。

二、已经在用 Harness 了——只是没意识到

今天才发现，我用的 OpenClaw 其实就是一种具体的 Harness 实现：

• • openclaw.json 的 agents.defaults → 底座：统一模型、上下文压缩策略、并发控制
• • 各个 agent workspace → 角色层：每个角色有自己的工具权限、身份配置、技能包
• • 飞书 bindings → 渠道接入层：不同 bot 账号对应不同虚拟角色

这套配置里已经有了：SOC Tier1、SOC Tier2、SOC Tier3、威胁情报、漏洞管理、合规……6 个虚拟安全角色，每个都有自己的飞书机器人账号，在同一个群里。

问题是：它们互相不说话。

三、虚拟 SOC 团队的协作挑战

挑战1：飞书 bot 只响应 @提及

在飞书群里，每个 bot 只有被 @ 到才会响应。我发给 Tier1，Tier1 回复了，但它的回复里没有真正触发 Tier2 的 @ 事件——因为 AI 输出的 @SOC Tier2 只是普通文字，不是飞书的 mention 对象。

解法：建立 bridge.ps1 监听脚本，每 5 秒轮询群消息，检测到 /ir 命令就自动触发完整的编排流程。

挑战2：模型不调用工具

原本的设想：用户发消息给小秘 → 小秘通过 exec 工具调用脚本 → 脚本串联各角色。

现实：无论 Kimi K2.5 还是 MiniMax M2.5，收到任务后都说「立即执行」，但文件从未被创建。

根本原因：OpenClaw 的 messaging profile 没有把 exec 工具作为真正的函数调用（function call）传给模型，而是通过 system prompt 文字描述工具能力——模型只是”知道”有这个工具，但没有被正式调用的能力。

解法：把编排逻辑从模型层下移到基础设施层。脚本直接调 OpenClaw 网关 API 获取各角色的分析，再通过飞书 API 用对应 bot 身份发群消息。

这反而符合 Harness 的设计原则：基础设施操作不应该依赖模型的概率性判断。

挑战3：模型在分析报告里输出工具调用代码

SOC 角色（威胁情报、漏洞管理）在输出安全分析时，反复尝试在回复里写 exec() / <tool_call> / tool_code XML——因为它们从上下文里推断出「应该调用工具」。

解法：在每个角色的提示里加强硬性边界：

[CRITICAL INSTRUCTION] Write a plain text security analysis report in Chinese.
Do NOT output tool calls, exec(), XML, or code of any kind.
FORBIDDEN: <tool>, exec(), function_call, JSON blocks, XML tags.

经过几轮迭代，最终 5/5 角色全部输出干净的专业分析报告。

四、最终实现的效果

架构

飞书群发送：/ir [安全事件描述]
         ↓
bridge.ps1 监听（5秒内触发）
         ↓
call-agent.ps1 → OpenClaw 网关 → Kimi K2.5
         ↓ 串行调用，带完整上下文传递
SOC Tier1 初判
  → SOC Tier2 深度分析
    → 威胁情报 IOC 关联
    → 漏洞管理 漏洞评估
      → SOC Tier3 综合决策
         ↓ 各角色用自己的 bot 身份发群消息

实测效果节选

SOC Tier1 初判（事件定级、攻击链梳理、5条立即行动建议）

SOC Tier2 深度分析（完整攻击链还原表格、三阶段处置方案、升级建议）

威胁情报（IOC 关联、MITRE ATT&CK TTP 映射、APT 归因分析）

漏洞管理（7个漏洞 CVSS 评分、修复优先级时间线、合规风险提示）

SOC Tier3 处置决策（根因分析、8节完整报告、5项需人工确认的决策清单）

五、未解决的问题

坦白说，这次实践有一个核心问题没有彻底解决：

模型不调用工具（exec）这件事，目前靠的是架构绕开，而不是真正修复。

正确的解法应该是：小秘收到安全事件 → 模型识别后调用 exec → 脚本自动运行 → 群里出现各角色分析。

但这需要 OpenClaw 的工具调用在 messaging 渠道里正确传递函数定义，或者找到一个原生支持 exec 工具调用的模型配置。

目前：

• • ✅ 飞书发 /ir → 5 个角色自动协同分析
• • ⚠️ 需要 bridge.ps1 持续在后台运行
• • ❌ 小秘还不能直接调 exec 触发脚本

工具与资源

• • OpenClaw：openclaw.ai（Agent Harness 平台）
• • Agent Harness 2026：philschmid.de/agent-harness-2026
• • Kimi K2.5：platform.moonshot.cn（分析用模型）
• • MiniMax M2.5：platform.minimaxi.com（触发器用模型）

免责声明：

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

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

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

本文转载自：AI简化安全 DIMU DIMU《天下无贼Ⅲ：用 Agent Harness 构建虚拟 SOC，一个人的安全运营中心》