Software Engineering Radio：728期：Clare Liguori 谈用于 AI Agent 的 AWS Strands SDK

728期：Clare Liguori 谈用于 AI Agent 的 AWS Strands SDK

核心主题

本期播客围绕 AWS 推出的 Strands SDK，深入探讨了构建生产级 AI 智能体（AI Agent）的核心架构、设计哲学以及开发模式，旨在解答如何从传统工作流和繁琐的硬编码编排，转向以模型驱动（Model-driven）为核心的智能体工程实践。

基本信息

节目：Software Engineering Radio
嘉宾：Clare Liguori（Amazon Web Services 资深首席工程师，专注于开发者工具与 Agentic AI 领域）
日期：2026-07-09
来源：IEEE Computer Society
链接：https://se-radio.net/2026/07/se-radio-728-clare-liguori-on-aws-strand-sdk-for-ai-agents/

核心观点

智能体的本质是极简的三元组结构：任何 AI 智能体在架构上都可以拆解为「模型（Model）+ 工具集（Tools）+ 提示词（Prompt）」。过多且复杂的硬编码编排（Scaffolding）不仅增加了维护成本，还会限制大语言模型（LLM）自身的推理与泛化能力。
转向模型驱动的自主决策架构：随着大模型对工具调用（Tool Calling）和结构化输出支持的成熟，开发者应摒弃预设分支的流程图式编排（Workflow），转向将能力包装为工具，由模型自主决定执行路径的“模型驱动”模式。
确定性控制与灵活性平衡：生产环境中的智能体需要在自主性与合规性之间取得平衡。Strands 提出的「转向钩子（Steering Hooks/Guardrails）」机制通过在模型决策链路的关键节点注入确定性校验逻辑，替代了强绑定的工作流引擎。

Highlights 核心亮点

告别脚手架演进史：Strands 的诞生源于开发 Amazon Q Developer（现更名为 Q/Kira CLI）时的痛点。早期模型（如 Claude 2）无法稳定进行结构化工具调用，开发团队必须编写大量的重试和 JSON 解析器（Scaffolding）。随着 Claude 3.5 等模型的出现，这些底层的脚手架应被完全剥离，交由模型原生驱动。
检索增强生成（RAG）工具化：在智能体设计中，不应将检索到的上下文硬编码拼接进 System Prompt（Proactive RAG），而应将 RAG 封装为一个工具（Tool）。模型在需要时主动发起查询，这能显著降低 Prompt 污染并减少模型的混淆度。
转向钩子（Steering Hooks）替代工作流：硬编码的工作流逻辑（如 If-Else）会让智能体失去灵活性。Strands 推荐使用 Steering Hooks（转向钩子），在模型调用工具前/后进行阻断或重定向，例如在贷款审批场景中强校验“是否已验证收入”。
记忆与轨迹管理：Strands 引入了「账本（Ledger）」机制，作为智能体执行轨迹的唯一事实源。账本记录了智能体所有的步骤、工具调用和响应，不仅用于转向钩子的条件判断，也为后续的 Debug 和评估提供了基础。
评价与部署的性价比选择：在生产环境中，智能体评估应首先从具有“确定性轨迹”的用例开始。同时，利用 steering 机制注入 Python 确定性代码进行校验，比完全依赖大模型作为裁判（LLM-as-a-Judge）成本更低、可靠性更高，这也促成了 Strands 在 AWS 内部实现数周内快速交付上线的实践。

长文笔记

1. 智能体架构的演进：从“过度编排”到“模型驱动”

观点结论

智能体的构建哲学已从“基于硬编码规则的繁琐编排（Scaffolding）”演进为“模型驱动（Model-driven）”的极简架构。开发者应当信任并利用现代大语言模型自身的推理能力，而不是试图用代码限制模型的行为路径。

底层运行机制

在早期阶段（以 Claude 2 为代表），大模型缺乏原生的工具调用（Tool Calling）和结构化输出能力。开发者为了确保智能体能按格式输出，被迫在 Prompt 中用 Markdown 描述 JSON 结构，并围绕模型输出编写大量的重试循环（Retry Loops）和防御性解析代码。这种方式被称为“脚手架编排”。

随着模型（如 Claude 3.5）的发展，模型能够原生、稳定地输出结构化格式，并准确理解工具定义。Strands 倡导的“模型驱动”则是直接将底层脚手架剥离：

开发者只需定义模型、工具接口和基础提示词。
模型在运行时自主解析输入，选择最合适的工具，并根据工具返回的结果决定下一步行动。
检索增强生成（RAG）不再是在输入阶段将海量文档塞给模型，而是作为一个可选的“工具”提供给模型，由模型判断何时调用该查询接口。

支撑案例

在 Amazon Q 开发者工具（现为 Kira CLI）的早期版本中，团队为了防止模型生成格式损坏的 JSON，编写了复杂的拦截器。当升级到支持结构化工具调用的模型后，团队移除了这部分逻辑，转而将 API 接口作为 Tools 直接暴露给模型。结果表明，Agent 的执行效率和成功率不仅没有下降，反而因为减少了人工编写规则的干扰而大幅提升。另一个典型例子是 AWS 官方文档的问答 Agent：将 RAG 作为主动工具提供后，模型不再因为被动灌入不相关文档而产生认知偏差，其答复的准确度显著提升。

实践启发

对于新进入智能体开发领域的工程师，最常见的反模式（Anti-pattern）是编写了过多的编排代码。如果在开发过程中发现自己正在为智能体编写复杂的控制流（如状态机、多层嵌套条件判断），应当停下来思考：是否可以通过重新设计工具定义、优化 Prompt，或者更换推理能力更强的模型来替代这些硬编码逻辑。

2. 工作流与智能体编排的边界划分

观点结论

智能体不等于传统的工作流管理系统（Workflow）。工作流适合高确定性、无分支或固定分支的业务流程，而智能体适用于需要根据多变的环境信息进行动态决策的场景。试图在工作流引擎中强行塞入智能体，或用智能体完全替代工作流，都是不切实际的。

底层逻辑与对比

工作流系统（Workflow）：由确定的有向无环图（DAG）定义，执行步骤是预设的。虽然可以进行简单的条件分支（If-Else），但无法应对未知输入的组合。其底层逻辑是“过程式控制”。
智能体编排（Agent Orchestration）：执行路径在运行前是未知的，由大模型在每一步根据当前状态和工具返回的事实进行实时规划。其底层逻辑是“目标导向的动态决策”。

维度	工作流（Workflow）	智能体（Agent）
执行路径	静态、可预测的 DAG	动态生成、运行期决策
适用场景	流程标准化的业务（如财务报销审批）	逻辑复杂、需要推理与容错的场景（如故障排查、代码重构）
容错机制	预设重试与退避策略	模型自主修复、重新寻找替代工具

行业影响与实践启发

企业在落地智能体时，往往因为合规和安全要求而走向极端——将智能体框死在复杂的工作流引擎中，使其沦为仅仅填充文本的工具。合理的工程实践是解耦：由工作流引擎控制宏观的业务阶段（如：第一阶段收集资料，第二阶段运行智能体分析，第三阶段人工审核），而将具体的分析和操作细节交给智能体自主决策。

3. 转向钩子（Steering Hooks）的确定性控制机制

观点结论

为了在生产环境中对智能体进行合规性约束与行为校正，Strands 推出了“转向钩子（Steering Hooks）”机制。它提供了一种在不破坏模型自主决策的前提下，注入确定性业务规则的优雅方案。

运行机制

转向钩子类似于传统软件工程中的拦截器（Interceptor）或切面（AOP），但它是面向智能体执行轨迹的。Strands 维护了一个名为「账本（Ledger）」的结构，记录了当前会话的所有历史状态和动作。

当智能体尝试调用某个工具（如 approve_loan）时，Steering Hook 会被触发。该钩子并不依赖大模型来做合规判断，而是运行一段确定的代码（如 Python 代码）：

检查账本中是否包含已成功调用 verify_income 工具的记录。
如果存在该记录，且返回值为真，则允许执行 approve_loan。
如果不存在，钩子将拦截该请求，并向模型返回一条系统层面的修正指示（例如：“在批准贷款前，你必须先调用 verify_income 工具来确认用户收入”）。模型接收到该指示后，会自动跳转去调用收入验证工具。

[Agent Engine] -> 尝试调用工具: approve_loan()
      |
      v
[Steering Hook] -> 检查 Ledger 中是否存在 verify_income() 成功记录
      |
      +---> 有 ────> 放行执行工具
      |
      +---> 无 ────> 拦截请求，返回提示词: "请先验证收入" -> 引导 Agent 修正行为

实践启发

通过 Steering Hooks，开发者可以把合规要求（Guardrails）与业务逻辑解耦。这不仅保证了智能体的灵活性（它依然可以决定何时去验证收入，如何处理验证失败），又保证了核心风控底线不被突破。这比通过复杂的 Prompt 规定“先做 A 再做 B”要稳定得多，因为长提示词在复杂的多轮对话中极易发生“注意力漂移”。

4. 工具化演进：从本地函数到 MCP 协议集成

观点结论

工具是智能体与外部世界交互的桥梁。Strands SDK 通过支持本地定义（如 Python/TypeScript 函数）和标准化的模型上下文协议（MCP，Model Context Protocol），极大扩展了智能体的生态连接能力，使得跨服务、跨组织的工具共享成为可能。

运行机制

在 Strands 中，定义工具非常简单。开发者只需编写标准的 Python 函数，并利用 Pydantic 规范输入输出，SDK 会自动将该函数的签名、文档注释转换为模型可以理解的 Schema。

为了解决多团队、多系统间工具集成的混乱，Strands 深度集成了 MCP 协议：

MCP 客户端/服务端架构：允许开发者将常用的公共工具（如数据库查询、GitHub 操作、Slack 发送）部署为独立的 MCP 服务端。
动态接入：Strands 智能体可以通过网络动态连接这些 MCP 服务端，无需在智能体代码中硬编码任何 API 调用逻辑。
安全沙箱：MCP 将工具的执行环境与智能体本身的运行环境隔离，确保恶意的模型生成代码不会直接威胁到核心应用的安全。

行业启发

随着 MCP 的普及，未来的智能体开发将呈现出“工具集市”的图景。开发团队的重心将从“如何让模型调用我的 API”转向“如何为模型编写高质量的 MCP 工具接口”。良好的工具接口设计应具备：清晰的语义命名、详尽的参数描述（Desc）以及严格的输入校验。

5. 子智能体（Sub-Agents）与多智能体（Multi-Agent）的设计选择

观点结论

在面对超长上下文或跨领域复杂任务时，单一巨型智能体（Monolithic Agent）会因为 Prompt 冲突和工具集过大而失效。采用“子智能体（Sub-Agents）作为工具”的模式是降低系统复杂度的有效手段。

底层逻辑与运行机制

当一个智能体拥有超过 20 个工具时，大模型在选择工具时的错误率会呈指数级上升，同时系统 Prompt 的理解成本也会激增。Strands 推荐的解决方式是将特定的任务域划分给独立的子智能体，并将这些子智能体包装成父智能体的“工具”。

上下文隔离：父智能体只需要知道子智能体的输入输出契约（如同普通的 API 工具），子智能体内部的复杂 Prompt、特定工具调用细节对父智能体完全屏蔽。
按需加载：子智能体只有在被调用时才会初始化并消耗 Token，有效节省了上下文窗口（Context Window）空间。

支撑案例

在构建一个软件重构智能体时，如果将“读取文件”、“运行测试”、“分析代码”、“提炼文档”、“发送 Slack 通知”等所有工具直接塞给一个 Agent，模型很容易在代码分析过程中迷失。Strands 的做法是设计一个“代码分析子智能体”和一个“测试运行子智能体”。父智能体只需下达任务，由子智能体在隔离的上下文中完成具体操作并返回摘要结果。

6. 生产级智能体的测试、评估与快速部署实践

观点结论

AI 智能体研发的最大瓶颈在于测试与评估（Eval）。生产就绪（Production Readiness）要求建立一套能够自动化运行、具有确定性基准且性价比较高的评估体系。

运行机制与测试方法

Clare Liguori 结合 AWS 内部的开发经验，提出了以下智能体评估路径：

从确定性轨迹（Deterministic Trajectories）开始：不要一上来就尝试评估开放式的聊天（Open-ended chat）。首先评估那些有明确正确答案的用例，例如：“对于特定的输入，智能体是否最终调用了特定的工具 X”。
利用 Steering 机制加速评估：通过注入 Steering 钩子，开发者可以在不需要大模型作为裁判（LLM-as-a-Judge）的情况下，通过确定性代码自动判断智能体的账本（Ledger）中是否包含了正确的执行链路，这大大降低了评估成本，提升了评估速度。
可观测性第一：利用 open telemetry 标准，记录智能体的每一次决策、工具调用的延迟、Prompt 消耗。在发生线上故障时，能够通过轨迹图（Trace Map）清晰定位是模型决策错误，还是外部 API 工具响应超时。

行业影响

在 AWS 内部，基于 Strands 极简的模型驱动设计和确定性评估机制，开发团队仅用了 3 周时间就将 Kira CLI 从构想推向了生产环境部署。这种快速迭代能力直接得益于Strands 提供的可观测性工具和轻量化测试框架，证明了精简架构在工业级交付中的效率优势。