1. 新闻摘要这件事为什么必须由Agent来做1.1 传统摘要工具与Agent的本质差异我在媒体技术部门干了快十年这两年最深的体会是新闻摘要这个活儿看起来简单实际上比想象中难得多。早些年我们也用过抽取式摘要工具就是把原文里看起来像重点的句子挑出来拼在一起。遇到通稿类新闻还行稍微复杂一点就露馅。句子之间逻辑接不上数字和引语经常打架碰到报道里有但是然而这种转折抽取式工具完全分不清哪段是最终结论拼出来的摘要经常让编辑哭笑不得。后来大模型出来把整篇新闻扔给模型让它概括效果好了不少但很快又遇到新问题通用模型回答了但它是没有任务意识的。你跟它说生成摘要它给你来一段漂亮的书面语放在新闻稿里行吗行。但放在突发新闻的推送场景里呢要60字以内、要带最新伤亡数字、要标注信源待核实——它做不到因为没有人告诉它这些约束它也不知道你手头有一条半分钟前刚发生的突发事件正在等推送。这就是AI Agent和普通模型的根本区别Agent是带着目标、带着工具、带着约束去执行任务的执行体而不是一个问答器。在新闻摘要这个场景里Agent要理解我是谁某个版面的值班助手我要干什么把这篇稿子压缩成摘要我的边界是什么字数、风格、时效、准确度我有哪些资源原文、历史稿件、信源数据库、审核规则。普通模型只知道回答而Agent知道干活。1.2 媒体摘要场景的三大硬约束做媒体行业的技术方案不能只盯着谁的摘要写得好得先看清楚这个业务场景自己有多特殊。我总结下来有三个硬约束几乎决定了整个Agent的设计方向。第一个是时效性。突发新闻的摘要要求在事件发生后几分钟内出来而且随着事件进展摘要可能要连续更新七八版。这意味着Agent不能走原文来了再从头生成的路子它得能增量处理前一轮已经确认的事实保留新增信息往里插过时信息删掉整篇摘要始终保持最新状态。第二个是准确性。新闻摘要不是菜谱宽容度极低。模型把3人受伤写成3人失踪或者把某位发言人的话改了个语气在新闻场景里就是事故。所以Agent不能只做生成这一步它必须有一个自我核查环节把摘要里的每个关键信息点切出来逐一和原文比对不一致就回炉重写。第三个是风格一致性。同样是摘要突发新闻要快、要短、要冷峻深度报道的摘要可以稍微放慢节奏把事情的前因后果说清楚社论摘要则要提炼观点而不是复述事实。一个Agent如果只会一种风格在编辑部里根本落不了地。我对团队的要求是摘要的风格必须和原稿的栏目气质对齐而不是模型自己想怎么写就怎么写。2. 动手搭Agent之前先把目标和边界拆明白2.1 输入输出边界先回答什么活儿不该交给Agent很多项目死在第一步——恨不得把编辑部所有活儿都塞给Agent。我的经验是先明确什么活儿不该交给Agent剩下的才是Agent该干的。不适合交给Agent的新闻类型我列过一张清单。第一类是高敏感、强时效的报道比如重大突发事件的伤亡统计、司法案件的关键判决细节这类信息一旦摘要出错连带责任太重必须人写机校。第二类是编辑部已经形成固定模板的短文快讯本身正文就一两百字再生成摘要纯属脱裤子放屁。第三类是观点性极强的评论摘要会让观点失真这类稿子通常也不需要摘要标题就是观点。适合交给Agent的是可复述、可归纳、信息密度高的常规新闻社会新闻、财经短讯、体育赛事报道、文化活动报道、科技产品发布等。这类新闻的共同点是——读者需要的是快速知道发生了什么事摘要的价值最大出错的风险也可控。2.2 摘要约束条件不光是字数还有信息完整性确定完边界之后要把业务规则翻译成Agent能理解的约束条件。字数是最基本的但远远不够。我跟编辑团队一起整理了一套摘要约束清单每条都很具体字数要求不同版面不同短讯摘要60字以内普通新闻摘要控制在原文长度的15%到20%之间六要素覆盖什么人、什么事、什么时间、什么地点、为什么、结果如何前四者必须齐全数字准确性所有数字必须与原文一致必要时保留单位转换引语处理宏观引语可转述关键人物直接引语必须保留原话核心含义信息新鲜度摘要只承载原文中最新的关键进展历史背景除非直接影响理解否则不放入摘要结论前置第一句必须直接交代核心事实不允许铺垫。这些约束不是拍脑袋定的而是逐条从编辑部现有的摘要规范里提炼出来的。我建议任何想上Agent的团队都先做这一步——把业务规则文本化变成检查项而不是靠感觉。2.3 产品定位摘要Agent是编辑的助手不是编辑的替代最后特别想强调一个定位问题。摘要Agent做出来后它直接在编辑部值班但它的身份必须是助手不是替代。我们的设计是这样Agent生成的摘要全部进入待审核队列编辑可以一键改稿、一键驳回、一键采纳。Agent永远不会直接把摘要推进发布系统。这不是对技术不自信而是新闻行业的伦理底线——机器可以把编辑从重复劳动里解放出来但最终的发稿责任必须由人承担。这个定位也直接影响技术方案既然需要人审Agent的输出必须方便人工快速判断。所以我们要求Agent会输出摘要的同时附上摘要来源标注每个信息点对应原文的段落编号编辑一眼就能核对。这个设计在后期实测中被证明是编辑部最喜欢的功能。3. 技术选型与整体方案设计3.1 模型选型要的是听话不是炫技先聊模型选型。新闻摘要任务对模型的要求排序和很多人想的不一样。在我这儿第一要求是指令遵循能力——你说60字它就60字上下浮动不超过10%你说结论前置它就老老实实把核心事实放第一句。第二要求是中文长文本理解能力特别是读懂新闻里常见的倒金字塔结构以及虽然…但是…这类转折表达。第三才是语言组织能力只要别写出AI味太重的书面腔及格就行。跑了两个多月主流商用大模型API之后我们的结论是规模不需要最大但指令遵循必须最好。曾经有一个模型文采特别好但让它控制在80字以内它非要写成120字而且每次都要多一点这种模型在新闻场景里根本没法用。后来我们换了一个指令遵循更强的模型字数控制得死死的实测摘要通过率反而高得多。另外还要考虑延迟和成本突发新闻摘要要求首屏秒级出结果大模型API要是经常排队方案就得推翻重来。3.2 编排框架选型可视化平台和代码框架怎么取舍再聊Agent编排框架。目前主流就两条路一是用低代码的可视化Agent平台拖拽节点流程直观适合快速验证和业务人员参与二是用开源编排框架自己写代码灵活度高适合和现有新闻系统深度集成。我给团队的建议分两步走先用可视化平台把业务链路跑通验证效果再整体迁移到代码框架和现有的CMS系统做集成。不要一上来就铺开写代码因为编辑部的需求磨合期很长可视化平台上改一个节点比改代码快得多等需求稳定了再上代码框架把每个节点固化成可维护的代码模块。这里必须提醒一个坑可视化平台虽然方便但别把核心业务逻辑做成黑盒。摘要Agent的每个环节都要有日志、有中间产物可回溯。否则出了问题你不知道是模型抽风还是上游喂的数据有误还是Prompt写崩了。我在项目初期就吃过这个亏一个节点日志没开摘要连续三天出错居然找不到原因。3.3 核心链路从新闻生产流程反推Agent工作流这是整个项目最重要的设计决策Agent工作流不是技术人员凭空设计的而是从新闻编辑的现有生产流程反推出来的。我们花了一周时间跟着值班编辑走完整个生产流程把所有动作拆成节点然后看哪些节点能自动化、哪些必须保留人工。最后形成了摘要Agent的五个核心环节触发、采集、抽取、生成、核查。下面一节我会详细拆这五个环节。4. 核心工作流搭建五个环节的拆解与踩坑实录4.1 触发环节让Agent在正确的时间醒来摘要Agent不是24小时傻转的它得知道现在该干活了。我们的触发机制分几种定时触发整点批量扫描选题池、事件触发选题池里新增了带突发标签的稿件、人工触发编辑手动把稿子拖进Agent队列。这个环节最常踩的坑是触发噪音。刚开始我们把所有新入库的稿件都丢给Agent生成摘要结果大量低价值快讯和重复通稿挤满了编辑的审核队列编辑烦得要死。后来加了一道价值预筛先让一个轻量模型判断这篇稿子是否需要摘要以及时效级别再决定用哪个摘要模板。这个判断节点让编辑部的审核负担直接降了70%。4.2 采集与结构化吃进去的料不能脏摘要质量的一半取决于输入质量。很多团队只盯着Prompt优化忽略了上游数据清洗。新闻正文从CMS导出来通常带着大量杂质广告代码残留、相关阅读链接、图片说明、版权声明、上一版的修订记录。这些杂质一旦混进大模型摘要质量立即崩坏。我们的做法是分三步清洗第一步正则过滤明显杂质第二步用抽取模型识别正文主体段落第三步做信息结构化——把人名、地名、时间、数字、机构名、核心事件抽取出来形成一份结构化的事件要素表。这份要素表有两大用处一是直接喂给摘要生成环节要素齐全保证六要素不丢二是作为后面核查环节的比对基准。清洗这一步在网上有很多成熟的开源工具可以直接用关键是结合自家CMS的模板做定制规则光靠通用抽取效果打折扣。4.3 摘要生成环节Prompt工程是减法而不是加法生成摘要是核心节点但也是最容易翻车的地方。我见过很多人把Prompt写得跟论文似的恨不得塞进一百条规则。以我们的实测经验Prompt设计有四条铁律规则数量控制在5到8条超过8条模型就开始顾此失彼每条规则必须独立成句、逻辑互斥不能出现既要…也要…但又要…的分裂句式必须给正例和反例各给一个模型对例子的理解远超对抽象规则的遵从把禁止做的事单独列一节比如禁止补充原文未出现的信息禁止使用夸张形容词这类负向指令对新闻摘要的效果出奇地好。我们的摘要生成提示词最终版大概长这样简化展示你是某媒体平台突发事件摘要助手。你的任务是把给定的新闻正文压缩成摘要。 要求 1. 第一句必须直接交代核心事实人/事/时间/地点/结果 2. 全文字数控制在50-80字 3. 只使用原文出现的信息禁止推断和补充 4. 所有数字必须与原文完全一致 5. 禁止使用据悉据了解引发关注等套话 正面示例某路段发生交通事故两车相撞致3人受伤事故原因调查中 负面示例某路段发生交通事故据悉事故引发广泛关注伤亡情况正在进一步核实你会发现这个Prompt几乎没有创作的指令全是约束。做新闻摘要的Prompt做的是减法不是加法。少让它发挥它就不容易出错。4.4 核查环节宁可让编辑骂我慢也不能让发布出事故核查环节是整个Agent灵魂所在。我们的核查流程分三道第一道是要素核查把摘要里出现的每一个数字、人名、地名、时间点逐一与结构化要素表比对不一致就重新生成。第二道是来源核查对摘要的每一句生成它对应的原文依据段落编号没有依据的句子直接标记为待验证。第三道是模型自查把摘要和原文同时交给另一个模型实例让它扮演严格校对员逐句判断摘要是否有信息偏移。三道核查下来AI幻觉基本被摁死了。我们内部实测了几百条样本配上核查环节之后与原文存在事实出入的摘要比例从7.3%降到不到0.5%。你可能觉得三道核查太慢但我们衡量过摘要环节本身只耗时几秒钟核查环节多花几秒钟换来的是编辑部敢真正批量使用Agent这笔账非常划算。5. 实测中的意外情况与应对规范、幻觉、以及编辑的习惯5.1 标题党问题Agent学会了网媒的坏毛病上线第一个星期我们遇到一个之前完全没预料到的问题Agent生成摘要时会模仿网上各种标题党的语气。比如一篇讲某地举办文化节的稿子摘要开头写的是重磅某地文化节盛大开幕现场人流爆棚。文本本身没语法错误但作为新闻完全不合格。排查发现原因很微妙训练语料里包含大量网络新闻模型学到的摘要风格其实是被大量标题党污染过的。后来在Prompt的正向示例里刻意只放编辑部自己过往的规范摘要样本同时加了一条用该媒体平台的官方简讯语气禁止夸张和情绪化词语问题明显缓解。这个坑提醒我Prompt里的示例比规则更管用但示例必须来自你自己的业务场景而不是通用语料。5.2 AI幻觉最危险的故障类型做媒体AI最怕的就是幻觉。我们有次内部测试给Agent一篇讲某公司发布新款手机的长稿摘要居然写上了该手机售价约4999元将于6月1日开售——原文里压根没有价格信息和发售日期。模型是凭借对同类手机新闻的记忆自行脑补的。这是最危险的故障因为读起来非常合理人工审核一眼看过去很难发现破绽。为了按死幻觉除了前面说的三道核查我们还加了一个孤儿信息检测每个语义单位数字、日期、价格、引语都必须在原文中有锚点找不到锚点就整句重写。从那以后类似的问题基本没有再出现过。我也在这里劝所有同行做内容生成的Agent核查环节不能省如果你只能选一个环节投入开发资源选核查别选生成。5.3 编辑的习惯技术再好也得顺着人的工作流实测阶段最大的收获其实不是技术而是协作。刚开始我们把Agent生成的摘要直接放在审核列表里和编辑自己写的摘要混在一起。结果编辑根本不看全部驳回自己重新写。后来私下问了几个编辑回复出奇地一致谁知道你写的靠不靠谱我重写还快一些。后来我们改了一个交互设计Agent不是直接给摘要而是先给一份摘要建议稿原文对照依据编辑可以一键采纳、或者一键把自己的版本覆盖上去Agent再学习编辑改写的地方。这个学习编辑改写的反馈环才是Agent真正变好用的核心。跑了一个月之后某个固定版面的采纳率从不到5%升到了60%以上。技术再聪明也得顺着人的工作流走这是我在这个项目里最大的体会。6. 从能跑到好用评测集、反馈闭环与多Agent协同6.1 建一个属于你自己的评测集很多团队评估摘要Agent拿十几条新闻测一遍看个感觉就说还行。这在媒体行业完全不够。我从项目一开始就拉着两位资深编辑人工写了98条标准摘要覆盖六大新闻类别突发、时政通稿、财经、社会、体育、文娱。每条标准摘要背后都标好了为什么这么写的注释。这个评测集是整个项目的定海神针每次改Prompt、换模型、调参数都拿同一套评测集跑分科学得很。评测指标不能只看文本相似度。新闻摘要要看的核心指标是关键信息召回率六要素覆盖了多少、事实准确率有没有和原文冲突的信息、字数合规率在不在规定范围、人工采纳率编辑愿不愿直接使用。前三个技术指标可以自动化人工采纳率需要累计统计。6.2 反馈闭环让Agent在编辑部长大Agent上线之后不是一劳永逸需要持续学习。我们的反馈闭环是编辑每次对摘要建议稿的修改行为都会被记录修改超过三次的样本自动进入难点池。每周技术团队会分析难点池里的样本看是模型的指令理解问题还是Prompt缺了规则还是需要更新示例库。这个机制跑起来之后Agent的质量提升非常明显。比如有个反复出现的难点——引语处理。模型经常把受访者的直接引语改写成转述虽然意思没变但编辑认为丢失了原话的语气。后来我们专门在Prompt里加了一条当原文出现引号引语时保留引语原句不得改写。难点池里的问题就是这样被一个个解决的。6.3 再进一步摘要Agent的多智能体协同当单个Agent跑稳之后我们开始做多智能体协同。最初的场景来自一个很实际的需求同一篇突发新闻需要生成三套不同长度、不同风格的摘要——一套给App推送60字以内一套给网站快讯150字以内一套给编辑部内部研判500字以内。三套摘要如果各跑各的很容易跑出自相矛盾的信息。我们最后的方案是一个主编Agent负责阅读全文、维护一份事实要素主表三个执行Agent分别基于主表生成不同版本的摘要主编Agent最后统一校验三份摘要之间的逻辑一致性。这个主从协同的架构跑下来三份摘要的信息高度统一和过去三个编辑各写各的经常打架相比质量稳得多。离开这个项目的时候我又学到一句话当Agent不再是单一工具、而是一个协作团队的时候它才真正从能跑变成了好用。多智能体协同的核心不是堆数量而是先做好一个主从关系和共享的事实底座。这套思路放到任何内容生成类项目里都通用。