1. 投顾队长的日常困局与AI工作台的破局思路做了六年投顾团队负责人我每天的工作节奏基本可以用四个字概括盯盘、复盘、沟通、写报告。早上八点半到工位先扫一遍隔夜外盘和宏观数据九点十五集合竞价开始盯自选池盘中要随时响应客户经理转过来的持仓疑问收盘后还得整理当日异动、更新策略观点、给团队做复盘纪要。说实话真正用来做深度研究和策略思考的时间被这些重复性事务挤压得所剩无几。团队里六个人每个人手里管着几百个客户信息同步靠微信群、文档靠手动整理、复盘靠个人记忆。这种模式在行情平稳的时候还能凑合一旦遇到板块轮动加快或者突发消息整个团队的响应速度就明显跟不上。我算过一笔账一个投顾每天花在信息收集、格式整理、重复回复上的时间保守估计在三个小时以上。这三个小时如果拿来做客户深度服务和策略打磨产出价值完全不是一个量级。后来我开始琢磨能不能用一套AI工作台把这些重复环节接管掉。市面上工具不少但要么太重、要么太散直到接触到WorkBuddy这套以Agent和MCP为核心的方案才算是找到了一个能真正落地的切入点。它的逻辑不复杂把日常重复的操作流程拆解成标准步骤交给AI Agent去执行人只负责判断和决策。配合MCP协议打通各个数据源和工具链再挂上自动化任务做定时触发基本上就形成了一个“人管方向、AI管执行”的协作模式。这篇文章我打算把这套工作台从零搭建到跑通自动化的完整过程拆开讲。五步上手是基础后面用自动化接管盯盘复盘才是真正省时间的地方。适合谁看如果你也是投顾、研究员、或者任何需要每天处理大量信息并输出观点的人这套思路可以直接抄作业。如果你只是想了解AI工作台和Agent到底能干什么前面的基础部分也能帮你建立完整的认知。2. 五步上手WorkBuddy从安装到跑通第一个Agent2.1 第一步环境准备与WorkBuddy安装WorkBuddy的安装本身不复杂但有几个前置条件需要提前确认。首先是操作系统Windows和Linux都支持我用的是Ubuntu 22.04的云主机做主力环境本地Windows机器做辅助。如果你习惯用Mac国际版同样可以跑安装包在官网都能找到。安装之前建议先把Node.js环境准备好版本建议在18以上。我试过用16的版本部分依赖会报错升级到20之后一切正常。Python环境也需要因为后面要跑一些数据处理脚本3.10以上的版本比较稳妥。# 以Ubuntu为例先更新系统包 sudo apt update sudo apt upgrade -y # 安装Node.js 20 curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash - sudo apt install -y nodejs # 验证版本 node -v npm -v # 安装Python 3.10 sudo apt install -y python3.10 python3.10-venv python3-pip环境准备好之后WorkBuddy的安装方式有两种一种是直接下载安装包另一种是通过包管理器安装。我推荐后者因为后续更新和依赖管理会方便很多。安装完成后第一次启动会引导你配置工作目录和基础参数这里建议把工作目录设在一个独立的盘符或者分区因为后续Agent产生的日志、缓存、临时文件会比较多混在系统盘里容易乱。注意安装过程中如果遇到权限报错不要直接加sudo了事先检查当前用户对目标目录是否有读写权限。我踩过一次坑用sudo安装之后普通用户跑不起来最后只能重装。2.2 第二步理解MCP协议与Agent的基本概念在继续往下走之前有必要把MCP和Agent这两个概念说清楚。MCP全称是Model Context Protocol你可以把它理解成AI世界的“USB接口标准”。以前每个AI工具要连数据库、连API、连文件系统都得单独写一套对接代码费时费力。MCP定义了一套统一的通信规范只要工具端实现了MCP ServerAI端实现了MCP Client两边就能即插即用。Agent则是执行具体任务的“数字员工”。一个Agent可以理解成一个有特定技能的程序比如“抓取行情数据”“生成复盘报告”“监控持仓异动”。Agent通过MCP协议去调用各种工具和数据源完成你交给它的任务。这两者的关系可以这样类比MCP是电话线和信号协议Agent是打电话的人。没有MCPAgent就是个孤岛没有AgentMCP就是一根空线。WorkBuddy的工作台本质上就是帮你管理这些Agent和MCP连接的控制中心。我在配置的时候先把常用的几个MCP Server挂上一个是本地文件系统的用来读写报告和日志一个是数据库的用来存持仓和交易数据还有一个是浏览器自动化的后面做信息抓取会用到。每个MCP Server的配置方式略有不同但核心都是填好连接地址和认证信息。{ mcpServers: { filesystem: { command: npx, args: [-y, modelcontextprotocol/server-filesystem, /home/user/workbuddy/data] }, database: { command: npx, args: [-y, modelcontextprotocol/server-sqlite, /home/user/workbuddy/data/portfolio.db] } } }提示MCP Server的配置信息通常放在一个JSON文件里WorkBuddy会自动读取。如果你不确定路径可以在设置界面里找到“MCP配置”入口直接编辑保存即可。2.3 第三步创建你的第一个Agent并定义任务环境通了、MCP挂上了接下来就是创建Agent。WorkBuddy里创建Agent的入口很直观点“新建Agent”之后会让你填几个关键信息Agent名称、任务描述、触发方式、以及要调用的MCP工具。我的第一个Agent是“每日行情摘要生成器”。任务描述写的是每天收盘后从数据库读取当日自选池的涨跌幅数据从文件系统读取前一天的复盘笔记然后生成一份包含异动说明和明日关注点的摘要文档。这里有个关键点任务描述要写得足够具体但不能太死板。太笼统了Agent不知道干什么太细了又失去了灵活性。我的经验是把“输入是什么、处理逻辑是什么、输出是什么”这三件事说清楚就够了。比如上面这个任务输入是数据库里的行情数据和文件系统里的笔记处理逻辑是“对比前一日、找出异动、提炼关注点”输出是一份Markdown格式的摘要。创建完成后可以先手动触发一次看看Agent的执行日志。第一次跑大概率会有问题比如数据格式不对、路径找不到、输出不符合预期。这很正常根据日志调整任务描述或者MCP配置就行。我第一个Agent调了三次才跑通主要是数据库字段名和Agent理解的不一致改了一下映射关系就好了。2.4 第四步配置Skill让Agent具备专业能力Agent跑通基础流程之后你会发现它虽然能干活但干得不够“专业”。比如生成行情摘要时它不知道什么是“有效异动”也不知道“关注点”应该从哪些维度提炼。这时候就需要用到WorkBuddy的Skill功能。Skill可以理解成给Agent安装的“专业技能包”。你可以自己写Skill也可以用社区里别人分享的。我写了一个“投顾复盘Skill”里面定义了几个关键规则涨跌幅超过3%算异动、成交量放大超过50%算异常、连续三天跑输大盘要重点标注。这些规则写进Skill之后Agent生成摘要时就会自动按照这个标准来筛选和标注。# 一个简单的Skill示例判断是否属于有效异动 def is_significant_move(change_pct, volume_ratio, benchmark_change): 判断个股是否属于有效异动 change_pct: 个股涨跌幅 volume_ratio: 成交量比值 benchmark_change: 基准指数涨跌幅 if abs(change_pct) 3.0: return True, 涨跌幅超过3% if volume_ratio 1.5: return True, 成交量放大超过50% if abs(change_pct - benchmark_change) 2.0: return True, 相对基准偏离超过2% return False, Skill写完之后在Agent配置里挂上就行。这里有个小技巧Skill的规则不要一次写太多先写最核心的三五条跑一段时间之后再根据实际效果增补。我一开始写了十几条规则结果Agent生成的内容过于冗长反而不好用。精简到五条之后摘要质量明显提升。2.5 第五步跑通完整流程并验证输出五步走到这里基本的工作台已经成型了。最后一步是跑通完整流程并验证输出。我建议选一个交易日从收盘后开始手动触发整个链路数据抓取Agent先跑把行情数据入库然后摘要生成Agent跑读取数据并生成报告最后用文件系统MCP把报告写到指定目录。验证的时候重点看三个地方一是数据准不准跟行情软件对一下二是逻辑对不对异动判断是否符合预期三是格式规不规范输出能不能直接给团队用。我第一次跑通的时候数据没问题但格式比较乱后来在Skill里加了一个输出模板强制Agent按照固定格式生成就整齐多了。整个五步走下来如果顺利的话一个下午就能搞定。我因为中间踩了一些坑前后花了大概两天时间。但这两天的投入换来的是后面每天至少省出两个小时怎么算都划算。3. 用自动化接管盯盘复盘从手动触发到定时执行3.1 自动化任务的核心逻辑与触发机制手动触发Agent只能解决“偶尔用一下”的需求真正要省时间必须让Agent自己跑起来。WorkBuddy的自动化功能支持多种触发方式我用得最多的是定时触发和事件触发。定时触发就是设定一个时间点到点自动执行。比如每个交易日15:30触发数据抓取Agent16:00触发摘要生成Agent。事件触发则是监听某个条件条件满足时执行。比如当某只持仓股跌幅超过5%时自动触发预警Agent。这两种触发方式可以组合使用。我的配置是定时触发负责日常流程事件触发负责异常监控。日常流程保证每天的基础工作自动完成异常监控保证突发情况能及时响应。配置自动化任务的时候有一个参数很容易被忽略超时时间。Agent执行任务时如果卡住了没有超时设置就会一直挂着占用资源。我一般把超时设在5到10分钟具体看任务复杂度。数据抓取这种轻量任务设5分钟报告生成这种复杂任务设10分钟。# 自动化任务配置示例 tasks: - name: 每日行情数据抓取 trigger: type: cron expression: 30 15 * * 1-5 # 周一到周五15:30 agent: market_data_fetcher timeout: 300 # 5分钟超时 retry: 2 # 失败重试2次 - name: 持仓异动预警 trigger: type: event condition: portfolio.change_pct -5 agent: alert_agent timeout: 60 retry: 1注意cron表达式的格式是“分 时 日 月 周”周一到周五用1-5表示。如果你不确定表达式写得对不对可以用在线工具验证一下写错了不会报错但任务不会触发。3.2 盯盘自动化实时监控与预警推送盯盘这件事人盯着容易疲劳而且不可能同时盯几百只股票。用Agent来做实时监控效率完全不一样。我的做法是让一个Agent每隔5分钟扫描一次自选池按照预设规则判断是否需要预警。预警规则我分了三个级别一级是“关注”比如涨跌幅在2%到3%之间或者成交量温和放大二级是“提醒”涨跌幅3%到5%或者触及关键均线三级是“紧急”涨跌幅超过5%或者出现重大公告。不同级别对应不同的推送方式一级只记录日志二级发消息通知三级直接打电话。这里有个细节Agent扫描的频率不要设得太高。我一开始设了1分钟一次结果数据接口频繁被限流反而影响了正常使用。后来改成5分钟一次既保证了及时性又不会给接口太大压力。推送渠道我用的是企业微信的机器人接口配置很简单在群里添加一个机器人拿到Webhook地址填到Agent的推送配置里就行。消息格式建议用Markdown这样在手机上看也清晰。# 预警推送示例 import requests def send_alert(level, stock_name, message): webhook_url https://qyapi.weixin.qq.com/cgi-bin/webhook/send?keyyour_key level_map { 关注: info, 提醒: warning, 紧急: critical } content f【{level}】{stock_name}\n{message} payload { msgtype: markdown, markdown: { content: content } } requests.post(webhook_url, jsonpayload)3.3 复盘自动化数据整理与报告生成复盘是投顾每天的重头戏也是最耗时的环节。传统做法是打开行情软件一个个翻看自选股手动记录异动然后整理成文档。这套流程我做了六年闭着眼睛都能走完但确实浪费时间。用Agent接管之后流程变成了这样收盘后15:30数据抓取Agent自动从数据源拉取当日行情写入本地数据库16:00复盘Agent启动从数据库读取数据按照Skill里定义的规则筛选异动个股生成复盘报告16:10报告通过文件系统MCP写入指定目录同时推送一份到团队群。报告的内容结构我固定了几个模块市场概况、自选池表现、异动个股分析、明日关注点、风险提示。每个模块的数据来源和生成逻辑都在Skill里定义好了Agent只需要按部就班执行就行。这里有个经验报告模板不要写得太死。我一开始把模板写得很细结果遇到特殊行情时Agent生成的内容很生硬。后来改成“框架固定、内容灵活”框架保证结构统一内容让Agent根据实际情况填充效果好很多。# 复盘报告模板示例 ## 市场概况 - 主要指数涨跌幅{index_data} - 成交量变化{volume_data} - 北向资金流向{northbound_data} ## 自选池表现 - 上涨家数{up_count} - 下跌家数{down_count} - 平均涨跌幅{avg_change} ## 异动个股分析 {anomaly_stocks} ## 明日关注点 {focus_points} ## 风险提示 {risk_alerts}3.4 自动化流程的监控与异常处理自动化跑起来之后最怕的就是“悄无声息地挂了”。Agent执行失败如果没有通知你可能过了好几天才发现报告没生成。所以监控和异常处理必须配齐。我的做法是每个自动化任务都配一个“心跳检测”。任务执行成功时写一条日志如果超过预定时间没有日志就触发告警。告警方式跟预警推送一样走企业微信机器人。异常处理分两种情况一种是可重试的比如网络超时、接口限流这种配置自动重试就行另一种是不可重试的比如数据格式变了、数据库连不上这种需要人工介入。我在Agent里加了一个错误分类逻辑可重试的错误自动重试不可重试的错误直接推送告警并暂停任务。# 错误分类与处理示例 def handle_error(error, task_name): retryable_errors [Timeout, RateLimit, ConnectionError] non_retryable_errors [DataFormatError, DatabaseError, AuthError] error_type type(error).__name__ if error_type in retryable_errors: return retry elif error_type in non_retryable_errors: send_alert(紧急, task_name, f任务失败{str(error)}) return pause else: send_alert(提醒, task_name, f未知错误{str(error)}) return retry提示日志一定要保留至少30天。我遇到过一个问题某天报告生成异常但当时没发现一周后想排查日志已经被清理了只能从头复现。后来把日志保留期改成90天再也没出现过这种情况。4. 常见问题与排查技巧实录4.1 Agent执行失败的高频原因与解决方法Agent执行失败是家常便饭尤其是刚配置好的时候。我把遇到过的问题整理了一下高频原因主要有这么几类第一类是路径问题。Agent找不到文件或者目录报错信息通常是“FileNotFoundError”或者“Permission denied”。解决方法很简单检查MCP配置里的路径对不对以及当前用户有没有读写权限。我踩过一次坑路径里用了中文Agent识别不了改成英文就好了。第二类是数据格式问题。Agent从数据库或者API拿到数据后解析失败。常见原因是字段名对不上、数据类型不匹配、或者数据为空。解决方法是在Agent里加一层数据校验拿到数据先检查格式不对就报错并记录原始数据方便排查。第三类是认证问题。调用外部API时Token过期或者权限不足。这个没什么好说的定期检查Token有效期该续期续期该换Key换Key。第四类是资源问题。Agent跑着跑着内存不够了或者CPU占用太高被系统杀了。这种情况一般出现在处理大量数据的时候解决方法是优化代码分批处理或者给Agent分配更多资源。问题类型典型报错排查方法解决措施路径问题FileNotFoundError检查MCP配置路径和权限改用英文路径确认读写权限数据格式JSONDecodeError打印原始数据检查格式加数据校验层记录原始数据认证问题AuthError检查Token有效期和权限续期Token更换Key资源问题MemoryError查看系统资源占用分批处理增加资源分配4.2 MCP连接不上的排查思路MCP连接不上是另一个高频问题。表现是Agent启动时报“MCP Server not reachable”或者“Connection refused”。排查思路可以按这个顺序来先确认MCP Server有没有启动。有些MCP Server是独立进程需要手动启动或者配置成系统服务。我一开始不知道以为配置好就行结果Agent一直连不上后来发现Server根本没跑。再确认端口和地址对不对。MCP Server默认监听本地端口如果配置里写了远程地址要确保网络能通。我试过用云主机跑Server本地Agent连不上排查了半天发现是防火墙没放行端口。然后确认认证信息。有些MCP Server需要Token或者密钥配置里没填或者填错了都会连不上。这个看Server的日志最直接日志里会明确说“Unauthorized”或者“Invalid token”。最后确认版本兼容性。MCP协议还在演进不同版本的Server和Client可能有兼容问题。我遇到过Server是旧版、Client是新版连上了但功能不正常。统一升级到最新版就好了。# 检查MCP Server是否在运行 ps aux | grep mcp-server # 检查端口是否监听 netstat -tlnp | grep 3000 # 测试连接 curl http://localhost:3000/health4.3 自动化任务不触发的排查清单自动化任务配好了但不触发这个问题最让人头疼因为表面上一切正常就是不动。我整理了一个排查清单按顺序过一遍基本能定位问题检查cron表达式是否正确。最常见的是“分 时 日 月 周”的顺序搞反了或者用了不支持的语法。检查任务是否被禁用。WorkBuddy里每个任务都有启用/禁用开关有时候不小心点到了禁用任务就不会触发。检查时区设置。如果服务器时区和你预期的不一样任务触发时间会偏移。我遇到过服务器是UTC时区我按北京时间配的结果差了8小时。检查依赖任务是否完成。如果任务B依赖任务A的输出任务A失败了任务B可能就不会触发。检查日志。WorkBuddy的任务日志会记录每次触发的详细信息包括触发时间、执行结果、错误信息。看日志是最直接的排查方式。注意如果任务配置了重试失败后会等待一段时间再重试。如果重试次数用完了还是失败任务会进入“暂停”状态需要手动恢复。我建议给关键任务配一个“失败告警”这样即使暂停了也能第一时间知道。4.4 性能优化与资源占用的实操心得WorkBuddy跑久了资源占用会慢慢上去。我观察过主要占用来自三个方面Agent进程、MCP Server、以及日志和缓存文件。Agent进程方面建议给每个Agent设置内存上限防止某个Agent跑飞了把系统拖垮。WorkBuddy支持在Agent配置里设资源限制我一般给单个Agent设512MB到1GB具体看任务复杂度。MCP Server方面如果同时挂了很多Server可以考虑合并一些功能相近的。比如文件系统和数据库可以合并成一个Server减少进程数量。日志和缓存方面定期清理是必须的。我写了一个清理脚本每周跑一次删除30天前的日志和7天前的缓存。这个脚本本身也可以做成一个Agent让WorkBuddy自己管理自己。#!/bin/bash # 清理脚本示例 # 删除30天前的日志 find /home/user/workbuddy/logs -name *.log -mtime 30 -delete # 删除7天前的缓存 find /home/user/workbuddy/cache -type f -mtime 7 -delete # 清理数据库中的历史数据保留90天 sqlite3 /home/user/workbuddy/data/portfolio.db DELETE FROM market_data WHERE date date(now, -90 days);5. 从单点自动化到团队协作的扩展思路5.1 多Agent协作的编排方式单个Agent能解决的问题有限真正复杂的工作流需要多个Agent协作。WorkBuddy支持Agent之间的编排你可以定义一个工作流让Agent A的输出作为Agent B的输入依次执行。我的复盘工作流现在有四个Agent数据抓取Agent、数据清洗Agent、分析Agent、报告生成Agent。数据抓取Agent从外部接口拉数据数据清洗Agent做格式化和去重分析Agent按照Skill规则筛选异动报告生成Agent输出最终文档。四个Agent串行执行前一个成功了后一个才开始。编排的时候要注意错误传递。如果数据抓取失败了后面的Agent不应该继续跑否则会基于空数据生成错误的报告。我在工作流里加了条件判断前一个Agent返回失败时整个工作流终止并发送告警。# 工作流编排示例 workflow: name: 每日复盘流程 steps: - agent: data_fetcher on_success: data_cleaner on_failure: alert - agent: data_cleaner on_success: analyzer on_failure: alert - agent: analyzer on_success: report_generator on_failure: alert - agent: report_generator on_success: notify on_failure: alert5.2 团队共享与权限管理工作台搭好之后团队里其他人也想用这时候就需要考虑共享和权限。WorkBuddy支持多用户模式每个用户可以有自己的Agent和工作目录也可以共享公共的Agent和Skill。我的做法是把基础的Agent和Skill设为公共比如数据抓取、报告生成这些通用能力所有人都能用。个性化的部分比如每个人的自选池、预警规则各自独立配置。这样既保证了基础能力复用又保留了个性化空间。权限管理方面建议按角色分配。管理员可以创建和修改Agent普通用户只能使用和查看。我吃过一次亏团队里有人误删了一个关键Agent导致第二天复盘没跑成。后来把权限收紧只有我和另一个负责人有修改权限问题就没再出现过。5.3 后续可扩展的方向与个人建议这套工作台跑顺之后可扩展的方向其实很多。我目前正在尝试的有两个一个是把客户沟通记录也接入进来让Agent在生成复盘报告时能结合客户最近的关注点做个性化提示另一个是接入更多的数据源比如公告、研报、舆情让分析维度更丰富。如果你也想搭一套类似的系统我的建议是先从最简单的场景开始跑通一个Agent再逐步扩展。不要一上来就追求大而全那样很容易卡在某个环节上最后不了了之。我见过太多人兴致勃勃地开始配了一堆Agent和MCP结果因为一个连接问题没解决就放弃了。另外自动化不是万能的。Agent能帮你省掉重复劳动但判断和决策还是得人来。我现在的模式是Agent负责把数据整理好、把异动标出来、把报告初稿写出来我负责看报告、做判断、给团队定方向。这样既享受了自动化的效率又没有丢掉人的核心价值。最后分享一个小技巧定期回顾Agent的执行日志看看哪些任务经常失败、哪些任务耗时最长、哪些任务其实没必要跑。我每个月会花半小时做这件事每次都能发现一些可以优化的地方。工作台不是搭好就完了它需要持续维护和迭代才能越用越顺手。