02——从 Prompt 到 Workflow

从 Prompt 到 Workflow：把"会说"变成"会做"的 Agent 应用开发方法

开篇：为什么你的 Prompt 一到线上就失灵

很多团队会经历同一种挫败：

在测试环境里，Prompt 看起来很好
一上线，多轮任务就开始跑偏
输出格式频繁异常，工具调用失败
每改一次 Prompt，就引入新的副作用

根因通常不是"模型不够聪明"，而是：

你在用"单轮问答思维"解决"多步骤任务问题"。

Prompt 可以提升一次回答质量，但不能替代流程控制 。

当任务涉及检索、判断、执行、校验、回退时，必须进入 Workflow 设计。

一、先定义边界：Prompt 负责表达，Workflow 负责执行

1.1 Prompt 的职责

明确任务目标与角色边界
约束输出格式
提供必要上下文
降低回答歧义

1.2 Workflow 的职责

控制任务步骤与分支
管理外部工具调用
处理超时、重试、失败补偿
保证最终结果可追踪、可回放

一句话：

Prompt 解决"怎么说"，Workflow 解决"怎么做"。

二、Agent 开发中的三种常见编排模式

2.1 Chain（线性链）

适合步骤固定的任务，如：

文档解析 -> 摘要 -> 结构化输出
用户问题 -> 检索 -> 生成答案

优点：简单稳定，易观测

缺点：灵活性有限，无法应对复杂分支

2.2 Router（路由分发）

适合多任务类型入口，如：

售后问题分流（退款、物流、投诉）
企业助手分流（制度问答、IT 支持、审批查询）

优点：扩展性好

缺点：路由错误会放大下游错误

2.3 Planner + Executor（规划执行）

适合复杂开放任务，如：

"帮我做本周销售复盘并给改进建议"
"分析这批工单并输出可执行优化项"

优点：复杂任务表现好

缺点：成本高、控制难、调试复杂

工程建议：

能用 Chain 不上 Planner；能用 Router 不写复杂自由流程。

先求稳，再求"智能感"。

三、一个生产可用的最小 Workflow 架构

是
否
用户请求
输入预处理/安全过滤
任务路由 Router
上下文构建: Prompt + Memory + RAG
LLM推理
是否调用工具
Tool Executor
结果校验
输出结构化
策略审查/降级兜底
响应返回
日志与评估回流

这个流程体现了两条原则：

每一步都可失败、可重试、可观测
任何"自由生成"都要被"结构化约束"收口

四、Prompt 工程化：不要再用"字符串拼接"

4.1 错误方式：Prompt 分散在代码各处

python 复制代码

def ask(q):
    prompt = "你是客服专家，回答：" + q
    return llm(prompt)

问题：

版本不可追踪
改动不可回归
输出约束弱

4.2 推荐方式：模板化 + 参数化 + 版本化

python 复制代码

PROMPT_V3 = """
你是企业客服Agent。
任务目标：
1) 判断用户意图
2) 生成结构化响应

输出必须是JSON：
{
  "intent": "...",
  "answer": "...",
  "need_tool": true/false,
  "tool_name": "..."
}

用户输入：
{user_input}

知识片段：
{knowledge}
"""

def build_prompt(user_input: str, knowledge: str) -> str:
    return PROMPT_V3.format(user_input=user_input, knowledge=knowledge)

继续升级建议：

Prompt 存在独立配置中心
每次更新带版本号和变更说明
关键场景做回归集测试

五、输出结构化：稳定性的第一道门

如果你让模型"自由回答"，你就把下游系统暴露给随机性。

生产系统必须结构化输出。

5.1 推荐：Schema 驱动解析

python 复制代码

from pydantic import BaseModel, ValidationError
from typing import Optional

class AgentResult(BaseModel):
    intent: str
    answer: str
    confidence: float
    need_tool: bool
    tool_name: Optional[str] = None

def parse_result(raw: str) -> AgentResult:
    try:
        return AgentResult.model_validate_json(raw)
    except ValidationError:
        raise ValueError("模型输出不符合协议，触发降级")

5.2 结构化失败怎么办

不要无限重试。

推荐策略：

重试 1 次（附带更强格式约束）
仍失败则降级为固定模板响应
记录样本进入评估池

六、Router 设计：分类正确率决定全链路质量

路由是很多 Agent 系统的"隐形瓶颈"。

一旦第一步分错，下游越努力越错。

6.1 Router 的最小实现策略

先规则路由（高置信业务关键词）
再模型路由（模糊场景）
最后兜底路由（转人工或通用答复）

是
否
是
否
用户问题
规则命中?
固定路由
LLM路由判定
置信度足够?
对应工作流
兜底流程/人工

6.2 Router 评估指标

路由准确率（Top-1）
高风险意图召回率
低置信请求占比
兜底触发率

七、Tool Calling：真正让 Agent"做事"的关键层

没有工具调用，Agent 本质还是"文本生成器"。

有了工具调用，Agent 才能执行真实业务动作。

7.1 工具调用的 5 个工程约束

白名单：只能调用授权工具
参数校验：类型、范围、必填项
超时机制：避免单工具拖垮链路
幂等保障：重复调用不产生副作用
审计日志：记录谁、何时、调用了什么

7.2 错误示例：无约束工具执行

python 复制代码

tool_name = result["tool_name"]
params = result["params"]
return tools[tool_name](**params)  # 无校验、无权限、无超时

7.3 推荐示例：安全执行器

python 复制代码

def call_tool_safely(user_id: str, tool_name: str, params: dict):
    if tool_name not in TOOL_WHITELIST:
        raise PermissionError("tool not allowed")
    validate_params(tool_name, params)
    with timeout(3):
        resp = invoke_with_retry(tool_name, params, retries=1)
    write_audit_log(user_id, tool_name, params, resp)
    return resp

八、状态管理：多轮任务不设计状态，必然失控

Agent 的多轮交互常见两类状态：

会话状态：当前任务进度、已确认参数、上一步结果
业务状态：订单状态、审批状态、库存状态等

工程原则：

会话状态短期存储，设置 TTL
业务状态以系统真实数据为准，不信模型"记忆"
所有关键状态转移要可追踪

九、从 Demo 到生产：你需要的 4 类降级策略

9.1 模型降级

主模型超时 -> 切小模型
小模型仍失败 -> 固定模板答复

9.2 工具降级

工具失败 -> 返回解释 + 引导人工
高风险工具失败 -> 强制中止，不猜结果

9.3 路由降级

低置信意图 -> 通用流程 + 引导补充信息

9.4 输出降级

JSON 解析失败 -> 二次修复提示
二次失败 -> 统一错误协议返回

核心思想：

让失败"可预期"，比追求每次都完美更重要。

十、评估闭环：Workflow 不评估，就无法优化

建议最小评估面板包含以下指标：

任务完成率
工具调用成功率
输出结构化通过率
平均时延（P50/P95）
单请求 Token 成本
兜底触发率

线上请求日志
失败样本池
人工标注
评估集更新
Prompt/Workflow改版
回归测试
灰度发布

这就是 Agent 项目的"持续进化飞轮"。

十一、常见反模式（强烈建议避开）

把 Agent 当万能入口：什么都接，结果什么都不稳
所有任务都上 Planner：复杂度暴涨，收益不成比例
只调 Prompt 不做数据回流：问题反复出现
没有协议化输出：每次升级都可能破坏下游
没有人工兜底：线上体验风险不可控

十二、上线 Checklist（可直接复制到项目）

任务定义

已定义明确输入、输出、边界
已列出不可执行场景与兜底策略

Prompt 与 Workflow

Prompt 模板版本化管理
Workflow 图谱清晰，有状态转移说明
关键节点有超时、重试、降级

Tool Calling

工具白名单与权限校验已启用
参数校验与幂等策略已实现
调用日志可审计

质量与运维

评估集和回归测试可执行
关键指标接入监控告警
灰度发布与快速回滚已验证

结语

Prompt 很重要，但它只是 Agent 系统里的"语言接口"。

真正决定你能否交付生产价值的，是 Workflow 设计能力。

大模型应用开发的分水岭，不是"谁写的 Prompt 更花哨"，

而是"谁能把任务编排成稳定可控的执行系统"。

下一篇预告

下一篇进入最核心实战环节：

《RAG 实战：检索质量决定 Agent 上限》

我们会完整讲透：

文档切分怎么做才不丢语义
为什么召回率高仍然答不好
重排、引用、可信答案链路如何落地