Amazon Quick 智能体原语的分类框架

过去一年里，在构建 Amazon Quick 的过程中，我们的智能体从回答问题进化到了执行行动：安排会议、开展调研、生成报告。随着系统演进，有一个问题不断浮现：对于智能体工作所依赖的基本构件，缺乏一个统一的定义。同样几个概念不断以不同的名字被重复构建：执行工作的执行者、启动工作的信号、打包好的流程，以及承载经验教训的记忆。这种重复渗透到了产品设计乃至用户体验中。

以一个说“监控我的 Slack 频道，每天给我发一份摘要”的用户为例。这是一个新智能体、对现有智能体的定时指令、一个工作流，还是一个技能？这些是不同的问题，但在没有共享词汇的情况下，它们坍缩成一个令人困惑的选择。

本文分享我们最终收敛出的分类体系：将智能体工作分解为四个朴素的问题后得到的一组基本构件：何时？、做什么？、谁来做？和怎么做？。这一框架的大部分在设计上对最终用户是不可见的，但共享词汇让任何在其之上构建的人都更容易理解这个系统。

框架概览

图 1：触发器、智能体与能力之间的关系，学习过程从会话运行时反馈回来

触发器启动工作并携带任务（何时与做什么），智能体承接任务（谁来做），并使用其能力（工具、技能和工作流）来执行任务（怎么做）。本文将介绍这些基本构件以及它们之间的相互关系。这是系列文章的第一篇，后续文章将涵盖我们的智能体操作系统、后台学习、主动推送等更多内容。

触发器：什么引发了工作的开始

触发器是完成工作的激活机制，但它们也承载指令：一条人类消息既是激活的时刻，也是对要做什么的描述。它们既是任务的何时？，也是做什么？

人类发起：一个人开启对话，请求智能体做某件事。交互式、同步、对话式。
智能体委派：一个智能体在任务执行过程中调用另一个智能体来处理某个子问题。程序化、可组合、可能递归。
定时触发：基于时间的激活，例如“每周一上午 9 点运行财务调研”。具有确定性，每次运行都应用相同的固定指令。
事件驱动：来自外部系统的信号，例如新邮件、Slack 提及、文件变更或 webhook。

触发器的类型决定了执行方式：定时的后台任务可能保持保守（例如，不确定时不做任何事），而人类发起的任务则应具有响应性（例如，宁可询问而不是停止）。

智能体

我们将智能体定义为持久的、会学习的执行者。它是任何执行中的谁来做？，也是学习积累所依附的锚点。两个智能体即使输入完全相同，也可能表现不同，因为它们携带的指令、能力和历史各不相同。智能体并不是它所遵循的指令，而是解释这些指令的实体。它由三部分组成：

指令： 定义人格、角色、上下文文件和运行原则的固定指导。财务智能体之所以表现得不同于通用助手，主要就是因为这一点。
能力： 可供使用的工具、技能、工作流和子智能体，动态更新。一个图表库可以在一次会话中被添加，在下一次会话中被移除。
习得的上下文： 在使用过程中积累的记忆：哪些查询对某个工具有效、用户偏好的格式、他们关心的边缘情况。这就是为什么第十次执行胜过第一次，而无需任何人修改指令。

其余一切都是外在的：智能体所基于的大语言模型（LLM）是可替换的模型参数，会话历史是每次会话的状态，触发器则属于平台。

这个定义的一个推论是，用户请求“我想要一个监控我的 Slack 并每天早上发送摘要的智能体”通常是给现有智能体添加一个触发器，而不是一个新的智能体或工作流。有了这个框架，我们可以把聊天、定时和“自主”智能体合并为一个行动者：你可以与它对话、为它排期，它也能编排并检查自己过去的工作。

能力

能力是智能体如何行动，涵盖从完全智能体化到完全确定性的光谱。这条轴实际上是一份信心契约：智能体保留多少自由度，用户预先固定多少。

工具是具有类型化模式的原子操作：发送电子邮件、查询数据库、读取文件。无论是本地函数、Model Context Protocol (MCP) 服务器，还是协议边界后的另一个智能体，调用者看到的都是相同的接口：名称、描述、参数、结果。

技能是留有判断空间的结构化指引：与资源（模板、脚本、示例）捆绑在一起的指令，描述的是一种方法而非僵化的步骤序列。它们通过渐进式披露加载，因此智能体起初只看到名称和简短描述，直到某项技能变得相关时才读取完整指令。因此，技能可以打包任意深度的专业知识，而没有持续的成本。

工作流是确定性的协调：声明的步骤、控制流、分支和错误处理按固定顺序执行，决策逻辑在代码中而非模型推理中。设想一条采购审批路线：预算检查、经理签批，然后是财务，每一步都有记录。路线是固定的，但步骤内部的判断仍然属于智能体。

图 2：技能与工作流，二者的区别在于由智能体还是代码决定步骤顺序

为什么技能和工作流比模型改进更持久

一个自然的问题是：如果模型不断改进，技能和工作流会不会变得不必要？我们认为不会，因为二者各自拥有独立于模型能力的价值。技能是捕获、版本化和共享机构专业知识的单元，而工作流则提供可审计性、分步可见性和确定性的多服务协调。它们也不是固定不变的：一项被充分理解的技能可以收紧为工作流（结晶化），一个不断碰到边缘情况的工作流也可以松动回技能（溶解）。这是通过我们的持续学习框架在 Quick 中实现的，我们将在未来的文章中加以描述。

在实践中这意味着什么

回到“监控我的 Slack 频道并发送每日摘要”。由于这些原语可以组合，同一请求可以通过多种有效方式来满足：

一个带有单行指令的定时任务，其余的交给智能体自行解决。
同一任务，但由一个技能支撑，带有明确的格式规则和频道优先级。
同一任务，调用一个具备确定性步骤和错误处理的工作流。

三者都能按计划产出每日摘要。不同之处在于信心契约。信任智能体的用户想要第一种，被不一致性坑过的用户想要第二种，运行合规敏感流程的用户想要第三种。

学习会随时间改变这条轨迹。一个一开始只有一句话的任务（“检查我的邮件中是否有紧急事项”）会积累特定领域的经验：有效的查询方式、偏好的格式，以及哪些发件人重要。第十次运行的表现明显更好，而无需任何人手动编码这些内容。正确的设计是满足用户信心要求的最简方案，并在用户需要更多时，通过自主学习逐步升级。

结论

这套智能体原语分类法的价值在于，四个简单的问题——何时、什么、谁和如何——就足以定位任何智能体工作，从单行聊天请求到定时的、合规级别的流程。共享同一套词汇让构建者能够对系统进行推理，也让产品得以隐藏复杂性。最重要的是，用户无需学习其中任何内容。他们只需说出自己想要什么，系统就会组装合适的原语来完成工作。

本系列下一篇：构建在这些原语之上并为 Amazon Quick 提供动力的智能体操作系统。

继续探索

准备好尝试了吗？从Amazon Quick 入门指南开始。