agent-">从技能图谱到工程落地：Agent工作流开发全景解析

一、为什么需要工作流：从单次调用到多步骤协作

大模型应用的第一阶段往往是“单点问答”：一次输入、一次输出，逻辑封闭、边界清晰。但当任务变成“检索资料—分析约束—生成方案—校验结果—必要时回退重试”这样的多阶段过程时，单次调用就暴露出三个根本问题：状态无法在步骤间传递、分支与循环难以表达、失败后无法局部恢复。

Agent 工作流的本质，是把一个复杂任务拆解为若干可独立描述、可独立观测的节点，并用明确的控制流把它们连接起来。这样做的收益不只是“能跑通”，更在于工程上的可维护性：每个节点可以单独测试、单独替换、单独监控；整条链路的行为可以被追踪和回放。

从能力分布上看，工作流编排能力在整体技能需求中占比约 11.2%，技能封装与复用约 11.0%，面向交付的工程化方向约 4.5%，遗留系统改造约 5.0%，数学与原理基础约 7.6%，面向特定场景的智能体实践约 6.4%。这组比例说明一个事实：编排与技能抽象是主体，而数学基础与工程化是支撑，场景实践是验证。下文按这个优先级依次展开。

二、图结构编排：工作流的核心抽象

2.1 节点、边与共享状态

把工作流建模为有向图是最通用的做法。节点代表一个执行单元（一次模型调用、一次工具调用、一段确定性计算），边代表控制流，全局共享一个状态对象在各节点间传递。节点读取状态、写入状态，边根据状态决定下一步走向。

# 示意性伪代码：图结构工作流的最小骨架
state = {"query": "", "docs": [], "draft": "", "retries": 0}
def retrieve(state):      # 检索节点
    state["docs"] = search(state["query"])
    return state
def generate(state):      # 生成节点
    state["draft"] = llm(state["query"], state["docs"])
    return state
def validate(state):      # 校验节点
    return "ok" if check(state["draft"]) else "retry"
graph.add_node("retrieve", retrieve)
graph.add_node("generate", generate)
graph.add_edge("retrieve", "generate")
graph.add_conditional_edge("generate", validate,
                           {"ok": END, "retry": "retrieve"})

这段骨架体现了三个关键设计：状态是显式的，任何节点都能看到完整上下文；分支是声明式的，由条件函数而非散落的 if-else 决定走向；回退是结构化的，重试不是异常处理，而是图中的一条边。

2.2 为什么图优于链式调用

线性链式调用的致命弱点是“只能前进”。一旦中间步骤质量不达标，只能整体重跑，成本和延迟都被放大。图结构允许环、允许汇合、允许并行分支，因此可以表达“校验不通过则回到上游”“多个子任务并行后聚合”“根据意图分流到不同子流程”等真实业务形态。这是工作流从演示走向生产的分水岭。

2.3 状态的粒度与持久化

状态设计要克制：只放跨节点真正需要共享的数据，避免把整段原始输入反复搬运。对于长流程，还需要考虑检查点机制——在每个节点执行后持久化状态快照，使流程可以中断续跑、可以从任意历史点回放调试。这在人工审核介入的场景中尤其重要：流程暂停等待人工确认，确认后从检查点继续。

三、技能封装：把能力变成可复用单元

3.1 技能的定义边界

“技能”（Skill）应当是一个内聚的能力单元：有明确的输入契约、明确的输出契约、明确的失败语义。它可以是纯函数式的确定性计算，也可以是一次带工具调用的模型推理，但对外表现必须一致——调用方不需要知道内部是模型还是规则。

封装技能时最容易犯的错误是“把提示词当技能”。提示词是技能的实现细节，不是接口。接口应该是“给定结构化输入，返回结构化输出或明确错误”，这样技能才能被测试、被替换、被不同流程复用。

3.2 技能的注册与发现

当技能数量增长到几十个，必须有注册机制：统一的元数据描述（名称、用途、输入输出模式、适用场景），让编排层可以按语义选择技能，而不是在代码里硬编码调用。这一步做好了，才能支撑后续的自动规划类应用；做不好，工作流就会退化成一大堆难以维护的硬连接。

3.3 失败语义与降级

技能必须显式区分三类失败：可重试失败（超时、限流）、不可重试失败（输入非法、权限不足）、部分成功（返回了结果但置信度低）。编排层据此决定重试、跳过还是转人工。缺少这层语义，整条链路就只能“一错全停”。

四、面向交付的工程化：从原型到生产

4.1 可观测性先行

工作流的调试成本远高于单次调用，因此可观测性不是可选项。至少需要三类信息：每个节点的输入输出快照、每个节点的耗时与资源消耗、整条链路的调用树。有了调用树，才能定位“是检索召回差还是生成阶段跑偏”。日志、指标、链路追踪这三件套在智能体场景里同样适用，只是追踪的对象从服务调用变成了节点执行。

4.2 评估体系的建立

生产级应用必须有离线评估集：一批带标准答案或评判标准的样本，覆盖主流程与典型边界。每次修改提示词、替换模型、调整编排逻辑，都先跑评估集再上线。评估指标应分层：节点级（检索命中率、生成合规率）与链路级（端到端成功率、平均重试次数）。没有评估集的工作流迭代，本质上是在盲改。

4.3 成本与延迟控制

多步骤流程的成本是乘性的。控制手段包括：在简单节点使用小模型、对可缓存的中间结果做缓存、对并行分支设置并发上限、为整条链路设置总预算与超时。编排层应当把“预算”作为一等公民，允许在预算耗尽时优雅降级而不是硬性失败。

五、遗留系统改造：让老项目接入智能能力

存量系统接入智能能力，风险不在模型，而在边界。改造时应遵循“包一层、不侵入”的原则：在原有业务逻辑之外增加一个适配层，把老接口包装成技能，由工作流编排调用；老系统本身的行为保持不变，出问题时可以随时摘掉适配层回退到原路径。

具体落地可分三步：第一步，选一条低风险、高频次的业务链路做试点，例如查询类或摘要类任务；第二步，为适配层补齐输入校验与输出兜底，确保模型输出异常时不影响主业务；第三步，建立灰度与回滚机制，按流量比例逐步放开。改造的目标不是“用上大模型”，而是“在可回滚的前提下提升特定环节的效率”。

六、数学基础：理解能力的来源与边界

数学基础在技能图谱中占比约 7.6%，它不是要求人人推导公式，而是要求建立对模型行为的正确预期。向量空间与相似度度量解释了检索为何有效、为何在语义漂移时失效；概率分布与采样参数解释了生成的随机性从何而来、温度如何影响稳定性；损失与优化的基本概念解释了为什么微调需要数据质量而非数据数量。

这些认知直接指导工程决策：知道相似度度量的局限，就不会盲目相信召回结果；知道采样机制，就不会在需要确定性的节点使用高随机性配置；知道评估的统计性质，就会为评估集设置置信区间而非只看单点数值。

七、场景实践：把上述能力串起来

一个典型的多步骤实践是“资料处理助手”：接收问题后先做意图识别分流；检索类问题走“检索—重排—生成—引用校验”子图；计算类问题走“参数抽取—工具调用—结果格式化”子图；两条子图共享同一套技能注册表与同一份状态检查点。上线后通过调用树定位瓶颈，通过评估集验证每次调整，通过预算控制约束成本。

这条链路把编排、技能封装、工程化、数学认知四部分能力全部用上，也解释了为什么各项能力在技能图谱中呈现这样的比例：编排与技能是骨架，工程化是保障，数学是判断力，场景是检验场。缺任何一环，系统都只能停留在演示阶段。

八、小结

Agent 工作流的专业性不在于用了多少新概念，而在于是否把“状态、控制流、契约、可观测、可评估、可回滚”这几件事做扎实。图结构提供了表达力，技能封装提供了复用性，工程化提供了交付保障，数学基础提供了判断力。按这个顺序投入，才能让智能体应用从能跑变成能维护、能扩展、能放心上线。