9人研究团队这个项目更新到第四篇前面的坑已经趟了不少。这次要拆的角色是行业分析师。它不负责收集资料不负责处理数据只回答一个问题行业故事讲得再大到底是不是入场的理由。这句话听起来像投资逻辑但落到工程上就是一类典型的Agent指令让大模型接收一堆行业素材然后输出一个带约束的判断而不是机械复述。很多AI研究团队最后沦为“废话生成器”问题就出在这个角色没有独立立场。行业分析师如果只会顺着资料说好话那整个多智能体管线的价值都会被稀释掉。这篇文章会把行业分析师的定位、提示词模板、多Agent任务编排、结构化输出、接口API、批量任务、成本观察、常见问题全部展开。你可以不沿用这个9人团队的完整框架单独把一个行业分析师Agent摘出来接进自己的研究管线或投资决策流程里。它本质上是一个可以独立部署、独立验证的AI角色。适合正在搭多智能体团队的研发同学、做行业研究的分析岗以及所有被“万亿市场”“景气度持续提升”这类宏大叙事折磨过的人。核心只有一点怎么让大模型学会区分“市场讲了一个好故事”和“这个行业现在真的能进去”。下面直接进主题。1. AI多智能体行业分析师核心能力速览先把能力清单放在最前面方便你做技术选型。这个Agent不是一个大模型而是一个由角色定义、任务协议、结构化输出、重试机制组成的服务单元可以单独运行也可以挂进更大的多智能体系统。能力项说明角色类型研究型Agent中的行业分析角色属于多智能体协作的一环上游输入信息采集Agent输出的行业资料、公司新闻、研报摘要、市场数据下游输出行业结论、证据缺口、入场判断、条件触发项核心能力拆解行业生命阶段、区分叙事层与事实层、识别证据缺口、给出条件式结论扩展能力批量分析多个细分行业、API接口调用、定时跑批任务运行方式大模型API调用不依赖本地显卡也可接入本地大模型推理服务部署形式Python脚本 / FastAPI服务 / 任务队列Worker批量任务支持按行业列表批量调度需自行控制并发与重试是否提供API可通过FastAPI封装为内部服务典型输出结构化JSON含entry_verdict、evidence_gap、conditions等字段在这个系列的设计里这个Agent最大的价值不是“能总结”而是“敢拒绝”。它需要拒绝低信息密度的表达。“市场空间大”不算结论算开场白“龙头集中度提升”不构成入场信号要看集中度提升的速度和驱动力。这些约束全部要写进Prompt和输出协议里而不是指望模型自己“懂事”。2. 行业分析师在9人研究团队中的定位在9人研究团队这种多智能体系统里角色之间的分工必须非常清楚。行业分析师既不负责把PDF转成文本也不负责清洗财报数据它是在研究管线中间层做判断的节点。前几篇已经搭好了多角色任务调度的基础框架这一环要解决的核心问题是上游给一堆素材下游要一个判断中间怎么保证判断不是材料的简单复读。上游给它一包资料可能是新闻列表、券商研报摘要、公司官网信息、财务快报来源很杂。下游等着它的结论比如策略Agent要据此生成配置建议风险Agent要据此识别哪些信号说明入场前提不成立。如果行业分析师输出的内容只是把上游材料重新排列一遍下游Agent就没有增量信息可用整个9人研究团队的串联能力就崩塌了。更关键的是它要做“反叙事”动作。行业分析师必须从需求、供给、竞争、财务、资本五个维度同时看一个行业任何单一维度的故事都不能直接转化为入场理由。需求侧真实需求还是政策催生出来的需求有没有人愿意持续付费供给侧技术成熟度曲线走到什么位置产能能不能跟上竞争格局新进入者的壁垒是什么头部厂商能不能守住份额财务验证主要玩家是否已经验证了单位经济模型还是靠融资续命资本态度一级二级市场的热度是领先指标还是已经透支这五个维度就是行业分析师的“内部工作台”。在Agent实现里可以做成一个中间推理步骤先让模型依次输出五维摘要再合成最终判断。这样做的好处是模型不会因为某一篇材料过分乐观或过分悲观就整体带偏结论。这里需要说明的是这些维度不是让Agent穷举所有信息而是帮它过滤噪音。很多行业材料都在讲市场规模预测但市场预测恰恰是最容易失真的信息。真实行研会用历史渗透率、订单能见度、客户复购这些可追踪指标去交叉验证。Agent也应该这样先找可验证指标再下结论而不是把一份预测数据当作事实直接引用。3. 提示词工程让Agent拒绝宏大叙事行业分析师的Prompt核心是“立场纠正”。你需要明确告诉模型你不是来夸这个行业的你是来判断入场时机的。模型在默认状态下非常容易顺着用户语气走如果输入材料全是乐观情绪模型很可能也输出乐观结论。所以必须用System Prompt把分析立场钉死。下面给出一版通用Prompt模板可以直接复制到你的Agent项目里。这里只写提示词工程部分不绑定具体大模型供应商。# System Prompt 你是一名行业分析师服务于一个多智能体研究团队。 你的任务是基于输入资料判断这个行业的宏大叙事是否经得起事实检验现阶段是否值得入场。 你必须遵守以下工作原则 1. 事实优先于观点。任何结论必须关联到资料中的可验证信息。 2. 区分叙事层与事实层 - 叙事层媒体标题、券商口号、发布会愿景、市场对未来的预期。 - 事实层收入、出货量、订单、渗透率、产能利用率、复购率、毛利率、市占率。 3. 对每一个宏大叙事尽量找到对应的可验证指标。找不到就标记为 evidence_gap。 4. 不要直接输出长期看好这类无法证伪的结论。 5. 最终 verdict 只能是三个之一enter_now当前具备入场条件、wait需要等待条件触发、pass放弃。 # 输出格式要求 以 JSON 对象输出包含以下字段 narrative_claims: 从资料中提取的主要宏大叙事最多5条 fact_check: 每条叙事对应的事实证据或证据缺口 five_dimension_review: 需求、供给、竞争、财务、资本五个维度的简要判断 entry_verdict: enter_now / wait / pass conditions: 如果 verdict 是 wait列出触发入场需要观察的条件 evidence_gap: 当前资料中缺失的关键信息 risk_warning: 必须提示的风险点这个Prompt看起来很长但它解决了三个关键问题。第一它给了模型一个独立的“分析立场”避免模型顺着上游资料的语气走。第二它用输出格式约束模型必须把叙事和证据分开这比在文章里写“要客观”有用得多。第三它让输出结果可以被程序解析下游Agent可以直接消费不需要再人工从长文本里抽字段。实际使用的时候System Prompt里还可以加入行业相关的背景知识。比如分析消费电子时补充“库存周期”“换机周期”这类专业术语分析AI工具时补充“MAU”“付费转化率”“留存率”这类指标。上下文越贴近行业输出越能避开空话。但Prompt本身不能代替数据如果模型拿到的资料只有一篇媒体稿即使Prompt写得再好它也只能输出“资料不足”。所以在真实系统里更建议把evidence_gap做成强制字段让模型主动承认自己不知道什么。很多Agent项目不愿意让模型输出“不知道”总觉得这是能力不足。其实对研究型Agent来说知道自己不知道什么比硬写一个漂亮结论有价值得多。4. 多智能体任务编排输入输出协议接下来是把行业分析师接进多智能体流程。这个系列前几篇已经搭好了基础调度框架这里只说明行业分析师这一环的输入输出协议怎么设计。在设计多智能体系统时比较推荐的做法是每个Agent之间的数据交互都用结构化JSON而不是自由文本。因为自由文本拼接容易丢失字段也会让下游Agent解析不稳定。如果上游发来一大段散文下游策略Agent还要自己做信息抽取效率低且容易出错。给出一份简化的任务编排配置{ agent_id: industry_analyst, role: 行业分析师, upstream: [info_collector, data_processor], downstream: [strategy_agent, risk_agent], input_schema: { industry_name: string, focus_question: string, source_materials: [array of text chunks], market_data: optional json }, output_schema: { narrative_claims: array, fact_check: array, five_dimension_review: object, entry_verdict: string, conditions: array, evidence_gap: array, risk_warning: array } }所有下游Agent只读这个JSON不直接读原始资料。这样设计有几个好处。第一解耦。资料收集Agent的存储方式发生变化时下游分析任务不受影响。第二可审计。可以把每个行业分析Agent的输入JSON和输出JSON全部落盘方便后续回溯和效果对比。第三便于做多版本测试。同一个agent_id和同样的输入需要在调试时反复调整Prompt和模型参数如果协议不统一每次对比都没有基准。这个配置文件在实际项目中可以用YAML、JSON或数据库表保存。建议至少把schema版本号放到配置里。因为Agent系统迭代很快输入输出协议一旦变过对旧结果和新结果做横向对比就会非常困难。版本号记录是成本最低的兜底手段。另外还要说明一点9人研究团队不是每次任务都必须全流程跑。行业分析师可以单独接收一批素材并处理。因此在调度系统设计时需要支持“局部任务触发”即消息队列里来一条研究任务只有命中了“行业分析”类型才唤起这个Agent。否则每次都要等9个Agent跑完成本和延迟都扛不住。5. 最小可运行实现Python构建行业分析师Agent现在给出一个最小Python实现。不依赖LangChain这类重框架只用标准库加requests方便直接理解核心逻辑。实际项目里可以在此基础上升级为异步框架或任务队列。import os import json import requests class IndustryAnalystAgent: 行业分析师Agent最小实现。 使用方式 agent IndustryAnalystAgent(api_key...) result agent.analyze( industry_nameAI编程辅助工具, focus_question当前AIGC编程工具渗透率是否已经跨过早期采用者阶段, source_materials[...], ) SYSTEM_PROMPT 你是一名行业分析师... # 使用上一节的Prompt def __init__(self, api_keyNone, model, base_urlhttps://api.openai.com/v1): self.api_key api_key or os.getenv(LLM_API_KEY, ) self.model model or os.getenv(LLM_MODEL, gpt-4o-mini) self.base_url base_url def _call_llm(self, messages: list) - str: url f{self.base_url}/chat/completions headers { Authorization: fBearer {self.api_key}, Content-Type: application/json, } payload { model: self.model, messages: messages, temperature: 0.2, response_format: {type: json_object}, } resp requests.post(url, jsonpayload, headersheaders, timeout120) resp.raise_for_status() return resp.json()[choices][0][message][content] def analyze(self, industry_name: str, focus_question: str, source_materials: list[str]) - dict: user_content { industry_name: industry_name, focus_question: focus_question, source_materials: source_materials, } messages [ {role: system, content: self.SYSTEM_PROMPT}, {role: user, content: json.dumps(user_content, ensure_asciiFalse)}, ] for retry in range(3): try: output self._call_llm(messages) parsed json.loads(output) # 强制校验关键字段 assert entry_verdict in parsed assert evidence_gap in parsed return parsed except (json.JSONDecodeError, AssertionError, requests.RequestException) as e: if retry 2: raise RuntimeError(f行业分析师调用失败重试3次后退出: {e})这个实现非常简短但它包含了一个Agent该有的骨架System Prompt定义模型人设和工作规则User消息里塞入结构化输入API调用使用低temperature保证输出稳定解析JSON并校验关键字段失败重试三次。在真实项目中你需要根据自己的大模型服务调整base_url、model名和response_format。如果使用DeepSeek、Qwen等兼容OpenAI协议的服务结构基本不变。如果使用的是本地模型可能要去掉response_format并在解析层做更宽松的容错。因为本地模型对JSON结构化输出的遵从度往往不如商用API稳定必须在解析层兜底。读者如果希望看到FastAPI封装可以直接看后面第8节。批量任务部分也放到后面这里先确保单个Agent能被调用即可。拿到单点可用之后再上并发和API化排查问题会容易很多。6. 结构化输出叙事层与事实层分离行业分析师输出什么直接决定了这个Agent是不是真的有用。我把输出分成“叙事层”和“事实层”两大块。简单来说叙事层是别人告诉你的故事事实层是你能拿到的证据两者必须分开存储不能混在一个长段落里。下面是一个示意输出。{ industry_name: AI编程辅助工具, focus_question: 当前AIGC编程工具渗透率是否已经跨过早期采用者阶段, narrative_claims: [ {claim: AI将重塑软件研发范式, narrative_source: 多家媒体/厂商发布会}, {claim: AI编程工具用户量快速增长, narrative_source: 公开用户量数据} ], fact_check: [ { claim: AI编程工具用户量快速增长, evidence: 头部产品MAU披露数据、开发者调研报告, evidence_level: 部分可验证, gap: 缺少企业付费转化率与续费率数据 } ], five_dimension_review: { demand: 早期需求旺盛但付费意愿需验证, supply: 技术供给能力持续提升, competition: 竞争激烈头部集中度仍不稳定, finance: 头部厂商收入增长快盈利质量尚未验证, capital: 一级市场热度较高需警惕估值透支 }, entry_verdict: wait, conditions: [ 观察头部产品企业级客户的续费率是否稳定超过阈值, 观察开发者在日常工作流程中的覆盖率是否持续提升 ], evidence_gap: [ 缺少主要厂商的分客户类型收入结构, 缺少开发者付费转化漏斗数据 ], risk_warning: [ 行业处于早期阶段商业模式尚未完全验证, 巨头进入后可能导致中小厂商份额快速压缩 ] }这个输出的好处是显而易见的。它把“AI将重塑软件研发范式”这种宏大叙事归到narrative_claims同时标记来源。下游判断时可以看到这个信息但它不会被当成事实使用。evidence_gap字段暴露了当前证据的不足这会让整个研究团队意识到本次分析的置信度有限。实现层面还有一个技巧强制模型在拿到每个叙事信息时必须回填一个“证据等级”。可以设计成verified、partial、unverified三档。如果大量字段都是unverified那么这个Agent给出的verdict就不应该被下游策略Agent当作强信号使用。这一点也是防止“宏大叙事变成入场理由”的最有效手段。当模型必须面对自己证据不足这件事时它很难再输出一个斩钉截铁的“长期看好”。逼模型承认不知道反而会让整个系统更可靠。7. 功能测试与效果验证行业分析师Agent跑通后不能只看一次输出漂亮就收工。需要建立一套可重复的验证流程。下面给出一套通用测试方案不依赖特定数据集用你自己手头的素材就能跑。7.1 基础能力测试测试目的确认Agent能正常接收素材并返回结构化JSON。输入素材两篇关于AI编程辅助工具行业的公开文章摘要或任意文本片段。操作步骤调用agent.analyze传入industry_name和focus_question。预期结果返回JSON包含所有核心字段没有解析异常。判断成功标准entry_verdict字段是enter_now、wait、pass三者之一且evidence_gap字段存在。如果连基本JSON都返回不了优先检查API配置和Prompt里的输出格式指令。7.2 反宏大叙事测试测试目的验证Agent是否有独立判断不会顺着输入素材的乐观语气走。操作方式很直接把输入素材写得非常乐观比如“AI行业即将爆发市场空间万亿”但同时不给任何财务或订单数据。然后观察Agent的输出。判断标准如果Agent直接输出enter_now且没有任何evidence_gap说明它被宏大叙事带偏了需要调整Prompt。更合理的输出应该是wait或pass同时evidence_gap里明确列出缺少数据。这一步是行业分析师Agent最重要的验收项因为一个只会复述素材的Agent在真实业务里不会带来增量价值。7.3 条件触发测试测试目的确认wait结论能输出有效触发条件。当verdict为wait时conditions字段必须包含可观测指标而不是“等待行业进一步发展”这种废话。可以用一个简单规则去校验conditions里的每一条是否都包含一个可以观察的数据指标。比如“观察企业级客户的续费率是否稳定超过80%”就是可观测条件高于“关注未来增长”这种空泛表达。7.4 批量稳定性测试测试目的确认Agent在同一批行业上连续执行输出结构不漂移。可以用5个行业跑20轮统计字段缺失率和JSON解析失败率。如果失败率超过5%说明重试和容错需要加强。结构漂移通常表现为某些轮次多了字段、某些轮次少了字段、JSON里出现多余注释。这时需要在解析层做归一化处理统一输出schema。功能测试的逻辑是功能演示不是看完一篇输出就结束而是要把“什么算坏结果”也定下来。只有同时定义了好结果和坏结果才能迭代提示词和模型。坏结果的定义越具体系统迭代方向就越明确。8. 接口API与批量任务接入行业分析师Agent在团队内部使用时建议封装成HTTP接口。这样其他角色、外部系统、定时任务都可以调用。下面给一个FastAPI封装示例。from fastapi import FastAPI, HTTPException from pydantic import BaseModel, Field from agent_impl import IndustryAnalystAgent app FastAPI() agent IndustryAnalystAgent() class AnalyzeRequest(BaseModel): industry_name: str focus_question: str 该行业目前是否具备入场条件 source_materials: list[str] Field(..., max_length20) class AnalyzeResponse(BaseModel): industry_name: str entry_verdict: str evidence_gap: list[str] conditions: list[str] risk_warning: list[str] app.post(/industry/analyze, response_modelAnalyzeResponse) async def analyze_industry(req: AnalyzeRequest): try: result agent.analyze( industry_namereq.industry_name, focus_questionreq.focus_question, source_materialsreq.source_materials, ) return result except Exception as e: raise HTTPException(status_code500, detailstr(e))启动服务可以使用命令uvicorn main:app --host 127.0.0.1 --port 8000。启动后可以用curl做一次快速验证确认接口链路是否通。curl -X POST http://127.0.0.1:8000/industry/analyze \ -H Content-Type: application/json \ -d { industry_name: AI编程辅助工具, focus_question: 当前是否具备入场条件, source_materials: [这里放行业报告摘要, 这里放新闻摘要] }返回结果中会拿到entry_verdict、evidence_gap、conditions、risk_warning这些结构化字段。接口可以跑通后就可以把行业分析师能力开放给团队内部的其他业务系统使用。批量任务场景下需要考虑三件事。第一并发控制。大模型API一般都有速率限制同时请求数量过大会触发429错误。建议在批量循环里使用信号量限制并发数比如同时最多3个请求。第二失败重试。超时、限流、JSON解析失败都需要重试而且重试要加指数退避避免打爆上游API。第三结果落盘。每次批量分析的结果都要写到文件、数据库或对象存储里后续可以按行业、按时间维度分析也可以用来复盘Prompt调整前后的效果。下面给一个简单的异步批量调度示例。import asyncio import aiohttp SEMAPHORE_LIMIT 3 async def analyze_one(session, payload): async with SEMAPHORE_LIMIT: async with session.post(http://127.0.0.1:8000/industry/analyze, jsonpayload) as resp: return await resp.json() async def batch_analyze(industry_list): async with aiohttp.ClientSession() as session: tasks [analyze_one(session, item) for item in industry_list] results await asyncio.gather(*tasks, return_exceptionsTrue) return results上面用到了aiohttp库实际项目里可以根据你的技术栈替换成httpx、requests或者其他客户端。核心思想是批量任务不是一个for循环发请求那么简单必须考虑并发限制和异常收集。否则跑到第20个任务时前面的异常可能会把进程拖垮。批量任务做完以后建议加一个质量抽检步骤。从100条结果里抽10条人工看是否出现明显幻觉、是否答非所问、是否输出过长的空泛结论。这个抽检成本不高但对保证研究团队的输出质量很有价值尤其当结果要进入下游决策链的时候。9. 资源消耗与稳定性观察如果按常见的大模型API方式部署行业分析师Agent跑在API上不涉及本地显存。资源观察重点在token开销、上下文窗口和成本控制。如果你改用本地大模型部署才需要额外关注显存占用这部分要按你实际的模型参数量和量化位准去测没有统一答案。先看token开销。一次完整调用包含三部分System Prompt固定长度大约800到1500 token取决于你写的详细程度User输入由source_materials长度决定行业分析场景一次传10到20个文本片段很常见可能到5000到10000 token模型输出是JSON结构一次约800到1500 token。如果只是单次分析消耗不大。但如果做批量行业研究比如一次跑50个行业累计token就会明显增加。更麻烦的是所有素材拼接进上下文后模型容易在长文本中注意力衰减导致输出质量下降。所以工程上要做的第一件事就是压缩源材料信息采集Agent在把资料传给行业分析师之前应该先做摘要、去重、截断不要把原始PDF全文塞进来。控制上下文长度的常用做法包括每个文本片段限制在500到1000字以内按相关度排序后只保留Top N个片段重要数字单独抽出来作为market_data字段传入使用支持更长上下文的模型时仍需注意输出稳定性。长上下文不等于高质量分析反而更容易让模型抓不住重点。在稳定性方面常见隐患是模型在长上下文下会重复部分内容或者JSON里多出注释导致解析失败。所以解析层一定要做兼容处理可以把模型返回内容中的JSON块用正则提取而不是直接json.loads整个字符串。降低成本的另一个角度是缓存。如果同一个行业、同一批素材在短时间内重复分析结果往往没有变化。可以在Redis或者内存里加一层缓存key用行业名加素材哈希值。这个方案能显著减少重复请求尤其在定时任务每天跑同一批行业的场景下非常省钱。10. 常见问题与排查方法行业分析师在真实使用中会遇到的问题主要集中在输出质量、接口调用和批量任务这三个方向。下面用一张表整理常见现象、可能原因和处理思路。问题现象可能原因排查方式解决方案输出全是“行业发展前景广阔”类空话没有做立场纠正或输入素材只有乐观观点检查System Prompt是否包含事实优先原则增加“区分叙事层与事实层”指令强制输出evidence_gapAgent从不输出enter_now过于保守Prompt约束过强或缺少正面事实素材查看fact_check字段确认输入资料是否覆盖正面数据在Prompt中补充“当多个可验证指标同时成立时可以给出enter_now”返回JSON解析失败模型输出夹杂了Markdown或额外文字查看原始返回内容用正则截取JSON块或强制response_format为json_objectAPI调用报429超出速率限制检查接口返回头和日志增加限流、指数退避重试批量任务跑到一半卡死单次请求超时或内存积累查看worker日志为每个请求设置超时时间任务队列增加断点续跑同一个行业两次分析结果差异很大模型temperature过高或输入素材顺序不同固定temperature锁定素材顺序设定temperature为0.1到0.3稳定材料拼接顺序evidence_gap永远为空模型不敢承认不知道检查Prompt是否强调证据不足可以承认加入“如果缺少证据必须标记gap不允许猜测”指令分析结果与最新事实不符训练数据存在时间滞后检查输入素材时效性确保信息采集Agent补充最近新闻与数据这些排查项都指向同一个原则Agent的输出质量高度依赖输入质量和Prompt约束而不是模型本身有多智能。把这两层管好大部分问题就能解决。11. 最佳实践与使用建议行业分析师Agent的工程化落地远不止写一个Prompt和几行代码。下面几条建议在搭建类似Agent系统时都适用尤其是研究型多智能体项目。第一第一次搭建时先跑小参数测试。用1个行业、5个文本片段验证链路。很多项目上来就批量分析50个行业结果发现接口解析有bug50个任务全部失败。先小后大可以降低调试成本也能更快定位是代码问题还是Prompt问题。第二保留一套最小可运行配置。把固定的System Prompt、模型参数、输入模板、输出schema放在单独的配置目录里不要散落在代码里。这样每次调整都能快速对比。如果配置经常变动建议用config版本管理工具至少也要在文件名里带上日期。第三素材质量比Prompt重要。行业分析师能输出什么样的结论取决于上游信息采集Agent给了它什么。如果上游只有一篇充满形容词的行业软文任何Prompt都不能让它变成严谨分析。所以在团队里信息采集Agent的权重一定要专门调优尽量给行业分析师喂带数据、带出处的材料。第四使用条件式结论避免绝对化判断。行业研究很少有“一定可以入场”的结论。更多情况下Agent应该输出“在什么条件下可以入场”“在什么信号下要退出”。这样的结果对下游策略Agent更有价值也更符合真实决策场景。第五多Agent互相审计。在9人团队里可以让风险Agent接收行业分析师的证据缺口字段专门对evidence_gap做二次追问。这样等于给行业分析师加了一道质检工序。如果风险Agent发现证据缺口过大而行业分析师仍然给出enter_now这个矛盾应该被标记出来重新分析。第六涉及版权、隐私、商业机密和敏感数据的素材必须确认获取和使用的合法性。Agent承担的研究任务越接近真实决策对数据源合规的要求就越高。如果素材来源不明确宁可提示使用者不要采用该结论也不要让Agent基于黑产数据或侵权内容生成分析。第七从用户角度看不要让Agent直接持有“应当入场”的绝对决定权。Agent的输出应当被当作辅助分析材料由人来做最终判断。尤其涉及投资、商业决策时必须保留人工复核环节。AI可以压缩信息密度但不能替代人为责任。12. 总结与下一步这次拆完行业分析师这个9人研究团队的中间判断层已经补上了最关键的一块。行业分析师不是让AI讲出更大的故事而是让AI在故事面前踩一脚刹车问一句可验证的证据在哪里。这个角色真正要产出的不是一篇漂亮的行业报告而是一份带证据缺口和条件触发的判断结果。你现在最应该验证的是它的“反宏大叙事测试”。把一堆乐观素材丢给它看它有没有勇气把verdict写成wait或者pass并且列出当前材料的证据缺口。如果它做到了这一步说明这个Agent形成了自己的判断框架而不是一个复读机。最容易踩的坑是输入素材拼接失控。资料越多模型越容易陷入泛泛而谈。先做素材抽取和截断再交给行业分析师是这个角色稳定运行的前提。另一种常见坑是输出结构漂移需要在解析层做兜底不能完全信任模型的JSON格式承诺。后续的搭建方向也比较清楚可以给行业分析师挂上真实的数据接口比如价格、销量、财报指标定时更新也可以让多个行业分析师并行跑再把不同行业的结论汇总给策略角色。等这一层跑通整个9人研究团队就能从“能回答行业问题”升级到“能自己发现问题并追踪变化”。下一篇可以继续拆解负责把分析结论转化为行动方案的策略角色。