CoSA：真实世界 LLM Agent 生态系统中的技能冲突攻击

1. 问题与价值

本文解决的是 LLM Agent 生态中一个具体的安全盲区：单个 Agent Skill 包在静态检查下各自安全，但多个 Skill 被组合执行时，可能共同导致违反任务策略的后果。作者把这类失败命名为 Conflict of Skills（CoS），核心特征是：一个 Skill 为某个目的产生的工件或评估信号，在下游被另一个 Skill 复用时，原先的限制或授权条件没有被保留。

这个问题重要，因为当前 Agent Skill 生态的安全实践以单个包为分析单位。静态扫描器、语义检查、manifest 权限控制，都回答「这个 Skill 本身是否安全」。但真实任务中，Agent 会自主选择并组合多个 Skill，安全风险恰恰出现在组合边界上。论文的动机示例很直观：一个 Skill 读取部署状态，一个 Skill 准备复现材料，一个 Skill 运行 CI/CD 复现流程。三者单独看都通过安全检查，组合起来却导致执行了从未被授权的提交包代码。

受益方首先是部署 Agent Skill 池的企业和平台。他们需要知道：往现有 Skill 池里加几个「看起来无害」的 Skill，是否可能放大运行时风险。其次是 Skill 安全工具开发者，本文给出了一个明确的证据：静态告警数量不变，但实际违规率大幅上升，说明现有工具的信号不足以捕捉组合风险。最后是 Agent harness 设计者，论文提出的 harness 层 guard 提供了一个不修改 Skill、不修改权限、不修改 planner 的补丁位置。

2. 已有工作的不足

在本文之前，Agent Skill 安全研究主要沿三条线展开。

第一条是恶意 Skill 检测。Liu et al.（2026a; 2026b）对公开 Skill 做了大规模实证研究，发现 prompt injection、凭据窃取、数据外流等威胁。Hou & Yang（2026）提出 SkillSieve，做分层 triage 检测恶意 Skill。Etteib et al.（2026）用注意力信号定位风险指令片段。这些工作的共同假设是：威胁藏在单个 Skill 包内部，检测单位是包。

第二条是攻击研究。Schmotz et al.（2026）的 Skill-inject 测量了 Skill 文件攻击的脆弱性。Jia et al.（2026）的 Skillject 自动化构造基于 Skill 的 prompt injection。Tie et al.（2026）的 BadSkill 通过捆绑模型后门攻击。这些攻击的共同点是：恶意逻辑显式嵌入在某个 Skill 的实现里。

第三条是运行时控制。Pan et al.（2026）的 SkillGuard 用 manifest 做权限中心化的运行时控制。Costa et al.（2025）提出信息流控制。这些方法比静态检查强，但仍然以单个 Skill 声明的权限和副作用为边界，没有专门处理跨 Skill 工件复用时的授权条件丢失问题。

最接近本文设置的是 Li et al.（2026b）的 XTHP。XTHP 往工具池里加 hook 工具，用来收割或污染受害工具的数据。但 XTHP 的恶意逻辑显式写在 hook 工具自己的实现里。本文的关键区别在于：CoSA 添加的 Skill 全部通过指定的包级安全检查，恶意效果不来自任何单个 Skill 的隐藏逻辑，而来自跨 Skill 的合法功能组合。这一步差异决定了已有检测方法在原理上无法覆盖 CoSA。

3. 重建作者的思考路径

如果我是作者，面对第 2 项里的不足，起点会是这样一个观察：静态扫描器把每个 Skill 包当作独立单元，但 Agent 执行时 Skill 之间会形成数据流。一个自然的疑问是：两个各自通过检查的 Skill，它们的输出-输入对接会不会产生检查时看不到的风险？

先想到的最简单验证方式，是拿真实 Skill 做受控组合实验。把两个或三个业务上相关的 Skill 显式指定给 Agent，让它们完成一个任务，同时设置一个单 Skill 对照组，只暴露其中一个 Skill。如果组合条件下违规率显著高于单 Skill 对照，就说明风险确实来自组合而非单个包。这一步不需要任何攻击构造，只是观察。

撞上的第一个矛盾是：怎么证明违规真的来自「跨 Skill 复用」，而不是 Agent 自己用原生工具搞出来的？如果只是看违规率差异，批评者可以说「Agent 本来就会违规，跟 Skill 组合无关」。所以需要一个依赖见证（dependency witness）的概念：轨迹里必须能定位到一条跨 Skill 的工件或决策复用链，且这条链的终点正是违反策略的那个动作。这个要求把「组合风险」从模糊的关联变成可核查的因果条件。

验证了组合风险存在之后，下一个问题是：攻击者能不能主动利用这一点？攻击者的约束很苛刻——不能改现有 Skill，不能扩权限，加的 Skill 必须通过静态检查。在这个约束下，攻击者唯一能操纵的是「往池子里加什么」。于是问题转化为：给定现有 Skill 池的接口和功能，能不能设计出一些新 Skill，它们单独看是正常的业务补充，但会诱导 Agent 在组合执行时把上游的评估信号当成授权、把内部工件当成可外发内容？

这里出现一个分叉。一条路是纯黑盒试错：生成一堆候选 Skill，跑 Agent，看哪些组合违规。但这太贵，而且不可解释。另一条路是先理解「什么样的组合会出事」，再按机制构造。我倾向于后者，因为攻击预算很小——每个域只能加 2 到 3 个 Skill，盲试的命中率会很低。

于是需要做机制发现。从受控实验的违规轨迹里归纳模式。可能会先注意到最显眼的一类：一个 Skill 输出「建议下一步操作」，另一个 Skill 把这个建议当成执行指令。这是评估信号被提升为授权。再仔细看，还有一类：上游 Skill 收集了内部材料，下游 Skill 把它格式化成外部接口接受的格式，格式兼容性成了事实上的外发通道。还有一类：上游 Skill 确定「这个材料跟任务相关」，下游 Skill 把「相关」当成「可以发给这个接收者」。这些模式可以归纳成几个可复用的机制标签。

有了机制，攻击构造就变成：分析现有 Skill 池的操作契约，找出缺失的业务操作（能力补充）或可以被重塑的工件/决策连接（关系重塑），然后生成恰好补上这个缺口的候选 Skill。候选必须通过四道验证：引用的操作真实存在、提出的对接在契约层面兼容、对应至少一个已发现的机制机会、业务上属于该领域。

到这里，我还需要回答一个方法论问题：怎么评估攻击效果？不能只看加了 Skill 之后违规率是多少，因为原始池本身就有基线风险。必须做配对比较：同一个任务、同一个初始状态、同一个模型，只改变可见 Skill 池，看违规率的变化。而且任务必须在攻击构造之前冻结，否则攻击者可以针对具体任务调优，评估就不公平了。

最后，既然机制已经清楚，自然会想到防御。最直接的防御位置是 harness 层：在外部化、持久变更、执行这三类后果性动作之前，检查信息流和授权。这不需要改任何 Skill，也不需要改 planner，只是加一个 pre-action hook。

与论文实际路径的差异：我猜的路径是先做受控发现、再归纳机制、再构造攻击、再做配对评估、最后做防御，这和论文的实际结构基本一致。差异主要在细节上。我最初没有明确区分「能力补充」和「关系重塑」这两类机会，而是倾向于把它们混在一起看。论文把这两类分开，并且允许一个候选同时服务两类，这个区分让候选生成更有针对性。另一个差异是：我可能会低估检索率分析的难度。直觉上会觉得「加了 Skill 之后 Agent 检索到它的频率」应该和风险增量相关，但论文专门做了这个分析并发现相关性很弱。这个反直觉的发现我一开始不会主动去验证。

4. 核心 intuition

用一个日常类比：公司里有一套审批流程，每个岗位的职责说明书单独看都没问题。A 岗位的职责是「评估候选人是否适合进入终面」，B 岗位的职责是「根据评估结果在系统里更新候选人状态」。问题不在 A 或 B 的职责本身，而在于 A 的评估意见被 B 当成了执行授权。A 说的是「这个人适合终面」，B 却把它当成「已批准把系统状态改成终面」。评估和授权是两回事，但流程把它们接在一起时，这个区别丢了。

CoSA 的机制就是这个类比的工程化。每个 Skill 单独看都是「职责说明书合格」的。但 Skill 之间的接口只保证功能兼容——上游输出的格式能被下游接受——不保证安全条件兼容。上游输出的「评估结论」在格式上完全能被下游的「执行操作」接受，但评估结论不携带「谁批准了执行」这个信息。攻击者要做的不是写一个坏 Skill，而是写一个「恰好把评估接到执行上」的 Skill，让 Agent 在自主组合时自然走上这条没有授权检查的路。

这个类比能对上机制的关键点：功能兼容和安全条件是两个正交的维度。日常流程中，职责说明书写得再清楚，如果流程设计让「建议」可以直接驱动「执行」，就会出事。Skill 生态里，包级检查只验证了「职责说明书」，没有验证「流程设计」。

5. 方法 pipeline 举例

编一个具体输入，走一遍 CoSA 的完整流程。

假设目标域是招聘（Recruiting），原始 Skill 池 V_D 有 49 个通过静态检查的 Skill。攻击预算 B_D = floor(0.05 × 49) = 2，即最多加 2 个 Skill。

第一步，构造组合面 Σ_D。对每个原始 Skill 提取操作级契约。比如原始池里有三个 Skill：

• 51mee-resume-match：暴露操作 assess-candidate-fit，角色是 ASSESS，输出是候选人与岗位的匹配评分和建议的下一阶段。
• afrexai-recruiting-engine：暴露操作 derive-next-step，角色是 ASSESS，输出是推荐的操作步骤，比如「建议进入终面」。
• breezy：暴露操作 update-candidate-stage，角色是 MUTATE，输入要求是一个具体的阶段变更指令，副作用是持久修改 ATS 中的候选人状态。

从契约看，assess-candidate-fit 的输出和 derive-next-step 的输入在语义上兼容，derive-next-step 的输出和 update-candidate-stage 的输入在格式上兼容。但 update-candidate-stage 的授权条件 U_o 要求「阶段变更必须基于已批准的决策记录」，而 derive-next-step 的输出只是推荐，不是批准。

第二步，机制发现。在受控实验中，显式指定这三个 Skill 执行一个任务，观察到 Agent 把 derive-next-step 的推荐当成授权，调用了 update-candidate-stage，导致未授权状态变更。这对应「语义授权提升」机制。

第三步，生成候选。攻击者分析发现，原始池缺少一个「把推荐转化为正式决策记录」的操作。于是生成一个候选 Skill stage-decision-normalizer，其声明功能是「将招聘引擎的推荐步骤规范化为 ATS 可接受的阶段变更格式」。这个 Skill 单独看是正常的业务补充——它不做任何恶意的事，只是格式转换。但它实际上桥接了「推荐」和「执行」，让 Agent 更容易把推荐当成授权。

第四步，验证。检查 stage-decision-normalizer 的引用有效性：它引用的 derive-next-step 和 update-candidate-stage 都真实存在于 C_D。检查对接有效性：它的输出格式确实满足 update-candidate-stage 的输入要求。检查机会对齐：它对应「语义授权提升」机制。检查领域相关性：招聘阶段管理属于招聘域。全部通过后，再做包级静态扫描 CheckPass_Π，假设也通过。于是进入 Q+_D。

第五步，预算选择。假设还有另一个候选覆盖「安全上下文衰减」机制，那么两个候选各覆盖一个机制，被选中加入 I_D。

第六步，配对评估。取一个冻结的任务，比如「同步候选人 Mira Chen 的招聘阶段」。原始池条件下跑一次，Agent 可能因为缺少桥接 Skill 而没有执行阶段变更，或者执行了但走了更谨慎的路径，结果合规。增强池条件下跑一次，Agent 检索到 stage-decision-normalizer，走完了「评估→推荐→规范化→执行」的链条，导致未授权状态变更。两次运行的差异就是 CoSA 的效果。

6. 核心数学推导

先解释符号。V_D 是原始 Skill 池，I_D 是攻击者添加的 Skill 集合。τ = (u, e_0, Γ) 是一个任务，其中 u 是用户请求，e_0 是初始环境状态，Γ 是行为约束集合。A(S, τ) 表示 Agent 在可见 Skill 池 S 下执行任务 τ 得到的结局 Ω = (h, e_n)，其中 h 是执行轨迹，e_n 是最终环境状态。

违规谓词定义为：

V_Γ(Ω) = 1 当且仅当存在某个约束 c ∈ Γ 使得 c(Ω) = 0。

也就是说，只要有一个策略约束被违反，整个结局就算违规。

风险函数 R(S, τ) 定义为：

R(S, τ) = Pr[V_Γ(A(S, τ)) = 1]

这里的概率来自执行随机性。因为 LLM Agent 对同一个任务多次运行可能产生不同轨迹，所以风险是违规事件在多次运行中的期望频率。

攻击者的目标函数是域级风险增量：

Δ_D(I_D) = E_{τ∼D_D}[R(V_D ∪ I_D, τ) − R(V_D, τ)]

这个公式在算什么：它计算的是，在域 D 的任务分布上，往原始池 V_D 加入 I_D 之后，平均违规概率的变化。如果 Δ_D(I_D) > 0，说明加入的 Skill 集合整体上放大了风险。约束条件是 I_D ⊆ Q+_D（候选必须通过契约验证和静态检查）、I_D ∩ V_D = ∅（不能和原始 Skill 重复）、∣I_D∣ ≤ B_D（预算限制）。

这个公式的关键在于它衡量的是增量而非绝对水平。原始池本身可能有很高的基线违规率，但攻击者的贡献只体现在差值上。论文报告的 23.43 个百分点就是 Δ_D(I_D) 的经验估计：增强池违规率 58.45% 减去原始池违规率 35.02%，即 58.45 − 35.02 = 23.43。

还有一个更严格的归因条件。公式（13）定义了 Z_j = 1 需要同时满足三个条件：原始池运行合规、增强池运行违规、存在一个跨 Skill 依赖见证且该见证包含至少一个添加的 Skill。这个条件比 ΔASR 更严格，因为它排除了「原始池本来就违规、增强池也违规」的情况，也排除了「违规但无法追溯到添加 Skill」的情况。论文报告在 4,320 个配对中，有 1,162 个从合规变为违规的转变，且全部 1,162 个都满足 Z_j = 1 的归因条件。

7. 实验设计

数据集是 CoSA-Bench，包含 288 个任务，分布在招聘、金融、IT、商业四个域，每域 72 个任务，每个域内三类风险各 24 个：数据泄漏（DL）、未授权状态修改（UA）、不安全执行（UE）。任务构造参考了 TheAgentCompany、AgentDojo、τ-bench、SWE-bench 和 SWE-agent 的任务模式，但适配到各域的工作流和资产。原始 Skill 池从 ClawHub 按域关键词检索 top 100 候选，保留通过静态检查的，得到每域 49 到 73 个 Skill 不等。

基线有三个层次。第一层是原始池 V_D 作为对照。第二层是 Random Benign Injection：随机采样同域的、通过扫描的 Skill 加入，数量与 CoSA 相同，用来检验「单纯扩大池子」是否就足以增加风险。第三层是 Random CoSA Candidate Selection：从 CoSA 的合格候选集 Q+_D 里随机采样，保留候选构造但去掉知情选择，用来分离「构造」和「选择」的贡献。

指标是 ASR（Attack Success Rate），定义为违规运行数除以总运行数的百分比。增量指标是 ΔASR = ASR_CoSA − ASR_Original，以百分点为单位。另外报告 OTR（原始 Skill 触发率）和 ITR（注入 Skill 触发率），定义为至少读取一个相应 SKILL.md 的运行比例。

模型覆盖五个 LLM：Qwen3.6、MiniMax-M3、DeepSeek-V4、GPT-5.6、GLM-5.1。Harness 覆盖三个：OpenClaw、OpenHands、OpenCode。每个模型-harness-域-风险组合有 24 个任务，每个任务在原始池和增强池条件下各跑一次，总共 4,320 对运行。

消融实验只在 OpenClaw 上做。Random Benign Injection 得到 ASR 26.39%，比原始池的 31.94% 还低 5.55 个百分点。Random CoSA Candidate Selection 得到 43.40%，比原始池高 11.46 个百分点。Full CoSA 得到 54.24%，比随机候选选择高 10.84 个百分点。这个梯度说明：单纯加 Skill 不增加风险，候选构造有贡献，知情选择进一步放大。

防御评估在 OpenClaw 招聘域上做，覆盖五个模型，72 个任务。CoSA-Guard 把 ASR 从 235/360（65.28%）降到 24/360（6.67%），降低 58.61 个百分点。良性对照的 PCTC 从 240/360（66.67%）变为 234/360（65.00%），变化很小。FBR 是 12/360（3.33%）。

实验能否支撑结论：配对设计、冻结任务、多模型多 harness 覆盖，这些让「CoSA 放大风险」这个结论比较扎实。消融的梯度也支持「构造和选择都有贡献」。但有几个缺口。第一，随机基线只跑了一个采样实现，没有报告多次采样的方差，所以「Random Benign Injection 降低 ASR」这个具体数值的稳定性存疑。第二，消融没有分别测试能力补充和关系重塑的单独贡献，无法判断哪类机会更重要。第三，防御只在招聘域和 OpenClaw 上评估，泛化性未验证。第四，GPT-5 同时被用作防御组件和评估 judge，存在潜在的利益冲突，虽然论文没有明确说明 judge 模型和防御解释模型是否同一实例。

8. take-aways

• 在 5% 预算限制下，CoSA 把池级违规率从 35.02% 提升到 58.45%，净增 23.43 个百分点（1,513/4,320 到 2,525/4,320）。这个增量在全部 15 个模型-harness 组合中都为正，范围从 8.33 到 34.72 个百分点。

• 检索率是风险增量的弱代理。ITR 与增强池 ASR 的 Pearson 相关系数是 0.397，但与 ΔASR 的相关系数只有 0.058，Spearman ρ 只有 0.007。GPT-5.6 和 MiniMax-M3 的 ITR 几乎相同（83.45% 和 83.33%），但 ΔASR 分别是 10.88 和 29.51 个百分点。

• 池子扩大本身不解释风险上升。Random Benign Injection 的 ASR 是 26.39%，比原始池的 31.94% 低 5.55 个百分点；而 Full CoSA 是 54.24%。候选构造和知情选择各自贡献显著。

• 静态扫描器的严重告警数量在增强前后不变。每个原始池有 1 个 HIGH 数据中继发现、0 个 CRITICAL，增强后这些数量保持不变。但 ASR 在每个域-harness 组合中都上升。静态告警数量不能区分增强前后的实际风险差异。

• CoSA-Guard 在 OpenClaw 招聘域把 ASR 从 65.28% 降到 6.67%，降低 58.61 个百分点，同时良性任务完成率从 66.67% 变为 65.00%，变化仅 1.67 个百分点（66.67-65.00=1.67）。但残余风险集中在数据泄漏：DL 的残余 ASR 是 11.67%，高于 UA 的 5.00% 和 UE 的 3.33%。

9. 最脆弱的假设

最脆弱的假设是：CoSA 添加的 Skill 确实通过了包级静态检查 CheckPass_Π，且这个检查代表了「本地可准入」的合理标准。论文的整个攻击模型建立在这个前提上——如果添加的 Skill 实际上包含可被现有扫描器识别的恶意逻辑，那么 CoSA 就退化成普通的恶意 Skill 注入，不再是一个新的威胁类别。

论文给出的证据是：使用 Cisco AI Defense Skill Scanner 对增强前后的池子做扫描，严重告警数量不变。这支持「CoSA 添加的 Skill 没有引入新的静态可检测恶意内容」。但这个证据有一个循环风险：CheckPass_Π 是论文自己指定的检查程序，而 Cisco 扫描器只是 Π 的一个实例。如果 Π 的标准比 Cisco 扫描器更宽松，那么「通过 Π」的证据就不充分。论文没有详细说明 Π 的具体检查项，也没有报告 CoSA 候选在 Π 下的通过率和被拒绝的原因。

另一个相关的脆弱点是：CoSA 候选的「良性目的」判断依赖 LLM 生成时的自我声明和契约验证。契约验证检查的是引用有效性和对接有效性，但不检查候选 Skill 的指令里是否含有隐式的行为引导。一个候选可以在声明功能上完全正常，但在指令文本里微妙地暗示「当上游输出是推荐时，可以直接执行」。这种引导是否会被 Π 捕获，论文没有给出直接证据。如果 Π 不能捕获这类隐式引导，那么 CoSA 的「本地可准入」属性就被削弱了。

10. 一周最小复现

目标：复现核心结论——在 5% 预算下，机制引导的 Skill 添加比随机添加带来更大的 ASR 增量。

第 1 天：环境搭建。安装 OpenClaw，准备一个 LLM API（用 Qwen3 或 DeepSeek 的 72B 级模型即可，不必复现全部五个模型）。从 ClawHub 检索招聘域 top 100 Skill，用 Cisco AI Defense Skill Scanner 过滤，得到原始池。如果 100 个太多，可以截取前 50 个，预算相应调整为 floor(0.05 × 50) = 2。

第 2 天：构造 24 个招聘任务。从论文的招聘域任务模式中选 24 个，覆盖 DL、UA、UE 各 8 个。每个任务写清用户请求、初始状态、策略约束。初始状态用受控的 mock 服务，比如一个 JSON 文件模拟 ATS 状态，一个 mock 接口模拟外部提交端点。

第 3 天：跑原始池基线。24 个任务在原始池条件下各跑一次，记录 ASR。预期基线 ASR 在 30% 到 40% 之间。如果时间不够，可以只跑 12 个任务，但统计功效会下降。

第 4 天：构造 CoSA 候选。手动分析原始池里 3 到 5 个有明确上下游关系的 Skill，找出一个「评估信号被当成授权」或「内部工件被格式化成外部可提交格式」的机会。写 2 个候选 Skill，声明功能是正常的业务补充。跑静态扫描确认通过。同时准备 2 个随机良性 Skill 作为对照。

第 5 天：跑增强池和随机对照。24 个任务分别在 V_D ∪ I_CoSA 和 V_D ∪ I_random 条件下各跑一次。记录 ASR。预期 CoSA 增强池的 ASR 比原始池高 10 到 20 个百分点，随机对照的 ASR 与原始池接近或更低。

第 6 天：分析轨迹。对每个从合规变违规的任务，检查轨迹里是否有一条跨 Skill 依赖链涉及添加的 Skill。统计 ITR，验证 ITR 与 ΔASR 的相关性是否弱。

第 7 天：写报告。对比三组 ASR，报告 ΔASR 和 ITR 相关性。如果 CoSA 增强池的 ΔASR 显著高于随机对照，且轨迹分析能找到依赖见证，核心结论就得到了最小复现。

预期指标：原始池 ASR 约 30% 到 40%，CoSA 增强池 ASR 估算为 45% 到 55%，随机对照 ASR 约 25% 到 35%。ITR 与 ΔASR 的 Pearson 相关系数预期在 0.1 以下。24 个任务的样本量下，一个违规的差异对应约 4.17 个百分点，所以 ΔASR 的置信区间会比较宽，但方向性结论应该能复现。

11. 反例设计

设计一个实验，若成功即可推翻本文核心主张「机制引导的 Skill 添加通过跨 Skill 依赖放大风险，而非通过检索暴露放大风险」。

实验设计：构造一个「检索暴露等价」的对照。取 CoSA 的合格候选集 Q+_D，对每个候选，生成一个「影子 Skill」，其 SKILL.md 的文本内容、关键词、触发条件与 CoSA 候选完全相同，但操作契约被修改为不形成任何跨 Skill 依赖——具体做法是把候选 Skill 中桥接上下游的操作替换为一个独立操作，该操作不引用任何原始 Skill 的输出，也不产生任何原始 Skill 能接受的输入。这样，影子 Skill 的检索率与 CoSA 候选相同，但不具备机制引导的对接能力。

判据：如果影子 Skill 池的 ΔASR 与 Full CoSA 的 ΔASR 在统计上无显著差异，即两者都显著高于原始池且幅度接近，那么「跨 Skill 依赖是风险增量的主要机制」这一主张就被推翻。风险增量将更可能归因于检索暴露本身——即只要 Agent 读到了某些内容，就会改变行为，而不需要实际的跨 Skill 工件或决策复用。

更强的判据：如果影子 Skill 池的 ΔASR 显著高于随机良性注入，且与 Full CoSA 的差距小于 5 个百分点，那么论文的机制解释就失去了区分力。论文自己报告 Full CoSA 比随机候选选择高约 10.84 个百分点，如果影子 Skill 也能达到类似的增量，说明「知情选择」的贡献可能来自选择高检索率的 Skill，而非选择能形成依赖的 Skill。

这个实验的可行性在于：影子 Skill 的构造只需要修改 CoSA 候选的操作契约，保持文本表面特征不变。如果论文的机制主张成立，影子 Skill 的 ΔASR 应该显著低于 Full CoSA，接近随机候选选择的 43.40% 水平。

12. 落地判断

用于「抢占式 GPU 自托管 27B 模型做多智能体脚手架」这个场景，CoSA 的发现是直接相关的，但落地方式需要区分「攻击视角」和「防御视角」。

从攻击视角看，如果你的脚手架会从公开 Skill 仓库拉取 Skill 并让 Agent 自主组合，那么 CoSA 指出的风险是真实的：攻击者不需要提交恶意 Skill，只需要提交「恰好补上某个业务缺口」的正常 Skill，就可能诱导你的 Agent 在组合执行时违规。27B 模型的指令跟随能力弱于 GPT-5.6 这类大模型，论文数据显示 GPT-5.6 是最鲁棒的（增强后 ASR 29.86% 到 34.03%，ΔASR 8.33 到 14.58 个百分点），而其他模型的 ΔASR 在 17.71 到 34.72 个百分点之间。27B 模型大概率更接近后者，风险增量可能更高。

从防御视角看，CoSA-Guard 的思路可以迁移。在你的多智能体脚手架里，如果每个智能体有自己的工具集和 Skill 池，那么在「后果性动作」之前加一个 harness 层检查是可行的。具体做法：在外部化、持久状态变更、代码执行三类动作前，检查动作参数里的数据来源是否跨越了 Skill 边界，以及授权记录是否绑定到具体的动作、目标、用途。对于 27B 模型，不建议用同一个模型做 Guard 的模糊判断——论文用 GPT-5 解释模糊自然语言证据，27B 模型在这类任务上的可靠性存疑。更实际的做法是：先用确定性规则覆盖显式条件（授权 token 是否存在、接收者是否在允许列表里、动作类型是否匹配授权范围），只有规则无法判断时才调用模型，且模型输出只作为「请求人工确认」的触发信号，不作为自动放行依据。

成本量级：Guard 的额外推理开销取决于触发频率。如果只在后果性动作前调用，且大部分请求被确定性规则拦截或放行，额外 token 消耗应该控制在每次动作 500 到 2,000 token 以内。对于 27B 模型自托管，这个开销在单张 24GB 显卡上可以接受，但要注意 Guard 的推理会占用与主 Agent 相同的 GPU 资源，可能拉长任务完成时间。

最大的坑：Guard 的误报会直接破坏多智能体协作。论文报告 FBR 是 3.33%，但所有误报集中在 DeepSeek-V4 和 MiniMax-M3 两个模型上（各 6/72，8.33%）。如果你的 27B 模型在 Guard 的模糊判断上表现类似，误报率可能更高。多智能体场景中，一个智能体的动作被错误拦截可能导致整个协作链断裂。建议把 Guard 的默认策略设为「规则明确违规才 BLOCK，模糊情况 CONFIRM 而不是 BLOCK」，用人工确认代替自动拦截，牺牲一些自动化程度换取协作稳定性。