Q&A: Ask anything about Vibe-Trading

[warren618]

🙏 Got questions? Ask here!

This is the place for setup help, usage questions, and development discussions. Lower barrier than opening an issue.

Common topics

• Installation: pip install, Docker, environment setup
• Configuration: .env variables, API keys, model selection
• Usage: CLI commands, frontend features, MCP integration
• Backtesting: engines, strategies, data sources
• Swarm: presets, custom teams, DAG workflows
• Development: contributing, adding tools/skills, architecture

Before asking, check the README — it covers most setup questions.

No question is too basic. Ask away!

[Probe343]

你好，我使用的是WorkBuddy这种由内置大模型调用，且内置大模型调用的api对用户和mcp工具透明，因此Vibe-Trading无法得到内置模型的api key，这样的话应该如何为swarm多智能体功能配置大模型环境呢？

[warren618]

你好！swarm 的 worker 需要 Vibe-Trading 独立发起 LLM 调用，没法复用宿主模型的通道，所以必须单独配一个 key（跟 WorkBuddy 的内置模型互不影响）。

在启动 Vibe-Trading MCP server 的环境里（agent/.env 或系统环境变量）加：

LANGCHAIN_PROVIDER=deepseek         # 或 openrouter / openai / anthropic
LANGCHAIN_MODEL_NAME=deepseek-chat
DEEPSEEK_API_KEY=sk-xxx             # 对应 provider 的 key

文档里 run_swarm 是 22 个工具里唯一需要 LLM key 的，其他 21 个零 key 即可使用。

[Probe343]

你好，请问agent/.env的完整路径是什么？

[warren618]

@Probe343 没有"唯一固定路径"，Vibe-Trading 启动时会按下面的顺序找 .env，命中第一个就用：

1. ~/.vibe-trading/.env ← 推荐，跨 pip 升级保留
2. <安装目录>/agent/.env ← 源码克隆开发用
3. $CWD/.env ← 启动时的当前工作目录

WorkBuddy 场景手动建一下就行：

mkdir -p ~/.vibe-trading
cat > ~/.vibe-trading/.env <<'EOF'
LANGCHAIN_PROVIDER=deepseek
LANGCHAIN_MODEL_NAME=deepseek-chat
DEEPSEEK_API_KEY=sk-xxx
DEEPSEEK_BASE_URL=https://api.deepseek.com/v1
EOF
chmod 600 ~/.vibe-trading/.env

对应完整路径就是 /Users/<用户名>/.vibe-trading/.env（Linux 同理；Windows 是 C:\Users\<用户名>\.vibe-trading\.env）。

启动 MCP server 后日志里会有一行 dotenv resolved from ~/.vibe-trading/.env | provider=deepseek model=deepseek-chat base=https://api.deepseek.com，按这行确认实际生效的是哪个槽位。

[Probe343]

你好，我如果是使用nvidia nim的api key，但是使用的模型是mistralai的模型，那提供给swarm的.env该怎么写呢？

[warren618]

你好，可以这样配。这里看的是“API 网关/协议”，不是模型厂商：NVIDIA NIM 提供 OpenAI-compatible Chat Completions API，所以在 Vibe-Trading 里走 openai provider，把 NVIDIA NIM 的 key/base URL 填到 OPENAI_* 变量即可。

Hosted NVIDIA NIM 示例：

LANGCHAIN_PROVIDER=openai
LANGCHAIN_MODEL_NAME=mistralai/mistral-nemotron
OPENAI_API_KEY=你的_NVIDIA_NIM_API_KEY
OPENAI_BASE_URL=https://integrate.api.nvidia.com/v1

LANGCHAIN_TEMPERATURE=0.0
TIMEOUT_SECONDS=120
MAX_RETRIES=2

LANGCHAIN_MODEL_NAME 换成 NVIDIA NIM 页面上的完整 model id 即可，例如 mistralai/mistral-nemotron、mistralai/mistral-7b-instruct-v0.3、mistralai/mixtral-8x7b-instruct 等。

注意不要只写：

NVIDIA_API_KEY=...
NVIDIA_BASE_URL=...

当前 Vibe-Trading 的 provider 映射不会读取这两个变量；swarm 内部 LLM 调用最终会通过 OpenAI-compatible 客户端读取 OPENAI_API_KEY / OPENAI_BASE_URL。

如果是本地自部署 NIM，则类似这样：

LANGCHAIN_PROVIDER=openai
LANGCHAIN_MODEL_NAME=你的本地NIM模型名
OPENAI_API_KEY=not-used
OPENAI_BASE_URL=http://localhost:8000/v1

参考：NVIDIA NIM LLM API 文档里 hosted URL 是 https://integrate.api.nvidia.com，chat endpoint 是 /v1/chat/completions，并标注 compatible with OpenAI：
https://docs.api.nvidia.com/nim/reference/llm-apis
https://docs.api.nvidia.com/nim/reference/mistralai-mistral-nemotron-infer

[Probe343]

你好，我想问一下，如果我想构建自己的工作流，比如构建每日的自动化投资工作流，我可以自己调用vibe-trading的金融skill来搭建吗？在不使用自然语言的情况下。其实相当于是把vibe-trading当作是一个工具箱，这样可以吗？

[warren618]

可以的，我们支持mcp调用，可以用您自己的coding agent（claude code，codex，workbuddy等）直接调用vibe trading的绝大多数功能。

[Probe343]

请问Finance Skill Library ，这8 个类别中的 77 个 skills也是可以我自己调用的吗？

[warren618]

可以的。所有的skills都可以被workbuddy直接调用。

[Probe343]

请问skills是可以如何被调用呢？是通过CLI命令还是其他方式？

[warren618]

好问题,这个确实容易混。先把两个概念分开就清楚了:skill 是知识文档(markdown),它本身不会执行任何动作;真正干活的是 tool(回测、取数据这些)。所以你想当工具箱、不走自然语言,其实是直接调 tool,skill 只在你想参考某类策略怎么搭的时候,load 出来看看就好。

三种调法,看哪种顺手:

一是 MCP,你现在 WorkBuddy 走的就是这条。server 里 list_skills / load_skill(name) 是 skill 那两个,真正执行的是 backtest、get_market_data、factor_analysis、analyze_options、run_swarm 这些(一共 36 个)。每日流程基本就是把这几个按顺序串起来。

二是命令行,vibe-trading skills 能把所有 skill 列出来,先看看有哪些可用。

三是想完全脚本化、挂 cron 的话,直接 import 进 Python 就行:

from src.tools import build_registry

registry = build_registry()
result = registry.execute("get_market_data", {
    "symbol": "600519.SH", "start": "2025-01-01", "end": "2026-01-01",
})

一句话:不想用自然语言,就直接调 tool;skill 当参考文档,需要时再 load。你要是愿意,把每天想跑的流程发我(比如 选股 → 回测 → 出报告),我帮你写一段最小的串法,照着改就行。

[tomes-commits]

我的docker desktop只有vibe strading这个项目，火绒出现这个提示，请问项目是否有问题？

[warren618]

没有问题，这个是你在中国大陆的网络下，调用okx接口进行加密货币量化研究的时候会访问到的域名，对于加密货币相关的域名，火绒是会报警告的。

[barteksibiga]

Hello @warren618 I found your project and I’m interested in speaking with you about possible collaboration.
Is there a good way to contact you directly?

[warren618]

Hi @barteksibiga, thanks for reaching out and glad you found the project interesting! The best way to reach me directly is via the email on my GitHub profile (haozhe_wu@connect.hku.hk). Feel free to drop me a line with some details on what kind of collaboration you have in mind.

[cwx1150314525-alt]

如果我想让数据更稳定一些，数据源能如何做啊

[warren618]

数据稳定性从低到高有四档，按需求选：

1. 零配置：用 source="auto"（内置 fallback 链，A 股优先走 tencent → mootdx → eastmoney → baostock → akshare → tushare），并开 VIBE_TRADING_DATA_CACHE=1（已结算的 K 线缓存到 ~/.vibe-trading/cache，减少重复请求被限流的概率）。
2. 本地数据桥（推荐，A 股最稳）：mootdx 走通达信 TCP 直连、无 IP 限流，或者把通达信数据同步到本地后用 local: 源（CSV/Parquet/DuckDB），彻底不依赖公网接口。
3. key 源：配 TUSHARE_TOKEN（A 股）或 finnhub/alphavantage/tiingo/fmp（海外），配额内很稳定。
4. 商用数据：Settings → QVeris（付费市场，按量计费，显式启用才会用到）。

多数场景 1+2 组合就够了。之前在 #394 里给你的建议（先通达信本地同步，满意后再上商用数据）依然成立。

[brady-cec]

Hi I am trying to clone the Vibe-Trading on my local machine by following these steps.

git clone https://github.com/HKUDS/Vibe-Trading.git
cd Vibe-Trading
python -m venv .venv

.venv\Scripts\Activate.ps1 # Windows PowerShell

pip install -e .
cp agent/.env.example agent/.env # I completed the API key setup here
vibe-trading - This step is giving me below error

'Vibe-Trading' is not recognized as an internal or external command,
operable program or batch file.

[newgo]

hi, 我有一个关于系统提示词的问题 @warren618
agent/src/agent/context.py:51

感觉分析与研究的系统提示词写的很笼统，不像其他的写得很详细按步骤来执行（比如回测、影子账户等），以至于有时候进行ETF或则个股分析与研究的时候数据不准确（比如有时候大模型不会调用工具实时获取股价而是自己编一个股价、etf名字无法对应等问题）

[warren618]

Thanks for the detailed repro — the steps you followed match the README exactly, so this isn't a docs mismatch, but let's find out why vibe-trading isn't on PATH in your shell.

The vibe-trading command is installed by pip install -e . into .venv\Scripts\ as part of the venv — that mechanism itself works (verified). The most common reason it doesn't show up after that on Windows is that .venv\Scripts\Activate.ps1 silently failed to run because of PowerShell's default execution policy, so pip install -e . actually ran against your system/base Python instead of the venv.

A couple of things to check: (1) after activating, does your prompt show a (.venv) prefix — did you see a red "running scripts is disabled" error at that step? (2) if you closed/reopened your terminal between install and running, you'll need to reactivate — it doesn't persist across sessions; (3) as a quick diagnostic that sidesteps PATH entirely, try running .venv\Scripts\vibe-trading.exe directly.

If it's the execution-policy issue, that's common enough on fresh Windows setups that we should add a one-line README note (Set-ExecutionPolicy -Scope Process -ExecutionPolicy RemoteSigned) — let us know what you find.

[brady-cec]

Hi Thank you for your response. I removed everything and followed each step again At activation step I do see the (.venu) is showing in the front [image: image.png] CP command is not valid for CMD Prompt [image: image.png] So I do this step in the windows explorer and since I am using ollama on a different machine with QWQ model I maintained the following entries into my .env file [image: image.png] I was able to run the .exe from explorer [image: image.png] Is this how it should appear? How do I use it from here if this is the right location? Thank you for your guidance so far. Much appreciated.

…

On Thu, Jul 16, 2026 at 2:59 AM Haozhe Wu ***@***.***> wrote: Thanks for the detailed repro — the steps you followed match the README exactly, so this isn't a docs mismatch, but let's find out why vibe-trading isn't on PATH in your shell. The vibe-trading command is installed by pip install -e . into .venv\Scripts\ as part of the venv — that mechanism itself works (verified). The most common reason it doesn't show up after that on Windows is that .venv\Scripts\Activate.ps1 silently failed to run because of PowerShell's default execution policy, so pip install -e . actually ran against your system/base Python instead of the venv. A couple of things to check: (1) after activating, does your prompt show a (.venv) prefix — did you see a red "running scripts is disabled" error at that step? (2) if you closed/reopened your terminal between install and running, you'll need to reactivate — it doesn't persist across sessions; (3) as a quick diagnostic that sidesteps PATH entirely, try running .venv\Scripts\vibe-trading.exe directly. If it's the execution-policy issue, that's common enough on fresh Windows setups that we should add a one-line README note (Set-ExecutionPolicy -Scope Process -ExecutionPolicy RemoteSigned) — let us know what you find. — Reply to this email directly, view it on GitHub <#29?email_source=notifications&email_token=B4XCBJEMNBLAZW6TTUNLQVT5FB4NZA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZWGU3TQNRYUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-17657868>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/B4XCBJHPEXZ3DAIZSVE7PQL5FB4NZAVCNFSNUABIKJSXA33TNF2G64TZHMYTCOJYGMYDMOBRGI5UI2LTMN2XG43JN5XDWOJYG4ZTGMBYUF3AE> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/B4XCBJAFDWZ7WALB46C3QZD5FB4NZA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZWGU3TQNRYUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSVGM33PORSXEX3JN5ZQ> and Android <https://github.com/notifications/mobile/android/B4XCBJD56ZQJANFTAGXSKJL5FB4NZA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZWGU3TQNRYUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ>. Download it today! You are receiving this because you commented.Message ID: ***@***.***>

[warren618]

Good news — that window is the interactive CLI, so your install is working correctly. Sorry the path there was so bumpy.

One suggestion: rather than launching the .exe from Explorer, run it from a terminal. Launched from Explorer you can't pass any subcommands, and if anything goes wrong the window closes before you can read the error. From a terminal in the project folder:

cd path\to\Vibe-Trading
.venv\Scripts\activate.bat        (CMD)
.venv\Scripts\Activate.ps1        (PowerShell)
vibe-trading

Then just type your question at the prompt. If you'd prefer a browser interface, vibe-trading serve gives you the Web UI instead.

You're also quite right that cp isn't a CMD command — that's our README's fault, not yours; it assumes a POSIX shell. On CMD it's copy agent\.env.example agent\.env, and in PowerShell Copy-Item agent\.env.example agent\.env. I'll fix the README, and add a note about the PowerShell execution policy too, since that seems to catch people at the activation step.

For the remote Ollama with QwQ, the .env entries you'll want are:

LANGCHAIN_PROVIDER=ollama
LANGCHAIN_MODEL_NAME=<your model tag>
OLLAMA_BASE_URL=http://<that-machine>:11434

One thing worth checking: Ollama binds to localhost by default, so the machine serving QwQ may need OLLAMA_HOST=0.0.0.0 before the Windows box can reach it on 11434.

Thanks for sticking with it and for reporting each step so clearly — the cp problem in particular is something we should have caught ourselves.

[Cheeseburger444]

Title: start_research_goal MCP tool fails with "session_id is required" — LLM has no way to provide it
Body:
When running a simple backtest prompt, the agent calls start_research_goal and immediately fails validation because session_id is missing — but the LLM was never given a session_id to pass, and nothing appears to inject it automatically for this tool.
Steps to reproduce:
vibe-trading run -p "Backtest a 20/50-day moving average crossover on SPY for the past 2 years, show Sharpe ratio and max drawdown"
Result: Run status shows SUCCESS, but the actual answer is just an error explaining that session_id is required, with no backtest output.
Relevant trace.jsonl excerpt:
json{"type": "tool_call", "iter": 1, "tool": "start_research_goal", "call_id": "call_o6jgf6hb", "args": {"criteria": [...], "objective": "...", "risk_tier": "research_general", "run_dir": "..."}, "ts": ...}
{"type": "tool_result", "iter": 1, "tool": "start_research_goal", "call_id": "call_o6jgf6hb", "status": "error", "preview": "{"status": "error", "error_type": "validation", "error": "session_id is required"}", ...}
Note the args in the tool_call — no session_id field is present, since the LLM has no way of knowing it.
What I found digging into the code:

agent/src/tools/goal_tool.py and agent/src/tools/init.py have a session_injected_classes mechanism (StartResearchGoalTool etc.) that's explicitly designed so "the LLM never knows the session id" — session_id gets injected by the host at registration time.
However, agent/mcp_server.py also defines a start_research_goal MCP tool (@mcp.tool) that takes session_id: str as a required positional argument with no default/injection — the docstring even says session_id: External conversation/session id owned by the MCP client, implying the MCP client is responsible for injecting it, not the LLM.
It looks like whatever path vibe-trading run takes ends up calling the MCP-server-style tool definition (which requires session_id as an LLM-supplied arg) rather than the local class-based tool (which injects it automatically) — or the MCP client isn't injecting session_id when it should be.

Environment:

vibe-trading (installed via pip, .venv on Windows)
LLM: qwen3:32b via local Ollama (also reproduced on qwen3:8b)
Reproduced consistently across both model sizes, so this doesn't appear to be a model tool-calling capability issue.

Happy to share the full run directory / trace.jsonl if useful.

[warren618]

You're right, and @initial-d's reading of it is right too. I traced it through the source and this is a genuine bug on our side, not something you did wrong — sorry you had to dig through the code to find it.

The path:

• agent/cli/_legacy.py:1404 — cmd_run() calls _run_agent() with no session id
• agent/cli/_legacy.py:991 — _run_agent() defaults it to ""
• agent/cli/_legacy.py:1151 — passes session_id or None into build_registry()
• agent/src/tools/__init__.py:146 — goal tools get registered unconditionally with default_session_id=None
• agent/src/tools/goal_tool.py:194 — so execute() hits the empty-id branch and returns session_id is required

So non-interactive vibe-trading run fails this tool every time. And as you noticed, the run still reports SUCCESS while the answer is only the validation error — I've added that to the issue as well, since a run like that shouldn't be reported as a success.

@initial-d is also right about the other half: agent/mcp_server.py:444 declares start_research_goal(session_id: str, ...) as a required, model-supplied argument, which is the opposite contract from the local tool. The host should own the session id on both paths; you shouldn't have to invent one.

Tracked in #885. Your workaround of passing a stable id yourself should hold in the meantime. Thank you for the trace excerpt and for going into the source — that's the only reason this was actionable straight away.

[initial-d]

I think this is probably not a user-side prompting issue. It looks like there are two different paths with slightly different assumptions:

• The local agent tool treats session_id as host-injected. In agent/src/tools/goal_tool.py, StartResearchGoalTool says session_id is optional and falls back to default_session_id.
• But the MCP server exposes start_research_goal(session_id: str, ...) in agent/mcp_server.py, so for an external MCP client the schema makes session_id a required model-supplied argument.

That means the model is being asked to provide an internal/session-scoped value it does not naturally know. A short-term workaround is to call the tool with any stable per-conversation id, for example something like session_id="local-cli-default" or session_id="backtest-20260717", as long as the same id is reused for get_research_goal, add_goal_evidence, and update_research_goal_status in that run.

For a code fix, I would make the MCP path match the local-agent path: make session_id optional in the MCP tool, then derive it from the MCP/FastMCP context if available, or from a server-side fallback generated at session startup. The important part is that the LLM should not be responsible for inventing a hidden session id. If no context id can be derived, returning a clearer error like “MCP host did not provide a session id; configure VIBE_TRADING_SESSION_ID or pass session_id explicitly” would make the failure much easier to debug.

[initial-d]

@newgo 我也赞同这个判断：金融研究类 agent 里，"分析/研究"这段如果只写成通用原则，模型很容易把“语言推理”误当成“数据查询”，尤其是 ETF 名称、实时价格、财务指标、A/H/US 不同市场代码映射这几类。

我会把它拆成更硬的三层规则，而不是只加强语气：

1. Symbol canonicalization first
   任何 ETF/股票分析前，先调用 symbol/search/profile 类工具，把用户输入解析成明确的代码、交易所、币种、数据源。解析不到就停下来问用户，不要猜。

2. Market-data claims must be tool-backed
   只要回答里出现价格、涨跌幅、成交量、估值、持仓、成分股、财报数字，就必须先有对应工具结果。没有工具结果时只能写“未验证/无法确认”，不能用模型记忆补。

3. Evidence table before conclusion
   对研究任务，先输出一个很小的 evidence block，例如：

   Symbol: SPY / NYSE Arca / USD
   Data source: yfinance
   Price timestamp: ...
   Last close: ...
   Missing fields: holdings unavailable
   

   然后再写分析结论。这样模型会更难“直接开讲”。

如果要改代码，我觉得可以在 agent/src/agent/context.py 的 Analysis / research 路由下面加一个明确的 finance-data policy，并且把“不得编造市场数据”从通用 Guidelines 移到工具调用前置条件里。单靠 prompt 不一定 100% 解决，但把“先 search_symbol / get_stock_profile / market_data，再分析”写成流程，会比一句 “do not fabricate data” 稳很多。

[newgo]

可能作者认为研究方法很多需要使用者自己进行提示词撰写，而不是给一个固定模板

[initial-d]

对，我同意研究方法本身不应该被写成一个固定模板。不同用户会有不同的分析框架，比如价值分析、技术分析、事件驱动、组合归因、宏观/行业比较，这些确实应该开放给用户自己写 prompt。

我想区分的是两层东西：

1. Research method / reasoning template：这个应该灵活，由用户或具体 workflow 决定。
2. Data-grounding policy：这个最好由系统层固定下来，比如先解析 symbol，再调用数据工具；没有工具结果时，不要编造价格、财务指标、ETF 名称、成分股或实时行情。

所以我不是建议把“研究方法”固定死，而是建议把“市场数据必须 tool-backed”变成底层规则。这样用户仍然可以自由写自己的研究 prompt，但 agent 在基础事实层面不会因为模型记忆或猜测而 hallucinate。

换句话说：研究路径可以开放，但数据来源和证据链应该收紧。这样对金融 agent 会更稳。

[Cheeseburger444]

Thanks, this is exactly the distinction I was trying to make. I completely agree that research methodology should remain flexible and user-defined. My concern was only about the factual layer. For a financial agent, enforcing tool-backed market data (symbol resolution, prices, fundamentals, ETF constituents, etc.) at the system level would significantly reduce hallucinations while preserving full freedom for users to design their own research workflows.

…

On Tue, 21 Jul 2026 at 10:04, Yimin Du ***@***.***> wrote: 对，我同意研究方法本身不应该被写成一个固定模板。不同用户会有不同的分析框架，比如价值分析、技术分析、事件驱动、组合归因、宏观/行业比较，这些确实应该开放给用户自己写 prompt。 我想区分的是两层东西： 1. Research method / reasoning template：这个应该灵活，由用户或具体 workflow 决定。 2. Data-grounding policy：这个最好由系统层固定下来，比如先解析 symbol，再调用数据工具；没有工具结果时，不要编造价格、财务指标、ETF 名称、成分股或实时行情。 所以我不是建议把“研究方法”固定死，而是建议把“市场数据必须 tool-backed”变成底层规则。这样用户仍然可以自由写自己的研究 prompt，但 agent 在基础事实层面不会因为模型记忆或猜测而 hallucinate。 换句话说：研究路径可以开放，但数据来源和证据链应该收紧。这样对金融 agent 会更稳。 — Reply to this email directly, view it on GitHub <#29?email_source=notifications&email_token=BMB6RDP2MXIAIA7FGTB2MT35F4BXBA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZXGEYDSOBZUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-17710989>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BMB6RDMSO7ENTZUGOXULK2D5F4BXBAVCNFSNUABIKJSXA33TNF2G64TZHMYTCOJYGMYDMOBRGI5UI2LTMN2XG43JN5XDWOJYG4ZTGMBYUF3AE> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/BMB6RDJH4I3WOZUHCDPIUE35F4BXBA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZXGEYDSOBZUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSVGM33PORSXEX3JN5ZQ> and Android <https://github.com/notifications/mobile/android/BMB6RDME2TCSQKOY5UCZNXD5F4BXBA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZXGEYDSOBZUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ>. Download it today! You are receiving this because you commented.Message ID: ***@***.***>

[initial-d]

Yes, exactly. I think the practical implementation point is to make the factual layer a small contract, not just another prompt instruction.

For example, the agent/runtime could require something like:

1. resolve the symbol before analysis: user text -> canonical symbol / exchange / currency / data source;
2. attach evidence metadata to market-data claims: source, timestamp, field name, and whether it is observed / derived / unavailable;
3. fail closed for factual fields: if price, volume, fundamentals, ETF constituents, etc. were not returned by a tool, the answer should say that explicitly instead of filling the gap from model memory;
4. keep the research method separate: valuation, technical analysis, macro comparison, portfolio attribution, etc. can still be fully user-defined.

That way the system does not lock users into one research template, but it does lock down the part that is most dangerous in a finance agent: ungrounded market facts. If this becomes a docs or prompt PR later, I would probably frame it as a "finance evidence contract" rather than as a fixed analysis workflow.

[newgo]

原始trace.json
trace.json

调用工具get_market_data 返回数据是正确的，但是生成报告的数据对不上，不知是怎么回事

[warren618]

@newgo 谢谢你提供 trace，这份材料的价值比"模型没调工具"那类描述高很多。我把 trace.json 下载下来逐条看了，问题确实存在，而且比你描述的更明确一些。

同一个交易日 2026-06-23 的对比：

字段	get_market_data 返回	最终报告表格
open	1.141	0.895
high	1.164	0.907
low	1.121	0.892
close	1.137	0.903

工具返回里能看到的所有 K 线都在 1.11–1.18 区间，报告整张 20 行表都在 0.88–0.91 区间，随后的「重仓买入区 0.881」也是取自这张对不上的表。而报告开头写的是「根据工具查询到的实际数据」——所以不是模型没调工具，是它声称了自己并不具备的依据。

另外从同一份 trace 里还看到两点，可能你没注意到：

1. search_symbol 返回的是 562500.SS，下一步却调用了 get_market_data(["562500.SH"])，这个转换全程没有暴露出来；
2. get_stock_news 的 tool_result.status 是 "ok"，但 payload 是 {"ok": false, "error": "eastmoney news fetch failed: ..."}——失败在 status 层就被吞掉了，下游自然也不会把它当成"缺失的证据"。

已建 #886 跟踪，会把你这份 trace 做成回归 fixture：如果最终答案的行情数字和同一次 run 的工具返回对不上，测试就应该挂掉。

有一点想先说清楚：我目前只做了 trace 的静态核对，还没有本地复现，所以修复面要等复现之后才能定。另外 trace 里 preview 字段是展示用的截断，并不等于模型实际收到的内容（模型侧上限是 10000 字符），模型到底拿到了完整序列还是被截断过的数据，也要复现才能确认——这一条我写进 issue 的第一项验收标准了。

你最早提的"分析/研究这段系统提示词偏笼统、不像回测那样按步骤走"，这个观察我认为也成立。不过修法应该不是把研究方法写死成模板（上面 @initial-d 和 @Cheeseburger444 的讨论我很认同）：研究方法保持开放，要收紧的是事实层。

[newgo]

我又回看了一下trace，get_market_data(["562500.SH"])可能根本就没有使用search_symbol 返回的数据
search_symbol 第一次tool_call的"ts": 1784704947.8136623
get_market_data 第一次tool_call 的"ts": 1784704947.814284
然后
search_symbol 第一次tool_result "ts": 1784704948.5770946
get_market_data 第一次tool_result "ts": 1784704948.578406

可以发现search_symbol 第一次tool_result "ts": 1784704948.5770946 大于 get_market_data 第一次tool_call 的"ts": 1784704947.814284
如果get_market_data 的请求参数需要等待search_symbol返回的结果那么get_market_data的发起调用时间应该比search_symbol 返回结果时间大才对

下面是今天运行的trace，相同的问题
1：生成的报告与实际调用工具查询的数据不符
2：get_market_data 发起调用的时间大于search_symbol 返回结果的时间
3：search_symbol 返回的是 562500.SS
trace.json

环境
1：code version 0.1.10

2：模型配置

[warren618]

@newgo 你这个时间戳分析非常关键，我逐条核对了：search_symbol 和 get_market_data 的 tool_call 时间只差 0.0006s，而 search_symbol 的结果在两者发起之后才返回——也就是说这两个调用是同一轮并行发出的，get_market_data 的参数 562500.SH 不可能来自 search_symbol 的返回，它是模型凭先验平行"猜"出来的；工具实际返回的是 562500.SS。之前我说"转换过程没有暴露"，你的时间戳证明了更糟的事实：根本不存在转换，因为不存在数据依赖。

这个发现直接改变 #887 身份门的设计要求：只检查"是否调用过 search_symbol"是不够的——resolver 和消费其结果的调用出现在同一并行批次里，本身就是应当被拦截的违例。门的正确形态是：任何以 symbol 为参数的行情/数据调用，其参数必须取自已锁定的 identity record，而不是模型自由生成；identity 未锁定时这类调用直接拒绝。

顺带说明为什么这个 bug 一直没被发现：562500.SH 恰好是 eastmoney/tushare 系 loader 接受的后缀格式，所以平行猜测"碰巧能用"——猜对的时候完全不可见，只有猜错或者报告与数据脱节时才暴露。这正是它危险的原因。

新的 trace.json 我会连同这条时间戳分析一起收进 #887 的测试夹具。谢谢你把它挖到了机制层面。

[initial-d]

@newgo Thanks for sharing the trace. This is actually a stronger example than simply “the model did not call tools”.

From the trace, the agent did call search_symbol, get_market_data, get_stock_news, and get_sector_info. The problem is that the final answer diverged from the tool evidence.

For example, get_market_data(["562500.SH"]) returned a latest close of 0.961 on 2026-07-22, with the one-month range roughly 0.913 low to 1.229 high. But the final answer claimed latest close 0.890, low 0.881, high 0.907, and then built buy/sell zones around those numbers. So the issue is not only “tool use required”; it is that the final response is not grounded against the actual tool result.

I see three guardrails that would help here:

1. After search_symbol, the agent should lock a canonical symbol / exchange / data source and reuse it consistently. If 562500.SS is converted to 562500.SH, that mapping should be explicit.
2. Failed tool results such as get_stock_news -> ok:false should be surfaced as unavailable evidence, not silently ignored.
3. Before finalizing, any market-data numbers in the answer should be checked against the latest tool result. If the answer mentions price, volume, date range, support/resistance, or derived indicators, those values should be traceable to the returned OHLCV data or marked as derived.

This is the kind of case where a “finance evidence contract” would be useful: tool calls happened, but the final natural-language answer still escaped the evidence.

[warren618]

@initial-d This is the right framing, and I'd like to adopt it.

The distinction you and @Cheeseburger444 arrived at — research method stays user-defined, the factual layer becomes a system-level contract — is the line I think we should be holding, and I don't think we've been holding it. Vibe-Trading deliberately doesn't ship a fixed analysis template and shouldn't start now. But "the final answer may contradict a successful tool result from the same run" isn't user freedom, it's a defect, and you're right to separate the two.

Your four points are close to what I'd want implemented:

1. resolve the symbol to canonical symbol / exchange / currency / data source before analysis, and lock it for the run;
2. attach evidence metadata to market-data claims — source, timestamp, field, and observed / derived / unavailable;
3. fail closed on factual fields: a value no tool returned is stated as unavailable rather than filled from model memory;
4. leave the research method alone.

One correction to my own reading, in the interest of not overstating things: I went through @newgo's trace.json directly, and the specific figures quoted in this thread (latest close 0.961, one-month range 0.913–1.229) fall outside the truncated preview field in that file, so I couldn't verify them from the attachment — I assume they came from the screenshots. What I could verify is a direct field-by-field contradiction on 2026-06-23 (tool 1.141/1.164/1.121/1.137 vs. report 0.895/0.907/0.892/0.903), which makes the same point. I've written the issue against the verified comparison and flagged the rest as unverified.

Two things in that trace that I don't think were mentioned yet, and that support your point 1: search_symbol returned 562500.SS while the next call used 562500.SH, with the conversion never surfaced; and get_stock_news was recorded with status: "ok" while its payload said {"ok": false}, so the failure was invisible to anything downstream.

I've split this into two issues rather than one, since the fixes land in different places:

• [Bug] Final answer can contradict the market data returned by tools in the same run #886 — answer grounding, with @newgo's trace as the regression fixture
• [Bug] Skill routing can happen before the instrument's identity is verified #887 — routing, since @peterchen-99 has posted a case where a research skill was chosen before the instrument's identity was verified at all

The session_id problem you diagnosed is #885.

"Finance evidence contract" is a better name than anything I had, and it's the framing I used in the issues. Thank you for working this at the source level rather than the symptom level — all three are actionable because of it.

[peterchen-99]

你好，我在本地 Web UI 使用 OpenAI Codex（gpt-5.4）测试个股研究时，发现一个可能影响投资研究准确性的 Agent 工作流问题。

复现提问：

SpaceX 在什么价格买入比较合适？

观察到的行为：

1. Agent 在没有先完成 ticker / 上市状态核验时，就自动加载了 private-company-research 工作流。
2. 随后给出了私募二级份额、SPV、流动性折价、等待 IPO 等建议。
3. 后续测试中，即使 search_symbol 已返回公司到代码的精确映射（SpaceX -> SPCX.US，并带有市场来源信息），最终回答仍可能称其为“未上市/私募公司”。

我理解问题不应只看“SpaceX 实际是否上市”，而是：

• 工具已经返回的公司身份/上市状态，未能约束最终回答；
• 模型可以绕过关键事实核验，直接进入不匹配的研究技能；
• 当数据源冲突或无法核实时，系统仍继续给出估值和买卖建议，而不是明确提示“无法核验”。

期望行为：

• 对上市状态、ticker、价格、估值、买卖建议等市场敏感问题，先强制核验标的身份；
• 已验证的工具结果不能被最终回答直接否定；
• 核验失败或来源冲突时，应停止给投资建议并说明不确定性；
• 未明确市场的标的不应静默路由到 A 股或私募公司研究流程。

这个问题可能会导致用户拿到方向完全错误的投资研究结论。
如有需要，我可以提供脱敏后的 trace.jsonl 片段和截图。

[warren618]

谢谢，这条报得非常清楚。它和上面 @newgo / @initial-d 那条线应该是同一族问题的两个环节：他们那条是"最终答案没有对齐已经返回的工具结果"，你这条更靠前——工具还没核验标的身份，路由就已经发生了，于是整个 run 从第一轮起就被锁进了错误的框架。

你列的期望行为里，有两条我认为应该做成系统级约束，而不是靠提示词措辞：

• 涉及上市状态、ticker、价格、估值、买卖建议时，先锁定标的身份（代码 / 交易所 / 币种 / 数据源），锁不定就停下来问，不猜；
• 已核验的工具结果不应被最终回答直接否定；来源冲突或无法核实时，应停止给投资建议并明确说明不确定性。

顺带一提，另一条线的 trace 里有个旁证：search_symbol 返回 562500.SS，下一步却用了 562500.SH，转换过程完全没有暴露。这说明标的身份目前在 run 里确实没有被"钉住"过，和你观察到的现象方向一致。

已建 #887 跟踪路由这一环。

如果方便的话，麻烦把你说的脱敏 trace.jsonl 片段和截图贴到那个 issue 上，尤其是 search_symbol 那一步的原始返回——我想确认它到底返回了什么。这一条我还没有在本地复现，你的 trace 会直接决定修复面有多大。再次感谢你把复现路径和期望行为分开写清楚，这样的报告对我们帮助很大。

[peterchen-99]

谢谢，我补充一段脱敏后的 trace。

说明：这是我本地加入临时防线后的复测，所以末尾的
market_listing_contradiction 是本地补丁记录的事件，不是上游原本已有的行为。
但前面的模型初始判断和 search_symbol 原始返回未改动。

{"type":"message","iter":1,"role":"user","content":"我想知道 Space X 在什么价格买入比较合适？"}

{"type":"thinking","iter":1,"content":"SpaceX 是未上市公司，不存在公开二级市场“买入价位”这一说法……"}

{"type":"market_fact_verification_required","iter":1,"allowed_tools":["get_market_data","get_sec_filings","read_url","search_symbol","web_search"]}

{"type":"tool_call","iter":2,"tool":"search_symbol","args":{"query":"SpaceX","limit":10}}

{"type":"tool_result","iter":2,"tool":"search_symbol","status":"ok",
"result":{
  "ok":true,
  "market":"multi",
  "source":"symbol_search",
  "data":{
    "query":"SpaceX",
    "count":10,
    "candidates":[
      {
        "symbol":"SPCX.US",
        "name":"SpaceX",
        "market":"us",
        "type":"美股",
        "source":"eastmoney",
        "also_from":["yahoo"],
        "cik":"0001181412"
      }
    ],
    "sources":{"eastmoney":"ok","yahoo":"ok","sec_edgar":"ok"}
  }
}}

{"type":"thinking","iter":5,
"content":"……工具检索里出现了“SPCX.US”等结果，但这更像是映射/衍生产品名称，不能直接等同于 SpaceX 已正常公开上市可交易普通股……"}

{"type":"market_listing_contradiction","iter":5,"symbols":"SPCX.US"}

[warren618]

@peterchen-99 这段脱敏 trace 比你标注的还要有价值——我拿它做了一次独立核实，结论把这个案例的性质定死了。

直接查了 SEC EDGAR：CIK 0001181412 就是 SPACE EXPLORATION TECHNOLOGIES CORP，注册 ticker SPCX，交易所 Nasdaq；filing 序列是 2026-06-11 EFFECT → 2026-06-12 424B4（IPO 定价招股书）+ S-8，随后一连串 Form 3/4 和 8-K——标准的上市序列。也就是说 SpaceX 自 2026 年 6 月中旬起就是纳斯达克上市公司，search_symbol 三个来源一致返回的 SPCX.US 是正确映射；模型 iter-1 thinking 里的"SpaceX 是未上市公司"是训练截止日期之前的过期先验，iter-5 再把正确的工具结果合理化成"映射/衍生产品名称"——这是 #887 那条约束（"下游不得用模型记忆推翻 identity record"）能找到的最干净的标本。你本地补丁记录的 market_listing_contradiction 触发得完全正确。

这个案例还顺手排除了一个有诱惑力的反向设计："工具数据看起来可疑时，信模型的谨慎"。这里三个独立来源一致、带 CIK，模型仍然推翻了它们，而且给出的是一个听起来很稳妥、实际上错误的答案。所以冲突的正确出口只有一个：identity 标记为 conflicting / ambiguous，停下来问用户——两个方向的静默覆盖都不允许。

@initial-d 之前要的两个测试夹具（一个真未上市公司 + 一个模型倾向于推翻的已上市映射），这条正好是第二个，我会把它按 identity.v1 / invalidated_by 的结构收进 #887。谢谢这次复测。

[initial-d]

I think this SpaceX example is the same class of failure as the trace above, but one step earlier in the workflow: the system is choosing a research route before the instrument identity is locked.

For finance workflows, I would put a small identity gate before any specialized skill such as private-company-research, A-share analysis, ETF analysis, etc. Something like:

user query
  -> resolve entity / symbol / venue / instrument type
  -> produce evidence: listed_security | private_company | fund | ambiguous | not_found
  -> only then choose the workflow

The important rule is that downstream agents should not be allowed to override that identity with model memory. If search_symbol returns a listed instrument mapping, the final answer cannot later say 'this is an unlisted private company' unless another tool result explicitly invalidates the mapping. If the mapping is ambiguous or source confidence is weak, the safer behavior is to stop and ask which market/instrument the user means, especially before giving any buy-price or valuation advice.

So I would separate this into two guardrails:

1. Pre-routing identity check: no investment workflow runs until symbol/listing status/instrument type are resolved or marked ambiguous.
2. Final answer consistency check: identity, price, date, and market-data claims in the final response must match the locked evidence record, or be labeled unavailable/conflicting.

That would preserve flexible research workflows, while preventing the most dangerous failure mode: a plausible but wrong investment answer caused by an early routing assumption.

[warren618]

@initial-d That state machine is a better specification than what I put in the issue, and I'd like to use it as written — the listed_security | private_company | fund | ambiguous | not_found enumeration in particular, because it makes ambiguous and not_found first-class outcomes rather than something the model routes around.

The rule you drew after it is the one I think matters most: downstream agents must not be allowed to override the identity record with model memory. That is exactly the failure @peterchen-99 hit — search_symbol had already produced a mapping and the final answer still called the instrument unlisted. Only another tool result should be able to invalidate a mapping.

I've quoted this into #887 as the design target. The one thing I still need before implementing is the reporter's trace, since I haven't reproduced it locally yet and I'd rather build the gate against a real failing run than against my reading of one.