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