分享内部 AI 助手的生产级日志监控和自动化审计流程,包括日志设计(含 provenance)、指标追踪、Agent 驱动的周度分析。实战经验丰富。
我们在20年历史的旧版帮助台系统之上运行了一个内部AI助手。从4月份开始投产,5个角色的15个活跃用户,从开发人员到运维人员再到项目经理。模型的重要性不如人们想的那么大。真正让助手周复一周改进的是一个枯燥的过程:对其日志的结构化周审查。这篇文章描述了这个过程、我们跟踪的指标,以及评查捕获的两个真实失败,是我本来永远找不到的。
一份摘要日志,每个请求一行:
[2026-07-20 16:46:52] user=xxx timing=99926ms status=ok
model=... turns=13 tools=12 cost=$0.25
profile=xxx ftok=1820ms query="have we ever solved..."
还有一份每个会话的完整 JSONL 转录:每个用户回合、每个回答,加上注入了哪些上下文以及它来自何处。这个数据溯源部分是后来才加上的,在一次评查显示我们无法解释助手为什么说某个回答后。如果你在构建一个助手,从第一天就开始记录答案的数据溯源。
手工读完一周的转录是不可持续的,所以评查本身就是一个agent任务。我说"做一次评查",agent就会找出还没有覆盖的时间段,从服务器拉取日志,然后逐个会话地工作。不是抽样。是全部。
评查有三个输出:
会话质量评审。agent对回答进行评分,重要的部分是:它针对实际数据库重新验证事实主张。如果助手告诉用户"这个修复在5月份安装到了客户X",评查会检查这是否属实。
改进建议。具体且优先级明确,每个都包含问题、证据(会话ID、引用)、建议的修复和工作量估计。每个建议进入一个积压清单,有各种状态:已提议、已批准、已实现、已拒绝或待观察。
用户档案。每个用户的使用模式反馈进个性化(详见下文)。

下一次评查会验证上一轮:已实现的修复是否真的停止了它们针对的故障?好几次答案是"部分地",该项又回到了积压清单中。没有这个验证步骤,改进积压就会变成一份自我满足的清单。
每次评查都会在一个长期记分卡上增加一行。同样的指标、同样的方法论,所以趋势是可见的:请求数、用户数、会话数、错误率、中位数和P95响应时间、纠正数、事实错误、漏报、安全事件、用户反馈、平均会话评分。
最近一周是这样的:137个请求、12个用户、44个会话、0个错误、中位数响应99秒、P95262秒、平均会话评分5分中的4.5分,评查覆盖率100%。

维护中得到的两个实践经验。首先,写下计数方法论,因为"多少个会话"原来有边界情况(我们现在把会话定义为至少有一个真实用户回合的转录文件,不包括仅反馈的文件)。其次,在记分卡本身标记方法论变化。否则一个指标跳跃看起来像是退步,其实是更深入的测量。
泄漏限制横幅。一个下午,我们的主要认证令牌不断触发速率限制,一个备用方案接管了。故障转移工作了,但评查发现至少12个回答展示给4个用户时,在最终回答的顶部粘着英文的"You've hit your limit"横幅和第一次失败尝试的碎片。用户看到了什么也没说。没人会报告他们还没有完全信任的工具里的古怪地方,这正是为什么你要读日志。
被接纳的错误前提。一个用户问了一个项目的问题,他们的问题包含了关于代码涉及哪个客户群的错误假设。助手原样接受了这个前提,并自信地把一切都归于错误的公司。转录的评分很好(用户很满意!),但事实是错的。修复是一个prompt规则:在根据代码构建回答之前,即使用户声称代码是什么,也要针对数据库验证代码背后的实体。你不会从用户反馈中捕获这类故障,因为用户是错误的来源。
每个用户有一个档案,助手把它加载到系统prompt中:角色、他们可能看到哪些项目、典型问题、首选答案深度。一个开发人员问一个包的问题会得到代码引用。一个项目经理问同一件事会得到一份商业摘要。一个运维人员问一个错误代码会得到过去的工单解决方案加上哪个开发人员要指派的建议。
花费迭代的部分:我们保留两个独立的档案集合。分析档案是我们对每个用户的内部理解,从日志评查构建。Agent档案是assistant实际加载的提炼版本。分析档案是原始材料,agent档案是产品。混合它们是我们最初犯的一个错误:关于用户的内部观察不属于prompt。
我会为任何这样做的人标出一个规则:个性化必须保持为默认值,而不是约束。一个问技术问题的非技术用户会得到技术答案。日志评查是关于改进assistant,而不是评估员工,这是你应该大声说出来并写下来的东西,在有人发现他们的对话被阅读之前。
生产中的AI助手是一个产品,它需要产品循环:工具、定期评查、优先级明确的积压、对修复有效性的验证。用agent做评查使100%覆盖率成为可能。最高价值的发现是用户永远不会报告的:所有人都满意时但其实是错的回答。