生成式推荐需要多个 Agent 时，怎么划分角色和共享状态？

先这样答

我会按推荐漏斗划分 Agent，并用集中式候选池与特征存储共享状态。召回 Agent 负责生成候选，排序 Agent 负责融合多目标打分，解释 Agent 负责生成推荐理由，审核 Agent 负责合规与多样性校验。每个 Agent 只承担漏斗中的一类工作，边界由输入和交付物定义。

共享状态不放在各 Agent 的自然语言对话里。我会把候选和特征分别放进集中式候选池与特征存储。Agent 之间传结构化候选列表，让下游按统一字段读取候选。这样可以明确每一层交付了什么，也能避免自然语言描述代替候选数据。

完成条件分两层定义。每层先约定交付物，例如召回层交候选列表，排序层交融合多目标后的结果，解释层交推荐理由，审核层交合规与多样性校验结果。整体完成条件看排序质量指标。面试里，我会把角色边界、状态位置、传递格式和完成条件一并讲清楚。

面试官会怎么追问

• 「为什么不让一个 Agent 直接完成从召回到解释？」 按推荐漏斗拆分后，每个 Agent 负责一类工作。召回生成候选，排序融合多目标打分，解释生成推荐理由，审核检查合规与多样性。每层都有明确交付物，便于判断这一层是否完成。

• 「Agent 之间具体共享什么状态，怎么传？」 共享状态放在集中式候选池与特征存储中。Agent 之间传结构化候选列表，不传自然语言。这样下游接收的是明确的候选数据，而不是对候选的文字描述。

• 「每个 Agent 做完就算整体完成了吗？」 不算。每层需要先满足自己的交付物定义，整体完成还要看排序质量指标。分层条件和整体条件分别判断，不能只凭某个 Agent 返回结果就结束。

回答的坑

• 只说按推荐流程拆 Agent，却不交代集中式候选池、特征存储和结构化候选列表，漏掉了共享状态与传递方式。
• 把各层交付物当成整体完成条件，或用自然语言传候选，都会模糊 Agent 的边界和完成标准。