Amazon Quick 中的智能体原语分类体系

在过去一年里，随着我们构建 Amazon Quick，我们的智能体从回答问题发展到采取行动：安排会议、开展研究、生成报告。随着系统不断演进，一个问题反复出现：对于构成智能体工作的基础原语，没有共享的定义。同样几个概念不断以不同的名称被重新构建：执行工作的行动者、启动它的信号、打包好的流程，以及承载经验向前传递的记忆。这种重复渗透到了产品设计中，也影响到了用户。

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

本文分享我们最终收敛到的分类体系：通过将智能体工作拆解为四个简单问题——何时？、什么？、谁？和如何？——而发现的一组原语。按照设计，该框架的大部分对最终用户保持不可见，但共享的词汇让任何在其之上构建的人都能更容易地理解这个系统。

框架概览

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

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

触发器：工作因何开始

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

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

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

智能体

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

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

其余一切都是外在的：代理底层的大语言模型（LLM）是一个可替换的模型参数，对话历史是每会话状态，触发器属于平台。

这一定义的一个推论是，用户请求“我想要一个监控我的 Slack 并每天早上发送摘要的代理”通常是添加到现有代理的触发器，而不是新的代理或工作流。按照这一框架，我们可以将聊天、定时和“自主”代理合并为一个参与者，你可以与之对话、安排日程，并且它可以编排和检查自己过去的工作。

能力

能力是代理如何行动，涵盖从完全代理式到完全确定性的一个谱系。这个轴实际上是一份置信契约：代理保留多少自由度，对比用户预先固定多少。

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

技能是留有判断空间的结构化指导：与资源（模板、脚本、示例）捆绑的指令，描述一种方法而非固定序列。它们通过渐进式披露加载，因此代理只看到名称和简短描述，直到某个技能变得相关，然后才读入完整指令。因此，一个技能可以捆绑任意深度的专业知识，而无需持续成本。

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

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

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

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

这在实践中意味着什么

回到“监控我的 Slack 频道并每天给我发送摘要”。因为这些原语可以组合，同一个请求可以通过几种有效方式满足：

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

三者都会按计划生成每日摘要。不同之处在于置信契约。信任智能体的用户想要第一种，因不一致而吃过亏的用户想要第二种，运行合规敏感流程的用户想要第三种。

学习会随时间推移改变这一轨迹。一个最初只有一句话的任务（“检查我的邮件中是否有紧急事项”）会积累领域相关的学习成果：有效的查询、偏好的格式，以及哪些发件人重要。第十次运行会明显更好，且无需任何人手工编码。正确的设计是满足用户置信要求的最简单选项，并在用户需要更多时提供通过自主学习逐步升级的路径。

结论

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

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

继续探索

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

关于作者

Thomas Delteil

Thomas 是 Amazon Quick 团队的高级首席技术专家，也是 Amazon Quick Desktop 背后创始团队的成员之一。他的工作核心是协同为人们完成实际工作的智能体系统。工作之余，你可能会看到他在独木舟上，探索太平洋西北地区最美好的一面。

Adi Kalyanpur

Adi 是 Amazon Quick 团队的首席科学家，也是 Quick Research 和 Quick Desktop 的创始成员。他的专业领域涵盖面向企业的智能体 AI 系统、神经符号推理，以及能够从经验中持续学习的自我改进智能体。工作之余，Adi 热爱运动、历史和旅行。

Ron Litman

Ron 是 AWS 的科学研究经理，负责管理 Amazon Quick 在所有界面（桌面端、网页端、移动端和扩展程序）上的核心体验。他的职业兴趣包括智能体 AI 系统、应用推理，以及构建能够无缝融入日常工作流程的智能助手。工作之余，Ron 正在探索抱石和攀岩的世界。