一名开发者在Linux.do论坛发帖称，使用AI编程工具Astra执行任务时，发现五小时额度在等待subagent工作期间仍在持续消耗。查看本地会话统计后，按token数量计算，等待行为约占Astra总用量的61.2%。进一步拆分显示：Astra自身47.1%的credits和49.6%的token属于纯timeout，等待整体占据五小时额度的41.2%，其中纯timeout约31.7%。原因在于等待期间，Astra会反复调用wait agent进行轮询和启动，token消耗随subagent等待时长成比例增长。该用户的编排策略是让主Agent专注于需求澄清、方案拆解、任务分发和结果验收，将读代码、写代码、跑测试、批量修改等实现类工作派给subagent执行：复杂任务交给5.6sol high模型，简单任务交给luna high模型。发帖者向社区询问优化方案，或是否应改用规划与执行分离的工作流，即只让Astra输出规划文档、另开会话执行任务。该案例引发了对多智能体编排中隐性token成本的关注与讨论。
事件分析
该事件揭示了多智能体系统编排层的真实开销：主Agent在等待子任务期间并非被动挂起，而是通过反复轮询持续消耗token，在长时任务下成本被显著放大。目前主流AI编程工具的subagent机制多依赖轮询而非事件驱动通知，架构层面存在明显改进空间。可行的优化方向包括：降低轮询频率、合并子任务以减少等待次数、调整编排策略让主会话仅产出计划、由独立会话执行具体实现。随着Agent工作流复杂度持续提升，token效率正成为衡量工具竞争力的重要指标，厂商可能需要在任务调度与状态同步机制上进行架构级重构，否则用户将被推向多会话手动编排的原始工作模式。
核心观点：轮询式等待暴露了多智能体编排的成本软肋，事件驱动调度将成为AI编程工具竞争的下一个焦点。
原文链接：Linux.do
评论前必须登录！
立即登录 注册