从工作流定义到模型驱动的范式转移

AWS Strands 框架的核心哲学在于“模型驱动方法”（Model-Driven Approach），即通过委托编排任务给大语言模型本身来构建智能体。这一理念源于 AWS 内部在开发 Q Developer、Kero 等产品时的实际需求，旨在解决传统 AI 工作流中难以定义的图结构（Graphs）和脆弱性导致的扩展性问题。与需要手动定义每一步骤的传统工作流不同，Strands 允许开发者提供足够的上下文和工具，让模型自主迭代解决问题。这种架构的优势在于其可扩展性（Scalability）：随着底层模型能力的加速提升，基于该框架的智能体工作流无需修改代码即可自动获益。正如嘉宾 Morgan Willis 所指出的，开发者需要经历从“定义每一步”到“给予上下文并让模型自主工作”的思维转变，这是理解 Strands 如何工作的关键。这种模式正逐渐成为行业标准，因为使用更新的模型即可提升整体效果，而无需重构底层逻辑。

Strands 的演进：从 SDK 到完整的产品组合

自去年以开源项目形式发布以来，Strands 已经从一个简单的智能体循环 SDK（Agent Loop SDK）演变为一个丰富的产品组合。Aaron 将其现状概括为：“Strands today is a portfolio of offerings”，涵盖了帮助开发者安全地包含和运行智能体的多种工具。这一演进反映了行业对效率（Efficiency）和安全性（Safety）的关注升级。早期 Strands 主要解决如何构建智能体的问题，而现在则侧重于如何在赋予模型自主权的同时，确保其在受控环境中高效运行。这种转变使得 Strands 不再仅仅是一个开发库，而是成为了一套完整的智能体基础设施（Agent Infrastructure）。嘉宾提到，Strands 团队在过去一个月中引入了大量创新，特别是针对状态管理（State Management）和错误处理机制的优化。这种从单一功能到全栈支持的转变，使得 Strands 能够应对更复杂的商业场景，如 DevOps 自动化和安全性检查等内部高要求任务。

护栏与自主性的平衡：减少过度工程化

在 Strands 的演进中，一个显著的趋势是对确定性护栏（Deterministic Guardrails）的需求与模型能力提升之间的动态平衡。过去，由于智能体行为不可预测，开发者不得不构建复杂的状态机（State Machines）和大量的规则来约束其行为。然而，随着 Opus 等前沿模型能力的提升，许多开发者开始意识到“不再需要为编辑或其他模型设置过多的护栏”。这种观点的转变意味着，当基础模型足够强大时，过度工程化的控制逻辑反而成为负担。Strands 通过提供最先进的智能体护栏（State-of-the-art Harness Agents），允许开发者在保持模型自主性的同时，通过更少的代码实现更安全的行为控制。嘉宾 Aaron 强调，Strands 的设计初衷就是“委托编排给模型”，但随着框架成熟，它提供了更多杠杆供客户调整智能体的运行方式。这种“模型驱动 + 适度护栏”的组合，既保留了 AI 的灵活性，又满足了企业级应用对稳定性和安全性的严格要求。

智能体循环与安全护栏：从YOLO到确定性控制

随着大模型能力的提升，开发者逐渐让模型自主决定调用哪个子智能体（sub-agent），但这并不意味着可以毫无约束地运行。演讲者强调，这并非“YOLO”（随意行事）模式，必须在模型调用和智能体循环中建立确定性的安全护栏。亚马逊团队近期的一项创新是将这种智能体循环与神经符号AI（neural symbolic AI）相结合。具体而言，在每一次智能体的执行周期中，系统会将其行为与特定的策略（如Dogwood政策引擎）进行验证。这种机制确保了智能体在采取行动前，必须通过预定义的规则检查。

以客服场景为例，当智能体提出“向用户退款100美元”的请求时，系统会立即启动策略验证流程。这些验证包括：用户是否在最近24小时内下单、如果是游戏退款则检查游玩时间是否少于2小时，以及用户的信任评分（trust score）是否达标。如果验证通过，操作继续；若失败，模型会收到具体的拒绝原因，并据此向用户反馈或寻找替代方案（如转交人工客服审核）。这种确定性护栏正是区分普通“智能体”与完整“Harness（框架/驾驭器）”的关键所在，它解决了单纯依赖模型自主性带来的不可控风险。

工程范式的演变：从Prompt到Harness Engineering

AI Agent的开发范式正在经历快速迭代，反映了该领域学习最佳实践的速度。演讲者指出，行业术语从最初的Prompt Engineering（提示词工程）演变为AI Engineering、Loop Engineering、Graph Engineering，直至如今的Harness Engineering（框架工程）。这一演变直接体现在Strands产品的演进中：早期仅提供一个基础的SDK，允许开发者创建简单的循环并添加工具；而现在，Strands推出了Harness SDK，提供从底层构建完整框架所需的所有组件。

近期发布的Strands Harness是一个预优化的、开箱即用的解决方案。其核心卖点在于，开发者仅需几行代码即可拥有一个具备完整记忆（memory）和上下文管理（context management）能力的智能体。正如演讲者所言：

“我们不再只是谈论一个简单的循环，而是通过Harness SDK提供所有不同的部分来从头创建框架。”

这种转变标志着行业标准的提升。12到18个月前，智能体循环（agent loop）和工具调用还是令人兴奋的新特性；如今，这已成为“基础门槛”（table stakes）。任何缺乏此功能的智能体都不再被视为前沿产品。Strands团队在与Amazon Q、Cairo及AWS Frontier Agents等内部产品的合作中，观察到客户面临相同的挑战：仅靠循环不足以维持状态的最新性（state of the state），因此需要更丰富的功能集。

Harness的核心组件：默认工具与智能上下文管理

Strands Harness不仅是一个框架，还内置了一套经过基准测试的默认工具集。这些工具的选择主要基于客户反馈和内部经验。对于通用型智能体（如能编写代码、访问文件、检索互联网信息的Agent），以下工具通常足以覆盖广泛用例： 1. 文件操作（File operations） 2. Web搜索工具 3. 程序化工具调用能力（Call tools programmatically）

除了工具，Harness还解决了上下文窗口限制这一关键痛点。传统的做法是不断向上下文追加内容，但这会导致信息过载和模型偏离轨道。Strands Harness采用了即时组装（just-in-time assembly）的高级上下文管理技术：它不会无限制地堆积历史，而是从多个智能体或人类用户写入的上下文日志中，动态提取并重组最关键的信息片段。这种机制确保了模型始终拥有最高效、最相关的上下文输入，从而提升性能。

演讲者Aaron进一步解释：

“Harness建立在SDK的构建块之上，它是这些构建块的 opiniated（有观点/预设）配置。我们对其进行了基准测试并公布了结果。”

这意味着，虽然Harness提供了预设的最佳实践配置（包括默认工具和上下文策略），但它完全兼容SDK的灵活性。开发者可以在此基础上添加自定义工具，同时利用Harness提供的内存管理、策略验证和基准性能优化。这种设计既降低了入门门槛，又保留了深度定制的空间，体现了从“构建循环”到“驾驭智能体生命周期”的工程化成熟度。

工具调用的通用价值与安全隔离

在构建 AI Agent（智能体）时，除了编码类任务，工具调用能力是支撑复杂业务场景的核心。以客户服务智能体为例，其核心价值在于能够在受控、安全且隔离的环境中读写文件。这种能力不仅确保了数据隐私，还允许智能体将信息以“文件”形式进行引用和存储。

更重要的是，长期记忆机制依赖于这种文件系统。当同一用户一个月后再次访问时，智能体能够从历史文件中检索相关信息，实现连续性的服务体验。此外，通过程序化工具调用（Programmatic Tool Calling），智能体可以将多个工具组合成脚本并执行。这种方式显著减少了 Token 的使用量，从而降低了运营成本。Strands 框架遵循开源理念，所有组件均经过预配置和基准测试，但同时也允许用户完全自定义：启用、禁用或添加专属工具。例如，在特定情况下支持将任务升级（Escalate）给人类操作员处理。

Harness 工程学的定义与架构组成

随着行业对 Agent 概念的深入，Harness Engineering（智能体框架工程）成为关键术语。对于“什么是 Harness”，业界存在多种定义，但核心共识可以概括为：Agent 由模型（Model）和 Harness 两部分组成。Harness 是围绕大语言模型构建的软件系统，它将静态的模型转化为可运行的智能体。

具体而言，Harness 承担了以下关键职责： 1. 处理模型调用与工具请求：例如执行“提交退款”等具体操作。 2. 上下文管理（Context Management）：实现智能的、即时组装的上下文信息，优化输入效率。 3. 注入 Hooks（钩子）：在模型调用与工具执行之间，或任务结束时插入验证检查、自动化推理等逻辑。 4. 记忆与审批机制：支持长期记忆的存储，并允许将结果发送给人类操作员审核。在更自主的场景中，甚至可以使用次要模型（Secondary Model）作为裁判来审查变更。

“An agent is two things. It's the model and it's the harness.”

术语的演进与行业标准化趋势

尽管“Harness”一词在一年前并不常见，但当前的 Harness 功能已比 12-18 个月前大幅增强。早期简单的 Agent Loop（智能体循环）和工具调用本质上就是 Harness，只是当时缺乏统一的术语。如今，高性能的 Harness 已成为获取 SOTA（最先进）结果的标配。行业倾向于保持定义的适度宽松，因为技术迭代极快，过于僵化的定义可能阻碍创新。这种模糊性设计旨在提供共享词汇的同时，避免过度规定具体组件。

“The harness is the software system that sits around the model that turns it into a running agent.”

Strands Harness 的技术实现与多语言支持

Strands Agent SDK 现已升级为 Strands Harness SDK，并在其之上构建了抽象层。该框架支持多种交互方式： * 编程接口：提供 Python 和 TypeScript 两种语言的 Fluent API，开发者可直接通过代码构建和定制智能体。 * CLI 工具：新推出的 Strands CLI 允许用户快速创建和交互智能体。 * YAML 配置：通过 YAML 文件形式提供声明式配置，简化部署流程。

这种架构不仅封装了 Amazon 和 AWS 工程师的最佳实践，还允许用户针对特定领域（如物理 AI、机器人控制）进行专业化定制。通过优化上下文组装和工具组合，Strands Harness 在Token 效率提升方面表现优异。无论是使用预构建的 Harness 还是自定义开发，开发者都能获得经过基准测试的高性能基础。

“Strands is configurable. If you prefer something more autonomous, you can even have the agent do that itself or a secondary model call to kind of act as a judge and review the change before it incorporates it.”

Strands Harness 的多接口设计与核心优势

Strands Agent Config 功能支持将配置定义为文件并加载，但其核心价值在于提供了 Python、TypeScript 和 CLI 三种程序化接口。这种多语言支持使得开发者可以将 Harness 嵌入到应用程序中作为库使用，仅需一行代码即可获取包含预建默认值的完整代理框架。同时，CLI 接口提供了与编程界面相同的功能体验，只是交互方式不同。

这种设计极大地简化了开发流程。开发者无需手动定义和配置代理所需的基础模块，如对话历史、会话管理、上下文管理和基础工具。通过 CLI 或代码嵌入，开发者可以快速启动代理原型。正如讨论中提到的：“你可以将其嵌入你的应用程序……只需一行代码，就能拥有这个具有所有预建默认值的 Harness。”这种灵活性允许开发者根据需求选择是进行命令行原型开发，还是将其集成到自定义应用中。

CLI 在开发与 CI/CD 中的具体应用

对于开发者而言，CLI 不仅是入门工具，更是开发、测试和集成工作流中的重要环节。通过 NPM 安装 Strands CLI 后，开发者可以通过简单的命令和终端 UI（支持交互模式）快速启动代理并进行对话测试。这种即时反馈机制极大地加速了原型验证过程。

此外，CLI 与 CI/CD（持续集成/持续部署） 系统有着良好的兼容性。开发者可以直接通过 Strands CLI 运行代理测试，甚至无需编写任何代码即可将其集成到 GitHub Actions 等流程中。这种非侵入式的集成方式使得代理的自动化测试和部署变得异常简便。讨论中指出：“CLI 对开发、入门非常有用……我能够相当容易地将其集成到 CI/CD 中。”对于需要更深层次集成的生产环境，则可以使用 Python 或 TypeScript SDK 进行后端进程集成。

Skills 支持与从原型到生产的无缝过渡

Strands Harness 的另一个关键特性是其对 Skills（技能） 的支持，这进一步增强了其在事件驱动架构中的适用性。开发者可以将 Skills 放入支持的目录中，快速构建能够响应特定事件的代理。这种机制使得代理可以轻松接入现有业务流程。

更重要的是，Strands Harness 并非仅限于原型开发。由于其底层基于 Strands Agents SDK，开发者可以覆盖任何内置元素，从而实现从原型到生产环境的平滑过渡。这种架构既保证了快速启动的能力，又避免了功能限制。讨论强调：“Strands Harness 一般是从原型到生产都可以使用的……你可以覆盖其中的任何元素。”目前，AWS Agent Core Harness 内部正是基于 Strands Harness 构建的，证明了其在生产环境中的成熟度。

Agent Core Harness：AWS 托管的生产级服务

Agent Core Harness 是 AWS 提供的一套托管代理基础设施和服务套件，它建立在 Strands Agents SDK 之上。与开源的 Strands Harness 不同，Agent Core Harness 提供了完整的托管体验，包括代理运行时、特定计算资源、可观测性（如 OpenTelemetry 追踪）、记忆功能和代码解释器等。

开发者可以通过 AWS Console Playground 或 Agent Core CLI 进行实验和配置。通过简单的 API 调用，开发者可以指定要加载的工具、启用或禁用记忆功能以及设置提示词。AWS 负责处理无限扩展和吞吐量管理。讨论中解释道：“代理核心 Harness 是 Strands Harness 的托管版本……你只需调用 API，AWS 为你管理所有无限扩展。”这种服务模式让开发者能够专注于代理逻辑本身，而无需关心底层基础设施的运维。

配置导出与迭代工作流

在 CLI 交互过程中，开发者可以通过特定命令将当前的代理配置导出为代码。例如，使用 /export 命令可以将 CLI 中构建的代理配置转换为可部署的代码片段。这使得开发者可以在交互式环境中快速迭代，然后将最终结果导出并部署到生产环境或本地运行。

这种工作流结合了快速原型设计和工程化落地的优势。开发者可以在终端中通过命令查看可用选项，并通过导出功能将配置转化为 Python 或 TypeScript 代码。讨论中提到：“有一个 export 命令……它会将你在 CLI 中构建的内容导出为代码。”这种机制确保了从探索性开发到正式部署的无缝衔接，同时保留了配置的灵活性和可移植性。

基准测试中的Token效率优势

在评估AI代理性能时，Strands Harness展现出了显著的成本效益。通过与Claude Code和Codex等主流工具的对比测试，研究团队发现Strands Harness在六个涵盖编码、游戏解谜及物理AI任务的标准化基准测试中，效率提升了34%。这一数据是在使用相同底层模型（如Claude或GPT）的前提下得出的，证明了代理的性能不仅取决于模型本身，更受到运行框架（Harness）的巨大影响。即使更换相同的模型，仅改变底层架构也能在准确率、执行速度和成本上产生截然不同的结果。这种效率提升并非偶然，而是源于对上下文工程（Context Engineering）的深度优化。

工具卸载与渐进式披露机制

Strands Harness提升Token效率的核心在于其工具结果（Tool Results）的管理策略。当代理在解决问题时，会频繁调用API、运行代码或读取本地文件，这些操作产生的上下文如果全部保留在模型窗口中，会导致Token消耗激增且包含大量无关信息。为此，Strands Harness采用了工具卸载（Tool Offloading）技术：它不会将所有工具结果保留在上下文中，而是激进地截断并存储这些信息到外部文件。同时，系统会生成一个预览摘要供模型参考。这种机制类似于渐进式披露（Progressive Disclosure），即当代理需要更详细信息时，再按需从文件中检索。这一策略大幅减少了上下文窗口的占用，从而显著提升了Token使用效率。

自动化压缩与自定义策略

除了工具卸载，Strands Harness还具备后台自动压缩（Compaction）功能。系统会利用一个模型在后台分析当前上下文，生成摘要或压缩后的分析报告，以进一步节省Token。虽然系统提供了针对通用场景优化的默认设置，但用户拥有高度的自定义权限。开发者可以关闭不必要的工具（例如仅保留基础的5-6个核心工具），从而减少模型的关注点，提升准确率并降低成本。此外，用户还可以覆盖默认的压缩模型和指令，针对特定用例进行微调。这种灵活性使得代理能够在保持高效的同时，适应各种复杂的业务需求。

Strands Box与Dogwood策略引擎

为了解决代理的安全性和沙盒隔离问题，团队推出了Strands Box预览版。这是一个独立的容器层，用于限制代理的文件系统和网络访问权限。其核心策略引擎是开源的Dogwood，基于Amazon AWS的Cedar构建。与传统的静态沙盒不同，Dogwood引入了时间维度（Temporal Layer），能够分析历史事件序列。例如，在处理退款请求时，策略可以验证用户是否先完成了下单等前置步骤。Dogwood提供确定性保证：一旦编写了策略，系统就强制其执行。此外，它支持丰富的语义规则，如限制代理每10分钟只能向Slack发送一次更新，防止信息轰炸。这种结合文件系统/网络限制与时间序列语义策略的机制，为AI代理提供了更精细、更安全的行为控制。

进程级沙箱与微虚拟机（Micro VM）的技术定位

在讨论 Agent 安全时，常有人混淆 Strands Box 与其他沙箱方案（如 Lambda Micro VMs 或 Agent Core Runtime）的区别。Strands Box 采用进程级沙箱（Process Sandbox）架构，将 Agent 封装在单个进程中运行。这与基于微虚拟机（Micro VMs）的方案形成对比，后者为每个 Agent 会话启动一个独立的轻量级虚拟机实例。

"Strands box is another approach there, where it's a process sandbox... It encapsulates your agent within that process."

进程级沙箱的优势在于其极低的资源开销和高密度部署能力。相比微虚拟机，它没有虚拟化层的额外负担，允许在单台机器上运行更多 Agent 实例。然而，这也意味着其可信计算基（Trusted Compute Base, TCB）更大，边界攻击面相对更广。Strands Box 通过整合 Amazon AWS 的工程最佳实践和经验教训，弥补了这一潜在风险。对于需要极高密度和快速启动的场景，进程级沙箱是更优选择；而对于极端隔离需求，微虚拟机方案则更为合适。

多层级沙箱技术的协同防御架构

在构建AI Agent运行时，单一的安全隔离手段往往不足以应对复杂威胁。业界存在多种沙箱选项，包括独立的计算节点、微虚拟机（Micro VM）以及进程级隔离。Strands Box 提供的是操作系统层面的容器化保护，它并非孤立存在，而是可以与其他技术栈组合使用。 这种设计理念强调技术的互补性而非竞争性。例如，当Agent被赋予执行Shell命令、访问互联网以及读写代码的权限时，若其核心运行时直接部署在宿主机上，它将拥有对宿主环境乃至自身源代码的完全访问权。这种高权限状态极易引发安全风险，因为Agent可能绕过IAM凭证管理等安全机制。

为了构建更严密的防线，采用“微虚拟机+操作系统级隔离”的双重边界策略成为关键。 在这种架构中，微虚拟机构成了最外层的物理或虚拟化隔离屏障，而Strands Box则在其内部进一步划分出严格的文件和网络边界。这种分层设计允许开发者在受限环境中运行代码，同时通过Dogwood策略精确控制Agent可执行的动作。正如演讲者所言：“这些是互补的技术，而不是相互竞争的关系。” 通过这种组合拳，开发者既能利用微虚拟机的强隔离性，又能借助Strands Box实现细粒度的资源访问控制。

"So, it's like right, Strands box is operating system level containment, and you can combine that with these other approaches as well."

案例解析：月球着陆模拟中的防作弊隔离机制

在re:Invent大会的工作坊中，展示了一个极具代表性的应用场景：一个基于Strands Harness构建的AI Agent负责训练并编写策略，以模拟月球着陆器安全降落。该案例的核心挑战在于如何确保评估脚本的公正性，防止Agent通过读取评分标准来“作弊”或操纵结果。 评估逻辑被编写为一个算法脚本，定义了着陆器必须以特定角度、低速触地并关闭引擎才算成功。如果Agent直接访问该脚本，它可能会利用代码逻辑漏洞来伪造着陆数据。

为解决这一问题，演讲者引入了Strands Box进行严格的隔离。 首先，Agent被限制无法读取存储在GitHub上的评估脚本或本地副本中的评分代码。其次，网络访问权限也被严格管控：Agent虽然可以搜索互联网和访问特定网页，但被禁止访问GitHub以及本地评估脚本所在的目录。 这种设计将环境划分为两个独立的切片：一个是Agent运行的区域，另一个是隔离的评估执行区。这种精细化的权限控制确保了即使Agent拥有极高的智能和代码生成能力，也无法突破安全边界去获取评估依据。

"I don't want my agent to just read that script, right? Because it will cheat. It will game the results and cheat."

Strands Decider：轻量级System 1模型的应用价值

除了安全隔离，AWS还发布了Strands Decider，这是一种基于System 1架构的超轻量级决策模型。与传统的重型大语言模型不同，Strands Decider旨在快速做出概率性决策，其参数量范围从20亿到200多亿不等。 这些模型支持多种后端，包括Gwen和Gemma系列，并可根据需求部署在GPU或CPU上。随着参数规模的增加，模型的决策能力随之提升，但相应的计算资源需求也相应增长。 这种灵活性使得开发者可以根据成本效益和性能要求选择合适的模型大小。

在典型应用场景中，如客服代理处理退款请求时，Strands Decider可以接收对话上下文和预定义的选项（如“批准退款”、“转人工客服”或“拒绝退款”），并输出每个选项的概率值（0到1之间）。开发者可以直接选取概率最高的动作执行，或者结合其他逻辑进行干预。 这种机制特别适用于需要高频采样且对延迟敏感的场景。例如，在安全诊断中，Agent可以每分钟进行一次低成本的决策采样，判断是否需要升级警报，从而避免频繁调用昂贵的大型模型。这种模块化设计允许将Decider作为“干预”或“引导”机制无缝嵌入现有Agent工作流，无需重写核心代码。

"Strands Decider... is a super lightweight, very small... it makes decisions very quickly."

成本优化与新兴应用趋势

引入Strands Decider等轻量级模型不仅提升了安全性，还带来了显著的成本效益。在处理分类或简单决策任务时，使用前沿的大型语言模型会消耗大量Token，而轻量级模型则能大幅降低这一开销。 这种效率提升在需要实时或高频决策的场景中尤为关键。近期，社区中出现了一种新的应用模式：创建一个能够接收诊断信息并决定是否需要升级处理的Agent。通过每分钟进行一次低成本的采样决策，而非每次都调用全功能LLM，企业能够以极低的成本实现高效的安全监控。

Strands框架的设计哲学强调组合性与灵活性，使得新技术如Decider能够轻松接入现有系统。 这种架构不仅解决了Token效率问题，还为Agent引入了更稳健的决策层。通过将System 1的快速直觉判断与System 2的深度推理相结合，开发者可以构建出既安全又经济的AI Agent系统。这种趋势表明，未来的Agent架构将更加注重模块化组件的协同工作，而非依赖单一的强大模型。

"That flexibility and that composability really goes a long way whenever new technologies like this come out."

Strands Decider：全开源的决策模型与评估集成

Strands Decided 是一个完全开放的“Decider”（决策者）模型，其配方、权重以及用于训练的数据均公开可用。这种开放性允许用户下载并根据特定用例进行定制和微调，从而为开发者带来显著价值。Strands 不仅仅是一个 SDK，它包含 Harness、Box、Decider 以及 Evals（评估）包。其中，Evals 包旨在解决构建 Agent 后如何确保其可靠性的问题。System 1 模型在 Evals 中被用作替代传统 LLM Judge，这不仅能大幅降低评估成本（取决于测试用例数量和所选模型），在某些情况下甚至能提高准确性。此外，Strands Evals 还具备合成数据生成功能，帮助用户生成微调所需的数据。开发者可以利用这些数据轻松调整 Strands Decider 以适应最终用途。

System 1 模型在游戏与机器人控制中的低延迟优势

System 1 模型因其体积小、速度快，在需要毫秒级响应的场景中表现优异。与 LLM 不同，System 1 模型只需一次前向传播即可得出结论，而非多次迭代。这种特性使其非常适合实时控制任务，如机器人导航（前进、左转等）。视频中展示了利用 System 1 模型和 Strands Decider 玩 Doom、Tetris、Snake 等游戏的案例，以及通过摄像头图像反馈控制机器人的实验。多模态输入（如游戏截图或机器人视觉流）与快速决策的结合，展示了该技术在实时交互领域的潜力。这种低延迟特性是传统 LLM 难以企及的，特别是在需要即时反馈的物理控制场景中。

AI 工程演进：从专用分类器到通用 System 1 模型

随着 AI 工程的演变，系统设计方式正在发生根本性变化。System 1 模型的显著优势在于其通用性。传统的分类器需要针对特定用例进行大量调优，这不仅耗费资金和精力，还要求开发者具备高超的技能。相比之下，基于 LLM（如 Gwen 或 Gemma）构建的 System Decider 具有更强的可泛化性，无需强制微调即可使用（尽管完全开源允许用户选择是否微调）。这种通用性降低了技术门槛，使得开发者能够更灵活地应对不同场景。视频中提到的“HBO Silicon Valley 热狗/非热狗”分类案例，以及更复杂的多模态追踪任务，都证明了这种通用模型在处理多样化问题时的有效性。

智能路由与双向流式语音 Agent：实时交互的新范式

Strands Harness SDK 提供了模型路由器功能，允许开发者自定义智能体使用的后端（如 GPT、Claude 或开源模型），并集成 LLM 或 System 1 模型进行智能路由决策。双向流式语音支持已从实验阶段转为 GA（一般可用），允许用户与 Agent 进行实时对话。这种技术并非简单的语音转文本，而是直接将音频流传输给模型。保留语调、情感和停顿等细微差别是语音交互相比文本交互的核心优势，这些情感信息在纯文本转换中往往丢失。目前支持的提供商包括 Amazon 新发布的 NovaSonic 2.5、GPT Live/Real-time 模型以及 Gemini Voice 模型，为开发者提供了丰富的选择以构建更具自然感的语音 Agent。

双向流式传输重塑语音交互体验

Strands 发布的双向流式支持（bidirectional streaming support）为构建语音 Agent 提供了极易使用的接口，其核心优势在于大幅降低了交互延迟。传统语音模型常因响应缓慢而成为痛点，但双向流式架构允许用户声音实时传入模型，并在说话停止后立即开始响应。这种低延迟特性使得语音 Agent 的互动感显著提升。

"That architecture makes it way more responsive."

演讲者分享了一个极具代表性的实验案例：他在夏季将 Amazon Nova Sonic 模型接入 Bedrock，通过 Raspberry Pi 控制一个名为 "Big Mouth Billy Bass" 的玩具鱼。该 Agent 被赋予了访问日历和读取网页的工具，能够实时播报新闻。低延迟使得原本机械的问答变成了真正的对话，消除了传统语音交互中常见的 10 秒滞后感。这一模式不仅适用于娱乐场景，同样可应用于客户服务等需要高实时性的语音 Agent 开发中。

SDK GA 版本解决回声与中断难题

随着双向流式传输功能从实验模式进入通用可用（GA）阶段，SDK 内置了多项关键优化，解决了早期开发中的棘手问题。在硬件麦克风与扬声器同处一室（如玩具鱼或机器人）的场景下，设备容易听到自己的声音并产生自我中断的混乱。Echo suppression（回声抑制）功能现在由 SDK 原生支持，避免了开发者自行处理复杂的音频反馈问题。

"It lets you interrupt... if it can hear itself, then it will interrupt itself. And so it gets really confused."

在实验阶段，语音模型允许用户打断 Agent 的发言以实现纠错，但若设备能听到自身回放声音，Agent 会误判为新的用户指令从而陷入自我中断的循环。GA 版本的 SDK 通过内置最佳实践清理了这些逻辑冲突，使得开发者无需重复造轮子即可实现稳定的语音交互。这种框架层面的封装确保了 Agent 在复杂声学环境下的鲁棒性，为后续更复杂的硬件集成奠定了基础。

机器人交互与 Agent 工具调用能力

在 re:Invent 大会上，Strands 展示了该技术在人形机器人上的应用。语音模型不仅作为机器人的"声音大脑"，还能理解用户的情绪、停顿及中断意图。机器人通过麦克风与扬声器紧密相邻的硬件布局，利用回声抑制实现了实时互动。

"The voice model is able to also... make tool calls. Right? So then it can control the robot, right?"

语音 Agent 具备与其他 LLM Agent 相同的工具调用能力，能够直接控制机器人执行物理动作（如跳舞、握手）或进行网络信息检索并口头反馈。这种语音与物理控制的深度融合展示了 Agent 在具身智能领域的潜力，使得机器人不仅能"说"，还能通过语音指令驱动复杂的肢体行为和外部工具调用。

Strands 品牌演进与安全控制愿景

Strands 的品牌形象从最初的 DNA 双螺旋标志演变为现在的青蛙吉祥物，象征着其技术栈从一个简单的"模型+工具"组合进化为一个完整的、有生命的有机体。这一演变反映了 Strands 在过去 18 个月中从 Q Developer、Kiro 等产品后端技术积累，到推出 Strands Harness、Decider 模型及 Evo SDK 的完整产品矩阵。

"We want to make sure that it happens safely."

当前，Strands 的研发重点聚焦于Agent 的控制与安全。通过与 Dogged、Strands Box 以及 Amazon 自动推理组的合作，团队致力于在神经符号推理（neuro-symbolic reasoning）基础上增强对强大 Agent 的安全约束。目标是在不削弱 Agent 效能的前提下，确保其在受控环境中运行。递归自我改进（recursive self-improvement）作为当前热点话题，也是 Strands 在 Agent Harness 层面持续探索的方向之一。

Agent自主进化与安全控制成为核心焦点

随着大语言模型能力的提升，AI Agent不再仅仅是静态的工具调用者，而是具备了自我进化的潜力。Agent技术的最新进展体现在其能够动态调整自身行为，例如修改自身的提示词（Prompts），甚至在运行时生成新的工具供自己使用。这种动态创建并执行新工具的能力，使得Agent能够处理更复杂的任务场景。生成形式化证明（Lean proofs）和代码验证是其中的典型应用，即Agent在生成代码的同时，自动生成对该代码属性进行形式化验证的逻辑。然而，这种强大的自主性也带来了严峻的安全挑战。Agent安全与控制（Safety and Control）因此成为当前研发的重点领域，特别是在面对具备高度自主性的Agent时，如何确保其行为符合预期且安全可控，是业界关注的热点话题。

生产环境中的Agent实践与社区生态

对于曾经关注过Strands项目但后来未再跟进的开发者，现在的技术栈已经发生了显著变化。AWS工程师基于服务数百万客户的最佳实践，构建了一套强大的生产级Agent工具集。这些工具旨在帮助开发者在真实的生产环境中可靠地运行AI Agent。为了促进技术交流和协作，AWS建立了活跃的社区生态。Strands Discord服务器链接在官方网站上提供，聚集了大量开发者、贡献者和思想领袖。大家在此分享想法、讨论技术难题并共同推进项目发展。访问官方网站了解产品组合，或通过社交媒体联系团队，是获取最新进展和参与社区互动的有效途径。这种从理论到生产落地的闭环，使得Agent技术不再局限于实验阶段。

行业洞察：从底层原理到物理世界的延伸

在技术快速迭代的背景下，回顾基础与探索前沿同样重要。一位专家推荐了最新发布的《Google SRE Book》第二版，该书深入探讨了如何利用生成式AI提升工程师和运维人员的效率，以及如何从系统层面可靠地大规模运行生成式AI。另一位专家则推荐了经典著作《Code: The Hidden Language of Computer Hardware and Software》。这本书从摩尔斯电码讲起，层层剖析计算机硬件与软件的底层逻辑。在AI日益抽象化底层的今天，重温这些基础原理有助于理解技术的演进脉络。

在工具选择上，两位专家均提到了对Agent的高度依赖。其中，Kiro Crew作为一个基于CLI构建的Harness工具备受青睐。它支持远程连接、云端任务执行以及多个Agent实例的链式调用，极大地提升了开发效率。展望未来，物理AI（Physical AI）和形式化验证是两大深入方向。将LLM技术安全地应用于物理世界，需要解决与现实环境不同的约束条件；而通过Agent辅助学习神经符号AI（Neuro-symbolic AI）和形式化验证，则是弥补传统计算机科学教育中相关领域不足的有效手段。

结论

Strands Harness通过模型驱动范式与确定性安全护栏的结合，解决了AI Agent在扩展性、安全性和成本效率上的核心痛点。基准测试证实其Token效率较主流工具提升34%，这得益于即时上下文组装、渐进式披露及后台压缩等工程优化。Strands Box与Dogwood引擎提供了进程级隔离和时间序列语义验证，确保复杂业务逻辑下的行为合规。Strands Decider引入轻量级System 1模型，在降低延迟与成本的同时支持实时语音交互及具身智能控制。该框架已从原型工具演进为涵盖SDK、托管服务及安全沙箱的完整基础设施，适用于需要高自主性且对安全与成本敏感的生产环境。