2026西湖龙井茶官网DTC发售：茶农直供，政府溯源防伪到农户家
这是我在 dev.to 上创建的第一篇文章，我正在学习如何遵守规则并提供内容。
在 Stealth 公司，我们构建了 AgentTrace，这是一种用于人工智能代理工作流的可观测性基础设施。其前提听起来很简单：捕获代理在何时、为何以及做了哪些操作。但在实践中，为了实现这一目标，我们经历了三次传输架构的迭代，将数据模式从 JSONB 转移出来，并经历了一次生产事故，该事故在任何人察觉之前静默地丢失了 87% 的追踪数据。
以下是我们学到的经验。
- 数据模型：跨度与追踪任务
传统的分布式追踪使用“跨度”（span），其中跨度是具有父级引用、时间戳和一组属性的单个工作单元。我们保留了这一基本原语。
在 AgentTrace 中，一个跨度捕获以下信息：父跨度 ID、父追踪 ID、开始时间，以及一组依赖于类型的属性，包括客户端 IP、大语言模型 IP、状态、错误代码、大语言模型系统提示词、用户提示词和模型响应。类型决定了存在哪些属性。
但是，代理工作流并非扁平的服务调用链。一次代理运行涉及分支决策、子代理调用、工具调用和多跳推理——所有这些都嵌套在单一意图之下。原始的跨度树无法捕捉这种复杂性。
我们引入了“追踪任务”作为组织单元：即一次代理工作流的完整记录，包括由哪个代理发起、代理的目的是什么、涉及哪些节点，以及其下的完整跨度树。跨度是叶子和分支，而追踪任务是主干。
这种区分对于查询至关重要。当工程师询问“为什么这个代理失败了？”时，他们是在追踪任务层级进行查询。当他们询问“在这次大语言模型调用中究竟发生了什么？”时，他们是在深入查看某个跨度。数据模型必须支持这两种模式，而不将它们混淆。
- 数据接入：使用代理而非软件开发工具包
天真的方法是提供一个软件开发工具包（SDK），并要求开发人员对其代理代码进行检测。这会造成摩擦：企业客户并不总是控制代理运行时，而且要求为了可观测性而更改代码往往导致此事无法落实。
我们通过网络层的 Envoy 代理解决了这个问题。任何通过标准协议通信的代理都会透明地发出追踪数据，因为代理会拦截流量、提取相关字段并发出跨度，而无需代理知晓可观测性的存在。对于可以使用软件开发工具包的客户，它可以直接集成。对于无法使用的客户，代理可以在不更改代码的情况下工作。
- 管道：收集器与处理器
在代理和数据库之间，存在着两个不同的服务。
追踪收集器是摄入端：它接收来自边车代理和普通代理的跨度，验证它们，并发布到事件传输层。这里是处理吞吐量和可靠性的关键所在。
追踪处理器是消费端：它从传输层读取事件，将跨度组装成其追踪任务树结构，处理详细记录，并写入 PostgreSQL 数据库。
这种分离很重要，因为这两个服务具有不同的故障模式和扩展需求。收集器 需要能够在不阻塞的情况下吸收突发性的数据摄入；处理器 需要正确写入结构化查询语言（SQL）并保持树结构的一致性。如果将它们耦合在一起，意味着缓慢的写入路径会堵塞摄入管道。
一个不明显的问题是：你如何知道一个追踪何时完成？如果代理工作流不发送保证的“完成”信号，跨度就会持续到达。收集器 需要决定何时关闭追踪并将其移交给 处理器，但过早关闭意味着
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
