从 Gemini 的任务示例出发：AI 能否从知识中推导工作流？

从 Gemini 的任务示例出发：AI 能否从知识中推导工作流？

观察 Gemini Spark 的任务示例，例如整理文件、处理邮件、跟踪请求和安排后续工作，我一直在思考一个问题：

当用户只给出目标 时，AI 执行的步骤究竟从哪里来？

Google 将 Tasks、Skills 和 Schedules 作为组织执行能力的产品概念。这些能力让用户能够通过自然语言安排工作。但从技术实现的角度，还可以继续追问：

一个任务的分解方式，是开发者提前写好的？是模型参考类似经验生成的？还是系统能够依据知识中的依赖关系，自行推导出来？

这里讨论的三种路径，是我对任务规划架构的分析，并不代表 Gemini 已公开的内部实现。它们也与我目前探索的企业知识系统路线直接相关：如何让知识逐步支撑任务分解、执行能力装配，以及结果验证。

一、自然语言之后，仍然需要任务分解

用户可以用一句话描述目标：

在目标计算机上安装 Tomcat，让指定应用能够正常访问。

但执行系统需要解决一系列具体问题：

• 目标主机是什么操作系统？

• 应用与 Tomcat、Java 环境有哪些兼容要求？

• 机器是否已经具备满足要求的运行环境？

• 安装位置、权限和配置如何确定？

• 如何判断部署已经成功？

这些问题没有被自然语言界面消除，只是从用户面前转移到了系统内部。

从项目管理角度，可以用 WBS------工作分解结构------组织需要完成的工作。但进入自动化执行阶段，还必须补充工作项之间的依赖、输入输出、前置条件和验收标准。

能够理解目标，只是起点。执行系统还需要把目标变成一组有依据、可操作、可验证的工作。

我认为，这个过程至少有三种实现路径。

二、第一条路径：基于任务模板进行分解

最直接的方式，是提前整理任务模板。

例如，"部署某类应用"对应一套流程结构：

检查环境、准备依赖、部署文件、修改配置、启动服务、检查结果。

用户提供目标后，系统识别任务类型，填入参数，再根据条件选择分支。

模板可以包含：

内容	作用
适用范围	判断任务是否符合模板条件
输入参数	指定主机、版本、路径等信息
前置条件	判断是否允许开始执行
条件分支	处理环境差异
验证规则	判断工作项是否完成
异常处理	定义失败后的处理方式

这种方式的优势非常明确：结构稳定、执行速度快，容易进行测试和审核。

对于重复频率高、环境边界清晰的任务，模板通常很有效。

它的局限在于适用范围。当目标环境或用户要求偏离既有条件时，系统需要判断：模板还能否使用？应该修改哪个部分？缺失的步骤如何补充？

如果这些判断仍然全部依赖人工维护，模板数量与维护负担就可能随场景增加而扩大。

三、第二条路径：基于经验和世界知识生成方案

另一种方式，是让模型参考已有案例、行业惯例和专家经验，提出任务分解。

人处理很多工作时，也采用这种方式：

"类似情况以前做过，可以先按照那个方案尝试。"

这条路径比固定模板更灵活。模型可以根据任务描述调整步骤，也能够对部分没有明确模板的场景提出候选方案。

但需要注意：

一个方案符合常见经验，并不意味着它在当前环境中成立。

以部署任务为例，模型可能生成一套看起来完整的流程，却没有检查目标主机已有的运行环境，或者忽略了应用本身的兼容要求。

此外，"最合理的方案"必须对应具体评价标准。

最快完成、最低成本、最小变更、最容易维护，可能分别对应不同方案。系统需要知道用户的约束和优先级，才能作出选择。

因此，经验知识适合提供候选路径，但候选路径仍然需要经过条件核对。

四、第三条路径：从知识中的依赖关系推导任务分解

这是我目前重点探索的方向。

假设系统没有保存一份完整的"当前环境下安装 Tomcat"的流程，但掌握了以下知识：

• 所选 Tomcat 版本对 Java 运行环境有要求；

• 应用对运行环境可能有额外约束；

• 服务启动需要必要的配置与权限；

• 应用可访问，需要部署、服务和访问路径等条件同时成立。

这些知识可能分别存在于安装指南、兼容说明、应用文档和运维资料中。

系统可以从目标开始，逐步反推：

要让应用正常访问，需要哪些条件成立？

每个条件，又依赖哪些前提？

当前机器已经满足哪些前提？

哪些条件需要通过操作建立？

这样形成的规划过程是：

目标状态 → 必要条件 → 当前状态核对 → 缺失条件 → 实现动作 → 结果验证。

这里有一个重要区别：

从"Tomcat 需要兼容的 Java 环境"，不能直接推出"必须下载并安装一个 JDK"。

系统还需要确认当前机器是否已经具备满足要求的环境，以及目标任务具体需要什么。

如果条件已经成立，就可以跳过对应动作。

知识给出条件，环境探测给出事实，两者之间的差额决定需要执行哪些工作。

完整流程因此可以由多处知识共同支撑，而不要求它事先以完整操作手册的形式存在。

五、三条路径的区别，在于如何使用知识

三种路径都依赖知识，边界也并非绝对。

文档可以包含经验案例；员工经验经过整理，也可以形成严格的前置条件与依赖关系。

真正值得区分的是：

路径	系统主要做什么
模板分解	取出已有结构，填参数并选择分支
经验规划	参考相似做法，生成候选方案
依赖推理	根据条件与关系，重新构造任务结构

因此，第三种路径不能仅靠增加文档数量实现。

如果检索只返回几段相关文字，却没有保留其中的适用范围、条件、依赖和结果，系统仍然很难形成可靠规划。

企业知识系统需要回答的不只是"这段资料与问题是否相关"，还包括：

• 这条要求适用于哪个版本和场景？

• 它是必要条件，还是一种推荐做法？

• 哪个动作能够建立这个条件？

• 动作完成后，可以观察到什么结果？

• 支撑这一判断的来源是什么？

知识的组织方式，会直接影响任务分解的质量。

六、知识推理较慢，如何形成可复用能力？

相比直接读取模板，从依赖关系出发进行推理，可能需要更多检索、条件判断和环境检查。

但这并不意味着，每次执行都要从头推导。

我更倾向于形成以下循环：

推导方案 → 执行 → 验证 → 保存适用条件与证据 → 后续复用。

一次任务成功后，系统应该保存的不只是操作顺序，还包括：

• 方案适用的条件；

• 当时确认的环境状态；

• 关键决策的依据；

• 可以跳过的工作项；

• 每项操作的验证方式；

• 失败和恢复记录；

• 后续复用前需要重新检查的条件。

下一次遇到类似目标，系统可以先检查已有方案是否适用。对于变化的部分，再进行针对性推理。

这意味着：

任务模板可以成为经过验证的推理结果。

模板不必全部依靠人工提前编写，也可以随着执行经验逐步沉淀。

不过，一次成功只能证明方案在当时条件下有效。要扩大适用范围，仍然需要新的验证，不能直接把个别成功提升为普遍规则。

七、WBS 之后，是执行能力的选择与装配

完成任务分解后，下一步是将工作项映射到具体执行能力。

但"安装运行环境"这样的工作项，还不足以直接执行。系统至少需要明确：

信息	需要回答的问题
输入	操作哪台机器，使用哪些参数？
前置条件	当前是否具备执行条件？
预期效果	完成后应该改变什么状态？
权限边界	允许访问和修改哪些资源？
验证方法	如何证明操作达到目标？
失败处理	重试、恢复、换方案还是请求协助？

这些信息清楚以后，才能选择适当的 API、脚本、浏览器操作或 Agent。

我不认为每个工作项都需要一个独立 Agent。

已有稳定 API 或确定性脚本能够完成的动作，可以直接调用。需要理解变化、选择策略和处理不确定性的部分，再交给 Agent。

因此，"Agent 装配"更准确地说，是依据任务要求进行执行能力装配。

如果现有能力不足，也可以尝试生成新的脚本或工具，但生成后仍然需要检查与验证，不能因为它来自 AI 就省略工程约束。

八、我目前探索的路线

我希望连接的是这样一条链路：

企业知识 → 目标推理 → 任务分解 → 执行能力装配 → 执行证据 → 复用与修正。

这条路线有几个明确的研究问题。

首先，如何从分散文档中保留足够完整的条件与依赖，避免只提取出孤立的操作片段？

其次，如何区分已知事实、推理结论和待验证假设，防止模型把合理猜测当成执行依据？

再次，如何在执行中更新任务计划？有些条件只能通过现场检查获知，初始 WBS 需要保留调整空间。

最后，如何沉淀成功经验，同时限制它的适用范围，让系统逐步提高效率，而不是不断积累未经验证的流程？

这些问题也说明：收集更多知识很重要，但知识规模本身不能保证任意目标都能被可靠分解。

目标可能不明确，约束可能冲突，环境也可能发生变化。系统必须具备识别这些情况并作出响应的能力。

Gemini Spark 的任务示例，让我们看到自然语言委托正在成为一种产品交互方式。对企业系统而言，我更关注这背后的下一步：

有多少原本需要人工完成的工作流设计，能够成为知识推理的产物，并通过实际执行得到验证？

这正是我目前希望持续探索的方向。