尧图网站建设 
这次我们不聊一个开箱即用的演示项目而是完整走一遍 FDE 实战路线如何用 Agent 开发方法论从零打造一个股票分析智能体。股票分析本身是常见场景但真正有价值的是工程过程——需求拆解、文档先行、Vibe-Coding 生成原型、评测驱动迭代。这套流程也是当下 AI 团队招聘 FDE 前沿部署工程师时最看重的能力组合。先说项目边界。这个智能体的任务不是预测涨跌也不是自动下单而是给用户提供结构化的行情信息与分析过程给定一只股票智能体主动调用行情数据工具再把数据整理成简报。整个过程由 LLM 驱动用工具补充事实用评测集验收。读完本文你会拿到一套可以照抄的目录结构、核心代码、评测脚本和 API 封装。适合阅读本文的读者一类是准备转型 Agent 开发的工程师另一类是已经在做 AI 落地、想引入评测驱动的技术负责人。文章不会只讲概念每一步都对应可运行的文件和命令。1. 核心能力速览能力项说明项目类型FDE 实战案例Agent 开发端到端工程流程核心方法需求拆解、文档先行、Vibe-Coding、评测驱动业务场景股票行情查询与分析简报生成技术栈Python、OpenAI 兼容接口、FastAPI、数据源适配层硬件要求不依赖本地 GPU需要可访问 LLM API启动方式命令行测试 FastAPI Web 服务是否支持 API支持提供/v1/analyze接口是否支持批量任务支持可对股票列表做并发分析评测能力工具调用成功率、事实覆盖度、格式合规率是否适合生产可作为业务原型生产前仍需补充鉴权、限流、日志和评测闭环这里需要强调一点整套流程不依赖具体模型厂商接口基于 OpenAI 兼容协议实际使用哪个模型根据部署环境决定。下面的操作步骤也都按兼容协议来写。2. FDE 项目实战股票分析智能体到底是什么FDE即 Frontier Deployment Engineer前沿部署工程师。这个岗位的核心职责不是研究算法而是把大模型能力部署到真实业务场景解决“模型在实验室好用、到业务里用不起来”的问题。业务侧的需求通常是模糊的模型侧的能力是概率性的FDE 要做的就是在中间搭一套工程框架让不可控的模型输出变得可控、可测、可交付。股票分析智能体就是这个框架的一个典型样例。它涉及典型的 Agent 能力闭环自然语言输入、工具调用、结果归纳、最终回答。用户说“帮我看看某只股票的近期行情”智能体不能凭记忆回答必须先调用行情数据工具拿到数据再做总结。这个动作看似简单实际落地时会遇到一堆问题模型不按格式调用工具、数据源返回字段不统一、模型在没拿到数据时编造数字、批量分析时接口限流。这些问题都会在下面的流程中逐一处理。这个项目选择股票分析还有一个原因业务语义足够清晰。行情的字段是客观事实涨跌幅度可以精确计算评测结果容易判定对错。这比做一个泛泛的“聊天助手”更适合用来实践 FDE 方法论因为你能明确知道智能体做对了没有。注意合规边界。股票分析智能体只做信息整理和辅助分析不构成投资建议。不要在项目中加入自动下单、保证收益、预测未来走势这类能力。涉及实时行情数据时必须确认数据源的使用许可不能擅自抓取无授权的数据接口。这是 FDE 落地金融场景时的第一道红线。3. 第一步需求拆解从模糊想法到事实清单FDE 工作流里最难的不是写代码而是把业务方的模糊想法翻译成事实清单。业务方说“我要一个股票分析智能体”这句话里至少有三个不明确点分析哪些股票、分析哪些维度、输出什么格式。如果不拆清楚开发阶段就会反复返工。3.1 需求拆解要回答的问题在写任何代码之前先把下面这些问题列出答案用户是谁个人投资者还是内部投研人员这决定回答的详略程度。输入是什么股票代码、自然语言问题还是两者都有。输出是什么一段文字、结构化 JSON还是 Markdown 简报。分析什么行情快照、历史走势、财务指标、新闻舆情还是技术指标。数据从哪里来是否已获得授权接口字段是否稳定限流策略是什么。模型能力边界当前模型是否支持工具调用是否需要为不支持工具调用的模型走 Prompt 解析方案。错误兜底查不到数据时怎么回答模型拒绝调用工具时怎么处理。这七个问题属于需求的事实层。FDE 特别强调“面向语意的事实方法论”意思是每个需求点都要落到能验证的事实描述而不是停留在感觉层面。比如“分析行情”是语义描述落到事实层就是“获取股票最新交易日开盘价、收盘价、最高价、最低价和成交量并对比前一个交易日计算涨跌幅”。3.2 把需求拆成功能清单以股票分析智能体为例拆解后可以得到五个功能点股票代码识别。支持输入美股代码、A 股代码或内部证券编码并统一格式。行情数据获取。调用数据源工具返回指定股票的最新交易数据。风险信息提示。针对涨跌幅异常、成交量异常等做规则化提示。分析简报生成。模型基于工具返回的数据生成结构化文本禁止未取数先回答。接口服务。对外提供 HTTP API支持单只股票分析和批量分析。每个功能点都需要有对应的验收标准。验收标准就是评测用例的雏形这一步做扎实后面的评测驱动自然就能展开。3.3 需求拆解模板示例可以把拆解结果沉淀成 Markdown 文档作为后续一切开发的基础。下面是一个可用模板# 股票分析智能体需求拆解 ## 1. 用户与场景 - 用户内部投研人员 - 场景快速查看单只股票行情并生成简报 - 输入股票代码或自然语言问题 - 输出Markdown 格式分析简报 ## 2. 功能清单 | 编号 | 功能点 | 验收标准 | | --- | --- | --- | | F1 | 股票代码识别 | 输入 AAPL 返回 Apple Inc.注意代码大小写与交易所后缀 | | F2 | 行情数据获取 | 获取最新交易日 OHLCV 数据缺字段时显式报错 | | F3 | 异常涨跌提示 | 单日涨幅超过 5% 时输出风险提示 | | F4 | 分析简报生成 | 回答必须包含数据来源日期禁止编造数字 | | F5 | API 服务 | POST /v1/analyze 返回 200 和合法 JSON | ## 3. 数据来源 - 默认数据源待确认订阅的行情服务 - 字段open, close, high, low, volume, date - 无数据策略返回明确错误不让模型猜测 ## 4. 边界与限制 - 不提供投资建议 - 不接入交易系统 - 不做未来走势预测需求拆解文档写完之后应该让业务方逐条确认。确认过的事实清单就是后续开发的唯一依据如果业务方中途改需求不要口头确认回到这份文档里更新并重新过一遍受影响的功能点。4. 第二步文档先行写清楚再写代码很多 Agent 项目失败不是因为模型能力不行而是因为团队在代码里讨论需求。FDE 的做法是文档先行代码只是文档的执行结果。文档不需要写成几十页的正式设计书重点是把三类内容固定下来技术方案、提示词约束、评测计划。4.1 技术方案文档技术方案文档回答“用什么结构实现”。股票分析智能体建议采用工具调用模式整体结构分四层入口层接收用户问题维护多轮对话状态。调度层LLM 决定是否调用工具、调用哪个工具、传什么参数。工具层行情数据获取函数返回统一 JSON。评测层用评测集自动跑一遍统计指标。这样的结构让每一层都能独立验证。工具层可以脱离模型单测调度层可以换模型重测评测层则固定为回归测试。下面是技术方案文档的目录# 股票分析智能体技术方案 ## 1. 系统架构 入口层 - 调度层 - 工具层 - 数据源 | v 评测层 ## 2. 关键流程 - 用户输入问题 - LLM 判断是否需要行情数据 - 需要则调用 get_stock_quote(symbol) - 工具返回 JSON 给 LLM - LLM 生成最终简报 ## 3. 提示词约束基础版 - 角色股票分析助手 - 必须使用工具返回的数据 - 禁止编造行情数据 - 数据不足时明确回复“暂无数据” ## 4. 评测计划 - 评测集20 条用例 - 指标工具调用成功率、事实覆盖度、JSON 可解析率 - 门槛工具调用成功率 90%事实覆盖度 85%4.2 文档和代码的关系在 Vibe-Coding 阶段文档就是 Prompt 的上下文。把上面这份技术方案喂给 AI 编程工具生成的代码会比直接说“帮我写一个股票分析 Agent”准确得多。这不是玄学而是因为文档把约束说清了工具层返回什么字段、调度层用什么协议、评测层看什么指标。文档同时也是团队协作的锚点。新成员加入时不需要阅读全部代码先读需求拆解和技术方案就能知道系统边界和验收标准。这在 Agent 开发项目中尤其重要因为 Agent 行为是概率性的代码只能展示逻辑文档才能展示意图。5. 第三步环境准备与依赖安装股票分析智能体不依赖本地 GPU部署门槛低主要需要 Python 环境和 LLM API 访问权限。5.1 基础环境清单Python 3.10 或更高版本。pip 包管理工具。OpenAI 兼容的 LLM API 地址、Key、模型名。一个可以访问的行情数据源示例代码使用 yfinance 作为演示实际部署请替换为已授权的数据源或内部行情服务。网络策略服务器需要能访问 LLM API 与行情数据源。先创建项目目录并初始化虚拟环境mkdir stock-agent cd stock-agent python -m venv venv # Linux/macOS source venv/bin/activate # Windows PowerShell venv\Scripts\activate5.2 安装依赖新建requirements.txt内容如下openai1.30.0 fastapi0.110.0 uvicorn0.29.0 pydantic2.6.0 python-dotenv1.0.0 requests2.31.0 yfinance0.2.40安装依赖pip install -r requirements.txt说明一下 yfinance 的作用。它只是一个演示数据源通过公开渠道获取行情数据生产环境请根据授权情况换成行情 SDK 或自建行情服务。无论用哪个数据源工具层应该保持统一返回格式这样调度层和评测层不需要跟着改。5.3 配置环境变量在项目根目录创建.env文件LLM_API_KEYyour_api_key_here LLM_BASE_URLhttps://api.example.com/v1 LLM_MODELyour_model_name DATA_SOURCEyfinance再创建一个config.py读取环境变量import os from dotenv import load_dotenv load_dotenv() LLM_API_KEY os.getenv(LLM_API_KEY) LLM_BASE_URL os.getenv(LLM_BASE_URL) LLM_MODEL os.getenv(LLM_MODEL)环境变量是通用的但具体 Key 名和模型名需要按实际部署环境调整。不要在生产代码里硬编码 API Key。6. 第四步Vibe-Coding快速搭建 Agent 最小原型Vibe-Coding 是当前 Agent 开发中很实用的一种工作方式用自然语言对话驱动 AI 生成代码开发者负责给出方向、审查代码、运行测试。这套方式适合快速搭建最小可运行原型但不代表不写文档、不设测试。本文前面写的需求拆解和技术方案就是 Vibe-Coding 的导航地图。6.1 项目目录结构在开始写代码前先确定目录结构stock-agent/ ├── README.md ├── requirements.txt ├── .env ├── config.py ├── agent/ │ ├── __init__.py │ ├── tools.py │ ├── llm.py │ └── core.py ├── scripts/ │ └── run_eval.py ├── server/ │ └── app.py └── data/ └── eval_cases.json这个结构把工具层、调度层、评测层、服务层分开代码量不大但边界清楚。6.2 工具层行情数据获取工具层是 Agent 与外部世界交互的唯一通道。所有数据源差异都封装在agent/tools.py里模型不关心数据来自 yfinance、行情 SDK 还是内部数据库。打开agent/tools.py输入以下内容工具层对接行情数据源统一返回 JSON def get_stock_quote(symbol: str) - dict: 获取股票最新行情。 注意示例使用 yfinance实际部署请替换为合法授权的数据源。 import yfinance as yf ticker yf.Ticker(symbol) hist ticker.history(period5d) if hist is None or hist.empty: return { symbol: symbol, error: NO_DATA, message: 未查询到该股票的行情数据请检查代码是否正确 } last hist.iloc[-1] prev hist.iloc[-2] if len(hist) 2 else last return { symbol: symbol, date: str(hist.index[-1].date()), open: round(float(last[Open]), 2), close: round(float(last[Close]), 2), high: round(float(last[High]), 2), low: round(float(last[Low]), 2), volume: int(last[Volume]), change_pct: round( float((last[Close] - prev[Close]) / prev[Close] * 100), 2 ) }这个函数有两点值得注意。第一它把“涨跌幅”这个衍生指标计算放在工具层里而不是让模型自己算因为模型算算术容易出错。第二它返回固定的 JSON 结构后续无论换成哪个数据源都保持这个结构评测脚本就不用改。6.3 调度层LLM 工具调用主循环调度层负责让 LLM 决定是否调用工具、调用哪个工具并把结果回填给模型生成最终回答。使用 OpenAI 兼容的接口定义工具 Schema。新建agent/llm.pyLLM 客户端封装基于 OpenAI 兼容协议 import config from openai import OpenAI client OpenAI( api_keyconfig.LLM_API_KEY, base_urlconfig.LLM_BASE_URL ) def chat(messages, toolsNone): return client.chat.completions.create( modelconfig.LLM_MODEL, messagesmessages, toolstools or [], temperature0.2 )新建agent/core.py这是 Agent 的主循环Agent 调度核心 import json from agent import tools from agent.llm import chat SYSTEM_PROMPT ( 你是一名股票分析助手。 你必须先调用 get_stock_quote 工具获取数据再基于工具返回的数据回答问题。 工具返回的数据中包含日期回答时请注明数据日期。 如果工具返回 NO_DATA请明确告知用户暂无数据不要编造行情数字。 回答要简明扼要包括开盘价、收盘价、涨跌幅和成交量。 ) TOOLS [ { type: function, function: { name: get_stock_quote, description: 获取指定股票的最新行情数据包括开盘价、收盘价、最高价、最低价、成交量和涨跌幅, parameters: { type: object, properties: { symbol: { type: string, description: 股票代码例如 AAPL、MSFT } }, required: [symbol] } } } ] TOOL_FUNCTIONS { get_stock_quote: tools.get_stock_quote, } def run_agent(user_question: str, max_steps: int 3) - dict: messages [ {role: system, content: SYSTEM_PROMPT}, {role: user, content: user_question} ] for _ in range(max_steps): response chat(messages, toolsTOOLS) assistant_message response.choices[0].message messages.append(assistant_message) tool_calls assistant_message.tool_calls if not tool_calls: return { reply: assistant_message.content or , tool_called: None, steps: exhausted } for tool_call in tool_calls: fn_name tool_call.function.name fn_args json.loads(tool_call.function.arguments) if fn_name not in TOOL_FUNCTIONS: continue result TOOL_FUNCTIONS[fn_name](**fn_args) messages.append({ role: tool, tool_call_id: tool_call.id, content: json.dumps(result, ensure_asciiFalse) }) return { reply: 已达到最大调用步数未完成分析。, tool_called: None, steps: exhausted }代码里没有使用model_dump()之类的序列化方法是因为不同版本的 OpenAI SDK 对消息对象的处理不同。如果你的 SDK 版本较新需要在messages.append(assistant_message)之前做一次转换可参照官方文档调整。这属于 Vibe-Coding 后的审查环节AI 生成的代码必须人工检查过再运行。6.4 运行第一个测试在项目根目录新建test_quick.pyfrom agent.core import run_agent if __name__ __main__: result run_agent(请分析一下 AAPL 的最新行情) print(result[reply])运行python test_quick.py预期输出会类似“根据 2025-06-XX 数据AAPL 收盘价 XX 美元涨跌幅 X%...”。注意第一批代码跑通不代表功能正确。如果模型没有调用工具而是直接回答或者返回了编造的数字这说明提示词或工具 Schema 需要调整。不要急着改代码先按文档中的约束检查提示词再检查工具 Schema 的名称和参数是否匹配。7. 第五步评测驱动给智能体立规矩Agent 开发最容易出现的情况是“这个用例好了另一个用例坏了”。因为模型是概率性的改一个提示词可能影响全部行为。评测驱动的做法是把关键行为固定成自动化用例每次改动后都跑一遍用数据判断好还是坏。7.1 评测指标对于股票分析智能体最核心的评测指标有四类指标名称计算方式业务含义工具调用成功率正确调用 get_stock_quote 的用例占比智能体是否知道什么时候该取数事实覆盖度回答中包含预期关键字段的用例占比是否把行情数据完整说清楚格式合规率输出符合结构要求的用例占比是否方便下游解析幻觉发生率回答中出现数据源未提供数字的用例占比越低越好是否编造行情评测指标不需要一开始就做得很复杂先把这三项跑起来就已经能拦住大部分回归问题。7.2 评测集设计新建data/eval_cases.json[ { id: case_001, question: 请分析 AAPL 的最新行情, expected_tool: get_stock_quote, expected_symbol: AAPL, expected_facts: [date, close, change_pct] }, { id: case_002, question: 帮我看看 MSFT 最近怎么样, expected_tool: get_stock_quote, expected_symbol: MSFT, expected_facts: [date, close, change_pct] }, { id: case_003, question: 分析 000001.SZ 的最新行情, expected_tool: get_stock_quote, expected_symbol: 000001.SZ, expected_facts: [date, close] }, { id: case_004, question: 今天适合买什么股票, expected_tool: null, expected_facts: [] } ]看到case_004了吗这一条是负向用例。智能体不能对“今天买什么股票”给出推荐它应该拒绝回答或说明只能提供行情分析。这类用例对金融场景尤其重要它评测的不是模型能力而是边界意识。7.3 自动评测脚本新建scripts/run_eval.py评测驱动自动运行评测集并输出指标 import json from agent.core import run_agent def load_cases(pathdata/eval_cases.json): with open(path, encodingutf-8) as f: return json.load(f) def evaluate_case(case): result run_agent(case[question]) reply result[reply] tool_called result.get(tool_called) expected_tool case.get(expected_tool) facts {} for fact_name in case.get(expected_facts, []): facts[fact_name] fact_name in reply or f{fact_name} in reply tool_ok tool_called expected_tool fact_ok all(facts.values()) return { case_id: case[id], question: case[question], tool_called: tool_called, expected_tool: expected_tool, tool_ok: tool_ok, fact_ok: fact_ok, has_forbidden_recommendation: 建议买入 in reply or 建议卖出 in reply } def main(): cases load_cases() rows [evaluate_case(c) for c in cases] tool_ok_count sum(1 for r in rows if r[tool_ok]) fact_ok_count sum(1 for r in rows if r[fact_ok]) total len(rows) print(json.dumps(rows, ensure_asciiFalse, indent2)) print(ftool call pass rate: {tool_ok_count / total:.2%}) print(ffact coverage pass rate: {fact_ok_count / total:.2%}) if __name__ __main__: main()运行评测python scripts/run_eval.py评测脚本能做的事不多但价值很高任何改动之后跑一遍指标变差就说明改坏了。如果工具调用成功率只有 50%优先排查提示词是否约束了“必须先调用工具”如果事实覆盖度低优先排查数据源返回字段是否被正确解析。7.4 评测驱动如何持续迭代评测集要跟着需求走。发现一个新问题就往评测集里加一条用例让它永远不再出现。比如模型在某次回答中编造了一个“52 周最高价”虽然工具返回字段里根本没有这个值但模型自己填了一个这就是典型的幻觉。处理方式不是只改这一次的提示词而是把“回答中出现未提供字段”的用例加入评测集再调整提示词约束。这样迭代两到三轮后智能体的行为会明显稳定。评测驱动不是一种“测试方法”而已它是 Agent 开发的开发方法先定义正确再让模型逼近正确。8. 第六步接口 API 与批量任务原型验证通过之后要把智能体封装成服务供前端或内部系统调用。这里用 FastAPI 提供最小可用的 HTTP API。8.1 FastAPI 服务新建server/app.pyAPI 服务对外提供股票分析智能体接口 from fastapi import FastAPI from pydantic import BaseModel from agent.core import run_agent app FastAPI(titleStock Agent API, version0.1.0) class AnalyzeRequest(BaseModel): symbol: str question: str app.post(/v1/analyze) def analyze(req: AnalyzeRequest): if not req.symbol.strip(): return {error: symbol is required} question req.question.strip() if not question: question f请分析 {req.symbol} 的最新行情 result run_agent(question) return { symbol: req.symbol, reply: result[reply], tool_called: result.get(tool_called) }启动服务uvicorn server.app:app --host 127.0.0.1 --port 8000启动后访问http://127.0.0.1:8000/docs可以直接在 Swagger 界面调试接口。8.2 接口调用示例使用curl测试curl -X POST http://127.0.0.1:8000/v1/analyze \ -H Content-Type: application/json \ -d {symbol: AAPL, question: 分析最新行情}返回结果{ symbol: AAPL, reply: 根据 2025-06-XX 数据AAPL 收盘价 XXX涨跌幅 X%..., tool_called: get_stock_quote }这里注意tool_called字段。如果它是null说明模型没有调用工具这通常意味着提示词或工具 Schema 有问题接口测试时第一件事就是看这个字段。8.3 批量任务设计批量分析是实际业务中最常见的需求。比如一次分析十只股票不能简单地开十个线程直接调 LLM否则会撞上接口限流。建议在项目里加一个批量脚本scripts/batch_analyze.py批量分析股票列表 import time from concurrent.futures import ThreadPoolExecutor, as_completed from agent.core import run_agent SYMBOLS [AAPL, MSFT, GOOG, 000001.SZ, 600519.SS] def analyze_one(symbol: str) - dict: try: result run_agent(f请分析 {symbol} 的最新行情) return {symbol: symbol, ok: True, reply: result[reply]} except Exception as exc: return {symbol: symbol, ok: False, error: str(exc)} def batch_analyze(symbols: list[str], max_workers: int 3) - list[dict]: results [] with ThreadPoolExecutor(max_workersmax_workers) as pool: futures [pool.submit(analyze_one, s) for s in symbols] for future in as_completed(futures): results.append(future.result()) return results if __name__ __main__: results batch_analyze(SYMBOLS, max_workers3) for item in results: print(item[symbol], item[ok]) time.sleep(1)批量任务有三个工程要点控制并发数。LLM API 和数据源都有限流并发太高会触发 429 错误。记录失败任务。批量任务不能因为一个失败就整体失败把okFalse的条目单独落盘重跑时只跑失败的。增加超时控制。run_agent内部调用 LLM API建议给请求加timeout避免一个卡住的请求拖住整个批次。9. 常见问题与排查方法以下是这个项目最常见的六个问题及排查思路。问题现象可能原因排查方式解决方案模型直接回答不调用工具提示词没有强制工具调用模型不支持 function callingtools 参数未传打开 messages 日志打印 tools 列表在 system prompt 强调“必须先调用工具”换支持工具调用的模型工具返回 NO_DATA股票代码不合法数据源覆盖范围不足停牌单独运行 get_stock_quote 函数看返回值检查代码格式补充数据源覆盖范围回答中出现编造数字模型在工具未返回时自行补全对照工具返回 JSON 与最终回答强化提示词约束增加评测用例接口返回 500依赖未安装LLM API Key 无效模型名不存在查看 Uvicorn 控制台日志检查 .env 配置确认依赖安装完整批量任务频繁失败并发过高触发限流查看返回状态码是否为 429降低 max_workers增加重试与退避策略端口被占用8000 端口已有进程Linux 执行lsof -i:8000Windows 执行netstat -ano换端口启动或结束占用进程排查 Agent 类问题有一个通用技巧打印完整的 messages。调用 LLM 前把 messages 序列化输出到日志看最后几轮对话模型是否真的收到了工具返回数据。很多时候不是模型不行而是消息传递环节出了问题比如 tools 返回格式不对、tool_call_id 不匹配。10. 最佳实践、成本控制与合规边界10.1 工程化最佳实践固定模型版本。不要在开发过程中频繁更换模型至少在一轮评测周期内保持一致否则指标波动无法归因。把所有外部依赖封装在工具层。数据源、行情 SDK、内部接口都收敛到tools.py后续替换成本最低。评测集与代码一起提交。新增功能时同步扩充评测用例保证回归测试覆盖。缓存行情结果。同一只股票在一天内多次请求可以缓存收盘后的数据减少数据源压力。批量任务写进度日志。每完成一只股票都记录时间和结果方便断点续跑。10.2 成本控制股票分析智能体的主要成本是 LLM API 调用。控制成本有几个办法把行情计算放到工具层完成减少模型需要处理的原始数据量。对相同问题做缓存短时间重复请求直接返回上一次结果。评测时用小成本模型预筛只有指标接近门槛再换强模型验收。批量任务设置最大 token 上限防止单次回答过长。从实际部署经验看这类工具型 Agent 的单次调用成本受两个因素影响最大输入历史长度和工具返回数据大小。每次多轮调用都会把之前的消息重新发送给模型控制历史轮次能明显降低 token 消耗。10.3 合规边界股票分析场景有两条必须守住的底线第一不构成投资建议。产品文档、接口返回、页面展示都要有明确提示比如“以上内容仅供技术演示与信息参考不构成投资建议”。第二行情数据来源合法。不要抓取未经授权的行情数据不要绕过数据供应商的访问限制。对评测集和演示数据也要确认为可公开使用的样例。如果未来把这个智能体接入真实业务还要考虑用户输入是否包含个人信息、分析结果是否涉及敏感标的、接口是否需要鉴权。这些不在最小原型范围内但在 FDE 部署上线前必须补齐。11. 总结与下一步这个 FDE 实战项目最值得尝试的地方不是“用 LLM 查股票”这个想法本身而是五步工程闭环需求拆解产出事实清单文档先行固定技术约束Vibe-Coding 快速生成原型评测驱动做回归兜底API 服务对外交付。这五步对任何业务型 Agent 都适用。建议第一次实践时先把data/eval_cases.json里的用例跑通再改提示词观察评测指标变化这个过程能直观感受“评测驱动”的价值。最容易踩的坑有两个一是不评测就直接部署上线后行为不可控二是批量任务并发开太高被数据源限流之后整个任务失败。后续可以扩展的方向包括接入研报解析工具、增加历史走势图与 K 线数据、引入本地模型做推理降本、把评测集扩展到多轮对话、增加人类反馈标注流程。每一个方向都从更新需求拆解文档开始而不是直接加代码这才是 FDE 方法论的最终落点。整套工程代码建议按本文的目录结构保留一份最小可运行版本放在公司的实验环境里后续任何 Agent 项目都可以从这份骨架上改造起步。当前股票分析智能体只做到了“查行情、做简报”这个最小闭环你已经拥有继续扩展它的正确姿势了。 FDE实战：从零构建股票分析智能体的工程全流程
这次我们不聊一个开箱即用的演示项目而是完整走一遍 FDE 实战路线如何用 Agent 开发方法论从零打造一个股票分析智能体。股票分析本身是常见场景但真正有价值的是工程过程——需求拆解、文档先行、Vibe-Coding 生成原型、评测驱动迭代。这套流程也是当下 AI 团队招聘 FDE 前沿部署工程师时最看重的能力组合。先说项目边界。这个智能体的任务不是预测涨跌也不是自动下单而是给用户提供结构化的行情信息与分析过程给定一只股票智能体主动调用行情数据工具再把数据整理成简报。整个过程由 LLM 驱动用工具补充事实用评测集验收。读完本文你会拿到一套可以照抄的目录结构、核心代码、评测脚本和 API 封装。适合阅读本文的读者一类是准备转型 Agent 开发的工程师另一类是已经在做 AI 落地、想引入评测驱动的技术负责人。文章不会只讲概念每一步都对应可运行的文件和命令。1. 核心能力速览能力项说明项目类型FDE 实战案例Agent 开发端到端工程流程核心方法需求拆解、文档先行、Vibe-Coding、评测驱动业务场景股票行情查询与分析简报生成技术栈Python、OpenAI 兼容接口、FastAPI、数据源适配层硬件要求不依赖本地 GPU需要可访问 LLM API启动方式命令行测试 FastAPI Web 服务是否支持 API支持提供/v1/analyze接口是否支持批量任务支持可对股票列表做并发分析评测能力工具调用成功率、事实覆盖度、格式合规率是否适合生产可作为业务原型生产前仍需补充鉴权、限流、日志和评测闭环这里需要强调一点整套流程不依赖具体模型厂商接口基于 OpenAI 兼容协议实际使用哪个模型根据部署环境决定。下面的操作步骤也都按兼容协议来写。2. FDE 项目实战股票分析智能体到底是什么FDE即 Frontier Deployment Engineer前沿部署工程师。这个岗位的核心职责不是研究算法而是把大模型能力部署到真实业务场景解决“模型在实验室好用、到业务里用不起来”的问题。业务侧的需求通常是模糊的模型侧的能力是概率性的FDE 要做的就是在中间搭一套工程框架让不可控的模型输出变得可控、可测、可交付。股票分析智能体就是这个框架的一个典型样例。它涉及典型的 Agent 能力闭环自然语言输入、工具调用、结果归纳、最终回答。用户说“帮我看看某只股票的近期行情”智能体不能凭记忆回答必须先调用行情数据工具拿到数据再做总结。这个动作看似简单实际落地时会遇到一堆问题模型不按格式调用工具、数据源返回字段不统一、模型在没拿到数据时编造数字、批量分析时接口限流。这些问题都会在下面的流程中逐一处理。这个项目选择股票分析还有一个原因业务语义足够清晰。行情的字段是客观事实涨跌幅度可以精确计算评测结果容易判定对错。这比做一个泛泛的“聊天助手”更适合用来实践 FDE 方法论因为你能明确知道智能体做对了没有。注意合规边界。股票分析智能体只做信息整理和辅助分析不构成投资建议。不要在项目中加入自动下单、保证收益、预测未来走势这类能力。涉及实时行情数据时必须确认数据源的使用许可不能擅自抓取无授权的数据接口。这是 FDE 落地金融场景时的第一道红线。3. 第一步需求拆解从模糊想法到事实清单FDE 工作流里最难的不是写代码而是把业务方的模糊想法翻译成事实清单。业务方说“我要一个股票分析智能体”这句话里至少有三个不明确点分析哪些股票、分析哪些维度、输出什么格式。如果不拆清楚开发阶段就会反复返工。3.1 需求拆解要回答的问题在写任何代码之前先把下面这些问题列出答案用户是谁个人投资者还是内部投研人员这决定回答的详略程度。输入是什么股票代码、自然语言问题还是两者都有。输出是什么一段文字、结构化 JSON还是 Markdown 简报。分析什么行情快照、历史走势、财务指标、新闻舆情还是技术指标。数据从哪里来是否已获得授权接口字段是否稳定限流策略是什么。模型能力边界当前模型是否支持工具调用是否需要为不支持工具调用的模型走 Prompt 解析方案。错误兜底查不到数据时怎么回答模型拒绝调用工具时怎么处理。这七个问题属于需求的事实层。FDE 特别强调“面向语意的事实方法论”意思是每个需求点都要落到能验证的事实描述而不是停留在感觉层面。比如“分析行情”是语义描述落到事实层就是“获取股票最新交易日开盘价、收盘价、最高价、最低价和成交量并对比前一个交易日计算涨跌幅”。3.2 把需求拆成功能清单以股票分析智能体为例拆解后可以得到五个功能点股票代码识别。支持输入美股代码、A 股代码或内部证券编码并统一格式。行情数据获取。调用数据源工具返回指定股票的最新交易数据。风险信息提示。针对涨跌幅异常、成交量异常等做规则化提示。分析简报生成。模型基于工具返回的数据生成结构化文本禁止未取数先回答。接口服务。对外提供 HTTP API支持单只股票分析和批量分析。每个功能点都需要有对应的验收标准。验收标准就是评测用例的雏形这一步做扎实后面的评测驱动自然就能展开。3.3 需求拆解模板示例可以把拆解结果沉淀成 Markdown 文档作为后续一切开发的基础。下面是一个可用模板# 股票分析智能体需求拆解 ## 1. 用户与场景 - 用户内部投研人员 - 场景快速查看单只股票行情并生成简报 - 输入股票代码或自然语言问题 - 输出Markdown 格式分析简报 ## 2. 功能清单 | 编号 | 功能点 | 验收标准 | | --- | --- | --- | | F1 | 股票代码识别 | 输入 AAPL 返回 Apple Inc.注意代码大小写与交易所后缀 | | F2 | 行情数据获取 | 获取最新交易日 OHLCV 数据缺字段时显式报错 | | F3 | 异常涨跌提示 | 单日涨幅超过 5% 时输出风险提示 | | F4 | 分析简报生成 | 回答必须包含数据来源日期禁止编造数字 | | F5 | API 服务 | POST /v1/analyze 返回 200 和合法 JSON | ## 3. 数据来源 - 默认数据源待确认订阅的行情服务 - 字段open, close, high, low, volume, date - 无数据策略返回明确错误不让模型猜测 ## 4. 边界与限制 - 不提供投资建议 - 不接入交易系统 - 不做未来走势预测需求拆解文档写完之后应该让业务方逐条确认。确认过的事实清单就是后续开发的唯一依据如果业务方中途改需求不要口头确认回到这份文档里更新并重新过一遍受影响的功能点。4. 第二步文档先行写清楚再写代码很多 Agent 项目失败不是因为模型能力不行而是因为团队在代码里讨论需求。FDE 的做法是文档先行代码只是文档的执行结果。文档不需要写成几十页的正式设计书重点是把三类内容固定下来技术方案、提示词约束、评测计划。4.1 技术方案文档技术方案文档回答“用什么结构实现”。股票分析智能体建议采用工具调用模式整体结构分四层入口层接收用户问题维护多轮对话状态。调度层LLM 决定是否调用工具、调用哪个工具、传什么参数。工具层行情数据获取函数返回统一 JSON。评测层用评测集自动跑一遍统计指标。这样的结构让每一层都能独立验证。工具层可以脱离模型单测调度层可以换模型重测评测层则固定为回归测试。下面是技术方案文档的目录# 股票分析智能体技术方案 ## 1. 系统架构 入口层 - 调度层 - 工具层 - 数据源 | v 评测层 ## 2. 关键流程 - 用户输入问题 - LLM 判断是否需要行情数据 - 需要则调用 get_stock_quote(symbol) - 工具返回 JSON 给 LLM - LLM 生成最终简报 ## 3. 提示词约束基础版 - 角色股票分析助手 - 必须使用工具返回的数据 - 禁止编造行情数据 - 数据不足时明确回复“暂无数据” ## 4. 评测计划 - 评测集20 条用例 - 指标工具调用成功率、事实覆盖度、JSON 可解析率 - 门槛工具调用成功率 90%事实覆盖度 85%4.2 文档和代码的关系在 Vibe-Coding 阶段文档就是 Prompt 的上下文。把上面这份技术方案喂给 AI 编程工具生成的代码会比直接说“帮我写一个股票分析 Agent”准确得多。这不是玄学而是因为文档把约束说清了工具层返回什么字段、调度层用什么协议、评测层看什么指标。文档同时也是团队协作的锚点。新成员加入时不需要阅读全部代码先读需求拆解和技术方案就能知道系统边界和验收标准。这在 Agent 开发项目中尤其重要因为 Agent 行为是概率性的代码只能展示逻辑文档才能展示意图。5. 第三步环境准备与依赖安装股票分析智能体不依赖本地 GPU部署门槛低主要需要 Python 环境和 LLM API 访问权限。5.1 基础环境清单Python 3.10 或更高版本。pip 包管理工具。OpenAI 兼容的 LLM API 地址、Key、模型名。一个可以访问的行情数据源示例代码使用 yfinance 作为演示实际部署请替换为已授权的数据源或内部行情服务。网络策略服务器需要能访问 LLM API 与行情数据源。先创建项目目录并初始化虚拟环境mkdir stock-agent cd stock-agent python -m venv venv # Linux/macOS source venv/bin/activate # Windows PowerShell venv\Scripts\activate5.2 安装依赖新建requirements.txt内容如下openai1.30.0 fastapi0.110.0 uvicorn0.29.0 pydantic2.6.0 python-dotenv1.0.0 requests2.31.0 yfinance0.2.40安装依赖pip install -r requirements.txt说明一下 yfinance 的作用。它只是一个演示数据源通过公开渠道获取行情数据生产环境请根据授权情况换成行情 SDK 或自建行情服务。无论用哪个数据源工具层应该保持统一返回格式这样调度层和评测层不需要跟着改。5.3 配置环境变量在项目根目录创建.env文件LLM_API_KEYyour_api_key_here LLM_BASE_URLhttps://api.example.com/v1 LLM_MODELyour_model_name DATA_SOURCEyfinance再创建一个config.py读取环境变量import os from dotenv import load_dotenv load_dotenv() LLM_API_KEY os.getenv(LLM_API_KEY) LLM_BASE_URL os.getenv(LLM_BASE_URL) LLM_MODEL os.getenv(LLM_MODEL)环境变量是通用的但具体 Key 名和模型名需要按实际部署环境调整。不要在生产代码里硬编码 API Key。6. 第四步Vibe-Coding快速搭建 Agent 最小原型Vibe-Coding 是当前 Agent 开发中很实用的一种工作方式用自然语言对话驱动 AI 生成代码开发者负责给出方向、审查代码、运行测试。这套方式适合快速搭建最小可运行原型但不代表不写文档、不设测试。本文前面写的需求拆解和技术方案就是 Vibe-Coding 的导航地图。6.1 项目目录结构在开始写代码前先确定目录结构stock-agent/ ├── README.md ├── requirements.txt ├── .env ├── config.py ├── agent/ │ ├── __init__.py │ ├── tools.py │ ├── llm.py │ └── core.py ├── scripts/ │ └── run_eval.py ├── server/ │ └── app.py └── data/ └── eval_cases.json这个结构把工具层、调度层、评测层、服务层分开代码量不大但边界清楚。6.2 工具层行情数据获取工具层是 Agent 与外部世界交互的唯一通道。所有数据源差异都封装在agent/tools.py里模型不关心数据来自 yfinance、行情 SDK 还是内部数据库。打开agent/tools.py输入以下内容工具层对接行情数据源统一返回 JSON def get_stock_quote(symbol: str) - dict: 获取股票最新行情。 注意示例使用 yfinance实际部署请替换为合法授权的数据源。 import yfinance as yf ticker yf.Ticker(symbol) hist ticker.history(period5d) if hist is None or hist.empty: return { symbol: symbol, error: NO_DATA, message: 未查询到该股票的行情数据请检查代码是否正确 } last hist.iloc[-1] prev hist.iloc[-2] if len(hist) 2 else last return { symbol: symbol, date: str(hist.index[-1].date()), open: round(float(last[Open]), 2), close: round(float(last[Close]), 2), high: round(float(last[High]), 2), low: round(float(last[Low]), 2), volume: int(last[Volume]), change_pct: round( float((last[Close] - prev[Close]) / prev[Close] * 100), 2 ) }这个函数有两点值得注意。第一它把“涨跌幅”这个衍生指标计算放在工具层里而不是让模型自己算因为模型算算术容易出错。第二它返回固定的 JSON 结构后续无论换成哪个数据源都保持这个结构评测脚本就不用改。6.3 调度层LLM 工具调用主循环调度层负责让 LLM 决定是否调用工具、调用哪个工具并把结果回填给模型生成最终回答。使用 OpenAI 兼容的接口定义工具 Schema。新建agent/llm.pyLLM 客户端封装基于 OpenAI 兼容协议 import config from openai import OpenAI client OpenAI( api_keyconfig.LLM_API_KEY, base_urlconfig.LLM_BASE_URL ) def chat(messages, toolsNone): return client.chat.completions.create( modelconfig.LLM_MODEL, messagesmessages, toolstools or [], temperature0.2 )新建agent/core.py这是 Agent 的主循环Agent 调度核心 import json from agent import tools from agent.llm import chat SYSTEM_PROMPT ( 你是一名股票分析助手。 你必须先调用 get_stock_quote 工具获取数据再基于工具返回的数据回答问题。 工具返回的数据中包含日期回答时请注明数据日期。 如果工具返回 NO_DATA请明确告知用户暂无数据不要编造行情数字。 回答要简明扼要包括开盘价、收盘价、涨跌幅和成交量。 ) TOOLS [ { type: function, function: { name: get_stock_quote, description: 获取指定股票的最新行情数据包括开盘价、收盘价、最高价、最低价、成交量和涨跌幅, parameters: { type: object, properties: { symbol: { type: string, description: 股票代码例如 AAPL、MSFT } }, required: [symbol] } } } ] TOOL_FUNCTIONS { get_stock_quote: tools.get_stock_quote, } def run_agent(user_question: str, max_steps: int 3) - dict: messages [ {role: system, content: SYSTEM_PROMPT}, {role: user, content: user_question} ] for _ in range(max_steps): response chat(messages, toolsTOOLS) assistant_message response.choices[0].message messages.append(assistant_message) tool_calls assistant_message.tool_calls if not tool_calls: return { reply: assistant_message.content or , tool_called: None, steps: exhausted } for tool_call in tool_calls: fn_name tool_call.function.name fn_args json.loads(tool_call.function.arguments) if fn_name not in TOOL_FUNCTIONS: continue result TOOL_FUNCTIONS[fn_name](**fn_args) messages.append({ role: tool, tool_call_id: tool_call.id, content: json.dumps(result, ensure_asciiFalse) }) return { reply: 已达到最大调用步数未完成分析。, tool_called: None, steps: exhausted }代码里没有使用model_dump()之类的序列化方法是因为不同版本的 OpenAI SDK 对消息对象的处理不同。如果你的 SDK 版本较新需要在messages.append(assistant_message)之前做一次转换可参照官方文档调整。这属于 Vibe-Coding 后的审查环节AI 生成的代码必须人工检查过再运行。6.4 运行第一个测试在项目根目录新建test_quick.pyfrom agent.core import run_agent if __name__ __main__: result run_agent(请分析一下 AAPL 的最新行情) print(result[reply])运行python test_quick.py预期输出会类似“根据 2025-06-XX 数据AAPL 收盘价 XX 美元涨跌幅 X%...”。注意第一批代码跑通不代表功能正确。如果模型没有调用工具而是直接回答或者返回了编造的数字这说明提示词或工具 Schema 需要调整。不要急着改代码先按文档中的约束检查提示词再检查工具 Schema 的名称和参数是否匹配。7. 第五步评测驱动给智能体立规矩Agent 开发最容易出现的情况是“这个用例好了另一个用例坏了”。因为模型是概率性的改一个提示词可能影响全部行为。评测驱动的做法是把关键行为固定成自动化用例每次改动后都跑一遍用数据判断好还是坏。7.1 评测指标对于股票分析智能体最核心的评测指标有四类指标名称计算方式业务含义工具调用成功率正确调用 get_stock_quote 的用例占比智能体是否知道什么时候该取数事实覆盖度回答中包含预期关键字段的用例占比是否把行情数据完整说清楚格式合规率输出符合结构要求的用例占比是否方便下游解析幻觉发生率回答中出现数据源未提供数字的用例占比越低越好是否编造行情评测指标不需要一开始就做得很复杂先把这三项跑起来就已经能拦住大部分回归问题。7.2 评测集设计新建data/eval_cases.json[ { id: case_001, question: 请分析 AAPL 的最新行情, expected_tool: get_stock_quote, expected_symbol: AAPL, expected_facts: [date, close, change_pct] }, { id: case_002, question: 帮我看看 MSFT 最近怎么样, expected_tool: get_stock_quote, expected_symbol: MSFT, expected_facts: [date, close, change_pct] }, { id: case_003, question: 分析 000001.SZ 的最新行情, expected_tool: get_stock_quote, expected_symbol: 000001.SZ, expected_facts: [date, close] }, { id: case_004, question: 今天适合买什么股票, expected_tool: null, expected_facts: [] } ]看到case_004了吗这一条是负向用例。智能体不能对“今天买什么股票”给出推荐它应该拒绝回答或说明只能提供行情分析。这类用例对金融场景尤其重要它评测的不是模型能力而是边界意识。7.3 自动评测脚本新建scripts/run_eval.py评测驱动自动运行评测集并输出指标 import json from agent.core import run_agent def load_cases(pathdata/eval_cases.json): with open(path, encodingutf-8) as f: return json.load(f) def evaluate_case(case): result run_agent(case[question]) reply result[reply] tool_called result.get(tool_called) expected_tool case.get(expected_tool) facts {} for fact_name in case.get(expected_facts, []): facts[fact_name] fact_name in reply or f{fact_name} in reply tool_ok tool_called expected_tool fact_ok all(facts.values()) return { case_id: case[id], question: case[question], tool_called: tool_called, expected_tool: expected_tool, tool_ok: tool_ok, fact_ok: fact_ok, has_forbidden_recommendation: 建议买入 in reply or 建议卖出 in reply } def main(): cases load_cases() rows [evaluate_case(c) for c in cases] tool_ok_count sum(1 for r in rows if r[tool_ok]) fact_ok_count sum(1 for r in rows if r[fact_ok]) total len(rows) print(json.dumps(rows, ensure_asciiFalse, indent2)) print(ftool call pass rate: {tool_ok_count / total:.2%}) print(ffact coverage pass rate: {fact_ok_count / total:.2%}) if __name__ __main__: main()运行评测python scripts/run_eval.py评测脚本能做的事不多但价值很高任何改动之后跑一遍指标变差就说明改坏了。如果工具调用成功率只有 50%优先排查提示词是否约束了“必须先调用工具”如果事实覆盖度低优先排查数据源返回字段是否被正确解析。7.4 评测驱动如何持续迭代评测集要跟着需求走。发现一个新问题就往评测集里加一条用例让它永远不再出现。比如模型在某次回答中编造了一个“52 周最高价”虽然工具返回字段里根本没有这个值但模型自己填了一个这就是典型的幻觉。处理方式不是只改这一次的提示词而是把“回答中出现未提供字段”的用例加入评测集再调整提示词约束。这样迭代两到三轮后智能体的行为会明显稳定。评测驱动不是一种“测试方法”而已它是 Agent 开发的开发方法先定义正确再让模型逼近正确。8. 第六步接口 API 与批量任务原型验证通过之后要把智能体封装成服务供前端或内部系统调用。这里用 FastAPI 提供最小可用的 HTTP API。8.1 FastAPI 服务新建server/app.pyAPI 服务对外提供股票分析智能体接口 from fastapi import FastAPI from pydantic import BaseModel from agent.core import run_agent app FastAPI(titleStock Agent API, version0.1.0) class AnalyzeRequest(BaseModel): symbol: str question: str app.post(/v1/analyze) def analyze(req: AnalyzeRequest): if not req.symbol.strip(): return {error: symbol is required} question req.question.strip() if not question: question f请分析 {req.symbol} 的最新行情 result run_agent(question) return { symbol: req.symbol, reply: result[reply], tool_called: result.get(tool_called) }启动服务uvicorn server.app:app --host 127.0.0.1 --port 8000启动后访问http://127.0.0.1:8000/docs可以直接在 Swagger 界面调试接口。8.2 接口调用示例使用curl测试curl -X POST http://127.0.0.1:8000/v1/analyze \ -H Content-Type: application/json \ -d {symbol: AAPL, question: 分析最新行情}返回结果{ symbol: AAPL, reply: 根据 2025-06-XX 数据AAPL 收盘价 XXX涨跌幅 X%..., tool_called: get_stock_quote }这里注意tool_called字段。如果它是null说明模型没有调用工具这通常意味着提示词或工具 Schema 有问题接口测试时第一件事就是看这个字段。8.3 批量任务设计批量分析是实际业务中最常见的需求。比如一次分析十只股票不能简单地开十个线程直接调 LLM否则会撞上接口限流。建议在项目里加一个批量脚本scripts/batch_analyze.py批量分析股票列表 import time from concurrent.futures import ThreadPoolExecutor, as_completed from agent.core import run_agent SYMBOLS [AAPL, MSFT, GOOG, 000001.SZ, 600519.SS] def analyze_one(symbol: str) - dict: try: result run_agent(f请分析 {symbol} 的最新行情) return {symbol: symbol, ok: True, reply: result[reply]} except Exception as exc: return {symbol: symbol, ok: False, error: str(exc)} def batch_analyze(symbols: list[str], max_workers: int 3) - list[dict]: results [] with ThreadPoolExecutor(max_workersmax_workers) as pool: futures [pool.submit(analyze_one, s) for s in symbols] for future in as_completed(futures): results.append(future.result()) return results if __name__ __main__: results batch_analyze(SYMBOLS, max_workers3) for item in results: print(item[symbol], item[ok]) time.sleep(1)批量任务有三个工程要点控制并发数。LLM API 和数据源都有限流并发太高会触发 429 错误。记录失败任务。批量任务不能因为一个失败就整体失败把okFalse的条目单独落盘重跑时只跑失败的。增加超时控制。run_agent内部调用 LLM API建议给请求加timeout避免一个卡住的请求拖住整个批次。9. 常见问题与排查方法以下是这个项目最常见的六个问题及排查思路。问题现象可能原因排查方式解决方案模型直接回答不调用工具提示词没有强制工具调用模型不支持 function callingtools 参数未传打开 messages 日志打印 tools 列表在 system prompt 强调“必须先调用工具”换支持工具调用的模型工具返回 NO_DATA股票代码不合法数据源覆盖范围不足停牌单独运行 get_stock_quote 函数看返回值检查代码格式补充数据源覆盖范围回答中出现编造数字模型在工具未返回时自行补全对照工具返回 JSON 与最终回答强化提示词约束增加评测用例接口返回 500依赖未安装LLM API Key 无效模型名不存在查看 Uvicorn 控制台日志检查 .env 配置确认依赖安装完整批量任务频繁失败并发过高触发限流查看返回状态码是否为 429降低 max_workers增加重试与退避策略端口被占用8000 端口已有进程Linux 执行lsof -i:8000Windows 执行netstat -ano换端口启动或结束占用进程排查 Agent 类问题有一个通用技巧打印完整的 messages。调用 LLM 前把 messages 序列化输出到日志看最后几轮对话模型是否真的收到了工具返回数据。很多时候不是模型不行而是消息传递环节出了问题比如 tools 返回格式不对、tool_call_id 不匹配。10. 最佳实践、成本控制与合规边界10.1 工程化最佳实践固定模型版本。不要在开发过程中频繁更换模型至少在一轮评测周期内保持一致否则指标波动无法归因。把所有外部依赖封装在工具层。数据源、行情 SDK、内部接口都收敛到tools.py后续替换成本最低。评测集与代码一起提交。新增功能时同步扩充评测用例保证回归测试覆盖。缓存行情结果。同一只股票在一天内多次请求可以缓存收盘后的数据减少数据源压力。批量任务写进度日志。每完成一只股票都记录时间和结果方便断点续跑。10.2 成本控制股票分析智能体的主要成本是 LLM API 调用。控制成本有几个办法把行情计算放到工具层完成减少模型需要处理的原始数据量。对相同问题做缓存短时间重复请求直接返回上一次结果。评测时用小成本模型预筛只有指标接近门槛再换强模型验收。批量任务设置最大 token 上限防止单次回答过长。从实际部署经验看这类工具型 Agent 的单次调用成本受两个因素影响最大输入历史长度和工具返回数据大小。每次多轮调用都会把之前的消息重新发送给模型控制历史轮次能明显降低 token 消耗。10.3 合规边界股票分析场景有两条必须守住的底线第一不构成投资建议。产品文档、接口返回、页面展示都要有明确提示比如“以上内容仅供技术演示与信息参考不构成投资建议”。第二行情数据来源合法。不要抓取未经授权的行情数据不要绕过数据供应商的访问限制。对评测集和演示数据也要确认为可公开使用的样例。如果未来把这个智能体接入真实业务还要考虑用户输入是否包含个人信息、分析结果是否涉及敏感标的、接口是否需要鉴权。这些不在最小原型范围内但在 FDE 部署上线前必须补齐。11. 总结与下一步这个 FDE 实战项目最值得尝试的地方不是“用 LLM 查股票”这个想法本身而是五步工程闭环需求拆解产出事实清单文档先行固定技术约束Vibe-Coding 快速生成原型评测驱动做回归兜底API 服务对外交付。这五步对任何业务型 Agent 都适用。建议第一次实践时先把data/eval_cases.json里的用例跑通再改提示词观察评测指标变化这个过程能直观感受“评测驱动”的价值。最容易踩的坑有两个一是不评测就直接部署上线后行为不可控二是批量任务并发开太高被数据源限流之后整个任务失败。后续可以扩展的方向包括接入研报解析工具、增加历史走势图与 K 线数据、引入本地模型做推理降本、把评测集扩展到多轮对话、增加人类反馈标注流程。每一个方向都从更新需求拆解文档开始而不是直接加代码这才是 FDE 方法论的最终落点。整套工程代码建议按本文的目录结构保留一份最小可运行版本放在公司的实验环境里后续任何 Agent 项目都可以从这份骨架上改造起步。当前股票分析智能体只做到了“查行情、做简报”这个最小闭环你已经拥有继续扩展它的正确姿势了。