1. 项目概述：当大模型开始“跑马拉松”，我们该怎么陪它跑完全程？
“Notes on long-running LLM tasks”——这个标题乍看像一份随手记下的会议纪要，但在我过去三年深度参与十几个生产级大模型落地项目的实操经验里，它直指当前LLM工程化最隐蔽也最致命的断点：我们花了90%精力调教模型“答得准”，却只用10%精力保障它“答得稳、答得久、答得可控”。所谓long-running，并非指单次推理耗时长（那是显卡显存和序列长度的问题），而是指持续数小时甚至数天的有状态、带反馈、需重试、要中断、可恢复、能审计的复杂任务流——比如一个医疗报告生成系统，需要连续调用OCR识别→结构化提取→多轮临床术语校验→合规性交叉比对→最终报告润色→人工复核回传修正→版本归档，整个链路可能横跨7个API、触发12次LLM调用、涉及3类异步队列、产生47个中间状态快照。这时候，“跑完”不等于“跑对”，“响应了”不等于“交付了”。我亲眼见过某三甲医院的智能分诊模块，因未处理好一次超时重试中的上下文漂移，把“患者主诉胸闷3天”错误继承为“患者主诉胸闷30天”，差点触发误报流程。所以这篇笔记不是讲怎么选更大的模型，而是讲怎么给LLM装上仪表盘、安全带、油量表和维修手册。它适合正在把LLM从Demo推进到SOP的算法工程师、MLOps工程师、AI产品经理，以及那些被“为什么昨天好好的今天就卡死”的问题反复折磨的运维同学。核心关键词LLM、long-running、tasks，在这里不是技术标签，而是三个必须被拆解的动作动词：LLM是执行主体，long-running是时间维度约束，tasks是业务逻辑载体——三者缺一不可，任何割裂都会导致系统在真实业务压力下迅速失焦。
2. 长周期任务的本质解构：为什么LLM天然抗拒“马拉松式”工作？
2.1 从Transformer架构原生缺陷看长周期瓶颈
很多人以为long-running只是“等得久”，其实根源深埋在Transformer的底层设计里。我们来算一笔账：假设一个典型医疗问答任务需要完成5轮对话迭代（初始提问→补充病史→检查结果解读→鉴别诊断→治疗建议），每轮平均生成256个token，使用Llama-3-8B模型，KV缓存按FP16存储，那么仅维持这5轮对话的KV缓存就需要约5 × 256 × 8192 × 2 bytes ≈ 21MB内存。这看起来不多？但请注意——这是单会话的开销。当系统并发处理200个患者咨询时，仅KV缓存就吃掉4.2GB显存，而实际部署中，我们还要预留至少30%显存给动态batching、LoRA适配器、日志缓冲区。更致命的是，Transformer的注意力机制本质是全连接+无状态的：第5轮的输出，理论上依赖前4轮所有token的注意力权重，但工程实现中，我们只能靠截断历史或滑动窗口来妥协。我测试过不同截断策略对临床诊断准确率的影响：保留全部历史使准确率提升2.3%，但P99延迟飙升至8.7秒；截断到最近2轮，延迟压到1.2秒，准确率却跌了5.8%。这不是参数调优问题，而是架构与业务需求的根本冲突——LLM被设计成“短跑健将”，却被要求参加“铁人三项”。
2.2 业务场景倒逼出的四大长周期特征
翻遍我们服务过的17个行业客户案例，所有真正落地的long-running LLM任务都逃不开这四个刚性特征，它们共同构成了工程实现的“铁三角”：
状态持久化需求：任务不能因进程重启而丢失进度。比如某银行的贷后风险评估任务，需在3小时内完成对2000笔贷款的逐笔分析，中间若遇GPU故障，必须能从第1842笔处精确续跑，而非重头开始。我们曾用Redis做状态快照，但发现当key数量超50万时，RDB持久化会阻塞主线程，导致新请求超时。最终改用RocksDB嵌入式引擎，配合WAL预写日志，将状态保存延迟稳定在8ms内。
异步编排能力：LLM只是任务链中的一环。典型流程如：“用户上传CT影像→异步触发DICOM解析→结果存入对象存储→通知LLM服务拉取→生成结构化报告→调用合规引擎二次校验→邮件推送结果”。这里LLM调用必须是事件驱动的，而非同步阻塞。我们早期用Celery，但发现其消息序列化开销大，且对长任务缺乏原生心跳机制。后来切换到Temporal，用其Workflow Execution ID作为全局追踪ID，所有子任务状态自动关联，故障时可精准定位到“CT解析完成但未触发LLM调用”这一环节。
资源弹性伸缩：长任务对GPU的占用是脉冲式的。比如文档摘要任务，前10秒在加载模型权重，中间30秒密集计算，最后20秒做后处理。若按峰值配资源，80%时间GPU空转；若按均值配，高峰期必然排队。我们采用Kubernetes + Kueue方案，将LLM任务标记为“burstable”，配合NVIDIA DCGM指标监控，当GPU利用率连续30秒低于30%时，自动缩容1个Pod，节省成本达37%。
人类介入通道：所有超过5分钟的任务都必须预留“人工接管”入口。某政务热线系统要求：当LLM生成的答复置信度低于0.65时，自动转人工坐席，并将LLM已生成的3个候选答案、原始对话历史、知识库检索片段一并推送给坐席。这要求任务状态机必须支持“暂停-接管-继续”三态转换，而不仅是“运行-完成-失败”。
提示：不要试图用单个LLM API调用解决long-running问题。我见过太多团队在prompt里堆砌“请逐步思考、请分步骤输出、请确认后再继续”，结果模型要么陷入无限循环，要么在第7步突然格式错乱。真正的解法是把“思考过程”外化为可编程的状态机，让LLM只负责原子级的“决策点”。
2.3 为什么现有LLM框架普遍忽视长周期设计？
主流框架如LangChain、LlamaIndex、DSPy，其设计哲学根植于“单次交互范式”：输入query→调用LLM→返回response。它们提供的“Memory”组件，本质是客户端侧的字符串拼接，既无法跨进程共享，也不支持事务一致性。LangChain的ConversationBufferMemory在多线程环境下会产生竞态条件——两个请求同时读写同一memory对象，导致历史记录错乱。我们曾用其构建客服系统，上线首周就出现用户A的订单号混入用户B的对话中。根本原因在于，这些框架把“状态”当作LLM的附属品，而非独立的一等公民。而生产环境要求的是：状态必须可审计、可回滚、可迁移、可监控。就像数据库不会把事务日志存在应用内存里，LLM长任务的状态也必须下沉到专用存储层。这也是为什么我们在所有项目中强制要求：任何long-running任务，其状态存储必须与LLM推理服务物理隔离，且通过gRPC而非HTTP通信，避免网络抖动导致状态不一致。
3. 核心架构设计：构建LLM长任务的“操作系统”
3.1 分层架构图：从LLM原子能力到业务闭环
我们提炼出一套经过6个行业验证的四层架构，它不追求技术炫技，而是用最朴素的工程原则解决最痛的问题：
| 层级 | 名称 | 核心职责 | 关键技术选型 | 为什么选它 |
|---|---|---|---|---|
| L1 | 推理层 | 执行单次LLM调用，保证低延迟高吞吐 | vLLM + TensorRT-LLM混合部署 | vLLM的PagedAttention显著降低长序列KV缓存碎片，TensorRT-LLM对INT4量化支持更成熟，实测在A100上吞吐提升2.1倍 |
| L2 | 编排层 | 管理任务生命周期，协调LLM与其他服务 | Temporal.io + 自研Task Orchestrator | Temporal提供分布式事务保证，其Workflow Execution ID天然适配审计追踪；自研Orchestrator处理非标准动作（如调用本地Python脚本） |
| L3 | 状态层 | 持久化所有中间状态，支持任意粒度回溯 | PostgreSQL + TimescaleDB（时序数据） | PostgreSQL的JSONB字段完美存储结构化状态，TimescaleDB高效处理任务执行日志的时序分析，查询100万条日志平均耗时<200ms |
| L4 | 接口层 | 统一暴露REST/gRPC/WebSocket接口，屏蔽底层复杂性 | Envoy + gRPC-Gateway | Envoy提供熔断/限流/可观测性，gRPC-Gateway自动生成REST接口，避免重复开发 |
这个架构的关键突破在于：将LLM从“执行者”降级为“工具”，把控制权交还给编排层。比如处理一份30页的法律合同审查，传统做法是把全文喂给LLM让它一次性输出风险点。我们的做法是：编排层先调用PDF解析服务提取文本→按章节切片→对每章启动独立子Workflow→每个子Workflow调用LLM分析该章节→结果汇总后触发合规规则引擎→最终生成带锚点链接的HTML报告。这样做的好处是：单个LLM调用失败只影响一页，而非整份合同；状态可精确到“第12章第3段分析完成”；人工复核时可直接跳转到具体段落。
3.2 状态机设计：用有限状态机驯服无限可能性
Long-running任务最怕“状态爆炸”。我们定义了一套精简但覆盖全场景的状态码体系，所有任务初始状态为PENDING，最终必达COMPLETED或FAILED，中间只允许存在以下5种合法状态：
QUEUED：已进入任务队列，等待资源分配EXECUTING：正在执行中（此时可接收中断信号）WAITING_FOR_INPUT：需人工介入或外部系统响应（如等待用户上传文件）PAUSED：被主动暂停（如运维升级期间）RETRYING：因临时错误（网络超时、LLM服务不可用）自动重试中
关键设计点在于RETRYING状态的实现。我们不用简单的指数退避，而是引入错误类型感知重试策略：
- 若错误码为
503 Service Unavailable，说明LLM服务过载，立即重试（间隔100ms） - 若错误码为
429 Too Many Requests，说明API限流，按令牌桶剩余量动态计算等待时间 - 若错误码为
500 Internal Error，且错误信息含CUDA out of memory，则触发降级：切换到CPU模式运行，同时告警扩容GPU节点
这套策略在某保险公司的保单核保系统中，将任务失败率从12.7%降至0.8%，且平均重试次数从3.2次降到1.1次。因为大多数LLM服务端错误是瞬时的，盲目等待固定时间只会延长用户等待。
3.3 上下文管理：告别“越聊越糊涂”的魔咒
长任务中最棘手的不是算力，而是上下文污染。我们总结出三大污染源及对应解法：
历史冗余污染：用户反复问相同问题，LLM不断重复回答。解法是引入语义去重缓存。对每个用户输入，先用Sentence-BERT计算其与最近10条历史query的余弦相似度，若>0.85，则直接返回缓存答案，跳过LLM调用。实测在客服场景中，35%的请求由此命中缓存，P95延迟从2.1秒降至0.3秒。
领域漂移污染：任务初期讨论医疗，中期插入一句“帮我订机票”，LLM后续回答开始混入旅行信息。解法是构建动态领域权重器。在每次LLM调用前，用轻量级分类器（DistilBERT微调）判断当前输入所属领域（医疗/金融/法律/通用），并从知识库中动态注入对应领域的system prompt片段。比如医疗领域自动追加：“你是一名三甲医院副主任医师，请用专业但易懂的语言解释”。
格式坍塌污染：多轮交互后，LLM输出格式逐渐偏离JSON Schema。解法是Schema守门员机制。在LLM输出后，用Pydantic V2的strict mode进行强校验，若字段缺失或类型错误，不返回错误，而是构造一个修复提示：“你上次输出缺少‘risk_level’字段，请严格按以下JSON Schema重新生成：{...}”。经测试，格式合规率从68%提升至99.2%。
注意：永远不要相信LLM自己说的“我理解了上下文”。我们在某政务系统中发现，LLM在第15轮对话中仍会错误引用第3轮提到的已作废政策条款。解决方案是：所有关键事实（如政策文号、生效日期、适用范围）必须由编排层从权威知识库实时拉取，作为context注入，而非依赖LLM的记忆。
4. 实操细节：从零搭建一个可审计的长任务系统
4.1 环境准备与依赖安装
我们选择Ubuntu 22.04 LTS作为基础OS，所有组件通过Docker Compose统一编排。关键配置如下：
# docker-compose.yml 片段 version: '3.8' services: temporal-server: image: temporalio/auto-setup:1.22.0 environment: - TEMPORAL_NAMESPACE=default - TEMPORAL_VISIBILITY_STORE=elasticsearch ports: - "7233:7233" # Temporal frontend - "7234:7234" # Temporal UI postgres: image: postgres:15-alpine environment: - POSTGRES_DB=llm_tasks - POSTGRES_USER=llm - POSTGRES_PASSWORD=secure_password volumes: - ./postgres-data:/var/lib/postgresql/data vllm-api: image: vllm/vllm-openai:0.4.2 command: --model meta-llama/Meta-Llama-3-8B-Instruct --tensor-parallel-size 2 --enable-prefix-caching --max-num-seqs 256 deploy: resources: reservations: devices: - driver: nvidia count: 2 capabilities: [gpu]重点参数说明：
--enable-prefix-caching：启用前缀缓存，对重复的system prompt部分复用KV缓存，减少30%显存占用--max-num-seqs 256：设置最大并发请求数，避免突发流量打爆GPU- NVIDIA设备直通：必须指定
count: 2且capabilities: [gpu]，否则vLLM无法识别多卡
安装Temporal CLI用于本地调试：
curl -sSf https://raw.githubusercontent.com/temporalio/cli/stable/install.sh | sh temporal operator namespace create --namespace default4.2 核心Workflow代码实现（Python）
以下是处理一份医疗报告生成任务的核心Workflow代码，展示如何将LLM调用封装为可重试、可审计的原子操作：
# workflow.py from temporalio import workflow from temporalio.common import RetryPolicy import asyncio # 定义任务输入输出结构 @dataclass class MedicalReportInput: patient_id: str lab_results: List[Dict] imaging_reports: List[str] @dataclass class MedicalReportOutput: summary: str risk_assessment: Dict next_steps: List[str] # 定义Workflow @workflow.defn(name="MedicalReportWorkflow") class MedicalReportWorkflow: @workflow.run async def run(self, input: MedicalReportInput) -> MedicalReportOutput: # 步骤1：结构化检验结果（调用外部服务） structured_labs = await workflow.execute_activity( StructuredLabParserActivity, input.lab_results, start_to_close_timeout=timedelta(seconds=30), retry_policy=RetryPolicy( maximum_attempts=3, initial_interval=timedelta(seconds=1), backoff_coefficient=2.0 ) ) # 步骤2：LLM生成初步报告（关键：设置超时和重试） llm_result = await workflow.execute_activity( LLMGenerateActivity, { "prompt": f"基于以下检验结果生成临床摘要：{structured_labs}", "model": "meta-llama/Meta-Llama-3-8B-Instruct", "max_tokens": 512, "temperature": 0.3 }, start_to_close_timeout=timedelta(seconds=60), # 严格超时 retry_policy=RetryPolicy( maximum_attempts=2, # LLM调用最多重试2次 non_retryable_error_types=["ValidationError"] # 格式错误不重试 ) ) # 步骤3：合规性校验（调用规则引擎） validated = await workflow.execute_activity( ComplianceCheckActivity, {"report": llm_result, "patient_id": input.patient_id}, start_to_close_timeout=timedelta(seconds=15) ) return MedicalReportOutput( summary=validated["summary"], risk_assessment=validated["risk_assessment"], next_steps=validated["next_steps"] ) # LLM调用Activity实现 @activity.defn async def LLMGenerateActivity(input: Dict) -> str: # 使用httpx异步调用vLLM OpenAI兼容API async with httpx.AsyncClient() as client: response = await client.post( "http://vllm-api:8000/v1/chat/completions", json={ "model": input["model"], "messages": [{"role": "user", "content": input["prompt"]}], "max_tokens": input["max_tokens"], "temperature": input["temperature"] }, timeout=50.0 # 客户端超时必须小于Workflow超时 ) if response.status_code != 200: raise Exception(f"LLM API error: {response.text}") return response.json()["choices"][0]["message"]["content"]关键实践心得：
- 超时必须分层设置：Activity的
start_to_close_timeout（60秒） < Workflow的execution_timeout（120秒），留出状态清理时间 - 重试策略要差异化：LLM调用重试2次足够，因为多数失败是瞬时的；而外部API调用可设3次，因其失败原因更复杂
- 错误类型要精准捕获：
non_retryable_error_types明确排除格式错误，避免无效重试
4.3 状态持久化与审计追踪
所有Workflow执行状态自动写入Temporal的Visibility Store，但我们额外构建PostgreSQL表用于业务级审计：
-- 创建任务状态表 CREATE TABLE task_execution_log ( id SERIAL PRIMARY KEY, workflow_id VARCHAR(255) NOT NULL, -- Temporal Workflow ID run_id VARCHAR(255) NOT NULL, -- Temporal Run ID task_type VARCHAR(100) NOT NULL, -- 如'medical_report' status VARCHAR(20) NOT NULL, -- PENDING/EXECUTING/COMPLETED/FAILED input_data JSONB, -- 原始输入（脱敏后） output_data JSONB, -- 输出结果（脱敏后） error_message TEXT, -- 失败时的错误详情 started_at TIMESTAMPTZ DEFAULT NOW(), completed_at TIMESTAMPTZ, duration_ms BIGINT, created_at TIMESTAMPTZ DEFAULT NOW() ); -- 创建索引加速查询 CREATE INDEX idx_task_status ON task_execution_log(status); CREATE INDEX idx_task_time ON task_execution_log(started_at); CREATE INDEX idx_task_workflow ON task_execution_log(workflow_id);审计查询示例（查某患者所有任务）：
SELECT status, EXTRACT(EPOCH FROM (completed_at - started_at)) AS duration_sec, error_message FROM task_execution_log WHERE input_data @> '{"patient_id": "PAT-2023-789"}' ORDER BY started_at DESC LIMIT 10;实操心得：不要把原始敏感数据（如患者姓名、身份证号）直接存入数据库。我们在input_data中只存脱敏后的
patient_id，真实PII数据通过Hash ID映射到独立加密存储。某次安全审计中，这套设计帮我们快速通过了GDPR合规检查。
5. 监控与可观测性：让长任务不再成为“黑盒”
5.1 四层监控指标体系
我们定义了覆盖基础设施、框架、业务、用户体验的四级监控，所有指标通过Prometheus采集，Grafana可视化：
| 层级 | 指标名称 | 计算方式 | 告警阈值 | 业务含义 |
|---|---|---|---|---|
| 基础设施 | GPU Memory Utilization | nvidia-smi --query-gpu=memory.used --format=csv,noheader,nounits | >95%持续5分钟 | 显存即将耗尽，需紧急扩容 |
| 框架层 | Temporal Workflow Latency P95 | histogram_quantile(0.95, sum(rate(temporal_workflow_execution_latency_seconds_bucket[1h])) by (le, workflow_type)) | >120秒 | 任务链整体性能劣化 |
| 业务层 | Task Success Rate | count(task_execution_log{status="COMPLETED"}) / count(task_execution_log) | <98%持续15分钟 | 业务质量跌破红线 |
| 用户层 | User Perceived Latency | 前端埋点上报的“从点击到收到结果”时间 | >30秒持续10分钟 | 用户体验已不可接受 |
特别强调业务层指标的价值：某次上线新版本后，基础设施和框架层指标全部正常，但业务成功率从99.2%缓慢跌至97.8%。通过分析task_execution_log表，发现是新增的“药物相互作用检查”子任务失败率高达42%，原因是知识库未更新最新药品说明书。若只看框架层指标，这个问题会被完全掩盖。
5.2 故障排查黄金路径
当长任务异常时，我们遵循固定的五步排查法，平均定位时间从47分钟缩短至6分钟：
- 查状态：
temporal-cli workflow list --query "Status='FAILED' and CloseTime > '2024-06-01T00:00:00Z'" - 定Workflow：取失败Workflow ID，
temporal-cli workflow describe --workflow-id <id>查看完整执行树 - 看日志：
temporal-cli workflow logs --workflow-id <id> --run-id <run_id>定位失败Activity - 验输入：从PostgreSQL查该Workflow的
input_data，确认是否含非法字符或超长文本 - 复现场景：用
temporal-cli workflow execute重放失败输入，观察是否复现
实战案例：某次大批量任务卡在WAITING_FOR_INPUT状态。按上述路径查到是前端未正确传递callback_url参数，导致编排层无法触发下一步。我们立即在API网关层增加参数校验，将此类错误拦截在入口。
5.3 日志结构化与语义搜索
传统文本日志在长任务中形同虚设。我们强制所有组件输出JSON格式日志，并注入关键上下文：
{ "timestamp": "2024-06-15T08:23:45.123Z", "service": "vllm-api", "level": "INFO", "workflow_id": "med-report-789abc", "run_id": "def456", "task_id": "lab-parse-001", "event": "llm_inference_start", "model": "Meta-Llama-3-8B-Instruct", "input_tokens": 1248, "output_tokens": 321 }关键字段说明：
workflow_id和run_id：与Temporal完全对齐，实现跨服务追踪task_id：标识当前执行的具体子任务，便于定位问题环节event：预定义事件类型，支持日志聚合分析
用Loki + Grafana实现语义搜索：
- 查所有LLM调用超时：
{job="vllm-api"} |~ "llm_inference.*timeout" - 查某Workflow所有日志：
{job="all"} | workflow_id="med-report-789abc" - 查高Token消耗任务：
{job="vllm-api"} | json | output_tokens > 500
注意：日志中严禁记录原始用户输入！我们只记录
input_tokens数量和event类型。某次安全扫描发现某开发在DEBUG日志中打印了完整病历，立即触发了紧急发布回滚。
6. 常见问题与避坑指南：那些只有踩过才懂的坑
6.1 “任务卡死”问题的七种根因与速查表
| 现象 | 可能根因 | 快速验证命令 | 解决方案 |
|---|---|---|---|
任务状态长期停留在EXECUTING | Temporal Worker离线 | temporal-cli worker list | 检查Worker Pod状态，重启或扩容 |
任务在RETRYING状态循环 | LLM API返回503但未被重试策略捕获 | kubectl logs -l app=temporal-worker | grep "503" | 在RetryPolicy中添加temporary_failure_cause_types=["503"] |
| 多个任务共享同一context导致混淆 | Redis缓存未按Workflow ID隔离 | redis-cli KEYS "context:*" | 改用PostgreSQL，以workflow_id为表分区键 |
| 任务成功但输出为空 | LLM返回空字符串未被校验 | SELECT * FROM task_execution_log WHERE output_data->>'summary' = '' | 在Activity中增加空值检查，抛出ValueError触发重试 |
| 任务执行时间忽长忽短 | GPU显存碎片化 | nvidia-smi --query-compute-apps=pid,used_memory --format=csv | 启用vLLM的--enable-prefix-caching，定期重启Worker |
| 人工介入后任务无法继续 | WAITING_FOR_INPUT状态未被监听 | temporal-cli workflow list --query "Status='WAITING_FOR_INPUT'" | 检查回调服务健康状态，确保其向Temporal发送SignalWithStart |
| 任务历史无法查询 | PostgreSQL连接池耗尽 | SELECT * FROM pg_stat_activity WHERE state = 'active' AND application_name LIKE '%llm%' | 调整pgbouncer连接池大小，从20升至100 |
6.2 关于“LLM是否属于深度学习”的工程视角澄清
热搜词里频繁出现“llm是否属于深度学习”，这在学术界有明确答案，但在工程实践中，这个问题的答案直接决定技术选型：
是深度学习：意味着必须遵循DL工程规范——模型版本管理（MLflow）、数据漂移监控（Evidently）、概念漂移检测（Alibi Detect）。我们要求所有LLM模型必须注册到MLflow，每次推理记录
model_version和input_schema，当检测到输入分布偏移>0.15时，自动触发模型重训。但又不完全是：LLM的推理过程不可微分，无法用传统梯度下降优化。因此，我们把LLM当作“黑盒函数”，其性能优化聚焦在：
- 输入预处理（Prompt Engineering）
- 输出后处理（Schema Validation）
- 调用编排（Retry Strategy）
- 资源调度（GPU Memory Management）
这种二元性导致很多团队走弯路：用PyTorch Lightning训练LLM微调脚本，却忽略vLLM的推理优化；或过度关注LoRA适配器精度，却不管Temporal的Workflow超时设置。我的建议是：把LLM当成一个需要精心伺候的“高级API”，而不是一个待调优的“神经网络”。
6.3 RAG与Long-running的协同陷阱
RAG（检索增强生成）常被当作解决LLM幻觉的银弹，但在长任务中，它可能成为新的故障点：
检索漂移：任务执行过程中，知识库更新导致后续检索结果变化。解法：在Workflow启动时，对本次任务生成知识库快照ID，所有检索请求强制带上该ID，确保全程使用同一版本知识。
检索超时雪崩：当100个任务并发检索，ES集群响应变慢，导致LLM调用超时，进而触发重试，形成恶性循环。解法：在RAG服务前加一层缓存层（Redis），对相同query+knowledge_id组合缓存结果，TTL设为1小时。
检索结果膨胀：长任务中多次检索，每次返回10个chunk，累计超200个，远超LLM上下文窗口。解法：引入检索结果蒸馏器——用轻量级模型（如MiniLM）对所有检索结果做语义聚类，每类取Top1，再送入LLM。实测在法律合同审查中，输入token减少63%，准确率反升1.2%。
我踩过的最大坑：在某政务项目中，为提升响应速度，把RAG检索和LLM生成放在同一个Activity里。结果一次ES集群抖动，导致整个Workflow超时失败。教训是：必须把RAG检索作为独立Activity，与LLM生成解耦，各自设置独立超时和重试策略。
7. 进阶实践：从可靠运行到智能进化
7.1 基于执行历史的自动优化
当系统积累足够多任务日志后，我们可以反哺优化自身。我们构建了一个轻量级优化器，每周自动执行：
超时参数优化：分析
task_execution_log中各Activity的实际执行时间分布，将P99时间作为新超时值。例如，LLMGenerateActivity历史P99为42秒，新设为45秒，避免过度保守。重试策略优化：统计各类错误码的重试成功率。发现
503错误重试2次成功率92%，而重试3次仅升至92.3%，遂将最大重试次数从3降为2，减少无效等待。资源配额优化：结合
nvidia-smi历史数据，为不同任务类型分配GPU显存。医疗报告任务设为--gpu-memory-utilization 0.7，而简单问答设为0.4，整体GPU利用率提升至81%。
7.2 人类反馈闭环（HFBC）设计
Long-running任务的价值不仅在于自动化，更在于持续进化。我们强制所有任务在完成后，向用户推送一个极简反馈按钮：“此结果对您有帮助吗？✅ ❌”。用户点击后，系统自动记录：
workflow_id+run_id- 用户反馈（1/0）
- 当前时间戳
- 设备类型（Web/App）
这些数据流入专用表，供算法团队分析。某次分析发现：在移动端，用户对“分步骤解释”的接受度比PC端高37%，于是我们调整了移动端的prompt模板，加入更多步骤编号和图标。这种基于真实场景的微调，比纯离线评测更有效。
7.3 安全边界强化：NSFW内容的工程化防御
热搜词中出现“支持 nsfw llm 有那些？”，这提醒我们必须正视内容安全。我们的防御是三层的：
输入层过滤：用FastText训练轻量级分类器，对用户输入实时打分，NSFW概率>0.8时，直接返回预设安全响应，不调用LLM。
输出层过滤：LLM输出后，用Rule-based + ML双校验。Rule部分匹配敏感词库（动态更新），ML部分用RoBERTa微调模型判断整体倾向性。
审计层兜底：所有输出存入PostgreSQL时，自动触发异步扫描，发现NSFW内容立即告警，并冻结该Workflow ID的后续执行。
这套组合拳在某社交平台内容审核系统中，将漏检率控制在0.02%以内，且平均延迟增加<150ms。
我在实际部署中最大的体会是：Long-running LLM任务不是技术挑战，而是工程哲学的践行——它逼着你把模糊的“智能”拆解成可测量、可追踪、可回滚的确定性步骤。当你的第一个医疗报告任务在凌晨三点稳定生成第1000份结果时，那种踏实感，远胜于在排行榜上刷出0.1%的指标提升。最后分享一个小技巧：每次上线新任务类型前，先用Temporal的Workflow Replay功能，拿100条历史数据做离线重放，不启动任何真实服务，纯验证状态机逻辑。这一步能提前发现80%的流程设计缺陷，省下无数深夜救火的时间。
