Claude新指南，教你构建属于自己的智能体

本文来自微信公众号：王智远，作者：王智远，原文标题：《Claude发布一套智能体构建指南》，题图来自：AI生成

上周五，2024年12月20日。Anthropic这家AI公司发布一份报告，题目是《Building effective agents》（构建高效的智能代理）。

你可能没听过Anthropic，但他们的产品你可能知道，比如Claude系列的AI助手，有Claude 3.5 Haiku和Claude 3.5 Sonnet等等。

这份报告，是基于他们过去一年与数十个团队合作构建LLM（大语言模型）代理系统的经验总结。我周末看了，大概有五点内容：

1. 对代理系统Agents的定义； 2. 讨论什么时候用代理系统； 3. 五种核心的工作流模式； 4. 一些现实中的例子； 最后，给开发者提供一些实践认知。

我觉得内容对开发者，或者对智能体、工作流感兴趣的人挺有帮助；所以，把有价值的内容理解后，跟你汇报下。

一

Agents不少人听过，Anthropic这家公司怎么理解的呢？他们认为，代理可以有很多种定义。

有些客户把代理看作完全独立的系统，可以长时间自主运行，使用各种工具来完成复杂的任务；另一些客户则把这个词用来描述那些按照预先设定的流程运行的系统。

在Anthropic，把所有这些不同的形式都叫做代理系统（agentic systems），但在工作流（Workflows）和代理（Agents）之间，有很大的区别。

区别在哪呢？

工作流，是提前写好的代码来协调人和工具的系统；代理是自己动态管理自己的流程和工具使用，保持对完成任务方式的控制。

这种区别很重要，因为它帮我们理解了代理系统的本质：即，不是所有的AI辅助系统都得完全自主，有时候一个提前设定好的工作流更适合某些情况。

那么，什么时候该用工作流、什么时候该用智能体？

其认为，如果任务定义得很清楚，工作流更适合，因为它能提供可预测性和一致性。

如果要大规模的灵活性和模型驱动的决策，代理是更好的选择，但对很多应用来说，优化单个LLM调用，配合检索和上下文示例通常就够用了。

通俗地说：工作流更适合任务明确、步骤固定的工作。就像你按照食谱做菜，每一步都写得清清楚楚，只要跟着做就行了。

而智能体适合要灵活应对、随机应变的情况。比如：你要去一个新城市冒险，没有固定的路线，要根据实际情况来决定下一步怎么走，此时，智能体能帮你在复杂多变的环境中做出决策。

关于定义，这是第一部分内容。第二部分是什么呢？

Anthropic提出，目前，看到市面有四种流行开发框挺火。分别是：LangChain的LangGraph、Amazon Bedrock的AI Agent框架、Rivet和Vellum。

相信你看到名字有些理解不透，别着急，我和你一样，于是，索性查了一下。

先说说LangChain。它是一个工具，帮我们创建和管理语言模型（LLM）的工作流。你可以把它想象成一个图表，帮开发者把不同的任务和步骤连起来，这样，就能清楚地知道每一步该怎么做，调整起来也方便。

接下来是Amazon Bedrock的AI Agent框架。

这是亚马逊提供的一个框架，像一个工具箱，里面有很多现成的工具和资源；帮开发者快速搭建智能应用，你可以用它来设计和运行各种AI任务，不用从头开始。

然后是Rivet，它是一个拖放式的图形用户界面（GUI）工具，专门用来构建语言模型的工作流。

我们可以把它想象成拼积木一样，把不同的功能和步骤拖到一起，形成一个完整的工作流程，这种方式简单直观，适合不太会编程的人。

最后是Vellum，它也是一个图形用户界面工具，主要是用来构建和测试复杂的工作流；设计完成后，你可以在Vellum里测试，确保一切正常运行。就像一个实验室，让你可以在里面尝试各种方案。

总的来说，四个工具区别在于：LangGraph用图表连接任务和步骤；Amazon Bedrock的AI Agent框架提供全面的工具箱，让开发者不用从零开始；Rivet是一个拖放式的GUI工具，适合不懂编程的人；Vellum专注于复杂工作流的设计和测试。

Anthropic给了一个建议：

开发者可以先直接用LLM API来开发，因为很多功能用几行代码就能搞定；如果要用框架，一定要弄懂底层代码，要小心，框架可能会让调试变难，别因为框架功能多就乱加复杂性。

它们还特别提醒，客户常犯的一个错误是，对框架底层实现有误解。这告诉我们，工具只是帮手，真正重要的是理解背后的道理。

所以，结论是：1. 框架确实能让一些基本任务变简单，比如调用LLM、定义和解析工具、链接调用，但框架不应该成为我们增加不必要复杂性的理由；2. 保持系统简单、好维护、好调试，这才是最重要的。

二

第三部分，报告中详细介绍五种核心工作流模式。

这部分很重要，首先提到，提示链式工作流（Prompt chaining）。怎么理解？

想象一下，你要完成一个复杂的写作任务，比如写一篇很棒的营销文案。你可能先写个大纲，检查一下大纲合不合格，然后，再根据大纲写出完整的文案。

这种工作流的要点是，把一个大任务拆成一连串的小步骤。每个步骤都是一个LLM调用来处理的，而且后面的步骤会用前一个步骤的结果作为输入。

在这个过程里，你还可以加一些检查点（报告里叫“gate”），确保一切都在正确的轨道上。

这种工作流最适合能明确分成几个固定小任务的情况。主要目的是让每个LLM调用都专注于更简单的任务，提高整体的准确性，虽然可能会多花点时间。

具体例子是：

文档写作流程：第一步，生成文档大纲；第二步，检查大纲是否符合特定标准；第三步，基于审核过的大纲写完整文档。

优势是每个步骤都专注做一个任务，提高准确性；可以在关键点加质量检查；流程清晰，容易调试和优化。

第二种是：路由工作流（Routing）。

这个模式挺有意思，处理很多用户请求时，会遇到各种各样的问题；有的问题简单，有的要专业技术支持，还有的可能涉及退款这种敏感操作。

路由工作流，关键是先对问题进行分类，然后引导到最合适的处理流程，这样做的好处很明显：可以针对不同类型的任务优化不同的处理方式，而不是用一个通用的办法来应对所有情况。

举个例子：

客户服务系统里，收到用户的问题后，路由工作流可以先判断这是个一般问题、退款请求还是技术支持需求，然后分别引导到不同的处理流程。

更聪明的是，它还能根据问题的复杂度选择用不同能力的模型。比如，简单常见的问题可以交给像Claude 3.5 Haiku这样快速的模型处理，复杂或不常见的问题可以交给像Claude 3.5 Sonnet这样强大的模型来解决。

这样既能保证服务质量，又能优化成本和速度，关键是，这种分类可以通过LLM来完成，也可以用传统的分类模型或算法。

所以，它的优势在于灵活性和可扩展性，随着业务的发展，你可以轻松添加新的分类和处理流程，不会影响现有的功能。

三

第三种，是并行化工作流（Parallelization），这个模式适合要同时处理好多任务。

比如：你在做一个大项目，得同时考虑好几个方面；类似于开发软件，要一个模型来检查用户输入的安全性，同时另一个模型来生成代码。

并行化工作流，就是为了应对这种要同时做多件事的情况设计。

报告里说，并行化主要有两种实现方式：

1. 把任务拆成独立的小任务，让它们同时进行，这样可以省时间；2. 通过投票机制，让好几个模型处理同一个任务，然后汇总结果；这样做的好处是，你能从不同的角度得到不同的输出，提高结果的可信度。

总的来说，它像一个多功能团队，每个人都做自己最擅长的事，一起合作，最后得到一个更强的结果。

第四种，协调者-工作者工作流（Orchestrator-workers）是什么？

你在组织一场音乐会，总得有个人来管大局，确保每个细节都能顺利进行，这个人就像“协调者”。

其他人就负责具体的活儿，比如：调音响、弄灯光、卖票这些，他们就是“工作者”，协调者得根据现场情况灵活调整谁干什么。

报告里说，协调者-工作者工作流的点子是一个中央LLM（就是协调者）来动态分配任务，让好多工作者LLM去完成这些任务。

这样，协调者能根据实际情况，灵活决定要做哪些小活儿，而不是一开始就把步骤都定死了。

这个模式适合你没法提前知道具体要干啥的情况，比如软件开发里的编程任务，每次根据需求，可能要改好多文件，协调者就能根据实际情况决定哪些活儿先干，哪些可以放一放。

总之，协调者-工作者工作流就像是一位指挥家。

接下来说说第五种：评估者-优化者工作流（Evaluator-optimizer），这个模式适合要反复改进和反馈的任务。

比如：你写文章，可能先写个草稿，然后请朋友看看，提提意见；你根据意见再修改，让文章更好。这个过程就跟评估者-优化者工作流差不多。

再举个例子，我们搜一个东西可能要好几轮；评估者工作流，会看看现在的搜索结果满不满足要求，不满足继续搜，直到找到想要的信息。

报告里说，这种工作流的关键是循环：

一个LLM先给出初步的回应，另一个LLM来评估这个回应，然后提供反馈，这个过程可以一遍遍重复，直到得到一个更好的结果。

好处在于它可以一遍遍改进，通过不断的反馈和调整，最后的输出质量能提高很多；所以，评估者-优化者工作流就像一个严格的编辑，帮你把文章改得更好。

以上五种核心工作流模式，你对哪一种印象比较深？

记不住也没关系，有一个办法是，用个人工作的方式，去嵌入几种模式中，看看哪些业务、项目、任务适合哪一种。

四

第四部分主要讲述了：智能代理怎么工作。其提到：代理会先根据用户的命令或者和用户的互动，来搞清楚要干啥。一旦任务明确，代理就自己开始干活。

干活时，代理得知道周围的情况，比如用工具得到的结果或者代码运行的反馈，这样它才能知道自己干得怎么样。

如果代理在干活的时候碰到难题，它可以停下来，找人问问，确保任务能顺利完成；任务干完了就结束了，但也可以先设定好一些停止的条件，比如最多干多少次，这样能控制整个过程。

在第10页中，Anthropic给了一些实际例子。

他们强调，代理特别适合处理开放性的问题，尤其是步骤不好预测的任务。因为代理能自己干活，所以，在信任它们的地方，它们能帮大忙。

比如：有个编码代理，用来解决软件工程里的任务，代理自己先看看哪些文件需要改，然后反馈出来，这样能大大提高开发的速度。

最后，第五部分里，Anthropic给出了一套开发工具的好点子，他们觉得：

1. 工具在代理系统里特别重要。它们能让代理和外面的服务、API好好交流；所以，工具设计和做出来时要清楚明白，这样代理用起来才顺手。 2. 开发者得给模型足够的时间思考。别让模型在生成输出的时候卡壳，工具的输入格式和参数描述要简单明了，这样模型才能更好地理解和用这些工具。 3. 工具的定义和规格要和整体的提示工程一样重视。开发者要考虑不同格式对模型表现的影响。比如：在编辑文件时，可以选择用差异格式或者重写整个文件，要确保选的格式能让模型更容易生成正确的输出。

报告还建议要多做测试，观察模型怎么用工具，然后根据测试结果不断改进工具的设计，通过运行好多示例输入，开发者可以发现模型可能犯的错误，然后改进。

最后，创建一个好的代理计算机接口（ACI）也很重要，开发者要确保工具用起来简单直接，这样用户体验才好；通过这些方法，Anthropic希望能帮开发者在开发工具的时候避开常见的坑，确保代理系统能高效运行。

注释：[1].Anthropic. Building effective agents. 2024.12.20；地址：https://www.anthropic.com/research/building-effective-agents

本文来自微信公众号：王智远，作者：王智远

本内容为作者独立观点，不代表虎嗅立场。未经允许不得转载，授权事宜请联系 hezuo@huxiu.com