概念/概念定义

应用背景：一句“任务完成”无法用来排错

用户看到“薪资组配置完成”，事后却发现两名员工没有被关联。开发者需要沿同一条时间线查到：意图如何识别，调度器选了哪个节点，工具收到什么参数，API 返回什么，状态又是何时被标记为完成。

一般应用日志可以证明进程在运行，却很难还原 Agent 的决策链。这里需要统一的活动事件和可关联的执行帧。

概念定义

Agent 可观测性记录一次会话中发生的意图识别、路由、推理、工具调用、状态读写和回复合成。目标是让开发者能够根据结构化事件定位执行偏差，而非只比较用户输入和最终输出。

东方屹腾把会话拆为 Activity，并在 Activity 下记录 Frame。Frame 可包含模型输入输出、工具请求与回执、状态变化、耗时和成本。

工程机制

各运行模块发布统一事件：

event_id
session_id
activity_type
step_id
started_at / ended_at
input_ref / output_ref
model_or_tool
cost
status

前端按时间排序显示事件，并允许展开具体 Frame。开发环境可显示完整提示词和回执；生产环境按权限脱敏或关闭调试字段。事件 ID 用于关联叙事、机械状态和任务节点的变化。

可观测性应从第一阶段进入运行时接口。后补日志很难还原模块边界、状态来源和模型当时看到的上下文。

案例用法

东方屹腾在接通对话管道后即建设事件时间线。意图识别结果、网关路由、ReAct 轮次和工具调用都以 Activity 展示；每次模型调用的提示词、输出、耗时和成本记录在 Frame 中。

当薪资组配置结果异常时，开发者可以定位到意图误判、推理选择错误、参数来源校验失败或业务回执不符合验收条件，无需反复重放整段会话进行猜测。

适用条件

当一次请求跨越多个能力模块，且错误需要定位到具体步骤、输入和状态变化时，应建立活动事件与执行时间线。事件生产方通常由Orchestrator统一协调。