这段视频由Anthropic公司Claude Relations部门的Alex，以及分别来自研究团队和“应用于视觉”团队的Eric和Barry组成，深入探讨了构建有效的AI代理的复杂性。他们详细阐述了最近一篇关于此主题的博客文章，区分了工作流程和真正的代理，并为涉足代理开发的开发者提供了实用的建议。 Eric首先澄清了代理的定义，将其与简单的工作流程区分开来。虽然很多人随意地将任何涉及多次调用LLM（大型语言模型）的系统称为“代理”，但该团队澄清说，代理的特征在于其自主性。它通过迭代循环运作，由LLM的决策引导，直到任务完成。步骤的数量不是预先确定的，这与工作流程形成鲜明对比，后者遵循固定、预定义的路径。代理会根据情况调整其方法，使其适合于客户支持或代码迭代等任务，在这些任务中，解决过程是可变的。 Barry解释说，工作流程和代理之间的区别是在模型变得更加复杂后出现的。最初，使用的是单个LLM，后来发展为利用代码编排的多个LLM的系统。这种演进揭示了两种不同的模式：工作流程，它们是高度编码和编排的；以及代理，它们更简单，但具有不同类型的复杂性。模型能力的提升促使团队正式定义了“代理”一词，并将其与工作流程区分开来。 在实践中，Eric解释说，这种差异体现在提示（prompt）级别。工作流程提示按顺序结构化，一个提示的输出以线性方式输入到下一个提示中。每个提示都有特定的目的，例如对用户问题进行分类。相比之下，代理提示是开放式的，它为模型提供了各种工具和资源，例如网络搜索或代码编辑，以实现目标。 Barry分享了一个来自他的入职经历的幽默轶事：他被安排运行OS World，这是一个计算机用户基准测试。面对反直觉的代理行为，他和一位同事通过闭上眼睛，短暂地瞥一眼屏幕来模拟模型的有限视角，模仿模型的输入。这个练习强调了同理心和向模型提供充足上下文的重要性。 Eric强调，在设计工具时，需要考虑模型的视角。开发者经常创建美观、详细的提示，但忽略了充分记录提供给模型的工具，这可能会导致过程中的困难。他强调，一个工具需要像为人类工程师准备的那样，为模型提供良好的文档。 然后，对话转向了代理技术的现状，讨论了其过度炒作和被低估的方面。Eric认为，被低估的方面是自动化任务，即使是很小的任务，也能节省人们的时间。自动化这些任务可以改变完成这些事情的频率。Barry指出，校准真正需要代理的地方很困难，需要找到一个有价值的、复杂任务的“最佳点”，在这些任务中，出错的代价相对较低。他以编码和搜索为例。 Barry解释了编码代理的潜力，强调了它们可以通过单元测试进行验证。编码代理的成功取决于用于向模型提供反馈的单元测试的质量。Eric同意，并认为改进代理性能将回归到验证。他们建议专注于添加对你真正关心的内容的测试，以便模型本身可以测试这些内容，并在返回给人类之前知道它是正确的还是错误的。 展望2025年，Barry设想了多代理环境，其中多个AI代理进行交互和协调。他提到了一个实验，其中多个“Claude”模型玩一个基于文本的社交演绎游戏“狼人杀”，以探索代理交互。虽然单个代理还需要在生产中展示许多成功的应用，但它可能是下一代模型的一个潜在扩展。Eric预测，越来越多的企业会采用代理来自动化重复性任务。他对面向消费者的代理处理度假计划等复杂任务持怀疑态度，因为难以指定偏好以及出错的风险很高。 最后，发言者为有兴趣进行代理开发的开发者提供了建议。Eric建议专注于可衡量的结果，以便获得关于所构建的东西是否有效的反馈。Barry建议从尽可能简单的事情开始，并逐渐增加复杂性。他们都强调构建一些可以随着模型变得更智能而改进的东西的重要性。

The video features Alex from Claude Relations at Anthropic along with Eric and Barry from the research and Apply to the Eye teams, respectively, diving into the intricacies of building effective AI agents. They elaborate on a recent blog post about the same, distinguishing between workflows and true agents, and offer practical advice for developers venturing into agent development. Eric begins by clarifying the definition of an agent, differentiating it from a simple workflow. While many loosely apply the term “agent” to any system involving multiple LLM (Large Language Model) calls, the team clarifies that an agent is characterized by its autonomy. It operates through iterative loops, guided by the LLM's decision-making, until a task is resolved. The number of steps is not predetermined, contrasting sharply with workflows, which follow a fixed, pre-defined path. An agent adapts its approach based on the situation, making it suitable for tasks like customer support or code iteration, where the resolution process is variable. Barry explains that the distinction between workflows and agents emerged as models became more sophisticated. Initially, single LLMs were used, evolving into systems utilizing multiple LLMs orchestrated in code. This progression revealed two distinct patterns: workflows, which are heavily coded and orchestrated, and agents, which are simpler yet possess a different kind of complexity. The rising capabilities of models prompted the team to formally define the term “agent” and differentiate from workflows. In practical terms, Eric explains that the difference manifests at the prompt level. A workflow prompt is structured sequentially, with the output of one prompt feeding into the next in a linear fashion. Each prompt has a specific purpose, such as categorizing a user question. In contrast, an agent prompt is open-ended, providing the model with a variety of tools and resources, such as web search or code editing, to achieve a goal. Barry shares a humorous anecdote from his onboarding experience, tasked with running OS World, a computer user benchmark. Faced with counterintuitive agent behavior, he and a colleague simulated the model's limited perspective by closing their eyes and briefly glimpsing the screen, mimicking the model's input. This exercise highlighted the importance of empathy and providing ample context to the model. Eric emphasizes the need to consider the model’s perspective when designing tools. Developers often create beautiful, detailed prompts but neglect to adequately document the tools provided to the model, which can cause difficulty in the process. He stressed that a tool needs to have good documentation for the model as it would for a human engineer. The conversation then transitions to the current state of agent technology, addressing both its overhyped and underhyped aspects. Eric suggests that the underhyped aspect is the automation of tasks, even small ones, that save people time. Automating these tasks can change the dynamics of how often these things can be done. Barry points out the difficulty in calibrating where agents are truly needed, identifying a "sweet spot" of valuable, complex tasks where the cost of error is relatively low. He cites coding and search as examples. Barry explains the potential of coding agents, highlighting their verifiability through unit tests. The success of coding agents depends on the quality of the unit tests used to provide feedback to the model. Eric agrees and suggests that improving agent performance will come back to verification. They propose focusing on ways to add tests for the things that you really care about so that the model itself can test this and know whether it's right or wrong before it goes back to the human. Looking ahead to 2025, Barry envisions multi-agent environments, where multiple AI agents interact and coordinate. He mentions an experiment where multiple "Claude" models play a text-based social deduction game, "Werewolf," to explore agent interaction. While single agents still need to show a lot of successful applications in production, it would be a potential extension with the next couple of generations of models. Eric predicts increased business adoption of agents to automate repetitive tasks. He expresses skepticism about consumer-facing agents for complex tasks like vacation planning, due to the difficulty of specifying preferences and the high risk of errors. Finally, the speakers offer advice for developers interested in agent development. Eric advises focusing on measurable results to get feedback about whether what is being built is working. Barry recommends starting as simple as possible and building complexity gradually. They both emphasize the importance of building something that can improve as models get smarter.