我写下这份指南，正是希望当初自己在转型为应用 AI 工程师之前，能有人给我这样一份指引。
这个角色与传统软件工程大体上有重叠，但它增加了一些重要的概念，而大多数软件工程师在转型过程中都需要学习这些。我建议你把它当作一份核心主题大纲来理解，然后顺着文章中的链接资源深入探索。
读完本文后，你应该能更清晰地理解什么是应用 AI 工程，这份工作实际上需要什么，以及它如何超越传统软件工程。
如果你有兴趣与一支才华横溢的工程团队一起，解决应用 AI 领域一些最有趣的问题，我们随时在招聘。请访问我们的网站 varickagents.com 申请，或者推荐候选人，成功入职即可获得 2 万美元推荐奖金。
话虽如此，理解应用 AI 工程的最佳方式，还是从你思考构建软件方式的转变开始。
软件工程 vs AI 工程
软件工程师与 AI 工程师最大的区别在于，传统软件工程训练你确定性思维，而应用 AI 则迫使你进行概率性思维。
在常规软件中，你编写逻辑，让它运行，当出现问题时通常可以追踪——结构化输入确定性地产生结构化输出。
应用 AI 并非如此。你是在围绕一个非确定性的智能 API 调用进行构建，这意味着相同的输入每次可能返回不同的结果。正因如此，工作不再仅仅是构建软件，而是变成了衡量系统是否真的按预期运行。
我们通过评估（evals）来实现这一点，所以我将详细讲解如何构建一个评估套件，以确保你开发的 Agent 不会犯错。我逐渐认识到，鉴于我们工作的非确定性本质，这是应用 AI 开发者最重要的技能之一。
文章接下来的部分涵盖了开发 AI Agent 的各个组成部分（当然，模型本身除外），因为你可以调用模型的 API，但其他所有东西都需要自己构建。这被称为“框架工程”（harness engineering）。
最后，我将介绍如何从单个 Agent 上线发展到多个 Agent——以及为什么这是一个分布式系统问题。如果你能坚持读完这篇文章，你完全有能力转型成为一名应用 AI 工程师。
评估（Evals）
应用 AI 工程师通过评估将不确定性转化为可衡量的信心。在传统软件开发中，你信任系统是因为你编写了逻辑并测试了代码。在应用 AI 中，你无法以这种方式信任系统，因为模型在不同运行中可能表现不同。因此，AI 工程师必须在 Agent 周围构建一个测量层。
评估就是给 Agent 一个任务，让它运行，然后对其行为进行评分的过程。目标是证明两件事：Agent 正确完成了工作，并且 Agent 始终在其被赋予的边界内运行。
第一步是对结果进行评分。这是评估过程中最简单的一步。对于我通常处理的发票 Agent 来说，这意味着确保发票被发送到正确的位置，或者重复发票被标记出来。你只需将最终结果与预期结果进行比较。
第二步是对轨迹进行评分。这是 Agent 达成结果所走的路径：它调用了哪些工具，接触了哪些字段，传递了哪些参数，以及沿途尝试了哪些操作。这一点很重要，因为 Agent 可能得出正确的最终答案，但在此过程中却做了危险的事情。它可能正确分类了发票，但同时更改了银行信息，或者在审批前就发送了付款。
轨迹本身就是一个日志：Agent 调用的每个工具及其传递参数的顺序列表——对其进行评分，就是针对该日志编写检查。
有些检查是确定性的——确保 send_payment 永远不会出现在审批调用之前，检查只有 Agent 被允许写入的字段才被写入。其他检查则是判断性的——例如升级是否恰当，推理是否证明了行动的合理性。这些会交给第二个模型，并附带一个评分标准。
遵循的一般原则是：确定性检查通常能捕获安全违规行为，而判断模型则对质量进行评分。
结果是每个测试用例有两个评分：Agent 是否得到了正确答案，以及它在得到答案的过程中行为是否正确。这两个评分需要分开报告，因为一个能 95% 正确分类发票但在 4% 的运行中接触了禁止字段的 Agent，在综合评分上看起来很棒，但在生产环境中会造成严重的业务问题。
本文是对评估及所有其他主题的介绍，所以我链接了其他资源帮助你深入探索。以下是一些帮助我理解如何构建有效评估的资源：
我建议你逐一阅读，但先从 Lenny 和 Hamel 的文章开始，然后再学习评估课程（后者更偏实践）。
但是，评估仍然需要一个 Agent 来测试，而模型周围的一切都需要你来构建。这个外围系统被称为“框架”（harness）——下一节将介绍如何思考框架工程过程的每个部分，从工具调用到上下文窗口优化。
框架工程（Harness Engineering）
模型本身并不是一个 Agent。模型可以推理、分类、写作和决策，但它无法独自在公司内部运作。它可以说明应该采取什么行动，但除非你为其构建系统，否则它无法安全地采取该行动——而这个系统就是框架。
框架是模型周围的一切，它将 API 调用转变为一个工作的 Agent：它可以使用的工具，它看到的上下文，它记住的状态，约束它的护栏，以及让它持续工作直到任务完成的循环。
框架的第一部分是工具执行。
模型只能读写文本，所以当模型决定做某事时，它实际上并不会执行。它会发出一个结构化的请求（一个 JSON 字符串）来更新记录、发送电子邮件或搜索数据库。
框架接收该请求，验证它，运行实际操作，然后将结果以文本形式发送回模型。
第二部分是上下文管理。每条指令、工具菜单、工具结果和先前的消息都会占用模型上下文窗口中的空间。框架必须决定模型当前需要看到什么，哪些内容应该被总结，哪些应该被移除。没有这个，Agent 会在不相关的历史记录中迷失方向。
我之后会写一篇更全面的文章，深入探讨框架开发过程的每个部分，但现在，我建议你听听 Arize（一个 Agent 持续学习平台）一位工程师的演讲，其中深入探讨了他们在上下文管理方面的思考过程。
要了解如何在实践中将有效的上下文管理应用于你的 Agent，请阅读以下博客：
框架工程的第三部分是状态与记忆。模型在调用之间是无状态的，因此 Agent 需要记住的任何东西都必须存在于模型之外（通常在数据库、文件存储或任务记录中）。上下文是模型当前正在查看的内容。状态是 Agent 知道但当前未查看的所有内容。
第四部分是护栏。由于模型可能以与正确行动相同的信心请求错误的行动，框架必须检查权限、验证输入、阻止不安全的行为，并将高风险步骤路由给人类。
最后，所有这些都通过 Agent 循环连接在一起：构建上下文，调用模型，检查其响应，如果允许则执行工具，存储结果，更新上下文，然后重复，直到任务完成。
框架工程是你作为应用 AI 工程师要做的大部分工作，所以请花时间仔细阅读这一部分。作为一名应用 AI 工程师，你的全部工作就是构建一个运行环境，让一个概率性系统能够在确定性软件内部工作。
但生产环境通常不会止步于一个 Agent。
随着工作流程变得更大，自然的直觉是拆分工作。但一旦你添加了第二个 Agent，系统设计就发生了变化。
对于一个 Agent，大部分复杂性都存在于一个循环内部。对于多个 Agent，你现在有多个循环在同一个环境中运行。每个 Agent 可能读取另一个 Agent 刚刚更改的状态，写入另一个 Agent 依赖的记忆，或者调用一个其结果会影响整个工作流程的工具。
此时，困难的部分不再仅仅是提示词工程、评估或框架设计。它变成了一个分布式系统问题：谁拥有哪个状态，谁可以写入记忆，哪些工具可以安全重试，以及当两个合理的 Agent 以错误的顺序采取行动时会发生什么。
多 Agent 部署是一个分布式系统问题
当第一个 Agent 工作正常且工作流程变大时，新的应用 AI 工程师自然会本能地将工作拆分为不同的角色：一个 Agent 负责研究，一个负责规划，一个负责执行，一个负责审查。
但是，第二个 Agent 将设计单元从 Agent 本身转变为系统。现在有多个循环在同一个环境中运行——一个 Agent 可能在更新客户状态，而另一个 Agent 正在根据过时的状态进行规划。两者都做出了合理的决定，但系统让这些决定以错误的顺序相互影响。
这是一个分布式系统问题。好消息是，分布式系统工程师几十年前就解决了这些故障。你的工作是将这些解决方案应用于恰好包含 LLM 的循环。以下是一些适用于 AI 工程的分布式系统解决方案列表：
单写入者原则。每个重要的状态片段都恰好有一个 Agent 可以写入它——其他 Agent 从中读取或提交更改请求。在工具层面强制执行这一点：如果执行 Agent 是唯一可以写入 CRM 的 Agent，那么无论研究 Agent 的推理能力有多差，它都无法破坏 CRM。
幂等键。当某些操作失败或超时时，Agent 会重试工具调用，但如果工具改变了现实世界中的某些东西，重试可能会很危险。你不希望 Agent 因为第一次请求看起来失败了就发送两次相同的付款。解决方法是为每个会改变数据的工具调用附加一个唯一的键——即任何在外部系统中更改数据的操作。如果工具再次看到相同的键，它应该返回原始结果，而不是再次执行该操作。Stripe 的 API 就是这样工作的——在处理支付、电子邮件等场景时，这同样适用于 Agent 开发。
写入前提条件。Agent 常常基于对世界的旧视图采取行动。从 Agent 制定计划到它尝试更新外部系统之间，某些事情可能已经发生了变化。为了防止基于过时数据的写入，会改变数据的工具在做出更改之前应该要求一个条件。例如：“仅当状态仍为‘待处理’时，才将其设置为‘已批准’。”如果状态已经改变，工具应该清晰地失败，而不是静默地覆盖较新的状态。
明确的交接。使用具有定义模式的消息传递工作，并由编排器排序。Agent 应该接收其任务，而不是发现任务。
总结
本文概述了作为应用 AI 工程师我学到的最重要的主题：评估、框架工程和多 Agent 系统设计。
如果你只能带走一样东西，那就是——模型提供智能，但使其可靠的一切（测量层、运行环境、协调规则）都是由你设计的。理解了这些，从软件工程的转型就变成了对你已有技能的延伸。
如果你对这种工作感兴趣，并希望与一支才华横溢的工程团队一起解决应用 AI 领域一些最有趣的问题，我们随时在招聘。请访问我们的网站 varickagents.com 申请，我们可以让你尽快入职。另一方面，如果你推荐候选人成功入职，我们将提供 2 万美元的推荐奖金。
