Workflow

这套 skills 是什么 Matt Pocock（Total TypeScript / aihero.dev 作者）公开了一套面向 AI 编码的 Agent Skills 集合，本质是一组 SKILL.md 文件，把「从想法到上线」的工程流程拆成若干可被 Agent 按需加载的步骤。它不是某个 IDE 插件，而是一批可以装进 Claude Code（或其他支持 skill 的 harness）的流程说明。 装好之后目录大致是这样：~/.claude/skills/ 下一批软链接指向实际的 skill 仓库；setup-matt-pocock-skills 是每个仓库跑一次的前置配置（约定 issue tracker、triage 标签、文档布局）；ask-matt 是一个路由 skill，用来在记不清该用哪个流程时反查。 主流水线：idea → ship 大部分工作走这一条线： grill-with-docs：用连续追问把模糊的想法逼清楚，过程沉淀进 CONTEXT.md 和 ADR。没有工作目录时用 grill-me（无状态版）。 如果有些问题必须靠能跑的代码才能回答（状态、业务逻辑、要看的 UI），绕道 prototype 写一份一次性代码，用 handoff 在会话之间传递结论。 多会话构建：to-spec 把对话变成 spec，to-tickets 拆成一批 tracer-bullet ticket，每个声明自己的阻塞边；然后逐个 implement，ticket 之间清空上下文。单会话能做完就直接 implement。 implement 内部驱动 tdd（一次一个红-绿切片），收尾跑 code-review（Standards + Spec 两轴审查）再提交。 匝道和支线：bug 和请求堆积走 triage；线上出问题走 diagnosing-bugs（坚持先有一个已经变红的命令再谈修复）；大到一个会话装不下的模糊工程走 wayfinder（先画决策地图，产出决策而非交付物，再汇入 to-spec）。 ...

什么是 LangGraph LangGraph 是 LangChain 生态系统中的一个框架，专门用于构建有状态的、多步骤的 AI 应用程序。它通过图（Graph）的方式来定义和管理复杂的 AI 工作流，让开发者能够创建具有循环、条件分支和持久化状态的智能体系统。 LangGraph 的核心理念是将 AI 应用程序建模为状态机，其中节点代表操作步骤，边代表流程控制，状态在节点之间传递和更新。 核心概念 State（状态） State 是在整个工作流中传递和更新的数据结构。通常使用 TypedDict 定义： from typing import TypedDict, Annotated from langgraph.graph import add_messages class AgentState(TypedDict): messages: Annotated[list, add_messages] user_input: str analysis_result: str Node（节点） Node 是执行具体操作的函数，接收当前状态并返回更新后的状态： def research_node(state: AgentState): # 执行研究任务 result = do_research(state['user_input']) return { "analysis_result": result, "messages": [("assistant", f"研究完成：{result}")] } Edge（边） Edge 定义节点之间的连接关系： Normal Edge（普通边）：直接连接两个节点 Conditional Edge（条件边）：根据状态决定下一个节点 from langgraph.graph import StateGraph, END # 普通边 workflow.add_edge("node_a", "node_b") # 条件边 def should_continue(state): if state['done']: return END return "continue_node" workflow.add_conditional_edges( "decision_node", should_continue ) Graph（图） Graph 是完整的工作流定义，包含所有节点、边和状态管理： from langgraph.graph import StateGraph workflow = StateGraph(AgentState) # 添加节点 workflow.add_node("research", research_node) workflow.add_node("analyze", analyze_node) workflow.add_node("respond", respond_node) # 定义边 workflow.add_edge("research", "analyze") workflow.add_edge("analyze", "respond") # 设置入口点 workflow.set_entry_point("research") # 编译图 app = workflow.compile() 核心特性 1. 状态持久化 LangGraph 支持状态的持久化存储，可以实现： ...

什么是工作流引擎 工作流引擎（Workflow Engine / Process Engine）是一种用于定义、执行和管理业务流程的中间件。它把业务逻辑从代码中剥离出来，用流程图（或规则配置）来描述"下一步该做什么、由谁来做、满足什么条件才能流转"，从而让业务流程可配置、可追踪、可审计。 典型应用场景： 审批流：请假、报销、合同会签 订单流转：下单 → 支付 → 发货 → 收货 → 售后 任务编排：复杂的多步骤业务处理链路 规则驱动的路由决策 主流引擎一览 工作流引擎大致分两类： BPMN 流程引擎：遵循 BPMN 2.0 标准，配套可视化设计器，偏重人工审批、流程管理 轻量规则流引擎：不依赖 BPMN，以组件编排为核心，更适合纯代码驱动的业务链路 jBPM 官网：https://jbpm.org 仓库：https://github.com/kiegroup/jbpm jBPM 是 Java 工作流引擎的"鼻祖"，由 Red Hat（JBoss）维护，历史最悠久。 特点： 与 Drools（规则引擎）深度集成，适合流程 + 规则组合的场景 提供 KIE Workbench 可视化管理平台 技术栈较重，学习曲线陡峭 社区活跃度不如 Flowable，国内使用较少 适用场景： 已有 Red Hat/JBoss 技术栈，或需要流程与 Drools 规则引擎联动。 Activiti 官网：https://www.activiti.org 仓库：https://github.com/Activiti/Activiti Activiti 是国内使用最广泛的开源 BPMN 流程引擎，诞生于 2010 年，由 Alfresco 公司主导，核心开发者来自 jBPM。 ...