Agentic Workflow Designer

From messy manual processes to autonomous AI pipelines — design, document, and deploy.

⚠️ CAPABILITY NOTICE / 能力说明

• Type: Design and advisory framework — produces workflow blueprints, JSON/YAML specs, and ROI estimates as reference material
• No code is executed by this skill; generated specs are for the user to review and import into their own environment
• No persistent storage, network calls, background execution, or credential collection
• All outputs require human review before production deployment
• Workflows touching PII or regulated data must include retention, access control, and audit considerations

What This Skill Does

Agentic AI (AI that can autonomously execute multi-step tasks) is the #1 enterprise tech trend in 2026 with a projected $8.5B market and 40% CAGR. Yet most teams struggle to:

• Map which workflows are actually suitable for agentic automation
• Design reliable pipelines that don't break silently
• Choose between n8n, Make, Zapier, or custom agent frameworks
• Justify the ROI to business stakeholders

This skill bridges the gap between AI hype and practical workflow automation:

• Workflow Discovery — Identify and prioritize automation opportunities in any business process
• Agentic Pipeline Design — Create detailed workflow blueprints with triggers, agents, tools, and fallbacks
• Platform Selection — Compare n8n / Make / Zapier / custom LangGraph for your use case
• Generate Workflow Specs — Produce JSON/YAML specs importable into n8n or Make
• ROI Calculator — Estimate time/cost savings from automation
• Human-in-the-Loop (HITL) Design — Design appropriate checkpoints for sensitive decisions

Trigger Words

Agentic workflow, automate my process, workflow automation, n8n, Make automation, Zapier flow, design a workflow, workflow design, process automation, automate with AI, AI pipeline, autonomous workflow, HITL pattern, 工作流设计, 自动化工作流, 流程自动化, 智能体工作流, 帮我设计流程, 自动化这个流程, n8n工作流, 企业自动化, RPA替代, agentic AI pipeline

Target Users

• Operations managers digitizing manual business processes
• Developers building production AI automation systems
• Product managers scoping automation features
• Consultants delivering workflow automation projects
• Entrepreneurs building AI-native products

Workflow

平台与技术动态（截至 2026-09-24）

2026-08 更新要点：

• MCP 成为事实标准：Model Context Protocol 于 2025 年底转入 Linux 基金会中立治理后，2026 年官方与社区服务器数量持续扩张，企业内部 MCP 注册表逐步成为新的基础设施层。
• 国内合规要求趋严：涉及个人信息与重要数据的工作流，需满足最小必要采集、境内存储与可审计要求，自托管方案的优先级上升。
• 长上下文成本下探：长文档场景（招股书、年报、长合同）的单位 Token 成本持续下降，使得"全文入参 + 结构化抽取"逐步替代早期分段检索方案。
• 可观测性成为刚需：生产级 agentic 工作流普遍补齐链路追踪、成本归因与失败重放能力，缺乏可观测性的方案难以通过投产评审。
• [2026-09 新增] 从"能不能跑"转向"能不能管"：试点期关注功能实现，规模化后真正的瓶颈变成命名规范、版本管理、灰度发布与故障定位，设计阶段就要预留这些能力。
• [2026-09 新增] 选型标准从跑分转向可控性：受监管行业（金融、医疗、政务）更看重私线部署、数据不出境与审计留痕，模型跑分高不再是唯一决策依据。
• [2026-09 新增] 成本归因细化到工作流：单位 Token 成本需要能分摊到具体工作流与具体节点，否则规模化后无法判断哪些流程值得继续投入。
• [2026-09-24 新增] 智能体身份与权限被单独治理：工作流里的 agent 逐步被当作"非人类身份"管理，需要独立的凭据、最小权限与回收机制，共用一把管理员 Key 的做法在审计中难以通过。
• [2026-09-24 新增] 评测集先于优化：团队在实践中发现，没有评测集就做提示词调优等于盲调；先用 30-100 条真实样本建最小评测集，再谈优化，成为投产前的默认动作。
• [2026-09-24 新增] 失败重放成为交付标准：无法复现失败现场的工作流在验收时被直接打回，输入、输出、版本、耗时、成本五项留痕被视为最低要求。

本期新增观察（截至 2026-09-24）

| 维度 | 变化 | 对流程设计的意义 | 落地动作 | 可信度标注 | |------|------|----------------| | 治理 | 企业内部 MCP 注册表从"可选"变为"基础件"，工具接入需统一登记与权限控制 | 设计时把工具来源收敛到注册表，避免各流程各接一套 | 建立工具清单与负责人，禁止流程内硬编码凭据 | 以官方最新发布为准 | | 运维 | 工作流数量增长后，命名与版本混乱成为主要故障源 | 约定命名规范与语义化版本，变更需留 changelog | 采用"业务域-动作-对象-版本"命名，变更走评审 | 以官方最新发布为准 | | 成本 | 成本归因要求下沉到节点级 | 每个节点标注预期调用量与成本上限，超限告警 | 为高成本节点设单日预算与熔断 | 以官方最新发布为准 | | 合规 | 涉及个人信息与重要数据的流程需满足最小必要与可审计 | 在蓝图阶段即标注数据分类与留存期限 | 数据分类标签前置到 Step 1 盘点表 | 以官方最新发布为准 | | 身份 | agent 作为"非人类身份"需独立凭据与最小权限 | 共用管理员凭据的做法不可审计 | 一个工作流一套凭据，定期轮换与回收 | 以官方最新发布为准 | | 评测 | 最小评测集成为投产前置条件 | 没有评测集就调优等于盲调 | 先建 30-100 条真实样本的最小评测集 | 以官方最新发布为准 |

Step 2 新增技术评估（2026）：

• LangGraph v1.0生产就绪：状态机工作流/长期记忆/错误恢复三大核心能力，企业级部署支持Kubernetes自动扩缩容，GitHub Stars突破85K
• CrewAI v1.10多智能体协作：支持6种角色类型+并行任务编排，内置20+企业级连接器（Slack/Notion/Airtable/GitHub），2026年Q1新增中文文档
• Claude Agent SDK / OpenAI Agents SDK横向对比：工具调用准确率(94% vs 91%)/上下文利用率(78% vs 82%)/成本效率(￥0.8/千Token vs ￥1.2/千Token)三大维度全面评测
• MCP(Model Context Protocol)生态爆发：50+官方服务器覆盖GitHub/Slack/Notion/Postgres等，企业内部MCP注册表成为新基础设施
• LLM长上下文之战：Gemini 2M Token / Claude 200K / GPT-4o 128K技术选型指南，针对金融长文档(招股书/年报)场景给出最优性价比方案

Step 1 — Process Discovery

Ask the user to describe their current workflow:

• What triggers it? (email, schedule, webhook, human action?)
• What are the key steps? (list them in plain language)
• Who (or what system) does each step today?
• Where do errors/delays typically occur?
• What's the desired output/outcome?

示例：报销流程的 Step 1 拆解（访谈 → 结构化盘点）

访谈关键问题（用于发现隐性规则）

• 哪些步骤你会凭经验"感觉不对"？——这一步通常隐含未写明的规则。
• 上一次出错是怎么发现的？——说明现有校验缺口在哪。
• 哪些步骤你会跳过或补做？——说明流程设计与实际执行脱节。
• 拆解结论：6 个子步骤中 4 步可自动化、2 步（超标准判断、领导审批）必须保留人工，与后续 Step 2 打分结论一致。

Step 2 — Automation Suitability Assessment

Score the workflow across 5 dimensions:

| Dimension | Score | 判断依据 | 打分示例（周报自动化） | 打分示例（客户投诉处理） | 低分时的拆解建议 | |-----------|-------|---------|---------------------|----------------------| | Repetitiveness | /10 | How often does this run identically? | 9（每周一次，步骤固定） | 4（内容差异大） | 拆出"固定格式部分"单独自动化 | | Rule-based | /10 | Are decisions clear-cut or judgment-based? | 8（汇总规则明确） | 3（需人工判断责任与情绪） | 把判断拆为"分类"与"处置"两步，只自动化分类 | | Data availability | /10 | Is input data structured and accessible? | 8（5 张表结构固定） | 5（邮件正文非结构化） | 增加"结构化抽取"前置节点后再评 | | Error tolerance | /10 | Can errors be caught and recovered automatically? | 7（数字错误可在复核环节发现） | 4（误判会直接损害客户关系） | 增加复核节点与灰度放行，提升容错后再评 | | Stakes | /10 (inverted) | Low-stakes = easier to automate | 8（内部参考，出错影响小） | 2（涉及对外承诺与赔偿） | 高风险部分保留人工，低风险子环节单独评分 | | Automation Score | /50 | >35 = High priority, 20–35 = Medium, <20 = Keep manual | 40/50 → 高优先级 | 18/50 → 暂不自动化 |

评分补充说明

• Stakes 为反向计分：风险越高得分越低。涉及资金、对外承诺、数据删除的流程，即使前四项得分高，总分也会被拉低。
• 两例对照的意义：周报自动化 40 分应直接推进；客户投诉处理 18 分不宜整体自动化，但可拆出"分类 + 路由"子环节单独自动化（该子环节约 32 分）。
• 拆解法：整体分数偏低时，不要放弃，而是把流程拆到子步骤重新评分——大多数流程都存在可自动化的局部环节。

Step 3 — Agentic Pipeline Design

Generate a detailed pipeline blueprint:

[Workflow]: [Name]
[Trigger]: [webhook / cron / event / manual]
[Agents]:
  ├── Agent 1 [Role]: [Tool 1, Tool 2] → Output: [description]
  ├── Agent 2 [Role]: [Tool 3] → Output: [description]
  └── Agent 3 [Role]: [Tool 4, Tool 5] → Output: [description]
[Flow]: Sequential / Parallel / Conditional
[Memory]: [ephemeral / Redis / vector DB]
[Error Handling]: [retry / fallback agent / human escalation]
[HITL Checkpoints]: [list high-stakes decision points]
[Output]: [final deliverable description]

Example — Lead Qualification Pipeline:

[Workflow]: B2B Lead Qualification & Outreach
[Trigger]: New form submission webhook
[Agents]:
  ├── Enrichment Agent [Clearbit + LinkedIn scraper] → Company profile JSON
  ├── Scoring Agent [GPT-4o] → Lead score (0-100) + reasoning
  ├── Decision Gate [Human] → Approve for outreach? (HITL)
  └── Outreach Agent [Email API + CRM API] → Personalized email + CRM update
[Flow]: Sequential with HITL gate
[Memory]: PostgreSQL (lead history)
[Error]: Retry enrichment 3x → flag for manual review
[HITL]: Score > 80 auto-approves; 50-80 requires human review; <50 auto-rejects
[Output]: CRM updated + email queued

Example — 保险理赔单据预审 Pipeline:

[Workflow]: 理赔单据完整性预审
[Trigger]: 理赔系统上传事件（webhook）
[Agents]:
  ├── 分类 Agent [OCR + 规则表] → 单据类型与置信度
  ├── 校验 Agent [规则引擎] → 缺失项清单
  ├── 决策门 [规则 + 人工] → 通过 / 退回补件 / 转人工
  └── 通知 Agent [短信 API + 工单 API] → 补件提醒 + 工单创建
[Flow]: 先并行分类，后串行校验（Conditional）
[Memory]: PostgreSQL（单据状态机），不含原始影像
[Error]: OCR 置信度 < 0.85 → 强制转人工，不自动退回
[HITL]: 涉及拒赔、金额调整、个人信息变更的一律转人工；仅限"是否缺件"自动判定
[Output]: 预审结论 + 缺失项清单 + 工单号

示例 — 监管报送数据校验 Pipeline（2026-09-24 新增）：

[Workflow]: 报送数据口径校验与差错清单生成
[Trigger]: 每日定时任务（cron，T+1 凌晨）
[Agents]:
  ├── 抽取 Agent [SQL + 文件解析] → 原始报送数据集
  ├── 校验 Agent [规则库] → 差错项清单（含记录定位）
  ├── 归因 Agent [LLM] → 差错原因归类与整改建议
  └── 决策门 [人工] → 确认差错清单与整改责任人
[Flow]: 串行，校验后可并行归因
[Memory]: 仅保存差错摘要与规则版本，不落原始明细
[Error]: 规则库版本未对齐即中止，禁止带疑点报送
[HITL]: 任何涉及数据修改的动作必须人工确认；仅"生成差错清单"可自动
[Output]: 差错清单 + 归因建议 + 待确认事项

三个示例的设计差异对比（2026-09-24 新增）：

判断口诀的延伸：自动化可以覆盖判断过程，但不应覆盖责任归属；对于受监管流程， 还要再加一句——可以自动生成结论，但不能自动生成对外口径。

• Lead Qualification 属低风险、可容忍误判场景，因此允许 80 分以上自动放行。
• 理赔预审属受监管、不可自动决策场景，自动化边界严格限定在"完整性检查"，任何影响客户权益的结论必须人工确认。
• 判断依据：自动化可以覆盖判断过程，但不应覆盖责任归属。

Step 4 — Platform Recommendation

| Platform | Best For | Agent Support | Self-host | Price | 学习曲线 | 典型用例 | 主要风险 | HITL 实现成本 | |----------|----------|--------------|-----------|-------|---------|---------|---------| | n8n | Technical teams, complex logic | [Yes] via AI nodes | [Yes] | Free/OSS | 较陡 | 内部数据同步、单据预审、带审批的批处理 | 自托管需自行承担运维与升级 | 中（加等待节点 + 外部审批表） | | Make (Integromat) | Non-technical, API integrations | Partial | [No] | ~$9+/mo | 平缓 | 跨 SaaS 数据流转、市场活动自动化 | 国内访问海外 SaaS 稳定性差 | 中（需外挂审批存储） | | Zapier | Simple triggers, non-technical | Partial | [No] | ~$20+/mo | 最平缓 | 表单→通知、 CRM 字段回写 | 任务量上去后成本增长快 | 中高（复杂审批链难维护） | | LangGraph (custom) | Complex state machines, production | [Yes] Native | [Yes] | Dev hours | 陡（需开发） | 长时间运行的对话式业务、需要中断恢复的流程 | 需自建可观测与灰度能力 | 低（原生 interrupt） | | CrewAI | Role-based agent teams | [Yes] Native | [Yes] | Dev hours | 中等 | 研究分析、多角色报告生成 | 角色编排调试成本较高 | 中（需自行实现中断与恢复） |

Step 4.5 — 2026平台详细对比表（生产选型参考）

选型建议（2026）：

• 国内团队/数据合规要求 → n8n自托管（数据不出境，支持国产LLM接入）
• 海外业务/非技术团队 → Make（1000+连接器，学习成本低）
• 简单场景/销售团队 → Zapier（即开即用，但长期成本高）
• 复杂AI管线/生产部署 → LangGraph（状态持久化，支持Human-in-the-Loop）
• 多角色协作/研究分析 → CrewAI（角色分工清晰，2026年中文文档完善）

Step 5 — n8n Workflow JSON Spec (Sample Output)

{
  "name": "Lead Qualification Pipeline",
  "nodes": [
    {
      "name": "Webhook Trigger",
      "type": "n8n-nodes-base.webhook",
      "parameters": { "path": "lead-inbound" }
    },
    {
      "name": "Enrich Lead",
      "type": "@n8n/n8n-nodes-langchain.agent",
      "parameters": {
        "promptType": "define",
        "text": "Enrich this lead data using Clearbit: {{ $json.email }}"
      }
    },
    {
      "name": "Score Lead",
      "type": "@n8n/n8n-nodes-langchain.openAi",
      "parameters": {
        "resource": "text",
        "operation": "message",
        "modelId": "gpt-4o",
        "messages": { "values": [{ "content": "Score this lead 0-100..." }] }
      }
    }
  ]
}

Step 6 — ROI Calculator

ROI 计算注意事项

• 只计入真实节省的时间：若节省的时间并未转化为其他产出（例如员工只是多了空闲），不宜直接折算为现金收益，应改为"释放工时"表述。
• 必须计入运维成本：工作流会因接口变更、页面改版而失效，建议按初始搭建成本的 15%-25%/年 计入维护。
• 隐性收益单独列示：如响应时效提升、差错率下降，可用定性描述补充，不要强行货币化。
• 示例 2（客服工单分类路由）：单次从 4 分钟降至 30 秒，日均 300 单 → 每日节省约 17.5 小时；但因需保留人工复核，净节省按 60% 折算更稳妥。

可观测性与灰度发布 / Observability & Rollout（2026-09-24 新增）

最小可观测指标集（投产前必须能回答）

灰度发布四步

1. 影子运行：只跑不落结论，输出与现状对照，验证差异率；
2. 小流量放行：选低风险子集（如内部部门）先行，人工 100% 复核；
3. 阈值收紧再放开：先用高阈值只放行最有把握的部分，逐步下调；
4. 随时可回滚：保留手动开关与旧流程，回滚时间目标明确（示例：10 分钟内）。

灰度期间必须保留新旧双轨对照，否则无法判断自动化是否真的带来改善。

常见设计反模式 / Anti-Patterns

| 反模式 | 症状 | 后果 | 修正方式 | 早期检测信号 | |-------|------|------|---------| | 一步全自动 | 把含判断与担责的环节也交给模型自动放行 | 出错后责任无法归属，监管与客户均不可接受 | 拆出"可自动化的判断"与"必须人工的决策"，中间设 HITL 闸口 | 流程图上找不到任何人工节点 | | 提示词即流程 | 用一段超长提示词描述整个业务流程 | 无法定位失败节点，改动一处影响全局 | 拆成多节点，每节点单一职责并单独可测 | 单个提示词超过一屏，且无人能说清中间态 | | 无置信度阈值 | 模型输出直接落库 | 低置信结果被当成确定结论 | 设阈值：高置信自动、中置信人工复核、低置信拒绝并提示 | 数据库里没有置信度字段 | | 静默重试 | 失败后自动重试到成功为止 | 掩盖系统性故障，成本失控 | 限制重试次数，超过即告警并保留失败现场 | 成功率长期 100% 但成本持续上升 | | 不留痕 | 不记录模型输入输出 | 事后无法复盘，合规检查无法举证 | 全链路留痕，含输入、输出、版本、耗时、成本 | 出问题时无法回答"当时模型看到了什么" | | 成本无上限 | 没有单次运行的成本约束 | 异常输入导致费用暴涨 | 设单次与单日成本上限，超限熔断 | 无法说出单条流程的月度成本 |

判断口诀：自动化可以覆盖判断过程，但不应覆盖责任归属；可以加速执行，但不应消除证据。

Example Interactions

User: "I spend 3 hours every Monday pulling sales data from 5 spreadsheets, writing a summary email, and updating our CRM. Can this be automated?"

Skill response: Scores the workflow (42/50 — High priority), designs a 4-agent pipeline (data collector → analyzer → email writer → CRM updater), recommends n8n as the platform (self-hostable, native AI nodes), generates a complete n8n JSON spec, and estimates 11.5 hours/month saved = ~$580 value at $50/hr.

User: "I want to build a customer support triage system that reads emails, classifies them, and routes to the right team."

Skill response: Designs a HITL-enabled pipeline with email reading, classification, confidence threshold (>85% auto-route, <85% human review), CRM ticket creation, and Slack notification. Recommends LangGraph for its state persistence and human review interrupt capability.

User: "我们的报销单据要先核对发票真伪、再查预算、最后领导审批，能不能全自动？"

Skill response: 先按五维打分——重复性 9、规则明确 7、数据可得 6、错误容忍 4、风险（反向）3，合计 29/50 属中等。给出结论：不宜全自动。建议拆为两段：发票真伪校验与预算占用查询可自动化（该子流程约 36 分），领导审批必须保留人工节点。技术上推荐 n8n 自托管（涉及财务数据与发票信息，数据不出境），并明确指出自动化边界应止于"为审批人提供核对结论"，不得代替审批签字。

User: "我有一份 200 页的年报，想自动抽取关键财务指标并生成摘要。"

Skill response: 评估后指出这是长上下文单文档处理场景，不是典型的多步骤工作流，无需引入 agent 编排。给出两条路径：① 长上下文模型全文入参 + 结构化抽取（实现快、成本可控，适合一次性或低频任务）；② 分段检索 + 抽取（适合高频批量）。提示关键风险：抽取结果必须保留原文定位（页码/段落），便于人工复核，避免模型生成的数字无法追溯。若涉及未公开信息，须先确认数据合规与使用授权。

User: "我们有 40 多个自动化流程了，现在最大的问题是不知道哪个挂了、哪个最烧钱，怎么治理？"

Skill response: 先指出这是规模化运维问题，不是设计问题，不要靠重写流程解决。给出三步治理：① 建立流程清单与命名规范（业务域-动作-对象-版本），并为每条流程标注负责人与成本上限；② 补可观测性——链路追踪 + 节点级成本归因 + 失败重放，优先覆盖资金相关与客户可见的流程；③ 建立分级告警与熔断，按"是否涉及资金/对外承诺"分级。提示关键取舍：治理投入应集中在高影响流程，不要 40 条流程平均用力；同时建议对长期无人使用、且无合规要求的流程做下线评估。

保存与外发前确认 / Save & Send Confirmation（2026-09-24 新增）

1. 工作流蓝图、JSON/YAML 规格、ROI 测算先在对话中完整展示，供用户逐段预览；
2. 用户明确确认后再写入文件或导入生产环境；未经确认不落盘、不导入；
3. 规格文件中不得包含真实凭据，凭据一律用环境变量占位符表示；
4. 落盘时一并记录：生成时间、平台版本、适用环境、审核人。

变更记录 / Changelog

Notes & Constraints

• Always design HITL checkpoints for: financial decisions, customer communications, data deletions, external API calls with side effects
• For regulated industries (finance, healthcare, insurance): flag compliance requirements
• Workflows involving PII must include data retention and access control considerations
• Recommend starting with a pilot workflow (lowest risk, highest frequency) before scaling
• Provide rollback strategies: every agentic workflow should have a manual fallback

GitHub: https://github.com/gechengling/agentic-workflow-designer