企业官网建设流程全解析

在金融数据服务公司做投研系统的第七年，我最深的感受不是“数据不够多”，而是“信息过载已经开始影响判断”。当我同时盯着一家公司的财报、三份卖方研报、十几条行业新闻和一堆会议纪要时，真正有生产力的不是记忆力，而是能不能从一个模糊需求出发，稳定地把这些材料变成结论。去年我给自己立了一个项目：做一个以AI大模型为底座、由AI Agent自主驱动的投研工作流，让系统自己巡数据、自己查证、自己写结构化纪要，而我把时间留给更重要的假设与决策。这篇文章就是我在这件事上的完整复盘。

如果你也正在做AI应用开发、AI编程相关的事，尤其想用Agent处理某个垂直领域的高密度文本，这篇文章里的思路和坑应该对你有用。我会按真实搭建顺序来讲，先说架构选择，再讲哪些环节真正实现了自主，最后讲工程落地和风险兜底。

1. 为什么我把投研流程拆成“数据管线 + 决策智能体”两层

1.1 传统投研工作流里的三个隐性成本

先说传统工作流。一个典型的研究任务大概是这样：确定研究对象，去几个信息平台收集公告和研报，阅读后建立事实时间线，提取关键指标，最后形成一段有逻辑的观点。听起来不复杂，但实际做下来有三个非常隐蔽的成本：注意力切换、疲劳漏读、观点锚定。这三个成本几乎每个人都会踩中，只是不会立刻让结果出错，而是会在长期研究里慢慢侵蚀判断质量。

第一个成本是注意力切换。研究一只股票或一个行业时，往往要同时看财务数据、产能数据、管理层发言和下游舆情，这些信息分散在不同系统里，每切换一个来源，大脑就要重新建立上下文，一天下来真正用于思考的时间少得可怜。第二个成本是疲劳漏读。我自己有个明显体会：连续读三份同类研报之后，对第四份的敏感度会下降很多，容易漏掉转折句和风险提示。第三个成本是观点偏差，人很容易被最近读到的材料锚定，尤其当多份材料说法不一致时，最后写出来的结论往往取决于阅读顺序，而不是证据强度。

我尝试过用普通AI聊天窗口来缓解这些问题，效果很有限。聊天式AI适合回答单点问题，但它没有持久记忆，也不理解“连续监控一家公司两个月”意味着什么，更不会主动发现问题。所以我从一开始就决定，不做聊天助手，而是做一个能自主推进任务的Agent系统，也就是把投研流程拆成两层：底层是干净、持续更新的数据管线，上层是负责规划、调用工具、判断和执行的研究智能体。

1.2 分层设计的核心逻辑

为什么一定要拆成“数据管线 + 决策智能体”两层？因为模型不应该直接面对原始数据。原始数据里有大量噪声：PDF表格转文本后列会错位、公告里同一个公司可能用不同简称、网页上的日期格式千奇百怪。让大模型在原始文本上做推理，它会把不少算力浪费在纠错上，而且纠错失败的后果会一路传递到结论层。

所以我的数据管线负责把所有非结构化材料处理成结构化事实。具体来说，它做五件事：解析、抽取、规范化、去重、向量化。解析是把PDF、HTML、音频转写文字变成纯文本；抽取是识别公司名、时间、金额、业务主体等关键实体；规范化是把“1.2亿”和“120,000,000”统一成标准数值；去重是把同一事件在不同来源里的重复信息合并；向量化则是为了后续做语义检索。

智能体这层只管做决策，不关心材料本身在哪个网站。它拿到手的是数据管线提交的干净事实和检索入口，所以上下文更短、更聚焦，幻觉率也明显下降。这层再往上，才是面向人的交互层。也就是说，用户看到的是最终研究结果，模型从来不需要自己去和乱糟糟的原始网页搏斗。

1.3 这套架构最终解决了什么

这套架构跑起来之后，解决的核心问题可以归纳成三句话：第一，信息巡护不再依赖人的精力，系统会按固定频率检查标的池里的公司有没有新公告、新研报、新舆情，并自动判断哪些变化值得发起一次研究任务。第二，研究过程不再是人肉翻阅，Agent会把一篇研报拆成“结论-论据-数据-风险”四个要素，并逐条验证这些结论是否和原始数据一致。

第三，观点生成不再是一锤子买卖，系统会保存每次分析的状态，下次继续跟踪时直接基于之前的结论做增量更新，而不是从零开始。坦白说，这三句话听起来很像是产品宣传词，但真正把它落地，中间每一步都有不少坑。后面的章节我会一个个展开。

2. 自主驱动不等于全自动：我先让AI接管了这三个环节

2.1 环节一：信息收集与实时监控

做AI Agent最容易犯的错误，是一上来就想要一个全自动闭环，输入公司代码，直接输出买卖建议。这种想法既危险也不现实。我的做法是从环节级自主开始：先选评价标准清晰、出错后果可控的流程给AI接管，跑顺一个再扩大边界。

我第一个接管的环节是信息收集与监控。每天早上八点半，系统会启动一个研究助理Agent，遍历我的关注列表，去公告源、研报源和舆情源做增量检查。一旦发现新内容，它先做基础解析，再结合历史观点判断这件事有没有增量信息。比如某家电公司发布了月度销售数据，Agent会自动和上月对比，提取异常项，生成一条“数据变化摘要”推送到我的工作台。

这个环节最适合先自动化，因为它没有复杂的价值判断，信息是否新增、对比后数值是否异常，这些都是可校验的。而且一旦跑通，它能解放掉我每天至少一小时的无脑刷新时间。更关键的是，监控任务里出现错误时，影响范围非常有限，最多是一条推送判断不准确，人工一眼就能纠正，不会造成严重后果。

2.2 环节二：结构化观点核验

第二个环节是观点核验。过去我读完一份卖方研报，要手动把它提出的逻辑链条和数据源对照一遍，这个过程又慢又枯燥。现在Agent会先把研报里的观点拆成断言，比如“公司A在细分赛道的市占率持续提升”，然后基于数据管线里的财务数据和产业数据做一致性检查。如果研报给出的支持证据与数据库中的数值冲突，Agent会明确标出“矛盾”，而不是假装没看到。

这里有一个从实操中总结出来的关键细节：给Agent设计核验任务时，必须要求它把每个判断行号和证据行号同时输出。也就是说，AI不能只说“市占率提升”，还要指出这个结论对应原始文本的哪个章节、支撑数据来自哪一行。一旦这样要求，模型的胡诌空间就会被压缩到很小，因为行号对不上时，人工审核一眼就能发现问题。

2.3 环节三：会议纪要与调研纪要的结构化

第三个环节是会议纪要与调研纪要的结构化处理。这个场景比公告更复杂，因为口语内容里大量省略主语，像“我们明年会继续加大这块投入”，没有上下文时根本不知道“这块”指什么。Agent在处理时，需要先结合这家公司最近的产品和财报口径，把指代消解成具体的业务线，再提取口径变化、资本开支计划和绩效目标。

最开始我让Agent只做关键词抽取，效果很差，因为它分不清哪一个数字是新增信息、哪一个只是复述历史内容。后来我改成两步走：第一步让Agent总结原文里所有“变化点”，第二步再让Agent基于历史版本找“新增变化”，把两步结果做差集，才真正把会议纪要的价值释放出来。这一步跑通之后，我的深度研究效率提升非常明显，但我仍然要说，它只是辅助，不是决策替代。

这三个环节之所以先做，是因为它们都满足同一标准：输入输出边界清楚，错误能被看见，结果可以验证。凡是满足这个标准的任务，才值得谈自主。那些判断链条长、主观因素多的环节，我到现在仍然保持更高程度的人工参与。

3. 核心引擎的搭建：任务规划、工具调用与记忆管理

3.1 为什么选择Agent而不是一条Prompt链

把Agent接到投研场景之后，我最常被问的问题就是：为什么不写一个超长的Prompt链，按步骤调用模型，非要用Agent架构？答案很简单：真实投研任务的路径不是固定的。同样是“分析一家公司”，有的任务需要先查财务数据，有的需要先读产业数据，有的还需要横向对比几家同行。如果用固定Prompt链，每加一种新任务类型就要重写一套流程，维护成本高得吓人。

Agent的核心优势是能在运行中动态规划。系统给Agent一个目标，它自己决定先调用哪个工具、再推理哪个结论，遇到证据不足时还会主动扩大搜索范围。我在这套系统里实际上采用的是ReAct风格的循环：模型先思考当前任务需要什么信息，再调用对应工具，观察结果后决定下一步，直到任务完成。这样既保留了步骤的可追溯性，又避免了为每种任务单独写流程。

为了便于理解，我把这套循环简化成下面的伪代码：

class ResearchAgent: def __init__(self, llm, tools, memory): self.llm = llm self.tools = {tool.name: tool for tool in tools} self.memory = memory def run(self, task): plan = self.llm.split_task(task) for step in plan: result = self.execute_step(step) self.memory.save(result) return self.memory.collect()

实际工程里当然比这复杂，但核心思想是一样的：Agent不是一次性生成答案，而是把一个大任务切成多步，每步都带着前面步骤的结论往下走。

3.2 工具集的设计与选择

工具集是整个Agent能力的边界。我的工具集最初有十几个接口，后来砍到了六个：公告检索、财务数据查询、网页搜索、文档解析、数值计算、向量记忆检索。因为实践下来发现，模型做工具选择的准确性会随着工具数量增加而下降。给模型太多选择，它反而容易在无关工具上犯错，尤其在复杂研究场景里，一个选择错误就可能带偏整个推理方向。

每个工具的定义必须足够清晰。我给工具写了两部分内容：第一部分是功能描述，用来让模型判断“什么情况下该用它”；第二部分是JSON Schema，把参数限制得尽可能严。比如财务数据查询工具的输入参数必须包含公司ID和指标名，不允许模型自由发挥传一个模糊的“最近数据”。这样做的代价是灵活性降低，但换来的是调用成功率大幅提升，整体收益非常高。

3.3 记忆与上下文管理

投研系统对记忆的需求非常特殊。研究一家公司往往要持续几周甚至几个月，Agent如果每次分析都只看当前材料，就会丢失历史判断。我在系统里做了三层记忆：短期记忆是当前分析任务的中间结果，存内存里；长期记忆是历史研究报告和关键结论，放进向量数据库，按公司和主题建索引；结构化记忆是公司的基础数据、财务指标时间序列、以及已经核验过的事实，放在结构化数据库里。

这样的分层带来的直接好处是上下文窗口不再被历史材料占满。刚开始做的时候我图省事，把所有相关材料都塞进上下文，结果token消耗巨大，而且长文本把模型注意力稀释了，输出质量反而变差。后来改成“先检索后生成”的RAG模式，每次只把最相关的一段材料放进上下文，模型输出明显更稳定。这个现象其实不难理解：让模型在五千个非关键事实里找一个关键事实，和在五十个高相关事实里做判断，难度完全不在一个量级。

3.4 多Agent协作还是单Agent

关于架构，我还犹豫过要不要上多Agent。市面上很多宣传把多Agent说得无所不能，但实际落地时，多个Agent之间的通信协议和状态同步会带来巨大复杂度。我的最终方案是折中：主体是一个研究Agent，负责规划、检索和推理；另外挂了两个只做专门任务的轻量Agent，一个是事实验证Agent，专门对研究Agent的结论做反向证伪，一个是语言改写Agent，负责把零散的推理结果整理成结构化报告。

这种组合既避免了多Agent网状协作的麻烦，又保留了“生成和验证分离”的好处。核心原因在于，让同一个模型既负责推导结论又负责检查自己，容易陷入自我确认偏差；单独抽一个验证Agent出来做“找茬”，效果会好很多。如果你也想做垂直领域的Agent，我建议不要一上来就铺很多角色，先把“一个主Agent加一个验证Agent”这个最小组合跑稳，再考虑扩展。

4. 数据质量与幻觉问题：我在评测和测试中踩过的坑

4.1 AI测试不是问它好不好，而是给用例集打分

很多刚开始做AI应用开发的人，测试方式是把几个问题扔给模型，肉眼看一下回答得怎么样。这种测试在投研场景远远不够，因为投研输出不仅要求“看起来流畅”，还要求每一个数字、每一个结论都有据可查。我专门做了一套评测集，规模不大，五十条左右，但每一条都包含四部分：任务类型、输入材料、期望输出结构、关键事实标签。跑一次大概半小时，但对模型选型和版本升级非常关键。

评测指标我用了五个：事实准确率、引用完整率、格式合规率、单任务延迟和单任务成本。重点说前两个。事实准确率是指Agent输出里和原始材料一致的内容占比，引用完整率是指有具体出处来源的断言占所有断言的比例。这两个指标加起来，基本能反映一个Agent在投研场景里有没有乱说。

这里想强调一句：评测集最怕一次性建完就不管。模型在升级，工具在变，数据源也在变，评测集必须跟着迭代。我每个月会往里面加几条最近半年真实踩过坑的case，让测试集始终贴近实际使用场景。

4.2 Agent自己要会交叉验证

评测集只是最后一道防线，真正降低幻觉的是系统内部的交叉验证机制。做法是：每次Agent生成一个重要结论，都必须附带证据链；证据链要么来自结构化数据库，要么来自某篇源文档的某个段落。如果某个结论找不到证据链接，它在最终报告里的展示权重会被系统自动降低。

更激进一点，我还会让验证Agent主动反向提问。比如研究Agent说“该公司的产能利用率明显提升”，验证Agent会立刻去数据表里查产能数据和产量数据，如果增幅不匹配，就会给这个结论打上“存疑”标签。这一步让系统不只是在总结材料，而是在做一定程度的事实审核，对投研场景来说很有价值。

4.3 幻觉的源头往往不在模型，而在数据管线

这是我最想提醒后来人的一点。很多团队把幻觉问题全归咎于大模型，拼命调Prompt和温度参数，却忽略了数据管线里的低级错误。有一次，系统把一份财报PDF里错位的表格数据当成真实业绩，生成的分析结论完全反了方向。排查之后发现，问题是PDF转文本时，两列数字被交换了位置。这样的错误，再强的模型也救不回来。

所以我在数据管线的每一层都加了质量检查：解析之后做schema校验，抽取之后做实体对齐，入库之前做数值格式校验。一旦发现异常，宁可跳过这一份材料，也不能把脏数据喂给Agent。这条原则非常朴素，但无数次救我于水火。如果你正在做其他垂直领域，比如医疗、法律或工业文档，这条原则同样适用。

4.4 置信度和来源追溯是底线

最后是置信度机制。AI生成的研究输出不能是“全对”或者“全错”的二值状态，我要求每个核心断言都带一个置信度，范围是0到1，并且模型必须给出给低分的原因。比如“供应链数据显示原材料价格回落，因此该公司下季度毛利有望改善”，置信度如果只有0.6，那Agent必须说明低分是因为原材料价格回落尚未反映在历史财务数据里，属于外推判断。

来源追溯则是让用户能顺着证据链回看。我在系统里给每份源文档算了一个内容指纹，Agent引用的每一个事实都记录来源ID和段落位置。这样做除了提升透明度，还有一个实际好处：当新的数据发布后，系统能快速识别哪些历史结论已经过时，主动推送给用户，而不是装作无事发生。这个机制对长期跟踪同一批标的特别重要。

5. 从日级任务到分钟级响应：部署层与模型路由的工程实践

5.1 任务调度：不是所有任务都需要实时

系统上线之后，我第一版设计把所有Agent任务都做成实时触发，结果资源消耗很快就失控了。后来我按业务价值重新设计了调度策略。每天开盘前的晨报、每周的行业复盘、以及季度财报季的集中事件提示，它们的时效性要求完全不同，不应该共用一套调度逻辑。

我用一个简单的任务优先级表来管理：

优先级越高的任务用越轻量的模型和越短的上下文，优先级低的任务才允许调用复杂模型做深度分析。调度层重新设计之后，整体成本能省一半以上。这其实是我对AI基础设施最朴素的理解：不是堆GPU，而是先把资源按真实需求分配好。

5.2 模型路由与成本控制

投研任务里其实大量步骤并不需要最强的大模型。比如抽取公告里的发布日期、解析财务表格、做文本分类，这些任务用轻量级模型就够了。我按任务难度把模型分成了三档：第一档用于实体抽取和格式转换，响应要快、成本要低；第二档用于信息摘要和逻辑推理，需要中等水平；第三档才用于观点生成和复杂推理，使用最强模型。

这个路由策略帮我控制住了成本。同一个研究流程，如果全程使用最强模型，成本是路由后的差不多四倍，而综合质量并没有显著提升。我的经验是：不要因为大模型调用方便就不假思索地滥用，越是大规模任务流，越要在模型选择上花时间。顺便说一句，模型路由不只是省钱，它还能降低延迟，让轻量任务做到秒级响应。

5.3 部署后的可观测性

Agent系统的最大工程风险是不可观测。普通Web接口调用一次返回一次，出了问题看日志就好；但Agent会在一次任务里做多次推理、多次工具调用，链路长且状态复杂，一旦出问题很难定位。所以我在部署阶段，坚持给每一轮推理和工具调用都打日志：模型输入的摘要、工具名称、返回值长度、耗时、token数、是否触发重试。

这部分的投入在初期显得很繁琐，但后来几次线上问题，都是靠这些日志才快速定位。比如有一次系统持续生成同一公司的大量重复纪要，日志显示是向量检索的结果排序没加时间衰减，导致旧材料一直排在前面。没有可观测性，这种问题几乎不可能被发现。如果你在做Agent类的应用，请务必从第一天起就把链路日志当成核心功能来做，而不是事后补救。

5.4 模型部署迭代的策略

在模型部署和迭代方面，我不追求每出一款新模型就立刻切换。更稳妥的策略是并行运行：把要评测的模型和当前线上模型接到同一套评测集上，跑一周对比，看的不是某个单点案例，而是整体指标分布。这听起来很笨，但能避免不少被单一样例误导的冲动。

此外，所有上游模型接口都要做一层适配层。这样换模型时，下游数据结构和业务代码不需要大改。经历过一次模型供应商接口变化导致全线报错之后，我极度推荐把模型调用封装成统一接口，这属于AI工程实践里最容易被忽略却最重要的一点。系统稳定运行的时间越长，你越会发现，这种基础设施层面的约束比某个独门Prompt值钱得多。

6. 自主投研的安全带：评审、留痕与人为最终决策

6.1 自主程度分级：我最终停在L2

聊完工程，必须聊边界。很多朋友听完我的分享，第一反应是问：那它能不能完全替代研究员？我的回答是，我把它分成了四级：L0是完全人工，L1是AI辅助检索和摘要，L2是AI生成完整初稿加人工审核，L3是完全无人参与的自动决策。我自己目前部署在L2，L3只用在信息预警和环境变化的初筛上。

之所以不轻易上L3，是因为投研场景里最终结论的容错空间太窄。AI擅长从大量材料里提取和追踪信息，但判断还需要考虑市场情绪、资金面、事件冲击等很难结构化的因素，这些东西现阶段让模型负全责，我不放心。与其追求完全自动化，不如承认人的判断仍然是闭环里不可省的一环。

6.2 评审流程与留痕机制

在L2模式下，系统输出的任何一份研究初稿，都带两个附加属性：模型版本号和材料快照。模型版本号保证如果结论质量波动，可以回溯到具体是哪一版模型造成的；材料快照则保证即使源网站后续修改或删除内容，审核者看到的始终是Agent当时读到的原始版本。

我还在工作流里加了一个“建议动作”字段，Agent可以对每条风险事件给出“继续观察、需要复核、建议关注”之类的标签，但不会输出“买入或卖出”这样的交易指令。真正的决策，必须由人在充分知情的情况下做出。这套机制不是为了限制AI，而是为了让它能在一个更安全的环境里被长期使用。

6.3 人的工作不是重复AI，而是发现AI发现不了的问题

当AI把信息收集和结构化工作做得越来越好后，人的角色会自然发生变化。以前我大部分时间花在找材料和核对数字上，现在这些工作Agent十分钟就能完成，我把重心转向了提出更关键的假设、评估被忽视的风险、以及处理AI还没法理解的模糊信息。

举个例子，Agent能从公告里准确提取“公司计划三年内实现产能翻倍”，但它很难判断管理层这句话背后是基于真实订单需求还是行业惯性扩张。这类问题的答案藏在产业关系和经营细节里，需要的是行业经验，不是信息处理能力。所以在我看来，AI自主驱动的投研，最终形态不是替代研究员，而是把研究员从信息苦力中解放出来，去做真正需要人的判断力的工作。

每次有人问我这个系统做到什么程度，我通常会说：它还不能替我承担决策责任，但它已经帮我找回了大量被信息淹没的时间。后续我打算继续做两件事：一是把跟踪频率从日级提升到更细粒度，二是让Agent在跨公司横向对比上更聪明。这些都是工程和算法问题，可以做得很稳。如果有人正在做类似的垂直领域Agent，希望这篇复盘能让你少走几段弯路。