WorkBuddy 这个词最近在 AI Agent 圈子里讨论度确实高。它不是一个聊天框而是一个能承载多角色、多任务、带记忆和工具的「AI 工作台」。我这次用它搭的是一支 7×24 小时待命的 AI 投研团队——把日常看盘、信息收集、财报拆解、风险提示这些重复性工作全部交给 Agent 去做自己只负责最后审核和决策。如果你也在做行业跟踪、个股研究、或者每天被大量数据和报告淹没这篇文章会给出一套可以直接抄作业的搭建思路。先说结论这套方案适合三类人。一是独立投资者二是做行业研究的研究员三是想给团队搭一套自动化研究流水线的技术负责人。使用门槛不高但需要你花几个小时把角色定义和指令写好——这部分是决定最终效果的关键WorkBuddy 只是把「运行」这件事做得很稳。1. 为什么要用 Agent 搭投研团队1.1 投研工作的痛点其实都是「重复劳动」做投资研究的人都有一个共同的感受真正花在「思考」上的时间不到三分之一剩下的时间都在做苦力。查行情、翻公告、整理新闻、对比历史数据、把数据从 Excel 挪到 Word……这些动作每一样都不难但组合起来非常消耗精力而且特别容易因为漏掉一条信息影响判断。大模型出来之后很多人试过用对话式 AI 辅助研究但很快会发现两个问题。第一对话式的 AI 没有上下文连续性昨天让它跟踪的行业今天它完全不记得一切都要重新交代。第二它没有工具能力不能自己去抓最新数据、不能定时执行、也不能主动推送结果。说白了一个聊天机器人不是一个合格的「同事」。Agent 解决的就是这两件事。Agent 有记忆、有工具、有自主执行的能力它不只是「回答你的问题」而是「替你完成一项任务」。这与投研工作的需求天然契合——投研本质上就是一套流程收集信息 → 加工分析 → 输出结论 → 持续跟踪。每一个环节都可以拆成独立的任务单元交给不同的 Agent 去跑。1.2 WorkBuddy 在其中的位置WorkBuddy 是一个以 Agent 为核心的工作台型产品。它不是单一功能的 AI 工具而是提供了一个「工作环境」你可以在里面创建多个不同的 Agent给每个 Agent 配置不同的角色、技能Skill和模型也可以把多个 Agent 编排成一条工作流让它们互相协作。这个定位很关键因为投研恰恰需要的是团队协作而不是一个全能选手。选 WorkBuddy 而不是从零自己开发一套 Agent 系统主要理由是它能替你把「基建」做完。Agent 的调度、工具调用、上下文管理、日志记录这些底层逻辑都有现成的框架你只需要专注在「业务层」——也就是每一个投研角色的指令怎么写、Skill 怎么配、数据从哪里来。我自己是从代码方案切到 WorkBuddy 的省下来的时间不是一点半点。2. 先把团队架构想清楚四个角色一条流水线2.1 角色拆解一支投研团队需要哪些人在设计 AI 团队之前我先复盘了真人团队的职能分工。一个标准的研究小组大致包含前端的资料收集人员、中端的分析师、负责写报告的主笔、以及后端盯风控的人。这四类角色在 AI 团队里可以用四个 Agent 来对应情报采集员负责定时扫描新闻、公告、行情数据按关键词过滤并汇总。数据分析师负责处理财务数据、计算指标、做基本面拆解和同业对比。研报主笔负责把所有素材整合成结构化研报包含核心结论、逻辑推演、风险提示。风控哨兵负责监控关注池的异动信号比如价格波动、负面新闻、财报披露异常等。这四类角色各有侧重但信息流是串起来的采集员的数据喂给分析师分析师的结论交给主笔成文风控哨兵则独立运行一旦发现问题就向上层 Agent 通报。2.2 为什么是四类而不是一个「全能 Agent」我一开始也试过用一个 Agent 包办所有投研任务但实测下来效果很不理想。原因很简单角色的职责越模糊模型越容易「跑偏」或者「发挥不稳定」。一个身兼数职的 Agent 在抓数据时容易跑题去写评论在写报告时又容易细节缺失。而把任务拆成多个专职 Agent 后每个 Agent 的指令可以写得非常具体模型的输出质量会明显提升。另一个原因是并行效率。四个专职 Agent 可以同时跑不同的任务而一个全能 Agent 只能串行处理。遇到财报季这种需要同时处理几十家公司数据的场景并行执行的时间优势非常大。我试过同样一批任务拆分后整体处理时间比单 Agent 模式快了将近一倍。2.3 Skill 是 Agent 的「手」决定它能干什么WorkBuddy 里的 Skill 是 Agent 能力的扩展模块可以理解成给 Agent 装配的工具包。没有 Skill 的 Agent 只能靠训练数据里的旧知识回答问题有了 Skill 才能实时抓数据、读写文件、执行代码、发起请求。投研场景下我常用的几类 Skill 包括行情数据拉取、公告文本解析、PDF 报告解析、SQL 查询财务数据库、定时任务触发器。配置 Skill 时需要注意接口的稳定性和数据源的合规性尽量选择有正式 API 的数据服务抓爬无稳定接口的页面很容易在后续维护中翻车。3. 实操用 WorkBuddy 把流水线跑起来3.1 环境准备与模型选型第一步是环境准备。我这边主力在 Linux 环境下跑WorkBuddy 有对应的版本安装过程不复杂按照官方文档拉取并初始化即可。如果你用的是 Windows 或 macOS流程基本一致只是路径和权限处理会有一些差异。模型选型上我的建议是「混用」。WorkBuddy 支持对接不同的大模型包括各类开源和闭源模型热门方案里就有接入 DeepSeek 的做法。我的配置思路是任务类型推荐模型理由情报采集、数据清洗、公告摘要DeepSeek 这类高性价比模型量大、重复度高成本敏感财务分析、逻辑推演强推理模型需要多步计算和逻辑一致性研报主笔、最终润色表达能力强的旗舰模型输出质量直接决定阅读体验这里有个误区要提醒不是所有任务都要上最强模型。情报采集每天要跑几十次如果全用旗舰模型成本会非常难看。把高频低难度的任务交给轻量模型把低频高难度的任务留给重模型总成本能下降一半以上而输出质量几乎不受影响。3.2 写好四个 Agent 的「岗位说明书」Agent 的指令就是它的岗位说明书这部分是整套方案的核心我花了最多的时间打磨。以数据分析师为例我的指令大致是这样的骨架你是团队里的数据分析师负责对目标公司做基本面拆解。 工作流程 1. 拉取近5年的核心财务数据营收、净利润、毛利率、净利率、经营性现金流、资产负债率。 2. 计算年复合增长率CAGR并与同行业2-3家可比公司做横向对比。 3. 识别数据中的异常波动尤其是与行业趋势背离的点给出可能原因。 4. 输出结构化结论包括基本面画像、关键驱动因素、需要进一步验证的疑问。 输出要求 - 使用表格呈现财务数据结论部分使用列表每条不超过100字。 - 如果某项数据缺失明确标注「数据缺失」不要编造。 - 所有结论必须有数据支撑禁止使用「大概」「可能」这类模糊表述。关键点在于「输出要求」这一节。模型生成内容时指令里的格式要求越具体输出的规范性就越高。我见过很多人把指令写成一段话结果 Agent 每次都输出不同的格式后面对接非常痛苦。情报采集员的指令又是另一种风格你是团队里的情报采集员负责持续跟踪关注池中的公司和行业动态。 数据源优先级 1. 交易所公告 2. 权威财经媒体的公司新闻 3. 行业垂直媒体的深度报道 处理规则 - 每2小时扫描一次按关键词过滤剔除重复内容。 - 每条信息标注来源、发布时间、影响主体、影响方向正面/负面/中性。 - 重大突发信息如业绩预告、并购重组、高管变动需要立即标记为「高优先级」并触发通知。 输出格式 - 按时间倒序输出单条信息包含标题、来源、摘要50字以内、影响判断。写指令的时候一定要反复强调「不要编造」。大模型在训练时见过很多类似数据一旦某个实时数据没抓到它会倾向于「脑补」一个看起来合理的结果。这个坑我在初期踩过很多次后来在指令里加上了「数据缺失必须标注」这条硬规则情况才好转。3.3 配置数据源让 Agent 能实时触达信息有了角色和指令接下来就是给 Agent 接上数据源。这里要区分两类玩法一类是通过 WorkBuddy 的 Skill 对接标准 API另一类是自定义脚本拉取后投喂给 Agent。我优先推荐前者原因是稳定性有保障。比如行情数据、财务数据这类标准数据正规数据提供商都有成熟稳定的 API直接在 Skill 里配置好鉴权参数就能用。需要注意 token 有效期的问题建议做一个自动刷新机制否则隔几天就要手动换一次 key。公告和新闻类数据稍微特殊一点很多来源没有开放 API。我的做法是用一个轻量脚本定时抓取公告列表把纯文本内容存为 Markdown 文件再由采集员 Agent 读取并做结构化处理。这样做的优势是数据链路每一步都可查出了问题能快速定位是抓取环节还是解析环节。自定义脚本的目录结构我习惯这样组织data_sources/ ├── announcements/ # 公告原始文本 ├── news/ # 新闻抓取结果 ├── prices/ # 行情快照 └── processed/ # 清洗后的结构化数据每个子目录按日期生成子文件夹避免文件越积越多后无法回溯。WorkBuddy 的 Skill 在读取这些本地文件时只需要配置好路径Agent 就可以基于最新数据进行分析。3.4 编排工作流从采集到研报的自动化链路四个 Agent 建好之后就要把它们编排成一条工作流。WorkBuddy 里工作流的逻辑是「事件驱动 定时触发」相结合。日常模式我设了三个定时任务早上开盘前比如 8:30执行一次「晨间快报」由采集员汇总隔夜重要新闻分析师给出当日关注要点主笔生成一份 500 字内的晨报。盘中每 2 小时执行一次情报扫描只跑采集员和风控哨兵实时刷新异动信息。收盘后比如 18:00执行一次「深度复盘」分析当天市场表现、持仓标的变化、以及触发风控信号的事件。财报季还需要额外加一条「财报专项流水线」公告一发布自动触发采集员解析财报文本分析师计算关键财务指标主笔将结果与历史数据和同业数据对比输出一份完整的季报点评。这条流水线全自动跑下来一份常规的财报点评从发布到出具初稿基本可以控制在 20 分钟以内。编排工作流时我建议先跑小范围验证再放开全量。第一次先把范围控制在 2-3 只标的上跑通整个链路后再逐步把关注池扩大。直接一步到位上几十只标的一旦某个环节出问题排查成本会很高。3.5 研报输出用模板固定质量下限研报是整套系统的最终产出也是我最看重质量的部分。我的做法是给主笔 Agent 设置一个固定的 Markdown 模板所有研报都按这个结构生成# 公司名季度/年度点评 ## 核心观点 3条以内每条一句话说清核心结论 ## 关键数据 表格呈现核心财务指标及同比变化 ## 逻辑推演 从数据和信息到结论的推演过程分层论述 ## 风险提示 列出最可能影响逻辑成立的风险因素 ## 跟踪计划 明确下次需要重点验证的信息点模板的价值在于「固定质量下限」。即使某次分析深度一般至少结构是完整的读者能快速找到关键信息。模板定了之后后续如果要让研报适配不同的发布渠道邮件、公众号、知识库就是一个格式转换的问题不需要重新调整 Agent 的分析逻辑。3.6 知识库与记忆让 Agent 越用越懂你投研分析很讲究连续性——上季度说过什么、当时为什么看好、现在的逻辑还成不成立。WorkBuddy 支持接入本地知识库我团队里常用的是 Obsidian 库把历史研报、会议纪要、关注池变更记录都放进去Agent 在做分析前会先检索相关历史内容。这个设计解决了一个很实际的问题没有知识库的 Agent 每次分析都是「失忆」状态无法判断新信息与历史判断之间的关系。接入知识库之后Agent 能主动对比新旧逻辑在研报里写出「相比上次跟踪本次新出现的变量是什么」这对投研工作的价值非常大。我的经验是知识库的目录结构要按标的和主题组织命名规则保持统一比如stocks/600XXX/历史研报/2025-Q1.md。命名越规范Agent 的检索准确率越高这一点在初期规划时就要想清楚。4. 常见问题与排查技巧实录4.1 问题速查表搭建和使用过程中一定会遇到各种问题我把自己踩过以及帮朋友排查过的典型问题整理成了表格现象可能原因排查思路Agent 输出明显错误的数据数据源接口失效或字段变更检查 Skill 日志确认接口返回格式是否变化报告中出现不存在的「事实」指令中未禁止编造或模型温度参数过高在指令中加入硬性规则调低温度参数定时任务没有按时执行时区配置不一致确认 WorkBuddy 调度器的时区设置与任务定义一致多 Agent 协作时信息交接丢失上下文消息截断或结构不统一统一消息格式使用 Markdown 结构化片段传递关键信息成本超出预期所有任务都用了旗舰模型按任务难度分级选模型高频简单任务用轻量模型4.2 几个值得单独说的坑第一个坑是「模型温度参数」。默认配置下很多模型的随机性偏高做分析类任务时容易飘。我的做法是把采集类任务的温度调到接近 0让输出高度确定性只有写研报的主笔 Agent 保留稍高的温度让表达不那么死板。第二个坑是「上下文窗口溢出」。情报采集员跑一段时间后历史消息会越来越长最终超出模型上下文限制。解决方案是把 Agent 的长期记忆沉淀到知识库而不是留在对话历史里。我是给采集策略加了一条规则每次任务完成后把结构化结果写入知识库并清空会话的历史 trace只保留最近一轮的上下文。第三个坑是「外部接口鉴权过期」。很多数据 API 的 token 有效期只有几小时到几天一旦过期Agent 表现出的症状是「数据一直拉取失败」而不是直接报错。排查时如果发现 Agent 行为异常先看 Skill 调用日志确认是不是鉴权问题不要急着调指令。第四个坑比较隐蔽多 Agent 协作时A 传给 B 的内容如果格式不统一B 很容易解析出错。比如采集员用自然语言段落传数据分析师接到的就是一份「读后感」无法直接做计算。我最终把所有跨 Agent 传递的信息统一为「Markdown 表格 结构化列表」之后再没出现过解析混乱的问题。5. 实操心得与后续扩展思路这套「AI 投研团队」从上线到现在跑了接近一个季度我的体感是它不能替代深度研究但能把深度研究之外的所有脏活累活接走。以前我每天晚上要花两三个小时整理当天的信息现在每天早上一封晨报、晚上一份复盘中间随时可以打开工作台看最新的异动提示。省下来的时间真正用在了「想问题」上而不是「找资料」上。再分享一个细节刚开始不要追求 Agent 一步到位。第一周可以把目标定成「把一个 Agent 跑好」比如只做情报采集等到输出稳定了再叠加第二个、第三个角色。很多人的 Agent 方案最后烂尾不是因为工具不行而是因为一开始就把系统设计得太复杂出问题后不知道怎么排查。小步快跑先把链路跑通再逐步完善反而是最快的路径。最后说后续扩展。我正在试的方向是把研报和复盘内容接入自动化推送每天早上定时推送到团队协作群并按照关注标的生成「每周观察清单」。另外还在考虑加一个「良构性校验」的 Skill在研报发布前自动检查数据完整性和逻辑自洽性。WorkBuddy 这套架构的扩展性不错每隔一段时间都会有新的 Skill 出来保持关注即可不用急着把功能一次做满。