From Spans to Trajectories: Observability for Long-Running Agents

TL;DR: 随着AI智能体运行时间从分钟延长到数天甚至数百步，传统可观测性方法失效，需要转向基于轨迹的可观测性驱动开发来监控和调试长时间运行的智能体。 ## 背景：智能体的风险与挑战 我是Sunny，Honeycomb的创始工程师。Honeycomb是一个可观测性与评估平台。如果你的智能体在生产环境中运行，你需要监控它、评估它。我们正好有相关产品。 2026年的典型智能体：我们原本想部署的是一个“好孩子”，能帮公司完成各种任务；结果实际上线的是一个拥有root权限、能执行`rm -rf`的“好孩子”。随着模型和智能体越来越强大，赋予它们的权限越来越多，风险也在急剧增加。 ### 三个真实事故 1. **LangChain智能体连续运行11天，产生47,000美元费用，最后什么都没干成**（2025年3月）。 2. **智能体删除系统文件**——比如删除你Mac上的系统文件。 3. **智能体读取超大文件，导致上下文爆炸，污染整个会话**。 用过Claude Code的人应该对这些情况很熟悉。 ## 智能体发展的三个阶段 ### 第一阶段：教LLM如何思考 - 提示工程、上下文工程、RAG、评估（evals）——概念来自机器学习，后被智能体公司采纳。 ### 第二阶段：编排框架兴起（2024-2025） - o1-mini、o3-mini时期。 - Crew AI、LangChain等框架流行。 - MCP出现，React智能体出现。 - 试图教模型如何规划，状态机和状态追踪开始兴起。 ### 第三阶段：自主智能体（2026） - 模型变得更强、更自主（如Claude Code、Opus 4.7）。 - 不再试图教它们如何思考或规划，而是直接给它们工具、技能，让它们自己想办法。 - 范式转向“harness”（套件）和“sandbox”（沙箱）——你建一个沙箱，给工具和信用卡，让智能体自由发挥。 ## Harness：长时间运行的循环 Harness本质上是一个环绕LLM的循环，可以运行几小时甚至几天。在这个循环里： - 调用LLM； - LLM选择配置沙箱、调用工具、协调子智能体。 借用Anthropic的类比：**大脑**是LLM和其周围的harness，**手**是沙箱和工具。 现代harness的特点： - 长度可达100-1000步。 - 2026年趋势：把“手”设计得非常好（安全、访问控制），harness层通常很薄。 - 随着模型变强，harness层将继续保持薄的状态。 ## 可视化：真实轨迹示例 我用HoneyHive追踪了自己的Claude Code会话。例如一个开发功能的任务，产生了**689个事件**，包含几百次工具调用（bash、read、write、file edit）和大量模型事件（智能体与用户的交互）。 以前最多10-20步，现在可以是几百甚至几千步。要从中找出错误就像大海捞针——不可能逐个看完几百步再评估。这带来了前所未有的挑战。 ## Hooks与Skills ### Hooks（钩子） - 类似于webhook，在harness的各个执行点触发。 - Claude Code的hook示例：pre-tool use、post-tool use、permission requests（需要人类许可时）、task tracking、spawn sub-agents、agent start/stop。 - 这些hooks是同步的，可以用于可观测性以及客户端评估器，实现运行时护栏。 ### Skills（技能） - 被所有前沿模型支持的范式。 - 一个skill包含三部分： 1. 实际的工具执行代码； 2. skill的前言（总是嵌入智能体记忆，类似于语义钩子）； 3. skill的MD文件（指导智能体如何使用工具）。 - Skills是可复用的行为单元，例如“PR review”或“QA feature”技能，不同AI工作者可在不同上下文中使用同一技能。 ## 轨迹（Trajectory）是什么 轨迹是一系列事件或步骤。事件包括：LLM事件、工具调用、智能体委派、决策点、权限请求等。 例如，一个689步的会话轨迹可视化显示：用户轮次、bash、read、edit等反复出现，大约600次。这让你能可视化智能体的行为模式，并观察输入token数量、评估器结果等自定义字段。 ## AI工作者：目标与挑战 企业真正想要的是**AI工作者**——在特定领域内高效完成特定任务，而不是通用智能体。AI工作者应有： - 明确的成功标准（可衡量ROI）； - 清晰的护栏； - 受限的爆炸半径（出错时影响可控）； - 水平可扩展性。 ### 六种故障模式 1. **上下文腐败（Context rot）**：某个工具消耗大量token，残留在会话中，降低后续调用质量。 2. **健忘症（Amnesia）**：智能体手动尝试做已有skill或工具能做到的事。 3. **人机工程学（Ergonomics）**：工具返回嘈杂JSON、语义不直观时，智能体困惑甚至模仿工具行为。 4. **YOLO**：智能体自信执行不可逆操作而不请求许可。 5. **委派问题（Delegation）**：智能体自己干所有事，不调用子智能体。 6. **随机性（Stochasticity）**：轨迹方差极大，希望有偏好路径而非完全随机。 ## 仪表盘：发现故障模式的基础 有效的仪表盘对长时间运行智能体尤其有用： - **按工具统计token使用量**：识别膨胀上下文的工具，如bash工具每天消耗7万token。 - **步骤数量随时间变化**：例如最长会话有4600步。 - **工具使用分组**：了解智能体偏好哪些工具，哪些被低估或过度使用。 ## 评估驱动开发（Eval-Driven Development）的局限性 评估驱动开发将无法规模化，原因有三： 1. **能力超越评估基础设施**：模型变好，行为变，评估必须更新；新工具、新范式、新模型层出不穷，评估跟不上节奏。 2. **评估是静态的**：当智能体有几十万步时，评估不太有用。轨迹非确定性，方差极大，随着步数增加随机性指数增长。在第50步，不同运行可能已经处于完全不同位置。 3. **模拟困难**：模拟与生产环境的差距仍然很大。 ## 可观测性驱动开发（Observability-Driven Development） 更适合长时间运行智能体的方法，步骤： 1. **Instrumentation（插桩）**：使用Honeycomb提供的开箱即用trace支持。 2. **部署AI工作者，设置严格护栏**：创建大量护栏来理解执行边界，据此设定阈值。 3. **收集真实轨迹**：几百到上千条轨迹后，聚类技术可帮助识别任务类别，发现新故障模式。 4. **专门化**：基于轨迹模式进一步优化智能体行为。 例如，在轨迹中设置两个护栏：“不可逆操作”和“bash token超过1万”。一旦智能体越过阈值，立即告警。在Honeycomb中，可以在服务器端评估器上设置告警，至少能让你在智能体越界时得到通知。 这种方法强调从真实轨迹中学习，而非依赖静态评估或模拟。 --- Source: https://www.youtube.com/watch?v=5XFRr4xkMQk