你问DeepSeek一句话以后，AI到底做了什么？

你有没有想过，当你和DeepSeek对话时，它到底是怎么听懂你的？

比如你问：

北京到上海有多远？

几秒钟以后，AI给出一个答案。你接着问：

坐高铁呢？

你没有再说一遍北京和上海，它通常也知道你还在问同一段路程。

如果你继续说：

预算1500元，帮我安排一下。

这次，AI面对的已经不只是一个距离问题。它需要弄清日期，查找合适的交通方案，还要考虑到达时间和预算。

AI是如何像人一样处理这些复杂问题的呢？

看完这篇文章，你就能理解：一句话发出去以后，AI是怎样听懂你的意思，又是怎样一步步完成任务。

这也是作为AI产品经理，必须了解的核心知识。

下面借这段和AI的对话，来看看AI产品处理任务的一种典型方式。

一、最简单的场景

我们先看“北京到上海有多远”。

为了方便理解，可以把这次问答压缩成三个动作：

第一，AI产品收到你的问题。

第二，系统把问题和其他必要的信息一起发给大模型。

第三，大模型生成回答，系统再把结果展示给你。

第一步很好理解：聊天框收到的原始输入，就是用户刚刚打出的这句话。

第二步，AI产品会准备本轮要发给大模型的信息。除了用户的问题，还可能包括话术要求，例如使用中文回答、表达尽量简洁。系统把这些内容组装在一起，再一次性交给模型。

第三步，大模型读取这些信息，判断用户“正在询问北京与上海之间的距离”，再根据已有知识组织回答。AI产品接收大模型生成的文字，把它显示在聊天框里。

这三个动作里，最容易被忽略的是第二步。大模型这一轮能根据什么回答，取决于系统这一轮给了它什么。你电脑里存着、心里想着，却没有通过系统提供给它的内容，大模型不会凭空知道。

解决办法，是在每次调用大模型以前，由系统主动准备“这一次回答需要知道的信息”。

第一次回答时，系统准备的内容可能只有：

北京到上海有多远？

用户接着问“坐高铁呢”，系统就要多准备一项：

坐高铁呢？

产品经理需要根据任务场景定义：哪些信息每次都要带给模型？哪些信息只有满足条件时才加载？缺少什么信息就必须追问？

系统按照这份规则准备模型输入，模型才有机会知道“它该知道的信息”，然后才有可能给出正确的答案。

你是不是已经开始产生疑问了？比如，AI如何才能判断“缺少了信息”？没关系，接下来一一给你讲解清楚。

二、如何补上“用户省略掉的信息”

第二次对话时，系统需要把“北京到上海”这个讨论对象和“坐高铁呢”这个新问题一起告诉给模型。

如果模型只看到“坐高铁呢”，这句话的意思并不完整：坐高铁去哪里？问的是距离、时间还是价格？

系统补入“北京到上海有多远”以后，模型就不用再猜目的地了。它可能判断你想了解坐高铁需要多久，也可能认为你在问票价。如果仍然无法确定，系统就应该继续追问。

这些为了理解问题而需要提供给模型的信息，其实就是“上下文”。

你可以简单理解为：AI处理眼前这句话时，系统提供给它的相关信息。

上下文不等于你们聊过的所有内容。对话很长时，系统这一轮可能只选择最近几轮提供给模型，也可能把更早的内容整理成一份更短的摘要，再提供给模型。后一种做法通常叫“上下文压缩”。

所以，AI有时能接住你省略了很多信息的追问，有时又会突然弄错“那个”“第二个”指什么。模型的理解能力会影响结果，系统有没有提供正确的前情也会影响结果。

产品要减少这类错误，通常需要做三件事：

第一，暂时保存当前正在讨论的对象，例如“北京→上海”。这类服务于当前对话的信息，就是最基础的“短期记忆”。

第二，优先把与当前问题有关的历史内容加载给模型。

例如，用户问“坐高铁呢”时，系统需要加载“北京到上海”这个讨论对象，却不需要加载更早聊过的天气或餐厅，这就叫“上下文加载”。

第三，“那个”可能对应多个对象时，要求AI先追问，不要自行猜测。

产品经理需要定义的，也正是这三类规则：哪些信息应该暂时记住，当前步骤应该加载什么，歧义达到什么程度必须追问。

这也是设计Agent产品非常关键的一步。

三、如何让AI处理任务

你继续说：

预算1500元，帮我安排一下。

前两轮只需要回答问题。这一轮，用户希望AI帮忙安排出差。

AI先要从这句话里弄清几件事：从北京出发，周五上午到上海，预算1500元。它还会发现几个问题：“周五”到底是哪一天？上午几点前到？预算是否包含住宿？

如果日期不明确，系统就不应该直接查询车次。比较合理的下一步，是先问：

1500元只包含交通，还是也包含住宿？

用户补充具体日期、最晚到达时间，并说明预算只算交通以后，AI才获得了继续安排所需的必要信息。

AI理解用户想做什么以后，还要判断当前信息够不够。缺少关键信息就先追问，信息已经足够才继续行动。

对于AI产品经理来说，这里有一个关键问题：系统怎样知道信息够不够？

在“安排出差”这种必需信息比较明确的任务中，我们需要定义任务必须具备哪些信息。这些需要逐项收集的信息，通常叫任务字段，也常被称为“槽位”。

以当前任务为例，我们需要让系统填充以下槽位：

最晚到达时间（必填项）是：

在和用户沟通的过程中，系统可以让模型从原话里提取这些字段，然后，系统把已经拿到的信息和槽位必填项进行比较，发现出发日期（必填项）和最晚到达时间（必填项）还不明确。

此时，系统还不会开始查询车次，而会先追问缺失信息。用户回答以后，系统更新对应字段，再判断是否已经满足查询条件。

对产品经理来说，可以把它简单理解成一张随对话不断更新的任务记录：日期确认了吗？出发地和目的地确认了吗？没有这张记录，AI就很难收集到完成任务所需的信息。

四、信息够了，AI还要决定下一步做什么

日期、出发地、目的地和到达时间都已经明确后，系统也要进入下一步：查询符合条件的交通方案。

此时，可能会出现多种情况，比如：

1）如果用户确认条件不变，系统就开始查询交通方案。

2）如果用户临时说“改成下周五”，系统先更新出发日期，再检查信息是否完整。

3）如果用户说“先不查了”，系统就停止当前任务，不再调用查询工具。

不同情况对应不同的下一步，系统需要根据眼前的情况作出选择。

系统根据当前情况安排下一步动作，这个过程通常叫“编排”。

如果你觉得这个词太专业，可以想象人是怎么处理一件事情：先看事情进行到哪里，再决定接下来查信息、问别人，还是直接执行。

“编排”的第一种做法，是产品和研发提前把每一步写好：日期不明确就追问；信息齐全就查询；用户选好方案就进入订单确认。这种方式通常叫Workflow。

Workflow并不一定只有一条直线，它也可以包含条件分支、循环、暂停和恢复。只是这些主要路径和处理规则，通常需要提前定义。

Workflow的好处是下一步比较确定。可一旦用户临时改时间、换预算，或者插入一个新要求，产品和研发就要继续增加分支。

“编排”的另一种做法，是系统先看任务进行到哪里、用户刚说了什么，再从“追问、查询、比较方案、请求确认”等动作中选择下一步。这种方式叫“动态编排”。

动态编排能接住更多变化，但模型也可能选错。因此，系统不能让模型想做什么就做什么，产品经理仍然要规定它可以选择哪些动作，哪些动作必须再次确认。

实际设计中，两种方式可以结合。系统先结合用户意图和当前任务状态，通过动态编排决定下一步是继续查询、修改条件，还是取消任务；一旦涉及提交订单、付款或权限校验等高风险动作，则进入预先定义的Workflow，按照固定规则完成检查和确认。

假设，在这次出差任务里，系统确认信息已经齐全，于是决定开始查询交通方案。

五、决定查询车次以后，系统才知道该准备什么

系统决定查询交通方案后，需要把具体日期、出发地、目的地和最晚到达时间发送给查询工具。

根据当前动作准备必要信息，就是前面提到过的“上下文加载”。第二轮对话时，系统加载的是“北京到上海”这个讨论对象；现在准备查询时，系统加载的是完成查询所需的条件。

为了方便理解，这篇文章采用广义的“上下文加载”：既包括给模型准备相关信息，也包括给工具准备执行所需的数据。在更严格的技术表述中，后者也常被称为“工具参数准备”。

产品经理可以为每个关键动作设计一张“信息清单”，写清楚四件事：需要哪些信息；从哪里读取；交给模型还是工具；信息缺失时怎么办。

例如，查询交通方案需要日期、出发地、目的地和最晚到达时间。日期缺失就继续追问。

开发人员按照这张清单实现读取和检查。系统每次查询前自动准备信息，必需条件齐全才调用工具。这就是“上下文加载”最核心的逻辑。

为什么需要通过“查询工具”来完成“查询交通方案”的任务呢？

因为大模型擅长理解要求和比较方案，查询工具负责获取实时车次、票价和余票。没有工具，大模型就只能提供一般建议，无法保证实时信息准确。

顺便说一句，“成熟工具”也是SaaS公司相对于原生AI公司最大的护城河。

六、AI给出三个方案，你只说“第二个可以”

查询工具返回候选结果以后，系统筛选出三个候选的交通方案并展示给你。任务随即进入“等待用户选择方案”的阶段。

你看完三个候选方案以后回复：

第二个可以

系统此时保存着两个关键信息：

当前等待事项是“等待用户选择交通方案”。

这就是前面提到的“短期记忆”。

模型同时看到这两项信息和用户回复“第二个可以”，就有机会把“第二个”对应到方案2，把“可以”理解为接受这个方案。如果候选列表已经变化，或者“第二个”可能对应多个列表，系统就应该追问，不能继续猜。

产品经理还要定义哪些情况必须追问、哪些动作在信息不清楚时禁止执行，不能只靠一句提示词要求模型“谨慎”。

“等待用户选择方案”是一种任务状态。它记录事情进行到哪一步、用户已经确认什么、系统还在等待什么，也是短期记忆中的关键部分。

另外，产品经理还需要定义每个任务状态下允许执行什么。例如：

等待支付授权时，只有用户明确说“确认支付”，并通过必要校验，系统才能调用支付工具。

只有定义好行为边界，AI才不会胡乱执行。

七、工具执行以后，系统还要看结果

用户选择方案并完成必要确认以后，如果AI产品能够调用购票工具，系统就可以提交订单了。订单提交可能返回三种结果：成功、失败，或者暂时无法确定。

如果工具返回“出票成功”，系统记录订单编号并告诉用户任务完成；

失败时，说明原因并请用户更换方案。

网络中断可能让系统暂时不知道订单有没有提交成功，此时不能马上再买一次，否则可能生成重复订单。

为了让系统正确处理这些情况，产品经理需要提前定义异常规则：

结果无法确认时不得立即再次购票，系统要先查询订单状态，仍无法确认时转人工。

最后，工具执行完毕后，系统还要检查结果、更新进度，再决定是回复用户、换方案还是请求人工处理。

八、总结一下

总结一下整个对话，AI处理任务的过程是这样的：

回复用户，或者继续下一步

最开始的“北京到上海有多远”，只走过很短的一段：收到问题，交给模型，生成回答。

到了“坐高铁呢”这一轮，系统需要把“北京到上海”这个讨论对象一起提供给模型。

到了“帮我安排出差”，AI已经不只是在回答问题。它需要追问、查询、等待选择、确认授权、调用工具，还要根据执行结果继续处理。

能够根据当前情况选择动作、调用工具，并连续推进任务的AI系统，通常可以称为Agent。

九、这些能力怎样串成一个文章Agent

我最近设计文章Agent时，也使用了同一条任务主线。用户可能会对它说：“我刚补了一份访谈材料。把提纲第二部分改得口语一点，加入材料里的CRM案例，其他地方别动。”

刚才安排出差时出现的关键能力，可以完整放进这次文章修改任务：

回复用户

放进文章Agent以后，每个概念都有了具体分工：

短期记忆：负责保存当前文章、提纲版本、材料状态和等待事项。

编排：负责在允许的动作中决定先处理材料，还是向用户追问。

上下文加载：负责为当前步骤准备相关提纲、材料和修改要求，排除无关内容。

大模型：负责理解与生成。

工具：负责读取文件和保存版本。

这些组件不是各做各的。短期记忆提供当前进度，编排根据进度决定下一步，上下文加载为这一步准备信息，大模型或工具负责执行。执行结果经过检查后，又会写回短期记忆，成为下一轮判断的依据。

场景从安排出差换成修改文章，Agent推进任务的主线没有变化。

作为AI产品经理，在和AI对话时，可以观察四个问题：

第一，它知道事情已经做到哪里了吗？

第二，它知道下一步应该做什么吗？

第三，它拿到了完成这一步所需的信息吗？

第四，它执行以后，知道结果是什么、接下来是否还要继续吗？

对产品经理来说，这四个问题对应着一条完整的Agent任务链：保存当前进度、决定下一步、准备必要信息、执行并处理结果。这就是作为AI产品经理，必须了解的核心知识。

来源 | ToB老人家（ID：ToBlaorenjia）

作者 | 王戴明 ; 编辑 | 呼呼大睡

内容仅代表作者独立观点，不代表早读课立场