从去年开始“AI Agent”这个词在圈子里快被说烂了。但大多数讨论要么停在概念层面要么就是拿通用场景炫技。我自己一直做商品期货研究平时最烦的事情就是日报——尤其是PTA这种产业链长、数据维度多的品种每天早上光是把价格、价差、库存、开工率这些数据整理齐再拼出一段像样的逻辑点评没一两个小时根本下不来。所以当本地大模型跑起来之后我第一个想做的事情就是能不能让一个Agent住在我的电脑里帮我把PTA日报的活干了。这篇文章不是概念科普也不是那种“Agent改变世界”的宏大叙事。我直接给你看我实际搭出来的这套系统它能做什么、不能做什么、用了哪些组件、踩了哪些坑以及最后产出的日报长什么样。如果你也在做期货研究或者对“本地部署AI Agent做垂直领域自动化”这件事感兴趣这篇文章应该能帮你省掉不少试错时间。1. 先把话说清楚这个项目到底在解决什么问题1.1 PTA日报这个场景的痛点在哪儿PTA是精对苯二甲酸的简称上游是PX下游是聚酯和纺织整条产业链长影响因素杂。一份合格的PTA日报至少要有以下几块内容期货盘面数据主力合约收盘价、涨跌幅、成交量、持仓量变化近远月价差结构现货跟基差华东PTA现货价格、基差走势仓单数量变化成本利润PX价格、PTA加工费即期加工费、盘面加工费、聚酯产品利润供需数据PTA装置开停车动态、开工率聚酯开工率、织造开工率库存情况消息面与逻辑点评把上面这些数据串起来解释当天行情为什么涨、为什么跌给出短期关注重点。你发现没有前四块是“死数据”标准、可查、重复性极高但采集和整理非常耗时。第五块是“活逻辑”需要人对产业链有理解但本质上也是在固定框架里做梳理和判断。这两个特点加在一起正好是Agent擅长的事情——固定流程的自动化执行加上基于规则和知识库的文本生成。1.2 Agent在期货研究里到底该扮演什么角色在动手之前我先把定位想清楚了。Agent不是用来代替研究员做主观判断的更不可能替你预测行情。它真正能解放你的是“从数据到初稿”这中间的一大段重复劳动。打个比方以前每天早上我像流水线工人打开文华、打开Wind、打开隆众资讯把十几个数字抄进Excel再对着模板填点评最后截图发给群里。这套流程毫无创造性但一天都不能断。Agent要做的就是把我从流水线上换下来它负责把数据采齐、把表格填好、把第一版点评写出来我只需要在它完成的基础上做复核、修正、补充——从一个“写日报的人”变成一个“审日报的人”。所以我给这个项目划定了三条边界数据必须可追溯Agent给的每一个关键数字都要能对应到原始数据源逻辑点评只做“基于数据的客观梳理”不输出预测性结论最终决策权永远在人手里Agent产出的是草稿不是答案。这三条边界在后来的开发过程中帮我避免了很多折腾也让这套系统的定位非常清晰——它是一个“研究助理”不是一个“研究员”。2. 整体设计思路与选型拆解为什么非要本地部署2.1 先回答最核心的问题用在线API不行吗这是每个听说我这个项目的人都会问的第一句话。说实话如果单纯从效果上看用GPT-4或者Claude的API生成日报点评的质量确实会更好开发成本也更低。我一开始也试过但用下来有三个难以接受的问题数据隐私和合规期货研究涉及的持仓、策略、关注品种这些数据相当敏感。把日报相关的原始数据全部丢给外部API哪怕在协议上是“会话级隔离”我的心理防线也过不去。研究业务的数据合规要求会越来越严提前把数据留在本地是成本最低的合规措施。成本是细水长流地放血日报是每天都要跑的任务如果每天用API生成几千字的报告一个月下来是一笔固定支出。单独为了这个项目不太值得。本地部署的硬件是一次性投入长期摊薄下来成本低得多。可控性和定制自由度在线API是个黑盒提示词调优、模型微调、输出格式控制都受限。本地部署之后我可以任意换模型、改参数、改预处理逻辑甚至给Agent挂上外挂工具完全掌控整个流程。当然本地部署也有明显的短板模型能力天花板比顶级在线API低硬件投入有门槛运维需要自己来。但只要把预期放对位置——我要的不是最强文案能力而是稳定、可控、低成本地把固定流程跑起来——本地部署就是更优解。2.2 架构设计Agent不是一个模型是一套流水线很多人把“AI Agent”理解成“一个很聪明的大模型”这是个误区。在我这套系统里Agent是一个由多个模块组成的自动化流程大模型只是其中的“大脑”而已。整个架构我分成三层数据层负责从各个数据源抓取原始数据包括期货行情、现货报价、装置动态、库存数据等。这一层做的事情不涉及AI就是常规的爬虫和API调用。逻辑层负责调度、处理和分析。包括数据清洗、指标计算、格式化以及调用大模型进行文字生成。交互层负责把结果呈现给用户也就是最终的日报文档。用一张表格看更清楚层级核心职责具体工具/技术数据层多源采集、数据标准化Python爬虫、交易所/资讯平台API逻辑层指标计算、数据分析、文本生成Ollama 本地大模型具体见下交互层日报生成、定时推送Markdown模板、定时任务调度这套架构最大的好处是“模块之间解耦”。数据层出问题了不影响逻辑层模型效果不理想可以单独换模型不用动其他代码。对个人项目来说这种可维护性太重要了——你不用每次改动都把整个系统重跑一遍。2.3 具体选型Ollama DeepSeek为什么是这个组合本地跑大模型现在主流方案基本是Ollama、Llama.cpp、vLLM这几个。我最终选了Ollama原因很朴素安装和上手成本最低一条命令就能拉模型、跑服务对个人电脑友好CPU和GPU都能跑显存不够也能硬撑自带API服务默认端口是11434可以直接用Python调用不用自己写推理代码。模型选的是DeepSeek-R1 的 7B 蒸馏版。选七亿参数量级是因为我本地的显卡不算太高配RTX 3060 12G这个量级的模型跑起来速度和效果比较平衡。DeepSeek-R1 系列继承了推理模型的优势在逻辑推导、结构化输出上的表现比同尺寸的通用模型好不少刚好适合日报这种需要分步骤分析的场景。实际用下来7B模型在期货领域的常识储备不算强但它的优势在于“规则执行能力”——只要我把数据给到位、把分析框架写清楚它能在这个框架里产出质量相当稳定的文字。换句话说它不擅长自己发挥但很擅长按规矩办事这正好符合日报场景的需求。3. 核心能力拆解一份PTA日报背后的Agent工作流3.1 数据获取让Agent从“看盘”变成“读数据”Agent要干活首先得有数据。PTA日报涉及的数据维度多我没有试图用一个万能爬虫搞定所有来源而是按数据类型分了三路期货行情数据用新浪财经和交易所官网的公开接口直接拿主力合约的日线数据包括收盘价、最高价、最低价、成交量、持仓量、结算价。这里要注意不同数据源的字段定义不一样比如“持仓量变化”有些接口给的是当日值有些给的是差值必须统一口径。现货和基差数据从CCFEI中国化纤信息网和隆众资讯抓取PTA华东现货价格、PX价格。这两个网站的数据是行业公认基准但反爬机制一直存在我的做法是尽量低频访问、做好缓存不让对方服务器有压力。装置和库存数据从行业资讯网站和公开新闻里提取装置开停车信息、PTA库存、聚酯开工率。这部分数据最难自动化因为很多信息藏在新闻稿里不是结构化数据。我的做法是对关键词做规则匹配——比如“停车”“检修”“重启”“提负”这类词配合装置名称和日期提取出结构化事件。需要说明的是数据抓取这件事合规边界一定要守住。我只抓公开的、允许访问的数据不做暴力爬取不绕过登录验证不抓非公开数据。速率控制也做得比较保守每两次请求之间至少间隔几秒。研究用的数据值得多等一会儿不值得冒合规风险。3.2 指标计算日报里那些数字是怎么算出来的原始数据到手只是第一步日报里真正有价值的是那些“加工过的指标”。这部分逻辑完全是规则化的我写成了标准的Python函数库加工费PoyPTA加工费 PTA现货价格 - PX价格 × 0.655。这个0.655是行业通行的PX单耗系数指生产一吨PTA需要消耗的PX量。加工费是PTA研究的核心指标之一它反映的是PTA生产企业的利润空间加工费过低会引发减产预期过高则会刺激开工。基差基差 现货价格 - 期货主力合约价格。基差走强意味着现货强于期货通常反映近端供需偏紧。价差结构近月合约价格减去远月合约价格判断市场是back结构还是contango结构这直接影响套保策略的选择。涨跌幅和持仓变化这些指标直接反映资金动向。持仓量大幅增加配合价格上涨通常意味着多方主动进攻持仓下降的上涨则可能是空头回补。这些计算公式不是AI生成的是行业常识的代码化。Agent在这里承担的是执行角色不是判断角色——你得先把规则教给它它才能算出正确的数。这也是我反复强调的一点Agent项目里最有价值的部分永远是你自己的领域知识而不是模型本身。3.3 逻辑点评生成提示词设计的几个关键细节逻辑点评是整个日报里最有含金量、也最能体现Agent价值的环节。我的做法是设计了一套结构化的生成流程而不是直接把所有数据一股脑丢给模型让它自由发挥。每个交易日的逻辑点评我要求模型严格按以下框架输出当日行情概述用一两句话概括盘面表现包括价格方向、涨跌幅、持仓变化特征驱动因素分析从成本端PX、原油、供需端装置变化、开工率、库存、价差结构基差、月差三个维度梳理当天行情的影响因素产业链利润分布描述加工费、聚酯利润的变化指出利润在上中下游之间的流转方向短期关注点基于数据变化列出接下来需要跟踪的变量。为了让模型输出的内容不离谱提示词里我还做了三件事明确角色和任务开头就写清楚“你是一名专业的PTA期货研究员请基于以下数据分析今日市场”数据先行、格式固定先把当日所有关键数据以“指标名: 数值”的形式列出然后指令“严格按照上述数据进行分析禁止自行编造数据”限定输出长度和风格每一段的字数范围、语言风格专业但简洁、不堆砌形容词都做了约束。刚开始用的时候模型经常出现“明明数据说加工费走弱点评却写加工费支撑强劲”这种数据与结论矛盾的问题。后来我调整了策略不再让模型“看完数据自己总结”而是引导它“先复述数据再基于复述做判断”——相当于强制它先“读题”再“作答”逻辑一致性明显提升。3.4 日报输出与自动化每天早上的第一杯咖啡配什么日报生成之后还有一个自动化调度的环节。我用的方案是Windows计划任务 Python脚本每天早上8点自动触发程序依次执行数据抓取、指标计算、点评生成、日报渲染最后把Markdown格式的日报输出到指定文件夹并同步发送到自己的工作群。这里有一个很典型的注意事项期货市场不是每天都有交易日数据。周末和节假日跑脚本要么没数据要么拿到的是上一交易日的数据导致日报内容重复。我的解决方案是在脚本里维护一个交易日历文件执行前先判断当天是否交易日不是就直接退出。另外我特意让日报的最后有一栏叫“数据源与备注”把每个关键数据的来源、采集时间、是否做了人工修正都记录下来。一开始觉得这栏没必要后来发现它极大提高了日报的可用性——不管是自己回看还是给别人看你都能马上知道这个数是从哪儿来的、能不能信。4. 实操过程从零搭出一套能跑的Agent4.1 环境准备硬件、系统、软件的踩坑总结先说说我的硬件环境方便你对号入座显卡RTX 3060 12G这是整个系统的性能核心CPUi5-13400内存32GB DDR4硬盘1TB NVMe SSD系统Windows 11Python 3.10。如果你手里的显卡是8G显存也能跑但建议选更小的模型比如Qwen2.5-7B或者Llama-3-8B如果是16G以上显存可以直接上14B甚至34B的模型生成质量会更好。软件安装步骤核心就这几步# 安装Ollama在官网下载对应系统的安装包即可 # 安装完成后拉取DeepSeek-R1蒸馏版模型 ollama pull deepseek-r1:7b # 验证模型是否正常加载 ollama run deepseek-r1:7b 你好介绍一下你自己 # 启动Ollama的API服务安装后默认自动启动端口11434 # 测试API是否可用 curl http://localhost:11434/api/generate -d {model: deepseek-r1:7b, prompt: 你好}这里要提醒几个坑显存不够怎么办Ollama默认会占用所有可用显存如果机器上还要跑其他程序可以设置环境变量OLLAMA_MAX_LOADED_MODELS1限制加载模型数量或者用OLLAMA_NUM_GPU控制显存分配比例。Windows的Path环境变量Ollama安装后命令行工具可能不在系统Path里需要手动把C:\Users\你的用户名\AppData\Local\Programs\Ollama加到Path中。模型下载速度慢Ollama默认从官方源下载模型国内网络环境可能比较慢但这是公开渠道的正常下载多等一会儿就好。4.2 数据抓取脚本从零开始写出来要多久数据抓取部分是整个项目里工程量最大的模块但逻辑并不复杂。我的实现思路是为每个数据源单独写一个采集函数统一返回DataFrame格式再合并成当天的全量数据集。以期货行情数据为例import requests import pandas as pd def fetch_futures_daily(symbolTA, date20240115): # 以新浪期货接口为例 url fhttps://stock2.finance.sina.com.cn/futures/api/jsonp.php/var%20_{symbol}/InnerFuturesNewService.getDailyKLine?symbol{symbol} response requests.get(url) # 解析返回的JSON数据提取需要的字段 # 字段映射d日期、o开盘价、h最高价、l最低价、c收盘价、v成交量、p持仓量 data response.json() df pd.DataFrame(data) df df[[d, c, p, v]].tail(1) # 只保留最新一天数据 return df实际开发中不同数据源的返回格式千奇百怪有JSON的、有HTML的、有JS变量的清洗逻辑占了整个脚本的60%以上。所以如果你要复刻这个项目我建议先在Notebook环境里把每一个数据源的解析逻辑跑通再统一封装成函数分步推进会比一次性写完整套流程省心得多。我整个数据抓取模块从零到稳定运行大概花了两周左右的业余时间。主要是中间要反复应对网站结构变化、字段缺失、编码问题等小Bug。4.3 Agent核心代码提示词工程和调用封装数据层搞定后就到了Agent最核心的部分——调用本地模型生成点评。我的做法是写了一个generate_report函数专门负责组织提示词、调用Ollama API、解析返回结果。import requests import json def generate_market_commentary(market_data, analysis_framework): # 构造提示词 prompt f 你是一名专业的PTA期货研究员。 请根据以下当日市场数据分析今日PTA行情输出日报点评部分。 当日数据如下 {market_data} 分析框架要求 {analysis_framework} 要求 1. 严格基于上述数据不得编造任何数据 2. 每个部分先复述相关数据再给出分析判断 3. 语言专业、简洁不堆砌形容词 4. 总字数控制在800字以内。 # 调用Ollama API response requests.post( http://localhost:11434/api/generate, json{ model: deepseek-r1:7b, prompt: prompt, stream: False, temperature: 0.3, # 低温保证一致性 max_tokens: 2048 } ) result json.loads(response.text) return result[response]这里有几个参数设置值得单独说一下temperature设为0.3日报点评是“固定框架内的分析”输出一致性比创造性更重要。温度设太低接近0容易让文字呆板机械设太高超过0.7容易跑偏0.3是我试了很多次之后觉得最平衡的值。max_tokens要留足日报点评的合理长度在800字左右加上中间推理过程2048个tokens是底线。设太短会导致输出被截断日报缺胳膊少腿。关闭流式输出stream: False流式输出适合聊天场景但日报生成是后台任务一次性拿到完整结果更方便后续解析和处理。4.4 一次完整的日报生成实录下面给你看一次实际运行的完整流程从数据采集到最终日报出炉第一步数据采集约30秒脚本自动运行依次抓取PTA期货主力合约日线数据包括收盘价、涨跌幅、成交量、持仓量以及近月与远月合约价格华东PTA现货价格、PX价格、聚酯价格PTA装置开停车信息通过关键词匹配从资讯流中提取各环节开工率与库存数据。第二步指标计算几乎瞬间完成脚本把原始数据加工成研究用的指标计算PTA加工费 现货价 - PX价格 × 0.655并与前一日加工费对比计算基差 现货价 - 期货主力价计算月间价差 近月合约价 - 远月合约价统计各数据的环比变化。第三步调用模型生成点评约1~2分钟调用Ollama API把第二步得到的指标数据和提示词框架一起提交给DeepSeek-R1。模型经过内部推理生成四个部分的点评行情概述、驱动因素分析、产业链利润分布、短期关注点。第四步汇总渲染输出几乎瞬间完成程序把指标表格和模型点评合并到Markdown模板中生成完整日报另存为当天的文件比如PTA日报_20250115.md。整个流程从触发到完成大约3分钟内搞定。我每天早上8点计划任务自动跑一遍到了工位打开文件夹日报已经在等我了。5. 常见问题与排查技巧实录5.1 模型自作主张编数据这个坑最致命这是整个项目里最严重的坑。模型在生成点评时偶尔会“自动补齐”一些我不知道的数据——比如“华东PTA现货价格下跌45元/吨至5850元/吨”但实际数据里根本没有这个数。这就是典型的“模型幻觉”。排查之后我发现问题出在提示词的结构上。当数据是以表格形式长篇幅出现时模型会倾向于在长上下文中“平均”或“补充”一些数据。后来我做了两件事在提示词里加了一行显式的硬约束“如果某个数据在上述数据列表中不存在请明确写‘数据缺失’不要推断或补充。”在生成后增加了一个数据一致性校验脚本把点评中提到的所有带数字的句子与当天数据源做交叉比对。如果某个数字和数据源对应不上该校验脚本直接报错提醒人工复核。加了校验之后编数据的情况几乎被杜绝了。这也让我养成了一个习惯Agent的输出永远要过一层规则校验不能完全信任模型。5.2 本地推理速度慢7B模型也要等两分钟刚搭好的时候完整生成一次日报要将近5分钟一度让我怀疑是不是哪里配置出了问题。后来排查发现两个原因一是同时加载了多个模型显存频繁换入换出二是Ollama在CPU和GPU之间分配不合理。解决办法设置OLLAMA_MAX_LOADED_MODELS1保证同一时间只有一个模型驻留显存在模型加载时指定num_gpu参数确保完全使用GPU推理检查电脑的电源方案插上电源并使用高性能模式避免CPU/GPU降频。调整之后生成时间从5分钟缩短到1分半左右完全在可接受范围内。这里再补充一点日报是每天早上固定任务不是交互式对话1~2分钟的等待完全没问题。如果是做实时对话型应用那可能就得考虑小模型或者量化加速方案了。5.3 数据源改版导致抓取失败别慌这是常态做爬虫的人都知道数据源改版是最让人头疼的事情之一。我的PTA现货价格数据源在项目上线第二周就改了一次网页结构爬虫直接失效。好在我从一开始就做了防御性设计每个数据源的采集函数都是单独模块数据源失效不会波及整个系统。处理步骤也很常规打开数据源页面检查网页结构变化用浏览器开发者工具定位新的DOM结构或接口位置修改对应的解析函数跑一遍历史数据做回归测试确保其他数据源不受影响。这里想强调一点这种维护工作是常态不是意外。任何依赖外部数据源的自动化系统都要预留出日常维护的时间。如果连每天花几分钟检查数据是否正常都不愿意那这个系统迟早会因为一个隐蔽的数据错误坑你一次。5.4 日报质量评估怎么评判Agent干得好不好日报毕竟不是纯客观的数据汇总它还包含文字点评。怎么评判Agent生成的内容好不好我给自己定了一套打分规则维度判断依据权重数据准确性所有数字是否与数据源一致40%逻辑一致性点评结论是否与数据表现一致30%完整度四个部分是否齐全、有无遗漏15%语言质量是否通顺、专业、无废话15%每周我会随机抽三天的日报自己打分做复核。这套评估机制坚持了两个月最大的收获是Agent的短板主要在前两个维度——数据准确性和逻辑一致性语言质量反而问题不大。所以后续优化的重点都放在数据校验和提示词约束上没有在“让模型写得更华丽”这件事上浪费过时间。6. 给想动手做类似项目的人一些实在建议6.1 先做减法不要一开始就贪大求全我第一次设计这个系统时恨不得把所有功能都塞进去——除日报外还想让Agent做周报、月报、品种间价差分析、自动生成交易信号……结果项目拖了一个多月都没跑起来每天都在改架构。后来痛定思痛把范围砍到只剩“PTA日报”这一件事两周就上线了。这个教训特别值得分享个人做Agent项目最重要的不是能力上限而是闭环速度。先把最小可用版本跑起来哪怕它每天只帮你省半小时你也已经赚到了。后续再在稳定版本上迭代加功能心理负担和试错成本都会小很多。6.2 Agent的边界说“不”的能力比“做”的能力更重要用Agent做期货研究多了我越来越清楚它的边界在哪里它做不了真正的预测。模型只是基于历史数据做模式匹配它不知道明天原油会涨还是会跌也不知道哪条突发新闻会改变市场逻辑它做不了对突发事件的处理。比如装置意外爆炸、宏观政策突变这类黑天鹅事件的数据和文本都不会出现在它的训练集里它做不了“反常识”的判断。模型的推理高度依赖你给定的框架如果市场逻辑恰好超出了框架范围它不会告诉你“框架错了”只会用旧框架硬套。所以我的定位一直是Agent是“起草者”人是“决策者”。所有Agent产出的内容都必须经过人的脑子过一遍。这个过程不仅是为了纠错更重要的是一旦你依赖Agent成了习惯、放松了对市场的主动跟踪你的盘感会钝化这就本末倒置了。6.3 下一步还能怎么扩展日报只是第一步。基于这套已经跑通的架构我接下来的计划是嵌入更多品种把PTA的框架复制到MEG乙二醇、短纤等聚酯产业链品种上共用同一套数据采集和点评生成逻辑做周度和月度总结在日报基础上让Agent汇总一周或一个月的价格表现和核心矛盾生成周期更长的研究报告初稿结构化知识库把历史日报和关键事件沉淀到向量数据库中让Agent能基于历史数据回答“历史上加工费跌到这么低之后通常会发生什么”这类问题定时任务升级将Windows计划任务改成更灵活的调度器支持交易日自动识别、异常重试、多渠道推送等功能。说实话这个项目做到现在最让我有成就感的一刻并不是Agent生成第一篇日报的时候而是有一天早上我坐在工位上看着日报文件夹里已经静静躺着的当天报告突然意识到自己已经两个多月没有因为“抄数据”这种事影响过吃早餐的心情了。如果你也想动手做一个类似的Agent我的建议只有一条选一个你真正熟悉的垂直场景把它切到足够小然后让模型在这个小场景里跑起来——剩下的交给时间去迭代。本地部署的AI Agent不会让你一夜之间变成超人但它确实能帮你把那些重复了无数遍的脏活累活捡起来让你把时间花在真正值钱的地方。