企业官网建设流程全解析

1. 从"AI炒股"到"AI价值投资"：这个项目到底在解决什么问题

第一次看到 ai-berkshire 这个名字，我下意识以为又是一个"让大模型帮我选股"的玩具项目。毕竟这两年打着 AI 投资旗号的东西太多了，绝大多数本质上是把行情数据喂给模型，让它输出一个"买/卖"的结论，然后拿历史数据回测出一张漂亮的收益曲线。这类东西的问题在于：它把投资简化成了一个预测问题，而真正的价值投资从来不是预测股价，而是判断一家企业的内在价值与市场价格之间的差距。

ai-berkshire 走的是另一条路。它把巴菲特、芒格那一套价值投资的分析框架——护城河、管理层、财务健康度、估值区间、能力圈——拆解成结构化的研究流程，然后用 AI Agent 去执行这个流程中的信息收集、数据整理、逻辑推演和报告生成环节。换句话说，它不是让 AI 替你拍板买什么，而是让 AI 帮你把一家公司研究透，把研究员从繁琐的资料搜集和格式化整理中解放出来，把精力留给最终的判断。

这个定位非常关键。它决定了整个项目的技术架构不是"数据管道 + 预测模型"，而是"研究框架 + 多 Agent 协作 + 可追溯的分析链路"。关键词里出现的 Claude Code、Codex、AI Agent、开源，其实都指向同一个技术底座：用编码型 AI Agent 作为执行引擎，把投资研究这个原本高度依赖个人经验的工作，变成一套可复用、可审计、可迭代的流程。

适合读这篇内容的人有三类。第一类是对 AI Agent 落地感兴趣的技术人，想看看 Agent 在垂直领域到底怎么设计才有实用价值，而不是停留在 demo 阶段。第二类是有一定投资基础、想用工具提升研究效率的个人投资者，你需要理解这套框架的边界在哪里。第三类是正在做垂直领域 AI 产品的开发者，ai-berkshire 的架构思路可以直接迁移到法律、医疗、咨询等同样依赖"结构化研究流程"的领域。

我接下来会从它的核心设计逻辑讲起，然后拆解 Agent 编排、数据层、提示词工程这几个关键模块，再聊聊实际跑起来会遇到哪些坑，最后说说这类项目真正的价值边界在哪。全程按我自己的理解和使用经验来讲，不堆术语，该给配置给配置，该说原理说原理。

2. 价值投资框架怎么变成可执行的 Agent 流程

2.1 为什么不能用一个"万能提示词"搞定

很多人做 AI 投资工具的第一反应是写一个超长的提示词，把价值投资的所有要点塞进去，然后让模型一次性输出分析报告。我早期也这么干过，结论是：能跑，但没法用。

问题出在三个地方。第一，上下文长度和注意力分配的矛盾。一份完整的公司研究涉及财报三张表、多年数据、行业对比、管理层背景、竞争格局，信息量极大。你把所有东西塞进一个 prompt，模型对中间部分的注意力会明显衰减，经常出现"前面分析得很细，后面估值部分开始胡说"的情况。第二，无法追溯。一次性输出的报告，你没法知道哪个结论是基于哪份数据推出来的，出了问题只能整体重来。第三，无法复用和迭代。你想调整估值方法，得把整个 prompt 重写一遍。

ai-berkshire 的做法是把研究流程拆成多个阶段，每个阶段由独立的 Agent 或 Agent 组负责，阶段之间有明确的数据契约。这其实就是软件工程里"关注点分离"的思路搬到投资研究上。每个 Agent 只干一件事，干完把结构化结果传给下一个环节。这样做的好处是每个环节都可以单独调试、单独替换、单独验证。

2.2 研究流程的阶段拆解

按照价值投资的经典逻辑，整个流程大致分成这么几个阶段，我结合项目里的 Agent 设计来说。

信息采集阶段。这个阶段负责把分散的数据源汇总起来：财务报表、公告、行业数据、新闻、管理层公开讲话。这里的关键不是"能不能抓到"，而是"抓到的数据怎么结构化"。财报是 PDF，公告是 HTML，新闻是自然语言，如果直接丢给下游 Agent，下游还得重新解析一遍，效率极低。所以这个阶段的核心产出是一套统一的数据 schema，把不同来源的信息映射到相同的字段上。

基本面分析阶段。这是价值投资的核心。项目里通常会拆成几个子 Agent：盈利能力分析、现金流质量分析、资产负债结构分析、成长性分析。每个子 Agent 拿到的输入是结构化的财务数据，输出是对应的分析结论和关键指标。这里有个设计细节很重要：子 Agent 之间不直接通信，而是各自把结果写到共享的分析上下文里，由汇总 Agent 统一读取。这样避免了 Agent 之间互相干扰，也方便并行执行。

护城河与定性分析阶段。财务数据能告诉你"过去怎么样"，但护城河、管理层能力、行业地位这些东西得靠定性分析。这个阶段 Agent 要做的是从大量文本信息里提取关键信号：管理层是否坦诚（比如年报里对问题的描述是否具体）、竞争优势是否可持续（比如毛利率能否长期维持）、行业格局是否在恶化。这块是最考验提示词设计的地方，因为定性判断很容易变成"正确的废话"。

估值阶段。基于前面的分析，用 DCF、相对估值等方法给出估值区间。这里 Agent 的职责不是"算出一个精确的数字"，而是"给出一个合理的区间和背后的假设"。价值投资里估值的意义在于判断"当前价格是否提供了足够的安全边际"，而不是精确预测内在价值。

报告生成阶段。把前面所有阶段的结果整合成一份可读的研究报告，同时保留每个结论的数据来源和推理链路。

2.3 阶段之间的数据契约设计

这是我觉得整个项目里最值得学习的地方。Agent 之间传递的不是自然语言，而是结构化的 JSON。每个阶段有明确的输入 schema 和输出 schema，字段类型、必填项、取值范围都定义清楚。

举个具体的例子，基本面分析 Agent 的输出大概长这样：

{ "company_id": "XXXXXX", "analysis_period": "2020-2024", "profitability": { "gross_margin_trend": [0.42, 0.41, 0.43, 0.44, 0.45], "net_margin_trend": [0.18, 0.17, 0.19, 0.20, 0.21], "roe_trend": [0.15, 0.14, 0.16, 0.17, 0.18], "conclusion": "毛利率和净利率稳步提升，ROE 持续改善，盈利能力向好" }, "cash_flow_quality": { "ocf_to_net_income": [1.1, 1.05, 1.2, 1.15, 1.18], "conclusion": "经营现金流持续高于净利润，盈利质量高" }, "confidence": 0.85, "data_sources": ["annual_report_2024", "annual_report_2023"] }

这种设计的好处是，下游 Agent 不需要理解自然语言，直接读字段就行。而且confidence字段让整个系统有了"自我评估"的能力——如果某个环节置信度低，汇总阶段可以标记出来提醒人工复核。data_sources字段则保证了可追溯性。

提示：设计数据契约时，一定要给每个结论字段配一个confidence和data_sources。这两个字段在后期调试和人工复核时能省掉大量时间。我见过太多 Agent 项目因为缺少这两个字段，出了问题只能从头查。

3. Agent 编排：Claude Code 和 Codex 在这里扮演什么角色

3.1 为什么选编码型 Agent 而不是通用对话模型

关键词里 Claude Code 和 Codex 出现频率很高，这不是偶然。ai-berkshire 这类项目选择编码型 Agent 作为执行引擎，背后有很实际的原因。

通用对话模型的问题是它只能"说"，不能"做"。你让它分析一家公司，它只能基于训练数据里的记忆来回答，没法主动去读你本地的财报文件、没法执行计算、没法调用外部数据接口。而编码型 Agent 的核心能力是工具调用和文件操作——它能读文件、写文件、执行代码、调用 API。这恰好是投资研究需要的：读财报、算指标、查数据、生成报告。

Claude Code 在这类项目里的典型用法是作为"主控 Agent"，负责协调整个研究流程。它读取配置文件，按顺序调用各个子 Agent，处理阶段之间的数据传递，最后汇总生成报告。Codex 则更多用在需要代码执行的环节，比如财务指标计算、估值模型运算。两者配合的方式通常是：Claude Code 负责流程编排和文本分析，Codex 负责数值计算和数据处理。

3.2 本地模型接入的实际考量

热词里有一条"claude code 调用 lmstudio 的本地模型"，这个需求在投资研究场景里特别真实。原因很简单：财务数据是敏感的，很多人不愿意把持仓和研究成果传到云端。用 LM Studio 跑本地模型，配合 Claude Code 的调用能力，就能在完全本地的环境下完成研究。

实际配置上，LM Studio 启动本地服务后，会暴露一个兼容 OpenAI 格式的接口。Claude Code 通过配置环境变量指向这个本地地址即可。这里有个坑要注意：本地模型的上下文窗口通常比云端模型小，而投资研究需要的上下文又特别大。解决办法是把长文档做分块处理，每个子 Agent 只处理自己需要的那部分，而不是把整份年报塞进去。

另一个坑是本地模型的指令遵循能力。云端大模型对复杂 JSON schema 的输出格式遵循得比较好，本地小模型经常跑偏。我的经验是在提示词里把输出格式用示例写死，并且在解析端做容错——如果 JSON 解析失败，自动重试一次，重试时把上次的错误输出作为负面示例带上。

3.3 多 Agent 并发的处理

热词里"ai agent 怎么扛并发"这个问题，在 ai-berkshire 场景下尤其突出。一份完整研究涉及多个子 Agent，如果串行执行，一份报告可能要跑十几分钟。并行化是必然选择。

但并行化带来两个问题。第一是资源竞争。多个 Agent 同时调用模型接口，容易触发速率限制。解决办法是加一个请求队列，控制并发数，同时做好失败重试和退避。第二是结果一致性。多个 Agent 并行分析同一家公司的不同维度，如果它们读到的数据版本不一致，结论就会打架。所以数据层必须做版本控制，所有 Agent 在同一个研究任务里读到的必须是同一份数据快照。

我在实际项目里的做法是给每个研究任务分配一个task_id，所有中间数据都带上这个 id，Agent 之间通过 id 来隔离。这样即使同时跑多个公司的研究，也不会串数据。

4. 数据层：决定这套框架能不能用的隐形地基

4.1 财务数据的结构化是最大的工作量

很多人低估了这一步的难度。以为找个财经数据接口拉数据就完事了，实际上公开接口的数据质量参差不齐，字段定义不统一，历史数据经常有缺失和修正。而价值投资恰恰最看重历史数据的连续性和准确性。

ai-berkshire 这类项目通常需要自己维护一套数据清洗流程。核心工作包括：统一字段命名（不同数据源的"营业收入"可能叫 revenue、operating_income、total_revenue）、处理缺失值（是补零、插值还是标记为不可用）、处理数据修正（财报重述后要保留版本记录）、计算衍生指标（各种比率、增长率、同比环比）。

这块工作没有捷径，但可以工程化。我的建议是把数据清洗做成独立的 pipeline，每个步骤有明确的输入输出和校验规则。比如"计算 ROE"这一步，输入是净利润和净资产，输出是 ROE 序列，校验规则是"ROE 不应超过 100% 除非净资产为负"。这种校验能在早期发现数据问题，避免错误数据一路传到分析报告里。

4.2 非结构化信息的处理策略

财报文本、公告、新闻这些非结构化信息，处理策略和财务数据完全不同。财务数据追求精确，非结构化信息追求"信号提取"。

具体做法是先用规则做粗筛，再用模型做精读。比如从年报里提取"管理层讨论与分析"章节，可以用章节标题做定位；从新闻里筛选和公司相关的，可以用关键词匹配加实体识别。粗筛之后，再让 Agent 对筛选出的内容做深度阅读，提取关键信息。

这里有个经验：不要让 Agent 读整份年报。一份年报几百页，Agent 读下来既慢又容易丢失重点。正确做法是先定位到关键章节（MD&A、风险因素、财务报表附注），再让 Agent 精读这些章节。这样既节省 token，又提高分析质量。

4.3 数据版本与可追溯性

投资研究有个特点：结论会随着新信息的出现而变化。今天基于最新财报得出的结论，下个季度财报出来后可能就不成立了。所以数据层必须支持版本管理，每次研究都要记录用的是哪个版本的数据。

ai-berkshire 的做法是给每个数据快照打时间戳和版本号，研究报告里明确标注"本报告基于 XXXX 年 XX 月 XX 日的数据"。这样当结论需要复核时，能准确还原当时的分析依据。这个设计看起来简单，但在实际使用中价值极大——它让整个研究过程变得可审计。

5. 提示词工程：让 Agent 输出"有观点"而不是"正确的废话"

5.1 价值投资分析最怕什么

最怕输出一堆"公司经营稳健、行业前景良好、估值处于合理区间"这种话。这种话放在任何一家公司上都成立，等于没说。好的投资分析必须有明确的判断：这家公司的护城河是在变宽还是变窄？当前价格是提供了安全边际还是已经透支了预期？

让 Agent 输出有观点的分析，关键在于提示词设计。我的经验是三个原则。

第一，强制给出判断和依据。提示词里明确要求"每个结论必须附带至少两个数据支撑或事实依据"，不允许出现没有依据的判断。第二，强制做对比。孤立地看一家公司的毛利率是 40%，你没法判断这是好是坏。必须和它的历史比、和同行比、和行业平均比。第三，强制指出风险。要求 Agent 在给出正面结论的同时，必须列出至少一个反面证据或潜在风险。

5.2 提示词的分层设计

ai-berkshire 的提示词不是一个大字符串，而是分层的。最底层是角色定义和通用规则，中间层是具体任务指令，最上层是输出格式要求。这种分层设计让提示词可以复用——不同公司的分析任务共享底层规则，只需要替换中间层的具体数据。

举个具体的分层示例。底层规则可能包括"你是一名严谨的财务分析师，所有结论必须有数据支撑，不确定的地方要明确标注"。中间层是"请分析以下公司的盈利能力，重点关注毛利率、净利率、ROE 的五年趋势"。上层是"输出 JSON 格式，字段包括 xxx"。

这种设计还有个好处是便于 A/B 测试。你想优化分析质量，只需要改底层规则，所有任务都会受益，不用一个个改。

5.3 处理模型幻觉的实战方法

投资研究里模型幻觉的后果很严重——编造一个不存在的财务数据，可能导致完全错误的结论。处理幻觉有几个实用方法。

一是数据引用强制化。要求 Agent 在输出每个数据点时，必须标注来源（哪份财报、哪个字段）。如果模型编造数据，往往标注不出来源，或者来源和内容对不上。二是交叉验证。关键数据用两个独立来源核对，不一致就标记出来人工确认。三是数值计算交给代码。让 Agent 做加减乘除是自找麻烦，所有计算都通过代码执行，Agent 只负责调用和解读结果。

注意：不要相信 Agent 自己报告的数据。我踩过的坑是 Agent 在报告里写"净利润同比增长 15%"，实际数据算出来是 12%。原因是它把两个不同口径的净利润混用了。后来我把所有计算都改成代码执行，Agent 只负责从计算结果里读取，这类问题就消失了。

6. 实际跑起来会遇到的那些坑

6.1 环境配置阶段的常见问题

Claude Code 和 Codex 的安装配置本身不复杂，但在实际项目里经常卡在几个地方。一是版本兼容性，不同版本的 Agent 工具对配置文件格式的要求不一样，升级后旧配置可能失效。二是权限问题，Agent 需要读写本地文件、执行代码，如果权限没配好，会在运行到一半时报错。三是网络和接口配置，如果用本地模型，要确保接口地址、端口、模型名称都对得上。

我的建议是先把最小可运行环境跑通——用一个最简单的任务（比如读一个文件、输出一句话）验证 Agent 能正常工作，再逐步加上复杂功能。不要一上来就配全套，出了问题很难定位。

6.2 Agent 执行中断的排查思路

Agent 执行长任务时中断是家常便饭。排查思路是分层定位：先看是模型调用失败还是工具调用失败，再看是输入问题还是输出解析问题。

模型调用失败通常是网络或速率限制，看错误码就能判断。工具调用失败往往是参数格式不对，比如让 Agent 读一个不存在的文件路径。输出解析失败最常见，模型输出的 JSON 格式不对，解析器报错。这种情况我的处理方式是：记录原始输出，分析失败模式，然后在提示词里针对性加强格式约束。

6.3 分析质量的波动问题

同一个任务跑两次，结果质量可能差很多。这是大模型的固有特性，没法完全消除，但可以缓解。方法一是降低温度参数，让输出更稳定。方法二是关键任务多次执行取交集，比如让 Agent 分析三次，只保留三次都出现的结论。方法三是人工抽检，定期检查输出质量，发现系统性偏差就调整提示词。

6.4 成本控制

Agent 跑投资研究，token 消耗不小。一份完整报告可能消耗几十万 token。控制成本的关键是减少无效调用。具体做法包括：缓存中间结果，同样的数据不重复分析；精简上下文，只给 Agent 需要的信息；用便宜模型做粗筛，贵模型做精读。

7. 这套框架的边界与真实价值

7.1 它能做什么，不能做什么

ai-berkshire 能大幅提升研究效率，把原本需要几天的资料搜集和整理压缩到几十分钟。它能保证分析流程的一致性，不会因为研究员状态好坏而遗漏关键维度。它能做到可追溯，每个结论都能找到数据来源。

但它不能替代判断。价值投资里最难的部分——判断管理层是否可信、判断行业变化是短期波动还是长期趋势、判断当前价格是否提供了足够安全边际——这些需要人的经验和直觉。Agent 能做的是把事实摆清楚，把逻辑理顺畅，但最终的决策必须由人来做。

7.2 对个人投资者的实际意义

对个人投资者来说，这套框架最大的价值不是"帮你选股"，而是"帮你建立研究纪律"。很多人做投资是凭感觉，看到新闻就买，听到消息就卖。用这套框架，你会被迫按流程走一遍：这家公司靠什么赚钱、财务是否健康、估值是否合理、风险在哪里。走完这个流程，你的决策质量会有明显提升，哪怕最终的买卖决定还是你自己做的。

7.3 这类项目的演进方向

从技术角度看，ai-berkshire 这类项目的演进方向大概是三个。一是数据源的扩展，从公开财报扩展到更多维度的信息。二是分析框架的细化，针对不同行业设计不同的分析模板。三是人机协作的深化，Agent 不只是输出报告，还能在人的研究过程中提供实时辅助，比如你读财报时遇到不懂的地方，Agent 能立刻给出解释和背景。

我在实际使用中的体会是，这类工具的价值会随着你对它的理解而增长。刚开始你可能只是用它来省时间，用久了你会发现它其实在帮你建立一套更系统的思考方式。工具本身不会让你变成更好的投资者，但它能让你把精力集中在真正需要判断的地方，而不是消耗在资料整理上。

最后分享一个实用建议：如果你打算自己搭一套类似的框架，不要追求一步到位。先用最简单的流程跑通一个环节，比如只做财务数据整理，验证效果后再逐步加上分析、估值、报告生成。每加一个环节，都要确保前一个环节的输出质量可靠。投资研究这件事，宁可慢一点，也要保证每个结论都站得住脚。