「Monitor my Slack channel and send me a daily digest」——一个用户在 Amazon Quick 里输入这句话时，系统面临的选择比用户意识到的要多得多。按照 Amazon Quick 团队在 AWS 机器学习博客中的描述，这句话至少可以被理解为 4 种不同的事物：一个全新的 agent、一条挂载到已有 agent 上的定时指令（scheduled instruction）、一个 workflow、或者一个 skill。4 种理解，4 条产品路径，4 种截然不同的系统行为。如果没有一套共享词汇来拆解这句话背后的组件，它们就会——用团队的原话说——「collapse into one confusing choice」。

这是 Amazon Quick 团队在构建 agent 系统过程中反复撞上的问题。他们在 AWS 机器学习博客中发布的 Taxonomy of agentic primitives in Amazon Quick 一文，将这个问题以及他们收敛出的解法——一套以 4 个朴素问题为骨架的 agent 原语分类法——完整地呈现了出来。这篇文章的价值在于它暴露了一个在 agent 系统工程化过程中被严重低估的瓶颈：概念层面的混乱。

当 agent 系统从单轮对话扩展到持续自主运行时，必须有一套清晰的原语定义来支撑系统设计和用户体验。Amazon Quick 团队的贡献在于，他们把这个问题的推理过程和收敛逻辑完整地公开了。

从回答问题到执行动作：同一概念被反复重建

Amazon Quick 团队在博客中给出了一条清晰的演进线索：过去一年里，Quick 的 agent 从回答问题（answering questions）扩展到执行动作——scheduling meetings、running research、generating reports。这条线索的起点是一个 AI 助手，终点是一个能持续代用户工作的自主 agent 平台。

Amazon Quick 官方博客对这个平台的能力描述具体到场景级别：用户开完一整天会议回来，停滞的交易已被跟进、合规变更已被摘要、会议准备材料已被撰写。用户可以用自然语言描述需求来创建 agent，也可以从预配置 agent 库中选择；用户可以决定给每个 agent 多大的自主权——从精确的分步指令到宽泛的目标，由 agent 自行规划路径。每个 agent 都在用户设定的 guardrails 内运行。

据 2026 年 6 月发布的 Quick 官方博客，彼时 Quick 已发布了 30 多个现成的 skill，覆盖销售、财务和营销场景——从 prospect leads 到 chase overdue invoices、build business cases、generate proposals、run market intelligence、forecast payroll、set up OOO workflows1。同一篇博文提到，Quick 当时新增了 16 个集成连接器，包括 Adobe、Cisco Webex、Dun & Bradstreet、Figma、Google Chat、Shopify、Smartsheet、Snowflake、Zapier、ZoomInfo 等。考虑到 Quick 处于快速迭代期，这些数字截至目前可能已有变化。

但正是在这种快速扩展中，一个结构性问题浮出水面。Amazon Quick 团队在 Taxonomy 博文中直接写道：「there was no shared definition of the primitives that agentic work is built from. The same few ideas kept getting rebuilt under different names: an actor that does the work, a signal that starts it, a packaged procedure, and a memory that carries lessons forward.」

4 个想法——执行者（actor）、触发信号（signal）、打包流程（packaged procedure）、记忆（memory）——在不同的功能模块、不同的开发团队、不同的产品界面上被反复实现，但每次都换了一个名字。这种重复不仅仅是工程层面的浪费。按照团队的说法，它「leaked into product design and onto the user」——渗透到了产品设计和用户体验上。

这里的因果链条很直接：当系统内部对「agent 到底由什么组成」没有共识时，暴露给用户的概念就会混乱。用户说「我要一个 agent 帮我每天早上发 Slack 摘要」，产品界面到底应该引导他去创建一个新 agent、配置一个定时触发器、编排一个 workflow、还是安装一个 skill？如果内部团队自己都没有统一的答案，用户面对的就是一个充满歧义的交互界面。

4 个朴素问题：When、Who、What、How

Amazon Quick 团队收敛出的分类法，骨架极其简单：把所有 agentic work 拆解为 4 个问题——When?（何时触发）、What?（做什么任务）、Who?（谁来执行）、How?（如何执行）。每个问题对应一类原语。

Triggers：When 和 What

Trigger 是工作的激活机制，但它同时承载指令——一条人类消息既是激活时刻，也是任务描述。因此 trigger 同时回答了 When 和 What 两个问题。团队定义了 4 种 trigger 类型：

  • Human-initiated：用户打开对话、向 agent 提问或下指令。交互式、同步、对话式。
  • Agent-delegated：一个 agent 在执行任务过程中调用另一个 agent 来处理子问题。程序化、可组合、可能递归。
  • Scheduled：基于时间的激活，例如「run financial research every Monday at 9am」。确定性的，每次运行时应用相同的常驻指令。
  • Event-driven：来自外部系统的信号——新邮件、Slack mention、文件变更、webhook。

一个关键的设计决策是：trigger 的类型会影响执行行为。团队在博文中明确指出，一个 scheduled background task 可能会偏保守（uncertain 时什么都不做），而一个 human-initiated 的请求则会偏响应式（uncertain 时主动询问而非停止）。这意味着 trigger 不仅仅是一个启动开关，它还携带了关于执行策略的隐含约束。

Agent：Who

Agent 被定义为「a persistent, learning actor」——一个持久化的、具备学习能力的执行者。它是任何执行中的 Who，也是学习成果累积的锚点。团队特别强调：两个 agent 即使接收到完全相同的输入，也可能产生不同的输出，因为它们携带着不同的 instructions、capabilities 和 histories。

Agent 由 3 个内在组件构成：

  • Instructions：定义 persona、role、context files 和 operating principles 的常驻指导。一个 Finance Agent 和一个通用助手的行为差异，主要来自这一层。
  • Capabilities：可用的 tools、skills、workflows 和 sub-agents，可动态更新。一个图表库可以在一次 session 中被添加，在下一次中被移除。
  • Learned context：通过使用积累的记忆——哪些查询对某个工具有效、用户偏好什么格式、他们关心哪些边缘情况。这是让第 10 次执行优于第 1 次的机制，而无需任何人修改 instructions。

团队同时划定了 agent 的边界：底层的 LLM 是可替换的模型参数（extrinsic），对话历史是 per-session state（extrinsic），trigger 属于平台（extrinsic）。这个边界划定的意义在于，它让 agent 的身份（identity）独立于具体的模型版本和会话状态。换一个 LLM，agent 还是同一个 agent；开一个新 session，agent 的 learned context 不会丢失。

Capabilities：How

Capabilities 是 agent 执行动作的方式，覆盖从「完全 agentic」到「完全 deterministic」的光谱。团队将这个光谱描述为一个「confidence contract」：agent 保留多大的自由裁量权，用户又事先固定多少。

原文把 capability 分成三类：tool 是有类型化 schema 的原子操作（发邮件、查数据库、读文件），无论背后是本地函数、MCP 服务器还是另一个 agent，调用方看到的接口都一样；skill 是留有判断空间的结构化指引，以渐进式披露加载，agent 平时只看到名字和简短描述，用到时才读入全文；workflow 是确定性的编排，步骤、分支和错误处理按固定顺序执行，决策逻辑写在代码里而不是交给模型推理——路线固定，但每一步内部的判断仍由 agent 做。团队还写道，理解充分的 skill 可以收紧成 workflow（crystallization），老是碰到边缘情况的 workflow 可以放松回 skill（dissolution），这由 Quick 的持续学习框架完成，细节留待后续文章。

这个光谱的存在意味着，同一个 agent 可以在某些任务上高度自主（例如根据上下文判断是否需要跟进一笔交易），在另一些任务上严格按步骤执行（例如按固定模板生成合规报告）。自主程度不是 agent 级别的属性，而是 capability 级别的属性。这一点的工程意义在于：编排层可以对每个步骤的可预测性做出不同级别的承诺，而不是对整个 agent 做一刀切的设定。笔者判断，这种粒度的控制对于企业级部署尤其关键——合规敏感的步骤可以被锁定在 deterministic 端（workflow），而需要 contextual judgment 的步骤则可以释放给 agentic 端（skill 或直接 tool-calling）。

Quick Automate 最佳实践博文中的建议与这个光谱直接呼应。该博文强调要「combine them with deterministic steps」，即在 agent 驱动的流程中混合确定性步骤。笔者判断，这在实践中意味着：一个端到端的自动化流程可能由若干 workflow 步骤（确定性的数据提取、格式校验、系统写入）和若干 skill/tool-calling 步骤（需要上下文判断的内容摘要、优先级排序、异常处理）交替组成。编排层根据每个步骤的 confidence contract 来决定是走确定性路径还是释放给 agent 判断。crystallization 和 dissolution 机制则让这个分配可以随运行经验动态调整——一个反复产出稳定结果的 skill 可以被固化为 workflow 以提高可预测性，一个频繁遇到意外输入的 workflow 可以被放松为 skill 以提高灵活性。

回到那句话：「Monitor my Slack channel and send me a daily digest」

有了这套分类法，那句让系统犯难的用户请求就可以被清晰地拆解了。

Amazon Quick 团队在博文中给出了明确的判断：「a user request ‘I want an agent that monitors my Slack and sends a digest every morning’ is usually a trigger added to an existing agent, not a new agent or workflow.」

这个判断的推理路径是：

  • Who（谁来执行）：用户大概率已经有一个通用助手 agent，不需要为这个任务创建一个全新的 agent。新 agent 意味着新的 instructions、新的 learned context 从零开始积累，这在大多数情况下是不必要的开销。
  • When/What（何时触发、做什么）：「每天早上」是一个 scheduled trigger，「monitor my Slack channel and send me a digest」是这个 trigger 携带的 standing instructions。
  • How（如何执行）：agent 使用其已有的 capabilities（Slack 连接器、文本摘要能力）来完成任务。

原文同时给出了这句请求的 3 种合理实现：一条带一句话指令的定时任务；同样的任务加一个写明格式规则和频道优先级的 skill；同样的任务调用一个有确定性步骤和错误处理的 workflow。三者都能按时产出摘要，区别在 confidence contract：信任 agent 的用户选第 1 种，被不一致结果坑过的选第 2 种，跑合规敏感流程的选第 3 种；团队的原则是选能满足用户信心要求的最简单方案。

这套分解的力量在于，它让系统能够把一个看似需要「创建新东西」的请求，转化为对已有 agent 的一次配置操作——添加一个 scheduled trigger 并选择合适的 capability 层级。用户不需要理解 trigger、agent、capability 之间的区别（团队明确说「Most of the framework stays invisible to end users by design」），但系统内部需要这套词汇来做出正确的路由决策。

团队在博文中进一步指出，这套框架带来的一个重要结果是：可以把 chat agent、scheduled agent 和 autonomous agent 统一为同一个 actor——「you can converse with, schedule, and that can orchestrate and inspect its own past work」。这消除了产品层面的一个常见困境：用户在 chat 界面创建的 agent 和在 automation 界面创建的 agent 是不是同一个东西？在这套框架下，它们就是同一个 agent，只是被不同类型的 trigger 激活。

从原语到生产系统：Quick Automate 的实践验证

原语分类法解决的是概念层面的问题，但概念最终要落到生产系统中。Amazon Quick Automate——Quick 内的多 agent 自动化能力——提供了一个观察这套分类法如何支撑规模化部署的窗口。

据 AWS 机器学习博客关于 Quick Automate 最佳实践的文章描述，Quick Automate 可以「coordinate teams of agents across departments, systems, UI and API interactions, and third-party applications」。这里的「teams of agents」可以对应到原语分类法中的 agent-delegated trigger（笔者的对应，原文未这样表述）——一个 agent 在执行过程中调用另一个 agent 处理子问题，形成多 agent 协作。

但 Quick Automate 团队在实践中遇到的挑战，恰好印证了原语分类法的必要性。他们在博文中列出了 agentic automation 面临的运维挑战：「Processes span many systems, inputs are often unstructured or semi-structured, and business logic shifts frequently.」如果没有清晰的原语边界，在这种复杂环境下部署 agent 会导致「brittle workflows, unpredictable behavior, and eroded trust」。

Quick Automate 团队给出的应对方案，与原语分类法的逻辑高度一致。他们强调要「design agents around clear responsibilities」——这对应 Who 维度的边界划定；要「combine them with deterministic steps」——这对应 How 维度中 capability 光谱从 agentic 到 deterministic 的设计；要「apply human review where it matters」——这可以被理解为在 agent 执行流程的关键节点插入人类审核。

Quick Automate 团队还提出了一个容易被忽视但极其重要的实践原则：「The process matters more than the technology. The most common mistake I see is teams jumping straight to automation design before they truly understand the process they intend to automate.」这句话的含义是，agent 原语分类法提供的是一套拆解工具，但拆解的对象——业务流程本身——需要在拆解之前被充分理解。团队甚至给出了一个启发式规则：「delete every step you can. If you aren’t occasionally forced to add a few back, you did not cut deeply enough.」

这个规则的背景是：从手动流程迁移到 agent 驱动的流程时，很多步骤本身就是为了弥合断开的系统之间的缝隙——把 PDF 中的数据重新输入到电子表格、通过 3 个邮箱路由文件以确保可见性、从一个工具下载文件再上传到另一个工具。在 agent 能够直接跨系统操作的前提下，这些步骤应该被彻底删除，而非被 agent 原样复制。

Activity Feed：原语分类法的一个推断性映射

以下分析是笔者基于 Amazon Quick 官方博客对 activity feed 功能的描述，以及 Taxonomy 博文中的原语定义，所做的推断性映射。Amazon Quick 团队在博文中并未直接将 activity feed 与原语分类法挂钩。

据 Quick 官方博客描述，activity feed 将 email、messaging、calendar 和 tasks 整合到一个按优先级排列的视图中。它能学习用户的行为模式——哪些消息用户总是快速回复、哪些线程用户跳过、哪些话题驱动用户的一周。

从原语分类法的视角看，activity feed 的运作机制可以被拆解为：event-driven triggers（新邮件到达、Slack 消息出现、日历事件变更）激活一个具备摘要和优先级排序 capabilities 的 agent，该 agent 利用其 learned context（用户的历史行为模式）来生成个性化的优先级视图。6 条升级消息被合并为 1 张摘要卡片并附带起草好的回复、会议谈话要点在用户打开邀请前就已生成、VP 的消息在用户阅读前就被标记——这些都可以被理解为 agent 在 event-driven trigger 下利用 learned context 自动执行的结果。

这个映射引出一个笔者认为值得追问的问题：activity feed 中 learned context 的更新机制存在一个隐含假设——用户对 agent 输出的沉默可能被系统解读为认可。当用户没有修改 agent 起草的回复就直接发送时，agent 是否会将此视为正向反馈并强化当前的措辞风格？当用户跳过某张摘要卡片时，agent 是否会降低同类信息的优先级？如果是，这种「沉默即认可」的机制在长期运行中可能导致 agent 行为逐渐漂移——agent 基于用户的惯性行为（而非深思熟虑的偏好）不断自我强化，最终偏离用户的真实意图。这个问题在 scheduled 和 event-driven trigger 场景下尤为突出，因为用户对后台运行的 agent 的关注度天然低于对 human-initiated 交互的关注度。团队预告的后续关于 background learning 的文章，可能会回应这个问题。

原语标准化的工程价值：可靠性、可观测性、变化韧性

笔者判断，Amazon Quick 团队发布这套分类法的时机和动机，与 agent 系统从单点能力向规模化部署演进的阶段密切相关。

当一个 agent 系统只需要处理用户的即时对话请求时，概念混乱的代价是可控的——最多是产品界面上的一些歧义。但当系统需要支持 scheduled agent 在后台持续运行、event-driven trigger 响应外部系统信号、多个 agent 之间相互委托任务时，缺少共享原语定义的代价会急剧放大。

Quick Automate 博文中描述的生产环境挑战可以作为佐证：流程跨多个 systems of record、输入为非结构化或半结构化（email、documents）、决策需要 contextual judgment 而非基本的 if-then 逻辑、异常频发且传统自动化脚本无法处理。在这种环境下，如果团队 A 把「一个每天早上运行的摘要任务」实现为一个独立的 agent，而团队 B 把同样的任务实现为一个 workflow，团队 C 把它实现为一个 skill 挂载到通用 agent 上，那么当这 3 个实现需要协作时——例如摘要任务的输出需要触发另一个 agent 的行动——系统的可观测性和可维护性就会急剧下降。

原语分类法的工程价值在于它提供了 3 个层面的标准化：

第一，责任边界的标准化。当 agent 被定义为「persistent, learning actor」并与 trigger、capability 明确分离时，一个 agent 的职责范围就变得可审计。它有哪些 instructions、挂载了哪些 capabilities、被哪些 triggers 激活、积累了什么 learned context——这些都是可以被枚举和检查的。

第二，组合接口的标准化。Trigger 的 4 种类型（human-initiated、agent-delegated、scheduled、event-driven）定义了 agent 被激活的所有合法方式。Capability 从 tool 到 skill 到 workflow 的三级划分，让系统可以在编排层面对每个步骤的可预测性做出承诺。这些标准化的接口让多 agent 协作成为可能，而非每次协作都需要定制集成。

第三，学习积累的标准化。Learned context 被锚定到 agent 这个实体上，而非散落在 session 历史、workflow 配置或 skill 参数中。这意味着一个 agent 在处理 Slack 摘要任务时学到的用户偏好（例如「用户不关心 #random 频道的内容」「用户偏好 bullet point 格式」），可以在下一次被不同的 trigger 激活时继续生效。

尚未回答的问题

Amazon Quick 团队在 Taxonomy 博文中明确说这是系列文章的第一篇（「It’s the first post in a series, and upcoming posts cover our agentic operating system, background learning, proactive feeds, and much more」）。这意味着当前公开的信息还有几个关键空白：

Learned context 的具体实现机制，团队说会在后续介绍持续学习框架的文章中展开。Agent 如何在不同 session 之间持久化学习成果？学习的粒度是什么——是 key-value 对、向量嵌入、还是结构化的偏好模型？当 learned context 积累到一定规模时，如何处理冲突或过时的记忆？这些问题直接影响 agent 在长期使用中的行为可预测性。

多 agent 协作中的 agent-delegated trigger 的递归深度和错误传播机制同样是开放问题。当 agent A 委托 agent B、agent B 又委托 agent C 时，如果 C 失败了，错误如何回溯？A 的 learned context 是否会记录这次失败链路？

Crystallization 和 dissolution 的触发条件也尚待明确。团队提到这由 Quick 的持续学习框架完成，但一个 skill 在什么条件下会被判定为「理解充分」从而收紧为 workflow？一个 workflow 碰到多少边缘情况才会被放松回 skill？这个阈值是系统自动判定还是需要人工介入？

这些问题的答案将决定这套分类法从概念框架到生产系统的距离。但即便在当前的公开信息下，Amazon Quick 团队提出的核心论点——agent 系统的瓶颈在于缺少共享的原语词汇表——已经足够清晰，也足够值得其他构建 agent 系统的团队认真对待。当 agentic automation 从单个 agent 回答问题，演进到多 agent 跨部门、跨系统持续协作时，对「agent 到底由什么组成」这个问题的回答质量，将直接决定系统的可靠性、可观测性和面对变化时的韧性。

主题分类：企业AI落地

参考资料

  1. Taxonomy of agentic primitives in Amazon Quick — AWS Machine Learning Blog, 2026-11-06
  2. Get back hours every day with autonomous agents in Amazon Quick — AWS Machine Learning Blog, 2026-06-17
  3. Best practices for building agentic automations with Amazon Quick Automate — AWS Machine Learning Blog, 2026-09-03

  1. 以上数字来自 2026 年 6 月博文，距今近 5 个月，仅供参考产品当时的覆盖范围。 ↩