生产环境中的 LLM 工作流：实现可靠智能体执行的实战蓝图

核心要点

• 生产级 LLM 工作流不是“一个提示词加一个模型”，而是由上下文组装、模型推理、工具控制、审批和可观测性组成的运行时系统。
• 与其让一个智能体在检索、规划和执行之间自由 improvisation，不如把工作流拆成更窄的步骤，这通常更能提升可靠性。
• 上线后的首批重大问题，往往不只是模型问题，而是工作流问题：上下文过多、工具暴露过宽、回退路径薄弱、以及缺乏追踪信息。
• 最有用的架构模式往往刻意“无聊”：拿到一个小型证据包，在其上推理，检查策略，执行一个受限动作，然后记录整次运行。
• 当工作流可靠性依赖于一种可复用、受治理的上下文层，并且这层上下文需要在多个智能体、工具和人工复核步骤之间保持一致时，puppyone 最能发挥作用。

什么才算生产环境里的 LLM 工作流

大多数团队起步时的心智模型都很简单：

• 用户输入
• LLM 调用
• 返回答案

这对原型足够，但对生产环境不够。

一旦 LLM 工作流触达真实运营，新的问题会立刻冒出来：

• 证据从哪里来？
• 模型在这个步骤里能调用哪些工具？
• 什么时候工作流应该停下来请求审批？
• 如果检索到的内容不完整或互相冲突，会怎样？
• 一次坏运行发生后，如何事后重建？

这就是为什么一旦越过 demo，“工作流”会比“提示词”更重要。Anthropic 在其关于 AI 智能体有效上下文工程 的工程笔记中也提出了类似观点：上下文是有限的，工具边界很重要，长时间运行的智能体需要显式整理，而不是不断把更多内容堆进提示词。

在实践里，生产级 LLM 工作流，就是模型之外那整套控制面。

这张蓝图的核心：先分职责，再谈优化

最安全的默认做法，是给不同的工作流层分配不同职责。

这种结构看起来刻意不炫技。

但好的生产系统通常就是“清晰的系统”。它把一个庞大、神秘的“智能体循环”替换成几个操作员能够理解和推理的显式边界。

执行契约比“聪明程度”更重要

提升可靠性最快的方法之一，是不要再把每个步骤都当成自由格式的散文生成。

一个工作流步骤应该返回一个可预测的包裹结构，而不是一段写得很漂亮的惊喜文本：

{
  "step": "draft_refund_decision",
  "status": "needs_approval",
  "confidence": 0.73,
  "evidence": [
    {"source": "policy-14", "quote": "Refunds allowed within 14 days for unused credits."},
    {"source": "order-8821", "quote": "Purchase date: 2026-03-25"}
  ],
  "proposed_action": {
    "type": "approve_refund",
    "target_id": "order-8821"
  },
  "reason": "Policy appears satisfied but account history includes one prior manual exception."
}

这种契约会同时带来三个好处：

1. 它强迫工作流把“证据”和“动作”分开
2. 它给下游策略检查一个可确定解析的对象
3. 它让失败运行在事后更容易回放和评估

如果一个人工审核者看不清模型看到了什么、得出了什么结论、以及它下一步准备做什么，那这个工作流还不算生产就绪。

可靠的智能体执行，始于上下文纪律

生产环境里最大的错误，依然是给模型塞太多原材料。

更好的模式是：

1. 检索最小可用证据包
2. 把它压缩成面向单一步骤的上下文
3. 只让模型做这一步的工作
4. 向后传递结构化结果，而不是整个对话转录

这听起来很显然，但很多系统做的恰恰相反。它们把搜索结果、历史消息、工具输出和策略片段全丢进一个上下文窗口里，然后希望模型自己找到正确线索。

这种做法会以可预测的方式失败：

• 关键信号被稀释
• 精确的策略语言被埋没
• 模型开始混淆不同案件的证据
• token 成本上升，但答案质量下降

Anthropic 关于紧凑上下文整理的建议在这里非常相关。OpenTelemetry 关于 traces 的文档则解释了旁边那一层可观测性问题：如果一个工作流跨越多个决策和工具，你需要的是一串可追踪的 spans，而不是一个黑盒式的“LLM 步骤”。

工具范围应该跟着步骤变化

很多团队谈论工具调用时，仿佛一个智能体只有两种状态：“有工具”或“没工具”。对生产环境来说，这种划分太粗了。

更好的问题是：

在这个具体步骤里，为了这个具体目的，应该开放哪一个工具？

例如：

• 摘要步骤不需要写权限
• 规划步骤通常不需要破坏性动作
• 策略审查步骤可能需要只读访问证据和规则，但不需要触发外部副作用
• 执行步骤可能只需要一个窄范围的变更工具，而且要建立在前面的检查已经通过之后

如果每一步都能看到完整工具目录，模型就得先花 token 判断“到底什么是安全可调的”。更糟的是，操作员会被迫相信提示词措辞，而不是相信系统边界。

一个实用的步骤范围划分规则可以是：

这不是过度设计，而是防止一次检索错误直接演变成系统变更的关键。

在追求自治之前，先建检查点

另一个可靠模式，是在工作流变得昂贵或危险之前插入检查点。

常见触发条件包括：

• 置信度低于阈值
• 证据互相矛盾
• 涉及策略敏感动作
• 上下文包异常庞大
• 同一步骤重复重试

很多所谓“智能体”系统，就是在这里重新赢回可信度的。模型依然有用，但它不需要在工作流已经进入模糊区时，硬装出一副很确定的样子。

NIST 的 AI 风险管理框架 在这里是个很好的锚点。信任问题不只是输出质量，更是治理、可复核性，以及人是否能在正确的时机介入。

你最先会遇到的生产故障

这些问题通常会在真实使用的头几周出现：

注意，这里面几乎没有哪个问题是靠“换一个更强模型”就能解决的。

模型质量当然重要，但生产可靠性的第一批明显提升，往往来自工作流结构，而不是换前沿模型。

puppyone 在这张蓝图里的位置

当工作流的难点不在于“生成文本”本身，而在于反复、稳定且安全地组装正确上下文时，puppyone 才是关键。

这通常体现在：

• 同一组证据要在多个工作流步骤之间反复复用
• 多个智能体或操作员需要共享同一事实源
• 检索质量依赖于受治理、结构化的企业知识
• 审核者需要 provenance、稳定标识，以及更干净的运行重建能力

在这些情况下，模型不应该每一轮都重新去猜企业上下文。上下文层应该把证据塑形一次，再把它稳定地分发给不同步骤、不同智能体，或者人工审核节点。

这比不断给原始文档堆更长的提示词，更适合生产环境。

一条更理性的上线顺序

如果你正在把一个已有的 LLM 工作流推向生产，最高杠杆的顺序通常是：

1. 把工作流明确映射成若干步骤
2. 定义每一步允许看到什么上下文
3. 收窄每一步的工具面
4. 为真正有风险的地方加一个审批检查点
5. 强制结构化输出 envelope
6. 在扩张自治能力之前，先补好 traces 和评估

不要从“让智能体更自治”开始。

先从“让工作流更容易解释”开始。

这种心态通常会产生一种系统：第一周不那么惊艳，但第三个月更容易活下来。

FAQs

Q1. 什么让一个 LLM 工作流算“生产级”，而不只是 demo？

生产级工作流需要显式的上下文边界、按步骤收窄的工具、必要时的回退行为、审批规则，以及足够的日志去重建发生了什么。Demo 可以靠直觉，生产环境不行。

Q2. 每个 LLM 工作流都应该变成完全自治的智能体吗？

不应该。很多工作流更适合做成“辅助式”或“带检查点”的系统。完全自治是一种设计选择，不是成熟度证明。

Q3. 升级一个现有 LLM 工作流可靠性的最快办法是什么？

通常是先把上下文组装与模型推理分开，再减少每一步可用的工具数量。这种改动往往能同时改善质量、成本和可复核性。