一条命令导出 Agent 轨迹：witty-insight 的 ATIF v1.6 数据格式完整实践

一条命令导出 Agent 轨迹witty-insight 的 ATIF v1.6 数据格式完整实践【免费下载链接】witty-insightThe witty-insight is an eBPF-based observability framework for tracing agent execution pipelines.项目地址: https://gitcode.com/openeuler/witty-insightwitty-insight 基于 eBPF 采集 Agent 的 LLM 调用并把完整运行轨迹按 ATIF v1.6 标准一键导出为 JSON——一份文件就能还原 Agent 的全部决策过程、工具调用与 token 消耗。Agent 排查最费时的环节行为散落在三处复盘一次 Agent 行为最难的从来不是拿到日志而是把日志对齐。系统提示词藏在请求体开头工具返回埋在消息历史中间token 统计躲在响应的计费字段里三块数据分属不同协议帧手工拼一次调用链要翻几十分钟。更麻烦的是格式不互通Claude Code 导出的轨迹和 OpenAI 风格的记录字段名完全不同分析脚本在 A 框架上写好换 B 框架就要重写。witty-insight 把 LLM 调用先还原成语义事件、持久化到本地 SQLite再提供一组 ATIF 导出端点让你直接拿到标准化 JSON跳过所有对齐工作。先认识 ATIF v1.6给 Agent 轨迹盖一个标准面单ATIFAgent Trajectory Interchange Format代理轨迹交换格式就像快递面单无论哪家快递公司揽收面单上发件人、收件人、重量的位置都一样分拣设备照单干活。ATIF 固定了字段位置让任何团队的解析工具都能读懂不同 Agent 系统产出的轨迹。witty-insight 当前实现的是 ATIF v1.6 版本四个核心结构如下结构作用AtifDocument轨迹根文档schema_version固定为ATIF-v1.6含session_id、agent配置、steps步骤数组与final_metrics汇总AtifStep单个交互步骤source取值system/user/agent可携带消息文本、工具调用与观测结果AtifToolCall/AtifObservation前者记录调了哪个工具、传了什么参数后者记录工具执行后环境返回的反馈AtifStepMetrics/AtifFinalMetrics前者是单步的prompt_tokens、completion_tokens、cached_tokens后者是整条轨迹的 token 总量与步骤数所有字段定义与序列化逻辑都在 src/atif/schema.rsNone字段导出时会自动省略所以 JSON 里不会有一堆空值。三步导出你的第一份轨迹 JSON先启动采集与服务agentsight二进制需要trace与serve两个子进程前者用 eBPF 抓事件后者把 SQLite 里的数据通过 HTTP 暴露出来。sudo ./target/release/agentsight trace --config agentsight.json ./target/release/agentsight serve --db genai_events.db --port 7396⚠️serve默认只监听127.0.0.1:7396跨机器访问需显式传--host。三个导出端点覆盖不同粒度按需选择端点导出范围GET /api/export/atif/trace/{trace_id}单个 trace即一次用户查询对应的完整 LLM 调用链GET /api/export/atif/session/{session_id}整个会话包含该 session 下所有 traceGET /api/export/atif/conversation/{conversation_id}单条对话内的全部 LLM 调用实际操作上先查会话列表拿到 ID再请求导出curl http://127.0.0.1:7396/api/sessions curl http://127.0.0.1:7396/api/export/atif/session/session_id第二个请求返回的 JSON 就是一份完整轨迹文档可直接喂给任何 ATIF 解析工具。深挖一条 LLM 调用记录如何变成标准轨迹转换逻辑集中在 src/atif/converter.rs核心是五个动作取数从 genai SQLite 表中按 trace / session / conversation 拉出TraceEventDetail事件序列每条对应一次 LLM 调用。补头trace 内第一次调用的请求上下文里提取系统提示词与用户提问生成source为system和user的前置步骤。拆步每次 LLM 调用映射为一个agent步骤——响应消息文本进message推理文本进reasoning_contentToolCall 部分进tool_callstoken 字段进metrics。关联观测这是最关键也最微妙的一步。Agent 调工具后工具结果并不会独立落库而是作为tool角色消息出现在下一次LLM 请求的历史里。转换器因此向前多看一条事件定位到最后一个带 ToolCall 的 assistant 消息之后收集其后的 tool 角色响应优先按tool_call_id精确匹配匹配不上再按位置对齐。汇总final_metrics直接累加所有步骤的input_tokens、output_tokens与缓存命中数。每个字段都有两级取值来源先尝试反序列化事件里的完整LLMCall语义结构失败则回退到output_messages、input_messages等数据库列保证部分损坏的记录也能导出。完整的语义模型说明见 genai-semantic.md。下一步做什么✅ 先用/session端点导出一份真实会话和数据库里的原始 LLM 调用记录逐字段对一遍理解一条记录拆成几步。 端点实现在 src/server/handlers.rs整体数据链路参考 docs/ARCHITECTURE.md。 免费发行版下载入口项目官网源码构建只需一行git clone https://gitcode.com/openeuler/witty-insight【免费下载链接】witty-insightThe witty-insight is an eBPF-based observability framework for tracing agent execution pipelines.项目地址: https://gitcode.com/openeuler/witty-insight创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考