报告不是场景，是管道——复合流程容器实战

现状之痛：场景路由解决了90%的单场景任务。但剩下10%的复合任务怎么办？一份报告里有询价、有报价、有催单、有DN、有POD——一个场景装不下。

读完你将：学会复合流程容器——把复杂任务拆成五阶段管道，让报告稳定输出。

---

一、问题：报告里有太多「小任务」

场景路由体系上线后，单场景任务质量显著提升。但报告生成成了例外。

一份在途报告看起来是个简单输出任务，但内部包含大量子任务：

• 需要读取INBOX的所有邮件（邮件场景的能力）
• 需要查询每票的当前状态（查询场景的能力）
• 需要整理应收应付数据（财务场景的能力）
• 需要给出每条状态的判断（决策场景的能力）

更复杂的是，报告里的每一封邮件都要单独判断：这票该关闭了吗？有新的DN/POD到了吗？需要催代理吗？这些判断又涉及多种场景的交织。

最初尝试把报告当作一个「报告场景」处理——配所有工具，让它自由发挥。结果可想而知：LLM在多个工具域之间反复跳跃，输出不稳定，有时漏掉关键邮件，有时重复催单。

核心洞察：报告不是一个场景（scene），而是一个流程容器（pipeline container）——它编排多个场景的执行，而不是自己成为一个场景。

---


*▲ 五阶段复合流程容器：汇总→拆解→分发→执行→报告*

---

二、核心思路：五阶段管道

重新定义报告生成流程，分解为五个阶段：

① 汇总 → ② 拆解 → ③ 分发 → ④ 执行 → ⑤ 报告

第一阶段：汇总。 全量读取报告周期内的所有邮件、数据更新、事件日志。这个阶段不分类、不判断、不筛选——只是收集。

第二阶段：拆解。 将汇总的内容按邮件、按票、按主题拆解为独立的工作单元。每个工作单元包含：原始数据、待判断事项、关联票号。

第三阶段：分发。 将每个工作单元路由到对应的场景处理器。邮件的去邮件场景，财务的去财务场景，追索的去追索场景。每个子任务在自己独立的上下文中执行。

第四阶段：执行。 每个子任务独立执行，输出结构化的子结果。邮件场景输出「已分类+已判断」，财务场景输出「应收应付汇总」，追索场景输出「催单建议」。

第五阶段：报告。 将所有子结果汇总为一个完整的报告文本，按统一的格式输出。

---

三、技术实现

3.1 流程容器的特例：不限制工具

对于报告流程，场景路由做了一个特例：不限制工具集。

这不是违背场景路由原则，而是「流程容器」概念的体现。报告流程需要访问邮件（邮件场景工具）、需要查询数据库（查询场景工具）、需要生成表格（报告场景工具）。限制任何一类工具都会导致报告不完整。

但「不限制工具」不等于「无规则」。报告流程依然遵守所有铁律，门禁系统依然在关键节点检查行为合规性。

3.2 管道代码

def generate_report(period):
    # ① 汇总：全量读取
    all_mails = fetch_inbox(period)
    all_events = fetch_events(period)
    raw_data = all_mails + all_events

    # ② 拆解：按票/主题拆分
    work_units = split_into_units(raw_data)
    # [{"ticket": "TK001", "mails": [...], "pending": [...]}, ...]

    # ③ 分发：路由到场景
    dispatched = {}
    for unit in work_units:
        scene = classify_unit(unit)  # 复用双层分类
        dispatched.setdefault(scene, []).append(unit)

    # ④ 执行：各场景独立处理
    results = {}
    for scene, units in dispatched.items():
        results[scene] = process_scene(scene, units)

    # ⑤ 报告：LLM只做最终组装
    report = llm_assemble(results)
    return report

3.3 关键：脏活脚本干，LLM只做最后组装

为什么前四个阶段用脚本而不是LLM？

因为脏活（扫邮件、清数据、做统计）不适合LLM做——它慢、贵、不稳定。脚本做脏活又快又准，LLM做最终组装输出风格统一。各取所长。

# 阶段④执行：纯脚本（no_agent）
def process_scene(scene, units):
    if scene == "email":
        return classify_and_judge(units)  # 脚本逻辑
    elif scene == "finance":
        return summarize_finance(units)   # 脚本统计
    return None

# 阶段⑤报告：LLM
def llm_assemble(results):
    prompt = build_prompt(results)  # 结构化数据
    return llm_call(prompt)          # 组装自然语言

✅ 验证：改造后报告稳定性从~60%提升到~95%。数据来源可追溯，判断依据清晰，输出格式统一。

踩坑：最早让LLM「自由发挥」直接生成报告，结果时好时坏——有时报告很详细，有时只有三行。关键转折是接受了「定时任务让大模型自由发挥就不稳定了」这个反馈，改成五阶段管道。

价值：每个阶段有明确的输入、输出和验证标准。LLM的角色从「报告撰写者」变成了「SOP执行者」。

▸ 认知跃迁：原子场景保证质量，组合流程完成任务。场景是原子，流程是组合——不同粒度的抽象层级。

---

四、优缺点

✅ 优点

• 报告稳定——五阶段SOP确保每次都按相同流程执行
• 每封邮件归类处理——不会漏掉周期内的任何邮件
• 草稿箱统一存放——报告草稿可追溯、可复查
• 判断有依据——每个结论都标注数据来源
• 跨子任务隔离——一个子任务的错误不会影响其他子任务

⚠️ 缺点

• 依赖SOP写得细——SOP不够详细时，LLM会自行发挥
• 多场景自动拆解还需编排框架——当前是手动编排的流程
• 流程容器增加了延迟——五阶段比单场景多消耗约30%时间
• 复合任务的边界模糊——有些任务介于单场景和复合流程之间

---

五、此刻的你

此刻的你，已经不再是那个「把报告当场景、给Agent所有工具自由发挥」的乐观主义者。你正在成为一个能用流程容器编排复杂任务的系统设计者。

报告不是场景，是流程容器。场景是原子（atomic），处理单一职责的任务。流程是组合（composite），编排多个原子场景完成复杂目标。

下一篇：系统跑起来了，怎么知道它可靠？可观测性三件套——门禁+审计+纠正沉淀，让商业化Agent持续改进。

---

️ 实体：复合流程容器, 五阶段管道, 场景编排 价值：报告自动化, 复杂任务拆解, 输出稳定 认知：从「报告场景」到「流程容器」——原子保证质量，组合完成任务