智能体追踪

关于追踪

追踪是智能体在运行期间执行的所有操作的详细记录，包括采取的步骤、处理的数据、做出的决策和生成的结果。 每个追踪都捕获智能体行为的完整时间线，包括时间戳、错误、输入/输出和上下文元数据。 追踪记录用于：

• 调试和故障排除：准确识别智能体故障或意外行为。
• 性能分析：评估智能体运行的延迟、错误和吞吐量以优化行为。
• 合规和审计：保持智能体的操作、操作时间和方式的可验证记录，这对于审计或监管工作流至关重要。
• 持续改进：使用追踪洞察微调智能体逻辑，调整行为或训练新模型。

下表概述了追踪记录可视化可以增强您调试、分析和优化智能体行为的常见用例。每个示例都重点介绍了追踪数据如何帮助在开发和 runtime 监控期间发现洞察并推动更好的决策。

Use case	追踪记录为您提供哪些帮助
工具调用期间智能体故障	查找并检查具体的步骤、输入、输出和错误
速度较慢	使用时间戳定位瓶颈
调查错误激增的情况	按状态筛选运行并追踪模式
验证生产修复	重现原始运行，并确认此问题不再发生
准备审计报告	导出或查看显示决策路径和已处理数据的追踪记录

追踪类型

追踪有两种不同类型，每种类型都有特定用途，用于理解和分析智能体行为：

• 智能体运行追踪：这些追踪记录智能体在实时或计划运行期间的逐步执行。 它们显示了智能体如何处理数据、调用工具、处理条件以及对不同状态进行实时响应。
• 评估运行追踪：当智能体根据预定义输入进行测试时，通常是在模型评估、场景验证或测试用例期间，会生成评估追踪。 这些有助于评估智能体的准确性、决策质量和受控条件下的行为。

访问追踪记录

您可以从两个关键位置访问这两种类型的追踪记录：

• Agent Builder – 在设计或测试智能体时，追踪在 Agent Builder 中直接可用：
  • 运行智能体时，底部面板会自动打开 Execution Trail（执行追踪记录）选项卡，显示当前运行的实时跟踪。您还可以切换到“历史记录”选项卡，以查看过去的运行，并直接将其添加到评估集中。
  • “评估”和“输出”选项卡提供了最近运行情况的另一个视图，您可以在其中检查行为和结果以及智能体定义。
• “智能体实例”页面 – 导航到“智能体 > 实例”版块。 在这里选择一个智能体，然后选择任何运行以打开其追踪视图，其中包括完整的可视化追踪和日志面板。

在查看智能体运行或评估运行的追踪记录时，您可以看到智能体的执行情况。您可以：

• 查看彩色标记节点所示的执行结果：成功、失败或重试。
• 将鼠标悬停在任何节点上，以预览开始和结束时间戳、执行状态、输入和输出代码段。
• 选择一个节点以查看详细信息，包括完整的 JSON 有效负载、日志和错误、runtime 指标（令牌使用情况、延迟）。

管理追踪数据的访问权限

本节概述了管理员如何使用基于角色的访问控制模型配置追踪数据访问权限。

要查看追踪日志，您需要以下权限：

• Logs.View
• Jobs.View

有关默认角色权限的详细信息，请参阅“默认角色”。

以下矩阵介绍了基于权限组合的可见性结果。这些组合定义了您可以查看的详细追踪信息，具体取决于您的角色权限。

Logs.View	Jobs.View	访问结果
启用	启用	所有属性
启用	禁用	所有属性
禁用	启用	部分属性（例如，名称、类型）
禁用	禁用	无访问权限

当你缺少查看追踪数据的必要权限时，您会看到一条消息，说明访问权限是完全受限还是部分受限，并提供请求必要权限的指导。

备注：

追踪数据，包括输入和输出数据，可以使用客户托管密钥 (CMK) 进行加密。智能体追踪 CMK 加密是一项可选功能，为您的组织配置 CMK 时，该功能不会自动启用。要启用该功能，请提交支持工单。有关详细信息，请参阅《管理员指南》中的“按服务加密”。

对智能体运行的反馈（预览）

反馈是解释和改进智能体 runtime 的关键机制。利用反馈，您可以查看行为、诊断问题，并记录有关智能体如何做出决策的有意义模式。

除了调试之外，反馈还充当基于反馈的情景记忆的核心输入，让智能体能够逐步优化其决策策略，无需为每次调整重写完整的提示词。

反馈和记忆之间的关系

虽然反馈充当批注工具，但其最强大的应用是影响情景记忆。

提供有关追踪的反馈，突出显示智能体在未来运行时应复制或避免的行为。

• 演进而非重复：与静态解决方案不同，借助基于反馈的记忆，智能体的行为将随时间推移而不断改进。智能体学习识别被标记为正确或不正确的模式。
• 针对性改进：此方法在智能体经常“接近正确”或决策策略尚在形成的流程中尤为有效。
• 选择性记忆：并非所有反馈都会自动变成记忆。您必须主动确定哪些批注代表高价值学习机会，以防止低质量或不一致的反馈导致性能下降。

在何处应用反馈

您可以在智能体追踪中提供有关任何跨度的反馈。借助这种灵活性，您可以在查看或诊断行为时对特定的工具调用、防护机制检查或 LLM 输出进行批注。

只有应用于智能体运行跨度的反馈才有资格获得情景记忆。虽然您可以对追踪的任何部分进行批注以供分析，但只有直接附加到智能体运行跨度的反馈才会作为记忆存储并在将来的运行中进行检索。

何时应用反馈

虽然提供有关所有追踪的反馈会最大化迭代式学习的效果，但在实践中，您应专注于可提供最高优化价值的追踪。

重点关注以下场景：

• 关键场景：涉及高风险决策或高影响错误的追踪。
• 重复模式：智能体始终难以解决或出现重复故障的区域。
• 艰难决策：智能体面临复杂选择的实例。
• 消极情绪：导致用户体验较差的运行。
• 模型行为：清晰演示您希望智能体严格复制或严格避免的特定行为的示例。

应用反馈对于持续改进至关重要。利用反馈，您可以对更优行为进行增量编码，使智能体运行更加可靠和一致。

• 对追踪排定优先级：重点关注关键场景中的追踪、影响较大的错误或智能体难以解决的重复模式。
• 高价值场景：将优先处理代表智能体的艰难决策、体现负面用户情绪或清晰说明您希望智能体复制或避免的行为的运行。
• 重点领域：清晰识别您要提供反馈的内容：
  • 输出：最终结果是否符合预期？
  • 计划执行（轨迹）：智能体是否按预期顺序执行任务步骤？
  • 评论：使用评论来丰富反馈内容，并为记忆检索提供依据。

Custom Time-to-Live settings for traces

You can use the AI Trust Layer policy in Automation Ops to configure how long trace spans are retained by setting custom Time-to-Live (TTL).

Traces Time-to-Live defines the retention window for execution traces in the AI Trust Layer. Each trace consists of spans that record the steps of an automation or AI interaction. The TTL setting determines how long these spans remain available, and automatically deletes any data older than the selected duration.

This feature gives you fine-grained control over trace visibility, allowing you to align retention with your privacy, compliance, and operational requirements.

The policy is enforced at the tenant level, meaning the configured TTL applies to all spans and affects what every user in the tenant is able to view.

Within the Automation Ops policy settings under the AI Trust Layer feature toggles, you can enable or disable TTL enforcement:

• When enabled: spans are retained for the number of days specified in the TTL Days field and deleted automatically once they expire.
• When disabled: traces are not subject to a strict TTL policy.

To enable and configure custom TTLs for traces, follow these steps:

1. Navigate to Automation Ops.
2. If you don’t already have an AI Trust Layer policy, select Add Product Policy – AI Trust Layer. Otherwise, open and edit your existing policy.
3. Select Feature Toggles.
4. 配置以下字段：
   • Time-To-Live enforcement for trace data – When enabled, this setting controls how long spans remain visible before being removed. After the TTL expires, all affected spans are permanently deleted from the UI.
     • TTL days – Specifies the number of days that trace spans are stored before being purged.
   • Restricted Insights Trace data – If enabled, all non-UiPath metadata is removed from trace data before it is sent to Insights. This limits the detail available in Insights and affects the ability to view detailed or aggregated metrics on the Agents page.

备注：

If feedback or memory is added to any span within a trace, the entire trace is preserved and no longer subject to the configured TTL. To allow the trace to be cleaned up, you must first remove the associated feedback or memory.

Trace governance implications

Configuring custom TTLs for trace data has several important effects:

• Analytics: Your TTL configuration determines how much historical trace data is available for analysis. Shorter retention supports stricter data-minimization requirements, while longer retention preserves more execution context for investigation and troubleshooting.
• Data deletion: Spans are automatically deleted once they exceed the configured TTL. Changing your TTL does not restore any data that has already expired or been restricted.
• Visibility: Execution runs that fall outside the TTL window no longer appear in the Traces UI or in components that rely on speed-layer trace data.
• Scope: The configured TTL applies to all spans within the tenant and affects visibility for every user.
• Exceptions: Some features may bypass TTL entirely, such as agent memory and trace feedback. Data for these features is retained indefinitely until a dedicated end-of-life policy is defined.