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所有中间数据都带上这个 idAgent 之间通过 id 来隔离。这样即使同时跑多个公司的研究也不会串数据。4. 数据层决定这套框架能不能用的隐形地基4.1 财务数据的结构化是最大的工作量很多人低估了这一步的难度。以为找个财经数据接口拉数据就完事了实际上公开接口的数据质量参差不齐字段定义不统一历史数据经常有缺失和修正。而价值投资恰恰最看重历史数据的连续性和准确性。ai-berkshire 这类项目通常需要自己维护一套数据清洗流程。核心工作包括统一字段命名不同数据源的营业收入可能叫 revenue、operating_income、total_revenue、处理缺失值是补零、插值还是标记为不可用、处理数据修正财报重述后要保留版本记录、计算衍生指标各种比率、增长率、同比环比。这块工作没有捷径但可以工程化。我的建议是把数据清洗做成独立的 pipeline每个步骤有明确的输入输出和校验规则。比如计算 ROE这一步输入是净利润和净资产输出是 ROE 序列校验规则是ROE 不应超过 100% 除非净资产为负。这种校验能在早期发现数据问题避免错误数据一路传到分析报告里。4.2 非结构化信息的处理策略财报文本、公告、新闻这些非结构化信息处理策略和财务数据完全不同。财务数据追求精确非结构化信息追求信号提取。具体做法是先用规则做粗筛再用模型做精读。比如从年报里提取管理层讨论与分析章节可以用章节标题做定位从新闻里筛选和公司相关的可以用关键词匹配加实体识别。粗筛之后再让 Agent 对筛选出的内容做深度阅读提取关键信息。这里有个经验不要让 Agent 读整份年报。一份年报几百页Agent 读下来既慢又容易丢失重点。正确做法是先定位到关键章节MDA、风险因素、财务报表附注再让 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 能立刻给出解释和背景。我在实际使用中的体会是这类工具的价值会随着你对它的理解而增长。刚开始你可能只是用它来省时间用久了你会发现它其实在帮你建立一套更系统的思考方式。工具本身不会让你变成更好的投资者但它能让你把精力集中在真正需要判断的地方而不是消耗在资料整理上。最后分享一个实用建议如果你打算自己搭一套类似的框架不要追求一步到位。先用最简单的流程跑通一个环节比如只做财务数据整理验证效果后再逐步加上分析、估值、报告生成。每加一个环节都要确保前一个环节的输出质量可靠。投资研究这件事宁可慢一点也要保证每个结论都站得住脚。