如果你关注AI编程工具大概率听说过Claude Code这个名字。它让开发者用自然语言直接指挥一个智能体完成从读代码、改代码到跑测试、提PR的完整闭环。那如果把这个思路从代码世界搬到金融市场会是什么样李昱琦创办的Panda AI正在做这件事——用Harness重构投研工作流想成为“交易领域的Claude Code”。这篇文章我想结合Panda AI的思路聊聊为什么投研行业需要一次工程化重构Harness这种看似新鲜的概念到底解决了什么问题以及一个面向交易场景的智能体系统应该如何设计。不绕弯子全是干货。1. 投研行业的核心痛点信息过载与工作流断裂1.1 研究员的真实一天大量时间浪费在“找数据”而不是“做判断”我接触过不少买方和卖方的研究员大家有个共同的感受真正用于思考、建模、写结论的时间可能连工作日的一半都不到。剩下的大量时间去了哪里答案是——搜集、清洗、整理数据。一个典型的个股研究流程大概是这样的早上打开行情软件看盘前异动然后去财报网站翻最新披露去资讯平台扫行业新闻再跑到数据终端把历史财务数据导出来粘到Excel里手工处理。如果涉及产业链上下游对比还要再开好几个网页把各家公司的数据一一对齐。这一套下来光是把信息凑齐就要花两三个小时。等到终于开始写报告、搭模型时精力已经消耗了一大半。这个问题的本质不是研究员不努力而是工具链条断裂了。数据散落在不同系统里格式不统一更新频率不同没有任何一个工具能把“收集-清洗-分析-输出”串成一条流水线。而Claude Code在编程领域做的事情恰恰是把类似的断裂补齐了——它让模型不再是“聊天窗口里的问答机器”而是能自己动手去读文件、执行命令、看运行结果并据此调整下一步的智能体。1.2 为什么说投研是最适合被Harness重构的场景之一金融投研有几个天然适合智能体化的特点。首先它的工作对象大部分是数字和文本这两类数据恰好是大模型最擅长处理的。财报里的营收增速、研报里的核心逻辑、公告里的事件驱动信号模型都能理解并做结构化提取。其次投研任务有清晰的、可拆解的路径。比如“分析一家公司的财务健康度”可以进一步拆成“读取近三年财报”“计算毛利率、净利率、ROE等指标”“对比同行业公司”“输出风险提示”。每一步都是独立可验证的这正好符合Harness对任务拆解和工具调用的设计范式。第三投研对结果有客观的校验标准。推荐逻辑对不对看看后续行情和业绩就知道了模型输出的财务指标准不准和报表一比对就能发现。这种可验证性决定了智能体在 Fintech 场景里能形成“执行-反馈-修正”的闭环而不是像某些抽象问答场景那样只能凭感觉判断好坏。1.3 从“让模型聊天”到“让模型干活”Claude Code给行业的启发Claude Code真正的价值不在于它背后用了多大的模型而在于它重新定义了人机协作的形态。过去的AI助手是你问我答你告诉它需求它给你一段文字或者一段代码。但Claude Code这样的工具做的是把需求变成一个可执行的任务清单自己调用工具、读取上下文、迭代执行直到目标完成。这个转变对投研的意义非常直接。以前你让ChatGPT“分析一下宁德时代的财务风险”它只能凭记忆给你一些泛泛而谈的观点。但如果是一个Harness架构下的投研智能体它会先去拉取宁德时代最新的财报数据提取关键科目变动再对比行业平均水平最后给你一份有数据支撑的风险清单。不会写SQL没关系它会自己生成查询去数据库里跑不会配爬虫也没关系它会自己去网页抓取结构化信息。这才是“替代研究员做脏活累活”的正确姿势。2. Harness架构拆解它和普通Agent到底有什么区别2.1 先厘清概念Harness不是模型是一套“让模型安全干活”的框架现在网上关于Harness的讨论很多很多人把它和Agent混着用其实两者有明确的层次关系。Agent是“有自主决策能力的智能体”而Harness是承载Agent的那套“马具”——你可以把它理解为智能体运行时的基础设施它管着模型怎么调用工具、怎么管理上下文、怎么在每一步做完之后评估要不要继续。用造房子来类比模型是泥瓦匠Agent是那个会独立思考今天先砌哪面墙的工头而Harness是工地的管理制度和安全网。没有制度工头一高兴可能把承重墙砌歪了没有安全网砌错了就得整体返工。Harness的价值就在于它通过预设好的流程、权限边界和校验机制让Agent能在可控范围内自主行动。这也是为什么热词里面会出现“harness和agent区别”这种搜索。很多人以为做智能体就是写好Prompt扔给大模型结果一旦任务复杂起来模型就开始胡言乱语、反复横跳。本质上是缺了Harness层——没人告诉它每一步该调用什么工具、输出要符合什么格式、遇到错误该怎么恢复。2.2 Harness的四大核心组件上下文管理、工具调用、状态控制、可观测性我拆解了市面上几个主流Harness实现包括LangChain和LangGraph的组合方案发现它们不管出身如何内核都逃不出四个组件。第一个是上下文管理。模型的上下文窗口再大也是有限的而一个真实任务可能涉及几十份文档、上百个数据点。Harness要做的是决定什么信息需要始终留在上下文里什么信息可以放到外部存储里按需取回。投研场景尤甚一份研报几十页全塞进上下文不现实Harness会在分析过程中按需检索相关章节。第二个是工具调用。Harness定义了统一的工具接口让模型可以调用外部API、数据库、代码解释器等。关键在于工具的“描述质量”——你在给模型工具清单时写清楚“这个工具能干什么、输入输出格式是什么、什么时候用”效果会天差地别。这一点在Claude Code这类产品上体现得淋漓尽致Claude Code的工具描述写得极其清晰模型几乎不会误用。第三个是状态控制。Harness要维护整个任务执行过程中的状态包括当前做到哪一步了、哪些子任务已经完成、上下文发生了哪些变化。LangGraph那张图就非常直观——它把智能体的工作流画成了一张有向图节点是操作边是流转条件这让复杂的多步任务有了明确的执行路径。第四个是可观测性。智能体每一步做了什么、为什么做这个决定、调用工具返回了什么都要有日志可以追溯。这个在投研领域尤其重要因为基金经理不会相信一个“黑箱”给出的投资建议。Harness的Logging机制让每个研究结论都能回溯到原始数据和推理过程这既是合规要求也是建立信任的基础。2.3 单Agent的局限与多Agent编排的现实需求有意思的是Claude Code最初是一个偏单Agent的形态但到了复杂任务场景多Agent协作几乎是必然选择。为什么因为单Agent在超长任务链上会出现“注意力稀释”——任务越复杂越容易忘记早期目标或者在某一步陷进去出不来。多Agent的思路是让不同智能体各管一摊通过编排让它们协同。比如在投研场景里可以拆成数据采集Agent、财务分析Agent、新闻解读Agent、风险控制Agent各自只做自己最擅长的事。每个Agent的Prompt可以做得非常专精工具集也收敛这样模型的行为会更加可控。但这并不等于Agent数量越多越好。多Agent会带来通信开销和一致性问题Agent之间传递信息的格式不统一系统就会越跑越乱。我自己实际测试下来的感受是三个以内是收益较高的超过五个Agent协调成本就开始大于分工收益了。Panda AI在投研场景里的做法值得借鉴他们没有一上来就堆Agent数量而是先围绕“数据分析师的一天”这个流程做了精细拆解再按需引入编排。3. Panda AI的产品定位交易领域Claude Code意味着什么3.1 不是做另一个“AI荐股软件”而是做投研操作系统说Panda AI要做“交易领域的Claude Code”很容易被误解成又一个自动荐股工具。但仔细听李昱琦在Z Waves专访里的表述产品的核心其实更接近一个“投研操作系统”。Claude Code在编程领域的成功靠的不是帮程序员写出某一段代码而是改变了整个开发工作流的组织方式。Panda AI想做的是一样的重构不再是单点地解决“帮我写一段分析”这样的问题而是把研究员从信息收集到观点输出的整个链条都搬到这个智能体工作台上来。李昱琦在采访里有个比喻很形象他说过去的投研就像在没有电梯的办公楼上班你需要一层层爬楼梯费力且低效。Panda AI想做的是装上一套“中枢连接系统”你在一楼按一下按钮系统自动把你带到想去的那一层。这本质上是在做流程再造而不是做一个更快的爬楼梯者。3.2 产品形态猜想终端优先、命令式交互、可编程工作流参考Claude Code的产品形态Panda AI的投研工具大概率会走“终端优先命令式交互”的路线。为什么不是聊天界面因为真正专业的投研工具用户要的是可精确控制、可复现、可批处理而不是一段上下文就丢失的漫谈式对话。在Claude Code里你会输入类似“找到test目录下对这段函数的调用统一加上超时错误处理”这样的精确指令工具会拆解并执行。投研场景对应的可能是——“分析最近五个交易日里半导体板块中主力资金连续三日净流入的个股并过滤掉市值低于200亿的公司”。这个指令要拆成好几步数据分析操作每一步都需要回溯验证。可编程工作流也很关键。研究员可能有自己固定的一套分析框架比如“先看宏观和行业景气度再看公司竞争格局最后做财务验证”。如果产品只提供一个固定模板那不会比传统软件高级到哪里去。真正的Harness应该允许用户定义自己的分析流程把模型作为流程执行器而不是流程本身。这样每个基金公司都可以沉淀自己的投研方法论。3.3 为什么说金融行业是最容易出现“行业级Claude Code”的地方我之所以觉得金融投研是Claude Code模式最容易迁移成功的领域有几个原因。第一是付费意愿和能力最强。金融机构对效率工具的付费意愿在所有行业里都是数一数二的。一套能切实节省研究员时间的工具客单价做到几十万甚至上百万都有市场这和C端工具靠订阅费的模式完全不同。第二是数据和工具生态相对规范。投研领域有Wind、Bloomberg等成熟数据终端有大量结构化的财务数据库、API接口。Harness调用外部工具的前提是“工具存在且接口稳定”金融恰好满足这个条件。不像某些自动化场景工具层面都还没打通Agent再聪明也使不上劲。第三是结果的价值链足够长。代码领域里Claude Code帮程序员省下的时间最终通过更快的迭代速度体现价值。而投研领域省下时间就是能抓住更多交易机会、产出更高质量的策略建议价值可以直接量化到金钱上。4. 实操视角如何在投研场景搭建一套Harness工作流4.1 从“给模型配工具”开始一次最小可用Harness的搭建过程讲完理论说点能直接落地的。我自己在本地搭建过一个简化版的投研Harness底层思路和Panda AI的方向类似这里把关键步骤和踩过的坑分享出来。首先是工具层的准备。我选了三个基础工具一个Tushare数据库接口用于获取A股行情和财务数据一个本地文件系统用于读取/写入研报草稿还有一个网页检索工具用于获取新闻资讯。三个工具对应投研最基础的三个动作——看数据、写报告、找信息。然后是模型层。当时用的是DeepSeek的开源模型通过本地部署接入。之所以不用闭源API一方面是出于数据安全考虑另一方面在Harness这个框架里工具调用的频次非常高本地部署模型的成本优势很明显。这里多说一句热词里搜“deepseek harness”的人很多其实核心就是把DeepSeek模型接入Harness框架作为推理引擎。开源模型的性价比在这里得到了很好的体现——投研场景对推理质量有要求但也没到非用最贵模型不可的程度。最核心的是编排层。我用LangGraph搭了一个最简单的有向图起始节点负责理解用户目标然后路由到数据采集节点数据采集完成之后进入分析节点分析结束后进入报告输出节点。每个节点之间的流转带条件判断比如“如果数据采集失败则尝试备用数据源”这样的逻辑。4.2 Prompt设计与工具描述决定Harness成败的隐形细节跑通流程之后我才意识到Harness这种架构里真正决定上限的往往不是模型本身而是工具描述和Prompt的设计。我给Tushare数据查询工具写的描述第一版只有一句“查A股股票的财务数据”结果模型经常不知道在什么情况下调用这个工具或者传错参数。后来我参考Claude Code对工具的描述格式把每个工具都写了详细的使用说明适用场景、参数列表、返回值结构、常见错误码。改了之后模型的工具调用准确率直线上升。Prompt设计上也有几个容易踩的坑。一个是“目标越具体行为越可控”。如果你给智能体的指令是“分析新能源行业”它大概率不知道从哪里下手会按自己的偏好乱发挥。但如果指令是“找出新能源板块中过去三年营收复合增速超过30%、且最近一个季度毛利率环比提升的公司”任务边界一下就清晰了。Harness里的Agent不是要靠悟性来工作的它需要的是清晰的目标函数。另一个坑是缺少“中间产物校验”。早期我的智能体经常在分析节点直接给出结论但我无法确认它的数据是否准确。后来在流程里加了一个校验节点要求模型每一步都把关键中间结果比如算出来的ROE、增速以结构化格式输出我再写一段规则去比对原始数据。这个“防呆节点”花不了多少成本却把系统的可信度提升了一个量级。4.3 多智能体编排的实践经验什么时候拆、什么时候合前面提到多Agent不能无脑堆数量这里展开讲一下我的实操经验。在投研Harness里我发现有两类任务很适合拆成单一Agent。一类是强工具依赖型任务。比如数据采集Agent它的Context里只需要记住“怎么调用数据API、参数怎么传”不需要管财务分析的理论。这种Agent的行为非常简单直接几乎没有自由发挥空间非常适合薄Prompt厚工具描述的组合。另一类是强领域知识型任务。比如财务风险分析Agent它需要大量领域知识来判断“这个财务指标异常可能意味着什么”。这类Agent就应该给它配一个比较强的模型并且在Prompt里注入行业先验知识。不适合拆的场景是“信息强耦合任务”。比如分析产业链上下游传导关系时你很难把“上游研究”和“下游研究”拆给两个Agent因为它们需要共享同一套因果逻辑。强行拆开会导致各自得出片面的结论。这种情况下我更倾向于让一个Agent负责全链路用工具调用和上下文管理来完成任务而不是通过分割上下文的方式才合作。4.4 投研Harness的落地避坑表我爬过的那些坑坑点现象解决方法工具描述含糊模型频繁误用参数或忘记调用工具参考Claude Code格式重写工具说明标注适用场景、参数类型、返回示例上下文无限膨胀执行到中后段开始遗忘早期目标设置上下文清理策略早期的中间结果存入外部存储按需召回缺少校验节点模型输出的数值和原始数据对不上增加结构化中间产物输出用规则引擎做交叉验证Agent数量过多通信开销上升系统变慢且逻辑混乱收敛Agent数量信息强耦合场景用单Agent代替多Agent错误恢复路径缺失工具调用失败后直接终止任务在编排图里增加重试、备用数据源、容错降级等分支逻辑日志记录不足结论出错后无法追溯推理过程每步记录“模型推理工具调用返回结果”做到全链路可回溯这六条每一条都是从真实项目里磨出来的。特别是“上下文无限膨胀”这个问题我在做长链条投研分析时几乎每次都会遇到。模型一开始还兢兢业业地按流程走越到后面越容易“飘”开始凭记忆和想象补细节。后来加了状态管理模块每完成一个节点就把关键信息提炼成摘要存入外部存储模型的主上下文始终只保留当前节点需要的信息问题才得到实质性解决。5. 专访浓缩李昱琦谈Harness重构投研的完整逻辑5.1 为什么会选“投研Harness”这个组合一段关于使命的回溯在Z Waves的专访里李昱琦被问到最多的一个问题就是为什么是投研为什么是Harness他的回答很坦诚——因为这是他过去从业经历里最痛的那个点。据他介绍他在创业前曾在一线金融机构做过几年投研相关的技术工作亲眼看到顶尖研究员也在用非常原始的方式处理数据。明明很多工作是可以被自动化、标准化的但因为金融行业的工具链太封闭导致技术革新的速度远慢于互联网行业。他创办Panda AI的初衷就是想把在AI编程工具领域被验证过的这套人机协作范式平移到投研场景里来。但平移不是照搬。李昱琦特别强调了一个差异代码和金融的风险属性完全不同。代码跑错了顶多是报错重新改就行投资建议出错了涉及真金白银的损失和合规责任。所以Panda AI的Harness设计在第一性原则上是“可靠性优先于效率”——宁可慢一点也不让模型在未经验证的情况下输出结论。5.2 Harness在Panda AI体系里的角色让模型“戴着镣铐跳舞”谈到Harness的具体角色李昱琦也用了一个很形象的表达“让模型戴着镣铐跳舞”。传统大模型是自由的你问什么它答什么但有时候自由过了头就会乱跑。Harness的存在就是给模型的自由加上轨道——不是限制它的能力而是确保它的每一步都在可控范围内。他说Panda AI内部对Harness的基本要求是三条第一任何数据操作都要可追溯每一步从哪取数、怎么算的必须留痕第二任何结论输出都要有依据模型不能只给一个结论必须展示推理链条和支撑数据第三任何外部工具的调用都要有权限校验不是模型想调什么就调什么而是要根据任务类型和用户权限动态判断。这三条如果展开说其实就是合规、可信、安全的工程化落地。这些话听起来不那么性感但恰恰是机构客户最在意的三个点。5.3 开源模型在Panda AI技术栈中的位置质变正在发生聊到模型选型时李昱琦的观点和我最近的观察非常一致——开源模型的质变正在改变AI原生应用的成本结构。过去做金融AI应用基本只有闭源API一条路因为开源模型的能力差距摆在那里。但最近这段时间以DeepSeek为代表的开源模型在推理能力上已经逼近甚至部分追平了顶级闭源模型。李昱琦提到他们在搭建投研Harness时很大一部分推理任务已经可以由本地部署的开源模型完成尤其是那些定义清晰、流程固定的工具调用任务开源模型的执行稳定性已经足够好。这不是说闭源模型没有价值——在最难的那部分推理任务上闭源模型仍然有明显优势。关键在于分层把简单重复的推理和工具调用交给成本更低的开源模型把复杂判断和长链条推理留给更强的大模型。这种混合推理架构等于把单位任务成本降低了将近一个数量级对于需要高频调用大量Agent的金融场景节约的成本是非常可观的。6. 对行业的影响与延展思考当Claude Code模式蔓延出代码世界6.1 不只是投研Harness模式适用于一切“专家工作流”写完投研这个案例我想再往远看一层。Panda AI在做的事情表面上是给投研行业做工具本质上是在验证一个更大的命题——Claude Code模式能不能从代码世界延伸出来重构其他专家工作流。沿着这个思路看凡是符合“信息获取-专业分析-结论输出”三段式结构的工作都有可能被Harness重构。法律行业的合同审查和案例检索、医疗行业的文献分析和辅助诊断、电商行业的竞品监控和选品策划甚至包括我们内容行业的信息搜集和初稿草拟本质上是同一类模式。但每个行业都有自己的哈ness落地难度。投研之所以能先跑出来是因为它有标准化程度相对较高的数据结构和清晰的价值回报路径。其他行业要想复制这套模式得先问自己几个问题数据源统一吗专业分析流程有标准范式吗结论是可以通过结果验证的吗这三个问题答得越干脆Harness落地的可行性就越高。6.2 从“辅助工具”到“流程重构”AI应用的下一个分水岭过去一年AI应用的主流形态是Copilot模式——你在旁边写东西AI帮你补全。这种模式解决的是“提质增效”但本质上没有改变工作流程。而Claude Code和Panda AI这类尝试的深层变化在于它们开始介入整个流程的执行而不只是理解某一个片段。这个分水岭一旦跨过去带来的改变是结构性的。组织会有能力把自己的核心方法论固化到智能体系统里变成可沉淀、可复制、可迭代的“数字资产”。当AI不再是一个工具而是一套由流程、知识与工具构成的系统工程时它的价值量级会有一个质的提升。7. 写在后面我的几点真实感受聊了这么多最后说点个人体会。我在搭建这套简化版投研Harness的过程中最大的感受是——技术难点从来不在“把模型接进来”而在“让系统的每一步都可信”。模型的能力再强如果在流水线上自如地出入不受约束它也会像一个天才实习生——能力很强但经常不按流程走让你又爱又怕。Harness这类架构的核心价值不在于管住了模型而在于让模型能在可控的范围内最大化发挥能力。它把“模型的自由度”这件事变得可调节了你可以选择给Agent多一点自由让它探索也可以选择收紧约束让它严格执行流程。这种灵活性是传统软件工程范式很难提供的。对于想在这个方向尝试的朋友我的建议是先别急着追求复杂的多Agent架构从一条最小的闭环开始选一个你日常工作里重复性最高的任务给它配上2到3个工具用Harness框架编排起来跑通之后再逐步加复杂度。你会很快感受到那种“给一条指令整个流程自己跑起来”的体验有多爽。而这只是这个方向的第一步。
