AWS 把 Agent 的控制权单独开源了：Strands Harness SDK 拆掉了 Agent 框架的最后一堵墙

GitHub Trending 深度研究 | 2026-09-23
项目: strands-agents/harness-sdk
语言: Python + TypeScript | 协议: Apache 2.0 | 今日 Stars: +96

一句话结论

Strands Harness SDK 不是又一个 Agent 框架，而是把 Agent 的"控制层"从框架里拆出来单独开源。 当所有 Agent 框架都在卷"更智能的工具调用"时，AWS 选择把"如何控制 Agent 的循环、记忆、会话、钩子"做成独立 SDK——这相当于把 Agent 从"自动驾驶模式"升级为"可接管模式"。

场景开篇：Agent 框架的"黑箱困境"

你用 LangChain 写了个 Agent，上线后效果不错。然后：

• 想改 Agent 的循环逻辑（比如加个"每 3 步检查一次预算"）→ 发现循环逻辑埋在框架深处
• 想看 Agent 每一步的中间状态 → 框架只暴露最终结果
• 想换模型提供商 → 要改一堆配置
• 想在多个会话间共享记忆 → 框架的记忆系统是黑箱
• 想加个钩子，在工具调用前做安全检查 → 没有钩子接口

最后你发现：Agent 框架帮你做了 80% 的工作，但剩下 20% 的控制权你拿不到。

Strands Harness SDK 就是来解决这个问题的。它的定位很明确：不是帮你更快写 Agent，而是让你能完全控制 Agent。

Strands 生态的两层架构

要理解 Harness SDK，先要理解 Strands 的整体设计：

┌─────────────────────────────────────┐
│  Strands Agents SDK (底层)          │
│  - 模型驱动，几行代码写 Agent        │
│  - 工具调用、记忆、上下文管理        │
│  - 2025 年 5 月发布                  │
└─────────────────────────────────────┘
              ↑ 基于底层 SDK
┌─────────────────────────────────────┐
│  Strands Harness SDK (上层)         │
│  - 控制 Agent 的循环、工具、模型      │
│  - 会话管理、记忆、钩子              │
│  - 2026 年 9 月发布                  │
└─────────────────────────────────────┘

底层 SDK 解决"怎么快速写一个 Agent"——模型驱动，几行代码搞定。

Harness SDK 解决"怎么完全控制一个 Agent"——循环、工具、模型提供商、记忆、会话、钩子，全部可接管。

AWS 宣称 Harness 比传统方案便宜 45%（来源：The New Stack，2026-09-21）。这个数字的来源不是模型更便宜，而是控制更精细 = 浪费更少。

核心概念：Harness 是什么？

"Harness"这个词在软件工程里有特定含义——测试 harness、CI harness，指的是"包裹被测系统的控制框架"。

在 Agent 语境下，Harness 指的是：

包裹 Agent 的控制层，让你能接管 Agent 运行时的每一个环节。

具体来说，Harness SDK 暴露了 6 个可控制维度：

1. The Loop（循环）

Agent 的核心是"感知-思考-行动"循环。传统框架把这个循环藏在内部，Harness 把它暴露出来：

• 自定义循环逻辑（比如"每 3 步做一次预算检查"）
• 插入中断点（比如"工具调用前暂停等人类确认"）
• 修改循环参数（最大步数、超时、重试策略）

类比：从"自动驾驶"变成"可随时接管的辅助驾驶"。Agent 可以自己跑，但你随时能踩刹车。

2. Tools（工具）

• 动态注册/注销工具
• 工具调用前/后钩子
• 工具权限控制（某些工具只对特定用户开放）

3. Model Providers（模型提供商）

• 运行时切换模型（同一 Agent 先用便宜模型跑，复杂步骤切到强模型）
• 多模型并行（不同 Agent 用不同模型）
• 自定义模型路由逻辑

4. Memory（记忆）

• 自定义记忆存储后端（Redis、PostgreSQL、文件系统）
• 记忆读写钩子
• 跨会话记忆共享

5. Sessions（会话）

• 会话生命周期管理
• 多会话并行
• 会话恢复（Agent 崩溃后从上次状态继续）

6. Hooks（钩子）

• 工具调用前钩子（安全检查、权限验证）
• 工具调用后钩子（日志、审计、结果修改）
• 循环钩子（每步开始/结束时的回调）

为什么"Harness 层"是必要的？

Agent 工程的三层模型

过去一年，Agent 工程逐渐形成清晰的三层结构：

Harness SDK 填充的是最底层——之前这一层被各种框架各自实现，没有统一接口。

类比：这就像 Web 开发里的 WSGI/asgi——不是框架，是框架之间的协议层。有了 WSGI，Flask 和 Django 可以共用中间件；有了 Harness 接口，不同 Agent 框架可以共用控制层。

生产环境的痛点

研究阶段的 Agent 和生产环境的 Agent 是两种生物：

Harness SDK 的所有设计——会话管理、钩子、记忆控制——都是面向生产环境的。

Python + TypeScript 双语言

Harness SDK 同时提供 Python 和 TypeScript 版本：

• Python：适合数据科学、ML 场景，和底层 SDK 一致
• TypeScript：适合 Web 应用、全栈场景

这不是简单的"翻译"——两个版本共享相同的概念模型，但各自利用语言特性。比如 TypeScript 版本的钩子可以用装饰器，Python 版本用上下文管理器。

双语言的意义：Agent 不再只是 Python 世界的玩具。当你的前端需要直接调用 Agent（比如浏览器里的 Agent），TypeScript 版本让全栈 Agent 应用成为可能。

和其他 Agent 框架的对比

Strands Harness 的独特位置：不试图替代其他框架，而是提供控制层。理论上，你可以用 LangGraph 写 Agent 逻辑，用 Strands Harness 做控制层。

AWS 的 Agent 战略

Strands 是 AWS 的 Agent 品牌。从时间线看 AWS 的布局：

模式：从"写 Agent"到"控制 Agent"到"Agent 进入物理世界"。AWS 在用 Strands 品牌覆盖 Agent 的全生命周期。

这和 Google 的 Agent 策略（Ax、Gemini）、Microsoft 的策略（AutoGen + Semantic Kernel）形成对比。AWS 的差异化在于：开源 + 云中立。Strands 不绑定 AWS 服务，支持任何模型、任何云。

谁应该用？

• Agent 生产化团队：从 demo 到生产的 Agent 需要控制层
• 多模型混用场景：需要运行时切换模型的
• 合规要求高的场景：需要审计、钩子、安全检查的
• TypeScript 全栈团队：想在前后端统一 Agent 接口的

不适合：

• 刚入门 Agent 的（先用底层 SDK，几行代码搞定）
• 单次脚本任务（不需要会话管理）
• 已有成熟 Agent 基础设施的（迁移成本高）

我的看法

Strands Harness SDK 的出现标志着一个趋势：Agent 工程正在从"框架之争"转向"控制层之争"。

过去两年，Agent 框架百花齐放——LangChain、CrewAI、AutoGen、LangGraph——每个都在卷"更好的 Agent 抽象"。但生产环境的真正痛点不是"怎么写 Agent"，而是"怎么控制 Agent"。

这和 Kubernetes 的发展路径惊人相似：

1. 先有"怎么部署应用"（Docker → 容器化）
2. 再有"怎么管理容器"（Kubernetes → 编排层）
3. 最后有"怎么控制编排"（Operator → 控制层）

Agent 工程正在走到第二步：从"怎么写 Agent"到"怎么控制 Agent"。Strands Harness 是这一步的早期玩家。

预测：未来 12 个月，所有主流 Agent 框架都会暴露 Harness 级别的控制接口。Strands 的先发优势在于：它是第一个只做控制层、不做框架的 SDK。

参考

• 项目地址: github.com/strands-agents/harness-sdk
• 文档: strandsagents.com
• The New Stack 报道: AWS open-sources an AI agent it says is 45% cheaper
• 底层 SDK: PyPI strands-agents | npm @strands-agents/sdk