追踪 AI 智能体执行：分布式系统中的可观测性与证据

同一学术作品的技术版。内容仍在作者审核中；DOI 和外部 URL 待定。

目录

• 摘要
• 1. 引言
• 2. 基础：追踪、跨度与会话
• 3. 可观测性问题及其信号
• 4. 方法、来源与局限性
• 5. 开放标准：OpenTelemetry GenAI
• 6. 厂商平台
• 7. 独立平台
• 8. 比较分析
• 9. 讨论：差距、风险与工程实践
• 10. 对分布式边缘环境中 SGAEIA 的概念性启示
• 11. 结论
• 术语表
• 参考文献
• 关于作者
• 研究与项目资源
• 图表
• 许可协议
• 系列连续性
• 引用建议

边缘自主代理治理的可观测性、评估与证据

SGAEIA 研究系列 — 第 18 篇文章

Aridio Silva 独立研究员，SGAEIA（安全治理的自主边缘智能架构）创作者 ORCID: 0009-0008-2411-6995

版权：© 2026 Aridio Silva | 许可：CC BY 4.0

摘要

截至 2026 年 10 月，主要 AI 代理平台能够记录执行的各个步骤，但生态系统仍缺乏稳定且统一的语义。本文结合了三项贡献：针对代理可观测性问题的概念框架；对 13 个平台的比较综述（软件包版本检查于 2026 年 10 月 10 日进行）；以及对 SGAEIA 在分布式多代理和边缘环境中影响的非规范性解读。结果表明，追踪可以重构执行路径，但无法证明结果的正确性；关键功能仍处于测试版、预览版或开发阶段；而不同的内容捕获默认设置直接带来了隐私、治理和证据连续性方面的风险。核心结论是，追踪、评估和受控证据必须作为互补功能运行：观察执行过程、评判结果，并为审计和保证保留可验证的基础。

关键词：人工智能；AI 代理；可观测性；分布式追踪；OpenTelemetry；跨度；代理评估；多代理系统；边缘 AI；SGAEIA。

1. 引言

当 AI 代理被激活时，操作员需要知道它实际做了什么：执行是否正常结束，错误或偏差出现在哪里，耗时多少、成本如何，调用了哪些工具，以及控制权移交给了哪些代理。代理在运行时选择工具和委托路径，因此其行为是非确定性的，仅凭扁平的应用程序日志无法可靠地重构其轨迹。因此，工程实践将微服务系统中的分布式追踪适应于代理生命周期。

本文探讨四个研究问题：

1. RQ1. 追踪和跨度如何应用于一个或多个 AI 代理的执行？
2. RQ2. 哪些信号能够回答关于完成、错误、偏差、持续时间、成本和已执行步骤的问题？
3. RQ3. 哪些平台提供这些功能，成熟度如何，具有哪些优势和局限性？
4. RQ4. 从 SGAEIA 的概念视角来看，追踪、评估和证据保存如何与分布式边缘代理的治理相关联？

范围涵盖来自 Anthropic、OpenAI、Google、Microsoft 和 AWS 的代理运行时；七个独立的可观测性平台；以及 OpenTelemetry 标准。语言模型本身并不生成此操作记录。追踪由执行层产生：围绕模型的 SDK、框架、编排环境或托管平台。

1. 基础：追踪、跨度与会话

Span 是追踪工作的基本单位。每个相关操作都可以生成自己的 span，通常包括开始和结束时间、父子关系、状态以及特定于操作的属性。常见的例子包括模型调用、工具调用以及交接或嵌套代理的调用。Trace 将因果相关的 spans 分组到操作的全流程中，而 session 或 thread 则可能将属于同一对话或更长运行任务的多个 trace 进行分组。

在 OpenAI Agents SDK 中，spans 暴露了诸如 started_at、ended_at、parent_id 以及步骤特定数据等字段 [R4]。AWS AgentCore 同样记录状态和事件 [R15]。术语并不完全统一：一个平台可能将 trace 定义为完整的操作，另一个平台将其定义为一个请求-响应周期，而第三个平台可能使用 session 来提供更长的边界。

2.1 改变 trace 解释的三个细微差别

首先，trace 并不总是整个任务。OpenAI 可以通过 group_id 连接多次执行 [R4]，而 AgentCore 将 trace 视为一个请求-响应周期，并将 traces 分组到一个 session 中 [R15]。因此，审查者必须在比较持续时间、成本或完成情况之前确定平台的执行边界。

其次，handoff（交接）并不总是由专用的 span 表示。OpenAI 定义了 handoff span [R4]，而 OpenTelemetry 定义了 create_agent、invoke_agent 和 execute_tool，允许子代理作为嵌套的 invoke_agent 操作出现 [R18, R19]。微软也记录了代理之间通信的语义 [R11, R44]。

第三，代理 trace 可能包含除了 model、tool 和 handoff spans 之外的更多内容。护栏检查、回合数、权限决策以及等待人类批准所花费的时间都可能是可观察的操作。例如，Claude Agent SDK 可以为等待用户授权的工具记录一个子 span [R1]。

2.2 树状结构

Spans 形成的是树状结构而非扁平列表。图 1 展示了从 session 到 traces 和嵌套 spans 的转变，包括模型调用、工具和子代理。这种层次结构支持延迟分析、因果重建和故障定位，而无需将执行过程简化为无法区分的消息流。

图 1 — 从 session 到可验证的 spans。一个 session 可以分组多个 trace；每个 trace 将代理、模型、工具和交接 spans 组织成因果结构。© 2026 Aridio Silva | Project SGAEIA | CC BY 4.0。

1. 可观测性问题及其信号

主要的分析区别在于技术上的完成与实质上的成功。一次运行可以在没有异常的情况下终止，但仍产生错误的答案、违反指令或在预期范围之外行动。Trace 报告操作事实；结果必须由单独的评估器、测试、模式验证器或人工审查来判断。

3.1 完成与结果质量

Claude Agent SDK 的结果可以报告终止子类型、错误状态、轮次数量、持续时间和成本，包括成功、最大轮次终止和执行错误等结果 [R36]。这些字段描述了执行是如何停止的；它们并不能证明所请求的目标已经实现。因此，语义故障对于普通的错误状态而言可能是不可见的 [R37]。OpenAI 的轨迹评分展示了在大规模下评估轨迹和结果的互补方法 [R5]。

3.2 错误、偏差和可审计性

错误出现在跨度状态、API 错误事件和失败的 tool 结果中。偏差需要更广泛的证据：权限事件、护栏决策、预期路径比较以及对结果状态的独立观察。Claude Code 的权限决策可以作为与最终用户关联的结构化事件导出，为审计或 SIEM 工作流提供输入 [R2]。

1. 方法、来源和局限性

本次审查于 2026 年 10 月 10 日进行，使用了三类来源：来自 PyPI 和 npm 的软件包注册表数据 [R40]；官方供应商和平台文档；以及仅在官方文档未涵盖相关要点时使用的次要技术来源。次要来源和竞争对手制作的对比内容已被识别并谨慎对待。软件包版本指的是在咨询日期时在注册表中可见的稳定发布版本。

在对比矩阵中，✔ 表示在 consulted 文档中确认的能力，◐ 表示部分或条件支持，— 表示在审阅材料中未发现该能力。矩阵中的缺失并不能证明某功能不存在。SaaS 平台没有单一的平台版本，因此当适用时，版本列报告的是相关的 SDK。

这是一项结构化的对比审查，而非系统性审查或实验基准测试。本工作不测量仪器开销，不复现供应商评估，也不建立生产环境的有效性。平台行为、价格、保留策略和成熟度标签可能在所述日期之后发生变化；采用决策必须重新验证相关文档。

1. 开放标准：OpenTelemetry GenAI

OpenTelemetry GenAI 语义规范是跨运行时和后端通用语言的首选候选者，但它们仍处于积极开发阶段 [R18–R20]。定义的操作包括 create_agent、invoke_agent 和 execute_tool；属性涵盖 agent 和 tool 的身份；指标包括 agent 运行持续时间、tool 调用次数和推理调用次数 [R18, R19]。开发状态意味着名称和行为在不同版本之间仍可能发生变化。

其实际价值在于可移植性。Datadog 接受兼容 OpenTelemetry GenAI 1.37 或更高版本的轨迹 [R28]，MLflow 可以摄入和导出这些规范 [R33]，Google ADK 原生实现了它们 [R7]。然而，可移植性仍然不完整，因为供应商 SDK 可能会发出专有跨度类型，需要 ADOT 等分发版，或依赖第三方桥接器。

1. 供应商平台

6.1 Anthropic：Claude Agent SDK、Claude Code 和托管 Agents

Claude Agent SDK 将 Claude Code 作为子进程运行，并可以导出交互、模型调用、tools、tokens、成本、权限决策和嵌套子 agent 的跨度 [R1, R2]。其主要优势在于无需强制后端即可进行 OTLP 导出，并且默认禁用读写负载的内容。局限性包括 beta 阶段的跨度名称、默认情况下静默的导出失败，以及 hook 跨度所需的额外 beta 配置；Managed Agents 还使用 beta API 头 [R1, R3]。

6.2 OpenAI Agents SDK

OpenAI 追踪功能默认启用，包含运行（run）、任务（task）、回合（turn）、智能体（agent）、生成（generation）、工具（tool）、护栏（guardrail）、交接（handoff）和音频（audio）跨度 [R4]。该平台通过 group_id 连接追踪数据，并集成追踪评分和智能体评估 [R5, R6]。其优势在于低摩擦的仪器插入和丰富的智能体特定语义；局限性包括与零数据保留追踪不兼容、默认捕获输入和输出、批量导出行为，以及依赖第三方工具来实现 OpenTelemetry 桥接 [R4, R26]。

6.3 Google ADK 和 Vertex AI Agent Engine

Google ADK 实现了 OpenTelemetry GenAI 语义，以智能体执行为根跨度，并为模型和工具操作创建子跨度 [R7, R8]。Agent Engine 将追踪数据发送至 Cloud Trace，并暴露响应时间和已执行的操作 [R9]。该设计得益于原生 OpenTelemetry 支持和托管可视化功能，而 Cloud Logging 的大小限制以及缺乏文档化的集成追踪评估工作流仍是主要约束 [R9, R10]。

6.4 Microsoft Foundry 和 Agent Framework

Microsoft 为提示词和托管智能体提供正式可用的追踪功能，并为工作流和外部智能体提供预览支持，遥测数据存储于 Application Insights 中 [R11–R14]。其多智能体语义和 Azure Monitor 集成是显著优势。成本、数据保留策略、访问角色要求以及不同文档中成熟度标签的差异需要仔细进行运营审查；在评估相关的比较中，明确标识了一个第三方来源 [R39]。

6.5 AWS Bedrock AgentCore

AgentCore 围绕会话、追踪和跨度组织可观测性，包括工具输入、输出、时间戳和错误信息 [R15]。统一的每智能体日志组可以在 IAM 和客户管理的加密控制下合并跨度、提示词和日志 [R17]。智能体跨度需要 ADOT 仪器插入，必须配置 CloudWatch 事务搜索，且经审查的文档未建立集成的结果质量评估机制 [R15, R16]。

1. 独立平台

7.1 LangSmith

LangSmith 将运行视为跨度，并将它们分组到项目和线程中。它支持 OpenTelemetry 数据摄入、分布式追踪、采样、敏感数据控制、令牌成本、仪表板和在线评估 [R21–R23]。相关局限性包括每个追踪的运行限制、针对 OpenAI Agents SDK 仅支持 Python 集成，以及由第三方报告的关于自托管的企业级条件 [R41]。

7.2 Langfuse

Langfuse 提供 MIT 许可的核心组件，支持自托管、嵌套观察、会话、智能体图、人工标注队列以及面向 OTLP 的数据摄入 [R24, R25, R45]。开源消除了许可证费用，但并未消除运营和维护平台安全的成本 [R38]。

7.3 Arize Phoenix 和 AX

Phoenix 使用 OpenTelemetry 和 OpenInference 语义来处理 LLM、工具、智能体和检索器的跨度，并包含评估、数据集、实验和提示词管理功能 [R26, R27]。Elastic License 2.0 允许广泛的内部使用，但限制了将软件作为托管服务提供的可能性，同时部分 TypeScript 评估组件仍处于早期阶段 [R26, R46]。

7.4 Datadog Agent Observability

Datadog 接受 OpenTelemetry GenAI 追踪，并使用跨度链接为多智能体管道构建执行图 [R28, R29]。它监控延迟、错误率、成本和决策，并为选定的框架提供自动仪器插入。跨追踪链接可能被存储但未绘制显示，且在审查范围内该服务仅提供 SaaS 模式。

7.5 Braintrust

Braintrust 将生产日志与离线和在线评估相结合，并集成 Claude、OpenAI 和 Google 智能体 SDK [R30–R32]。其自托管模型为混合模式，文档描述了发送至供应商控制平面的遥测数据，这对数据分析具有相关性。单独标识了一个仅作为补充上下文使用的第三方供应商档案 [R42]。

7.6 MLflow Tracing

MLflow 提供了一个与 OpenTelemetry 兼容的开源追踪层，包括 GenAI 约定的摄入和导出以及 30 多种自动集成 [R33, R34]。必须为每个集成显式启用 Autologging，这使得配置纪律成为保障边界的一部分。

7.7 Pydantic Logfire

Logfire 基于 Python 和 JavaScript SDK 构建于 OpenTelemetry 之上，并与 Pydantic AI 集成 [R35, R43, R47]。在底层审查中，评估和提示管理的主张未在官方开放页面上得到完全确认，因此评估仍标记为有条件。自托管仅限于企业安排 [R43]。

1. 对比分析

8.1 2026 年 10 月 10 日的版本和成熟度

8.2 能力矩阵

符号仅反映已审查的文档。破折号表示“在已审查的来源中未找到”，而非“该功能不存在”。

1. 讨论：差距、风险和工程实践

生态系统正趋向于 OpenTelemetry，但仍暴露出不兼容的方言。Claude 发出 claude_code.* span，OpenAI 使用带有第三方桥接的原生格式，Google 和 Microsoft 更直接地遵循 GenAI 约定，而 AWS 依赖于 ADOT。因此，多供应商部署需要一个 OpenTelemetry collector 或其他规范化层，以及用于语义变更的显式版本管理。

成熟度参差不齐。几个高价值的能力仍处于测试版、预览版或开发阶段，核心 SDK 仍使用 1.0 之前的编号。长期运行的部署应预期模式迁移，并避免将保障主张绑定到不稳定的属性名称上。

隐私风险是架构性的而非偶然的。Claude 默认不捕获读写内容 [R1]，而 OpenAI 追踪默认捕获输入和输出 [R4]。提示、工具参数、检索记录和输出可能包含个人数据、机密信息或受监管信息，因此在生产之前必须决定收集、脱敏、访问控制、保留和删除规则。

遥测数据可能会无声地失效。当导出失败不会中断智能体执行时 [R1]，缺失的追踪记录可能意味着“什么都没发生”或“证据已丢失”。因此，监控遥测管道本身就是可观测性的一部分。一个经得起推敲的部署方案应跟踪跨度（span）数量、导出器健康状况、队列丢包、时钟质量以及智能体活动与记录证据之间的时间差。

最后，追踪记录并不等同于评估结果。将追踪数据连接到评分或评估的平台涵盖了操作重建和结果分析；而其他平台则需要独立的评估者。实际采用时应将“执行结束且无错误”与“结果正确且获授权”区分开来，明确定义捕获策略，监控遥测数据的导出，并通过稳定的会话边界对相关的追踪记录进行分组。

1. 分布式边缘环境中 SGAEIA 的概念性启示

10.1 可观测性并非治理

从 SGAEIA 的角度来看，追踪是一种观察和重建能力，而非行动授权，也不是合规性的自动证明。追踪记录可以显示智能体调用了工具、转移了控制权或产生了输出，但合法性取决于权威、上下文和政策，这些无法仅从遥测数据中推断出来。这保留了以下区别：技术能力、经过身份验证的身份和声明的意图并不等于操作权限。

10.2 证据必须在分布式环境中得以保存

在云边协同环境中，执行过程可能跨越设备、服务、管理域以及间歇性断网的时段。只有在上下文能够连贯传播、标识符和时间信息保持足够可靠、保留期限与风险成比例，且能够区分证据丢失与缺乏活动时，追踪才具有价值。概念上的要求并不是要捕获所有数据，而是要保留足够的受控证据，以便在不将可观测性平面变成另一个披露渠道的前提下，重建决策及其影响。

图 2 — SGAEIA 中的追踪、评估与证据。追踪记录路径；评估考察结果的合规性与质量；受控证据在明确假设的支持下支持审计与保证。这是一种非规范性的概念解读。© 2026 Aridio Silva | Project SGAEIA | CC BY 4.0.

10.3 结果的正确性需要独立的信号

对于自主系统而言，最重要的发现是：没有异常并不意味着目标已经达成。一次运行可能干净利落地结束，却生成了错误的内容、选择了不合适的路径，或在合法范围之外采取行动。因此，保证机制必须至少区分两个维度：执行的完整性和结果的质量或合规性，防止单一的“绿色”状态掩盖语义层面的失败。

图 3 — 追踪不等于正确性。技术执行状态与结果质量是两个独立的维度；只有结合追踪与评估，才能区分操作的完成与实质性的成功。© 2026 Aridio Silva | Project SGAEIA | CC BY 4.0.

10.4 研究与验证需求

这种解释为 SGAEIA 的受控演进提出了研究问题，但并不会自动将控制措施或组件提升为规范性架构。未来的工作应评估跨智能体和域的上下文连续性、证据链对压制和篡改的抵抗力、离线及降级运行状况、采样和脱敏对可审计性的影响，以及局部事件与分布式轨迹之间的关系。任何由此得出的要求、不变量或机制都必须通过“研究到架构”流程，并在支持保证声明之前经过验证。

1. 结论

对代理执行的详细追踪在审查过的所有平台上均可行，使用跨度（spans）记录模型调用、工具使用、控制权移交及相关操作，这些跨度在追踪中按层级排列，有时还会被分组为会话。然而，该领域仍处于过渡阶段：Claude Agent SDK 的追踪功能和托管代理仍处于测试版，Foundry 工作流和外部代理的追踪包含预览范围，OpenTelemetry GenAI 规范仍处于开发阶段，且几个主要 SDK 仍保留 0.x 版本。采用者应预期到迁移成本和语义变更。

研究问题可回答如下。对于 RQ1，分布式追踪概念直接适用于代理系统，但在命名和边界上存在实质性差异。对于 RQ2，追踪信号可以回答关于完成状态、错误、持续时间和已执行步骤的问题，但结果的正确性需要独立评估。对于 RQ3，生态系统广泛，但在可移植性、隐私默认设置、成熟度、评估和托管方面发展不均。对于 RQ4，SGAEIA 应将追踪视为一种受管制的证据来源，它补充而非取代权威、评估、验证和保证。

未来工作包括对仪器开销的经验测量、对文档中标记为缺失的功能进行直接产品验证、对 OpenTelemetry GenAI 稳定化的纵向监控，以及在间歇性边缘环境中对证据连续性的实验。

术语表

• 代理（Agent）：一个在运行时使用模型决定调用哪些工具或代理的系统。
• 评估（Evaluation）：基于代码、模型或人工的结果质量评估。
• 控制权移交（Handoff）：将一个代理的控制权转移给另一个代理。
• OpenTelemetry (OTel)：用于生成和导出追踪、指标和日志的开放标准。
• OTLP：用于遥测传输的 OpenTelemetry 协议。
• 会话/线程（Session/thread）：属于一次对话或扩展任务的一组追踪。
• 跨度（Span）：具有父级关系和状态的带时间戳、带属性的被追踪工作单位。
• 追踪（Trace）：由跨度组成的端到端操作记录。
• 追踪评分（Trace grading）：为代理追踪分配分数以识别故障和回归。
• ZDR：零数据保留；在 ZDR 模式下，OpenAI Agents SDK 的追踪功能不可用。

参考文献 / 引用

所有资料来源均于 2026 年 10 月 10 日查阅。保留了源研究中的验证标记：[A] 页面完整打开；[B] 通过搜索恢复页面并与声明匹配；[C] 注册表 API 数据。第三方来源已明确标识。

供应商和标准

• R1. Anthropic. Observability with OpenTelemetry (Agent SDK). [A]
• R2. Anthropic. Monitoring (Claude Code). [A]
• R3. Anthropic. Managed Agents: observability. [B]
• R4. OpenAI. Tracing (Agents SDK). [A]
• R5. OpenAI. Trace grading. [B]
• R6. OpenAI. Evaluate agent workflows. [B]
• R7. Google. Agent activity traces (ADK). [B]
• R8. Google. Observability for agents (ADK). [B]
• R9. Google Cloud. Trace an agent (Agent Engine). [B]
• R10. Google Cloud. Observability for AI agent developers. [B]
• R11. Microsoft. Trace agent concept (Foundry). [B]
• R12. Microsoft. Set up tracing in Foundry. [B]
• R13. Microsoft. Quickstart: tracing a hosted agent. [B]
• R14. Microsoft. Enable observability for agents (Agent Framework). [B]
• R15. AWS. Observability for agentic resources in AgentCore. [A]
• R16. AWS. Add observability to AgentCore resources. [B]
• R17. AWS. Amazon Bedrock AgentCore now delivers unified observability with traces and logs in a single log group (23 July 2026). [B]
• R18. OpenTelemetry. OpenTelemetry GenAI Semantic Conventions. Official repository to which the former agent-spans documentation now points. [A]
• R19. Dash0 (third party). OpenTelemetry GenAI semantic conventions explained. [B]
• R20. DEV Community (third party). OpenTelemetry's GenAI semantic conventions are not stable yet. [B]
• R44. Microsoft. Tracing in Microsoft Foundry (earlier page mentioning Outshift). [B]

独立平台

• R21. LangChain。可观测性概念（LangSmith）。[B]
• R22. LangChain。使用 OpenTelemetry 进行追踪（LangSmith）。[B]
• R23. LangChain。可观测性操作指南（LangSmith）。[B]
• R24. Langfuse。工程澄清说明。[B]
• R25. Langfuse。数据模型。[B]
• R26. Arize。Phoenix 代码库。[B]
• R27. Atlan（第三方）。什么是 Arize。[B]
• R28. Datadog。OpenTelemetry 仪器化。[B]
• R29. Datadog。代理监控。[B]
• R30. Braintrust。自托管部署。[B]
• R31. Braintrust。发行说明。[B]
• R32. Braintrust。术语表。[B]
• R33. MLflow。用于 LLM 和代理可观测性的追踪功能。[B]
• R34. Databricks。自动追踪与集成。[B]
• R35. Pydantic。Logfire：AI 可观测性。[B]
• R45. Langfuse。AI SDK C++ 集成。[B]
• R47. Pydantic。Pydantic AI：Logfire。[B]

第三方来源与版本数据

• R36. Inference.net（第三方）。生产环境中的 Claude Agent SDK 追踪与评估。[B]
• R37. ClickHouse（第三方）。什么是 AI 代理可观测性。[B]
• R38. BenchLM（第三方）。最佳 LLM 可观测性工具。[B]
• R39. Jannik Reinhard（第三方）。Microsoft Foundry 可观测性。[B]
• R40. PyPI 和 npm 注册表，于 2026 年 10 月 10 日通过 API 访问以获取版本和发布日期。[C]
• R41. Latitude（第三方）。LLM 可观测性工具对比。[B]
• R42. RFP.wiki（第三方）。Braintrust。[B]
• R43. Pydantic。Logfire 常见问题解答。[B]
• R46. Inference.net（第三方）。面向代理可观测性的 Arize Phoenix 替代方案。[B]

关于作者

Aridio Silva 是一位驻巴西的独立研究员，致力于自主和分布式人工智能系统的架构、安全性、治理及可信度研究。

他的研究重点包括 Agentic AI（智能体 AI）、多智能体系统、边缘 AI、AI 安全、零信任、设计即安全（Security-by-Design）、AI 治理、规范驱动开发以及持续的安全保障。

他是 SGAEIA——安全治理的边缘自主智能架构（Secure Governed Autonomous Edge Intelligence Architecture）的创始人兼首席研究员。SGAEIA 是一项研究计划，旨在调查在分布式边缘云环境中运行的安全、受治理、可审计且可信的自主 AI 系统的架构基础。

研究与项目资源

1. ORCID: https://orcid.org/0009-0008-2411-6995
2. Google Scholar: https://scholar.google.com/citations?user=rPn5O48AAAAJ
3. Zenodo — SGAEIA 社区: https://zenodo.org/communities/sgaeia
4. OpenAIRE: https://explore.openaire.eu/search/find?fv0=Aridio%20Silva&f0=q
5. Medium: https://medium.com/@aridiosilva
6. DEV Community: https://dev.to/aridiosilva
7. GitHub: https://github.com/aridiosilva
8. LinkedIn: https://www.linkedin.com/in/aridio-silva-74997111/
9. 个人主页: https://aridiosilva.com
10. SGAEIA 主页: https://aridiosilva.com/sgaeia
11. SGAEIA LinkedIn: https://www.linkedin.com/company/sgaeia/

图表

封面未编号。图 1–3 为公开的概念插图，不披露任何私有的 SGAEIA 协议、算法、状态机、策略结构、阈值或执行机制。最终资产必须包含可见的署名以及嵌入的创作者、版权、项目、标题、描述和许可元数据。

许可证

除非另有注明，本文中的文本和原创概念插图均采用知识共享署名 4.0 国际许可协议（CC BY 4.0）授权。

© 2026 Aridio Silva。您可以出于任何目的分享和改编本作品，前提是给予适当的署名。

SGAEIA 软件和研究成果仍受其各自的 Apache License 2.0 约束。

自主 AI。设计即治理。证据证可信。

系列连续性

本作品属于 SGAEIA 研究系列——第 18 篇文章。直到外部发布并经作者验证后，官方主页记录、Zenodo 存档、DOI、Medium URL 和 DEV Community URL 才会正式确立。

建议引用

Silva, Aridio. (2026). Tracing AI Agent Execution: Foundations, State of the Art, and Implications for Distributed Multi-Agent Systems. SGAEIA Research Series, Article 18. CC BY 4.0. Canonical URL and DOI pending.