沟通：你所需要的一切[译]

"我们遇到的问题是沟通失效。" - 《铁窗喋血》（Cool Hand Luke, 1967)

沟通是生活中最具挑战性的部分。构建大语言模型 (LLM) 应用时，沟通也是最难的部分。

新员工入职时，不论他们多聪明，都需要进行大量的沟通。这可能包括领取关键流程和最佳实践指南、由主管指导以帮助新员工快速上手，以及获取使用特定软件的权限，以确保工作顺利进行。在适应期内，持续的反馈沟通能够确保新员工在其岗位上取得成功。

正如新员工入职需要周全的沟通一样，构建智能体也需要高标准的良好沟通。无论底层的大语言模型变得多么智能，它们仍然需要适当的上下文才能可靠地运行，而这种上下文需要得到恰当传达。

💡 大多数时候，智能体表现不稳定，根本原因并非模型不够智能，而是上下文和指令没有被恰当地传达给模型。

请不要误解，模型确实会出错，而且仍有改进的空间。但更多时候，问题归根结底是基本的沟通问题。

如果我们认为沟通是构建大语言模型应用的关键，那么由此我们可以推导出一些关于智能体的"热门观点"，我已在下面简要列出。所有这些观点都可以（也许将来会）单独成篇博客文章。

为什么提示工程不会消失

随着模型的改进，诸如用小费贿赂大语言模型之类的提示工程技巧，或者纠结于 JSON 与 XML 格式的选择，都将变得近乎过时。然而，有效地、清晰地与模型沟通，并就如何处理各种场景给出明确的指令，仍然至关重要。

💡 模型不是读心术大师，如果你想让它以某种方式运行或处理特定信息，你必须提供相应的上下文。

诊断智能体为何无法正常工作的最佳方法在于：直接检查对大语言模型的实际调用记录以及提示词的具体输入。然后，设想如果将这些输入交给你所认识的最智慧的人，他们是否能给出你所期待的回复；如果不能，便需要进一步澄清你的请求，通常可通过调整提示词来实现。这个过程，也就是提示工程 (prompt engineering)，它不太可能在短期内消失。

为什么代码将构成智能体"认知架构"的很大一部分

提示词是向大语言模型传达其在智能体系统中应如何运作的一种方式，但代码同样重要。代码是传达系统行为的绝佳方式。与自然语言相比，代码能够更精确地传达你期望系统执行的步骤。

💡 你的智能体的 "认知架构" 将由代码和提示词共同构成。

某些指令智能体只能通过自然语言来传达。另一些则可以用代码或语言来表达。代码可以更精确、更高效，因此在构建智能体的"认知架构"时，我们看到在许多方面，代码比提示词更有用。

为什么你需要一个智能体框架

作为智能体开发者，为了最好地向智能体传达其应该做什么，某些代码部分是必须由你编写的。这构成了你应用的认知架构，也是你的竞争优势和护城河的一部分。

💡 还有一些通用基础设施和工具的代码需要编写，但它们并不提供差异化优势。这就是智能体框架可以提供帮助的地方。

智能体框架通过让你专注于重要的代码部分——即智能体应该做什么——来提供便利，同时处理与你的应用认知架构无关的常见问题，例如：

智能体行为的清晰流式输出
持久化以支持多租户记忆
支持人机协作交互模式的基础设施
以容错、水平可扩展的方式运行智能体

为什么 LangGraph 是目前最具可控性的智能体框架

你需要一个能够解决上述部分问题的智能体框架，但它仍然能让你尽可能清晰地（通过提示词和代码）传达智能体应该做什么。任何阻碍这一点的智能体框架都会成为障碍——即使它让入门变得更容易。坦率地说，这就是我们在 langchain 中看到的情况，它让入门很容易，但受限于内置的提示词、硬编码的 while 循环，并且不易扩展。

我们确保在 LangGraph 中解决了这个问题。

💡 LangGraph 之所以从所有其他智能体框架中脱颖而出，是因为它专注于底层、高度可控和高度可定制。

没有任何内置的东西会限制你能构建的认知架构。节点和边只不过是 Python 函数——你可以把任何你想要的东西放进去！

智能体将大量采用代码作为其认知架构的一部分。智能体框架可以帮助消除一些常见的基础设施需求。但是，它们不能限制你智能体的认知架构。那会阻碍你传达你究竟想发生什么，并且智能体将变得不可靠。

为什么像 LangGraph 这样的智能体框架将长期存在

我经常被问到一个问题是："随着模型变得更好，这是否会消除对像 LangGraph 这样的框架的需求？" 其潜在的假设是，模型将变得非常出色，以至于它们将消除对围绕大语言模型的任何代码的需求。

不会的。

如果你使用 LangGraph 从模型中获得更好的通用推理能力，那么，当然，也许有可能。

但这并不是大多数人使用它的方式。

💡 大多数人使用 LangGraph 来构建垂直领域特定的、高度定制化的智能体应用。

沟通是其中的关键部分，而代码是沟通的关键部分。沟通不会消失，代码和 LangGraph 也不会消失。

为什么构建智能体是一项多学科的工作

我们很快发现，构建智能体的团队不仅仅包括工程师。

💡 非技术领域的专家也经常在构建过程中发挥关键作用。

一个关键领域是提示工程，领域专家通常会为提示词编写最佳的自然语言指令，因为他们比工程师更了解大语言模型应该如何表现。

然而，领域专家的价值不仅仅在于提示词。他们可以审查智能体的整个"认知架构"，以确保所有逻辑（无论是用语言还是代码表达）都是正确的。LangGraph Studio 等工具可以将智能体的流程可视化，从而简化这一过程。

领域专家还能帮助调试智能体的错误，因为智能体出错通常是由于沟通失败，而领域专家非常擅长发现这种问题。

为什么我们将 LangSmith 打造成最用户友好的 LLM Ops 工具

由于人工智能工程需要多个团队协作来弄清楚如何最好地利用大语言模型进行构建，因此像 LangSmith 这样的大语言模型运维 (LLM Ops) 工具也专注于促进这种类型的协作。大部分问题分类流程的核心在于——"查看你的数据！"，我们希望在 LangSmith 中让查看大量、主要是文本的响应变得非常容易。

我们从一开始就投入了大量精力来打造美观的用户界面，以可视化智能体追踪信息。这种美观是有目的的——它使各个技术水平的领域专家更容易理解正在发生的事情。它比 JSON 日志更清晰地传达了正在发生的事情。

💡 LangSmith 中追踪信息的可视化让每个人——无论技术能力如何——都能理解智能体内部发生了什么，并为诊断任何问题做出贡献。

LangSmith 还在其他领域促进了这种跨团队协作——最值得注意的是提示词 Playground——但我喜欢用追踪信息作为例子，因为它非常微妙但又非常重要。

为什么人们要求向最终用户公开 LangSmith 追踪信息

出于上述相同的原因，我们已经收到多家公司要求向其最终用户公开 LangSmith 追踪信息。理解智能体正在做什么，不仅对开发者很重要——对最终用户也很重要！

当然，还有其他（更用户友好的方式）可以做到这一点，而不仅仅是我们的追踪信息。但听到这个要求仍然令人感到荣幸。

为什么用户界面和用户体验是人工智能领域最重要的创新方向

这篇文章的大部分内容都集中在构建人工智能智能体时，沟通的重要性，但这同样适用于最终用户。允许用户以透明、高效和可靠的方式与智能体交互，对于推广应用至关重要。

💡 人工智能应用的力量归根结底在于它在多大程度上促进了人机协作，因此我们认为用户界面/用户体验 (UI/UX) 是最重要的创新领域之一。

我们已经讨论了我们看到的正在涌现的不同智能体用户体验 (UX)（这里、这里和这里），但这个领域仍然处于非常早期的阶段。

沟通至关重要，因此最能促进人机交互的 UI/UX 将带来更好的产品。