做投研的人应该都有同感每天打开行情软件消息推送几百条公告、研报、社交媒体观点混在一起真正有价值的信息往往被淹没在噪音里。最近 Z Waves 对 Panda AI 李昱琦的专访在圈子里讨论度不低核心观点很直接——用 Harness 重构投研流程做“交易领域的 Claude Code”。我认真读了两遍又结合自己折腾智能体工程化的经验这篇文章想把这套思路背后的技术逻辑拆开聊聊Harness 到底是什么、和普通 Agent 有什么区别、投研场景下落地时有哪些关键节点以及从 0 到 1 怎么搭一套能用而不是“能跑”的投研智能体。适合正在做量化研究、行研自动化或者对智能体编排感兴趣的读者。1. 一句话破题Panda AI 想解决投研的什么痛点1.1 投研根本不是“信息不够”而是“信息处理和确认太慢”很多没做过投研的人会误以为这个行业的核心壁垒是信息渠道。但真正在里面待过就知道信息早就过剩了。一份财报上百页一条突发公告可能改写整个逻辑链条一个产业链上下游的数据散落在十几个数据源里。分析师的大量时间不是花在“发现机会”上而是花在机械劳动上读材料、摘字段、做交叉验证、写纪要。这些事情高度重复、规则明确但每一步都需要仔细核对恰恰是 LLM 最擅长、也最适合工程化的场景。李昱琦在专访里把方向定为“用 Harness 重构投研”本质上是把投研从一个“靠人肉堆时间”的流程变成一个“可编排、可审计、可迭代”的智能体工作流。这个切入点很聪明因为它没有试图替代基金经理做决策而是先解决“研究环节的成本与速度”问题。Claude Code 为什么能在编程圈火道理其实一样它解决的不是“写代码”这个创造性动作而是读代码、改代码、跑测试、查报错这些消耗时间的体力活。1.2 Claude Code 带来的范式变化从“工具”到“Agent”聊 Panda AI 之前得先把 Claude Code 这个对标物说清楚。早期我们把 AI 当“工具”用你给它一个明确的 prompt它给你一份输出。这种模式的问题在于所有拆解任务、组织步骤、判断结果的活还是人干。而 Claude Code 这类编码智能体不一样它是一整套自动化循环模型负责理解和规划终端工具负责读写文件和执行命令上下文负责携带项目状态人在关键节点做确认和纠偏。这个循环带来一个关键变化AI 从“回答问题的助手”变成了“对目标负责的执行者”。你给它一个任务比如“修复这个测试失败”它会自己去读代码、定位问题、改文件、跑测试然后告诉你结果。放到投研里对应场景就是你告诉智能体“分析一下这家公司最近的公告有没有隐藏风险点”它应该自己去抓公告、抽取关键字段、对比历史数据、生成风险清单而不是等你把材料整理好再问它。Panda AI 想做的“交易领域的 Claude Code”就是把这套以目标驱动、工具闭环、人在回路的模式从代码世界搬进金融世界。研究对象从仓库文件变成公告、财报、行情数据执行动作从读写代码变成调数据接口、跑统计模型、写研究摘要。1.3 “交易领域的 Claude Code”不是自动交易而是研究自动化这里必须澄清一个容易误读的点Panda AI 的方向不是全自动交易。自动交易系统在华尔街已经存在几十年了那不是新故事。真正的痛点是在交易信号产生之前有大量研究判断工作很难自动化或者说很难系统化。比如某个行业突然出政策你需要马上搞清楚涉及哪些上市公司、这些公司历史上对同类事件的反应如何、当前估值隐含了什么预期。这些工作以前只能靠研究员手动梳理做完可能已经错过最佳反应时间。而一个投研智能体会做的事情是把“政策文本解读、受益标的筛选、历史类比分析、报告摘要生成”拆成一组可编排的任务由 Harness 统一调度把小时级的响应缩短到分钟级。但最后是买入、卖出还是观望仍然由人来决定。这个边界设计决定了它在真实交易场景里能不能被接受。2. Harness 到底是什么它不是又一个 Agent而是智能体的工程框架2.1 单个 Agent 解决“能做”Harness 解决“可靠地做”现在市面上有大量“Agent 框架”但很多人用下来会发现一个问题单个 Agent 做 Demo 很惊艳放到生产环境就翻车。原因很简单Agent 本身只是一个执行单元它知道“怎么完成任务”但不知道“流程怎么治理”。任务失败怎么重试中间状态存哪里多个 Agent 之间怎么交接人工确认点怎么插工具权限怎么控制这些问题的答案不在 Agent 里在编排层。Harness 在这里扮演的角色更像是一个“项目管理办公室”。它不负责具体干活但负责把活拆清楚、把状态管起来、把每个环节的输入输出定义好。李昱琦在专访里强调用 Harness“重构”投研关键词是重构也就是说不是简单地在外面套一层壳而是把投研业务当成一个软件工程问题来处理。哪一步需要自动化哪一步必须人工介入哪一步的输出需要校验全部显式地建模出来。2.2 Harness 与 Agent 的区别一张表说清楚很多读者分不清 Agent 和 Harness 的关系我直接用表格对比对比维度单个 AgentHarness核心职责完成一个具体任务编排一组 Agent 完成任务状态管理跟随单次对话上下文跨节点持久化支持断点续跑工具使用自带少量工具自主调用统一注册、鉴权、限额管理可观测性日志简单定位困难全链路追踪节点级检查点人工介入对话式随机干预在流程节点上显式设置审批失败处理往往整体重跑定位失败节点局部恢复你可以把单个 Agent 理解成一个能力很强的员工把 Harness 理解成公司的项目管理制度。员工能力再强没有流程约束也会失控制度再完善没有能干的员工也出不了活。Panda AI 选择 Harness本质上是要在“智能体能力”和“业务流程可控性”之间找到平衡点这在金融场景里是生死线。2.3 底层技术形态LangChain LangGraph 生态的工程化封装从技术栈上看Harness 这类框架跟 LangGraph 的思路是一脉相承的用图结构来定义工作流节点是具体的执行单元边是流转条件然后在节点内部跑 LLM 调用或工具调用。这样做有几个非常实际的好处。第一流程是显式的。一个投研工作流长什么样打开配置就看得到不会像纯对话式 Agent 那样黑箱。第二流程是可恢复的。某个节点调用外部数据源失败不需要重新跑前面所有步骤只要把失败节点修好从检查点继续就行。第三流程是可插拔的。模型可以换工具可以换但是业务逻辑的骨架不动。热搜词里一直有人问“harness架构(langchainlanggraph)智能体开发案例”其实就是想知道这类框架在实际业务里是不是真的能落地。从我自己的实践经验看能落地的关键不在于框架本身多花哨而在于它能不能让你把业务流程“画”出来并且每个环节都能单独测试。Graph 式的编排天然适合这个需求Harness 只是把这一套工程化得更完整了包括 Skill 机制、工具注册、审计日志等。2.4 为什么选 Harness 而不是自己造轮子这个问题我在自己的项目里也纠结过。自己写一套编排框架听起来很酷但代价是你得同时维护状态管理、并发控制、工具鉴权、日志追踪这一大堆和业务无关的工程问题。对于 Panda AI 这种专注于投研场景的团队来说时间应该花在提炼投研方法论上而不是重写一个 LangGraph。用 Harness 这类框架相当于把智能体工程的通用问题外包出去自己专注做行业层的东西把研究员脑子里的分析框架变成 Skill把数据源封装成标准工具把复核流程变成工作流节点。李昱琦在专访里的表述我理解下来也是这个意思投研领域的核心竞争力不是“我们会调模型”而是“我们懂投研并且知道怎么把投研流程拆给机器干”。3. 重构投研把研究员的工作流拆成可编排的智能体3.1 投研工作流的五层拆解如果想把投研流程工程化第一步不是写代码而是把流程拆到足够细。我按自己做项目时的习惯把一次典型的投研任务拆成五层信号采集、事实抽取、证据交叉验证、假设生成、输出与复盘。信号采集层负责盯外部变化比如公告发布、新闻推送、行情异动它回答的是“现在有什么值得看”。事实抽取层负责把非结构化文本变成结构化字段比如从财报里抽出营收增速、毛利率、现金流从公告里抽出交易标的和价格。证据交叉验证层是最容易被忽视的它要回答“这个信息是否可信”需要把不同来源的数据放在一起比对找出矛盾点。假设生成层基于前几步的结果生成可检验的假设比如“如果下游需求改善哪些公司的弹性最大”。输出与复盘层把整个链路的结果整理成一份研究纪要并且记录决策依据方便后续回溯。这五层不是线性关系而是一个带反馈的闭环。Harness 的价值就是把这个闭环从“人脑里的隐性流程”变成“系统里的显式工作流”每一层都可以独立测试、独立替换、独立加人工审核点。3.2 用 Harness 组织“研究管线”我在实际项目里搭过一个简化版的研究管线流程是这样的入口触发器收到一条公司公告先由采集 Agent 把公告正文和关联的历史公告抓取下来然后由抽取 Agent 把关键字段结构化接着由验证 Agent 去对比历史数据和同类事件最后汇总 Agent 生成一页纸的研判摘要送给人做最终确认。这里面有一个关键设计不要让一个 Agent 干所有事。你如果试图让一个大模型吃掉全部材料然后直接给结论上下文会爆炸而且一旦某一步错了你很难定位是哪个环节出了问题。拆成多个子 Agent 之后每个环节的输入输出都是明确的验证 Agent 发现数据矛盾可以直接把问题带回采集 Agent 重新查而不是把整条链路推倒重来。用 Harness 来编排就是把上面这条管线画成一个图节点是各个 Agent边是数据流转条件边负责判断“验证通过还是打回”。这样做还有一个额外好处就是新来的研究员可以看懂整个系统在干什么而不是面对一个只能输入问题、输出答案的黑盒。3.3 关键设计点上下文管理、流程记忆、审计合规三个细节决定这类系统能不能真正用于生产。第一是上下文管理。财报几十页研报上百页不可能全塞进模型上下文。正确做法是“先检索再精读”先用向量检索把相关片段捞出来再把片段交给抽取 Agent 处理。第二是流程记忆。很多智能体系统做着做着就忘了之前查过什么导致重复劳动。Harness 支持跨节点状态持久化可以把已经验证过的数据存下来后续节点直接复用这能省掉大量 token 和时间。第三是审计合规。投研机构对信息来源的要求非常高系统里每个结论都要能追溯这个数字来自哪份公告那句话出自哪篇研报。所以从设计第一天起所有中间结果都要记录来源引用这个在金融场景里不是可选项是硬要求。3.4 为什么每个阶段都要留“人工确认点”经常有人问我投研智能体做到最后是不是就不需要研究员了。我的看法是恰恰相反研究员的价值会更高只是角色从“执行者”变成“审核者”。原因很简单交易的错误成本太高而 LLM 的幻觉问题短期内不可能根除。智能体能帮你把研究范围缩到很小把证据摆到面前但扣扳机这件事必须由人来做。所以用 Harness 搭投研流程时我建议在三个位置强制加入工确认点数据源确认防止采到错误数据、关键假设确认防止逻辑链条建立在错误前提上、最终决策确认这是交易红线。人工确认点不是降低效率而是保证系统出问题时有人兜底这也是智能体能在严肃金融场景里存活的前提。4. 从 0 到 1搭一个投研 Harness 的实操路径4.1 环境准备与最小装配聊完思路上点实操。我自己搭这种系统时一般分四步走。第一步是准备环境Python 3.10 以上把 Harness 项目 clone 下来然后pip install -e .安装依赖模型这块建议先接 OpenAI 兼容接口方便后面替换。需要说明的是这个领域的框架迭代非常快具体安装命令以官方仓库为准我这里说的是通用路径。第二步是配置模型。强烈建议把 API Key 放在环境变量里而不是写死在代码中不然代码一旦提交到仓库密钥就泄露了。第三步是熟悉 Harness 的 Skill 机制。Skill 相当于给智能体的“岗位说明书”一个 Skill 定义清楚输入、输出、处理步骤和注意事项。投研场景下可以先把“财报摘要 Skill”“公告风险点提取 Skill”这类高频能力沉淀下来。第四步是测试最小闭环输入一份公告看系统能不能跑通“提取、摘要、人工确认”这条链路。4.2 第一个最小闭环公告解读我拿公告解读举个例子。这个任务的输入是公告全文输出是一份结构化结果包括事件类型、关键条款、潜在风险点。用 Harness 风格的伪代码来表达大概是下面这个样子from harness import Workflow, Skill Skill def extract_event_type(text: str) - str: # 调用 LLM 判断公告类型 ... Skill def extract_risk_points(text: str) - list[str]: # 抽取与风险相关的表述 ... Skill def summarize(text: str, event_type: str, risks: list[str]) - dict: # 生成一页纸摘要 ... workflow Workflow(announcement_reader) workflow.add_step(extract_type, extract_event_type) workflow.add_step(extract_risk, extract_risk_points) workflow.add_step( summarize, summarize, after[extract_type, extract_risk] ) result workflow.run({text: announcement_text})这段代码是示意具体 API 以实际框架为准但思路是通用的先拆步骤再定依赖最后跑工作流。跑通这个最小闭环之后你已经拥有了一个能自动读公告的智能体它的输出可以直接交给研究员做二次判断也可以存进知识库备用。4.3 升级到多智能体编排采集、验证与信号生成最小闭环跑通后下一步是做多智能体编排。我常用的方案是三个 Agent 协同采集 Agent 负责抓取公告、新闻、行情数据验证 Agent 负责交叉比对不同来源的数据判断一致性信号生成 Agent 基于前两步的结果产生候选研究假设或预警信号。在 Harness 里这三个 Agent 被编排成一张图核心在条件边验证 Agent 发现矛盾时工作流不会继续往下走而是沿“打回”分支回到采集 Agent 重新查证。这个设计很像真实研究流程里“证据不足就打回重查”只不过现在由系统自动执行。多智能体的难点不是让每个 Agent 都会干活而是定义好它们之间的交接协议上游输出什么字段、下游需要什么字段、字段缺失时怎么处理。这些细节决定了系统在真实场景中的稳定性。4.4 接入回测与风控智能体输出如何变成可用信号研究管线产出的信号不能直接接到交易系统上中间必须有回测和风控两道闸门。我的习惯是智能体只负责输出“候选信号”比如“某公司毛利率连续三个季度改善且当前估值处于历史低位”然后由独立的回测模块去历史数据上验证这个信号在过去几年的表现再由风控规则引擎检查当前的仓位限制、行业集中度、流动性约束等硬性条件最后才把完整的研究报告和风险提示推送给人做决策。这里有一个必须强调的原则回测通过不意味着实盘能赚钱样本内表现好很容易样本外稳定才说明信号有泛化能力。所以我建议在回测流程里固定划分样本外区间并且每次迭代策略时都重新评估防止整个系统变成“过拟合机器”。智能体把这个流程自动化之后唯一不能自动化的就是对结果的最终负责。5. 常见问题与避坑记录关于这套方向我的几条真实经验5.1 最大的坑试图把上下文塞满我早期做投研智能体犯过最典型的错误就是觉得模型上下文窗口越来越大干脆把整份年报丢进去让它分析。结果有两个一是费用飙升二是效果反而变差。为什么会这样大模型处理超长文本时注意力会被大量无关细节稀释关键的几个数字反而抓不住。解决办法是“分层摄入”第一层用检索把相关章节捞出来第二层只让模型精读这些片段第三层再由抽取 Agent 把结构化字段整理出来。看起来多了一个步骤实际上省了钱也提高了准确率。这条经验适用于几乎所有长文档场景财报、招股书、研报都一样先检索再精读不要做一头扎进全文的莽夫。5.2 工具调用会失控权限必须最小化智能体一旦接了外部工具就会面临“乱调用”的问题。比如它可能因为某次任务失败反复请求同一个外部数据接口账单直接爆掉也可能把中间结果写进不该写的目录。这不是模型不够聪明而是工程上缺约束。用 Harness 跑多智能体时我建议给每个工具设置三类限制调用次数上限、超时时间、操作范围。只读类工具可以放开调用写操作、外部请求这类动作必须经过审批节点。尤其是涉及交易相关的接口哪怕只是模拟交易也要走审批流程不然出一次事故就够你喝一壶的。金融系统里权限最小化不是保守是保命。5.3 别神化“交易领域的 Claude Code”这个类比Claude Code 在编程领域确实很成功但把它的模式搬到投研有一个本质区别必须正视程序报错是即时反馈代码能不能跑、测试通不通几分钟内就见分晓而投研信号的反馈周期可能长达数周甚至数月而且中间夹杂着大量市场噪音。这导致智能体在编程场景可以用高频率试错来快速收敛在投研场景却不能这么做。所以“交易领域的 Claude Code”这个口号我理解更多是指“交互范式和工程架构”上的对标而不是自动化程度上的对标。真正做落地时必须人为降低系统的自主度把“建议”和“执行”严格分开。我的判断是谁能在这种边界感上保持清醒谁才可能把投研智能体真正做成一个有长期价值的产品而不是又一个小玩具。5.4 隐私与合规怎么处理最后聊一个很多人容易忽略的点投研数据非常敏感持仓、策略、研究笔记一旦泄露后果很严重。如果用纯闭源 API等于把核心研究过程暴露给第三方很多机构是绝对不允许的。最近圈子里本地模型讨论热度很高一个很实际的原因就是把模型部署在自己可控的环境里数据不出域合规上才过得去。我的建议是走混合架构敏感数据相关的流程用本地化部署的模型处理通用文本摘要这类低风险任务再考虑调用外部模型。Harness 这类框架的好处就在这里模型层是可替换的你在工作流配置里切换底层模型不会影响上层的业务逻辑。我自己的体会是技术选型时多考虑一层“能不能离线跑”能在关键时刻救你一次。