企业官网建设流程全解析

做金融投研的人都有一个共同的疲惫感：每天开盘前，你需要快速处理隔夜行情、公司公告、行业新闻、财报数据，有时候还要临时拉一份可比公司分析。这些信息量庞大且碎片化，手动汇总往往要花掉一两个小时，留给真正思考的时间少得可怜。我自己在搭建投研辅助工具时也经历过这个阶段——从写脚本自动化抓数据，到后来发现脚本解决不了"理解"问题，才开始转向智能体方案。这篇文章要聊的，就是基于OpenClaw这类企业级智能体框架，把重复的投研信息处理工作交给"数字研究员"的方法。重点会拆解17个实操场景，并给出可以直接参考的代码链路，适合正在做投研工具、量化研究支持或企业内部投研中台的开发者，也适合想用智能体替代重复劳动的投研分析人员。

所有代码我都按能跑通的最小工程结构来组织。你可以把OpenClaw理解为一个偏重"任务编排 + 工具调度"的智能体底座：它本身不替你决策，而是把"查什么、算什么、读什么、写什么"这些步骤拆成一个个可编排的任务，再由模型根据上下文调用工具、组合结果。这个思路和我之前用脚本写投研工具的感受完全不同，下面从场景价值开始讲。

1. 为什么金融投研是智能体落地最值得做的场景之一

1.1 投研工作的本质：信息搬运加上结构化判断

很多人觉得投研是纯研究型工作，但真正做过的人会有另一个感受：一天里大量的时间花在"搬信息"上。隔夜海外市场涨跌、行业板块的资金流向、重点公司公告里的关键数据、财报里同比环比变化，这些内容本身没有太多智力门槛，难的是把它们快速、准确、不遗漏地汇总到一起。

这正是智能体最容易发挥价值的地方。数据抓取脚本只能按照固定规则拉取字段，但投研信息的表达方式千变万化：同一家公司的公告可能用"净利润同比增长20%"也可能用"实现利润总额XX亿元，增幅两成"。传统脚本面对这种差异就得不断维护规则，而智能体可以把"提取关键信息并按标准结构输出"当作一个理解任务来处理。

1.2 传统自动化方案的三个硬伤

在转向智能体之前，我试过很长时间的纯脚本方案，也用过现成的数据工具，总结下来有三个绕不开的硬伤。

第一，抓数容易理解难。脚本拉回来一堆行情、财务字段，但这些数据之间是什么关系、为什么今天这个板块异动、这个指标异常意味着什么，脚本完全无法回答。最后还得人去看原始数据，自动化的效率大打折扣。

第二，规则写不完。市场语言变化太多，财报表述、公告格式、研报风格每次都有差异。你写了50条解析规则，第51种情况又出现了，而且规则的优先级冲突会让结果越来越难维护。

第三，结果不敢直接信。脚本输出一个数字，没人知道这个数字从哪张表里来、口径对不对。投研是强审计场景，每一步结论都需要能追溯来源。普通脚本把这一步做成了黑盒，风控和合规根本不敢用。

1.3 智能体方案为什么能补上这些缺口

OpenClaw这类企业级智能体框架解决的是"从数据到结论的完整链路"。它把工作拆成任务、工具、知识三层：任务层定义"要做什么"，工具层提供"能做什么"，知识层负责"依据是什么"。模型在中间做调度和理解，每一步操作都有记录，输出报告可以带上引用来源，这就把前面说的三个硬伤逐个化解了。

所以，我建议不要把它当成一个简单的"AI助手"，而是当成一个可以按投研逻辑编排的流水线引擎。接下来我把我实际搭建时用到的架构完整展开。

2. OpenClaw数字研究员的技术架构：任务编排到工具调用的设计

2.1 四层架构：任务层、编排层、工具层、知识层

我在搭建时把OpenClaw上的投研应用分成四层，后面对话里提到的代码都是按这个分层组织的。

• 任务层：每一类投研工作对应一个可复用的任务定义，比如"行情异动扫描""公告事件抽取""财报指标提取"。任务层只描述输入输出和参数，不含具体业务逻辑，方便统一管理。
• 编排层：把多个任务按投研流程组合成流水线，比如"日报流水线"就是先扫行情、再抓新闻、然后提取公告、最后生成报告。这一层同时负责错误重试、超时控制、上下文传递。
• 工具层：所有外部能力都以工具形式注册进来，行情快照、新闻搜索、财务数据接口、向量检索、文档解析，全部是插件化接入。模型通过工具名和参数描述来调用它们，不需要改核心代码。
• 知识层：存放历史研报、公告原文、行业资料等非结构化内容，用向量检索把相关内容召回后拼进模型上下文，让输出有依据。

这里面最关键的思路是：模型不直接碰数据库，也不直接写文件，所有操作都通过工具完成。这既是为了安全审计，也能让每次调用都有日志。

2.2 编排层的核心：从"写死流程"到"意图路由"

早期做自动化投研工具，流程是写死的：先查A接口，再解析B文件，最后拼装C模板。问题是一旦中间步骤发生异常，整个链路就断了，而且没法处理"这个公司没有发布财报"这类分支情况。

OpenClaw的编排层引入了意图路由和工作流两步走的机制。简单理解：

• 对结构固定的批量任务（比如每早8点跑全市场异动扫描），走工作流模式，按预设DAG顺序执行，每个节点都是之前定义好的任务。
• 对开放式的研究问题（比如"分析一下最近新能源板块为什么走强"），走意图路由模式，模型自主选择调用哪些工具、按什么顺序组合，最后汇总答案。

两种模式混在一个平台里，生产环境才能同时保证"可预期"和"灵活"。我在实现时把工作流定义成结构化配置，这样就算没有模型参与，调度引擎也能正常跑完链路，模型只负责需要理解和判断的节点。

2.3 工具注册与可插拔接入机制

工具层是所有能力的最小单元。在OpenClaw里，我把一个工具定义成三个部分：工具名、入参结构、执行函数。模型看到的是工具名和参数描述，实际执行时由函数去对接数据源SDK或HTTP接口。

这样做的好处是隔离性极强。比如我接入的行情数据源后来换过一次服务商，只需要修改market_snapshot这个工具内部的实现，上面的任务定义和编排层完全不用动。注册工具的代码骨架类似这样：

# tool_registry.py from openclaw import ToolRegistry, tool registry = ToolRegistry() @tool.register( name="market_snapshot", description="获取指定市场在某一交易日的行情快照，包含指数、成交额、涨跌家数", params={ "date": {"type": "string", "required": True, "desc": "交易日，格式YYYY-MM-DD"}, "market": {"type": "string", "required": False, "desc": "市场代码，默认CN"}, }, ) def market_snapshot(date: str, market: str = "CN") -> dict: # 内部对接行情服务商提供的Python客户端 client = get_market_client() dataframe = client.snapshot(date=date, market_code=market) records = dataframe.head(50).to_dict(orient="records") return {"market": market, "date": date, "records": records}

藏在这段代码背后的一个经验是：工具返回值一定要结构化，别让模型去解析一段打印日志，模型解析JSON比解析日志可靠得多。另外每个工具都应该返回"来源标记"，比如数据源编号、抓取时间、原始记录ID，这是后面做引用链追溯的基础。

2.4 人与AI的分工界面：保留一个审阅位

架构上还有一个容易被忽略的设计：每个任务节点在生成结论后，都必须带一个"审阅状态"字段。OpenClaw流水线跑完不是直接发报告，而是先进入一个审阅队列，由研究员确认后再对外推送。这个审阅位不是摆设，后面第6章我会讲没有它会有多惨。

3. 17个投研场景全景拆解：按信息链路分层的打法

3.1 场景地图：三类任务，覆盖信息处理全链路

我整理了一个17场景的清单，按信息在投研工作中的流动方向分成了三组：采集与结构化、分析与洞察、决策与交互。表格如下，先给你一个全貌。

表格里每一行放到OpenClaw里的实现路径都不太一样。有些是单工具就能完成的，比如行情扫描；有些需要走完整条流水线加RAG，比如产业链图谱生成。我把三类场景背后的共性逻辑讲一下。

3.2 采集与结构化组：先解决"数据可信"

第一组是第1到第6个场景，核心目标是让原始信息变成干净、结构化、可检索的数据。

比如第3个场景"财报关键指标提取与标准化"，难点在于不同公司的财报格式不同，有的在资产负债表里叫"应收账款"，有的叫"应收款项"。OpenClaw的做法是先让模型阅读报表结构识别科目，再映射到统一的指标字典。这个映射表一开始可能需要人工维护，但模型会把每次识别时的上下文存下来，后面的准确率会越来越稳。

再比如第5个场景"主力资金流向追踪"，如果数据源只给当日净流入，数字很容易失真。更可靠的做法是同时抓取多日的流向明细，让模型计算连续3日和5日的累计流向，再结合涨跌幅归因生成提示。这类任务调度上放在尾盘后比较合适，避免盘中频繁请求数据源。

3.3 分析与洞察组：把数据变成逻辑链条

第二组是第7到第12个场景，处理的不再是单条信息，而是多份数据的交叉和归因。

第7个场景"行业产业链结构图谱生成"最有代表性。它需要把几十篇行业研报切片、分块、向量化，再通过模型抽取每个实体（公司、产品、原材料）之间的上下游关系。我实际跑下来的体感是：图谱质量不完全取决于模型，更取决于知识库里研报覆盖是否全面。如果知识库里只有三五篇研报，生成的图谱一定比较单薄，这个场景必须配合持续的知识库建设。

第9个场景"财务异常波动识别"要小心一点。模型在解释异常时容易把"波动大"直接说成"财务造假"。我的做法是在工具库里增加一个勾稽校验工具，用来核对利润表、现金流量表之间的逻辑一致性，异常识别结果必须引用至少两个财务指标的组合才允许生成提示。

3.4 决策与交互组：守住输出边界

第三组是第13到第17个场景，这类场景直接面对研究员甚至投资经理，对表达形式和合规边界要求最高。

第16个场景"投研知识库智能问答"就是经典的RAG应用。但投研场景有一个特殊要求：答案不是越多越好，而是越能定位出处越好。我在知识库层强制要求每条回答后面挂引用列表，引用必须来自实际文档切片，不能由模型编造。这个约束会在第6章展开讲。

第17个场景"定制投研日报/周报生成"是汇总型任务，它会把前面所有场景的输出拉齐，按预设的日报模板重组。这里最忌讳的是让模型从头到尾一次性生成2000字长文，我后面给出的完整代码就是为这个场景设计的，采用的是分段组装。

4. 核心代码实现：研报自动生成引擎的完整链路

4.1 用JSON定义研报流水线

先看最早期的部分：一个日报流水线的工作流定义。我把每个步骤参数化，放在配置里，OpenClaw的调度器负责按顺序执行。

{ "pipeline_id": "daily_research_brief", "name": "每日投研简报", "schedule": "cron: 30 8 * * 1-5", "steps": [ { "task": "market_snapshot", "params": {"date": "$TODAY", "market": "CN"} }, { "task": "overnight_global_summary", "params": {"window_hours": 24} }, { "task": "announcement_extract", "params": {"event_types": ["earnings_forecast", "major_contract"], "date": "$TODAY"} }, { "task": "capital_flow_track", "params": {"lookback_days": 5} }, { "task": "sentiment_screen", "params": {"topics": ["sector_rotation", "supply_demand"], "top_k": 10} }, { "task": "report_assemble", "params": {"template": "daily_brief_v3", "output": "$REPORT_DIR/daily_brief_$TODAY.md"} } ] }

这里有一个很关键的细节："$TODAY"这样的变量占位符。流水线配置文件本身不写死日期，而是由调度器在启动时注入。这样同一份配置每天早上都能复用，不会因为日期过期导致误抓历史数据。

4.2 工具层的具体实现

接下来是几个核心工具的实现。你会看到每个工具都比较薄，只做"取数 + 结构化"两步，真正需要判断的部分留给模型。

# tools/market_tools.py from openclaw import tool from utils.market_client import get_market_client from utils.time_utils import normalize_trade_date @tool.register( name="overnight_global_summary", description="获取隔夜全球市场要闻摘要，按区域分组返回", params={ "window_hours": {"type": "integer", "required": False, "default": 24}, }, ) def overnight_global_summary(window_hours: int = 24) -> dict: client = get_market_client() # 这里使用数据服务商提供的宏观快照接口 global_data = client.global_snapshot(hours=window_hours) grouped = {} for item in global_data.get("items", []): region = item.get("region", "other") grouped.setdefault(region, []).append({ "index_name": item.get("index_name"), "change_pct": item.get("change_pct"), "event_type": item.get("event_type"), "source": item.get("source_url"), }) return {"grouped": grouped, "as_of": global_data.get("as_of")}

# tools/announcement_tools.py from openclaw import tool @tool.register( name="announcement_extract", description="从公司公告原文中抽取关键事件并打标签", params={ "event_types": {"type": "array", "items": {"type": "string"}}, "date": {"type": "string", "required": True}, }, ) def announcement_extract(event_types: list, date: str) -> dict: raw_docs = fetch_announcements(date=date) extracted = parse_with_model(raw_docs, event_types=event_types) # 模型输出格式: [{"company": "...", "event": "...", "tag": "...", "confidence": 0.9}] return {"announcements": extracted, "total_docs": len(raw_docs)}

实际开发中，parse_with_model不是直接让模型自由发挥，而是给模型一个事件标签字典和输出JSON Schema，让它按约束填充。比如事件标签只允许取值earnings_forecast、major_contract、shareholder_change、litigation等，超出范围的一律归入other。

4.3 编排器：把上下文串起来

工具都定义好后，编排器负责执行。我写了一个通用的流水线执行器，它按配置里的步骤顺序执行，把每个步骤的输出累加到上下文里，然后在最后一步把整个上下文交给报告组装任务。

# engine/pipeline_runner.py from openclaw import registry def resolve_variables(params: dict, context: dict): resolved = {} for key, value in params.items(): if isinstance(value, str) and value.startswith("$"): var_name = value[1:] if var_name == "TODAY": resolved[key] = context["today"] else: resolved[key] = context.get(var_name) else: resolved[key] = value return resolved def run_pipeline(pipeline: dict, init_context: dict) -> dict: context = dict(init_context) for step in pipeline["steps"]: task_func = registry.get(step["task"]) if task_func is None: raise RuntimeError(f"task not registered: {step['task']}") try: params = resolve_variables(step["params"], context) result = task_func(**params) except TimeoutError: result = {"error": "task_timeout", "task": step["task"]} return _mark_failed(context, step["task"], result) context[step["task"]] = result return context

这里的错误处理值得注意。任何一个工具调用超时，我不会让整个流水线崩溃，而是先把错误标记写回上下文，并触发告警。因为投研日报的环境里，某一路数据源失败并不应该影响其余数据的生成，宁可输出一份带有"部分数据缺失"标注的报告，也比早上一张白纸强。

4.4 RAG知识库接入

投研知识库问答和产业链图谱这两个场景都依赖RAG。我把知识库抽象成一个接口，接入OpenClaw后，模型可以直接通过工具调用检索。

# tools/knowledge_tools.py from openclaw import tool from core.vector_store import VectorStore from core.embedding import embed_text store = VectorStore(collection="investment_research") @tool.register( name="kb_query", description="从投研知识库检索与问题相关的文档片段，返回引用列表", params={ "query": {"type": "string", "required": True}, "top_k": {"type": "integer", "required": False, "default": 5}, }, ) def kb_query(query: str, top_k: int = 5) -> dict: query_vector = embed_text(query) docs = store.search(query_vector, top_k=top_k) return { "docs": [ { "content": doc.content, "source": doc.meta["source"], "page": doc.meta.get("page"), "score": doc.score, } for doc in docs ] }

注意我返回了source和page。这是投研问答场景的硬要求，没有来源的答案默认视为无效。后面所有基于知识库生成的段落，都会把这些字段原样带进报告。

4.5 组装与生成：分段报告模板

最后一个工具是报告组装。这是最容易写出"AI味"的一步，也是我认为最需要工程化的一部分：不要让模型自由发挥写一整篇报告，而是给它一个章节骨架和每章的材料包，让它分段填充。

# tools/report_tools.py from openclaw import tool from datetime import datetime @tool.register( name="report_assemble", description="按模板组装投研日报", params={ "template": {"type": "string", "required": True}, "output": {"type": "string", "required": True}, }, ) def report_assemble(template: str, output: str, context: dict) -> dict: sections = [] if "market_snapshot" in context: sections.append("## 一、市场概况\n\n" + render_from_market_data(context["market_snapshot"])) if "overnight_global_summary" in context: sections.append("## 二、隔夜要闻\n\n" + render_from_global_data(context["overnight_global_summary"])) if "announcement_extract" in context: sections.append("## 三、重点公告\n\n" + render_events(context["announcement_extract"])) if "kb_query" in context: sections.append("## 四、研究参考\n\n" + render_references(context["kb_query"])) if "sentiment_screen" in context: sections.append("## 五、舆情提示\n\n" + render_sentiment(context["sentiment_screen"])) markdown_content = "\n\n".join(sections) markdown_content += "\n\n> 免责声明：本报告由智能体自动生成，仅供内部研究参考，不构成任何投资建议。\n" markdown_content += f"\n> 生成时间：{datetime.now().isoformat()}\n" with open(output, "w", encoding="utf-8") as f: f.write(markdown_content) return {"output_path": output, "section_count": len(sections)}

每段填充时，模型只拿到本段需要的结构化数据，上下文长度可控，"上下文爆炸"问题也就基本不会出现了。

5. 数据接入与时效性保障：最容易翻车的环节

5.1 数据源选型的三个原则

投研智能体对数据源的需求和一般爬虫完全不同。我在选型时坚持三条原则：

• 权威性优先。宁可花多一些采购成本，也要选能提供原始数据出处、更新时间戳的官方或准官方数据源，不要用二手聚合接口。因为报告要给人看，数据来源说不清楚等于白做。
• 接口成熟度比丰富度重要。一个接口哪怕字段少，只要响应时间稳定、有完善的错误码，都比一堆花哨但经常超时的接口可靠。
• 可控的增量更新。最好支持按时间增量拉取，避免每天全量抓取造成资源浪费和数据拥堵。

5.2 盘前、盘中、盘后的调度设计

投研对时效性的要求是分级的。盘前（约7点到9点）需要跑隔夜摘要、公告提取、资金流向追踪，因为数据量相对少，适合批量流水线；盘中适合跑异动扫描和舆情预警，这类任务频率高但单次数据量小，必须保证低延迟；盘后适合跑财务指标、产业链图谱这类重计算任务，这时候数据源基本更新完毕，跑出来的结果也相对稳定。

我是通过OpenClaw的定时触发器来管理这些节奏的：

# 用于演示的调度配置片段 openclaw schedule add --name daily_premarket --timer "30 7 * * 1-5" --pipeline daily_brief.json openclaw schedule add --name intraday_screener --timer "*/10 9-15 * * 1-5" --pipeline intraday_screen.json openclaw schedule add --name after_close_metrics --timer "0 16 * * 1-5" --pipeline deep_metrics.json

这里有个经验：不要把盘中的异动扫描频率设得太高。我用10分钟一次已经足够，更短的间隔会产生大量重复告警，反而淹没有效信号。

5.3 数据质量校验：重复、缺失和时区对齐

数据质量这一章值得单独记录。第一个坑是重复：同一家公司可能在不同数据源里名字不同，拉取两次就产生两条记录。我的做法是在入库前统一做主键归一化，用"公司代码+公告标识"作为唯一键，重复的直接跳过。

第二个坑是缺失。数据源偶尔会返回空字段，如果不处理，模型会把空值理解成"数据为零"，产生严重误导。我在工具层统一做规则：遇到关键字段缺失时，返回null并在报告对应位置标注"数据缺失"，而不是让模型猜一个数字填进去。这个约束要从工具返回值里强制保证，不能靠提示词说服模型。

第三个坑是时区对齐。海外行情如果按当地时间入库，而报告里用北京时间的日期做过滤，就会漏掉半天数据。我让所有工具在返回前都执行一次normalize_trade_date，统一转成目标时区的交易日字符串。

5.4 合规边界：只做信息结构化，不做收益预测承诺

这一点放在工程之后单独说，因为它影响所有报告模板的设计。投研智能体可以做的是：把信息整理清楚、把风险提示传递到位、把不同来源的论据并列呈现。它不应该做的是：给出一句"该股票未来必涨"的结论。

这个边界不光是合规要求，从工程上看也是保护模型。一旦模型开始输出高确定性的预测句，就容易进入幻觉高发区。我在报告模板里固定放了一段免责声明，同时约定所有输出里禁止出现"必涨""稳赚""目标价保证达到"这类措辞。实际落地时，这个约定比任何技术手段都有用。

6. 实测踩坑记录：幻觉、权限和上下文爆炸

6.1 幻觉问题：把推测写成事实

我第一次跑通日报流水线时，生成的报告里写了一句"该公司因毛利率下滑导致净利润下降"，看起来很有道理，但核查后发现财报里根本没有"毛利率下滑"这个数字，是模型从"净利润下降"反推出来的。

这个问题的根因在于：模型把因果推理和事实陈述混在一起输出了。修复方案是一个混合策略。

• 工具层强制要求，陈述性句子的内容必须能在上下文里找到对应的数据来源，找不到就不写。
• 报告模板中增加一个"模型推测"分区，凡是推理性内容统一放到这个分区，并且用"推测"作为前缀。
• 最后一遍用单独一个审阅模型跑"事实一致性检查"，它的任务是核对报告中每个数字是否能在输入材料里找到，找不到就拦截。

这套三层校验下来，幻觉虽然不能完全归零，但已经不会出现在正式推送的报告里了。

6.2 权限边界：绝对不让智能体碰交易接口

我自己在测试时曾经一时冲动，想过让数字研究员在发现异动时直接下单模拟盘交易。后来冷静下来觉得这个方向风险极大。

一方面是安全风险，一旦工具层放开了写权限，一个错误的参数就可能导致不可逆操作，模型越界调用的案例行业内已经有不少教训。另一方面是逻辑风险，投研和交易需要完全不同的时延和策略逻辑，智能体做研究可以慢一点、全面一点，但交易场景对延迟和风控的要求完全不同。我的最终建议是：智能体工具层的权限一律默认只读，所有交易相关接口直接不注册。你要让系统报一个"可交易信号"，可以，输出给风控人员审核，但系统本身永远不能变成"看完研究报告就自动下单"的机器。

6.3 上下文爆炸：长报告生成时的分段策略

第二个很现实的坑就是上下文长度管理。我一开始试图让模型一次性生成一份包含市场概况、隔夜要闻、公告解析、产业链专题的完整日报，结果经常卡在超时，就算生成了，后面的章节质量也明显下降。

后来改成第4章的分段组装方式：每个章节的生成只携带本段所需的数据包，一个章节一个章节地拼。这个思路解决的不只是长度问题，还让每个章节可以独立编辑、独立重跑，某段数据出错时不用整套报告重新生成。

6.4 踩坑问题排查清单

把几个常见问题整理成表，方便你直接对照排查。

这六个问题是我搭建过程中真实遇到过的，前三个属于数据工程问题，后三个属于编排和模型协作问题。如果你一上手就遇到类似现象，不用怀疑是某个环节独有，基本都是这几个原因。

7. 工程化落地建议：从Demo到日更的投研流水线

7.1 最小可行版本怎么搭

很多人拿到OpenClaw后第一件事就想把17个场景全做出来，我建议千万不要。先搭一个三场景的MVP链路，我实际验证下来比较合适的组合是：每日行情异动扫描 + 公告事件抽取 + 投研日报生成。

这三个场景覆盖了"取数—理解—输出"的完整闭环，而且不需要太复杂的知识库建设。等这条链路稳定跑一周，再逐步加入舆情预警、资金流向、知识库问答这些扩展场景。一次铺开太多场景，出问题时排查起来非常痛苦。

7.2 从日更到多源融合的演进路径

MVP跑通后，下一步是加多源数据和历史时序。单一数据源只解决"今天发生了什么"，没法回答"这个趋势已经持续了多久"。我在第二阶段把行情、资金、舆情都接入了时序存储，让每个工具都能返回"近N日趋势"，报告的价值立刻上了一个台阶。

再往后才是产业链图谱、财务异常识别这类重分析场景，因为这些场景依赖知识库质量和历史数据积累，前两步没做好，后面效果一定打折。

7.3 人机协作：把AI当实习生，不是当研究员

整个落地过程中我体会最深的一点是：别指望智能体独立交付一份成熟的研究报告，它更像一个高度自觉的实习生。它能快速完成信息收集、初稿撰写、格式规整，但关键判断和最终审阅必须留给人。

我在流程里设计了一个强制审阅环节：所有自动生成的报告都要进入一个待确认列表，研究员打开后看到的不是"直接可用"的成品，而是带引用标记的初稿。研究员可以一键修改某段数据、删除某条不确定的推测，确认后才算完成。这个流程听起来多了一步，实际上省去了大量来回核对的时间，因为AI已经把95%的素材整理到位了。

7.4 成本控制：token从哪里省

最后聊预算。投研日报这类日常任务，最大的成本不在模型调用，而在反复把长文档塞进上下文。我的省钱策略是分层缓存：

• 行情、资金这类结构化任务，结果直接走缓存，不经过模型。
• 公告解析这类需要模型的，先做文档切片，只把可能包含关键信息的段落送给模型。
• 知识库RAG检索出来的文档，按相似度排序后只取前三到五段，不在上下文里堆满十个片段。

这套策略下，我跑一份日报的总token成本比最初版本下降了大概六到七成，而输出质量基本没受影响。成本优化不是喊口号，就是这种对上下文的严格控制换来的。

最后再分享一个小技巧：在把智能体接入正式投研流程之前，先用一份历史数据回测跑一遍，看看它能从旧新闻和旧财报里提取出什么结论，再和当时的真实市场反馈对照。这一步能同时验证工具层的数据质量、模型的理解准确度、以及报告格式是否顺手，比直接上线新场景稳妥得多。我自己的体验是，花一个下午做回测，能省下后面几周的返工时间。