在许多 LLM 应用中单次生成往往难以稳定满足质量要求。模型可能遗漏约束、表达不够清晰或者在复杂任务中产生不完整的结果。为了提高输出质量一个常见思路是将“生成”与“评审”拆开先由一个模型完成初稿再由另一个模型审查结果、提出反馈并在必要时触发修订。这种思路通常被称为 Reflection反思。Reflection 指的是一次 LLM 生成之后紧接着触发另一次基于前一次输出结果的评审或反思。第二个 LLM 不直接完成原始任务而是针对第一个 LLM 的输出给出批评、建议或改进方向。Writer–Critic 正是 Reflection 模式在多 Agent 协作中的一种典型实现Writer 负责生成内容Critic 负责评审内容并根据评审结果决定是否进入下一轮修订。通过“生成—评审—修订”的闭环系统可以在多轮迭代中逐步提升内容质量。在 AutoGen 或 Agent Framework 的上下文中这种模式可以被实现为一组协作 Agent。它们持续交互直到达到某个停止条件例如内容通过评审或者达到最大迭代次数。Agent Framework 为这一模式提供了工程化实现方式基于条件路由的工作流图、跨执行步骤的共享状态、结构化输出以及流式响应。Writer–Critic 工作流的需求本文示例实现的是一个可迭代的内容评审系统。需求如下用户输入一个写作主题或写作请求。Writer Agent 根据用户请求生成初稿。Critic Agent 对 Writer 生成的内容进行评审。如果内容不符合要求Critic Agent 返回具体反馈。Writer Agent 根据反馈对内容进行修订。Writer 与 Critic 持续循环直到内容通过评审或达到最大迭代次数。内容通过后Summary Agent 输出最终版本。我们定义Writer Agent首先Writer Agent 接收一个字符串输入代表用户的初始写作请求。Writer Agent 生成的内容以 ChatMessage 对象的形式输出供后续的 Critic Agent 评审使用。Writer Agent 定义如下internal sealedpartialclassWriterExecutor : Executor { privatereadonly AIAgent _agent; public WriterExecutor(IChatClient chatClient) : base(Writer) { this._agent new ChatClientAgent( chatClient, name: Writer, instructions: 你是一个熟练的写作者。根据用户请求创建清晰、有吸引力的内容。 如果收到反馈请仔细修改内容以解决所有问题。 保持相同的主题和长度要求。 ); } [MessageHandler] public async ValueTaskChatMessage HandleInitialRequestAsync( string message, IWorkflowContext context, CancellationToken cancellationToken default) { returnawaitthis.HandleAsyncCoreAsync(new ChatMessage(ChatRole.User, message), context, cancellationToken); } [MessageHandler] public async ValueTaskChatMessage HandleRevisionRequestAsync( CriticDecision decision, IWorkflowContext context, CancellationToken cancellationToken default) { string prompt 根据以下反馈修改内容\n\n $反馈: {decision.Feedback}\n\n $原始内容:\n{decision.Content}; returnawaitthis.HandleAsyncCoreAsync(new ChatMessage(ChatRole.User, prompt), context, cancellationToken); } private async TaskChatMessage HandleAsyncCoreAsync( ChatMessage message, IWorkflowContext context, CancellationToken cancellationToken) { FlowState state await FlowStateHelpers.ReadFlowStateAsync(context); Console.WriteLine($\n 写作者 (迭代 {state.Iteration}) \n); StringBuilder sb new(); awaitforeach (AgentResponseUpdate update inthis._agent.RunStreamingAsync(message, cancellationToken: cancellationToken)) { if (!string.IsNullOrEmpty(update.Text)) { sb.Append(update.Text); Console.Write(update.Text); } } Console.WriteLine(\n); string text sb.ToString(); state.History.Add(new ChatMessage(ChatRole.Assistant, text)); await FlowStateHelpers.SaveFlowStateAsync(context, state); returnnew ChatMessage(ChatRole.User, text); } }WriterExecutor 继承自 Executor并通过构造函数创建内部的 ChatClientAgent。这个 Agent 的系统指令定义了 Writer 的角色根据用户请求生成清晰、有吸引力的内容并在收到反馈时进行修订。这里有两个公开的消息处理方法HandleInitialRequestAsync(string message, ...) HandleRevisionRequestAsync(CriticDecision decision, ...)它们都使用了[MessageHandler]特性。Agent Framework 会根据进入该节点的数据类型选择匹配的消息处理方法。第一次进入 Writer 时输入是用户的原始字符串因此会调用HandleInitialRequestAsync(string message, ...)当 Critic 不通过并返回 CriticDecision 时数据再次回到 Writer这时会调用HandleRevisionRequestAsync(CriticDecision decision, ...)HandleAsyncCoreAsync是内部复用的核心方法不会被工作流框架直接调用。它负责真正调用 Writer Agent流式接收模型输出更新共享状态返回生成后的 ChatMessage需要注意的是HandleAsyncCoreAsync本身并不直接调用 Critic。它只是返回 Writer 生成的 ChatMessage。随后工作流中定义的writer - critic边会把这个返回值路由给CriticExecutor。Critic Agent结构化评审与反馈Critic Agent 负责审查 Writer 生成的内容并返回结构化决策。其输出类型是 CriticDecisioninternal sealedclassCriticDecision { [JsonPropertyName(approved)] publicbool Approved { get; set; } [JsonPropertyName(feedback)] publicstring Feedback { get; set; } ; [JsonIgnore] publicstring Content { get; set; } ; [JsonIgnore] publicint Iteration { get; set; } }其中Approved 表示内容是否通过评审。 Feedback 表示未通过时的修改建议。 Content 和 Iteration 是工作流内部使用的字段不参与 JSON 结构化输出。Critic Agent 定义如下internal sealedclassCriticExecutor : ExecutorChatMessage, CriticDecision { privatereadonly AIAgent _agent; public CriticExecutor(IChatClient chatClient) : base(Critic) { this._agent new ChatClientAgent(chatClient, new ChatClientAgentOptions { Name Critic, ChatOptions new() { Instructions 你是一名建设性的评论者。请审查内容并提供具体反馈。 只有当内容经过至少 2 次修改后才允许 approved 为 true。 如果是第一次审查必须返回 approvedfalse并给出具体修改建议。 请按照以下结构化格式给出你的判断 approved如果内容良好则为 true如果需要修改则为 false feedback需要改进的具体建议如果已批准则为空 你的反馈应当简洁但具体明确。 , ResponseFormat ChatResponseFormat.ForJsonSchemaCriticDecision() } }); } public override async ValueTaskCriticDecision HandleAsync( ChatMessage message, IWorkflowContext context, CancellationToken cancellationToken default) { FlowState state await FlowStateHelpers.ReadFlowStateAsync(context); Console.WriteLine($ 评论者 (迭代 {state.Iteration}) \n); // 使用 RunStreamingAsync 获取流式更新然后在末尾反序列化 IAsyncEnumerableAgentResponseUpdate updates this._agent.RunStreamingAsync(message, cancellationToken: cancellationToken); // 实时输出流式内容例如推理或说明 awaitforeach (AgentResponseUpdate update in updates) { if (!string.IsNullOrEmpty(update.Text)) { Console.Write(update.Text); } } Console.WriteLine(\n); // 将流转换为响应并反序列化结构化输出 AgentResponse response await updates.ToAgentResponseAsync(cancellationToken); CriticDecision decision JsonSerializer.DeserializeCriticDecision(response.Text, JsonSerializerOptions.Web) ?? thrownew JsonException(无法从响应文本反序列化 CriticDecision。); Console.WriteLine($ 决策: {(decision.Approved ? ✅ 已批准 : ❌ 需要修改)}); if (!string.IsNullOrEmpty(decision.Feedback)) { Console.WriteLine($反馈: {decision.Feedback}); } Console.WriteLine(); // 安全措施如果达到最大迭代次数则自动批准 if (!decision.Approved state.Iteration Program.MaxIterations) { Console.ForegroundColor ConsoleColor.Yellow; Console.WriteLine($⚠️ 达到最大迭代次数 ({Program.MaxIterations}) - 自动批准); Console.ResetColor(); decision.Approved true; decision.Feedback ; } // 仅在拒绝时递增迭代次数将回到 Writer if (!decision.Approved) { state.Iteration; } // 将决策存入历史记录 state.History.Add(new ChatMessage(ChatRole.Assistant, $[决策: {(decision.Approved ? 已批准 : 需要修改)}] {decision.Feedback})); await FlowStateHelpers.SaveFlowStateAsync(context, state); // 填充工作流专用字段 decision.Content message.Text ?? ; decision.Iteration state.Iteration; return decision; } }CriticExecutor 继承自ExecutorChatMessage, CriticDecision这表示该执行器接收 ChatMessage 作为输入并输出 CriticDecision。它的入口方法是HandleAsync(ChatMessage message, ...)这里的 message 就是 Writer 生成的内容。Critic 的评审结果来自 LLM 的结构化输出。通过ResponseFormat ChatResponseFormat.ForJsonSchemaCriticDecision()我们要求模型按照 CriticDecision 的 JSON Schema 返回结果从而让程序可以稳定解析CriticDecision decision JsonSerializer.DeserializeCriticDecision(...)不过需要注意approvedtrue 或 approvedfalse 的初始判断来自 LLM。Agent Framework 只是提供结构化输出能力并不会替我们判断内容质量。程序侧仍然可以在必要时覆盖这个判断例如达到最大迭代次数时自动批准if (!decision.Approved state.Iteration Program.MaxIterations) { decision.Approved true; decision.Feedback ; }这就是防止无限循环的安全阀。Summary Agent输出最终内容当 Critic 返回 Approved true 时工作流会进入 Summary Agent。 Summary Agent 的职责不是继续评审而是将最终通过的内容呈现给用户internal sealedclassSummaryExecutor : ExecutorCriticDecision, ChatMessage { privatereadonly AIAgent _agent; public SummaryExecutor(IChatClient chatClient) : base(Summary) { this._agent new ChatClientAgent( chatClient, name: Summary, instructions: 你将最终批准后的内容呈现给用户。 仅输出润色后的最终内容——不需要任何额外说明。 ); } public override async ValueTaskChatMessage HandleAsync( CriticDecision message, IWorkflowContext context, CancellationToken cancellationToken default) { Console.WriteLine( 总结 \n); string prompt $呈现此已批准的内容\n\n{message.Content}; StringBuilder sb new(); awaitforeach (AgentResponseUpdate update inthis._agent.RunStreamingAsync(new ChatMessage(ChatRole.User, prompt), cancellationToken: cancellationToken)) { if (!string.IsNullOrEmpty(update.Text)) { sb.Append(update.Text); } } ChatMessage result new(ChatRole.Assistant, sb.ToString()); await context.YieldOutputAsync(result, cancellationToken); return result; }SummaryExecutor 继承自ExecutorCriticDecision, ChatMessage这表示它接收 Critic 的决策结果并输出最终的 ChatMessage。这里的关键方法是context.YieldOutputAsync(result, cancellationToken);它用于向工作流外部发布最终输出。外层的 WatchStreamAsync 会接收到 WorkflowOutputEvent然后打印最终结果。工作流图与条件路由三个执行器定义完成后需要通过 WorkflowBuilder 组织成工作流图WorkflowBuilder workflowBuilder new WorkflowBuilder(writer) .AddEdge(writer, critic) .AddSwitch(critic, sw sw .AddCaseCriticDecision(cd cd?.Approved true, summary) .AddCaseCriticDecision(cd cd?.Approved false, writer)) .WithOutputFrom(summary);这段代码定义了完整的路由关系第一次进入 Writer 时输入类型是 string因此匹配 HandleInitialRequestAsync。当 Critic 不通过时它返回的是 CriticDecision。这个对象再次流入 Writer因此匹配 HandleRevisionRequestAsync。这也是 [MessageHandler] 的关键作用对于继承自非泛型 Executor 的执行器可以定义多个消息处理方法框架根据进入节点的数据类型选择对应方法。而对于ExecutorTInput, TOutput 输入类型已经由泛型参数 TInput 明确指定因此框架会调用其重写的 HandleAsync 方法。状态控制在 Writer–Critic 工作流中状态控制非常重要。因为 Writer 和 Critic 之间存在循环如果没有状态记录就无法判断当前已经迭代了多少次也无法设置最大迭代次数。状态定义如下internal sealed class FlowState { public int Iteration { get; set; } 1; public ListChatMessage History { get; } []; }其中Iteration 表示当前迭代轮次。 History 保存 Writer 输出和 Critic 决策记录。 状态通过 IWorkflowContext 读写internal staticclassFlowStateShared { publicconststring Scope FlowStateScope; publicconststring Key singleton; } internalstaticclassFlowStateHelpers { public static async TaskFlowState ReadFlowStateAsync(IWorkflowContext context) { FlowState? state await context.ReadStateAsyncFlowState( FlowStateShared.Key, scopeName: FlowStateShared.Scope); return state ?? new FlowState(); } public static ValueTask SaveFlowStateAsync(IWorkflowContext context, FlowState state) context.QueueStateUpdateAsync( FlowStateShared.Key, state, scopeName: FlowStateShared.Scope); }ReadStateAsync 用于从工作流上下文中读取状态。如果之前没有保存过状态则返回 null因此这里会创建一个新的 FlowState。QueueStateUpdateAsync 用于将修改后的状态保存回工作流上下文使后续执行器能够读取到更新后的状态。在 Writer 中状态主要用于记录生成历史state.History.Add(new ChatMessage(ChatRole.Assistant, text)); await FlowStateHelpers.SaveFlowStateAsync(context, state);在 Critic 中状态用于控制循环次数if (!decision.Approved state.Iteration Program.MaxIterations) { decision.Approved true; decision.Feedback ; } if (!decision.Approved) { state.Iteration; }因此状态控制的逻辑是第 1 轮 Writer 生成内容 Critic 评审 如果不通过Iteration 增加到 2第 2 轮 Writer 根据反馈修订 Critic 再次评审 如果不通过Iteration 增加到 3第 3 轮 Writer 再次修订 Critic 再次评审 如果仍不通过由程序侧强制批准避免无限循环 需要注意的是当前样例虽然把 Writer 输出和 Critic 决策写入了 History但并没有在后续 Agent 调用中将 History 作为上下文传给模型。因此History 在当前代码中更多用于记录、调试或后续扩展并不会自动影响模型生成结果。如果希望历史真正参与模型推理需要显式将 state.History 拼入 prompt或者构造完整的消息列表传给 Agent。小结Writer–Critic 工作流展示了 Agent Framework 中一种典型的多 Agent 协作模式。它的核心机制包括Writer Agent 负责生成和修订内容。 Critic Agent 负责评审内容并通过结构化输出返回 CriticDecision。 Summary Agent 负责输出最终通过的内容。 工作流通过 AddSwitch 根据 Approved 字段进行条件路由。 IWorkflowContext 用于跨执行器共享状态。 Iteration 用于限制最大循环次数避免无限迭代。 [MessageHandler] 允许同一个 Executor 根据输入类型处理不同场景。生成 - 评审 - 不通过修订 - 通过输出 这个样例的价值不只是展示多个 Agent 如何串联更重要的是展示了如何把 LLM 的不确定输出纳入一个可控的工程流程中通过结构化输出获得可解析的决策通过条件路由实现闭环通过共享状态控制迭代边界。源代码地址https://github.com/bingbing-gui/dotnet-agent-playbook/tree/master/src/ai-agent/Agent-Framework/39-WriterCritic-Pattern
Agent Framework 自我改进模式 构建 Agent 自优化闭环
发布时间：2026/5/28 1:47:14
在许多 LLM 应用中单次生成往往难以稳定满足质量要求。模型可能遗漏约束、表达不够清晰或者在复杂任务中产生不完整的结果。为了提高输出质量一个常见思路是将“生成”与“评审”拆开先由一个模型完成初稿再由另一个模型审查结果、提出反馈并在必要时触发修订。这种思路通常被称为 Reflection反思。Reflection 指的是一次 LLM 生成之后紧接着触发另一次基于前一次输出结果的评审或反思。第二个 LLM 不直接完成原始任务而是针对第一个 LLM 的输出给出批评、建议或改进方向。Writer–Critic 正是 Reflection 模式在多 Agent 协作中的一种典型实现Writer 负责生成内容Critic 负责评审内容并根据评审结果决定是否进入下一轮修订。通过“生成—评审—修订”的闭环系统可以在多轮迭代中逐步提升内容质量。在 AutoGen 或 Agent Framework 的上下文中这种模式可以被实现为一组协作 Agent。它们持续交互直到达到某个停止条件例如内容通过评审或者达到最大迭代次数。Agent Framework 为这一模式提供了工程化实现方式基于条件路由的工作流图、跨执行步骤的共享状态、结构化输出以及流式响应。Writer–Critic 工作流的需求本文示例实现的是一个可迭代的内容评审系统。需求如下用户输入一个写作主题或写作请求。Writer Agent 根据用户请求生成初稿。Critic Agent 对 Writer 生成的内容进行评审。如果内容不符合要求Critic Agent 返回具体反馈。Writer Agent 根据反馈对内容进行修订。Writer 与 Critic 持续循环直到内容通过评审或达到最大迭代次数。内容通过后Summary Agent 输出最终版本。我们定义Writer Agent首先Writer Agent 接收一个字符串输入代表用户的初始写作请求。Writer Agent 生成的内容以 ChatMessage 对象的形式输出供后续的 Critic Agent 评审使用。Writer Agent 定义如下internal sealedpartialclassWriterExecutor : Executor { privatereadonly AIAgent _agent; public WriterExecutor(IChatClient chatClient) : base(Writer) { this._agent new ChatClientAgent( chatClient, name: Writer, instructions: 你是一个熟练的写作者。根据用户请求创建清晰、有吸引力的内容。 如果收到反馈请仔细修改内容以解决所有问题。 保持相同的主题和长度要求。 ); } [MessageHandler] public async ValueTaskChatMessage HandleInitialRequestAsync( string message, IWorkflowContext context, CancellationToken cancellationToken default) { returnawaitthis.HandleAsyncCoreAsync(new ChatMessage(ChatRole.User, message), context, cancellationToken); } [MessageHandler] public async ValueTaskChatMessage HandleRevisionRequestAsync( CriticDecision decision, IWorkflowContext context, CancellationToken cancellationToken default) { string prompt 根据以下反馈修改内容\n\n $反馈: {decision.Feedback}\n\n $原始内容:\n{decision.Content}; returnawaitthis.HandleAsyncCoreAsync(new ChatMessage(ChatRole.User, prompt), context, cancellationToken); } private async TaskChatMessage HandleAsyncCoreAsync( ChatMessage message, IWorkflowContext context, CancellationToken cancellationToken) { FlowState state await FlowStateHelpers.ReadFlowStateAsync(context); Console.WriteLine($\n 写作者 (迭代 {state.Iteration}) \n); StringBuilder sb new(); awaitforeach (AgentResponseUpdate update inthis._agent.RunStreamingAsync(message, cancellationToken: cancellationToken)) { if (!string.IsNullOrEmpty(update.Text)) { sb.Append(update.Text); Console.Write(update.Text); } } Console.WriteLine(\n); string text sb.ToString(); state.History.Add(new ChatMessage(ChatRole.Assistant, text)); await FlowStateHelpers.SaveFlowStateAsync(context, state); returnnew ChatMessage(ChatRole.User, text); } }WriterExecutor 继承自 Executor并通过构造函数创建内部的 ChatClientAgent。这个 Agent 的系统指令定义了 Writer 的角色根据用户请求生成清晰、有吸引力的内容并在收到反馈时进行修订。这里有两个公开的消息处理方法HandleInitialRequestAsync(string message, ...) HandleRevisionRequestAsync(CriticDecision decision, ...)它们都使用了[MessageHandler]特性。Agent Framework 会根据进入该节点的数据类型选择匹配的消息处理方法。第一次进入 Writer 时输入是用户的原始字符串因此会调用HandleInitialRequestAsync(string message, ...)当 Critic 不通过并返回 CriticDecision 时数据再次回到 Writer这时会调用HandleRevisionRequestAsync(CriticDecision decision, ...)HandleAsyncCoreAsync是内部复用的核心方法不会被工作流框架直接调用。它负责真正调用 Writer Agent流式接收模型输出更新共享状态返回生成后的 ChatMessage需要注意的是HandleAsyncCoreAsync本身并不直接调用 Critic。它只是返回 Writer 生成的 ChatMessage。随后工作流中定义的writer - critic边会把这个返回值路由给CriticExecutor。Critic Agent结构化评审与反馈Critic Agent 负责审查 Writer 生成的内容并返回结构化决策。其输出类型是 CriticDecisioninternal sealedclassCriticDecision { [JsonPropertyName(approved)] publicbool Approved { get; set; } [JsonPropertyName(feedback)] publicstring Feedback { get; set; } ; [JsonIgnore] publicstring Content { get; set; } ; [JsonIgnore] publicint Iteration { get; set; } }其中Approved 表示内容是否通过评审。 Feedback 表示未通过时的修改建议。 Content 和 Iteration 是工作流内部使用的字段不参与 JSON 结构化输出。Critic Agent 定义如下internal sealedclassCriticExecutor : ExecutorChatMessage, CriticDecision { privatereadonly AIAgent _agent; public CriticExecutor(IChatClient chatClient) : base(Critic) { this._agent new ChatClientAgent(chatClient, new ChatClientAgentOptions { Name Critic, ChatOptions new() { Instructions 你是一名建设性的评论者。请审查内容并提供具体反馈。 只有当内容经过至少 2 次修改后才允许 approved 为 true。 如果是第一次审查必须返回 approvedfalse并给出具体修改建议。 请按照以下结构化格式给出你的判断 approved如果内容良好则为 true如果需要修改则为 false feedback需要改进的具体建议如果已批准则为空 你的反馈应当简洁但具体明确。 , ResponseFormat ChatResponseFormat.ForJsonSchemaCriticDecision() } }); } public override async ValueTaskCriticDecision HandleAsync( ChatMessage message, IWorkflowContext context, CancellationToken cancellationToken default) { FlowState state await FlowStateHelpers.ReadFlowStateAsync(context); Console.WriteLine($ 评论者 (迭代 {state.Iteration}) \n); // 使用 RunStreamingAsync 获取流式更新然后在末尾反序列化 IAsyncEnumerableAgentResponseUpdate updates this._agent.RunStreamingAsync(message, cancellationToken: cancellationToken); // 实时输出流式内容例如推理或说明 awaitforeach (AgentResponseUpdate update in updates) { if (!string.IsNullOrEmpty(update.Text)) { Console.Write(update.Text); } } Console.WriteLine(\n); // 将流转换为响应并反序列化结构化输出 AgentResponse response await updates.ToAgentResponseAsync(cancellationToken); CriticDecision decision JsonSerializer.DeserializeCriticDecision(response.Text, JsonSerializerOptions.Web) ?? thrownew JsonException(无法从响应文本反序列化 CriticDecision。); Console.WriteLine($ 决策: {(decision.Approved ? ✅ 已批准 : ❌ 需要修改)}); if (!string.IsNullOrEmpty(decision.Feedback)) { Console.WriteLine($反馈: {decision.Feedback}); } Console.WriteLine(); // 安全措施如果达到最大迭代次数则自动批准 if (!decision.Approved state.Iteration Program.MaxIterations) { Console.ForegroundColor ConsoleColor.Yellow; Console.WriteLine($⚠️ 达到最大迭代次数 ({Program.MaxIterations}) - 自动批准); Console.ResetColor(); decision.Approved true; decision.Feedback ; } // 仅在拒绝时递增迭代次数将回到 Writer if (!decision.Approved) { state.Iteration; } // 将决策存入历史记录 state.History.Add(new ChatMessage(ChatRole.Assistant, $[决策: {(decision.Approved ? 已批准 : 需要修改)}] {decision.Feedback})); await FlowStateHelpers.SaveFlowStateAsync(context, state); // 填充工作流专用字段 decision.Content message.Text ?? ; decision.Iteration state.Iteration; return decision; } }CriticExecutor 继承自ExecutorChatMessage, CriticDecision这表示该执行器接收 ChatMessage 作为输入并输出 CriticDecision。它的入口方法是HandleAsync(ChatMessage message, ...)这里的 message 就是 Writer 生成的内容。Critic 的评审结果来自 LLM 的结构化输出。通过ResponseFormat ChatResponseFormat.ForJsonSchemaCriticDecision()我们要求模型按照 CriticDecision 的 JSON Schema 返回结果从而让程序可以稳定解析CriticDecision decision JsonSerializer.DeserializeCriticDecision(...)不过需要注意approvedtrue 或 approvedfalse 的初始判断来自 LLM。Agent Framework 只是提供结构化输出能力并不会替我们判断内容质量。程序侧仍然可以在必要时覆盖这个判断例如达到最大迭代次数时自动批准if (!decision.Approved state.Iteration Program.MaxIterations) { decision.Approved true; decision.Feedback ; }这就是防止无限循环的安全阀。Summary Agent输出最终内容当 Critic 返回 Approved true 时工作流会进入 Summary Agent。 Summary Agent 的职责不是继续评审而是将最终通过的内容呈现给用户internal sealedclassSummaryExecutor : ExecutorCriticDecision, ChatMessage { privatereadonly AIAgent _agent; public SummaryExecutor(IChatClient chatClient) : base(Summary) { this._agent new ChatClientAgent( chatClient, name: Summary, instructions: 你将最终批准后的内容呈现给用户。 仅输出润色后的最终内容——不需要任何额外说明。 ); } public override async ValueTaskChatMessage HandleAsync( CriticDecision message, IWorkflowContext context, CancellationToken cancellationToken default) { Console.WriteLine( 总结 \n); string prompt $呈现此已批准的内容\n\n{message.Content}; StringBuilder sb new(); awaitforeach (AgentResponseUpdate update inthis._agent.RunStreamingAsync(new ChatMessage(ChatRole.User, prompt), cancellationToken: cancellationToken)) { if (!string.IsNullOrEmpty(update.Text)) { sb.Append(update.Text); } } ChatMessage result new(ChatRole.Assistant, sb.ToString()); await context.YieldOutputAsync(result, cancellationToken); return result; }SummaryExecutor 继承自ExecutorCriticDecision, ChatMessage这表示它接收 Critic 的决策结果并输出最终的 ChatMessage。这里的关键方法是context.YieldOutputAsync(result, cancellationToken);它用于向工作流外部发布最终输出。外层的 WatchStreamAsync 会接收到 WorkflowOutputEvent然后打印最终结果。工作流图与条件路由三个执行器定义完成后需要通过 WorkflowBuilder 组织成工作流图WorkflowBuilder workflowBuilder new WorkflowBuilder(writer) .AddEdge(writer, critic) .AddSwitch(critic, sw sw .AddCaseCriticDecision(cd cd?.Approved true, summary) .AddCaseCriticDecision(cd cd?.Approved false, writer)) .WithOutputFrom(summary);这段代码定义了完整的路由关系第一次进入 Writer 时输入类型是 string因此匹配 HandleInitialRequestAsync。当 Critic 不通过时它返回的是 CriticDecision。这个对象再次流入 Writer因此匹配 HandleRevisionRequestAsync。这也是 [MessageHandler] 的关键作用对于继承自非泛型 Executor 的执行器可以定义多个消息处理方法框架根据进入节点的数据类型选择对应方法。而对于ExecutorTInput, TOutput 输入类型已经由泛型参数 TInput 明确指定因此框架会调用其重写的 HandleAsync 方法。状态控制在 Writer–Critic 工作流中状态控制非常重要。因为 Writer 和 Critic 之间存在循环如果没有状态记录就无法判断当前已经迭代了多少次也无法设置最大迭代次数。状态定义如下internal sealed class FlowState { public int Iteration { get; set; } 1; public ListChatMessage History { get; } []; }其中Iteration 表示当前迭代轮次。 History 保存 Writer 输出和 Critic 决策记录。 状态通过 IWorkflowContext 读写internal staticclassFlowStateShared { publicconststring Scope FlowStateScope; publicconststring Key singleton; } internalstaticclassFlowStateHelpers { public static async TaskFlowState ReadFlowStateAsync(IWorkflowContext context) { FlowState? state await context.ReadStateAsyncFlowState( FlowStateShared.Key, scopeName: FlowStateShared.Scope); return state ?? new FlowState(); } public static ValueTask SaveFlowStateAsync(IWorkflowContext context, FlowState state) context.QueueStateUpdateAsync( FlowStateShared.Key, state, scopeName: FlowStateShared.Scope); }ReadStateAsync 用于从工作流上下文中读取状态。如果之前没有保存过状态则返回 null因此这里会创建一个新的 FlowState。QueueStateUpdateAsync 用于将修改后的状态保存回工作流上下文使后续执行器能够读取到更新后的状态。在 Writer 中状态主要用于记录生成历史state.History.Add(new ChatMessage(ChatRole.Assistant, text)); await FlowStateHelpers.SaveFlowStateAsync(context, state);在 Critic 中状态用于控制循环次数if (!decision.Approved state.Iteration Program.MaxIterations) { decision.Approved true; decision.Feedback ; } if (!decision.Approved) { state.Iteration; }因此状态控制的逻辑是第 1 轮 Writer 生成内容 Critic 评审 如果不通过Iteration 增加到 2第 2 轮 Writer 根据反馈修订 Critic 再次评审 如果不通过Iteration 增加到 3第 3 轮 Writer 再次修订 Critic 再次评审 如果仍不通过由程序侧强制批准避免无限循环 需要注意的是当前样例虽然把 Writer 输出和 Critic 决策写入了 History但并没有在后续 Agent 调用中将 History 作为上下文传给模型。因此History 在当前代码中更多用于记录、调试或后续扩展并不会自动影响模型生成结果。如果希望历史真正参与模型推理需要显式将 state.History 拼入 prompt或者构造完整的消息列表传给 Agent。小结Writer–Critic 工作流展示了 Agent Framework 中一种典型的多 Agent 协作模式。它的核心机制包括Writer Agent 负责生成和修订内容。 Critic Agent 负责评审内容并通过结构化输出返回 CriticDecision。 Summary Agent 负责输出最终通过的内容。 工作流通过 AddSwitch 根据 Approved 字段进行条件路由。 IWorkflowContext 用于跨执行器共享状态。 Iteration 用于限制最大循环次数避免无限迭代。 [MessageHandler] 允许同一个 Executor 根据输入类型处理不同场景。生成 - 评审 - 不通过修订 - 通过输出 这个样例的价值不只是展示多个 Agent 如何串联更重要的是展示了如何把 LLM 的不确定输出纳入一个可控的工程流程中通过结构化输出获得可解析的决策通过条件路由实现闭环通过共享状态控制迭代边界。源代码地址https://github.com/bingbing-gui/dotnet-agent-playbook/tree/master/src/ai-agent/Agent-Framework/39-WriterCritic-Pattern
相关文章
AI赋能医疗影像：重塑精准诊疗新范式
一、引言：医疗影像的行业困境与智能化需求医疗影像作为现代临床诊疗的“金标准”，是疾病筛查、病情诊断、术前评估、术后复查的核心依据，涵盖CT、X光、核磁共振、超声、病理切片等多种检查形式，贯穿疾病诊疗全流程。在医疗体系中&…
别再只看平均响应时间了！用Python和Excel实战解读P90/P95/P99，让你的性能报告更专业
性能测试报告进阶指南：用Python和Excel挖掘P90/P95/P99的真实价值当系统突然在凌晨两点崩溃，客服电话被打爆时，你会发现平均响应时间这个"老好人"指标有多不可靠——它永远微笑着告诉你"一切正常"，却对那1%卡…
2026年苏州活动策划公司效率大揭秘，究竟有多高？快来一探究竟！
在当今竞争激烈的商业环境中，一场成功的活动对于企业的品牌推广、业务拓展起着至关重要的作用。而活动策划公司的效率，直接影响着活动的质量和效果。今天，我们就来深入揭秘2026年苏州活动策划公司的效率情况，以苏州独石传媒为例&a…
阿姆智创IBOX-6076R工控一体机，机器视觉设备控制升级
在工业智能化转型浪潮中，机器视觉设备作为工业“慧眼”，正从高端场景走向全行业普及，成为3C电子、汽车制造、半导体、食品医药、智能物流等领域提质增效的重要装备。阿姆智创作IBOX-6076R工控一体机，以RK3576强算力、可扩展四网口…
力扣HOT100（34）图论-岛屿数量
方法一：深度优先搜索（DFS，面试首选）1. 核心思路我们把网格看作一个无向图：每个 1 是一个顶点上下左右相邻的 1 之间有边相连解题步骤：遍历整个网格，遇到 1 说明发现了新岛屿，岛屿数 …
Taotoken 支持的最新模型更新速度与接入便利性观察
🚀 告别海外账号与网络限制！稳定直连全球优质大模型，限时半价接入中。 👉 点击领取海量免费额度 Taotoken 支持的最新模型更新速度与接入便利性观察 对于依赖大模型进行应用开发的团队和个人而言，能否快速、便捷地使用…
SPA如何被AI正确引用：从SSR到结构化数据的实战指南
1. 项目概述：当大模型遇上单页应用，一场关于“引用”的硬仗 如果你是一名开发者，或者深度依赖ChatGPT、Claude、Perplexity这类AI工具来辅助研究、写作或信息整理，那么“让它引用我的资料”这个需求你一定不陌生。我们常常会把自…
别再只会ls了！用C语言opendir/readdir遍历目录，实现你的第一个文件管理器
用C语言打造你的专属文件管理器：从opendir到readdir的深度实践你是否已经厌倦了在终端反复输入ls命令查看目录内容？作为开发者，理解底层实现原理远比单纯使用工具更有价值。今天，我们将用C语言的文件操作函数，从零构建…
FP7125停产断供？替代物料FP7135详解来了
FP7135完美替代FP7125，已经量产上车性能还更强，它延续了FP7125的核心优势，同样支持8~100V宽电压输入。8A大电流输出搭配共阳输出设计，满足大功率LED驱动需求，覆盖各类照明场景。 PWM调光深度做到了0.1%，让灯…
大模型核心加速器：KV Cache 如何将 O(n²) 计算复杂度降至 O(n)？
KV Cache 是大模型自回归生成任务的关键优化技术，通过“空间换时间”策略缓存历史 Key 和 Value 向量，将推理复杂度从 O(n) 降至 O(n)。文章阐述了语义缓存与前缀精确匹配两种核心范式，深入分析了 KV Cache 的技术底层原理、工程化应用及规模…
物流系统如何打通信息孤岛？哲盟软件系统：一键打通内外部数据壁垒
在数字化转型加速的今天，物流企业面临的最大痛点之一就是信息孤岛——ERP、电商平台、智能硬件、OMS/TMS/WMS等系统各自为政，数据无法自由流转，导致人工操作繁琐、效率低下、出错率高。特别是在跨境物流领域，亚马逊、Shopee、TikT…
Windows Defender终极恢复指南：5种强力方法解决禁用问题
Windows Defender终极恢复指南：5种强力方法解决禁用问题 【免费下载链接】no-defender A slightly more fun way to disable windows defender firewall. (through the WSC api) 项目地址: https://gitcode.com/GitHub_Trending/no/no-defender 当你的Windo…
施工现场安全事故预警准确率达94.6%？——解密某央企AI Agent边缘计算部署架构与3个月落地实录
更多请点击： https://codechina.net 第一章：施工现场安全事故预警准确率达94.6%？——解密某央企AI Agent边缘计算部署架构与3个月落地实录 在华北某大型地铁盾构施工现场，一套轻量化AI Agent系统于2024年Q2完成全栈部署ÿ…
附录 B：术语表
本术语表面向“从 MM 到 HMM”专栏阅读过程中的快速查阅。它不是内核 API 手册，而是把文章中反复出现的概念放到同一张地图上：先给出直观含义，再说明它在 Linux MM/HMM 语境里的作用。建议阅读方式： 初读专栏时，把它当…
Midjourney渐变美学的神经渲染原理（附RGB-HSV-LCH三空间渐变映射对照表·行业首曝）
更多请点击： https://kaifayun.com 第一章：Midjourney渐变美学的神经渲染原理（附RGB-HSV-LCH三空间渐变映射对照表行业首曝） Midjourney 的渐变美学并非传统插值实现，而是由其隐式神经渲染器（Implicit Neu…
MPC-BE：基于DirectShow架构的专业级开源媒体播放解决方案
MPC-BE：基于DirectShow架构的专业级开源媒体播放解决方案 【免费下载链接】MPC-BE MPC-BE – универсальный проигрыватель аудио и видеофайлов для операционной системы Windows. 项目地址:…
如何快速计算3D模型体积和重量：STL-Volume-Model-Calculator终极指南
如何快速计算3D模型体积和重量：STL-Volume-Model-Calculator终极指南 【免费下载链接】STL-Volume-Model-Calculator STL Volume Model Calculator Python 项目地址: https://gitcode.com/gh_mirrors/st/STL-Volume-Model-Calculator 你是否曾经为3D打印项目…
通过Taotoken CLI工具一键配置团队开发环境与模型密钥
通过Taotoken CLI工具一键配置团队开发环境与模型密钥 1. CLI工具安装与基本使用 Taotoken提供的CLI工具可通过npm全局安装或直接使用npx运行。对于需要频繁使用CLI的团队，推荐全局安装： npm install -g taotoken/taotoken对于临时使用或项目级配置&a…