Context Engineering 实战：为什么没有上下文的 AI 会生成不可用的 Kestra 工作流（LLM Zoomcamp 2026）-迪斯科星球

Context Engineering 实战：为什么没有上下文的 AI 会生成不可用的 Kestra 工作流（LLM Zoomcamp 2026）

【免费下载链接】llm-zoomcampLLM Zoomcamp - a free online course about real-life applications of LLMs. In 10 weeks you will learn how to build an AI system that answers questions about your knowledge base. Register here 👇🏼项目地址: https://gitcode.com/GitHub_Trending/ll/llm-zoomcamp

上下文工程（Context Engineering）是本课程 03-orchestration 模块中理解 AI 可靠性的起点：大模型只在训练截止时间之前"见过"世界，而 Kestra 这样的开源编排平台每天都在演进，插件类型、属性名与最佳实践不断变化。读完本文，你将通过一个可复现的对照实验，掌握"为什么泛化 AI 助手会生成过时甚至虚构的 Kestra 工作流"的底层原因，并理解 Kestra 如何通过上下文注入（RAG、AI Copilot）把不可信的猜测变成可信的生产代码——这正是后续 RAG 工作流与 AI Copilot 两课的理论根基。

一、对照实验：让 ChatGPT 在没有上下文的情况下生成 Kestra 工作流

本模块的核心论点来自一个任何人都能复现的简单实验。文档给出的实验步骤如下：

在隐私浏览窗口中打开 ChatGPT（关键前提：避免携带任何历史对话上下文）；

输入以下提示词：

Create a Kestra flow that loads NYC taxi data from a CSV file to BigQuery. The flow should extract data, upload to GCS, and load to BigQuery.

观察输出结果。

实验结论非常明确：ChatGPT确实会生成一个看起来结构完整的 Kestra 工作流，但其中大概率包含三类问题：

过时的插件语法：使用了已被重命名或废弃的旧任务类型（例如io.kestra.plugin.core.http.Download这类当前插件命名空间之外的写法）；
不存在的属性名：引用了当前版本中并不存在的配置字段；
幻觉出来的功能：包括从未存在过的任务、触发器或属性。

本模块的真实演示流 1_chat_without_rag.yaml 用同一思路印证了这一点：它直接向 Gemini 提问 "Which features were released in Kestra 1.1?"，并明确要求列出至少 5 个主要特性，但不注入任何检索到的上下文。执行结果的日志提示我们注意响应中可能出现的三种症状：回答不正确、回答含糊笼统、以及"列出的特性其实是很久以前就发布的，而不是这个版本新增的"。

❌ Response WITHOUT RAG (no retrieved context): {{ outputs.chat_without_rag.textOutput }} 🤔 Did you notice that this response seems to be: - Incorrect? - Vague/generic? - Listing features that haven't been added in exactly this version but rather a long time ago?

提示：这两个演示流使用 Gemini 作为 AI 提供方，需要在 Kestra 中配置{{ secret('GEMINI_API_KEY') }}。完整的密钥配置方法见环境搭建指南。

二、为什么会这样：训练截止时间是模型的"出生日期"

实验结果的根源不在 Kestra 本身，而在大语言模型的基本特性上。文档明确指出：

像 GPT 这样的大语言模型，训练数据只覆盖到某个特定时间点为止。它们不会自动知道：软件的更新和新版本、被重命名或变更 API 的插件、你所在组织的新最佳实践、以及针对你基础设施的特定配置。

这被称为训练截止时间（training cutoff）。模型中"内置的知识"有明确的时效边界——例如对某个主流模型而言，其内置知识可能只截止到某年某月，之后发布的版本、插件和 API 变更它一概不知。ChatGPT 自己也承认这一点：当被问及"你的训练日期截止到什么时候"时，它的回答是内置知识只覆盖到某个时间点，并提示可以用实时网络搜索获取更新的信息。

这带来一个更深层的推论：模型只能使用它能够访问到的信息工作。当用户询问 "Kestra 1.1 发布了哪些功能" 或要求生成 "加载 NYC 出租车数据到 BigQuery" 的流程时，模型能依据的只有训练语料——其中可能包含旧版 Kestra 的语法、其他平台的工作流模式，甚至完全不存在的内容。这就是幻觉的机制：模型不是"撒谎"，而是在没有足够证据时进行概率性补全，而补全的结果恰好停留在某个历史快照上。

三、上下文就是一切：从"猜测"到"可信"的分水岭

将两个结果并排对比，本模块的核心结论就非常清晰了：

没有上下文：通用 AI 助手会幻觉出过时或错误的代码，这种输出无法信任用于生产环境；
有上下文：AI 生成准确、最新、可直接迭代的生产级代码。

同一个原则适用于所有场景——无论是生成工作流，还是基于自己的数据回答问题。关键差别不在于模型能力，而在于生成时模型被提供了什么。

在 Kestra 的生态中，这一原则具体化为三种上下文注入手段，也是本模块后续课程的主线：

手段	解决的问题	对应课程
AI Copilot	为"生成工作流"注入当前插件文档、合法属性名与最佳实践	04-ai-copilot.md
静态 RAG	为"回答知识库问题"注入你 ingest 的文档向量	05-rag.md
Web Search RAG	为"回答时效性问题"注入实时检索结果	05-rag.md

四、在仓库中验证：同一问题，有无上下文的代码级对比

上下文工程不是抽象口号，本模块的 flows 目录提供了可直接运行的对照实验。

4.1 无上下文基线：`1_chat_without_rag.yaml`

tasks: - id: chat_without_rag type: io.kestra.plugin.ai.completion.ChatCompletion description: Query about Kestra 1.1 features WITHOUT RAG provider: type: io.kestra.plugin.ai.provider.GoogleGemini modelName: gemini-2.5-flash apiKey: "{{ secret('GEMINI_API_KEY') }}" messages: - type: USER content: | Which features were released in Kestra 1.1? Please list at least 5 major features with brief descriptions.

这个 flow 只做一件事：把用户问题原样交给 LLM，不携带任何外部资料。模型的回答完全依赖其训练数据中的 Kestra 认知，因此很可能含糊或过时。

4.2 有上下文对照：`2_chat_with_rag.yaml`

tasks: - id: ingest_release_notes type: io.kestra.plugin.ai.rag.IngestDocument description: Ingest Kestra 1.1 release notes to create embeddings provider: type: io.kestra.plugin.ai.provider.GoogleGemini modelName: gemini-embedding-001 apiKey: "{{ secret('GEMINI_API_KEY') }}" embeddings: type: io.kestra.plugin.ai.embeddings.KestraKVStore drop: true fromExternalURLs: - https://raw.githubusercontent.com/kestra-io/docs/refs/heads/main/src/contents/blogs/release-1-1/index.md - id: chat_with_rag type: io.kestra.plugin.ai.rag.ChatCompletion ... systemMessage: | You are a helpful assistant that answers questions about Kestra. Use the provided documentation to give accurate, specific answers. If you don't find the information in the context, say so. prompt: | Which features were released in Kestra 1.1? Please list at least 5 major features with brief descriptions.

与 4.1 相比，这里多了两个关键动作：

摄取（Ingest）：IngestDocument从 Kestra 官方 1.1 发布说明文档 URL 拉取内容，用gemini-embedding-001生成向量，存入 Kestra 的 KV Store（drop: true表示每次重跑先清空再写入）；
带上下文问答：ChatCompletion同时配置了chatProvider（负责生成回答）与embeddingProvider+embeddings（负责把用户问题向量化并检索最相似的文档片段），并将检索结果拼入提示词。

注意systemMessage中的一句关键指令："如果上下文里找不到相关信息，请直说（say so）"——这是上下文工程的经典技巧：允许模型承认无知，而不是强行编造。

4.3 进一步延伸：`3_rag_with_websearch.yaml`

tasks: - id: chat_with_rag_and_websearch_content_retriever type: io.kestra.plugin.ai.rag.ChatCompletion chatProvider: type: io.kestra.plugin.ai.provider.OpenAI apiKey: "{{ secret('OPENAI_API_KEY') }}" modelName: gpt-5-mini contentRetrievers: - type: io.kestra.plugin.ai.retriever.TavilyWebSearch apiKey: "{{ secret('TAVILY_API_KEY') }}" systemMessage: You are a helpful assistant that can answer questions about Kestra. prompt: What is the latest release of Kestra?

这个 flow 把"上下文"的来源从静态文档换成了实时网络搜索：通过TavilyWebSearch检索器在查询时抓取实时结果注入提示词，无需任何 ingest 步骤。它适合回答"最新版本是什么"这类变化速度超过重新摄取频率的问题。代价是结果质量取决于搜索引擎本身，检索到的上下文可能不相关或不准确——课程文档特别提醒：使用 web search RAG 时必须测试检索上下文的质量。两种 RAG 的取舍（静态 vs. 实时）在 05-rag.md 中有完整对比。

运行以上三个 flow 前，请先完成环境搭建中的密钥配置：

export GEMINI_API_KEY="your-gemini-api-key-here" # required export SECRET_GEMINI_API_KEY=$(echo -n $GEMINI_API_KEY | base64) # required export SECRET_OPENAI_API_KEY=$(echo -n "your-openai-api-key-here" | base64) # required for flow 3 export SECRET_TAVILY_API_KEY=$(echo -n "your-tavily-api-key-here" | base64) # required for flow 3 docker compose up -d

五、把上下文工程落到生成环节：Kestra AI Copilot

如果说不带上下文的 LLM 是"凭记忆答题"，那么 Kestra 的 AI Copilot 就是"带着当前版本文档答题"。课程文档指出，AI Copilot 之所以可靠，是因为它基于你正在运行的 Kestra 版本所对应的当前插件文档、合法属性名与最佳实践生成流程——而不是像通用 AI 助手那样猜测。

在 Flow Editor 右上角点击 AI Copilot 按钮（✨ 图标），输入与第一节实验中完全相同的提示词：

Create a Kestra flow that loads NYC taxi data from a CSV file to BigQuery. The flow should extract data, upload to GCS, and load to BigQuery.

结果与裸 ChatGPT 形成鲜明对比：Copilot 生成的 YAML 使用正确的任务类型（如io.kestra.plugin.core.http.Download下载 CSV、io.kestra.plugin.gcp.gcs.Upload上传 GCS、io.kestra.plugin.gcp.bigquery.Load加载 BigQuery）、合法的属性名，且是可执行的完整流程——同时它还会把不确定的假设（如 GCS 桶名、服务账号密钥）以注释形式标注出来，供你确认。

这就是"上下文工程"在代码生成场景的完整闭环：先诊断无上下文时模型会如何失败（本课），再用 AI Copilot 将官方文档注入生成过程（下一课），最后用 RAG 将你自己的数据注入问答过程（再下一课）。三者的共同底层逻辑只有一句话：上下文就是一切。

六、要点回顾

可复现的诊断实验：在隐私窗口用同一提示词询问通用 AI 助手，观察其输出中的过时语法、错误属性名与幻觉功能；
根本原因：大模型的训练截止时间决定了它无法知道训练之后的插件变更、版本演进与组织最佳实践；
通用结论：上下文质量直接决定 AI 输出的可信度，无上下文不可用于生产，有上下文可快速迭代；
模块内的验证路径：依次运行 1_chat_without_rag.yaml、2_chat_with_rag.yaml 与 3_rag_with_websearch.yaml 三个 flow，用同一问题的三种回答质量直观理解上下文的作用；
进阶方向：本课是整个 03-orchestration 模块的理论基石，后续将围绕"AI Copilot 生成流"、"RAG 接地"、"AI Agents 自主执行"与"多智能体协作"逐层展开。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

企业官网建设流程全解析