设计 Agent 之前，先弄清任务从哪里来

一、“采购 Agent”这个名字，还没有说明它要做什么

准备做一个采购 Agent，很容易开始讨论：接哪些系统，提供什么工具，要不要拆成询价、下单、催交几个子 Agent。

但这些设计需要先有一个依据：它准备承担哪部分工作，为什么需要这部分工作？

上一篇《当我们说“让 AI 帮人完成任务”，到底在说什么？》讨论了任务背后的目标。这一篇进一步放到企业里看：如果组织的功能、业务对象和运行规则能够被明确表达，任务的来源和边界就有机会被推导出来。

以一家零售企业为例。门店需要在指定时间备齐一批商品，采购只是满足这项需要的可能手段之一。究竟应该采购、跨店调拨，还是调整销售安排，需要结合当前情况判断。“采购 Agent”这个名称，已经提前选定了一部分解决方式。

二、从组织承担的功能，找到工作的来源

一个组织为什么存在，可以从它在价值网络中承担的功能理解。零售企业连接商品供应与消费者需求，门店承担本地销售和服务，供应保障环节则需要让合适的商品在需要时可用。

这是组织的生态位在具体业务中的展开：为谁提供什么价值，依赖哪些上游，又向下游作出什么承诺。

继续向内部拆，才会出现需求预测、库存管理、采购、配送等分工。它们共同服务于商品可用性，也受到资金占用、损耗和运输成本等约束。

这里的分析单位是分工环节承担的功能。当前由哪个部门、哪个岗位完成，可以另行安排。同一个功能可能由多人协作，也可能由人、传统系统和 Agent 共同承担。

“保障供应”是一项持续职能，“今天为某门店补足某商品”才是一项具体任务。两者之间，还需要当前业务情况。

三、目标与当前状态的差距，让任务具体化

假设门店周五的活动需要 100 件商品。当前可用库存有 20 件，另有 50 件已确认能在活动前到达，并且都可用于这次活动。那么，尚未覆盖的需求是 30 件。

这时可以识别出供应缺口，但还不能直接认定需要采购 30 件。附近门店是否有可调拨库存？供应商能否及时送达？新增费用是否值得？这些条件决定采用什么方案。

识别缺口之后，可以先形成核实信息、比较方案或请求决策的任务。处理方案确定后，再展开为发起调拨、补充采购等执行任务。每项任务的范围、时限和预期结果，都应当能追溯到这次业务需要。

任务也可能因变化而调整。原本确认到货的 50 件突然延期，缺口就需要重新计算；如果活动取消，相关任务也应重新检查，避免继续执行已经失去依据的工作。

任务是业务要求、当前状态和处理方案共同作用的结果。 它需要保留与这些依据的联系，才能随业务变化而更新。

这里的 gap，与产品需求中的 gap 有所不同：商品不足产生补货等业务任务；系统无法识别商品不足，则可能产生建设库存关联和缺口计算能力的产品任务。两者都需要明确目标与现状，但改变的对象不同。

四、落到对象，才能说清任务做到哪里

“跟进一下这批货”很容易被理解成发一条消息。消息发出之后，任务是否完成，却仍然不清楚。

如果任务是确认交期，预期结果应当是取得可追溯的交期确认，并更新对应订单。如果任务是处理供应缺口，仅取得一个无法满足活动时间的交期，还没有完成工作，需要继续选择其他方案。

同一个场景，可以形成不同边界的任务：

这些任务有的改变现实业务状态，有的补充事实，有的形成判断。它们都需要说明：针对哪个对象，要得到什么结果，用什么依据确认完成。

边界还决定了交接。负责确认交期的人发现延期，可以完成事实确认，同时把供应异常交给有责任处理的人。不能因为“询问已经完成”，就让上游的供应问题一起消失。

五、职责与授权，决定任务可以交给谁

明确任务之后，才能判断承接者需要什么能力，以及允许采取哪些行动。

采购人员可能负责跟进订单，但不能自行增加预算；门店负责人可以提出调拨申请，却不能直接占用其他门店的预留库存。管理责任和执行权限需要分别表达。

Agent 接入时也一样。如果 Agent 的授权只停留在“某个角色可以调用哪些工具或接口”，就很难表达它能对哪些具体对象、在什么状态和条件下采取行动，以及何时需要升级决策。角色权限需要进一步连接任务、对象和业务规则，才能形成实际可执行的授权边界。如果它负责确认交期，需要读取订单、联系供应商并记录确认结果；如果它还负责处理延期，就需要看到关联需求、比较方案，并知道自己可以在什么范围内执行。

一旦超出授权，例如需要增加费用或改变客户承诺，就应当找到相应的决策责任人。升级之后，任务也需要保留状态和处理结果，才能接续执行。

已有的职能与对象关系，还可以为系统配置提供共同依据：执行者看到自己负责的对象和待办，管理者看到责任范围内的汇总与异常；对象变化产生相关通知，超出授权的动作进入决策流程。

Agent 的工作边界，应当由它承接的任务、责任范围和授权共同定义。 工具清单是据此配置的实现条件。

六、数字孪生让任务有机会被持续推导

当上述定义进入数字孪生，就可以把持续职能与具体任务连接起来。

门店需求明确后，系统检查可用库存和预计到货，识别缺口；到货承诺变化后，重新分析影响；方案确定后，生成相应任务，并依据职责和权限分配；执行结果再更新业务状态，供下一轮判断使用。

其中有些环节可以按明确规则计算，有些需要预测、优化或 Agent 分析，也有些需要人作出决定。缺少事实或业务定义时，可以先形成核实与澄清任务。

这个过程也需要管理任务本身。相同异常不能每次检测都重复生成待办，原有任务覆盖了多少缺口需要可见；目标改变、问题已经解决时，相关任务需要更新或关闭。发现差距之后，还要结合影响、成本和资源决定是否处理。

这套推导的基础，是组织功能、业务要求、对象状态、规则和责任之间的关系。数字孪生将它们持续承载起来，才有机会让任务的产生、分配和评价逐步可计算。

由此再设计 Agent，问题就具体了：在这套持续运行的业务中，它承担哪部分判断与行动，需要什么环境支持，怎样知道自己完成了工作？