MacOS 26.1 Tahoe Upgrade

Overview

1. What are agents? 什么是智能体?
2. When (and when not) to use agents? 何时使用智能体以及何时不使用智能体?
3. When and how to use frameworks? 何时以及如何使用框架?
4. Build Block: The augmented LLM
5. Workflow 工作流
6. Agents 智能体
7. Principles for Building effective agents 构建高效智能体的原则
8. Agents in practice：Agent 应用实践
9. Prompt engineering your tools 工具的提示词工程

What are agents? 什么是智能体?

Agent 有不同的定义，但最关键理解是要和 workflow 区分开来

Workflows are systems where LLMs and tools are orchestrated through predefined code paths.
Agents, on the other hand, are systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks.

intuitively, 1. agent 本质就是一个 The augmented LLM 增强版大语言模型, 除了对话以外，必须实现三种能力: 检索、调用工具、读写记忆 2. 理解 agent 本质, 通常需要区分下 workflow/agent: workflow 一定按照固定的、编排好的 llm 执行和工具执行路径; agent 是: llm 动态指导自己的执行流程和工具的使用, 没有完全固定、明确的执行路径 ## When (and when not) to use agents? 何时使用智能体以及何时不使用智能体? 1. 使用 LLM 构建应用的时候，有个原则是 **永远用最简单的方法解决问题, 能不增加复杂性绝不增加复杂性** 2. 构建 agent 应用一定会带来性能的约束，需要延时或者成本代价 3. 当任务具备很强的复杂性, 工作流能为任务带来可预测性相对比较好把控; 但是如果需要更多为了达成目标的能力灵活性，或者需要依靠模型自己来决策一些事的时候, 就搭建 agent 4. 对于很多任务而言，检索 + few-shot 能直接完成任务 ## When and how to use frameworks? 何时以及如何使用框架? 1. Agent 有很多框架, 让入门非常轻松 2. 但其实很多 Agent 几行代码就能实现逻辑, 因此入门学习的时候，直接手撸; 后续可以考虑用框架，但需要理解底层原理，不然出错不容易发现 ## Build Block: The augmented LLM

1. 如何构建三件套: 检索、调用工具、读写记忆? 主要关注两个方面
   1. 定义接口
   2. 定义接口文档

接下来我们分别介绍 WorkFlow 和 Agent

Workflow 工作流

Workflow: Prompt chaining 工作流：提示词链

1. Prompt chain 把一项任务分解成一系列的步骤, 每次调用都会处理前一个的输出 2. 什么时候要用 Prompt chain ? 整体任务是能明确、清晰地分解的, 举例如下: 1. 生成营销文案 => 然后将其翻译成另一种语言 2. 撰写文档提纲 => 检查该提纲是否符合特定标准 => 然后根据提纲撰写文档 ### Workflow: Routing 工作流：路由

1. 路由是 Workflow 中一种更高级的机制，对输入进行分类，然后分别指向特定的任务 2. 复杂的任务中，任务存在着明显的区别，分开这些任务单独处理会更好, 举例: 1. 不同的业务任务流拆分: 将不同类型的客户服务查询（一般问题、退款请求、技术支持）分配到不同的下游流程、提示和工具中 2. 不同的任务复杂度下的模型性能适配: 将简单/常见问题分配给更小、更具成本效益的模型; 将困难/特殊问题分配给更强大的模型，以实现最佳性能优化 ### Workflow: Parallelization 工作流：并行化

1. LLM 可以并行处理多个任务, 主要的并行化有两类常见场景: 1. Sectioning (分段): 一个任务拆成多项可以并行的子任务 2. Voting (投票): 多次执行相同的任务，目标获得多样化的输出 2. 什么时候需要并行化? 1. Sectioning: 安全机制中，一个模型用来相应请求，另一个模型同时用来检测不当内容或者请求; 自动化评估中，通常并行评估模型的不同方面的能力 2. Voting: 代码审查任务中，用不同的 prompt 并行进行审查; 采用多个提示词评估不同方面; ### Workflow: Orchestrator-workers 工作流：编排器-工作器

1. 编排器-工作器是一种典型的 workflow，中央模型会动态分解任务，然后各个模型处理任务，最终综合合并下最终结果 2. 什么时候使用编排器-工作器 ? 有些非常复杂任务，需要开几个子任务是没法确定的; 1. 比如一个写代码任务, 里面有多个代码文件，需要更改的文件数量不太好确定, 这个问题其实是需要一个编排器来分配的 2. 搜索任务，涉及到从多个来源收集和分析信息，但不能依靠人工去分割子任务 ### Workflow: Evaluator-optimizer 工作流：评估器-优化器

1. 评估器-优化器也是一种典型的 workflow, 一个 LLM 提供响应，另一个 LLM 提供评估 2. 什么时候用 评估器-优化器 workflow? 我们有很明确的评估标准，且迭代优化能带来可衡量的价值的时候; 其实就是依赖 "人首先能说清楚这个回复不好在哪" 且 " LLM 能给出来这种好或者不好的明确反馈", 典型例子: 1. 文学翻译中，翻译 LLM 最初可能无法捕捉到一些细微差别，但 评估 LLM 可以提供有用的改进意见 2. 需要多轮搜索和分析来收集全面信息的复杂搜索任务，评估者会在这类任务中判断是否有必要进一步搜索 ## Agents 智能体

1. Agent 和 Workflow 的关键区别在于: agent 在一个和环境交互的循环中根据反馈换着使用工具 2. 细微对比下什么时候非要要用 Agent? 1. 无法一步确定需要几步才能完成任务 2. 完成这件事需要经过什么步骤没那么清晰, 比如写代码, 其实怎么写都行

Principles for Building effective agents 构造智能体的原则

Agent 做成事情关键认知:

1. 没有固定的 agent 构建套路, 要灵活、自由地组合上面的方法
2. agent 本质上还是个 LLM，只不是增强版 LLM
3. 把一个事情做事的关键: 仍然是在于有效衡量模型 performance 以及衡量迭代改进带来的变化
4. 只有引入复杂性能明确带来更显著变好效果的时候，我们搞 workflow/agent; 不然就不做，否则白白引入复杂性

实操层面 Agent 做成的三个原则:

Maintain simplicity in your agent’s design.
Prioritize transparency by explicitly showing the agent’s planning steps.
Carefully craft your agent-computer interface (ACI) through thorough tool documentation and testing.

Agent 最关键的三个原则:

1. 设计最简化, 复杂化就是给自己挖坑
2. 要清清楚楚明明白白打出来具体的规划过程, 不黑盒化任何步骤
3. 细扣工具文档和测试: 工具文档要详细，测试要全面细致

Agents in practice：Agent 应用实践

Agent 最合适的实践场景

1. Customer support 客户支持: 客户支持将常见的聊天机器人界面与通过工具集成获得的增强功能相结合。这对于更具开放性的智能体来说是很自然的契合

   1. 支持性互动自然地遵循对话流程，同时需要获取外部信息和执行操作
   2. 可以集成工具来提取客户数据、订单历史和知识库文章
   3. 诸如退款或更新工单等操作可通过编程方式处理
   4. 成功可以通过用户定义的解决方案来清晰衡量

2. Coding agents 编码智能体

   1. 代码解决方案可通过自动化测试进行验证
   2. 智能体可以利用测试结果作为反馈来迭代解决方案
   3. 代码问题空间定义明确且结构清晰
   4. 输出质量可以客观衡量

Prompt engineering your tools 工具的提示词工程

一些通用的 Agent PE 原则

1. 给模型足够的 token，让它在陷入困境之前有时间”思考”
2. 保持输入格式一致性，输入格式别太格式化、模板化;
3. 确保没有格式上的 “额外负担”，例如必须准确统计数千行代码的数量，或者对其编写的任何代码进行字符串转义
4. 一个经验 PE 法则: 人费多大劲能看懂，模型就得用多大劲能看懂；比如写的太粗糙简略，人都看不懂，不能指望模型分分钟看懂；是个人都能看懂，那模型大概率等分钟看懂；
   1. 仅仅根据描述和参数，是一目了然还是得细细琢磨？
   2. 好的工具定义应该至少包含介绍、实例、corner case、输入格式要求
   3. 不遗余力优化参数名的定义和描述的定义
   4. 测试工具使用，给一大堆测试输入，看看会犯什么错
   5. 在优化工具上的时间比优化 PE 时间更多
   6. 用防错设计 Poka-yoke 替代原始设计, 例如

原始设计:

def get_weather(location: str, unit: str):
    """
    获取天气信息。
    location: 城市名
    unit: 单位（必须是 'C' 或 'F'）
    """

防错设计: 用枚举值代替参数值，提供默认值，让错误输入自动被拒绝, 模型几乎无法生成无效参数，调用成功率显著提升

from typing import Literal
def get_weather(
    location: Literal["Beijing", "Shanghai", "New York", "San Francisco"],
    unit: Literal["C", "F"] = "C"
):
    """
    获取天气信息。
    """

Reference

[1]. Building effective agents

---

转载请注明来源 goldandrabbit.github.io