北京
生成式AI热潮的第一波，往往从一个“Hello World”式智能体开始：一段简单脚本把大语言模型接到几个工具上，跑在本地笔记本或临时云函数里。它能用，效果也很惊艳，但一旦尝试规模化，就迅速崩溃。
在生产环境中，大语言模型应用不只是软件，它们是叠加在确定性基础设施之上的随机系统。大语言模型输出的非确定性，带来了传统软件可观测性——日志、指标和链路追踪——从未设计去处理的一类故障模式。
你没法简单地对提示词做哈希来定位某个错误，因为提示词每次可能略有变化，但语义意图却完全相同。要从原型走向生产，工程师必须采用专门的架构思维。
确定性悖论：传统调试方法失效
进入架构之前，先要承认核心挑战：确定性悖论。传统软件是确定性的，给定输入X，总能得到输出Y。你可以对它做单元测试、缓存，并即时复现故障。
大语言模型是概率性的，给定输入X，可能得到输出Y、Z，或者一个幻觉出来的错误结果，取决于温度和上下文窗口。当引入智能体——即大语言模型循环、推理并调用外部工具的系统——复杂度会指数级上升。
一次智能体调用可能衍生出15次工具调用。如果某个工具因网络超时失败，这算工具的错还是智能体的错？如果智能体决定不必要地调用某个工具，这是逻辑错误还是提示词中的语义歧义？调试这类问题，需要从根本上改变观察和度量软件行为的方式。
为概率系统构建可观测性
OpenTelemetry标准已经成为现代分布式追踪的骨干。但把原生OpenTelemetry直接套用到AI智能体上并不够，因为它捕获了执行过程，却丢失了语义。
在微服务架构中，追踪GET /users/123是一致的。在智能体架构中，查询可能是“查找John的最后一笔订单”，也可能是“我2022年在哪里买的鞋”。两者最终都触发数据库查询，但意图不同。
要构建生产级可观测性流水线，需要四个不同的数据平面：
- 大语言模型追踪：每次大语言模型调用的标准请求/响应日志，包括输入令牌、输出令牌、延迟、模型版本和提示词模板。
- 嵌入向量：捕获输入和输出的向量表示，支持跨历史交互进行相似性搜索。
原文在此处截断，后续关于记忆层与护栏架构的内容未提供，因此无法进一步展开。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
