一句话看懂：InfoQ 提出“智能体适应度函数”这一架构治理新方法，用经过校准的 AI 智能体补充传统确定性规则检查，用于捕捉代码边界侵蚀、语义契约漂移等需要人工判断的架构问题。
事件核心：发生了什么
InfoQ 发布了一篇关于“智能体适应度函数”的技术文章，探讨如何将演进式架构中的适应度函数从确定性规则扩展到 AI 智能体评估。传统上，架构治理依赖编译器、代码检查工具和 SLO 检查等确定性门控，这些机制能拦截明确违规，但无法识别“所有规则都通过、设计意图却在悄悄偏离”的变更——例如某个 API 保持向后兼容但暴露了内部实现细节，或某项变更未违反依赖规则却削弱了业务能力边界。
文章提出一种新机制：由经过校准的 AI 智能体作为评估者，接收限定范围的“证据包”（如 PR 差异、API 规范、ADR 决策记录），按照分析性评分标准输出包含评分、置信度、证据引用和理由的结构化判定结果。该机制并非取代确定性检查，而是与之并列运行——确定性规则继续处理客观约束，智能体处理需要判断的解释层问题。作者还基于 Google ADK 发布了名为 agent-fitness-functions 的参考实现。
为什么重要
这一思路的价值在于把架构治理从“零散的人工审查”推向“可重复、可审计的持续反馈”。随着 AI 生成代码的普及，传统人工审查无法覆盖每个拉取请求和每个智能体生成的补丁，架构侵蚀正以更隐蔽的方式发生。智能体适应度函数不是要做一个“全知预言机”，而是让原本依赖资深工程师经验判断的问题——如语义耦合、契约的领域含义是否保留、ADR 背后的假设是否仍然成立——具备足够的可重复性和透明度，以便纳入自动化流水线。
文章特别强调校准与控制：在影响输出结果前，需要用 20-50 个已分类的历史变更案例校准评估器，测量误报率和方差。低置信度、评审分歧、证据缺失等情况必须上报人工，而不是简单求平均值掩盖不确定性。这种“保守升级”的设计哲学，与当前许多 AI 治理方案中“让模型直接做决定”的激进路径形成了明显对比。
对用户/开发者/创作者的影响
对于软件架构师和技术负责人，这篇文章提供了一套可落地的框架：将治理拆分为确定性门控与智能体评估两层，明确哪些问题用规则和阈值解决，哪些问题需要校准过的评分标准。具体实施时，证据包应限定在变更范围内（如 PR diff、涉及的契约文件、相关的 ADR），而不是把整个代码库丢给模型；评估标准要像代码一样进行版本管理；判定结果应保存供审计和趋势分析。
AI 工具推荐
想把多个 AI 模型放在一个入口？
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。
推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。
对于使用 AI 编程工具的开发者，这意味着架构保护机制可能从“事后检测”转向“变更时持续评估”。而对于 AI 应用开发者，文中提出的“判定模型应与生成代码的智能体隔离”“防止提示注入奖励破解”等控制措施，也提供了代理式 AI 在生产环境中落地的安全边界参考。
值得关注的后续
1. agent-fitness-functions 参考实现是否会被更多团队采用并形成社区标准，值得持续观察——目前它只是一个基于 ADK 的小型实现，距离广泛使用尚需验证。
2. 文章明确指出“只有当校准证明精度、召回率和方差都在可接受范围内，智能体检查才会产生更大影响力”，这意味着采用团队需要投入精力建立校准集和评估流程，短期内可能只有治理成熟度较高的团队能率先落地。
3. 智能体适应度函数是否能将从反复出现的问题中提炼出的模式转化为确定性规则，是衡量其长期价值的关键——如果所有判断最终都能固化为规则，那智能体的角色将始终处于“辅助而非决策”的位置。
来源：InfoQ CN
