AI书房
用书来读懂AI
这里收录金京镇律师的AI、法律、产业、历史、政治、文化主题在线书。每本书都按目录、序言、章节、尾声整理，方便连续阅读。
[AI书房] 第6章 WAT框架：工作流、智能体、工具
Claude Code完全掌握
Claude Code完全掌握
第6章 WAT框架：工作流、智能体、工具
金京镇
引入
打开冰箱取出食材，对照食谱烤一个蛋糕。食谱摆在那里，厨师站在那里，面粉、鸡蛋、糖一样不少。把这三样东西分清楚，任何人都能烤出同一款蛋糕。
换一份食谱，蛋糕就不一样；换一批食材，味道就会变化；哪怕换了厨师，只要照着食谱走，做出来的成品也差不到哪里去。在Claude Code中搭建智能体工作流程，遵循的正是这个原理。
蛋糕的比喻：食谱（工作流）、食材（工具）与主厨（智能体）
WAT框架是三个英文单词的首字母缩写。W代表工作流（Workflow），A代表智能体（Agent），T代表工具（Tool）。
工作流就是食谱。「要做这款蛋糕，先打两个鸡蛋，加一杯面粉，放进180度的烤箱烤30分钟」，，它用自然语言描述任务的目标、步骤和条件。文件格式是Markdown（.md），写的不是编程语言，而是日常句子。
工具是食材，也是厨房器具。打鸡蛋的动作、预热烤箱的动作、搅拌面糊的动作，每一个都是一件工具。技术上看，它们是Python脚本文件（.py），负责API调用、数据转换、文件生成等实际执行操作。
智能体是主厨，就是Claude Code本身。它读食谱（工作流），挑选需要的食材（工具），按正确的顺序使用。执行过程中遇到问题，它自己做判断：烤箱温度太高就调低，面粉不够就找替代材料。
关键在于，这三者是分离的。换一份食谱，就能做出不同的成品；换一批工具，同一份食谱也能对接不同的服务；而主厨（智能体）无论哪种食谱和工具的组合，都能驾驭。
工作流用Markdown，工具用Python：为什么要分离
打开一个工作流文件，看到的大致是这样的结构。
# 竞争对手分析工作流 ## 目标 收集并分析竞争对手数据，生成带品牌标识的PDF报告。 ## 所需输入 - 公司信息（business_profile.json） - 品牌资产（logo、品牌规范） ## 使用工具 1. discover_competitors.py 2. research_competitors.py 3. analyze_competitors.py 4. generate_report.py ## 预期输出 - 各竞争对手档案文件 - 分析结果摘要 - 带品牌标识的PDF报告 ## 异常处理 - 竞争对手网站拒绝访问时：搜索替代数据源 - API调用配额超限时：切换为批量请求
全是日常用语，不懂编程的人也能读懂。工作流文件既是交给智能体的任务说明书，也是一份人可以审阅的文档。
工具文件则是Python代码。打开discover_competitors.py，里面是API调用逻辑、数据解析代码、错误处理例程。用户几乎不需要亲自阅读或修改这些代码。智能体生成它们，智能体修改它们。用户要操心的只有工作流文件的内容，也就是「我想做什么」。
分离的理由在于职责划分。工作流指明「做什么」，工具解决「怎么做」。把两者混在一起，想改任务指令就得动代码，想改代码又会搅乱指令文档。正因为分离，才能只修改工作流就改变分析范围，或者只替换工具就对接另一个API。
概率推理与确定性执行的分离如何带来可靠性
WAT框架把工作流和工具分开，背后还有一层更深的技术原因。AI智能体的推理属于概率性过程，同一个问题每次可能给出略有不同的答案。代码的执行则属于确定性过程，同样的输入永远产出同样的结果。
如果让智能体直接处理每一个步骤，概率性推理逐层叠加，准确率会急剧下降。假设单步准确率是90%。两步之后变成81%（0.9 × 0.9）。五步之后跌到59%（0.9⁵）。十步之后只剩35%。
WAT框架解决的就是这个问题。智能体只负责判断「用哪些工具、按什么顺序执行」，真正的数据处理、API调用、文件生成这些执行工作，全部交给确定性代码（工具）完成。智能体的概率判断只集中在少数关键决策点上，其余执行过程由代码一致地完成。整个工作流的可靠性因此提升。
五步连续任务的准确率陷阱：90%是如何跌到59%的
把这道数学题拆得再细一些。
假设让AI模型完成这样一串任务：读一封邮件、提炼要点、归类、排优先级、起草回复。五个步骤。如果每步模型做出正确判断的概率是90%，五步全部正确的概率大约是59%。换句话说，十次里有四次会在某个环节出错。
解决办法就是「关注点分离（Separation of Concerns）」。读邮件、从文本中提取关键词、打分类标签，把每个动作做成独立的工具。每个工具按确定性方式运行。智能体只做一个判断：「对这封邮件执行分类工具，再根据分类结果执行优先级工具。」
判断的复杂度降下来了，整体准确率就上去了。
这就是在实际工作中采用WAT框架的理由。把每个步骤拆成独立工具，让智能体去组合它们，比一句「你全部搞定吧」丢给智能体，产出稳定得多。
自我改进循环：从错误中学习并更新工作流的机制
WAT框架内置了一个自我改进循环（Self-Improvement Loop）。智能体在执行工具时遇到报错，会读取错误信息并分析原因，然后修改工具代码，验证修改后的工具能否正常运行，末尾在工作流文件中补上一条「遇到这种情况应这样处理」的异常处理项。
举个例子。爬取竞争对手网站的工具触发了API调用配额超限。智能体从错误信息中读到「Rate Limit Exceeded」，去检索API文档，看有没有批量接口（Batch Endpoint）。找到之后，它修改工具代码，把请求方式切换为批量调用，然后跑一遍验证。
确认正常运行后，智能体在工作流文件里加上「API配额超限时使用批量接口」这一条。
下次再执行同一个工作流，智能体读到更新后的文档，一开始就用批量方式发送请求，同样的错误不会再犯。工作流每多跑一次，异常处理就多积累一层，工具代码就多打磨一轮，整个系统越来越结实。
文件结构设计：workflows、tools、temp三个文件夹的职责
智能体生成的文件越来越多，就需要一套整理规则。WAT框架使用三个核心文件夹。
workflows/ 文件夹存放工作流文件。竞争对手分析工作流、Newsletter生成工作流、线索爬取工作流，每个是一份Markdown文件。
tools/ 文件夹存放工具文件。网页爬取工具、PDF生成工具、邮件发送工具，每个是一份Python文件。
temp/ 文件夹是临时文件的存放空间。任务执行过程中产生的中间数据、调试日志、一次性输出物都放在这里。任务结束后可以清理掉。
把这套文件夹结构告诉智能体，正是claude.md文件的职责之一。在claude.md中写上「工作流存入workflows/文件夹，工具存入tools/文件夹，临时文件存入temp/文件夹」，智能体就会遵守这个规则。
不写这个文件的话，智能体可能把所有文件一股脑堆在项目根目录下。文件越积越多，越来越乱，智能体自己找工具也要浪费时间。
在项目中放入claude.md文件，对智能体说「读一下这个文件，然后初始化项目」，智能体就会自动创建文件夹结构。左侧资源管理器里出现workflows、tools、temp三个文件夹，每个文件夹内还放好了说明文件（README）。这个初始化操作每启动一个新项目只需要做一次。
[图表 05-01：WAT框架结构图。智能体（A）读取工作流（W）、执行工具（T）的三角关系。同时展示workflows文件夹、tools文件夹、temp文件夹的布局。]
回到蛋糕的比喻。食谱整理好了，同一款蛋糕随时可以再做一遍；只换食材，就能尝试变体；哪怕换了一位厨师，照着食谱来，做出的成品也相差无几。把工作流和工具分开存放，产生的正是这种效果。
不过，在把食谱递给厨师之前，还得先设定好厨师本身的工作方式。这就是claude.md的角色。而要把这个设定写好，需要先理解智能体的工作记忆是如何运作的。
人工智能专家 金京镇律师
AI法律政策专家 · 前国会议员 · 著作等身
如果这本书曾在你身边短暂停留，请支持我们，让下一个故事得以面世。
（自愿赞助账户：韩国农协银行 302-1096-0948-81 户名：金京镇）