大多数软件工作流都是管道式的：输入进来，按顺序执行步骤，输出出去。它们可预测、可调试，但也脆弱。当某个步骤失败时——API 挂了、页面布局变了、数据格式与预期不符——工作流就会停止，等待人工介入。
智能体工作流（Agentic Workflows）改变了这一切。你不再预设固定的步骤序列，而是给 AI 智能体一个目标，让它自己决定如何达成——根据执行过程中发现的情况实时调整。这种转变不仅是技术层面的，它改变了可自动化的范畴。
本指南涵盖了构建在生产环境中真正可用的智能体工作流所需的设计模式、决策框架和能力需求。
什么让工作流变得"智能体化"？
当工作流将决策权委托给 AI，而不是预先编写好每一个分支时，它就变得智能体化了。关键词是自主性（autonomy）。
| 传统工作流 | 智能体工作流 |
|---|---|
| "如果 X，做 Y。如果 A，做 B。"（全部预先编码） | "达成目标 G。你有工具 T。找到路径。" |
| 遇到意外输入时失败 | 适应意外输入 |
| 调试：检查日志中哪一步报错 | 调试：检查智能体为什么做出那个决策 |
| 通过添加更多分支条件来扩展 | 通过给智能体更好的工具来扩展 |
Andrew Ng 在智能体设计方面的核心洞见：智能体工作流不是更好的管道。它是一种不同类别的自动化——系统在执行过程中做出选择。
智能体工作流的四种模式
每个智能体工作流都由四种基本模式构建而成，可以单独使用，也可以组合使用。
模式一：反思（Reflection）
智能体先产出结果，然后批判自己的作品并加以改进。
写代码 → 审查代码 → 发现 bug → 修复 → 再次审查
这是最简单的模式，也往往是投资回报率最高的。即使是一个基础的"审查你自己的作品并改进"循环，也能捕捉到单次生成会遗漏的错误。LLM 更擅长批判输出，而不是第一次就产出完美结果——反思正是利用了这种不对称性。
模式二：工具使用（Tool Use）
智能体调用外部工具来获取信息或执行超出文本生成范围的操作。
"X 的当前价格是多少？" → 调用搜索工具 → "价格是 Y 元" → 继续
工具将智能体从推理引擎转变为行动者。没有工具，智能体只能思考。有了工具——搜索、爬取、生成、存储、发布——它就能真正影响世界。
这正是 AnyCap 成为智能体能力层的地方。智能体不必说"我希望我能搜索网页"，而是直接运行：
anycap search --prompt "NVIDIA 股票当前价格是多少？"
工具执行。智能体读取结果。工作流继续。
模式三：规划（Planning）
智能体将复杂目标分解为子任务，按顺序执行，并根据学习到的信息调整计划。
目标："撰写一份关于 AI 视频的市场报告"
→ 计划：(1) 搜索关键厂商 (2) 爬取定价页面
(3) 比较功能 (4) 撰写报告 (5) 发布
→ 执行步骤 1 → 发现新厂商 → 修订计划 → 继续
规划是智能体工作流与传统管道差异最大的地方。管道有固定的计划。智能体工作流有一个在执行过程中根据发现而演变的计划。
模式四：多智能体协作（Multi-Agent Collaboration）
多个具备不同专长的智能体在编排器的协调下处理任务的不同部分。
研究智能体：寻找信息来源
写作智能体：撰写报告
审查智能体：检查错误和遗漏
发布智能体：部署最终页面
多智能体系统增加了复杂性，但实现了专业化。研究智能体可以优化为追求全面性，而写作智能体则优化为追求清晰度——不同的系统提示、不同的工具、不同的优先级。
能力：你的智能体执行工作流需要什么
没有工具的工作流模式只是一张图表。智能体需要实际的能力来执行：
| 工作流模式 | 所需能力 | AnyCap 工具 |
|---|---|---|
| 反思 | 生成，然后审查 | LLM 自我批判 |
| 工具使用 | 搜索、爬取、生成、存储、发布 | anycap search、anycap crawl、anycap image generate、anycap drive、anycap page |
| 规划 | 以上所有，加上状态管理 | 完整的 AnyCap 工具集 |
| 多智能体 | 以上所有，加上消息传递 | 编排器 + 每个智能体的 AnyCap |
智能体工作流的质量与可用工具的质量成正比。一个只有搜索工具的智能体只能产出搜索结果。一个拥有搜索 + 爬取 + 生成 + 存储 + 发布能力的智能体，能产出已完成、已交付的作品。
编排决策：何时使用哪种模式
并非每个任务都需要多智能体规划系统。决策框架：
任务路径是否可预测？
→ 是：传统管道即可。不要过度设计。
→ 否：使用工具使用或规划模式。
任务是否受益于自我批判？
→ 是：添加反思模式。
→ 否：跳过。
任务是否太大，单个智能体无法胜任？
→ 是：考虑多智能体。
→ 否：单个智能体更简单、更可靠。
最常见的错误：在用尽单个装备精良的智能体所能做的事情之前，就跳到多智能体。
生产环境考量
成本管理
智能体工作流可能很昂贵。每次工具调用都消耗积分；每个规划步骤都消耗 token。缓解措施：
- 限制每次工作流执行的步骤数
- 对简单的子任务使用更便宜的模型（反思、格式化）
- 缓存常见的工具结果（不要搜索两次相同的内容）
故障处理
智能体工作流的失败方式与管道不同。管道在特定步骤以特定错误失败。智能体工作流可能在意识到错误之前沿着错误路径走了好几步。
针对这一点进行设计：
- 超时：如果工作流超过 N 步或 T 分钟，返回部分结果
- 检查点：保存中间状态，以便智能体可以恢复而非重启
- 人机协同：对于高风险操作（发布、发送），需要审批
可观测性
你看不到的东西就无法调试。记录每一个决策：调用了什么工具、用了什么参数、返回了什么结果、智能体决定下一步做什么。没有这些，你就是在调试一个黑箱。
从理论到实践
智能体工作流不是未来的概念。它们今天已经在生产环境中运行——自动化研究、生成内容、管理数据管道、交付完成的作品。
障碍不在于模式，而在于工具访问。模式已经得到了充分的记录。一直缺失的是一个统一的方式，让智能体能够真正执行它们——搜索、爬取、生成、存储和发布，而无需集成十几个独立的 API。
AnyCap 提供了这个统一的能力层。一个 CLI。全部工具。智能体专注于决策；运行时负责执行。