多 Agent 工作流为什么需要产品化

多 Agent 容易被包装成技术概念。更值得追问的是，它能否稳定地帮助人完成复杂任务。

pi-dynamic-workflows 做的是把一个提示拆成一组可执行的子任务，让多个 Agent 并行工作，再把结果汇总回来。它支持模型分层、工作流恢复、成本核算和交互式查看。对产品经理来说，这些能力背后都是非常具体的产品问题。

并行不是目的，降低等待时间和认知负担才是目的。代码审查、大范围重构、资料交叉验证，这些任务适合多 Agent，因为它们天然可以拆分，也需要交叉复核。任务不能拆，或者拆完之后没有综合判断，多 Agent 只会制造更多噪音。

最初接触多 Agent，常会被“同时做很多事”吸引。做久一点会发现，麻烦的不是把任务发出去，而是把结果收回来。十个子任务给出十份结论，如果没有结构化的汇总、冲突标记和证据来源，用户的负担并没有减少，只是从等待变成了阅读。

长任务在后台运行，用户最怕的不是慢，而是不知道它在做什么。执行到哪一步、哪个子任务失败、成本花了多少、结果能否复用，这些状态都需要被产品化。工作流导航、阶段视图、恢复执行和成本核算不是附加功能，它们决定用户是否敢把真实工作交给工具。

Agent 工具不能只看演示时开了多少个窗口。更有价值的指标包括任务完成率、错误结论比例、人工复核耗时、恢复执行成功率、单次有效发现的成本。没有这些口径，并行只是热闹。

模型路由也不只是“贵模型做难题，便宜模型做简单题”。问题在于什么叫难，什么时候需要升级，什么时候应该让两个模型交叉验证，什么时候应该直接停下来让人判断。一个成熟的工作流系统，需要把这些策略变成可观察的决策，而不是把所有选择藏在提示词里。

恢复执行是另一个常被低估的能力。现实里的长任务很少一次跑完：网络会断，预算会变，用户会临时中止，代码库也可能在执行过程中变化。能不能从 journal 里恢复，能不能知道哪些结果还有效，能不能避免重复花钱，这些细节决定工具是否能进入日常工作。

多 Agent 产品的关键，是降低不确定性。它要能解释、能暂停、能恢复、能复查，也要能把分歧和失败暴露出来。日常使用时，用户需要知道它在做什么，更需要知道结果为什么可信。

最后会回到一个很朴素的判断：一个人把任务交给工具之后，是更清楚了，还是更困惑了。多 Agent 如果只增加产出数量，价值有限；如果能把复杂问题拆开、验证、收敛，再把判断交还给人，它才算完成了产品化。