让智能体工作流可观测：Palantir AIP 的全栈遥测体系

摘要

Palantir 架构师 Chad Walquist 与可观测性（observability）负责人 Bennett 在本期 Chad 系列中，演示了 AIP 平台为复杂 AI 工作流提供的全栈可观测能力。问题背景很直白：当你在本体论（Ontology）与 LLM 之上构建复杂工作流，它会横跨众多资源——Workshop 应用、语言模型、AIP Logic 函数、自动化（automation）与智能体互相调用，你迫切需要俯瞰全局、又能下钻到每一次具体执行、每一条日志、每一个错误消息的能力。Bennett 强调：每一次调用、每一行日志都要可见，无论触发者是用户还是智能体。

演示以监控虚构企业 Onyx 的应用展开：可以按函数搜索、查看运行历史与调用链追踪（trace），下钻到请求状态、参数、本体论交互、日志行；也能排查失败——例如某函数报「与语言模型交互时权限被拒」，获取极细粒度的信息并直接采取行动。AIP Logic 函数还提供模型用量、token 计数与成本指标。智能体链越复杂（一个自动化调用动作、动作调用五个函数），跨切面（crosscutting）的追踪价值越大——尤其当工作流里跑着 70 到 100 个智能体时。

平台既自动发射大量遥测，也支持开发者用开放标准定制：演示用 TypeScript v2 函数安装 OpenTelemetry API（npm 数百万次安装的库），自定义 span 与自动埋点（每个出站网络请求）混合；AIP Logic 团队还提供了实时调试器视图。客户 Gallatin AI 借此在生产中优化了复杂工作流。下一步方向包括平台内指标与告警、符合 OTel 格式的流式数据集导出，以及跨平台统一的「一键看追踪」体验。

正文

一、可观测性：从「什么鬼在发生」到完整追踪

Bennett 开门见山地定义了 AI 时代的可观测性：如果他在本体论与 LLM 之上构建复杂工作流，它必然横跨许多构建在本体论之上的资源。他需要跨所有这些产品看到追踪（tracing）、请求历史与日志；既要俯瞰全局（bird's eye view），也要能下钻到具体的执行、具体的日志、具体的错误消息，弄清复杂工作流里到底在发生什么——无论触发者是用户本人，还是自动化或智能体。他的要求是：每一次调用、每一行日志，都要有可见性。Chad 补充了痛点：「当智能体调用智能体时，你只会想——什么鬼在发生？」把可观测性贯穿智能体与人类流程、并落地在高度可审计的环境中，正是 Bennett 团队聚焦的方向。

演示应用是监控虚构企业 Onyx 的企业级应用，包含多层 Workshop 应用、多层语言模型、AIP Logic 函数与本体论。先打开幕后看工作流的复杂性，然后搜索具体函数——Titan 库存迁移模型——打开运行历史：可以看到它被自动化调用、调用发生在何时、运行时长；进入某次具体调用，看到函数调用的追踪：请求、状态、结果、参数、与本体论的具体交互，以及日志行（来自编排工作流的高信任服务或用户在 Foundry 中编写的代码）。

好例子之后是坏例子：Titan 视觉图像处理函数在编排某些工作流时出现失败。进入日志详情查看失败，点击「调查」获得极细粒度信息——「这是与语言模型交互时的权限被拒错误」——然后直接行动：修复、继续构建。Bennett 的愿景就是：在复杂工作流中搜索可执行对象、查看运行历史、执行追踪与关联日志，深入理解复杂系统内部。

二、深入调用链：追踪、日志、指标与失败排查

一个大型复杂应用里，本体对象、AI 智能体、人类调用函数无处不在。Chad 指出关键点：不仅要知道函数之间如何连接，更要看到具体的一次次调用——可审计的日志与调用记录：谁做的、从哪里、何时做的。而且调用不会总是「一个简单函数调用本体论」：可能是一整条复杂链——自动化调用动作、动作再调用五个不同函数。你需要看到这种跨切面的可观测性如何穿过接缝，以及 Foundry 如何为你整合这一切。当工作流持续运转、你引入了新模型，能否在细粒度层面持续看清它的表现，非常重要。

AIP Logic 函数视图展示了模型使用情况：这些函数交互的模型、token 计数与成本——不仅有细粒度日志与追踪，还在工作流之上给出指标，让你看到资源花在哪里。对理解跨工作流的 LLM 用量，这极其重要。深入一个被自动化触发的 AIP Logic 函数：查看详情与追踪——AIP Logic 效果经 Automate 执行，带有细粒度标签（触发的监控 ID、版本、RID），下钻到 AIP Logic 函数上的粒度 span：这是一次本体论编辑（写回本体），再一路下到被调用的模型、持续时间、执行的动作、token 用量、发往语言模型的请求——构建者需要的一切细粒度可见性都在这里。

Chad 特别称赞堆栈追踪（stack trace）视图：智能体流程的「操作顺序」一目了然——有时它们会循环，为推理反复调用模型多次。能看到执行顺序、调用了什么、直接跳到某次具体调用去调试，这对排查至关重要。而且这只是开始：未来会有更多资源向这个视图发射遥测。当工作流里跑着 70 甚至 100 个智能体时，这种可观测性从「好用」变成「绝对关键」——这正是规模化的前提。

三、自定义遥测与开放标准

平台不仅自动发射大量遥测，还投入巨资让构建者定制自己发射的遥测，并使用开放、标准的库。演示的 TypeScript v2 函数「high priority tickets」展示了这一点：开发者从库中安装了 OpenTelemetry API 与 API logs 库——这些库在 npm 上有数百万次安装、在 TypeScript 开发者社区被广泛使用。函数里获取 tracer、启动自定义 span，调用 AIP Logic 函数筛选未解决支持工单（非常标准的查询），再让 AIP Logic 函数总结最重要的工单、以用户口吻给出「哪些工单最该优先处理」。

打开运行历史与日志详情，能看到自定义 span 被发射出来。TypeScript v2 的一个好处是自动埋点（auto-instrument）每一个出站网络请求——可以看到与 API 网关的交互被直接埋点。开发者自定义 span 与 AIP 开箱即用的自动埋点相结合，正是希望鼓励构建者对自己的系统拥有更多可见性与信任——尤其是在异构的企业架构中，让这些日志与其余系统并列、用于告警或其他需求，非常有用。

Bennett 还特别致敬 AIP Logic 团队：他们在产品里构建了非常出色的调试器视图。预览运行中能看到实时发射的追踪、实时调试器、业务逻辑的细粒度实时步骤——这种可见性带来巨大信心。Chad 说这是他最喜欢的演示之一：尤其是非常复杂的逻辑函数，实时看到链式思考推理在堆栈追踪中展开、找到「最长的杆」（耗时瓶颈），对构建者调试「是哪个模型、我怎么调提示词、发生了什么」帮助极大——变量太多了，能在那个视图中看到一切非常棒。

四、客户实践与未来：从流式数据集到一体化监控

更复杂的工作流示例是「汽车推荐自动化」：收到一辆新车、进行处理——五六个动作依次执行、进入四五个函数，用户代码与函数调用一路下探到模型。可以看到发往 LLM 的确切数据（「你是一个总结汽车维修报告、预测复发可能性的助手」）并审计这些工作；结合自定义日志，看到为唯一 ID 做出的推荐、所有 LLM 请求、token 用量、成功执行，再回到追踪视图看时间花在哪里，前瞻性地优化这条复杂调用链。Chad 把它上升为业务流程视角：订单到现金（order to cash）——制造商接到订单，判断库存、原材料与产能是否足够——整条业务流程都能这样查看：全程关联的日志、耗时，甚至精确到「某个对象被创建的那个实例」。想诊断一张异常工单？你可以在一个地方看到整个事情的每一个细节。写回系统、进一步自动化时，还能获得整条链的完整历史——不只今天，还有昨天、上周，形成对系统的整体理解。

过去这些数据分散在大量系统中：丢进日志聚合器再查询不够业务友好，或者把一堆表 join 起来试图理解业务流程——而现在，血缘（lineage）随着流程实际发生被全程追踪，带着最细的细节。客户案例方面，Gallatin AI 在 Foundry 之上构建了非常复杂的 ODK 第三方应用：在生产中获得本体加载、函数调用与动作调用的可见性后，他们不再靠猜，而是用真实数据、真实遥测找到系统需要改进之处，大幅优化了工作流。双管齐下的另一面是：平台内体验之外，强大的构建者可以把日志导出到流式数据集（streaming dataset）与第三方系统——许多前向部署工程师已经在用流式数据集构建复杂的分析 Workshop 与监控视图。这些日志流甚至可以再本体论化（ontologize），在之上构建对自己应用（包括面向消费者的应用）的监控与告警应用——形成第二轮回写与反馈循环。

展望未来几个月，Bennett 最兴奋的三件事：第一，AIP 工作流的平台内指标与监控——动作、函数、自动化，「出问题时我要被呼叫、被告警」，并有信心系统被完全监控；第二，把流式数据集做成符合 OpenTelemetry（OTel）格式，让强力构建者导出到第三方系统自由使用——「我们想要出色的默认值、出色的平台内体验，但也要成为互操作性的家园」；第三，AIP 遥测数据存储已跨不同平台、产品与团队汇聚到中心位置，下一步是如何让用户最方便地触达——「我有一个错误，能不能一键看到我的追踪、我的日志？」这个能力已经进入 Workflow Builder，很快会出现在更多地方。