先别急着写 prompt，也别一头扎进 LangChain 的文档里翻。
你卡住的地方，大概率不是模型调不好——上周我帮一个电商客服团队改工作流，他们那个 Agent 老把退货和换货逻辑搞混，查了半天才发现，Skills 的边界根本就没定义清楚，工作流里也缺了决策分支。
说到底，没理清三个问题：谁在做事？它会什么？事情怎么一步步做完？
这三个问题不拎清，后面堆再多自动化都是空中楼阁。
先搞懂三个概念：AI Agent、Skills 和工作流分别是什么
AI Agent 不是“更聪明的 ChatGPT”，它是能自己看目标、拆任务、选工具、判结果的执行单元。
比如你让它“查昨天订单异常并通知运营”，它得判断要不要调用数据库 API、要不要读 Slack 日志、要不要生成摘要——这整个闭环，就是 Agent。
Skills 是它的“标准动作库”。不是 prompt 堆砌，也不是临时写函数。
一个 Skill 必须含三样东西：SKILL.md（明确输入/输出契约）、scripts/ 下可执行的代码（比如 ）、references/ 里的业务规则快照（比如《售后 SOP v3.2》PDF）。
没有这三件套，它就只是个临时工。
工作流不是流程图，是带条件跳转的执行轨道。LangChain 的 StateGraph、LlamaIndex 的 Workflow、甚至飞书多维表格的「自动规则」，本质都在干同一件事：当 Agent 说“要查库存”，工作流决定走 Redis 缓存还是直接连 ERP，失败时切到备用通道——而不是让 Agent 自己猜。
打个比方：Agent 是厨师，Skills 是他刀工、火候、调味三项认证证书，工作流则是那张贴在灶台边的《宫保鸡丁 SOP》——油温 180℃ 才下花生，辣椒段后放，末了淋醋前必须确认糖醋比。少一样，菜就不是那个味。
个人效率场景：用 AI 工作流把「邮件回复」从半小时压缩到 5 分钟
理论说完了，得拿个具体场景下地试试。我挑了个最烦人但又绕不开的事——处理邮件。
别笑，真不是小题大做。我算过一笔（好吧，就这一次），每天平均收 40～60 封邮件，其中至少 20 封需要回复。每封读一遍、理清上下文、想措辞、检查附件、点发送，快则 5 分钟，慢的能拖到 15 分钟——格外是那种客户投诉转了好几手、抄送一串人的。一天两小时就没了。
两小时，够我写半篇技术文档了。
先拆出来三个 Skill
按上一章说的框架，先把邮件处理拆成 Agent 能用的标准动作。每个 Skill 必须有 SKILL.md 定义输入输出契约，不能靠 prompt 糊弄。
- 邮件解析 Skill：输入是 RFC 822 原始邮件字符串，输出结构化对象——发件人、收件人列表、时间戳、正文纯文本、附件清单、邮件头中的 Reply-To 和 Message-ID。坑点在于：有的邮件正文是 HTML 混文本，得先转 Markdown 再提取有效内容。我用的
email标准库 +html2text做剥离，反复测过 3 次才把签名档和自动回复标记滤干净。 - 情绪识别 Skill：输入是正文文本，输出一个情绪标签（urgent / neutral / positive / frustrated）加一个 0～1 的置信度。别指望大模型直接判——太贵也太慢。我调了一个
微调模型，本地跑推理，单封耗时不到 200ms。关键配置是max_length=512截断，超过的部分直接舍掉，反正邮件的关键情绪一般在前三段。 - 模板匹配 Skill：输入是解析后的邮件对象 + 情绪标签，输出是推荐回复模板 ID。这里不是硬编码 if-else——我维护了一个
templates/目录，每份模板是个 Jinja2 文件，SKILL.md里写死了模板选择规则：比如情绪为 frustrated 且正文含「退款」「投诉」就命中。匹配逻辑用Levenshtein距离 + 关键词权重打分，阈值 0.7 以上才自动选模板，否则丢人工队列。
这三个 Skill 各干各的事，互不耦合。后面要是换模型、改模板，只动对应的 scripts/ 目录就行，不会炸掉整条线。
工作流编排：关键在条件分支和人工节点
Skill 搭好了，但怎么串起来，是工作流的事。我用的 LangGraph 画执行图，不是画着好看——是要把「出错怎么办」「特殊情况怎么跳」写死在轨道里。
from langgraph.graph import StateGraph, END
workflow = StateGraph(MailState)
# 注册节点：每个节点调对应的 Skill
workflow.add_node("parse", mail_parse_skill)
workflow.add_node("emotion", emotion_detect_skill)
workflow.add_node("template_match", template_match_skill)
workflow.add_node("draft", draft_generation_skill)
workflow.add_node("grammar_check", grammar_check_skill)
workflow.add_node("human_review", human_review_node)
workflow.add_node("send", send_mail_skill)
# 条件分支：紧急邮件直接跳过模板匹配，走快速草拟
workflow.add_condition(
"emotion",
lambda state: "urgent" if state["emotion_label"] == "urgent" else "normal",
{
"urgent": "draft",
"normal": "template_match"
}
)
# 人工审核节点：置信度低于 0.8 时必须经人确认
workflow.add_condition(
"draft",
lambda state: "review" if state["confidence"] < 0.8 else "grammar_check",
{
"review": "human_review",
"grammar_check": "grammar_check"
}
)
workflow.set_entry_point("parse")
workflow.add_edge("human_review", "grammar_check")
workflow.add_edge("grammar_check", "send")
workflow.add_edge("send", END)注意那个 节点——它不是摆设。实际跑下来，真正需要人改的也就 15% 的邮件，主要是那些情绪标签标成了 frustrated 但实际是中性询问的误判。人工改完点一下「确认」，继续走语法检查和发送。
最开始的版本我没加这个节点，结果一封骂客户的邮件差点发出去——情绪识别把「我真的很失望」判成了 neutral，模板匹配给了个标准感谢回复。要不是测试集里抓到了，后果不敢想。
实际跑下来：5 分钟是保守说法
说 5 分钟，是因为还留了人工审核的余量。纯自动的邮件（大约 60%）从收件到发送，平均耗时 47 秒。加上人工审核的平均 2 分钟，整体在 3 分半左右。
但真正省下的不是那几分钟——是脑子。以前回完 20 封邮件，注意力基本散光了，再看代码得重新热身。现在工作流跑着，我喝着咖啡扫一眼审核列表，点几个确认就行。下午写代码的状态明显比之前好。
说实话，这玩意儿最值钱的部分不是自动化本身，是你终于不用再记那些「这个客户上次说过什么」「那个供应商的付款条款是啥」——Skill 的 references/ 目录里全存着呢。Agent 替你记住了。
下次碰到那种「一个邮件链来回 7 个人」的破事，试着拆成 Skill 试试。
小团队协作场景：搭建「周报自动生成」工作流，告别催交
上周三下午三点，我盯着飞书多维表格里 7 个空着的「本周进展」单元格发呆。不是没人写——是写了也像日记：「改了点 bug」「跟客户聊了聊」。老板要的不是流水账，是「上线了 XX 功能，DAU 拉高 12%」这种能塞进季度汇报的句子。
后来把整个流程拆成四步：拉日志 → 清洗 → 提炼 → 分发。关键不是全自动化，而是让每一步都可插拔、可调试。比如清洗环节，我们用正则 + LlamaIndex 的 NodeParser 做双保险：先用 re.sub(r'\s+', ' ', text) 把换行和多余空格压平，再交给 按标题切片——不然「需求评审」和「UI 走查」老被揉进同一段。
图表生成？别硬塞进 prompt
早期想让模型直接输出 PNG，结果要么尺寸错乱，要么数据对不上。现在改用 Python 脚本调 matplotlib.pyplot.savefig() 生成图，再存到 下，路径写进 Skill 的 references/ 目录。Agent 只需在 Markdown 模板里插一句 ，渲染时自动挂载。
渐进式披露就靠这个机制撑住：邮件正文只放摘要 + 3 个核心指标，点击「展开详情」才加载完整图表和原始日志片段——上下文不爆，人眼也不累。
那个「催交」按钮，其实是个 Skill
飞书机器人响应 /weekly remind 后，不是发群消息，而是调 ：查 字段，过滤出超 48 小时未提交者，再用 feishu_bot.send_private_message() 单聊提醒。没用任何「智能」，但比群里 @ 全员有效得多。
这玩意儿跑稳后，最意外的反馈来自测试同学：她说终于不用翻三天前的对话找「那个接口文档在哪」——所有日志里的链接、PR 编号、Jira ID 都被 提出来，塞进了全局 。
工具选型：2026 年主流 AI 工作流平台怎么挑
在人工智能的浪潮中，选择合适的 AI 工作流平台对于提高工作效率、降低技术门槛至关重要。
- Zion：一个基于 Web 的低代码平台，提供丰富 API 和可视化工具，适合非技术人员拖拽搭建 AI 工作流。
- ChatO：专注于聊天机器人开发的平台，插件和集成选项多，适合需要构建复杂聊天机器人的场景。
- LangChain + LlamaIndex：灵活但需要编程知识，适合想自己控制每一环的团队。
- 飞书多维表格自带的 AI 工作流：零成本试错，拉日志、清洗、提炼、分发几步走就能跑起来。
别只看功能清单——得看你团队最常翻车的环节在哪儿。如果每次都是上下文爆掉，LangChain 的 比任何低代码平台都管用。如果是权限混乱，飞书自带的行级权限可能更省心。
避坑指南：搭建 AI 工作流最容易翻车的三个地方
跑通一个 Agent 真的不难，难的是让它稳稳当当跑上半年不出幺蛾子。我们团队在飞书多维表格上搭 weekly report 工作流那会儿，前两周每天都得凌晨三点爬起来看告警——结果发现根本不是模型崩了，是人设先崩了。
上下文撑爆：别把 PDF 当早餐喂给 AI
有次把整份 87 页的《Q2 用户行为分析白皮书》PDF 原样丢进 context，还加了「请逐页总结」指令。结果 Llama3-70B 直接卡死在第 43 页的图表 caption 里，返回空响应。后来改用 pdfplumber 提取文字后按章节切片，每片加 metadata: {section: "3.2", page_range: "21-25"}，再配 retriever.similarity_search() 动态召回——不是所有信息都得塞进 prompt，有些该留在 references/ 里等着被查。
技能冲突：两个 Skill 同时调飞书机器人？会发两遍私信
“催交”和“补文档”两个 Skill 共享 feishu_bot.send_private_message()，没加锁也没设 priority。某天测试同学收到三条一模一样的提醒，最后发现是并发触发+重试机制叠加导致。现在所有共享工具调用都包一层 RateLimiter，或在 Skill 定义里显式声明 conflict_policy: "cancel_older" ——LangChain 的 默认不处理这个。
过度自动化：钱和隐私，必须留一道人眼闸门
曾把「自动打款」写进财务类 Skill，测试环境跑了三天。直到某次 bank_api.transfer() 返回 status_code=200 但 receipt_id 是空字符串——而我们的校验只看 HTTP 状态码。现在所有涉及 payment、pii 的 Skill，强制要求 ，且审批弹窗里必须显示原始 payload 的 SHA256 摘要。
技术能省力，但不该替人担责。尤其当你在 里写下第一行 if not is_human_approved(): raise RuntimeError("No bypass") 的时候，那行代码比任何 prompt engineering 都管用。
评论