面试智能体产品岗，先问清“多智能体”指什么

消息提到，面壁智能展示了一个本地智能体案例：在 DGX Spark 上由 32 个 worker 协调处理发票、采购订单与付款对账，执行 232 次工具调用，67.8 秒内完成 32 个案例核验，由 GPT-6 Astra 负责协调。这是展示性质的信息，不能推断该工作流已产品化或正在招人，但它给面试提问提供了一个具体参照：多智能体不是“接了几个模型”，而是任务被拆开、工具被调用、角色之间有协调。

面试时，与其问“你们用多智能体吗”，不如问四个可验证的问题。

四个问题，区分工作流编排与单点包装

任务链路：一个用户请求进来后，经过几个环节？哪些环节由模型判断，哪些由规则或人工兜底？如果对方只能描述“调一次模型返回结果”，更接近单点能力包装；如果能说清拆解、执行、核验的分段，才涉及工作流。

工具调用：智能体要读写哪些系统？调用失败怎么处理？素材里 232 次工具调用对应的是发票、订单、对账这类真实业务动作。面试中可以追问：工具是团队自己接，还是依赖平台？权限和审计谁负责？

协调角色：多个 worker 之间是并行、串行还是互相校验？谁决定任务分给谁？素材中由 GPT-6 Astra 负责协调，但协调策略是写死还是动态生成，需要向目标团队确认，不能假定。

交付形态：最终交付的是一段回答、一个可回滚的流程，还是一份带核验记录的结果？这决定产品经理日常是在调提示词，还是在设计状态流转和异常处理。

对照自己：缺的是产品能力还是领域知识

假设一个模拟场景：两位候选人面试同一岗位。A 做过客服工单系统，能讲清状态流转、升级规则和人工介入点；B 做过模型 API 封装，能讲清调用成本与延迟。若团队做的是发票对账类工作流，A 的流程梳理经验更可迁移，B 需要补业务规则；反过来做通用工具产品，B 的接口设计经验更直接。

转岗前先确认目标团队的业务领域与交付形态，再决定补流程梳理、工具集成还是行业知识，而不是盲目学模型部署。面试中可以用“我过去做过的流程里，[实际记录] 这类环节和你们说的核验步骤有相似之处”来定位自己，但不要编造数字成果。

最后给一个可做的小建议：面试前挑一个你熟悉的业务流程，用任务链路、工具调用、协调角色、交付形态四栏写下来，面试时对照对方的回答追问差异。这比背“多智能体”定义更能帮你判断岗位真实工作内容。