企业官网建设流程全解析

前段时间，我按“多模型议会”（LLM Council）的思路搭了一套自动化流程，目标是让 9 个不同模型协作生成一份金融通讯稿。架构听起来很完整：资讯摘要、宏观分析、行业研究、数字校验、事实核查、观点生成、风险审查、文风润色、主编终稿，每个环节由不同模型负责。但真正跑起来之后，问题一个接一个：同一份财报，两个模型给出的营收增速完全相反；审查模型和写作模型互相较劲，改了三轮内容反而更差；一轮完整跑完，token 消耗高得吓人。

这篇文章不是来夸“多模型协作多先进”的，而是想把这套 9 模型议会系统里真正会坏的地方拆开讲清楚。适合正在做多智能体应用、想用多模型写报告或做内容类产品的开发者，也适合已经踩过坑想找排查思路的读者。读完你会知道：哪些问题来自模型本身，哪些问题来自流程设计，哪些问题干脆不应该用模型解决。

1. 背景与核心概念

1.1 什么是 LLM Council 多模型议会

LLM Council，也叫多模型委员会、模型议会，是一种把多个大语言模型组合到同一个任务里的架构模式。它不是一个标准化框架，更像一类设计思路。常见形态有三种：

• 平行投票：多个模型对同一个问题分别作答，最后投票或评分选出最佳答案。
• 角色分工：每个模型只负责流水线里的一个环节，比如摘要、分析、审查、润色。
• 辩论迭代：多个模型互相审阅对方输出，提意见，再让目标模型修改，循环若干轮。

9 模型议会是规模比较大的配置。成员一多，角色划分可以更细，理论上能覆盖更完整的业务链路。但也正因为成员多，协调成本、错误传播和上下文污染都会被放大。这个架构的难点不是“怎么让模型说话”，而是“怎么让多个模型的输出在同一个流程里可靠地衔接”。

1.2 为什么是金融通讯稿

金融通讯稿是一个很典型的“适合但没那么简单”的场景。

适合是因为金融文本结构化程度高：有固定的信息单元，比如指数涨跌幅、公司财报数据、宏观指标、风险提示，输出模板相对明确。而且金融分析需要多角度交叉验证，宏观、行业、公司、风险几个视角天然可以拆给不同模型去做，符合议会模式的直觉。

不适合也有充分理由。金融资讯对事实准确性要求极高，一个数字错误可能造成完全错误的解读；时效性又强，从数据更新到稿件发布之间的时间窗口很短；更麻烦的是，最终输出有被读者当成投资建议的风险。这些问题叠加在一起，会让 9 模型议会里的每一个薄弱环节都被放大。

1.3 9 个模型不等于 9 倍能力

这是本文想强调的核心认知。

很多团队搭建多模型系统时，默认“模型多 = 质量高”。实际恰恰相反，模型数量带来的是系统复杂度提升，错误面也随之扩大。9 个模型中任何一个输出不可靠，后续环节都会继承这个错误：摘要员漏掉关键数据，分析员就会在错误数据上继续推演；分析员引用了过期信息，核查员如果没识别出来，主编就会把错误结论写进终稿。

也就是说，9 模型议会的能力上限取决于组织流程的质量，而不是模型数量。本文后面拆解的所有故障，几乎都源于这个基本矛盾。

2. 九个角色怎么分工

2.1 角色清单与职责

一个可运行的 9 模型议会，需要先定义清楚每个模型的角色边界。下面是我在示例中采用的角色拆分：

注意，这里的角色是“逻辑角色”，不一定必须对应 9 个不同厂商的模型。你可以用同一个模型的不同 prompt 扮演多个角色，也可以真的让 9 个不同模型各干各的。角色拆分越细，每个环节的 prompt 越容易控制，但流程越复杂，衔接处越容易出问题。

2.2 数据流与编排方式

整个流水线大致如下：

1. 定时任务拉取原始资讯，可以是 RSS、API 或爬虫抓取结果。
2. 调用 news_summarizer 把原始资讯转换成结构化摘要条目。
3. macro_analyst 和 industry_analyst 并行分析摘要，得到两个分析视角。
4. data_checker 和 fact_checker 对分析结果做校验。
5. 校验通过后，view_generator 生成观点草稿。
6. risk_reviewer 检查合规风险。
7. copy_editor 润色文案。
8. editor_in_chief 汇总所有中间结果，输出终稿。

编排方式上，宏观分析和行业分析可以并行，其他环节大多是串行。串行环节越多，整体延迟越高；并行环节越多，资源竞争和上下文拼接越复杂。这里的每一步都是潜在故障点：上游输出格式不对，下游直接崩溃；一个模型超时，整条流水线卡住。

2.3 为什么容易“坏”

一句话总结：多环节串行流程会把单点错误放大成系统性错误。

单一模型生成文本时，出错影响范围相对可控。但在议会模式里，模型 A 的输出是模型 B 的输入，模型 B 的输出又成为模型 C 的审查对象。任何一环的错误，都会像滚雪球一样传递下去。再加上不同模型的能力、偏好、参数设置不一致，很多问题在单一模型测试时根本不会出现。

3. 环境准备与版本说明

3.1 运行环境

我使用的参考环境如下，你的实际情况可能不同，重点看配置思路：

• 操作系统：Linux / macOS / Windows 均可
• Python：3.10 或更高版本
• 依赖：openai SDK、anthropic SDK、requests，具体按接入的模型厂商 SDK 安装
• 运行方式：命令行脚本或定时任务均可

版本相关说明：不同厂商 API 的版本变化很快，本文示例中的模型名只作为展示，运行时请以你账号实际可用的模型名为准。不要照搬模型名到生产环境，尤其是 OpenAI、Anthropic、本地 Ollama 的模型列表经常更新。

3.2 模型接入方式

接入方式有三种主流选择：

• 云端商业 API：如 OpenAI、Anthropic、通义千问等，响应质量高，但按 token 计费。
• 本地开源模型：如通过 Ollama、vLLM 部署 Qwen、Llama、DeepSeek 等，数据不出内网，但需要 GPU 资源。
• 混合模式：部分角色用云端模型，部分角色用本地模型。

混合模式最常见，也最容易出问题。不同模型的响应格式、超时时间、速率限制都不同，统一封装层必须处理这些差异。另外要明确：不是所有模型都必须部署在同一台电脑上。很多人在问“ComfyUI 与 LLM 是否必须在同一台电脑上”，其实这取决于工作流的编排方式。在我们这个场景里，九个模型分布在多个 API 和本地推理服务上是常态，跨机调用带来的超时、限流、鉴权和上下文传输问题，远比模型本身的问题更频繁。

3.3 项目结构

建议按下面结构组织代码：

llm_council/ ├── main.py # 入口与定时任务 ├── callers.py # 统一模型调用封装 ├── roles.py # 9 个角色定义 ├── pipeline.py # 流水线编排 ├── output/ # 结果输出目录 └── prompts/ # 各角色提示词文件

把角色定义、调用封装、流程编排拆开，后续排查问题时能快速定位是哪一层出了问题。

4. 最小可行的多模型议会实现

4.1 统一模型调用层

为了让 9 个角色都不需要关心模型来源，先写一个统一的调用封装。这是整个系统能跑起来的基础。

# 文件路径：llm_council/callers.py import os import re import json from openai import OpenAI def call_model( provider: str, model: str, system_prompt: str, user_prompt: str, max_tokens: int = 1024, temperature: float = 0.3, ) -> str: """统一模型调用入口。 provider 支持 openai / anthropic / ollama。 实际使用前，请先安装对应 SDK，并按你的版本调整参数。 这里给的是最简示例，线上建议增加超时、重试和日志。 """ messages = [ {"role": "system", "content": system_prompt}, {"role": "user", "content": user_prompt}, ] if provider == "openai": client = OpenAI( api_key=os.getenv("OPENAI_API_KEY"), base_url=os.getenv("OPENAI_BASE_URL"), ) resp = client.chat.completions.create( model=model, messages=messages, max_tokens=max_tokens, temperature=temperature, ) return resp.choices[0].message.content if provider == "anthropic": from anthropic import Anthropic client = Anthropic(api_key=os.getenv("ANTHROPIC_API_KEY")) resp = client.messages.create( model=model, max_tokens=max_tokens, temperature=temperature, system=system_prompt, messages=[{"role": "user", "content": user_prompt}], ) return resp.content[0].text if provider == "ollama": import requests prompt = f"system:\n{system_prompt}\n\nuser:\n{user_prompt}" resp = requests.post( "http://localhost:11434/api/generate", json={"model": model, "prompt": prompt, "stream": False}, timeout=180, ) return resp.json()["response"] raise ValueError(f"不支持的 provider: {provider}")

实际项目中，这个封装层还需要处理：超时重试、速率限制、token 截断、调用日志。线上的失败场景往往发生在这些边界里。

4.2 定义 9 个角色

角色定义可以放在单独文件里，方便统一管理 prompt 和模型映射。

# 文件路径：llm_council/roles.py ROLES = { "news_summarizer": { "provider": "openai", "model": "gpt-4o-mini", "system": "你负责把原始新闻压缩成结构化条目，每条必须包含：标题、日期、核心事实、来源链接。不要添加原文没有的信息。", }, "macro_analyst": { "provider": "anthropic", "model": "claude-3-5-sonnet", "system": "你负责宏观环境分析，输出格式为 JSON，包含 trend、evidence、risk 三个字段。所有判断必须基于输入摘要，不允许猜测数据。", }, "industry_analyst": { "provider": "openai", "model": "gpt-4o", "system": "你负责行业景气度分析，输出格式为 JSON，包含 outlook、valuation、risk 三个字段。注意与宏观分析相互独立。", }, "data_checker": { "provider": "openai", "model": "gpt-4o-mini", "system": "你负责检查所有数字的一致性。输入中如果出现互相矛盾的数字，必须列出冲突项，并说明哪个数字更可信、理由是什么。输出格式为 JSON。", }, "fact_checker": { "provider": "anthropic", "model": "claude-3-5-sonnet", "system": "你负责事实核查。对每条关键断言判断是否能在输入材料中找到依据，存在可疑信息时必须标记出来。", }, "view_generator": { "provider": "openai", "model": "gpt-4o", "system": "你负责根据通过校验的分析结果生成观点草稿。观点必须与数据一致，不能编造未出现的逻辑。", }, "risk_reviewer": { "provider": "anthropic", "model": "claude-3-5-sonnet", "system": "你负责合规审查。检查文本是否可能被理解为投资建议，缺少风险提示时给出修改建议。", }, "copy_editor": { "provider": "openai", "model": "gpt-4o-mini", "system": "你负责把草稿改写成订阅者友好语气：段落短一些、专有名词保留、不改变数据事实。", }, "editor_in_chief": { "provider": "anthropic", "model": "claude-3-5-sonnet", "system": "你是主编。汇总所有中间结果，输出一篇结构完整、含风险提示的金融通讯稿。不要复制审查意见，只输出最终内容。", }, }

这里的模型名只是示例。实际使用时，你应该根据成本、速度和效果选择合适的模型，并把模型名放到配置中心或环境变量里，而不是写死在代码中。

4.3 流水线主流程

主流程的关键点有三个：并行执行、格式解析、失败降级。下面是一个简化版实现，重点展示多角色如何串联。

# 文件路径：llm_council/pipeline.py import json import re from concurrent.futures import ThreadPoolExecutor from callers import call_model from roles import ROLES def safe_parse_json(raw: str): """解析模型输出的 JSON，兼容多余文字和代码块包裹。""" if not raw: return None # 去掉 markdown 代码块 cleaned = re.sub(r"^```(?:json)?|```$", "", raw.strip(), flags=re.MULTILINE) try: return json.loads(cleaned) except json.JSONDecodeError: # 尝试截取第一个大括号到最后一个大括号 start = cleaned.find("{") end = cleaned.rfind("}") if start != -1 and end != -1 and end > start: try: return json.loads(cleaned[start : end + 1]) except json.JSONDecodeError: return None return None def run_one(role_name: str, user_prompt: str) -> str: cfg = ROLES[role_name] return call_model( provider=cfg["provider"], model=cfg["model"], system_prompt=cfg["system"], user_prompt=user_prompt, ) def run_pipeline(raw_news: str) -> str: # 1. 摘要 summary = run_one("news_summarizer", f"请压缩以下资讯：\n{raw_news}") # 2. 宏观 + 行业 并行分析 with ThreadPoolExecutor(max_workers=2) as pool: macro_future = pool.submit(run_one, "macro_analyst", summary) industry_future = pool.submit(run_one, "industry_analyst", summary) macro_text = macro_future.result() industry_text = industry_future.result() # 3. 数据校验并尝试解析 check_text = run_one("data_checker", f"宏观结论：\n{macro_text}\n\n行业结论：\n{industry_text}") check_result = safe_parse_json(check_text) # 4. 如果数字冲突严重，可回退到 fact_checker 或直接终止 if check_result is None: return "pipeline failed: data_checker 输出无法解析为 JSON" # 5. 观点生成 view = run_one("view_generator", f"通过校验的分析结果：\n{json.dumps(check_result, ensure_ascii=False)}") # 6. 风险审查 risk_text = run_one("risk_reviewer", view) risk_result = safe_parse_json(risk_text) # 7. 润色 edited = run_one("copy_editor", view) # 8. 主编终稿 final = run_one( "editor_in_chief", f"请基于以下内容输出最终通讯稿：\n\n{edited}\n\n风险审查建议：\n{risk_text}", ) return final

这段代码的核心价值在于：把并行、解析、失败判断这几个最容易“坏”的点单独露出来。后面排查问题时，你会发现在这些位置补逻辑比换模型更有效。

4.4 预期输出与效果

跑通后的输出应该是一篇结构完整的金融通讯稿，包含市场回顾、行业观察、风险提示和免责声明。但第一次能跑通只是起点，距离“稳定可用”还有很长的路。你在执行时大概率会遇到：某一步输出不是合法 JSON、某个模型超时、某个模型把审查建议写进了正文。

5. What breaks：九模型议会的高频故障拆解

5.1 数字不一致与事实幻觉

金融场景里最致命的问题，是不同模型输出互相矛盾的数据，而且每个模型都“信心满满”。比如宏观分析师引用某个指数涨跌幅，行业分析师引用了同一指数但数值不同；又比如一个模型说“公司营收同比增长 15%”，另一个模型说“同比下降 2%”，中间没有任何一个环节能直接判断哪个正确。

根本原因有几个：

• 模型训练数据截止时间不同，对同一事件的记忆有差异。
• 模型会把上一轮的输出当成事实，即使上一轮是错的。
• 多数模型没有实时数据源，所谓“实时”依赖于输入材料是否完整准确。

解决方案不能依赖“再找个模型来投票”。更可靠的是让模型在输出数字时附上来源标记，比如“根据输入材料 3 的财报数据，营收同比增长 15%”。然后再用一套硬编码规则去核对输入材料里是否存在对应数字。数字一致性检查应该优先用代码去比对，而不是让另一个模型去猜。

5.2 互相否定与无限修订

多模型议会里常见的画面是：编辑模型写完初稿，审查模型挑出 5 个问题，写作模型修改后，另一个审查模型又挑出 4 个新问题，改到第三轮时内容已经偏离原意，甚至把正确答案改成了错误答案。这就是模型之间的“无限修订”。

原因在于审查模型没有被限制修改范围。它面对任何文本都能找出可以调整的地方，因为语言表达本身没有绝对最优。每次修改都在消耗 token，也都在增加语义漂移的风险。

解决思路是给修订轮次设硬上限，比如最多两轮。同时把审查模型的职责从“自由点评”改成“只列出必须修改项”。必须修改项包括：数字错误、来源缺失、合规风险。措辞风格类建议直接丢弃，不让它进入修改循环。

5.3 上下文污染与角色串音

上下文污染是指某个模型错误地把其他模型的中间过程当成了事实，导致最终结论扭曲。典型现象是：主编的输出里出现了“数据检查员认为这里可能有误”“事实核查员对某个数字存疑”这样的审查过程语言，而不是干净的结论。

原因也很明显：我们把太多中间过程拼接进了同一份 prompt。模型无法区分哪些是“已确认事实”，哪些是“待核查的判断”。在长上下文中，早期指令还会被后续内容稀释，模型更容易被靠近输出的那部分内容带偏。

解决办法是角色隔离。每个角色只拿到它完成任务所必需的最小上下文。比如主编需要的是“通过校验的最终观点 + 合规意见”，而不是把 9 个模型的原始输出全部塞给它。中间结果可以做结构化落盘，让每个环节只读取自己需要的字段。

5.4 输出格式漂移与解析失败

多模型并存的系统里，最头疼的故障不是模型答错，而是模型没有按约定格式输出。OpenAI 返回的是纯文本，Anthropic 返回 content 数组，本地 Ollama 返回的字段名又不一样。更常见的是：某个模型在输出 JSON 前后加了一段说明文字，或者中途截断，导致 json.loads 直接报错。

这类问题看起来是小事，但一旦加入 9 个模型和多个串行环节，概率会被放大。一个环节解析失败，后续所有环节都停摆。

应对方案是把解析逻辑收敛到统一函数里，并做好容错：

• 去掉 markdown 代码块标记。
• 提取第一个{到最后一个}之间的内容。
• 如果解析失败，让调用层记录原始输出，方便排查。
• 必要时做一次带错误信息的重试，但重试次数不宜超过一次。

5.5 成本与延迟失控

9 个模型 × 多轮迭代 × 大上下文，token 成本上涨速度远超预期。一次完整流水线可能消耗几十万 token，如果中途还有修订循环，成本还会翻倍。延迟同样不可控：串行环节多，任何一个模型慢都会拖垮整体时效，而金融资讯恰恰对时效敏感。

这里想多说一句部署方式。很多人在问“ComfyUI 与 LLM 是否必须在同一台电脑上”，类似的问题也会出现在多模型议会里：9 个模型非要部署在同一台机器上吗？答案是否定的。真正的常态是混合部署，本地模型处理敏感数据，云端模型处理高质量生成。但这会引入新的故障面：跨机调用超时、API 限流、鉴权失败、上下文传输延迟。部署拓扑越复杂，故障排查越难。

成本控制的核心不是省每个模型的单次调用，而是避免无意义的重复调用：

• 先让小模型做初筛，只有存在争议的内容才交给大模型。
• 给每个角色设置独立的 token 上限。
• 监控每次调用的输入、输出 token 数和耗时。

5.6 合规安全边界模糊

金融通讯稿天然处于合规敏感区。9 个模型并不理解不同国家和地区的监管要求，它们只会按照 prompt 里的指令输出文本。如果没有额外保护措施，最终稿可能读起来像一份“投资建议”，这是非常危险的结果。

在这套系统里，合规不能交给模型自觉。风险审查模型只能作为辅助工具，真正的合规底线要靠流程保证：输出前强制添加免责声明；明确文案定位是“信息摘要”而非“投资建议”；发布前必须经过人工审核。涉及未公开的市场敏感数据时，也要谨慎决定是否调用第三方云端 API。

6. 常见问题清单与排查思路

6.1 高频报错对照表

6.2 系统化排查步骤

遇到问题不要一上来就换模型。按下面顺序排查：

1. 先复现：用同样的输入再跑一次，确认是不是随机性问题。
2. 看日志：检查是哪个环节失败，找到第一条报错记录，而不是只看最终结果。
3. 隔离变量：把失败环节的输入输出单独拿出来，用单个模型直接调用，判断是模型问题还是上游数据问题。
4. 检查 prompt：确认是否要求了 JSON 输出、是否加入了来源标记要求。
5. 检查上下文：看看传给该角色的 prompt 里有没有多余的中间过程内容。
6. 看成本：统计每个角色的 token 消耗，找出成本异常点。

6.3 如何避免问题再次出现

• 所有模型调用必须记录输入输出，这是排查问题的前提。
• 每个角色只接收最小必要上下文，减少污染概率。
• 输出格式统一用 JSON，并让所有模型遵循同一个 schema。
• 对重写、审查循环设置硬性上限，不能无限迭代。
• 每次修改 prompt 后，用固定的小样本集做回归测试。

7. 从“会坏”到“稳定”：工程化改进

7.1 先小后大、先主后次

如果你是第一次搭多模型协作系统，不建议直接上 9 个模型。更合理的路径是：先做一个两模型 MVP，一个负责起草，一个负责挑错；再配合一段硬编码数据校验脚本。跑通之后，再根据实际短板逐步拆角色、加模型。这样你能清楚知道每个新增模型到底解决了什么问题，而不是凭空增加故障点。

7.2 用规则引擎做硬校验

模型擅长处理语义，不擅长精确计算。数字一致性、来源是否存在于输入材料中、免责声明是否包含，这些任务应该交给规则引擎或脚本去完成。比如用正则提取“同比增长 xx%”中的数字，然后与输入数据源对比。规则引擎不能解决所有幻觉问题，但能把最危险的数字错误拦截在发布之前。

7.3 上下文隔离与版本追溯

给每轮流水线生成一个唯一 ID，所有中间结果都带上这个 ID 落盘。这样你可以回溯到任何一个模型的输入是什么、输出是什么。上下文隔离方面，每个角色消费的必须是上一环节的结构化输出字段，而不是完整对话历史。主编看到的应该是干净的结论，而不是一堆待办意见。

7.4 成本预算与观测指标

为每个角色单独设置成本上限，并记录以下指标：

• 单次调用的输入 token 数、输出 token 数
• 调用耗时
• 重试次数
• 是否解析失败
• 该角色是否存在修改轮次

这些指标能帮你快速判断系统是“模型能力不足”还是“流程设计不合理”。成本预算要提前设，不要在月底看账单时才后悔。

7.5 人工审核与合规底线

不管系统多成熟，金融通讯稿发布前必须有人工审核环节。这不是“对模型的信任问题”，而是责任边界问题：模型出错，责任最终在发布方。可以让人工只审核最终稿，但审核模板必须包含：所有数字是否与原始材料一致、是否存在投资建议表述、是否包含免责声明、是否有明显逻辑断层。

7.6 评估集与回归测试

为内容生成系统准备一个固定评估集非常重要。收集 10 到 20 条历史资讯，记录下每个环节的理想输出，作为回归基线。每次修改 prompt、更换模型、调整编排方式后，都用这套样本跑一遍，对比输出质量。没有评估集的系统，永远无法判断一次修改是变好了还是变坏了。

8. 总结与下一步

9 模型议会这套架构，真正难的不是模型数量，而是流程控制。每个模型单拎出来都可能很强，但把它们串成流水线后，会遇到数字不一致、互相否定、上下文污染、格式漂移、成本失控、合规模糊这六类问题。这些问题几乎没有一个是靠换更强模型能解决的，它们需要从流程设计、上下文隔离、硬编码校验、人为审核这些层面去解决。

如果让我重做一次这套系统，我不会再一上来就组 9 个模型。我会先跑一个“起草模型 + 挑错模型 + 数字校验脚本”的三角组合，确认它能稳定产出 7 分的内容后，再把耗时最多的环节拆成独立角色。多模型议会是把双刃剑，模型越多、故障面越大。真正让系统稳定的，永远是清晰的流程、可控的上下文、可观测的日志，和那个最后按下发布键的人。

如果你也在跑类似的 Multi-Agent 或 LLM Council 项目，欢迎在评论区聊聊你遇到过的模型互相否定问题。