Anthropic挑战OpenAI：Agent构建新思路

好的，没问题。我将根据你提供的信息，结合我作为资深新闻记者和编辑的经验，为你撰写一篇高质量的新闻报道。

标题：Anthropic揭秘高效Agent构建之道：告别复杂框架，拥抱简单模式

引言：

在人工智能领域，Agent（智能体）正逐渐成为构建复杂应用的关键。OpenAI的劲敌Anthropic，这家以创新和务实著称的公司，近日公开了其在Agent构建方面的独到见解。与业界普遍追求复杂框架和专用库不同，Anthropic强调通过简单、可组合的模式来构建高效Agent。这篇报道将深入探讨Anthropic的Agent构建理念，揭示其背后的逻辑和实践，为开发者提供实用的指导。

主体：

Agent的定义与架构：

Anthropic认为，Agent的定义并非只有一种。它可以是完全自主的系统，长时间独立运行，利用各种工具完成复杂任务；也可以是遵循预定义工作流的规范化实现。Anthropic将这些变体统称为Agentic系统，并在此基础上区分了两种重要的架构：

工作流（Workflow）： 通过预定义代码路径编排大型语言模型（LLM）和工具的系统。
Agent： 由LLM动态指导自身流程和工具使用的系统，从而控制任务完成方式。

何时以及何时不使用Agent：

Anthropic强调，在构建LLM应用时，应遵循“简单至上”的原则。只有在必要时才增加复杂性，这意味着并非所有场景都适合使用Agent系统。Agent系统通常以牺牲延迟和成本为代价来换取更好的任务性能，因此需要仔细权衡。

工作流： 适用于明确定义的任务，提供可预测性和一致性。
Agent： 适用于需要大规模灵活性和模型驱动决策的场景。
简单LLM调用： 对于许多应用而言，使用检索和上下文示例优化单个LLM调用就足够了。

框架的合理使用：

市面上存在许多Agent框架，如LangChain的LangGraph、Amazon Bedrock的AI Agent框架等。这些框架简化了调用LLM、定义和解析工具等低级任务，降低了入门门槛。然而，它们也可能引入额外的抽象层，掩盖底层的提示和响应，增加调试难度。Anthropic建议开发者从直接使用LLM API开始，许多模式只需几行代码即可实现。如果确实需要使用框架，务必了解其底层代码，避免因错误的假设而导致问题。

Agent系统的构建模块：

Anthropic在生产实践中总结出一些Agent系统的常见模式，这些模式基于以下构建模块：

增强型LLM： 具备检索、工具和记忆等功能。Anthropic建议关注两个关键方面：
- 根据特定用例定制这些功能。
- 确保为LLM提供简单、有良好文档的界面。
- Anthropic通过模型上下文协议，允许开发者通过简单的客户端实现与第三方工具生态系统集成。

Agent系统的常见模式：

Anthropic总结了五种常见的工作流模式：

提示链（Prompt Chaining）： 将单个任务分解为一系列步骤，每个LLM调用处理前一个调用的输出。适用于可以轻松分解为多个固定子任务的情况，以牺牲延迟为代价获得更高的准确性。
- 示例： 生成营销文案，然后将其翻译成不同的语言。
路由（Routing）： 对输入进行分类并定向到专门的后续任务。适用于复杂任务，这些任务有不同的类别，最好单独处理。
- 示例： 将不同类型的客户服务查询引导到不同的下游流程。
并行化（Parallelization）： 同时处理一项任务，并以编程方式聚合其输出。
- 分段： 将任务分解为多个并行运行的独立子任务。
  - 示例： 实施护栏，一个模型处理用户查询，另一个模型筛选不适当内容。
- 投票： 多次运行同一任务以获得不同的输出。
  - 示例： 审查一段代码是否存在漏洞。
编排器-工作者（Orchestrator-Workers）： 中央LLM动态分解任务，委托给工作者LLM，并负责综合后者的结果。适用于无法预测需要哪些子任务的复杂任务。
- 示例： 每次要对多个文件进行复杂更改的编程产品。
评估器-优化器（Evaluator-Optimizer）： 一个LLM调用生成响应，另一个调用在一个循环中提供评估和反馈。适用于有明确评估标准，并且迭代改进有可衡量价值的场景。

结论：

Anthropic的Agent构建理念强调简单、可组合的模式，而非复杂的框架和专用库。通过对Agent系统架构的深入理解，以及对各种工作流模式的灵活运用，开发者可以构建出高效、可靠的Agent应用。Anthropic的实践经验为我们提供了一个重要的启示：在追求技术复杂性的同时，更应关注问题的本质，选择最适合的解决方案。未来，随着LLM技术的不断发展，Agent将在更多领域发挥重要作用，而Anthropic的经验将为开发者提供宝贵的参考。

参考文献：