AI Agents¶

本篇文章主要阅读收集关于ai agent的相关内容，调研学习为目的。

Building effective agents¶

Workflow and Agents¶

Workflow: 预先定义好执行路径和orchestrator，在每个环节调用LLMs和tools
Agents: 没有预先定义的路径，LLMs动态指导处理和工具调用，LLM控制如何完成任务

之前我经常提的，SOP其实是让agents的模型按照一套固定流程“自主”完成任务，在这个场景下，做成workflow会更好么，需要更多的evaluation。

文章建议保持解决方案简洁，只在迫不得已时引入复杂度。

When building applications with LLMs, we recommend finding the simplest solution possible, and only increasing complexity when needed.

agents系统主要在latency, cost 和系统表现之间做tradeoff。

当问题变得复杂的时候，workflow确定性和一致性更高，而agents面对灵活性和需要做决定的规模场景下表现更好。

在规模化处理问题的时候，每个需要决策的环节都让人参与来做决定是不现实的，所以这里引入模型这个不确定的要素对解决问题是必要的，也是workflow解决不了的。

Framework Usages¶

有很多agents framework, 这些框架把agents的基本能力做了封装，也创建了新的封装.

新的封装带来了新的复杂度，anthropic的作者（2024年）建议实现自己的agents，直接处理LLM APIs，实现代码并不是一件复杂的事情。这里我觉得要具体的来看，一个常见的问题是框架提供了开箱即用的功能，并不需要处理这些琐碎的事情。另外就是“你做的再好还能做的过claude code/codex”这个说法。

我现在的想法主要是如何去测试下面的agents实现，因为对于claude agent SDK来说，下方的claude code并不一定是最适合特定场景的engine，具体见我关于测评的思路论述。

Blocks and workflows¶

这里引入了一堆概念.

block: 增强版LLM

简单来说，就是给LLM装了查询，工具调用和memory机制的一个集合。

The basic building block of agentic systems is an LLM enhanced with augmentations such as retrieval, tools, and memory.

workflow：链式prompt

把任务拆成一系列的子步骤，然后不断的用LLM来处理，通过gate程序化验证结果觉得是否流转。这里就是workflow，之前我在我们组的agents也做过这个内容。

Prompt chaining decomposes a task into a sequence of steps, where each LLM call processes the output of the previous one.

Workflow Routing

这个也比较常见，就根据情况来分发下面具体使用的agents.

Routing classifies an input and directs it to a specialized followup task.

Workflow Parallelization

这里主要讲述如何并发的触发多个内容，主要目标是为了加速，然后后面放一个aggregator 就可以了。注意这里的tasks是predefined。

Workflow Orchestrator-workers

这个也是开启了多个LLM calls来做，需要注意的是这个和并发的不同，因为他不预先定义潜在的任务类型。

Workflow: Evaluator-optimizer

当有明确的可量化的评价体系的时候，可以在llm generator和evaluator之间反复流转，让内容持续变好。

In the evaluator-optimizer workflow, one LLM call generates a response while another provides evaluation and feedback in a loop.

Agents¶

Workflow 需要人来设计流程，根据场景的不同流程可能会很复杂，主要的复杂度在于人。而agents就需要模型的能力了，作者提到主要取决于理解复杂任务，推理和计划能力。

Agents are emerging in production as LLMs mature in key capabilities—understanding complex inputs, engaging in reasoning and planning, using tools reliably, and recovering from errors.

对于agent本身的实现是很简单的，正如我之前读codex的代码，主要复杂的其实是如何和环境environment打交道，而不是处理LLM的决定等信息。

agent的应用场景是(1) 执行步骤不确定; (2) 无法预测固定路径; 时可以参考的，因为这个时候workflow无法解决这种复杂的场景，因为workflow本质上就是尝试把执行放在一个确定的路径上执行，这是workflow本身的特性。

Demystifying evals for AI agents¶

https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents

本篇内容主要阐述如何对agents做eval，尤其是对多步骤，对外部产生影响的内容做测试。

Eval Terminology¶

task: 测试的基本单位，定义输入和成功的标准
trail: 每次跑一次测试的行为叫做trial，通常来说会跑多个trail来得到一致性更高的场景
garder: 从某些标准给agents表现评分，一个task会有多个graders，grader里面会有多个assertions（或者叫做checks）
transcript(trace/trajectory): trial的完整记录
outcome: 环境的最终状态
evaluation harness: 跑e2e eval的技术设施
agent harness: 让一个模型作为agents来跑，比如说claude code就是agent harness，
evaluation suite: 用来衡量特定能力行为的tasks集合

Graders and Evals¶

文章列出了很多graders，比如Code-based graders;Model-based graders;Human graders. 具体的不详细列举，但anyway这些都是一些评分的方法。

Evals 可以分为两种，测试功能本身以及regression的测试，没什么新奇的。

Evaluating 具体的agents¶

code agents benchmark: SWE-bench Verified and Terminal-Bench
Conversational agents: 对话agents有自指的问题, 也就是说和他对话本身也是测试的一部分，所以说需要第二个LLM来扮演用户，这个方式在deepeval框架里也有体现。

the quality of the interaction itself is part of what you're evaluating.

测试集合的话用 \(\tau\)-Bench and its successor, \(\tau^2\)-Bench.

Research agents: 研究型agents的主要问题在于判断标准难，只能通过相对task的程度来判断outcome是否是好的，然后不同的人对如何定义是好的也有不同。测试集合比如 BrowseComp.

computer use agents 略过，不是主要关注对象。

不确定性的处理¶

LLM本身就意味着不确定性，所以说不同run之间差距可能会很大；比如说一个agent可能第一次90%成功，第二次30%成功。为了衡量这种不确定性的分布，通常来说有几种办法:

pass@k: measures the likelihood that an agent gets at least one correct solution in k attempts.
pass^k: measures the probability that all k trials succeed.

pass@k来衡量是否有一次成功，pass^k 关注行为是否一致。

构建eval实践¶

这里有很多步骤，如图：

这里列出比较重要的是：

构建平衡的测试，描述should和shouldn't发生的行为，这样可以避免class-imbalanced eval.
选graders的一些建议，etc, 但工程上可能重用已有实现，并且关注真正实践效果。