1. 为什么资料汇编这件事值得用 Agent 编排重做一遍做历史专题资料汇编的人大概都有过这种体验一个专题从立项到成稿真正花在找资料上的时间可能只占三成剩下七成全耗在整理、比对、去重、补漏、格式统一这些看起来没什么技术含量、但极其消耗耐心的环节上。更麻烦的是历史类资料有个天然特性——同一件事在不同来源里的表述可能互相矛盾时间线、人物关系、事件因果经常需要交叉验证人工做这件事不仅慢而且容易在疲劳时漏掉关键矛盾点。我这次要复盘的项目就是围绕历史专题资料汇编这个场景从零搭一套 AI Agent 编排架构。注意这里说的从 0不是指从零写一个大模型而是指在没有现成编排框架、没有成熟工作流模板的前提下把资料采集→清洗→结构化→交叉校验→汇编成稿→质量复核这条链路拆成多个可独立运行、又能互相传递上下文的 Agent 任务并用一套调度逻辑把它们串起来。关键词里提到的六轮真实任务复盘指的是我在实际跑这套架构时针对同一个历史专题连续做了六轮完整任务每一轮都记录下 Agent 的表现、编排层的调度决策、以及人工介入的位置。这六轮不是简单的重复而是每轮都在上一轮暴露的问题上做针对性调整——有的轮次改的是任务拆分粒度有的改的是 Agent 之间的上下文传递方式有的改的是校验环节的触发条件。这篇文章适合三类人看一是正在做资料汇编、专题整理、知识库构建相关工作想看看 AI 能不能真正帮上忙的从业者二是对 Agent 编排有兴趣但还没找到合适落地场景的开发者三是单纯好奇多个 AI 任务串起来干活到底靠不靠谱、坑在哪里的技术爱好者。我会把六轮复盘里最有价值的发现、最容易被忽略的细节、以及那些文档里不会写但实际一定会遇到的问题尽量讲透。需要提前说明的是这套架构里所有涉及具体历史专题的内容我都会用虚构代称处理重点放在架构设计、任务拆分逻辑、编排策略和踩坑经验上。你完全可以把这套思路迁移到自己的资料整理场景里不管是历史、法律、医学还是行业调研底层逻辑是相通的。2. 把汇编拆成 Agent 能接住的六类任务2.1 先想清楚哪些环节适合交给 Agent哪些必须留给人很多人一上来就想让 Agent 从头到尾全自动跑完结果发现中间某个环节一旦出错后面全盘皆输而且根本不知道错在哪。我在第一轮任务里就犯了这个错误——把资料采集和事实校验混在一个 Agent 任务里导致 Agent 既要判断这条资料要不要收又要判断这条资料可不可信两个判断标准互相干扰输出质量很不稳定。后来我重新梳理了一遍把整个汇编流程拆成六类任务每类任务对应一个独立的 Agent 角色任务类型核心职责是否适合全自动人工介入点采集任务按主题关键词抓取候选资料适合关键词表需人工确认清洗任务去重、去噪、格式归一适合抽样检查即可结构化任务抽取时间、人物、事件、来源适合字段定义需人工定校验任务交叉比对矛盾点、标记存疑半自动存疑项必须人工裁决汇编任务按大纲组织成稿半自动大纲需人工审核复核任务检查遗漏、逻辑断裂适合最终稿人工终审这个拆分的关键在于采集和清洗可以放心交给 Agent 批量跑但校验和汇编必须留出人工裁决的接口。历史资料的特殊性在于矛盾本身可能就是有价值的信息——两个来源说法不一致不一定是谁错了可能是不同立场、不同时期的记录差异。这种判断 Agent 做不了也不应该让它做。2.2 每个 Agent 任务的输入输出契约怎么定拆完任务类型下一步是定义每个任务的输入输出契约。这一步看起来枯燥但直接决定了编排层能不能顺畅地把任务串起来。我的做法是每个 Agent 任务都必须明确三件事——输入是什么格式、输出是什么格式、失败时返回什么。以结构化任务为例它的输入是一批清洗后的文本片段输出是一个结构化记录列表每条记录包含时间、地点、涉及人物、事件摘要、来源标识、原文片段。失败时不是简单报错而是返回一个部分成功的结果把无法结构化的片段单独标记出来附上失败原因。这里有个很容易被忽略的细节Agent 的输出格式必须足够稳定编排层才能做自动路由。我前两轮用的是自由文本输出结果编排层每次都要额外花一个 Agent 任务去解析上一步的输出既浪费算力又引入不确定性。第三轮改成强制 JSON 输出后编排层的调度逻辑一下子清爽了很多。提示定义输出契约时宁可字段多一点、结构死一点也不要为了灵活留自由文本字段。Agent 编排里灵活性应该放在任务拆分层面而不是单个任务的输出格式上。2.3 编排层到底在编排什么很多人以为编排层就是按顺序调用 Agent其实远不止。我这套架构里编排层实际承担了四个职责第一是任务路由根据当前上下文决定下一步该跑哪个 Agent。比如采集任务返回的候选资料数量低于阈值时编排层会自动触发扩展关键词再采集的分支而不是直接进入清洗。第二是上下文裁剪Agent 的上下文窗口是有限的不能把前面所有任务的输出都塞给下一个 Agent。编排层需要根据任务类型只传递相关字段。比如校验任务只需要结构化记录和来源标识不需要原始文本全文。第三是失败重试与降级某个 Agent 任务失败时编排层不是简单重跑而是根据失败类型决定策略。格式解析失败就重跑一次内容质量不达标就降级到人工队列。第四是进度与状态管理六轮任务跑下来我发现最容易被低估的就是状态管理。哪些资料已经处理过、哪些还在队列里、哪些被标记为存疑这些状态必须有一个统一的存储层否则 Agent 之间会重复劳动。2.4 六轮任务分别验证了什么简单交代一下六轮任务的侧重点后面几章会展开讲每轮的具体发现第一轮验证基本链路能不能跑通结果暴露了任务粒度太粗的问题。第二轮调整任务拆分重点看 Agent 之间的上下文传递是否顺畅。第三轮引入强制结构化输出解决编排层解析困难。第四轮加入校验 Agent专门处理矛盾点标记。第五轮优化编排层的失败重试和降级策略。第六轮整体压测看这套架构在资料量翻倍时的表现。每一轮我都记录了三个指标任务完成率、人工介入次数、最终成稿质量评分。这三个指标的变化基本能反映架构调整是否有效。3. 采集与清洗Agent 最容易用力过猛的两个环节3.1 采集任务的关键词策略宽进严出还是严进宽出采集任务看起来简单——给关键词抓资料。但实际跑起来第一个要做的决策就是关键词应该宽还是严我第一轮用的是严进策略关键词卡得很死结果采集回来的资料数量太少很多有价值的边角信息根本没进来。第二轮改成宽进关键词放得很开资料量上来了但清洗环节压力剧增而且大量无关内容混进来反而拉低了整体效率。第三轮我找到了一个相对平衡的做法采集阶段用核心词扩展词两层策略。核心词是专题必须覆盖的扩展词是可能相关的。采集 Agent 对核心词命中的资料标记为高优先级对扩展词命中的标记为待定。清洗环节优先处理高优先级资料待定资料根据后续校验结果决定是否纳入。这个策略的好处是采集阶段不用做太精细的判断把要不要的决策推迟到清洗和校验环节而那两个环节有更充分的上下文来做判断。3.2 清洗去重的坑历史资料里的重复往往不是真重复清洗任务里最耗时的就是去重。但历史资料有个特点两段文字看起来很像可能一个是原始记录一个是后人转述一个是不同版本的抄本。简单用文本相似度去重会把有价值的版本差异直接删掉。我在第二轮任务里就踩了这个坑——用相似度阈值 0.85 做去重结果把两个不同来源对同一事件的不同描述合并成了一条丢失了表述差异这个重要信息。后来改成分层去重第一层完全相同的文本直接合并保留来源列表。第二层高度相似但有关键差异的文本不合并而是标记为同源异述一起保留。第三层相似度较低但主题相关的文本正常保留不做特殊处理。这个分层逻辑写进清洗 Agent 的指令后去重环节的信息损失明显减少。代价是清洗后的资料量比之前多了大概三成但考虑到历史汇编对版本差异的敏感度这个代价是值得的。3.3 格式归一别小看标点和日期格式清洗环节还有一个容易被轻视的工作格式归一。历史资料里日期格式五花八门有某年某月、有某朝某代某年、有公历有农历标点用法也不统一。如果不在清洗阶段统一后面结构化任务会非常痛苦。我的做法是在清洗 Agent 里加一个格式标准化子任务专门处理三类格式日期格式统一转成公历年份-月份的近似格式无法精确转换的保留原文并标记。标点符号统一全角半角统一引号样式。数字格式中文数字和阿拉伯数字统一但保留原文中的特殊计数方式如若干数十年。这里有个经验格式归一不要追求一步到位。我一开始想让清洗 Agent 把所有日期都转成精确公历结果发现很多历史日期根本没法精确转换Agent 要么瞎猜要么报错。后来改成能转就转不能转就标记反而更实用。3.4 清洗质量的抽样检查怎么做才有效清洗任务全自动跑完之后必须做抽样检查。但抽样不是随便抽几条看看而是要有针对性。我的抽样策略是从高优先级资料里抽 10%检查是否有误删。从同源异述标记里抽 20%检查标记是否准确。从格式转换失败的记录里抽 50%检查失败原因是否合理。这个抽样比例不是拍脑袋定的而是根据前三轮任务里各类问题的出现频率调整出来的。高优先级资料误删率低所以抽 10% 就够格式转换失败率高所以要多抽一些。注意抽样检查的结果要反馈回清洗 Agent 的指令里。我在第四轮任务里发现把上一轮的抽样问题总结成几条注意事项加进 Agent 指令下一轮的清洗质量会有明显提升。这相当于让 Agent 在任务之间积累经验。4. 结构化与校验让 Agent 学会标记不确定而不是强行给答案4.1 结构化字段怎么定从汇编大纲倒推结构化任务要抽取哪些字段不应该拍脑袋决定而应该从最终的汇编大纲倒推。我的做法是先人工写一版汇编大纲看大纲里每个章节需要哪些信息然后把这些信息拆成结构化字段。比如大纲里有一章是事件时间线那结构化字段就必须包含时间和事件摘要有一章是人物关系那字段里就必须有涉及人物和人物角色。这样倒推出来的字段每一个都有明确的用途不会出现抽了一堆字段但汇编时用不上的情况。六轮任务下来我最终确定的结构化字段是时间、地点、涉及人物、事件摘要、来源标识、原文片段、可信度标记、版本标记。其中可信度标记和版本标记是第四轮才加上的因为校验环节需要这两个字段来做矛盾点分析。4.2 校验 Agent 的核心逻辑找矛盾而不是判对错校验任务是整套架构里最特殊的一环。我一开始的想法是让 Agent 判断哪条资料是对的后来发现这完全不现实——历史资料的对错往往需要专业背景知识Agent 没有这个能力强行判断只会产生误导。第四轮任务里我把校验 Agent 的职责重新定义为只负责找矛盾不负责判对错。具体来说它做三件事第一时间矛盾检测同一事件在不同资料里的时间表述是否冲突。第二人物矛盾检测同一事件涉及的人物在不同资料里是否不一致。第三因果矛盾检测同一事件的起因、结果在不同资料里是否有明显差异。检测到矛盾后Agent 不给出谁对谁错的结论而是生成一条存疑记录包含矛盾双方的信息、矛盾类型、以及建议的裁决方向比如建议查证原始出处。这些存疑记录会进入人工裁决队列。这个改动带来的效果非常明显第四轮任务的人工介入次数比第三轮下降了约四成因为人工不再需要从头检查所有资料只需要处理 Agent 标记出来的存疑项。4.3 存疑记录的优先级怎么排存疑记录多了之后人工裁决也需要排优先级。我的排序逻辑是三个维度加权影响范围这个矛盾涉及的是核心事件还是边角信息核心事件的矛盾优先级更高。矛盾程度是完全冲突还是细微差异完全冲突的优先级更高。来源可信度矛盾双方的来源标识是否可靠如果一方来源明显更可靠优先级可以降低。这三个维度加权后存疑记录会被分成必须裁决建议裁决可暂缓三档。实际跑下来真正需要人工仔细裁决的通常只占存疑记录的两成左右其余要么可以快速判断要么可以暂时搁置不影响成稿。4.4 结构化输出的稳定性怎么保证结构化任务最容易出现的问题就是输出不稳定——同样的输入两次跑出来的字段格式可能不一样。这在编排架构里是致命的因为下游任务依赖上游的稳定输出。我试过几种方案最后发现最有效的是双重约束一是在 Agent 指令里给出严格的 JSON Schema二是在编排层加一个格式校验步骤对不符合 Schema 的输出直接打回重跑。这里有个细节重跑时不要把原始输入原样再给一遍而是把上次输出哪里不符合 Schema作为附加信息一起给 Agent。这样重跑的成功率会高很多。我在第五轮任务里加了这个机制后结构化任务的一次通过率从大概七成提升到了九成以上。5. 汇编与复核Agent 写初稿人做终审5.1 汇编 Agent 的输入不是所有资料而是裁决后的资料汇编任务最容易犯的错误就是把前面所有环节的资料一股脑塞给 Agent让它自己看着办。我第一轮就是这么干的结果 Agent 把存疑资料也写进了初稿而且没有标注导致初稿里混入了不少未经裁决的内容。正确的做法是汇编 Agent 只接收已裁决的资料。存疑记录在人工裁决之前不进入汇编环节。裁决后的资料会带上已确认已修正已排除三种标记汇编 Agent 根据标记决定哪些内容写入初稿、哪些内容作为待考附注。这个改动让初稿的可靠性大幅提升。第五轮任务的初稿里需要人工大改的地方比第一轮少了将近一半。5.2 大纲驱动还是资料驱动两种汇编策略的取舍汇编 Agent 的工作方式有两种一种是大纲驱动先定大纲再往每个章节里填资料另一种是资料驱动先把资料聚类再根据聚类结果生成大纲。我两种都试过。大纲驱动的好处是结构清晰成稿逻辑性强坏处是如果资料和大纲不匹配会出现硬填的情况。资料驱动的好处是充分利用资料坏处是成稿可能比较散需要额外花时间调整结构。最后我采用的是混合策略先用资料驱动生成一版资料聚类大纲再人工调整成目标大纲然后汇编 Agent 按目标大纲来组织内容。这样既保证了大纲的合理性又避免了硬填。5.3 复核 Agent 查什么遗漏、断裂、重复复核任务是在初稿完成后跑的。我让复核 Agent 重点查三类问题遗漏大纲里有的章节初稿里是否都有对应内容。断裂章节之间的逻辑衔接是否顺畅有没有突然跳转。重复同一信息是否在不同章节里重复出现。这三类问题里断裂是最难自动检测的因为逻辑衔接好坏很主观。我的做法是让复核 Agent 只标记疑似断裂的位置并给出理由最终判断还是交给人工。实际跑下来复核 Agent 标记的疑似断裂点里大约有六成确实是需要修改的这个准确率已经足够帮人工节省大量时间。5.4 终审环节人应该重点看什么终审是最后一道关人工不可能逐字逐句看所以要抓重点。我的终审清单是存疑记录的裁决结果是否都正确反映在终稿里。核心事件的时间线是否连贯、无矛盾。关键人物的关系描述是否前后一致。附注和待考标记是否清晰、不误导读者。这四项检查完基本就能保证终稿的质量底线。至于文笔、可读性这些属于锦上添花有时间就打磨没时间也不会影响资料的可用性。6. 六轮复盘里最值钱的几条经验6.1 编排层不要追求全自动要追求可中断可恢复六轮任务跑下来我最大的体会是Agent 编排架构的价值不在于全自动而在于可中断可恢复。历史资料汇编这种任务中间必然需要人工裁决架构设计时必须假设随时会停下来等人而不是假设一口气跑完。具体做法是每个 Agent 任务的输出都持久化存储编排层记录每个任务的完成状态。中断后重新启动时编排层从上次中断的地方继续而不是从头再来。这个机制在第五轮任务里救了我一次——跑到一半系统需要维护重启后直接从断点继续没有浪费已经完成的工作。6.2 Agent 之间的上下文传递宁少勿多前面提过上下文裁剪这里再强调一次Agent 之间的上下文传递宁少勿多。我第二轮任务时为了让每个 Agent 信息充分把前面所有输出都传给下一个 Agent结果不仅浪费上下文窗口还导致 Agent 被无关信息干扰输出质量反而下降。后来我改成按需传递每个 Agent 任务在定义时就明确声明我需要上游的哪些字段编排层只传这些字段。这个改动让每个 Agent 的输入都变得干净、聚焦输出质量明显提升。6.3 失败重试要有上限降级路径要提前设计Agent 任务失败是常态不是异常。关键是要有重试上限和降级路径。我的设置是格式类失败最多重试两次内容类失败最多重试一次超过上限就降级到人工队列。降级路径必须提前设计好不能等失败了再想怎么办。我在第三轮任务时没设计降级路径结果一个 Agent 任务连续失败后整个流程卡死只能手动干预。第四轮加了降级队列后流程再也没卡死过。6.4 质量指标要可量化不能凭感觉六轮任务我都记录了三个指标任务完成率、人工介入次数、成稿质量评分。前两个是客观数据第三个是人工打分1-5 分。这三个指标的变化帮我判断每次架构调整是否有效。比如第三轮引入强制结构化输出后任务完成率从 78% 提升到 91%人工介入次数从 47 次降到 31 次成稿质量评分从 3.2 提升到 3.8。这些数据比感觉好多了有说服力得多。6.5 最容易被低估的环节状态管理如果只能给一条建议我会说把状态管理做好。Agent 编排里状态管理是最不显眼但最关键的环节。哪些资料处理过、哪些没处理、哪些在队列里、哪些被标记这些状态如果没有统一管理Agent 之间就会重复劳动甚至互相覆盖结果。我的做法是用一个轻量级的状态存储就是一个结构化的任务状态表每个 Agent 任务开始和结束时都更新状态。编排层调度时先查状态表避免重复调度。这个机制看起来简单但省下的算力 and 时间非常可观。7. 如果你也想搭一套类似的架构从哪开始7.1 先跑通最小链路再逐步加环节不要一上来就搭完整架构。我的建议是先跑通采集→清洗→汇编这条最小链路哪怕每个环节都很粗糙先让流程能跑起来。跑通之后再逐步加入结构化、校验、复核环节。最小链路的价值在于它能让你快速发现哪些环节是真正的瓶颈。我第一轮跑最小链路时发现瓶颈不在采集而在清洗去重这个发现直接影响了后续的优化方向。7.2 任务拆分粒度一个 Agent 只做一件事任务拆分粒度是个需要反复调整的参数。我的经验是一个 Agent 只做一件事。如果发现一个 Agent 任务里包含两个独立的判断逻辑就应该拆开。但也不能拆得太细否则编排层的调度开销会超过任务本身的开销。判断标准是如果两个子任务共享大部分输入输出且总是一起执行就可以合并如果它们的输入输出差异较大或者执行频率不同就应该拆开。7.3 人工介入点要设计成队列而不是弹窗人工介入不要设计成流程跑到这里停下来等人操作而应该设计成把需要人工处理的内容放进队列人工有空时批量处理。这两种设计的体验差别很大——前者会阻塞整个流程后者可以让流程继续跑其他不依赖人工的部分。我的做法是所有需要人工裁决的内容都进入待裁决队列编排层在汇编环节之前检查队列是否清空。如果没清空就先跑其他不依赖裁决的任务等队列清空后再继续。7.4 从历史专题迁移到其他领域的注意事项这套架构的核心逻辑是通用的但迁移到其他领域时要注意几点法律类资料矛盾检测的重点是法条引用是否准确而不是事实是否冲突。医学类资料可信度标记的权重需要调高因为医学资料对来源可靠性要求更高。行业调研类资料时间敏感度更高过期资料需要更早标记。迁移时不要照搬字段定义而是根据领域特点重新设计结构化字段和校验规则。架构骨架可以复用但领域适配层必须重做。7.5 一个实际跑下来最稳的配置参考最后分享一套我实际跑下来最稳的配置供参考配置项推荐值说明采集关键词层级核心词扩展词核心词命中标记高优先级去重相似度阈值0.85分层处理高于阈值不直接删标记同源异述结构化输出格式强制 JSON Schema编排层加格式校验校验重试上限格式类 2 次内容类 1 次超限降级人工队列人工介入方式队列批量处理不阻塞主流程状态存储结构化任务状态表每个任务开始/结束更新这套配置不是最优解但在我跑的六轮任务里表现最稳定。你可以根据自己的资料特点和团队情况调整核心原则是流程可中断、状态可恢复、人工可批量介入。我在实际使用中发现这套架构最大的价值不是省了多少人力而是把人的精力集中到了真正需要判断的地方。采集、清洗、格式归一这些机械劳动交给 Agent人只需要处理存疑裁决和终审整个汇编工作的节奏会舒服很多。踩过几次坑之后我越来越觉得Agent 编排的关键不在于 Agent 有多强而在于编排层有没有把人机分工设计清楚。