2026 年 3 月 18 日，Anthropic 宣布将 Claude Code 的输出 token 上限从 25,000 提升到 128,000。这是一个超过 5 倍的增长，意味着 Claude 在单次响应中可以生成约 9-10 万字的中文内容或等量的代码。
对于普通的聊天场景，25K token 已经足够了——大多数对话回复用不到几千个 token。但对于 agent 场景，128K 输出上限打开了一系列之前不可能的用途。
25K 的瓶颈
在 25K 输出限制下，很多有用的 agent 任务被人为截断。
让 agent 生成一份完整的技术文档？25K token 大约对应 5000-7000 字的中文，对于一份认真的技术文档来说太短了。让 agent 做一次完整的代码审查？如果代码库有几千行，审查意见加上修改建议很容易超出限制。让 agent 分析一份长报告并生成结构化摘要？输入不是问题（上下文窗口有 200K），但输出被卡在了 25K。
开发者找到了变通方法：把长任务拆成多个短任务，每次生成一部分，然后拼接。但这引入了一致性问题——当你把一篇文档拆成五部分生成时，前后风格和逻辑的连贯性很难保证。agent 在第三部分可能忘记了第一部分的上下文，或者重复了第二部分已经说过的内容。
这些变通方法增加了应用层的复杂性。你需要实现任务分割逻辑、上下文传递、结果拼接和一致性检查。这不是几行代码能解决的——这是一个完整的功能模块。
128K 如何改变游戏
128K 输出上限意味着大多数 agent 任务可以在单次响应中完成。
一份完整的技术文档、一次全面的代码审查、一份详细的分析报告——这些都可以一次性生成，不需要拆分和拼接。这不仅是使用体验的改善——它消除了一整个类别的应用层复杂性。
当输出不需要拆分时，你不需要任务分割逻辑。不需要跨请求的上下文传递。不需要结果拼接。不需要一致性检查。你的代码可以是简单的"发送请求、等待响应"。
薄架构的放大效应
这就是 NanoClaw 受益最大的地方。
NanoClaw 的编排层在 Claude Agent SDK 和用户之间没有额外的抽象。它不截断输出，不做分段处理，不添加自己的格式化。当 Claude 的输出上限从 25K 变成 128K 时，NanoClaw 用户立即获得了完整的 128K 输出能力——不需要更新代码，不需要调整配置，甚至不需要知道这个变化发生了。
对比那些在模型输出之上构建了处理层的框架。有些框架会截断超长输出、有些会分页显示、有些会对输出做后处理。当输出上限变化时，这些处理层可能需要更新——截断阈值要改、分页逻辑要调、后处理的假设要重新验证。
NanoClaw 没有这些层。模型的输出直接到达用户。所以模型输出能力的任何提升，都以零延迟、零开发成本传导到用户。
这是薄架构的一个核心优势：当底层能力提升时，薄中间层让提升无损传导。中间层越厚，传导越多阻力——因为中间层的每一个假设、每一个处理步骤、每一个格式转换都可能成为阻碍。
128K 输出 + 容器环境
128K 输出在 NanoClaw 的容器环境中特别有价值。
NanoClaw 的 agent 在容器中可以执行代码。当 agent 生成一份长代码文件时——比如一个完整的 Python 脚本或一个多文件的项目——128K 上限意味着 agent 可以在单次响应中生成完整的代码，然后在同一个容器会话中执行它、测试它、修复问题、再次运行。整个开发-测试-修复循环在一个连贯的上下文中完成。
以前需要拆分的长文本生成任务现在也变得直截了当。让 agent 写一篇深度分析、生成一份完整的 API 文档、创建一个多章节的教程——128K 上限让这些都成为单次交互就能完成的任务。
趋势的方向
从 25K 到 128K 不是终点。Anthropic 的路线图清楚地表明输出能力会持续提升。Claude 的上下文窗口从 100K 到 200K，现在输出从 25K 到 128K——模型的输入和输出能力都在快速扩张。
对于薄架构来说，每一次扩张都是免费的能力增长。NanoClaw 不需要做任何事情来"支持"更长的输出——因为它从来就没有限制过输出长度。当 Anthropic 将输出上限提升到 256K 或 512K 时，NanoClaw 用户会自动获得新的能力，就像他们从 25K 到 128K 的升级一样无感。
你没有构建的功能不需要升级。你没有添加的限制不需要移除。这就是最少代码哲学在能力扩张时的回报——什么都不做，就已经做了最正确的事。