我们需要停止构建"Hope-and-Pray"式的AI代理。（为什么你的封装会崩溃。）
摘要
对仅依赖系统提示的简单AI代理架构的批评，认为概率性LLM需要自反思层和确定性门控以确保可靠的生产行为。作者介绍了Langoedge作为构建可信代理的解决方案。
我已经厌倦了看到那些"自主代理"实际上只是将系统提示直接连接到外部API。在测试中它有90%的时间工作正常。然后你将其推送到生产环境，它就会对一个愤怒的用户幻觉生成100%退款策略。核心问题不在于LLM，而在于架构。我们正在使用概率性引擎（语言模型），却期望它们像确定性函数（代码）一样完美运行。如果你想阻止失控的API调用，就必须引入一个自反思层。原来的流程是：提示 -> 生成 -> 执行；现在需要改为：提示 -> 草拟动作 -> 内部评估（是否违反核心规则？） -> 执行。这会增加一点延迟，但这是获得真正可预测性的唯一方法。你必须用明确的逻辑来把关关键步骤，而不仅仅是令牌。在代理执行工具调用之前，它需要先检查自己的作业。过去几个月，我在自己的初创公司Langoedge一直致力于构建这个精确的确定性编排引擎，以解决这个令人头疼的问题。我写了一篇完整的文章，介绍如何构建这些自反思评估循环，如何处理状态化交接，以及如何在生产环境中真正信任你的代理。我很好奇你们在自己的技术栈中是如何处理不可预测的webhooks以及防止失控的API调用的？
相似文章
我发布过的最可靠的数据代理，其 ~90% 是确定性代码。LLM 只负责解析意图和进行对话。不服来辩。
作者认为，AI 代理的可靠性来自于确定性代码，而非 LLM，并分享了在混乱的真实世界数据上构建可信代理的五项关键实践。
没有停止策略的AI智能体只是一个昂贵的循环
关于AI智能体可靠性的实用说明，主张生产环境中的智能体需要明确的门控机制，包括证据阈值、重试预算和影响评估，而不是仅依赖记忆来确定任务是否完成。
尝试让 agent loops 更少依赖提示，更具确定性
讨论使 AI agent loops 更少依赖提示、更具确定性的方法，旨在提高 agentic 系统的可靠性和可控性。
停止构建AI智能体。
作者认为，大多数要求构建AI智能体的创始人实际上只需要简单的自动化流程，并辅以最少的LLM集成，理由包括生产环境故障、合规障碍，以及更简单工作流带来的更高投资回报率。文章提供了一个实用的决策框架，帮助开发者和创始人优先考虑可靠的自动化，而非复杂且不可预测的智能体。
当前的AI智能体被过度炒作且存在根本性限制
本文批评当前的AI智能体被过度炒作且根本上有限，认为它们本质上是带有脚手架的大语言模型，并且其依赖的下一个词元预测使其在长期规划和问责方面不可靠。