Trajectory features organize the identifiable behaviors in an execution process into events. This helps you filter issues by dimensions such as tool, agent, model, or file, and return to the specific execution steps to view evidence.
Scope and prerequisites
The current page provides four types of features: tool, skill, memory, and file. Before you use this feature, make sure that the corresponding feature processing and query capabilities are available in the current environment and that event data exists in the resource.
|
Feature type |
Main purpose |
Interpretation notes |
|
Tool |
View tool calls and the result status |
A successful tool API call does not mean that the business task is successful. |
|
Skill |
View the identified skill loading or usage behaviors |
Loading a skill does not mean that the skill has been called or that its instructions have been followed. |
|
Memory |
View the identified memory access behaviors |
Returning memory content does not mean that the model has adopted the content. |
|
File |
View the identified file access behaviors |
Events cover only the behaviors that can be identified by the current collection and processing solution. |
The existence of raw logs or trajectories does not necessarily mean that feature events exist. In particular, skill and memory identification requires matching collected content and processing configurations. The current page is used to query existing events and does not provide a general feature rule configuration wizard or AI processor configuration wizard.
Query events
-
Open the destination SessionStore and select Trajectory Features.
-
Set the time range, and then select Feature List to view events.
-
Set the type, agent, model, and status as needed, or enter search conditions in the search box.
-
If you use the search box, click Search & Analyze. Changes to structured filters trigger an update.
-
Open an event in the results to view its details and evidence.
The following example finds the events of a tool. The current data must contain the corresponding fields.
event_type:"tool" AND agent_tool_name:"search_order"
To query the events of a trajectory, use the following statement:
trajectory_id:"demo-trajectory-001"
Note: Feature fields are not exactly the same as trajectory list fields. For example, the name of a tool event usesagent_tool_name, whereas the set of tools in a trajectory usestool_names. View Event JSON or the query and analysis properties first to check the actual fields. The agent in a feature indicates the node to which the event belongs, and is not necessarily the representative agent of the trajectory.
Switch the result organization mode
The feature list supports the following organization modes.
|
Mode |
Purpose |
|
Event details |
View specific behaviors by record. You can change the time sorting order. |
|
Summary by trajectory |
Find trajectories that have a large number of events or concentrated failures. |
|
Summary by agent |
Compare the event distribution of different agents. |
|
Summary by model |
Compare the event distribution of associated models. |
Summary results can be sorted by event count, failure count, and other metrics. Both details and summaries support pagination. The current options are 20, 50, and 100 entries per page.
The counts next to candidate filter options may use a different range from the formal results and should not be used as exact totals. To determine the number of matching events, refer to the results after you submit the query.
View Log View
To check the specific fields of event records, switch to Log View, check the time range and query conditions, and then run the query again. Log View queries the processed feature events, not the raw logs of the application. If an event has multiple versions, the number of logs may differ from the number of deduplicated events in the feature list.
Different display modes may retain their own query states. After you switch, check the conditions again.
View the aggregate report
Switch to Aggregate Report to view the event statistics under the current time range and filter conditions, such as total events, associated trajectories, tool events, and failed events, and the distributions by type, status, tool, agent, model, and file.
The report statistics are not a simple sum of the currently visible list page. Ranking charts may display only the top items, and objects that do not appear do not necessarily have no events.
Take note of the following differences in scope:
-
Trends are organized by event record time and should not be directly used as the distribution of the actual occurrence time of business actions.
-
If you drill down from grouped results and then switch to the report, check the filter conditions again. Do not assume that the group restriction automatically becomes a report condition.
-
The current report does not support selecting or editing dashboard templates. Do not use it as a complete dashboard that can be freely arranged.
View execution evidence from an event
-
Open an event in the event list.
-
On the Details tab, view the event type, name, status, and related identifiers.
-
On the Evidence tab, view the available content, and use the entries that are provided on the page to locate the execution step or open the raw trajectory.
-
To check the complete fields, view Event JSON.
The same tool call may be associated with file, skill, or memory events at the same time. You can use the associated events to understand an operation, but you cannot add them all up as the number of tool calls.
Event evidence requires the trajectory records of the corresponding version. If the page prompts that evidence is missing, the destination version does not exist, or you do not have access permissions, do not use a newer version instead to draw historical conclusions.
Understand event status and updates
|
Status or symptom |
Meaning |
|
Successful |
The interface or operation reported by the current event is successful. You still need to consider the business result. |
|
Error |
The current event contains a failure signal. You can further check the execution evidence. |
|
Completed |
The event has ended, but the business success or failure is not necessarily determined. |
|
Unknown or missing information |
The data is insufficient for the corresponding judgment. This does not mean success and should not be automatically counted as a failure. |
A feature query first filters events by the current time and conditions, and then selects the newer version of the matched events. For example, a query by error status may match a historical error record that has since recovered. To check whether an event is still failing, further check the update records and the corresponding evidence.
Empty list or request failure
If the list is empty, clear the filters, expand the time range to a reasonable range, and then check whether the corresponding event processing is enabled. The absence of skill or memory events does not prove that the application has no related behaviors.
If the page explicitly reports that a resource does not exist or a permission error occurs, resolve the resource and permission issues first. Do not interpret a request failure as zero events. Similarly, the report should not use empty results in place of statistics that failed to complete.