晚上十点收到一条政策新闻弹窗内容直接关系到我在盯的一家目标公司供应链。按照老思路我得先打开新闻原文搜两份行业解读把公司过去三个季度的数据翻出来对照再写一段纪要。等全部弄完凌晨一点。第二天开盘前又刷到一条关联信息心里咯噔一下昨晚漏了这条更关键的。这种状态持续了大概两个月我终于下定决心把投研里最消耗精力的信息采集、资料整理、初筛对比、风险提醒这四类活交给一支不需要睡觉的AI团队。于是有了这个搭建项目——用 WorkBuddy 搭一支 7×24 小时待命的「AI 投研团队」。这篇文章会把完整搭建过程写出来包括团队怎么分组、Skills 怎么配、定时任务怎么排、踩过的坑有哪些。适合正在做行业研究、个股跟踪、宏观资料整理又不想被重复劳动拖垮的从业者。你不需要精通编程能看懂简单配置就行。1. 为什么投研团队能自动化以及边界画在哪里1.1 投研工作里最容易被 AI 替代的四类重复劳动投研本质上是个“信息处理工作”把散落各处的碎片信息收集起来清洗干净整理成结构化的结论供人做决策。这个链条里真正值钱的是“决策”但大量时间花在“处理”上。第一类算是信息采集。新闻、公告、行业政策、机构观点分散在几十个网站和数据库里。人工逐页翻效率极低且容易漏。第二类是结构整理。把一篇几千字的财报公告抽取成营收、毛利、研发费用、现金流等固定字段再和历史同期做对比。第三类是初步筛选。几十条新闻里哪些和当前关注标的直接相关哪些只是泛行业消息需要先打标签。第四类是风险提醒。比如目标公司突然出现负面舆情、行业监管政策变化、关键财务指标异常这些都需要第一时间被人看到。这四类工作的共同点是规则前置、重复度高、对人的耐心要求苛刻。刚好是 AI Agent 最容易上手的地方。普通脚本也能做一部分但页面结构一变、接入数据源一多脚本维护成本就失控。AI Agent 的价值在于它可以用自然语言理解任务遇到页面结构变化时能像一个实习生那样想办法绕过去而不是傻在那里报错。1.2 自动化不是替代决策而是把决策质量垫高这话我放在最前面AI 投研团队不是用来替你下结论的它是用来给你提供“经过清洗和验证的素材”的。我给自己定的原则是系统输出任何“建议”都必须伴随数据来源和计算口径没有来源的信息一律标记为未验证。最终买不买、卖不卖、跟踪不跟踪永远需要人来做判断。这个边界想清楚之后系统设计就简单了。我不需要 WorkBuddy 去预测股价也不需要它生成华丽的投资报告。我需要它每天定时把海量信息变成一张干净的桌子桌面上摆好了新闻原文链接、财务数据对比表、风险事件时间线。我只需要在桌子前坐十分钟做只有我能做的事。1.3 为什么用 WorkBuddy 而不是一堆脚本最直接的替代方案是写 Python 脚本定时爬取信息再用 SQLite 存起来。我在初期也尝试过。问题是爬虫脚本面对每个网站都需要单独适配网站改版就失效数据清洗规则跑一段时间后需要频繁调整而且很难灵活地让“采集”“分析”“写报告”三个环节协作。WorkBuddy 更像一个 AI Agent 工作台它可以让我用自然语言定义各种“角色”和“技能”每个角色负责一类任务然后通过工作流把它们串起来。加上它支持自定义指令、Skills 扩展、定时触发和本地文件读写正好覆盖投研团队的所有需求。更关键的是它可以把成果直接输出为 Markdown 文件方便沉淀进 Obsidian 这样的知识库。这就让整个系统不再是一次性脚本而是真正可以长期运营的“团队”。2. 环境初始化与目录规划这步偷懒后面全是坑2.1 先确定运行环境Linux 还是本地电脑WorkBuddy 本身可以安装在本地电脑上但既然目标是“7×24 小时待命”我更建议直接部署在一台常开的机器上。我自己的选择是一台低功耗 Linux 小主机8GB 内存、四核 CPU跑这套系统绰绰有余。如果你手头有云主机也行但注意 IO 不要太差因为 Skills 会频繁读写小文件磁盘太慢会把整个流程拖垮。如果是第一次接触我建议现在自己电脑上先把链路跑通再考虑搬去服务器。在 Linux 上部署时有几个细节提前处理好后面会省很多事第一不要用 root 账号跑服务第二设计好目录结构第三把日志写到独立文件而不是直接扔在任何目录。2.2 创建专用运行账号避免一上来就 502安装完成后第一次跑任务遇到最多的报错就是502 write EACCES。很多人以为这是 WorkBuddy 的 bug其实是运行账号对输出目录没有写权限。WorkBuddy 服务以某个系统用户启动但这个用户对数据目录不可写于是文件写入动作全部失败。我当时复现的排查链路是先看服务日志发现只有write EACCES没有任何业务报错接着去检查目录权限发现整个/data/workbuddy属于 root而我启动服务的账号是普通用户普通用户对这个目录根本没有写权限。解决办法也简单创建专用运行账号把整个工作目录交给它管理。sudo useradd -r -m workbuddy sudo mkdir -p /data/workbuddy sudo chown -R workbuddy:workbuddy /data/workbuddy sudo chmod 750 /data/workbuddy后续所有 WorkBuddy 进程都用workbuddy这个账号启动。注意750权限就够了没必要用777这样可以避免其他账号随意改动 AI 团队的数据。2.3 目录规划让数据流一眼能看明白安装好之后第一件事就是规划目录。我的目录结构如下/data/workbuddy/ ├── skills/ # 团队成员技能包 ├── flows/ # 工作流编排配置 ├── data/ │ ├── raw/ # 原始采集数据 │ ├── processed/ # 清洗后的结构化数据 │ └── seen.json # 已处理信息指纹 ├── reports/ # 最终研报输出 └── logs/ # 运行日志有人会觉得这多此一举所有文件放一个目录不就行了但等 AI 团队跑起来文件会快速增长而且不同环节的数据混在一起会互相干扰。我见过一个项目所有中间结果都堆在一个output目录里跑了两周后连哪个文件是当天的日报都分不清。把 raw、processed、reports 分开不仅是整理问题更是让后续每个 Skill 只关心自己该读写的目录不容易出错。2.4 自定义指令把团队工作规范一次性写清楚WorkBuddy 支持自定义指令这是整个项目最重要的配置文件之一。它相当于团队宪法所有角色在输出时都必须遵守这里的规则。如果这一步写错后面所有卖力优化的 Skill 都会带着病跑。我自己的全局指令长这样你可以直接参考name: ai_research_team spirit: 先确认信息再输出结论。没有来源的信息一律标记为【未验证】。 output_rules: - 所有结论必须附数据来源URL和获取时间 - 时间格式统一使用 UTC8 - 涉及数字对比时必须给出计算口径 - 不允许生成伪造的数据尤其是财务指标 - 对风险等级的定义 level 0: 无影响 level 1: 需要关注暂不影响逻辑 level 2: 可能影响判断建议人工复核 level 3: 紧急风险立即通知第一条和第四条我尤其看重。AI 在信息不完整的时候容易“脑补”数据和链接这在投研场景里是不能接受的。把“不允许生成伪造数据”写进系统指令后输出质量有了明显提高。如果后续发现某个具体任务仍出现幻觉不要只在全局指令里打补丁而应该在对应的 Skill 定向优化。3. 四位成员的分工设计与 Skills 配置WorkBuddy 里的 Skill 就像一个技能包包含任务描述、提示词模板和辅助脚本。每个成员对应一个或多个 Skill四个成员之间通过文件和标准格式协作。我先说结论不要一上来就做二十个 Skill先把四个角色的核心流程跑通再逐步加细节。3.1 情报员负责外部信息采集与去重情报员是整条流水线的起点对应NEWS_COLLECTOR这个 Skill。它的职责是访问指定信息源抓取和关注标的相关的新闻、公告、行业动态输出原始信息到data/raw/目录。我给这个 Skill 配了一个采集脚本负责从信息源拉取内容而提示词部分负责从抓到的内容中抽取关键字段。name: NEWS_COLLECTOR description: 采集与关注标的相关的市场信息 input: - watchlist: 当前关注的标的和行业 output: data/raw/{date}.json prompt: | 从输入内容中提取以下字段 - title: 标题 - source_url: 原文链接 - publish_time: 发布时间 - summary: 一句话摘要 - entities: 涉及的公司、行业、政策主体 - sentiment: 正面/中性/负面采集脚本我建议用纯 Python 写抓取逻辑简单直接不要引入重型框架。关键点有两个一是给所有请求设置超时避免某个源卡住整个流程二是对抓到的内容做去重重复的 URL 直接跳过。去重逻辑我会在第 5 节专门讲。3.2 研究员负责财务指标计算、公告拆解和纵向对比第二棒是研究员。它的输入是情报员采集到的 raw 数据以及人工预置的财务数据集。研究员 Skill 我命名为FIN_PARSE任务是把公告和新闻里的信息结构化并和已有的历史数据做对比。这里最重要的经验是不要指望 AI 自己去计算财务指标。AI 的强项是语义理解不是数值计算。比如“同比增速”“毛利率变化”这类指标应该让 AI 抽取字段然后用 Python 脚本去计算计算完再让 AI 生成解读。这样做有两个好处数值准确且计算口径一致。示例的流程是AI 读取公告原文抽取关键字段。字段传入parse_fin.py脚本脚本计算同比/环比变化。脚本输出计算结果到data/processed/fin.json。AI 再读取计算结果生成一段人类可读的解读写入研究报告草稿。我在这个 Skill 的提示词里加了一句如果公告里没有给出具体数字直接标记为缺失不要猜测。3.3 风控员盯舆情、盯异常波动、做风险提示风控员的工作是在情报员和研究员产出的基础上做一层主动的“异常检测”。它不是单纯把信息汇总而是根据预设的规则把风险事件按照严重程度分级触发告警。我给风控员 Skill 命名为RISK_MONITOR。它的输入有两个data/raw/里新增的舆情数据data/processed/里最新的财务数据。风控员输出的是当天的风险等级清单并标注哪些条目达到了人工复核标准。告警规则一开始不要定太复杂。我在第一版只定了五条出现“停牌”“立案”“退市”等关键词直接标记 level 3。单条新闻情感为负面且与关注标的强相关标记 level 2。财务指标出现 30% 以上异常波动标记 level 2。监管或行业政策直接点名关注标的标记 level 2。其他泛行业消息标记 level 0 或 1。规则越简单误报越少。不要一开始就想做一个完美的风控系统先把最核心的异常事件抓住再逐步上调灵敏度。3.4 资料管家把每次分析的成果沉淀进 Obsidian最后一位成员是资料管家负责把整个团队的产出整理成美观、可回溯的文档写进 Obsidian 的 vault。这个成员对应的 Skill 是DB_WRITER。为什么要接 Obsidian因为投研工作需要长期积累一个标的的分析不是一次性的而是持续迭代的。如果每天产出的报告只是躺在reports/目录里的 Markdown 文件很难和之前的分析做关联。Obsidian 的双链功能可以把同一家公司、同一行业的笔记串成一张知识网络。DB_WRITER做的事情很直接把当天的研报草稿、风险提示、数据汇总转换成带 YAML frontmatter 的 Markdown 文件写入 Obsidian vault 下的Inbox/目录。--- title: 2025-03-21 目标公司A 日报 tags: [投研, 目标公司A] date: 2025-03-21 creator: ai-research-team source: workbuddy --- ## 今日要点 ...写入之后我会在 Obsidian 里手动打几个标签后续复盘时用图的视图就能看到公司A、行业B、政策C之间的关系。这个环节让“AI 团队跑了一周但什么都没沉淀下来”的问题彻底消失。3.5 跨角色协作时的上下文传递每个成员是独立的 Skill但它们之间需要协作。协作方式我设计为文件传递而不是让 AI 之间直接对话。原因很简单文件传递可以留痕、可重跑、可排查而 AI 直接对话有随机性也可能出现上下文污染。完整数据流是这样的情报员把当天新闻写入data/raw/2025-03-21.json。研究员读取该文件提取财务相关字段调用脚本计算指标输出data/processed/fin.json。风控员读取 raw 和 processed 两个目录检查是否触发风险规则输出data/processed/risk.json。资料管家读取所有输出合并成日报写入 Obsidian。每个角色的输入输出都是固定的文件名和目录相当于给整个团队定了一套“接口协议”。后续要增加新角色只要它遵守这个协议就能无缝接入。4. 从“按一下跑一次”到“定时自运转”编排与通知4.1 用工作流把成员串起来WorkBuddy 里可以把多个 Skill 组合成一个 Flow。我在这里定义了一个命名为morning_report的工作流执行序列如下情报员增量采集凌晨时段的新信息。研究员读取新信息更新相关标的的财务对比表。风控员做风险分级把 level 2 以上的条目提取出来。资料管家生成早间日报并写入 Obsidian。晚上还会跑一次evening_risk流程更短情报员快速扫描晚间的新闻风控员只输出风险增量资料管家不重复生成日报只在发现高风险时追加一条风险提醒。工作流的颗粒度要有区别不能每天 24 小时都用完全一样的流程否则会产生大量重复报告。4.2 定时触发crontab 还是 systemd timerWorkBuddy 自身支持定时任务配置也可以用系统级别的定时器。我更推荐用 systemd timer因为它在 Linux 下更可靠还能记录每次运行的状态。先写一个 service 文件再写一个 timer 文件。workbuddy.service[Unit] DescriptionWorkBuddy Research Flow Afternetwork-online.target [Service] Userworkbuddy Groupworkbuddy Typeoneshot ExecStart/usr/local/bin/workbuddy run --flow morning_reportworkbuddy.timer[Unit] DescriptionRun WorkBuddy morning report at 07:30 Requiresworkbuddy.service [Timer] OnCalendar*-*-* 07:30:00 RandomizedDelaySec180 Persistenttrue [Install] WantedBytimers.target注意我加了RandomizedDelaySec180让任务在 07:30 到 07:33 之间随机启动。这样做的原因是如果多台机器同时定点触发会对信息源造成不必要的瞬时压力。别小看这个细节实际运行久了就会发现随机延迟极大降低了信息源限流的概率。4.3 结果输出与通知怎么让“待命”有意义如果 AI 团队每天生成几十条报告却没人看那“待命”就没有价值。所以通知策略必须有取舍。我给系统定了一条硬规则只有 level 2 以上的风险或者人工关注的标的出现信息更新时才向我的手机推送。日常日报和低风险信息只写入 Obsidian不主动推送。WorkBuddy 可以通过 webhook 实现通知。我的做法是写一个简单的脚本当风控员输出包含 level 2 以上条目时把内容发送到自己的企业微信机器人。这不复杂但执行后反馈非常明显以前我每隔十分钟就想刷新一次新闻现在只在手机收到提醒时才打开。人不用一直盯盘这就是 7×24 小时待命的意义。4.4 日志与断点恢复AI 团队也需要值班记录我强烈建议把 WorkBuddy 的日志输出到固定目录并做 logrotate 切割。实际操作中我会定期检查日志里的关键字确认某个流程是否卡住。排障命令如下tail -f /data/workbuddy/logs/workbuddy.log另外服务进程需要在异常退出后自动拉起。如果是长时间运行的 daemon 模式用之前写的 systemd service 配置加Restartalways就能实现。对于一次性 flow我则建议用 systemd timer 的Persistenttrue这样即使机器在当时关机了下次开机后也会补跑错过的任务。这一套组合拳下来团队才算真正变成了“7×24 小时待命”而不是“依赖人记得手动点击运行”。5. 运行一个月后的踩坑记录权限、幻觉、重复数据、时效性5.1 502 write EACCES不是 WorkBuddy 的锅是权限前面提过一次这个错值得单独拿出来细说。我见过很多人在社区里问这个问题第一反应都是怀疑 WorkBuddy 有 bug但 99% 的情况就是运行目录权限不足。当时我还遇到一个更隐蔽的情况明明已经把目录chown给了workbuddy用户但报错依旧。后来排查发现WorkBuddy 尝试向$HOME下某个隐藏目录写文件而这个$HOME对应的还是 root 的家目录。最后通过设置EnvironmentWORKBUDDY_HOME/data/workbuddy并确保所有子目录属主正确问题才彻底解决。建议一上来就把WORKBUDDY_HOME显式指定好不要依赖系统默认路径。5.2 指令幻觉AI 会给你编出一份从未存在的财报数据运行两周后我发现研究员输出的某家公司季度营收数据和历史财报里记录的完全对不上。刚开始以为脚本算错了后来仔细一看是 AI 在抽取字段时觉得原文数值不太合理于是自己“修正”成了它认为合理的数字。这个问题极其危险。我的对策有三层在全局指令里明确“禁止修改原始数值缺失就标记缺失”。在研究员 Skill 里增加校验脚本抽取出来的每个数字都和原始文本做正则比对不一致的直接丢弃。所有最终报告必须附来源说明没有来源的数据不会进入最终稿。这套规则上线后幻觉数据基本被拦截。但不要以为这样就万事大吉任何新增 Skill 都有可能出现类似情况所以校验脚本最好是通用的必须作为模板沉淀下来。5.3 重复采集与数据污染同一句话被分析了三遍定时任务跑得越勤重复采集的概率就越大。一条新闻被不同源转载情报员可能一天采集到五次。如果不处理重复研究员会基于同一份信息反复更新结论风控员也会重复触发同一条告警甚至出现“同一个风险事件被分析三遍”的情况。我的做法是在情报员脚本里加一个seen.json每条信息的指纹用 URL 加标题做哈希。只要指纹出现过后续就直接忽略。具体逻辑不复杂import json, hashlib, pathlib def make_fingerprint(url, title): return hashlib.sha256(f{url}|{title}.encode()).hexdigest() def is_seen(fp): seen_file pathlib.Path(data/seen.json) seen json.loads(seen_file.read_text()) if seen_file.exists() else [] if fp in seen: return True seen.append(fp) seen_file.write_text(json.dumps(seen)) return False这个文件只增不减跑了几个月后会越来越大建议定期只保留最近一个月内的指纹。5.4 时效性失控昨天的新闻今天早上还在报最后一个是时效性问题。情报员采集到的新闻包含发布时间但有些网站不会正确输出时间字段导致系统把旧闻当成新闻来采集。最典型的表现是某条周一晚上发布的政策解读周二早上团队还在推送“最新消息”。我给的解法比较简单粗暴所有输入数据必须带有可信时间戳来源没有明确发布时间的一律标记为“未知时间”并降级处理。研究员和风控员在生成结论时只允许使用发布时间在 24 小时以内的信息作为触发条件。超过 24 小时的可以归档但不能触发当日风险告警。这样能保证“7×24 小时待命”不等于“反复咀嚼冷饭”。一点体会整个系统跑下来最大的感受是AI 投研团队并不是“不需要人管了”而是把人的注意力从“整理信息”转移到了“复核结论”上。我每天花十分钟看日报盯一眼风险提醒偶尔手动修正几个字段剩下的时间全部留给真正需要判断力的事情。如果你准备自己动手搭我的建议是从最小闭环开始先只跑一个情报员加一个资料管家连着跑三天看看产出是否可靠再逐步加入研究员和风控员。不要一上来就铺十个八个角色AI 团队和人类团队一样人越多协作的复杂度越高。先把接口协议定清楚再扩大编制系统才能稳定运行。