如果面试官问我：“主Agent把任务交给另一个Agent，是不是就可以继续做别的事？”我会说：“可以，等它回消息。”

“消息发送成功，但对方根本没开始呢？它回了‘完成’，交回来的却不是你要的东西呢？”

这是一道模拟协作题。主Agent要解释一笔换货申请，把“核查对应型号是否有货”交给库存Agent。任务看起来很短，漏一个型号就能全白忙。

消息送到了，只证明通信走了一步。有人接、按要求做、交回正确结果，还得分别确认。

一、委派前，先把任务说完整

我会给这次委派一个稳定任务编号，明确商品型号、查询范围和需要返回什么。要求是检查可换货库存，不是提交换货，也不是替用户锁库存。

返回结果至少应说清查询对象、库存状态、查询时间和证据标识。没有库存与查询失败要区分，未知不能被包装成零。

主Agent还要说明完成标准：给出可核验的库存判断即可，不能擅自加预约动作。子Agent如果缺少型号，应返回缺信息状态，而不是根据商品名称猜一个最接近的型号。

这份约定不必写成很长的角色设定。真正有用的是输入、范围、交付物和边界。十段“你是一位资深专家”，也补不回一个缺失的订单条件。

二、收到、认领、完成，不是一种状态

面试官问：“对方接口返回成功，我就记完成，有什么不行？”

要看成功对应哪一步。请求被接受，可能只是进入队列；任务被认领，说明有执行者负责；计算结束，说明对方提交了结果；主Agent验收通过，才说明这份结果能用于当前目标。

我会让任务状态对这些阶段有明确表达，具体名字由应用协议决定。跨系统协作协议也常区分任务状态与产物，但接入了协议不等于业务验收自动完成。

返回的结果必须关联原任务编号与需求版本。用户中途把商品换了，旧型号的库存结果即便查询正确，也不能直接进入新答案。

还要有负责人和等待上限。不能因为一句“正在处理”，就让任务永远没有下文。超过约定时间，主Agent要查询状态、说明等待原因，或者进入明确的失败处理路径。

三、超时之后，不要盲目再派一份

如果网络超时，主Agent不知道对方有没有收到，可以先按稳定任务编号查状态。重复发送时，接收方按约定识别同一个逻辑任务，避免把同一请求当两份新工作。

只读查询重复执行可能主要浪费成本；一旦任务会创建订单或发通知，重复委派就会产生真实副作用。必须把通信重试和重新开展一次业务操作区分开。

需要故障转移时也一样。新执行者接管，不代表旧执行者真的停了。应用应让产物与动作带上有效的执行代次，并由最终写入服务拒绝过期执行者提交的受控变更。

如果外部业务系统不支持这种约束，就不能声称已经解决所有重复执行。应结合它实际提供的幂等键、查询接口与对账流程，明确仍然存在的边界。

四、主Agent仍然负责最终交付

库存Agent返回“有货”，主Agent还得看是不是对应型号，状态是不是最新，是否只是展示库存而非可用于换货的数量。

如果返回的是“查询失败”，主Agent不能为了让流程看起来完成，把它改写成“暂时缺货”。失败说明证据不足，缺货是业务结论，两者对用户的影响不同。

验收失败时，反馈要具体。例如“结果缺少型号，无法与订单对应”，而不是笼统地让它“再认真想想”。没有明确差异的重试，只是在付钱等待另一段类似文字。

我会限制返工次数，并保留需要人工介入的出口。主Agent不能无限指责子Agent，也不能把“已委派”作为对用户的最终交付。

验证时，安排重复消息、延迟回执、旧需求结果和格式正确但对象错误四类样本。重点看主Agent能否认出该用的结果，以及有没有把不确定状态冒充成功。

面试时，我会这样回答

“委派需要稳定任务标识、明确范围和验收标准。消息发送、任务认领、结果产生与验收通过分开记录，结果绑定需求版本。超时先查状态，重复请求按逻辑任务处理；故障转移还要约束旧执行者。主Agent对最终交付负责，不能因为子Agent说完成就直接通过。”