给 Agent 立名字，是一件比训练模型更晚熟、也更困难的事。
过去一年，亚马逊 AWS 团队在搭建一个叫 Amazon Quick 的系统时，眼看着自己的 agent 从“回答问题”长成了“做事情”：安排会议、跑研究、生成报告。能力上去了，一个问题却反复冒出来：所有人对“构成 agent 工作的基本构件”没有统一说法。同一个东西在不同团队嘴里换不同名字，干活的叫 actor，启动它的叫 signal，打包好的叫 procedure，记经验的叫 memory。
这种命名混乱没有停留在工程师的嘴里，它漏进了产品设计，最后砸在了用户脸上。用户说“帮我盯着 Slack 频道，每天发个摘要”，系统该把它当成一个新 agent、一条给现有 agent 的定时指令、一个 workflow，还是一个 skill？四个不同的问题，因为没有共享词汇，坍缩成一个让人困惑的选择题。
2026 年 11 月初，AWS 在官方博客贴出了他们的答案：《Taxonomy of agentic primitives in Amazon Quick》。这是系列第一篇。它没有讲新模型，没有抛新 benchmark，而是干了一件更底层的事：把 agent 工作拆成四个朴素问题，When（何时）、What（做什么）、Who（谁来做）、How（怎么做），然后给每个问题分配一个原语。
这件事的真正看点不在分类本身，而在它背后那个行业信号：Agent 基础设施的竞争，正在从“谁能把 agent 跑起来”，悄悄转向“谁能给 agent 立规矩”。
当“agent”变成一个什么都能装的词
先承认一个事实：今天行业里“agent”这个词，已经快被用坏了。
一个会调工具的 LLM 应用叫 agent，一段固定编排的 workflow 叫 agent，一个定时跑的脚本也叫 agent。厂商要卖点，开发者图省事，投资人和用户照单全收。结果是每个人都觉得自己说的是同一个东西，直到要把它做进产品里才发现，我们连“什么是一个 agent”都没说清。
AWS 这篇博客的价值，首先在于它拒绝继续装糊涂。它从一句非常克制的定义开始：agent 是“persistent, learning actor”，持久的、可学习的行动者。注意两个限定词：持久，意味着它不是用完即弃的一次性会话；可学习，意味着它会随着使用积累记忆。更重要的是后面这句：“The agent isn't the instructions it follows. It's the entity that interprets them.”agent 不是它遵循的指令，而是解释指令的那个实体。
这句话把三样东西解耦了：指令（Instructions）、能力（Capabilities）、习得的上下文（Learned context）。而底层的大语言模型呢？文章说得很淡，那只是个“可替换的模型参数”（swappable model parameter）。对话历史是每会话状态，触发器属于平台。
这是整篇文章里最容易被忽略、也最狠的一句话。它把过去一年被捧上神坛的“模型即一切”叙事，轻轻放回了它该在的位置：模型是引擎，不是车。
四个问题，一套词汇
AWS 的分类法简单到近乎朴素。任何一段 agent 工作，都可以落到四个问题上。
When 加 What，由 Trigger（触发器）承担。触发器不只是启动机制，它还携带指令。一条人发的消息，既是激活的时刻，也是对“做什么”的描述。Who，由 Agent（智能体）承担，它是任何一次执行中的“谁”，也是学习积累的锚点。How，由 Capabilities（能力）承担，agent 用它手里的工具、技能、工作流、子 agent 来完成任务。
Trigger 被分成四类：人发起的，打开对话让 agent 做事，交互式、同步；agent 委派的，一个 agent 中途调用另一个处理子问题，可编程、可组合、可能递归；定时的，比如“每周一上午 9 点做金融研究”，确定性，跨轮次应用相同的常驻指令；事件驱动的，来自外部系统的信号，新邮件、Slack 提及、文件变更、webhook。
这个分类的妙处在于，触发类型会反过来影响执行性格。一个定时后台任务可以保守一点，不确定就不做；而一个人发起的对话可以更主动，不确定就问，别自己瞎猜。同一个 agent，挂上不同 trigger，表现出不同的行为边界。
于是那个困扰用户的选择题有了答案。“我想要一个监控我 Slack 并每天早上发摘要的 agent”，通常不是要一个新 agent，而是给现有 agent 加一个 trigger。借这个框架，聊天 agent、定时 agent、“自主”agent 可以被合并成同一个 actor，你可以跟它对话，给它排程，让它编排并审查自己的过往工作。
信心契约：从 Tool 到 Skill 到 Workflow
Capabilities 是这套分类法里最见功力的一层。AWS 没有把工具、技能、工作流并列成三种功能，而是把它们放在一条轴上，从完全 agentic 到完全 deterministic。文章说，这条轴的本质是一个“confidence contract”（信心契约），用户愿意让 agent 保留多少自由裁量，又愿意提前固定多少东西。
最自由的是 Tool（工具）。原子操作，带类型 schema：发邮件、查数据库、读文件。不管背后是本地函数、一个 MCP server，还是协议边界后的另一个 agent，调用方看到的接口一模一样：名字、描述、参数、结果。这是 Model Context Protocol（MCP）那套思路的延续，把异构能力包装成统一接口。
中间层是 Skill（技能）。结构化指导，但留有判断空间。它捆绑了模板、脚本、示例这些资源，描述的是一套方法，而不是僵化的步骤序列。关键是它用“渐进式披露”（progressive disclosure）加载，agent 平时只看到技能的名字和短描述，直到某个技能变得相关，才把完整指令读进来。这意味着一个技能可以捆绑任意深度的专业知识，却不用在平时付出持续的 token 成本。
最确定的是 Workflow（工作流）。声明式步骤、控制流、分支、错误处理，按固定顺序执行，决策逻辑写在代码里而不是交给模型推理。比如采购审批路线：预算检查、经理签字、财务，每一步留痕。路线是固定的，但每个步骤里的判断仍然归 agent。
AWS 配了一张图说清楚这件事：skill 让 agent 自己解释指导、选择步骤顺序，确定性较低；workflow 用代码把步骤顺序焊死，确定性较高。
这不是技术高低之分，是责任分配之分。用户要的不是“更智能”，而是“在我能接受的范围内智能”。一个合规级的采购流程，用户要的是确定性，用工作流；一个创意调研任务，用户要的是灵活性，用技能。好的系统不是把一切都交给模型，而是给用户一条从确定到不确定的滑轨，让他自己选坐在哪里。
AWS 还预判了一个可能的反驳：模型越来越强，skills 和 workflows 会不会变得多余？答案是不会。skills 是沉淀、版本化和共享机构知识的单元，workflows 提供的是可审计性。模型会迭代，但这些承载组织经验的构件不会因此过时。
学习在后台发生，不是用户教出来的
这套分类法里还藏着一个容易被漏掉的部件：学习。
文章里有个例子：一个任务最开始只有一句话，“检查我的邮件里有没有紧急事项”。随着一次次运行，它积累下领域绑定的学习：哪些查询对邮箱工具有效、用户喜欢什么格式、哪些发件人重要。到第十次运行时，效果明显比第一次好，而没有人为此改过一行指令。
这就是“Learned context”（习得上下文）的意义。它让同一个 agent 在相同输入下可以表现不同，因为它带着不同的指令、能力和历史。第十次执行胜过第一次，靠的不是提示词工程，是记忆。
而学习发生的位置也很讲究：它在后台，在 session runtime 之外。用户不必教系统“怎么学”，系统自己从执行轨迹里长出来。AWS 给的设计原则是：选那个能满足用户信心要求的最简单选项，同时留一条路，让任务可以在用户需要时“毕业”到更自主的学习路径上。
一句话总结这个设计哲学：复杂归系统，简单归用户。
最好的抽象，是用户永远不必知道它存在
这篇博客的结尾有一句很值得玩味的话：“Best of all, the user never has to learn any of it.”最好的是，用户根本不必学这些。他们说想要什么，系统就在后台组装合适的原语，把活干了。
这才是平台产品成熟的标志。一套好的分类法，对用户是透明的，对构建者是可见的。用户在最外层说人话，工程师在中间层用共享词汇推理系统，原语在最底层默默组合。复杂度被藏起来了，但不是被消灭了，它只是被挪到了该待的地方。
把视线拉远一点。这不是 AWS 一家的事。Anthropic 推 Model Context Protocol，OpenAI 有 Agents SDK，Google 有 ADK，各家都在做同一件事：把 agent 世界里那些被反复重建的概念收敛成一套标准原语。当行业还在为“谁的模型更强”吵架时，基础设施层的玩家已经在为“谁的构件更标准”铺路。
模型会迭代，benchmark 会过时，但原语一旦成为标准，就会像数据库的关系代数、像操作系统的进程与线程一样，变成后来者不得不兼容的地基。
Agent 战争的上半场，比的是谁能把 agent 跑起来。下半场，比的是谁能给 agent 立规矩。AWS 这张分类表，是下半场的第一张出牌。
真正成熟的 agent 平台，不是让用户学会 trigger、skill、workflow 这些词，而是让用户说完“我想要什么”之后，再也想不起这些词的存在。
快报