周三下午，我启动了一场极限测试。不是测评新模型，也不是跑分测试，而是把日常工作拆成五份，同时扔给了五个Claude Code子代理。一小时后，它们不仅完成了全部任务，还提前把我的使用额度窗口彻底榨干。

这个结果比我预想的快了太多。按照常规节奏，这点工作量足够我消磨半天，但也正因为子代理太能干，我第一次感受到了什么叫做“用好就没了”。

打开网易新闻 查看精彩图片

Claude Code本身的体验已经很出色，但真正让我刮目的是子代理系统。我配置了五个独立子代理，各自拥有独立的上下文窗口，只处理分配给它的特定任务，最后返还简短摘要和关键元数据。主代理不需要翻几十个文件、不需要逐行检查原始日志，只需要拿着精炼过的结论来规划和决策。

这种分工模式带来的爽感很直接：以往一个大任务扔给单一代理，它得挨个文件读、逐条日志查，上下文窗口膨胀得飞快，每次响应都在追加新的追踪信息，运转两三轮就开始丢细节、甚至前后矛盾。子代理把脏活累活外包出去，主代理的上下文始终保持清爽。

更关键的是并行能力。我不必等第一个任务完成再启动第二个，把大工作拆成小块后丢出去就行。同时跑五个代理，一个是代码库勘探员，快速定位相关文件；一个做现有实现评审，标出潜在问题；一个负责研读文档和依赖关系；一个专查漏洞和边界情况；最后一个审核改动方案并寻找优化空间。五线并进的半小时里，主代理在规划整体实施路径，等各条线结果归拢，代码库已经勘探完毕、文档已梳理清楚、代码缺陷已被标出、修改方案已过了一遍审核。

系统还支持动态模型路由，轻量任务可以分流到轻量模型上，重度推理留给更强模型处理。这个设计让资源调配更合理，也让我省下一部分不必要的计算消耗。

子代理的产出质量和速度都超出预期。问题在于，好东西的代价写在账单里。Claude Code的使用额度本来也不怎么宽松，启动子代理之后消耗速度更是陡升。上下文隔离这个核心优势同时成了胃口放大器，每个子代理都维护自己的上下文窗口，五个并行意味着五倍的上下文膨胀量。它们干活确实快，可是额度燃烧得更快。

一小时跑完半天活当然爽，但眼看着使用窗口快速收窄，这种体验用一句话概括就是：你可能觉得它好用，太好用，甚至有点好过头了。我至今还在琢磨，这种速度到底值不值得每次都用。