在一个由 9 个 AI Agent 组成的研究团队里行业分析师是最容易被误会的角色。它看起来只需要读资料、写行业综述实际搭建之后才会发现这个角色的价值不在于描述一个行业有多大而在于回答一个更克制的问题这个行业的宏大叙事是否真的能作为我们进入这个行业的理由。这个判断如果做不好后面的公司分析、财务建模、风险复核都会建立在一个虚浮的地基上。这个“AI 九人研究团队”系列目标是搭出一套能完成研究闭环的多智能体系统。前面几篇完成了总体架构、任务路由和第一批角色定义这一篇把“行业分析师”单独抽出来做细。行业分析师处在宏观研究之后、公司分析之前负责把宏观趋势翻译成产业机会再把产业机会拆解成可验证、可反驳、可追踪的研究结论。本文将围绕这个角色完成四件事定义职责边界、设计系统提示词与任务流程、用最小可运行代码跑通一个行业分析师 Agent、以及实现最关键的一项机制——让 Agent 学会隔离“行业宏大叙事”与“入场理由”。1. 先给行业分析师 Agent 定好边界它的核心问题不是“行业好不好”1.1 行业分析师在 9 人团队中的位置9 人研究团队的划分方式可以根据项目不同做调整但有一个相对稳定的角色骨架项目管理 Agent 负责任务分发宏观分析师处理经济环境行业分析师判断产业机会公司分析师筛选具体标的财务分析师搭建财务模型风险分析师识别下行风险反方 Agent 负责挑战结论数据工程师负责数据获取资深分析师负责最终合并与质量控制。行业分析师处于整条链路的中间位置。它接收上游宏观分析输出的经济环境、利率预期、技术周期变化也要接收下游公司分析对特定公司的疑问然后返回一套行业层面的判断。它并不是一个独立写报告的岗位而是一个信号转换器把宏观信号转换成行业机会把行业机会转换成后续角色可以继续验证的问题。它的职责边界要足够窄。行业分析师不负责给出具体的买入或投资决策也不负责公司估值。它只负责回答三个问题这个行业当前处于什么阶段行业需求是否真实以及在什么条件下值得进入。超出这三个范围的内容应该由团队里的其他角色接走。1.2 “宏大叙事”是输入信号不是输出结论行业研究里最常出现的表述是这样的行业空间接近万亿复合增长率超过 20%是未来十年的确定性方向政策持续加码技术拐点已经到来。这类表述并不是没有价值它告诉我们这个行业值得花时间研究。但如果研究中只有这类表述那它只能算宏大的叙事不能作为入场的理由。问题出在逻辑跳跃。市场规模大不代表产业里每个参与者都能赚钱增速高不代表当下时点能切入政策鼓励不代表商业模式已经成立趋势不可逆不代表你的资源配置能等到趋势兑现。行业分析师容易被这类叙事吸引还因为大模型本身就有生成叙事的倾向。训练语料里有大量增长故事模型接触到的“行业分析”文本多数在讲前景、讲趋势、讲想象空间缺少对数据的交叉验证和反面讨论。如果系统提示词不加以约束Agent 输出的第一版大概率是一篇漂亮的行业前景展望。所以启动研究流程之前就要明确宏大叙事是研究输入不是研究结论。Agent 必须在输出的每个关键判断旁边标注证据类型把“数据”“推断”“叙事”“观点”分开放不能拿叙事冒充事实。更具体地说行业分析师输出的最终结论必须是一张包含结论分级和入场条件的决策前置表。1.3 这个角色要输出的是一张决策前置表下面这个表格定义了行业分析师的输入输出边界适合直接写进提示词或任务说明中本角色负责本角色不负责判断行业当前所处阶段给出具体交易或买入决策判断行业需求是否真实、可验证用市场规模数字替代逻辑论证拆解宏大叙事并标记证据等级汇总行业全部新闻与事件输出结论分级和入场触发条件代替公司分析师筛选个股为下游角色提供证据清单代替财务分析师搭建财务模型这个边界要先定下来否则 Agent 很容易越界。实际开发中常见的情况是行业分析师输出里混入了大量公司层面的判断比如“某公司具备较强的产品力”这种内容应当交给公司分析师而不是由行业分析师输出。边界一旦模糊后续多智能体协作就会出现职责重叠和结论冲突。2. 搭建前先做角色拆解人设、研究流程、输出规范、验收标准2.1 角色人设的系统提示词搭建行业分析师 Agent第一件事不是写代码而是定义系统提示词。系统提示词是在每次调用大模型时固定发送的角色指令。它会决定 Agent 的立场、工作原则和输出风格。设计原则是提示词要短规则要硬边界要明确。不要写几百字的人物背景故事那样只会增加模型的随机性。真正重要的是几条硬性约束。下面是一个可以直接使用的最小系统提示词示例INDUSTRY_ANALYST_PROMPT 你是研究团队中的「行业分析师」。 你的职责不是给行业写综述而是回答一个问题 这个行业当前是否值得进入以及在什么条件下值得进入。 工作原则 1. 区分事实、推断和叙事。 - 事实有来源、有时间的数字和事件。 - 推断基于事实推出的趋势。 - 叙事口号、类比、行业故事。 2. 推断必须给出逻辑链叙事必须单独列出不能用来证明结论。 3. 对每一个看多逻辑至少生成三个反向问题。 4. 如果证据不足直接输出“证据不足”不要用篇幅掩盖。 5. 最终结论必须落到 A/B/C/D 四级禁止使用“前景广阔”这类模糊表达。 输出格式 严格按照 JSON 输出包含字段industry、conclusion_level、 conclusion、entry_conditions、key_facts、narratives、 opposing_questions、confidence。 这段提示词的关键点有三个。第一用“你是什么角色你要回答什么问题”开头让模型明确任务。第二用“工作原则”给出硬性约束其中把证据分级写进规则。第三指定输出字段强迫模型以结构化方式返回结果而不是自由写作。2.2 研究任务结构系统提示词解决的是“这个角色怎么思考”任务结构解决的是“每次研究具体做什么”。在进行任何大模型调用之前先定义研究任务的输入格式。推荐使用 JSON 结构{ industry: 智能家居行业示范样例, research_scope: 家庭安防与能源管理两个细分方向, research_window: 未来 12 个月, research_question: 当前是否具备进入该行业的窗口, input_materials: [ 材料1某机构发布的智能家居行业白皮书摘要, 材料2最近三个季度的智能家居设备出货量统计 ], priority: high }字段含义如下字段作用说明industry研究对象明确到行业必要时带上细分领域research_scope研究边界防止 Agent 把范围扩大到无关方向research_window研究时间窗口行业结论必须带时间属性research_question本次要回答的问题不同项目可以有不同的核心问题input_materials输入材料清单如果为空必须提示证据不足priority任务优先级供调度 Agent 使用任务结构要先定是因为大模型在自由状态下会倾向于扩大范围。一旦研究范围不明确行业分析师可能会把智能家居安防研究写成整个物联网行业的宏观报告导致后续无法使用。2.3 六步研究流程行业分析师 Agent 不能只靠一次大模型调用完成全部工作建议拆成六个步骤。每一步都有明确产物这样方便检查质量问题也方便定位出错环节。第一步问题生成。根据任务结构中的 research_question将核心问题拆成子问题比如需求真实性、竞争结构、进入壁垒、政策影响、技术成熟度、替代风险。第二步材料收集。根据子问题将输入材料按主题归入对应问题或者调用检索工具搜索外部信息。这一步的产物是一个“材料与问题对应表”。第三步证据标注。将材料中的关键语句提取出来逐条标记证据类型、来源、时间、置信度。这一步是防止宏大叙事夹带的关键。第四步交叉验证。检查是否存在互相矛盾的数据检查数据口径是否一致检查结论是否有多个独立来源支持。第五步反向复核。对每一个看多逻辑提出至少一个反向问题必要时单独调用一次“反方审查”提示词。这一步是为了避免模型被单方向叙事拉扯。第六步结论分级。根据以上信息输出 A/B/C/D 结论分级和入场条件清单。流程设计的核心思路是每一步都把模型的一次自由生成拆解成一个有边界的子任务。拆得越细越容易控制质量。2.4 输出规范与验收清单流程执行完毕后Agent 需要输出结构化的 JSON 结果。必须包含以下字段输出字段含义质量要求industry行业名称与任务输入一致conclusion_level结论分级只能是 A/B/C/Dconclusion核心结论一句话说清不能含糊entry_conditions入场条件清单每条必须可验证key_facts关键事实必须含来源、时间、证据类型narratives识别出的宏大叙事单独列出不与事实混用opposing_questions反向问题每个看多逻辑至少一个confidence总体置信度high/medium/low/unverified验收清单可以设计成下面这样每次任务结束后逐项检查结论分级是否为 A/B/C/D 之一且与正文一致。关键事实是否包含来源和时间是否标注了证据类型。是否输出了至少 3 个反向问题。是否将宏大叙事单独提取到 narratives 字段。是否存在缺少证据但仍给出强结论的关键判断。输出是否可以直接被下一个角色解析而不是需要人工重新整理。提示在验收清单里增加一项“是否存在不可验证的绝对化表达”例如“必然”“一定”“毫无风险”。这类表达出现时应将对应结论降级。3. 用最小可运行案例跑通一个行业分析师 Agent3.1 环境准备与依赖为了快速验证角色设计可以用 Python 脚本搭建一个最小可运行案例。需要准备 Python 3.10 或更高版本安装两个依赖即可pip install openai python-dotenv这里以 OpenAI 兼容的 Chat Completions 接口为例因为大量大模型服务都支持该协议。在项目目录下创建.env文件写入访问配置LLM_API_KEY你的密钥 LLM_BASE_URLhttps://你的服务地址 LLM_MODEL你的模型名称如果是学习环境可以直接使用支持 OpenAI 协议的服务如果是生产环境建议统一通过网关或者代理服务接入避免把密钥散落在业务代码里。加载配置import os from dotenv import load_dotenv load_dotenv() MODEL_NAME os.getenv(LLM_MODEL, your-model) client OpenAI( api_keyos.getenv(LLM_API_KEY, your-key), base_urlos.getenv(LLM_BASE_URL, https://api.example.com), )实际项目中请根据自己使用的模型和服务地址替换这些配置。不要照抄这里的示例地址。3.2 定义数据模型先把研究过程中需要用到的基础结构定义出来。使用标准库的 dataclass 就可以不需要为了演示引入太重型的依赖。from dataclasses import dataclass, field dataclass class Evidence: statement: str evidence_type: str # data / inference / narrative / opinion source: str time: str confidence: str # high / medium / low / unverified dataclass class OpposingQuestion: logic: str # 被反问的原始逻辑 question: str # 反向问题 severity: str # mild / moderate / severe dataclass class IndustryConclusion: industry: str conclusion_level: str # A / B / C / D conclusion: str entry_conditions: list[str] key_facts: list[Evidence] narratives: list[str] opposing_questions: list[OpposingQuestion] confidence: str这些数据结构的价值在于强制 Agent 的输出是可验证的。如果conclusion_level被设置成 A那么entry_conditions里就必须有可验证的条件如果key_facts为空那么confidence就不允许是 high。这类约束可以在后续处理代码中继续校验。3.3 实现行业分析师 Agent 类接着实现核心的 Agent 类。这里给出一个骨架实现重点展示流程调用而不是堆砌复杂代码。import json from openai import OpenAI class IndustryAnalystAgent: def __init__(self, llm_client: OpenAI, model: str): self.llm llm_client self.model model def _ask_llm(self, system_prompt: str, user_prompt: str) - str: response self.llm.chat.completions.create( modelself.model, messages[ {role: system, content: system_prompt}, {role: user, content: user_prompt}, ], temperature0.2, ) return response.choices[0].message.content def _build_sub_questions(self, task: dict) - list[str]: prompt ( 根据以下行业研究任务输出 6 个需要研究的子问题。\n f任务{json.dumps(task, ensure_asciiFalse)}\n 输出 JSON 数组例如[\需求真实性\, \竞争结构\] ) content self._ask_llm(INDUSTRY_ANALYST_PROMPT, prompt) return json.loads(content) def _collect_evidence(self, task: dict, sub_questions: list[str]) - str: # 真实项目中这里会接入检索、爬虫或知识库。 # 最小演示直接基于 task 中的 input_materials 处理。 return json.dumps(task.get(input_materials, []), ensure_asciiFalse) def _draft_analysis(self, task: dict, materials: str) - dict: prompt f 请基于以下材料完成行业分析。 研究任务 {json.dumps(task, ensure_asciiFalse)} 已有材料 {materials} 要求 - 关键结论必须标注证据类型。 - 识别并单独列出宏大叙事。 - 对每个看多逻辑提出反向问题。 - 输出符合 INDUSTRY_ANALYST_PROMPT 中定义的 JSON 结构。 content self._ask_llm(INDUSTRY_ANALYST_PROMPT, prompt) return self._parse_json(content) def _parse_json(self, content: str) - dict: # 如果接口支持 response_format优先使用 JSON mode。 # 这里保留一个简单的容错处理。 try: return json.loads(content) except json.JSONDecodeError: start content.find({) end content.rfind(}) 1 return json.loads(content[start:end]) def research(self, task: dict) - dict: sub_questions self._build_sub_questions(task) materials self._collect_evidence(task, sub_questions) result self._draft_analysis(task, materials) result[sub_questions] sub_questions return result关键点有三个。第一temperature设置为 0.2降低随机性保证行业研究这类事实型任务输出稳定。第二_ask_llm是统一调用入口之后想接入日志、监控、重试机制都在这一个位置扩展。第三research方法按照“拆问题、找材料、写分析”的顺序执行这与人工研究员的路径一致。3.4 运行一个演示任务编写入口函数跑一个演示任务。下面用“智能家居行业”作为示例所有数字都是示意数据仅为展示输出结构。def main(): task { industry: 智能家居行业演示样例, research_scope: 家庭安防与能源管理, research_window: 未来 12 个月, research_question: 当前是否具备进入该行业的窗口, input_materials: [ 材料1某白皮书显示行业出货量连续两年增长示意数据, 材料2市场仍有多种通信协议并存互操作问题未解决 ], priority: high, } agent IndustryAnalystAgent(llm_clientclient, modelMODEL_NAME) result agent.research(task) print(json.dumps(result, ensure_asciiFalse, indent2)) if __name__ __main__: main()运行成功后输出会是一个 JSON 结构形式上类似下面这样{ industry: 智能家居行业演示样例, conclusion_level: B, conclusion: 行业需求在增长但当前缺少可验证的触发信号建议等待关键指标改善后再进入, entry_conditions: [ 头部设备连接标准出现收敛趋势, 用户复购率出现可量化的提升, 安装服务成本下降到可接受范围 ], key_facts: [ { statement: 智能家居设备出货量连续两年增长示意数据, evidence_type: data, source: 材料1, time: 最近两年, confidence: medium }, { statement: 通信协议并存互操作问题未解决, evidence_type: fact, source: 材料2, time: 研究窗口内, confidence: high } ], narratives: [ 万物互联是必然趋势 ], opposing_questions: [ 如果主要增长来自低端设备用户渗透率提升是否还能代表需求真实改善, 协议并存问题是否会让早期用户产生更换顾虑进而限制规模的进一步扩展, 如果安装服务成本短期无法下降这个行业是否只能停留在小众人群 ], confidence: medium }注意这只是演示结构不是真实行业结论。真正运行时要替换成自己的材料和真实数据。输出中把“万物互联是必然趋势”放进了 narratives 字段而不是作为支持结论的事实这正是设计要达成的效果。4. 关键机制让 Agent 不被宏大叙事绑架4.1 把事实、推断、叙事和观点分开前面已经提到证据类型这里展开讲清楚。行业研究报告的质量差异很大程度上取决于是否区分这四种信息证据类型含义示例能否直接支持结论data有来源、有时间、有数字的事实某地区出货量环比增长 5%可以inference基于事实的推断出货量增长说明需求在改善可以但需要逻辑链narrative行业故事、类比、口号万物互联是必然趋势不可以opinion专家或报告作者的观点某机构认为行业将加速洗牌参考需标注立场在系统提示词里要明确要求所有支持结论的内容至少要是“data”或者带完整逻辑链的“inference”。如果一段分析全部由 narrative 组成应该直接判定为证据不足。实际测试中大模型经常会把“某行业报告显示市场规模超过万亿”当作事实使用但如果没有来源、时间、统计口径这句话其实已经退化成叙事。要解决问题不能在提示词里写一句“请提供准确数据”就算了而是要在结构化输出中让模型填写source和time无法填写时就只能降低置信度。4.2 强制反向研究防止宏大叙事绑架结论的最有效手段是强制生成反向问题。一个看多逻辑如果没有经历反向质疑它就不是研究结论只是观点。可以在每次分析完成后额外调用一次反向审查。单独设计一个提示词效果比在主提示词里加一句“请考虑风险”好得多。原因在于一次对话中模型已经输出了看多逻辑再次要求它自我否定时它往往会温和地修正而不是真正推翻。REVERSE_REVIEW_PROMPT 你是行业分析的反方审查者。 下面是行业分析师给出的一系列看多逻辑 {analysis} 请逐条提出反向问题。要求 1. 每条逻辑至少一个反向问题。 2. 问题必须具体不能是“存在风险”这种空话。 3. 可以从假设被证伪、数据口径改变、竞争加剧、 技术路线变化、下游需求不及预期等角度出发。 4. 输出 JSON 数组每个元素包含 logic、question、severity。 然后将返回的反向问题合并进最终的 JSON 输出。如果某个看多逻辑对应的反向问题数量不足质量检查环节应当直接扣分。4.3 结论分级和入场条件检查清单结论分级是这个角色的核心出口。分级设计越简单越容易执行。建议使用四级制等级含义使用场景A当前具备入场条件核心条件已验证且有多来源支撑B等待触发信号方向成立但关键条件还不满足C暂不关注叙事明显强于事实或者行业进入下行期D证据不足无法判断需补充材料后再评估等级为 B 时必须在entry_conditions里写明具体触发信号例如“头部厂商统一连接标准”“某个关键原材料价格下降到 X”。这样下游 Agent 可以持续跟踪。等级为 D 时建议返回明确的“缺失证据清单”而不是勉强选一个方向。提示“证据不足”不是失败结论而是行业分析师最常用且最安全的合法结论。要允许 Agent 说不知道。4.4 数据来源、时间窗口和置信度行业研究经常犯一个错误把过去的数据当作未来趋势的证据。因此每个关键事实都要带上时间。置信度可以分四级high、medium、low、unverified。如果输入材料里没有相关内容模型必须输出“未在输入材料中找到”而不是自行脑补。这一点需要在提示词中写成硬性规则。比如“当材料中没有某个事实时在对应字段填写未找到并将置信度设为 unverified不得用常见知识补全。”实际项目里这条规则能显著减少行业分析师的幻觉输出。因为行业研究涉及大量市场规模、增速、渗透率等数字如果没有强制“未找到”机制模型非常容易生成看起来合理但实际不存在的统计数字。5. 运行验证怎么判断行业分析师 Agent 的输出合格5.1 用三个行业案例做行为测试Agent 搭建完成后不要只用一个案例验证。建议准备三个差异明显的行业案例观察输出是否具备区分度。第一个案例高叙事但缺验证的行业。例如某个正处于概念期的新兴行业材料里只有市场规模预测和趋势描述没有客户验证、订单数据和成本结构。合格输出应该是 D 或 B并且narratives字段要能识别出那些未经证实的趋势口号。第二个案例周期性行业出现可验证信号。例如航运周期或工程机械周期材料里有明确的运价指数、库存天数、新签订单数据。合格输出应该能判断当前处于周期什么位置给出 B 或 A并指出哪些数据是判断依据。第三个案例成熟行业巨头主导。例如某个已经高度集中的消费行业材料显示头部份额持续提升新进入者缺少差异化空间。合格输出应该是 C除非模型能在细分市场里找到明确的空白点。这三个案例分别对应“叙事多于事实”“事实可验证”“事实已经表明格局稳定”三种情况。如果一个 Agent 对三类案例都输出“前景广阔、值得关注”说明它的结论分级机制没有生效。5.2 输出质量评分卡为了自动评估 Agent 输出可以设计一张评分卡。每个维度 1 到 5 分总分达到 90 分以上才允许进入下游环节。维度满分标准扣分点结论分级正确性A/B/C/D 与事实匹配明显证据不足却给 A证据标注完整度每条事实均有来源、时间、类型存在无来源关键数字叙事隔离程度narratives 字段完整、准确将趋势口号当作事实使用反向研究数量与质量每个看多逻辑至少一个问题反向问题是“注意风险”式空话结构化可解析性能被下游角色直接消费JSON 字段缺失或无法解析语言克制度结论使用条件句、限制词频繁使用“必然”“一定”这个评分卡既是验收工具也是调试工具。如果某一批任务质量偏低可以先看扣分集中在哪个维度。比如永远在“叙事隔离程度”扣分就说明提示词里对 narratives 的约束不够。5.3 日志与中间过程追踪多智能体系统最难排查的问题之一是不知道哪一步产生了错误输出。行业分析师 Agent 内部建议做三件日志工作记录每次大模型调用的耗时与 token 消耗保存每个子问题的材料集合给最终结论附上可追踪的中间结果。以下是一段简易的日志实现思路import logging logging.basicConfig(levellogging.INFO) class IndustryAnalystAgent: def research(self, task: dict) - dict: logging.info(开始行业分析任务: %s, task[industry]) sub_questions self._build_sub_questions(task) logging.info(子问题: %s, sub_questions) materials self._collect_evidence(task, sub_questions) logging.info(材料数量: %d, len(materials)) result self._draft_analysis(task, materials) logging.info(结论分级: %s, result.get(conclusion_level)) return result日志的作用不只是排查错误还可以用来评估提示词修改是否有效。每次修改 prompt 后跑同一批测试任务并对比输出质量不要凭印象判断。6. 行业分析师如何融入多智能体协作链路6.1 它在工作流中的前后端接口在 9 人研究团队中行业分析师不是独立完成研究的孤岛。一条典型的工作流是项目管理 Agent 解析研究需求把任务分发给宏观分析师宏观分析师输出经济与政策环境后把任务转给行业分析师行业分析师输出行业结论后公司分析师开始筛选值得深入研究的公司之后财务分析师、风险分析师、反方 Agent 依次介入最终由资深分析师角色合并结论。行业分析师与上下游之间的交互建议全部使用 JSON 格式而不是自然语言长段落。这样可以避免下游 Agent 解析文本时丢失信息。比如行业分析师输出给公司分析师的应该是一个包含“行业关键变量、值得关注的公司名单、行业风险清单”的 JSON 对象。6.2 给下游角色的“可消费”输出不同下游角色关心不同类型的信息。行业分析师在输出时要考虑这些角色下游角色需要的行业信息建议输出字段公司分析师值得研究的公司范围、行业关键变量candidate_directions财务分析师产业链结构、成本传导、毛利影响因素industry_cost_drivers风险分析师不可证伪的假设、单一来源数据unverifiable_assumptions反方 Agent可反驳的看多逻辑opposing_questions项目管理 Agent任务状态、后续需要补充的材料missing_evidence不要把所有内容都塞进conclusion字段。字段越细下游越容易处理。实际开发中长文本结论会导致后续每个角色都要先做一次语义解析不仅耗时还容易产生歧义。6.3 重跑、版本与缓存行业结论具有时效性。三个月前成立的结论三个月后可能已经失效。生产环境中行业内 Agent 的任务需要支持三个能力定期重跑、输入快照、版本对比。定期重跑是指按照固定频率或者在关键事件发生时重新执行研究流程。输入快照是指在每次研究启动时保存输入材料列表和配置。版本对比是指在重跑完成后把新旧结论的差异输出出来。比如{ changed_fields: [conclusion_level], old_level: B, new_level: A, change_reason: 关键原材料价格在最新一期数据中下降到触发区间 }这种对比能力对用户判断非常有用也是行业分析师从“一次性报告生成器”升级为“持续跟踪研究系统”的关键一步。7. 常见问题与排查路径7.1 常见现象、原因和处理方式行业分析师 Agent 在开发过程中会出现几类高频问题。下面用表格列出常见现象与排查建议问题现象常见原因检查方式处理建议输出像营销软文提示词中缺少证据约束检查 key_facts 是否有来源和时间加入 evidence_type 硬性标注结论永远偏向 A/B没有设置最低证据标准查看结论分级分布加入“无法验证则 D”规则输出大量编造数据模型不认识输入材料的边界抽查某个数字能否在材料中找到强制“未找到”机制反向问题全是空话反向提示词不够具体检查 questioning 字段质量要求给出数字或场景JSON 解析频繁失败未使用 JSON modetemperature 过高查看响应原文打开 response_format调低温度与下游角色无法衔接输出字段设计不合用观察下游 agent 抛错日志重新设计输出 schema7.2 典型排查输出全是宏大叙事这是最常见的失败模式。现象是Agent 输出很长看起来结构完整但key_facts大多是“行业空间巨大”“增长迅速”这类描述缺少来源和时间。排查顺序如下第一步检查提示词。确认系统提示词中是否明确要求输出source和time。如果没有先补上同时要求没有来源的事实不得出现在 key_facts 中。第二步检查输入材料。如果输入材料本身就只有行业白皮书的摘要没有具体数据那么结论分级不应该是 A更不应该是“值得重点关注”而应该是 D并返回“缺失证据清单”。第三步检查解析结果。将模型原始响应与最终解析输出做对比确认是不是解析阶段把 narratives 字段丢掉了。实践中常见的情况是模型原本已经区分了叙事和事实但程序解析时只保留了结论字段。第四步如果以上都没问题再考虑升级约束。在提示词中增加一条当关键事实没有来源时在对应字段填写“未找到”并将置信度设置为 unverified。这通常会立刻减少编造情况。7.3 约束不要靠堆提示词要靠结构新手常犯的错误是看到模型输出宏大叙事就不断往提示词里加约束词。加了“注意不要用模糊词汇”又加“必须使用来源”再加“不要编造数据”。提示词越来越长问题却没有彻底解决。原因是模型对一条 800 字的提示词和一条 1500 字的提示词遵循程度并不会成比例提升。提示词过长反而会让模型将重点放在最后几条指令上忽略中间规则。更有效的方式是引入结构性约束。把输出从“自然语言报告”改成“JSON 字段表”模型被迫在字段层面填写来源、时间、证据类型不能通过模糊措辞逃避。把“结论分级”从可选项变成必选项模型必须选择一个具体等级。把“反向问题”从软性要求变成独立流程单独调用一次反方审查。结构比措辞更稳定。在实际项目中遇到质量问题时优先增加流程步骤和输出字段而不是继续堆砌提示词。8. 生产环境落地建议和扩展方向8.1 学习环境与生产环境的差别本地脚本能跑通距离生产环境可用还有相当距离。两者的差别主要集中在以下方面维度学习环境生产环境材料输入手工粘贴知识库、数据库、资讯源自动接入检索能力无网络检索、RAG、实体链接模型输出直接调用通过网关统一管理密钥、限额、审计质量保障人工目测评分卡自动拦截、人工抽检结论版本无记录输入快照、输出版本、变更对比任务调度手动运行定时触发、事件触发、队列调度失败恢复无重试、降级、告警、人工复核把上面表格逐行落实才算真正从演示脚本走向可用系统。尤其是“人工复核”这条不能省行业研究结论可能影响后续一系列动作生产环境至少要保留“高级分析师角色”对 A 级结论进行复核的环节。8.2 扩展方向行业分析师 Agent 可以往几个方向扩展。第一个方向是接入真实数据源。把新闻资讯、行业数据库、上市公司公告通过接口接入让 Agent 不再依赖用户手工粘贴材料。这需要增加数据清洗和去重流程因为行业信源大量重复。第二个方向是增加检索工具。通过函数调用或者自定义工具让 Agent 在“材料收集”阶段自动搜索外部信息。搜索结果的来源、标题、时间必须一起进入系统而不是只把正文丢给模型。第三个方向是建设行业知识图谱。将上下游关系、供应商、替代品、价格传导路径结构化存储。行业分析师在有知识图谱支撑后可以完成更复杂的推演例如“某种原料涨价会向行业哪个环节传导”。第四个方向是引入多语言信源。真实行业研究往往需要阅读海外报告跨语言信源的引入可以让 Agent 发现国内材料不常提到的信号减少信息盲区。8.3 给后续角色的复用思路行业分析师这个角色的设计模式可以直接复用到团队里的其他角色。最重要的是三件事把角色边界写进系统提示词把输出结构化成可解析的 JSON把质量保障拆成独立检查流程。后续搭建财务分析师时可以把行业分析师提供的industry_cost_drivers字段作为财务模型的输入同时沿用证据分级和结论分级机制。搭建风险分析师时可以复用unverifiable_assumptions和opposing_questions把它们作为风险清单的基础素材。搭建反方 Agent 时它天然依赖行业分析师输出的narratives字段——那些被识别出的宏大叙事正是最有价值的反驳靶子。行业分析师是 9 人研究团队里非常基础但非常关键的节点。它负责把宏观趋势翻译成可被后续角色验证或反驳的行业判断同时也是第一道拦截宏大叙事的闸门。搭建这个角色时真正要做的不是让它更像一个分析师而是让它学会区分两件事行业是否值得研究以及现在是否值得入场。前者靠流程后者靠证据。只要把证据标注、反向研究、结论分级这三件事做实这个 Agent 在团队里的价值就会立刻显现。后续搭建财务分析师或风险官时可以继续沿用这套结构化方法把同样严谨的研究纪律复制到整个团队。