我们深入探讨了Anthropic团队在AI代理系统设计中的一个重要发现：

简约性往往优于复杂性。

这个观点不仅挑战了行业常规认知，更为我们提供了一个全新的系统设计视角。

今天，让我们继续探索这份研究报告中的其他实践经验，特别是在AI Agents的具体实践层面。

如何在保持系统简约的同时确保其效能？

如何在实际应用中平衡自主性与可控性？

这些问题不仅关系到技术实现，更涉及到整个AI系统的设计哲学。

在这个快速发展的AI时代，我们常常被各种新技术和框架所吸引，却可能忽视了最基本的工程智慧。

正如数学和物理学中最基础的定律往往以最简洁的方程呈现，优秀的AI系统设计同样应该追求"大道至简"的境界。

让我们继续深入Anthropic团队的研究发现，看看他们如何将这种简约理念付诸实践。

五、构建模块、工作流和代理

代理系统的基本构建模块是经过增强的LLM，它具备检索、工具使用和记忆等功能。

我们当前的模型可以主动使用这些能力 —— 生成自己的搜索查询、选择合适的工具，并决定保留哪些信息。 对于实现，我们建议重点关注两个方面：

将这些功能针对性地适配您的具体用例，并确保为LLM提供简单、文档完备的接口。

虽然实现这些增强功能的方式有很多，

但其中一种方法是通过我们最近发布的模型上下文协议（Model Context Protocol），

它允许开发者通过简单的客户端实现来集成不断增长的第三方工具生态系统。

在探索完AI代理系统设计的基本原则后，Anthropic团队为我们揭示了一个渐进式的系统构建方法。

这种方法从最基础的构建块开始，通过不同的工作流模式组合，最终达到复杂的自主代理系统。

让我们先深入理解这个构建体系的基石——增强型LLM。

这不是一个简单的大语言模型，而是一个经过精心增强的系统，集成了检索、工具使用和记忆等核心能力。

有趣的是，现代LLM已经能够主动利用这些能力，比如自主生成搜索查询、选择合适的工具，并决定需要保留哪些信息。

The augmented LLM

在实现层面，Anthropic特别强调两个关键点：

• 一是要根据具体应用场景定制这些增强能力，

• 二是要确保为LLM提供清晰、文档完备的接口。

这种设计思路体现了工程实践中"易用性"与"可靠性"的平衡。

比如说，如果我们在开发一个代码分析助手，那么增强型LLM不仅需要理解代码，还需要能够有效使用版本控制工具、代码分析工具等。

这些工具接口的设计必须既要足够简单清晰，让LLM能够准确理解和使用，又要保持足够的灵活性以适应不同的使用场景。

增强型LLM：代理系统的基石

在我们深入探讨工作流和代理系统之前，必须先理解其核心基础——增强型LLM（Large Language Model）。

在当前的AI系统设计中，增强型LLM(Large Language Model)已经成为构建智能代理系统的核心基石。

这种设计理念超越了传统的"单纯语言模型"思维，转而追求一种更全面的智能体系。

什么是增强型LLM？从本质上看，它是一个集成了检索、工具调用和记忆等多重能力的综合系统。

增强型LLM不同于普通的语言模型，它集成了三个关键能力：

检索（Retrieval）、工具使用（Tools）和记忆（Memory）。

想象一下，这就像是给予了大语言模型一套完整的"感知-思考-行动"能力：

通过检索获取信息（感知），通过推理处理信息（思考），通过工具使用来实现目标（行动）。

这种设计让AI系统不再局限于简单的文本生成，而是能够与现实世界进行更深层次的互动。

Anthropic团队在实践中发现，现代LLM已经展现出令人惊喜的能力

——它们能够主动生成搜索查询、自主选择合适的工具、判断需要保留的关键信息。

这种主动性的出现，标志着AI系统正在向真正的"智能助手"方向发展。

增强型LLM系统架构

Anthropic团队的研究表明，一个优秀的AI代理系统往往建立在经过精心设计的增强型LLM之上。

让我想起了斯坦福大学研究的一个发现：

工具的威力不在于其复杂程度，而在于使用者能否准确理解并恰当运用它。

同样的道理，构建增强型LLM时，我们需要关注两个核心问题：

1. 如何让这些增强能力真正服务于特定场景

2. 以及如何确保LLM能够轻松地理解和使用这些能力。

Anthropic最近发布的Model Context Protocol就是一个很好的例子。

这个协议允许开发者通过简单的客户端实现来集成各种第三方工具。

Model Context Protocol

这种增强型LLM的设计思路，让我想起了Unix操作系统的设计哲学：

提供一组简单而强大的工具，通过灵活的组合来解决复杂的问题。

正如物理学中夸克和电子这样的基本粒子通过精妙的组合构成了浩瀚宇宙中的一切物质，

增强型LLM的这些基础能力也能在其相互作用与组合中，绽放出令人惊叹的智能效果。

在下一部分，我们将探讨如何基于这个强大的基础构建块，设计出更复杂的工作流模式。

但请记住，无论系统变得多么复杂，增强型LLM始终是其中最重要的基石。

一座大厦能够屹立不倒，关键在于它的地基是否扎实。

工作流模式的艺术

提示链工作流：任务的优雅分解

接下来让我们探索工作流模式中的第一个重要形态：提示链工作流（Prompt Chaining）。

提示链将任务分解为一系列步骤，每个LLM调用都会处理前一个调用的输出。

您可以在任何中间步骤添加程序化检查（参见下图中的"gate"），以确保整个流程仍在正轨上。

工作流的使用时机：这种工作流最适合那些可以轻松、清晰地分解为固定子任务的情况。

主要目标是通过让每个LLM调用处理更简单的任务来用延迟换取更高的准确性。

提示链的实用示例：

• 生成营销文案，然后将其翻译成其他语言

• 撰写文档大纲，检查大纲是否符合特定标准，然后基于大纲撰写文档

The prompt chaining workflow

提示链工作流将复杂任务分解为连续的步骤，每个LLM调用都基于前一步的输出进行处理。

关键在于，开发者可以在任意中间步骤添加程序化的检查点，确保流程始终在正确的轨道上。

这种工作流特别适合那些可以清晰分解为固定子任务的场景。

比如将营销文案生成和多语言翻译组合在一起，或是先生成文档大纲，验证其符合要求后再展开完整内容。

它的主要优势在于用轻微的延迟换取更高的准确性——通过让每个LLM调用专注于更简单的任务来实现。

这种设计反映了软件工程中的单一职责原则：每个组件只负责一个明确的任务。

在实践中，这种模式不仅提高了系统的可靠性，还大大简化了调试和优化的过程。

接下来探讨的路由工作流展示了另一种优雅的任务处理方式。

路由工作流：智能分流的艺术

这是另一种精妙的设计模式。

路由会对输入进行分类，并将其引导至专门的后续任务。

这种工作流允许关注点分离，并构建更专门化的提示。

如果没有这种工作流，为某一类型输入优化可能会影响到其他输入的性能表现。

使用时机：

路由适用于那些有明显不同类别、需要分开处理的复杂任务，且这些类别可以通过LLM或传统的分类模型/算法进行准确分类。

路由的实用示例：

• 将不同类型的客服查询（一般问题、退款请求、技术支持）引导到不同的下游流程、提示和工具

• 将简单/常见问题路由给较小的模型（如Claude 3.5 Haiku），将困难/特殊问题路由给更强大的模型（如Claude 3.5 Sonnet），以优化成本和速度

The routing workflow

路由工作流的核心思想是对输入进行智能分类，然后将其导向专门的处理流程。

这种设计允许我们为不同类型的任务优化独立的提示和工具，避免了一个通用解决方案可能带来的性能损失。

实际应用中，这种模式特别适合处理客户服务场景。

比如，一个查询可能是技术支持请求、退款申请或一般咨询，通过路由系统，每种类型的请求都能得到最专业的处理。

更智能的做法是根据任务复杂度将查询分配给不同能力的模型，如将简单任务交给Claude Haiku处理，复杂任务交给Claude Sonnet处理，从而实现性能和成本的最优平衡。

这种分而治之的方法让我想起了微服务架构的设计理念：通过服务的专业化来提高系统的整体性能和可维护性。

在AI系统中，这种专业化同样带来了显著的效果提升。

并行化工作流：效率与准确的平衡

这种设计模式有两个关键变体：任务分段和投票机制。

LLM有时可以同时处理任务，并通过程序化方式汇总其输出。这种并行化工作流主要有两种关键变体：

• 分段：将任务拆分为并行运行的独立子任务

• 投票：多次运行相同任务以获得多样化的输出

使用时机：并行化在以下情况下特别有效：

• 一是可以将子任务并行化以提高速度

• 二是需要多个视角或尝试来获得更高置信度的结果。

• 对于涉及多个考虑因素的复杂任务，当每个考虑因素由单独的LLM调用处理时，LLM通常表现更好，因为这允许对每个具体方面进行专注处理。

The parallelization workflow

在任务分段模式中，系统将复杂任务拆分为可以并行处理的独立子任务。

例如，在代码安全审查中，一个LLM检查业务逻辑，另一个专注于安全漏洞，第三个关注性能优化。

这种并行处理不仅提高了效率，还能实现更专注和深入的分析。

投票机制则采用多个LLM同时处理相同任务，通过整合多个视角来提高结果的可靠性。

这在内容审核等需要高准确度的场景特别有用，通过设置不同的投票阈值来平衡准确率和召回率。

编排者（协调者）- 执行者工作流：动态任务分配

在编排者（协调者）- 执行者工作流中，一个中央LLM动态地分解任务，将它们分配给执行者LLM，并综合它们的结果。

使用时机：

这种工作流非常适合那些无法预测所需子任务的复杂任务（例如，在编程中，需要修改的文件数量和每个文件中的修改性质可能都取决于具体任务）。 虽然在结构上与并行化类似，但关键区别在于其灵活性 —— 子任务不是预先定义的，而是由编排者根据具体输入来确定。

编排者-执行者工作流的实用示例：

• 需要对多个文件进行复杂修改的编程产品

• 涉及从多个来源收集和分析可能相关信息的搜索任务

The orchestrator-workers workflow

编排者（协调者）- 执行者工作流的独特之处在于其动态任务分解能力。

中央编排者（协调者）LLM根据具体任务动态规划子任务，并将它们分配给专门的执行者LLM。

这种架构特别适合需要复杂协调的场景，如多文件代码修改或跨领域的分析任务。

在实际应用中，这种模式在复杂的软件开发任务中表现出色。

例如，当需要修改多个相关文件时，协调者可以分析依赖关系，规划修改顺序，并将具体修改任务分配给专门的执行者。

与简单的并行处理不同，这种模式能够处理任务间的复杂依赖关系。

评估者-优化者工作流：迭代提升的智慧

这种模式通过引入反馈循环来不断提升输出质量。

在评估者-优化者工作流中，一个LLM调用生成响应，而另一个在循环中提供评估和反馈。

使用时机：

当我们有明确的评估标准，且迭代优化能带来可衡量的价值时，这种工作流特别有效。

判断是否适合使用这种工作流有两个标志：

• 首先，当人类明确表达反馈时，LLM的响应能够明显改善；

• 其次，LLM能够提供这样的反馈。这类似于人类作者在创作精良文档时可能经历的迭代写作过程。

评估者-优化者工作流的实用示例：

• 文学翻译，其中译者LLM最初可能无法捕捉到的细微差别可以通过评估者LLM的有用批评来改进。

• 需要多轮搜索和分析才能收集全面信息的复杂搜索任务，其中评估者决定是否需要进行更多搜索。

The evaluator-optimizer workflow

这种工作流模式特别适用于需要高质量输出的场景，如文学翻译或复杂搜索任务。

在实践中，评估者LLM会根据预设标准对生成的内容进行评估，提供具体改进建议。

例如，在翻译任务中，评估者可能会指出原文的细微含义是否被准确传达，或是文化背景是否得到恰当处理。

这个过程类似于人类写作中的编辑流程：通过多轮审阅和修改来提升作品质量。

系统会在达到预设质量标准或完成指定迭代次数时停止优化过程。

这种模式的关键在于评估标准的设定和反馈的质量。

好的评估标准应该具体、可衡量，而反馈则需要既有建设性又足够具体，能指导生成器进行有效改进。

六、自主代理：走向真正的AI智能

6.1 自主代理的本质与实现

接下来是很多人关注的热点——自主代理（Autonomous Agents）。

随着LLM在关键能力上日趋成熟 —— 理解复杂输入、进行推理和规划、可靠地使用工具以及从错误中恢复，代理系统正在生产环境中逐渐兴起。

代理通过接收用户的指令或与用户进行交互对话来开始工作。

一旦任务明确，代理就会独立规划和运行，必要时会向用户寻求更多信息或判断。

在执行过程中，代理需要在每个步骤都从环境中获取"基准事实"（如工具调用结果或代码执行情况）来评估其进展。

Autonomous agent

这是AI代理系统中最复杂的形态。

自主代理是随着LLM核心能力的成熟而出现的高级形态：

理解复杂输入、推理规划、可靠使用工具、错误恢复。

它们通过与环境的持续交互获取"基础事实"，在执行过程中可以暂停等待人类反馈或处理阻碍。

典型应用包括：

1. SWE-bench任务解决，涉及多文件代码修改

2. 计算机使用任务，代理直接操作计算机完成任务

关键设计原则：

• 保持设计简单性

• 确保规划步骤透明

• 精心设计代理-计算机接口

6.2 自主代理的实现细节和最佳实践

自主代理系统实现的关键在于设计合理的控制流程和干预机制。

如图所示，整个执行过程包含多个关键节点：

1. 任务理解和规划：代理需要准确理解任务目标，制定执行计划

2. 控制点设置：在关键节点（C1-C3）设置检查点，用于验证执行进度和结果

3. 工具调用：通过清晰的接口文档和严格的测试确保工具使用的可靠性

4. 人工干预：预设明确的干预条件和机制，在必要时暂停执行等待人类反馈

与框架驱动的方法不同，这种实现更注重底层控制的直接性和透明性。

让我们看看自主代理的代码实现示例。

class AutonomousAgent:`    `def __init__(self, llm, tools, max_iterations=10):`        `self.llm = llm`        `self.tools = tools`        `self.max_iterations = max_iterations`        `self.execution_history = []``   `    `async def execute_task(self, task_description):`        `"""执行给定任务"""`        `plan = await self.create_plan(task_description)``   `        `for i in range(self.max_iterations):`            `# 检查点1: 任务理解和计划验证`            `if not self.validate_plan(plan):`                `await self.request_human_feedback("计划验证失败")`                `plan = await self.revise_plan(task_description)``   `            `# 执行当前步骤`            `step_result = await self.execute_step(plan.current_step)`            `self.execution_history.append(step_result)``   `            `# 检查点2: 执行结果验证`            `if not self.validate_step_result(step_result):`                `await self.handle_error(step_result)`                `continue``   `            `if self.is_task_complete(plan):`                `return self.compile_final_result()``   `        `return {"status": "max_iterations_reached", "history": self.execution_history}``   `    `async def create_plan(self, task_description):`        `"""使用LLM创建执行计划"""`        `prompt = self.create_planning_prompt(task_description)`        `response = await self.llm.generate(prompt)`        `return self.parse_plan(response)``   `    `async def execute_step(self, step):`        `"""执行单个步骤"""`        `tool = self.select_tool(step.tool_name)`        `try:`            `result = await tool.execute(step.parameters)`            `return {"status": "success", "result": result}`        `except Exception as e:`            `return {"status": "error", "error": str(e)}``   `    `async def handle_error(self, error_result):`        `"""错误处理逻辑"""`        `if self.can_auto_resolve(error_result):`            `await self.auto_resolve_error(error_result)`        `else:`            `await self.request_human_feedback(error_result)``   `    `def validate_step_result(self, result):`        `"""验证步骤执行结果"""`        `validation_prompt = self.create_validation_prompt(result)`        `validation_result = self.llm.generate(validation_prompt)`        `return self.parse_validation_result(validation_result)``   `    `async def request_human_feedback(self, context):`        `"""请求人类反馈"""`        `feedback_request = self.format_feedback_request(context)`        `return await self.human_interface.get_feedback(feedback_request)

这个实现展示了自主代理的一些核心组件：

• 任务规划和验证

• 执行步骤的循环控制

• 错误处理机制

• 人类反馈集成

在构建自主代理系统时，代码结构反映了人类决策的基本思维过程。

就像我们在解决复杂问题时会制定计划、执行操作、评估结果并根据需要调整策略，这个代理系统也遵循着相似的模式。

代码的设计体现了一种优雅的平衡：既要让代理拥有足够的自主性来处理复杂任务，又要确保其行为始终在可控范围内。

通过设置迭代上限，我们避免了代理陷入无休止的循环，就像给一个人设定任务期限一样。

在执行过程中，系统会在关键节点进行自我检查。

这些检查点就像是项目中的里程碑，帮助我们及时发现和纠正问题。

当遇到无法自行解决的情况时，代理会寻求人类的帮助，这种设计反映了人机协作的理想状态。

错误处理机制也非常人性化，系统会先尝试自行解决问题，就像一个经验丰富的工程师会先试着独立处理遇到的困难。

只有在确实需要时，才会请求外部协助。

同时，所有的执行历史都被完整记录，这对于后期分析和改进系统至关重要。

合理使用自主代理的时机

使用时机：

代理适用于难以或无法预测所需步骤数量的开放性问题，以及无法硬编码固定路径的场景。

LLM可能需要运行多个回合，因此您必须对其决策能力有一定程度的信任。

代理的自主性使其非常适合在可信环境中扩展任务。

代理的自主特性意味着更高的成本，以及错误累积的可能性。

我们建议在沙盒环境中进行广泛测试，并配备适当的安全防护措施。

自主代理最适合处理那些具有高度不确定性的复杂任务。

比如多文件代码重构，代理需要理解代码结构、确定修改范围，并在修改过程中持续验证系统完整性。

又如复杂的数据分析任务，需要根据阶段性发现来调整分析策略。

然而，使用自主代理也意味着更高的计算成本和更长的执行时间。

因此，最重要的是在系统设计初期就建立完善的安全机制和测试环境。

在实践中，我们应该从最简单的解决方案开始，只在确实需要时才考虑引入自主代理。

实践案例分析：代码编写与计算机使用

Anthropic 列举了2个实践案例，我们主要分析第2个案例

“我们的“计算机使用”参考实现，Claude 使用计算机来完成任务。”

High-level flow of a coding agent

这张图展示了代码编辑 Agent 系统的工作流程，我们可以看到整个过程分为两个主要循环：

第一个循环（Until tasks clear）:

• 用户提交查询后，系统通过接口与LLM交互

• LLM通过澄清和优化来确保理解用户意图

• Interface发送具体上下文给LLM

第二个循环（Until tests pass）:

• LLM搜索相关文件

• 环境返回文件路径

• LLM编写代码并获取执行状态

• 运行测试并根据结果进行迭代

这种精心设计的双层循环架构体现了系统的智能与稳健。

通过在任务理解和执行层面分别建立反馈循环，系统能够确保每个环节的准确性。

就像一个经验丰富的工程师，在动手之前会反复确认需求，在执行过程中也会不断验证结果。

持续的反馈机制让系统具备了自我纠正的能力，当发现偏差时能够及时调整。

这种设计特别注重人机协作的自然性，用户可以在任何阶段介入并提供指导，就像与一个细心的助手合作。

通过将复杂任务分解为连续的小步骤，系统能够在每个阶段都确保正确性，避免错误的累积效应。

正是这种周密的架构设计，让Claude能够像一个可靠的专业助手一样，稳妥地完成各种复杂的计算机操作任务。

这不仅提高了执行效率，更重要的是确保了任务完成的质量与可靠性。

七、构建之道：从模式到实践

这些构建模块并非强制性的规范。

它们是开发者可以根据不同用例来塑造和组合的常见模式。

与任何LLM功能一样，成功的关键在于衡量性能并迭代实现。

需要重申的是：

只有在确实能够改善结果的情况下，才考虑增加复杂性。

这段内容实际上揭示了构建AI系统的一个核心设计理念。

这里强调了一个重要观点：以上的工作流模式和构建模块并不是教条式的规则，而是可以灵活运用的工具。

就像在厨房里，厨师会根据不同的菜品选择和组合不同的烹饪方法，开发者也需要根据具体的应用场景来选择和组合应用这些模式。

在当前AI快速发展的背景下，报告对"复杂性"的思考尤其深刻。

我们经常看到开发者陷入一个误区：过度追求复杂的技术方案，仿佛系统越复杂就越先进。

然而报告提醒我们，增加复杂性必须有明确的目的性，只有当增加复杂性能带来明显的性能提升时，才应该这么做。

它应该服务于性能的提升，而不是为了复杂而复杂。真正的成功来自于对系统性能的准确衡量和持续迭代优化。

技术模式就像工具箱中的工具，关键在于如何根据实际需求选择合适的工具组合。

我们要找到那个最佳平衡点，在这个点上，系统的复杂度刚好满足业务需求，而不会过度工程化。

最终的目标不是构建出最复杂的系统，而是打造一个"恰到好处"的解决方案。

这种追求简约但不简单的设计思维，在当前不断追求更大规模计算集群和模型参数的AI领域显得尤为珍贵。

简单来说，这段话传达了这样一个信息：模式是工具而不是规则，要根据实际需求灵活运用，同时始终记住："够用就好"的原则。

八、总结与展望

在LLM领域取得成功并不在于构建最复杂的系统，而在于构建最适合您需求的系统。

从简单的提示开始，通过全面的评估来优化它们，只有在更简单的解决方案不足以满足需求时，才添加多步骤的代理系统。

在实现代理时，我们遵循三个核心原则：

• 保持代理设计的简单性

• 通过明确展示代理的规划步骤来确保透明度

• 通过全面的工具文档和测试来精心设计代理-计算机接口（ACI） 框架可以帮助您快速入门，但当转向生产环境时，不要犹豫于减少抽象层并使用基本组件构建。

通过遵循这些原则，您可以创建既强大又可靠、可维护，并能获得用户信任的代理系统。

回归本质：简约性的胜利

在当前AI技术快速迭代的时代，这份报告给我们带来了一个清醒的声音：回归本质。

成功并不在于堆砌最尖端复杂的技术，而是要找到最适合需求的解决方案。

这种思维方式让我想起了著名的"奥卡姆剃刀"原则：如无必要，勿增实体。 在LLM领域，这个原则再次展现。

报告建议我们从最简单的prompt开始，通过系统性的评估来逐步优化。

这种渐进式的方法不仅能帮助我们更好地理解问题本质，也能避免过度工程化带来的资源浪费。

正如报告中强调的简洁性原则，简单并不意味着能力的缺失，而是背后对问题本质的深刻理解。

未来发展：AI代理系统的新篇章

报告提出了构建Agent时应该遵循的三个核心原则：

• 首先是保持设计的简洁性。 这呼应了之前的讨论，简洁不等于简单，而是要做到精准而高效。

• 其次是重视透明性，要明确展示Agent的规划步骤。 这一点特别重要，因为它直接关系到系统的可理解性和可调试性。在实践中，我经常看到一些系统出现问题时很难定位原因，往往就是因为缺乏这种透明性。

• 第三是精心设计人机交互接口（ACI），并做好文档和测试工作。 这让我想起了人机交互（HCI）领域的经验，良好的接口设计和完整的文档对于系统的可用性和可维护性至关重要。

报告最后提到了框架的使用问题。框架确实能帮助快速起步，但在迈向生产环境时，不要犹豫于减少抽象层次，使用基础组件来构建。

这个建议非常实用，因为过多的抽象层可能会带来不必要的额外的复杂性和性能开销。

通过遵循这些原则，我们能够构建出既强大又可靠、可维护、可信赖的Agent系统。

感谢作者 Erik Schluntz 和 Barry Zhang 基于 Anthropic 的实践经验提出这些见解，为整个行业提供了宝贵的参考。

附录1：代理的实践应用

这个附录非常有趣，它展示了AI Agents在实际应用中最成功的两个领域。让我们深入解读一下。

首先，报告指出这两个应用领域之所以特别成功，是因为它们都具备四个关键特征：

需要对话和行动的结合、有明确的成功标准、能够形成反馈循环、以及包含有意义的人类监督。

这个框架非常重要，它为我们评估其他潜在的AI Agent应用场景提供了很好的参考标准。

在客户支持领域，AI Agent的应用非常适合更开放式的代理。

这让我想起了传统客服系统的局限性 - 它们要么过于简单，只能处理预设的问题，要么过于复杂，难以维护。

而现代AI Agent通过工具集成，优雅地解决了这个问题。它能够自然地进行对话，同时可以查询订单历史、访问知识库、处理退款等实际操作。

令人印象深刻的是，一些公司采用了基于成功解决率的计费模式，这种商业模式本身就证明了这类系统的有效性。

在代码开发领域，AI Agent的应用更加引人注目。

从简单的代码补全发展到现在能够自主解决问题，应该说2024年 AI 最大的进展之一就是在 AI 辅助编程方面了。

关键在于这个领域具备"可验证性" - 通过自动化测试，我们可以客观地验证代码是否正确工作。

这让AI Agent可以通过测试结果不断改进其解决方案。

Anthropic提到他们的Agent能够仅基于PR描述就解决实际的GitHub问题，这确实是一个重要的突破。

不过报告也很谨慎地指出，虽然自动化测试可以验证功能，但人类审查仍然是确保解决方案符合更广泛系统要求的关键。

这两个案例给我们的启示是，成功的AI Agent应用不仅需要技术上的可行性，还需要有清晰的价值主张和合适的应用场景。

附录2：工具的提示工程

附录2探讨了工具提示工程的重要性。

首先，这部分强调了一个关键观点：工具定义的提示工程与整体提示工程同样重要。

这很容易被忽视，因为我们往往过分关注主要提示，而忽略了工具接口的设计。

然而在实践中，工具接口的设计质量往往决定了Agent的实际表现。

报告指出了一个有趣的观点：

虽然同一个动作可以有多种指定方式（比如用diff或重写整个文件来指定文件编辑），但对LLM来说，不同格式的难度差异很大。

举个例子，要生成diff，模型需要提前知道要修改的行数；而在JSON中写代码比在markdown中写要复杂得多，因为需要处理转义字符。

对于工具格式的选择，报告给出了几个实用的建议：

• 给模型足够的"思考空间"，避免让它陷入困境

• 选择接近模型在互联网上常见的格式

• 避免复杂的格式要求，比如行数计数或字符转义

特别精彩的是报告引入了"agent-computer interfaces (ACI)"的概念，类比于人机交互(HCI)。

这个类比非常形象：既然我们在设计人机 UI 界面时会投入大量精力，那么设计 AI 代理与计算机的接口时也应该投入同等的努力。

报告还提供了一些具体的实践建议：

• 设身处地为模型考虑，评估工具的使用是否足够直观

• 通过优化参数名称和描述来提高可理解性

• 大量测试和迭代 - 运用防错设计（Poka-yoke）原则

最后，报告用一个实际案例做了说明：

在构建SWE-bench的Agent时，他们发现相对路径会导致问题，于是改用绝对路径，这个简单的改动就显著提高了模型的表现。

这个例子很好地说明了工具设计的细节如何影响整体效果。

我个人觉得这段内容特别有价值，它不仅提供了具体的指导原则，更重要的是提出了一个全新的视角：

将Agent工具接口设计提升到与人机交互设计同等重要的地位。

这对于构建更可靠的AI系统具有重要的指导意义。

那么您觉得这种将ACI与HCI类比的方式是否有助于我们更好地理解工具设计的重要性呢？欢迎在评论区留言讨论您的观点。

那么到这里，我的解读就全部完成了。

作为这个领域的初学者、研究者和实践者，

我认为这份报告不仅提供了实用的技术指导，

更重要的是提供了一个清晰的思维框架，有助于我们在复杂的AI技术浪潮中找到正确前行的方向。

在未来的AI系统开发和实践中，这些原则和方法或许将会发挥重要的指导作用。

如何学习大模型 AI ？

由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。

但是具体到个人，只能说是：

“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。

这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。

我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。

我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。

第一阶段（10天）：初阶应用

该阶段让大家对大模型 AI有一个最前沿的认识，对大模型 AI 的理解超过 95% 的人，可以在相关讨论时发表高级、不跟风、又接地气的见解，别人只会和 AI 聊天，而你能调教 AI，并能用代码将大模型和业务衔接。

• 大模型 AI 能干什么？
• 大模型是怎样获得「智能」的？
• 用好 AI 的核心心法
• 大模型应用业务架构
• 大模型应用技术架构
• 代码示例：向 GPT-3.5 灌入新知识
• 提示工程的意义和核心思想
• Prompt 典型构成
• 指令调优方法论
• 思维链和思维树
• Prompt 攻击和防范
• …

第二阶段（30天）：高阶应用

该阶段我们正式进入大模型 AI 进阶实战学习，学会构造私有知识库，扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架，抓住最新的技术进展，适合 Python 和 JavaScript 程序员。

• 为什么要做 RAG
• 搭建一个简单的 ChatPDF
• 检索的基础概念
• 什么是向量表示（Embeddings）
• 向量数据库与向量检索
• 基于向量检索的 RAG
• 搭建 RAG 系统的扩展知识
• 混合检索与 RAG-Fusion 简介
• 向量模型本地部署
• …

第三阶段（30天）：模型训练

恭喜你，如果学到这里，你基本可以找到一份大模型 AI相关的工作，自己也能训练 GPT 了！通过微调，训练自己的垂直大模型，能独立训练开源多模态大模型，掌握更多技术方案。

到此为止，大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗？

• 为什么要做 RAG
• 什么是模型
• 什么是模型训练
• 求解器 & 损失函数简介
• 小实验2：手写一个简单的神经网络并训练它
• 什么是训练/预训练/微调/轻量化微调
• Transformer结构简介
• 轻量化微调
• 实验数据集的构建
• …

第四阶段（20天）：商业闭环

对全球大模型从性能、吞吐量、成本等方面有一定的认知，可以在云端和本地等多种环境下部署大模型，找到适合自己的项目/创业方向，做一名被 AI 武装的产品经理。

• 硬件选型
• 带你了解全球大模型
• 使用国产大模型服务
• 搭建 OpenAI 代理
• 热身：基于阿里云 PAI 部署 Stable Diffusion
• 在本地计算机运行大模型
• 大模型的私有化部署
• 基于 vLLM 部署大模型
• 案例：如何优雅地在阿里云私有部署开源大模型
• 部署一套开源 LLM 项目
• 内容安全
• 互联网信息服务算法备案
• …

学习是一个过程，只要学习就会有挑战。天道酬勤，你越努力，就会成为越优秀的自己。

如果你能在15天内完成所有的任务，那你堪称天才。然而，如果你能完成 60-70% 的内容，你就已经开始具备成为一名大模型 AI 的正确特征了。

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】