Amazon Quick 智能体原语分类法：用 When、What、Who、How 四个问题拆解智能体工作

Amazon Quick 团队在构建产品过程中发现，智能体工作缺少共享的原语定义，同一个概念常以不同名字被反复重建，并直接泄漏到产品设计和用户体验上。例如用户说“监控我的 Slack 频道并每天发摘要”，这究竟是一个新智能体、给已有智能体的定时指令、一个工作流还是一个技能，在没有共同词汇时会被压缩成一个令人困惑的选择。文章给出的答案是四个朴素问题：When、What、Who、How。 触发器负责启动工作并携带任务，同时回答 When 和 What。文章将其分为四类：人类发起（交互式、同步、对话式）、智能体委派（程序化、可组合、可能递归）、定时（基于时间激活，跨运行应用同一套常驻指令）、事件驱动（来自外部系统的信号，如新邮件、Slack 提及、文件变更或 webhook）。触发器类型会影响执行策略，定时后台任务可能偏保守，人类发起的则更倾向于追问而非停止。 智能体被定义为持久、会学习的行为主体，是执行中的 Who，也是学习积累的锚点。它由三部分组成：指令（定义人设、角色、上下文文件和运行原则的常驻指导）、能力（可动态增删的工具、技能、工作流和子智能体）、习得上下文（使用中积累的记忆，如对某工具有效的查询、用户偏好的格式）。底层 LLM 只是可替换的模型参数，对话历史是会话级状态，触发器属于平台。按此定义，“我想要一个监控 Slack 并每天早上发摘要的智能体”通常只是给已有智能体加了一个触发器。 能力是智能体行动的方式，从完全智能体化到完全确定性构成一条光谱，本质是一份置信度契约：智能体保留多少自由度，用户预先固定多少。工具是带类型 schema 的原子操作，无论本地函数、MCP 服务器还是协议边界后的另一个智能体，调用方看到的接口一致。技能是留有判断空间的结构化指导，通过渐进披露加载，智能体先只看到名称和简短描述，相关时才读入完整指令，因此可以打包任意深度的专业知识而不产生常驻成本。工作流是确定性协调，步骤、控制流、分支和错误处理按固定顺序执行，决策逻辑在代码而非模型推理中，例如预算检查、经理审批、财务审批的采购审批路径。 文章回应了“模型持续变强后技能和工作流是否会多余”的疑问：技能是捕获、版本化和共享机构专业知识的单元，工作流提供可审计性、逐步可见性和确定性的多服务协调，二者价值独立于模型能力。它们也不是固定的，理解充分的技能可以收紧为工作流（结晶），频繁遇到边缘情况的工作流可以放宽回技能（溶解），这在 Quick 中通过持续学习框架完成。 回到 Slack 摘要的例子，同一请求可以有多种有效实现：一句指令的定时任务、带明确格式规则和频道优先级的技能、带确定性步骤和错误处理的工作流，三者都能按时产出摘要，差别在于置信度契约。文章建议采用满足用户置信度要求的最简方案，并在需要时通过自主学习逐步升级。该系列后续将介绍智能体操作系统、后台学习、主动信息流等内容。