如何构建有效的 AIAgents：化繁为简——深度解读 Claude 实践《Building effective agents》(下)

本文由 简悦 SimpRead 转码， 原文地址 mp.weixin.qq.com

在前文《如何构建有效的 AIAgents：化繁为简——深度解读 Claude 实践《Building effective agents》(上)》中，我们深入探讨了 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（Large Language Model）。

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

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

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

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

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

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

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

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

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

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

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

增强型 LLM 系统架构

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

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

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

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

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

  1. 以及如何确保 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 任务解决，涉及多文件代码修改
    1. 计算机使用任务，代理直接操作计算机完成任务

关键设计原则：

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

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

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

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

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

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

  4. 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）:

第二个循环（Until tests pass）:

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

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

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

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

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

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

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

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

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

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

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

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

需要重申的是：

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

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

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

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

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

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

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

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

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

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

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

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

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

八、总结与展望

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

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

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

• 保持代理设计的简单性

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

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

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

回归本质：简约性的胜利

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

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

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

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

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

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

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

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

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

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

通过遵循这些原则，我们能够构建出既强大又可靠、可维护、可信赖的 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 代理与计算机的接口时也应该投入同等的努力。

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

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

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

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

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

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

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

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

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

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

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

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

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

全文完。