一个 Agent 项目可以拥有成百上千个单元测试，却仍没有回答最危险的问题：当网页、文件或工具返回的内容影响模型后，模型能否换一条路径调用 shell、插件或浏览器，绕过原本那道确认？
9 月 15 日提交的一项实证研究审查了 157 个至少获得 100 个 GitHub Star 的开源 Agent 项目。137 个项目包含常规测试或规格，95 个包含安全保障导向的测试，但只有 8 个出现提示注入、对抗、越狱或红队测试路径。更尖锐的口径是：研究者认定 45 个项目存在“不可信上下文传播需要对抗测试”的仓库可见风险链，其中只有 1 个匹配到直接的提示注入或对抗测试，缺口为 44 个。
这不是“156 个 Agent 都不安全”的证据。论文没有运行 157 套生产系统，也没有测事故率。它揭示的是更具体的工程错位：开发者已经在加权限、沙箱和测试，但这些措施常按某个工具或入口布置；Agent 的真实权力却来自多条入口串成的行动路径。
一个高风险动作，往往有不止一个入口
传统功能测试容易围绕组件展开：参数能否解析、设置能否保存、API 是否返回预期结果。Agent 的边界问题则发生在组件之间。一个“执行命令”的动作，可能由内置 shell 工具、MCP 工具、插件、自动模式、无头服务或子 Agent 触发；一个“读取文件”的动作，也可能经由文件工具、shell、上传流程、浏览器下载或持久化状态完成。
论文把这种差异拆成四层：Agent 在哪里行动，分别有哪些保护措施，仓库里有哪些测试，以及不可信输入如何一路到达敏感动作。按其编码，152 个项目具有至少五类执行面，因而被归入“重叠行动路径控制可能不一致”的审查范围。其中 142 个可见审批或鉴权控制、106 个可见沙箱或隔离机制、101 个可见权限或策略控制。这里的重点不是“完全没有防护”，而是同一动作换入口后，防护是否仍成立。
开放复现包里的证据片段能说明这种复杂度。以研究固定快照中的 Gemini CLI 为例，仓库同时暴露 shell、文件、浏览器和 MCP 路径，也分别出现命令确认、沙箱扩展、MCP 工具确认和浏览器会话模式。逐个组件都能找到控制，并不能自动证明“已授权目录”“需确认命令”或“可访问域名”在所有组合路径上保持同一语义。
常规测试覆盖组件，对抗测试才追踪行动链
研究统计显示，157 个项目中有 137 个包含常规测试，95 个包含安全保障导向测试，78 个包含评测、基准、对抗或类似红队的路径，只有 8 个包含提示注入、对抗、越狱或红队测试路径。几组数字可以重叠，不能相加；它们记录的是仓库里可定位的测试意图，不是测试质量评分。
“97.8%”尤其需要看清分母。它来自 45 个被标记为存在不可信上下文传播风险的项目：其中 1 个匹配到直接对抗测试，44 个没有。若放回全部 157 个项目，论文给出的全局数字是 8 个项目存在这类测试路径。研究的匹配还依赖文件名、路径和人工审查规则，因此 97.8% 适合描述该编码框架下的直接覆盖缺口，不适合改写成开源 Agent 的普遍失守率。
这个结论与更早的测试实践研究形成了可解释的连续线索。后者从 39 个 Agent 框架和 439 个 Agent 应用中抽取测试函数，发现超过七成测试精力集中在工具等资源组件与工作流等协调组件，涉及提示词的触发组件约占 1%。前一项研究说明测试集中在哪里，这次研究进一步追问：这些组件测试能否证明一次模型决策经过多个工具后仍停留在授权边界内。
风险记录不是漏洞，开放数据也不能完全复现分类
论文将 814 条记录称为“风险场景”，它们是需要做边界审查的候选行动链，不是已经确认可利用的漏洞。比如，不可信网页影响后续工具调用、插件继承本地进程权限、工作区内容进入持久状态，都可以形成风险链；是否真的越权，还取决于部署配置、托管服务侧控制、依赖行为和运行时策略。
研究样本也有明显边界。它是 2026 年 5 月的固定快照，要求项目至少 100 Star，编码和浏览器自动化项目占比较高；闭源企业系统、小型项目和此后新增控制不在结论范围内。研究使用自动搜索与 LLM 辅助摘要发现候选材料，再由人工核验；分类法在开放编码过程中演化，因此没有计算分类构建阶段的标注者一致性。
本轮下载并运行了复现包的校验脚本：157 个仓库、814 条风险记录以及各汇总表在包内相互一致。复现包也列出固定提交、文件路径和证据片段，适合抽样回查。它没有包含汇总表所引用的全部上游中间数据和 157 个仓库快照，因此外部读者可以复算已发布 CSV，却不能只靠这个包从原始代码完整重建所有标签。这个限制不推翻统计，但要求读者把它当作一项可审计程度有限的静态仓库研究。
测试对象应从“工具能不能用”改为“动作能不能越界”
对 Agent 团队最实用的改法，是先按受保护的动作或资产定义边界，再枚举所有等价入口。下面这张清单不是论文中的新统计，而是根据其行动链方法整理出的测试模板：
| 受保护对象 | 需要同时覆盖的入口 | 应保持的边界 | 失败导向测试 |
|---|---|---|---|
| shell 与宿主进程 | 内置工具、MCP、插件、API、自动模式 | 同一审批、沙箱和命令策略 | 换入口或模式后，未授权命令仍必须失败 |
| 工作区文件 | 文件工具、shell、上传下载、hook、子 Agent | 路径解析后仍限制在工作区 | 绝对路径、..、符号链接和持久状态复用均不能越界 |
| 密钥与会话 | 环境变量、MCP 配置、日志、浏览器 Cookie、工具输出 | 最小继承、脱敏和域隔离 | 不可信页面或文件诱导回传时，测试必须阻断泄露 |
| 插件与动态代码 | 本地插件、远程 MCP、包安装、运行时代码 | 注册、来源和权限变更可审查 | 新增工具后自动重跑权限矩阵与多步回放 |
这类测试不只验证“有一道确认框”，而要故意拆掉或绕过某个控制，确认回放用例会失败。AgentDojo早已展示了这种思路：它把 97 个任务与 629 个安全测试用例放进可扩展环境，测试外部工具返回的不可信数据能否把 Agent 引向恶意任务。具体项目不必照搬同一基准，但需要保留同样的因果链：触发输入、模型决策、工具序列、受保护资产、预期阻断点和可重复断言。
157 个项目的审查最终留下的不是一句“测试太少”，而是一条更可执行的判断：Agent 增加一个工具时，团队增加的不是一个孤立功能，而是一条可能通往已有权限的新路径。发布门槛也应随之改变——只有每条等价路径都通过同一边界断言，组件测试的绿色才真正能代表 Agent 的行动被约束住。
