谈谈 `AI Agent`（智能体）

• 能利用LLM来管理工作流执行并做出决策，它能识别工作流何时完成，并能在需要时主动纠正其行为，如果失败，它可以停止执行并将控制权交还给用户。
• 能够访问各种工具以与外部系统交互（既能获取上下文，也能采取行动），并根据工作流的当前状态动态选择适当的工具，始终在明确定义的安全内运行。

是不是现在智能体很多，所有的工作都用智能体来解决？
智能体适合那些传统的、确定性的、基于规则的方法难以处理的工作流，所以对于能通过一些确定性编程或者流程就能解决的，其实不太需要智能体。
以支付欺诈分析为例，传统的规则引擎就像一个检查清单，根据预设标准标记交易，相比之下，LLM智能体更像一位经验丰富的调查员，评估上下文，考虑细微模式，即使在没有明确违反规则的情况下也能识别可疑活动，这种细致的推理能力正是智能体能够有效管理复杂、模糊情况的关键。
所以在评估智能体可以在哪些地方的确有价值，请优先考虑那些以前难以自动化、尤其是传统方法遇到阻力的工作流：

• 复杂决策：涉及细微判断、例外情况或上下文敏感决策的工作流。
• 难以维护的规则：由于规则集庞大且复杂而变得笨重、更新成本高昂或容易出错的系统。
• 重度依赖非结构化数据：涉及解读自然语言、从文档中提取含义或与用户进行对话式交互的场景。

• 模型：为智能体的推理和决策提供动力的LLM，决定了智能体的下限。
• 工具：智能体可用于采取行动的外部函数或API。
• 指令：定义智能体行为的明确指导方针和安全策略。

样例代码：

• 建立评估体系以确定性能基线。
• 专注于使用可用的最佳模型达到您的准确率目标。
• 在可能的情况下，用更小的模型替换更大的模型，以优化成本和延迟。

• 类型描述示例数据工具：使智能体能够检索执行工作流所需的上下文和信息，比如查询交易数据库或CRM等系统，读取PDF文档，或搜索网络。
• 行动工具：使智能体能够与系统交互以采取行动，例如向数据库添加新信息、更新记录或发送消息，发送电子邮件和短信，更新CRM记录，将客户服务工单转交给人工。
• 编排工具：智能体本身可以作为其他智能体的工具，作为多智能体系统中单个 。

• 利用现有文档：在创建流程时，使用现有的操作程序、支持脚本或策略文档来创建，例如  提出的 ，其他模型比较通用的  等。
• 提示智能体分解任务：从密集的资源中提供更小、更清晰的步骤，有助于最小化歧义，并帮助模型更好地遵循指令。
• 定义清晰的动作：确保流程中的每一步都对应一个特定的动作或输出，例如，一个步骤可能指示智能体向用户询问订单号，或调用API来检索账户详情，明确说明动作（甚至面向用户消息的措辞）可以减少解释错误的空间。
• 控制边界处理：现实世界的交互经常会产生决策点，例如当用户提供不完整信息或提出意外问题时如何继续，一个健壮的流程应预见常见的变体，并包含如何处理它们的指令，例如使用条件步骤或分支（如果缺少必要信息，则执行替代步骤）。

 为了和多个其他系统交互，衍生了两种系统交互的协议， 和 。

 在之前的文章已经讲过了（mp.weixin..com/s/qHfSbSjox… LLM 提供上下文的方式， 提供了一种将模型连接到资源、提示和工具的标准化方式。

样例代码如下：

以上代码是汇率的 ，通过  可以获取汇率数据。

A2A的工作原理：

• 发现：使用标准化的  查找其他智能体技能  和功能 ；
• 协议：安全的交换消息和数据；
• 协作：委派任务给到相应技能的  并协调行动；

样例代码如下：

单智能体的智能大部分场景下依赖基座模型，在处理明确问题时较为高效，对于约束性任务时较为准确，并且可以进行回测，但面对复杂、多领域任务时，其能力往往受限。

样例代码如下：

• 当用户提交查询时，系统会创建一个主智能体，该智能体进入迭代任务流程。
• 主智能体首先会思考任务方法，并将计划保存到内存中以持久化上下文信息，因为如果上下文窗口超过 20 万个标记，LLM会信息遗忘或者截断，所以保留计划至关重要。
• 然后，它会创建专门的子智能体，每个子智能体负责特定的任务。
• 每个子智能体独立执行网络搜索，使用交错思维评估工具结果，并将结果返回给主智能体。
• 主智能体综合这些结果，并决定是否需要进行更多任务 —— 如果需要，它可以创建更多子智能体或优化其策略。
• 一旦收集到足够的信息，系统就会退出循环，并将所有结果传递给引文智能体。
• 引文智能体处理文档和报告，以确定具体的引文位置，最终的结果（包括引用）将返回给用户。

样例代码如下：

在传统软件中，一个错误可能会导致功能失效、性能下降或系统宕机，而在智能体系统中，微小的变化也会引发巨大的行为改变，这使得为需要在长时间运行的进程中维护状态的复杂智能体编写代码变得异常困难，那我们应该怎么做？

• 智能体是有状态的，错误会不断累积，我们需要做好容错和沙盒环境。
  智能体可以长时间运行，并在多次工具调用中保持状态，这意味着我们需要持久地执行代码，并在执行过程中处理错误，如果没有有效的缓解措施，即使是轻微的系统故障也可能对智能体造成灾难性后果，当错误发生时，我们不能简单地从头开始：重启成本高昂，因此我们需要构建可以从错误发生时智能体所在位置恢复运行的系统。
  
  
• 构建完整的可观测系统，如果某个智能体不符合预期，应该分析原因。
  智能体会做出动态决策，即使提示信息完全相同，每次运行的结果也并不确定，这使得调试更加困难，智能体使用了错误的搜索查询？选择了不合适的数据源？还是遇到了工具故障？添加完整的生产环境跟踪功能后，我们能够诊断智能体故障的原因并系统地修复问题，除了标准的可观测性之外，我们还监控智能体的决策模式和交互结构，这种高层次的可观测性帮助我们诊断根本原因、发现异常行为并修复常见故障。
  
  
• 智能体同步执行会造成瓶颈，尽可能使用并行处理。
  主智能体同步执行子智能体，等待每组子智能体完成任务后再继续执行下一个，这简化了协调，但也造成了智能体间信息流的瓶颈，例如，主智能体无法控制子代智能体，子智能体之间也无法协调，整个系统可能会因为等待单个子智能体完成搜索而被阻塞，异步执行可以实现更高的并行性：智能体可以并发工作，并在Agent 智能体需要时创建新的子智能体，当然这种异步性也带来了结果协调、状态一致性和错误在子智能体间传播方面的挑战。
  
  
• 智能体的可测试性在线上运行十分重要。
  传统的软件对一些子功能我们通常会进行单元测试，这个功能点同样适用于构建的智能体，特别是对于那些希望输入和输出需要保持一致性的智能体系统，那该如何实现？首先智能体功能测试不应该依赖单个大模型；其次将功能测试用例拆分输入和预期输出，对于一些强校验的功能，智能体调用子智能体和系统API的所有的输出应该保持预期测试执行流程一致，才算通过测试用例；最后大模型多次对相同的输入不一定获得相同的结果，所以测试用例应该是多次运行，通过率应该通过次数/执行次数的方式来统计。