大模型Agent安全执行与监控成本实践指南

大模型的能力越强，它在系统中能做的事情就越多。一个能读代码、调用工具、连续执行多步任务的Agent，其风险已经从”回答错误”转向”执行错误”。传闻中的参数表和上下文长度数字无法验证，本文不把它们当作结论。下面只讨论企业架构中可以直接落地的做法。

一、工具调用必须由执行器本地校验

模型生成的计划不能当作可信指令。模型的输出可能受提示词注入影响，其中自带的风险等级字段也可能被篡改或误判。因此，执行器应当用本地的确定性规则判定风险，模型给出的标签只能作为参考。

常见的做法包括以下几项。

• 工具白名单：只执行已注册的工具名称，未注册的调用直接拒绝。
• 参数校验：对路径、域名、命令做前缀或正则匹配，拒绝越界访问。
• 高风险操作二次确认：写文件、对外发送请求、修改权限等动作，必须由人或独立的策略服务批准。
• 沙箱隔离：执行环境使用容器加强隔离，例如Kubernetes配合Kata Containers，并限制网络出口和文件系统范围。

下面是一个简化的执行拦截示例。模型输出在进入执行器前，应先经过结构校验，解析为固定字段的Action对象。

import re
from dataclasses import dataclass
from urllib.parse import urlparse
@dataclass
class Action:
    tool: str
    args: dict
class PolicyViolation(Exception):
    pass
# 规则由执行器本地维护，不读取模型输出中的任何风险字段
READ_ONLY_TOOLS = {"read_file", "run_tests", "http_get"}
WRITE_TOOLS = {"write_file", "http_post"}
NETWORK_TOOLS = {"http_get", "http_post"}
ALLOWED_HOSTS = {"api.internal.example.com"}
BLOCKED_PATTERNS = [
    re.compile(r"rm\s+-rf"),
    re.compile(r"curl[^|]*\|\s*(sh|bash)"),
    re.compile(r"/etc/(passwd|shadow)"),
]
def validate(action: Action) -> str:
    """返回本地判定的风险等级 'low' 或 'high'，违规则抛出异常。"""
    if action.tool not in READ_ONLY_TOOLS | WRITE_TOOLS:
        raise PolicyViolation(f"工具未注册: {action.tool}")
    text = " ".join(str(v) for v in action.args.values())
    for pattern in BLOCKED_PATTERNS:
        if pattern.search(text):
            raise PolicyViolation(f"命中禁止规则: {pattern.pattern}")
    if action.tool in NETWORK_TOOLS:
        host = urlparse(action.args.get("url", "")).hostname
        if host not in ALLOWED_HOSTS:
            raise PolicyViolation(f"域名不在白名单: {host}")
    return "high" if action.tool in WRITE_TOOLS else "low"
def run_plan(plan, execute, request_approval):
    results = []
    for action in plan:
        risk = validate(action)          # 违规直接抛出异常，计划终止
        if risk == "high" and not request_approval(action):
            results.append({"tool": action.tool, "status": "rejected"})
            break                        # 审批被拒绝后，停止后续步骤
        results.append(execute(action))
    return results

需要说明的是，正则黑名单只能拦截已知模式，攻击者可以用编码、拆分命令等方式绕过。因此它只是第一层过滤。真正的安全边界来自最小权限和沙箱：即使校验被绕过，Agent也无法访问白名单之外的资源。

二、把监控算力写进预算

旁路监控指的是独立于模型推理路径的审计服务。它检查每一次工具调用和关键输出，并记录结果。监控不是免费的，它会占用推理算力，也会增加响应延迟。

容量规划可以用下面的方式估算：

单次请求成本 = 推理成本 × (1 + 被监控请求比例 × 监控开销比例)

其中，监控开销比例必须用自己的业务负载压测得出，不能直接套用供应商的宣传数字。假设压测显示监控使被监控请求的算力增加20%，而其中只有30%的请求触发深度检查，那么整体成本的增幅约为6%。覆盖率和检查深度都会改变这个结果，所以预算表中要分别列出两者。

上线前建议核对以下检查清单。

1. 同步拦截路径的额外延迟有明确上限，例如P99增加不超过团队设定的阈值。超过阈值时，应切换为异步审计，并对高风险工具保持同步确认。
2. 每次工具调用都写入审计日志，至少包含以下字段：时间戳、请求ID、Agent ID、工具名称、参数哈希、命中的规则、判定结果、审批人、耗时。
3. 参数原文涉及敏感信息时只记录哈希或脱敏值，避免日志本身泄露数据。
4. 熔断策略采用失败关闭（fail closed）：监控服务超时或错误率超过阈值时，写操作和外部网络请求一律拒绝。只读操作可以降级为异步审计。
5. 监控服务与Agent服务分开部署和扩缩容，防止监控拖垮业务。
6. 每季度用历史日志复盘规则命中情况，清理误报，补充新的攻击模式。

三、参数规模不能直接代表能力

网传的参数数字常被拿来比较，但总参数量和模型能力之间没有简单的线性关系。混合专家（MoE）架构是主要原因。

MoE模型的总参数决定显存占用，激活参数决定单次推理的计算量。两者需要分开看。

指标	稠密模型（1T参数）	MoE模型（10T总参数，假设激活约1T）
单次推理计算量	约1T参数的计算量	约1T参数的计算量
显存需求	容纳1T参数即可	需要容纳全部10T参数
路由与通信开销	无专家路由	存在专家路由和跨卡通信

表中的10T和激活比例只是假设，用来说明比较方法。直接用总参数量比较两个模型，会同时忽略计算效率、部署成本和路由策略。

参数量也不能单独决定能力上限。训练数据的质量通常决定能力的下限，算法和训练方法（例如合成数据的使用、课程学习、对齐算法的效率）常常决定上限。把两个未经核实的参数数字相除，再推算能力倍数，在方法上站不住脚。

评测维度同样需要拆开看。一个模型在代码审计或网络安全任务上表现突出，并不意味着它在创意写作、多语言翻译、事实准确性或情感理解上有同样幅度的提升。大模型的能力分布很不均匀，选型时应按自己的业务任务做评测。

四、本文的事实依据与选型建议

本文不引用未经核实的具体数字，包括传闻中的参数规模、上下文长度、训练暂停时长和监控开销比例。这些数字在没有正式来源时，不应进入架构决策。

选型时，建议向供应商索取以下材料。

• 正式发布的系统卡（System Card）或技术报告，以及其中的评测方法说明。
• 安全评估结果，包括测试范围、测试条件和未覆盖的场景。
• 在与自身业务接近的负载下，启用与不启用监控时的延迟和算力对比数据。
• 服务等级协议（SLA）中关于延迟、可用性和数据留存的条款。

大模型应用的竞争重点已经从调用最新接口，转向工程能力本身。团队需要在Agent的自主性和业务风险之间找到平衡，把模型视为不完全可信的执行者，用本地校验、最小权限、沙箱和审计日志