一位开发者在 Linux.do 论坛发帖求助，称其在 AI 编程工作流中遭遇子代理效率问题。该开发者使用 Kimi Code Desktop 搭配 DeepSeek V4.1 Flash 1017 模型，以 harness 流程进行网站开发：先由 Trellis 0.6.17 规划并生成任务文档，再进入实现阶段。Trellis 默认会派发 trellis-implement、trellis-check 等子代理负责功能实现与质量检查，但子代理一旦启动便耗时极长，上下文开销迅速膨胀。查看任务记录后发现，子代理基本不读取任务文档与工程规范，稍有疑问就直接翻源码，各类信息都要重新理解一遍；更耗费注意力的是，子代理会逐一研究 vant、antd 等前端组件库源码，甚至在编译完成后去读取 DLL 二进制内容。发帖者坦言，项目组织方式老旧也是诱因之一。他列出几个可能的解决方向：优化子代理提示词、魔改 Trellis、放弃子代理改由主对话直接完成，或更换其他开发工具集，并询问社区开发者使用与优化子代理的经验。该帖反映出多智能体编程流程在实际工程中的落地痛点，引发社区对子代理上下文管理与成本控制的讨论。
事件分析
该案例暴露出当前多智能体编程框架的共性短板：子代理启动时缺乏有效的上下文继承机制，无法自动加载任务文档与工程规范，只能靠重新遍历源码建立认知，token 消耗与耗时因此成倍放大。将第三方组件库甚至二进制产物纳入阅读范围，则反映出智能体在检索边界控制上的不足。可行的改进方向包括：派发时注入精简的任务摘要与规范索引、为子代理设定明确的探索范围、引入代码索引与跨会话记忆机制等。随着 Claude Code、Trellis 等编排框架普及，子代理的上下文治理与成本控制正成为衡量 AI 编程工具成熟度的关键指标，也将是各家工具下一阶段竞争的焦点。
核心观点：子代理效率瓶颈本质是上下文管理缺失：多智能体编排若无知识继承机制，并行派发只会放大成本而非效率。
原文链接：Linux.do
