迁移断层：harness 为什么成了新瓶颈
AWS 在官方博客中描述的痛点非常具体：许多开发者已经习惯用 Claude Code、Codex 这类成熟工具在本地机器上「开箱即用」地搭智能体原型，因为它们在自己机器上跑得很顺；但当要把原型迁到可扩展的云端环境时，就会遇到各种问题——要么自己重写 agent 循环，要么绑定到单一云的托管平台。
Strands Harness 的回答是提供一个完整、即用型的通用智能体：本地能跑，任意云也能跑，而且默认配置就是 AWS 团队认为「生产可用」的那一套。这与 2026 年以来行业从「模型竞争」转向「运行层竞争」的大趋势一致——Harness 决定智能体能否从 demo 走向生产。
Strands Agents SDK 提供积木（模型驱动的 agent 循环、工具、记忆等构件），Strands Harness 把这些积木装配成一台成品：create_harness() 一行代码返回一个带 shell、文件、搜索、记忆与子任务委派能力的通用 agent——它不是编码 agent，而是通用任务 agent。
架构拆解：SDK 之上的「开箱默认值」
Strands Harness 构建于 Strands Harness SDK 之上（AWS 开源的多智能体模式管理框架），以 Apache 2.0 协议发布，同时提供 Python 与 TypeScript 两个版本。开箱即用的能力清单如下：
| 能力域 | 默认组件 | 设计取舍 |
|---|---|---|
| 基础工具 | 读取、写入、编辑文件；shell 执行；网络搜索 | 依赖底层模型既有工具知识，而非为每类任务定制工具 |
| 模型接入 | Amazon Bedrock、Anthropic、OpenAI、Google、本地 Ollama、LiteLLM | 模型层完全开放，不绑定单一厂商 |
| 上下文管理 | 工具结果卸载至独立文件；重复请求部分缓存 | 缩短处理时间、降低 token 消耗（详见下文三条规则） |
| 长期记忆 | 跨运行保持记忆，可通过会话 ID 恢复历史对话 | 面向长周期任务与会话延续 |
| 子任务委派 | 内置辅助智能体 + 自动化清单追踪多步工作 | 开放式子任务可委派并跟踪进度 |
| 扩展机制 | Agent Skills 上传；集成 MCP 服务器等外部工具 | 与 2026 年主流扩展生态对齐 |
这里最值得咀嚼的是「依赖模型既有工具知识」这一条：AWS 明确表示不要求开发者为每项任务设计定制工具，而是押注前沿模型本身已经掌握如何使用 shell、文件与搜索。这是一种把复杂度从框架侧转移给模型侧的赌注——模型越强，harness 需要补的课越少。
跨云部署面：任意云与本地 Ollama
Strands Harness 的部署主张是「一次构建，随处运行」：
- 云侧：官方支持 AWS、Google Cloud、Microsoft Azure、Modal、Cloudflare 等主流平台；随包附带的 skills 文件可以帮助编码类智能体自动生成各云的部署配置
- 本地侧：可指向本机 Ollama 模型，整套智能体流量不出自有基础设施
- 运行环境：运行于 Linux 容器，这解释了它为何能在异构云与本地之间保持行为一致
配套发布的还有 Strands CLI：AWS 团队自己就是用它开发出来的——用户选择底层模型、添加提示词与工具，就能以自然语言原型化一个智能体，再用 /export 命令把底层 harness 代码导出为 Python 或 TypeScript 文件继续定制。安装方式为 pip install strands-harness 或 npm install @strands-agents/harness。
成本账本：28% 与 77% 是两个口径
AWS 公布的基准数字需要分清两个口径，媒体传播中二者经常被混为一谈：
| 口径 | 数字 | 含义 |
|---|---|---|
| 六基准平均成本节省 | 28% | ALFWorld、ContextBench、GAIA、WebShop、τ²-bench、Terminal-Bench 2.1 六个基准的平均每任务成本，对比对象包含 Claude Code、Codex、oh-my-pi、OpenCode、DeepSeek Harness |
| 对 Claude Code 单项对比 | 77% | 同一任务、Anthropic Fable 5 模型、Terminal-Bench 2.1 上，Strands Harness 成本比 Claude Code 低 77%，且综合分数更高 |
| 媒体转述口径 | 26% | 部分媒体报道为「相同底层模型下比其他框架构建的智能体效率高 26%」——与 28% 属于不同表述，均系 AWS 自报 |
28% 这个数字有个容易被略过的脚注：DeepSeek Harness 是全场 token 效率更高的 harness，运行成本比 Strands Harness 还低约 14%，只是在所有基准上分数都更低。把 DeepSeek Harness 计入对比后，整体节省数字从更高的水平回落到 28%。换句话说，28% 是一个「对弱者也让利」之后的保守值，这是诚实的呈现方式。
同模对决：Terminal-Bench 2.1 五 harness
整套评测中最有信息量的是 Terminal-Bench 2.1 上的同模型对比：同样的 Anthropic Fable 5，五个 harness、每格 89 次试验。评测在 Amazon EC2 上用 Harbor（Terminal-Bench 团队的评测框架）分布式执行：
| Harness | 运行成本（美元） | 准确率 |
|---|---|---|
| Strands Harness | 56.29 | 69.7 |
| oh-my-pi | 86.83 | 69.7 |
| OpenCode | 73.42 | 66.3 |
| Claude Code | 248.05 | 61.8 |
| DeepSeek Harness | 40.30 | 59.5 |
从这张表能读出三层信息：
- 对 Claude Code：成本只有约 23%（-77%），准确率反高 7.9 分——这是官方传播的主叙事
- 对 oh-my-pi：准确率打平（同为 69.7），成本却低 54%——同分段拼的是效率
- 对 DeepSeek Harness：对方更便宜（40.30 美元），但分数低 10.2 分——便宜与准确各占一头，不存在全维度碾压
图表上分数最高的点位是 Claude Opus 5 跑在 Strands Harness 上，接近 85 分——这说明 harness 的上限取决于背靠的模型，而非 harness 本身。
独立的 HarnessTax 研究曾对 Claude Code、Codex CLI 与 Pi 跨 7 个模型做过对比，结论与 AWS 的数据方向一致：harness 的选择几乎不改变成功率，但同样的模型达到相近成功率，成本差距可达 5 倍。token 经济学已经是软件架构问题——「智能体怎么遗忘、怎么摘要、怎么委派」决定了账单。
效率从哪来：三条上下文规则
AWS 团队把 token 效率与准确率的双赢主要归因于上下文管理，具体是三条默认规则：
- 工具结果截断：超过约 1500 token 的工具输出被截断，避免大块原始数据反复进入上下文
- 摘要压缩：上下文用量超过 85% 时触发 compaction，把历史对话压缩成摘要
- 循环内恢复：窗口溢出时在 agent 循环内部执行上下文恢复，而不是中断任务
配合提示词缓存（对重复请求的复用部分做缓存）与工具结果卸载（大输出写入文件、按需引用），这四件事构成了「默认就省钱」的运行时。值得强调的是：这些不是 Strands 的发明，而是 2026 年 harness 工程的共识做法——Strands Harness 的价值在于把它们变成了不用配置的默认值。
边界与冷思考
- 全部数字系厂商自报：六基准平均、77%、26% 均来自 AWS 自己的评测，独立验证尚未完成；AWS 团队表示后续会发布配套基准论文，届时方法学细节才可复核
- 「任意云」的工程代价：跨云一致行为依赖 Linux 容器化与模型开放接入，但企业级的治理特性（审计、权限、合规）并未在开源 harness 层面给出完整答案——那仍是 AgentCore 等托管平台的领域
- 竞品不会静止：Claude Code、Codex、OpenCode 等商业与开源 harness 都在快速迭代 token 效率，任何静态对比的保质期都以月计
- 定位是原型而非全托管：官方明确把快速原型开发列为首要场景；从原型到企业生产，中间仍需托管运行时、观测与治理层的补位
- 发布日期口径：多家媒体于 9 月 21-22 日报道官方博客发布，个别第三方文章写作 9 月 25 日，以 AWS 官方博客时间为准
目前官方及行业暂未披露更多细节（如企业级支持政策、托管化路线与基准论文的完整方法学），后续将持续跟进迭代动态。