开源通用Agent底座Strands harness在2026年9月21日正式亮相，基于Apache 2.0协议的Strands Harness SDK构建。团队拿出的成绩单非常抓人眼球：在EC2环境运行Harbor分布式基准测试时，面对同等Claude或GPT模型，Strands harness跨6项基准测试将Token成本压低了28%，且宣称准确率持平或更高。在Terminal-Bench 2.1基准与Claude Fable 5的89次试验里，它甚至宣称比官方工具Claude Code便宜77%且得分反超。
当所有团队都在被大模型长程自主循环的账单压得喘不过气时，跑分立省四分之三的说辞极具煽动力。但天下没有免费的算力，大幅节省的Token背后不是高超的算法跃迁，而是一套极其激进的工程剪枝。
暴跌的账单全靠重手截断
根据Strands官方博客披露，驱动这种极致Token效率的三大默认设定其实并不神秘：工具执行返回的结果一旦超过约1500 tokens就会被强行截断，当整体上下文水位涨至85%时触发摘要压缩，并在循环内部捕获上下文溢出执行自动恢复。
把长输出砍掉、把旧记忆压缩，账面Token自然大幅减少。问题在于，这种剪枝策略本身具有双刃剑效应。同一个测试集中同时对比的DeepSeek Harness，其Token成本其实比Strands还要再低约14%，但代价值得警惕：在所有基准测试里，DeepSeek Harness的准确率均排在最末位。这足以说明，在智能体长程规划的场景里，无差别的粗暴瘦身极易切掉执行动作所必需的环境感知。
削足适履以就屦，省下的表面Token终将在失败重试里加倍偿还。
Claude Code在面对膨胀的上下文时，采用的是Prompt缓存搭配手动或自动compact压缩机制。缓存Token在计费上确实享受折扣，但在物理层面上，它依然实打实地占满整个窗口空间。Strands选择在工具吐出数据的第一步就动刀，把大块输出直接改写或剔除，以此强行遏制窗口扩张。
开源显微镜下的工程裂缝
抛开亮眼的发布文告，翻开GitHub代码仓库能看到截然不同的图景。
官方博客所宣扬的1500 tokens截断和85%压缩阈值，在当前的SDK主分支中甚至没有确立为通用默认常量。在Issue与PR讨论区里，开发者们对压缩水位的争论一直围绕着70%（#555）与80%（正在进行的#3552）展开。这意味着文章里打出的超低消耗，极大概率是研发团队为了刷榜而量身定制的特调参数。截至目前，官方基准测试尚未公开每个Trial的原始数据、Harbor Job ID或可一键复现的环境配置，详细测试细节全寄托在一篇仍在预告阶段的学术论文中。
更致命的隐患出在提示词缓存的底层一致性上。在已关闭的GitHub Issue #2112中，开发者曾指出当Agent发起并发工具调用时，网络响应返回的先后顺序并不稳定。这种不稳定直接导致返回内容拼接进Prompt时的顺序发生变动。
大模型的KV Cache完全依赖严格的字符前缀哈希。一旦顺序错乱，整个提示词缓存瞬间失效，不仅无法省钱，还会引发执行轨迹的分歧。社区用户在讨论区（#1391）给出了另一组对照：在首轮任务准确率相当的条件下，成熟的LangGraph框架在自身测试中表现出的延迟比Strands约低6倍，Token消耗反而低了25至30倍。
- 提醒.评估Agent底座时，不能脱离任务成功率单看Token降幅；脱离基线复现的极端截断，往往把成本转嫁给了重试。
算力账本该从单价转向终局
行业对AI脚手架的审视，正在经历一场去魅。早期的Agent实验只要能跑通几个简单脚本便能博得满堂喝彩；但当这些流程进入生产系统，开发者面对的是复杂的日志分析、庞大的代码库检索和长达数十步的调用链。
在这一背景下，把测试集当作考场，通过激进截断输出来取得漂亮的Token单价并不困难。古人行军讲求因粮于敌，务求实效；如果为了辎重轻便而将干粮裁减大半，队伍走不完全程，前期的节省便毫无意义。真正的指标永远只有一个：单次任务成功闭环成本。
如果一个通用脚手架为了省下前期的上下文，将关键的错误堆栈从1500 tokens外切断，导致模型在后续步骤中盲人摸象、反复重试，甚至得出完全错误的代码结论，那么哪怕表面Token费用下降了77%，实际业务中的工程结算单依然是在大幅亏损。Strands harness的开源确实为云端通用脚手架提供了新的解题切面，但在它的完整日志与独立第三方复现落地之前，对这样的数字狂欢仍需保持克制。