ARTICLE DETAIL

建站实战干货

来自一线的建站与推广经验沉淀,每一条都经过真实交付验证。

AI智能体调试新范式:构建可追溯的会话追踪系统

2026/8/24 4:57:12 拓冰建站 浏览量
AI智能体调试新范式:构建可追溯的会话追踪系统 这次我们来看一个名为ctx的项目它被描述为“git blamebut for agent sessions”。简单来说这是一个为 AI 智能体Agent会话设计的调试与追溯工具。就像开发者用git blame来查看代码的每一行是谁、在什么时候修改的ctx的目标是让你能清晰地看到 AI 会话中每一步决策、每一次 API 调用、每一个生成的内容具体是由哪个“智能体”、在哪个环节、基于什么上下文做出的。对于正在开发或调试复杂 AI 工作流、多智能体系统的工程师和研究者而言这直接命中了一个核心痛点当会话结果不符合预期时传统的日志可能杂乱无章难以定位问题根源。ctx试图引入版本控制的思想为 AI 会话提供结构化的、可追溯的“审计轨迹”。本文将带你快速了解ctx的核心概念、它能解决什么问题并基于其项目理念构建一套可落地的本地部署、测试验证与集成方案。即使项目本身可能还处于早期阶段我们也可以从中提炼出对智能体系统进行观测和调试的通用方法论。1. 核心能力速览能力项说明与推断项目类型AI 智能体会话追踪与调试工具。核心类比类似于git blame对代码行的追溯但对象是 AI 会话中的步骤Step。主要功能记录会话步骤、关联输入输出、追溯决策源头、可视化会话流。数据记录应能捕获用户输入、智能体调用、工具Tool执行、API 响应、LLM 生成内容、耗时、token 消耗等。输出形式可能是命令行报告、Web UI 可视化界面或结构化日志文件JSON 等。集成方式推测为 SDK/库集成到智能体代码中或作为中间件Middleware拦截请求。适合场景开发调试多智能体系统、分析复杂工作流瓶颈、审计 AI 决策过程、教学演示。重要提示由于输入材料未提供ctx项目的具体仓库、安装命令或 API 文档下文内容将基于其核心概念“为 Agent Sessions 提供 git blame 能力”进行通用性构建和演示。我们将创建一个模拟的、具备类似核心功能的简易系统并阐述其设计思路与验证方法。当实际项目代码可用时可参照此框架进行适配。2. 适用场景与使用边界谁需要这个工具AI 应用开发者正在构建基于 LangChain、LlamaIndex、AutoGen 等框架的智能体应用需要调试其复杂逻辑。提示词工程师需要精细分析多轮对话中哪一步提示词Prompt导致了模型的特定输出。运维与算法工程师需要监控生产环境 AI 服务的决策链路进行问题排查和性能分析。技术负责人/审计人员需要对 AI 系统的决策过程进行合规性审查与追溯。能解决什么问题问题定位当最终输出错误时快速定位是哪个智能体、调用了哪个工具、或哪次 LLM 生成出了问题。性能分析统计每个步骤的耗时和 Token 使用找出系统瓶颈。上下文还原重现问题发生的完整上下文包括当时的系统状态、历史消息等便于复现和修复。流程可视化将线性的日志转换为有向图直观展示智能体间的协作关系和数据流向。不适合什么场景对简单、单次 LLM 调用进行调试使用常规日志或 LangSmith 等现有平台可能更轻量。追求极致的性能与零开销深度集成追踪必然引入少量性能损耗。封闭、无法修改代码的第三方服务需要能在智能体代码中植入追踪点。伦理与合规边界数据隐私追踪记录可能包含用户输入的敏感信息、模型生成的原始内容。必须确保记录存储的安全并在生产环境中考虑脱敏或选择性记录。审计合规在金融、医疗等受监管领域使用 AI 决策时此类追溯工具可作为审计证据的一部分但需满足该行业特定的数据留存和安全性要求。知识产权记录的提示词、工作流可能包含业务逻辑核心需妥善保护。3. 环境准备与前置条件为了模拟和验证ctx这类工具的理念我们需要搭建一个基础的智能体开发环境。以下是一个通用的准备清单操作系统Linux (Ubuntu 20.04)、macOS 或 Windows (WSL2 推荐)。本文以 Ubuntu 为例。Python 环境Python 3.10 或 3.11。推荐使用conda或venv创建虚拟环境。核心开发框架选择一种智能体框架进行实验。LangChain目前最流行的框架之一生态丰富。AutoGen微软推出的多智能体对话框架。LlamaIndex擅长与数据连接构建上下文。本文示例将使用LangChain因其受众最广。LLM 接入需要一个大语言模型的 API 密钥或本地模型。云端 APIOpenAI GPT、Anthropic Claude、DeepSeek 等。准备相应的API_KEY。本地模型使用 Ollama、LM Studio 或 vLLM 等部署本地 LLM 服务。这更适合需要完全控制数据流的场景。基础工具链git用于版本管理。pipPython 包管理器。存储追踪数据需要存储可以是本地文件JSON、SQLite 数据库或更专业的向量数据库如 Chroma, Weaviate用于后续检索分析。4. 安装部署与启动方式由于没有具体的ctx项目包我们将创建一个最小化的模拟追踪模块并集成到 LangChain 智能体中。4.1 创建项目并安装依赖# 创建项目目录 mkdir agent-session-tracker cd agent-session-tracker # 创建虚拟环境 python -m venv venv source venv/bin/activate # Windows: venv\Scripts\activate # 安装核心依赖 pip install langchain langchain-openai langchain-community # 安装用于记录和可视化的额外库 pip install pydantic sqlalchemy networkx matplotlib4.2 设计并实现简易的 Session Tracker我们创建一个tracker.py文件实现核心的追踪逻辑。# tracker.py import json import time from datetime import datetime from typing import Any, Dict, List, Optional from uuid import uuid4 from pydantic import BaseModel class StepRecord(BaseModel): 记录会话中的单一步骤 step_id: str parent_step_id: Optional[str] # 类似 git 的父提交用于构建树形结构 session_id: str agent_name: str action_type: str # 如”llm_call“, ”tool_execute“, ”decision“ input_data: Dict[str, Any] output_data: Dict[str, Any] metadata: Dict[str, Any] # 耗时、token数、时间戳等 timestamp: str class SessionTracker: 会话追踪器模拟 ctx 的核心记录功能 def __init__(self, storage_path: str ./session_logs): self.storage_path storage_path self.current_session_id None self.steps: List[StepRecord] [] def start_session(self, session_id: Optional[str] None): 开始一个新的追踪会话 self.current_session_id session_id or fsession_{uuid4().hex[:8]} self.steps.clear() print(f[Tracker] Session started: {self.current_session_id}) return self.current_session_id def record_step(self, agent_name: str, action_type: str, input_data: Dict, output_data: Dict, parent_step_id: Optional[str] None, **metadata): 记录一个步骤 if not self.current_session_id: self.start_session() step_record StepRecord( step_idfstep_{uuid4().hex[:8]}, parent_step_idparent_step_id, session_idself.current_session_id, agent_nameagent_name, action_typeaction_type, input_datainput_data, output_dataoutput_data, metadata{ duration_ms: metadata.get(duration_ms, 0), token_usage: metadata.get(token_usage, {}), timestamp: datetime.now().isoformat(), **metadata }, timestampdatetime.now().isoformat() ) self.steps.append(step_record) return step_record.step_id def blame(self, step_id: str) - Optional[StepRecord]: 模拟 git blame根据 step_id 查找完整的步骤记录 for step in self.steps: if step.step_id step_id: return step return None def get_session_tree(self) - List[Dict]: 获取会话的步骤树用于可视化 # 简化实现将步骤按父子关系组织 tree [] step_map {s.step_id: s for s in self.steps} for step in self.steps: node { id: step.step_id, agent: step.agent_name, action: step.action_type, parent: step.parent_step_id, input_preview: str(step.input_data)[:50] ..., output_preview: str(step.output_data)[:50] ..., } tree.append(node) return tree def save_session(self): 将当前会话保存到文件 if not self.current_session_id: return import os os.makedirs(self.storage_path, exist_okTrue) filename os.path.join(self.storage_path, f{self.current_session_id}.json) data { session_id: self.current_session_id, steps: [step.dict() for step in self.steps] } with open(filename, w, encodingutf-8) as f: json.dump(data, f, indent2, ensure_asciiFalse) print(f[Tracker] Session saved to: {filename}) def load_session(self, session_id: str): 从文件加载会话 import os filename os.path.join(self.storage_path, f{session_id}.json) if os.path.exists(filename): with open(filename, r, encodingutf-8) as f: data json.load(f) self.current_session_id data[session_id] self.steps [StepRecord(**step) for step in data[steps]] print(f[Tracker] Session loaded: {session_id}) else: print(f[Tracker] Session file not found: {filename})4.3 创建并集成一个可追踪的 LangChain 智能体接下来我们创建一个使用该追踪器的简单 LangChain 智能体。# agent_with_tracking.py import os from langchain.agents import AgentExecutor, create_react_agent from langchain.tools import Tool from langchain_community.utilities import SerpAPIWrapper from langchain_openai import ChatOpenAI from langchain import hub from tracker import SessionTracker # 初始化追踪器 tracker SessionTracker() session_id tracker.start_session() # 1. 定义工具 (Tools) def search_web(query: str) - str: 模拟一个网络搜索工具。实际使用时需替换为真实 API如 SerpAPI。 # 这里模拟返回 start_time time.time() result f模拟搜索结果关于 {query} 的信息。 duration int((time.time() - start_time) * 1000) # 记录工具执行步骤 tracker.record_step( agent_nameWebSearchTool, action_typetool_execute, input_data{query: query}, output_data{result: result}, metadata{duration_ms: duration} ) return result def calculate(expression: str) - str: 模拟一个计算器工具。 start_time time.time() try: # 警告实际应用中应使用更安全的评估方式 result str(eval(expression)) except Exception as e: result f计算错误: {e} duration int((time.time() - start_time) * 1000) tracker.record_step( agent_nameCalculatorTool, action_typetool_execute, input_data{expression: expression}, output_data{result: result}, metadata{duration_ms: duration} ) return result # 将函数包装成 LangChain Tool 对象 tools [ Tool( nameSearch, funcsearch_web, description当需要回答关于实时信息或最新事件的问题时使用此工具。输入应为搜索查询。 ), Tool( nameCalculator, funccalculate, description当需要计算数学表达式时使用此工具。输入应为有效的数学表达式如 2 2 或 3 * 5。 ) ] # 2. 初始化 LLM # 方式一使用 OpenAI API (需设置环境变量 OPENAI_API_KEY) llm ChatOpenAI(modelgpt-3.5-turbo, temperature0) # 方式二使用本地模型例如通过 Ollama # from langchain_community.llms import Ollama # llm Ollama(modelllama3) # 3. 创建智能体 prompt hub.pull(hwchase17/react) # 使用 ReAct 提示模板 agent create_react_agent(llm, tools, prompt) agent_executor AgentExecutor(agentagent, toolstools, verboseTrue, handle_parsing_errorsTrue) # 4. 包装执行函数以加入追踪 def run_agent_with_tracking(user_input: str): 执行智能体并追踪其每一步 print(f\n{*50}) print(f用户输入: {user_input}) print(f{*50}) # 记录用户输入作为会话的“根步骤” root_step_id tracker.record_step( agent_nameUser, action_typeuser_input, input_data{query: user_input}, output_data{}, metadata{note: 会话开始} ) # 为了追踪 LangChain 内部的思考过程我们需要更精细的钩子Callback。 # 这里为简化我们在执行前后记录并手动模拟关键步骤。 # 记录智能体开始思考 tracker.record_step( agent_nameMainAgent, action_typeagent_start, input_data{prompt: user_input}, output_data{}, parent_step_idroot_step_id, metadata{note: 智能体开始处理} ) # 实际执行 LangChain 智能体 start_time time.time() try: result agent_executor.invoke({input: user_input}) final_output result.get(output, No output) except Exception as e: final_output fAgent execution failed: {e} duration int((time.time() - start_time) * 1000) # 记录智能体完成并输出结果 tracker.record_step( agent_nameMainAgent, action_typeagent_finish, input_data{}, output_data{output: final_output}, parent_step_idroot_step_id, metadata{duration_ms: duration, note: 智能体执行完成} ) print(f\n智能体输出: {final_output}) print(f总耗时: {duration} ms) # 保存本次会话记录 tracker.save_session() return final_output if __name__ __main__: # 测试运行 test_query 上海今天的天气怎么样先搜索如果是晴天就计算一下 25 度的华氏度是多少。 run_agent_with_tracking(test_query) # 打印追踪到的步骤树 print(\n 会话步骤追踪树 ) for node in tracker.get_session_tree(): print(f[{node[id]}] {node[agent]} - {node[action]}) print(f 输入: {node[input_preview]}) print(f 输出: {node[output_preview]}) if node[parent]: print(f 父步骤: {node[parent]}) print()5. 功能测试与效果验证现在我们来运行这个集成了追踪器的智能体并验证其“git blame”能力。5.1 启动测试确保已设置 OpenAI API Key如果使用云端模型export OPENAI_API_KEYyour-api-key-here运行我们的智能体脚本python agent_with_tracking.py5.2 预期结果与验证脚本运行后你将在控制台看到LangChain 智能体的标准输出因为设置了verboseTrue包括其思考Thought、行动Action、观察Observation的循环。我们自定义的追踪日志显示会话开始、步骤记录。最终的智能体输出。打印出的会话步骤追踪树以文本形式展示步骤间的父子关系。验证点 1会话文件是否生成检查./session_logs/目录应该会生成一个类似session_abc123.json的文件。打开它你会看到结构化的 JSON 数据完整记录了整个会话的所有步骤、输入输出和元数据。这相当于你的“git log”。验证点 2能否进行“blame”追溯我们在tracker.py中实现了blame方法。可以编写一个简单的查询脚本# blame_demo.py from tracker import SessionTracker # 加载最近的一次会话 tracker SessionTracker() # 假设你的会话文件是 session_abc123.json tracker.load_session(session_abc123) # 替换为实际文件名不含.json # 假设我们想查看某个特定步骤 ID 的详情 step_id_to_inspect step_xxxxxx # 从之前的输出或 JSON 文件中复制一个 step_id step_record tracker.blame(step_id_to_inspect) if step_record: print(f Blame for Step: {step_record.step_id} ) print(fAgent: {step_record.agent_name}) print(fAction: {step_record.action_type}) print(fTimestamp: {step_record.timestamp}) print(f\nInput:) print(json.dumps(step_record.input_data, indent2, ensure_asciiFalse)) print(f\nOutput:) print(json.dumps(step_record.output_data, indent2, indent2, ensure_asciiFalse)) print(f\nMetadata:) print(json.dumps(step_record.metadata, indent2, ensure_asciiFalse)) else: print(fStep {step_id_to_inspect} not found.)运行此脚本你将获得该步骤的完整上下文。这就是git blame的核心精准定位。验证点 3可视化会话流进阶我们可以利用记录的父子关系生成简单的可视化图表。安装networkx和matplotlib后可以添加以下代码# visualization.py import networkx as nx import matplotlib.pyplot as plt from tracker import SessionTracker def visualize_session(session_id: str): tracker SessionTracker() tracker.load_session(session_id) tree_data tracker.get_session_tree() G nx.DiGraph() labels {} for node in tree_data: node_id node[id] G.add_node(node_id) # 节点标签显示代理和动作 labels[node_id] f{node[agent]}\n{node[action]} if node[parent]: G.add_edge(node[parent], node_id) plt.figure(figsize(12, 8)) pos nx.spring_layout(G, seed42) # 布局算法 nx.draw(G, pos, with_labelsTrue, labelslabels, node_size3000, node_colorskyblue, font_size8, font_weightbold, arrowsize20) plt.title(fSession Flow: {session_id}) plt.tight_layout() plt.savefig(f{session_id}_flow.png) print(f流程图已保存为 {session_id}_flow.png) plt.show() if __name__ __main__: visualize_session(session_abc123) # 替换为你的 session_id这将生成一个 PNG 图片直观展示智能体会话中各个步骤的调用关系。6. 接口 API 与批量任务一个成熟的ctx类工具应该提供 API 以便其他服务集成并支持批量处理历史会话日志进行分析。6.1 设计简易的查询 API我们可以用 FastAPI 快速搭建一个服务提供会话和步骤的查询接口。# api_server.py from fastapi import FastAPI, HTTPException from pydantic import BaseModel from tracker import SessionTracker import os app FastAPI(titleAgent Session Tracker API) tracker SessionTracker() class SessionQuery(BaseModel): session_id: str class StepQuery(BaseModel): session_id: str step_id: str app.get(/) def read_root(): return {service: Agent Session Tracker API, version: 0.1} app.get(/sessions) def list_sessions(): 列出所有已保存的会话ID log_dir tracker.storage_path if not os.path.exists(log_dir): return {sessions: []} sessions [f.replace(.json, ) for f in os.listdir(log_dir) if f.endswith(.json)] return {sessions: sessions} app.post(/session/load) def load_session(query: SessionQuery): 加载指定会话到内存 try: tracker.load_session(query.session_id) return {status: success, message: fSession {query.session_id} loaded., step_count: len(tracker.steps)} except Exception as e: raise HTTPException(status_code404, detailfFailed to load session: {e}) app.get(/session/tree) def get_session_tree(session_id: str): 获取指定会话的步骤树 tracker.load_session(session_id) return tracker.get_session_tree() app.post(/step/blame) def blame_step(query: StepQuery): 查询特定步骤的详细信息git blame功能 tracker.load_session(query.session_id) step_record tracker.blame(query.step_id) if not step_record: raise HTTPException(status_code404, detailfStep {query.step_id} not found in session {query.session_id}) return step_record.dict() if __name__ __main__: import uvicorn uvicorn.run(app, host127.0.0.1, port8000)启动服务pip install fastapi uvicorn python api_server.py访问http://127.0.0.1:8000/docs即可使用交互式 API 文档进行测试。6.2 批量分析任务对于保存在session_logs/下的多个会话文件我们可以编写脚本进行批量分析例如统计平均响应时间。找出最常调用的工具。检索所有失败的步骤根据输出内容判断。# batch_analysis.py import json import os from collections import Counter def analyze_all_sessions(log_dir./session_logs): total_sessions 0 total_steps 0 agent_counter Counter() action_counter Counter() error_steps [] for filename in os.listdir(log_dir): if not filename.endswith(.json): continue total_sessions 1 filepath os.path.join(log_dir, filename) with open(filepath, r, encodingutf-8) as f: data json.load(f) for step in data.get(steps, []): total_steps 1 agent_counter[step[agent_name]] 1 action_counter[step[action_type]] 1 # 简单错误检测如果输出包含“error”或“failed” output_str json.dumps(step[output_data]).lower() if any(keyword in output_str for keyword in [error, fail, exception]): error_steps.append({ session: data[session_id], step_id: step[step_id], agent: step[agent_name], action: step[action_type] }) print(f 批量分析报告 ) print(f总会话数: {total_sessions}) print(f总步骤数: {total_steps}) print(f\n智能体调用统计:) for agent, count in agent_counter.most_common(): print(f {agent}: {count} 次) print(f\n动作类型统计:) for action, count in action_counter.most_common(): print(f {action}: {count} 次) if error_steps: print(f\n⚠️ 发现 {len(error_steps)} 个可能错误的步骤:) for err in error_steps[:5]: # 只显示前5个 print(f 会话 {err[session]}, 步骤 {err[step_id]}, 代理 {err[agent]}, 动作 {err[action]}) else: print(f\n✅ 未发现明显错误步骤。) if __name__ __main__: analyze_all_sessions()7. 资源占用与性能观察对于此类追踪系统性能开销主要来自数据序列化/反序列化将每一步的输入输出转为 JSON 并存储。I/O 操作频繁写入文件或数据库。内存占用在内存中维护当前会话的所有步骤记录。优化建议异步写入将tracker.record_step的保存操作改为异步不阻塞主线程。采样记录在生产环境中可以配置为只记录特定比例如 1%的会话或只记录错误会话。使用轻量级存储对于高性能场景可以考虑使用内存数据库如 Redis暂存再定期持久化到磁盘。控制记录粒度不是所有中间数据都需要记录。可以设计过滤规则只记录关键步骤或元数据。监控指标延迟增加对比开启追踪和关闭追踪时智能体完成相同任务的平均耗时。内存增长长时间运行后追踪器内存占用的增长情况。存储空间会话日志文件随时间的增长速率制定合理的清理策略。8. 常见问题与排查方法问题现象可能原因排查方式解决方案追踪器未记录任何步骤1.tracker.record_step未被调用。2.current_session_id未初始化。1. 检查智能体代码中是否在关键位置调用了记录函数。2. 在record_step开始处添加打印语句。1. 确保在智能体初始化后调用tracker.start_session()。2. 使用装饰器或中间件自动注入追踪逻辑。步骤父子关系混乱parent_step_id传递错误。检查get_session_tree输出查看父子链接是否正确。确保在执行链中正确传递和更新parent_step_id。可以考虑使用调用栈或上下文管理器自动管理。会话文件过大单次会话步骤过多或记录的输入输出数据如图片、长文本太大。查看生成的 JSON 文件大小。1. 对大型数据进行摘要或哈希后记录而非完整存储。2. 实现日志轮转和自动清理。API 服务查询不到数据1. 会话 ID 错误。2. 文件路径权限问题。3. 数据未正确保存。1. 检查/sessions端点返回的列表。2. 查看 API 服务日志。3. 直接检查session_logs目录下的文件。1. 确保前端或调用方传递正确的 session_id。2. 确保服务进程对日志目录有读写权限。3. 在save_session方法中加入更健壮的异常处理。集成后智能体性能明显下降同步的、阻塞式的记录操作拖慢了主流程。使用性能分析工具如 cProfile定位耗时最长的函数。将记录操作改为异步如使用asyncio或消息队列或降低记录频率。无法可视化流程图networkx或matplotlib未安装或图形过于复杂。检查导入错误尝试绘制只有少数节点的简单图。1. 确保安装了可视化依赖。2. 对于复杂图可以考虑使用交互式可视化库如pyvis或导出为 Graphviz 格式。9. 最佳实践与使用建议定义清晰的步骤类型Action Type如llm_call,tool_search,tool_calculate,decision_point,error_handled。这有助于后续的过滤和分析。为步骤记录添加业务标签在metadata中加入自定义标签如project_name,user_id,pipeline_stage便于多维度的会话检索和聚合分析。实施数据脱敏在记录之前对可能包含个人身份信息PII、密钥或敏感商业逻辑的字段进行脱敏处理。建立开发与生产的不同配置在开发环境记录完整细节用于调试在生产环境则记录摘要、抽样或仅记录错误以平衡可观测性与性能、成本。与现有可观测性栈集成可以将追踪数据导出到 OpenTelemetry、Prometheus 或专门的 APM应用性能监控工具中实现统一的监控。版本化会话模式当智能体的提示词、工具或模型版本更新时在会话记录中保存这些版本信息。这样在分析历史问题时能明确知道当时运行的是哪个版本的智能体。设计会话“回放”功能利用记录的输入数据可以重新运行某个历史会话在相同的智能体版本下以复现和调试问题这是ctx理念的终极价值之一。10. 总结与下一步通过构建一个模拟的ctx系统我们深入理解了“为 Agent Sessions 提供 git blame 能力”这一概念的核心价值将黑盒的 AI 决策过程变为白盒提供可追溯、可调试、可分析的透明化管道。这个自建的原型展示了从数据记录、存储、查询到可视化的完整链路。虽然简陋但具备了核心功能。在实际项目中你可以基于此框架根据所选用的智能体框架LangChain, AutoGen等进行深度集成例如利用其提供的 Callback 系统来无侵入式地捕获更精细的内部事件。最值得尝试的下一步与 LangChain Callbacks 深度集成替换我们手动的record_step调用使用 LangChain 的BaseCallbackHandler来自动追踪所有的 LLM 调用、工具执行和链式操作这是实现零侵入集成的关键。探索开源替代品在投入大量时间自建之前调研现有的开源工具如LangSmith、Arize Phoenix、Weights Biases的 LLM 追踪功能它们可能提供了更成熟、功能更全面的解决方案。定义团队规范与你的团队一起确定哪些信息必须记录、记录粒度如何、保存多久并制定相应的数据治理策略。最容易踩的坑过度记录影响性能什么都记会导致系统变慢、日志爆炸。一开始就要设计好采样和过滤策略。数据格式不兼容不同工具或 LLM 返回的数据结构差异很大追踪器需要具备良好的兼容性和扩展性。忽略隐私与合规切记你记录的可能是真实用户数据。从第一天起就要考虑加密、脱敏和访问控制。将这个追踪能力作为智能体系统的“标配”不仅能极大提升调试效率还能为模型效果评估、流程优化和合规审计打下坚实的基础。建议将本文的示例代码作为起点逐步迭代出适合自己业务场景的智能体可观测性平台。