黑箱转向（五）：架构即风险几何

Lingming — Tue, 03 Mar 2026 15:02:24 -0500

同一个支付漏洞，可以只影响一笔测试交易，也可以在几分钟内扩散到所有商户。代码缺陷也许相同，事故规模却由系统边界、权限、发布方式和恢复能力共同决定。

这就是“架构即风险几何”最实际的含义：上一篇讨论一项主张需要哪些证据，本篇讨论证据仍然失败时，架构怎样改变失败的形状。

这些方法并非生成式 AI 的新发明。故障隔离、最小权限、零信任、灰度发布、可观测性和冗余都有长期工程历史。AI 生成提高变更吞吐、代理增加动态权限之后，它们会变得更重要，但不能被包装成一种突然诞生的黑箱架构。

风险几何不是装饰性比喻

如果“几何”只表示结构很复杂，它不会帮助设计。本文用四个可以追问的维度限制这个比喻：

维度	核心问题	常见控制
故障半径	一个错误能够影响多少用户、数据和服务？	分区、隔离、队列、租户边界
权限范围	出错组件能够读取、修改或调用什么？	最小权限、能力限制、零信任
暴露时间	多久能发现、停止并恢复？	监控、灰度、开关、回滚或前滚
失败相关性	多个防线会不会因同一原因一起失效？	独立实现、供应商分散、故障域设计

风险不等于四项简单相乘，这张表也不是精确公式。它是一套设计检查：如果无法降低缺陷出现的概率，能否至少缩小其可达范围、持续时间或共同失效概率？

隔离：让错误停在边界内

模块化只有落实到运行边界，才真正改变故障半径。目录分层可以提高可读性，却不能阻止一个进程读取所有数据。更强的隔离可能来自：

按租户或区域划分数据与计算；
用进程、容器或沙箱限制资源；
通过队列隔离生产者与消费者的瞬时故障；
给关键写操作设置独立服务与审批边界；
对代理生成和执行代码使用一次性环境。

隔离不是越多越好。边界会增加网络、运维和一致性成本，也可能把一个容易理解的单体切成难以排查的分布式系统。判断标准应当是风险和团队能力，而不是“微服务天然更安全”。

最小权限和零信任：限制错误能做什么

一个代码生成器只能提出补丁，和一个代理可以读取生产密钥、修改数据库并直接部署，是完全不同的风险系统。代理的推理能力没有改变，权限几何已经改变。

最小权限要求主体只获得完成当前任务所需的能力，并尽量限制时间和资源范围。零信任则反对仅因请求来自“内部网络”或组织自有设备就默认可信，强调围绕具体资源持续评估身份、设备和上下文。

这不等于每个函数调用都重新完成一套昂贵认证。NIST 把零信任描述为一组资源保护原则和部署模型，而不是单一产品。实际设计需要在会话、服务身份、授权缓存、性能与风险之间取舍。

对 AI 代理尤其应区分：

读代码与读生产数据；
创建分支与合并主干；
建议迁移与执行迁移；
查询日志与访问用户隐私；
在沙箱运行与在生产运行。

“需要工具权限”不能自动推出“需要全部权限”。权限越接近不可逆外部行动，人类批准、细粒度审计和速率限制就越重要。

渐进发布：不要一次暴露全部系统

生成代码并不会天然要求更频繁部署，但低成本变更容易增加发布次数和批量。架构应使每次变化先在有限范围内接受真实反馈：

影子流量只观察结果，不影响用户；
金丝雀发布先覆盖少量实例或用户；
特性开关把部署与启用分开；
分阶段迁移保留旧读写路径；
自动停止条件在关键指标恶化时阻断扩散。

渐进发布的关键不是“慢”，而是让新证据在风险仍小的时候出现。

回滚也不是万能按钮。无状态代码通常容易退回，数据库迁移、外部支付、消息发送和隐私泄漏却可能已经造成不可逆副作用。此时需要前滚修复、补偿事务、双写校验或人工处置。声称系统“可回滚”之前，应明确哪些状态可以恢复、恢复点在哪里、数据是否向后兼容。

可观测性：缩短未知持续的时间

日志、指标和追踪不会让系统获得“自我意识”。它们只是给人和自动控制器提供信号，而且信号可能缺失、延迟或误导。

有用的可观测性从问题出发：

用户是否真正完成关键操作？
错误集中在哪类请求、版本和租户？
延迟来自本服务还是依赖？
业务不变量是否被破坏？
模型或代理是否出现分布漂移和异常工具调用？

只收集海量日志会增加成本与隐私风险，并不保证更快发现事故。信号需要与服务目标、告警动作和负责人相连。无人响应的告警不是控制。

冗余与降级：防止一处失败成为全面失败

多副本、备用区域、降级路径和缓存可以吸收局部故障，但冗余只有在失败足够独立时才有效。两个实例使用同一错误配置，三个模型复用同一脆弱依赖，都会一起失败。

AI 生成还可能增加相关性风险：多个团队接受同一模型偏好的库、鉴权模式或错误处理，表面上存在多份实现，实际上共享同一种缺陷。重要防线应尽量使用独立检查方法，例如让安全策略由确定性规则执行，而不是让生成模型判断自己是否越权。

降级同样需要业务选择。推荐系统失败可以退回热门列表，支付授权失败却不能默认为允许。架构韧性不是“永远可用”，而是事先决定哪些能力可以牺牲、哪些底线不能跨越。

一个具体例子：代码代理修改结算服务

假设代理要优化结算任务：

它在隔离分支和临时环境中工作，不能直接访问生产数据。
访问令牌只允许读取必要仓库和创建待审查变更。
契约测试、账本不变量和安全扫描作为合并门槛。
发布先进入一个内部商户和少量影子任务。
对账差异、重复支付、延迟和失败率触发自动停止。
数据迁移采用向后兼容步骤，并预先演练补偿与恢复。
人类负责人决定是否扩大范围，并对结果承担组织责任。

这里没有哪一层要求团队理解所有依赖，也没有哪一层允许团队完全不看代码。控制来自多重边界共同缩小风险，而不是来自一句“测试通过”。

结语：架构管理的是失败的可达性

完美实现从来不是可靠系统的充分条件，容错也不是放弃正确实现的借口。成熟架构同时降低错误概率和错误后果。

“风险几何”的价值，是把抽象的黑箱焦虑转成四个具体问题：错误能走多远，拥有多大权限，多久会被发现，以及防线是否会一起倒下。只要这些问题能被测量、演练和问责，几何就不再只是漂亮比喻。

延伸阅读与参考资料

上一篇：《黑箱转向（四）：控制不可读之物，需要哪些证据》；下一篇：《黑箱转向（六）：从编码者到约束设计者？》。

零信任 on Lingming 灵明