Strands Agents：完全开放的智能体构建基座

本次工作坊由Sandy和Elizabeth主持，旨在引导参与者从构思、定制到部署完整构建智能体（Agent）。我们将以Strands Agents作为核心工具，这是一个由AWS维护但完全开源的智能体框架（Agentic Harness）。该框架的核心理念是“Bring Your Own LLM”，即允许开发者接入任何大语言模型提供商的模型，从而在底层构建完全可控的智能体应用。Sandy强调：“Strands agents is an open-source agent harness which means you can bring your own LLM... and control it end to end.” 这种开放性不仅体现在模型选择上，还允许开发者添加自定义工具、利用GitHub社区支持以及遵循MCP和A2A等开放协议。无论是本地运行还是部署在AWS托管服务上，Strands Agents都提供了极高的灵活性和端到端的控制能力。

Agent Core：生产级智能体运行时环境

为了将构建好的智能体投入生产，工作坊推荐使用Amazon Bedrock Agent Core。这是一个专为部署智能体而设计的服务，其核心是Agent Runtime（运行时容器）。Sandy指出：“Amazon Bedrock Agent Core is a service dedicated only to put agents in production.” 该运行时支持多种框架（如LangChain、CrewAI等），开发者只需将代码放入容器，即可通过CLI一键部署。Agent Runtime内置了会话管理（Session Management）功能，支持从15分钟到8小时的运行时长。更重要的是，它提供了企业级的安全性、自动扩缩容能力以及“不用于训练模型”的数据隐私承诺。所有数据仅在用户账户内使用，无需管理底层基础设施的扩展问题。

内置可观测性与三层记忆架构

Agent Core的一大优势在于其内置的智能体级可观测性（Agentic Observability）。Sandy澄清道：“observability is not about the RAM... it's about agentic observability.” 开发者可以通过CloudWatch监控Token消耗、工具调用情况及智能体循环内的具体行为，而不仅仅是容器资源状态。此外，Agent Core提供了三种内置记忆类型：短期记忆（Runtime内建）、长期语义记忆和自定义提示词驱动的记忆。Sandy解释：“Agent Core build for you in three different types of memory... You don't have to build the vector store.” 开发者只需声明需要Agent Core Memory，系统即可自动部署语义搜索能力。同时，通过Agent Core Gateway，所有工具和MCP协议可通过单一端点暴露，并利用语义搜索为智能体循环选择最佳工具。

工作坊议程与进阶内容展望

本次一小时的工作坊将聚焦于基础概念，包括智能体循环（Agent Loop）的构建、Hooks（钩子）、Skills（技能）和Steering机制。Ellie将负责讲解会话管理及如何部署至Agent Core运行时。虽然时间有限，无法深入所有高级概念或评估框架（Evalentic Frameworks），但Sandy表示：“We want to take it slow... make sure everyone understands the basics.” 参与者将获得可在会后两天内运行的代码环境。如果时间允许，将简要介绍评估框架；若未涵盖，参与者仍可通过链接在后续两天内访问相关资源。整个流程旨在确保每位开发者都能掌握从基础到生产部署的关键路径，无需额外配置即可拥有记忆和可观测性支持。

工作坊接入与账户准备

本次演示的“Agent Speedrun”工作坊为参与者提供了预配置的AWS环境，无需个人信用卡或创建新账户即可免费使用。该资源最初为约250名参与者开放，若遇名额已满或技术故障，现场备有备用链接。用户需通过指定链接进入Workshop Studio账户界面，首次访问仅需输入邮箱并验证一次性密码（OTP）。这一流程旨在降低技术门槛，确保所有参与者能直接在云端环境中运行代码。

"You don't have to create your own AWS account. Uh these accounts are already created for you... It's free of charge."（你不需要创建自己的AWS账户。这些账户已经为你准备好了……这是免费的。）

在登录过程中，若遇到网络或Wi-Fi问题导致无法同步操作，演讲者承诺将在会议结束后分享所有幻灯片及代码仓库。参与者可克隆该Jupyter Notebook格式的存储库，在本地或后续时间内复现实验内容。这种设计兼顾了现场互动的即时性与学习资源的长期可用性，确保即使因网络波动掉队的用户也能完整掌握构建过程。

开发环境配置与内核选择

进入Workshop Studio后，界面左侧提供分步操作指南（Step-by-step walkthrough），右侧则展示代码编辑器。对于网络状况良好的用户，可直接点击“Agent Speedrun Code”按钮并滚动至底部获取代码编辑器URL。然而，成功运行模块的关键在于正确选择Python内核。演讲者强调，每个新打开的Jupyter Notebook模块都必须手动配置环境。

具体操作为：在Workshop Studio的设置（Setup）页面中找到“Next Steps”，复制推荐的Python环境路径，通常为/usr/bin/python3.13。随后在代码编辑器中点击“Select Kernel”，粘贴该路径并确认选择。这一配置步骤必须在每个模块运行时重复执行，以确保代码能在正确的解释器中编译和运行。若用户跳过此步或选择错误内核，将导致代码无法执行。现场工作人员会协助解决此类基础配置问题，确保技术障碍不影响核心内容的学习。

构建客户服务智能体（Module One）

工作坊的第一个模块聚焦于使用Amazon Bedrock API构建客户服务智能体。演讲者指出，参与者将有机会调用Anthropic模型以及Amazon自身提供的多种大语言模型。这些API通过Bedrock服务进行统一接入，使得开发者无需管理底层基础设施即可快速集成先进的AI能力。此外，Amazon Bedrock Agent Core的使用成本较低且易于批准，尽管新用户可能因不熟悉计费模式而产生顾虑，但实际体验显示其费用可控。

"Today we're building a customer service agent and we're building that using Strand's agent."（今天我们正在构建一个客户服务智能体，并使用Strand的智能代理来构建它。）

在实操环节，参与者将基于预置的代码框架进行定制和运行。代码以Jupyter Notebook形式呈现，支持直接执行、下载或在本地环境修改后复现。这种“即插即用”的模式让参与者能专注于智能体的逻辑构建与API交互，而非环境部署。通过这一模块，观众将直观理解如何利用AWS生态中的现成工具链，快速开发出具备实际业务价值的AI代理应用。

Strands Agent Harness 的多模型兼容架构

Strands Agent Harness 是一个基于代理循环（Agent Loop）的框架，旨在简化大语言模型（LLM）与外部工具的集成。用户输入包含上下文和问题，框架核心在于其原生支持 Amazon Bedrock 托管模型的能力。然而，该架构的灵活性远超单一供应商限制：开发者可以接入任何偏好的模型提供商，包括本地部署的 Llama 或 Hugging Face 上的其他开源模型。实现这一兼容性的关键在于代码层面的解耦，开发者只需在调用处定义模型名称即可切换后端。正如演讲者所述：> "you can use any of your favorite model providers... you just have to specify model and your model name"。这种设计允许团队在不改变系统提示词（System Prompt）或架构结构的前提下，自由替换底层模型进行性能对比。这意味着相同的样板代码可以适配不同的 LLM 基准测试，极大地降低了多模型评估的复杂性。

工具定义与代理执行逻辑

Agent 的强大之处源于其推理循环（Agentic Reasoning Loop），这解决了 LLM 仅靠预测下一个 token 无法获取实时事实的问题。为了赋予代理执行具体功能的“能动性”（Agency），必须定义一组工具，将 LLM 的推理能力与真实数据源（如数据库、文件）连接起来。在演示中，团队构建了一个客户服务代理案例，首先创建了包含两名客户及其订单状态的模拟数据字典。工具的定义遵循统一模式：使用 @tool 装饰器编写功能代码或 NLP 工具。具体实现了三个核心工具：1. get_customer_id（查找客户 ID）；2. get_order_history（获取订单历史）；3. process_refund（处理退款）。这些工具虽然功能各异，但都遵循相同的装饰器格式。代理通过 LLM 的推理能力决定何时调用哪个工具，从而确保回答基于事实来源而非模型内部知识。这种机制使得代理能够根据用户请求，动态选择并执行相应的数据查询或事务处理。

系统提示词与代理交互流程

创建 Agent 仅需三个基本要素：系统提示词（System Prompt）、LLM/模型配置以及已定义的工具列表。在客户服务场景中，系统提示词起到了关键的指导作用。演讲者展示了具体的指令设定：> "Always verify customer using look up customer before taking action. Use tool data to answer questions."。这些指令明确了代理的行为规范，例如在执行任何操作前必须先验证客户身份，且必须利用工具返回的数据来回答问题。当用户输入“我是某某客户，请检查我的最近订单”时，代理启动推理循环：首先调用 get_customer_id 工具进行身份验证，随后调用 get_order_history 获取订单摘要。整个过程对用户而言是无缝的，代理最终汇总信息并询问是否还有其他帮助需求。这种交互模式展示了从自然语言输入到结构化工具调用，再到最终文本回复的完整闭环。通过这种方式，开发者可以构建出既具备语言理解能力又拥有精确操作权限的智能代理。

内部机制监控与消息追踪

为了调试和理解 Agent 的内部运作，Strands 框架提供了对代理循环（Agent Loop）的详细监控能力。传统的黑盒模式让开发者难以掌控 Agent 的行为，而该框架允许检查 agent_messages。在用户发送消息后，系统记录了完整的交互历史：包括用户的初始输入、助手的回复、以及中间产生的工具调用（Tool Call）和对应的工具结果。例如，在一次订单查询中，消息流清晰地展示了从用户请求到助手调用 tool one（客户查找），再到 tool two（订单历史）的完整路径。这种透明度对于故障排查和性能优化至关重要。通过查看消息对象，开发者可以精确分析 LLM 在每一步的决策逻辑、工具调用的准确性以及响应生成的时机。这种可观测性确保了代理系统的可控性，使团队能够深入理解“幕后”发生了什么，从而优化提示词或工具定义以提升整体表现。

基础Agent的多轮对话实现

视频首先展示了如何从单轮交互扩展到多轮连续对话。虽然基础演示仅涉及单次问答，但通过启用 chat.py 模块，开发者可以运行支持扩展聊天功能的Agent。该模块下的每个子目录都包含对应的 chat.py 文件，其底层代码逻辑与单轮版本完全一致，仅开启了多轮会话支持。用户只需在终端中安装依赖并运行脚本，即可直接通过命令行与Agent进行多轮交互。整个过程仅需不到 60 行代码，即可实现具备工具调用能力的完整Agent系统。这种设计使得开发者能够以极低的代码成本，快速验证Agent在持续对话场景下的表现。

Hooks机制的核心价值与控制点

为了提升Agent的健壮性与可控性，演讲者引入了Hooks（钩子）机制。Hook允许开发者在Agent生命周期的关键节点插入自定义代码，从而实现对执行流程的程序化控制。具体而言，开发者可以在以下关键阶段介入：Agent被调用前（Before Invocation）、LLM生成响应后但工具执行前（After LLM Call / Before Tool Call）、以及工具执行完成后发送响应前。在这些节点，可以嵌入断言（assert）或验证函数，用于身份校验、问题类型过滤以及速率限制。例如，可以检查用户是否有权访问特定工具，或判断当前问题是否在Agent的服务范围内。这种机制确保了在最终输出之前，所有前置检查均已通过，从而有效防止Agent因异常行为导致的资源浪费或安全风险。

基于Hooks的速率限制器实战案例

演讲者通过一个具体的速率限制器（Rate Limiter）示例，演示了Hooks的实际应用。该Hook旨在防止LLM因“发疯”而无限循环调用工具，从而消耗大量Token。实现逻辑包括：定义一个最大调用次数（如 3次），并在每次用户新请求时将计数器重置为0。在 Before Tool Call 事件中，Hook会检查当前工具调用次数是否超过上限；若未超限则允许执行并递增计数，若已超限则直接阻断后续调用。在测试中，当设置最大调用次数为1时，Agent仅执行了一次工具查找便触发阻断机制，成功阻止了后续的工具调用。这证明了Hooks能够有效实施硬停止（Hard Stop）策略，确保Agent在异常情况下不会失控。

Hooks：从概率性LLM到确定性控制

在构建基于大语言模型（LLM）的Agent应用时，一个核心挑战在于LLM的本质是概率性的。正如演讲者所指出的：“When you use a hook, you can be more deterministic.” 这意味着仅靠Prompt作为建议是不够的，我们需要在Agent循环中加入代码逻辑来实现更严格的控制。Hooks允许我们在工具调用之前（Before Call）或之后（After Call）插入Python代码，从而对Agent的行为进行干预。

这种机制带来了显著的性能和安全优势。首先，通过前置Hook可以实施速率限制（Rate Limiting）或逻辑阻断。例如，如果检测到Agent试图连续调用超过三个工具，或者涉及敏感信息（如信用卡号），Hook代码可以立即拦截该请求。演讲者强调：“You don't waste tokens because you are stopping that.” 这种拦截避免了无效的模型调用，节省了Token消耗。其次，后置Hook可用于过滤输出内容，防止向客户服务发送不当回答。

针对现场观众关于“如何避免Agent陷入无限循环”的提问，演讲者澄清：虽然演示中为了展示Hook的工作机制（如反复拦截工具调用）而保留了循环，但在实际生产中，“we can define the hook in such a way to even end the agent's turn if we wanted to.” 开发者可以自定义Hook逻辑，在检测到特定条件时直接终止当前回合（End Turn），从而确保系统的稳定性和确定性。

Skills文件夹：动态上下文注入与知识管理

为了解决Agent在面对复杂或特定领域问题（如退款、订单追踪）时知识不足的问题，AWS引入了Skills文件夹机制。这是一种将“单一事实来源（Single Source of Truth）”以Markdown文件形式存储的方法，用于指导Agent如何处理特定类型的问题。

“When a certain type of question is being asked, we can give it context that is relevant to that specific type of question.”

传统的系统提示词（System Prompt）如果包含所有信息，会导致输入Token浪费。Skills机制通过动态加载相关上下文来解决这一痛点。例如，“Account Troubleshooting”技能文件详细列出了重置密码、解锁账户等步骤；“Order Tracking”则包含追踪订单的标准流程。当用户提出请求时，Agent首先检索Skills文件夹，识别当前问题所属类别（如“account issues”），然后仅加载对应的技能插件。

这种设计使得Agent的行为更加确定性（Deterministic）。它不再仅仅依赖LLM的通用推理能力，而是像调用工具一样“调用”技能文件。例如，当用户询问无线耳机退款时，Agent会激活相应的Skill插件，获取账户信息并遵循预设步骤。这种方式不仅提高了回答的准确性，还确保了Agent在处理高频常见问题（FAQ）时遵循标准化的操作程序。

Steering与技能组合：构建稳健的Agent系统

在Hooks和Skills的基础上，演讲者进一步探讨了Steering（引导/操控）的概念。通过结合Hooks的硬性控制和Skills的动态知识注入，开发者可以更精细地引导LLM按照预期方式响应。这种组合使得Agent能够处理多轮对话（Multi-turn Conversations），并在不同模块中灵活切换。

在实际操作中，开发者可以通过修改chat.py等代码文件来启用Hooks并测试不同的Skills组合。例如，可以设置Hook阻止特定类型的客户提问，或者在对话过程中动态切换不同的Skill插件以应对不断变化的用户需求。演讲者指出：“It's becoming more and more deterministic. It’s got a natural order.” 这种结构化方法确保了Agent在处理客户服务等关键任务时，既能保持灵活性（通过LLM的自然语言理解），又能维持严格的业务逻辑约束。

最终，这种架构允许开发者在不溢出系统提示词容量的前提下，为Agent提供丰富的领域知识。通过将Skills作为插件（Plugin）参数传递给模型，系统能够根据实时需求精准匹配上下文信息。这不仅优化了Token使用效率，还通过明确的指令集（Instructions）减少了模型幻觉的风险，为构建生产级、高可靠性的Agentic系统奠定了坚实基础。

解决输出格式失控：引入Buddy Agent进行实时纠偏

在构建AI代理（Agent）时，开发者常面临一个痛点：模型虽然能回答复杂问题，但往往输出冗长、格式混乱或包含不必要的符号（如破折号），导致无法直接用于生产环境。结构化输出是确保系统稳定性的关键，而传统的提示词工程难以保证每次调用的确定性。为此，AWS提出了Steering（引导/转向）机制，其核心理念类似于编程中的“结对编程”或Buddy Agent（伙伴代理）。当主Agent生成响应时，Buddy Agent会实时监听并检查输出内容。

从 Jupyter Notebook 到 CLI 的生产环境迁移

将 AI Agent 应用投入生产时，开发阶段使用的 Jupyter Notebook 并不适用，必须转向基于命令行界面（CLI）的终端操作。在部署文件夹中，开发者需要整合引擎、客户服务工具以及技能模块等所有必要组件。生产环境部署的核心在于使用 AWS CLI 通过终端执行少量命令，将 Agent 代码发送至 AWS Runtime。这一过程由 Agent Core 自动处理容器化部署，开发者无需手动管理底层基础设施。同时，系统会自动配置内存管理机制，即使不使用特定的框架（如 LangChain），仅通过代码层面的 n get called memory 也能实现记忆存储，从而简化了架构复杂度。

MPT Entry Point：连接本地与生产的关键入口

在构建 GenAI 应用并准备将代码放入 Core Runtime 时，唯一需要修改的关键点是添加 MPT Entry Point（入口点）。这是本地笔记本环境与生产环境之间的唯一区别。MPT 入口点是 Runtime 识别 Agent 边界的标志，Runtime 能够看到 MPT Entry Point，而该入口点之后的所有代码逻辑均被视为 Agent 的一部分。每次调用 Runtime 时，容器都会执行 MPT Entry Point 之后的代码。这一机制确保了 Agent 在云端运行时逻辑的完整性和一致性，使得开发者可以专注于业务逻辑而非环境适配。

启用内置可观测性与本地调试配置

为了实现内置的可观测性（Observability），开发者必须在 AWS Console 中进行特定配置。首先，进入 Agent Core 服务页面，找到 Configure（配置） 选项并启用 Transaction Search。这一设置至关重要，因为它允许 CloudWatch 接收 Agent 的运行信息；若未启用，将无法在运行时看到 Agentic Observability。其次，需要在 requirements 文件中安装 AWS OpenTelemetry Distri库（或对应框架如 LangChain/CrewAI 的专用库）。对于 Amazon Bedrock，由于 Agent Core 内置支持，无需额外修改代码即可实现可观测性；但使用其他框架时需遵循文档进行微调。本地调试时，开发者可使用 agentcore dev 命令在虚拟环境中测试 Agent，通过查看 Token 用量和会话状态来探索内部运行机制。

使用 Bring Your Own Code (BYOC) 部署流程

在实际部署操作中，开发者选择 Bring Your Own Code（自带代码） 模式而非直接创建新 Agent。通过 CLI 命令 agentcore add，系统会自动创建所需的容器环境文件夹。部署流程包括选择直接代码部署或容器部署，并指定模型提供商（如 Amazon Bedrock）。随后，将本地代码复制粘贴至创建的容器中。执行 agentcore deploy 命令后，Agent 即被部署到生产环境。整个过程在 Amazon Bedrock Workshop 环境中无需额外配置 AWS 凭证，因为该虚拟环境已预置权限。开发者可以在本地使用 agentcore dev 验证相同代码在本地环境下的表现，确保 Agent Core Runtime 部署前后的行为完全一致。

AWS Core Agent 的零配置基础设施自动化

在 AWS 环境中构建应用时，开发者通常需要处理繁琐的基础设施权限管理。传统流程要求手动创建 IAM 角色、定义策略权限，并配置服务间的连接规则，这一过程往往耗时且容易出错。然而，AWS Core Agent 展示了其核心优势：它接管了所有底层基础设施的创建与配置工作。用户无需关心具体的权限策略或连接细节，Agent 会自动处理这些复杂环节。这种自动化不仅简化了开发流程，还确保了部署的安全性与合规性。

"If you are familiar with AWS when you build everything inside AWS you need to create the am you need to create policy permissions... Core is handle everything for me."

这一机制极大地降低了使用门槛，使得开发者可以将精力集中在业务逻辑而非基础设施运维上。通过抽象掉复杂的权限配置步骤，Core Agent 实现了真正的“即插即用”体验。

CDK 代码生成与 CloudFormation 栈管理

Core Agent 在后台利用 Cloud Development Kit (CDK) 生成基础设施即代码（IaC）。对于不熟悉 CDK 的用户，可以将其理解为一种通过编程语言定义云资源的方式。开发者可以使用自己熟悉的语言（如 Python 或 TypeScript）来描述基础设施，而 Core Agent 会自动将这些代码转化为具体的 AWS CloudFormation 栈。

在演示中，可以看到 Agent 自动创建部署所需的各项资源，并在 AWS 控制台的 CloudFormation 服务中生成对应的栈。尽管在本地验证阶段可能因账户类型限制无法立即看到完整状态，但一旦部署进入运行时环境，这些基础设施资源便会清晰呈现。这种基于代码的基础设施管理方式不仅提高了可重复性，还便于版本控制和团队协作。

运行时验证与 SDK 调用测试

部署完成后，核心环节是对生成的 Agent 进行实际运行验证。演示者通过 Amazon Bedrock Runtime 接口直接调用该 Agent，以确认其功能正常。这一过程展示了从代码生成到实际服务可用的完整闭环。

为了验证 Agent 是否正常工作，开发者可以使用提供的 SDK（如 Bedrock Runtime）进行调用测试。演示中明确提到："It is invoking the agent." 并确认响应正确返回，证明 Agent 已成功上线并可被外部系统调用。这种即时验证能力确保了部署的可靠性，让开发者能够迅速确认服务状态。

可观测性仪表盘与社区资源分享

除了功能验证，AWS Bedrock Runtime 提供了内置的可观测性仪表盘（Observability Dashboard）。该仪表盘允许开发者监控 Agent 的运行状态，包括会话数量、追踪信息以及每个运行时容器（Runtime Container）的具体表现。由于 Agent 的启动和初始化可能需要 1-2 分钟，开发者需耐心等待数据在仪表盘中更新。

"You can go to the runtime. In here you have the observability dashboard and you can see the session the trace how many runtime that you running."

演示最后，演讲者分享了包括幻灯片、Workshop 链接及社区资源在内的全套学习资料。通过 QR 码，观众可以访问 LinkedIn、Twitter 和 Instagram 等社交平台获取更多关于 Core Agent 的信息。这种开放的资源分享策略旨在帮助更多开发者快速上手并深入理解该工具。

结论

Strands Agents结合Amazon Bedrock Agent Core，构建了一套从开发到生产的全链路智能体解决方案。其核心优势在于“Bring Your Own LLM”的开放性、内置的记忆架构与可观测性，以及通过Hooks和Skills实现的确定性控制。Agent Core自动化了基础设施配置（如IAM权限），显著降低了部署门槛，并承诺数据隐私。然而，该系统仍面临LLM概率性带来的不确定性挑战，需依赖Hooks进行速率限制和逻辑拦截以保障稳定。此外，生产环境迁移要求开发者理解MPT Entry Point机制及CLI操作规范。总体而言，该方案适合追求端到端可控性、需快速集成多模型并具备一定工程化能力的开发者，但在复杂场景下的自动化程度仍需结合具体代码逻辑验证。