聊完一份复盘，第二天还得翻聊天记录找昨天的数字，这是我设计股票 Agent 工作流时最想解决的麻烦。
所以这篇不继续比哪款模型更会点评市场。我想给 WorkBuddy 规定一个很小的交付物：每天留下三个文件，事实、解释、待验证问题各放一处。第二天能直接读回来比较。
我参与悟道数据的维护，下面使用悟道 MCP 的实际查询结果展示这个设计。数据接口已查询验证；WorkBuddy 部分是可照做的任务模板，不冒充某个客户端版本的端到端测试记录。
1. 先约定目录，再写提示词
建议给 WorkBuddy 一个单独的工作目录，例如：
text
reviews/
2026-09-08/
daily.md
facts.csv
pending.md三个文件分别解决三件事：
| 文件 | 内容 | 刻意不放的东西 |
|---|---|---|
| daily.md | 当日对照摘要、解释、对应事实 | 无来源的判断 |
| facts.csv | 两个交易日的数值、单位、来源、查询时间 | 涨跌预测 |
| pending.md | 待查的问题、需要的数据、验证条件 | 包装成事实的猜测 |
目录和字段是本文建议的报告格式，不是悟道接口原始响应结构。历史目录不覆盖；重新查询发现修订时另存一个带查询时间的版本。
2. 接入悟道 MCP，先做一次小查询
在 WorkBuddy 的 MCP 或连接器设置里添加远程服务。界面名称可能随版本变化，按当前客户端入口操作。
text
服务名称：wudao-stock-data
服务地址：https://stock.quicktiny.cn/api/mcp
请求头名称：Authorization
请求头值：Bearer YOUR_API_KEYYOUR_API_KEY 替换成自己的 Key。获取及当前接入说明见悟道数据官网 data.quicktiny.cn。不要把真实 Key 写进复盘文件或提交到 Git。
腾讯官方连接器文档支持添加自定义 MCP 连接器，也说明了认证配置。接入后先确认三件事：能列出工具、能实际调用交易日历、调用结果有返回日期。服务名称显示"已添加"不等于完成数据读取。
这一轮只需要三个查询工具：
- trading_calendar：确定本次复盘交易日和上一交易日。
- market_overview：读取上涨、下跌、平盘等市场宽度信息。
- limit_stats：读取触板、封板、炸板等统计。
先做完这个小流程，再加题材、公告或自选股。没必要一次把所有工具都塞进任务。
3. 用一组真实返回，定义事实表
写稿时查询了2026年9月7日与9月8日。以下是当时返回的收盘口径快照，之后服务可能修订数据。
| 指标 | 9月7日 | 9月8日 | 变化 |
|---|---|---|---|
| 上涨家数 | 3167 | 3417 | +250 |
| 下跌家数 | 2196 | 2026 | -170 |
| 封住涨停 | 93 | 72 | -21 |
| 炸板家数 | 19 | 37 | +18 |
| 封板率 | 83.04% | 66.06% | 约-16.98个百分点 |
上涨、下跌来自 market_overview；后三项统一来自 limit_stats。由原始计数计算：9月7日封板率为93/112，9月8日为72/109，展示时保留两位小数。
这组对照能支持一个有限的描述：上涨覆盖面扩大，但触板后的封板比例下降。它不能单独证明发生了哪一种资金行为，更不能直接推出下一交易日走势。
这里还有个真实的小坑：同次查询中，market_overview 附带的涨停数与 limit_stats 专项统计存在差异。本文没有把两个值混着用，而是让两日涨停相关指标都使用 limit_stats，并保留"跨工具统计不一致"的核查项。复盘程序应当暴露这种差异，不能悄悄选一个数。
建议 facts.csv 使用这些字段：
csv
metric,unit,previous_date,current_date,previous,current,delta,source_tool
rise_count,count,2026-09-07,2026-09-08,3167,3417,250,market_overview
fall_count,count,2026-09-07,2026-09-08,2196,2026,-170,market_overview
sealed_limit_up,count,2026-09-07,2026-09-08,93,72,-21,limit_stats
broken_limit_up,count,2026-09-07,2026-09-08,19,37,18,limit_stats这是精简示例。实际落盘还应增加 checked_at、returned_date、status 和 source_note，记录查询时间、接口返回日期、缺失状态和口径差异；不能把示例中的日期和数字当成每日默认值。
4. 可以交给 WorkBuddy 的完整任务
text
在我指定的 reviews 工作目录完成一次盘后复盘。
先确认目录访问权限。通过悟道 MCP 的交易日历确认最近一个
已收盘交易日 T 和上一交易日 P，禁止简单用日期减一。
分别查询 P、T 的 market_overview 和 limit_stats。
市场宽度取 market_overview；涨停统计统一取 limit_stats。
逐项核对返回日期。缺失写 missing，失败写 failed，
不要从搜索摘要或模型记忆补数，也不要覆盖已有历史文件。
请生成三个文件：
1. facts.csv：保存指标、单位、两日数值、差值、来源工具、
返回日期、查询时间、状态及口径备注。
2. daily.md：先放对照表，再写不超过三条观察。
每条观察引用 facts.csv 中的指标，区分事实和解释。
3. pending.md：写出尚不能确认的问题，每个问题附上所需数据、
支持条件、否定条件和当前状态。
封板率差值使用"百分点"，不要写成百分比增长。
跨工具数值不一致时保留差异，明确本次采用哪个来源。
不要修改自选股，不调用交易类操作。
完成后列出文件路径、实际使用日期、成功/失败的查询；
重新读取三个文件，检查是否为空、日期是否一致。这段任务的核心不是让 Agent 更啰嗦，而是给"完成"一个可检查的形状。如果当前环境没有文件权限，就先在对话里输出三个文件的内容并说明未落盘，不能口头宣称已保存。
5. 第二天只追问昨天留下的问题
第一次写完文件，还只是完成记录。下一交易日可以接着说：
text
先读取上一份 daily.md 和 pending.md，再查询本次交易日数据。
逐条更新昨天的问题：支持、否定、证据不足。
引用对应数值，保留旧记录；将新结果写进新的日期目录。
最后告诉我哪条原判断需要修改，不要只总结今天发生了什么。例如，对"上涨覆盖面扩大是否延续"，继续对照上涨、下跌家数；对"封板比例回落是否只发生了一天"，继续查同口径封板率。需要成交额、涨幅分布、题材结构才能回答的问题，就补对应工具查询；没查到仍然记作证据不足。
我更看重这一段，因为它让复盘不再每天重新写一篇小作文，而是接着昨天的问题往下做。
6. 换成其他 Agent，保留这份交付约定
这套设计的关键是可查询的数据、明确日期和可回读的文件，并不绑定 WorkBuddy。换成具备相应 MCP 接入及文件操作能力的 Codex、Claude 等客户端，可以沿用这三个交付物，认证和目录权限按各自文档配置。
悟道 MCP 在这里负责提供查询入口，Agent 把数据组织成文件；真正值得留下的，是自己的研究问题和每次修改判断的理由。
我的建议是先跑通两天，不着急上自动化。能打开文件核对数值，能发现日期错误，能把昨天的问题接着往下问，这个复盘助手才开始变得有用。
参考：腾讯 WorkBuddy 官方《连接器》文档 https://www.codebuddy.cn/docs/workbuddy/From-Beginner-to-Expert-Guide/Function-Description/Connector