北京
一个被悄悄劫持的运行过程
智能体日志里写着“成功”，但运行过程可能在第2步就被不可信内容带偏，到第6步才真正影响工具调用。行业里常见的应对方式，是再拿一个大模型去检查前一个大模型。Weir走了另一条路：确定性检查，不引入任何大模型。
它读取你已有的OpenTelemetry追踪数据，只回答两个问题：同样的输入是否产生字节级一致的答案，以及敏感数据是否到达了不该到达的接收端。整个过程没有大模型参与，数据也不离开本机。
把追踪数据变成CI门禁
Weir的定位是AI智能体的CI门禁。它读取智能体已经发出的OpenTelemetry追踪，一旦发现敏感数据流向不应到达的接收端，就让构建失败。安装方式很直接：pip install weir-scan，然后运行 weir gauge --sample。
它问的是一个结构性问题：智能体是否把敏感数据传给了不应接收的接收端。智能体在追踪数据里其实已经回答了这个问题。Weir重建会话图，在图中追踪污点传播，并逐节点展示证据。
确定性替代“第二个大模型”
当前默认做法是用第二个大模型去审查第一个大模型，这本身带有不确定性。Weir把检查逻辑固定下来：同样的输入、字节级一致的答案、没有大模型参与、数据不出本机。它不判断意图，只判断结构。
项目采用Apache-2.0许可证。对已经接入OpenTelemetry的团队来说，Weir可以直接复用现有追踪数据，不需要额外埋点或改变智能体代码。
证据链逐节点可见
Weir展示的不是一个笼统的通过或失败，而是从会话图重建出的证据节点。污点从哪里进入、经过哪些步骤、最终到达哪个接收端，都能在追踪数据里对应到具体位置。这让失败原因可以被定位，而不是只看到“构建失败”四个字。
对于把AI智能体接入生产流程的团队，这种确定性检查补上了日志“成功”与实际行为之间的缺口。它不替代可观测性，而是把已有的可观测性数据变成一道可以卡住发布的闸门。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
