同一个支付漏洞，可以只影响一笔测试交易，也可以在几分钟内扩散到所有商户。代码缺陷也许相同，事故规模却由系统边界、权限、发布方式和恢复能力共同决定。
这就是“架构即风险几何”最实际的含义：上一篇讨论一项主张需要哪些证据，本篇讨论证据仍然失败时，架构怎样改变失败的形状。
这些方法并非生成式 AI 的新发明。故障隔离、最小权限、零信任、灰度发布、可观测性和冗余都有长期工程历史。AI 生成提高变更吞吐、代理增加动态权限之后，它们会变得更重要，但不能被包装成一种突然诞生的黑箱架构。
风险几何不是装饰性比喻
如果“几何”只表示结构很复杂，它不会帮助设计。本文用四个可以追问的维度限制这个比喻：
| 维度 | 核心问题 | 常见控制 |
|---|---|---|
| 故障半径 | 一个错误能够影响多少用户、数据和服务？ | 分区、隔离、队列、租户边界 |
| 权限范围 | 出错组件能够读取、修改或调用什么？ | 最小权限、能力限制、零信任 |
| 暴露时间 | 多久能发现、停止并恢复？ | 监控、灰度、开关、回滚或前滚 |
| 失败相关性 | 多个防线会不会因同一原因一起失效？ | 独立实现、供应商分散、故障域设计 |
风险不等于四项简单相乘，这张表也不是精确公式。它是一套设计检查：如果无法降低缺陷出现的概率，能否至少缩小其可达范围、持续时间或共同失效概率？
隔离：让错误停在边界内
模块化只有落实到运行边界，才真正改变故障半径。目录分层可以提高可读性，却不能阻止一个进程读取所有数据。更强的隔离可能来自：
- 按租户或区域划分数据与计算；
- 用进程、容器或沙箱限制资源；
- 通过队列隔离生产者与消费者的瞬时故障；
- 给关键写操作设置独立服务与审批边界；
- 对代理生成和执行代码使用一次性环境。
隔离不是越多越好。边界会增加网络、运维和一致性成本，也可能把一个容易理解的单体切成难以排查的分布式系统。判断标准应当是风险和团队能力，而不是“微服务天然更安全”。
最小权限和零信任：限制错误能做什么
一个代码生成器只能提出补丁，和一个代理可以读取生产密钥、修改数据库并直接部署，是完全不同的风险系统。代理的推理能力没有改变，权限几何已经改变。
最小权限要求主体只获得完成当前任务所需的能力，并尽量限制时间和资源范围。零信任则反对仅因请求来自“内部网络”或组织自有设备就默认可信，强调围绕具体资源持续评估身份、设备和上下文。
这不等于每个函数调用都重新完成一套昂贵认证。NIST 把零信任描述为一组资源保护原则和部署模型，而不是单一产品。实际设计需要在会话、服务身份、授权缓存、性能与风险之间取舍。
对 AI 代理尤其应区分：
- 读代码与读生产数据；
- 创建分支与合并主干；
- 建议迁移与执行迁移；
- 查询日志与访问用户隐私；
- 在沙箱运行与在生产运行。
“需要工具权限”不能自动推出“需要全部权限”。权限越接近不可逆外部行动，人类批准、细粒度审计和速率限制就越重要。
渐进发布：不要一次暴露全部系统
生成代码并不会天然要求更频繁部署，但低成本变更容易增加发布次数和批量。架构应使每次变化先在有限范围内接受真实反馈：
- 影子流量只观察结果，不影响用户；
- 金丝雀发布先覆盖少量实例或用户；
- 特性开关把部署与启用分开；
- 分阶段迁移保留旧读写路径；
- 自动停止条件在关键指标恶化时阻断扩散。
渐进发布的关键不是“慢”，而是让新证据在风险仍小的时候出现。
回滚也不是万能按钮。无状态代码通常容易退回，数据库迁移、外部支付、消息发送和隐私泄漏却可能已经造成不可逆副作用。此时需要前滚修复、补偿事务、双写校验或人工处置。声称系统“可回滚”之前，应明确哪些状态可以恢复、恢复点在哪里、数据是否向后兼容。
可观测性：缩短未知持续的时间
日志、指标和追踪不会让系统获得“自我意识”。它们只是给人和自动控制器提供信号，而且信号可能缺失、延迟或误导。
有用的可观测性从问题出发：
- 用户是否真正完成关键操作？
- 错误集中在哪类请求、版本和租户？
- 延迟来自本服务还是依赖？
- 业务不变量是否被破坏？
- 模型或代理是否出现分布漂移和异常工具调用？
只收集海量日志会增加成本与隐私风险，并不保证更快发现事故。信号需要与服务目标、告警动作和负责人相连。无人响应的告警不是控制。
冗余与降级：防止一处失败成为全面失败
多副本、备用区域、降级路径和缓存可以吸收局部故障，但冗余只有在失败足够独立时才有效。两个实例使用同一错误配置，三个模型复用同一脆弱依赖，都会一起失败。
AI 生成还可能增加相关性风险：多个团队接受同一模型偏好的库、鉴权模式或错误处理，表面上存在多份实现，实际上共享同一种缺陷。重要防线应尽量使用独立检查方法，例如让安全策略由确定性规则执行，而不是让生成模型判断自己是否越权。
降级同样需要业务选择。推荐系统失败可以退回热门列表，支付授权失败却不能默认为允许。架构韧性不是“永远可用”，而是事先决定哪些能力可以牺牲、哪些底线不能跨越。
一个具体例子：代码代理修改结算服务
假设代理要优化结算任务：
- 它在隔离分支和临时环境中工作，不能直接访问生产数据。
- 访问令牌只允许读取必要仓库和创建待审查变更。
- 契约测试、账本不变量和安全扫描作为合并门槛。
- 发布先进入一个内部商户和少量影子任务。
- 对账差异、重复支付、延迟和失败率触发自动停止。
- 数据迁移采用向后兼容步骤，并预先演练补偿与恢复。
- 人类负责人决定是否扩大范围，并对结果承担组织责任。
这里没有哪一层要求团队理解所有依赖，也没有哪一层允许团队完全不看代码。控制来自多重边界共同缩小风险，而不是来自一句“测试通过”。
结语：架构管理的是失败的可达性
完美实现从来不是可靠系统的充分条件，容错也不是放弃正确实现的借口。成熟架构同时降低错误概率和错误后果。
“风险几何”的价值，是把抽象的黑箱焦虑转成四个具体问题：错误能走多远，拥有多大权限，多久会被发现，以及防线是否会一起倒下。只要这些问题能被测量、演练和问责，几何就不再只是漂亮比喻。