1. 项目概述1.1 为什么要把“写研报”交给 Agent先交代一下背景我是一名大模型开发工程师2025年开始密集接触各类 Agent 框架和落地场景。当时团队接到一个内部需求要把“企业研报撰写”这件事半自动化。传统路径是这样行业分析师先定框架然后助理手动拉数据、翻公告、扒行业统计最后分析师花两三天建模、校验、写正文。一份中等深度的企业研报人力成本至少一周。我们做的事就是把这个流程拆成“框架规划—信息检索—数据抽取—交叉验证—章节写作—格式输出”六个环节用 Agent 编排一整条流水线。目标不是替代分析师做判断而是把“找资料、读资料、整理资料”的时间压缩到原来的十分之一让分析师把时间花在真正值钱的判断上。这个项目对两类人特别有价值一类是正在做 AI Agent 开发、想找一个真实企业级场景练手的工程师另一类是金融、咨询、投研团队里的技术负责人想评估 Agent 在研报场景里到底能干到什么程度。1.2 项目要达到什么效果先明确一个原则Agent 生成的研报不是“一次性交付物”而是一个“初稿生产系统”。最终交付的报告里每一段关键结论都必须能回溯到原始来源数字要能对得上财报原文引用要能点开看。我们给它起了个内部代号叫“研报流水线”这条流水线跑一次大约需要 8 到 15 分钟产出一份 5000 字左右、带引用上标的公司研究初稿。接下来我会把整个项目的架构设计、技术选型、提示词工程、踩坑实录全部拆开讲。我会尽量保持“直接、可落地”的风格因为这套东西我们已经在真实业务里跑了几百次很多细节是文档里不会写的。2. 企业研报 Agent 的整体设计与架构拆解2.1 先想清楚一个问题Agent 在这里到底“负责什么”很多人一上来就纠结框架但我建议先想清楚一个问题研报写作这个场景哪些步骤适合交给大模型哪些步骤绝对不能交给大模型。研报的本质不是“写”而是“判断”。一份合格的企业研报需要把公司的商业模式、财务状况、行业地位、风险因素讲清楚。这里面 80% 的信息是公开数据但公开数据不等于“已经整理好的数据”。大模型最擅长的是把散落在不同来源的信息按照某个逻辑框架组织起来再生成自然语言。它最不擅长的是做事实核查——模型会一本正经地编造一个看起来合理的数字而真正负责任的研报不允许出现一个未经核实的数字。所以架构上必须做一层“隔离”信息收集和分析判断交给 Agent但最终的事实校验和投资结论必须由人来收口。这个思路决定了下面整套架构的形态。2.2 六层架构从需求到报告的完整链路我们的研报 Agent 采用“分层流水线 子 Agent 并行”的架构。整体分成六层第一层需求解析层。输入是用户的一句话比如“分析一下某家动力电池公司的投资价值重点看产能和现金流”。这一层要做两件事一是解析出“目标公司”“分析维度”“时间范围”“报告深度”二是把用户需求转成一个结构化的“研究任务书”。第二层框架规划层。根据研究任务书规划出一个研报大纲。大纲不是简单的章节列表而是每个章节带着“需要什么数据”“数据从哪来”“需要几条独立证据交叉验证”的元信息。这一层我们用了不少提示词工程后面第三章会详细讲。第三层工具调度层。把研究大纲中的每个模块拆成可执行任务调度各种工具去执行。工具包括联网搜索 API、年报 PDF 解析器、招股说明书抽取器、企业数据库查询接口、行业统计网站爬虫。这一层是 Agent 架构里最容易翻车的地方因为工具一多模型的“选择焦虑”就会出现——要么反复调用同一个工具要么干脆不调用。第四层数据抽取与记忆层。原始资料收集上来之后先不进大模型上下文而是先做结构化抽取。比如从年报 PDF 里抽出“营业收入、净利润、经营性现金流、资产负债率”这些指标存成 JSON。这个设计的核心动机是省 token、减幻觉。我后面会解释为什么这一步是关键中的关键。第五层写作编排层。按照大纲逐章节生成内容。这里不再是一个大模型从头写到尾而是“一个章节一个子 Agent”每个子 Agent 拿到的上下文是固定的、干净的一小段写作指令 相关结构化数据 参考来源摘要。第六层校验与输出层。对生成的报告做“数字一致性校验”“引用可回溯性校验”“完整性校验”全部通过后才转成 Markdown 或 PDF 输出。2.3 一个关键的架构决策为什么不做“全自动闭环”我们早期版本的设计目标是全自动——用户丢一个公司名字进去10 分钟后收到完整研报。跑了一段时间发现不行问题不在技术而在“信任”。研报读者对错误的容忍度极低。一个财务数据错了整份报告的可信度全部崩塌。而大模型生成的内容即使你把错误率压到 1%在金融场景里 1% 也是不可接受的。所以我们最终把“全自动闭环”改成了“人机协同闭环”。具体做法是流水线跑完之后不是直接输出报告而是输出一份“带证据包的初稿”。分析师拿到初稿后重点检查三样东西——关键假设是否成立、数据是否准确、结论是否有逻辑跳跃。这个改动看似让系统变得“不够炫酷”但实际效果反而是业务方愿意真正用起来的关键。3. 技术选型框架、模型与工具链的取舍3.1 主流通用框架对比2025 年下半年到 2026 年这个时间点市面上能用的 Agent 框架已经非常多而且分化明显。我按团队的实际体验给几个代表做一下横向对比框架核心特点适合场景主要痛点LangGraph图状态机节点和边完全可控复杂工作流、需要精细控制的项目学习曲线陡峭概念偏多AutoGen多 Agent 对话协作自动会话管理快速原型、研究性任务生产环境的可控性偏弱CrewAI角色化 Agent任务分解直观中小团队快速落地复杂分支场景不够灵活Coze/扣子可视化编排国内生态完善业务人员自助搭建定制深度受限百炼阿里云模型和企业工具集成度高已有阿里云生态的企业自托管能力偏弱我们最终选了 LangGraph 作为生产主干理由有两点。第一研报流水线本质上是一个“有严格顺序和分支逻辑”的工作流不是一个自由对话。LangGraph 把流程建模成节点和边的图结构每个节点可以绑定一个子 Agent 或者一个工具函数节点之间通过状态传递数据。这种“图状长流程”比“自由对话式编排”更适合研报这种必须稳定复现的流程。第二LangGraph 的 checkpoint 机制让我们能在任意节点插入人工审核。研报场景里有几个环节必须暂停等人确认比如“确认研究框架没问题再往下搜数据”。LangGraph 允许我们在图中间挂一个“interrupt”流程跑到那里会停下来等人通过 API 确认后继续。这在业务上价值极大。另外提一下 Hermes Agent。如果你只是想要一个轻量的、跑在桌面上的助手型 AgentHermes 这类产品确实开箱即用、省事。但企业研报这种场景需要的是可控的流水线、可审计的工具调用、可回溯的引用链自成体系的桌面型 Agent 就不太合适了。我们的经验是工具型 Agent 和流水线型 Agent 是两条路线选型前先搞清楚自己到底需要哪一种。3.2 配套模型与工具链的具体选择框架定了之后模型选择上我们采用“分工合作”而不是“一个模型干所有活”。规划层用一个强推理模型——负责任务拆解和大纲设计对长文本理解要求高写作层也用一个长上下文模型——负责生成章节内容但抽取层和校验层我们用的是一个小参数、低成本的模型——因为抽取只需要遵循固定格式校验只需要做模式匹配用大参数模型纯属浪费。这个分工带来的成本节省非常可观。我们的线上数据显示同样跑一份研报全流程用同一个旗舰模型token 消耗大约是分层模型的 3.2 倍而报告质量没有显著差异。工具链方面我们自建了两个关键工具年报抽取器输入 PDF 文件路径输出结构化财务数据。内部实现是“版面分析 OCR 表格识别 实体对齐”。这一步是整个系统中技术含量最高的模块没有现成的开源工具能直接满足精确要求必须自己调。引用追踪器记录每个检索来源的 URL、标题、抓取时间、关键段落给每段研报内容生成引用标记。最后生成的报告里每个引用的数字旁边会有一个上标数字点击能跳转到来源网页。3.3 关于“Harness 与 Agent 的区别”的选型思考搜索热词里有个问题Harness 和 Agent 的区别是什么。这个恰好是我们项目里真实纠结过的问题。简单说Agent 是一个“决策主体”它根据目标自主选择动作Harness 是“约束 Agent 的一套运行环境”让它只能在限定的工具、限定的步骤、限定的上下文里行动。一个类比是Agent 像是司机Harness 像是交通规则和道路围栏。研报场景里我们需要一个“收着跑”的 Agent而不是“放开跑”的 Agent。因为每一次工具调用都有成本每一次模型决策都有不可预测性。所以我们的 LangGraph 设计里同时兼容了两种状态开发调试阶段允许 Agent 比较自由地探索工具生产阶段则通过 Harness 把搜索工具、PDF 解析工具、数据库工具全线“白名单化”模型只能从预先定义好的动作集合里选不能自己发明动作。这个“先放开、后收拢”的策略我认为是所有做企业级 Agent 的人都应该借鉴的。4. 提示词与流程编排把研报分析框架注入 Agent4.1 核心方法论让 Agent“先搭框架再填内容”项目中最核心的提示词设计思路可以总结成一句话永远不要直接对模型说“写一份关于某某公司的研报”而是让它“严格按照给定的分析框架填充内容”。为什么我给你看一个真实对比。如果直接让模型写研报它默认的“研究报告”认知往往来自训练数据里的零散片段。结果就是报告写得泛泛而谈、千篇一律甚至把某家公司的财务指标错误地安放在另一家公司头上。而当我们把分析框架显式注入提示词后效果立刻不一样。我们的研报框架是这样定义的分五大维度商业模式与护城河公司靠什么赚钱、为什么能持续赚钱、竞争对手的壁垒在哪行业空间与竞争格局市场规模、增速、玩家份额、上下游议价能力财务状况与盈利质量收入结构、毛利率趋势、现金流覆盖、负债水平成长驱动因素产能扩张、新品周期、客户突破、政策催化风险提示业务风险、财务风险、治理风险、行业风险、估值风险每个维度下还嵌套了若干二级问题。比如“财务状况”里会问“近两年现金流是否覆盖资本开支”“应收账款周转天数是否在拉长”。这些二级问题就是我们让 Agent 去搜集数据的“任务单”。4.2 提示词模板给子 Agent 的写作指令到底长什么样下面给出一段我们实际在用的章节写作提示词模板结构上可以分成四个部分。这里里的关键不在“文采”而在“约束”。你是一名企业研究分析师。现在需要撰写研报的【财务分析】章节。 【目标公司】 {company_name} 【当前章节】 {section_name} 【可用的结构化数据】 {json_data} 【写作要求】 1. 所有财务数字必须从上方JSON中取用禁止编造任何指标。 2. 每个关键结论后面必须标注[source:N]其中N对应数据来源的编号。 3. 如果数据缺失请明确写“数据暂未获得”不要用模糊措辞掩盖缺失。 4. 语气保持中性客观不使用夸张形容词。 5. 输出长度控制在800字以内段落间使用空行分隔。 【历史报告风格参考】 {style_reference}这个模板有四个核心设计要点。第一所有数据以 JSON 形式提前放入上下文而不是让模型自己“回忆”数据。大白话说模型是一个“优秀的写手”但不是“数据库”你让它凭记忆写数据它必然给你编。第二强行要求“每个关键结论标注来源编号”这就逼着模型引用我们已经提供给它的结构化数据。一旦发现某段话没有引用来源校验层可以直接把它标红提示“疑似幻觉段落”。第三明确说明“数据缺失就写缺失”这是防止模型用“大约”“可能”这种含糊词弥补空缺导致整份报告看起来好像什么都说了、其实什么也没说。第四历史风格参考是从过往人工撰写的研报里抽的摘录用来校准语气和行文风格。这招对“报告像个机器人在写”的问题非常有效。4.3 Agent 记忆与技能两种增强手段的实际应用搜索热词里“agent记忆”和“agent skill”频繁出现我们的项目正好同时用到了这两样。记忆层我们分成短期和长期。短期记忆就是当前这份研报跑批过程中各个节点产生的中间数据存在 LangGraph 的状态对象里每个节点都能读取。长期记忆是“行业先验知识”比如动力电池行业的关键技术路线、补贴政策历史、龙头公司的历史财务特征。这些先验知识被固化在独立的 Embedding 知识库里写某个章节之前系统先用语义检索拉出相关片段注入上下文相当于给 Agent 配了一个“行业背景顾问”。技能层我们参考了 Agent Skill 的思路把“如何从招股书里抽取募集资金用途”“如何判断毛利率连续三年的变化趋势”这一类的专家方法固化成可复用的命令式技能。每个技能有一个名字、一段参数说明、一组执行步骤。Agent 在规划阶段会判断当前任务是否需要调用某个技能如果需要就调用技能对应的函数而不是临时用自然语言指挥模型“你自己想想怎么做”。这最大的好处是稳定同样的任务技能版执行的结果方差远小于自由发挥版。5. 实操过程与核心环节实现5.1 从需求到报告的完整跑批流程下面把我们真实跑批流程按步骤展开。你如果照着这个流程搭前期会省掉很多试错。第一步需求解析。用户通过一个简单的前端页面提交任务比如“分析全球最大的五家光伏逆变器公司重点对比出货量、毛利率、海外收入占比”。后端收到后先用一个解析模型提取出“目标公司列表”“分析维度”“报告语言”“时间范围”。这一步提取结果必须非常结构化连中文数字都要精确转成可计算的数值。第二步研究框架生成。框架规划 Agent 拿到需求元数据后生成一份 JSON 格式的大纲每个章节带四个字段章节 ID、标题、需要检索的关键词列表、需要填写的结构化数据字段列表。这一份大纲就是整条流水线的“施工图纸”。第三步并发数据采集。按照大纲并行触发采集任务。采集分两大类一类是从公开 API 直接拉数据另一类是从 PDF 年报里抽取。两类任务放在两个队列里控制并发数避免触发第三方接口限流。实测下来一份 5000 字的研报数据采集环节大约要跑 3 到 5 分钟其中年报解析时间占大头。第四步数据标准化与清洗。把采集到的数据统一转成我们定义的中间格式。比如“营业收入”字段不管来源是万得、新浪财经、年报 PDF 还是新闻稿最终都转成统一单位人民币元、亿元或美元、统一币种、统一时间口径。这一步非常琐碎但极其关键因为模型不会自动意识到“Q3”和“前三季度”的区别。第五步章节写作。按大纲逐个章节生成。我们在 LangGraph 里设置每个章节流水线的最大并发数为 4写完后所有章节暂存在状态对象里不直接拼接。第六步校验与聚合。先把所有章节拼接成完整报告再跑三层校验第一层是“数字一致性校验”把报告中出现的所有数字提取出来和数据库中的源数据做逐一比对第二层是“引用完整性校验”检查每个[source:N]标记是否有对应的来源记录第三层是“章节完整性校验”检查每个章节是否达到最低字数要求。5.2 并发处理和限流Agent 怎么扛住真实压力搜索热词里有“ai agent 怎么扛并发”这其实是所有 Agent 从原型走向生产的必经之路。研报场景还不算极端并发但已经足够说明问题。我们的流水线在一份报告内部有多个并行任务比如五个公司、每个公司五个章节理论最大并行度是 25。但如果完全放开并行会同时打爆三样东西语言模型 API 的限流阈值、搜索 API 的配额、公司内部数据库的连接池。缓解方案用了三层请求级缓存。对搜索 query 和 PDF 解析结果做哈希缓存同样的关键词在 24 小时内只真正请求一次。实测缓存命中率能达到 35% 到 45%相关性高的行业词命中率尤其高。滑动窗口限流。给每个 API 单独维护一个令牌桶限制每秒最大请求数。搜素 API 限到每秒 5 次语言模型 API 限到每秒 8 次PDF 解析服务限到每秒 2 次。自适应重试。遇到 429 限流错误采用指数退避策略从 1 秒开始每轮乘 2最多重试 5 次。如果重试后依然失败任务进入“待人工处理队列”而不是继续折磨服务器。这里有一个容易被忽略的细节并行度不是越高越好。我们在生产环境实测当并发数从 4 调到 8单份报告的总耗时反而增加了约 20%原因是模型 API 在高并发下出现大量排队和重试净吞吐量反而下降。所以“并发阈值”需要在你的真实环境里跑一遍压测再定。5.3 成本控制一份研报到底烧多少 token做企业级 Agent成本是躲不开的话题。我直接给数字我们线上生产版本跑一份 5000 字企业研报平均消耗环节输入 token 量输出 token 量需求解析与框架规划约 4000约 1500数据采集工具调用上下文约 22000约 4000章节写作5 章约 18000约 12000校验与修复约 6000约 2000合计约 50000约 19500单份报告总 token 大约 7 万折合成本因模型而异。这里有两个省钱的技巧特别值得说。第一不要把所有采集到的原文全文都塞给写作模型。我们的做法是只把“结构化抽取后的结果”注入上下文而不是把整篇年报 PDF 塞进去。同样一个数据注入“营收 42 亿元同比增长 18%”比注入原始财报段落省 50 倍 token。第二把校验环节做成“先规则判断再模型兜底”。数字一致性校验先用程序做精确匹配只有程序匹配失败的情况才调模型做模糊判断。这一步把校验环节的 token 消耗降低了 70%。6. 常见问题与排查技巧实录6.1 幻觉问题模型“睁眼说瞎话”怎么根治这是所有研报 Agent 项目遇到最多、也最让人头疼的问题。最典型的场景是公司 2024 年财报明明写了“营收 28.6 亿元”模型在写作时写成了“营收 30 亿元”并且语气无比肯定如果不细看根本发现不了。我们用了三层方案来压制这个问题。第一层是“数据前置”。在写作提示词里把结构化数据以 JSON 形式明确摆出并注明“所有财务数字必须取自该 JSON禁止从模型记忆中提取”。这个约束把因为“模型记忆混淆”导致的数据错误基本消灭了。第二层是“来源强制标注”。每段内容必须标注[source:N]检查器直接扫描输出文本凡是没有标注的段落直接进入“疑似幻觉”列表。第三层是“数值级验证器”。程序提取报告中的所有数字和源数据做交叉比对。数字形态不匹配的直接报错匹配但来源不同的标记“需要分析师复核”。这一层拦截掉最后漏网之鱼。三层叠加下来我们内部抽测了 40 份报告未标注来源的可疑段落从早期版本的 12.5% 降到了 2% 以下。6.2 上下文丢失长报告写到后半段就开始“塌方”第二个高频问题是当报告篇幅超过 3000 字后半段的写作质量会肉眼可见地下降甚至出现重复前面内容、章节前后矛盾的情况。原因并不神秘——模型的长上下文注意力有“中部迷失”的倾向写过长的内容会出现开头结尾更受关注、中间被忽略的现象。我们的解法是“碎片化写作、结构化拼装”而不是“一次性长上下文”。每个章节由独立的子 Agent 编写子 Agent 的上下文被严格限制在“本章节相关的数据 本章节的写作指令”不允许它看到其他章节的内容也不允许它依赖已被生成的前文。这样一来每个章节的写作任务都控制在一个合理范围内质量方差大大减小。章节之间的一致性靠另一条机制保证所有章节都从同一个“公司事实清单”读取数据。“事实清单”是一份几百行的结构化信息由数据采集阶段统一生成。写作阶段无论哪个章节写“营业收入”这个指标取到的都是同一个值。所以根本不存在“前一章写 28.6 亿、后一章写 29 亿”这种矛盾。6.3 搜索质量拉胯检索引擎返回的内容根本没法用Agent 项目里有一个特别容易踩的坑把联网搜索做成“一次搜索 把前几条结果塞给模型”。这在研报场景里完全不够用。一份严肃的研报要求每个关键论点有多源交叉验证。如果只搜索一次模型只能“看到一个说法就写进去”。而网络上的信息鱼龙混杂同一个财务指标在财经媒体、公司官宣、第三方研报里经常出现不同数字。我们把搜索环节升级为“迭代式搜索”先根据研究框架初步搜索然后对搜索结果进行“信息地图”分析找出哪些论点已经有足够证据、哪些论点还缺证据。针对缺证据的论点再生成第二轮、第三轮更精准的搜索词。比如第一轮搜“宁德时代 海外收入”发现公开报道的时间口径不一致就会生成第二轮搜索词“宁德时代 2025 半年报 海外收入 分地区”。这种迭代搜索在框架规划好的情况下能显著提升报告的信息密度。6.4 结构化输出不稳定明明要求 JSON结果还给你一段散文我们用过不少提示词最难受的问题之一是模型的输出不够“结构化”。你让它输出 JSON它偶尔会在开头加一段“好的我来回答”或者结尾加一句“希望以上信息对你有帮助”直接把整段 JSON 解析搞挂。这个问题的根治方案是双管齐下在语言模型 API 调用层启用“结构化输出模式”或函数调用模式直接从 API 层面约束输出格式。在代码层增加一个“提取与修复器”先尝试直接解析完整 JSON失败则用正则从文本中抠出 JSON 片段再失败就向模型发送一条“修复消息”把残缺的 JSON 发回去要求仅返回修正后的完整 JSON不附加任何其他文字。在同时启用这两个方案之后我们线上流程的结构化输出成功率从 86% 提升到了 99.7%几乎再也没有因为解析异常中断流水线。6.5 被低估的坑PDF 解析里的“表头错位”问题最后说一个非常冷门但致命的坑年报 PDF 里的数据表格在解析之后经常出现列错位现象。比如表格有“营业收入、营业成本、净利润”三列解析器有可能把数值整体右移一列导致“营业收入”对应的数值其实是“净利润”的10倍数量级。这种错位不能靠模型识别因为模型拿到数据后根本不知道源表格长什么样。我们的应对策略是建立“财务指标合法性检查器”预先给每个指标绑定一个合理值域。资产负债率不可能超过 500%净利润率一般不可能超过 200%。当抽取出来的指标违反合理性约束时系统自动回到原 PDF 重新定位表格进行二次抽取。如果二次抽取仍然异常就把该表格标记为“人工核查”。这个检查器看起来毫不起眼但它是我们项目中避免最荒谬错误的最后一道防线。7. 一些后续优化方向与个人体会7.1 评测体系怎么判断一套 Agent 到底是好是坏最后聊一个经常被忽略但非常重要的话题Agent 项目的评测。业务方问你“这套系统到底行不行”你不能只拿两份报告说“看起来挺专业”。你需要一套可量化、可复现的评测方法。我们设计了一套五维评分体系事实准确率抽样核对报告中的关键数字与源数据一致的比例证据覆盖率报告中的关键结论里有明确来源支撑的比例结构完整度五大分析维度是否全部覆盖、章节是否齐全逻辑一致性章节之间是否存在矛盾、数据是否前后统一可读性行文是否顺畅、表达是否客观、有无明显机器味每跑完一批实验我们会抽出 20 份报告由两位分析师独立打分再取平均分。这个评测体系最大的价值是让我们能比较“换一个框架”“改一段提示词”到底是变好还是变坏而不是靠感觉拍脑袋。7.2 学习路线参考如果你正在规划 Agent 开发的学习路线我根据自己的实践经验给你一个参考顺序先吃透提示词工程重点是结构化输出和上下文管理再掌握函数调用这是 Agent 与工具交互的基石然后学习主流框架里的工作流编排理解图状态、节点、缓存这些核心抽象在此基础上再研究多 Agent 协作、记忆、技能这些进阶主题。最后一定要做一两个真实场景的端到端项目因为只有在真实项目里你才会碰到限流、解析失败、上下文冲突、输出不稳定这些“生产环境才有的问题”。我个人最深的一个体会是做 Agent 开发最大的难点不是把 Agent 跑起来而是让它“稳定地跑完”。跑起来只需要几天稳定跑完需要几个月。企业级场景里“稳定可控”的价值远大于“聪明惊艳”。所以做完这个项目之后我对 Agent 产品的要求变得非常朴素每一次跑批都稳定成功每一句输出都有据可查。做到这两点就已经超越了市面上大多数演示级 Agent。最后分享一个小技巧如果你也要做类似的 Agent 项目建议从“一个切片”开始比如先只做“财务分析”这一个章节的流水线跑通之后再往其他章节扩展。一次做一个章节能让你的调试成本降低一个数量级也能在早期就把数据质量、输出稳定性这些基础问题解决掉。