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不再是单一工具、而是一个协作团队的时候，它才真正从"能跑"变成了"好用"。多智能体协同的核心不是堆数量，而是先做好一个主从关系和共享的事实底座。这套思路，放到任何内容生成类项目里都通用。
