如果说过去两年“AI投研”的故事大多停留在概念阶段Claude Code的出现算是把这个方向真正往前推了一大步。因为Claude Code证明了agent不只能聊天还能像一个真正的开发者那样读代码、改文件、跑测试、修bug独立完成一整条工程链路。Panda AI创始人李昱琦在交流时跟我说得很直白他的目标就是把Claude Code这套“agentic”模式搬到金融投研领域做一个能自动分析数据、生成研报、持续跟踪市场的“投研Claude Code”底层工程框架选择了字节开源的Harness。这篇文章我会从投研的真实痛点讲起拆解Harness的设计思路结合我实际搭建投研agent时踩过的坑把整个过程的经验沉淀下来。不管你是AI创业者、金融科技从业者还是正在摸索agent开发的工程师这篇应该都能给你一些参考。1. 投研的“三座大山”为什么传统分析师忙不过来很多不了解金融行业的人以为分析师的工作就是坐在电脑前看看K线、写写观点。真正干过这行或者跟卖方打过交道的都清楚投研是一个极度消耗人力的信息密集型工作。李昱琦在分享里反复提到一个词“信息差”。投研赚钱的逻辑说到底是信息差——比市场更早、更准、更深地理解一家公司、一个行业。但信息差的前提是你得有足够的带宽去处理海量信息。一个覆盖TMT行业的分析师每天要面对多少东西几百条行业新闻、几十篇券商研报、上市公司公告、数据库里的财务数据、微信群里转发的行业纪要还有各种路演和专家访谈。别说深度分析了光是把这些材料过一遍就要花掉大半天时间。1.1 信息过载分析师的一天怎么被消耗这里说个直观的数字一个中型研究所每天收进来的各类研报、公告、新闻摘要少说几千条。如果靠人工筛选一个分析师一天的有效工作时间可能只有四五个小时其余全被信息收集和过滤消耗掉了。而且很多关键信息藏在PDF里、藏在录音里、藏在图片里机器搜不到人工翻又慢。以前行业里的常规操作是招一堆实习生做“摘录”把重要段落摘出来、整理成表格。这个活儿不是不能干但很耗人力而且实习生水平参差不齐漏掉关键信息是常有的事。这正是大模型最擅长补位的环节——长文本理解、关键信息抽取、结构化输出说白了就是LLM的主场。我在自己的项目里也验证过让模型去读一份五十页的招股说明书把核心财务数据抽取到表格里准确率相当高而且耗时只有人工的十分之一。1.2 数据孤岛与重复劳动同一个数字算三遍投研的第二个痛点是数据孤岛。财务数据在一个系统里行业数据在另一个数据库里舆情数据又在第三方平台上。分析师每次做研究都要把这些数据手动导出来拼到一张Excel表里。同一家公司的营收增速可能因为数据源口径不一致被分析师算了三遍、对了三遍。李昱琦说Panda AI的第一步不是去做“自动交易”而是先把这些低效的重复劳动干掉。用一个统一的数据接入层把各种结构化、非结构化数据接到agent里让agent自动完成清洗、对齐、格式化。你给它一个指令它自己跑完“获取数据—清洗—分析—生成报告”的全过程。这个思路本质上和Claude Code处理代码的方式一模一样你给它一个任务它自己读取代码、定位问题、修改文件、跑测试最后给你一个可用的交付物。1.3 投研AI化的真实机会从“辅助”到“替代”这里要澄清一个常见的误区投研AI不是要替代分析师的判断力恰恰相反它是把分析师从“搬砖”中解放出来让他们把精力放在真正需要人类智慧的地方——投资逻辑、行业洞察、风险判断。Panda AI瞄准的正是“AI执行、人做决策”这个中间层。我自己非常认同这个定位。过去几年见过不少“全自动投资系统”项目最后都死在过于激进的模型上。反而那些老老实实做“AI辅助投研”的产品活得更久——因为它们解决的是真实存在的效率问题而不是试图取代人类对市场的理解和判断。就像Claude Code并没有让程序员失业而是让程序员从重复劳动里腾出手来思考架构一样。2. Harness是什么一个能承载agent的工程底座聊完了投研痛点下一个问题自然就来了为什么用Harness说实话在Panda AI之前我和很多开发者一样对Harness这个开源项目只有一个模糊的印象——字节跳动开源的智能体开发框架底层是LangChain和LangGraph。但真正要把一个“投研Claude Code”落地你会发现自己光秃秃地写LangChain完全不够而Harness恰好补上了这个工程缺口。2.1 Harness的底层LangChainLangGraph的组合拳先说底层。LangChain是构建大模型应用的生态库提供了大量组件——模型封装、Prompt模板、工具调用、向量检索等。LangGraph则是在LangChain之上做“agent状态编排”的库它把agent的执行过程建模成一张有向图每个节点是一个逻辑步骤每条边是状态转移的条件。Harness就是把这两层再往上做了一层工程封装。它把数据采集、模型编排、逻辑调度和服务化打包成了一个开箱即用的框架。你不需要自己去拼装那些组件只需要按照Harness的约定用配置文件声明Agent的角色、工具、模型和任务流程它就能把一个多步骤的智能体任务跑起来。打个比方LangChain提供的是造一辆车的零件LangGraph是车辆的装配图和流水线调度逻辑而Harness直接给你一辆可以上路的车——轮子和发动机你都认得但不用从头拧螺丝了。2.2 Harness与Agent的区别方向盘和车的比喻其实很多人问“harness和agent区别”这个问题的时候还没搞清楚一个概念层级关系。Agent是一个抽象概念——一个能感知环境、做出决策、执行动作的智能体。而Harness是一套让Agent能够稳定运行的工程框架它解决的是Agent的“落地问题”。拿开车举例Agent是实现自动驾驶的那套算法和决策逻辑Harness是整辆车的底盘、悬挂和供油系统。没有好的底盘再聪明的算法也跑不稳。Harness做的就是这些“脏活累活”——比如怎么管理agent运行时的上下文、怎么在某个步骤失败后自动重试、怎么在多轮工具调用之间维护状态、怎么把结果结构化返回给外部系统。这些工作看着不起眼但没有它们agent只能在理想环境里跑通一碰到现实业务就崩。2.3 为什么选Harness而不是从零造轮子李昱琦在交流里提到一个很实在的观点Panda AI的核心壁垒是投研场景的深度理解而不是重新发明一套Agent框架。如果从底层LangChain写起团队至少要花两三个月去做脚手架工程而且随着需求变复杂代码很可能越写越乱。用Harness这样的成熟框架可以把80%的工程问题挡在门外团队只专注那20%真正绑定场景的东西。另外一个现实原因是模型兼容性。Harness的模型适配层做得比较厚既能接闭源API也能接本地部署的Ollama模型。对于金融场景来说数据敏感度高、合规要求严很多企业客户要求私有化部署Harness这种“一套框架、多种模型后端”的特性非常关键。你在本地跑个7B的小模型做初筛遇到复杂推理再切到云端大模型完全可以在Harness里配置出来。3. “交易领域的Claude Code”从编程范式到投研范式的迁移接下来是这篇文章最关键的部分理解“交易领域的Claude Code”到底意味着什么。李昱琦这个提法不是空喊口号背后有一套清晰的逻辑——Claude Code验证了“agentic coding”这种模式而这种模式可以被迁移到任何以信息处理和文档输出为核心的知识工作领域。3.1 Claude Code到底做对了什么Claude Code火起来不是因为它的聊天能力多强而是它把AI从“聊天对象”变成了“干活的人”。你在终端里给它一个任务它真的能读取你整个代码库找到相关文件修改代码执行测试根据报错继续修复直到任务完成。它的核心是形成了一套闭环理解、行动、反馈、修正、输出。这套交互方式解决了一个终极问题人类不再需要事无巨细地下指令只需要给一个高层次的意图Agent负责把细节补完。编程这件事天然适合这种模式因为代码是结构化的、机器可执行的Agent的错误可以被测试用例立刻反馈形成闭环修正。这也是为什么Claude Code在编程领域的落地速度远超其他行业——不是因为它只适合程序员用而是编程这个领域天生具备“可验证性”。3.2 投研版Claude Code应该具备的五个核心能力如果把投研比作一个“知识工作者的日常”那投研版Claude Code至少应该具备五个核心能力数据接入与清洗能力能够自动从新闻源、公告、财报、数据库中抓取数据完成清理和结构化。信息检索与筛选能力收到一个研究任务后先拆解成子问题再针对每个子问题做定向检索找到可信度高的信息源。财务建模与分析能力能调用计算逻辑对公司基本面做定量分析计算估值指标、增长率、毛利率等。报告生成能力把分析过程整理成结构化的研报包含数据表格、观点结论、风险提示。持续跟踪能力不是“一次性问答”而是能设定周期定期拉取新数据更新结论——这一点和Claude Code持续维护代码库其实是同构的。用Harness落地这五个能力每个能力就是一个Agent节点或一个工具调用通过LangGraph的图结构串起来。这比硬编码好得多因为每个环节都能挂上不同模型、不同prompt、不同工具出问题时单独调整一个节点就行不会牵一发动全身。3.3 人在回路的取舍别追求全自动和Claude Code一样投研agent也不能是完全无人值守的。Claude Code在执行关键操作前会请求用户确认投研场景更需要这样的人机协同。李昱琦的核心观点是“人来定方向、AI来跑细节”分析师设定研究框架和关键假设agent负责数据获取、清洗和初稿撰写最终分析师复核并签署结论。这种半自动模式既保住了效率也保住了专业性和合规底线。我自己做agent开发时也有相同体会。全自动的agent看着酷跑起来就是灾难——一旦某个步骤出现幻觉或者数据源出错后面全崩。加了人工确认节点之后虽然每次任务多花几分钟但整体可靠性提升一个量级。这个取舍做erp系统的人叫“审批流”做AI的人叫“人在回路”本质都一样关键节点要留给人来兜底。4. 用Harness搭建投研Agent的完整实操理论说了一堆现在进入实操环节。我按照Panda AI公开分享过的技术路线结合我自己搭harness的经验整理了一套“从0搭一个投研Agent”的完整流程。这里用的例子是通用的你换成财报分析、舆情监控、行业研究都可以直接套用。4.1 环境准备安装Harness与模型接入先交代一下技术背景。Harness官方仓库的安装方式很常规我推荐用git clone加pip install的组合环境隔离用conda或venv都行。# 克隆项目 git clone https://github.com/bytesigma/harness.git cd harness # 安装依赖 pip install -r requirements.txt然后配置模型接入。Harness支持的模型后端比较灵活既支持OpenAI、Gemini、Claude这类云端API也支持DeepSeek、Ollama本地模型。以我最常用的DeepSeek为例配置一个API Key就能跑model: provider: deepseek api_key: ${DEEPSEEK_API_KEY} model_name: deepseek-chat这里的核心思路是Harness通过统一的模型接入层屏蔽了不同厂商API的差异。你写好一套Agent逻辑今天用DeepSeek、明天换Claude配置改一行就行。对于投研场景这种对成本敏感、对模型能力要求又不低的使用场景这个灵活性非常重要。4.2 用YAML定义一个“研究员Agent”Harness最大的特点是可以用声明式配置来定义Agent。你不需要写复杂的类继承一个YAML文件就可以描述一个Agent的角色、模型和工具集。我自己第一次看到这种设计的时候还挺意外的——原来Agent定义可以像写简历一样清晰。agents: research_analyst: name: 投研分析师 model: deepseek-chat role: 你是一名专业的基本面分析师擅长解读财报数据、 识别行业趋势、评估公司竞争优势。 tools: - fetch_news - parse_pdf - calculate_financial_ratios - search_web system_prompt: 你需要对给定的公司或行业进行深度研究。 第一步收集信息第二步构建财务模型 第三步输出结构化的研究报告。看到没有你只需要说清楚“你是谁、你能用哪些工具、你该干什么”剩下的就可以交给Harness来调度。这套定义方式非常适合团队协作不同分析师可以各自维护自己的agent配置互不干扰。而且配置是文本天然支持git版本管理改了什么记录得一清二楚。4.3 LangGraph状态流转设计Agent定义好了还需要一个重要设计任务怎么流转。在Harness里这一步会用LangGraph的图结构来描述。一个完整的投研Agent流程通常包含下面几个节点collect_data数据收集触发新闻抓取、财报下载clean_data数据清洗剔除重复、修复格式错误analyze核心分析调用LLM做财务分析和逻辑推理write_report报告撰写按模板输出文档review人工复核关键数据需要分析师确认节点之间的边不是全连通的而是有条件的。比如analyze之后如果数据不足会跳回collect_data重新补充数据而不是硬着头皮往下走。这种“条件边”设计是LangGraph相对普通For循环的最大优势——Agent真的能在运行中自我修正而不是一条道走到黑。4.4 一条研报自动化流水线的演示我实际跑过的最简单版本是这样输入一家公司的股票代码agent先抓取最近三条财报数据然后调用计算工具算出毛利率、净利率、营收增速最后输出一份五段式研报初稿——公司概况、财务分析、竞争优势、风险提示、结论。全部流程大概两分钟中间不需要人干预只在最后一步跳到review节点让我确认数据有没有算错。这套流水线的核心价值在于成本重构以前这件事至少需要一个分析师花半天到一天现在两分钟就能出一个基础版的初稿。虽然没有高级分析师写得深但作为“第一版粗稿”完全够用后面人类分析师做增量修改就好。这就是李昱琦讲的“给每个分析师配一个智能投研助手”的具体落地方式——不是取代分析师而是让分析师从空白的Word文档开始写报告变成在AI初稿上优化迭代。5. 实战中的坑数据、状态、幻觉与模型选型写到这里如果你觉得“这不就是一个配置执行工具嘛没什么技术含量”那就错了。真正把投研Agent跑起来之后你会撞上一堆文档里没有的坑。这些坑不解决agent就是demo玩具解决好了才是生产力工具。5.1 数据源的质量陷阱金融数据源的问题比技术问题更恶心。首先是免费的数据接口不稳定今天能抓明天对方改了JSON结构就挂了。其次是PDF财报的解析质量我用过好几个解析工具遇到扫描版PDF基本全废需要OCR兜底。再者是数据口径问题——同一家公司A源给的手续费收入口径和B源不一致如果不加校验模型会在一个报表里混用两种口径算出来的指标根本没法看。我的经验是一定要在数据接入层做一道“数据血缘校验”把每个数字的来源、时间、口径都记录下来后面分析用到的每一个关键数据都能追查到原始来源。这在投研场景不是可选项是刚需。否则你做出来的报告连数据怎么来的都不知道分析师根本不敢签字。5.2 Agent状态失控超时、循环、上下文溢出第二个大坑是Agent运行时的状态管理。LangGraph的图流程看着清爽跑起来全是细节。最经典的是死循环agent在“数据不足、补充数据、还是不足、继续补充”的循环里出不来白白烧掉一堆token。我的解决方案是给每个节点设置最大重试次数和超时时间超时就直接进入人工review节点让人接管。另一个高频问题是上下文溢出。投研任务往往要连续处理几十个文档LLM的上下文窗口很快就满了。我在Harness里一般会给每个子任务限定输入范围一次只让模型看当前需要处理的那份PDF或那几张表格分析完把结论写回状态容器再清空上下文处理下一个文件。这种“分而治之”的策略比硬堆长上下文便宜且稳定得多。5.3 幻觉问题如何防止AI编造财务数据AI幻觉在聊天场景问题不大在投研场景就是事故了。模型很可能在计算营收增长率的时候因为概率采样抽风算出一个和原始数据对不上的数字而且它还会一本正经地把这个错误数字写进报告里。这个我真实踩过坑有一次生成的研究报告里净利润的绝对值和增长率明显矛盾要不是人工复核及时发现发出去就麻烦了。针对这个坑我的做法是三层防御第一层所有关键数字强制走计算工具用代码算不让模型心算第二层报告里的每一个数字都要求agent标注数据来源页码没有来源的数字自动标红第三层任何涉及金额、比率的数字在review节点做交叉校验如果和原始财报不一致直接拦截不输出。这套流程跑下来幻觉导致的数字错误基本能被拦在门外。5.4 模型选型与成本控制的经验心得最后说说模型选型。我之前试过用Claude做复杂的行业分析推理质量确实高但成本也感人DeepSeek性价比高普通的数据抽取和报告整理任务完全够用但遇到需要复杂多步推理的场景偶尔会掉链子。我的实践是用Harness做“分级调用”简单任务比如数据抽取、格式转换用便宜的模型复杂任务比如投资逻辑分析、风险识别切到强推理模型。这样整体成本能压到原来的三分之一效果还不打折扣。这个经验其实和Claude Code社区总结的分层策略很像——不是所有代码任务都需要最强的模型简单的格式化修改用便宜模型就够了。投研业务里这种任务分级的需求更明显因为金融数据的处理量太大全用贵模型成本根本吃不消。6. 从Panda AI的模式看投研Agent化的确定性方向做完上面这些实践再回头看李昱琦做“交易领域Claude Code”这件事我觉得有几个方向是确定的也值得后续做agent的同行们参考。6.1 从工具到“数字研究员”Agent的定位进化Panda AI的整套打法核心是把agent从“回答问题的小工具”升级成“能独立完成研究任务的数字研究员”。这个定位的差异很关键工具是等指令、做一件事、返回一个答案而“数字研究员”是接一个课题、自主规划路径、多步骤执行、产出完整成果。Claude Code在编程领域已经证明了后者可行投研领域的需求更强烈——研究报告的价值远高于一段代码补丁用户愿意为“一份可用的初稿”付费。6.2 垂直场景的数据壁垒比模型能力更稀缺另一个确定的方向是数据壁垒。模型能力可以通过换更好的模型来提升但高质量的结构化金融数据——干净、口径统一、有历史积累的数据——是别人短时间补不回来的。Panda AI之所以敢做投研agent除了因为Harness降低了工程门槛更重要的原因是他们手里掌握着大量结构化的研报和数据库资源。这让我想起早年做智能客服时的经验决定上线效果的往往不是模型调得多好而是知识库整得多干净。6.3 给想做垂直领域Agent的开发者三个建议最后结合我自己的经验给想做垂直领域Agent的开发者三个建议别一开始就做“全能agent”先找一个高频、重复、耗时、且错误容忍度相对高的环节切进去比如研报初稿、数据清洗、舆情汇总跑通了再往上游延伸。工程框架直接采用成熟方案Harness是目前比较合适的选择之一。把时间花在数据清洗和场景建模上不要花在造轮子上。一定要设计好人机确认机制。哪怕是再强大的agent也需要至少一个“让人签字”的环节。这既是风险控制也是让专业用户对你的产品建立信任的必经之路。李昱琦的团队在用Harness重构投研这件事上踏出的路径其实很有参考价值它不是简单做一个“金融版Copilot”而是把agent当正式员工去分工、去管理、去优化。这条路我看着靠谱也希望后续能看到更多基于开源框架生长出来的垂直领域agent标杆而不是每个团队都重新发明一遍轮子。根据我个人的实操体验垂直领域agent的开发最难的不是技术选型而是能不能沉下心把行业里的脏数据、怪逻辑、潜规则摸清楚。技术底座已经开源真正的门槛在于你对一个行业场景的理解有多深。