给每个 Agent 一个独立空间：腾讯云 Agent Bucket 实测

先说我碰到的问题

最近在折腾一个 Agent 应用，跑着跑着冒出来一个挺实际的问题——Agent 弄出来的那些文件，到底往哪儿放？

中间结果、用户传上来的附件，以及 Agent 自己生成的产物，这些东西全混在一块儿。我一开始图省事，直接往一个 COS 桶里写，靠 Key 前缀区分，user/2026/10/xxx.png、agent/task-123/result.json 这么拼。文件少的时候完全没感觉，等文件一多，麻烦就一件一件冒出来了。

头一个麻烦是，前缀这东西是约定，它不是约束。哪段代码路径拼错了，就能写到别人的目录里去，而且没人会发现——因为压根没人检查。想给某个用户限个配额呢，得自己在业务代码里算，还得防着并发。想看看某个用户到底占了多少空间，那就更麻烦，自己扫一遍 Key 再 sum。

说白了，这些活本来就该存储平台干，我在应用层又写了一遍，而且写得很糙。

腾讯云新上的 Agent Bucket（智能体桶） 打的正好是这个点：把「空间（Space）」做成存储层的原生概念，一个用户或者一个 Agent 实例一个空间，配额、权限，以及用量全都挂在空间上，不用在 Key 里做文章。我申请了体验资格，实测了一下。

开通：十来分钟跑通，中间踩了个小坑

流程本身不复杂。产品页点「立即开通」→ COS 控制台创建智能体桶 → 第一次建桶要授权 SMH_QCSLinkedRoleCOS（智能体桶底层依赖智能媒资托管，这一步别漏，漏了后面建不了空间）→ 建空间 → 传文件。

我的桶名是系统生成的：smh3botkuweflrsb-1432500741，改不了。这个设计我能理解，全局唯一嘛，但真到了多桶的场景，就只能靠备注字段人工分辨了。建议后面支持一下备注名搜索，不然桶一多真的会混。

建空间要填三项：空间 ID（必填）、存储配额（选填，留空就是不限）、备注（选填）。实测一个空间 1-2 分钟建好，不用等资源分配，这点挺利索。

这里踩了个坑，单独说一下。

我习惯性地把空间 ID 填成 test-base，提交，报错。我想那可能是连字符的问题，改成 test_dedup 用下划线，还是报错。折腾到第三遍才反应过来——空间 ID 只支持英文字母和数字，连字符、下划线，以及点号，一个都不行。

限制本身没问题，问题出在提示上。报错就一句话"格式不合法"，没告诉我不支持哪些字符；输入框的 placeholder 也只有"请输入空间 ID"这几个字。要是 placeholder 直接写「仅支持字母和数字，1-32 位」，我一次就过了，不至于试三遍。

（图 1：空间管理页，三个空间 hello 配 20GB、testbase 配 1GB、testdedup 配 1GB）

三个空间都跑起来了，配额各不相同——这本身就说明配额是按空间独立生效的，不是整桶统一配置。

核心实测：去重到底生效了没有

官方主打的能力之一是内容级去重 + 秒传：内置 SHA-256 全量哈希，跨用户全局去重，相同内容只存一份。

这个能力要是真成立，价值不小。多 Agent 场景下重复内容其实特别多——同一份文档被好几个 Agent 引用，以及同一张图被反复上传，这种事天天在发生。但问题是，它到底生效了没有，我怎么知道？

我设计了一组对照测试：建两个空间，文件全部用随机生成的内容，靠 SHA-256 精确控制谁和谁一样。

基准组 testbase，5 个文件

对照组 testdedup，7 个文件

我想搞清楚三件事：跨空间的同内容会不会只存一份？改了名字它还认不认得出来？8MB 这种大文件也一样吗？

（图 2：testbase 空间文件列表，底部显示共 5 条）

（图 3：testdedup 空间文件列表，底部显示共 7 条）

结果是，34 个文件全部上传成功，批量拖拽一次没失败。但去重这件事，我没能验证成。

不是测试没做，是控制台上找不到任何能证明它的地方。我把能翻的地方都翻了一遍：

1. 文件列表里没有「秒传命中」以及「引用」之类的标记，传完就传完了，看不出哪一次走了秒传
2. 文件详情和空间详情都只显示逻辑大小，没有单文件的物理占用，也没有引用数
3. 空间管理页那列「已用容量」（testbase 显示 8.02 MB、testdedup 显示 8.01 MB）我也看了，是逻辑总量，不是真实物理占用——两个空间加起来约 16 MB，根本看不出有没有去重
4. 「资源用量」页面对智能体桶显示 0 B，页面标注约 2 小时延迟，这个也没法拿来验证

翻完之后我又把文档对了一遍，确认这几处确实没有，不是我漏看了。

所以结论有点尴尬：产品说它做了跨空间全局去重，我信，但我在界面上找不到任何一个数字能证明它。

我没有质疑这个能力不存在。SHA-256 全量哈希做秒传是很成熟的机制，官方不至于在这件事上吹牛。我想说的是：一个最有技术含量、最能省钱的能力，做出来了却看不见，等于白做一半。

顺手的地方：这三块是真好用

吐槽归吐槽，好用的地方也得讲清楚，不然显得我在挑刺。

第一，空间这个抽象层，设计对了。

它把"一个用户一个独立目录 + 独立配额"从业务代码里的字符串约定，变成了平台层的强制约束。这两者的区别不只是省了几行代码，而是责任边界变了：前缀隔离是"我们说好这么放"，空间隔离是"平台保证只能这么用"。写过权限 bug 的人应该懂，这个差别有多值钱。

第二，目录树 + 批量上传是开箱即用的。

整目录拖拽、批量多选，以及目录管理，全都有，不用自己造。标准 COS 桶你得自己在 Key 里拼 user/2026/07/xxx.png，还得自己写一层网盘中间层来做目录展示以及批量操作。这里直接就有，省掉的工作量不小。

第三，完全兼容 COS/S3 协议。

Key 格式是 <SpaceId>/<path>，本质上还是 COS，现有的 SDK、工具链，以及迁移脚本都不用重写。这一条对迁移成本影响最大——不用改代码就能试，试错成本低很多。

给官方的建议（按优先级排的）

1. 文件列表加一个「秒传命中」标记

上传的时候能识别出来就打个标签，成本极低，但信任感完全不一样。现在这种"我觉得它生效了但我不确定"的状态，对使用者来说挺难受的。

2. 文件详情展示「逻辑大小、物理占用，以及引用数」

这是验证去重的唯一途径，也是成本核算的基础。我花了钱，总得知道这 8 MB 到底占了几份吧。

3. 桶级或空间级给一个「去重节省量」看板

比如"本桶共去重 X GB，节省 Y%"。这比任何技术描述都能说明产品价值，也是最好的宣传素材。

4. 把智能体桶的用量纳入资源用量视图

现在显示 0 B，第一次看到会以为数据没写进去，容易误判。

5. 空间 ID 的校验提示前置

placeholder 里写清楚「仅字母和数字，1-32 位」，比事后报错强一百倍。我为了这个试错了三次，纯属没必要。

6. 配额超限的行为写进文档

是拒绝写入，还是允许写入后告警？这个不清楚，业务侧没法设计降级逻辑。我这次测的文件最大才 8 MB，没碰到 1 GB 配额的边界，所以也没敢下结论。

7. 补一个端到端的 demo

现在的文档是 API 参考式的，概念讲清楚了，但"从零跑通"这一步要自己拼。建议出一个最小示例：建空间 → 签发 Token → 前端直传 → 列目录，四步跑完一遍就什么都明白了。

最后

Agent Bucket 让我印象最深的是空间这个抽象层。它没有发明什么新东西，只是把大家一直在应用层手搓的那套隔离逻辑，下沉成了平台能力。这个方向是对的。

上手也顺，批量上传和目录树是我这次觉得最好用的两块。

但这次体验最大的遗憾是：去重这么硬的能力，目前只能靠相信，不能靠验证。 补一个秒传命中标记、加一个物理占用字段，成本大概不大，但这个产品的可信度会完全不一样。

至于要不要上生产——空间隔离和配额这两块我觉得已经够用了。真要接多租户场景，我会先等 AccessToken 的生命周期（有效期、续期，以及失效时机）在文档里写清楚再说，这个不清楚，我不太敢往生产上放。

测试环境：桶 smh3botkuweflrsb-1432500741，地域 ap-chengdu，3 个空间共 34 个文件，测试时间 2026-10-22。文中测试文件均为随机生成的脱敏文件。

#玩转 Agent Bucket