宝玉 (@dotey) “【6】三天黑客松——Subagents 功能是怎么诞生的 Subagents 这个功能的灵感，来自 Reddi” — TopicDigg

【6】三天黑客松——Subagents 功能是怎么诞生的 Subagents 这个功能的灵感，来自 Reddit 上的一条帖子。 有人说他同时开了五个 Claude Code 实例，给每个实例设定不同的角色，然后用文件系统让它们互相通信。 Sid Bidasaria 看到这条帖子的时候，第一反应是：这个玩法很酷，但用户不应该需要这么折腾。我们应该把它做成产品内置的功能。 正好公司有个三天的内部黑客松，Sid 决定用这三天来做这件事。 第一天，团队兴奋地画出了各种复杂的 Agent 拓扑结构：Agent 之间用消息总线通信、异步模式、多对多交互……图画得很漂亮，概念很先进。 第二天，他们意识到这样做似乎不可行。 问题不是技术实现——那些复杂模式都能做出来。问题是用户没法理解。Claude Code 的 UI 就是一个简单的终端，你怎么在这么简单的界面里让用户明白那些复杂的 Agent 通信模式？ 他们决定推倒重来，回到一个根本问题：普通开发者能用的最简单形式是什么？ 他们给自己定了两条约束： 第一，不发明任何新东西。只用 Claude Code 已有的能力——“/”命令和 .md 文件。 第二，不做 Agent 间通信。改成一个简单的编排模式：有一个主 Agent，它可以调用子 Agent，子 Agent 完成任务后返回结果，仅此而已。 他们还和 Anthropic 的研究团队聊了聊。研究人员正在研究多 Agent 模式，但结论是：复杂的 Agent 拓扑是否真的有效，目前还没有定论。 这给了他们更多信心：既然连研究团队都说复杂不一定好，那就更应该做简单的版本。 第三天结束时，他们做出了一个能用的版本。用户可以在 .md 文件里定义子 Agent 的角色和能力（比如“前端子 Agent：使用 React 19 和 Next.js”），Claude Code 会在合适的时候调用它们，或者用户可以手动触发。 黑客松结束后，稍微打磨了一下，功能就上线了。 现在你可以定义各种专属子 Agent：有安全审计专长的后端 Agent、熟悉特定框架的前端 Agent、专门写测试的 QA Agent……它们可以在后台并行工作，各司其职。 很多团队在黑客松里会舍不得推翻自己的复杂方案，毕竟花了一整天画图讨论，有感情了。能够承认“这条路走不通”并推翻从头开始，需要勇气，也需要对“简单”的信念。 简单不是偷懒。简单是在无数可能性里找到那个用户真正能用的形态。