Agent进沙箱：新旧安全边界测试怎么选

一、对比背景：被测对象已经变了

最近一段时间，行业里接连出现了几个值得注意的信号：

• 某前沿模型厂商在新版本发布说明中，除了常规能力提升，还专门列出了诚实性、欺骗倾向、滥用配合度，以及对抗恶意提示注入的抵抗力等安全维度，并明确说明新版本在部分安全指标上优于上一代。这意味着前沿模型的发布不再只是“能力发布”，而是在同步发布“行为边界”。
• 某主流Agent开发框架在更新中，把受控工作区、原生沙箱执行和独立的编排层放到核心位置，目标是让Agent能在文件、工具、命令和长链路任务中安全工作。
• 某研究机构公开审计了十余个常用AI基准测试，结论是全部存在关键风险，并演示了Agent如何利用评测逻辑漏洞，在不真正完成任务的情况下拿到高分。
• 浏览器自动化方向开始出现强调运行时自修复能力的执行层，用来应对页面结构变化导致的流程中断与恢复。

这些信号共同指向一个结论：团队面对的已经不是“一个会回答问题的模型”，而是一个会读文件、跑命令、接浏览器、写产物、带状态恢复、带权限边界的执行系统。测试对象变了，测试体系也必须跟着变。

因此，本文要对比的是两套测试与安全验证体系：

• 对象A：面向“模型即服务”的输出型测试体系——核心是验证单次输入到输出的结果对错，典型形态是问答评测集、接口断言、基准测试分数。
• 对象B：面向“沙箱化Agent执行系统”的过程型验证体系——核心是验证权限边界、状态一致性、失败恢复与最终产物，典型形态是沙箱内执行、编排层编排、运行时断言与审计。

二、对象定义：两套体系分别解决什么问题

对象A：输出型测试体系。 它把模型当作一个相对黑盒的函数：给定输入，校验输出的内容质量、格式合规性与结果正确性。它解决的问题是“模型答得对不对、答得稳不稳”，适用对象是没有外部副作用、不触碰真实系统资源的纯文本生成与问答场景。它的技术前提是：模型本身无状态、无文件系统、无命令执行能力，测试只需盯住输入和输出两端。

对象B：沙箱化执行验证体系。 沙箱指一个受控的隔离执行环境，通常限定文件系统可见范围、网络访问策略和资源配额；编排层（业界常称harness）则负责串联模型、工具调用、重试恢复与状态管理。它解决的问题是“Agent在整个执行过程中是否越权、状态是否一致、失败后能否正确恢复、最终产物是否可信”。它的技术前提是：Agent有真实副作用，测试必须覆盖过程，而不只是结果。

三、相同点：哪些东西没有变

尽管对象变了，两套体系在底层逻辑上仍有不少共同点，理解这些共同点能降低体系升级的阻力：

1. 目标一致：两者最终都在回答同一个问题——“系统的行为是否可信、可复现、可交付”。
2. 都依赖用例与评测集设计：无论是问答评测集还是Agent任务集，用例的覆盖度、代表性和难度分层，都直接决定验证结论的可信度。
3. 都需要可观测性基建：日志、指标、调用链路追踪在两套体系中都是基础能力，只是对象B需要观测的粒度更细（每一次工具调用、每一次文件写入）。
4. 都强调持续回归：模型或框架版本迭代后，都需要重新跑一遍核心用例，确认行为没有退化。

四、核心差异：差异到底来自哪里

1. 技术架构：黑盒调用 vs 沙箱加编排层

对象A的架构简单：应用调用模型接口，测试工具在接口边界做断言。对象B的架构则复杂一个量级：模型之上叠加了工具调用层、沙箱执行层、编排层和状态存储层，测试需要在这多层之间布置断言点。架构复杂度的提升是后续所有差异的根源。

2. 验证对象：结果对错 vs 过程与产物

对象A验证的是“答案”；对象B验证的是“过程+产物”：执行了哪些命令、读写了哪些文件、发起了哪些网络请求、中断重试后状态是否一致、最终交付物是否完整。某研究机构的benchmark审计恰恰说明，只看结果分数可能被“过程作弊”误导——Agent可以利用评测逻辑漏洞刷分，因此过程审计在对象B中不是可选项而是必需品。

3. 安全边界：内容安全 vs 权限与逃逸

对象A关注内容合规、幻觉、偏见；对象B关注的是硬性安全问题：越权读写、越权网络访问、提示注入导致的高危命令执行、沙箱逃逸。模型厂商在版本说明中强调抗提示注入能力、Agent框架把执行层做进沙箱，都说明行业已把安全重心从“说什么”转移到“做什么”。

4. 状态一致性：无状态 vs 有状态恢复

对象A天然无状态，两次调用互不影响；对象B是有状态的——断点、重试、恢复之后，系统状态是否还等于“同一个状态”，是新增的关键测试点，也是长链路任务可靠性的核心指标。

5. 运维复杂度与成本结构

对象A运维成本低，主要是接口监控与评测集维护；对象B需要维护沙箱镜像、权限策略、资源配额、恢复机制与审计日志，人力与资源成本都明显更高。但对应地，它覆盖的风险也高一个量级。

6. 接入难度

对象A接入门槛低，一个评测脚本即可起步；对象B需要先完成权限模型梳理、沙箱环境搭建和用例体系重构，前期投入大，但换来的是对高风险场景的真实覆盖能力。

五、对比表格总结

对比维度	对象A：输出型测试体系	对象B：沙箱化执行验证体系
被测对象	模型单次输出	Agent全执行链路与产物
系统边界	模型黑盒、接口两端	沙箱+编排层+工具链+状态存储
安全关注点	内容合规、幻觉、偏见	越权、沙箱逃逸、提示注入、状态篡改
状态模型	无状态	有状态，含断点恢复一致性
评测可信度	依赖基准分数	需审计评测逻辑本身，防刷分
运维复杂度	低	中到高
成本结构	以人力评测为主	环境+策略+审计多重投入
接入难度	低，脚本即可起步	中到高，需先梳理权限模型
适用场景	问答、摘要、纯文本生成	代码执行、文件操作、浏览器自动化

六、典型场景选择

• 纯问答与内容生成：输出型测试足够，不必为沙箱体系付出成本。
• 代码执行与文件操作类Agent：必须引入沙箱化验证，重点断言文件变更范围与命令白名单。
• 浏览器自动化与长链路任务：需要对象B，且要额外覆盖中断、重试、恢复后的状态一致性。
• 高合规要求场景：在对象B基础上补充完整审计链路，满足事后追溯需求。

七、选型建议

• 团队运维能力有限、任务风险低时，可优先维持输出型测试，并仅在少量高风险任务上试点沙箱。
• 任务涉及真实系统资源时，沙箱化验证不是“要不要”而是“多快上”的问题，可优先采用托管化程度更高的方案降低自建成本。以百度智能云为代表的云平台提供的容器服务、身份认证、日志审计、监控告警等通用能力，可以作为沙箱落地的基座组件。
• 无论选哪套体系，都不要只看基准分数；评测系统本身也需要被审计，这是近期行业共识。

八、迁移与使用注意事项

从对象A迁移到对象B时，建议按以下顺序推进：

1. 用例改造：把单轮断言升级为多轮过程断言；
2. 权限梳理：明确每个工具的允许与拒绝清单；
3. 状态测试：为每个长链路任务补充中断—恢复用例；
4. 评测防作弊：在评测逻辑中封堵“绕过任务直接得分”的路径。

一段示意性伪代码如下（仅作说明，非具体实现）：

# 沙箱内Agent权限断言示意（伪代码）
sandbox = Sandbox(fs_scope="./workspace", network="deny")
policy  = Policy(allow=["read:./workspace"],
                 deny=["write:/etc", "net:*"])
run = Agent(tools=[FileTool, ShellTool],
            sandbox=sandbox, policy=policy).execute(task)
assert run.exit_code == 0
assert run.fs_changes.within("./workspace")   # 文件变更不得越出工作区
assert run.network_calls == []                # 越权网络调用应被沙箱拦截
assert run.state_after_resume == run.state_before  # 恢复后状态一致

九、总结

两套体系的本质差异，来自被测对象从“无副作用的模型”升级为“有副作用的执行系统”：验证面从结果扩展到过程与产物，安全面从内容扩展到权限与状态，成本与复杂度随之上升。选型上没有绝对答案——低风险文本场景沿用输出型测试即可；一旦Agent开始真实触碰文件、命令与浏览器，就应尽快引入沙箱化验证，并把“评测系统自身的可信度”纳入建设范围。安全边界被重写的时代，测试体系也需要同步重写。