这门课不再铺开讲全套智能体知识，而是让客户在两小时内完成一次 业务痛点到 Agent 方案 的转换。
讲师只保留必要概念：Agent 是一段业务责任的 AI 执行单元，Workflow 是稳定执行路径，Skill 是可复用能力块。所有解释都回到采购预算预审这一个案例。
从客户头疼点开始
先问“哪一步慢、错、反复切系统”，不要先问“要不要建智能体”。
把现状流程画出来
只画客户能核对的内容：谁做、在哪做、输入是什么、输出给谁。
标出 AI 可接手的活动
把查询、比对、摘要、草稿生成圈出来，再讨论 Agent / Workflow / Skill。
再拆 Agent、Workflow 和 Skill
Agent 看责任边界，Workflow 看稳定路径，Skill 看能否独立测试。
用最小验证收尾
最后落到样本、指标、人工复核和失败回退，客户才能继续推进。
CASE OPENING
贯穿案例：采购预算预审
整场只用这一条案例讲透：财务预审采购单为什么慢，哪些动作交给 AI，怎么画 Agent、Workflow、Skill、集成入口和验收表。
财务每次预审要切 3 个系统，意见还不稳定
采购员在 OA 提交申请；财务要查预算余额、历史采购价、供应商风险，再把判断写回 OA。客户听到这里，就能立刻看到痛点不是“缺一个聊天机器人”，而是流程中有一组重复判断动作。
在 OA 侧边栏嵌入“采购预算预审 Agent”
目标不是承诺全自动审批，而是在 OA 单据页给财务一份可复核的预审结果：预算依据、历史价依据、供应商风险和建议话术。
现状流程：人工在系统之间搬运上下文
这张图保留原课件的主线：先从现状流程找 AI 活动块。课堂中让客户直接指出“查、比、写、转人工”四类节点。
案例判断卡
应建几个 Agent？
课堂答案：先建 1 个“采购预算预审 Agent”。它只服务采购预审这一段责任，不扩展成万能财务助手。
要不要 Workflow？
要。提交、读取、并行查询、条件分支、写回和转人工都是稳定路径，适合画成 Workflow。
应建几个 Skill？
先拆 4 个：读取采购单、预算校验、历史价比对、供应商风险摘要。意见草案由 Agent 汇总生成即可。
接到哪里？
优先接 OA 采购单页侧边栏。结果要贴近财务正在处理的单据，不让客户另开一个孤立聊天入口。
OPERATING METHOD
两小时方法：从痛点到可汇报方案的 8 个动作
保留原来的 8 步骨架，但讲法收敛：每一步只回答一个客户能判断的问题，最后形成一套可继续开需求会的材料。
不要这样推进
先问“我们要不要建一个 Agent？”然后马上进入工具演示。
客户会听懂名词，但不知道这个东西替代哪一步、接在哪里、谁来验收。
要这样推进
先把“财务预审慢”定位到具体流程活动，再决定 Agent、Workflow 和 Skill。
客户最后拿到的是一张方案图和一组验收表，而不是一堆概念定义。
AGENT BOUNDARY
什么时候拆 Agent：看流程断点，不看系统数量
这里保留一个最小概念：Agent 不是“聊天框”，而是一段清楚业务责任的 AI 执行单元。课堂只讲一个判断：断点变了，就考虑拆。
Agent 拆分决策树
这张树是客户现场最重要的一张判断图：不按系统数量拆，按人工断点、责任边界、上下文和权限拆。
人 AI 人：通常拆开讲
人工确认会改变责任和上下文。客户只要记住：中间需要人拍板，就不要硬塞进一个 Agent。
人 AI AI 人：连续相关就合并
预算、历史价、风险都服务同一份预审意见，中间没有人工断点，所以先合成一个采购预审 Agent。
连续但无数据依赖：可以拆
只是排在一起，不代表同一责任。输入输出、验收人不同，就拆成不同能力。
跨系统：先别急着拆
采购预审跨 OA、预算、采购、供应商系统，但责任仍是一段预审，所以跨系统本身不是拆分理由。
课堂演示：创建“采购预算预审 Agent”
这一段保留为课堂演示，不展开平台菜单细节。讲师只演示三个动作：命名 Agent、绑定已发布 Flow、用一张采购单测试是否调用正确。
先定责任
名称就叫“采购预算预审 Agent”。它只负责预审，不负责制度咨询、供应商建档、预算调整。
再绑定 Flow
把“采购预算预审 Flow”作为可调用能力，并写清何时调用、需要什么输入、返回什么字段。
最后做测试
输入“帮我预审 CG-2026-001”，看它是否调用 Flow，而不是靠自由发挥编一个结论。
| 配置动作 | 在斑头雁里要填什么 | 采购案例示例 | 完成标准 |
|---|---|---|---|
| 1. 新建智能体 | 左侧选择 Agent，点击新建 Agent，填写名称、业务角色、适用场景，避免命名成泛泛的“AI 助手”。 | 名称：采购预算预审 Agent；角色：辅助财务完成采购单预审。 | 一眼能看出它负责哪段业务，不负责什么。 |
| 2. 写系统提示词 | 写清任务目标、输入要求、何时调用 Flow、输出格式、异常处理。 | 当用户提供采购单编号时，调用采购预算预审 Flow；返回结论、依据、建议话术。 | 同一输入多次测试，输出结构稳定。 |
| 3. 绑定可调用能力 | 在技能里添加已发布的“采购预算预审 Flow”，并补齐技能说明书。 | 技能描述：用于对采购单进行预算、历史价、供应商风险预审；输入 purchase_order_id。 | 智能体能找到正确 Flow，而不是靠自由发挥回答。 |
| 4. 写技能说明书 | 说明这个 Flow 什么时候用、输入参数是什么、返回字段各代表什么。 | 当用户要求“预审/校验/看这张采购单能不能过”时调用；不要用于预算调整。 | Agent 能把用户自然语言转成 Flow 入参。 |
| 5. 配知识库 | 只绑定与判断口径相关的规则、制度、模板，不放实时业务流水。 | 采购制度、预算审批规则、供应商风险等级解释。 | 回答依据能回到制度规则，且不会混入无关知识。 |
| 6. 做一次对话测试 | 输入一张采购单编号，检查是否调用 Flow，是否输出结构化预审结论。 | 输入：请预审 CG-2026-001。输出：结论、预算依据、价格依据、风险依据、建议话术。 | 能完成一次端到端调用；失败时能说明失败节点。 |
WORKFLOW AS EXECUTION FORM
Workflow 不是 Agent 的附属品，而是一种执行形态
这里只讲一句话：Workflow 是可重复执行的路径。它可以独立运行，也可以被 Agent 调用；客户要画清触发器、节点、分支、异常和写回。
Agent、Workflow、Skill 的关系图
这张关系图保留原课件逻辑，但改成客户判断用：稳定路径画 Workflow，灵活入口交给 Agent，单点能力沉淀 Skill。
Workflow 独立运行
适合触发明确、路径固定的事。比如 OA 采购单提交后自动跑预算预审。
Workflow 被 Agent 调用
适合用户先用自然语言表达任务。Agent 理解“帮我预审这张采购单”后，再调用同一个 Workflow。
Workflow 不等于 Skill
Skill 是一个能力块，Workflow 是一条路径。客户只需要会区分“点能力”和“整条执行线”。
Agent 不一定需要 Workflow
如果只是简单问答，不必强行画 Workflow；步骤多、分支多、要审计时才值得画。
案例：采购预算预审 Workflow 怎么画
这张图是两小时课的核心画图练习：同一个预审 Workflow，可以由 OA 提交触发，也可以由 Agent 在对话里调用。
| 构建步骤 | 要回答的问题 | 采购案例写法 | 产出物 |
|---|---|---|---|
| 1. 定触发器 | 谁启动 workflow？是用户点击、表单提交、定时任务，还是 Agent 调用？ | OA 采购单提交时自动触发；Agent 对话中也可以手动触发。 | 触发条件 + 入参 schema |
| 2. 定节点 | 哪些是系统动作，哪些是 Skill，哪些是人工节点？ | 读取采购单、预算校验、历史价比对、风险摘要、财务复核、写回 OA。 | 节点清单 |
| 3. 定数据流 | 每个节点吃什么输入，吐什么输出，下一步如何使用？ | 采购单 order_json 同时传给预算、价格、风险三个节点，汇总为 review_result。 | 输入输出字段表 |
| 4. 定分支 | 什么条件走自动通过，什么条件转人工，什么条件建议退回？ | 预算充足且风险低：写回通过；信息缺失：转财务；超预算或高风险：建议退回。 | 条件分支表 |
| 5. 定异常 | 接口失败、缺字段、规则冲突、Skill 置信度低时怎么处理？ | 任何关键节点失败都转财务复核，并记录失败节点和原因。 | 异常处理表 |
| 6. 定验收 | 如何证明 workflow 本身跑得对，而不是只看 Agent 回答是否好听？ | 30 条采购单端到端测试，检查路径选择、写回内容、人工转交是否正确。 | 路径测试用例 |
先画独立 Workflow
把采购预审画成“OA 提交即触发”的执行图，先只画触发器、节点、分支、写回，不急着画 Agent。
再画 Agent 调用 Workflow
增加一个对话入口：用户说“帮我预审这张采购单”。Agent 识别采购单编号后调用同一个 workflow，并解释结果。
最后判断是否需要 Skill
逐个节点看：能否直接接口完成？是否需要模型理解？需要模型理解的节点才沉淀成 Skill。
课堂演示：搭建“采购预算预审 Workflow”
这一段只作为演示：把图上的触发、节点、分支和输出对应到 Flow。客户课不深入讲每个菜单，只让业务方看懂建设对象。
新建 Flow
进入 Flow，新建“采购预算预审 Flow”。先配置开始节点的入参 purchase_order_id。
画节点
用 API、代码、LLM、知识检索、逻辑分支等节点，搭出读取、校验、汇总、分支、输出。
运行调试
准备通过、人工复核、建议退回三组样例，运行后查看每个节点的输入输出和命中的分支。
发布调用
调试通过后发布 Flow。它可以单次运行、批量运行、定时运行、API 调用，也可以添加到 Agent 技能里。
| 编排动作 | 在斑头雁里怎么做 | 采购案例示例 | 练习产出 |
|---|---|---|---|
| 1. 定义入口 | 在开始节点里配置入参，至少包含采购单编号；可先用单次运行模拟 OA 提交。 | input: purchase_order_id = CG-2026-001。 | 一个可手动运行的 Flow。 |
| 2. 添加读取节点 | 用 API 节点或模拟节点读取采购单，统一输出 order_json。 | order_json 包含金额、科目、供应商、申请部门、采购品类。 | 后续节点都只依赖 order_json，不反复读原始表单。 |
| 3. 添加并行校验节点 | 添加预算校验、历史价比对、供应商风险三个节点；可用 API、代码、LLM 或知识检索节点承接不同任务。 | 输出 budget_result、price_result、risk_result。 | 三个结果都能被汇总节点读取。 |
| 4. 添加条件分支 | 用逻辑分支节点根据汇总结果设置通过、人工复核、建议退回三条路径。 | 预算充足且风险低：通过；缺字段：人工复核；超预算或高风险：建议退回。 | 至少跑通三组样例，分别命中三条路径。 |
| 5. 添加输出/写回 | 把最终结果组织成财务可读格式；未接真实 OA 前可先输出到输出节点。 | 结论、依据、建议话术、失败节点、人工处理建议。 | 输出字段稳定，方便 Agent 解释或页面展示。 |
| 6. 挂给 Agent 调用 | 发布 Flow 后，在 Agent 的技能里添加这个 Flow，并填写技能说明书。 | 用户：帮我预审 CG-2026-001。Agent 调用 Flow 后解释结果。 | 同一个 Flow 既能独立运行，也能被 Agent 调用。 |
SKILL GRANULARITY
一个 Agent 里放几个 Skill：按“独立步骤”拆
Skill 用业务语言解释就是“可复用的小能力”。客户只需要记住四个判断：输入输出是否清楚、能不能复用、能不能单测、后续能不能改。
采购预算预审 Agent 的 Skill 编排
先画 Workflow，再拆 Skill。不要一上来列一堆 Skill，容易把业务路径讲散。
| 节点复杂度 | Skill 数量建议 | 采购案例落法 | 不要做什么 |
|---|---|---|---|
| 简单节点只有一个稳定动作 | 1 个 Skill | 只从 OA 读取采购单字段：申请人、金额、科目、供应商。 | 不要拆成“读取金额”“读取科目”“读取供应商”三个碎 Skill。 |
| 串行节点后一步依赖前一步 | 2 到 5 个 Skill | 读取采购单 → 预算校验 → 历史价比对 → 风险摘要 → 生成预审意见。 | 不要把所有接口调用和判断逻辑塞进一个 800 行提示词或一个巨型 Skill。 |
| 并行节点多个数据源互不依赖 | 并行 Skill + 汇总逻辑 | 预算余额、历史价格、供应商风险可以并行查询，Agent 汇总后生成意见。 | 不要为了“流程顺序好看”强行串行，造成响应变慢。 |
| 复用动作多个 Agent 都会用 | 单独沉淀 Skill | “供应商风险摘要”未来可被合同审批、付款审核、招采评审复用。 | 不要把可复用能力写死在某个 Agent 的系统提示词里。 |
KNOWLEDGE · PROMPT · WORKFLOW
知识库和提示词如何配合 Workflow
这一页只保留业务方必须懂的边界：实时数据走接口，规则制度进知识库，提示词写 Agent 的操作规程，Workflow 管稳定执行路径。
知识库：放判断依据
预算制度、采购分类规则、风险等级解释可以放进去；预算余额这类实时数据不要塞进知识库。
提示词：写操作规程
让 Agent 知道什么时候调用 Workflow、什么时候只解释规则、失败时怎么交还人工。
Workflow：管执行路径
触发器、节点、分支、写回和人工复核都放到 Workflow 里，方便复用和验收。
| 问题 | 判断 | 采购案例 |
|---|---|---|
| 要不要知识库？ | 任务是否需要规则、模板、案例、制度作为判断依据，且这些依据会更新。 | 预算余额来自接口，不进知识库；“超预算多少必须升级审批”进知识库。 |
| 提示词写什么？ | 写 Agent 如何调用 skill、如何使用知识、如何处理失败、如何输出。 | 先调用采购单读取，再并行调用预算/历史价/风险，最后输出四段式结论。 |
| 平台怎么串联执行？ | 如果平台支持 workflow，就优先把稳定路径画成 workflow；如果不支持，再用系统提示词模拟调用链和参数传递。 | 采购预审 workflow 负责 order_json 的传递和分支；Agent 负责判断何时调用它、如何解释结果。 |
SYSTEM INTEGRATION
Agent 建在哪里：跟着用户工作现场走
客户课里不讨论平台偏好，只讨论工作现场：AI 结果应该出现在用户正在处理业务对象的地方。
未来流程：在 OA 采购单页嵌入 Agent 侧边栏
这张未来流程图保持原课件画法：左侧是角色，右侧是活动，AI 活动块下面标 Skill，最后标清人工复核和系统写回。
| 集成形态 | 什么时候用 | 采购案例判断 | 风险 |
|---|---|---|---|
| 侧边栏嵌在业务单据页 | 用户正在处理某个对象，需要 AI 读取页面上下文并给出建议。 | 首选。财务在 OA 单据页直接看预审结果，无需跳转。 | 需要处理页面权限和字段读取。 |
| 操作豆腐块按钮/卡片触发 | AI 是一个明确动作，比如“生成摘要”“一键校验”。 | 可作为侧边栏里的触发按钮：重新预审、生成补充说明。 | 动作边界要很清楚，否则用户不知道何时点。 |
| 中心化对话框统一入口 | 跨流程、探索型、问答型任务。 | 不首选。采购预审是流程内动作，不应让财务另开聊天窗口。 | 容易脱离业务上下文，使用率低。 |
| 后台自动任务定时/事件触发 | 无需用户实时参与，可批处理预筛选。 | 适合夜间批量扫描待审采购单，标出高风险单据。 | 必须设计人工复核和异常通知。 |
MINIMUM VERIFICATION
验收标准要前置：先验证 Skill，再验证 Agent
两小时课不承诺一步到位上线，只让客户带走最小验证口径：先验证 Skill，再验证 Agent，始终保留人工复核和失败回退。
样本
先取 30 条真实采购单：20 条常规、5 条超预算、5 条供应商风险异常。
指标
字段读取准确率、预算判断一致率、风险摘要覆盖率、平均响应时间。
边界
缺字段、接口超时、制度规则冲突、供应商不存在时必须有明确处理。
复核
上线初期保留人工确认按钮，并记录 AI 建议是否被采纳，用于持续优化。
| 对象 | 最小测试 | 通过标准 | 失败后改哪里 |
|---|---|---|---|
| Skill 1：读取采购单 | 30 条 OA 单据，覆盖不同采购类型和字段缺失情况。 | 金额、科目、供应商、申请部门字段提取准确率达到业务约定阈值。 | 字段映射、接口参数、输出 JSON schema。 |
| Skill 2：预算校验 | 20 条预算充足、5 条不足、5 条需升级审批。 | 与财务人工判断保持一致；不确定时必须返回“需人工确认”。 | 预算规则知识库、科目映射、判断阈值。 |
| Skill 3：历史价比对 | 同类物资历史价格、不同供应商价格、无历史价格三类样本。 | 能输出“高于/低于历史均值”的依据，不把无可比数据误判为异常。 | 同类物资匹配规则、历史窗口、异常阈值。 |
| Agent：预审结果 | 端到端跑 30 条采购单，财务复核并标注采纳/修改/拒绝。 | 结果结构稳定，财务能在 1 分钟内判断是否采纳；异常不阻塞流程。 | 系统提示词、Skill 调用顺序、输出模板、异常策略。 |
FACILITATOR BACKUP
讲师备查：依据与适用边界
这部分从主讲内容降级为备查页。客户现场只讲结论和边界，遇到质疑时再展开平台依据，避免两小时课被文档细节拖住。
| 关键观点 | 性质 | 依据与边界 |
|---|---|---|
| Agent 可以基于指令、上下文和工具执行任务 | 已验证 | OpenAI Agents SDK 将 Agent 描述为配置了 instructions、tools、guardrails、handoffs 等能力的模型；Dify 也把 Agent 描述为可推理、可拆解任务、可自主调用工具的系统。 OpenAI Agents SDK · Dify Agent |
| Workflow 可以独立运行，也可以被 Agent 调用 | 已验证 | 斑头雁 BetterYeah Flow 文档说明 Flow 可作为 Agent 技能、独立运行、批量运行、定时运行和 API 调用；Google Cloud Workflows 支持通过控制台、API、客户端库、gcloud 等方式执行；Microsoft Copilot Studio 的 agent flows 可手动、事件、计划或由 agent 触发，并可作为工具添加给 agent。 BetterYeah Flow · Google Cloud Workflows · Copilot Studio agent flows |
| Workflow 适合表达固定步骤、条件分支、系统动作和人工节点 | 已验证 | 斑头雁 Flow 文档列出开始、LLM、知识库查询、代码、API、逻辑分支、Flow 等节点；AWS Step Functions 明确定义 Choice 条件分支；Google Cloud Workflows 支持等待回调，用于人工确认等交互。 BetterYeah Flow 节点 · AWS Choice state · Google callbacks |
| Skill 是被 Agent 或 Workflow 调用的能力单元 | 概念映射，需按平台命名调整 | 不同平台未必叫 Skill，常见名称包括 tool、action、plugin、function、connector。OpenAI 文档将 tools 描述为模型可用来获取上下文或执行动作的能力；本课件用 Skill 作为业务方容易理解的统一称呼。 OpenAI tools |
| 知识库适合放制度、模板、案例、规则；实时数据更适合走系统接口 | 前半部分已验证，后半部分是落地建议 | OpenAI File Search 和 Dify Knowledge 都支持从文档/知识源中检索上下文；但“实时系统数据走接口、规则文档进知识库”是为了减少过期数据和权限混淆的工程建议。 OpenAI File Search · Dify Knowledge |
| 有人工断点、责任边界变化时倾向拆 Agent | 规划建议 | 这是面向业务梳理和权限治理的拆分准则，不是某个平台的硬性规则。实际要结合权限、审计、成本、上下文长度、用户入口和平台编排能力再定。 |
| Skill 按可独立输入输出、可复用、可测试、可维护拆分 | 规划建议 | 这是软件工程的模块化思路在 AI 能力建设里的应用。平台不会强制这么拆，但这样更便于复用、单测、排错和灰度上线。 |
| 优先把 AI 入口放在用户工作现场，例如单据页侧边栏 | 体验设计建议 | 这是基于“贴近任务上下文、减少跳转”的交互建议，不是技术事实。若业务是跨流程咨询或探索型问答，中心化对话入口也可能更合适。 |
2-HOUR LEARNING PATH
两小时实战路径：从案例判断到方案沉淀
这是重新整理后的客户课节奏。每 15 到 20 分钟都有一个看得见的产出，避免课程停留在概念讲解。
120 分钟课堂路线图
这张图用于开场对齐预期：前 30 分钟只讲必要概念，后 90 分钟全部围绕采购预算预审画方案。
0-15 分钟：案例定位
用采购预算预审现状图确认痛点：慢在哪里、错在哪里、哪几步在搬运上下文。
15-30 分钟：必要概念
只解释 Agent、Workflow、Skill 三个词，知识库、提示词、验收只给业务边界。
30-50 分钟：拆 Agent
用决策树判断人工断点、责任边界、上下文和权限，得出 1 个采购预算预审 Agent。
50-70 分钟：画 Workflow
画出触发器、读取节点、并行查询、条件分支、异常处理和写回路径。
70-88 分钟：拆 Skill
把读取采购单、预算校验、历史价比对、供应商风险摘要拆成可测试能力块。
88-103 分钟：知识库与提示词
判断哪些是接口实时数据，哪些是制度规则；提示词只写调用规则和失败交还。
103-115 分钟：集成与验收
确定 OA 侧边栏入口、人工复核动作、30 条样本和最小通过标准。
115-120 分钟：交付确认
收齐现状流程表、Agent 定义卡、Workflow 图、Skill 清单和最小验证表。
WORKSHEETS
AI 能力规划的 5 个交付物
两小时结束时，客户必须带走能继续推进的材料，而不是只说“听懂了 Agent”。下面 5 个交付物就是课程收口。
现状流程表
角色、活动、系统、输入、输出、耗时、错误点、是否可 AI 化。用于把“很麻烦”落到具体流程节点。
Agent 定义卡
Agent 名称、业务责任、触发条件、人工断点、可调用 Workflow / Skill、权限、输出结果和验收指标。
Workflow 编排图
触发器、节点、数据流、条件分支、人工复核、异常处理、系统写回，并标清独立运行还是被 Agent 调用。
Skill 定义卡
Skill 名称、输入字段、输出 schema、依赖系统/知识、成功条件、失败处理、可复用场景、测试样本。
最小验证表
样本来源、样本数量、常规/异常比例、通过口径、人工复核人、上线门槛和失败回退策略。
业务访谈开场问题
请按下面格式说清楚一个真实业务痛点： 1. 现在谁在做这件事？ 2. 在哪个系统里做？ 3. 每次输入是什么，输出是什么？ 4. 最慢、最容易错、最烦的具体动作是哪一步？ 5. 这一步如果由 AI 辅助，业务人员最后要看到什么结果？ 6. 结果错了会造成什么业务风险？
Agent 系统提示词：调用 Workflow
你是“采购预算预审 Agent”。当用户要求预审采购单时： 1. 先识别采购单编号和用户意图。 2. 如果用户是在咨询规则，只回答规则并引用知识库。 3. 如果用户要求执行预审，调用【采购预算预审 Workflow】。 4. Workflow 返回 review_result 后，结合知识库中的采购制度和风险等级解释，输出： - 结论：通过 / 需补充 / 建议退回 / 需人工确认 - 依据：预算、历史价、供应商风险三类证据 - 建议话术：给财务复制到 OA 的 80 字以内意见 如果 Workflow 任一节点失败，不要编造结果；标明失败节点、失败原因、建议人工处理方式。
Agent / Workflow / Skill 拆分判断
请基于我提供的流程节点，判断 Agent、Workflow 和 Skill 的规划： 1. 先列出所有可 AI 化活动； 2. 按人工断点把 AI 活动分组； 3. 对每组判断是否连续执行、是否共享上下文、是否同一业务责任、是否同一权限边界； 4. 给出建议 Agent 数量和名称； 5. 判断哪些执行路径适合做成 Workflow，并说明它是独立运行，还是被 Agent 调用； 6. 对每个 Workflow 节点，判断是系统接口、人工节点，还是需要沉淀成 Skill； 7. 说明每个 Skill 的输入、输出、依赖系统、是否需要知识库； 8. 最后给出最小验证样本和验收标准。