AI代理需约束使用，避免无筛选访问业务。LLM虽强大但不可靠，企业应用需拥抱约束，专注封闭世界问题，构建专用代理和工具，并进行严格测试与治理，以确保可靠性与安全性。
译自：Don’t Build Chatbots — Build Agents With Jobs
作者：Sean Falconer
你不会给每个员工都提供对生产服务器的 root 访问权限。那么，为什么要给 AI 代理 未经筛选地访问你的业务呢？
在 AI 领域，存在着一种日益增长的幻想：完全自主的代理，可以处理任何任务，在任何领域，无需任何监督。这是一个引人注目的愿景，但也是企业采用持续停滞的最大原因之一。
大型语言模型 (LLM) 功能强大，但本质上不可靠。这不仅仅是偶尔出现的错误；幻觉是底层技术“不可避免”的局限性。一个提示可能会返回有用的信息，下一个提示则完全是无稽之谈。斯坦福大学最近的一项研究发现，在法律场景中，幻觉率高达 88%。企业看到了这一点，信任非常脆弱。承诺开放式智能只会分散人们对这些系统今天可以可靠地提供的价值的注意力。
如果你想要有用的 AI，你必须顺应技术的发展。这意味着拥抱约束：封闭世界问题、专门构建的代理、范围限定的工具、强大的评估和分层治理。
除非你告诉它们，否则 LLM 永远不会了解你
我们喜欢将 LLM 与人脑进行比较。它们看起来很聪明、口齿伶俐，甚至很有洞察力。但是，尽管我们喜欢这种比较，但 LLM 并不像人，期望它们以这种方式行事会让你失望。
在第一波 AI 浪潮中，系统一次只接受一项工作的训练。
你会获取公司的数据，对其进行标记，并训练一个模型来做一些非常具体的事情，比如预测客户流失或对支持工单进行分类。结果是一个真正了解你的领域的模型，因为它将你的数据直接融入其权重中。权衡之处在于灵活性。你不能使用同一个模型来撰写博客文章或分析图像。它擅长一件事，而且仅此而已。
专门构建的模型训练管道。
基础模型则相反。
它们很灵活，能够处理大量任务。但它们没有接受过你的系统、你的流程或你的客户数据的训练。因此，尽管它们是出色的通才，但它们对你的业务来说真的很笨。
这就是提示设计和情境化发挥作用的地方。为了获得有用的结果，你必须每次都向模型提供它需要知道的一切。提示之间没有记忆。每次交互都从头开始。
针对特定应用程序的答案进行情境化提示。
关键在于：可靠性不是免费的。它必须经过精心设计。而且它不是二元的。可靠性是一个范围，而“足够可靠”完全取决于用例。
如果你要完全自动化金融交易或医疗记录处理，你可能需要接近完美的准确性。在那个世界里，LLM 要么还没有准备好（而且可能永远不会），要么你需要将它们包裹在多层验证、测试和回退逻辑中，以确保它们的安全。另一方面，如果你要生成会议记录、展示有用的支持文档或总结内部通讯，只要整体信号有用，偶尔出现错误可能是可以接受的。
理解这种差异是将现实世界中可用的 AI 与在生产中崩溃的原型区分开来的关键。如果你想要一致、可靠的输出，请将上下文视为一流的输入。保持紧凑，专注于任务，并为模型提供足够的上下文来成功完成你要求它完成的工作。
LLM 是新的操作系统；不要给每个人终端访问权限
Tesla 前 AI 总监 Andrej Karpathy 在他的演讲“软件正在改变（再次）”中，将 LLM 比作操作系统。正如应用程序在 macOS 或 Windows 上运行一样，AI 应用程序现在在 GPT、Claude 和 Gemini 上运行。在这个类比中，ChatGPT 是终端：功能强大、灵活且开放。
但终端不是为最终用户准备的。它们是为开发人员准备的。在实际系统中，我们不会给人们原始访问权限；我们会构建结构化的接口。这同样适用于这里。AI 需要防护措施，而不是 root 访问权限。
你不会让员工使用原始 SQL 在你的生产数据库中四处查询。你会通过仪表板或应用程序等工具为他们提供范围限定的访问权限，这些工具可以帮助他们完成工作，而无需暴露底层的所有内容。同样的逻辑也适用于这里。
对于商业 AI 系统，理想的 UX 不是聊天框。这不是关于某人在提示窗口中输入问题并希望获得有用的答案。真正的机会在于始终开启、在后台默默工作的 AI 系统。这些系统不会等待人类提出问题。它们会对信号做出反应：新的支持工单、客户放弃购物车、事件警报。当这些信号出现时，它们会以目标、上下文和约束来采取行动。
这种从人工提示到信号驱动的转变，需要一种不同的 UX 方法。
你不是在构建通用聊天机器人。你正在构建具有工作要做的代理。这意味着在正确的时间为他们提供访问正确数据的权限，以实现明确定义的目的。
为了有效地使用 AI，请优先处理封闭世界问题。
专注于封闭世界问题
团队在使用 AI 代理时犯的最大错误之一是试图解决开放世界问题，而他们应该解决封闭世界问题。
开放世界问题是指“教我数学”或“给我写一些有趣的东西”。没有明确的输入，没有固定的输出，也没有单一的方法来衡量结果是好是坏。模型可能会给你一些聪明的东西，或者它可能会完全偏离目标。
封闭世界问题则不同。你可以定义输入、预期的输出和成功的标准。考虑一下以下事项：
- 处理保险索赔
- 解决 IT 工单
- 引导新客户或员工
这些是具有规则、约束和可衡量结果的有界任务。这使得它们适合基于 LLM 的系统，不仅因为它们更容易自动化，而且因为它们更容易信任。
到目前为止，代码生成一直是 LLM 最成功的用例之一，这并非巧合。输入清晰，输出可测试，正确性可验证。你可以运行代码。同样的模式、明确的期望和紧密的反馈循环正是使封闭世界业务用例可行的原因。
当你专注于封闭世界问题时，你会得到：
- 更好的可测试性： 你可以编写测试用例，并知道好的响应是什么样的。
- 更多的可解释性： 当出现问题时，更容易调试或审计系统。
- 更严格的防护措施： 你可以限制 AI 可以查看、说或做什么。
你减少歧义的程度越高，你的 AI 系统就越可靠。这完全取决于有目的地进行设计。解决路径清晰、范围已定义且风险已知的问题。尽可能多地将确定性添加到本质上不确定的过程中。这就是你构建能够交付结果而不是带来意外的 AI 的方式。
专门构建的代理，而不是通用聊天机器人
一旦你缩小了问题空间，下一步就是将其分解。
试图构建一个单一的、无所不知的 AI，它可以处理从客户服务到销售预测的所有事情，这会迅速导致复杂性和混乱。相反，将 AI 视为软件：模块化、可组合且范围限定于特定工作。
这就是专门构建的代理的用武之地。
专门构建的代理是一个具有明确定义的职责的 AI 系统，例如分流支持工单、监控系统日志或生成每周销售报告。每个代理都经过优化，可以很好地完成一件事。
构建专门构建的代理。
就像在软件中一样，力量来自组合。
以处理保险索赔这样的封闭世界问题为例。它不仅仅是一个步骤。它是一系列结构化的、相互连接的任务：验证输入、检查资格、获取相关的保单详细信息、总结案例和升级异常。与其构建一个单一的整体代理来处理所有这些，不如设计原子代理，每个代理处理一个特定的部分，并将它们编排成一个多代理系统。
这种分解使你的 AI 系统更可靠、更安全且更易于发展。就像软件微服务一样，魔力不仅发生在每个代理内部，而且发生在它们协同工作的方式中。
为 LLM 构建工具，而不是为人类构建工具
一旦你将系统分解为专门构建的代理，下一步就是为它们提供正确的工具，就像你为任何团队提供工具一样。
对于 LLM，它们完全依赖于你向它们公开的内容以及描述的程度。因此，如果你希望你的代理以可预测的方式运行，那么你的工具需要考虑到这一点进行设计。
决定工具使用的思维循环。
这不仅仅是公开你现有的 API 端点的问题。通用工具（例如对你的生产数据库的开放式 SQL 接口）可能看起来很强大，但 LLM 很难安全地使用它。
想象一下，代理使用通用 SQL 工具编写查询需要什么：
- 请求模式。
- 解析大型的、可能杂乱的模式响应。
- 推断要使用的正确表。
- 猜测跨相关表的必要联接。
- 构造正确的 SELECT 语句。
- 尝试决定要返回多少数据。
- 以有用的方式格式化结果。
- 处理边缘情况或不明确的字段。
这些步骤中的每一步都会引入风险，例如错误的假设、不完整的上下文、不明确的命名以及幻觉的高可能性。更糟糕的是，如果查询失败，大多数代理框架将重试整个序列，通常会对提示进行细微的调整。这会导致令牌膨胀、级联重试和成本增加，而不会改善结果。
最终，你会得到开放世界问题的所有缺点：不明确的意图、广泛的决策空间、不可预测的行为。与代理一样，工具也应该是专门构建的。它们应该专门设计来帮助代理解决范围明确的任务。考虑“获取今天未发货的订单”，而不是“运行你想要的任何查询”。
你减少歧义的程度越高，模型就越能可靠地完成工作。
这意味着构建的工具应该：
- 强类型： 输入或输出的内容没有歧义。
- 受约束： 小型、专注的工具更易于代理进行推理，并且更难滥用。
- 自描述： 工具应包含元数据、示例和描述，以帮助模型了解何时以及如何使用它们。
- 访问控制： 就像用户一样，并非每个代理都应该有权访问每个工具。范围很重要。
这就是模型上下文协议 (MCP) 等协议的用武之地。MCP 帮助标准化工具的定义和描述方式，以便代理可以更有效地对它们进行推理。如果你做得对，那么你就是在为 LLM 提供正确的上下文，以安全、正确地使用工具。
当你正确设计工具时，你可以强制实现可靠性。模型停止即兴创作，并开始像软件应该做的那样运行：具有明确的规则、定义的行为和可预测的结果。
治理、测试以及对 AI 测试人员的需求
在传统软件中，测试是关于输出是否正确。对于 AI 代理，这仅仅是个开始。你还需要测试代理如何发现工具、如何决定使用它们以及是否正确使用它们。
这意味着要花费大量时间进行评估。
如果你已将你的代理和工具构建为专门构建且范围明确的，那么编写好的评估应该很简单。你知道输入，你知道预期的输出，并且你可以在边缘情况和常见工作流程中运行一致的检查。这不是你可以随意观察的东西。你需要可重复、确定性的测试，就像任何其他生产系统一样。
对于许多用例，人工参与应该成为系统的一部分。你应该考虑清楚什么是可以完全自主的，什么是需要人工监督的。你可能需要人员参与升级、验证和学习。让 AI 处理例行的、可预测的任务，让人类在情况变得混乱时介入。
控制是一项功能，而不是一种限制
当 LLM 的范围、结构和基础都在清晰的上下文中时，它们最有效。可预测性是使 AI 在大规模上可靠的原因。如果你想要能够交付实际结果的 AI，请为控制和目的而设计，而不是为开放式自由而设计。
