把机制串起来
Agent Harness不是模型本身，而是包住模型的执行系统：负责循环调用、工具、上下文、记忆和失败恢复。模型每次看到的上下文越长，输入Token成本和超窗风险通常越高，因此工具结果裁剪、摘要压缩和缓存会直接影响成本与稳定性。SDK提供可组合的零件，Harness则把这些零件组装成拿来即用的默认Agent。
Harness通过统一循环让模型决定何时调用Shell、文件和Web工具，并用清单跟踪多步任务，必要时把开放式子任务交给辅助Agent。超过约1500 Token的工具结果会被截断，上下文使用率超过85%时触发压缩，窗口溢出时在循环内执行恢复。重复请求部分使用提示缓存，庞大工具输出则外置为文件，减少后续请求反复携带完整内容。会话ID和长期记忆支持跨运行恢复，Skills机制则允许Agent按需加载任务能力。代价是压缩可能丢失细节，截断可能削弱推理，缓存收益还依赖请求前缀稳定；
['先用create_harness验证通用任务，再按需替换默认循环', '适合工具调用、长流程、跨会话任务，不等于编码专用Agent', '对关键细节任务应检查截断与压缩，避免信息丢失', '部署前固定模型、提示和缓存策略，单独核算真实成本']
从“能跑”到“能复用”，缺的是模型外的一层系统
AWS Strands Agents 团队发布的 Strands Harness，是一个面向通用 Agent 的开源运行框架。它使用 Apache 2.0 许可，提供 Python 和 TypeScript 版本，既可以在本地运行，也可以部署到云端，目标是解决这样一个具体问题：一个 Agent 在 Claude Code 或 Codex 里看起来有效，重新用自己的循环、工具和上下文逻辑搭建后，却往往变得更贵、更脆弱，甚至难以复现。
这次发布值得读，不是因为“一个命令创建 Agent”本身有多新，而是因为它把模型之外的工程层明确暴露出来。Strands Harness 将循环、工具、上下文处理、记忆、任务恢复和子 Agent 委派组合成一套工作默认值，试图让 Agent 的效果不再主要依赖某个开发者临时写出的隐性控制逻辑。它也因此把一个常被当成胶水代码的问题，变成了可以比较的系统架构问题。
Harness 不是包装器，而是一组运行时取舍
调用 create_harness() 后，系统默认提供当前推理模型的接入能力，模型来源包括 Amazon Bedrock、Anthropic、OpenAI、Google、Ollama 和 LiteLLM。工具层不是为某个任务单独定制的接口，而是直接提供 shell、文件读写编辑和网页工具。对于跨任务的通用 Agent，这种选择降低了从零拼装工具链的门槛，但也意味着工具权限、输入边界和输出规模必须由部署方进一步约束。
Strands Harness 还把几个容易被忽视的运行时能力放进默认路径。大型工具结果会被转存到文件中，重复请求的部分会被缓存，长期记忆可以跨运行保留，会话可以通过 session ID 恢复，开放式子任务可以交给内置 helper agent，多步骤任务则由 checklist 跟踪。系统还会在发现 Agent Skills 时加载它们。换句话说，它并不只是把模型 API 换成另一个函数，而是在替开发者预先决定哪些信息留在上下文里、哪些信息被外置，以及任务如何在失败后继续。
28% 不是模型魔法，而是上下文管理的结果
团队在 Amazon EC2 上使用 Terminal-Bench 团队的 Harbor 评测框架进行分布式测试，平均结果覆盖 ALFWorld、ContextBench、GAIA、WebShop、τ²-bench 和 Terminal-Bench 2.1 六个基准。团队报告称，在运行相同 Claude 或 GPT 模型时，Strands Harness 相比其他 Harness 平均成本低 28%，准确率接近。这个数字的比较单位不是“哪个模型更强”，而是“同一个模型放进不同运行系统后如何表现”。
证据里有一个必须保留的限定。DeepSeek Harness 在总体 token 效率上比 Strands Harness 还便宜约 14%，但在每个基准上的得分都更低，而且将其纳入统计后，Strands 的总体节省幅度被拉低到 28%。在最清楚的单模型对照中，Claude Fable 5 运行 Terminal-Bench 2.1，每个 Harness 进行 89 次试验，Strands 比 Claude Code 成本低 77%，准确率高 7.9 个百分点。Oh-my-pi 达到相同的 69.7 准确率，却多花 54% 成本，DeepSeek Harness 更便宜但低了 10.2 个百分点。这些结果支持“系统设计影响成本与效果”的判断，但不能脱离任务分布解释成普遍规律。
真正起作用的是三道上下文闸门
Strands 团队把上下文管理称为 token 效率和准确率的主要来源。它的默认策略包含三道闸门：工具结果超过约 1,500 个 token 时截断，整体上下文使用量超过 85% 时触发摘要压缩，窗口溢出时在循环内部执行上下文恢复。三者共同改变了 Agent 的工作方式。Agent 不再把每一次网页抓取、命令输出或文件内容都原封不动地带入下一轮，而是让运行时决定哪些内容需要保留、压缩或重新取得。
这也是成本与准确率可能同时改善的原因。单纯截断可能减少 token，却可能丢掉完成任务所需的信息。压缩和恢复则试图在控制上下文规模的同时，保留任务状态，让模型在窗口接近上限时还有机会继续工作。材料提到的 HarnessTax 研究提供了相近方向的独立证据：在 Claude Code、Codex CLI 和 Pi 上比较七个模型后，Harness 选择对成功率影响很小，但同一个模型达到相近成功率时，成本最高可相差 5 倍。换言之，低成本并非只是少发几段 prompt，而是对信息生命周期做了更严格的管理。
部署路径很宽，但生产边界仍由团队自己承担
Strands Harness 的部署叙事相当开放。它可以本地运行，也提供捆绑的 skills 文件，帮助编码 Agent 为 AWS、GCP、Azure、Cloudflare 和 Modal 生成部署配置。安装入口也很直接，Python 使用 pip install strands-harness，TypeScript 使用 npm install @strands-agents/harness，模型既可以按名称选择，也可以指向本地 Ollama 模型。Strands CLI 还允许开发者用自然语言搭建原型，演示中 Agent 被要求添加 Playwright MCP server，并测量一个博客页面的视频加载延迟，随后通过 /export 生成配置。
但“能部署”不等于“已经适合生产”。通用 shell、文件和网页工具扩大了可用性，也扩大了权限失控、敏感数据进入长期记忆、工具输出污染上下文以及子 Agent 难以审计的风险。材料没有给出这些场景下的隔离、审批、观测或成本上限设计，因此不能把开箱即用误读为治理已经完成。技术负责人更适合把 Strands 当作一个可复用的基线，然后针对任务类型重新验证上下文截断是否安全、恢复是否会重复执行副作用操作、缓存是否会带来数据边界问题，并用自己的工作负载复测成本与准确率。