AWS Strands Agents（亚马逊智能体框架）

AWS 团队在博客中回顾了这一转变的背景：早期模型没有原生工具调用能力，构建智能体需要复杂的提示词工程、响应解析器与编排逻辑，框架库因此不可或缺；但随着模型的原生推理与工具调用能力大幅提升，继续依赖重型编排反而在限制模型能力的发挥。Strands 的对策是模型驱动：开发者只定义提示词与工具列表，模型动态决定每一步做什么。

这与早期 ReAct 论文（见 arXiv:2210.03629）确立的「推理与行动交替」一脉相承，差别在于实现层把编排职责从框架代码转移到了模型本身。对简单场景，几行代码即可得到可用智能体；对复杂场景，再按需定制工具选择、上下文管理与状态存储。

Strands 的核心循环很直接：每轮把提示词、智能体上下文与工具描述交给模型，模型可以回复最终答案、规划步骤、反思前序操作，或选择一个或多个工具；框架执行工具、把结果回传模型，循环往复直到任务完成。

工具生态是它的另一条主线：原生支持 MCP，意味着数千个现成的 MCP 服务器可以直接挂为工具；SDK 另带 20 余个内置示例工具，覆盖文件操作、API 请求、AWS 服务交互等；@tool 装饰器让任意 Python 函数一行代码变成工具。博客还展示了两个有代表性的模式：检索工具——把数千个工具的描述存进知识库，用语义搜索按需取回相关子集交给模型（有内部智能体的可选工具超过 6,000 个）；思考工具——把深度分析建模为工具，由模型判断何时需要多轮深思。

对复杂任务，Strands 内建三种多智能体协作模式：Swarm（集群）、Graph（图）与 Workflow（工作流）。它的独特之处在于把这些编排结构建模为工具：工作流、图与集群都作为工具暴露给模型，由模型推理判断当前任务是否需要动用某种编排，以及何时把工作委派给子智能体。

这种「编排即工具」的思路与预定义 DAG 式的编排框架形成方法学对照：前者信任模型的判断，把控制权留在运行时；后者把控制流固定在代码里，换取确定性与可审计性。两者各有适用面——对高确定性要求的合规场景，固定工作流仍更稳妥。

Strands 与 AWS 托管服务的衔接是它的现实优势：与 Amazon Bedrock、AWS Lambda、AWS Step Functions 等服务无缝集成，可配合容器化与无服务器方案部署，并内置监控追踪机制。它定位为通用开源 SDK——可在任何环境运行、支持任意具备推理与工具调用能力的模型，并不强制绑定 AWS。

生产背书方面，AWS 内部的 Amazon Q Developer、AWS Glue 与 VPC Reachability Analyzer 都在使用 Strands；AWS Transform for .NET 服务也以它为底层，用多个专门化智能体协作完成 .NET 应用的现代化改造。开源社区的参与方包括 Accenture、Anthropic（贡献 Anthropic API 支持）、Meta（贡献 Llama 支持）、Langfuse、mem0.ai、PwC、Tavily 等。官方博客表示对 A2A 协议的支持在计划中。

模型驱动的思路并非没有代价：把控制权交给模型意味着行为的空间变大，对延迟、成本与确定性的控制力弱于固定编排。AWS 自己的文档也将其定位为「适合构建全自主方案」的框架——对每一步都需要人工确认或强合规约束的流程，显式工作流可能仍是更好起点。

与既有框架的关系上，Strands 与 LangGraph 等编排优先框架互补而非互斥：前者适合模型能力足够、希望减少脚手架的场景；后者适合需要精细控制状态机与流转条件的场景。选型时值得按「自主度需求」而非框架知名度来决策。后续版本与生态动态将持续跟进。

Strands 代表的模型驱动路线正随模型原生能力增强而获得更多验证，AWS 内部生产系统与外部贡献者的加入使其生态快速扩展。多智能体模式、A2A 协议支持与跨云部署能力是后续演进方向。版本与生态动态将持续跟进。