下面是个人对于agent的一些理解与描述
定义
agent是能代表个体进行一系列独立任务的工具
(具有一个核心的特征,能够代表用户完成一系列操作)
核心实现
- 利用大模型LLM管工作流并做出决策,并且能够主动优化和调整工作流程,并能识别到何时完成
- 如果出现故障,能够暂停并交还控制权
- 利用外部工具与外部系统进行交互(
其实就是能够阅读上下文和调用工具)
适用场景
- 复杂的决策
- 难以维护的规则
- 高度依赖非结构化的数据
agent的设计
agent的主要部分
- 模型
- 工具
- 说明书
从代码角度出发
- 名字
- 系统设定提示词
- 工具列表
模型选择
- 最好的解决最精确的问题
- 用小模型替代大模型,优化成本和延迟
- 评估模型处理问题中所需要的绩效曲线
工具选择
Data:数据(如何获取上下文,有效处理信息)Action:行动(交互的一系列操作)Orchestration:配器(作为其他agent的工具进行迭代使用)
指令配置
(高质量的指令能够优化决策,并减少歧义)
- 使用现有的业务逻辑将其结构化后提供给LLM模型
- 拆解任务,拆分为小的清晰的指令
- 明确任务内容定义,每一步指令都有对应的操作和输出
- 对于不符合预期情况的变化,能够有对应的说明和操作指导
如何完成一个完整的agent设计?
采用逐步迭代的方式,将一个完整的agent拆分为多个小的agent协同工作的多agent系统
编排模型
- 单一agent + 单一的工作流
- 多agent +协同多工作流
单一agent设计
设计基本构想
通过逐步添加工具处理任务保持复杂度的可控性,简化了评估和维护,并且通过工具的迭代扩展不需要多agent的管理
基本的工作框架

实现流程
Input:任务描述,上下文agent:理解任务,规划步骤,完成任务,生成结果output:提供答案
主要的工作流
instructions:指令,提示tools:工具Guardrails:规则Hooks:接口(用于实现工程化运维)
关于循环的理念
每种编排模式都有运行的概念,即是作为一个循环的整体,直到退出
While的循环是agent的核心
一个最有效管理agent的方法就是设定好它的系统提示词
- 有效适应上下文,并简化了维护和评估的额外开销
- 并且只需要更新它的提示词并不需要重写工作流
多agent的设计需求
-
直观的概念分离
-
处理复杂的指令
(当需求包含多重条件,并且提示词难以扩展,以及当没有办法明确工具的定义,功能,以及描述,即需要多agent的调用)
多agent设计
manager:管理:作为核心调用多个功能专一的agent,每个agent负责特定功能Decentraliezd:分散:多个agent分工合作,负责一部分区域,并且互相传递任务
如果建模为图(以智能体为节点)
Manager:边缘表示工具调用Decentraliezd:边缘表示agent之间的转换。
Manager Pattern
Manager Pattern使核心的agent通过工具调用监控,主要的agent拥有最大权限,通过上下文内容理解选择正确的agent进行工作,将结果合并为一个有效的交互。
基本框架

声明性图和非声明性图
有些框架是声明式的,要求开发者通过节点和以及明确定义的图
- 优点:提高视觉清晰度
- 缺点:使工作流更加的复杂,需要学习特定的语言。
agents SDK(agent的专用开发)
采用的是非声明性图,开发者采用的是自己熟悉的变成结构来表达工作流的逻辑
- 优点:更加灵活,具有动态性,适应性更强
Decentraliezd pattern
在同等基础上使用多agents,其中每个单一的agent可将工作流控制转交到其他agent上(移交是一种单向策略)
在其中,agent可以相互“切换”工作流执行(切换是一种工具或功能,在调用切换函数或工具后,我们将开启新的agent执行)
主要受众
不需要单一agent维护manager,允许多agent接管
典型案例

适用人群
- 对分类对话等场景有特殊需求的
- 当希望专门的agent完全接管,可以为第二个agent配置传回第一个agent的切换功能
Guardrails
合适的guardrails可以有效管理数据的隐私风险
基于LLM的部署的关键组件,要与身份验证与协议,访问权限与软件安全相结合
合理使用多层次的guardrails能更弹性的防护
基本类别
- 相关性分类:跟内容是否有关
- 安全分类:越狱或提示注入
- pll过滤:防止个人信息泄露
- 调节:标记有害或不当的行为
- 工具防护:评估风险,合理风控
- 基于规则保护:如禁用sql注入等
- 输出验证
基本框架

有效的方法
- 重点关注数据隐私和内容安全
- 根据实际情况添加新的guardrails
- 优化安全性和用户体验
