《扣子编程从零开始搭建智能体 卢欣欣 清华大学出版社》【摘要 书评 试读】- 京东图书《扣子编程从零开始搭建智能体》全书案例持续更新-CSDN博客在进入具体节点设计之前必须先回答一个范式层面的问题同样是基于大模型的内容生成需求第7章选择了单Agent多工具的范式本章为何转而采用工作流多节点的范式这一问题的答案直接决定了后续所有设计决策的走向。8.2.1 Agent与工作流的本质差异Agent与工作流并不是同一类事物的两种命名而是两种本质不同的能力组织方式。Agent的核心是让大模型自主决定下一步做什么工作流的核心是让流程结构来决定下一步做什么。前者赋予系统更高的灵活性但也带来了不确定性后者牺牲了部分灵活性换来了高度的可预测性与可观测性。具体到本章的语境中行业热点内容生成是一个步骤明确、依赖关系清晰、输出格式严格的任务。新闻必须先搜索后判断文章必须先有结论后有正文配图必须先有提示词后生成图像。每一个步骤的输出都是下一个步骤的输入且这种依赖关系不会随着关键词的不同而变化。这种特征恰恰是工作流的最佳适配场景。反之如果允许Agent自主决定现在是先搜新闻还是先确定基调反而会带来三类风险一是顺序错乱先写文章后搜新闻二是节点遗漏忘了配图就直接结束三是循环重复不断重新搜索同一关键词。8.2.2 适用边界的判断准则从工程实践角度可以总结出Agent与工作流的三条判断准则。第一条是流程确定性。如果任务步骤可以提前完整描述工作流是首选如果任务步骤需要根据中间结果动态决定Agent更合适。第二条是输出契约严格度。如果需要严格的、可被下游系统消费的输出格式工作流的优势明显如果输出可以是开放式对话Agent的灵活性更被需要。第三条是失败可观测性。工作流的每一个节点都有独立的输入输出便于定位故障Agent的失败往往是整体失败难以诊断。表8-2把这三条准则整理为决策矩阵。表8-2 Agent与工作流的范式选择决策矩阵判断维度倾向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节将会详细讨论如何在扣子编程中落地这些契约。