“Chain”这个名字很容易让人产生一个误会只要把几个模型调用首尾相接就算搭好了应用。第 5 章从基础链、顺序链、路由链讲到 Stuff、Refine 和 MapReduce。读下来以后我更关心的反而是另一个问题一段流程什么时候值得封装成 Chain又有哪些逻辑应该老老实实留在普通代码里从一个客服流程开始假设用户提交一句反馈“升级后无法导出 Excel而且订单号是 A1024。”系统可能要做这些事识别问题类型 - 查询对应知识库 - 生成回复 - 检查是否需要转人工这是一条比较适合组合的流程因为每一步都有清晰的输入和输出分类器返回问题类型Retriever 返回文档模型根据文档生成草稿规则判断是否升级工单。但“用户有没有查看订单的权限”“工单是否已经创建”不适合让模型凭语义判断。权限、事务、幂等和金额计算应继续由确定性代码负责。顺序、路由和并行差别在控制流顺序流程适合前一步结果稳定地交给下一步。例如先抽取文章主题再按主题生成摘要。它容易理解但上游错误会一路传下去。路由流程先判断输入属于哪个分支例如售前咨询进入产品知识库故障问题进入排障知识库。文件类型、用户角色等确定条件可以直接用代码判断只有模糊的语义意图才值得交给模型分类。并行流程适合互不依赖的任务。例如同时生成摘要、关键词和风险提示最后再合并。并行可以降低整体延迟但要提前定义合并时的数据结构。无论使用哪种方式我都会先写清楚每一步的契约需要哪些字段产生哪些字段失败后是重试、跳过还是终止流程。长文档为什么有多种合并策略书中介绍的 Stuff、Refine 和 MapReduce可以用“怎样处理一摞材料”来理解。策略 做法 更适合的情况 主要代价Stuff 把材料一次交给模型 内容少、上下文放得下 噪声多容易超长Refine 先写初稿再逐份材料修正 答案需要持续完善 调用次数多受顺序影响MapReduce 分别处理再汇总中间结果 长文档、可并行任务 汇总时可能丢细节例如总结 100 页会议记录时Stuff 简单但可能塞不下MapReduce 可以先分章节提炼行动项再统一去重Refine 则适合沿时间顺序不断更新一份项目结论。策略没有固定排名。文档长度、预算、延迟、是否能拆分以及答案是否需要全局一致性都会影响选择。Chain 变长以后最先坏在哪里长链最麻烦的不是代码多而是错误位置和表现位置可能相隔很远。分类步骤输出了一个意外标签直到后面的 Prompt 缺变量时才报错摘要步骤遗漏了数字最后汇总出来的报告仍然语句通顺。我会给关键节点加三类保护中间结果尽量结构化并对字段做校验记录步骤名、输入摘要、输出摘要、耗时和错误给重试、并发和总调用次数设置上限。重要流程还可以保存中间状态。这样失败后不必从第一步重跑也能还原哪一步开始偏离。这章给我的启发Chain 最有价值的地方是把数据流和阶段边界表达清楚。它不是隐藏复杂度的盒子更不是所有代码都要进入的容器。如果一段流程连输入输出都说不清先套框架只会把问题藏起来。先画出数据怎样流动再决定哪些步骤组合、哪些分支显式书写通常会更稳。