cn0xroot/ArgusBPF

来源：https://github.com/cn0xroot/ArgusBPF

ArgusBPF

中文说明

看清楚你的操作系统——以及运行在它上面的每一个 AI 编码 agent——到底在做什么：通过 eBPF 实现，用大白话解释，而不是堆砌 syscall 术语。

名字取自希腊神话中的“百眼巨人“Argus（阿尔戈斯）：这个工具所做的正是如此——直接挂接到内核（eBPF），同时还能识别出它所监视的活动是否专门属于某个 AI agent CLI。

ArgusBPF 是一个单一的 Go 二进制文件。在以 root 运行的 Linux/amd64 上，它通过 eBPF 直接挂接内核（CO-RE，运行时无需内核头文件）；在其他情况下（其他操作系统、其他架构、非 root），它会自动回退到基于 gopsutil（https://github.com/shirou/gopsutil）构建的跨平台轮询采集器。

Web UI 支持在 专业模式（syscall 格式、内存地址、扇区号、原始字段）和 大白话模式（用日常语言和类比解释同样的事件）之间切换。这与 CC-Monitor（https://github.com/）等工具的理念相同——它们监视 AI 编码 agent 对你的机器做了什么——只是把这一思路应用到了操作系统本身，并扩展到可以识别具体是哪个 AI agent CLI 在操作。

截图

概览

概览

AI 活动

AI 活动

实时事件

实时事件

时间线

时间线

网络

网络

磁盘

磁盘

内存

内存

进程

进程

告警

告警

术语表

术语表

设计

• 单一内核侧调度器，而非逐进程 ptrace。 一个 CO-RE 程序（bpf/monitor.c）挂接到 raw_syscalls/sys_enter 以及 module_load/block_rq_issue 跟踪点，覆盖全系统所有进程，避免了 ptrace 逐进程附加的开销，并且无需重新编译即可跨内核版本工作（运行时无需内核头文件）。
• 按进程身份识别 AI agent。 10 个主流 AI 编码 agent CLI 会与内置表进行匹配；被识别的事件带有 agent 字段、在实时流中显示徽标，并拥有专属的时间线泳道，让你能看清某个 agent 到底动了什么。
• TLS/DNS/SQL 明文捕获。 采用 eCapture 式的 uprobe，对 SSL_read/SSL_write/getaddrinfo/exec_simple_query 进行探测，在目标进程自身的内存中恢复明文（加密前/加密后），无需 MITM 代理或证书处理。
• 每个事件两种呈现。 每个事件都有真实的 syscall 格式专业渲染，以及单独生成的大白话解释和日常类比，由离线模板/查找引擎生成（不调用 LLM，完全确定性，完全离线也能工作）。
• 单一二进制，跨平台。 纯 Go 实现，任何地方都不使用 CGO（SQLite 亦然）。root + Linux/amd64 获得完整的 eBPF 管线；任何其他操作系统、架构或非 root 环境则回退到基于 gopsutil 的轮询器。

特性

• AI agent 识别 — 每个事件的进程都会与主流 AI 编码 agent CLI 对照表进行检查（Claude Code、Codex、Cursor、Gemini CLI、Grok CLI、Aider、OpenCode、ZCode、OpenClacky、Antigravity CLI——与 CC-Monitor 开发分支追踪的名单一致）；匹配的事件带有 agent/agent_display 字段、在实时流中显示 🤖 徽标，时间线页面还有专门的“按 AI agent“泳道，让你能看到某个 agent 具体动了什么，与机器上运行的其他一切分开呈现。
• 实时事件流 — 每次 exec、文件打开/写入/删除/重命名、网络连接/监听、mmap/mprotect/ptrace/跨进程内存访问、内核模块加载以及块设备 IO，均通过 WebSocket 推送。
• 风险规则 — 一个小型 JSON 规则集（可编辑、可被用户覆盖），标记读取 /etc/shadow、W+X 内存页、ptrace attach、跨进程内存写入、内核模块加载、SSH 活动等行为，分为 info/low/medium/high 四级。
• 大白话解释 — 每个事件都同时拥有技术单行描述（mprotect(addr=0x7f.., prot=RWX)）和通俗易懂的英文解释与日常类比，由离线模板/查找引擎生成（不调用 LLM，完全确定性）。
• eCapture 式应用探针 — 对 getaddrinfo（DNS）、OpenSSL SSL_read/SSL_write（TLS 明文）和 Postgres exec_simple_query（SQL 文本）进行尽力而为的 uprobe 探测，当目标库/二进制存在时自动挂接；如果不存在，每项都会优雅降级（并在 /api/info 中说明）。
• 完整的 Web 仪表盘 — 概览页含实时 CPU/内存/磁盘/网络图表、实时事件表格、泳道时间线（按类别、按进程或按 AI agent）、网络连接、磁盘 IO（含扇区级散点图）、逐进程内存映射（/proc//maps 可视化并逐区域解释）、进程树、告警视图以及术语表——风格类似 Grafana（深色面板网格、图例、时间范围选择器），但完全自包含，无需安装 Grafana。
• 跨平台设计 — 纯 Go，无 CGO（SQLite 通过 modernc.org/sqlite）。可为 darwin/windows/linux 的 amd64/arm64 构建；只有 eBPF 采集器是 linux/amd64 专属，其余功能处处可运行。
• 可选的 PTY Web 终端（--enable-terminal，默认关闭）— 在仪表盘中直接打开一个真正的终端，在其中运行任何东西（AI agent CLI、shell），支持多个并发会话和网格视图同时观察多个终端。这与本工具其余的只读性质是真正不同的信任模型——它可以启动并驱动真实进程——这也是它需要显式 flag 开启、而非仅由仪表盘 UI 控制的原因。如果你开启它，请同时设置 --token，并保持 --listen 绑定在 localhost（默认）或你自己的反向代理上——任何能访问该端口的人都可以打开一个 shell。
• 面向 AI 客户端的 MCP 服务器（--mcp）— 运行 argusbpf --mcp 作为 Model Context Protocol（https://modelcontextprotocol.io/）的 stdio 服务器，让 AI 助手（Claude Code、Claude Desktop、任何 MCP 客户端）可以直接查询这台机器：hardware_info（CPU/内存/磁盘/主机）、busybox_applets（BusyBox 实际提供了什么，在 /bin 大多是同一个 BusyBox 二进制的嵌入式/车载镜像中尤其有用）、recent_events 和 event_stats（与仪表盘展示的捕获活动相同，可按类别/风险/agent/时间窗口过滤）。它以只读方式读取仪表盘自身的 SQLite 数据库，因此无需 root、无需开放端口、也无需 --token——参见下文使用 MCP 服务器。

支持的 AI agent CLI

识别依据是进程 comm/exe 身份（见 internal/agents），与 CC-Monitor 开发分支追踪的名单一致。可在 API/UI 中通过 ?agent= 过滤上述任意一个，也可以在时间线的“按 AI agent“泳道中查看。

新增 agent 只需在 internal/agents/agents.go 中加一行——欢迎为缺失的项目提交 PR。

快速开始

# 构建（无需 clang/bpftool——eBPF 对象已预编译并随仓库提供）
make build

# 以 root 运行以启用 eBPF 采集器；非 root 会自动回退到轮询模式
sudo ./argusbpf

# 打开仪表盘
open http://127.0.0.1:1024

常用参数：

使用 MCP 服务器

argusbpf --mcp 作为独立的 MCP（https://modelcontextprotocol.io/）stdio 服务器运行，取代仪表盘——它读取仪表盘所写入的同一个 SQLite 数据库（若使用非默认路径则为 --db），并暴露四个工具：hardware_info、busybox_applets、recent_events、event_stats。它不需要 root、不开放网络端口、也不需要 --token——客户端会按协议标准的 stdio 传输方式将其作为短生命周期子进程启动。

对于 Claude Code，可以这样添加：

claude mcp add argusbpf -- /usr/local/bin/argusbpf --mcp

或者直接配置（Claude Code 的 .mcp.json、Claude Desktop 的 claude_desktop_config.json，或任何其他 MCP 客户端）：

{
  "mcpServers": {
    "argusbpf": {
      "command": "/usr/local/bin/argusbpf",
      "args": ["--mcp"]
    }
  }
}

如果仪表盘使用了非默认的 --db 路径，请在此传入相同的路径（"args": ["--mcp", "--db", "/path/to/events.db"]），以便 MCP 服务器读取正确的文件。hardware_info/busybox_applets 不需要仪表盘正在运行（它们直接读取运行中的机器）；recent_events/event_stats 则需要数据库已经存在，也就是说仪表盘至少需要运行过一次。

从源码构建 eBPF 程序

仓库中已提交预编译的 internal/collector/monitor_x86_bpfel.o，因此 make build 从不需要 clang。如果你修改了 bpf/monitor.c：

make vmlinux  # 将当前内核的 BTF 导出到 bpf/vmlinux.h（需要 bpftool）
make bpf      # 重新编译 monitor.c -> .o/.go 文件对（需要 clang、llvm-strip）
make build

架构

完整设计参见 DESIGN.md：事件模型、采集管线、风险规则、大白话/专业解释引擎，以及 web/ 所使用的 HTTP/WebSocket API 契约。

发布历史参见 CHANGELOG.md。

collector (eBPF | poller) -> pipeline (rules + explain + 1s aggregation) -> SQLite + WebSocket hub -> web UI

平台支持

已知局限

• 尚未实现 MySQL 的 dispatch_command SQL 捕获——其参数布局随版本变化过大，无法安全发布；Postgres（exec_simple_query，稳定的单个 char* 签名）已支持。
• 尚无 bash readline 命令审计 uprobe。
• 入站连接（accept）未被 eBPF 路径单独捕获；磁盘页面的“IO 最高的文件“目前还没有数据来源（仅有逐进程 IO 和扇区散点图）。
• 发行版打包的 Postgres 二进制通常经过 LTO 构建并去除了符号，因此 exec_simple_query 无法按名称挂接；install.sh 的 uprobe 逻辑会在已安装匹配的 -dbgsym 调试包时回退到解析其地址，而在没有调试包的情况下该能力就完全不可用了。

ferstar (@ferstar_org)： 天天在终端里跑 Claude Code、Cursor、Codex，大家心里其实都有个犯嘀咕的事：

Agent 本质上就是你机子上的一个普通子进程。你的终端有什么权限它就有什么权限。读写当前代码正常，但如果它随手读一下 ~/.ssh/id_rsa、扫一眼 ~/.aws/credentials，或者翻翻隔壁商业项目，操作系统根本不会有任何拦截。