Amazon Quick 团队提出 agentic 原语四问分类：用 confidence contract 区分 skill 与 workflow
Amazon Quick 团队提出一套将 agentic 工作分解为 When、What、Who、How 四个问题的原语词汇表，核心主张是：同一个用户请求可以有多种合法实现路径，区别在于 agent 保留多少自主权——即“confidence contract”。该框架试图解决构建 agent 系统时反复出现的归类歧义。
构建 agent 系统时，一个反复出现的问题是：同一个用户请求到底该归类为什么。Amazon Quick 团队在 2026 年 11 月发表的一篇博客中给出了他们的回答——不是给出唯一答案，而是提供一套让不同答案可以共存并互相切换的词汇。
他们把 agentic 工作拆成四个基本问题：When（什么触发了工作）、What（任务内容是什么）、Who（谁来做）、How（怎么做）。触发器同时回答 When 和 What；agent 回答 Who；能力（capability）回答 How。这个分解本身并不复杂，但它的价值在于：当你有了这四个问题，同一个请求的不同实现路径就不再是互斥的竞争方案，而是同一框架下 confidence contract 的不同刻度。
所谓 confidence contract，是指 agent 保留多少自主权与用户预先固定多少流程之间的比例。Amazon Quick 团队用了一个具体例子来说明：用户说“监控我的 Slack 频道，每天发一份摘要”。这句话至少可以三种方式实现——第一种，一条定时任务加一句指令，让 agent 自己判断怎么做；第二种，用一个 skill 打包明确的格式规则和频道优先级；第三种，用一个 workflow 声明确定性步骤和错误处理。三种都产出每日摘要，区别仅在于 agent 的 latitude 有多大。
这个区分在实践中有一个可操作的推论：一个用户请求“我要一个监控 Slack 并每天发摘要的 agent”，通常不是要创建新 agent 或 workflow，而是给已有 agent 加一个 trigger。Amazon Quick 团队由此把聊天、定时和所谓“自主” agent 合并为同一个 actor——你可以跟它对话、给它排日程、让它编排和检视自己的过去工作。
关于 skill 和 workflow 的关系，他们提出了一对动态概念：crystallization（结晶）和 dissolution（溶解）。一个被充分理解的 skill 可以收紧为 workflow；一个频繁遇到边界情况的 workflow 可以放松回 skill。这个转换由他们的 continuous learning 框架驱动，具体机制在后续文章中展开。
值得注意的边界：这是一套厂商内部提出的词汇表，用于统一其自身产品线的架构讨论。文章没有提供独立采纳证据，也没有对照实验表明这套分类确实降低了构建者的混淆。它的价值目前停留在“一个清晰的归因论证”层面——作者解释了为什么需要共享词汇、这套词汇如何构成、以及它如何改变一个具体请求的归类方式。对于正在构建 agent 系统的读者，这套四问分解和 confidence contract 提供了一个可直接使用的思考框架，但将其视为行业标准仍为时尚早。