企业官网建设流程全解析

1. 项目概述：MCPFlow，为AI代理构建结构化工作流

如果你正在开发基于Model Context Protocol（MCP）的工具，并且希望让像Cursor或GitHub Copilot这样的AI代理能够以更可控、更安全的方式使用你的工具，那么你很可能遇到过这样的困境：代理直接执行操作，缺乏一个“计划-批准-执行-跟进”的清晰流程。用户可能还没反应过来，文件就已经被修改了，或者操作因为一个简单的输入错误而卡住，代理却不知道下一步该做什么。MCPFlow这个轻量级的.NET库，就是为了解决这个问题而生的。

简单来说，MCPFlow定义了一种结构化的JSON响应格式。当你的MCP工具被调用时，它不再只是返回一个简单的成功消息或错误代码，而是返回一个完整的“编排计划”。这个计划清晰地告诉代理：“我打算做这几件事，可能会影响这些文件，你批准吗？” 如果遇到问题，比如找不到某个资源，它还能提供恢复路径，比如“这里出错了，你可以从这几个选项里选一个来修复”。这相当于在你的工具和AI代理之间，建立了一套标准化的、可预测的对话协议。

我最初接触这个想法，是在尝试将一些复杂的脚手架和代码生成任务集成到Cursor中。直接让代理调用工具，感觉就像把方向盘交给了它，心里总是不踏实。MCPFlow提供的这套模式，让我找回了那种“合作编程”的感觉——AI提出计划，我审核批准，它再执行，最后我们还能讨论下一步。这不仅提升了安全性，也让整个自动化流程变得更有条理、更易于调试。

2. MCPFlow的核心设计理念与架构解析

2.1 从“直接执行”到“编排计划”的范式转变

在没有MCPFlow之前，一个典型的MCP工具交互流程往往是线性的：代理调用工具，工具执行操作，返回结果或错误。这种模式存在几个明显的短板。首先，缺乏可见性：用户或代理在操作执行前，很难全面了解即将发生什么，特别是可能产生的副作用（如文件修改）。其次，错误处理僵化：工具通常只能返回“成功”或“失败”，对于可恢复的错误（如缺少参数、资源不存在），缺乏引导代理或用户进行修复的标准方式。最后，流程断裂：一个多步骤的任务（如“创建页面->添加组件->连接API”）往往需要多次独立的工具调用，中间缺乏连贯的上下文和自然的跟进点。

MCPFlow引入的“编排计划”范式，正是为了弥补这些短板。它的核心思想是将工具的执行拆解为三个明确的阶段：

1. 计划呈现与批准：工具首先返回一个计划（instruction），描述意图，并声明安全影响（safety）。这给了用户或代理一个明确的“刹车点”。
2. 有序执行与错误恢复：计划中包含一个有序的下一步动作列表（next_actions）。执行过程中，如果遇到可预见的错误（如“未找到”），计划可以包含恢复动作（recovery_actions）和收集缺失信息的表单（ask），引导流程回到正轨。
3. 执行后跟进：所有动作成功完成后，一个跟进问题（follow_up）可以自然地引导至下一个相关任务，形成流畅的工作流。

这种设计使得MCP工具从一个简单的“命令执行器”，升级为一个“工作流协调器”。它赋予了工具表达复杂意图、处理异常分支和引导对话的能力。

2.2 核心数据结构深度剖析

MCPFlow定义了一个名为OrchestratedPlan的核心数据结构，它通过JSON进行序列化。理解每个字段的用途和设计考量，是有效使用它的关键。我们可以将其字段分为几个功能组：

身份与状态标识字段：

• kind: 固定为"orchestrated_plan"。这是一个类型标识符，让消费方（如Cursor规则）能快速识别出这是一个MCPFlow计划，而不是普通的文本或错误信息。
• version: 模式版本号（如"1"）。这是一个前瞻性的设计，为未来可能的结构变更提供了兼容性保障。如果你的工具升级了MCPFlow库并使用了新字段，可以通过提升版本号来告知消费方需要新的解析逻辑。
• status: 这是计划当前的状态枚举，是整个数据结构的“总开关”。它决定了消费方应该如何解读其余字段。ok表示一切就绪，等待批准执行；error表示遇到了可恢复的错误（如资源未找到）；invalid表示输入数据有问题；blocked表示因外部依赖或权限问题无法继续；partial表示部分操作已成功，部分失败。

流程控制字段：

• instruction: 这是展示给用户的、对计划目标的人类可读摘要。它应该简洁、清晰，例如“为用户管理模块搭建CRUD界面及相关API模型”。这是用户做出“批准”决策的主要依据。
• next_actions: 一个有序的对象数组，定义了在获得批准后要执行的具体步骤。每个动作指定要调用的MCP工具（tool）及其参数（args）。label和confirm字段提供了额外的UI和控制粒度。
• follow_up: 在所有next_actions成功完成后，向用户提出的自然语言问题。例如，“需要我为新创建的API模型生成Swagger文档吗？”。这个字段是创造流畅、连贯的多步骤体验的关键，它能将离散的工具调用串联成一个有意义的对话。

错误处理与恢复字段：

• errors: 当status为error,invalid,blocked时，这里包含一个错误对象数组，提供机器和人类可读的诊断信息。code,field,message,hint和关键的recoverable标志共同构成了丰富的错误上下文。
• missing: 当输入验证失败时，列出缺失的必填字段名。这为自动生成补救性的用户输入表单提供了直接依据。
• ask: 定义一个用于收集缺失或修正信息的“微型表单”。包含提示语（prompt）和字段定义（fields），字段类型可以是字符串、选择列表等。这是实现交互式错误修复的核心。
• recovery_actions: 提供一组安全的、可选的工具调用，用于尝试自动修复或提供更多上下文。例如，当组件ID未找到时，可以提供一个“列出所有可用组件”的恢复动作。

安全与元数据字段：

• safety: 包含writes_code和touches_files字段。这是在执行前向用户披露风险的重要机制。明确的文件路径模式（如src/modules/**）能让用户非常直观地了解影响范围。
• affected_paths: 与safety.touches_files的预测性不同，这是在执行后填充的实际被影响的具体文件路径列表，用于事后审计和日志。
• correlation_id: 一个可选的追踪ID，用于将工具调用、聊天步骤和系统日志关联起来，在调试分布式、多步骤的AI工作流时极其有用。

这种结构化的设计，使得计划本身成为了一个富含语义的数据契约，而不仅仅是文本。消费方（AI代理或规则引擎）可以程序化地解析它，并据此驱动复杂的交互逻辑。

3. 使用Builder模式构建计划的实操指南

MCPFlow库提供了强类型的FlowBuilder来创建OrchestratedPlan对象。使用Builder模式而非手动构造JSON，能带来编译时类型检查、智能提示和防止字段拼写错误等巨大好处。下面我们深入看看如何构建各种状态的计划。

3.1 构建一个标准的成功计划

这是最常见的场景：工具验证输入无误，并制定出一个可执行的计划。

using MCPFlow; var plan = FlowBuilder.Orchestrated(PlanStatus.Ok) // 1. 声明计划状态为“就绪” .WithInstruction("为用户管理模块搭建CRUD界面及相关API模型。") // 2. 设置清晰的任务描述 .WithFollowUp("需要为这些新模型生成数据库迁移脚本吗？") // 3. 预设下一步的引导问题 .WithSafety(writesCode: true, touchesFiles: new[] { "src/features/user/**", "src/api/models/**" }) // 4. 声明安全影响 .AddNextAction("scaffold_feature", new { // 5. 添加第一个步骤：搭建功能模块 featureName = "UserManagement", entities = new[] { "User", "Role", "Permission" } }) .AddNextAction("generate_api_models", new { // 6. 添加第二个步骤：生成API模型 feature = "UserManagement", format = "TypeScript" }, label: "生成TypeScript接口定义") // 可选：为步骤添加友好标签 .Build(); // 7. 构建最终计划对象 // 在MCP工具的Handler中返回 return FlowResult.Payload(plan);

实操要点：

• 指令（Instruction）要具体：避免模糊的“做一些事情”。好的指令应包含动作（搭建）、目标（CRUD界面、API模型）和范围（用户管理模块）。
• 安全声明要准确：touches_files使用Glob模式（如**表示任意子目录）来合理预估影响范围。过于宽泛（如src/**）会引发不必要的警惕，过于狭窄则可能漏报。
• 下一步动作要原子化：每个next_action应代表一个逻辑上独立、可成功执行的小步骤。避免在一个动作中做太多事情，这样有利于错误隔离和状态恢复。

3.2 构建可恢复的错误计划

当工具执行遇到预期内的障碍时（如资源不存在），返回一个错误状态计划，并引导用户修复。

// 假设在创建屏幕时，传入的 `themeId` 在系统中不存在 var errorPlan = FlowBuilder.Orchestrated(PlanStatus.Error) // 状态设为 Error .WithInstruction($"无法继续：未找到ID为 '{request.ThemeId}' 的主题配置。") .NotFound("themeId", request.ThemeId, "请从现有主题中选择或创建一个新的。") // 便捷方法添加错误详情 .AddMissing("themeId") // 标记该字段缺失（需要用户提供） .WithAsk("请选择一个有效的主题或创建新主题：", // 定义询问表单 new[] { new AskField { Name = "themeId", Type = AskFieldType.Select, // 使用下拉选择，提供选项 Required = true, Options = new[] { "light", "dark", "high-contrast" } // 从数据库或配置中动态获取更好 }, new AskField { Name = "createIfMissing", Type = AskFieldType.Boolean, Required = false, Label = "如果不存在，是否创建？" // 友好的字段标签 } }) .AddRecoveryAction("list_available_themes", new { }) // 恢复动作：列出所有主题 .AddRecoveryAction("create_theme", new { name = "CustomTheme" }, label: "创建自定义主题（安全）", confirm: true) // 带确认的恢复动作 .WithFollowUp("选定主题后，继续搭建UI组件？") .Build(); return FlowResult.Payload(errorPlan);

设计逻辑解析：

1. 状态驱动流程：消费方看到status: "error"，就知道这不是一个可立即执行的计划，而是一个需要先解决问题的中间状态。
2. 错误信息结构化：NotFound辅助方法生成的错误条目，包含了错误码、字段、具体信息和给用户的提示（hint）。recoverable: true是关键，它告诉代理这个错误可以通过用户交互来修复。
3. 引导式修复：ask字段定义了一个清晰的表单。Select类型的字段比纯文本输入更友好，能减少用户输入错误。提供recovery_actions作为快捷方式，用户可以直接选择“列出所有主题”来获取信息，而无需手动输入。
4. 保持流程上下文：即使出错了，follow_up仍然预设了问题，让用户在解决当前问题后能无缝回到主流程。这保持了工作流的连贯性。

3.3 处理输入无效与流程阻塞

除了“未找到”这类业务错误，还有两种常见状态：

输入无效（Invalid）：当用户提供的参数不符合工具要求的模式时使用。例如，要求数字却传了字符串，或缺少必填字段。

var invalidPlan = FlowBuilder.Orchestrated(PlanStatus.Invalid) .WithInstruction("输入数据验证失败。") .AddError(new ErrorInfo { Code = "REQUIRED", Field = "userEmail", Message = "缺少必填字段 'userEmail'。" }) .AddError(new ErrorInfo { Code = "FORMAT", Field = "userEmail", Message = "'userEmail' 字段必须是有效的电子邮件格式。" }) .AddMissing("userEmail") .WithAsk("请提供有效的用户邮箱地址：", new[] { new AskField { Name = "userEmail", Type = AskFieldType.String, Required = true } }) .Build();

流程阻塞（Blocked）：当遇到无法通过用户输入解决的外部障碍时使用，如网络故障、磁盘只读、依赖服务不可用。

var blockedPlan = FlowBuilder.Orchestrated(PlanStatus.Blocked) .WithInstruction("操作被阻止：目标目录没有写入权限。") .AddError(new ErrorInfo { Code = "PERMISSION_DENIED", Message = "对路径 '/var/www/project' 的访问被拒绝。", Recoverable = false }) .AddRecoveryAction("select_output_directory", new { }, label: "选择其他输出目录") .WithFollowUp("权限问题解决后，重试生成操作？") .Build();

关键区别：invalid状态通常意味着“请修正你的输入”，而blocked状态意味着“存在外部障碍，需要你手动干预（如修改权限）或选择替代方案”。recoverable标志在blocked状态下通常为false，因为工具自身无法解决该问题。

3.4 序列化与返回

构建好OrchestratedPlan对象后，需要使用FlowResult.Payload(plan)来将其包装并序列化。这个包装器会确保输出是符合MCPFlow模式的结构化JSON，并且会自动忽略所有为null的字段，保持响应的简洁。

// 这是推荐方式，直接返回给MCP服务器框架（如 MCPSharp） return FlowResult.Payload(myPlan); // 如果你需要获取JSON字符串（例如用于日志记录或测试） string jsonString = FlowResult.Json(myPlan, indented: true); Console.WriteLine(jsonString);

关于枚举序列化：为了在JSON中得到可读的字符串（如"ok"而非数字0），你需要在你的序列化配置中添加JsonStringEnumConverter。在System.Text.Json中，可以这样配置：

// 在Program.cs或启动配置中 services.AddControllers().AddJsonOptions(options => { options.JsonSerializerOptions.Converters.Add(new JsonStringEnumConverter(JsonNamingPolicy.CamelCase)); });

4. 与AI代理集成：以Cursor和Copilot为例

MCPFlow计划本身是数据，需要消费方（AI代理）来解读和执行。下面我们看看如何让主流的AI编码助手理解并遵循这个流程。

4.1 在Cursor中实现自动化工作流

Cursor通过其强大的规则（Rules）系统，可以完美地解析和执行MCPFlow计划。你只需要添加一个简单的规则文件。

第一步：创建Cursor规则在项目根目录的.cursor/rules文件夹下，创建一个文件，例如mcpflow_plan_executor.md。

--- type: Always description: "MCPFlow计划执行器：解析计划 -> 请求批准 -> 按序执行 -> 跟进提问" alwaysApply: true --- 当检测到上一个工具调用的结果中包含 `"kind": "orchestrated_plan"` 时： 1. **呈现计划**： * 从 `instruction` 字段提取1-3行摘要，作为计划描述显示给用户。 * 如果存在 `safety` 字段，明确告知用户： * `writes_code`: 此操作将**写入或修改代码**。 * `touches_files`: 可能影响的文件/路径模式：`{{ safety.touches_files | join(', ') }}`。 * 最后，清晰地向用户提问：**是否继续执行此计划？** 2. **处理用户响应**： * 如果用户回答 **是**、**同意**、**执行**、**继续** 等肯定性词语： * 按顺序遍历 `next_actions` 列表中的每一项。 * 对于每一项，先向用户简要说明即将执行的动作（使用 `label` 或 `tool` 名称），然后调用对应的MCP工具，并传入 `args` 参数。 * 如果某个动作的 `confirm` 字段为 `true`，则在调用该工具前，额外询问用户一次“确定要执行 `[label]` 吗？”。 * 所有动作执行成功后，如果存在 `follow_up` 字段，则将该问题直接抛给用户。 * 如果用户回答 **否**、**取消**、**停止** 等否定性词语： * 询问用户：“您希望修改计划的哪个部分？” 或 “请提供新的指令。” * 根据用户的反馈，重新调用相关的规划工具（或让用户直接修改输入）。 3. **处理错误状态**： * 如果计划的 `status` 是 `"error"` 或 `"invalid"`： * 向用户展示 `errors` 数组中的每一条错误信息（`message` 和 `hint`）。 * 如果存在 `ask` 字段，则根据其中定义的 `fields`，引导用户逐一提供缺失或修正的信息。 * 用户提供信息后，使用这些新信息重新调用最初触发该计划的工具。 * 如果 `status` 是 `"blocked"`： * 展示阻塞原因，并提示用户执行 `recovery_actions` 中建议的手动步骤（或直接调用其中提供的工具）。

第二步：体验工作流现在，当你的MCP工具返回一个MCPFlow计划时，Cursor会自动触发上述规则。你会看到类似这样的对话：

• 你：“为订单模块创建一个详情页。”
• 你的MCP工具：（返回一个status: "ok"的OrchestratedPlan）
• Cursor：“计划：为订单模块搭建详情页面，包含订单信息、商品列表和状态跟踪组件。影响文件：src/features/order/**。是否继续？”
• 你：“继续。”
• Cursor：“正在执行步骤1/2：创建订单详情页... [调用工具] 完成。正在执行步骤2/2：生成状态跟踪组件... [调用工具] 完成。所有步骤执行完毕。需要为这个新页面添加单元测试吗？”（这是follow_up）

进阶：使用状态机文件进行更精细的控制对于极其复杂、多轮交互的工作流，可以结合一个“状态机”Markdown文件（如workflow_state.md）来实现有状态的流程控制。Cursor规则可以读取和更新这个文件，根据## State字段决定当前该做什么。这适合需要严格顺序、且步骤间有强依赖关系的场景。不过对于大多数用例，上述的即时规则已经足够强大和灵活。

4.2 在GitHub Copilot Chat或其他通用代理中集成

GitHub Copilot Chat没有Cursor那样的内置规则引擎，但你可以通过精心设计系统提示词（System Instructions）来指导其行为。核心思路是：教代理识别MCPFlow的JSON结构，并按照固定的流程与之交互。

第一步：暴露一个HTTP端点（或CLI）你的MCP工具可能需要通过一个Web服务来暴露。这个服务接收请求，调用背后的工具逻辑，并返回MCPFlow格式的JSON。

// ASP.NET Core Minimal API 示例 app.MapPost("/api/mcp/plan-feature", async (FeatureRequest request) => { // 1. 这里是你的业务逻辑，验证请求，制定计划... var validationResult = ValidateRequest(request); if (!validationResult.IsValid) { // 返回一个 invalid 状态的计划 var invalidPlan = FlowBuilder.Orchestrated(PlanStatus.Invalid) .WithInstruction("输入验证失败。") .WithErrors(validationResult.Errors.Select(e => new ErrorInfo{...}).ToList()) .Build(); return Results.Json(FlowResult.Payload(invalidPlan).Content); } // 2. 制定成功计划 var plan = FlowBuilder.Orchestrated(PlanStatus.Ok) .WithInstruction($"为功能 '{request.Name}' 生成脚手架。") .WithSafety(true, new[]{$"src/features/{request.Name}/**"}) .AddNextAction("scaffold", new { feature = request.Name }) .Build(); // 3. 返回MCPFlow JSON return Results.Json(FlowResult.Payload(plan).Content); });

第二步：编写代理系统指令将以下指令（或根据你的需求调整后）粘贴到你的Copilot Agent、Claude Desktop自定义指令或其他支持系统提示词的AI代理中。

你是一个遵循MCPFlow协议的工作流助手。当你调用返回JSON的API，且该JSON包含顶级字段 `"kind": "orchestrated_plan"` 时，请按以下流程操作： 1. **解析与呈现**： * 读取 `status` 字段。 * 如果 `status` 是 `"ok"`： * 向用户清晰展示 `instruction` 字段的内容，作为计划摘要。 * 如果存在 `safety` 字段，务必告知用户：“此操作将修改代码，可能影响以下文件/目录：[列出 safety.touches_files 中的路径]”。 * 然后询问用户：“**是否批准并执行此计划？**” * 如果 `status` 是 `"error"` 或 `"invalid"`： * 告诉用户：“计划遇到问题：`[instruction]`”。 * 逐条列出 `errors` 数组中的 `message` 和 `hint`。 * 如果存在 `ask` 字段，则根据 `ask.prompt` 提示用户，并按照 `ask.fields` 的定义，逐个向用户收集所需信息。收集完毕后，使用这些新信息重新调用最初的API。 * 如果 `status` 是 `"blocked"`： * 告知用户阻塞原因，并建议他们手动检查或执行 `recovery_actions` 中描述的操作。 2. **执行计划**： * 仅在用户明确批准（回答“是”、“批准”、“执行”等）后，才执行 `next_actions`。 * 按顺序处理 `next_actions` 数组中的每一项： * 向用户简要说明：“即将执行：[使用 action.label 或 action.tool]”。 * 调用对应的工具/API端点，传入 `args` 中的参数。 * 如果某个动作的 `confirm` 字段为 `true`，则在调用前再次向用户确认。 3. **跟进**： * 所有 `next_actions` 成功完成后，如果存在 `follow_up` 字段，直接将该问题作为下一个对话轮次抛给用户。 始终记住：在用户批准前，不要执行任何 `next_actions` 中的步骤。

第三步：测试交互流程配置好后，你的对话可能如下所示：

• 你：“调用 /api/mcp/plan-feature，参数是 name=Dashboard。”
• Copilot Agent：（调用API，收到MCPFlow响应）“计划：为功能‘Dashboard’生成脚手架。安全提示：此操作将修改代码，可能影响src/features/Dashboard/**下的文件。是否批准并执行此计划？”
• 你：“批准。”
• Copilot Agent：“正在执行步骤：脚手架功能‘Dashboard’... [调用API] 完成。功能脚手架已创建。是否立即为Dashboard功能配置路由和导航菜单？”

通过这种方式，即使在没有内置工作流引擎的通用AI代理中，你也能实现结构化的、安全的工具交互循环。

5. 实战经验、避坑指南与高级模式

在实际项目中集成MCPFlow几个月后，我积累了一些宝贵的经验和踩过的坑，这里分享给大家。

5.1 工具设计的经验法则

1. 工具粒度要适中：你的MCP工具应该保持相对较小的功能单元。一个工具最好只做一件事（如“创建屏幕”、“添加组件”、“连接API”）。这样，next_actions列表才能灵活组合成复杂工作流。如果一个工具本身就是一个庞大的、多步骤的“黑盒”，那么MCPFlow的计划和批准机制就失去了意义。
2. 指令（Instruction）是用户界面：把instruction字段当作写给用户看的“执行摘要”。它应该足够清晰，让非技术人员也能理解将要发生什么。避免使用内部技术术语。好的指令是建立信任的第一步。
3. 安全声明宁严勿宽：对于safety.touches_files，如果你不确定精确的路径，使用稍宽泛的Glob模式（如src/features/order/*.tsx）比漏报要好。用户宁愿多一次确认，也不愿看到意料之外的文件被修改。
4. 为所有可能的失败场景设计计划：在工具开发初期，就思考各种失败情况：输入无效、资源不存在、权限不足、网络超时。为每种情况预先设计好对应的error、invalid或blocked计划，并提供有意义的recovery_actions和ask表单。这能极大提升工具的健壮性和用户体验。

5.2 常见问题与排查技巧

问题1：Cursor规则没有触发。

• 检查点：首先确认你的规则文件（.cursor/rules/mcpflow_plan_executor.md）是否放在了正确的位置，并且文件后缀是.md。然后，检查你的MCP工具返回的JSON，最外层是否确实包含"kind": "orchestrated_plan"字段。你可以通过添加日志或直接在Cursor中查看工具调用的原始输出来验证。
• 技巧：在规则开头添加一个简单的调试日志是一个好习惯。例如，可以在规则中先写一句：“检测到MCPFlow计划，状态为：{{ last_tool_result.status }}”，看看它是否被打印出来。

问题2：follow_up问题在错误发生后仍然被提问。

• 原因：这是逻辑设计问题。follow_up字段在计划构建时就被确定了。如果你的工具在遇到错误时也设置了follow_up，那么即使用户修复了错误，代理也可能会问那个可能已经不合时宜的跟进问题。
• 解决方案：在构建错误状态（error,invalid,blocked）的计划时，通常不应该设置follow_up。follow_up应该只用于成功的、线性的流程推进。错误恢复后的下一步，应该由用户的新指令或修复后重新生成的计划来决定。

问题3：next_actions中的步骤有依赖关系，但前一个步骤失败了。

• 设计模式：MCPFlow本身不处理步骤间的依赖或条件执行。如果一个步骤失败，整个计划就停止了。对于有复杂依赖的场景，你有两个选择：
  • 方案A（推荐）：设计更粗粒度的工具。让一个工具完成一组有强依赖的原子操作，内部处理错误，对外只返回最终成功或包含具体错误信息的失败计划。
  • 方案B（高级）：使用partial状态。当第一个步骤成功，第二个步骤失败时，返回status: "partial"，并在partial_results中详细说明每个步骤的结果。然后在recovery_actions中提供修复第二个步骤的选项。这需要更复杂的消费方（代理）逻辑来处理部分成功的情况。

问题4：如何测试MCPFlow的端到端流程？

• 使用烟雾测试计划：项目README中提供的“Quick Smoke Test Plan”是一个极佳的起点。创建一个最简单的MCP工具，让它固定返回那个测试用的JSON计划。然后分别在Cursor和Copilot中测试，观察整个“计划->批准->执行->跟进”的循环是否如预期般运行。这是验证你的集成环境是否就绪的最快方法。
• 单元测试你的Builder逻辑：为你的工具中构建各种状态计划（成功、各种错误）的代码编写单元测试。确保生成的JSON结构正确，字段齐全，没有null值污染（除了应该被忽略的字段）。

5.3 高级模式：状态持久化与复杂工作流

对于需要跨多个对话轮次、涉及复杂决策树的工作流，仅靠单个OrchestratedPlan可能不够。这时可以结合一个外部的“状态存储”。

模式：Plan as a Stage将每个MCPFlow计划视为工作流中的一个“阶段”。消费方（如增强的Cursor规则）在执行完一个计划后，将当前的工作流状态（例如，“阶段1完成”、“等待用户选择主题”）和累积的结果存储在一个外部文件（如workflow_state.json）或数据库中。当用户给出后续指令时，代理先读取状态，再决定调用哪个工具，并传入之前累积的上下文。

你的MCP工具也需要被设计成可以接收这种“上下文”参数，从而生成基于当前状态的新计划。这实际上是将一个长流程分解为多个由MCPFlow计划连接的、可暂停和可恢复的短流程。

虽然MCPFlow库本身不提供这种状态管理，但它输出的结构化数据（尤其是correlation_id和partial_results）为构建这样的上层系统提供了坚实的基础。