股票工作台

为什么做它

个股研究最耗时间的不是写结论，而是反复做同样的事：收集数据、对照自己的持仓、回头核对当初为什么这么判断。聊天工具能给答案，但答案不会自己变成报告，也不知道我现在手里有什么、账上还剩多少现金。

股票工作台把这条链路放进同一个地方。研究由 Agent 完成，结论落成一份带时间点的报告；持仓、挂单和成交记在同一本账上；下一次研究直接接着账本往下走。

一次研究怎么走

1. 在看板里选一只股票，或者从机会扫描的候选里挑一只。
2. 发起完整分析，也可以输入自己的问题。
3. Agent 按需读取方法手册和参考资料，采集行情与资料，做分析和决策，写成报告。运行中只显示研究阶段和子任务标题，不暴露内部草稿。
4. 报告里的买卖区间同步到看板。我按自己的判断决定要不要操作，并把真实成交记回账本。

实现方案：一个 Agent 是怎么做研究的

产品页面上它是「点一下、等十几分钟、出一份报告」。这一节把它拆开，写清楚这个 Agent 是怎么搭的、每一步在想什么、在干什么。

不是聊天窗口，是一条可恢复的研究流水线

每次完整分析是一个 Cloudflare Workflow 任务：Durable Object 保存研究状态，每轮动作执行前后各写一次检查点到 R2。模型超时、供应商 502、部署重启，都能从检查点接着跑；因网络类故障暂停的任务，五分钟后由定时任务自动续跑（最多三次）。页面只会看到「分析进行中」。

没有轮数、token、搜索次数或研究时长的预算上限。停下来的原因只有三种：方法跑完了、真实故障暂停了、或者我叫停了。让「研究做没做完」而不是「预算用没用完」决定什么时候停。

方法手册就是提示词的主体

Agent 的系统上下文里放的不是几句角色设定，而是完整的方法手册：一千多行的主手册（五环节决策机器：场景识别 → 全维抓取 → 分析 → 决策 → 报告），加上项目的执行约定。任务开始时锁定手册版本，本次研究全程用同一版。另有 24 篇参考资料（数据口径的坑、回测记录、字段对照等）平时只给目录，Agent 用 methods.read 按需分页读取。手册怎么写，它就怎么做；手册更新一版，行为跟着变，不用改代码。

程序和模型各管一半

这是整套设计里最重要的一条线。原则是：数据能决定的判断由程序按规则表算，程序算不了的才交给模型。

程序负责（规则，可复核）	模型负责（判断，要给依据）
真实时钟、标的身份核对	场景判定：是否海外绑定、归哪个板块指数、选哪些国际锚
真实账本：现金、持仓、成本、T+1 可卖数量	选哪些可比同行、用什么检索词、读哪几篇公告正文
按数据门清单自动抓行情、日线、财报、公告、资金流、估值历史，逐项核对数量门槛	把事件串成因果链，标注证据
机械精算：技术指标、估值分位、同行对比、订单整手与价格档、风险精算	基本面、催化剂强度这类规则覆盖不了的维度
按规则表算趋势/资金/相对强弱等状态；三情景概率按回测校准的权重查表	多空裁决：回答四个问题，给出最终动作
校验：结构、证据、数字、方法覆盖、订单，指出问题并给出修法	决定是否接受数据缺口、怎么披露

校验只指出问题、给修复方式，不代写结论。模型写错的数字不会被悄悄改对，只会被打回重做。

从请求到报告，每一步干了什么

1. 动手之前，程序先跑一遍：查真实时钟、核对标的身份、读真实账本、按数据门清单自动抓数据、查历史报告。模型第一轮拿到的已经是「时间、身份、账本、数据都在手边」的状态，不为「现在几点」「这是哪只股票」浪费轮次。
2. 场景判定（scene）：模型第一个动作必须是单独提交场景判定——是否海外绑定、A 股标的归哪个板块指数、海外标的选哪些美股/港股锚。这是程序替不了的判断；声明之后，程序按声明去抓国际数据。
3. 采集（collect）：程序自动抓的部分照清单来；模型补它才决定的部分——政策面背调的检索词、按主题搜索、决定读哪几篇公告正文。数据门查的是实际结果而不是调用次数：资金流必须东财和新浪两个来源都实际失败才允许登记例外；估值历史不足 1000 个交易日，不能拿别的数据凑数。
4. 预处理（preprocess）：技术指标、财务指标、估值分位、同行对比由程序完成机械精算，模型只消费结果。采集没完成时不允许提前算衍生指标。
5. 分析（analyze）：模型写下诊断和因果链，每条论点挂上证据 ID；重要判断委派 BULL/BEAR 对抗研究（见下一节）。每个工具返回都存成带 ID 和哈希的证据，此后的推理只能引用这些证据。
6. 决策（decide）：先逐项判断，不写大文章。报告级判断（论点、风险、多空、未决问题）和每个标的的判断（持仓状态机、买卖区间、三情景、连续跟踪、路径）分批提交，程序即时核对：区间锚点合不合法、概率和评分是否一致；订单精算（整手、价格档、可卖数量、现金与风险）直接算好返回。
7. 报告（report）：程序把全部判断合并成完整报告，一次性核验，自动刷新行情复核落点，然后发布归档。模型在最后一步只交标题、结论和三问答案，没有机会在成稿时引入新的数字。

多空对抗：让反方先说话

数据门全部通过后，主 Agent 可以委派 BULL（看多）和 BEAR（看空）两个独立研究：它们共享同一份事实基线，互相看不见对方的论证，也看不到主候选。各自返回全部有依据的论据——不限条数，但每条必须引用真实存在的证据。最后由主模型回答四个问题裁决：最强的卖出理由是什么？如果判断错了，最可能错在哪？哪些证据互相冲突？反方是否足以推翻当前判断？正文新增不会自动作废已有论证，但同一证据内容变化会让依赖它的专项失效重做。

数字和引文过不了关就发不出去

• 报告里出现的数字（含「万/亿/%」换算）必须能在已观察数据、计算结果或已读正文里找到出处，否则直接阻断发布。
• 引用原文必须逐字匹配；对不上时，程序会把来源里数字附近的原文段落附在错误反馈里。
• 引文核对、数字断言、风险依据、方法覆盖、订单精算各有独立检查，任何一项不过都到不了归档。
• 真实数据缺口必须如实披露：报告可以带着「明确写出的缺口」发布，但不能给出可执行订单，也不能假装没缺口。

报告之外：连续跟踪、快速复核和盘中核对

• 连续跟踪：判断材料自动带上历史报告和未成交挂单。有旧报告就必须写清「旧计划→实际→变化→处理」；现价越过旧区间要判计划失效；每笔挂单给出保留/改价/撤销，保留或改价后的挂单必须落在本轮区间内。
• 快速复核：盘中的例行复核以当天完整报告为基线。程序先刷新数据并算出一张变化清单——落点迁移、触及止损、资金转向、新公告……每项标着最低响应级别——模型逐条回应，不重复采集基线已有的财报和正文。业绩预告、重组、增减持这类论点级新信息不当场裁定：先给保护性动作，转完整分析处理。
• 盘中核对计划：完整分析定了计划之后，盘中用「核对计划」检查强制规则和路径是否触发，不调用模型；规则提示与报告动作冲突时，再决定要不要重新做完整分析。

失败怎么办

模型传输失败先在同一次调用内退避重试，流式响应断了就改非流式；主模型持续失败时自动切到备用模型完成这一步。任务暂停时，页面直接显示暂停原因和继续按钮——平台故障不会伪装成「模型没响应」。检查点让任何一次中断都能续跑：续跑保留已采集的资料和已完成的阶段，不重启整个流程。

实际开销

按最近一次真实任务：一次完整分析约 12 分钟、主模型 24 次调用，输入约 300 万 token（约一半命中缓存）、输出约 9.5 万 token。早期版本光写报告就要 20 分钟以上——因为整份报告写完才检查，错一处重来整份。改成「先逐项判断再生成报告」之后，生成报告本身只占 1 分钟左右。

和常见做法有什么不同

• 报告和账本互相校验：建议不是凭空给的，仓位、现金和成本都来自账本，风险按账本核验。
• 区间只有一套算法：报告和看板共享同一套买卖区间识别，不会出现两处数字对不上。
• 发现和深挖分开：机会扫描做横向比较、只回答「值得研究吗」；深挖才落到价位和股数。前者便宜、后者精细，各管一段。
• 模型可以换：支持 DeepSeek、OpenAI、Kimi、MiniMax 等多家供应商，主模型失败时自动切到备用模型完成这一步。

使用边界

• 不连接券商，不自动下单。
• 报告、计划和任务完成都不会改变持仓；持仓只随我确认的实际成交或明确补录而变化。
• 行情只在 A 股和港股开市窗口内抓取。
• 这是我自己的研究工具，输出不构成投资建议。

技术底座

前端和 API 跑在 Cloudflare Workers 上，业务数据放 D1，完整分析由 Workflows 分步执行，研究状态由 Durable Object 持有、检查点写入 R2，长报告和原始归档也存 R2。