“帮我把这个改动提交到开源仓库。”敲完这一句，你起身去接了杯咖啡。回来时 Agent 已经干完了一切：commit、push、提交成功。屏幕上干干净净，一条黄色警告都没有。几分钟后，平台通知弹了出来：你的 API Key 被一个陌生 IP 调用。时间 15:03，地点：境外。你愣了几秒——你只是提交了次代码，钥匙怎么就到了别人手里？
翻开各处的记录想弄明白发生了什么。Agent 日志里只有一次普通的 Shell 调用；进程记录显示跑的是系统自带的 curl；文件审计写着私钥被读取成功；网络设备上是一次看起来正常的公网连接。每条记录看起来都能解释，可你想问的几个问题，一条都答不上来：
- 是谁读了这把私钥，它发生在哪一次 Agent 任务里？
- 私钥只是被读取，还是已经形成了可疑的外传链路？
- 如果已经下发拦截策略，怎么证明它真的生效了？
我们很熟悉的“Harness”守不住这一层
这一年来，“Harness”这个词已经深入人心。大家都清楚它大致是什么：包在大模型外面的那层脚手架——喂 prompt、解析输出、把工具调用接起来、驱动“思考-行动”的循环。Claude Code 有它的 Harness，DeepSeek 也做了自己的 Harness。可以说，Agent 能不能干活，靠的就是这层应用级的 Harness。
但需要注意一件事：应用级 Harness 只能看见“经过它自己”的东西。它知道 Agent 调了一个名叫 shell 的工具，参数是什么；可当这条 shell 命令真正 fork 出子进程、拉起系统自带的 curl、把 .env 读进内存、朝公网发起一次连接时——这些真实的系统效果发生在操作系统里，早已跑到了应用级 Harness 的视野之外。
受到 Prompt 注入或恶意 Skill 影响的 Agent 更是如此：它既是被约束的对象，又是执行约束的人。让 Agent 自己的 Harness 来保证 Agent 不越界，信任关系本身就不成立。
所以我们需要在另一层再套一层 Harness——不是包在模型外面，而是包在操作系统这一侧。我们把它叫做 OS Harness。
Agent Harness 负责让 Agent 把活干成；OS Harness 负责在操作系统这一层，替你盯住它到底做了什么、并在越界时兜底拦住。
OS Harness 有三个应用级 Harness 给不了的特性：
1、路径无关：它约束的是真实的文件、进程、网络操作，而不是某个工具入口。Agent 换用 SDK、直连 Shell、绕到子进程里去做，都躲不过。
2、不可绕过：策略由 Agent 之外的可信组件执行，Agent 只能"请求"操作，不能自行决定跳过检查或伪造成功。
3、效果前阻断：在删除、外发、连接真正发生之前同步 Allow / Deny，而不是事后在日志里发现。
ANOLISA 是专为 AI Agent 设计的操作系统，AgentSight 是其中负责可观测的组件——它承担的是 OS Harness 中最贴近系统的那一块：从系统层面零侵入地观测你启动的 Agent 的进程、文件与网络行为，越界时既能审计也能拦截。它是这道护栏的一部分，而不是护栏本身。代码已开源（复制链接至浏览器打开）：https://github.com/alibaba/anolisa（src/agentsight/）。
更棘手的是，Agent 可能接触的不只是 SSH 私钥。模型 API Key、云凭据和集群 Token，都可能出现在它完成任务的路径上。凭据一旦离开控制边界，结果可能是陌生调用、异常登录，甚至生产环境被接管。
本文就从其中最直观的一条风险链路开始：同一棵 Agent 进程树读取了 SSH 私钥，4 秒后又连接了一个不在可信列表中的公网目标。这里说的“外泄风险”，指的是这条行为链已经具备了往外传的条件，并不代表私钥内容真的发出去了；但它已经值得你停下来查一查，也值得系统卡一道出口。
为什么当时没有任何人察觉
不是没有记录，而是记录被切碎，散在了不同系统里。文件审计那边看到敏感路径被读，进程监控那边看到 Shell 和 curl，网络设备那边看到一次指向陌生公网的连接。各看各的，每一条都合情合理。
文件审计看见敏感路径被读取，进程监控看见 Shell 和 curl，网络设备看见一次指向不可信公网目标的连接；单独看，每个动作都有合理解释。
还有一层原因：Agent 本来就该在那儿。它是你亲手启动的，用的是完成任务所需的正常权限，调的也是系统里现成的工具。只有把这些动作重新放回同一次任务、同一棵进程树、彼此相隔几秒的时间线上，风险才显出形状。
每条日志都没错，但没人看见全貌。这恰恰是应用级 Harness 视野之外、需要 AgentSight 来补的那一块。
AgentSight 怎么找到这条链
看到“读私钥”这个动作，AgentSight 没有急着下结论说凭据泄了，也没有一刀切把 Agent 的公网访问全禁掉。它先问一个更基本的问题：这些动作，是不是出自同一次 Agent 执行？
系统会把 Agent、会话、工具调用和进程树关联起来。任务中间就算绕过 Shell、curl 或别的子进程，它也能顺着同一棵进程树一路跟下去。
一旦确认属于同一次任务，“这次任务碰过敏感凭据”这件事就会被后面的每一步继续带着走，哪怕中间隔了好几层子进程也不会断。整个过程里，AgentSight 不去读私钥正文，也不管文件里装的到底是什么，它只盯着一件事：碰过之后又干了什么。
于是，原本散落在不同系统里的几条记录被还原成了一条连续行为：Agent 任务打开敏感路径，这次接触被后续操作持续携带，子进程连接了不可信公网目标。
单独看，每一步都可能正常；连续看，它值得被调查。
但“值得调查”不能只停留在一条告警上。用户需要一个明确入口，继续回答前面的问题：是谁做的、发生在哪次任务里、敏感接触如何被后续动作携带，以及是否需要立即拦截。AgentSight 会把这段连续行为整理成一条待研判的风险案件，调查就从这里开始。
先开启保护，再等风险浮现
在 AgentSight 的 Agent 看板，每个正在运行的 Agent 旁边都有一键开启保护的入口。
用户指定保护目录、敏感文件路径（如 .env、~/.ssh/id_rsa），以及可信网络目标（可选），点击“开启审计保护”即可生效。
默认使用审计模式——不会阻断 Agent 任务，也不读取文件内容，只是持续跟踪进程树对敏感文件的访问和后续网络外发行为。一旦形成可疑链路，系统自动生成风险案件，看板上的红色“待研判”徽标第一时间提醒。
点击看板上的“查看案件”，直接进入系统审计页面的“风险研判”标签，已经按该 Agent 过滤好了案件列表。
从一条风险案件开始，把事情讲清楚
进入 AgentSight 可视化面板的“系统审计”标签页，默认打开的是“风险研判”标签。用户首先看到的是执行器状态、生效策略数、审计违规和待研判案件数等概览信息，而不是一串需要自己拼接的内核日志。
点开“凭据衍生数据访问了不可信网络目标”案件，页面会把与这次任务有关的事实按时间排开：谁发起了任务、哪棵进程树打开了敏感路径、这次接触又是如何被后续动作携带的、随后连接了哪里、当时运行的是哪版策略，以及最终的执行结果是什么。
这一步解决用户最迫切的两个问题：
1.从哪里来的？ 回到具体 Agent、会话和进程树。
2.为什么被判为风险？ 查看敏感读取与不可信公网连接之间的连续关系。
原始事件各自保留；采集过程中出现缺口时，页面会明确显示证据不完整，而不是用一个风险分替代事实。
AgentSight 此时能确认的是：同一次刚刚接触过敏感凭据的任务，随后访问了不可信公网目标。这构成一条需要调查和约束的外泄风险链路，但不能单独证明私钥内容已经被发送，因为系统不读取文件正文和网络明文。
从研判到策略：同一页内切换
我们为这个页面做了两个标签：“风险研判”回答“发生了什么”，“防护策略”回答“做了什么约束”。两者是同一条风险链的上下半场。
当完成案件研判后，用户想检查正在生效的策略是否已经覆盖这个场景，或者需要调整为更强的模式。此时不需要离开当前页面：点击案件详情中的“查看关联策略”，页面会直接切换到“防护策略”标签，并高亮当前案件关联的策略绑定。
反过来也一样：在“防护策略”标签下，看到某条策略绑定发生了一次违规，想看事件的来龙去脉，点击“查看关联案件”即可切回“风险研判”标签。
渐进式拦截：从审计到拦截的三个等级
AgentSight 的策略不是“要么全放，要么全封”。系统提供三个渐进式保护等级：
观察模式（Observe）：在日志中记录事件，不干预 Agent 运行。适用于初次开启保护后，先观察一段时间确认策略不会误伤正常工作。
审计模式（Audit）：当触发条件满足时，不阻断进程，但立即生成待研判案件并发送通知。这也是一键开启保护的默认模式。
拦截模式（Block）：直接终止子进程的网络连接。Agent 会看到连接被拒绝（connection refused），无法完成外发。适用于确认策略边界后，对关键场景实施硬性保护。
实际用起来，路径通常是这样：一键开保护先默认审计，观察一阵确认没误伤；再到“防护策略”标签，按观察到的结果把某几条升成拦截；万一发现误伤，随时退回审计或观察。每一步都能反悔，不用被逼着在“全放开”和“全封死”之间二选一。
拦截生效后，为什么能确认它起作用了
下发拦截策略后，怎么确认它真的在工作？
在“防护策略”标签中，每条策略绑定会显示两个维度的信息：
- 状态指示：当前绑定是否生效（Active / Inactive / Error）
- 违规记录：这条绑定过去拦截了多少次、审计了多少次，最后一次触发是什么时间
如果策略设为拦截模式，并且发生了一次触发：用户会看到绑定的违规计数增加，时间更新，以及系统审计侧一条新的风险案件（可通过“查看关联案件”切过去确认）。这可以知道：策略确实已经拦截了那次外发。
审计模式的判断类似：策略状态“Active” + 计数增加 + 研判侧有对应案件，证明行为已被记录（虽未阻断）。
AgentSight 把“拦截是否生效”拆成三个可以核对的事实：策略要求拒绝（想拦）→ 策略已安装并生效（准备好了）→ 匹配的连接再次发生时真实返回拒绝（真的拦住）。只有三者同时成立，才标“已阻断”。系统不会把一次“可能成功”显示为确定结论。
安全界面上一盏提前亮起的绿灯，往往比没有告警更危险。
完整路径：从开启保护到拦截生效
回看整个流程，它形成了一个闭环：
整个过程中，用户不需要在多个系统之间切换，也不需要拼接日志。每一步操作和它的下一步之间都有明确的入口。
解决什么，不能解决什么
这次版本聚焦一类明确风险：同一棵进程树接触敏感凭据后，又尝试连接不可信的公网目标。作为 OS Harness 的重要部分，AgentSight 可以发现并约束这条链路，但不会仅凭这两个动作就宣布“凭据已经泄漏”。
- 当前版本运行于 Linux 内核之上，要求版本 5.10 及以上，并启用 BTF 与 BPF-LSM ，具体环境要求见项目文档（复制链接至浏览器打开）：https://github.com/alibaba/anolisa/blob/main/docs/user-guide/zh/installation.md。
- 系统不读取文件正文、凭据内容、请求头或 TLS 明文。
- 探针或策略安装失败时，预览版默认放行，同时明确记录防护缺口。
边界越清楚，页面上的“已经阻断”才越可信。
下一步：让 Agent Harness 与 OS Harness 对上话
回到 OS Harness 这道护栏本身。当前 AgentSight 已经把其中“系统层的观测与执行”这块做了出来：发生了什么、策略有没有落地、最终是否真的拒绝，都能在系统层给出可核对的事实。但这只是护栏的一部分。
下一步，ANOLISA 会补齐 OS Harness 的其余环节,让这道护栏更完整：由 AgentSecCore 根据 Agent、任务、工具和工作区的上下文理解“用户想干什么、该给什么授权”并表达安全策略，AgentSight 再把这些策略落实到具体的系统执行点，并用真实的系统结果证明约束是否生效。两者接起来，“用户意图 → 策略执行 → 系统结果”才形成完整闭环。
入群交流
欢迎加入ANOLISA 钉钉交流群（群号：90400034325）交流。
—— 完 ——
ANOLISA：Agent 系统管家，致力于打造更高效更安全的 Agent Native 环境。我们正在进入新的智能操作系统范式 Agentic OS 时代，而 ANOLISA 是落地新范式的入口，是传统操作系统上叠加的一层转换层，能更好地支持 Agent 使用操作系统，并且使 Agent 获得更好的性能。我们通过 ANOLISA 重新定义了操作系统，为您带来完整的 Agentic OS 体验。用 ANOLISA，构建你的 Agentic OS！
- 开源使用（如果喜欢这个项目，请点 Star ⭐支持。复制链接至浏览器打开）：
https://github.com/alibaba/anolisa/blob/main/README.md - 阿里云产品上使用（复制链接至浏览器打开）：
https://help.aliyun.com/zh/alinux/agentic-os-getting-started
注：ANOLISA 音译为“安诺丽萨（拼音Ān Nuò Lì Sà），系 Agentic Nexus Operating Layer & Interface System Architecture 的缩写。
