ARTICLE · 1215253
老梁AI电商:工作交给下一个Agent,先交清这五项信息
老梁AI电商:工作交给下一个Agent,先交清这五项信息
交接时少说的一句话，到了下一个Agent那里，往往就成了一次猜测。 老梁AI电商，专注帮电商企业建立可落地的 AI 能力体系——从 AI 内容生产到私有知识库、岗位 Agent。对于多Agent协作，先把一个具体问题说清楚：工作交给下一位执行者时，究竟要交什么，才能让对方独立开工，让主控收到结果后知道如何继续？ 假设一条商品上新流程中，资料Agent整理完材料，接下来交给文案Agent。转交消息只有一句：“资料整理好了，你继续写。” 这句话看似推进了工作，实际上留下不少空缺。写哪个商品、哪个渠道、哪一批任务？使用哪版资料？哪些卖点有依据，哪些还在等核实？这一次只交草稿，还是允许保存、上传？资料不齐时应该回来问谁？ 如果接收方逐项追问，交接会反复；如果接收方直接补齐，错误又可能进入下一道工序。问题就在于，发出任务的一方，以为对方知道自己知道的事。 一次有效的Agent交接，需要交清五项信息：任务身份、输入资料、授权范围、验收标准和回传要求。这五项分别回答结果归到哪里、依据是什么、动作做到哪里、怎样算完成、出了问题如何继续。 同一款商品，可以对应不同批次的上新、不同渠道的文案，也可能在资料更新后重新核验。商品名称能够说明业务对象，却不能单独说明这一次任务。 假设“商品A”同时有两份核验需求，一份用于本次上新，一份用于旧页面修订。如果交接时都只说“检查商品A”，即使两个执行者都很认真，主控收到报告后也可能分不清哪份对应哪次工作。 所以，交接的开头应写清所属流程实例、当前节点、负责推进的主控，以及本节点需要解决的问题。实例身份用来区分这一次工作，节点身份用来定位这一步责任。两者配合，结果才有明确归属。 如果还有外层父任务，也要保留关联。例如，外层任务是商品上新，而当前领域流程是商品资料核验。参数检查只是核验流程中的一个节点。接收方完成参数检查，不等于商品上新已经结束，更不等于所有内容可以直接发布。 这个区分还决定了结果应该交给谁。同一流程实例在同一时刻应由一个运行时主控推进，执行节点向这个主控回传。不能因为接收方看到了外层任务，就跳过领域主控，自己宣布整件事完成。 任务身份不需要写成一大段技术说明。关键是让接收方能回答：我正在为哪一次流程做哪一步？这一步的结果由谁接收？我的工作和外层目标是什么关系？这几个问题回答清楚，交接才有稳定的落点。 
“用之前的资料”是交接中很容易留下歧义的一句话。之前是哪一次？资料有没有更新？对方能否读取？如果这些条件没有说清，一份看似完整的任务，就可能建立在不同版本的事实之上。 资料可以直接作为任务输入，也可以提供当前工作区内能够读取的相对路径。无论采用哪种方式，都要说明本次应该使用哪些材料，以及每份材料承担什么作用。 例如，在商品参数核验这个假设任务中，商品资料可以提供业务描述，参数表可以作为逐项比对的对象。上游摘要帮助接收方快速理解问题，但涉及材质、尺寸和适用范围等具体结论，仍要能回到相应依据。 摘要负责帮助理解，事实来源负责支持判断。不能因为摘要写得顺，就把摘要中没有依据的判断当成已确认事实。接收方需要知道哪些信息已经确认，哪些只是待核实内容，哪些材料之间存在冲突。 如果两份资料对尺寸的描述不同，应把冲突作为输入状态交给下游，要求核对并标记。不能为了让交接显得完整，就在转交前随意选一个数字，更不能让下游凭经验把空白填上。 同样，材料无法读取也是一个需要说明的事实。文件缺失、路径不在当前工作区、当前执行者没有访问条件，都可能影响任务开始。此时应该返回缺失项与影响，不能默认去另一个Agent的目录搜索补料。 交资料也并非越多越好。整段聊天中可能混有讨论、旧版本、未采纳建议和不同任务的素材。把这些一并丢给接收方，会让它重新做一次筛选，却仍不清楚哪些结论已经确认。 更好的做法是围绕当前节点组织输入：给齐必需事实、对应依据、执行方法和判断标准，再把已知缺口单独写明。接收方看到的任务应当是可开始的工作单元，而不是需要重新解释的资料堆。 
“请负责写文案”，只说明了工作类型，还没有说明动作范围。 写在对话里、保存成文件、修改已有文件、上传素材、公开发布，是不同的动作。接收方可能具备执行这些动作的工具，却不能因此认为这些动作都在当前任务授权中。 继续用商品资料交接举例。如果主控只要求根据资料返回一份文案草稿，下游就应在这个范围内完成。即使整个上新流程最终需要上传和发布，也不能把最终目标倒推成当前节点已经获得了全部权限。 这里最容易混淆的是“后面需要做”和“现在允许做”。流程可以定义未来存在发布节点，但发布仍要满足相应授权和审核条件。当前写作节点完成，只代表可以提交写作结果。 授权也不能在转交过程中自然变大。上游只拿到草稿权限，转交给下游时依旧只有草稿权限。多经过一层主控，或者换一个工具，都不会产生额外的发布授权。 交接时，应把允许读取的材料、允许写入的位置、能否修改原件，以及是否包含上传发布逐项说明。范围明确，接收方才知道哪些动作可以直接完成，哪些动作需要交回主控处理。 这并不意味着每做一步都要重新问一次。已经清楚授权的动作，按既定范围完成即可。需要进一步确认的是范围之外的新动作，而不是把已经允许的执行反复交回真人。 在假设的参数核验任务中，“只在对话返回核验结果，不修改原资料”就能划出清晰边界。接收方发现参数冲突，可以列明依据和待确认内容；它不能因为自己认为某份资料更可信，就直接替换主文件中的参数。 授权写清，还有助于解释为什么某件事暂时没有做。主控收到的应是“核验已完成，原资料未改动，冲突等待确认”，而不是一份看不出执行范围的笼统完成通知。 
“质量高一点”“认真核对”“保证准确”，都表达了期待，却不足以成为验收标准。接收方无法据此判断哪些项必须做，主控也难以据此区分工作已经完成还是只完成了一部分。 一个更具体的商品参数核验要求，可以是：核对材质、尺寸与适用范围；每项结论说明依据；不同资料之间的冲突单独列出；无法确认的内容标记待确认。 这些要求的价值，不在于语言更加正式，而在于能够逐项核对。下游知道要检查什么，主控知道要接收什么，遗漏也能被明确指出。 完成不等于把空白填满。如果输入资料确实缺少适用范围的依据，合格的核验结果可以是“该项无法确认，需要补充资料”。相反，交出一份每格都有内容、却混入推测的报告，并不符合事实核验要求。 标准还应说明产物的形式。只需要在对话交稿，就直接返回正文；已经授权保存，则按要求提供文件与相对路径。没有必要为了显得工作完整，额外创建任务没有要求的文件。 对于主控来说，验收时也应沿用开工前交代的标准。如果原要求只是核验三项参数，就先判断这三项是否有依据、冲突是否列明、未知是否标记。不能在结果返回后，临时把完整文案策划或页面制作算进本节点的未完成项。 发现遗漏，应指出具体缺哪一项、缺哪类依据、补充到什么程度，而不是笼统退回“再完善一下”。清晰的退回要求，实际上也是下一次交接，需要继续遵守相同的输入、授权和验收边界。 当标准能够提前说清，执行者就能自查，主控也能稳定验收。双方讨论的会是同一份工作，而不是各自心里想象的“应该做到”。 交接不是把任务发出去就结束。下游如何返回结果，决定主控能否继续推进流程。 只回“完成”有一个明显问题：主控不知道完成了什么。材料是否齐全？检查了哪些项目？结果存在哪里？有没有遗留冲突？如果仍要重新追问，主控其实还没有拿到可用于下一步判断的信息。 一次成功回传，应说明当前状态、主要结论、正文或产物、已做验证，以及仍需处理的问题。已授权保存时提供对应路径；未保存时直接返回需要接收的正文，不把不存在的文件写成已交付。 这里可以把“节点工作已经完成”和“下一步可以启动”分开看。假设参数核验已经按要求完成，但其中一项缺少依据。下游可以完成核验和缺口标记，主控却仍需判断是否补料，不能直接据此进入正式文案制作。 失败回传也要具体。缺资料，应指出缺哪项、影响哪个结论；执行出错，应说明失败位置和已完成部分；当前不能安全继续，应交代恢复需要什么条件。 例如，“尺寸核验没有完成”仍然不够清楚。如果能说明“本次两份资料尺寸不一致，尚无确认依据；材质与适用范围已核对，需主控确认尺寸来源后继续”，主控就能够决定把问题退给谁，而不必让所有环节从头再来。 下游的职责是把事实和影响交清，主控的职责是根据回传选择继续、退回、补料或请求真人处理。两者分工明确，异常才不会变成执行者自行扩大权限的理由。 回传中保留任务身份也同样必要。一份结论写得再好，如果缺少实例和节点关联，仍可能归入错误的批次。任务从主控发出，再带着清晰结果回到主控，才构成一次能接续的交接。 
下面仍是用于说明机制的假设示例，不代表真实客户项目或已经运行的系统成果。设定任务为商品A资料核验流程中的参数检查，只要求对话交稿，可以这样交接： 任务身份：本次属于商品A资料核验流程，执行参数检查节点，由该流程主控统一接收结果；如有外层上新父任务，保留对应关联。 输入资料：使用本次提供的商品资料和参数表。上游已确认项与待核实项分别标明，具体结论需指向对应依据。 授权范围：读取所附材料，只在对话返回核验结果。不修改原资料，不保存额外文件，不上传或发布。 验收标准：核对材质、尺寸与适用范围，每项说明依据。冲突和缺失标记待确认，不自行补写。 回传要求：返回已核验项、异常项、主要结论及继续处理需要补充的资料；无法继续时说明影响和恢复条件。 这份交接没有要求接收方理解整个企业的所有背景，也没有把完整上新流程都塞给它。它只把当前节点必需的事实、动作和完成条件组织起来。 接收方可以据此开始检查，遇到没有依据的参数也知道应怎样处理。主控拿到结果后，可以沿原标准验收，再决定下一步。交接真正节省的，是双方不断猜测彼此意图的成本。 如果将来这个节点改为允许保存核验报告，就应同步改写产物位置和保存授权；如果仍不允许上传，上传边界继续保留。任务包要反映这一次真实授权，不能因为模板里有某个动作，就默认执行。 企业不必一开始就设计所有岗位之间的交接。可以先选一个经常发生、边界相对清楚的节点，把五项要求写下来，再通过两类任务检查是否有效。 1.用资料齐全的任务试走。 观察接收方能否只凭当前交接开工，是否还在追问任务归属、材料版本或交付方式。主控拿回结果后，能否按原先标准验收，而不需要重新解释一遍目标。 2.用缺少关键资料的任务试走。 观察接收方能否识别缺口、标明影响并回传，是否擅自补写事实，是否把未完成核验包装成全部完成。再看主控能否根据这些信息找到恢复位置，而不是只能要求整体重做。 正常任务检查输入和执行是否接得上，缺资料任务检查边界和异常是否说得清。两类都能说明问题，不能只凭一次顺利完成，就认定整条协作已经稳定。 如果试走中反复追问同一项信息，先回看交接要求是否漏写。如果结果总是难以验收，先检查标准是否具体。如果接收方越过范围执行，先检查授权是否传清。把问题落到对应信息上，比单纯要求Agent“更聪明”更容易改进。 
多Agent协作需要能持续接续的工作关系。交接给出了这种关系最具体的起点：让执行者知道从哪里开始、在哪里停下，让主控知道结果凭什么成立、下一步还缺什么。 先把一个交接点说清，保留试走中的问题，再逐步完善。老梁AI电商，专注帮电商企业建立可落地的 AI 能力体系——从 AI 内容生产到私有知识库、岗位 Agent。企业的协作能力，就在这些能够交出去、接回来、验得清的具体工作中逐步建立。
老梁AI电商：工作交给下一个Agent，先交清这五项信息
一、任务身份：先说明这是哪一次工作
二、输入资料：把事实和待确认项分开交
三、授权范围：把允许的动作传到底
四、验收标准：在开工前定义完成条件
五、回传要求：让主控据此决定下一步
六、把五项要求放进一份交接
七、别只看正常任务，再用缺资料任务试一次
