智能体适应度函数：将演进式架构扩展至确定性规则之外

通过一个个看似合理的变更——它们虽然能通过所有既定规则的检验，但其实现却在悄无声息地偏离团队原本认为已经加以保护的设计意图。从历史经验来看，解决之道是人工审查。问题在于，人工审查无法扩展到每个拉取请求、每个契约变更、每个工作流跟踪，或是每个智能体生成的补丁。 图 1. 确定性适应度函数将架构意图转化为可执行的约束条件；智能体适应度函数则将该模型扩展至边界意图、语义漂移及其他需要大量判断的架构问题（图片为作者自制） 智能体适应度函数：经过校准的判断，而非预言机 智能体适应度函数是一种架构治理检查机制，其评估者为经过校准的 AI 智能体，评估标准以分析性评分标准的形式呈现，输出结果为包含证据、置信度和理由的结构化判定结果。它并非预言机，也不能替代确定性检查。它是一种方法，旨在使某些原本需要人工进行的架构判断具备足够的可重复性以实现持续运行，并具备足够的透明度以供审计。 这一区别至关重要。在检测到明显违规时，编译器、代码检查工具、模式验证器或 SLO 检查仍然应该阻止部署。而通常，智能体适应度函数应首先作为建议性信号。只有在与先前的人工决策进行校准后，证明其精度、召回率和方差均在可接受的范围内，它才会产生更大的影响力。即便如此，若出现置信度低、评审人员意见不一致、影响范围过大或架构权衡存在歧义等情况，仍然应该上报给人工评审员进行处理。 设计原则很简单：对客观不变量使用确定性门控，对基于证据的解释使用智能体式评估器。应该向智能体提供一个小型的证据包，而非整个项目。它的评估对象应该是特定的关注点，而非泛泛而谈的“良好架构”。它应该返回机器可读的结果，而非对话式文章。而且，评估标准本身应像代码一样进行版本控制和审查。 图 2. 智能体适应度函数与确定性门控并列。它们消耗一个限定范围的证据包，生成结构化的判定结果，并将低置信度的结果上报，而不是默默地将其平均掉（图片为作者自制） 可用于生产环境的智能体适应度函数：结构解析与 ADK 参考实现 一个可用于生产环境的智能体适应度函数应该被视为可执行的治理组件，而非形式自由的 AI 审查。其价值源于明确的执行边界：它接收特定的架构关注点，评估限定范围内的证据，应用明确的评分标准，并输出可存储、可追踪趋势且可审计的结构化判定结果。 其基本构成包括四个部分。首先是适应度函数意图：团队希望保护的架构关注点，例如边界保真度、语义契约完整性或 ADR 漂移。其次是证据契约：允许审查的限定范围内的工件集，例如 PR 差异、已更改的 API 规范、相关 ADR、所有权元数据、服务目录条目、确定性检查输出或跟踪窗口。第三是智能体判定者：一个经过校准的 AI 智能体，负责将分析标准应用于证据分析。第四是结构化判定结果：一份机器可读的结果，包含评分、置信度、违反的标准、违反理由、证据引用以及建议采取的行动。 为了具体说明这一模式，我们基于 ADK 创建了一个小型参考实现： agent-fitness-functions "。 该实现将智能体适应度函数建模为一条处理管道。变更事件（例如拉取请求或契约差异）会被转换为一个限定范围的证据包。首先运行确定性检查以处理客观约束，例如依赖规则、模式验证、策略检查以及基于阈值的门控机制。随后，基于 ADK 的架构评估器会使用评分标准对剩余的、需要大量判断的关注点进行评估，并生成结构化的判定结果。 一个重要的设计选择是职责分离。该框架并不要求智能体取代确定性适应度函数，而是将其置于这些函数的旁边，使其能够评估那些受证据约束但难以简化为固定规则的问题。例如，一条依赖规则可能会检测到存在新的服务交互；而智能体评估器则可以评估该交互是出于有意协作、偶然耦合，还是一个边界保真度风险。模式差异分析可能显示某个 API 仍然保持着向后兼容性；智能体则可以评估该契约是否仍然保留着领域含义。 图 3. 当问题可以表述为规则或阈值时，应使用确定性适应度函数；当校准过的评分标准能够一致地应用于有限的证据时，应使用智能体适应度函数。应备有一份“真实歧义点手册”（图片为作者自制） 一份简明扼要的结构化判定书 { "fitness_function": "checkout-boundary-fidelity", "rubric_version": "2026.07.01", "score": 0.68, "confidence": 0.74, "decision": "advisory_warn", "violated_criteria": [ "semantic coupling"], "evidence": ["ADR-014", "OrderEvent.diff", "PaymentSession DTO"], "recommended_action": "Move PaymentSession behind a checkout-owned adapter or create an explicit shared-kernel ADR.", "deterministic_rule_candidate": "Disallow public events from exporting internal payment-state DTOs." } 校准与控制 在影响输出结果之前，需要对智能体适应度函数进行校准。一个实用的校准数据集应包含 20 至 50 个先前的变更案例，而这些案例已经被架构社区分类为“可接受”、“有风险”或“不可接受”。在这些示例上运行评估器，并调整评分标准，直到充分理解误报、漏报及变异性。每当模型、提示词、评分标准、工具链或证据契约发生变化时，都应该在该数据集上重新运行评估器。 不要掩盖不确定性。置信度是判定的一部分。若两个判定器之间存在分歧、重复运行之间结果的方差较大，或证据缺失，就应该上报给人工处理。通过求平均值来消除分歧是危险的，因为分歧往往表明架构真的存在需要权衡的问题。 该系统还需具备防范奖励破解和提示注入的控制措施。除非这些内容被明确列为证据，否则智能体应该忽略出现在代码注释、PR 描述、日志或生成的文件中的指令。在可行的情况下，判定模型应该与生成代码的智能体隔离。评分标准的变更应经过拉取请求审查，而且判定数据应该予以保留，供审计、趋势分析和重新校准之用。 智能体适应度函数的三个示例 以下示例展示了代理式 AI 的适用场景。每个示例都在可能的情况下保留了确定性控制平面，仅将智能体用于此前需要资深审核员参与的解释层。 边界保真审查员 确定性依赖规则可以检测到明显的边界违规，例如某个包导入了被禁止的包。更棘手的问题在于，如何判断某项变更是否在未违反任何显式依赖规则的情况下削弱了业务能力的所有权。通常，架构侵蚀表现为共享抽象、泄露的实现细节、重复的业务逻辑，或是服务间协调的增加，而非非法导入。 一个基于智能体的边界保真审查员会根据 ADR、服务所有权元数据、包图、CODEOWNERS 以及代码库上下文来评估拉取请求，从而推断出架构意图。它会查找语义耦合、隐藏的协调路径、共享的状态抽象，以及跨越了架构边界上下文的未明确授权的知识。 该判定结果包括边界保真度评分、证据引用、置信度以及建议采取的行动。它并非要取代确定性依赖分析，而是要通过尽早识别