当我们让一个 AI Agent 完成任务时，通常通过两种方式判断它是否可靠：一是检查最终结果是否正确，二是查看 Agent 的执行日志，确认它调用了哪些工具、执行了哪些操作。

但这里存在一个容易被忽视的问题：Agent 的执行日志，真的能够完整反映它做过的事情吗？

假设我们让一个编程 Agent 修复代码中的 Bug。Agent 最终成功修改了代码，所有测试全部通过，执行日志也没有出现明显异常。然而，在完成任务的过程中，它调用了一个辅助脚本，而这个脚本又在后台读取了 SSH 私钥，并尝试向外部服务器发送数据。

从最终结果看，Agent 完成了任务；从执行日志看，Agent 也只是运行了一个脚本。至于脚本内部究竟执行了哪些命令、读取了哪些文件、连接了哪些服务器，传统的 Agent 执行轨迹未必能够完整呈现。

这个问题在 Agent 逐渐获得文件系统、命令行、网络访问乃至企业业务系统操作权限的背景下，变得越来越重要。

2026 年 10 月，瑞士圣加仑大学等机构的研究人员发表了论文《AgentSpy: Making AI Agent Behavior Observable》，提出了一种从操作系统层面观察 Agent 真实执行行为的方法。

https://arxiv.org/pdf/2610.06001

与传统方法不同，AgentSpy 不依赖 Agent 自己提供的执行记录，而是在独立的运行环境中监测它及其子进程产生的系统调用和网络活动。

研究团队进一步证明，即使 Agent 已经通过全部任务测试，仍然可能执行与任务无关的操作、忽略开发者提供的 Skill 指导，甚至在执行过程中触发未经授权的系统行为。

这项研究最值得关注的地方，并不是提出了某种全新的安全检测算法，而是将 Agent 安全评测的关注点从最终结果进一步扩展到了真实执行过程。

一个 Agent 能够正确完成任务，并不代表它完成任务的方式就是可靠和安全的。

为什么 Agent 的执行轨迹还不够？

当前主流 Agent 框架通常会记录执行轨迹（Trajectory），包括模型的推理过程、工具调用以及工具返回结果。这些信息对于理解 Agent 的任务规划与执行过程具有重要价值，也是目前大量 Agent 安全评测和异常诊断系统的分析基础。

但执行轨迹存在一个天然限制：它的最小观察单位通常是一次工具调用。

例如 Agent 执行了一条 python process_data.py 命令，执行轨迹可以记录命令本身、运行结果和返回信息，却不一定能够展示 Python 脚本内部启动的全部子进程、访问的文件和网络连接。

如果脚本继续调用其他程序，甚至运行下载的第三方代码，这些间接产生的行为就可能超出原始执行轨迹的记录范围。

另外，执行轨迹是由 Agent 框架提供的。虽然大多数情况下它能够真实记录工具交互，但其完整性仍然依赖框架的记录机制。对于无法获取完整推理过程的模型，或者嵌套调用较多的复杂任务，开发者能够看到的信息还会进一步减少。

研究人员认为，仅依靠这些记录分析 Agent 行为存在两个局限。

首先，最终结果测试只能判断任务有没有完成，无法验证 Agent 是否采用了开发者预期的执行方式。例如，开发者要求 Agent 使用某个特定的验证流程，但 Agent 可能绕过流程，通过其他途径得到正确答案。

其次，执行轨迹无法保证覆盖工具调用背后发生的所有底层操作。当第三方 Skill、辅助脚本或者受攻击者控制的代码参与执行时，这个问题尤其明显。

因此，AgentSpy 提出了一种不同的观察思路：既然 Agent 最终需要通过操作系统执行命令、读写文件和访问网络，那么就直接从操作系统这一层收集行为证据。

这种方法与 Agent 采用什么模型、如何组织 Prompt、是否开放推理过程没有直接关系。只要相关行为发生在受监测的操作系统边界内，就能够通过系统级监测机制捕获相应事件。

需要强调的是，这种完整性是相对于被监测的系统边界而言的，并不意味着能够理解 Agent 的所有意图，或者观察远程服务内部的全部操作。

AgentSpy 如何观察 Agent 的真实行为？

AgentSpy 的整体架构可以分为三个部分：执行编排器（Orchestrator）、执行管理器（Execution Manager）和分析执行器（Analysis Runner）。

首先，编排器接收 Agent 需要完成的任务、模型配置以及分析类型，并创建一个独立的执行环境。研究团队使用 Firecracker microVM 实现环境隔离，每次运行都从预先构建的文件系统镜像启动，以尽可能保证不同实验拥有一致的初始条件。

这里有一个值得注意的设计，叫作 Execution Kind，可以理解为一套声明式执行配置。它负责定义运行环境、网络设置、用户权限、模型参数以及需要启用的监测组件。针对不同类型的任务，开发者可以在基础配置之上扩展专门的执行环境。

随后，执行管理器在隔离环境中启动 Agent，安装任务依赖，执行任务，并收集执行过程中产生的监测数据。即使 Agent 执行失败或者超时，系统也会尽可能保留已经产生的执行证据。

最后，分析执行器读取这些数据，执行相应的行为分析并生成报告。

在具体实现上，研究团队并没有重新开发一套底层监控系统，而是组合了多个已经相对成熟的系统安全工具。

针对可靠性分析，AgentSpy 使用 auditd 收集系统调用，通过 laurel 将日志转化为结构化数据，并使用 Zeek 补充网络流量信息。

针对安全性分析，则使用基于 eBPF 的 Falco，根据预先定义的安全规则检查系统调用。

这两套机制最终服务于两个不同的研究目标：一套分析 Agent 是否按照预期工作，另一套检查 Agent 是否执行了不允许的操作。

论文将它们分别称为符合性分析（Conformance Analysis）和安全性分析（Safety Analysis）。

两者的区别可以简单理解为：

符合性分析关注 Agent 应该做什么，安全性分析关注 Agent 绝对不能做什么。

例如，要求 Agent 在提交代码之前运行测试，属于前者；禁止 Agent 读取 SSH 私钥并向未知服务器发送数据，则属于后者。

这两类约束无法互相替代。一个 Agent 可能没有违反任何明确的安全禁令，却没有遵循开发者要求的执行流程；也可能完整执行了某个 Skill 中的步骤，但这个 Skill 本身已经被恶意修改。

这也是 AgentSpy 同时研究可靠性与安全性的原因。

将 Agent 的执行过程变成可比较的行为指纹

面对大量系统调用日志，如何判断一次 Agent 执行是否正常？

AgentSpy 并没有直接将原始日志交给大模型分析，而是设计了一种相对简单的结构化表示方法：星型图（Star Graph）。

一张星型图代表一次完整的 Agent 执行。图的中心节点是这次任务运行，外围节点则对应 Agent 使用的环境资源，主要包括三类：执行过的命令、读取或写入的文件，以及访问过的网络主机。

中心节点与资源节点之间的连线记录操作类型和发生次数。

例如，一个负责检查论文引用的 Agent，可能调用 Python 脚本解析参考文献，读取本地 BibTeX 文件，再通过 Crossref 等外部数据库验证引用信息。

在 AgentSpy 的行为图中，这些操作都会转化为相应的资源节点。

如果 Agent 运行了五次 Python，就会在对应命令的连接上记录五次调用；如果它访问了多个网络主机，也会分别记录每个目标主机及其访问次数。

这种表示方式的优势在于，不同执行过程可以使用统一结构进行比较。即使两次运行中进程 ID 不同，或者内部创建了不同的子进程，最终仍然可以按照命令、文件和网络资源进行对齐。

为了量化这种差异，研究人员使用了加权 Jaccard 相似度。

具体来说，AgentSpy 首先统计每类资源的调用次数，再将其归一化为资源使用比例，最后计算两次运行之间的相似度。命令、文件和网络主机分别计算，再进行平均。

这里的关键是比较资源使用比例，而不只是绝对次数。

假设某次执行访问 Crossref 10 次、OpenAlex 2 次，而另一次执行分别访问 20 次和 4 次。虽然调用次数翻倍，但两次执行的网络资源使用比例完全相同，因此主机维度的相似度仍然为 1。

研究者还设计了一个 Skill Coverage 指标，衡量 Agent 在执行过程中实际访问了多少 Skill 文件。

例如，一个 Skill 包含 14 个文件，而 Agent 只读取了 SKILL.md，对应的文件覆盖率就是 1/14，约为 7.1%。

这能够帮助开发者发现某些值得调查的行为：Agent 虽然加载了 Skill，却没有使用其中的辅助脚本、验证程序或参考资料。

不过，需要注意的是，行为相似度并不等于行为正确率，Skill Coverage 也不能直接理解为 Skill 指令遵循率。

某些任务本来就存在多种合理解法，Agent 不一定需要访问 Skill 中的所有文件。因此，这两个指标主要用于发现行为差异和辅助定位问题，最终仍然需要结合任务要求理解其含义。

实验结果

为了验证 AgentSpy 能否有效分析 Agent 的执行行为，研究人员首先使用 SkillsBench 基准开展实验。

SkillsBench 包含软件工程、数学、网络安全和内容生产等不同领域的任务，每个任务提供相应的 Skill、测试程序和参考解决方案。

研究从原有 87 个任务中排除了 10 个无法在实验环境中复现的任务，最终选取 77 个任务进行可靠性分析。

实验统一采用 Codex Agent 框架，分别测试三个模型，并让每个任务重复执行三次，以观察 Agent 行为的非确定性。

1. 同一个任务，Agent 的执行方式有多稳定？

研究人员首先构建两类执行组合：一类包含同一任务的三次运行，另一类则混入不同任务的运行。

如果行为画像确实具有区分能力，那么同一任务的执行结果应该比不同任务的执行结果更加相似。

实验结果支持了这一判断。

在 gpt-5.6-terra 模型上，同一任务运行组合的平均相似度为 0.60，而混入不同任务执行后的平均相似度下降到约 0.30。

综合三个模型，在 92.2% 的相关比较中，同一任务重复运行的行为相似度高于混合任务组合。

这说明仅仅通过系统级资源使用情况，就可以在一定程度上区分不同任务的执行行为。

但这一结果并不等于 AgentSpy 具有 92.2% 的异常检测准确率。实验为了构建明显不同的任务组合，选择了 Skill 文档语义差异最大的任务作为对照，因此更准确的结论是：系统级行为画像具备区分不同执行模式的能力，而不是已经能够准确区分正常行为与恶意行为。

2. 全部通过测试的任务，还有多少隐藏问题？

接下来，研究人员将重点放在那些已经成功完成任务的 Agent 身上。

在全部实验中，共有 88 个任务—模型组合满足三次运行全部通过测试的条件，对应 264 次成功执行。

研究者进一步检查这些执行的系统级行为报告，结果发现：

这里的统计单位是任务—模型组合，只要三次运行中有一次出现相关行为，就计入对应类别，而且不同类别之间可能存在重叠。

这些现象值得分别讨论。

首先，18.2% 的组合存在任务无关活动，包括探索不必要的目录、访问任务没有要求的网络服务，以及读取评测文件。这些活动不一定都属于恶意行为，但至少说明 Agent 的实际行动可能超出开发者原本设定的任务范围。

其次，有 6 个组合出现了访问评测测试文件的情况。部分 Agent 甚至直接使用基准提供的确定性参考程序获得结果，而不是独立完成任务。这会影响评测结果的解释，因为模型通过测试，并不一定意味着它依靠自身能力完成了预期的推理和操作。

最后，17.0% 的组合存在没有充分使用开发者 Skill 指导的情况。

论文中的一个案例非常典型。研究人员要求 Agent 检查一份包含真实与伪造引用的 BibTeX 文件，提供的 Skill 中包含完整的文献验证方法和辅助脚本。

Agent 最终正确找出了伪造引用，并通过全部九项测试，但执行过程中没有完整遵循 Skill 提供的验证流程。它自行调用外部数据库，根据 DOI 和标题匹配结果做出判断，甚至在部分步骤失败后仍然得出了正确答案。

从最终测试看，这个 Agent 没有任何问题。

但从执行过程看，开发者实际上无法确认它是否采用了预期的验证方法，也无法保证这种替代方法在其他数据上仍然可靠。

这组实验揭示了一个重要问题：传统 Agent Benchmark 主要验证最终结果，而真实业务系统往往还关心执行过程是否满足要求。

对于企业 Agent 来说，完成任务只是基本要求。Agent 是否访问了不必要的数据、是否调用了未经授权的服务、是否遵循了指定流程，同样会影响它能否真正进入生产环境。

AgentSpy 能否发现隐藏在 Skill 中的攻击？

除了可靠性分析，论文还设计了专门的安全实验，验证系统级监测能否发现 Agent 执行过程中发生的危险操作。

研究使用 Skill-Inject 数据集。该数据集通过修改 Agent Skill 中的内容或脚本，测试攻击者能否诱导 Agent 执行原本不应该执行的操作。

论文重点关注的是脚本型注入：攻击者不一定直接要求 Agent 执行危险命令，而是修改 Skill 中的说明，让 Agent 在完成正常任务时运行某个辅助脚本。

恶意操作被隐藏在脚本内部，Agent 可能只是认为自己正在执行一项正常的工作流程。

例如，论文给出了一个文献验证任务的案例。

攻击者在 Skill 文档中加入一条额外要求，让 Agent 在提交结果之前先运行 sync_cache.sh，用于同步缓存信息。

这条指令表面上属于正常的任务准备操作，但脚本内部却包含读取 SSH 私钥并向外部服务器发送数据的逻辑。在完成这些操作后，脚本还会继续执行正常的验证程序。

因此，Agent 的最终任务仍然可能成功，执行轨迹中也只是出现一次成功的 Shell 调用。

而 AgentSpy 从系统层面看到的情况完全不同：脚本启动了 curl，读取了 SSH 私钥文件，并尝试连接未授权的网络主机。

根据预先定义的规则，AgentSpy 可以分别对敏感文件访问和异常网络连接产生告警。

研究人员总共设计了四类通用系统级安全规则，分别针对敏感凭据读取、工作区之外的文件修改、非可信程序执行与权限变化，以及访问未授权的网络目标。

这类规则的优势在于判断过程相对确定。它不需要让另一个大模型阅读整个 Agent 对话并猜测某次操作是否危险，而是直接检查实际发生的系统事件有没有越过预先定义的边界。

安全实验取得了什么结果？

研究从 Skill-Inject 中选取五类脚本攻击场景，包括数据外传、数据破坏、拒绝服务、恶意程序和后门植入。

每类场景分别设置包含注入指令的实验组，以及去除注入指令的对照组，每组重复运行五次，共计 50 次执行。

在 25 次包含注入指令的运行中，Agent 实际执行了攻击行为 18 次，其余 7 次没有执行攻击。

AgentSpy 在这 18 次实际执行的攻击行为中成功发现 14 次，没有对其余 32 次未执行攻击行为的运行产生误报。

最终结果为：Precision（精确率）达到 100%，Recall（召回率）约为 77.8%。

需要强调，这只是五类选定攻击案例、50 次运行中的实验结果，不能直接外推到真实企业环境中的整体检测准确率。

但结果已经能够说明，系统级监测可以有效补足传统 Agent 执行轨迹中的部分信息缺口。

为什么 AgentSpy 仍然漏掉了后门植入？

安全实验中最值得关注的，其实是四次没有被发现的攻击。

研究人员发现，四次漏报全部发生在后门植入场景中。

攻击者的脚本没有立即向外部发送数据，而是在本地 Git 配置中添加了一个恶意远程仓库地址。

这意味着 Agent 当前执行的操作并没有直接产生数据泄漏，也没有访问禁止访问的文件。修改 Git 配置的行为发生在允许操作的工作目录之内，因此没有触发 AgentSpy 预先定义的安全规则。

真正的危险可能出现在后续任务中。

如果 Agent 未来执行 Git Push，代码才可能被上传到攻击者指定的仓库。但在本次实验中，后续推送并未发生，因此相关网络行为也没有出现。

这个案例揭示了系统级安全检测的一项重要局限：并不是所有危险行为都会立即跨越明确的权限边界，有些操作只是改变了系统状态，为未来的风险创造条件。

修改 Git Remote、调整 CI/CD 工作流、修改自动化任务配置，甚至改变某些业务系统的默认权限，都可能属于这种情况。

单独观察这些操作，它们未必违规。只有结合任务上下文、用户授权和后续执行过程，才能判断是否真正存在风险。

这也说明，AgentSpy 虽然能够让 Agent 的执行过程变得更加透明，但它并不自动具备理解全部业务风险的能力。

安全监测系统能够回答某个文件是否被修改、某个主机是否被连接，却未必能够直接回答这项修改是否符合用户的真实意图。

从可观测到可控，企业 Agent 安全还缺什么？

从企业安全产品的角度看，AgentSpy 提供了一种很有价值的基础能力，但距离完整的 Agent 安全防护体系仍然存在一定距离。

传统大模型内容安全主要围绕输入与输出展开，例如判断用户请求是否违规、模型回复是否包含敏感信息，以及是否存在提示注入或越狱攻击。

进入 Agent 场景后，安全问题发生了变化。模型不再只是生成内容，还能够执行命令、调用工具、修改文件和操作业务系统。因此，安全判断必须覆盖从用户意图到实际执行行为的整个过程。

我认为，企业级 Agent 安全可以进一步划分为三个相互关联的层次。

第一层是内容与语义安全，负责理解用户请求、外部信息以及 Agent 输出中潜在的风险。

第二层是意图与工具安全，负责验证 Agent 准备执行的操作是否符合用户授权与任务目标。例如一个财务 Agent 是否有权限导出报表，或者一个代码 Agent 是否可以直接修改生产环境配置。

第三层是运行时行为安全，负责记录实际发生的文件操作、程序执行和网络访问，并判断是否触及系统级安全边界。

AgentSpy 主要解决第三层中的可观测与审计问题。它与前两层形成互补，而不是替代关系。

例如，一个 Agent 通过企业允许的邮件服务发送了包含客户数据的文件。从操作系统层面看，它访问的是一个可信服务，可能并没有违反任何系统级规则；但如果实际收件人并未获得授权，这依然是一次严重的业务安全问题。

因此，企业不能只依赖系统调用判断 Agent 是否安全，还需要将系统级事件与 Agent 身份、业务任务、工具调用和授权策略关联起来。

另一方面，AgentSpy 主要验证的是隔离环境下的行为审计，而不是一套已经经过验证的生产环境实时阻断系统。运行时防护如果需要在操作执行前进行授权，还必须设计额外的策略执行点。

更现实的工程问题是，企业 Agent 往往会调用远程 MCP Server、SaaS API、云函数或者其他业务服务。这些操作的实际执行地点可能并不在 Agent 所在主机上，单靠本地内核监测无法获得远端全部行为。

未来如果希望构建完整的 Agent 行为审计体系，就需要将系统级日志、工具调用记录、API 网关日志和业务操作审计进行关联，形成跨执行环境的行为证据链。

对于 Agent 安全评测平台而言，这可能比单独增加一种检测算法更有实际价值。

对 Agent 安全评测的启发

AgentSpy 的研究让我想到，当前很多 Agent 安全评测仍然沿用传统大模型评测的思路：通过构造任务与攻击样本，观察最终结果是否符合预期。

这种方法并没有问题，但当 Agent 开始具备实际执行能力之后，仅依赖最终结果可能会遗漏重要信息。

例如，在一次提示注入攻击中，攻击者试图诱导 Agent 将本地文件上传到外部服务器。最终文件没有成功上传，评测系统于是将这次攻击判定为失败。

但这里其实存在几种不同情况。

第一种是 Agent 正确识别了注入内容，没有执行任何危险操作。

第二种是 Agent 接受了攻击指令，尝试读取和上传文件，但由于工具权限不足，操作被阻止。

第三种是 Agent 已经读取敏感文件，并尝试建立外部连接，只是在后续网络环节失败了。

从最终攻击结果看，这三种情况都可能被判定为攻击失败，但它们反映出的 Agent 安全能力显然不同。

第一种说明 Agent 自身具备一定的攻击抵抗能力；第二种说明权限控制发挥了作用；第三种则意味着执行过程中已经发生了部分危险行为。

如果只统计 Attack Success Rate，就容易将模型自身的防御能力与外部环境的安全约束混在一起。

AgentSpy 提供的系统级行为证据，可以帮助评测系统对这些情况进行进一步区分。

在实际产品设计中，可以考虑把 Agent 安全评测扩展为几个相互独立的维度：最终任务成功率、攻击目标达成率、执行过程中的约束违反情况、重复运行的行为一致性，以及关键操作的审计完整性。

这些指标分别回答不同的问题，不能简单混合成一个综合分数。

尤其对于企业场景，开发者可能并不要求 Agent 每次采用完全相同的执行路径，但必须确保它始终遵守某些不可突破的行为边界。

例如，财务 Agent 可以自主选择如何分析数据，但不能未经授权导出客户资料；代码 Agent 可以自主选择构建工具，但不能擅自修改生产环境配置。

这意味着未来的 Agent 安全评测，不仅需要验证任务和攻击结果，还需要建立可执行的行为约束，并提供能够独立复核的执行证据。

AgentSpy 的研究价值与局限

从技术创新角度看，AgentSpy 并没有提出全新的底层监测技术。Firecracker、auditd、Zeek、Falco 和 eBPF 都已经在传统系统安全领域得到广泛应用。

论文的主要贡献，是将这些技术组合成面向 Agent 的可重复执行与分析框架，并围绕可靠性和安全性提出了两套不同的分析方法。

其研究价值主要体现在三个方面。

首先，它通过实验说明了结果测试与过程观测之间的互补关系。通过全部测试的 Agent，仍然可能产生与任务无关的活动，或者没有遵循开发者提供的工作流程。

其次，它将传统系统安全中的资源监测和规则审计引入 Agent 场景，为第三方 Skill、辅助脚本和工具执行提供了独立于 Agent 自身记录的行为证据。

最后，它为 Agent 行为稳定性研究提供了一种量化方法。通过比较多次运行的资源使用模式，可以识别值得进一步调查的执行差异。

但论文的局限同样明显。

研究主要使用 Codex 这一种 Agent 框架，虽然覆盖多个模型，但不同 Agent 框架、不同操作系统以及远程工具调用场景下的适用性仍然需要验证。

可靠性实验中的行为问题，部分依赖研究者人工判断。星型图虽然能够反映资源使用差异，却没有完整保留操作之间的先后关系和因果链，因此不适合直接作为复杂攻击链的完整解释。

安全实验规模也相对有限，五类选定攻击场景不足以证明其对开放环境中各类 Agent 攻击均具有稳定的检测效果。

论文还对性能开销进行了实验，结果没有观察到具有统计显著性的执行时间差异。但测试没有覆盖全部环境准备和日志收集环节，因此不能据此认为生产部署没有性能成本。

总体来看，AgentSpy 更适合被定位为 Agent 运行时可观测性与行为审计框架，而不是一套可以直接替代现有安全护栏和权限控制的完整防御系统。

Agent 安全正在从结果走向过程

过去，大模型主要负责生成文本，因此人们可以通过检查输入和输出来判断很多安全问题。

如今，Agent 开始能够执行代码、访问文件、调用外部工具，甚至直接操作企业业务系统。它的安全风险不再局限于生成了什么内容，而是进一步延伸到了实际执行了什么操作。

AgentSpy 所研究的问题，正是这一变化带来的新需求。

它没有试图让模型更聪明地识别风险，而是提供了一种相对独立的系统级观察机制，使开发者能够获得 Agent 及其子进程真实执行行为的证据。

但可观测并不等于可理解，更不等于可控制。

看到了 Agent 访问某个文件，还需要知道它为什么访问；发现 Agent 修改某项配置，还需要判断这项修改是否获得授权；即使确认当前操作没有造成损害，也需要考虑是否可能为后续执行引入风险。

因此，未来的 Agent 安全体系需要将行为观测、语义理解、策略判断和执行控制结合起来。

对于企业而言，真正值得追求的并不只是让 Agent 更高效地完成任务，而是能够回答一个更加基础的问题：

我们能否独立验证，Agent 在完成任务的过程中，始终没有突破预先设定的安全边界？

AgentSpy 并没有完全解决这个问题，但它为这一方向提供了一个值得研究和借鉴的起点。

声明：本文来自模安局，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。