营运与维护 · 实作指南
沿着一项客户请求追踪整条 AI 工作流
用共同请求身份，分清模型、队列与整合延误。
助手慢，不一定是模型慢
假设维修流程等待分类很久，员工直觉怪罪模型，但真正时间可能花在队列或外部连接器。调模型前先画出请求旅程：接收、验证、检索、推论、批准、外部操作与确认。每段开始和结束都要有一致身份，才不会把不同请求的时间拼在一起。还要决定客户真正关心哪段时间，例如提交後多久有可用下一步，而非只看单次推论的速度。
订一份精简追踪合约
OpenTelemetry 提供串连操作的追踪模型。建议把相关识别码传入非同步讯息，在耗时阶段记录有界的追踪片段，附状态和设定版本，不附整段客户内容。等待人工批准与系统处理应分开，因为改善後者不一定能缩短前者。抽样要保留足够失败例子以便诊断，但不应把每份资料都变成遥测。团队需事先知道哪些资讯会离开执行环境。
流程一览
把技术轨迹转成使用者时间线
员工看到的可以是已接收、检查资料、等待审核、更新系统或需要处理，支援人员再连到背後技术轨迹。不能模型回答完成便宣告整项工作完成，涉及写入应以外部纪录确认为适当检查点。一条清楚时间线有助减少因不确定而重复提交，也方便交给人工处理。状态文字要反映真实阶段，不能只以转动图示掩盖长时间等待。
按观察结果处理瓶颈
演练工作者延误、提供方变慢和批准积压，查看各阶段分布与最久未解决的请求，而不只看平均数。每次只改一个限制，例如并行数或审核时段，才能比较效果。追踪也有成本，可从最重要路径开始。精细轨迹能解释时间，却不能证明答案正确或操作已获授权；内容品质与权限仍需独立验证，不要用维运图表代替业务验收。
共用事故参考号
在请求画面提供无害支援参考号，员工回报慢速工作时不用把客户文件贴进聊天。参考号在内部连到追踪轨迹，支援先索取它，再判断特定调查是否真的需要更多内容。这同时改善诊断与少量披露，亦方便跨语言团队沟通同一事件。参考号不能自行成为阅读资料的通行证，开启详情仍须按登入身份检查权限。
来源与延伸阅读
- TracesTracesOpenTelemetry · 官方文件 ·
编辑原则
本系列以 AI 辅助原创撰写，并对照连结的公开来源。实作建议与假设情境属编辑分析，并非客户实绩。来源发布日期及产品细节可能与本系列整理日期不同。