Strands Agents：把AI Agent从“工程艺术”拉回“模型与工具”

AWS 的 Suman Debnath 在这场演示中介绍了 Strands Agents——一个刻意“反工程化”的开源 AI Agent SDK。它试图用极少的 scaffolding，把推理权真正交还给模型，并通过真实 Demo 展示：当你只保留模型与工具，Agent 反而能做得更多。

为什么 Strands 要“反对 scaffolding”？

在一开场，Suman Debnath 就抛出了一个非常明确、甚至有些激进的立场：Strands Agents 的“唯一动机”，就是让 AI Agent 变得尽可能简单。他反复强调一句话——“唯一需要的只有模型和工具（model and tools），没有别的。”

这并不是偷懒，而是一种对大模型能力变化的判断。Suman 认为，随着模型本身的推理能力不断增强，工程师再用大量 system prompt、背景说明、流程约束去“教”Agent 该怎么做，反而是一种历史包袱。他在现场直言：“我们不想用一堆 prompt、一堆 system prompt 去 scaffold agent 的 reasoning。”

Strands 的设计哲学非常清晰：推理属于模型，人类只负责提供工具。SDK 本身不要求你预先定义复杂的流程图，也不需要告诉 Agent 每一步该干什么。模型会根据目标，自主决定何时调用哪个工具。这种“放权”，正是 Strands 与许多 Agent 框架的根本区别。

在集成层面，Strands 并没有把用户锁死在 AWS 生态中。虽然默认使用 Amazon Bedrock 上的 Claude 3.7，但它同时支持通过 LiteLLM 接入任意模型，也可以用 Llama 在本地测试。这一点，让“简单”不只停留在理念层面，而是落实到了开发者的实际选择自由上。

两根“线”的 Agentic Loop：模型与工具

Strands 的 logo 里有两条缠绕的“线”，Suman 在演讲中半开玩笑地说，他是“昨天才知道”这两条线的含义：一条代表模型，一条代表工具。这正好对应了 Strands 的 agentic loop。

这个 loop 没有复杂的中间状态机，也没有显式的规划器（planner）。模型接收目标后，根据上下文自行决定是否、以及如何调用工具；工具返回结果后，再交回给模型继续推理。这种循环一直持续，直到模型认为任务完成。

为了让概念落地，Suman 选择了一个极其朴素的 Demo：从本地磁盘读取一个文件，总结内容，把总结写回磁盘，然后把结果“读出来”。听起来平淡，但关键在于三件事——读文件、写文件、文本转语音——全部使用 Strands 自带的默认工具完成，没有写一行自定义工具代码。

他强调：“你只需要 pip install strands 和 strands-tools，就可以直接开始。”在这个 Demo 里，Agent 没有被明确指示执行顺序，开发者只是用一句自然语言提出目标，剩下的执行顺序、工具选择，全部交给模型。这正是 Strands 想验证的一点：当 scaffolding 被拿掉，Agent 是否依然可控、且足够强大。

从文件总结到“开口说话”：一个完整 Agent 的最小形态

在代码层面，Suman 展示了 Strands 的“最小可用 Agent”。创建 Agent 时，只传入三样东西：模型、system prompt 和 tools。甚至在多数情况下，模型 ID 都不需要显式指定，默认配置即可工作。

当 Agent 接收到指令——“读取第 10 章，总结成 Markdown 文件，并读出来”——它自动完成了一整套动作链：先调用文件读取工具，再调用写文件工具，最后调用语音工具。现场扬声器里响起合成语音时，Suman 特意调高了音量，让所有人意识到：这不是幻灯片，而是真正在跑的 Agent。

这个 Demo 的价值不在于技术炫酷，而在于它展示了一种新的工程边界。过去，这种多步骤任务通常需要手写 orchestration 逻辑；而在 Strands 中，工程师只需描述“结果”，模型负责决定“过程”。这也解释了为什么 Suman 一再强调“我们希望模型来做 reasoning”。

对于熟悉 Agent 框架的人来说，这种极简方式可能一开始会让人不安。但正如这个 Demo 所展示的，只要工具设计合理，模型的推理能力已经足以支撑相当复杂的任务链。

Strands + MCP：把 Agent 接到“外部世界”

如果说前一个 Demo 证明了 Strands 在“本地任务”上的简洁，那么接下来的 MCP（Model Context Protocol）集成，才是真正让现场观众兴奋的部分。Suman 甚至自嘲道：“没有 MCP 和 Agents，我都被告知没法在这个会议上演讲。”

他设想的场景是：用 Agent 自动生成类似 Three Blue One Brown 的数学动画。这背后依赖的是 manim 库，而 manim 被封装在一个 MCP server 中。Strands 在这里的角色非常克制——它只是作为 MCP client，把 server 暴露出来的能力当作工具。

关键的一幕是：在创建 Agent 时，tools 不再是默认工具，而是 MCP server 提供的工具列表。Suman 特别指出：“我的 tool 就只是 MCP server。”Agent 并不知道 manim 的实现细节，只知道“我可以用这些工具生成可视化”。

当他输入诸如“在 x=3 范围内可视化一个三次方程”“解释 Byte Pair Encoding”“解释 SVD 和矩阵乘法”这样的提示时，Agent 自行推理需要生成多长的视频、调用哪些能力。这再次呼应了 Strands 的核心理念——不写 scaffolding，让模型自己想。

一行代码到交互式 Agent：工程体验的另一种可能

在演示的最后一部分，Suman 快速翻过了 MCP server 和 Agent 的完整代码。MCP server 中，每一个函数只需用 MCP decorator 包装，就会自动变成一个可被 Agent 调用的工具。

在 Agent 侧，创建流程同样直接：列出 tools，给出少量示例，然后用一行代码调用 Agent。甚至可以放进一个 while true 循环，立即变成一个交互式聊天体验。相比许多需要大量配置文件和中间抽象的框架，这种“扁平化”的工程结构显得异常轻量。

他还顺带展示了如何创建自定义工具：任何函数，只要用 Strands 的 tools decorator 包裹，就能被 Agent 感知和调用。这种一致的工具抽象，让默认工具、MCP 工具和自定义工具可以无差别混用。

在结尾，Suman 把 Strands 定位为一个真正的开源项目：GitHub 仓库、文档网站 strandsagent.com、示例代码全部开放，并鼓励大家提交 PR、分享自己构建的 Agent。这并不是一个“完成品”，而更像一次关于 Agent 未来形态的公开实验。

总结

Strands Agents 传递的关键信息并不是“又一个 Agent SDK”，而是一种判断：当模型足够聪明，工程师真正该做的，是设计好工具，而不是设计好流程。通过一系列看似简单却高度真实的 Demo，Suman Debnath 展示了一个可能的未来——Agent 不再是被层层提示词牵着走的脚本，而是能在模型与工具之间自由推理的执行者。对开发者而言，这既是一种解放，也是一种新的挑战。

关键词： Strands Agents， AI Agent， MCP， Amazon Bedrock， 推理

事实核查备注： 演讲者：Suman Debnath；SDK 名称：Strands Agents（开源）；默认模型：Amazon Bedrock 上的 Claude 3.7；可选模型：通过 LiteLLM 使用任意模型、Llama 本地测试；核心概念：model + tools，无 scaffolding；协议：MCP（Model Context Protocol）；演示工具：manim；功能演示：文件读取、文件写入、文本转语音、数学动画生成。