企业官网建设流程全解析

1. 金融 Multi-Agent 的起点：先想清楚为什么拆

最近社区里 Jev 的讨论度很高，很多人跑来问我：能不能用它搭一个金融 Multi-Agent 系统？我的回答通常是——先别急着选工具，先想清楚你到底需不需要多智能体。

我见过太多项目，一开始就画了三五个 Agent 的协作图，结果做出来一个壳子：每个 Agent 实际只调了一次模型，中间没有任何状态传递，所谓的“协作”就是把几个 Prompt 拼在一起。这种设计不叫 Multi-Agent，叫分布式 Prompt。金融场景不是不能做多智能体，而是要先回答一个核心问题：你的业务流程里，是否真的存在多个职责不同、需要独立决策实体、并且彼此之间有信息交换的环节？

1.1 单体 Prompt 的瓶颈在哪儿

金融领域有个特点：任务链条长、专业分工细、对可解释性要求高。拿一篇研报生成来说，传统单体 Prompt 也能做，但你会遇到三个绕不开的坎。

第一是上下文膨胀。一篇完整的宏观策略分析，需要同时处理经济数据、行业新闻、个股公告、历史回测结果。把这些全部塞进一个上下文窗口，很快会超过模型能承受的长度，而且越是靠后的信息，模型越容易“遗忘”。第二是角色冲突。同一个模型既要当“数据清洗员”，又要当“策略分析师”，还要当“合规审核员”，Prompt 里反复切换角色，模型很容易在一段输出里角色漂移——前半段还在客观陈述数据，后半段就开始下投资结论了。第三是错误隔离差。如果最终输出有问题，你很难定位是数据环节错了，还是分析环节错了，因为你只有一次完整的输入输出，中间过程是个黑盒。

这三个问题，本质上是“一个大脑做所有事”的结构性缺陷。Multi-Agent 的价值不是把任务拆碎，而是把不同的认知职责分开，让每个 Agent 只做好一件事，并且让这个过程可观测、可追溯。

1.2 金融场景天然适合多体协作

金融业务本身就有清晰的岗位边界：研究员负责找数据、分析师负责下判断、风控负责挑毛病、交易员负责执行、合规负责留痕。这套分工逻辑延续了几十年，把它映射到 Agent 架构上，是顺理成章的事。

我举个例子。一个舆情监控系统，如果只有一个 Agent，你要让它同时完成“采集新闻 → 判断情绪 → 识别关联标的 → 判断影响程度 → 生成预警报告”，每一步之间互相污染的概率很高。但如果你把链路拆成四个独立 Agent——采集器只负责抓数据和清洗，情绪分析器只负责判断文本情感倾向，关联分析器只负责把情绪映射到股票和行业，预警合成器只负责生成最终报告——每个 Agent 的职责都相对简单，提示词可以写得非常聚焦，单个 Agent 的输出质量会提升一个档次，而且中间任何一步出问题，你可以精确地定位到具体 Agent。

这就像一家餐厅，如果只有一个厨师又切菜又炒菜又洗碗，他很快就会崩溃；但如果你让切配、炉灶、洗碗各司其职，每个人都能把自己的动作练到极致。金融 Multi-Agent 的本质，是把“单一大脑”变成“专家委员会”。

1.3 什么情况下不该用 Multi-Agent

说了这么多好处，我也得泼点冷水。如果你只是做一个简单的问答机器人，或者只需要一次文本摘要，真没必要上多智能体。Multi-Agent 会带来额外的延迟、成本、状态同步复杂度，这些开销在简单任务上是纯负担。

我的判断标准很简单：如果任务在一个 Prompt 内，用 2000 token 的指令就能说清楚，就不要拆。拆分的意义在于，只有当任务存在“多个视角”或者“多个阶段”，而且这些视角/阶段之间有明确的输入输出依赖关系时，多 Agent 才会比单 Agent 更强。否则，你只是把简单问题复杂化。

2. 架构设计：拓扑、角色与通信机制

确定了要拆，接下来就是架构设计。这一部分是最容易产生分歧的地方，也是 Multi-Agent 设计的核心。很多人拿着 Jev 这样的模型就开始写 Agent 代码，完全没想过拓扑结构，结果搭出来的系统像一盘散沙——Agent 之间互相找不到、消息乱飞、状态不同步。我先把三种主流拓扑讲透，再讲通信机制。

2.1 拓扑结构怎么选：编排式、分层式、还是自治式

我先说结论：金融场景 90% 的情况，用中心化编排就够。你不需要搞那种百花齐放的自治网络。

中心化编排（Orchestrator）的结构是：一个总控 Agent 负责任务理解、拆分、调度和结果汇总，其他所有 Agent 都是“被调用方”，彼此不直接通信。这种结构的好处是流程可控、状态集中、便于审计，非常契合金融行业对合规和可追溯的要求。坏处是编排器容易成为瓶颈，而且一旦编排器的 Prompt 设计得不好，整个系统就崩了。

分层式（Hierarchical）比编排式多一层中间管理。比如总控下面再设几个组长 Agent，每个组长管理一组专业 Agent。这种结构适合任务粒度差异特别大的场景，比如一个 Group 管数据处理，一个 Group 管策略研究，一个 Group 管合规检查。它比单层编排更清晰，但实现复杂度也更高，每一层都要做好上下文传递。

自治式（Peer-to-Peer）是 Agent 之间自由协商、动态组队，这种模式在学术论文里很流行，但在金融生产环境里我非常不建议用。你没法预测 Agent 之间会产生什么对话，也没法在关键路径上做强制校验。自治网络适合探索性任务，不适合“必须按流程走”的业务。一句话：金融要的是确定性，不是涌现性。

2.2 角色拆分与职责边界

拓扑定了，下一步就是角色定义。我在设计 Agent 角色时有一个原则：一个 Agent 只承担一种认知职责，并且它的输出用结构化格式固定下来。

举个例子，一个投研系统至少应该有五个角色：

• 数据采集 Agent：从数据库、API、新闻源拉取原始数据，做清洗去重，输出标准化的 JSON 数据表。
• 基本面分析 Agent：基于财务报表和宏观数据做估值分析，输出包含目标价、估值区间、关键假设的报告结构体。
• 舆情分析 Agent：处理新闻和社媒文本，输出带情绪分值、热度趋势的舆情指标。
• 风险审查 Agent：对策略和建议做逆向检查，列出潜在风险点、回撤情景，给出“通过/打回”的结论。
• 报告合成 Agent：把前面几个 Agent 的结构化输出组装成一篇完整研报，统一文风。

你注意看，每个角色的输出都设计成了固定的结构体，而不是自由文本。这一点非常关键。因为 Agent 之间的通信如果走自然语言，解析起来会非常痛苦；但如果每个 Agent 的输出是 JSON Schema 约束过的，下一个 Agent 就能稳定地消费这些数据。我见过太多项目死在“Agent 之间传文本然后解析失败”这件事上，所以我在设计角色之初，就会给每个角色定义好输入输出 Schema，这部分的工作量甚至比写 Prompt 还大。

2.3 通信机制：同步调用、事件总线和黑板模式

拓扑和角色是静态结构，通信机制是运行时行为。金融场景里最实用的是三种模式，我给你做个对比。

同步调用最简单直接：编排器按顺序调用每一个 Agent，前一个返回，后一个才开始。适合链路稳定、步骤固定的流程，比如“先采集 → 再分析 → 最后复核”。坏处是整个链路耗时等于所有 Agent 耗时之和，而且某一步卡住，整个流程就卡住了。

事件总线适合异步场景：Agent 发布消息到总线，其他 Agent 订阅自己关心的主题。比如舆情 Agent 发现某个标的情绪剧变，往总线上发一个“异常情绪事件”，风控 Agent 订阅了这个主题就会自动触发复核流程。这种模式很灵活，但调试起来很考验功力，因为执行顺序不再显式可见。

黑板模式是我在金融场景里最偏爱的：所有 Agent 共享一个“工作区”（黑板上），把自己的输出写到黑板的指定区域，其他 Agent 从黑板上读取自己需要的数据。它比事件总线更结构化——每个区域有明确的读写权限，谁写了什么一目了然。我在做估值分析系统时用的就是黑板模式：数据 Agent 把清洗后的财务数据写到“数据区”，基本面分析 Agent 从“数据区”读数据、把估值结果写到“观点区”，合规 Agent 扫描“观点区”做检查。这种方式在追踪问题上特别香，因为每一步的状态都沉淀在黑板上，问题复现和审计都很方便。

2.4 一次研报复盘任务的完整链路

把上面这些要素串起来，我画一个典型链路，你就明白整个系统怎么跑了。某交易日收盘后，系统收到指令“复盘今天的市场异动”。

第一步，编排器把这个任务解析为：数据采集、异动识别、归因分析、风险提示、报告生成五个子任务。第二步，编排器把子任务按依赖关系排成一个 DAG（异动识别依赖数据采集，归因分析依赖异动识别，风险和报告依赖前面的结果）。第三步，依次触发各 Agent。数据采集 Agent 拉取当天所有行情、板块和资金流数据，写到黑板的“数据区”。异动识别 Agent 扫描数据区，用异常检测算法找出偏离均值超过 3 个标准差的板块和个股，并把结果写到“异动区”。归因分析 Agent 读取异动区，结合新闻数据生成“可能是因为某政策发布”之类的归因描述。风险提示 Agent 最后扫描全链路，标记哪些异动伴随放量、哪些有负面舆情，输出风险等级。报告合成 Agent 把黑板上所有内容拿过来，生成一篇结构完整的复盘日报告。

整个过程，一个 Agent 都没直接调用另一个 Agent，它们只是在黑板上读写。这就是我前面说的“黑板模式”的优势——流程天然并行，数据天然留痕，调试天然可回溯。

3. 记忆与状态：多 Agent 最容易翻车的地方

如果说架构决定了一个 Multi-Agent 系统能跑多远，那记忆和状态管理就决定了它会不会在跑到一半的时候突然散架。这个部分我踩的坑最多，也最想跟你分享。

3.1 上下文窗口 vs 长周期任务

模型上下文窗口再大，也是有限的。而金融任务天然是长周期的——一个投研项目可能持续几周，期间要反复参考前面的假设、数据版本、当时的判断逻辑。如果每次调用都把整个历史记录塞进上下文，你会很快撞到窗口上限，而且模型在超长上下文中提取关键信息的能力会断崖式下降。

我见过一个团队试图用“把整段对话记录全部传给每个 Agent”的方式解决记忆问题，结果跑到第 5 轮对话，单次调用输入 token 就已经超过 10 万，费用暴增不说，模型开始在各种细节里迷失，输出的质量明显下降。问题是，这些历史信息对当前决策真正有价值的可能只有几百个 token 的“关键摘要”，你把十万个 token 全塞进去，等于用高射炮打蚊子，还打不中。

3.2 三种记忆组织方式

我把记忆分成三层：短期状态、工作记忆、长期记忆。

短期状态指的是当前任务执行过程中的中间产物，比如某个 Agent 刚写入黑板的数据。这个用共享存储来实现就可以，关键是设定好生命周期——任务结束就清理，避免脏数据越积越多。

工作记忆是当前“回合”内需要所有 Agent 共同维持的上下文，比如一次策略讨论的当前结论、当前争议点。我的做法是把工作记忆做成一个独立的 Memory Agent，它会持续把其他 Agent 产出的关键信息做摘要，压缩成交互时最需要的那部分内容。这样每个 Agent 的上下文里只需要包含“我专注领域的工作记忆摘要”，而不是全量历史。

长期记忆是跨任务复用的知识，比如历史复盘结论、常用的分析模板、过去的错误记录。这个我会落到向量数据库里，用语义检索的方式按需提取。比如风控 Agent 在下一次判断“这类情况是否危险”时，不再需要从头分析，而是先检索历史类似场景，把过去的风险判断作为参考。

3.3 共享状态与一致性保障

多 Agent 系统里有一个非常隐蔽的坑：状态同步。两个 Agent 同时更新同一个数据，你怎么保证谁先谁后？一个 Agent 读到半个更新怎么办？

金融场景尤其敏感。举个例子，估值 Agent 在计算目标价时会读 OCF（现金流量表）数据，而数据 Agent 正好在更新这组数据，如果读到了不一致的版本，估值结果就是错的。

我的解决方案是给黑板的每个数据区加版本号。写入时每次都要自增版本号，读取时带上自己需要的版本号，如果读取时发现数据版本已经变了，就等待或重新读取。更严格的做法是，在关键数据上直接采用双写校验：数据 Agent 写入后，一个校验 Agent 独立拉取源数据做比对，通过后才标记为“可信”。这个机制听起来重，但能够挡住绝大多数“死数据”问题。我曾经在一个交易信号系统里因为没有做版本控制，出现了同一指标两种数值的情况，导致策略同时开多和开空——这个教训相当昂贵。

4. 工具接入与动作执行：让 Agent 真正干活

Multi-Agent 系统光靠聊天演示没有意义，尤其在金融行业，Agent 必须能调数据、能算指标、能发预警、能提交订单。这一章讲工具接入的实操经验。

4.1 从“只说”到“能做”

很多人搭建的 Agent 只会“说”，不会“做”。你说让他“查一下今天某股票的行情”，他回你一段文字“我建议你查看行情软件”——这玩意儿没有任何实用价值。

要让 Agent 真正干活，核心是给它接工具（Function Calling）。每个 Agent 在定义时，应该同时声明它拥有哪些工具能力，并且把工具的调用约束写进主持词的 Access 权限里。数据采集 Agent 拥有“查行情”“查财务报表”“查新闻”等工具；风控 Agent 拥有“回测”“压力测试”等工具。

工具接入有一个关键设计：工具的输入输出格式必须和 Agent 的通信 Schema 保持一致。我见过很多系统，Agent 的通信走 JSON，工具调用走 Python 对象，转换层写了一大堆胶水代码。我的做法是，所有工具对外暴露统一的 JSON 接口，Agent 通过这个接口与工具交互。这样工具可以替换，Agent 不用改，系统的可维护性大幅提升。

4.2 工具接口的抽象设计

工具的抽象层级要把握好：太细，Agent 要调十次才能完成一个动作；太粗，Agent 逻辑和具体工具绑定在一起，不好扩展。

我推荐按“业务动作”而不是“技术函数”来定义工具。不要定义 get_stock_price_web 这种技术性函数，而是定义 mark_price_lookup（行情查询）、fin_report_analysis（财务分析）这样偏业务的能力。前者把 Agent 绑死在某个数据源上，后者则可以屏蔽底层实现，今天用 Wind 的数据，明天换成别的数据源，Agent 不需要感知。

另外，工具的参数要尽量少，只提供给核心变量，剩下的默认值在工具内部处理。Agent 的参数如果太多，模型会频繁产生错误调用。这里有个经验：工具参数超过 5 个的，大概率模型会漏参数，你需要重新思考怎么合并参数或拆工具。

4.3 沙盒与仿真环境的必要性

金融 Agent 做动作前，一定要在仿真环境里跑一遍。这不是技术洁癖，是风控底线。

你设计一个自动交易 Agent，第一次让它真金白银下单之前，至少要在历史数据上做回测，在纸面交易环境中模拟运行两周。我见过一个团队，策略 Agent 的盈利逻辑在仿真环境里日均收益 0.5%，结果上线第一天亏损超过 3%。原因是在仿真环境里忽略了滑点和手续费。后来他们把这两个因素加入仿真成本模型后，新增了一轮调整，才把策略拉回安全线。

沙盒环境的设计原则是“尽量真实”。行情推送要有噪声、成交要有延时、数据流偶尔会断，这些“不完美的细节”才是检验 Agent 稳定性的关键。如果只在理想数据流里跑，你测试的只是 Agent 的理想状态，而不是它面对真实世界的能力。

5. 评估、可观测性与安全护栏

Multi-Agent 系统比起单体应用，多了一个巨大的难题：不确定性。单体代码你有一套测试用例就能覆盖大部分分支，但多 Agent 里每个 Agent 的表现是模型输出的，同样的输入可能产生不同的输出。所以你需要一套专门针对 Agent 系统的评估和护栏机制。

5.1 评估集怎么建

金融领域的 Agent 评估标准绝不仅仅是“答得对不对”，你需要分层评估。

第一层是任务层：最终产出物是否完成了任务目标。比如研报生成 Agent，输出是否包含结论、论据、风险提示三段结构，关键数据是否与源数据一致。

第二层是过程层：中间环节是否合理。数据采集 Agent 是否只用了授权数据源，分析 Agent 是否在假设步骤里遗漏了关键变量，风控 Agent 是否漏掉了某个风险类别。过程层评估我认为比结果层更重要，因为你很难穷举所有结果，但过程是有限的，你可以在关键节点上设置校验条件。

第三层是表征层：格式是否正确。JSON 是否符合 Schema，日期格式、单位换算有没有错误。别小看这层，金融数据里的单位错误是最常见的坑——某 Agent 把亿和万弄混，直接导致一个策略的收益预期被放大 10 倍。

评估集的建设要从真实历史任务里抽样。不要自己凭空编造测试问题，而是把过去 3 个月真实业务中遇到的问题、用户查询、数据快照全部攒起来，手工标注正确答案，做成一个回归测试集。每次改版后，把这个测试集全量跑一遍，确保任何一次 Prompt 微调、工具替换，都不会让你把以前做对的事情做错。

5.2 可观测性：日志、血缘与回放

Multi-Agent 系统的调试难度呈指数级上升，你必须从一开始就设计好可观测性。每条 Agent 的输入输出都要落日志；每个写入黑板的动作都要记录时间戳和版本号；每次工具调用都要记录参数和返回结果。

做得更完善一点，你要再造一条“血缘追踪线”。比如最终交付的研报里出现了一个数字，你要能沿着血缘链路找到：这个数字来自哪个 Agent 的输出，它对应黑板的哪一条记录，原始数据是哪个数据源、哪个时间点采集的。这个追溯能力对金融场景太重要了。监管问你这个数字怎么来的，你不能说是“模型生成的”，你得拿出完整链路。

事故回放功能也要保留。线上环境跑出问题了，你需要的是一键重演能力——把当时的输入、当时的黑板上所有版本数据、当时的 Agent 输出全部存成一个“任务快照”，然后离线重新跑一遍，看能不能复现问题。没有这个机制，线上出问题基本只能靠猜，效率极低。

5.3 财务动作的护栏机制

在金融场景里，Agent 绝对不能有“无限权利”。你需要在系统里加入类似“权限刹车”的机制。

我的做法是引入一个独立的 Guard Agent，它不参与任务主流程，只负责在关键动作前做拦截检查。自动交易 Agent 准备发订单指令时，Guard Agent 会验证：订单价格是否在合理波动区间内，单笔金额是否超过限额，当前风控状态是否为“可交易”。任何一个检查不通过，订单就被拦截，并且进入人工审批队列。

这里有个细节：Guard Agent 不应该使用和业务 Agent 相同的模型。因为同源模型具有相同偏差，如果业务 Agent 产生了某种幻觉，Guard Agent 很可能用同一个幻觉来包庇它。我在生产系统里用的是不同厂商的两个模型做交叉验证，虽然成本翻倍，但安全性有了质的提升。

5.4 合规与审计视角

金融 AI 系统绕不开合规问题。Multi-Agent 的架构在这里反而有优势：每个 Agent 的职责边界清晰，天然适合按角色做权限审计。

你在设计之初就应该把每一个 Agent 都当作一个“独立员工”来对待。数据采集 Agent 应该只有读权限，没有写权限；交易执行 Agent 只能在授权额度下行动；报告合成 Agent 能读取所有分析结论，但不能发起资金动作。把这些权限映射到底层的 IAM 上，做到每个 Agent 的每条动作都有归属、有留痕。

另外，Agent 的所有交互记录要保留足够长的时间，并且不可篡改。一旦出现争议，你能拿出完整的“决策时间线”用来做事实认定。我在设计里通常要求每次决策都附带置信度分数和关键依据摘要，这两个信息能大幅增加审计的通过率。

6. 常见问题与避坑实录

最后这一章，我把这几年的实战经验压缩成一张“问题速查表”，都是真实踩过的坑，每一项后面都有解决方案。

6.1 模型幻觉在多 Agent 里会被放大

多 Agent 系统里有一个很反直觉的现象：单个模型的幻觉率如果走 5%，两个 Agent 协作后，最终结果里的错误比例可能会远远高于 5%。原因是 Agent A 产生了幻觉，Agent B 基于这个幻觉继续推理，会衍生出更多错误，而且推理链条越长，错误越容易被“合理化”掩盖。

我的对策是三个：一是强制每个 Agent 在输出关键数字时附带数据来源 ID，这个 ID 对应到源数据的唯一记录；二是设置交叉验证 Agent，对关键结论用另一套模型做独立验算；三是在链路末尾加“事实核查”步骤，任何中间结论如果不带来源标识，直接打回重做。

6.2 Agent 死循环与拖沓

你给 Agent 开放了工具调用能力之后，它有可能陷入死循环：反复调用一个工具，反复出现相同错误，反复重试。我见过一个舆情监控 Agent 因为某个数据接口返回格式异常，在 3 分钟内重试了同一个请求 47 次，白白消耗了大量 token。

解决死循环，第一要务是给所有工具调用设置最大重试次数和超时时间；第二是引入“尝试次数计数器”，同一个错误连续出现 3 次，Agent 就必须停止自动重试并上报编排器；第三是要在编排器里加一个全局循环检测——如果同一 Agent 的输出在 5 轮内没有变化，就强制终止任务。

6.3 令牌消耗爆炸

很多人做 Multi-Agent 项目的预算超支，问题出在哪？在于每个 Agent 都要带一份“完整历史”用来理解背景，多 Agent 叠加后，大量 token 被浪费在重复传递上下文上。

我的做法是给每类 Agent 设定一个“上下文预算”，比如分析 Agent 上限 8000 token、数据 Agent 上限 3000 token。超出的部分用摘要压缩，而不是生硬截断。我还会定期统计每个 Agent 的 token 消耗，快速发现异常消耗的调用链。有一次我发现一个 Agent 单次消耗 6 万 token，查下去原来是它把整个数据库表结构描述都加载到了上下文中，后续改成只加载当前任务需要的字段定义，消耗降了 80%。

6.4 团队与组织的障碍

这部分可能不像技术问题那么直观，但往往才是项目失败的根本原因。Multi-Agent 系统要求开发和业务团队紧密协作——业务要明确定义每个 Agent 的职责、权限和交互协议，开发要围绕这些职责做工程实现。

我见过最典型的问题是“业务甩手，开发自嗨”：业务只给了一句“做一个智能投顾”，然后就不参与了。开发自己闷头定义了 Agent 角色和流程，做完后发现业务根本不认，因为 Agent 的分析框架与真实投研流程差异太大。

我的建议是：业务方必须深度参与角色定义和评估集建设。至少每周要开一次“Agent 评审会”，业务人员现场拿真实案例来考 Agent，发现问题现场改 Prompt、改流程。这个过程要坚持两三个月，系统才算真正跑顺。

6.5 快速验证的推荐路径

如果你现在准备启动一个金融 Multi-Agent 项目，我推荐四条快速验证路径：

第一，不要一开始就追求完整平台能力，拿 Python + LangGraph/自研裸框架手工编排 3 个 Agent，跑通一个最小闭环比什么都重要。第二，把 Agent 的设计重心放在“输入输出 Schema”上，而不是 Prompt 上。Schema 是 Agent 协作的地基，地基稳了，后面什么都能加。第三，没有真实数据源之前，用 mock 数据和本地可部署的小模型（比如在本地跑 Jev 这类支持密钥申请和本地部署的模型助手）先把链路调通，验证设计逻辑，等逻辑成熟后再替换高性能模型和数据源。第四，上线前务必做好全链路的日志、血缘和版本管理，别等项目出事故后再补。

我个人在实际操作中最深的一点体会是：Multi-Agent 设计比拼的不是模型多聪明，而是工程约束多严密。只要你在角色边界、通信格式、状态管理和护栏机制上做到位，即使各 Agent 用的模型不强，整个系统也能稳定产出；反过来，如果这些地基没打好，就算每个 Agent 都配顶级模型，最终交付物照样漏洞百出。最后再分享一个小技巧：给你的每个 Agent 起一个“岗位说明书”，把职责、输入、输出、权限、相交互的 Agent 都写在一张表里，把它当作招聘新员工一样严格对待。这套文档不仅帮开发，也帮审计和后续迭代，是最值得投入的一笔时间。