Amazon Quick 代理工作原始元素分类

在过去的一年里，随着 Amazon Quick 的开发，我们的代理从回答问题发展到执行操作：安排会议、进行研究和生成报告。 随着系统的演变，一个持续出现的问题是：没有关于代理工作所基于的原始元素的共同定义。 相同的一些想法在不同的名称下不断被重建：执行工作的参与者、启动工作的信号、打包的程序以及传递经验教训的记忆。 这种重复渗透到产品设计中，并影响用户。 例如，当用户说“监控我的 Slack 频道并发送每日摘要”时，这是一个新的代理、对现有代理的预定指令、一个工作流程还是一项技能？

这些问题是不同的，但没有共同的语言，它们会变成一个令人困惑的选择。 本文分享了我们形成的分类法：通过将代理工作分解为四个简单的问题来找到一组原始元素：何时？ 什么？ 谁？ 以及如何？ 该框架的设计使得大部分内容对最终用户保持不可见，但共同的语言使任何在它下面构建的人都更容易理解该系统。 框架概览：图1：触发器、代理和能力之间的关系，学习从会话运行时反馈。 触发器启动工作并携带任务（何时和什么），代理接管任务（谁）并使用其能力（工具、技能和工作流程）来执行任务（如何）。 本文描述了这些原始元素以及它们之间的关系。

这是系列文章的第一篇，未来的文章将涵盖我们的代理操作系统、背景学习、主动信息流以及更多内容。 触发器：什么导致工作开始触发器是完成工作的激活机制，但它们也携带指令：人类消息既是激活的时刻，也是要做什么的描述。 它们是任务何时和什么的体现。 人类发起的：一个人打开对话并要求代理做某事。 交互式、同步、对话式。 代理委托的：一个代理在执行任务时，调用另一个代理来处理子问题。 程序化的、可组合的、潜在的递归的。 计划的：基于时间的激活，例如“每周一上午 9 点运行财务研究”。 确定的，相同的指令在运行之间应用。

事件驱动的：来自外部系统的信号，例如新电子邮件、Slack 提及、文件更改或 webhook。 触发条件调节执行：一个计划的背景任务可能会保持保守（例如，如果不确定则什么也不做），而人类发起的一个则会响应（例如，询问而不是停止）。 代理：我们将代理定义为一个持久的、学习的参与者。 它是任何执行中的谁，以及学习累积的锚点。 给两个代理相同的输入可能会不同，因为它们携带不同的指令、能力和历史。 代理不是它遵循的指令。 它是解释这些指令的实体。 它由三部分组成：指令：定义角色、上下文文件和操作原则的持久指导。

金融代理与通用助手的不同主要归因于此。 能力：可用的工具、技能、工作流程和子代理，动态更新。 图表库可以在一次会话中添加，在下次会话中移除。 学习上下文：通过使用累积的记忆：工具有效的问题、用户喜欢的格式、他们关心的边缘情况。 这是第十次执行比第一次好，而没有人改变指令。 其他一切都是外部的：代理下层的语言模型（LLM）是一个可交换的模型参数，对话历史是会话状态，触发器属于平台。 这个定义的一个后果是，用户请求“我想一个监控我的 Slack 并每天发送摘要的代理”通常是一个添加到现有代理的触发器。