边界生效的前提:先问它圈住了哪些动作

📅 发布时间:2026/10/3 13:00:34
边界生效的前提:先问它圈住了哪些动作
前几篇发出去以后有人问了三个问题。看起来毫不相干- tool 是 AI 行动的正确单位吗- 你不知道存在的路径怎么监控- 大坝闸门、裂变堆的安全系统、自动驾驶撞人——这些你怎么办三个问题我都答不完整。但它们其实在问同一件事**你这道边界到底圈住了哪些动作。**先说结论这个问题的答案比「检查够不够严」重要得多。## 一、加强度是自然反应边界被质疑的时候第一反应都是加码。加规则、加确认、加审计、把检查写得更细。这些都有用。但都只在**已经被圈住的动作**上生效。举个最小对比- 删数据——有名字delete_customer、有风险级R5、策略能把它阻断- 屏幕点击——**没有名字**第二件事你没法设卡不是因为策略不够严是因为**没有东西可以挂**。所以顺序应该是先穷举再加码。## 二、可枚举是前提门禁要设卡得有三样东西**一个名字、一组参数、一个风险级**。离散的动作面三样都有。函数调用、MCP 工具、OpenAPI 端点——每个都有名字、有参数、能定级。有了这三样才谈得上风险分级、人工确认、审计留痕、事后撤销。前几篇讲的所有东西都建立在这三样之上。非离散的动作面三样都没有。computer-use 的 agent 在点屏幕带 shell 的 agent 在敲命令长期自主的 agent 留下的是一整条轨迹——这些动作没有名字。你没法说「它属于 R 几」也就没法在任何一层设卡。不是策略不够严。是**没有挂载点**。## 三、我们站在哪三种动作面状态不一样| 动作面 | 可枚举 | 边界能做什么 | 我们的状态 ||---|---|---|---|| 工具调用MCP / OpenAPI / 函数调用 | 是 | 挂风险级、绑确认、审计、撤销 | 已实现 || 非离散动作面computer-use / shell / 长期轨迹 | 否 | **没有挂载点** | **没有实现也不在范围内** || 物理执行器闸门 / 反应堆 / 车辆 | — | 不在业务运行时 | 属另一个安全体系 |中间这行得说清楚因为它是**范围声明不是待办**。我们做的是「AI 调用业务系统」这件事——动作面是工具调用所以可枚举。非离散的动作面我们不打算覆盖。写在这里是为了让人知道这道边界到哪儿为止而不是让人以为它能无限延伸。后果也一并说透**如果你把 agent 接上 shell这道边界对它是零。**不是变弱是不存在。第三行顺便提一句因为它被问到过。大坝闸门、反应堆安全系统、自动驾驶——那不是业务运行时的活儿。它们属于工业功能安全那套体系有自己的标准和自己的方法。拿一个企业应用的治理层去回答那个问题是答错了卷子。## 四、一个可以自己做的检验与其问「我的治理有多强」不如先问一个更基础的问题**你能列出这个 agent 能做的全部动作吗**能列出来——有清单、有名字、每条都能说清是什么——那就可以往下走定风险级、绑确认、加审计。前几篇讲的那套才有意义。列不出来先别加规则。**你说不出名字的那类动作就在边界外。**边界外发生的事再严的规则也管不到。清单越短、越穷尽边界越实。列不全的时候加码只是让清单内的部分更严——不会让清单外的部分变得可控。## 结语回到开头那三个问题。我到现在也没法给出完整答案。但有个想法比答案实用**边界不是画出来的是列出来的。**你圈住的动作就是那份清单。清单之外没有边界。