三个部门抢一个接口排期，我把文档摘要系统拆成了四层

一、业务痛点：摘要这件事，没人愿意接

我们是家两百人规模的咨询公司，每年产出几千份调研报告、尽调材料和会议纪要。管理层最常提的需求是：“这份八十页的报告，给我一页的结论。”过去这件事靠实习生手动压缩，质量不稳定不说，交付周期还总卡在客户催得最急的时候。

今年初我立项做智能文档摘要系统时，以为最难的是模型效果。立项会上跑了一圈才明白，真正的阻力全在协作侧：

• 法务部要审：摘要涉及客户机密文档，原文直接发给外部模型 API，数据出域的合规风险没人敢签字。
• 业务部门要快：三个业务线都要接入，每条线文档格式不同（PDF、Word、扫描件），需求排期吵成一团。
• 财务要算账：不同模型价格差十倍，摘要任务用顶配模型还是轻量模型，直接影响年度 AI 预算。
• IT 只有两个人：我们运维资源有限，接五家模型厂商 SDK、管一堆 API Key、写各自的限流重试逻辑，这个方案评审时就被我否了。

一句话总结：效果问题是技术问题，好解决；权限、成本、审计问题是管理问题，才是系统的骨架。

二、架构设计：四层拆分，各管各的

我把系统切成四层，每层对应一个明确的责任人，这也是后续跨部门协作能推进下去的关键：

┌─────────────────────────────────────────┐
│ 应用层：Web摘要工作台 / 业务系统API / 定时批处理 │
├─────────────────────────────────────────┤
│ 业务逻辑层：文档解析 → 长文分块 → 摘要编排 → 质量校验 │
├─────────────────────────────────────────┤
│ 统一AI网关层：单一接入点，密钥托管、模型路由、用量统计 │
├─────────────────────────────────────────┤
│ 模型层：长文本模型（初稿）+ 轻量模型（润色/标题）│
└─────────────────────────────────────────┘

几条管理者视角的设计原则：

1. 应用层只认一个网关地址。业务开发不接触任何模型厂商的 SDK 和 Key，所有请求走统一 AI API 网关，Key 由网关侧统一托管和轮换。
2. 模型路由按任务分级。八十页报告的初稿摘要走长上下文模型，生成标题、润色措辞这类轻任务走便宜的小模型，成本账在架构层面就算清楚，不用等月底复盘才发现超标。
3. 摘要结果落库留痕。谁在什么时间对哪份文档调了什么模型、花了多少 token，全部留审计记录，法务那边一次过审。

三、关键实现步骤

步骤清单（流程版）

1. 文档接入：监听文档库上传事件，触发解析流水线；
2. 格式归一：PDF/Word/扫描件统一转为纯文本，扫描件走 OCR；
3. 分块摘要：超长文档按章节分块，逐块生成局部摘要（Map 阶段）；
4. 汇总提炼：局部摘要合并后生成最终结论（Reduce 阶段）；
5. 质量校验：轻量模型检查摘要是否遗漏关键数字与结论，不合格自动重试一次；
6. 结果投递：写回文档系统，按部门权限分发。

核心编排代码（简化版）

import os

GATEWAY_BASE = os.environ["GATEWAY_BASE"]   # 统一网关地址
GATEWAY_KEY  = os.environ["GATEWAY_KEY"]    # 网关侧密钥，业务不接触厂商Key

def summarize_document(doc_id: str) -> dict:
    text = parse_and_ocr(doc_id)

    # Map：分块摘要，走长上下文模型
    chunks = split_by_section(text, max_tokens=6000)
    partials = []
    for chunk in chunks:
        partials.append(call_gateway(
            model="long-context-model",
            messages=[{"role": "user",
                       "content": f"提炼以下章节的核心结论与关键数据：\n{chunk}"}],
            timeout=60, retries=2,
        ))

    # Reduce：汇总，同样走网关，模型在网关侧可配置切换
    final = call_gateway(
        model="long-context-model",
        messages=[{"role": "user",
                   "content": "合并以下分章摘要为一页结论：\n" + "\n".join(partials)}],
    )

    # 质检：轻量模型做遗漏检查，控制成本
    check = call_gateway(
        model="light-model",
        messages=[{"role": "user",
                   "content": f"对比原文摘要与结论，列出遗漏的关键数字：\n{final}"}],
    )
    if check.strip() not in ("无", "none"):
        final = refine(final, check)  # 补一轮重试

    log_usage(doc_id)  # 审计留痕：模型、token、耗时
    return {"doc_id": doc_id, "summary": final}

注意代码里没有任何一家模型厂商的 SDK——全部请求打到同一个网关端点。模型升级或更换时，只改网关侧配置，业务代码一行不动。

四、为什么统一网关能砍掉维护成本

这是我评审时算给团队听的一笔账：

• 对接成本从 N 到 1。直连多家厂商意味着每家一套鉴权、错误码、限流规则和 SDK 版本依赖。统一网关后，业务侧只维护一个端点、一套错误处理，厂商侧的差异被网关屏蔽。
• 密钥治理集中化。过去 Key 散落在各个脚本和环境变量里，泄露了都未必知道。网关托管后，密钥轮换、权限分级、调用日志一处管理，法务和安全的合规检查有了单一抓手。
• 模型可替换性。摘要模型三个月换一代，价格波动也大。走网关路由，切换模型是配置变更而不是代码变更，两个开发人员不会被模型迁移排期绑架。
• 成本可视。网关的用量统计按部门、按任务类型出账，财务不再月底对账对到头疼，预算超支在周报里就能看到苗头。

系统上线三个月，两个 IT 人员维护整个流水线绰绰有余，模型侧的运维时间几乎为零——省下来的精力都花在摘要质量和业务对接上了。

五、写在最后

从管理者角度看，AI 应用落地的胜负手往往不在提示词，而在于权限、成本、审计这三件事有没有在架构第一天就被设计进去。统一 AI API 网关正是把这些管理诉求收敛到一个技术抓手上的方案。

如果你的团队也在规划类似的 AI 应用，可以从统一接入开始搭底座：https://api.thistoken.ai/register

---

本文的示例只需一个 API Key 就能复现：在 https://api.thistoken.ai/register 注册即用。