一句话结论
Amazon Quick 团队发布智能体原语分类法，用四个核心维度统一 AI 智能体系统术语，降低开发复杂度和跨团队沟通成本。
关键要点
- Amazon Quick 团队提出基于“何时（When?）、何事（What?）、何者（Who?）、如何（How?）”四问的智能体原语分类法，包含触发器、智能体、能力、工具四类核心原语。
- 触发器（Trigger）定义任务激活机制与执行风格：定时后台任务倾向保守执行（不确定时不行动），人为发起任务倾向响应式执行（不确定时询问用户）。
- 能力（Capabilities）层包含工具、技能和工作流三种形式，其核心设计原则为“置信度契约”（confidence contract），即智能体保留的决策自由度与用户预先固定的约束程度之间的平衡。
- 工具（Tools）是具有类型化模式（typed schema）的原子操作，无论底层实现是本地函数、模型上下文协议（MCP）服务器还是其他智能体，调用者看到的统一接口仅包括名称、描述、参数和结果四项。
- 技能（Skills）和工作流（Workflows）具备独立于模型能力的价值：技能用于捕获、版本化和共享机构专业知识，工作流提供可审计性和确定性多服务协调；二者可通过 Amazon Quick 的持续学习框架相互转化。
背景与事实
Amazon Quick 团队在构建智能体（Agents）系统过程中发现，缺乏统一的“agentic primitives”（智能体原语）定义导致相同概念在不同项目以不同名称被重复构建，造成开发资源浪费和架构理解偏差。团队针对这一痛点提出了一套结构化的分类法框架，通过“何时、何事、何者、如何”四个基础问题对任何智能体工作进行定位和拆解。
该分类法将智能体系统解构为四个核心原语层级。第一层为触发器（Trigger），作为工作的激活机制，它同时携带任务指令，回答了“何时”与“何事”两个问题。触发类型直接决定智能体的执行风格：定时后台任务倾向于保守策略，即在遇到不确定情况时选择静默不行动；而人为发起的任务则倾向于响应式策略，即在不确定时主动询问用户以获取确认。第二层为智能体（Agent），被定义为持久且具备学习能力的行动者，对应“何者”维度。它是智能体系统中学习和知识积累的锚点，由可替换的大语言模型（LLM）参数、每会话状态（会话历史）以及触发器（属于平台层）三部分组成。两个接受相同输入的智能体，可能因指令集、能力和历史数据的不同而表现出截然不同的行为结果。
第三层为能力（Capabilities），对应“如何”维度，涵盖工具、技能和工作流三种具体形态。该层级的核心设计原则是“置信度契约”（confidence contract），即明确界定智能体在特定任务中保留的决策自由度与用户预先固定的操作约束之间的平衡关系。不同用户对智能体的信任程度存在显著差异：对智能体高度信任的用户、曾被不一致结果困扰的用户以及运行合规敏感流程的用户，分别需要不同的置信度契约配置。例如，定时生成每日摘要（daily digest）的功能，在面对上述三类用户时，其底层处理机制和交互方式会有所区别。
第四层为具体的能力实现形式。工具（Tools）是具有类型化模式（typed schema）的原子操作，典型示例包括发送邮件、查询数据库等。无论底层实现是本地函数、模型上下文协议（MCP）服务器还是其他智能体，调用者看到的统一接口仅包括名称、描述、参数和结果四项，屏蔽了底层复杂性。技能（Skills）是留有判断余地的结构化指导，捆绑了模板、脚本、示例等资源。技能通过“渐进式披露”（progressive disclosure）机制加载：智能体初始仅可见技能名称和简短描述，仅在相关场景触发时才读取完整指令，从而以恒定的初始成本捆绑任意深度的专业知识。工作流（Workflows）则是确定性的协调机制，包含声明的步骤、控制流、分支和错误处理逻辑，按固定顺序执行，其决策逻辑位于代码层面而非依赖模型推理。
该分类法还揭示了技能与工作流之间的动态转化关系。技能和工作流的价值独立于模型能力本身：技能用于捕获、版本化和共享机构专业知识，工作流提供可审计性、步骤可见性和确定性多服务协调。在 Amazon Quick 的持续学习框架下，二者可相互转化：成熟的技能可“结晶”为工作流，而频繁处理边缘情况的工作流可“溶解”回技能。此外，该分类法的核心价值在于通过四个问题即可定位任何智能体工作，范围涵盖从单行聊天请求到定时的合规级流程。统一术语有助于开发者理解系统架构，允许产品层隐藏底层复杂性，用户无需学习这些机制，只需表达需求，系统即可自动组装相应的智能体原语。随着学习过程的推移，任务轨迹会持续变化，例如从“检查紧急邮件”这一简单指令开始，系统会积累领域特定的学习数据，包括有效的查询方式、首选格式及重要发件人，第十次运行时效果显著优于初始运行，且无需手动编码这些规则。
影响分析
对中文开发者而言，该分类法提供了明确的智能体系统架构设计参考，有助于在构建企业级 AI 智能体时避免概念混淆和重复开发。通过统一“触发器-智能体-能力-工具/技能/工作流”的层级结构，团队可在项目初期明确各组件的职责边界和接口规范，降低跨团队协作成本。置信度契约的显式化设计对合规敏感场景尤为关键，中文开发者在构建金融、医疗等受监管行业的智能体系统时，可据此设计差异化的用户信任配置机制，满足审计和合规要求。该框架还提示，智能体系统的长期价值不仅依赖模型能力，更依赖对机构知识的版本化管理和工作流的确定性协调，这为中文企业构建私有化智能体系统提供了可落地的架构思路。
适用边界
该分类法主要适用于 Amazon Quick 框架下的智能体系统构建，其原语定义和渐进式披露机制针对特定技术栈设计。对于基于其他智能体框架（如 LangChain、AutoGen）或纯模型驱动的场景，直接套用该分类法可能不适用，需根据框架特性调整原语层级和接口规范。此外，置信度契约的差异化配置假设用户群体存在明确的信任梯度，在用户画像模糊或信任边界不清晰的应用场景中，该机制的落地效果可能受限。
孤本观察
该分类法将“触发器”从传统的事件机制提升为与“智能体”“能力”同级的核心原语，这一设计判断暗示在智能体系统中，任务激活的时机与方式对系统行为的影响不亚于模型能力本身。将“渐进式披露”作为技能加载的核心机制，则反映了团队对上下文窗口成本与专业知识深度之间平衡的明确取舍。
常见问题
触发器类型如何影响智能体的执行策略？
定时后台任务倾向保守策略，遇到不确定情况时选择静默不行动；人为发起的任务倾向响应式策略，遇到不确定时主动询问用户获取确认。
工具层对调用者暴露的统一接口包含哪些核心字段？
无论底层是本地函数、MCP服务器还是其他智能体，调用者看到的统一接口仅包括名称、描述、参数和结果四项，以屏蔽底层实现复杂性。
“技能”的渐进式披露机制主要平衡了什么成本与收益？
该机制平衡了上下文窗口成本与专业知识深度。智能体初始仅加载技能名称和简短描述，仅在相关场景触发时才读取完整指令，以恒定初始成本捆绑深度知识。
在 Amazon Quick 框架下，技能与工作流之间存在怎样的动态转化关系？
二者可相互转化：成熟的技能可“结晶”为工作流，而频繁处理边缘情况的工作流可“溶解”回技能，通过持续学习框架实现机构知识与管理。
该智能体原语分类法对哪些现有框架或场景不直接适用？
该分类法主要针对 Amazon Quick 技术栈设计，直接套用于 LangChain、AutoGen 等其他框架或纯模型驱动场景可能不适用，需根据框架特性调整原语层级和接口规范。