企业官网建设流程全解析

《扣子编程：从零开始搭建智能体 卢欣欣 清华大学出版社》【摘要 书评 试读】- 京东图书

《扣子编程：从零开始搭建智能体》全书案例持续更新-CSDN博客

在进入具体节点设计之前，必须先回答一个范式层面的问题：同样是基于大模型的内容生成需求，第7章选择了单Agent＋多工具的范式，本章为何转而采用工作流+多节点的范式？这一问题的答案，直接决定了后续所有设计决策的走向。

8.2.1 Agent与工作流的本质差异

Agent与工作流并不是同一类事物的两种命名，而是两种本质不同的能力组织方式。Agent的核心是让大模型自主决定下一步做什么，工作流的核心是让流程结构来决定下一步做什么。前者赋予系统更高的灵活性，但也带来了不确定性；后者牺牲了部分灵活性，换来了高度的可预测性与可观测性。

具体到本章的语境中，行业热点内容生成是一个步骤明确、依赖关系清晰、输出格式严格的任务。新闻必须先搜索后判断，文章必须先有结论后有正文，配图必须先有提示词后生成图像。每一个步骤的输出都是下一个步骤的输入，且这种依赖关系不会随着关键词的不同而变化。这种特征恰恰是工作流的最佳适配场景。反之，如果允许Agent自主决定现在是先搜新闻还是先确定基调，反而会带来三类风险：一是顺序错乱（先写文章后搜新闻）；二是节点遗漏（忘了配图就直接结束）；三是循环重复（不断重新搜索同一关键词）。

8.2.2 适用边界的判断准则

从工程实践角度，可以总结出Agent与工作流的三条判断准则。第一条是流程确定性。如果任务步骤可以提前完整描述，工作流是首选；如果任务步骤需要根据中间结果动态决定，Agent更合适。第二条是输出契约严格度。如果需要严格的、可被下游系统消费的输出格式，工作流的优势明显；如果输出可以是开放式对话，Agent的灵活性更被需要。第三条是失败可观测性。工作流的每一个节点都有独立的输入输出，便于定位故障；Agent的失败往往是整体失败，难以诊断。表8-2把这三条准则整理为决策矩阵。

表8-2 Agent与工作流的范式选择决策矩阵

8.2.3 九节点能力拆解

确认采用工作流范式之后，下一步是把整体目标拆解为可独立设计、可独立测试的节点。本章最终落地为9个节点：开始、新闻搜索、热点定调、内容模式路由、深度解读（条件分支 A）、盘点汇总（条件分支 B）、文章生成、图片提示词规划、图片生成、结束。这九个节点恰好对应内容生产的九个独立工序。

这种节点化拆解带来三个明显的工程收益。第一，每个节点都可以独立配置模型、温度、提示词，使得精度与成本可以在节点级精细权衡——例如热点定调对推理深度要求高，可使用Pro模型；图片提示词规划对结构化输出要求高，可使用Lite模型。第二，每个节点都可以独立测试与替换，例如未来想把搜索引擎从默认源换成专业财经数据源，只需替换搜索节点，其他节点完全不受影响。第三，节点级失败定位极大降低了调试成本，错误日志会直接告诉开发者是哪一个节点的输出格式不符合契约。

图8-1 工作流9节点DAG结构页面

8.2.4 条件分支：让流程具备判断力

如果九个节点只是简单的串联，工作流就和线性脚本没有本质区别，无法体现AI的价值。本章的关键创新在于第4个节点——内容模式路由，它让工作流具备了根据数据内容自主选择路径的能力。

具体来说，热点定调节点会输出一个content_mode字段，取值为重磅模式或日常模式。当内容路由节点检测到content_mode为重磅模式时，工作流自动进入深度解读分支，调用大模型进行单点深度分析；当检测到content_mode为日常模式时，工作流自动进入盘点汇总分支，调用大模型进行多点横向梳理。两条分支最终在文章生成节点合流。这种设计既保留了工作流的确定性骨架，又通过条件路由注入了AI的判断力，是确定性流程与智能化决策结合的典型代表。

8.2.5 编排难点：节点契约与数据流

以上节点划分听起来清晰，但真正实现时最容易出错的恰恰是节点之间的契约。所谓契约，就是上游节点的输出字段与下游节点的输入字段之间的对应关系。在多节点工作流中，一旦上下游字段名不一致、字段类型不匹配，或某个节点遗漏了下游必需的字段，整条流水线就会在该节点中断。

本章的契约设计原则有三条：其一是上游能给的，下游不再问——下游不应该重新去搜索数据，而应该直接消费上游已经生成的字段。其二是下游需要的，上游必须显式输出——上游不能只输出文本流，必须输出结构化字段。其三是全局共享变量与节点局部变量分离——例如keyword在整条流水线中均可访问，而news_list仅在搜索节点产生、在定调节点消费。后续8.4节将会详细讨论如何在扣子编程中落地这些契约。