立正观察到，模型遇到复杂任务时容易把“更努力”理解成“再开几个 subagent”，这更像把旧组织的做法搬进 AI。问题是这些 agent 往往来自同一个模型、继承相似的上下文、沿用相似的偏好，五个 agent 可能只是同一个平均值采样了五次，错误也高度相关。放到你的场景：让几个 agent 分别看同一份用户行为数据去猜产品方向，它们很可能给出措辞不同、结论雷同的几份报告，你反而更难判断哪个可信。只有当子问题真的需要不同信息源或不同判断标准时，拆开才有意义⁠1。

更值得先做的是把“产品方向”这个模糊目标翻译成可检验的问题，例如某个功能的使用是否真的带来留存变化，然后设计一个能给出新信息的检验。立正在讲团队该优化什么时提到，应该尽量让每次尝试最大化信息增益，一个成败各半的实验信息量最大。对应到 agent 结构上：如果一个问题单次调用加一份清晰的数据上下文就能回答，就不必上多 agent；只有当需要分别做取数、验证逻辑、再综合判断时，才值得分层，并且每一层都要有明确的通过标准，比如生成的查询先过逻辑校验再取数⁠2,3。

立正把只用工具拿到一次性结果的人称为停在 tinker 阶段，而 builder 会先想清楚要什么，再设计一条有效的工作流去得到结果。你的目标如果是从数据得出产品方向，那么关键工作是你来定义问题、数据和判断标准，agent 只承担其中可分解的执行环节。可以先只搭一条最小链路：一个负责取数和计算的 agent，加上你自己对结论的复核，看它给出的方向判断是否真的改变了你的决策；如果没有，说明问题还没被拆到值得并行的程度⁠4。