AWS 用四类原语梳理智能体架构

用户说「每天早上汇总 Slack 消息」，系统到底该创建一个新 Agent，还是给现有助手加个定时任务？Amazon Quick 团队发现，如果这些概念没有清晰边界，同一种能力就会被换着名字重复实现，最后还要用户替系统做选择。

他们给出的答案，是用 When、What、Who、How 四个问题拆解 Agent 工作。值得程序员借鉴的不是术语清单，而是背后的设计取舍：谁负责长期积累经验，谁负责启动任务，以及哪些步骤该交给模型判断、哪些该写进代码。

每增加一个任务，都需要新建 Agent 吗

Amazon Quick 团队把 Agent 定义为一个持续存在、能够学习的执行主体。它回答的是 Who，也就是「谁来干活」，并承接多次执行积累的经验。

按照这个定义，Agent 由三部分组成：

• Instructions 是长期指令，规定角色、上下文文件和行为原则。财务助手与通用助手的差异，首先来自这里。
• Capabilities 是当前可用的能力，包括 tools、skills、workflows 和 sub-agents，可以动态增减。
• Learned context 是使用中积累的经验，比如某个工具怎样查询更有效、用户偏好什么格式、哪些边界情况需要特别处理。

这里有一个容易混淆的区分：对话历史属于某次会话的状态，学到的经验才属于 Agent 的长期积累。底层大语言模型（LLM）则是可以替换的参数，不是 Agent 身份本身。

任务变了，不代表执行任务的主体也必须变。

所以，「监控 Slack 并每天发送摘要」通常只需要给已有 Agent 增加一个触发器。这个助手既能聊天，也能按时工作，还能协调任务、检查自己过去的执行情况。

触发器负责 When 和 What：既决定什么时候启动，也携带要做什么的指令。作者列出四种：

• 人工发起，由用户在对话中提出请求。
• Agent 委派，由一个 Agent 在执行中调用另一个处理子问题，也可能继续递归委派。
• 定时触发，例如每周一上午 9 点运行财务研究，每次沿用既定指令。
• 事件触发，例如新邮件、Slack 提及、文件变化或 webhook。

触发方式还会影响执行策略。后台定时任务遇到不确定情况，可以保守地不行动；用户正在对话时，则可以继续追问。它们可以共享同一个 Agent，但不必共享同一种交互策略。

Tool、Skill、Workflow，差别在谁决定步骤

三者都属于 How，回答「怎么完成任务」。作者用一条从模型自主决策到代码确定执行的连续谱来理解它们，并称之为 confidence contract。

这里可以理解为「对执行可控程度的约定」：用户预先固定多少，模型还能自由决定多少。它不是模型输出的置信度分数。

Tool 是带类型化 schema 的原子操作，比如发送邮件、查询数据库、读取文件。无论背后是本地函数、Model Context Protocol（MCP）服务，还是通过协议边界暴露的另一个 Agent，调用方看到的接口都包含名称、描述、参数和结果。

Skill 是允许判断空间的结构化指导。它把指令与模板、脚本、示例等资源打包，告诉 Agent 应该采用什么方法，但通常不固定完整的执行顺序。

Skill 还采用渐进式披露（progressive disclosure）：先让 Agent 看到名称和简短描述，相关时再读取完整说明。这样可以携带较深的专业知识，而不用每次都把全部内容塞进上下文。不过，这种设计减少的是持续加载成本，不代表使用 Skill 没有读取和执行成本。

Workflow 则把步骤、分支和错误处理写进代码，按声明的控制流执行。采购审批就是原文的例子：先检查预算，再由经理签字，最后交给财务，每个环节都留下记录。

区分 Skill 和 Workflow，关键看步骤顺序由模型决定，还是由代码决定。

Workflow 内部仍然可以调用 Agent 做判断。例如流程固定要求先检查预算，但具体材料如何理解，可以交给模型。固定的是协调路径，不是要求每个步骤都完全排除推理。

同一份日报，可以有三种合理实现

回到 Slack 日报，作者给出了三档实现方式。

第一档是定时任务加一句指令，让 Agent 自己决定检索、筛选和组织内容的方式。适合用户愿意给助手较大自主空间的情况。

第二档在相同任务后面挂一个 Skill，把格式规则、频道优先级等要求明确下来。模型仍可选择步骤，但不必每次重新猜测用户想要什么。

第三档调用 Workflow，固定执行步骤和错误处理。它更适合要求过程可检查、协调方式可预测的任务，原文用合规敏感流程说明这一需求。

三种方案都能按时产出日报，差别是用户要求多少确定性。作者主张选择满足信任要求的最简单方案，并保留进一步演进的路径。

他们也认为，模型变强不会让 Skill 和 Workflow 消失。Skill 承载的是组织经验，便于保存、版本管理和共享；Workflow 提供的是审计、逐步可见性，以及跨服务协调的确定性。这些价值不能单靠模型更聪明来替代。

两者也可以互相转化。已经摸清规律的 Skill，可以逐渐固化成 Workflow，作者称为 crystallization；频繁遇到例外的 Workflow，可以重新放宽为 Skill，称为 dissolution。

但这部分仍有信息缺口。作者表示 Amazon Quick 通过持续学习框架完成这种演进，具体机制要留到后续文章说明。本文没有交代系统如何判断转化时机、怎样验证新流程，以及出错后如何处理。

我的判断

我认同它把「长期主体」「触发机制」「执行能力」拆开的做法。对于同时提供聊天、定时任务和后台执行的产品，这套划分能减少重复实现，也能避免让用户面对「先选 Agent 还是先选 Workflow」的内部架构题。

它也没有把 Workflow 简化为落后的固定脚本。对审批、审计和多服务协作而言，步骤可见、失败位置明确，往往就是需求的一部分。相较于全部交给模型临场安排，把稳定流程写进代码有明确价值。

不过，这是一套产品架构经验，不是经过对照实验验证的效果结论。

原文说第 10 次执行会比第 1 次明显更好，却没有给出任务样本、评估指标或对照数据。学到的内容怎样去重、纠错、限制适用范围，也没有展开。「不改长期指令就能持续进步」可以作为设计目标，不能直接当成上线后的质量保证。

这套定义也有适用前提。作者把持久存在和学习视为 Agent 的组成部分，但普通团队的一次性 AI 任务，可能根本不需要长期身份和记忆。直接使用无状态模型调用、显式上下文和普通定时作业，结构可能更简单。

另一个前提是平台已经具备相应支撑。把触发器归到平台、把能力动态挂到 Agent 上，概念上很清楚；但权限怎样约束、任务重复触发怎样处理，本文没有说明。分类解决的是职责边界，工程实现仍需补齐。

能拿来做什么

• 给现有 Node AI 任务按 When、What、Who、How 做一次梳理，先检查多个定时脚本是否只是同一个助手的不同任务入口，再决定是否需要拆出多个 Agent。
• 做团队消息或邮件摘要时，先明确用户要求。允许结果灵活变化的任务可以从一句指令开始；已有稳定格式和筛选偏好的任务，可以把这些要求整理成 Skill。
• 如果流程要求固定检查顺序、记录每一步结果，或明确处理失败，就把协调逻辑放进 Workflow，并单独划出需要模型判断的步骤。
• 对重复任务保留可比较的执行记录，在引入长期记忆后检查结果是否改善；不要仅凭运行到了第 10 次，就认定 Agent 已经学会了用户偏好。