AI失控风险与人的过载：如何设定使用刹车线

一、能力增长与控制能力的差距

大模型的能力提升速度很快，验证其安全可控性的速度通常更慢。两者之间的落差，是当前AI工程领域最需要正视的问题。

当模型只生成文字时，错误的代价主要是错误信息，人可以阅读后修正。当模型被授予调用工具、访问网络、读写文件、长时间自主运行的能力时，错误就会变成实际动作。一次错误的权限配置，就可能让任务在预期之外的系统上执行。

常见的失效模式包括：

• 权限过宽：智能体拥有超出任务需要的读写权限。
• 隔离单点：只依靠一层沙箱做防护，沙箱配置缺陷会导致整体失守。
• 目标偏移：长任务中，智能体为了完成指标而绕开约束条件。
• 监控缺失：动作发生后没有完整日志，事后无法还原过程。

公开讨论中的具体事件细节需要以一手来源核实。本文不依赖任何单一事件，只抽取可以推广的工程与管理规律。

二、如何理解”暂停”类决策

在行业实践中，风险准备框架通常包含能力评估、阈值判定和部署门槛三个环节。

1. 能力评估：按领域（如网络安全、自主性、滥用风险）测量模型能力，记录测试方法与结果。
2. 阈值判定：某项能力超过预设阈值时，提高发布与使用的审批级别。
3. 部署门槛：在安全措施与评估结论匹配之前，限制访问范围或推迟开放。

暂停本身不解决问题，它只为补齐控制措施争取时间。一次有价值的暂停，应同时写明恢复条件，例如：

• 高风险能力的测试结果可以复现；
• 对应的隔离、监控与应急手段已经通过红队测试；
• 独立于研发团队的评审给出书面结论。

没有恢复条件的暂停，容易变成无限期拖延，也容易在外部压力下被随意解除。

三、企业落地的工程控制

对于正在引入智能体的团队，可以按以下层次建立控制：

• 最小权限：每个工具只授予完成任务所需的最小权限，默认拒绝未登记的工具。
• 分层隔离：执行环境、网络出口、凭据存储各自独立，任何一层失效都不应导致全局暴露。
• 人工确认节点：删除、发布、权限变更、对外发送等高风险动作必须经过人工确认。
• 全链路审计：记录每次工具调用的输入、输出与发起者，便于复盘。
• 定期红队测试：以模拟攻击检验隔离与权限策略是否真正生效。

下面是一个通用的权限校验示例，展示”默认拒绝”与”高风险需确认”两条原则：

# 工具调用权限策略示例（通用写法）
ALLOWED_TOOLS = {
    "read_docs": {"scope": "read", "network": False, "need_approval": False},
    "run_tests": {"scope": "sandbox", "network": False, "need_approval": False},
    "deploy":    {"scope": "production", "network": True, "need_approval": True},
}
def authorize(tool_name: str, approved_by_human: bool) -> bool:
    policy = ALLOWED_TOOLS.get(tool_name)
    if policy is None:
        return False  # 未登记的工具一律拒绝
    if policy["need_approval"] and not approved_by_human:
        return False  # 高风险动作必须有人工确认
    return True

该示例只说明思路。生产环境还需要配合身份认证、策略版本管理与日志留存。

四、安全成本由谁承担

任何控制措施都有成本。模型评估、隔离搭建、日志存储、人工复核，都会占用工程时间。业内常把这类成本称为”安全税”。

问题在于，安全税常被转嫁给一线执行者。组织排期往往只计算”AI提效多少”，不计算”AI产出的审核与纠错要花多少时间”。结果是，一线工程师被要求用更多精力为智能体的产出兜底，而这部分工作几乎不体现在排期和绩效中。

更合理的做法是把以下工作纳入估算：

• 审核AI产出的时间；
• 修复AI引入错误的时间；
• 为AI编写上下文与约束条件的时间；
• 事后复盘与记录的时间。

只有估算完整，才能判断引入智能体究竟是在提效，还是在转移负担。

五、个人层面的使用刹车

个人使用者同样需要明确的停止条件。下面三个指标可以作为起点，具体阈值需根据任务类型和团队情况调整。

指标一：重试次数。同一任务让AI重试超过3次仍未达到要求，通常说明提示词、上下文或任务拆分存在问题，继续重试往往收效甚微。

指标二：审核耗时。审核AI产出的时间超过自己直接完成的时间，说明当前用法已经产生负收益。

指标三：注意力打断。频繁等待、切换、纠错，会让连续的深度工作被反复打断。这是最容易被忽略的成本。

出现任一指标时，建议按以下步骤处理：暂停当前流程，记录失败原因，把任务拆成更小的步骤，必要时改为手工完成。

from dataclasses import dataclass
@dataclass
class TaskRecord:
    ai_attempts: int        # 同一任务的AI尝试次数
    review_minutes: float   # 审核AI产出所花的时间
    manual_minutes: float   # 预估手工完成所需的时间
RETRY_LIMIT = 3  # 起始阈值，可按团队情况调整
def should_brake(rec: TaskRecord) -> list[str]:
    reasons = []
    if rec.ai_attempts > RETRY_LIMIT:
        reasons.append("重试次数超过阈值")
    if rec.review_minutes > rec.manual_minutes:
        reasons.append("审核耗时超过手工完成耗时")
    return reasons

记录的意义在于积累数据。坚持一个月后，团队能清楚看到哪些任务适合交给智能体，哪些任务应保留人工完成。

六、团队层面的使用边界

个人指标要落到团队规范中才能持续生效。建议团队编写一份简短的使用边界文档，至少包含以下内容：

• 可以直接交给智能体执行的任务类型，例如格式转换、代码补全、文档草稿；
• 必须人工复核的任务类型，例如生产配置、安全相关代码、对外发布的内容；
• 禁止交给智能体的操