The InfoQ Podcast：迈向模型驱动与生产落地：Strands Agents 的大模型智能体架构实践

迈向模型驱动与生产落地：Strands Agents 的大模型智能体架构实践

核心主题

本期播客围绕开源智能体开发框架 Strands Agents 展开，重点讨论了智能体（Agents）如何从简单的 Python SDK 演进为能够运行在生产环境中的高可靠系统，探讨了模型驱动架构的优势，以及在大模型持续演进的背景下，如何解决智能体在实际工程落地中的可靠性、评估与长程任务处理等难题。

基本信息

节目：The InfoQ Podcast
嘉宾：Clare Liguori（AWS 资深首席工程师、Strands Agents 开源项目技术负责人）
日期：2026-07-21
来源：InfoQ
链接：https://soundcloud.com/infoq-channel/strands-agents-with-clare

核心观点

智能体架构应转向模型驱动（Model-Driven），而非受限于硬编码的工作流（Workflow-Based）：早期智能体框架过度依赖开发者手动定义复杂的分支与逻辑链条，这在面对不可预测的用户输入时极易碎裂。应当将规划、工具调用和决策的权力交还给模型本身。
在生产环境中保障智能体可靠性的核心在于“评估机制（Evals）”与“运行时钩子（Hooks）”的结合：不能依靠完全限制大模型行为来追求安全，而应通过轻量化模型在运行时对输入/输出及工具调用进行动态阻断与校验（即 Steering Hooks），并在离线状态下利用评估套件进行持续回归测试。
传统的确定性软件工程思维在大模型智能体开发中面临失效：开发者必须适应非确定性（Non-deterministic）系统，从追求“单元测试 100% 通过”转向“基于数据集的概率性效果评估”，通过可观测性数据（如 OpenTelemetry 追踪）反向迭代系统提示词与工具设计。

Highlights 核心亮点

Strands Agents 起源于 AWS 内部解决客户自动化管理资源的工具，因其通用性和易用性，最终演变为向全社区开放的开源智能体 harness 框架。
模型驱动架构简化了开发流程，开发者只需定义系统提示词（System Prompt）、工具集（Tools）和模型选择（Model）这三个核心要素即可快速构建智能体。
智能体的评估（Evals）是走向生产环境的核心瓶颈，Strands 推出了专有的 Evals 工具包，帮助开发者量化智能体偏离预期轨迹的概率。
引入了“转向钩子（Steering Hooks）”机制，通过在运行时维护智能体完整的工具调用账本（Ledger），实现对复杂前置依赖业务逻辑的 100% 确定性拦截与引导。
智能体正从简单的“单次问答交互”向长程任务（Long-running tasks）演进，这要求框架必须提供上下文压缩、状态持久化与中断恢复等“智能体容器（Harness）”级别能力。

长文笔记

从工作流限制到模型驱动：智能体架构的根本性转变

观点结论

智能体开发框架正从“基于硬编码工作流”向“模型驱动”演进，给予模型更大的规划与推理自主权是提升智能体应对复杂生产环境鲁棒性的关键。

支撑论据与案例

Clare 提到，早期的智能体框架非常沉重，要求开发者在代码中定义极其复杂的图结构和控制流分支。然而，在 AWS 实际的客户服务场景中，用户总是会提出超出开发人员预设范围的复合型问题（例如：“帮我分析这个资源账单，同时把超过预算的服务关掉”）。在硬编码的工作流中，这类非线性、跨领域的输入极易导致系统崩溃。

底层逻辑与运行机制

模型驱动架构（Model-Driven Approach）的核心是精简框架本身的逻辑，只保留三个核心输入：系统提示词（System Prompt）、工具集（Tools）以及指定的 LLM 实例。框架不再规划具体步骤，而是把推理（Reasoning）、工具调用（Tool Calling）和多步骤规划（Planning）的责任完全交给大模型本身。以 Claude 3.7 Sonnet 等模型为例，它们本身已具备极强的长程规划与工具链调用能力，框架仅充当执行大模型决策的运行时环境。

行业影响与实践启发

这种转变为开发者带来了两点变革：

开发门槛急剧降低：开发者无需学习复杂的有向无环图（DAG）构建 API，只需几行代码配置好提示词与工具定义即可上线智能体。
避免过度工程化（Over-engineering）：开发者容易陷入主动为智能体填充各种上下文的误区（如过度设计 RAG 管道）。实践表明，模型在具备主动调用工具的能力后，能够根据需要自主拉取（Retrieve）信息，比开发人员硬编码灌入信息更高效。

生产环境的防线：Steering Hooks 与运行时治理

观点结论

解决大模型智能体“越轨”或“幻觉”的有效手段不是限制模型的推理自由度，而是在运行时部署基于历史调用账本（Ledger）的拦截与评估钩子（Steering Hooks）。

支撑论据与案例

在 AWS 的实际应用中，智能体可能涉及敏感操作（如修改安全组规则或审批贷款申请）。传统的做法是限制智能体只能执行无害查询，或者使用极其复杂的代码层层拦截。Strands Agents 引入了运行时钩子（Hooks）机制，在不破坏模型规划自由度的前提下，实现了安全和确定性的双重保障。

底层逻辑与运行机制

运行时钩子的核心是利用轻量级大模型进行实时审计。Strands 支持以下几种运行时控制模式：

输入/输出过滤：在响应返回给用户前，利用低成本的模型（如 GPT-4o-mini 或更小参数模型）评估该响应是否包含敏感数据，或是否违反合规策略。
转向钩子（Steering Hooks）：这是比普通 Hook 更进阶的控制方式。Strands 会在内存中维护一个“账本（Ledger）”，完整记录智能体自本次会话开始以来执行过的所有工具调用路径。当智能体尝试调用某个关键工具（例如 approve_mortgage）时，Steering Hook 会拦截该请求，扫描账本以验证前置必要条件（如 verify_income）是否已被成功调用并返回合规结果。如果未检测到，Hook 将阻止该调用并向大模型返回明确的错误提示信息，引导大模型重新规划并去调用缺失的工具。

[智能体决策: 调用 approve_mortgage]
              │
              ▼
    [Steering Hook 拦截] ────查阅────► [运行时账本 (Ledger)]
              │                               │
       检查是否已调用:                         │ (记录了历史调用路径)
       verify_income ?                         │
              │                               │
      ┌───────┴───────┐                       │
     YES              NO                      │
      │               │                       │
      ▼               ▼                       │
[放行工具调用]  [拒绝调用，并向大模型] ◄────────┘
                [返回错误: "需先验证收入"]

行业影响与实践启发

Steering Hooks 使得开发者能够以极低的成本将业务规则（Business Rules）强制约束在非确定性的智能体系统中。通过将规则判定放在运行时钩子中，智能体既能保留面对突发输入时的规划灵活性，又能在关键红线上表现出百分之百的确定性。同时，使用小模型作为运行期审计员，规避了调用大模型的延迟与高昂成本。

质量评估的重构：从确定性测试到概率性评估

观点结论

智能体质量的度量无法再依赖传统的软件测试通路，必须构建以“评估集（Evals Kits）”为核心的离线与在线概率评估体系。

支撑论据与案例

Clare 提到，很多传统软件工程师在刚接触智能体开发时，会试图为其编写标准的单元测试，并期望其每次都能稳定输出相同的值。当他们发现智能体的输出具有非确定性时，往往会感到挫败。为了解决这个问题，Strands 开源了配套的 Strands Evals Kit。

底层逻辑与运行机制

评估智能体主要通过两类评估器（Evaluators）来完成：

工具调用比对评估：对于业务导向的智能体，最直接的评估指标是“工具调用的准确性”。如果给智能体分配任务 A，正确的调用路径是工具 1 + 工具 2，那么通过离线批量运行测试集，比对智能体实际生成的工具调用序列与标准答案是否一致，即可得出其准确率。
大模型裁判（LLM as a Judge）：对于开放式回答，采用一个独立且没有参与任务执行的 LLM 实例（通常使用不同的模型提供商以避免自我偏见），对照预先设定的评估维度和评分细则（Rubrics），对智能体的最终输出和中间思考链（Chain of Thought）进行打分。

行业影响与实践启发

软件工程师需要完成思维模式的转变：

接受非确定性：开发智能体更像是做科学实验或训练宠物，不能要求 100% 的单元测试通过率，而应关注整体测试集（Evaluation Dataset）的“通过率百分比”。
利用生产数据迭代测试集：测试集不应该是静态的。当生产环境中的智能体因为客户的特异输入而出现非预期行为（如死循环调用工具）时，应当将该真实案例捕获并脱敏，转化为新的测试样本加入离线评估集中，从而形成持续集成与持续评估（CI/CD/CE）的闭环。

智能体 Harness：支撑长程任务与生产级运维

观点结论

一个合格的智能体 Harness（运行容器）必须提供超出简单框架层面的系统级能力，包括上下文管理、状态持久化与全链路观测性，以支持小时级甚至天级维度的长程复杂任务。

支撑论据与案例

Strands 框架在 AWS 内部被广泛用于支持复杂的网络故障排查和资源调配。这类任务无法通过单次请求-响应（Request-Response）完成，智能体需要调用十几个甚至几十个 API，耗时可能长达数十分钟甚至数小时。在此期间，任何网络波动或后台任务超时都可能导致智能体崩溃。

底层逻辑与运行机制

为了实现生产级可运维，Strands 设计了以下系统支撑能力：

可观测性集成（OpenTelemetry）：智能体内部的每一步动作（大模型推理、系统提示词拼接、工具调用参数与返回值）都会生成详细的 Trace。这些 Trace 采用开放标准（OpenTelemetry），可以直接无缝接入现有的企业级监控系统（如 CloudWatch、Datadog 或 OpenSearch），方便运维团队在智能体陷入死循环或输出异常时进行单步回溯。
持久化与可中断恢复（Persistence & Resumability）：由于智能体需要处理长程任务，Strands 支持将当前会话的上下文（包括大模型的对话历史、当前的工具执行状态、决策 Ledger）序列化并保存到持久化存储介质中。当发生网络中断或进程崩溃时，可以在新的计算节点上重构该状态，并向大模型传递中断上下文，由其决定是重试上一次失败的工具调用还是改变策略。
上下文主动管理（Active Context Management）：大模型的上下文窗口虽大，但冗长的历史会急剧拉高推理成本并降低模型的专注度。Strands 在运行容器层面支持对历史对话进行语义提取与阶段性摘要总结（Active Summarization），主动剔除无用的工具返回值明细，仅保留关键事实，确保大模型始终运行在高信噪比的输入环境中。

实践启发

对于计划将智能体推向生产环境的软硬件架构师而言，这表明智能体开发的核心挑战已经不在于提示词工程（Prompt Engineering）或如何接入某个特定的新大模型，而在于如何构建支撑智能体稳定运行的“底层基础设施”。选择或构建具备状态管理、运行期拦截和高标准可观测性的 Harness 框架，是降低生产环境故障率、实现系统平稳落地的基石。