长程投资任务
长程投资任务不是"自动交易机器人"。Bastix 用 TAP(可持续运行策略单元)把一个投资想法拆成研究→观察→持仓→复盘四阶段,按交易日无人值守地做研究、观察与整理,事件溯源地积累长程记忆;需要对外执行的动作统一回到主会话由你决定。它只做研究不下单、不连接券商、无统一回测。
大多数 AI 工具是"一问一答":你问一次,它答一次,然后忘记。投资研究不是这样工作的——一个想法需要连着好几周盯着、反复观察、记住上次的判断、到复盘时回看当初为什么这么想。
Bastix 的差异化能力就在这里:长程投资任务。它由 TAP(可持续运行策略单元) 承载,可以无人值守地按每个交易日定时运行,把一个投资想法沿着研究 → 观察 → 持仓 → 复盘四个阶段持续推进,并用事件溯源的方式把每一步观察记下来。12
但请先记住这条边界,它贯穿全文:无人值守的持续任务只做研究、观察和整理,不自动下单、不连接券商。 需要对外执行的动作,统一回到你在场的主会话由你决定。13
它解决的问题:一次性提问撑不起长期研究
| 一次性 AI 问答的问题 | 长程投资任务怎么承接 |
|---|---|
| 每次重新开始,不记得上次结论 | 事件溯源记忆:当前状态由历次更新累积推出,而非只看最近几句对话2 |
| 你得每天手动来问一遍 | 无人值守:按交易日从盘前到盘后定时运行,不需要你守着4 |
| 研究、盯盘、复盘各用一套工具,割裂 | 同一个单元贯穿研究→观察→持仓→复盘四阶段,一条主线2 |
| 说"帮我盯着",它却擅自替你操作 | 持续任务只研究整理,对外动作回主会话,你在场再决定13 |
长程投资任务不是让 AI 替你交易,而是让 AI 替你持续做功课:把该看的看了、该记的记了、该提醒的提醒了,最后把判断交回给你。
TAP 是什么:可持续运行的策略单元
TAP(可持续运行策略单元)是长程投资任务的载体。在产品事实登记中,TAP 与定时触发标为 production(生产可用):策略定义、运行记录、启动/停止与调度链路都存在。1
它具备这样几个特征:
- 可并存多个 TAP。 通过
tap_id区分,同一个智能体可以同时拥有"盘前""盘中""复盘"等多个相互独立的 TAP,各自有自己的触发时点。5 - 可启动、可停止、留运行记录。 启动/停止链路与运行记录(
tap_runs)存在,每次运行的状态可被回看。16 - 由调度模块按时点火。 定时触发由调度模块驱动,按交易日运行。1
- 单次推理有更充足的步数预算。 平台已提高持续任务单次推理的步数预算,让需要多步推理才能完成的长任务更不容易中途因步数用尽而提前结束。7
四阶段生命周期:研究 → 观察 → 持仓 → 复盘
长程投资任务最像"长期研究"的地方,是它给每个投资事件一条受控的四阶段生命周期。在智能体的工作记忆工具中,stage(阶段)是一个受控枚举,只有这四个值:研究、观察、持仓、复盘——没有"关闭"。2
| 阶段 | 这一步在做什么 | 记忆怎么推进 |
|---|---|---|
| 研究 | 建立一个投资事件:为什么关注、看什么、判断依据 | mode=create 开一个新事件2 |
| 观察 | 按交易日追加观察与进展,看假设是否还成立 | mode=update 追加一条观察2 |
| 持仓 | 记录围绕该事件的策略目标仓位意图与理由 | 阶段推进;仓位写入见下节的沙箱账本23 |
| 复盘 | 回看整条事件流,总结当初判断对在哪、错在哪 | 阶段推进到复盘,事件流完整可回溯2 |
它是事件溯源的:每个事件是一条持续更新的流水,当前状态由历次更新推出来,而不是只凭最近几句对话。2 这正是"长程记忆"的实质——每轮运行开始、判断今日重点前,先读取当前仍未关闭的事件及其更新流,再决定今天观察什么。2
这条"研究→观察→持仓→复盘"的主线,就是 Bastix 对"长期持有一个投资逻辑并持续跟踪"的产品化表达。
持续任务和主会话:各归其位
Bastix 把智能体工作分成两种场景,从第一句话起就按各自方式工作:8
- 主会话 —— 你在场时的即时对话。需要产生对外影响的动作,在这里由你决定。
- 持续任务 —— 无人值守、定时运行的后台任务。它专注研究本身。
关键分工是:定时运行的持续任务只做研究、观察与整理,不再自行发起对外动作;需要对外执行的动作统一回到主会话、由你在场时进行。 智能体的操作说明里已明确"持续任务不用于直接交易",避免把定时任务误当成自动下单的通道。3
这一分工不是文案口号,而是有代码级依据的:在 tap:{tapId} 会话里,写入目标仓位(set_target)和重置基准(reset)会被门禁拒绝——TAP 只做观察与判断,调仓主张写进结论文本回到主会话,由主会话决定是否执行。9
持仓怎么记:沙箱策略账本,不是券商持仓
当长程投资任务推进到"持仓"阶段,涉及的仓位记录写在沙箱内的策略仓位账本里,不是券商账户。10
- 账本记录的是策略目标仓位意图(标的、比例 −1..1、时间、理由),不是真实成交。1011
- 当前占比、净值等是按"份额法"用目标快照 + 日线收盘价实时重建出来的,以虚拟初始资金
nav0 = 1为基准、无量纲——不是账户里真实存在的金额。详见持仓分析功能页。12 - 仓位随价格自然漂移,系统不会因此自动买卖或再平衡。13
换句话说:长程投资任务能帮你持续记录和跟踪一个策略的仓位主张与漂移,但它不接管你的资金、不连接券商、不下真实订单。14
一个长程投资任务大致长什么样
以下为说明四阶段结构的示意,标的与数字均为占位、非真实运行数据。
tap: 某行业景气度跟踪 # 一个可并存的 TAP,按 tap_id 区分
trigger: 每交易日盘后 # 定时触发,无人值守
lifecycle:
- stage: 研究 # create:为什么关注、看什么、判断依据
- stage: 观察 # update:按交易日追加观察,检验假设
- stage: 持仓 # 记录策略目标仓位意图与理由(写回主会话执行)
- stage: 复盘 # 回看整条事件流,总结对错
memory: 事件溯源 # 当前状态由历次更新累积推出
external_action: none # 持续任务不自动下单;对外动作回主会话这个结构的价值在于:它把"长期跟踪一个投资逻辑"这件本来靠人脑记忆和手工笔记完成的事,变成一条可回溯、可交接、有明确边界的研究流水。
Bastix 在长程投资任务上明确不做什么
- 不自动下单、不连接券商。 内置能力未发现券商连接或下单 API;持续任务只做研究、观察与整理。143
- 不是自动交易机器人。 "自动交易""自动下单""券商同步持仓"是禁止声明。15
- 没有现成统一回测引擎。 用户只能在受限代码工具中自行组织研究计算。16
- 不保证结论正确或可盈利。 模型输出可能出错,不构成投资建议。17
什么样的人适合用长程投资任务
- 有一套自己的投资逻辑,需要连续几周跟踪它是否还成立的人;
- 希望盘前/盘中/盘后各有一个定时研究任务分工运行的人;
- 重视复盘、想让每次判断都有据可查的人;
- 明确知道决策和交易由自己负责、只需要 AI 持续做功课的人。
如果你要的是"把钱交给 AI 自动赚钱",Bastix 不是这样的产品,也不会这样宣称。
相关阅读
- 自然语言生成交易策略:先把想法拆成可检查的研究骨架,再交给长程投资任务承接。
- 持仓分析功能页:沙箱策略仓位账本的口径与真实内部模型。
- 交易复盘指南:把"复盘"阶段做深的方法。
- 投研工作流:长程投资任务在整体投研流程中的位置。
Footnotes
-
Bastix《公开产品事实登记》0.1.0(取证日期 2026-08-14)"TAP(可持续运行策略单元)与定时触发"为
production:策略定义、运行记录、启动/停止与调度链路存在;无人值守任务只做研究、观察和整理,不等于自动下单。证据:apps/agent-api/src/sandboxes/portfolio-db.ts、apps/server/src/scheduler、v1-0-9.mdx。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 -
apps/agent-api/src/mastra/prompts/capability-intros.ts(tap_memory_manager):用事件溯源管理沙箱内投资事件,每个事件是一条持续更新的流水,当前状态由更新推出;stage生命周期为"研究→观察→持仓→复盘"受控枚举,仅这四值、不含"关闭";mode=create开新事件、mode=update追加、传stage则推进阶段;每轮开始先mode=query读未关闭事件及更新流。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 -
同 changelog:"持续任务更专注于研究本身——定时自动运行的持续任务现在只做研究、观察与整理,不再自行发起对外动作;需要对外执行的动作统一回到主会话、由你在场时进行",且操作说明已明确"持续任务不用于直接交易"。 ↩ ↩2 ↩3 ↩4 ↩5
-
apps/web/content/docs/changelog/v1-0-9.mdx:官方信息雷达"无人值守,每个交易日从盘前到盘后定时运行",为"按交易日无人值守定时运行"提供已上线实例;该雷达"只做信息研判,不替任何人下单,也不调仓"。 ↩ -
同文件(
tap_manager):用于构建、更新或并存多个 TAP 定义,按tap_id区分——新tap_id新建、复用同一tap_id更新,同一代理可同时拥有盘前/盘中/复盘等多个独立 TAP。 ↩ -
产品事实登记"每一步动作都可追溯"为
beta:对话、工具调用、持仓、策略定义、运行(tap_runs)与控制记录有多处留痕,但尚无覆盖全部动作的统一审计契约;公开只能列出具体可追溯对象,不得承诺"每一步完全可追溯"。 ↩ -
同 changelog:"持续任务更不容易中途卡住"——提高了持续任务单次推理的步数预算,让多步推理的长任务更不容易中途因步数用尽而提前结束。 ↩
-
同 changelog:"主会话与持续任务的表现各归其位"——即时对话(主会话)与无人值守定时运行(持续任务)两种场景,从第一句话起各按其方式工作。 ↩
-
apps/agent-api/src/runtime-tools/strategy-position-tool.ts:在tap:{tapId}会话中set_target/reset被门禁拒绝——TAP 只做观察与判断,调仓主张写回主会话由其决定是否执行。这是"持续任务不自动下单"的代码级依据。 ↩ -
产品事实登记"持仓管理"为
production:记录策略目标/当前仓位、变更时间、标的、仓位比例和原因;是沙箱内策略仓位账本,不是券商持仓或真实成交。证据:POSITIONS_HISTORY_TABLE、strategy_position。 ↩ ↩2 -
capability-intros.ts(策略持仓):set_target记录的是策略意图,实际成交以真实下单回路为准;比例以设置时组合总市值为基准,按标的增量更新。 ↩ -
apps/agent-api/src/product-api/agent-detail/returnMetrics.ts等:份额法盯市,虚拟初始资金nav0 = 1、无量纲,当前真实权重 = 份额 × 收盘价 ÷ nav。 ↩ -
产品事实登记 PF-02:持仓来自沙箱策略账本,不是券商同步;仓位随价格漂移不代表系统提交订单或自动再平衡。 ↩
-
产品事实登记"券商连接与真实下单"为
unsupported:对apps、packages、services、infra生产代码检索未发现券商或下单实现;apps/agent-api/src/runtime-tools无下单工具。 ↩ ↩2 -
产品事实登记"禁止声明":"自动交易""自动下单""券商同步持仓""内置回测已上线"等在任何公开页面、销售材料、Schema 或截图中均不得使用。 ↩
-
产品事实登记"回测引擎"为
unsupported:没有现成统一回测引擎,只能在受限代码工具中由用户自行组织研究计算;backtest-routes.ts返回未实现。 ↩ -
产品事实登记"智能体对话与工具调用"为
production:模型输出可能出错,不构成投资建议。 ↩