3 篇博文 含有标签「logging」

你把事故响应 agent 接入了 Splunk。你在系统提示里给了它查询语法,给了它执行 SPL 的工具,还有一个新鲜的 API token。第一次真正处理告警时,它拉了错的日志,总结了错的服务,信誓旦旦地报了错的客户。集成做得完美无缺,agent 却一文不值。

你忘了什么。十五年的日志惯例、没文档的字段名、跨越三次重组从 ERR 漂移到 error 再到 ERROR 的告警级别字符串、把 customer_id 在认证服务里变成 cust_id_v2_actual、在计费服务里变成 tenant.user.id 的团队特定后缀——这些东西没有一条出现在 prompt 里。你给了 agent 对 API 的访问权,但你没有给它访问那些让 API 变得有用的机构知识的权力。

这种失败的形状比 Splunk 大得多。任何把查询语言暴露给 agent、而底层语料是团队手工塑造了十年的工具,都会撞上这堵墙。Agent 拿到了动词,没拿到名词。

一个 AI 系统将某份求职申请标记为低优先级。候选人提出申诉。法务部门向工程团队询问："请展示模型当时看到的确切内容、检索的文档、触发的策略规则以及生成的置信度分数。"工程师打开日志，发现的是：时间戳、HTTP 200、响应体，以及延迟指标。其余的信息已经消失。

这不是日志记录的失败。按照所有传统标准，日志是完整的。问题在于，应用日志从来就不是为记录推理过程而设计的——而 AI 系统不只是在执行代码，它们做出的是依赖上下文的概率性决策，只有给定决策时刻存在的完整输入上下文，才能被理解。

2026年，大多数构建AI系统的工程团队都知道欧盟《人工智能法》的存在。但很少有人真正理解它要求他们构建什么。该法规对高风险AI系统的核心义务——自动事件日志记录、人工监督机制、风险管理系统、技术文档——并非法律团队能在截止日期前生产的政策文件。它们是工程交付物，需要在项目启动时做出架构决策，而非在合规审计前的最后一个冲刺阶段。

硬性截止日期是2026年8月2日。在欧盟部署的高风险AI系统必须完全符合第9至15条的规定。在就业筛选、信用评分、福利分配、医疗优先级、生物特征识别或关键基础设施管理领域部署AI的组织均在适用范围内。如果你的系统在这些领域做出实质性影响欧盟居民的决策，它几乎肯定属于高风险。而现实的合规实施周期需要8至14个月——这意味着如果你还没有开始，已经落后了。