应用AI工程师转型指南

我写下这篇文章，作为我希望在转型为应用 AI 工程师之前就能拥有的指南。

这个角色与传统软件工程有广泛的重叠，但它增加了一些大多数软件工程师在转型时不得不学习的重要概念。我建议你将其视为核心主题大纲，在你想深入了解时，再跟随文章中的链接资源进一步学习。

到本文结尾，你将更清楚地理解什么是应用 AI 工程、这份工作的实际要求，以及它如何超越传统软件工程。

话虽如此，理解应用 AI 工程的最佳方式是先审视你对构建软件的思维方式的转变。

软件工程与 AI 工程

传统软件工程与 AI 工程师最大的区别在于，前者训练你确定性思考，而后者迫使你概率性思考。

在常规软件中，你编写逻辑、运行程序，当出现问题时通常可以追溯——结构化输入确定性地产生结构化输出。

应用 AI 并非如此。你围绕一个非确定性的智能 API 调用构建系统，这意味着相同的输入每次可能返回不同的结果。因此，你的工作不再仅仅是构建软件，而是衡量系统是否确实按预期运行。

我们通过评估（evals）来实现这一点，因此我将详细说明如何构建一个评估套件，确保你开发的智能体不犯错误。我逐渐认识到，鉴于工作的非确定性本质，这是应用 AI 开发者最重要的技能之一。

文章的下一部分涵盖开发 AI 智能体的每个部分（当然，除了模型本身），因为你可以调用模型的 API，但其他一切都需要你自己构建。这被称为工具链工程（harness engineering）。

最后，我将介绍如何从单个智能体生产部署发展到多个智能体——以及为什么这是一个分布式系统问题。如果你能坚持读完这篇文章，那么你应该完全有能力转型成为应用 AI 工程师。

评估（Evals）

应用 AI 工程师通过评估将不确定性转化为可衡量的信心。在传统软件开发中，你信任系统，因为你编写了逻辑并测试了代码。但在应用 AI 中，你不能以这种方式信任系统，因为模型在不同运行中行为可能不同。因此，AI 工程师必须在智能体周围构建一个测量层。

评估的过程是：给智能体一个任务，让它运行，然后对其行为进行评分。目标是证明两件事：智能体正确完成了工作，并且智能体保持在给定边界内。

第一步是评分结果。这是评估过程中最简单的一步。对于我通常处理的发票智能体，这意味着确保发票到达正确的位置，或者重复项被标记。你只是在比较最终结果与应该发生的情况。

第二步是评分轨迹。这是智能体达到该结果的路径：它调用的工具、它接触的字段、它传递的参数以及它沿途尝试的操作。这很重要，因为智能体可能得出正确的最终答案，但在此过程中仍然做了危险的事情。它可以正确分类发票，同时更改银行详细信息或在批准前发送付款。

轨迹本身只是一个日志：智能体调用的每个工具及其传递的参数的顺序列表——评分只是意味着针对该日志编写检查。

一些检查是确定性的——确保 send_payment 永远不会出现在批准调用之前，检查写入的字段仅限于智能体允许写入的字段。其他检查是判断性的——升级是否适当，推理是否证明了行动的合理性。这些将交给一个带有评分标准的第二个模型。

要遵循的一般原则是，确定性检查通常捕获安全违规，而评判模型则负责质量评分。

结果是每个测试用例有两个评分：智能体是否得到了正确的答案，以及它是否以正确的方式得到了答案。这些需要分别报告，因为一个在 95% 的时间内正确分类发票，但在 4% 的运行中触及了禁止字段的智能体，在综合评分上看起来很好，但在生产环境中会导致重大的业务问题。

本文是对评估以及所涵盖的所有其他主题的介绍，因此我链接了其他资源来帮助你深入学习。一些帮助我理解如何构建有效评估的资源包括：

• Anthropic 的评估课程
• Lenny 的评估完整指南
• Hamel 的评估常见问题

我建议逐一阅读，但从 Lenny 和 Hamel 的文章开始，然后再看评估课程（后者稍微更偏实践）。

但评估仍然需要一个智能体来测试，而模型周围的所有东西都必须由你构建。这个周围系统被称为工具链（harness）——下一部分将介绍如何思考工具链工程过程的每个部分，从工具调用到上下文窗口优化。

工具链工程（Harness Engineering）

模型本身并不是智能体。模型可以推理、分类、编写和决策，但它无法独自在公司内部运作。它可以说明应该采取什么行动，但除非你围绕它构建系统——这个系统就是工具链——否则它无法安全地执行该行动。

工具链是模型周围的一切，它将 API 调用转化为一个可工作的智能体：包括它可以使用的工具、它看到的上下文、它记住的状态、约束它的护栏，以及让它持续工作直到任务完成的循环。

工具链的第一部分是工具执行。

模型只能读写文本，因此当模型决定做某事时，它实际上并不执行该操作。它会发出一个结构化请求（JSON 字符串）来更新记录、发送电子邮件或搜索数据库。

工具链接收该请求，验证它，运行实际操作，并将结果以文本形式发送回模型。

第二部分是上下文管理。每条指令、工具菜单、工具结果和先前的消息都会占用模型上下文窗口的空间。工具链必须决定模型当前需要看到什么、哪些内容应该被总结、哪些应该被移除。没有这个，智能体就会迷失在不相关的历史中。

我将写一篇更全面的文章，深入介绍工具链开发过程的每个部分，但目前，我建议听听 Arize 工程师的这次演讲，Arize 是智能体的持续学习平台，该演讲深入探讨了他们对上下文管理的思考过程。

要了解更多关于如何在实践中将有效的上下文管理应用于你的智能体，请阅读以下博客：

• OpenAI 的上下文管理文章
• 上下文管理实用指南
• Anthropic 的上下文工程指南

工具链工程的第三部分是状态和记忆。模型在调用之间是无状态的，因此智能体需要记住的任何东西都必须存在于模型之外（通常存储在数据库、文件存储或任务记录中）。上下文是模型当前正在查看的内容。状态是智能体知道但当前没有查看的所有内容。

第四部分是护栏。由于模型可能以与正确行动相同的自信度请求错误行为，因此工具链必须检查权限、验证输入、阻止不安全操作，并将高风险步骤路由给人类。

最后，所有这一切都在智能体循环中结合在一起：构建上下文，调用模型，检查其响应，如果允许则执行工具，存储结果，更新上下文，并重复直到任务完成。

工具链工程是你作为应用 AI 工程师要做的绝大部分工作，所以请花时间仔细阅读这一部分。作为应用 AI 工程师，你的全部工作就是构建一个操作环境，让概率性系统能够在确定性软件内部工作。

但生产环境通常不会止步于一个智能体。

随着工作流程变得更大，自然的本能是拆分工作。但一旦你添加了第二个智能体，系统设计就发生了变化。

对于单个智能体，大部分复杂性存在于一个循环内部。对于多个智能体，你现在有多个循环在同一环境中运行。每个智能体可能会读取另一个智能体刚刚更改的状态，写入另一个智能体依赖的记忆，或者调用一个结果会影响整个工作流程的工具。

此时，困难的部分不再仅仅是提示工程、评估或工具链设计。它变成了一个分布式系统问题：谁拥有哪个状态、谁可以写入记忆、哪些工具可以安全重试、以及当两个合理的智能体以错误的顺序采取行动时会发生什么。

多智能体部署是一个分布式系统问题

当第一个智能体正常工作且工作流程变大时，新的应用 AI 工程师自然会有本能将工作拆分成角色：一个智能体负责研究，一个负责规划，一个负责执行，一个负责审查。

但是第二个智能体将设计单元从智能体转变为系统。现在有多个循环在同一环境中运行——一个智能体可能更新客户状态，而另一个智能体正在基于过时的状态编写计划。两者都做出了合理的决策，但系统让这些决策以错误的顺序相互作用。

这是一个分布式系统问题。好消息是，分布式系统工程师在几十年前就解决了这些故障。你的工作是将它们应用于恰好包含 LLM 的循环中。以下是从分布式系统中适用于 AI 工程的解决方案列表：

• 单写者原则。 每一项重要的状态恰好有一个智能体可以写入它——其他智能体从中读取或提交更改请求。在工具级别强制执行：如果执行智能体是唯一可以写入 CRM 的智能体，那么无论研究智能体的推理能力有多差，它都不能破坏 CRM。

• 幂等键。 当某次调用失败或超时时，智能体会重试工具调用，但当工具已在现实世界中做出更改时，重试可能是危险的。你不想仅仅因为第一个请求看起来失败了，就让智能体重复发送相同的付款。解决方案是为每个会改变数据的工具调用附加一个唯一键——即任何在外部系统中更改数据的操作。如果工具再次看到相同的键，它应该返回原始结果，而不是第二次执行该操作。Stripe 的 API 就是这样工作的——并且这同样适用于涉及付款、电子邮件等操作的智能体开发。

• 写入的前置条件。 智能体经常基于对世界的旧视图来行动。从智能体制定计划到它尝试更新外部系统之间，某些内容可能已经发生了变化。为了防止过时写入，改变数据的工具在做出更改之前应要求一个条件。例如：“仅当状态仍为待处理时，才将状态设置为已批准。”如果状态已经更改，工具应明确失败，而不是静默地覆盖较新的状态。

• 显式交接。 通过具有定义模式的消息来传递工作，并由协调器排序。智能体应该接收其任务，而不是去发现任务。

TLDR

本文概述了我作为应用 AI 工程师所学到的最重要的主题：评估、工具链工程和多智能体系统设计。

如果你只带走一样东西，那就是——模型提供智能，但使其可靠的一切（测量层、操作环境、协调规则）都是由你工程化实现的。理解了这些，从软件工程的转型就成为了对你已有技能的延伸。

• 原文链接： x.com/eyad_khrais/status...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～