AI 底层逻辑 / 经典论文
AI Architecture Fitness Functions：持续架构治理
AI Architecture Fitness Function 是一条可执行的架构约束: 它把“系统应该持续满足的质量、风险、成本或治理要求”转成测试、门禁、监控、阈值、证据查询和复核节奏。
290 行ai-foundations/papers/88-ai-architecture-fitness-functions-continuous-governance.md
AI Architecture Fitness Functions / Continuous Governance 解读
配对阅读：本篇的操作手册版（模板/RACI/门禁/runbook）是
docs/AI_ARCHITECTURE_FITNESS_FUNCTIONS_CONTINUOUS_GOVERNANCE_PLAYBOOK.md。第一遍读本篇建立原理与架构判断；第二遍做案例时再用 playbook 查表落地，两者不需要重复精读。
核心问题: AI 架构不能只在立项和上线前评审一次。模型、数据、prompt、工具、策略、成本和用户行为都会变化, 所以架构治理必须从“会议评审”升级为持续可检查的 architecture fitness functions。
Source Anchors
| Source | Link | 用途 |
|---|---|---|
| NIST AI RMF | https://www.nist.gov/itl/ai-risk-management-framework | 将 AI 风险管理拆成治理、映射、测量、管理活动, 支撑 fitness function 的风险闭环（AI RMF 1.0: 2023-01；GenAI Profile NIST AI 600-1: 2024-07） |
| ISO/IEC 42001 | https://www.iso.org/standard/81230.html | 参考 AI management system、持续改进、管理责任和控制体系（标准发布: 2023-12） |
| OpenTelemetry | https://opentelemetry.io/docs/ | 用 trace、metrics、logs 支撑 runtime fitness functions 和 SLO 观测（访问日期: 2026-07-01） |
| OpenAPI Specification | https://spec.openapis.org/oas/latest.html | 为 API/tool contract fitness checks 提供结构化契约锚点（访问日期: 2026-07-01） |
| JSON Schema | https://json-schema.org/ | 为结构化输出、工具参数、事件 payload 和 contract testing 提供 schema 锚点（访问日期: 2026-07-01） |
核心导读
AI Architecture Fitness Function 是一条可执行的架构约束: 它把“系统应该持续满足的质量、风险、成本或治理要求”转成测试、门禁、监控、阈值、证据查询和复核节奏。
传统架构评审常把图、文档和批准记录冻结在上线前; AI 系统上线后却会继续变化。模型版本、prompt、知识源、工具契约、攻击方式、用户行为、成本结构都会漂移。持续治理的目标不是增加审批层级, 而是让架构意图在 CI/CD、release gate、runtime telemetry 和周期复核中持续被验证。
Fitness function 的成熟度体现在三点: 约束能否执行, 结果能否产生证据, 例外能否被限时管理。
问题定义
传统路径通常是:
architecture review -> launch approval -> production drift
AI 系统更容易漂移, 因为变化源比传统软件多:
| 漂移来源 | 对架构治理的影响 |
|---|---|
| Model version | 同一 prompt 在新模型上可能出现质量、安全、成本变化 |
| Prompt / system instruction | 小改动可能改变拒答、引用、工具选择和语气 |
| RAG source | 文档更新、权限变化、chunking 调整会改变答案 |
| Tool contract | API 字段、错误语义、副作用、审批规则变化会破坏 agent workflow |
| User behavior | 用户会把系统用于设计之外的任务或对抗式输入 |
| Cost / latency | 上下文长度、模型路由、流量结构会改变 unit economics |
| Security attack | prompt injection、data exfiltration、tool misuse 的方式会演进 |
| Human operation | 人工 override、review backlog、例外审批会形成新的风险 |
因此 AI 架构治理要变成闭环:
architecture intent
-> fitness function
-> build/release/runtime check
-> evidence capture
-> exception/remediation
-> architecture decision update
架构师关注的不是“是否通过一次评审”, 而是“系统是否持续满足被批准的架构意图”。
架构模型/核心原理
Fitness function 的基本结构
一条可执行的 fitness function 至少包含:
| 字段 | 说明 |
|---|---|
| Intent | 保护的质量属性、风险边界、产品目标或治理要求 |
| Scope | 适用于哪个 use case、服务、组件、路径、渠道或风险等级 |
| Measurement | 用测试、指标、查询、人工抽样或组合方式判断 |
| Threshold | 通过、警告、阻断、复核的标准 |
| Execution point | PR、CI、release gate、runtime、daily batch、quarterly review |
| Owner | 负责解释结果和推动修复的业务、架构、平台、风险或运营 owner |
| Evidence | 结果存在哪里, 如何进入 release bundle 或 audit binder |
| Exception rule | 例外如何申请、审批、过期、补偿和复查 |
| Remediation | 失败后应调整的 source、prompt、retriever、policy、tool、workflow 或 ADR |
示例:
| Fitness function | Execution | Threshold | Evidence |
|---|---|---|---|
| Customer-facing RAG 引用必须来自 approved source | release eval + runtime sampling | unapproved citation = hard stop | eval report、trace sample |
| 高风险 tool call 必须有 approval id | contract test + runtime policy | missing approval id = block | tool gateway logs |
| Prompt 变更必须关联 regression eval | CI gate | no eval run = block merge | PR evidence、eval run id |
| P95 latency 不超过 3 秒 | runtime SLO | 7 天滚动违反触发 architecture review | SLO dashboard |
| 每 case 模型成本不超过预算 | runtime FinOps | 超预算 20% 触发 routing review | cost ledger |
Fitness function 可以实现为测试, 但不等同于测试。测试是执行形式之一; fitness function 表达的是架构意图和可接受边界。
生命周期模型
Concern
-> quality/risk statement
-> fitness function spec
-> implementation as test/gate/monitor/query
-> evidence capture
-> exception/remediation
-> ADR and architecture review update
| 阶段 | 应定义或执行的 fitness functions |
|---|---|
| Discovery / Design | risk tier、quality attributes、policy boundary、human oversight、eval coverage、初始 SLO、unit cost budget |
| Build / CI | schema validation、prompt regression、retrieval permission tests、red-team tests、ADR link check、contract compatibility |
| Release Gate | golden set eval、segment eval、tool trajectory eval、control coverage、evidence completeness、rollback readiness |
| Runtime | trace completeness、latency/cost SLO、policy violation rate、human override rate、citation sampling、drift alerts |
| Quarterly Review | residual risk、exception aging、tech debt、new usage pattern、platform reuse、value realization |
这套模型把 NIST AI RMF 的治理、测量、管理活动和 ISO/IEC 42001 的持续改进思想落到工程执行点。
关键机制
AI fitness taxonomy
| 类别 | 典型 concern | Fitness function 示例 |
|---|---|---|
| Quality | groundedness、citation correctness、task success、regression、segment quality | regulated answer unsupported claim = 0; 新 prompt 不得低于 baseline |
| Safety / Risk | advice boundary、high-impact decision、human oversight、kill switch、incident readiness | AI 不得直接做拒贷、冻结、赔付; 高风险 case 必须进入 HITL |
| Security | prompt injection、tool authorization、data exfiltration、contract validation、audit trail | tool call 必须通过 policy engine; restricted context 不得发送到未批准模型 |
| Privacy / Data | PII handling、retention、permission filtering、lineage、data minimization | retrieval 前必须执行权限过滤; trace 中敏感字段必须 redaction |
| Cost / Latency | unit economics、P95/P99、routing efficiency、context budget、capacity | 简单任务使用小模型或 cache; 平均 input token 不随文档增长失控 |
| Evidence / Governance | release evidence、control coverage、trace completeness、exception hygiene、management review | material risk 至少映射一个 control 和一个 test; trace span 覆盖率达标 |
成熟治理不是所有系统套同一套规则, 而是按 use case risk tier 决定 fitness depth。低风险内部助手可以轻量, customer-facing 或 high-impact 场景必须有更强门禁和证据。
Gate matrix
| Gate | 必要检查 |
|---|---|
| G0 Idea intake | business outcome、risk tier、data boundary 已识别 |
| G1 Discovery | quality attributes、risk statement、initial eval contract 已草拟 |
| G2 Architecture review | C4 views、threat model、control map、ADR present |
| G3 Pilot build | schema/tool contracts、telemetry hooks、eval harness ready |
| G4 Pilot launch | baseline eval pass、HITL/runbook ready、trace completeness pass |
| G5 Release | regression eval、risk signoff、rollback、evidence bundle complete |
| G6 Scale | cost/SLO stable、adoption value proven、incident response tested |
| G7 Quarterly review | drift、exceptions、residual risk、tech debt、value realization reviewed |
Gate 不应只是人工 checklist。每个 gate 至少应有一部分由测试、查询、dashboard 或 evidence rule 自动检查。
Exception management
没有例外机制, fitness function 会变成僵硬流程; 没有期限和补偿控制, 例外会变成治理漏洞。
| Exception field | 必须说明 |
|---|---|
| Fitness function | 哪条约束未满足 |
| Business reason | 为什么需要例外, 不例外会影响什么 |
| Risk impact | 影响哪些 concern、用户、流程或控制 |
| Compensating control | 临时控制, 如人工复核、限流、只内部使用 |
| Expiry | 明确过期日期 |
| Owner | 业务 owner 和风险 owner |
| Evidence | 批准记录、监控结果、补救计划 |
| Exit condition | 什么时候恢复正常门槛 |
例外不是绕过架构治理, 而是把 tradeoff 暴露、限时、可复查。
产品价值和架构健康的联合指标
Fitness functions 不能只服务合规, 也要服务 AI 产品价值。
| Metric | 判断意义 |
|---|---|
| Time-to-safe-release | 从 idea 到满足关键 fitness functions 的时间 |
| Fitness pass rate | 每个 gate 首次通过率 |
| Regression catch rate | 上线前被 fitness functions 捕获的问题比例 |
| Production escape rate | 上线后才暴露的架构/控制问题比例 |
| Exception aging | 例外平均存活时间 |
| Cost per controlled outcome | 单个合规成功业务结果的成本 |
| Control evidence completeness | 关键控制证据完整率 |
| Fitness maintenance load | 维护测试、阈值、dashboard 的成本 |
| Adoption with control | 采用率是否在质量和风险边界内增长 |
如果 adoption 低但 fitness 全绿, 系统可能“可控但无价值”。如果 adoption 高但 exception 激增, 系统可能“有需求但架构承压”。
证据与控制
Fitness function 的输出要进入 evidence binder, 才能支撑 release、scale、audit 和 incident review。
| Control area | Fitness evidence |
|---|---|
| Eval quality | eval run id、dataset version、metric、threshold、failure analysis、signoff |
| Tool governance | OpenAPI/JSON Schema validation、policy decision、approval id、idempotency result |
| Data governance | source allowlist、retrieval permission test、lineage report、retention audit |
| Runtime observability | OpenTelemetry trace completeness、span coverage、SLO dashboard、cost ledger |
| Risk management | control coverage map、red-team report、exception memo、residual risk decision |
| Release governance | ADR、rollback plan、runbook、risk approval、evidence bundle completeness |
一条高质量的 fitness function 应能回答:
What intent does it protect?
Where does it execute?
What threshold decides pass/warn/block?
Who owns remediation?
What evidence proves execution?
What exception can temporarily override it?
Runtime 侧尤其要避免“上线前全绿、线上无证据”。关键 span 应带 use case、risk tier、prompt version、model route、source version、tool contract version、policy decision、approval id、cost、latency、outcome 等标签。
AI产品/金融零售场景
Payment dispute agent
场景: AI agent 帮助运营人员处理银行卡争议。它可以读取交易、政策、历史 case, 生成下一步建议和草稿, 但不能自动退款或直接通知客户。
| ID | Fitness function | Execution | Threshold |
|---|---|---|---|
| AFF-PD-001 | Agent 不得直接执行退款 | runtime tool policy | refund tool unavailable to agent |
| AFF-PD-002 | Case recommendation 必须引用政策和交易证据 | eval + runtime sample | missing evidence < 2% |
| AFF-PD-003 | 高金额 case 必须人工复核 | workflow gate | bypass = 0 |
| AFF-PD-004 | Tool call 参数必须符合 schema | CI + runtime | invalid payload blocked |
| AFF-PD-005 | P95 case triage latency 不超过 5 秒 | runtime SLO | 7 天滚动达标 |
| AFF-PD-006 | Agent 建议被人工 override 比例持续上升触发 review | ops monitor | 2 周上升超过 30% |
| AFF-PD-007 | prompt/model/tool 变更必须跑 regression eval | CI gate | missing run blocks release |
| AFF-PD-008 | Evidence bundle 包含 ADR、eval、approval、trace sample | release gate | completeness = 100% |
Architecture fitness dashboard:
| Panel | Signals |
|---|---|
| Quality | recommendation acceptance、evidence support、override reasons |
| Safety | blocked tool actions、HITL bypass、policy exceptions |
| Security | prompt injection attempts、unauthorized tool attempts |
| Cost / Latency | cost per case、model route distribution、P95 latency |
| Operations | incident count、review backlog、failed spans |
| Evidence | release bundle completeness、exception aging |
架构决策和 fitness functions 应互相连接:
| ADR | 关联的 fitness concern |
|---|---|
| Use tool gateway for all case system access | schema validation、authorization、audit trail |
| Keep refund action human-only | high-risk action boundary、HITL |
| Require policy citation in recommendations | groundedness、evidence completeness |
| Stage release from internal pilot to limited region | risk-tiered gates、runtime learning |
这个场景的关键不是让 agent 更“聪明”, 而是让它在受控边界内稳定创造运营价值。
反模式
| 反模式 | 表现 | 修正 |
|---|---|---|
| Checklist theater | 人工勾选很多项, 没有测试或证据 | 把关键项转成自动测试、查询或 dashboard |
| Accuracy monoculture | 只看准确率, 不看工具、隐私、安全、HITL、成本 | 建立 multi-dimensional taxonomy |
| Release-only governance | 上线前通过, 线上漂移无人发现 | 增加 runtime telemetry、sampling、periodic review |
| Threshold without owner | 有阈值但无人负责解释和修复 | 每条 function 指定 owner 和 remediation path |
| Over-gating | 低风险实验也套高风险流程 | 按 risk tier 设计 gates |
| Exception without expiry | 例外长期存在 | exception 必须有 expiry、compensating control、exit condition |
| Evidence as attachment | 证据只是散落附件 | 结构化 evidence object 和 binder |
| No value signal | 所有控制达标但业务没有采用 | 把 adoption、cycle time、unit economics 纳入 fitness review |
最终心智模型
AI 架构持续治理可以压缩成一条链:
Architecture intent
-> executable constraint
-> evidence-producing check
-> exception/remediation loop
-> architecture evolution
设计 fitness functions 时, 始终追问五件事:
| 问题 | 判断标准 |
|---|---|
| 它保护什么 | 质量属性、风险边界、成本目标、运营韧性或产品价值是否明确 |
| 它在哪里执行 | CI、release、runtime、batch review、季度复核是否合适 |
| 它如何判定 | metric、threshold、hard stop、warning、review trigger 是否可解释 |
| 它如何产生证据 | eval report、trace、dashboard、approval、control log 是否可查询 |
| 它失败后怎么办 | owner、remediation、exception、rollback、ADR update 是否明确 |
成熟的 AI 组织不会把架构治理寄托在一次评审会, 而会把关键架构意图变成持续运行的检查系统。Fitness functions 就是这套系统的最小执行单元。
SOTA 检查 (2026-07-01)
- 标准锚点仍现役且在扩展, 本篇主线成立: NIST AI RMF 1.0 (2023-01) + Generative AI Profile NIST AI 600-1 (2024-07) 仍是美国侧主参考, 且 NIST 于 2026-04 发布了关键基础设施 AI RMF Profile 的 concept note, RMF 1.1 增补与 SP 800-53 AI control overlays 预计 2026 年内陆续落地——"风险管理要落到可执行控制点"的方向与本篇 fitness function 闭环一致, 未被替代。
- ISO 侧从"管理体系"扩展到"影响评估": ISO/IEC 42001:2023 (2023-12) 之外, ISO/IEC 42005:2025 (2025-04 发布, 部分来源标注 2025-05) 补上了 AI system impact assessment 的方法论, 其 Annex A 显式映射回 42001——对应本篇 G0-G2 阶段的 risk tier / risk statement 定义活动, 可直接作为 Discovery 段 fitness function 的输入。42001 认证在 B2B AI 供应商侧正成为类 SOC 2 的准入基线, 但截至 2025-01 全球获证 AI 公司仍是两位数, 采用尚早期。
- 监管时间线更新 (务必用新时间线): EU AI Act GPAI 义务已于 2025-08-02 生效, 欧盟委员会执法自 2026-08-02 开始; 而 Annex III 高风险系统义务经 Digital Omnibus (2026-05-07) 推迟至 2027-12-02。本篇按 risk tier 分层设计 gate 的做法正好是应对这种"分阶段生效"合规节奏的正确姿势。
- Runtime 观测层有了事实标准但尚未 stable: 本篇要求的 trace 标签 (model route、token/cost、tool call、policy decision) 正在被 OpenTelemetry GenAI semantic conventions (
gen_ai.*, GenAI SIG 自 2024-04 起制定) 标准化——截至 2026-03 仍为 Development/experimental 状态, semconv v1.36 起需用OTEL_SEMCONV_STABILITY_OPT_IN=gen_ai_latest_experimental切换新属性格式, Datadog 等厂商已在 OTel v1.37 提供原生支持。落地本篇 runtime fitness functions 时应直接采用gen_ai.request.model/gen_ai.usage.input_tokens等约定属性名, 而不是自造标签。 - Fitness function 思想本身在向 AI 治理迁移: 2026 年社区的新动向是用 MCP 作为治理意图与实现之间的防腐层、以及用生成式模型把声明式架构约束编译成 CI/CD 中的具体 fitness functions (Thoughtworks 播客与 O'Reilly《Building Evolutionary Architectures》第二版 (2022-12) 一脉相承)。这印证本篇的框架性结论——"意图→可执行约束→证据→例外→架构演进"的闭环、gate matrix、exception 限时管理、按 risk tier 分层——是不随模型/平台版本过时的部分; 会过时的是具体属性名、阈值示例和监管日期。
- 库内实践对照: 本篇 CI gate 段的可运行实现见
docs/aipa/day19-blocking-ci-eval-gate.md(AIPA-120, 2026-06 完成), 操作手册版见docs/AI_ARCHITECTURE_FITNESS_FUNCTIONS_CONTINUOUS_GOVERNANCE_PLAYBOOK.md。