AI热榜 通过一个个看似合理的变更——它们虽然能通过所有既定规则的检验，但其实现却在悄无声息地偏离团队原本认为已经加以保护的设计意图。
从历史经验来看，解决之道是人工审查。
问题在于，人工审查无法扩展到每个拉取请求、每个契约变更、每个工作流跟踪，或是每个智能体生成的补丁。
图 1.
确定性适应度函数将架构意图转化为可执行的约束条件；智能体适应度函数则将该模型扩展至边界意图、语义漂移及其他需要大量判断的架构问题（图片为作者自制） 智能体适应度函数：经过校准的判断，而非预言机 智能体适应度函数是一种架构治理检查机制，其评估者为经过校准的 AI 智能体，评估标准以分析性评分标准的形式呈现，输出结果为包含证据、置信度和理由的结构化判定结果。
它并非预言机，也不能替代确定性检查。
它是一种方法，旨在使某些原本需要人工进行的架构判断具备足够的可重复性以实现持续运行，并具备足够的透明度以供审计。
这一区别至关重要。
在检测到明显违规时，编译器、代码检查工具、模式验证器或 SLO 检查仍然应该阻止部署。
而通常，智能体适应度函数应首先作为建议性信号。
只有在与先前的人工决策进行校准后，证明其精度、召回率和方差均在可接受的范围内，它才会产生更大的影响力。
即便如此，若出现置信度低、评审人员意见不一致、影响范围过大或架构权衡存在歧义等情况，仍然应该上报给人工评审员进行处理。
设计原则很简单：对客观不变量使用确定性门控，对基于证据的解释使用智能体式评估器。
应该向智能体提供一个小型的证据包，而非整个项目。
它的评估对象应该是特定的关注点，而非泛泛而谈的“良好架构”。
它应该返回机器可读的结果，而非对话式文章。
而且，评估标准本身应像代码一样进行版本控制和审查。
图 2.
智能体适应度函数与确定性门控并列。
它们消耗一个限定范围的证据包，生成结构化的判定结果，并将低置信度的结果上报，而不是默默地将其平均掉（图片为作者自制） 可用于生产环境的智能体适应度函数：结构解析与 ADK 参考实现 一个可用于生产环境的智能体适应度函数应该被视为可执行的治理组件，而非形式自由的 AI 审查。
其价值源于明确的执行边界：它接收特定的架构关注点，评估限定范围内的证据，应用明确的评分标准，并输出可存储、可追踪趋势且可审计的结构化判定结果。
其基本构成包括四个部分。
首先是适应度函数意图：团队希望保护的架构关注点，例如边界保真度、语义契约完整性或 ADR 漂移。
其次是证据契约：允许审查的限定范围内的工件集，例如 PR 差异、已更改的 API 规范、相关 ADR、所有权元数据、服务目录条目、确定性检查输出或跟踪窗口。
第三是智能体判定者：一个经过校准的 AI 智能体，负责将分析标准应用于证据分析。
第四是结构化判定结果：一份机器可读的结果，包含评分、置信度、违反的标准、违反理由、证据引用以及建议采取的行动。
🔗 原始来源
如果你要核对细节，可以再看原文： InfoQ AI原文链接