随着编码智能体超越实验阶段，进入日常开发工作，两个问题对试图理解这些系统如何融入其工作流的组织来说变得日益相关：团队内部AI编码工具的使用有多广泛？开发人员用它们做什么？
这种转变也解释了为何一些被广泛采用的编码智能体背后的供应商，开始更清晰地展示其系统在大规模环境中的运行情况。
编码智能体进入生产环境，度量指标随之出现
12月初，某代码托管平台引入了新的仪表板，汇总了与Copilot代码生成活动相关的度量指标，让组织能更清晰地了解该工具在团队中的使用情况。这揭示了高层面的信号，例如在AI辅助下更改的代码量，区分了由开发人员直接发起的更改和由Copilot智能体功能自动进行的更改，并按模型和编程语言细分了这些活动。
与此同时，同名开源编码助手背后的初创公司Continue，也采取了类似步骤，在其任务控制界面内为其基于云的智能体引入了度量指标。虽然Continue此前已公开基本使用数据，但此次升级将这些信号集中到一个专为大规模运行智能体的团队设计的控制平面中。
这些更新反映了为使基于云的编码智能体更易于团队评估而日益增长的努力，尤其是在它们进入生产使用时。随着更多的工程工作被委托给自动化系统，组织希望有更清晰的方法来了解这些智能体在做什么，以及它们的产出如何融入日常开发。
“当我们信任输出时，工程团队才会采用自动化，而信任需要可见性，”Continue的高级开发者布道师Bekah Hawrot Weigel说。“随着越来越多的组织转向云端托管的AI智能体和持续AI，同样的问题不断出现。”
这些问题集中在基于云的智能体长期实际完成了什么、哪些自动化工作流产生了实质性的工程产出，以及随着这些系统成为开发流程的一部分，团队应如何评估投资回报率。
“度量指标让这一切变得可见，”她继续说道。
云可观测性：智能体度量的蓝图
值得注意的是，某代码托管平台的仪表板和API展示的是Copilot在其自身环境中生成的活动，而Continue的度量指标反映的是通过其云平台运行的智能体的行为。这并不意外。
但对于接下来可能发生的情况，存在历史先例。这类第一方可见性通常在平台达到一定的运营成熟度时出现。在云基础设施领域，当某中心、某机构等提供商的云服务成为企业的核心生产依赖后，便开始通过诸如CloudWatch、Azure Monitor和Google Cloud Monitoring等工具公开使用情况、可靠性和成本数据。托管机器学习平台也遵循了类似的轨迹，例如某中心的SageMaker、某机构的Vertex AI和Azure Machine Learning。在每种情况下，度量指标都随着企业关于治理、报告和问责制的期望而出现。
智能体度量指标自然契合于同样的发展轨迹。随着AI驱动的系统更深地嵌入日常开发，组织希望更清晰地洞察这些系统的行为方式以及其使用的广泛程度。仪表板和API提供了一种实用的方式来展示这些信息，并将其连接到现有的管理和报告流程。
随着时间的推移，随着组织采用多云和混合环境，云可观测性超越了单一提供商的视图。诸如Datadog、Prometheus和OpenTelemetry等工具应运而生，用于聚合跨云和本地基础设施的度量指标、日志和跟踪，而不是将可见性绑定到单一提供商的运行时环境。
随着团队并行部署多个智能体和自动化工具，围绕AI智能体可能会出现类似的动态。更高层面的方法不是监测特定智能体运行时内的执行，而是关注智能体活动对工程系统其余部分变得可见的那些节点。
诸如Git-ai这样的开源项目通过在代码仓库和工作流层面操作来体现这种方法。Git-ai不追踪智能体内部如何推理或它调用了哪些工具，而是关注代码库中最终发生了什么变化：哪些提交受到了AI影响，自动化贡献如何通过拉取请求推进，以及智能体驱动的更改如何随时间演变。通过将可观测性锚定在Git层，可以跨不同的智能体和工具，使用一个共同的参考框架来分析AI活动。
从这个意义上说，供应商提供的度量指标和仓库级可观测性解决了不同的问题。平台仪表板帮助组织了解特定智能体在托管环境内的行为，而更高层级的工具则着眼于任何单一运行时环境之外持续存在的结果。随着智能体应用的普及，这两种视角可能会共存，发挥互补作用，而不是融合为单一视图。
