项目线 C 多步骤业务工作流 Agent

这条项目线是整套指南里最能体现“Agent 工程化能力”的综合案例。它不只要求你会调模型、会接工具，还要求你能把一个真实业务流程拆解成节点、定义状态流转、设计失败补偿、接入人工审批，并最终把整个系统做成一个可评测、可观测、可上线的业务工作流。

1. 项目定位

1.1 项目目标

做一个面向业务任务的多步骤工作流 Agent，例如：

• 运营活动复盘生成与任务拆解。
• 客诉处理流转与回复建议。
• 销售线索初筛、摘要与跟进建议。
• 内部需求受理、分类、补充信息和分派建议。

项目重点不是“回答一个问题”，而是把一个本来需要多人、多系统、多轮沟通才能完成的流程，重构成一个可追踪、可协作、可恢复的 Agent 工作流。

1.2 为什么它是高价值项目线

这条项目线能覆盖大量工程能力：

• 任务拆解与节点设计。
• 多工具协作与状态传递。
• 人工审批与回退机制。
• 评测与发布门禁。
• 可观测性、监控和回滚。
• 项目叙事、作品集和面试表达。

如果前两条项目线更多体现“问答能力”和“执行能力”，这条项目线则更体现“系统设计能力”。

2. 推荐场景选择

建议选择一个满足以下特征的业务流程：

• 有明显阶段性步骤。
• 有一部分可自动化，一部分必须人工决策。
• 有清晰输入输出。
• 结果可量化评估。
• 失败后需要恢复或补偿。

一个很适合展示的例子是： “用户提交一个运营活动复盘需求，系统自动收集资料、生成总结、抽取问题、提出行动建议、拆解待办，并在关键节点等待运营负责人确认。”

3. 推荐能力地图

这条项目线重点覆盖：

• Workflow 编排。
• Multi-Agent 或多角色分工。
• Tool Calling。
• Eval 与质量门禁。
• Observability 与 tracing。
• Security 与权限边界。
• Human-in-the-Loop。
• Production readiness。

4. 一套推荐的系统架构

可以按以下层级设计：

• 前端任务工作台：创建任务、查看步骤、审批节点、查看结果与日志。
• 编排层：负责流程节点调度、状态流转、重试、补偿和超时控制。
• Agent 层：负责理解任务、规划步骤、生成中间结果、做节点决策。
• 工具层：文档读取、知识检索、数据查询、通知发送、任务系统写入等工具。
• 状态层：任务状态、节点状态、审批状态、失败分类、补偿记录。
• 观测层：trace、日志、指标、告警、人工干预记录。

主链路可以理解为：

1. 用户创建任务。
2. 系统拆解成多个节点。
3. 每个节点根据状态执行对应动作。
4. 高风险或低置信度节点等待人工确认。
5. 最终结果汇总并生成可交付产物。
6. 全流程被记录、可回放、可评测。

5. 一个推荐的节点拆分示例

以“运营活动复盘助手”为例，可以拆成：

• 节点 1：读取输入材料与目标说明。
• 节点 2：补全背景信息与关键数据。
• 节点 3：生成复盘摘要。
• 节点 4：识别问题与根因。
• 节点 5：提出改进建议与优先级。
• 节点 6：拆解待办并指定负责人建议。
• 节点 7：等待负责人确认。
• 节点 8：确认后写入任务系统并归档。

这样的流程既能体现智能能力，也能体现工程控制能力。

6. 实施步骤

第一步：先定义流程边界

先明确：

• 起点是什么。
• 终点是什么。
• 哪些输入是必须的。
• 哪些节点允许自动推进。
• 哪些节点必须人工介入。
• 哪些失败必须立即中止。

如果边界不清，后面流程很容易膨胀。

第二步：把流程拆成可观测节点

每个节点建议明确：

• 节点目标。
• 输入。
• 输出。
• 依赖。
• 成功条件。
• 失败条件。
• 是否可重试。
• 是否需要人工确认。

第三步：定义状态机

至少要定义这些状态：

• pending
• running
• succeeded
• failed
• waiting_human
• compensated
• cancelled

如果没有状态机，流程一复杂就会出现“看起来执行了，但不知道当前到底处在哪一步”的问题。

第四步：设计补偿与恢复

多步骤系统不可能永远成功。 你需要提前设计：

• 某个节点失败后，是重试、跳过还是回退。
• 某些已经执行的副作用是否需要补偿。
• 人工接管后如何重新进入自动流程。

第五步：加评测与发布门禁

工作流 Agent 不能只看最终结果是否“看起来不错”。 建议从以下角度评估：

• 关键节点完成率。
• 审批通过率。
• 失败恢复成功率。
• 输出结构化结果的可用率。
• 人工介入比例。

第六步：设计前端工作台

前端不应只是展示聊天记录。 建议做成任务工作台，至少包括：

• 当前任务概览。
• 当前节点状态。
• 已完成与待执行节点。
• 审批与确认入口。
• 失败原因与补偿动作。
• 输出结果与归档记录。

第七步：做观测与告警

至少要知道：

• 哪个节点最常失败。
• 哪个节点耗时最长。
• 哪些任务最常被人工接管。
• 哪一类输入最容易触发流程中断。

7. 前端工程师最能体现优势的地方

7.1 把流程做成真正可协作的界面

前端可以把复杂流程可视化，让用户和业务方知道：

• 当前走到哪里。
• 接下来要做什么。
• 需要谁确认。
• 为什么失败。

7.2 把系统状态和用户操作绑紧

例如：

• 等待审批时，前端必须准确给出审批按钮和上下文。
• 节点失败时，前端必须展示可重试还是只能转人工。
• 补偿执行后，前端必须同步展示新的状态。

7.3 把业务工作流做成作品集强叙事项目

相比一个普通聊天 Demo，这类项目更容易讲清：

• 真实业务背景。
• 系统设计深度。
• 工程治理能力。
• 你的职责与决策价值。

8. 推荐指标

建议至少追踪：

• 工作流整体完成率。
• 节点级成功率。
• 人工介入比例。
• 失败恢复成功率。
• 平均任务完成时长。
• 高风险节点审批通过率。
• 用户满意度或业务接受度。

9. 常见坑

9.1 节点拆得太粗

结果是任何问题都只能笼统地说“流程失败了”，无法定位。

9.2 节点拆得太细

结果是工作流管理成本过高，状态爆炸，调试困难。

9.3 把审批当成额外补丁

正确做法是从一开始就把人工介入设计进流程，而不是最后再补一个弹窗。

9.4 只管成功链路，不管补偿链路

工作流一旦涉及外部系统写入，补偿设计就非常关键。

9.5 只做流程图，不做评测

很多项目流程图看起来很完整，但一上线就暴露节点失败率高、人工介入过多的问题。

10. 建议的阶段性交付物

阶段 1：流程可跑通版本

交付物：

• 一个最小任务创建入口。
• 一个节点化流程定义。
• 一个基本执行链路。

阶段 2：可协作版本

交付物：

• 人工确认节点。
• 前端任务工作台。
• 节点状态展示。

阶段 3：可恢复版本

交付物：

• 重试与补偿机制。
• 失败分类。
• 节点级日志与 trace。

阶段 4：可评测与可上线版本

交付物：

• 评测样本和指标面板。
• 发布清单。
• 回滚与告警方案。

阶段 5：可投递版本

交付物：

• 作品集项目卡片。
• 业务流程图。
• 系统架构图。
• 指标与复盘报告。
• 面试讲述稿。

11. 作品集怎么讲

建议重点讲四件事：

• 业务流程原本为什么低效。
• 你如何把流程拆成节点并控制风险。
• 你如何处理人工审批、失败恢复和可观测性。
• 项目上线后如何证明它是稳定、可解释、可协作的。

12. 面试表达

你可以这样讲：

“这条项目线是我把 Agent 从问答系统升级成业务工作流系统的实践。核心不是让模型回答得更花，而是把真实任务拆成节点、定义状态机、设计人工审批和失败补偿，再通过前端任务工作台把整个流程可视化。这样系统才不仅能跑，还能在团队和业务场景里真正落地。”

---

13. 自托管部署变体

🏠 零 API 依赖版本

工作流 Agent 的多节点调用非常适合本地模型——高频调用场景下自托管成本优势显著。

技术栈替换对照

组件	云端版	自托管版
AI 节点模型	GPT-4o	Ollama + Qwen3-8B
辅助模型	GPT-4o-mini	Ollama + Qwen3-4B
状态存储	不变	不变
工作流引擎	不变	不变

自托管改造要点

1. 成本优势：工作流多节点调用，本地模型节省 90%+ API 费用
2. 延迟优化：节点间无网络往返，总延迟可降低 50%+
3. 并发限制：本地模型并发有限，高并发建议 vLLM 替代 Ollama
4. 适用场景：内部审批流程、文档处理流水线、数据清洗管道

详细部署方案参考 专题 11：自托管 AI Agent 全栈指南