提出智能体适应度函数扩展演进式架构规则
通过一个个看似合理的变更——它们虽然能通过所有既定规则的检验，但其实现却在悄无声息地偏离团队原本认为已经加以保护的设计意图。从历史经验来看，解决之道是人工审查。问题在于，人工审查无法扩展到每个拉取请求、每个契约变更、每个工作流跟踪，或是每个智能体生成的补丁。
图 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 以及代码库上下文来评估拉取请求，从而推断出架构意图。它会查找语义耦合、隐藏的协调路径、共享的状态抽象，以及跨越了架构边界上下文的未明确授权的知识。
该判定结果包括边界保真度评分、证据引用、置信度以及建议采取的行动。它并非要取代确定性依赖分析，而是要通过尽早识别细微的边界侵蚀，将架构设计的关注点引导至人类判断最能发挥价值的领域，从而起到对确定性依赖分析的补充作用。
语义契约评估员
模式验证器可以确保 API 和事件在结构上保持兼容，但兼容性并不能保证良好的架构边界。一份契约能够保持向后兼容，也可能在迭代过程中逐步暴露出内部标识符、基础设施相关逻辑、UI 专属字段，或是服务提供方的实现细节，这些内容会让调用方与服务之间产生不必要的强耦合。
基于智能体的语义契约评估器会审查 OpenAPI 或 AsyncAPI 的差异报告、示例有效载荷、消费者契约、架构决策记录（ADR）以及 API 设计指南，从而评估该契约是否始终以消费者为中心，是否在语义上保持了一致，是否使用了领域语言进行表达。它会推导接口的含义，而不仅仅是其结构。
该评估结果包括语义连贯性评分、耦合风险评估、证据引用、置信度以及建议采取的行动。确定性验证器则继续确保模式兼容性，而智能体则就含义、抽象以及长期耦合风险提供架构层面的解读。
ADR 漂移监督员
架构决策只有在支撑其成立的假设仍然成立时才有效。某项架构决策（ADR）可能会因流量较低而支持同步通信，将共享数据库视为临时方案，或基于组织或运营方面的限制而容忍某种特定的权衡。随着系统的发展，即使实现仍然符合文档中记载的决策，这些假设也可能会悄然失效。
基于智能体的 ADR 漂移监督员会定期将 ADR 假设与运营指标、事件、成本趋势、依赖关系图、部署模式以及所有权变更进行对比。它不评估代码变更，而是评估架构决策是否仍然与当前的实际情况相符，并识别架构漂移的迹象。
该判定指出了最初的假设、已发生变化的证据、由此产生的架构风险、置信度以及建议的审查路径。它不会导致构建失败；相反，它会主动提示架构师，重新审视那些最初的依据可能已经不再成立的决策。
实践指南
确保硬门槛具有确定性。对于能够以规则、模式、阈值、策略或可重复性实验等形式表达的条件，应当采用确定性检查。切勿用概率性判断取代可靠的门槛。
从提建议开始。将每个新的智能体适应度函数先在建议模式下运行，直到校准可以证明其信号稳定、有用且值得采取行动为止。
将证据范围限定在变更范围内。向智能体提供 PR 差异、涉及的契约、本地依赖关系图、相关的 ADR 以及一个较小的跟踪窗口，而非整个代码库。
使用分析性评分标准。将判断分解为命名标准。单凭架构质量评分无法付诸行动；而标准层面的判定则可以。
保留人工干预机制。当出现置信度不足、评审员意见不一致、影响范围过大或权衡取舍不明确等情况时，应该立即转交人工评审员进行处理。
促进结果的稳定性。当特定的结果反复出现，且团队一致认为其代表真实的违规情况时，应将其转化为明确的评分标准或确定性规则。
对评审流程进行版本管理。将提示词、评分标准、校准集、模型版本和工具定义视为受管控的成果。
审核证据链。保存证据引用、判定结果、置信度、理由及后续行动，以便团队日后复核该决策。
迈向规范化的架构判断
演进式架构并非旨在预测系统的最终形态，而是要确保下一次有意义的变更是安全的、可观察的、可逆的，并且符合组织所重视的架构特征。适应度函数是核心机制，因为它将治理从零星的意见转变为持续的反馈。
代理式 AI 将这一机制延伸到了以往需要人工干预的领域。它能够审查限定范围内的证据，应用经过校准的评估标准，并针对确定性规则无法完全涵盖的问题——如语义漂移、边界保真度、韧性解读以及过时的架构假设——给出结构化的判断。这之所以有用，恰恰是因为这些判断在架构实践中本就存在。智能体并非凭空创造这些判断，而是使其具有足够的可重复性以便观察，并具备足够的规范性以便改进。
安全模式要保守。将确定性门作为门控。将智能体检查用作经过校准的信号。对不确定性场景进行升级。对评估标准进行版本管理。随时间推移重新校准。在可能的情况下，将反复出现的结果转化为确定性检查。以这样的方式使用时，智能体适应度函数便成为软件治理自动化的一种务实的延伸：将判断视为代码，但同时保持谦逊——即认识到判断仍然需要证据、上下文和可说明性。
原文链接：https://www.infoq.com/articles/agentic-fitness-functions-evolutionary-architecture/