103 篇博文 含有标签「agents」

你的监控栈能告诉你关于请求率、CPU 和数据库延迟的一切。但它几乎无法告诉你你的 LLM 是否刚刚幻觉出了一个退款政策，为什么一个面向客户的智能体在回答一个简单问题时循环调用了三次工具，或者你的产品中哪个功能正每天悄悄烧掉 800 美元的 Token。

传统的可观测性是围绕确定性系统构建的。LLM 在结构上完全不同 —— 每次都是相同的输入，不同的输出。故障模式不再是 500 错误或超时；而是一个听起来自信且合理、但恰好错误的答案。成本也不再稳定可预测；当一个配置错误的 Prompt 遇到流量高峰时，成本会激增。调试也不再是“在堆栈跟踪中查找异常”；而是“重建为什么智能体在周二凌晨 2 点选择了这条工具路径”。

这正是 LLM 可观测性（Observability）所要解决的问题 —— 而这一领域在过去 18 个月里已经显著成熟。

当你的智能体在放弃之前，第三次默默地重试同一个损坏的工具调用时，你就会意识到，“仅仅添加工具”并不是一种生产环境的策略。工具调用解锁了真正的能力——外部数据、副作用、保证格式的输出——但使其工作的智能体循环（agentic loop）具有在演示中不会表现出来的尖锐边缘。

这篇文章将探讨这些边缘：循环实际上是如何运行的，悄悄破坏并行执行的格式规则，如何编写能让模型做出正确选择的工具描述，以及如何处理错误以让模型恢复而不是陷入死循环。

一家公司交付了 7,949 个 AI Agent。其中只有 15% 能够正常工作。其余的要么静默失败，要么陷入死循环，或者在执行任务中途前后矛盾。这并非个别现象——企业级分析一致发现，88% 的 AI Agent 项目从未进入生产阶段，95% 的生成式 AI 试点项目以失败告终或表现严重不及预期。引人入胜的演示 (Demo) 与可靠系统之间的差距并非模型问题，而是架构问题。

那些成功交付了实际可用 Agent 的工程师们，在架构决策上达成了一系列共识，而这些决策与框架教程中的玩具示例截然不同。本文将探讨这些决策：层级如何划分、故障集中在哪里，以及为什么最难的问题从来不是提示词 (Prompt)。

LLM 在生产环境中函数调用失败最令人惊讶的地方在于它们的来源。不是幻觉推理。也不是模型选错了工具。代理不稳定的首要原因在于参数构造：错误的类型、缺少必填字段、格式错误的 JSON、幻觉出的额外字段。模型本身没问题。你的 schema 才是问题所在。

这是个好消息，因为 schema 修复成本很低。

大多数 AI 团队都在错误地衡量事物，使用错误的方式，并且让错误的人参与其中。典型的评估设置是这样的：一个 1 到 5 的李克特量表，少量示例，以及一个初级工程师进行数据统计。然后有人会构建一个 LLM 评判者来自动化这个过程——六个月后却想不明白为什么整个系统漏洞百出。

如果方法得当，将 LLM 用作评判者是一种强大的模式。但“方法得当”这个词在句子中承载了大量工作。本文是一个具体的指南，教你如何构建与实际质量相关联、捕获真实回归问题并经受住生产环境考验的评估器。

大多数生成式 AI 项目都以失败告终——并非因为模型本身不好，而是因为团队在技术栈的每个层面都犯了相同且可预测的错误。一项 2025 年的行业分析发现，42% 的公司放弃了他们大部分的 AI 计划，而 95% 的生成式 AI 试点项目未能产生可衡量的业务影响。这些并非模型故障，而是团队本可以避免的工程和产品失败。

本文将列举那些最容易导致 AI 项目失败的陷阱——从问题选择到评估——并结合生产系统中的具体案例进行阐述。

大多数AI智能体项目失败，并非因为模型能力不足——而是因为构建这些系统的工程师在尚未积累足够经验时就急于引入复杂性。通过对数十个生产环境部署案例的深入研究，一个清晰的规律浮现出来：那些成功落地可靠智能体的团队，都从最简单的系统出发，只有在指标数据确实需要时才增加复杂度。

本文将系统梳理那些能将稳健智能体系统与容易幻觉、陷入循环、在真实负载下崩溃的系统区分开来的核心思维模型、架构模式和实践技巧。