1. 项目概述1.1 从零手搓投资Agent的动机先说背景。我们团队在开发这套系统之前已经用传统量化策略跑了将近两年规则引擎、因子库、事件驱动框架都搭过一遍但遇到一个很难绕过去的坎传统策略对“非结构化信息”的处理能力几乎为零。一条突发新闻、一份几百页的研报、一段管理层电话会的语气变化这些信息在传统因子模型里根本没法被有效编码。所以当我们决定从零手搓一个投资Agent时核心目标非常明确让系统能像一位研究员一样去“读”海量信息并形成判断而不是只计算一堆数值指标。这个项目最终处理了百亿token级别的文本数据覆盖新闻公告、研究报告、社交媒体讨论、财报电话会记录等多个信息源整套系统全部由我们自己搭建没有直接套用现成的Agent框架。用“手搓”这个词是因为核心的编排逻辑、工具调用机制、记忆管理策略全部是一行行代码写出来的。这套系统解决的核心问题可以概括为在海量、异构、高噪声的金融文本中自动化完成信息的获取、清洗、理解、推理和决策输出。适合参考这个项目的人包括正在做量化投研但受困于文本处理的技术团队想搭建垂类Agent但没有现成范式的AI工程师以及研究大模型应用落地的算法同学。如果你只是想看一个Demo级别的Agent调用例子这篇内容对你来说会偏重因为我们会深入到百亿token级别才会遇到的数据工程和系统设计问题。1.2 系统的整体能力与运行边界先看一个实际场景理解这套Agent到底在做什么。假设现在时间是工作日上午9点系统刚刚完成夜间数据的增量更新它需要回答的问题是今天应该关注哪些行业方向有哪些标的出现了基本面逻辑的变化持仓中有没有需要警惕的风险信号整个过程在系统内部被拆解为多个阶段。Agent会先形成对宏观环境的判断随后扫描行业层面的边际变化再下沉到底层标的基本面事件的解读最后输出一份带有置信度评分的决策参考报告。整个过程涉及的数据量是巨大的新闻源每天新增约2-3万条研报约2000份社交平台讨论约50万条电话会记录和公告约3000份。这些数据折算成token每天净增约8000万到1亿。系统运行大半年之后累计处理的数据量就突破了百亿token。这里先建立一个最重要的认知百亿token不是指模型同时能容纳百亿token的上下文而是指整个系统的生命周期内流入并沉淀的数据总量。这是一个完全不同的工程问题——你不需要一台超级机器塞下所有内容而是需要一套高效的水管系统让数据持续不断地流经模型的处理管线把有价值的沉淀下来把没价值的丢弃或归档。2. 整体架构设计与核心决策2.1 为什么不能直接套用通用Agent框架项目立项时我们先做了一个竞品调研市面上有多套成熟的Agent框架支持工具调用、记忆存储、多智能体编排这些能力开箱即用的体验相当好。但经过两周的验证测试我们确认了这些框架在投资场景存在三个致命问题。第一是记忆机制太单一。通用框架的记忆往往就是一个向量库把历史对话塞进去做相似度召回。但投资分析需要的记忆是分层级的宏观观点、行业配置、个股逻辑、交易记录、风险事件这些层级的记忆之间还有复杂的联动关系。用一套扁平的向量库来管理召回的相关性完全不够。第二是工具调用的编排不够可控。投资分析的工作流有一条清晰的逻辑链条宏观→行业→个股→交易信号。这个链条不允许Agent随意跳步更不允许Agent在缺少某个关键数据时强行给结论。通用框架给Agent的自由度太高在我们这个场景反而是风险。第三是评估反馈的闭环成本太高。通用框架往往要依赖用户交互来纠正Agent行为但我们希望系统能独立跑完整个投研流程并且能用历史数据做大规模回测。这意味着需要自建一套评估循环。所以最终我们决定不修改框架直接自己写编排层。事实证明这个决策是正确的——后续系统迭代中我们多次调整了决策链条的拓扑结构如果依赖外部框架每一次调整都可能碰到框架底层的约束。2.2 双引擎架构流式数据管线与决策推理引擎的协同在动手写代码之前我们需要先把系统最上层的架构想清楚。类比一下如果你要把一座图书馆装满书还需要一位能随时回答问题的图书管理员。在这个比喻里流式数据管线就是不断运书进来的物流系统决策推理引擎则是图书管理员。两个引擎的分工完全不同。数据管线的核心指标是吞吐量、延迟、成功率它每天要处理几十个不同来源的数据接入做去重、清洗、格式化、落库。决策推理引擎负责的是分析和判断它要读取数据管线整理好的内容结合当前持仓和历史记忆执行一套多步骤的分析流程最终产出调仓建议。这两个引擎之间的接口设计是整个项目中最关键的部分。数据管线产出的是统一格式的“信息条目”每个条目包含信息类型、来源、时间戳、实体关联比如关联的公司、行业板块、文本内容、结构化字段比如财务指标、事件类型标签。决策引擎只认这种格式不关心数据是从哪里来的。这样设计之后新增一个数据源只需要写一个适配器完全不影响决策层的逻辑。2.3 关于模型选型和成本控制的认识百亿token项目的核心成本在模型推理。我们进行过一组实际测算平均每条新闻从原始文本到完成结构化分析需要消耗约800个token的输入和150个token的输出用于生成标签、摘要、情感极性。研报这类长文本更夸张一篇万字研报完整分析下来需要消耗3-5万token。这么算下来日均token消耗量在4到5亿左右按私有化部署的算力成本折算这是一笔相当可观的费用。我们的成本优化策略分三层。第一层是路由分流并不是所有信息都需要最高规格的模型来处理快讯类消息用轻量模型处理深度研报和电话会记录才用顶级模型。第二层是缓存策略同一标的高频出现的相似信息比如同一事件的多家媒体报道系统只完整分析第一篇后续报道做相似度比对后自动合并。第三层是总结压缩长文档先做分段摘要再用摘要作为推理层的输入把3万token的研报压缩到3000token以内的核心观点再进入决策管线。模型的选型上主推理链路我们使用了一款在金融领域做了专门精调的模型底座参数量处于当前主流梯队的中上水平。为什么不用最大参数的模型因为通过工程手段把信息预处理做扎实之后决策层需要理解的已经是“精炼后的信息而非原始噪声”模型容量够用即可没必要让最大的模型去处理几万条清洗前的原始文本。预算要花在刀刃上。3. 数据管道建设百亿token从哪来、怎么洗、怎么存3.1 数据源分级与接入策略数据是整套系统的燃料。我们在建设数据层时把所有信息源按照可靠性和时效性分成三个层级每一级的处理方式完全不同。第一级是权威快讯和公告数据包括交易所公告、监管披露信息等。这一类数据质量最高结构化程度也最好接入时主要做格式统一和字段映射。比如一份PDF公告需要先做文本抽取再按照公告类型年报、减持、并购、诉讼等进行分类再提取出关键实体和金额数据。这部分数据的处理准确率要求极高不能出错因为它是决策层做判断的重要依据。第二级是研报和深度新闻。这些内容的分析价值高但格式差异极大而且不同券商对同一事件的解读可能存在矛盾。处理策略是全文拆解后做结构化归档研报的关键章节核心观点、盈利预测、风险提示会被单独拆出来与历史研报做纵向对比。第三级是社交平台讨论和自媒体内容。这部分噪声最大但往往能提供最早的市场情绪信号。处理方式是先做噪声过滤去掉广告、无意义灌水再做群体情绪聚类。我们做过一个验证某些标的的社交讨论热度会在正式公告前1-2天出现异常波动这类信号对短线预警非常有效。但也必须承认第三级数据的误报率相当高所以它永远不会被单独作为决策依据只能作为辅助信号进入多因子融合模块。3.2 清洗流程的关键细节实体对齐与时间归一化数据清洗是这套系统里最容易被低估的模块。我见过很多团队以为清洗就是去掉HTML标签和特殊字符实际上金融文本的清洗远比这复杂。最核心的两件事是实体对齐和时间归一化。实体对齐解决的是“同一事物的多种叫法”问题。举例来说一家公司在其公告里出现的是完整注册名新闻稿里用的可能是简称社交媒体上用的可能是投资者的俗称甚至可能带着错别字。我们需要建一个实体映射表把这些不同写法统一到唯一的标准实体ID上。这个映射不是一次性建立的系统会每天从新增文本中挖掘新的实体别名用上下文embedding做相似度匹配再经过规则校验后加入映射表。时间归一化解决的是“事件发生时间与文本发布时间不一致”的问题。很多研报写的是“上周行业发生了某某事件”如果不把这个时间信息校准到准确的日期系统的时序判断就会出错。我们的做法是把所有文本中出现的相对时间“上周”“昨日”“本月初”转换为绝对时间戳再和文本提到的具体事件做关联最终生成一条带精确时间线的“事件记录”。3.3 存储架构的选型逻辑百亿token的文本数据如果全部以原始形式存储占用的空间惊人。但不加选择地直接丢弃又会丢掉未来可能有价值的信息。我们最终的存储方案是三级分层。热存储层承担的是最近7天的增量数据供决策引擎实时读取。这一层用的是高性能的内存数据库加倒排索引查询响应要求控制在毫秒级。温存储层保存最近一年的结构化信息条目采用列式存储加分区表支持按时间、行业、实体等维度快速过滤。冷存储层保存所有原始数据和中间处理结果用高压缩率的格式存到低成本对象存储中平时不访问只有当需要做历史复盘或重新挖掘因子时才会被拉出来。这种分层在成本上的收益非常显著。按实际压缩比计算百亿token原始文本压缩后约占地几十TB冷存储一年的费用只占整体预算的很小比例。而如果把这些数据全放在高性能存储里成本会高出至少一个数量级。3.4 增量处理与全量重算的双轨机制数据管线每天处理量巨大但对准确性的容忍度并不相同。系统设计了双轨机制日常的增量处理追求低延迟当天的数据要在当天完成分析每周则会有一次全量重算把过去7天的增量结果合并进历史跨度重新校准。这个设计源自我们踩过的坑。早期版本只做增量处理结果实体对齐错误会一路错下去——如果某公司的简称在第1天没有被正确识别后续几天的关联分析都会基于错误的实体ID。全量重算引入之后这类系统性错误可以被定期修复。重算过程耗费的计算资源比日常增量高出许多但因为安排在低峰期执行对系统整体性能的影响很小。4. 决策推理引擎投资Agent核心工作流拆解4.1 多层级的决策链条设计决策推理引擎的内部结构是整个项目的灵魂。我们把投资分析的流程建模为一个四层的决策链条宏观环境层、行业趋势层、标的事件层和交易信号层。每一层处理不同粒度的信息层与层之间存在严格的先后关系和信息传递接口。宏观环境层负责回答“现在的钱该往哪些方向配置”这个问题。它读取的输入包括政策新闻、经济数据、货币流动性指标、全球主要市场的走势等。输出是一组宏观情景标签和对应的风险偏好评分。比如当流动性环境宽松并且政策支持方向明确时系统会给高风险偏好行业加一个正向偏置。行业趋势层关注的是具体行业板块的景气度变化。这一层会聚合与某个行业相关的所有信息条目计算行业层面的信息热度、事件冲击强度、盈利预期调整方向等。行业趋势层还会对比不同行业之间的相对强弱形成“行业轮动”的候选序列。标的事件层聚焦到具体的投资标的。它会对该标的最近的重大事件做逐一解读包括业绩变化、管理层变动、股东增持减持、重大合同签署、诉讼进展等。每个事件都会被映射为一个事件标签并附带一个影响方向和影响程度的评分。交易信号层是最后一层把前三层的结果汇总起来结合当前持仓和风险预算输出具体的调仓信号。这一层还会考虑交易成本、流动性因素和持仓约束。这四层链条的编排逻辑是硬编码的写得很死不可由Agent自行更改。Agent的自主性体现每一层的内部操作比如在标的事件层Agent可以自主决定先查看哪份最新研报、调用哪个工具获取数据、是否需要展开查看某项财务指标的详细历史。这种“骨架固定、血肉自主”的设计是我们经过多次失败实验后确立的原则。4.2 工具集的设计与调用机制Agent要完成上述分析不能只靠模型自身的知识储备必须接入外部工具。我们的工具集按照功能分成五类数据查询类、计算分析类、文本处理类、时序统计类和执行模拟类。每个工具都封装为统一的接口Agent通过函数调用的方式使用它们。数据查询类工具连接的是新闻库、公告库、价格行情库和财务数据库支持按时间范围、股票代码、事件类型等条件检索。计算分析类工具包括估值计算模块、行业景气度打分模块、技术指标计算模块。文本处理类工具包含摘要生成、实体提取、情感分析等模型能力。时序统计类工具负责收益率分析、波动率计算、相关性矩阵等。执行模拟类的工具则用于模拟调仓后的组合表现。关键的机制设计是工具调用的条件触发。比如估值计算工具Agent不是在所有情况下都需要查询当事件对估值逻辑不构成实质性影响时系统会通过一个轻量级的判断来阻止Agent进行多余的调用。这样可以节省大量不必要的时间和token消耗。实测下来这个简单的门控机制减少了约三成的工具调用次数系统整体的响应速度提升明显。4.3 从分析到决策的内部推理流程以一个具体的“事件驱动型调仓决策”为例看看Agent内部是怎么走完整个流程的。某天晚上数据管线捕获了一条重要信息一加工业龙头企业发布了超出市场预期的年度业绩预告净利润同比增长超一倍远超此前卖方一致预期。数据管线完成清洗后把这条信息打上了“业绩预增”的事件标签并关联到对应的标的实体然后推送给决策引擎。决策引擎的标的事件层先启动对该标的的主题分析。Agent读取业绩预告全文提取关键数据营收、净利润、增速、变动原因和历史同期数据做对比再调出最近三份券商研报的一致预期数据做差值比较。这一步完成后系统识别出这是一次正向业绩超预期事件超预期幅度约为25%。行业趋势层随后介入检查这家公司在行业中是否具有代表性行业整体是否处于景气上行周期同行业的其他公司最近是否也有类似业绩变化。如果确认这是一次行业级别的共振信号行业层面的评分会被上调。宏观环境层则检查当前是否有利于制造业板块的配置时机比如流动性环境和相关政策导向是否支持。最后交易信号层汇总所有信息标的本身基本面改善、行业景气度共振、宏观环境不构成阻碍但也要考虑估值是否已经偏高、短期股价是否已经完成反应。系统会输出一个包含方向、力度和建仓节奏建议的信号。4.4 置信度评分与多信号融合单一事件不能直接触发调仓。系统会积累多个独立的信号综合评估后再做决策。每个信号都有自己的置信度评分和过期时间。置信度评分由几个因素共同决定信息源的权威程度、事件与标的的关联强度、信息的时间新鲜度、以及是否存在逻辑链条上的矛盾。信号的融合采用的是带权重加权的逻辑回归模型权重由历史回测自动校准。这个权重校准的过程本质上就是用几百次历史决策的结果去逆向拟合出“什么类型的信号更可靠”。我们也尝试过让大模型直接对多个信号做综合裁决但效果并不稳定。大模型在单一信号解读上表现优秀但在对多个信号做最终决策时容易受到表述顺序和措辞的干扰给出不一致的结论。所以最终的决策合成还是交给了规则化的模型。5. 核心实操过程关键实现与参数选择实录5.1 Agent行为循环感知-思考-行动-记忆的代码化实现很多人把Agent循环理解得很神秘实际上写出来就是一个带着状态管理的while循环。核心就这么十几行逻辑但每一行的设计都是有讲究的。我用简化的代码来展示核心框架。class InvestmentAgent: def __init__(self, memory_manager, tool_registry, model): self.memory memory_manager self.tools tool_registry self.model model self.max_iterations 12 def run(self, task_input): 主执行循环感知-思考-行动-记忆 context self.memory.build_initial_context(task_input) analysis_result {} for step in range(self.max_iterations): # 思考让模型决定下一步动作 thought self.model.plan_next_action( contextcontext, available_toolsself.tools.list(), stepstep ) # 判断是否产出最终决策 if thought.is_final(): analysis_result self.model.generate_final_answer(context) break # 行动调用指定工具 observation self.tools.execute(thought.tool_call) # 感知将工具返回结果加入到上下文 context context.append(thought.tool_call, observation) # 记忆将本次交互的关键信息异步写入长期记忆 self.memory.async_write(thought.tool_call, observation) self.memory.update_decision_memory(analysis_result) return analysis_result这个循环的关键约束之一是max_iterations的设定。我们尝试过不同数值发现12次是一个合理上限。如果超过这个次数还在思考没有形成结论大概率是分析路径出现了偏差与其让它继续跑下去浪费token不如强制收敛并标记为“低置信度”结果。同时循环体里每一步之后都会更新上下文但上下文不会无限膨胀系统会在每步结束时对不再需要引用的原始文本做摘要压缩控制输入长度。5.2 记忆管理的实现方案从短期工作区到长期知识库Agent的记忆设计是这个项目中投入精力最多的部分之一。一个没有记忆的Agent同一件事问两次会给出完全独立的分析这在投资决策中是绝对不能接受的。我们将记忆拆成三层实现。短期工作区是Agent在当前分析过程中的临时记忆类似于人类的“工作记忆”容量有限只保存当前任务相关的数据片段。当一个分析流程结束后工作区会被清空。中期记忆区保存的是近期的分析结论和重要事件用于保证在一段时间内系统对不同问题的回答保持一致。例如本周内已经评估过的标的再次提到时不会重新给出完全独立的分析结论。长期知识库则是系统沉淀下来的核心观点库包括对行业格局的理解、对某些公司的长期判断、对特定风险事件的复盘总结。长期知识库的写入不是所有分析都会进入的系统有一个专门的记忆价值评估环节。某个观点要被写入长期知识库至少要满足以下条件中的一个与当前持仓高度相关、与近期重大市场事件相关、或者在多次独立分析中出现了一致的结论。如果只是一次性的事件解读虽然这次有用但不会进入长期知识库避免知识库很快被低价值的碎片信息淹没。记忆的更新也有一套冲突检测机制。如果新分析得出的结论与长期知识库中已有的观点存在方向性矛盾比如对同一家公司从“看好”变为“看空”系统不会直接覆盖旧观点而是把两个观点都保留下来并标记一个“待复核”状态。后续如果再出现支持其中某个方向的第三方信息系统才会自动确认其中一个观点并废弃另一个。5.3 关键参数与配置的选择依据整个系统里有几组关键参数直接影响行为质量。我把最有参考价值的整理如下。温度参数是模型生成的核心控制项。我们做了多轮对比测试不同场景的最佳温度差异显著。摘要生成类任务温度设为0.1要求尽量忠实原文情感分析温度设为0完全确定性输出标签综合分析推理温度设为0.3允许模型在逻辑判断上有少量灵活性但不过度发散。需要特别强调的是投资Agent中不应该出现温度高于0.5的情况过高的随机性在决策场景是灾难性的。上下文窗口的分配策略也做了一组精细的切分。每次主模型调用的输入由三部分拼装当前任务描述占约2000 token、相关记忆和环境信息占约4000-8000 token、工具返回的最新数据占约3000-6000 token。超出总窗口的部分必须经过摘要压缩。长窗口模型确实能装下更多内容但并不代表在窗口内堆砌越多信息输出质量就越高。冗余信息会对推理产生干扰所以我们对输入做了严格的信息瘦身。调度策略方面不同级别的任务对应不同的并发优先级。市场监控类任务实时性要求极高优先级最高日常研报解读中午前完成即可历史复盘类任务则集中到晚间低峰期批量执行。合理的调度让有限计算资源利用率提升了至少三成。5.4 历史回测与效果评估的方法评估一套投资Agent的好坏不能只看单次决策的对错要看长周期内决策质量的稳定性。我们构建了一套离线回测体系。回测的基本方法很直接把历史某一时刻的系统状态完整保存下来把数据管线的输出截断到那个时刻让决策引擎基于当时能看到的信息做决策然后与真实后续走势对比。但这个“简单”的回测逻辑背后有一个技术难点如何防止未来信息泄漏。我们在这件事上踩过一个大坑。早期做回测时实体对齐表是全量构建的这就导致回测时系统已经知道了未来才会出现的实体别名。一个小细节就会让回测结果失真。后来我们把时间旅行机制做进了整个数据管线任何历史时刻的查询都严格限定在那之前构建的数据索引上。回测结果的指标包括年化收益率、最大回撤、夏普比率、胜率和盈亏比。但还有两个不太常见但很重要的指标决策稳定性和信息利用效率。决策稳定性衡量的是相同输入条件下系统是否给出相同结论信息利用效率衡量的则是系统实际消费的token中有多少真正影响到了最终结论。早期版本的信息利用效率很低大量token被花在了与决策无关的文本上这也侧面印证了上下文压缩和工具调用门控的必要性。6. 常见问题与排查经验6.1 信息过载导致的决策漂移问题系统上线一个多月后我们遇到了第一个大问题当同时出现几十条重要信息时Agent的分析结论会变得十分不稳定甚至出现关注点被最新一条信息带跑的情况。昨天的结论和今天的结论之间缺乏连续性这在投资决策中是难以接受的。排查后确认这是“上下文污染”问题。问题不在模型推理层而在于我们提供的上下文信息量超过了模型的有效注意力范围。修复方案是引入信息优先级排序。进入上下文前所有信息先经过一个重要性打分器按影响级别排列并明确限制同时进入核心推理上下文的高优先级信息上限。经过调整后决策稳定性大幅提升。6.2 实体识别的历史性错误累积前面提到的实体对齐误差是另一个隐蔽的问题。某个简称在首次出现时没有被识别为正确实体后续关联的所有信息都会串线而且在一段时间内会持续累积错误。这种错误在增量处理模式下几乎无法实时感知。我们的解决方案是增加每日巡检任务。系统每天凌晨对前一天所有新入库的信息条目做一次实体对齐质量抽检抽检比例设为5%。同时每周的全量重算会重新执行实体对齐并生成差异报告。通过双重保险把实体错误的生命周期压缩到了最低限度。6.3 工具调用失败与服务降级策略工具调用失败的场景远比预想中多。可能是指数服务超时、数据库访问异常、第三方数据源限流。初始版本中工具调用失败会导致整个分析流程中断后来我们设计了服务降级策略。每一个工具按照重要性分成了三个等级。第一等级工具不可用整个分析流程终止并标记“数据缺失无法决策”。第二等级工具不可用系统尝试用替代数据源补齐同类信息。第三等级工具不可用系统会继续分析并生成一个带“低置信度”的结论。这个分级策略保证系统在局部故障时不会完全瘫痪同时在关键数据缺失时也不会强行生成可能误导的信号。6.4 token消耗异常的排查思路日常运维中token消耗监控是我们重点关注的一环。如果某天消耗突然上升了50%系统出现异常的可能性很高。排查思路按照以下顺序展开。第一步检查是否有异常的数据量涌入比如某数据源出现了重复推送或爬虫抓取到大量垃圾数据。第二步检查是否有工具调用进入死循环Agent反复调用同一个工具却不继续推进流程。第三步检查上下文压缩是否失效如果某类文档反复以完整形式进入模型而没有触发摘要消耗就会倍数级上涨。第四步检查是否出现了大量调用高规格模型的情况比如调度模块把快讯类消息误分配到了高性能模型上。在运维面板中我们专门做了一个消耗异常告警模块设置了三档告警阈值日消耗超过均值的1.5倍时提醒、2倍时警告、3倍时自动停止非核心任务。这看起来很简单但在一次实际故障中帮助我们在很短时间内定位到了原因并避免了超标费用。7. 最后分享的几点经验和思考7.1 独立思考基础设施比调优模型更加重要回看整个项目投入产出比最高的环节不是模型层的优化而是数据清洗和记忆管理这两块基础设施。模型来来回回换过好几个版本每次替换都能带来一定提升但不改变大局。而数据管线的质量、记忆机制的合理性直接决定了系统能力的上限。我想用一个比喻来说明。好模型是一台好发动机但如果没有一套靠谱的传动系统发动机动力再强也到不了轮子上。数据管线就是传动系统记忆管理是方向盘。很多团队在做Agent时把精力全花在选模型和调提示词上基础设施搭得极其简陋这其实是本末倒置了。7.2 系统的可信度来自于完全可解释的决策链条投资场景有一个特殊要求每一个决策必须能够被完全复盘和解释。模型可以给出模糊的推理过程但系统不能给出模糊的决策记录。我们在Agent设计的初期就确定了一个原则——每次调仓决策系统必须同时产出一条完整的决策路径记录详细到用了哪个工具、查询了哪些数据、参考了哪篇研报、基于什么逻辑链条得出最终结论。这条决策路径记录被保存下来不仅用于监管合规和内部复盘还用于模型行为的持续改进。每次回测结束后研究团队都会人工抽样审视决策路径找出逻辑链条中的不合理之处然后针对性修改提示词或增加约束规则。这个“人工审视-规则修正”的循环是我们系统后期迭代质量提升的最大来源。7.3 关于Agent的自主边界需要一个阶段一个阶段地放开最后谈一下Agent的自主边界。我们在这条路上的策略非常保守先让Agent做增量信息提示再由人工决策然后让Agent给出带评分的建议人工审核后执行最后才允许Agent在低风险任务中自动执行。即便是现在设置在自动执行范围内的任务也只限于低仓位调整和风险预警类动作任何涉及大额持仓变动的决策仍然强制要求人工确认。不要把放开边界理解成一个技术问题。技术上讲Agent完全有能力在完整闭环中自动交易但风险管理的本质不是“能不能做”而是“值不值得承担不可控的风险”。一个Agent可以在99%的时间里做出完美决策但1%的极端异常情况可能吞噬所有收益。人留在决策回路里的价值就是为这个1%兜底。这套系统的定位始终是“辅助决策的增强工具”而不是替代人的“自动驾驶系统”。想清楚这一点你就知道自己该怎么设计Agent的去自动化程度了。
