和Google，OpenAl+不同，Anthropic这篇文章并没有仰望星空，而是非常接地气地总结了他们在过去的一年里积累下的实战经验:
这篇长文中最重要的一点是:
明确的区分出workflow(工作流)和 agent(代理)，清晰的讲解了两者的区别，何时候使用workflow+，何时使用agent。
什么是Agent
目前，普遍将Agent定义为完全自主的系统，这些系统在较长时间内独立运行，使用各种工具完成复杂的任务。而Anthropic首次将Agent进行了分类：
工作流workflow：通过预定义的代码路径编排 LLM 和工具的系统。
代理agent： LLM 动态指导自己的流程和工具使用，保持对他们完成任务方式的控制的系统。
何时使用代理
总结来说：
只有在必要的时候才使用Agent。
当任务复杂性较高时，一工作流可以为明确的任务提供稳定性和一致性，而在需要灵活性以及大规模模型驱动决策的场景中，智能体则是更好的选择。通过检索和上下文示例优化单次LLM调用通常已经足以满足需求。然而，对于多数应用场景，通过检索和上下文示例优化单次LLM调用通常已经足以满足需求。
使用什么框架来构建
有许多框架能够实现Agent系统：
·来自 LangChain 的 LangGraph;
·Amazon Bedrock 的 AI 代理框架;
·Rivet，拖放式 GUI LLM 工作流程构建器;
·Vellum，另一个用于构建和测试复杂工作流的 GUI 工具。
然而，Anthropic在多次实践中得出结论：
建议直接使用LLM API，许多模式可以在几行代码中实现。
如何构建Agent？
Anthropic从构建块、工作流、Agent的顺序进行介绍：
构建块：增强的 LLM
类似传统软件设计中的模块化。不同点是Agent中主要是 LLM 和检索、工具、记忆等块进行交互，并推荐使用 anthropic 最近刚发布的MCP协议来作为块之间的通讯协议。
构建工作流：
在解决实际问题的时候，大部分场景需要的都不是Agent，而是Workflow：
提示链接工作流：
借助COT方法，多步提示来完成任务
提示链接将任务分解为一系列步骤，其中每个 LLM 调用都会处理前一个调用的输出。可以在任何中间步骤中添加编程检查，以确保流程仍处于正轨上。
主要目标是通过使每个 LLM 调用成为一项更轻松的任务，在延迟之间进行权衡以获得更高的准确性。
路由工作流：
对输入分类并引导到某个流程中
如果没有此工作流程，针对一种输入进行优化可能会损害其他输入的性能。路由非常适合复杂任务，其中有不同的类别，可以更好地单独处理，并且可以通过 LLM 或更传统的分类模型/算法准确处理分类。
并行工作流：
通过分区和投票，来并行的执行流程
·分段：将任务分解为并行运行的独立子任务。
·投票：多次运行同一任务以获得不同的输出。
当可以并行化已划分的子任务以提高速度时，或者当需要多个视角或尝试以获得更高的置信度结果时，并行化非常有效。对于具有多个考虑因素的复杂任务，当每个考虑因素都由单独的 LLM 调用处理时，LLM 通常会表现得更好，从而可以将注意力集中在每个特定方面。
Orchestrator-worker工作流：
抽象出协调者和工人，在工作流中应对无法预测的复杂任务。
此工作流程非常适合于无法预测所需子任务的复杂任务。虽然它在拓扑上相似，但与并行化的主要区别在于它的灵活性 — 子任务不是预定义的，而是由编排器根据特定输入确定的。
Evaluator-optimizer工作流：
一个类似迭代的结构，用来循环的生成+评估。
当我们有明确的评估标准并且迭代优化提供可衡量的价值时，此工作流程特别有效。这类似于人类作家在制作精美的文档时可能经历的迭代写作过程。
构建Agent
自主智能体适合处理开放式问题，尤其是那些难以预测所需步骤或无法通过硬编码预设路径的任务。在这些场景中，LLM可能需要经过多轮交互完成任务，因此需要对其决策能力有足够的信任。自主智能体非常适合在可信环境中扩展任务。
最后Anthropic总结了构建Agent的原则：
· 保持简单
• 保持透明
• 设计清晰的工具文档
构建Agent的关键，就像文中最后所说的：
在LLM领域取得成功并非在于构建最复杂的系统,而是构建适合你需求的正确系统。从简单的提示开始,通过全面评估优化它们,只有当更简单的解决方案不足时才添加多步骤智能系统。